In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden die in den Catalyst Switches der Serie 9000 verwendeten Switch Integrated Security Features (SISF) beschrieben. Außerdem wird erläutert, wie SISF verwendet werden kann und wie es mit anderen Funktionen interagiert.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Die Informationen in diesem Dokument basieren auf Cisco Catalyst 9300-48P mit Cisco IOS® XE 17.3.x
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.
Hinweis: Informationen zu den Befehlen, die zur Aktivierung dieser Funktionen auf anderen Cisco Plattformen verwendet werden, finden Sie im entsprechenden Konfigurationsleitfaden.
Dieses Dokument kann auch mit folgenden Hardware- und Softwareversionen verwendet werden:
Ab Version 17.3.4 der Cisco IOS XE Software
Hinweis: Dieses Dokument gilt auch für die meisten Cisco IOS XE-Versionen, bei denen SISF und Geräteverfolgung zum Einsatz kommen.
SISF stellt eine Host-Binding-Tabelle bereit, und es gibt Feature-Clients, die die Informationen aus dieser Tabelle verwenden. Die Einträge werden in die Tabelle durch gelesene Pakete wie DHCP, ARP, ND oder RA aufgenommen, die die Host-Aktivität verfolgen und dabei helfen, die Tabelle dynamisch zu füllen. Wenn die L2-Domäne über unbeaufsichtigte Hosts verfügt, können statische Einträge verwendet werden, um der SISF-Tabelle Einträge hinzuzufügen.
SISF verwendet ein Richtlinienmodell, um Geräterollen und zusätzliche Einstellungen auf dem Switch zu konfigurieren. Eine einzelne Richtlinie kann auf Schnittstellen- oder VLAN-Ebene angewendet werden. Wenn eine Richtlinie für das VLAN und eine andere Richtlinie für die Schnittstelle angewendet wird, hat die Schnittstellenrichtlinie Vorrang.
SISF kann auch verwendet werden, um die Anzahl der Hosts in der Tabelle zu begrenzen, es bestehen jedoch Unterschiede zwischen dem IPv4- und dem IPv6-Verhalten. Wenn der SISF-Grenzwert festgelegt und erreicht wird:
Ab Version 16.9.x und neuerer Version wird eine SISF-Client-Funktionspriorität eingeführt. Es fügt Optionen hinzu, um die Updates in SISF zu steuern. Wenn zwei oder mehr Clients die Bindungstabelle verwenden, werden Updates von der Funktion mit höherer Priorität angewendet. Die Ausnahmen sind die "limit address-count for IPv4//IPv6 per mac"-Einstellungen. Die Einstellungen der Richtlinie mit der niedrigsten Priorität sind wirksam.
Hier einige Beispiele, bei denen die Geräteverfolgung aktiviert sein muss:
Hinweis: Zur Auswahl der Richtlinieneinstellungen wird die Priorität verwendet.
Die über die CLI erstellte Richtlinie hat die höchste Priorität (128). Dadurch können Benutzer eine andere Richtlinieneinstellung anwenden als in den programmgesteuerten Richtlinien. Alle konfigurierbaren Einstellungen unter der benutzerdefinierten Richtlinie können manuell geändert werden.
Das nächste Bild zeigt eine SISF-Richtlinie und wie sie gelesen wird:
Innerhalb der Richtlinie können Sie unter "protocol Keyword" (Protokollschlüsselwort) feststellen, welche Pakettypen zum Füllen der SISF-Datenbank verwendet werden:
switch(config-device-tracking)#? device-tracking policy configuration mode: data-glean binding recovery by data traffic source address gleaning default Set a command to its defaults destination-glean binding recovery by data traffic destination address gleaning device-role Sets the role of the device attached to the port distribution-switch Distribution switch to sync with exit Exit from device-tracking policy configuration mode limit Specifies a limit medium-type-wireless Force medium type to wireless no Negate a command or set its defaults prefix-glean Glean prefixes in RA and DHCP-PD traffic protocol Sets the protocol to glean (default all) <-- security-level setup security level tracking Override default tracking behavior trusted-port setup trusted port vpc setup vpc port switch(config-device-tracking)#protocol ? arp Glean addresses in ARP packets dhcp4 Glean addresses in DHCPv4 packets dhcp6 Glean addresses in DHCPv6 packets ndp Glean addresses in NDP packets udp Gleaning from UDP packets
Die Funktionen in der nächsten Tabelle aktivieren SISF entweder programmgesteuert, wenn sie aktiviert sind, oder fungieren als SISF-Client:
SISF-Programmfunktion |
Funktionen des SISF-Clients |
LISP im VLAN |
Punkt 1x |
EVPN im VLAN |
Webauthentifizierung |
DHCP-Snooping |
CTS |
Wenn eine SISF-Clientfunktion auf einem Gerät aktiviert ist, das ohne eine Funktion konfiguriert ist, die SISF aktiviert, muss eine benutzerdefinierte Richtlinie auf Schnittstellen konfiguriert werden, die mit Hosts verbunden sind.
Die Hauptrolle der Geräteverfolgung besteht darin, die Präsenz, den Standort und die Bewegung von Endknoten im Netzwerk zu verfolgen. SISF tastet den vom Switch empfangenen Datenverkehr ab, extrahiert die Geräteidentität (MAC- und IP-Adresse) und speichert sie in einer Bindungstabelle. Viele Funktionen, wie IEEE 802.1X, Web-Authentifizierung, Cisco TrustSec und LISP usw., hängen von der Genauigkeit dieser Informationen ab, um ordnungsgemäß zu funktionieren. Die SISF-basierte Geräteverfolgung unterstützt IPv4 und IPv6. Es gibt fünf Methoden, mit denen der Client IP lernen kann:
Die Geräteverfolgung auf Port-Channels (oder Etherchannels) wird unterstützt. Die Konfiguration muss jedoch auf die Channel-Gruppe und nicht auf die einzelnen Port-Channel-Mitglieder angewendet werden. Die einzige Schnittstelle, die vom Bindungsstandpunkt aus angezeigt wird (und bekannt ist), ist der Port-Channel.
Sonde:
Datenbank:
In SISF können Sie einige Optionen konfigurieren, um zu steuern, wie lange ein Eintrag in der Datenbank gespeichert wird:
tracking enable reachable-lifetime <second|infinite> <-- how long an entry is kept reachable (or keep permanently reachable)
tracking disable stale-lifetime <seconds|infinite> <-- how long and entry is kept inactive before deletion (or keep permanently inactive)
Lebenszyklus eines Eintrags, zu dem der Host abgefragt wird:
Arten von Knotendiebstählen:
Dies sind einige der SISF-abhängigen Funktionen:
Zu den häufigsten Verhaltensweisen im Zusammenhang mit SISF gehören:
Das Topologiediagramm wird für das nächste SISF-Szenario verwendet. Bei 9300-Switches handelt es sich nur um Layer-2-Switches, für die im Client-VLAN 10 KEINE SVI konfiguriert ist.
Hinweis: SISF wird in dieser Übung manuell aktiviert.
Die Standard-SISF-Konfiguration wurde auf beiden 9300 Switches mit Access-Ports eingerichtet, während auf die Trunk-Ports eine benutzerdefinierte Richtlinie angewendet wurde, um die erwarteten SISF-Ausgaben zu veranschaulichen.
Switch 9300-1:
9300-1#show running-config interface GigabitEthernet 1/0/1 Building configuration... Current configuration : 111 bytes ! interface GigabitEthernet1/0/1 switchport access vlan 10 switchport mode access device-tracking <-- enable default SISF policy end
9300-1#
9300-1#show running-config | section trunk-policy
device-tracking policy trunk-policy <-- custom policy
trusted-port <-- custom policy parameters
device-role switch <-- custom policy parameters
no protocol udp
9300-1# 9300-1#show running-config interface tenGigabitEthernet 1/1/1 Building configuration... Current configuration : 109 bytes ! interface TenGigabitEthernet1/1/1 switchport mode trunk device-tracking attach-policy trunk-policy <-- enable custom SISF policy
end
Switch 9300-2:
9300-2#show running-config interface GigabitEthernet 1/0/2 Building configuration... Current configuration : 105 bytes ! interface GigabitEthernet1/0/2 switchport access vlan 10 switchport mode access device-tracking <-- enable default SISF policy end
9300-2#show running-config | section trunk-policy
device-tracking policy trunk-policy <-- custom policy
trusted-port <-- custom policy parameters
device-role switch <-- custom policy parameters
no protocol udp
9300-2#show running-config interface tenGigabitEthernet 1/1/1 Building configuration... Current configuration : 109 bytes ! interface TenGigabitEthernet1/1/1 switchport mode trunk device-tracking attach-policy trunk-policy <-- custom policy applied to interface
end
Mit den folgenden Befehlen können Sie die angewendeten Richtlinien validieren:
show device-tracking policy <policy name>
show device-tracking policies
show device-tracking database
Switch 9300-1:
9300-1#show device-tracking policy default Device-tracking policy default configuration: security-level guard device-role node <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy default is applied on the following targets: Target Type Policy Feature Target range Gi1/0/1 PORT default Device-tracking vlan all
9300-1#show device-tracking policy trunk-policy Device-tracking policy trunk-policy configuration: trusted-port <-- security-level guard device-role switch <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy trunk-policy is applied on the following targets: Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all 9300-1#
9300-1#show device-tracking policies Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all Gi1/0/1 PORT default Device-tracking vlan all
9300-1#show device-tracking database Binding Table has 1 entries, 1 dynamic (limit 200000) Codes: L - Local, S - Static, ND - Neighbor Discovery, ARP - Address Resolution Protocol, DH4 - IPv4 DHCP, DH6 - IPv6 DHCP, PKT - Other Packet, API - API created Preflevel flags (prlvl): 0001:MAC and LLA match 0002:Orig trunk 0004:Orig access 0008:Orig trusted trunk 0010:Orig trusted access 0020:DHCP assigned 0040:Cga authenticated 0080:Cert authenticated 0100:Statically assigned Network Layer Address Link Layer Address Interface vlan prlvl age state Time left ARP 10.10.10.100 98a2.c07e.7902 Gi1/0/1 10 0005 8s REACHABLE 306 s 9300-1#
Switch 9300-2:
9300-2#show device-tracking policy default Device-tracking policy default configuration: security-level guard device-role node <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy default is applied on the following targets: Target Type Policy Feature Target range Gi1/0/2 PORT default Device-tracking vlan all
9300-2#show device-tracking policy trunk-policy Device-tracking policy trunk-policy configuration: trusted-port <-- security-level guard device-role switch <-- gleaning from Neighbor Discovery gleaning from DHCP gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn Policy trunk-policy is applied on the following targets: Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all 9300-2#
9300-2#show device-tracking policies Target Type Policy Feature Target range Te1/1/1 PORT trunk-policy Device-tracking vlan all Gi1/0/2 PORT default Device-tracking vlan all
9300-2#show device-tracking database Binding Table has 1 entries, 1 dynamic (limit 200000) Codes: L - Local, S - Static, ND - Neighbor Discovery, ARP - Address Resolution Protocol, DH4 - IPv4 DHCP, DH6 - IPv6 DHCP, PKT - Other Packet, API - API created Preflevel flags (prlvl): 0001:MAC and LLA match 0002:Orig trunk 0004:Orig access 0008:Orig trusted trunk 0010:Orig trusted access 0020:DHCP assigned 0040:Cga authenticated 0080:Cert authenticated 0100:Statically assigned Network Layer Address Link Layer Address Interface vlan prlvl age state Time left ARP 10.10.10.101 98a2.c07e.9902 Gi1/0/2 10 0005 41s REACHABLE 273 s 9300-2#
Problem
Die vom Switch gesendete Keepalive-Anfrage ist eine L2-Prüfung. Aus Sicht des Switches sind daher die in den ARPs als Quelle verwendeten IP-Adressen unwichtig: Diese Funktion kann auf Geräten verwendet werden, auf denen überhaupt keine IP-Adresse konfiguriert ist, sodass die IP-Quelle 0.0.0.0 nicht relevant ist. Wenn der Host diese Nachrichten empfängt, antwortet er zurück und füllt das Ziel-IP-Feld mit der einzigen im empfangenen Paket verfügbaren IP-Adresse, nämlich der eigenen IP-Adresse, auf. Dies kann zu Warnungen über falsche doppelte IP-Adressen führen, da der Host, der antwortet, seine eigene IP-Adresse sowohl als Quelle als auch als Ziel des Pakets sieht.
Es wird empfohlen, die SISF-Richtlinie so zu konfigurieren, dass für ihre Keepalive-Tests eine automatische Quelle verwendet wird.
Hinweis: Weitere Informationen finden Sie in diesem Artikel über doppelte Adressprobleme.
Standardprobe
Dies ist das Testpaket, wenn keine lokale SVI vorhanden ist, und die Standardeinstellungen für Tests:
Ethernet II, Src: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02), Dst: Cisco_76:63:c6 (00:41:d2:76:63:c6) <-- Probe source MAC is the BIA of physical interface connected to client Destination: Cisco_76:63:c6 (00:41:d2:76:63:c6) Address: Cisco_76:63:c6 (00:41:d2:76:63:c6) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: 000000000000000000000000000000000000 Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Sender IP address: 0.0.0.0 <-- Sender IP is 0.0.0.0 (default) Target MAC address: Cisco_76:63:c6 (00:41:d2:76:63:c6) Target IP address: 10.10.10.101 <-- Target IP is client IP
Lösung
Konfigurieren Sie den Prüfpunkt so, dass er eine andere Adresse als den Host-PC für den Prüfpunkt verwendet. Dies kann mit diesen Methoden erreicht werden
Automatische Quelle für "Verbindung aufrecht halten"
Konfigurieren Sie eine automatische Quelle für die Keepalive-Tests, um die Nutzung von 0.0.0.0 als Quell-IP zu reduzieren:
device-tracking tracking auto-source fallback <IP> <MASK> [override]
Die Logik bei Anwendung des Auto-Source-Befehls funktioniert wie folgt:
device-tracking tracking auto-source fallback 0.0.0.253 255.255.255.0 [override] <-- Optional parameter
Hinweis: Wenn der Befehl mit <override> angewendet wird, springen wir immer zu Schritt 3.
Modifizierte Sonde
Durch das Festlegen der Konfiguration für den automatischen Quell-Fallback zur Verwendung einer IP im Subnetz wird der Prüfpunkt geändert. Da keine SVI und kein anderer Client im Subnetz vorhanden ist, greifen wir auf die konfigurierte IP/Maske in der Konfiguration zurück.
switch(config)#device-tracking tracking auto-source fallback 0.0.0.253 255.255.255.0 <-- it uses .253 for all subnets where there is no existing client and no SVI
Dies ist das modifizierte Probe-Paket:
Ethernet II, Src: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02), Dst: Cisco_76:63:c6 (00:41:d2:76:63:c6) <-- Probe source MAC is the BIA of physical interface connected to client Destination: Cisco_76:63:c6 (00:41:d2:76:63:c6) Address: Cisco_76:63:c6 (00:41:d2:76:63:c6) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: ARP (0x0806) Padding: 000000000000000000000000000000000000 Address Resolution Protocol (request) Hardware type: Ethernet (1) Protocol type: IPv4 (0x0800) Hardware size: 6 Protocol size: 4 Opcode: request (1) Sender MAC address: c0:64:e4:cc:66:02 (c0:64:e4:cc:66:02) Sender IP address: 10.10.10.253 <-- Note the new sender IP is now using the fallback IP configured. Target MAC address: Cisco_76:63:c6 (00:41:d2:76:63:c6) Target IP address: 10.10.10.101
Weitere Informationen zum Verhalten von Sonden
Command |
Aktion (Zur Auswahl der Quell-IP- und MAC-Adresse für die ARP-Anfrage zur Geräteverfolgung) |
Hinweise |
automatische Geräteverfolgung |
|
Wir empfehlen, die Geräteverfolgung auf allen Trunk-Ports zu deaktivieren, um MAC-Flapping zu vermeiden. |
Überschreiben der automatischen Geräteverfolgung |
|
Wird nicht empfohlen, wenn keine SVI vorhanden ist. |
Device-Tracking Auto-Source Fallback <IP> <MASK> |
|
Wir empfehlen, die Geräteverfolgung auf allen Trunk-Ports zu deaktivieren, um MAC-Flapping zu vermeiden. Die berechnete IPv4-Adresse darf keinem Client oder Netzwerkgerät zugewiesen werden. |
Device-Tracking Autosource-Fallback <IP> <MASK> überschreiben |
|
Die berechnete IPv4-Adresse darf keinem Client oder Netzwerkgerät zugewiesen werden. |
Erläuterung des Befehls device-tracking auto-source fallback <IP> <MASK> [override]:
Je nach Host-IP muss eine IPv4-Adresse reserviert werden.
<reserved IPv4 address> = (<host-ip> & <MASK> ) | <IP>
Hinweis: Dies ist eine boolesche Formel.
Beispiel.
Wenn wir den Befehl verwenden:
device-tracking tracking auto-source fallback 0.0.0.1 255.255.255.0 override
host IP = 10,152.140,25
IP = 0,0.0,1
Maske = 24
Lässt die boolesche Formel in zwei Teile unterbrechen.
1. Betrieb: 10.152.140.25 UND 255.255.255.0
10.152.140.25 = 00001010.10011000.10001100.00011001 AND 255.255.255.0 = 11111111.11111111.11111111.00000000 RESULT 10.152.140.0 = 00001010.10011000.10001100.00000000
2. Betrieb: 10.152.140.0 ODER 0.0.0.1:
10.152.140.0 = 00001010.10011000.10001100.00000000 OR 0.0.0.1 = 00000000.00000000.00000000.00000001 RESULT 10.152.140.1 = 00001010.10011000.10001100.00000001
Reservierte IP = 10,152.140,1
Reservierte IP = (10.152.140.25 und 255.255.255.0) | (0,0.0,1) = 10,152.140,1
Hinweis: Die als IP-Quelle verwendete Adresse muss einen Bereich außerhalb der DHCP-Bindungen für das Subnetz aufweisen.
Problem
Fehler bei doppelter IPv6-Adresse, wenn IPv6 im Netzwerk aktiviert und eine Switched Virtual Interface (SVI) in einem VLAN konfiguriert ist.
In einem normalen IPv6-DAD-Paket wird das Feld "Source Address" (Quelladresse) im IPv6-Header auf die nicht angegebene Adresse (0:0:0:0:0:0:0:0:0) festgelegt. Ähnlich wie bei IPv4.
Wählen Sie im SISF-Test die Quelladresse aus:
Lösung
Es wird empfohlen, der SVI-Konfiguration die nächsten Befehle hinzuzufügen. Auf diese Weise kann die SVI automatisch eine Link-Local-Adresse abrufen. Diese Adresse wird als Quell-IP-Adresse des SISF-Tests verwendet, um ein Duplikat der IP-Adresse zu vermeiden.
interface vlan <vlan> ipv6 enable
Problem
Die vom Switch gesendete Keepalive-Anfrage wird über alle Ports gesendet, wenn sie programmgesteuert aktiviert ist. Verbundene Switches in derselben L2-Domäne senden diese Broadcasts an ihre Hosts, sodass der ursprüngliche Switch Remote-Hosts seiner Geräteverfolgungsdatenbank hinzufügt. Die zusätzlichen Hosteinträge erhöhen die Speichernutzung auf dem Gerät, und der Vorgang des Hinzufügens der Remote-Hosts erhöht die CPU-Nutzung des Geräts.
Es wird empfohlen, die programmatische Richtlinie durch Konfigurieren einer Richtlinie für den Uplink zu angeschlossenen Switches zu erweitern, um den Port als vertrauenswürdig und an einen Switch angeschlossen zu definieren.
Hinweis: Beachten Sie, dass SISF-abhängige Funktionen wie DHCP-Snooping das ordnungsgemäße Funktionieren von SISF ermöglichen, was dieses Problem auslösen kann.
Lösung
Konfigurieren Sie eine Richtlinie für den Uplink (Trunk), um Tests und das Lernen von Remote-Hosts zu stoppen, die von anderen Switches bevorzugt werden (SISF wird nur zum Verwalten der lokalen Hosttabelle benötigt).
device-tracking policy DT_trunk_policy trusted-port device-role switch interface <interface> device-tracking policy DT_trunk_policy
Problem
Aufgrund eines Migrationsproblems von IPDT zu SISF-basierter Geräteverfolgung kommt es bei der Migration von älteren Versionen auf 16.x und neuere Versionen manchmal zu einer nicht standardmäßigen erreichbaren Zeit.
Lösung
Es wird empfohlen, die erreichbare Standardzeit wiederherzustellen. Hierzu konfigurieren Sie:
no device-tracking binding reachable-time <seconds>
Problem
Wenn Switches in das Meraki Cloud-Überwachungstool integriert werden, wendet dieses Tool benutzerdefinierte Richtlinien für die Geräteverfolgung an.
device-tracking policy MERAKI_POLICY security-level glean no protocol udp tracking enable
Die Richtlinie wird unterschiedslos auf alle Schnittstellen angewendet, d. h. sie unterscheidet nicht zwischen Edge-Ports und Trunk-Ports, die anderen Netzwerkgeräten (z. B. Switches, Firewalls, Router usw.) gegenüberliegen. Der Switch kann mehrere SISF-Einträge auf Trunk-Ports erstellen, auf denen MERAKI_POLICY konfiguriert ist, was zu Leerungen an diesen Ports sowie zu einem Anstieg der CPU-Auslastung führt.
switch#show interfaces port-channel 5
Port-channel5 is up, line protocol is up (connected)
<omitted output> Input queue: 0/2000/0/112327 (size/max/drops/flushes); Total output drops: 0 <-- we have many flushes <omitted output>
switch#show process cpu sorted CPU utilization for five seconds: 26%/2%; one minute: 22%; five minutes: 22% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 572 1508564 424873 3550 11.35% 8.73% 8.95% 0 SISF Main Thread 105 348502 284345 1225 2.39% 2.03% 2.09% 0 Crimson flush tr
Lösung
Richten Sie die nächste Richtlinie für alle Nicht-Edge-Schnittstellen ein:
configure terminal device-tracking policy NOTRACK no protocol ndp no protocol dhcp6 no protocol arp no protocol dhcp4 no protocol udp exit
interface <interface> device-tracking policy NOTRACK end
Problem
Dieses Szenario tritt häufig bei Appliances im HA-Modus (hohe Verfügbarkeit) auf, die unterschiedliche IP-Adressen, aber dieselbe MAC-Adresse verwenden. Sie wird auch in VM-Umgebungen beobachtet, die denselben Zustand aufweisen (eine MAC-Adresse für zwei oder mehr IP-Adressen). Diese Bedingung verhindert Netzwerkverbindungen zu allen IPs, die keinen Eintrag in der SISF-Tabelle haben, wenn eine benutzerdefinierte SISF-Richtlinie im Schutzmodus aktiviert ist.Gemäß der SISF-Funktion wird nur eine IP pro MAC-Adresse gelernt.
Hinweis: Dieses Problem tritt bei Versionen 17.7.1 und höher auf.
Beispiel:
SISF-Richtlinie
switch#show run | sec IPDT_POLICY device-tracking policy IPDT_POLICY no protocol udp tracking enable
switch#show device-tracking policy IPDT_POLICY Device-tracking policy IPDT_POLICY configuration: security-level guard <-- default mode device-role node gleaning from Neighbor Discovery gleaning from DHCP6 gleaning from ARP gleaning from DHCP4 NOT gleaning from protocol unkn tracking enable Policy IPDT_POLICY is applied on the following targets: Target Type Policy Feature Target range Gi1/0/1 PORT IPDT_POLICY Device-tracking vlan all Gi1/0/2 PORT IPDT_POLICY Device-tracking vlan all
SISF-Datenbank
switch#show device-tracking database Binding Table has 2 entries, 2 dynamic (limit 200000) Codes: L - Local, S - Static, ND - Neighbor Discovery, ARP - Address Resolution Protocol, DH4 - IPv4 DHCP, DH6 - IPv6 DHCP, PKT - Other Packet, API - API created Preflevel flags (prlvl): 0001:MAC and LLA match 0002:Orig trunk 0004:Orig access 0008:Orig trusted trunk 0010:Orig trusted access 0020:DHCP assigned 0040:Cga authenticated 0080:Cert authenticated 0100:Statically assigned Network Layer Address Link Layer Address Interface vlan prlvl age state Time left ARP 10.0.0.3 10b3.d659.7858 Gi1/0/3 10 0005 90s REACHABLE 222 s try 0 ARP 10.0.0.1 10b3.d5a9.bd9f Gi1/0/1 10 0005 84s REACHABLE 220 s try 0
Erreichbarkeitstest Server A
ServerA#ping 10.0.0.3 source 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
ServerA#ping 10.0.0.3 source 10.0.0.100 <-- entry for 10.0.0.100 is not on SISF table
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.100
.....
Erreichbarkeitstest Server B.
ServerB#ping 10.0.0.3 <-- entry for 10.0.0.2 is not on SISF table
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Validierung verwirft auf Switch.
switch(config)#device-tracking logging
Protokolle
switch#show logging
<omitted output>
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.100 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/1 P=ARP Reason=Packet accepted but not forwarded
<omitted output>
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
%SISF-4-PAK_DROP: Message dropped IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f I/F=Gi1/0/2 P=ARP Reason=Packet accepted but not forwarded
%SISF-4-MAC_THEFT: MAC Theft IP=10.0.0.2 VLAN=10 MAC=10b3.d5a9.bd9f IF=Gi1/0/1 New I/F=Gi1/0/2
Lösung
Option 1: Wenn Sie die IPDT-Richtlinie vom Port entfernen, können ARP-Pakete und betroffene Geräte erreicht werden
switch(config)#interface gigabitEthernet 1/0/1
switch(config-if)#no device-tracking attach-policy IPDT_POLICY
switch(config-if)#interface gigabitEthernet 1/0/2
switch(config-if)#no device-tracking attach-policy IPDT_POLICY
Option 2: Entfernen Sie Protokoll-ARP-Läuterung aus der Richtlinie zur Geräteverfolgung.
switch(config)#device-tracking policy IPDT_POLICY
switch(config-device-tracking)#no protocol arp
Option 3: Ändern Sie die Sicherheitsstufe von "IPDT_POLICY" in "Glean".
switch(config)#device-tracking policy IPDT_POLICY
switch(config-device-tracking)#security-level glean
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
17-Jan-2024 |
Erstveröffentlichung |