eBGP and iBGP

Stands for: external BGP and internal BGP

The two kinds of BGP session: external, between routers in different autonomous systems, and internal, within one.

RFC 4271 calls a peer in a different AS external and one in the same AS internal, abbreviated EBGP and IBGP. The session type changes the rules: what a speaker adds to a route, which attributes travel, which route wins a tie and, inside the AS, a requirement that every speaker peer with every other.

On an eBGP session a speaker prepends its own AS number to the AS_PATH and by default puts the address it uses for that session in NEXT_HOP; towards an internal peer it must not modify the AS_PATH. LOCAL_PREF goes to internal peers only and must not be sent to external ones, except within a confederation. In the decision process, if any candidate was received over eBGP, the iBGP-learned routes are removed. RFC 4271 also suggests a slower advertisement pace for eBGP, 30 seconds, than for iBGP, 5 seconds.

The full-mesh rule comes from one sentence of section 9.2: a speaker that receives an UPDATE from an internal peer shall not re-distribute it to other internal peers, unless it acts as a route reflector. Every iBGP speaker must therefore peer with every other, n(n-1)/2 sessions for n speakers: 45 for ten, 4,950 for a hundred. RFC 4456 says the requirement clearly does not scale.

Two remedies replace the mesh. Route reflection (RFC 4456) lets chosen speakers pass iBGP routes on to their clients; a confederation (RFC 5065) splits the AS into member ASes that appear as one AS from outside, so the sessions inside follow the inter-domain model. Since RFC 8212 (July 2017), an eBGP session with no explicit import or export policy accepts and sends nothing.

Also known as: ebgp, ibgp, external bgp, internal bgp, ibgp full mesh, bgp full mesh

Sources

← All glossary entries