> With the current “default free zone” containing around 1,000,000 routes
Back in ~1998 I was tasked with building a route collector/looking glass machine for an internet exchange point (sadly defunct). I remember the day we switched the collector on and acquired "all the routes", there were ~98,000 of them, you could've knocked me over with a feather. It was like looking into the Total Perspective Vortex. Having been out of that game for many years now I'd no idea we were up to 1M routes...wow. One of the RIPE conferences I attended back then there was much concern about the rapidly increasing size of the global routing table and whether vendors could build hardware powerful enough to keep up.
For anyone interested the route collector was built on FreeBSD (3.0 I think) and Zebra[0].
And finally, what cracking blog, especially stuff like this:
32,528 of them are in the 103.0/8 range, but on the other hand 21.0.0.0/8 is advertised once, no subnets at all. (same with 26, 28, 30, 33, 73. I don't have a route for 9.0.0.0/8 aside from 9.9.9.0/24.
Only 108,000 IPv6 routes.
One of course is that some Autonomous Systems don't advertise IPv6, either they have no globally routable IPv6 or they only achieve IPv6 via a tunnel and so that's only advertised via their tunnel provider.
But more important, many Autonomous Systems only need to advertise one prefix in IPv6 because it's big enough. Even if your needs grow, because we'd done this before and because IPv6 addresses are plentiful the allocations were deliberately sparse - so your RIR can give you the adjacent addresses, meaning you still only need one route entry for your larger space.
With IPv4 a provider may find itself advertising hundreds or even sometimes thousands of routes to the same Autonomous System since the addresses they need to advertise aren't contiguous.
https://cumulusnetworks.com/blog/768k-day-importance-adaptab...
[0] https://www.cnet.com/news/how-pakistan-knocked-youtube-offli...
I am not aware how popular and which company are using it, but I doubt that youtube is today as vulnerable as it was in 2008. BGP securities has a lot of tractions these days and is an interesting topic to follow.
However, now it seems like the Internet is facing new challenges and a different trade-off might make sense. Why not add a "valid until" attribute on each route? The originating router would have to re-announce a new route every 24 hours. Failure to propagate the update at any point would automatically withdraw it. Of course, re-announcing 1M routes every day might be a lot, but at this point it feels worth considering.
Now that's progress!
Reminds me of some of the naive comments in a few of the recent posts on HN about programming multithreading. It's not as easy as just adding more threads.
Or sending in more trains :) https://www.youtube.com/watch?v=-hyttagGsz0
In the case where there are multiple next hops to choose from, it might be nice to have some sort of quality metric to decide, but that's really tricky to measure and integrate. It's really outside the scope of BGP.
You would need to instrument packet loss or transfer speed or something like that by destination path on your application servers (or load balancers), and be able to adjust the proportion of traffic through various paths; keeping in mind that you can't really influence the path beyond your routers or the return path.
It's a lot of work, and I don't think the tools are built for it, but I would love to work on it for someone though. I did something similar for SMS routing, but that's a ton easier, fewer choices, less traffic, clearer success, etc.
Also, any valid BGP message resets the keepalive timer, so the reading side just needs to occasionally pop something off the full queue and process it. Which, say, if you're swapping to hell and back, can still get done. (Assuming it even has the scheduling get to killing things due to holdtime expiry. It might just not be expiring anything anymore for reasons of floating face-down in the river.)
Get Cisco and Juniper to implement it and that's 75% of LINX covered at least, I assume other exchanges have similar equipment makeup.
It seems reasonable behaviour to me.
It doesn't prevent the problem of the malicious BGP peer of course, but we know that already - if they choose to ignore your messages (while being happy with a high send-window) but continue to send keepalives you're equally screwed.
