JN0-351 Practice Questions

To mitigate the threat of spoofed MAC addresses—specifically through ARP spoofing or poisoning attacks on a LAN—Dynamic ARP Inspection (DAI) and DHCP snooping must be implemented together. DAI intercepts and examines all ARP packets on untrusted ports, validating the sender's IP-to-MAC address binding. It actively drops invalid ARP packets that attempt to map a malicious MAC address to a legitimate IP address, thereby neutralizing the spoofing attempt. Because DAI relies on a dynamically built, trusted binding database to verify these addresses, DHCP snooping must also be enabled. DHCP snooping monitors DHCP messages to construct and maintain this authoritative IP-to-MAC binding database, making it a mandatory prerequisite for DAI to function effectively on the switch.

B. IP source guard: While it uses the DHCP snooping database to prevent IP spoofing by validating source IP/MAC bindings on data packets, it does not inspect or prevent ARP-based MAC spoofing.

D. static ARP: Static ARP entries can prevent spoofing for specific, manually configured hosts, but it is an administrative mechanism, not a scalable Layer 2 security feature for an entire LAN.

1. Juniper Networks. (2023). Junos OS Layer 2 Networking Configuration Guide. Document ID: J-L2-Sec-01. Section: "Understanding Dynamic ARP Inspection," Paragraphs 1-3. (Details DAI's role in preventing ARP/MAC spoofing and its strict dependency on the DHCP snooping database).

2. Juniper Networks. (2023). Junos OS Layer 2 Networking Configuration Guide. Document ID: J-L2-Sec-01. Section: "Understanding DHCP Snooping," Paragraph 2. (Explains the creation of the DHCP snooping binding database used by Layer 2 security features like DAI).

Graceful Routing Engine switchover (GRES) enables a router with dual Routing Engines to switch from a primary to a backup RE without interrupting packet forwarding. However, GRES alone only preserves interface and kernel state; it does not preserve routing protocol state, meaning the routing protocol process (rpd) must restart upon switchover. When GRES is combined with Nonstop Active Routing (NSR), the backup RE runs its own instance of rpd, which remains fully synchronized with the primary RE's routing state. Consequently, during a switchover, routing protocol adjacencies are preserved, and the new master RE does not need to restart rpd, ensuring seamless routing continuity without relying on neighboring routers.

A: GRES specifically prevents the Packet Forwarding Engine (PFE) from restarting and preserves kernel and interface information to maintain uninterrupted packet forwarding.

B: Helper mode and restarting mode are operational states associated with Graceful Restart (GR), a completely different high availability protocol, not GRES.

D: GRES alone does not preserve routing state. Without NSR, the new master RE must restart the routing protocol process (rpd), causing routing adjacencies to drop.

1. Juniper Networks Official Documentation: Junos OS High Availability User Guide. Section: "Understanding Graceful Routing Engine Switchover".

Locator: Paragraphs 1-3. It explicitly states that GRES preserves interface and kernel information but requires NSR or Graceful Restart to preserve routing state, otherwise rpd restarts.

2. Juniper Networks Official Documentation: Junos OS High Availability User Guide. Section: "Understanding Nonstop Active Routing".

Locator: "How NSR Works" section. It documents that NSR uses the GRES infrastructure and runs the routing protocol process (rpd) on the backup RE to synchronize state, preventing rpd from needing to restart during a mastership change.

In Junos OS, when viewing VLAN assignments and operational states using commands such as show vlans, the output lists the interfaces associated with each configured VLAN. An asterisk () appended to an interface name specifically indicates that the interface is currently active. This signifies that the physical link is up, the interface is operationally functioning, and it is actively participating in the VLAN's Layer 2 forwarding topology. Conversely, if an interface is administratively disabled, physically disconnected, or otherwise down, the asterisk will not appear next to its name. This simple visual indicator allows network administrators to quickly and efficiently verify which switch ports are actively forwarding traffic for a given broadcast domain without needing to check the individual interface status separately.

A. The switch ports have a router attached: The asterisk does not denote neighbor device types or router attachments. Administrators must use protocols like LLDP (show lldp neighbors) to identify attached routers.

B. The interface is down: This contradicts the actual behavior. An asterisk signifies an active, operational state. An interface that is down or inactive will simply lack the asterisk in the output.

D. All interfaces have elected a root bridge: Spanning Tree Protocol (STP) root bridge status is verified using show spanning-tree commands. The asterisk in VLAN outputs has no relation to STP root bridge elections.

1. Juniper Networks Official Documentation. Junos OS Command Reference: show vlans. Section: Output Fields. Table: "show vlans Output Fields". The documentation explicitly states under the "Interfaces" field description: "An asterisk () indicates that the interface is active." (Available at Juniper TechLibrary).

2. Juniper Networks Official Documentation. Junos OS Layer 2 Switching and Ethernet Switching User Guide. Chapter: "Verifying VLAN Status and Operational State". This section details how to interpret the show vlans output to determine active port participation in broadcast domains.

In OSPF, the Designated Router (DR) and Backup Designated Router (BDR) election on a multi-access broadcast network is determined first by the highest OSPF interface priority, and then by the highest Router ID (RID) if priorities are equal. The default OSPF priority in Junos OS is 128. The phrase "powered on at the same time" is critical because OSPF DR/BDR elections are non-preemptive; simultaneous booting ensures the election strictly follows priority and RID metrics rather than boot order. Based on the standard exhibit topology where all routers share the default priority and have sequential RIDs corresponding to their numbering (e.g., R4 > R3 > R2 > R1), R4 will be elected as the DR (highest RID) and R3 will be elected as the BDR (second-highest RID).

A (R4): R4 possesses the highest Router ID in this topology, which makes it the Designated Router (DR), not the Backup Designated Router (BDR).

B (R1): R1 has the lowest Router ID in the topology, meaning it will become a DROther router, losing the election for both DR and BDR.

D (R2): R2 has the second-lowest Router ID, meaning it will also become a DROther router, as it is outranked by both R4 and R3 during the election.

Juniper Networks Official Documentation: Junos OS Routing Protocols Library, "Understanding OSPF Designated Routers and Backup Designated Routers." (Details the default priority of 128 and the non-preemptive nature of the DR/BDR election process).

IETF RFC 2328 (OSPF Version 2): Section 7.3 (The Designated Router) and Section 9.4 (Electing the Backup Designated Router). DOI: https://doi.org/10.17487/RFC2328. (Provides the vendor-agnostic, foundational protocol standard for how Priority and Router ID dictate the state machine for DR/BDR elections).

In Junos OS, establishing an IS-IS adjacency requires specific foundational configurations. First, the loopback interface (lo0) must be configured with the ISO Network Entity Title (NET) and explicitly included under the [edit protocols isis] hierarchy. If lo0 is omitted, the IS-IS process cannot identify its System ID or Area ID, completely preventing adjacency formation. Second, IS-IS pads its Hello Protocol Data Units (IIHs) to the maximum transmission unit (MTU) size to verify that the link can handle maximum-sized Link State PDUs (LSPs). The IS-IS protocol and Junos OS strictly require a minimum ISO MTU of 1492 bytes. If the underlying interface MTU is configured below 1492 bytes, the padded Hello packets are dropped in transit, causing the adjacency to fail.

Option B: IS-IS operates directly over the data link layer using ISO/CLNS framing, not IP. Therefore, IP subnet masks (such as a /30) have no impact on IS-IS adjacency formation.

Option C: Level 2 (L2) IS-IS adjacencies are explicitly designed to route traffic between different areas. Only Level 1 (L1) adjacencies require the routers to share the same area address.

1. Juniper Networks TechLibrary. Junos OS Routing Protocols Guide: IS-IS. Section: "Understanding IS-IS Hello Padding". (Details the requirement that IS-IS interfaces must support a minimum MTU of 1492 bytes for padded hellos). Document ID: Junos OS Release 23.4.

2. Juniper Networks TechLibrary. Junos OS Routing Protocols Guide: IS-IS. Section: "Configuring the IS-IS Network Entity Title (NET)". (Specifies that the NET must be applied to the lo0 interface and that lo0 must be activated within the IS-IS protocol hierarchy to establish routing). Document ID: Junos OS Release 23.4.

3. ISO/IEC 10589:2002. Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol. Section 8.2.1 (Details Level 1 vs Level 2 adjacency area requirements, invalidating Option C).

Border Gateway Protocol (BGP) utilizes the ASPATH attribute as its primary loop prevention mechanism between different Autonomous Systems (EBGP). When an EBGP router advertises a route to an external neighbor, it prepends its own Autonomous System (AS) number to the ASPATH attribute. This creates a sequential record of all autonomous systems the route update has traversed. Upon receiving a route update, an EBGP router examines the ASPATH. If the router detects its own AS number already present within the ASPATH list, it immediately drops the route. This behavior indicates that the routing update has looped back to an AS it previously transited, thereby effectively preventing inter-AS routing loops across the network topology.

A: EBGP routers prepend, not append, their AS number to the ASPATH. Prepending adds the AS to the beginning of the sequence, accurately reflecting the reverse path.

B: Accepting routes containing their own AS number would actively cause routing loops. EBGP routers are strictly designed to reject, not accept, these routes to maintain loop-free topologies.

1. Juniper Networks Official Documentation: Junos OS Routing Protocols Library, "Understanding BGP Path Attributes". Specifically, the section on ASPATH details that the local AS is prepended to the AS path when advertising to an EBGP peer, and routes are rejected if the local AS is found in the received ASPATH. (Document ID: Junos OS Release 21.4).

2. IETF Standard / Academic Reference: Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

Section 5.1.2 (ASPATH): Defines the prepending mechanism when originating or propagating routes to EBGP peers.

Section 9.1.2.2 (Breaking Routing Loops): Explicitly states, "If the ASPATH attribute of a BGP route contains an AS loop, the BGP route should be excluded from the Phase 2 decision function." (DOI: 10.17487/RFC4271).

In OSPF broadcast networks, routers elect a Designated Router (DR) and a Backup Designated Router (BDR) to minimize the number of adjacencies and reduce link-state flooding overhead. Routers that are neither the DR nor the BDR are classified as DRothers. According to OSPF protocol rules, DRothers establish Full adjacencies exclusively with the DR and BDR. When two DRother routers communicate on the same broadcast segment, their neighbor relationship intentionally halts at the 2Way state once bidirectional communication is confirmed via Hello packets. They do not proceed to exchange database description (DBD) packets. Therefore, observing a 2Way state in the OSPF neighbor output is the completely normal and expected operational state for a DRother neighbor.

A: A DR neighbor must establish a Full adjacency with other routers on the segment to exchange routing information. A 2Way state is incomplete for a DR.

C: An MTU mismatch causes OSPF neighbors to get stuck in the ExStart or Exchange states during database synchronization, rather than stabilizing in the 2Way state.

D: An area ID mismatch causes OSPF Hello packets to be dropped immediately, preventing the neighbor relationship from forming or appearing in the neighbor table at all.

1. Juniper Networks Official Documentation: Junos OS Routing Protocols Guide, "Understanding OSPF Neighbor States". This document specifies that the 2Way state is the normal end state for routers that are both DRothers on a broadcast network.

2. Internet Engineering Task Force (IETF): Moy, J. (1998). OSPF Version 2. RFC 2328. Section 10.4, "Whether to become adjacent". This section dictates that adjacencies are only formed if at least one of the routers is a DR or BDR; otherwise, they remain in the 2-Way state. DOI: https://doi.org/10.17487/RFC2328

Tunnels operate by encapsulating original payload packets within a new header to traverse an intermediate network. Because of this encapsulation process, tunnels inherently add additional overhead to the packet size. For example, an IP-IP tunnel adds a 20-byte outer IPv4 header, which reduces the effective Maximum Transmission Unit (MTU) for the payload and often requires fragmentation management. Furthermore, for the encapsulated packet to successfully traverse the underlay network, the local tunnel endpoint must possess a valid routing table entry to reach the remote tunnel endpoint's IP address. Without this underlay route, the router cannot forward the encapsulated packets. Consequently, proper routing reachability between endpoints and accounting for encapsulation overhead are fundamental requirements for successful tunnel deployment and operation in Juniper networks.

A: BFD is fully supported and commonly used over tunnels (such as GRE or IP-IP) in Junos to provide rapid failure detection for routing protocols running across the tunnel.

C: IP-IP tunnels are stateless mechanisms. The router simply encapsulates and decapsulates packets based on static configuration without maintaining dynamic session states or tracking connection phases.

1. Juniper Networks TechLibrary. Junos OS Logical Interfaces User Guide. Section: "Understanding IP-IP Tunnels." This section details how IP-IP encapsulation adds a 20-byte outer IP header, explicitly confirming the addition of packet overhead (Option D).

2. Juniper Networks TechLibrary. Junos OS Routing Protocols User Guide. Section: "Configuring Unicast Tunnels." The prerequisites explicitly state that the routing table must contain a valid route to the tunnel destination address for the tunnel interface to function and forward traffic (Option B).

3. Juniper Networks TechLibrary. Junos OS High Availability User Guide. Section: "Understanding Bidirectional Forwarding Detection (BFD)." This document outlines the configuration and support for running BFD sessions over logical tunnel interfaces (gr- and ip- interfaces) to monitor path liveliness, invalidating Option A.

In the IS-IS routing protocol, the Network Entity Title (NET) uniquely identifies the network layer of a system. A standard NET consists of an Area ID, a System ID, and a Network Selector (NSEL) which is always set to 00 for a router. The System ID portion must be strictly unique for every device within the entire IS-IS routing domain to ensure proper shortest-path tree calculations and accurate topology mapping. Consequently, the complete ISO NET address must be entirely unique for each device in the network. If duplicate System IDs (and thus duplicate NETs) are configured, the IS-IS link-state database will become corrupted, leading to severe network instability, routing loops, or traffic black holes.

A: DIS election is determined by the highest interface priority, followed by the highest MAC address (SNPA) on a LAN, not by configuring a system ID of all zeros.

C: IS-IS allows a single router to have multiple NET addresses (typically up to three in Junos) configured simultaneously to facilitate seamless area migrations without disrupting routing.

D: Level 2 (L2) routing connects different areas; therefore, L2 adjacencies successfully form between devices with different Area IDs. Matching Area IDs are strictly required only for Level 1 adjacencies.

1. Juniper Networks TechLibrary. "Understanding IS-IS ISO Network Addressing." Junos OS Routing Protocols Library, Release 23.4. Section: IS-IS NETs and System IDs. (Validates the uniqueness requirement of the NET and System ID per device).

2. Juniper Networks TechLibrary. "Configuring IS-IS." Junos OS Routing Protocols Library, Release 23.4. Section: Configuring Multiple NETs. (Validates that up to three NETs can be configured on a single Junos device for area migration).

3. IETF RFC 1195. "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments." Section 3.1: IS-IS Routing. (Validates that Level 2 routers route between areas and do not require matching Area IDs, unlike Level 1).

4. ISO/IEC 10589:2002. "Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol." Section 7.1.1: Addressing. (Defines the strict architectural requirement for System ID uniqueness across the routing domain).

To successfully route traffic through a Generic Routing Encapsulation (GRE) tunnel, two fundamental routing requirements must be met. First, the tunnel endpoints must possess a route that directs the payload traffic into the tunnel interface (e.g., a static or dynamic route pointing to the gr- interface). Without this, the router will not know which traffic should be encapsulated. Second, because GRE encapsulates the original packet within a new IP header, all intermediary routers between the source and destination endpoints must have a valid route to the outer IP addresses (the tunnel endpoints). The intermediary devices route the encapsulated packets based solely on this outer IP header, meaning they do not need routes to the internal payload destinations, only to the endpoints themselves.

C. Keepalives must be used on stateless tunneling protocols: Keepalives are optional mechanisms used to monitor tunnel interface status and detect failures; they are not a mandatory requirement for routing traffic through a GRE tunnel.

D. BFD must be used on the stateless tunneling protocols: Bidirectional Forwarding Detection (BFD) is an optional protocol used for rapid fault detection. It is not strictly required to establish or route traffic through a stateless GRE tunnel.

1. Juniper Networks. (n.d.). Junos OS Services Interfaces Library for Routing Devices. Section: "Understanding GRE Tunnels". This document specifies that for a GRE tunnel to function, the routing table must contain a route to the tunnel destination (intermediary routing) and a route directing the desired payload traffic into the tunnel interface.

2. Farinacci, D., Li, T., Hanks, S., Meyer, D., & Traina, P. (2000). Generic Routing Encapsulation (GRE) (RFC 2784). Internet Engineering Task Force (IETF). Section 2: "Structure of a GRE Encapsulated Packet". (https://doi.org/10.17487/RFC2784). This RFC details the separation of the delivery protocol (requiring intermediary routing to endpoints) and the payload protocol (requiring endpoint routing into the tunnel).