A city fabric enables BGP add-path so equal-cost EVPN Type-2 paths from multiple VTEPs stay visible in the RIB. What overlay outcome does that primarily support?
Select an answer to reveal the explanation.
Short Explanation
Think of add-path like keeping every equally good exit lane on the city map instead of erasing all but one. For EVPN, that means multiple equal-cost overlay next hops can stay installed so multipath works. Suppressing alternates, dumping MBGP, or dropping VXLAN misses the point.
Full Explanation
BGP add-path for EVPN allows a route reflector or peer to advertise more than one path for the same NLRI so equal-cost Type-2 next hops from multiple VTEPs remain visible in the RIB instead of being suppressed to a single best path. On a municipal fabric that needs overlay multipath toward dual-homed or parallel egress VTEPs, add-path preserves those alternate overlay next hops for forwarding. It does not replace Multiprotocol BGP with PIM-SM. Forcing every leaf to use a unique RD is a different design lever and does not make add-path unnecessary when the goal is multiple paths for the same host or ES context as reflected. Disabling VXLAN encapsulation to fall back to pure VLAN flooding abandons the EVPN-VXLAN architecture. Exam caveat: add-path must be enabled consistently on RR and clients, and multipath must also be allowed in forwarding—advertising extra paths without multipath install still yields one active path. Operational check: from two city leaves advertising the same multihomed MAC via EVPN, confirm the RR shows multiple paths with add-path, that a remote leaf installs multipath next hops as designed, and that withdrawing one path shifts traffic without a full reconvergence blackhole.