In BGP, what distinguishes an eBGP session from an iBGP session, and how does each one treat the routes it passes on?
answer
- same AS or different AS
- who touches AS_PATH
- who rewrites NEXT_HOP
- LOCAL_PREF stays inside
- internal routes are not relayed internally
basics
~20 seBGP joins speakers in different autonomous systems, iBGP speakers in the same one. eBGP prepends the sender's AS number and normally rewrites NEXT_HOP; iBGP changes neither and, outside route reflection, does not relay one iBGP peer's routes to another.
solid answer
~50 sIt is one protocol with two kinds of neighbour, decided only by whether the peer's AS number equals yours. Over an **eBGP** session (a peer in another AS) the speaker prepends its own AS number to `AS_PATH`, normally sets `NEXT_HOP` to its own address, and must not send `LOCAL_PREF`. Over an **iBGP** session (a peer in the same AS) RFC 4271 says it does not modify `AS_PATH`, should not modify `NEXT_HOP` unless configured to, and must include `LOCAL_PREF`. The rule that shapes iBGP designs: a route learned from one internal peer is never passed to another internal peer, so every BGP speaker in the AS must hear external routes directly from the border router that learned them, a full mesh, unless route reflectors or a confederation relax it. eBGP peers are usually directly connected; iBGP peers are usually loopbacks reached through the IGP.
go deeper
Know the one-line definition: eBGP connects different autonomous systems, iBGP connects BGP routers inside the same one, and the AS number of the peer is what decides it.
Explain what each session does to AS_PATH, NEXT_HOP and LOCAL_PREF, and state the no-relay rule for iBGP-learned routes and why it follows from the AS_PATH loop check.
Connect the rules to failures you have seen: unreachable next hops after a border change, missing routes when a router was left out of the mesh, sessions that died with one interface because they peered on it.
Frame the iBGP design choice for the whole AS: full mesh, route reflectors or a confederation, and what each costs in sessions, path diversity and migration effort as the network grows.
## One protocol, two kinds of neighbour BGP-4 (RFC 4271) calls a peer in a different **autonomous system (AS)** an *external peer* and a peer in the same AS an *internal peer*; the sessions are abbreviated **eBGP** and **iBGP**. Nothing else distinguishes them: the same TCP transport on port 179, the same messages, the same attributes. What differs is what a speaker is required to do to a route as it crosses each kind of session. The split exists because the two sessions have different jobs: - **eBGP** exchanges reachability between organisations. Each hop crosses an administrative boundary, so the route must record that boundary and point at a router the neighbour can actually reach. - **iBGP** distributes what the border routers learned to every other BGP speaker inside the same AS, so that all of them make consistent decisions. RFC 4271 section 3 assumes a consistent view is provided "by having all BGP speakers within the AS maintain IBGP with each other". ## What changes on an eBGP hop When a speaker in AS 64500 advertises a route to a speaker in AS 64501: 1. **`AS_PATH` gains an entry.** The sender prepends its own AS number (RFC 4271 section 5.1.2). This is BGP's loop prevention: a receiver that finds its own AS number already in the path discards the route. 2. **`NEXT_HOP` normally becomes the sender.** By default it is the address of the interface the sender uses for the session (section 5.1.3), so the receiver forwards traffic to the router it peers with. A "third-party" next hop is allowed when the receiver shares a subnet with a better router. 3. **`LOCAL_PREF` is withheld.** A speaker MUST NOT send it to external peers, and a receiver ignores it if one arrives (section 5.1.5), with confederations as the stated exception. ## What stays the same on an iBGP hop When the border router passes that route to a colleague in its own AS: - **`AS_PATH` is untouched** ("SHALL NOT modify"). A locally originated route is even sent with an empty `AS_PATH`. - **`NEXT_HOP` is left as received** ("SHOULD NOT modify") unless the speaker is explicitly configured to put its own address there, the setting usually called *next-hop-self*. Otherwise interior routers must reach the external neighbour's address through the IGP. - **`LOCAL_PREF` is mandatory** on every UPDATE to internal peers, so the whole AS agrees on which exit it prefers. - **Routes from one internal peer go to no other internal peer** (section 9.2: "SHALL NOT re-distribute", unless the speaker is a route reflector). ## Side by side | | eBGP session | iBGP session | |---|---|---| | Peer's AS | different | same | | `AS_PATH` on send | own AS prepended | unchanged | | `NEXT_HOP` on send | normally the sender's address | unchanged by default | | `LOCAL_PREF` | not sent; ignored if received | required | | Relay of routes learned on this kind of session | to internal and external peers | to external peers only | | Typical peering address | interface on a shared link | loopback reached via the IGP | ## Why the asymmetry exists The `AS_PATH` loop check only works when something is added at each hop. Inside one AS nothing is added, so a route relayed from internal peer to internal peer would carry no trace of having circulated. The no-relay rule closes that hole, and it is why an AS with many BGP speakers needs either a **full mesh** of iBGP sessions (n(n-1)/2 of them) or a sanctioned exception: **route reflectors** (RFC 4456) or a **confederation** (RFC 5065). The peering addresses differ for practical reasons. An eBGP neighbour usually sits at the far end of one link, and many implementations send eBGP packets with a TTL of 1 by default so a session cannot form with anything farther away; that is an implementation choice, not an RFC 4271 rule. iBGP speakers are often several routers apart, so they peer between **loopback addresses** that the IGP keeps reachable over any surviving path. ## Common misreadings - iBGP is not "BGP used as an IGP". It carries external routes across the AS; the IGP still carries the AS's own links and loopbacks. - A session's type does not depend on the physical topology. Two routers on one cable in the same AS are iBGP peers; two routers several hops apart in different ASes are eBGP peers (*multihop eBGP*). - Preferring an eBGP-learned route over an iBGP-learned one is a later tie-breaker in the decision process, not part of what defines the session.
- If iBGP never changes AS_PATH, how does the AS avoid loops for routes it learned externally?Loops between ASes are still caught at the eBGP edge: a border router discards any route whose `AS_PATH` already holds its own AS number. Inside the AS the protection is structural: because an iBGP-learned route is never relayed to another internal peer, a route cannot circulate among internal speakers. Route reflectors relax that rule and so add their own loop attributes, `ORIGINATOR_ID` and `CLUSTER_LIST`.
- Why does an iBGP session usually run between loopback addresses rather than interface addresses?A loopback is not tied to any one physical link, and the IGP advertises it over every path that exists. If the link carrying the session fails, the IGP reroutes to the loopback and the TCP session survives. Peering on an interface address would tear the session down with that one interface, even though the two routers can still reach each other.
- Does an iBGP router send LOCAL_PREF to an eBGP neighbour if the policy sets it?No. RFC 4271 section 5.1.5 says a speaker MUST NOT include `LOCAL_PREF` in UPDATEs to external peers and a receiver MUST ignore it if one arrives, with BGP confederations as the only exception. It is an AS-internal signal about which exit to prefer; to influence a neighbour you use other attributes or communities.
saying these in an interview costs you the question
- eBGP and iBGP are different protocols with different message formats
- iBGP is just BGP used as the interior routing protocol
- Every BGP hop prepends the AS number, including iBGP hops
- Two routers on the same cable must be eBGP peers
- An iBGP router relays routes to all its iBGP peers like a distance-vector protocol
- LOCAL_PREF is sent to the upstream provider to choose its path