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"

7 comments:

  1. 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
  2. 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).
  3. 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
    !
  4. The Small Site Multi-Homing article I wrote a while ago contains a tested configuration in the "End-to-end connectivity test" section.
  5. 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.
  6. I'm not agree with your last sentence (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
  7. Hi,
    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
Add comment
Sidebar