Free JN0-362 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

The BGP Multi-Exit Discriminator (MED) is an optional, non-transitive attribute used to influence how a neighboring Autonomous System (AS) chooses an entry point into your own AS. When an AS has multiple connections to another single AS, it can set different MED values on the routes it advertises over each connection. The receiving AS will prefer the path with the lowest MED value, assuming all other preceding BGP attributes are equal. If a BGP update is received without the MED attribute, the BGP decision process treats its value as 0, which is the most preferred value.

B. BGP routes do not require the MED attribute. It is an optional non-transitive attribute and is not present in all BGP updates.

C. By default, BGP only compares MED values for routes received from the same neighboring AS. Comparing MEDs from different ASs is not standard behavior because their MED policies may not be comparable.

1. Juniper Networks Documentation, BGP Path Selection. In the Junos OS BGP path selection process, step 6 covers the MED attribute. It states, "By default, MED is compared only among paths from the same neighboring AS." It also clarifies, "For the purpose of MED comparison, a missing MED attribute is treated as a MED of 0." This directly supports answers A and D and refutes C.

Source: Juniper TechLibrary, BGP Feature Guide for Routing Devices, "BGP Path Selection".

2. RFC 4271 - A Border Gateway Protocol 4 (BGP-4). This RFC defines the BGP protocol standards.

Section 5.1.4, "MULTIEXITDISC", defines MED as an "optional non-transitive attribute," which refutes option B.

Section 9.1.2.2, "Decision Process", step (d) specifies that MEDs are compared for paths from the same neighboring AS. It also states, "The MEDs of paths from different neighboring ASs are not comparable. As a special case, if a route is received with no MED, it should be treated as if the MED is 0." This supports answers A and D and refutes C.

3. Juniper Networks, JNCIS-SP Study Guide. In the chapter on BGP, the MED attribute is described. It states, "The MED attribute is an optional nontransitive BGP attribute... The MED is only compared between routes learned from the same peer AS." This confirms that MED is optional (refuting B) and that comparison is within a single AS (supporting A, refuting C).

Source: JNCIS-SP Study Guide: JN0-362, Chapter 5: "Border Gateway Protocol (BGP)".

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.

On OSPF broadcast multi-access networks, such as Ethernet, a Designated Router (DR) and a Backup Designated Router (BDR) are elected to optimize the exchange of routing information. This mechanism prevents the need for a full mesh of adjacencies between all routers on the segment. Instead, all non-DR/BDR routers (known as DROTHERs) establish a full adjacency only with the DR and the BDR. The DR and BDR, in turn, form full adjacencies with all other routers on the segment. This hub-and-spoke model for adjacencies reduces LSA flooding and conserves router resources.

A. Routers form an adjacency with the DR in addition to the BDR. The BDR is primarily for redundancy, but an adjacency is required with both.

B. Routers also form an adjacency with the BDR to ensure a fast and seamless takeover if the primary DR fails.

C. This describes a full-mesh topology. The entire purpose of the DR/BDR election on broadcast links is to prevent this inefficient n-squared adjacency scaling.

1. Juniper Networks TechLibrary, Junos OS Documentation. In the "Understanding OSPF Designated Routers" guide, it is stated: "All other routers on the network segment (called DROthers) form adjacencies with only the DR and the BDR." This directly supports the correct answer.

Source: Understanding OSPF Designated Routers, Juniper Networks, Junos OS 22.4.

2. RFC 2328 - OSPF Version 2. This is the defining standard for OSPF. It details the adjacency process on different network types.

Source: Moy, J. (1998). RFC 2328: OSPF Version 2. IETF. Section 10, "The Adjacency-Forming Process," describes how routers on broadcast subnets will only form full adjacencies with the DR and BDR, while remaining in a 2-Way state with other DROTHER routers.

3. Juniper Day One Library. The "Junos for IOS Engineers" guide explains OSPF network types and adjacencies.

Source: "Junos for IOS Engineers", Day One Series, Juniper Networks. Chapter 4: "OSPF", section on "OSPF Network Types", explains that on broadcast networks, adjacencies are formed with the DR and BDR.

Virtual switches are Layer 2 constructs that create separate broadcast domains. To enable communication between these distinct Layer 2 domains on the same router, a Layer 3 routing function is required. In Junos OS, an Integrated Routing and Bridging (IRB) interface serves as the Layer 3 gateway for a Layer 2 domain (such as a VLAN within a virtual switch). By configuring a unique IRB interface for each virtual switch and assigning it an IP address, the router can perform inter-VLAN routing, effectively connecting the two virtual switches and allowing traffic to be routed between them.

A. A VRF (Virtual Routing and Forwarding) instance creates a separate Layer 3 routing table but does not, by itself, create the Layer 3 interfaces needed to connect the Layer 2 domains.

B. A forwarding routing instance is used for filter-based forwarding (policy-based routing), which directs traffic based on filter criteria, rather than establishing the primary Layer 3 connectivity between bridge domains.

C. Using a physical cable is an inefficient and improper workaround for a logical configuration task. The connection between logical entities within a single device should be configured logically.

1. Juniper Networks TechLibrary, Junos OS Switching Configuration Guide, "Understanding Integrated Routing and Bridging": This document states, "Integrated routing and bridging (IRB) provides support for simultaneous Layer 2 bridging and Layer 3 routing on the same interface. IRB enables you to route traffic between a bridged domain and a routed domain... You can also use IRB to route traffic between VLANs." This directly supports using IRBs to connect Layer 2 domains.

2. Juniper Networks TechLibrary, Junos OS Routing Protocols Library, "Routing Instances Overview": This document defines the virtual-switch instance type as being used for "Layer 2 applications" and representing "a Layer 2 network." It also defines the forwarding instance type for "filter-based forwarding applications," distinguishing its purpose from establishing basic connectivity.

3. Juniper Networks TechLibrary, Junos OS Layer 2 Switching and Bridging Library, "Configuring IRB Interfaces": This guide details the configuration steps, showing how an irb interface is explicitly associated with a bridge domain or VLAN. The section "Example: Configuring Routing Between Two Bridge Domains" demonstrates creating two bridge domains and using irb.0 and irb.1 to route between them, which is analogous to connecting two virtual switches.

The configuration snippet defines a BGP group named underlay-ebgp with the type explicitly set to external. This command is used to establish a peering session with a router in a different Autonomous System (AS), which is the definition of an external BGP (eBGP) session.

The local-address statement specifies the source IP address for the BGP TCP session. If this statement is omitted, the Junos OS automatically uses the IP address of the egress interface toward the BGP neighbor as the source address. Assuming the local interface used to reach the neighbor 10.0.0.2 is configured with the IP address 10.0.0.1, the session would establish correctly without this statement, making it not strictly required.

C. The type external command explicitly configures the session as eBGP (external), which is for peering between different Autonomous Systems, not iBGP (internal).

D. This statement is only required when the default source IP address (the egress interface's address) is not the desired one, such as when peering between loopback interfaces.

1. Juniper Networks TechLibrary, Junos OS 22.4 > BGP Feature Guide > Understanding BGP Peering Sessions. This document states, "External BGP (EBGP) peering sessions take place between routers in different ASs... To configure an EBGP session, include the type external statement." This directly supports answer A.

2. Juniper Networks TechLibrary, Junos OS 22.4 > CLI User Guide > Configuration Statements > local-address (Protocols BGP). The documentation explains, "Specify the address of the local end of a BGP session... If you do not include the local-address statement, BGP uses the primary address of the interface best used to forward packets to the neighbor as the local address." This confirms that the statement is not always required, supporting answer B and invalidating D.

3. Juniper Networks TechLibrary, Junos OS 22.4 > BGP Feature Guide > Example: Configuring EBGP. In various configuration examples for directly connected eBGP peers, the local-address statement is often omitted, demonstrating that the session establishes using the directly connected interface addresses by default. This reinforces that the statement is not a mandatory requirement for session establishment.

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

By default, penultimate-hop popping (PHP) removes the MPLS label at the router just before the egress LSR. The egress router then receives a standard IP packet and must rely on the IP header's DSCP bits for Class of Service (CoS) classification. Disabling PHP (by signaling an explicit null label) ensures the MPLS-labeled packet is sent to the egress router. This preserves the MPLS header's Traffic Class (TC/EXP) bits, allowing the egress router to apply CoS policies based on the MPLS header. This enforces a consistent CoS behavior across the entire Label Switched Path (LSP).

A. Disabling PHP alters label operations on the penultimate router; it does not bypass the router. IPv6 tunneling capability is an unrelated feature.

B. The penultimate router forwards packets based on the MPLS label, not the final IP destination. The egress router performs the destination route lookup.

D. A router's support for IPv6 tunneling is irrelevant to the decision to disable PHP, which is a control plane signaling and forwarding plane action within MPLS.

1. Juniper Networks TechLibrary, Junos OS 22.4., "Understanding Penultimate Hop Popping". This document states, "Disabling PHP is useful...if you need to preserve the MPLS label and EXP bits for QoS purposes on the egress router." This directly supports the reasoning that disabling PHP is done to enforce CoS behavior.

2. Juniper Networks TechLibrary, Junos OS 22.4., "MPLS Applications Configuration Guide", section "Configuring an Explicit Null Label for LSPs". The guide explains that configuring no-penultimate-hop-popping causes the router to advertise an explicit null label, which "instructs the penultimate router not to pop the label." This ensures the label, with its CoS information, reaches the egress router.

3. Juniper Networks TechLibrary, Junos OS 22.4., "Class of Service Configuration Guide", section "MPLS and Class of Service Overview". This guide details how MPLS EXP bits are used for CoS. It implicitly supports the need to preserve these bits until the egress router for consistent QoS by explaining their role in packet classification and scheduling within an LSP. Disabling PHP is the mechanism to achieve this preservation on the final hop.

Graceful Routing Engine Switchover (GRES) is the foundational high availability feature that preserves interface and kernel information by synchronizing this state from the primary to the backup Routing Engine. This ensures the Packet Forwarding Engine continues forwarding traffic without interruption during a switchover. Nonstop Active Routing (NSR) works in conjunction with GRES, using the preserved kernel and interface state to also maintain routing protocol sessions and adjacencies with neighbors. Together, GRES and NSR provide a seamless control plane and forwarding plane switchover without being visible to peer devices.

A. Graceful Restart (GR) is a protocol-level mechanism that relies on neighbor cooperation to maintain forwarding during a control plane restart; it does not preserve local kernel state.

B. Nonstop Bridging (NSB) is the Layer 2 equivalent of NSR. While it also relies on GRES, NSR is the specific feature for preserving Layer 3 routing protocol information.

1. Juniper Networks TechLibrary, Junos OS High Availability User Guide, "Understanding Graceful Routing Engine Switchover" section. This document states, "GRES preserves interface and kernel information. Traffic is not interrupted." This directly supports GRES (D) as a correct answer.

2. Juniper Networks TechLibrary, Junos OS High Availability User Guide, "Understanding Nonstop Active Routing" section. This document explains, "Nonstop active routing (NSR) uses the same infrastructure as graceful Routing Engine switchover (GRES) to preserve interface and kernel information." This confirms that NSR (C) is a feature that preserves this information by leveraging GRES.

3. Juniper Networks TechLibrary, Junos OS High Availability User Guide, "Understanding Graceful Restart" section. This source clarifies that Graceful Restart allows a router to continue forwarding packets while routing protocols are restarting, but it relies on "helper" neighbors and does not involve synchronizing kernel state to a backup RE.

Internal BGP (IBGP) is used for peering between routers within the same Autonomous System (AS). Unlike External BGP (EBGP), IBGP peers do not need to be directly connected. As long as there is IP reachability between the peers, typically provided by an Interior Gateway Protocol (IGP), they can be located anywhere within the AS.

To prevent routing loops within the AS, IBGP employs a split-horizon rule by default. This rule states that a BGP route learned from one IBGP peer will not be advertised to another IBGP peer. This mechanism makes IBGP inherently loop-free but necessitates a full mesh of IBGP peers or the use of route reflectors or confederations for full reachability.

B. While using the loopback interface (lo0) for peering is a common best practice for stability, it is not a mandatory requirement. Peering can be established using physical interface addresses.

C. IBGP is specifically designed to support peering between non-directly connected routers, which is a multihop scenario. The protocol inherently supports multihop communication within an AS.

1. Juniper Networks TechLibrary, Junos OS Routing Protocols Configuration Guide, "BGP Overview": This document states, "Internal BGP (IBGP) runs between routers in the same AS... To prevent routing loops, IBGP has a rule that a device does not advertise routes learned from one IBGP peer to other IBGP peers." This supports answers A and D.

2. Juniper Networks TechLibrary, Junos OS Routing Protocols Configuration Guide, "Example: Configuring IBGP Peer Sessions": This section provides configuration examples that demonstrate peering to loopback addresses as a typical design, but does not state it is a requirement. It implicitly confirms that peers can be anywhere in the AS, connected via an IGP. This supports the reasoning against option B and for option A.

3. Juniper Networks TechLibrary, Junos OS Routing Protocols Configuration Guide, "BGP Peering Sessions": This section explains, "For internal BGP (IBGP), peer routers can be anywhere in the local AS and are often not directly connected to each other." This directly supports answer A and refutes answer C.

The IPv6 address fe80::206:aff:fe0e:e01/64 is a link-local address. According to the IPv6 addressing architecture standard (RFC 4291), any address beginning with the fe80::/10 prefix is designated for link-local use. These addresses are automatically generated by Junos OS on any interface where the inet6 family is enabled. They are not routable and are used exclusively for communication on the local network segment, primarily for functions like the Neighbor Discovery Protocol (NDP). The address shown in the exhibit was not manually configured; it was automatically created by the device.

A. The IPv6 loopback address is a specific address, ::1, used for internal testing on the local host, not the address shown.

B. IPv6 multicast addresses are used for one-to-many communication and always begin with the prefix ff00::/8.

C. The statically assigned address is 2001:db8:0:9::/64, which was explicitly configured by the user, not the automatically generated fe80:: address.

1. Juniper Networks TechLibrary, Junos OS IPv6 Configuration Guide for Routing Devices. In the section "Understanding IPv6 Link-Local Addresses," it states, "IPv6 link-local addresses use the prefix fe80::/10. When you enable a routing protocol on an interface, the software automatically enables family inet6 and assigns a link-local address to the interface." This confirms that fe80:: addresses are link-local and automatically assigned.

2. IETF RFC 4291, "IP Version 6 Addressing Architecture". Section 2.5.6, "Link-Local IPv6 Unicast Addresses," defines these addresses: "Link-Local addresses are for use on a single link... Link-Local addresses have the following format: 1111 1110 10 | 54 bits | 64 bits | which corresponds to the prefix FE80::/10." This establishes the standard for identifying link-local addresses.

3. Juniper Networks TechLibrary, Junos OS, show interfaces command reference. The documentation for the show interfaces command shows that for family inet6, both manually configured global addresses and automatically generated link-local addresses will be displayed for an active interface, matching the output in the exhibit.

On MX Series devices, MAC learning is a function of a bridge domain. To disable MAC learning for a specific logical interface, the no-mac-learning statement must be applied to that interface within the bridge domain's configuration hierarchy. The correct syntax is set bridge-domains interface no-mac-learning. Option B correctly applies this configuration, targeting only the ge-0/0/0.0 interface within the data bridge domain, fulfilling the specific requirement of the question.

A. This syntax is incorrect. The no-mac-learning statement is not a valid option directly under the [edit interfaces ge-0/0/0 unit 0] hierarchy.

C. This command disables MAC learning for the entire data bridge domain, affecting all interfaces within it, not just the specified ge-0/0/0.0 interface.

D. This syntax is incorrect. The no-mac-learning statement cannot be applied to a physical interface (ge-0/0/0) at this configuration hierarchy.

1. Juniper Networks TechLibrary, Junos OS 22.4R1. Layer 2 Configuration Guide. "Disabling MAC Learning for a Logical Interface in a Bridge Domain". This document explicitly shows the correct configuration method: [edit bridge-domains data] user@host# set interface ge-1/0/1.0 no-mac-learning, which is the command structure presented in Option B.

2. Juniper Networks TechLibrary, Junos OS 22.4R1. CLI Explorer. no-mac-learning (Bridge Domains). This reference details the statement's usage, specifying it can be configured at the [edit bridge-domains bridge-domain-name] level for the entire domain or at the [edit bridge-domains bridge-domain-name interface interface-name] level for a specific interface. This confirms the validity of Option B's syntax and the invalidity of Option C for the given scenario.

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.

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

Bridge Protocol Data Units (BPDUs) are the control messages exchanged between switches running Spanning Tree Protocol (STP). Their primary purpose is to build a loop-free logical topology. This is achieved through two main functions: first, switches use the Bridge ID information within BPDUs to elect a single root bridge for the entire Layer 2 domain. Second, after the root bridge is elected, switches use the path cost information contained in BPDUs to calculate and determine the shortest (least-cost) path to that root bridge. These two functions are fundamental to establishing the stable, loop-free spanning tree.

A. to exchange MAC addresses: General MAC address learning for forwarding data frames occurs by inspecting the source address of incoming data traffic, not through STP BPDUs.

C. to determine the root-alternate port: The designation of a port as root-alternate (a role in RSTP) is a result of the BPDU exchange and path cost calculations, not the primary purpose of the BPDU message itself.

1. Juniper Networks TechLibrary, Junos OS Documentation. "Understanding Spanning Tree Protocol". In the section "STP Operation," it states, "To establish a loop-free network, STP uses a special data packet called a bridge protocol data unit (BPDU). Switches exchange BPDUs to elect a root bridge and to identify the status of ports that will be used to communicate with the root bridge." This directly supports the election of the root bridge (D) and the process of finding the best path to it (B).

2. Juniper Networks TechLibrary, Junos OS Documentation. "Understanding BPDU Protection for Spanning-Tree Protocols". The document's overview explains, "Spanning-tree protocols use special data frames called bridge protocol data units (BPDUs) to exchange information about bridge IDs and root path costs." This explicitly links BPDUs to the two core components: determining the root bridge (via bridge IDs) and determining the least-cost path (via root path costs).

3. Stanford University, CS 144: Introduction to Computer Networking. "Lecture 6: Switching". In the section on "Spanning Tree Algorithm," the lecture notes detail the contents of a BPDU: "Each BPDU contains: ID of switch sending it, ID of what sender thinks is root, Distance (cost) from sender to root." This confirms that BPDUs carry the necessary information to both determine the root bridge (D) and the least-cost path (B).

The core requirement is to control the specific path an MPLS Label Switched Path (LSP) takes through the network. This capability is known as explicit path routing or constrained-path routing, a fundamental component of MPLS Traffic Engineering (TE). The Resource Reservation Protocol (RSVP) is the signaling protocol designed for this purpose. By implementing RSVP and defining an explicit path (a list of specific router addresses), an administrator can force the LSP to traverse a predetermined route, overriding the default shortest path calculated by the Interior Gateway Protocol (IGP). The Label Distribution Protocol (LDP) does not support this functionality; it is designed to establish LSPs that strictly follow the IGP's best path.

A: Fast Reroute is a resiliency feature that provides a pre-computed backup path; it does not define the primary explicit path for the LSP.

C: The Label Distribution Protocol (LDP) lacks the capability for explicit path routing; it automatically follows the shortest path determined by the IGP.

D: LDP does not have traffic engineering extensions for defining explicit routes. This functionality is a key feature of RSVP-TE, not LDP.

1. Juniper Networks TechLibrary, Junos OS 22.4, MPLS Applications Configuration Guide. In the section "Configuring Constrained-Path LSPs," the documentation states, "To configure a constrained-path LSP, you must enable MPLS and RSVP on the router... An explicitly defined path consists of a sequence of router addresses." This directly confirms that RSVP is used to establish an LSP with a defined, explicit route.

2. Juniper Networks TechLibrary, Junos OS 22.4, MPLS Path Selection. This document clarifies the difference between the protocols: "LDP directs traffic by forwarding packets along the best path to the destination, as determined by the IGP." In contrast, for RSVP, it states, "You can configure LSPs that are explicitly routed. An explicitly routed LSP is one for which you manually specify the path the LSP should take." This highlights why LDP (options C and D) is incorrect for this scenario.

3. Juniper Networks Day One Library, "This Week: An Expert Packet Walkthrough of LDP and RSVP." In the "RSVP-TE" section, it explains, "RSVP-TE allows for the creation of explicitly routed LSPs, where the path is defined by the network administrator rather than being determined by the IGP." This reinforces that RSVP is the correct protocol for meeting the requirement.