--- Begin Message ---
Thanks Garrett!
Unfortunately I cannot afford a 30 minutes outage.
What doesn't make sense to me is the "issu loadversion" step. If I understand
correctly, it would load the current hot standby with the new version. But
wouldn't a cold standby take over if I reloaded the hot standby CPU,
effectively bringing me back to the same state?
Is there a reason why I shouldn't do the upgrade the old fashion way? That is,
change the boot variable, reload hot standby manually, failover and then reload
the other three supervisor engines.
I mean, is there a benefit to using "issu
loadverion/runversion/acceptversion/commitversion" process vs just loading the
software and reloading manually?
Thanks,
Eli
On Friday, March 12, 2021, 04:08:25 PM EST, Garrett Skjelstad
<garr...@skjelstad.org> wrote:
I know this is an awful answer, but just don't do ISSU on them. 😅
Most of my experiences come from quad Sup8s in the same chassis. We have been
running 3.11.1 for the past 49 weeks, since our last cycle, which is 12/18
months.
The biggest ISSUe (lol) with it, is just the sheer number of jumps back and
forth as you climb the ISSU ladder from a historic release. We have also found
it to be beneficial to do a pre-ISSU supervisor restarts for each supervisor
prior to actually doing the upgrade so as to lessen the chance of getting
'stuck' in a ISSU-loop with a hung Supervisor. The fact that 4500 sups sit in a
'cold' mode when doing the jumps just adds to the delay, 6500s/6800s are MUCH
nicer for this action in the fact they are 'warm(hot?)' and already booted.
A full cold restart of the shelves takes approximately 23 minutes per our lab
units. We have found in some locations that have tolerable maintenance windows,
to load/prep and simply cold start the shelves, instead of a weeklong of ISSU
maintenance windows. Of course, if you patch every 60-120 days as the cadence
of each release, perhaps it's more manageable. I read there are some additional
protections and time optimizations in later rommon versions, but for our use,
we just haven't seen the need for a seperate out of cycle ROMMON patches. We
are currently looking at simply replacing them with Catalyst 9k models.
The 4500-Xs run the same supervisor set and are just as friendly, although
contending with only duals vs quads.
Obviously out-of-band management on all supervisors is a necessity.
YMMV, good luck!
-Garrett
On Fri, Mar 12, 2021 at 12:27 PM Eli Kagan via cisco-nsp
<cisco-nsp@puck.nether.net> wrote:
>
>
>
> ---------- Forwarded message ----------
> From: Eli Kagan <e.ka...@yahoo.com>
> To: "cisco-nsp@puck.nether.net" <cisco-nsp@puck.nether.net>
> Cc:
> Bcc:
> Date: Fri, 12 Mar 2021 20:25:01 +0000 (UTC)
> Subject: Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade
> Hi all,
>
> I have a rather old Cat4507R+E pair, running on four Sup7e as a VSS, IOS-XE
> version 3.8.8E.
>
> I'd like to understand what's the right way of doing an ISSU on a quad sup
> system. I am planing to go to version 3.8.10E unless someone has a better
> suggestion.
>
> Sharing your first hand experience would be greatly appreciated.
>
> Thanks,
> Eli
>
>
>
> ---------- Forwarded message ----------
> From: Eli Kagan via cisco-nsp <cisco-nsp@puck.nether.net>
> To: "cisco-nsp@puck.nether.net" <cisco-nsp@puck.nether.net>
> Cc:
> Bcc:
> Date: Fri, 12 Mar 2021 20:25:01 +0000 (UTC)
> Subject: [c-nsp] Cisco Cat4500 Quad Sup VSS ISSU IOS Upgrade
>
> _______________________________________________
> 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/
>
--- End Message ---
_______________________________________________
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/
