I have a requirement to provide a L2 VLAN through a nexus environment built on 7K's between Cat6Ks which so that the Cat6K's can provide first hop redundance using HSRP. I would prefer not to have anything L3 wise on the Nexus, rather just use it as a interconnect VLAN between the 2 Cat6k's.
The Cat 6K's can ping each other fine, so ARP, ICMP echo's etc is functioning correctly. HSRP though isn't aware of its partner leading to both being active with no standby. I believe this is caused by the Nexus filtering the multicast Hello packets.
What would you think is the best way to get this working keeping the L3 off the Nexus platforms ?
/--N7K-A1---N7K-B1--\ Cat6K-1 Cat6K-2 \--N7K-A2---N7K-B2--/
if the ports are assigned to correct vlans and there is no loop in the network, you can try turning on HSRP on 7ks using the command below.
I can't try that at the moment due to operational pressures. But will give it a go later, I am not running HSRP (or even a layer 3 SVI) on the Nexus environment so am surprised this could be is the reason the HSRP hello packets Version 1 or 2 are not passing through the nexus environment.
I will however report back here and mark as correct if this solves the problem.
Thanks in Advance.
The other thing you can do is to make sure that spanning tree instance is running on cat and nexus switches for the vlan used by hsrp group and is allowed through the trunk interface that connects 7ks.
sh spanning-tree vlan x
also check if switches are learning mac addresses that belong to hsrp interface.
The L2 appears to be working fine for none multicast (HSRP Hello's). I can ping between the 2 Cat6K's fine. The ARP cache is being populated with other hosts connected to both 6K's on either side. I can ping all the devices on both side, from both the 6K's.
I believe spanning tree, trunking etc are fine with unicast traffic working as expected, just not HSRP which has both in Active state with standby unknown.
I tested HSRP configuration using catalyst switches and NX-OS in a virtual environment. And enabling HSRP feature on nexus didn't fix the problem. I tried using hsrp version 1 and 2, but no luck. Catalyst switches were able to ping each other just like in your case.
I checked both SVIs and they were both registered to multicast group 184.108.40.206 which is used by version 2. Debugged standby and hsrp engine on all switches, didn't see anything that would point to any issue.
It's either a feature on NX-OS that needs to be enabled or this implementation is not supported with NX-OS which is hard to believe. I haven't come across this kind of design and usually it's the other way around. You may want to open a ticket with cisco TAC.
Many thanks for confirming I'm not completely loosing it.
Unfortunately even though this isn't a typical design, it is some functionality that we need to provide in our environment. In the future I fully expect to be able to "design it out", but that is likely to be during equipment refresh which is some time away.
I will raise a call through our partner who will probably refer it to TAC.
Your welcome. You don't have to have a typical design to make things work, you are not breaking any rules with this implementation and on paper it should work without having any issues.
I will try what Jon is suggesting and it may work. Will keep you guys posted.
After a short vacation, I'm back working on this, and have a call raised with out support partner.
Will report back as / when we make some progress.
Thanks for the thoughts and suggestions thus far.
I agree that even though this is not a typical design there is no reason why it shouldn't work.
Would be interested to hear the solution if you get one.
Check out this link - http://www.cisco.com/c/en/us/support/docs/switches/nexus-5000-series-switches/116270-technote-nexus-00.html
Nexus 7Ks should have similar policies.
You can issue this command on nexus - Switch# show policy-map interface control-plane | i class-map|match
and look for hsrp-vrrp policy.
This may or may not help.