eBGP vs iBGP
eBGP connects different autonomous systems, while iBGP distributes routes inside one AS. Compare next-hop, AS-path, TTL and the typical role of each mode.
Last updated:
eBGP (external BGP) is a BGP session between routers in different autonomous systems. iBGP (internal BGP) is a session between routers inside the same AS. Both modes use the same protocol (BGP-4, RFC 4271), but they differ in how they handle next-hop, the AS-path attribute, the TTL value and route-propagation rules. For that reason they play distinct roles in an operator network.
| Aspect | eBGP | iBGP |
|---|---|---|
| Relationship | Between different autonomous systems | Inside one autonomous system |
| Next-hop | Rewritten to the neighbour's address | Preserved unchanged |
| AS path | Own AS number prepended | Left unchanged |
| Route propagation | To all neighbours | Not on to other iBGP peers |
| Session topology | Usually directly connected neighbours | Full mesh or route reflector |
| Default TTL | 1, multihop needs a change | 255 |
| Local preference | Does not cross AS boundaries | Propagated inside the AS |
Next-hop: when the address changes and when it does not
This is the most common source of misconfiguration. On an eBGP session a router sets itself as the next-hop for advertised prefixes by default. On iBGP the NEXT_HOP attribute is passed unchanged, so a route learned from eBGP keeps the original next-hop of the external neighbor. If that address is not reachable via the IGP, the route stays inactive and is not installed in the routing table.
- eBGP: next-hop rewritten to the local router address at the AS boundary.
- iBGP: the NEXT_HOP attribute is passed unchanged (RFC 4271).
- Common fix: the next-hop-self command on border routers.
- Alternative: advertise external link subnets into the IGP so the next-hop is reachable.
AS-path and propagation loops
On eBGP a router prepends its own AS number to the AS_PATH attribute on every advertisement. This is the loop-detection mechanism between autonomous systems. On iBGP the AS number is not prepended, because the route does not leave the system. Consequently iBGP has no built-in loop protection, and the rule is that routes learned via iBGP are not re-advertised to other iBGP peers. This forces a full mesh of sessions, or the use of route reflectors (RFC 4456) or confederations (RFC 5065).
TTL, session establishment and path selection
eBGP sessions usually connect directly adjacent routers, so BGP packets are sent with TTL=1 (multihop eBGP requires explicitly raising the TTL). iBGP sessions often traverse multiple IGP hops, so peers need not be directly connected. Default preference also differs: eBGP routes have a lower administrative distance (20 on Cisco) than iBGP (200), and in the BGP best-path selection process eBGP paths are preferred over iBGP.
- eBGP: TTL=1 by default, peers directly connected.
- iBGP: peers can be several IGP hops apart.
- Administrative distance: eBGP 20, iBGP 200 (Cisco).
- GTSM (RFC 5082) protects eBGP sessions by checking that packets arrive with a sufficiently high TTL.
eBGP and iBGP in the AS202520 SkyPass network
In AS202520 SkyPass, eBGP carries all external relationships: peering sessions at Polish IXPs (THINX, TPIX, WRIX, 1-IX) and IP transit sessions delivering the full BGP table to customers. Inside our AS, iBGP distributes those routes consistently between border routers, with route reflectors in our Warsaw and Wroclaw PoPs. When you configure a BGP session with us, you bring up eBGP to AS202520. On our side iBGP ensures your prefixes are visible at every interconnection point. You can verify route state in our Looking Glass.
Frequently asked questions
What is the difference between eBGP and iBGP in one sentence?
eBGP connects routers in different autonomous systems; iBGP distributes routes between routers within the same AS.
Why is an iBGP route inactive even though I can see it?
Usually the next-hop learned from eBGP is not reachable via the IGP. Fix it with next-hop-self on the border router, or advertise the link subnet into the IGP.
Does iBGP detect loops via AS-path?
No. iBGP does not prepend the AS number, so iBGP-learned routes are not passed to other iBGP peers. Loops are prevented by a full mesh, route reflectors (RFC 4456) or confederations (RFC 5065).
Do eBGP peers need to be directly connected?
By default yes, because packets use TTL=1. Sessions across multiple hops require explicit multihop eBGP with a raised TTL.