BGP operates in two fundamentally different modes depending on whether peers are in the same Autonomous System or different ones. External BGP (eBGP) connects different ASes across organizational boundaries. Internal BGP (iBGP) distributes external routing information within an AS.

Although both use the same protocol messages and attributes, their behaviors differ significantly. Understanding these differences is crucial for designing scalable BGP deployments, troubleshooting routing issues, and avoiding common pitfalls that trap inexperienced network engineers.

The distinction between eBGP and iBGP is based on a simple criterion: do the peers share the same AS number?

This simple difference triggers cascading behavioral changes designed to prevent routing loops and enable scalable operation.

eBGP sessions connect different Autonomous Systems. They are the glue that holds the Internet together, enabling routing information to flow between organizations.

eBGP Session Characteristics:

1. Direct Connectivity Requirement

By default, eBGP peers must be directly connected (TTL=1 in IP packets). This is a security feature—it ensures peers are actually adjacent and not spoofed from elsewhere.

However, multihop eBGP allows peering over multiple network hops:

neighbor 192.0.2.1 remote-as 65002
neighbor 192.0.2.1 ebgp-multihop 3

Multihop is used when peering via loopbacks or across intermediate devices.

2. AS_PATH Prepending

When advertising a route via eBGP, the local AS number is prepended to the AS_PATH. This:

• Provides loop prevention (receiving AS sees sender's ASN)
• Increases path length for downstream path selection
• Documents the route's traversal history

3. NEXT_HOP Setting

When advertising to an eBGP peer, NEXT_HOP is set to the local router's interface address (or update-source if configured). This ensures the receiving AS can reach the advertising router.

4. eBGP Load Balancing

With multiple eBGP sessions to the same destination AS, load balancing is possible:

router bgp 65001
  maximum-paths 4              ! Up to 4 equal-cost eBGP paths
  maximum-paths ibgp 4         ! Up to 4 equal-cost iBGP paths

For paths to be considered equal, they must have identical:

• Weight, LOCAL_PREF, AS_PATH length, ORIGIN, MED (if same AS)
• Same neighboring AS for the first hop

iBGP sessions connect routers within the same Autonomous System. Their purpose is to distribute routing information learned from eBGP peers to all routers that need it.

Why Do We Need iBGP?

Consider an AS with two edge routers (R1 and R2) receiving routes from external peers:

1. R1 learns route X via eBGP from AS 65002
2. R2 needs to know about route X to make forwarding decisions
3. IGP (OSPF/IS-IS) can't carry BGP routes (wrong protocol, wrong scale)
4. iBGP distributes BGP routes between R1 and R2

iBGP Session Characteristics:

The iBGP Split-Horizon Rule:

The critical iBGP behavior is the split-horizon rule:

A route learned from an iBGP peer is not re-advertised to other iBGP peers.

This prevents routing loops within the AS. Without AS_PATH prepending (since ASN is unchanged), loops could form if routes were freely re-advertised.

The Problem This Creates:

The split-horizon rule means that every iBGP router must peer directly with every other iBGP router—a full mesh.

Route Reflectors (RRs) are the most common solution to iBGP scaling. They relax the split-horizon rule, allowing designated routers to "reflect" routes between iBGP peers.

Route Reflector Concept:

Instead of full mesh, routers peer with Route Reflectors:

• Route Reflector: A router that reflects routes between iBGP peers
• Client: A router that peers with the RR (not full mesh with others)
• Non-Client: A router that peers normally (full mesh among non-clients)

Reflection Rules:

Loop Prevention in RR:

Route reflectors introduce two attributes for loop prevention:

1. ORIGINATOR_ID

• Set by the RR to the Router ID of the route's originator
• If a router receives a route with its own ORIGINATOR_ID, the route is discarded

2. CLUSTER_LIST

• Each RR adds its CLUSTER_ID when reflecting
• If a router receives a route with its own CLUSTER_ID in CLUSTER_LIST, the route is discarded
• Prevents loops in hierarchical RR designs

RR Design Best Practices:

Confederations are an alternative iBGP scaling solution that divides an AS into smaller sub-ASes. To the outside world, the confederation appears as a single AS.

Confederation Concept:

• The AS is divided into member ASes (sub-ASes)
• Within each member AS: normal iBGP rules apply (full mesh or RR)
• Between member ASes: eBGP-like sessions (AS_PATH modification)
• To external peers: confederation appears as single AS

How It Works:

Confederation AS_PATH Handling:

Confederation sessions modify AS_PATH, but use special segment types:

Key Behaviors:

1. Within confederation, sub-AS numbers appear in AS_PATH (as CONFED segments)
2. When advertising externally, CONFED segments are stripped
3. External peers see only the confederation's public ASN
4. CONFED segments don't count toward AS_PATH length for best path selection

Example AS_PATH transformation:

Understanding operational differences between eBGP and iBGP is critical for troubleshooting. Here are the most common issues and their diagnosis:

Common eBGP Issues:

Common iBGP Issues:

Building a robust BGP deployment requires careful attention to both eBGP and iBGP design. Here are consolidated best practices:

Scalability Guidelines:

Session Monitoring:

Always monitor:

• BGP session state (Established vs other states)
• Prefix count (sudden changes indicate issues)
• Memory usage (large tables consume RAM)
• CPU utilization (path computation spikes)
• Session uptime (frequent flaps indicate instability)

The distinction between eBGP and iBGP is fundamental to understanding BGP operation. Let's consolidate the key lessons:

Module Complete:

With this page, you have completed the comprehensive study of BGP. You now understand:

• BGP's role as the inter-domain routing protocol of the Internet
• Path vector routing and its advantages over distance vector and link state
• The AS_PATH attribute and its critical functions
• The full complement of BGP path attributes and their roles in the decision process
• The fundamental differences between eBGP and iBGP and how to design scalable BGP networks

This knowledge forms the foundation for working with routing in enterprise networks, service provider environments, cloud architectures, and beyond.