N7K ISSU “a long time ago” has evolved drastically.
I vaguely remember that 5.0, 5.1, and 5.2 code each had a scheduler re-write
because things would get bungled up under load. I’m sure some of the TMEs on
this list can comment.
I myself had a few issues moving from 5.1 to 5.2 — causing
Actually ISSU is not that stable, I tried it a couple of times "long time ago"
with no luck so I stopped using it at all.
Best Regards,
Ahmed Elnagar | CCIE#24697, CCNP R/DC
-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Bradley
Ordner
Sent:
Sorry, memory served me wrong, should use long timeout, not short.
Sent from my iPhone
> On Feb 23, 2018, at 7:49 PM, Hunter Fuller wrote:
>
> We were required to use long LACP timers for one upgrade. The show impact
> command will tell all, in this regard.
>
> As Mike
We were required to use long LACP timers for one upgrade. The show impact
command will tell all, in this regard.
As Mike mentioned, if an stp change occurs it will rollback the ISSU.
On Fri, Feb 23, 2018 at 21:39 Michael Lee wrote:
> Make sure use short lacp timeout, no
Make sure use short lacp timeout, no spanning-tree change during the upgrade
Also boot disk array status
Mike
Sent from my iPhone
> On Feb 23, 2018, at 4:16 PM, Hunter Fuller wrote:
>
> On Fri, Feb 23, 2018 at 8:06 AM Justin M. Streiner
> wrote:
>
was to "reload"
./Randy
From: Bradley Ordner <bradin...@hotmail.com>
To: Hunter Fuller <hf0...@uah.edu>
Cc: cisco-nsp NSP <cisco-nsp@puck.nether.net>
Sent: Friday, February 23, 2018 5:27 PM
Subject: Re: [c-nsp] Nexus 7k Upgr
I’ll be honest I was pretty confident after reading the config guide on the
website. This was going to happen this weekend but I wanted more time to
prepare.
The config guide does say ‘one command does it all’ which sounded great! I
wasn’t aware of some of the issues people have seen such as
On Fri, Feb 23, 2018 at 8:06 AM Justin M. Streiner
wrote:
> Vendors also sometimes conflate "ISSU" and "hitless", or their
> documentation doesn't always make it clear that an ISSU carries the
> potential of outages.
For what it is worth - there is a NX-OS command for
On Fri, 23 Feb 2018, Bradley Ordner wrote:
Thanks, I’ll take this all onboard. The reason for the upgrade is we
wanted to start using Loopbacks for OTV and finish a DR design that
seems to have not been completed. Sent from my iPhone
ISSU is nice in practice, but it's something that's very
Hello,
On 23 February 2018 at 08:58, Pete Templin wrote:
> I would even go so far as to:
>
> load system/kickstart files
> isolate the box (shutdown all ports)
> power-cycle the box, let it boot into the new code
> perform EPLD updates on all cards
> run the ISSU command
Thanks, I’ll take this all onboard. The reason for the upgrade is we wanted to
start using Loopbacks for OTV and finish a DR design that seems to have not
been completed.
Sent from my iPhone
> On 23 Feb 2018, at 5:58 pm, Pete Templin wrote:
>
> I would even go so
I would even go so far as to:
load system/kickstart files
isolate the box (shutdown all ports)
power-cycle the box, let it boot into the new code
perform EPLD updates on all cards
run the ISSU command to ensure all of the little microcode thingies
(PSUs, fans, etc.) are covered
unisolate the
Definitely not a stupid question. While the double ISSU would work we
generally would not do it for big jumps like that.
The problem is that the whole procedure tended to be buggy so we are too
afraid. Not speaking about crazy bugs we ran into half year later because
"triggered by previous issu
On Fri, 23 Feb 2018, Bradley Ordner wrote:
We have a Nexus 7K with two SUP2Es. We need to get to software version 8.1(2).
It says that you can't double hop to a software version without an outage.
Although I have found the following -
ISSU from 7.2(0)D1(1) to 7.3(1)D1(1) then to 8.1(2).
We
14 matches
Mail list logo