Testing SLA with BGP peering

[John Blakley]

All,

I have an ethernet circuit that we brought up this morning to test. We did a failover test with me shutting the interface down, and while this work it's not a real world test. BGP took a while to converge. (Timers are set to 7 and 21.) Basically, we have the following:

Provider

   |

Switch

        |

     My router

If the circuit goes down, I can't track it by line-protocol because the router will think it's up if the switch is fine. I created an SLA that pings the provider, but I found that this is extremely difficult to simulate a failure with. Is it even possible? I tried to create a loopback and create an sla to ping that. I shut the loopback down, and using tracking failed over to the other router. That part worked, but because the provider was still up, my bgp peering obviously never went away. My traffic was going into the primary site even though the primary site was now the standby for hsrp. I tried conditional advertisement based on the loopback interface (lo15) being in the routing table, and then if it wasn't, I wanted to stop advertising the subnet that I was trying to get to. Well, this didn't work at all. The subnet from lo15 wasn't in the table, but I was still advertising it. That's going to be something I'll need to look at later. Anyway, is there a way to simulate an sla failure and have the 2 routers fail over without getting the provider involved? My next step is to get in touch with the provider and just have them shut their interface to me to see if failover happens fairly quickly.

Thanks!

John

[Vasileios Bouloukos MSc, ITIL, CCIE]

Hi John,

Maybe the next link can help you to simulate an sla failure and to have the 2 routers to failover without getting the provider involved

http://blog.ioshints.info/2011/09/shut-down-bgp-session-based-on-tracked.html

but the track command you can use an sla instead of of monitoring the status of the interface.

Regards,

Vasilis

[John Blakley]

Vasilis,

Thanks for the response. I labbed this up, but I don't see a difference with it vs. leaving the standard fast-external-fallover feature enabled unfortunately. From what I see it doesn't do anything different from tracking an sla using hsrp and then moving from active to standby when that sla is triggered.

Thanks!

John

[John Blakley]

I had the provider shut their port down towards me and failover happened within about 5 packets. Traffic kept flowing seamlessly to the user, so I don't think anything else on this side needs to be done

[Vasileios Bouloukos MSc, ITIL, CCIE]

Hi John,

I have a comment that could not appear in your lab.

According to the network topology described in your initial post, the router is connected to a switch.

So, if the link between the switch and the ISP router fails, the fast external fallover to your router will not "react".

Maybe, in the lab you  shut down the interface and the f external fall over worked. This is one reason that I would recommended the track with sla.

Finally, I believe that if you configure the suggested BGP-config you could achieve faster convergence since in case of a failure the BGP shuts and send a direct TCP reset message to the BGP peering.

Regards,

Vasilis