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 wird die ICMP-Funktion (Internet Control Message Protocol) zur Paketumleitung beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
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.
In diesem Dokument wird die Paketumleitungsfunktion erläutert, die vom Internet Control Message Protocol (ICMP) bereitgestellt wird. In diesem Dokument wird erläutert, was das Vorhandensein von ICMP-Umleitungsnachrichten im Netzwerk normalerweise bedeutet und was getan werden kann, um die negativen Nebenwirkungen zu minimieren, die mit Netzwerkbedingungen verbunden sind und die Erzeugung von ICMP-Umleitungsnachrichten verursachen.
Die ICMP-Umleitungsfunktion wird in RFC 792 Internet Control Message Protocol anhand des folgenden Beispiels erläutert:
Das Gateway sendet in dieser Situation eine Umleitungsnachricht an einen Host.
Ein Gateway, G1, empfängt ein Internetdatagramm von einem Host in einem Netzwerk, an das das Gateway angeschlossen ist. Das Gateway G1 überprüft seine Routing-Tabelle und erhält die Adresse des nächsten Gateways G2 auf der Route zum Datagramm-Internet-Zielnetzwerk X
Befinden sich G2 und der durch die Internet-Quelladresse des Datagramms identifizierte Host im gleichen Netzwerk, wird eine Umleitungsnachricht an den Host gesendet. Die Umleitungsnachricht rät dem Host, seinen Datenverkehr für das Netzwerk X direkt an das Gateway G2 zu senden, da dies ein kürzerer Pfad zum Ziel ist.
Das Gateway leitet die ursprünglichen Datagrammdaten an sein Internetziel weiter.
Dieses Szenario ist in Abbildung 1 dargestellt. Host und zwei Router, G1 und G2, sind mit einem gemeinsam genutzten Ethernet-Segment verbunden und haben IP-Adressen im gleichen Netzwerk 10.0.0.0/24
Image1 - ICMP-Umleitungen in Multipoint-Ethernet-Netzwerken
Host hat die IP-Adresse 10.0.0.100. Die Host-Routing-Tabelle enthält einen Standard-Routing-Eintrag, der auf die IP-Adresse 10.0.0.1 des Routers G1 als Standard-Gateway verweist. Router G1 verwendet die IP-Adresse 10.0.0.2 des Routers G2 als nächsten Hop, wenn Datenverkehr an das Zielnetzwerk X weitergeleitet wird.
Dies geschieht, wenn der Host ein Paket an das Zielnetzwerk X sendet:
1. Gateway G1 mit der IP-Adresse 10.0.0.1 empfängt ein Datenpaket vom Host 10.0.0.100 in einem Netzwerk, mit dem es verbunden ist.
2. Das Gateway G1 überprüft seine Routing-Tabelle und erhält die IP-Adresse 10.0.0.2 des nächsten Gateways G2 auf der Route zum Datenpaket-Zielnetzwerk X.
3. Wenn sich G2 und der durch die Quelladresse des IP-Pakets identifizierte Host im gleichen Netzwerk befinden, wird eine ICMP-Umleitungsnachricht an den Host gesendet. Die ICMP-Umleitungsmeldung rät dem Host, seinen Datenverkehr für Netzwerk X direkt an Gateway G2 zu senden, da dies ein kürzerer Pfad zum Ziel ist.
4. Das Gateway G1 leitet das ursprüngliche Datenpaket an sein Ziel weiter.
Abhängig von der Host-Konfiguration kann er entscheiden, ob ICMP-Umleitungsnachrichten ignoriert werden sollen, die von G1 an ihn gesendet werden. Wenn der Host jedoch ICMP-Umleitungsnachrichten verwendet, um seinen Routing-Cache anzupassen, und anfängt, nachfolgende Datenpakete direkt an G2 zu senden, werden diese Vorteile in diesem Szenario erreicht
Image 2 - Next Hop G2 im Host-Routing-Cache installiert
Wie in Abbildung 2 gezeigt, werden die folgenden Vorteile im Netzwerk sichtbar, nachdem der Host einen Routen-Cache-Eintrag für Netzwerk X mit G2 als nächstem Hop erstellt hat:
Um die Bedeutung des ICMP-Umleitungsmechanismus zu verstehen, sollten Sie bedenken, dass bei den ersten Internet-Router-Implementierungen für die Verarbeitung des Datenverkehrs in erster Linie CPU-Ressourcen erforderlich waren. Daher war es wünschenswert, das Datenverkehrsvolumen, das von einem einzelnen Router verarbeitet werden musste, zu reduzieren und auch die Anzahl der Router-Hops, die ein bestimmter Datenverkehrsfluss auf dem Weg zum Ziel durchlaufen musste, zu minimieren. Gleichzeitig wurde die Layer-2-Weiterleitung (auch als Switching bezeichnet) hauptsächlich in angepassten ASICs (Application-Specific Integrated Circuits) implementiert und war in Bezug auf die Weiterleitungsleistung im Vergleich zur Layer-3-Weiterleitung (auch als Routing bezeichnet) relativ kostengünstig, was wiederum in universellen Prozessoren erfolgte.
Neuere ASIC-Generationen können Pakete auf Layer 2 und Layer 3 weiterleiten. Die hardwarebasierte Layer-3-Tabellensuche trägt dazu bei, die mit der Paketverarbeitung durch die Router verbundenen Leistungskosten zu senken. Darüber hinaus wurde durch die Integration der Layer-3-Weiterleitungsfunktion in Layer-2-Switches (die jetzt als Layer-3-Switches bezeichnet werden) die Paketweiterleitung effizienter. Dadurch waren keine Designoptionen für einarmige Router (auch als "Router on a Stick" bekannt) erforderlich, und die mit solchen Netzwerkkonfigurationen verbundenen Einschränkungen wurden vermieden.
Image 3 basiert auf dem Szenario in Image 1. Layer-2- und Layer-3-Funktionen, die ursprünglich von zwei separaten Knoten, dem Switch und dem Router G1, bereitgestellt wurden, werden nun in einem einzigen Layer-3-Switch konsolidiert, z. B. einer Plattform der Serie Nexus 7000.
Image 3 - Layer-3-Switch ersetzt einarmige Router-Konfiguration
Dies geschieht, wenn der Host ein Paket an das Ziel Netzwerk X sendet:
1. Gateway-L3-Switch mit IP-Adresse 10.0.0.1 empfängt Datenpaket von einem Host 10.0.0.100 in einem Netzwerk, mit dem er verbunden ist.
2. Das Gateway, L3 Switch, überprüft seine Routing-Tabelle und erhält die Adresse 10.0.0.2 des nächsten Gateways G2 auf der Route zum Datenpaket-Zielnetzwerk X.
3. Wenn sich G2 und der durch die Quelladresse des IP-Pakets identifizierte Host im gleichen Netzwerk befinden, wird eine ICMP-Umleitungsnachricht an den Host gesendet. Die ICMP-Umleitungsmeldung rät dem Host, seinen Datenverkehr für Netzwerk X direkt an Gateway G2 zu senden, da dies ein kürzerer Pfad zum Ziel ist.
4. Das Gateway leitet das ursprüngliche Datenpaket an sein Ziel weiter.
Da Layer-3-Switches nun sowohl Layer-2- als auch Layer-3-Paketweiterleitung auf ASIC-Ebene durchführen können, kann geschlossen werden, dass die ICMP-Umleitungsfunktion beide Vorteile bietet. Zum einen wird eine verbesserte Verzögerung durch das Netzwerk erreicht, zum anderen wird eine Reduzierung der Netzwerkressourcennutzung erreicht, und es besteht keine Notwendigkeit mehr, den Techniken der Pfadoptimierung in Mehrpunkt-Ethernet-Segmenten viel Aufmerksamkeit zu schenken.
Bei Aktivierung der ICMP-Umleitungsfunktion an Layer-3-Schnittstellen besteht bei einer suboptimalen Weiterleitung über Multipoint-Ethernet-Segmente jedoch weiterhin ein potenzieller Leistungsengpass, auch wenn dies aus einem anderen Grund geschieht (siehe Abschnitt "Überlegungen zur Nexus-Plattform" weiter unten in diesem Dokument).
Hinweis: ICMP-Umleitungen sind auf Layer-3-Schnittstellen der Cisco IOS®- und Cisco NX-OS-Software standardmäßig aktiviert.
Hinweis: Zusammenfassung der Bedingungen, unter denen ICMP-Umleitungsnachrichten generiert werden: Der Layer-3-Switch generiert die ICMP-Umleitungsnachricht zurück an die Quelle des Datenpakets, wenn das Datenpaket von der Layer-3-Schnittstelle, auf der dieses Paket empfangen wird, weitergeleitet werden soll.
Interior Gateway Protocols (IGP), wie Open Shortest Path First (OSPF) und Cisco Enhanced Interior Gateway Routing Protocol (EIGRP), wurden entwickelt, um Routing-Informationen zwischen Routern zu synchronisieren und ein konsistentes und vorhersehbares Paketweiterleitungsverhalten auf allen Netzwerkknoten bereitzustellen, die diese Informationen berücksichtigen. Wenn beispielsweise bei Multipoint-Ethernet-Netzwerken alle Layer-3-Knoten in einem Segment die gleichen Routing-Informationen verwenden und sich auf den gleichen Ausgangspunkt zum Ziel einigen, ist eine suboptimale Weiterleitung über solche Netzwerke selten der Fall.
Um zu verstehen, was suboptimale Weiterleitungspfade verursacht, sollten Sie bedenken, dass Layer-3-Knoten die Entscheidungen zur Paketweiterleitung unabhängig voneinander treffen. Die von Router B getroffene Entscheidung über die Paketweiterleitung hängt also nicht von der Entscheidung über die Paketweiterleitung ab, die von Router A getroffen wurde. Dies ist eines der wichtigsten Prinzipien, das Sie bei der Fehlerbehebung für die Paketweiterleitung über IP-Netzwerke berücksichtigen müssen. Es ist wichtig, dass Sie dieses beachten, wenn Sie den suboptimalen Weiterleitungspfad in Mehrpunkt-Ethernet-Netzwerken untersuchen.
Wie bereits erwähnt, darf es in Netzwerken, in denen alle Router für die Bereitstellung des Datenverkehrs zwischen Endpunkten auf ein einziges dynamisches Routing-Protokoll angewiesen sind, nicht zu einer suboptimalen Weiterleitung über Mehrpunkt-Ethernet-Segmente kommen. In realen Netzwerken ist es jedoch sehr üblich, eine Kombination verschiedener Paketweiterleitungs- und -weiterleitungsmechanismen zu finden. Beispiele für solche Mechanismen sind verschiedene IGPs, statisches Routing und richtlinienbasiertes Routing. Diese Funktionen werden in der Regel gemeinsam verwendet, um die gewünschte Weiterleitung des Datenverkehrs durch das Netzwerk zu erreichen.
Die kombinierte Verwendung dieser Mechanismen kann zwar dazu beitragen, den Datenverkehrsfluss zu optimieren und die Anforderungen eines bestimmten Netzwerkdesigns zu erfüllen, sie übersehen jedoch die Nebenwirkungen, die diese Tools zusammen in Mehrpunkt-Ethernet-Netzwerken verursachen können und die zu einer schlechten Netzwerkleistung führen können.
Um dies zu veranschaulichen, betrachten Sie das Szenario in Bild 4. Router A hat eine statische Route zu Netzwerk X mit Router B als Next-Hop. Gleichzeitig verwendet Router B Router C als Next-Hop auf statischer Route zu Netzwerk X.
Abbildung 4: Suboptimaler Pfad mit statischem Routing
Während der Datenverkehr über Router A in dieses Netzwerk eintritt, es über Router C verlässt und schließlich an das Zielnetzwerk X weitergeleitet wird, müssen Pakete dieses IP-Netzwerk zweimal durchlaufen, um an das Ziel zu gelangen. Dies ist keine effiziente Nutzung von Netzwerkressourcen. Stattdessen würde das direkte Senden von Paketen von Router A an Router C zu denselben Ergebnissen führen, während weniger Netzwerkressourcen benötigt würden.
Hinweis: Obwohl in diesem Szenario Router A und Router C als Eingangs- und Ausgangs-Layer-3-Knoten für dieses IP-Netzwerksegment verwendet werden, können beide Knoten durch Netzwerkgeräte (z. B. Load Balancer oder Firewalls) ersetzt werden, wenn diese eine Routing-Konfiguration aufweisen, die zu demselben Paketweiterleitungsverhalten führt.
Policy Based Routing (PBR) ist ein weiterer Mechanismus, der zu suboptimalen Pfaden durch Ethernet-Netzwerke führen kann. Im Gegensatz zu statischem oder dynamischem Routing funktioniert PBR jedoch nicht auf Ebene der Routing-Tabelle. Stattdessen programmiert es die Zugriffskontrollliste (ACL) für die Datenverkehrsumleitung direkt in der Switch-Hardware. Bei ausgewählten Datenverkehrsflüssen umgeht die Paketweiterleitungssuche auf der Eingangs-Linecard daher Routinginformationen, die über statisches oder dynamisches Routing abgerufen werden.
In Image 4 tauschen Router A und B Routing-Informationen über das Zielnetzwerk X mit einem der dynamischen Routing-Protokolle aus. Beide stimmen darin überein, dass Router B der beste Next-Hop für dieses Netzwerk ist.
Bei einer PBR-Konfiguration auf Router B, die die vom Routing-Protokoll empfangenen Routing-Informationen überschreibt und Router C als nächsten Hop zu Netzwerk X festlegt, ist die Bedingung zum Auslösen der ICMP-Umleitungsfunktion erfüllt, und das Paket wird zur weiteren Verarbeitung an die CPU von Router B gesendet.
Bisher bezog sich dieses Dokument auf Ethernet-Netzwerke mit drei (oder mehr) verbundenen Layer-3-Knoten, daher der Name "Multipoint Ethernet Networks". Beachten Sie jedoch, dass ICMP-Umleitungsnachrichten auch auf Punkt-zu-Punkt-Ethernet-Verbindungen generiert werden können.
Betrachten Sie das Szenario auf Bild 5. Router A sendet Datenverkehr über eine statische Standardroute an Router B, während Router B über eine statische Route zu Netzwerk X verfügt, die auf Router A verweist.
Bild 5 - ICMP-Weiterleitung bei Point-to-Point-Links
Diese Designoption, die auch als Single-Homed-Verbindung bezeichnet wird, ist eine beliebte Option, wenn Sie kleine Benutzerumgebungen mit Service Provider-Netzwerken verbinden. Router B ist ein Provider Edge (PE)-Gerät, und Router A ist ein User Edge (CE)-Gerät.
Beachten Sie, dass die typische CE-Konfiguration aggregierte statische Routen zu Benutzer-IP-Adressblöcken umfasst, die auf die Null0-Schnittstelle verweisen. Diese Konfiguration ist eine empfohlene Best Practice für die Option mit Single-Homed-CE-PE-Verbindungen mit statischem Routing. Im Rahmen dieses Beispiels wird jedoch davon ausgegangen, dass eine solche Konfiguration nicht vorhanden ist.
Angenommen, Router A verliert die Verbindung zu Netzwerk X, wie im Bild gezeigt. Wenn Pakete vom Benutzer-Netzwerk Y oder Remote-Netzwerk Z versuchen, Netzwerk X zu erreichen, können die Router A und B den Datenverkehr zwischen den Paketen zurückwerfen und das IP-Time-To-Live-Feld in jedem Paket so lange verringern, bis sein Wert 1 erreicht, sodass kein weiteres Routing des Pakets möglich ist.
Während der Datenverkehr zu Netzwerk X zwischen PE- und CE-Routern hin- und herfließt, erhöht sich die Bandbreitennutzung der CE-PE-Verbindungen drastisch (und unnötig). Das Problem verschärft sich noch, wenn ICMP-Umleitungen auf einer oder beiden Seiten der Punkt-zu-Punkt-PE-CE-Verbindung aktiviert sind. In diesem Fall wird jedes Paket im an Netzwerk X gerichteten Fluss auf jedem Router mehrmals in der CPU verarbeitet, um die ICMP-Umleitungsnachrichten zu generieren.
Wenn die ICMP-Umleitung an der Layer-3-Schnittstelle aktiviert ist und ein eingehendes Datenpaket diese Schnittstelle sowohl für den Eingang als auch für den Ausgang eines Layer-3-Switches verwendet, wird eine ICMP-Umleitungsmeldung generiert. Während die Layer-3-Paketweiterleitung in der Hardware der Cisco Nexus 7000-Plattform erfolgt, ist die Switch-CPU weiterhin für die Erstellung der ICMP-Umleitungsnachrichten zuständig. Zu diesem Zweck muss die CPU auf dem Nexus 7000-Supervisor-Modul IP-Adressinformationen des Datenflusses abrufen, dessen Pfad durch das Netzwerksegment optimiert werden kann. Aus diesem Grund werden Datenpakete von der Eingangs-Linecard an das Supervisor-Modul gesendet.
Wenn Empfänger der ICMP-Umleitungsnachricht diese ignorieren und den Datenverkehr weiterhin an die Layer-3-Schnittstelle des Nexus-Switches weiterleiten, auf der ICMP-Umleitungen aktiviert sind, wird der ICMP-Umleitungsgenerierungsprozess für jedes Datenpaket ausgelöst.
Auf Linecard-Ebene beginnt der Prozess mit einer Ausnahme für die Hardware-Weiterleitung. Auf ASICs werden Ausnahmen ausgelöst, wenn der Paketweiterleitungsvorgang vom Linecard-Modul nicht erfolgreich abgeschlossen werden kann. In diesem Fall müssen Datenpakete zur korrekten Paketbehandlung an das Supervisor-Modul gesendet werden.
Hinweis: Die CPU des Supervisor-Moduls generiert nicht nur ICMP-Umleitungsnachrichten, sondern verarbeitet auch viele andere Ausnahmen für die Paketweiterleitung, z. B. IP-Pakete mit einem TTL-Wert (Time To Live) von 1 oder IP-Pakete, die fragmentiert werden müssen, bevor sie an den nächsten Hop gesendet werden.
Nachdem die CPU des Supervisor-Moduls eine ICMP-Umleitungsnachricht an die Quelle gesendet hat, wird die Ausnahmebehandlung abgeschlossen, indem das Datenpaket über das Ausgangs-Linecard-Modul an den nächsten Hop weitergeleitet wird.
Während die Nexus 7000 Supervisor-Module leistungsstarke CPU-Prozessoren verwenden, die große Datenmengen verarbeiten können, ist die Plattform so konzipiert, dass sie den Großteil des Datenverkehrs auf Linecard-Ebene verarbeiten kann, ohne den Supervisor-CPU-Prozessor in den Paketweiterleitungsprozess einbeziehen zu müssen. Auf diese Weise kann sich die CPU auf ihre Kernaufgaben konzentrieren, und der Paketweiterleitungsbetrieb bleibt für dedizierte Hardware-Engines auf den Linecards verfügbar.
In stabilen Netzwerken ist davon auszugehen, dass Ausnahmen für die Paketweiterleitung, sofern sie auftreten, mit relativ niedrigen Raten erfolgen. Unter dieser Annahme können sie von der Supervisor-CPU verarbeitet werden, ohne dass die Leistung wesentlich beeinträchtigt wird. Andererseits können sich bei einer CPU, die mit der Paketweiterleitung befasst ist, Ausnahmen, die mit einer sehr hohen Rate auftreten, negativ auf die Stabilität und Reaktionsfähigkeit des Gesamtsystems auswirken.
Das Design der Nexus 7000-Plattform bietet eine Reihe von Mechanismen zum Schutz der Switch-CPU vor umfangreichen Datenverkehrsmengen. Diese Mechanismen werden an verschiedenen Stellen im System implementiert. Auf Line Card-Ebene gibt es Hardware-Ratenlimitierungen und die Kontrollebene Policing
(CoPP). Beide legen Grenzwerte für die Datenverkehrsrate fest, die die Menge des Datenverkehrs steuern, der von jedem Linecard-Modul an den Supervisor weitergeleitet wird.
Diese Schutzmechanismen bevorzugen den Datenverkehr verschiedener Steuerungsprotokolle, die für die Netzwerkstabilität und die Switch-Verwaltbarkeit von entscheidender Bedeutung sind, wie OSPF, BGP oder SSH, und filtern gleichzeitig aggressiv Datenverkehrstypen, die für die Funktionalität der Kontrollebene des Switches nicht kritisch sind. Der Großteil des Datenverkehrs, der aufgrund von Ausnahmen bei der Paketweiterleitung an die CPU weitergeleitet wird, wird durch solche Mechanismen streng geregelt.
Während Hardware-Ratenlimitierungen und CoPP policing
Mechanismen sorgen für die Stabilität der Kontrollebene des Switches und sollten unbedingt immer aktiviert sein. Dies kann einer der Hauptgründe für Datenpaketverluste, Übertragungsverzögerungen und eine insgesamt schlechte Anwendungsleistung im Netzwerk sein. Aus diesem Grund ist es wichtig, die Pfade zu kennen, über die der Datenverkehr das Netzwerk durchläuft, sowie die Verwendung von Tools zur Überwachung der Netzwerkgeräte, die die ICMP-Umleitungsfunktion nutzen können bzw. sollten.
Sowohl Cisco IOS als auch die Cisco NX-OS Software bieten eine Möglichkeit, Statistiken des von der CPU verarbeiteten Datenverkehrs zu überprüfen. Dies wird mit show ip traffic
aus. Dieser Befehl kann verwendet werden, um den Empfang und/oder die Generierung von ICMP-Umleitungsnachrichten durch einen Switch oder Router auf Layer 3 zu überprüfen.
Nexus7000#show ip traffic | begin ICMP
ICMP Software Processed Traffic Statistics
------------------------------------------
Transmission:
Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
ICMP originate Req: 0, Redirects Originate Req: 1000
Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0
Reception:
Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,
<output omitted for brevity>
Nexus7000#
Ausgeführt show ip traffic
einige Male und überprüfen, ob die Zähler für die ICMP-Umleitung inkrementiert werden.
Die Cisco NX-OS Software verfügt über ein integriertes Tool zur Erfassung des Datenverkehrs flowing
zwischen Switch-CPUs (auch als Ethanalyzer bekannt).
Hinweis: Weitere Informationen zu Ethanalyzer finden Sie im Ethanalyzer auf Nexus 7000 Troubleshooting Guide.
Abbildung 6 zeigt ein Szenario, das dem auf Abbildung 3 ähnelt. Hier wird Netzwerk X durch das Netzwerk 192.168.0.0/24 ersetzt.
Bild 6: Ethanalyzer-Erfassung durchführen
Der Host 10.0.0.100 sendet einen kontinuierlichen Strom von ICMP-Echoanfragen an die Ziel-IP-Adresse 192.168.0.1. Der Host verwendet die Switch Virtual Interface (SVI) 10 des Nexus 7000 als nächsten Hop zum Remote-Netzwerk 192.168.0.0/24. Zu Demonstrationszwecken ist der Host so konfiguriert, dass er ICMP-Umleitungsnachrichten ignoriert.
Mit diesem nächsten Befehl können Sie den von der Nexus 7000 CPU empfangenen und gesendeten ICMP-Datenverkehr erfassen:
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 Capturing on inband 2018-09-15 23:45:40.124077 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.124477 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.124533 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.126344 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.126607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.126655 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.130362 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.130621 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.130669 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.132392 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.132652 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.132700 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.134347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.134612 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.134660 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.136347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.136598 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.136645 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.138351 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23:45:40.138607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23:45:40.138656 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request
...
Zeitstempel in der vorherigen Ausgabe weisen darauf hin, dass drei Pakete, die in diesem Beispiel hervorgehoben wurden, gleichzeitig erfasst wurden, 2018-09-15 23:45:40.128. Der nächste Schritt ist eine Paketaufschlüsselung dieser Paketgruppe
2018-09-15 23:45:40.128348 10.0.0.100 -> 192.168.0.1 ICMP-Echo (Ping)-Anfrage
2018-09-15 23:45:40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host)
2018-09-15 23:45:40.128659 10.0.0.100 -> 192.168.0.1 ICMP-Echo (Ping)-Anfrage
Während Sie durch große Ethianalyzer-Aufnahmen navigieren, die viele Pakete unterschiedlicher Art und Ströme enthalten, kann es schwierig sein, ICMP-Umleitungsnachrichten mit dem Datenverkehr zu korrelieren, der ihnen entspricht.
Konzentrieren Sie sich in diesen Fällen auf ICMP-Umleitungsnachrichten, um Informationen über nicht optimal weitergeleitete Datenverkehrsflüsse abzurufen. ICMP-Umleitungsnachrichten umfassen den Internet-Header plus die ersten 64 Bit der ursprünglichen Datagrammdaten. Diese Daten werden von der Quelle des Datagramms verwendet, um die Nachricht dem entsprechenden Prozess zuzuordnen.
Verwenden Sie das Paket-Erfassungstool Ethanalyzer mit einem detaillierten Schlüsselwort, um den Inhalt von ICMP-Umleitungsnachrichten anzuzeigen und nach IP-Adressinformationen des Datenflusses zu suchen, die nicht optimal weitergeleitet werden.
Nexus7000#ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail
...
Frame 2 (70 bytes on wire, 70 bytes captured)
Arrival Time: Sep 15, 2018 23:54:04.388577000
[Time delta from previous captured frame: 0.000426000 seconds]
[Time delta from previous displayed frame: 0.000426000 seconds]
[Time since reference or first frame: 0.000426000 seconds]
Frame Number: 2
Frame Length: 70 bytes
Capture Length: 70 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:icmp:ip:icmp:data]
Ethernet II, Src: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf), Dst: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Destination: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
Address: 00:0a:00:0a:00:0a (00:0a:00:0a:00:0a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
Address: 00:be:75:f2:9e:bf (00:be:75:f2:9e:bf)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xadd9 [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 5 (Redirect)
Code: 1 (Redirect for host)
Checksum: 0xb8e5 [correct]
Gateway address: 10.0.0.2 (10.0.0.2)
Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0xf986 (63878)
Flags: 0x00
0.. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 254
Protocol: ICMP (0x01)
Header checksum: 0xa8ae [correct]
[Good: True]
[Bad : False]
Source: 10.0.0.100 (10.0.0.100)
Destination: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x02f9 [incorrect,should
be 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)
...
Wenn beim Netzwerkdesign der Datenverkehrsfluss von derselben Layer-3-Schnittstelle, auf der er den Switch oder Router betreten hat, geroutet werden muss, kann verhindert werden, dass der Datenverkehrsfluss durch die CPU geleitet wird, wenn Sie die entsprechende ICMP-Umleitungsfunktion auf der Layer-3-Schnittstelle deaktivieren.
Für die meisten Netzwerke empfiehlt es sich, die ICMP-Umleitungen auf allen Layer 3-Schnittstellen proaktiv zu deaktivieren, sowohl physisch (wie bei der Ethernet-Schnittstelle) als auch virtuell (wie bei Port-Channel- und SVI-Schnittstellen). Verwenden Sie no ip redirects
Befehl auf Schnittstellenebene von Cisco NX-OS zum Deaktivieren von ICMP-Umleitungen auf einer Layer-3-Schnittstelle. So überprüfen Sie, ob die ICMP-Umleitungsfunktion deaktiviert ist:
no ip
redirects-Befehl wird zur Schnittstellenkonfiguration hinzugefügt.Nexus7000#show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
Nexus7000#show ip interface vlan 10 | include redirects IP icmp redirects: disabled
Nexus7000#show system internal eltm info interface vlan 10 | i icmp_redirect per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0
Nexus7000#attach module 7
Attaching to module 7 ...
To exit type 'exit', to abort type '$.'
Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts/0
module-7#
!--- Optionally, jump to non-admin Virtual Device Context (VDC) if verification needs to be done in one of the custom VDCs
module-7#vdc 6
module-7#show system internal iftmc info interface vlan 10 | include icmp_redirect
icmp_redirect : 0x0 ipv6_redirect : 0x1
Der in RFC 792 beschriebene ICMP-Umleitungsmechanismus wurde zur Optimierung des Weiterleitungspfads über Multipoint-Netzwerksegmente entwickelt. Zu Beginn des Internets trug eine solche Optimierung dazu bei, teure Netzwerkressourcen wie Verbindungsbandbreite und CPU-Zyklen der Router zu schützen. Mit zunehmendem Kostenaufwand für Netzwerkbandbreite und relativ langsamem CPU-basiertem Paketrouting, das in dedizierten Hardware-ASICs zu schnellerer Layer-3-Paketweiterleitung führte, wurde die Bedeutung einer optimalen Datenübertragung durch Multipoint-Netzwerksegmente verringert. Standardmäßig ist die ICMP-Umleitungsfunktion auf jeder Layer-3-Schnittstelle aktiviert. Die Versuche des Benutzers, Netzwerkknoten in Multipoint-Ethernet-Segmenten über optimale Weiterleitungspfade zu informieren, werden jedoch nicht immer vom Netzwerkpersonal verstanden und umgesetzt. In Netzwerken mit kombinierter Verwendung verschiedener Weiterleitungsmechanismen, wie statisches Routing, dynamisches Routing und richtlinienbasiertes Routing, kann dies zu einer unerwünschten Verwendung der Transitknoten-CPU zur Verarbeitung des Produktionsdatenverkehrs führen, wenn Sie die ICMP-Weiterleitungsfunktion aktiviert lassen und nicht ordnungsgemäß überwachen. Dies wiederum kann erhebliche Auswirkungen sowohl auf den Produktionsdatenverkehr als auch auf die Stabilität der Netzwerkinfrastruktur auf der Kontrollebene haben.
Für die meisten Netzwerke wird es als Best Practice erachtet, die ICMP-Umleitungsfunktion auf allen Layer-3-Schnittstellen in der Netzwerkinfrastruktur proaktiv zu deaktivieren. Dadurch können Szenarien mit Produktionsdatenverkehr vermieden werden, der in der CPU von Layer-3-Switches und -Routern verarbeitet wird, wenn ein besserer Weiterleitungspfad durch Multipoint-Netzwerksegmente vorhanden ist.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
3.0 |
31-Oct-2023 |
Aktualisierte Branding-Anforderungen, Formatierung und Teilnehmerliste. |
2.0 |
22-Sep-2022 |
Rezertifizierung |
1.0 |
17-Oct-2018 |
Erstveröffentlichung |