JN0-362 Practice Questions

To transport both tagged and untagged Layer 2 traffic over a single physical link between two MX Series devices, the connecting interfaces must be configured as trunk ports. A trunk port is designed to carry traffic for multiple VLANs, which it does by using 802.1Q tags to identify the VLAN for each frame. To handle untagged traffic, the native-vlan-id option is configured on the trunk interface. Any untagged frames received on this interface are then associated with the specified native VLAN. This configuration effectively allows the single link to multiplex traffic from multiple tagged VLANs and one untagged VLAN.

A. Access ports are designed to carry traffic for a single VLAN and do not support multiple tagged VLANs. The native VLAN option is a feature of trunk ports.

C. An access port, even with a voice VLAN, is not designed to carry traffic for multiple general-purpose tagged VLANs, which is a primary function of a trunk port.

D. The voice VLAN option is a specialized feature, typically for access ports, to prioritize voice traffic. The standard mechanism for handling untagged traffic on a trunk is the native-vlan-id setting.

1. Juniper Networks TechLibrary, Junos OS, Layer 2 Switching and VLANs for Routing Devices. Configuring VLANs on Interfaces (ELS). This document explains the different interface modes. It states, "Trunk—Configure a trunk interface to accept packets with an 802.1Q tag... To accept untagged packets on a trunk interface, you must configure a native VLAN ID." This directly supports the use of a trunk port with a native VLAN.

2. Juniper Networks TechLibrary, Junos OS, Layer 2 Switching and VLANs for Routing Devices. Example: Configuring a Trunk Port to Accept Untagged Packets. This configuration example demonstrates the exact scenario. It shows setting the port-mode to trunk and then configuring the native-vlan-id on that same interface to process untagged packets. The commands shown are set interfaces ge-fpc/pic/port unit 0 family ethernet-switching port-mode trunk and set interfaces ge-fpc/pic/port unit 0 family ethernet-switching native-vlan-id .

3. Juniper Networks TechLibrary, Junos OS, Layer 2 Switching and VLANs for Routing Devices. Understanding Bridging and VLANs on Switches. This guide defines the interface types: "Access interfaces admit untagged packets... Trunk interfaces multiplex traffic from multiple VLANs and discriminate among them by their VLAN tags." This clarifies why an access port (Options A and C) is incorrect for carrying multiple tagged VLANs.

The Explicit Route Object (ERO) is used in RSVP Path messages to specify a particular path that a Label-Switched Path (LSP) must take. The ingress Label Switching Router (LSR) includes the ERO, which contains a list of specific routers (hops) for the path. This allows network administrators to explicitly control the route, overriding the path that would otherwise be selected by the Interior Gateway Protocol (IGP). This capability is fundamental to MPLS Traffic Engineering (TE).

A. The record route object (RRO) is used to record the actual path that an LSP traverses, not to influence its selection beforehand.

C. The hop object (PHOP/NHOP) identifies the previous or next hop router in the path for message processing, but does not define the entire explicit route.

D. The session object identifies the specific data flow (e.g., destination address, protocol) for which a reservation is being made, not the network path.

---

1. Juniper Networks TechLibrary, MPLS Applications User Guide, "RSVP Traffic Engineering." This guide states, "To establish a TE LSP, the ingress router must determine the path to the egress router. The path can be explicit. An explicit path is a list of routers, specified in the ERO, that the LSP must traverse." This directly links the ERO to path selection.

2. Juniper Networks TechLibrary, Junos OS Routing Protocols Library for Routing Devices, "RSVP Objects." This document defines the key RSVP objects. It describes the Explicit Route Object (ERO) as being "carried in Path messages. It consists of a sequence of hops that the LSP must traverse." It also defines the Record Route Object (RRO) as being used to "record the actual route taken by the LSP," clearly distinguishing its function from the ERO.

3. Juniper Networks Day One, "This Week: An Expert Packet Walkthrough on the Junos OS," Chapter 4: MPLS. This book explains, "The ingress LER will insert an Explicit Route Object (ERO) into the RSVP Path message... The ERO contains the list of hops that the LSP must traverse." This reinforces the ERO's role in dictating the path.

Generic Routing Encapsulation (GRE) encapsulates payload packets within an outer IP packet for transport over an IP network. For this transport to succeed, the device originating the tunnel (the source endpoint) must have a valid route in its routing table to the IP address of the tunnel's destination endpoint. This ensures the outer IP packet can be forwarded correctly.

Within Juniper's Junos OS, tunnel interfaces such as GRE (gr-) are implemented as logical interfaces that have specific limitations. A key limitation is that they support the configuration of only a single logical unit, which must be unit 0.

B. GRE tunnels support multiple logical units per interface

This is incorrect. Junos OS explicitly restricts GRE (gr-) interfaces to a single logical unit (unit 0).

C. GRE tunnels are stateful by default

This is incorrect. GRE is a stateless tunneling protocol as defined in its RFC. It does not track connection states or sessions; it only provides an encapsulation mechanism.

1. Juniper Networks TechLibrary, Junos OS Interfaces Configuration Guide for Routing Devices, "Tunnel Services Interfaces Overview": This document states, "For gr-, ip-, pe-, and pd- interfaces, you can configure only one logical unit, unit 0." This directly supports answer D and refutes answer B.

2. Juniper Networks TechLibrary, Routing Policies, Firewall Filters, and Traffic Policers Feature Guide, "Example: Configuring a GRE Tunnel Between Two Routers": In the configuration steps, the guide specifies, "Configure a static route to the remote tunnel endpoint address..." This demonstrates the requirement for a valid route to the remote endpoint for the tunnel to function, supporting answer A.

3. IETF RFC 2784, "Generic Routing Encapsulation (GRE)", Section 1, Introduction: The RFC describes GRE as a mechanism for "encapsulation of an arbitrary protocol over another arbitrary protocol." The specification details a simple header format without any fields or procedures for state management, confirming its stateless nature and refuting answer C.

When a packet matches a static route configured with the reject next-hop action, the Junos device performs two actions: it drops the packet and sends an ICMP "Destination Unreachable" message back to the source host. This behavior explicitly informs the source that the destination is unreachable, which is distinct from the discard action that drops the packet silently without any notification. The reject option is commonly used to enforce routing policies and provide immediate feedback about unreachable networks.

A. The system silently drops the packet.

This describes the discard next-hop action, not reject. Reject actively sends an ICMP notification.

B. An ICMP message is sent to the source and the packet is forwarded.

This is incorrect because the primary function of the reject action is to stop the packet from being forwarded.

D. The packet is forwarded and the packet is marked as rejected in the header.

This is incorrect. The packet is dropped, not forwarded, and there is no standard mechanism to "mark" a packet as rejected in its header for forwarding.

1. Juniper Networks TechLibrary, Junos OS Routing Protocols Library for Routing Devices: In the section describing static routing options, the reject next-hop is defined. It states, "If the routing device receives a packet for which the destination address matches a route that has reject as the next hop, the routing device drops (discards) the packet and sends an ICMP destination unreachable message to the source."

Source: Junos OS Routing Protocols Library for Routing Devices, "Static Route Options" section.

2. Juniper Networks TechLibrary, static (Protocols) Configuration Statement: The configuration guide for static routes explicitly lists the possible next-hop actions.

Source: static (Protocols) Statement Reference, under [edit routing-options static route destination-prefix]. The documentation for the reject option specifies: "Reject the packet and send an ICMP unreachable message."

The network diagram shows two distinct BGP peering types. The connection between R1 (AS 65001) and R4 (AS 65002) is an External BGP (eBGP) session because the peers are in different Autonomous Systems. The standard and most common practice for eBGP between directly connected routers is to establish the peering session using the IP addresses of the physical interfaces.

The connections between R1, R2, and R3 are Internal BGP (iBGP) sessions, as they all reside within the same Autonomous System (AS 65001). For iBGP, the best practice is to use loopback interface addresses for peering. This design provides stability, as the loopback interface is always active, and the iBGP session will remain up as long as the underlying Interior Gateway Protocol (IGP) can maintain reachability between the loopback addresses.

A. Using loopback addresses for a standard, single-link eBGP session is not a best practice and requires additional multihop configuration, as the loopbacks are not directly connected.

D. Using physical interface addresses for iBGP is not a resilient design. If the specific physical interface used for peering fails, the iBGP session will terminate, even if an alternate path exists.

1. Juniper Networks TechLibrary, BGP Overview: "For internal BGP (IBGP), peer sessions are generally configured between the loopback interface addresses of the neighboring routers... For external BGP (EBGP), peer sessions are almost always configured between the interface addresses of the directly connected neighboring routers."

Source: Juniper Networks Documentation, Junos OS Routing Protocols Library for Routing Devices, "BGP Overview".

2. Juniper Networks Day One Guide: Deploying BGP in the Enterprise, Page 18: "It is a best practice to configure iBGP to peer between loopback addresses... This provides stability for the iBGP peering session because loopback interfaces are always available as long as the router is operating. If a physical interface used for peering fails, the iBGP session remains active if the IGP finds an alternate path to the iBGP peer."

Source: Day One: Deploying BGP in the Enterprise, Chapter 2, "BGP Basics", Page 18.

3. Juniper Networks TechLibrary, Example: Configuring an EBGP Connection Between Directly Connected Peers: This configuration example demonstrates the standard practice of using physical interface IP addresses for the neighbor statement in an eBGP configuration.

Source: Juniper Networks Documentation, Junos OS Routing Protocols Library for Routing Devices, "Example: Configuring an EBGP Connection Between Directly Connected Peers".

In Junos OS, if an IS-IS level is not explicitly configured for a specific interface, that interface inherits the level setting from the global [edit protocols isis] configuration. The default behavior for a Juniper router, when IS-IS is enabled without a specific level designation at the global level, is to function as a Level 1 and Level 2 (L1/L2) router. Therefore, since the ge-0/0/0.0 interface in the exhibit has no specific level configured, it inherits the default L1/L2 behavior and will participate in both Level 1 and Level 2 adjacencies and routing.

B. The ge-0/0/0.0 interface will act as an L2 interface only

This is incorrect. The interface would only be L2 if level 2 were explicitly configured globally or on the interface itself.

C. The ge-0/0/0.0 interface will act as an L1 interface only

This is incorrect. The interface would only be L1 if level 1 were explicitly configured globally or on the interface itself.

D. The ge-0/0/0.0 interface will not be assigned to a level

This is incorrect. An interface actively participating in IS-IS must be assigned to at least one level; it cannot be unassigned.

---

1. Juniper Networks TechLibrary, Junos OS 22.4. Configuration Statements, level (Protocols IS-IS). "If you do not include the level statement, Level 1 and Level 2 are enabled." This confirms the default global behavior. Link

2. Juniper Networks TechLibrary, Junos OS 22.4. Configuration Statements, level (IS-IS Interface). "If you do not include this statement, the levels configured at the [edit protocols isis] hierarchy level are inherited." This confirms that the interface inherits the global setting. Link

3. Juniper Networks Day One Guide. This is IS-IS, Deciphering the Seven-Part Puzzle. Page 14, Chapter 2. "By default, a Juniper Networks router is configured as a Level 1/Level 2 router." This source corroborates the default router type. Link

The primary function of a virtual-router routing instance in Junos OS is to create a separate and isolated routing table (e.g., instance-name.inet.0) and a corresponding forwarding table. This effectively partitions a single physical router into multiple independent logical routers. Each virtual-router instance has its own interfaces, routing protocol configurations, and policies, operating independently from the main inet.0 routing table and other instances. This is used for non-VPN network segmentation scenarios where traffic from different logical networks must be kept separate.

A. This is a general goal of network segmentation, which routing instances facilitate, but it does not describe the specific mechanism of a virtual-router instance.

B. This is incorrect. Junos OS supports multiple routing instance types, including vrf, forwarding, l2vpn, and vpls, among others.

C. The vrf (Virtual Routing and Forwarding) instance type is specifically used for Layer 3 VPN implementations, as it includes necessary BGP policies like route targets.

1. Juniper Networks TechLibrary, Junos OS Routing Protocols Library for Routing Devices, "Routing Instances Overview."

Section: "Routing Instance Types"

Content: This document explicitly states for the virtual-router type: "In this type of instance, there is a one-to-one mapping between an interface and a routing instance. Each virtual-router instance has its own routing and forwarding tables." This directly supports the correct answer (D). It also describes the vrf type as being used for Layer 3 VPNs, invalidating option C. The list of multiple instance types in this document invalidates option B.

2. Juniper Networks TechLibrary, Junos OS Routing Protocols Library for Routing Devices, "Example: Configuring a Virtual Router Routing Instance."

Section: "Overview"

Content: The overview explains that a virtual router instance "isolates traffic" and "has its own routing table." This reinforces that the core function is the creation of separate routing and forwarding planes.

3. Juniper Networks Day One Library, "This Week: An Introduction to Logical Systems and Virtual Routers."

Section: "Virtual Routers"

Content: This guide details that a virtual router "creates a separate routing and forwarding table" and is a method of partitioning a device into multiple, independent, logical routers for non-VPN scenarios. This confirms the purpose described in option D.

In a Spanning Tree Protocol (STP) environment, the switch with the lowest Bridge ID is elected as the root bridge. The Bridge ID is a combination of a configurable bridge priority and the switch's MAC address. All switches have a default priority of 32768. The scenario indicates the older Switch D became the root because it has a lower MAC address than the other switches.

To force Switch A to become the root bridge, its Bridge ID must be made the lowest in the network. The most reliable method is to configure a bridge priority on Switch A that is lower than the default. Option B sets the priority on Switch A to 4096 (4k), which is lower than 32768, ensuring it will win the root bridge election.

A: While setting the priority to 0 would make Switch A the root, this command uses the stp hierarchy for the legacy Spanning Tree Protocol, whereas rstp is the modern standard.

C: Setting Switch D's priority to a high value (61440) prevents it from becoming root but does not guarantee Switch A will be elected; another switch (B or C) could still have a lower MAC address than A.

D: This command sets Switch D's priority to the default value of 32768. This configuration would result in no change, and Switch D would remain the root bridge.

1. Juniper Networks TechLibrary, Junos OS Documentation, "Understanding Spanning-Tree Protocols": This document explains the root bridge election process. It states, "The switch with the lowest bridge ID is elected as the root bridge... The bridge ID contains two components, the bridge priority and the MAC address of the switch... If the bridge priorities are equal, the switch with the lowest MAC address is elected as the root bridge." This confirms why Switch D became root.

2. Juniper Networks TechLibrary, Junos OS Documentation, "Configuring Spanning-Tree Protocols": This guide details the configuration syntax. In the "Configuring the Root Bridge" section, it shows the command set protocols rstp bridge-priority . It also specifies, "The priority value can be from 0 through 61440, in increments of 4096. The default is 32768." This validates the command in Option B as the correct method to manually set a new root bridge.

3. Juniper Knowledge Base, Article KB15133, "[EX] STP & RSTP - Root bridge selection process": This article reinforces the election logic. It states, "To influence the Root Bridge election, you can change the Bridge Priority. The lower the Bridge Priority, the more likely the switch will be selected as the Root Bridge." This supports the strategy of lowering the priority on the desired root, as done in Option B.

The exhibit shows that Area 1 is connected to the backbone (Area 0) and also contains an Autonomous System Boundary Router (ASBR) that is redistributing routes from an external BGP domain. A standard stub area or a totally stubby area cannot contain an ASBR. The Not-So-Stubby Area (NSSA) is a specific OSPF area type designed for this exact scenario. An NSSA blocks Type 5 LSAs (external routes) from entering from other areas but allows an internal ASBR to inject external routes as Type 7 LSAs. The Area Border Router (ABR) then translates these Type 7 LSAs into Type 5 LSAs for propagation into the backbone.

A. stub area: A stub area is not permitted to contain an ASBR, which is clearly present in Area 1.

B. totally stubby area: Like a standard stub area, a totally stubby area cannot contain an ASBR.

D. backbone area: The backbone area is designated as Area 0. A network can only have one OSPF backbone area.

1. Juniper Networks TechLibrary, Junos OS Routing Protocols Library for Routing Devices, "OSPF Area Types": In the description for "Not-So-Stubby Areas," it states, "Not-so-stubby areas (NSSAs) are similar to stub areas in that they do not accept OSPF external advertisements. However, NSSAs can import external routes into the OSPF routing domain and inject them into the NSSA and from the NSSA into the OSPF backbone." The description for "Stub Areas" explicitly states, "...nor can a stub area contain an autonomous system boundary router (ASBR)." This directly supports the choice of NSSA and the exclusion of stub/totally stubby areas.

2. IETF RFC 3101, "The OSPF Not-So-Stubby Area (NSSA) Option," Section 1, Introduction: "This memo defines a new optional type of OSPF area, called a Not-So-Stubby Area (NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion." This foundational document defines the purpose of an NSSA, which matches the requirement in the exhibit.

The Junos OS routing process selects the active route for the forwarding table based on the lowest route preference value when comparing routes to the same destination prefix.

In this scenario, two protocols are configured to provide a route to the 10.3.0.0/24 prefix:

1. OSPF: The preference for all OSPF-learned routes is explicitly set to 5.

2. MPLS: The install statement under the LSP R1-to-R6 injects a route for 10.3.0.0/24 into the inet.0 routing table with an explicit preference of 7.

Since the OSPF preference (5) is lower than the MPLS LSP's preference (7), the OSPF-learned route will be selected as the active route. Consequently, traffic destined for 10.3.0.1 will be forwarded using the OSPF next-hop, not the LSP. The active route entry in the routing table will show a preference of 5.

A. Traffic destined to 10.3.0.1 will use the R1-to-R6 LSP as a next hop.

This is incorrect because the OSPF route has a better (lower) preference value (5 vs. 7) and will be the active route used for forwarding.

D. The active 10.3.0.0/24 prefix installed in the route table will have a route preference of 7.

This is incorrect because the active route is the one learned via OSPF, which has a preference of 5. The MPLS-installed route with preference 7 will be inactive.

1. Junos OS Routing Protocols Library for Routing Devices - Understanding Route Preference Values: This document states, "The Junos OS routing protocol process selects the active route by choosing the route with the lowest preference value." It also lists default preferences, which are overridden in the provided configuration. (Reference: Junos OS Documentation, Routing Protocols Library, "Route Preferences and BGP Communities," section "Understanding Route Preference Values").

2. MPLS Applications User Guide - Configuring Static LSPs: This guide details the install statement under [edit protocols mpls label-switched-path lsp-name]. It confirms that this statement installs a prefix into the forwarding table and that the preference option sets the preference value for this installed route. The default preference is 7, which is also the value configured in the exhibit. (Reference: Junos OS Documentation, MPLS Applications User Guide, "Configuring Basic MPLS," section "Configuring Static LSPs").

3. Junos OS Routing Protocols Library for Routing Devices - preference (Protocols OSPF): This document explains that the preference statement under [edit protocols ospf] configures the preference for all routes learned by OSPF. The configured value of 5 will be used for route selection. (Reference: Junos OS Documentation, Routing Protocols Library, "OSPF Command Reference," section "preference (Protocols OSPF)").