Free JN0-364 Practice Test Questions 2026

Explanation:

In IS-IS (Intermediate System to Intermediate System), the formation of an adjacency relies on a three-way handshake to ensure bidirectional communication. The Initializing state is the middle step of this process. It indicates that the local router has successfully received a Hello PDU from a neighbor, but the neighbor has not yet seen a Hello PDU from the local router.

When a router enters the Initializing state, it includes the neighbor's MAC address (on LANs) or System ID (on Point-to-Point links) in its own transmitted Hellos. The state only transitions to Up once the router receives a Hello back from that neighbor that explicitly lists the local router’s identity in the "neighbor" field, confirming that the path is viable in both directions.

Why the Other Options are Incorrect

A. loading:
This is an OSPF (Open Shortest Path First) state used during the synchronization of the Link State Database (LSDB). IS-IS does not have a "loading" state; it uses CSNPs and PSNPs for database synchronization after the adjacency is Up.

C. up:
This is the final state. While it indicates packets have been exchanged, it means the adjacency is fully established and the routers are ready to exchange Link State PDUs (LSPs). The question specifically asks for a state where it is not yet fully established.

D. two-way:
This is a state specific to OSPF (representing bidirectional communication on multi-access networks). While the concept is similar to the logic of IS-IS reaching the "Up" state, the terminology is not used within the IS-IS state machine.

References

ISO/IEC 10589: The OSI standard for IS-IS, which defines the state machine for Intermediate System neighbors.

RFC 5303: Three-Way Handshake for IS-IS Point-to-Point Adjacencies, which clarifies the transition from Down to Initializing to Up.

Explanation:

The AS Path (Autonomous System Path) is a mandatory transitive attribute in BGP that records every AS number a route advertisement has passed through. It serves two primary functions in BGP operations:

Loop Prevention (B):
This is the most critical function of the AS Path. When a BGP router receives an update, it scans the AS Path attribute. If it sees its own local AS number already listed in the path, it recognizes that the advertisement has looped back to its starting point. The router will then discard the update to prevent a routing loop from forming.

Path Selection (C):
BGP is a path-vector protocol. One of the early steps in the BGP Best Path Selection algorithm is comparing the length of the AS Path. By default, a router will prefer the route with the fewest number of AS numbers in the path (the "shortest" path), as this typically represents the most direct logical route to the destination prefix.

Why the Other Options are Incorrect

A. the origin of a route from IGP or EGP:
This information is determined by the Origin Attribute, not the AS Path. The Origin attribute explicitly tags whether the route was learned via an Interior Gateway Protocol (IGP), Exterior Gateway Protocol (EGP), or is Incomplete (usually via redistribution).

D. the total number of next-hop devices to reach a prefix:
The AS Path only counts the number of Autonomous Systems traversed. It does not provide visibility into the internal topology of those ASs. A single "AS hop" could consist of dozens of physical next-hop routers (devices) within that network, which the AS Path attribute cannot see.

References

RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5.1.2, which defines the AS_PATH attribute and its use in loop detection.

Juniper Networks Technical Publication: Junos OS BGP Peering and Path Selection Guide, specifically the "AS-Path Attribute" and "BGP Path Selection" sections.

Explanation:

To support dual VLAN tags (often referred to as Q-in-Q tunneling or 802.1ad), Junos devices require specific configuration at the physical interface level to allow the processing of both an outer (S-tag) and an inner (C-tag) header.

flexible-vlan-tagging (A):
This is the most versatile statement. It allows the interface to support a mix of tagging methods across different logical units, including single tags, dual tags (stacked), and even mixed encapsulation types like PPP over Ethernet. It is the standard for modern Juniper service provider configurations where multiple service types exist on one physical port.

stacked-vlan-tagging (D):
This is a specific legacy-style statement used to explicitly enable the device to process dual 802.1Q VLAN tags. While "flexible-vlan-tagging" is more common now, "stacked-vlan-tagging" remains a valid method to achieve the same result for Q-in-Q tunneling.

Why the Other Options are Incorrect

B. gigether-options:
This hierarchy is used for physical layer settings such as auto-negotiation, flow control, and loopback testing. It does not control VLAN encapsulation or the number of supported tags.

C. vlan-tagging:
While this statement enables VLAN support on an interface, it is limited to single 802.1Q tags only. It will not allow the configuration of a second (inner) tag on a logical unit.

References

Juniper Networks Technical Publication:Junos OS Layer 2 Switching Configuration Guide.

JNCIS-SP Exam Objectives: Layer 2 Bridging and VLANs (Q-in-Q tunneling).

Junos CLI Hierarchy: [edit interfaces interface-name]—specifically the encapsulation requirements for 802.1ad.

Explanation:

BGP attributes are categorized based on how routers handle them when they are not recognized. The Community attribute is a prime example of an Optional Transitive attribute.

Why the Other Options are Incorrect

A. Origin:
This is a Well-known Mandatory attribute. Every BGP speaker must recognize it, and it must be included in every BGP update message.

B. AS Path:
This is also a Well-known Mandatory attribute. It is essential for loop detection and path selection and must be present in every update.

D. MED (Multi-Exit Discriminator):
This is an Optional Non-transitive attribute. If a BGP speaker does not recognize the MED, it is ignored and not passed on to other peers. Furthermore, MED is typically stripped when a route is passed to a third-party Autonomous System.

References

RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 5, which defines the categories of BGP path attributes.

RFC 1997: BGP Communities Attribute, which specifically classifies communities as optional and transitive.

Explanation:

Bidirectional Forwarding Detection (BFD) uses a negotiation process between neighbors to establish the transmission and reception intervals. This ensures that both sides are capable of processing the control packets at the agreed-upon speed without overwhelming either device's CPU.

Why the Other Options are Incorrect

A. Each router will send BFD packets at the rate locally configured:
This is incorrect because BFD is a negotiated protocol. If routers sent at different rates without agreement, the detection multipliers would be inconsistent, leading to "flapping" sessions.

B. BFD will fail due to the mismatched timers:
BFD is designed specifically to handle mismatched timers. As long as the timers are within a supported range for the hardware, the session will establish using negotiated values.

D. Each router will negotiate to the fastest of the two rates:
Negotiating to the fastest rate (300ms) would risk overwhelming R2, which has explicitly stated it is configured for 400ms. BFD always defaults to the more conservative (slower) timer to ensure stability.

References

RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.1, which details the transmission interval negotiation.

Juniper Networks Technical Publication: Junos OS Routing Protocols Configuration Guide, section on "BFD for IS-IS."

Explanation:

In Junos OS, routing and forwarding information is organized into specific tables based on the protocol and the type of data being handled. The mplS.0 table is the dedicated table for MPLS label operations.

Label Information Base (LIB):
When a router acts as a Label Switching Router (LSR), it needs to know what to do when it receives a packet with a specific MPLS label. The mpls.0 table stores these label-to-action mappings (such as pop, swap, or push).

Transit Traffic: This table is primarily used for transit label-switched paths (LSPs). When an MPLS packet arrives, the router performs a lookup in mpls.0 based on the incoming label to determine the next-hop interface and the outgoing label.

Why the Other Options are Incorrect

A. inet6.0: This table is used for storing IPv6 unicast routes. It is not involved in label-switching logic.

C. inet.3: This is the MPLS Path Information Table. It stores the ingress LSPs and is used by the local router to resolve BGP next-hops to LSPs. While related to MPLS, it does not store the LIB for transit label operations.

D. inet.0: This is the default IPv4 unicast routing table used for standard IP packet forwarding and route selection.

References

Juniper Networks Technical Publication: Junos OS MPLS Configuration Guide, specifically the section on "MPLS Label Tables."

JNCIS-SP Study Materials: Domain: MPLS Fundamentals and Label Information Base.

Explanation:

To influence inbound traffic (traffic entering your network from an external AS), you must manipulate attributes that external BGP peers use to make their path selection.

Why the Other Options are Incorrect

A. a route reflector:
This is an internal BGP (IBGP) feature used to scale the network by reducing the need for a full mesh of peerings. It is not used to influence inbound path selection from external peers.

B. origin code:
While the Origin attribute is part of the BGP selection process (preferring IGP over EGP or Incomplete), it is not a standard or reliable way to perform traffic engineering. Manipulating it can cause unpredictable results compared to AS-path length.

D. local preference:
This is a Well-known Discretionary attribute used to influence outbound traffic (how traffic leaves your network). Local preference is not transitive across Autonomous Systems; therefore, your upstream peers will never see the local preference value you set on your own routers.

References

RFC 4271:A Border Gateway Protocol 4 (BGP-4), Section 5.1.2 (AS_PATH).

Juniper Networks Technical Publication: Junos OS BGP User Guide, Chapter on "Influencing BGP Path Selection."

Explanation:

The Established state is the final stage of the BGP state machine. At this point, the BGP session is fully operational, and the neighbors have agreed on all parameters. In this state, the routers can exchange the following types of messages:

Update (C):
This is the most critical message type used during the Established state. It is used to advertise feasible routes to peers or to withdraw previously advertised routes that are no longer reachable. It contains path attributes (like AS Path and Next Hop) and Network Layer Reachability Information (NLRI).

Notification (D):
This message is sent whenever an error is detected or when a peer decides to close the connection. If a Notification message is sent or received while in the Established state, the BGP session is immediately terminated, and the state transitions back to Idle.

Why the Other Options are Incorrect

A. open:
The Open message is only exchanged during the OpenConfirm state. It is used to propose session parameters (such as ASN and Hold Time) before the session reaches the Established state. Once the session is Established, Open messages are no longer sent.

B. request:
BGP does not have a message type called "request." Unlike protocols like OSPF or IS-IS that use Link State Requests, BGP is an incremental update protocol that pushes information via Update messages without being prompted by a request.

References

RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 8.2.2, which details the Finite State Machine (FSM) and the messages allowed in the Established state.

Juniper Networks Technical Publication: Junos OS BGP User Guide, "BGP Message Types" section.

Explanation:

In the IS-IS (Intermediate System to Intermediate System) protocol, Hello PDUs (Protocol Data Units) are the fundamental packets used for neighbor discovery and adjacency maintenance.

Why the Other Options are Incorrect

A. link-state PDU (LSP):
These are used to distribute actual routing information (topology data) once the adjacency is already established. They do not create the initial neighbor relationship.

C. partial sequence number PDU (PSNP): These are used to acknowledge the receipt of specific LSPs or to request missing LSPs during database synchronization.

D. update PDU:
This is not a valid IS-IS packet type. While BGP uses "Update" messages, IS-IS relies on LSPs to propagate changes in the network topology.

References

ISO/IEC 10589: The primary specification for the IS-IS protocol, detailing the "Hello" mechanism for neighbor acquisition.

Juniper Networks Technical Publication: Junos OS Routing Protocols Configuration Guide, specifically the "IS-IS PDUs" section.

Explanation:

Both GRE (Generic Routing Encapsulation) and IP-IP (IP-in-IP) are tunneling protocols used to encapsulate one packet inside another to transport data across a network.

Overhead (A):
When a packet is tunneled, a new delivery header is prepended to the original packet.

Lack of Encryption (D):
By default, both GRE and IP-IP are "clear-text" tunneling protocols. They provide a logical path for data but do not provide confidentiality, integrity, or authentication. If security is required, these tunnels must be wrapped within IPsec to encrypt the payload.

Why the Other Options are Incorrect

B. These tunnels do not add any overhead:
This is mathematically impossible in networking. Any encapsulation process requires at least a new header to route the packet to the tunnel endpoint, which inherently adds bytes (overhead) to the original payload.

C. These tunnels offer secure encryption mechanisms:
This is a common misconception. While GRE is often used with IPsec, GRE itself has no built-in encryption capability. It simply "hides" the inner protocol (like OSPF or IS-IS) so it can be routed over an IP network.

References

RFC 2784: Generic Routing Encapsulation (GRE), which defines the protocol and its header structure.

RFC 2003: IP Encapsulation within IP, detailing the IP-in-IP mechanism and its 20-byte overhead.

Explanation:

In IS-IS, the network is divided into hierarchies to maintain scalability. Level 1 (L1) routers operate within a specific area, while Level 2 (L2) routers form the backbone. Level 1/2 (L1/L2) routers act as the border routers between these two worlds.

Separate Topologies (C):
A Level 1/2 router maintains two distinct Link State Databases (LSDBs)—one for Level 1 and one for Level 2. It does not merge them into a single SPF (Shortest Path First) calculation. It participates in the L1 intra-area routing and the L2 backbone routing simultaneously but keeps the topology information partitioned.

Restricted L1 Visibility (D):
By design, IS-IS does not leak Level 2 routes into Level 1 areas. Therefore, a Level 1 router has a complete map of its own area (L1 topology) but is completely "blind" to the backbone (L2) or other areas. To reach destinations outside its area, the L1 router relies on a default route automatically advertised by the L1/L2 router (via the Attached Bit or "ATT bit").

Why the Other Options are Incorrect

A. The Level 1/2 router merges Level 1 and Level 2 into one complete topology:
This is incorrect. Merging them would defeat the purpose of the hierarchical design. The L1/L2 router keeps separate databases to ensure that stability issues in one level do not automatically trigger SPF recalculations in the other.

B. The Level 1 router will learn the full topology of the Level 2 network:
This is incorrect. L1 routers never learn L2 topology details. They are designed to be "stubby" to save memory and CPU cycles, only knowing how to reach the nearest exit point (the L1/L2 router).

References

ISO/IEC 10589: The IS-IS standard, which defines the hierarchical relationship between Level 1 and Level 2.

RFC 1195:Use of OSI IS-IS for Routing in TCP/IP and Dual Environments.

Juniper Networks Technical Publication: Junos OS Routing Protocols Configuration Guide, Chapter: "IS-IS Hierarchical Routing."

Explanation:

In a standard MPLS Label Switched Path (LSP), routers perform different operations based on their position in the path:

Ingress LSR (R1): Perfroms a Label Push. It receives an unlabeled IP packet, determines the forwarding class/destination, and pushes a label onto the packet before sending it to the next hop.

Transit LSR (R3): Performs a Label Swap. It receives a labeled packet, looks up the label in the mpls.0 table, and swaps the incoming label with a new outgoing label toward the next hop.

Penultimate LSR (R4): Performs PHP (Penultimate Hop Popping) by default in Junos. Because R5 (the egress) advertises an "Implicit Null" label (Label 3) to R4, R4 will pop the label and send a raw IP packet to R5.

Egress LSR (R5): Performs a Route Lookup. Since the label was already popped by R4, R5 receives an IP packet and performs a standard lookup in inet.0.

Why the Other Options are Incorrect

A. R4: As the penultimate hop, it performs a pop operation (removing the label) rather than a swap, ensuring the egress router (R5) doesn't have to perform two lookups (one for the label and one for the IP).

C. R5: As the egress router, it handles the final packet. Under default Junos settings (PHP), it receives the packet with no label at all.

D. R1: As the ingress router, it performs a push operation to initiate the MPLS journey.

References

RFC 3031: Multiprotocol Label Switching Architecture, defining the roles of Ingress, Transit, and Egress LSRs.

Juniper Networks Technical Publication: Junos OS MPLS Configuration Guide, section on "Label Operations and PHP."