04-12-2015 11:06 PM
No this is not normal behaviour. Can you share your configuration so we can have a look ? also some logs at the moment of a failover occurs would be helpful
Please Mark My Solution Accepted if it Helped, Kudos are Appreciated Too
04-13-2015 07:31 AM
15 minutes is really long for sure. Graceful restart for your routing-protocols does require that the downstream routers are capable of GR as well, but even if they are not, 15 minutes is an eternity for protocol convergence. If your Juniper platform supports it, NSR / NSB is a better alternative as it does not require participation from the downstream routers.
04-13-2015 07:42 AM
Why Advance TAC said it because we not enable NSR but GR. That's why i'm not understand. Is it GRES + NSR more better than GRES + GR. For your information during the failover i see all the routong protocol restarted. I see that when i using command "show system uptime".
Thanks and hope someone can give me strong point regarding ATAC said is true or not.
04-13-2015 07:50 AM
NSR is better than GR for sure. NSR synchronizes things across both the primary and secondary routing-engines, so downstream routers do not lose adjacency during a failover. If all goes well, the downstream devices will not notice an NSR at all. GR signals the downstream routers that the switchover is about to happen, and devices that are configured to support GR will basically "wait" for a while before dropping adjacencies.
04-14-2015 09:17 AM
Thanks for your explanation. One more thing is it NSR suitable for all design of network that have multivendor such as Core router Cisco (P) but PE was MX480 and with services like IPTV, Multicast and etc.
Is it NSR have some limitation of design. I ask this reason because i'm already propose to change for using NSR but the end user give the reason their network is suitable using GR. That's why make me confusing whether NSR have some restriction.
Thanks and hope u can give some explanation
04-16-2015 12:18 PM
NSR is advantageous in networks where neighbor routers do not support GR protocol extensions, as well as failure scenarios where GR cannot negotiate a grace period. As a result of this enhanced functionality, NSR is a natural replacement for GR.
Although NSR supports most protocols, it does not support all protocols. For all protocols supported by NSR, the state information is preserved during a switchover event. If you configure a protocol that is not supported by NSR, the protocol operates as usual. When a switchover occurs, the state information for the unsupported protocol is not preserved and must be refreshed using the normal recovery mechanisms inherent in the protocol. Also note that NSR is not supported on all Junos devices may be thats the reason your customer is saying that their network is suitabel for GR.
JNCIE-ENT#520, JNCIP-SP, JNCDS-DC
04-21-2015 04:58 AM
It is not supported on all hardware or for all features. The capabilities and limitations are pretty well laid-out here:
04-21-2015 08:03 AM
Hi Ronf & Kanoi,
Thanks for your feedback and url also. Currently the box is MX480 and Junos version was 11.4R7.5. So if i upgrade the box using 14.x it's look like NSR will support most of protocol or i can say all compare using GR right?
If yes, then i will suggest to end user upgrade the Junos version.
Thanks and aprreciate again your answer.
04-24-2015 05:45 AM
Yes, I would probably be running something in at least the 12.3 family, but more likely 14.X in order to support more protocols / hardware in NSR.