Juniper JN0-364: Service Provider Routing and MPLS

The JN0-364 examination leads to Juniper's JNCIS-SP credential and assesses the skills used to configure, monitor and troubleshoot service-provider routing and switching. Juniper lists JNCIA-Junos as the prerequisite, with 65 multiple-choice questions over 90 minutes and a Junos OS 25.2 reference. The syllabus stretches beyond simple IP reachability into OSPF, IS-IS, BGP, MPLS, provider bridging, IPv6 and high availability. Its unifying question is how a provider can transport many customers' traffic while maintaining predictable reachability, separation and resilience. Effective study should center on forwarding outcomes, not just protocol abbreviations.

Build routing tables with clear policy boundaries

Protocol-independent routing covers static, aggregate and generated routes, routing instances, routing information base groups and load balancing. Each tool changes what reachability information is present and where it may be installed. A static route can solve a simple next-hop requirement but introduces maintenance cost when physical topology changes. Aggregation can reduce route volume yet accidentally conceal unreachable specifics if the supporting design is weak. A generated route is not identical to an unconditional static advertisement; its creation depends on configuration and contributing route logic. A specialist must inspect whether routing information is valid for the intended table before it can reach the forwarding plane.

Provider networks often contain several service contexts. A routing instance allows separate forwarding knowledge for distinct purposes, while policy controls the acceptance and advertisement of routes. If a prefix is visible in an instance but the wrong customer learns it, the problem is more than suboptimal convergence: it may breach isolation. Consider using a small lab with customer A and B networks plus a provider backbone. Document which interface, routing table and policy should handle each direction. The goal is to be able to predict how a route changes when a policy term is added or an aggregate loses its contributor.

Compare OSPF and IS-IS underlay behavior

OSPF and IS-IS both support link-state routing but differ in protocol design and operational conventions. OSPF maintains neighbors, a link-state database and area structure; parameters such as network type, area, timers and authentication can influence adjacency. IS-IS uses levels, areas, protocol data units and TLVs, with distinct adjacency and designated intermediate system behavior. Understanding the similarities helps in diagnosis, but treating the protocols as interchangeable can lead to a misleading checklist. In a provider environment, the underlay must reach router loopbacks and transport endpoints reliably before higher-layer VPN services can operate.

When a router cannot reach a loopback, verify the correct routing instance, neighbor state, route distribution and next-hop resolution. Differentiate a failed control-plane adjacency from a route accepted into the RIB but never selected for forwarding. Check link errors or inconsistent metrics rather than immediately changing every interface cost. A protocol's link-state view may converge correctly while service traffic is broken higher in the stack. The service engineer should demonstrate each dependency independently and record whether the underlay changed after maintenance.

Explain BGP policy and interdomain selection

BGP exchanges reachability through peers and selects eligible routes using defined attributes and policy. Internal and external sessions serve different roles: eBGP typically connects administrative systems, while iBGP distributes routes within an AS without changing their external origin. Understand how local preference, AS path, MED and next-hop reachability influence selection, and how policy can prevent an otherwise established peer from exchanging usable prefixes. A routing decision must not be inferred from a single attribute while ignoring eligibility and filtering.

In service-provider deployments, BGP may also carry routes for customer services or overlays, creating dependencies on address families and route-target policy. A network operator diagnosing a missing customer's prefix should inspect the advertising neighbor, received route, import policy, installed route and VPN context. A generic command showing peer uptime answers only the first of those questions. The same route-policy checks—prefix matching, next-hop resolution and controlled export—also apply to BGP route policy on IOS XR, although Junos and Cisco have different command hierarchies. Verify these decisions in Junos directly instead of transplanting IOS XR configuration examples.

Trace an MPLS label-switched path

MPLS separates a packet's service label handling from ordinary destination-IP forwarding decisions. Understand labels, label stack operations, the label information base, and the distinction between ingress, transit and egress label-switching behavior. MPLS transport paths may use different signaling approaches, such as LDP, RSVP or segment routing with MPLS. They need underlay reachability and viable label bindings, so a broken link-state route can disrupt services that appear unrelated to the underlay at first glance.

Provider bridging and VLAN handling also matter. Q-in-Q allows provider and customer tags to coexist under defined service boundaries, but mismatched encapsulation can leak or discard traffic. Integrated routing and bridging supports Layer 3 forwarding for VLAN-associated interfaces, while virtual switches preserve some Layer 2 segmentation. The exam expects conceptual differences among provider Ethernet services rather than a single packet path for all customers. Engineers should know how to locate a mismatch: is the frame tagged incorrectly, the LSP missing, the label not installed, or the VPN service unable to resolve its next hop? Effective Junos MPLS L3VPN troubleshooting isolates transport reachability, VPN route import, label installation and customer attachment before changing the network.

Account for IPv6, tunneling and availability

IPv6 changes addressing, neighbor discovery and the route families a service must support. OSPFv3, IS-IS and BGP can participate in IPv6 reachability, but the presence of one IPv4 route does not guarantee a corresponding IPv6 path. GRE and other IP tunnels can transport traffic over existing infrastructure; they introduce encapsulation overhead and possible MTU constraints. Testing an IPv6 service should include source and destination addressing, route selection, tunnel endpoints and return traffic. Avoid assuming that dual-stack simply doubles the number of identical routes.

High availability mechanisms address different failure intervals. Link aggregation can protect a member failure, BFD can detect forwarding failure rapidly, and graceful restart, GRES or NSR may limit control-plane disruption depending on platform and configuration. VRRP can protect a first-hop gateway where applicable, but is not a replacement for backbone routing. Measure impact when a transport link fails: what routes withdraw, which labels change and what delay do customer sessions experience? The best answer describes a particular failure domain rather than claiming that one availability feature makes a service fully resilient.

Troubleshoot a multi-customer outage methodically

Imagine a provider core where two customers lose connectivity after a fiber restoration, while other VPNs recover. Begin by verifying the physical interface and the IS-IS or OSPF underlay route to the remote loopback. Check whether the intended MPLS paths and labels exist and whether the correct BGP service routes are accepted. The fact that unaffected customers share some routers does not prove the fabric is healthy for every route target or encapsulation. Compare affected and unaffected service contexts to isolate the difference. A mistaken route-target export may disrupt just two customers even though transit labels remain valid.

Use path tests at progressively higher layers. Validate underlay IP, label resolution, VPN route acceptance and then customer forwarding. Record what changed during the restoration—optical path, metric, route policy, targeted session or service interface. If an MTU mismatch appears after moving traffic to a different transport, changing BGP preference may only hide the symptom. Document the smallest viable correction and confirm that unaffected customers remain isolated. JN0-364 rewards the ability to make that layered diagnosis under pressure.

Verify quality of service without confusing it with basic reachability

Service-provider networks carry traffic with different latency and loss requirements. A customer using interactive voice, a backup service and telemetry might reach all destinations while experiencing very different outcomes under congestion. The engineer needs to understand classification, forwarding classes, queues and where traffic is policed or shaped. A label-switched path does not guarantee a quality-of-service contract by itself. Class-of-service behavior depends on consistent marking and enforcement across the entire transit path.

Consider a transport circuit that fills during nightly backups. A ping to the remote loopback still succeeds, so operations mistakenly conclude there is no network issue. Application telemetry shows voice jitter and retransmitted business transactions at the same time. Examine interface queue counters, class mapping and whether the offered load exceeds provisioned capacity. Verify that markings are not unintentionally rewritten as frames move between customer Ethernet service, MPLS transport and IP routing. A configuration may be syntactically valid while allowing bulk traffic to consume a queue intended to protect interactive workloads.

Capacity analysis must include the failure case. If two parallel provider links normally carry half the load each, the remaining link may become congested after a single failure even when routing reconverges immediately. The incident therefore has both availability and performance components. Develop tests that validate not only that routes and LSPs reappear, but also that the remaining path can meet business expectations or at least degrade predictably. JN0-364 candidates who can relate MPLS labels, routing and class-of-service evidence are better positioned to troubleshoot realistic customer complaints than candidates who treat successful control-plane status as complete proof of service health.

Prepare with service-oriented experiments

Construct a lab with an IP underlay, BGP peering, separate customer routing contexts and at least one MPLS LSP. Deliberately remove a loopback route, reject a BGP prefix, alter a customer VLAN tag and take down a transport link. For each fault, explain which layer fails first and what operational evidence should appear. Compare Juniper certifications to place JNCIS-SP before the JN0-664 professional examination. Review the official exam objective weights and software reference before booking. The point of preparation is to relate provider service continuity to concrete routing and forwarding state, not merely to recall MPLS vocabulary.