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:
>
--- Begin Message ---
To OP:
My 2 cents: If at all possible, use traditional-upgrade.
Personal-experience attempting ISSU on 65xx, 7ks, 9ks:
Mixed-Bag - some went flawlessely and others; sideways(outage). I have also
experienced the *sideways* upgrade after a few months: vendor's recommendation
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
Hi all, curious if anyone has run into issues with IPv6 uRPF on NCS5500 and/or
XR 6.2.3? I have an interface where I added:
Ipv4 verify unicast source reachable-via any
ipv6 verify unicast source reachable-via any
and immediately lost my ability to talk to a BGP peer connected to it using a
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
Hello,
We experience the same problem with our Nexus 9k switches that we have. The
OID returns some kilobits of traffic which in reality is much more. The version
of NX-OS is 7.0(3)I2(2d)
I don't have any news regarding this fix which is very annoying and I don't
believe its HW limitation
Hi Gert,
Gert Doering wrote on 23/2/2018 9:34 πμ:
> Hi,
>
> On Thu, Feb 22, 2018 at 11:48:05PM +0200, Tassos Chatzithomaoglou wrote:
>> Lately we revisited the topic, opened a case and TAC informed us about bug
>> CSCuy92828, where it's clearly written that hw switched IPv6 traffic isn't
>>
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
13 matches
Mail list logo