Free Juniper JN0-650 Practice Exam with Questions & Answers

In Junos OS routing policies, the order of evaluation and the impact of terminal actions are critical for predictable control.

Immediate Execution (Option D): When a route-filter contains an explicit action like accept or reject within its block, that action is considered terminal if a match is found.

Evaluation Flow: The policy engine processes terms and conditions from top to bottom. If a prefix matches a route-filter that has an embedded accept action, the policy executes that action immediately and stops further evaluation of that specific term. Consequently, any subsequent then clause in the same term is completely ignored.

Best Practice: To ensure a then clause (which might include modifications like changing a preference or community) is executed, the route-filter should be defined without an internal action, allowing the match to fall through to the term ' s common then statement.

The behavior described is the fundamental operational principle of OSPF ' s hierarchical area structure.

LSA Flooding Scope: In OSPFv2, Type-1 (Router) and Type-2 (Network) Link-State Advertisements (LSAs) are restricted to a local area flooding scope . They contain detailed topology information (such as which routers are connected to which links) that is only relevant for calculating the Shortest Path First (SPF) tree within that specific area.

ABR Functionality: Area Border Routers (ABRs), such as R1 in this scenario, act as the gateway between areas. The ABR does not forward Type-1 or Type-2 LSAs from one area to another. Instead, it extracts the prefix information (the network address and mask) from those LSAs and generates a Type-3 (Summary) LSA .

Interarea Reachability: This Type-3 LSA is then flooded into the backbone (Area 0) and subsequently into other non-backbone areas, such as Area 2. This explains why R2 sees an " interarea route " to R3’s network in its routing table and has the corresponding Type-3 LSA in its database, but cannot see the original Type-1 or Type-2 LSAs from Area 1.

Why other options are incorrect: Option A is incorrect because this is standard protocol behavior, not the result of a manual filter. Option B is incorrect as there is no such " disable " feature; the protocol design inherently prevents these LSAs from crossing boundaries. Option C is incorrect because OSPFv3 still uses Type-1 and Type-2 LSAs (renamed but functionally similar for topology), and the prompt specifically identifies the deployment as OSPFv2 .

In Junos OS Class of Service (CoS), a scheduler is the mechanism used to assign resources to the various egress queues on an interface. Specifically, when utilizing a modified deficit round-robin (MDRR) or weighted round-robin algorithm to service these queues, the scheduler ' s behavior is defined by two primary variables:

Transmit Rate (Option A): This variable defines the minimum guaranteed bandwidth for a queue. In the context of a deficit round-robin algorithm, the transmit rate serves as the weight for the queue. Queues with higher transmit rates receive a larger " quantum " of data they can send during each round-robin cycle compared to queues with lower rates.

Buffer Size (Option C): This variable defines the amount of memory (buffer space) allocated to the queue. It ensures that the queue can hold a certain amount of delayed traffic during periods of congestion to prevent immediate packet drops. The buffer size can be configured as a percentage of the total interface buffer or as a temporal value.

Why other options are incorrect:

Layer 2 and Layer 3 fields (Options B & D): These fields are utilized by classifiers (Behavior Aggregate or Multifield) to identify and group traffic into forwarding classes. They are used before the scheduling process begins and do not define the resource allocation of the scheduler itself.

In an EVPN-VXLAN architecture, the network is divided into two distinct planes: the Underlay and the Overlay.

Underlay (IP Fabric): The underlay ' s only job is to provide IP reachability between the loopback addresses of all VTEPs (Virtual Tunnel Endpoints). This is typically achieved using OSPF, IS-IS, or EBGP.

Overlay (EVPN Control Plane): The overlay is responsible for carrying Layer 2 MAC and Layer 3 IP reachability information between switches. EVPN signaling is the standard mechanism for this task.

Protocol Choice (Option D): EVPN uses MP-BGP (Multiprotocol BGP) as its control plane protocol. On Juniper EX Series and QFX Series switches, the most scalable and recommended design for the overlay is EBGP (External BGP).

In a 3-stage or 5-stage Clos architecture, EBGP is used in the overlay to exchange EVPN routes (Route Types 1-5) between Leaf and Spine switches.

EBGP simplifies configuration by avoiding the need for Route Reflectors (required for IBGP) and provides better control over route propagation through BGP community and policy management.

Incorrect Options:

Options A and B refer to the underlay protocols. While they provide the path for the VXLAN tunnels, they do not handle the EVPN signaling itself.

Option C (MPLS) is a different transport technology. While EVPN can run over MPLS (EVPN-MPLS), campus designs on EX series devices specifically use VXLAN as the data plane, making EBGP the standard signaling protocol for the EVPN-VXLAN overlay.

To secure a Layer 2 network running Multiple VLAN Registration Protocol (MVRP) against unauthorized VLAN propagation from rogue devices, you must control the registration state of the ports.

Forbidden Registration Mode (Option D): This mode is specifically designed to prevent an interface from participating in the MVRP exchange.

When a port is set to forbidden, it will neither register nor declare VLANs (except those statically configured on the interface).

If a rogue device sends MVRP PDUs to this interface, the distribution switch will ignore those PDUs, preventing the rogue device from dynamically creating or learning VLANs through that port.

Registration Hierarchy: In Junos OS 24.4, this is configured at the [edit protocols mvrp interface < interface-name > registration forbidden] level.

Other Modes: normal (default) allows full participation, while restricted ignores joins for VLANs not already statically defined on the switch but still declares its own.

In this scenario, the requirement is to authenticate devices based on their MAC addresses using a centralized database.

MAC RADIUS (Option A): This is the standard Juniper method for authenticating " headless " or non-802.1X capable devices based on their hardware (MAC) address. The switch acts as a proxy, sending the device ' s MAC address as the username and password to a centralized RADIUS server (the centralized database). If the MAC address is found in the server ' s database, the device is granted access to the network. This perfectly matches the user ' s requirement for MAC-based authentication and a centralized database.

Captive Portal (Option B): This is a web-based authentication method requiring user interaction (login via a browser), which is not based on MAC address identification for the initial authentication phase.

Supplicant Modes (Options C & D): These define how multiple devices are handled on an 802.1X-enabled port, but they are not authentication methods themselves; they rely on 802.1X (EAP-based) or MAC-RADIUS being already configured.

In Junos OS, the supplicant-mode configuration under protocols dot1x determines how the switch handles multiple MAC addresses on a single physical port. According to the exhibit, the current mode is set to Single, and the Number of connected supplicants is 2. This indicates that the port is currently allowing multiple devices, which contradicts the goal of limiting access to only one device at a time.

Here is the breakdown of why Option C is the correct solution based on Juniper’s standard behavior:

Supplicant Mode: Single (Current State): In this mode, the first device to authenticate opens the port for all subsequent devices. As long as the first device remains authenticated, other devices can send traffic through the port without individual authentication. This is why the exhibit shows 2 connected supplicants despite the mode being " Single. "

Supplicant Mode: Single-Secure (The Solution): This mode strictly limits the port to only one MAC address. Once a device successfully authenticates via 802.1X, the switch drops any traffic coming from any other MAC address on that port. If the authenticated device logs off or the session times out, the port becomes available for a new device, but never more than one simultaneously. * Supplicant Mode: Multiple (Option B): This mode allows multiple supplicants to authenticate individually. Each MAC address must go through its own authentication process. This would allow more than one device, which is the opposite of the user ' s requirement.

MAC RADIUS Restrict (Option A): This feature is used to force MAC-based authentication and does not inherently limit the number of devices to one in the same way that changing the supplicant mode does.

Maximum EAPOL requests (Option D): This parameter defines how many times the switch will send an EAP-Request/Identity frame to a supplicant before giving up. Changing this to 1 does not restrict the number of devices allowed on the port; it only changes the retry logic for a single authentication attempt.

Configuration Example for Junos OS 24.4: To implement this change, you would use the following command: set protocols dot1x edit interface ge-0/0/10.0 supplicant-mode single-secure

In Junos OS, particularly in BGP-based environments like EVPN-VXLAN or MPLS, the router often needs to perform a recursive lookup to resolve the BGP next-hop of a route.

Next-Hop Resolution (Option C): When an EVPN route (found in default-switch.evpn.0) is received, the protocol next-hop is typically the loopback IP of the remote VTEP. To actually forward traffic, the switch must know how to reach that loopback IP.

The inet.3 table is the default table in Junos used to store egress interface information for BGP next-hops.

While inet.0 handles standard unicast routing, inet.3 is specifically consulted for resolving the path toward BGP peers. In an EVPN context, this ensures that the VXLAN tunnel endpoint is reachable and properly resolved through the underlay.

Other Tables: * inet.2 (Option A) is used for Multicast RPF checks.

default-switch.evpn.0 (Option B) stores the EVPN routes themselves (MAC/IP), but it is the source of the lookup, not the table where the recursive resolution occurs.

vxlan.inet (Option D) is an internal table used to track active VXLAN tunnels but is not the primary table for recursive BGP next-hop validation.

The exhibit displays the default-switch.evpn.0 routing table, which is used on Juniper leaf devices to store EVPN Type 2 (MAC/IP) routes.

Route Distinguisher (Option C): In EVPN, the Route Distinguisher (RD) is an 8-byte prefix added to a route to make it unique within the BGP control plane. The RD format in the exhibit is < IP-Address > : < Identifier > .

For example, the prefix 2:192.168.100.1:1::5010::... indicates an EVPN Type 2 route (2:) where 192.168.100.1:1 is the Route Distinguisher.

This RD identifies the specific routing instance on the originating VTEP that advertised the MAC/IP address.

Option A is incorrect: The RD 192.168.100.2:1 does not necessarily mean the host device has that IP; it means the originating switch has that router ID/IP used for its RD.

Option B is incorrect: While the RD often incorporates the router ID, the RD itself is the full string (e.g., 192.168.100.1:1), which is distinct from the raw Router ID used in the BGP summary.

Option D is incorrect: Looking at the entries for 10.1.1.1 and 10.1.2.3, they are associated with different identifiers in the RD strings (5010 and 5020 respectively), which typically map to different VNIs or bridge domains.

The show ospf interface output provides critical information about the local OSPF state.

Loopback Behavior (Option A): The output shows lo0.0 is in the DR (Designated Router) state with Nbrs 0. In Junos OS, OSPF adjacencies are not formed over loopback interfaces; they are treated as stub networks.

Neighbor State (Option D): Every interface listed (ge-0/0/1.0, ge-0/0/2.0, and lo0.0) shows Nbrs 0. This indicates that the router is not seeing any OSPF neighbors. Since the physical interfaces are in the DR state (meaning the router has elected itself as the DR because no other routers responded), it confirms the router is not receiving OSPF Hello messages from any potential neighbors on those segments.

Router ID: The DR ID 192.168.1.17 is the local router ' s own ID, not a neighbor it is trying to reach.