From a configuration perspective, the only difference between an iBGP peering and an EBGP peering is that with an EBGP peering, the remote-as is different than the local-as. In practice, however, many important attributes differ between the two. As shown in the following output, R4 knows that the peering occurs on a directly connected external link and that the TTL should be 1 instead of 255. This implies that the neighbors must be directly connected for peering to be established, otherwise the TTL would be exceeded in transit and the TCP frames would be dropped.
R7#show ip bgp neighbors 177.1.79.9
BGP neighbor is 177.1.79.9, remote AS 54, external link
BGP version 4, remote router ID 212.18.3.1
BGP state = Established, up for 00:00:55
Last read 00:00:05, last write 00:00:24, hold time is 180, keepalive interval is 60 seconds
Neighbor sessions:
1 active, is not multisession capable (disabled)
Neighbor capabilities:
Route refresh: advertised and received(new)
Four-octets ASN Capability: advertised and received
Address family IPv4 Unicast: advertised and received
Enhanced Refresh Capability: advertised and received
Multisession Capability:
Stateful switchover support enabled: NO for session 1
Message statistics:
InQ depth is 0
OutQ depth is 0
Because both R9 and R10 run BGP in AS 54, the same view should be coming in from both peers. In the output below, R7 sees 10 prefixes learned from R9 and 11 prefixes learned from R8 (R8’s Loopback0 plus the ten AS 54 prefixes from R10):
R7#show ip bgp summary
BGP router identifier 177.1.7.7, local AS number 100
BGP table version is 19, main routing table version 19
18 network entries using 2592 bytes of memory
18 path entries using 1512 bytes of memory
6/6 BGP path/bestpath attribute entries using 960 bytes of memory
2 BGP AS-PATH entries using 48 bytes of memory
1 BGP community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
177.1.0.5 4 100 32 32 19 0 0 00:23:41 1
177.1.23.2 4 100 31 32 19 0 0 00:23:38 1
177.1.37.3 4 100 33 32 19 0 0 00:23:46 1
177.1.58.8 4 100 30 32 19 0 0 00:23:31 3
177.1.67.6 4 100 29 32 19 0 0 00:23:51 1
177.1.79.9 4 54 12 11 19 0 0 00:04:59 8
177.1.146.1 4 100 32 32 19 0 0 00:23:47 1
177.1.146.4 4 100 33 32 19 0 0 00:23:48 1
Because duplicate routing information is learned, the BGP Bestpath Selection process must be run to choose one path over the other. The path that is active, known as the “best” path, can be seen from the greater-than sign (>) in the left column of the show ip bgp output:
R1#show ip bgp
BGP table version is 18, local router ID is 170.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
>i 28.119.16.0/24 177.1.108.10 0 100 0 54 i
>i 28.119.17.0/24 177.1.108.10 0 100 0 54 i
>i 112.0.0.0 177.1.79.9 0 100 0 54 50 60 i
>i 113.0.0.0 177.1.79.9 0 100 0 54 50 60 i
>i 114.0.0.0 177.1.79.9 0 100 0 54 i
>i 115.0.0.0 177.1.79.9 0 100 0 54 i
>i 116.0.0.0 177.1.79.9 0 100 0 54 i
>i 117.0.0.0 177.1.79.9 0 100 0 54 i
>i 118.0.0.0 177.1.79.9 0 100 0 54 i
>i 119.0.0.0 177.1.79.9 0 100 0 54 i
> 170.1.1.1/32 0.0.0.0 0 32768 i
>i 170.1.3.3/32 177.1.0.3 0 100 0 i
>i 170.1.4.4/32 177.1.0.4 0 100 0 i
>i 170.1.5.5/32 177.1.0.5 0 100 0 i
>i 170.1.6.6/32 177.1.146.6 0 100 0 i
>i 170.1.7.7/32 177.1.67.7 0 100 0 i
*>i 170.1.8.8/32 177.1.58.8 0 100 0 i
The best path is the only route that is installed in the routing table, and the only route that is advertised to other BGP neighbors. From the above output of R1, we can see that the best path for all AS 54 routes is via 177.1.79.9. Why this selection occurs can be seen from the detailed output below:
R1#show ip bgp 112.0.0.0 255.0.0.0
BGP routing table entry for 112.0.0.0/8, version 9
Paths: (1 available, best #1, table default)
Flag: 0x100
Not advertised to any peer
Refresh Epoch 1
54 50 60
177.1.79.9 (metric 3328) from 177.1.67.7 (177.1.7.7)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Note the difference between the next-hop value and the neighbor from which the prefix is learned. The first highlighted value, 177.1.79.9, is the next-hop that R1 needs to be able to perform route-recursion toward to use the route. The next value, 177.1.67.7, is the BGP peer address that R1 uses to reach R7. The final address, 170.1.7.7, is the BGP router-id of R7. In this case, the route through R7 is chosen over R8’s route because of the lower metric of 3328 toward the next-hop 177.1.79.9, as opposed to the metric 3584 toward 177.1.108.10. Bestpath selection will be discussed in detail in further tasks. When R1 does its final lookup on 112.0.0.0/8, recursion continues toward the next hop 177.1.79.9, resulting in two outgoing interfaces (ECMP), GigabitEthernet0/2 and GigabitEthernet0/1, toward 177.1.146.6 and 177.1.13.3, respectively:
R1#show ip route 112.0.0.0
Routing entry for 112.0.0.0/8
Known via "bgp 100", distance 200, metric 0
Tag 54, type internal
Last update from 177.1.79.9 00:06:52 ago
Routing Descriptor Blocks:
* 177.1.79.9, from 177.1.67.7, 00:06:52 ago
Route metric is 0, traffic share count is 1
AS Hops 3
Route tag 54
MPLS label: none
R1#show ip route 177.1.79.9
Routing entry for 177.1.79.0/24
Known via "eigrp 100", distance 90, metric 3328, type internal
Redistributing via eigrp 100
Last update from 177.1.146.6 on GigabitEthernet0/2, 00:07:43 ago
Routing Descriptor Blocks:
177.1.146.6, from 177.1.146.6, 00:07:43 ago, via GigabitEthernet0/2
Route metric is 3328, traffic share count is 1
Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
* 177.1.13.3, from 177.1.13.3, 00:07:43 ago, via GigabitEthernet0/1
Route metric is 3328, traffic share count is 1
Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
R1#show ip route 177.1.146.6
Routing entry for 177.1.146.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/2
Route metric is 0, traffic share count is 1
R1#show ip route 177.1.13.3
Routing entry for 177.1.13.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Redistributing via eigrp 100
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/1
Route metric is 0, traffic share count is 1
R1#traceroute 112.0.0.1 source Loopback 0
Type escape sequence to abort.
Tracing the route to 112.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
1 177.1.13.3 2 msec
177.1.146.6 3 msec
177.1.13.3 2 msec
2 177.1.67.7 2 msec
177.1.37.7 2 msec
177.1.67.7 2 msec
3 177.1.79.9 3 msec * 3 msec
Pitfall
Note: R7 and R8 did not update the next-hop values when advertising an EBGP learned route to their iBGP peers. If the iBGP peers do not have a route to the next-hop value in the prefix, bestpath selection fails and the route cannot be used. Fixes for this problem will be explored in depth in further tasks.
