I just wanted to go over some route reflection rules in my BGP preparations. I did test all of these in my lab, and the real results I saw on my devices reflect what is depicted in these diagrams. If you have any questions, or anything to say at all please leave a comment.
1. If the route is received from a non-client peer, reflect to clients only (will go to EBGP peers of the AS as well).
2. If the route is received from a RR-client, reflect to all non-client and client peers.
3. If the route is received from an EBGP peer, reflect to all clients and non-clients.
I guess it is a pretty easy concept, but labbing it up definitely helped my understanding out a bit. Cisco also has some great links on route-reflection, but I also like this one:
Wiki dot nil route reflector link...
Showing posts with label BGP. Show all posts
Showing posts with label BGP. Show all posts
Friday, May 7, 2010
Wednesday, May 5, 2010
Suppress and Unsuppress maps
Not going to dive into any great detail on this, just some notes. Say you have a router hosting these subnets:
10.0.1.0/24
10.0.2.0/24
10.0.3.0/24
10.0.4.0/24
The administrator...you, wants to advertise an aggregate address for these in the form of 10.0.0.0/8, but wants to also advertise theses specific subnets along with the aggregate:
10.0.2.0/24
10.0.3.0/24
On the aggregating router we would enter the following:
access-list 1 deny 10.0.2.0 0.0.0.255
access-list 1 deny 10.0.3.0 0.0.0.255
access-list 1 permit any
route-map SUPPRESS permit 10
match ip address 1
router bgp (as)
aggregate-address 10.0.0.0 255.0.0.0 suppress-map SUPRESS
Seems a bit counter-intuitive huh?!? Well think of it this way. The access list is going to permit any routes we WANT suppressed, and deny any that we do not. So we will advertise this to any other bgp routers. Their routing tables should have these entries:
10.0.0.0/8
10.0.2.0/24
10.0.3.0/24
BUT WAIT.... what if there is a specific neighbor that we want to unsuppress some other routes for...well, guess what? Its access-list time again!
access-list 2 permit 10.0.4.0 0.0.0.255
route-map unSUPRESS permit 10
match ip address 2
router bgp (as)
neighbor (ip address) unsuppress-map unSUPPRESS
dont forget to do a clear ip bgp * (soft) to reset your neighbors.
After that command, that specific neighbors routing table should contain these entries:
10.0.0.0/8
10.0.2.0/24
10.0.3.0/24
10.0.4.0/24
Go ahead, try it out for yourself!
10.0.1.0/24
10.0.2.0/24
10.0.3.0/24
10.0.4.0/24
The administrator...you, wants to advertise an aggregate address for these in the form of 10.0.0.0/8, but wants to also advertise theses specific subnets along with the aggregate:
10.0.2.0/24
10.0.3.0/24
On the aggregating router we would enter the following:
access-list 1 deny 10.0.2.0 0.0.0.255
access-list 1 deny 10.0.3.0 0.0.0.255
access-list 1 permit any
route-map SUPPRESS permit 10
match ip address 1
router bgp (as)
aggregate-address 10.0.0.0 255.0.0.0 suppress-map SUPRESS
Seems a bit counter-intuitive huh?!? Well think of it this way. The access list is going to permit any routes we WANT suppressed, and deny any that we do not. So we will advertise this to any other bgp routers. Their routing tables should have these entries:
10.0.0.0/8
10.0.2.0/24
10.0.3.0/24
BUT WAIT.... what if there is a specific neighbor that we want to unsuppress some other routes for...well, guess what? Its access-list time again!
access-list 2 permit 10.0.4.0 0.0.0.255
route-map unSUPRESS permit 10
match ip address 2
router bgp (as)
neighbor (ip address) unsuppress-map unSUPPRESS
dont forget to do a clear ip bgp * (soft) to reset your neighbors.
After that command, that specific neighbors routing table should contain these entries:
10.0.0.0/8
10.0.2.0/24
10.0.3.0/24
10.0.4.0/24
Go ahead, try it out for yourself!
Tuesday, May 4, 2010
BGP Syncronization
We all know the BGP rule of syncronization states that BGP speaking routers will not advertise a route within the AS unless all other routers know about the route via an IGP such as EIGRP, RIP, IGRP, etc... This is basically a black hole prevention mechanism. Take the following diagram:
Worry about AS 6501 here. Imagine R0 is hosting a route to 1.1.1.1/32. The only routers running BGP in AS 6501 are R3 and R4. R3, R4, and R7 run EIGRP AS 6501 as their IGP. Now imagine that R3's link to R0 was severed, but R3 was sending packets to 1.1.1.1. It has to go through R7 to reach 1.1.1.1 now, but R7 does not have that in its routing table. It drops the packet, creating the black hole that synchronization works to prevent. This is how you tell if a route is not synchronized:
Notice the not synchronized at the bottom of the show ip bgp output. This shows that synchronization has not been accomplished with bgp and the running igp (eigrp). This is true in this case. But say R7 has a default route out the two border routers...it would then be safe to turn off synchronization via the no synch command. Another instance where it would be safe to turn it off is if all routers in the local as were running IBGP.
Worry about AS 6501 here. Imagine R0 is hosting a route to 1.1.1.1/32. The only routers running BGP in AS 6501 are R3 and R4. R3, R4, and R7 run EIGRP AS 6501 as their IGP. Now imagine that R3's link to R0 was severed, but R3 was sending packets to 1.1.1.1. It has to go through R7 to reach 1.1.1.1 now, but R7 does not have that in its routing table. It drops the packet, creating the black hole that synchronization works to prevent. This is how you tell if a route is not synchronized:
R3#show ip route 1.0.0.0
% Network not in table
R3#show ip bgp 1.0.0.0
BGP routing table entry for 1.0.0.0/8, version 19
Paths: (1 available, no best path)
Flag: 0x820
Not advertised to any peer
1200
172.16.47.2 (metric 30720) from 172.16.47.2 (172.16.47.2)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
Notice the not synchronized at the bottom of the show ip bgp output. This shows that synchronization has not been accomplished with bgp and the running igp (eigrp). This is true in this case. But say R7 has a default route out the two border routers...it would then be safe to turn off synchronization via the no synch command. Another instance where it would be safe to turn it off is if all routers in the local as were running IBGP.
Tuesday, April 27, 2010
BGP Conditional Advertisements
I am still preparing for my BGP exam, and found myself going through Narbiks old Soup-to-Nuts BGP labs. They are very interesting. One thing that caught me off guard was conditional route advertisements in bgp. They were not discussed in either of the BGP books I read unfortunately. So, I decided to post a bit here. Take the following topo:
Now suppose R1 is the hub in AS 100, the other two are in AS 200, 300. The only router with an EBGP peering with all other routers is R1. So we want R1 to only advertise 2.2.2.2 to R3 only if 1.1.1.1 is present in the BGP table. If 1.1.1.1 disappears we want 2.2.2.2 to also not be advertised to R3. So how can we do this...well by advertise maps is how. The config looks like this....first we create access-lists and route-maps to identify those two routes:
Then we configure our neighbor statement under our BGP process:
So lets go through what this means...To neighbor 131.1.13.3 we want to advertise NotThere (2.2.2.2) only if advertise (1.1.1.1) *exists*. So if 1.1.1.1 is present, 2.2.2.2 is advertised to R3 as well. If its not present, and 2.2.2.2 is, 2.2.2.2 is pulled from the advertisements. Its worth mentioning that there is also a non-exist-map you can use to say advertise this when this (non-advertise-map) is absent from the bgp table. Handy little tools. You can verify with the "show ip bgp neighbor [ip address] advertised-routes" command, or this:
You should see the condition-map line third up from the bottom. It tells you the route-map mappings by name, and also the status of the condition-map. Here it is advertise because the 1.1.1.1 route is up. If I were to shut down that interface the status would move to withdrawn. On a side note, today when I initially set this up I got a status uninitialized message. After quite a bit of digging, thanks Brian McGahan, I found a groupstudy post that mentioned that there was a bug in the 12.0(T) release that made this happen. I upgraded the IOS and got some joy from my router. Thanks for listening.
Now suppose R1 is the hub in AS 100, the other two are in AS 200, 300. The only router with an EBGP peering with all other routers is R1. So we want R1 to only advertise 2.2.2.2 to R3 only if 1.1.1.1 is present in the BGP table. If 1.1.1.1 disappears we want 2.2.2.2 to also not be advertised to R3. So how can we do this...well by advertise maps is how. The config looks like this....first we create access-lists and route-maps to identify those two routes:
Then we configure our neighbor statement under our BGP process:
So lets go through what this means...To neighbor 131.1.13.3 we want to advertise NotThere (2.2.2.2) only if advertise (1.1.1.1) *exists*. So if 1.1.1.1 is present, 2.2.2.2 is advertised to R3 as well. If its not present, and 2.2.2.2 is, 2.2.2.2 is pulled from the advertisements. Its worth mentioning that there is also a non-exist-map you can use to say advertise this when this (non-advertise-map) is absent from the bgp table. Handy little tools. You can verify with the "show ip bgp neighbor [ip address] advertised-routes" command, or this:
You should see the condition-map line third up from the bottom. It tells you the route-map mappings by name, and also the status of the condition-map. Here it is advertise because the 1.1.1.1 route is up. If I were to shut down that interface the status would move to withdrawn. On a side note, today when I initially set this up I got a status uninitialized message. After quite a bit of digging, thanks Brian McGahan, I found a groupstudy post that mentioned that there was a bug in the 12.0(T) release that made this happen. I upgraded the IOS and got some joy from my router. Thanks for listening.
Thursday, April 15, 2010
BGP Route Dampening
Quick run through BGP Route Dampening this morning. I'm in a hurry, so I might not hit all the details. Heres the topology:
So in this scenario R1 and R0 are running OSPF between them, and RT1 is running EBGP with R2 in AS3. R2 and R3 are running IBGP with each other in AS3. RT1 is redistributing bgp routes into OSPF. Now, R2's route to 172.16.220.0/24 is flapping. The admin of AS1 wants to apply route dampening to that route, and suppress it if it goes over a certain penalty.
Half Life - 20 minutes
reuse-limit - 950
suppress-limit- 2500
max-suppress-time- 80 minutes
Heres the commands:
You should be able to see where I used the requirements above to plug in damening values into the route-map set statements. Here is the output, after I bounced the route for 172.16.220.0/24 a couple of times:
The first one shows the route after it has flapped twice. You can see that it has a penalty of 1932, below the 2500 that we set the suppression penalty to. So the route is not suppressed yet. It is important to note that the penalty slowly decreases over time as the route is stable. This is how a route recovers from dampening also. The next show ip bgp output actually shows the route after it has flapped 3 times. Now it is suppressed, notice the message "suppressed due to dampening." The dampinfo now shows the penalty 2841 (> 2500). This is awesome!!! So now the route is going to be suppressed until the penalty falls below 950. I originally thought this would be in 9 minutes 49 seconds...but when this number go to 0, the penalty was only at 2032, and it restarted the timer at like 10 minutes. Check it out:
Of course you can manually clear the dampening if you, or the administrator, feel that the route is stable again:
Here is some termonoligy from Cisco on dampening:
So in this scenario R1 and R0 are running OSPF between them, and RT1 is running EBGP with R2 in AS3. R2 and R3 are running IBGP with each other in AS3. RT1 is redistributing bgp routes into OSPF. Now, R2's route to 172.16.220.0/24 is flapping. The admin of AS1 wants to apply route dampening to that route, and suppress it if it goes over a certain penalty.
Half Life - 20 minutes
reuse-limit - 950
suppress-limit- 2500
max-suppress-time- 80 minutes
Heres the commands:
You should be able to see where I used the requirements above to plug in damening values into the route-map set statements. Here is the output, after I bounced the route for 172.16.220.0/24 a couple of times:
The first one shows the route after it has flapped twice. You can see that it has a penalty of 1932, below the 2500 that we set the suppression penalty to. So the route is not suppressed yet. It is important to note that the penalty slowly decreases over time as the route is stable. This is how a route recovers from dampening also. The next show ip bgp output actually shows the route after it has flapped 3 times. Now it is suppressed, notice the message "suppressed due to dampening." The dampinfo now shows the penalty 2841 (> 2500). This is awesome!!! So now the route is going to be suppressed until the penalty falls below 950. I originally thought this would be in 9 minutes 49 seconds...but when this number go to 0, the penalty was only at 2032, and it restarted the timer at like 10 minutes. Check it out:
Of course you can manually clear the dampening if you, or the administrator, feel that the route is stable again:
Here is some termonoligy from Cisco on dampening:
Understanding Route Dampening Terms
The following terms are used when describing route dampening:
•
Flap—A route is available, then unavailable, or vice versa.

•
History state—After a route flaps once, it is assigned a penalty and put into history state, meaning the router does not have the best path, based on historical information.

•
Penalty—Each time a route flaps, the router configured for route dampening in another autonomous system assigns the route a penalty of 1000. Penalties are cumulative. The penalty for the route is stored in the BGP routing table until the penalty exceeds the suppress limit. At that point, the route state changes from history to damp.

•
Damp state—In this state, the route has flapped so often that the router will not advertise this route to BGP neighbors.

•
Suppress limit—A route is suppressed when its penalty exceeds this limit. The default value is 2000.

•
Half-life—Once the route has been assigned a penalty, the penalty is decreased by half after the half-life period (which is 15 minutes by default). The process of reducing the penalty happens every 5 seconds.

•
Reuse limit—As the penalty for a flapping route decreases and falls below this reuse limit, the route is unsuppressed. That is, the route is added back to the BGP table and once again used for forwarding. The default reuse limit is 750. The process of unsuppressing routes occurs at 10-second increments. Every 10 seconds, the router finds out which routes are now unsuppressed and advertises them to the world.

•
Maximum suppress limit—This value is the maximum amount of time a route can be suppressed. The default value is four times the half-life.

The routes external to an autonomous system learned via iBGP are not dampened. This policy prevent the iBGP peers from having a higher penalty for routes external to the autonomous system.
Friday, April 9, 2010
BGP Studies
Well I finally got through the "theory" portion of Internet Routing Architectures, and am going through chapter 11 which actually begins the configuration portion as it pertains to Cisco. I am doing the labs with Halabi as he explains them in the book. Lots of redistribution stuff at first, and a backdoor lab as well. I will note the backdoor lab here. Topology is as such:
So the key here is that RTC is going to get 2 different routes to the 192.68.10.0/24 network. The ospf connection is the more desirable one, check out the administrative distances:
BGP(external)-20
OSPF (internal)-110
So notice the route that shows up in the routing table:
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 172.16.220.0/24 [20/0] via 172.16.20.2, 00:24:31
C 172.16.20.0/24 is directly connected, Serial3/0
B 172.16.1.0/24 [20/0] via 172.16.20.2, 00:24:31
B 172.16.65.1/32 [20/65] via 172.16.20.2, 00:17:28
B 192.68.10.0/24 [20/0] via 172.16.20.2, 00:20:24
C 192.68.11.0/24 is directly connected, Loopback0
B 192.68.5.0/24 [20/20] via 172.16.20.2, 00:15:46
C 192.68.6.0/24 is directly connected, FastEthernet0/0
Its the less desirable BGP route. So how do you remedy this? Well, the easiest way is to simply use what is known as the BGP "backdoor." This command:
3640-RTC(config)#router bgp 1
3640-RTC(config-router)#network 192.68.10.0 backdoor
Now, its seems weird that you do this on RTC...but using this command does not advertise the network, it simply changes the AD of the BGP route to 200. If I were to sever the OSPF link, the bgp route would show back up...check it out.
3640-RTC(config)#int fa0/0
3640-RTC(config-if)#shut
02:32:50: %OSPF-5-ADJCHG: Process 2, Nbr 192.68.10.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
3640-RTC(config-if)#do show ip route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 172.16.220.0/24 [20/0] via 172.16.20.2, 00:45:13
C 172.16.20.0/24 is directly connected, Serial3/0
B 172.16.1.0/24 [20/0] via 172.16.20.2, 00:45:13
B 172.16.65.1/32 [20/65] via 172.16.20.2, 00:38:11
B 192.68.10.0/24 [200/0] via 172.16.20.2, 00:00:04
C 192.68.11.0/24 is directly connected, Loopback0
B 192.68.5.0/24 [20/20] via 172.16.20.2, 00:36:28
O 192.68.6.0/24 [110/1] via 192.68.6.2, 00:00:04, FastEthernet0/0
So that is how easy, and cool bgp backdoor is!
So the key here is that RTC is going to get 2 different routes to the 192.68.10.0/24 network. The ospf connection is the more desirable one, check out the administrative distances:
BGP(external)-20
OSPF (internal)-110
So notice the route that shows up in the routing table:
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 172.16.220.0/24 [20/0] via 172.16.20.2, 00:24:31
C 172.16.20.0/24 is directly connected, Serial3/0
B 172.16.1.0/24 [20/0] via 172.16.20.2, 00:24:31
B 172.16.65.1/32 [20/65] via 172.16.20.2, 00:17:28
B 192.68.10.0/24 [20/0] via 172.16.20.2, 00:20:24
C 192.68.11.0/24 is directly connected, Loopback0
B 192.68.5.0/24 [20/20] via 172.16.20.2, 00:15:46
C 192.68.6.0/24 is directly connected, FastEthernet0/0
Its the less desirable BGP route. So how do you remedy this? Well, the easiest way is to simply use what is known as the BGP "backdoor." This command:
3640-RTC(config)#router bgp 1
3640-RTC(config-router)#network 192.68.10.0 backdoor
Now, its seems weird that you do this on RTC...but using this command does not advertise the network, it simply changes the AD of the BGP route to 200. If I were to sever the OSPF link, the bgp route would show back up...check it out.
3640-RTC(config)#int fa0/0
3640-RTC(config-if)#shut
02:32:50: %OSPF-5-ADJCHG: Process 2, Nbr 192.68.10.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached
3640-RTC(config-if)#do show ip route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks
B 172.16.220.0/24 [20/0] via 172.16.20.2, 00:45:13
C 172.16.20.0/24 is directly connected, Serial3/0
B 172.16.1.0/24 [20/0] via 172.16.20.2, 00:45:13
B 172.16.65.1/32 [20/65] via 172.16.20.2, 00:38:11
B 192.68.10.0/24 [200/0] via 172.16.20.2, 00:00:04
C 192.68.11.0/24 is directly connected, Loopback0
B 192.68.5.0/24 [20/20] via 172.16.20.2, 00:36:28
O 192.68.6.0/24 [110/1] via 192.68.6.2, 00:00:04, FastEthernet0/0
So that is how easy, and cool bgp backdoor is!
Tuesday, March 30, 2010
BGP
So I am working on my BGP skills at the moment. This is going to be a fun exam I think, as the content is rich, and labbing will be plentiful. I still have a streaming subscription to CBTnuggets for a little while, so I breezed through the CCIE Certification Series BGP videos. Jeremy did a fantastic job on those, and I took pretty good notes throughout. I am going to continue on by reading a book that just arrived...Internet Routing Architectures. The first couple of chapters are a bit dry, but provide a good history in the internet, and ISP's in general. I will update you all as I go, but bid you farewell for now!
Subscribe to:
Posts (Atom)