JNCIP-SP common mistakes
JNCIP-SP · Understand the traps and how to avoid them.
Configuring an LDP signaled LSP end-to-end and then expecting RSVP-TE style bandwidth reservation and explicit-path control to work on the same tunnel, instead of choosing the signaling protocol based on the requirement.
Candidates memorize that both LDP and RSVP build label-switched paths and treat them as interchangeable transport options. LDP distributes labels along the IGP shortest path with no resource reservation or path constraint, while RSVP-TE carries the SESSION and SENDER_TSPEC objects that enforce bandwidth and explicit hops. The confusion surfaces when a question asks which protocol satisfies a traffic-engineering requirement.
What to do instead
Build a decision table before the exam: LDP for plain loopback-to-loopback transport driven by IGP reachability; RSVP-TE when you need bandwidth reservation, admin groups (affinity), explicit paths, or fast reroute with facility backup. Practice reading an RSVP-TE LSP configuration and identifying exactly which statement (bandwidth, priority, affinity, explicit-path) is doing the engineering work.
Treating a BGP route reflector as a full transit router, i.e. expecting the RR to change the next hop or to be in the forwarding path, and mis-predicting which routes a client will install.
The rule that an RR reflects routes without modifying next hop, AS path, or MED is easy to state but hard to apply. Candidates forget that the client resolves the next hop through the IGP, that the RR must be reachable via an IGP for the session, and that cluster-id and originator-id loop prevention change which paths appear. Questions about route distribution inside a cluster then get answered as if the RR were a normal eBGP hop.
What to do instead
Rehearse the RR rules explicitly: reflect only best routes (unless additional-path is configured), preserve next hop, add ORIGINATOR_ID and CLUSTER_LIST, and do not reflect back to the client that sent the route or to clients in the same cluster unless the client is a route reflector. Trace a single prefix from an originator through the RR to two clients and write down the exact attributes at each hop.
Assuming an MPLS LSP is up and usable just because the IGP adjacency and the LDP session are established, without checking label binding, transport address reachability, or PHP behavior at the egress.
Candidates conflate IGP convergence with LSP availability. LDP needs a reachable transport address (usually the loopback) and matching label bindings; an LSP can be broken while the IGP is fully converged. Similarly, implicit-null and explicit-null behavior at the penultimate hop changes what the egress receives, which affects QoS and EXP handling.
What to do instead
Learn a fixed verification order: IGP adjacency and loopback reachability, then LDP session state and label bindings (show mpls ldp bindings), then the in-label/out-label chain (show mpls lsp / show route table inet.3), then the push/swap/pop operation at each hop. Memorize that penultimate-hop popping advertises implicit-null (label 3) and that explicit-null (label 0) is used when the egress must receive the packet with a label intact.
Configuring an interface-based or family-based IS-IS/OSPF adjacency and then wondering why the loopback prefix or the MPLS transport address is not advertised, because the loopback was never added to the routing instance or the correct address family.
In service provider designs the loopback is the router-id, the LDP transport address, and the BGP next hop all at once. Candidates focus on the physical link configuration and forget that the loopback must be included in the IGP instance (and for IS-IS, that the correct topology/level carries it), so downstream features silently fail.
What to do instead
Adopt a checklist for every IGP task: interface in the correct routing instance, correct address family enabled, loopback passive and advertised, and the IGP router-id set to the loopback. Verify with the IGP database and the routing table that the peer loopback is reachable as an internal prefix before moving on to LDP or BGP.
Building an inter-AS or carrier-supporting-carrier VPN option and mixing up which option uses which signaling: treating Option A, B, and C as variations of the same configuration rather than distinct models with different next-hop and label behavior.
The three inter-AS options differ in where VRFs live, whether ASBRs hold VPN routes, and whether end-to-end LSPs are stitched. Candidates memorize the letters but not the mechanics: Option A uses per-VRF back-to-back VRFs, Option B exchanges VPNv4 across ASBRs with next-hop-self, Option C uses multi-hop VPNv4 between route reflectors plus a labeled-unicast inter-AS LSP. Questions that ask which option scales or which requires an inter-AS LSP expose the gap.
What to do instead
Write one paragraph per option covering: where the VRF sits, what address family crosses the ASBR, whether next hop is rewritten, and whether a contiguous LSP is required. Then practice mapping requirements (scalability, ASBR memory, end-to-end QoS, number of VRFs) onto the correct option. Remember Option C requires labeled-unicast (BGP-LU) between ASBRs and multi-hop VPNv4 between RRs.
Assuming a VRF automatically isolates traffic and provides forwarding, without confirming route targets, route distinguishers, and the import/export policy match on both ends of the VPN.
Candidates configure a VRF, attach an interface, and expect connectivity. In reality the RD only makes the prefix unique, and the route target controls import/export into VRFs. A mismatch in RT, or a missing export policy on the PE-CE protocol, leaves the remote VRF with no routes even though the MP-BGP session is up.
What to do instead
For every VPN task, verify in order: VRF defined and interface bound, RD unique per VRF, RT export on the originating PE, RT import on the receiving PE, MP-BGP VPNv4 (or VPNv6) session established, and the route present in the target VRF table (not just the global table). Practice reading a VPNv4 route and naming the RD, RT, and next hop separately.
Mixing up the BGP path-selection order, particularly local-preference versus AS-path length, and where weight and origin fit, then choosing the wrong best path on a multi-homed or confederation topology.
The decision process has many steps and candidates recall fragments. The classic error is placing AS-path length before local-preference, or forgetting that weight is Cisco-proprietary and local to the router, or that MED is only compared between paths from the same neighboring AS by default. Confederation and route-reflector scenarios add more steps.
What to do instead
Memorize a compact ordered list: weight, local-preference, locally originated, AS-path length, origin, MED, eBGP over iBGP, lowest IGP metric to next hop, oldest route, lowest router-id, lowest neighbor address. Then practice with two or three candidate paths and justify each elimination step out loud, including where MED comparison is suppressed across different neighboring ASes.
Configuring QoS classification and marking on the CE-facing interface but not translating those markings into the MPLS EXP bits, so the provider core drops or reclassifies traffic unexpectedly.
Candidates treat DiffServ as a single-layer concept. In an MPLS network the EXP (or traffic-class) bits in the label stack carry the treatment, and the mapping from IP DSCP to EXP at ingress and back at egress must be explicit. Without a rewrite rule or a classifier that sets EXP, the core sees default treatment regardless of the customer marking.
What to do instead
Trace a packet through the full path: classification at ingress PE, DSCP-to-EXP mapping (or a fixed EXP per VPN), per-hop behavior in the core based on EXP, and EXP-to-DSCP or queuing treatment at egress. Practice writing the rewrite/classifier statements and verify with a show command that the EXP bits on the imposed label match the intended forwarding class.
Designing a multicast VPN and confusing the provider tunnel (P-tunnel) with the customer multicast tree, or selecting PIM-SM in the core when the design calls for point-to-multipoint LSP or mLDP-based trees.
MVPN introduces two layers: customer multicast signaled by PIM between PEs, and a provider tunnel that carries it. Candidates conflate the two, forget that the default MDT uses PIM in the core, and do not distinguish inclusive versus selective provider tunnels. Questions about which tunnel type scales or which needs a certain signaling protocol then go wrong.
What to do instead
Draw the two layers separately: customer PIM adjacencies (PE-CE), then the provider tunnel (PIM-SM default MDT, PIM-SSM, mLDP, or RSVP-TE P2MP). Note which MVPN profile/version you are using and what it implies for data MDT and selective tunnels. Verify with the MVPN and PIM state on the PE and the tunnel state in the core.
Ignoring control-plane protection and convergence: configuring BFD or fast reroute as an afterthought, or assuming IGP timers alone give sub-second convergence, without verifying that the failure is detected and the backup path is pre-installed.
Candidates focus on steady-state configuration and treat convergence as automatic. In practice sub-second convergence needs BFD or link-layer detection, pre-computed loop-free alternates or a TI-LFA/RSVP backup, and a verified repair path. Without these, the failure is detected only after IGP hello/hold timers expire.
What to do instead
For each design, state the detection mechanism (BFD interval and multiplier, or physical/link event), the repair mechanism (LFA, remote LFA, TI-LFA, or RSVP facility backup), and the expected convergence budget. Verify that the backup path is installed before the failure (show the backup route or the FRR LSP) and that the primary path returns after recovery. Practice reading BFD session state and timer values.