Configure the default route based on the presence of a BGP session
You've probably already heard the phrase "When the only tool you have is a hammer, everything looks like a nail" (and seen people acting according to it). Likewise, if you have an IOS release with EEM support, a lot of things that would require smart design could be solved in a brute-force way with a few EEM applets. For example, the problem of the BGP default route could be solved “easily” with a few applets that track syslog messages reporting when the BGP neighbors go up/down.I've set up the following scenario:
- My router has two BGP neighbors: 10.0.7.2 and 10.0.7.6;
- Internet access through10.0.7.2 is the primary path;
- The default route through 10.0.7.6 should be used as a backup only.
The solution shown below is probably a bit over-engineered, as it would be sufficient to track solely the availability of the primary BGP peer and insert/remove the primary static default route (leaving the floating one intact) … or you could use yet another floating default route as the backup-of-last-resort. It's important, though, that you remove the default routes when the router is restarted, as there will be no BGP-related syslog messages if the BGP neighbor is not available after the reload.
event manager applet BGP_A_Up
event syslog pattern "BGP-5-ADJCHANGE.*10.0.7.2 Up"
action 1.0 cli command "enable"
action 1.1 cli command "configure terminal"
action 1.2 cli command "ip route 0.0.0.0 0.0.0.0 10.0.7.2"
action 2.0 syslog msg "Primary BGP peer available"
event manager applet BGP_A_Down
event syslog pattern "BGP-5-ADJCHANGE.*10.0.7.2 Down"
action 1.0 cli command "enable"
action 1.1 cli command "configure terminal"
action 1.2 cli command "no ip route 0.0.0.0 0.0.0.0 10.0.7.2"
action 2.0 syslog msg "Primary BGP peer lost"
event manager applet BGP_B_Up
event syslog occurs 1 pattern "BGP-5-ADJCHANGE.*10.0.7.6 Up" period 20
action 1.0 cli command "enable"
action 1.1 cli command "configure terminal"
action 1.2 cli command "ip route 0.0.0.0 0.0.0.0 10.0.7.6 250"
action 2.0 syslog msg "Alternate BGP peer available"
event manager applet BGP_B_Down
event syslog pattern "BGP-5-ADJCHANGE.*10.0.7.6 Down"
action 1.0 cli command "enable"
action 1.1 cli command "configure terminal"
action 1.2 cli command "no ip route 0.0.0.0 0.0.0.0 10.0.7.6 250"
action 2.0 syslog msg "Alternate BGP peer lost"
event manager applet BGP_Restart
event syslog pattern "SYS-5-RESTART"
action 1.0 cli command "enable"
action 1.1 cli command "configure terminal"
action 1.2 cli command "no ip route 0.0.0.0 0.0.0.0 10.0.7.2"
action 1.3 cli command "no ip route 0.0.0.0 0.0.0.0 10.0.7.6 250"
action 2.0 syslog msg "Default routes removed following the system restart"
Posts
5 comments:
A elegant way of doing it is by tracking objects and SLA monitor. No eem is involved.
1) create a track object call trackrouteA which has reachability monitoring via SLA
2) Schedule the track object to run forever
3) Then add track objects to the static routes
ip route 0.0.0.0 0.0.0.0 10.0.7.2 trackrouteA
ip route 0.0.0.0 0.0.0.0 10.0.7.6 250 trackrouteB
You're absolutely correct and I've already covered a number of designs using this technique (including a SOHO multihoming).
But you cannot check whether the BGP session with the ISP is alive with SLA (assuming you want to use that as the trigger to install the default route).
After your article, I've just played a bit with reliable static routing with object tracking. Based on Cisco's recommendation, the following configuration should be applied to prevent pinging via the secondary link, but it breaks the operation of tracking. Am I missing something?
!
ip sla monitor 1
type echo protocol ipIcmpEcho 2.2.2.2
timeout 1000
threshold 2
frequency 3
ip sla monitor schedule 1 life forever start-time now
!
track 222 rtr 1 reachability
delay down 2 up 2
!
ip local policy route-map TRACK
ip route 0.0.0.0 0.0.0.0 FastEthernet0/0 track 222
ip route 0.0.0.0 0.0.0.0 FastEthernet0/1 100
!
access-list 101 permit icmp any host 2.2.2.2 echo
!
route-map TRACK permit 10
match ip address 101
set interface FastEthernet0/0 Null0
!
The Small Site Multi-Homing article I wrote a while ago contains a tested configuration in the "End-to-end connectivity test" section.
The problem with SLA tracking is what you actually track. In networks with redundant data paths for high avaialbility, which device / link / interface are you tracking.
Commonly people track www.google.com, but what if they stop allowing ICMP, or go offline, do you really want to failover everything just because of that.
SLA works for small networks, but no so well for large networks.
This blog is using JS-Kit comments. You have to enable JavaScript if you want to post a comment.