BGP Fundamentals

BGP is a path vector protocol that exchanges full autonomous system paths between routers to enable inter-domain routing across the internet [1]. It operates as a Layer 7 application over TCP port 179 [1, 5], using a rich attribute set for policy-driven route selection [1]. This chapter covers BGP’s protocol classification, the role of ASBRs, the administrative distance mechanism that prevents redistribution loops, BGP’s OSI placement, and eBGP peering over loopback interfaces.

Content

Protocol Classification: Path Vector

BGP is commonly described as an “advanced distance vector” protocol, but the precise term is path vector. Classical distance vector protocols such as RIP advertise only a metric (hop count) toward each destination. BGP extends this model fundamentally: every route advertisement carries the complete AS_PATH — the ordered list of autonomous systems the route has traversed [1].

The AS_PATH serves double duty. It is both the primary loop-prevention mechanism (a router that sees its own AS number in the path silently drops the route) and a coarse metric for path selection (shorter AS paths are preferred, all else being equal) [1, 4].

Beyond the AS_PATH, BGP carries a set of path attributes that enable fine-grained routing policy:

Attribute	Scope	Selection Rule	Primary Use
WEIGHT	Local to router (Cisco)	Highest wins	Override all other attributes locally [6]
LOCAL_PREF	Intra-AS	Highest wins	Steer outbound traffic across exit points [1]
AS_PATH	Inter-AS	Shortest wins	Loop prevention + coarse path selection [1]
MED	Inter-AS hint	Lowest preferred	Suggest entry point to neighboring AS [1]
NEXT_HOP	Per-route	Must be reachable	IP of next-hop router for the prefix [1]

BGP Best Path Selection Order

WEIGHT → LOCAL_PREF → locally originated → shortest AS_PATH → lowest origin type → lowest MED → eBGP over iBGP → lowest IGP metric to next-hop → oldest route → lowest router ID

This is the Cisco simplified ordering; the full IOS algorithm has 13 steps (cluster-list length and lowest-neighbor-IP appear after router-ID) [6].

Unlike RIP or EIGRP, BGP does not perform periodic full-table dumps. It runs over TCP (port 179), sends a full table only at session establishment, and thereafter transmits incremental updates as the routing table changes [1].

Autonomous System Boundary Router (ASBR)

An ASBR is a router that sits at the edge of an autonomous system and connects it to one or more external ASes. It is the gateway between an internal routing domain and the wider internet.

The term appears in two contexts with slightly different implications:

OSPF context. Any OSPF router that injects external routes into the OSPF domain qualifies as an ASBR. It does this by redistributing routes learned from another protocol (BGP, EIGRP, static) into OSPF, which generates Type 5 (or Type 7 in NSSA areas) external LSAs. A typical example is a router running OSPF internally and BGP toward an upstream ISP — it takes BGP-learned prefixes and redistributes them into OSPF.

BGP context. The ASBR is the router that maintains eBGP sessions with peers in other autonomous systems [4]. It is the enforcement point for inter-AS routing policy: prefix filters, AS_PATH manipulation, community tagging, and MED advertisement all happen here [4, 8].

A single physical router may simultaneously serve as an ASBR, an ABR (Area Border Router bridging OSPF areas), and a DR (Designated Router on a multi-access segment). These roles are independent and determined by the network topology.

Administrative Distance: eBGP 20, iBGP 200

Cisco IOS assigns different administrative distances to routes learned via eBGP and iBGP:

Source	AD	Rationale
eBGP	20	Learned directly from an external peer — high trust [7]
OSPF	110	Standard IGP [7]
iBGP	200	Learned internally from another BGP speaker — low trust [7]

The large gap between iBGP (200) and OSPF (110) is not arbitrary. It exists specifically to prevent routing loops in networks that perform mutual redistribution between BGP and an IGP [7, 10].

Topology context. Consider two ASBRs (ASBR1 and ASBR2) within the same AS, both running eBGP toward AS 200 and OSPF internally. AS 200 advertises 10.0.0.0/8. Both ASBRs learn this prefix via eBGP at AD 20. Internally, an OSPF domain connects the ASBRs and their downstream routers at AD 110. iBGP sessions between the ASBRs carry the same prefix at AD 200.

graph TD
    AS200["AS 200<br/>External advertises<br/>10.0.0.0/8"]
    ASBR1["ASBR1"]
    ASBR2["ASBR2"]
    INT["Internal Router (OSPF)"]

    AS200 -->|"eBGP AD=20"| ASBR1
    AS200 -->|"eBGP AD=20"| ASBR2
    ASBR1 <-->|"iBGP AD=200"| ASBR2
    ASBR1 -->|"OSPF AD=110"| INT
    ASBR2 -->|"OSPF AD=110"| INT

Under normal conditions, the eBGP-learned route (AD 20) wins on both ASBRs. The iBGP copy exists in the BGP table but is never installed in the routing table because its AD is higher than both the eBGP and OSPF alternatives.

The Mutual Redistribution Loop

A straightforward iBGP topology does not loop. The dangerous scenario requires mutual redistribution between BGP and OSPF on both ASBRs — a common pattern in enterprise networks that need external reachability through OSPF.

The failure sequence:

sequenceDiagram
    participant AS200 as AS 200
    participant ASBR1
    participant ASBR2
    participant OSPF as OSPF Domain

    AS200->>ASBR1: eBGP: prefix P (AD 20)
    ASBR1->>OSPF: Redistribute P into OSPF (external LSA)
    OSPF->>ASBR2: P via OSPF (AD 110)
    ASBR2->>ASBR1: Redistribute P back into iBGP (AD 200)
    Note over AS200,ASBR1: eBGP session drops (link failure)
    Note over ASBR1: Holds iBGP echo (AD 200) → points to ASBR2
    Note over ASBR2: Holds OSPF external (AD 110) → points to ASBR1
    ASBR1-->>ASBR2: Forwarding loop!
    ASBR2-->>ASBR1: Packets bounce until TTL expires

1. ASBR1 learns prefix P via eBGP and redistributes it into OSPF as an external LSA.
2. ASBR2 receives P through OSPF and redistributes it back into BGP.
3. This “echoed” route propagates via iBGP back to ASBR1.
4. ASBR1’s eBGP session drops (link failure, peer reset).
5. ASBR1 still holds the iBGP echo at AD 200, pointing toward ASBR2.
6. ASBR2 holds the OSPF external route, pointing back toward ASBR1.
7. A forwarding loop forms: packets bounce between ASBR1 and ASBR2 until TTL expires.

Why AD 200 Prevents the Loop

When ASBR1 loses its eBGP route, the iBGP echo (AD 200) is evaluated against the OSPF external (AD 110). Since 200 > 110, the iBGP echo is never installed — the loop cannot form.

Why AD 200 prevents the loop. When ASBR1 loses its eBGP route, it evaluates the iBGP echo (AD 200) against any remaining OSPF external route (AD 110). Because 200 exceeds 110, the iBGP echo is never installed. Without a forwarding entry pointing at ASBR2, the loop cannot form. OSPF convergence then cleans up the stale external LSA normally.

If iBGP’s AD were lower than OSPF’s — say, 30 — the iBGP echo would win (30 < 110), and the loop would persist. In the worst case, mutual redistribution makes the loop self-sustaining: ASBR2 re-redistributes the iBGP echo into OSPF as a fresh external LSA, which ASBR1 picks up, which keeps the iBGP echo alive. AD 200 breaks this cycle at the root by ensuring the echo route never influences the forwarding table.

Why OSPF Convergence Alone Is Insufficient

Two factors make AD manipulation necessary rather than relying on OSPF to eventually flush stale routes:

Transient window. After ASBR1’s eBGP session drops, a chain of convergence events must complete: iBGP withdrawal propagation, OSPF LSA flush, LSA flooding to all routers, SPF recalculation on ASBR2, and finally ASBR2’s BGP withdrawal. During this window — which may last seconds in a large OSPF domain — both routers hold stale forwarding entries pointing at each other. Packets loop until TTL expiry.

Self-sustaining echo. With mutual redistribution, the loop can become permanent. ASBR2 redistributes the iBGP echo back into OSPF as a new external LSA (originated by ASBR2, not ASBR1). ASBR1 installs this new LSA. The iBGP echo now feeds off ASBR2’s redistribution rather than ASBR1’s original, and OSPF convergence never removes it because the LSA is continuously refreshed. AD 200 eliminates this failure mode entirely.

BGP and the OSI Model

BGP operates at Layer 7 (Application Layer) of the OSI model. It establishes a TCP session on port 179 between peers [1, 5], and any protocol that runs on top of TCP is by definition an application-layer protocol — the same classification as HTTP, SSH, or FTP.

This creates an important distinction:

• Function: BGP makes Layer 3 routing decisions (which prefixes are reachable, through which next hop).
• Transport: BGP communicates as a Layer 7 application, riding TCP (Layer 4) over IP (Layer 3).

Compare this with OSPF and EIGRP, which run directly over IP using protocol numbers 89 and 88 respectively [5]. Those protocols must implement their own reliability mechanisms (acknowledgments, retransmission, sequencing). BGP inherits all of this from TCP — a critical advantage when exchanging hundreds of thousands of routes across the global internet, where packet loss and reordering are routine [1].

eBGP Connected Check and Loopback Peering

By default, eBGP requires the configured neighbor IP to reside on a directly connected subnet [11]. The router verifies that the peer address is reachable through an interface exactly one hop away. This is a safety mechanism: eBGP sessions use a TTL of 1, so packets destined for a non-adjacent peer would be dropped in transit anyway [11].

Loopback peering disables this check to gain session resilience. When two ASes are connected by multiple parallel physical links, peering over loopback addresses ensures the BGP session survives any single link failure — the IGP reroutes traffic to the peer’s loopback via the surviving link(s) [9, 11].

Two configuration changes are required:

Parameter	Default	Loopback Peering Value	Purpose
disable-connected-check	Enabled (require connected subnet)	Disabled	Accept neighbor not on a directly connected subnet
ebgp-multihop <ttl>	TTL = 1	TTL = 2+	Allow BGP packets to traverse intermediate hops to reach remote loopback
update-source	Physical interface	Loopback0	Source TCP session from the stable loopback address

ebgp-multihop and disable-connected-check are not independently required

Configuring ebgp-multihop implicitly disables the connected-subnet check on Cisco IOS — the two knobs are not orthogonal [11]. In practice, ebgp-multihop 2 alone is sufficient for loopback peering; disable-connected-check is shown above for explicitness and for the rare case where you want to relax the connected check while keeping TTL = 1.

When to Use Loopback Peering

Use loopback peering when two ASes connect via multiple parallel physical links. The BGP session survives any single link failure because the IGP reroutes to the peer’s loopback via surviving links.

router bgp 100
 neighbor 2.2.2.2 remote-as 200
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 disable-connected-check
 neighbor 2.2.2.2 ebgp-multihop 2

The update-source Loopback0 directive ensures BGP uses the local loopback as the source address for the TCP session, matching what the remote peer expects.

References

1. RFC 4271 — A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li, S. Hares (Eds.), IETF, January 2006. https://www.rfc-editor.org/rfc/rfc4271
2. RFC 7606 — Revised Error Handling for BGP UPDATE Messages. E. Chen et al., IETF, August 2015. https://www.rfc-editor.org/rfc/rfc7606
3. RFC 5492 — Capabilities Advertisement with BGP-4. J. Scudder, R. Chandra, IETF, February 2009. https://www.rfc-editor.org/rfc/rfc5492
4. RFC 1772 — Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross, IETF, March 1995. https://www.rfc-editor.org/rfc/rfc1772
5. IANA Protocol Numbers Registry. https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
6. Cisco — BGP Best Path Selection Algorithm (Doc 13753). https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
7. Cisco — Describe Administrative Distance (Doc 15986). https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html
8. S. Halabi, Internet Routing Architectures, 2nd ed., Cisco Press, 2000.
9. I. van Beijnum, BGP, O’Reilly, 2002.
10. J. Doyle & J. Carroll, Routing TCP/IP, Volume II, 2nd ed., Cisco Press, 2016.
11. B. Edgeworth, A. Foss, R. Garza Rios, IP Routing on Cisco IOS, IOS XE, and IOS XR, Cisco Press, 2014.