It is kinda funny, right before this whole Facebook thing happened I started trying to explore BGP more. I actually found a really cool guide(https://labs.ripe.net/author/samir_jafferali/build-your-own-...) from RIPE that walks you through setting up an AS to do anycast.
I have been doing some pretty heavy networking stuff for years, but I finally got an AS number and IPv6 block assigned to me. My thought is that if it is cheaper to just do something to learn it rather than taking a class you should just do it.
The least expensive way, if you have a networking presence in their service region, is to retain the services of a sponsoring LIR in the RIPE area. For example, Securebit will do it for 60CHF setup and 15CHF per year: https://www.securebit.ch/internet/resources
You need to show that you will have connectivity through two upstreams to justify receiving an ASN. This is easy to do, pick two providers from bgp.services (or pick one other provider and also list Securebit's tunnelbroker.ch service).
You will also need to show that you have a network presence in the RIPE service area. This is also easy to do, rent an inexpensive dedicated server or a couple of BGP virtual machines in Europe and have a copy of the invoice ready to give to your chosen sponsoring LIR.
Regarding IPv6 blocks, there are two types of IP space assigned from the registries: provider aggregated and provider independent space. The latter is directly assigned to you as an end user for your own use (you can't assign it to customers for their networks, for example). If you have PI space, you can move it from one LIR to another without changing numbers. The free IPv6 space that LIRs and others will lend you is PA space so you can't take those numbers with you. There's no real distinction if you are just learning, but you might want to choose a sponsoring LIR bundle that comes with PI IPv6 space in case you think you might change LIRs and want to keep your existing IP setup.
Oh, one other thing: the provider independent assignments from RIPE are /48, or the smallest IPv6 subnet that can be announced (akin to an IPv4 /24). If you want to announce multiple IPv6 subnets into the global BGP table, you will need a larger allocation, usually from your sponsoring LIR. Every sponsoring LIR I've seen will give you anywhere from a /44 to a /40 for free and that's many /48s for you to play with.
(It's no longer possible to get PI IPv4 space from registries. You'd have to buy it on the open market and it is expensive. You can either buy IPv4 PA space from the open market or you can join RIPE and get a single /24, and both are expensive.)
If you are at all interested in networking, I highly recommend doing this or joining the private DN42 network that's mentioned elsewhere in the thread. Setting this all up and actually seeing your IP addresses respond to pings from a machine halfway around the world is, to me, an amazing feeling.
We aren't going to run out of 32-bit (six digit) ASNs or IPv6 addresses any time soon, so you're not consuming a scarce resource by doing this.
Awesome writeup; I used SnapServ and so far the guy that runs it has been nothing but awesome. I am not experienced what it comes to this specific area of networking since it is my first time trying to get my own IP block; he walked me through everything and even corrected dumb mistakes I made in my RIPE registration with great explanations as to what my mistakes were.
BGP is spoken between networks. There are a lesser known "IGP" protocols stitching together the insides of those networks. IS-IS and OSPF being the most notable. Though the nature of the beast is that when you screw up BGP everyone sees it, and when you screw up your IGP it could just look like servers or load balancers having a bad day. Though if a telco messes them up everyone notices.
dn42 [0] also has, effectively, a playground for BGP. While I don't have experience with it personally, it seems to be just a VPN network with private addressing where you can find other folks to form neighbors with.
That being said, you don't need to be online to play with routing protocols. A couple VMs with your favourite flavour of Cisco/Juniper virtualised switches do just as well. Some of the most popular projects to simplify VM spin-up and interconnections are GNS3 [1] and EVE-NG [2].
I'm surprised large users don't have a simulate-before-issuing BGP-changes policy given the number of times BGP has bitten people. I imagine the devil would be in the differences between your sim and actual behavior, but it might save a few people a lot of pain.
I recommend bgp.he.net and bgp.tools too - they are simpler and more lightweight than RIPEStat, so they’re nice to use when you don’t need all the features of RIPEStat.
bgp.he.net was down (extremely slow/timing out/failed my bot check and told me to turn on JS and cookies, both of which were on) when I checked it while Facebook was down.
13 years ago I wrote a nice reference implementation for BGP "client" use - I just treated it as an API onto Cisco routers: https://github.com/BytemarkHosting/bgpfeeder is 1300 lines of Ruby, one file, no dependencies, and quite verbose.
At the time I was running a hosting company & wanted to feed updates to our IP lists from a web-based database into our routers (e.g. a customer wants a new IP to their servers, or moves their VPS images between physical hosts). But I couldn't understand how to get tight control of quagga, or the Ciscos and wondered how how to speak it directly?
It took about a week poring over the RFCs and the Net::BGP Perl module, but I can go back to it now for some useful revision. It brought a lot of disparate BGP knowledge together in one place, and re-expressed it in a language I still know. So if you know Ruby and are curious about BGP it might help you see what you can do with it.
Though if you want to use BGP to control your network devices today, you'd use https://github.com/Exa-Networks/exabgp instead. It can pull every trick you could possibly want with BGP - e.g. DDoS mitigation, anycast, and generally letting you mess with BGP via JSON. There are lots of extensions to BGP, and I only cared about the ones to send v4 & v6 routes around. Also I only wanted to write one file :)
PS, there is one horror in BGP implementation and that is TCP-MD5. i.e. to authenticate to a peer, you sign every packet of your TCP connection with a little extra extension that contains an MD5 sum derived from a shared secret. It's so weird, but probably preferable to IPSEC or whatever would have been "standard" in 1998: https://blog.habets.se/2019/11/TCP-MD5.html
It's a wee bit out of date having been written ~20 years ago, but it gives you the general gist of how BGP works as pertaining to the actual internet rather than the RFC theory.
I used it (and the first edition) when I got dropped into a project to build out an internet exchange point with a route collector and all that good stuff circa ~1999.
I semi-regularly come across what I believe to be messed up BGP routes (doing support for global companies trying to reach specific webhosts) and yet I'm still just absolutely stumped on find any way to report the issues.
I imagine that's to reduce support load on the network teams running all of this, but some kind of check would be helpful.
I have been doing some pretty heavy networking stuff for years, but I finally got an AS number and IPv6 block assigned to me. My thought is that if it is cheaper to just do something to learn it rather than taking a class you should just do it.