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

The Juniper JN0-364 examination tests the Service Provider Routing and Switching Specialist knowledge represented by JNCIS-SP. It is designed for networking professionals moving beyond basic Junos administration into traffic transport across provider infrastructure. The official Juniper certification program identifies JNCIA-Junos as its prerequisite, a 90-minute multiple-choice examination with 65 questions and software objectives referencing Junos OS 25.2. HPE Juniper Networking introduced this exam in February 2026 to replace JN0-363. The specialist's subject matter is distinct from a typical enterprise campus network: protocol-independent routing, MPLS, label-switched paths, tunnels, IPv6 transport and high availability are central because the network often carries many customers' services across shared infrastructure.

Consider a provider connecting corporate customers across several cities. Each customer expects its traffic to reach the correct endpoint, survive reasonable faults and remain isolated where necessary. The provider must make forwarding decisions through its own network without forcing customers to understand each interior router. A prefix that appears reachable by ordinary IP routing might still fail to traverse the expected transport path if a label-switched path is missing or an intermediate route is unresolved. JN0-364 encourages engineers to reason about multiple layers of reachability and to understand how label distribution, routing protocols, tunnels and protection mechanisms interact. A strong candidate can describe not only what a command means, but why the chosen transport architecture exists.

Separate IP route knowledge from label forwarding

A service provider's IP control plane may use static, aggregate, generated and dynamic routes. These route types inform ordinary next-hop decisions, but MPLS adds labeled forwarding through paths known as label-switched paths. The label information base and related forwarding information are not simply copies of a conventional IP route table. They capture additional transport state. A packet entering a label-switched path can be forwarded using labels through the provider domain, and different services can use that transport in different ways. Understanding the relationship between IP reachability and label state is essential before troubleshooting a network whose outer and inner forwarding decisions differ.

Label distribution mechanisms introduce their own control conditions. LDP distributes label bindings associated with reachable destinations, while RSVP signaling can establish paths with particular traffic-engineering characteristics. Segment routing with MPLS uses different assumptions to steer packets through segments. These technologies should not be mixed in an explanation simply because each places labels on packets. A candidate should know what information establishes the path, how state is represented and which failure would indicate a control-plane problem rather than a physical link issue. A labeled packet that reaches an unexpected egress may require inspection of signaling, policy and forwarding behavior together.

The underlying routing design still matters. If an interior protocol cannot provide reachability to a next hop, labels alone may not create the intended working path. An aggregate route may advertise a broad destination even when a component prefix has failed. A routing policy may prevent the information needed by a transport mechanism from being distributed. Troubleshooting should therefore establish what route is known, which next hop is active and how the label-switched path is resolved. This layered method reduces the temptation to make a sweeping MPLS configuration change based on one missing customer flow.

A practical lab could begin with an ordinary routed three-node topology and then introduce a single supported label-switched path. Observe how traffic reaches the same destination before and after labeled forwarding, using appropriate diagnostic output to identify the state. Then remove one permitted component under controlled conditions and see whether the path reconverges or fails as expected. This experiment teaches the difference between a protocol session existing and the actual availability of a complete transport service.

Handle IPv6 and tunnels with explicit path assumptions

IPv6 is not simply IPv4 with longer addresses. Prefixes, neighbor discovery, routing protocol families and configuration details create operational differences, especially in provider networks supporting dual-stack customers. The JN0-364 objectives include static routing and dynamic IPv6 operation through OSPFv3, IS-IS and BGP, as well as IPv6 carried across IPv4 mechanisms where relevant. An engineer must identify which address family is being advertised and resolved. An established BGP session for one family does not by itself guarantee that every other address family is exchanging valid routes.

Tunnels provide a way to carry traffic across networks that may not directly understand or expose the inner traffic's form. Generic Routing Encapsulation can be useful in specified interconnection designs, but it adds overhead, encapsulation choices and troubleshooting questions. An observer may see an outer packet reach its tunnel endpoint while the encapsulated inner packet is dropped or misrouted. The correct diagnostic model records the source and destination of both layers, the relevant routing context and any firewall or MTU effects. A simple connectivity test aimed at the outer endpoint proves only a small part of the service.

MTU planning can become significant once labels or tunnel headers are added. A path that supports an ordinary packet may fail when additional encapsulation increases its size, especially if fragmentation or path-MTU discovery is not operating as expected. An operator should avoid automatically treating intermittent application failures as a transport-protocol defect when packet size and filtering could be involved. Test with representative traffic and maintain a diagram of the encapsulation path. This kind of operational reasoning is more durable than memorizing a list of default parameters without understanding their consequences.

The need to distinguish address families, routing instances and tunnel contexts becomes more important as customers share infrastructure. Two tenants may use overlapping private addresses that are meaningful only within their own service contexts. A provider must preserve the intended separation while maintaining control and visibility. The specialist syllabus introduces transport concepts; deeper VPN design belongs to professional-level work. Even so, a specialist should learn to ask whose route table, whose labels and whose traffic a particular observation describes.

Protect continuity when protocols or links fail

Service-provider high availability needs multiple levels of planning. Link aggregation can provide alternate physical capacity, while routing protocol behavior and rapid failure detection influence how quickly traffic moves after a disruption. The official JNCIS-SP objectives include graceful restart, Graceful Routing Engine Switchover, nonstop bridging and nonstop active routing, Bidirectional Forwarding Detection and VRRP. These features are not synonymous. Some preserve protocol or forwarding state during control-plane events, others detect connectivity loss or provide alternate first-hop behavior. Applying each feature appropriately depends on the failure being addressed.

A backbone link failure can affect many labeled paths and customer services. The right investigation records interface events, protocol neighbor changes, path signaling state, alternate-route selection and customer-facing symptoms. Time sequence matters. A label-switched path may be eventually rebuilt but still cause an outage long enough to violate a service commitment. A route may converge promptly while one tunnel or customer context remains broken. Measuring only whether a device returned to an “up” state does not establish that all required services recovered. Operators should know how to correlate events at different layers without confusing them.

Protocol independence does not mean operational independence. When several services depend on the same physical ring or underlay, a single shared failure can defeat several apparently separate redundant mechanisms. A sensible network design describes failure domains and tests one fault at a time before trying complex combined scenarios. BFD may shorten reaction time to certain failures, but it cannot make an alternate path appear if the topology offers none. A useful high-availability test begins with the business interruption tolerance, then verifies whether the network's behavior meets it.

Change management is particularly important because provider configuration changes can affect services whose details the engineer may not directly see. Candidate configurations, review and rollback procedures help limit risk, but an automated policy adjustment can still alter a large route set at once. Test configurations against representative customer routing contexts and label paths; identify potential route leaks; and monitor both control-plane status and forwarding. Documentation should connect each intended change to the exact outcome it is expected to produce.

Move from specialist transport to advanced VPN services

The professional-level JNCIP-SP JN0-664 exam extends the track toward more advanced routing and Layer 2 VPN services, including EVPN and VPLS. That progression is natural only after an engineer understands the routing and labeled transport beneath those services. JN0-364 is not a generic preparation module for every data center or enterprise specialization; its distinguishing concern is provider transport and the operational visibility required when many customer services traverse one backbone. A candidate should choose labs and practice questions that reflect that context.

Useful revision scenarios include a missing label binding, an IPv6 route present only in the wrong address family, a GRE path whose outer endpoint works but whose inner payload fails, and a BFD event that causes rerouting without restoring an application. For each, write the predicted state, observe what the control plane actually reports and verify where traffic travels. The BGP route-selection concepts provide supporting context for route attributes and next-hop reasoning, but do not replace Juniper-specific objectives about MPLS and transport. It is better to understand one complete path than to memorize the names of several unrelated protocols.

A thoughtful JNCIS-SP study plan uses Juniper's current published exam resources, maps the topics to a controlled multi-node lab and records unexpected results. Exact current exam codes matter: older JN0-363 materials can contain useful technical concepts but should not be treated as proof of present blueprint coverage or appointment availability. Junos 25.2 is the software version identified by the active JN0-364 certification page at the time of review. Where configuration details are consequential, verify against the supported release and the vendor's technical documentation rather than trusting a third-party answer explanation.

JN0-364 is valuable because it teaches the engineer to think beyond one interface and one route. A provider's service depends on a coherent chain of IP reachability, transport state, encapsulation, failure detection and recovery. When those layers can be described separately and then connected, troubleshooting becomes more precise and design choices more defensible. That is the practical specialist capability this exam is meant to establish.