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.

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:

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

EtherChannel Mishaps

So we implemented Cisco's Virtual Switching System at work this week, and almost flawlessly I might add.  We ran into a small mishap on our final 2 switches while configuring the multi-chassis etherchannels.  Now we configured the channels correctly, but there was one statement that bit us:
switchport trunk allowed vlan [list]
This, on the server distribution switches, was different on the physical interfaces.  One of the physical interfaces had one more vlan in the list than the other.  Now, the channel came up, and looked good on the core end, and on the server distribution switch end...except that the port with the most vlans in the allowed list was suspended from the port channel (its actual state was up/down).  We began having intermittent connectivity problems to some of our servers.  Weird.  Upon investigation I found that suspended port on the server switches.  First I noticed the up/down state in a show ip int b; then the suspended port in a show interface status.  A quick look at the log showed the problem (different vlan/mask).  I quickly added the vlan manually to the port-channel interface and the physical interface came up, and began operations in the channel-group once again.  After a quick bit of labbing I confirmed the problem.  The intermittent connectivity was indeed because of the load-balancing algorithm, and etherchanneling protocol in use.  We were using src-dst-ip load balancing on both ends.  Because we used channel-group mode on, as our statement, the core end of the channel saw the suspended port as still in the channel (had we used PaGP we would not have had the problem).  Because it was still in the channel, the XOR calculation was still using the port index as a transmit link.  So when the XOR hit...the link was used to transmit packets.  When packets chased down the link, they were silently discarded by the suspended port.  Funny how things work!  Luckily, we were able to quickly identify the problem, and resolve it.  TAC confirmed our suspicions. 

XOR with 2 links...

gig0/1 -- index 0
gig0/2 -- index 1

Use the last bit of the IP address for XOR calculations (2^1 give you 2)

192.168.100.1 --> 192.168.100.2
1 in binary 00000001
2 in binary 00000010

XOR 1 and 0 = 1 (Use link gig0/2)

XOR breakdown
0 and 0 = 0
0 and 1 = 1
1 and 0 = 1
1 and 1 = 0

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!