JNCIS-SP common mistakes
JNCIS-SP · Understand the traps and how to avoid them.
OSPF: Expecting an NSSA to carry Type 5 LSAs, or expecting a totally-stubby area to still receive Type 3 summaries for other areas. Candidates apply a single 'stub blocks externals' slogan to every non-backbone area type.
Area types are usually memorized as a list of names rather than as an LSA-permission table, so the distinctions between stub, totally-stubby, NSSA and totally-NSSA blur under exam pressure.
What to do instead
Build a table of LSA types 1-7 permitted in each area type and who originates the default: stub blocks Type 5 and the ABR injects a Type 3 default; totally-stubby also blocks Type 3/4 except the default; NSSA blocks Type 5 but allows Type 7 and the ABR originates a Type 7 default; totally-NSSA adds the Type 3/4 block on top. State the originator and the LSA type for each default, not just 'a default route appears'.
OSPF: Treating every 'adjacency will not come up' symptom as an area-ID or subnet-mask mismatch, instead of reading the neighbor state (Init, ExStart/Exchange, Loading, 2-Way) and narrowing the cause from it.
Area ID and mask are the first two things candidates learn to check, so they become the default answer for all adjacency failures.
What to do instead
Map state to cause: no state or Init means hellos are not being accepted (area ID, authentication type/key, hello/dead timers, ACL, MTU-independent); ExStart/Exchange stalls point at MTU mismatch or duplicate router IDs; Loading points at an LSA exchange problem; a stable 2-Way on a broadcast segment between non-DR/BDR routers is normal. Compare interface MTU and router IDs explicitly before touching area configuration.
IS-IS: Expecting a Level 1 router to compute an optimal end-to-end path into another area, and expecting interface bandwidth to influence the default IS-IS cost the way it does in OSPF.
Candidates carry OSPF mental models into IS-IS, assuming a per-area SPF that selects the best exit router and an automatic bandwidth-derived metric.
What to do instead
Remember that a Level 1 router installs a default route toward the nearest L1/L2 router (advertised via the ATT bit) and has no visibility of other areas; the L1/L2 router does the interarea selection. Costs are manually configured, the narrow metric defaults to 10 on every interface, and wide metrics are required for traffic engineering and large values - metric-style must be consistent across the domain.
BGP: Reciting the path-selection ladder from memory but misplacing steps - selecting by shortest AS path when local preference differs, comparing MED across paths learned from different neighbor ASes, or forgetting that a path with an unreachable next hop is eliminated before the ladder is applied at all.
The list is long and usually memorized as a flat sequence without the qualifiers (MED scope, next-hop validity, eBGP-before-iBGP placement) that the exam tests.
What to do instead
Write the ladder out in order with the qualifiers attached: weight, local preference, locally originated, AS path length, origin, MED (only among paths from the same neighboring AS unless always-compare-med is set), eBGP over iBGP, IGP metric to next hop, then tie-breakers. Treat next-hop reachability as a precondition, not a step.
BGP: Assuming a route reflector rewrites the next hop or prepends to the AS path, or assuming the cluster list is what stops a route being reflected back to the client that originated it.
The control-plane changes a reflector makes are taught loosely, and the two loop-prevention attributes are easily swapped.
What to do instead
Know precisely what a reflector does: it reflects the route to other clients and non-clients without changing the next hop or the AS path, adding an originator ID (the originating router's router ID) and prepending its own cluster ID to the cluster list. The originator ID prevents a route from returning to its originator; the cluster list prevents loops between clusters and between redundant reflectors.
MPLS: Describing the label stack in the wrong order or placing the VPN label pop at the wrong node - e.g. stating the VPN/service label is the outer label or that a P router removes the VPN label before forwarding to the PE.
The two labels are learned as separate chapters (LDP/RSVP-TE versus L3VPN) and their relative position in the stack is not rehearsed together.
What to do instead
Fix the model: the outer (top) label is the transport label distributed by LDP or RSVP-TE and is swapped at every transit hop; the inner (bottom) label is the VPN/service label that identifies the VRF and is pushed by the ingress PE and popped only by the egress PE. PHP/implicit-null applies to the transport label at the penultimate hop, never to the VPN label.
MPLS/L3VPN: Treating the route distinguisher and the route target as if they must match between PEs, or using an RD where an RT is required (or vice versa) in the VRF configuration.
Both are 8-byte or extended-community values attached to the same VPN route, so their distinct jobs are easy to collapse into one concept.
What to do instead
State the roles separately: the RD is prepended to the customer prefix solely to make it unique in BGP, it never controls import; the route target is an extended community that the exporting VRF attaches and the importing VRF matches on its import policy. RDs may differ on every PE, while RTs must be the values the two VRFs agree on.
Layer 2 switching: Configuring MSTP instances and assuming they interoperate with the neighbouring switch while the region name, revision, or VLAN-to-instance mapping differs, and then being surprised that the link behaves as a boundary port.
Revision number is the parameter candidates remember, so the other three region identifiers - especially the exact VLAN-to-instance mapping - are treated as optional.
What to do instead
Treat the region as a tuple (name, revision, VLAN-to-instance mapping) where all members must match exactly; a mismatch makes the port a boundary port running CIST instance 0, so per-instance load balancing silently disappears. Verify the region digest and the per-port instance state after any change.
Routing policy: Applying a policy in the wrong direction or scope - expecting an import policy on a BGP session to control what is advertised to that peer, or expecting a term with no explicit action to deny the route.
Import and export are described in the same chapter as 'policy', and the implicit default action of a term (fall through to the next term, then the chain default) is rarely stated out loud.
What to do instead
Anchor every policy question to a direction and a point in the chain: policy imported from a peer filters what you accept and install; policy exported to a peer filters what you advertise. Within a chain, a matching term with no terminating action continues evaluation, and an unmatched route falls to the chain's default action - so test with the policy-evaluation trace and confirm both the matched term and the final accept/reject.
High availability: Blurring graceful restart with non-stop routing - assuming GR preserves forwarding when the neighbour has no helper mode configured, or assuming NSR requires the peer to support anything at all.
Both features keep traffic flowing across a control-plane event, so candidates attribute the same requirements and mechanisms to each.
What to do instead
Separate the mechanisms: GR relies on the restarting router retaining its forwarding state while neighbours (in helper mode) advertise it as still reachable for the restart timer - if the neighbour does not support or is not configured for helper mode, GR gains nothing. NSR keeps the data plane and the routing protocol state alive on the restarting router itself through a synchronized backup engine and requires no neighbour cooperation. BFD is an independent fast-failure detector and must be configured and timed on both ends to be useful.