Nexus 3548 - NX-OS 6.0(2)A7(2) - vPC - no orphan-port suspend option

[Lukas Hubschmid]

Dear all,

I have two Nexus 3548 in a vPC setup, running NX-OS 6.0(2)A7(2) in a small on-premise datacenter environment.

Attached to it are downstream switches (Catalyst) with LACP / vPC and ESXi 6.0 hosts without LACP / vPC (vDS in ESXi is configured with route based on originating virtual port). Now to make sure the ports to the ESXi are shutdown e.g. on vPC peerlink failure, I looked for the command vpc orphan-port suspend in the interface configuration (Et1/1-3), but the command is simply not available.

What did I miss? How can I configure the orphan ports to suspend on 3548?

Many thanks in advace!
Lukas

[Reza Sharifi]

Hi,

You can only apply this command to FEX host ports. 

Can you test it on a FEX port?

HTH

[Lukas Hubschmid]

Hello Reza,

Thanks for your answer!
There are no FEX, only those two Nexus 3548.

KR & Thanks,
Lukas

[Reza Sharifi]

Hi,

Sorry, there is no option to enable it for non-fex port.

Thanks!

[Lukas Hubschmid]

Ok, thanks - then I think the only way is to go with static etherchannel (so the ports will be VPCs) and configure the ESX DvS with Route based on IP hash.

Thanks for your help!

[Reza Sharifi]

Yes, you can configure the etherchannel as static (on) or don't use etherchannel at all.

Just uplink the ports to both Nexus switches, trunk them and let the server do the load balancing and file-over for you. A

This actually works well. Not sure of you can do route based with IP hash without using etherchannel.

HTH

[Lukas Hubschmid]

What happens if one Nexus switch is isolated (e.g. vPC peerlink fails, or directly after a reboot) to the uplinks to the ESX (non-vPC)? From my point of view they will be kept up and therefore generating a blackhole, as the ESX still sends traffic to the isolated switch. With IP hashing and etherchannel, the uplinks to the ESX servers will be part of the vPC and will be shutdown if the switch is isolated. Or am I wrong?

Many thanks!
Lukas

[Reza Sharifi]

As long as you have HSRP running, when you shut down/reboot one switch, the other switch will become HSRP master and the NIC on the sever connecting to say switch-a now fail-over to switch-b and continue forwarding traffic without any interruptions.  We tested it this during OS upgrade and it works really well.

HTH

[willwetherman]

Hi,

You are correct with what you stated above. I faced the same challenge with a small data centre installation where we had 2 x Nexus 3548 switches and a bunch of Cisco C220 servers running ESXi that were directly connected to both N3ks. The original plan was to use standard virtual switches with route based on originating virtual port ID, but I discovered as you did, that the N3ks don’t support orphan port suspend so both NICs to the ESXi servers remained up when the vPC peer link fails resulting in broken communication between VMs running on different ESXi hosts.

The solution was to change the ESXi standard virtual switches to use route based on IP hash and then configure the N3ks to bundle the corresponding NICs into a virtual unconditional (mode on) port-channel.

When the vPC peer link failed, the vPC ports on the second N3k switch were shutdown resulting in all traffic to be shifted to the primary N3k.

I hope that this helps