cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9721
Views
17
Helpful
6
Replies

GLEAN in ACI

Greetings,

My understanding of GLEAN in ACI is that it is for only ARP.. So when a ARP request is for Silent host and when Flooding is not enabled, Spine is queried and when Spine does not know the endpoint, initiates a GLEAN. (please correct me if i am wrong)

I understand that the above does not happen for unknown unicast (so the source endpoint has a static arp but since the destination is silent host  the ACI does not know the endpoint).. what is the reasoning behind this? (i understand that for unknown unicast flooding should be enabled to overcome this).. is it not that GLEAN for unknown unicast also will be better? 

Sorry if it is a basic question.....

 

1 Accepted Solution

Accepted Solutions

Hi @Jayashanker warrier 

To answer your question, I believe the glean for l2 traffic is not really something desired because it will generate quite a lot of heat at CPU level. Think about the traditional networks - if the dMAC is not known, the traffic is flooded. The HW Proxy (Coop verification) is just a mechanism to avoid unnecessary flood since COOP SHOULD know about all EPs.

The reason why it does not work for you with Hw Proxy enabled is because of the static ARP. Generally speaking, when a communication is initiated between two EPs, the first packet would be an ARP request for the silent host, which will trigger the ARP reply from it, making it visible to spines. Since you have the static ARP, the ARP request is never generated. If the ACI Fabric doesn't know about the PC2, it all depends on the BD settings. Flood -> send to destination, HW Proxy -> drop.

 

Hope it helps,

Sergiu

 

View solution in original post

6 Replies 6

Sergiu.Daniluk
VIP Alumni
VIP Alumni

Hi @Jayashanker warrier 

I think there is a bit of confusion about ARP Glean process. Allow me to try and clarify how it works:

ARP Gleaning, known also as Silent Host Detection mechanism, represents the process in which the ACI Spines generates an ARP request for a destination IP which does not exists in the COOP database. How does the traffic reaches the Spines in the first place? Well, that is called Spine Proxy, and refers to the situation when the Leaf does not know either the dMAC or the dIP in it's endpoint table (unknown unicast), and needs to send it to Spine to take a forwarding decision. The decision to forward it to spines for L2 traffic is based on BD configuration. While for L3 traffic is based on the pervasive route always configured on the Leaf switch.

And since there are different situations depending on the type of traffic (L2 or L3), this is from ACI whitepaper:

  • For (L2) switched traffic to an unknown MAC, the L2 Unknown Unicast option under the BD may need to be set to “Flood”. This is because the ACI fabric with the L2 Unknown Unicast “Hardware-Proxy” configuration drops the L2 unicast packets on the spine in cases where the destination MAC has not been learned as an endpoint anywhere on the BD in ACI, and the COOP database doesn’t have the information.
  • For (L3) routed traffic to an unknown IP, the ACI leaf will generate an ARP request from its BD SVI (pervasive gateway) IP toward the unknown IP in order to detect and learn the unknown IP. Only the leaf with BD SVI IP for the unknown IP subnet will generate an ARP request. This behavior is originally triggered by the spine when the spine couldn’t find the unknown IP, even in the COOP database. This behavior is called silent host detection, or ARP gleaning. This behavior for (L3) routed traffic happens regardless of configuration, such as L2 Unknown Unicast or ARP flooding (mentioned below), as long as the traffic is routed to an unknown IP.
  • For ARP requests with a broadcast destination MAC, the ARP flooding option under the BD controls the flooding behavior. The ACI fabric will flood the ARP request within the BD when the ARP flooding option is enabled. Because the frame is flooded to the entire BD, any silent host would receive the packet and respond appropriately. In cases where the ARP flooding option is disabled, the ACI fabric will perform unicast routing against the target IP located in the ARP header instead of flooding. If the target IP is a silent host and unknown to the leaf and spines (COOP), the ACI leaf switches will follow the same procedure as the (L3) routed traffic scenario discussed earlier (ARP gleaning) and generate an ARP request from its BD SVI (pervasive gateway), even if the target IP and the source IP are in the same subnet. This implies that both enabling and disabling the ARP flooding option can detect most silent hosts.

Ref: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739989.html

 

But since most of the times a pictures is worth a thousand words, you might find the next diagram taken from best ciscolive presentation BRKACI-3545 - Mastering ACI Forwarding more informative:

aciforwarding.png

 

aciforwarding2.png

 

If there are things which are still not clear, let us know.

 

Stay safe,

Sergiu

Thanks for the beautiful explanation... my question is what is the reasoning that we do not do a glean kind of solution for un-known unicast (for the subnets within the fabric)?... i can understand that flood is required for un-known unicast to solve this issue...

For example say PC1 has a static arp entry for pc2.. but pc2 is a silent host.... now without flood enabled my communication is dropped.. if there is a process like glean then this situation would be avoided right?

Sorry if the above does not make sense....

 

thanks

Jayashanker

Hi @Jayashanker warrier 

To answer your question, I believe the glean for l2 traffic is not really something desired because it will generate quite a lot of heat at CPU level. Think about the traditional networks - if the dMAC is not known, the traffic is flooded. The HW Proxy (Coop verification) is just a mechanism to avoid unnecessary flood since COOP SHOULD know about all EPs.

The reason why it does not work for you with Hw Proxy enabled is because of the static ARP. Generally speaking, when a communication is initiated between two EPs, the first packet would be an ARP request for the silent host, which will trigger the ARP reply from it, making it visible to spines. Since you have the static ARP, the ARP request is never generated. If the ACI Fabric doesn't know about the PC2, it all depends on the BD settings. Flood -> send to destination, HW Proxy -> drop.

 

Hope it helps,

Sergiu

 

Hi @Jayashanker warrier ,

@sehas hit the nail on the head with "because of the static ARP".  

I actually asked a similar question a couple of years ago, and my research led me (forgive me for banging my own drum) to write this which may help you undersatnd the process.

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.

So, I have a basic question over here, what the source IP when the spine tries to forward the Glean ARP? Also what are the layer 2 headers? Such as source mac and target mac?

Hi @Suprit Chinchodikar ,

This thread has already been answered.  If you have a new question, start a new thread and refer to this one as part of the question.

In the meantime, I'll start preparing an answer.

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.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Save 25% on Day-2 Operations Add-On License