BGP AS_PATH Attribute

What AS_PATH Is

AS_PATH (Type code 2) is the well-known mandatory path attribute that records which ASes a route has traversed as a list of AS numbers (BGP Path Attributes and Best Path Selection). It is why BGP is called a path vector protocol, and it plays two roles.

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)

Adding it inside the AS would break its meaning as a per-AS distance (RFC 4271 section 5.1.2). A route you originate with network travels through your own AS with an empty AS_PATH.

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, 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.

AS_PATH expanded by tshark -V (UPDATE from R3 to R5)
        Path Attribute - AS_PATH: 65002 65001 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
<snip>
            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. Aggregation itself is covered in BGP Route Aggregation (aggregate-address).

Loop Detection

A received route whose AS_PATH contains the local AS is discarded (RFC 4271 section 9.1.2). The route itself carries enough information to detect the loop, without a hop-count limit. Where the discard happens and what allowas-in does are covered in BGP (Border Gateway Protocol).

Position in Best Path Selection

AS_PATH length is compared fourth in best path selection, before MULTI_EXIT_DISC (sixth): if the lengths differ, MED is never examined. Only the length is compared, and bgp bestpath as-path ignore does not disable loop detection.

Inbound Traffic Engineering with AS_PATH Prepending

AS_PATH prepending adds extra copies of your own AS number in an eBGP outbound policy to steer inbound traffic: the route looks longer, so that link is less likely to be chosen. On IOS XR it is prepend as-path own-as <count>.

Adding one extra copy of the local AS number (IOS XR, from show running-config)
route-policy TO-R3
  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 FROM-R3 in
   route-policy TO-R3 out
   soft-reconfiguration inbound always
  !

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

If the upstream AS decides its exit with LOCAL_PREF, prepending does not reach it. LOCAL_PREF is the second step of best path selection, evaluated before AS_PATH at the fourth.

Difference from MED

MED produces the same result for choosing an entry point in the adjacent AS. The 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 not propagated beyond the AS that receives it (RFC 4271 section 5.1.4), whereas prepending rewrites AS_PATH itself, which propagates, so it takes effect in ASes beyond the one intended. STEP 1 (MED) and STEP 3 (prepending) below show this difference in reach.

Hands-on Verification

Five XRd 26.1.1 routers confirm the following.

When paths of equal length are compared, the path received first is kept
MED changes the entry point in the adjacent AS without affecting the ASes beyond
Prepending changes the adjacent AS’s entry point the same way
Lengthening both exits changes the selection of the AS two hops away
Removing the policy does not restore the best path; 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

R1 advertises 192.168.1.0/24, and we follow how it looks from the other ASes
AS 65002 (R3) connects to AS 65001 over two links (via R1 and via R2), so MED comparison applies
AS 65004 (R5) is not directly connected to AS 65001 and has two choices, via AS 65002 and via AS 65003, both of AS_PATH length 2
The R5 - R4 session is shut down in the initial state. This makes R5 receive the path via AS 65002 first and the one via AS 65003 later, because the choice between paths of equal length depends on which was received first

Overview of the Verification

STEP	Operation	What it shows
0	Initial state (R5 - R4 is shut down)	R5 has only one path to `192.168.1.0/24`, via AS 65002
1	Bring up the R5 - R4 session	Two paths exist, but the best path stays via AS 65002 (with equal lengths, the path received first is kept)
2	MED 200 on R1->R3, MED 50 on R2->R3	MED changes only R3’s entry point; R5’s table does not change at all
3	Remove MED and apply prepend x1 on R1->R3	The same change of entry point happens through `AS_PATH` length
4	Also apply prepend x1 on R2->R3	The selection of AS 65004, two hops away, changes (which MED could not do)
5	Remove the prepends (configuration returns to that of STEP 1)	The best path is not restored automatically
6	Run `soft-reconfiguration inbound` on R5	Soft reconfiguration does not restore it either
7	Shut down the R5 - R4 session	The alternative disappears, so the path via AS 65002 is chosen again
8	Bring the R5 - R4 session back up (final state)	With equal lengths, the best path stays via AS 65002

Captures were taken on four links in every STEP: R1 - R3, R2 - R3, R3 - R5 and R4 - R5 (in STEP 0 the R4 - R5 session is down, so no BGP flows on that link).

STEP 0: Initial State (R5 - R4 Is Shut Down)

R5 starts with its eBGP session to 10.4.5.4 (R4) shut down. R5 has only one path to 192.168.1.0/24, via AS 65002.

R5: 192.168.1.0/24 (only one path, via AS 65002)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  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

R3 holds two paths to the same prefix, one via R1 and one via R2. This is the side where MED comparison applies.

R3: 192.168.1.0/24 (two paths, via R1 and via R2)
RP/0/RP0/CPU0:R3#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  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
<snip>
  Path #2: Received by speaker 0
<snip>
  65001, (received & used)
    10.2.3.2 from 10.2.3.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external

STEP 1: Receiving the Path via AS 65003 Later

Bring up R5’s session to 10.4.5.4. Both 65002 65001 and 65003 65001 have an AS_PATH length of 2.

Configuration committed on R5 in STEP 1
RP/0/RP0/CPU0:R5#show configuration commit changes last 1
Mon Sep 28 14:12:45.843 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65004
 neighbor 10.4.5.4
  no shutdown
 !
!
end

When lengths are equal, the path received first is kept. R5 has held the path via AS 65002 since STEP 0, so it does not switch to the one via AS 65003 that arrives later.

R5: 192.168.1.0/24 (two paths, best still via AS 65002)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  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
<snip>
  Path #2: Received by speaker 0
<snip>
  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

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

Attach MED 200 to the routes R1 advertises to R3, and MED 50 to those from R2.

Configuration committed on R1 in STEP 2
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Mon Sep 28 14:19:19.377 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R3
  set med 200
  pass
end-policy
!
end

Configuration committed on R2 in STEP 2
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Mon Sep 28 14:19:28.530 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R3
  set med 50
  pass
end-policy
!
end

R3’s best path moves to the one via R2, which carries the smaller MED.

R3: 192.168.1.0/24 (the path via R2 with MED 50 is best)
RP/0/RP0/CPU0:R3#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #2)
<snip>
  Path #1: Received by speaker 0
<snip>
  65001, (received & used)
    10.1.3.1 from 10.1.3.1 (10.0.0.1)
      Origin IGP, metric 200, localpref 100, valid, external
<snip>
  Path #2: Received by speaker 0
<snip>
  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

R5’s table, on the other hand, is identical to STEP 1. MED is not propagated beyond the AS that receives it, so nothing reaches the AS two hops away.

R5: 192.168.1.0/24 (same as STEP 1)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  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
<snip>
  Path #2: Received by speaker 0
<snip>
  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

STEP 3: Doing the Same with AS_PATH Prepending

Remove MED and add one extra copy of the local AS number to what R1 advertises to R3.

Configuration committed on R1 in STEP 3
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Mon Sep 28 14:25:58.761 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R3
  prepend as-path own-as 1
  pass
end-policy
!
end

Configuration committed on R2 in STEP 3
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Mon Sep 28 14:26:06.027 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R3
  pass
end-policy
!
end

Placing two UPDATEs from the same R1 - R3 link side by side shows exactly where MED and prepending write. MED only adds MULTI_EXIT_DISC and leaves AS_PATH as the single 65001; prepending stretches AS_PATH to 65001 65001.

STEP 2, No.1 (R1 to R3, MED 200), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.1.3.1
<snip>
                192.168.1.0/24
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65001 
<snip>
            AS Path segment: 65001
<snip>
        Path Attribute - MULTI_EXIT_DISC: 200
<snip>
            Multiple exit discriminator: 200

STEP 3, No.3 (R1 to R3, prepend x1), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.1.3.1
<snip>
                192.168.1.0/24
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65001 65001 
<snip>
            AS Path segment: 65001 65001
<snip>
        Path Attribute - MULTI_EXIT_DISC: 0
<snip>
            Multiple exit discriminator: 0

The prepending side also carries MULTI_EXIT_DISC: 0. That is the 0 IOS XR attaches when no MED is configured, which is a different thing from the 200 set in STEP 2.

Download the pcap of the packet in the tshark output above (No.1 UPDATE, MED 200)

Download the pcap of the packet in the tshark output above (No.3 UPDATE, prepend x1)

R3’s best path moves to the one via R2, just as it did with MED. For the purpose of choosing an entry point, either gives the same result.

R3: 192.168.1.0/24 (the path via R2, which was not prepended, is best)
RP/0/RP0/CPU0:R3#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #2)
<snip>
  Path #1: Received by speaker 0
<snip>
  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
<snip>
  Path #2: Received by speaker 0
<snip>
  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

STEP 4: Lengthening Both Exits to Move the AS Two Hops Away

Apply the same prepend to what R2 advertises to R3, making both exits of AS 65001 one AS longer.

Configuration committed on R2 in STEP 4
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Mon Sep 28 14:32:36.520 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R3
  prepend as-path own-as 1
  pass
end-policy
!
end

From R3, the paths via R1 and via R2 are now equal at 65001 65001, but what R3 advertises to R5 becomes 65002 65001 65001, a length of 3. From R5, the path via AS 65003 (length 2) is now shorter, so the best path of AS 65004, two hops away, switches. This is what MED could not do.

R5: 192.168.1.0/24 (switched to the path via AS 65003)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #2)
<snip>
  Path #1: Received by speaker 0
<snip>
  65002 65001 65001, (received & used)
    10.3.5.3 from 10.3.5.3 (10.0.0.3)
      Origin IGP, localpref 100, valid, external, group-best
<snip>
  Path #2: Received by speaker 0
<snip>
  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

STEP 4, No.1 (R3 to R5, the UPDATE whose AS_PATH grew to three), tshark -V
Border Gateway Protocol - UPDATE Message
<snip>
        Path Attribute - MP_REACH_NLRI
<snip>
            Next hop: 10.3.5.3
<snip>
                192.168.1.0/24
<snip>
                    MP Reach NLRI IPv4 prefix: 192.168.1.0
        Path Attribute - ORIGIN: IGP
<snip>
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 65001 65001 
<snip>
            AS Path segment: 65002 65001 65001

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

Forwarding follows the path that was selected.

Reachability from R5 to 192.168.1.1 (STEP 4)
RP/0/RP0/CPU0:R5#ping 192.168.1.1 source 192.168.5.1 count 50 timeout 1
<snip>
Type escape sequence to abort.
<snip>
Success rate is 100 percent (50/50), round-trip min/avg/max = 8/11/50 ms

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

Remove the prepends from R1 and R2, returning the configuration to the state of STEP 1.

Configuration committed on R1 in STEP 5
RP/0/RP0/CPU0:R1#show configuration commit changes last 1
Mon Sep 28 14:39:06.972 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R3
  pass
end-policy
!
end

Configuration committed on R2 in STEP 5
RP/0/RP0/CPU0:R2#show configuration commit changes last 1
Mon Sep 28 14:39:14.339 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
route-policy TO-R3
  pass
end-policy
!
end

The AS_PATH length returns to 65002 65001 and ties with the path via AS 65003, yet the best path stays via AS 65003. The rule that the path received first is kept now works in the opposite direction: the path via R3 was re-advertised when the prepend was added and removed, which makes the path via R4 the older one.

R5: 192.168.1.0/24 (lengths are equal again, but best is still via AS 65003)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #2)
<snip>
  Path #1: Received by speaker 0
<snip>
  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
<snip>
  Path #2: Received by speaker 0
<snip>
  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

STEP 6: Soft Reconfiguration Does Not Restore It Either

Run clear bgp ipv4 unicast 10.4.5.4 soft in on R5. This passes the stored received routes through the inbound policy again without dropping the session.

Running soft reconfiguration on R5 (STEP 6)
RP/0/RP0/CPU0:R5#clear bgp ipv4 unicast 10.4.5.4 soft in
Mon Sep 28 14:45:45.851 UTC

The best path does not move, because the difference in how recently each path was received remains.

R5: 192.168.1.0/24 (same as STEP 5)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #2)
<snip>
  Path #1: Received by speaker 0
<snip>
  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
<snip>
  Path #2: Received by speaker 0
<snip>
  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

STEP 7 and 8: Shutting the Session Down and Bringing It Back Up

Shutting down R5’s session to 10.4.5.4 removes the path via AS 65003, so the path via AS 65002 is chosen again.

Configuration committed on R5 in STEP 7
RP/0/RP0/CPU0:R5#show configuration commit changes last 1
Mon Sep 28 14:52:16.485 UTC
!! Building configuration...
!! IOS XR Configuration 26.1.1
router bgp 65004
 neighbor 10.4.5.4
  shutdown
 !
!
end

R5: 192.168.1.0/24 (only the path via AS 65002 remains)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (1 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  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

When the session comes back up, the path via AS 65003 is now the most recently received one. Even with equal lengths the best path stays via AS 65002, and this is the final state.

R5: 192.168.1.0/24 (final state)
RP/0/RP0/CPU0:R5#show bgp 192.168.1.0/24
<snip>
Paths: (2 available, best #1)
<snip>
  Path #1: Received by speaker 0
<snip>
  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
<snip>
  Path #2: Received by speaker 0
<snip>
  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

This is the operation required to reliably undo the effect of a prepend.

Verification Configs and show Output

For every STEP, the following files were collected from all five routers, split per router. The verification configs are 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` and the full BGP and OSPF state (including `advertised-routes`, `routes` and `received routes` per neighbor)
`..._log.txt`	`show logging` limited to that STEP. A marker is written with `logmsg` at the start of each STEP and its timestamp is passed to `show logging start`
`..._run.txt`	`show running-config` at that STEP (that is, the verification config for the STEP)
`..._ping.txt`	`ping` and `traceroute` results for that STEP
`..._trace.txt`	`show bgp trace neighbor` / `show bgp trace error`
`..._commit.cfg`	Only the configuration actually committed in that STEP (routers whose configuration changed)
`..._exec.txt`	Operations that are not configuration changes, such as `clear bgp ... soft in` (STEP 6 only)

STEP 0: Initial state (R5 - R4 is shut down)

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

STEP 1: Bring up the R5 - R4 session

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

STEP 2: MED 200 on R1->R3, MED 50 on R2->R3

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

STEP 3: Remove MED and apply prepend x1 on R1->R3

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

STEP 4: Also apply prepend x1 on R2->R3 (lengthen both exits)

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

STEP 5: Remove the prepends (configuration returns to that of STEP 1)

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

STEP 6: Run soft-reconfiguration inbound on R5

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

STEP 7: Shut down the R5 - R4 session

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

STEP 8: Bring the R5 - R4 session back up (final state)

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

Packet captures were taken per STEP on four links.

STEP	R1 - R3	R2 - R3	R3 - R5	R4 - R5
0	pcap	pcap	pcap	pcap
1	pcap	pcap	pcap	pcap
2	pcap	pcap	pcap	pcap
3	pcap	pcap	pcap	pcap
4	pcap	pcap	pcap	pcap
5	pcap	pcap	pcap	pcap
6	pcap	pcap	pcap	pcap
7	pcap	pcap	pcap	pcap
8	pcap	pcap	pcap	pcap

References

RFC 4271 - A Border Gateway Protocol 4 (BGP-4) section 4.3 (AS_PATH), 5.1.2 (how it grows on eBGP and iBGP), 5.1.4 (MED is not propagated), 9.1.2 (loop detection), 9.1.2.2 (best path selection and how AS_SET is counted)