My company has a customer that has a Cisco 1721 and Cisco 1841. The 1841 is connected to Road Runner cable and the 1721 is connected to Verizon DSL. The 1721 connected to Verizon is strictly backup for the RR cable, which goes down occassionally.
Originally, the network was configured for dead gateway detection. The customer has several VPN's that don't work right when the line goes down using this method. A few of the servers that are setup with static NAT configurations through the 1841 router can't use the failover with the dead gateway detection. Consequently, HSRP was configured on the two routers.
Everything works great when you pull a cable out of the WAN port. However, when RR goes down, the port remains up foiling the failover.
Is there some way to have the routers detect that there is no WAN connectivity on the other side of the modem, so the WAN port goes administratively down? Actually, is there any way, given the circumstances, to make the failover happen when RR goes down but the modem keeps the WAN port up?
You can configure HSRP to calculate the interface priority based on whether another interface is up or not. You can configure it to decrement the priority when the tracked interface goes down. The idea is to have the interface priority drop below the priority of the 'other' routers' HSRP interface, making that one active.
I believe in 12.4 this has been extended to include "objects" that can be interfaces or other things. I haven't toyed with non-interface tracking.
Thank you for your input, Adrian. You are referring to interface tracking, which is setup on both routers in question to track the WAN interface port. As I mentioned in my initial post, it works great when you pull the cable out of the WAN port. However, when the Internet service from Road Runner goes down, the WAN port stays up because it is connected to the cable modem. The cable modem is still active and keeps the WAN port active even though there is no incoming cable signal and consequently, no connection to the Internet.
As you have mentioned there is an issue in the standard implementation of HSRP which is that the tracking feature looks for changes in interface state (looks for change from line protocol up to line protocol down). But there are situations like you describe where the connection is over Ethernet and you may have lost connectivity but the interface remains line protocol up and HSRP does not fail over.
Cisco has addressed that issue and has introduced a new feature called enhanced object tracking. This link:
gives a good description of this new feature. While it is not written for the specific platform that you are running I think it will give you the information that you need to get you going with enhanced object tracking for HSRP and will result in HSRP failing over when you lose connectivity on the RR link.
While I am confident that this will get past the issue where HSRP does not fail over, I do not know enough about your situation to say whether it will address all of your issues. In particular I believe that the static NAT will still be problematic. And the VPNs with dead peer detection may also have issues.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...