Juniper JN0-650 Enterprise Routing and Switching - Professional (JNCIP-ENT) Exam Practice Test

The exhibit illustrates an Autonomous System (AS 65512) receiving the same prefix ($203.0.113.0/24$) from two different neighbors, ISP A and ISP B. To influence outbound traffic from AS 65512 so that ISP A is preferred, you must manipulate the BGP Local Preference attribute.BGP Path Selection and Local Preference: Local preference is the first attribute evaluated by BGP after checking if the next hop is reachable. A higher local preference value is always preferred over a lower one. The default value in Junos OS is 100.Applying the Preference (Option B): By applying an import policy on router R1 to set a local preference higher than 100 (e.g., 200) for routes from ISP A, R1, R2, and R3 will all prefer the path through R1 to reach ISP A.Applying the Preference (Option C): Alternatively, you can achieve the same result by applying an import policy on R2 to set a local preference lower than 100 (e.g., 50) for routes from ISP B. Since the routes from R1 remain at the default of 100, the path through ISP A (100) will be preferred over ISP B (50).Why A and D are incorrect: Setting a lower preference for ISP A (Option A) or a higher preference for ISP B (Option D) would result in ISP B being preferred for outbound traffic, which is the opposite of the requirement.

VSTP (VLAN Spanning Tree Protocol) is designed for interoperability with environments running Cisco’s Per-VLAN Spanning Tree Plus (PVST+).

Per-VLAN Instances (Option E): The core function of VSTP is to maintain a separate spanning tree instance for every VLAN configured on the switch. This allows for different root bridges and different topologies per VLAN, enabling traffic load-balancing across various physical links.

BPDU Generation (Option A): Because each VLAN has its own instance, VSTP must send separate BPDUs for each VLAN. These BPDUs are tagged with the respective VLAN ID to ensure the receiving switch can process them for the correct instance.

Instance Limits (Option D): On many Juniper platforms, VSTP is limited to supporting a maximum of 253 unique spanning tree topologies (instances). If the number of VLANs exceeds this limit, additional VLANs will not have spanning tree protection unless migrated to a different protocol like MSTP.

Incorrect Statements: Option B is incorrect because VSTP is compatible with RSTP; it actually uses RSTP algorithms (Rapid-VSTP) by default in modern Junos versions to provide fast convergence. Option C is incorrect because STP or RSTP is usually the default spanning tree protocol on EX Series switches, not VSTP.

OSPF stub areas are used to reduce the size of the Link-State Database (LSDB) in routers with limited resources by restricting the flooding of external routes.

Virtual Links (Option C): According to OSPF standards (both v2 and v3), virtual links cannot pass through stub areas. A virtual link must transit a "transit area," which must be a standard (non-stub) area with a full routing table.

Totally Stubby Areas (Option D): A stub area (which blocks Type 5 External LSAs) can be further restricted into a totally stubby area. In Junos OS, this is done by adding the no-summaries statement to the stub configuration. This blocks both Type 5 and Type 3 (Inter-area) LSAs, replacing them with a single default route.

Incorrect Statements: Option A is incorrect because standard stub areas cannot contain an ASBR; only Not-So-Stubby Areas (NSSA) allow for an ASBR. Option B is incorrect because an area is either a Stub or an NSSA; they are mutually exclusive configurations for the same area.

In a three-stage EVPN-VXLAN fabric (Spine-Leaf architecture) where leaf devices perform the gateway services (Edge-Routed Bridging or ERB):

VTEP Functionality (Option B): Leaf devices act as VXLAN Tunnel End Points (VTEPs). They are responsible for encapsulating Ethernet frames from locally connected hosts into VXLAN packets for transport across the IP fabric and de-encapsulating incoming VXLAN packets.

Fabric Support (Option C): In a standard Juniper IP fabric design, both the leaf and spine devices are typically expected to support VXLAN and EVPN capabilities. While spines in an ERB design might only perform IP forwarding in the underlay, they often participate in the BGP control plane (as Route Reflectors) or provide the ability to transition to Centrally-Routed Bridging (CRB) where spines would act as gateways.

Incorrect Options: Option A is incorrect because the entire fabric infrastructure must be "VXLAN aware" in terms of MTU settings and routing capability to support the overlay. Option D is incorrect because in an ERB design, the spine devices are high-speed transit nodes and do not terminate VXLAN tunnels; only the edge (leaf) devices act as VTEPs.

In Junos OS 24.4, the no-loss forwarding class is used for traffic that requires lossless delivery, such as iSCSI or FCoE, typically in a Data Center Bridging (DCB) environment.

Priority-Based Flow Control (Option C): To guarantee "no-loss" behavior, the switch must support and use Priority-based Flow Control (PFC). PFC allows the switch to send "pause" frames for a specific priority (forwarding class) to prevent buffer overflow and packet drops without affecting other traffic on the same link.

Forwarding Class Sets (Option B): In enhanced Layer 2 software (ELS) versions used by modern QFX and EX series switches, lossless traffic must be managed within forwarding class sets (also known as priority groups). This grouping is necessary to apply specific DCB properties, such as PFC and specific bandwidth guarantees, to the lossless traffic class.

Why A and D are incorrect: Default scheduler maps and default drop profiles do not provide the specialized buffer management or lossless signaling required for this class. Lossless traffic specifically requires the suppression of tail drops rather than standard drop profiles.

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 for Layer 3 connectivity. They allow different IP-VRFs on different VTEPs to exchange prefix information directly. This model is widely referred to as IP-VRF-to-IP-VRF routing 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 the overlay 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.

To simplify VLAN management and automate the creation and pruning of VLANs across a network, Juniper utilizes the Multiple VLAN Registration Protocol (MVRP).

MVRP on Trunk Interfaces (Option C): MVRP is the IEEE 802.1ak standard that replaces the older, proprietary GVRP. It is designed to run on trunk interfaces between switches.

Dynamic Creation: When a VLAN is added to one switch, MVRP advertises its existence to neighboring switches. If those switches need to reach that VLAN, they can dynamically create it in their database.

Pruning: If a switch no longer has any active ports or downstream neighbors interested in a specific VLAN, it stops advertising that VLAN on its trunks. This "prunes" the VLAN traffic from those links, saving bandwidth.

Incorrect Options: Option A and B are incorrect because GVRP is legacy and no longer the recommended protocol for modern Junos deployments. Option D is incorrect because MVRP is meant for inter-switch trunk links to manage the fabric, not for edge access ports where VLAN membership is usually static.

Junos OS 24.4 handles multicast traffic using two distinct models based on whether the source is known in advance.

Knowledge and Sources (Option A): PIM-ASM (Any Source Multicast) is designed for "many-to-many" communication where receivers join a group ($*,G$) and rely on a Rendezvous Point (RP) to discover active sources. In contrast, PIM-SSM (Source-Specific Multicast) is for "one-to-many" scenarios where receivers must already know the exact source IP ($S,G$) before joining.

Protocol and RP Logic (Option D): PIM-SSM bypasses the RP entirely. It relies on IGMPv3 messages from the host, which explicitly include both the source address and the group address. This allows the last-hop router to build a Shortest Path Tree (SPT) directly toward the source immediately.

Register Process (Option B): While PIM-ASM does use registers, it is the First-Hop Router (Designated Router on the source segment) that sends the register to the RP, not the receiver's DR.

RP Role (Option C): This is exactly backwards; PIM-ASM requires an RP for source discovery, whereas PIM-SSM does not use one at all.

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 port roles (isolated vs. community) rather than the method used to enable trunking between switches.

To interoperate with Cisco switches running Per-VLAN Spanning Tree Plus (PVST+), Juniper devices must use VLAN 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.

The exhibit illustrates an EVPN-VXLAN fabric using multi-homing. Server1 is dual-homed to Leaf1 and Leaf2 using an Ethernet Segment Identifier (ESI) in an active-active or active-standby configuration. Server2 is single-homed to Leaf3.

In EVPN environments, specific mechanisms are used to prevent loops and duplicate traffic when dealing with Broadcast, Unknown Unicast, and Multicast (BUM) traffic:

Broadcast Propagation (Option A): When Server2 (connected to Leaf3) generates a broadcast frame, Leaf3 encapsulates this traffic into a VXLAN tunnel and forwards it to all other VTEPs (Virtual Tunnel End Points) that participate in that specific Virtual Network Instance (VNI). Therefore, both Leaf1 and Leaf2 will receive the broadcast frame from the core fabric.

Designated Forwarder (DF) Election (Option C): To prevent a multi-homed device (like Server1) from receiving duplicate copies of the same broadcast frame from multiple leaf switches, EVPN utilizes a Designated Forwarder (DF). For a given ESI, only one leaf switch is elected as the DF.

The exhibit explicitly states that Leaf2 is the Designated Forwarder.

According to the Junos EVPN implementation, only the DF is responsible for decapsulating BUM traffic received from the core and forwarding it to the local access segment.

While Leaf1 receives the frame (Option A), it will see that it is not the DF for that segment and will drop the frame rather than forwarding it to Server1. This ensures Server1 receives exactly one copy of the broadcast, delivered by Leaf2.

Option B is incorrect because in a standard ingress replication or multicast-based underlay, all VTEPs in the VNI receive the broadcast.

Option D is incorrect because Leaf1 is the non-designated forwarder (non-DF) for this segment and is prohibited from forwarding BUM traffic to the ESI.

The exhibit shows a BGP routing process where an Import Policy is being applied to routes received in the RIB-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 a hidden 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 were rejected 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 A is incorrect because it only shows accepted routes.

Option B and C are 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.

The exhibit shows an OSPF network where Area 1 is configured as a Not-So-Stubby Area (NSSA). R5 is an Autonomous System Boundary Router (ASBR) injecting an External Route (203.0.113.0/24) into this area.

NSSA ASBR Behavior (Option D): Within an OSPF NSSA, external routes cannot be advertised as standard Type 5 LSAs because stubby areas do not support them. Instead, the ASBR (R5) advertises the external prefix using a Type 7 LSA (NSSA External LSA). This LSA is flooded throughout Area 1.

ABR Translation Behavior (Option C): When the Type 7 LSA reaches the Area Border Router (R1), the ABR is responsible for translating it into a Type 5 LSA (AS External LSA). This allows the external route to be propagated into the backbone (Area 0) and subsequently to the rest of the OSPF domain.

Incorrect Statements (A & B): Option A is incorrect because Type 7 LSAs are local to the NSSA and are never advertised into Area 0. Option B is incorrect because Type 5 LSAs are strictly prohibited within an NSSA.

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.

The exhibit shows a network topology where Multiple VLAN Registration Protocol (MVRP) is used to dynamically manage VLANs across switches Core-1, Access-1, and Access-2.

Identifying the Missing Configuration: According to the diagram, the trunk link between Core-1 and Access-2 uses interface ge-0/0/16.0 on the Core-1 side.

Output Analysis: However, the show protocols mvrp output for Core-1 only lists interfaces ge-0/0/14.0 and ge-0/0/15.0.

MVRP Requirements: For MVRP to successfully propagate VLAN information between Access-2 and the rest of the network, the protocol must be enabled on every trunk interface in the path.

Solution: Because ge-0/0/16.0 is missing from the Core-1 MVRP configuration, VLAN registration messages from Access-2 are not being processed by Core-1. Configuring this interface under MVRP on Core-1 will solve the communication problem.

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.

In a standard Layer 2 switch environment without specific multicast optimizations, multicast traffic is treated similarly to broadcast traffic and is flooded out of all ports within a VLAN (except the port where it was received). This is inefficient as it consumes unnecessary bandwidth on ports where no receivers are present.

To optimize this, IGMP Snooping is the standard solution.

How it works: The switch "snoops" or monitors IGMP (Internet Group Management Protocol) messages between hosts and routers.

Result: When a receiver sends an IGMP Membership Report (Join) for a specific multicast group, the switch records which port that request came from. It then builds a Layer 2 multicast forwarding table so that traffic for that group is only forwarded to the specific ports that have active listeners.

Junos OS 24.4 Configuration: On modern Juniper switches, you enable this globally or per VLAN using the set protocols igmp-snooping vlan command.

Option A (Promiscuous mode) is used for monitoring or specific security configurations (like Private VLANs) and would not limit multicast flooding. Option B (Spanning Tree) manages loop prevention and does not differentiate between traffic types for forwarding optimization. Option D (IRB interface) is used for Layer 3 routing between VLANs but does not inherently provide Layer 2 multicast optimization within a single VLAN.

OSPFv2 (IPv4) and OSPFv3 (IPv6) share many fundamental concepts, such as the SPF algorithm and the use of areas, but they have distinct differences in how they handle prefix information and LSA headers in Junos OS.

Backbone Requirement (Option C): Both OSPFv2 and OSPFv3 utilize a hierarchical structure. In both versions, all areas must connect to a central Area 0 (the backbone) to allow for inter-area routing. If an area is not physically connected to Area 0, a virtual link must be established.

Flooding Scope (Option D): One of the significant architectural changes in OSPFv3 is the inclusion of the flooding scope directly into the LSA header. In OSPFv3, the LS Type field is expanded to 16 bits, where the top three bits define the flooding scope (e.g., Link-local, Area, or AS scope). This allows routers to understand how far an LSA should be propagated without needing to understand the specific LSA type itself.

LSA Prefix Information (Option A): This statement is misleading. In OSPFv2, Router and Network LSAs (Type 1 and 2) carry both topology and prefix information. However, a key design goal of OSPFv3 was to separate topology from prefix information. In OSPFv3, Type 1 and 2 LSAs only describe the topology, while prefixes are carried in new LSA types: Intra-Area-Prefix-LSAs (Type 9) and Link-LSAs (Type 8).

Processing (Option B): OSPFv2 is processed "per-subnet" because it forms adjacencies based on IPv4 subnets. OSPFv3 is processed "per-link", meaning it forms adjacencies between interfaces on the same physical link regardless of whether they share a common IPv6 prefix.

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 network without 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 use Multifield (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 a rewrite rule on 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 use Behavior 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.