JNCIE-SP common mistakes
JNCIE-SP · Understand the traps and how to avoid them.
Configuring an RSVP-TE LSP with an explicit path and bandwidth reservation but never verifying that the LSP is actually up and carrying traffic, then assuming the traffic-engineering tunnel is protecting or steering traffic when it is not.
Candidates treat LSP configuration as complete once committed. In lab conditions the path may be down because the explicit-path hops are not reachable via the IGP, the CSPF metric constraints exclude links, or the bandwidth reservation fails, and 'show mpls lsp' output is not checked. Because the ingress route for the destination still resolves over IGP, traffic silently follows IP forwarding instead of the tunnel.
What to do instead
After every LSP commit, run 'show mpls lsp extensive' and confirm State is Up and the path is the intended explicit path. Check 'show rsvp session' for the session state and 'show rsvp interface' for bandwidth availability. Verify CSPF constraints with 'show mpls lsp detail' and confirm that the IGP is advertising the links in the explicit path. Also verify that traffic actually uses the LSP by checking 'show route detail' for the tunnel next-hop, and use 'show mpls lsp statistics' to confirm packet counts increment.
Building an L3VPN with MP-BGP but omitting the route-target export/import policy, or configuring the same target on both export and import without checking the direction, then reporting that the VPN 'does not work' when routes are present in the VRF table but not advertised into MP-BGP.
Route targets are the control plane's way of deciding which VRFs receive which routes. Candidates often configure the VRF table and the BGP family inet-vpn peering but forget that the VRF must be associated with a route-target policy, or they attach the wrong policy direction. The result is that the local VRF routes are never exported into inet-vpn, so remote PEs never see them.
What to do instead
For each VRF, explicitly configure 'vrf-target export target:x:y' and 'vrf-target import target:x:y' (or use vrf-target with a policy). Verify with 'show route table .inet.0' that local routes exist, then 'show route table bgp.l3vpn.0' that they were exported, and 'show route table .inet.0 detail' on the remote PE that they were imported. Use 'show bgp neighbor ' to confirm the inet-vpn family is negotiated and 'show route advertising-protocol bgp ' on the PE to confirm the export.
Configuring iBGP route reflection but leaving the cluster ID and originator ID handling at defaults without understanding the loop-prevention implications, or building a full mesh instead of reflection and then failing to scale when the topology grows.
Candidates learn route reflection as a concept but do not practice verifying the cluster ID and originator ID attributes. They also often default to full-mesh iBGP because it is simpler to reason about, then hit the scalability wall the exam is designed to test. When reflection is used, the cluster ID must be unique per cluster and the originator ID must be preserved so that the route reflector does not re-advertise a route back to its originator.
What to do instead
Configure 'cluster ' on the route reflector and confirm with 'show route detail' that the originator ID and cluster list are present and correct. Ensure the cluster ID is unique across clusters and that clients are configured with 'peer-as' matching the reflector's AS. Verify that the reflector does not send a route back to its originator by checking 'show route detail' on the originating client. For scaling, plan a hierarchical reflection design and document the cluster IDs before committing.
Deploying EVPN-MPLS multihoming without verifying the designated forwarder election and the Ethernet segment route, then assuming that a dual-homed CE is protected when one PE fails, only to find traffic black-holed.
EVPN multihoming depends on the Ethernet segment route being advertised and the DF election converging. Candidates configure the ESI and the LAG but do not verify that the ES route is present in EVPN, that the DF election has completed, or that the aliasing and backup paths are installed. If the ESI is misconfigured or the ES route is not advertised, the remote PE does not know about the multihoming and does not install a backup path.
What to do instead
On each PE, verify 'show evpn ethernet-segment' shows the ESI with the correct DF state and that 'show evpn instance' shows the ES route. Confirm 'show route table bgp.evpn.0' contains the Ethernet segment route (type 4) and the inclusive multicast route (type 3). Test failover by disabling one PE's link and confirming that traffic continues via the backup path. Ensure the ESI is identical on both PEs and that the LACP system ID is consistent.
Configuring PIM-SM but forgetting to enable PIM on the RPF interface toward the rendezvous point, or misconfiguring the RP address, then troubleshooting multicast as if it were a unicast routing problem.
PIM-SM requires a consistent RP configuration and PIM enabled on all interfaces in the multicast path, including the RPF interface toward the RP and the source. Candidates often enable PIM only on the customer-facing interface and forget the core interface, or they configure the RP on some routers but not others. The result is that (*,G) joins fail or the SPT switchover never happens.
What to do instead
Verify 'show pim rps' shows the same RP on all routers and 'show pim interfaces' shows PIM enabled on every interface in the path. Check 'show pim join' for both (*,G) and (S,G) state and confirm the RPF interface with 'show multicast rpf '. Use 'show pim statistics' to confirm that joins and registers are being processed. For SSM, confirm that the group range is within the SSM range and that IGMPv3 is enabled on the receiver-facing interface.
Enabling BFD for a BGP or OSPF session without tuning the timers to match the platform's capabilities, causing the session to flap under normal CPU load, and then blaming the routing protocol rather than the BFD configuration.
BFD timers that are too aggressive (for example, minimum-interval 50 ms with a multiplier of 3) can exceed what the line card or CPU can sustain during convergence or a control-plane event. Candidates copy aggressive timers from documentation without checking the platform's minimum supported values or the peer's capability. The result is false positives where BFD tears down a healthy session.
What to do instead
Check the peer's BFD capability with 'show bfd session detail' and confirm the negotiated transmit and receive intervals. Start with conservative timers (for example, 300 ms interval, multiplier 3) and tighten only after verifying platform support with 'show bfd session extensive'. Monitor 'show bfd session' for flap counts and correlate with control-plane CPU. If flapping persists, increase the multiplier or interval and verify that the routing protocol's hold timers are consistent with the BFD timers.
Configuring a firewall filter or CoS policy on the loopback or core interface without accounting for the implicit deny or the order of terms, then locking out management access or dropping control-plane traffic.
Junos firewall filters are evaluated top-down and end with an implicit discard if no term matches. Candidates write a filter to protect the RE, test it in a lab, and then apply it in a way that also matches management or routing protocol traffic. Similarly, CoS classifiers applied to the wrong interface can reclassify control traffic into a low-priority queue. Because the filter is applied to the loopback, the candidate loses the very access needed to fix it.
What to do instead
Always include an explicit 'then accept' term for management and routing protocol traffic (SSH, SNMP, BGP, OSPF, BFD) at the top of the filter, and test with 'test policy' or by applying the filter to a non-critical interface first. Use 'commit confirmed' so that a lockout automatically rolls back. Verify with 'show firewall filter ' counters that expected traffic is accepted. For CoS, apply classifiers only to customer-facing interfaces and verify with 'show class-of-service interface' that the correct classifier is attached.
Performing a software upgrade without checking the dual-RE or unified-issue compatibility, or without verifying that the new image supports the current configuration, and then discovering that the commit fails or the RE does not come back.
Candidates treat 'request system software add' as a single step and do not validate the upgrade path, the partition requirements, or the configuration compatibility. On dual-RE platforms, the backup RE may not be upgraded or may not be synchronized, and the candidate assumes that ISSU will handle it. The result is a partially upgraded chassis or a commit failure after reboot.
What to do instead
Before upgrading, run 'show version' and 'show chassis routing-engine' to confirm the RE model and current release, and check the release notes for the supported upgrade path. Use 'request system software add no-validate' only after verifying the package checksum. On dual-RE systems, upgrade the backup RE first, verify with 'show version' after it reboots, then upgrade the master and confirm synchronization with 'show chassis redundancy'. Always take a configuration backup with 'show configuration | display set' before upgrading.
Building a VRF route leak or hub-and-spoke L3VPN by redistributing routes between VRFs without controlling the route targets, causing unintended any-to-any reachability or routing loops.
Route leaking between VRFs is done by importing and exporting route targets, and candidates often add a leak by redistributing connected or static routes into BGP without checking which VRFs import those targets. In a hub-and-spoke design, the spoke VRFs must import only the hub's target, not each other's. If the targets overlap, spokes learn each other's routes directly and the hub's policy is bypassed.
What to do instead
Document the route-target plan: each VRF exports a unique target and imports only the targets it should receive. For hub-and-spoke, configure the hub VRF to export a hub target that all spokes import, and configure spokes to export a spoke target that only the hub imports. Verify with 'show route table .inet.0' on each spoke that only hub routes and local routes are present. Use 'show route table bgp.l3vpn.0 detail' to confirm the target communities on each route.
Troubleshooting a BGP session that is stuck in Active or Connect by checking only the BGP configuration, without verifying IGP reachability to the peer's update source, the TCP port 179 reachability, or the multihop TTL.
BGP relies on TCP and on IGP reachability to the peer address. Candidates often configure the neighbor address but forget that the update-source loopback must be reachable via the IGP, or they forget 'multihop' for eBGP peers that are not directly connected. The session stays in Active because the TCP SYN never reaches the peer or the return path is missing.
What to do instead
Verify IGP reachability to the peer's update source with 'show route ' and confirm the source address used by 'show bgp neighbor ' matches the configured update-source. For eBGP over multiple hops, configure 'multihop ttl ' and verify with 'show bgp neighbor ' that the TTL is sufficient. Check that port 179 is not blocked by a firewall filter with 'show firewall'. Use 'show bgp neighbor ' to see the last state and error, and 'monitor traffic interface ' to confirm TCP SYN/ACK exchange.