How to track a learned default route

[Patrick Bixler]

I have 2 core routers, 2 data centers and each has an ISP.

R1 is a VSS pair of 6807s in our main data center and is advertising a static default route for our primary Internet connection.  This route is advertised via EIGRP to the rest of the network including the Colo.

R2 is a Nexus 7010 in the Colo receives the default route through EIGRP advertisements.  It is the core router for our Colo and will need to take over routing to ensure the Colo is survivable.  When doing a "show ip route" it shows the following learned default route which originates from the main data center.

0.0.0.0/0, ubest/mbest: 1/0

    *via 10.20.30.225, Vlan960, [170/259328], 1w3d, eigrp-CCHCS500, external

On R1, I am looking to implement and IP SLA and tracker that checks to see if main ISP router is reachable and if not, it will remove the static default route and will no longer advertise it in EIGRP.  This router is configured to redistribute static. That IP SLA and Tracker looks like this.

ip sla 1

icmp-echo 206.121.115.61 source-interface VLAN 105

track 1 ip sla 1 reachability

delay down 15 up 30

event manager applet Default_Route

event track 1 state down

action 010 syslog msg "AT&T Internet Down"

action 020 cli command "enable"

action 030 cli command "config t"

action 040 cli command "no ip route 0.0.0.0 0.0.0.0 10.10.105.10"

action 090 syslog msg "Failing over to Verizon Internet"

event manager applet Default_Route

event track 1 state up

action 010 syslog msg "AT&T Internet Up"

action 020 cli command "enable"

action 030 cli command "config t"

action 040 cli command "ip route 0.0.0.0 0.0.0.0 10.10.105.10"

action 090 syslog msg "Returned traffic to AT&T"

R2 needs to see that there has been an EIGRP change and the default route has been removed.  When it does, it will configure a new static default route and advertise that through EIGRP to the rest of the network.  There are several scenarios as to why the Colo will need to do this for survivability or to advertise back to the data center networks a path to the secondary Internet.  I have a partial script written, but need to fill in the blanks. This router is also configured to redistribute static, but it has no static routes until it configures one.

ip sla 1

  ?? How to check for no 0.0.0.0/0 route in EIGRP ??

track 1 ip sla 1 (?? What needs to go here for tracking ??)

delay down 15 up 30

event manager applet Default_Route

event track 1 state down

action 010 syslog msg "AT&T Internet Down"

action 020 cli command "enable"

action 030 cli command "config t"

action 040 cli command "ip route 0.0.0.0 0.0.0.0 10.200.25.6"

action 090 syslog msg "Failing over to Verizon Internet"

event manager applet Default_Route

event track 1 state up

action 010 syslog msg "AT&T Internet Up"

action 020 cli command "enable"

action 030 cli command "config t"

action 040 cli command "ip route 0.0.0.0 0.0.0.0 10.200.25.6"

action 090 syslog msg "Returned traffic to AT&T"

I know that I could do this by having both routers ping the next hop to AT&T to determine if it is down, but I really want R2 to rely on the decision of R1 to remove the default route before R2 inserts a new default route.  TAC is unable to provide assistance with IP SLA, Tracking and EEM scripting, per a TAC case that I currently have open.  Quote from TAC

"I also  understand the fact that the EEM and IP SLA solution was given by a previous TAC engineer but that support should go through the support community, can you try reaching support through that channel I can assure you  that if there’s a process  for EEM to accomplish what you required the answer will come from there."

[Mark Malone]

Hi

Cant see a way of using ip sla to track an exact default route like that without using next-hop but take a look at this it may be useful , instead of eem use a weighted default route that only comes into effect when you cant reach something upstream of the current default route , as your already redistributing static if the link fails to current ISP the weighted route becomes valid and gets put into the table it should be redistributed through EIGRP anyway to the colo giving R2  a new default route

https://supportforums.cisco.com/document/30296/using-ipsla-change-routing

[Peter Paluch]

Hi Mark,

Sorry to jump into your thread - I was slower in writing my response.

In any case, I was thinking about using object tracking on R2 to check on the route's metric which would obviously be different for a static and for an EIGRP-learned route, but NX-OS does not seem to support the track ip route metric threshold command so that approach was not an option.

Best regards,
Peter

[Mark Malone]

Not at all Peter the more options the better :) I feel the same way about TAC there , that's a paid service redirecting the customer to a free forum where they may or may not get someone to help, TAC are not in a position to be suggesting that.

[Peter Paluch]

Patrick,

I have to say that I am taken aback by the response from the TAC suggesting that you should be looking for EEM support here. While we are here to do everything we can to help you, it is unexpected for a payed support service to redirect you to a forum driven by volunteers.

In any case, I have been looking into the way you could accomplish what you need. I believe that the approach through EEM on the NX-OS is unnecessarily complicated. How about this?

• Have a static default route configured on R2 pointing to 10.200.25.6 with an administrative distance of 171 or higher (but less than 255).
• While R1 has a default route, it will redistribute it into EIGRP and it will be learned on R2 with an AD of 170, causing it to be preferred to the locally configured static route.
• When R1 stops advertising the default route, the static route on R2 will take over with its AD of 171.
• When R1 starts advertising the default route again, its default route will again be more preferred on R2 thanks to its AD of 170.

The trick is to keep the AD of the static default route on R1 at its default value of 1 but keep it above 170 on R2.

Would this work for you?

Best regards,
Peter

[Patrick Bixler]

I was in the process of replying to Mark when this came in and was on the same train of thought.

The example provided in the link in Mark's reply assumes that the logic is all on 1 router and I am assuming RTR-1.  If RTR-1 becomes unavailable, then RTR-2 will not learn a new default route from RTR-1 and will be pretty much dead in the water.  That is a scenario I am trying to avoid as this deals with a Data Center and a Colo with traffic between then and a different ISP at each location.  I don't want my Colo to be without a default route if it cannot communicate with the main data center.

I was also thinking about a more heavily weighted static route on the Nexus router.  The issue I have with that is route flapping.  I implemented EIGRP at our Colo just 2 weekends ago and in the process of doing that I saw several times where EIGRP updates for routes were still processing in other parts of my network and Colo was seeing a lot of poisoned routes.  This is the main reason why I wanted to use the tracking to suppress the update of a new default route after a certain amount of time.  15 seconds may be a bit long, but immediately too short.  This is closer to what I am looking for.

[Patrick Bixler]

I think I might have figured this out, but I am not sure if the commands will work on the 7k.  Nothing changes for the EEM on R1.  It will do what it needs to do in the case of losing or regaining the primary Internet.  I do, however, need a defined route for getting to the ATT router that remains in place during the default route changes.  This may be the script I add to R2 (Nexus 7k)

ip sla 1
 icmp-echo 206.121.115.61 source-interface VLAN 960

track 1 ip route 0.0.0.0/0 reachability
track 2 ip sla 1 reachability
track 10 list boolean and
  object 1
  object 2

event manager applet Default_Route
 event track 10 state down
 action 010 syslog msg "AT&T Internet Down"
 action 020 cli command "enable"
 action 030 cli command "config t"
 action 040 cli command "ip route 0.0.0.0 0.0.0.0 10.200.25.6"

 action 090 syslog msg "Failed over to Verizon"

event manager applet Default_Route
 event track 10 state up
 action 010 syslog msg "AT&T Internet Up"
 action 020 cli command "enable"
 action 030 cli command "config t"
 action 040 cli command "ip route 0.0.0.0 0.0.0.0 10.200.25.6"
 action 090 syslog msg "Returned traffic to AT&T"

Track 1 checks to see if there is a default route in the routing table.  If R1 removes the advertised default static route from its config, then that route should disappear from the 7k's routing table.  Track 2 is to verify that the ATT link is down by using an IP SLA check, which is the same as the one on R1.  This is also why I need to have that ATT route in place all the time.  If both Track 1 and Track 2 switch to down, then Track 10 will also switch to down and trigger the EEM script to write the new default route on the 7k and advertise it out.  This will change my default route for my entire network and send all unknown traffic out the Verizon Internet. 

If the default route comes back from R1, but ATT is still down, there is no up trigger.  If ATT is up then R1 should advertise the default route and in which case both Track 1 and Track 2 will show up, so Track 10 changes to up and then R2 removes the default route and the route advertised by R1 becomes the new default route. 

[Patrick Bixler]

Cisco TAC has drawn the line between support for IP SLA and EEM.  I am now trying to determine their support for the TRACK command.  I found the following document on Enhanced Object Tracking.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp/configuration/15-mt/iap-15-mt-book/iap-eot.html

There is a section on IP-Route Reachability, that looks like it may be tracking a subnet in the route table. The document's example is this.

Device(config)# track 100 ip route 10.2.2.0/24 reachability 

I could modify that to look for the default route in the route table like this.

track 1 ip route 0.0.0.0/0 reachability

If my R1 removes its static default route that would trigger the removal of the 0.0.0.0/0 route in the R2 (Nexus route table).  That may cause the EEM to trigger and for the Nexus to add its static default route to its configuration and then advertise the new default route.

I think where this will break is that currently the static default route is learned externally while the new default route would be local.  This may show up at 0.0.0.0/0 in the new route table on the Nexus, which may then trigger an up and it will remove the static default route and go into a flapping situation.

It looks like I may have to try a Boolean Expression to track more than just the route in the route table.  Maybe this is both an IP SLA ping and the removal of the learned default route to trigger the EEM.