A Migrated BGP Router, a Real Throughput Bug, and a Hardware Store Fix
Moved the cloud side of my own BGP setup to a new, unmetered 10G VPS and rebuilt the tunnel between it and the home office from the ground up — which turned up two real infrastructure bugs along the way. That led straight into root-causing a long-standing mlvpn-rs throughput mystery all the way to an ISP traffic policer. In between: a quick PC repair at the local Ace Hardware in Zion.
Migrating the cloud BGP router to a real 10G, unmetered box
The cloud half of my BGP setup — the side that peers with my upstream and announces my own IP space out to the internet — moved to a brand-new VPS on a genuinely unmetered 10 gigabit connection. Getting it there meant standing the whole stack back up from scratch on the new host: BIRD for the actual BGP session, the WireGuard tunnel back to the upstream, and mlvpn-rs itself for the link back to the home office, cut over cleanly with no duplicate announcements while the old server was still technically live.
Two real bugs showed up once traffic was supposed to be flowing end to end. First, the routing rules that are supposed to send my own delegated address space back out to the internet were referenced in the BGP config's own comments but had actually never been written down anywhere — added, and traffic started moving. Second, and much sneakier: routing was correct, but nothing was actually getting through. Turned out Docker, running on the same box for an unrelated service, quietly installs its own firewall rule that blocks all forwarded traffic by default — invisible unless you know to go looking for it, since the routing itself looks completely fine right up until the point a packet actually needs to leave the machine. Fixed properly by adding an explicit rule to the exact chain Docker itself provides for this — not a rule that competes with Docker's own logic and could get silently overwritten the next time Docker restarts, but one that's guaranteed to survive it. Confirmed by actually rebooting the box on purpose and checking that routing still worked afterward, not just trusting that it would.
Root-causing a real mlvpn-rs throughput mystery
With the new cloud router up, the obvious next question was why mlvpn-rs's own speed test kept reporting only 6–8 Mbps on a home connection that's actually rated for 45 Mbps upload. The daemon's own internal counters showed zero drops anywhere — which had looked, on paper, like a genuine unsolved mystery going back months. Chased it further this time: captured raw network traffic during a real test and found the daemon was actually trying to send data at nearly 400 Mbps — almost ten times the real connection's capacity — with literally zero pacing or rate limiting on the sending side. The excess was getting silently dropped by the ISP's own equipment before it ever left the building, invisible to anything running on the box itself.
Fixed with a proper adaptive approach: the daemon now ramps its test traffic up gradually — a little, then a little more, then more again — until it actually finds the real ceiling, then backs off to a safe margin below it, the same rough idea as how a cautious driver finds a slippery road's actual grip instead of gunning it and finding out the hard way. No manual configuration needed on any given connection. A second, more careful code review (deliberately asked for, on top of the review each piece already got as it was built) caught a real edge case before it ever got installed anywhere real: if literally every measurement attempt failed, the old logic would still report a fabricated number and quietly bake it in as the truth from then on, permanently corrupting how the daemon plans around that connection. Fixed, tested, and now live on both ends of my own real connection at home and in the cloud.
Smaller things
Fixed up a manager's PC at the local Ace Hardware here in Zion — the kind of quick, in-person fix that's a nice change of pace from a week spent entirely inside network configs and Rust code.