JN0-650 Questions and Answers

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 theencapsulation and de-encapsulationof 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 toidentify 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 Ais incorrect because VNIs are identifiers, not the "engine" that performs encapsulation—that is the VTEP's job.Option Cis incorrect because VTEPs identify the endpoints of a tunnel, not the individual broadcast domains themselves.

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 centralArea 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 theflooding scopedirectly 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 toseparatetopology 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) andLink-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.

In OSPF, the election of aDesignated Router (DR)and aBackup Designated Router (BDR)is mandatory on broadcast and non-broadcast multi-access (NBMA) network types to manage link-state database synchronization efficiently.

The exhibit shows that bothdevice1anddevice2have their OSPF interface priority explicitly set to0. According to the Junos OS 24.4 OSPF implementation:

Ineligibility (Priority 0):A router with a priority of 0 is strictlyineligibleto be elected as a DR or BDR for that segment.

No Election Possible:When every router on a broadcast segment has a priority of 0, the election process cannot complete because there are no eligible candidates to fill the required roles.

State Behavior (Stuck in 2-Way):In OSPF adjacency formation, the2-Way stateindicates that bidirectional communication has been established (each router has seen itself in the other's Hello packets). However, to progress to theExstartandExchangestates on a multi-access network, routers must first identify a DR and BDR.

Result:Since neither router can become the DR, they both wait indefinitely for a third party (with priority > 0) to take the lead. Consequently, the OSPF adjacency will bestuck in the 2-Way state. Adjacencies only reach theFullstate with the DR and BDR; routers in a "DROther" role remain in 2-Way with each other.

Option A and Dare incorrect because the router ID (IP address) only acts as a tiebreaker if priorities are equal andgreater than 0.Option Bis incorrect because routers cannot reach the Exstart state (where they negotiate master/slave for database exchange) without first having a DR/BDR elected.

The IETF standards for EVPN-VXLAN define the scalability and forwarding behavior of the architecture.

VXLAN Scale (Statement B):The Virtual Network Identifier (VNI) is a24-bit fieldin the VXLAN header. This allows for up to $2^{24}$ unique identifiers, which translates to approximately16 milliondistinct VXLAN broadcast domains (segments) within a single fabric. *Forwarding Behavior (Statement D):VXLAN is a MAC-in-UDP encapsulation technology. When a Layer 2 frame enters the tunnel at a VTEP, theoriginal Layer 2 frame(including the original source and destination MAC addresses) is encapsulated into a UDP/IP packet and transported across the IP underlay. When it reaches the egress VTEP, the header is removed and theLayer 2 frame is forwarded unchangedto the destination host.

Why others are incorrect:Statement A is incorrect because EVPN itself can technically support more than 16 million domains, but the data plane (VXLAN) is the limiting factor in this specific deployment scenario. Statement C is incorrect because VXLAN encapsulates Layer 2 frames, not just "IP packets," and it treats the entire frame as a payload.

The exhibit shows a multicast network runningPIM Sparse Modewhere R2 is configured as a localRendezvous Point (RP). However, the non-RP routers (like R5) show no learned RP in their show pim rps output. To resolve this usingstandard protocolsfor dynamic RP discovery, you must implement a mechanism that automates the distribution of RP information across the PIM domain.

Bootstrap Router (BSR) (Option B):BSR is the industry-standard (RFC 5059) mechanism for dynamically electing an RP and distributing that information throughout a PIM-SM domain.

It uses two roles:Candidate-RPs (C-RPs), which announce their desire to be an RP, andCandidate-BSRs (C-BSRs), which collect these announcements and flood them to all other routers in the network via PIM bootstrap messages.

BSR is a "standard protocol" as it is part of the PIMv2 specification. Once configured on R2 (as C-RP) and potentially R1 or R2 (as C-BSR), all other routers will dynamically learn that R2 is the RP for the specified group ranges.

Auto-RP (Option D):While this also provides dynamic RP discovery, it is aproprietaryCisco protocol. Although Junos supports it for interoperability, the question specifically asks for "standard protocols only," making BSR the preferred choice.

MSDP (Option A):Multicast Source Discovery Protocol (MSDP) is used to share information about active sources betweendifferentPIM domains or for Anycast-RP. It does not handle the initial discovery of an RP within a single domain for standard PIM-SM operations.

Anycast RP (Option C):This is a technique used for RP redundancy and load balancing. While it can use BSR or MSDP for synchronization, it is a design architecture rather than a standalone "standard protocol" for the basic dynamic discovery of an RP in the manner requested here.

Configuration Example for BSR in Junos OS 24.4:To enable this, you would add the following to the RP (R2):

set protocols pim rp bootstrap-discovery

set protocols pim rp candidate-rp 10.222.1.2 group-ranges 224.0.0.0/4

set protocols pim rp candidate-bsr 10.222.1.2

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.

This question focuses on port security and preventing "rogue switches" or multiple devices from accessing a single physical port simultaneously.

Single-Secure Supplicant Mode (Option A):This is the most restrictive 802.1X mode in Junos OS. It allowsexactly oneMAC address to be authenticated on the port at a time. If a device successfully authenticates, the switch will drop any traffic coming from any other MAC address on that same physical interface. If a user tries to plug in a switch, only the first device that authenticates will have access; all other devices behind that switch will be blocked.

Single Supplicant Mode (Option C):This mode allows the first authenticated user to "open" the port for all other users. This would actuallyallowa rogue switch to function once the first device is authorized.

Multiple Supplicant Mode (Option B):This allows multiple devices to connect, provided each one authenticates individually. While secure, it does not prevent a user from connecting multiple devices to the port, which violates the requirement to allow only one.

MAC-RADIUS (Option D):This is an authenticationmethod, not a port-accessmodethat limits the number of supplicants.

The exhibit shows the output of the show poe interface command on a Juniper switch.

VTEP Power Capabilities (Statement D):The exhibit shows the Pair/Mode as 2P/AT, which refers to theIEEE 802.3at(PoE+) standard. Under this standard, a switch can supply up to30 Wof power per port to attached devices (PDs). *Dynamic Learning (Statement C):Looking at the Max power column for port ge-0/0/0, it shows 19.5W(L). The(L)indicator signifies that the power has beendynamically learned(negotiated) via LLDP or hardware classification, rather than being statically configured by an administrator. Additionally, it has identified the device asClass 4, which is a standard dynamic classification for PoE+ devices.

Why others are incorrect:Statement A (60 W) refers to the 802.3bt (PoE++) standard, which is not indicated here. Statement B is incorrect because the "(L)" confirms the configuration is not static.

Private VLANs (PVLANs) allow for granular port isolation within a single broadcast domain. When extending a PVLAN across multiple switches (S1 to S2), the secondary VLANs (Community or Isolated) must be preserved across the trunk links.

802.1Q Tagging (Option B):For traffic from aCommunity VLAN (RND)to reach members on a different switch, the Community VLAN must have its own802.1Q VLAN tag (VLAN ID)associated with it. When a frame from a community port on S1 traverses the trunk to S2, it is tagged with this specific secondary VLAN ID. S2 receives the tagged frame, identifies it as belonging to the RND community, and forwards it to the appropriate community or promiscuous ports.

Why it fails without a tag:If the RND community is only defined locally on S1 without a global VLAN ID, the trunk port will not know how to distinguish that traffic from the Primary VLAN or other communities.

Incorrect Options:Option Ais incorrect because the community VLANmusthave a different tag than the parent (Primary) VLAN to maintain the internal PVLAN logic.Option Cis incorrect because stripping tags would lead to the traffic being merged into the native VLAN or dropped.Option Dis incorrect because RND is a community VLAN; changing it to an isolated VLAN would change its behavior (preventing communication between members of that same group).

In a standard Layer 2 switch environment without specific multicast optimizations, multicast traffic is treated similarly to broadcast traffic and isflooded out of all portswithin 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 Snoopingis 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 isonly forwardedto 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.

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 asVXLAN 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 theleaf and spine devicesare 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 Ais incorrect because the entire fabric infrastructure must be "VXLAN aware" in terms of MTU settings and routing capability to support the overlay.Option Dis 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.

The exhibit illustrates anEVPN-VXLANfabric using multi-homing. Server1 is dual-homed to Leaf1 and Leaf2 using anEthernet 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 aDesignated Forwarder (DF). For a given ESI, only one leaf switch is elected as the DF.

The exhibit explicitly states thatLeaf2 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 incorrectbecause in a standard ingress replication or multicast-based underlay, all VTEPs in the VNI receive the broadcast.

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

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.

When integrating a QFX Series switch into an EVPN-VXLAN IP fabric, specific BGP and EVPN hierarchy configurations are required to establish the control and data planes:

EVPN Encapsulation (Option A):In Junos OS, the encapsulation vxlan statement must be explicitly configured under the protocols evpn hierarchy. This defines that the EVPN control plane will use VXLAN as the data plane encapsulation method rather than MPLS.

BGP Address Family (Option C):EVPN uses Multiprotocol BGP (MP-BGP) to distribute reachability information. For the control plane to function, you must enable the EVPN signaling address family under the BGP protocol using the command set protocols bgp group family evpn signaling.

Incorrect Options:Option Bis incorrect because family vpls is used for traditional VPLS signaled by BGP, not for EVPN-VXLAN.Option Dis incorrect because while the loopback interface must be reachable, it is typically advertised via anIGP(like OSPF or IS-IS) to provide the underlay connectivity that BGP then rides upon; BGP itself does not "advertise" the loopback to establish the initial peerings.