4A0-106 Nokia VPRN: Layer 3 VPN Routing, MP-BGP, and SRA Troubleshooting

Nokia 4A0-106, Virtual Private Routed Networks, is a current Service Routing Architect exam covering MPLS-based Layer 3 VPN services. Nokia’s associated course describes VPRN design, configuration, monitoring, proactive troubleshooting, Inter-AS models A, B, and C, and carrier-supporting-carrier concepts. The exam therefore combines routing logic with service-provider VPN architecture.

VPRN becomes manageable when candidates separate customer routing from provider VPN distribution. A customer prefix is learned at a PE, placed into the correct virtual routing context, represented with VPN information for distribution across the provider network, and then installed at the remote PE for delivery toward another site. Each transformation has a purpose and a potential failure point.

In the Nokia program, 4A0-106 sits in the current SRA written requirements beside architect-level BGP, VPLS, QoS, and EVPN. Candidates should therefore expect the VPRN service to depend on routing policy and provider transport rather than operate as a self-contained feature.

A VPRN is a separate routing context, not simply a tunnel

Each VPN needs its own customer-facing routing information so overlapping customer prefixes can coexist without conflict. Candidates should understand the purpose of virtual routing and forwarding separation at the provider edge. The MPLS core transports traffic, but the VRF-like service context determines which customer routing table is consulted and where a received packet belongs.

This distinction is useful during troubleshooting. A label-switched path can be healthy while a route is missing from one VPRN. Conversely, the customer route may exist locally while provider reachability prevents it from being distributed or used remotely. Always identify whether the symptom is local service state, VPN route distribution, or transport forwarding.

Route distinguishers and route targets solve different problems

Layer 3 VPN control planes need a way to make overlapping customer prefixes unique and a way to decide which VPN should import a route. Route distinguishers and route targets serve those different functions. Candidates who reduce both to “VPN identifiers” often make mistakes when analyzing why a route is present in the provider control plane but absent from a specific VPRN.

Practice with two customers that use the same IPv4 prefix. Show how the provider can carry both routes without collision, then change import/export policy so one route appears in the wrong or right VPN. The exercise makes the distinction operational and supports later MP-BGP troubleshooting.

MP-BGP distributes VPN reachability across provider edges

VPRN relies on multiprotocol BGP to exchange VPN route information between provider edges. The fundamentals from 4A0-102 BGP still apply: sessions, attributes, policy, next-hop reachability, and route selection all matter. The added VPN address family carries information that ordinary IPv4 unicast routing alone cannot represent.

When a remote customer route is missing, confirm that the PE learned the customer prefix, exported it with the intended VPN attributes, advertised it to the relevant BGP peer or route reflector, and that the remote PE imported it into the correct service. This sequence prevents random changes to PE-CE routing when the fault actually exists in provider VPN distribution.

PE-CE routing should be chosen and troubleshot independently from core VPN signaling

Customer sites can connect to the provider using static routing or dynamic protocols depending on the design. Candidates should understand how the PE learns customer reachability and how the customer learns remote destinations. The chosen PE-CE protocol affects convergence, policy, and operational complexity but does not replace the provider’s VPN control plane.

Use fault scenarios in which one site advertises an incorrect prefix, a redistribution policy is missing, or the PE-CE neighbor fails while MP-BGP remains healthy. The exercise reinforces the boundary between customer-edge routing and provider-edge VPN distribution, a distinction that is critical in real support cases.

MPLS transport must deliver the packet to the correct remote PE

After the control plane selects a VPN route, the data plane still needs transport reachability. Label stacks can identify both the provider path and the VPN service context. This is where MPLS knowledge becomes essential: a correct MP-BGP route cannot carry traffic through a broken LSP.

Troubleshoot forwarding in layers. Confirm the customer packet enters the intended VPRN, verify the selected VPN route and next hop, inspect the transport path toward the remote PE, and then check egress service forwarding. Correlating these states is much faster than assuming “BGP is up” proves the service path is working.

Inter-AS VPRN changes the trust and control boundaries of the design

Nokia’s course includes Inter-AS models A, B, and C, which allow Layer 3 VPN services to span autonomous-system boundaries in different ways. Candidates should understand the architectural tradeoff rather than memorizing labels. Ask where VPN routes are exchanged, how much customer-specific state the AS boundary routers hold, and how end-to-end reachability is maintained.

Draw each model with explicit control-plane and data-plane boundaries. Then identify which operator must coordinate route targets, labels, or per-VPN interfaces. The differences become clearer when framed as operational responsibility and scalability rather than as three isolated diagrams.

Carrier supporting carrier extends the same separation principles another level

Carrier-supporting-carrier designs allow one service provider to use another provider’s infrastructure to connect parts of its own network. The concept can feel abstract until candidates identify whose customer routes, provider routes, and labels are being carried at each layer. Keep each administrative domain and service context clearly labeled in diagrams.

The purpose of studying the model is to understand layered service-provider routing, not to memorize a rare configuration. It reinforces the exam’s main skill: determining which routing system owns a prefix and which transport system is responsible for moving the packet between the devices that own that route.

Current SRA requirements integrate VPRN with Layer 2, QoS, and EVPN services

As of October 2026, SRA includes 4A0-105 VPLS, 4A0-106 VPRN, 4A0-107 QoS, 4A0-102 BGP, and 4A0-115 EVPN Services, plus the practical lab. The 4A0-C02 SRA Composite can replace the first four individual exams but not the need to understand their combined technologies.

Integrated study is important because a routed VPN can be reachable yet unusable due to poor QoS, an unstable transport, or incorrect edge policy. Architect preparation should evaluate service quality, scale, and failure behavior instead of treating route presence as the only success condition.

Final practice should trace one prefix and one packet end to end

Choose a customer prefix at site A and narrate its entire lifecycle: how the PE learns it, how it becomes a VPN route, how it is exported, distributed, imported at the remote PE, installed in the destination VPRN, and advertised toward site B. Then trace a packet back along the resulting data path.

Repeat with one deliberate fault at a time. Remove an import target, break the PE-CE adjacency, or interrupt the transport LSP and predict which control-plane or forwarding evidence disappears. This is a powerful exam method because it converts a complex VPRN into a sequence of verifiable state transitions.

4A0-106 is best approached as a route-lifecycle exam. If candidates can explain how customer reachability becomes a VPN route and then a forwarding decision at another site, most configuration and troubleshooting questions become much more systematic.

The exam remains current in Nokia’s SRA path. Use the current Nokia requirements and course objectives when preparing, and practice enough end-to-end scenarios that MP-BGP, MPLS transport, and PE-CE routing remain distinct even when they appear in the same fault.

Route leaking between VPN contexts should be treated as an intentional policy decision, never as a default convenience. If shared services require selected reachability, define which prefixes may cross the boundary and why. Broad import policies can defeat the isolation that the VPN design is meant to provide. Candidate exercises should include both a permitted shared route and a route that must remain isolated.

Overlapping address space is a useful stress test for understanding. Build two VPRNs that both use the same customer prefix and verify that each retains separate forwarding. Then inspect the provider control-plane representation that keeps those routes distinguishable. If the candidate cannot explain why both can coexist, route distinguisher and service-context knowledge needs more work.

Control-plane scale should be considered alongside correctness. Large VPN environments can contain many customer prefixes and policy relationships. Route reflectors, summarization where appropriate, import/export design, and operational visibility influence how manageable the network remains. A design that works for two lab sites may become difficult to operate at hundreds of sites if every exception requires unique policy.

Data-plane verification should test both directions because asymmetric customer or provider policy can produce one-way connectivity. Confirm the return route in the remote VPRN, the transport path back to the original PE, and the PE-CE advertisement toward the source site. Successful forward traffic does not prove the reverse control plane is complete.

Use service-impact language in troubleshooting notes. Instead of writing only “route target missing,” record which sites and prefixes become unreachable and whether other VPRNs are unaffected. That habit connects protocol evidence to customer impact and helps prioritize incidents. It also proves the candidate understands what the configuration element is protecting.

Customer route policy should be documented independently from the provider VPN policy. A PE may correctly import a remote VPN route yet advertise an undesired prefix to the CE, or it may learn a customer route that should never be exported into the VPN. Separate inbound PE-CE policy, VPN export/import policy, and outbound PE-CE policy in study diagrams so each decision has a clear owner.

For migration scenarios, compare old and new paths before moving traffic. If a site changes PE, access circuit, or routing protocol, confirm that both control planes will not advertise conflicting information during the transition. A staged plan with explicit preference and rollback behavior reduces the chance of transient loops or black holes and gives VPRN concepts a realistic operational context.