Cisco SPVI 300-515: Build VPN Services Without Losing Customer Isolation

A managed network provider migrates one enterprise customer between backbone routers. Both the old and new provider edges advertise the customer prefixes, yet a branch office suddenly reaches a different tenant's test network while its own payment application becomes unavailable. Engineers confirm that MPLS transport is working and conclude that the fault must be at the customer firewall. In fact, route-target policy in the service VPN has imported information into the wrong virtual routing table.

Cisco 300-515 SPVI, Implementing Cisco Service Provider VPN Services, examines how providers create and operate isolated services over common network infrastructure. Cisco describes the current concentration as covering Layer 2, Layer 3, and IPv6 VPN services; it also supports the CCNP Service Provider pathway alongside the 350-501 SPCOR core. This is not an exam primarily about home VPN software or a remote employee's encrypted tunnel. Its center of gravity is customer separation, provider-edge control planes, labeled transport, and service continuity. The relationship to SPRI advanced routing is technical, not a requirement to pass one concentration before the other.

Separate physical sharing from logical isolation

Service providers gain scale by transporting multiple customers through shared physical links, switches, and backbone routers. That sharing does not entitle one customer to reach another's routes. A Layer 3 VPN commonly uses a VRF on the provider edge to maintain a distinct set of routes for a customer or service. Interfaces, imported routes, and forwarding decisions are associated with the proper context rather than a global table that represents everyone.

The distinction is easy to miss when a troubleshooting command defaults to the global routing table. A provider-edge router may have excellent reachability to a customer destination in one VRF while the incoming packet belongs to another. For an incident, state the ingress interface and its VRF, verify the destination route in that same table, and inspect any explicit import or leak relationship. Fundamentally, virtual routing and forwarding allows independent routing tables to coexist on one provider edge; SPVI adds controlled imports, service labels, and customer contracts between those routing contexts.

Customer isolation is not encryption. MPLS VPNs can segregate forwarding contexts without necessarily providing end-to-end confidentiality against every threat in a transit network. If an application needs cryptographic protection, that is a separate requirement. Do not choose a Layer 3 VPN merely because a question says secure; determine whether the requested property is route separation, traffic encryption, path availability, or operational control.

Interpret route distinguishers and route targets correctly

A route distinguisher helps make otherwise identical customer prefixes unique within the relevant VPN routing information. Two companies may each use 10.0.0.0/24, and the provider must represent those destinations without confusing them. A route target serves a different purpose: it expresses which VPN routes should be imported or exported into a VRF under policy. Having distinct route distinguishers does not by itself prevent an accidental import across customers.

For the migration incident, inspect the exact route-target values on the old and new provider edges. Compare import and export settings against the approved service definition. A copied configuration might reuse a route target intended for a shared service, allowing routes from an unintended VPN into the customer's table. A service that is meant to share access to a common DNS resolver should use deliberately controlled import policy, not a general merge of tenant route sets.

Address conflicts complicate recovery. A temporary migration overlay can create two representations of the same prefix with different next-hop or label behavior. Determine whether the old path is being withdrawn as designed, whether the new edge advertises reachable next hops, and whether remote sites have converged. A correct fix changes the affected route-policy boundary rather than deleting a whole VRF to clear a symptom.

Follow a Layer 3 VPN route across the provider network

In a typical provider-edge model, the customer edge exchanges selected routes with its provider edge using an agreed routing arrangement. The provider edge places accepted routes into the customer VRF, advertises VPN reachability to appropriate remote provider edges, and uses MPLS transport across the backbone where applicable. Intermediate core routers need not learn each customer's private routes. This scaling separation is a primary architectural advantage.

Suppose a remote site sees the customer prefix but fails to forward traffic. Check whether the VPN route is present in the correct VRF, whether the associated next hop resolves, and whether the expected service and transport labels are usable. A BGP VPN route may be accepted by the control plane while a separate transport path fails. Conversely, the MPLS backbone may forward successfully while a VRF import policy has withheld the requested prefix.

End-to-end diagnostics should name all three layers: customer attachment, VPN route distribution, and provider transport. Then test the reverse direction. An MPLS L3VPN can suffer asymmetry when the two endpoints import different route sets or when a firewall on the customer edge allows only a narrower return flow. A successful one-way traceroute is not an adequate service acceptance test.

Layer 2 services solve a different application requirement

Some customers need Ethernet-like connectivity between locations rather than provider-routed Layer 3 reachability. Layer 2 VPN approaches such as pseudowires or virtual private LAN services can carry customer frames across a provider network, with important differences in how endpoints learn MAC addresses and how flooding and multihoming behave. The design must identify the service's actual Layer 2 scope and what happens when redundant paths are available.

Extending a broadcast domain widely can preserve legacy application assumptions, but it also increases the consequences of loops, excessive broadcasts, and poorly controlled MAC learning. The correct response is not always to emulate one giant LAN. If an application only needs routed connectivity and no shared Layer 2 semantics, a Layer 3 VPN may provide a cleaner failure boundary. Conversely, if a cluster or migration constraint genuinely requires Ethernet adjacency, an L2VPN design must address those operational risks explicitly.

When troubleshooting an L2VPN, separate control-plane signaling, pseudowire or service state, physical attachment, VLAN mapping, MTU, and learned forwarding entries. A tunnel up state can coexist with dropped frames caused by tagging or MTU mismatch. Look at the offered service and customer-facing evidence before changing a provider core route that is used by many other tenants.

IPv6 and multicast services require specific planning

Adding IPv6 is not equivalent to adding an address family label to a configuration file. Each endpoint needs compatible addressing, route distribution, and forwarding support, and the provider must ensure that IPv6 routes remain within the intended VPN context. Dual-stack customers can have working IPv4 and broken IPv6, or a policy that accidentally exports an IPv6 prefix more broadly than its IPv4 counterpart. Test both families independently.

A provider may also offer multicast VPN capability to carry one source stream to many receivers across customer sites. That service requires more than unicast reachability: group membership, source reachability, distribution-tree behavior, and relevant multicast control-plane functions must cooperate. Multicast data must remain scoped to the correct subscribers. A successful ping between two CEs cannot prove that a branch will receive an expected group stream.

A sound migration plan inventories address families and service types before the move. It also records which routes and groups should be learned at each site, how failover is expected to behave, and what observations define success. Avoid a change plan that checks only that the BGP session came up; operational acceptance is a verified tenant experience.

Service acceptance should distinguish user-visible connectivity from internal route state. For example, an enterprise may require its branch ERP system to reach a shared cloud service while forbidding any east-west branch communication through the provider. Test both expectations from the customer edge, then correlate results with the route targets and service labels that produced them. During failover, repeat the negative isolation test, because a backup provider edge can carry an older policy copy. A robust provider treats tenant separation as a continuously verified property of the service, not an assumption established only during initial provisioning.

Design shared services as explicit exceptions

Real providers sometimes expose shared DNS, authentication, internet egress, security inspection, or managed application endpoints to several customer VPNs. Route leaking or controlled shared-services VRFs can implement this, but the scope must be narrow and documented. The fact that two customers consume one service does not mean that their networks should share all routes or be able to initiate arbitrary sessions with one another.

Decide which prefixes a consumer needs, whether return routes exist, and how access controls identify the consumer. Record ownership for each import/export policy and audit changes as sensitive service modifications. This is where an apparently small edit can have a large blast radius: a broad export target may leak routes to many tenants before monitoring detects the issue.

A useful lab includes two customers with overlapping address space and a third shared-services VRF. Demonstrate that each customer can reach its own sites, that both can reach the approved common service, and that neither can route to the other's private test prefix. Then introduce an incorrect route target deliberately and document how the evidence reveals the error.

Prepare with a customer-service acceptance test

Build a modest provider-edge topology with an MPLS-capable transport domain and two virtual customer networks. Document which VRFs, route distinguishers, route targets, and service labels you expect to see. Establish Layer 3 VPN reachability, then test one negative case in which cross-tenant traffic must fail. Add an L2 service or IPv6 customer where supported by the training lab, and trace how the service differs from routed L3 delivery.

SPVI questions reward the ability to separate tenant policy from provider transport and identify which component is responsible for the symptom. The strongest preparation artifact is a table of expected versus observed route imports, labels, interfaces, and application reachability—not a collection of configuration fragments. When a multiple-choice answer would 'fix' one customer by broadly exposing another, it fails the service provider's most important promise: delivering connectivity without erasing isolation.