A retail bank's ACI bridge domain uses hardware proxy, so unknown unicast is sent toward the spine, but a host broadcast still reaches the other leaves in that bridge domain. Why does the broadcast still flood?
Select an answer to reveal the explanation.
Short Explanation
You can think of hardware proxy as looking up an unknown unicast by name, while a broadcast still has to travel down every hall in the bridge domain. That means you can see COOP direct unknown unicast toward the owning leaf and still have broadcasts flood to the other leaves. Flood mode, an open contract, and a full COOP database do not explain this combination.
Full Explanation
Hardware proxy changes how unknown unicast is handled: the leaf sends the frame toward the spine, and COOP uses its endpoint database to direct the frame to the leaf that owns the endpoint instead of flooding it to every leaf. Broadcast is separate. The bridge domain still floods broadcasts to the other leaves that carry it, which explains the bank’s symptom and does not indicate a proxy failure. A bridge domain in flood mode would also flood unknown unicast, so that setting does not fit a leaf already sending unknown unicast through the spine. Contracts filter traffic between EPGs; an open contract is not what replicates a bridge-domain broadcast to every leaf. COOP is a directory of endpoints learned from leaves, not a record of broadcasts, so a flooded broadcast does not show that the spine database is full. Caveat: ARP flooding can be enabled independently while unknown unicast uses hardware proxy, so check that setting before attributing an ARP symptom to COOP. Practical check: confirm the bridge domain uses hardware proxy, verify that COOP has the remote MAC endpoint, and check that the broadcast follows the bridge-domain flood list.