Border Gateway Protocol (BGP) is one of the most important routing protocols on the Internet and within enterprise networks. It maintains routing tables and selects the best paths for traffic flows across networks. There are two types of BGP—external BGP (eBGP) and internal BGP (iBGP). While they serve complementary purposes, understanding the key differences between them is critical for network engineers.
External vs. Internal BGP
As its name suggests, external BGP handles routing between autonomous systems (AS)—groups of networks under single administrative control. In simple terms, eBGP enables routing between different organizations and ISPs across the Internet.
Meanwhile, internal BGP handles routing within an autonomous system. It enables routing between routers in the same organization or AS. iBGP allows the AS to share external and internal routes throughout its network so all routers can construct complete routing tables.
The Origins of Border Gateway Protocol
BGP first emerged in 1989 as a replacement for the obsolete Exterior Gateway Protocol (EGP) which had difficulty scaling across rapidly growing networks in the early days of the Internet. BGP provided several transformational capabilities including full, classless interdomain routing, policy controls, and integrated route authentication.
The creators of BGP realized early on that consolidating external peering and internal route distribution would introduce complex failure points and administrative challenges as global infrastructure expanded exponentially. This key insight led to the version split between external BGP for internet interconnects and internal BGP for intra-AS route exchange. Yet despite differences in implementation, the underlying protocol remains the same.
Autonomous Systems and Administrative Domains
An autonomous system (AS) represents a connected group of one or more IP prefixes managed by common network policies under singular administrative authority and control planes. In the early Internet, AS numbers corresponded one-to-one with large ISPs or backbone networks.
As the cyber-physical ecosystem has grown, so too has the diversity of organizations operating AS‘s — from local governments and universities to cloud computing giants running hundreds of thousands of systems concurrently. This geographic distribution at web-scale introduced new demands of resilience, vendor-neutrality and access equality for the aging standard exterior protocols.
After several failed piecemeal attempts to revamp compatibility while retaining availability across interlinked systems, BGP‘s clean separation of external versus internal routing domains presented a scalable and sustainable path forward based on reasonable abstraction layers.
eBGP vs iBGP: Key Differences
While eBGP and iBGP solve two sides of the same coin — flexible routing across the heterogeneous fabric of networks that comprise the modern Internet — their precise configuration and operation modalities differ significantly. Let‘s explore some key differentiators side-by-side:
Peering and Route Advertisement
eBGP neighbors must be directly connected since eBGP does not advertise routes to its iBGP or eBGP peers. Only routes learned from one AS are advertised to other ASes.
In contrast, iBGP neighbors can be multiple hops away within the network since routes are not readvertised to other iBGP peers.
TTL and Administrative Distance
eBGP messages use a short Time-To-Live (TTL) value of 1, allowing messages to reach only directly connected neighbors. This enhances security and reduces the chance of routing loops.
iBGP messages use the maximum TTL of 255, enabling communication between any routers in the AS regardless of hop count.
eBGP also has a lower default administrative distance of 20 versus iBGP‘s 200. So if both iBGP and eBGP routes exist, the router will prefer the eBGP route by default due to its lower administrative distance value.
Next Hop and Underlying Security
When eBGP advertises routes, it changes the next hop attribute to point to the local router as exit point from the AS. iBGP, however, preserves the next hop unchanged regardless of where route advertisement originates.
Also, eBGP peers often use MD5 authentication to verify identities, while iBGP relies on native security mechanisms within the internal network.
Topology and Loop Prevention
eBGP routing can work with any topology between ASes. But iBGP requires routers to be fully meshed with TCP sessions between all peers to share routing information.
For loop prevention:
- eBGP uses AS path to prevent routing loops
- iBGP uses split horizon to avoid sending learned iBGP routes back into the iBGP network
Example Configurations
To illustrate some of these concepts, consider the following simplified examples:
// eBGP peers connected via direct layer 2 link
router bgp 100
neighbor 10.10.10.2 remote-as 300
!
router bgp 300
neighbor 10.10.10.1 remote-as 100// iBGP peers multi-hopped across layer 3 core
router bgp 100
neighbor 10.10.10.2 remote-as 100
neighbor 10.10.10.2 update-source loopback0
neighbor 10.10.10.2 ebgp-multihop 5When to Use eBGP and iBGP
Use eBGP to enable routing:
- Between your organization‘s network and ISPs
- Between your company‘s separate campuses
- Over the public Internet
Use iBGP to enable routing:
- Between routers within your autonomous system
- Inside your organization‘s LAN and across multiple sites/campuses
So in summary:
- eBGP for external communication
- iBGP for internal communication
Unique Security Considerations
The intrinsic differences between eBGP and iBGP also inform their threat exposure and mitigation techniques.
For example, malicious BGP route hijacks are a common attack vector in eBGP connections to the public internet. Prefix filters, RPKI validation, MD5 authentication and other best practices help protect external peers.
Meanwhile configuration mistakes like iBGP loops or route reflector policies gone awry can take down the internal network. Rigorous testing procedures including assistance from commercial route validator tools should be adopted before deployment.
Implications for Scaling and Performance
The full mesh requirement in iBGP presents unique scaling obstacles within larger autonomous systems. Several optimizations exist including BGP Route Reflectors (RR) and BGP Confederations to relax this constraint. These architectural options come with their own convergence tradeoffs during network events.
According to Juniper Networks testing in a condensed lab topology, benchmark convergence times for eBGP stub failures run in the low single digit seconds. For iBGP RR designs, reconciliation duration is generally sub-second assuming proper protocol timers are configured. These numbers also depend significantly on the stability of the underlying data plane.
Ongoing Platform Innovations
Thanks to its resilience and adaptability, BGP remains a continually evolving protocol even 30 years later.
Active working groups continue developing new extensions like BGPSec which adds a level of cryptographic assurance to prevent spoofing and hacking. Other promising upgrades strive to improve operational stability during maintenance cycles or software upgrades via graceful restart and non-stop routing.
On the implementation side, leading networking vendors like Cisco and Arista allow extensive customization around path attributes, traffic engineering policies and advanced monitoring. Meanwhile SDN architectures and cloud-based virtual network services facilitate programmatic interfaces to interact with the complex BGP domain.
Key Takeaways
Clearly, eBGP and iBGP serve distinct yet complementary purposes. eBGP handles inter-domain routing, enabling connectivity to the Internet. iBGP handles intra-domain routing, facilitating connectivity inside a local network.
Modern networks leverage both protocols simultaneously to enable seamless, reliable connectivity within and across organizational boundaries.
