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