Juniper JN0-364: Service Provider Routing, MPLS and Resilience

A service provider network can carry traffic for thousands of customer sites while exposing only a small number of operational symptoms when something goes wrong. A failed interior gateway adjacency, an inaccessible label-switched path, or a changed BGP export policy may each appear to a customer as a general connectivity problem. Engineers need to separate transport, routing, label forwarding, and service reachability to diagnose the real failure rather than treating the whole provider network as one forwarding domain.

JN0-364 is the current JNCIS-SP exam in Juniper's Service Provider Routing and Switching track. Juniper introduced this version in February 2026 after JN0-363 ended on February 1. The official specialist syllabus lists 65 multiple-choice questions in 90 minutes, requires JNCIA-Junos, and references Junos OS 25.2. Its central subject is not merely how to configure a protocol; it is how OSPF, IS-IS, BGP, MPLS, IPv6, tunneling, and high-availability mechanisms combine in a provider transport environment. The prior JNCIA-Junos provides the platform foundation, but this track requires additional protocol-specific judgment.

Interpret protocol-independent routing and routing instances

A routing table is a collection of candidate routes rather than a list of promises that all destinations are reachable. A static route may have an unresolved next hop; a generated or aggregate route may depend on contributing entries; or a policy may prevent a route from entering the expected instance. Junos also distinguishes routing information from the forwarding table, where usable next-hop choices are installed for packet transport. Understanding that boundary prevents a common mistake: seeing a prefix in some output and assuming data-plane delivery must succeed.

Service provider devices often carry multiple service contexts, including routing instances, which means that route placement and leakage are design decisions. An engineer must know why a route is kept separate, how selective import/export works, and what happens when one instance has no path to a shared service. The wrong next-hop route in a provider's default table can be just as disruptive as a missing route in a customer virtual routing environment. In lab practice, inspect each relevant table and note the exact source and status of the route before inserting additional static statements.

Route policy is particularly important for controlled aggregation and traffic engineering. Summarization may reduce advertisement volume but can conceal an unreachable component if a summary remains present after the useful more-specific paths disappear. A filter-based forwarding decision can change which route table is consulted without changing the original destination. These ideas are easier to test when a lab deliberately introduces a rejected prefix and records why it is inactive or omitted. The broader contrast between routing protocol selection becomes concrete when an operator follows one route from origination to forwarding.

Diagnose OSPF and IS-IS rather than treating both as generic IGPs

OSPF maintains a link-state view, but adjacency establishment depends on interface conditions and compatible protocol parameters. Router IDs, area types, timers, network types, authentication, and multiaccess election behavior affect whether routers share link-state information. A neighbor stuck before full adjacency may be the immediate symptom; a route missing from the table may result from a later distribution or selection issue. These should be investigated separately. Understanding OSPF adjacency troubleshooting gives useful conceptual grounding, while Junos-specific evidence must guide actual commands.

IS-IS organizes adjacencies around Level 1 and Level 2 operation, with LSPs and TLVs distributing topology information. Its designated intermediate system role on a broadcast segment is not a direct copy of OSPF's DR behavior. Level boundaries, overload conditions, metric style, and route leaking can influence where reachability is carried. A provider operator who knows only the OSPF analogy risks overlooking IS-IS-specific mechanisms when a route stops propagating across an area boundary.

The objective in either protocol is predictable reconvergence. During a failure, operators want a stable graph and viable backup paths rather than oscillating adjacencies. A lab can intentionally disable a core link, monitor topology updates and route reinstallation, and compare traffic behavior with and without BFD. However, faster failure detection is not an automatic improvement if links are unstable or the device is undersized. Timing decisions must match measured network characteristics. The correct question is how the entire control-plane and forwarding process reacts to loss, not whether a single detection timer can be set lower.

Understand BGP reachability, route attributes, and next-hop resolution

BGP connects routing domains and handles policies that determine which prefixes are advertised or accepted. A stable session is necessary but not sufficient for usable reachability. The next hop for an advertised route must resolve; import policy must accept the information; and the resulting candidate must win the route-selection process or otherwise be eligible for forwarding. Operators must distinguish the BGP RIB, the active route table, and the actual forwarding entries rather than collapsing these layers into a binary neighbor-up check.

The practical value of BGP attributes becomes evident when two upstream paths exist. Local preference can favor one exit within an autonomous system; AS-path length may influence selection under certain conditions; communities and export policies can change downstream treatment. None of these features should be described as one universal order of preference without regard to vendor implementation and configured policy. A clear treatment of BGP attributes helps explain why traffic may shift even when the physical network is unchanged.

Provider operators should verify both the control-plane decision and downstream impact before modifying a policy. A route-map or Junos routing-policy error can withdraw routes far beyond the device where it was committed. Change validation includes reviewing expected matches, comparing accepted and advertised prefixes, confirming next-hop resolution, and checking sampled paths from representative customer locations. In a lab, creating an intentionally overbroad filter and then correcting it illustrates why policy must be tested with more than one prefix and more than one neighbor.

MPLS transport, label distribution, and traffic paths

Multiprotocol Label Switching adds an important forwarding abstraction. The ingress router can impose one or more labels; transit routers swap labels according to their forwarding state; and the egress may remove labels before IP forwarding continues. The label operations do not eliminate the need for a functioning transport topology. A label-switched path depends on the routing information used to reach its endpoint and the signaling or segment-routing mechanisms that establish label behavior.

The JN0-364 material includes RSVP-signaled and LDP-signaled paths, MPLS forwarding tables, and segment routing with MPLS. These are related but distinct mechanisms. RSVP-TE is associated with explicitly signaled paths and traffic-engineering constraints; LDP uses label distribution aligned with routed reachability; segment routing encodes a path through segment identifiers and associated instructions. The choice affects scaling, traffic-engineering controls, and operational visibility. A concise treatment of MPLS forwarding is useful only as background; Junos-specific path states remain the authoritative operational evidence.

A diagnostic workflow separates the underlay route to the label-switched path endpoint, label distribution or programming, forwarding behavior, and service-specific labels where applicable. If traffic drops when a link fails, identify whether the route changed, the LSP was withdrawn, the alternate path was not eligible, or the payload exceeded MTU after encapsulation. The same symptom can arise at different layers. Blindly reestablishing the label protocol may temporarily restore service without identifying a persistent transport fault.

IPv6, GRE tunnels, and edge-to-core continuity

Dual-stack service provider networks require IPv6 as a routed service, not simply as an additional address family. A device can carry IPv4 reachability while lacking the corresponding IPv6 next-hop path. OSPFv3, IS-IS and BGP can participate in IPv6 routing, while static routes and policy govern particular deployments. Operators must recognize how control-plane address families, route tables, neighbor reachability, and forwarding entries interact. IPv4 and IPv6 networking supplies context for addressing differences, but it does not replace lab testing of Junos protocols.

GRE tunnels can provide a logical connection across another routed network, yet encapsulation adds overhead and diagnostic complexity. The underlay must reach the tunnel endpoint; MTU and path-MTU behavior must permit the encapsulated packets; and the overlay needs its own coherent routing design. A tunnel endpoint may reply to a ping while the payload path still fails because a filter or transport route treats encapsulated traffic differently. Capture or trace evidence should distinguish the outer packet from the inner service traffic.

Care is needed when introducing IPv6 over IPv4 tunnels. They can facilitate a transition or specialized transport connection, but they also create an operational dependency on an IPv4 path. Engineers should document that dependency and avoid assuming that the overlay offers redundancy when both primary and alternate tunnels share the same underlying links. Scenario-based study is more effective when a candidate predicts failure effects before inspecting device output.

High availability and progression beyond the specialist level

Provider resilience is not a single switch. Link aggregation handles member failure; VRRP can maintain a first-hop gateway; BFD can detect forwarding-path loss; and GRES, NSR, NSB, or graceful restart address particular control-plane and forwarding continuity concerns. Each mechanism solves a different problem and can have prerequisites or platform limitations. An engineer should be able to say exactly which state is preserved and which faults remain outside the feature's protection.

A meaningful test has several phases: establish the baseline, trigger a controlled link or Routing Engine failure, observe protocol convergence and customer traffic, then verify stable operation after restoration. Compare the failure event against actual service impact rather than declaring success because the control plane eventually returned. The principle behind network high availability is that resilient designs specify the failure they intend to tolerate and prove that the alternative path is independent.

The specialist track supports progression to JNCIP-SP, where advanced routing policy, multicast, Layer 2/Layer 3 VPNs and scaling become central. For JN0-364, prioritize the ability to explain what each route, label, adjacency or tunnel state proves, then rehearse how failures propagate between those layers. Use Juniper's current objective list and software guidance immediately before scheduling; archived JN0-363 practice material should never be treated as the final authority for this exam revision.