BGP AS_PATH Attribute

What AS_PATH Is

AS_PATH (Type code 2) is the path attribute that records which ASes a route has traversed, as a list of AS numbers. As covered in BGP Path Attributes and Best Path Selection, it is classified as well-known mandatory and is always present in an UPDATE.

This attribute is why BGP is called a “path vector” protocol. Instead of a numeric distance or cost, it carries the sequence of traversed ASes itself as the route’s identity.

AS_PATH serves two purposes at once.

Purpose	Description
Loop detection	If a received route’s `AS_PATH` contains the local AS number, the route has already passed through this AS, so it is treated as a loop and discarded
Path length comparison	In best path selection, the route with fewer AS numbers in its `AS_PATH` is preferred

How It Grows on eBGP and iBGP

AS_PATH grows only when advertising to an eBGP peer. Nothing is added when advertising to an iBGP peer.

Advertised to	Behavior
eBGP peer	Prepend the local AS number to the front of `AS_PATH` and send
iBGP peer	Send `AS_PATH` unchanged (the local AS number is not added)

If routers within the same AS added their AS number to each other, the length would vary with how many routers the route crossed inside the AS, breaking its meaning as a per-AS distance.

A route you originate with network travels through your own AS with an empty AS_PATH. That is why the Path column of show bgp is blank except for the trailing Origin code.

A route R1 originates itself (AS_PATH is empty)
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i

Segment Types

AS_PATH is encoded as a sequence of “segments”. Segments have a type, and the one you normally see is AS_SEQUENCE.

Type	Value	Meaning
`AS_SET`	1	An unordered set of ASes. Used when route aggregation (`aggregate-address`) merges multiple routes, to list the ASes the original routes traversed without duplication
`AS_SEQUENCE`	2	An ordered list of ASes. This is what normal route propagation produces

tshark -V expands the segment type and element count, so the breakdown of the value is directly readable.

AS_PATH expanded by tshark -V
        Path Attribute - AS_PATH: 65002 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65002 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65002
                AS4: 65001

For length calculation, an AS_SET counts as 1 no matter how many ASes it holds. This keeps an aggregated route’s AS_PATH from becoming unnaturally short.

Loop Detection

If a route received over eBGP has the local AS number in its AS_PATH, the route is discarded. Rather than stopping loops with a hop count limit as distance vector protocols do, the route itself carries enough information to detect the loop — the advantage of a path vector protocol.

At which stage of reception this discard happens, and what becomes visible when you deliberately disable it with allowas-in, is covered in the hands-on verification of BGP (Border Gateway Protocol).

Position in Best Path Selection

AS_PATH length is compared fourth in best path selection. It takes effect when WEIGHT, LOCAL_PREF, and locally originated routes have not settled the decision.

What matters is that it is evaluated before MULTI_EXIT_DISC (sixth). If you set both, the comparison ends as soon as AS_PATH length differs, so MED is never examined.

Note that only the length is compared; which AS numbers are in it does not matter. To make AS_PATH length be ignored, use bgp bestpath as-path ignore — but this does not disable loop detection.

Inbound Traffic Engineering with AS_PATH Prepending

When you want to steer which path traffic takes into your AS, adding extra copies of your own AS number in an eBGP outbound policy is called AS_PATH prepending. The route looks longer from the other side, so that link becomes less likely to be chosen.

On IOS XR you write it with RPL (Routing Policy Language) as prepend as-path own-as <count>.

Adding one extra copy of the local AS number (IOS XR, from show running-config)
route-policy PREPEND-1
  prepend as-path own-as 1
  pass
end-policy
!
<snip>
 neighbor 10.1.3.3
  remote-as 65002
  description eBGP to R3
  address-family ipv4 unicast
   route-policy PASS-ALL in
   route-policy PREPEND-1 out
   soft-reconfiguration inbound always
  !
 !

The configuration commands themselves are covered in IOS XR BGP Route Policy.

Difference from MED

MED is another way to influence inbound traffic, and for simply choosing an entry point in the adjacent AS, both produce the same result. The decisive difference is how far the influence reaches.

Aspect	MED	AS_PATH prepending
Reach	Only the adjacent AS. The receiving AS does not propagate it further	Travels with `AS_PATH`, so it reaches distant ASes
Comparison condition	Only compared among routes learned from the same neighboring AS	No condition. All routes’ lengths are compared
Selection order	Sixth	Fourth
Side effects	Contained within the adjacent AS	Can affect the selection of every AS the route passes through

MED is a demanding attribute: it only applies when routes with the same AS_PATH length and the same ORIGIN arrive from the same neighboring AS. Prepending, on the other hand, rewrites AS_PATH itself — an attribute that propagates — so it takes effect in ASes beyond the one you intended. We verify this difference on real devices.

Hands-on Verification

Using a lab of five XRd (IOS XR 26.1.1) routers, we confirm four points.

When MED changes the entry point in the adjacent AS, ASes beyond it are unaffected
Doing the same with AS_PATH prepending changes the adjacent AS’s entry point in the same way
Lengthening both exits changes the selection of the AS two hops away
Removing the policy does not restore the best path automatically; a session reset is required

AS_PATH verification topology. From AS 65001 (R1 and R2, iBGP and OSPF area 0) there are two links to AS 65002 (R3) via R1 and R2, and one link from R2 to AS 65003 (R4). AS 65004 (R5) connects to both AS 65002 and AS 65003

Key points of the topology:

R1 advertises 192.168.1.0/24. We follow how this route looks from the other ASes
AS 65002 (R3) connects to AS 65001 over two links (via R1 and via R2). Since both come from the same neighboring AS, MED comparison applies
AS 65004 (R5) is not directly connected to AS 65001. It has two choices, via AS 65002 and via AS 65003, and both have an AS_PATH length of 2. This is the “distant AS”

What each STEP changes:

STEP	Operation
0	No policy (initial state)
1	MED 200 on R1→R3, MED 50 on R2→R3
2	Remove MED, apply prepend ×1 on R1→R3
3	Also apply prepend ×1 on R2→R3 (lengthen both exits)
4	Remove the prepends (configuration returns to be identical to STEP 0)
5	Reset the BGP sessions

Packet captures were taken on the R1 - R3 and R3 - R5 links (tcp port 179).

STEP 0: Initial State

192.168.1.0/24 as seen from R3. There are two paths, via R1 (10.1.3.1) and via R2 (10.2.3.2), and both have AS_PATH of a single 65001.

R3 (AS 65002): show bgp 192.168.1.0/24
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  7            7
Last Modified: Sep  6 21:55:55.774 for 00:10:38
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001, (received & used)
    10.1.3.1 from 10.1.3.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 7
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  65001, (received & used)
    10.2.3.2 from 10.2.3.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Neither AS_PATH length, ORIGIN, nor MED makes a difference, and since both are eBGP the IGP metric is not compared either, so the decision falls through to the ninth criterion, “route age”, and the path via R1 wins.

Now AS 65004 (R5), two hops away. 192.168.1.0/24 arrives via AS 65002 (65002 65001) and via AS 65003 (65003 65001), both of length 2.

R5 (AS 65004): show bgp
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.1.0/24     10.3.5.3                               0 65002 65001 i
*                     10.4.5.4                               0 65003 65001 i
*  192.168.2.0/24     10.3.5.3                               0 65002 65001 i
*>                    10.4.5.4                               0 65003 65001 i
*> 192.168.3.0/24     10.3.5.3                 0             0 65002 i
*                     10.4.5.4                               0 65003 65001 65002 i
*  192.168.4.0/24     10.3.5.3                               0 65002 65001 65003 i
*>                    10.4.5.4                 0             0 65003 i
*> 192.168.5.0/24     0.0.0.0                  0         32768 i

Processed 5 prefixes, 9 paths

A traceroute from R5. It enters AS 65002 (10.3.5.3 = R3) and exits directly to R1 (10.1.3.1).

R5: traceroute 192.168.1.1 source Loopback1
Type escape sequence to abort.
Tracing the route to 192.168.1.1

 1  10.3.5.3 9 msec  6 msec  5 msec 
 2  10.1.3.1 9 msec  *  9 msec

STEP 1: Changing the Adjacent AS’s Entry Point with MED

As a baseline, let us first do the same thing with MED. We attach MED 200 to routes R1 advertises to R3, and MED 50 to routes R2 advertises to R3.

R1: show running-config (R2 has MED-50 with set med 50 in the same shape)
route-policy MED-200
  set med 200
  pass
end-policy
!
<snip>
 neighbor 10.1.3.3
  remote-as 65002
  description eBGP to R3
  address-family ipv4 unicast
   route-policy PASS-ALL in
   route-policy MED-200 out
   soft-reconfiguration inbound always
  !
 !

R3’s best path moved to the one via R2 (10.2.3.2). AS_PATH is still 65001 on both, so the tie is broken by MED at the sixth criterion.

R3: show bgp 192.168.1.0/24 (after applying MED)
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 14           14
Last Modified: Sep  6 22:23:59.774 for 00:00:52
Paths: (2 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001, (received & used)
    10.1.3.1 from 10.1.3.1 (10.0.0.1)
      Origin IGP, metric 200, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001, (received & used)
    10.2.3.2 from 10.2.3.2 (10.0.0.2)
      Origin IGP, metric 50, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 14
      Origin-AS validity: (disabled)

The packet shows MULTI_EXIT_DISC set to 200. AS_PATH remains a single 65001.

No.99 UPDATE from R1 to R3 (tshark -V, the 192.168.1.0/24 portion)
        Path Attribute - AS_PATH: 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65001
        Path Attribute - MULTI_EXIT_DISC: 200
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 200

Download the pcap of the packet in the tshark output above (No.99 UPDATE)

Meanwhile, nothing changed on R5, two hops away. The best path is still via AS 65002, and the Metric column is blank.

R5: show bgp 192.168.1.0/24 (after MED, unchanged)
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  7            7
Last Modified: Sep  6 21:56:23.774 for 00:28:55
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65002 65001, (received & used)
    10.3.5.3 from 10.3.5.3 (10.0.0.3)
      Origin IGP, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 7
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  65003 65001, (received & used)
    10.4.5.4 from 10.4.5.4 (10.0.0.4)
      Origin IGP, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Last Modified is still at the STEP 0 time (21:56:23) — the fact that AS 65001 changed anything never reached R5. MED does not cross AS boundaries, so R3 does not pass the MED it received on to R5.

The traffic path does change, however. R5’s traceroute keeps the same first hop (entering R3), but the exit within AS 65002 moved to 10.2.3.2 (R2).

R5: traceroute (after applying MED)
Type escape sequence to abort.
Tracing the route to 192.168.1.1

 1  10.3.5.3 6 msec  5 msec  5 msec 
 2  10.2.3.2 8 msec  8 msec  9 msec 
 3  10.1.2.1 23 msec  *  13 msec

The packets take a different route even though BGP’s path selection did not change — because the decision inside AS 65002 changed. As far as R5 is concerned, it still goes through AS 65002.

STEP 2: Doing the Same with AS_PATH Prepending

We remove MED and instead apply one prepend on R1’s outbound toward R3.

R1: show running-config (MED-200 has been removed)
route-policy PREPEND-1
  prepend as-path own-as 1
  pass
end-policy
!
<snip>
 neighbor 10.1.3.3
  remote-as 65002
  description eBGP to R3
  address-family ipv4 unicast
   route-policy PASS-ALL in
   route-policy PREPEND-1 out
   soft-reconfiguration inbound always
  !
 !

The AS_PATH of routes R1 advertises to R3 became 65001 65001. Both 192.168.1.0/24, which R1 originates itself, and 192.168.2.0/24 and 192.168.4.0/24, which it received from R2 and is transiting, were lengthened without distinction.

R1: show bgp neighbors 10.1.3.3 advertised-routes
Network            Next Hop        From            AS Path
192.168.1.0/24     10.1.3.1        Local           65001 65001i
192.168.2.0/24     10.1.3.1        10.0.0.2        65001 65001i
192.168.4.0/24     10.1.3.1        10.0.0.2        65001 65001 65003i

Processed 3 prefixes, 3 paths

In the packet, the AS_PATH segment length is 2 and two AS4: 65001 entries are lined up. MED is back to 0.

No.126 UPDATE from R1 to R3 (tshark -V, the 192.168.1.0/24 portion)
        Path Attribute - AS_PATH: 65001 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65001 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65001
                AS4: 65001
        Path Attribute - MULTI_EXIT_DISC: 0
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 0

Download the pcap of the packet in the tshark output above (No.126 UPDATE)

R3’s best path moved to the one via R2. Same outcome as STEP 1, but decided at a different stage: this time at the fourth criterion, AS_PATH length (2 versus 1), never reaching MED.

R3: show bgp 192.168.1.0/24 (after applying the prepend)
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 17           17
Last Modified: Sep  6 22:30:26.774 for 00:02:06
Paths: (2 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001 65001, (received & used)
    10.1.3.1 from 10.1.3.1 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001, (received & used)
    10.2.3.2 from 10.2.3.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 17
      Origin-AS validity: (disabled)

And R5, as in STEP 1, is unchanged.

R5: show bgp (only one prepend, unchanged)
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.1.0/24     10.3.5.3                               0 65002 65001 i
*                     10.4.5.4                               0 65003 65001 i
*  192.168.2.0/24     10.3.5.3                               0 65002 65001 i
*>                    10.4.5.4                               0 65003 65001 i
*> 192.168.3.0/24     10.3.5.3                 0             0 65002 i
*                     10.4.5.4                               0 65003 65001 65002 i
*  192.168.4.0/24     10.3.5.3                               0 65002 65001 65003 i
*>                    10.4.5.4                 0             0 65003 i
*> 192.168.5.0/24     0.0.0.0                  0         32768 i

Processed 5 prefixes, 9 paths

The AS_PATH R5 receives is still 65002 65001. R3 selected the path via R2 (the one that was not lengthened) as its best path and advertises only that best path to R5. The lengthened 65001 65001 merely stays as a candidate inside R3 and never leaves.

So far, MED and prepending have produced the same result: changing the entry point in the adjacent AS.

STEP 3: Lengthening Both Exits to Move a Distant AS

We apply the same prepend on R2’s outbound toward R3 as well. Now both exits from AS 65001 toward AS 65002 are lengthened.

R2: show running-config (PREPEND-1 is identical to R1's)
 neighbor 10.2.3.3
  remote-as 65002
  description eBGP to R3
  address-family ipv4 unicast
   route-policy PASS-ALL in
   route-policy PREPEND-1 out
   soft-reconfiguration inbound always
  !
 !

Both of R3’s paths are now 65001 65001, so whichever one R3 picks, the AS_PATH it advertises to R5 has three entries.

R3: show bgp neighbors 10.3.5.5 advertised-routes
Network            Next Hop        From            AS Path
192.168.1.0/24     10.3.5.3        10.1.3.1        65002 65001 65001i
192.168.2.0/24     10.3.5.3        10.1.3.1        65002 65001 65001i
192.168.3.0/24     10.3.5.3        Local           65002i
192.168.4.0/24     10.3.5.3        10.3.5.5        65002 65004 65003i
192.168.5.0/24     10.3.5.3        10.3.5.5        65002 65004i

Processed 5 prefixes, 5 paths

In this UPDATE as it reaches AS 65004, the single prepend configured by AS 65001 has been carried past AS 65002 all the way to AS 65004.

No.168 UPDATE from R3 to R5 (tshark -V, the 192.168.1.0/24 portion)
        Path Attribute - AS_PATH: 65002 65001 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 14
            AS Path segment: 65002 65001 65001
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 3
                AS4: 65002
                AS4: 65001
                AS4: 65001

Download the pcap of the packet in the tshark output above (No.168 UPDATE)

R5’s best path switched to the one via AS 65003 (10.4.5.4). Via AS 65002 it is 3 entries, via AS 65003 it is 2, so the fourth criterion, AS_PATH length, decides it.

R5: show bgp (two prepends)
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.1.0/24     10.3.5.3                               0 65002 65001 65001 i
*>                    10.4.5.4                               0 65003 65001 i
*  192.168.2.0/24     10.3.5.3                               0 65002 65001 65001 i
*>                    10.4.5.4                               0 65003 65001 i
*> 192.168.3.0/24     10.3.5.3                 0             0 65002 i
*                     10.4.5.4                               0 65003 65001 65002 i
*> 192.168.4.0/24     10.4.5.4                 0             0 65003 i
*> 192.168.5.0/24     0.0.0.0                  0         32768 i

Processed 5 prefixes, 8 paths

The traceroute changed from the very first hop. AS 65004, which is not directly connected to AS 65001, changed its choice of neighboring AS because of AS 65001’s configuration.

R5: traceroute (two prepends)
Type escape sequence to abort.
Tracing the route to 192.168.1.1

 1  10.4.5.4 6 msec  8 msec  5 msec 
 2  10.2.4.2 8 msec  8 msec  8 msec 
 3  10.1.2.1 10 msec  *  12 msec

With MED in STEP 1, R5’s traceroute kept 10.3.5.3 as its first hop (via AS 65002). With prepending, that hop moves. This is the decisive difference from MED.

Prepending takes effect beyond your intended target. In this lab it changed AS 65004’s route, but on the real Internet every AS the AS_PATH reaches is affected. If you only want to adjust the entry point in the adjacent AS, MED — which does not propagate — has smaller side effects.

The side effects are not limited to this prefix. R3’s (AS 65002’s) 192.168.4.0/24 also flipped: the path via AS 65001 grew to 65001 65001 65003 (3 entries) and lost to 65004 65003 (2 entries) via AS 65004. That is why 192.168.4.0/24 shows 10.3.5.5 (R5) in the From column of the advertised-routes output above. A prepend AS 65001 added for its own route moved the selection of a prefix that has nothing to do with AS 65001.

STEP 4: Removing the Policy Does Not Restore the Best Path

We remove the prepends from both R1 and R2, restoring route-policy PASS-ALL out. At this point the running-config of all five routers is identical to STEP 0.

The AS_PATH R3 advertises to R5 is back to 65002 65001.

R3: show bgp neighbors 10.3.5.5 advertised-routes (after removal)
Network            Next Hop        From            AS Path
168.1.0/24     10.3.5.3        10.1.3.1        65002 65001i
168.2.0/24     10.3.5.3        10.1.3.1        65002 65001i
168.3.0/24     10.3.5.3        Local           65002i
168.4.0/24     10.3.5.3        10.3.5.5        65002 65004 65003i
168.5.0/24     10.3.5.3        10.3.5.5        65002 65004i

Yet R5’s best path is still via AS 65003.

R5: show bgp 192.168.1.0/24 (after removal, not restored)
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  8            8
Last Modified: Sep  6 22:34:24.774 for 00:08:05
Paths: (2 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65002 65001, (received & used)
    10.3.5.3 from 10.3.5.3 (10.0.0.3)
      Origin IGP, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65003 65001, (received & used)
    10.4.5.4 from 10.4.5.4 (10.0.0.4)
      Origin IGP, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 8
      Origin-AS validity: (disabled)

Both AS_PATHs are back to 2 entries, 65002 65001 and 65003 65001, so they tie again. The fourth criterion cannot decide, and the comparison falls through to the ninth, “route age” (older wins). The path via AS 65003 has been held as the best path ever since STEP 3, while the path via AS 65002 was re-installed in STEP 4, so the older AS 65003 path keeps winning.

The evidence is that Last Modified is still 22:34:24 — the STEP 3 timestamp.

In other words, restoring the configuration does not restore the best path. BGP is designed to prefer the status quo on a tie, to avoid route flapping.

STEP 5: Resetting the Sessions to Return to the Initial State

First we try a soft reset. We ran clear bgp ipv4 unicast 10.4.5.4 soft in on R5, but the show bgp 192.168.1.0/24 immediately afterwards still showed Last Modified of Sep 6 22:34:24.774 and Speaker version 8 — nothing moved from the STEP 4 state shown above. soft in only re-applies the inbound policy; it does not reset the route “age” used for tie-breaking.

So we tear the session down and bring it back up. Because some forms of clear bgp on IOS XR prompt for confirmation, we used shutdown followed by no shutdown on the neighbor.

Commands entered on R5 (committed in two steps)
router bgp 65004
 neighbor 10.4.5.4
  shutdown

router bgp 65004
 neighbor 10.4.5.4
  no shutdown

The syslog records the session going down and coming back up (the lines in between are the commit logs for no shutdown).

R5: show logging (STEP 5 range)
RP/0/RP0/CPU0:Sep  6 23:09:19.795 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.4.5.4 Down - Admin. shutdown (CEASE notification sent - administrative shutdown) (VRF: default) (AS: 65003) 
<snip>
RP/0/RP0/CPU0:Sep  6 23:09:58.957 UTC: bgp[1084]: %ROUTING-BGP-5-ADJCHANGE : neighbor 10.4.5.4 Up (VRF: default) (AS: 65003) 

After re-establishment the path via AS 65003 became the “newer” one, and the path via AS 65002 returned as the best path.

R5: show bgp 192.168.1.0/24 (after the session reset)
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 11           11
Last Modified: Sep  6 23:09:19.774 for 00:04:21
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65002 65001, (received & used)
    10.3.5.3 from 10.3.5.3 (10.0.0.3)
      Origin IGP, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 11
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  65003 65001, (received & used)
    10.4.5.4 from 10.4.5.4 (10.0.0.4)
      Origin IGP, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

The traceroute is back to the same path as STEP 0.

R5: traceroute (after the session reset)
Type escape sequence to abort.
Tracing the route to 192.168.1.1

 1  10.3.5.3 6 msec  4 msec  5 msec 
 2  10.1.3.1 8 msec  *  9 msec

The order in which you reset changes the outcome. Since the ninth criterion is “older wins”, the session you reset last carries the newest routes and loses the tie-break. Here we reset R3 - R5 first and R4 - R5 second, so the path via AS 65002 won. Reversing the order reverses the result. If you need tied routes to land on a particular side, do not rely on reset order — make the difference explicit with LOCAL_PREF or WEIGHT.

Because of this order dependency, 192.168.2.0/24, which R2 advertises, settled on the opposite choice from STEP 0 (via AS 65002). In STEP 0 the path via AS 65003 happened to arrive first; the configuration is identical.

Verification Configs and show Output

For every STEP, the following three files were captured per router from all five routers. The verification config is these ..._run.txt files (the final state is the one from the last STEP).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show route bgp` / `show bgp` / `show bgp summary` / `show bgp <prefix>` (5 prefixes) / `show bgp neighbor` / `show bgp neighbors <peer> advertised-routes` / `show bgp neighbors <peer> routes` / `show bgp neighbors <peer> received routes` / `show bgp update-group` / `show rpl route-policy` / `show ospf neighbor` (R1 and R2 only) / `traceroute` (R3, R4 and R5 only)
`..._log.txt`	`show logging` narrowed to that STEP’s range. A marker was inserted with `logmsg` at the start of each STEP and its timestamp passed to `show logging start`
`..._run.txt`	`show running-config` at that STEP (i.e. that STEP’s verification config)

In the final state (STEP 5) the only policy is PASS-ALL, and the running-config matches STEP 0 on all five routers.

STEP 0: Initial state

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 1: MED 200 on R1→R3 and MED 50 on R2→R3 applied

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 2: MED removed, prepend ×1 applied on R1→R3

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 3: Prepend ×1 also applied on R2→R3

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 4: Prepends removed (configuration identical to STEP 0)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

STEP 5: BGP sessions reset (final state)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run

The full captures are below. They contain every UPDATE caused by the policy changes from STEP 0 through STEP 4 (the STEP 5 session reset is outside the capture window).

Download the full capture of the R1 - R3 link

Download the full capture of the R3 - R5 link

Download the pcap of the UPDATE R3 re-sent after the prepends were removed (No.183)

References

Document	Title	Overview
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	Section 4.3 defines the `AS_PATH` segment types, 5.1.2 the update rules for eBGP/iBGP, and 9.1.2.2 the comparison order for best path selection.
RFC 6793	BGP Support for Four-Octet Autonomous System (AS) Number Space	The extension to four-octet AS numbers, including how `AS4_PATH` works across non-capable routers.
RFC 7454	BGP Operations and Security	Section 6.1 recommends operational practices such as limiting `AS_PATH` length.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of numbers used by BGP, including path attribute type codes and AS_PATH segment types.