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"
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
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).
!
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
!
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.
IP SLA can be used to test the availability of the backbone via a point-to-point link for example.
Another example:
You have 2 routers (using HSRP on the LAN side) at a customer where you have to use NAT to expose this one toward your datacenter. To manage the WAN redundance, you're using BGP.
To redistribute the IP pool used by NAT, you need to define a static route redistributed into BGP. If the LAN on the primary router is not available, this router still advertises the static route through BGP. Therefore, the return trafic will drop.
In using IP SLA, you can test the availability of the LAN and in the case where this one is not available you remove the static route. In addition, you also can test the WAN point-to-point link (in case of ethernet WAN solution, you can have the interface UP/UP but not trafic forwarded), if it's not operational you can decrease the priority of HSRP.
I'm using this kind of solution. But indeed I don't test any ressources outside my network.
Regards,
Lionel
we have come up with following solution:
1) set an static default-route
ip route 0.0.0.0 0.0.0.0 track 1000
2) creating tracks:
track 991 ip route 17.0.0.0 255.0.0.0 metric threshold
threshold metric up 1 down 2
!
track 992 ip route 18.0.0.0 255.0.0.0 metric threshold
threshold metric up 1 down 2
!
track 993 ip route 32.0.0.0 255.0.0.0 metric threshold
threshold metric up 1 down 2
!
track 994 ip route 55.0.0.0 255.0.0.0 metric threshold
threshold metric up 1 down 2
!
track 1000 list boolean or
object 991
object 992
object 993
object 994
3) set metric value for iBGP:
address-family ipv4
neighbor route-map TO-IBGP out
route-map TO-IBGP permit 65535
set metric 5120
Do we overlook something?
Greets,
Flo