[afnog] Backup routing Engine

ibtisam jamal ibty.jamal at gmail.com
Wed Jun 13 12:49:54 UTC 2012


We will follow this procedure .
Insert second RE ,upgrade the junos to the existing RE junos version and
verify ...using Show version invoke-on all-routing-engines

set chassis redundancy routing-engine 0 master
set chassis redundancy routing-engine 1 backup
set chassis redundancy failover on-loss-of-keepalives
set chassis redundancy failover on-disk-failure
set chassis redundancy graceful-switchover

verify using
show system switchover

Any other recommendation .We will leave out nonstop active routing for now.


On Tue, Jun 12, 2012 at 5:35 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:

> On Tuesday, June 12, 2012 03:59:20 PM ibtisam jamal wrote:
> > > Thanks for the link but what i wanted was to have both
> > > Routing engines operational for redundancy.
> > > one as master and another as backup.
> > > In case the master faces issues a graceful switchover
> > > happens.
> What you're looking for is known as GRES (Graceful Routing
> Engine Switchover).
> It's also well-documented:
> http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuration/gres-
> configuring.html
> Please note that GRES only enables redundancy for the
> routing engines. It does not do the same for protocols.
> If you want protocol redundancy, e.g., for IS-IS, OSPF, BGP,
> RSVP, LDP, PIM, RIP, e.t.c., you'll need to look at 2x
> options:
>        1. IETF Graceful Restart.
>        2. NSR (Non-Stop Routing).
> IETF Grace Restart is now quite mature for all the protocols
> I mentioned above, and more. But it requires the devices on
> the other side of the link support it too. It's also an open
> standard, so if different vendors implement it, it "should"
> work between them.
> NSR is locally-significant to the router. Unlike Graceful
> Restart, NSR simply copies protocol state from the primary
> routing engine to the backup one. In case of failure of the
> primary RE, the backup one assumes control using protocol
> state it had the time of failure of the primary RE. In
> theory, this should minimize protocol convergence time
> during an RE switchover.
> However, the only issue with NSR is that there is a higher
> potential for an NSR-related bug taking down the primary RE
> and propagating that issue to the backup RE, rendering the
> whole solution moot. But it's just a risk :-).
> Also, NSR support for various protocols tends to happen much
> more slowly than for the Graceful Restart, so you'll end up
> needing to run bleeding-edge code if you're an NSR fanatic
> and want all your protocols to be NSR-aware.
> You can read all about the solutions here:
> http://www.juniper.net/techpubs/en_US/junos9.5/information-
> products/topic-collections/swconfig-high-
> availability/graceful-restart-for-routing-protocols-
> configuring.html
> http://www.juniper.net/techpubs/en_US/junos10.2/topics/task/configuration/nsr-
> configuring.html
> Hope that helps.
> Cheers,
> Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://afnog.org/pipermail/afnog/attachments/20120613/d7e9b3db/attachment.html>

More information about the afnog mailing list