City leaf peers establish BGP EVPN, but large UPDATE messages carrying many Type-2 routes are silently dropped on the path. Which transport health issue is the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
Huge EVPN UPDATEs are like overloaded city buses — if the tunnel is too small, they never arrive. MTU or TCP MSS trouble on the peer path drops those big BGP payloads even when the session looks up. ESI, IRB mode, or matching RTs are different problems.
Full Explanation
Large BGP UPDATE messages carrying many EVPN Type-2 routes are TCP segments that must traverse the underlay path MTU. Path MTU black holes or overly large TCP MSS without clamping commonly cause silent drops of oversized updates, so EVPN sessions stay Established while routes fail to exchange completely. That transport-health issue is the most likely cause among the options when city leaf peers establish EVPN but big updates disappear on path. Missing ESI values on single-homed ports are normal and do not drop BGP UPDATEs. Symmetric IRB on L2-only leaves is an architecture mismatch topic, not the classic silent large-UPDATE symptom. Route targets that match every VRF cause leaks, not silent UPDATE drops. Exam caveat: EVPN bursts after leaf reload can expose MTU problems that small lab tests never hit—test with realistic MAC scale. Operational check: verify underlay Path MTU between municipal leaf and RR loopbacks, enable MSS clamping or fix MTU mismatches, clear BGP EVPN gently, and confirm full Type-2 counts arrive without TCP retransmit storms or incomplete tables. Include EVPN UPDATE scale drills in maintenance windows so Path MTU issues appear in lab, not during a Monday morning MAC storm.