[j-nsp] NSR+GRES vs Graceful restart
David Lockuan
dlockuan at gmail.com
Wed Feb 23 13:20:15 EST 2011
Hi Amos,
I think that the use of NSR+GRES or GR, its depends of your network
topology. If you have in your network different vendors and you want that
all equipment know when a router is doing restart, maybe you need to use
GR+GRES; with this you can do that forwarding plane continue forwarding
packets while the control plane is finishing to synchronize.
But if you want a routers don't advise when it are going to restart, maybe
you need to use NSR+GRES; with this you are doing that both REs are
constantly in replication and synchronization for this motive you need the
same version of JunOS in both RE. Aditionally you have to remember that NSR
only work in the default logical-system and you can't to select NSR for a
specific protocol, this feature take all protocols active in the chassis.
Other thing, NSR and GR need that GRES is active, because GRES permit to the
PFE's continue forwarding packets.
If you want to read more about these features, I will recommend to read the
book of Juniper: Junos High Availability Best Practices.
Best regards,
--
David
On Wed, Feb 23, 2011 at 12:49 PM, Amos Rosenboim <amos at oasis-tech.net>wrote:
> Hello All,
>
> I was wondering what are people thinking and doing in regards to redundancy
> on MX boxes or generally on Junos platforms.
> So far I did not run NSR+GRES in a live environment.
> In my lab a very basic test of NSR+GRES worked fine, but talking to a
> colleague of mine he mentioned some serious issues with NSR+GRES.
> The protocols/features used in the live network are very basic - plain
> vanilla ISIS+BGP not even MPLS.
>
>
> Regards
>
> Amos
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list