Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Problem with 2 Sup720-3Bs and HSRP/Vlans between both switches

I have 2 Cat6509s in Hybrid mode (CatOS 8.5(1) IOS 12.2(18)SXF) and Sup720-3B.

These have a number of layer 2 Vlans configured, most of which have corresponding L3 Vlan interfaces on the MSFC.

Both are VTP servers, so the L2 Vlan config on both is identical.

For odd-numbered Vlans, switch 1 is the root bridge, while switch 2 is root for even-numbered Vlans. HSRP is configured in the same way: router 1 is primary for odd-numbered Vlans, etc.

Now I have a server connected to e.g. Vlan60, IP address (it makes no difference to this problem whether the server is connected to one switch or the other).

If I try to ping the server from another Vlan for which the other switch is root/HSRP primary, e.g. Vlan105 (either from a machine on Vlan105 or with extended ping on a router using Vlan105 as source interface) then I get no response. The server is receiving the ping and sending a reply but the reply is not reaching the source of the ping.

I can work around this problem by shutting down the layer 3 Vlan interface for Vlan60 (where the server is) on the router which is HSRP primary.

CEF appears to be working correctly because it can see the server on the correct interface on both switches.

Has anyone else experienced something like this? I am completely at a loss to explain this behaviour.


Re: Problem with 2 Sup720-3Bs and HSRP/Vlans between both switch

That's an interesting one. My impression is that this must be a layer2 issue.

The HSRP active node is where the ping-reply from the server goes to. The issue is not there when you use the other switch's interface. Therefore you must check the L2-path from the vl60 hsrp-primary switch to vlan105. I assume that vl105 is either discontinuous or pruned somewhere between the 6509 and the destination host. Another (remote) possibility is that you have a duplicate mac-address on the network.