BGP Full Routing Table vs Default Route: What to Accept

A BGP full routing table vs default route decision comes down to one question: do you need to choose between multiple paths to the internet, or do you just need one good exit? If you have a single upstream, a default route or provider-only routes are almost always enough. If you are multi-homed and want to control outbound traffic per destination, you need a full table.

This guide compares the three common options, explains the real RAM and CPU cost, and gives sample filters you can adapt.

The Three Options

Those global table sizes grow every year, so verify against a public source before sizing hardware.

Full table

You get a route for nearly every prefix on the internet. Your router or VDS can compare paths from several upstreams and pick the best one per destination using local-pref, AS-path length, MED, or your own communities.

Default route

The upstream sends one route that means "send everything to me." Your device makes no per-destination choices. It is simple and light, but you give up visibility and control over outbound paths.

Provider routes only

You receive only routes originated by the provider and its customers. This is enough to reach those networks directly, but you still need a default route for everything else. Whether the provider also sends a default, or you configure a static one, is something to confirm up front. A missing default is a classic cause of "the session is up but nothing works."

RAM and CPU: What a Full Table Actually Costs

Numbers vary by software version, address families, and how many sessions you run. Treat these as orders of magnitude, not guarantees.

Memory - Each full feed stores around a million IPv4 routes plus IPv6 in the routing daemon (BIRD, FRRouting). Attributes are shared between routes, but memory still grows with the number of feeds. - The Linux kernel FIB holds the best route per prefix. On a VDS there is no hardware forwarding table, so the kernel table uses ordinary RAM. - Every additional full feed adds to the daemon's memory because it keeps alternative paths for each prefix. - Options like keeping filtered routes (import keep filtered in BIRD, soft-reconfiguration inbound in FRR) add more memory. - Practical rule: for one full feed on a VDS, leave at least a couple of GB of RAM headroom for the daemon and kernel, and more for several feeds. Measure on your own system after convergence.

CPU - The initial table download is the heavy moment. The daemon processes about a million updates, applies your filters, and installs routes into the kernel. Expect a CPU spike for tens of seconds to a few minutes depending on vCPU count. - Steady state is usually quiet, with a constant trickle of updates from global churn. - Session resets are the expensive events. Every flap means re-downloading and reprocessing the table. Complex filters (long AS-path regexes, large prefix-list lookups) make each reload slower. - Single-threaded parts of the daemon mean that more vCPUs help less than higher per-core speed.

A default route or provider-only session makes all of this negligible: a few routes, no spike, no reset penalty.

Which Option for Which Scenario

Announcing your own prefix from a single VDS with one upstream. Take a default route or provider-only routes plus a static default. Your goal is to originate your ASN and prefix, not to optimize paths. See our guide to announcing your own IP block via BGP for the prerequisites.

Hosting or game servers behind one upstream. Default route. Outbound traffic goes to the upstream, which decides the best path. You save resources for the workload itself.

Two upstreams for redundancy only. Default routes from both with different local-pref values (primary and backup) are often enough. You get failover without a full table.

Two or more upstreams with per-destination control. Take full tables, or a partial table (provider routes plus customer routes from each) plus a default as a fallback. Partial tables give you much of the benefit at a fraction of the cost.

Route analysis, research, or looking-glass-style tooling. Full table, ideally with a collector or a dedicated box. Do not run this on a small VDS next to production workloads.

Transit, IX peering, or building a mini-ISP. Full table on proper hardware or a well-sized dedicated server. At that point, think about dedicated servers rather than a small virtual machine.

Sample BIRD 2 Filters

These examples use documentation values: your ASN is AS64500, the upstream is AS64496 at 192.0.2.1, and your prefix is 198.51.100.0/24.

Accept only a default route

filter default_only {
    if net = 0.0.0.0/0 then accept;
    reject;
}

filter announce_mine {
    if net = 198.51.100.0/24 then accept;
    reject;
}

protocol bgp upstream4 {
    local as 64500;
    neighbor 192.0.2.1 as 64496;
    ipv4 {
        import filter default_only;
        export filter announce_mine;
        import limit 5 action restart;
    };
}

The small import limit works as a safety net. If the provider starts sending more than expected, the session is shut down rather than flooding your table.

Accept a full table safely

function is_bogon_v4() {
    return net ~ [ 0.0.0.0/8+, 10.0.0.0/8+, 127.0.0.0/8+,
                   169.254.0.0/16+, 172.16.0.0/12+, 192.0.2.0/24+,
                   192.168.0.0/16+, 198.51.100.0/24+, 203.0.113.0/24+,
                   224.0.0.0/3+ ];
}

filter full_in {
    if is_bogon_v4() then reject;
    if net.len > 24 then reject;
    if bgp_path.len > 64 then reject;
    bgp_local_pref = 100;
    accept;
}

protocol bgp upstream4 {
    local as 64500;
    neighbor 192.0.2.1 as 64496;
    ipv4 {
        import filter full_in;
        export filter announce_mine;
        import limit 1200000 action restart;
    };
}

Note that the bogon list above also rejects the documentation ranges used in this article. In a real config, remove the documentation entries for your own prefix, or the filter will block it. Also keep the export filter strict, so you never leak upstream routes to another upstream.

FRRouting equivalent for a prefix cap

router bgp 64500
 neighbor 192.0.2.1 remote-as 64496
 address-family ipv4 unicast
  neighbor 192.0.2.1 maximum-prefix 1200000
  neighbor 192.0.2.1 route-map UP-IN in
  neighbor 192.0.2.1 route-map UP-OUT out

For the full FRR walkthrough, see our earlier article on bgpd configuration and route-maps.

Verify What You Receive

birdc show protocols all upstream4
birdc show route count
ip -4 route show | wc -l
free -m

Compare the route count with what you expect, then watch memory after the session settles. You can also check how your prefix looks from outside with a public looking glass, such as the Nixcon looking glass, which supports BGP route, ping, and traceroute queries from İzmir, Frankfurt, and the US.

Common Mistakes and Fixes

• Session is Established but no traffic flows. You took provider-only routes and have no default route. Add a static default via the upstream next hop or confirm the provider sends one.
• Out-of-memory kills on a small VDS. A full table was accepted on a VM sized for the application. Move to a default route, or add RAM. Remove keep filtered if you do not need it.
• Session flaps after config reload. Large filters and a full table make reloads slow. Use birdc configure with soft reconfiguration instead of restarting the daemon, and avoid unnecessary changes.
• Accepting a default and a full table together without preference. The default is only used when no more specific route exists, but a bad filter can create odd paths. Be explicit about local-pref per source.
• No maximum-prefix limit. A leak or misconfiguration upstream can fill your table. Always set a limit sized to what you expect to receive.
• Leaking routes between upstreams. Export only your own prefixes. Rejecting everything else by default prevents accidental transit.
• Forgetting IPv6. A second address family needs its own filters, limits, and session or channel.

How This Maps to Nixcon BGP VDS

On a Nixcon BGP VDS, the routes you receive are a choice you make at setup. You can receive only Nixcon routes, or ask for the full routing table. You also pick between a DDoS-unprotected or DDoS-protected announcement. Your ASN and prefix are checked automatically against RPKI ROA and RIR/IRR records, and your ASN is added to the AS-NIXCON AS-SET. Setup is automated. Details are on the BGP-enabled VDS page.

If your use case is a single upstream with one announced prefix, start with the lightest option. You can move to a full table later when you have a measured need and the resources for it.

Quick Decision Checklist

1. One upstream and no need for path control: default route or provider-only routes plus a static default.
2. Two upstreams for failover: default routes with different local-pref.
3. Multiple upstreams and traffic engineering: full or partial table.
4. Small VDS: avoid full tables unless the VM is sized for them.
5. Always: prefix limits, strict export filters, RPKI-aware policy, and IPv6 handled separately.