Überprüfen des Synchronisierungsverhaltens der ARP- und MAC-Tabelle der Nexus Serie 9000

Einleitung

In diesem Dokument wird ein spezifisches Synchronisierungsverhalten beschrieben, das in den ARP- und MAC-Adresstabellen der Cisco Nexus Switches der Serie 9000 beobachtet wird. 

Voraussetzungen

Anforderungen

Um die Vorteile dieses Dokuments vollständig zu nutzen, verfügt der Leser über ein grundlegendes Verständnis verschiedener wichtiger Konzepte und Technologien:

1. Virtual Port Channel (vPC): Vertrautheit mit Einrichtung, Konfiguration und Betriebsmanagement von vPCs, da diese wesentlich zum Verständnis der beschriebenen Netzwerkszenarien beitragen.

2. Virtual Port Channel Peer Gateway-Funktion von NX-OS: Kenntnisse der Funktion des Peer-Gateways in einer vPC-Konfiguration, einschließlich seiner Rolle bei der Weiterleitung von Datenverkehr und bei Redundanzmechanismen.

3. Cisco Nexus Operating System (NX-OS): Grundlegendes Verständnis von NX-OS mit Schwerpunkt auf der Kommandozeile und typischen Konfigurationen für Nexus Switches der Serie 9000.

Verwendete Komponenten

• Switch-Modelle: Switches der Serien Nexus 3000 und Nexus 9000 (nur Switches der ersten Generation), die aufgrund ihrer einzigartigen ASIC-Einschränkungen eine zentrale Rolle bei der Veranschaulichung des Verhaltens der ARP- und MAC-Tabelle spielen.

• Virtual Port Channel (vPC): Konfiguriert zum Testen des Synchronisierungsverhaltens aller verbundenen Geräte. 

• vPC-Peer-Gateway-Funktion: Wird innerhalb der vPC-Domäne aktiviert, um den Einfluss dieser Funktion auf die ARP- und MAC-Synchronisierung zu untersuchen.

• Layer-2-Trunk (nicht vPC): Dient zum Anschließen der Nexus-Peers.

• Non-vPC Switch Virtual Interfaces (SVIs): Diese Schnittstellen sind so konfiguriert, dass sie das Verhalten untersuchen, wenn keine benutzerdefinierten MAC-Adressen verwendet werden. Sie heben die Standardbehandlung bei der Synchronisierung von ARP- und MAC-Adressen hervor.

• Betriebssystem: NX-OS Version 7.0(3)I7(5)

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

In komplexen Netzwerkumgebungen ist die Synchronisierung von Address Resolution Protocol (ARP)- und MAC-Adresstabellen zwischen verbundenen Geräten unerlässlich, um einen konsistenten Datenfluss und die Zuverlässigkeit des Netzwerks sicherzustellen. Dieser Leitfaden soll Ihnen einen umfassenden Überblick über diese Verhaltensweisen geben. Er wird durch praktische Laborbeobachtungen und Konfigurationen unterstützt und hilft bei der Fehlerbehebung und effektiven Konfiguration von Switches der Serie Nexus 9000. 

Die in diesem Dokument beschriebenen Synchronisierungsprobleme bei ARP und MAC-Adressen beziehen sich auf bestimmte Konfigurationen von Cisco Nexus Switches der Serie 9000. Diese Probleme treten in erster Linie unter zwei Bedingungen auf:

1. Wenn Switch Virtual Interfaces (SVIs) ohne benutzerdefinierte MAC-Adressen konfiguriert werden

2. Wenn die vPC-Peer-Gateway-Funktion (Virtual Port Channel) in den vPC-Domäneneinstellungen aktiviert ist.

Dieses spezielle Verhalten ist wichtig, da es beeinflusst, wie ARP-Einträge trotz entsprechender MAC-Adresseinträge, die möglicherweise veraltet sind oder explizit aus der MAC-Adresstabelle gelöscht werden, beibehalten werden. Dies kann zu Inkonsistenzen bei der Paketweiterleitung und der Instabilität des Netzwerks führen.

Außerdem ist zu beachten, dass dieses Verhalten auf eine ASIC-Hardwarebeschränkung zurückzuführen ist, die nur bei Switches der Serie Nexus 9000 der ersten Generation gegeben ist. Diese Einschränkung gilt nicht für die später eingeführten Cloud-Scale-Modelle der Nexus Serie 9300 (EX-, FX-, GX- und C-Versionen). Das Problem wurde erkannt und unter dem Cisco Bug IDCSCuh94866 katalogisiert.

Topologie

Überblick

Nehmen wir ein Netzwerkszenario, bei dem VLAN 150 als Nicht-vPC-VLAN konfiguriert ist, die ARP- und die MAC-Adresstabelle zwischen Host-A und Nexus 9000-Switch B (N9K-B) anfangs leer sind und ein Ping von Host-A nach N9K-B initiiert wird.

Host-A# ping 192.0.2.3
PING 192.0.2.3 (192.0.2.3): 56 data bytes
36 bytes from 192.0.2.100: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.0.2.3: icmp_seq=1 ttl=254 time=1.011 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=254 time=0.763 ms
64 bytes from 192.0.2.3: icmp_seq=3 ttl=254 time=0.698 ms
64 bytes from 192.0.2.3: icmp_seq=4 ttl=254 time=0.711 ms

--- 192.0.2.3 ping statistics ---
5 packets transmitted, 4 packets received, 20.00% packet loss
round-trip min/avg/max = 0.698/0.795/1.011 ms

Dieser Ping fordert Host-A auf, eine ARP-Anforderung an N9K-B zu senden. Diese Anforderung wird über Port-Channel 21 (Po21) auf Nexus 9000-Switch A (N9K-A) gesendet, der für VLAN-Flooding zuständig ist. Gleichzeitig wird die Anforderung über Cisco Fabric Services (CFS) für Port-Channel 20 (Po20) getunnelt. Als direkte Folge wird die MAC-Adresstabelle auf N9K-B aktualisiert, um den richtigen Eintrag für Host-A aufzunehmen, und ein ARP-Eintrag wird auch in der ARP-Tabelle auf N9K-B eingerichtet, der auf Po21 - den Nicht-vPC-Layer-2-Trunk - als Schnittstelle für die MAC-Adresse von Host-A verweist (0223.e957.6a3a a)

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:01:07  0223.e957.6a3a  Vlan150         

N9K-B# show mac address-table address  | i i 6a3a
*  150     0223.e957.6a3a   dynamic  0         F      F    Po21

N9K-B# show ip arp detail | i 3a
192.0.2.100   00:03:22  0223.e957.6a3a  Vlan150          port-channel21   <<<< Expected port-channel

Das Problem tritt auf, wenn die MAC-Adresse von Host-A aus der MAC-Adresstabelle von N9K-B entfernt wird. Diese Entfernung kann aus verschiedenen Gründen erfolgen, darunter der natürliche Alterungsprozess der MAC-Adresse, der Empfang des Spanning Tree Protocol (STP), Topology Change Notifications (TCNs) oder manuelle Eingriffe wie die Ausführung des dynamischen Befehls clearmac address-table.

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:00:29     0223.e957.6a3a  Vlan150             <<< ARP remains populated

N9K-B# show mac address-table address 0223.e957.6a3a
Legend: 
        * - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
        age - seconds since last seen,+ - primary entry using vPC Peer-Link,
        (T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
   VLAN     MAC Address      Type      age     Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
<empty, no MAC>

N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
64 bytes from 192.0.2.100: icmp_seq=0 ttl=253 time=1.112 ms
64 bytes from 192.0.2.100: icmp_seq=1 ttl=253 time=0.647 ms
64 bytes from 192.0.2.100: icmp_seq=2 ttl=253 time=0.659 ms
64 bytes from 192.0.2.100: icmp_seq=3 ttl=253 time=0.634 ms
64 bytes from 192.0.2.100: icmp_seq=4 ttl=253 time=0.644 ms

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.634/0.739/1.112 ms

Trotz dieser Löschungen ist es bemerkenswert, dass der Ping-Datenverkehr weiterhin erfolgreich ist. Der ARP-Eintrag für Host-A auf N9K-B verweist jedoch unerwartet auf Port-Channel 20 (Po20 - der vPC-Peer-Link) und nicht auf Port-Channel 21 (Po21), der als Layer-2-Trunk ohne vPC bezeichnet wird. Diese Umleitung erfolgt, obwohl VLAN 150 als Nicht-vPC-VLAN konfiguriert ist, was zu einer Inkonsistenz im erwarteten Datenverkehrsfluss führt.

N9K-B# show ip arp detail | i i 6a3a

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry

IP ARP Table for context default
Total number of entries: 2
Address         Age       MAC Address     Interface        Physical Interface  Flags
192.0.2.100   00:15:54   0223.e957.6a3a    Vlan150          port-channel20   <<< Not Po21 once the issue is triggered.

Mit dem Befehl show ip arp internal event-history auf beiden Nexus 9000-Switches können Sie nachweisen, dass Pakete über Cisco Fabric Services (CFS) getunnelt werden:

N9K-B# show ip arp internal event-history event | i i tunnel
    [116] [27772]: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [27772]: Received tunneled packet on iod: Vlan150, physical iod: port-channel20

N9K-A# show ip arp internal event-history event | i i tunnel
    [116] [28142]: Tunnel Packets sent with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [28142]: Tunnel it to peer destined to remote SVI's Gateway MAC. Peer Gateway Enabled

Sie können auch die debug ip arp-Reihe von debug-Befehlen auf 9K-B verwenden, um dieses Verhalten zu beschreiben:

N9K-B# debug logfile TAC_ARP
N9K-B# debug ip arp packet 
N9K-B# debug ip arp event 
N9K-B# debug ip arp error 

N9K-B# show debug logfile TAC_ARP | beg "15:31:23"
2018 Oct 11 15:31:23.954433 arp: arp_send_request_internal: Our own address 192.0.2.3 on interface Vlan150,sender_pid =27661 
2018 Oct 11 15:31:23.955221 arp: arp_process_receive_packet_msg: Received tunneled packet on iod: Vlan150, physical iod: port-channel20 
2018 Oct 11 15:31:23.955253 arp: arp_process_receive_packet_msg: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677 
2018 Oct 11 15:31:23.955275 arp: (context 1) Receiving packet from Vlan150, logical interface Vlan150 physical interface port-channel20, (prty 6) Hrd type 1 Prot type 800 Hrd len 6 Prot len 4 OP 2,  Pkt size 46 
2018 Oct 11 15:31:23.955293 arp: Src 0223.e957.6a3a/192.0.2.100 Dst 00be.758e.5677/192.0.2.3 
2018 Oct 11 15:31:23.955443 arp: arp_add_adj: arp_add_adj: Updating MAC on interface Vlan150, phy-interface port-channel20, flags:0x1 
2018 Oct 11 15:31:23.955478 arp: arp_adj_update_state_get_action_on_add: Different MAC(0223.e957.6a3a) Successful action on add Previous State:0x10, Current State:0x10 Received event:Data Plane Add, entry: 192.0.2.100, 0000.0000.0000, Vlan150, action to be taken send_to_am:TRUE, arp_aging:TRUE 
2018 Oct 11 15:31:23.955576 arp: arp_add_adj: Entry added for 192.0.2.100, 0223.e957.6a3a, state 2 on interface Vlan150, physical interface port-channel20, ismct 0. flags:0x10, Rearp (interval: 0, count: 0), TTL: 1500 seconds update_shm:TRUE 
2018 Oct 11 15:31:23.955601 arp: arp_add_adj: Adj info: iod: 77, phy-iod: 91, ip: 192.0.2.100, mac: 0223.e957.6a3a, type: 0, sync: FALSE, suppress-mode: ARP Suppression Disabled flags:0x10

Die ARP-Antwort von Host A erreicht zuerst Nexus 9000-Switch A (N9K-A) und wird dann auf Nexus 9000-Switch B (N9K-B) getunnelt. N9K-A leitet die ARP-Antwort an seine Kontrollebene weiter und nutzt dabei die vPC-Domänenerweiterung des Peer-Gateways. Mit dieser Konfiguration kann N9K-A das Routing des Pakets für N9K-B verarbeiten, ein Vorgang, der in einer Nicht-vPC-VLAN-Konfiguration normalerweise nicht erwartet wird.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:32:47.378648 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3 <<<< 
2018-10-11 15:32:47.379262 02:23:e9:57:6a:3a -> 00:be:75:8e:56:77 ARP 192.0.2.100 is at 02:23:e9:57:6a:3a

Um das Verhalten der ARP-Antwort zu validieren, kann die Ethanalyzer-Funktion auf NX-OS verwendet werden. Mit diesem Tool wird bestätigt, dass die Kontrollebene von N9K-B diese ARP-Antwort nicht direkt beobachtet. Dies unterstreicht die spezielle Behandlung von ARP-Datenverkehr in vPC-Konfigurationen.

N9K-B# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:33:30.053239 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:16.817309 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:42.222965 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.44?  Tell 192.0.2.43
<snip>

Vorsicht: Je nach der Abfolge von Ereignissen und Umständen kann es zu einem Paketverlust von N9K-B zu Host-A kommen.

N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
36 bytes from 192.0.2.3: Destination Host Unreachable
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

Zusammenfassung und Problemumgehung

Das beobachtete Verhalten, bei dem ARP-Einträge fälschlicherweise auf den vPC-Peer-Link und nicht auf den erwarteten Nicht-vPC-Trunk verweisen, tritt in der Regel unter bestimmten Umständen auf: wenn benutzerdefinierte MAC-Adressen nicht auf Nicht-vPC-Switch Virtual Interfaces (SVIs) konfiguriert sind, selbst wenn diese SVIs nicht für das Routing von Adjacencies über einen vPC verwendet werden.

Dieses Verhalten gilt nur für Nexus 9000-Switches der ersten Generation.

Um dieses Problem zu beheben, wird empfohlen, die MAC-Adressen für die betroffenen SVIs manuell zu konfigurieren. Durch das Ändern der MAC-Adressen kann verhindert werden, dass die ARP-Weiterleitung auftritt. Dadurch wird sichergestellt, dass das Netzwerk wie vorgesehen funktioniert, ohne dass in Nicht-vPC-Szenarien die vPC-Peer-Verbindung verwendet werden muss. 

Problemumgehung:

N9K-A(config)# interface Vlan150
N9K-A(config-if)# mac-address 0000.aaaa.0030
N9K-A(config-if)# end

N9K-B(config)# interface Vlan150
N9K-B(config-if)# mac-address 0000.bbbb.0030
N9K-B(config-if)# end

Hinweis: Aufgrund einer Hardwarebeschränkung können jeweils nur 16 benutzerdefinierte MAC-Adressen pro Gerät konfiguriert werden. Dies wird im Konfigurationsleitfaden für Cisco Nexus Nexus 9000-Schnittstellen dokumentiert, da der Switch eine Beschränkung auf 16 benutzerdefinierte MAC-Adressen (MEv6/statisch) aufweist. Eine Konfiguration nach diesem Grenzwert kann zu Problemen führen, die in der Cisco Bug-ID CSCux84428 dokumentiert sind

Nachdem die Problemumgehung angewendet wurde, kann mithilfe der Ethanalyzer-Funktion auf NX-OS überprüft werden, ob der Nexus 9000-Switch A (N9K-A) die ARP-Antwort nicht mehr an seine Kontrollebene weiterleitet, wodurch die korrekte Verarbeitung der ARP-Antworten im Netzwerk bestätigt wird.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:36:11.675108 00:00:bb:bb:00:30 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3

Zugehörige Informationen

Weitere Informationen zu Layer-2-Trunks ohne vPC, Routing-Nachbarschaften und benutzerdefinierten SVI-MAC-Anforderungen finden Sie im Dokument Create Topology for Routing over Virtual Port Channel (Topologien für Routing über virtuellen Port-Channel erstellen).