AS Number Range Checker and BGP ASN Planner

With best intentions, you begin your home lab. It’s time to learn how routers talks to each other and you want to run BGP. Unfortunately, you come up against a brick wall. How do I choose an autonomous system number?

There is conflicting advice everywhere on the internet. “Pick something random” says one guide. “Grab yourself something from this range” says another.

How to Pick the Right BGP Number for Your Home Lab

Here lies the issue; not all AS numbers are created equaly. Some are private, some are reserved for documentation purposes, some are absolutely forbidden from ever going anywhere near public internet. Choose incorrectly and you may end up announcing your private network to the world… or worse, having routes go completely missing.

Once you have your config line pasted into your router, though, there’s no guarantee you got the right number in there. That’s where the calculator comes in to help separate the wheat from the chaff. It doesn’t just validate a number. It also tells you what that number mean.

You can put in a range of ASNs and the tool verifies the range against the IANA special registry. Does that mean you’re in public space? Or private space? Or even documentation space? Because how BGP treats an origin depends on which one it is.

Use the wrong one (like trying to use a public ASN in a lab without proper filtering) and you may leak routes. Use a reserved ASN in production and guess what? Your transit provider won’t accept you.

The tool catches this kind of problem by calculating a risk score based off your inputs.

The second most popular error is using the 16-bit private range. The range of 64512, 65534 is reserved for private use at home. It is for home labs. Configure your VyOS, FRRouting or MikroTik devices there without fear of colliding with actual operators.

The reference table on the page explain it nicely. It shows how those addresses get stripped before being sent out onto public internet. That’s the point. Those addresses aren’t global; they’re local. Freedom. You can re-use them. And you can overlap them across different lab segments. Just don’t announce them upstream.

What if your lab is getting bigger though? What if you’re working on something like a multi-tenant fabric or an EVPN overlay? When you start assigning an ASN to each tenant or virtual network, the 16-bit private range run out pretty quickly. There’s only about 1,000 numbers you can use.

That’s where 32-bit ASNs enter. 2 billion. Safe too. Defined by RFC6996. Use the calculator to see if your peers has it covered. Some routers and some versions of router software don’t handle 4-byte ASNs so well. If you’ve got old and new mixing together you may run into compatibility walls. The tool flags that as a risk. Warns you if your peer list suggests you may have some legacy equipment that requires AS_TRANS workarounds.

It’s also about planning for growth. You want some ASNs for right now and some ASNs for later on. How many ASNs do you need right this minute? And how many would you like reserved in case you start a new project or add another site? So that’s what the tool asks for, and it adds a buffer.

It uses simple math to apply a buffer so you don’t run out of space before you know it. For a home lab, a 10% buffer is normally sufficient. That provides some breathing room while using as few addresses as possible. After calculating the buffers and conflicts, the calculator shows you exactly how many usable ASNs is left over. Did your plan fit?

The tool shows you if your plan fits, and also calculates the exact number of usable ASNs taking into account buffers and conflicts.

And there’s another little bit here (documentation). There are special ASN ranges that blogs and books reserve for demonstration purposes. These ranges come from RFC5398. This is great if you’re writing a guide. It is bad when you copy-paste a blog example into production and accidently import a block of example ASNs into your live network. That’s what the checker catches. It won’t let you put down example data by mistake. It is a tiny thing, but it is significant. It prevents you from spending hours troubleshooting why your routing table looks like an example out of a textbook, not a functioning network.

BGP is strong stuff but it’s also unforgiving. It expects you to know what you’re doing. A planner takes the guesswork out of it. Check the ranges. Verify your peers. Make sure your private space remains private.

That way you can get down to the fun stuff. The building the network part. You watch the routes spread. You see the protocols do their thing. With the proper numbers in place, all the rest is just configuration.

So start simple. Use private ranges in your lab. If you go live, get some public ones from your RIR. Separate your documentation. And always check that risk score before you hit enter.

That way your BGP sessions remains stable, your routes remain clean, and your lab remains yours. You should of checked the math too.