Hello,
I am studying for DCACI, and in the course I am studying (DCACI Cisco U.), the ARP traffic handling left some holes of potential scenarios, a fact that is killing me...
1) What if the Bridge Domain has Unicast Routing enabled and ARP Flooding enabled, BUT the ingress leaf that receives the ARP Request has an entry in the endpoint table with the MAC/IP of the Target EP? Will it still flood the ARP Request? Will it respond directly to the sending endpoint with an ARP Reply with the MAC Address of the Target EP, effectively "impersonating the Target EP"? Will it forward the ARP Request to the Target EP in Unicast through the fabric?
2) Related to the first question: when the ingress leaf of the ARP Request receives the ARP Request, and knows the MAC/IP of the target EP, does it forward the ARP Request or impersonates the Target EP and replies with the MAC/IP of the Target EP?
Image of the course:
Image of what I understood:
EDIT: Corrected the first image background.
Accepted Solutions
Hi @BertiniB ,
Sorry, but the first picture is correct.
If an ARP broadcast arrives at a leaf, and ARP flooding is enabled, the Leaf does NOT check its EP table - ARP is always flooded. I admit I was confused about this when I first started with ACI (I may have even lied to some people accidentally)
But the 2nd bit is more important that you understand
ACI NEVER sends ARP replies unless the ARP request is for it's own IP address (let's skip Proxy ARP at this stage - but even if proxy ARP was enabled, it's a particular use-case:- to enable Proxy ARP, intra-EPG endpoint isolation must be enabled on the EPG)
So what ACI DOES do to reduce the amount of ARP traffic is identify the VTEP (leaf or VPC VTEP) where the endpoint exists, and sends it just to that VTEP. When the target Leaf gets the ARP request it floods the frame within the BD for that VTEP/Leaf.
Here's my version of the same diagram, which I think is more complete
Hi @BertiniB ,
Sorry, but the first picture is correct.
If an ARP broadcast arrives at a leaf, and ARP flooding is enabled, the Leaf does NOT check its EP table - ARP is always flooded. I admit I was confused about this when I first started with ACI (I may have even lied to some people accidentally)
But the 2nd bit is more important that you understand
ACI NEVER sends ARP replies unless the ARP request is for it's own IP address (let's skip Proxy ARP at this stage - but even if proxy ARP was enabled, it's a particular use-case:- to enable Proxy ARP, intra-EPG endpoint isolation must be enabled on the EPG)
So what ACI DOES do to reduce the amount of ARP traffic is identify the VTEP (leaf or VPC VTEP) where the endpoint exists, and sends it just to that VTEP. When the target Leaf gets the ARP request it floods the frame within the BD for that VTEP/Leaf.
Here's my version of the same diagram, which I think is more complete
Thanks for the reply @RedNectar!
Just one more question, is this image about L3 Forwarding Behavior also correct?
If so, what exactly does the triangle "Does Leaf Have BD Subnets for Dst IP (Route to Anycast Spine)?
Is it that whether the subnet is defined in the BD of the EPG that the packet came from? If it has an SVI to route the packet?
Got stuck in this part.
Hi @BertiniB ,
I think that the wording on that diagram is very poor. Guess what? I have my own version of this diagram too!!!
Essentially, if the Destination IP is not in the EP table, the leaf routes the packet - just like any other router. I think talking about "BD Subnets for Dst IP" actually complicates the issue.
What happens in ACI is that when the first static (or VMM dynamic) connection is created on a leaf switch, the APIC pushes a rout to the leaf something like this:
apic1# fabric 2201 show ip route vrf Tenant18:Prod_VRF
----------------------------------------------------------------
Node 2201 (Leaf2201)
----------------------------------------------------------------
<snip>
10.218.11.0/24, ubest/mbest: 1/0, attached, direct, pervasive
*via 10.2.128.65%overlay-1, [1/0], 20:48:27, static
10.218.11.1/32, ubest/mbest: 1/0, attached, pervasive
*via 10.218.11.1, vlan33, [0/0], 20:48:27, local, local
10.218.12.0/24, ubest/mbest: 1/0, attached, direct, pervasive
*via 10.2.128.65%overlay-1, [1/0], 20:48:27, static
In the example above, a BD was assigned the gateway address of 10.218.11.1/24. Although not visible on THIS leaf, there is also another BD that's been assigned the gateway address of 10.218.12.1/24
The moment a static mapping for an EPG linked to the10.218.11.1/24 BD on this leaf (2201) ACI immediately
- created a VLAN (vlan33) on the leaf to hold the pervasive gateway IP
- assigned the the pervasive gateway IP 10.218.11.1/24 to that leaf (explaining the 10.218.11.1/32 route in the table via its own IP)
- pushed the10.218.11.0/24 route via 10.2.128.65 (which of course is the IP4 Proxy VTEP).
- What this route does in fact is tell the leaf that if it sees a packet addressed to anything in the 10.218.11.0/24 subnet that it doesn't have in its endpoint table, send it to the Proxy. Or as worded in the diagram "Does Leaf Have BD Subnets for Dst IP (Route to Anycast Spine)"
At sometime, the EPG using the 10.218.11.1/24 pervasive gateway IP was assigned a contract with an EPG using the the 10.218.12.1/24 gateway IP - it may have been before the above or after - the point is that since this contract exists, this leaf also needs to be able to handle traffic addressed to the 10.218.12.0/24 subnet that is not in its endpoint table. And as you can probably interpret now, the the 10.218.12.0/24 route says send it to the IPv4 Proxy.
I hope this helps.
Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.
Oh- for the record. I have my own L2 forwarding diagram too, which I usually show first as it explains the GIPo
