What BGP Best External is
Even when several routes exist for the same prefix, BGP selects one best path and advertises only that one to its peers. This is the rule of section 9.1.3 (Phase 3: Route Dissemination) of RFC 4271: whether the peer is iBGP or eBGP, what gets advertised is the best path installed in the Loc-RIB.
One consequence of this rule is that when a border router prefers an iBGP route from another border router over its own eBGP route, it advertises its own eBGP route nowhere. Seen from the other routers in the AS, the exit beyond that border router might as well not exist.
Best External is a feature that, in this case, advertises the best of the non-best external routes (the “best external”) to iBGP peers. The IETF draft draft-ietf-idr-best-external (expired; never standardized) lays out the procedure.
Given that Internal paths are not re-advertised to Internal peers, it was specified that the best of the external paths, as determined by the path selection tie breaking algorithm, would be advertised to Internal peers.
As the draft says, early BGP-4 (RFC 1771) advertised “the best of the external paths” to iBGP peers, and RFC 4271 changed this to “the overall best path”. Best External is that older rule, reworked so that it also operates with route reflection and confederations.
Why it becomes necessary: the active-backup topology
The problem appears when an operator concentrates traffic on one exit (an active-backup topology).
| Router | Routes received | Best path | Advertised to iBGP peers |
|---|---|---|---|
| R1 (primary exit) | eBGP from R4 (given LOCAL_PREF 200) | Its own eBGP | Yes |
| R2 (backup exit) | eBGP from R4 (LOCAL_PREF 100), iBGP from R1 (LOCAL_PREF 200) | iBGP from R1 | No (the best path is iBGP, so there is nothing to advertise to iBGP peers) |
| R3 (internal) | iBGP from R1 only | Via R1 | — |
R2’s exit is alive, yet neither R3 nor R1 knows the route via R2. The backup path described in BGP PIC is “the same prefix received from another next hop”, so PIC has nothing to use as a backup. When the R1-R4 link goes down, forwarding stops until R1 withdraws the routes to R3, R2 re-selects its best path and advertises it to R3, and R3 installs it.
With advertise best-external on R2, R2 advertises its own eBGP route (not best, but the best of its external routes) to its iBGP peers. R3 and R1 receive the route via R2 and can install it in the FIB as the PIC backup. The benefits the draft lists are faster restoration of connectivity (“Faster restoration of connectivity”), less inter-domain churn and black-holing, prevention of persistent iBGP route oscillation, and better MED comparison among routes from the same neighboring AS.
The loop condition and the address-family restriction
A route advertised by Best External does not become best on the routers that receive it (its LOCAL_PREF is lower). In steady state it is not used for forwarding; it is used as a backup only during a failure. The draft uses this as the basis for consistent path selection within the AS.
consistency in the path selection process across the AS is still guaranteed since the ingress routers will not choose the best-external route as the best route for a destination in steady state.
The moment of a failure needs care, though. Packets from the router that switched to the backup follow the IGP toward the next hop (R2). If another router sits in between, that router decides where to forward them from its own BGP table, and if its best path still points at the original exit, the packets are sent back and loop. The problem does not arise if labels (MPLS) carry the packets to the next hop, or if the backup border router is reached over a direct link, as in the topology of this article.
For this reason Cisco’s guides describe Best External as configurable only in certain address families.
| OS | What the guide says | Source |
|---|---|---|
| IOS XR | VRF IPv4/IPv6, VPNv4/VPNv6, L2VPN, IPv4/IPv6 labeled-unicast. “Unlabelled best-external is not supported as it may create routing loop” | ASR 9000 Routing Command Reference, IOS XR 6.4.x |
| IOS XE | VPNv4, VPNv6, IPv4 VRF, IPv6 VRF | IOS XE 17.x IP Routing Configuration Guide |
XRd 26.1.1, used in this article, accepts advertise best-external under the plain IPv4 unicast address-family as well, and it works as described (confirmed in STEP 5). The restriction in the older command reference does not apply to the current release. The MPLS VPN (VPNv4) form is explained in BGP Best External (MPLS VPN).
Configuration and verification on IOS XR
| Item | Detail |
|---|---|
advertise best-external | Under address-family. When the best path is an iBGP route, advertises the best external route to iBGP peers and RR clients |
show bgp <prefix> | The path chosen as Best External is marked best-external and gets an Advertised ... to peers line. Not advertised to any peer on a non-best path means it is not advertised |
show bgp neighbors <peer> advertised-routes | The routes actually advertised to that peer |
show route <prefix> / show cef <prefix> | Whether a PIC backup is installed (BGP backup path / backup) |
Verification on real devices
Verified with five XRd 26.1.1 routers.
- In AS 65001, R1 and R2 are the border routers and R3 is internal (iBGP full mesh,
next-hop-self, OSPF area 0). R1 and R2 are directly connected - R4 in AS 65002 connects to both R1 and R2 over eBGP and advertises Loopback1
192.168.4.0/24and Loopback2100.63.255.0/24. The return direction (R4 → R5) is pinned via R2 (LOCAL_PREF 200on the routes from R2, inbound at R4), so that the return traffic never uses the R1-R4 link that the failure hits and only the forward direction is measured - R5 in AS 65003 is the traffic source. Traffic from R5 to R4 goes R3 → R1 → R4
- Outbound and inbound policies have a different name per neighbor (all just
pass); every neighbor hassoft-reconfiguration inbound always
Loss during the failure is measured with pings from R5 to 192.168.4.1 and 100.63.255.1 at 100 ms intervals, and from the gap between replies in the capture on the R3-R5 link (the same method as in BGP PIC).
Overview of the verification
| STEP | Change | What to check |
|---|---|---|
| 0 | Initial state | Both R1 and R2 have their own eBGP route as best and advertise it to each other. R3 receives two |
| 1 | LOCAL_PREF 200 on the routes from R4, inbound at R1 | R2’s best becomes the iBGP route (via R1) and R2 stops advertising its own eBGP route (WITHDRAW). R3 and R1 are left with one route |
| 2 | PIC (backup 1 install) on R1 and R3 | No backup mark, since there is nothing to use |
| 3 | R1-R4 link down | Loss, because there is no backup: R1’s withdrawal → R2’s re-selection and advertisement → R3 installs it |
| 4 | Restore | |
| 5 | advertise best-external on R2 | R2 advertises its own non-best eBGP route to its iBGP peers (UPDATE, the best-external mark). R3 and R1 gain a backup |
| 6 | R1-R4 link down (with Best External) | No loss, since a backup exists |
| 7 | Restore | |
| 8 | no advertise best-external (final state) | R2’s advertisement disappears (WITHDRAW) and so does the backup |
All times in the show output and the captures below are UTC (matching the routers’ syslog).
STEP 0: Initial state
Both R1 and R2 have their own eBGP route as best and advertise it to each other over iBGP. In R2’s show bgp, the eBGP route (10.2.4.4) carries Advertised IPv4 Unicast paths to peers and is advertised to R1 and R3, and R3 receives two routes.
R2 show bgp 192.168.4.0/24 (STEP 0)
RP/0/RP0/CPU0:R2#show bgp 192.168.4.0/24
Wed Sep 16 13:25:22.272 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 4 4
Last Modified: Sep 16 12:47:14.023 for 00:38:08
Paths: (2 available, best #2)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.3 10.0.0.1
Path #1: Received by speaker 0
Not advertised to any peer
65002, (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
Received Path ID 0, Local Path ID 0, version 0
Path #2: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.3 10.0.0.1
65002, (received & used)
10.2.4.4 from 10.2.4.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 4
Origin-AS validity: (disabled)R1 show bgp 192.168.4.0/24 (STEP 0)
RP/0/RP0/CPU0:R1#show bgp 192.168.4.0/24
Wed Sep 16 13:24:30.104 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 6 6
Last Modified: Sep 16 12:47:16.023 for 00:37:14
Paths: (2 available, best #2)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.3 10.0.0.2
Path #1: Received by speaker 0
Not advertised to any peer
65002, (received & used)
10.0.0.2 (metric 2) from 10.0.0.2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
Received Path ID 0, Local Path ID 0, version 0
Path #2: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.3 10.0.0.2
65002, (received & used)
10.1.4.4 from 10.1.4.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 6
Origin-AS validity: (disabled)R3 show bgp 192.168.4.0/24 (STEP 0)
RP/0/RP0/CPU0:R3#show bgp 192.168.4.0/24
Wed Sep 16 13:26:14.746 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 7 7
Last Modified: Sep 16 12:47:18.023 for 00:38:56
Paths: (2 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
65002, (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 7
Path #2: Received by speaker 0
Not advertised to any peer
65002, (received & used)
10.0.0.2 (metric 2) from 10.0.0.2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal
Received Path ID 0, Local Path ID 0, version 0Traffic from R5 to R4 goes R3 → R1 → R4.
R5 traceroute 192.168.4.1 (STEP 0)
RP/0/RP0/CPU0:R5#traceroute 192.168.4.1 source 192.168.5.1 probe 3 timeout 1 maxttl 6
Wed Sep 16 13:28:22.320 UTC
Type escape sequence to abort.
Tracing the route to 192.168.4.1
1 10.3.5.3 7 msec 5 msec 5 msec
2 10.1.3.1 9 msec 8 msec 28 msec
3 10.1.4.4 12 msec * 13 msec STEP 1: LOCAL_PREF 200 on the routes from R4, inbound at R1
R2’s best path becomes the iBGP route from R1, and R2 stops advertising its own eBGP route.
Configuration committed on R1 in STEP 1
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Wed Sep 16 13:28:46.113 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy FROM-R4
set local-preference 200
pass
end-policy
!
endIn R2’s show bgp the best path is now the one via R1 with localpref 200, and its own eBGP route reads Not advertised to any peer.
R2 show bgp 192.168.4.0/24 (STEP 1)
RP/0/RP0/CPU0:R2#show bgp 192.168.4.0/24
Wed Sep 16 13:31:44.925 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 9 9
Last Modified: Sep 16 13:28:47.023 for 00:02:58
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 200, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 9
Path #2: Received by speaker 0
Not advertised to any peer
65002, (received & used)
10.2.4.4 from 10.2.4.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: (disabled)In the capture, 30 ms after R1 sends the LOCAL_PREF 200 route in an UPDATE, R2 sends a WITHDRAW (the two prefixes in MP_UNREACH_NLRI) to R3 and R1. R2’s exit is alive, but the other routers in the AS can no longer see it.
R2-R3 link during STEP 1 (UPDATEs from R2 to R3)
$ tshark -r bgp-best-external-step1-r2r3.pcap -t ud -Y 'bgp.type==2'
2 2026-09-16 13:28:47.539877Z 10.0.0.2 → 10.0.0.3 BGP 85 UPDATE MessageR3 and R1 are left with one route each.
R3 show bgp 192.168.4.0/24 (STEP 1)
RP/0/RP0/CPU0:R3#show bgp 192.168.4.0/24
Wed Sep 16 13:32:37.238 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 9 9
Last Modified: Sep 16 13:28:47.023 for 00:03:50
Paths: (1 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
65002, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 200, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 9R1 show bgp 192.168.4.0/24 (STEP 1)
RP/0/RP0/CPU0:R1#show bgp 192.168.4.0/24
Wed Sep 16 13:30:53.362 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 10 10
Last Modified: Sep 16 13:28:47.023 for 00:02:06
Paths: (2 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.3 10.0.0.2
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.3 10.0.0.2
65002
10.1.4.4 from 10.1.4.4 (10.0.0.4)
Origin IGP, metric 0, localpref 200, valid, external, best, group-best
Received Path ID 0, Local Path ID 1, version 10
Origin-AS validity: (disabled)
Path #2: Received by speaker 0
Not advertised to any peer
65002, (received-only)
10.1.4.4 from 10.1.4.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, external
Received Path ID 0, Local Path ID 0, version 0
Origin-AS validity: (disabled)STEP 2: PIC (backup 1 install) on R1 and R3
With no route to use as a backup, configuring PIC adds no backup mark. R3’s routing table has a single next hop, and no Number of pic paths line appears.
Configuration committed on R3 in STEP 2
RP/0/RP0/CPU0:R3#show configuration commit changes last 1
Wed Sep 16 13:35:20.308 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy PIC
set path-selection backup 1 install
end-policy
!
router bgp 65001
address-family ipv4 unicast
additional-paths selection route-policy PIC
!
!
endR3 show route 192.168.4.0/24 (STEP 2)
RP/0/RP0/CPU0:R3#show route 192.168.4.0/24
Wed Sep 16 13:39:14.906 UTC
Routing entry for 192.168.4.0/24
Known via "bgp 65001", distance 200, metric 0
Tag 65002, type internal
Installed Sep 16 13:28:47.509 for 00:10:27
Routing Descriptor Blocks
10.0.0.1, from 10.0.0.1
Route metric is 0, Wt is 1
No advertising protos. STEP 3: R1-R4 link down (without Best External)
With no backup, forwarding stops until R2’s route has spread through the AS. Shutting down R1’s Gi0/0/0/2 (the R4 side is shut as well) makes R1 send a WITHDRAW to R2; R2 then re-selects its own eBGP route as best and advertises it to R1 and R3.
R1 show logging (STEP 3)
RP/0/RP0/CPU0:R1#show logging start Sep 16 13:37:54
Wed Sep 16 13:45:42.363 UTC
Time Zone UTC, DST disabled
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: Disabled
Monitor logging: level debugging, 0 messages logged
Trap logging: level informational, 0 messages logged
Buffer logging: level debugging, 158 messages logged
Log Buffer (2097152 bytes):
RP/0/RP0/CPU0:Sep 16 13:37:54.525 UTC: logger[68497]: %OS-SYSLOG-6-LOG_INFO : informational STEP3-BEGIN
RP/0/RP0/CPU0:Sep 16 13:37:54.918 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11107]: Received disconnect from 10.100.3.1 port 50706:11: disconnected by user
RP/0/RP0/CPU0:Sep 16 13:37:54.918 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11107]: Disconnected from user cisco 10.100.3.1 port 50706
RP/0/RP0/CPU0:Sep 16 13:41:58.111 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11495]: Accepted authentication/pam for cisco from 10.100.3.1 port 51046 ssh2
RP/0/RP0/CPU0:Sep 16 13:42:02.703 UTC: ifmgr[155]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/2, changed state to Administratively Down
RP/0/RP0/CPU0:Sep 16 13:42:02.707 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.1.4.4 Down - Admin. shutdown (CEASE notification sent - administrative shutdown) (VRF: default) (AS: 65002)
RP/0/RP0/CPU0:Sep 16 13:42:03.132 UTC: config[68893]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000005' to view the changes.
RP/0/RP0/CPU0:Sep 16 13:42:03.327 UTC: config[68893]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco on vty0 (10.100.3.1)
RP/0/RP0/CPU0:Sep 16 13:42:05.334 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11500]: Received disconnect from 10.100.3.1 port 51046:11: disconnected by user
RP/0/RP0/CPU0:Sep 16 13:42:05.334 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11500]: Disconnected from user cisco 10.100.3.1 port 51046
RP/0/RP0/CPU0:Sep 16 13:45:24.732 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11852]: Accepted authentication/pam for cisco from 10.100.3.1 port 51339 ssh2
RP/0/RP0/CPU0:Sep 16 13:45:39.023 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11868]: Received disconnect from 10.100.3.1 port 51339:11: disconnected by user
RP/0/RP0/CPU0:Sep 16 13:45:39.023 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[11868]: Disconnected from user cisco 10.100.3.1 port 51339
RP/0/RP0/CPU0:Sep 16 13:45:40.116 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[12068]: Accepted authentication/pam for cisco from 10.100.3.1 port 51349 ssh2 R1-R2 link during STEP 3 (WITHDRAW from R1 to R2, then UPDATE from R2 to R1)
$ tshark -r bgp-best-external-step3-r1r2.pcap -t ud -Y 'bgp.type==2'
9 2026-09-16 13:42:02.905376Z 10.0.0.1 → 10.0.0.2 BGP 85 UPDATE Message
10 2026-09-16 13:42:02.939058Z 10.0.0.2 → 10.0.0.1 BGP 125 UPDATE MessageR2-R3 link during STEP 3 (UPDATE from R2 to R3)
$ tshark -r bgp-best-external-step3-r2r3.pcap -t ud -Y 'bgp.type==2'
307 2026-09-16 13:42:02.935153Z 10.0.0.2 → 10.0.0.3 BGP 125 UPDATE MessageFrom the link going down (13:42:02.703) to R2’s re-advertisement (13:42:02.935) is 0.23 s, but replies came back only at 13:42:03.928, once R3 had installed it: a gap of 1.12 s. The pings at 100 ms intervals lost 1 of 900.
R5 ping 192.168.4.1 (STEP 3, 100 ms interval)
RP/0/RP0/CPU0:R5#ping 192.168.4.1 source 192.168.5.1 count 900 interval 100 timeout 1
Wed Sep 16 13:41:44.291 UTC
Type escape sequence to abort.
Sending 900, 100-byte ICMP Echos to 192.168.4.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (899/900), round-trip min/avg/max = 8/16/94 msR5 ping 100.63.255.1 (STEP 3, 100 ms interval)
RP/0/RP0/CPU0:R5#ping 100.63.255.1 source 192.168.5.1 count 900 interval 100 timeout 1
Wed Sep 16 13:41:48.992 UTC
Type escape sequence to abort.
Sending 900, 100-byte ICMP Echos to 100.63.255.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (899/900), round-trip min/avg/max = 9/15/93 msSTEP 4: Restore
Both ends are set to no shutdown, back to the state of STEP 2.
STEP 5: advertise best-external on R2
R2 advertises its own non-best eBGP route to its iBGP peers, and R3 and R1 get their backup back. The configuration is one line under address-family.
Configuration committed on R2 in STEP 5
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 16 13:56:10.659 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
address-family ipv4 unicast
advertise best-external
!
!
endIn R2’s show bgp the eBGP route is now marked best-external and the Advertised IPv4 Unicast paths to peers line is back. The best path is still the one via R1.
R2 show bgp 192.168.4.0/24 (STEP 5)
RP/0/RP0/CPU0:R2#show bgp 192.168.4.0/24
Wed Sep 16 13:59:09.675 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 16 16
Last Modified: Sep 16 13:56:12.023 for 00:02:57
Paths: (2 available, best #1)
Not advertised to any peer
Path #1: Received by speaker 0
Not advertised to any peer
65002, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 200, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 14
Path #2: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.0.0.3 10.0.0.1
65002, (received & used)
10.2.4.4 from 10.2.4.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, external, best-external
Received Path ID 0, Local Path ID 2, version 16
Origin-AS validity: (disabled)The capture holds the UPDATE R2 sent to R3 right after the commit (the two prefixes with LOCAL_PREF 100).
R2-R3 link during STEP 5 (UPDATE from R2 to R3)
$ tshark -r bgp-best-external-step5-r2r3.pcap -t ud -Y 'bgp.type==2'
2 2026-09-16 13:56:11.824278Z 10.0.0.2 → 10.0.0.3 BGP 125 UPDATE MessageR3 receives the route via R2, and the PIC configured in STEP 2 makes it the backup (backup, add-path, BGP backup path). The same happens on R1.
R3 show bgp 192.168.4.0/24 (STEP 5)
RP/0/RP0/CPU0:R3#show bgp 192.168.4.0/24
Wed Sep 16 14:00:02.113 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 19 19
Last Modified: Sep 16 13:56:12.023 for 00:03:50
Paths: (2 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
65002, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 200, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 16
Path #2: Received by speaker 0
Not advertised to any peer
65002, (received & used)
10.0.0.2 (metric 2) from 10.0.0.2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, internal, backup, add-path
Received Path ID 0, Local Path ID 3, version 19R3 show route 192.168.4.0/24 (STEP 5)
RP/0/RP0/CPU0:R3#show route 192.168.4.0/24
Wed Sep 16 14:00:04.028 UTC
Routing entry for 192.168.4.0/24
Known via "bgp 65001", distance 200, metric 0
Tag 65002
Number of pic paths 1 , type internal
Installed Sep 16 13:56:11.827 for 00:03:52
Routing Descriptor Blocks
10.0.0.1, from 10.0.0.1
Route metric is 0, Wt is 1
10.0.0.2, from 10.0.0.2, BGP backup path
Route metric is 0, Wt is 1
No advertising protos. R1 show cef 192.168.4.0/24 (STEP 5)
RP/0/RP0/CPU0:R1#show cef 192.168.4.0/24
Wed Sep 16 13:58:20.239 UTC
192.168.4.0/24, version 54, internal 0x5000001 0x40 (ptr 0x8851a380) [1], 0x0 (0x0), 0x0 (0x0)
Updated Sep 16 13:56:11.847
local adjacency to GigabitEthernet0/0/0/2
Prefix Len 24, traffic index 0, precedence n/a, priority 4
gateway array (0x8938b008) reference count 2, flags 0x102010, source rib (7), 0 backups
[1 type 3 flags 0x48501 (0x8942df60) ext 0x0 (0x0) (collapsed)]
LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
gateway array update type-time 1 Sep 16 13:56:11.831
LDI Update time Sep 16 13:56:11.847
via 10.0.0.2/32, 3 dependencies, recursive, backup [flags 0x6100]
path-idx 0 NHID 0x0 [0x8851b0f0 0x0]
next hop 10.0.0.2/32 via 10.0.0.2/32
via 10.1.4.4/32, 2 dependencies, recursive, bgp-ext [flags 0x6020]
path-idx 1 NHID 0x0 [0x8851b470 0x0], Internal 0x8a9b80a0
next hop 10.1.4.4/32 via 10.1.4.4/32
Weight distribution:
slot 0, weight 1, normalized_weight 1, class 0
Load distribution: 0 (refcount 1)
Hash OK Interface Address
0 Y GigabitEthernet0/0/0/2 10.1.4.4 STEP 6: R1-R4 link down (with Best External)
The same failure, and this time no loss. All 900 pings to both destinations were answered, and the largest gap between replies in the capture is 0.21 s.
R5 ping 192.168.4.1 (STEP 6, 100 ms interval)
RP/0/RP0/CPU0:R5#ping 192.168.4.1 source 192.168.5.1 count 900 interval 100 timeout 1
Wed Sep 16 14:03:22.827 UTC
Type escape sequence to abort.
Sending 900, 100-byte ICMP Echos to 192.168.4.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (900/900), round-trip min/avg/max = 9/17/173 msR5 ping 100.63.255.1 (STEP 6, 100 ms interval)
RP/0/RP0/CPU0:R5#ping 100.63.255.1 source 192.168.5.1 count 900 interval 100 timeout 1
Wed Sep 16 14:03:27.390 UTC
Type escape sequence to abort.
Sending 900, 100-byte ICMP Echos to 100.63.255.1 timeout is 1 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (900/900), round-trip min/avg/max = 8/17/136 msR1’s interface goes down at 14:03:40.850, and 56 ms later (14:03:40.906) the packets from R5 appear on the R1-R2 link: R1’s FIB switched to the route via R2 (the backup) that it had received through Best External. In STEP 3 that route did not exist at all, and R1 had to wait for R2’s re-advertisement.
R1 show logging (STEP 6)
RP/0/RP0/CPU0:R1#show logging start Sep 16 13:58:43
Wed Sep 16 14:07:18.756 UTC
Time Zone UTC, DST disabled
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: Disabled
Monitor logging: level debugging, 0 messages logged
Trap logging: level informational, 0 messages logged
Buffer logging: level debugging, 223 messages logged
Log Buffer (2097152 bytes):
RP/0/RP0/CPU0:Sep 16 13:58:43.926 UTC: logger[67558]: %OS-SYSLOG-6-LOG_INFO : informational STEP6-BEGIN
RP/0/RP0/CPU0:Sep 16 13:58:44.330 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[14263]: Received disconnect from 10.100.3.1 port 52989:11: disconnected by user
RP/0/RP0/CPU0:Sep 16 13:58:44.330 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[14263]: Disconnected from user cisco 10.100.3.1 port 52989
RP/0/RP0/CPU0:Sep 16 14:03:37.108 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[14723]: Accepted authentication/pam for cisco from 10.100.3.1 port 53249 ssh2
RP/0/RP0/CPU0:Sep 16 14:03:40.850 UTC: ifmgr[155]: %PKT_INFRA-LINK-5-CHANGED : Interface GigabitEthernet0/0/0/2, changed state to Administratively Down
RP/0/RP0/CPU0:Sep 16 14:03:40.851 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.1.4.4 Down - Admin. shutdown (CEASE notification sent - administrative shutdown) (VRF: default) (AS: 65002)
RP/0/RP0/CPU0:Sep 16 14:03:41.152 UTC: config[68025]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000007' to view the changes.
RP/0/RP0/CPU0:Sep 16 14:03:41.251 UTC: config[68025]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco on vty0 (10.100.3.1)
RP/0/RP0/CPU0:Sep 16 14:03:43.149 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[14728]: Received disconnect from 10.100.3.1 port 53249:11: disconnected by user
RP/0/RP0/CPU0:Sep 16 14:03:43.149 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[14728]: Disconnected from user cisco 10.100.3.1 port 53249
RP/0/RP0/CPU0:Sep 16 14:07:02.413 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[15036]: Accepted authentication/pam for cisco from 10.100.3.1 port 53412 ssh2
RP/0/RP0/CPU0:Sep 16 14:07:15.625 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[15041]: Received disconnect from 10.100.3.1 port 53412:11: disconnected by user
RP/0/RP0/CPU0:Sep 16 14:07:15.625 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[15041]: Disconnected from user cisco 10.100.3.1 port 53412
RP/0/RP0/CPU0:Sep 16 14:07:16.452 UTC: ssh_syslog_proxy[1188]: %SECURITY-SSHD_SYSLOG_PRX-6-INFO_GENERAL : sshd[15223]: Accepted authentication/pam for cisco from 10.100.3.1 port 53421 ssh2 R1-R2 link during STEP 6 (Echo requests from R5, rerouted by R1 to R2)
$ tshark -r bgp-best-external-step6-r1r2.pcap -t ud -Y 'icmp.type==8'
5 2026-09-16 14:03:40.906320Z 192.168.5.1 → 100.63.255.1 ICMP 114 Echo (ping) request id=0x3973, seq=124/31744, ttl=253
6 2026-09-16 14:03:40.908027Z 192.168.5.1 → 100.63.255.1 ICMP 114 Echo (ping) request id=0x3973, seq=124/31744, ttl=252
7 2026-09-16 14:03:40.909325Z 192.168.5.1 → 100.63.255.1 ICMP 114 Echo (ping) request id=0x3973, seq=124/31744, ttl=251
8 2026-09-16 14:03:40.911463Z 192.168.5.1 → 100.63.255.1 ICMP 114 Echo (ping) request id=0x3973, seq=124/31744, ttl=250
9 2026-09-16 14:03:40.912680Z 192.168.5.1 → 100.63.255.1 ICMP 114 Echo (ping) request id=0x3973, seq=124/31744, ttl=249
10 2026-09-16 14:03:40.914636Z 192.168.5.1 → 100.63.255.1 ICMP 114 Echo (ping) request id=0x3973, seq=124/31744, ttl=248
<snip>（以下 18 行）STEP 7: Restore
Both ends are set to no shutdown, back to the state of STEP 5.
STEP 8: no advertise best-external (final state)
Removing the configuration makes R2 send a WITHDRAW to R3 and R1; R3’s backup disappears and the state returns to that of STEP 2.
Configuration committed on R2 in STEP 8
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Wed Sep 16 14:17:47.153 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65001
address-family ipv4 unicast
no advertise best-external
!
!
endR2-R3 link during STEP 8 (WITHDRAW from R2 to R3)
$ tshark -r bgp-best-external-step8-r2r3.pcap -t ud -Y 'bgp.type==2'
3 2026-09-16 14:17:48.424068Z 10.0.0.2 → 10.0.0.3 BGP 85 UPDATE MessageR3 show bgp 192.168.4.0/24 (STEP 8)
RP/0/RP0/CPU0:R3#show bgp 192.168.4.0/24
Wed Sep 16 14:21:38.105 UTC
BGP routing table entry for 192.168.4.0/24
Versions:
Process bRIB/RIB SendTblVer
Speaker 25 25
Last Modified: Sep 16 14:17:48.023 for 00:03:50
Paths: (1 available, best #1)
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
Path #1: Received by speaker 0
Advertised IPv4 Unicast paths to peers (in unique update groups):
10.3.5.5
65002, (received & used)
10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
Origin IGP, metric 0, localpref 200, valid, internal, best, group-best
Received Path ID 0, Local Path ID 1, version 24Verification config and show output
In each STEP the following files were collected from all five routers, one set per router. The verification config is ..._run.txt (the final state is the one from STEP 8).
| File | Contents |
|---|---|
..._show.txt | show bgp summary / show bgp / show route bgp / show bgp <prefix> (192.168.1.0/24 to 192.168.5.0/24 and 100.63.255.0/24) / show route summary / show route and show cef (192.168.4.0/24, 100.63.255.0/24, 192.168.5.0/24, 10.0.0.1/32, 10.0.0.2/32) / show bgp neighbors / show bgp process / show rpl route-policy / advertised-routes / routes / received routes per peer. R1-R3 also show ospf neighbor / show route ospf |
..._log.txt | show logging limited to that STEP. A logmsg marker is put at the start of each STEP and its time is given to show logging start |
..._run.txt | show running-config at that STEP (= the verification config of the STEP) |
..._ping.txt / ..._ping2.txt | ping and traceroute from R5 to 192.168.4.1 and 100.63.255.1. In the failure STEPs (3, 6), 900 pings at 100 ms intervals per destination, started before the failure (_ping.txt for 192.168.4.1, _ping2.txt for 100.63.255.1); 50 pings otherwise |
..._trace.txt | show bgp trace neighbor / show bgp trace error |
..._commit.cfg | Only the configuration actually committed in that STEP. Only for routers whose configuration changed |
STEP 0: Initial state
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | - |
| R2 | show | log | run | - | trace | - |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | - |
| R5 | show | log | run | ping | trace | - |
STEP 1: LOCAL_PREF 200 on the routes from R4, inbound at R1
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | cfg |
| R2 | show | log | run | - | trace | - |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | - |
| R5 | show | log | run | ping | trace | - |
STEP 2: PIC (backup 1 install) on R1 and R3
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | cfg |
| R2 | show | log | run | - | trace | - |
| R3 | show | log | run | - | trace | cfg |
| R4 | show | log | run | - | trace | - |
| R5 | show | log | run | ping | trace | - |
STEP 3: R1-R4 link down (without Best External)
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | cfg |
| R2 | show | log | run | - | trace | - |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | cfg |
| R5 | show | log | run | ping / ping2 | trace | - |
STEP 4: Restore
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | cfg |
| R2 | show | log | run | - | trace | - |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | cfg |
| R5 | show | log | run | ping | trace | - |
STEP 5: advertise best-external on R2
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | - |
| R2 | show | log | run | - | trace | cfg |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | - |
| R5 | show | log | run | ping | trace | - |
STEP 6: R1-R4 link down (with Best External)
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | cfg |
| R2 | show | log | run | - | trace | - |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | cfg |
| R5 | show | log | run | ping / ping2 | trace | - |
STEP 7: Restore
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | cfg |
| R2 | show | log | run | - | trace | - |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | cfg |
| R5 | show | log | run | ping | trace | - |
STEP 8: no advertise best-external (final state)
| Router | show output | syslog | running-config | ping | trace | commit |
|---|---|---|---|---|---|---|
| R1 | show | log | run | - | trace | - |
| R2 | show | log | run | - | trace | cfg |
| R3 | show | log | run | - | trace | - |
| R4 | show | log | run | - | trace | - |
| R5 | show | log | run | ping | trace | - |
Packet captures were taken per STEP on the R3-R5 link (R5’s pings, used to measure the gaps between replies), the R1-R2 link and the R2-R3 link.
| STEP | R3-R5 | R1-R2 | R2-R3 |
|---|---|---|---|
| 0 | pcap | pcap | pcap |
| 1 | pcap | pcap | pcap |
| 2 | pcap | pcap | pcap |
| 3 | pcap | pcap | pcap |
| 4 | pcap | pcap | pcap |
| 5 | pcap | pcap | pcap |
| 6 | pcap | pcap | pcap |
| 7 | pcap | pcap | pcap |
| 8 | pcap | pcap | pcap |
References
| Source | Title | Summary |
|---|---|---|
| RFC 4271 | A Border Gateway Protocol 4 (BGP-4) | 9.1.3: only the best path is advertised |
| draft-ietf-idr-best-external-05 | Advertisement of the best external route in BGP | The Best External procedure and its benefits (expired draft) |
| Cisco ASR 9000 Routing Command Reference, IOS XR 6.4.x | advertise best-external | The address families the guide of that release lists, and why unlabeled can loop (XRd 26.1.1 accepts it in IPv4 unicast too) |
| Cisco IOS XE 17.x IP Routing Configuration Guide | BGP Best External | The active-backup topology and the VPNv4 / VRF restriction |
Related articles
- BGP (Border Gateway Protocol)
- BGP Messages
- BGP Neighbor States
- iBGP and eBGP
- BGP next-hop-self
- BGP Route Reflector
- BGP Path Attributes and Best Path Selection
- BGP ORIGIN Attribute
- BGP AS_PATH Attribute
- BGP NEXT_HOP Attribute
- BGP LOCAL_PREF Attribute
- BGP MED Attribute
- BGP WEIGHT Attribute
- BGP COMMUNITY Attribute
- BGP Route Aggregation (aggregate-address)
- MP-BGP (Multiprotocol Extensions)
- BGP Extended Community
- BGP Multipath (maximum-paths)
- BGP Four-Octet AS Numbers (RFC 6793)
- Removing Private AS Numbers in BGP (remove-private-AS)
- BGP ADD-PATH (RFC 7911)
- BGP PIC (Prefix Independent Convergence)
- BGP Best External (advertising a non-best external route)