Full BGP table on a VPS without your own ASN — possible in 2026?

I've been exploring whether a budget VPS can handle the full IPv4 + IPv6 global routing table in 2026 without holding your own ASN or PI space. The short answer: yes, with caveats.

Three practical paths exist today:

• Provider-transit ASN with LOA. Some hosts (Contabo, OVHcloud) will announce your /24 or longer prefix under their ASN with a letter of authorization. You establish eBGP multihop to their route reflectors. You receive full feeds but do not originate. RPKI ROAs must align with their AS-SET in the IRR.
• Looking glass / research feeds. RouteViews and similar collectors offer read-only tables. Not actionable for traffic engineering but valid for path analysis and community string study. No transit value.
• GRE/WireGuard tunnels to transit-friendly endpoints. I run this presently: a 2GB KVM at Vultr t

1GB is tight. Full table + DDoS scrubbing = bad time.

Anycast over tunnel beats full feed for most. 400Gbps attacks now common. Scrubbing layer needs state, not 900k prefixes.

If you must: Bird 2.15 with filtered feed, drop >24, save 40% RAM.

1. Memory baseline: FRR 10.0.1 on Debian 12 requires 2.8GB stable for dual-stack full feeds with 4 upstreams. Convergence after cold start: 4m 12s on Ryzen 9 5950X, 8m 47s on Xeon E5-2680v4.

2. OpenBGPD 8.3 on OpenBSD 7.5: 1.9GB for same topology. RIB compression reduces path attribute storage by 34% per my metrics. Convergence slower: 11m 30s on identical hardware.

3. KVM constraint: cgroup memory limit includes kernel slab and socket buffers. A 1GB VPS with 1 vCPU at OVHcloud (E5-2680v4, 2.4GHz reported) OOM-killed bgpd at 847MB during peer establishment. The provider's virtio-net driver also imposed ~12% CPU overhead at 1Mpps.

4. Practical recommendation: 2GB minimum for single-homed full feed. Enable bgp graceful-restart. Set max-med on import to reduce bestpath computation. For production visibility, request a partial feed with default route from your tunnel endpoint rather than

Prices only go up

/24 will cost you a kidney. $12k last month on ipv4market. Used to be $8k in 2024.

You want PI space for this? Good luck with RIPE last /22 policy. LIRs sitting on hoarded blocks renting at $0.50/IP/month.

BGP table growth is IPv4 table growth. More deaggregation, more /24s from speculators. Feed gets fatter, RAM gets thinner.

Anyway

3am experiment on a 768mb RackNerd kvm, openbgpd 8.3, wireguard tunnel to my friend's box at some colo in prague

# bgpctl show rib | wc -l
  974381

# vmstat
procs  memory       page
 r b   avm    fre   flt
 1 0  687M    41M   0

41MB free. Idk why I do this. Convergence took 19 minutes. Box started swapping when I added a second peer. Kernel route cache ate the rest.

Single feed works. Barely. Would not route actual traffic through it. The virtio interrupt was at 40% cpu just from keepalives.

OpenVZ would explode here. No separate route table namespace, kernel route cache shared with host. You would need the host to carry 975k prefixes, which no oversold OpenVZ node does.

KVM with virtio-net: better, but still virtualization tax. The vhost-net backend on the host copies every BGP update through userspace. At 150-300 prefix changes per second during normal churn, this is negligible. During a session reset, you see 30-60 seconds of 50-80K pps control plane traffic. The virtualization tax manifests as CPU steal during this window.

I measured 8% steal on Vultr's "NVMe KVM" tier during convergence. Their Ryzen 7950X nodes show less than 3%. The E5 nodes at Hetzner spike to 22%. Avoid.

For 1GB full feed: possible only with OpenBGPD and a tuned kernel. FRR's zebra holds duplicate RIB structures that balloon under cgroup limits. Bird 2.15 is middle ground but lacks some comm

What RAM did OVHcloud actually allocate, 1GB or 2?

Bird 2.15 or FRR 10.0.1 — which did you end up running?