A basic overview of our current network design for core and distribution is as follows:
6506-E chassis in VSS
6509-E chassis single sup connected to each of the 6506 chassis in the core.
We are looking to replace the VSS in the core with Nexus 7K switches. Since the Nexus switches are not virtual by nature, I have to consider a HA protocol like HSRP or GLBP. Currently our links between the Core and Dist are L3 Point-To-Point. We wish to maintain this configuration in the new design. Since the two links on the Dist side are port-channels we currently have 2Gbps throughput. If I use HSRP with LACP one link goes into suspended mode, therefore only giving us 1Gbps throughput. With GLBP we continue to have 2Gbps. From what I can tell, ECMP (Equal-cost multipath) is enabled and should be in effect at this point, but I cannot find a way to prove this since I do not have another 6509 for distribution (my test distribution switch is just a 3560).
My question is this...
What is the best practice way to go in this situation? Should we allow STP to provide a look free environment and use priorities to determine the path (using HSRP and LACP) or should I use GLBP and have an active-active scenario from DIST to Core? Any suggestions on a solid way to test that load balancing is in fact working properly?
Excuse me if I misspeak on anything here as this is my first solo attempt at replacing a core. I've been living in the distribution and access layers for many years now.
The Nexus switches do support VPC (Virtual port channel - think of MEC on VSS) and VDC (virtual switches within the same chassis). Also HSRP has been modified on the Nexus 7K switches so that in effect your pair of Nexus switches become active/active in HSRP terms. It might be worth you having a read of some of the Nexus white papers which specifically cover Nexus/6500 intergration -
I do have a VDC running with a vPC link between them for the Core switches. I guess I failed to mention that in the post... I tried to provide as much detail as I could. When I configure HSRP according to the guides, it recommends ACTIVE mode for the interfaces in the port-channel rather than ON mode, which then enabled LACP on the interfaces, which in turn suspends one of the interfaces in the channel, thus creating an active-standby scenario. With GLBP the guides recommends ON mode for the interfaces in the port-channel which then disables LACP, thus creating an active-active scenario. I have read many docs and papers, and searched the web for best practices sample configs, but since the Nexus is a fairly new product, i'm sure there is a limited amount of information out there yet. I will also continue to investigate.
A quick overview of the topology for this lab/prep setup:
Two Nexus 7010 switches with a VDC named Core and vPC between them. Our normal distribution switch is a 6509 but since I do not have a spare I am trying to make do with a spare 3560 running the latest IOS. From the 3560 I have a L3 1Gb link to each of the N7K switches in a port channel. The default route is the GLBP address of this port channel, and OSPF is the routing protocol. I'm not sure how to tell which side of the link is placing the interface in Suspended mode. Hope some of the outputs below provide some details and a path.
What I am trying to accomplish is replacing the 6500 VSS in the core with the Nexus 7K switches while keeping the L3 portchannels i currently have in place from the distribution to the core, hopefully providing a load balance scenario.
Just my 2 cents: i think this is because you created a routed portchannel. Just create a trunked portchannel with VLAN 51 for example (switchport trunk allowed vlan 51). then put ip config on "int vlan 51".
The portchannel to the acess should come up with P/P (both links present)
This document gives several answers on frequently asked questions for PFRv3 channel state behavior.
Q1: What are all the channel operational states from a BR (border role) perspective and what are the rules/conditions to be in each st...
The need was to reach an host inside a LAN through a VPN connection managed by the LAN gateway (Cisco 1921).
The LAN gateway performs NAT and there was a dedicate nat rule for the host i wanted to reach through VPN.
I couldn't connect to the hos...