Brief HSRP question

The switch didnt refresh it mac-address-table fast enough or probably counted that as an error (there r port -security settings in cisco switches, make sure they r not turned on)

As far as I can tell, the port security settings on the Catalyst were turned off. As for the timing of the refresh of the MAC address table, it appeared as if the switch couldn't/wouldn't resolve the virtual MAC of the virtual IP shared between the two routers (debug output showed something along the lines of "incomplete ARP entry for W.X.Y.Z", even though the gratituous ARP messages were being received by the switch--also shown in debug output). Note that the real MAC addresses of each router were properly listed.

can u send the config once ???

is spanning tree configured? the type of spanning-tree port mayb an issue

I'll try to post a sanitized copy of the interface configs (where HSRP is configured) later today.

I considered that as well, so I configured the ports on the Catalyst where the routers connect to use portfast and set them as access ports only. That didn't seem to help at all.

Here's a sanitized copy of the config.

First, the primary router (Cisco 2800 series):

interface FastEthernet0/0 description LAN IP address ip address 172.16.1.253 255.255.255.0 standby ip 172.16.1.1 standby priority 105 standby preempt standby track serial0/0 standby use-bia

Then, the secondary router (Cisco 871):

interface Vlan1 description LAN IP address ip address 172.16.1.252 255.255.255.0 ip virtual-reassembly ip tcp adjust-mss 1452 standby ip 172.16.1.1 standby preempt standby track Tunnel0 standby use-bia

Tunnel0 is a GRE/IPSec tunnel to another location. Both of these interfaces connect to the same Catalyst 3750 switch.

This configuration works, but only because I had the "standby use-bia" command; it did not work without that command. I'm very curious to know why, so that I can try to avoid problems in the future.

Please POST IOS releases being used on each router

"standby preempt" should only be on the primary router.

BernieM

Could be CSCin32819

CSCin32819 Bug Details

Headline Address resolution fails for standby IP address Product IOS Feature OTHERS Components Duplicate of Severity 3 Severity help Status Resolved Status help First Found-in Version 12.3, 12.2(14.5)T All affected versions First Fixed-in Version 12.3(1.3), 12.3(1.2)T, 12.3(2.3)B Version help

Release Notes

Release Note: =============

Symptom:

The Address resolution of Virtual IP address (standby) is failing with the setup in which, the router with Virtual IP interface was unable to send ARP packets to its peer.

Conditions:

The router in which an interface is being configured with standby IP address and the peer connecting to it cannot identify the interface with Virtual IP address but with the interface main IP address

Workaround: The quick workaround is to configure the additional standby command:

standby use-bia

Further Problem Description:

This DDTS is not found in 12.2(12.9)T but in the 12.2(14.5)T

Feedback

Please rate this release note:

Select OneExcellentGoodAverageFairPoor

If you gave this release note a low rating, please tell us why.

Ignore my post about standby-preempt only being on the primary router ... what i said was incorrect.

BernieM

Actually Bernie, you're right.

You only need to have preempt in there for a higher priority node to take over the standby ip. This usually goes on the interface with the highest priority, there is no need for it on the other.

As for the issue with hsrp here, I was under the impression that when a new interface takes over that a gratuitus arp is sent out. So it does sound a bit like a bug to me.

Have you upgraded to the latest version of ios in your train?

LH CCIE#15331

BernieM wrote:

Negative, Bernie was right when he corrected himself. If you do not have the preempt command in there the standby router will never take over regardless of the status of the primary or it's priority. This is quite different than how it USED to be, pre 12.1 code the preempt used to tell the router with the highest priority to take back over control, now it is used for either router to take control, higher priority always wins. This is well documented all over CCO, simple search for HSRP configuration will bring it up. I agree with you on the bug, gotta be, unless the switch config it's patched to is messed up. Personally I never use the default group either. I usually use the group number of the subnet it's on, prevents any confusion or group overlaps.

-Brian

Hey there Brian,

You're right, but not 100% right.

The changes bought about in 12.1 were to do with object tracking and some other clever bits along that line. When you not tracking an interface and you've got hsrp on in case the router/switch falls over, then there is no need for preempt. Preempt is all to do with priority levels and the decrementing of that number.

But to give you your credit, I'd probably excpect to not see a config without the preepmt command in there.

LH CCIE#15331

Brian V wrote:

Heya Leigh,

When not tracking an interface you are 100% right, if you are simply doing hardware failure, then there is technically no need for the preempt shy of it being Cisco's recomended way of doing it now. If the router with the higher priority fails the standby will kick in once the heartbeat is missed, once the heartbeat comes back the one with the higher priority if it had preempt would come back. I just lab'd it and without a question works fine for hardware failure.

r2#sho stand Ethernet0 - Group 2 Local state is Standby, priority 100 Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.444 Virtual IP address is 10.10.108.7 configured Active router is 10.10.108.5, priority 105 expires in 9.292 Standby router is local 4 state changes, last state change 00:00:34 IP redundancy name is "hsrp-Et0-2" (default) r2#

*Mar 1 00:17:31.731 UTC: %STANDBY-6-STATECHANGE: Ethernet0 Group 2 state Standby -> Active r2#sho stand Ethernet0 - Group 2 Local state is Active, priority 100 Hellotime 3 sec, holdtime 10 sec Next hello sent in 0.680 Virtual IP address is 10.10.108.7 configured Active router is local Standby router is unknown Virtual mac address is 0000.0c07.ac02 5 state changes, last state change 00:00:05 IP redundancy name is "hsrp-Et0-2" (default) r2# *Mar 1 00:18:03.987 UTC: %STANDBY-6-STATECHANGE: Ethernet0 Group 2 state Active -> Speak r2#sho stand Ethernet0 - Group 2 Local state is Standby, priority 100 Hellotime 3 sec, holdtime 10 sec Next hello sent in 2.274 Virtual IP address is 10.10.108.7 configured Active router is 10.10.108.5, priority 105 expires in 8.332 Standby router is local 7 state changes, last state change 00:00:00 IP redundancy name is "hsrp-Et0-2" (default)

On a standard router setup tracking should always be used as that what sets the decrement for the priority, it's 10 per interface being tracked. As far as the OP's problem, the HSRP config is correct, it is most likely a switch issue not flushing it's table to the gratuitus arp. One big thing that backs that up is the fact when he used the bia it worked fine.

-Brian

I can only provide the major version at this time--12.3. It will be a short while before I am back on-site again and can get the exact release number.

We have not upgraded to the latest IOS version, as we were able to make the configuration work with "standby use-bia" in the configuration.

Using "debug ip icmp" on the switch console, we could see the gratuitous ARP being received by the switch for the virtual IP, but it still didn't work. Bsaed on Merv's post earlier in the thread, it does indeed look like a bug--CSCin32819--as the behavior matches and we are using an affected version.