How Graceful Restart works...

[NetworkGroover]

Hey guys,

I thought I had an OK grip on Graceful Restart... but now I'm running into something that's really bothering me.

Let's say you have a chassis with dual sups and you're running OSPF Graceful Restart.  Downstream is a router that doesn't support even helper mode.

What happens when the active supervisor fails?  Does this failed supervisor magically send out a Grace LSA or somehow tell the standby sup to do it?

I know how stupid this question sounds, and it's on purpose.

[NetworkGroover]

If someone has a spare chassis switch sitting around and can set this up, that would be awesome.  Needs to be with SSO + GR(Or NSF.. whatever you want to call it).

Do tpdump/mirror/whatever from the downstream device.  Unseat the active sup - see if you get a Grace LSA.

[NetworkGroover]

Never mind - got a definitive answer on this, and if you're curious, the answer is yes the standby sup sends it.

Even in an unplanned outage scenario, as long as you're running SSO + GR, if you go and pull the active sup, the standby sup will send a grace LSA to continue normal forwarding while it fully spins up.

[that1guy15]

Just saw this.

Yup NSF and SSO handle this.

[wintermute000]

https://www.nanog.org/meetings/nanog42/presentations/Weissner_SSO.pdf


I don't think I'm reading things right or one of us is wrong (wouldn't be the first time... HA!) I just ran into a nasty ASA refuse to peer BGP bug due to choking on the GR capability negotiation sent by its upstream GR capable neighbor, so I just went through this stuff.


According to how I understand GR, its negotiated during neighbor setup (e.g. BGP GR capability). This can be GR capable or GR aware (helper).
If the capability is not negotiated (as seen in debugs, show ip bgp nei), then its not going to be used. Period.
If its negotiated then yes the standby sup would send the GR LSA or BGP message or whatever.

I do recall something about an alternative RFC where the device sends the GR message regardless (its in the preso somewhere but I CBF looking up what vendors use what RFC), perhaps  this is the confusion?

[that1guy15]

https://www.nanog.org/meetings/nanog42/presentations/Weissner_SSO.pdf


I don't think I'm reading things right or one of us is wrong (wouldn't be the first time... HA!) I just ran into a nasty ASA refuse to peer BGP bug due to choking on the GR capability negotiation sent by its upstream GR capable neighbor, so I just went through this stuff.


According to how I understand GR, its negotiated during neighbor setup (e.g. BGP GR capability). This can be GR capable or GR aware (helper).
If the capability is not negotiated (as seen in debugs, show ip bgp nei), then its not going to be used. Period.
If its negotiated then yes the standby sup would send the GR LSA or BGP message or whatever.

I do recall something about an alternative RFC where the device sends the GR message regardless (its in the preso somewhere but I CBF looking up what vendors use what RFC), perhaps  this is the confusion?

Grace full Restart per RFC is optional as you mentioned. But welcome to the wonderful land of vendors not following RFC. Just ran into similar between both Cisco and Arista peering with Fortinet.

I have never liked peering with firewalls as they usually suck at implementing routing protocols but times are changing and they need to start stepping up their game.

[NetworkGroover]

In the defense of vendors though.. I've run into more than one occasion where something as written in the RFC isn't exactly clear, nor makes any use of SHOULD or MUST statements... so then it's a free-for-all in how it's implemented.