Evaluating IGP and BGP Information Middle Convergence « ipSpace.internet weblog

A Thought Chief ^{lately revealed a LinkedIn article evaluating IGP and BGP convergence in knowledge middle materials. In it, they claimed that:}

iBGP designs would require route reflectors and extra processing, which may lead to barely slower convergence.

Let’s see whether or not that declare makes any sense.

TL&DR: No. For those who’re constructing a easy leaf-and-spine cloth, the selection of the routing protocol doesn’t matter (however you already knew that when you learn this weblog).

As I mentioned within the Quick Failover sequence, the general convergence time has these elements:

1. A failure needs to be detected.
2. The node detecting the failure has to report a change in community topology.
3. The change should be propagated throughout the community
4. Different nodes should recompute the very best paths based mostly on the brand new community topology
5. The brand new greatest paths should be put in within the forwarding tables.

In a fine-tuned community, steps #1 and #5 may take longer than steps #2..#4, making our dialogue as related because the well-known angels-on-pinhead one. Out of the field, most routing protocol implementations suck as a result of they’re nonetheless utilizing defaults from the Eighties^.

Lastly, we should differentiate between endpoint topology modifications (carried in IBGP and EBGP) and core topology modifications (carried in IGP or EBGP). As IBGP shouldn’t be concerned within the core topology modifications, the impression of route reflectors is zero, and the potential variations within the core community convergence rely solely on how fine-tuned your IGP or EBGP timers are.

BGP offers with the endpoint topology modifications in the identical manner no matter whether or not you employ IBGP route reflectors or EBGP-only design:

• An edge node detects a topology change and sends a BGP UPDATE message describing it.
• A backbone change or a route reflector (intermediate node) receives the BGP UPDATE message and modifies its BGP desk accordingly.
• The intermediate node selects the brand new greatest BGP path and stories the change in one other BGP replace to its neighbors. The BGP replace is often despatched instantly over IBGP classes and is perhaps delayed on EBGP classes as a result of default worth of the replace interval^.
• The method continues till the change notification reaches all the sting nodes.

Apparently, in a multi-stage leaf-and-spine cloth^{, an EBGP-only implementation is perhaps slower (not sooner) than an IBGP implementation with centralized route reflectors as a result of multihop replace propagation course of.}