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

[Brad Hedlund (brhedlun)]

Hi Chuck,

The switch not being upgraded will keep the vPC connections UP, just as you witnessed when your switch rebooted due to fan issues. However... 

Prior to the recent 5.0(2) release, IF your vPC connections were reset for some other reason (server rebooting) while you had one of your Nexus 5000s down for maintenance, your server vPC would not come back up. This is because the default behaviour is for the vPC primary switch to first check the vPC interface configuration is in sync with the secondary switch before allowing it come UP. If the secondary switch was down for maintenance you were SOL.

In 5.0(2) a new "feature" was introduced called vPC Peer Config Check Bypass, which if configured, allows the vPC member ports to come UP even if the secondary switch is unavailable. The config check will happen after the secondary switch comes online, and if there is a mismatch only the new leg will be prevented while the existing leg continues to forward.

Cheers,

Brad Hedlund
http://bradhedlund.com
--



On Mar 14, 2011, at 9:49 PM, "Church, Charles" <Charles.Church at harris.com> wrote:

> 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/