Free JN0-649 Practice Test Questions | Know You're Ready for Enterprise Routing and Switching Professional (JNCIP-ENT)

Explanation:

Understanding EVPN Route Types:

EVPN (Ethernet VPN) is used for providing Ethernet multipoint services over MPLS or VXLAN networks.

EVPN Route Types:

Type 1 (Ethernet Auto-Discovery Route): Used for auto-discovery of PEs and for detecting multi-homed devices.

Type 2 (MAC/IP Advertisement Route):

Carries endpoint MAC address information.

Carries endpoint IP address information.

Facilitates MAC learning and IP-to-MAC binding distribution.

Type 3 (Inclusive Multicast Route):<br><br>

Carries replication information.

Used for forwarding multicast and broadcast traffic.

Type 5 (IP Prefix Route): Carries IP prefixes for inter-subnet connectivity, but not replication information.

Verification:

Type 2 routes are crucial for distributing MAC and IP information about endpoints.

Type 3 routes are used to manage multicast traffic effectively.

References:

Juniper EVPN Configuration Guide

Understanding EVPN Route Types

Explanation:

You're dealing with BGP VPNs (Layer 3 VPNs) and multitenancy, which means you're using BGP with VPNv4/VPNv6 NLRI over MPLS L3VPNs. In these environments, some routers (especially non-MPLS capable or legacy routers) do not understand VPN NLRIs. You must prevent advertising those VPN routes to such peers.

Option B: Correct
"Configure an export policy on the local BGP peer to reject the VPN routes being sent to the remote peer."
This is a standard way to control route advertisement in Junos.
You define a BGP export policy to match VPN routes (e.g., by route type, community, etc.) and reject them.
Applied at the local BGP peer level.
Reference:
Junos OS Policy Framework

Option D: Correct
"Configure the apply-vpn-export feature on the local BGP peer."
By default, export policies under [edit policy-options policy-statement] are not automatically applied to VPN routes unless you explicitly tell BGP to apply them.
The apply-vpn-export statement ensures that the configured export policy is also applied to VPN routes.
Without this, even a correctly configured export policy won’t affect VPN NLRIs.
Reference:
Juniper Documentation – apply-vpn-export

❌ Option A: Incorrect
"Configure an import policy on the remote peer to reject the routes when they are received."
You cannot control another device’s import policies, especially if it is not under your administrative domain.
Furthermore, the goal is to prevent sending, not to rely on the receiver rejecting routes.
Sending unsupported VPN NLRI can cause session reset or route installation failures.

❌ Option C: Incorrect
"Configure a route reflector for the VPN NLRI."
Route reflectors are used to simplify iBGP mesh and are unrelated to preventing advertisements to certain eBGP peers.
This does not solve the problem of advertising unsupported VPN routes to a peer.

Question Context:

You have IP phones and computers sharing the same physical switch port on an EX Series switch (common in enterprise VoIP deployments). The voice VLAN feature is designed to simplify the process of assigning phones to a separate VLAN (usually for quality of service and security purposes), while still allowing the computer to communicate on the data VLAN.

✅ Option B: Correct
"The interfaces must be configured as access ports."
In Junos, when using the voice VLAN feature, the interface is configured as an access port that can support two VLANs simultaneously:
Access VLAN (data) – for the PC traffic
Voice VLAN – for the phone traffic
This is done using interface-mode access under ethernet-switching configuration.
Reference:
Juniper Voice VLAN Overview

✅ Option C: Correct
"Assigning the incoming voice and data traffic to separate VLANs enables the ability to prioritize the traffic using CoS."
Separating voice and data traffic into different VLANs enables differentiated CoS (Class of Service) treatment.
Voice traffic is latency-sensitive, so it’s prioritized using CoS settings (e.g., higher forwarding class, queue).
Junos can use VLAN-based CoS classifiers to map traffic to different forwarding queues.
Reference:
CoS and Voice VLAN

❌ Option A: Incorrect
"The voice VLAN feature must be used with LLDP-MED to associate VLAN ID and 802.1p values with the traffic."

Explanation:

C. single-secure supplicant mode
This mode allows only one device to authenticate on the port.
If a second device attempts to connect, it will be denied access, even if the first device has already authenticated.
This is the most secure mode for environments where strict one-device-per-port policies are required (e.g., high-security zones or compliance-driven networks).

Key Characteristics:
Only one MAC address is allowed.
If the authenticated device disconnects, the port resets and waits for a new authentication.
Prevents piggybacking or unauthorized access via hubs or daisy-chained devices.

❌ Incorrect Options:

A. single supplicant mode
Allows one 802.1X-capable device to authenticate.
However, non-802.1X devices (like printers or IP phones) may still gain access via fallback methods like MAC authentication.
Less strict than single-secure mode.

B. multiple supplicant mode
Allows multiple devices to authenticate independently on the same port.
Useful for setups with both a PC and IP phone, but not suitable when you want to restrict access to a single device.

D. MAC authentication mode
Used for devices that do not support 802.1X, like printers or legacy hardware.
Authenticates based on MAC address, but does not enforce a single-device limit unless combined with other controls.

Reference:
Juniper 802.1X Configuration Guide
Understanding 802.1X Supplicant Modes

Question Breakdown

Scenario:
You have computers and IP phones sharing a single switch port on a Juniper EX Series switch, and you're considering using the voice VLAN feature.
This is a typical enterprise deployment where:
Computers use the data VLAN (untagged)
IP phones use the voice VLAN (tagged with 802.1Q and optionally marked with CoS bits)

✅ B. The interfaces must be configured as access ports
In Junos, the voice VLAN feature is applied on access interfaces, not trunk interfaces.
The interface will carry untagged data VLAN traffic (for the PC) and tagged voice VLAN traffic (for the IP phone).
The phone tags its own voice packets with a VLAN ID (voice VLAN), while the PC sends untagged traffic.
Reference:
Juniper Voice VLAN Overview
✅ C. Assigning the incoming voice and data traffic to separate VLANs enables the ability to prioritize the traffic using CoS
By separating voice and data traffic into different VLANs, you can:
Apply Class of Service (CoS) policies to prioritize voice traffic (which is sensitive to delay and jitter)
Use VLAN-based CoS classifiers and forwarding classes
Reference:
Juniper CoS and Voice VLAN

❌ A. The voice VLAN feature must be used with LLDP-MED to associate VLAN ID and 802.1p values with the traffic
This is incorrect because LLDP-MED is optional, not mandatory.
LLDP-MED allows the switch to inform the phone about the voice VLAN ID and 802.1p priority dynamically, but you can also manually configure the VLAN ID on the phone.
The voice VLAN feature can work without LLDP-MED.

❌ D. The voice VLAN feature will enable incoming tagged data and voice traffic to be associated with separate VLANs
This is incorrect because the interface in voice VLAN mode does not accept both voice and data traffic as tagged.
Only voice traffic is expected to be tagged, and data traffic must be untagged.
If both are tagged, the interface would need to be a trunk, not an access port with voice VLAN.

Explanation:

✅ B. ge-0/0/11 continues to receive power
This implies that ge-0/0/11 has a higher priority in the PoE configuration.
Juniper switches allow you to assign PoE priorities (high, medium, low). If power is constrained, low-priority ports lose power first.
So if ge-0/0/11 is high priority, it will continue to receive power even if the total exceeds a threshold like 90W.

✅ D. ge-0/0/10 supports PoE+
PoE+ (IEEE 802.3at) provides up to 25.5 watts per port.
If the exhibit shows ge-0/0/10 with PoE+ capability or power allocation above 15.4W (standard PoE), this confirms PoE+ support.

❌ Likely Incorrect Options:
❌ A. Max wattage is 100 watts
Most EX Series switches support more than 100W — often 370W or 740W, depending on the model and power supply.
Unless the exhibit explicitly shows a 100W budget, this is likely false.

❌ C. PoE not enabled on ge-0/0/0
If the exhibit shows any power allocation or PoE status (even 0W), it means PoE is enabled, even if no device is drawing power.
“Not enabled” would mean the port is administratively disabled for PoE.

Explanation:

🔸 IS-IS Levels Overview:
Level 1 (L1):
Intra-area routing (within the same IS-IS area).
Level 2 (L2):
Inter-area routing (between different IS-IS areas).
L1/L2:
A router that participates in both levels and can form adjacencies with either.

✅ A. R1 is L1/L2
If the exhibit shows R1 forming adjacencies with both L1 and L2 neighbors, or if its system type is listed as Level 1/Level 2, then it’s participating in both levels.
This is common for routers acting as area border routers.

✅ D. R2 is L2 only
If R2 forms only Level 2 adjacencies, or its system type is listed as Level 2 only, then it’s not participating in Level 1.
This setup is typical for backbone routers or routers outside the local area.

❌ Likely Incorrect Options:

❌ B. R2 is L1/L2
If the exhibit shows only Level 2 adjacency for R2, this is false.

❌ C. R1 is Level 2 only
If R1 is forming both L1 and L2 adjacencies, or its configuration includes both levels, this is incorrect.

Reference:
Juniper IS-IS Configuration Guide
Use show isis adjacency and show isis interface to verify levels and adjacency states.

Explanation:

Why C (Static MAC Bypass) is Correct:
Static MAC bypass allows you to whitelist a specific MAC address (the printer) so that it can bypass 802.1X authentication.
The switch will allow traffic from this MAC without requiring 802.1X authentication, while still enforcing 802.1X for other devices.
This is the standard and secure way to handle non-802.1X-capable devices like printers, IP phones, or IoT devices.

Configuration Example (Juniper EX Switch): text set protocols dot1x static-mac-bypass mac

Why the Other Options Are Incorrect:
❌ A. MAC filtering
While MAC filtering can restrict access based on MAC addresses, it does not integrate with 802.1X.
It is a separate feature and doesn’t provide the same dynamic control as MAC bypass.

❌ B. MACsec (IEEE 802.1AE)
MACsec provides link-layer encryption, not authentication bypass.
It’s used for securing traffic between devices, not for allowing unauthenticated devices.

❌ D. MAC RADIUS (MAC Authentication Bypass, MAB)
MAB uses RADIUS to check if a MAC address is allowed, but it still requires RADIUS authentication.
Since the printer doesn’t support 802.1X, static MAC bypass is simpler and more reliable than MAB.

Key Takeaway:
Static MAC bypass is the best solution for allowing a non-802.1X device (like a printer) on a secured port.
It’s more secure than MAC filtering and simpler than MAB (which requires RADIUS).

References:
Juniper Docs: Configuring Static MAC Bypass for 802.1X
IEEE 802.1X-2010 Standard