HSRP alternative

[daniel.kline]

I have a configuration where I am doing BGP peering two different service providers and using HSRP to control outbound failover. One of the service providers (SAVVIS) recently installed two additional T1 interfaces into my router that connects me to them. Instead of providing me three serial interfaces, they installed an Integrated Edge Device (IED) - essentially a router thaat multilinks the three serial circuits. From the IED they provide me an Ethernet connection. I use this as my primary route out to the Internet.

Well, if I track the Ethernet interface on my router that connects to their IED and the circuit fails, which it has already, HSRP does not failover because the Ethernet interface doesn't drop.

Does anybody know of an alternative way to accomplish this without using the track interface command in HSRP?

I had looked at the commands for "Tracking IP-Route Reachability " on Cisco's website for Enhanced Object Tracking: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/fthsrptk.htm#wp1040072, but I'm not quite sure how that works.

Regards,

Dan

[olorunloba]

You are along the right path. The problem with normal HSRP like you have noticed is that it tracks the ethernet interface which does not go down during link failures. By using enhanced object tracking, you can track more advanced things. A good one, and very applicable to you is SAA tracking.

By using SAA probes, you can configure the router to probe a particular IP address with ICMP packets for example. A tracked object can be declared against this probe such that the tracked object is up when there are ICMP replies and the tracked object is down when there are no ICMP replies. The status of the link can therefore be reliably determined.

Check the following link for further examples and explanation.

http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps5207/products_feature_guide09186a00801d2d74.html

[daniel.kline]

Thank you. I think that may solve my issue. I assume the following rtr commands must also be applied:

rtr 1

type echo protocol ipIcmpEcho

timeout 1000

frequency 3

threshold 2

request-data-size 1400

rtr sched 1 start-time now life forever

!

track 2 rtr 1 state

track 3 rtr 1 reachability

!

interface e0/1

ip address 10.21.0.4 255.255.0.0

no shutdown

standby 3 ip 10.21.0.10

standby 3 priority 120

standby 3 preempt

standby 3 track 2 decrement 10

standby 3 track 3 decrement 10

Will this configuration fail back when the tracked ojbect becomes available again?

I'm assuming that's what the "delay up seconds down seconds" command does. This allows you to wait a certain amount of time after the object becomes reachable or unreachable before, in this case, promoting or demoting the primary router.

Regards,

Dan

[olorunloba]

Yeah, it should fail back.

Another thing to note, is that depending on the ip address of the tracked object and your routing configuration, you might want to configure local policy based routing to force the locally generated packets out through an interface. The idea is that when there is a failed link, the routing protocol could reconverge, such that the tracked object is now reachable via another route.

[daniel.kline]

It appears as though the rtr command is only available with certain IOS feature sets.

But I was able to use the track 10 ip route A.B.C.D/30 command, which I believe will accomplish the same thing. I then added "standby 2 track 10 decrement 10" to my HSRP interface configuration. This should cause HSRP to decrement the router priority by 10, forcing it to become the standby router. When the tracked object becomes reachable again, the router priority should be incremented by 10, causing it to become the primary router again.

Am I understanding this correctly?

[olorunloba]

Yeah, the logic is right. Also, not IOS support the rtr feature.

You need to be careful though on which route you are tracking. The route will need to disappear during the link failure. For instance, it might not make sense to track the connected route of the ethernet interface since that route will always be in the routing table. Realising that you are running BGP, you could track a route that is only learnt via that BGP connection.

Hope this helps