Free Juniper JN0-650 Practice Exam with Questions & Answers | Set: 2

This scenario describes a specific use case where a switch port is shared by multiple devices (e.g., via a downstream unmanaged switch), and you want to simplify the authentication process.

Single Supplicant Mode (Option A): In this mode, the switch requires only the first device that connects to the port to successfully authenticate via 802.1X. Once that first device is authorized, the switch " opens " the port for all traffic. This means all subsequent devices attached to that same downstream switch are permitted to access the network without undergoing their own authentication.

Other Modes:

Single-secure supplicant (C): Only allows the first authenticated device; all others are blocked.

Multiple supplicant (D): Requires every device to authenticate individually.

MAC RADIUS (B): This is an authentication method, not a port-control mode.

To provide IP phones with geographic location details (such as civic addresses or coordinates) automatically, Juniper EX Series switches utilize the LLDP-MED (Link Layer Discovery Protocol - Media Endpoint Discovery) protocol.

VoIP Specifics: While standard LLDP (C) is for general device discovery, LLDP-MED is an enhancement specifically designed for network-to-endpoint communication for VoIP devices.

Location Identification: LLDP-MED supports Location Identification TLVs (Type-Length-Values). These allow a switch to push geographic or civic location data to an IP phone, which is critical for E911 services and asset tracking.

Junos Implementation: On EX Series switches, this is typically configured under protocols lldp-med to ensure the switch advertises the necessary location information to connected endpoints.

Junos OS 24.4 on EX Series switches provides robust support for LLDP (Link Layer Discovery Protocol) and its extension, LLDP-MED (Media Endpoint Discovery).

LLDP-MED Power Negotiation: This feature allows a switch (Power Sourcing Equipment or PSE) and a connected device (Powered Device or PD), such as an IP phone or access point, to negotiate power requirements beyond the standard IEEE 802.3af/at classes. The switch can dynamically allocate the exact amount of power the device needs (in 0.1W increments), which optimizes the power budget of the switch.

LLDP Scope: LLDP is a Link Layer protocol (Layer 2), but it is not restricted to Layer 2 interfaces; it can also operate on Layer 3 interfaces to advertise system identity and capabilities. This makes Option A incorrect.

Link-Local Protocol: LLDP frames use a specific multicast MAC address (01:80:c2:00:00:0e) that is not flooded or forwarded by switches. They are strictly link-local between two directly connected neighbors. This makes Option B incorrect.

Endpoint Focus: LLDP-MED is specifically designed for Media Endpoint Devices (like VoIP phones), providing TLVs for network policy (VLAN/QoS), location identification, and inventory management. Standard LLDP is used for discovering network connectivity devices. This makes Option D incorrect.

The exhibit shows a BGP Route Reflector (RR) configuration where an export policy named NHS (Next-Hop Self) is applied to the internal BGP group int-group. The policy NHS sets the next-hop self attribute for BGP routes.

The Problem (Traffic Tromboning): In a standard BGP Route Reflector design, the RR should reflect routes without modifying the BGP next-hop attribute. By applying a next-hop self policy on the export to clients, the RR tells all its clients that it is the exit point for those routes. Consequently, all data plane traffic is sent to the RR first before being forwarded to the actual destination, rather than following the optimal direct path between clients. This is known as " traffic tromboning " or suboptimal routing.

The Solution (Option C): The most direct way to fix this is to delete the export policy that is forcing the next-hop to be the RR. By deleting protocols bgp group int-group export NHS, the RR will resume standard behavior and reflect the original next-hop received from the route source, allowing clients to route traffic directly to the correct destination.

The Refined Solution (Option D): If you must keep the NHS policy (perhaps for routes learned from external peers), you should ensure it only applies to those specific routes. By adding from route-type internal to the policy term and then potentially changing the logic (or simply narrowing the scope), you can prevent the RR from incorrectly applying next-hop self to internal routes that it is merely reflecting. In the context of this specific problem, Option D combined with a change in the policy ' s action or scope helps ensure reflected internal routes maintain their original, optimal next-hops.

Option A is incorrect because setting next-hop self for external routes is common practice, but it doesn ' t solve the problem of internal reflected routes being diverted to the RR.

Option B is incorrect because applying this as an import policy would change how the RR itself sees the routes, but it wouldn ' t fix the attributes being sent out to the clients in the reflection process.

In this scenario, router1 (AS 65001) is attempting to establish an External BGP (EBGP) peering with router2 (AS 65002) using their loopback (lo0) interface addresses (192.168.1.1 and 172.16.1.1).

According to the Junos OS 24.4 documentation on BGP peering sessions:

EBGP TTL Default: By default, EBGP packets are sent with a Time-to-Live (TTL) value of 1. This assumes the peer is directly connected on a shared physical subnet.

Loopback Peering Challenge: When peering between loopback addresses, the destination IP is not on the same subnet as the physical ingress interface. Even if the routers are directly connected physically, the router treats the loopback interface as an additional " hop " . With a TTL of 1, the BGP packet expires before it can be processed by the peer ' s routing engine.

The Multihop Solution (Option D): To allow this session to form, you must configure the multihop statement under the BGP neighbor hierarchy. This tells Junos to increase the TTL (the default becomes 64 when multihop is enabled) and allows the session to establish even though the peer ' s address is not directly connected.

Target Neighbor: The neighbor address specified in the configuration on router1 must be the remote loopback address of router2 (172.16.1.1).

Option A (Multipath) is incorrect because it is used for load balancing across multiple active BGP paths, not for initial session establishment.

Options B and C are incorrect because they reference physical interface addresses (10.10.20.1 or 10.10.10.1) which are not the addresses being used for the loopback-based BGP session.

In standard BGP operations, a router typically selects only one " best path " for a given destination prefix and installs that single path into the forwarding table. To utilize multiple paths for traffic forwarding (load-balancing), specific multipath features must be enabled.

BGP Multipath: This feature allows a router to install multiple equal-cost paths into the routing and forwarding tables. However, by default, BGP multipath requires that all candidate paths have the same neighboring Autonomous System (AS).

Multipath Multiple-AS (Option B): In the exhibit, R1 is receiving routes from ISP A (AS 65501) and ISP B (AS 65502). Since these are two different neighboring ASs, the standard multipath feature is not sufficient. You must use the multipath multiple-as statement under the BGP group or neighbor hierarchy. This tells Junos to consider paths as equal even if they originate from different neighboring ASs, provided all other BGP path selection attributes (Local Preference, AS Path length, Origin, MED, etc.) are identical.

Why other options are incorrect: * Option A (multihop) is used for peering with routers that are not directly connected.

Option C (prefix limit) is a security and stability feature to limit the number of prefixes received from a neighbor.

Option D (damping) is used to penalize unstable, " flapping " routes to prevent constant routing table churn.

Configuration Example for Junos OS 24.4: To implement this on R1, you would use the following configuration:

set protocols bgp group < group-name > multipath multiple-as

In BGP path selection, the Local Preference attribute is one of the most common ways to influence outbound traffic from an Autonomous System (AS). It is a well-known discretionary attribute that is propagated throughout the AS to tell internal routers which path is preferred for a specific destination.

Priority Rule: In the BGP selection algorithm, a higher local preference value is always preferred over a lower one. The default value in Junos OS is 100.

Influencing Outbound Traffic (Option A): To ensure that Provider A is always preferred, you would apply an import policy on R1 (the router connected to Provider A) to set the local preference of all received routes to a value higher than the default (e.g., 200). Since 200 > 100, R3 and R4 will prefer the path via R1.

Alternative Method (Option C): Conversely, you can achieve the same result by applying an import policy on R2 (the router connected to Provider B) to set the local preference to a value lower than the default (e.g., 50). Since the routes from R1 remain at the default of 100, and 100 > 50, the path via R1 (Provider A) is preferred.

Why B and D are incorrect: Setting a higher local preference on R2 (Option B) would make Provider B the preferred exit point. Setting a lower local preference on R1 (Option D) would make Provider A the least preferred exit point.

Junos OS uses specific routing tables for handling multicast traffic to ensure loop prevention through Reverse Path Forwarding (RPF) checks:

Multicast RPF (Option C): The inet.0 table is the default unicast routing table. In most standard multicast deployments, Protocol Independent Multicast (PIM) performs its RPF checks against this table to determine the upstream interface toward the multicast source.

Topology Differences (Option A): The inet.2 table is specifically designed for multicast RPF lookups when the multicast forwarding topology differs from the unicast forwarding topology. This is common in environments using Multiprotocol BGP (MBGP) where you might want multicast traffic to follow a different path than standard data traffic.

inet.1 Role (Option B): The inet.1 table is the multicast forwarding cache. It stores (S,G) and (*,G) entries for actual packet forwarding. Routing protocols like MBGP or IS-IS do not place routes directly into inet.1; instead, PIM uses information from inet.0 or inet.2 to populate inet.1.

IS-IS and OSPFv3 (Option D): These protocols place their IPv4/IPv6 unicast routes into inet.0 or inet6.0. They do not place routes into inet.2 " directly " unless specific RIB-group configurations or address families are enabled to share those routes for multicast RPF purposes.

In Junos OS, a physical or logical interface is typically associated with a single OSPF area. However, there are specific design requirements—such as migrating an interface from one area to another without downtime or creating specific transit topologies—where an interface needs to exist in two areas simultaneously.

Multi-area Adjacency (Option B): The secondary command under the OSPF interface hierarchy allows an interface to be part of a secondary area in addition to its primary area.

Protocol Behavior: When an interface is configured as secondary, the router sends and receives OSPF Hello packets for both the primary and secondary areas on that single link. This allows the router to form adjacencies with neighbors in both areas over the same physical connection.

Use Case: This is frequently used in hub-and-spoke topologies or during network restructuring to ensure reachability is maintained while changing area boundaries. It effectively allows a " logical " split of the interface at the OSPF protocol level.

In an EVPN-VXLAN architecture, the interaction between the control plane (EVPN) and the data plane (VXLAN) is defined by specific functional components:

VTEP (VXLAN Tunnel End Point): These are the entities responsible for the encapsulation and de-encapsulation of Layer 2 Ethernet frames into Layer 3 UDP/IP packets. A VTEP can be a physical switch (like a QFX or EX series) or a software-based entity. When traffic enters the fabric, the ingress VTEP wraps it in a VXLAN header; the egress VTEP removes this header before delivering it to the destination host. (Option B)

VNI (Virtual Network Identifier): The VNI is a 24-bit field in the VXLAN header that allows for up to 16 million unique identifiers. It is used to identify specific broadcast domains (or VLANs) within the overlay network. Each VNI effectively represents a virtualized Layer 2 segment that is stretched across the Layer 3 underlay. (Option D)

Incorrect statements: Option A is incorrect because VNIs are identifiers, not the " engine " that performs encapsulation—that is the VTEP ' s job. Option C is incorrect because VTEPs identify the endpoints of a tunnel, not the individual broadcast domains themselves.