Verständnis von ARP Flooding und ARP Gleaning in der ACI

Einleitung

In diesem Dokument wird die Verwendung von Address Resolution Protocol (ARP)-Flooding und ARP-Flutung in der Application Centric Infrastructure (ACI)-Fabric beschrieben.

ARP-Flooding im Überblick

In der Cisco ACI besteht die Option, ARP-Flooding zu verwenden oder bei Bedarf zu deaktivieren. Es ist zwingend erforderlich, das Fabric-Verhalten in Bezug auf das ARP-Flooding zu kennen, damit Sie die Layer-2-Probleme beheben können.

Wenn ARP-Flooding aktiviert ist, wird der ARP-Datenverkehr innerhalb der Fabric gemäß der regulären ARP-Verarbeitung in traditionellen Netzwerken geflutet. ARP-Flooding ist erforderlich, wenn kostenlose ARP-Anfragen (GARP) zum Aktualisieren von Host-ARP-Caches oder Router-ARP-Caches erforderlich sind. Dies ist der Fall, wenn eine IP-Adresse über eine andere MAC-Adresse verfügen kann (z. B. mit Clustering für Failover von Load Balancern und Firewalls).

Wenn ARP Flooding deaktiviert ist, versucht die Fabric, Unicast zum Senden des ARP-Datenverkehrs an das Ziel zu verwenden. Daher wird eine Layer-3-Suche nach der Ziel-IP-Adresse des ARP-Pakets durchgeführt. Das ARP verhält sich wie ein Layer-3-Unicast-Paket, bis es den Ziel-Leaf-Switch erreicht.

Als Nächstes sehen Sie einige Anwendungsfälle im Zusammenhang mit ARP-Flooding.

Anwendungsfall 1: Erfahrungen mit Endgeräten in der ACI

Dieser Anwendungsfall tritt ein, wenn beide Endpunkte dem Leaf-Switch bekannt sind.

In diesem Szenario spielt ARP Flooding keine Rolle. Der Datenverkehr wird lokal geswitcht, wenn der Leaf-Switch die Endpunktinformationen kennt. Dieses Verhalten ist identisch, wenn ein Endpunkt, z. B. H1, eine ARP-Anforderung an den anderen Endpunkt (H2) sendet und ARP-Flooding deaktiviert ist. Da der Leaf-Switch weiß, wo H2 angeschlossen ist, und die ARP-Ziel-IP-Adresse (eine H2-IP-Adresse) überprüft, muss der Datenverkehr nicht geflutet oder an den Spine-Layer umgeleitet werden. Daher wird die ARP-Anforderung an H2 gesendet. 

Unabhängig von den Einstellungen für Endpunktgruppe (EPG), Bridge-Domäne oder Zugriff/Kapselung werden Endpunkte, die dem Leaf bekannt sind, auf die gleiche Weise behandelt. 

Beispiel 1. Der Fabric bekannte Endpunkte, die in derselben EPG, Bridge-Domäne und in derselben Zugriffs-/Kapselungsmethode arbeiten.

Beispiel 2. Dem Fabric bekannte Endpunkte, die in derselben EPG, Bridge-Domäne, aber unterschiedlichen Zugriffs-/Kapselungsmethoden arbeiten.

Beispiel 3. Der Fabric bekannte Endpunkte, die in verschiedenen EPGs, aber in derselben Bridge-Domäne arbeiten.

Wenn ARP Flooding deaktiviert ist und die Endpunkte Teil der verschiedenen EPGs in derselben Bridge-Domäne sind, während sie mit demselben Leaf-Switch verbunden sind, wird der ARP-Datenverkehr lokal geroutet, wenn der Leaf-Switch die ARP-Ziel-IP-Adresse kennt (Unicast-Routing ist aktiviert).

Anwendungsfall 2: Erkenntnisse zu Endgeräten im COOP

Dieser Anwendungsfall gilt, wenn beide Endpunkte mit verschiedenen Leaf-Switches verbunden sind, die sich in der COOP-Datenbank (Cooperative Protocol) des Spine Switch befinden.

ARP-Anfragen müssen über das Fabric weitergeleitet werden. Der Fluss des ARP-Datenverkehrs von H1 zu H3 ist wie folgt:

• H1 sendet eine ARP-Anforderung für H3 mithilfe einer Broadcast-Ziel-MAC-Adresse.

• Die ACI versucht, Unicast-Weiterleitung zum Senden der ARP-Anforderung zu verwenden. Der lokale Leaf-Switch überprüft daher die ARP-Ziel-IP-Adresse, d. h. die H3-IP-Adresse. Da der lokale Leaf-Switch die IP-Adresse des Endpunkts H3 nicht kennt, sendet er die ARP-Anforderung für den Spine-Proxy an den Spine-Switch.

• Der Spine verfügt über die H3-Informationen in der COOP-Datenbank (Unicast-Routing ist aktiviert) und leitet die ARP-Anforderung an den Ziel-Leaf-Switch im Fabric weiter, der sie an H3 weiterleitet. Sobald H3 den Datenverkehr empfängt, antwortet es auf H1.

Beispiel 1. Der Fabric bekannte Endpunkte, die in derselben EPG, Bridge-Domäne und in derselben Zugriffs-/Kapselungsmethode arbeiten.

Beispiel 2. Dem Fabric bekannte Endpunkte, die in derselben EPG, Bridge-Domäne, aber unterschiedlichen Zugriffs-/Kapselungsmethoden arbeiten.

Beispiel 3. Der Fabric bekannte Endpunkte, die in verschiedenen EPGs, aber in derselben Bridge-Domäne arbeiten.

Anwendungsfall 3: Ziel-IP unbekannt, ARP Flood deaktiviert

Dieser Anwendungsfall wird angewendet, wenn der Eingangs-Leaf den Standort der Ziel-IP-Adresse nicht kennt (ARP-Flooding deaktiviert, Unicast-Routing aktiviert).

In einem ähnlichen Szenario wird, wenn ARP Flooding deaktiviert ist und der Eingangs-Leaf nicht weiß, wo sich die ARP-Ziel-IP-Adresse befindet, eine ARP-Anforderung an den Anycast Spine-Proxy Tunnel End-Point (TEP) anstatt an Flooding gesendet. Der Fluss des ARP-Datenverkehrs von H1 zu H2 ist wie folgt:

• H1 sendet eine ARP-Anforderung für H2 mithilfe einer Broadcast-Ziel-MAC-Adresse.

• Die ACI versucht, die ARP-Anforderung mithilfe der Unicast-Weiterleitung zu senden. Der lokale Leaf-Switch kennt die IP-Adresse des Endpunkts H2 nicht (die ARP-Ziel-IP-Adresse ist dem Eingangs-Leaf unbekannt) und sendet daher die ARP-Anforderung an den Spine-Switch für den Spine-Proxy.

• Da in der COOP-Datenbank auf dem Spine-Switch H2-Endpunktinformationen fehlen, verwirft der Spine das ursprüngliche Paket, löst jedoch stattdessen die ARP-Erkennung zur Erkennung der Ziel-IP aus, sodass nachfolgende ARP-Anforderungen nicht verworfen werden.

Beispiel 1. Unabhängig von den Einstellungen für EPG, Bridge-Domäne oder Zugriff/Kapselung bleibt der Fluss der ARP-Anforderungen derselbe wie zuvor erwähnt.

Anwendungsfall 4: Ziel-IP unbekannt, ARP Flood aktiviert

Dieser Anwendungsfall tritt ein, wenn der Eingangs-Leaf den Standort der Ziel-IP-Adresse nicht kennt (ARP-Flooding aktiviert, Unicast-Routing aktiviert).

Wenn das ARP-Flooding in der Bridge-Domäne aktiviert ist, erreicht die ARP-Anforderung von H1 durch Flooding H2. Der Fluss des ARP-Datenverkehrs von H1 zu H2 beträgt:

• H1 sendet eine ARP-Anforderung für H2 mithilfe einer Broadcast-Ziel-MAC-Adresse.

• Die ARP-Anforderung wird an alle Schnittstellen in der Bridge-Domäne geflutet. H2 empfängt den Frame und antwortet, während er in der Fabric erfasst wird.

Beispiel 1.

Einer der Vorteile von ARP-Flooding besteht darin, eine automatische IP-Adresse erkennen zu können, die von einem Standort zu einem anderen wechselt, ohne ein ACI-Leaf zu benachrichtigen. Da die ARP-Anforderung innerhalb der Bridge-Domäne geflutet wird, reagiert der Host mit der stillen IP angemessen, sodass der Eintrag vom ACI-Leaf entsprechend aktualisiert werden kann, auch wenn das ACI-Leaf denkt, dass sich die IP am alten Standort befindet.

Wenn ARP-Flooding deaktiviert ist, leitet das ACI-Leaf die ARP-Anforderung nur an den alten Standort weiter, bis das Alter des IP-Endpunkts erreicht ist. Andererseits besteht der Vorteil der Deaktivierung von ARP-Flooding in der Möglichkeit, den Datenverkehrsfluss zu optimieren, indem die ARP-Anforderung direkt an den Standort der Ziel-IP-Adresse gesendet wird. Dabei wird davon ausgegangen, dass sich kein Endpunkt bewegt, ohne dass die Bewegung über GARP usw. gemeldet wird.

Anwendungsfall 5: Endpunkte in verschiedenen EPGs und BDs

Dieser Anwendungsfall wird angewendet, wenn Endpunkte in verschiedenen EPGs und Bridge-Domänen verbunden sind.

Wenn die Endpunkte Teil der verschiedenen EPGs und Bridge-Domänen sind, muss der Datenverkehr zwischen ihnen weitergeleitet werden. Die Überflutung passiert nicht die Bridge-Domänen, einschließlich der ARP-Überflutung. Wenn H1 also mit H2 kommunizieren muss, das an denselben Leaf-Switch angeschlossen ist, wird der Datenverkehr an die Standard-Gateway-MAC-Adresse gesendet, sodass ARP-Flooding in diesem Beispiel nicht relevant ist.

ARP-Erkennung

Die Cisco ACI verfügt über verschiedene Mechanismen zur Erkennung von unbeaufsichtigten Hosts, bei denen ein ACI-Leaf nicht auf ein lokales Endgerät zugreift. Die ACI verfügt über einige Mechanismen, um diese stillen Hosts zu erkennen. Für Layer-2-Switched-Datenverkehr zu einer unbekannten MAC können Sie die Option Layer 2 Unknown Unicast unter der Bridge-Domäne (BD) auf Flood festlegen, während Sie für ARP-Anforderungen mit einer Broadcast-Ziel-MAC-Adresse die Option ARP Flooding unter der Bridge-Domäne verwenden können, um das Flooding-Verhalten zu steuern. Darüber hinaus verwendet die Cisco ACI die ARP-Bereinigung, um ARP-Anfragen zur Auflösung der IP-Adresse eines noch zu erlernenden Endpunkts zu senden (automatische Host-Erkennung).

Wenn beim ARP-Cleaning der Spine keine Informationen darüber hat, wo das Ziel der ARP-Anforderung verbunden ist (die Ziel-IP-Adresse befindet sich nicht in der COOP-Datenbank), generiert die Fabric eine ARP-Anforderung, die von der Switch Virtual Interface (SVI) (Pervasive Gateway)-IP-Adresse der Bridge-Domäne stammt. Diese ARP-Anforderung wird an alle Edge-Schnittstellen der Leaf-Knoten in der Bridge-Domäne gesendet. Außerdem wird die ARP-Bereinigung für (Layer 3)-gerouteten Verkehr unabhängig von der Konfiguration ausgelöst, z. B. für ARP-Flooding, solange der Verkehr an eine unbekannte IP-Adresse geroutet wird.

ARP-Reinigung hat einige Anforderungen:

• Die IP-Adresse wird für die Weiterleitung verwendet (ARP-Anfragen mit deaktiviertem ARP-Flooding oder Datenverkehr zwischen Subnetzen mit ACI BD SVI als Gateway).

• Unicast-Routing aktiviert

• Unter der Bridge-Domäne erstelltes Subnetz

Anwendungsfall 1: Ziel-IP unbekannt, ARP Flood deaktiviert

Dieser Anwendungsfall gilt, wenn der Ziel-/Zielendpunkt für die Fabric nicht bekannt ist (ARP-Flooding deaktiviert).

Wenn sich die Endpunkte auf verschiedenen Leaf-Switches befinden, die zur gleichen EPG- und Bridge-Domäne gehören und die gleiche VLAN-Zugriffszuordnung verwenden, muss die ARP-Anforderung (z. B. von H1 zu H3) über die Fabric weitergeleitet werden. Wenn in der COOP-Datenbank auf dem Spine-Switch (Silent Host) H3-Informationen fehlen und ARP-Flooding deaktiviert ist, kann auch die ARP-Reinigung verwendet werden, wie in dieser Abbildung dargestellt.

Der Fluss des ARP-Datenverkehrs von H1 zu H3 ist wie folgt:

• H1 sendet eine ARP-Anforderung für H3 mithilfe einer Broadcast-Ziel-MAC-Adresse.

• Die ACI versucht, die ARP-Anforderung mithilfe der Unicast-Weiterleitung zu senden, sodass der lokale Leaf-Switch die ARP-Ziel-IP-Adresse (H3-IP) überprüft. Da der lokale Leaf-Switch die IP-Adresse des Endpunkts H3 nicht kennt, sendet er die ARP-Anforderung für den Spine-Proxy an den Spine-Switch.

• Die H3-Informationen fehlen in der COOP-Datenbank auf dem Spine-Switch und lösen die ARP-Bereinigung aus, indem die allgegenwärtige Gateway-IP-Adresse als Quelle verwendet wird. Diese ARP-Anforderung wird in der Domäne geflutet.

• H3 empfängt die ARP-Anforderung und antwortet, während sie in der Fabric erfasst wird.

Unabhängig von den Einstellungen für EPG, Bridge-Domäne oder Zugriff/Kapselung funktioniert die ARP-Glean-Funktion auf die gleiche Weise, wenn zwei Endpunkte versuchen, miteinander zu kommunizieren (unabhängig von ihrer Verbindung mit demselben oder unterschiedlichen Leaf-Switches innerhalb der Fabric).

Anwendungsfall 2: Endpunkte in verschiedenen EPGs und BDs

Dieser Anwendungsfall gilt, wenn Endpunkte in verschiedenen EPGs und Bridge-Domänen verbunden sind (ARP-Flooding aktiviert).

Wenn die Endpunkte Teil der verschiedenen EPGs und Bridge-Domänen sind, muss der Datenverkehr zwischen ihnen weitergeleitet werden. Das Flooding passiert keine Bridge-Domänen, einschließlich ARP-Flooding, das durch ARP-Entriegelung generiert werden kann. Wenn H1 also mit H2 kommunizieren muss, das an denselben Leaf-Switch angeschlossen ist, wird der Datenverkehr an die Standard-Gateway-MAC-Adresse gesendet, sodass die ARP-Bereinigung in diesem Beispiel nicht relevant ist.