Skip to main content

5.1. Choosing EBGP as the Routing Protocol

5.1. Choosing EBGP as the Routing Protocol​

REQ2 would give preference to the selection of a single routing protocol to reduce complexity and interdependencies. While it is common to rely on an IGP in this situation, sometimes with either the addition of EBGP at the device bordering the WAN or Internal BGP (IBGP) throughout, this document proposes the use of an EBGP-only design.

Although EBGP is the protocol used for almost all Inter-Domain Routing in the Internet and has wide support from both vendor and service provider communities, it is not generally deployed as the primary routing protocol within the data center for a number of reasons (some of which are interrelated):

  • BGP is perceived as a "WAN-only, protocol-only" and not often considered for enterprise or data center applications.

  • BGP is believed to have a "much slower" routing convergence compared to IGPs.

  • Large-scale BGP deployments typically utilize an IGP for BGP next-hop resolution as all nodes in the IBGP topology are not directly connected.

  • BGP is perceived to require significant configuration overhead and does not support neighbor auto-discovery.

This document discusses some of these perceptions, especially as applicable to the proposed design, and highlights some of the advantages of using the protocol such as:

  • BGP has less complexity in parts of its protocol design -- internal data structures and state machine are simpler as compared to most link-state IGPs such as OSPF. For example, instead of implementing adjacency formation, adjacency maintenance and/or flow-control, BGP simply relies on TCP as the underlying transport. This fulfills REQ2 and REQ3.

  • BGP information flooding overhead is less when compared to link-state IGPs. Since every BGP router calculates and propagates only the best-path selected, a network failure is masked as soon as the BGP speaker finds an alternate path, which exists when highly symmetric topologies, such as Clos, are coupled with an EBGP-only design. In contrast, the event propagation scope of a link-state IGP is an entire area, regardless of the failure type. In this way, BGP better meets REQ3 and REQ4. It is also worth mentioning that all widely deployed link-state IGPs feature periodic refreshes of routing information while BGP does not expire routing state, although this rarely impacts modern router control planes.

  • BGP supports third-party (recursively resolved) next hops. This allows for manipulating multipath to be non-ECMP-based or forwarding-based on application-defined paths, through establishment of a peering session with an application "controller" that can inject routing information into the system, satisfying REQ5. OSPF provides similar functionality using concepts such as "Forwarding Address", but with more difficulty in implementation and far less control of information propagation scope.

  • Using a well-defined Autonomous System Number (ASN) allocation scheme and standard AS_PATH loop detection, "BGP path hunting" (see [JAKMA2008]) can be controlled and complex unwanted paths will be ignored. See Section 5.2 for an example of a working ASN allocation scheme. In a link-state IGP, accomplishing the same goal would require multi-(instance/topology/process) support, typically not available in all DC devices and quite complex to configure and troubleshoot. Using a traditional single flooding domain, which most DC designs utilize, under certain failure conditions may pick up unwanted lengthy paths, e.g., traversing multiple Tier 2 devices.

  • EBGP configuration that is implemented with minimal routing policy is easier to troubleshoot for network reachability issues. In most implementations, it is straightforward to view contents of the BGP Loc-RIB and compare it to the router's Routing Information Base (RIB). Also, in most implementations, an operator can view every BGP neighbors Adj-RIB-In and Adj-RIB-Out structures, and therefore incoming and outgoing Network Layer Reachability Information (NLRI) information can be easily correlated on both sides of a BGP session. Thus, BGP satisfies REQ3.

Last updated on