A Thought Leader¹ recently published a LinkedIn article comparing IGP and BGP convergence in data center fabrics². In it, they³ claimed that:

iBGP designs would require route reflectors and additional processing, which could result in slightly slower convergence.

Let’s see whether that claim makes any sense.

TL&DR: No. If you’re building a simple leaf-and-spine fabric, the choice of the routing protocol does not matter (but you already knew that if you read this blog).

As I discussed in the Fast Failover series, the overall convergence time has these components:

1. A failure has to be detected.
2. The node detecting the failure has to report a change in network topology.
3. The change must be propagated across the network
4. Other nodes must recompute the best paths based on the new network topology
5. The new best paths must be installed in the forwarding tables.

In a fine-tuned network, steps #1 and #5 could take longer than steps #2..#4, making our discussion as relevant as the famous angels-on-pinhead one. Out of the box, most routing protocol implementations suck because they’re still using defaults from the 1980s⁴.

Finally, we must differentiate between endpoint topology changes (carried in IBGP and EBGP) and core topology changes (carried in IGP or EBGP). As IBGP is not involved in the core topology changes, the impact of route reflectors is zero, and the potential differences in the core network convergence depend solely on how fine-tuned your IGP or EBGP timers are.

BGP deals with the endpoint topology changes in the same way regardless of whether you use IBGP route reflectors or EBGP-only design:

• An edge node detects a topology change and sends a BGP UPDATE message describing it.
• A spine switch or a route reflector (intermediate node) receives the BGP UPDATE message and modifies its BGP table accordingly.
• The intermediate node selects the new best BGP path and reports the change in another BGP update to its neighbors. The BGP update is usually sent immediately over IBGP sessions and might be delayed on EBGP sessions due to the default value of the update interval⁵.
• The process continues until the change notification reaches all the edge nodes.

Interestingly, in a multi-stage leaf-and-spine fabric⁶, an EBGP-only implementation might be slower (not faster) than an IBGP implementation with centralized route reflectors due to the multihop update propagation process.