iBGP vs. eBGP

What Are iBGP and eBGP?

A peering between routers in the same AS is iBGP (Internal BGP); one between routers in different ASes is eBGP (External BGP). Both are the same protocol with the same messages and state machine; what differs is the behaviour when advertising routes and how peers are set up. This article lays out those differences and confirms them on IOS XR (XRd).

Summary of 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 (except for routes it originates)
`LOCAL_PREF`	Not sent	Sent (default 100)
Loop prevention	Discards routes whose `AS_PATH` contains its own AS number	Does not advertise routes learned over 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` and others)	Anywhere within the AS
Default advertisement interval (MRAI)	30 seconds	0 seconds (RFC 4271 suggests 5 seconds)
Typical peering address	Directly connected interface address	Loopback interface address

AS_PATH, NEXT_HOP, LOCAL_PREF and loop prevention are defined by RFC 4271; the other defaults are IOS XR’s. For MRAI, chapter 10 of RFC 4271 suggests 30 seconds for eBGP and 5 seconds for iBGP, while IOS XR uses 0 seconds for iBGP.

How AS_PATH, NEXT_HOP and LOCAL_PREF Are Handled

When advertising over eBGP, a router prepends its own AS number to AS_PATH and rewrites NEXT_HOP to its own address. Over iBGP it changes neither (RFC 4271 5.1.2, 5.1.3). So the NEXT_HOP of a route received over iBGP is still the address of a router outside the AS, and the route is not usable unless the receiving router can reach it. Either distribute a route to that address with the IGP, or use next-hop-self.

LOCAL_PREF is a preference within the AS, so it must not be included in UPDATEs sent to eBGP peers (RFC 4271 5.1.5).

Loop Prevention

eBGP prevents loops by discarding routes whose AS_PATH contains its own AS number. Over iBGP the AS_PATH does not change, so instead the rule “do not advertise routes learned from an iBGP peer to other iBGP peers” (iBGP split horizon, RFC 4271 9.2) prevents loops.

Why a Full Mesh Is Needed

Because of split horizon, iBGP routes travel only one hop, so every BGP router in the AS must peer directly with every other (a full mesh).

The number of peerings is n × (n - 1) ÷ 2 (45 for 10 routers, 190 for 20); route reflectors and confederations exist to reduce it.

Two Mechanisms Behind eBGP’s “Directly Connected” Requirement

An eBGP peer has to be directly connected because two separate mechanisms are at work.

Mechanism	What it does	What relaxes it
Connected check	If the peer address is not on a directly connected subnet, the router does not start a TCP connection. The state stays `Idle`	`ignore-connected-check`, or `ebgp-multihop`
TTL 1	BGP packets are sent with TTL `1`, so they are dropped one router away	`ebgp-multihop <hop count>`

The connected check happens entirely inside the router, so when the peer is not directly connected not a single packet goes out. Removing only the check makes the router start connecting, but the TTL-1 packets are dropped by the router in between. ebgp-multihop relaxes both (the TTL is set by the sender, so configure it on both sides).

iBGP uses TTL 255 by default and does no connected check, so it can peer with a router anywhere in the AS. Peering on loopback addresses keeps the session up as long as an alternate path exists.

Verification on Real Devices

Four XRd 26.1.1 routers sit in three ASes: R1 - R2 is iBGP, while R2 - R3 and R3 - R4 are eBGP. Each router advertises 192.168.N.0/24.

R2 has both an iBGP peer (R1) and an eBGP peer (R3), so the two kinds of peering can be compared on one router. R4 is two hops from R2 and is used to test the connected check and the TTL. Each eBGP neighbor has its own outbound route policy name (all contain only pass).

STEP	Action	What it shows
0	Initial state	The iBGP and eBGP peers side by side on R2 (`internal` / `external`, where routes are advertised, distance, MRAI)
1	`clear bgp ipv4 unicast * soft out` on R2	The UPDATEs carrying the same route to iBGP and eBGP, side by side in the capture
2	Peer R2 - R4 (two hops) on Loopback0 (no options)	The connected check keeps TCP from starting
3	Only `ignore-connected-check` on R2 and R4	TCP starts, but the TTL-1 SYN is dropped at R3
4	Replace `ignore-connected-check` with `ebgp-multihop 2`	The session comes up; eBGP loop prevention
5	Remove the R2 - R4 peering (final state)	Back to the STEP 0 state

STEP 0: Comparing Two Kinds of Peering on One Router

internal and external, and where routes are advertised

show bgp <prefix> shows where a route was learned as internal / external. 192.168.3.0/24, learned by R2 over eBGP, is external, and the iBGP peer R1 (10.0.0.1) is listed as a peer it is advertised to. 192.168.1.0/24, learned over iBGP, is internal, and it is advertised only to the eBGP peer R3 (10.2.3.3). Routes learned over iBGP are not advertised to other iBGP peers.

R2 show bgp 192.168.3.0/24 (STEP 0)
RP/0/RP0/CPU0:R2#show bgp 192.168.3.0/24
Tue Sep 22 08:47:48.732 UTC
BGP routing table entry for 192.168.3.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  5            5
Last Modified: Sep 22 08:35:28.023 for 00:12:20
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, (received & used)
    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 5
      Origin-AS validity: (disabled)

R2 show bgp 192.168.1.0/24 (STEP 0)
RP/0/RP0/CPU0:R2#show bgp 192.168.1.0/24
Tue Sep 22 08:47:48.187 UTC
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  4            4
Last Modified: Sep 22 08:35:16.023 for 00:12:32
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, (received & used)
    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 4

How AS_PATH and NEXT_HOP change on advertisement

What R2 advertises to its two peers. Toward the iBGP peer (R1), the routes received from R3 keep Next Hop 10.2.3.3 and AS Path 65002 / 65002 65003. Toward the eBGP peer (R3), every Next Hop is rewritten to R2’s own 10.2.3.2, and 65001 is prepended to AS Path.

R2 show bgp neighbors 10.0.0.1 advertised-routes (STEP 0)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.0.1 advertised-routes
Tue Sep 22 08:47:50.600 UTC
Network            Next Hop        From            AS Path
192.168.2.0/24     10.0.0.2        Local           i
192.168.3.0/24     10.2.3.3        10.2.3.3        65002i
192.168.4.0/24     10.2.3.3        10.2.3.3        65002 65003i

Processed 3 prefixes, 3 paths

R2 show bgp neighbors 10.2.3.3 advertised-routes (STEP 0)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.2.3.3 advertised-routes
Tue Sep 22 08:47:51.422 UTC
Network            Next Hop        From            AS Path
192.168.1.0/24     10.2.3.2        10.0.0.1        65001i
192.168.2.0/24     10.2.3.2        Local           65001i

Processed 2 prefixes, 2 paths

On R1, both AS_PATH and NEXT_HOP arrive unchanged (from 10.0.0.2 is the peer that sent it, which is separate from NEXT_HOP). Not advertised to any peer is iBGP split horizon: R1’s only peer is the iBGP peer R2, so the route goes nowhere.

R1 show bgp 192.168.4.0/24 (STEP 0)
RP/0/RP0/CPU0:R1#show bgp 192.168.4.0/24
Tue Sep 22 08:46:57.900 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  6            6
Last Modified: Sep 22 08:35:58.023 for 00:10:59
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65002 65003, (received & used)
    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 6

R1 can use this route because R2 advertises 10.2.3.0/24 in OSPF, so 10.2.3.3 is reachable.

The administrative distance difference

The number on the left inside the brackets of show route bgp is the distance. For the same 192.168.3.0/24, R2 (learned over eBGP) has 20 and R1 (learned over iBGP) has 200.

R2 show route bgp (STEP 0)
RP/0/RP0/CPU0:R2#show route bgp
Tue Sep 22 08:47:48.046 UTC

B    192.168.1.0/24 [200/0] via 10.0.0.1, 00:12:32
B    192.168.3.0/24 [20/0] via 10.2.3.3, 00:12:20
B    192.168.4.0/24 [20/0] via 10.2.3.3, 00:11:50

R1 show route bgp (STEP 0)
RP/0/RP0/CPU0:R1#show route bgp
Tue Sep 22 08:46:56.947 UTC

B    192.168.2.0/24 [200/0] via 10.0.0.2, 00:11:41
B    192.168.3.0/24 [200/0] via 10.2.3.3, 00:11:29
B    192.168.4.0/24 [200/0] via 10.2.3.3, 00:10:59

Differences in the neighbor attributes

R2’s show bgp neighbor lists the differences between the two peers.

R2 show bgp neighbor (STEP 0, excerpt)
BGP neighbor is 10.0.0.1
 Remote AS 65001, local AS 65001, internal link
<snip>
  Minimum time between advertisement runs is 0 secs
<snip>
    Neighbor is not directly connected
<snip>
BGP neighbor is 10.2.3.3
 Remote AS 65002, local AS 65001, external link
<snip>
  Enforcing first AS is enabled
<snip>
  Minimum time between advertisement runs is 30 secs
<snip>
    Neighbor is directly connected

Line	iBGP (10.0.0.1)	eBGP (10.2.3.3)
Link type	`internal link`	`external link`
Directly connected	`Neighbor is not directly connected`	`Neighbor is directly connected`
Advertisement interval (MRAI)	`0 secs`	`30 secs`
First-AS check	—	`Enforcing first AS is enabled` (rejects UPDATEs whose `AS_PATH` does not start with the peer’s AS number)

STEP 1: Comparing the UPDATEs That Carry One Route to iBGP and eBGP

Running clear bgp ipv4 unicast * soft out on R2 makes it resend its routes to every peer without tearing down the sessions. R1 - R2 and R2 - R3 were captured at the same time, and the UPDATEs carrying R2’s own 192.168.2.0/24 are shown side by side.

STEP 1 R1 - R2 No.3 UPDATE (R2 to R1), tshark -V (excerpt)
Internet Protocol Version 4
    Time to Live: 255
    Source Address: 10.0.0.2
    Destination Address: 10.0.0.1
Border Gateway Protocol - UPDATE Message
<snip>
    Length: 61
<snip>
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 38
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
                ...1 .... = Extended-Length: Set
<snip>
            Length: 13
<snip>
            Next hop: 10.0.0.2
<snip>
                192.168.2.0/24
<snip>
        Path Attribute - ORIGIN: IGP
<snip>
                ...0 .... = Extended-Length: Not set
<snip>
            Length: 1
<snip>
        Path Attribute - AS_PATH: empty
<snip>
                ...0 .... = Extended-Length: Not set
<snip>
            Length: 0
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
                ...0 .... = Extended-Length: Not set
<snip>
            Length: 4
<snip>
        Path Attribute - LOCAL_PREF: 100
<snip>
                ...0 .... = Extended-Length: Not set
<snip>
            Length: 4
            Local preference: 100

STEP 1 R2 - R3 No.1 UPDATE (R2 to R3), tshark -V (excerpt)
Internet Protocol Version 4
    Time to Live: 1
    Source Address: 10.2.3.2
    Destination Address: 10.2.3.3
Border Gateway Protocol - UPDATE Message
<snip>
    Length: 60
<snip>
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 37
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
                ...1 .... = Extended-Length: Set
<snip>
            Length: 13
<snip>
            Next hop: 10.2.3.2
<snip>
                192.168.2.0/24
<snip>
        Path Attribute - ORIGIN: IGP
<snip>
                ...0 .... = Extended-Length: Not set
<snip>
            Length: 1
<snip>
        Path Attribute - AS_PATH: 65001 
<snip>
                ...0 .... = Extended-Length: Not set
<snip>
            Length: 6
            AS Path segment: 65001
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
                ...0 .... = Extended-Length: Not set
<snip>
            Length: 4

Download the pcap of the iBGP packet above (STEP 1 R1 - R2 No.3)

Download the pcap of the eBGP packet above (STEP 1 R2 - R3 No.1)

Item	iBGP (R2 to R1)	eBGP (R2 to R3)
IP TTL	`255`	`1`
`NEXT_HOP`	`10.0.0.2` (R2’s Loopback0; its own address because it originates the route)	`10.2.3.2` (R2’s interface toward R3)
`AS_PATH`	empty	`65001`
`LOCAL_PREF`	`100`	absent

STEP 2: An eBGP Peer That Is Not Directly Connected Does Not Start a Connection

R2 and R4 are two hops apart, with R3 in between. After adding static routes to each other’s Loopback0, configure an eBGP peering between the Loopback0 addresses (update-source Loopback0, no options).

R2 eBGP peering to R4 (STEP 2, R2 commit)
route-policy TO-TEST
  pass
end-policy
!
route-policy FROM-TEST
  pass
end-policy
!
router static
 address-family ipv4 unicast
  10.0.0.4/32 10.2.3.3
 !
!
router bgp 65001
 neighbor 10.0.0.4
  remote-as 65003
  description test: eBGP to R4 (2 hops away)
  update-source Loopback0
  address-family ipv4 unicast
   route-policy FROM-TEST in
   route-policy TO-TEST out
   soft-reconfiguration inbound always
  !
 !
!

The static route to R4’s Loopback0 is in place (show route 10.0.0.4/32), yet the state is Idle (eBGP neighbor not directly connected). Local host is 0.0.0.0 and Connections established 0: no TCP connection has been started. The R2 - R3 and R3 - R4 captures contain no packets to 10.0.0.4 at all.

R2 show route 10.0.0.4/32 (STEP 2)
RP/0/RP0/CPU0:R2#show route 10.0.0.4/32
Tue Sep 22 08:57:32.124 UTC

Routing entry for 10.0.0.4/32
  Known via "static", distance 1, metric 0
  Installed Sep 22 08:54:36.604 for 00:02:55
  Routing Descriptor Blocks
    10.2.3.3
      Route metric is 0
  No advertising protos. 

R2 show bgp neighbor 10.0.0.4 (STEP 2, excerpt)
BGP neighbor is 10.0.0.4
 Remote AS 65003, local AS 65001, external link
<snip>
  BGP state = Idle (eBGP neighbor not directly connected)
<snip>
  Connections established 0; dropped 0
  Local host: 0.0.0.0, Local port: 0, IF Handle: 0x00000000
  Foreign host: 10.0.0.4, Foreign port: 0
<snip>
  External BGP neighbor not directly connected.

STEP 3: Removing Only the Connected Check

Configure only ignore-connected-check on R2 and R4. The TTL stays at 1.

R2 ignore-connected-check (STEP 3, R2 commit)
router bgp 65001
 neighbor 10.0.0.4
  ignore-connected-check
 !
!

The state changes from Idle to Active, and Local host becomes 10.0.0.2. With the connected check removed, the router has started a TCP connection. Still, the session does not come up.

R2 show bgp neighbor 10.0.0.4 (STEP 3, excerpt)
BGP neighbor is 10.0.0.4
 Remote AS 65003, local AS 65001, external link
<snip>
  BGP state = Active
<snip>
  Connections established 0; dropped 0
  Local host: 10.0.0.2, Local port: 0, IF Handle: 0x00000000
  Foreign host: 10.0.0.4, Foreign port: 0

In the capture, the SYN sent by R2 has TTL 1, and R3 (10.2.3.3) answers with ICMP Time Exceeded. The SYN is retransmitted at 2-, 4- and 8-second intervals, and the same ICMP comes back every time. The R3 - R4 capture contains no packets from R2 at all (for the same reason, R4’s own SYNs are dropped at R3).

R2 - R3 packet capture (STEP 3, tshark listing)
 0.000000     10.0.0.2 → 10.0.0.4     TCP 62 16770 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
 0.003066     10.2.3.3 → 10.0.0.2     ICMP 110 Time-to-live exceeded (Time to live exceeded in transit)
 2.000413     10.0.0.2 → 10.0.0.4     TCP 62 [TCP Retransmission] 16770 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
 2.003217     10.2.3.3 → 10.0.0.2     ICMP 110 Time-to-live exceeded (Time to live exceeded in transit)
 6.001255     10.0.0.2 → 10.0.0.4     TCP 62 [TCP Retransmission] 16770 → 179 [SYN] Seq=0 Win=32768 Len=0 MSS=1240 WS=1
 6.004113     10.2.3.3 → 10.0.0.2     ICMP 110 Time-to-live exceeded (Time to live exceeded in transit)

STEP 3 R2 - R3 No.2 ICMP (R3 to R2), tshark -V (excerpt)
Internet Protocol Version 4, Src: 10.2.3.3, Dst: 10.0.0.2
<snip>
    Time to Live: 255
<snip>
    Source Address: 10.2.3.3
    Destination Address: 10.0.0.2
<snip>
Internet Control Message Protocol
    Type: Time-to-live exceeded (11)
<snip>
    Code: 0 (Time to live exceeded in transit)
<snip>
    Internet Protocol Version 4, Src: 10.0.0.2, Dst: 10.0.0.4
<snip>
        Time to Live: 1
<snip>
        Source Address: 10.0.0.2
        Destination Address: 10.0.0.4
<snip>
    Transmission Control Protocol, Src Port: 16770, Dst Port: 179, Seq: 1946219533

Download the pcap of the packet in the tshark output above (STEP 3 No.2 ICMP)

STEP 4: Establishing With ebgp-multihop

Remove ignore-connected-check and configure ebgp-multihop 2 on both R2 and R4. The session comes up and the text changes to may be up to 2 hops away.

R2 show bgp neighbor 10.0.0.4 (STEP 4, excerpt)
BGP neighbor is 10.0.0.4
 Remote AS 65003, local AS 65001, external link
<snip>
  BGP state = Established, up for 00:02:58
<snip>
  Connections established 1; dropped 0
  Local host: 10.0.0.2, Local port: 57050, IF Handle: 0x00000000
<snip>
  External BGP neighbor may be up to 2 hops away.

Packets sent by R2 now have TTL 2. R4 sends with 2 as well, but R3 decrements it, so on R2 - R3 it is 1.

R2 - R3 packet capture (STEP 4, R2 - R4 BGP with TTL)
10.0.0.2	10.0.0.4	2	OPEN Message
10.0.0.4	10.0.0.2	1	OPEN Message, KEEPALIVE Message
10.0.0.2	10.0.0.4	2	KEEPALIVE Message
10.0.0.4	10.0.0.2	1	UPDATE Message, UPDATE Message, UPDATE Message, UPDATE Message
10.0.0.2	10.0.0.4	2	UPDATE Message, UPDATE Message, UPDATE Message, UPDATE Message, UPDATE Message
10.0.0.4	10.0.0.2	1	UPDATE Message, KEEPALIVE Message

AS_PATH loop prevention

Over this session, R4 sends R2 every route it has learned. Among them, 192.168.1.0/24 and 192.168.2.0/24 left R2’s AS 65001 and came back around through R3 and R4, with AS_PATH 65003 65002 65001 (No.15).

STEP 4 R2 - R3 No.15 UPDATE (R4 to R2), tshark -V (excerpt)
Border Gateway Protocol - UPDATE Message
<snip>
                192.168.1.0/24
<snip>
                192.168.2.0/24
<snip>
        Path Attribute - AS_PATH: 65003 65002 65001 
<snip>
                AS4: 65003
                AS4: 65002
                AS4: 65001

Download the pcap of the packet in the tshark output above (STEP 4 No.15 UPDATE)

R2 discards these two because they contain its own AS number 65001. They do not appear even in received routes, which shows routes before the inbound policy.

R2 show bgp neighbors 10.0.0.4 received routes (STEP 4)
RP/0/RP0/CPU0:R2#show bgp neighbors 10.0.0.4 received routes
Tue Sep 22 09:08:11.188 UTC
BGP router identifier 10.0.0.2, local AS number 65001
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 7
BGP main routing table version 7
BGP NSR Initial initsync version 3 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*  192.168.3.0/24     10.0.0.4                               0 65003 65002 i
*> 192.168.4.0/24     10.0.0.4                 0             0 65003 i

Processed 2 prefixes, 2 paths

STEP 5: Restoring the Configuration (Final State)

Remove the R2 - R4 peering, the static routes and the test policies, returning to the STEP 0 state.

Verification Config and Command Outputs

For every step, the following files were collected from all four routers, one per router. The verification config is the ..._run.txt file (the final state is the one from STEP 5).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show bgp` / `show bgp summary` / `show bgp <prefix>` / `show bgp neighbors` / per-peer `advertised-routes`, `routes` and `received routes` / `show bgp update-group` / `show rpl route-policy`. R1 and R2 also include `show ospf neighbor`. In STEPs 2-4, R2 adds `show route 10.0.0.4/32` and R4 adds `show route 10.0.0.2/32`
`..._log.txt`	`show logging` limited to that step. A `logmsg` marker is written at the start of each step and its timestamp passed to `show logging start`
`..._run.txt`	`show running-config` at that step (that is, the verification config for the step)
`..._ping.txt`	The `ping` and `traceroute` of that step (50 packets from R1, R2 and R4 toward `192.168.4.1` or `192.168.1.1`)
`..._trace.txt`	`show bgp trace neighbor` and `show bgp trace error` (internal events of the BGP process)
`..._commit.cfg`	The configuration actually committed in that step (only for the routers that were changed)
`..._exec.txt`	The `clear bgp` command run in that step, with its timestamp (R2 in STEP 1)

STEP 0: Initial state

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	—
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	—

STEP 1: clear bgp ipv4 unicast * soft out on R2

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	exec
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	—

STEP 2: Peer R2 - R4 on Loopback0 (no options)

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	commit
R3	show	log	run	—	trace	commit
R4	show	log	run	ping	trace	commit

STEP 3: ignore-connected-check on R2 and R4

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	commit
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	commit

STEP 4: Replace ignore-connected-check with ebgp-multihop 2

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	commit
R3	show	log	run	—	trace	—
R4	show	log	run	ping	trace	commit

STEP 5: Remove the R2 - R4 peering (final state)

Router	show output	syslog	running-config	ping	trace	Committed config
R1	show	log	run	ping	trace	—
R2	show	log	run	ping	trace	commit
R3	show	log	run	—	trace	commit
R4	show	log	run	ping	trace	commit

Packet captures were taken per step (a dash means no capture on that link).

STEP	R1 - R2	R2 - R3	R3 - R4
0	pcap	pcap	—
1	pcap	pcap	—
2	—	pcap	pcap
3	—	pcap	pcap
4	—	pcap	pcap
5	—	pcap	—

References

Source	Title	Summary
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	The base BGP-4 specification. 5.1.2-5.1.5 define the handling of AS_PATH, NEXT_HOP and LOCAL_PREF, 9.2 iBGP split horizon, and chapter 10 the suggested MRAI values.
RFC 4456	BGP Route Reflection	Defines route reflectors, which relax the iBGP full mesh.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of numbers used in BGP.