What Are iBGP and eBGP?
BGP peering relationships fall into two types depending on whether the peer belongs to the same AS (autonomous system) or a different one. Peering between routers in the same AS is called iBGP (Internal BGP), and peering between routers in different ASes is called eBGP (External BGP).
Both use the same BGP protocol, with the same message formats and the same state transitions. What differs is the behavior when advertising routes: the handling of AS_PATH and NEXT_HOP, the loop-prevention mechanism, the packet TTL, and the preference of the routes. This article organizes those differences and then confirms the actual behavior in an IOS XR (XRd) lab. For the basics of how BGP works, see BGP (Border Gateway Protocol).
Summary of the Differences
| Item | eBGP | iBGP |
|---|---|---|
| Peer relationship | Routers in different ASes | Routers in the same AS |
AS_PATH | Prepends its own AS number when advertising | Unchanged |
NEXT_HOP | Rewritten to its own address when advertising | Unchanged |
| Loop prevention | Discards routes whose AS_PATH contains its own AS number | Does not advertise routes learned via iBGP to other iBGP peers (split horizon) |
| Administrative distance | 20 | 200 |
| IP packet TTL (default) | 1 | 255 |
| Peer requirement | Must be directly connected (can be relaxed with ebgp-multihop) | Anywhere within the AS |
| Typical peering address | Address of the directly connected interface | Loopback interface address |
Handling of AS_PATH and NEXT_HOP
When advertising a route over eBGP, a router prepends its own AS number to the AS_PATH and rewrites the NEXT_HOP to its own address. Each time the route crosses an AS boundary, the record of which ASes it has traversed and where to hand it next is updated.
Over iBGP, neither is changed. The advertisement is only a relay within the same AS and does not cross an AS boundary. As a result, the NEXT_HOP of a route received via iBGP remains the address of a router outside the AS rather than a router inside it. If the receiving router cannot reach that NEXT_HOP, the route does not become valid, so either an IGP must carry a route to that address or next-hop-self must be used. This is covered in next-hop-self.
Loop Prevention
eBGP prevents loops with the AS_PATH. If a received route’s AS_PATH contains the router’s own AS number, the route has already passed through its AS, so it is discarded.
iBGP cannot use that method because the AS_PATH does not change. Instead it prevents loops with the rule that a route learned from an iBGP peer is not advertised to other iBGP peers (iBGP split horizon).
Why a Full Mesh Is Required
Because of split horizon, an iBGP route travels only one hop. Every router running BGP inside the AS therefore has to peer directly with every other one, which is called a full mesh.
For n routers the number of peerings is n × (n - 1) ÷ 2, which grows quickly: 45 for 10 routers and 190 for 20. Route reflectors and confederations exist to reduce this burden, and route reflectors are covered in a separate article.
TTL and the Peer Requirement
eBGP sends IP packets with a TTL of 1 by default. A packet with a TTL of 1 is discarded by the next router, so the peer must be directly connected. With even one router in between, ebgp-multihop is needed to raise the TTL.
iBGP defaults to a TTL of 255, so it can peer with a router anywhere in the AS. This is why iBGP peering normally uses loopback interface addresses. Peering on a physical interface address means the session drops when that link fails, whereas peering on loopbacks keeps the session up as long as an alternate path exists.
Verification on Real Devices
I use the same lab as in BGP (Border Gateway Protocol): four IOS XR (XRd) routers spread across three ASes. R1 - R2 within AS 65001 is an iBGP peering, and R2 - R3 and R3 - R4 between ASes are eBGP peerings.
R2 has both an iBGP peer (R1) and an eBGP peer (R3), so the two kinds of peering can be compared on the same router.
The internal and external Markers
show bgp <prefix> shows whether a route was learned via iBGP or eBGP as internal or external. First, 192.168.3.0/24 as learned by R2 via eBGP.
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24
Sat Sep 5 05:10:56.009 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 19 19
Last Modified: Sep 5 04:54:22.774 for 00:16:33
Paths: (1 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.1
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.1
65002
10.2.3.3 from 10.2.3.3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 19
Origin-AS validity: (disabled)It is marked external, and Advertised IPv4 Unicast paths to peers lists the iBGP peer R1 (10.0.0.1). A route learned via eBGP is advertised to iBGP peers.
Next, 192.168.1.0/24 as learned by R2 via iBGP.
RP/0/RP0/CPU0:R2#show bgp 192.168.1.0/24
Sat Sep 5 05:10:56.315 UTC
BGP routing table entry for 192.168.1.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 22 22
Last Modified: Sep 5 05:10:40.774 for 00:00:15
Paths: (1 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.2.3.3
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.2.3.3
Local
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 22This one is internal, and the only advertisement target is the eBGP peer R3 (10.2.3.3). A route learned via iBGP is advertised to eBGP peers but not to other iBGP peers.
Confirming iBGP Split Horizon
The 192.168.3.0/24 held by R1 is a route received from R2 via iBGP.
RP/0/RP0/CPU0:R1#show bgp 192.168.3.0/24
Sat Sep 5 05:11:03.447 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 26 26
Last Modified: Sep 5 05:10:40.774 for 00:00:22
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002
10.2.3.3 (metric 2) from 10.0.0.2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 26It shows Not advertised to any peer, meaning it is advertised to nobody. R1’s only BGP peer is R2, and R2 is an iBGP peer, so split horizon blocks the advertisement.
AS_PATH and NEXT_HOP Staying Unchanged
The 192.168.4.0/24 held by R1 was advertised by R4 in AS 65003 and reached R1 through R3 and R2.
RP/0/RP0/CPU0:R1#show bgp 192.168.4.0/24
Sat Sep 5 05:11:03.750 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 25 25
Last Modified: Sep 5 05:10:40.774 for 00:00:23
Paths: (1 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002 65003
10.2.3.3 (metric 2) from 10.0.0.2 (10.0.0.2)
Origin IGP, localpref 100, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 25The AS_PATH is 65002 65003: R2 did not prepend its own AS number 65001 when advertising over iBGP. The NEXT_HOP is also still 10.2.3.3 (R3’s address) rather than R2’s. The from 10.0.0.2 indicates that R2 is the peer that sent the route, which is separate information from the NEXT_HOP.
R1 can use this route because R2 advertises its link toward R3 (10.2.3.0/24) into OSPF, making 10.2.3.3 reachable.
Differences in Peer Attributes
The output of show bgp neighbor differs as well. First the iBGP peer (R2 as seen from R1).
RP/0/RP0/CPU0:R1#show bgp neighbor 10.0.0.2
Sat Sep 5 05:11:25.445 UTC
BGP neighbor is 10.0.0.2
Remote AS 65001, local AS 65001, internal link
Description: iBGP to R2 (Loopback0)
Remote router ID 10.0.0.2
BGP state = Established, up for 00:00:45
Previous State: Idle
Last Received Message: Update
NSR State: None
Hold time is 180, keepalive interval is 60 seconds
Configured hold time: 180, keepalive: 60, min acceptable hold time: 3
Received 139 messages, 0 notifications, 0 in queue
Sent 130 messages, 1 notifications, 0 in queue
Fast fallover is not enabled
Neighbor is not directly connected
Neighbor fast-fallover is not configured
Connections established 2; dropped 1
Local host: 10.0.0.1, Local port: 43703, IF Handle: 0x00000000
Foreign host: 10.0.0.2, Foreign port: 179The distinguishing lines are internal link and Neighbor is not directly connected. The same fields on an eBGP peer (R3 as seen from R2) read external link and Neighbor is directly connected (see the output in BGP Messages).
TTL of eBGP Packets
eBGP packets are sent with a TTL of 1. Extracting the IP TTL of the BGP packets from the capture on the R2 - R3 link shows that every one of them is 1.
1 10.2.3.2 10.2.3.3 1 3
9 10.2.3.2 10.2.3.3 1 1
15 10.2.3.3 10.2.3.2 1 1
18 10.2.3.2 10.2.3.3 1 1,4
19 10.2.3.3 10.2.3.2 1 4
20 10.2.3.2 10.2.3.3 1 2,2,2
21 10.2.3.3 10.2.3.2 1 2,2,2
23 10.2.3.3 10.2.3.2 1 2,2,4
25 10.2.3.3 10.2.3.2 1 2
27 10.2.3.2 10.2.3.3 1 4
29 10.2.3.3 10.2.3.2 1 2
31 10.2.3.2 10.2.3.3 1 4
33 10.2.3.3 10.2.3.2 1 4iBGP, on the other hand, uses a TTL of 255, so it can peer across any number of routers within the AS.
Configuration Files
Download R1 config (r1_bgp-ibgp-ebgp.cfg)
Download R2 config (r2_bgp-ibgp-ebgp.cfg)
Download R3 config (r3_bgp-ibgp-ebgp.cfg)
Download R4 config (r4_bgp-ibgp-ebgp.cfg)
References
| Source | Title | Summary |
|---|---|---|
| RFC 4271 | A Border Gateway Protocol 4 (BGP-4) | The base specification of BGP-4, defining the route advertisement rules for iBGP and eBGP. |
| RFC 4456 | BGP Route Reflection | Defines route reflection, which relaxes the iBGP full mesh. |
| IANA | Border Gateway Protocol (BGP) Parameters | The registry of numbers used by BGP. |