A dual-homed application pair at the water utility uses ESI multihoming with anycast VTEP behavior. At a high level, what does that change in the VXLAN data plane?
Select an answer to reveal the explanation.
Short Explanation
Multihoming with anycast/ESI is like two loading docks sharing one city address for deliveries. Remote leaves steer encapsulated frames toward that shared outer destination rather than picking a random single-homed VTEP. The overlay still uses VXLAN—you’re just choosing the right front door.
Full Explanation
At a high level, ESI multihoming with anycast VTEP behavior for a dual-homed application pair at the water utility influences which outer destination VTEP address encapsulated frames use when reaching the multihomed endpoint. Remote VTEPs can send encapsulated traffic toward a shared next-hop or VTEP address representing the multihomed Ethernet segment while still using VXLAN encapsulation.
ESI and anycast VTEP constructs do not remove the need for any underlay IP address on the leaves. They do not force all BUM traffic to hairpin through a single spine route reflector as their defining data-plane change. They do not disable VNI encapsulation and switch the pair to QinQ only.
Exam caveat: multihoming changes outer destination or next-hop selection for the segment; it does not eliminate underlay addressing or VNIs.
Operational check: verify ESI and anycast VTEP configuration on the dual-homed utility leaves, confirm remote leaves show the shared VTEP next-hop for the segment’s MACs, and failover one leaf to observe traffic landing on the remaining member without renumbering VNIs. Validate DF election or equivalent multihoming behaviors for BUM if the design requires them. Document the shared VTEP address in the utility runbook so NOC staff recognize it during incidents.