BGP Full Table or Default Route: What Does My Router Need?
Default, full tables or selected routes plus default: choose the right route feed for single-homed and multi-upstream networks.
A default route is often sufficient when a network uses one upstream or only needs a general primary and backup path across two upstreams. Full BGP tables become useful when the local router must choose between several exits for many individual destination prefixes. A practical middle ground is selected routes for deliberate decisions plus a default for everything else. The right choice follows from the required routing policy—not from port speed.
The three models at a glance
| Model | The router receives | Typical use | Limit |
|---|---|---|---|
| Default only | 0.0.0.0/0 and/or ::/0 | Simple standard path or primary/backup | No local path choice per Internet destination |
| Selected routes + default | Defined prefix groups and a standard path | Targeted decisions with a limited table size | Only supplied detail routes support a differentiated choice |
| Full tables | The upstream's global IPv4 and/or IPv6 view | Path selection per destination prefix across upstreams | Greater hardware, filtering, operational and testing demands |
RFC 7454 describes both the simple case in which a customer receives only a default route and the delivery of full tables, including a full table combined with a default. It does not imply one universal recommendation: the agreed feed and import filters must match the actual purpose.
RFC 7454: default, full-table and filtering models
What a default route actually does
The IPv4 default route 0.0.0.0/0 and IPv6 default route ::/0 match any destination for which no more-specific route exists. RFC 4098 distinguishes a default route from a full default-free table. Normal longest-prefix-match forwarding still applies: an available more-specific route wins over the default.
RFC 4098: default route and full default-free table terminology
With one BGP default from each of two upstreams, local policy can set a preferred and a secondary exit. While both paths are available, however, all traffic without a more-specific route follows the same general decision. This can implement primary/backup cleanly, but it cannot by itself differentiate load or quality based on individual Internet destination prefixes.
A BGP default is not the same as a static default
When a BGP session closes, RFC 4271 removes the routes learned through it—including a dynamically learned default. An independently configured static default follows different conditions. In both cases, testing must show that the remaining next hop is not merely present in the router but that the intended service is actually reachable through it.
What a full table adds
With full tables, the router sees paths and BGP attributes offered by each upstream for many destination prefixes. Local import policy assigns preferences to these candidates and the BGP decision process then selects a path for the local routing table. This allows different outbound treatment per prefix or prefix group instead of one standard exit for almost everything.
RFC 4271: BGP updates, RIBs and decision process
Receiving a full table does not automatically control inbound traffic. Remote networks choose their path to your prefixes according to their own view and policy. Your announcements, their attributes and upstream capabilities matter for that direction. A large table also does not make a circuit faster or replace physical redundancy or DDoS protection.
Illustrative two-upstream example
The following scenario uses documentation values only: customer network AS64496 connects to upstream A (AS64497) and upstream B (AS64498). 203.0.113.0/24 represents an Internet destination solely for the example. It is neither a real route nor an AS51202 policy.
| Feed | General policy | Result for 203.0.113.0/24 |
|---|---|---|
| Two defaults | Prefer A; use B as backup | Like almost all destinations, the example follows the default through A |
| Selected route + default | A remains default; prefer the detail route through B | Only the supplied example prefix can be directed through B |
| Two full tables | Use A generally; prefer B for defined destination groups | The router can compare candidates from both upstreams and apply local policy |
This example shows outbound selection only. It says nothing about which upstream carries the return traffic. Stateful firewalls, NAT, DDoS mitigation and capacity planning must therefore account for asymmetric forward and return paths.
Decide separately for IPv4 and IPv6
Multiprotocol BGP identifies routing information by address family and subsequent address family. RFC 4760 therefore enables the exchange of IPv6 routes, among others. For every enabled address family, decide whether the service should provide a default, selected routes or full tables. A full IPv4 feed says nothing about IPv6 route delivery; prefix limits, filters and acceptance tests must also fit each family.
RFC 4760: Multiprotocol BGP and address families
Router capacity is more than a data-sheet number
- RIB and FIB: the router must process received candidates, the selected path and the forwarding entries actually programmed into the relevant tables.
- Multiple feeds: two upstreams provide multiple paths to the same destinations, so memory demand cannot be derived from the number of unique prefixes alone.
- Address families: IPv4 and IPv6 each consume capacity; additional services or tables may use the same hardware resources.
- Updates and convergence: the steady state is not enough. Restart, route refresh, large update bursts and failover must operate within acceptable limits.
- Prefix limits: a maximum-prefix limit protects against unexpectedly large feeds, but it needs growth headroom and must not take down the connection simply because the threshold was too tight.
- Observability: memory, CPU, FIB use, rejected updates, session state and prefix count should be visible before and after changes.
RFC 4098 notes that the composition of a full table varies by observation point and time. A fixed marketing claim such as ‘supports one million routes’ is therefore insufficient. Ask about the limits of the exact platform with its software release, enabled features, both address families and the planned number of concurrent feeds.
Filtering and failure behaviour belong to the feed design
- Accept only the agreed feed: a default-only connection should not silently import arbitrary detail routes.
- Handle non-global, over-specific or local prefixes according to the agreed policy and log unexpected announcements.
- Maintain import and export filters separately: permission to receive routes does not permit re-advertising third-party routes to an upstream.
- Set prefix limits and warning thresholds with documented headroom, and handle upstream changes through a planned process.
- Test RPKI validation and other security rules in the order used by local policy; a full feed is not a reason to install every route unchecked.
A five-step acceptance test
- 1Record which feed is expected from each neighbour for IPv4 and IPv6 and confirm that prefix counts remain within the agreed range.
- 2Inspect samples: default, selected destination prefixes, next hop, attributes and installed forwarding must match the policy.
- 3Test a controlled session failure for each upstream and observe which routes disappear, which replacement path is installed and whether applications remain reachable.
- 4Consider a reachable BGP neighbour with broken forwarding beyond it separately; an established session is not end-to-end evidence.
- 5Document the result, convergence, alerts and rollback, then repeat after material policy, software or hardware changes.
What to include in a transit enquiry
Provide your ASN, IPv4 and IPv6 prefixes, the number and type of upstreams, desired operating model, router platform and software release. For each address family, state separately whether you need a default, selected routes or a full table and which prefix limits you plan to use. An AS51202 enquiry should also include the site, port, commit, redundancy objective and DDoS requirements. This allows the route feed to be agreed precisely instead of treating a full table as a generic quality mark.