Day 2 — Autonomous System Numbers: 2-Byte, 4-Byte, Private Space and Operational Ownership

at

Learning objective

Distinguish public and private ASNs, understand 2-byte and 4-byte ASN operation and notation, and configure a safe lab using private ASNs without creating assumptions that would be unsafe on the public Internet.





1. Opening — an ASN is an administrative identity, not just a number in a command

The command router bgp 64512 looks simple. The operational meaning is not.

An Autonomous System Number identifies an autonomous system in interdomain routing. In production Internet routing, globally unique ASNs provide a way to describe routing-domain identity and construct the AS path used for policy and loop prevention. In private labs and some closed environments, private-use ASNs let engineers build BGP systems without consuming globally assigned numbers.

Treating the ASN as a random configuration value creates several risks:

  • using a private ASN where a globally unique ASN is required;
  • leaking private ASNs into the public Internet;
  • assuming 4-byte interoperability without checking peer support;
  • writing regular expressions that break when ASN display notation changes;
  • misunderstanding AS_TRANS during old/new speaker interoperability;
  • and confusing BGP ASN identity with IGP process IDs or OSPF area numbers.

This post establishes the numbering discipline used throughout the rest of the series.

2. Standards behaviour

2.1 The original 2-byte space

BGP originally encoded autonomous-system numbers in a two-octet field. That provides values from 0 through 65535, although not every value is available for ordinary assignment. Growth in the Internet made this number space insufficient.

2.2 Four-octet ASNs

RFC 6793 defines BGP support for four-octet ASNs and uses a BGP capability to signal support between speakers. A speaker that supports four-octet ASNs can exchange that capability during OPEN negotiation.

The key operational point is that 4-byte ASN support was designed for transition and interoperability, not as a flag day where every router had to be replaced at once.

RFC 6793 introduces mechanisms including the AS4_PATH and AS4_AGGREGATOR attributes so newer speakers can preserve four-octet information when communicating through environments that include older two-octet-only speakers.

2.3 AS_TRANS

When a new BGP speaker with a four-octet ASN must communicate with an old speaker that cannot represent the ASN directly, the special value AS_TRANS (23456) is used in relevant compatibility processing. Engineers should recognize 23456 as a transition mechanism rather than automatically treating it as the organization’s real ASN.

2.4 ASPLAIN representation

RFC 5396 defines decimal representation of the complete ASN value as the textual representation to be used. This is commonly called ASPLAIN. Cisco documentation notes that IOS/IOS XE moved to ASPLAIN as the default display/matching representation in later releases, while older software had used ASDOT-style forms.

For this series, canonical examples will use ASPLAIN unless a topic specifically discusses notation compatibility.

Example:

65551

rather than representing the same 32-bit value using dotted ASN notation.

2.5 Private-use ASN ranges

RFC 6996 reserves two ranges for private use:

  • 64512–65534
  • 4200000000–4294967294

These are appropriate for closed labs and certain private routing designs.

However, RFC 6996 gives an important operational requirement: private-use ASNs must not be allowed to remain in AS path information when prefixes using them are advertised to the global Internet. Operators must design removal/filtering appropriately at the public boundary.

2.6 Public ASN ownership

A production organization that needs a globally unique ASN obtains it through the applicable Internet number-resource process, usually via its Regional Internet Registry or an appropriate sponsoring/provider arrangement depending on policy and region.

Do not copy an ASN from a tutorial into production merely because the configuration works syntactically.

3. ASN versus other routing identifiers

An ASN is not equivalent to:

  • an OSPF process ID;
  • an OSPF area;
  • an IS-IS NET;
  • a router ID;
  • a VRF route distinguisher;
  • a BGP cluster ID;
  • a VLAN ID;
  • or a local policy tag.

The ASN participates directly in BGP protocol semantics. It can appear in AS_PATH, influence whether a peer is treated as internal or external, participate in loop prevention, and affect policy.

4. Scenario — RETICUX Lab FND-002

We will extend the two-router foundation lab with one design requirement: document why the chosen ASNs are safe for a closed environment and prove how each router classifies the peer.

ASN plan


Autonomous System Numbers

| Device | ASN | Type | Reason |
|---|---:|---|---|
| EDGE-A | 64512 | Private 16-bit range | Documentation-safe closed lab |
| EDGE-B | 4200000001 | Private 32-bit range | Demonstrates four-octet ASN operation |

Addressing

  • EDGE-A Gi0/0: 203.0.113.1/30
  • EDGE-B Gi0/0: 203.0.113.2/30
  • EDGE-A Loopback10: 192.0.2.1/24
  • EDGE-B Loopback10: 198.51.100.1/24

5. Baseline configuration

EDGE-A

hostname EDGE-A
!
interface GigabitEthernet0/0
 ip address 203.0.113.1 255.255.255.252
 no shutdown
!
interface Loopback10
 ip address 192.0.2.1 255.255.255.0
!
router bgp 64512
 bgp log-neighbor-changes
 neighbor 203.0.113.2 remote-as 4200000001
 address-family ipv4
  network 192.0.2.0 mask 255.255.255.0
  neighbor 203.0.113.2 activate
 exit-address-family

EDGE-B

hostname EDGE-B
!
interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.252
 no shutdown
!
interface Loopback10
 ip address 198.51.100.1 255.255.255.0
!
router bgp 4200000001
 bgp log-neighbor-changes
 neighbor 203.0.113.1 remote-as 64512
 address-family ipv4
  network 198.51.100.0 mask 255.255.255.0
  neighbor 203.0.113.1 activate
 exit-address-family

These examples intentionally combine one private ASN from each RFC 6996 private range.

6. Verification before modification

Verify the configured autonomous system and neighbor classification

show ip bgp summary
show ip bgp neighbors 203.0.113.2

On EDGE-A, expected relevant fields include:

  • local BGP process ASN 64512;
  • remote AS 4200000001;
  • neighbor shown as an external link when established/configured as a different AS.

On EDGE-B, the reverse should be true.

Verify AS_PATH

On EDGE-A:

show ip bgp 198.51.100.0 255.255.255.0

Expected relevant field:

Path: 4200000001

On EDGE-B:

show ip bgp 192.0.2.0 255.255.255.0

Expected relevant field:

Path: 64512

The exact formatting of command output is platform/release dependent; this post records only the fields that should be inspected rather than fabricating an executed transcript.

7. Controlled modification — create an ASN mismatch

On EDGE-B, intentionally configure the wrong remote ASN for EDGE-A:

configure terminal
router bgp 4200000001
 no neighbor 203.0.113.1 remote-as 64512
 neighbor 203.0.113.1 remote-as 64514
end

Expected result

The BGP session should not establish successfully because the peer identity expected by EDGE-B does not match the ASN announced by EDGE-A in the BGP OPEN process.

This is a configuration-layer identity problem, not a basic IP reachability problem.

8. Fault injection

Illustrative lab — not a real incident.

Lab name

FND-002-ASN-MISMATCH

Fault

EDGE-B expects remote AS 64514 while EDGE-A actually operates BGP AS 64512.

Symptoms

  • Layer-3 ping can still succeed.
  • TCP may be attempted.
  • BGP does not remain Established.
  • Logs/neighbor state should point toward an OPEN/peer-AS mismatch rather than loss of interface reachability.

9. Troubleshooting

``text show ip interface brief ``

``text ping 203.0.113.1 ``

``text show ip bgp summary ``

``text show running-config | section router bgp ``

``text show ip bgp neighbors 203.0.113.1 ``

  1. Confirm the physical/interface state.
  2. Confirm IP reachability.
  3. Check BGP summary.
  4. Inspect the neighbor configuration.
  5. Inspect neighbor details and recent resets.
  6. Compare the local ASN on the remote router with the configured remote-as value.
  7. Correct only the proven mismatch.

A hard reset is not a substitute for correcting incorrect identity configuration.

10. Root cause and correction

Incorrect configuration

neighbor 203.0.113.1 remote-as 64514

Correct configuration

configure terminal
router bgp 4200000001
 no neighbor 203.0.113.1 remote-as 64514
 neighbor 203.0.113.1 remote-as 64512
 address-family ipv4
  neighbor 203.0.113.1 activate
 exit-address-family
end

Why it works

The configured peer expectation once again matches EDGE-A’s actual BGP autonomous system.

11. Post-fix verification

show ip bgp summary
show ip bgp neighbors 203.0.113.1
show ip bgp 192.0.2.0 255.255.255.0
show ip route 192.0.2.0 255.255.255.0
ping 192.0.2.1 source 198.51.100.1

Check that:

  • the session is Established;
  • the peer is recognized with the intended remote ASN;
  • the route is learned with the expected AS path;
  • the route is installed;
  • forwarding succeeds.

12. Rollback

Return to the known-good neighbor statement:

configure terminal
router bgp 4200000001
 no neighbor 203.0.113.1 remote-as 64514
 neighbor 203.0.113.1 remote-as 64512
 address-family ipv4
  neighbor 203.0.113.1 activate
 exit-address-family
end

Preserve logs and neighbor reset reason before clearing sessions if an unexplained production mismatch occurs.

13. Production lessons

Design lesson

Use globally assigned ASNs for public interdomain identity and private ASNs only where the design explicitly supports them.

Security lesson

Private ASN leakage is not merely untidy documentation. It can create ambiguous paths and connectivity problems and must be controlled at Internet boundaries.

Migration lesson

Four-octet ASNs are normal in modern BGP. Legacy assumptions about 16-bit-only ranges can break filters, regexes, inventory systems and monitoring tools.

Tooling lesson

Store ASN values as 32-bit-capable integers/strings in automation and telemetry pipelines. Do not assume a maximum of 65535.

Troubleshooting lesson

When IP reachability works but BGP will not establish, compare both sides’ ASN expectations early in the investigation.

14. Knowledge check

Q1

Which private-use ASN ranges are documented by RFC 6996?

Answer: 64512–65534 and 4200000000–4294967294.

Q2

Why can ASN 23456 appear during four-octet ASN interoperability?

Answer: It is AS_TRANS, used as part of compatibility with older BGP speakers that cannot directly represent a four-octet ASN.

Q3

A company uses private ASN 64520 internally and connects to the public Internet through another globally unique ASN. What design issue must be handled at the boundary?

Answer: Private-use ASNs must not remain in AS path information advertised to the global Internet; removal/filtering must be designed and verified.

15. Sources

  1. RFC 6793 — *BGP Support for Four-Octet Autonomous System (AS) Number Space*.
  2. RFC 6996 — *Autonomous System (AS) Reservation for Private Use*.
  3. RFC 5396 — *Textual Representation of Autonomous System Numbers*.
  4. RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)*.
  5. Cisco — *BGP Command Reference: show ip bgp neighbors / show ip bgp summary*.
  6. Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.x*.


#BGP #ASN #CiscoNetworking #NetworkEngineering #CCNP #InternetRouting #RETICUX

Labels:

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