Engineers debate why ingress replication lists on municipal leaves grow as more VTEPs join each VNI. What scaling relationship should they cite?
Select an answer to reveal the explanation.
Short Explanation
Ingress replication is like the mayor’s office printing one flyer per branch—more branches, more copies. As VTEPs join a VNI, that replication list and the BUM fan-out work grow with them. It is not an STP sideshow and it does not magically stay at one remote leaf forever.
Full Explanation
Engineers debating why ingress replication lists on municipal leaves grow as more VTEPs join each VNI should cite this scaling relationship: with ingress replication, BUM fan-out work and replication-list size grow with the number of remote VTEPs that share the VNI. Each additional interested VTEP means another unicast VXLAN copy from the ingress leaf—an explicit control- and data-plane scale consideration for large civic broadcast domains.
Replication list size does not shrink automatically to one entry no matter how many VTEPs join. Each new VTEP does not remove all prior list entries because EVPN somehow allows only a single remote leaf per VNI. List growth is not caused only by Spanning Tree topology changes; it tracks VTEP membership count for that VNI in the EVPN fabric.
Exam caveat: HER scale grows with VTEPs-per-VNI membership, which motivates multicast underlays, optimized EVPN multicast features, or careful VNI scoping during capacity planning.
Operational check: track replication-list length for a busy civic VNI as leaves are added in lab; measure BUM encapsulation load at the ingress leaf and decide whether VNI scoping or multicast optimization is required before production growth.