Multicast in VXLAN Fabrics: Let the Control Plane Do the Work
VXLAN extends Layer 2 segments across an IP fabric by encapsulating frames between VTEPs. Unicast traffic can follow learned endpoint reachability, but broadcast, unknown unicast, and multicast traffic—collectively BUM—still needs a replication method. The design can use underlay multicast or ingress replication, and BGP EVPN supplies control-plane information that helps VTEPs know which remote peers participate. Those mechanics sit directly inside the network objectives of the 350-601 DCCOR exam and the CCNP Data Center certification.
The topic becomes confusing when “multicast” is used to mean several different things. Underlay multicast may be used only to replicate BUM traffic between VTEPs. Tenant routed multicast is a different problem: actual multicast applications inside tenant networks need group membership and routing across the overlay. Engineers should separate those use cases before choosing protocols or troubleshooting a failed flow.
The useful mental model is to ask where replication happens, how participants are discovered, and what state the underlay must maintain. Once those questions are clear, the choice between multicast replication and head-end replication becomes an architecture trade-off rather than a memorized command.
BUM traffic exists because the destination is not always a single known VTEP
A known remote MAC can be encapsulated toward the VTEP that advertises it. Broadcast traffic, an unknown unicast, or a Layer 2 multicast frame has multiple potential receivers. The ingress VTEP therefore needs a way to send copies to all remote VTEPs participating in that Layer 2 VNI.
That requirement is a consequence of stretching a broadcast domain across an IP underlay. The basic IP addressing and subnetting of the underlay remains ordinary routed connectivity, but VXLAN adds an overlay membership problem: which tunnel endpoints need a copy of this multidestination frame?
Underlay multicast lets the network replicate a single ingress copy
With multicast replication, the ingress VTEP sends BUM traffic toward a multicast group associated with the VNI. The routed underlay builds a multicast distribution tree, and branch points replicate the packet only where paths diverge toward participating VTEPs. This avoids the ingress VTEP creating a separate unicast copy for every remote peer.
The efficiency comes with operational requirements. The underlay must run and troubleshoot multicast routing, VTEPs must join the correct groups, and VNI-to-group mappings must be consistent. The design is attractive at scale when the cost of head-end replication would be high, but it adds PIM and multicast state to the underlay.
Ingress replication moves replication work to the source VTEP
Ingress replication, also called head-end replication, does not require multicast trees in the underlay for BUM transport. The source VTEP creates separate unicast copies and sends one toward each remote VTEP that participates in the VNI. BGP EVPN Type 3 IMET routes help advertise that membership so the source can build its replication list.
This simplifies the routed underlay because it remains unicast-only, but replication work grows with the number of VTEPs. A small or moderate fabric may accept that trade-off, while a very large fan-out can consume more bandwidth and source resources. Architecture is therefore about where the replication cost should live.
EVPN control-plane signaling keeps replication membership dynamic
Without a control plane, administrators would need static knowledge of every remote VTEP participating in each segment. EVPN distributes reachability and membership information so the overlay can adapt as VTEPs and VNIs appear or disappear. IMET routes are central to discovering remote participants for BUM forwarding under ingress replication.
This is the same separation emphasized in modern network architecture: the control plane distributes intent and reachability; the data plane forwards packets according to that state. When BUM forwarding fails, engineers should ask whether the replication list is wrong because signaling failed or whether signaling is correct and the underlay cannot carry the packet.
Tenant multicast is not the same as using multicast for BUM replication
An application may intentionally send multicast traffic to a tenant group and expect receivers in different subnets or VNIs to join. Supporting that traffic can require tenant routed multicast features and additional control-plane state. That is different from an operator choosing multicast in the underlay merely as an efficient transport for generic BUM frames.
Conflating the two leads to poor troubleshooting. A tenant application can fail even when BUM replication is healthy, and a BUM replication problem can occur in a fabric with no multicast applications at all. Start by identifying the traffic role before inspecting group state.
Scale changes the replication trade-off
Ingress replication is operationally attractive because it avoids multicast routing in the underlay, but every additional remote VTEP can add another copy of each BUM frame at the source. Underlay multicast sends fewer copies from the ingress and lets branch points replicate, but it consumes multicast state and requires a multicast-capable operational model.
The decision should consider VTEP count, BUM rate, underlay capabilities, operator familiarity, and future growth. A design that is simple for twenty VTEPs may not remain efficient at two hundred. Conversely, adding underlay multicast to a small fabric may create more operational complexity than the bandwidth savings justify.
Troubleshooting should prove membership before chasing packet loss
For ingress replication, verify the VNI, EVPN Type 3 advertisements, NVE peer state, and the resulting replication list. For multicast replication, verify the VNI-to-group mapping, VTEP joins, PIM neighbors, rendezvous or source-specific behavior as applicable, and multicast routing state through the underlay. Only then does packet capture become easy to interpret.
The general discipline from network troubleshooting still applies: define the expected path and find the first place reality diverges. VXLAN adds overlay and replication state, so the path has more layers than a conventional VLAN but can still be tested systematically.
Control-plane health is part of multicast forwarding health
EVPN reduces flooding by distributing endpoint and VTEP information, but that means BGP state becomes part of the service. Route-policy errors, neighbor failures, VNI mismatches, or stale control-plane state can change who receives BUM traffic even when every physical link is up. Monitoring only interfaces is therefore insufficient.
This is why CCNP Data Center preparation should connect protocol state to packet behavior. Engineers need to know which route types and memberships create the forwarding entries, then verify that those entries correspond to the intended fabric design.
ARP and neighbor-discovery suppression can reduce some BUM traffic by allowing the fabric to answer known endpoint resolution requests from control-plane information rather than flooding every request across the segment. That does not eliminate BUM, but it changes the volume and type of traffic that needs replication. Designs should account for these suppression mechanisms when estimating multicast or ingress-replication load.
Multicast group allocation is another scaling consideration for underlay replication. Mapping many VNIs to a small group pool increases sharing, while assigning very granular groups consumes more multicast state. The right balance depends on platform scale and traffic patterns. Operators should know how the controller or fabric manager allocates groups so a scale limit does not appear unexpectedly as new networks are added.
Ingress replication also has a failure characteristic that is easy to overlook: the source VTEP must have an accurate remote-peer list. If EVPN signaling is incomplete, the underlay can be perfectly healthy and still omit a receiver because the source never creates that unicast copy. Troubleshooting therefore needs to distinguish underlay reachability from overlay membership rather than proving only one of them.
For tenant multicast, receiver membership and routed multicast state add another layer. The engineer may need to prove that a receiver joined the group, that the first-hop device learned the membership, that the overlay distributed the relevant multicast information, and that replication reached the correct remote VTEPs. The path is different from ordinary unknown-unicast flooding even though both may share VXLAN tunnels.
Capacity testing should generate realistic BUM patterns. A quiet lab with a few ARP requests will not reveal the cost of a large broadcast domain or a bursty multicast application. Measure source replication rate, underlay link utilization, VTEP CPU or hardware counters, and receiver delivery as the number of VTEPs grows. The results show whether the chosen replication model still fits the intended scale.
The replication decision should also be revisited as the fabric evolves. A design that began with ingress replication may add enough VTEPs or BUM-heavy segments that underlay multicast becomes attractive, while a simplified fabric may move the opposite direction. Because the choice affects operational tooling and failure modes, migration should be tested as an architectural change rather than treated as a toggle in the fabric manager.
The best replication model is the one the team can operate at the required scale
Underlay multicast and ingress replication are both legitimate approaches. One moves replication into the routed network; the other keeps the underlay simpler and duplicates traffic at the source. Neither choice removes the need to understand BUM, VTEP membership, and EVPN signaling.
The durable DCCOR skill is to separate the overlay problem from the underlay transport and then reason about scale, failure, and observability. Once engineers know who should receive a copy and where that copy is created, multicast in a VXLAN fabric becomes a traceable forwarding process rather than a collection of acronyms.