Fehlerbehebung bei DHCP-Problemen auf den DHCP Relay Agents der Catalyst Serie 9000
Einleitung
Dieses Dokument beschreibt die Fehlerbehebung bei langsamen oder zeitweiligen Fehlern bei der DHCP-Adresszuweisung auf Catalyst 9000-Switches als DHCP-Relay-Agents.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Dynamic Host Configuration Protocol (DHCP) und DHCP Relay Agents
- Internet Control Message Protocol (ICMP)
- Control Plane Policing (CoPP)
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Catalyst Switches der Serie 9000
- Cisco IOS® XE Versionen 16.x und 17.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.
Verwandte Produkte
Dieses Dokument kann auch mit folgenden Hardware- und Softwareversionen verwendet werden:
- Catalyst Switches der Serien 3650/3850 mit Cisco IOS XE 16.x
Hintergrundinformationen
In diesem Dokument wird die Fehlerbehebung bei langsamen DHCP-Adresszuweisungen (Dynamic Host Configuration Protocol) oder zeitweiligen DHCP-Adresszuweisungsfehlern auf Catalyst Switches der Serie 9000 als DHCP-Relay-Agents beschrieben.
Die Control Plane Policing (CoPP)-Funktion erhöht die Sicherheit auf Ihrem Gerät durch Schutz der CPU vor unnötigem Datenverkehr und Denial-of-Service-Angriffen (DoS). Sie kann außerdem Kontrolldatenverkehr und Verwaltungsdatenverkehr vor Datenverlusten schützen, die durch große Mengen an anderem Datenverkehr mit geringerer Priorität verursacht werden.
Ihr Gerät ist in der Regel in drei Betriebsebenen unterteilt, die jeweils eigene Ziele haben:
- Die Datenebene, auf der die Datenpakete weitergeleitet werden.
- Kontrollebene, um Daten korrekt weiterzuleiten
- die Verwaltungsebene, auf der die Netzwerkelemente verwaltet werden.
Sie können CoPP verwenden, um den Großteil des CPU-gebundenen Datenverkehrs zu schützen und die Routing-Stabilität, Erreichbarkeit und Paketübermittlung sicherzustellen. Am wichtigsten ist, dass Sie CoPP verwenden können, um die CPU vor einem DoS-Angriff zu schützen.
CoPP verwendet die modulare QoS-Kommandozeilenschnittstelle (MQC) und die CPU-Warteschlangen, um diese Ziele zu erreichen. Unterschiedliche Typen von Steuerungsebenen-Datenverkehr werden anhand bestimmter Kriterien zusammengefasst und einer CPU-Warteschlange zugewiesen. Sie können diese CPU-Warteschlangen durch die Konfiguration dedizierter Richtlinien in der Hardware verwalten. Sie können beispielsweise die Policer-Rate für bestimmte CPU-Warteschlangen (Datenverkehrstyp) ändern oder die Policer für einen bestimmten Datenverkehrstyp deaktivieren.
Obwohl die Richtlinien in der Hardware konfiguriert sind, hat CoPP keine Auswirkungen auf die CPU-Leistung oder die Leistung der Datenebene. Da dies jedoch die Anzahl der Pakete begrenzt, die zur CPU geleitet werden, wird die CPU-Last gesteuert. Das bedeutet, dass für Services, die auf Pakete von der Hardware warten, eine kontrollierte Rate der eingehenden Pakete angezeigt wird (diese Rate kann vom Benutzer konfiguriert werden).
Problem
Ein Catalyst 9000-Switch wird als DHCP-Relay-Agent konfiguriert, wenn der Befehl ip helper-address auf einer gerouteten Schnittstelle oder SVI konfiguriert wird. Die Schnittstelle, auf der die Hilfsadresse konfiguriert wird, ist in der Regel das Standard-Gateway für Downstream-Clients. Damit der Switch seinen Clients erfolgreiche DHCP-Relay-Dienste bereitstellen kann, muss er in der Lage sein, eingehende DHCP Discover-Nachrichten zu verarbeiten. Dazu muss der Switch die DHCP-Erkennung empfangen und das Paket bis zur CPU durchsuchen, um verarbeitet zu werden. Sobald die DHCP Discover-Nachricht empfangen und verarbeitet wurde, erstellt der Relay-Agent ein neues Unicast-Paket, das von der Schnittstelle stammt, an der die DHCP Discover-Nachricht empfangen wurde, und an die IP-Adresse gerichtet ist, wie in der Konfiguration ip helper-address definiert. Nachdem das Paket erstellt wurde, wird es von der Hardware weitergeleitet und an den DHCP-Server gesendet, wo es verarbeitet und schließlich an den Relay-Agent zurückgesendet werden kann, sodass der DHCP-Prozess für den Client fortgesetzt werden kann.
Ein häufiges Problem tritt auf, wenn DHCP-Transaktionspakete am Relay-Agent versehentlich durch Datenverkehr beeinträchtigt werden, der an die CPU gesendet wird, da er einem bestimmten ICMP-Szenario unterliegt, z. B. einer ICMP-Umleitung oder einer ICMP-Meldung "Destination Unreachable" (Ziel nicht erreichbar). Dieses Verhalten kann sich dadurch manifestieren, dass Clients nicht in der Lage sind, eine IP-Adresse von DHCP rechtzeitig oder sogar einen vollständigen DHCP-Zuweisungsfehler zu erhalten. In einigen Szenarien kann das Verhalten nur zu bestimmten Tageszeiten beobachtet werden, z. B. zu Spitzenzeiten, wenn die Netzwerkauslastung vollständig maximiert ist.
Wie im Abschnitt "Hintergrund" erwähnt, ist für Catalyst Switches der Serie 9000 eine CoPP-Standardrichtlinie konfiguriert und aktiviert. Diese CoPP-Richtlinie fungiert als Quality of Service (QoS)-Richtlinie, die sich im Pfad des Datenverkehrs befindet, der an den Ports an der Vorderseite empfangen wird und für die Geräte-CPU bestimmt ist. Die Übertragungsrate begrenzt den Datenverkehr auf Basis des Datenverkehrstyps und der vordefinierten Grenzwerte, die in der Richtlinie konfiguriert werden. Einige Beispiele für standardmäßig klassifizierten und eingeschränkten Datenverkehr sind Routing-Control-Pakete (in der Regel mit DSCP CS6 markiert), Topology Control Packets (STP BPDUs) und Low Latency Packets (BFD). Diese Pakete müssen priorisiert werden, da ihre Verarbeitung zu einer stabilen Netzwerkumgebung führt.
Zeigen Sie die CoPP-Richtlinienstatistiken mit dem Befehl show platform hardware fed switch active qos queue stats internal cpu policer an.
Die ICMP-Umleitungswarteschlange (Warteschlange 6) und die BROADCAST-Warteschlange (Warteschlange 12) verwenden beide denselben PlcIdx von 0 (Policer-Index). Das bedeutet, dass der Broadcast-Datenverkehr, der von der Geräte-CPU verarbeitet werden muss, z. B. eine DHCP-Erkennung, für den Datenverkehr freigegeben wird, der auch an die Geräte-CPU in der ICMP-Umleitungswarteschlange gerichtet ist. Dies kann zu dem bereits erwähnten Problem führen, bei dem DHCP-Transaktionen fehlschlagen, da der Datenverkehr der ICMP-Umleitungswarteschlange den Datenverkehr verliert, der von der BROADCAST-Warteschlange verarbeitet werden muss, was dazu führt, dass legitime Broadcast-Pakete verworfen werden.
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 0 0 <-- Policer Index 0
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
9 19 EWLC Control Yes 13000 13000 0 0
10 16 EWLC Data Yes 2000 2000 0 0
11 13 L2 LVX Data Pack Yes 1000 1000 0 0
12 0 BROADCAST Yes 600 600 0 0 <-- Policer Index 0
13 10 Openflow Yes 200 200 0 0
14 13 Sw forwarding Yes 1000 1000 0 0
15 8 Topology Control Yes 13000 16000 0 0
16 12 Proto Snooping Yes 2000 2000 0 0
17 6 DHCP Snooping Yes 500 500 0 0
18 13 Transit Traffic Yes 1000 1000 0 0
19 10 RPF Failed Yes 250 250 0 0
20 15 MCAST END STATION Yes 2000 2000 0 0
<snip>
Datenverkehr, der die standardmäßige Paketrate von 600 pro Sekunde in der CoPP-Richtlinie überschreitet, wird verworfen, bevor er die CPU erreicht.
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 3063106173577 3925209161 <-- Dropped packets in queue
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
9 19 EWLC Control Yes 13000 13000 0 0
10 16 EWLC Data Yes 2000 2000 0 0
11 13 L2 LVX Data Pack Yes 1000 1000 0 0
12 0 BROADCAST Yes 600 600 1082560387 3133323 <-- Dropped packets in queue
13 10 Openflow Yes 200 200 0 0
14 13 Sw forwarding Yes 1000 1000 0 0
15 8 Topology Control Yes 13000 16000 0 0
16 12 Proto Snooping Yes 2000 2000 0 0
17 6 DHCP Snooping Yes 500 500 0 0
18 13 Transit Traffic Yes 1000 1000 0 0
19 10 RPF Failed Yes 250 250 0 0
20 15 MCAST END STATION Yes 2000 2000 0 0
<snip>
Szenario 1: ICMP-Umleitungen
Betrachten Sie diese Topologie für das erste Szenario:
Die Abfolge der Ereignisse ist wie folgt:
1. Ein Benutzer unter 10.10.10.100 initiiert eine Telnet-Verbindung mit Gerät 10.100.100.100, einem Remote-Netzwerk.
2. Die Ziel-IP-Adresse befindet sich in einem anderen Subnetz, sodass das Paket an das Standardgateway 10.10.10.15 des Benutzers gesendet wird.
3. Wenn der Catalyst 9300 dieses Paket zum Weiterleiten empfängt, sendet er es an seine CPU, um eine ICMP-Umleitung zu generieren.
Die ICMP-Umleitung wird generiert, da es aus Sicht des 9300-Switches für den Laptop effizienter wäre, dieses Paket einfach unter der Adresse 10.10.10.1 direkt an den Router zu senden, da dies sowieso der nächste Hop von Catalyst 9300 ist und sich in demselben VLAN befindet, in dem sich der Benutzer befindet.
Das Problem besteht darin, dass der gesamte Fluss an der CPU verarbeitet wird, da er die ICMP-Weiterleitungskriterien erfüllt. Wenn andere Geräte Datenverkehr senden, der das ICMP-Umleitungsszenario erfüllt, wird in dieser Warteschlange noch mehr Datenverkehr an die CPU gesendet, was sich auf die BROADCAST-Warteschlange auswirken kann, da sie die gleiche CoPP-Richtlinie verwenden.
Debuggen Sie ICMP, um das Syslog für die ICMP-Umleitung anzuzeigen.
9300-Switch#debug ip icmp <-- enables ICMP debugs
ICMP packet debugging is on
9300-Switch#show logging | inc ICMP
*Sep 29 12:41:33.217: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.218: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.219: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:41:33.219: ICMP: echo reply sent, src 10.10.10.15, dst 10.10.10.100, topology BASE, dscp 0 topoid 0
*Sep 29 12:43:08.127: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:09.517: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:10.017: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1 <-- ICMP Redirect to use 10.10.10.1 as Gateway
*Sep 29 12:50:14.293: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:19.053: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:23.797: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:28.537: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
*Sep 29 12:50:33.284: ICMP: redirect sent to 10.10.10.100 for dest 10.100.100.100, use gw 10.10.10.1
Eine Embedded Packet Capture auf der CPU der Catalyst Serie 9300 zeigt das anfängliche TCP SYN für die Telnet-Verbindung auf der CPU sowie die generierte ICMP-Umleitung.
Das ICMP-Umleitungspaket stammt von der für den Client bestimmten Catalyst 9300 VLAN 10-Schnittstelle und enthält die ursprünglichen Paket-Header, für die das ICMP-Umleitungspaket gesendet wird.
Lösung
In diesem Szenario können die Pakete, die bis zur CPU durchgelockt werden, verhindert werden, wodurch auch die Generierung des ICMP-Umleitungspakets gestoppt wird.
Moderne Betriebssysteme verwenden keine ICMP-Umleitungsnachrichten, sodass die Ressourcen, die zum Generieren und Senden und Verarbeiten dieser Pakete erforderlich sind, keine effiziente Nutzung von CPU-Ressourcen auf Netzwerkgeräten darstellen.
Sie können auch den Benutzer auffordern, das Standard-Gateway 10.10.10.1 zu verwenden. Eine solche Konfiguration kann jedoch aus einem bestimmten Grund erfolgen und ist nicht Bestandteil des vorliegenden Dokuments.
Deaktivieren Sie ICMP-Umleitungen einfach über die CLI no ip redirects.
9300-Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip redirects <-- disable IP redirects
9300-Switch(config-if)#end
Stellen Sie sicher, dass die ICMP-Umleitungen auf einer Schnittstelle deaktiviert sind.
9300-Switch#show ip interface vlan 10
Vlan10 is up, line protocol is up
Internet address is 10.10.10.15/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.102
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is BLOCK-TELNET
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are never sent <-- redirects disabled
ICMP unreachables are never sent
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
<snip>
Weitere Informationen zu ICMP-Umleitungen und dem Zeitpunkt ihres Versands finden Sie unter folgendem Link: https://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13714-43.html
Szenario 2: ICMP nicht erreichbar
Stellen Sie sich dieselbe Topologie vor, in der der Benutzer unter 10.10.10.100 eine Telnet-Verbindung mit 10.100.100.100 initiiert. Diesmal wurde eine eingehende Zugriffsliste für die VLAN 10-SVI konfiguriert, die Telnet-Verbindungen blockiert.
9300-Switch#show running-config interface vlan 10
Building Configuration..
Current Configuration : 491 bytes
!
interface Vlan10
ip address 10.10.10.15 255.255.255.0
no ip proxy-arp
ip access-group BLOCK-TELNET in <-- inbound ACL
end
9300-Switch#
9300-Switch#show ip access-list BLOCK-TELNET
Extended IP access list BLOCK-TELNET
10 deny tcp any any eq telnet <-- block telnet
20 permit ip any any
9300-Switch#
Die Abfolge der Ereignisse ist wie folgt:
1. Der Benutzer unter 10.10.10.100 initiiert eine Telnet-Verbindung mit Gerät 10.100.100.100.
2. Die Ziel-IP-Adresse befindet sich in einem anderen Subnetz, sodass das Paket an das Standard-Gateway des Benutzers gesendet wird.
3. Wenn der Catalyst 9300 dieses Paket empfängt, wird es anhand der eingehenden ACL ausgewertet und blockiert.
4. Da das Paket blockiert ist und IP Unreachables auf der Schnittstelle aktiviert sind, wird das Paket an die CPU gesendet, sodass das Gerät ein nicht erreichbares ICMP-Zielpaket generieren kann.
Debuggen Sie ICMP, um das nicht erreichbare ICMP-Ziel-Syslog anzuzeigen.
9300-Switch#debug ip icmp <-- enables ICMP debugs
ICMP packet debugging is on
9300-Switch#show logging | include ICMP
<snip>
*Sep 29 14:01:29.041: ICMP: dst (10.100.100.100) administratively prohibited unreachable sent to 10.10.10.100 <-- packet blocked and ICMP message sent to client
Eine Embedded Packet Capture auf der CPU der Catalyst Serie 9300 zeigt das anfängliche TCP SYN für die Telnet-Verbindung auf der CPU sowie das gesendete ICMP Destination Unreachable.
Das Paket "ICMP Destination Unreachable" stammt von der für den Client bestimmten Catalyst 9300 VLAN 10-Schnittstelle und enthält die ursprünglichen Paket-Header, für die das ICMP-Paket gesendet wird.
Lösung
Deaktivieren Sie in diesem Szenario das Verhalten, bei dem blockierte Pakete durch eine ACL blockiert werden, um die Meldung "ICMP Destination Unreachable" (ICMP-Ziel nicht erreichbar) zu generieren.
Die Funktion "IP Unreachable" ist auf gerouteten Schnittstellen der Catalyst Switches der Serie 9000 standardmäßig aktiviert.
9300-Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip unreachables <-- disable IP unreachables
Stellen Sie sicher, dass sie für die Schnittstelle deaktiviert sind.
9300-Switch#show ip interface vlan 10
Vlan10 is up, line protocol is up
Internet address is 10.10.10.15/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.102
Outgoing Common access list is not set
Outgoing access list is not set
Inbound Common access list is not set
Inbound access list is BLOCK-TELNET
Proxy ARP is disabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are never sent
ICMP unreachables are never sent <-- IP unreachables disabled
ICMP mask replies are never sent
IP fast switching is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
<snip>
Szenario 3: ICMP-TTL überschritten
Berücksichtigen Sie die Topologie, die zuvor für die beiden vorherigen Szenarien verwendet wurde. Diesmal versucht der Benutzer unter 10.10.10.100, eine Ressource in einem Netzwerk zu erreichen, das seit der Außerbetriebnahme beendet wurde. Aus diesem Grund sind die SVI und das VLAN, die zum Hosten dieses Netzwerks verwendet wurden, auf dem Catalyst 9300 nicht mehr vorhanden. Der Router verfügt jedoch weiterhin über eine statische Route, die als nächster Hop für dieses Netzwerk auf die Catalyst 9300 VLAN 10-Schnittstelle verweist.
Da dieses Netzwerk für den Catalyst 9300 nicht mehr konfiguriert ist, wird es nicht als direkt verbunden angezeigt, und der Catalyst 9300 leitet Pakete, für die er keine spezifische Route für besitzt, an seine statische Standardroute weiter, die unter 10.10.10.1 auf den Router verweist.
Dieses Verhalten führt zu einer Routing-Schleife im Netzwerk, wenn der Benutzer versucht, eine Verbindung zu einer Ressource im Adressbereich 192.168.10.0/24 herzustellen. Das Paket wird zwischen dem Router der Serie 9300 und dem Router in Schleifen übertragen, bis die TTL abläuft.
1. Der Benutzer versucht, eine Verbindung zu einer Ressource im Netzwerk 192.168.10/24 herzustellen.
2. Das Paket wird von Catalyst 9300 empfangen und mit dem nächsten Hop 10.10.10.1 auf die Standardroute geroutet, und der TTL wird um 1 herabgesetzt.
3. Der Router empfängt dieses Paket und überprüft die Routing-Tabelle, um eine Route für dieses Netzwerk mit dem nächsten Hop 10.10.10.15 zu finden. Er setzt den TTL um 1 herab und leitet das Paket zurück an den 9300.
4. Catalyst 9300 empfängt das Paket und leitet es erneut an 10.10.10.1 zurück. Die TTL wird um 1 herabgesetzt.
Dieser Prozess wird wiederholt, bis die IP-TTL den Wert 0 erreicht.
Wenn der Catalyst das Paket mit der IP TTL = 1 empfängt, sendet er das Paket an die CPU und generiert eine ICMP-Meldung über eine Überschreitung der TTL.
Der ICMP-Pakettyp ist 11 mit Code 0 (bei der Übertragung ist die TTL abgelaufen). Dieser Pakettyp kann nicht über CLI-Befehle deaktiviert werden.
Das Problem mit dem DHCP-Datenverkehr kommt in diesem Szenario ins Spiel, da die Pakete, die in Loops zusammengefasst werden, der ICMP-Umleitung unterliegen, da sie dieselbe Schnittstelle auslassen, auf der sie empfangen wurden.
Die vom Benutzer gesendeten Pakete unterliegen ebenfalls der ICMP-Umleitung. In diesem Szenario kann der DHCP-Datenverkehr aus der BROADCAST-Warteschlange entfernt werden. Bei einer Skalierung wäre dieses Szenario aufgrund der Anzahl der Pakete, die in die Umleitungswarteschlange gestellt werden, noch schlimmer.
Hier werden CoPP-Drops durch 1000 Pings zum Netzwerk 192.168.10.0/24 mit einer Zeitüberschreitung von 0 Sekunden zwischen jedem Ping demonstriert. Die CoPP-Statistiken auf dem 9300 werden gelöscht und bei null Byte verworfen, bevor die Pings gesendet werden.
9300-Switch#clear platform hardware fed switch active qos statistics internal cpu policer <-- clear CoPP stats
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer | i Redirect|Drop <-- verify 0 drops
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
6 0 ICMP Redirect Yes 600 600 0 0 <-- bytes dropped 0
<snip>
Benutzer sendet Datenverkehr an entferntes Netzwerk.
User#ping 192.168.10.10 timeout 0 rep 1000 <-- User sends 1000 pings
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 192.168.10.10, timeout is 0 seconds:
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
....................
Success rate is 0 percent (0/1000)
Die ICMP-Debugs zeigen die durch die Routing-Schleife bedingten Redirect-Syslogs und TTL-Exceeded-Syslogs.
9300-Switch#debug ip icmp
ICMP packet deubgging is on
*Sep 29 16:33:22.676: ICMP: redirect sent to 10.10.10.100 for dest 192.168.10.10, use gw 10.10.10.1 <-- redirect sent
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0 <-- TTL exceeded observed
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0
*Sep 29 16:33:22.678: ICMP: time exceeded (time to live) sent to 10.10.10.100 (dest was 192.168.10.10), topology BASE, dscp 0 topoid 0
<snip>
CoPP-Drops werden aufgrund des Datenverkehrs erkannt, der zur Umleitung an die CPU geleitet wird. Beachten Sie, dass dies nur für einen einzelnen Client gilt.
9300-Switch#show platform hardware fed switch active qos queue stats internal cpu policer
CPU Queue Statistics
============================================================================================
(default) (set) Queue Queue
QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) Drop(Frames)
--------------------------------------------------------------------------------------------
0 11 DOT1X Auth Yes 1000 1000 0 0
1 1 L2 Control Yes 2000 2000 0 0
2 14 Forus traffic Yes 4000 4000 0 0
3 0 ICMP GEN Yes 600 600 0 0
4 2 Routing Control Yes 5400 5400 0 0
5 14 Forus Address resolution Yes 4000 4000 0 0
6 0 ICMP Redirect Yes 600 600 15407990 126295 <-- drops in redirect queue
7 16 Inter FED Traffic Yes 2000 2000 0 0
8 4 L2 LVX Cont Pack Yes 1000 1000 0 0
<snip>
Lösung
Die Lösung in diesem Szenario ist die Deaktivierung von ICMP-Umleitungen, wie in Szenario 1. Die Routing-Schleife ist ebenfalls ein Problem, die Intensität wird jedoch noch erhöht, da die Pakete auch für die Umleitung analysiert werden.
ICMP-Pakete mit TTL-Überschreitung werden auch bei einem TTL-Wert von 1 gesendet. Diese Pakete verwenden jedoch einen anderen CoPP Policer-Index und verwenden keine Warteschlange für BROADCAST, sodass der DHCP-Datenverkehr nicht beeinträchtigt wird.
Deaktivieren Sie die ICMP-Umleitungen über die CLI no ip redirects.
9300-Switch#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
9300-Switch(config)#interface vlan 10
9300-Switch(config-if)#no ip redirects <-- disable IP redirects
9300-Switch(config-if)#end
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
20-Oct-2023 |
Rezertifizierung |
1.0 |
30-Sep-2021 |
Erstveröffentlichung |
Feedback