When you run BGP with an upstream provider, you choose how much of the internet routing table it sends you. The main options are the full table, partial routes (usually combined with a default), and a default route only. The right choice depends on how many providers you connect to, how much control you need over outbound traffic, and what your routers can handle.
Full Internet Table
Your provider sends you every prefix it knows about: currently about a million IPv4 prefixes plus a few hundred thousand IPv6 prefixes, and both numbers keep growing. For each prefix you get the provider’s best path, along with attributes such as AS path and communities. You don’t see every path that exists on the internet, only the one your provider has chosen.
Benefits
- Best-path outbound routing when multihomed. With full tables from two or more providers, your routers can pick the provider with the better path (for example, the shorter AS path) for each destination, instead of sending everything to one exit.
- Detailed outbound traffic engineering. You can write policy for specific destinations or networks, such as preferring Provider A for a certain cloud provider or business partner.
- Visibility. Having the table on your own routers helps with troubleshooting, checking reachability, and spotting route anomalies.
Things to watch out for
- Hardware limits. Make sure both the routing table (RIB) and the forwarding hardware (FIB/TCAM) can hold the full table with room to grow. Platforms that ran out of space caused real outages, such as the “512k day” event in 2014.
- Slower convergence. After a session or link failure, a larger table takes longer to process and reinstall.
- BGP doesn’t measure performance. Path selection uses attributes like local preference and AS-path length, not latency, bandwidth, or congestion. Routing by performance needs manual policy or extra tools.
Typical use cases
- ISPs and transit providers, which need full tables to route between customers and the rest of the internet.
- Large enterprises, content providers, and data centers connected to multiple providers that need detailed outbound control.
Partial Routes + Default
A partial table is not a list of “popular” routes. It’s usually the provider’s own prefixes plus those of its direct customers (its customer cone), and sometimes its peers’ routes too. These are destinations your provider reaches directly, so sending that traffic through it is usually the best choice. A default route is almost always sent along with it to cover everything else.
Benefits
- Most of the benefit of a full table at a fraction of the size. Traffic to each provider’s own networks takes the direct path, and everything else follows the default.
- Lower memory and CPU needs and faster convergence than a full table.
- Works on modest hardware that can’t hold the full table.
Things to watch out for
- For destinations outside the partial set, path choice depends on how the default routes are set up (for example, primary/backup via local preference, or load sharing).
- The configuration effort is about the same as for a full table. The savings are in resources, not complexity.
Typical use cases
- Mid-sized enterprises connected to two or more ISPs that want better outbound paths without full-table hardware.
- Sites where one provider has a large share of the destinations you care about (for example, a regional ISP serving your customers or partners).
Default Route Only
The provider sends a single route, 0.0.0.0/0 (and ::/0 for IPv6), that matches any destination not otherwise in your table and points to the provider as the next hop.
Benefits
- Minimal resource use and the simplest possible routing policy.
- Simple failover. Default routes from two providers, one preferred over the other, give you reliable redundancy. You don’t need a full table for failover.
Things to watch out for
- No per-destination path choice. Outbound traffic goes to whichever default is preferred, even when the other provider has a much better path.
- A provider can keep sending you a default route even after it has lost some of its own upstream connectivity, so traffic may go into a degraded network.
Typical use cases
- Organizations that need BGP mainly to advertise their own address space across two providers, with simple primary/backup or active/active failover.
- Note: a small site with a single ISP and provider-assigned addresses usually doesn’t need BGP at all. A static default route does the job.
Side-by-Side Comparison
| Full Table | Partial + Default | Default Only | |
|---|---|---|---|
| Routes received | About 1M IPv4 + a few hundred thousand IPv6 | Provider’s own and customer prefixes, plus default | 1 per address family |
| Router memory/CPU | High; check FIB capacity | Low to moderate | Minimal |
| Outbound path quality (multihomed) | Best path for each destination | Good for the provider’s own networks, default for the rest | Whichever default is preferred |
| Failover | Yes | Yes | Yes |
| Convergence after failure | Slowest | Faster | Fastest |
| Effect on inbound traffic | None. Inbound is controlled by what you advertise. | ||
| Typical user | ISPs, large multihomed networks | Mid-sized multihomed enterprises | Multihomed sites needing simple failover |
Other Options and Considerations
- Receive full, install partial. You can take the full table and filter it yourself, for example accepting only prefixes up to a certain AS-path length or only certain networks. Some platforms can also keep the full table in the RIB while installing only part of it in the FIB.
- Route security. Whatever you receive, apply inbound filters (bogons, your own prefixes, prefixes that are too specific), set maximum-prefix limits on sessions, and consider RPKI route origin validation to guard against hijacks and route leaks.
- uRPF. Strict unicast reverse-path forwarding can drop legitimate traffic on multihomed links. With full or partial tables, loose mode is usually the safer choice.
Choosing
If you have one provider, you probably need a static default, not BGP. If you’re multihomed and mainly need failover, a default route from each provider is enough. If you also want better outbound paths but have limited hardware, use partial routes plus a default. Take full tables when you need detailed control of outbound traffic and your routers can handle the size and its growth.