HSRP Standby switch can't ping HSRP Virtual IP

[Pavithran Nair]

Hi guys, I've encountered a perplexing problem in PT6.0 that I've been trying to solve but I just can't crack it.

I have a simple set up involving 2 units of 3560 multi layer switches connected to each other via a single trunk connection with all VLANs allowed. I then configured a new VLAN and a VLAN switch virtual interface on both the switches set with IPs. I tested pings between the switches and it worked. Great!

I then went back to the Switch Virtual Interface on each switch and applied HSRP configurations along with priorities and preemption on one of the switches. I checked the HSRP (show standby) and it looked great - both switches settled into their Active & Standby roles as I intended and could "see" the standby Virtual IP.

Here's where the problem starts... I tested the pings from switches. The switch which was the HSRP Active for the VLAN I created was able to ping the virtual IP, no problem. The switch which was HSRP Standby however wasn't able to ping the HSRP Virtual IP.

I've been trying to figure out what's going on but I just don't see the problem - do you see a problem?

The configs are below and the Packet Tracer file is attached.

Configurations as follows

CORE-1

CORE-2

//basic initial setup hostname CORE-1 interface range fa0/1-24 shut interface range gi0/1-2 shut interface vlan 1 shut exit ip routing //trunk setup interface gi0/1 desc TRUNK_CORE-2 switchport trunk encap dot switchport mode trunk switchport trunk allowed vlan all no shut exit //VLAN, VLAN SVI & HSRP Setup vlan 2 name Network_VLAN exit interface vlan 2 ip address 2.0.0.2 255.255.255.0 standby 1 ip 2.0.0.1 standby 1 priority 255 standby 1 preempt exit

//basic initial setup hostname CORE-2 interface range fa0/1-24 shut interface range gi0/1-2 shut interface vlan 1 shut exit ip routing //trunk setup interface gi0/1 desc TRUNK_CORE-1 switchport trunk encap dot switchport mode trunk switchport trunk allowed vlan all no shut exit //VLAN, VLAN SVI & HSRP Setup vlan 2 name Network_VLAN exit interface vlan 2 ip address 2.0.0.3 255.255.255.0 standby 1 ip 2.0.0.1 standby 1 priority 250 exit

[Reza Sharifi]

Hi

Looking at your config you have shut interface

interface range gi0/1-2

shut

gi0/1 is your trunk interface.  Can you do a no sh and test again?

HTH

[Pavithran Nair]

I turned it back on in the //trunk setup section. The configs were applied exactly in the order you see up there. Also note that I can ping 2.0.0.3 (CORE-2 VLAN 2 SVI) from CORE-1 and I can ping 2.0.0.2 (CORE-1 VLAN 2 SVI) from CORE-2, meaning there's successful 2-way communications on that trunk link.

[Richard Burts]

I do not have Packet Tracer so I can not check the file that you sent. But from the description I am guessing that it is a flaw in the PT implementation. If you want to investigate it further I would suggest these steps:

- on the switch that is standby check its arp table. does it have an arp entry for 2.0.0.1?

- if there is an arp entry what MAC address does it show for 2.0.0.1? (is it the correct HSRP MAC?)

- if there is an arp entry and it is the correct MAC then check the mac address table of the switch.

- is there an entry in the mac address table for the HSRP MAC?

- if there is an entry in the mac address table does it point to the active switch, and on the correct interface?

HTH

Rick

[Pavithran Nair]

Hey Richard, thanks for the pointers. I did what you described and all the information appears to be accurate, I've included the outputs below for your reference. I wonder if there's something in the configuration that I missed - the part I can't wrap my head around is where I can successfully ping the SVI on CORE-1 from CORE-2 and vice versa. So there really shouldn't be a problem with reaching the HSRP VIP on CORE-1 from CORE-2.

CORE-1

CORE-2

//ARP Looks good on CORE-1 CORE-1#sh ip arp Protocol Address  Age(m) Hardware Addr  Type Interface Internet 2.0.0.1  1      0000.0C9F.F001 ARPA Vlan2 Internet 2.0.0.2  -      0060.701A.6038 ARPA Vlan2 Internet 2.0.0.3  0      0060.7042.5749 ARPA Vlan2 //Note the HSRP MAC Address CORE-1#show standby Vlan2 - Group 1 (version 2)   State is Active     6 state changes, last state change 00:00:30   Virtual IP address is 2.0.0.1   Active virtual MAC address is 0000.0C9F.F001     Local virtual MAC address is 0000.0C9F.F001 (v2 default)   Hello time 3 sec, hold time 10 sec     Next hello sent in 1.557 secs   Preemption enabled   Active router is local   Standby router is 2.0.0.3, priority 255 (expires in 8 sec)   Priority 255 (configured 255)   Group name is hsrp-Vl2-1 (default) //No entry on CORE-1 MAC Table CORE-1#show mac address-table           Mac Address Table ------------------------------------------- Vlan    Mac Address       Type        Ports ----    -----------       --------    -----    1    0006.2ac2.9419    DYNAMIC     Gig0/1    2    0060.7042.5749    DYNAMIC     Gig0/1 //CDP Neighbors CORE-1#sh cdp nei DeviceID Local Intrfce Holdtme Platform Port ID CORE-2   Gig 0/1       154    3560     Gig 0/1

//ARP Looks good on CORE-1 CORE-2#show ip arp Protocol Address  Age(m) Hardware Addr  Type Interface Internet 2.0.0.1  0      0000.0C9F.F001 ARPA Vlan2 Internet 2.0.0.2  0      0060.701A.6038 ARPA Vlan2 Internet 2.0.0.3  -      0060.7042.5749 ARPA Vlan2 //Note the HSRP MAC Address CORE-2#show standby Vlan2 - Group 1 (version 2)   State is Standby     7 state changes, last state change 00:00:39   Virtual IP address is 2.0.0.1   Active virtual MAC address is 0000.0C9F.F001     Local virtual MAC address is 0000.0C9F.F001 (v2 default)   Hello time 3 sec, hold time 10 sec     Next hello sent in 1.853 secs   Preemption disabled   Active router is 2.0.0.2, priority 250 (expires in 7 sec)     MAC address is 0000.0C9F.F001   Standby router is local   Priority 250 (configured 250)   Group name is hsrp-Vl2-1 (default) //Entry available on CORE-2 MAC Table CORE-2#show mac address-table           Mac Address Table ------------------------------------------- Vlan    Mac Address       Type        Ports ----    -----------       --------    -----    1    0001.963e.6719    DYNAMIC     Gig0/1    2    0000.0c9f.f001    DYNAMIC     Gig0/1    2    0001.963e.6719    DYNAMIC     Gig0/1    2    0060.701a.6038    DYNAMIC     Gig0/1 //CDP Neighbors CORE-2#sh cdp nei DeviceID Local Intrfce Holdtme Platform    Port ID CORE-1   Gig 0/1       162     3560        Gig 0/1

[Richard Burts]

Thank you for the outputs that provide answers to my questions. The outputs on core2 all appear as we would expect and seem to show that core2 is working correctly. The surprising thing, and almost certainly the explanation for the problem, is that core1 does not have the standby MAC in its mac address table. To me it certainly looks like a flaw in PT and certainly is not because of any mistake in your configuration.

HTH

Rick

[Reza Sharifi]

I don't have packet tracer on my system either.  Can you change it to MS word or notepad and repost?

[Jan Hrnko · Accepted solution]

Hi gentlemen,

I investigated it further since I  do have PT on my laptop. Everything seems correct, so answer to all of  Richard's questions is a big YES.

What I found out in  simulation mode is that when the packet arrives at Active switch, it  tries to broadcast it rather than processing it itself (and replying).  Active switch has not simply dropped it, since I connected a PC to one  of it's ports and assigned it to VLAN2 (I was trying to ping Virtual IP  from PC - no luck, same case).

Simulation mode - upon reception of ICMP from Standby sw (or PC) - Active switch says this:

The frame destination MAC address is not in the MAC table. The Multilayer Switch floods the frame to all ports in the same VLAN except the receiving port.

So in the end, it seems like yet another PT bug.

But let me know if you want more information from PT or anything else.

Best regards,

Jan

[Pavithran Nair]

Hey Jan & Richard

Looks like you're both right! I got the same results as Jan from the simulator function too.

Looks like my virtual PCs are not going to be able to ping their default gateways for a while, until the bug is fixed

Thanks for the feedback guys!

[Jan Hrnko]

Hi Adam,

Looks like my virtual PCs are not going to be able to ping their default gateways for a while, until the bug is fixed 


Thanks for the feedback guys!

You're welcome! There are just so many flaws in PT I encoutered so far... sometimes a simple save&restart will do it but unfortunately not in this case.

A friend of mine has started to learn CCNA and he is using PT. There are bugs even in much simpler things such as SSH connection from PC to a device (you can actually connect without defining valid username, which is mandatory for ssh! Just define a password on line vty and there you go :P). Have fun learning and playing with PT and if you do have questions, we are always happy if we can help.

Best regards,

Jan