Free Juniper JN0-650 Practice Exam with Questions & Answers

The exhibit shows a BGP routing process where anImport Policyis being applied to routes received in theRIB-IN. Specifically, Policy 1 states:"Reject 0.0.0.0/0 from AS 64512."

In Junos OS, when a routing policy rejects a route, that route is not placed in the main routing table (inet.0) for active use. Instead, it becomes ahidden route. To verify that a specific peer is actually sending a route that is subsequently being rejected by your policy, you must use specific diagnostic commands:

Understanding "Hidden" Routes:When a BGP route is received but fails to meet policy requirements (or has an unreachable next-hop), Junos keeps it in the BGP RIB-IN but marks it as "hidden." It will not appear in a standard show route command.

Command Logic (Option D):The command show route receive-protocol bgp hidden allows an administrator to view all routes received from a specific neighbor, including those that wererejected by import policies.

show route receive-protocol bgp : Shows only the routes that passed the import policy and were accepted into the table. Since the 0.0.0.0/0 route from AS 64512 is explicitly rejected in the exhibit, it would not show up here.

Adding the hidden keyword is the essential step to see the rejected default route and verify that AS 64512 is indeed sending it before the policy drops it.

Other Options:

Option Ais incorrect because it only shows accepted routes.

Option B and Care used to filter the existing active routing table based on gateway or next-hop attributes, but they cannot show routes that have been rejected and excluded from that table.

In a standard campus deployment on Juniper EX Series switches involving VoIP phones and 802.1X authentication, understanding the default behavior of Junos OS 24.4 is critical:

Voice VLAN (Option A):By default, an access port belongs to a single VLAN (the native or data VLAN). For an IP phone to operate correctly on the same physical port as a PC, aVoice VLANmust be explicitly configured and associated with the interface. This allows the switch to segregate voice traffic (usually tagged) from data traffic (untagged).

802.1X Configuration (Option D):Access ports do not have 802.1X authentication enabled by default. To enforce network access control for the client PCs, you must manually enable and configure the dot1x protocol on all relevant interfaces.

PoE Default (Option B):On EX Series switches that support PoE (like P or MP models),PoE is enabled by defaulton all PoE-capable ports. Therefore, additional configuration is generally not required unless you need to change power priorities or management modes.

LLDP Default (Option C):Standard LLDP is typically enabled by default in the factory configuration of most EX Series switches to facilitate neighbor discovery. While LLDP-MED is used for VoIP, the core requirement for "deploying" the described environment highlights the manual steps of VLAN and security setup rather than protocol discovery which often runs out-of-the-box.

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 candynamically allocatethe 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 onLayer 3 interfacesto advertise system identity and capabilities. This makesOption Aincorrect.

Link-Local Protocol:LLDP frames use a specific multicast MAC address (01:80:c2:00:00:0e) that isnot floodedor forwarded by switches. They are strictly link-local between two directly connected neighbors. This makesOption Bincorrect.

Endpoint Focus:LLDP-MED is specifically designed forMedia 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 makesOption Dincorrect.

EVPN Route Type 5 (IP Prefix Route) is used to advertise IP prefixes (subnets) between broadcast domains or between VRFs in an EVPN fabric.

IP-VRF-to-IP-VRF (Statement C):In an EVPN-VXLAN architecture, Type 5 routes are primarily used forLayer 3 connectivity. They allow different IP-VRFs on different VTEPs to exchange prefix information directly. This model is widely referred to asIP-VRF-to-IP-VRFrouting because it enables inter-subnet routing at the leaf layer without requiring Layer 2 MAC learning for those specific prefixes.

Overlay Next Hop (Statement B):For a PE router to reach a prefix advertised via a Type 5 route, it must resolve theoverlay next hop. This next hop is typically the loopback IP address of the originating VTEP, which the receiving router uses to build the VXLAN tunnel.

Why others are incorrect:Statement A is incorrect because Type 7 routes are used for IGMP/MLD join synchronization. Statement D is incorrect because Type 5 routes advertise IP prefixes, not MAC addresses; MAC extended communities are associated with Type 2 routes.

Private VLANs (PVLANs) provide Layer 2 isolation between ports within the same broadcast domain. When a PVLAN spans multiple switches, a special type of trunk configuration is required to maintain the isolation and community logic across the inter-switch links.

Isolated VLAN Trunking (Option D):To extend an isolated VLAN across multiple switches, you must configure the trunk port on each switch to allow the isolated VLAN ID. In Junos OS, this is specifically achieved by configuring the interface as a trunk and associating it with the primary VLAN and the specific isolated VLAN. The correct syntax for enabling this inter-switch communication is to configure trunk ports that recognize the isolated VLAN tag (e.g., set interfaces unit 0 family ethernet-switching vlan members [ primary-vlan isolated-vlan ]).

Forwarding Rules:Traffic from an isolated port on Switch A must reach a promiscuous port (often on Switch B) to exit the PVLAN. The inter-switch trunk carries this traffic using the secondary (isolated) VLAN ID, ensuring that it remains isolated from other host ports on the remote switch.

Option A (inter-switch-link):In standard Junos switching, the inter-switch-link statement is used in Virtual Chassis or specific fabric designs, but for standard PVLAN extension, standard 802.1Q trunking with secondary VLAN IDs is the mechanism used.

Options B and C:These describe specific portroles(isolated vs. community) rather than the method used to enable trunking between switches.

The exhibit illustrates a standard end-to-end Class of Service (CoS) path consisting of an edge router (R1) and core/intermediate routers (R2 and R3).

Edge Classification (Option B):The scenario specifies that video traffic enters the networkwithout any class-of-service markings. Because there are no DSCP or 802.1p bits to inspect, the ingress router (R1) cannot use simple Behavior Aggregate (BA) classification. Instead, it must useMultifield (MF) classification. MF classification allows the router to look deeper into the packet (Source/Destination IP, Protocol, Port numbers) to identify the video stream and assign it to a specific forwarding class. *Core Classification (Option D):Once R1 has identified the traffic, it will typically apply arewrite ruleon its egress interface to mark the packets with a specific CoS value (like a DSCP code). Consequently, the downstream routers (R2 and R3) do not need to perform expensive deep-packet inspection again. They can useBehavior Aggregate (BA) classification, which simply looks at the markings in the packet header to determine the appropriate forwarding priority.

Option A and C:These are incorrect because BA classification is impossible on unmarked ingress traffic, and performing MF classification in the core is inefficient and not a recommended Juniper design practice for high-speed transit.

Junos OS 24.4 provides several server-failover options for 802.1X authentication to maintain network availability when the RADIUS server is unreachable.

Fallback Behavior (Option D):Theuse-cachefallback action allows the switch to consult its local cache of previously authenticated MAC addresses.

If a device was already authorized and its information is in the cache, the switch willcontinue to permit accessbased on those cached credentials.

However, if a new device (not in the cache) attempts to connect while the server is down, the switch cannot verify its credentials and willdeny the access attempt. This matches the specific requirement to permit authorized devices while denying new ones.

Other Fallback Options:

permit (Option C):This would allowalldevices (even new ones) to access the network, typically in a restricted "guest" or "bypass" VLAN.

deny (Option A):This would drop all traffic from all devices on the port if the server is unreachable.

vlan-name (Option B):This moves authenticated or unauthenticated users into a specific fallback VLAN.

The exhibit shows the output of the command show route protocol bgp on router R1 for the prefix 172.16.10.1/32. To determine the correct characteristics of this route, we analyze the specific BGP attributes and next-hop information provided in the routing table entry:

Multipath Parameter (Option B): The routing table shows two distinct paths for the prefix 172.16.10.1/32. The first path has two next hops (192.168.10.1 and 192.168.20.1) and is marked with the plus symbol (+) and the asterisk (*), indicating it is both an active and the best route. The presence of multiple next hops being used simultaneously for a single BGP path is a clear indication that the multipath parameter is enabled in the BGP configuration. In Junos OS, BGP multipath allows the installation of multiple equal-cost BGP paths into the forwarding table to facilitate load balancing.

Available Next Hops (Option C): The output explicitly lists two functional next hops for the active path: 192.168.10.1 via ge-1/0/0.2 and 192.168.20.1 via ge-1/0/1.3. Both show an outgoing interface, confirming that this route has two next hops available for traffic forwarding.

IBGP vs. EBGP (Option A): The BGP routes shown have an AS path of 200 I. This indicates the routes were learned from an external Autonomous System (AS 200). Furthermore, the protocol preference is 170. In Junos OS, the default preference for External BGP (EBGP) is 170, whereas the default preference for Internal BGP (IBGP) is 200. Therefore, this configuration is for EBGP, not IBGP.

Hidden Next Hops (Option D): The summary line at the top of the exhibit mentions that there are "2 hidden" routes in the inet.0 table. However, these hidden routes are not the next hops for the 172.16.10.1/32 prefix. A hidden route is a prefix that was rejected by policy or has an unreachable next hop; it is not a "hidden next hop" belonging to an active route.

To interoperate with Cisco switches runningPer-VLAN Spanning Tree Plus (PVST+), Juniper devices must useVLAN Spanning Tree Protocol (VSTP).

PVST+ Compatibility:VSTP is specifically designed to handle the per-VLAN BPDU requirements of Cisco's PVST+. It generates a separate spanning tree instance for each VLAN and uses the same multicast destination MAC address as Cisco devices.

Other Protocols:MSTP (B) is used for grouping VLANs into regions; RSTP (D) is a single-instance protocol (IEEE 802.1w) and is generally incompatible with per-VLAN BPDU requirements without additional configuration.

In External BGP (EBGP), there is a default safety mechanism that requires the peer's next hop to be on a directly connected network.

TTL Constraint: By default, EBGP packets are sent with a Time-to-Live (TTL) value of 1. If the next hop is not directly connected (e.g., when peering via loopback interfaces or across a multi-hop path), the packet will expire before reaching the destination, causing the route to be discarded or the session to fail.

The Multihop Solution (Option B): To override this behavior, you must configure the multihop statement under the BGP neighbor or group hierarchy. This allows the BGP session to establish by increasing the TTL (typically to 64 or a user-defined value) and bypasses the "directly connected" check.

Incorrect Options: Option A (accept-remote-nexthop) is used in internal BGP or specific routing-instance scenarios to resolve next hops that aren't in the local routing table, but it doesn't solve the EBGP TTL/direct-connection requirement. Option C (advertise-inactive) allows BGP to advertise routes that are not the best path in the routing table, which is irrelevant to next-hop reachability. Option D (multipath) is used for load-sharing across multiple paths.