Juniper Networks JN0-664: Current JNCIP-SP Routing

Juniper Networks JN0-664 is the current written exam for the JNCIP-SP certification. It replaced Juniper Networks JN0-663 in December 2022. Juniper lists the current exam at 90 minutes with 65 multiple-choice questions and Junos OS 22.3 as the referenced software version. The ExamSnap Juniper Networks JN0-664 page is the live preparation destination.

The professional service-provider track expects candidates to connect routing protocols with MPLS and customer services. Core areas include advanced OSPF and IS-IS, BGP, class of service, MPLS, traffic engineering, Layer 2 VPNs, Layer 3 VPNs, EVPN, and operational troubleshooting. Success depends on understanding which control plane creates each piece of forwarding state.

A practical study plan should therefore be topology-driven. Build a provider core, add BGP and label distribution, attach multiple customer VPNs, then introduce faults that affect only one layer at a time. The ability to explain why a route, label, or service entry exists is more important than simply reproducing a known configuration.

Build the transport before the service

Every provider service depends on transport reachability, so begin with the IGP and loopback design. OSPF or IS-IS should provide stable infrastructure routes before BGP or VPN signaling is introduced. The ExamSnap OSPF fundamentals article is helpful for revisiting adjacency, topology, cost, and route-selection logic in a clean context.

Once the underlay is stable, verify how transport labels are distributed and resolved. Candidates should know which control-plane relationships must be healthy before a provider-edge router can forward a labeled packet across the core. This prevents a service-layer symptom from being misdiagnosed as a VPN-specific issue.

Use failure experiments early. Break one underlay adjacency, remove one route, or disturb a label path and observe which higher-level services fail. This makes dependency relationships visible and teaches the candidate to start troubleshooting at the lowest broken prerequisite.

A transport baseline should include latency and path observations in addition to route presence. When the network has multiple equal-cost or protected paths, candidates should know which path traffic actually uses and what changes after a failure. That makes later service symptoms easier to interpret.

BGP policy controls reachability at scale

BGP is central to Juniper Networks JN0-664 because provider networks use it for internet routing and multiple service address families. The ExamSnap BGP fundamentals article provides a concise review of peering, attributes, path selection, and policy before the professional service-provider extensions are added.

Candidates should be comfortable with route reflectors, policy chains, communities, and the distinction between learned, accepted, active, exported, and received routes. A healthy session tells only one part of the story. Professional troubleshooting requires locating the exact stage where the expected route stopped progressing.

Build a policy lab in which connectivity still works but the selected path violates the intended design. That “works but wrong” condition is more realistic than a completely failed session and forces the candidate to inspect attributes, preference, and export behavior rather than stopping as soon as a ping succeeds.

BGP policy labs should test communities and route filtering together. Tag routes at one point, act on those tags elsewhere, and verify both the control-plane result and the final forwarding choice. This shows how providers scale policy intent without writing unique rules for every prefix.

MPLS becomes clear when you follow the label stack

MPLS study should always include packet movement. The ExamSnap MPLS and BGP article is useful for connecting labels with the routing context that produces them. For each hop, explain which label is present, why that label was chosen, and which table drives the swap, push, or pop operation.

When VPN services are added, distinguish the transport label from the service label. The outer label gets the packet across the provider core, while the inner context identifies the customer service at the destination provider edge. Understanding that separation makes many Layer 3 VPN failures much easier to classify.

Traffic engineering adds explicit path intent and additional state. Candidates do not need to memorize the network as a static picture; they need to understand how constraints, signaling, and failure handling change the forwarding path when the preferred route is unavailable or no longer meets policy.

MPLS study benefits from separating control-plane labels from packet-capture evidence. First predict the labels from routing and signaling state, then inspect what the packet actually carries. Agreement between those two views is a strong sign that the candidate understands how the control plane programs forwarding.

Layer 3 VPNs combine several control planes

A Layer 3 VPN requires VRFs, unique route representation, import and export policy, MP-BGP signaling, and labeled forwarding. The most important distinction is between route distinguishers and route targets. One creates uniqueness for overlapping prefixes, while the other controls policy relationships between VPN routing tables.

A productive lab uses two customers with overlapping address ranges. Confirm isolation, verify that only the intended routes enter each VRF, and then introduce an incorrect route target. Trace the resulting control-plane state before touching forwarding configuration. This demonstrates how a small policy error can create a very specific service failure.

Professional candidates should also reason about next-hop resolution and label availability. A VPN route may be present in BGP but still unusable because the transport path to the remote provider edge is incomplete. That is why service troubleshooting should always include the underlay and MPLS prerequisites.

For Layer 3 VPNs, test partial success. One site may learn remote routes while another fails because of a route-target or next-hop issue. Comparing the working and failing sites often isolates the configuration difference faster than examining the broken site alone.

Layer 2 VPNs and EVPN need service-specific reasoning

Layer 2 VPN technologies move Ethernet service semantics across the provider network, while EVPN uses BGP to distribute endpoint and service information. Candidates should know what the control plane learns, how multihoming changes redundancy, and which state must exist on each provider edge for forwarding to work.

Rather than memorizing separate feature lists, compare the services by the information they exchange and the forwarding problem they solve. Ask whether MAC learning is local or control-plane assisted, how broadcast or unknown traffic is handled, and how a dual-homed site behaves when one path fails.

EVPN becomes much easier when the underlay and BGP foundation are already stable. Verify transport reachability first, then service signaling, then local attachment state. This layered order keeps troubleshooting focused and prevents the overlay from absorbing blame for a basic routing problem.

Layer 2 VPN and EVPN labs should include multihoming because redundancy changes both signaling and forwarding expectations. The candidate should be able to explain which device forwards, how duplicate traffic is avoided, and what state changes when one attachment disappears.

Class of service protects the provider objective

Provider class of service should be studied from an SLA or traffic requirement backward. Identify which classes matter, how packets are classified, where congestion can occur, and what scheduling or drop behavior preserves the intended service. The configuration is the implementation of that model, not the starting point.

Test class of service under actual contention. Without congestion, many queueing errors are invisible. Generate competing flows, verify counters and queue behavior, then change one policy element and observe whether the measured result reflects the intended priority, shaping, or loss behavior.

Professional questions often include enough distracting information to reward candidates who can identify the relevant decision point. A packet may already carry the correct markings while the real problem is the scheduler or egress bandwidth. Follow the packet through the entire treatment chain before choosing a fix.

Class-of-service designs should be checked at multiple interfaces. A packet may receive correct treatment at ingress and still encounter an unexpected bottleneck later in the provider path. End-to-end verification prevents local counters from being mistaken for proof of service-level performance.

Troubleshoot from dependency to symptom

The ExamSnap network troubleshooting framework fits service-provider work because each layer depends on the one below it. Start with interface and transport reachability, then protocol state, then labels, then service tables, and finally customer forwarding. Skipping directly to the visible service often wastes time.

Use one command or observation for one question. If the question is whether a VPN route was imported, inspect the relevant routing table and policy evidence; if the question is whether the transport label exists, inspect MPLS state instead. Precision matters more than running a large familiar command set.

A final Juniper Networks JN0-664 lab should combine BGP, MPLS, one VPN service, and a controlled failure. Write the expected state at each layer before creating the fault, then prove where the real state first differs. That exercise captures the professional reasoning the certification is designed to validate.

A professional incident summary should identify the affected service, dependency that failed, corrective change, and evidence of restoration. Practicing that concise explanation reinforces the distinction between observing symptoms and proving root cause across a multi-layer provider architecture.

Traffic engineering connects policy with transport

Provider traffic engineering is useful when ordinary shortest-path routing does not express the business requirement. Candidates should be able to state the desired constraint, identify the mechanism that enforces it, and predict how the network reacts when the preferred resource is unavailable.

Create a topology with two plausible core paths and impose a reason to favor one. Observe the signaling and forwarding state, then remove a link and verify whether the fallback behavior matches the design. This transforms traffic engineering from a feature list into a measurable path-control problem.

When an answer choice proposes a path change, ask which control plane will create that change and whether the required state is actually present. That question often distinguishes a valid professional solution from a command that looks related but operates at the wrong layer.

Review failures by dependency order: physical path, underlay, labels, BGP, VPN state, and customer forwarding. Repeating that sequence until it becomes automatic helps prevent expensive detours into a higher layer whose prerequisites are already broken.

Final practice should be service oriented

Instead of studying protocols in isolated chapters, finish with customer-service scenarios. One exercise might combine BGP policy, MPLS transport, a Layer 3 VPN, and class of service; another might combine EVPN multihoming with a core failure and route reflection.

For each exercise, list the expected state at the underlay, BGP, label, service, and forwarding layers. Then change one condition and identify the first layer whose state becomes wrong. This creates a repeatable troubleshooting method that scales beyond any single exam question.

Juniper Networks JN0-664 candidates should be able to explain not only how a provider service is configured, but why it works, what it depends on, and how they would prove the service has recovered after a fault. That operational confidence is the real goal of professional preparation.

Include at least one exercise where two faults exist at once. Resolve the lower-layer transport problem first, then observe which service symptom remains. Multi-fault drills teach candidates not to stop at the first successful change and reinforce the need to revalidate every dependency after restoration.

Before the exam, revisit the diagrams rather than only the commands. If the candidate can draw how routes, labels, VPN state, and customer traffic move across the provider network from memory, the configuration details have a framework to attach to and unfamiliar questions become easier to reason through.