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

Church, Charles Charles.Church at harris.com
Mon Mar 14 22:49:41 EDT 2011


Brad,

	What is the consequence of doing a disruptive upgrade on one of the
5010s or 5020s?  I've had a 5010 reboot due to a fan issue, with no server
connectivity lost due to the redundancy.  Will the one not being upgraded
keep its VPCs up, or will they go down for a bit while the other is
reloading?  I'm not too worried about any downstream FEX modules, but
keeping the VPCs up on 10 gig ports is what's important.

Thanks,

Chuck

-----Original Message-----
From: Brad Hedlund (brhedlun) [mailto:brhedlun at cisco.com] 
Sent: Sunday, March 13, 2011 10:53 PM
To: Church, Charles
Cc: nsp-cisco
Subject: Re: [c-nsp] Non-disruptive ISSU for Nexus 5000

Hi Chuck,

ISSU for Nexus 5000 is only supported when the switch is a Leaf on the
Spanning Tree, not a Root. That might be the case with your 5010s, but not
your 5020s.  

Reason for that is because there is a ~90 sec budget to restart the lone
control plane, and that is too long for a STP root not to be sending BPDUs
;(

BTW, you can make a trunk port an "Edge" with the interface command:
"spanning-tree port type edge trunk"

Cheers,
Brad


Brad Hedlund
http://bradhedlund.com
--


On Mar 13, 2011, at 8:13 PM, "Church, Charles" <Charles.Church at harris.com>
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6514 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20110315/6dae3633/attachment-0001.bin>


More information about the cisco-nsp mailing list