Day 16 — BGP AS_PATH: Loop Prevention, Path Length and Controlled Prepending

Learning objective

Read and interpret AS_PATH, explain its role in autonomous-system loop prevention and best-path selection, apply controlled prepending, and diagnose a policy that makes a normally preferred path unnecessarily long.


BGP AS_PATH: Loop Prevention, Path Length and Controlled Prepending
BGP AS_PATH: Loop Prevention, Path Length and Controlled Prepending



1. Opening — BGP remembers the autonomous systems a route crossed

Unlike an IGP metric, AS_PATH is not a measurement of latency, bandwidth or geographic distance. It is a record of autonomous-system path information carried with the route.

Each eBGP hop normally adds its AS number as the route crosses an AS boundary. When a BGP speaker sees its own AS in the received path, the ordinary loop-prevention behavior is to reject the route rather than accept a path that has already traversed the local AS.

Cisco's best-path algorithm also uses AS_PATH length: after earlier attributes such as Weight, LOCAL_PREF and local origination, a shorter AS path is normally preferred.

These two roles—loop prevention and path selection—must not be confused.


2. AS_PATH is not a latency metric

Suppose two candidate routes are:

Path A: 65010 65100
Path B: 65020 65030 65100

BGP sees Path A as shorter in AS sequence length. That does not prove Path A has lower latency or more available bandwidth. It simply crosses fewer AS_SEQUENCE entries for the comparison.

Policy may intentionally prefer the longer AS path through higher LOCAL_PREF, and that would be completely valid because LOCAL_PREF is evaluated earlier in Cisco's sequence.

Never explain BGP as “always choosing the shortest AS path.”


3. Loop prevention

RFC 4271's AS_PATH processing provides inter-AS loop detection. When a BGP speaker receives an UPDATE containing its own AS in the AS_PATH, normal processing prevents that route from being accepted as a loop-free external path.

There are specialized mechanisms such as allowas-in and migration-related local-AS features that alter default behavior in controlled designs. Those belong in later migration and advanced-policy posts.

For normal eBGP:

> Seeing your own AS in the path is a strong loop signal.


4. AS_SEQUENCE and modern AS_SET warning

The common path you read in operational tables is an ordered AS_SEQUENCE.

Older BGP aggregation designs could create AS_SET path segments. However, RFC 9774, published in May 2025, prohibits originating new AS_SET and AS_CONFED_SET segments. Day 11 already incorporated that current standards change.

Therefore this series will not recommend AS_SET-based aggregation as modern design practice.


5. Prepending

AS-path prepending intentionally adds repeated AS numbers so a path appears longer to remote BGP decision processes.

Example:

Normal:    65010 65100
Prepended: 65010 65010 65010 65100

Prepending is commonly used to influence inbound traffic by making one advertisement less attractive to external networks.

But it is a weak signal compared with higher-priority policy in the remote AS. A provider can use LOCAL_PREF to prefer the prepended route anyway.

Prepending therefore influences; it does not command.


6. Scenario — Summit Path-Length Shift

Illustrative lab — not a real incident.

Topology

                 Service S
                 AS65100
                 /      \
                /        \
          P1 AS65010    P2 AS65020
              |             |
              | eBGP        | eBGP
              +------ E -----+
                   AS65050

Service router S originates 192.0.2.128/25 and advertises it to both providers.

Enterprise E receives:

  • via P1: 65010 65100
  • via P2: 65020 65100

The paths have equal AS-path length before modification.

Controlled change

P1 prepends its own AS twice on the advertisement toward E.

Expected P1 path becomes conceptually:

65010 65010 65010 65100

P2 remains shorter and can become preferred if earlier attributes tie.


7. Prerequisites

  • Four routers.
  • eBGP S–P1, S–P2, P1–E and P2–E.
  • Documentation-safe point-to-point addressing.
  • All next hops reachable.
  • Equal Weight and LOCAL_PREF at E.

The topology is deliberately small; it models path policy rather than a real Internet transit business relationship.


8. Topic-specific configuration excerpt

Service S — AS65100

ip route 192.0.2.128 255.255.255.128 Null0
!
router bgp 65100
 bgp router-id 10.51.0.1
 neighbor 192.0.2.1 remote-as 65010
 neighbor 198.51.100.1 remote-as 65020
 address-family ipv4 unicast
  network 192.0.2.128 mask 255.255.255.128
  neighbor 192.0.2.1 activate
  neighbor 198.51.100.1 activate
 exit-address-family

P1 — AS65010

route-map PREPEND-TO-E permit 10
 set as-path prepend 65010 65010
!
router bgp 65010
 neighbor 192.0.2.2 remote-as 65100
 neighbor 203.0.113.2 remote-as 65050
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
  neighbor 203.0.113.2 activate
 exit-address-family

Do not apply PREPEND-TO-E yet in the baseline.

P2 — AS65020

router bgp 65020
 neighbor 198.51.100.2 remote-as 65100
 neighbor 203.0.113.6 remote-as 65050
 address-family ipv4 unicast
  neighbor 198.51.100.2 activate
  neighbor 203.0.113.6 activate
 exit-address-family

E — AS65050

router bgp 65050
 neighbor 203.0.113.1 remote-as 65010
 neighbor 203.0.113.5 remote-as 65020
 address-family ipv4 unicast
  neighbor 203.0.113.1 activate
  neighbor 203.0.113.5 activate
 exit-address-family

The lab package provides the full interface plan.


9. Verification before modification

At E:

show ip bgp 192.0.2.128
show ip bgp regexp _65100$
show ip route 192.0.2.128 255.255.255.128

At P1:

show ip bgp 192.0.2.128
show ip bgp neighbors 203.0.113.2 advertised-routes

Capture the original AS_PATH through each provider.

Because the two path lengths are equal, do not claim which path wins the remaining tie-breakers before observing the actual lab.


10. Controlled modification — prepend P1 toward E

On P1:

configure terminal
router bgp 65010
 address-family ipv4 unicast
  neighbor 203.0.113.2 route-map PREPEND-TO-E out
end

Use a safe outbound refresh so the changed advertisement is sent.

Expected result

At E, the route through P1 should show additional 65010 entries. If all earlier selection attributes tie, the route through P2 now has the shorter AS_PATH and should be preferred.


11. Fault injection

Illustrative lab — not a real incident.

Lab name

Summit Excessive Prepend

Fault

An operator intends to add two prepends but adds six repeated AS numbers instead.

route-map PREPEND-TO-E permit 10
 set as-path prepend 65010 65010 65010 65010 65010 65010

Expected impact

The P1 advertisement becomes much less attractive to networks that consider AS_PATH length at the relevant stage.

Important caveat

The change may have no effect in a remote AS that deliberately gives the P1 route higher LOCAL_PREF. That is not a BGP failure; it is remote policy winning earlier.


12. Troubleshooting sequence

  1. Confirm the exact prefix and both candidate paths.
  2. Verify next-hop reachability.
  3. Check Weight and LOCAL_PREF before blaming AS_PATH.
  4. Read the AS_PATH on the receiving router.
  5. Identify whether repeated ASNs are natural transit hops or intentional prepends.
  6. Inspect outbound route maps on the advertising edge.
  7. Confirm the route-map scope: neighbor, direction and address family.
  8. Compare intended versus actual number of prepends.
  9. Remove or reduce the smallest incorrect policy.
  10. Refresh safely and verify the path returns to the intended ranking.

13. Root cause and correction

Root cause

An outbound route map on P1 made its path substantially longer than intended.

Correction

Reduce the prepend count or remove the route map if no de-preference is required.

route-map PREPEND-TO-E permit 10
 set as-path prepend 65010 65010

Why it works

The receiving BGP speaker sees a shorter path through P1 than it saw during the fault, allowing the normal decision hierarchy to evaluate the revised path.


14. Post-fix verification

At E:

show ip bgp 192.0.2.128
show ip route 192.0.2.128 255.255.255.128

At P1:

show route-map PREPEND-TO-E
show ip bgp neighbors 203.0.113.2 advertised-routes

If the purpose is real inbound traffic engineering, supplement route-table verification with flow/telemetry evidence. A BGP best path does not alone prove how all remote networks will send traffic.


15. Rollback

router bgp 65010
 address-family ipv4 unicast
  no neighbor 203.0.113.2 route-map PREPEND-TO-E out

Preserve the route-map and before/after path evidence before rollback if an incident investigation is active.


16. Production lessons

Protocol lesson

AS_PATH provides autonomous-system path information and loop prevention; it is not a performance metric.

Policy lesson

Shortest AS_PATH matters only after earlier path-selection criteria tie.

Traffic-engineering lesson

Prepending is an influence mechanism for remote selection, not a guarantee.

Security lesson

Unexpected AS_PATH changes can indicate leaks, hijacks, misconfiguration or migration behavior. Compare against expected routing relationships.

Standards lesson

Do not design new aggregation around AS_SET/AS_CONFED_SET; RFC 9774 now prohibits their origination.


16A. Prepending strategy and its limits

A prepend count should be chosen from evidence, not folklore. “Prepend three times” is not a protocol rule. The useful count depends on competing paths and the remote networks whose decisions matter.

A disciplined process is:

  1. Measure the normal AS_PATHs seen from representative external vantage points.
  2. Identify which remote ASes actually send the traffic of interest.
  3. Check whether your provider offers BGP communities that change LOCAL_PREF inside the provider; those can be more predictable than blind prepending.
  4. Apply the minimum prepend needed to create the intended relative difference.
  5. Observe route collectors, provider looking glasses or telemetry where authorized.
  6. Roll back if the change shifts traffic farther than intended.

The same prepend can produce different results in different remote ASes because each AS owns its own policy.

Do not prepend somebody else's ASN casually

Operational policy normally prepends the local ASN to make the local advertisement less attractive. Adding arbitrary third-party ASNs can create misleading path information and trigger loop prevention or filtering. Specialized migration features can alter AS-path construction, but those require their own design treatment.

More prepends can reduce resilience

If an alternate path is made excessively unattractive, some remote networks may keep using another path even after conditions change, depending on their available routes and policy. Prepending should therefore be tested not only in the healthy state but also during primary-path failure and restoration.


17. Knowledge check

Q1

Why might a longer AS_PATH still be selected?

Answer: A higher-priority criterion such as Weight or LOCAL_PREF can prefer it before AS_PATH length is evaluated.

Q2

What is the basic loop-prevention signal in ordinary eBGP AS_PATH processing?

Answer: The receiving BGP speaker sees its own AS number already present in the AS_PATH and rejects the looping route under normal behavior.

Q3

Does prepending force every remote AS to avoid the prepended path?

Answer: No. Remote policy such as LOCAL_PREF can override the AS_PATH-length preference.


18. Sources

  1. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — AS_PATH attribute, loop prevention and Decision Process.
  2. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — shortest AS path in Cisco best-path selection.
  3. Cisco — *Connecting to a Service Provider Using External BGP, IOS XE 17.x* — AS-path policy examples.
  4. RFC 9774 — *Deprecation of AS_SET and AS_CONFED_SET in BGP* — current prohibition on originating those path segment types.

Accessed: 2026-08-11.


Featured Post

Day 41 — BGP Confederations: Sub-AS Design, External View and Migration

1. Opening Confederations are another way to scale BGP inside a large administrative domain. They divide the domain into member autonomous systems while presenting a single confederation identifier to external peers. They are powerful, but their operational model is more complex than simply 'using private ASNs inside.' The engineering goal is not to memorize another BGP command. It is to understand what information each speaker is allowed to propagate, what path information can be hidden, and what failure domain is created by the chosen control-plane architecture . 2. Concept and standards behavior RFC 5065 defines AS_CONFED_SEQUENCE and AS_CONFED_SET and how member-AS relationships are represented. Confederation external sessions have eBGP-like properties inside the confederation, while the confederation is presented externally as one AS. Modern guidance must also account for the fact that RFC 9774 prohibits new origination of AS_SET/AS_CONFED_SET in ordinary aggregation c...