Nokia VPRN common mistakes
Nokia VPRN · Understand the traps and how to avoid them.
When configuring a VPRN, the candidate assigns the service ID and customer ID but forgets to enable the service with 'no shutdown' under the service context, then spends exam time debugging why the SAP is down and routes are not installed.
VPRN services on SR OS are administratively down by default. Candidates coming from platforms where creating a service implies it is active skip the explicit shutdown state, and the symptom (SAP operational state down) mimics a port or encapsulation problem.
What to do instead
Build a fixed configuration skeleton in memory: create service vprn customer , configure route distinguisher and route target, add interfaces/SAPs, then always issue 'no shutdown' at the service level and verify with 'show service service-using vprn' and 'show service id base' before moving on.
The candidate confuses the VPRN's route distinguisher with its route target, or sets a route target that does not match the far-end PE, and then cannot explain why the VPN-IPv4 route exists locally but is not imported remotely.
Both are BGP extended community attributes on the same route, and in a single-PE lab they are often configured identically, so the distinction between 'makes the route unique in the global table' (RD) and 'controls import/export policy between VRFs' (RT)' is never forced. Under exam pressure the candidate swaps them.
What to do instead
Memorize the one-line distinction: RD = uniqueness/identity, RT = membership/import-export. Practise reading 'show router bgp routes vpn-ipv4' output and pointing at which field is the RD and which is the extended community, and check both ends with 'show service id bgp' plus the VRF's vrf-import/vrf-export policies.
On an SR OS router, the candidate mixes up the base router interface configuration with the VPRN interface configuration and applies OSPF or IS-IS to the wrong context, so the underlay adjacency never forms or the VPRN leaks routes into the global table.
SR OS uses a single CLI tree with explicit context switching ('configure router' versus 'configure service vprn '), and interface names, loopbacks, and protocol stanzas look nearly identical in both. Candidates who practise only in one context pattern-match to the wrong prompt.
What to do instead
Before each routing task, state the context out loud: which router instance am I in, and should this adjacency be in the base or the VRF? Verify with 'show router interface' versus 'show router interface' and 'show router ospf neighbor' versus the VPRN equivalent; never configure an IGP inside a VPRN unless the scenario explicitly asks for a CE-facing routing protocol.
The candidate treats a VPRN as a flat L2 extension and configures a VPLS-style SAP with a null or dot1q encapsulation on a port that is already carrying a VPRN IP interface, causing encapsulation mismatch and a down SAP.
VPRN SAPs are IP-facing and require the port to be in network or hybrid mode with the correct encapsulation (null, dot1q, qinq) and matching VLAN tags. Candidates who learned switching first default to switchport thinking and miss the port mode and the 'no shutdown' on the SAP.
What to do instead
Check the port with 'show port detail' for mode (network/access/hybrid) and configure encapsulation explicitly on the SAP. Remember that a VPRN IP interface can be a loopback or a SAP; if it is a SAP, the port mode and tag must match end to end. Verify with 'show service id sap' and confirm the operational flags.
When asked to design an aggregation layer for VPRN services, the candidate proposes a full mesh of BGP sessions between all PEs instead of a route-reflector hierarchy, or omits the RR cluster design entirely.
Lab exercises often use two or three PEs, so a full mesh works and the candidate never internalizes scaling constraints. The exam scenario adds many PEs and the candidate reuses the small-lab topology without recognizing the iBGP full-mesh requirement is O(n^2).
What to do instead
Default to a two-level design: PEs peer only with route reflectors, RRs are redundant and placed in the aggregation/core, and cluster IDs are unique per RR pair. Be ready to justify why VPN-IPv4 routes need an RR that preserves the next-hop and extended communities. Verify with 'show router bgp summary' showing session counts per peer.
The candidate enables LAG or MC-LAG for aggregation but forgets to make the LACP configuration symmetric (different system priority, lacp-xmit-interval, or port thresholds on each side), then cannot explain why the LAG stays down or flaps.
LAG parameters must match on both ends, and in a multi-chassis design the candidate must also configure the peer link, the multi-chassis peer, and the sync/keepalive. Candidates configure only one side because the diagram shows only one side's CLI.
What to do instead
Treat LAG as a two-ended object: verify 'show lag detail' on both ends for system ID, admin key, and port state, and for MC-LAG verify 'show redundancy multi-chassis peer' and the sync state. Practise the full MC-LAG sequence: peer config, peer link, sync, then the LAG with lacp-key and port-threshold.
The candidate uses the Network Services Platform (NSP) as a pure GUI and cannot describe how a service is modeled, so when asked to automate VPRN provisioning they propose CLI scripting rather than the model-driven workflow.
NSP exposes intent-based service models and templates; candidates who have only clicked through the UI miss that the underlying objects are service definitions instantiated via the NSP API or workflow engine. They answer with expect scripts, which is the wrong abstraction layer.
What to do instead
Learn the NSP layering: service intent (service definition/template) -> instantiation against discovered network -> device configuration via MDM. Be able to state that NSP discovers devices, builds a topology model, and pushes configuration through the model, and that automation should target the service intent API rather than device CLI. Name the workflow steps in order when asked.
When asked to validate an automated VPRN deployment, the candidate checks only that the configuration was pushed and declares success, without verifying service state, route presence, or end-to-end reachability.
Automation tools report 'config committed' and candidates equate commit with working service. In SR OS, a committed VPRN can still be administratively down, have a down SAP, or lack the VPN-IPv4 route, so post-change validation is a distinct step the candidate skips.
What to do instead
Adopt a three-tier validation checklist: configuration present (show service id base), operational state up (SAP and service oper flags), and data plane correct (VPN route in BGP table, VRF route table populated, ping/traceroute from CE to CE). Automate these as post-checks and describe them explicitly in any automation answer.
The candidate secures the VPRN only at the CE edge and leaves the PE-CE protocol unauthenticated, or applies a single global filter instead of per-VRF and per-interface filters, then cannot explain where filtering actually happens in the SR OS pipeline.
SR OS has distinct filter attachment points (SAP ingress/egress, network ingress/egress, VRF-level) and candidates assume one filter covers all. They also forget that MD5 authentication on BGP and OSPF is a per-session setting inside the VRF context, not global.
What to do instead
Map each security requirement to a specific attachment point: SAP filters for CE-facing traffic, network filters for core-facing, VRF import/export policies for route leaking control, and MD5/TCP-AO for protocol sessions. Verify with 'show filter ip' and 'show router bgp neighbor detail' to confirm authentication is active.
The candidate designs a data center gateway VPRN with a single PE-facing interface and no redundancy, or terminates all DC VRFs on one gateway, so the design has no path redundancy and no clear failure domain.
DC gateway scenarios emphasize multi-homing and EVPN/VXLAN integration, but candidates reduce them to a simple VPRN with one uplink because that is what they practised. They also miss that the gateway must be dual-homed to the DC leaf/spine layer.
What to do instead
For any DC gateway answer, state the redundancy model explicitly: dual gateway PEs, MC-LAG or EVPN multihoming toward the DC, and per-tenant VRF separation with defined RT policies. Describe the failure domain: what happens if one gateway PE or one uplink fails, and which protocol reconverges. Draw the traffic path in words before writing the config.