Is there a way to maintain the BGP prefixes a router has learned from another device even when reachability to the peer drops so that bgp doesn't need to withdraw all the routes and then relearn them?

I'm running into an issue sometimes when connectivity drops from high cpu load for various reasons and then the ibgp session goes down; at that point, all routes are withdrawn and then relearned when the session gets reestablished, but it takes way too long.

I currently run ibgp between 2 core devices and ospf to advertise the loopbacks; I need solutions for brocade.

  • 2
    FYI the accepted answer does not help the situation you described. Graceful Restart only helps when the bgp router proactively warns its neighbor about a pending reload. AFAIK the random outages you described are not mitigated with GR. See the RFC for specifics Aug 2, 2014 at 1:54

2 Answers 2


BGP graceful-restart is the mechanism that you are looking for.

Graceful-restart maintains forwarding for the routes that have been received from a BGP neighbor while the connection is being restarted. When the neighbor drops, the routes will be marked Stale (S) in the BGP table and will still be available for route selection.

There are two timers that are associated with graceful-restart:

  • stalepath time - maximum amount of time to hold onto stale routes
  • restart time - maximum amount of time to wait for neighbor to come back up

BGP graceful-restart capability is advertised in the BGP OPEN message. This means that if you do decide to use it, you will have to restart the BGP connection for each neighbor before it will work.

Probably shouldn't use graceful-restart if you are also using BFD on the link as it can cause issues.


For Brocade Vyatta Routers

set protocols bgp 65000 parameters graceful-restart [stalepath-time seconds]

For Brocade IOS Routers

To enable globally

router bgp

To enable per-vrf

router bgp
 address-family ipv4 unicast vrf test

Bonus Round

Vyatta routers let you dynamically advertise new capabilities for BGP, this allows you to test options without risking the BGP session not coming up. The following needs to be configured:

set protocols bgp [ASN] [neighbor address] capability dynamic

You can then configure graceful-restart without resetting the BGP peering.

  • Hi mbud, thanks for the info. I actually found out about this command as well. This is for foundry/brocade gear. Jul 31, 2014 at 22:59
  • mbud, I am afraid that GR would not help this problem Aug 2, 2014 at 1:59

If you are unable to stabilize your bgp sessions with longer timeouts or similar, here is a hack I have been forced to use on a few occations:

If there are only a limited number of routes, and you have a stable environment without too many regular changes, you could insert static routes with higher preference/cost than the bgp routes. When the bgp sessions drop, the static routes will become active.

However, I would regard this as a "nasty hack" to stabilize an unstable environment, and not in any way a good permanent solution. You should really fix the CPU issue causing all the problems.

  • Hi Sven, thanks for the tip. I've thought of this however I'd rather not have to do this as it's not ideal. The problem arises when bgp reconverges and it takes way too long to receive all the routes. The cpu's are only 400Mhz which is part of the problem. The cpu spikes to 99-100% and causes the ospf adjacencies to break which then cause the ibgp sessions to break as well. I guess I need to check out the ospf timers, etc to see if there is something I can do. Thanks again Jul 31, 2014 at 21:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.