04-08-2014 02:04 PM
Hi,
I'm relatively new to the IP SLA procedure and very new to EEM. I'm searching for the most efficient way to monitor the availability (packet loss and latency) of a BGP neighbor from a router to actively shutdown the neighbor relationship in order to failover to a back up L2L VPN I have configured on an ASA. It's important that I'm able to continue monitoring the BGP neighbor so that when the neighbor becomes stable again, I can reenable the BGP neighbor relationship. I've put something quick together (below) but am not sure if it will do what I want. I'd appreciate any suggestions and feedback.
Thank you!
-Mike
ip sla 90
icmp-echo <neighbor_ip> source-ip <source_ip>
threshold 250
timeout 500
frequency 3
ip sla schedule 90 life forever start-time now
ip sla enable reaction-alerts
!
track 90 ip sla 90 reachability
delay down 3 up 180
!
!
!
event manager applet BGP_NEIGHBOR_DIRTY
description SHUT DOWN BGP NEIGHBOR IF RTT OVER 250 FOR 3 SECONDS
event syslog pattern "90 ip sla 90 reachability Up->Down"
action 1.0 cli command "enable"
action 1.1 cli command "configure term"
action 1.2 cli command "router bgp 63320"
action 1.3 cli command "neighbor <neighbor_ip> shutdown"
action 1.4 cli command "end"
event manager applet BGP_NEIGHBOR_CLEAN
description ENABLE BGP NEIGHBOR IF RTT UNDER 250 FOR 3 MINUTES
event syslog pattern "90 ip sla 90 reachability Down->Up"
action 1.0 cli command "enable"
action 1.1 cli command "configure term"
action 1.2 cli command "router bgp 63320"
action 1.3 cli command "no neighbor <neighbor_ip> shutdown"
action 1.4 cli command "end"
!
04-08-2014 10:18 PM
This should do what you want.
04-09-2014 05:41 AM
Thanks for the confirmation, Joseph. I have a maintenance window for testing scheduled for Friday night. I'll post the results once testing is complete.
Thanks again,
Mike
06-18-2014 09:51 AM
Did this work? I'd like to implement this same solution but wanted to see if it worked for you like you posted it or if you needed to make any changes
Erik
06-18-2014 11:24 AM
Hi Eric,
It did work just as expected. The problem we had with it after testing is that it works just fine if the latency or outage exists between this device and its next hop neighbor. But if the problem is between this device and some other device beyond the neighbor, the configured IP SLA is never triggered and the backup VPN route never comes into play. If you find a workaround, please post it.
Thanks,
-Mike
06-18-2014 11:27 AM
I meant to open this up to Joseph Clarke as well. Looking through this forum, it seems he's the go to guy for the more complex EEM scripting questions!
-Mike
06-18-2014 11:32 AM
Understood on the limitations of this. Even with that limitation it will solve 95% of my MPLS BGP outages and bring the reroute times down to a level where the end users won't even notice.
06-18-2014 11:34 AM
Great. Hope it helps you out.
06-18-2014 12:50 PM
All you would need to do is change the target IP in the IP SLA collector to be some remote device instead of the neighbor IP. You could pick something like 8.8.8.8 for Google, for example.
06-20-2014 06:52 AM
By chosing a target that is along your desired path, you can certainly have a more robust script. I would use loopback to loopback communication as well, this will force the traffic through the router, and also find any potential issues where the peer is alive and sending bgp but not actually passing traffic. You will definitely need some "fudge" factors in there to deal with routers have to process the ICMP packets (Any CoPP will really really skew the results you are getting). I have had experiences where testing to/from a Nexus device gives wildly different results vs testing through the boxes.
HTH
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide