how to track the next hop of a route ?

[gnijs]

Hello,

I want to track the next hop of a default route.

For example: I have a router with two interfaces, and i can receive the default route via BGP via any of the two interfaces.

I want a tracking object that:

  is UP when the default route with next hop 1.1.1.1 is present (show ip route 0.0.0.0 0.0.0.0 , next hop is 1.1.1.1)

  is DOWN when the default route is not present or when it is present with any other next hop address (for example 2.2.2.2)

Can this be done (on ASR1001 platform, IOS XE) ?

regards,

Geert

[Francesco Molino]

Hi

You want to track an ip but what do you want to do with it? If the tracking is up or down what action you want to execute?

[gnijs]

The track object will be used to change HSRP priorities of downstream interfaces.

[e.ciollaro]

I add another two questions:

1. is it possible that the default route is in routing table with next.hop 2.2.2.2 but 1.1.1.1 is reachable ?
2. If yes, it could be reachable via both interface or just from  the interface used when the default has 1.1.1.1 as next-hop ? 

Bye,

enrico.

[gnijs]

Both next hops can indeed be reachable (while not receiving any route). The default route received on the BGP sessions comes from multiple hops away.

I need to determine from where it comes. Now, i was thinking about the route metric (there is something like route metric tracking). The BGP AS path is different for both routes. But the standard BGP "metric" is the same. A default is selected by BGP using Local Preference. But for the downstream HSRP priorities, i need to be able to determine from where the default comes (i have two upstream interfaces).

[Georg Pauwen]

Hello,

if you have both IP addresses (next hops that you want to track) you can implement an EEM script that changes the priority of your HSRP, depending on the reachability of each hop.

Post the config of your router and indicate the IP addresses which need to be tracked...

[gnijs]

Both next hops are always reachable. That doesn't show me to where the default route points that eventually makes it to the routing table. So both ip sla or ping tracking of the next hop isn't relevant.

I am now looking at an EEM script example of Joe Clarke that looks promising.

Here it seems you can explicitly check for the $_routing_lastgateway of a route. I am going to lab this up.

event manager applet link-check

event routing network 0.0.0.0/0 type modify

action 1.0 syslog msg "Route changed to $_routing_lastgateway"

action 2.0 snmp-trap strdata "Route changed to $_routing_lastgateway"

[Georg Pauwen]

Hello,

you don't necessarily need to track the next hop, you can also track e.g. 8.8.8.8, and specify the source interface of your outgoing connection...

Either way, curious to know if you get that script to work the way you want...

[gnijs]

ha Georg, that might also be good alternative.

I have found that the following EEM script also runs fine in lab tests:

event manager applet check-default
event routing network 0.0.0.0/0 type modify
action 1.0 syslog msg "Default route changed to $_routing_lastgateway"
action 2.0 if $_routing_lastgateway eq "2.2.2.2"
action 3.0 cli command "enable"
action 3.1 cli command "conf t"
action 3.2 cli command "interface Fa0/0"
action 3.3 cli command "standby 80 prio 50"
action 4.0 elseif $_routing_lastgateway eq "1.1.1.1"
action 5.0 cli command "enable"
action 5.1 cli command "conf t"
action 5.2 cli command "interface Fa0/0"
action 5.3 cli command "standby 80 prio 150"
action 6.0 end

1.1.1.1 is the next hop of the local ISP router (ebgp)

2.2.2.2 is the next hop of the iBGP session to the backup router/link (ibgp)

Principle is easy: if the default points to the locally connected ISP, match the downstream HSRP as primary (attract traffic)

if the default is routed to the backup link (ibgp, remote ISP, non-local-link), lower the downstream HSRP priority.

[e.ciollaro]

Hi,

just an idea (alternative to EEM): I guess the two routers have an iBGP session between them and an eBGP session used to receive the default route. If so why not filter the default over the iBGP session so that the only way to reach remote ip is the default received over the eBGP session ? It is enough to track a remote ip and decrement HSRP priority if not reacheble. Could it be ?

Bye,

e

[gnijs]

yes, in fact i am using already iBGP session between the routers + tracking of physical interface state to lower HSRP priority on the inside. This works great (standard design) both for physical line failure and logical line failure (ie bgp down, or 0.0.0.0/0 removed).
However, in case of logical failure (bgp down, interface up), it leads to assymetric routing (outbound to router A, from router A to router B, exit internet B, inbound traffic B, to router B, -but- since router B has local interface into fw vlan, it will route directly and not back across the iBGP link to router A). It is not a critical situation, it should work, however, using EEM scripting i wanted to catch this situation and increase routers B HSRP priority to remove the assymetry in this case. I agree, a lot of work for a situation that will not happen all that often :-)

[e.ciollaro]

Hi,

but assymetric routing is due to the fact that A still has a default router (that forward traffic to B); what I suggest is to filter on router A the default router received over the iBGP session; this way A can't track a remote public IP (no default to route traffic) so it decrement  HSRP priority, B becomes active and traffic flow throug it.

Bye

enrico.