CCNA Evpn Questions

Without a valid instance-type, the routing instance cannot assume the EVPN role, so it never builds the EVPN route table or import policies that process Type-2 MAC/IP routes. The instance-type statement defines the protocol family and import behaviour, making its absence or misconfiguration a direct cause of import failure.

Type 2 routes are specifically designed to advertise MAC addresses and optionally IP addresses along with the associated VXLAN VNI and next-hop. When Host A's MAC is learned locally, the leaf generates a Type 2 route that is distributed via BGP EVPN to all other leaf devices. Remote leaf devices install this route, enabling them to forward unicast traffic directly to the correct leaf without flooding.

If ESIs match but BGP session stability or Type-4 route advertisements fluctuate, the DF election re-runs continuously, causing churn.

ARP suppression works by having the local VTEP maintain a cache of IP-MAC bindings from EVPN Type-2 routes. When an ARP request is received for an IP in the cache, the VTEP responds on behalf of the target, suppressing the need to flood the ARP request across the VXLAN fabric. This reduces broadcast traffic and is a key feature of EVPN.

Type 5 carries IP prefix reachability rather than MAC or host information, so it maps cleanly onto L3VPN semantics. Advertising tenant prefixes into an MPLS backbone and between subnets lets EVPN function as the control plane for routed inter-subnet traffic.

Identical virtual gateway MAC and IP addresses on every leaf IRB interface create a distributed anycast gateway, so hosts retain one default gateway regardless of which VTEP they attach to. This satisfies the inter-subnet forwarding requirement by enabling seamless VM mobility and symmetric routing across leaf VTEPs.

MAC limit features with action drop protect bridge domains from MAC flooding and unauthorized source MACs.

Route Type 2 carries the MAC/IP Advertisement, binding a host MAC to its IP address and forwarding context. Type 1 advertises Ethernet Auto-Discovery, Type 3 carries Inclusive Multicast, and Type 4 handles Ethernet Segment routes, so Type 2 uniquely satisfies the MAC-plus-IP requirement.

The MAC Mobility Extended Community carries a sequence number that increments each time a host moves between provider edge routers, letting all PEs order movements and suppress stale or looping advertisements. This delivers the loop-free MAC movement tracking the stem describes.

In a distributed gateway, all leaf switches that participate in the same subnet use a common virtual MAC address for the anycast gateway. This allows hosts to use the same default gateway IP and MAC regardless of which leaf they are attached to. When a host sends traffic to the gateway, it is handled locally by the attached leaf, providing optimal routing and avoiding tromboning. This is a fundamental characteristic of anycast gateway.

Type 1 routes carry the Ethernet Segment Identifier and can be advertised per-EVI or per-Ethernet Segment, satisfying the stem's requirement for valid EVPN auto-discovery behaviour. Per-ES advertisement supports multihoming split-horizon and designated-forwarder election, while per-EVI advertisement applies to single-homed access, so both granularities are legitimate.

This command displays detailed information about Ethernet segments, including the DF election state, the designated forwarder, and the backup forwarder. It is essential for troubleshooting DF election issues because it shows which PE is elected as DF for each Ethernet segment and the reason for the election result. This directly addresses the scenario's need to verify DF state.

The 'show evpn database' command on MX Series displays MAC addresses learned through both the EVPN control plane (Type 2 routes) and the data plane, across every bridge domain, satisfying the requirement to view local and remote entries together.

The Ethernet Segment Identifier uniquely identifies the attachment circuit to the Ethernet segment, and all PE routers multi-homing that segment must share the same ESI value. This satisfies the requirement for a unique identifier in all-active EVPN multi-homing.

The 'show interfaces vtep' command displays the status of the virtual tunnel endpoint interface, including its operational state, encapsulation, and associated VXLAN network identifiers. It helps verify that the VTEP is up and properly configured. If the VTEP is down, VXLAN tunnels cannot be established, preventing traffic forwarding even if EVPN routes are present. This command is essential for diagnosing data plane issues in EVPN-VXLAN.

Route Type 5 carries IP prefix routes, enabling inter-subnet forwarding between IP-VRFs across the EVPN fabric. Unlike Types 2 and 3, which advertise MAC/IP and inclusive multicast respectively, Type 5 satisfies the stem's requirement for IP prefix reachability in an IP-VRF-to-EVPN integration.

In all-active multi-homing, the DF election determines which PE forwards BUM traffic to the multi-homed device. Type 4 routes carry the Ethernet Segment Identifier (ESI) and are used in the DF election process. The elected DF is responsible for forwarding BUM traffic, while all PEs can forward known unicast traffic based on locally learned MAC addresses or Type 2 routes.

Type 3 routes advertise the VTEP IP address and are used for BUM traffic replication. They include the originating VTEP's IP address and the VNI, allowing remote VTEPs to build a multicast or ingress replication list. This enables VXLAN tunnels to be established for BUM traffic, which is essential in an EVPN-VXLAN fabric.

The 'family evpn signaling' configuration under the BGP neighbor enables the EVPN address family, allowing the routers to exchange EVPN routes. This is the correct and required configuration for EVPN-VXLAN fabrics. Without it, BGP will not negotiate the EVPN capability, and no EVPN routes will be exchanged, breaking the control plane for MAC and IP reachability.

For traffic to be forwarded to a remote VTEP, a VXLAN tunnel must be established. This requires receiving the remote VTEP's Type-3 route. If the Type-3 route is missing, the local VTEP will not have a tunnel to the remote VTEP, and traffic will be dropped even if the MAC address is known via Type-2. This is the most likely cause.

Type 2 EVPN routes distribute MAC addresses through the control plane, so the ingress PE already knows the destination MAC and forwards as known unicast. This control-plane learning removes the need to flood unknown unicast across the core for multi-homed hosts.

Type 2 routes populate the control plane, but forwarding requires a valid VNI-to-tunnel mapping and resolvable next hop. If that mapping or resolution is incomplete, the route appears in bgp.evpn.0 yet traffic cannot be encapsulated, explaining the data-plane drop despite control-plane presence.

Route targets are extended communities attached to EVPN routes, determining which VRFs import or export them. Configuring matching import and export targets on each PE establishes the routing-instance-level reachability required for EVPN route exchange across the peer session.

EVPN Route Type 3 carries the Inclusive Multicast Ethernet Tag route, advertising each PE's participation in a broadcast domain. Receiving PEs build the ingress replication list from these advertisements, enabling BUM traffic delivery without multicast underlay support.

The DF is responsible for sending BUM traffic down to the attached customer site.

To exchange EVPN routes, BGP must be configured with the evpn signaling address family. This enables the PE routers to negotiate and exchange EVPN NLRIs. Without this configuration, BGP will not carry EVPN routes, and the fabric cannot learn remote MAC or IP addresses. This is a fundamental requirement for EVPN signaling in Junos.

EVPN routing instances are declared under the routing-instances hierarchy, where the instance-type statement set to evpn activates EVPN address families and enables the corresponding BGP and VXLAN signalling. This is the exact hierarchy Junos requires for an EVPN instance.

show route table bgp.evpn.0 displays the BGP EVPN routing table, including route types and next hops, confirming which EVPN routes were received and installed. This satisfies the stem's requirement for essential diagnostic information about EVPN routing tables in Junos OS.

In All-Active multihoming, the DF election per Ethernet segment ensures that only one PE (the DF) forwards BUM traffic to the multihomed device, preventing duplicate packets. However, known unicast traffic can be forwarded by any PE that has the MAC address in its EVPN table, allowing load balancing. This is the correct behavior for EVPN All-Active multihoming on Junos.

Route Type 5 carries IP prefix routes, allowing the data centre gateway to translate between EVPN and the IP-VRF MPLS L3VPN backbone. Types 2 and 3 advertise MAC or MAC/IP bindings and inclusive multicast, which cannot convey prefix reachability across the two domains.

With distributed gateway IRB, every leaf terminates inter-subnet traffic locally using a shared virtual MAC and IP address as the default gateway. This symmetric, anycast-style design avoids tromboning traffic to a centralised gateway, reducing latency and improving forwarding efficiency across the EVPN-VXLAN fabric.

Type-4 Ethernet Segment routes carry the ESI and DF election capability, letting PE routers run the DF election algorithm per Ethernet segment. This satisfies the all-active requirement that only one PE forwards BUM traffic for a given segment, preventing duplicate flooded frames while all PEs remain active for known unicast.

EVPN routes such as MAC/IP advertisement and IMET are carried in the BGP EVPN address family, enabled as evpn signalling under the neighbour hierarchy. The inet or inet6 families carry unicast IP routes only, so they cannot distribute EVPN NLRI between PE routers.

The VTEP source address is typically a loopback interface address, which ensures high availability and stability. It must be reachable via the underlay network so that remote VTEPs can establish VXLAN tunnels. This is a standard best practice for EVPN-VXLAN deployments on Junos.

Type 2 advertisements bind a tenant MAC to its associated IP in one NLRI, letting remote PEs install both bridging and routing entries from a single BGP update rather than separate MAC and ARP/ND messages.

In Junos EVPN, each bridge domain maps its VNI under the bridge-domains hierarchy within the routing instance. Placing vni at that level binds the layer-2 domain to its unique EVPN identifier, satisfying the one-VNI-per-bridge-domain requirement.

EVPN MAC mobility relies on sequence numbers carried in Type-2 (MAC/IP Advertisement) routes, allowing every PE to determine the most recent advertisement for a given MAC. When a host moves to another PE, the higher sequence number wins, so stale entries are withdrawn and traffic follows the host, satisfying the requirement to track movement between PEs.

When a multi-homed PE receives BUM traffic from its own Ethernet segment, the receiving PE checks the ESI label; split horizon filtering drops frames whose ESI label matches the local segment, preventing the loop back to the originating PE.