Free JN0-364 Practice Test Questions | Know You're Ready for Service Provider Routing and Switching - Specialist (JNCIS-SP)

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."

Explanation:

This question addresses two specific requirements: ensuring the primary remains active when available and allowing servers to ping their gateway (the Virtual IP or VIP).

hy the Other Options are Incorrect

A. The backup router requires the track parameter:
Interface tracking is used to force a failover if an upstream link goes down. While useful for redundancy, it does not enable the "ping" functionality for the gateway.

B. The preempt parameter:
In VRRP for IPv6 (VRRPv3), preemption is often enabled by default. Furthermore, while preemption ensures the primary is active, it does not dictate whether the VIP responds to ICMP traffic.

C. Both routers require a static ARP entry:
VRRP uses a Virtual MAC address ($00:00:5E:00:01:XX$ for IPv4 or $00:00:5E:00:02:XX$ for IPv6) to handle Layer 2 resolution. Static ARP (or NDP for IPv6) entries are not required and would break the dynamic nature of the redundancy protocol.

References

RFC 5798: Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6, which discusses the restrictions on traffic destined for the IPv6 virtual address.

Juniper Networks Technical Publication: Junos OS High Availability Configuration Guide, specifically the section "Configuring VRRP to Respond to Ping Requests (accept-data)."

Explanation:

The Idle state is the first stage of the BGP Finite State Machine (FSM). When a session is stuck in this state, it indicates that the BGP process is either not started or is being prevented from initiating the connection attempt.

Why the Other Options are Incorrect

A. The BGP hold time is too short:
Hold time issues typically cause a session to reach the Established state and then flap (drop and restart) due to missed keepalives. It would not prevent the session from leaving the Idle state initially.

B. The BGP group type is set to internal instead of external:
If the group type is misconfigured, the BGP session will usually attempt to start but will fail during the OpenConfirm or OpenSent states because the remote AS received in the neighbor's Open message won't match the local configuration.

D. The peer IP address is incorrect:
If the peer IP is incorrect (but a local AS exists), the router will transition from Idle to Active or Connect. In these states, it will actively try to initiate a TCP three-way handshake ($SYN$). Because the IP is wrong, the connection will time out, and the router will cycle between Connect and Active, but it won't stay "stuck" in Idle.

References

RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 8.2.2, which describes the Idle state and its transition requirements.

Juniper Networks Technical Publication: Junos OS BGP User Guide, specifically the "Troubleshooting BGP Sessions" and "Configuring the Local AS" sections.

Explanation:

BGP (Border Gateway Protocol) relies on specific advertisement rules to maintain a loop-free network, particularly within an Autonomous System (AS). These rules dictate how routes are propagated between Internal BGP (IBGP) and External BGP (EBGP) neighbors.

A. EBGP peers advertise routes learned from IBGP or EBGP peers to other EBGP peers:
This is the fundamental behavior of BGP. A router at the edge of an AS will take any valid route it has selected as the "best path"—whether it learned it from an internal neighbor or another external neighbor—and advertise it to its external peers.

B. IBGP peers advertise routes received from EBGP peers to other IBGP peers:
When an edge router learns a route from an external AS (EBGP), it shares that information with all of its internal neighbors (IBGP) so that the entire AS knows how to reach that external destination.

D. IBGP peers do not advertise routes received from IBGP peers to other IBGP peers:
This is known as the IBGP Split Horizon rule. To prevent routing loops within an AS, a BGP router is prohibited from passing a route learned from one IBGP peer to another IBGP peer. This is why IBGP requires a "full mesh" configuration (where every router peers with every other router) or the use of Route Reflectors.

Why the Other Options are Incorrect

C. IBGP peers advertise routes received from IBGP peers to other IBGP peers:
This contradicts the Split Horizon rule mentioned above. If this were allowed, a route could loop infinitely within the AS because IBGP does not change the AS-Path attribute.

E. IBGP peers do not advertise routes received from EBGP peers to other IBGP peers:
This is incorrect. If internal routers did not share their external findings, the rest of the network would have no way to reach the outside world.

References

RFC 4271:A Border Gateway Protocol 4 (BGP-4), Section 9.1.2.2, which defines the rules for propagating routes to IBGP and EBGP neighbors.

Juniper Networks Technical Publication: Junos OS BGP User Guide, section on "BGP Internal and External Peering."

Explanation:

In Junos OS, the inet.3 table is specifically designated as the MPLS Path Information Table. It is the primary location where the local router stores information about all Label Switched Paths (LSPs) for which it acts as the ingress node.

When an LSP is successfully established (via RSVP or LDP), the exit point (egress) of that LSP is placed into the inet.3 routing table. This table is then used by BGP to resolve its next-hop addresses. If BGP finds a match for its next hop in inet.3, it knows it can forward that traffic through an MPLS tunnel instead of using standard IP routing.

It is important to note that, by default, the routes in inet.3 are only used for BGP next-hop resolution and are not used for standard IPv4 traffic lookups unless specifically configured otherwise (such as using traffic-engineering bgp-igp-both-ribs).

Why the Other Options are Incorrect

A. inet.2:
This table is used for Multicast Source Discovery Protocol (MSDP) and is involved in Unicast Reverse Path Forwarding (uRPF) checks for multicast traffic. It does not store LSP information.

C. inet.1:
This table is used to store multicast forwarding cache information (the Multicast Forwarding Information Base).

D. inet.0:
This is the default IPv4 unicast routing table. While it contains routes learned via IGPs (OSPF, IS-IS) and BGP, it does not store ingress LSP information by default.

References

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

JNCIS-SP Study Materials: Domain: MPLS Operations and Next-Hop Resolution.

Day One: Configuring MPLS: Explains the functional difference between inet.3 (for BGP) and mpls.0 (for transit).