L3VPN handoff: private routes, a default, or a full feed?

Your circuit is up, the VRF is configured, and the provider asks a short question that decides the rest of the design: what should the customer edge receive? Three answers are common, and none of them follows from the fact that a label stack exists. They are service decisions about where traffic leaves the branch.

Walking the handoff in order is the cheapest way to get this right. You start from what happens to traffic that matches nothing, then write down the private prefixes and their failure behaviour, and only then talk about how large a feed you are willing to carry.

Begin with the traffic nobody planned for

Ask one question before any prefix list appears: when a packet matches no private route, where should it go? A branch with its own internet circuit usually keeps a local default, so ordinary web traffic leaves through the local firewall and never touches the provider. In that design the VPN carries only the remote private sites, and the more specific prefixes do the selecting.

A branch that is meant to use a central exit is the opposite case. There the default points into the service, and the provider or central site owns forwarding, return routing and any translation. Saying "default to the VPN" without that owner in place produces a branch that resolves names and reaches nothing.

The two designs differ in what a routing failure looks like, which is why guessing is expensive. With a local default, a lost private route sends that traffic to the internet, where it is dropped by the firewall or, worse, answered by something you did not intend. With a central default, the same loss removes internet access entirely and the ticket arrives as "the whole branch is down". Neither failure is wrong by itself, but only one of them matches the service you sold, and a BGP configuration alone will not tell you which one you built.

Write the private prefixes down with their failure case

List the prefixes the branch must reach and note which of them are summarized. An aggregate that is one bit too broad pulls unknown destinations into the VPN, which is fine only if the far side actually owns and forwards them.

Then describe the intended behaviour when the private service fails. A retained discard route keeps traffic off an unauthorized path and produces a clean, expected outage. A floating default can preserve availability by shifting to a backup path, but only if the backup path is authorized to carry that traffic.

Keep availability and permitted fallback as two separate requirements in the handoff document. Teams that merge them end up arguing about whether the branch should have failed, instead of checking whether the agreed policy was implemented.

Check what the CE really installed

Configuration intent and forwarding state diverge often enough that verification belongs in the handoff, not in the incident review. On an IOS-XE customer edge the three commands below answer three different questions: what was offered, what was accepted, and what is actually being used.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Run all three on the day of the handoff rather than a month later, while someone still remembers what was agreed. The first output depends on soft-reconfiguration inbound or a stored route refresh; without either, the CE cannot show you what it rejected. The second shows accepted and best paths after policy. The third tells you where the default really goes, which is the single most useful line in the whole handoff.

Run the same checks on a second CE if the site is dual-homed. Asymmetric acceptance between two edges is a common cause of "it works from one server and not the other", and it is invisible in a configuration diff that looks symmetric.

Qualify a larger feed instead of assuming one

Sometimes the customer genuinely needs internet path information inside the VRF, for policy routing or for a central exit that steers by prefix. That is a requirement to state, scope and price, not a hidden default. It comes with memory for the RIB and FIB, CPU for updates, filter maintenance and an owner for the resulting table.

Capacity arguments go wrong in both directions. A full table is not forbidden inside a VRF, and it is not free either. Equally, you cannot infer today's cost from an old route count, and a smaller label allocation does not remove the cost of storing routes.

The BGP/MPLS IP VPN specification discusses several internet-access arrangements next to the VPN service itself, and it does not declare a full table or a default mandatory for every customer, which is the section worth pointing at when a claim about "standard practice" appears: RFC 4364.

Close the handoff by recording the advertised set, the received set and the selected set next to the agreed exit policy, and by testing one private destination, one intended public destination and one route-loss case. A signed record of those three tests settles more arguments than any statement about what most networks do.