Einleitung

In diesem Dokument werden einige der häufigsten Probleme mit dem standortübergreifenden Cluster für den transparenten EtherChannel beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• ASA-Firewall (Adaptive Security Appliance)
• ASA-Clustering

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Ab ASA Version 9.2 wird standortübergreifendes Clustering unterstützt, wobei sich die ASA-Einheiten in verschiedenen Rechenzentren befinden können und die Cluster Control Link (CCL) über einen Data Center Interconnect (DCI) verbunden ist. Folgende Bereitstellungsszenarien sind möglich:

•  Individuelle Schnittstelle zwischen Standorten
•  Standortübergreifendes EtherChannel-Cluster im transparenten Modus
•  Standortübergreifendes Cluster mit EtherChannel-Routing (Spanned EtherChannel) (wird ab 9.5 unterstützt)

MAC MOVE-Benachrichtigungen

Wenn eine MAC-Adresse in der Content Addressable Memory (CAM)-Tabelle den Port ändert, wird eine MAC MOVE-Benachrichtigung generiert. Es wird jedoch keine MAC MOVE-Benachrichtigung generiert, wenn die MAC-Adresse der CAM-Tabelle hinzugefügt oder daraus entfernt wird. Angenommen, wenn eine MAC-Adresse X über die Schnittstelle GigabitEthernet0/1 in VLAN10 abgerufen wird und nach einiger Zeit dieselbe MAC über GigabitEthernet0/2 in VLAN 10 erkannt wird, wird eine MAC MOVE-Benachrichtigung generiert.

Syslog vom Switch:

NEXUS7K %L2FM-4-L2FM_MAC_MOVE: Mac 000c.8142.2600 in vlan 10 has moved from GigabitEthernet0/1 to GigabitEthernet0/2

Syslog von ASA:

ASA-4-412001: MAC 003a.7b58.24c5 moved from DMZ to INSIDE

Netzwerkdiagramm

Standortübergreifende Cluster-Bereitstellung, wobei die ASAs im transparenten Modus konfiguriert sind, der VLAN 1535 und VLAN 35 überbrückt. Das interne VLAN 35 wird über die Overlay Transport Virtualization (OTV) erweitert, während das externe VLAN 1535 nicht über das OTV erweitert wird, wie im Bild gezeigt

MAC-Verschiebungsbenachrichtigungen auf dem Switch

Szenario 1

Datenverkehr, der an eine MAC-Adresse gerichtet ist, deren Eintrag nicht in der MAC-Tabelle der ASA vorhanden ist, wie im Bild gezeigt:

Befindet sich die Ziel-MAC-Adresse des auf der ASA eintreffenden Pakets in einer transparenten ASA nicht in der MAC-Adresstabelle, sendet sie eine ARP-Anforderung (Address Resolution Protocol) für dieses Ziel (wenn im gleichen Subnetz wie BVI) oder eine ICMP-Anforderung (Internet Control Message Protocol) mit Time To Live 1 (TTL 1) mit der Quell-MAC als virtuelle Bridge-Schnittstelle (BVI) MAC-Adresse und Ziel-MAC-Adresse, da Destination Media Access Controller (DMAC) nicht erkannt wurde.

Im vorherigen Fall ergibt sich folgender Datenverkehrsfluss:

1. Der ISP-Router im Rechenzentrum 1 leitet den Datenverkehr an ein spezifisches Ziel hinter der ASA weiter.
2. Beide ASAs können den Datenverkehr empfangen, und in diesem Fall ist die Ziel-MAC-Adresse des Datenverkehrs der ASA nicht bekannt.
3. Die Ziel-IP-Adresse des Datenverkehrs befindet sich im selben Subnetz wie die BVI. Wie bereits erwähnt, generiert die ASA jetzt eine ARP-Anforderung für die Ziel-IP-Adresse.
4. Der Switch 1 empfängt den Datenverkehr und leitet ihn bei einer Broadcast-Anforderung an Rechenzentrum 2 sowie über die OTV-Verbindung weiter.
5. Wenn Switch 2 die ARP-Anforderung von der ASA auf der OTV-Verbindung erkennt, protokolliert er eine MAC MOVE-Benachrichtigung, da die MAC-Adresse der ASA zuvor über eine direkt verbundene Schnittstelle abgerufen wurde und nun über die OTV-Verbindung abgerufen wird.

Empfehlungen

Es handelt sich um ein Eckenszenario. MAC-Tabellen werden in Clustern synchronisiert, sodass es für ein Mitglied weniger wahrscheinlich ist, dass es keinen Eintrag für einen bestimmten Host hat. Gelegentliche MAC-Verschiebungen für clustereigene BVI-MAC-Adressen werden als zulässig erachtet.

Szenario 2

Zentralisierte Datenflussverarbeitung durch ASA, wie im Bild gezeigt:

Der prüfungsbasierte Datenverkehr in einem ASA-Cluster wird in drei Typen unterteilt:

• Zentralisiert
• Verteilt
• Semi-verteilt

Bei der zentralen Überprüfung wird der gesamte Datenverkehr, der überprüft werden muss, an die primäre Einheit des ASA-Clusters umgeleitet. Wenn eine sekundäre Einheit des ASA-Clusters den Datenverkehr empfängt, wird dieser über die CCL an die primäre Einheit weitergeleitet.

Im vorherigen Image arbeiten Sie mit SQL-Datenverkehr, der ein CIP (Centralized Inspection Protocol) ist. Das hier beschriebene Verhalten gilt für alle CIPs.

Sie empfangen den Datenverkehr in Rechenzentrum 2, wo Sie nur über sekundäre Einheiten des ASA-Clusters verfügen. Die primäre Einheit befindet sich im Rechenzentrum 1, also in der ASA 1.

1. Der ISP-Router 2 im Rechenzentrum 2 empfängt den Datenverkehr und leitet ihn Downstream an die ASAs am Standort weiter.
2. Jede der ASAs kann diesen Datenverkehr empfangen. Wenn sie festgestellt hat, dass dieser Datenverkehr überprüft werden muss, und wenn das Protokoll zentralisiert ist, leitet sie den Datenverkehr über das CCL an die primäre Einheit weiter.
3. ASA 1 empfängt den Datenverkehrsfluss über CCL, verarbeitet den Datenverkehr und sendet ihn Downstream an den SQL Server.
4. Wenn die ASA 1 den Datenverkehr jetzt an einen Downstream weiterleitet, behält sie die ursprüngliche Quell-MAC-Adresse des ISP-Routers 2, der sich im Rechenzentrum 2 befindet, bei und sendet sie an einen Downstream.
5. Wenn Switch 1 diesen speziellen Datenverkehr empfängt, meldet er sich als MAC MOVE-Benachrichtigung an, da er ursprünglich die MAC-Adresse des ISP Routers 2 über die OTV-Verbindung erkennt, die mit Rechenzentrum 2 verbunden ist, und jetzt den Datenverkehr sieht, der von den mit der ASA 1 verbundenen Schnittstellen eingeht.

Empfehlungen

Es wird empfohlen, zentralisierte Verbindungen an den Standort weiterzuleiten, der den primären Host (basierend auf Prioritäten) darstellt, wie im Bild gezeigt:

Szenario 3

Bei einer Kommunikation zwischen Domänencontrollern (DC) im transparenten Modus wird dieser spezifische Datenverkehrsfluss nicht behandelt oder dokumentiert, aber dieser spezifische Datenverkehrsfluss funktioniert vom Standpunkt der ASA-Datenflussverarbeitung aus. Dies kann jedoch zu MAC-Verschiebungsbenachrichtigungen auf dem Switch führen. 

1. Host 1 im VLAN 35 versucht, mit Host 2 zu kommunizieren, der sich im anderen Rechenzentrum befindet.
2. Host 1 verfügt über ein Standard-Gateway, nämlich Router 1, und Router 1 hat einen Pfad, um Host 2 zu erreichen, indem er direkt mit Router 2 über eine alternative Verbindung kommunizieren kann. In diesem Fall gehen wir von Multiprotocol Label Switching (MPLS) und nicht über das ASA-Cluster aus.
3. Router 2 empfängt den eingehenden Datenverkehr und leitet ihn an Host 2 weiter.
4. Wenn Host 2 nun antwortet, empfängt Router 2 den zurückkehrenden Datenverkehr und findet eine direkt verbundene Route durch die ASAs anstelle des Datenverkehrs, den er über das MPLS sendet. 
5. Zu diesem Zeitpunkt verfügt der Datenverkehr, der Router 2 verlässt, über die Quell-MAC der Ausgangsschnittstelle von Router 2.
6. Die ASAs im Rechenzentrum 2 empfangen den zurückkehrenden Datenverkehr und suchen eine bestehende Verbindung, die von den ASAs im Rechenzentrum 1 hergestellt wird.
7. Die ASAs im Rechenzentrum 2 senden den zurückfließenden Datenverkehr über CCL zurück an die ASAs im Rechenzentrum 1.
8. Zu diesem Zeitpunkt verarbeitet die ASAs im Rechenzentrum 1 den zurückfließenden Datenverkehr und sendet ihn an Switch 1. Das Paket verfügt weiterhin über die gleiche Quell-MAC wie die Ausgangsschnittstelle von Router 2.
9. Wenn Switch 1 jetzt das Paket empfängt, protokolliert er eine MAC-Verschiebungsbenachrichtigung, da er zunächst die MAC-Adresse von Router 2 über die Schnittstelle erfasst hat, die mit der OTV-Verbindung verbunden ist. Zu diesem Zeitpunkt beginnt er jedoch, die MAC-Adresse von der Schnittstelle zu lernen, die mit den ASAs verbunden ist.
   
   

Szenario 4

Von der ASA generierter Datenverkehr, wie im Bild gezeigt:

Dieser spezielle Fall gilt für jeglichen Datenverkehr, der von der ASA selbst generiert wird. Dabei werden zwei mögliche Situationen berücksichtigt, in denen die ASA entweder versucht, ein Network Time Protocol (NTP) oder einen Syslog-Server zu erreichen, die sich im gleichen Subnetz wie die BVI-Schnittstelle befinden. Diese Situation ist jedoch nicht nur auf diese beiden Bedingungen beschränkt, sondern kann auch immer dann auftreten, wenn von der ASA Datenverkehr für eine beliebige IP-Adresse generiert wird, die direkt mit den BVI-IP-Adressen verbunden ist.

1. Wenn ASA nicht über die ARP-Informationen des NTP-/Syslog-Servers verfügt, generiert die ASA eine ARP-Anforderung für diesen Server.
2. Da es sich bei der ARP-Anforderung um ein Broadcast-Paket handelt, empfängt Switch 1 dieses Paket von seiner verbundenen Schnittstelle der ASA und flutet es über alle Schnittstellen im spezifischen VLAN, einschließlich des Remote-Standorts über das OTV.
3. Der Remote-Standort-Switch 2 empfängt diese ARP-Anforderung von der OTV-Verbindung und generiert aufgrund der Quell-MAC-Adresse der ASA eine MAC-Flapping-Benachrichtigung, da dieselbe MAC-Adresse über die direkt mit der ASA verbundenen lokalen Schnittstellen im OTV erfasst wird.

Szenario 5

 Datenverkehr, der von einem direkt verbundenen Host an die BVI-IP-Adresse der ASA gerichtet ist, wie im Bild gezeigt:

Eine MAC MOVE kann auch dann beobachtet werden, wenn der Datenverkehr an die BVI-IP-Adresse der ASA geleitet wird. 

Im Szenario befindet sich ein Host-Rechner in einem direkt verbundenen Netzwerk der ASA und versucht, eine Verbindung zur ASA herzustellen.

1. Der Host verfügt nicht über den ARP der ASA und löst eine ARP-Anforderung aus.
2. Der Nexus empfängt den Datenverkehr, und da es sich um einen Broadcast-Datenverkehr handelt, sendet er den Datenverkehr über das OTV auch an den anderen Standort. 
3. Die ASA im Remote-Rechenzentrum 2 kann auf die ARP-Anforderung reagieren und sendet den Datenverkehr über denselben Pfad zurück, der Switch 2 auf der Remote-Seite, OTV, Switch 1 auf der lokalen Seite und dann der End-Host ist.
4. Wenn die ARP-Antwort auf der lokalen Seite von Switch 1 angezeigt wird, löst sie eine MAC-Verschiebungsbenachrichtigung aus, da sie die MAC-Adresse der ASA erkennt, die von der OTV-Verbindung eingeht.

Szenario 6

ASA hat den Datenverkehr, mit dem eine RST an den Host gesendet wird, abgelehnt, wie im Bild gezeigt:

In diesem Fall haben wir einen Host 1 im VLAN 35. Er versucht, mit Host 2 im selben Layer-3-VLAN zu kommunizieren. Host 2 befindet sich jedoch tatsächlich im Rechenzentrum-2-VLAN 1535.

1. Die MAC-Adresse des Hosts wird auf Switch 2 über die Schnittstelle angezeigt, die mit den ASAs verbunden ist.
2. Switch 1 sieht die MAC-Adresse von Host 2 über die OTV-Verbindung.
3. Host 1 sendet Datenverkehr an Host 2. Dieser Pfad entspricht Switch 1, OTV, Switch 2, ASAs im Rechenzentrum 2.
4. Dies wird von der ASA ausdrücklich abgelehnt, und da ASA so konfiguriert ist, dass es eine RST an Host 1 zurücksendet, wird das RST-Paket mit der Quell-MAC-Adresse der ASA zurückgesendet.
5. Wenn dieses Paket über das OTV zurück zu Switch 1 gelangt, protokolliert Switch 1 eine MAC MOVE-Benachrichtigung für die MAC-Adresse der ASA, da er nun die MAC-Adresse über das OTV erkennt, wobei er die Adresse nicht von seiner direkt verbundenen Schnittstelle sieht.

Überprüfung

Für diese Konfiguration ist derzeit kein Überprüfungsverfahren verfügbar.

Fehlerbehebung

Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.

Zugehörige Informationen

• Konfigurationsleitfaden für die CLI der Cisco ASA Serie
• Technischer Support und Dokumentation für Cisco Systeme