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

quinn snyder snyderq at gmail.com
Sun Mar 13 23:05:07 EDT 2011


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/


More information about the cisco-nsp mailing list