BGP is BGP — until you realize you are running two fundamentally different versions of it depending on where your routers sit relative to an AS boundary. Miss that distinction and you will spend hours debugging why routes are not propagating the way you expect.
The One Line That Explains Everything
The difference comes down to one thing: Autonomous System numbers.
- eBGP (External BGP): peers in different AS numbers
- iBGP (Internal BGP): peers in the same AS number
That is it. Same protocol (TCP port 179), same UPDATE messages, same path attributes — but the rules change dramatically based on which side of that boundary you are on. Think of it like the difference between talking to a colleague on your own team versus negotiating with another company. The language is the same; the trust model is completely different.
eBGP: Talking to the Outside World
eBGP is what most people picture when they think of BGP — the session between your edge router and your ISP, between your data center and a transit provider, or between two organizations exchanging routes across an administrative boundary.
Key Behaviors
- TTL = 1 by default — eBGP peers must be directly connected. Use
ebgp-multihopwhen peering across intermediate hops (loopbacks, out-of-band peering links). - Next-hop changes to the advertising router — your ISP advertises a default route with their interface IP as the next-hop. You own the resolution from there.
- Administrative distance of 20 — preferred over almost everything else in the routing table.
# Cisco IOS — eBGP to upstream ISP
router bgp 65001
neighbor 203.0.113.1 remote-as 64512
neighbor 203.0.113.1 description ATT_Transit
neighbor 203.0.113.1 ebgp-multihop 2
!
address-family ipv4 unicast
neighbor 203.0.113.1 activate
neighbor 203.0.113.1 route-map FILTER-IN in
neighbor 203.0.113.1 route-map ADVERTISE-OUT outCode language: CSS (css)When to Use eBGP
- Internet peering — ISPs, CDNs, IXPs
- Multi-homed connectivity to two or more transit providers
- Data center interconnect (DCI) across separate AS domains
- Any time you are crossing an organizational or administrative boundary
iBGP: Getting Your Own Routers to Agree
iBGP is where things get more nuanced — and where most engineers get tripped up. Your edge routers learn routes from ISPs via eBGP. But your internal core routers need to know about those routes too so they can make forwarding decisions. That is iBGP’s job: distributing externally-learned routes across your own AS.
Key Behaviors
- TTL = 255 — peers do not need to be directly connected. You almost always peer over loopbacks for stability. If a physical link flaps but the loopback is reachable via IGP, the BGP session stays up.
- Next-hop is NOT changed — this is the one that bites people. A route learned via eBGP and re-advertised over iBGP keeps the ISP address as the next-hop. Your internal routers need an IGP (OSPF or IS-IS) to resolve it. No IGP reachability equals a black hole.
- Administrative distance of 200 — less preferred than eBGP.
- No re-advertisement between iBGP peers — a route learned from one iBGP peer will not be passed to another iBGP peer. This is the loop prevention mechanism, and it is exactly why full mesh or route reflectors are required.
# Juniper — iBGP peering over loopbacks
set protocols bgp group IBGP type internal
set protocols bgp group IBGP local-address 10.0.0.1
set protocols bgp group IBGP neighbor 10.0.0.2 description CORE-RTR-2
set protocols bgp group IBGP neighbor 10.0.0.3 description CORE-RTR-3
set protocols bgp group IBGP neighbor 10.0.0.4 description EDGE-RTR-2Code language: CSS (css)The Full-Mesh Problem
Here is the catch with iBGP: every router must peer with every other router in the AS. In a 5-router network that is 10 sessions. In a 20-router network that is 190. It scales as n(n-1)/2 and gets ugly fast.
The standard solution is Route Reflectors (RR). Designate one or more routers as a hub — all other routers (clients) peer only with the RR. The RR re-advertises routes between clients, which is the one deliberate exception to the no-re-advertisement rule. This is how every real enterprise and service provider network solves the scaling problem.
# Cisco IOS — Route Reflector config
router bgp 65001
neighbor 10.0.0.2 remote-as 65001
neighbor 10.0.0.2 description CORE-RTR-2
neighbor 10.0.0.2 route-reflector-client
neighbor 10.0.0.3 remote-as 65001
neighbor 10.0.0.3 description CORE-RTR-3
neighbor 10.0.0.3 route-reflector-clientCode language: CSS (css)Put your RR on your most stable, most connected routers — not the edge. Edge routers go into maintenance windows, lose circuits, and get replaced. Your RR needs to be the last thing to fail.
Key Differences at a Glance
| eBGP | iBGP | |
|---|---|---|
| AS relationship | Different ASes | Same AS |
| Default TTL | 1 (direct connect) | 255 (loopback peering) |
| Next-hop behavior | Changes to local router | Preserved (unchanged) |
| Route propagation | Advertises freely | Will not re-advertise to iBGP peers |
| Admin distance | 20 | 200 |
| Scale challenge | Managed per-peer policy | Full mesh required (use RR) |
| Typical use | ISP peering, DCI, org boundaries | Internal route distribution |
Design Decisions: Where It Gets Real
Single-homed with one ISP?
You probably do not need BGP at all. A static default route is simpler, more stable, and easier to troubleshoot. BGP to a single upstream is operational overhead without meaningful benefit.
Multi-homed with two ISPs?
Now BGP earns its place. Run eBGP to both providers. Use LOCAL_PREF to control outbound path preference. Use MED to influence inbound — with the caveat that your ISP actually has to honor it, which is not guaranteed. iBGP between your edge routers lets them share what each learned so both can make consistent forwarding decisions.
Enterprise core with multiple egress points?
Route reflectors are your friend. Place them on your core distribution layer, not the edge. Build redundancy into your RR design — a single RR is a single point of failure for your entire BGP topology.
Data center fabric?
BGP in the underlay is increasingly standard — especially with Arista, Cumulus, and SONiC in EVPN deployments. Running eBGP between spine and leaf (each leaf pair in its own private AS) sidesteps the full-mesh problem entirely and gives you clean failure isolation per rack. This is where iBGP scaling limitations pushed the industry toward a new architecture — and it is worth understanding that history before you design your next fabric.
The Takeaway
iBGP and eBGP are not two protocols — they are the same tool used for two completely different jobs. eBGP is how you talk to the world. iBGP is how you make sure the rest of your network knows what you learned from the world.
Get the boundary right and BGP is remarkably predictable. Forget the next-hop behavior, skip route reflectors, or blur where your AS actually ends — and you will be staring at show bgp summary wondering why half your routers have black holes at 2am.
— Mike
Questions or want to dig deeper? Connect with me on LinkedIn.