[c-nsp] Non-disruptive ISSU for Nexus 5000

[Brad Hedlund (brhedlun)]

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 <snyderq at gmail.com> 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: charles.church at harris.com
>> Southcom E-mail: charles.church.ctr at hq.southcom.mil
>> 
>> 
>> 
>> 
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/