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:brhed...@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.chu...@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.chu...@harris.com > Southcom E-mail: charles.church....@hq.southcom.mil > > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/