Ops sees the same MAC advertised from conflicting Ethernet Segment locations and suspects a learning conflict. What awareness should the engineer apply?
Select an answer to reveal the explanation.
Short Explanation
Two places claiming the same MAC is a municipal double-booking — investigate ESI mistakes or loops, do not shrug. Disabling add-path, wiping OSPF, or merging all VNIs does not fix a duplicate-MAC conflict.
Full Explanation
Duplicate MAC advertisements across EVPN—especially for hosts that should be unique—signal a learning conflict: misconfigured ESI multihoming, loops, dual-active servers advertising from unexpected leaves, or mobility gone wrong. The engineer should detect and investigate those conflicting Type-2s rather than ignore them. Treating every duplicate MAC as proof that add-path must be disabled fabric-wide confuses multipath with duplication. Clearing the underlay OSPF database does not correctly regenerate EVPN Type-2s as a duplicate fix. Changing all VNIs to the same value to make duplicates intentional anycast destroys tenant isolation and is not a troubleshooting step. Exam caveat: some anycast gateway MACs are intentionally identical across ERB leaves—distinguish designed anycast IRB MACs from accidental duplicate server MACs on the municipal fabric. Operational check: list EVPN MAC routes that show multiple active advertisers for the same non-anycast host, correlate to ESI and port state, fix the wiring or ESI, and confirm a single authoritative Type-2 remains. Open an incident for unexpected duplicate non-anycast MACs rather than clearing tables repeatedly—duplicates are usually wiring or ESI bugs.