I like using Cisco IOS for my routing protocol virtual labs¹. It uses a trivial amount of memory² and boots relatively fast. There was just one thing that kept annoying me: Cisco IOS release 15.x takes forever to install local routes in the BGP table and even longer to select the best routes and propagate them³.

I finally found the culprit: bgp update-delay nerd knob. Here’s what the documentation has to say about it:

When BGP is started, it waits a specified period of time for its neighbors to be established themselves and to begin sending their initial updates. Once that period is complete, or when the time expires, the best path is calculated for each route, and the software starts sending advertisements out to its peers.

Why would you want to do that? Back to documentation…

This behavior improves convergence time because, if the software were to start sending advertisements out immediately, it would have to send extra advertisements if it later received a better path for the prefix from another peer.

That makes perfect sense. It would be ridiculous to waste CPU cycles selecting the best routes based on incomplete information and telling everyone else about your wonderful “discovery” while the BGP table is still being updated with incoming messages. It’s much better to keep collecting incoming updates until the neighbors tell you they’re done (assuming they know what End-of-RIB marker is)⁴ and then do your job.

However, that procedure works well when a single router is restarted. As netlab starts lab devices in parallel and configures BGP on them at the same time, all BGP routers wait for everyone else to send them the updates. Obviously nothing happens until the bgp update-delay timer expires, everyone gives up, selects the current best routes (which happen to be locally originated routes), and forwards them to the neighbors… and we have fully synchronized BGP tables in a second.

The default value of bgp update-delay is 120 seconds – not unreasonable if you expect to receive full Internet routing table from a few BGP neighbors, but definitely way too long for a virtual lab. Adding bgp update-delay 5 to netlab Cisco IOS BGP configuration template turned a major annoyance back into a lovely experience.

Finally, keep in mind that what works best in a lab might not be suitable for production deployment. Don’t tweak this nerd knob in a production network unless you have an extremely good reason to do it, see also the comment by Mehdi SFAR.