Autonomous system numbers

An autonomous system is a collection of networks under one routing policy. Its autonomous system number, or ASN, is the identifier BGP uses to tell one policy boundary from another. A wrong ASN is not a cosmetic mistake: it changes whether a session is eBGP, changes the AS_PATH seen by every peer, and can make a valid route look like a loop.

This lesson establishes the numbering model before the course moves to eBGP, iBGP, path attributes, and session debugging. The practical question is not merely “which number is valid?” It is “what does this number mean to FRR, the peer, the route policy, and the operator responsible for the change?”

The number has two jobs

BGP uses an ASN for two related purposes:

1. It selects the BGP relationship at session establishment. A peer with a different ASN is an eBGP neighbor; a peer with the same ASN is an iBGP neighbor.
2. It supplies the identifier that is added to AS_PATH when a route crosses an autonomous-system boundary.

The second job makes an ASN a routing policy signal, not just an administrative label. Prefixes and communities may change at a session, but AS_PATH preserves the chain of policy domains that handled the route. A route that returns to an AS whose ASN is already in its AS_PATH is rejected as a loop.

flowchart LR
  A["AS 65001<br/>customer network"] --> B["eBGP session<br/>different ASNs"]
  B --> C["AS 65002<br/>provider network"]
  C --> D["BGP UPDATE<br/>AS_PATH 65001 65002"]
  D --> E["Reject if local ASN<br/>reappears in AS_PATH"]

An engineer who changes an ASN must therefore review all four planes:

• the configured local ASN and the peer remote AS values;
• the rendered FRR configuration and the OPEN messages;
• inbound and outbound route policy, including AS_PATH filters;
• monitoring, prefix-list numbers, communities, and incident history.

The 2-byte pool

The original BGP-4 field held 16 bits, allowing 65,536 values. The operational ranges are:

A private ASN is not “less secure” and it is not automatically stripped. It is simply not valid for unrestricted use on the public Internet. A private ASN can be used between two sites of the same organization, between a customer and a provider under a documented private peering agreement, or inside a lab. It must not be advertised to a public exchange without the provider explicitly handling it.

The most common production error is assuming that a private ASN is magically removed. A route can still leave the private domain with the private value attached unless the provider applies remove-private-as or an equivalent policy. Inspect the received path on the other side; do not infer it from the local configuration.

The 4-byte pool

The four-octet field expands the value range to 32 bits. VyOS 1.5 LTS and the FRR implementation accept values from 1 through 4,294,967,294. Zero and 4,294,967,295 are reserved. The full numeric range is:

A four-byte ASN is carried in the extended ASN field when the session negotiates four-byte capability. The value is not automatically converted to a two-byte number merely because the remote device was built many years ago. The two endpoints must negotiate the capability and the operator must validate the displayed representation on both sides.

asplain, asdot, and asdot+

There are two common human-readable representations for 4-byte ASNs:

• asplain displays the full value as a decimal integer, such as 4,200,000,001.
• asdot displays a value above 65,535 as two 16-bit components separated by a dot, such as 256.1.
• asdot+ displays every ASN in dotted notation, including values that could fit in the original 2-byte field.

The wire format and the local display are different questions. An operator can type or read 256.1 while FRR stores the corresponding 32-bit value internally. The same route may be printed differently by two management systems. Before changing a filter or regex, record the representation used by each peer and monitoring exporter.

flowchart TB
  N["ASN 4200000001"] --> P["asplain<br/>4200000001"]
  N --> D["asdot<br/>256.1"]
  N --> C["Wire field<br/>4-byte ASN"]
  D --> C
  P --> C

Use one canonical representation in the runbook. If an automation template accepts decimal input, do not mix dotted and plain values in the same field without a normalization function. A regex that matches 65000 will not reliably match the dotted form of a larger ASN.

The VyOS 1.5 LTS configuration

The current VyOS 1.5 LTS tree sets the local process with system-as:

configure
set protocols bgp system-as 65000
set protocols bgp parameters router-id 192.0.2.1
commit
save

Some older course material and generated examples show the equivalent ASN-node shorthand:

set protocols bgp 65000

That shorthand is useful when comparing FRR concepts across releases, but the live VyOS 1.5 LTS configuration tree is authoritative. After commit, inspect the active and rendered forms:

show configuration
show configuration commands
run show bgp summary

The summary identifies the local AS used by bgpd. If the local number is correct in the candidate but wrong in the summary, the operator is looking at a generated-configuration or commit-order problem, not an ASN-range problem.

A staged ASN transition

An ASN migration is a routing change, not a single set command. The safe sequence is:

1. Inventory every local ASN, remote AS, peer group, route map, prefix list, community, and automation variable that encodes an ASN.
2. Check the current session state, prefix counts, best paths, and outstanding dampening or prefix-limit state.
3. Confirm whether the new ASN is public or private and whether a provider or registry contract is required.
4. Configure a canary or one side of a dual-homed site with the new value while the old session remains in place.
5. Observe both OPEN messages, AS_PATH display, inbound filters, outbound advertisements, and return traffic.
6. Move prefixes and policy only after both sides accept the new relationship.
7. Remove the old ASN configuration during a controlled window and recheck the RIB, FIB, telemetry, and backups.

Do not use a global search-and-replace that changes both sides at once. Do not assume that a private ASN can be converted to a public ASN by changing one digit. Do not let an old route-map name or automation variable preserve a stale policy after the live protocol has moved.

What fails in production

The important failure signatures are:

• The session is treated as iBGP when the operator expected eBGP. This commonly happens when two sites accidentally use the same ASN. The local remote-as value and the remote OPEN ASN disagree.
• The new ASN is valid but a provider filters it. A registry or transit contract may not be in place, or the route may still carry a private ASN upstream.
• AS_PATH filters reject the migrated path. A literal ^65000$ or a 65000 65001 assumption can turn a harmless migration into a total outbound-policy failure.
• Monitoring displays two formats. Grafana, SNMP exporters, and peer dashboards can label the same ASN differently during a transition.
• The router-id changes with the ASN. Router IDs and ASNs are separate identifiers. An ASN migration should not silently move the router-id unless the design explicitly requires a new identity.

Rollback

Before the change, save a named configuration and record the current summary:

save /config/backup/before-asn-change.boot
show configuration commands | match protocols
run show bgp summary

For an unsuccessful commit, discard returns to the candidate configuration that existed before the migration. For a committed change, use the last known-good revision:

configure
rollback N
commit
save

If only one peer is affected, remove the new remote-AS and restore the old peer value first. Do not roll back a whole estate when a single route policy is wrong; narrow the blast radius while keeping the old sessions alive.

Cross-course references

The BGP attribute lessons in XXVI-VyOS-BGPAttributes explain how AS_PATH is evaluated. The session lessons in XXIV-VyOS-BGPSession show how the local ASN affects eBGP and iBGP classification. The troubleshooting lessons in XXXI-VyOS-BGPTroubleshoot cover the operational evidence to capture during a migration. The Linux V-Linux-NetConfig material is useful for understanding the address and route table underneath the BGP control plane.

Quiz