In a VXLAN segment using data-plane learning, what does each VTEP learn as two hosts complete their first ARP exchange?
answer
- the request travels as a flood
- the reply travels unicast
- learning happens on decapsulation
- inner source, outer source
basics
~20 sHost A's ARP broadcast is flooded to every VTEP in the VNI, so each learns A's MAC behind A's VTEP. B's unicast reply goes to A's VTEP alone, which learns B's MAC behind B's VTEP; afterwards both directions are known unicast.
solid answer
~40 sHost A broadcasts an ARP request. VTEP1 learns A on its local port, encapsulates the frame with the segment's VNI and floods it — to the VNI's multicast group or as one copy per peer — with its own address as outer source. Every VTEP hosting the VNI, VTEP2 and VTEP3 alike, decapsulates it, records `(VNI, MAC-A) → VTEP1` and delivers the broadcast locally. B answers with a unicast ARP reply; VTEP2 already knows where A lives, so it sends one unicast VXLAN packet to VTEP1, which learns `(VNI, MAC-B) → VTEP2`. From then on both directions travel known unicast. VTEP3, though, now holds an entry for A that its hosts may never use, and it has learned nothing about B.
code
pseudocode · 21 lineson_local_frame(vni, frame, port):
local_table.learn(vni, frame.src_mac, port)
if local_table.has(vni, frame.dst_mac):
forward_to_port(local_table.port(vni, frame.dst_mac), frame)
else if remote_table.has(vni, frame.dst_mac):
send_unicast(remote_table.vtep(vni, frame.dst_mac), vni, frame)
else: # broadcast, multicast or unknown unicast
flood_local_ports(vni, frame, except_port = port)
flood_to_peers(vni, frame) # VNI's group, or one copy per peer VTEP
on_vxlan_packet(outer_src_ip, vni, frame):
if not serves(vni):
drop(frame)
return
remote_table.learn(vni, frame.src_mac, outer_src_ip)
if frame.dst_mac is broadcast or multicast:
flood_local_ports(vni, frame) # never sent back into the overlay
else if local_table.has(vni, frame.dst_mac):
forward_to_port(local_table.port(vni, frame.dst_mac), frame)
else:
drop(frame) # no local host owns that MACgo deeper
Recall that the request floods and the reply travels unicast, and that a VTEP learns a remote MAC from packets it receives, not from packets it sends.
Walk the six steps with addresses: local learning at VTEP1, the flood, learning at every receiving VTEP, the unicast reply, and VTEP1 learning B from that reply.
Point out what the walk leaves behind: entries at VTEP3 nobody uses, no entry for B anywhere but VTEP1, and floods returning whenever an entry ages out.
Use the walk to argue about table pressure and flood volume as hosts and VTEPs multiply, and about what a control plane that pre-populates entries would remove.
## The setup RFC 7348 describes VXLAN with **data-plane learning**: a **VTEP** (VXLAN Tunnel End Point) learns which remote VTEP a host lives behind by watching the packets it decapsulates. The clearest way to see it is to trace one ARP exchange between two hosts that have never spoken. Three VTEPs host the same segment, **VNI 5010**, which the management layer has mapped to the documentation multicast group `233.252.0.10`: | Element | Address | Hosts in VNI 5010 | |---|---|---| | VTEP1 | `10.0.0.1` | host A: MAC `00-00-5E-00-53-0A`, IP `10.1.1.10` | | VTEP2 | `10.0.0.2` | host B: MAC `00-00-5E-00-53-0B`, IP `10.1.1.20` | | VTEP3 | `10.0.0.3` | host C, which takes no part | ## Step by step 1. **A broadcasts an ARP request** asking who has `10.1.1.20`. The destination MAC is the broadcast address. 2. **VTEP1 learns A locally** — MAC-A on the port it arrived from, in VNI 5010 — just as a bridge would. 3. **VTEP1 floods it.** A broadcast has no single destination, so VTEP1 encapsulates it with VNI 5010 and sends it to `233.252.0.10` (or, with ingress replication, one unicast copy each to `10.0.0.2` and `10.0.0.3`). The outer source IP is `10.0.0.1` either way. 4. **VTEP2 and VTEP3 decapsulate and learn.** Each records `(5010, MAC-A) → 10.0.0.1` and delivers the broadcast to its local hosts in the segment. RFC 7348 §4.2 points out that the reply can go unicast precisely because of the mapping "learned earlier through the ARP request". 5. **B sends a unicast ARP reply** to MAC-A. VTEP2 looks up `(5010, MAC-A)`, finds `10.0.0.1`, and sends **one unicast VXLAN packet** to VTEP1. No flood. 6. **VTEP1 decapsulates and learns** `(5010, MAC-B) → 10.0.0.2`, then delivers the reply to A. ## The tables afterwards | VTEP | Remote entries in VNI 5010 | Learned from | |---|---|---| | VTEP1 | MAC-B → `10.0.0.2` | the unicast ARP reply | | VTEP2 | MAC-A → `10.0.0.1` | the flooded ARP request | | VTEP3 | MAC-A → `10.0.0.1` | the same flood, although its hosts never asked | When A now sends to B, VTEP1 finds MAC-B and sends unicast to VTEP2; RFC 7348 §4.1 notes that the receiving VTEP keeps learning from those packets too, so the reply needs no "unknown destination" flooding. ## Why the key includes the VNI The entry is keyed by **VNI and MAC**, not by MAC alone. RFC 7348 §4 allows overlapping MAC addresses in different segments because the VNI scopes the inner frame, so the same MAC can sit behind VTEP1 in one VNI and behind VTEP3 in another without confusion. Learning reads the **outer source IP**, not the outer source MAC: across a routed underlay the outer MAC belongs to the last router hop and says nothing about the remote VTEP. ## What the walk shows about the model - **Floods teach everybody.** Every VTEP in the segment learned A, whether or not it needed to; table space fills with entries that may never be used. - **Unicast teaches one VTEP.** Only VTEP1 learned B, because the reply travelled unicast. VTEP3 still floods if one of its hosts sends to B. - **Broadcasts never stop flooding.** A later ARP request from C for B is flooded again, however many entries exist. - **Entries are soft state.** A VTEP ages out entries that see no traffic, like a bridge; the timer is an implementation choice. When an entry ages out, the next frame to that MAC is unknown unicast and floods until the host's traffic relearns it. - **The delivery method does not change the learning.** Whether the request went to the group or as two unicast copies, its outer source IP was `10.0.0.1`, so every receiving VTEP learned the same entry. - **Received floods are not re-flooded.** A VTEP delivers a decapsulated BUM frame only to its local ports, never back into the overlay; RFC 7365 lists a split-horizon mesh among the rules that keep overlay flooding loop-free. The pseudocode below shows the two paths a VTEP runs, with the learning step on the receive side.
- Why does VTEP3 hold an entry for host A when none of its hosts talked to A?A's ARP request was flooded to every VTEP hosting VNI 5010, and a VTEP learns on decapsulation, before it knows whether any local host cares. Flood-and-learn therefore fills tables with entries driven by other hosts' broadcasts. They cost table space and age out if no traffic refreshes them.
- VTEP2's entry for host A ages out while only B is sending to A; what happens next?B's next frame to MAC-A is unknown unicast at VTEP2, so VTEP2 floods it to every VTEP in the segment. VTEP1 delivers it to A; the other VTEPs discard it because no local host owns MAC-A. The entry returns as soon as any frame from A reaches VTEP2, such as A's next reply to B.
- Can two VNIs contain the same MAC address without confusing a VTEP?Yes. RFC 7348 lets segments reuse MAC addresses because the VNI scopes the inner frame and traffic never crosses between segments. The VTEP keys its tables by VNI and MAC together, so the same MAC can map to different VTEPs in different VNIs.
saying these in an interview costs you the question
- The ARP reply is flooded like the request, because it is also an ARP packet.
- VTEP1 learns where host B lives from the ARP request it flooded itself.
- A VTEP learns the remote host's IP address against the VTEP, like a route.
- The learned entry points at the outer source MAC of the received packet.
- Only the VTEP behind the target learns anything from a flooded ARP request.
- After the first exchange, later ARP broadcasts in that segment are sent unicast.