The Impact of BGP Update Delay

Consider a scenario where your network architecture features two redundant CE routers linked to two PE routers. In this setup, the PE routers are configured to transmit only the default route to the CE routers, particularly beneficial for Branch routers, which typically do not require the complete routing table

Now, what would happen if you reboot the PE Router ? :

How can this issue be resolved? we can consider using the BGP update-delay feature.

Cisco describes it as follow :

When BGP is started, it waits a specified period of time for its neighbors to establish peering sessions and to complete sending their initial updates. After all neighbors complete their initial updates, or after the update delay timer expires, the best path is calculated for each route, and the software starts sending advertisements out to its peers. This behavior improves convergence time. If the software were to advertise a route as soon as it learned it, it would have to readvertise the route each time it learned a new path that was preferred over all previously learned paths.

Use the bgp update-delay command to tune the maximum time the software waits after the first neighbor is established until it starts calculating best paths and sending out advertisements.

In summary :

• BGP update-delay optimizes network congestion by delaying BGP update messages, preventing overload, and unnecessary calculation cycles.
• The update-delay timer waits until after the FIRST neighbor is established before initiating its calculation
• The update-delay timer ceases after ALL peers have established neighboring connections and signaled the completion of their initial updates. (In Cisco IOS-XR, there’s an option called “always” that can be added, ensuring that the router always waits for the update delay time, regardless of whether all neighbors have completed sending their initial updates sooner)
  • In a scenario where two or more routers reboot simultaneously, they will adhere to the default timers (typically 120 seconds on Cisco) before initiating the update process. Therefore, caution is advised when considering the use of the “always” option
• The peer signals completion by transmitting a BGP Keepalive message, indicating that the sender has finished its updates and the best path computation can commence. Alternatively, in scenarios where Graceful Restart (GR) is negotiated, the End of Rib (EoR) message serves as an indicator of completion.
• The update-delay timer should be carefully considered, especially in multihoming scenarios. Depending on the number of peerings and routes involved, maintaining or even increasing the update-delay timer may be necessary in certain use cases.
• In a multihomed scenario where an unconditional default route is sent, you may need to increase the default 120-second timer to allow the router sufficient time to fully boot and converge with the IGP/BGP VPN routes before initiating the transmission of the default route (and I have encountered scenarios like this)
  • You can also use the “bgp nopeerup-delay”, but I didn’t test this feature.
• The “bgp update-delay” command in Cisco devices can only be set globally, affecting all peers and VRF instances uniformly.

By the way, I haven’t been able to test this in a virtual environment like EVE-NG using CSR1K or Cisco IOL. This is may be due to the presence of the “bgp nopeerup-delay” feature, which I couldn’t modify even with commands like “bgp nopeerup-delay cold-boot” and “bgp nopeerup-delay post-boot”. The only image that effectively demonstrated and tested this behavior was the IOS-XRv (or ASR9K) whether virtual or physical.

Are you considering tuning your network or do you have any questions about it? We can assist you. Please don’t hesitate to reach out to us through the CONTACT-US page or by emailing us at [email protected] for advise assistance.

Mehdi SFAR (CCDE 2021:3, CCIE #51583)