Troubleshooting Beim LAN-Switching

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 fr das Troubleshooting erforderlichen Kennt-nisse zu erlangen und die entsprechenden Prfungsaufgaben schnell und richtig beantworten zu knnen. Gleichzeitig soll Sie dieses Kapitel auch besser auf Situationen vorbereiten, in denen Sie in der Praxis netzwerkspezifische Probleme beheben mssen.

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 greren 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. Zunchst einmal beschreibt es natrlich das Troubleshooting von LANs. Weni ger augenscheinlich drfte jedoch sein, dass in diesem Kapitel auch viele der Themen im Zusam-menhang mit Ethernet-LANs wiederholt werden, die Voraussetzung fr das Verstndnis dieses Buchs sind. In Kapitel 1, Konzepte des Spanning-Tree-Protokolls, wurden einige der Themen wiederholt. Im vorliegenden Kapitel werden zahlreiche weitere folgen. Auerdem erfahren Sie hier, wie Sie auf der Basis Ihres vorhandenen und des neuen Wissens das Troubleshooting von Ethernet-LANs durchfhren.

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

Q Allgemeine Anstze zum TroubleshootingQ Troubleshooting der LAN-Switching-Data-PlaneQ Beispiele und bungen zum TroubleshootingAngesichts der schieren Lnge dieser Abschnitte sollten Sie in Betracht ziehen, jeden Abschnitt separat zu bearbeiten, sind sie doch zehn bzw. zwanzig Seiten lang. Alle drei Abschnitte gehren thematisch zusammen, weswegen sie im selben Kapitel untergebracht sind. Dabei enthlt der mittlere die wichtigsten Themen zum Troubleshooting von LAN-Switches. Zuvor definieren wir zunchst 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 Einschtzung 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-Prfungen angeht, sollten Sie diese Kapitel in jedem Fall unabhngig von Ihrem gegen-wrtigen Kenntnisstand lesen. Aus diesen Grnden enthalten die Kapitel zum Troubleshooting auch keine Fragen zur Einschtzung 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 knnen Sie gerne den Groteil dieses Kapitels berspringen und mit dem Abschnitt Aufgaben zur Prfungsvorbereitung am Ende des Kapitels fortfahren.

ICND2.indb 82 20.02.14 17:33

3.1 Allgemeine Anstze zum Troubleshooting 83

3

Grundlagenthemen

3.1 Allgemeine Anstze zum Troubleshooting

HINWEIS Die hier beschriebenen allgemeinen Anstze und Methoden zum Trouble-shooting sind Mittel zum Zweck. Fr die Prfung brauchen Sie diese Ablufe weder zu studieren noch sie sich zu merken. Vielmehr sind diese Prozesse dafr gedacht, Ihnen bei der Problemanalyse whrend der Prfung zu helfen, sodass Sie die Fragen ein wenig schneller und mit etwas mehr Selbstvertrauen beantworten knnen.

Wenn man mit einem Netzwerkproblem konfrontiert wird, verwendet man bewusst oder unbe-wusst immer irgendeine Troubleshooting-Methodik. Es gibt Menschen, die zunchst einmal die physische Verkabelung und den Interface-Status aller physischen Verbindungen berprfen, die Ursache des Problems sein knnten. 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 mglichen Schritte aus, bis sie am Ende intuitiv erfassen, worin genau das Problem besteht. Keine dieser Methoden ist fr 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 frher oder spter Gewohnheiten und Anstze, die im Rahmen ihrer eigenen Erfahrungen und Strken 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-Prfungen vorzubereiten.

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

Q 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.

Q Problemeingrenzung: Bei diesem Schritt wird folgende Frage beantwortet: Was genau funktioniert nicht? Wenn ein Problem auftritt, mssen 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.

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

ICND2.indb 83 20.02.14 17:33


Die Verinnerlichung dieser drei Schritte sollte zur Folge haben, dass Sie wissen, wie Sie ein Problem grundstzlich lsen, statt nur die Symptome zu beseitigen. Als Nchstes werden wir einige Gedanken zu der Frage erlutern, wie man die einzelnen Schritte des Troubleshooting-Ablaufs angehen kann.

Normalbetrieb des Netzwerks analysieren und prognostizierenAufgabe eines jeden Netzwerktechnikers ist es, dafr Sorge zu tragen, dass Daten von einem Endbenutzergert zu einem anderen bertragen werden. Um ein Netzwerk analysieren zu kn-nen, muss der Techniker die Logik kennen, die von den einzelnen verschalteten Gerten bei der Weiterleitung der Daten zum jeweils nchsten Gert zugrunde gelegt wird. Indem er sich verge-genwrtigt, was auf den einzelnen Gerten passieren sollte, kann der Techniker den gesamten Datenfluss beschreiben.

Der Begriff Data-Plane (Datenebene) bezieht sich auf Schritte, die von Gerten bei der Weiter-leitung von Daten ausgefhrt werden. Zur Weiterleitung wendet ein Gert 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 empfngt, trifft er seine Weiterleitungsentscheidung basie-rend auf den Eintrgen 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 zustzliche Prozesse, die zwar die Vorgnge auf dem Netzwerkgert steuern, aber nicht fr jedes Paket oder jeden Frame durchzufhren sind. Beispiele fr 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 Gert Daten weiterleitet. So kann CDP (Cisco Discovery Protocol) etwa ntzlich sein, um die Richtigkeit der Netzwerkdokumentation zu verifizieren, lsst sich allerdings ebenso deak-tivieren, ohne dass sich dies auf die Weiterleitungsprozesse der Data-Plane auswirken wrde. Auch CDP wre ein Control-Plane-Prozess.

Um den voraussichtlichen Betrieb eines Netzwerks prognostizieren oder erlutern zu knnen, wie ein korrekt funktionierendes Netzwerk gegenwrtig arbeitet, kann es fr das Trouble-shooting hilfreich sein, sich zunchst mit der Control-Plane oder der Data-Plane zu beschfti-gen. Im Folgenden werden wir zwar zunchst die Data-Plane behandeln, doch knnen 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 Gerte im angenommenen Weiterleitungs-pfad der Daten in der jeweiligen Reihenfolge untersucht. Die Analyse beginnt bei dem Host, auf dem die Daten ursprnglich erstellt werden. Dieser Host sendet die Daten an ein anderes Gert, welches sie dann wiederum an ein anderes Gert weiterleitet usw., bis die Daten schlielich beim endgltigen Empfnger eintreffen.

Beim Troubleshooting in der Data-Plane mssen beide Datenflussrichtungen zwischen zwei Gerten berprft werden. Wenn nmlich ein Gert Daten sendet, dann schickt der empfan-gende Host in aller Regel irgendeine Antwort zurck. 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

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

Sofern die Symptome nicht bereits Rckschlsse 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 knnen 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 mchten, mssen Sie zunchst berlegen, wie der Paketfluss von links nach rechts erfolgt; danach den-ken Sie darber nach, wie der Ablauf in umgekehrter Richtung stattfindet. Die sechs in der Abbildung gezeigten Schritte gestatten die folgende Analyse:

Schritt 1: berprfen 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: berprfen Sie die Weiterleitungslogik von R1 zur Zuordnung der Empfnger-IP-Adresse des Pakets in der Routing-Tabelle von R1 unter der Annahme, dass R1 das Paket als Nchstes an R2 weiterleitet.

Schritt 3: Auf R2 sollten Sie dieselbe Zuordnungslogik in der Routing-Tabelle wie im vorheri-gen Schritt bei R1 berprfen, 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 grundstzlich 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: berprfen Sie die Weiterleitungslogik von R2 fr 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


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, kn-nen Sie sich der nheren Untersuchung von Schicht 2 zuwenden. Sie fhren die Analyse wieder in derselben Reihenfolge durch und betrachten dabei zunchst den ersten in Abbildung 3.1 gezeigten Schicht-3-Routing-Schritt (PC1 sendet ein Paket an R1). Dabei berprfen 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

Fr diese Analyse beginnen Sie zunchst wieder bei PC1. Diesmal berprfen Sie Ethernet-Header und -Trailer und dabei insbesondere die MAC-Adressen von Absender und Empfnger. In Schritt 2 verifizieren Sie dann die Weiterleitungslogik von SW1: Diese vergleicht die Empfnger-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 fr 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 durchgefhrten Schritte keine direkte Rolle bei der Weiterleitung eines Frames oder Pakets spielen.

Whrend die Prozesse der Data-Plane sich fr eher universelles Troubleshooting eignen, bei dem die Weiterleitungslogik auf jedem Gert untersucht wird, unterscheiden sich die Prozesse der Control-Plane zu deutlich voneinander, als dass sie ein allgemeingltiges Troubleshooting ermglichen wrden. Jeder Prozess der Control-Plane kann separat untersucht werden. So erklrt beispielsweise Kapitel 2, STP-Implementierung, wie man verschiedene Arten STP-spezifischer Probleme beheben kann .

ICND2.indb 86 20.02.14 17:33


3

Zusammenfassung zur Prognose des NormalbetriebsBei den Prfungen wird die eine oder andere Aufgabe auf Sie zukommen, bei der Sie den norma-len Betrieb eines laufenden Netzwerks analysieren und vorhersagen mssen. In anderen Fllen ist die Prognose des normalen Verhaltens lediglich als Vorlauf zur Eingrenzung und Behebung eines Problems gedacht. Unabhngig davon knnen Sie, wenn die Aufgabe keine bestimmten Hinweise zu dem Teil des Netzwerks enthlt, 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 nchsten Router und schlielich vom letzten Router bis zum Empfngerhost in beiden Richtungen .

b. Analysieren Sie fr jedes Schicht-2-Netzwerk zwischen einem Host und einem Router oder zwei Routern die Weiterleitungslogik aller beteiligten Gerte.

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

a. Ermitteln Sie, welche Control-Plane-Protokolle fr 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 ordnungsgemen Betrieb der Data-Plane nicht beeintrchtigen, auf einen spteren Zeitpunkt, wenn Sie sicher sind, dass Sie dieses Protokoll (z. B. CDP) brauchen, um die Aufgabe zu bearbeiten.

Probleme eingrenzenBeim Troubleshooting mssen 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 darber, worin das Problem bestehen knnte:

Vor der Problemeingrenzung: Sie kennen einige Symptome, haben aber keine Ahnung, worin das Problem bestehen knnte.Nach der Problemeingrenzung: Sie wissen nun, was nicht funktioniert, knnen dies in ein Verhltnis zum erwnschten Normalbetrieb setzen und haben auch erkannt, auf welchen Gerten die Funktionen nicht wie gewnscht ausgefhrt 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 zurck bermittelt wird. In diesem Fall jedoch stellen Sie fest, dass zwar R2 das in der Abbildung von links nach rechts wandernde Paket erhlt, dieses aber nicht an PC2 ausgeliefert wird. Also sehen Sie sich den dritten Routing-Schritt zwischen R2 und PC2 in der Abbildung nher an, um das Problem weiter einzugrenzen. Dieser Vorgang des Isolierens von Problemursachen heit Problemeingrenzung.

ICND2.indb 87 20.02.14 17:33


Nachdem Sie das Problem auf genau einen IP-Weiterleitungsschritt eingegrenzt haben (vgl. Abbildung 3.1), sollten Sie es weiter auf eine mglichst kleine Anzahl von Komponenten beschrnken. Wenn beispielsweise R2 das Paket empfngt, PC2 aber nicht, dann kann das Problem auf R2, SW4, SW5, PC2, bei der Verkabelung oder auch bei Gerten vorliegen, die nicht in der Netzwerkdokumentation angegeben sind.

Zur weiteren Eingrenzung des Problems ist nun gewhnlich ein berprfen 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 knnen. Wenn Sie feststellen, dass R2 ber keinen ARP-Eintrag zu PC2 verfgt, knnten Sie versucht sein, anzunehmen, dass ein IP-spezifisches Problem aufgetre-ten ist. Die Problemursache kann allerdings jedes Element der folgenden Liste sein :

Q Der Trunk zwischen SW4 und SW5 kann deaktiviert worden sein.Q Das Kabel zwischen SW5 und PC2 ist unter Umstnden schadhaft.Q In der IPv4-Konfiguration von PC2 ist die IP-Adresse von PC2 mglicherweise nicht festge-

legt.Q Der DHCP-Server (Dynamic Host Configuration Protocol) knnte 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 fr PC2 fehlgeschlagen ist; warum genau dies passiert ist, haben wir allerdings an dieser Stelle noch nicht bestimmt.

Wenn eine Prfungsaufgabe keinerlei Hinweise darauf enthlt, wo man ansetzen knnte, bietet der folgende Ablauf eine geeignete allgemeine und systematische Strategie zur Problem-eingrenzung:

Schritt 1: Untersuchen Sie zunchst 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 fehlschlgt.

Schritt 2: Grenzen Sie das Problem auf mglichst wenige Komponenten ein:

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

b. Untersuchen Sie gleichermaen die Funktionen der Data-Plane und der Control-Plane.

Denken Sie bei den Prfungen daran, dass Sie allein fr gute Troubleshooting-Methoden keinen Schnheitspreis 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 mssen. 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-Prfungen ebenfalls den Schwerpunkt auf diese drei Schichten legen. Sehen Sie aber zu, dass Sie diesen Vorgang so weit abkrzen, wie es die Frage gestattet.

ICND2.indb 88 20.02.14 17:33


3

UrsachenanalyseDer letzte der drei Schritte die Ursachenanalyse (engl. Root Cause Analyses) steht am Abschluss des Troubleshootings . Es geht darum, das Gert und die zugehrige Funktion zu ermitteln, die korrigiert werden mssen. Die Ursache ist ein im Netzwerk aufgetretenes Problem; ist es behoben, dann ist das ursprngliche Problem zumindest teilweise gelst.

Die Suche nach dieser Hauptursache ist zu ihrer Behebung unabdingbar. Vergegenwrtigen 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:

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

Alle diese Aussagen treffen gewiss auf ein bestimmtes Problemszenario zu, aber nur fr den letzten Eintrag in der Liste gibt es eine naheliegende Lsung (nmlich den Austausch des vor-handenen Kabels gegen ein ordnungsgem belegtes). Zwar sind die anderen Aussagen zutref-fende und auch wichtige Aspekte, die whrend der Problemeingrenzung zu bercksichtigen sind, aber es gibt keine Manahme, die sich direkt anbieten wrde, um eines dieser Probleme zu lsen. Infolgedessen reduziert sich die Ursachenanalyse auf zwei einfache Anweisungen:

Schritt 1: Fahren Sie mit der Problemeingrenzung fort, bis Sie die Ursache erkennen, fr die eine Lsung naheliegt.

Schritt 2: Wenn Sie das Problem nicht auf eine echte Ursache eingrenzen knnen, fhren Sie die Eingrenzung so weit wie mglich durch und ndern Sie etwas im Netzwerk, damit sich die Symptome mglicherweise ndern und Sie so weitere Einsichten in das Wesen des Problems gewinnen.

Prfungsaufgaben und die PraxisSuchen Sie bei der Prfung nach Hinweisen, etwa dem allgemeinen Thema, fr 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 zunchst die LAN-Umgebung ansehen. Trotzdem sollten Sie natrlich auch die Schichten 1 bis 3 sowie die Details der Data-Plane und der Control-Plane bercksichtigen, um die gewnschten 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 Einfhrung in die Methoden des Troubleshootings. Nun wollen wir uns dem Troubleshooting fr praktisch alle in der ICND1-Prfung behandelten Themen zum LAN-Switching zuwenden.

ICND2.indb 89 20.02.14 17:33


3.2 Troubleshooting bei der LAN-Switching-Data-Plane

HINWEIS Hier ein paar Tipps fr den Anfang dieses zweiten Abschnitts im Kapitel. Machen Sie eine kleine Pause, schpfen 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 Lektre vor dem Ende dieses langen Abschnitts unter-brechen mssen, tun Sie dies mglichst vor einer berschrift, die mit Schritt 1, Schritt 2 usw. beginnt.

Die bislang in diesem Kapitel behandelten Troubleshooting-Strategien legen nahe, dass man zunchst den IP-Routing-Prozess in Schicht 3 berprft. Wenn der Netzwerktechniker ein Problem bei einem bestimmten Schritt im IP-Weiterleitungsprozess erkennt, sollte der nchs-te Schritt darin bestehen, sich diesen Schritt genauer anzusehen, wobei auch der Status der zugrunde liegenden Schichten 1 und 2 bercksichtigt werden muss. Wird bei einem Routing-Schritt ein LAN durchquert, dann knnen 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 fr 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 knnen 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 fnf Hauptthemen. Am Anfang rekapitulieren wir zunchst 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-fhrlich 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 bercksich-tigt. In den nachfolgenden Prozessschritten ist diese Logik aufs Neue skizziert, diesmal jedoch mit zustzlichen 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 aufgefhrt ist.

Schritt 2: Wenn das Eingangs-Interface in diesem VLAN sich im Learning- oder Forwarding-Status befindet, fgt der Switch die Absender-MAC-Adresse zu seiner MAC-Adresstabelle hinzu und verknpft 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 Empfnger-MAC-Adresse des Frames in der MAC-Adresstabelle, jedoch nur fr Eintrge im in Schritt 1 ermittelten VLAN. Je nach dem, ob die MAC-Adresse gefunden wird oder nicht, werden die folgenden Schritte ausgefhrt:

a. Die MAC-Adresse wird gefunden. Der Frame wird ber genau das Interface weitergeleitet, das im zur Adresse passenden Tabelleneintrag aufgefhrt 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 vollstndig untersttzt auffhren.

Um einen Frame weiterzuleiten, muss ein Switch zunchst ermitteln, in welchem VLAN der Frame weitergeleitet werden soll (Schritt 1), bei Bedarf die Absender-MAC-Adressen erlernen (Schritt 2) und schlielich 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.22220200.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


Betrachten Sie den Frame, der von PC1 (Absender-MAC-Adresse 0200.1111.1111) an R1 (Empfnger-MAC-Adresse 0200.0101.0101) gesendet wird. Die folgende Liste erlutert die Weiterleitungslogik fr alle in der Abbildung gezeigten Schritte:

Q 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.

Q In Schritt 2 ergnzt SW1 einen Eintrag in seiner MAC-Adresstabelle, der die MAC-Adresse 0200.1111.1111, das Interface Fa0/11 und das VLAN 3 auffhrt.

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

Q In Schritt 4 schlielich 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 auffhrt, dann leitet SW1 den Frame nur ber Gi0/1 weiter. Ist das ausgehende Interface Gi0/1 ein Trunk-Interface, dann fgt SW1 einen VLAN-Trunking-Header hinzu, der das VLAN mit der in Schritt 1 ermittelten ID (also VLAN 3) auffhrt.

Ein weiteres, etwas abgendertes 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 untersttzen. Dabei gilt die Einschrnkung, 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 Bchern 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 berprfen. Aus diesem Grund wird in diesem Kapitel ein Troubleshooting-Vorgang fr die Data-Plane beschrieben, der alle Manahmen 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 nchsten vier Abschnitten wiederholen und erlutern wir die Konzepte und Werkzeuge, mit denen diese Schritte durchgefhrt werden. Zwar werden einige Tatsachen und Angaben neu fr Sie sein, doch der Groteil 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 zusammenzufhren, damit die Analyse konkreter Szenarios, wie sie bei den Prfungen verlangt wird, weniger lang dauert und die Erfolgschancen erhht werden .

ICND2.indb 92 20.02.14 17:33


3

Schritt 1: Netzwerkdiagramme mit CDP verifizierenDas CDP-Protokoll (Cisco Discovery Protocol) kann ntzlich sein, um die Informationen im Netzwerkdiagramm zu verifizieren und weitere hilfreiche Angaben zu Gerten und zur Netzwerktopologie zu ermitteln. In der Praxis sind Netzwerkdiagramme hufig alt und ber-holt; Probleme treten meist dann auf, wenn jemand die Verkabelung gendert, das Diagramm aber nicht aktualisiert hat. Ich bezweifle zwar, dass man vonseiten Ciscos in einer Aufgabe eine Abbildung zeigt, die bewusst falsche Angaben enthlt, aber es ist durchaus mglich, dass eine solche Abbildung nicht alle erforderlichen Informationen zeigt, weswegen Sie die brigen Details mit dem CDP-Protokoll ermitteln mssen. 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: berprfen Sie mithilfe von CDP die im Netzwerkdiagramm aufgefhrten Anga-ben auf Richtigkeit und Vollstndigkeit.

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

Router, Switches und andere Gerte von Cisco verwenden CDP fr viele unterschiedliche Zwecke. Router und Switches nutzen das Protokoll in erster Linie, um Informationen ber sich selbst also etwa den Hostnamen, den Gertetyp, die IOS-Version und die Interface-Nummern an ihre Nachbarn zu bermitteln. Im Wesentlichen sind es die drei in Tabelle 3.1 aufgefhr-ten Befehle, die von den Nachbarn erlernte CDP-Informationen auflisten. Ist berhaupt kein Netzwerkdiagramm vorhanden, dann knnte 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 Gerten

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 Fhrt umfangreiche Informationen (ca. 15 Zeilen) pro Nachbargert auf.

show cdp entry name Fhrt 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 aufgefhrtes Interface sich auf dem lokalen oder einem benachbarten Gert befindet. Von links nach rechts listet die Ausgabe gewhnlich den Hostnamen des Nachbargerts unter der berschrift Device ID auf. In der nchsten Spalte erscheinen unter Local Intrfce Name und Nummer des lokalen Interface. Name und Nummer des Interface des Nachbargerts befin-den sich rechts in der Ausgabe unter der berschrift Port ID.

ICND2.indb 93 20.02.14 17:33


Listing 3.1 zeigt exemplarisch die Ausgabe von show cdp neighbors fr 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 fr welche Gerte 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 Sicherheitslcke. Um zu verhindern, dass ein Angreifer Kenntnis zu Einzelheiten der vorhandenen Switches erlangt, lsst 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 knnen Sie mit dem globalen Befehl no cdp run CDP fr 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 darber versenden kann . Insofern soll-te ein (durchaus naheliegender) Schritt beim Troubleshooting darin bestehen, den Status der einzelnen Interfaces zu verifizieren. Dies gilt insbesondere fr diejenigen Interfaces, von denen man annimmt, dass sie bei der Weiterleitung von Frames verwendet werden; diese sollten darauf geprft werden, ob sie aktiv sind und funktionieren.

In diesem Abschnitt untersuchen wir die mglichen Interface-Statusfestlegungen bei Cisco-IOS-basierten Switches, fhren wesentliche Ursachen fr Nichtbetriebszustnde auf und behan-deln ein verbreitetes Problem, das auch dann auftritt, wenn das Interface funktionsfhig zu sein scheint. Die wesentlichen Aufgaben fr diesen Schritt lassen sich wie folgt zusammenfassen:

Schritt 2: berprfen Sie wie folgt auf Interface-Probleme:

a. Bestimmen Sie den oder die Interface-Statuscodes fr 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. Prfen 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

Statuscodes bei Interfaces und Grnde fr NichtbetriebszustndeCisco-Switches verwenden zwei verschiedene Stze mit Interface-Statuscodes: einen Satz mit zwei Codes (Wrtern), 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 fhren wie bei Routern die Zweiwortcodes auf. Die beiden Codes heien 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 fr die Sicherungsschicht verwenden, weswegen das Sicherungsschichtprotokoll niemals ein Problem aufweisen sollte.

HINWEIS In diesem Buch werden die beiden Statuscodes verkrzt dargestellt, indem sie lediglich durch einen Schrgstrich voneinander getrennt werden (z. B. up/up).

Der Befehl show interfaces status fhrt 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 fr 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. Fr jeden Nichtbetriebsstatus gibt es jeweils einige wenige Ursachen. Beachten Sie auerdem, dass in den Prfungen durchaus eine Aufgabe auftauchen kann, bei der nur der eine oder andere Statuscode angegeben wird; berei-ten Sie sich also gut auf die Prfungen vor, indem Sie die Bedeutungen der beiden Interface-Statusscodes gewissenhaft studieren. Tabelle 3.2 fhrt die Codekombinationen sowie einige Ursachen fr den jeweiligen Interface-Status auf .

Tabelle 3.2 Statuscodes fr LAN-Switch-Interfaces

Line-Status Protokoll-status

Interface-status

Typische Problemursache

admin. down down disabled Fr das Interface wurde der Befehl shutdown konfiguriert.

down down notconnect Fehlendes oder schadhaftes Kabel, falsche Kabelbelegung, Geschwindigkeits-Mismatch bei zwei verbundenen Gerten, abgeschaltetes Gert oder Interface auf der Gegenseite

up down notconnect Auftreten bei LAN-Switch-Interfaces unwahrscheinlich

Schlssel-thema

ICND2.indb 95 20.02.14 17:33


Line-Status Protokoll-status

Interface-status

Typische Problemursache

down down (err-disabled)

err-disabled Interfaces durch Port-Security deaktiviert

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

up up connected Interface ist funktionsfhig .

Der Status notconnect und die KabelbelegungTabelle 3.2 fhrt verschiedene Grnde dafr auf, dass ein Interface sich im Status notconnect befindet. Viele dieser Grnde bedrfen keiner weiteren Erluterung: 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 Grnde fr das Auftreten eines solchen Status die falsche Kabelbelegung erfordert jedoch ein wenig mehr Aufmerksamkeit, weil es sich um einen hufig 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 fr UTP-Kabel beschreiben die Kontakte des RJ-45-Anschlusses, an die die einzelnen Leitungsdrhte am Kabelende angeschlossen werden mssen. Die Gerte bertragen Signale ber Leiterpaare, wobei 10BASE-T und 100BASE-T zwei Paare verwenden: je eines fr den Versand und den Empfang. Wenn man zwei Gerte miteinander verbindet, die fr den Signalversand dieselben Kontaktpaare verwenden, muss das verwendete Kabel ein Crossover-Kabel das bertragungskontaktpaar des einen Gerts berkreuz mit dem erwar-teten Empfangskontaktpaar des anderen Gerts verbinden. Umgekehrt wird fr Kabel, bei dem die Leiterpaare fr den Datenversand bereits entgegengesetzt angeordnet sind, ein Straight-Through-Kabel bentigt, welches die Kontakte nicht berkreuz ausfhrt. Abbildung 3.4 zeigt exemplarisch ein Switch-LAN, in dem die beiden Kabeltypen zum Einsatz kommen.

Gebude 1

Straight-Through-Kabel

Gebude 2

Straight-Through-Kabel

Crossover-Kabel

Switch 11

Switch 12

Switch 21

Switch 22

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

Fr ein effizientes Troubleshooting mssen Sie wissen, welche Gerte ber welche Leiterpaare bertragen. Tabelle 3.3 fhrt im CCNA-Kontext hufiger verwendete Gerte und die zugeh-rigen Paare auf. Beachten Sie, dass, wenn zwei Arten von Gerten in derselben Spalte aneinan-der angeschlossen werden sollen, ein Crossover-Kabel verwendet werden muss, whrend zur Verbindung zweier Gerte aus verschiedenen Spalten der Tabelle ein Straight-Through-Kabel zum Einsatz kommt.

Schlssel-thema

ICND2.indb 96 20.02.14 17:33


3

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

Gerte, die auf 1,2 senden und auf 3,6 empfangen

Gerte, 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. Standardmig 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 fr 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


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

Schlssel-thema

ICND2.indb 97 20.02.14 17:33


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, whrend full auf eine manuelle Konfiguration des Modus verweist. Die in diesem Listing abge-setzten Bereiche zeigen die folgenden Nachweise fr 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 Prfix a-)

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

Probleme bei Geschwindigkeit und DuplexmodusWenn Sie ein Troubleshooting durchfhren und das Problem im Bereich der bertragungs-geschwindigkeit oder des Duplexmodus liegt, kann es sinnvoll sein, sich die Gerte an beiden Seiten der Verbindung anzusehen. Die Gerte mssen nicht dieselben Geschwindigkeits- oder Duplexeinstellungen verwenden, was aber ggf. zu unterschiedlichen Ergebnissen fhrt:

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

Q 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.

Schlssel-thema

ICND2.indb 98 20.02.14 17:33


3

Interessanterweise ist es vergleichsweise schwierig, ein Mismatch bei Cisco-Switches ber-haupt zu erreichen. Natrlich werden die Gerte auf beiden Seiten der Verbindung, sofern sie das Autonegotiating nutzen, nachfolgend dieselbe Geschwindigkeit verwenden. Wenn das Autonegotiating jedoch auf dem benachbarten Gert 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 erwhnt fr ein Gigabit-Interface keine empfehlenswerten Einstellungen sind). SW2 wrde diese Einstellungen nun verwenden und das Autonegotiating abschalten, weil beide Befehle speed und duplex konfi-guriert wurden. Auch wenn fr 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 fr Switch-Interfaces anzeigen

SW1# show interfaces gi0/1 status


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

In diesem Listing werden Geschwindigkeit und Duplexeinstellung mit dem Prfix a- angezeigt, was auf das Autonegotiating hindeutet. Grund dafr ist in diesem Fall, dass die Geschwindig-keit automatisch ermittelt und die Duplexeinstellung basierend auf den vom IEEE-Auto-negotiating vorgegebenen Standardwerten gewhlt wurde. Die IEEE-Standards legen fest, dass bei Ports mit einer Rate von 100 Mbit/s standardmig der Halbduplexmodus gewhlt wird, wenn das Autonegotiating fehlschlgt.

Ein Mismatch bei der Geschwindigkeit lsst sich relativ einfach bilden, indem unterschiedliche Geschwindigkeiten auf den Gerten 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 vorbergehend immer wieder zu Problemen kommen.

Ein Duplex-Mismatch auf einem Link fhrt zu Problemen, weil ein Gert (die Halbduplex-seite) die CSMA/CD-Logik (Carrier Sense Multiple Access With Collision Detection) ver-

ICND2.indb 99 20.02.14 17:33


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 Gert den aktuellen Sendevorgang sofort abbricht. Das Vollduplexgert hingegen sendet Frames jeder-zeit, weswegen das Halbduplexgert irrtmlich davon ausgeht, dass Kollisionen stattfinden. Ist die Netzbelastung ausreichend hoch, dann befindet sich das Interface zwar im Status connected, ist aber fr die Weiterleitung von Daten weitgehend nutzlos und zudem sogar fr den Verlust wichtiger STP-Nachrichten verantwortlich .

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

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

Q berprfen Sie bestimmte Zhler bei Halbduplexinterfaces auf steigende Werte. Die ent-sprechenden Ereignisse Runts, Kollisionen und spte Kollisionen treten auf, wenn das andere Gert den Vollduplexmodus verwendet. (Beachten Sie jedoch, dass die Zhler auch bei normalen Kollisionen hochgezhlt werden.)

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

Die Ursache fr Duplex-Mismatches kann durch die Voreinstellungen bedingt sein, die beim IEEE-Autonegotiating ausgewhlt werden. Wenn ein Gert versucht, das Autonegotiating durchzufhren, und kein anderes Gert reagiert, whlt das erste Gert die Standardeinstellung fr den Duplexmodus basierend auf der aktuellen Geschwindigkeit aus. Nach Vorgabe des IEEE werden standardmig die folgenden Einstellungen gewhlt:

Q Liegt die Datenrate bei 10 oder 100 Mbit/s, dann wird standardmig der Halbduplex-modus festgelegt.

Q Liegt die Datenrate bei 1.000 Mbit/s, dann wird standardmig der Vollduplexmodus fest-gelegt.

HINWEIS Ethernet-Interfaces , die schneller als 1 Gbit/s sind, verwenden grundstzlich 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 knnten. So knnen etwa sowohl fr Router als auch fr 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-Prfungen, wohl aber eine hnliche Switch-Funktionalitt namens Port-Security. Wie in Kapitel 8 des offiziellen Handbuchs CCENT/CCNA ICND1 100-101 beschrieben, ist es Aufgabe von Port-Security, dafr zu sorgen, dass der Switch bestimmte Frames verwirft, die ber ein bestimmtes Interface eingehen oder versen-

Schlssel-thema

Schlssel-thema

ICND2.indb 100 20.02.14 17:33


3

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

Q Sie kann festlegen, welche MAC-Adressen Frames ber ein Switch-Interface versenden und empfangen knnen. Frames von oder an andere MAC-Adressen werden verworfen.

Q Sie kann die Anzahl der MAC-Adressen begrenzen, die das Interface verwenden drfen. Frames von oder an MAC-Adressen, die nach Erreichen des Hchstwerts erlernt wurden, werden verworfen.

Q Die beiden vorgenannten Punkte knnen auch kombiniert werden.

Der erste Schritt beim Troubleshooting in Verbindung mit der Port-Security besteht darin, herauszufinden, fr welche Interfaces die Port-Security aktiviert ist. Danach wird geprft, ob gegenwrtig Verste auftreten. Der kniffligste Teil bezieht sich auf unterschiedliche Reaktionen des IOS auf Verste basierend auf dem Interface-Subbefehl switchport port-security violation violation-modus; dieser Befehl bezeichnet dem Switch gegenber, was zu tun ist, wenn eine Violation (Versto) festgestellt wird. Generell sieht die Syntax wie folgt aus:

Schritt 3: berprfen Sie wie folgt auf Port-Security-Probleme:

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

b. Ermitteln Sie , ob gegenwrtig 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 fr den Violation-Zhler.

III. protect: Das Interface befindet sich im Status connect und der Befehl show port-security interface zeigt keinen ansteigenden Wert fr den Violation-Zhler.

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 zulssig 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 Schlsselpunkte der bersicht halber zusammen.

ICND2.indb 101 20.02.14 17:33


Tabelle 3.4 Aktionen bei Port-Security-Versten

Option des Befehls switchport port-security violation

Protect Restrict Shut Down*

Verwirft unzulssigen Datenverkehr Ja Ja Ja

Deaktiviert das Interface und verwirft den gesamten Datenverkehr

Nein Nein Ja

Erhht den Violation-Zhler bei jedem unzulssigen 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 fr die Verwendung der Port-Security konfiguriert wurde, eine Violation stattgefunden hat und zum gegenwrtigen 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 zunchst 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 fr 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 nchste Befehl zeigt den Status "err-disabled" an, was einen Sicherheitsversto impliziert.

SW1# show interfaces Fa0/13 status


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

!

! In der Ausgabe des nchsten Befehls sind die wichtigsten Details abgesetzt dargestellt.

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

Schlssel-thema

ICND2.indb 102 20.02.14 17:33


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 enthlt einige Elemente, die beim Trouble-shooting hilfreich sein knnen. Der Portstatus secure-shutdown bedeutet, dass das Interface infolge eines Verstoes fr den gesamten Datenverkehr gesperrt und der Interface-Status err-disabled zugewiesen wird. Am Ende der Befehlsausgabe wird ein Violation-Zhler aufgefhrt, der fr jeden neuen Versto um 1 erhht wird. Interessanterweise bewirkt ein Versto im shutdown-Modus, dass der Zhler um 1 erhht und das Interface in den Status err-disabled versetzt wird, weswegen der Zhler nachfolgend erst dann wieder hochgezhlt werden kann, wenn der Netzwerktechniker fr das Interface nacheinander die Befehle shutdown und no shutdown absetzt.

Beachten Sie schlielich, dass in der zweitletzten Zeile die Absender-MAC-Adresse des letzten ber das Interface empfangenen Frames angezeigt wird. Dieser Wert kann ntzlich sein, um die MAC-Adresse des Gerts 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 unzulssige 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 Grnde fr eine Nichtweiterleitung von Daten vorliegen knnen.

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 beschrnkt, die von 0200.1111.1111 bermittelt wurden.

Listing 3.5 Port-Security im protect-Modus

SW1# show running-config! Zeilen aus Platzgrnden gekrzt

interface FastEthernet0/13

switchport mode access

switchport port-security

switchport port-security mac-address 0200.1111.1111

switchport port-security violation protect

! Zeilen aus Platzgrnden gekrzt

ICND2.indb 103 20.02.14 17:33


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 unzulssigen PCs als Absender-MAC-Adresse des zuletzt empfangenen Frames an. Beachten Sie jedoch, dass der Portstatus secure-up aufgefhrt ist und der Violation-Zhler den Wert 0 hat; diese beiden Angaben knnten 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 knnen, dass tatschlich ein Versto stattgefunden hat. Der einzige Hinweis besteht darin, dass die Endbenutzerdaten nicht dahin gelangen, wohin sie sollen.

Wre in diesem Beispiel der Violation-Modus restrict verwendet worden, dann wre ebenfalls der Portstatus secure-up angezeigt worden, aber der Violation-Zhler wre pro unzulssigem Frame um den Wert 1 erhht worden.

Bei den Prfungen kann ein Port-Security-Versto durchaus kein Problem, sondern vielmehr die gewnschte Funktion darstellen. Mglicherweise gibt der Aufgabentext ausdrcklich an, was genau die Port-Security tun sollte. In solchen Fllen knnen Sie die Aufgabe schneller lsen, 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 Gerte. Das wahrscheinlichste Problem besteht bei den Prfungsaufgaben darin, dass die MAC-Adressen fehlkonfiguriert wurden oder die Hchstanzahl 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 standardmig festgelegte maximale Anzahl zulssiger MAC-Adressen fr das Interface (1).

Schlssel-thema

ICND2.indb 104 20.02.14 17:33


3

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

Schritt 5: (optional) Definieren Sie die zulssigen Absender-MAC-Adressen fr 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 hngt sowohl von der Definition der Access-VLANs an den Access-Interfaces als auch von den VLAN-Trunks ab, die Daten fr mehrere VLANs weiterleiten. Auerdem 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 Manahmen:

Schritt 4: berprfen 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 knnen.

Die nchsten drei Abschnitte beschreiben die Schritte 4a, 4b und 4c im Detail.

Sicherstellen, dass die richtigen Access-Interfaces sich in den richtigen VLANs befindenUm zu gewhrleisten, 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 zugehrigen Access-VLANs auf jedem Interface ermitteln und die gewonnenen Erkenntnisse mit der Dokumentation vergleichen. Die in Tabelle 3.5 aufgefhr-ten show-Befehle knnen dabei recht hilfreich sein.

ICND2.indb 105 20.02.14 17:33


Tabelle 3.5 Befehle zum Ermitteln von Access-Ports und VLANs

EXEC-Befehl Beschreibung

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

show vlan brief Gibt eine krzere Version derselben Informationen wie der Befehl show vlan aus

show vlan id num Listet Access-Ports fr 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-Tabelleneintrge auf, d. h. MAC-Adressen mit zugehrigen Interfaces und VLANs

Falls mglich, 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-hlt; vor allem geben diese Befehle Folgendes aus:

Q Interfaces, die gegenwrtig nicht als Trunks betrieben werden, Q Interfaces mit beliebigem Interface-Status einschlielich notconnect und err-disabled.

So knnen 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, knnte das Interface mit Trunking-Verhandlungen beginnen und wre 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 Prfungs-aufgabe nicht verfgbar sind, knnen 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 Prfungsaufgabe impliziert, dass ein Switch-Interface an einen Einzel-PC angeschlossen ist, sollte nur ein einzelner MAC-Tabelleneintrag aufgefhrt sein, der genau dieses Access-Interface auflistet; die fr diesen Eintrag angegebene VLAN-ID bezeichnet das Access-VLAN. (Bei Trunking-Interfaces sind derartige Annahmen jedoch nicht mglich.)

Nachdem Sie Access-Interfaces und zugehrige 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.

Schlssel-thema

ICND2.indb 106 20.02.14 17:33


3

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

Q der Switch ber keine Definition fr das VLAN x (beispielsweise ber den Befehl vlan x) verfgt,

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

Der nchste Troubleshooting-Schritt 4b ist eine Erinnerung, um sicherzustellen, dass jeder Switch ber eine Definition fr das VLAN verfgt 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. Fr die Zwecke dieses Buchs wollen wir annehmen, dass VTP deaktiviert oder in den transparenten Modus versetzt wurde. Deswegen mssen in unserem Szenario alle Switches mit dem Befehl vlan x konfiguriert worden sein, um das VLAN mit der Nummer x zu untersttzen.

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 mssen Sie das VLAN mit dem Konfigura-tionsbefehl vlan vlan-id hinzufgen. Wird es hingegen angezeigt, dann ist als Status active oder act/lshut aufgefhrt. 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 darber weitergeleitete VLANs ermittelnIn Schritt 4c knnen 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 gegenwrtig betriebsfhigen Trunks enthalten. Am besten beginnen Sie die Durchsicht im letzten Abschnitt der Ausgabe, denn dort sind VLANs aufgefhrt, deren Daten ber den Trunk weitergeleitet werden. VLANs, die es bis in diese abschlieende VLAN-Liste schaffen, weisen die folgenden Kriterien auf:

Q 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).

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

Q Das VLAN wurde nicht via VTP-Pruning aus dem Trunk entfernt . (Diese VTP-Funktion wird in diesem Abschnitt eigentlich ignoriert; sie ist hier nur aufgefhrt, weil sie in der Ausgabe des show-Befehls erwhnt wird.)

Q 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 fr 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


Listing 3.6 Listen zulssiger 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 aufgefhrten Grnde vorliegt. Allerdings kann es bei einer Prfungsaufgabe durchaus sinnvoll sein, zu wissen, warum Daten fr ein VLAN nicht ber einen Trunk weitergeleitet werden. Die Details in der Ausgabe nennen die jeweiligen Grnde.

Die Ausgabe des Befehls show interfaces trunk enthlt 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 Grnde dafr zusammen, warum ein VLAN vom Switch zur Liste hinzugefgt (oder eben nicht hinzugefgt) wird.

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

Listenposition berschrift Grund

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

Zweite VLANs allowed and active

Entspricht der ersten Liste abzglich 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 abzglich der durch STP geblockten und der durch VTP entfernten Interfaces

Bevor wir mit dem nchsten Thema fortfahren, sollten Sie an dieser Stelle auch die Konfigura-tion des nativen VLAN eines Trunks berprfen. 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, fgt er keinen VLAN-Header hinzu, da es sich ja um das native VLAN handelt. Empfngt nun Switch SW2 den Frame, so stellt er das Fehlen des 802.1Q-Headers fest und geht davon

Schlssel-thema

ICND2.indb 108 20.02.14 17:33

3.3 Beispiele und bungen zum Troubleshooting 109

3

aus, dass der Frame zum fr SW2 konfigurierten nativen VLAN gehrt. Wurde fr SW2 jedoch VLAN 2 als natives VLAN dieses Trunks konfiguriert, dann versucht SW2, den empfangenen Frame an VLAN 2 weiterzuleiten.

Abschlieend prfen 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 fr das Interface aktiviert und auf der Basis welcher Regeln es verhandelt werden soll. Mit dem Befehl show interface switchport zeigen Sie fr 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 fr 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 Fllen misslingt das Trunking fr 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 mssen 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 nchsten 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 zunchst eingegrenzt und dann ihre Ursachen ermittelt.

Schlssel-thema

ICND2.indb 109 20.02.14 17:33


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 flieen. 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 Fhigkeit 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-gefhrt. Dies sind die letzten LAN-spezifischen Themen Ihres CCNA-Studiums und sie fassen viele von Ihnen bereits erlernte Konzepte zusammen. Sie werden danach einschtzen knnen, wie gut Ihr Know-how im Bereich der Ethernet-LAN-Technologien ist. Der Kreis schliet 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 betrgt etwa zwlf Buchseiten. Sie knnen das Beispiel auf zweierlei Weise nutzen:

Q Zur Anschauung: In diesem Fall lesen Sie einfach ganz normal weiter.Q 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 mglichst viele Probleme, die Sie durch Analyse der Befehlsausgabe und Vergleich mit der Abbildung ermitteln knnen. Vergleichen Sie Ihre Liste mit der am Ende des Kapitels aufgefhrten. (Sie ist dort versteckt, um zu verhindern, dass Sie die Antworten versehentlich ersphen.) Danach knnen Sie den Begleittext zu den Listings lesen, wenn Sie Lcken im Troubleshooting-Beispiel schlieen mchten.

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 fr 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 ausfhrlich behandelt haben.

Wenn Sie das folgende Troubleshooting-Beispiel zur bung durcharbeiten, knnen Sie den nachfolgenden Text zunchst 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 Groteil 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 berprfen. 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





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 fr SW2

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




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


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 fr SW3





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 flschlich angegebene Interface hat unter Umstnden Auswirkungen auf den Netzwerkbetrieb. Wre beispielsweise zwischen SW2 und R1 ein Trunking erforderlich gewesen, dann htte dieses fr das Interface Fa0/9 nicht fr Fa0/10! explizit konfiguriert werden mssen, 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 prfenIm nchsten Schritt untersuchen wir den Status aller Interfaces

Documents

Troubleshooting Beim LAN-Switching