A public-works fabric must deliver broadcast, unknown unicast, and multicast (BUM) frames to other VTEPs in a VNI. What data-plane behavior is required?
Select an answer to reveal the explanation.
Short Explanation
BUM is the city megaphone—more than one listener needs a copy. VXLAN either blasts via underlay multicast or the ingress leaf photocopies the frame to each interested VTEP (head-end replication). One silent unicast to a random leaf won’t wake the whole VNI.
Full Explanation
A public-works fabric delivering BUM frames to other VTEPs in a VNI must replicate those frames to the appropriate remote VTEPs using ingress replication or underlay multicast groups for that VNI. Multi-destination overlay traffic has to reach all interested VTEPs so ARP/ND and unknown-unicast learning behaviors continue to work across the municipal pod.
BUM frames are not rewritten as unicast only to the lowest VTEP IP and never replicated. BUM frames do not stay on the originating leaf because VXLAN somehow forbids multi-destination traffic. BUM frames are not converted to GRE keepalives between spines before any leaf sees them.
Exam caveat: know which BUM mode the civic fabric uses—head-end replication versus underlay multicast—because capacity planning and troubleshooting differ sharply.
Operational check: identify BUM mode in configuration, send a broadcast on a test VNI, and capture either unicast VXLAN copies to each remote VTEP or a single underlay multicast copy as designed; confirm remote leaves receive and bridge the BUM frame. Measure BUM bandwidth at scale before adding many VTEPs to a wide public-works VNI. If ARP fails remotely, inspect flood lists or multicast group state before host troubleshooting.