[j-nsp] ISSU timeouts on MX upgrades due to large routing tables?

[Mark Tinka]

On Wednesday, May 22, 2013 08:38:40 AM Saku Ytti wrote:

> We banned ISSU from our network due to poor hit/miss
> ratio, not uncommonly something strange would happen
> after ISSU.
> Like firewall filter was programmed wrong, routes were
> blackholing.
> 
> But as far as I understand, ISSU on routers isn't useful
> in other vendors gear either.
> 
> Even if ISSU would work in JNPR, it wouldn't be that
> useful to us, as it can cause blackholing for several
> seconds, which is not something we can do intentionally
> without announced maintenance windows, and if we do
> announce maintenance window, we might as well do full
> reload.

+1.

I've never tried implementing ISSU in any networks I've 
run/built because on paper, it looks both rosey and dark at 
the same time.

As many have said on this and other operational lists in the 
past, since most ISSU runs would happen in a maintenance 
window anyway, why not keep your life simple and just run 
upgrades vanilla?

For those running IOS XR, ISSU sounds like a great idea, but 
even SMU's that are documented as hitless have hit us many 
times. That said, I'm hearing some good news for IOS XR 5 
re: reduction of software upgrade times. I digress...

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20130522/0af14201/attachment.sig>