Does VPNv4 Need MPLS in the Core? Not Necessarily

Turning on the VPNv4 address family between two routers creates a route-distribution context and nothing more. It does not install a forwarding path, and it does not tell you which encapsulation will carry a customer packet to the remote endpoint. Once those two facts are separated, the question "does this need MPLS in the core" turns into a narrower and answerable one about the platform's supported data plane.

What the address family actually negotiates

Multiprotocol BGP carries the VPNv4 network layer reachability information under AFI 1 and SAFI 128, and each entry pairs a route distinguisher with a prefix and a label. The session negotiates that both speakers can encode and decode that information. What it does not negotiate is a data plane. Everything after this paragraph concerns forwarding, and none of it is settled by the session coming up.

So a successful session is evidence about control-plane capability, not about forwarding. A router can hold thousands of VPNv4 entries and still drop every customer packet, which is why the two failure classes get confused in the first place.

Note the label in the NLRI. It is a service label, bound to a prefix inside a VRF, and it has a forwarding role once the packet reaches the egress endpoint. Whether any transit device reads it is a separate design decision.

Receipt, import and forwarding are three steps

Receiving a route, being allowed to use it, and being able to forward with it are performed by different parts of the device. BGP stores what it hears; import policy and route-target matching decide which VRF may consider it; the forwarding plane then has to resolve the advertised next hop into something it can actually push onto a wire.

That middle step is where most surprising failures live. A route can be present in the BGP table, valid and even best, while the VRF route table stays empty because no route target matched the import list. Nothing logs a protocol error, because no protocol error occurred.

The last step is where platform support shows up. A next hop that is reachable in the underlay is not automatically resolvable as a VPN service transport, and the device may require a specific tunnel type, a specific label operation, or both. Reading the resolution status is more informative than reading the route count.

An IP core can carry a stack it never switches

The distinction worth keeping is between "the core does not run MPLS" and "no label exists anywhere in the service". Those are different claims, and only the first is a statement about transit devices. RFC 4023 defines carrying MPLS through IP or GRE tunnels, which is the mechanism that makes the second claim possible on an all-IP core.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Transit routers forward on the outer IP destination and need neither the customer prefixes nor native label switching. At the far end, the outer tunnel is removed and the service label resumes its job. The core moved an opaque payload, which is exactly what an IP network is good at.

What this design does not give you is a universal guarantee. It is not proof that every router resolves every VPNv4 next hop over any GRE interface, and it is not a reason to delete a working native MPLS configuration. It is a counterexample to the universal claim, and the practical question stays local to the platform. Record that question as a platform limitation rather than a protocol rule.

Walk the chain on the box until it breaks

Start from the received route and stop at the first step that fails, because the later steps cannot be diagnosed while an earlier one is broken. Four commands cover most of it on a typical implementation.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Read them as a sequence rather than as four independent checks. The first confirms the family is active and the peer is exchanging routes; the second shows whether the prefix arrived with a usable next hop; the third proves import eligibility; the fourth shows whether the forwarding plane bound a label or tunnel to it.

Then test the workload path in both directions, with an MTU that survives encapsulation. GRE adds header bytes, and a path that passes small probes can fail on full-size packets in one direction only, which looks like an application fault rather than a transport one.

Two operational notes close the loop. GRE is encapsulation, not confidentiality, so an untrusted transit network needs a supported security arrangement on top rather than an assumption. And record which encapsulation the platform actually supports before the design review, since that single answer decides whether an IP-only core is a valid choice or a plan that cannot forward.