Architects compare ingress replication versus underlay multicast trees for BUM on the municipal EVPN fabric. Which tradeoff statement is most accurate?
Select an answer to reveal the explanation.
Short Explanation
Ingress replication is the simple underlay story with more photocopying at the sending leaf; underlay trees flip that—fewer copies, more multicast plumbing. Pick the tradeoff for the city's scale. Neither mode trashes Type-2 MAC learning.
Full Explanation
Ingress replication copies BUM at the ingress VTEP toward each remote IMET member over VXLAN unicast tunnels. That simplifies the underlay—no PIM trees required—but increases head-end replication load and bandwidth as VTEP count grows. Underlay multicast trees can reduce the number of copies the ingress must generate, at the cost of building and operating multicast in the IP fabric. That tradeoff is the accurate comparison for a municipal EVPN fabric. Ingress replication does consume head-end bandwidth; claiming it never does is wrong. Underlay multicast trees do not eliminate the EVPN control plane; EVPN still advertises membership and host state. Neither mode requires disabling Type-2 MAC learning. Exam caveat: large city fabrics may start with ingress replication and revisit underlay multicast only when BUM or IPTV scale demands it—know the operational break points. Operational check: measure replication list size and ingress leaf CPU/bandwidth during controlled BUM tests; document whether underlay multicast is in use; validate that Type-2 unicast still works independently of the BUM transport mode. Revisit the tradeoff when leaf VTEP counts grow; what is fine for a small city hall fabric may overwhelm ingress replication at metro scale.