A township still runs an underlay multicast group for VXLAN BUM delivery between civic VTEPs. What role does that multicast underlay play in a classic VXLAN design?
Select an answer to reveal the explanation.
Short Explanation
Think of underlay multicast as the township’s shared megaphone for flood traffic—one BUM shout fans out to every VTEP that joined the group. That is the classic way VXLAN shared broadcast, unknown unicast, and multicast without building a unicast copy per remote leaf. It is not an encryption feature and it is not limited to Type-5 routes.
Full Explanation
In classic VXLAN designs still seen in some township fabrics, an underlay multicast group distributes BUM—broadcast, unknown unicast, and multicast—so civic VTEPs share multi-destination overlay traffic without the ingress VTEP head-end replicating a separate unicast copy to every peer. That same multicast distribution historically supported flood-and-learn discovery: a single encapsulated BUM packet reaches interested remote VTEPs via the underlay group mapped to the VNI.
Underlay multicast does not replace VNIs or convert every leaf into a Layer-3-only gateway; VNIs remain the overlay segment identifiers. Multicast does not encrypt tenant MAC addresses inside IPsec before spines—confidentiality needs separate crypto designs. Multicast BUM is not required only for EVPN Type-5 routes and unused for Layer-2 VNIs; it is fundamentally an L2 multi-destination delivery tool in classic VXLAN.
Exam caveat: modern EVPN-VXLAN often prefers ingress replication, yet JN0-683 still expects you to know multicast’s classic role for BUM distribution versus HER.
Operational check: if the civic pod still uses multicast BUM, verify VTEP-to-group mapping and PIM state for those underlay groups; generate ARP broadcast and confirm remote VTEPs receive multicast-encapsulated copies rather than unexplained per-VTEP unicast fan-out from the ingress leaf.