Free JN0-650 Practice Test Questions 2026

Explanation:

C is correct because LLDP-MED (Link Layer Discovery Protocol
- Media Endpoint Discovery) is an extension to standard LLDP specifically designed for communication between network switches and endpoint devices such as IP phones, cameras, and wireless access points . One of its key features is the Power Management TLV (Type-Length-Value), which enables advanced Power over Ethernet negotiation. When an LLDP-MED capable device connects to an EX Series switch, it can communicate its exact power requirements to the switch, allowing dynamic allocation of PoE power based on the device's needs rather than relying on static power classes . This optimizes the switch's power budget and ensures devices receive only the power they actually require.

Why A is incorrect: The statement "LLDP only operates on interfaces configured for Layer 2" is false. LLDP is a Layer 2 protocol that runs over the data-link layer, but it is not restricted to interfaces configured exclusively for Layer 2 switching. LLDP operates on physical interfaces regardless of whether they are configured for Layer 2 or Layer 3 operations . It discovers neighbors and advertises information about the device itself, not about the Layer 2/Layer 3 configuration of the interface.

Why B is incorrect: EX Series devices do not flood LLDP frames across a Layer 2 domain to calculate network topology. LLDP is a neighbor discovery protocol that operates on a point-to-point basis—each device communicates directly with its immediate neighbors only. LLDP frames are not flooded; they are transmitted to a specific multicast MAC address (01:80:C2:00:00:0E) and are not forwarded by switches beyond the directly connected link . Topology calculation using LLDP would require central collection of neighbor information (e.g., via a network management system), not flooding.

Why D is incorrect: LLDP-MED does not focus on discovering network connectivity devices like routers and switches. That is the function of standard LLDP. LLDP-MED is specifically designed for media endpoint devices such as IP phones, video conferencing systems, and other voice/video endpoints . LLDP-MED extends LLDP with additional TLVs for VoIP applications, including network policy discovery (VLAN, CoS, DSCP), power management, inventory management, and location information for emergency services (e.g., E911) .

References:

Juniper Networks Documentation: LLDP-MED power negotiation capabilities on EX Series switches

Cisco Configuration Guide: LLDP-MED Power Management TLV for dynamic power allocation

Explanation:

MVRP (Multiple VLAN Registration Protocol) is the IEEE 802.1ak standard that dynamically manages VLAN registration information across a Layer 2 network. When enabled on trunk interfaces, MVRP allows switches to automatically:

Dynamically create VLANs based on declarations from neighboring switches
Prune VLANs when they are no longer needed by any switch in the network
Propagate VLAN membership information only across trunk links that require specific VLANs

This simplifies VLAN management by eliminating the need to manually configure the same VLANs on every switch's trunk ports. When a switch declares a VLAN (because it has an access port in that VLAN), MVRP carries that declaration across trunk interfaces, and only trunk interfaces that need that VLAN will dynamically register and carry its traffic.

Why other options are incorrect

A. Enable GVRP on access interfaces – Incorrect. GVRP (GARP VLAN Registration Protocol) is an older, less robust protocol than MVRP. Even if GVRP were used, access interfaces do not need dynamic VLAN registration because they are statically assigned to VLANs. Dynamic registration is designed for trunk links between switches.

B. Enable MVRP and GVRP on all interfaces– Incorrect. Running both protocols concurrently is unnecessary and may cause conflicts. MVRP is the successor to GVRP and is the recommended protocol for Juniper EX Series switches. Additionally, enabling either protocol on access interfaces serves no practical purpose.

D. Enable MVRP on access interfaces – Incorrect. Access interfaces connect to end devices (servers, workstations) that do not participate in VLAN registration protocols. Enabling MVRP on access interfaces provides no benefit and may cause unnecessary processing overhead.

References:
Juniper TechLibrary – MVRP: "MVRP dynamically registers and deregisters VLANs on trunk interfaces"
IEEE 802.1ak – Multiple Registration Protocol (MRP) and MVRP specifications
JNCIP-ENT study guide – Layer 2 protocols: MVRP for dynamic VLAN management and pruning

Explanation:

A. Separate BPDUs are flooded for each VSTP enabled VLAN.
– Correct. VLAN Spanning Tree Protocol (VSTP) operates on a per‑VLAN basis. For each VLAN enabled for VSTP, the switch generates and floods separate BPDUs specific to that VLAN. This allows different VLANs to have different spanning tree topologies, including independent root bridges, port roles, and states.

D. VSTP supports up to 253 unique spanning tree topologies.
– Correct. Juniper EX Series switches support up to 253 VSTP instances (VLANs) simultaneously. This limit accounts for system resource constraints (CPU and memory), as each VSTP instance maintains its own spanning tree state machine, timers, and BPDU processing.

E. A separate spanning tree instance is generated for each VLAN.
– Correct. The core principle of VSTP is to create an independent spanning tree instance per VLAN. Unlike RSTP (which uses a single instance for all VLANs) or MSTP (which maps multiple VLANs to fewer instances), VSTP dedicates one spanning tree topology per VLAN, providing maximum flexibility at the cost of higher resource consumption.

Why B and C are incorrect

B. VSTP is incompatible with RSTP.
– Incorrect. VSTP is actually an extension of RSTP (IEEE 802.1w) and operates on a per‑VLAN basis. VSTP uses the same rapid convergence mechanisms as RSTP, including proposal/agreement handshake and edge port detection. VSTP is fully compatible with RSTP when VLAN consistency is maintained across the Layer 2 domain. The statement confuses "incompatible" with "different scope" (single instance vs. multiple instances).

C. VSTP is enabled by default on EX Series switches.
– Incorrect. By default, Juniper EX Series switches run RSTP (Rapid Spanning Tree Protocol) on all interfaces. VSTP must be explicitly configured under [edit protocols vstp] after disabling RSTP or other spanning tree protocols. VSTP is not the default STP mode.

References:

Juniper TechLibrary – VSTP: "VSTP runs a separate spanning tree instance per VLAN, with up to 253 instances supported"

Juniper EX Series Configuration Guide – Spanning Tree Protocols: RSTP is default, VSTP requires explicit configuration

Explanation:

To prevent other OSPF routers from forwarding transit traffic through a router during maintenance, you need to configure the overload feature (also known as stub router or max-metric). When enabled, the router signals to neighbors that it should not be used for transit traffic, while still allowing traffic destined for its directly connected networks.

Why other options are incorrect

A. traffic-engineering
– Incorrect. MPLS traffic engineering is used to influence path selection based on constraints like bandwidth or administrative groups, not to temporarily prevent a router from carrying transit traffic during maintenance. This is a fundamentally different operational purpose.

C. preference
– Incorrect. The preference parameter adjusts the administrative distance of OSPF routes relative to other routing protocols. It does not signal other OSPF routers to avoid using a router for transit traffic. This controls local route selection only.

D. spf-options
– Incorrect. The spf-options stanza configures SPF calculation parameters such as delay timers or rapid updates. It does not provide the overload/stub router advertisement functionality needed to repel transit traffic during maintenance .

References:
Juniper TechLibrary – overload configuration for repelling transit traffic
RFC 3137 – OSPF Stub Router Advertisement (overload mechanism)
Juniper CLI reference – set protocols ospf overload

Explanation:

To make 10GbE interfaces preferred over 1GbE in OSPF, you need lower OSPF cost on the faster links because OSPF always prefers the path with lowest cost.

A. Define the reference bandwidth as 10G, which will assign the 1GbE interfaces a higher cost. – Correct.
OSPF cost = reference‑bandwidth / interface speed. Default reference (100M) gives both 1G and 10G a cost of 1 (no preference). Changing reference to 10G makes 1GbE cost = 10,000/1,000 = 10 and 10GbE cost = 10,000/10,000 = 1, so 10GbE is preferred.

D. Manually assign the interface metric for each 1GbE interface to be higher than the 10GbE interfaces. – Correct.
Manual metric overrides automatic calculation. Setting a higher cost (e.g., 10) on 1GbE and a lower cost (e.g., 1) on 10GbE directly ensures faster links are preferred.

Why B and C are incorrect

B. Manually assign higher metric to 10GbE interfaces
– Incorrect. This gives faster links a higher cost than slower links, causing OSPF to prefer the slower 1GbE paths—the opposite of what is required.

C. Define reference bandwidth as 1G
– Incorrect. Formula: 1G reference gives 1GbE cost = 1,000/1,000 = 1 and 10GbE cost = 1,000/10,000 = 0.1 (rounded up to 1). Both become 1, so no preference is achieved. Reference must be higher than the fastest link to create differentiation.

References

Juniper TechLibrary – OSPF cost calculation: reference-bandwidth adjusts per‑interface cost based on link speed

RFC 2328 (OSPFv2) – Section 12.3: Cost is inversely proportional to link speed; lower cost is more preferred

Explanation:

Local Preference (LocalPref) is a BGP attribute used to influence outbound traffic path selection within an autonomous system. A higher LocalPref value is more preferred. To make Provider A (R1) the preferred path for all Internet traffic when available, you must ensure routes from R1 have a higher LocalPref than routes from R2.

A. Use a routing policy to set the local preference attribute value higher for the routes that are learned by R1.
– Correct. Increasing LocalPref on routes from R1 makes them more preferred than routes with default or lower LocalPref from R2.

C. Use a routing policy to set the local preference attribute value lower for the routes that are learned by R2.
– Correct. Decreasing LocalPref on routes from R2 makes them less preferred, so R1 routes (with default or higher LocalPref) win.

Both actions achieve the same goal: routes from R1 have higher relative LocalPref than routes from R2. You can do one or the other, or both.

Why B and D are incorrect

B. Set LocalPref higher for routes learned by R2
– Incorrect. This would make R2 more preferred, directing traffic toward Provider B instead of Provider A.

D. Set LocalPref lower for routes learned by R1 – Incorrect. This would make R1 less preferred, again steering traffic away from Provider A.

References

Juniper TechLibrary – BGP Local Preference: Higher value is more preferred for outbound route selection

RFC 4271 (BGP-4) – Section 5.1.1: Local Preference attribute

JNCIP-ENT study guide – BGP path selection: LocalPref is the first tie-breaker after highest weight (Cisco) or after next-hop reachability (Juniper)

Explanation:

EVPN (Ethernet VPN) signaling requires a control plane protocol to exchange MAC, IP, and Ethernet segment reachability information between VTEPs. On EX Series switches in a VXLAN EVPN deployment, this signaling is performed exclusively by MP‑BGP (Multiprotocol BGP) using the evpn address family (AFI 25, SAFI 70). This BGP session is typically established as an EBGP overlay network between loopback interfaces of VTEPs, independent of the underlay routing protocol.

The underlay (OSPF, IS‑IS, or static) provides only IP reachability between VTEP loopbacks. It does not and cannot carry EVPN routes. The overlay BGP EVPN control plane is mandatory for EVPN to function.

Why A, B, and C are incorrect

A. OSPF underlay network
– Incorrect. OSPF can provide underlay IP connectivity (VTEP loopback routes), but it has no mechanism to carry EVPN NLRI. OSPF is completely unaware of EVPN route types.

B. IS‑IS underlay network
– Incorrect. Same limitation as OSPF: IS‑IS handles only underlay routing. EVPN signaling requires BGP, not IS‑IS.

C. MPLS overlay network
– Incorrect. MPLS is a data plane encapsulation method, not a control plane signaling protocol. While EVPN can run over MPLS instead of VXLAN, BGP is still the signaling protocol. Additionally, EX Series switches typically use VXLAN for EVPN overlays, not MPLS.

References

Juniper TechLibrary – EVPN/VXLAN: "EVPN uses MP‑BGP with address family evpn for control plane signaling"

RFC 7432 (EVPN) – Section 7: BGP EVPN NLRI definition

RFC 8365 (NVO3) – Overlay control plane requirements

Explanation:

To enable Juniper switches to interoperate with Cisco switches running PVST+ (Per-VLAN Spanning Tree Plus), you must configure VSTP (VLAN Spanning Tree Protocol) on the Juniper devices.

Cisco's PVST+ and Rapid-PVST+ are proprietary per-VLAN spanning tree protocols that are not IEEE standards . Juniper developed VSTP specifically to provide compatibility with Cisco's PVST+ implementation, allowing both vendors' switches to coexist in the same Layer 2 network . Juniper's official documentation explicitly states: "If your EX Series or QFX Series switch interoperates with a Cisco device running Rapid per VLAN Spanning Tree (Rapid PVST+), we recommend that you enable both VSTP and RSTP on the EX Series or QFX Series interface" .

Why other options are incorrect

A. RPVST+
– Incorrect. RPVST+ (Rapid Per-VLAN Spanning Tree Plus) is Cisco's proprietary protocol. Juniper switches do not run RPVST+ natively; they use VSTP to interoperate with it .

B. MSTP
– Incorrect, though it can work. MSTP (Multiple Spanning Tree Protocol) is an IEEE standard (802.1s) that interoperates with Cisco's MST implementation. However, when Cisco switches run PVST+ (not MST), MSTP and PVST+ have well-documented interoperability issues. The PVST Simulation feature can cause ports to block when receiving differing PVST+ BPDUs because Cisco uses Extended System ID (VLAN ID embedded in Bridge ID), making BPDUs for different VLANs non-identical . While technically possible with careful root bridge configuration, VSTP is the Juniper-recommended and more straightforward solution for PVST+ environments .

D. RSTP
– Incorrect. RSTP (Rapid Spanning Tree Protocol) is VLAN-unaware—it runs a single spanning tree instance for all VLANs. Cisco's PVST+ runs a separate instance per VLAN. These two models are fundamentally incompatible and cannot interoperate directly .

References:

Juniper Networks Documentation – VSTP: Designed for Cisco PVST+ interoperability
Cisco Community – MSTP recommended for mixed environments, VSTP also possible
Network Engineering Stack Exchange – PVST+ vs MSTP compatibility issues

Explanation:

B. Port ge-0/0/0 is enabled and has its maximum power and device class designations statically configured.
– Correct. The show poe interface output shows Max power = 19.5W (L), where (L) indicates a statically configured limit. Class 4 is also manually assigned, overriding dynamic detection. This static mode is used to preserve total power budget.

D. The switch is capable of supplying up to 30 W of power to attached PoE devices.
– Correct. The attached device on ge-0/0/0 is Class 4, which requires PoE+ (802.3at) capability. PoE+ ports can deliver up to 30 W per port, even if a specific port has been administratively limited to 19.5 W.

Why other options are incorrect

A. 60 W capability
– Incorrect. No evidence supports 60 W (PoE‑bt). Class 4 indicates only PoE+ (30 W max per port).

C. Dynamically learned class/power
– Incorrect. Dynamic learning would show default max power (e.g., 30 W for Class 4) without the (L) flag. The (L) and non‑standard 19.5 W value prove static configuration.

References
Juniper TechLibrary – show poe interface: (L) indicates statically configured maximum power
Juniper CLI Reference – Static PoE management mode overrides dynamic class defaults
IEEE 802.3at – PoE+ Class 4 requires 30 W PSE capability per port

Explanation:

VSTP (VLAN Spanning Tree Protocol) has a hard limit on the number of VLANs it can support. On EX Series switches running Junos OS that does not support Enhanced Layer 2 Software (ELS), the maximum is 253 VLANs . When you exceed this limit—as you are with 450 VLANs—some VLANs will not function properly because they are not covered by any spanning-tree protocol.

The solution is to enable RSTP alongside VSTP. RSTP is already enabled by default on EX Series switches . When both protocols are configured concurrently, VSTP handles up to its maximum supported VLANs, while RSTP automatically provides spanning-tree coverage for the remaining VLANs. This is the Juniper-recommended best practice .

Enabling RSTP adds minimal overhead and ensures that all VLANs have a loop-prevention mechanism, resolving the issue.

Why other options are incorrect

A. force-version stp – Incorrect. This forces the spanning-tree version to original IEEE 802.1D STP . It does not increase the VLAN limit or fix the problem.

C. Set max-age to 3600 – Incorrect. Max-age controls how long BPDUs are retained and influences convergence timing . It does not affect how many VLANs VSTP can support.

D. Increase bridge priority to 16k – Incorrect. Bridge priority influences root bridge election , not the number of VLANs that can run VSTP.

References
Juniper Manuals – VSTP limit: 253 VLANs on non-ELS EX Series
Juniper Pathfinder – RSTP and VSTP concurrent configuration support
Juniper Best Practice – "Configure RSTP when you configure VSTP" to cover all VLANs

Explanation:

The question involves the route 203.0.113.0/24 and OSPF LSA types Type 5 (AS External) and Type 7 (NSSA External). Type 7 LSAs are used only in Not-So-Stubby Areas (NSSA) and are translated by the ABR into Type 5 LSAs when they leave the NSSA.

C. R1 will advertise the 203.0.113.0/24 route as an OSPF Type 5 LSA into Area 0 – Correct if:
R1 is an ABR between an NSSA (Area 1) and Area 0.
The route originates as a Type 7 LSA in Area 1 (from R5).
R1, as the ABR, translates Type 7 into Type 5 and floods into Area 0.


D. R5 will advertise the 203.0.113.0/24 route as an OSPF Type 7 LSA into Area 1 – Correct if:
R5 is an ASBR inside an NSSA (Area 1).
By definition, an ASBR in an NSSA injects external routes as Type 7 LSAs, not Type 5.

Why A and B are incorrect

A. R1 advertises Type 7 into Area 0
– Incorrect. Type 7 LSAs never leave an NSSA. They are blocked by ABRs and optionally translated to Type 5.

B. R5 advertises Type 5 into Area 1
– Incorrect. If Area 1 is an NSSA, an ASBR inside it must generate Type 7, not Type 5.

References
RFC 2328 (OSPFv2): Type 5 vs Type 7 behavior
RFC 3101 (NSSA): Type 7 LSAs originate in NSSA; ABR translates Type 7 → Type 5
Juniper TechLibrary: NSSA configuration and LSA types

Explanation:

The prefix-limit BGP parameter allows you to set a maximum number of prefixes that can be accepted from a BGP peer. When the limit is exceeded, the router can take actions such as:

Log a warning (default)
Shut down the BGP session to protect the router from memory exhaustion

This directly addresses the scenario of an incorrectly configured routing policy injecting hundreds of thousands of unwanted routes into the routing table.

Why other options are incorrect

A. damping
– Incorrect. BGP route damping is used to suppress unstable routes that flap (frequently appear and disappear). It reduces churn but does not limit the number of prefixes received.

C. graceful-restart
– Incorrect. Graceful restart allows a BGP session to recover without disrupting forwarding during a control plane restart. It has no effect on the number of prefixes received.

D. advertise-inactive
– Incorrect. This parameter controls whether inactive routes (non-best paths) are advertised to peers. It does not limit prefix count.

References

Juniper TechLibrary – prefix-limit BGP configuration
JNCIP-ENT Study Guide – BGP prefix limiting for route flood protection
RFC 4271 – BGP-4; prefix limits are an implementation-specific feature