I have two Nexus 5010 switches setup with vPC. I have two Nexus 2148T FEXs, each one is connected to one of the Nexus 5000s. I have a Dell M1000e blade chassis with 4 blade switches installed. The A1/A2 IO slots have PowerConnect M6220 1G switches. These switches are not stacked. Each has two uplinks to each of the two FEXs. The first uplink from each and the second uplink from each are configured to belong to two vPCs. The B1/B2 IO slots have PowerConnect M8024 10G switches. These switches are not stackable. Each has two uplinks to each of the two Nexus 5010s. The first uplink from each and the second uplink from each are configured to belong to two vPCs.
When I run "show spanning-tree issu-imapct" on either Nexus 5010 switch, I have problems with criteria 3 with non-edge ports. Ports 11-14 on each Nexus 5010 switch are what are used for the 10G uplinks from the M8024 switches. vPCs 11-14 are used for these ports.
Given this network hardware and connectivity, is there a way to resolve the non-edge ports so that I would be able to do non-disruptive firmware updates?
switch31b# show spanning-tree issu-impact
For ISSU to Proceed, Check the Following Criteria : 1. No Topology change must be active in any STP instance 2. Bridge assurance(BA) should not be active on any port (except MCT) 3. There should not be any Non Edge Designated Forwarding port (except MCT) 4. ISSU criteria must be met on the VPC Peer Switch as well
Following are the statistics on this switch
No Active Topology change Found! Criteria 1 PASSED !!
No Ports with BA Enabled Found! Criteria 2 PASSED!!
In most platforms where we support ISSU we have two supervisors, in other words two CPUs. However in the N5K we have just the single CPU so we have quite some limitations on ISSU, or rather it can only be carried out in certain circumstances.
The caveat here which is most relevant would be "STP can not be enabled on switches under the parent Cisco Nexus 5000 Series switch." So ISSU is unfortunetly not supported with your current topology.
If you absolutely need ISSU you could workaround it by temporarily using edge ports, but it comes with fairly inherent risks (and is not a Cisco recomendation). I could not follow the exact topology you described, but presuming there is no internal link between the blade switches, what you could do during the ISSU is shut down all links that would normally be blocking, then make the forwarding links to the Dell blade chassis as portfast trunk ports, this would mean they would no longer be considered as designated and the ISSU would then be supported. Once the ISSU is complete, you could remove the portfast configuration, and renable the shut down links.
I would really emphasize here that it is vital to shut down the links that are normally blocking so you have no redundant path between the Dell and Nexus switches and therefore can't create a loop. As stated above, if not followed correctly there is the risk of a loop which could potentially lead to a network down, so it is really your call if you consider this preferable to a normal disruptive NX-OS upgrade.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...