Maintain prefixes even when bgp peer goes down

Question

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.

Answer 1

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.

Configuration

For Brocade Vyatta Routers

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

For Brocade IOS Routers

To enable globally

router bgp
 graceful-restart

To enable per-vrf

router bgp
 address-family ipv4 unicast vrf test
  graceful-restart

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.

Answer 2

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.