cisco ccna routing und switching icnd2 200- 101...Ð darunter auch solchen aus dem offiziellen...

50
Cisco CCNA Routing und Switching ICND2 200-101 Das offizielle Handbuch zur erfolgreichen Zertifizierung Bearbeitet von Wendell Odom Übersetzung der 2. amerikanischen Auflage 2014. Buch. LII, 732 S. Hardcover ISBN 978 3 86490 110 2 Format (B x L): 17,5 x 24 cm Weitere Fachgebiete > EDV, Informatik > EDV, Informatik: Allgemeines, Moderne Kommunikation > EDV: Ausbildung, Berufe, Zertifizierung Zu Inhaltsverzeichnis schnell und portofrei erhältlich bei Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft. Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, eBooks, etc.) aller Verlage. Ergänzt wird das Programm durch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr als 8 Millionen Produkte.

Upload: others

Post on 12-May-2020

13 views

Category:

Documents


0 download

TRANSCRIPT

Cisco CCNA Routing und Switching ICND2 200-101

Das offizielle Handbuch zur erfolgreichen Zertifizierung

Bearbeitet vonWendell Odom

Übersetzung der 2. amerikanischen Auflage 2014. Buch. LII, 732 S. HardcoverISBN 978 3 86490 110 2

Format (B x L): 17,5 x 24 cm

Weitere Fachgebiete > EDV, Informatik > EDV, Informatik: Allgemeines, ModerneKommunikation > EDV: Ausbildung, Berufe, Zertifizierung

Zu Inhaltsverzeichnis

schnell und portofrei erhältlich bei

Die Online-Fachbuchhandlung beck-shop.de ist spezialisiert auf Fachbücher, insbesondere Recht, Steuern und Wirtschaft.Im Sortiment finden Sie alle Medien (Bücher, Zeitschriften, CDs, eBooks, etc.) aller Verlage. Ergänzt wird das Programmdurch Services wie Neuerscheinungsdienst oder Zusammenstellungen von Büchern zu Sonderpreisen. Der Shop führt mehr

als 8 Millionen Produkte.

KAPITEL 3

Troubleshooting beim LAN-SwitchingGemeinsam mit einigen anderen Kapiteln und Abschnitten hat das vorliegende Kapitel eine wichtige Aufgabe : Es soll Ihnen dabei helfen, die für das Troubleshooting erforderlichen Kennt-nisse zu erlangen und die entsprechenden Prüfungsaufgaben schnell und richtig beantworten zu können. Gleichzeitig soll Sie dieses Kapitel auch besser auf Situationen vorbereiten, in denen Sie in der Praxis netzwerkspezifische Probleme beheben müssen.

Die Kapitel und Abschnitte zum Troubleshooting in diesem Buch verfolgen ein etwas ande-res Ziel als das übrige Material. Einfach formuliert konzentrieren sich alle Themen, die sich nicht explizit dem Troubleshooting widmen, auf einzelne Merkmale und Tatsachen zu einem Technologiebereich, wogegen die Troubleshooting-Themen eine wesentlich umfassendere Menge von Konzepten in sich vereinen. Diese Kapitel zum Troubleshooting betrachten die Welt der Netzwerktechnik aus einem größeren Abstand: Sie legen den Schwerpunkt darauf, wie die einzelnen Teile miteinander interagieren, und setzen dabei voraus, dass Sie die behandelten Einzelkomponenten bereits kennen.

Dieses Kapitel verfolgt ein naheliegendes und ein weiteres, vielleicht nicht ganz so nahelie-gen des Ziel. Zunächst einmal beschreibt es natürlich das Troubleshooting von LANs. Weni ger augenscheinlich dürfte jedoch sein, dass in diesem Kapitel auch viele der Themen im Zusam-menhang mit Ethernet-LANs wiederholt werden, die Voraussetzung für das Verständnis dieses Buchs sind. In Kapitel 1, »Konzepte des Spanning-Tree-Protokolls«, wurden einige der Themen wiederholt. Im vorliegenden Kapitel werden zahlreiche weitere folgen. Außerdem erfahren Sie hier, wie Sie auf der Basis Ihres vorhandenen und des neuen Wissens das Troubleshooting von Ethernet-LANs durchführen.

In diesem sehr langen Kapitel werden wir das Material in drei Abschnitten vorstellen:

Allgemeine Ansätze zum Troubleshooting Troubleshooting der LAN-Switching-Data-Plane Beispiele und Übungen zum Troubleshooting

Angesichts der schieren Länge dieser Abschnitte sollten Sie in Betracht ziehen, jeden Abschnitt separat zu bearbeiten, sind sie doch zehn bzw. zwanzig Seiten lang. Alle drei Abschnitte gehören thematisch zusammen, weswegen sie im selben Kapitel untergebracht sind. Dabei enthält der mittlere die wichtigsten Themen zum Troubleshooting von LAN-Switches. Zuvor definieren wir zunächst einige Begrifflichkeiten zum Troubleshooting und am Ende stehen im Wesentlichen zwei umfangreiche Beispiele mit zahlreichen show-Befehlen. Mithilfe dieser Beispiele sollen Sie einige Fertigkeiten beim Analysieren von show-Ausgaben auf Cisco-Switches entwickeln.

ICND2.indb 81 20.02.14 17:33

82 Kapitel 3: Troubleshooting beim LAN-Switching

Fragen zur Einschätzung des WissensstandsWeil die Kapitel zum Troubleshooting in diesem Buch Konzepte aus vielen anderen Kapiteln – darunter auch solchen aus dem offiziellen Handbuch Cisco CCENT/CCNA ICND1 100-101 – in sich vereinen und zudem zeigen, wie man einige der anspruchsvolleren Fragen in den CCNA-Prüfungen angeht, sollten Sie diese Kapitel in jedem Fall unabhängig von Ihrem gegen-wärtigen Kenntnisstand lesen. Aus diesen Gründen enthalten die Kapitel zum Troubleshooting auch keine Fragen zur Einschätzung des Wissensstands. Sollten Sie jedoch der Meinung sein, dass Sie sich mit dem Troubleshooting beim LAN-Switching, wie sie in diesem Buch sowie im offiziellen Handbuch Cisco CCENT/CCNA ICND1 100-101 beschrieben werden, wirklich gut auskennen, dann können Sie gerne den Großteil dieses Kapitels überspringen und mit dem Abschnitt »Aufgaben zur Prüfungsvorbereitung« am Ende des Kapitels fortfahren.

ICND2.indb 82 20.02.14 17:33

3.1 Allgemeine Ansätze zum Troubleshooting 83

3

Grundlagenthemen

3.1 Allgemeine Ansätze zum Troubleshooting

HINWEIS Die hier beschriebenen allgemeinen Ansätze und Methoden zum Trouble-shooting sind Mittel zum Zweck. Für die Prüfung brauchen Sie diese Abläufe weder zu studieren noch sie sich zu merken. Vielmehr sind diese Prozesse dafür gedacht, Ihnen bei der Problemanalyse während der Prüfung zu helfen, sodass Sie die Fragen ein wenig schneller und mit etwas mehr Selbstvertrauen beantworten können.

Wenn man mit einem Netzwerkproblem konfrontiert wird, verwendet man bewusst oder unbe-wusst immer irgendeine Troubleshooting-Methodik. Es gibt Menschen, die zunächst einmal die physische Verkabelung und den Interface-Status aller physischen Verbindungen überprüfen, die Ursache des Problems sein könnten. Andere schicken anfangs stets Ping-Befehle an alle Systeme, um mehr zum Problem zu erfahren, und arbeiten sich dann nach und nach vor. Wieder andere probieren alle möglichen Schritte aus, bis sie am Ende intuitiv erfassen, worin genau das Problem besteht. Keine dieser Methoden ist für sich genommen gut oder schlecht; ich habe sie alle (und auch weitere) bereits ausprobiert und mit jedem Ansatz habe ich mindestens einmal Erfolg gehabt.

Zwar entwickeln die meisten Menschen zur Behebung von Problemen früher oder später Gewohnheiten und Ansätze, die im Rahmen ihrer eigenen Erfahrungen und Stärken gut funk-tionieren. Allerdings kann jeder, der sich mit dem Troubleshooting insbesondere in einem bestimmten Sachgebiet auseinandersetzt, durch Aneignen einer systematischeren Methodik erlernen, wie man Probleme mit mehr Aussicht auf Erfolg angeht. In den folgenden Abschnitten beschreiben wir einen solchen systematischen Ansatz, der Ihnen dabei helfen soll, sich auf die CCNA-Prüfungen vorzubereiten.

Diese Methodik basiert auf drei wesentlichen Phasen, die gewöhnlich in der folgenden Reihen-folge auftreten:

Normalbetrieb analysieren/prognostizieren: Bei diesem Schritt wird folgende Frage beantwortet: Was sollte in diesem Netzwerk geschehen? Ergebnis dieses Schritts ist eine Beschreibung und Vorhersage der Einzelheiten dessen, was passieren sollte, wenn das Netz-werk korrekt arbeitet, basierend auf der Dokumentation, der Konfiguration und der Aus-gabe von show- und debug-Befehlen.

Problemeingrenzung: Bei diesem Schritt wird folgende Frage beantwortet: Was genau funktioniert nicht? Wenn ein Problem auftritt, müssen Sie die Komponenten suchen, die im Vergleich zum Normalverhalten nicht korrekt funktionieren. Danach ermitteln Sie die Ursache des Problems usw. Auch hier basieren die Antworten auf Dokumentation, Konfiguration und der Ausgabe von show- und debug-Befehlen.

Ursachenanalyse (engl. Root Cause Analysis): Bei diesem Schritt wird folgende Frage beantwortet: Was muss korrigiert werden, um das Problem zu lösen? Sie ermitteln dabei die Ursachen des im vorherigen Schritt erkannten Problems. Es geht dabei insbesondere um Ursachen, die sich durch bestimmte Maßnahmen beheben lassen.

ICND2.indb 83 20.02.14 17:33

84 Kapitel 3: Troubleshooting beim LAN-Switching

Die Verinnerlichung dieser drei Schritte sollte zur Folge haben, dass Sie wissen, wie Sie ein Problem grundsätzlich lösen, statt nur die Symptome zu beseitigen. Als Nächstes werden wir einige Gedanken zu der Frage erläutern, wie man die einzelnen Schritte des Troubleshooting-Ablaufs angehen kann.

Normalbetrieb des Netzwerks analysieren und prognostizierenAufgabe eines jeden Netzwerktechnikers ist es, dafür Sorge zu tragen, dass Daten von einem Endbenutzergerät zu einem anderen übertragen werden. Um ein Netzwerk analysieren zu kön-nen, muss der Techniker die Logik kennen, die von den einzelnen verschalteten Geräten bei der Weiterleitung der Daten zum jeweils nächsten Gerät zugrunde gelegt wird. Indem er sich verge-genwärtigt, was auf den einzelnen Geräten passieren sollte, kann der Techniker den gesamten Datenfluss beschreiben.

Der Begriff Data-Plane (Datenebene) bezieht sich auf Schritte, die von Geräten bei der Weiter-leitung von Daten ausgeführt werden. Zur Weiterleitung wendet ein Gerät Logik und Prozesse seiner Data-Plane auf den Frame oder das Paket an. Wenn ein LAN-Switch beispielsweise einen Frame über ein Interface in VLAN 3 empfängt, trifft er seine Weiterleitungsentscheidung basie-rend auf den Einträgen zu VLAN 3 in der MAC-Adresstabelle und leitet das Paket dann weiter. Diese Logik legt den Schwerpunkt auf die Weiterleitung von Benutzerdaten und ist insofern Bestandteil der Data-Plane-Verarbeitung des Switchs.

Der Begriff Control-Plane (Steuerungsebene) hingegen verweist auf zusätzliche Prozesse, die zwar die Vorgänge auf dem Netzwerkgerät steuern, aber nicht für jedes Paket oder jeden Frame durchzuführen sind. Beispiele für Control-Plane-Prozesse sind STP (Spanning Tree Protocol) und alle IP-Routing-Protokolle.

Zudem ändern einige Control-Plane-Prozesse noch nicht einmal indirekt die Art und Weise, wie das Gerät Daten weiterleitet. So kann CDP (Cisco Discovery Protocol) etwa nützlich sein, um die Richtigkeit der Netzwerkdokumentation zu verifizieren, lässt sich allerdings ebenso deak-tivieren, ohne dass sich dies auf die Weiterleitungsprozesse der Data-Plane auswirken würde. Auch CDP wäre ein Control-Plane-Prozess.

Um den voraussichtlichen Betrieb eines Netzwerks prognostizieren oder erläutern zu können, wie ein korrekt funktionierendes Netzwerk gegenwärtig arbeitet, kann es für das Trouble-shooting hilfreich sein, sich zunächst mit der Control-Plane oder der Data-Plane zu beschäfti-gen. Im Folgenden werden wir zwar zunächst die Data-Plane behandeln, doch können Sie in der Praxis je nach vorliegenden Symptomen bei der Data- oder der Control-Plane beginnen.

Data-Plane analysierenBeim Troubleshooting in der Data-Plane werden alle Geräte im angenommenen Weiterleitungs-pfad der Daten in der jeweiligen Reihenfolge untersucht. Die Analyse beginnt bei dem Host, auf dem die Daten ursprünglich erstellt werden. Dieser Host sendet die Daten an ein anderes Gerät, welches sie dann wiederum an ein anderes Gerät weiterleitet usw., bis die Daten schließlich beim endgültigen Empfänger eintreffen.

Beim Troubleshooting in der Data-Plane müssen beide Datenflussrichtungen zwischen zwei Geräten überprüft werden. Wenn nämlich ein Gerät Daten sendet, dann schickt der empfan-gende Host in aller Regel irgendeine Antwort zurück. Wenn also ein Benutzer beispielsweise meldet, dass er keine Verbindung mit Server1 herstellen kann, kann dies durchaus durch ein Problem verursacht werden, aufgrund dessen keine Pakete vom Benutzer an Server1 übertragen

ICND2.indb 84 20.02.14 17:33

3.1 Allgemeine Ansätze zum Troubleshooting 85

3

werden können; genauso gut kann es aber sein, dass einfach keine Pakete von Server1 zum Benutzer gesendet werden können. Sie müssen also, um zu verstehen, wie die Kommunikation sinnvoll erfolgt, den Pfad immer auch in Gegenrichtung analysieren.

Sofern die Symptome nicht bereits Rückschlüsse auf ein bestimmtes Problem zulassen, sollte das Data-Plane-Troubleshooting mit einer Analyse der Schicht-3-Data-Plane beginnen. Wenn Sie bei Schicht 3 anfangen, erkennen Sie die wesentlichen Schritte beim Versand und Empfang von Daten zwischen zwei Hosts. Sie können sich dann jeden einzelnen Weiterleitungsschritt in Schicht 3 genauer ansehen und dabei auch die jeweiligen Schicht-1- und Schicht-2-Details ana-lysieren. Abbildung 3.1 zeigt exemplarisch die sechs wesentlichen Schritte der IP-Weiterleitung (Data-Plane) in einem kleinen Netzwerk.

321

5

46

R1 R2PC1

PC2

SW1 SW3 SW4

SW5SW2

Abbildung 3.1 Wesentliche Schritte bei der IP-Weiterleitung

Wenn Sie das voraussichtliche Verhalten in Schicht 3 in diesem Fall nachvollziehen möchten, müssen Sie zunächst überlegen, wie der Paketfluss von links nach rechts erfolgt; danach den-ken Sie darüber nach, wie der Ablauf in umgekehrter Richtung stattfindet. Die sechs in der Abbildung gezeigten Schritte gestatten die folgende Analyse:

Schritt 1: Überprüfen Sie die IP-Adresse und die Subnetzmaske von PC1 und von PC2 und die Logik, mit der PC1 erkennt, dass sich PC2 in einem anderen Subnetz befindet. Aus diesem Grund sendet PC1 das Paket an sein Default-Gateway (R1).

Schritt 2: Überprüfen Sie die Weiterleitungslogik von R1 zur Zuordnung der Empfänger-IP-Adresse des Pakets in der Routing-Tabelle von R1 unter der Annahme, dass R1 das Paket als Nächstes an R2 weiterleitet.

Schritt 3: Auf R2 sollten Sie dieselbe Zuordnungslogik in der Routing-Tabelle wie im vorheri-gen Schritt bei R1 überprüfen, nur dass hier die Routing-Tabelle von R2 verwendet wird. Der passende Eintrag sollte eine an R2 angeschlossene Route sein.

Schritt 4: Dieser Schritt bezieht sich auf das Antwortpaket von PC2, wobei grundsätzlich dieselbe Logik wie in Schritt 1 zum Einsatz kommt. Vergleichen Sie IP-Adresse und Subnetzmaske von PC2 mit der IP-Adresse von PC1. Hierbei stellen Sie fest, dass sie sich in verschiedenen Subnetzen befinden. Infolgedessen sollte PC2 das Paket an sein Default-Gateway R2 schicken.

Schritt 5: Überprüfen Sie die Weiterleitungslogik von R2 für Pakete, die an die IP-Adresse von PC1 gesendet werden, unter der Annahme, dass R2 diese Pakete bei passender Route direkt an R1 schickt.

ICND2.indb 85 20.02.14 17:33

86 Kapitel 3: Troubleshooting beim LAN-Switching

Schritt 6: Der letzte Schritt auf R1 sollte zeigen, dass ein Paket, das an die IP-Adresse von PC1 gerichtet ist, zu einer an R1 angeschlossenen Route passt. Aus diesem Grund sendet R1 das Paket direkt an die MAC-Adresse von PC1.

Nachdem Sie das voraussichtliche Verhalten in allen Schritten von Schicht 3 erfasst haben, kön-nen Sie sich der näheren Untersuchung von Schicht 2 zuwenden. Sie führen die Analyse wieder in derselben Reihenfolge durch und betrachten dabei zunächst den ersten in Abbildung 3.1 gezeigten Schicht-3-Routing-Schritt (PC1 sendet ein Paket an R1). Dabei überprüfen Sie die Schicht-1- und Schicht-2-Details hinsichtlich der Frage, wie der Frame von PC1 gesendet wird, um bei R1 zu landen (Abbildung 3.2) .

2

3

1 4R1SW3SW1

SW2

PC1

STP-Blocking

Abbildung 3.2 Wesentliche Schritte bei der LAN-Switching-Weiterleitung

Für diese Analyse beginnen Sie zunächst wieder bei PC1. Diesmal überprüfen Sie Ethernet-Header und -Trailer und dabei insbesondere die MAC-Adressen von Absender und Empfänger. In Schritt 2 verifizieren Sie dann die Weiterleitungslogik von SW1: Diese vergleicht die Empfänger-MAC-Adresse mit der MAC-Adresstabelle auf SW1 und weist SW1 daraufhin an, den Frame an SW2 weiterzuleiten. Die Schritte 3 und 4 wiederholen die Logik aus Schritt 2 für SW2 bzw. SW3.

Control-Plane analysierenViele Prozesse in der Control-Plane wirken sich direkt auf den Data-Plane-Prozess aus. So funk-tioniert beispielsweise der Data-Plane-Prozess des IP-Routings nicht ohne geeignete IP-Routen, d. h., Router verwenden normalerweise ein dynamisches Routing-Protokoll – ein Control-Plane-Protokoll – zum Erlernen der Routen. Routing-Protokolle gelten teilweise deswegen als Protokolle der Control-Plane, weil die vom Routing-Protokoll durchgeführten Schritte keine direkte Rolle bei der Weiterleitung eines Frames oder Pakets spielen.

Während die Prozesse der Data-Plane sich für eher universelles Troubleshooting eignen, bei dem die Weiterleitungslogik auf jedem Gerät untersucht wird, unterscheiden sich die Prozesse der Control-Plane zu deutlich voneinander, als dass sie ein allgemeingültiges Troubleshooting ermöglichen würden. Jeder Prozess der Control-Plane kann separat untersucht werden. So erklärt beispielsweise Kapitel 2, »STP-Implementierung«, wie man verschiedene Arten STP-spezifischer Probleme beheben kann .

ICND2.indb 86 20.02.14 17:33

3.1 Allgemeine Ansätze zum Troubleshooting 87

3

Zusammenfassung zur Prognose des NormalbetriebsBei den Prüfungen wird die eine oder andere Aufgabe auf Sie zukommen, bei der Sie den norma-len Betrieb eines laufenden Netzwerks analysieren und vorhersagen müssen. In anderen Fällen ist die Prognose des normalen Verhaltens lediglich als Vorlauf zur Eingrenzung und Behebung eines Problems gedacht. Unabhängig davon können Sie, wenn die Aufgabe keine bestimmten Hinweise zu dem Teil des Netzwerks enthält, um den es geht, der folgenden Liste eine empfoh-lene Vorgehensweise zur Antwortfindung entnehmen:

Schritt 1: Untersuchen Sie die Data-Plane wie folgt:

a. Ermitteln Sie die wesentlichen Schicht-3-Schritte – also vom Ursprungshost zum Default-Gateway, von den einzelnen Routern zum jeweils nächsten Router und schließlich vom letzten Router bis zum Empfängerhost – in beiden Richtungen .

b. Analysieren Sie für jedes Schicht-2-Netzwerk zwischen einem Host und einem Router oder zwei Routern die Weiterleitungslogik aller beteiligten Geräte.

Schritt 2: Untersuchen Sie die Control-Plane wie folgt:

a. Ermitteln Sie, welche Control-Plane-Protokolle für die Weiterleitung zum Einsatz kommen und wichtig sind.

b. Untersuchen Sie alle wichtigen Control-Plane-Protokolle auf ordnungsgemä-ßen Betrieb. Die Details dieser Analysen unterscheiden sich je nach Protokoll.

c. Verschieben Sie die Analyse von Protokollen der Control-Plane, die den ordnungsgemäßen Betrieb der Data-Plane nicht beeinträchtigen, auf einen späteren Zeitpunkt, wenn Sie sicher sind, dass Sie dieses Protokoll (z. B. CDP) brauchen, um die Aufgabe zu bearbeiten.

Probleme eingrenzenBeim Troubleshooting müssen Sie die Ursache eines Problems finden und beheben. Der Prozess der Ursachenermittlung beginnt mit der Eingrenzung des Problems. Hierdurch gelangen Sie von allgemeinen Ansichten zum Problem ausgehend zu einer bestimmten Meinung darüber, worin das Problem bestehen könnte:

Vor der Problemeingrenzung: Sie kennen einige Symptome, haben aber keine Ahnung, worin das Problem bestehen könnte.Nach der Problemeingrenzung: Sie wissen nun, was nicht funktioniert, können dies in ein Verhältnis zum erwünschten Normalbetrieb setzen und haben auch erkannt, auf welchen Geräten die Funktionen nicht wie gewünscht ausgeführt werden.

Betrachten Sie beispielsweise noch einmal Abbildung 3.1. Diese Abbildung zeigt in sechs Routing-Schritten, wie ein Paket von PC1 an PC2 und wieder zurück übermittelt wird. In diesem Fall jedoch stellen Sie fest, dass zwar R2 das in der Abbildung von links nach rechts wandernde Paket erhält, dieses aber nicht an PC2 ausgeliefert wird. Also sehen Sie sich den dritten Routing-Schritt zwischen R2 und PC2 in der Abbildung näher an, um das Problem weiter einzugrenzen. Dieser Vorgang des Isolierens von Problemursachen heißt Problemeingrenzung.

ICND2.indb 87 20.02.14 17:33

88 Kapitel 3: Troubleshooting beim LAN-Switching

Nachdem Sie das Problem auf genau einen IP-Weiterleitungsschritt eingegrenzt haben (vgl. Abbildung 3.1), sollten Sie es weiter auf eine möglichst kleine Anzahl von Komponenten beschränken. Wenn beispielsweise R2 das Paket empfängt, PC2 aber nicht, dann kann das Problem auf R2, SW4, SW5, PC2, bei der Verkabelung oder auch bei Geräten vorliegen, die nicht in der Netzwerkdokumentation angegeben sind.

Zur weiteren Eingrenzung des Problems ist nun gewöhnlich ein Überprüfen verschiedener Funktionen mehrerer Schichten des OSI-Modells erforderlich. Hierbei dreht es sich sowohl um die Data-Plane als auch um die Control-Plane. Beispielsweise muss R2 die MAC-Adresse von PC2 kennen, die er mithilfe des ARP-Protokolls (Address Resolution Protocol) erlernt hat, um Pakete an PC2 weiterleiten zu können. Wenn Sie feststellen, dass R2 über keinen ARP-Eintrag zu PC2 verfügt, könnten Sie versucht sein, anzunehmen, dass ein IP-spezifisches Problem aufgetre-ten ist. Die Problemursache kann allerdings jedes Element der folgenden Liste sein :

Der Trunk zwischen SW4 und SW5 kann deaktiviert worden sein. Das Kabel zwischen SW5 und PC2 ist unter Umständen schadhaft. In der IPv4-Konfiguration von PC2 ist die IP-Adresse von PC2 möglicherweise nicht festge-

legt. Der DHCP-Server (Dynamic Host Configuration Protocol) könnte fehlkonfiguriert sein,

weswegen PC2 keine IP-Adresse erlernt hat.

Bei der Problemeingrenzung geht es darum, ausgehend von einer allgemeinen Idee immer spe-zifischer zu werden. In unserem Beispiel wurde das Problem bis zu dem Punkt hin eingegrenzt, an dem klar wurde, dass der ARP-Request von R2 für PC2 fehlgeschlagen ist; warum genau dies passiert ist, haben wir allerdings an dieser Stelle noch nicht bestimmt.

Wenn eine Prüfungsaufgabe keinerlei Hinweise darauf enthält, wo man ansetzen könnte, bietet der folgende Ablauf eine geeignete allgemeine und systematische Strategie zur Problem-eingrenzung:

Schritt 1: Untersuchen Sie zunächst die Schicht-3-Data-Plane (IP-Weiterleitung) und verglei-chen Sie die Ergebnisse mit dem erwarteten Normalverhalten, bis Sie den ersten wichtigen Routing-Schritt erkennen, der fehlschlägt.

Schritt 2: Grenzen Sie das Problem auf möglichst wenige Komponenten ein:

a. Untersuchen Sie alle OSI-Schichten, aber legen Sie den Schwerpunkt auf die Schichten 1, 2 und 3.

b. Untersuchen Sie gleichermaßen die Funktionen der Data-Plane und der Control-Plane.

Denken Sie bei den Prüfungen daran, dass Sie allein für gute Troubleshooting-Methoden keinen Schönheitspreis erhalten, d. h., Sie sollten die Antwort auf irgendeine Weise finden, auch wenn dies bedeutet, dass Sie auf der Basis des Aufgabenkontextes ein bisschen raten müssen. So wird beispielsweise in Schritt 2a vorgeschlagen, dass Sie sich bei Ihren Überlegungen auf die Schichten 1, 2 und 3 konzentrieren sollten. Dieser Vorschlag basiert darauf, dass die CCNA-Prüfungen ebenfalls den Schwerpunkt auf diese drei Schichten legen. Sehen Sie aber zu, dass Sie diesen Vorgang so weit abkürzen, wie es die Frage gestattet.

ICND2.indb 88 20.02.14 17:33

3.1 Allgemeine Ansätze zum Troubleshooting 89

3

UrsachenanalyseDer letzte der drei Schritte – die Ursachenanalyse (engl. Root Cause Analyses) – steht am Abschluss des Troubleshootings . Es geht darum, das Gerät und die zugehörige Funktion zu ermitteln, die korrigiert werden müssen. Die Ursache ist ein im Netzwerk aufgetretenes Problem; ist es behoben, dann ist das ursprüngliche Problem zumindest teilweise gelöst.

Die Suche nach dieser Hauptursache ist zu ihrer Behebung unabdingbar. Vergegenwärtigen wir uns noch einmal unser Beispiel, bei dem R2 keine Pakete an PC2 weiterleiten konnte. Hierbei haben wir im Zuge der Eingrenzung die folgenden Probleme erkannt:

R2 kann keine Pakete an PC2 weiterleiten. R2 erhält keine ARP-Replys von PC2. Das Interface von SW4 zum Trunk zu SW5 befindet sich im Status down/down. Das zwischen SW4 und SW5 verlegte Kabel ist fehlerhaft belegt.

Alle diese Aussagen treffen gewiss auf ein bestimmtes Problemszenario zu, aber nur für den letzten Eintrag in der Liste gibt es eine naheliegende Lösung (nämlich den Austausch des vor-handenen Kabels gegen ein ordnungsgemäß belegtes). Zwar sind die anderen Aussagen zutref-fende und auch wichtige Aspekte, die während der Problemeingrenzung zu berücksichtigen sind, aber es gibt keine Maßnahme, die sich direkt anbieten würde, um eines dieser Probleme zu lösen. Infolgedessen reduziert sich die Ursachenanalyse auf zwei einfache Anweisungen:

Schritt 1: Fahren Sie mit der Problemeingrenzung fort, bis Sie die Ursache erkennen, für die eine Lösung naheliegt.

Schritt 2: Wenn Sie das Problem nicht auf eine echte Ursache eingrenzen können, führen Sie die Eingrenzung so weit wie möglich durch und ändern Sie etwas im Netzwerk, damit sich die Symptome möglicherweise ändern und Sie so weitere Einsichten in das Wesen des Problems gewinnen.

Prüfungsaufgaben und die PraxisSuchen Sie bei der Prüfung nach Hinweisen, etwa dem allgemeinen Thema, für das ein Teil des Troubleshootings erfolgt . Wenn also beispielsweise die Abbildung in der Aufgabe ein Netzwerk wie das in Abbildung 3.1 gezeigte darstellt, aber alle Multiple-Choice-Antworten sich auf VLANs und STP beziehen, dann sollten Sie sich zunächst die LAN-Umgebung ansehen. Trotzdem sollten Sie natürlich auch die Schichten 1 bis 3 sowie die Details der Data-Plane und der Control-Plane berücksichtigen, um die gewünschten Antworten zu finden.

HINWEIS Dieser Abschnitt bezieht sich zwar generell auf das Troubleshooting, ist aber nur in diesem Kapitel enthalten, weil es sich hierbei um das erste Kapitel in diesem Buch handelt, das sich dem Themenkreis des Troubleshootings widmet.

Damit endet die Einführung in die Methoden des Troubleshootings. Nun wollen wir uns dem Troubleshooting für praktisch alle in der ICND1-Prüfung behandelten Themen zum LAN-Switching zuwenden.

ICND2.indb 89 20.02.14 17:33

90 Kapitel 3: Troubleshooting beim LAN-Switching

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

HINWEIS Hier ein paar Tipps für den Anfang dieses zweiten Abschnitts im Kapitel. Machen Sie eine kleine Pause, schöpfen Sie Atem und bereiten Sie sich vor. Der nun bevor-stehende Abschnitt ist lang – und zwar etwa so lang wie der Teil »Grundlagenthemen« der meisten anderen Kapitel. Wenn Sie die Lektüre vor dem Ende dieses langen Abschnitts unter-brechen müssen, tun Sie dies möglichst vor einer Überschrift, die mit »Schritt 1«, »Schritt 2« usw. beginnt.

Die bislang in diesem Kapitel behandelten Troubleshooting-Strategien legen nahe, dass man zunächst den IP-Routing-Prozess in Schicht 3 überprüft. Wenn der Netzwerktechniker ein Problem bei einem bestimmten Schritt im IP-Weiterleitungsprozess erkennt, sollte der nächs-te Schritt darin bestehen, sich diesen Schritt genauer anzusehen, wobei auch der Status der zugrunde liegenden Schichten 1 und 2 berücksichtigt werden muss. Wird bei einem Routing-Schritt ein LAN durchquert, dann können Sie das Problem mithilfe der Angaben in diesem Abschnitt eingrenzen und die Ursache ermitteln.

Auf dieser Seite beginnt der zweite der drei Hauptabschnitte in diesem Kapitel: Hier werden wir uns die Tools und Prozesse genau ansehen, mit denen man Probleme bei den Prozessen der LAN-Data-Plane in den Schichten 1 und 2 behebt. Im weiteren Verlauf dieses Kapitels setzen wir voraus, dass die Ursache ein LAN-spezifisches Problem und kein Schicht-3-Problem ist; das Schicht-3-Troubleshooting für IPv4 wird in den Kapiteln 4, »Troubleshooting beim IPv4-Routing (Teil 1)«, 5, »Troubleshooting beim IPv4-Routing (Teil 2)«, und 11, »Troubleshooting von IPv4-Routing-Protokollen«, behandelt. Im vorliegenden Kapitel wird auch auf Control-Plane-Protokolle verwiesen, und zwar insbesondere auf STP; dieses Protokoll war allerdings bereits Gegenstand der beiden vorherigen Kapitel. Insofern können wir uns in den folgenden Abschnitten ganz auf die LAN-Switching-Data-Plane konzentrieren.

Noch ein paar Worte zur Struktur dieses Abschnitts: Sie finden hier fünf Hauptthemen. Am Anfang rekapitulieren wir zunächst noch einmal die Weiterleitungsprozesse beim LAN-Switch und stellen Ihnen die vier wichtigsten Schritte des Troubleshootings beim LAN-Switching vor, wie sie in diesem Kapitel behandelt werden. Die weiteren vier Themen beschreiben dann aus-führlich jeweils einen Troubleshooting-Schritt.

Der normale Weiterleitungsprozess bei LAN-Switches in der ÜbersichtIn Kapitel 1 dieses Buchs wurde noch einmal wiederholt, mit welcher Logik ein LAN-Switch Frames weiterleitet. Allerdings wurde STP bei der Beschreibung dieser Logik nicht berücksich-tigt. In den nachfolgenden Prozessschritten ist diese Logik aufs Neue skizziert, diesmal jedoch mit zusätzlichen Anmerkungen hinsichtlich der Auswirkungen von STP auf die Weiterleitung durch Switches:

ICND2.indb 90 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 91

3

Schritt 1: Der Switch ermittelt das VLAN, in dem der Frame weitergeleitet werden soll, wie folgt:

a. Wenn der Frame über ein Access-Interface empfangen wird, wird das Access-VLAN des Interface verwendet.

b. Wenn der Frame über ein Trunk-Interface eingeht, verwenden Sie das VLAN, welches im Trunking-Header des Frames aufgeführt ist.

Schritt 2: Wenn das Eingangs-Interface in diesem VLAN sich im Learning- oder Forwarding-Status befindet, fügt der Switch die Absender-MAC-Adresse zu seiner MAC-Adresstabelle hinzu und verknüpft sie dort mit dem eingehenden Interface und der VLAN-ID (sofern die Angaben dort noch nicht vorhanden sind).

Schritt 3: Wenn das eingehende Interface sich in diesem VLAN nicht im STP-Forwarding-Status befindet, wird der Frame verworfen.

Schritt 4: Der Switch sucht nach der Empfänger-MAC-Adresse des Frames in der MAC-Adresstabelle, jedoch nur für Einträge im in Schritt 1 ermittelten VLAN. Je nach dem, ob die MAC-Adresse gefunden wird oder nicht, werden die folgenden Schritte ausgeführt:

a. Die MAC-Adresse wird gefunden. Der Frame wird über genau das Interface weitergeleitet, das im zur Adresse passenden Tabelleneintrag aufgeführt ist.

b. Die MAC-Adresse wird nicht gefunden. Der Frame wird über alle anderen Access-Ports im selben VLAN, die sich im Forwarding-Status befinden, sowie über alle Trunk-Ports geflutet, die dieses VLAN als vollständig unterstützt aufführen.

Um einen Frame weiterzuleiten, muss ein Switch zunächst ermitteln, in welchem VLAN der Frame weitergeleitet werden soll (Schritt 1), bei Bedarf die Absender-MAC-Adressen erlernen (Schritt 2) und schließlich festlegen, wohin der Frame weitergeleitet werden soll. Um sicherzu-stellen, dass Sie diesen Prozess wirklich verstanden haben, betrachten Sie das in Abbildung 3.3 gezeigte Beispiel. Hier sendet PC1 einen Frame mit der in der Abbildung gezeigten MAC-Adresse an sein Default-Gateway R1 .

Gi0/1Fa0/11

Gi0/1 Fa0/10Gi0/2Fa0/12

0200.1111.1111

0200.2222.2222

0200.0101.0101Gi0/2 Gi0/1

Gi0/1 Gi0/2

Fa0/13

R1

PC1

PC3

PC2 SW1 SW2

SW3

Abbildung 3.3 Geswitchtes Netzwerk zur Verwendung bei der Data-Plane-Analyse in Kapitel 3

ICND2.indb 91 20.02.14 17:33

92 Kapitel 3: Troubleshooting beim LAN-Switching

Betrachten Sie den Frame, der von PC1 (Absender-MAC-Adresse 0200.1111.1111) an R1 (Empfänger-MAC-Adresse 0200.0101.0101) gesendet wird. Die folgende Liste erläutert die Weiterleitungslogik für alle in der Abbildung gezeigten Schritte:

SW1 ermittelt über den oben beschriebenen Schritt 1, ob das Interface Fa0/11 als Access-Interface oder als Trunk verwendet wird. In diesem Fall handelt es sich um ein Access-Interface, das VLAN 3 zugewiesen ist.

In Schritt 2 ergänzt SW1 einen Eintrag in seiner MAC-Adresstabelle, der die MAC-Adresse 0200.1111.1111, das Interface Fa0/11 und das VLAN 3 aufführt.

In Schritt 3 vergewissert sich SW1, dass sich das eingehende Interface Fa0/11 im Forwarding-Status befindet.

In Schritt 4 schließlich sucht SW1 nach einem Eintrag mit der MAC-Adresse 0200.0101.0101 in VLAN 3. Findet SW1 einen Eintrag, der das Interface Gigabit 0/1 aufführt, dann leitet SW1 den Frame nur über Gi0/1 weiter. Ist das ausgehende Interface Gi0/1 ein Trunk-Interface, dann fügt SW1 einen VLAN-Trunking-Header hinzu, der das VLAN mit der in Schritt 1 ermittelten ID (also VLAN 3) aufführt.

Ein weiteres, etwas abgeändertes Beispiel: Angenommen, PC1 sendet einen Broadcast. Die Schritte 1 bis 3 erfolgen wie in der Liste beschrieben, doch in Schritt 4 flutet SW1 den Frame. SW1 allerdings flutet den Frame nur über die Access-Ports in VLAN 3 sowie über Trunk-Ports, die VLAN 3 unterstützen. Dabei gilt die Einschränkung, dass SW1 über Ports, die sich nicht im Forwarding-Status befinden, keine Kopie des Frames weiterleitet.

Obwohl diese Weiterleitungslogik relativ simpel gestrickt ist, erfordert der Troubleshooting-Vorgang die Anwendung fast aller LAN-spezifischen Konzepte, die in den Büchern zu ICND1 und ICND2 beschrieben werden, sowie weiterer Aspekte. Wenn man beispielsweise weiß, dass PC1 zuerst Frames an SW1 schickt, ist es sinnvoll, den Status des Interface zu überprü-fen, sicherzustellen, dass das Interface up/up ist, und – sollte dies nicht der Fall sein – das Problem mit dem Interface zu beheben. Um Probleme zu beseitigen, kann es notwendig sein, Dutzende einzelner Faktoren zu überprüfen. Aus diesem Grund wird in diesem Kapitel ein Troubleshooting-Vorgang für die Data-Plane beschrieben, der alle Maßnahmen in vier verschie-dene Schritte unterteilt:

Schritt 1: Netzwerkdiagramme mit CDP verifizieren

Schritt 2: Interface-Probleme eingrenzen

Schritt 3: Probleme in Zusammenhang mit Filterung und Port-Security eingrenzen

Schritt 4: VLAN- und Trunking-spezifische Probleme eingrenzen

In den nächsten vier Abschnitten wiederholen und erläutern wir die Konzepte und Werkzeuge, mit denen diese Schritte durchgeführt werden. Zwar werden einige Tatsachen und Angaben neu für Sie sein, doch der Großteil der zugrunde liegenden Konzepte wurde – entweder im offi-ziellen Handbuch Cisco CCENT/CCNA ICND1 100-101 oder in den ersten beiden Kapiteln dieses Buchs – bereits behandelt. Das wesentliche Ziel der folgenden Abschnitte besteht darin, alle Konzepte zusammenzuführen, damit die Analyse konkreter Szenarios, wie sie bei den Prüfungen verlangt wird, weniger lang dauert und die Erfolgschancen erhöht werden .

ICND2.indb 92 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 93

3

Schritt 1: Netzwerkdiagramme mit CDP verifizierenDas CDP-Protokoll (Cisco Discovery Protocol) kann nützlich sein, um die Informationen im Netzwerkdiagramm zu verifizieren und weitere hilfreiche Angaben zu Geräten und zur Netzwerktopologie zu ermitteln. In der Praxis sind Netzwerkdiagramme häufig alt und über-holt; Probleme treten meist dann auf, wenn jemand die Verkabelung geändert, das Diagramm aber nicht aktualisiert hat. Ich bezweifle zwar, dass man vonseiten Ciscos in einer Aufgabe eine Abbildung zeigt, die bewusst falsche Angaben enthält, aber es ist durchaus möglich, dass eine solche Abbildung nicht alle erforderlichen Informationen zeigt, weswegen Sie die übrigen Details mit dem CDP-Protokoll ermitteln müssen. In diesem Abschnitt geht es also um CDP und ein empfehlenswerter erster Schritt zur Behebung von Problemen der LAN-Data-Plane lautet mithin:

Schritt 1: Überprüfen Sie mithilfe von CDP die im Netzwerkdiagramm aufgeführten Anga-ben auf Richtigkeit und Vollständigkeit.

HINWEIS Dieses Kapitel zeigt eine Anzahl von Schritten zur Behebung von Switching-Problemen, die beginnend mit 1 nummeriert sind. Die Reihenfolge der Schritte ist für die Prüfung irrelevant, die Nummerierung dient lediglich Ihrer Orientierung.

Router, Switches und andere Geräte von Cisco verwenden CDP für viele unterschiedliche Zwecke. Router und Switches nutzen das Protokoll in erster Linie, um Informationen über sich selbst – also etwa den Hostnamen, den Gerätetyp, die IOS-Version und die Interface-Nummern – an ihre Nachbarn zu übermitteln. Im Wesentlichen sind es die drei in Tabelle 3.1 aufgeführ-ten Befehle, die von den Nachbarn erlernte CDP-Informationen auflisten. Ist überhaupt kein Netzwerkdiagramm vorhanden, dann könnte ein Netzwerktechniker ein Diagramm der Router und Switches allein aus der Ausgabe des Befehls show cdp erstellen.

Tabelle 3.1 show cdp-Befehle zum Auflisten von Informationen zu benachbarten Geräten

Befehl Beschreibung

show cdp neighbors [typ nummer] Hiermit wird eine einzeilige Zusammenfassung zu jedem Nachbarn bzw., sofern ein Interface angegeben war, zu dem an diesem Interface gefundenen Nachbarn aufgelistet.

show cdp neighbors detail Führt umfangreiche Informationen (ca. 15 Zeilen) pro Nachbargerät auf.

show cdp entry name Führt dieselben Angaben wie show cdp neighbors detail auf, jedoch nur zum benannten Nachbarn.

Die CDP-Ausgabe kann ein bisschen knifflig sein, da oft nicht auf den ersten Blick ersichtlich ist, ob ein aufgeführtes Interface sich auf dem lokalen oder einem benachbarten Gerät befindet. Von links nach rechts listet die Ausgabe gewöhnlich den Hostnamen des Nachbargeräts unter der Überschrift »Device ID« auf. In der nächsten Spalte erscheinen unter »Local Intrfce« Name und Nummer des lokalen Interface. Name und Nummer des Interface des Nachbargeräts befin-den sich rechts in der Ausgabe unter der Überschrift »Port ID«.

ICND2.indb 93 20.02.14 17:33

94 Kapitel 3: Troubleshooting beim LAN-Switching

Listing 3.1 zeigt exemplarisch die Ausgabe von show cdp neighbors für SW2 in Abbildung 3.3. Nehmen Sie sich ein wenig Zeit und vergleichen Sie die hervorgehobenen Teile der Ausgabe mit den jeweiligen Details in Abbildung 3.3. Sie werden so erkennen, welche Felder Interfaces für welche Geräte auflisten .

Listing 3.1 show cdp -Ausgabe (Beispiel)

SW2# show cdp neighborsCapability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,

D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID

SW1 Gig 0/2 154 S I WS-C2960- Gig 0/1

SW3 Gig 0/1 170 S I WS-C2960- Gig 0/2

R1 Fas 0/10 134 R S I CISCO2901 Gig 0/1

Wenn CDP aktiviert ist, entsteht eine Sicherheitslücke. Um zu verhindern, dass ein Angreifer Kenntnis zu Einzelheiten der vorhandenen Switches erlangt, lässt sich CDP recht einfach deakti-vieren. Cisco empfiehlt die Deaktivierung von CDP auf allen Interfaces, bei denen kein speziel-ler Bedarf daran besteht. Interfaces, bei denen der Einsatz von CDP notwendig ist, sind solche, an die weitere Cisco-Router oder -Switches angeschlossen sind, sowie Interfaces, mit denen IP-Telefone von Cisco verbunden sind. Ansonsten kann CDP je Interface mit dem Interface-Subbefehl no cdp enable deaktiviert werden. (Der Interface-Subbefehl cdp enable aktiviert CDP erneut.) Alternativ können Sie mit dem globalen Befehl no cdp run CDP für den gesamten Switch deaktivieren; der Befehl cdp run reaktiviert CDP dann wieder global .

Schritt 2: Interface-Probleme eingrenzenEin Interface an einem Cisco-Switch muss aktiv sein, damit der Switch Frames, die über dieses Interface empfangen wurden, verarbeiten oder Frames darüber versenden kann . Insofern soll-te ein (durchaus naheliegender) Schritt beim Troubleshooting darin bestehen, den Status der einzelnen Interfaces zu verifizieren. Dies gilt insbesondere für diejenigen Interfaces, von denen man annimmt, dass sie bei der Weiterleitung von Frames verwendet werden; diese sollten darauf geprüft werden, ob sie aktiv sind und funktionieren.

In diesem Abschnitt untersuchen wir die möglichen Interface-Statusfestlegungen bei Cisco-IOS-basierten Switches, führen wesentliche Ursachen für Nichtbetriebszustände auf und behan-deln ein verbreitetes Problem, das auch dann auftritt, wenn das Interface funktionsfähig zu sein scheint. Die wesentlichen Aufgaben für diesen Schritt lassen sich wie folgt zusammenfassen:

Schritt 2: Überprüfen Sie wie folgt auf Interface-Probleme:

a. Bestimmen Sie den oder die Interface-Statuscodes für jedes erforderliche Interface. Befindet sich ein Interface nicht im Status connected (bzw. up/up), so beheben Sie alle Probleme, bis das Interface diesen Status erreicht.

b. Prüfen Sie bei Interfaces, die sich im Status up/up befinden, ferner auf zwei weitere Probleme: Duplex-Mismatches (Fehlanpassungen) und Varianten der Port-Security, bei denen gezielt Frames verworfen werden.

ICND2.indb 94 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 95

3

Statuscodes bei Interfaces und Gründe für NichtbetriebszuständeCisco-Switches verwenden zwei verschiedene Sätze mit Interface-Statuscodes: einen Satz mit zwei Codes (Wörtern), die dieselben Konventionen wie die Statuscodes von Router-Interfaces benutzen, und einen zweiten Satz mit nur aus einem Wort bestehenden Codes. Beide Statuscodegruppen erlauben die Feststellung, ob ein Interface funktioniert.

Die Switch-Befehle show interfaces und show interfaces description führen – wie bei Routern – die Zweiwortcodes auf. Die beiden Codes heißen Line-Status und Protokollstatus und die Codes verweisen jeweils darauf, ob Schicht 1 bzw. Schicht 2 funktioniert. Bei LAN-Switch-Interfaces werden beide Codes entweder als up oder als down angegeben, weil alle Switch-Interfaces dieselben Ethernet-Protokolle für die Sicherungsschicht verwenden, weswegen das Sicherungsschichtprotokoll niemals ein Problem aufweisen sollte.

HINWEIS In diesem Buch werden die beiden Statuscodes verkürzt dargestellt, indem sie lediglich durch einen Schrägstrich voneinander getrennt werden (z. B. up/up).

Der Befehl show interfaces status führt den Interface-Statuscode in der Einwortvariante auf. Ein solcher Code entspricht jeweils einer bestimmten Kombination aus traditionellen Zweiwortcodes. Die Zuordnung der Codes zueinander ist recht trivial. So gibt beispielsweise der Befehl show interfaces status den Status connected für funktionierende Interfaces aus; die-ser entspricht dem Status up/up, wie er mit den Befehlen show interfaces und show interfaces description ermittelt werden kann.

Ein anderer Interface-Status als connected bzw. up/up bedeutet, dass der Switch Frames über dieses Interface weder empfangen noch weiterleiten kann. Für jeden Nichtbetriebsstatus gibt es jeweils einige wenige Ursachen. Beachten Sie außerdem, dass in den Prüfungen durchaus eine Aufgabe auftauchen kann, bei der nur der eine oder andere Statuscode angegeben wird; berei-ten Sie sich also gut auf die Prüfungen vor, indem Sie die Bedeutungen der beiden Interface-Statusscodes gewissenhaft studieren. Tabelle 3.2 führt die Codekombinationen sowie einige Ursachen für den jeweiligen Interface-Status auf .

Tabelle 3.2 Statuscodes für LAN-Switch-Interfaces

Line-Status Protokoll-status

Interface-status

Typische Problemursache

admin. down down disabled Für das Interface wurde der Befehl shutdown konfiguriert.

down down notconnect Fehlendes oder schadhaftes Kabel, falsche Kabelbelegung, Geschwindigkeits-Mismatch bei zwei verbundenen Geräten, abgeschaltetes Gerät oder Interface auf der Gegenseite

up down notconnect Auftreten bei LAN-Switch-Interfaces unwahrscheinlich

Schlüssel-thema

ICND2.indb 95 20.02.14 17:33

96 Kapitel 3: Troubleshooting beim LAN-Switching

Line-Status Protokoll-status

Interface-status

Typische Problemursache

down down (err-disabled)

err-disabled Interfaces durch Port-Security deaktiviert

Bei EtherChannels wird dieser Status für Inter-faces verwendet, deren Konfiguration sich von der anderer Interfaces im EtherChannel unterscheidet.

up up connected Interface ist funktionsfähig .

Der Status notconnect und die KabelbelegungTabelle 3.2 führt verschiedene Gründe dafür auf, dass ein Interface sich im Status notconnect befindet. Viele dieser Gründe bedürfen keiner weiteren Erläuterung: Wenn ein Interface mit einem anderen Switch verbunden ist, gibt der lokale Switch den Status notconnect aus, wenn das Interface auf der anderen Seite der Verbindung abgeschaltet wurde. Einer der Gründe für das Auftreten eines solchen Status – die falsche Kabelbelegung – erfordert jedoch ein wenig mehr Aufmerksamkeit, weil es sich um einen häufig auftretenden Fehler handelt, der zudem an keiner anderen Stelle in diesem Buch behandelt wird. (Die Anschlussbelegung bei Ethernet-Kabeln wird in Kapitel 2 von Cisco CCENT/CCNA ICND1 100-101 beschrieben.)

Die Ethernet-Standards für UTP-Kabel beschreiben die Kontakte des RJ-45-Anschlusses, an die die einzelnen Leitungsdrähte am Kabelende angeschlossen werden müssen. Die Geräte übertragen Signale über Leiterpaare, wobei 10BASE-T und 100BASE-T zwei Paare verwenden: je eines für den Versand und den Empfang. Wenn man zwei Geräte miteinander verbindet, die für den Signalversand dieselben Kontaktpaare verwenden, muss das verwendete Kabel – ein Crossover-Kabel – das Übertragungskontaktpaar des einen Geräts überkreuz mit dem erwar-teten Empfangskontaktpaar des anderen Geräts verbinden. Umgekehrt wird für Kabel, bei dem die Leiterpaare für den Datenversand bereits entgegengesetzt angeordnet sind, ein Straight-Through-Kabel benötigt, welches die Kontakte nicht überkreuz ausführt. Abbildung 3.4 zeigt exemplarisch ein Switch-LAN, in dem die beiden Kabeltypen zum Einsatz kommen.

Gebäude 1

Straight-Through-Kabel

Gebäude 2

Straight-Through-Kabel

Crossover-Kabel

Switch 11

Switch 12

Switch 21

Switch 22

Abbildung 3.4 Crossover- und Straight-Through-Kabel im Einsatz

Für ein effizientes Troubleshooting müssen Sie wissen, welche Geräte über welche Leiterpaare übertragen. Tabelle 3.3 führt im CCNA-Kontext häufiger verwendete Geräte und die zugehö-rigen Paare auf. Beachten Sie, dass, wenn zwei Arten von Geräten in derselben Spalte aneinan-der angeschlossen werden sollen, ein Crossover-Kabel verwendet werden muss, während zur Verbindung zweier Geräte aus verschiedenen Spalten der Tabelle ein Straight-Through-Kabel zum Einsatz kommt.

Schlüssel-thema

ICND2.indb 96 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 97

3

Tabelle 3.3 Von 10BASE-T und 100BASE-T verwendete Kontaktpaare

Geräte, die auf 1,2 senden und auf 3,6 empfangen

Geräte, die auf 3,6 senden und auf 1,2 empfangen

PC-Netzwerkkarten Hubs

Router Switches

WLAN-Access-Points (Ethernet-Interface) –

Netzwerkdrucker (über Ethernet angebunden) –

Switch-Interface-Geschwindigkeit und Duplexmodus bestimmenSwitch-Interfaces ermitteln ihre Geschwindigkeits- und Duplexeinstellungen auf unterschied-liche Weise. Standardmäßig verwenden kupferbasierte Interfaces das Autonegotiating nach IEEE-Standard. Alternativ lassen sich bestimmte Einstellungen an Switch-Interfaces, Routern und den meisten Netzwerkkarten auch gezielt festlegen. Auf Switches und Routern werden diese Werte mit den Interface-Subbefehlen speed {10 | 100 | 1000} bzw. duplex {half | full} festgelegt.

Die Befehle show interfaces und show interfaces status geben auf LAN-Switches die Geschwin digkeits- und Duplexeinstellungen eines Interface an. Listing 3.2 zeigt ein Beispiel.

Listing 3.2 Geschwindigkeits- und Duplexeinstellungen für Switch-Interfaces anzeigen

SW1# show interfaces f0/11 status

Port Name Status Vlan Duplex Speed Type

Fa0/11 link to PC1 connected 3 a-full 100 10/100BaseTX

SW1# show interfaces f0/12 status

Port Name Status Vlan Duplex Speed Type

Fa0/12 link to PC2 connected 3 a-full a-100 10/100BaseTX

SW1# show interfaces fa0/12 FastEthernet0/12 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 1833.9d7b.0e8c (bia 1833.9d7b.0e8c)

Description: link to PC2

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

Keepalive set (10 sec)

Full-duplex, 100Mb/s, media type is 10/100BaseTX

input flow-control is off, output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:01, output hang never

Schlüssel-thema

ICND2.indb 97 20.02.14 17:33

98 Kapitel 3: Troubleshooting beim LAN-Switching

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

1453 packets input, 138334 bytes, 0 no buffer

Received 1418 broadcasts (325 multicasts)

0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 325 multicast, 0 pause input

0 input packets with dribble condition detected

33640 packets output, 2651335 bytes, 0 underruns

0 output errors, 0 collisions, 1 interface resets

0 unknown protocol drops

0 babbles, 0 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

Zwar sind beide Befehle auf ihre Weise hilfreich, doch nur show interfaces status gibt an, wie der Switch Geschwindigkeit und Duplexmodus festgelegt hat. In der Ausgabe sind via Autonegotiating verhandelte Einstellungen durch ein vorangestelltes a- gekennzeichnet. So bedeutet beispielsweise a-full, dass der Vollduplexmodus via Autonegotiating festgelegt wurde, während full auf eine manuelle Konfiguration des Modus verweist. Die in diesem Listing abge-setzten Bereiche zeigen die folgenden Nachweise für die Verwendung des Autonegotiating auf F0/11 und F0/12:

F0/11: 100 Mbit/s infolge der Konfiguration (100 ohne a-), Vollduplexmodus durch Autonegotiating (a-full)F0/12: Beide Werte automatisch ausgehandelt (a-100 und a-full mit dem Präfix a-)

Beachten Sie, dass der Befehl show interfaces Fa0/12 (ohne die Option status) die Geschwin-digkeits- und Duplexeinstellungen aufführt, nicht jedoch, wie der Switch die Werte erlernt oder festgelegt hat.

Probleme bei Geschwindigkeit und DuplexmodusWenn Sie ein Troubleshooting durchführen und das Problem im Bereich der Übertragungs-geschwindigkeit oder des Duplexmodus liegt, kann es sinnvoll sein, sich die Geräte an beiden Seiten der Verbindung anzusehen. Die Geräte müssen nicht dieselben Geschwindigkeits- oder Duplexeinstellungen verwenden, was aber ggf. zu unterschiedlichen Ergebnissen führt:

Geschwindigkeits-Mismatch: Wenn die Endpunkte einer Ethernet-Verbindung unterschied-liche Geschwindigkeiten verwenden, sollten beide den Interface-Status notconnect bzw. down/down anzeigen.

Duplex-Mismatch: Verwenden die Endpunkte dieselbe Geschwindigkeit, aber unter schied-liche Duplexmodi, dann werden die Interfaces zwar aktiviert, aber bestimmte Leistungs-indikatoren werden Probleme auf der Seite der Verbindung melden, die im Halbduplex-modus betrieben wird.

Schlüssel-thema

ICND2.indb 98 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 99

3

Interessanterweise ist es vergleichsweise schwierig, ein Mismatch bei Cisco-Switches über-haupt zu erreichen. Natürlich werden die Geräte auf beiden Seiten der Verbindung, sofern sie das Autonegotiating nutzen, nachfolgend dieselbe Geschwindigkeit verwenden. Wenn das Autonegotiating jedoch auf dem benachbarten Gerät deaktiviert ist, ermittelt und nutzt ein Cisco-Switch auch ohne automatische Aushandlung die richtige Geschwindigkeit – vorausge-setzt, es wurde nicht mithilfe des Befehls speed eine bestimmte Geschwindigkeit voreingestellt. Ist hingegen mit einem speed-Befehl eine solche Geschwindigkeit konfiguriert (z. B. speed 100), dann muss der Switch versuchen, diese Geschwindigkeit zu verwenden.

HINWEIS Bei Cisco-Switches gibt es keinen einzelnen Befehl zur Deaktivierung des IEEE-Autonegotiating, sondern dies ist ein Nebeneffekt der expliziten Konfiguration von Geschwindigkeit und Duplexmodus mithilfe der betreffenden Befehle.

Nehmen wir etwa an, dass das Interface Gi0/2 von SW2 in Abbildung 3.3 mit den Befehlen speed 100 und duplex half konfiguriert wurde (was – nebenbei erwähnt – für ein Gigabit-Interface keine empfehlenswerten Einstellungen sind). SW2 würde diese Einstellungen nun verwenden und das Autonegotiating abschalten, weil beide Befehle – speed und duplex – konfi-guriert wurden. Auch wenn für das Interface Gi0/1 von SW1 (am anderen Ende der Verbindung) kein speed-Befehl konfiguriert wurde, erkennt und verwendet SW1 die Geschwindigkeit (100 Mbit/s), obwohl SW2 kein Autonegotiating einsetzt. Listing 3.3 zeigt die Ergebnisse dieses speziellen Falls auf SW1.

Listing 3.3 Geschwindigkeits- und Duplexeinstellungen für Switch-Interfaces anzeigen

SW1# show interfaces gi0/1 status

Port Name Status Vlan Duplex Speed Type

Gi0/1 Link to SW2 connected trunk a-half a-100 10/100/1000BaseTX

In diesem Listing werden Geschwindigkeit und Duplexeinstellung mit dem Präfix a- angezeigt, was auf das Autonegotiating hindeutet. Grund dafür ist in diesem Fall, dass die Geschwindig-keit automatisch ermittelt und die Duplexeinstellung basierend auf den vom IEEE-Auto-negotiating vorgegebenen Standardwerten gewählt wurde. Die IEEE-Standards legen fest, dass bei Ports mit einer Rate von 100 Mbit/s standardmäßig der Halbduplexmodus gewählt wird, wenn das Autonegotiating fehlschlägt.

Ein Mismatch bei der Geschwindigkeit lässt sich relativ einfach bilden, indem unterschiedliche Geschwindigkeiten auf den Geräten an den beiden Enden der Leitung konfiguriert werden. Sofern die Verbindung aktiviert war (no shutdown), wechselt das Switch-Interface in den Status disabled oder down/down.

Das Feststellen eines Duplex-Mismatch kann wesentlich schwieriger sein als die Erkennung eines Geschwindigkeits-Mismatch, denn das Switch-Interface befindet sich im Status connect (up/up). In diesem Fall funktioniert das Interface zwar, aber seine Performance ist gering und es kann vorübergehend immer wieder zu Problemen kommen.

Ein Duplex-Mismatch auf einem Link führt zu Problemen, weil ein Gerät (die »Halbduplex-seite«) die CSMA/CD-Logik (Carrier Sense Multiple Access With Collision Detection) ver-

ICND2.indb 99 20.02.14 17:33

100 Kapitel 3: Troubleshooting beim LAN-Switching

wendet, das andere hingegen nicht. Die Halbduplexseite wartet vor dem Versenden auf den Empfang eines Frames. Dabei geht die Halbduplexseite davon aus, dass, wenn sie gerade sendet und dann ein Frame empfangen wird, es zu einer Kollision gekommen ist – woraufhin das Gerät den aktuellen Sendevorgang sofort abbricht. Das Vollduplexgerät hingegen sendet Frames jeder-zeit, weswegen das Halbduplexgerät irrtümlich davon ausgeht, dass Kollisionen stattfinden. Ist die Netzbelastung ausreichend hoch, dann befindet sich das Interface zwar im Status connected, ist aber für die Weiterleitung von Daten weitgehend nutzlos und zudem sogar für den Verlust wichtiger STP-Nachrichten verantwortlich .

Probieren Sie Folgendes aus, um Duplex-Mismatches zu erkennen:

Verwenden Sie Befehle wie show interfaces an beiden Enden der Verbindung, um die jewei-ligen Duplexeinstellungen zu kontrollieren.

Überprüfen Sie bestimmte Zähler bei Halbduplexinterfaces auf steigende Werte. Die ent-sprechenden Ereignisse – Runts, Kollisionen und späte Kollisionen – treten auf, wenn das andere Gerät den Vollduplexmodus verwendet. (Beachten Sie jedoch, dass die Zähler auch bei normalen Kollisionen hochgezählt werden.)

In Listing 3.2 weiter vorn sind diese Zähler in der Ausgabe des Befehls show interfaces hervor-gehoben.

Die Ursache für Duplex-Mismatches kann durch die Voreinstellungen bedingt sein, die beim IEEE-Autonegotiating ausgewählt werden. Wenn ein Gerät versucht, das Autonegotiating durchzuführen, und kein anderes Gerät reagiert, wählt das erste Gerät die Standardeinstellung für den Duplexmodus basierend auf der aktuellen Geschwindigkeit aus. Nach Vorgabe des IEEE werden standardmäßig die folgenden Einstellungen gewählt:

Liegt die Datenrate bei 10 oder 100 Mbit/s, dann wird standardmäßig der Halbduplex-modus festgelegt.

Liegt die Datenrate bei 1.000 Mbit/s, dann wird standardmäßig der Vollduplexmodus fest-gelegt.

HINWEIS Ethernet-Interfaces , die schneller als 1 Gbit/s sind, verwenden grundsätzlich den Vollduplexmodus.

Schritt 3: Probleme in Zusammenhang mit Filterung und Port-Security behebenAllgemein gesagt sollte jede Analyse des Weiterleitungsprozesses auch alle Sicherheitsfunk -tionen in Betracht ziehen, durch die Frames oder Pakete verworfen werden könnten. So können etwa sowohl für Router als auch für Switches ACLs (Access Control Lists, Zugriffs steue-rungslisten) konfiguriert werden, die Pakete und Frames, die über ein Interface gesendet oder dort empfangen werden, untersuchen und ggf. verwerfen.

Switch-ACLs sind nicht Gegenstand der CCNA-Prüfungen, wohl aber eine ähnliche Switch-Funktionalität namens Port-Security. Wie in Kapitel 8 des offiziellen Handbuchs CCENT/CCNA ICND1 100-101 beschrieben, ist es Aufgabe von Port-Security, dafür zu sorgen, dass der Switch bestimmte Frames verwirft, die über ein bestimmtes Interface eingehen oder versen-

Schlüssel-thema

Schlüssel-thema

ICND2.indb 100 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 101

3

det werden. Die Port-Security bietet drei Grundfunktionen, mit denen festgelegt werden kann, welche Frames gefiltert werden sollen:

Sie kann festlegen, welche MAC-Adressen Frames über ein Switch-Interface versenden und empfangen können. Frames von oder an andere MAC-Adressen werden verworfen.

Sie kann die Anzahl der MAC-Adressen begrenzen, die das Interface verwenden dürfen. Frames von oder an MAC-Adressen, die nach Erreichen des Höchstwerts erlernt wurden, werden verworfen.

Die beiden vorgenannten Punkte können auch kombiniert werden.

Der erste Schritt beim Troubleshooting in Verbindung mit der Port-Security besteht darin, herauszufinden, für welche Interfaces die Port-Security aktiviert ist. Danach wird geprüft, ob gegenwärtig Verstöße auftreten. Der kniffligste Teil bezieht sich auf unterschiedliche Reaktionen des IOS auf Verstöße basierend auf dem Interface-Subbefehl switchport port-security violation violation-modus; dieser Befehl bezeichnet dem Switch gegenüber, was zu tun ist, wenn eine Violation (Verstoß) festgestellt wird. Generell sieht die Syntax wie folgt aus:

Schritt 3: Überprüfen Sie wie folgt auf Port-Security-Probleme:

a. Ermitteln Sie mit show running-config oder show port-security alle Interfaces, für die die Port-Security aktiviert wurde.

b. Ermitteln Sie , ob gegenwärtig ein Sicherheitsverstoß im Sinne des in der Port-Security-Konfiguration angegebenen Parameters violation-modus erfolgt:

I. shutdown: Das Interface befindet sich im Status err-disabled.

II. restrict: Das Interface befindet sich im Status connect, aber der Befehl show port-security interface zeigt einen ansteigenden Wert für den Violation-Zähler.

III. protect: Das Interface befindet sich im Status connect und der Befehl show port-security interface zeigt keinen ansteigenden Wert für den Violation-Zähler.

c. Vergleichen Sie in jedem Fall die Port-Security-Konfiguration mit dem Diagramm und mit dem Feld Last Source Address in der Ausgabe des Befehls show port-security interface .

Eine der Schwierigkeiten bei der Behebung von Port-Security-Problemen ist der Tatsache geschuldet, dass bestimmte Port-Security-Konfigurationen – ebenfalls basierend auf dem kon-figurierten Violation-Modus – nur abzuweisende Frames verwerfen, das Interface jedoch nicht deaktivieren. Alle drei Violation-Modi verwerfen Daten entsprechend der Konfiguration .

Wenn beispielsweise nur die vordefinierte MAC-Adresse 0200.1111.1111 zulässig ist, verwirft der Switch an diesem Interface alle Daten, die nicht von 0200.1111.1111 stammen bzw. an diese MAC-Adresse gerichtet sind. Sollte ein Verstoß gegen die Richtlinien auftreten, so bewirkt der Modus shutdown, dass nachfolgend alle weiteren Daten verworfen werden – auch die von oder an die Adresse 0200.1111.1111. Tabelle 3.4 fasst einige dieser Schlüsselpunkte der Übersicht halber zusammen.

ICND2.indb 101 20.02.14 17:33

102 Kapitel 3: Troubleshooting beim LAN-Switching

Tabelle 3.4 Aktionen bei Port-Security-Verstößen

Option des Befehls switchport port-security violation

Protect Restrict Shut Down*

Verwirft unzulässigen Datenverkehr Ja Ja Ja

Deaktiviert das Interface und verwirft den gesamten Datenverkehr

Nein Nein Ja

Erhöht den Violation-Zähler bei jedem unzulässigen Frame

Nein Ja Ja

* Shut down ist die Standardeinstellung.

Schritt 3b des obigen Troubleshooting-Ablaufs bezieht sich auf den Interface-Status err-disab-led (deaktiviert wegen Fehler). Dieser Status stellt sicher, dass das Interface für die Verwendung der Port-Security konfiguriert wurde, eine Violation stattgefunden hat und zum gegenwärtigen Zeitpunkt keine Daten über das Interface gelangen. Er impliziert zudem, dass der Violation-Modus shutdown verwendet wird, denn dies ist der einzige der drei Port-Security-Modi, der eine Abschaltung des Interface bewirkt.

Um diesen Status wieder aufzuheben, muss das Interface mit dem Befehl shutdown zunächst deaktiviert und dann mit no shutdown wieder aktiviert werden . Listing 3.4 zeigt ein Beispiel, in dem sich das Interface im Status err-disabled befindet .

Listing 3.4 Port-Security zur Definition korrekter MAC-Adressen für bestimmte Interfaces verwenden

! Der erste Befehl gibt alle Interfaces, auf denen Port-Security aktiviert wurde,

! sowie den Violation-Modus unter der Überschrift "Security Action" an.

SW1# show port-securitySecure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action

(Count) (Count) (Count)

---------------------------------------------------------------------------

Fa0/13 1 1 1 Shutdown

---------------------------------------------------------------------------

Total Addresses in System (excluding one mac per port) : 0

Max Addresses limit in System (excluding one mac per port) : 8192

!

! Der nächste Befehl zeigt den Status "err-disabled" an, was einen Sicherheitsverstoß impliziert.

SW1# show interfaces Fa0/13 status

Port Name Status Vlan Duplex Speed Type

Fa0/13 err-disabled 1 auto auto 10/100BaseTX

!

! In der Ausgabe des nächsten Befehls sind die wichtigsten Details abgesetzt dargestellt.

SW1# show port-security interface Fa0/13Port Security : Enabled

Schlüssel-thema

ICND2.indb 102 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 103

3

Port Status : Secure-shutdown

Violation Mode : Shutdown

Aging Time : 0 mins

Aging Type : Absolut

SecureStatic Address Aging : Disabled

Maximum MAC Addresses : 1

Total MAC Addresses : 1

Configured MAC Addresses : 1

Sticky MAC Addresses : 0

Last Source Address:Vlan : 0200.3333.3333:2

Security Violation Count : 1

Die Ausgabe von show port-security interface enthält einige Elemente, die beim Trouble-shooting hilfreich sein können. Der Portstatus secure-shutdown bedeutet, dass das Interface infolge eines Verstoßes für den gesamten Datenverkehr gesperrt und der Interface-Status err-disabled zugewiesen wird. Am Ende der Befehlsausgabe wird ein Violation-Zähler aufgeführt, der für jeden neuen Verstoß um 1 erhöht wird. Interessanterweise bewirkt ein Verstoß im shutdown-Modus, dass der Zähler um 1 erhöht und das Interface in den Status err-disabled versetzt wird, weswegen der Zähler nachfolgend erst dann wieder hochgezählt werden kann, wenn der Netzwerktechniker für das Interface nacheinander die Befehle shutdown und no shutdown absetzt.

Beachten Sie schließlich, dass in der zweitletzten Zeile die Absender-MAC-Adresse des letzten über das Interface empfangenen Frames angezeigt wird. Dieser Wert kann nützlich sein, um die MAC-Adresse des Geräts zu ermitteln, das den Verstoß verursacht hat.

Zu einem weiteren Beispiel: Auch die Violation-Modi restrict und protect bewirken das Verwerfen von Frames, wenn auch mit einem ganz anderen Verhalten. Bei diesen Violation-Modi verbleibt das Interface im Status connected (up/up), obwohl unzulässige Frames aufgrund der Port-Security weiterhin verworfen werden. Denken Sie also stets daran, dass bei einem Interface mit dem Status connected oder up/up auch andere Gründe für eine Nichtweiterleitung von Daten vorliegen können.

Listing 3.5 zeigt eine Beispielkonfiguration und eine show-Ausgabe bei Verwendung des protect-Modus . In diesem Fall schickt ein PC mit der MAC-Adresse 0200.3333.3333 Frames an Port Fa0/13. Dieser Port ist jedoch auf den Empfang von Frames beschränkt, die von 0200.1111.1111 übermittelt wurden.

Listing 3.5 Port-Security im protect-Modus

SW1# show running-config! Zeilen aus Platzgründen gekürzt

interface FastEthernet0/13

switchport mode access

switchport port-security

switchport port-security mac-address 0200.1111.1111

switchport port-security violation protect

! Zeilen aus Platzgründen gekürzt

ICND2.indb 103 20.02.14 17:33

104 Kapitel 3: Troubleshooting beim LAN-Switching

SW1# show port-security interface Fa0/13Port Security : Enabled

Port Status : Secure-up

Violation Mode : Protect

Aging Time : 0 mins

Aging Type : Absolut

SecureStatic Address Aging : Disabled

Maximum MAC Addresses : 1

Total MAC Addresses : 1

Configured MAC Addresses : 1

Sticky MAC Addresses : 0

Last Source Address:Vlan : 0200.3333.3333:1

Security Violation Count : 0

Diese Ausgabe des show-Befehls wurde erstellt, nachdem bereits eine Reihe von Frames von dem PC mit der MAC-Adresse 0200.3333.3333 geschickt wurden. Aufgrund der Port-Security-Konfiguration wurden alle diese Frames verworfen. Die Befehlsausgabe zeigt die MAC-Adresse 0200.3333.3333 des unzulässigen PCs als Absender-MAC-Adresse des zuletzt empfangenen Frames an. Beachten Sie jedoch, dass der Portstatus secure-up aufgeführt ist und der Violation-Zähler den Wert 0 hat; diese beiden Angaben könnten von Ihnen dahingehend interpretiert wer-den, dass alles in Ordnung ist. Allerdings zeigt der Befehl show port-security interface im pro-tect-Modus keine Informationen an, mit denen Sie sich vergewissern können, dass tatsächlich ein Verstoß stattgefunden hat. Der einzige Hinweis besteht darin, dass die Endbenutzerdaten nicht dahin gelangen, wohin sie sollen.

Wäre in diesem Beispiel der Violation-Modus restrict verwendet worden, dann wäre ebenfalls der Portstatus secure-up angezeigt worden, aber der Violation-Zähler wäre pro unzulässigem Frame um den Wert 1 erhöht worden.

Bei den Prüfungen kann ein Port-Security-Verstoß durchaus kein Problem, sondern vielmehr die gewünschte Funktion darstellen. Möglicherweise gibt der Aufgabentext ausdrücklich an, was genau die Port-Security tun sollte. In solchen Fällen können Sie die Aufgabe schneller lösen, indem Sie sofort einen Blick auf die Port-Security-Konfiguration werfen. Vergleichen Sie die Konfiguration dann mit den MAC-Adressen der an das Interface angeschlossenen Geräte. Das wahrscheinlichste Problem besteht bei den Prüfungsaufgaben darin, dass die MAC-Adressen fehlkonfiguriert wurden oder die Höchstanzahl der MAC-Adressen zu gering eingestellt wurde.

Die folgende Liste fasst die Schritte zur Port-Security-Konfiguration, die wir in Kapitel 8 des ICND1-Buchs bereits gesehen haben, noch einmal zusammen:

Schritt 1: Konfigurieren Sie das Switch-Interface mit den Interface-Subbefehlen switchport mode access bzw. switchport mode trunk wahlweise als Access- oder Trunk-Interface .

Schritt 2: Aktivieren Sie die Port-Security mit dem Interface-Subbefehl switchport port-security.

Schritt 3: (optional) Überschreiben Sie mit dem Interface-Subbefehl switchport port-security maximum nummer die standardmäßig festgelegte maximale Anzahl zulässiger MAC-Adressen für das Interface (1).

Schlüssel-thema

ICND2.indb 104 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 105

3

Schritt 4: (optional) Überschreiben Sie die Standardaktion beim Auftreten eines Sicher-heits verstoßes (shutdown) mit dem Interface-Subbefehl switchport port-security violation {protect | restrict | shutdown}.

Schritt 5: (optional) Definieren Sie die zulässigen Absender-MAC-Adressen für das Inter face mit dem Befehl switchport port-security mac-address mac-adresse. Um mehrere MAC-Adressen zu definieren, verwenden Sie den Befehl mehrfach.

Schritt 6: (optional) Weisen Sie den Switch mit dem Interface-Subbefehl switchport port-security mac-address sticky an, unter Verwendung von Sticky-Learning MAC-Adressen dynamisch zu erlernen .

Schritt 4: VLAN- und Trunking-spezifische Probleme behebenDer Weiterleitungsprozess eines Switchs hängt sowohl von der Definition der Access-VLANs an den Access-Interfaces als auch von den VLAN-Trunks ab, die Daten für mehrere VLANs weiterleiten. Außerdem muss ein Switch, um Frames in ein bestimmtes VLAN weiterzuleiten, dieses VLAN erst einmal – entweder über die Konfiguration oder via VTP – kennengelernt haben und das VLAN muss auch aktiv sein. Die folgenden Abschnitte beschreiben einige wich-tige Werkzeuge in Zusammenhang mit VLAN-Problemen. Dieser Schritt umfasst die folgenden Maßnahmen:

Schritt 4: Überprüfen Sie VLANs und VLAN-Trunks wie folgt:

a. Ermitteln Sie alle Access-Interfaces und die ihnen zugewiesenen VLANs und korrigieren Sie bei Bedarf die VLAN-Zuweisung.

b. Bestimmen Sie, ob die VLANs sowohl vorhanden sind (dies kann via Konfiguration oder mithilfe von VTP geschehen) als auch auf dem jeweiligen Switch aktiv sind. Sollte dies nicht der Fall sein, so konfigurieren und aktivie-ren Sie nach Bedarf die VLANs, um Probleme zu beheben.

c. Ermitteln Sie betriebsbereite Trunking-Interfaces an jedem Switch und bekom-men Sie heraus, welche VLANs über die jeweiligen Trunks weitergeleitet wer-den können.

Die nächsten drei Abschnitte beschreiben die Schritte 4a, 4b und 4c im Detail.

Sicherstellen, dass die richtigen Access-Interfaces sich in den richtigen VLANs befindenUm zu gewährleisten, dass jedes Access-Interface dem richtigen VLAN zugewiesen wurde, muss der Netzwerktechniker lediglich feststellen, welche Switch-Ports Access-Interfaces (und nicht Trunk-Interfaces) sind, die zugehörigen Access-VLANs auf jedem Interface ermitteln und die gewonnenen Erkenntnisse mit der Dokumentation vergleichen. Die in Tabelle 3.5 aufgeführ-ten show-Befehle können dabei recht hilfreich sein.

ICND2.indb 105 20.02.14 17:33

106 Kapitel 3: Troubleshooting beim LAN-Switching

Tabelle 3.5 Befehle zum Ermitteln von Access-Ports und VLANs

EXEC-Befehl Beschreibung

show vlan Führt alle VLANs und alle den VLANs jeweils zugeordneten Interfaces auf, gibt aber keine Trunks an

show vlan brief Gibt eine kürzere Version derselben Informationen wie der Befehl show vlan aus

show vlan id num Listet Access-Ports für das betreffende VLAN auf

show interfaces typ nummer switchport

Ermittelt am Interface vorhandene Access- und Voice-VLANs sowie den konfigurierten und den Betriebsmodus (Access oder Trunk)

show mac address-table dynamic

Listet MAC-Tabelleneinträge auf, d. h. MAC-Adressen mit zugehörigen Interfaces und VLANs

Falls möglich, beginnen Sie diesen Schritt mit den Befehlen show vlan und show vlan brief, denn diese listen alle bekannten VLANs sowie die ihnen jeweils zugewiesenen Access-Interfaces auf. Beachten Sie jedoch, dass die Ausgabe dieser Befehle viele, aber nicht alle Interfaces ent-hält; vor allem geben diese Befehle Folgendes aus:

Interfaces, die gegenwärtig nicht als Trunks betrieben werden, Interfaces mit beliebigem Interface-Status einschließlich notconnect und err-disabled.

So können diese Befehle etwa das Interface Gi0/2 in der Liste der Interfaces in VLAN 1 enthal-ten, wenn G0/2 kein Trunking-Interface ist; sobald jedoch Gi0/2 aktiv wird, könnte das Interface mit Trunking-Verhandlungen beginnen und wäre von nun an kein Access-Interface mehr, weswe-gen es nachfolgend in der Ausgabe von show vlan brief auch nicht mehr auftauchte.

Wenn die Befehle show vlan und show interface switchport bei einer bestimmten Prüfungs-aufgabe nicht verfügbar sind, können Sie das Access-VLAN auch mit dem Befehl show mac address-table ermitteln. Dieser Befehl listet die MAC-Adresstabelle auf, und zwar jeden Eintrag mit MAC-Adresse, Interface und VLAN-ID. Wenn die Prüfungsaufgabe impliziert, dass ein Switch-Interface an einen Einzel-PC angeschlossen ist, sollte nur ein einzelner MAC-Tabelleneintrag aufgeführt sein, der genau dieses Access-Interface auflistet; die für diesen Eintrag angegebene VLAN-ID bezeichnet das Access-VLAN. (Bei Trunking-Interfaces sind derartige Annahmen jedoch nicht möglich.)

Nachdem Sie Access-Interfaces und zugehörige VLANs ermittelt haben, verwenden Sie, wenn das Interface dem falschen VLAN zugeordnet ist, den Interface-Subbefehl switchport access vlan vlan-id zur Zuordnung der korrekten VLAN-ID.

Schlüssel-thema

ICND2.indb 106 20.02.14 17:33

3.2 Troubleshooting bei der LAN-Switching-Data-Plane 107

3

Nicht definierte oder inaktive Access-VLANsEin Switch leitet einen Frame in einem VLAN x nicht weiter, wenn

der Switch über keine Definition für das VLAN x (beispielsweise über den Befehl vlan x) verfügt,

das VLAN x auf dem Switch vorhanden, aber deaktiviert ist (shutdown).

Der nächste Troubleshooting-Schritt 4b ist eine Erinnerung, um sicherzustellen, dass jeder Switch über eine Definition für das VLAN verfügt und nicht beendet wurde.

Switches wissen normalerweise über die Existenz eines VLAN Bescheid, weil sie entweder via VTP davon erfahren oder lokal entsprechend konfiguriert wurden. Für die Zwecke dieses Buchs wollen wir annehmen, dass VTP deaktiviert oder in den transparenten Modus versetzt wurde. Deswegen müssen in unserem Szenario alle Switches mit dem Befehl vlan x konfiguriert worden sein, um das VLAN mit der Nummer x zu unterstützen.

Beide Probleme lassen sich der Ausgabe der Befehle show vlan oder show vlan brief ganz ein fach entnehmen. Ist das VLAN auf dem Switch nicht vorhanden, dann ist es in der Befehls-ausgabe schlicht nicht angegeben; in diesem Fall müssen Sie das VLAN mit dem Konfigura-tionsbefehl vlan vlan-id hinzufügen. Wird es hingegen angezeigt, dann ist als Status active oder act/lshut aufgeführt. Der zweite Wert gibt an, dass das VLAN beendet wurde. Um dieses Problem zu beheben, setzen Sie den globalen Konfigurationsbefehl no shutdown vlan vlan-id ab.

Trunks und darüber weitergeleitete VLANs ermittelnIn Schritt 4c können Sie die Probleme zu Beginn der Eingrenzung in zwei allgemeine Kategorien unterteilen : Probleme in Bezug auf die Funktionsweise eines betriebsbereiten Trunks und Probleme, die dadurch verursacht werden, dass ein Interface, das ein Trunk-Interface sein sollte, nicht als solches agiert.

Die erste Kategorie in diesem Schritt kann relativ leicht mit dem Befehl show interfaces trunk ermittelt werden, denn in der Ausgabe sind nur Informationen zu gegenwärtig betriebsfähigen Trunks enthalten. Am besten beginnen Sie die Durchsicht im letzten Abschnitt der Ausgabe, denn dort sind VLANs aufgeführt, deren Daten über den Trunk weitergeleitet werden. VLANs, die es bis in diese abschließende VLAN-Liste schaffen, weisen die folgenden Kriterien auf:

Das VLAN ist auf dem lokalen Switch vorhanden und aktiv (in dem Sinne wie im vorherigen Abschnitt beschrieben und über den Befehl show vlan ermittelbar).

Das VLAN wurde nicht aus der Liste der zulässigen VLANs auf dem Trunk entfernt, die mit dem Interface-Subbefehl switchport trunk allowed vlan konfiguriert wurde.

Das VLAN wurde nicht via VTP-Pruning aus dem Trunk entfernt . (Diese VTP-Funktion wird in diesem Abschnitt eigentlich ignoriert; sie ist hier nur aufgeführt, weil sie in der Ausgabe des show-Befehls erwähnt wird.)

Der Trunk befindet sich in diesem LAN im STP-Forwarding-Status. Dies geht auch aus der Ausgabe des Befehls show spanning-tree vlan vlan-id hervor.

Listing 3.6 zeigt exemplarisch eine Ausgabe des Befehls show interfaces trunk . Der für uns relevante letzte Teil der Ausgabe ist hervorgehoben. In diesem Fall leitet der Trunk Daten nur in den VLANs 1 und 4 weiter.

ICND2.indb 107 20.02.14 17:33

108 Kapitel 3: Troubleshooting beim LAN-Switching

Listing 3.6 Listen zulässiger und aktiver VLANs

SW1# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Gi0/1 desirable 802.1q trunking 1

Port Vlans allowed on trunk

Gi0/1 1-2,4-4094

Port Vlans allowed and active in management domain

Gi0/1 1,4

Port Vlans in spanning tree forwarding state and not pruned

Gi0/1 1,4

Das Fehlen eines VLAN in diesem letzten Teil der Befehlsausgabe muss nicht auf ein Problem hinweisen. Ein VLAN kann vielmehr durchaus aus einem Trunk ausgeschlossen werden, wenn irgendeiner der vor Listing 3.6 aufgeführten Gründe vorliegt. Allerdings kann es bei einer Prüfungsaufgabe durchaus sinnvoll sein, zu wissen, warum Daten für ein VLAN nicht über einen Trunk weitergeleitet werden. Die Details in der Ausgabe nennen die jeweiligen Gründe.

Die Ausgabe des Befehls show interfaces trunk enthält drei getrennte Listen mit VLANs, die jeweils unter einer eigenen Überschrift stehen. Diese drei Listen zeigen in »fortschreitender« Form, warum ein VLAN ggf. nicht über einen Trunk weitergeleitet wird. Tabelle 3.6 fasst die Überschriften vor den einzelnen Listen und die Gründe dafür zusammen, warum ein VLAN vom Switch zur Liste hinzugefügt (oder eben nicht hinzugefügt) wird.

Tabelle 3.6 VLAN-Listen in der Ausgabe von show interfaces trunk

Listenposition Überschrift Grund

Erste VLANs allowed VLANs 1-4094 abzüglich jener, die mit dem Befehl switchport trunk allowed entfernt wurden

Zweite VLANs allowed and active …

Entspricht der ersten Liste abzüglich jener VLANs, die entweder auf dem lokalen Switch nicht definiert sind oder sich im Modus shutdown befinden

Dritte VLANs in spanning tree…

Entspricht der zweiten Liste abzüglich der durch STP geblockten und der durch VTP entfernten Interfaces

Bevor wir mit dem nächsten Thema fortfahren, sollten Sie an dieser Stelle auch die Konfigura-tion des nativen VLAN eines Trunks überprüfen. Die ID des nativen VLAN kann an beiden Enden des Trunks mit dem Befehl switchport trunk native vlan vlan-id manuell auf unter-schiedliche VLANs gesetzt werden. Wenn die nativen VLANs sich unterscheiden, verlassen die Frames das eine VLAN und gelangen in ein anderes, was nicht beabsichtigt ist.

Wenn also etwa Switch SW1 einen Frame über das native VLAN 1 an einen 802.1Q-Trunk sen-det, fügt er keinen VLAN-Header hinzu, da es sich ja um das native VLAN handelt. Empfängt nun Switch SW2 den Frame, so stellt er das Fehlen des 802.1Q-Headers fest und geht davon

Schlüssel-thema

ICND2.indb 108 20.02.14 17:33

3.3 Beispiele und Übungen zum Troubleshooting 109

3

aus, dass der Frame zum für SW2 konfigurierten nativen VLAN gehört. Wurde für SW2 jedoch VLAN 2 als natives VLAN dieses Trunks konfiguriert, dann versucht SW2, den empfangenen Frame an VLAN 2 weiterzuleiten.

Abschließend prüfen Sie auf Links, bei denen das Trunking vorhanden sein sollte, aber nicht ist. Die wahrscheinlichste Ursache dieses Problems ist eine unterschiedliche Trunking-Konfigura-tion an beiden Enden der Verbindung. Mit dem Interface-Subbefehl switchport mode{access | trunk | dynamic {desirable | auto}} legen Sie fest, ob das Trunking für das Interface aktiviert und auf der Basis welcher Regeln es verhandelt werden soll. Mit dem Befehl show interface switchport zeigen Sie für jedes Interface den konfigurierten Trunking-Modus an .

Stellen Sie sicher, dass Sie die Bedeutung aller Optionen dieses Konfigurationsbefehls ken-nen. Eine besonders problematische Kombination ist die Verwendung von dynamic auto an beiden Enden; nichtsdestoweniger ist dies bei einigen Cisco-Switches die Default-Einstellung. Bei dieser Einstellung wird das Trunking von beiden Enden ausgehandelt – wenn die jeweilige Gegenstelle den Vorgang startet. Und aus diesem Grund warten beide für immer und bilden niemals einen Trunk. Tabelle 3.7 zeigt die Optionen des Befehls switchport trunk mode und den Trunking-Modus an, der jeweils am Ende aktiviert werden sollte.

Tabelle 3.7 Konfigurierter Administrativmodus und zu erwartender Trunking-Betriebsmodus

Administrativmodus Access Dynamic Auto Trunk Dynamic Desirable

access Access Access Access Access

dynamic auto Access Access Trunk Trunk

trunk Access Trunk Trunk Trunk

dynamic desirable Access Trunk Trunk Trunk

In einigen Fällen misslingt das Trunking für ein Interface aufgrund eines fehlkonfigurierten Trunking-Typs (ISL oder 802.1Q). Wenn beispielsweise beim Switch am einen Ende eines Segments der Befehl switchport trunk encapsulation isl und beim Switch am anderen Ende switchport trunk encapsulation dot1Q konfiguriert wurde, wird kein Trunk gebildet, weil die Trunking-Typen (d. h. die Kapselung) nicht zueinander passen .

3.3 Beispiele und Übungen zum TroubleshootingDer verbleibende Teil dieses Kapitels ist sehr praxisorientiert. Sie müssen sich an dieser Stelle entscheiden, ob Sie Ihre Studien durch Weiterlesen oder Beantworten der Fragen vor dem Weiterlesen fortsetzen oder aber bereits wissen, wie Sie den Stoff in diesem Kapitel praktisch anwenden, und folglich beim nächsten Kapitel fortfahren.

Im weiteren Verlauf dieses Kapitels werden zwei umfangreichere Beispiele der Anwendung von Troubleshooting-Konzepten und -Prozessen in LANs gezeigt. Im ersten Beispiel finden Sie ein LAN und eine Menge show-Befehle vor. In diesem LAN sind Konfigurationsprobleme aufge-treten. Von diesem Szenario ausgehend werden mithilfe des in diesem Kapitel beschriebenen, vier Schritte umfassenden Prozesses die Probleme zunächst eingegrenzt und dann ihre Ursachen ermittelt.

Schlüssel-thema

ICND2.indb 109 20.02.14 17:33

110 Kapitel 3: Troubleshooting beim LAN-Switching

Im zweiten Beispiel verwenden wir dasselbe LAN wie im ersten, wobei hier alle Probleme beho-ben sind. Dort werden wir uns die Frage stellen, wie genau die Frames in diesem LAN fließen. Auch im zweiten Beispiel werden wir dies anhand einer Vielzahl von show-Befehlen ermitteln.

Das Troubleshooting ist eine Fertigkeit und mit diesen Beispielen sollen Sie diese Fertigkeit fortentwickeln. Eine spezielle Fähigkeit besteht darin, die umfangreiche Ausgabe eines show-Befehls zu studieren und dessen Auswirkungen auf ein Netzwerkdiagramm zu übertragen. In den beiden folgenden Beispielen werden nach letztem Stand insgesamt 34 show-Befehle auf-geführt. Dies sind die letzten LAN-spezifischen Themen Ihres CCNA-Studiums und sie fassen viele von Ihnen bereits erlernte Konzepte zusammen. Sie werden danach einschätzen können, wie gut Ihr Know-how im Bereich der Ethernet-LAN-Technologien ist. Der Kreis schließt sich.

Troubleshooting-Beispiel 1: Probleme auf der LAN-Data-Plane suchenIm ersten Beispiel finden Sie ein Netzwerkdiagramm und eine Reihe von Listings mit show-Befehlen vor. Der Umfang dieses Beispiels beträgt etwa zwölf Buchseiten. Sie können das Beispiel auf zweierlei Weise nutzen:

Zur Anschauung: In diesem Fall lesen Sie einfach ganz normal weiter. Als Übung: Betrachten Sie die Abbildungen und Listings, versuchen Sie, alle Probleme

zu ermitteln, und entwickeln Sie einen Plan zu ihrer Behebung. Sehen Sie sich vor allem Abbildung 3.5 an und studieren Sie die Listings 3.7 bis 3.14. Ignorieren Sie den Text ebenso wie Abbildung 3.6 am Ende des Beispiels. Ermitteln Sie beim Lesen der Listings möglichst viele Probleme, die Sie durch Analyse der Befehlsausgabe und Vergleich mit der Abbildung ermitteln können. Vergleichen Sie Ihre Liste mit der am Ende des Kapitels aufgeführten. (Sie ist dort versteckt, um zu verhindern, dass Sie die Antworten versehentlich erspähen.) Danach können Sie den Begleittext zu den Listings lesen, wenn Sie Lücken im Troubleshooting-Beispiel schließen möchten.

Gi0/1Fa0/11

Gi0/1 Fa0/10Gi0/2Fa0/12

2.2.2.10200.1111.1111

2.2.2.20200.2222.2222

2.2.2.30200.3333.3333

0200.0101.0101Gi0/2 Gi0/1

Gi0/1 Gi0/2

Fa0/13

R1

PC1

PC3

PC2 SW1 SW2

SW3

2.2.2.9

Abbildung 3.5 Netzwerkdiagramm als Ausgangspunkt für das Troubleshooting-Beispiel 1

ICND2.indb 110 20.02.14 17:33

3.3 Beispiele und Übungen zum Troubleshooting 111

3

Das Beispiel beschreibt die Vorgehensweise beim Untersuchen des in Abbildung 3.5 gezeigten Netzwerks unter Verwendung der Ausgabe verschiedener show-Befehle. Der Text orientiert sich an der vier Schritte umfassenden Methodik, die wir im vorangegangenen Abschnitt des Kapitels beschrieben haben. Zu Beginn dieses Abschnitts fassen wir noch einmal die Schritte beim Troubleshooting zusammen, die wir oben im Abschnitt »Der normale Weiterleitungsprozess bei LAN-Switches in der Übersicht« ausführlich behandelt haben.

Wenn Sie das folgende Troubleshooting-Beispiel zur Übung durcharbeiten, können Sie den nachfolgenden Text zunächst ignorieren. Beginnen Sie mit der Analyse der Listings und suchen Sie dort nach Problemen. Nutzen Sie das Beispiel hingegen zur Anschauung, dann lesen Sie einfach weiter.

Schritt 1: Richtigkeit des Diagramms mit CDP verifizierenListing 3.7 zeigt einen Großteil der Befehlsausgabe von show cdp neighbors und show cdp entry auf den drei in Abbildung 3.5 gezeigten Switches. Durch einen einfachen Vergleich lassen sich die Namen und Interfaces in der Abbildung überprüfen. Die einzige Abweichung besteht darin, dass auf SW2 das Interface Fa0/9 und nicht – wie in der Abbildung gezeigt – das Interface Fa0/10 an den Router R1 angeschlossen ist.

Listing 3.7 Abbildung 3.5 mit CDP verifizieren

SW1# show cdp neighborsCapability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,

D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID

SW2 Gig 0/1 170 S I WS-C2960- Gig 0/2

SW3 Gig 0/2 167 S I WS-C2960- Gig 0/1

! Es folgen die Befehle für SW2

SW2# show cdp neighbors Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,

D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID

SW1 Gig 0/2 146 S I WS-C2960- Gig 0/1

SW3 Gig 0/1 162 S I WS-C2960- Gig 0/2

R1 Fas 0/9 139 R S I CISCO2901 Gig 0/1

SW2# show cdp entry R1-------------------------

Device ID: R1

Entry address(es):

IP-Adresse: 2.2.2.9

Plattform. Cisco CISCO2901/K9, Capabilities: Router Switch IGMP

Interface: FastEthernet0/9, Port ID (outgoing port): GigabitEthernet0/1

Holdtime : 148 sec

ICND2.indb 111 20.02.14 17:33

112 Kapitel 3: Troubleshooting beim LAN-Switching

Version :

Cisco IOS Software, C2900 Software (C2900-UNIVERSALK9-M), Version 15.2(4)M1, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2012 by Cisco Systems, Inc.

Compiled Thu 26-Jul-12 20:54 by prod_rel_team

advertisement version: 2

VTP Management Domain: ''

Duplex: full

Management address(es):

! Es folgen die Befehle für SW3

SW3# show cdp neighborsCapability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge

S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,

D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID

SW1 Gig 0/1 167 S I WS-C2960- Gig 0/2

SW2 Gig 0/2 176 S I WS-C2960- Gig 0/1

Dieser Fehler in der Dokumentation – das statt Fa0/9 fälschlich angegebene Interface – hat unter Umständen Auswirkungen auf den Netzwerkbetrieb. Wäre beispielsweise zwischen SW2 und R1 ein Trunking erforderlich gewesen, dann hätte dieses für das Interface Fa0/9 – nicht für Fa0/10! – explizit konfiguriert werden müssen, weil Router die Verwendung des Trunkings nicht automatisch verhandeln.

Beachten Sie , dass CDP keine Dokumentationsprobleme bei Interfaces erkennt, die mit End-benutzer-PCs verbunden sind; im vorliegenden Beispiel wollen wir davon ausgehen, dass die übri gen in Abbildung 3.5 gezeigten Interfaces korrekt sind.

Schritt 2: Auf Interface-Probleme prüfenIm nächsten Schritt untersuchen wir den Status aller Interfaces, die gegenwärtig verwendet werden sollten. Listing 3.8 zeigt die Ausgabe verschiedener show interface status-Befehle auf SW1 und SW3. (Wir setzen dabei voraus, dass alle Interfaces auf SW2 korrekt funktionieren.) Studieren Sie die Ausgabe, identifizieren Sie erkannte Probleme und erstellen Sie basierend auf der Ausgabe eine Liste weiterer interfacebezogener Probleme, die Sie näher untersuchen möchten.

Listing 3.8 Interface-Probleme auf SW1 und SW3

SW1# show interfaces fa0/11 statusPort Name Status Vlan Duplex Speed Type

Fa0/11 connected 3 a-full a-100 10/100BaseTX

SW1# show interfaces fa0/12 statusPort Name Status Vlan Duplex Speed Type

Fa0/12 notconnect 3 auto auto 10/100BaseTX

ICND2.indb 112 20.02.14 17:33

3.3 Beispiele und Übungen zum Troubleshooting 113

3

SW1# show interfaces Gi0/1 statusPort Name Status Vlan Duplex Speed Type

Gi0/1 connected trunk a-full a-1000 10/100/1000BaseTX

SW1# show interfaces Gi0/2 status Port Name Status Vlan Duplex Speed Type

Gi0/2 connected trunk a-full a-1000 10/100/1000BaseTX

! Wechsel zu SW3

SW3# show interfaces fa0/13 statusPort Name Status Vlan Duplex Speed Type

Fa0/13 connected 3 a-half a-100 10/100BaseTX

SW3# show interfaces Gi0/1 statusPort Name Status Vlan Duplex Speed Type

Gi0/1 connected trunk a-full a-1000 1000BaseTX

SW3# show interfaces Gi0/2 statusPort Name Status Vlan Duplex Speed Type

Gi0/2 connected trunk a-full a-1000 1000BaseTX

Ein auf SW1 vorhandenes Problem ist offensichtlich: Das Interface Fa0/12 hat den Status not-connect. Hierfür gibt es viele mögliche Ursachen, die sich allerdings fast alle auf ein Ver kabe-lungsproblem zurückführen lassen. Dies kann alles Mögliche sein – vom nicht vollständig in den Switch-Port eingesteckten Kabel bis hin zu schwer ermittelbaren Problemen mit elektrischen Störungen. (Mögliche Ursachen können Sie Tabelle 3.2 entnehmen .)

Für die Interfaces von SW3 lassen sich offenbar keine Probleme feststellen. Allerdings weisen alle drei Interfaces eine Duplexeinstellung auf, die derjenigen entspricht, die ein Switch ver-wenden würde, wenn das Autonegotiating fehlgeschlagen ist; auffällig ist die Verwendung der Halbduplexeinstellung auf Interface Fa0/13. Dies verweist auf die Möglichkeit eines Duplex-Mismatch.

Ein Mismatch der SW3-Interfaces Gigabit 0/1 und 0/2 können Sie ganz einfach ausschließen, indem Sie den Befehl show interfaces status am jeweils anderen Ende dieser beiden Ver bin-dungen – auf den Switches SW1 und SW2 – absetzen. Allerdings sind Ports, die mit einem PC verbunden sind, beim Troubleshooting schwierig zu handhaben, weil Sie sich wahrscheinlich nicht gerade in der Nähe des betreffenden PCs befinden und deswegen den Endbenutzer bei der Durchführung der Schritte anleiten müssen, die zur Überprüfung der Geschwindigkeits- und Duplexeinstellungen erforderlich sind. Trotzdem ist es sinnvoll, nach verräterischen Hinweisen auf Runts, Kollisionen und späte Kollisionen zu suchen, wie sie in der Ausgabe des Befehls show interfaces in Listing 3.9 auftauchen.

Listing 3.9 Hinweise auf ein Duplex-Mismatch

SW3# show interfaces fa0/13FastEthernet0/13 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is f47f.35cb.d78d (bia f47f.35cb.d78d)

MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation ARPA, loopback not set

ICND2.indb 113 20.02.14 17:33

114 Kapitel 3: Troubleshooting beim LAN-Switching

Keepalive set (10 sec)

Half-duplex, 100Mb/s, media type is 10/100BaseTX

input flow-control is off, output flow-control is unsupported

ARP type: ARPA, ARP Timeout 04:00:00

Last input never, output 00:00:01, output hang never

Last clearing of "show interface" counters never

Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: fifo

Output queue: 0/40 (size/max)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

14507 packets input, 1003344 bytes, 0 no buffer

Received 14488 broadcasts (466 multicasts)

54 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

0 watchdog, 466 multicast, 0 pause input

0 input packets with dribble condition detected

43824 packets output, 3440304 bytes, 0 underruns

0 output errors, 114 collisions, 2 interface resets

0 unknown protocol drops

0 babbles, 78 late collision, 0 deferred

0 lost carrier, 0 no carrier, 0 pause output

0 output buffer failures, 0 output buffers swapped out

In diesem Fall liegt tatsächlich ein Duplex-Mismatch vor, weil der Switch-Port den Halb-duplex modus verwendet. Beachten Sie jedoch, dass dieselben Zähler auch bei normalem Halb-duplexbetrieb hochgezählt werden, weswegen sie nicht in jedem Fall dazu beitragen können, das vorliegende Problem zu erkennen.

Hier muss die Konfiguration des Interface Fa0/13 von SW3 vom Halbduplex- auf den Voll-duplexbetrieb umgestellt werden, um eine Übereinstimmung mit der manuellen Einstellung auf PC3 zu erzielen .

Schritt 3: Auf Port-Security-Probleme prüfen Im nun folgenden Schritt untersuchen wir die Port-Security-Konfiguration und den Status der einzelnen Switches. Die erste Maßnahme besteht im Absetzen des Befehls show port-security. Dies ist besonders nützlich, weil der Befehl die Interfaces aufführt, auf denen die Port-Security aktiviert wurde. Listing 3.10 zeigt das Absetzen des Befehls auf den Switches SW1 und SW2 sowie einige weitere Befehle. Beachten Sie, dass weder auf SW2 noch auf SW3 die Port-Security aktiviert ist.

Studieren Sie das Listing 3.10 und machen Sie sich vor dem Weiterlesen ein paar Notizen dazu, welche weiteren Schritte Sie durchführen würden, um die Port-Security als potenzielle Problemquelle auszuschließen, und/oder mit welchem Befehl Sie ein mögliches Problem weiter eingrenzen würden.

ICND2.indb 114 20.02.14 17:33

3.3 Beispiele und Übungen zum Troubleshooting 115

3

Listing 3.10 Port-Security auf SW1 und SW2

SW1# show port-securitySecure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action

(Count) (Count) (Count)

---------------------------------------------------------------------------

Fa0/11 1 1 97 Restrict

---------------------------------------------------------------------------

Total Addresses in System (excluding one mac per port) : 0

Max Addresses limit in System (excluding one mac per port) : 4096

! Auf SW2 ist die Port-Security auf keinem Interface aktiviert.

SW2# show port-securitySecure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action

(Count) (Count) (Count)

---------------------------------------------------------------------------

---------------------------------------------------------------------------

Total Addresses in System (excluding one mac per port) : 0

Max Addresses limit in System (excluding one mac per port) : 8192

Die show port-security-Befehle im Listing führen die Interfaces auf, auf denen die Port-Security aktiviert wurde. Es handelt sich lediglich um das Interface Fa0/11 auf SW1 – Interfaces auf SW2 sind nicht betroffen. Auf SW1 sollten Sie zum Troubleshooting zunächst einmal festgestellt haben, dass unter der Überschrift »Security Action« für den Violation-Modus die Aktion »Restrict« angegeben ist. Bei dieser Einstellung kann die Port-Security auch dann, wenn das SW1-Interface Fa0/11 sich im Status connected befindet (vgl. Listing 3.8), Daten verwerfen, die gegen die Port-Security-Konfiguration verstoßen. Also ist eine nähere Untersuchung der Port-Security-Konfiguration angezeigt, wie sie Listing 3.11 darstellt.

Listing 3.11 Port-Security auf SW1 und SW2

SW1# show port-security interface fa0/11Port Security : Enabled

Port Status : Secure-up

Violation Mode : Restrict

Aging Time : 0 mins

Aging Type : Absolut

SecureStatic Address Aging : Disabled

Maximum MAC Addresses : 1

Total MAC Addresses : 1

Configured MAC Addresses : 1

Sticky MAC Addresses : 0

Last Source Address:Vlan : 0200.1111.1111:3

Security Violation Count : 97

!

! Als Nächstes zeigt die Konfiguration, dass die konfigurierte MAC-Adresse

! nicht mit der MAC-Adresse von PC1 übereinstimmt.

SW1# show running-config interface fa0/11

ICND2.indb 115 20.02.14 17:33

116 Kapitel 3: Troubleshooting beim LAN-Switching

interface FastEthernet0/11

switchport access vlan 3

switchport mode access

switchport port-security

switchport port-security violation restrict

switchport port-security mac-address 0200.3333.3333

!

! Die folgende Logmeldung zeigt auch ein Port-Security-Problem an.

01:46:58: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0200.1111.1111 on Port!FastEthernet0/11.

Das Listing beginnt mit Angaben zum Sicherheitsmodus und zum Violation-Zähler und zeigt auch die letzte MAC-Adresse an, die einen Frame an das Interface Fa0/11 gesendet hat (näm-lich 0200.1111.1111). Die MAC-Adresse von PC1 (0200.1111.1111) entspricht nicht der Port-Security-Konfiguration, wie man dem zweiten Teil des Listings entnehmen kann; diese legt maximal eine zulässige MAC-Adresse fest, die zudem explizit konfiguriert ist (0200.3333.3333).

Eine einfache Lösung besteht darin, die Port-Security so umzukonfigurieren, dass sie die MAC-Adresse von PC1 angibt. Beachten Sie, dass der Netzwerktechniker die Befehle shutdown und nachfolgend no shutdown für den Neustart dieses Interface nicht absetzen muss, denn die Konfiguration verwendet den Violation-Modus restrict, der das Interface laufen lässt und nur Daten von und an PC1 verwirft.

Am Ende des Listings schließlich findet sich eine Logmeldung, die vom Switch für jeden Verstoß im restrict-Modus generiert wird. Diese Meldung würde auf der Konsole oder über eine Telnet- oder SSH-Verbindung (Secure Shell) zum Switch ausgegeben, wenn der Remote-Benutzer den EXEC-Befehl terminal monitor absetzte. Sie kann auch von einem Syslog-Server erfasst werden (siehe Kapitel 19, »Netzwerkgeräte verwalten«).

Schritt 4: Auf VLAN- und VLAN-Trunk-Probleme prüfenSchritt 4a beginnt mit einer Untersuchung der Access-Interfaces, um sicherzustellen, dass diese den korrekten VLANs zugewiesen wurden. In diesem Fall sollten alle Interfaces in Abbildung 3.5, die an PCs und Router angeschlossen sind, VLAN 3 zugewiesen werden. Listing 3.12 zeigt einige nützliche show-Ausgaben. Nehmen Sie sich einen Moment Zeit und studieren Sie das Listing. Suchen Sie dort nach möglichen Problemen in Verbindung mit der VLAN-Zuordnung.

Das einzige Problem besteht in diesem Fall darin, dass zwar nach Vorgabe der Zeichnung das Interface Fa0/10 von SW2 zugeordnet war (vgl. Abbildung 3.5), SW2 jedoch über Fa0/9 an R1 angeschlossen ist, wie wir mithilfe von CDP ermittelt haben (vgl. Listing 3.7). Interface Fa0/9 ist standardmäßig Bestandteil von VLAN 1. Um dieses spezielle Problem zu beheben, setzen wir auf SW2 den Interface-Subbefehl switchport access vlan 3 für Interface Fa0/9 ab.

Im nun nachfolgenden Schritt 4b wird vorgeschlagen, die VLANs zu überprüfen, um sicher-zustellen, dass sie auf allen Switches aktiv sind. In unserem Beispiel kommt nur VLAN 3 zum Einsatz. Listing 3.13 zeigt, dass VLAN 3 tatsächlich auf allen Switches bekannt ist. Suchen Sie beim Lesen des Listings nach Problemen mit VLAN 3.

ICND2.indb 116 20.02.14 17:33

3.3 Beispiele und Übungen zum Troubleshooting 117

3

Listing 3.12 VLAN-Zuordnungen von Access-Interfaces überprüfen

SW1# show interfaces fa0/11 status

Port Name Status Vlan Duplex Speed Type

Fa0/11 connected 3 a-full a-100 10/100BaseTX

SW1# show interfaces fa0/12 status

Port Name Status Vlan Duplex Speed Type

Fa0/12 notconnect 3 auto auto 10/100BaseTX

! Nun SW2

SW2# show interfaces status! Zeilen aus Platzgründen gekürzt

Fa0/9 connected 1 a-full a-100 10/100BaseTX

Fa0/10 notconnect 3 auto auto 10/100BaseTX

! Nun SW3

SW3# show interfaces fa0/13 status

Port Name Status Vlan Duplex Speed Type

Fa0/13 connected 3 full a-100 10/100BaseTX

Listing 3.13 Auf aktive VLANs prüfen

SW1# show vlan id 3

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

3 book-vlan3 active Fa0/11, Fa0/12, Gi0/1, Gi0/2

! Zeilen aus Platzgründen gekürzt

! Nun SW2

SW2# show vlan brief

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4

Fa0/5, Fa0/6, Fa0/7, Fa0/8

Fa0/11, Fa0/12, Fa0/13, Fa0/14

Fa0/15, Fa0/16, Fa0/17, Fa0/18

Fa0/19, Fa0/20, Fa0/21, Fa0/22

Fa0/23, Fa0/24

3 VLAN0003 active Fa0/9, Fa0/10

! Zeilen aus Platzgründen gekürzt

! Nun SW3

SW3# show vlan brief

ICND2.indb 117 20.02.14 17:33

118 Kapitel 3: Troubleshooting beim LAN-Switching

VLAN Name Status Ports

---- -------------------------------- --------- -------------------------------

1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4

Fa0/5, Fa0/6, Fa0/7, Fa0/8

Fa0/10, Fa0/11, Fa0/13, Fa0/14

Fa0/14, Fa0/15, Fa0/16, Fa0/17

Fa0/18, Fa0/19, Fa0/20, Fa0/21

Fa0/22, Fa0/23, Fa0/24

3 book-vlan3 active Fa0/13

! Zeilen aus Platzgründen gekürzt

In diesem Fall ist VLAN 3 vorhanden und auf allen drei Switches aktiv. SW2 führt jedoch einen anderen Namen auf als die beiden anderen Switches. Für den Betrieb des VLAN ist dieser Name nicht von Bedeutung, weswegen der Unterschied keine Rolle spielt.

Der letzte Teilschritt 4c schließlich empfiehlt, den Trunking-Status aller angenommenen Trunk-Interfaces zu verifizieren. Außerdem ist es hilfreich, zu ermitteln, auf welchen Trunks die VLANs weitergeleitet werden. Listing 3.14 zeigt die Ausgabe, die uns hilft, die Fragen zu beantworten. Studieren Sie das Listing und notieren Sie vor dem Weiterlesen alle Trunks, die gegenwärtig keine Daten in VLAN 3 weiterleiten. Ergänzen Sie auf Ihrer Liste mögliche Gründe dafür, dass VLAN 3 vom Trunk nicht berücksichtigt wird.

Listing 3.14 Trunking und VLAN 3 überprüfen

SW1# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Gi0/1 desirable 802.1q trunking 1

Gi0/2 desirable 802.1q trunking 1

Port Vlans allowed on trunk

Gi0/1 1-4094

Gi0/2 1-4094

Port Vlans allowed and active in management domain

Gi0/1 1,3

Gi0/2 1,3

Port Vlans in spanning tree forwarding state and not pruned

Gi0/1 3

Gi0/2 1,3

! Nun SW2

SW2# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Gi0/1 auto 802.1q trunking 1

Gi0/2 auto 802.1q trunking 1

ICND2.indb 118 20.02.14 17:34

3.3 Beispiele und Übungen zum Troubleshooting 119

3

Port Vlans allowed on trunk

Gi0/1 1-4094

Gi0/2 1-4094

Port Vlans allowed and active in management domain

Gi0/1 1,3

Gi0/2 1,3

Port Vlans in spanning tree forwarding state and not pruned

Gi0/1 1,3

Gi0/2 1

! Nun SW3

SW3# show interfaces trunk

Port Mode Encapsulation Status Native vlan

Gi0/1 auto 802.1q trunking 1

Gi0/2 desirable 802.1q trunking 1

Port Vlans allowed on trunk

Gi0/1 1-4094

Gi0/2 1-4094

Port Vlans allowed and active in management domain

Gi0/1 1,3

Gi0/2 1,3

Port Vlans in spanning tree forwarding state and not pruned

Gi0/1 1,3

Gi0/2 1,3

Sehen wir uns zunächst das Ende der Ausgabe der drei im Listing gezeigten Befehle an und konzentrieren uns dabei auf VLAN 3. Alle Trunk-Ports auf diesen Switches geben VLAN 3 in ihrer letzten VLAN-Liste an – mit einer Ausnahme: der Port G0/2 von SW2. Warum? Weil STP diesen Port in VLAN 3 blockt.

Mithilfe verschiedener show spanning-tree-Befehle sollte sich nachweisen lassen, dass Port G0/2 in VLAN 3 geblockt ist; Sie können diesen Sachverhalt aber eigentlich bereits der Ausgabe im Listing entnehmen. Hierzu müssen Sie lediglich alle anderen Gründe dafür aus-schließen, warum VLAN 3 nicht in den vom Befehl show interfaces trunk ausgegebenen Listen enthalten ist:

VLAN 3 ist in der ersten VLAN-Liste der Ausgabe von show interfaces trunk auf SW2 enthalten, d. h., das VLAN muss auf der Liste zulässiger VLANs für diesen Trunk stehen.

VLAN 3 ist in der zweiten VLAN-Liste der Ausgabe von show interfaces trunk auf SW2 enthalten, d. h., das VLAN ist auf SW2 aktiv.

Nachdem Sie im vorliegenden Beispiel alle Probleme ermittelt und behoben haben, können PC1, PC3 und R1 nun erfolgreich Ping-Befehle aneinander senden. Allerdings funktioniert PC2 aufgrund eines nicht spezifizierten Verkabelungsproblems immer noch nicht.

ICND2.indb 119 20.02.14 17:34

120 Kapitel 3: Troubleshooting beim LAN-Switching

Troubleshooting-Beispiel 2: Verhalten der LAN-Data-Plane vorhersagenDieses zweite Beispiel verfolgt einen vollkommen anderen Ansatz als das erste. Am Anfang steht keine Vielzahl von Problemen, sondern ein vollkommen funktionsfähiges LAN. Ihre Aufgabe besteht nun darin, zu analysieren, wohin die Data-Plane in diesem LAN Frames weiterleitet.

Wir verwenden hier dasselbe Netzwerk wie im vorherigen Beispiel, diesmal aber ohne vorhan-dene Fehler. Das LAN funktioniert also und wir können uns darauf konzentrieren, den exakten Weg von Frames in diesem Netzwerk mithilfe der entsprechenden Befehle vorherzusagen. Dabei wollen wir in diesem Beispiel auf zwei Meldungen achten:

PC1 sendet einen ARP-Request für Router R1 als Broadcast-Frame. R1 sendet eine ARP-Reply als Unicast-Frame zurück an PC1.

Abbildung 3.6 zeigt das funktionsfähige Netzwerk im Detail. Am Ende dieses Abschnitts wird der Weg von ARP-Request und ARP-Reply in den Abbildungen 3.7 bzw. 3.8 dargestellt.

Gi0/1Fa0/11

Gi0/1 Fa0/9Gi0/2Fa0/12

0200.1111.1111

0200.2222.2222

0200.0101.0101Gi0/2 Gi0/1

Gi0/1 Gi0/2

Fa0/13

R1

PC1

PC3

PC2 SW1 SW2

SW3

Abbildung 3.6 Netzwerk für das Troubleshooting-Beispiel 2

HINWEIS Das Netzwerk für dieses Beispiel ist mit dem für das vorherige identisch, wobei hier alle Probleme behoben sind. Alle Access-Ports befinden sich in VLAN 3.

Falls Sie dieses Beispiel zur Übung bearbeiten möchten, analysieren Sie Abbildung 3.6 und die Listings und ignorieren Sie den dazwischen stehenden Text. Notieren Sie sich ausführlich alles, was Sie über den Weg des ARP-Broadcasts von PC1 und den der ARP-Reply von R1 herauskrie-gen können. Sie können das Beispiel natürlich, wenn Sie wollen, auch zur Anschauung verwen-den; lesen Sie in diesem Fall einfach weiter.

Der ARP-Request (Broadcast) von PC1Wenn PC1 ein IP-Paket in ein anderes Subnetz senden muss, dann übergibt er das Paket an sei-nen Default-Router. In diesem Fall agiert R1 als Default-Router von PC1. PC1 verfügt in seinem ARP-Cache unter Umständen nicht über die MAC-Adresse von R1 und sendet in diesem Fall einen ARP-Broadcast mit der Ethernet-Empfängeradresse FFFF.FFFF.FFFF.

ICND2.indb 120 20.02.14 17:34

3.3 Beispiele und Übungen zum Troubleshooting 121

3

Um den Weg des Broadcasts zu analysieren, orientieren Sie sich am allgemeinen Weiterleitungs-vorgang, wie er im Abschnitt »Der normale Weiterleitungsprozess bei LAN-Switches in der Übersicht« weiter oben in diesem Kapitel zusammengefasst wurde. Frühere Listings bestätig-ten, dass der SW1-Port Fa0/11 VLAN 3 zugewiesen ist und es sich bei diesem Interface um einen Access-Port handelt. Da der Frame ein Broadcast ist, flutet SW1 diesen. An dieser Stelle vermittelt Ihnen Listing 3.15 – eine Ausgabe des Befehls show spanning-tree vlan 3 active – genügend Informationen, um feststellen zu können, über welche Interfaces SW1 diesen von PC1 gesendeten Broadcast-Frame weiterleitet .

Listing 3.15 Liste der in VLAN 3 weiterleitenden Interfaces auf SW1

SW1# show spanning-tree vlan 3 active

VLAN0003

Spanning tree enabled protocol ieee

Root ID Priority 20483

Address f47f.35cb.d780

Cost 1

Port 26 (GigabitEthernet0/2)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)

Address 1833.9d7b.0e80

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Fa0/11 Desg FWD 19 128.11 P2p Edge

Fa0/12 Desg FWD 19 128.12 P2p

Gi0/1 Desg FWD 4 128.25 P2p

Gi0/2 Root FWD 1 128.26 P2p

Beachten Sie, dass SW1 den Frame nicht wieder über Fa0/11 ausgibt, da er über dieses Interface empfangen wurde. Außerdem leitet SW1 den Frame über seine beiden Trunk-Interfaces Gi0/1 und Gi0/2 sowie über Fa0/12 weiter. Ferner zeigt Listing 3.14 weiter oben in diesem Kapitel, dass die beiden Trunks von SW1 802.1Q mit dem nativen VLAN 1 verwenden, d. h., SW1 fügt einen 802.1Q-Header mit der VLAN-ID 3 zu jeder Kopie des Broadcast-Frames hinzu, die über diese beiden Trunks gesendet wurde.

Die Aktionen auf SW1 sollten nun zur Folge haben, dass SW2 und SW3 jeweils eine Kopie des von PC1 gesendeten Broadcast-Frames erhalten. Im Falle von SW2 wird die am Interface Gi0/2 empfangene Kopie des Broadcast-Frames verworfen. SW2 verwirft den Frame aufgrund von Schritt 3 des oben beschriebenen allgemeinen Weiterleitungsprozesses, weil das SW2-Eingangsinterface Gi0/2 sich im VLAN 3 im Blocking-Status befindet (siehe Listing 3.16).

ICND2.indb 121 20.02.14 17:34

122 Kapitel 3: Troubleshooting beim LAN-Switching

Listing 3.16 SW2: Blocking-Status auf Gi0/2 (eingehender Broadcast-Frame wird ignoriert)

SW2# show spanning-tree vlan 3

VLAN0003

Spanning tree enabled protocol ieee

Root ID Priority 20483

Address f47f.35cb.d780

Cost 4

Port 25 (GigabitEthernet0/1)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32771 (priority 32768 sys-id-ext 3)

Address 1833.9d7b.1380

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Fa0/9 Desg FWD 19 128.9 P2p

Gi0/1 Root FWD 4 128.25 P2p

Gi0/2 Altn BLK 4 128.26 P2p

Beachten Sie, dass der Blocking-Status auf SW2 nicht verhindert hat, dass SW1 den Frame an SW2 gesendet hat; der Frame wird vielmehr stillschweigend von SW2 verworfen .

Die Kopie des Broadcast-Frames von PC1, die von SW3 auf seinem Interface Gi0/1 empfangen wurde, wird von dem Switch geflutet. SW3 bestimmt das VLAN des Frames basierend auf dem eingehenden 802.1Q-Header und stellt fest, dass das eingehende Interface sich im STP-Forwarding-Status befindet. Basierend auf diesen Tatsachen leitet SW3 den Frame innerhalb von VLAN 3 weiter. Listing 3.17 zeigt alle Informationen, die notwendig sind, um festzustellen, über welche Interfaces SW3 den Broadcast aus VLAN 3 weiterleitet.

Listing 3.17 SW3: Weiterleitung eines Broadcasts in VLAN 3

SW3# show mac address-table dynamic vlan 3 Mac Address Table

-------------------------------------------

Vlan Mac Address Type Ports

---- ----------- -------- -----

3 0200.0101.0101 DYNAMIC Gi0/2

3 0200.1111.1111 DYNAMIC Gi0/1

3 0200.2222.2222 DYNAMIC Gi0/1

3 0200.3333.3333 DYNAMIC Fa0/13

Total Mac Addresses for this criterion: 4

ICND2.indb 122 20.02.14 17:34

3.3 Beispiele und Übungen zum Troubleshooting 123

3

SW3# show spanning-tree vlan 3 activeVLAN0003

Spanning tree enabled protocol ieee

Root ID Priority 20483

Address f47f.35cb.d780

This bridge is the root

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 20483 (priority 20480 sys-id-ext 3)

Address f47f.35cb.d780

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type

------------------- ---- --- --------- -------- --------------------------------

Fa0/13 Desg FWD 19 128.13 P2p

Gi0/1 Desg FWD 4 128.25 P2p

Gi0/2 Desg FWD 4 128.26 P2p

Wie SW1 leitet auch SW3 den Broadcast nicht über dasselbe Interface weiter, über das der Frame empfangen wurde (in diesem Fall Gi0/1), flutet ihn aber über alle anderen Interfaces in diesem VLAN, die sich im STP-Forwarding-Status befinden – hier also Fa0/13 und Gi0/2. Außerdem fügt, weil sein Interface Gi0/2 gegenwärtig das 802.1Q-Trunking mit dem nativen VLAN 1 verwendet, SW3 einen 802.1Q-Header mit der VLAN-ID 3 hinzu.

Schließlich arbeitet SW2, wenn er von SW3 die Kopie des Broadcasts über sein Interface Gi0/1 empfängt, denselben allgemeinen Prozess wie die anderen Switches ab. SW2 identifiziert das VLAN basierend auf dem eingehenden 802.1Q-Header, vergewissert sich, dass sich das einge-hende Interface im Forwarding-Status befindet, und flutet den Broadcast über alle Interfaces, die sich in VLAN 3 und im STP-Forwarding-Status befinden. In diesem Fall leitet SW2 den Frame nur über das Interface Fa0/9 weiter, das an den Router R1 angebunden ist. Listing 3.18 zeigt die dazugehörigen Ausgaben .

Listing 3.18 SW2: Weiterleitung eines von SW3 empfangenen Broadcasts in VLAN 3

! Beachten Sie zunächst, dass die Broadcast-Adresse FFFF.FFFF.FFFF

! nicht in der MAC-Tabelle in VLAN!3 enthalten ist

SW2# show mac address-table dynamic vlan 3 Mac Address Table

-------------------------------------------

Vlan Mac Address Type Ports

---- ----------- -------- -----

3 0200.0101.0101 DYNAMIC Fa0/9

3 0200.1111.1111 DYNAMIC Gi0/1

3 0200.2222.2222 DYNAMIC Gi0/1

3 0200.3333.3333 DYNAMIC Gi0/1

3 f47f.35cb.d79a DYNAMIC Gi0/1

Total Mac Addresses for this criterion: 5

ICND2.indb 123 20.02.14 17:34

124 Kapitel 3: Troubleshooting beim LAN-Switching

! Beachten Sie nun, dass Fa0/9 und Gi0/1 sich im STP-Forwarding-Status befinden und

! der Broadcast über Gi0/1 empfangen wurde, d.!h., SW2 flutet den Frame nur über Fa0/9.

SW2# show spanning-tree vlan 3 active! Zeilen aus Platzgründen gekürzt

Interface Role Sts Cost Prio.Nbr Type

---------------- ---- --- --------- -------- --------------------------------

Fa0/9 Desg FWD 19 128.9 P2p

Gi0/1 Root FWD 4 128.25 P2p

Gi0/2 Altn BLK 4 128.26 P2p

SW2 leitet den Frame nicht über Gi0/1 weiter, weil der Frame an diesem Interface einging .

ARP-Reply von R1 (Unicast)Die Antwort von R1 – eine ARP-Reply – wird als Unicast-Frame übertragen. Die Empfänger-MAC-Adresse (Schicht-2-Adresse) in der ARP-Reply von R1 ist die MAC-Adresse von PC1. Abbildung 3.8 am Ende dieses Abschnitts zeigt den Pfad. (Die Abbildung ist deswegen dort aufgeführt, damit Sie, falls Sie das Beispiel zur Übung bearbeiten, die Lösung nicht versehent-lich zu Gesicht bekommen.)

Die ARP-Reply wird in einem Ethernet-Frame übertragen, der an die Unicast-Ethernet-Adresse von PC1 gerichtet ist: 0200.1111.1111. Wenn SW2 diesen Frame von R1 erhält, stellt er fest, dass der Frame über das Interface Fa0/9 eingegangen ist, bei dem es sich um ein Access-Interface im VLAN 3 handelt. Am Ende von Listing 3.18 befand sich Fa0/9 auf SW2 in VLAN 3 im STP-Forwarding-Status, d. h., SW2 wird versuchen, den Frame in VLAN 3 weiterzuleiten. Im nun folgenden Listing 3.19 sehen wir, dass in der MAC-Adresstabelle von SW2 die MAC-Adresse von PC1 – 0200.1111.1111 – als über das Interface Gi0/1 erreichbar und in VLAN 3 befindlich aufgeführt wird; SW2 leitet den Frame also über Gi0/1 an SW3 weiter.

Listing 3.19 Logik von SW2 bei der Weiterleitung eines bekannten Unicasts an PC1

SW2# show mac address-table dynamic vlan 3 Mac Address Table

-------------------------------------------

Vlan Mac Address Type Ports

---- ----------- -------- -----

3 0200.0101.0101 DYNAMIC Fa0/9

3 0200.1111.1111 DYNAMIC Gi0/1

3 0200.2222.2222 DYNAMIC Gi0/1

3 0200.3333.3333 DYNAMIC Gi0/1

3 f47f.35cb.d79a DYNAMIC Gi0/1

Total Mac Addresses for this criterion: 5

ICND2.indb 124 20.02.14 17:34

3.3 Beispiele und Übungen zum Troubleshooting 125

3

Wenn SW3 den an die MAC-Adresse von PC1 gerichteten Frame von SW2 erhält, über-prüft SW3 zunächst das eingehende Interface. Dabei stellt er fest, dass der Frame über das Interface Gi0/2 einging, bei dem es sich um ein Trunk-Interface handelt; im Trunking-Header ist die VLAN-ID 3 aufgeführt. Am Ende von Listing 3.17 befand sich Gi0/2 im STP-Forwarding-Status in VLAN 3 (Weiterleitungsschritt 3), d. h., SW3 wird den Frame aufgrund des STP-Status nicht verwerfen. Im nun folgenden Listing 3.20 sehen wir, dass in der MAC-Adresstabelle von SW3 die MAC-Adresse von PC1 – 0200.1111.1111 – als über das Interface Gi0/1 erreichbar und in VLAN 3 befindlich aufgeführt wird; SW3 leitet den Frame also über Gi0/1 an SW1 weiter.

Listing 3.20 Logik von SW3 bei der Weiterleitung eines bekannten Unicasts an PC1

SW3# show mac address-table dynamic vlan 3 Mac Address Table

-------------------------------------------

Vlan Mac Address Type Ports

---- ----------- -------- -----

3 0200.0101.0101 DYNAMIC Gi0/2

3 0200.1111.1111 DYNAMIC Gi0/1

3 0200.2222.2222 DYNAMIC Gi0/1

3 0200.3333.3333 DYNAMIC Fa0/13

Total Mac Addresses for this criterion: 4

Wenn SW1 den Frame von SW3 erhält, stellt er fest, dass der Frame über das Interface Gi0/2 einging, bei dem es sich um ein Trunk-Interface handelt; im Trunking-Header ist VLAN ID 3 aufgeführt. Am Ende von Listing 3.15 befand sich das SW1-Interface Gi0/2 im STP-Forwarding-Status in VLAN 3. SW1 verwirft den Frame also nicht, sondern verarbeitet ihn, weil sich das Interface in VLAN 3 nicht im STP-Blocking-Status befindet. Im folgenden Listing 3.21 sehen wir, dass in der MAC-Adresstabelle von SW1 die MAC-Adresse von PC1 – 0200.1111.1111 – als über das Interface Fa0/11 erreichbar aufgeführt wird; SW1 leitet den Frame also über Fa0/11 an PC1 weiter. Nun entfernt SW1 den 802.1Q-VLAN-Header, weil es sich beim Interface Fa0/11 um ein Access-Interface handelt.

Listing 3.21 Logik von SW3 bei der Weiterleitung eines bekannten Unicasts an PC1

SW1# show mac address-table dynamic vlan 3 Mac Address Table

-------------------------------------------

Vlan Mac Address Type Ports

---- ----------- -------- -----

3 0200.2222.2222 DYNAMIC Fa0/12

3 0200.3333.3333 DYNAMIC Gi0/2

3 f47f.35cb.d799 DYNAMIC Gi0/2

Total Mac Addresses for this criterion: 3

ICND2.indb 125 20.02.14 17:34

126 Kapitel 3: Troubleshooting beim LAN-Switching

SW1# show mac address-table vlan 3 Mac Address Table

-------------------------------------------

Vlan Mac Address Type Ports

---- ----------- -------- -----

All 0100.0ccc.cccc STATIC CPU

All 0100.0ccc.cccd STATIC CPU

All 0180.c200.0000 STATIC CPU

All 0180.c200.0001 STATIC CPU

All 0180.c200.0002 STATIC CPU

All 0180.c200.0003 STATIC CPU

All 0180.c200.0004 STATIC CPU

All 0180.c200.0005 STATIC CPU

All 0180.c200.0006 STATIC CPU

All 0180.c200.0007 STATIC CPU

All 0180.c200.0008 STATIC CPU

All 0180.c200.0009 STATIC CPU

All 0180.c200.000a STATIC CPU

All 0180.c200.000b STATIC CPU

All 0180.c200.000c STATIC CPU

All 0180.c200.000d STATIC CPU

All 0180.c200.000e STATIC CPU

All 0180.c200.000f STATIC CPU

All 0180.c200.0010 STATIC CPU

All ffff.ffff.ffff STATIC CPU

3 0200.1111.1111 STATIC Fa0/11

3 0200.2222.2222 DYNAMIC Fa0/12

3 0200.3333.3333 DYNAMIC Gi0/2

3 f47f.35cb.d799 DYNAMIC Gi0/2

Total Mac Addresses for this criterion: 24

Dieser letzte Schritt hebt eine wichtige Tatsache zur MAC-Adresstabelle und zur Port-Security hervor. Beachten Sie, dass der Befehl show mac address-table dynamic auf SW1 die Mac-Adresse 0200.1111.1111 von PC1 nicht aufführt. Hierdurch könnte man zu der Annahme verleitet werden, dass SW1 den Frame flutet, weil es sich um einen unbekannten Unicast-Frame handelt. Da SW1 allerdings die Port-Security auf Fa0/11 einschließlich des Interface-Subbefehls switchport port-security mac-address 0200.1111.1111 konfiguriert hat, betrachtet IOS diese MAC-Adresse als statische MAC-Adresse. Wenn wir nun also das Schlüsselwort dynamic weg-lassen, führt der Befehl show mac address-table vlan 3 alle MAC-Adressen auf, die im VLAN bekannt sind – mithin auch 0200.1111.1111. Diese Befehlsausgabe bestätigt uns, dass SW1 den Unicast nur über das Interface Fa0/11 an 0200.1111.1111 weiterleitet.

Abbildung 3.7 zeigt den Pfad des als Broadcast gesendeten ARP-Request durch dieses LAN, Abbildung 3.8 den Weg der ARP-Reply (Unicast) .

ICND2.indb 126 20.02.14 17:34

3.3 Beispiele und Übungen zum Troubleshooting 127

3

Gi0/1Fa0/11

Gi0/1 Fa0/9Gi0/2Fa0/12

0200.1111.1111

0200.2222.2222

0200.0101.0101Gi0/2 Gi0/1

Gi0/1 Gi0/2

Fa0/13

R1

PC1

PC3

PC2 SW1 SW2

SW3

Abbildung 3.7 Weiterleitungspfad des ARP-Broadcasts von PC1 bis R1

Gi0/1Fa0/11

Gi0/1 Fa0/9Gi0/2Fa0/12

0200.1111.1111

0200.2222.2222

0200.0101.0101Gi0/2 Gi0/1

Gi0/1 Gi0/2

Fa0/13

R1

PC1

PC3

PC2 SW1 SW2

SW3

Abbildung 3.8 Weiterleitungspfad der ARP-Reply von R1 bis PC1

ICND2.indb 127 20.02.14 17:34

128 Kapitel 3: Troubleshooting beim LAN-Switching

Aufgaben zur Prüfungsvorbereitung

Alle Schlüsselthemen wiederholenWiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind mit dem Symbol »Schlüsselthema« gekennzeichnet. Tabelle 3.8 listet diese Themen sowie die Seitennummern auf, auf denen diese Themen zu finden sind.

Tabelle 3.8 Schlüsselthemen in Kapitel 3

Element Beschreibung Seite

Tabelle 3.2 Listet Codekombinationen für den Interface-Status und typische Ursachen für jeden Status auf.

95

Abbildung 3.4 Zeigt die typische Verwendung von Crossover- und Straight-Through-Kabeln.

96

Tabelle 3.3 Zeigt Geräte und Leitungen, über die Daten via 10BASE-T und 100BASE-TX übertragen werden.

97

Liste Definitionen von Geschwindigkeits- und Duplex-Mismatch 98

Liste Vorschläge zur Ermittlung von Duplex-Mismatches 100

Liste Optionsvorgaben für das IEEE-Autonegotiating basierend auf der aktuellen Übertragungsrate

100

Tabelle 3.4 Violation-Modi bei der Port-Security einschließlich der Unterschiede im Verhalten und der zugehörigen show-Befehle

102

Liste Schritte bei der Port-Security-Konfiguration 104

Tabelle 3.5 Führt show-Befehle auf, die nützlich sind, um Access-Interfaces und die ihnen zugeordneten VLANs zu ermitteln.

106

Tabelle 3.6 Vier Gründe dafür, warum ein Switch die Daten eines VLAN nicht über einen bestimmten Trunk weiterleitet

108

Tabelle 3.7 Kombinationen des switchport mode-Befehls und der zugehörigen Ergebnisse zur Frage, ob ein Trunking erfolgt

109

Tabellen und Listen aus dem Gedächtnis vervollständigenDrucken Sie aus Anhang D, »Tabellen zur Gedächtnisübung« (auf CD), den Abschnitt zu diesem Kapitel aus und vervollständigen Sie die Tabellen und Listen aus dem Gedächtnis. Der ebenfalls auf CD enthaltene Anhang E, »Lösungen zu Anhang D«, enthält die vollständigen Tabellen und Listen, mit denen Sie Ihre Lösungen überprüfen können.

Schlüssel-thema

ICND2.indb 128 20.02.14 17:34

Lösungen zum Troubleshooting-Beispiel 1 129

3

Lösungen zum Troubleshooting-Beispiel 1Wenn Sie das Troubleshooting-Beispiel 1 als Übung bearbeitet haben, fasst die folgende Liste die Probleme zusammen, die in dieser Übung entdeckt worden sein könnten:

Abbildung 3.5 zeigt die Verbindung von Port Fa0/10 von SW2 mit Router R1; CDP gibt jedoch an, dass hierfür in Wahrheit Port F0/9 von SW2 verwendet wird. Im Beispiel wurde das Problem durch eine entsprechende Anpassung des Netzwerkdiagramms behoben.

Der Port F0/12 von SW1, laut Abbildung mit PC2 verbunden, befindet sich im Status notconnect. Die Ursache hierfür geht aus den Listings nicht hervor. (Tatsächlich war das Kabel abgezogen; zur Vorbereitung auf das zweite Beispiel wurde dieses Kabel dann wieder gesteckt.)

Bei Port Fa0/13 von SW3 liegt möglicherweise ein Duplex-Mismatch vor. Angegeben sind hier a-100 für die Geschwindigkeit sowie half für den Duplexmodus; dies könnte passieren, wenn das andere Gerät (PC13) das Autonegotiating deaktiviert und für sich selbst 100 bzw. den Vollduplexmodus festgelegt hat. Das Problem wurde durch manuelle Konfiguration des Vollduplexmodus am Switch behoben.

Die Port-Security beim Interface F0/11 von SW1 filtert aufgrund einer fehlerhaften Kon-figuration der MAC-Adresse 0200.3333.3333 Daten vom einzigen Gerät, das mit ihm verbunden ist (PC1, 0200.1111.1111). Die Port-Security-Konfiguration wurde geändert und führt nun die richtige MAC-Adresse 0200.1111.1111 auf.

Port F0/9 von SW2 – physisch mit R1 verbunden – ist VLAN 1 zugewiesen, während Port F0/10, der in Abbildung 3.5 mit R1 verbunden ist, VLAN 3 zugeordnet ist (und dies mit Recht). Entweder muss das Kabel umgesteckt werden oder F0/9 muss VLAN 3 zugewiesen werden. Das Buch zeigt die Neukonfiguration des Ports F0/9 von SW2 mit dem Befehl switchport access vlan 3.

ICND2.indb 129 20.02.14 17:34