F5 Route Domains and MPLS VRFs: Map the Tenant Handoff

Two tenants both run an application at 10.50.0.10. The provider keeps them apart in separate MPLS VPNs, and the BIG-IP keeps their local traffic in separate route domains. That arrangement works right up to the handoff, where a missing suffix or a copied route-target quietly puts one tenant's packet into the other tenant's context. This runbook maps the two models together and ends with a per-tenant test.

Worksheet: one row per tenant

Fill this in before you change anything. Every later step refers to a cell in it, and a blank cell is a decision nobody has made yet.

Step 1: pin each object to its route domain

F5's route-domain documentation describes isolated traffic contexts, duplicate addresses and the address%ID notation for configuration objects. An address written as 10.50.0.10%2 names the local route-domain context, and that suffix is not an MPLS label carried in the customer's IP packet.

A VLAN or a supported tunnel belongs to one route domain in the documented model, so the interface and the address have to agree. Also inspect the administrative partition's default route domain, because an omitted suffix does not mean no context; it means whichever context the partition defaults to. That single default explains most of the incidents where a new object quietly answered in the wrong tenant. Check it before you add a self address.

tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vs

Step 2: use the provider's VRF and route targets

At the MPLS edge, the tenant is identified by the provider's VRF and the agreed customer routing service. Route targets control which routes the provider imports and exports between VRFs, and choosing a similar-looking BIG-IP route-domain number creates none of that relationship.

The two identifiers live in different systems and mean different things. A route-domain ID is a local context on the appliance. A route target is a provider-side policy attribute that decides route distribution, and a route distinguisher is a third thing again, used to keep otherwise identical prefixes distinct.

Step 3: decide whether contexts may share reachability

Review parent-domain lookup and strict-isolation settings deliberately, because they change what a context can reach. The F5 guide permits controlled forwarding through those relationships, and that is exactly why a route domain should not be treated as a complete tenant-security policy on its own.

If both tenants need a shared service, specify the approved path and permissions instead of casually pointing one tenant at the other's routing context. Preserve application identity and any intentional source translation along with the network destination, or the shared service will see one tenant as the other.

An ordinary routed handoff connects BIG-IP to a provider edge router without making BIG-IP an MPLS PE. If direct MPLS or VPN route-family integration is genuinely required, get explicit support for the exact platform and release, because local route-domain isolation does not establish that capability.

Step 4: verify one tenant at a time

Test tenant A from an endpoint in A's context to A's application address, then repeat for B. Use the %ID form in diagnostics so you can prove which context answered, and confirm that a request from the wrong context fails rather than landing somewhere plausible.

Check the provider side in the same pass: the prefix is present in the right VRF, the route targets match the worksheet, and the return path uses the intended attachment. A ping that works from the appliance itself proves the appliance's context, not the tenant's.

Record the final mapping in the worksheet, including the default route domain of each partition and any parent-domain relationship you enabled. The next change to this environment will be made by someone reading that table, not by someone reading this article.