Documentation ASNs (RFC 5398)

You landed here because the AS number you looked up falls inside one of the two documentation ranges defined by RFC 5398. These numbers exist specifically so authors of books, RFCs, blog posts, vendor training material and product docs can show realistic BGP configurations without accidentally colliding with a live network. No operator is ever assigned an ASN in these ranges, and a router that sees one in the default-free zone should drop the route at the ingress filter.

Why they exist

Before RFC 5398 was published in 2008, examples in BGP documentation used real ASNs — sometimes ones that later got re-assigned, which meant a training manual could point at a live network and pull the wrong operator into an unrelated discussion. RFC 5398 carved out a small block of 16 numbers per ASN width (32 total) so authors always have a safe pool to draw from. The equivalent address-space ranges are 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24 from RFC 5737, plus 2001:db8::/32 from RFC 3849.

Where engineers see them

• RFCs and I-Ds. Every IETF draft that needs to show a router-bgp config.
• Vendor docs. Cisco, Juniper, Arista, Nokia, and Huawei all use AS64496/AS64512 in their BGP configuration guides.
• Training labs. CCIE/CCNP, JNCIE, and self-study platforms like CBT Nuggets and INE ship topologies wired on these ASNs.
• Books. Doyle’s Routing TCP/IP, White’s Optimal Routing Design, van Beijnum’s BGP.
• Leaked configs. When a lab config escapes onto production, this block is the canary: no real network should ever see it on the wire, so anti-bogon filters flag it immediately.

Why ipctl can’t look them up

Documentation ASNs are not delegated by any RIR and are not tracked in any WHOIS or delegated-stats file. There is no record to return, and any sighting of one of these numbers in live BGP is a misconfiguration — typically a customer that forgot to swap the lab ASN for their real one before bringing up the session.

Frequently asked questions