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 <[email protected]> on behalf of Chris Burwell <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> > > Sent: Wednesday, 6 April 2016 8:35 AM > > To: CiscoNSP List > > Cc: [email protected] > > 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 <[email protected] > > <mailto:[email protected]>> 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 [email protected]<mailto: > > [email protected]> > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
