Cisco discontinued “spanning-tree pseudo-information” starting from NXOS version 7.0(3)4(1) on the 9000 platforms. So what is the solution for Nexus vPC and non-vPC VLANS on the same platform (hybrid)? Is it no longer going to be supported on NXOS/9000 platforms?
Although hybrid is not recommended vPC design for “aggregation layer” but you find a lot scenarios where you need to have both vPC and non-vPC within the same platform (mostly in mid-size data centres; where you have a lot reasons you can’t deploy traditional ethernet switches; hence you have considered the Cisco Nexus platforms).
If you carry everything (both vPC VLANs and non-vPC VLANs) over the vPC peer-links (yes, vPC carry orphaned VLANs as well!) – in this case if there is any issue happen on the vPC peer links and that stops the vPC working, the downstream switches those are connected to the Nexus via non-vPC/non-vPC VLANs will stop forwarding frames due to STP (any STP – STP/RSTP/PVSTP/MSTP) blockage as they don’t have any information about what happened between the vPC peer Nexus switches in a vPC peer failed scenario.
Experts suggest that you should have an additional Layer 2 trunk port-channel alongside your vPC peer-link; this Layer 2 port-channel will carry non-vPC VLANs in case vPC stops working (whatever reason; could be a Nexus reboot during maintenance!).
Well, now you have setup a seperate Layer 2 trunk port channel for non-vPC VLANs and shutdown the vPC peer link to test it – but you found it is still not working as expected! STP is blocking the Layer 2 trunk link, whats the problem! Cisco used to have a solution for this called “spanning-tree pseudo-information“; as I have mentioned in the beginning Cisco discontinued this starting from version 7.0(3)l4(1) on the Nexus 9000 platform. So what is your option for this? Should you stop using Nexus if you don’t follow spine and leaf design?
Yes – there is an answer to this, there is a small trick to make this working! By discontinuing psuedo-information, Cisco basically makes it ever easier to configure; you need to do the following –
i. First, you need to set STP root priority for the VLANs to a lower priority number on one of Nexus switch (default priority is 32768, lower is prefer; this should be done on the primary vPC role Nexus switch) and leave STP untouched on the other Nexus switch (this is the vPC secondary role switch).
ii. Second, on the non-vPC trunk port-channel set “spanning-tree port type normal” on “both” the switches; (“spanning-tree port type network” is recommended for vPC peer-link).
Here is an example config -Here is an example config –
On the vPC primary role switch, apply the following - (config)#spanning-tree vlan 10,20,30,40-50 priority 8192 On both the switches, apply the following - (config)#interface port-channel10 (config-if)#description "non-vPC trunk port" (config-if)#switchport (config-if)#switchport mode trunk (config-if)#switchport trunk allowed vlan 10,20,30,40-50 (config-if)#spanning-tree port type normal
Without having the above configuration applied you will find STP is blocking the non-vPC Layer 2 trunk link even if the vPC peer-link is shutdown. Also in this example – the vPC primary role switch will be the STP “root bridge” because of lower priority configured (8192).
To test your configuration – shutdown the vPC peer-link, run “show spanning-tree vlan xxx” – you should see STP put the L2 trunk interfaces in forwarding state immediately.
Here is a vPC and non-vPC VLANs on the same platform diagram –
Hi, I have a question. Can 3rd party devices such as Mellanox Switch (MLAG) communicate to Cisco (non-VPC VLAN)? I know that Mellanox MLAG PO can talk to Cisco vPC PO as it is proven. However, if the Cisco carries non-vPC (Orphaned), say VLAN 200 to other switches. It seems that despite adding VLAN 200 on my Mellanox MLAG PO, the traffic does not flow. Hope you can advise on this. Do we need to add the non-VPC VLANs into the vPC PO ?
You can surely add non-vPC VLANs to vPC PO – its no harm; all our setups have this. Also you can run show spanning-tree to see where your VLAN 200 is being blocked – this will give you some idea as well. Hope this help. Cheers.
Thanks for the information. We realised that the cisco vPC peer link does not have VLAN 200. In the show logging, we saw this error,
Interface PO 100, Vlan 200 is not allowed in vpc peering. This error seems to be telling me because Vlan 200 is not part of vPC peer link, thus even if I have 3rd party Switch PO 100 with Vlan 200 configured same as cisco switch PO 100 with Vlan 200. It will not work unless I have added Vlan 200 in vPC peer link
As Vlan 200 is non vPC Vlan, will there be any expected downtime if I were to add non vPC Vlan in vPC peering between the 2 cisco switch ?
By any chance do you remember what message was logged on the non vpc switches when spanning tree blocked the port. I imagine different vendors and platforms will have a similar behavior.
I can’t remember what messages were those; I don’t have the same setup anymore. I guess – there might be a lot of changes within the STP on the recent version of the NXOS software.