02 eBGP vs iBGP

BGP peer relationships come in two types, determined entirely by whether the two peers are in the same Autonomous System or in different ones. The protocol behaves differently in each case, so understanding this distinction is the foundation for most later BGP topics.

The core distinction

The peer type is derived from the AS numbers, not declared with a separate command:

• If both peers are in the same AS → the session is iBGP (Internal BGP).
• If the peers are in different AS → the session is eBGP (External BGP).

This is decided when the configured remote AS of a neighbor is compared against the local AS: the same value means iBGP, a different value means eBGP. There is no separate “router ibgp” command. Both types use identical syntax; the relationship is inferred from the AS comparison alone.

Behavioral differences

Many BGP behaviors change depending on the peer type. Each is covered in depth in its own note, but summarized here:

Behavior	eBGP	iBGP
Administrative Distance	20	200
Default TTL	1 (must be directly connected)	255 (multi-hop is normal)
AS-PATH on advertisement	Local ASN is prepended	AS-PATH is not changed
Next-hop on advertisement	Set to advertising router’s IP	Not modified by default
Loop prevention	AS-PATH (reject own ASN)	Split-horizon rule (no re-advertise)
Re-advertisement rule	Freely re-advertised	Routes from an iBGP peer are not sent to another iBGP peer

Why the peer type matters

• eBGP connects different administrative domains. Because peers are typically one hop apart, eBGP defaults to TTL 1 and prepends the AS-PATH, which also provides loop prevention between AS.
• iBGP distributes externally learned routes inside a single AS. Because AS-PATH is not modified between internal peers (same ASN), AS-PATH cannot detect internal loops. This forces a different loop-prevention mechanism (the iBGP split-horizon rule) and drives the need for full-mesh, route reflectors, and confederations.

Directly connected vs multi-hop

• eBGP peers are expected to be directly connected (one hop) by default, because of TTL 1.
• iBGP peers are frequently not directly connected; they reach each other through the internal IGP. For this reason iBGP sessions are commonly sourced from loopback interfaces, so the session survives the failure of any single physical link as long as the IGP still has a path to the loopback.

Self-check

Q1 — What determines whether a BGP session is eBGP or iBGP?

A) A dedicated router ibgp or router ebgp command
B) Whether the peers are directly connected or not
C) Whether the neighbor’s remote AS matches the local AS or not
D) The Administrative Distance configured on the neighbor

Respuesta

C is correct. If the neighbor’s remote AS equals the local AS it is iBGP; if different, it is eBGP. The type is inferred from the AS comparison.

• A) False — there is no separate command; both types use identical syntax.
• B) False — connectivity does not define the type; iBGP peers are often multi-hop and eBGP can be multi-hop too.
• D) False — AD is a consequence of the peer type, not what sets it.

Q2 — What are the default TTL values for eBGP and iBGP, and what do they imply?

A) eBGP 255, iBGP 1 — eBGP is multi-hop by default
B) eBGP 1, iBGP 255 — eBGP expects a directly connected peer
C) Both default to 1
D) Both default to 255

Respuesta

B is correct. eBGP defaults to TTL 1, so the peer must be one hop away (directly connected); iBGP uses a high TTL, so multi-hop peering through the IGP is normal.

• A) False — the values are reversed.
• C) False — only eBGP defaults to TTL 1; iBGP does not.
• D) False — eBGP does not default to 255; that is why ebgp-multihop exists.

Q3 — Why can AS-PATH not be used for loop prevention inside an AS (iBGP)?

A) Because iBGP does not use AS-PATH at all
B) Because the AS-PATH is stripped between iBGP peers
C) Because AS-PATH is not modified between iBGP peers, so a loop inside the AS would not add a detectable ASN
D) Because iBGP uses Weight instead of AS-PATH

Respuesta

C is correct. Between iBGP peers the AS-PATH is not changed (same ASN), so it cannot reveal an internal loop. This is why iBGP needs the split-horizon rule instead.

• A) False — iBGP routes still carry an AS-PATH; it just is not modified internally.
• B) False — the AS-PATH is not stripped, only left unchanged.
• D) False — Weight is a local best-path attribute, unrelated to loop prevention.

Q4 — What is the iBGP split-horizon (re-advertisement) rule?

A) A route learned from an iBGP peer is not advertised to another iBGP peer
B) A route learned from an iBGP peer is advertised to all other iBGP peers
C) A route learned from an eBGP peer is never advertised to iBGP peers
D) iBGP peers must always be directly connected

Respuesta

A is correct. Routes learned from one iBGP peer are not passed to another iBGP peer. This prevents internal loops but forces full-mesh, and drives route reflectors and confederations.

• B) False — that is exactly what the rule forbids.
• C) False — eBGP-learned routes are advertised to iBGP peers normally.
• D) False — iBGP peers are frequently multi-hop through the IGP.