Inleiding

In dit document worden enkele veelvoorkomende problemen beschreven met de intersite-cluster van de transparante modus van Spanned EtherChannel.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Adaptive Security Appliance (ASA)-firewall
• ASA-clustering

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Vanaf ASA versie 9.2 wordt intersite clustering ondersteund waarbij de ASA-eenheden in verschillende datacenters kunnen worden gevestigd en de Cluster Control Link (CCL) is verbonden via een Data Center Interconnect (DCI). De mogelijke implementatiescenario's zijn:

•  Individuele interfacecluster tussen locaties
•  Overspannen EtherChannel Transparent Mode Inter-Site Cluster
•  Intersite-cluster in de gerouteerde modus van het EtherChannel-kanaal (ondersteund vanaf 9.5)

MAC MOVE-meldingen

Wanneer een MAC-adres in de CAM-tabel (Content Addressable Memory) van poort verandert, wordt een MAC MOVE-melding gegenereerd. Een MAC MOVE-melding wordt echter niet gegenereerd wanneer een MAC-adres wordt toegevoegd aan of verwijderd uit de CAM-tabel. Stel dat een MAC-adres X wordt geleerd via de interface GigabitEthernet0/1 in VLAN10 en na enige tijd dezelfde MAC wordt gezien via GigabitEthernet0/2 in VLAN 10, dan wordt een MAC MOVE-melding gegenereerd.

Syslog van Switch:

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

Syslog van ASA:

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

Netwerkdiagram

Inter-site clusterimplementatie waarbij de ASA's zijn geconfigureerd in transparante modus die VLAN 1535 en VLAN 35 overbrugt. De binnenkant van VLAN 35 wordt uitgestrekt over de OTV (Overlay Transport Virtualization), terwijl de buitenkant van VLAN 1535 niet over de OTV wordt uitgestrekt, zoals in de afbeelding wordt getoond

MAC Verplaatsen Meldingen op Switch

Scenario 1

Verkeer bestemd voor een MAC-adres waarvan de vermelding niet aanwezig is op de MAC-tabel van de ASA, zoals weergegeven in de afbeelding:

Als het MAC-adres van de bestemming van het pakket dat op de ASA aankomt niet in de tabel met het MAC-adres staat, verzendt het een verzoek voor het Address Resolution Protocol (ARP) voor die bestemming (indien in hetzelfde subnet als BVI) of een Internet Control Message Protocol (ICMP)-verzoek met Time To Live 1 (TTL 1) met bron-MAC als het Bridge Virtual Interface (BVI) MAC-adres en het MAC-adres van de bestemming als Destination Media Access Controller (DMAC) wordt gemist.

In het voorgaande geval heb je deze verkeersstroom:

1. De ISP Router op Datacenter 1 stuurt verkeer door naar een specifieke bestemming die achter de ASA ligt.
2. Beide ASA's kunnen het verkeer ontvangen en in dit geval is het MAC-adres van de bestemming van het verkeer niet bekend bij de ASA.
3. Nu bevindt de IP-bestemming van het verkeer zich in hetzelfde subnet als dat van de BVI en zoals eerder vermeld, genereert ASA nu een ARP-verzoek voor de IP-bestemming.
4. De Switch 1 ontvangt het verkeer en aangezien het verzoek een uitzending is, stuurt het het verkeer door naar Datacenter 2 en via de OTV-link.
5. Wanneer Switch 2 het ARP-verzoek van de ASA op de OTV-link ziet, registreert het een MAC MOVE-melding omdat eerder het MAC-adres van ASA via een direct verbonden interface werd aangeleerd en nu wordt het via de OTV-link aangeleerd.

Aanbevelingen

Het is een hoekscenario. MAC-tabellen worden gesynchroniseerd in clusters, dus het is minder waarschijnlijk dat een lid geen vermelding heeft voor een bepaalde host. Een occasionele MAC-verplaatsing voor BVI MAC in clusterhanden wordt aanvaardbaar geacht.

Scenario 2

Gecentraliseerde stromingsverwerking door ASA, zoals weergegeven in de afbeelding:

Op inspectie gebaseerd verkeer in een ASA-cluster wordt ingedeeld in drie typen:

• gecentraliseerd
• Distributed (Gedistribueerd)
• halfgedistribueerd

In het geval van gecentraliseerde inspectie wordt elk verkeer dat moet worden geïnspecteerd, omgeleid naar de primaire eenheid van het ASA-cluster. Als een secundaire eenheid van het ASA-cluster het verkeer ontvangt, wordt het via de CCL doorgestuurd naar de primaire eenheid.

In de eerdere afbeelding werkt u met SQL-verkeer dat een gecentraliseerd inspectieprotocol (CIP) is en het hier beschreven gedrag is van toepassing op elke CIP.

U ontvangt het verkeer op Datacenter 2, waar u alleen secundaire eenheden van het ASA-cluster hebt, de primaire eenheid bevindt zich in Datacenter 1, dat ASA 1 is.

1. ISP Router 2 op Datacenter 2 ontvangt het verkeer en stuurt het stroomafwaarts naar de ASA's op zijn site.
2. Beide ASA's kunnen dit verkeer ontvangen en zodra het bepaalt dat dit verkeer moet worden geïnspecteerd en als het protocol is gecentraliseerd, stuurt het het verkeer door naar de primaire eenheid via de CCL.
3. ASA 1 ontvangt de verkeersstroom via de CCL, verwerkt het verkeer en stuurt het stroomafwaarts naar de SQL Server.
4. Nu, wanneer ASA 1 het verkeer stroomafwaarts doorstuurt, behoudt het het oorspronkelijke bron-mac-adres van ISP Router 2, dat zich in Datacenter 2 bevindt en het stroomafwaarts verzendt.
5. Wanneer Switch 1 dit specifieke verkeer ontvangt, logt het in een MAC MOVE-melding omdat het oorspronkelijk het ISP Router 2 MAC-adres ziet via de OTV-link die is verbonden met Datacenter 2 en nu ziet het het verkeer dat binnenkomt van de interfaces die zijn verbonden met de ASA 1.

Aanbevelingen

Het wordt aanbevolen om gecentraliseerde verbindingen te routeren naar de locatie waar de primaire verbinding wordt gehost (op basis van prioriteiten), zoals weergegeven in de afbeelding:

Scenario 3

Voor een Inter Domain Controller (DC)-communicatie in transparante modus wordt deze specifieke verkeersstroom niet behandeld of gedocumenteerd, maar deze specifieke verkeersstroom werkt vanuit een ASA-stroomverwerkingsstandpunt. Het kan echter resulteren in MAC-verhuizingsmeldingen op de switch. 

1. De host 1 op VLAN 35 probeert te communiceren met host 2 die aanwezig is in het andere datacenter.
2. De Host 1 heeft een standaardgateway die Router 1 is en Router 1 heeft een pad om Host 2 te bereiken door rechtstreeks via een alternatieve link met Router 2 te kunnen communiceren en in dit geval gaan we uit van Multiprotocol Label Switching (MPLS) en niet via het ASA-cluster.
3. Router 2 ontvangt het inkomende verkeer en stuurt het door naar Host 2.
4. Wanneer host 2 nu terugreageert, ontvangt router 2 het retourverkeer en vindt het een direct verbonden route door de ASA's in plaats van het verkeer dat het over de MPLS verzendt. 
5. In dit stadium heeft het verkeer dat Router 2 verlaat de bron MAC van de exit-interface van Router 2.
6. De ASA's in Datacenter 2 ontvangen het retourverkeer en vinden een verbinding die bestaat en wordt gemaakt door de ASA's in Datacenter 1.
7. De ASA’s in Datacenter 2 sturen het retourverkeer via CCL terug naar de ASA’s in Datacenter 1.
8. In dit stadium verwerken de ASA’s in Datacenter 1 het retourverkeer en sturen het naar de Switch 1. Het pakket heeft nog steeds dezelfde MAC-bron als die van de exit-interface van Router 2.
9. Wanneer Switch 1 nu het pakket ontvangt, registreert het een MAC-verzetmelding omdat het in eerste instantie het MAC-adres van Router 2 leerde via de interface die is verbonden met de OTV-link, maar in dit stadium begint het het MAC-adres te leren van de interface die is verbonden met de ASA's.
   
   

Scenario 4

Verkeer gegenereerd door de ASA, zoals weergegeven in de afbeelding:

Dit specifieke geval zal worden waargenomen voor elk verkeer dat wordt gegenereerd door de ASA zelf. Hier worden twee mogelijke situaties overwogen, waarbij de ASA ofwel probeert een Network Time Protocol (NTP) of een Syslog-server te bereiken, die zich op hetzelfde subnet bevinden als die van zijn BVI-interface.Deze situatie is echter niet alleen beperkt tot deze twee voorwaarden, deze situatie kan zich voordoen wanneer verkeer wordt gegenereerd door de ASA voor elk IP-adres dat rechtstreeks is verbonden met de BVI IP-adressen.

1. Als ASA niet beschikt over de ARP-informatie van de NTP-server/Syslog-server, genereert de ASA een ARP-verzoek voor die server.
2. Aangezien het ARP-verzoek een broadcast-pakket is, ontvangt de Switch 1 dit pakket van de gekoppelde interface van de ASA en wordt het verspreid over alle interfaces in het specifieke VLAN, inclusief de externe site over de OTV.
3. De Remote site Switch 2 ontvangt dit ARP-verzoek van de OTV-link en vanwege de bron-MAC van de ASA genereert het een MAC-flapmelding omdat hetzelfde MAC-adres via de lokale direct verbonden interfaces met de ASA over de OTV wordt geleerd.

Scenario 5

 Verkeer bestemd voor het BVI IP-adres van de ASA vanaf een direct verbonden host, zoals weergegeven in de afbeelding:

Een MAC MOVE kan ook worden waargenomen op momenten dat het verkeer bestemd is voor het BVI IP-adres van de ASA. 

In het scenario hebben we een hostmachine op een direct aangesloten netwerk van de ASA en proberen we verbinding te maken met de ASA.

1. De host heeft geen ARP van de ASA en activeert een ARP-verzoek.
2. De Nexus ontvangt het verkeer en opnieuw als het een uitzending verkeer het stuurt het verkeer over de OTV naar de andere site ook. 
3. De ASA op het externe Datacenter 2 kan reageren op het ARP-verzoek en stuurt het verkeer terug via hetzelfde pad dat Switch 2 is aan de externe kant, OTV, Switch 1 aan de lokale kant en vervolgens de eindhost.
4. Wanneer de ARP-reactie wordt gezien aan de lokale kant van Switch 1, activeert het een MAC-bewegingsmelding omdat het het MAC-adres van de ASA ziet dat binnenkomt via de OTV-link.

Scenario 6

ASA is ingesteld om verkeer te weigeren waarmee het een RST naar de host verzendt, zoals weergegeven in de afbeelding:

In dit geval hebben we een host 1 op VLAN 35, het probeert te communiceren met host 2 in hetzelfde Layer 3 VLAN, maar host 2 bevindt zich eigenlijk op Datacenter 2 VLAN 1535.

1. Het 2MAC-adres van de host zou te zien zijn op Switch 2 via de interface die is verbonden met de ASA's.
2. Switch 1 zou het MAC-adres van Host 2 zien via de OTV-link.
3. Host 1 verzendt verkeer naar Host 2 en dit volgt het pad van Switch 1, OTV, Switch 2, ASA's in Datacenter 2.
4. Dit specifieke wordt geweigerd door de ASA en als ASA is geconfigureerd om een RST terug te sturen naar Host 1, komt het RST-pakket terug met ASA's bron-MAC-adres.
5. Wanneer dit pakket terugkeert naar Switch 1 in de OTV, registreert Switch 1 een MAC MOVE-melding voor het MAC-adres van ASA, omdat het nu het MAC-adres over de OTV ziet, waarin voordat het het adres vanuit de direct verbonden interface ziet.

Verifiëren

Er is momenteel geen verificatieprocedure beschikbaar voor deze configuratie.

Problemen oplossen

Er is momenteel geen specifieke troubleshooting-informatie beschikbaar voor deze configuratie.

Gerelateerde informatie

• Configuratiehandleiding voor de CLI van de Cisco ASA-reeks
• Technische ondersteuning en documentatie – Cisco Systems