Just because your topology has no blocking links (thanks to vPC), doesn't mean it's a good idea to disable STP.
vPC cannot protect against loops you might create. For example, if a new cable is connected between 5010A and 5010B with STP disabled = Bad News. Or, if you misconfigure your vPC interfaces connecting two different domains (creating a logical loop) = Bad News. Brad Hedlund http://bradhedlund.com -- On Mar 13, 2011, at 10:18 PM, quinn snyder <[email protected]> wrote: > from the release notes -- i see the following[0] > > STP can not be enabled on switches under the parent Cisco Nexus 5000 Series > switch. > > it seems that since you've got your n5010 underneath the n5020, you've got > stp processes running and designated ports being assigned to the upstream > interfaces. this has bitten me in the past when doing an "in-band" > keepalive, rather than using mgmt0. in my case, since the keepalives were > simply sent between the n5k pair using a vlan that wasn't extended an an svi > using a /31, i disabled stp on that vlan and restored my issu ability. > > now -- it seems that this command is valid under 4.2(1)n2(1) > > n5k-1(config-if)# spanning-tree port type edge ? > <CR> > trunk Consider the interface as edge port (enable portfast) even in > trunk mode > > you may be able to put something together through the use of this command and > disabling spanning-tree -- since this is meant to combat the trunks required > for virtualised hosts. > > it also should be noted that issu wasn't possible on n5k platform until > 4.2(1)n1(1). anything prior and you'll only be able to perform the upgrade > with disruptive behaviour. > > q. > > -- > () ascii ribbon campaign - against html e-mail > /\ www.asciiribbon.org - against proprietary attachments > > On 03/13/2011 06:02 PM, Church, Charles wrote: >> All, >> >> I'm having a hard time getting a non-disruptive upgrade to happen on >> my Nexus 5010s and 5020s. I'd really like to have non-disruptive, as we've >> got SAN attached Windows servers which tend to blue screen if they're unable >> to reach their iSCSI disks across the Nexus devices for more than a couple >> seconds. The topology has a pair of 5020s peered together, with a >> downstream 5010 pair peered together. The NetApp SAN is a VPC off the >> 5020s, and the servers are multiple VPCs (one for each enclosure) off the >> 5010s. There are no redundant links, all VPCs. All ports on the 5010s and >> 5020s are designated forwarding. The connections into the SAN and servers >> are trunks, thus not really able to fall into the 'edge' category needed for >> a non-disruptive ISSU. It seems a trunk can't be an edge port, even if it >> should be. Since I've got no redundant links, should I consider disabling >> spanning tree all together until the upgrade is complete? I've got >> redundancy into all chassis, so the loss of one switch doing a 'disruptive' >> upgrade is ok, but my concern is the peer switch will drop the VPCs as well >> (like when you've got temporarily-mismatching things like QoS, etc). Any >> other way to consider? >> >> Thanks, >> >> Chuck Church >> Network Planning Engineer, CCIE #8776 >> Southcom >> Harris IT Services >> 1210 N. Parker Rd. >> Greenville, SC 29609 >> Office: 864-335-9473 >> Cell: 864-266-3978 >> E-mail: [email protected] >> Southcom E-mail: [email protected] >> >> >> >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
