Duplicate multicast frames appear on a multihomed municipal Ethernet Segment after a change. Which EVPN multicast interaction should engineers review first?
Select an answer to reveal the explanation.
Short Explanation
Two leaves both shoving the same multicast onto a dual-homed server segment is a classic DF/ESI foul. Fix who is allowed to forward into that ES before tweaking underlay hellos or Type-5 loopbacks. Multihoming discipline stops the echo.
Full Explanation
On a multihomed Ethernet Segment, only the Designated Forwarder should inject BUM/multicast onto the ES toward the CE; non-DF peers must not forward the same frames onto the wire. Duplicate multicast on a municipal ES after a change commonly points to DF election or ESI multihoming rules failing—mismatched ESI, split ES views, or DF timer/parameter skew. Review DF and ESI behavior first. Type-5 export policy for underlay loopbacks is an unrelated L3/underlay concern. OSPF hello timers on spines affect underlay adjacency, not ES DF election directly. ARP suppression timers on orphan ports do not explain duplicate multicast injection on a multihomed segment. Exam caveat: duplicates can also come from loops or dual-active miswires that look like EVPN problems—validate physical ESI membership and lacp/EVPN multihoming mode alongside DF state. Operational check: display DF election results for the ESI on both city leaves, confirm identical ESI values, generate multicast toward the CE, span the access ports, and verify a single forwarder; then withdraw one peer and confirm DF failover without sustained duplicates. Include ESI DF state in the city NOC dashboard for multihomed public-safety servers so duplicate BUM is caught before users report it.