JN0-364: MPLS, IPv6 and Provider Network Resilience

The JNCIS-SP JN0-364 exam focuses on the intermediate engineering knowledge required to operate a Junos-based service-provider network. Its subject matter is unusually broad: static and generated routes, OSPF, IS-IS, BGP, provider Ethernet switching, MPLS, IPv6, GRE tunnels and several resilience mechanisms. The common thread is a network that must carry many services across shared infrastructure while allowing faults and policy changes to be diagnosed precisely. An engineer cannot treat protocols as separate flashcard topics when their interactions determine the path that a customer's traffic takes.

Juniper's published JN0-364 overview specifies JNCIA-Junos JN0-106 as the prerequisite certification. It lists a 90-minute examination with 65 multiple-choice questions. For progression, the JNCIP-SP JN0-664 stage expands into advanced routing policy, provider VPNs, multicast and service quality. The specialist learner should first build a coherent model of which protocols populate routes, which protocols establish labeled transport, and which high-availability controls keep packet forwarding useful under failures.

Establish dependable reachability before adding services

Provider routing begins with the relationship among connected routes, static routes, aggregated or generated routes and the routing table that selects a usable next hop. A provider edge router may have separate routing instances representing a customer's traffic, management traffic and shared infrastructure. A route in one instance does not automatically appear in another. RIB groups and route policies can distribute information when explicitly configured, but indiscriminate leaking weakens service isolation and complicates fault analysis.

Imagine a customer whose internet connection works while a private connectivity service fails. Both services may traverse the same physical interface but use different forwarding contexts. The first useful questions involve which table contains the destination, whether a valid next hop exists, and which route source installed the entry. If the service prefix is absent, forcing another physical link up cannot repair missing routing information. A traceroute or ping must also be sourced from an appropriate routing context or it may test a path different from the customer's.

Load balancing needs a precise interpretation. Multiple equal-cost next hops allow distribution across alternatives, but a hash may keep each flow on a single path. A single very large flow can saturate its chosen link while aggregate capacity remains unused. Filter-based forwarding provides other choices for steering traffic, though asymmetric results and policy management can become more complex. These distinctions prevent candidates from assuming that a diagram with four parallel lines guarantees fourfold performance for every application.

Compare OSPF and IS-IS control-plane behavior

OSPF builds a link-state database and computes routes from its topology information. Interfaces, neighbor adjacencies, router IDs, areas and LSAs are all parts of that process. A device can have an interface operationally up but fail to become a neighbor because protocol parameters or adjacency conditions differ. OSPF is therefore not simply a command to advertise directly connected networks; it is a topology distribution mechanism with design boundaries.

IS-IS also uses link-state concepts but represents protocol information using different PDUs and type-length-value structures, and its Level 1 and Level 2 relationships create distinct area considerations. An engineer should know how a designated intermediate system functions on relevant shared-media segments, how metrics affect selection and how route leaking or summarization can limit reachability. The purpose of comparing these protocols is not to declare one universally superior, but to recognize where their operational state and design constraints differ.

For a practical fault, disable a link between two routers and inspect the resulting neighbor state, topology information and new active routes. Then repeat with one protocol parameter deliberately mismatched. A fast route convergence after a clean link failure is different from a persistent adjacency mismatch that prevents routes from being learned. Record which tool tells you about interface state, which about neighbors, which about the database and which about installed routes. These distinct kinds of evidence are central to the JN0-364 syllabus.

Use BGP to distribute routes according to service policy

BGP exchanges reachability between configured peers and relies heavily on attributes and policy. EBGP and IBGP relationships have distinct path propagation and next-hop implications. An established BGP session proves only that the peers can communicate at the protocol level; it does not show that every desired route has been received, accepted and installed. The selected route still depends on attributes, import policy and next-hop reachability. BGP routing becomes manageable when peers, available paths and intended policy are all documented.

In a provider backbone, BGP might connect customer and provider domains or distribute internal service reachability. A prefix advertised by a customer may be filtered for authorization and scope, while routes sent to a customer can be restricted to a default route or agreed set. Prefix leaks are operationally serious because a wrongly advertised route can divert traffic that the announcing network cannot forward. Policy review should therefore include what is denied and what would be advertised if no explicit term matched.

The specialist candidate needs to distinguish route selection inside a routing protocol from selection among routes learned from different protocols. A BGP path can win BGP's own best-path decision and still compete with another route source according to Junos preference and related conditions. In troubleshooting, confirm the path is accepted, active in the appropriate routing table and resolved to a forwarding next hop. The chain matters more than any single attribute name.

Connect Ethernet services to MPLS transport

Provider Ethernet networks carry customer frames using mechanisms including VLAN tagging, provider bridging and virtual switches. Q-in-Q encapsulation can preserve customer VLAN information within a provider's service tags, but the operator needs a strategy for tag interpretation, service boundaries and loop prevention. IRB bridges Layer 2 domains to routing functions where the design calls for it. STP variants and BPDU, loop or root protections affect which redundant Layer 2 paths can be used safely; they should not be confused with IP routing convergence.

MPLS forwards traffic using labels associated with established paths or forwarding equivalence classes. The label stack is processed differently from a plain destination-IP lookup at each hop. Label distribution mechanisms such as LDP and RSVP-TE, along with segment-routing approaches, have distinct signaling and operational characteristics. MPLS and Layer 3 VPN architecture supplies helpful conceptual background even though JN0-364 focuses on Junos implementations.

A customer may experience a VPN outage while the physical backbone still carries other services. That points toward labels, route distribution, VPN forwarding contexts or endpoint mappings rather than necessarily a broken fiber. The engineer should follow an intended packet from ingress service classification into label forwarding and finally egress. Determine whether the necessary transport path exists and whether the service information associates the customer with that path correctly. A label-switched path that exists on paper may still lack a valid forwarding entry or a reachable next-hop adjacency.

A label path also needs capacity management. Voice, video and bulk data may share transport infrastructure but have different sensitivity to jitter, packet loss and queueing. Class-of-service controls can protect important traffic under congestion when correctly classified and provisioned. They cannot create bandwidth that the physical path does not provide, and a wrongly applied classifier can disadvantage the very service it was meant to protect.

Account for IPv6, tunnels and failure recovery

IPv6 expands the protocol exercise beyond longer addresses. Candidates should understand static routes, OSPFv3, IS-IS and BGP for IPv6 reachability, and common ways of carrying IPv6 over infrastructure that may contain IPv4 segments. An IPv6 prefix that appears correct can still be unreachable because a neighboring interface lacks the right address family or policy. Troubleshooting must establish the actual route family and next-hop context, not extrapolate success from IPv4 pings.

GRE tunnels provide another form of encapsulation with clear transport prerequisites. The tunnel's apparent connectivity depends on reaching the physical endpoints through an appropriate underlay route. Packet overhead reduces available payload MTU, and careless recursive routing can send tunnel reachability through the tunnel itself. An operational test needs both outer transport verification and inner service traffic checks, especially when applications send large packets that reveal MTU problems absent in tiny pings.

High availability includes link aggregation, BFD, VRRP, graceful restart, graceful Routing Engine switchover, nonstop bridging and nonstop active routing. They protect different state or forwarding functions. For a provider voice service, detecting a link failure quickly is useful, but recovery still depends on a viable alternative path and sufficient quality of service. Lowering timers without considering instability may increase the number of disruptive reconvergences. The candidate should reason about what each feature preserves during a fault and what must still reconverge.

Prepare by tracing a customer service end to end

Create a four-router provider core with two customer sites. Establish IP routing, observe an IGP adjacency, configure a restricted BGP exchange, and add a simple labeled transport or tunnel scenario where your lab permits. Break one component at a time: remove an underlay route, deny a prefix by policy, make a tunnel endpoint unreachable, or lose a link with redundant alternatives. Record the outcome for control-plane neighbors, route tables, forwarding entries and end-user traffic.

Use Juniper's official JN0-364 objectives and software-version guidance as the boundary for precise preparation. The knowledge should connect protocol-independent routes, OSPF, IS-IS, BGP, Layer 2 provider services, MPLS, IPv6, tunnels and resilience into one set of operational questions. When traffic fails, identify where the network learned the route, how it selected an action, and whether the data plane can actually deliver the packet. That integration is what distinguishes genuine service-provider understanding from remembering separate protocol definitions.