AS216242 - Why?

I am currently the operator of AS216242. A lot of people are confused as to why I would want to run my own autonomous system, or how to do it at all. This is to explain and document it.

It started a few years ago. The company I work for had our only network guy go on extended medical leave. Over the years, he had trained me on much of our network equipment (switches, load balancers, and routers) but the one thing I knew very little about was advanced networking concepts (BGP, OSPF, etc). So, I took it upon myself to start reading up on BGP. Thankfully, we had no major issues during that time, but I got a better feel for how it all worked, and how to troubleshoot. But, I knew I really wouldn’t ever learn enough without being able to be hands-on.

iBGP

At this time, I had my home network (3 VLANs, an OPNsense router) and a number of VPS systems hosted with Vultr. To dip my toe in the water, I spun up another VPS with OPNsense on Vultr, and built a point-to-point WireGuard tunnel between the two. Then, I set up iBGP peering between the two, using the BGP functionality built into OPNsense, and a private AS number. The home router announced the IP ranges for my 3 VLANs, and the router on Vultr announced the IP range of my private network there. This did require some static routes to be configured on the VPS systems, but that wasn’t anything I wasn’t already familiar with thanks to my many years as a Linux SysAdmin.

DN42

Eventually, I wanted to learn more about eBGP, and I learned about DN42. DN42 is a project put together by a bunch of networking guys to “simulate” how the real internet works. It uses Private AS numbers, RFC1918 v4 space, and ULA v6 space. Peering links are point-to-point VPN (usually OpenVPN or WireGuard), and you talk BGP with your peers, just like in the real internet. So I registered an AS number, v4 and v6 space with the project, and set up a couple of WireGuard peering links, and I was on DN42. This process taught me a lot about route filtering, and controlling what routes I publish upstream, considering I still had my iBGP setup operational as well. I kept this in place for quite a while, and eventually I ended up switching from OPNsense to VyOS. A big part of that was the fact that at work, we changed from our old Foundry/Brocade gear to Juniper equipment, and the VyOS CLI was very similar.

The Real Internet

Eventually, gigabit fiber became available at my house, so I switched from my old cable modem connection (which was 1Gbps/200Mbps) to that (1Gbps/1Gbps). With the old cable connection, I could request a /56 of v6 network space, and be on the v6 network. But, the new fiber provider put me behind CG-NAT with v4 only, no v6 at all. For a while, I used the OPNsense router at Vultr with a v6 tunnel to Hurricane Electric, giving me a /40 of space, and brought part of that v6 space over my WireGuard tunnel back home. But, the latency was pretty terrible that way. I had thought occasionally about getting my own AS number and v6 space, but the prices with ARIN were a little high for a homelab, not to mention the need to register an LLC for ARIN to even talk to me.

I started researching, and ended up finding a Discord group dedicated to exactly this - hundreds of people who registered an AS number for their homelab. I ended up learning that RIPE - the regional registry for Europe - allowed individuals to obtain AS numbers and IP allocations. They would even allow US residents to do this, as long as they had some form of presence within the EU. I ended up registering for a RIPE ASN through https://cloudie.sh, and was assigned AS216242. As part of this, I was also assigned a /40 of v6 PA space by them. So, now I had an AS number and IP space allocated to me. I needed to find someplace to host it!

BGP from a VPS

So, the Discord group came to the rescue once again. I learned there are a number of companies that will provide a BGP connection to a VPS. A convenient list of most of them is available at https://bgp.services. I ended up choosing iFog since they had servers both in Europe as well as Kansas City. I knew that my provider had a direct 100Gb connection to KCIX, and my round trip time to the exchange from here in southeast Kansas was only about 9ms. Since iFog was also on KCIX, it meant that I’d have very low latency. So, I purchased an F4 VPS in Frankfurt, Germany (router-fra - to satisfy the RIPE requirements) and one in Kansas City (router2-mci). Later, I also found a second provider, F4, providing dedicated servers in Kansas City, and I took advantage of a special they had on a Xeon dedicated server with 64GB of RAM, and installed Proxmox on that system. Both VPS systems were installed with VyOS rolling, and the Proxmox system also had a VyOS VM installed on it (router-mci). I split my /40 up into 4 /42 subnets, announcing one /42 from router-fra, one from router2-mci, and the last 2 from router-mci. One of the two on router-mci was sent over a WireGuard tunnel to my VyOS router at home (router-k88). This allowed me to have full v6 functionality here at home, and it worked pretty well.

Adding v4

At this point, I had a fully functional BGP setup with v6. I wanted to learn what I needed to know about the v4 side of things as well, but getting your hands on v4 address space can be difficult and expensive. However, I am also an amateur radio operator. Back in 1981, a gentleman by the name of Hank Magnuski, callsign KA6M, was able to have 44.0.0.0/8 assigned to amateur radio operators worldwide. Any amateur radio operator can request an assignment of IP addresses from this space, and parts of this space are dedicated to hams who would like to announce this space over BGP. I made such a request, and was assigned 44.30.42.0/24, which I now announce from my system in Kansas City. I then again used VPN connections to hand out these IPs. The only real “gotcha” involved is that anything using these IPs must be related to amateur radio. So, currently these IPs are used for analog and digital radio hotspots, amateur radio websites, and other similar purposes.

The one thing I did discover after I added the v4 peering was that my low-memory VPS systems running VyOS were not able to handle both v4 and v6 route tables. For this reason, I scrapped VyOS from my 3 edge systems, and switched to a plain Debian 13 base, with the BIRD routing daemon, which works much better.

What is to come

The primary thing I want to eventually do is allow myself to announce the /24 v4 and my home /42 v6 from all 3 locations for redundancy. I had it sort of working, but the stateful nftables firewalls on the Debian boxes were not dealing with it properly, when traffic would, for example, go out router-mci, but come back in via router2-mci. I’ll figure that out eventually.