[c-nsp] 4500X in VSS - Upgrading IOS XE

Tue Apr 19 23:58:35 EDT 2016

Just an update to this...both switches (As mentioned) had new IOS uploaded to flash, verified ok on both, both had bootvars identical and conf reg set to 0x2102

Consoled to both via OOB, Reloaded first switch, came up ok, second switch decided for some reason to go into rommon, tried "boot" on that one, and it booted with the "oldest" IOS it could find on flash....which didnt support VSS(so both switches up, but no VSS), so renamed the IOS versions of the "old" IOS, reloaded, and it booted with the correct "new" IOS......why it didnt honour the bootvar, dont know, but thank you OOB access!....both switches back in VSS with new version of IOS.

Rather painful upgrade, but got there in the end

________________________________________
From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> on behalf of Chris Burwell <cburwell at gmail.com>
Sent: Tuesday, 19 April 2016 10:05 PM
To: cisco-nsp NSP
Subject: Re: [c-nsp] 4500X in VSS - Upgrading IOS XE

A bit off topic, but...

I have also found this to be true on the 4500X platform with L3 interfaces
(no switchport). I found this odd since there are some cases where we
needed to connect two L3 ports to the same upstream provider switch.

Also worth mentioning is that the 4500X does not have a provision for
changing the MAC on individual L3 ports when running in VSS. 6500's do, but
this feature is not available on the 4500X.

As you mentioned, it's easy to get yourself into trouble by templating the
VSS config and reusing the same domain ID.

- Chris

On Wed, Apr 6, 2016 at 8:31 AM, Garrett Skjelstad <garrett at skjelstad.org>
wrote:

> I assisted a client with something similar, it turned out they templated
> their config, and reused vss domain id numbers...
>
> SVI MACs are generated based on that number. 4500Xs were back-and-forth as
> the ARP would change...
>
> They only had 10 Production VSS pairs to change. whoops.
>
> -Garrett
> On Apr 6, 2016 05:23, "Steven Pfister" <SPfister at dps.k12.oh.us> wrote:
>
> > I've just been through upgrading a couple of 4500X pairs using this same
> > procedure (without touching the VSS link) going from 3.7.1E to 3.7.3E.
> >
> > The upgrade was done to try and fix a problem we've been having.
> > Occasionally, the 4500X pair will become unreachable for several minutes
> > and usually come back on its own. Nothing in the logs seems to indicate
> any
> > problems. On a small handful of occasions, a visit to the site is
> necessary
> > to do the redundancy shelf reload. When that happens, all the usual
> > neighbors seem to present, but nobody is pingable. Everything is OK after
> > the reload. Has anyone seen anything like that?
> >
> > >>> CiscoNSP List <CiscoNSP_list at hotmail.com> 4/5/2016 7:20 PM >>>
> >
> >
> > Disconnecting VSS/removing VSS/VSL conf was a recommendation from TAC(For
> > a non ISSU upgrade)....which sounded like a very unusual requirement
> > lol.....hence my question here.
> >
> >
> > cheers
> >
> > ________________________________
> > From: Garrett Skjelstad <garrett at skjelstad.org>
> > Sent: Wednesday, 6 April 2016 8:35 AM
> > To: CiscoNSP List
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] 4500X in VSS - Upgrading IOS XE
> >
> > Why would you need to disconnect the VSS link? We've upgraded them
> > successfully from 3.6 to 3.7 without disconnecting the VSS links and
> > reloading them individually.
> >
> > On Tue, Apr 5, 2016 at 2:22 PM, CiscoNSP List <CiscoNSP_list at hotmail.com
> > <mailto:CiscoNSP_list at hotmail.com>> wrote:
> >
> > Hi Everyone(Sent this to the list yesterday, but it still hasnt shown up?
> > So re-sending),
> >
> > I need to upgrade IOS XE on a pair of 4500X's...Id prefer not to try/use
> > ISSU, as they are remote switches and in production....so Im hoping
> someone
> > has performed an upgrade on these boxes(In VSS) and can provide some
> > guidance on a method that "works" :)
> >
> > Ive read where people disconnect the VSS link (Or shutdown those ports),
> > and perform the upgrade on the 2 switches, then reconnect VSS....but
> could
> > you do something like this:
> >
> > conf reg on both switches is already set to 0x2102, so the switches
> should
> > honour the bootvar variables
> >
> > copy new IOS XE to bootflash & slavebootflash
> >
> > update boot var to point to new XE image
> >
> > boot system flash bootflash:xxx
> >
> > wr mem and check bootvar is updated
> >
> > and reload both switches:
> >
> > redundancy reload shelf
> >
> > This should reload both switches, and they should come up with the new
> > image, and VSS should re-establish?
> >
> > Thanks in advance for any advice/recommendations
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net<mailto:
> > cisco-nsp at 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 at 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 at 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 at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/