JN0-650 Practice Questions

The exhibit shows an external BGP (eBGP) peering session in the Active state. This state indicates that the local router is attempting to establish a TCP connection with its peer but is failing. The configuration uses a local-address (10.10.10.1), which implies peering between loopback interfaces. By default, eBGP packets have a Time-to-Live (TTL) of 1, assuming peers are directly connected. When peering between loopbacks, the peers are typically multiple router hops away. The TTL of 1 causes the packets to be dropped by the first-hop router, preventing the session from establishing. Configuring multihop for the neighbor increases the TTL value, allowing the BGP packets to reach the remote peer.

A. multipath is used for load balancing across multiple equal-cost paths after a BGP session is already established; it does not resolve session establishment issues.

B. The multihop configuration must be applied to the correct neighbor, which is 172.16.1.1 as defined in the configuration, not 10.10.20.1.

C. The address 10.10.10.1 is the local-address of the router itself, not the BGP neighbor. The configuration must target the neighbor's address.

---

1. Juniper Networks TechLibrary, BGP Feature Guide, multihop (BGP): "For external BGP (EBGP) sessions, the peer is assumed to be directly connected by default. If the peer is not directly connected, you must configure multihop EBGP... When you configure multihop EBGP, a time-to-live (TTL) value greater than 1 is used in the IP packet header." (Section: multihop (BGP))

2. Juniper Networks TechLibrary, BGP Feature Guide, "Example: Configuring an EBGP Multihop Session": "By default, EBGP is configured to send packets with a time-to-live (TTL) value of 1. This means that EBGP expects the peer to be directly connected. If the peer is more than one hop away, you must configure multihop BGP." (Section: "Overview")

3. Juniper Networks TechLibrary, CLI Explorer, show bgp summary: The documentation for this command describes the State field. The Active state signifies that "The BGP system is trying to acquire a peer by initiating a TCP connection." A persistent Active state indicates a failure in this process, commonly due to reachability issues like an expired TTL. (Section: show bgp summary | Field Descriptions)

For a private VLAN (PVLAN) to span multiple switches, both the primary and secondary VLANs must be configured on all participating switches. Critically, each secondary VLAN (whether community or isolated) must be configured with its own unique 802.1Q VLAN ID (tag). This tag allows the trunk link between the switches to identify and carry the secondary VLAN traffic. The receiving switch uses this tag to map the traffic to the correct local PVLAN subdomain. Without an associated 802.1Q tag, the secondary VLAN is only a logical construct on the local switch and cannot be propagated across the network.

A. The primary (parent) and secondary VLANs must have different, unique 802.1Q tags to function correctly. Using the same tag would create a configuration conflict.

C. Stripping the 802.1Q tag would make the traffic untagged on the trunk, preventing the receiving switch from identifying which VLAN the frames belong to.

D. Changing the VLAN type from community to isolated alters its communication rules but does not solve the fundamental inter-switch transport and tagging problem.

1. Juniper Networks TechLibrary, Junos OS for EX Series. Understanding and Configuring Private VLANs on EX Series Switches. In the "Configuration Overview" section, it states: "You configure secondary VLANs by creating VLANs and specifying them as either an isolated VLAN or a community VLAN. You must also specify a VLAN ID for each secondary VLAN." This confirms the requirement for a tag.

2. Juniper Networks TechLibrary, Junos OS for EX Series. Example: Configuring a Private VLAN Spanning Multiple Switches. The configuration example explicitly shows the creation of secondary VLANs with unique vlan-id statements (e.g., set vlans community-vlan-101 vlan-id 101). This demonstrates that for inter-switch functionality, the secondary VLAN must have an associated tag.

3. Juniper Networks TechLibrary, Junos OS Switching Configuration Guide. Private VLANs Overview. Under the "PVLANs Spanning Multiple Switches" subsection, the guide explains that for PVLANs to span switches, you must "configure the primary and secondary VLANs on all switches," which inherently means defining them with their respective VLAN IDs.

When configuring a QFX Series switch for an EVPN-VXLAN fabric, two fundamental steps are required to establish the overlay. First, you must enable the EVPN address family within the BGP protocol configuration using the family evpn signaling statement. This allows BGP to act as the control plane, carrying EVPN Network Layer Reachability Information (NLRI) between VTEPs. Second, you must specify that the data plane encapsulation for this EVPN instance is VXLAN. This is accomplished by configuring encapsulation vxlan under the [edit protocols evpn] hierarchy. These two configurations are essential for linking the EVPN control plane to the VXLAN data plane.

B. The family vpls signaling address family is used for the legacy BGP-signaled Virtual Private LAN Service (VPLS) technology, not for EVPN.

D. While the loopback interface must be advertised for VTEP reachability, this can be done using an IGP (like OSPF or IS-IS) or BGP. Using BGP is not a strict requirement.

1. Juniper Networks TechLibrary, "Understanding EVPN with VXLAN Data Plane Encapsulation": This document explicitly states, "To enable EVPN, you include the encapsulation vxlan statement at the [edit protocols evpn] hierarchy level... You must also configure the family evpn address family at the [edit protocols bgp] hierarchy level to enable the exchange of EVPN routes." This directly validates answers A and C.

2. Juniper Networks TechLibrary, "Example: Configuring a Centrally-Routed Bridging Overlay": In the configuration example for a leaf device, the guide shows the commands set protocols bgp group family evpn signaling and set protocols evpn encapsulation vxlan. This demonstrates the practical application of the required configuration statements.

3. Juniper Day One+: "Deploying in the Campus with EVPN Multihoming": In Chapter 3, "Core and Distribution Layer Configuration," the sample configuration for the distribution switches (which act as VTEPs) includes both family evpn signaling under the BGP configuration and encapsulation vxlan under the protocols evpn hierarchy, reinforcing these as essential steps. It also shows an IGP (OSPF) being used for underlay reachability, confirming that BGP is not the only option for advertising the loopback interface.

The exhibit displays two external BGP (EBGP) paths to the prefix 10.10.10.10/32 from two different autonomous systems (AS 65001 and AS 65002). The path from peer 172.16.1.1 is active because it has a lower Multi-Exit Discriminator (MED) value (100) compared to the path from 10.10.20.2 (MED 200).

To enable both paths to be active simultaneously for load balancing, BGP multipath must be configured. For paths from different external ASs, the multipath feature, specifically with the multiple-as option, must be enabled at the BGP group level. This configuration instructs the router to consider paths from different ASs for multipathing and, crucially, to ignore the MED comparison step. Option B correctly identifies the necessary feature (multipath) and the correct configuration hierarchy (ext-peers group).

A. The multipath statement is configured for a BGP group, not as a per-neighbor option in this manner.

C. This option describes a configuration statement but does not specify an action to enable multipathing for both peers.

D. The multipath statement is a group-level configuration, not a keyword applied to a specific neighbor in this syntax.

1. Juniper Networks TechLibrary, BGP Feature Guide, "Understanding BGP Multipath": This document explains the conditions for BGP multipath. For EBGP, it states that paths must have the same cost (MED). It also introduces the concept of multipathing across different ASs, which relaxes this rule. "For external BGP (EBGP) paths, Junos OS selects multiple paths to the same destination if the paths have the same cost, and the BGP multipath feature is enabled. The cost is determined by the value of the MED attribute."

2. Juniper Networks TechLibrary, CLI Explorer, "multipath (Protocols BGP)": This reference details the multipath configuration statement. It specifies the multiple-as option, which is required for this scenario. The documentation states, "Enable load balancing across BGP peers in different autonomous systems... The paths must be of equal AS path length, but the MED is not considered." This confirms that enabling multipath at the group level is the correct approach to ignore the MED difference between the two peers.

3. Juniper Networks TechLibrary, BGP Feature Guide, "Example: Configuring BGP Multipath": This guide provides configuration examples showing that multipath is configured under the [edit protocols bgp group group-name] hierarchy, reinforcing that Option B points to the correct configuration location.

The single-secure supplicant mode is specifically designed to enhance port security by allowing only one end device to authenticate on an 802.1X-enabled port. After the first device successfully authenticates, the switch monitors the port for any other MAC addresses. If a new MAC address is detected, which would occur if a user connected a rogue switch, the port is error-disabled (shut down). This provides the most robust security to meet the requirement of preventing unauthorized devices from piggybacking on the connection.

B. multiple supplicant mode: This mode explicitly allows multiple devices to authenticate on the same port, which is the opposite of the stated security requirement.

C. single supplicant mode: This mode allows only the first device to authenticate, but it does not shut down the port if other devices attempt to connect; it simply denies them access. This is less secure than single-secure.

D. MAC-RADIUS: This is a fallback authentication method for non-802.1X capable devices, not a supplicant mode that controls the number of devices allowed on a port.

1. Juniper Networks TechLibrary, "Understanding 802.1X Multiple Supplicant, Single Supplicant, and Single-Secure Supplicant Modes": This document explicitly defines the behavior of single-secure supplicant mode. It states, "In single-secure supplicant mode, only one supplicant is allowed on the authenticator port... If another supplicant connects to the port and attempts to send traffic, the port is shut down." This directly supports the choice of option A for preventing rogue switch connections.

2. Juniper Networks TechLibrary, "Configuring 802.1X Interface Settings (CLI Procedure)": This guide shows the configuration command set protocols dot1x authenticator interface supplicant single-secure, confirming it as a distinct and configurable mode designed for high-security scenarios. It differentiates this from supplicant single and supplicant multiple.

3. Juniper Day One Guide: "Deploying 802.1X", Page 21, "Supplicant Modes": This guide explains, "Single-secure supplicant mode: This mode is similar to single supplicant mode, but provides a higher level of port security... If another supplicant connects to the port and attempts to send traffic, the port is shut down." This reinforces that single-secure is the correct choice for the highest level of security against unauthorized additional devices.

In an EVPN-VXLAN multihoming active-active scenario, a Designated Forwarder (DF) is elected per Ethernet Segment (ES) to handle Broadcast, Unknown Unicast, and Multicast (BUM) traffic. The DF is the only device that forwards BUM traffic from the VXLAN core to the multihomed device.

In this case, leaf2 is the DF. When server2 sends a broadcast frame, leaf2 forwards it locally to server1. leaf1 is the non-DF, so it is prohibited from forwarding any BUM traffic received from the core to server1. As an optimization, since leaf1 would drop the frame anyway, leaf2 may not forward the BUM frame to leaf1 at all. Consequently, only leaf2 forwards the frame to server1.

A. The broadcast frame will be forwarded to leaf1 and Ieaf2.

This is incorrect. The frame originates from a server connected to leaf2; it is not forwarded to leaf2. It is also not forwarded to leaf1 due to the non-DF role and potential pruning.

D. Only leaf1 will forward the broadcast frame to server1.

This is incorrect. leaf1 is the non-DF for the Ethernet Segment and is explicitly required to drop BUM traffic for that segment to prevent

The exhibit displays the output of the show ospf database command, which lists the Link State Advertisements (LSAs) in the OSPF database. The router with ID 192.168.2.1 is shown advertising Type 1 (Router) LSAs in both Area 0.0.0.0 (the backbone area) and Area 0.0.0.1. By definition, a router that has interfaces in more than one OSPF area, including the backbone, is an Area Border Router (ABR). The output does not show any Type 5 (AS-External) LSAs being originated by 192.168.2.1, which would be necessary for it to be classified as an Autonomous System Boundary Router (ASBR). Therefore, the router is solely an ABR.

A. neither an ABR nor an ASBR: Incorrect. The router advertises LSAs in two separate areas (0.0.0.0 and 0.0.0.1), which is the definition of an ABR.

B. an ASBR: Incorrect. The router is not originating Type 5 (AS-External) LSAs, which is the function of an ASBR. The ASBR in the exhibit is 192.168.1.1.

C. both an ABR and an ASBR: Incorrect. While the router is an ABR, it does not meet the criteria for an ASBR as it is not injecting external routes into OSPF.

1. Juniper Networks TechLibrary, OSPF Overview: "An area border router (ABR) is a router that is attached to more than one OSPF area. ABRs are used to connect the OSPF areas to the backbone area... An autonomous system (AS) boundary router is a router that is running OSPF and is also connected to another network that is running a different routing protocol... AS boundary routers advertise external routes into the OSPF AS by flooding Type 5 LSAs throughout the OSPF AS." This document defines both ABRs and ASBRs, confirming that a router connected to multiple areas is an ABR and a router originating Type 5 LSAs is an ASBR.

2. Juniper Networks TechLibrary, show ospf database: The documentation for the show ospf database command explains that the output lists LSAs grouped by area and type. The Adv rtr field indicates the advertising router's ID. Observing LSAs from the same Adv rtr (192.168.2.1) under different area headings (Area 0.0.0.0 and Area 0.0.0.1) confirms its ABR status. The absence of AS-External LSAs from this router ID confirms it is not an ASBR.

3. RFC 2328, OSPF Version 2, Section 3.1, Router types: "Area border routers: A router that attaches to more than one area... Autonomous system boundary routers: A router that exchanges routing information with routers belonging to other Autonomous Systems." This foundational RFC provides the standard definitions for OSPF router types, which align with the analysis of the exhibit.

The exhibit shows a route reflector (RR) applying an export policy named NHS to its iBGP group. This policy unconditionally changes the BGP next-hop attribute to the RR's own address (next-hop self) for all routes it advertises to its clients. This causes suboptimal routing for routes reflected between iBGP clients, as traffic is unnecessarily sent through the RR.

To resolve this, the next-hop self action should only be applied to routes learned from eBGP peers, not to routes being reflected from one iBGP client to another.

Option A correctly modifies the policy to apply next-hop self only to external (eBGP) routes, preserving the original next-hop for reflected internal (iBGP) routes.

Option D is also a correct approach. By removing the export policy entirely, the RR reverts to its default behavior of not modifying the next-hop attribute when reflecting routes, which also solves the suboptimal routing problem.

B. set protocols bgp group int-group import NHS

Applying an export-oriented action like next-hop self on import is illogical and would not affect the next-hop of routes being advertised to other peers.

C. delete protocols bgp group int-group export IfJHS

This option is incorrect because it targets a non-existent policy named IfJHS. The configured policy is NHS.

1. Juniper Networks Documentation, BGP Feature Guide for Routing Devices, "Understanding BGP Route Reflection": "When a route reflector reflects a route, it does not modify the following path attributes: NEXTHOP, ASPATH, LOCALPREF, MED." This establishes the default behavior that the configured policy is overriding. Removing the policy (Option D) restores this correct default behavior.

2. Juniper Networks Documentation, Routing Policies, Firewall Filters, and Traffic Policers User Guide, "Routing Policy Match Conditions": This guide details the from route-type match condition. It specifies that external matches routes learned from an eBGP peer. Using from route-type external (Option A) correctly limits the next-hop-self action to only those routes originating outside the AS, which is the standard best practice.

3. Juniper Networks Documentation, BGP Feature Guide for Routing Devices, "Example: Configuring Next-Hop Self for BGP": This documentation illustrates that next-hop-self is typically used when advertising routes learned from an eBGP peer into an iBGP mesh. This supports the logic of Option A, which restricts the policy to only external routes.

VLAN Spanning Tree Protocol (VSTP) is a Juniper Networks implementation that creates a separate Spanning Tree instance for each configured VLAN. This per-VLAN approach allows for different logical topologies and enables load balancing by assigning different root bridges for different VLANs. Each VSTP instance sends its own BPDUs, which are tagged with the corresponding VLAN ID, to maintain its unique topology. While the protocol can theoretically support more, on Juniper EX Series switches, VSTP is limited to a maximum of 253 unique spanning tree topologies (instances).

B. VSTP is incompatible with RSTP.

This is incorrect. VSTP is based on the IEEE 802.1w standard, which defines Rapid Spanning Tree Protocol (RSTP), and is fully compatible with it.

C. VSTP is enabled by default on EX Series switches.

This is incorrect. Rapid Spanning Tree Protocol (RSTP) is the default STP protocol enabled on EX Series switches, not VSTP.

1. Juniper Networks TechLibrary, "Understanding VSTP": This document states, "VSTP keeps a separate spanning-tree instance running for each VLAN." (Confirms E). It also explains, "BPDUs for a given VSTP instance are sent to the MAC address 01:00:0c:cc:cc:cd with the corresponding VLAN tag." (Confirms A). The document further specifies, "the maximum number of supported VLANs on EX Series switches is 253 for VSTP." (Confirms D).

2. Juniper Networks TechLibrary, "Spanning-Tree Protocols User Guide for EX Series Switches": In the "Default STP Configuration on Switches" section, it is noted that "By default, the Rapid Spanning Tree Protocol (RSTP) is enabled on all interfaces on EX Series switches..." (Confirms C is incorrect).

3. Juniper Networks TechLibrary, "Example: Configuring VSTP on EX Series Switches": This guide mentions that VSTP is based on the IEEE 802.1w standard (RSTP), which implies compatibility. (Confirms B is incorrect).

The no-loss forwarding class is designed for traffic, such as Fibre Channel over Ethernet (FCoE) or RoCEv2, that cannot tolerate packet loss due to network congestion. To achieve this, two key mechanisms are required. First, Priority-based Flow Control (PFC), defined in IEEE 802.1Qbb, must be enabled. PFC allows a switch to send a pause frame to an upstream device to temporarily halt traffic for a specific priority when its buffer is nearing capacity, thus preventing packet drops. Second, forwarding class sets (also known as priority groups) are used to group one or more lossless forwarding classes. This allows for consistent application of CoS policies, including PFC configuration and bandwidth allocation, to all traffic requiring lossless transport.

A. Use the default scheduler map.

The default scheduler map is not configured for the strict-priority handling and guaranteed bandwidth that lossless traffic requires. A custom scheduler and map are necessary.

D. Use the default drop profile.

The default drop profile is typically tail-drop, which discards packets during congestion. This is antithetical to the goal of a no-loss forwarding class.

1. Juniper Networks TechLibrary, "Understanding CoS Lossless RoCE": This document states, "To achieve lossless transport, you must enable PFC on the 802.1p code points (priorities) of the lossless traffic." It also explains, "You map the lossless forwarding classes to a forwarding class set (a priority group)." This directly supports options C and B.

Source: Juniper Networks Documentation, "Understanding CoS Lossless RoCE", section "Lossless Transport Components".

2. Juniper Networks TechLibrary, "Example: Configuring CoS for a Lossless FCoE Fabric": This configuration example demonstrates the creation of a forwarding-class-set and a congestion-notification-profile to enable PFC. It explicitly shows that default schedulers and drop profiles are not used for the fcoe and no-loss classes.

Source: Juniper Networks Documentation, "Example: Configuring CoS for a Lossless FCoE Fabric", configuration steps.

3. Juniper Networks TechLibrary, "Understanding CoS Priority-Based Flow Control (for QFX and EX Series)": This document details the function of PFC, stating, "PFC is a link-level flow control mechanism... PFC stops traffic for a specified priority... without stopping traffic for other priorities on the link. Pausing traffic for a priority prevents packet loss for that priority during periods of congestion." This confirms the necessity of PFC (Option C) for lossless behavior.

Source: Juniper Networks Documentation, "Understanding CoS Priority-Based Flow Control", section "Overview".