[j-nsp] graceful failover and software upgrades

Pekka Savola pekkas at netcore.fi
Fri Mar 18 18:07:34 EST 2005


On Fri, 18 Mar 2005, daniel wrote:
> actually; in both scenario's the sessions flap. Here's what happens with
> GRES (graceful RE switchover) enabled:
> - during normal operation the active RE synchronizes state with the
>   backup. This is things like interfaces, routes etc.
>
> - when the active RE fails; the standby takes over. During this time
>   the PFE (i.e. forwarding complex) continues to forward with the state
>   of the time of the failure.
>
> - GRES does not mirror TCP sessions or any other routing protocol
>   neighborships. So they will go down.

Sorry, I should have been more explicit.  Obviously, the sessions 
themselves will flap.  But the real question is whether the _routing_ 
flaps, i.e., whether it stays the same across the event.  With 
graceful restart, routing does not flap.

> - This is where graceful restart comes into play. The original master
>   had sessions with it's neighboring routers. When graceful restart is
>   enabled, you effectively tell your neighbor: if i disappear don't
>   worry i'll be back (tm) and while i'm gone assume i can still forward
>   traffic (i.e. don't withdraw my routes from the rest of the network).
>
> - when the new master comes up; it establishes new sessions/adjacencies
>   and indicates it came back after a graceful restart. The neighbors will
>   now resend all their routing info as it's possible that right at the
>   time of the failure a routing update was missed.

According to a couple of notes, GRES should be usable also w/o 
graceful restart just fine, it'll just result in some minor routing 
flaps.  But that's probably OK.

And if you also use graceful restart with GRES (and the neighbors 
support it), you can avoid the routing flaps as well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


More information about the juniper-nsp mailing list