Hi @Herman2022 ,
In a VXLAN environment, the flood and learn approach is used to flood unknown destination unicast traffic to all destinations of a VXLAN segment
ACI uses VXLAN as an infrastructure underlay, where each switch is allocated a VTEP address (via DHCP from the APIC), which in turn is advertised via ISIS so all switches learn all other switches VTEP addresses.
These same VTEP addresses are also used to encapsulate user traffic that is sent switch-to-switch. But leaf switches learn local user endpoint to VTEP address bindings and report these to spine switches using where this information is kept in a centralised database kept on the spine switches known as the Council Of Oracles database.
The protocol used by leaf switches to report this is therefore called the Council Of Oracles Protocol, most often written as COOP, and therefore the database is often referred to as the COOP database
This allows switches to send destination-unknown traffic to a spine switch (using a Proxy VTEP destination address) which will look up the COOP database and re-address the traffic to the resolved leaf-switch VTEP rather than using flood and learn. And if unknown destination is NOT in the COOP database, then:
- If the traffic is L2 traffic, the traffic is dropped.
- If the traffic is L3 IP traffic, the spine sends a request to all leaf switches to ARP for the unknown IP address, in the hope that the destination IP responds, the leaf learns the IP to VTEP binding, sends this via COOP to the spine, and finally the spine can re-address the traffic to the resolved leaf-switch VTEP. This process is known as ARP Gleaning (and I've written much about this if you go looking)
- The tricky one is ARP broadcasts, which ACI treats as IP unicasts based on the IP address being queried.
So it is more proxy-and-learn approach than flood-and-learn.
BUT ACI can be configured to selectively modify this behaviour, in some cases ACI essentially reverts to flood-and-learn, although it is not referred to as that. There are just settings in the Bridge Domain
- for L2 - L2 Unknown Unicasts can be configured to either Flood or use Hardware Proxy
- Selecting Flood essentially causes L2 to revert to flood-and-learn for unknown MAC addresses
- for L3, unknown IP unicasts are treated as above - proxy-and-learn
- for ARP, ARP Flooding can be enabled, so ARPs are treated like L2 broadcasts, or disabled so ARPs are treated like IP packets
- The tricky bit about this is that
- originally, ARP was disabled by default
- about v4.x ARP was either disabled or enabled by default, depending on how the BD was created (right-click or drag-and-drop)
- from around 5.x ARP is enabled by default
- Cisco have NEVER given an explanation as to why the defaults for what is called Optimized Forwarding when creating the BD has changed.
So the answer is not a straightforward Yes or No. Essentially it is No, but can be modified to behave in the same way
RedNectar aka Chris Welsh.
Forum Tips: 1. Paste images inline - don't attach. 2. Always mark helpful and correct answers, it helps others find what they need.
