How Route-Reflector clusters prevent loops

This is the topology I used to get familiar with the concept:


The idea is fairly easy to understand. You never want to learn routes from someone who learned them from you (directly or indirectly). I made the peers one by one to step through the process.

Here is the route on R1:

R1#sho ip bgp 200.0.0.0
BGP routing table entry for 200.0.0.0/8, version 12
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
3
100, (Received from a RR-client)
6.6.6.6 (metric 2) from 6.6.6.6 (6.6.6.6)
Origin IGP, metric 0, localpref 100, valid, internal, best
R1#

Now on R2, we see the first case of the origintaor-id as set by R1. And we also see the beginning of the cluster-list:

R2#sho ip bgp 200.0.0.0
BGP routing table entry for 200.0.0.0/8, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
100
6.6.6.6 (metric 3) from 1.1.1.1 (1.1.1.1)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 6.6.6.6, Cluster list: 1.1.1.1
R2#

R2 appends itself to the cluster-list before advertising to R5:

R5#sho ip bgp 200.0.0.0
BGP routing table entry for 200.0.0.0/8, version 12
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
2
100
6.6.6.6 (metric 2) from 2.2.2.2 (2.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 6.6.6.6, Cluster list: 2.2.2.2, 1.1.1.1
R5#

Eventually, these are the messages we get on R6 and R2, respectively.

R6#
*Mar 1 00:44:55.807: BGP(0): 5.5.5.5 rcv UPDATE about 201.0.0.0/8 -- DENIED due to: ORIGINATOR is us;
*Mar 1 00:44:55.811: BGP(0): 5.5.5.5 rcv UPDATE about 200.0.0.0/8 -- DENIED due to: ORIGINATOR is us;

R2#
*Mar 1 00:53:39.075: BGP(0): 3.3.3.3 rcv UPDATE about 201.0.0.0/8 -- DENIED due to: CLUSTERLIST contains our own cluster ID;
*Mar 1 00:53:39.083: BGP(0): 3.3.3.3 rcv UPDATE about 200.0.0.0/8 -- DENIED due to: CLUSTERLIST contains our own cluster ID;

AS_SET not used in AS Path length comparison

I was reading Chapter 3 today of Routing TCP/IP Volume 2 and it says that AS_SET is not considered when determining shortest AS_PATH. So I decided to lab it and see for myself. R4 is learning the 192.168.0.0/16 aggregate from R5 and R7 each with differing AS_SET lengths.

R4#sho ip bgp | be Net
   Network          Next Hop     Metric LocPrf Weight Path
*  192.168.0.0/16   192.168.47.7      0             0 7 {8,900} i
*>                  192.168.45.5      0             0 5 {6,600,6000,3033} i

The longest one is winning! AS_SET does count as 1 AS by the way.

R4#sho ip bgp 192.168.0.0
BGP routing table entry for 192.168.0.0/16, version 4
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
     1         
  7 {8,900}, (aggregated by 7 192.168.78.7)
    192.168.47.7 from 192.168.47.7 (192.168.78.7)
      Origin IGP, metric 0, localpref 100, valid, external
  5 {6,600,6000,3033}, (aggregated by 5 192.168.56.5)
    192.168.45.5 from 192.168.45.5 (192.168.56.5)
      Origin IGP, metric 0, localpref 100, valid, external, best
R4#

All other things being equal it looks like the most recent path is winning. If we clear BGP on R5, R7 would be the most recent:

R5#clear ip bgp *
R5#
R5#
*Mar  1 01:34:11.475: %BGP-5-ADJCHANGE: neighbor 192.168.45.4 Down User reset
*Mar  1 01:34:11.479: %BGP-5-ADJCHANGE: neighbor 192.168.56.6 Down User reset
*Mar  1 01:34:11.667: %BGP-5-ADJCHANGE: neighbor 192.168.56.6 Up 
*Mar  1 01:34:12.287: %BGP-5-ADJCHANGE: neighbor 192.168.45.4 Up 

R4#sho ip bgp | be Net   
   Network          Next Hop     Metric LocPrf Weight Path
*  192.168.0.0/16   192.168.45.5      0             0 5 {6,600,6000,3033} i
*>                  192.168.47.7      0             0 7 {8,900} i
R4#

For more details, you can read this document which I am sure we have all seen by now. But little things like this may be forgotten:

BGP PATH SELECTION

BGP - fast-external-fallover

This feature allows the router to bring a BGP session down when the interface to that peer goes down. If you don't want this or are asked to not allow this to happen, you can disable it:

R1 has a neighbor:

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 188 188 38 0 0 01:56:59 4

R1(config)#int f0/0
R1(config-if)#shut

*Dec 7 03:16:21.270: %BGP-5-ADJCHANGE: neighbor 136.10.12.2 Down Interface flap

We can prevent R1 from tearing the session down by disabling fast-external-fallover:

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 196 194 50 0 0 00:00:03 4

R1(config)#router bgp 100
R1(config-router)#no bgp fast-external-fallover
R1(config-router)#int f0/0
R1(config-if)#shut
R1(config-if)#

*Dec 7 03:19:41.386: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Dec 7 03:19:42.386: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R1(config-if)#^Z

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 196 194 54 0 0 00:00:50 4

Still up:

R1#show ip bgp sum | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
136.10.12.2 4 200 196 195 54 0 0 00:01:29 4

Now the session will come down when the hold time expires. Some things to remember:

-Only works for directly-connected EBGP peers (hence the word "external" in the command)
-I tested with ebgp-multihop peers and it does not have any effect
-Keepalives are use to bring session down
-Also configurable per-interface with ip bgp fast-external-fallover

BGP - Conditional route injection

Topology

R5----R7

R5 is advertising 10.34.19.0/26 to R7
Configure R7 to inject 10.34.19.48/28

1) MAKE PREFIX-LISTS

ip prefix-list EXIST seq 5 permit 10.34.19.0/26
ip prefix-list INJECT 5 permit 10.34.19.48/28
ip prefix-list SOURCE seq 5 permit 192.168.5.5/32


2) MAKE ROUTE-MAPS

route-map INJECT permit 10
set ip address prefix-list INJECT

route-map EXIST permit 10
match ip address prefix-list EXIST
match ip route-source prefix-list SOURCE


3) CONFIGURE BGP

route bgp 567
bgp inject-map INJECT exist-map EXIST


4) VERIFY

R5#show ip bgp nei 192.168.7.7 advertised-routes | begin Net
Network Next Hop Metric LocPrf Weight Path
*> 10.34.19.0/26 192.168.2.2 0 200 0 24 1 i

R7#show ip bgp injected-paths | begin Net
Network Next Hop Metric LocPrf Weight Path
*>i10.34.19.48/28 192.168.5.5 0 200 0 24 1 i

Things to remember:

- Must use Prefix-lists, NOT ACLs
- Injected route must a subset of am aggregate already in the table
- Use "set" command for inject-map, not "match"
- I commonly forget the "prefix-list" argument when configuring the maps
- inject-map Command is a bgp command, not per-neighbor

BGP - Local AS notes

Here is the topology:

R6[AS256]-----R9[AS9999]=====BB3[AS3561]

We will be looking at the BGP tables of R6 and BB3 as we test each option of the local-as neighbor configuration.

1) LOCAL-AS

R9 has local-as configured with as 19999. R6 sees routes as follows, with 19999 in between BB2 and R9 real AS number.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 19999 3561 ?
*> 150.100.69.9 0 9999 19999 3561 ?

BB3 sees routes from R9 in the same way, as if AS19999 was connected between itself and R9:

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i


2) LOCAL-AS NO-PREPEND

With the no-prepend option, R6 does not see 19999 in the path:

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?

This command has no impact on the routes BB3 receives. They look the same.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 9999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 9999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 9999 256 i


3) LOCAL-AS NO-PREPEND REPLACE-AS

With the Replace-as, everything looks the same as the last command on R6.

R9#show run | inc local-as
neighbor 100.100.250.250 local-as 19999 no-prepend replace-as
R9#

R6#show ip bgp

* 102.0.0.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.16.0/20 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.32.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?
* 102.0.48.0/22 150.100.96.9 0 9999 3561 ?
*> 150.100.69.9 0 9999 3561 ?

However on BB3 we now see a difference as 9999 is no longer in the path.

CoreTech-BB3#show ip bgp
*> 150.100.25.0/24 100.100.250.9 0 19999 256 i
*> 150.100.69.0/24 100.100.250.9 0 19999 256 i
*> 150.100.91.0/24 100.100.250.9 0 0 19999 i
*> 150.100.96.0/24 100.100.250.9 0 19999 256 i

BGP - RIP failures and suppress-inactive

Here is the topology:

R1 [AS10] ----- R2 [AS256]------R6[AS256]

The network between R2 and R6 is 150.100.100.0/24. This network is advertised into BGP on R6 but not R2. Because this is a connected route, R2 does not install it as a BGP route. It does receive the advertisement however and propagate it to R1.

Here is the R2 config:

R2#show run | sec router bgp
router bgp 256
no synchronization
bgp log-neighbor-changes
network 150.100.25.0 mask 255.255.255.0
neighbor 150.100.12.1 remote-as 10
neighbor 150.100.100.6 remote-as 256
neighbor 150.100.100.6 route-reflector-client
no auto-summary

Here is the R6 config:

R6#show run | sec router bgp
router bgp 256
no synchronization
bgp log-neighbor-changes
network 150.100.69.0 mask 255.255.255.0
network 150.100.96.0 mask 255.255.255.0
network 150.100.100.0 mask 255.255.255.0
neighbor 150.100.100.2 remote-as 256
no auto-summary

Here is R2's BGP table:

R2#show ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
*> 150.100.25.0/24 0.0.0.0 0 32768 i
*>i150.100.69.0/24 150.100.100.6 0 100 0 i
*>i150.100.96.0/24 150.100.100.6 0 100 0 i
r>i150.100.100.0/24 150.100.100.6 0 100 0 i

Notice the last entry has an 'r' next to it. This is not installed in the route table as a BGP route. It is already installed as connected. This is known as a RIB failure.

But the route is advertised to R1:

R1#show ip route bgp
150.100.0.0/16 is variably subnetted, 7 subnets, 2 masks
B 150.100.96.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.100.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.69.0/24 [20/0] via 150.100.12.2, 00:05:25
B 150.100.25.0/24 [20/0] via 150.100.12.2, 00:05:25

Now here's the tricky part. You can use the BGP suppress-inactive command to prevent RIB failures from getting advertised. But when I use it on R2 and R6 it doesn't work quite like I expected.

R2#show run | inc inac
bgp suppress-inactive
R2#

R6#show run | inc inac
bgp suppress-inactive
R6#

Notice here that R1 still has the 150.100.100.0 route from R2:

R1#clear ip bgp *
R1#
*Nov 23 13:59:37.379: %BGP-5-ADJCHANGE: neighbor 150.100.12.2 Down User reset
*Nov 23 13:59:38.039: %BGP-5-ADJCHANGE: neighbor 150.100.12.2 Up
R1#
R1#show ip bgp
BGP table version is 5, local router ID is 200.0.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 150.100.25.0/24 150.100.12.2 0 0 256 i
*> 150.100.69.0/24 150.100.12.2 0 256 i
*> 150.100.96.0/24 150.100.12.2 0 256 i
*> 150.100.100.0/24 150.100.12.2 0 256 i

Anybody know how this command is supposed to work in preventing RIB failures from getting advertised in BGP?

Debugging an E-BGP multihop scenario

I have the following frame-relay hub and spoke topology:

R5----R2----R6

R2 is the hub, all routers are in the 150.100.100.0/24 subnet.

R2 = 150.100.100.2
R5 = 150.100.100.5
R6 = 150.100.100.6

Please note that R2 has one multipoint subinterface connected to R5 and R6. Blogspot doesn't like text drawings so I must draw it like above.

All routers are in sub-AS bgp confederations. R2 can only peer with one, and R5 and R6 must peer with each other.

The peers will not come up without ebgp-multihop configured, but suppose we forgot that. What kind of debugging could we do to lead us to that conclusion?

1) debug ip bgp

R6#
*May 25 04:46:18.587: BGP: 150.100.100.5 open active, local address 150.100.100.6
*May 25 04:46:48.587: BGP: 150.100.100.5 open failed: Connection timed out; remote host not responding, open active delayed 29387ms (35000ms max, 28% jitter)

This debug command shows us that BGP never completes the Active state. RFC 1771 tells us this about the Active state:

"In this state BGP is trying to acquire a peer by initiating a transport protocol connection."

So our TCP connection is not completing. Do you we have IP connectivity to R5? Sure:

R6#ping 150.100.100.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.100.100.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/102/108 ms
R6#

So now we can look higher up the protocol stack (e.g. filtering), or maybe the problem is still in the IP layer. In this case we have no ACL's applied.

2) debug ip packet detail

What I am looking for here is some packets from R5, sourced from 150.100.100.5. Debugging shows that I am getting none! However it also shows that I am getting ICMP type 11 messages from R2 immediately after I send a packet to R5:

R6#
*May 25 04:51:44.539: IP: tableid=0, s=150.100.100.6 (local), d=150.100.100.5 (Serial0/1/0), routed via FIB
*May 25 04:51:44.539: IP: s=150.100.100.6 (local), d=150.100.100.5 (Serial0/1/0), len 44, sending
*May 25 04:51:44.539: TCP src=24713, dst=179, seq=1584149779, ack=0, win=16384 SYN
*May 25 04:51:44.563: IP: tableid=0, s=150.100.100.2 (Serial0/1/0), d=150.100.100.6 (Serial0/1/0), routed via RIB
*May 25 04:51:44.563: IP: s=150.100.100.2 (Serial0/1/0), d=150.100.100.6 (Serial0/1/0), len 56, rcvd 3
*May 25 04:51:44.563: ICMP type=11, code=0

Seems that R2 is telling us something about our packet sent to R5.

3) debug ip icmp

*May 25 04:53:23.839: ICMP: time exceeded rcvd from 150.100.100.2

Here we get our answer. At this point we realize that our tcp syn packets sent to R5 have an IP TTL of 1, and thus are getting dropped by R2.

Do you know any other commands that would help you come to this conclusion?

BGP - peer session templates

I had a task to configure bgp timers on R2 for the peering session to R1. I was not to use "timers bgp" or any neighbor commands withe the word "timers". I immediately thought of peer-session templates which was something I came across while reading the DocCD one day. Here is how it works. We are on R2:

R2(config)#router bgp 2456

R2(config-router)#template ?
peer-policy Template configuration for policy parameters
peer-session Template configuration for session parameters

R2(config-router)#template peer-session TEMPLATE-R1

R2(config-router-stmp)#timers 30 90
R2(config-router-stmp)#exit

R2(config-router)#neighbor 150.21.21.1 inherit ?
peer-policy Inherit a peer-policy template
peer-session Inherit a peer-session template

R2(config-router)#neighbor 150.21.21.1 inherit peer-session TEMPLATE-R1

Now we must clear bgp then debug bgp keepalives to verify. Here we can see that R2 is sending keepalives to R1 every 30 seconds, while the other peers are still at 60 seconds.

*Oct 18 18:28:15.486: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:28:15.486: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:28:46.166: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:28:46.166: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:01.166: BGP: 150.20.25.5 sending KEEPALIVE (io)
*Oct 18 18:29:01.490: BGP: 150.20.25.5 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:09.946: BGP: 150.20.246.4 sending KEEPALIVE (io)
*Oct 18 18:29:09.950: BGP: 150.20.246.4 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:15.654: BGP: 150.20.246.6 sending KEEPALIVE (io)
*Oct 18 18:29:15.654: BGP: 150.20.246.6 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:15.654: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:29:15.654: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:29:46.166: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:29:46.166: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:01.166: BGP: 150.20.25.5 sending KEEPALIVE (io)
*Oct 18 18:30:01.490: BGP: 150.20.25.5 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:09.946: BGP: 150.20.246.4 sending KEEPALIVE (io)
*Oct 18 18:30:09.946: BGP: 150.20.246.4 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:15.654: BGP: 150.20.246.6 sending KEEPALIVE (io)
*Oct 18 18:30:15.654: BGP: 150.20.246.6 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:15.654: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:30:15.658: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0
*Oct 18 18:30:46.166: BGP: 150.21.21.1 sending KEEPALIVE (io)
*Oct 18 18:30:46.166: BGP: 150.21.21.1 received KEEPALIVE, length (excl. header) 0

BGP - Allowas-in with number of occurrences

I ran into this BGP issue on IPexpert volume 2 Lab 4 today. Cat 1 is in AS 500. There are 3 other ASes, but CAT1 needs to see all of these as AS8888. Confederations right? For 2 of the ASes that is right, but the task says NOT to use a sub-as for AS78. Here is the AS map:

As500----As100----AS2456====AS78

AS2456 has 2 connections (R5 and R6) to AS78 (R7).

On R5 and R6 I have this ( I am allowed to use confederations on AS 2456):

router bgp 2456
bgp confederation identifier 8888
neighbor 150.20.56.7 remote-as 8888

on R7 I have this:

router bgp 78
neighbor 150.20.56.5 remote-as 8888
neighbor 150.20.56.5 local-as 8888
neighbor 150.20.56.5 allowas-in
neighbor 150.20.56.6 remote-as 8888
neighbor 150.20.56.6 local-as 8888
neighbor 150.20.56.6 allowas-in

Works great so far:

R7#show ip bgp sum | be Neigh
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
150.10.8.8 4 78 55 64 64 0 0 00:35:46 1
150.20.56.5 4 8888 112 121 64 0 0 00:01:07 5
150.20.56.6 4 8888 109 116 64 0 0 00:01:10 5

But notice the prefix I am learning from R8 (ibgp peer with R7). That prefix does not get installed by R5 and R6 because it has AS 8888 in the path. Here is the debug from R6:

R6#debug ip bgp update
*Oct 18 17:46:11.270: BGP(0): 150.20.56.7 rcv UPDATE about 200.200.200.0/24 -- DENIED
R6(config-rout due to: AS-PATH contains our own AS;

How do we allow R6 and R5 to accept this route? By using "allowas-in" option of the neighbor command. However, because we don't want R6 to learn routes that passed from R5 to R7 we set a maximum on the number of occurrences of the AS, which is 1.

R5 and R6:

router bgp 2456
neighbor 150.20.56.7 allowas-in 1

Now here is the same debug on R6:

*Oct 18 17:56:48.366: BGP(0): Revise route installing 1 of 1 routes for 200.200.200.0/24 -> 150.20.56.7(main) to main IP table

Let's take a look at CAT1 in AS 500

Cat1#show ip bgp | begin Net

Network Next Hop Metric LocPrf Weight Path
*> 200.200.200.0 150.20.110.1 0 8888 8888 78 ?

This is not good! We can get rid of AS 78 by doing this on R7:

R7(config)#router bgp 78
R7(config-router)#neighbor 150.20.56.5 local-as 8888 no-prepend replace-as
R7(config-router)#neighbor 150.20.56.6 local-as 8888 no-prepend replace-as

Now let's take a look:

Cat1#show ip bgp | beg Net

Network Next Hop Metric LocPrf Weight Path
*> 200.200.200.0 150.20.110.1 0 8888 8888 ?

BGP - regexp practice part 1

Using regexp with as-path access-list are one of the coolest features of BGP. The show ip bgp regexp command is good way to test your regular expression.

Here is what I have currently on R1's bgp table:

R1#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i

Suppose I want to match routes that contain one AS or two AS but no more. I could do this:

R1#show ip bgp regexp ^[0-9]*$|^[0-9]*_[0-9]*$

Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i

How about paths that only contain at least one 4-digit AS# (why? i have no clue but here's how)

R1#show ip bgp regexp _[0-9][0-9][0-9][0-9]_

Network Next Hop Metric LocPrf Weight Path
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i
R1#

Well that's it for now. I'll come up with some more later.

BGP - Neighbor discovery protocol

Ok. The title is misleading, there is no such thing!

But I was doing IPexpert's volume 1 section 11 lab on BGP and I thought this would be a cool topic since I always see some posts about this on groupstudy.

R9 is connected to the same LAN as BB3. We need to peer with BB3 but we don't know the IP or the AS number of BB3.

First, we can ping the broadcast address on the ethernet segment between R9 and BB3. This works best with only 1 other host. Otherwise we would have to resort to trial and error or some other means, maybe debug ip packet.

R9#ping 100.100.250.255

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.250.255, timeout is 2 seconds:

Reply to request 0 from 100.100.250.250, 4 ms
Reply to request 1 from 100.100.250.250, 1 ms
Reply to request 2 from 100.100.250.250, 1 ms

R9#

Now we know our peer ip, but we need to know the AS number. If you peer to the wrong AS, you can see the BB AS in message debug:

R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as 1

*Aug 12 02:57:05.411: %BGP-3-NOTIFICATION: sent to neighbor 100.100.250.250 2/2 (peer in wrong AS) 2 bytes 0DE9
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0DE9 00B4 6E0F 90C8 1002 0601 0400 0100 0102 0280 0002 0202 00

Here the neighbor is in AS 0DE9 (3561)

R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as

*Aug 12 02:59:12.359: %BGP-5-ADJCHANGE: neighbor 100.100.250.250 Up

Cool, eh?

BGP - TTL security

Suppose R5 and R6 are EBGP peers. Each send BGP packets with TTL of 1 to each other. They process any BGP packet with a TTL value of 1 or higher. So if an attacker wants to cause mayhem he can send tons of BGP packets to an edge router in a type of DoS attack and these packets will be processed no matter how far away the attacker is. With BGP TTL Security we can configure the router to expect to receive packets with higher TTL values. That way, an attacker more than the configured number of hops away, will never be able to DoS the router.

Example:

On R6 we configure:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 ttl-security hops 5

After 3 minutes (BGP default time) without a keepalive, R6 drops the neighbor:

Mar 1 03:16:55.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.5 Down BGP Notification sent
Mar 1 03:16:55.467: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.5 4/0 (hold time expired) 0 bytes

The reason this happens is because after the TTL security command is configured, R6 will silently drop any packet with a TTL lower of 250 or lower. If it receives a packet with TTL 250, I think it will drop it according to my testing. How can we make R5 send packets with a TTL of 251? We can use TTL-security on that router to or use ebgp-multihop.

In this case I use ebgp-multihop:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 ebgp-multihop 251

.Jul 14 23:01:46.740: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

In this case we use TTL security on R5:

R5(config)#router bgp 65005
R5(config-router)#no neighbor 172.14.45.6 ebgp-multihop 251
R5(config-router)#neighbor 172.14.45.6 ttl-security hops 5

After clearing the session:

.Jul 14 23:05:15.131: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up

You can verify like this:

R6#show ip bgp neighbors 172.14.45.5 | inc TTL
(output omitted)
External BGP neighbor may be up to 5 hops away.
Connection is ECN Disabled, Mininum incoming TTL 250, Outgoing TTL 255

I don't know why ebgp-multihop didn't work with 250. Perhaps the router decrements it before processing and then sees 249 as the TTL.

BGP - local-as option

BGP local-as option allows a router to appear as if it is in another AS. Suppose we have a frame-relay cloud with 3 routers all EBGP peers with each other:

R6: 172.14.45.6 (AS 65000)
R5: 172.14.45.5 (AS 65005)
R4: 172.14.45.4 (AS 345)

We can configure R6 to use the local-as option to appear to be from AS 65006 to R5, but remain in AS65000 for R4. Here's how:

R6(config-router)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006

On R5:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65006

Let's take a look at the neighbor summary:

R5# show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 220 221 244 0 0 00:03:39 9

R4#show ip bgp summary | be Ne
172.14.45.6 4 65000 176 146 69 0 0 00:00:08 11

Notice the different AS numbers. Also notice the AS path from R5's view:

R5# show ip bgp | inc 172.14.45.6
*> 6.0.3.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 65000 i

And the AS path from R6's view also includes the local-AS number:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65006 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65006 65005 i

The routes appear to magically pass through 65006. We can prevent R6 from prepending the local-as number on routes received from R6 with the no-prepend option

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend

65006 is no longer in the AS Path:

R6#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 2.2.2.2/32 172.14.45.5 0 65005 65002 i
*> 5.5.5.5/32 172.14.45.5 0 0 65005 i

With the replace-AS we can prevent R5's real BGP AS number from appearing in the AS path on routes from R6 to R5:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as

R5# show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 6.0.3.0/24 172.14.45.6 0 0 65006 i
*> 6.0.4.0/24 172.14.45.6 0 0 65006 i
*> 6.0.5.0/24 172.14.45.6 0 0 65006 i

Lastly, we can configure R6 to accept connections to either AS 65000 or AS 65006 with the dual-as option:

R6(config)#router bgp 65000
R6(config-router)#neighbor 172.14.45.5 local-as 65006 no-prepend replace-as dual-as

R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65006 268 284 343 0 0 00:00:08 9

R5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 remote-as 65000
R5(config-router)#
.Jul 14 21:34:34.273: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Remote AS changed
R5(config-router)#
.Jul 14 21:34:36.505: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
R5(config-router)#
R5(config-router)#^Z
R5#show ip bgp summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 270 286 0 0 0 00:00:09 0

BGP - maximum-prefix command

The network:

[R5]---[R6]

R5 connects to R6 via EBGP
R5 is 172.14.45.5
R6 is 172.14.45.6

R6 is advertising 10 networks to R5:

R5#show ip bgp | inc 45\.6
*> 6.0.0.0/24 172.14.45.6 0 0 65000 i
*> 6.0.1.0/24 172.14.45.6 0 0 65000 i
*> 6.0.2.0/24 172.14.45.6 0 0 65000 i
*> 6.0.3.0/24 172.14.45.6 0 0 65000 i
*> 6.0.4.0/24 172.14.45.6 0 0 65000 i
*> 6.0.5.0/24 172.14.45.6 0 0 65000 i
*> 6.0.6.0/24 172.14.45.6 0 0 65000 i
*> 6.0.7.0/24 172.14.45.6 0 0 65000 i
*> 6.0.8.0/24 172.14.45.6 0 0 65000 i
*> 6.0.9.0/24 172.14.45.6 0 0 65000 i

I am going to play with a few options of the maximum-prefix command and see the effect. First let's configure a maximum of 8 routes:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8
R5(config-router)#
.Jul 14 20:45:41.467: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down Maximum-Prefix restart timeout
.Jul 14 20:46:10.519: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:46:11.919: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:46:11.927: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:46:11.931: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:46:11.931: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
R5(config-router)# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0058 0200 0000 1940 0
101 0040 0204 0201 FDE8 4003 04AC 0E2D 0680 0404 0000 0000 1806 0009 1806 0008 1
806 0007 1806 0006 1806 0005 1806 0004 1806 0003 1806 0002 1806 0001 1806 0000

Notice that the nighbor tried to come up after I configured the max. It never tried to come up again after going down the second time. Now the neighbor has the following output (much of the output is omitted):

R5#show clock
.20:50:26.655 UTC Mon Jul 14 2008
R5#

R5#show ip bgp neighbor 172.14.45.6
...
Peer had exceeded the max. no. of prefixes configured.
Maximum prefixes allowed 8
Threshold for warning message 75%
Reduce the no. of prefix and clear ip bgp 172.14.45.6 to restore peering

We can also configure the router to try and establush the connection again after the max limit is reached and the connection is brought down:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 restart 1

Here is a sample of the output, the connection tries to re-establish but then drops because the max-prefix limit is reached:

R5#
.Jul 14 20:53:16.779: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:53:16.811: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:53:16.819: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:53:16.823: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:53:16.827: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:54:15.999: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:54:16.011: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:54:16.015: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:54:16.023: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:54:16.023: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes
.Jul 14 20:55:41.311: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 20:55:41.355: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8
.Jul 14 20:55:41.359: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8
.Jul 14 20:55:41.363: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Down BGP Notification sent
.Jul 14 20:55:41.367: %BGP-3-NOTIFICATION: sent to neighbor 172.14.45.6 3/1 (update malformed) 0 bytes

We can also configure a percentage to give us a warning. Here we configure the percantge to 75 of 8 (6) while disabling 3 of the loopbacks on R6:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 7

.Jul 14 21:00:08.226: %BGP-5-ADJCHANGE: neighbor 172.14.45.6 Up
.Jul 14 21:00:08.234: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 7, max 8

The connection stays up:

R5#show ip bgp summary

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 186 177 224 0 0 00:00:33 7

Lastly, we can configure a warning-only which doesn't bring down the connection:

R5(config)#router bgp 65005
R5(config-router)#neighbor 172.14.45.6 maximum-prefix 8 75 warning-only

.Jul 14 21:01:53.614: %BGP-4-MAXPFX: No. of prefix received from 172.14.45.6 (afi 0) reaches 8, max 8
.Jul 14 21:02:24.046: %BGP-3-MAXPFXEXCEED: No. of prefix received from 172.14.45.6 (afi 0): 9 exceed limit 8

The connection stays up:

R5#show ip bgp summary | be Ne
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.14.45.6 4 65000 190 181 226 0 0 00:02:41 9

This was a quick and dirty blog. Hopefully by reading this every now and then you get an idea about how the max-prefix option works.

BGP - deterministic-med and always-compare-med

The inspiration for this blog was directly from here:

How the bgp deterministic-med Command Differs from the bgp always-compare-med Command

In order to get the various routes to look right in the bgp table, it took some work. Here is a picture that helps explain it. I'm not gonna put addressing on it. If you want configs, let me know.


Our focus is on R1, it has 3 bgp entries to 3.3.3.0:

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 24
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.12.2 172.12.14.4
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external, best
R1#

Tiebreaker:
1. entry1 and entry2 are compared, entry2 is picked because external > internal
2. entry2 and entry3 are compared, entry 3 picked because RID 3.3.3.3

Now let's configre always-compare-med:

R1(config)#router bgp 65000
R1(config-router)#bgp always-compare-med

This command should allow entry1 to be picked over entry2 (lower MED), then entry1 will be preferred over entry3 (also lower MED):

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 41
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external

It works!

Notice that entries are compared in pairs. To get the pairs reordered you may have shut peers down and enable them accordingly. Example: I wanted the peers to appear in this order 4.0.3.4, 3.3.3.3, and 2.2.2.2. So I brought them up in reverse order: 2.2.2.2, 3.3.3.3, and finally 4.0.3.4. I just did a shut/no shut on the interface. Now I have:

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 47
Paths: (3 available, best #3, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best

Notice the best route is still from 2.2.2.2 because always-compare-med is enabled. Let's try bgp deterministic-med, without always compare-med. First reset bgp, then continue.

R1(config)#router bgp 65000
R1(config-router)#no bgp always-compare-med
R1(config-router)#bgp deterministic-med

In this case entry2 should be compared to entry3 with entry 2 winning based on lower MED (they are in the same AS so MED is compared). Then entry2 is compared to entry1, with entry1 winning because external bgp is preferred over internal. MED is not compared between these entries.

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 11
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.12.2 172.12.14.4
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external, best
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external

Notice in the above example that the entries are ordered in groups based on AS. I brough up 4.4.4.4 last, but it is showing up last with the other entry from AS400.

The last example uses both bgp deterministic-med and bgp always-compare-med. In this case, entry2 should win with the lowest MED. This is the same as the last example except MED is used for comparison between entry1 and entry2.

R1#show ip bgp 3.3.3.0
BGP routing table entry for 3.3.3.0/24, version 12
Paths: (3 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
172.12.13.3 172.12.14.4
65003
172.12.13.3 from 172.12.13.3 (3.3.3.3)
Origin IGP, metric 200, localpref 100, valid, external
400
172.12.12.2 from 172.12.12.2 (2.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
400
172.12.14.4 from 172.12.14.4 (4.0.3.4)
Origin IGP, metric 150, localpref 100, valid, external

Sweet!

BGP - set clauses are ignored on reflected routes

Network:

R4,R5,R6 have serial interfaces connected to Frame cloud 172.14.45.0/24
R3,R4,R5 have LAN interfaces connected to 172.12.34.0/24

R6 has EBGP peering with R5 and R4, however R5 has R6 neighbor shutdown for now.
R4 is connected to R5 via IBGP.
R5 then connects to R3 via IBGP.
R5 has R3 configured as a route-reflector client.
R5 reflects routes learned from R4 to R3.
R5 has the following config:

router bgp 345
bgp cluster-id 5
neighbor 3.3.3.3 remote-as 345
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community
neighbor 3.3.3.3 route-reflector-client
neighbor 3.3.3.3 route-map SET out
!
ip prefix-list SIX seq 5 permit 6.0.0.0/24
!
route-map LOOPBACK permit 10
match ip address 5
!
route-map SET permit 10
match ip address prefix-list SIX
set community 500
!
route-map SET permit 20
!

The community does not show up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 0.0.0.5

Now let's peer R5 directly with R6 and see what happens:

R5(config)#router bgp 345
R5(config-router)#neighbor 4.4.4.4 shutdown
R5(config-router)#no neighbor 172.14.45.6 shutdown

Immediately the community shows up on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 13
Paths: (1 available, no best path)
Flag: 0x820
Not advertised to any peer
65000
172.14.45.6 (inaccessible) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 200, localpref 100, valid, internal
Community: 500

I got this info while browsing the DocCD:

Configuring a Route Reflector

"The use of set clauses in outbound route maps can modify attributes and possibly create routing loops. To avoid this behavior, set clauses of outbound route maps are ignored for routes reflected to iBGP peers."

BGP - changing cluster-id

The network:

[R3]---[R5]---[R4]---[EXTERNAL AS]

R3 is IBGP peer with R5
R5 is IBGP peer with R4
R5 is the route reflector

Here is the bgp entry for a route learned initially from R4:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 5
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 5.5.5.5

Changing the cluster-id:

R5(config)#router bgp 345
R5(config-router)#bgp cluster-id ?
<1-4294967295> Route-Reflector Cluster-id as 32 bit quantity
A.B.C.D Route-Reflector Cluster-id in IP address format
R5(config-router)#bgp cluster-id 5

Here's how the change looks on R3:

R3#show ip bgp 6.0.0.0
BGP routing table entry for 6.0.0.0/24, version 9
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65000
4.4.4.4 (metric 2) from 5.5.5.5 (5.5.5.5)
Origin IGP, metric 0, localpref 100, valid, internal, best
Originator: 4.4.4.4, Cluster list: 0.0.0.5

BGP - prefix-based outbound route filtering

Prefix-based outbound route filtering is used so a local router can tell it's peer what routes it should send/filter. This prevents unnecessary resources from being used. There is no sense in a router sending a bunch of route updates, if they are only going to get filtered anyway.

In this example we have EBGP peers R4 and R3:

[R4]---[R3]

R3 is receiving a bunch of routes from R4:

R3#show ip bgp Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.2.0/24 172.12.34.4 0 400 65000 i
*> 2.0.3.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i
*> 4.0.1.0/24 172.12.34.4 0 0 400 i
*> 4.0.2.0/24 172.12.34.4 0 0 400 i
*> 4.0.3.0/24 172.12.34.4 0 0 400 i

R3 only wants to receive 3 routes:

1.0.0.0/24
2.0.0.0/24
4.0.0.0/24

R3 can create a prefix-list allowing these 3 routes only and advertise this to R4. R4 will use this list as a outbound filter. Let's configure it. First you need enable the advertisement of the orf capability. R3 is the one sending the prefix-list so use the send keyword. R4 is receiving the prefix-list.

R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 capability orf prefix-list send

R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 capability orf prefix-list receive

Now configure the prefix-list and apply it to the neighbor:

R3(config)#ip prefix-list ZERO seq 5 permit 1.0.0.0/24
R3(config)#ip prefix-list ZERO seq 10 permit 2.0.0.0/24
R3(config)#ip prefix-list ZERO seq 15 permit 4.0.0.0/24
R3(config)#router bgp 65003
R3(config-router)#neighbor 172.12.34.4 prefix-list ZERO in

R3#clear ip bgp * soft in prefix-filter

Here is the final result:

R3#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 3.3.3.0/24 0.0.0.0 0 32768 i
*> 4.0.0.0/24 172.12.34.4 0 0 400 i

Here are some captures I took in dynamips. The first shows the advertisement of the orf capability. The second shows the actually prefix-list R3 is sending. Wireshark shows this as "route-refresh" message. Pretty cool, eh?



Restrictions:

I used the bgp upgrade-cli command to configure these neighbors in AF mode.
Also, prefix-lists must be used, not ACL or distribute lists

For more info go here:

BGP Prefix-Based Outbound Route Filtering

BGP - expanded community-lists

BGP expanded community-lists are more flexible than their standard counterparts because they can match on regexp instead of just a community string. Here you can see the differences:

R4(config)#ip community-list standard STANDARD permit ?
<1-4294967295> community number
aa:nn community number
internet Internet (well-known community)
local-AS Do not send outside local AS (well-known community)
no-advertise Do not advertise to any peer (well-known community)
no-export Do not export to next AS (well-known community)

R4(config)#ip community-list expanded EXPANDED permit ?
LINE An ordered list as a regular-expression

Now for a little lab. R1 and R2 are both going to EBGP peer with R4. R4 will then EBGP peer with R3. R1 and R2 will each send routes with different community strings to R4, along with routes without a community. We will use an expanded list to match certain community values. Hopefully, we can get it done with one permit statement.

R1 has 4 loopback networks:
1.0.0.0/24
1.0.1.0/24
1.0.2.0/24
1.0.3.0/24

R2 has 4 loopback networks:
2.0.0.0/24
2.0.1.0/24
2.0.2.0/24
2.0.3.0/24

R1 is sending community 100 with its first two loopbacks
R2 is sending community 200 with its first two loopbacks
The other loopbacks do not have a community attached.
Here is how we do it on R1, R2 is similar:

R1(config)#ip prefix-list LOOP1 permit 1.0.0.0/24
R1(config)#ip prefix-list LOOP1 permit 1.0.1.0/24
R1(config)#route-map setcom
R1(config-route-map)#match ip address prefix LOOP1
R1(config-route-map)#set commu 100
R1(config-route-map)#exit
R1(config)#route-map setcom perm 20
R1(config-route-map)#exit
R1(config)#router bgp 65000
R1(config-router)#neighbor 172.12.14.4 send-community
R1(config-router)#neighbor 172.12.14.4 route-map setcom out

Verify on R4 (this shows R4 is receiving all loopbacks)

R4#sho ip bgp | begin Network
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.14.1 0 0 65000 i
*> 1.0.1.0/24 172.12.14.1 0 0 65000 i
*> 1.0.2.0/24 172.12.14.1 0 0 65000 i
*> 1.0.3.0/24 172.12.14.1 0 0 65000 i
*> 2.0.0.0/24 172.12.24.2 0 0 65000 i
*> 2.0.1.0/24 172.12.24.2 0 0 65000 i
*> 2.0.2.0/24 172.12.24.2 0 0 65000 i
*> 2.0.3.0/24 172.12.24.2 0 0 65000 i

Here are the loopbacks with community attributes:

R4#show ip bgp community 100 | begin Net
Network Next Hop Metric LocPrf Weight Path
* 1.0.0.0/24 172.12.14.1 0 0 65000 i
* 1.0.1.0/24 172.12.14.1 0 0 65000 i
R4#show ip bgp community 200 | begin Net
Network Next Hop Metric LocPrf Weight Path
* 2.0.0.0/24 172.12.24.2 0 0 65000 i
* 2.0.1.0/24 172.12.24.2 0 0 65000 i

Here is R3:

R3#show ip bgp

Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 1.0.2.0/24 172.12.34.4 0 400 65000 i
*> 1.0.3.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.2.0/24 172.12.34.4 0 400 65000 i
*> 2.0.3.0/24 172.12.34.4 0 400 65000 i

Now we will configure R4 to send only routes with community 100 or 200 to R3:

R4(config)#ip community-list expanded EXPANDED permit [1-2]00
R4(config)#route-map filtercom
R4(config-route-map)#match community ?
<1-99> Community-list number (standard)
<100-500> Community-list number (expanded)
WORD Community-list name
R4(config-route-map)#match community EXPANDED
R4(config-route-map)#exit
R4(config)#router bgp 400
R4(config-router)#neighbor 172.12.34.3 route-map filtercom out

Let's check on R3:

R3#show ip bgp
BGP table version is 66, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 172.12.34.4 0 400 65000 i
*> 1.0.1.0/24 172.12.34.4 0 400 65000 i
*> 2.0.0.0/24 172.12.34.4 0 400 65000 i
*> 2.0.1.0/24 172.12.34.4 0 400 65000 i

In this example the regexp string [1-2]00 matched either 100 or 200 an only allowed these routes through to R3.