Sie sind auf Seite 1von 49

KAPITEL 3

Troubleshooting beim
LAN-Switching
Gemeinsam mit einigen anderen Kapiteln und Abschnitten hat das vorliegende Kapitel eine
wichtige Aufgabe: Es soll Ihnen dabei helfen, die fr das Troubleshooting erforderlichen Kenntnisse 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 anderes 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 naheliegendes Ziel. Zunchst einmal beschreibt es natrlich das Troubleshooting von LANs. Weniger
augenscheinlich drfte jedoch sein, dass in diesem Kapitel auch viele der Themen im Zusammenhang 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 Troubleshooting

Troubleshooting der LAN-Switching-Data-Plane

Beispiele und bungen zum Troubleshooting

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

82

Kapitel 3: Troubleshooting beim LAN-Switching

Fragen zur Einschtzung des Wissensstands


Weil die Kapitel zum Troubleshooting in diesem Buch Konzepte aus vielen anderen Kapiteln
darunter auch solchen aus dem offiziellen Handbuch Cisco CCENT/CCNA ICND1 100101 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 gegenwrtigen 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.

3.1 Allgemeine Anstze zum Troubleshooting

83

Grundlagenthemen
3.1 Allgemeine Anstze zum Troubleshooting
HINWEIS Die hier beschriebenen allgemeinen Anstze und Methoden zum Troubleshooting 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 unbewusst 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 funktionieren. 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 Reihenfolge 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 Netzwerk korrekt arbeitet, basierend auf der Dokumentation, der Konfiguration und der Ausgabe von show- und debug-Befehlen.

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.

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.

84

Kapitel 3: Troubleshooting beim LAN-Switching

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 TroubleshootingAblaufs angehen kann.

Normalbetrieb des Netzwerks analysieren und prognostizieren


Aufgabe eines jeden Netzwerktechnikers ist es, dafr Sorge zu tragen, dass Daten von einem
Endbenutzergert zu einem anderen bertragen werden. Um ein Netzwerk analysieren zu knnen, 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 vergegenwrtigt, 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 Weiterleitung 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 basierend 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 deaktivieren, 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 Troubleshooting hilfreich sein, sich zunchst mit der Control-Plane oder der Data-Plane zu beschftigen. 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 analysieren
Beim Troubleshooting in der Data-Plane werden alle Gerte im angenommenen Weiterleitungspfad 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 empfangende 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

3.1 Allgemeine Anstze zum Troubleshooting

85

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 analysieren. Abbildung 3.1 zeigt exemplarisch die sechs wesentlichen Schritte der IP-Weiterleitung
(Data-Plane) in einem kleinen Netzwerk.
1

PC1
SW1

SW3

R1

SW2

R2

SW4

5
6

SW5
4
PC2

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 denken 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-IPAdresse 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 vorherigen 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.

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, knnen 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).
STP-Blocking
PC1
1

SW1

SW3
2

R1
4

3
SW2

Abbildung 3.2 Wesentliche Schritte bei der LAN-Switching-Weiterleitung


Fr diese Analyse beginnen Sie zunchst wieder bei PC1. Diesmal berprfen Sie EthernetHeader 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 analysieren
Viele Prozesse in der Control-Plane wirken sich direkt auf den Data-Plane-Prozess aus. So funktioniert beispielsweise der Data-Plane-Prozess des IP-Routings nicht ohne geeignete IP-Routen,
d. h., Router verwenden normalerweise ein dynamisches Routing-Protokoll ein ControlPlane-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 STPspezifischer Probleme beheben kann.

3.1 Allgemeine Anstze zum Troubleshooting

87

Zusammenfassung zur Prognose des Normalbetriebs


Bei den Prfungen wird die eine oder andere Aufgabe auf Sie zukommen, bei der Sie den normalen 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 empfohlene 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 ordnungsgemen 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 eingrenzen
Beim 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.

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 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 aufgetreten ist. Die Problemursache kann allerdings jedes Element der folgenden Liste sein:
Q

Der Trunk zwischen SW4 und SW5 kann deaktiviert worden sein.

Das Kabel zwischen SW5 und PC2 ist unter Umstnden schadhaft.

In der IPv4-Konfiguration von PC2 ist die IP-Adresse von PC2 mglicherweise nicht festgelegt.

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 spezifischer 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 Problemeingrenzung:
Schritt 1: Untersuchen Sie zunchst die Schicht-3-Data-Plane (IP-Weiterleitung) und vergleichen 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 CCNAPrfungen ebenfalls den Schwerpunkt auf diese drei Schichten legen. Sehen Sie aber zu, dass
Sie diesen Vorgang so weit abkrzen, wie es die Frage gestattet.

3.1 Allgemeine Anstze zum Troubleshooting

89

Ursachenanalyse
Der 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.

R2 erhlt 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 fr den
letzten Eintrag in der Liste gibt es eine naheliegende Lsung (nmlich den Austausch des vorhandenen Kabels gegen ein ordnungsgem belegtes). Zwar sind die anderen Aussagen zutreffende 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 Praxis


Suchen 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 LANSwitching zuwenden.

90

Kapitel 3: Troubleshooting beim LAN-Switching

3.2 Troubleshooting bei der LAN-Switching-DataPlane


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 bevorstehende 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 unterbrechen 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 nchste 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 RoutingSchritt 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 IPv4Routing (Teil 1), 5, Troubleshooting beim IPv4-Routing (Teil 2), und 11, Troubleshooting
von IPv4-Routing-Protokollen, behandelt. Im vorliegenden Kapitel wird auch auf ControlPlane-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 ausfhrlich jeweils einen Troubleshooting-Schritt.

Der normale Weiterleitungsprozess bei LAN-Switches in der


bersicht
In 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 bercksichtigt. 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:

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

91

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 AccessVLAN 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 ForwardingStatus befindet, fgt der Switch die Absender-MAC-Adresse zu seiner MACAdresstabelle 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-ForwardingStatus befindet, wird der Frame verworfen.
Schritt 4: Der Switch sucht nach der Empfnger-MAC-Adresse des Frames in der MACAdresstabelle, jedoch nur fr Eintrge im in Schritt 1 ermittelten VLAN. Je
nachdem, 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 sicherzustellen, 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 MACAdresse an sein Default-Gateway R1.
0200.1111.1111
PC1

PC2

Fa0/11
Fa0/12

Gi0/1

Gi0/2

SW1
Gi0/2

Fa0/10
SW2
Gi0/1

Gi0/1
R1
0200.0101.0101

0200.2222.2222
Gi0/1

Gi0/2

SW3
Fa0/13
PC3

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


Kapitel 3

92

Kapitel 3: Troubleshooting beim LAN-Switching

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 AccessInterface oder als Trunk verwendet wird. In diesem Fall handelt es sich um ein AccessInterface, das VLAN 3 zugewiesen ist.

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.

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

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 TrunkInterface, 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 TroubleshootingVorgang 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 berprfen, 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 verschiedene 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 offiziellen 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.

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

93

Schritt 1: Netzwerkdiagramme mit CDP verifizieren


Das 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 berholt; 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 Angaben auf Richtigkeit und Vollstndigkeit.
HINWEIS Dieses Kapitel zeigt eine Anzahl von Schritten zur Behebung von SwitchingProblemen, 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 aufgefhrten 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 befinden sich rechts in der Ausgabe unter der berschrift Port ID.

94

Kapitel 3: Troubleshooting beim LAN-Switching

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

SW1

Gig 0/2

154

SW3

Gig 0/1

R1

Fas 0/10

Capability

Platform

Port ID

S I

WS-C2960- Gig 0/1

170

S I

WS-C2960- Gig 0/2

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 deaktivieren. Cisco empfiehlt die Deaktivierung von CDP auf allen Interfaces, bei denen kein spezieller 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 InterfaceSubbefehl 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 eingrenzen


Ein 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 sollte 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 CiscoIOS-basierten Switches, fhren wesentliche Ursachen fr Nichtbetriebszustnde auf und behandeln 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.

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

95

Statuscodes bei Interfaces und Grnde fr Nichtbetriebszustnde


Cisco-Switches verwenden zwei verschiedene Stze mit Interface-Statuscodes: einen Satz
mit zwei Codes (Wrtern), die dieselben Konventionen wie die Statuscodes von RouterInterfaces 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-SwitchInterfaces werden beide Codes entweder als up oder als down angegeben, weil alle SwitchInterfaces 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; dieser 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; bereiten Sie sich also gut auf die Prfungen vor, indem Sie die Bedeutungen der beiden InterfaceStatusscodes 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- Interfacestatus


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

Schlsselthema

96

Kapitel 3: Troubleshooting beim LAN-Switching

Line-Status Protokoll- Interfacestatus


status

Typische Problemursache

down

Interfaces durch Port-Security deaktiviert

up

down (errdisabled)

err-disabled

up

connected

Bei EtherChannels wird dieser Status fr Interfaces verwendet, deren Konfiguration sich von der
anderer Interfaces im EtherChannel unterscheidet.
Interface ist funktionsfhig.

Der Status notconnect und die Kabelbelegung


Tabelle 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 erwarteten Empfangskontaktpaar des anderen Gerts verbinden. Umgekehrt wird fr Kabel, bei dem
die Leiterpaare fr den Datenversand bereits entgegengesetzt angeordnet sind, ein StraightThrough-Kabel bentigt, welches die Kontakte nicht berkreuz ausfhrt. Abbildung 3.4 zeigt
exemplarisch ein Switch-LAN, in dem die beiden Kabeltypen zum Einsatz kommen.
Schlsselthema

Gebude 1

Gebude 2
Switch 11

StraightThroughKabel

Switch 21
CrossoverKabel

Switch 12

StraightThroughKabel

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 zugehrigen Paare auf. Beachten Sie, dass, wenn zwei Arten von Gerten in derselben Spalte aneinander 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.

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

97

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)

Schlsselthema

Switch-Interface-Geschwindigkeit und Duplexmodus bestimmen


Switch-Interfaces ermitteln ihre Geschwindigkeits- und Duplexeinstellungen auf unterschiedliche 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
Geschwindigkeits- 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

Fa0/11

link to PC1

connected

a-full

Speed Type
100 10/100BaseTX

SW1# show interfaces f0/12 status


Port

Name

Status

Vlan

Duplex

Speed Type

Fa0/12

link to PC2

connected

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

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,
whrend full auf eine manuelle Konfiguration des Modus verweist. Die in diesem Listing abgesetzten 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 Geschwindigkeits- und Duplexeinstellungen auffhrt, nicht jedoch, wie der Switch die Werte erlernt oder
festgelegt hat.

Probleme bei Geschwindigkeit und Duplexmodus


Wenn Sie ein Troubleshooting durchfhren und das Problem im Bereich der bertragungsgeschwindigkeit 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:
Schlsselthema

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

Duplex-Mismatch: Verwenden die Endpunkte dieselbe Geschwindigkeit, aber unterschiedliche Duplexmodi, dann werden die Interfaces zwar aktiviert, aber bestimmte Leistungsindikatoren werden Probleme auf der Seite der Verbindung melden, die im Halbduplexmodus betrieben wird.

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

99

Interessanterweise ist es vergleichsweise schwierig, ein Mismatch bei Cisco-Switches berhaupt 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 vorausgesetzt, 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 GigabitInterface keine empfehlenswerten Einstellungen sind). SW2 wrde diese Einstellungen nun
verwenden und das Autonegotiating abschalten, weil beide Befehle speed und duplex konfiguriert 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


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 Prfix a- angezeigt,
was auf das Autonegotiating hindeutet. Grund dafr ist in diesem Fall, dass die Geschwindigkeit automatisch ermittelt und die Duplexeinstellung basierend auf den vom IEEE-Autonegotiating 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 Halbduplexseite) die CSMA/CD-Logik (Carrier Sense Multiple Access With Collision Detection) ver-

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 Gert
den aktuellen Sendevorgang sofort abbricht. Das Vollduplexgert hingegen sendet Frames jederzeit, 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:
Schlsselthema

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

berprfen Sie bestimmte Zhler bei Halbduplexinterfaces auf steigende Werte. Die entsprechenden 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 hervorgehoben.
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:
Schlsselthema

Liegt die Datenrate bei 10 oder 100 Mbit/s, dann wird standardmig der Halbduplexmodus festgelegt.

Liegt die Datenrate bei 1.000 Mbit/s, dann wird standardmig der Vollduplexmodus festgelegt.
HINWEIS Ethernet-Interfaces, die schneller als 1 Gbit/s sind, verwenden grundstzlich den
Vollduplexmodus.

Schritt 3: Probleme in Zusammenhang mit Filterung und


Port-Security beheben
Allgemein gesagt sollte jede Analyse des Weiterleitungsprozesses auch alle Sicherheitsfunktionen 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, Zugriffssteuerungslisten) 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 SwitchFunktionalitt 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-

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

101

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.

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.

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 portsecurity 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 PortSecurity-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 konfigurierten 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.

102

Kapitel 3: Troubleshooting beim LAN-Switching

Tabelle 3.4 Aktionen bei Port-Security-Versten


Schlsselthema

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-disabled (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 ViolationModus 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-security
Secure Port

MaxSecureAddr

CurrentAddr

(Count)

(Count)

SecurityViolation

Security Action

(Count)

--------------------------------------------------------------------------Fa0/13

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
Port

Name

Fa0/13

Status

Vlan

err-disabled 1

Duplex
auto

Speed Type
auto 10/100BaseTX

!
! In der Ausgabe des nchsten Befehls sind die wichtigsten Details abgesetzt
dargestellt.
SW1# show port-security interface Fa0/13
Port Security

: Enabled

3.2 Troubleshooting bei der LAN-Switching-Data-Plane


Port Status

: Secure-shutdown

Violation Mode

: Shutdown

Aging Time

: 0 mins

Aging Type

: Absolut

103

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 Troubleshooting hilfreich sein knnen. Der Portstatus secure-shutdown bedeutet, dass das Interface
infolge eines Verstoes fr den gesamten Datenverkehr gesperrt und der Interface-Status errdisabled 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 ViolationModi 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

104

Kapitel 3: Troubleshooting beim LAN-Switching

SW1# show port-security interface Fa0/13


Port 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-SecurityKonfiguration 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 ViolationZhler den Wert 0 hat; diese beiden Angaben knnten von Ihnen dahingehend interpretiert werden, dass alles in Ordnung ist. Allerdings zeigt der Befehl show port-security interface im protect-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:
Schlsselthema

Schritt 1: Konfigurieren Sie das Switch-Interface mit den Interface-Subbefehlen switchport


mode access bzw. switchport mode trunk wahlweise als Access- oder TrunkInterface.
Schritt 2: Aktivieren Sie die Port-Security mit dem Interface-Subbefehl switchport portsecurity.
Schritt 3: (optional) berschreiben Sie mit dem Interface-Subbefehl switchport portsecurity maximum nummer die standardmig festgelegte maximale Anzahl
zulssiger MAC-Adressen fr das Interface (1).

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

105

Schritt 4: (optional) berschreiben Sie die Standardaktion beim Auftreten eines Sicherheitsverstoes (shutdown) mit dem Interface-Subbefehl switchport port-security
violation {protect | restrict | shutdown}.
Schritt 5: (optional) Definieren Sie die zulssigen Absender-MAC-Adressen fr das Interface
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 portsecurity mac-address sticky an, unter Verwendung von Sticky-Learning MACAdressen dynamisch zu erlernen.

Schritt 4: VLAN- und Trunking-spezifische Probleme beheben


Der 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 wichtige 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 aktivieren Sie nach Bedarf die VLANs, um Probleme zu beheben.
c. Ermitteln Sie betriebsbereite Trunking-Interfaces an jedem Switch und bekommen Sie heraus, welche VLANs ber die jeweiligen Trunks weitergeleitet werden 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


befinden
Um 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 aufgefhrten show-Befehle knnen dabei recht hilfreich sein.

106

Kapitel 3: Troubleshooting beim LAN-Switching

Tabelle 3.5 Befehle zum Ermitteln von Access-Ports und VLANs


Schlsselthema

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 enthlt; vor allem geben diese Befehle Folgendes aus:
Q

Interfaces, die gegenwrtig nicht als Trunks betrieben werden,

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 enthalten, 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, weswegen 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 Prfungsaufgabe 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 MACTabelleneintrag 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.

3.2 Troubleshooting bei der LAN-Switching-Data-Plane

107

Nicht definierte oder inaktive Access-VLANs


Ein 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,

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
einfach entnehmen. Ist das VLAN auf dem Switch nicht vorhanden, dann ist es in der Befehlsausgabe schlicht nicht angegeben; in diesem Fall mssen Sie das VLAN mit dem Konfigurationsbefehl 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 ermitteln


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

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.

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

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.

108

Kapitel 3: Troubleshooting beim LAN-Switching

Listing 3.6 Listen zulssiger und aktiver VLANs


SW1# show interfaces trunk
Port

Mode

Encapsulation

Status

Native vlan

Gi0/1

desirable

802.1q

trunking

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
Schlsselthema

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 Konfiguration 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 unterschiedliche 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 sendet, 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

3.3 Beispiele und bungen zum Troubleshooting

109

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-Konfiguration 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 kennen. 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 TrunkingBetriebsmodus

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 Troubleshooting


Der 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 aufgetreten. Von diesem Szenario ausgehend werden mithilfe des in diesem Kapitel beschriebenen,
vier Schritte umfassenden Prozesses die Probleme zunchst eingegrenzt und dann ihre Ursachen
ermittelt.

Schlsselthema

110

Kapitel 3: Troubleshooting beim LAN-Switching

Im zweiten Beispiel verwenden wir dasselbe LAN wie im ersten, wobei hier alle Probleme behoben 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 showBefehls zu studieren und dessen Auswirkungen auf ein Netzwerkdiagramm zu bertragen. In
den beiden folgenden Beispielen werden nach letztem Stand insgesamt 34 show-Befehle aufgefhrt. 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


suchen
Im ersten Beispiel finden Sie ein Netzwerkdiagramm und eine Reihe von Listings mit showBefehlen 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.

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 TroubleshootingBeispiel schlieen mchten.

2.2.2.1
0200.1111.1111
PC1

PC2

2.2.2.2
0200.2222.2222

Fa0/11
Fa0/12

Gi0/1

Gi0/2

SW1
Gi0/2

Fa0/10
SW2
Gi0/1

Gi0/1

Gi0/1
R1
2.2.2.9
0200.0101.0101

Gi0/2

SW3
Fa0/13
PC3

2.2.2.3
0200.3333.3333

Abbildung 3.5 Netzwerkdiagramm als Ausgangspunkt fr das TroubleshootingBeispiel 1

3.3 Beispiele und bungen zum Troubleshooting

111

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 verifizieren


Listing 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
SW1# 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

SW2

Gig 0/1

170

Capability
S I

Platform

WS-C2960- Gig 0/2

Port ID

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
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID

Local Intrfce

Holdtme

SW1

Gig 0/2

146

SW3

Gig 0/1

R1

Fas 0/9

Capability

Platform

Port ID

S I

WS-C2960- Gig 0/1

162

S I

WS-C2960- Gig 0/2

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,
Interface: FastEthernet0/9,
Holdtime : 148 sec

Capabilities: Router Switch IGMP

Port ID (outgoing port): GigabitEthernet0/1

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

SW1

Gig 0/1

167

Capability
S I

Platform

WS-C2960- Gig 0/2

Port ID

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 Endbenutzer-PCs verbunden sind; im vorliegenden Beispiel wollen wir davon ausgehen, dass die
brigen in Abbildung 3.5 gezeigten Interfaces korrekt sind.

Schritt 2: Auf Interface-Probleme prfen


Im nchsten Schritt untersuchen wir den Status aller Interfaces, die gegenwrtig 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 nher untersuchen
mchten.
Listing 3.8 Interface-Probleme auf SW1 und SW3
SW1# show interfaces fa0/11 status
Port

Name

Fa0/11

Status

Vlan

Duplex

Speed Type

connected

a-full

a-100 10/100BaseTX

Status

Vlan

Duplex

Speed Type

notconnect

SW1# show interfaces fa0/12 status


Port
Fa0/12

Name

auto

auto 10/100BaseTX

3.3 Beispiele und bungen zum Troubleshooting

113

SW1# show interfaces Gi0/1 status


Port

Name

Gi0/1

Status

Vlan

Duplex

connected

trunk

a-full a-1000 10/100/1000BaseTX

Speed Type

Status

Vlan

Duplex

connected

trunk

SW1# show interfaces Gi0/2 status


Port

Name

Gi0/2

Speed Type

a-full a-1000 10/100/1000BaseTX

! Wechsel zu SW3
SW3# show interfaces fa0/13 status
Port

Name

Fa0/13

Status

Vlan

Duplex

Speed Type

connected

a-half

a-100 10/100BaseTX

Status

Vlan

Duplex

Speed Type

connected

trunk

a-full a-1000 1000BaseTX

Status

Vlan

Duplex

connected

trunk

a-full a-1000 1000BaseTX

SW3# show interfaces Gi0/1 status


Port

Name

Gi0/1

SW3# show interfaces Gi0/2 status


Port

Name

Gi0/2

Speed Type

Ein auf SW1 vorhandenes Problem ist offensichtlich: Das Interface Fa0/12 hat den Status notconnect. Hierfr gibt es viele mgliche Ursachen, die sich allerdings fast alle auf ein Verkabelungsproblem zurckfhren lassen. Dies kann alles Mgliche sein vom nicht vollstndig in den
Switch-Port eingesteckten Kabel bis hin zu schwer ermittelbaren Problemen mit elektrischen
Strungen. (Mgliche Ursachen knnen Sie Tabelle 3.2 entnehmen.)
Fr die Interfaces von SW3 lassen sich offenbar keine Probleme feststellen. Allerdings weisen
alle drei Interfaces eine Duplexeinstellung auf, die derjenigen entspricht, die ein Switch verwenden wrde, wenn das Autonegotiating fehlgeschlagen ist; auffllig ist die Verwendung der
Halbduplexeinstellung auf Interface Fa0/13. Dies verweist auf die Mglichkeit eines DuplexMismatch.
Ein Mismatch der SW3-Interfaces Gigabit 0/1 und 0/2 knnen Sie ganz einfach ausschlieen,
indem Sie den Befehl show interfaces status am jeweils anderen Ende dieser beiden Verbindungen 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 Nhe des betreffenden PCs befinden und deswegen den Endbenutzer bei der
Durchfhrung der Schritte anleiten mssen, die zur berprfung der Geschwindigkeits- und
Duplexeinstellungen erforderlich sind. Trotzdem ist es sinnvoll, nach verrterischen Hinweisen
auf Runts, Kollisionen und spte 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/13
FastEthernet0/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

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 tatschlich ein Duplex-Mismatch vor, weil der Switch-Port den Halbduplexmodus verwendet. Beachten Sie jedoch, dass dieselben Zhler auch bei normalem Halbduplexbetrieb hochgezhlt werden, weswegen sie nicht in jedem Fall dazu beitragen knnen,
das vorliegende Problem zu erkennen.
Hier muss die Konfiguration des Interface Fa0/13 von SW3 vom Halbduplex- auf den Vollduplexbetrieb umgestellt werden, um eine bereinstimmung mit der manuellen Einstellung auf
PC3 zu erzielen.

Schritt 3: Auf Port-Security-Probleme prfen


Im nun folgenden Schritt untersuchen wir die Port-Security-Konfiguration und den Status der
einzelnen Switches. Die erste Manahme besteht im Absetzen des Befehls show port-security.
Dies ist besonders ntzlich, weil der Befehl die Interfaces auffhrt, 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 PortSecurity aktiviert ist.
Studieren Sie das Listing 3.10 und machen Sie sich vor dem Weiterlesen ein paar Notizen
dazu, welche weiteren Schritte Sie durchfhren wrden, um die Port-Security als potenzielle
Problemquelle auszuschlieen, und/oder mit welchem Befehl Sie ein mgliches Problem weiter
eingrenzen wrden.

3.3 Beispiele und bungen zum Troubleshooting

115

Listing 3.10 Port-Security auf SW1 und SW2


SW1# show port-security
Secure Port

MaxSecureAddr

CurrentAddr

(Count)

(Count)

SecurityViolation

Security Action

(Count)

--------------------------------------------------------------------------Fa0/11

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-security
Secure Port

MaxSecureAddr

CurrentAddr

(Count)

(Count)

SecurityViolation

Security Action

(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 fhren die Interfaces auf, auf denen die PortSecurity 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 zunchst einmal
festgestellt haben, dass unter der berschrift Security Action fr 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 verstoen. Also ist eine nhere 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/11
Port 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 Nchstes zeigt die Konfiguration, dass die konfigurierte MAC-Adresse
! nicht mit der MAC-Adresse von PC1 bereinstimmt.
SW1# show running-config interface fa0/11

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 PortFastEthernet0/11.

Das Listing beginnt mit Angaben zum Sicherheitsmodus und zum Violation-Zhler und zeigt
auch die letzte MAC-Adresse an, die einen Frame an das Interface Fa0/11 gesendet hat (nmlich 0200.1111.1111). Die MAC-Adresse von PC1 (0200.1111.1111) entspricht nicht der PortSecurity-Konfiguration, wie man dem zweiten Teil des Listings entnehmen kann; diese legt
maximal eine zulssige MAC-Adresse fest, die zudem explizit konfiguriert ist (0200.3333.3333).
Eine einfache Lsung besteht darin, die Port-Security so umzukonfigurieren, dass sie die MACAdresse von PC1 angibt. Beachten Sie, dass der Netzwerktechniker die Befehle shutdown und
nachfolgend no shutdown fr den Neustart dieses Interface nicht absetzen muss, denn die
Konfiguration verwendet den Violation-Modus restrict, der das Interface laufen lsst und nur
Daten von und an PC1 verwirft.
Am Ende des Listings schlielich findet sich eine Logmeldung, die vom Switch fr jeden
Versto im restrict-Modus generiert wird. Diese Meldung wrde auf der Konsole oder ber
eine Telnet- oder SSH-Verbindung (Secure Shell) zum Switch ausgegeben, wenn der RemoteBenutzer den EXEC-Befehl terminal monitor absetzte. Sie kann auch von einem Syslog-Server
erfasst werden (siehe Kapitel 19, Netzwerkgerte verwalten).

Schritt 4: Auf VLAN- und VLAN-Trunk-Probleme prfen


Schritt 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 ntzliche show-Ausgaben. Nehmen Sie sich einen Moment Zeit und
studieren Sie das Listing. Suchen Sie dort nach mglichen 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
standardmig Bestandteil von VLAN 1. Um dieses spezielle Problem zu beheben, setzen wir
auf SW2 den Interface-Subbefehl switchport access vlan 3 fr Interface Fa0/9 ab.
Im nun nachfolgenden Schritt 4b wird vorgeschlagen, die VLANs zu berprfen, um sicherzustellen, dass sie auf allen Switches aktiv sind. In unserem Beispiel kommt nur VLAN 3 zum
Einsatz. Listing 3.13 zeigt, dass VLAN 3 tatschlich auf allen Switches bekannt ist. Suchen Sie
beim Lesen des Listings nach Problemen mit VLAN 3.

3.3 Beispiele und bungen zum Troubleshooting

117

Listing 3.12 VLAN-Zuordnungen von Access-Interfaces berprfen


SW1# show interfaces fa0/11 status
Port

Name

Fa0/11

Status

Vlan

Duplex

Speed Type

connected

a-full

a-100 10/100BaseTX

Status

Vlan

Duplex

Speed Type

notconnect

auto

auto 10/100BaseTX

SW1# show interfaces fa0/12 status


Port

Name

Fa0/12
! Nun SW2
SW2# show interfaces status

! Zeilen aus Platzgrnden gekrzt


Fa0/9

connected

a-full

a-100 10/100BaseTX

Fa0/10

notconnect

auto

auto 10/100BaseTX

! Nun SW3
SW3# show interfaces fa0/13 status
Port

Name

Fa0/13

Status

Vlan

connected

Duplex
full

Speed Type
a-100 10/100BaseTX

Listing 3.13 Auf aktive VLANs prfen


SW1# show vlan id 3
VLAN Name

Status

Ports

---- -------------------------------- --------- ------------------------------3

book-vlan3

active

Fa0/11, Fa0/12, Gi0/1, Gi0/2

Status

Ports

! Zeilen aus Platzgrnden gekrzt


! Nun SW2
SW2# show vlan brief
VLAN Name

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

VLAN0003

! Zeilen aus Platzgrnden gekrzt


! Nun SW3
SW3# show vlan brief

active

Fa0/9, Fa0/10

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

book-vlan3

active

Fa0/13

! Zeilen aus Platzgrnden gekrzt

In diesem Fall ist VLAN 3 vorhanden und auf allen drei Switches aktiv. SW2 fhrt jedoch einen
anderen Namen auf als die beiden anderen Switches. Fr den Betrieb des VLAN ist dieser Name
nicht von Bedeutung, weswegen der Unterschied keine Rolle spielt.
Der letzte Teilschritt 4c schlielich empfiehlt, den Trunking-Status aller angenommenen
Trunk-Interfaces zu verifizieren. Auerdem 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
gegenwrtig keine Daten in VLAN 3 weiterleiten. Ergnzen Sie auf Ihrer Liste mgliche Grnde
dafr, dass VLAN 3 vom Trunk nicht bercksichtigt wird.
Listing 3.14

Trunking und VLAN 3 berprfen

SW1# show interfaces trunk


Port

Mode

Encapsulation

Status

Native vlan

Gi0/1

desirable

802.1q

trunking

Gi0/2

desirable

802.1q

trunking

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

Gi0/2

1,3

! Nun SW2
SW2# show interfaces trunk
Port

Mode

Encapsulation

Status

Native vlan

Gi0/1

auto

802.1q

trunking

Gi0/2

auto

802.1q

trunking

3.3 Beispiele und bungen zum Troubleshooting


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

119

! Nun SW3
SW3# show interfaces trunk
Port

Mode

Encapsulation

Status

Native vlan

Gi0/1

auto

802.1q

trunking

Gi0/2

desirable

802.1q

trunking

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 zunchst 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 knnen diesen Sachverhalt aber eigentlich bereits der
Ausgabe im Listing entnehmen. Hierzu mssen Sie lediglich alle anderen Grnde dafr ausschlieen, warum VLAN 3 nicht in den vom Befehl show interfaces trunk ausgegebenen Listen
enthalten ist:
Q

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 zulssiger VLANs fr 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, knnen
PC1, PC3 und R1 nun erfolgreich Ping-Befehle aneinander senden. Allerdings funktioniert PC2
aufgrund eines nicht spezifizierten Verkabelungsproblems immer noch nicht.

120

Kapitel 3: Troubleshooting beim LAN-Switching

Troubleshooting-Beispiel 2: Verhalten der LAN-Data-Plane


vorhersagen
Dieses zweite Beispiel verfolgt einen vollkommen anderen Ansatz als das erste. Am Anfang steht
keine Vielzahl von Problemen, sondern ein vollkommen funktionsfhiges 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 vorhandene Fehler. Das LAN funktioniert also und wir knnen 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:
Q

PC1 sendet einen ARP-Request fr Router R1 als Broadcast-Frame.

R1 sendet eine ARP-Reply als Unicast-Frame zurck an PC1.

Abbildung 3.6 zeigt das funktionsfhige 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.
0200.1111.1111
PC1

PC2

Fa0/11
Fa0/12

Gi0/1

Gi0/2

SW1
Gi0/2

Fa0/9
SW2
Gi0/1

Gi0/1
R1
0200.0101.0101

0200.2222.2222
Gi0/1

Gi0/2

SW3
Fa0/13
PC3

Abbildung 3.6 Netzwerk fr das Troubleshooting-Beispiel 2


HINWEIS Das Netzwerk fr dieses Beispiel ist mit dem fr das vorherige identisch, wobei
hier alle Probleme behoben sind. Alle Access-Ports befinden sich in VLAN 3.
Falls Sie dieses Beispiel zur bung bearbeiten mchten, analysieren Sie Abbildung 3.6 und die
Listings und ignorieren Sie den dazwischen stehenden Text. Notieren Sie sich ausfhrlich alles,
was Sie ber den Weg des ARP-Broadcasts von PC1 und den der ARP-Reply von R1 herauskriegen knnen. Sie knnen das Beispiel natrlich, wenn Sie wollen, auch zur Anschauung verwenden; lesen Sie in diesem Fall einfach weiter.

Der ARP-Request (Broadcast) von PC1


Wenn PC1 ein IP-Paket in ein anderes Subnetz senden muss, dann bergibt er das Paket an seinen Default-Router. In diesem Fall agiert R1 als Default-Router von PC1. PC1 verfgt in seinem
ARP-Cache unter Umstnden nicht ber die MAC-Adresse von R1 und sendet in diesem Fall
einen ARP-Broadcast mit der Ethernet-Empfngeradresse FFFF.FFFF.FFFF.

3.3 Beispiele und bungen zum Troubleshooting

121

Um den Weg des Broadcasts zu analysieren, orientieren Sie sich am allgemeinen Weiterleitungsvorgang, wie er im Abschnitt Der normale Weiterleitungsprozess bei LAN-Switches in der
bersicht weiter oben in diesem Kapitel zusammengefasst wurde. Frhere Listings besttigten, 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
gengend Informationen, um feststellen zu knnen, 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

Port

26 (GigabitEthernet0/2)

Hello Time
Bridge ID

Interface

2 sec

Max Age 20 sec

Priority

32771

Address

1833.9d7b.0e80

Forward Delay 15 sec

(priority 32768 sys-id-ext 3)

Hello Time

2 sec

Aging Time

300 sec

Max Age 20 sec

Role Sts Cost

Forward Delay 15 sec

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. Auerdem 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 fgt
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 SW2Eingangsinterface Gi0/2 sich im VLAN 3 im Blocking-Status befindet (siehe Listing 3.16).

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

Port

25 (GigabitEthernet0/1)

Hello Time
Bridge ID

2 sec

Max Age 20 sec

Priority

32771

Address

1833.9d7b.1380

(priority 32768 sys-id-ext 3)

Hello Time

2 sec

Aging Time

300 sec

Interface

Forward Delay 15 sec

Max Age 20 sec

Role Sts Cost

Forward Delay 15 sec

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 STPForwarding-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

----

-----------

--------

-----

0200.0101.0101

DYNAMIC

Gi0/2

0200.1111.1111

DYNAMIC

Gi0/1

0200.2222.2222

DYNAMIC

Gi0/1

0200.3333.3333

DYNAMIC

Fa0/13

Total Mac Addresses for this criterion: 4

3.3 Beispiele und bungen zum Troubleshooting

123

SW3# show spanning-tree vlan 3 active


VLAN0003
Spanning tree enabled protocol ieee
Root ID

Priority

20483

Address

f47f.35cb.d780

This bridge is the root


Hello Time
Bridge ID

2 sec

Max Age 20 sec

Priority

20483

Address

f47f.35cb.d780

(priority 20480 sys-id-ext 3)

Hello Time

2 sec

Aging Time

300 sec

Interface

Forward Delay 15 sec

Max Age 20 sec

Role Sts Cost

Forward Delay 15 sec

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.
Auerdem fgt, weil sein Interface Gi0/2 gegenwrtig das 802.1Q-Trunking mit dem nativen
VLAN 1 verwendet, SW3 einen 802.1Q-Header mit der VLAN-ID 3 hinzu.
Schlielich arbeitet SW2, wenn er von SW3 die Kopie des Broadcasts ber sein Interface Gi0/1
empfngt, denselben allgemeinen Prozess wie die anderen Switches ab. SW2 identifiziert das
VLAN basierend auf dem eingehenden 802.1Q-Header, vergewissert sich, dass sich das eingehende 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 dazugehrigen Ausgaben.
Listing 3.18 SW2: Weiterleitung eines von SW3 empfangenen Broadcasts in VLAN 3
! Beachten Sie zunchst, dass die Broadcast-Adresse FFFF.FFFF.FFFF
! nicht in der MAC-Tabelle in VLAN3 enthalten ist
SW2# show mac address-table dynamic vlan 3
Mac Address Table
------------------------------------------Vlan

Mac Address

Type

Ports

----

-----------

--------

-----

0200.0101.0101

DYNAMIC

Fa0/9

0200.1111.1111

DYNAMIC

Gi0/1

0200.2222.2222

DYNAMIC

Gi0/1

0200.3333.3333

DYNAMIC

Gi0/1

f47f.35cb.d79a

DYNAMIC

Gi0/1

Total Mac Addresses for this criterion: 5

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 Platzgrnden gekrzt
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 EmpfngerMAC-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
aufgefhrt, damit Sie, falls Sie das Beispiel zur bung bearbeiten, die Lsung nicht versehentlich 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 erhlt, 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 STPForwarding-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
aufgefhrt 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

----

-----------

--------

-----

0200.0101.0101

DYNAMIC

Fa0/9

0200.1111.1111

DYNAMIC

Gi0/1

0200.2222.2222

DYNAMIC

Gi0/1

0200.3333.3333

DYNAMIC

Gi0/1

f47f.35cb.d79a

DYNAMIC

Gi0/1

Total Mac Addresses for this criterion: 5

3.3 Beispiele und bungen zum Troubleshooting

125

Wenn SW3 den an die MAC-Adresse von PC1 gerichteten Frame von SW2 erhlt, berprft SW3 zunchst 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 aufgefhrt. Am Ende von Listing 3.17 befand sich Gi0/2 im STP-ForwardingStatus 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 aufgefhrt 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

----

-----------

--------

-----

0200.0101.0101

DYNAMIC

Gi0/2

0200.1111.1111

DYNAMIC

Gi0/1

0200.2222.2222

DYNAMIC

Gi0/1

0200.3333.3333

DYNAMIC

Fa0/13

Total Mac Addresses for this criterion: 4

Wenn SW1 den Frame von SW3 erhlt, 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
aufgefhrt. Am Ende von Listing 3.15 befand sich das SW1-Interface Gi0/2 im STP-ForwardingStatus 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 aufgefhrt 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

----

-----------

--------

-----

0200.2222.2222

DYNAMIC

Fa0/12

0200.3333.3333

DYNAMIC

Gi0/2

f47f.35cb.d799

DYNAMIC

Gi0/2

Total Mac Addresses for this criterion: 3

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

0200.1111.1111

STATIC

Fa0/11

0200.2222.2222

DYNAMIC

Fa0/12

0200.3333.3333

DYNAMIC

Gi0/2

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 MacAdresse 0200.1111.1111 von PC1 nicht auffhrt. Hierdurch knnte 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 einschlielich 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 Schlsselwort dynamic weglassen, fhrt der Befehl show mac address-table vlan 3 alle MAC-Adressen auf, die im VLAN
bekannt sind mithin auch 0200.1111.1111. Diese Befehlsausgabe besttigt 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).

3.3 Beispiele und bungen zum Troubleshooting

127

0200.1111.1111
PC1

PC2

Fa0/11
Fa0/12

Gi0/1

Gi0/2

SW1
Gi0/2

Fa0/9
SW2
Gi0/1

Gi0/1
R1
0200.0101.0101

0200.2222.2222
Gi0/1

Gi0/2

SW3
Fa0/13
PC3

Abbildung 3.7 Weiterleitungspfad des ARP-Broadcasts von PC1 bis R1


0200.1111.1111
PC1

PC2

Fa0/11
Fa0/12

Gi0/1

Gi0/2

SW1
Gi0/2

Fa0/9
SW2
Gi0/1

0200.2222.2222
Gi0/1

Gi0/2

SW3
Fa0/13
PC3

Abbildung 3.8 Weiterleitungspfad der ARP-Reply von R1 bis PC1

Gi0/1
R1
0200.0101.0101

128

Kapitel 3: Troubleshooting beim LAN-Switching

Aufgaben zur Prfungsvorbereitung


Alle Schlsselthemen wiederholen
Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind mit dem Symbol
Schlsselthema gekennzeichnet. Tabelle 3.8 listet diese Themen sowie die Seitennummern auf,
auf denen diese Themen zu finden sind.
Tabelle 3.8 Schlsselthemen in Kapitel 3
Schlsselthema

Element

Beschreibung

Seite

Tabelle 3.2

Listet Codekombinationen fr den Interface-Status und typische


Ursachen fr jeden Status auf.

95

Abbildung 3.4

Zeigt die typische Verwendung von Crossover- und StraightThrough-Kabeln.

96

Tabelle 3.3

Zeigt Gerte und Leitungen, ber die Daten via 10BASE-T und
100BASE-TX bertragen werden.

97

Liste

Definitionen von Geschwindigkeits- und Duplex-Mismatch

98

Liste

Vorschlge zur Ermittlung von Duplex-Mismatches

100

Liste

Optionsvorgaben fr das IEEE-Autonegotiating basierend auf


der aktuellen bertragungsrate

100

Tabelle 3.4

Violation-Modi bei der Port-Security einschlielich der


Unterschiede im Verhalten und der zugehrigen show-Befehle

102

Liste

Schritte bei der Port-Security-Konfiguration

104

Tabelle 3.5

Fhrt show-Befehle auf, die ntzlich sind, um Access-Interfaces


und die ihnen zugeordneten VLANs zu ermitteln.

106

Tabelle 3.6

Vier Grnde dafr, warum ein Switch die Daten eines VLAN
nicht ber einen bestimmten Trunk weiterleitet

108

Tabelle 3.7

Kombinationen des switchport mode-Befehls und der


zugehrigen Ergebnisse zur Frage, ob ein Trunking erfolgt

109

Tabellen und Listen aus dem Gedchtnis


vervollstndigen
Drucken Sie aus Anhang D, Tabellen zur Gedchtnisbung (auf CD), den Abschnitt zu diesem
Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls
auf CD enthaltene Anhang E, Lsungen zu Anhang D, enthlt die vollstndigen Tabellen und
Listen, mit denen Sie Ihre Lsungen berprfen knnen.

Lsungen zum Troubleshooting-Beispiel 1

129

Lsungen zum Troubleshooting-Beispiel 1


Wenn Sie das Troubleshooting-Beispiel 1 als bung bearbeitet haben, fasst die folgende Liste
die Probleme zusammen, die in dieser bung entdeckt worden sein knnten:
Q

Abbildung 3.5 zeigt die Verbindung von Port Fa0/10 von SW2 mit Router R1; CDP gibt
jedoch an, dass hierfr 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 hierfr geht aus den Listings nicht hervor. (Tatschlich war das
Kabel abgezogen; zur Vorbereitung auf das zweite Beispiel wurde dieses Kabel dann wieder
gesteckt.)

Bei Port Fa0/13 von SW3 liegt mglicherweise ein Duplex-Mismatch vor. Angegeben sind
hier a-100 fr die Geschwindigkeit sowie half fr den Duplexmodus; dies knnte passieren,
wenn das andere Gert (PC13) das Autonegotiating deaktiviert und fr 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 Konfiguration der MAC-Adresse 0200.3333.3333 Daten vom einzigen Gert, das mit ihm
verbunden ist (PC1, 0200.1111.1111). Die Port-Security-Konfiguration wurde gendert und
fhrt nun die richtige MAC-Adresse 0200.1111.1111 auf.

Port F0/9 von SW2 physisch mit R1 verbunden ist VLAN 1 zugewiesen, whrend
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.