EVPN practice questions

Route Type 2 with MAC mobility extended community

Why it fails: MAC mobility handles MAC move detection and sequence numbers, not multi-homing load balancing aliasing.

Route Type 4 (Ethernet Segment Route)

Why it fails: Type 4 routes perform Designated Forwarder (DF) election, not per-flow unicast load-balancing/aliasing.

Route Type 3 (Inclusive Multicast)

Why it fails: Type 3 routes set up BUM tunnels, not load balancing for unicast traffic.

no-normalization

Why it fails: This is not a standard configuration statement related to EVPN Type-3 route imports.

multicast-snooping

Why it fails: Multicast snooping is used for optimizing BUM traffic locally, not for basic EVPN Type-3 route import.

vtep-source-interface lo0.0

Why it fails: While required for VXLAN encapsulation, missing vtep-source-interface prevents termination, not the import of Type-3 routes specifically.

BGP AS path prepending

Why it fails: AS path prepending influences BGP best-path selection, not the EVPN DF election, which hashes ESI and PE ordinal values. It would be correct when steering outbound traffic across multiple WAN links, not for forcing a DF role change.

Route Distinguisher value

Why it fails: The route distinguisher only makes EVPN routes unique across VRFs; it plays no part in the DF election hash, so altering it leaves the DF unchanged. It would be the right field to adjust when separating overlapping EVPN route targets between tenants.

Router ID of the BGP speaker

Why it fails: The DF election hash uses the Ethernet Segment Identifier and the ordinal position of each PE's IP address, not the BGP router ID, so changing it does not alter the election outcome. Router ID matters for BGP peer selection and route reflection, not EVPN DF roles.

lo0.0

Why it fails: lo0.0 acts as the VTEP source IP source address, but is not the interface directly bound per VNI bridge domain.

gre0

Why it fails: gre0 is used for Generic Routing Encapsulation tunnels, not EVPN-VXLAN.

fxp0

Why it fails: fxp0 is the out-of-band management interface on Junos devices.

show bridge mac-table

Why it fails: The bridge MAC table shows only locally learned Layer 2 addresses and forwarding state, revealing nothing about EVPN route generation or export to the remote VTEP. It is tempting because it is the standard command for confirming local MAC learning, which is correct when the fault lies in bridging rather than EVPN advertisement.

show bgp summary

Why it fails: BGP summary reports peer session state and prefix counts, not per-EVPN-instance MAC-VRF route generation or export. It is tempting because it is the standard first check for adjacency and route exchange problems, which is correct when EVPN peers are down rather than routes failing to export.

show evpn database

Why it fails: The EVPN database displays locally learned MAC-VRF entries and their states, but does not confirm the instance is generating and exporting type 2 routes to the remote VTEP. It is tempting because it is the standard first check for MAC learning, which is the correct use when verifying local EVPN entries.

Spanning Tree BPDU protection

Why it fails: BPDU protection shuts down ports receiving unexpected BPDUs, unrelated to EVPN MAC churn.

Fast-reroute backup paths

Why it fails: FRR protects against link or node failures, not MAC address flapping.

BGP route flap damping

Why it fails: BGP route flap damping suppresses unstable prefixes based on withdrawal frequency, but EVPN MAC mobility handles MAC-specific churn.

Route Type 2

Why it fails: Route Type 2 is the MAC/IP advertisement route.

Route Type 3

Why it fails: Route Type 3 is the Inclusive Multicast Ethernet Tag route.

Route Type 1

Why it fails: Route Type 1 is the Ethernet A-D route.

encapsulation-source-interface fxp0.0;

Why it fails: fxp0 is out-of-band management and cannot be used as a VTEP data plane source.

vxlan-source-ip lo0.0;

Why it fails: This is not a valid Junos configuration syntax.

tunnel-source loopback 0;

Why it fails: This syntax resembles other vendor CLIs, not Junos OS.

protocols bgp group <name> family evpn encapsulation vxlan

Why it fails: BGP EVPN family configuration negotiates route types and NLRI, but the encapsulation attribute advertised is derived from the EVPN instance's VNI and bridge-domain settings, not set here. It is tempting because encapsulation vxlan appears under the family, yet that only enables EVPN signalling, not the local VXLAN data-plane encapsulation.

interfaces lo0.0 family vxlan

Why it fails: The loopback interface carries the router's control-plane and VTEP source addressing; family vxlan is not a valid encapsulation definition for the EVPN instance's data plane. It is tempting because VTEPs are loopback-based, but the encapsulation type is bound to the bridge-domain VNI, not the lo0 unit.

bridge-domains <name> vni <id> encapsulation mpls

Why it fails: VXLAN encapsulation is configured under the EVPN instance's bridge-domain via the vni statement, not with an encapsulation mpls keyword; that keyword selects MPLS transport for the VNI, which mismatches the VXLAN data plane. It is tempting because MPLS encapsulation is valid for EVPN-MPLS bridge-domains, but this scenario requires VXLAN.

It advertises host IP prefixes for inter-subnet routing.

Why it fails: Host IP prefix advertisement for inter-subnet routing is performed by Route Type 5 (IP Prefix Route), which carries the IP prefix and gateway address. Route Type 3 carries only the Inclusive Multicast Ethernet Tag and originator IP for BUM replication. It would be correct if the question asked about inter-subnet routing.

It dynamically triggers MAC mobility sequence number increments.

Why it fails: MAC mobility sequence numbers are carried in Route Type 2 (MAC/IP Advertisement Route), which signals a MAC moving between PEs. Route Type 3 carries no MAC addresses, only the Inclusive Multicast Ethernet Tag and originating PE address for BUM traffic. It would be correct if the question concerned MAC mobility handling.

It performs Designated Forwarder election on multi-homed links.

Why it fails: Designated Forwarder election is driven by Route Type 4 (Ethernet Segment Route), which carries the ES-Import extended community used for DF election on multi-homed links. Route Type 3 carries only the Inclusive Multicast Ethernet Tag and originator IP, used to build BUM flooding trees. It would be correct if the question asked about DF election.

All-active multi-homing restricts host MAC learning to only one PE at a time.

Why it fails: Hosts behind all-active multi-homed segments can be learned across multiple PEs, handled via aliasing and split horizon.

In all-active mode, only the Designated Forwarder handles unicast traffic from the core.

Why it fails: The DF handles BUM traffic; unicast traffic is load-balanced across all active PEs via aliasing.

All-active multi-homing requires Spanning Tree Protocol to block redundant links.

Why it fails: Active-active multi-homing uses EVPN mechanisms rather than STP to utilize all links.

Type-4 Ethernet Segment route

Why it fails: Type-4 routes are used for Designated Forwarder election on multi-homed Ethernet segments. They advertise the Ethernet Segment Identifier and the originating PE's IP address. They have no role in advertising VLAN membership for a VLAN-aware bundle service. Therefore, they cannot address the problem of MAC addresses from one VLAN appearing in another VLAN's MAC table.

Type-3 Inclusive Multicast Ethernet Tag route

Why it fails: Type-3 routes are used to build ingress replication lists for BUM traffic and include the Ethernet Tag for the VLAN. They do not convey the full set of VLANs in a bundle. While they help with BUM forwarding, they are not responsible for advertising VLAN membership in a VLAN-aware bundle service, so they would not resolve the cross-VLAN MAC learning issue.

Type-2 MAC/IP Advertisement route

Why it fails: Type-2 routes carry MAC and IP address reachability information for hosts. They include a VLAN ID in the route, but they do not advertise the bundle of VLANs associated with an EVPN instance. In a VLAN-aware bundle service, the mapping of multiple VLANs to a single EVPN instance is communicated through a different route type, so Type-2 alone cannot prevent the cross-VLAN MAC installation described.

Type 3 route (Inclusive Multicast Ethernet Tag route)

Why it fails: Type 3 routes are used for BUM traffic replication and do not carry host MAC or IP information. They establish multicast tunnels but cannot provide the IP-to-MAC binding required for inter-subnet routing. In this scenario, the remote leaf needs to learn the gateway's MAC and IP to route traffic, which Type 3 does not supply.

Type 4 route (Ethernet Segment route)

Why it fails: Type 4 routes are used for Designated Forwarder election on multi-homed Ethernet segments. They do not carry host MAC or IP information. In this scenario, the requirement is to advertise the gateway's IP-to-MAC binding for inter-subnet routing, which is not the purpose of Type 4 routes.

Type 5 route (IP Prefix route)

Why it fails: Type 5 routes advertise IP prefixes, typically for Layer 3 VPNs or summarized routes, not individual host IP-to-MAC bindings. In this scenario, the host's gateway MAC and IP association is needed for inter-subnet routing, which is a host-specific binding, not a prefix. Using Type 5 would not provide the necessary MAC adjacency information for the remote leaf to route traffic correctly.

EVPN Type 2 routes with MAC and IP binding

Why it fails: Type 2 routes advertise MAC and IP bindings for hosts, which is essential for host reachability but does not advertise subnet prefixes. While Type 2 routes can carry IP information, they are not used for advertising IP prefixes for subnets. For inter-subnet routing, Type 5 routes are specifically designed to advertise IP prefixes, so Type 2 alone would not achieve the goal.

Centralized gateway with anycast IP

Why it fails: A centralized gateway model routes inter-subnet traffic through a central gateway, which can cause tromboning. The scenario explicitly asks to avoid tromboning, so a centralized gateway is not the solution. Anycast IP on a centralized gateway does not distribute routing; it still funnels traffic to the gateway. Thus, this is incorrect for the desired outcome.

IGP routing with OSPF or IS-IS

Why it fails: While an IGP is necessary for underlay reachability, it does not provide the overlay inter-subnet routing capabilities of EVPN. IGP alone cannot distribute subnet information across the EVPN fabric; it is used for VTEP reachability. Without EVPN Type 5 routes, the fabric lacks a mechanism to advertise tenant subnets, so IGP is insufficient for the requirement.

Static routes

Why it fails: Static routes can be used in very small deployments but do not scale and lack dynamic failover. In an EVPN-VXLAN fabric, dynamic routing is preferred for underlay to handle failures and changes. Static routes would require manual configuration for each VTEP, which is impractical. Therefore, static routes are not the common choice.

BGP

Why it fails: BGP is typically used for the overlay to exchange EVPN routes, not for underlay routing. While BGP can be used in the underlay in some designs, it is not the common choice for VTEP reachability due to complexity. OSPF or IS-IS are preferred for underlay because they provide fast convergence and simple configuration. Thus, BGP is not the best answer here.

RIP

Why it fails: RIP is a legacy distance-vector protocol that is not suitable for modern data center underlays due to slow convergence and limited scalability. It is not commonly used in EVPN-VXLAN deployments. The underlay requires a robust IGP like OSPF or IS-IS, so RIP is incorrect.

Ensure that the remote VTEP's loopback address is reachable via the underlay network and that the VXLAN tunnel is up.

Why it fails: Underlay reachability and VXLAN tunnel status are necessary for data plane connectivity but do not influence the advertisement of local MAC addresses via BGP EVPN. Even if the tunnel is down, Type-2 routes should still be advertised if MAC learning occurs. Therefore, this is not the cause of missing Type-2 advertisements.

Confirm that the EVPN instance is configured with a route distinguisher and route target that match the remote VTEPs.

Why it fails: Route distinguisher and route target mismatches would prevent the import of routes on remote VTEPs, but they do not stop the local VTEP from advertising Type-2 routes. The issue described is that local MACs are not being advertised at all, so the problem is likely before route export. Thus, this is not the correct action.

Verify that the VXLAN tunnel interface is included in the EVPN routing instance and that the MAC-VRF instance is correctly associated with the VLAN.

Why it fails: While the VXLAN tunnel interface and MAC-VRF association are important for data plane forwarding, they do not directly affect the advertisement of local MAC addresses via BGP EVPN. Type-2 routes are generated based on MAC learning in the EVPN instance, regardless of the tunnel interface state. This is not the primary cause of missing Type-2 advertisements.

The Type 2 routes are not being imported due to a route target mismatch.

Why it fails: If Type 2 routes are exchanged, they are being imported. A route target mismatch would prevent import, but the scenario indicates that routes are exchanged and presumably installed. The problem is more likely in the data plane encapsulation, such as the VXLAN tunnel interface binding.

The BGP EVPN session is using the wrong address family.

Why it fails: If BGP EVPN sessions are established and Type 2 routes are exchanged, the address family is correctly configured. The issue is likely in the data plane, not the control plane. The scenario states that sessions are established and routes are exchanged, so the address family is not the cause.

The remote VTEP IP address is not reachable.

Why it fails: If the remote VTEP IP is not reachable, BGP EVPN sessions would not be established because they rely on reachability. Since sessions are established, the VTEP IPs are reachable. The issue is likely in the VXLAN data plane configuration, such as the tunnel interface not being bound to the EVPN instance.

The gateway MAC address must be manually configured on each leaf switch and must be different.

Why it fails: The gateway MAC address must be the same on all leaf switches in a distributed anycast gateway. It is typically configured manually but must be identical across all leaves. Using different MACs would cause inconsistent gateway behavior and break the anycast model, leading to routing issues.

Each leaf switch advertises its own unique gateway MAC address via Type 2 routes.

Why it fails: In a distributed anycast gateway, the gateway MAC is the same on all leaf switches, not unique. Advertising unique MACs would break the anycast gateway model, as remote leaves would see multiple MACs for the same IP. The correct behavior is to advertise the shared gateway MAC and IP as a Type 2 route.

Inter-subnet routing is performed only at the spine switches.

Why it fails: In a distributed anycast gateway, inter-subnet routing is performed at the leaf switches, not the spines. Each leaf acts as the gateway for its local hosts, routing traffic locally and then bridging it over VXLAN to the destination leaf. This distributed routing model optimizes traffic flow and reduces latency compared to centralized routing at spines.

The underlay MTU must be set to exactly 9000 bytes to support VXLAN jumbo frames.

Why it fails: While jumbo frames (9000 bytes) can be used and are beneficial for large data transfers, they are not mandatory for VXLAN. Setting MTU to exactly 9000 is not required and may not be supported on all interfaces. The requirement is to have an MTU large enough to avoid fragmentation, which can be achieved with 1600 bytes. Therefore, this statement is overly restrictive and not a general requirement.

The underlay MTU must be set to at least 1500 bytes to accommodate the original Ethernet frame.

Why it fails: An MTU of 1500 bytes is the standard for Ethernet, but VXLAN encapsulation adds overhead. A 1500-byte MTU would cause fragmentation or dropped packets for full-sized frames because the encapsulated packet would exceed 1500 bytes. Therefore, this setting is insufficient for VXLAN traffic and would lead to performance issues and potential connectivity problems.

The underlay MTU must be increased to at least 1550 bytes to account for VXLAN, UDP, and IP headers.

Why it fails: While 1550 bytes may seem sufficient, VXLAN overhead is actually 50 bytes for IPv4 (outer IP 20, UDP 8, VXLAN 8, and inner Ethernet 14). A 1550-byte MTU would allow a payload of 1500 bytes, but it does not account for potential additional overhead such as MPLS or other encapsulations. In practice, a larger MTU like 1600 or 9000 is recommended to provide headroom. Thus, 1550 is a minimal increase but often not enough in real deployments.

Route Distinguisher (RD)

Why it fails: The route distinguisher only makes the EVPN MAC advertisement prefixes unique within the VRF; it does not identify the attachment circuit. It is tempting because RDs are mandatory in EVPN configuration, but the Ethernet Segment Identifier (ESI) is the field that uniquely names the segment, so an RD cannot distinguish individual multi-homed links.

Ethernet Tag ID

Why it fails: The Ethernet Tag ID identifies a broadcast domain or VLAN within an EVPN instance, not the physical attachment circuit itself. It is tempting because it appears in EVPN routes, but the Ethernet Segment Identifier (ESI) is the ten-octet value that uniquely names the segment, which the tag cannot do.

ESI Label Extended Community

Why it fails: The ESI Label Extended Community carries the label used for split-horizon filtering of BUM traffic, not the segment identifier. It is tempting because it is an EVPN multi-homing attribute, but the attachment circuit is uniquely identified by the Ethernet Segment Identifier in the ESI Extended Community.