Inter-AS VPNv4: what the label forwarding contract requires

Reading a VPNv4 label on an AS border router tells you little until you know which inter-AS model the handoff implements. The label is not a property of the route on its own; it records an agreement about encapsulation and delivery between two routers. Identify the model before you read the display. Otherwise you are debugging a contract nobody has written down.

Which model the boundary implements

The VRF-to-VRF arrangement joins matching VRFs through routed attachments. Each side sees the other as a customer-edge neighbour and they exchange ordinary IPv4 routes, so nothing at that boundary needs MPLS.

A second arrangement swaps labeled VPNv4 routes between the border routers themselves. That only works with a coherent label-switched path across the interconnect and a route-target distribution plus trust model that both sides accept. If either piece is missing, the model is not in use, whatever the configuration implies.

The third distributes labeled PE reachability while the VPN routes travel between endpoints or route reflectors across ASes. Each of the three leaves different work at the boundary, and mixing the control plane of one with the interface assumptions of another is the classic failure. That mismatch usually surfaces as a label that looks right on one side and vanishes on the other.

Read one prefix end to end

Take a single authorised customer prefix and walk it. Look at what was advertised, what arrived, the next hop, the label and the import policy that admitted it. Then look at how the router resolves forwarding toward that next hop, because that is where a label turns into a packet. Skip either half and you are describing a control plane that may not be moving traffic. The two readings only mean something together.

The number is local. It means something in relation to the router that allocated it and the path that carries packets there, which is why the same value can appear twice and mean two different things. Compare it with what the receiving side says it received.

A label is local, and so is the promise

Capability is checked at both ends of the interconnect, not one. A command on your interface does nothing to the neighbouring provider interface, and a route that BGP accepted does not by itself commit the neighbour to forwarding a labelled packet.

RFC 4364 restricts labelled VPNv4 peering to trusted arrangements and warns against accepting labels that were never advertised to that peer. That is a security statement as much as a protocol one. Keep the public internet routing relationship away from the private VPN route exchange. If the interconnect is plain IP, do not expect any label to survive it. And where the link is labelled, confirm the outer transport label is swapped correctly at every hop.

A label that looks right on one side and vanishes on the other is usually that mismatch, not a routing bug.

What to write down at acceptance

Acceptance is a packet test, not a table review. Follow a customer packet into the remote VRF and follow its reply back, then write down which model the handoff implements. Add the handoff owners on both sides and whether the boundary carries plain IP or labelled traffic.

That note is what lets the next operator read the same label display correctly. Without it the model gets inferred from the configuration, and inferred assumptions are how the same mistake gets repeated. The RFC 4364 inter-AS section is where to settle which model was intended.