For a VPS with one upstream and no destination-specific routing policy, a default route is usually a sensible starting point. A full table becomes useful when you have a specific decision to make with the extra routing information.
In GetVPS VPS Control → BGP Sessions, the route-mode choices depend on the location. Some locations offer default routes only. Use the options shown for your service and keep the peer details from the generated configuration; choosing a mode is not a reason to invent a different neighbour.
If you have not provisioned a session yet, start with the BGP walkthrough.
What changes between the modes?
| Default route | Full table | |
|---|---|---|
| Destination information | A catch-all route for the address family | The internet prefixes the peer chooses to advertise |
| Who makes most onward path decisions? | Your upstream | Your router can apply policy to the received destinations |
| Local state | Relatively small | More routes, attributes, and update processing |
| Useful starting case | A service node with one ordinary exit | A router with multiple paths or a defined routing-policy task |
A full feed is still one peer's view. It is not every possible path on the internet. Two sessions with the same upstream can improve session redundancy, but they do not automatically create two independent transit networks.
IPv4 and IPv6 are separate decisions. Check the selected mode and received routes for each family.
Receiving routes and announcing your prefix are separate
You can announce your authorised prefix while receiving only a default route. Receiving a full table does not make your prefix more globally visible. Visibility depends on your export policy, upstream acceptance, authorisation, and propagation.
Keep a narrow export allowlist for your own prefixes in either mode. Do not export routes learned from an upstream back to other peers unless you deliberately operate that transit policy.
If your session is up but your prefix is unreachable, use the prefix troubleshooting guide. Changing the inbound feed is unlikely to fix an unrelated export-filter or listener problem.
Decide what you will do with the extra information
Before choosing a full table, finish this sentence: “For destination prefixes matching this condition, I will choose this path or apply this policy.”
Examples include preferring one of two genuine upstreams for selected destinations, studying received paths in a routing lab, or testing a routing policy against real announcements. Write down the intended behaviour and how you will verify it.
If every destination will leave through the same next hop regardless of the received attributes, the full feed may add operating cost without changing forwarding. It does not by itself reduce application latency.
Also decide what should happen when a session withdraws its routes. A remaining default can preserve reachability, but it can also conceal the loss of a more-specific route. Monitor both the BGP state and the intended egress behaviour.
Measure the VPS you intend to use
There is no reliable universal RAM-per-prefix figure. Memory depends on the daemon version, address families, peers, attributes, retained paths, import/export tables, and what is installed in Linux. Leave capacity for the service running beside the router and for updates during convergence.
Record a baseline before changing the feed:
sudo birdc show status
sudo birdc show protocols all
sudo birdc show route count
free -h
ps -C bird -o pid,rss,%cpu,etime,args
ip -4 route show table main | wc -l
ip -6 route show table main | wc -l
rss is process resident memory in KiB. The ps CPU value is an average over the process lifetime, so use top or your normal monitoring for short convergence spikes. Available memory matters more than the size of the unused-memory column alone.
If your configuration uses several BIRD tables, inspect the relevant table explicitly. show route count reports BIRD's view; Linux route counts report installed forwarding entries. They are not interchangeable, and the kernel protocol determines what BIRD exports to Linux. See the BIRD 2 manual.
The Linux commands above count lines in the main table as a rough baseline. If you use policy routing, inspect ip rule show and the actual tables involved instead. Do not use those line counts as a precise internet-prefix census.
Change the feed in a controlled test
First save the working BIRD configuration and record the portal's current route mode. Keep an out-of-band console available before changing a router that carries your SSH connection.
On a test node or in a maintenance window:
- Select the desired route mode offered by the portal and retrieve any updated configuration it provides.
- Review changes to import policy, tables, and kernel export before applying them. Preserve your own-prefix export restrictions.
- Watch received-route counts, memory, CPU, and session stability until the feed settles.
- Test representative destinations from the VPS using the intended source addresses. Confirm which next hop Linux actually selects.
- During an agreed failure test, withdraw or disable one session and observe recovery, including the management connection and application traffic.
Write down the daemon version, enabled address families, peer count, table design, steady memory, and peak memory during the test. Those observations provide a basis for sizing. An idle screenshot taken before routes arrive does not.
Make rollback part of the choice
If memory pressure, slow convergence, or unexpected egress appears, restore the previous route mode and known-good configuration. Confirm the expected default route and application reachability before declaring rollback complete. Avoid clearing unrelated firewall rules or routing tables as part of the rollback.
For a single-exit service node, staying with a default route is a deliberate design choice. For a node that needs destination-level policy, a full feed is useful when you have measured the resources and tested the behaviour it enables.