Path-vector routing and AS_PATH

BGP is called a path-vector protocol because it carries not only a destination and next hop, but also a record of the autonomous systems that have advertised the path. That record is AS_PATH. It gives BGP enough information to reject a loop and enough context to compare routes that arrive from different neighbors.

Path-vector is not a promise that a route is short, fast, or safe. It is a policy history. AS_PATH length is a late tie-breaker after LOCAL_PREF, origin, and other policy signals. An operator who makes AS_PATH the first policy knob is usually optimizing the display rather than the business intent.

AS_PATH is a policy history

Consider a route originated in AS 65010, advertised through AS 65020, and received by AS 65030. The receiving router sees an AS_SEQUENCE such as 65010 65020. If the route is advertised to an eBGP neighbor in AS 65030, the local AS is added at the left or right according to the implementation display and forwarding direction. The important fact is that the policy chain is extended.

flowchart LR
  O["Originator<br/>AS 65010"] -->|"advertise"| T["Transit<br/>AS 65020"]
  T -->|"advertise"| R["Receiver<br/>AS 65030"]
  R -->|"contains own ASN"| X["Reject path<br/>loop detected"]
  R -->|"AS_PATH 65010 65020"| P["Compare with another path"]
  P --> Q["Shortest AS_PATH<br/>when earlier criteria tie"]

The AS_PATH attribute is transitive in the sense that it travels with an eBGP advertisement. It is not an encrypted or signed record. A neighbor that is not trusted should not be allowed to inject arbitrary path information, and every boundary should apply an explicit inbound and outbound policy.

AS_SEQUENCE, AS_SET, and prepending

An AS_SEQUENCE is an ordered list of ASNs. A route learned from different paths can be summarized with an AS_SET, which records that the aggregate was learned from more than one AS. An AS_SET is unordered and is treated differently in best-path logic and in security policy.

Prepending adds an ASN more than once to a path:

AS_PATH before prepending: 65001 65002
AS_PATH after three prepends: 65001 65002 65002 65002

Prepending is a traffic-engineering signal. It can make a path look less preferred when earlier best-path criteria are equal. It does not force an upstream provider to honor the preference, and it does not hide a misconfiguration.

How an UPDATE is processed

A useful operational model is a pipeline:

1. The neighbor sends an UPDATE over an Established TCP session.
2. bgpd parses the NLRI and path attributes, including AS_PATH, NEXT_HOP, ORIGIN, MED, LOCAL_PREF, and communities.
3. The inbound prefix-list and route-map policy evaluates the route.
4. The route enters the relevant Adj-RIBs-In and becomes a candidate for best-path selection.
5. The best path is installed in the Loc-RIB and, if the next hop and policy permit, sent to zebra for the kernel FIB.
6. The outbound policy shapes the Adj-RIBs-Out used for the neighbor.
7. FRR encodes the selected attributes and sends an UPDATE.

flowchart LR
  P["Peer UPDATE"] --> V["Parse and validate"]
  V --> I["Inbound policy"]
  I --> A["Adj-RIBs-In"]
  A --> S["Best-path selection"]
  S --> L["Loc-RIB"]
  L --> F["Linux FIB"]
  L --> O["Outbound policy"]
  O --> B["Adj-RIBs-Out"]
  B --> E["Encode UPDATE"]

The order matters in an incident. A route in Adj-RIBs-In but absent from the Loc-RIB was rejected or lost best-path comparison. A route in the Loc-RIB but absent from the FIB may have an unusable next hop. A route present in the FIB but not in Adj-RIBs-Out may be filtered from a particular peer.

VyOS configuration examples

Originate a network statement and apply an outbound AS-prepend policy:

configure
set protocols bgp system-as 65000
set protocols bgp address-family ipv4-unicast network 198.51.100.0/24
set protocols bgp neighbor 192.0.2.2 route-map PREPEND-TRANSIT out
commit
save

A route-map used for prepending must be defined in the route-policy part of the VyOS tree. The exact route-map sequence depends on whether the prefix is originated, aggregated, or redistributed. The principle is stable: the BGP neighbor command selects the direction; the route-map controls permitted and modified attributes.

Inspect the actual path before changing it:

show bgp ipv4 unicast 198.51.100.0/24
show bgp neighbor 192.0.2.2
show ip route 198.51.100.0/24

The first command shows the candidates and their AS_PATH values. The second shows whether the neighbor accepted or advertised the expected attributes. The third shows what the data plane can actually reach.

Validation and failure modes

Check both path semantics and packet reachability:

• show bgp summary proves the session and negotiated AS values.
• show bgp ipv4 unicast proves which paths bgpd considers valid.
• show bgp neighbor shows route refresh, policy, and received-prefix behavior.
• show ip route proves the selected path reached the FIB.
• tcpdump -ni any host 192.0.2.2 and tcp port 179 proves the transport path when the session is not behaving as expected.

Common failures include:

• a route is rejected because an inbound AS_PATH filter contains a stale ASN;
• an AS_SET or malformed path is rejected or hidden from an aggregation policy;
• prepending changes a route on one peer but is removed by an outbound route map on another;
• the AS_PATH is short, but the NEXT_HOP is unreachable;
• the session is Established while the wrong route is sent because the neighbor is in a different VRF or address family.

Rollback

For a bad outbound policy, delete the route-map reference or restore the previous map:

configure
delete protocols bgp neighbor 192.0.2.2 route-map PREPEND-TRANSIT
commit
save

For a bad aggregate or network statement, remove the originating configuration first, then verify that the peer withdraws the route. If the change is committed and spans several commits, use the last known good rollback N before altering the saved configuration.

A path-vector change record

A useful change record is a compact table the operator can read during an incident:

Capture the values before adding a prepend or changing an aggregate. A route can look correct in one peer view and wrong in another; the record prevents the operator from solving a different problem than the one that was changed.

A change is also not complete when the router accepts the command. Verify that the peer summary still shows the expected prefix count, that the selected path changed only where intended, and that the return path is still reachable. If the alternate path is selected, test traffic in both directions rather than relying on a green state.

Cross-course references

XXVI-VyOS-BGPAttributes develops ORIGIN, NEXT_HOP, MED, and LOCAL_PREF in detail. XXVII-VyOS-BGPBestPath turns the candidate list into a deterministic decision. XXVIII-VyOS-BGPPrefixFilters covers the policy boundary around AS_PATH, while XXXI-VyOS-BGPTroubleshoot shows how to prove whether a route is received, selected, installed, or advertised. The OPNsense and Linux routing courses provide useful comparisons for the same FRR path-vector model.

Quiz