[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