A municipal fiber consortium explains how one provider MPLS core can carry separated tables for multiple civic customers. What capability is MPLS enabling at that describe level?

A municipal fiber consortium describing one provider MPLS core carrying separated tables for multiple civic customers is describing multi-tenant separation over a shared labeled core. MPLS forwards traffic in per-customer contexts, using VRFs on provider-edge routers, VPN labels, and MP-BGP, so each agency does not need a unique physical network. Provider core routers switch transport labels without merging customer routing tables; this is the describe-level capability of MPLS L3VPN multi-tenancy. Requiring IPsec for every labeled packet while sharing one global routing table is incorrect: MPLS does not mandate IPsec, and a global table contradicts customer separation. Replacing provider-edge routers with customer routers and running LDP directly between sites over the public Internet is not how managed MPLS VPN service works; customer-edge routers do not create the provider LSP this way. Automatic OSPF-to-EIGRP conversion when customers share a provider core router is also incorrect: no such protocol mutation occurs, and customer IGPs remain isolated in provider-edge VRFs. Exam caveat: separation is logical through VRFs, RDs, RTs, and VPN labels, not encryption; overlapping RFC1918 addresses are normal. Do not confuse MPLS multi-tenancy with DMVPN overlays or CoPP as an isolation mechanism. Practical check: verify that provider-edge routers hold distinct VRFs with overlapping prefixes, VPNv4 routes have distinct RDs, provider core routers lack those VRF tables, and one agency’s customer-edge router cannot resolve another’s routes without intentional route leaking.