Sie sind auf Seite 1von 816

CCNA ICND2 Prfungshandbuch

Wendell Odom, CCIE Nr. 1624


bersetzung: Christian Alkemper Deutsche Bearbeitung: Ernst Schawohl

CCNA ICND2 Prfungshandbuch

Cisco Press

Addison-Wesley Verlag

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet ber <http://dnb.ddb.de> abrufbar.

Die Informationen in diesem Produkt werden ohne Rcksicht auf einen eventuellen Patentschutz verffentlicht. Warennamen werden ohne Gewhrleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit grter Sorgfalt vorgegangen. Trotzdem knnen Fehler nicht vollstndig ausgeschlossen werden. Verlag, Herausgeber und Autoren knnen fr fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung bernehmen. Fr Verbesserungsvorschlge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar. Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulssig. Fast alle Hardware- und Softwarebezeichnungen und weitere Stichworte und sonstige Angaben, die in diesem Buch verwendet werden, sind als eingetragene Marken geschtzt. Da es nicht mglich ist, in allen Fllen zeitnah zu ermitteln, ob ein Markenschutz besteht, wird das Symbol in diesem Buch nicht verwendet. Authorized translation from the English language edition, entitled CCNA ICND 2 Official Exam Certification Guide, ISBN: 978-1-58720-181-3, by Wendell Odom, published by Pearson Education, Inc, publishing as Cisco Press, Copyright 2008 All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. GERMAN language edition published by PEARSON EDUCATION DEUTSCHLAND, Copyright 2008 Umwelthinweis: Dieses Buch wurde auf chlorfrei gebleichtem Papier gedruckt. Die Einschrumpffolie zum Schutz vor Verschmutzung ist aus umweltvertrglichem und recyclingfhigem PE-Material.

10 9 8 7 6 5 4 3 2 1 10 09 08

ISBN 978-3-8273-2635-5

2008 by Markt+Technik Verlag, ein Imprint der Pearson Education Deutschland GmbH. Martin-Kollar-Strae 1012, D-81829 Mnchen/Germany Alle Rechte vorbehalten bersetzung: Christian Alkemper, info@alkemper.com Deutsche Bearbeitung: Ernst Schawohl, ernst.schawohl@fh-duesseldorf.de Lektorat: Sylvia Hasselbach, shasselbach@pearson.de Korrektorat: Ren Wiegand, info@wiegand-dokumentation.de Herstellung: Claudia Burle, cbaeurle@pearson.de Einbandgestaltung: Thomas Arlt, tarlt@adesso21.net Satz: text&form, Frstenfeldbruck Druck und Verarbeitung: Ksel, Kempten (www.KoeselBuch.de) Printed in Germany

Inhaltsverzeichnis
1

Vorwort Einleitung

17 21 44 47 berprfen Sie Ihren Wissensstand Wissensgrundlage VLAN-Funktionen Trunking mit ISL und 802.1Q IP-Subnetze und VLANs Das VTP-Protokoll Konfiguration und Verifizierung von VLANs und VLAN-Trunking VLANs erstellen und einer Schnittstelle zuordnen VLAN-Trunking konfigurieren VLANs und Trunking absichern VTP-Konfiguration und -Verifizierung VTP-Server und -Clients konfigurieren Vorsichtsmanahmen bei einer Vernderung der VTP-Default-Konfiguration Transparenten VTP-Modus konfigurieren Behebung von VTP-Problemen Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz 47 51 52 54 58 59 68 68 75 84 85 85 90 91 92 102 102 103 103 103

Teil I: LAN-Switching
1 VLANs 1.1 1.2 1.3 1.3.1 1.3.2 1.3.3 1.4 1.4.1 1.4.2 1.4.3 1.5 1.5.1 1.5.2 1.5.3 1.5.4 1.6 1.6.1 1.6.2 1.6.3 1.6.4

6
2

CCNA ICND2-Prfungshandbuch Das Spanning-Tree-Protokoll 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 2.6 2.6.1 2.6.2 2.6.3 2.6.4 2.7 2.7.1 2.7.2 2.7.3 2.7.4 berprfen Sie Ihren Wissensstand Wissensgrundlage Das Spanning-Tree-Protokoll (IEEE 802.1d) Warum ein Spanning-Tree notwendig ist Was Spanning-Tree bewirkt Wie Spanning-Tree funktioniert Optionale STP-Eigenschaften Rapid STP (IEEE 802.1w) Konnektivittstypen bei RSTP Port-Zustnde bei RSTP Port-Funktionen bei RSTP Konvergenz bei RSTP STP-Konfiguration und -Verifizierung Mehrere STP-Instanzen Konfigurationsoptionen, die sich auf die SpanningTree-Topologie auswirken STP-Default-Funktion verifizieren STP-Port-Kosten und Switch-Prioritt konfigurieren PortFast und BPDU Guard konfigurieren EtherChannel konfigurieren RSTP konfigurieren Behebung von STP-Problemen Root-Switch bestimmen Root-Port auf Nicht-Root-Switches bestimmen Designierten Port fr LAN-Segmente bestimmen Konvergenz bei STP Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz Fragen zur Einschtzung des Wissensstandes Wissensgrundlage Allgemeine Anstze zur Problembehebung Normalbetrieb des Netzwerks analysieren und prognostizieren 107 107 111 111 111 113 115 126 129 130 132 132 134 139 139 141 143 146 148 148 151 152 153 155 157 159 160 160 161 161 161 165 166 166 166 167

Troubleshooting beim LAN-Switching 3.1 3.2 3.3 3.3.1

Inhaltsverzeichnis 3.3.2 3.3.3 3.3.4 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.5 3.5.1 3.5.2 3.6 3.6.1 3.6.2 Probleme eingrenzen Ursachenanalyse Prfungsaufgaben und die Praxis Problembehebung bei der LAN-Switching-Datenebene Der normale Weiterleitungsvorgang bei LAN-Switches Schritt 1: Netzwerkdiagramme mit CDP berprfen Schritt 2: Schnittstellenprobleme eingrenzen Schritt 3: Probleme in Zusammenhang mit Filterung und Port-Security beheben Schritt 4: VLAN- und Trunking-Probleme beheben Problembehebung auf der Datenebene (Beispiel) Prognose des Normalbetriebs der LAN-SwitchingDatenebene Broadcast von PC1 in VLAN 1 Weiterleitungspfad eines Unicasts von R1 zu PC1 Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen

172 173 174 175 175 178 180 187 192 197 209 209 213 217 217 217 218 221 221 224 225 225 229 235 238 240 240 243 244 247 249 250 253 257 258

Teil II: IP-Routing


4 IP-Routing: Statische und direkt verbundene Routen 4.1 4.2 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.4 4.4.1 4.4.2 4.4.3 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 Fragen zur Einschtzung des Wissensstandes Wissensgrundlage IP-Routing und Adressierung IP-Routing IP-Adressierung und Subnetzbildung DNS, DHCP, ARP und ICMP Fragmentierung und MTU Routen zu direkt verbundenen Subnetzen Sekundre IP-Adressierung Direkt verbundene Routen in das Subnetz Null ISL- und 802.1Q-Konfiguration auf Routern Statische Routen Statische Routen konfigurieren Der erweiterte ping-Befehl Statische Default-Routen Zusammenfassung zu den Default-Routen Klassenbezogenes und klassenloses Routing

CCNA ICND2-Prfungshandbuch 4.6 4.6.1 4.6.2 4.6.3 4.6.4 Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz berprfen Sie Ihren Wissensstand Wissensgrundlage VLSM Klassenbezogene und klassenlose Routing-Protokolle berlappende VLSM-Subnetze Mit VLSM ein Subnetzschema bilden Neues Subnetz zu vorhandenem Design hinzufgen VLSM konfigurieren Manuelle Zusammenfassung von Routen Prinzip der Routenzusammenfassung Strategien der Routenzusammenfassung Autosummierung und nicht zusammenhngende klassenbezogene Netzwerke Autosummierung: Ein Beispiel Nicht zusammenhngende klassenbezogene Netzwerke Untersttzung und Konfiguration der Autosummierung Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Szenarien in Anhang F lesen Befehlsreferenz berprfen Sie Ihren Wissensstand Wissensgrundlage Standard-ACLs Konzepte von Standard-ACLs Standard-ACLs konfigurieren Erweiterte ACLs Funktion erweiterter ACLs Vergleich von TCP- und UDP-Port-Nummern Erweiterte ACLs konfigurieren 262 262 263 263 263 267 267 270 270 272 272 274 277 280 280 281 285 288 289 291 293 294 294 295 295 295 295 297 298 301 301 302 309 315 315 317 320

VLSM und Routenzusammenfassung 5.1 5.2 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5 5.4 5.4.1 5.4.2 5.5 5.5.1 5.5.2 5.5.3 5.6 5.6.1 5.6.2 5.6.3 5.6.4 5.6.5

IP-ACLs 6.1 6.2 6.3 6.3.1 6.3.2 6.4 6.4.1 6.4.2 6.4.3

Inhaltsverzeichnis 6.5 6.5.1 6.5.2 6.6 6.6.1 6.6.2 6.6.3 6.6.4 6.6.5 6.7 6.7.1 6.7.2 6.7.3 6.7.4 6.7.5 7 7.1 7.2 7.3 7.3.1 7.3.2 7.4 7.4.1 7.4.2 7.5 7.5.1 7.5.2 7.5.3 7.5.4 7.5.5 7.5.6 7.6 7.6.1 7.6.2 7.6.3 Fortschritte bei der ACL-Konfiguration ACLs mit Namen ACLs mit Sequenznummern editieren Weitere ACL-Themen Telnet- und SSH-Zugriff mit ACLs steuern Einsatz von ACLs Reflexive ACLs Dynamische ACLs Zeitbasierte ACLs Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Szenarien in Anhang F lesen Wichtige Definitionen Befehlsreferenz berprfen Sie Ihren Wissensstand Wissensgrundlage Die Befehle ping und traceroute ICMP Der Befehl traceroute Probleme bei der Paketweiterleitung beheben Hostbezogene Routing-Probleme eingrenzen Router-bezogene Routing-Probleme eingrenzen Tools und Tipps zur Problembehebung Host-bezogene Routing-Tools und Aspekte Referenz zum Befehl show ip route Schnittstellenzustand VLSM-Probleme Nicht zusammenhngende Netzwerke und Autosummierung Hinweise zum Troubleshooting bei ACLs Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen

325 325 328 331 331 333 335 336 338 338 338 339 339 339 340 343 343 343 344 344 351 354 354 356 365 366 368 370 370 376 377 380 380 381 381

Troubleshooting beim IP-Routing

10

CCNA ICND2-Prfungshandbuch

Teil III: Konfiguration und Problembehebung bei Routing-Protokollen


8 Theorie zu Routing-Protokollen 8.1 8.2 8.3 8.3.1 8.3.2 8.3.3 8.3.4 8.4 8.4.1 8.4.2 8.4.3 8.4.4 8.5 8.5.1 8.5.2 8.5.3 8.5.4 8.6 8.6.1 8.6.2 8.6.3 8.6.4 9 OSPF 9.1 9.2 9.3 9.3.1 9.3.2 9.3.3 9.3.4 9.4 9.4.1 9.4.2 Fragen zur Einschtzung des Wissensstandes Wissensgrundlage OSPF: Protokolle und Betrieb OSPF-Nachbarn Austausch der Topologiedatenbanken Die Routing-Tabelle erstellen OSPF ber ein hierarchisches Design skalieren OSPF-Konfiguration OSPF fr eine Area konfigurieren OSPF fr mehrere Areas konfigurieren Fragen zur Einschtzung des Wissensstandes Wissensgrundlage bersicht zu den dynamischen Routing-Protokollen Funktionen von Routing-Protokollen Interne und externe Routing-Protokolle IGPs vergleichen Administrative Distanz Merkmale von Distanzvektor-Protokollen Das Prinzip von Distanz und Vektor Betrieb von Distanzvektor-Protokollen in einem stabilen Netzwerk Routing-Schleifen verhindern Zusammenfassung zum Distanzvektor-Routing Eigenschaften von Link-State-Protokollen Identische Link-State-Datenbanken auf allen Routern erstellen Mit Dijkstras SPF-Algorithmus die beste Route finden Konvergenz mit Link-State-Protokollen Zusammenfassung und Vergleich mit den Distanzvektor-Protokollen Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz

382 385 385 389 389 390 392 393 397 399 399 401 403 416 416 417 419 422 422 424 424 425 425 425 427 427 431 431 431 437 442 443 448 449 451

Inhaltsverzeichnis 9.4.3 9.4.4 9.4.5 9.4.6 9.4.7 9.5 9.5.1 9.5.2 9.5.3 9.5.4 10 EIGRP 10.1 10.2 10.2.1 10.2.2 10.2.3 10.2.4 10.2.5 10.3 10.3.1 10.3.2 10.3.3 10.3.4 10.3.5 10.4 10.4.1 10.4.2 10.4.3 10.4.4 11.1 11.2 11.3 11.4 11.4.1 11.4.2 Fragen zur Einschtzung des Wissensstandes EIGRP: Konzepte und Betrieb EIGRP-Nachbarn EIGRP-Topologiedaten austauschen Die besten Routen fr die Routing-Tabelle berechnen EIGRP-Konvergenz Zusammenfassung zu EIGRP und Vergleich mit OSPF EIGRP-Konfiguration und -Verifizierung Grundlegende EIGRP-Konfiguration Metrik, Successor-Route und FS-Route bei EIGRP EIGRP-Authentifizierung Hchstanzahl der EIGRP-Pfade und EIGRP-Varianz EIGRP-Metrikberechnungen optimieren Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz Fragen zur Einschtzung des Wissensstandes Wissensgrundlage Perspektiven der Problembehebung bei RoutingProtokollen Schnittstellen mit aktiviertem Routing-Protokoll Beispiel fr die Problembehebung bei EIGRPSchnittstellen Beispiel fr das Troubleshooting bei OSPFSchnittstellen OSPF-Router-ID konfigurieren Die Hello- und Dead-Timer OSPF-Kostenmetriken OSPF-Authentifizierung OSPF-Lastausgleich Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz

11
454 455 457 458 461 462 462 463 463 463 467 467 470 471 472 473 477 480 481 482 485 490 493 495 496 496 497 497 497 501 502 502 503 505 506 511

11 Troubleshooting bei Routing-Protokollen

12

CCNA ICND2-Prfungshandbuch 11.5 11.5.1 11.5.2 11.6 11.6.1 11.6.2 11.6.3 Nachbarschaftsbeziehungen Nachbarschaftsanforderungen bei EIGRP Nachbarschaftsanforderungen bei OSPF Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Befehlsreferenz 513 515 518 525 525 526 526 528 531 531 534 535 535 536 541 541 543 544 544 546 547 551 554 554 554 555 555 557 557 561 562 564 565 568 570 571 572 575

Teil IV: WANs


12 Point-to-Point-WANs 12.1 12.2 12.3 12.3.1 12.3.2 12.4 12.4.1 12.4.2 12.4.3 12.5 12.5.1 12.5.2 12.5.3 12.6 12.6.1 12.6.2 12.6.3 12.6.4 13.1 13.2 13.3 13.3.1 13.3.2 13.3.3 13.4 13.4.1 13.4.2 13.5 Fragen zur Einschtzung des Wissensstandes Wissensgrundlage PPP-Funktionen Das PPP-Protokollfeld LCP PPP-Konfiguration PPP-Basiskonfiguration CHAP-Konfiguration und -Verifizierung PAP-Konfiguration Troubleshooting bei seriellen Verbindungen Schicht-1-Probleme beheben Schicht-2-Probleme beheben Schicht-3-Probleme beheben Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz Fragen zur Einschtzung des Wissensstandes Wissensgrundlage Frame Relay im berblick Frame Relay-Standards Virtuelle Leitungen LMI und Kapselungstypen Frame Relay-Adressierung Lokale Frame Relay-Adressierung Globale Frame Relay-Adressierung Frame Relay-Aspekte der Vermittlungsschicht

13 Frame Relay

Inhaltsverzeichnis 13.5.1 13.5.2 13.5.3 13.5.4 13.6 13.6.1 13.6.2 13.7 13.7.1 13.7.2 13.7.3 14.1 14.2 14.3 14.3.1 14.3.2 14.3.3 14.3.4 14.3.5 14.3.6 14.4 14.4.1 14.4.2 14.4.3 14.4.4 14.4.5 14.4.6 14.4.7 14.5 14.5.1 14.5.2 14.5.3 14.5.4 Schicht-3-Adressierung bei Frame Relay: Ein Subnetz fr alle Frame Relay-DTEs Schicht-3-Adressierung bei Frame Relay: Ein Subnetz je VC Schicht-3-Adressierung bei Frame Relay: Der Hybridansatz Umgang mit Schicht-3-Broadcasts Datenrate und Verwerfen von Daten in der Frame Relay-Wolke FECN und BECN Das DE-Bit Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Definitionen von Schlsselbegriffen Fragen zur Einschtzung des Wissensstandes Wissensgrundlage Frame Relay-Konfiguration und -Verifizierung Eine Frame Relay-Konfiguration planen Vollstndig vermaschtes Netzwerk mit einem IP-Subnetz Kapselung und LMI konfigurieren Frame Relay-Mapping Teilvermaschtes Netzwerk mit einem IP-Subnetz pro VC Teilvermaschtes Netzwerk mit vollstndig vermaschten Teilen Troubleshooting bei Frame Relay Empfehlung zur Problembehebung unter Frame Relay Schicht-1-Probleme auf der Zugangsleitung (Schritt 1) Schicht-2-Probleme auf der Zugangsleitung (Schritt 2) PVC-Status und PVC-Probleme (Schritt 3) Probleme mit dem Frame Relay-Mapping (Schritt 4) Ende-zu-Ende-Kapselung (Schritt 5) Fehlangepasste Subnetzadressen (Schritt 6) Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Szenarien in Anhang F lesen Befehlsreferenz

13

576 577 579 580 581 582 583 584 584 585 585 587 587 591 591 591 593 595 597 602 609 612 613 615 615 618 625 627 627 628 628 628 628 629

14 Konfiguration und Problembehebung bei Frame Relay

14

CCNA ICND2-Prfungshandbuch 631 Fragen zur Einschtzung des Wissensstandes Wissensgrundlage VPN-Grundlagen IPSec-VPNs IPSec-Verschlsselung IPSec-Schlsselaustausch IPSec-Authentifizierung und Nachrichtenintegritt Die Sicherheitsprotokolle ESP und AH Aspekte der IPSec-Implementierung SSL-VPNs Aufgaben zur Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Definitionen von Schlsselbegriffen 631 634 634 638 638 640 641 643 644 645 648 648 649 649 650 653 Fragen zur Einschtzung des Wissensstandes Wissensgrundlage Perspektiven der IPv4-Adressskalierbarkeit CIDR Private Adressierung NAT-Funktionen Statisches NAT Dynamische NAT-Funktion Konfiguration und Problembehebung bei NAT Statische NAT-Funktion konfigurieren Dynamische NAT-Funktion konfigurieren NAT-Overloading (PAT) konfigurieren Troubleshooting bei NAT Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz 653 657 657 658 661 662 663 666 672 672 675 680 683 685 685 686 686 686

15 VPNs 15.1 15.2 15.3 15.4 15.4.1 15.4.2 15.4.3 15.4.4 15.4.5 15.5 15.6 15.6.1 15.6.2 15.6.3

Teil V: IP-Adressraum skalieren


16 NAT 16.1 16.2 16.3 16.3.1 16.3.2 16.4 16.4.1 16.4.2 16.5 16.5.1 16.5.2 16.5.3 16.5.4 16.6 16.6.1 16.6.2 16.6.3 16.6.4

Inhaltsverzeichnis 17 IPv6 17.1 17.2 17.3 17.3.1 17.3.2 17.3.3 17.3.4 17.3.5 17.3.6 17.4 17.4.1 17.4.2 17.4.3 17.4.4 17.4.5 17.4.6 17.5 17.5.1 17.5.2 17.6 17.6.1 17.6.2 17.6.3 17.6.4 17.7 17.7.1 17.7.2 17.7.3 17.7.4 Fragen zur Einschtzung des Wissensstandes Wissensgrundlage Globale Unicast-Adressierung, Routing und Subnetzbildung Globale Routensummierung fr effizientes Routing Darstellung von IPv6-Adressen Darstellung von IPv6-Prfixen Beispiel fr die Zuweisung globaler Unicast-Prfixe Subnetzbildung bei globalen IPv6-Unicast-Adressen in einem Unternehmen Terminologie bei Prfixen IPv6-Protokolle und Adressierung DHCP fr IPv6 Host-Adresszuordnung bei IPv6 Default-Gateway mit NDP entdecken IP-Adressen von DNS-Servern erlernen IPv6-Adressen Zusammenfassung zu IP-Protokollen und -Adressierung Konfiguration von IPv6-Routing und RoutingProtokollen IPv6-Routing-Protokolle IPv6-Konfiguration IPv6-Migrationsoptionen Dual-Stacks bei IPv4 und IPv6 Tunneling Zwischen IPv4 und IPv6 mit NAT-PT bersetzen Zusammenfassung zur Migration Prfungsvorbereitung Wiederholung Vervollstndigen Sie die Listen und Tabellen Wichtige Definitionen Befehlsreferenz

15
689 689 692 694 695 697 699 702 704 707 707 708 709 715 715 716 720 721 722 722 726 727 727 729 730 731 731 732 732 732

16

CCNA ICND2-Prfungshandbuch 734 737 738 738 740 741 742 742 743 743 746 746 749 750 753 769 773 777 795

Teil VI: Abschlieende Vorbereitung


18 Abschlieende Vorbereitung 18.1 18.1.1 18.1.2 18.1.3 18.1.4 18.2 18.2.1 18.2.2 18.2.3 18.2.4 18.3 Lernhilfen zur Vorbereitung Prfungsmodul und Fragen auf der CD Das Cisco CCNA Prep Center Videos zu Subnetzen, Referenzseiten und bungsaufgaben Szenarien Lernplan Fakten wiederholen Subnetzbildung ben Problembehebung mit verschiedenen Szenarien trainieren Das Prfungsmodul verwenden Zusammenfassung

Teil VII: Anhnge


Anhang A: Antworten zu berprfen Sie Ihren Wissensstand Anhang B: Konvertierungstabelle fr Dezimal- und Binrzahlen Anhang C: Aktualisierungen der ICND2-Prfung, Version 1.0 Glossar Stichwortverzeichnis

Vorwort
Vorwort
Das CCNA/ICND2 Prfungshandbuch bietet hervorragendes Material fr das Selbststudium zur Vorbereitung auf die Prfung CCNA ICND2. Durch Bestehen der ICND2-Prfung weisen Sie die Kenntnisse und Fertigkeiten nach, die fr eine erfolgreiche Installation und den Betrieb eines kleinen bis mittelgroen Netzwerks und fr die Fehlersuche in diesem Netzwerk erforderlich sind. Es handelt sich um eine von zwei Prfungen, die fr die CCNA-Zertifizierung verlangt werden. Der Erwerb von Zertifizierungen in der Cisco-Technologie stellt den Schlssel fr die lebenslange Weiterbildung heutiger Netzwerktechniker dar. ber Zertifizierungsprogramme bewertet Cisco die Kenntnisse und das Fachwissen, welche zur qualifizierten Verwaltung eines modernen Unternehmensnetzwerks erforderlich sind. Die von Cisco Press publizierten Leitfden zur Zertifizierung und das Vorbereitungsmaterial bieten herausragenden und flexiblen Zugriff auf die Kenntnisse und Informationen, die Sie bentigen, um in Ihrem Fachgebiet auf dem aktuellen Stand zu bleiben oder neue Techniken zu erlernen. Ob als Ergnzung zur traditionellen Schulung oder als primre Quelle verwendet, bietet das hier vorgestellte Material dem Benutzer alle Grundlagen und Details, um neues Wissen und neue Kompetenzen zu erwerben. Entwickelt in Zusammenarbeit mit dem Cisco-Zertifizierungs- und -Schulungsteam, stellen Bcher von Cisco Press die einzigen von Cisco autorisierten Werke zum Selbststudium dar und bieten dem Lernenden eine Serie von prfungsspezifischen bungen und Ressourcen, die gewhrleisten, dass er die prsentierten Themen und Informationen vollstndig erfasst. Weitere von Cisco autorisierte Prsenzschulungen, E-Learnings, bungen und Simulationen werden von den Cisco Learning Solutions Partners in aller Welt exklusiv zur Verfgung gestellt. Informationen finden Sie unter http:// www.cisco.com/go/training.

18

CCNA ICND2-Prfungshandbuch

Ich hoffe, dass das vorliegende Material auch fr Sie ein wertvoller und ntzlicher Bestandteil Ihrer Prfungsvorbereitung sein wird. Erik Ullanderson Manager, Global Certifications Learning@Cisco

ber den Autor


Wendell Odom (CCIE Nr. 1624) ist seit 1981 im Bereich der Netzwerktechnik ttig. Gegenwrtig fhrt er QoS-, MPLS- und CCNA-Kurse fr die Firma Skyline Advanced Technology Services (http://www.skyline-ats.com) durch. Auerdem hat er bereits als Netzwerktechniker, Consultant und Systemtechniker sowie als Schulungsleiter und Kursentwickler gearbeitet. Er ist Autor aller vorangegangenen Auflagen von CCNA Exam Certification Guide sowie der Titel Cisco QoS Exam Certification Guide, Second Edition, Computer Networking First-Step, CCIE Routing and Switching Official Exam Certification Guide, Second Edition sowie CCNA Video Mentor (alle zu beziehen ber Cisco Press).

Typografische Konventionen
Die in den Listings in diesem Buch verwendeten typografischen Konventionen entsprechen denen anderer Cisco-Publikationen. Die folgenden Konventionen finden Anwendung:
Fettdruck bezeichnet Befehle und Schlsselwrter in der Form, wie sie eingegeben werden mssen. In den Konfigurationsbeispielen und AusgabeListings sind fett gedruckte Befehle (wie beispielsweise show) durch den Benutzer einzugeben. Dies gilt jedoch nicht fr die einfache Erwhnung von Befehlen im Flietext. Kursiv gesetzt sind Argumente, die Sie durch die erforderlichen Werte

ersetzen mssen. Vertikale Balken (|) trennen alternative, einander ausschlieende Elemente voneinander. Optionale Elemente werden durch eckige Klammen ([]) angezeigt. Geschweifte Klammern ({}) signalisieren eine obligatorische Auswahl. Geschweifte Klammern in eckigen Klammern ([{}]) bezeichnen eine obligatorische Auswahl innerhalb eines optionalen Elements.

Vorwort

19

In diesem Buch verwendete Symbole

Webserver

WebBrowser

PC

Laptop

Server

Drucker

Telefon

IP-Telefon

Kabelmodem

CSU/DSU

Router

Multiservice Switch

Switch

ATM Switch

Frame Relay Switch

PBX

Access Point

ASA

DSLAM

WAN Switch

Hub

PIX Firewall

Bridge

Drahtlose Verbindung

Netzwerkwolke

Ethernet-Verbindung

Serielle Verbindung

Virtuelle Verbindung

Einleitung
Einleitung
Herzlichen Glckwunsch: Wenn Sie es bis zur Einleitung dieses Buches geschafft haben, sind Sie wahrscheinlich fest entschlossen, Ihre CiscoPrfung in Angriff zu nehmen. Um als Techniker im Bereich der Netzwerktechnik erfolgreich zu sein, mssen Sie Cisco kennen. Ciscos Marktanteil bei den Routern und Switches ist unglaublich hoch und liegt in einigen Marktsegmenten bei mehr als 80 Prozent. In vielen Regionen und Mrkten der Welt ist Cisco quasi das Synonym zu Netzwerktechnik. Wollen Sie als Netzwerktechniker ernst genommen werden, dann ist die Cisco-Zertifizierung beinahe ein Muss. Historisch gesehen war die erste Cisco-Zertifizierung auf Einstiegsniveau das 1998 eingefhrte CCNA-Zertifikat (Cisco Certified Network Associate). Die ersten drei Versionen der CCNA-Zertifizierung (1998, 2000 und 2002) verlangten das Bestehen einer einzelnen Prfung zur erfolgreichen Zertifizierung. Allerdings nahm die Prfung im Laufe der Jahre sowohl hinsichtlich des Materialumfangs als auch des Schwierigkeitsgrades der Fragen an Gewicht zu. Aus diesem Grund bot Cisco bei der vierten groen berarbeitung, die im Jahr 2003 angekndigt wurde, mit CCNA weiterhin eine einheitliche Zertifizierung an. Offeriert werden zwei Mglichkeiten, diese Zertifizierung zu erwerben: entweder mit einer einzigen oder aber mit zwei Prfungen. Bei zwei Prfungen ist es dem Studierenden mglich, etwa die Hlfte des Materials zu lernen, dann die erste Prfung zu bestehen und nachfolgend mit dem Stoff fr die zweite Prfung fortzufahren. Im Juni 2007 kndigte Cisco nderungen an der CCNA-Zertifizierung und den Prfungen an. Diese Ankndigung benannte eine Reihe von nderungen, deren wichtigste die folgenden waren: Alle Prfungen erstrecken sich nun ber einen umfangreicheren Themenbereich. Die Prfungen legen nun mehr Gewicht darauf, die praktischen Fertigkeiten des Prflings zu verifizieren (statt nur Wissen abzufragen).

22

CCNA ICND2-Prfungshandbuch Mit CCENT (Cisco Certified Entry Network Technician) wurde eine neue Zertifizierung fr die Einstiegsstufe verfasst.

Fr die aktuellen Zertifizierungen, die im Juni 2007 angekndigt worden waren, erstellte Cisco die Prfungen ICND1 (640-822) und ICND2 (640816) zustzlich zur CCNA-Prfung (640-802). Um die CCNA-Zertifizierung zu erhalten, muss man entweder die ICND1- und die ICND2-Prfung oder aber die CCNA-Prfung bestehen. Die CCNA-Prfung behandelt schlicht gesagt alle Themen der Prfungen ICND1 und ICND2 und bietet Ihnen so zwei Mglichkeiten, Ihre CCNA-Zertifizierung zu erwerben. Der Ansatz der zweifachen Prfung bietet weniger erfahrenen Personen die Mglichkeit, zunchst einen weniger umfangreichen Stoff zu studieren, whrend mit der einmaligen Prfung jenen, die sich fr alle Themen gleichzeitig vorbereiten wollen, ein kostengnstigerer Zertifizierungspfad angetragen wird. Zwar ist die zweifache Prfung fr manche Zertifizierungskandidaten durchaus von Nutzen, doch entwickelte Cisco die ICND1-Prfung mit einem wesentlich wichtigeren Hintergedanken. Die CCNA-Zertifizierung ist in ihrer gegenwrtigen Form dafr geeignet, die Kenntnisse und Fertigkeiten abzufragen, die ber das Wissen eines Netzwerkeinsteigers hinausgehen. Allerdings bentigte Cisco auch eine Zertifizierung, welche die Kenntnisse reflektiert, die zur Bewltigung von Netzwerkaufgaben auf Einstiegsniveau bentigt werden. Aus diesem Grund entwickelte Cisco den ICND1-Kurs (Interconnecting Cisco Networking Devices 1) und die zugehrige Prfung (640-822), die Stoff beinhalteten, der von einem Techniker mit Einstiegsniveau in einem kleinen Unternehmensnetzwerk bentigt wird. Um Lernenden den Nachweis zu ermglichen, dass Kenntnisse fr derartige Aufgaben vorhanden sind, hat Cisco die neue CCENT-Zertifizierung entwickelt, die durch Bestehen der ICND1-Prfung erworben wird. Die folgende Abbildung zeigt die wesentliche Anordnung der Zertifizierungen und Prfungen zur Erringung der CCENT- und CCNA-Zertifizierungen. (Beachten Sie bitte, dass fr das Bestehen der ICND2-Prfung keine separate Zertifizierung vorhanden ist.)
ICND1-Prfung (640-822) Bestanden CCENTZertifizierung ICND2-Prfung (640-816)

Bestanden

CCNA-Prfung (640-802)

Bestanden

CCNAZertifizierung

Abbildung 1: Cisco-Zertifizierungen und -Prfungen auf Einsteigerniveau

Einleitung

23

Wie Sie der Abbildung entnehmen knnen, knnen Sie zwar durch Bestehen der ICND1-Prfung die CCENT-Zertifizierung erwerben, aber dies ist keine Voraussetzung, um die CCNA-Zertifizierung zu erhalten: Sie knnen die CCNA-Prfung auch einfach machen, ohne CCENT-zertifiziert zu sein. Die ICND1- und ICND2-Prfungen erstrecken sich ber verschiedene Themengebiete, wobei es zu geringfgigen berschneidungen kommt. So behandelt ICND1 die IP-Adressierung und Subnetzbildung, whrend ICND2 eine komplexere Variante der Subnetzbildung namens VLSM (Variable Length Subnet Masking) beschreibt; aus diesem Grund muss auch ICND2 die Subnetzbildung anreien. Die CCNA-Prfung behandelt alle Themen, die von den ICND1- und ICND2-Prfungen abgedeckt werden. Whrend sich der Beliebtheitsgrad der CCENT-Zertifizierung erst in ein paar Jahren herauskristallisieren wird, hat die CCNA-Zertifizierung gegenwrtig gewiss die Position des populrsten Zertifizierungsprogramms fr Netzwerkeinsteiger inne. Eine CCNA-Zertifizierung weist nach, dass Ihnen die Grundlagen zu den wichtigsten Komponenten der Cisco-Produktpalette in erster Linie Routern und Switches gelufig sind. Auerdem besttigt die Zertifizierung Ihr umfangreiches Wissen zu Protokollen und Netzwerktechnologien.

Format der CCNA-Prfungen


Die ICND1-, ICND2- und CCNA-Prfungen folgen alle demselben Schema. Wenn Sie beim Prfzentrum eintreffen und sich anmelden, erhalten Sie von der Aufsicht einige allgemeine Anweisungen und werden dann in einen stillen Raum geleitet, in dem sich ein PC befindet. Wenn Sie vor diesem PC sitzen, mssen Sie einige Schritte durchfhren, bevor die Uhr fr Ihre Prfung zu laufen beginnt. Sie knnen beispielsweise ein Musterquiz durchfhren, um sich mit dem PC und den Prfungsmethoden vertraut zu machen. Sofern Sie sich mit einem PC halbwegs gut auskennen, sollte die Prfungsumgebung Ihnen keine Probleme bereiten. In Kapitel 18, Abschlieende Vorbereitung, wird auf eine Cisco-Website verwiesen, auf der Sie ein Demo der Prfungs-Engine anzeigen knnen. Sobald Sie mit der Prfung beginnen, wird Ihnen eine Reihe von Fragen gestellt. Sie beantworten jeweils eine Frage und fahren dann mit der nchsten fort. Beachten Sie, dass die Prfungs-Engine es Ihnen nicht gestattet, zur vorherigen Frage zurckzukehren und die Antwort zu ndern. Es ist einfach so: Wenn Sie mit der nchsten Frage fortfahren, hat sich die vorherige Frage ob richtig oder falsch beantwortet fr Sie erledigt.

24

CCNA ICND2-Prfungshandbuch

Die Prfungsfragen knnen in den folgenden Formaten auftreten: Multiple-Choice-Fragen (MC) Minitest (Testlet) Drag&Drop-Frage (DND) Laborsimulation (Sim) Minisimulation (Simlet) Die ersten drei Fragetypen sind Bestandteil vieler Testumgebungen. Das Multiple-Choice-Format erfordert lediglich das Anklicken eines Optionsfeldes neben der oder den korrekten Antworten. Traditionell nennt Cisco Ihnen die Anzahl der auszuwhlenden Antworten, und die Prfsoftware stellt sicher, dass Sie nicht zu viele Antworten auswhlen. Testlets sind Fragen bezogen auf ein allgemeines Szenario, bei denen mehrere MC-Frage zum Gesamtszenario gestellt werden. Zur Beantwortung von Drag&Drop-Fragen klicken und ziehen Sie mit der Maus eine Schaltflche oder ein Symbol an einen anderen Ort und lassen die Maustaste dann los, um das Objekt am Zielort meist in einer Liste abzulegen. So mssen Sie etwa, um bestimmte Fragen korrekt zu beantworten, fnf Elemente einer Liste in der korrekten Reihenfolge anordnen. Die letzten beiden Typen verwenden fr die Frage jeweils einen Netzwerksimulator. Interessanterweise gestatten die beiden Typen Cisco die Bewertung von zwei sehr unterschiedlichen Fertigkeiten. Sim-Fragen beschreiben ein Problem allgemein. Ihre Aufgabe besteht darin, einen oder mehrere Router oder Switches so zu konfigurieren, dass das Problem behoben wird. Die Prfung bewertet die Frage dann basierend auf der von Ihnen genderten oder ergnzten Konfiguration. Aufflligerweise sind Sim-Fragen die bislang einzigen Fragen, bei denen Cisco offiziell besttigt hat, dass hierfr auch Teilwertungen vergeben werden. Simlet-Fragen stellen den wahrscheinlich schwierigsten Fragetyp der Prfungen dar. Sie verwenden auch einen Netzwerksimulator, aber statt die Antwort durch nderung der Konfiguration zu geben, enthalten solche Fragen ihrerseits eine oder mehrere MC-Fragen. Die Fragen erfordern, dass Sie mithilfe des Simulators das gegenwrtige Verhalten eines Netzwerks untersuchen und dabei zur Beantwortung der Frage die Ausgabe von show-Befehlen interpretieren mssen, an die Sie sich erinnern knnen. Whrend Sim-Fragen die Behandlung von Problemen erfordern, die im Zusammenhang mit einer Konfiguration auftreten, mssen Sie bei Simlets sowohl funktionierende als auch fehlerhafte Netzwerke analysieren und dabei Ausgaben von showBefehlen zu Ihrem Wissen ber Netzwerktheorie und Konfigurationsbefehle in Beziehung setzen.

Einleitung

25

Was wird bei den CCNA-Prfungen abgefragt?


Seit meiner Grundschulzeit fragte immer irgendjemand, sobald ein Lehrer eine Prfung ankndigte: Was kommt im Test vor?. Auch auf dem College versuchten viele Kommilitonen, mehr ber den Prfungsstoff zu erfahren. Im Kern geht es bei solchen Frage darum, zu erfahren, was intensiv, weniger intensiv oder gar nicht gelernt werden muss. Bei Cisco ist man bestrebt, die Themenauswahl fr jede Zertifizierungsprfung ffentlich bekannt zu geben wie auch eine Vorstellung davon zu vermitteln, welche Wissensgebiete und Fertigkeiten zu den einzelnen Themen vorhanden sein mssen. Aus diesem Grund verffentlicht Cisco fr jede Prfung eine Liste mit Prfungszielen. Die Prfungsziele geben bestimmte Themen wie IP-Adressierung, RIP oder VLANs vor und enthalten auch Angaben zu den fr das jeweilige Thema erforderlichen Kenntnissen. Ein Ziel kann zum Beispiel Beschreiben Sie , ein anderes Beschreiben, konfigurieren und korrigieren Sie lauten. Es ist wohl eindeutig, dass Sie beim zweiten Prfungsziel ein grndliches und umfassendes Verstndnis des Themas aufbringen mssen. Durch Angaben zu Themen und Kenntnisstand untersttzt Cisco uns alle bei der Prfungsvorbereitung. Zwar sind die Prfungsziele hilfreich, aber Sie sollten stets bedenken, dass die angegebenen Prfungsthemen nach Angaben von Cisco bei allen Zertifizierungsprfungen lediglich unverbindlichen Richtliniencharakter haben. Cisco ist bestrebt, die Prfungsfragen so weit wie mglich auf die jeweils angegebenen Prfungsziele zu beschrnken, und ich wei von Beteiligten, dass alle Fragen daraufhin abgeklopft werden.

Prfungsthemen fr ICND1
Tabelle 1 listet die Prfungsthemen fr ICND1 auf, Tabelle 2 die entsprechenden Themen fr die ICND2-Prfung. Whrend die auf Cisco.com verffentlichten Prfungsthemen nicht nummeriert sind, erhalten die Themen bei Cisco Press zur besseren Orientierung eine Nummer. Die Tabelle gibt auch an, in welchen Teilen des Buches welches Thema behandelt wird. Da sich die Prfungsthemen im Laufe der Zeit ndern knnen, sollten Sie die hier angegebenen Themen mit den auf Cisco.com (und dort insbesondere auf http://www.cisco.com/go/ccna) aufgefhrten abgleichen. Sollte Cisco in der Zukunft weitere Prfungsthemen hinzufgen, so knnen Sie Anhang C dieses Buches entnehmen, wie Sie auf http://www.ciscopress.com weitere Informationen zu diesen ergnzenden Themen herunterladen.

ANMERKUNG
Die grauen Hervorhebungen in der Tabelle werden weiter unten im Abschnitt CCNA-Prfungsthemen erlutert.

26

CCNA ICND2-Prfungshandbuch

Tabelle 1: Prfungsthemen fr ICND1


Nummer Teil des ICND1Buches, in dem das Thema behandelt wird I I I, II, III Prfungsthema

Den Betrieb von Datennetzwerken beschreiben 1 2 3 Zweck und Funktionen verschiedener Netzwerkgerte beschreiben Die fr eine bestimmte Netzwerkspezifikation erforderlichen Komponenten auswhlen Anhand des OSI- und des TCP/IP-Modells und der dazugehrigen Protokolle erlutern, wie Daten in einem Netzwerk flieen Verbreitete Netzwerk- und Webanwendungen beschreiben Zweck und grundlegende Funktionsweise der Protokolle im OSI- und im TCP/IP-Modell beschreiben Auswirkung von Anwendungen (Voice over IP und Video over IP) auf ein Netzwerk beschreiben Netzwerkdiagramme interpretieren Den Pfad zwischen zwei Hosts in einem Netzwerk ermitteln Die fr Netzwerk- und Internetkommunikation erforderlichen Komponenten beschreiben Anhand eines Schichtenmodells hufige Netzwerkprobleme in den Schichten 1, 2, 3 und 7 erkennen und korrigieren Unterschiede von LANs und WANs in Funktionsweise und Merkmalen erlutern Ein kleines geswitchtes Netzwerk aufbauen 12 II Die richtigen Medien, Kabel, Ports und Stecker zur Verbindung von Switches mit anderen Netzwerkgerten und Hosts auswhlen Technologie und Steuerungsmethode fr den Medienzugriff bei Ethernet-Technologien erlutern Netzwerksegmentierung und einfache Konzepte fr die Handhabung des Datenverkehrs erlutern Die Funktionsweise von Cisco-Switches und einfache Switching-Konzepte erlutern

4 5

I I

6 7 8 9 10

I IIV IIV I, III, IV IIV

11

II, III

13 14 15

II II II

Einleitung
Tabelle 1: Prfungsthemen fr ICND1 (Forts.)
Nummer Teil des ICND1Buches, in dem das Thema behandelt wird II Prfungsthema

27

16

Aufgaben zur Erstkonfiguration von Switches einschlielich Remote-Zugang durchfhren, Konfiguration speichern und berprfen Netzwerkstatus und Switch-Betrieb mit einfachen Dienstprogrammen (zum Beispiel ping, traceroute, Telnet, SSH, ARP, ipconfig), show- und debugBefehlen berprfen Einfache Sicherheitsmanahmen fr einen Switch konfigurieren und berprfen (Portsicherheit, Deaktivierung von Ports) Hufig vorkommende Probleme in geswitchten Netzwerken, bei der Konfiguration und Autonegotiation sowie Fehler der Switch-Hardware ermitteln und beheben Ein IP-Adressierungssystem und IP-Dienste anwenden, um die Netzwerkanforderungen eines kleinen Zweigbros zu erfllen

17

II

18

II

19

II

20 21 22

I, III I, III III

Notwendigkeit und Funktion der Adressierung in einem Netzwerk beschreiben Einen Adressierungsplan erstellen und auf ein Netzwerk anwenden Hosts, Servern und Netzwerkgerten in einer LAN-Umgebung gltige IP-Adressen zuweisen und diese berprfen Grundlegende Verwendung und Funktionsweise von NAT in einem kleinen Netzwerk erlutern, das an einen einzelnen ISP angeschlossen ist Die Funktion von DNS beschreiben und berprfen Funktionsweise und Vorteile der Verwendung privater und ffentlicher Adressierung beschreiben NAT fr ein kleines Netzwerk mit nur einer Verbindung zu einem ISP mithilfe von SDM aktivieren und das Funktionieren mit der Befehlszeilenschnittstelle und ping berprfen DHCP- und DNS-Betrieb auf einem Router konfigurieren, berprfen und korrigieren (einschlielich Befehlszeilenschnittstelle/SDM)

23

IV

24 25 26

I, III III, IV III, IV

27

III

28

CCNA ICND2-Prfungshandbuch

Tabelle 1: Prfungsthemen fr ICND1 (Forts.)


Nummer Teil des ICND1Buches, in dem das Thema behandelt wird III III Prfungsthema

28 29

Statische und dynamische Adressen fr Hosts in einer LAN-Umgebung anwenden Probleme bei der IP-Adressierung erkennen und korrigieren Ein kleines geroutetes Netzwerk aufbauen Grundlegende Routing-Konzepte beschreiben (darunter Paketweiterleitung und Ermittlung von Routen) Die Funktionsweise von Cisco-Routern beschreiben (darunter Starten des Routers, POST, RouterKomponenten) Geeignete Medien, Kabel, Ports und Stecker fr den Anschluss von Routern an andere Netzwerkgerte und Hosts auswhlen RIPv2 konfigurieren, berprfen und Fehler beheben Auf die Befehlszeilenschnittstelle des Routers zugreifen, um grundlegende Parameter festzulegen Die Schnittstelle eines Gerts anschlieen, konfigurieren und berprfen Konfiguration und Netzwerkanbindung mit ping, traceroute, Telnet, SSH oder anderen Dienstprogrammen berprfen Routing-Konfigurationsaufgaben fr eine statische oder Default-Route anhand bestimmter RoutingErfordernisse durchfhren und berprfen IOS-Konfigurationsdateien verwalten (zum Beispiel speichern, bearbeiten, aktualisieren, wiederherstellen) Cisco IOS verwalten Passwort- und physischen Schutz implementieren Netzwerkstatus und Router-Betrieb mit einfachen Dienstprogrammen (zum Beispiel ping, traceroute, Telnet, SSH, ARP, ipconfig), show- und debugBefehlen berprfen

30

I, III

31

III

32

I, III

33 34 35 36

III III III III

37

III

38

III

39 40 41

III III III

Einleitung
Tabelle 1: Prfungsthemen fr ICND1 (Forts.)
Nummer Teil des ICND1Buches, in dem das Thema behandelt wird Prfungsthema

29

Die fr ein WLAN erforderlichen Administrationsaufgaben erlutern und auswhlen 42 43 II II Standards fr drahtlose Medien beschreiben (IEEE, Wi-Fi Alliance, ITU/FCC) Zweck der Komponenten in einem kleinen drahtlosen Netzwerk nennen und beschreiben (SSID, BSS, ESS) Grundlegende Parameter nennen, die in einem drahtlosen Netzwerk zu konfigurieren sind, um zu gewhrleisten, dass die Gerte Verbindung zum richtigen Access-Point aufnehmen Sicherheitsmerkmale in drahtlosen Netzwerken und Fhigkeiten der WPA-Sicherheit vergleichend gegenberstellen (offene Netzwerke, WEP, WPA-1/2) Hufige Probleme beim Betrieb drahtloser Netzwerke erkennen Bedrohungen der Netzwerksicherheit erkennen und allgemeine Methoden zur Verringerung dieser Gefahren beschreiben 47 I Die aktuell zunehmenden Bedrohungen der Netzwerksicherheit und die Notwendigkeit erlutern, umfassende Sicherheitsrichtlinien zu implementieren, um die Bedrohungen zu verringern Allgemeine Methoden zur Verringerung hufiger Sicherheitsbedrohungen fr Netzwerkgerte, Hosts und Anwendungen erlutern Funktionen verbreiteter Sicherheitseinrichtungen und -anwendungen beschreiben Empfohlene Schutzverfahren einschlielich erster Schritte zum Schutz von Netzwerkgerten beschreiben WAN-Verbindungen implementieren und berprfen 51 52 IV IV Unterschiedliche Methoden fr den Anschluss an ein WAN beschreiben Eine einfache serielle WAN-Verbindung konfigurieren und berprfen

44

II

45

II

46

II

48

49 50

I I, II, III

30

CCNA ICND2-Prfungshandbuch

Prfungsthemen fr ICND2
Tabelle 0.2 listet die Prfungsthemen fr ICND2 (640-816) sowie die Teile des Titels CCNA ICND2-Prfungshandbuch auf, in denen die einzelnen Themen behandelt werden.
Tabelle 2: Prfungsthemen fr ICND2
Nummer Teil des ICND2Buches, in dem das Thema behandelt wird Prfungsthema

Switch mit VLANs und Switch-bergreifender Kommunikation konfigurieren und verifizieren und Problembehebung durchfhren 101 102 I I Erweiterte Switching-Technologien (einschlielich VTP, RSTP, VLAN, PVSTP, 802.1Q) beschreiben Bildung logisch getrennter Netzwerke durch VLANs und die Notwendigkeit des Routings zwischen diesen Netzwerken beschreiben VLANs konfigurieren und verifizieren und Problembehebung durchfhren Trunking bei Cisco-Switches konfigurieren und verifizieren und Problembehebung durchfhren VLAN-bergreifendes Routing konfigurieren und verifizieren und Problembehebung durchfhren VTP konfigurieren und verifizieren und Problembehebung durchfhren RSTP-Betrieb konfigurieren und verifizieren und Problembehebung durchfhren Ausgabe verschiedener show- und debug-Befehle interpretieren, um den Betriebszustand eines geswitchten Cisco-Netzwerks zu verifizieren Grundlegende Switch-Sicherheit (einschlielich Port-Security, nicht zugewiesener Ports, TrunkPorts usw.) implementieren IP-Adressierungsschema und IP-Dienste implementieren, um die Anforderungen an ein Zweigstellennetzwerk in einem mittelgroen Unternehmen zu erfllen 110 II VLSM-IP-Adressdesign berechnen und auf ein Netzwerk anwenden

103 104 105 106 107 108

I I II I I I

109

Einleitung Einleitung
Tabelle 2: Prfungsthemen fr ICND2 (Forts.)
Nummer Teil des ICND2Buches, in dem das Thema behandelt wird II Prfungsthema

31

111

Geeignetes klassenloses Adressierungsschema unter Verwendung von VLSM und Routensummierung bestimmen, um die Adressierungsanforderungen in einer LAN-/WAN-Umgebung zu erfllen Die technischen Anforderungen fr den Betrieb von IPv6 beschreiben (darunter Protokolle, dualer Stack, Tunneling usw.) IPv6-Adressen beschreiben Allgemeine Probleme in Verbindung mit der IP-Adressierungs- und der Host-Konfiguration erkennen und beheben Grundlegenden Betrieb und Routing auf CiscoGerten konfigurieren und Problembehebung durchfhren

112

113 114

V II, III

115 116 117 118 119 120 121

III III III II, III II, III II, III, IV II

Routing-Methoden und -Protokolle vergleichen und einander gegenberstellen OSPF konfigurieren und verifizieren und Problembehebung durchfhren EIGRP konfigurieren und verifizieren und Problembehebung durchfhren Konfiguration und Konnektivitt mit ping, traceroute und telnet oder SSH berprfen Probleme beim Routing beheben Betrieb von Router-Hardware und -Software mit
show- und debug-Befehlen berprfen

Grundlegende Router-Sicherheit implementieren NAT und ACLs in einem Zweigstellennetzwerk eines mittelgroen Unternehmens konfigurieren und berprfen und Problembehebung durchfhren

122 123 124

II II II

Zweck und Typen von ACLs beschreiben ACLs basierend auf den Filtererfordernissen des Netzwerks konfigurieren und anwenden ACL konfigurieren und anwenden, um den Telnetund SSH-Zugriff auf den Router einzuschrnken

32

CCNA ICND2-Prfungshandbuch

Tabelle 2: Prfungsthemen fr ICND2 (Forts.)


Nummer Teil des ICND2Buches, in dem das Thema behandelt wird II II V V V IV IV IV Prfungsthema

125 126 127 128 129 130 131 132

ACLs in einer Netzwerkumgebung verifizieren und berwachen Probleme der ACL-Implementierung beheben Die Grundfunktion von NAT erlutern NAT ber die Befehlszeilenschnittstelle fr ein gegebenes Netzwerk konfigurieren Probleme der NAT-Anwendung beheben WAN-Verbindungen einsetzen und berprfen Frame Relay auf Cisco-Routern konfigurieren und berprfen Probleme bei der WAN-Implementierung beheben Die VPN-Technologie beschreiben (darunter Bedeutung, Vorteile, Funktionen, Auswirkungen, Komponenten) PPP-Verbindungen zwischen Cisco-Routern konfigurieren und berprfen

133

IV

Prfungsthemen fr CCNA
In den frheren Prfungsversionen erstreckte sich die CCNA-Prfung ber einen Groteil des Stoffes fr die ICND-Prfung (640-811) sowie teilweise ber Themen der INTRO-Prfung (640-821). Die neue CCNA-Prfung (640-802) hingegen behandelt alle Themen der Prfungen ICND1 (640822) und ICND2 (640-816). Einer der Grnde fr diese ausgeglichenere Behandlung der Prfungen besteht darin, dass einige Themen, die ursprnglich Bestandteil der zweiten Prfung waren, zur ersten Prfung verschoben wurden. Die neue CCNA-Prfung (640-802) behandelt alle Themen aus ICND1 und ICND2. Die offiziellen Prfungsthemen zu CCNA 640-802, wie sie auf http://www.cisco.com aufgefhrt sind, erstrecken sich ber alle Themen, die in Tabelle 2 fr die ICND2-Prfung aufgefhrt sind, sowie einen Groteil der in Tabelle 1 genannten Themen der ICND1-Prfung. Die einzigen Prfungsthemen in diesen beiden Tabellen, die nicht als CCNA-Prfungsthemen aufgefhrt sind, sind die grau hervorgehobenen Themen in Tabelle 1. Trotz-

Einleitung

33

dem sind diese Themen Bestandteil der Prfung 640-802. Sie sind nur deswegen nicht unter den CCNA-Prfungsthemen aufgefhrt, weil sich eines der ICND2-Prfungsthemen auf dieselben Inhalte bezieht.

bersicht zu den ICND1- und ICND2-Kursen


Eine andere Mglichkeit, einen berblick zu den Prfungsthemen zu erhalten, besteht darin, sich die Kursbersichten der zugehrigen Kurse zu Gemte zu fhren. Cisco bietet zwei autorisierte Kurse mit CCNA-Bezug an, nmlich ICND1 und ICND2 (Interconnecting Cisco Network Devices 1 bzw. 2). Cisco autorisiert CLSPs (Certified Learning Solutions Providers) und CLPs (Certified Learning Partners) fr die Durchfhrung des entsprechenden Unterrichts. Diese autorisierten Unternehmen knnen auf der Grundlage dieses Materials speziell angepasste Lehrbcher erstellen, um in bestimmten Fllen Kurse anzubieten, die gezielt auf das Bestehen der CCNA-Prfung abgestimmt sind.

Wissenswertes zu den offiziellen Prfungshandbchern zu CCENT/CCNA ICND1 und CCNA ICND2


Wie bereits erwhnt, hat Cisco den Prfungsstoff fr CCNA in zwei Teile gegliedert: ICND1 behandelt Themen fr Techniker, die in Netzwerken kleiner Unternehmen ttig sind, whrend ICND2 den Stoff um weitere Themen ergnzt, die fr Netzwerktechniker in mittelgroen Unternehmen von Bedeutung sind. Analog umfasst die Serie der CCNA-Prfungshandbcher zwei Titel: CCENT/CCNA ICND1-Prfungshandbuch und CCNA ICND2-Prfungshandbuch. Diese beiden Titel behandeln die Themen aller Prfungen in der gebotenen Grndlichkeit, die teils sogar ber das fr die Prfungen erforderliche Ma hinausgeht, um sicherzustellen, dass Sie auch fr die schwierigeren Prfungen bestens vorbereitet sind. Die folgenden Abschnitte fhren die verschiedenen Eigenschaften des vorliegenden Buches und des Titels CCENT/CCNA ICND1-Prfungshandbuch auf. Beide Bcher weisen dieselben Grundmerkmale auf, das heit, wenn Sie sowohl das vorliegende Buch als auch den Band zu ICND1 bearbeiten, mssen Sie nicht die Einleitungen zu beiden Bchern lesen. Auerdem finden Leser, die beide Bcher zur direkten Vorbereitung der CCNA-Prfung 640802 verwenden (statt der zweimaligen Prfung), am Ende dieser Einleitung Vorschlge zur Lesereihenfolge.

34

CCNA ICND2-Prfungshandbuch

Lernziele und Methoden


Das wichtigste und auf der Hand liegende Ziel dieses Buches besteht darin, Ihnen beim Bestehen der ICND2- bzw. der CCNA-Prfung zu helfen. Wre es anders, wrde der Titel in die Irre fhren! Die verwendeten Methoden zielen aber auch darauf ab, Ihnen zu vermitteln, wie Sie Ihre Arbeit besser erledigen knnen. Dieses Buch setzt bestimmte Methoden ein, damit Sie herausfinden, welche Prfungsthemen Sie grndlicher durcharbeiten mssen, damit Sie diese Details vollstndig verstehen und sich merken und damit Sie feststellen knnen, ob Sie den Stoff beherrschen. Es soll Ihnen nicht durch das reine Auswendiglernen beim Bestehen der Prfungen helfen, sondern dadurch, dass Sie die Themen wirklich erfassen und verstehen. Die CCNA-Zertifizierung bildet die Grundlage fr zahlreiche Cisco-Profizertifikate, und es wre ein schlechter Dienst, wrde dieses Buch nicht dazu beitragen, dass Sie den Stoff wirklich beherrschen. Deshalb werden folgende Methoden benutzt: Hilfe bei der Feststellung, welche Prfungsthemen Sie noch nicht beherrschen Erluterungen und Informationen zum Fllen Ihrer Wissenslcken bungen, die Ihre Fhigkeit verbessern, sich Antworten auf Prfungsfragen ins Gedchtnis zu rufen oder abzuleiten Praktische bungen zu den Themen und zum Prfungsverfahren in Form von Testfragen auf der CD

Besonderheiten dieses Buches


Um Ihnen beim Lernen anhand dieser Bcher zu helfen, weisen die Kernkapitel einige Merkmale auf, die Sie dabei untersttzen, Ihre Zeit mglichst gut zu nutzen: Fragen zur berprfung Ihres Wissensstandes. Jedes Kapitel beginnt mit einem Test, mit dem Sie feststellen knnen, wie viel Zeit Sie diesem Kapitel widmen mssen. Wissensgrundlagen. Dabei handelt es sich um die zentralen Abschnitte des Kapitels. Sie erlutern Protokolle, Konzepte und Konfiguration des jeweiligen Themenbereichs. Aufgaben zur Prfungsvorbereitung. Der Abschnitt Prfungsvorbereitung am Ende des Kapitels enthlt eine Liste mit Lernaktivitten, die Sie durchfhren sollten. Jedes Kapitel zeigt die Aufgaben auf, die fr das Stu-

Einleitung

35

dium der enthaltenen Themen am sinnvollsten sind. Es gibt folgende Mglichkeiten: Wiederholung. Das Symbol fr die zentralen Themen erscheint neben den wichtigsten Punkten im Abschnitt Grundlagenthemen. Unter der berschrift Wiederholung werden die zentralen Themen des Kapitels mit der jeweiligen Seitenzahl aufgelistet. Zwar kann in der Prfung der gesamte Kapitelinhalt vorkommen, aber ganz sicher mssen Sie das beherrschen, was in den zentralen Themen steht. Vervollstndigen Sie die Listen und Tabellen. Damit Sie sich einige Fakten besser merken knnen, finden Sie die wichtigeren Listen und Tabellen des Kapitels in Anhang J auf der CD. Dieses Dokument enthlt nur einen Teil der Informationen, damit Sie sie vervollstndigen knnen. In Anhang K finden Sie zum leichteren Vergleich die vollstndigen Listen und Tabellen. Definitionen. Auch wenn es unwahrscheinlich ist, dass Sie in der Prfung aufgefordert werden, einen Begriff zu definieren, so setzen die CCNA-Prfungen doch voraus, dass Sie zahlreiche Termini im Zusammenhang mit Netzwerken lernen und beherrschen. In diesem Abschnitt sind jeweils die wichtigsten aus dem Kapitel zusammengestellt. Sie sollen eine Kurzdefinition verfassen und Ihre Antwort mit dem Glossar am Ende des Buches vergleichen. Befehlsreferenztabellen. Einige Kapitel behandeln zahlreiche Konfigurations- und EXEC-Befehle, die in diesen Tabellen aufgefhrt und beschrieben werden. Verwenden Sie diesen Abschnitt bei der Prfungsvorbereitung zum Nachschlagen, aber lesen Sie die Tabellen auch, whrend Sie die Aufgaben lsen, um sicher zu sein, dass Sie wissen, was die einzelnen Befehle bewirken. Praktische Examen auf der CD. Die Begleit-CD enthlt ein Prfungsmodul (von Boson Software, http://www.boson.com) mit zahlreichen realistischen Prfungsfragen zum ben. Mithilfe der CD knnen Sie eine simulierte ICND2- oder CCNA-Prfung ablegen. (Eine simulierte ICND1oder CCNA-Prfung knnen Sie mit der CD zum CCENT/CCNA ICND1-Prfungshandbuch durchspielen.) Videos zur Subnetzen. Die Begleit-DVD enthlt eine Reihe von Videos, die zeigen, wie Sie verschiedene Fakten ber IP-Adressierung und Subnetze herausbekommen insbesondere, indem Sie die in diesem Buch beschriebenen Abkrzungen verwenden. bungen zu Subnetzen. Anhang D auf der CD enthlt zahlreiche bungsprobleme zu Subnetzen mit Antworten und Erluterungen zum

36

CCNA ICND2-Prfungshandbuch Lsungsweg. Sie ist eine hervorragende Lernhilfe, um die Subnetzbildung gut und schnell zu erlernen. bungsszenarien auf der CD: Anhang F auf der CD enthlt einige Netzwerkszenarien fr zustzliche Studien, die verschiedene Netzwerke und Anforderungen beschreiben und Sie durch Entwurf, Konfiguration und berprfung fhren. Sie sind fr den Erwerb praktischer Fhigkeiten selbst ohne Laboranlage hilfreich. Begleitende Website. Auf der Website http://www.ciscopress.com/title/ 1587201828 werden neueste Materialien verffentlicht, die komplexe Prfungsthemen weiter verdeutlichen. Schauen Sie auf dieser Website regelmig nach neuen und aktualisierten Beitrgen des Autors, die tiefere Einsichten in schwierigere Themen bieten.

Aufbau des Buches


Dieses Buch enthlt 18 Kapitel, wobei Kapitel 18 den Stoff zum Teil zusammenfasst und Vorschlge zur Herangehensweise an die Prfungen enthlt. Jedes Kapitel handelt einen Teil der Themen ab, die Gegenstand der ICND2Prfung sind. Die Kapitel sind zu Teilen zusammengefasst und behandeln die folgenden Themen: Teil I: LAN-Switching Kapitel 1, VLANs. Dieses Kapitel erlutert die Konzepte und die Konfiguration virtueller LANs einschlielich des VLAN-Trunkings und des VTP-Protokolls. Kapitel 2, Das Spanning-Tree-Protokoll. Dieses Kapitel enthlt eine erschpfende Beschreibung des ursprnglichen STP-Protokolls (Spanning Tree Protocol) sowie des neuen RSTP (Rapid STP) und erlutert zugehrige Funktionen, die Konfiguration und die Problembehebung. Kapitel 3, Problembehebung beim LAN-Switching. Dieses Kapitel erlutert einige allgemeine Ideen zu Fragen der Problembehebung in Netzwerken, wobei der Schwerpunkt auf den von LAN-Switches verwendeten Weiterleitungsprozessen liegt. Teil II: IP-Routing Kapitel 4, IP-Routing: Statische und verbundene Routen. Dieses Kapitel untersucht, wie Router statische und verbundene Routen zur Routing-Tabelle hinzufgen, und erklrt zudem das Prinzip des Routings (d. h. der Weiterleitung) von Paketen.

Einleitung

37

Kapitel 5, VLSM und Routensummierung. Dieses Kapitel beschreibt, wie IP-Routing und Routing-Protokolle die Verwendung verschiedener Subnetzmasken in einem einzelnen klassenbezogenen Netzwerk untersttzen. Ferner werden die mathematischen Verfahren gezeigt, auf denen die Summierung mehrerer Routen zu einem Routing-Tabelleneintrag basiert. Kapitel 6, IP-ACLs. Dieses Kapitel untersucht, wie ACLs Pakete filtern, damit der Router sie nicht weiterleitet. Es veranschaulicht die Funktion und Konfiguration von Standard-ACLs und erweiterten ACLs, wobei auch ACLs mit Namen sowie nummerierte ACLs bercksichtigt werden. Kapitel 7, Problembehebung beim IP-Routing. Das Kapitel enthlt einen strukturierten Plan zur Eingrenzung des Problems zweier Hosts, die eigentlich Pakete austauschen knnen sollten, dies aber nicht knnen. Auerdem enthlt das Kapitel eine Anzahl von Tipps und Tools, mit denen sich Routing-Probleme analysieren lassen. Teil III: Konfiguration und Problembehebung bei Routing-Protokollen Kapitel 8, Theorie zu Routing-Protokollen. Dieses Kapitel erlutert die Theorie von Distanzvektor- und Link-State-Protokollen. Kapitel 9, OSPF. Dieses Kapitel beschreibt OSPF. Es enthlt unter anderem eine genauere Erluterung zur Link-State-Theorie in der Form, wie sie bei OSPF implementiert ist, sowie Hinweise zur OSPFKonfiguration. Kapitel 10, EIGRP. Dieses Kapitel behandelt EIGRP. Es liefert eine Beschreibung der Theorie hinter EIGRP sowie Angaben zur Konfiguration und Verifizierung von EIGRP. Kapitel 11, Problembehebung beim Routing-Protokollen. Dieses Kapitel erklrt einige typische Grnde dafr, dass es Routing-Protokollen nicht gelingt, Routing-Daten auszutauschen. Hierzu werden exemplarisch hufig auftretende Probleme in Zusammenhang mit OSPF und EIGRP beschrieben. Teil IV: WANs Kapitel 12, Point-to-Point-WANs. Dieses recht kurze Kapitel beschreibt noch einmal die Grundlagen von WANs und erlutert PPP einschlielich CHAP im Detail. Kapitel 13, Frame Relay. Dieses Kapitel legt den Schwerpunkt auf die Terminologie und die Theorie hinter dem Frame Relay-Protokoll. Behandelt werden unter anderem die Optionen der IP-Adressierung bei der Verwendung von Frame Relay.

38

CCNA ICND2-Prfungshandbuch Kapitel 14, Konfiguration und Problembehebung bei Frame Relay. Dieses Kapitel erklrt eine Vielzahl von Konfigurationsoptionen fr Frame Relay, darunter auch Point-to-Point- und Point-to-MultipointSubschnittstellen. Ferner wird beschrieben, wie man die Hauptursachen hufiger Frame Relay-Probleme mithilfe von show-Befehlen eingrenzt. Kapitel 15, VPNs. Dieses Kapitel untersucht Funktionen und Protokolle, die bei der Erstellung sicherer VPNs ber das Internet zum Einsatz kommen. Es beschreibt auerdem die Grundlagen zu IPSec. Teil V: IP-Adressraum skalieren Kapitel 16, NAT. Dieses Kapitel untersucht detailliert die Ursachen fr das Ausbluten des IPv4-Adressraumes und beschreibt, wie die Netzwerkadressbersetzung und hier insbesondere die Port-Adressbersetzung bei der Lsung dieses Problems helfen. Das Kapitel beschreibt zudem, wie man NAT mithilfe des IOS-CLI auf Routern konfiguriert. Kapitel 17, IPv6. Dieses Kapitel stellt die Grundlagen zu IPv6 vor, darunter das 128-Bit-Adressformat, die OSPF- und EIGRP-Untersttzung fr IPv6 und die wesentlichen Eigenschaften der nativen IPv6Konfiguration. Ferner werden das Konzept des IPv6-Tunnelings und Migrationsstrategien vorgestellt. Teil VI: Abschlieende Vorbereitung Kapitel 18, Abschlieende Vorbereitung. Dieses Kapitel prsentiert einen Plan zur abschlieenden Vorbereitung der Prfung, nachdem Sie die Hauptteile dieses Buches bearbeitet haben. Hierbei liegt der Schwerpunkt auf der Erluterung der zahlreichen Lernoptionen, die das Buch bietet. Teil VII: Anhnge (in der Druckausgabe) Anhang A, Antworten zu den Fragen zur berprfung Ihres Wissensstandes. Enthlt die Antworten zu allen Fragen in den Kapiteln 1 bis 17. Anhang B, Konvertierungstabelle fr Dezimal- und Binrzahlen. Fhrt die Dezimalwerte 0 bis 255 nebst ihrer Binrquivalente auf. Anhang C, Aktualisierung der ICND2-Prfung, Version 1.0. Dieser Anhang enthlt eine Vielzahl kurzer Themen, die der Veranschaulichung oder Erweiterung von an frherer Stelle in diesem Buch behandelten Themen dienen soll. Der Anhang wird regelmig aktualisiert und dann auf http://www.ciscopress.com/ccna zum Download

Einleitung

39

angeboten. Die zum Zeitpunkt der Drucklegung dieses Buches aktuelle Version ist hier als Anhang C enthalten. (Auf der ersten Seite des Anhangs finden Sie Hinweise dazu, wie Sie berprfen, ob eine aktuellere Version von Anhang C online zur Verfgung steht.) Glossar. Das Glossar enthlt Definitionen fr alle in den Kapiteln 117 unter der berschrift Definitionen aufgefhrten Termini. Teil VIII: Anhnge (auf der CD) Die folgenden Anhnge stehen im PDF-Format auf der CD zu diesem Buch bereit: Anhang D, Subnetzbungen. Obwohl die Subnetzbildung in keinem der Kapitel in diesem Buch behandelt wird, ist ihre Kenntnis eigentlich die wichtigste Voraussetzung fr das Bestehen der ICND2Prfung. Dieser Anhang sowie die Anhnge E, H und I enthalten Material aus dem CCENT/CCNA ICND1-Prfungshandbuch. Sie sollten diesen Stoff auch dann beherrschen, wenn Sie das ICND1Buch nicht erworben haben. Dieser Anhang beschreibt schwerpunktmig eine groe Zahl praktischer Probleme bei der Subnetzbildung sowie selbstverstndlich die zugehrigen Lsungen. Die Antworten nutzen sowohl binre als auch verkrzte dezimale Prozesse, die in Kapitel 12 des ICND1-Buches beschrieben sind. (Anhang H dieses Buches gibt das Kapitel 12 des ICND1-Buches vollstndig wieder.) Anhang E, Subnetz-Referenzseiten. Dieser Anhang fasst den Prozess, mit dessen Hilfe man Lsungen zu verschiedenen wichtigen Fragen zur Subnetzbildung ermittelt, auf einer Seite zusammen. Das Ziel besteht darin, Ihnen eine bersichtliche Referenz zu bieten, die Sie bei der praktischen Arbeit stets zur Hand nehmen knnen. Anhang F, Zustzliche Szenarien. Eine Methode, Ihre Fhigkeiten bei der Problembehebung und der Netzwerkanalyse zu verbessern, besteht darin, mglichst viele verschiedene Netzwerkszenarien zu untersuchen, darber nachzudenken und dann zu berprfen, ob Sie zu den richtigen Lsungen gekommen sind. Dieser Anhang enthlt eine Reihe derartiger Szenarien. Anhang G, Videos zu Subnetzaufgaben. Die DVD enthlt verschiedene Videos zur Subnetzbildung, die Ihnen zeigen, wie man die in Anhang H (entspricht Kapitel 12 aus dem ICND1-Buch) behandelten Prozesse verwendet. Dieser Anhang enthlt Kopien der wichtigsten Elemente dieser Videos, die beim Betrachten der Videos ntzlich sein knnen. (Auf diese Weise mssen Sie in den Videos nicht hin und her springen.)

40

CCNA ICND2-Prfungshandbuch Anhang H, ICND1, Kapitel 12: IP-Adressierung und Subnetzbildung. Dieser Anhang entspricht dem Kapitel 12 aus dem CCENT/ CCNA ICND1-Prfungshandbuch. Das Kapitel erlutert die IPAdressierung und die Subnetzbildung, die als Basiswissen fr die ICND2-Prfung bentigt werden. Anhang H ist fr diejenigen Leser enthalten, die nicht ber das CCENT/CCNA ICND1-Prfungshandbuch verfgen, die Subnetzbildung jedoch fr die Prfung beherrschen mssen. Anhang I, ICND1, Kapitel 17: WAN-Konfiguration. Dieser Anhang entspricht dem Kapitel 17 aus dem CCENT/CCNA ICND1Prfungshandbuch. Kapitel 12 des vorliegenden Buches, Point-toPoint-WANs, enthlt den Vorschlag, vorab einige wichtige Aspekte zu wiederholen, die in Kapitel 17 des ICND1-Buches enthalten sind. Dieses Kapitel ist fr diejenigen Leser enthalten, die nicht ber das CCENT/CCNA ICND1-Prfungshandbuch verfgen. Anhang J, Tabellen zur bung. Dieser Anhang enthlt Schlsseltabellen und -listen aus allen Kapiteln, bei denen einige Inhalte entfernt wurden. Sie knnen diesen Anhang ausdrucken und die Tabellen und Listen zur bung vervollstndigen. Auf dies Weise lernen Sie, sich Tatsachen zu merken, die in den Prfungen relevant sein knnen. Anhang K, Lsungen zu den bungen. Dieser Anhang enthlt die Antworten zu den bungen in Anhang J. Anhang L, Offene Fragen zu ICND2. Dieser Anhang ist ein berbleibsel aus frheren Ausgaben des Buches. Dort enthalten war eine Reihe von offenen Fragen, deren Zweck darin bestand, Sie bei der Vorbereitung auf die Prfung zu untersttzen. Die nderungen in der vorliegenden Ausgabe machen diese Fragen unntig. Im Sinne eines erhhten Anwendernutzens haben wir diese Fragen in der Form, wie sie in der letzten Ausgabe erschienen, hier noch einmal aufgefhrt.

Verwendung dieses Buches zur Vorbereitung auf die ICND2-Prfung (640-816)


Dieses Buch verfolgt im Wesentlichen zwei Ziele: Es soll Sie auf die ICND2Prfung sowie in Kombination mit dem CCENT/CCNA ICND1-Prfungshandbuch auf die CCNA-Prfung vorbereiten. Die Verwendung dieses Buches zur Vorbereitung auf die ICND2-Prfung ist weitgehend unkompliziert: Lesen Sie nacheinander alle Kapitel und beachten Sie die Lernvorschlge in Kapitel 18, Abschlieende Vorbereitung. Bei den Hauptkapiteln 1 bis 17 knnen Sie gelegentlich fr sich selbst entscheiden, wie viel Sie davon lesen wollen. In manchen Fllen kennen Sie den

Einleitung

41

im Kapitel behandelten Stoff vielleicht schon zum Teil oder gar vollstndig. Damit Sie feststellen knnen, wie viel Zeit Sie einem Kapitel widmen sollten, beginnen die Kapitel stets mit den Fragen zur berprfung Ihres Wissensstandes. Wenn Sie fr ein Kapitel alle diese Fragen korrekt beantworten oder vielleicht nur eine falsch beantwortet haben , so knnen Sie zum Ende des Kapitels springen. Sie finden dort jeweils einen Abschnitt Aufgaben zur Prfungsvorbereitung, mit dem Sie fortfahren sollten. Abbildung 2 zeigt den Gesamtplan.
Beantworten Sie die Fragen zur berprfung Ihres Wissensstandes Mehr als eine falsche Antwort Maximal eine falsche Antwort, aber Sie mchten Ihr Wissen vertiefen Maximal eine falsche Antwort, und Sie wollen fortfahren

Lesen Sie den Abschnitt Wissensgrundlage.

Lesen und bearbeiten Sie die Aufgaben zur Prfungsvorbereitung.

zum nchsten Kapitel

Abbildung 2: Vorgehensweise zur Bearbeitung der einzelnen Kapitel

Wenn Sie die Kapitel 1 bis 17 abgeschlossen haben, knnen Sie die Anleitung in Kapitel 18 verwenden, um die verbleibenden Aufgaben zur Prfungsvorbereitung im Einzelnen zu planen. Kapitel 18 enthlt die folgenden Vorschlge: Rufen Sie auf http://www.ciscopress.com die aktuelle Version von Anhang C ab. Diese kann zustzliche prfungsrelevante Themen enthalten. ben Sie die Subnetzbildung mithilfe der in den Anhngen auf der CD enthaltenen Anleitungen. Wiederholen Sie die Aufgaben zur Prfungsvorbereitung, die Sie jeweils am Kapitelende finden, fr alle Kapitel. Wiederholen Sie die Szenarien im Anhang F auf der CD. Wiederholen Sie alle Fragen zur berprfung Ihres Wissensstandes. ben Sie den Prfungsablauf mithilfe der Prfungs-Engine.

42

CCNA ICND2-Prfungshandbuch

Verwendung der Bcher zur Vorbereitung auf die CCNA-Prfung (640-802)


Wollen Sie Ihre CCNA-Zertifizierung in Form der einteiligen Prfung CCNA (640-802) erwerben, knnen Sie dieses Buch zusammen mit dem CCENT/CCNA ICND1-Prfungshandbuch verwenden. Die beiden Bcher wurden fr die gemeinsame Nutzung beim Lernen fr die CCNA-Prfung entworfen. Fr die Lesereihenfolge haben Sie zwei sinnvolle Mglichkeiten. Die erste und auf der Hand liegende besteht darin, zunchst das ICND1Buch durchzuarbeiten und dann mit diesem Buch fortzufahren. Sie knnen aber auch zunchst alles lesen, was das erste Buch zu einem Themenbereich bietet, dann mit der Abhandlung zum Thema im zweiten Buch fortfahren und anschlieend zum ersten zurckkehren. Abbildung 3 zeigt meinen Lesevorschlag fr die beiden Bcher.
ICND1-Prfungshandbuch Beginnen Sie hier. Grundlagen zu Netzwerken Switching im LAN ICND2-Prfungshandbuch Switching im LAN IP-Routing IP-Routing Routing-Protokolle WANs Abschlieende Vorbereitung WANs IP-Adressraum skalieren Abschlieende Vorbereitung

Abbildung 3: Leseplan fr die Vorbereitung auf die CCNA-Prfung

Beide Leseplne haben ihre Vorzge. Der Wechsel zwischen den Bchern hilft Ihnen, sich jeweils auf ein Thema zu konzentrieren. Beachten Sie jedoch, dass es gewisse berschneidungen zwischen den beiden Prfungen und damit auch zwischen den beiden Bchern gibt. Nach den Kommentaren zu den vorhergehenden Ausgaben der Bcher kamen Leser, die vorher nichts mit Netzwerken zu tun hatten, im Allgemeinen besser zurecht, wenn sie erst das eine und dann das andere Buch durcharbeiteten. Leser mit mehr Erfahrung und Vorkenntnissen zogen dagegen eher einen Leseplan wie in Abbildung 3 vor. Beachten Sie, dass Sie fr die letzten Vorbereitungen anstelle von Kapitel 18 dieses Buches das gleichnamige Kapitel des ICND1-Buches benutzen knnen.

Einleitung

43

Beim Lernen fr die CCNA-Prfung (anstelle von ICND1 und ICND2) ist es zustzlich zum Vorgehen nach Abbildung 3 wichtig, dass Sie die Bildung von IP-Subnetzen beherrschen, bevor Sie mit den Teilen zu IP-Routing und Routing-Protokollen (Teile II und III) in diesem Buch fortfahren. In diesem Buch gehen wir nicht noch einmal auf die Grundlagen von Subnetzen und die zugrunde liegende Mathematik ein, sondern es wird vorausgesetzt, dass Sie wissen, wie Sie die Antworten finden. Die betreffenden Kapitel insbesondere Kapitel 5, VLSM und Routensummierung, sind wesentlich leichter zu verstehen, wenn Sie keine Mhe mit den damit verbundenen Berechnungen haben.

Weitere Informationen
Falls Sie Anmerkungen zu diesem Buch machen wollen, knnen Sie sie (in englischer Sprache) auf http://www.ciscopress.com einreichen. Gehen Sie einfach auf die Website, whlen Sie CONTACT US an und geben Sie Ihren Text ein. Cisco kann unter Umstnden nderungen vornehmen, die die CCNA-Zertifizierung berhren. Sie sollten sich stets unter http://www.cisco.com/go/ ccna ber den neuesten Stand informieren. Die CCNA-Zertifizierung ist die wohl wichtigste Zertifizierung von Cisco, auch wenn die neue CCENT-Zertifizierung ihr in Zukunft den Rang ablaufen knnte. Bisher ist die CCNA-Prfung jedenfalls die von fast allen Netzwerktechnikern angestrebte Cisco-Zertifizierung. Sie wird fr einige weitere Zertifizierungen vorausgesetzt und bildet den ersten Schritt, um sich als Netzwerkexperte mit nachgewiesenen Cisco-Kenntnissen auszuzeichnen. Das CCNA ICND2-Prfungshandbuch soll Ihnen beim Erwerb sowohl der CCENT- als auch der CCNA-Zertifizierung helfen. Es ist das Buch des einzigen von Cisco autorisierten Verlags zu CCNA ICND2. Wir von Cisco Press sind der Ansicht, dass Ihnen dieses Buch helfen kann, die Prfung zu bestehen, aber die eigentliche Arbeit mssen Sie leisten! Ich vertraue darauf, dass Ihre Zeit gut angelegt ist.

Teil I
LAN-Switching
1 2 3 VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Das Spanning-Tree-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Troubleshooting beim LAN-Switching. . . . . . . . . . . . . . . . . . . . . . 165

In diesem Teil behandelte offizielle1 Cisco-ICND2-Prfungsthemen Switch mit VLANs und Switch-bergreifender Kommunikation konfigurieren und verifizieren und Troubleshooting durchfhren Erweiterte Switching-Technologien (einschlielich VTP, RSTP, VLAN, PVSTP, 802.1q) beschreiben Bildung logisch getrennter Netzwerke durch VLANs und die Notwendigkeit des Routings zwischen diesen Netzwerken beschreiben VLANs konfigurieren und verifizieren und Troubleshooting durchfhren Trunking bei Cisco-Switches berprfen, verifizieren und Troubleshooting durchfhren VTP konfigurieren, berprfen und Troubleshooting durchfhren RSTP-Betrieb konfigurieren, berprfen und Troubleshooting durchfhren Ausgabe verschiedener show- und debug-Befehle interpretieren, um den Betriebszustand eines geswitchten Cisco-Netzwerks zu verifizieren Grundlegende Sicherheitsmanahmen (einschlielich Port-Security, nicht zugewiesene Ports, Trunk-Zugriff usw.) auf dem Switch implementieren

1. Die aktuellen Versionen der Prfungsziele finden Sie stets unter http://www.cisco.com.

Dieses Kapitel behandelt die folgenden Themen


VLAN-Funktionen Dieser Abschnitt erlutert Zweck und Bedeutung von VLANs. Ferner werden das VLAN-Trunking und das VTP-Protokoll beschrieben. Konfiguration und Verifizierung von VLANs und VLAN-Trunking Dieser Abschnitt zeigt, wie man VLANs und Trunks auf Cisco CatalystSwitches konfiguriert. VTP-Konfiguration und -Verifizierung Dieser abschlieende Teil des Kapitels erklrt, wie man VTP-Installationen konfiguriert und eine Problembehebung durchfhrt.

Kapitel 1
VLANs
Der erste Teil dieses Buches, der die Kapitel 1 bis 3 enthlt, legt den Schwerpunkt auf die Welt der LANs. Kapitel 1 untersucht die Funktionen und Konfigurationen in Zusammenhang mit virtuellen LANs (VLANs), whrend Kapitel 2, Das Spanning-Tree-Protokoll, die Frage behandelt, wie STP Schleifen in einem geswitchten Netzwerk verhindert. Kapitel 3, Problembehebung beim LAN-Switching, schlielich fasst zahlreiche LAN-Funktionen zusammen und untersucht die Vorgnge bei der Behebung hufig im LAN auftretender Probleme. Wie bereits in der Einleitung erwhnt, setzt dieses Buch voraus, dass Sie ber grundlegendes Wissen zu den wichtigsten in der ICND1-Prfung behandelten Themen verfgen. Wenn Sie sich bezglich dieser Voraussetzungen nicht sicher sind, sollten Sie noch einmal einen Blick auf die Auflistung der fr dieses Buch vorausgesetzten Kenntnisse werfen, die Sie unter der berschrift Prfungsthemen fr ICND1 in der Einleitung finden.

1.1

berprfen Sie Ihren Wissensstand

Dieser Abschnitt gestattet es Ihnen zu ermitteln, ob Sie das gesamte Kapitel lesen mssen. Wenn Sie maximal eine der folgenden zehn Fragen zur Selbsteinschtzung nicht oder falsch beantworten, knnen Sie mit dem Abschnitt Aufgaben zur Prfungsvorbereitung fortfahren. Tabelle 1.1 listet die wichtigsten berschriften dieses Kapitels und die Nummern der Fragen auf, die sich auf die betreffenden Abschnitte beziehen. Auf diese Weise knnen Sie Ihr Wissen in den jeweiligen Bereichen selbst einschtzen. Die Antworten zu den Fragen in diesem Abschnitt finden Sie in Anhang A.
Tabelle 1.1: Zuordnung der folgenden Fragen zu den einzelnen Themengebieten
Grundlagenthema VLAN-Funktionen Konfiguration und Verifizierung von VLANs und VLAN-Trunking VTP-Konfiguration und -Verifizierung Fragen 1 bis 5 6 bis 8 9 und 10

48

CCNA ICND2-Prfungshandbuch

1. Welcher der folgenden Begriffe in einem LAN entspricht am ehesten dem Begriff VLAN? a) Kollisions-Domne b) Broadcast-Domne c) Subnetz-Domne d) Einzel-Switch e) Trunk 2. Stellen Sie sich einen Switch mit drei konfigurierten VLANs vor. Wie viele IP-Subnetze sind erforderlich, wenn man annimmt, dass alle Hosts in allen VLANs TCP/IP verwenden wollen? a) 0 b) 1 c) 2 d) 3 e) Dies geht aus den Angaben nicht hervor. 3. Welche der folgenden Technologien kapselt den ursprnglichen EthernetFrame in einem Trunking-Header, statt einen anderen Header in den ursprnglichen Ethernet-Header einzufgen? a) VTP b) ISL c) 802.1Q d) ISL und 802.1Q e) Keine der vorgeschlagenen Antworten trifft zu. 4. Welche der folgenden Technologien fgt einen Trunking-Header fr alle VLANs mit Ausnahme eines einzigen hinzu? a) VTP b) ISL c) 802.1Q d) ISL und 802.1Q e) Keine der vorgeschlagenen Antworten trifft zu.

Kapitel 1 VLANs

49

5. Welcher der folgenden VTP-Modi gestattet die Konfiguration von VLANs auf einem Switch? a) Client-Modus b) Server-Modus c) Transparenter Modus d) Dynamischer Modus e) Keine der vorgeschlagenen Antworten trifft zu. 6. Angenommen, Sie erhalten die Information, dass auf Switch 1 der Parameter auto fr das Trunking an seiner Schnittstelle Fa0/5 konfiguriert wurde, die mit Switch 2 verbunden ist. Sie sollen nun Switch 2 konfigurieren. Welche der folgenden Trunking-Einstellungen wrde das Trunking zum Laufen bringen? a) Trunking turned on b) auto c) desirable d) access e) Keine der vorgeschlagenen Antworten trifft zu. 7. Ein Cisco-Switch wurde soeben an Sie ausgeliefert. An diesem Switch wurden bislang weder VLANs konfiguriert, noch ist eine VTP- oder irgendeine andere Konfiguration vorhanden. Ein Techniker aktiviert den Konfigurationsmodus und setzt nacheinander die Befehle VLAN 22 und name Hannahs-VLAN ab. Welche der folgenden Aussagen sind zutreffend? a) VLAN 22 ist in der Ausgabe des Befehls show vlan brief aufgefhrt. b) VLAN 22 ist in der Ausgabe des Befehls show running-config aufgefhrt. c) VLAN 22 wird bei diesem Vorgang nicht erstellt. d) VLAN existiert erst auf diesem Switch, wenn diesem VLAN mindestens eine Schnittstelle zugeordnet wurde.

50

CCNA ICND2-Prfungshandbuch

8. Welche der folgenden Befehle listen den Betriebszustand der Schnittstelle Gigabit 0/1 bezglich des VLAN-Trunkings auf? a) show interfaces gi0/1 b) show interfaces gi0/1 switchport c) show interfaces gi0/1 trunk d) show trunks 9. Ein Techniker hat gerade vier neue 2960-Switches installiert und ber Crossover-Kabel aneinander angeschlossen. Alle Schnittstellen haben den Status up and up. Der Techniker konfiguriert auf allen Switches den VTP-Domnennamen Fred und belsst alle vier Switches im VTP-ServerModus. Um 9:00 Uhr fgt der Techniker auf Switch SW1 VLAN 33 hinzu und setzt 30 Sekunden spter auf den anderen drei Switches den Befehl show vlan brief ab. Allerdings wird VLAN 33 auf diesen drei anderen Switches nicht gefunden. Welche der folgenden Antworten beschreibt die wahrscheinlichste Ursache fr das Problem, das aufgetreten ist? a) VTP macht es erforderlich, dass alle Switches dasselbe VTP-Passwort aufweisen. b) Der Techniker htte mehr Geduld haben und darauf warten sollen, dass SW1 das nchste periodische VTP-Update sendet. c) Da an 2960-Switches standardmig der Modus auto fr die Trunking-Administration vorgewhlt ist, kommt es bei keiner der SwitchVerbindungen zum Trunking. d) Keine der vorgeschlagenen Antworten trifft zu. 10. Die Switches SW1 und SW2 sind ber einen funktionsfhigen Trunk miteinander verbunden. Der Techniker mchte Konfigurationsnderungen im VLAN via VTP kommunizieren. Er konfiguriert ein neues VLAN namens VLAN 44 auf SW1, aber SW2 erhlt keine Informationen zur Existenz dieses neuen VLAN. Welche der folgenden Konfigurationseinstellungen auf SW1 und SW2 ist keine mgliche Ursache dafr, dass SW2 nicht von VLAN 44 erfhrt? a) VTP-Domnennamen larry vs. LARRY b) VTP-Passwrter bob vs. BOB c) VTP-Pruning (aktiviert vs. deaktiviert) d) VTP-Modi (Server- vs. Client-Modus)

Kapitel 1 VLANs

51

1.2

Wissensgrundlage

Ein Cisco Catalyst-Switch verwendet Voreinstellungen, die eine Inbetriebnahme unmittelbar nach der Installation also ohne vorherige Konfiguration gestatten. Bei den meisten Installationen allerdings werden drei wesentliche Elemente konfiguriert: die in diesem Kapitel behandelten VLANs, das Spanning-Tree-Protokoll, welches Gegenstand von Kapitel 2 ist, und eine Reihe administrativer Einstellungen, die sich nicht auf das Weiterleitungsverhalten des Switchs auswirken (diese werden im CCENT/ CCNA ICND1-Prfungshandbuch erlutert). Alle offiziellen Lernziele fr die ICND1-Prfung sind als Voraussetzung fr die ICND2-Prfung zu betrachten, obwohl Letztere diese Themen nicht explizit behandelt. So wird etwa im ICND1-Buch beschrieben, dass Switches MAC-Adressen erlernen, indem sie die Absender-MAC-Adresse eingehender Frames untersuchen und ihre Weiterleitungs- und Filterentscheidungen basierend auf der Ziel-MAC-Adresse des Frames treffen. In den LAN-spezifischen Kapiteln des ICND1-Buches (Kapitel 3 sowie Kapitel 7 bis 11) werden ferner die Funktionen von Autonegotiating, Kollisionen, KollisionsDomnen und Broadcast-Domnen behandelt. Obwohl also in der ICND2Prfung keine Frage speziell zu diesen Themen erscheinen muss, ist das entsprechende Wissen doch notwendig, um Fragen zu den Prfungszielen der ICND2-Prfung zu beantworten. Und natrlich bezieht sich die CCNA-Prfung auf alle Themen und Lernziele der ICND1- und ICND2-Prfungen. Neben den Grundfunktionen beschreibt das ICND1-Buch auch eine Vielzahl kleinerer Konfigurationsaufgaben, die entweder den Zugriff auf einen Switch ermglichen oder nach Gewhren des Zugriffs der Absicherung des Switchs dienen. Fr einen Switch mssen IP-Adresse, Subnetzmaske und Default-Gateway konfiguriert werden, damit von auen auf ihn zugegriffen werden kann. Cisco empfiehlt zustzlich zur physischen Absicherung weitere Konfigurationsmanahmen, die die Sicherheit des Switchs verbessern und einen Zugriff ber die Switch-Konsole verhindern. So werden insbesondere Passwrter konfiguriert, und fr den Remote-Zugriff sollte statt Telnet mglichst SSH (Secure Shell) verwendet werden. Der HTTP-Dienst muss ebenfalls deaktiviert werden. berdies sollte das Anmeldebanner eine Warnung an potenzielle Angreifer enthalten. Auerdem sollten die Syslog-Meldungen auf Eintrge hin geprft werden, die kennzeichnend fr verschiedene Angriffsformen sind. Die drei Kapitel im ersten Teil dieses Buches spinnen den Faden der LANGeschichte fort und erlutern Themen, die fr die ICND2-Prfungsziele wichtig sind. Insbesondere untersucht dieses Kapitel VLAN-Funktionen und behandelt zudem die Konfiguration und den Betrieb von VLANs. Der erste

52

CCNA ICND2-Prfungshandbuch

groe Abschnitt dieses Kapitels erlutert die Hauptfunktionen. Hier wird beispielsweise erklrt, wie der VLAN-Datenverkehr mithilfe von VLANTrunks zwischen Switches erfolgt und wie das Cisco-eigene VTP-Protokoll die Konfiguration von VLANs in einem Campus-LAN untersttzt. Der zweite Hauptteil des Kapitels behandelt die Konfiguration von VLANs und VLAN-Trunks, die statische Zuordnung von Schnittstellen zu einem VLAN und die Konfiguration eines Switchs, damit ein Telefon und ein PC, die an dieselbe Schnittstelle angeschlossen sind, sich in zwei separaten VLANs befinden. Der letzte Teil behandelt die VTP-Konfiguration und die Problembehebung.

1.3

VLAN-Funktionen

Bevor wir uns mit den Einzelheiten von VLANs auseinandersetzen, bentigen Sie zunchst bestimmte Kenntnisse zur Definition eines LAN. Zwar kann man sich LANs aus verschiedensten Blickpunkten heraus vorstellen, aber es gibt eine Perspektive, die das Verstndnis von VLANs erheblich erleichtert: Ein LAN umfasst alle Gerte in derselben Broadcast-Domne. Eine Broadcast-Domne enthlt alle an das LAN angeschlossenen Gerte, die, wenn eines der Gerte einen Broadcast-Frame sendet, eine Kopie dieses Frames erhalten. Man kann sich unter einem LAN und einer BroadcastDomne also grundstzlich dasselbe vorstellen. Ohne VLANs betrachtet ein Switch alle seine Schnittstellen als zur selben Broadcast-Domne zugehrig, d. h., alle angeschlossenen Gerte befinden sich im selben LAN. Mit VLANs kann ein Switch einige Schnittstellen einer Broadcast-Domne und andere Schnittstellen einer anderen BroadcastDomne zuordnen, wodurch mehrere Broadcast-Domnen entstehen. Diese einzelnen vom Switch erstellten Broadcast-Domnen heien virtuelle LANs (oder kurz VLANs). Abbildung 1.1 zeigt ein Beispiel, bei dem jeweils zwei Gerte Bestandteil zweier VLANs sind. Das Zuordnen von Hosts zu unterschiedlichen VLANs bietet viele Vorteile, auch wenn dies Abbildung 1.1 nicht unbedingt auf den ersten Blick zu entnehmen ist. Sie erschlieen sich erst, wenn man feststellt, dass ein Broadcast, den ein Host in einem VLAN sendet, von allen anderen Hosts im VLAN empfangen wird nicht aber von den Hosts in einem anderen VLAN. Je mehr Hosts ein einzelnes VLAN enthlt, desto hher ist die Anzahl der Broadcasts, und desto strker erhht sich auch die von den einzelnen Hosts im VLAN bentigte Verarbeitungszeit. Auerdem stehen diverse Softwarepakete, die als Protokoll-Analyzer bezeichnet werden, zum kostenlosen Download zur Verfgung.

Kapitel 1 VLANs

53

Dino

VLAN1
Fred

Wilma

VLAN2
Betty

Abbildung 1.1: Beispielnetzwerk mit zwei VLANs an einem Switch

Ein solcher Analyzer kann alle Frames empfangen und interpretieren, die ein Host empfngt. (Einen empfehlenswerten kostenlosen Analyzer finden Sie etwa unter http://www.wireshark.org.) Infolgedessen machen grere VLANs anderen Hosts mehr und auch unterschiedlichere Broadcasts zugnglich. Hier kann ein Angreifer, der einen Protokoll-Analyzer verwendet, mehr Frames analysieren, um die Basis fr einen ReconnaissanceAngriff (dt. Erkundungsangriff) zu schaffen. Es gibt wichtige Grnde fr die Verteilung von Hosts auf verschiedene VLANs. Dies bietet sich beispielsweise an, um flexiblere Designs zu entwickeln, die Benutzer etwa nach Abteilungen oder Arbeitsgruppen statt nach ihrem Standort gruppieren, Gerte in kleinere LANs (Broadcast-Domnen) zu segmentieren und so den von den einzelnen Hosts im VLAN verursachten Overhead zu verringern, ein VLAN auf einen einzelnen Access-Switch zu beschrnken und so die Prozessorlast fr STP zu verringern, mehr Sicherheit zu erzwingen, indem Hosts, die mit sensiblen Daten arbeiten, in einem separaten VLAN gehalten werden, den von einem IP-Telefon gesendeten Datenverkehr von Daten zu separieren, die von einem an das Telefon angeschlossenen PC bermittelt werden. Wir werden die Grnde fr die Einrichtung von VLANs in diesem Kapitel nicht weiter behandeln, sondern uns mit Switch-bergreifenden VLANs und
Wichtig!

54

CCNA ICND2-Prfungshandbuch

mit deren Konfiguration beschftigen. Zu diesem Zweck behandelt der folgende Abschnitt das VLAN-Trunking eine Funktionalitt, die fr VLANs erforderlich ist, die sich ber mehrere LAN-Switches erstrecken.

1.3.1

Trunking mit ISL und 802.1Q

Wenn Sie VLANs in Netzwerken einsetzen, in denen mehrere miteinander verbundene Switches vorhanden sind, mssen diese Switches auf ihren Verbindungen untereinander das VLAN-Trunking einsetzen. Das VLAN-Trunking bewirkt, dass die Switches eine Funktion namens VLAN-Tagging einsetzen, bei dem der sendende Switch den Frame mit einem zustzlichen Header ergnzt, bevor er ihn ber den Trunk weiterleitet. Dieser zustzliche VLAN-Header enthlt ein VLAN-ID-Feld (VLAN-Kennung), sodass der sendende Switch die VLAN-ID eintragen kann und der empfangende Switch dann wei, welchem VLAN der jeweilige Frame zuzuordnen ist. Abbildung 1.2 veranschaulicht das grundstzliche Prinzip.
1
Wichtig!

3 Ethernet-Frame

Ethernet-Frame Switch 1

0/1

VLAN 1

Switch 2

0/1

VLAN 1

0/2

0/2

0/5

VLAN 2

0/5

VLAN 2

0/6

0/6

0/23

0/13

Trunk
VLAN-ID 2 Ethernet-Frame

Abbildung 1.2: VLAN-Trunking zwischen zwei Switches

Der Einsatz des Trunkings gestattet es Switches, Frames aus mehreren VLANs ber dieselbe physische Verbindung zu bertragen. So zeigt beispielsweise Abbildung 1.2, wie Switch 1 in Schritt 1 einen Broadcast-Frame an der Schnittstelle Fa0/1 empfngt. Um den Frame zu fluten, muss Switch 1 ihn an Switch 2 weiterleiten. Allerdings muss Switch 1 Switch 2 auch darber informieren, dass der Frame zu VLAN 1 gehrt. Aufgrund dessen fgt, wie Schritt 2 zeigt, Switch 2 einen VLAN-Header zum ursprnglichen

Kapitel 1 VLANs

55

Ethernet-Frame hinzu. Dieser Header enthlt in diesem Fall unter anderem die VLAN-ID 1. Sobald Switch 2 den Frame empfngt, erkennt er, dass der Frame von einem Gert aus VLAN 1 stammt, und wei infolgedessen, dass der Broadcast nur ber seine Schnittstellen in VLAN 1 weitergeleitet werden soll. Switch 2 entfernt den VLAN-Header und leitet den ursprnglichen Frame an seine Schnittstellen in VLAN 1 weiter (Schritt 3). Ein anderes Beispiel: Angenommen, das an der Schnittstelle Fa0/5 von Switch 1 angeschlossene Gert sendet einen Broadcast. Switch 1 sendet den Broadcast ber Port Fa0/6 (weil dieser Port sich im VLAN 2 befindet) und ber Fa0/23 (weil es sich hierbei um einen Trunk handelt, der mehrere verschiedene VLANs bedient). Switch 1 fgt einen Trunking-Header zum Frame hinzu, in dem die VLAN-ID 2 enthalten ist. Switch 2 bemerkt, dass der Frame zu VLAN 2 gehrt, und entfernt den Trunking-Header. Er wei nun, dass der Frame nur ber die Ports Fa0/5 und Fa0/6 gesendet werden darf, nicht aber ber die Ports Fa0/1 und Fa0/2. Cisco-Switches untersttzen zwei verschiedene Trunking-Protokolle: ISL (Inter-Switch Link) und IEEE 802.1Q. Trunking-Protokolle realisieren verschiedene Funktionen, deren wichtigste darin besteht, dass sie Header definieren, die die VLAN-ID benennen (vgl. Abbildung 1.2). Allerdings weisen sie auch einige Unterschiede auf, die wir als Nchstes behandeln werden.

ISL
Cisco entwickelte mit ISL bereits ein VLAN-Trunking-Protokoll viele Jahre, bevor das IEEE den Standard 802.1Q einfhrte. Da ISL proprietr ist, kann es nur zwischen zwei Cisco-Switches verwendet werden, die ISL ebenfalls untersttzen. (Dies ist zu beachten, weil es mittlerweile einige neuere CiscoSwitches gibt, die nicht mehr ISL, sondern nur noch die standardisierte Alternative 802.1Q untersttzen.) ISL kapselt jeden ursprnglichen Ethernet-Frame in einem ISL-Header und -Trailer. Der Original-Frame zwischen Header und Trailer bleibt unverndert. Abbildung 1.3 zeigt den Aufbau eines ISL-Frames.
ISL-Header CRC Gekapselter Ethernet-Frame 26 Bytes 4 Bytes

DA Type User SA LEN AAAA03 HSA VLAN BPDU INDEX RES

VLAN

BPDU

Abbildung 1.3: ISL-Header

56

CCNA ICND2-Prfungshandbuch

Der ISL-Header enthlt eine Anzahl von Feldern. Das wichtigste ist das VLAN-Feld, welches die Angabe der VLAN-Nummer ermglicht. Durch die Angabe der korrekten VLAN-Nummer im Header des Frames kann der sendende Switch sicherstellen, dass der empfangende Switch wei, zu welchem VLAN der gekapselte Frame gehrt. Zudem geben die Absender- und Empfngeradressen im ISL-Header die MAC-Adressen des sendenden und des empfangenden Switchs und nicht die Adressen der Gerte an, die den ursprnglichen Frame versendeten. Abgesehen davon sind weitere Einzelheiten zum ISL-Header fr uns nicht von Bedeutung.

IEEE 802.1Q
Das IEEE hat fr unsere heutigen LANs zahlreiche Protokolle standardisiert. Auch das VLAN-Trunking bildet hier keine Ausnahme. Erst Jahre, nachdem Cisco das ISL-Protokoll entwickelte hatte, schloss das IEEE die Arbeit an der Norm 802.1Q ab, die eine andere Mglichkeit des Trunkings definiert. Mittlerweile ist 802.1Q das verbreitetere Trunking-Protokoll, und Cisco untersttzt bei seinen neueren LAN-Switch-Modellen ISL teilweise selbst nicht mehr. (Dies gilt auch fr die in diesem Buch exemplarisch verwendeten 2960-Switches.) 802.1Q verwendet einen anderen Header fr das Frame-Tagging als ISL. Im Grunde genommen kapselt 802.1Q den Ursprungs-Frame eigentlich nicht zwischen einem weiteren Ethernet-Header und -Trailer, sondern ergnzt den Ethernet-Header des Original-Frames mit einem vier Byte langen VLANHeader. Dies fhrt dazu, dass der Frame anders als bei ISL nach wie vor die MAC-Adressen des ursprnglichen Absenders und Empfngers enthlt. Zudem erfordert, weil der Ursprungs-Header erweitert wurde, die 802.1QKapselung eine Neuberechnung der FCS (Frame Check Sequence, Rahmenprfzahl) im Ethernet-Trailer, weil diese Prfzahl auf dem Inhalt des gesamten Frames basiert. Abbildung 1.4 zeigt den 802.1Q-Header und das Format des genderten Ethernet-Headers.
Zieladresse Absenderadresse Lnge/Typ Daten FCS

Wichtig!

(New) Zieladresse Absenderadresse Tag Lnge/Typ Daten FCS

Type (16 Bits, 08100)

Prioritt (3 Bits)

Flag (1 Bit)

VLAN-ID (12 Bits)

Abbildung 1.4: 802.1Q-konformer Trunking-Header

Kapitel 1 VLANs

57

ISL und 802.1Q im Vergleich


Bisher wurden im Text eine Reihe von Unterschieden zwischen ISL und 802.1Q beschrieben, aber nur eine Gemeinsamkeit. Letztere besteht darin, dass sowohl ISL als auch 802.1Q einen VLAN-Header definieren, der ein VLAN-ID-Feld enthlt. Es ist allerdings so, dass jedes Trunking-Protokoll einen anderen Gesamt-Header verwendet, von denen einer standardisiert (802.1Q) und der andere proprietr (ISL) ist. In diesem Abschnitt wollen wir einige weitere Vergleichsaspekte zwischen den beiden Protokollen beleuchten. Beide untersttzen die gleiche Anzahl von VLANs, nmlich 4094. Zudem verwenden beide Protokolle 12 Bits des VLAN-Headers zur Nummerierung von VLANs, d. h. sie untersttzen 212 (also 4096) VLAN-IDs abzglich zweier reservierter Werte (0 und 4095). Beachten Sie, dass der ID-Bereich zwischen 1 und 1005 als normaler Bereich bezeichnet wird, whrend alle hheren IDs dem erweiterten Bereich zuzuordnen sind. Diese Unterscheidung ist im Zusammenhang mit dem VTP-Protokoll wichtig, welches wir im nchsten Abschnitt behandeln werden. ISL wie auch 802.1Q untersttzen eine separate Instanz des STP-Protokolls fr jedes VLAN, wobei die Implementierungsdetails sich jedoch unterscheiden (siehe Kapitel 2). Bei Campus-LANs mit redundanten Verbindungen hat die Verwendung nur einer STP-Instanz zur Folge, dass unter normalen Bedingungen einige Verbindungen ungenutzt bleiben und nur dann zum Einsatz kommen, wenn eine andere Verbindung ausfllt. Dank der Untersttzung mehrerer STP-Instanzen kann ein Techniker die STP-Parameter so optimieren, dass der Datenverkehr aus bestimmten VLANs den einen Teil der Verbindungen nutzt, whrend der Verkehr aus anderen VLANs die brigen Leitungen verwendet. Auf diese Weise werden alle Verbindungen im Netzwerk bestmglich ausgenutzt.

ANMERKUNG
802.1Q hat nicht von Anfang an mehrere STP-Instanzen untersttzt. Aufgrund dessen finden Sie in lteren Quellen unter Umstnden die (seinerzeit zutreffende) Information, dass 802.1Q nur eine einzelne STP-Instanz untersttzt. Ein wesentlicher hier behandelter Unterschied zwischen ISL und 802.1Q schlielich bezieht sich auf eine Eigenschaft, die als natives VLAN bezeichnet wird. 802.1Q definiert ein einzelnes VLAN in jedem Trunk als nativ, whrend ISL dieses Prinzip nicht verwendet. Die Default-Einstellung fr das native VLAN ist bei 802.1Q das VLAN 1. Definitionsgem fgt 802.1Q

58

CCNA ICND2-Prfungshandbuch

den Frames im nativen VLAN einfach keinen 802.1Q-Header hinzu. Wenn der Switch auf der anderen Seite des Trunks einen Frame ohne 802.1QHeader empfngt, wei er, dass dieser Frame dem nativen VLAN zuzuordnen ist. Beachten Sie, dass sich beide Switches aufgrund dieses Umstands darber einig sein mssen, welches VLAN das native ist. Ein natives VLAN nach 802.1Q bietet einige interessante Funktionen, die in der Hauptsache fr Verbindungen mit Gerten gedacht sind, die das Trunking nicht untersttzen. So knnte ein Cisco-Switch beispielsweise mit einem anderen Switch ohne 802.1Q-Trunking-Untersttzung verbunden werden. Der Cisco-Switch knnte dann Frames im nativen VLAN versenden; weil ein solcher Frame keinen Trunking-Header enthlt, wrde er vom anderen Switch auch verstanden werden. Das Konzept nativer VLANs bietet Switches die Mglichkeit, Daten zumindest in einem VLAN (nmlich dem nativen) weiterzuleiten, wodurch bestimmte Grundfunktionen mglich werden, zum Beispiel die Kontaktaufnahme mit einem Switch via Telnet. Tabelle 1.2 fasst die wichtigsten Eigenschaften von ISL und 802.1Q im Vergleich zusammen.
Tabelle 1.2: ISL und 802.1Q im Vergleich
Wichtig!

Funktion Wurde definiert von

ISL Cisco

802.1Q IEEE Ja Ja Ja Ja

Fgt einen weiteren 4-Byte-Header ein, statt den Ursprungs- Nein Frame vollstndig zu kapseln. Untersttzt VLANs im normalen Bereich (11005) sowie im Ja erweiterten Bereich (1006-4094). Ermglicht mehrere Spanning-Tree-Instanzen. Verwendet ein natives VLAN. Ja Nein

1.3.2

IP-Subnetze und VLANs

Wenn Sie VLANs in ein Netzdesign einbinden, dann mssen sich alle Gerte, die in einem VLAN sind, auch im selben Subnetz befinden. Derselben Logik entsprechend befinden sich Gerte, die Bestandteil verschiedener VLANs sind, auch in unterschiedlichen Subnetzen. Angesichts dieser Grundstze knnte man meinen, dass ein VLAN ein Subnetz ist und umgekehrt. Auch wenn dies nicht die ganze Wahrheit ist (denn ein VLAN ist ein Schicht-2-Konzept, whrend ein Subnetz der Schicht 3 zuzuordnen ist), ist die allgemeine Idee durchaus vernnftig, denn Gerte in einem einzelnen VLAN gehren stets demselben Subnetz an.

Kapitel 1 VLANs

59

Wie bei allen IP-Subnetzen auch muss, damit ein Host in einem Subnetz Pakete an einen Host in einem anderen Subnetz weiterleiten kann, mindestens ein Router vorhanden sein. Betrachten Sie etwa Abbildung 1.5: Diese zeigt einen Switch mit drei VLANs (gekennzeichnet durch die unterbrochenen Linien) und einen Teil der Logik, die verwendet wird, wenn ein Host in VLAN 1 ein IP-Paket an einen Host in VLAN 2 sendet.
Dino VLAN 1 IP-Subnetz 10.1.1.0/24 Fred Wilma Fa0/0 VLAN1 Frame VLAN2 Frame Barney VLAN 3 IP-Subnetz 10.1.3.0/24 VLAN 2 IP-Subnetz 10.1.2.0/24

Abbildung 1.5: Routing zwischen VLANs

In diesem Fall sendet Fred, wenn er ein Paket an Wilmas IP-Adresse schickt, dieses Paket an den Default-Router, denn Wilmas IP-Adresse befindet sich in einem anderen Subnetz. Der Router empfngt den Frame. Dieser enthlt einen VLAN-Header, aus dem hervorgeht, dass der Frame in das VLAN 1 gehrt. Der Router trifft seine Weiterleitungsentscheidung und schickt den Frame wieder ber dieselbe physische Leitung zurck. Im VLAN-TrunkingHeader ist allerdings nun VLAN 2 genannt. Der Switch seinerseits leitet den Frame dann an Wilma in VLAN 2 weiter. Man knnte nun den Eindruck gewinnen, dass es ein wenig ineffizient ist, das Paket vom Switch an den Router und dann gleich wieder zurck an den Switch zu schicken. Dies trifft in der Tat zu. In einem echten Campus-LAN bestnde die wahrscheinlichere Vorgehensweise in der Verwendung eines speziellen Switchs. Diesen nennt man Multilayer-Switch oder Layer-3Switch. Solche Switches knnen sowohl das Schicht-2-Switching als auch das Schicht-3-Routing durchfhren und damit den in Abbildung 1.5 gezeigten Router unntig machen.

1.3.3

Das VTP-Protokoll

Das Cisco-eigene VTP-Protokoll (VLAN Trunking Protocol) stellt eine Mglichkeit dar, mit der Cisco-Switches Daten zur VLAN-Konfiguration austauschen knnen. VTP gibt im Wesentlichen die Existenz aller VLANs

60

CCNA ICND2-Prfungshandbuch

basierend auf der VLAN-ID und dem VLAN-Namen bekannt. Allerdings macht VTP keine Details bezglich der Frage publik, welche Switch-Schnittstellen den einzelnen VLANs zugewiesen sind. Da wir die Konfiguration von VLANs in diesem Buch noch nicht erlutert haben, sollten Sie das folgende Beispiel beachten, um VTP besser einschtzen zu knnen. Stellen Sie sich vor, ein Netzwerk verfgt ber zehn Switches, die irgendwie ber VLAN-Trunks verbunden sind, und jeder Switch verfgt ber mindestens einen Port, der einem VLAN mit der VLAN-ID 3 und dem Namen Buchhaltung zugewiesen ist. Ohne VTP msste sich ein Netzwerktechniker an allen zehn Switches anmelden und dieselben beiden Konfigurationsbefehle eingeben, um das VLAN zu erstellen und den Namen zu definieren. Mit VTP mssten Sie VLAN 3 hingegen nur auf einem Switch erstellen die brigen neun wrden ber VTP ber dessen Existenz und den Namen in Kenntnis gesetzt. VTP definiert ein Schicht-2-Nachrichtenprotokoll, mit dessen Hilfe die Switches VLAN-Konfigurationsdaten austauschen. Wenn ein Switch seine VLAN-Konfiguration ndert d. h., wenn ein VLAN hinzugefgt oder entfernt oder ein vorhandenes VLAN gendert wird , bewirkt VTP, dass alle Switches ihre VLAN-Konfiguration synchronisieren und nachfolgend ber identische Informationen zu VLAN-IDs und VLAN-Namen verfgen. Der Vorgang hnelt ein wenig einem Routing-Protokoll, wobei jeder Switch regelmig VTP-Nachrichten sendet. Zudem senden Switches VTP-Nachrichten, sobald sich ihre VLAN-Konfiguration ndert. Wenn Sie beispielsweise ein neues VLAN 3 konfiguriert haben, dessen Name Buchhaltung lautet, wrde der Switch sofort VTP-Updates ber alle Trunks senden, um die neuen VLAN-Daten an die brigens Switches zu verteilen. Jeder Switch verwendet einen von drei VTP-Modi: den Server-, den Clientoder den transparenten Modus. Um VTP zu verwenden, versetzt der Techniker einige Switches in den Server-Modus und die brigen in den ClientModus. Danach kann die VLAN-Konfiguration auf den Servern hinzugefgt werden, und alle anderen Server und Clients erfahren nachfolgend von nderungen an der VLAN-Datenbank. Clients knnen nicht zur Konfiguration von VLAN-Daten verwendet werden. Erstaunlicherweise lsst sich VTP an Cisco-Switches nicht abschalten. Die Option, die einer solchen Abschaltung am nchsten kommt, ist der transparente Modus, in dem ein Switch VTP-Nachrichten zwar weiterleitet, sie aber fr sich selbst ignoriert. Im nchsten Abschnitt wird der normale Zustand beschrieben, wenn ein Techniker die Server- und Client-Modi einsetzt, um die Fhigkeiten von VTP

Kapitel 1 VLANs

61

zu nutzen. Danach folgt eine Erluterung der recht ungewhnlichen Vorgehensweise zur Deaktivierung von VTP via transparentem Modus.

Normaler VTP-Betrieb mit Server- und Client-Modus


Der VTP-Prozess beginnt mit der Erstellung des VLAN auf einem Switch, der als VTP-Server bezeichnet wird. Der VTP-Server verteilt nderungen an der VLAN-Konfiguration ber VTP-Nachrichten, die nur ber ISL- und 802.1Q-Trunks gesendet werden, im gesamten Netzwerk. VTP-Server wie auch VTP-Clients verarbeiten empfangene VTP-Nachrichten, aktualisieren die VTP-Konfigurationsdatenbank basierend auf diesen Nachrichten und versenden dann jeder fr sich VTP-Updates ber ihre Trunks. Am Ende des Vorgangs kennen alle Switches die neuen VLAN-Daten. VTP-Server und -Clients whlen aus, ob sie auf ein empfangenes VTPUpdate reagieren, und aktualisieren ihre VLAN-Konfigurationen basierend darauf, ob die Konfigurationsrevisionsnummer der VLAN-Datenbank sich erhht oder nicht. Jedes Mal, wenn ein VTP-Server seine VLAN-Konfiguration ndert, erhht er die aktuelle Konfigurationsrevisionsnummer um den Wert 1. Die VTP-Update-Nachrichten enthalten dann die neue Konfigurationsrevisionsnummer. Wenn ein anderer Client- oder Server-Switch eine VTP-Nachricht mit einer hheren Konfigurationsrevisionsnummer als der eigenen enthlt, aktualisiert er seine VLAN-Konfiguration. Abbildung 1.6 veranschaulicht, wie VTP in einem geswitchten Netzwerk agiert.
1 Neues VLAN hinzufgen
2 Rev 3 Rev 4
Wichtig!

3 VTP-Advertisement senden VTPClient

VTPServer

3 VTP-Advertisement senden VTPClient 4 Rev 3 Rev 4 5 Neue VLAN-Informationen synchronisieren

Rev 4 4 Rev 3 5 Neue VLAN-Informationen synchronisieren

Abbildung 1.6: VTP-Konfigurationsrevisionsnummern und VTP-Update

Abbildung 1.6 zeigt, dass alle Switches anfangs ber dieselbe VLAN-Konfigurationsrevisionsnummer verfgen, das heit, die VLAN-Konfigurationsdatenbanken aller Switches sind identisch sie alle kennen dieselben VLANNummern und -Namen. Zu Beginn des Vorgangs lautet die Konfigurations-

62

CCNA ICND2-Prfungshandbuch

revisionsnummer hier auf allen Switches 3. Abbildung 1.6 veranschaulicht die folgenden Schritte: 1. Jemand konfiguriert ein neues VLAN ber die Befehlszeile eines VTPServers. 2. Der VTP-Server setzt seine VLAN-Datenbankrevisionsnummer von 3 auf 4. 3. Der Server sendet VTP-Update-Nachrichten mit der Revisionsnummer 4 ber seine Trunk-Schnittstellen. 4. Die beiden VTP-Client-Switches stellen fest, dass die Updates eine hhere Revisionsnummer (4) enthalten als ihre aktuelle Revisionsnummer (3). 5. Die beiden VTP-Client-Switches aktualisieren ihre VLAN-Datenbanken basierend auf den VTP-Updates des Servers. Zwar zeigt das Beispiel nur ein kleines LAN, aber der Vorgang funktioniert in greren Netzwerken auf die gleiche Weise. Wenn ein VTP-Server die VLAN-Konfiguration aktualisiert, sendet er sofort VTP-Nachrichten ber alle Trunks. Die benachbarten Switches am anderen Ende der Trunks verarbeiten die empfangenen Nachrichten, ndern ihre VLAN-Datenbanken ab und senden dann ihrerseits VTP-Nachrichten an ihre Nachbarn. Der Vorgang wiederholt sich so lange auf den benachbarten Switches, bis am Ende alle Switches von der neuen VLAN-Datenbank Kenntnis erhalten haben.

ANMERKUNG
Den vollstndigen Vorgang, bei dem ein Server die VLAN-Konfiguration ndert und alle VTP-Switches von der neuen Konfiguration erfahren was am Ende dazu fhrt, dass alle Switches dieselben VLAN-IDs und -Namen kennen , nennt man Synchronisierung. VTP-Server und -Clients senden auerdem in regelmigen Abstnden von fnf Minuten VTP-Nachrichten fr den Fall, dass neu hinzugefgte Switches die VLAN-Konfiguration kennen lernen mssen. Zudem knnen, wenn ein neuer Trunk eingerichtet wird, Switches sofort eine VTP-Nachricht an den benachbarten Switch senden und dort die VLAN-Datenbank anfordern. Bislang haben wir VTP-spezifische Meldungen wahlweise als VTP-Updates oder als VTP-Nachrichten bezeichnet. In der Praxis definiert VTP drei Arten von Nachrichten: Summary-Advertisements, Subset-Advertisements und Advertisement-Anforderungen. Summary-Advertisements geben die Revisionsnummer, den Domnennamen und weitere Daten, aber keine VLANAngaben bekannt. Die regelmig alle fnf Minuten gesendeten VTP-Nach-

Kapitel 1 VLANs

63

richten sind VTP-Summary-Advertisements. Sobald eine nderung auftritt, die an einer erhhten Revisionsnummer erkannt werden kann, folgen dem Summary-Advertisement ein oder mehrere Subset-Advertisements, die jeweils einen Teilbereich der VLAN-Datenbank bekannt geben. Der dritte Nachrichtentyp die Advertisement-Anforderung ermglicht es einem Switch, VTP-Nachrichten direkt von einem benachbarten Switch abzurufen, sobald der Trunk verfgbar wird. Bei den Beispielen, die in diesem Buch gezeigt werden, werden die Nachrichten hinsichtlich ihres Verwendungszwecks nicht unterschieden.

Voraussetzungen fr die Funktionsfhigkeit von VTP zwischen zwei Switches


Wenn ein VTP-Client oder -Server eine Verbindung mit einem anderen VTPClient oder Server herstellt, verlangt Cisco IOS, dass die folgenden drei Voraussetzungen erfllt sein mssen, damit die beiden Switches VTP-Nachrichten austauschen knnen: Die Verbindung zwischen den Switches muss als VLAN-Trunk (nach ISL oder 802.1Q) betrieben werden. Die VTP-Domnennamen der beiden Switches mssen bereinstimmen. Die Gro-/Kleinschreibung wird hierbei bercksichtigt. Sofern auf mindestens einem der beiden Switches konfiguriert, mssen die VTP-Passwrter der beiden Switches bereinstimmen. Die Gro-/ Kleinschreibung wird hierbei bercksichtigt. Der VTP-Domnenname ist ein Designwerkzeug, das es Technikern gestattet, mehrere Gruppen von VTP-Switches die sogenannten Domnen zu erstellen, deren VLAN-Konfigurationen autonom sind. Zu diesem Zweck kann der Techniker eine Gruppe von Switches in der einen und eine andere Gruppe in einer anderen VTP-Domne konfigurieren. Switches ignorieren VTP-Nachrichten aus anderen Domnen. Mithilfe von VTP-Domnen kann ein Techniker also geswitchte Netzwerke in verschiedene administrative Domnen unterteilen. So knnte beispielsweise in einem groen Firmengebude mit vielen IT-Mitarbeitern der IT-Bereich einer Abteilung den VTPDomnennamen Buchhaltung verwenden, whrend der IT-Bereich einer anderen Abteilung den Namen Verkauf erhlt. Auf diese Weise knnen die einzelnen Abteilungen ihre Konfigurationen separat steuern und trotzdem Daten abteilungsbergreifend ber die LAN-Infrastruktur bertragen. Der VTP-Passwortmechanismus stellt eine Mglichkeit dar, zu verhindern, dass ein Angreifer die nderung der VLAN-Konfiguration eines Switchs verndert. Das Passwort selbst wird niemals unverschlsselt bertragen.
Wichtig!

64

CCNA ICND2-Prfungshandbuch

VTP mit dem transparenten Modus umgehen


Interessanterweise knnen Cisco-Switches VTP nicht einfach abschalten, um keine VLAN-Daten via VTP auszutauschen. Stattdessen mssen Sie den dritten VTP-Modus den transparenten Modus verwenden. Der transparente Modus bietet einem Switch Autonomie gegenber den brigen Switches. Wie VTP-Server knnen Switches im transparenten Modus VLANs konfigurieren. Im Gegensatz zu Ersteren jedoch aktualisieren Switches im transparenten Modus ihre VLAN-Datenbanken niemals basierend auf eingehenden VTP-Nachrichten, und sie versuchen auch nie, VTPNachrichten selbst zu erstellen und andere Switches ber ihre VLAN-Konfiguration zu informieren. VTP-Switches im transparenten Modus verhalten sich weitgehend so, als ob es VTP gar nicht gbe. Es gibt allerdings eine kleine Ausnahme: Switches im transparenten Modus leiten VTP-Updates, die sie von anderen Switches erhalten haben, weiter, um benachbarte VTP-Server oder -Clients zu informieren. Es gibt Netzdesigner, die aufgrund der verbundenen Risiken (die wir im nchsten Abschnitt behandeln werden) VTP vollstndig deaktivieren, indem sie alle Switches in den transparenten Modus versetzen. Andere wiederum versetzen nur einige wenige Switches in den transparenten Modus, um den zustndigen Technikern alle Mglichkeiten offen zu lassen, verwenden auf anderen Switches jedoch den Server- oder den Client-Modus.

VLAN-Konfiguration speichern
Um Datenverkehr fr ein VLAN weiterleiten zu knnen, muss ein Switch die VLAN-ID und den VLAN-Namen des VLAN kennen. Die Aufgabe von VTP besteht darin, diese Angaben bekannt zu machen. Die Summe der Konfigurationsdaten aller VLANs wird in diesem Zusammenhang als VLAN-Konfigurationsdatenbank oder einfacher: als VLAN-Datenbank bezeichnet. Interessanterweise speichert Cisco IOS die Angaben in der VLAN-Datenbank anders als Daten fr die meisten anderen Cisco IOS-Konfigurationsbefehle. Wenn VTP-Clients und -Server VLAN-Konfigurationen also in erster Linie VLAN-ID, VLAN-Name und andere VTP-Konfigurationseinstellungen speichern, wird die Konfiguration in einer Datei namens vlan.dat im Flashspeicher abgelegt. (Der Dateiname ist eine Kurzform fr VLAN-Datenbank.) Noch interessanter ist jedoch die Tatsache, dass Cisco IOS diese VLAN-Konfiguration weder in der Datei running-config noch in der Datei startup-config anzeigt. Es gibt keinen Befehl, um VTP- und VLAN-Konfiguration direkt anzuzeigen, sondern Sie mssen verschiedene

Kapitel 1 VLANs

65

show-Befehle verwenden, um Angaben ber VLANs und die VTP-Konfigura-

tion darzustellen. Die Speicherung der VLAN-Konfiguration in die Datei vlan.dat im Flashspeicher gestattet Clients wie auch Servern das dynamische Erlernen von VLANs. Die automatische Speicherung der Konfiguration bereitet Clients und Server dabei direkt auf den nchsten Ladevorgang vor. Wrde die dynamisch erlernte VLAN-Konfiguration nur zur laufenden Konfiguration hinzugefgt, knnte das Campus-LAN Opfer von Umstnden werden, unter denen alle Switches mehr oder weniger gleichzeitig ausfielen (was etwa bei einem Stromausfall im Gebude der Fall sein knnte). Die Folge wre der Totalverlust der VLAN-Konfiguration. Durch das automatische Speichern der Konfiguration in der Datei vlan.dat im Flashspeicher verfgt jeder Switch jedoch zumindest ber eine nicht allzu alte VLAN-Konfigurationsdatenbank und kann zudem VTP-Updates anderer Switches nutzen, sofern sich die VLAN-Konfiguration krzlich gendert hat. Ein interessanter Nebeneffekt dieses Vorgangs besteht darin, dass Sie, falls Sie einen VTP-Client oder -Server in einer bung verwenden und die gesamte Konfiguration entfernen wollen, um von Grund auf mit einem sauberen Switch neu anzufangen, nicht einfach nur den Befehl erase startup-config absetzen knnen. Lschen Sie nmlich nur die Startkonfiguration und laden den Switch dann neu, so erinnert dieser sich an die gesamten VLAN- und VTP-Konfigurationen, denn diese sind ja in der Datei vlan.dat im Flashspeicher abgelegt. Um diese Konfigurationsangaben vor dem Neuladen des Switchs zu entfernen, mssen Sie die Datei vlan.dat im Flashspeicher lschen. Dies geschieht mit einem Befehl wie etwa delete flash:vlan.dat. Switches im transparenten Modus speichern VLAN-Konfigurationsdaten sowohl in der Datei running-config als auch in der Datei vlan.dat im Flashspeicher. Die aktuelle Konfiguration kann zudem auch in der Startkonfiguration startup-config gespeichert werden.

ANMERKUNG
Bei einigen lteren Cisco IOS-Versionen fr Switches speicherten VTP-Server die VLAN-Konfiguration sowohl in der Datei vlan.dat als auch in der Datei running-config.

VTP-Versionen
Cisco untersttzt drei VTP-Versionen, die praktischerweise einfach durchnummeriert sind (Versionen 1, 2 und 3). Die meisten Unterschiede zwischen diesen Versionen sind fr die Erluterungen in diesem Buch irrelevant. Es

66

CCNA ICND2-Prfungshandbuch

gab allerdings in der VTP-Version 2 eine wesentliche Verbesserung gegenber Version 1, die sich auf den transparenten Modus bezog. Im Abschnitt VTP mit dem transparenten Modus umgehen haben wir weiter oben beschrieben, wie ein Switch mit der VTP-Version 2 funktioniert. In der VTP-Version 1 hingegen htte ein Switch im transparenten VTPModus zunchst den Domnennamen und das Passwort fr ein VTP-Update berprft. Sofern der Switch keine bereinstimmung bei diesen Parametern erkannte, verwarf er das VTP-Update, statt es weiterzuleiten. Das Problem bei VTP-Version 1 besteht darin, dass in Fllen, in denen ein Switch im transparenten Modus Bestandteil eines Netzwerks mit mehreren VTPDomnen ist, dieser Switch nicht alle VTP-Updates weiterleitet. Aufgrund dessen wurde die Logik im transparenten Modus bei Version 2 gendert: Domnenname und Passwort werden nun ignoriert, und ein Switch im transparenten Modus, der unter Version 2 luft, leitet alle empfangenen VTP-Updates weiter.

ANMERKUNG
Version 3 ist gegenwrtig nur auf High-End-Switches von Cisco implementiert. Wir werden in diesem Buch nicht nher darauf eingehen.

VTP-Pruning
Standardmig fluten Cisco-Switches Broadcasts (wie auch Unicasts mit unbekanntem Ziel) in allen aktiven VLANs ber alle Trunks, die nicht durch die aktuelle STP-Topologie gesperrt sind. (Weitere Informationen zu STP finden Sie in Kapitel 2.) In den meisten Campusnetzwerken hingegen existieren viele VLANs nur auf einigen wenigen und nicht auf allen Switches. Aus diesem Grund wre es Verschwendung, Broadcasts ber alle Trunks weiterzuleiten, denn in diesem Fall wrden Frames von Switches empfangen werden, die keinen Port im betreffenden VLAN haben. Switches untersttzen zwei Methoden, mit denen ein Techniker festlegen kann, aus welchen VLANs Daten ber einen Trunk gefhrt werden. Eine Methode erfordert die manuelle Konfiguration einer Liste zulssiger VLANs fr die einzelnen Trunks; wir werden im Verlauf dieses Kapitels noch darauf eingehen. Die zweite Methode das VTP-Pruning ermglicht es VTP, dynamisch zu ermitteln, welche Switches keine Frames aus bestimmten VLANs bentigen. In diesem Fall entfernt VTP diese VLANs aus den entsprechenden Trunks. Pruning bedeutet nichts anderes, als dass die entsprechenden Trunk-Schnittstellen von Switches keine Frames in dieses VLAN fluten. Abbildung 1.7 zeigt ein Beispiel, wobei die gestrichelten Kstchen Trunks bezeichnen, aus denen VLAN 10 automatisch entfernt wurde.

Kapitel 1 VLANs

67

Switch 4 Port 2 B

Geflutete Daten werden via Pruning entfernt.

Switch 5

Switch 2 VLAN 10

Port 1 Switch 6 Switch 3 Switch 1

Abbildung 1.7: VTP-Pruning

In Abbildung 1.7 verfgen die Switches 1 und 4 ber Ports in VLAN 10. Ist das VTP-Pruning netzwerkweit aktiviert, so erfahren die Switches 2 und 4 durch VTP automatisch, dass keiner der Switches, die unten links in der Abbildung gezeigt sind, ber Ports verfgen, die VLAN 10 zugewiesen sind. Infolgedessen entfernen die Switches 2 und 4 das VLAN 10 auf diesen Trunks. Das Pruning bewirkt also, dass die Switches 2 und 4 keine Frames in VLAN 10 ber diese Trunks sendet. Wenn Station A beispielsweise einen Broadcast sendet, fluten die Switches den Broadcast, wie durch die Pfeile in Abbildung 1.7 angedeutet. Das VTP-Pruning erhht die verfgbare Bandbreite durch Beschrnkung des gefluteten Datenverkehrs. Es stellt einen der beiden zwingendsten Grnde fr die Verwendung von VTP dar. (Der zweite ist die Tatsache, dass VTP die VLAN-Konfiguration vereinfacht und konsistenter gestaltet.)

Zusammenfassung der VTP-Eigenschaften


Tabelle 1.3 bietet einen vergleichenden berblick der drei VTP-Modi.
Tabelle 1.3: VTP-Eigenschaften
Funktion Sendet VTP-Nachrichten nur ber ISL- oder 802.1Q-Trunks. Untersttzt die CLI-basierte Konfiguration von VLANs. ServerModus Ja Ja ClientModus Ja Nein Ja Nein Transparenter Modus Ja Ja Ja Ja
Wichtig!

Kann den normalen VLAN-Bereich (11005) Ja verwenden. Kann den erweiterten VLAN-Bereich (10064095) verwenden. Nein

68

CCNA ICND2-Prfungshandbuch

Tabelle 1.3: VTP-Eigenschaften (Forts.)


Funktion ServerModus ClientModus Ja Transparenter Modus Nein

Synchronisiert die eigene KonfigurationsJa datenbank, wenn VTP-Nachrichten mit hherer Revisionsnummer empfangen werden. Erstellt und sendet alle fnf Minuten periodi- Ja sche VTP-Updates. Verarbeitet keine empfangenen VTP-Updates, Nein sondern leitet diese lediglich ber andere Trunks weiter. Legt VLAN-ID, VLAN-Name und VTP-Kon- Nein figuration in der Datei running-config ab. Legt VLAN-ID, VLAN-Name und VTPKonfiguration in der Datei vlan.dat im Flashspeicher ab. Ja

Ja Nein

Nein Ja

Nein Ja

Ja Ja

1.4

Konfiguration und Verifizierung von VLANs und VLAN-Trunking

Cisco-Switches bentigen fr den Betrieb zunchst einmal keine Konfiguration. Wenn Sie einen Cisco-Switch kaufen, alle Gerte installieren und korrekt verkabeln und den Switch dann einschalten, dann luft er. Ihr Switch funktioniert stets ohne jedwede Konfiguration, und zwar auch dann, wenn Sie mehrere Switches aneinander anschlieen. Einzige Ausnahme: Sie bentigen mehr als ein VLAN. Auch die STP-Voreinstellungen funktionieren ohne Probleme, aber wenn Sie VLANs verwenden wollen und dies ist in fast jedem Unternehmensnetzwerk der Fall , so sind letztendlich doch einige Konfigurationsarbeiten erforderlich. In diesem Kapitel werden wir die Einzelheiten der VLAN-Konfiguration in zwei greren Abschnitten behandeln. Zunchst werden wir den Schwerpunkt auf Konfigurations- und Verifizierungsaufgaben ohne Verwendung von VTP legen, d. h., wenn entweder die VTP-Default-Einstellungen benutzt werden oder der transparente VTP-Modus gewhlt wurde. Der abschlieende Abschnitt dieses Kapitels, VTP-Konfiguration und -Verifizierung, befasst sich dann im Speziellen mit VTP.

1.4.1

VLANs erstellen und einer Schnittstelle zuordnen

In diesem Abschnitt zeigen wir, wie man ein VLAN erstellt, ihm einen Namen gibt und Schnittstellen zuordnet. Da wir uns auf die wesentlichen

Kapitel 1 VLANs

69

Aspekte konzentrieren wollen, enthlt dieser Abschnitt Beispiele unter Verwendung eines einzelnen Switchs, VTP und Trunking sind also nicht erforderlich. Damit ein Cisco-Switch Frames in einem bestimmten VLAN weiterleitet, muss er so konfiguriert werden, dass er die Existenz des VLAN als gegeben akzeptiert. Auerdem muss der Switch ber Nicht-Trunk-Schnittstellen (sogenannte Access-Schnittstellen) verfgen, die dem VLAN zugeordnet sind. Die Konfigurationsschritte zur Erstellung des VLAN und die Zuordnung eines VLAN zu einer Access-Schnittstelle sind nachfolgend aufgelistet. (Beachten Sie, dass die Trunk-Konfiguration im Abschnitt Konfiguration des VLAN-Trunkings im weiteren Verlauf dieses Kapitels behandelt wird.) 1. Gehen Sie wie folgt vor, um ein neues VLAN zu konfigurieren: a) Geben Sie im Konfigurationsmodus den globalen Konfigurationsbefehl vlan vlan-id ein, um das VLAN zu erstellen und den VLANKonfigurationsmodus fr den Benutzer zu aktivieren. b) Geben Sie ber den VLAN-Befehl name name einen Namen fr das VLAN an (optional). Wird der Name nicht explizit konfiguriert, so lautet er VLANZZZZ, wobei ZZZZ die vierstellige VLAN-ID im Dezimalformat ist. 2. Gehen Sie wie folgt vor, um ein VLAN fr jede Access-Schnittstelle zu konfigurieren: a) Wechseln Sie mit dem Befehl interface in den Schnittstellen-Konfigurationsmodus der gewnschten Schnittstelle. b) Legen Sie mit dem Schnittstellenbefehl switchport access vlan id-number die VLAN-Nummer fest, die dieser Schnittstelle zugeordnet werden soll. c) Um das Trunking auf dieser Schnittstelle zu deaktivieren, vergewissern Sie sich zunchst, dass es sich um eine Access-Schnittstelle handelt, und geben Sie dann den Schnittstellenbefehl switchport mode access ein.
Wichtig!

ANMERKUNG
VLANs knnen im Konfigurationsmodus (wie in Schritt 1 beschrieben) oder mithilfe eines Konfigurationstools erstellt und benannt werden, das VLAN-Datenbankmodus genannt wird. Der VLAN-Datenbankmodus wird in diesem Buch nicht behandelt und ist gewhnlich auch nicht Gegenstand anderer Cisco-Prfungen.

70

CCNA ICND2-Prfungshandbuch

ANMERKUNG
Cisco-Switches untersttzen auch eine dynamische Methode der Zuordnung von Gerten zu VLANs, die auf den MAC-Adressen der Gerte basiert. Hierbei kommt das Tool VMPS (VLAN Management Policy Server) zum Einsatz. Dieses Tool wird jedoch wenn berhaupt nur selten verwendet. Obenstehender Ablauf kann auf einem Switch im transparenten Modus oder auf einem Switch ausgefhrt werden, bei dem die VTP-Voreinstellungen nicht gendert wurden. Zur Referenz zeigt die folgende Liste die VLAN- und VTP-spezifischen Default-Einstellungen fr Cisco-Switches.
Wichtig!

VTP-Server-Modus kein VTP-Domnenname automatische Konfiguration von VLAN 1 sowie VLANs 10021005 (diese VLANs knnen nicht gelscht werden) Zuordnung aller Access-Schnittstellen zu VLAN 1 (entspricht einem impliziten Befehl switchport access VLAN 1)

ANMERKUNG
In diesem Abschnitt wird vorausgesetzt, dass entweder die VTP-DefaultEinstellungen verwendet werden oder der Switch sich im transparenten Modus befindet. Der Abschnitt Vorsichtsmanahmen bei Vernderung der VTP-Default-Konfiguration weiter unten in diesem Kapitel greift die Voreinstellungen von Cisco-Switches wieder auf und beschreibt in diesem Zusammenhang im Gegensatz zum vorliegenden Abschnitt die Verwendung von VTP.

VLAN-Konfigurationsbeispiel 1: Vollstndige VLAN-Konfiguration


Listing 1.1 zeigt einen Konfigurationsablauf, bei dem ein neues VLAN erstellt und ihm Access-Schnittstellen hinzugefgt werden. Abbildung 1.8 stellt das im Netzwerk verwendete Beispiel dar, das einen LAN-Switch SW1 und zwei Hosts in jedem der VLANs 1 bis 3 umfasst. Das Beispiel zeigt die Einzelheiten des zweistufigen Vorgangs fr VLAN 2 und die Schnittstellen in VLAN 2. (Die Konfiguration von VLAN 3 wird im nchsten Abschnitt beschrieben.)

Kapitel 1 VLANs
VLAN 2

71

VLAN 3

VLAN 1

Fa0/13 Fa0/15

Fa0/14 Fa0/11

Fa0/16

Fa0/12

SW1

Abbildung 1.8: Netzwerk mit einem Switch und drei VLANs


Listing 1.1: VLANs konfigurieren und Schnittstellen zuordnen
sw1-2960#show vlan brief VLAN Name 000000000 Status Ports ---- --------------------------- --------- ------------------------------1 000000000000 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, 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 Gi0/1, Gi0/2 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup ! Oben existierte VLAN 2 noch nicht. Unten wurde VLAN 2 mit dem Namen Freds! vlan hinzugefgt, und es wurden zwei Schnittstellen zu VLAN 2 hinzugefgt. sw1-2960#configure terminal Enter configuration commands, one per line. End with CNTL/Z. sw1-2960(config)#VLAN 2 0000000 sw1-2960(config-vlan)#name Freds-vlan 0000000000000000 sw1-2960(config-vlan)#exit sw1-2960(config)#interface range fastethernet 0/13 - 14 sw1-2960(config-if)#switchport access VLAN 2 0000000000000000000000000 sw1-2960(config-if)#switchport mode access sw1-2960(config-if)#exit ! Unten zeigt der Befehl show running-config die Schnittstellenbefehle ! fr die Schnittstellen Fa0/13 und Fa0/14. Die Befehle VLAN 2 und ! name Freds-vlan erscheinen in der running-config nicht. sw1-2960#show running-config ! Zeilen zur Abkrzung weggelassen interface FastEthernet0/13 switchport access VLAN 2

72

CCNA ICND2-Prfungshandbuch

Listing 1.1: VLANs konfigurieren und Schnittstellen zuordnen (Forts.)


switchport mode access ! interface FastEthernet0/14 switchport access VLAN 2 switchport mode access ! SW1#show vlan brief VLAN Name Status Ports ---- --------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/15, Fa0/16, Fa0/17, Fa0/18 Fa0/19, Fa0/20, Fa0/21, Fa0/22 Fa0/23, Fa0/24, Gi0/1, Gi0/2 2 Freds-vlan active Fa0/13, Fa0/14 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup

Das Beispiel beginnt mit dem Befehl show vlan brief, mit dem die Standardeinstellungen der fnf nicht lschbaren VLANs berprft werden knnen. Alle Schnittstellen sind VLAN 1 zugewiesen. Beachten Sie insbesondere, dass dieser 2960-Switch ber 24 Fast-Ethernet-Ports (Fa0/1-Fa0/24) und zwei Gigabit-Ethernet-Ports (Gi0/1 und Gi0/2) verfgt, die alle als Bestandteil von VLAN 1 aufgefhrt sind. Weiter zeigt das Listing den Vorgang der Erstellung von VLAN 2 und die Zuordnung der Schnittstellen Fa0/13 und Fa0/14 zu VLAN 2. Beachten Sie hier insbesondere, dass im Listing der Befehl interface range benutzt wird; dieser bewirkt die Anwendung des Schnittstellenbefehls switchport access VLAN 2 auf beide Schnittstellen im Bereich, was auch aus der Ausgabe des Befehls show running-config am Ende des Listings hervorgeht. Nach Hinzufgen der Konfiguration wird der Befehl show vlan brief wiederholt, um das neue VLAN aufzulisten. Beachten Sie, dass dieser Befehl das VLAN, den Namen Freds-vlan und die dem VLAN zugeordneten Schnittstellen (Fa0/13 und Fa0/14) auffhrt.

Kapitel 1 VLANs

73

ANMERKUNG
Listing 1.1 verwendet die VTP-Default-Konfiguration. Allerdings wren, wenn am Switch zuvor der transparente VTP-Modus konfiguriert worden wre, die Konfigurationsbefehle VLAN 2 und name Freds-vlan ebenfalls in der Ausgabe von show running-config erschienen. Da sich der Switch jedoch im (standardmig vorgewhlten) Server-Modus befindet, speichert er diese beiden Befehle nur in der Datei vlan.dat. In bestimmten Fllen verwendet ein Switch je nach Betriebsmodus einer Schnittstelle das mit dem Befehl switchport access vlan vlan-id zugeordnete VLAN nicht. Der Betriebsmodus am Cisco-Switch gibt an, ob die Schnittstelle zum betreffenden Zeitpunkt ein Trunking-Protokoll verwendet. Eine Schnittstelle, die das Trunking gegenwrtig einsetzt, wird als Trunk-Schnittstelle bezeichnet, alle brigen Schnittstellen hingegen als Access-Schnittstellen. Aus diesem Grund verwenden Techniker Floskeln wie Fa0/12 ist ein Trunk-Port oder Fa0/13 ist eine Access-Schnittstelle und geben so an, ob das Design eine bestimmte Schnittstelle fr das Trunking (Trunk-Modus) oder nur zur Anbindung eines einzelnen VLAN (Access-Modus) verwendet. Der optionale Schnittstellenbefehl switchport mode access weist den Switch an, eine Schnittstelle lediglich als Access-Schnittstelle zuzulassen, d. h., die Schnittstelle verwendet in keinem Fall das Trunking und benutzt das zugeordnete Access-VLAN. Wenn Sie den optionalen Schnittstellenbefehl switchport mode access weglassen, knnte die Schnittstelle die Verwendung des Trunkings verhandeln, zur Trunk-Schnittstelle werden und das konfigurierte Access-VLAN ignorieren.

VLAN-Konfigurationsbeispiel 2: Krzere VLAN-Konfiguration


Listing 1.1 enthlt diverse optionale Konfigurationsbefehle. Ein Nebeneffekt dieses Umstandes besteht darin, dass das Listing etwas lnger als notwendig ist. Listing 1.2 zeigt eine wesentlich krzere Alternativkonfiguration. Es nimmt den Faden dort auf, wo Listing 1.1 endet, und stellt das Hinzufgen von VLAN 3 dar (vgl. Abbildung 1.8). Beachten Sie, dass SW1 zu Anfang des Listings noch nichts ber VLAN 3 wei.
Listing 1.2: Krzeres VLAN-Konfigurationsbeispiel (VLAN 3)
SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#interface range Fastethernet 0/15 - 16 000000000000000000000000000000000000000 SW1(config-if-range)#switchport access VLAN 3 0000000000000000000000000 % Access VLAN does not exist. Creating VLAN 3 SW1(config-if-range)#^Z

74

CCNA ICND2-Prfungshandbuch

Listing 1.2: Krzeres VLAN-Konfigurationsbeispiel (VLAN 3) (Forts.)


SW1#show vlan brief VLAN Name Status Ports ---- --------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/17, Fa0/18, Fa0/19, Fa0/20 Fa0/21, Fa0/22, Fa0/23, Fa0/24 Gi0/1, Gi0/2 2 Freds-vlan active Fa0/13, Fa0/14 3 VLAN0003 active Fa0/15, Fa0/16 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup SW1#

Listing 1.2 zeigt, wie ein Switch ein VLAN auf dynamische Weise erstellen kann, was im Gegensatz zum globalen Konfigurationsbefehl vlan vlan-id steht. Der Schnittstellenbefehl switchport access vlan verweist auf ein derzeit nicht konfiguriertes VLAN. Am Anfang dieses Listings wei SW1 wie gesagt nichts ber VLAN 3. Wenn der Schnittstellenbefehl switchport access VLAN 3 abgesetzt wird, stellt der Switch fest, dass das VLAN nicht existiert, und erstellt wie im hervorgehobenen Bereich des Listings gezeigt VLAN 3 mit dem Standardnamen VLAN0003. Zur Erstellung eines VLAN sind keine weiteren Schritte erforderlich. Am Ende des Vorgangs existiert VLAN 3 auf dem Switch und enthlt die Schnittstellen Fa0/15 und Fa0/16 (vgl. den hervorgehobenen Bereich der Ausgabe von show vlan brief). Zur Erinnerung sei noch einmal gesagt, dass ein Teil der in den Listings 1.1 und 1.2 gezeigten Konfiguration nur in der Datei vlan.dat im Flashspeicher und ein anderer Teil nur in der Datei running-config gespeichert wird. So befinden sich etwa die Schnittstellenbefehle in der Datei running-config, weswegen zur Speicherung der Konfiguration der Befehl copy running-config startup-config eingesetzt werden muss. Die Definitionen der neuen VLANs 2 und 3 hingegen wurden bereits automatisch in der Datei vlan.dat im Flashspeicher abgelegt. Die weiter unten in diesem Kapitel folgende Tabelle 1.7 enthlt eine Referenz der verschiedenen Konfigurationsbefehle, ihrer Speicherorte und der verschiedenen Mglichkeiten, die Konfigurationseinstellungen zu berprfen.

Kapitel 1 VLANs

75

1.4.2

VLAN-Trunking konfigurieren

Die Trunking-Konfiguration auf Cisco-Switches erfordert zwei wesentliche Konfigurationsentscheidungen: Trunking-Protokoll (IEEE 802.1Q, ISL oder Verhandlung des zu verwendenden Protokolls) der Administrativ-Modus (Trunking, kein Trunking oder Verhandlung) Cisco-Switches knnen das Trunking-Protokoll (ISL oder 802.1Q) entweder verhandeln oder direkt konfigurieren. Standardmig handeln CiscoSwitches den Trunking-Typ mit dem Switch am anderen Ende des Trunks aus und verwenden hierzu DTP (Dynamic Trunk Protocol). Beim Verhandeln wird ISL gewhlt, wenn beide Switches sowohl ISL als auch 802.1Q untersttzen. Untersttzt ein Switch beide Trunking-Typen, der andere jedoch nur einen Typ, so einigt man sich auf den von beiden Switches untersttzten Typ. Bei Switches, die beide Typen untersttzen, wird der von einer Schnittstelle bevorzugte Typ mit dem Schnittstellenbefehl switchport trunk encapsulation {dot1q | isl | negotiate} konfiguriert. (Viele der in letzter Zeit entwickelten Cisco-Switches so auch die 2960er untersttzen nur noch das 802.1Q-Trunking, weswegen die Voreinstellungen bei ihnen switchport trunk encapsulation dot1q lautet.) Unter dem Administrativ-Modus versteht man eine Konfigurationseinstellung, die bestimmt, ob das Trunking auf einer Schnittstelle eingesetzt werden soll oder nicht. Hierbei bezieht sich das Administrative darauf, was konfiguriert wird, whrend der Betriebsmodus einer Schnittstelle angibt, was gerade an der Schnittstelle geschieht. Cisco-Switches verwenden den mit dem Schnittstellenbefehl switchport mode konfigurierten Administrativ-Modus, um anzugeben, ob das Trunking verwendet wird. Tabelle 1.4 listet die Optionen des Befehls switchport mode auf.
Tabelle 1.4: Optionen fr den Trunking-Administrativ-Modus beim Befehl
switchport mode
Wichtig!

Befehlsoption
access trunk dynamic desirable

Beschreibung Verhindert die Verwendung des Trunkings, d. h., der Port agiert stets als Access-Port. Das Trunking wird grundstzlich verwendet. Initialisiert die Nachrichten zur Aushandlung (engl. Negotiation), mit denen dynamisch festgelegt wird, ob das Trunking verwendet werden soll oder nicht, und antwortet auf solche Nachrichten. Definiert auerdem die Trunking-Kapselung.

76

CCNA ICND2-Prfungshandbuch

Tabelle 1.4: Optionen fr den Trunking-Administrativ-Modus beim Befehl switchport mode (Forts.)
Befehlsoption
dynamic auto

Beschreibung Wartet passiv auf Trunking-Verhandlungsnachrichten. Bei Empfang solcher Nachrichten wird geantwortet und mit der Gegenseite verhandelt, ob und wenn ja, welches Trunking verwendet werden soll.

Betrachten Sie die beiden Switches in Abbildung 1.9. Die Abbildung zeigt eine erweiterte Variante des Netzwerks aus Abbildung 1.8 mit einem Trunk zu einem neuen Switch SW2. Teile der VLANs 1 und 3 sind mit Ports des Switchs 2 verbunden. Die beiden Switches verwenden eine Gigabit-EthernetLeitung fr den Trunk. In diesem Fall bildet sich der Trunk nicht dynamisch, weil die beiden 2960-Switches standardmig den Administrativ-Modus dynamic auto verwenden, das heit, kein Switch leitet den Verhandlungsprozess ein. Wenn man nun bei einem Switch den Administrativ-Modus dynamic desirable aktiviert, wird die Verhandlung eingeleitet. Die Switches einigen sich dann auf das Trunking via 802.1Q, da die 2960er nur dieses Protokoll untersttzen.
VLAN 2

VLAN 3

VLAN 1

Fa0/13 Fa0/15

Fa0/14 Fa0/11

Fa0/16

Fa0/12

SW1
Gi0/1 Trunk Gi0/2 Fa0/23 Fa0/21

Fa0/24

SW2

Fa0/22

Abbildung 1.9: Netzwerk mit zwei Switches und drei VLANs

Listing 1.3 zeigt anfangs die beiden Switches mit der Default-Konfiguration, d. h. ohne Trunking. Danach ist die Konfiguration von SW1 aufgefhrt.

Kapitel 1 VLANs

77

Durch sie beginnen die beiden Switches mit der Verhandlung und verwenden nachfolgend das 802.1Q-Trunking.
Listing 1.3: Trunking-Konfiguration und show-Befehle auf 2960-Switches
SW1#show interfaces gigabit 0/1 switchport Name: Gi0/1 Switchport: Enabled Administrative Mode: dynamic auto Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL Protected: false Unknown unicast blocked: disabled Unknown multicast blocked: disabled Appliance trust: none ! Beachten Sie, dass der nchste Befehl zu einer leeren Ausgabezeile fhrt. SW1#show interfaces trunk SW1# ! Als Nchstes wird der Administrativ-Modus auf dynamic desirable gesetzt. SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#interface gigabit 0/1 SW1(config-if)#switchport mode dynamic desirable 0000000000000000000000000000000000 SW1(config-if)#^Z SW1#

78

CCNA ICND2-Prfungshandbuch

Listing 1.3: Trunking-Konfiguration und show-Befehle auf 2960-Switches (Forts.)


01:43:46: %LINEPROTO-5-UPDOWN: Line protocol on 000000000 Interface GigabitEthernet0/1, changed state to down 00000000000000000000000000000000000000000 SW1# 01:43:49: %LINEPROTO-5-UPDOWN: Line protocol on 000000000 Interface GigabitEthernet0/1, changed state to up 000000000000000000000000000000000000000 SW1#show interfaces gigabit 0/1 switchport Name: Gi0/1 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) ! Zeilen zur Straffung weggelassen ! Der nchste Befehl hat weiter oben eine Leerzeile ausgegeben; nun zeigt er ! Informationen zu einem funktionsfhigen Trunk. SW1#show interfaces trunk Port Gi0/1 Port Gi0/1 Port Gi0/1 Port Gi0/1 Mode desirable Encapsulation Status 802.1q trunking Native vlan 1

Vlans allowed on trunk 1-4094 Vlans allowed and active in management domain 1-3 Vlans in spanning tree forwarding state and not pruned 1-3

Konzentrieren wir uns zunchst auf die wesentlichen Elemente der Ausgabe von show interfaces switchport am Anfang von Listing 1.3. Die Ausgabe zeigt die Default-Einstellung fr den Administrativ-Modus (dynamic auto). Da SW2 die gleiche Einstellung aufweist, wird der Betriebsstatus von SW1 als access angezeigt, d. h., es erfolgt kein Trunking. Die dritte hervorgehobene Zeile gibt an, dass auf diesem 2960-Switch lediglich das 802.1Q-Trunking untersttzt wird. (Bei einem Switch, der sowohl ISL als auch 802.1Q untersttzt, wrde hier standardmig negotiate aufgefhrt, das heit, der Kapselungstyp wird verhandelt.) Schlielich wird als verwendeter Trunking-Typ native aufgelistet eine subtile Art, zu sagen, dass der Switch keinen Trunking-Header zu Frames hinzufgt, die ber diesen Port weitergeleitet werden. (Die Frames werden also so behandelt, als ob sie sich in einem nativen 802.1Q-VLAN befnden.)

Kapitel 1 VLANs

79

Um das Trunking zu aktivieren, muss fr die Administrativ-Modi der beiden Switches eine Kombination gewhlt werden, die das Trunking ermglicht. Wenn nun wie im Listing gezeigt SW1 in den Modus dynamic desirable versetzt wird, leitet SW1 die Verhandlungen ein, und die beiden Switches verwenden nachfolgend das Trunking. Von besonderem Interesse ist die Tatsache, dass der Switch infolge der nderung des Administrativ-Modus die Schnittstelle zunchst deaktiviert und dann wieder aktiviert. Um sicherzustellen, dass das Trunking nun funktioniert, enthlt Listing 1.3 am Ende den Befehl show interfaces switchport. Beachten Sie, dass der Befehl die Administrativeinstellungen, die die konfigurierten Werte angeben, und die Betriebseinstellungen auflistet, die Angaben dazu enthalten, was der Switch gerade tut. In diesem Fall gibt SW1 nun an, sich im Betriebsmodus trunk zu befinden, wobei als Kapselung dot1Q gewhlt ist. Fr die ICND2- und die CCNA-Prfungen mssen Sie in der Lage sein, die Ausgabe des Befehls show interfaces switchport zu interpretieren, den Administrativ-Modus aus der Ausgabe abzuleiten und zu erkennen, ob die Leitung basierend auf den Einstellungen das Trunking verwendet. Tabelle 1.5 listet die Kombinationen der Administrativ-Modi und des voraussichtlichen Betriebsmodus (Trunk oder Access) auf, die sich aus den konfigurierten Einstellungen ergeben. Die Tabelle nennt dabei den Administrativ-Modus, der an einem Ende der Verbindung gewhlt wurde, in der linken Spalte und den Administrativ-Modus des anderen Switchs in der Kopfzeile.
Tabelle 1.5: Voraussichtlicher Trunking-Betriebsmodus basierend auf den konfigurierten Administrativ-Modi
access access dynamic auto trunk dynamic desirable Access Access Access Access dynamic auto Access Access Trunk Trunk trunk Access Trunk Trunk Trunk dynamic desirable Access Trunk Trunk Trunk

Wichtig!

Die auf einem Trunk untersttzten VLANs festlegen


Die Liste der zulssigen VLANs ermglicht Technikern, ein VLAN auf einem Trunk zu Administrationszwecken zu deaktivieren. Standardmig enthalten Switches alle mglichen VLANs (14094) in der Liste der zulssigen VLANs aller Trunks. Allerdings kann der Techniker die auf einem Trunk zulssigen VLANs mit dem folgenden Schnittstellenbefehl einschrnken:
switchport trunk allowed vlan {add | all | except | remove} vlan-list

80

CCNA ICND2-Prfungshandbuch

Dieser Befehl stellt eine Mglichkeit dar, VLANs unkompliziert zur Liste hinzuzufgen oder aus ihr zu entfernen. So gestattet die Option add dem Switch das Hinzufgen von VLANs zur Liste der zulssigen VLANs, whrend VLANs mit der Option remove aus der vorhandenen Liste entfernt werden. Die Option all bezeichnet alle VLANs, das heit, Sie knnen den Switch mit ihr auf die Voreinstellung (alle VLANs 14094 auf dem Trunk zulssig) zurcksetzen. Die Option except ist etwas knifflig: Sie fgt alle VLANs zur Liste hinzu, die nicht im Befehl aufgefhrt sind. So ergnzt der Befehl switchport trunk allowed vlan except 100-200 die VLANs 1 bis 99 und 201 bis 4094 zur Liste der auf diesem Trunk zulssigen VLANs. Zustzlich zur Liste der zulssigen VLANs gibt es noch drei weitere Grnde dafr, dass ein Switch das Weiterleiten von Daten eines bestimmten VLAN ber einen Trunk unterbinden sollte. Die folgende Liste fasst alle vier Grnde zusammen:
Wichtig!

Ein VLAN wurde aus der Liste der zulssigen VLANs entfernt. Ein VLAN ist in der Datenbank des Switchs nicht vorhanden oder nicht aktiv (dies lsst sich mit dem Befehl show vlan berprfen). Ein VLAN wurde via VTP-Pruning automatisch entfernt. Die STP-Instanz eines VLAN hat die Trunking-Schnittstelle in einen anderen Zustand als Forwarding versetzt. Der erste dieser drei weiteren Grnde soll etwas ausfhrlicher behandelt werden. (Der zweite das VTP-Pruning wurde bereits behandelt, und auf STP werden wir im nchsten Kapitel umfassend eingehen.) Wenn ein Switch nicht wei, dass ein VLAN vorhanden ist (was sich durch das Fehlen des betreffenden VLAN in der Ausgabe von show vlan belegen lsst), leitet er Frames in diesem VLAN ber keine seiner Schnittstellen weiter. Ferner kann ein VLAN zu Administrationszwecken auf jedem Switch mit dem globalen Konfigurationsbefehl shutdown vlan vlan-id heruntergefahren werden; auch in diesem Fall werden Frames in diesem VLAN nicht mehr weitergeleitet (und zwar auch nicht ber Trunks). Zusammenfassend kann man festhalten, dass Switches ber ihre Trunks keine Frames in nicht vorhandene oder deaktivierte VLANs weiterleiten. Dieses Buch nennt die vier Grnde fr das Beschrnken von VLANs auf einem Trunk in derselben Reihenfolge, in der das IOS sie in der Ausgabe von show interfaces trunk auffhrt. Dieser Befehl enthlt eine Abfolge von drei Listen mit den VLANs, die auf einem Trunk untersttzt werden. Hierbei handelt es sich um die folgenden Listen: VLANs in der Liste der fr den Trunk zulssigen VLANs

Kapitel 1 VLANs

81

VLANs der vorherigen Gruppe, die auf dem Switch konfiguriert und aktiv (d. h. nicht heruntergefahren) sind VLANs der vorherigen Gruppe, die nicht via Pruning entfernt wurden und den STP-Status Forwarding aufweisen Um einen Eindruck dieser drei Listen in der Ausgabe von show interfaces trunk zu vermitteln, zeigt Listing 1.4, wie VLANs aus unterschiedlichen Grnden fr einen Trunk ausgeschlossen werden. Die Befehlsausgabe wurde dem Switch SW1 in Abbildung 1.9 entnommen, nachdem die Konfiguration wie in den Listings 1.1, 1.2 und 1.3 gezeigt abgeschlossen wurde. Mit anderen Worten sind die VLANs 1 bis 3 vorhanden, und das Trunking ist einsatzbereit. Danach werden im Listing die folgenden Manahmen auf SW1 durchgefhrt: 1. VLAN 4 wird hinzugefgt. 2. VLAN 2 wird beendet. 3. VLAN 3 wird aus der Liste der fr den Trunk zulssigen VLANs entfernt.
Listing 1.4: Liste der zulssigen und der aktiven VLANs
! Die drei Listen mit VLANs im nchsten Befehl zeigen die zulssigen ! VLANs (1-4094), die zulssigen und aktiven VLANs (1-3) und die ! zulssigen/aktiven/nicht entfernten (not pruned) VLANs mit dem ! STP-Status Forwarding (1-3). SW1#show interfaces trunk Port Gi0/1 Port Gi0/1 Port Gi0/1 Mode desirable Encapsulation 802.1q Status trunking Native vlan 1

0000000000000000000000 Vlans allowed on trunk 1-4094 000000000000000000000000000000000000000000000 Vlans allowed and active in management domain 1-3

Port 000000000000000000000000000000000000000000000000000000 Vlans in spanning tree forwarding state and not pruned Gi0/1 1-3 ! Nun wird auf dem Switch das neue VLAN 4 konfiguriert, VLAN 2 wird ! deaktiviert und VLAN 3 wird aus der Liste der fr den Trunk zulssigen ! VLANs entfernt. SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#VLAN 4 SW1(config-vlan)#VLAN 2 SW1(config-vlan)#shutdown

82

CCNA ICND2-Prfungshandbuch

Listing 1.4: Liste der zulssigen und der aktiven VLANs (Forts.)
SW1(config-vlan)#interface gi0/1 SW1(config-if)#switchport trunk allowed vlan remove 3 SW1(config-if)#^Z ! Die drei Listen mit VLANs im nchsten Befehl zeigen die zulssigen VLANs ! (1-2, 4-4094), die zulssigen und aktiven VLANs (1,4) und und die ! zulssigen/aktiven/nicht entfernten (not pruned) VLANs mit dem STP-Status ! Forwarding (1,4). SW1#show interfaces trunk Port Gi0/1 Mode desirable Encapsulation Status 802.1q trunking Native vlan 1

! VLAN 3 erscheint nun nicht mehr, weil es aus der Liste der zulssigen ! VLANs entfernt wurde. Port Vlans allowed on trunk Gi0/1 1-2,4-4094 0000000000 ! VLAN 2 erscheint nun nicht mehr, weil es deaktiviert wurde. Die VLANs ! 5-4094 erscheinen nicht, weilsie auf SW1 nicht konfiguriert sind. Port 000000000000000000000000000000000000000000000 Vlans allowed and active in management domain Gi0/1 000 1,4 Port Gi0/1 Vlans in spanning tree forwarding state and not pruned 1,4

Trunking bei Cisco-IP-Telefonen


IP-Telefone von Cisco stellen via Ethernet Verbindungen zum IP-Netzwerk her, um VoIP-Pakete versenden zu knnen. Diese Telefone senden VoIPPakete an andere IP-Telefone, um Sprachverbindungen aufzubauen. Auerdem schicken sie Pakete an Voice-Gateways, die ihrerseits an das traditionelle Telefonnetz angeschlossen sind und auf diese Weise Verbindungen mit praktisch jedem Telefonanschluss auf der Welt herstellen knnen. Cisco nimmt an, dass knftig auf jedem Schreibtisch in einem Unternehmen sowohl ein IP-Telefon als auch ein PC stehen werden. Um das Kabelgewirr zu verringern, integriert Cisco in seine IP-Telefone jeweils einen kleinen LAN-Switch. Dieser Switch gestattet die unkomplizierte Anbindung der Gerte auf dem Schreibtisch: Eine Leitung fhrt vom Kabelschrank zum IPTelefon, und der PC wird dann ber ein kurzes Straight-Through-EthernetKabel an den telefoninternen Switch angeschlossen. Abbildung 1.10 zeigt die Verkabelung sowie auch ein paar weitere Informationen.

Kapitel 1 VLANs
Voice-VLAN 12

83

802.1Q Fa0/6 Trunking

Kein Trunking

IP

Access-VLAN 2

Abbildung 1.10: Typische Anbindung eines Cisco-IP-Telefons und eines PC an einen Cisco-Switch

Die Designrichtlinien fr die IP-Telefonie besagen, dass die Verbindung zwischen dem Telefon und dem Switch das 802.1Q-Trunking verwenden muss, und sich Telefon und PC in unterschiedlichen VLANs (und damit in verschiedenen Subnetzen) befinden sollten. Durch Platzierung der Telefone in dem einen VLAN und der an sie angeschlossenen PCs in einem anderen VLAN knnen Techniker den IP-Adressraum einfacher verwalten, QoSMechanismen (Quality of Service, Dienstgte) fr VoIP-Pakete leichter implementieren und die Sicherheit erhhen, indem Daten- und Sprachverkehr getrennt gehalten werden. Bei Cisco wird das fr den Telefonieverkehr verwendete VLAN als SprachVLAN und das fr den Datenverkehr vorgesehene VLAN als Daten-VLAN oder Access-VLAN bezeichnet. Damit der Switch die Daten korrekt weiterleitet, mssen Cisco-Switches die VLAN-ID sowohl des Sprach- als auch des Daten-VLAN kennen. Das Daten-VLAN wird, wie in den obigen Listings gezeigt, mit dem Befehl switchport access vlan vlan-id konfiguriert. Die Konfiguration des Sprach-VLAN erfolgt hingegen mit dem Schnittstellenbefehl switchport voice vlan vlan-id. In Abbildung 1.10 etwa msste die Schnittstelle Fa0/6 mit den Schnittstellenbefehlen switchport access VLAN 2 und switchport voice VLAN 12 konfiguriert werden. Tabelle 1.6 fasst die wesentlichen Aspekte zu Sprach-VLANs zusammen.
Tabelle 1.6: Konfiguration von Sprach- und Daten-VLANs
Gert Name des VLAN Konfigurationsbefehl
switchport voice vlan vlan-id switchport access vlan vlan-id
Wichtig!

Telefon Sprach-VLAN (oder Hilfs-VLAN) PC Daten- oder Access-VLAN

84

CCNA ICND2-Prfungshandbuch

1.4.3

VLANs und Trunking absichern

Switches sind ber benutzte wie auch unbenutzte Ports anfllig fr Sicherheitsrisiken. So knnte ein Angreifer beispielsweise einen Computer an eine Wandanschlussdose anschlieen, die mit einem Switch-Port verbunden ist, und auf diese Weise Probleme in einem diesem Port zugewiesenen VLAN verursachen. Auerdem knnte der Angreifer das Trunking verhandeln und zahlreiche auch VTP-spezifische Schwierigkeiten herbeifhren. Cisco gibt einige Empfehlungen zu der Frage ab, wie man unbenutzte Switch-Ports schtzt. Statt die Voreinstellungen zu verwenden, empfiehlt Cisco die folgende Konfiguration dieser Schnittstellen:
Wichtig!

Deaktivieren Sie die unbenutzte Schnittstelle mit dem Schnittstellenbefehl


shutdown administrativ.

Verhindern Sie ein Verhandeln des Trunkings, wenn der Port aktiviert ist. Hierzu unterbinden Sie mit dem Befehl switchport nonegotiate die Verhandlung oder setzen den Befehl switchport mode access ab, um die Schnittstelle statisch als Access-Schnittstelle zu konfigurieren. Weisen Sie den Port einem nicht verwendeten VLAN (einem sogenannten Park-VLAN) zu. Dies geschieht mit dem Befehl switchport access vlan vlan-id. Offengestanden wird die Sicherheitslcke natrlich geschlossen, wenn Sie die Schnittstelle einfach abschalten, aber auch die beiden anderen Schritte verhindern direkte Probleme, wenn ein anderer Techniker die Schnittstelle durch Absetzen des Befehls no shutdown aktiviert. Neben diesen Empfehlungen zu unbenutzten Ports legt Cisco auch nahe, die Verhandlung des Trunkings auf allen verwendeten Access-Schnittstellen zu deaktivieren und alle Trunks manuell fr das Trunking zu konfigurieren. Das Risiko besteht darin, dass ein Angreifer den Computer eines zulssigen Benutzers vom RJ45-Port abtrennen und seinen eigenen PC anschlieen kann, um nachfolgend das Trunking zu verhandeln. Wenn nun alle verwendeten Schnittstellen, auf denen kein Trunking verwendet werden soll, mit dem Schnittstellenbefehl switchport nonnegotiate konfiguriert werden, ist die dynamische Aktivierung des Trunkings auf diesen Schnittstellen nicht mehr mglich, wodurch entsprechende Risiken beseitigt werden. Ist das Trunking bei bestimmten Schnittstellen erforderlich, so empfiehlt Cisco eine manuelle Konfiguration.

Kapitel 1 VLANs

85

1.5

VTP-Konfiguration und -Verifizierung

Die VTP-Konfiguration erfordert zwar nur wenige Schritte, aber VTP hat das Potenzial, schwerwiegende Probleme zu verursachen entweder durch eine versehentliche Fehlkonfiguration oder infolge bswilliger Angriffe. Die folgenden Abschnitte behandeln zunchst die Gesamtkonfiguration. Danach folgen Anmerkungen zu Problemen, die vom VTP-Prozess verursacht werden knnen. Abschlieend erhalten Sie Informationen zur Behebung VTP-spezifischer Probleme.

1.5.1

VTP-Server und -Clients konfigurieren

Vor der Konfiguration von VTP mssen verschiedene VTP-Einstellungen festgelegt werden. Insbesondere muss der Techniker, wenn er VTP einsetzen will, entscheiden, welche Switches derselben VTP-Domne angehren sollen (diese Switches erhalten voneinander VLAN-Konfigurationsangaben). Ein Name muss fr die VTP-Domne ausgewhlt werden. Optional, aber empfehlenswert ist auch die Festlegung eines VTP-Passwortes. (Bei beiden Werten wird die Gro-/Kleinschreibung unterschieden.) Der Techniker muss auerdem entscheiden, welche Switches als Server agieren (dies sollten aus Redundanzgrnden mindestens zwei Switches sein) und welche Clients sein sollen. Nachdem die Planung abgeschlossen ist, kann VTP mit den folgenden Schritten konfiguriert werden: 1. Konfigurieren Sie den VTP-Modus mit dem globalen Konfigurationsbefehl vtp mode {server | client}. 2. Konfigurieren Sie den VTP-Domnennamen mit dem globalen Konfigurationsbefehl vtp domain domain-name. Die Gro-/Kleinschreibung wird unterschieden. 3. Konfigurieren Sie auf Clients und Servern jeweils dasselbe Passwort mit dem globalen Konfigurationsbefehl vtp password password-value (optional). Die Gro-/Kleinschreibung wird unterschieden. 4. Konfigurieren Sie mit dem globalen Konfigurationsbefehl vtp pruning das VTP-Pruning auf den VTP-Servern (optional). 5. Aktivieren Sie VTP-Version 2 mit dem globalen Konfigurationsbefehl vtp version 2 (optional). 6. Aktivieren Sie die Trunks zwischen den Switches. Listing 1.5 zeigt eine Beispielkonfiguration sowie den Befehl show vtp status fr die beiden Switches in Abbildung 1.11. Die Abbildung nennt die KonWichtig!

86

CCNA ICND2-Prfungshandbuch

figurationseinstellungen der beiden Switches vor dem Hinzufgen der VTP-Konfiguration aus Listing 1.5. Beachten Sie insbesondere, dass beide Switches die VTP-Default-Konfigurationseinstellungen verwenden.
VLANs: VTP-Modus: VTP-Domne: VTP-Passwort: VTP-Revision: IP-Adresse: 1, 2, 3,1002-1005 Server <null> <null> 5 192.168.1.105

SW1
Gi0/1

Trunk

Gi0/2

SW2

VLANs: VTP-Modus: VTP-Domne: VTP-Passwort: VTP-Revision: IP-Adresse:

1,1002-1005 Server <null> <null> 1 192.168.1.106

Abbildung 1.11: Switch-Konfiguration vor Ausfhrung von Listing 1.5

Listing 1.5 zeigt die folgende Konfiguration auf den Switches SW1 und SW2 sowie die Ergebnisse: SW1: Wird als Server mit dem VTP-Domnennamen Freds-domain, dem VTP-Passwort Freds-password und aktiviertem VTP-Pruning konfiguriert. SW2: Wird als Client mit dem VTP-Domnennamen Freds-domain und dem VTP-Passwort Freds-password konfiguriert.
Listing 1.5: Einfache VTP-Client- und -Serverkonfiguration
! Das IOS generiert mindestens eine Informationsmeldung nach jedem ! nachfolgend aufgefhrten VTP-Befehl. Die vom Autor hinzugefgten ! Kommentare beginnen jeweils mit einem Ausrufezeichen. SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#vtp mode server Setting device to VTP SERVER mode SW1(config)#vtp domain Freds-domain Changing VTP domain name from NULL to Freds-domain SW1(config)#vtp password Freds-password Setting device VLAN database password to Freds-password SW1(config)#vtp pruning Pruning switched on SW1(config)#^Z

Kapitel 1 VLANs
Listing 1.5: Einfache VTP-Client- und -Serverkonfiguration (Forts.)

87

! Wechsel zu Switch SW2 SW2#configure terminal 000 Enter configuration commands, one per line. End with CNTL/Z. SW2(config)#vtp mode client Setting device to VTP CLIENT mode. SW2(config)#vtp domain Freds-domain Domain name already set to Freds-domain. SW2(config)#vtp password Freds-password Setting device VLAN database password to Freds-password SW2(config)#^Z ! Die nachfolgende Ausgabe zeigt die Konfigurationsrevisionsnummer 5, ! mit 7 vorhandenen VLANs (1 bis 3, 1002 bis 1005) wie von SW1 erlernt. SW2#show vtp status VTP Version : 2 Configuration Revision : 5 Maximum VLANs supported locally : 255 Number of existing VLANs : 7 VTP Operating Mode : Client VTP Domain Name : Freds-domain VTP Pruning Mode : Enabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x22 0x07 0xF2 0x3A 0xF1 0x28 0xA0 0x5D Configuration last modified by 192.168.1.105 00000000000000000000000000000000000000000000 at 3-1-93 00:28:35 ! Der nchste Befehl listet die bekannten VLANs einschlielich der von SW1 ! erlernten VLANs 2 und 3 auf. SW2#show vlan brief VLAN Name Status Ports ---- --------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, 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 Gi0/1 2 Freds-vlan active 3 VLAN0003 active 1002 fddi-default act/unsup 1003 token-ring-default act/unsup 1004 fddinet-default act/unsup 1005 trnet-default act/unsup

88

CCNA ICND2-Prfungshandbuch

Listing 1.5: Einfache VTP-Client- und -Serverkonfiguration (Forts.)


! Wechsel zu Switch SW1 ! Zurck auf SW1 zeigt die nachfolgende Ausgabe dieselbe Revisionsnummer ! wie SW1, d. h. die beiden Switches haben ihre VLAN-Datenbanken ! synchronisiert. SW1#show vtp status 000 VTP Version : 2 Configuration Revision : 5 Maximum VLANs supported locally : 255 Number of existing VLANs : 7 VTP Operating Mode : Server VTP Domain Name : Freds-domain VTP Pruning Mode : Enabled VTP V2 Mode : Disabled VTP Traps Generation : Disabled MD5 digest : 0x10 0xA0 0x57 0x3A 0xCF 0x10 0xB7 0x96 Configuration last modified by 192.168.1.105 at 3-1-93 00:28:35 Local updater ID is 192.168.1.105 on interface Vl1 00000000000000000000000000000000000000000000000000 (lowest numbered VLAN interface found) SW1#show vtp password VTP Password: Freds-password

Dieses Listing ist relativ lang, die eigentliche Konfiguration hingegen ist recht unkompliziert. Beide Switches werden mit dem VTP-Modus (Server bzw. Client), demselben Domnennamen und demselben Passwort konfiguriert. Die Konfiguration des Trunkings hat bereits zuvor stattgefunden. Die Konfiguration fhrt dazu, dass SW2 (Client) seine VLAN-Datenbank durch SW1 (Server) synchronisiert. Cisco IOS-Switches im VTP-Server- oder -Client-Modus speichern die vtpKonfigurationsbefehle sowie einige weitere Konfigurationsbefehle in der Datei vlan.dat im Flashspeicher, nicht aber in der Datei running-config. Stattdessen werden zur Verifizierung dieser Konfigurationsbefehle und ihrer Einstellungen die Befehle show vtp status und show vlan verwendet. Tabelle 1.7 listet die VLAN-spezifischen Konfigurationsbefehle, die Position, an denen ein VTP-Server oder -Client seine Befehle speichert, sowie Angaben dazu auf, wie man die Einstellungen durch diese Befehle anzeigen kann.
Tabelle 1.7: Von VTP-Clients und -Servern verwendete Speicherorte fr VLANspezifische Konfigurationsangaben
Konfigurationsbefehl
vtp domain vtp mode

Wichtig!

Speicherposition vlan.dat vlan.dat

Anzeigebefehl
show vtp status show vtp status

Kapitel 1 VLANs

89

Tabelle 1.7: Von VTP-Clients und -Servern verwendete Speicherorte fr VLANspezifische Konfigurationsangaben (Forts.)
Konfigurationsbefehl
vtp password vtp pruning vlan vlan-id name vlan-name switchport access vlan vlan-id switchport voice vlan vlan-id

Speicherposition vlan.dat vlan.dat vlan.dat vlan.dat running-config running-config

Anzeigebefehl
show vtp password show vtp status show vlan [brief] show vlan [brief] show running-config, show interfaces switchport show running-config, show interfaces switchport

Eine Analyse von VTP und VLANs auf Cisco-Switches ist auf zwei wichtige Befehle angewiesen: show vtp status und show vlan. Beachten Sie zunchst einmal, dass, wenn die Domne synchronisiert wird, der Befehl show vtp status auf allen Switches dieselbe Konfigurationsrevisionsnummer ausgeben sollte. Auerdem sollte der Befehl show vlan jeweils dieselben VLANs und VLANNamen auflisten. So beenden etwa beide Switches SW1 und SW2 das Listing 1.5 mit der Revisionsnummer 5 und kennen die sieben VLANs 13 und 10021005. Beide Instanzen des Befehls show vtp status in Listing 1.5 fhren die IP-Adresse des letzten Switchs auf, der die VLAN-Datenbank modifiziert (nmlich SW1, also 192.168.1.105). Auf diese Weise ist es einfacher, zu ermitteln, welcher Switch die VLAN-Konfiguration zuletzt gendert hat. Nur bei VTP-Servern endet der Befehl show vtp status mit einer Zeile, die die IP-Adresse des betreffenden Switchs ausgibt, der sich bei der Bekanntgabe von VTP-Updates selbst identifiziert; auch dies erleichtert die Beantwortung der Frage, welcher Switch die VLAN-Konfiguration zuletzt gendert hat. Beachten Sie, dass das VTP-Passwort nur mit dem Befehl show vtp password angezeigt werden kann. Der Befehl show vtp status hingegen stellt nur einen MD5-Digest des Passwortes dar.

ANMERKUNG
Cisco-Switches senden VTP- und CDP-Nachrichten (Cisco Discovery Protocol) auf Trunks in VLAN 1.

90

CCNA ICND2-Prfungshandbuch

1.5.2

Vorsichtsmanahmen bei einer Vernderung der VTP-Default-Konfiguration

Das Standardverhalten von VTP birgt gewisse Risiken bei der Erstkonfiguration von VTP. Warum dies so ist, knnen Sie der folgenden Auflistung entnehmen: 1. Die VTP-Default-Konfiguration auf Cisco-Switches ist der VTP-ServerModus mit einem Null-Domnennamen. 2. Wenn alle Voreinstellungen beibehalten werden, sendet der Switch keine VTP-Updates (auch nicht ber Trunks), kann aber weil er sich im Server-Modus befindet mit VLANs konfiguriert werden. 3. Nach der Konfiguration eines Domnennamens beginnt der Switch sofort mit dem Versand von VTP-Updates ber alle Trunks. 4. Wenn ein Switch, der noch den (vorgegebenen) Null-Domnennamen aufweist, ein VTP-Update empfngt, welches per definitionem einen Domnennamen auflistet, und auf dem sendenden Switch kein Passwort verwendet wurde, verwendet der empfangende Switch ab sofort diesen VTPDomnennamen. 5. Wenn dies geschieht, bewirkt der Switch mit der hheren VLAN-Datenbankrevisionsnummer, dass der Switch mit der niedrigeren Revisionsnummer seine VLAN-Datenbank berschreibt. In Listing 1.5 finden diese fnf Ereignisse in der angegebenen Reihenfolge statt. Zunchst wird das Trunking zwischen den beiden Switches aktiviert dies jedoch mit den VTP-Default-Einstellungen (1 und 2). Sobald SW1 seinen VTP-Domnennamen konfiguriert, sendet er VTP-Nachrichten ber den Trunk an SW3 (3). SW2 reagiert, indem er fortan den VTP-Domnennamen verwendet, der im empfangenen VTP-Update enthalten ist (in diesem Fall Freds-domain). Wenn dann in Listing 1.5 der Befehl vtp domain Fredsdomain auf SW2 ausgefhrt wird, verwendet dieser Switch bereits den erlernten Domnennamen Freds-domain, weswegen Cisco IOS auf SW2 die Antwort Domain name already set to Freds-domain absetzt (4). Schlielich gleicht, weil er die niedrigere VTP-Revisionsnummer hat, SW2 seine VLAN-Datenbank mit der von SW1 ab (5). Der Vorgang luft in Listing 1.5 exakt so ab wie vorgesehen. Allerdings ist es mglich, dass ein Techniker beim selben Vorgang unbeabsichtigt den VTP-Domnennamen eines Switchs konfiguriert und ein geswitchtes LAN so zum Absturz bringt. Stellen wir uns beispielsweise vor, SW2 htte VLAN 4 konfiguriert und diesem VLAN verschiedene Schnittstellen zugewiesen, whrend SW1 ber keine Definition fr VLAN 4 verfgt. Wenn

Kapitel 1 VLANs

91

man den Gedanken nun weiterspinnt, berschreibt SW2 in dem Moment, in dem er seine VLAN-Datenbank zu SW1 synchronisiert, die alte Datenbank, woraufhin die Definition von VLAN 4 verlorengeht. An dieser Stelle kann SW2 nun keine Frames mehr in VLAN 4 weiterleiten. Schlimmstenfalls melden sich nun alle Benutzer von VLAN 4 beim Helpdesk. Derselbe Vorgang knnte auch verwendet werden, um via VTP einen DoSAngriff (Denial of Service, Dienstabweisung) auszufhren. Wurden die VTPVoreinstellungen nicht gendert, so kann jeder Angreifer, dem es gelingt, einen Trunk zwischen einem attackierenden Switch und dem vorhandenen legitimen Switch herzustellen, die vorhandenen Switches dazu bringen, sich zur VLAN-Datenbank des angreifenden Switchs zu synchronisieren, auf der unter Umstnden gar keine VLANs konfiguriert sind. Insofern sollten Sie in echten Netzwerken diesen als Switch im transparenten VTP-Modus konfigurieren, wenn Sie bereits bei der Installation eines Switchs wissen, dass Sie VTP nicht verwenden werden. (Wir werden im nchsten Abschnitt darauf eingehen.) Auf diese Weise wirkt sich die Konfiguration eines VTP-Domnennamens auf diesem neuen Switch nicht auf die vorhandenen Switches aus, und die Konfiguration eines Domnennamens auf einem anderen Switch beeintrchtigt diesen neuen Switch ebenso wenig.

ANMERKUNG
Der Abschnitt Behebung von VTP-Problemen erlutert, wie man erkennt, ob VTP eventuell Probleme wie das hier beschriebene verursacht hat.

1.5.3

Transparenten VTP-Modus konfigurieren

Um die Verwendung von VTP zu umgehen, mssen Sie den transparenten Modus konfigurieren. Im transparenten Modus aktualisiert ein Switch seine VLAN-Datenbank keinesfalls auf der Basis empfangener VTP-Nachrichten. Auch andere Switches aktualisieren ihre Datenbanken nicht basierend auf der VLAN-Datenbank des im transparenten Modus betriebenen Switchs. Die einzige VTP-Aktion, die von diesem Switch durchgefhrt wird, besteht in der Weiterleitung von ber einen Trunk empfangenen VTP-Nachrichten auf alle anderen Trunks; dies ermglicht anderen VTP-Clients und -Servern den korrekten Betrieb. Die Konfiguration des transparenten VTP-Modus ist ziemlich einfach: Setzen Sie im globalen Konfigurationsmodus einfach den Befehl vtp mode transparent ab. Sie bentigen hierfr weder einen Domnennamen noch ein Passwort.

92

CCNA ICND2-Prfungshandbuch

1.5.4

Behebung von VTP-Problemen

VTP kann auf Campus-LANs, die auf der Grundlage von Cisco-Switches aufgebaut sind, enorme Auswirkungen haben und zwar positive wie auch negative. In diesem Abschnitt untersuchen wir drei Aspekte der Behebung VTP-spezifischer Probleme. Zunchst wird die Fehlersuche und Problembehebung demonstriert, wenn VTP offensichtlich keine VLAN-Konfigurationsdaten (Ergnzungen, Lschungen und nderungen) im Netzwerk verteilt. Danach untersuchen wir eine allgemeine Klasse von Problemen, die auftreten knnen, wenn ein Trunk aktiv wird und dadurch an benachbarten Switches der Versand von VTP-Updates ausgelst wird, die die VLANDatenbank auf dem Switch berschreiben. Am Ende des Abschnitts schlielich finden Sie Empfehlungen zur Vermeidung von VTP-Problemen.

Ermitteln, warum VTP scheinbar nicht funktioniert


Der erste Schritt bei der Behebung von VTP-Problemen sollte zunchst einmal darin bestehen, zu ermitteln, ob berhaupt ein Problem vorliegt. Bei Switches, die in derselben Domne VTP verwenden sollen, kann ein Problem zuallererst daran erkannt werden, dass zwei benachbarte Switches unterschiedliche VLAN-Datenbanken aufweisen: Sie kennen unterschiedliche VLAN-IDs mit unterschiedlichen Namen und mit einer jeweils anderen Konfigurationsrevisionsnummer. Wenn Sie zwei benachbarte Switches mit nicht bereinstimmenden VLAN-Datenbanken erkannt haben, besteht der nchste Schritt darin, die Konfiguration und den Trunking-Betriebsmodus (nicht den Administrativ-Modus) zu kontrollieren und gegebenenfalls vorhandene Probleme zu beheben. Die folgende Liste gibt die Schritte im Einzelnen an:
Wichtig!

1. berprfen Sie die Switch-Namen, die Topologie (einschlielich der Frage, welche Switches an welche Schnittstellen angeschlossen sind) und die VTP-Modi. 2. Ermitteln Sie mit dem Befehl show vlan jeweils zwei benachbarte Switches, die entweder VTP-Clients oder -Server sein sollten und deren VLANDatenbanken sich unterscheiden. 3. berprfen Sie Folgendes bei jedem Switch-Paar mit unterschiedlichen Datenbanken: a) Zwischen den beiden Switches sollte mindestens ein funktionsfhiger Trunk vorhanden sein. Dies verifizieren Sie mit den Befehlen show interfaces trunk, show interfaces switchport oder show cdp neighbors.

Kapitel 1 VLANs

93

b) Die Switches mssen denselben VTP-Domnennamen aufweisen. Hierzu setzen Sie den Befehl show vtp status ein. Die Gro-/Kleinschreibung wird beachtet. c) Sofern konfiguriert, mssen die Switches dasselbe VTP-Passwort aufweisen. Hierzu setzen Sie den Befehl show vtp password ein. Die Gro-/ Kleinschreibung wird beachtet. d) Zwar sollte das VTP-Pruning innerhalb einer Domne auf allen Servern entweder aktiviert oder deaktiviert sein, doch das Vorhandensein zweier Server mit gegenstzlichen Pruning-Einstellungen verhindert die Synchronisierung nicht. 4. Fr jedes in Schritt 3 ermittelte Switch-Paar beheben Sie das Problem, indem Sie entweder die Ursache fr das Trunking-Problem ermitteln und beseitigen oder einen Switch so umkonfigurieren, dass Domnenname und/oder Passwort bereinstimmen.

ANMERKUNG
Bei echten Campus-LANs sollten Sie nicht nur die Elemente dieser Liste berprfen, sondern auch das vorgesehene VTP-Design. Der Vorgang der Problembehebung umfasst zwar mehrere Schritte, zeigt jedoch, dass sich Schwierigkeiten bereits mit dem Wissen angehen lassen, das Sie im bisherigen Verlauf des Kapitels erlernt haben. Im Wesentlichen geht es darum, dass, wenn die VLAN-Datenbanken sich unterscheiden und die Switches entweder VTP-Server oder VTP-Clients sind, ein Problem vorhanden ist, dessen Ursache letztendlich in aller Regel eine VTP-Fehlkonfiguration ist. Bei der Prfung allerdings kann es sein, dass Sie gentigt sind, die Antwort aus der Ausgabe eines show-Befehls abzuleiten. Nehmen wir an, in einem Problemszenario sind drei Switches SW1, SW2 und SW3 aneinander angeschlossen. In der Prfung knnten Sie aufgefordert werden, auf der Basis der Ausgabe von show-Befehlen wie der in Listing 1.6 gezeigten gegebenenfalls vorhandene VTP-Probleme zu ermitteln.

ANMERKUNG
Sie sollten das Listing zu bungszwecken unbedingt studieren und die oben aufgefhrten Schritte zur Problembehebung durchfhren, bevor Sie die Erluterungen lesen, die auf das Listing folgen.

94

CCNA ICND2-Prfungshandbuch

Listing 1.6: Behebung von VTP-Problemen (Beispiel)


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 Device ID SW2 SW3 SW1#show vlan Local Intrfce Gig 0/1 Gig 0/2 brief Holdtme 163 173 Capability S I S I Platform Port ID WS-C2960-2Gig 0/2 WS-C3550-2Gig 0/1

VLAN Name Status Ports ---- --------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/13, Fa0/14 Fa0/15, Fa0/16, Fa0/17, Fa0/18 Fa0/19, Fa0/20, Fa0/21, Fa0/22 Fa0/23, Fa0/24, Gi0/2 3 VLAN0003 active Fa0/11 4 VLAN0004 active 5 VLAN0005 active 49 VLAN0049 active 50 VLAN0050 active 1002 fddi-default act/unsup 1003 trcrf-default act/unsup 1004 fddinet-default act/unsup 1005 trbrf-default act/unsup SW1#show interfaces trunk Port Gi0/1 Port Gi0/1 Port Gi0/1 Mode desirable Encapsulation Status 802.1q trunking Native vlan 1

Vlans allowed on trunk 1-4094 Vlans allowed and active in management domain 1,3-5,49-50

Port Vlans in spanning tree forwarding state and not pruned Gi0/1 3-5,49-50 SW1#show vtp status VTP Version : 2 Configuration Revision : 131 Maximum VLANs supported locally : 255 Number of existing VLANs : 10

Kapitel 1 VLANs
Listing 1.6: Behebung von VTP-Problemen (Beispiel) (Forts.)
VTP Operating Mode : Client VTP Domain Name : Larry VTP Pruning Mode : Disabled VTP V2 Mode : Enabled VTP Traps Generation : Disabled MD5 digest : 0x1D 0x27 0xA9 0xF9 0x46 0xDF 0x66 0xCF Configuration last modified by 1.1.1.3 at 3-1-93 00:33:38 ! Wechsel zu Switch 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 Device ID SW1 SW3 SW2#show vlan Local Intrfce Gig 0/2 Gig 0/1 brief Holdtme 175 155 Capability S I S I

95

Platform Port ID WS-C2960-2Gig 0/1 WS-C3550-2Gig 0/2

VLAN Name Status Ports ---- --------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/13, Fa0/14, Fa0/15, Fa0/16 Fa0/17, Fa0/18, Fa0/19, Fa0/20 Fa0/21, Fa0/22, Fa0/23, Fa0/24 3 VLAN0003 active 1002 fddi-default act/unsup 1003 trcrf-default act/unsup 1004 fddinet-default act/unsup 1005 trbrf-default act/unsup SW2#show vtp status VTP Version : 2 Configuration Revision : 0 Maximum VLANs supported locally : 255 Number of existing VLANs : 6 VTP Operating Mode : Server VTP Domain Name : larry VTP Pruning Mode : Disabled VTP V2 Mode : Enabled VTP Traps Generation : Disabled MD5 digest : 0x8C 0x75 0xC5 0xDE 0xE9 0x7C 0x2D 0x8B Configuration last modified by 1.1.1.2 at 0-0-00 00:00:00 Local updater ID is 1.1.1.2 on interface Vl1 (lowest numbered VLAN interface found)

96

CCNA ICND2-Prfungshandbuch

Listing 1.6: Behebung von VTP-Problemen (Beispiel) (Forts.)


! Wechsel zu Switch SW3 SW3#show vlan brief VLAN Name Status Ports ---- --------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/14, Fa0/15, Fa0/16, Fa0/17 Fa0/18, Fa0/19, Fa0/20, Fa0/21 Fa0/22, Fa0/23, Fa0/24, Gi0/1 3 VLAN0003 active Fa0/13 4 VLAN0004 active 5 VLAN0005 active 20 VLAN20 active 1002 fddi-default act/unsup 1003 trcrf-default act/unsup 1004 fddinet-default act/unsup 1005 trbrf-default act/unsup SW3#show interfaces trunk Port Gi0/2 Port Gi0/2 Port Gi0/2 Mode desirable Encapsulation Status n-802.1q trunking Native vlan 1

Vlans allowed on trunk 1-4094 Vlans allowed and active in management domain 1,3-5,20

Port Vlans in spanning tree forwarding state and not pruned Gi0/2 1,3-5,20 SW3#show vtp status VTP Version : 2 Configuration Revision : 134 Maximum VLANs supported locally : 1005 Number of existing VLANs : 9 VTP Operating Mode : Server VTP Domain Name : Larry VTP Pruning Mode : Disabled VTP V2 Mode : Enabled VTP Traps Generation : Disabled MD5 digest : 0x76 0x1E 0x06 0x1E 0x1C 0x46 0x59 0x75 Configuration last modified by 1.1.1.3 at 3-1-93 01:07:29 Local updater ID is 1.1.1.3 on interface Vl1 (lowest numbered VLAN interface found)

Kapitel 1 VLANs

97

In Schritt 1 bieten die Befehle show cdp neighbors und show interfaces trunk genug Informationen, um die Topologie zu kontrollieren und anzuzeigen, welche Verbindungen als Trunks fungieren. Der Befehl show interfaces trunk listet nur Schnittstellen auf, die sich im Trunk-Modus befinden und betriebsbereit sind. Alternativ zeigt auch der Befehl show interfaces switchport den Betriebsmodus (Trunk- oder Access-Modus) an. Abbildung 1.12 zeigt die Netzwerktopologie. Beachten Sie hierbei auch, dass die Verbindung zwischen den Switches SW1 und SW3 gegenwrtig kein Trunking verwendet.
Client
Gi0/1 Gi0/2

Server SW2

SW1 SW1
Gi0/2

Gi0/1

Gi0/1

Gi0/2

SW3 Server

Abbildung 1.12: Geswitchte Netzwerktopologie aus Listing 1.6

Fr Schritt 2 zeigt ein schneller Blick auf die Ausgabe des Befehls show vlan brief der einzelnen Switches, dass alle drei Switches ber unterschiedliche VLAN-Datenbanken verfgen. So kennen zwar alle drei Switches VLAN 3, aber SW1 ist der einzige Switch, der VLAN 50 kennt, und SW3 der einzige, der von der Existenz von VLAN 20 wei. Da alle drei Paare benachbarter Switches unterschiedliche VLAN-Datenbanken aufweisen, mssen wir die Paare gem Schritt 3 separat untersuchen. Wenn wir mit SW1 und SW2 beginnen, enthllt ein Blick auf die Ausgabe von show vtp status auf beiden Switches das Problem: SW1 verwendet den Domnennamen Larry, whrend SW2 larry benutzt. Zur Erinnerung: Die Gro-/Kleinschreibung wird beachtet. Ebenso gibt es Schwierigkeiten zwischen SW3 und SW2 aufgrund des nicht identischen Domnennamens. Weil SW2 der einzige Switch ist, dessen Domnenname kleingeschrieben wird, bestnde eine Lsung darin, SW2 so umzukonfigurieren, dass der Domnenname Larry verwendet wird. Fahren wir nun mit Schritt 3 fr SW1 und SW3 fort, so stellen wir fest, dass beide Switches zwar denselben Domnennamen aufweisen (Schritt 3b), dass sie aber nicht durch einen Trunk verbunden sind (Schritt 3a). CDP besttigt uns, dass die Schnittstelle Gi0/2 von SW1 zwar an SW3 angeschlossen ist,

98

CCNA ICND2-Prfungshandbuch

aber der Befehl show interfaces trunk auf SW1 listet uns diese Schnittstelle nicht auf. Infolgedessen kann keiner der beiden Switches VTP-Nachrichten an den jeweils anderen senden. Die Hauptursache dieses Problems besteht wahrscheinlich in einer versehentlich durchgefhrten Fehlkonfiguration mit dem Schnittstellenbefehl switchport mode. Zwar gab es in diesem Beispiel keine Probleme aufgrund unpassender VTPPasswrter, doch ist es wichtig zu wissen, wie man die Passwrter berprft. Zunchst kann das Passwort auf jedem Switch mit dem Befehl show vtp password angezeigt werden. Zudem listet der Befehl show vtp status einen MD5-Hash auf, der aus dem VTP-Domnennamen und dem VTP-Passwort gebildet wird. Wenn also zwei Switches denselben Domnennamen und dasselbe Passwort (jeweils unter Bercksichtigung der Gro-/Kleinschreibung) aufweisen, so muss der in der Befehlsausgabe von show vtp status gezeigte MD5-Hashwert identisch sein. Wenn jedoch fr zwei Switches unterschiedliche MD5-Hashwerte ausgegeben werden, mssen Sie die Domnennamen untersuchen. Sind die Domnennamen identisch, dann mssen die Passwrter unterschiedlich sein, da die MD5-Hashes ansonsten gleich wren. Bevor wir nun mit dem nchsten Thema fortfahren, mchte ich noch eine kurze Anmerkung zu VTP und dazu einflieen lassen, wie es unter Umstnden die Funktion von Switches beeintrchtigen kann. Wenn Sie sich die Befehlsausgabe von show vtp status in Listing 1.6 noch einmal ansehen, werden Sie die Angaben VTP Version und V2 Mode: Enabled bemerken. Die erstgenannte Zeile listet die hchste VTP-Version auf, die von der Software dieses Switchs untersttzt wird, die zweite gibt an, was der Switch derzeit verwendet. Wenn an einem Switch der Befehl fr die VTP-Version 2 konfiguriert ist (wodurch die Default-Version 1 auer Kraft gesetzt wird), verwendet er vtp version 2 aber nur dann, wenn die anderen Switches in der Domne Version 2 ebenfalls untersttzen. Insofern hat eine fehlende bereinstimmung bei der konfigurierten VTP-Version zur Folge, dass die Switches zwar funktionieren, aber die VTP-Version 1 verwenden; in diesem Fall erschiene in der Zeile VTP V2 Mode das Wort disabled.

Probleme beim Anschlieen neuer Switches und beim Aktivieren von Trunks
VTP kann monatelang einwandfrei laufen, aber eines Tages luft beim Helpdesk unvermittelt eine Vielzahl Anrufe von Benutzern auf, die das Netzwerk nicht mehr verwenden knnen. Nach eingehender Untersuchung kommen Sie zu dem Schluss, dass praktisch jedes VLAN auf dem Campus gelscht wurde. Die Switches weisen jedoch noch zahlreiche Schnittstellen mit switchport access vlan-Befehlen auf, die weiterhin die nun gelschten VLANs

Kapitel 1 VLANs

99

referenzieren. Keines der Gerte in diesen gelschten VLANs funktioniert, da Cisco-Switches keine Frames an nicht vorhandene VLANs weiterleiten. Dieses Szenario ist durchaus realistisch: So etwas kommt vor vor allem, wenn ein neuer Switch an ein vorhandenes Netzwerk angeschlossen wird. Unabhngig davon, ob das Problem infolge eines Versehens oder eines DoSAngriffs auftritt, besteht die Hauptursache darin, dass ein neuer VLANTrunk (ISL oder 802.1Q) zwischen zwei Switches aktiv wird, die entweder VTP-Server oder VTP-Clients sind. Die Switches senden dann einander VTP-Updates zu. Wenn ein Switch ein VTP-Advertisement empfngt, das denselben Domnennamen enthlt und mit demselben VTP-Passwort generiert wurde, berschreibt der eine oder der andere Switch im Zuge des Synchronisierungsvorgangs seine VLAN-Datenbank. In jedem Fall synchronisiert der Switch mit der niedrigeren Revisionsnummer seine VLANDatenbank zu der des benachbarten Switchs (denn dieser hat ja eine hhere Revisionsnummer). Man kann den Vorgang auch etwas konventioneller formulieren: 1. Vergewissern Sie sich, dass auf der neuen Verbindung das Trunking aktiviert ist (vgl. Tabelle 1.5). 2. Vergewissern Sie sich, dass die beiden Switches denselben VTP-Domnennamen und dasselbe VTP-Passwort verwenden. Die Gro-/Kleinschreibung wird beachtet. 3. Wenn die Schritte 1 und 2 erfllt sind, funktioniert VTP. In diesem Fall aktualisiert der Switch mit der niedrigeren Revisionsnummer seine VLAN-Datenbank mit den Daten des anderen Switchs. Listing 1.6 und Abbildung 1.12 zeigen, dass das Trunking zwischen SW1 und SW3 nicht funktioniert. Wenn fr diese Verbindung das Trunking konfiguriert worden wre, so htten SW1 und SW3 einander VTP-Nachrichten zugeschickt und dabei denselben Domnennamen und dasselbe Passwort verwendet. Insofern wrde der eine Switch seine VLAN-Datenbank ndern, damit sie mit der des anderen bereinstimmt. Aus Listing 1.6 geht hervor, dass SW1 die Revisionsnummer 131 und SW3 die Revisionsnummer 134 aufweist; SW1 berschreibt also seine Datenbank, um sie an SW3 anzupassen: Die VLANs 49 und 50 werden gelscht. Listing 1.7 stellt die Fortsetzung von Listing 1.6 dar. Es zeigt, wie der Trunk zwischen SW1 und SW3 aktiv wird. Die VTP-Synchronisierung wird ermglich, und es kommt zu den nderungen an der VLAN-Datenbank von SW1.
Wichtig!

100

CCNA ICND2-Prfungshandbuch

Listing 1.7: Behebung von VTP-Problemen (Beispiel)


SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#interface gi0/2 SW1(config-if)#switchport mode dynamic desirable SW1(config-if)#^Z SW1# 01:43:46: %SYS-5-CONFIG_I: Configured from console by console 01:43:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to down SW1#01:43:49: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/2, changed state to up SW1#show vlan brief VLAN Name Status Ports ---- --------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/13, Fa0/14 Fa0/15, Fa0/16, Fa0/17, Fa0/18 Fa0/19, Fa0/20, Fa0/21, Fa0/22 Fa0/23, Fa0/24, Gi0/1 3 VLAN0003 active Fa0/11 4 VLAN0004 active 5 VLAN0005 active 20 VLAN20 active 1002 fddi-default act/unsup 1003 trcrf-default act/unsup 1004 fddinet-default act/unsup 1005 trbrf-default act/unsup

In der Praxis gibt es mehrere Mglichkeiten, die Wahrscheinlichkeit derartiger Probleme zu verringern, wenn Sie einen neuen Switch in einer vorhandenen VTP-Domne installieren. Zunchst einmal mssen Sie, bevor Sie einen neuen Switch an eine vorhandene Domne anschlieen, die Revisionsnummer des neuen Switchs auf 0 zurcksetzen. Hierzu knnen Sie eine der folgenden Methoden einsetzen: Sie konfigurieren am neuen Switch zunchst den transparenten VTPModus und whlen erst danach den Client- oder den Server-Modus aus. Sie lschen die Datei vlan.dat im Flashspeicher des neuen Switchs und laden den Switch dann neu. Diese Datei enthlt die VLAN-Datenbank des Switchs einschlielich der Revisionsnummer.

Kapitel 1 VLANs

101

Problemvermeidung durch Beachten von Empfehlungen


Neben dem Vorschlag, die Revisionsnummer der VLAN-Datenbank vor der Installation eines neuen Switchs zurckzusetzen, gibt es noch einige weitere empfehlenswerte VTP-Richtlinien sogenannte bewhrte Praktiken , mit denen sich VTP-spezifische Fallstricke vermeiden lassen. Hierbei handelt es sich um die folgenden: Sofern Sie nicht beabsichtigen, VTP zu verwenden, so konfigurieren Sie auf allen Switches den transparenten Modus. Falls Sie den VTP-Server- oder -Client-Modus verwenden, so vergeben Sie stets ein VTP-Passwort. Deaktivieren Sie mit den Befehlen switchport mode access und switchport nonegotiate das Trunking auf allen Schnittstellen, die nicht bekanntermaen Trunks sind. Hierdurch verhindern Sie VTP-basierte Angriffe, die durch die dynamische Erstellung von Trunks mglich werden. Wenn Sie die Verhandlung des Trunkings fr die meisten Ports unterbinden, kann ein potenzieller Angreifer keinesfalls ein VTP-Update von einem Ihrer Switches erhalten. Und wenn das VTP-Passwort festgelegt ist, msste ein Angreifer dieses Passwort kennen, um Schaden anzurichten und zwar auch dann, wenn er das Trunking auf einem vorhandenen Switch zum Laufen bekommt. Durch Verwendung des transparenten Modus knnen Sie schlielich auch Probleme umgehen, die wir weiter oben im Abschnitt Vorsichtsmanahmen bei Vernderung der VTP-Default-Konfiguration beschrieben haben.
Wichtig!

102

CCNA ICND2-Prfungshandbuch

1.6
1.6.1
Wichtig!

Prfungsvorbereitung
Wiederholung

Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind in der Randspalte mit dem entsprechenden Symbol gekennzeichnet. Tabelle 1.8 listet diese Themen sowie die Seitennummern auf, auf denen die Themen zu finden sind.
Tabelle 1.8: Schlsselthemen in Kapitel 1
Element Liste Beschreibung Grnde fr die Verwendung von VLANs Seite 53 54 56 58 61 63 67 70 69 75 79 80 83 84 85 88 92 99 101

Abbildung 1.2 Darstellung des VLAN-Trunkings Abbildung 1.4 802.1Q-Header Tabelle 1.2 Vergleich zwischen 802.1Q und ISL

Abbildung 1.6 VTP-Synchronisierungsvorgang Liste Tabelle 1.3 Liste Liste Tabelle 1.4 Tabelle 1.5 Liste Tabelle 1.6 Liste Liste Tabelle 1.7 Liste Liste Liste Voraussetzungen fr die Funktionsfhigkeit von VTP zwischen zwei Switches Zusammenfassung der VTP-Eigenschaften Checkliste fr die Konfiguration von VLANs und ihre Zuordnung zu Schnittstellen VTP- und VLAN-Default-Konfiguration Optionen des Befehls switchport mode Trunking-Status basierend auf der Konfiguration des Befehls switchport mode Ursachen fr das Nichtweiterleiten von Daten eines VLAN durch einen Trunk Konfiguration von Sprach- und Daten-VLANs sowie Terminologie Wie man unbenutzte Switch-Ports schtzt Checkliste fr die VTP-Konfiguration Befehle fr die VTP- und VLAN-Konfiguration sowie zugehrige Speicherpositionen Wenn VTP nicht wie gewnscht funktioniert Anschlieen eines neuen Switchs an ein Netzwerk Vermeidung von VTP-spezifischen Problemen

Kapitel 1 VLANs

103

1.6.2

Vervollstndigen Sie die Listen und Tabellen

Drucken Sie aus Anhang J, Tabellen zur bung (auf der CD vorhanden), den Abschnitt zu diesem Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls auf der CD enthaltene Anhang K, Lsungen zu den bungen, enthlt die vollstndigen Tabellen und Listen, mit denen Sie Ihre Lsungen berprfen knnen.

1.6.3

Wichtige Definitionen

Definieren Sie die folgenden Schlsselbegriffe aus diesem Kapitel und berprfen Sie Ihre Antworten anhand des Glossars: 802.1Q, ISL, Trunk, Trunking-Administrativ-Modus, TrunkingBetriebsmodus, VLAN, VLAN-Konfigurationsdatenbank, vlan.dat, VTP, VTP-Client-Modus, VTP-Pruning, VTP-Server-Modus, transparenter VTP-Modus

1.6.4

Befehlsreferenz

Wir fhren an dieser Stelle eine Referenz fr die in diesem Kapitel behandelten Befehle aus dem Konfigurations- und dem EXEC-Modus an. Eigentlich sollten Sie die Befehle beim Studieren des Kapitels und beim Durchfhren der Aktivitten in diesem Abschnitt zur Prfungsvorbereitung quasi als Nebeneffekt bereits verinnerlicht haben. Um zu berprfen, wie gut Sie diese Befehle schon kennen, knnen Sie die linke Spalte der Tabelle mit einem Blatt Papier abdecken. Lesen Sie dann die Beschreibungen in der rechten Spalte und kontrollieren Sie, ob Sie den betreffenden Befehl kennen.
Tabelle 1.9: Referenz der Konfigurationsbefehle aus Kapitel 1
Befehl
vlan vlan-id

Beschreibung Globaler Konfigurationsbefehl, der ein VLAN erstellt und das CLI in den VLAN-Konfigurationsmodus versetzt VLAN-Befehl zur Benennung des VLAN VLAN-Befehl, der verhindert, dass ein Switch Daten in das betreffende VLAN weiterleitet

name vlan-name shutdown

104

CCNA ICND2-Prfungshandbuch

Tabelle 1.9: Referenz der Konfigurationsbefehle aus Kapitel 1


Befehl
shutdown vlan vlan-id

Beschreibung Globaler Konfigurationsbefehl, der ein VLAN zu Administrationszwecken deaktiviert und so verhindert, dass der Switch Daten in dieses VLAN weiterleitet Globaler Konfigurationsbefehl, der den VTP-Domnennamen definiert Globaler Konfigurationsbefehl, der das VTP-Passwort definiert Globaler Konfigurationsbefehl, der den VTP-Modus definiert Globaler Konfigurationsbefehl, der den VTP-Server auffordert, alle Switches zur Verwendung des VTP-Prunings anzuweisen Schnittstellenbefehl, der den Administrativ-Modus auf der Schnittstelle konfiguriert Schnittstellenbefehl, der die Liste der zulssigen VLANs definiert Schnittstellenbefehl, der die die Schnittstelle im angegebenen VLAN statisch konfiguriert Schnittstellenbefehl, der definiert, welche Form des Trunkings verwendet wird (hierbei wird vorausgesetzt, dass das Trunking konfiguriert oder verhandelt wird) Schnittstellenbefehl, der definiert, welches VLAN fr den Versand und Empfang von Frames an und von einem Cisco-IP-Telefon verwendet wird Schnittstellenbefehl, der die Verhandlung des VLAN-Trunkings deaktiviert

vtp domain domain-name vtp password password vtp {server | client | transparent} vtp pruning

switchport mode {access | dynamic {auto | desirable} | trunk} switchport trunk allowed vlan {add | all | except | remove} vlan-list switchport access vlan vlan-id

switchport trunk encapsulation {dot1q

| isl | negotiate}

switchport voice vlan vlan-id

switchport nonnegotiate

Kapitel 1 VLANs
Tabelle 1.10: Referenz der EXEC-Befehle aus Kapitel 1
Befehl
show interfaces interface-id switchport show interfaces interface-id trunk

105

Beschreibung Listet Angaben zu den administrativen Einstellungen und dem Betriebszustand einer Schnittstelle auf. Listet Angaben zu allen funktionsfhigen Trunks (nicht aber zu anderen Schnittstellen) auf, z. B. die Liste der VLANs, die ber diesen Trunk weitergeleitet werden. Listet Angaben zum VLAN auf. Zeigt VLAN-Informationen an. Listet VPT-Konfigurations- und -Statusdaten auf. Zeigt das VTP-Passwort an.

show vlan [brief | id vlan-id | name vlan- name | summary] show vlan [vlan] show vtp status show vtp password

Dieses Kapitel behandelt die folgenden Themen


Das STP-Protokoll (Spanning Tree Protocol, IEEE 802.1d) Dieser Abschnitt erlutert die Arbeitsweise der ursprnglichen STP-Protokolle des IEEE. Rapid STP (IEEE 802.1w) Dieser Abschnitt legt den Schwerpunkt auf die Unterschiede zwischen dem frheren 802.1d-Standard (STP) und dem neueren RSTP-Standard (802.1w). STP-Konfiguration und -Verifizierung In diesem Abschnitt wird erlutert, wie man STP auf Cisco-IOS-Switches konfiguriert und den aktuellen STP-Zustand auf jedem Switch und fr jede Schnittstelle verifiziert. Behebung von STP-Problemen Dieser Abschnitt beschreibt eine Vorgehensweise, mit der sich die Port-Funktion einer STP-Schnittstelle und damit auch die Topologie des Spanning-Tree vorhersagen lsst.

Kapitel 2
Das Spanning-Tree-Protokoll
Wann immer ein LAN-Design mehrere Switches erfordert, fgen die meisten Netzwerktechniker redundante Ethernet-Segmente zwischen den Switches ein. Der Sinn dieser Manahme ist einfach: Switches knnen ausfallen und Kabel durchtrennt oder abgezogen werden, aber wenn redundante Switches und Kabel installiert sind, wird das Netzwerkdienst den meisten Benutzern weiterhin zur Verfgung stehen. Bei LANs mit redundanten Verbindungen besteht jedoch die Mglichkeit, dass Frames endlos im Netzwerk kreisen. Dieses Kreisen von Frames kann die Leistungsfhigkeit des Netzwerks beeintrchtigen. Aus diesem Grund verwenden LANs das Spanning-Tree-Protokoll (STP), welches die Nutzung redundanter LAN-Verbindungen ermglicht und gleichzeitig verhindert, dass Frames ber diese redundanten Leitungen ewig im LAN zirkulieren. In diesem Kapitel werden wir STP behandeln und auch einige Konfigurationsbefehle kennenlernen, die eine Optimierung des Verhaltens von STP ermglichen. Das Kapitel behandelt die Details zu STP und beschreibt auerdem eine neuere Variante, das RSTP-Protokoll (Rapid Spanning Tree Protocol). Am Ende dieses Kapitels wird die STP-Konfiguration auf 2960-Switches beschrieben. Auerdem finden Sie dort Vorschlge, wie Sie STP-Problemstellungen in den Prfungen angehen knnen.

2.1

berprfen Sie Ihren Wissensstand

Dieser Abschnitt gestattet es Ihnen zu ermitteln, ob Sie das gesamte Kapitel lesen mssen. Wenn Sie maximal eine der folgenden zehn Fragen zur Selbsteinschtzung nicht oder falsch beantworten, knnen Sie mit dem Abschnitt Aufgaben zur Prfungsvorbereitung fortfahren. Tabelle 2.1 listet die wichtigsten berschriften dieses Kapitels und die Nummern der Fragen auf, die sich auf die betreffenden Abschnitte beziehen. Auf diese Weise knnen Sie Ihr Wissen in den jeweiligen Bereichen selbst einschtzen. Die Antworten zu den Fragen in diesem Abschnitt finden Sie in Anhang A.

108

CCNA ICND2-Prfungshandbuch

Tabelle 2.1: Zuordnung der folgenden Fragen zu den einzelnen Themengebieten


Grundlagenthema Das Spanning-Tree-Protokoll (IEEE 802.1d) Rapid STP (IEEE 802.1w) STP-Konfiguration und -Verifizierung Behebung von STP-Problemen Fragen 1 bis 5 6 und 7 8 und 9 10

1. Welche der folgenden IEEE 802.1d-Port-Zustnde sind stabile Zustnde, die verwendet werden, wenn STP die Konvergenz abgeschlossen hat? a) Blocking b) Forwarding c) Listening d) Learning e) Discarding 2. Welche der folgenden sind flchtige IEEE 802.1d-Port-Zustnde, die nur bei laufender STP-Konvergenz verwendet werden? a) Blocking b) Forwarding c) Listening d) Learning e) Discarding 3. Welche der folgenden Bridge-IDs werden als Root ausgewhlt, sofern die Switches mit diesen Bridge-IDs sich im selben Netzwerk befinden? a) 32768:0200.1111.1111 b) 32768:0200.2222.2222 c) 200:0200.1111.1111 d) 200:0200.2222.2222 e) 40,000:0200.1111.1111

Kapitel 2 Das Spanning-Tree-Protokoll

109

4. Welcher der folgenden Faktoren bestimmt, wie oft eine Nicht-RootBridge oder ein Nicht-Root-Switch eine Hello-BPDU nach 802.1d sendet? a) Der auf diesem Switch konfigurierte Hello-Timer b) Der auf dem Root-Switch konfigurierte Hello-Timer c) Ein Standardwert von zwei Sekunden ist fest vorgegeben. d) Der Switch reagiert auf BPDUs, die vom Root-Switch empfangen wurden, durch Versand einer weiteren BPDU zwei Sekunden nach Empfang der Root-BPDU. 5. Welche STP-Eigenschaft bewirkt, dass eine Schnittstelle in den Zustand Forwarding versetzt wird, sobald sie physisch aktiv wird? a) STP b) RSTP c) Root Guard d) 802.1w e) PortFast f) EtherChannel 6. Welches ist der IEEE-Standard, der den ursprnglichen STP-Standard verbessert und die Konvergenzdauer verringert? a) STP b) RSTP c) Root Guard d) 802.1w e) PortFast f) Trunking 7. Welche der folgenden RSTP-Port-Zustnde haben denselben Namen wie ein hnlicher Port-Zustand beim traditionellen STP? a) Blocking b) Forwarding c) Listening d) Learning e) Discarding f) Disabled

110

CCNA ICND2-Prfungshandbuch

8. Welche der folgenden Befehle bewirken auf einem 2960-Switch eine nderung des Wertes der Bridge-ID? a) spanning-tree bridge-id value b) spanning-tree vlan vlan-number root {primary | secondary} c) spanning-tree vlan vlan-number priority value d) set spanning-tree priority value 9. Betrachten Sie den folgenden Auszug aus dem Befehl show spanning-tree, ausgefhrt auf einem Cisco-Switch:
Bridge ID Priority Address 32771 (priority 32768 sys-id-ext 3) 0019.e86a.6f80

Welche der folgenden Aussagen bezglich des Switchs, der diese Befehlsausgabe erzeugt hat, ist zutreffend? a) Die Angaben betreffen die STP-Instanz fr VLAN 1. b) Die Angaben betreffen die STP-Instanz fr VLAN 3. c) Die Befehlsausgabe zeigt, dass dieser Switch nicht der Root-Switch sein kann. d) Die Befehlsausgabe zeigt, dass dieser Switch gegenwrtig als RootSwitch agiert. 10. Switch SW3 empfngt nur zwei Hello-BPDUs, die beide vom selben Root-Switch stammen. Der Empfang erfolgt an zwei Schnittstellen wie folgt:
SW3#show interfaces status Port Name Zustand Vlan Fa0/13 connected 3 Gi0/1 connected 1 Duplex Speed a-half a-100 a-full a-1000 Type 10/100BaseTX 1000BaseTX

Fr SW3 gibt es keine STP-spezifischen Konfigurationsbefehle. Das auf Fa0/13 empfangene Hello gibt den Kostenwert 10 an, das auf Gi0/1 empfangene den Kostenwert 20. Welche der folgenden Aussagen zu STP auf SW3 ist zutreffend? a) SW3 whlt Fa0/13 als Root-Port. b) SW3 whlt Gi0/1 als Root-Port. c) Fa0/13 an SW3 wird ein designierter Port. d) Gi0/1 an SW3 wird ein designierter Port.

Kapitel 2 Das Spanning-Tree-Protokoll

111

2.2

Wissensgrundlage

Ohne das Spanning-Tree-Protokoll (STP) wrden Ethernet-Frames in einem LAN mit redundanten Leitungen fr immer zirkulieren, ohne jemals beim Empfnger zu landen. Ist STP hingegen aktiviert, so sperren einige Switches ausgewhlte Ports, damit diese keine Frames weiterleiten. STP bestimmt, welche Ports gesperrt werden, sodass nur ein einziger aktiver Pfad zwischen zwei beliebigen LAN-Segmenten (Kollisions-Domnen) vorhanden ist. Infolgedessen knnen Frames an jedes Gert ausgeliefert werden, ohne dass es zum Problem der Netzwerkschleifen kommt. Zu Anfang dieses Kapitels wird zunchst erklrt, warum ein STP-Standard vonseiten des IEEE notwendig war und wie dieser funktioniert. Der zweite groe Abschnitt beschreibt vergleichend, wie das neue und viel schnellere RSTP (Rapid STP) funktioniert. Die letzten beiden Hauptabschnitte untersuchen dann die Konfiguration von STP bzw. die Behebung STP-spezifischer Probleme.

2.3

Das Spanning-Tree-Protokoll (IEEE 802.1d)

IEEE 802.1d war der erste ffentliche Standard fr STP. Er definierte eine vernnftige Lsung fr das Problem der ber redundante Leitungen endlos kreisenden Frames. In den folgenden Abschnitten werden wir das zugrunde liegende Problem zunchst detailliert beschreiben. Danach erlutern wir, wie STP dieses Problem lst. Die Abschnitte enden jeweils mit einer lngeren Beschreibung der Funktionsweise von STP als verteiltem Prozess auf allen LAN-Switches zur Verhinderung von Schleifen.

2.3.1

Warum ein Spanning-Tree notwendig ist

Das am hufigsten auftretende Problem, das mithilfe von STP vermieden werden kann, sind Broadcast-Strme. Broadcast-Strme fhren dazu, dass Broadcasts (oder Multicasts oder auch Unicasts mit unbekannten Ziel) kontinuierlich in einem LAN kreisen. Infolgedessen kann es zu einer Sttigung von Leitungen mit sinnlosen Kopien ein und desselben Frames kommen, wodurch erwnschte Frames verdrngt werden. Zudem kann sich ein Broadcast-Sturm erheblich auf die Leistungsfhigkeit eines Endbenutzer-PC auswirken, weil dieser zu viele Broadcast-Frames verarbeiten muss. Abbildung 2.1 zeigt, wie man sich dies vorstellen muss: In einem Beispielnetzwerk sendet Bob einen Broadcast-Frame. Die unterbrochenen Linien zeigen, wie die Switches den Frame weiterleiten, falls STP nicht vorhanden ist.

112
Larry

CCNA ICND2-Prfungshandbuch

Fa0/11 Gi0/1 SW1 Gi0/2 Gi0/2 SW2 Gi0/1

Archie Fa0/12

Gi0/1 SW3 Fa0/13

Gi0/2

Bob 0200.3333.3333

Abbildung 2.1: Broadcast-Sturm

Switches fluten Broadcasts ber alle Schnittstellen im selben VLAN mit Ausnahme derjenigen, ber die der Frame empfangen wurde. In unserem obigen Beispiel bedeutet dies, dass SW3 Bobs Frame an SW2, SW2 an SW1 und SW1 wieder an SW3 weiterleitet, wo die Reise dann von vorne beginnt. Dieser Frame kreist so lange im Netzwerk, bis sich irgendetwas ndert, d. h., bis eine Schnittstelle abgeschaltet, ein Switch neu geladen oder irgendetwas anderes getan wird, was zu einer Unterbrechung der Schleife fhrt. Beachten Sie, dass dasselbe auch in entgegengesetzter Richtung passiert: Wenn Bob den ursprnglichen Frame sendet, schickt SW3 auch eine Kopie an SW1, der sie dann an SW2 weiterleitet. Und so weiter und so fort. Infolge der kreisenden Frames kommt es auch zu Instabilitten der MACTabelle. Hierunter versteht man, dass die MAC-Adresstabellen der Switches fortlaufend die Angaben zur Absender-MAC-Adresse des Frames ndern. So beginnt SW3 in Abbildung 2.1 etwa mit folgendem MAC-Tabelleneintrag:
0200.3333.3333 Fa0/13 VLAN 1

berlegen Sie nun einmal, welcher Lernprozess bei den Switches stattfindet, wenn der kreisende Frame zu SW2, dann zu SW1 und schlielich wieder zur Schnittstelle Gi0/1 von SW3 gelangt. SW3 denkt Soso: Die AbsenderMAC-Adresse lautet 0200.3333.3333, und den Frame habe ich ber meine Schnittstelle Gi0/1 erhalten. Bringen wir also meine MAC-Tabelle auf den neuesten Stand. Aufgrund dessen steht in der MAC-Tabelle von SW3 nun der folgende Eintrag:
0200.3333.3333 Gi0/1 VLAN 1

Kapitel 2 Das Spanning-Tree-Protokoll

113

Wenn nun ein anderer Frame bei SW3 eintrifft, der nicht mit dem kreisenden Frame identisch ist, aber an Bobs MAC-Adresse (0200.3333.3333) gerichtet ist, wrde SW3 diesen Frame flschlicherweise ber Gi0/1 an SW1 weiterleiten. Auch dieser neue Frame kann nun zu zirkulieren beginnen und wird unter Umstnden niemals bei Bob landen. Die dritte Variante von Problemen, die durch die Nichtverwendung von STP in einem Netzwerk mit Redundanz auftreten kann, besteht darin, dass laufende Hosts mehrere Kopien desselben Frames erhalten. Nehmen wir etwa an, Bob sendet einen Frame an Larry, aber keiner der vorhandenen Switches kennt Larrys MAC-Adresse. (Switches fluten Frames, die als Unicast an nicht bekannte Ziel-MAC-Adressen gesendet werden.) Wenn Bob nun den (an Larrys MAC-Adresse gerichteten) Frame sendet, schickt SW3 je eine Kopie an SW1 und SW2. SW1 und SW2 fluten den Frame ebenfalls die Kopien der Frames beginnen zu kreisen. SW1 sendet auch eine Kopie jedes Frames ber Fa0/11 an Larry. Infolgedessen erhlt Larry mehrere Kopien des Frames, was bestenfalls zu einem Anwendungsfehler fhrt wenn nicht zu noch drastischeren Netzwerkproblemen. Tabelle 2.2 fasst die drei wesentlichen Kategorien von Problemen zusammen, die auftreten knnen, wenn STP in einem LAN mit redundanten Leitungen nicht verwendet wird.
Tabelle 2.2: Probleme, die durch die Nichtverwendung von STP in redundanten LANs entstehen knnen
Problem Broadcast-Strme Beschreibung Wiederholtes Weiterleiten eines Frames ber dieselben Leitungen, wodurch erhebliche Verbindungskapazitten gebunden werden Fortlaufende Aktualisierung der MAC-Adresstabelle eines Switchs mit falschen Eintrgen infolge kreisender Frames, woraufhin Frames ber falsche Schnittstellen weitergeleitet werden Nebeneffekt kreisender Frames, bei dem mehrere Kopien desselben Frames an den Zielhost ausgeliefert werden, was dort zu Strungen fhren kann

Wichtig!

Instabile MACTabellen

Mehrfachbertragung von Frames

2.3.2

Was Spanning-Tree bewirkt

STP verhindert Schleifen, indem jeder Bridge- oder Switch-Port in den Zustand Forwarding oder Blocking versetzt wird. Schnittstellen mit dem Zustand Forwarding arbeiten wie gewohnt, das heit, sie empfangen Frames und leiten sie weiter. Schnittstellen mit dem Zustand Blocking hingegen verarbeiten ausschlielich STP-Nachrichten. Alle Ports mit dem Zustand Forwarding gelten als Bestandteil des aktuellen Spanning-Tree (dt. Spann-

114

CCNA ICND2-Prfungshandbuch

baum). Die Summe der weiterleitenden Ports erstellt genau einen Pfad, ber den Frames zwischen Ethernet-Segmenten bertragen werden. Abbildung 2.2 zeigt einen einfachen STP-Baum, der das in Abbildung 2.1 gezeigte Problem behebt, indem er einen Port von SW3 in den Zustand Blocking versetzt.
Larry Fa0/11 Gi0/1 3 SW1 Gi0/2 3 4 2 GESPERRT Gi0/1 SW3 Fa0/13 1 Bob 0200.3333.3333 Gi0/2 Gi0/2 SW2 Gi0/1 Fa0/12 4 Archie

Abbildung 2.2: Netzwerk mit redundanten Verbindungen und STP

Wenn Bob nun einen Broadcast-Frame sendet, beginnt dieser nicht zu kreisen. Bob sendet den Frame an SW3 (Schritt 1), welcher ihn dann nur an SW1 weiterleitet (Schritt 2), weil die Schnittstelle Gi0/2 von SW3 den Zustand Blocking hat. SW1 flutet den Frame ber seine Schnittstellen Fa0/11 und Gi0/1 (Schritt 3). SW2 flutet den Frame ber seine Schnittstellen Fa0/12 und Gi0/1 (Schritt 4). SW3 allerdings ignoriert den von SW2 empfangenen Frame, weil dieser an der gesperrten Schnittstelle Gi0/2 eingeht. Die STP-Topologie in Abbildung 2.2 sorgt dafr, dass die Switches die Verbindung zwischen SW2 und SW3 in diesem VLAN schlichtweg nicht fr die Datenbertragung nutzen (dies mag als kleiner Nachteil von STP gelten). Fllt jedoch die Verbindung zwischen SW1 und SW3 aus, dann konvergiert STP, sodass SW3 seine Schnittstelle Gi0/2 nicht mehr blockiert, sondern Daten darber weiterleitet.

ANMERKUNG
Der Begriff der STP-Konvergenz bezeichnet einen Vorgang, bei dem alle Switches bemerken, dass die LAN-Topologie sich gendert hat, und daraus schlieen, dass unter Umstnden neu konfiguriert werden muss, welche Ports blockieren und welche Daten weiterleiten.

Kapitel 2 Das Spanning-Tree-Protokoll

115

Wie nun gelingt es STP, Switches zum Sperren ihrer Schnittstellen bzw. zum Weiterleiten von Daten zu bringen? Und wie erfolgt der Wechsel vom Zustand Blocking zu Forwarding, um die vorhandenen redundanten Leitungen im Falle von Netzwerkausfllen auch zu nutzen? Diese Fragen werden in den nachfolgenden Abschnitten beantwortet.

2.3.3

Wie Spanning-Tree funktioniert

Der STP-Algorithmus erstellt einen Spanning-Tree aus Schnittstellen, die Frames weiterleiten. Diese Baumstruktur bildet genau einen Pfad aus jedem Ethernet-Segment in jedes andere Ethernet-Segment genau wie bei einem echten Baum, wo Sie den Weg im Grunde genommen jedes Blatts von der Wurzel bis zu seiner Position am Ende eines Zweigs nachverfolgen knnen.

ANMERKUNG
Da Ethernet-Bridges heutzutage nur noch selten eingesetzt werden, beschreibt dieses Kapitel ausschlielich Switches. Allerdings verwenden sowohl Bridges als auch Switches STP. Der von STP eingesetzte Vorgang, der manchmal auch als Spanning-TreeAlgorithmus (oder kurz STA) bezeichnet wird, legt fest, welche Schnittstellen in den Zustand Forwarding versetzt werden sollen. Alle Schnittstellen, die sich nicht im Zustand Forwarding befinden, werden vom STA in den Zustand Blocking versetzt. Anders formuliert: STP whlt aus, welche Schnittstellen Daten weiterleiten drfen. STP wendet drei Kriterien an, um auszuwhlen, ob eine Schnittstelle in den Zustand Forwarding versetzt werden soll: STP whlt einen Root-Switch aus. Alle aktiven Schnittstellen dieses RootSwitchs werden in den Zustand Forwarding versetzt. Jeder Nicht-Root-Switch whlt einen seiner Ports aus, der die niedrigsten administrativen Kosten fr die Verbindung zum Root-Switch bietet. STP versetzt diese Schnittstelle den sogenannten Root-Port (RP) in den Zustand Forwarding. Mehrere Switches knnen an dasselbe Ethernet-Segment angeschlossen sein. Der Switch-Port mit den niedrigsten administrativen Kosten bis zur Root-Bridge (im Vergleich zu anderen an dasselbe Segment angeschlossenen Switches) wird in den Zustand Forwarding versetzt. Der Switch mit den niedrigsten Kosten in einem Segment wird als designierter Switch bezeichnet. Die Schnittstelle dieses Switchs, die an das Segment angeschlossen ist, heit designierter Port (DP).

116

CCNA ICND2-Prfungshandbuch

ANMERKUNG
Der Grund dafr, dass der Root-Switch alle aktiven Schnittstellen in den Zustand Forwarding versetzt, besteht eigentlich darin, dass alle seine Schnittstellen DPs werden. Es ist jedoch leichter, sich zu merken, dass alle aktiven Schnittstellen des Root-Switchs Frames weiterleiten. Alle brigen Schnittstellen werden in den Zustand Blocking versetzt. Tabelle 2.3 fasst zusammen, auf welcher Grundlage STP einen Port in den Zustand Forwarding oder Blocking versetzt.
Tabelle 2.3: Grundlagen zu den Zustnden Forwarding und Blocking
Wichtig!

Charakteristik des Ports STP-Zustand Beschreibung Alle Ports des RootSwitchs Root-Ports aller NichtRoot-Switches Designierte Ports aller LANs Forwarding Der Root-Switch ist stets der designierte Switch in allen angeschlossenen Segmenten. Port mit den geringsten administrativen Kosten der Verbindung zum RootSwitch Der Switch, der die BPDU mit den niedrigsten Kosten in das Segment weiterleitet, ist der designierte Switch des Segments. Der Port wird nicht zur Weiterleitung von Frames verwendet. Ebenso wenig werden Frames weitergeleitet, die ber diese Schnittstellen empfangen werden.

Forwarding

Forwarding

Alle anderen aktiven Ports

Blocking

ANMERKUNG
STP bercksichtigt nur aktive Schnittstellen. Ausgefallene Schnittstellen (z. B. solche, an die kein Kabel angeschlossen ist) werden ebenso wie durch den Administrator deaktivierte Schnittstellen in den STP-Zustand Disabled versetzt. Insofern wird in diesem Abschnitt der Begriff der aktiven Ports fr Schnittstellen verwendet, die Frames weiterleiten knnten, sofern sie von STP in den Zustand Forwarding versetzt werden.

Kapitel 2 Das Spanning-Tree-Protokoll

117

Bridge-ID und Hello-BPDU


Der STA whlt zunchst einen Switch aus, der als Root-Switch agiert. Um diesen Auswahlprozess besser verstehen zu knnen, mssen Sie wissen, welche STP-Nachrichten zwischen Switches ausgetauscht werden, und auch ber Prinzip und Format der Kennung Bescheid wissen, mit denen die einzelnen Switches eindeutig identifiziert werden. Die Bridge-ID (kurz BID) ist ein acht Byte langer Wert, der fr jeden Switch eindeutig ist. Er besteht aus einem zwei Byte umfassenden Priorittsfeld und einer sechs Byte langen System-ID, die auf einer dem Switch fest zugewiesenen MAC-Adresse basiert. Die Verwendung einer solchen MACAdresse gewhrleistet, dass die BID eines Switchs in jedem Fall eindeutig ist. STP definiert als BPDUs (Bridge Protocol Data Units, Bridge-ProtocolDateneinheiten) bezeichnete Nachrichten, mit denen Bridges und Switches Daten miteinander austauschen knnen. Die hufigste Nachricht die Hello-BPDU enthlt die BID des sendenden Switchs. Durch Angeben ihrer eigenen BID knnen Switches BPDUs auseinanderhalten, die von anderen Switches bermittelt werden. Diese Nachricht gibt auch die BID des aktuellen Root-Switchs an. STP definierte mehrere Arten von BPDU-Nachrichten, wobei die HelloBPDU am hufigsten verwendet wird. Diese BPDU enthlt eine Anzahl von Feldern, deren wichtigste in Tabelle 2.4 aufgefhrt sind.
Tabelle 2.4: Felder der STP-Hello-BPDU
Feld Root-BID BID des Absenders Kosten fr das Erreichen des Root-Switchs Timer-Werte auf dem Root-Switch Beschreibung BID der Bridge bzw. des Switchs, den der Absender des Hello fr den gegenwrtigen Root-Switch hlt BID der Bridge bzw. des Switchs, der diese HelloBPDU sendet STP-Kosten zwischen diesem Switch und dem aktuellen Root-Switch Hello-Timer, MaxAge-Timer und Forward-DelayTimer
Wichtig!

Zunchst einmal mssen Sie sich nur die ersten drei Eintrge in Tabelle 2.4 merken, denn in den nchsten Abschnitten werden wir die drei Schritte behandeln, mit denen STP festlegt, welche Schnittstellen in den Zustand Forwarding versetzt werden.

118

CCNA ICND2-Prfungshandbuch

Root-Switch auswhlen
Switches whlen einen Root-Switch basierend auf den BIDs in den BPDUs aus. Der Root-Switch ist der Switch mit der numerisch niedrigsten BID. Aufgrund der Zweiteilung der BID wird zunchst der Priorittswert berprft, das heit, meist wird der Switch durch die niedrigste Prioritt zum RootSwitch. Wenn beispielsweise ein Switch den Priorittswert 100 und ein anderer den Wert 200 aufweist, so wird der Switch mit dem Wert 100 unabhngig davon ausgewhlt, mit welcher MAC-Adresse die BID fr die Bridges oder Switches erstellt wurde. Kommt es beim Priorittsvergleich der BIDs zu einem Gleichstand, dann wird der Switch mit der niedrigsten MAC-Adresse in der BID zum RootSwitch. Eine andere Unterscheidung ist nicht notwendig, da Switches eine ihrer fest vorgegebenen MAC-Adressen als zweiten Bestandteil der BIDs verwenden. Wenn es also zu einem Gleichstand der Prioritten kommt und ein Switch die MAC-Adresse 0020.0000.0000 als Bestandteil der BID verwendet, whrend dieser beim zweiten 0FFF.FFFF.FFF lautet, so wird der erste Switch (mit der MAC-Adresse 0020.0000.0000) zum Root-Switch. STP whlt einen Root-Switch auf eine Weise aus, die der politischen Kandidatenkr nicht unhnlich ist. Am Anfang des Vorgangs behaupten alle Switches, Root-Switch zu sein, indem sie Hello-BPDUs senden, die ihre jeweilige eigene BID als Root-BID enthalten. Wenn ein Switch nun ein Hello empfngt, das eine bessere d. h. niedrigere BID enthlt (man spricht auch von einem berlegenen Hello), hrt der Switch auf, sich selbst als Root auszuweisen, und leitet stattdessen das berlegene Hello weiter. Das vom besseren Switch gesendete Hello listet die BID dieses Switchs als Root auf. Das Ganze funktioniert wie eine politische Kampagne, in der ein weniger populrer Kandidat das Rennen irgendwann aufgibt und einem anderen Kandidaten seine Untersttzung zusichert. Am Ende sind sich dann alle darber einig, welcher Switch die beste (d. h. niedrigste) BID aufweist, und alle untersttzen diesen ausgewhlten Switch. (An dieser Stelle endet die Analogie zur Kandidatenkr.) Abbildung 2.3 zeigt den Anfang des Root-Auswahlprozesses. Hier haben sich SW1, SW2 und SW3 gleichermaen als Root ausgewiesen. Nun stellt SW2 aber fest, dass SW1 ein besserer Root-Switch wre, und leitet ab sofort das von SW1 stammende Hello weiter. Dieses weitergeleitete Hello enthlt die BID von SW1 als Root-BID. Bei der gezeigten Anordnung gehen SW1 und SW3 jedoch weiterhin davon aus, dass sie selbst jeweils die Besten sind, und geben deswegen beide ihre jeweilige BID als Root in den Hello-BPDUs an.

Kapitel 2 Das Spanning-Tree-Protokoll


Kosten bis Root: 0 Eigene BID: 32,769:0200.0001.0001 Root-BID: 32,769:0200.0001.0001

119

SW1 Gi0/2

Gi0/1

Gi0/2 SW2 Gi0/1 Kosten bis Root: 4 Eigene BID: 32,769:0200.0002.0002 Root-BID: 32,769:0200.0001.0001

Kosten bis Root: 0 Eigene BID: 32,769:0200.0001.0001 Root-BID: 32,769:0200.0001.0001

Gi0/1 SW3 Kosten bis Root: 0 Eigene BID: 32,769:0200.0003.0003 Root-BID: 32,769:0200.0003.0003

Gi0/2 Kosten bis Root: 0 Eigene BID: 32,769:0200.0003.0003 Root-BID: 32,769:0200.0003.0003

Abbildung 2.3: Erste Phase der Root-Auswahl

Mit SW1 und SW3 sind in Abbildung 2.3 also noch zwei Kandidaten fr die Root-Auswahl vorhanden. Wer also gewinnt? Auf der Basis der BID ist dies der Switch mit der niedrigeren Prioritt und bei identischen Priorittswerten der Switch mit der niedrigeren MAC-Adresse. Wie aus der Abbildung hervorgeht, hat SW1 eine niedrigere BID (32769:0200.0000.0001) als SW3 (32769:0200.0003.0003) und gewinnt das Rennen; jetzt glaubt auch SW3, dass SW1 der bessere Switch ist. Abbildung 2.4 zeigt die resultierenden von den Switches ausgetauschten Hello-Nachrichten.
Kosten bis Root: 0 Eigene BID: 32,769:0200.0001.0001 Root-BID: 32,769:0200.0001.0001 1 SW1 Gi0/2 Kosten bis Root: 0 Eigene BID: 32,769:0200.0001.0001 Root-BID: 32,769:0200.0001.0001 2 1 Kosten 4 Gi0/1 Kosten 5 Gi0/2 SW3 2 Gi0/1 Cost 4 Gi0/2 SW2 Kosten 4 Gi0/1

Kosten bis Root: 4 Eigene BID: 32,769:0200.0002.0002 Root-BID: 32,769:0200.0001.0001

Kosten bis Root: 5 Eigene BID: 32,769:0200.0003.0003 Root-BID: 32,769:0200.0001.0001

Abbildung 2.4: SW1 gewinnt die Wahl.

Nach Abschluss der Wahlen generiert nur noch der Root-Switch HelloBPDUs, whrend die brigen Switches diese Hellos empfangen, das Absen-

120

CCNA ICND2-Prfungshandbuch

der-BID-Feld (und das Kostenwertfeld) aktualisieren und die Hello-BPDUs ber ihre anderen Schnittstellen weiterleiten. Die Abbildung stellt diese Tatsache dar: SW1 sendet in Schritt 1 die Hellos, und SW2 und SW3 leiten diese dann in Schritt 2 unabhngig voneinander ber ihre anderen Schnittstellen weiter.

Root-Port auswhlen
Der zweite Abschnitt des STP-Prozesses findet statt, wenn alle Nicht-RootSwitches ihre jeweiligen Root-Ports auswhlen. Der Root-Port (RP) eines Switchs ist die Schnittstelle mit den niedrigsten STP-Kosten zum Erreichen des Root-Switchs. Ein Switch berechnet die Kosten, indem er die in einem empfangenen Hello angegebenen Kostenwerte zu den STP-Port-Kosten hinzuaddiert, die der betreffenden Schnittstelle zugewiesen sind. Der STP-Kostenwert ist ein einfacher ganzzahliger Wert, der allen Schnittstellen zugeordnet wird. Es handelt sich dabei um eine objektive Gre, anhand derer STP ermitteln kann, welche Schnittstellen zur STP-Topologie hinzuzufgen sind. Abbildung 2.5 zeigt exemplarisch, wie SW3 die Kosten zum Erreichen des Root-Switchs fr zwei mgliche Pfade berechnet, indem er die via Hello ausgewiesenen Kosten zu den in der Abbildung gezeigten Schnittstellenkosten hinzuaddiert.

Wichtig!

Kosten bis Root: 0 Eigene BID: 32,769:0200.0001.0001 Root-BID: 32,769:0200.0001.0001 Gi0/1

0+4=4 STP-Kosten 4

SW1 Gi0/2 Kosten bis Root: 0

Gi0/2 SW2 Gi0/1 Kosten bis Root: 4 Eigene BID: 32,769:0200.0002.0002 Root-BID: 32,769:0200.0001.0001

Eigene BID: 32,769:0200.0001.0001 Root BID: 32,769:0200.0001.0001

Gi0/1

RP STP-Kosten 5
SW3

STP-Kosten 4
Gi0/2

4+4=8 0+5=5

Abbildung 2.5: Berechnung der Kosten fr das Erreichen des Root-Switchs durch SW3 und Auswahl des Root-Ports

Am Ende des in Abbildung 2.5 dargestellten Vorgangs whlt SW3 seine Schnittstelle Gi0/1 als Root-Port aus, denn die Kosten fr das Erreichen des

Kapitel 2 Das Spanning-Tree-Protokoll

121

Root-Switchs ber diesen Port (5) sind niedriger als bei der anderen Alternative (Gi0/2, Kostenwert 8). Analog whlt SW2 seine Schnittstelle Gi0/2 als RP aus, denn diese weist den Kostenwert 4 auf die Summe aus dem von SW1 ausgewiesenen Kostenwert 0 und dem SchnittstellenKostenwert 4 fr Gi0/2. Jeder Switch versetzt seinen Root-Port in den Zustand Forwarding. In komplexeren Topologien ist die Auswahl des Root-Ports hufig nicht so offensichtlich. Der Abschnitt Behebung von STP-Problemen im weiteren Verlauf dieses Kapitels zeigt ein Beispiel, bei dem die Auswahl des RootPorts ein wenig mehr Aufwand erfordert.

Designierten Port fr LAN-Segmente auswhlen


Der letzte Schritt zur Einrichtung der STP-Topologie ist die Auswahl des designierten Ports in jedem LAN-Segment. Der designierte Port in einem LAN-Segment ist derjenige Switch-Port, der die niedrigsten Kosten in diesem Segment via Hello ausweist. Wenn ein Nicht-Root-Switch ein Hello weiterleitet, so setzt er das Kostenfeld im Hello auf seinen eigenen fr das Erreichen des Root-Switchs angegebenen Kostenwert. Am Ende wird dann von allen an ein Segment angeschlossenen Switches derjenige mit den niedrigsten Kosten fr das Erreichen des Root-Switchs zum designierten Port (DP) des Segments. In Abbildung 2.4 etwa leiten sowohl SW2 als auch SW3 Hello-Nachrichten in das Segment weiter. Beachten Sie, dass diese beiden Switches ihre jeweiligen Kosten fr das Erreichen des Root-Switchs ausweisen (Wert 4 bei SW2, Wert 5 bei SW3). Also ist die Schnittstelle Gi0/1 von SW2 der designierte Port in diesem LAN-Segment. Alle DPs werden in den Zustand Forwarding versetzt, das heit, dies gilt hier auch fr die Schnittstelle Gi0/1 von SW2. Wenn bei den ausgewiesenen Kosten ein Gleichstand vorliegt, erfolgt die Auswahl anhand der niedrigeren BID. In diesem Fall wrde SW2 gewinnen, da seine BID 32769:0200.0002.0002 niedriger ist als die von SW3 (32769:0200.0003.0003).

ANMERKUNG
Wenn Hubs verwendet werden, kann ein Switch auch ber zwei oder mehr Schnittstellen an dieselbe Kollisions-Domne angeschlossen sein. In solchen Fllen ist zur berwindung eines Gleichstandes unter Umstnden ein anderer Faktor notwendig. Der Switch whlt dann die Schnittstelle mit der niedrigsten internen Schnittstellennummer.

122

CCNA ICND2-Prfungshandbuch

Die einzige Schnittstelle bei den drei in den Abbildungen 2.3, 2.4 und 2.5 gezeigten Switches, bei der kein Grund fr den Wechsel in den Zustand Forwarding besteht, ist der Port Gi0/2 von SW3. Insofern ist der STP-Vorgang nun abgeschlossen. Tabelle 2.5 gibt den Zustand der einzelnen Ports und den Grund dafr an, dass dieser Zustand gewhlt wurde.
Tabelle 2.5: Zustand der Schnittstellen
Switch-Schnittstelle SW1, Gi0/1 SW1, Gi0/2 SW2, Gi0/2 SW2, Gi0/1 SW3, Gi0/1 SW3, Gi0/2 Zustand Forwarding Forwarding Forwarding Forwarding Forwarding Blocking Grund fr die Auswahl Schnittstelle am Root-Switch Schnittstelle am Root-Switch Root-Port Designierter Port im LAN-Segment zu SW3 Root-Port Ist weder Root-Port noch designierter Port.

Port-Kosten lassen sich zwar konfigurieren, aber Sie knnen auch die Default-Werte verwenden. Tabelle 2.6 listet diese Standardkostenwerte auf, wie sie vom IEEE definiert wurden (Cisco verwendet dieselben Voreinstellungen). Das IEEE hat diese Kostenwerte inzwischen revidiert, da man bei der ursprnglichen Formulierung in den frhen 1980er-Jahren nicht davon ausging, dass Ethernet dereinst Raten von 10 Gbit/s untersttzen wrde.
Tabelle 2.6: Standard-Port-Kosten nach IEEE
Wichtig!

Ethernet-Rate 10 Mbit/s 100 Mbit/s 1 Gbit/s 10 Gbit/s

IEEE-Kostenwert (ursprngliche Definition) 100 10 1 1

IEEE-Kostenwert (revidierte Definition) 100 19 4 2

Bei aktiviertem STP nehmen alle aktiven Switch-Schnittstellen auch Access-Ports einen der STP-Zustnde Forwarding oder Blocking an. Ein Switch leitet Hellos dabei auch ber Schnittstellen weiter, die mit Hosts oder Routern verbunden sind, die kein STP verwenden. Da der Switch das einzige Gert ist, das Hellos in ein LAN-Segment sendet, erhlt dieses Segment Informationen zum Switch mit dem niedrigsten Kostenfaktor; insofern wird der Switch zum designierten Port in diesem LAN-Segment. Letztendlich versetzt STP also als Folge der Festlegung designierter Ports aktive AccessSchnittstellen in den Zustand Forwarding.

Kapitel 2 Das Spanning-Tree-Protokoll

123

Auf nderungen im Netzwerk reagieren


Nachdem die STP-Topologie also die Gruppe der Schnittstellen mit dem Zustand Forwarding ermittelt wurde, erfolgen dort keine STP-Zustandsnderungen mehr, bis sich die Netzwerktopologie ndert. In diesem Abschnitt untersuchen wir, was STP tut, solange das Netzwerk stabil ist, und wie es zu einer neuen Topologie konvergiert, sobald im Netzwerk nderungen auftreten. Der Root-Switch sendet standardmig alle zwei Sekunden eine neue HelloBPDU. Jeder Switch leitet das Hello ber alle designierten Ports weiter allerdings erst, nachdem er zwei Parameter gendert hat. Zunchst wird der Kostenwert zum Erreichen des Root-Switchs so angepasst, dass er dem Wert des betreffenden Switchs entspricht. Auerdem wird das Absender-BID-Feld gendert. (Das Root-BID-Feld hingegen wird natrlich nicht gendert.) Durch Weiterleitung der empfangenen (und genderten) Hellos ber alle DPs erhalten alle Switches etwa alle zwei Sekunden aktuelle Hellos. Die folgende Liste fasst zusammen, wie der Betrieb bei stabilem Netzwerkzustand aussieht, wenn also keine nderungen in der STP-Topologie erfolgen: 1. Der Root-Switch erstellt und sendet ein Hello-BPDU mit dem Kostenwert 0 ber alle aktiven Schnittstellen (d. h. solche mit dem Zustand Forwarding). 2. Die brigen Switches empfangen das Hello ber ihre Root-Ports. Nachdem ein Switch in das Hello die eigene BID als Absender-BID eingetragen und den Kostenwert gendert hat, leitet er es ber alle designierten Ports weiter. 3. Die Schritte 1 und 2 wiederholen sich, bis eine nderung erfolgt. Jeder Switch ist auf diese periodisch empfangenen Hellos angewiesen, damit er wei, dass sein Pfad zum Root-Switch noch vorhanden ist. Erhlt ein Switch keine Hellos mehr, dann ist irgendetwas ausgefallen. Der Switch reagiert und startet den Vorgang zur nderung der Spanning-Tree-Topologie. Aus verschiedenen Grnden erfordert der Konvergenzprozess die Verwendung von drei Timern. Beachten Sie, dass alle Switches die Timer wie vom Root-Switch vorgegeben verwenden (diese fhrt der Root-Switch in den regelmig versendeten Hello-BPDUs auf). Die Timer und ihre Beschreibungen sind in Tabelle 2.7 aufgefhrt.
Wichtig!

124

CCNA ICND2-Prfungshandbuch

Tabelle 2.7: STP-Timer


Wichtig!

Timer Hello MaxAge

Beschreibung Zeitlicher Abstand zwischen den vom Root-Switch erzeugten Hellos Gibt an, wie lange ein Switch, wenn keine Hellos mehr eintreffen, warten soll, bevor er versucht, die STP-Topologie zu ndern.

Standardwert Zwei Sekunden Zehnfaches Hello-Intervall

ForwardDelay

Verzgerung, die sich auf den Vorgang auswirkt, 15 Sekunden der auftritt, wenn eine Schnittstelle aus dem Zustand Blocking in den Zustand Forwarding wechselt. Der Port verbleibt jeweils fr den durch diesen Timer angegebenen Zeitraum zunchst im Zustand Listening und dann im Zustand Learning.

Wenn ein Switch innerhalb des Hello-Intervalls keine Hello-BPDU empfngt, arbeitet er zunchst weiter wie gewhnlich. Sind allerdings bis zum Verstreichen des MaxAge-Intervalls Hellos ausgeblieben, so reagiert der Switch, indem er die zur nderung der STP-Topologie erforderlichen Schritte einleitet. An dieser Stelle analysiert der Switch im Grunde genommen erneut, welcher Switch Root-Switch sein soll und falls dies nicht der vorherige Root-Switch ist welche Ports als RP bzw. DPs festzulegen sind. Dabei geht er davon aus, dass die zuvor erhaltenen Hellos zuknftig nicht mehr eintreffen werden. Die beste Mglichkeit, die STP-Konvergenz zu beschreiben, besteht im praktischen Beispiel auf der Grundlage der bekannten Topologie. Diese ist in Abbildung 2.6 gezeigt.
Root ist SW1 Ich bin: SW1 Kosten = 0 Larry Fa0/11 DP Gi0/1 SW1 Gi0/2 DP DP RP Gi0/2 SW2 DP Gi0/1 Root ist SW1 Ich bin: SW2 Kosten = 4 Fa0/12 DP

Archie

RP Legende: RP: Root-Port DP: Designierter Port Gi0/1

SW3
DP Fa0/13

Gi0/2 Kosten 4

Bob 0200.3333.3333

Abbildung 2.6: Reaktion auf einen Verbindungsausfall zwischen SW1 und SW3

Kapitel 2 Das Spanning-Tree-Protokoll

125

Die Schnittstelle Gi0/2 von SW3 befindet sich im Zustand Blocking, aber Port Gi0/2 von SW1 ist soeben ausgefallen. SW3 reagiert auf die nderung, weil er keine Hellos mehr ber seine Schnittstelle Gi0/1 empfngt. SW2 hingegen muss nicht reagieren, weil er weiterhin in regelmigen Abstnden Hellos ber seine Schnittstelle Gi0/2 erhlt. In diesem Fall reagiert SW3 entweder nach Verstreichen des MaxAge-Timers oder aber, sobald er den Ausfall der Schnittstelle Gi0/1 erkannt hat. (Wenn die Schnittstelle ausfllt, geht der Switch naturgem davon aus, dass keine Hellos mehr eintreffen werden.) In diesem Szenario beginnt SW3 nun mit der Neubewertung potenzieller Root-Switches. Er erhlt das von SW2 weitergeleitete Hello von SW1, und SW1 weist eine niedrigere BID auf (sonst wre er ja auch zuvor nicht bereits Root-Switch gewesen). Folgerichtig geht SW3 davon aus, dass SW1 nach wie vor der beste Switch ist und SW3 selbst nicht Root. Im nchsten Schritt bewertet SW3 mgliche Root-Ports. An diesem Punkt empfngt SW3 nur ber eine einzige Schnittstelle Hellos, nmlich Port Gi0/2. Insofern wird Gi0/2 unabhngig von den ausgewiesenen Kosten der neue Root-Port von SW3. (Die Kosten betragen 8 die Summe aus den mit 4 ausgewiesenen Kosten fr SW2 und dem identischen Wert fr die Schnittstelle Gi0/2.) SW3 bewertet nun seine Funktion als designierter Port auf den anderen Schnittstellen. In unserem Beispiel fllt hierbei keine Arbeit an: SW3 war bereits designierter Port auf Schnittstelle Fa0/13, und dies bleibt auch so, da keine anderen Switches an diesen Port angeschlossen sind. Wenn STP konvergiert, wechselt ein Switch den Zustand seiner Schnittstellen. Allerdings ist ein Umschalten von Blocking zu Forwarding nicht ohne Weiteres mglich, da ein unvermittelter Wechsel vorbergehend dazu fhren knnte, dass Frames zu kreisen beginnen. Um solche temporren Schleifen zu verhindern, gibt es zwei Zwischenzustnde, die STP eine Schnittstelle durchlaufen lsst, bevor die Weiterleitung gestartet wird. Es sind dies: Listening: Wie im Zustand Blocking werden auch hier noch keine Frames weitergeleitet. Alte nun unzutreffende Eintrge in MAC-Tabellen werden in diesem Zustand durch Zeitberschreitung ungltig. (Solche Eintrge sind Hauptursache fr die temporren Schleifen.) Learning: Schnittstellen in diesem Zustand leiten immer noch keine Frames weiter, aber der Switch beginnt bereits mit dem Erlernen von MAC-Adressen aus Frames, die er an der betreffenden Schnittstelle empfngt.
Wichtig!

126

CCNA ICND2-Prfungshandbuch

STP weist den Schnittstellen beim Wechsel von Blocking nacheinander die Zustnde Listening, Learning und schlielich Forwarding zu. Dabei verbleibt die Schnittstelle jeweils fr die durch den Forward-Delay-Timer vorgegebene Dauer in den beiden Zwischenzustnden. Folglich dauert ein Konvergenzereignis, in dessen Verlauf die Schnittstelle von Blocking zu Forwarding wechselt, 30 Sekunden. Auerdem muss der Switch unter Umstnden noch das MaxAge-Intervall abwarten, bevor er berhaupt entscheiden kann, die Schnittstelle von Blocking auf Forwarding umzuschalten. Wenn wir bei unserem in den obigen Abbildungen gezeigten Beispiel bleiben, muss also SW3 zunchst den Ablauf des MaxAge-Timers (Standard: 20 Sekunden) abwarten, bevor er konstatieren kann, dass er ber seinen Root-Port keine BPDUs mehr vom Root-Switch empfngt; danach verbringt die Schnittstelle Gi0/2 jeweils 15 Sekunden im Zustand Listening und Learning. Ergebnis ist eine Konvergenzverzgerung von 50 Sekunden. Tabelle 2.8 fasst die verschiedenen STP-Schnittstellenzustnde der bersichtlichkeit halber zusammen.
Tabelle 2.8: STP-Zustnde im berblick
Wichtig!

Zustand

Weiterleitung von Erlernen von MAC-Adressen bergangszustand Daten-Frames? aus empfangenen Frames? oder stabiler Zustand? Nein Nein Nein Nein Nein Ja Ja Nein Stabil bergang bergang Stabil Stabil

Blocking Listening Learning

Forwarding Ja Disabled Nein

2.3.4

Optionale STP-Eigenschaften

STP gibt es schon seit mehr als 20 Jahren. Cisco-Switches implementieren STP nach IEEE 802.1d-Standard, aber im Laufe der Jahre wurden auch einige proprietre Merkmale hinzugefgt, die STP besser machen sollen. In manchen Fllen wurden diese Verbesserungen direkt oder in leicht abgewandelter Form vom IEEE bernommen sei es als Revision des 802.1d-Standards oder als neuer Standard. Die folgenden Abschnitte beschreiben drei der proprietren Ergnzungen: EtherChannel, PortFast und BPDU Guard.

Kapitel 2 Das Spanning-Tree-Protokoll

127

ANMERKUNG
Wenn Sie vorhaben, in einem LAN auf einem Produktionscampus zu arbeiten, lernen Sie am besten noch mehr ber STP-Funktionalitten, als in diesem Buch beschrieben wird. Rufen Sie zu diesem Zweck den Cisco Software Configuration Guide fr 2960-Switches auf und lesen Sie die Kapitel zu STP und RSTP sowie zu optionalen STP-Eigenschaften. Wo Sie die CiscoDokumentation finden, entnehmen Sie der Einleitung zu diesem Buch.

EtherChannel
Eine der besten Mglichkeiten, die Konvergenzdauer von STP zu verkrzen, besteht darin, eine Konvergenz generell auszuschlieen. EtherChannel ist ein Ansatz, der zur Anwendung kommt, wenn nur ein einzelner Port oder ein einzelnes Kabel ausfallen. Hierbei werden mehrere (genauer: bis zu acht) parallele Segmente gleicher Datenrate zwischen zwei Switches zu einem EtherChannel zusammengefasst. Die Switches behandeln was die Weiterleitung von Frames und den STP-Betrieb angeht den EtherChannel als einzelne Schnittstelle. Infolgedessen muss, falls eine Leitung ausfllt, aber mindestens eine weitere aktiv bleibt, keine neue STP-Konvergenz ermittelt werden. Abbildung 2.7 zeigt exemplarisch das bekannte Netzwerk mit den drei Switches. Im Unterschied zu vorher sind hier zwischen allen Switches jeweils zwei Gigabit-EthernetVerbindungen vorhanden.
Larry SW1 SW2 Archie

SW3

Bob

Abbildung 2.7: Doppelsegment-EtherChannels zwischen Switches

128

CCNA ICND2-Prfungshandbuch

Immer, wenn ein Paar Ethernet-Verbindungen als EtherChannel konfiguriert ist, behandelt STP diesen als Einzelverbindung. Anders gesagt: Es mssen schon beide Verbindungen zum selben Switch ausfallen, um die STP-Konvergenz auszulsen. Ohne EtherChannel wrde, wenn es mehrere parallele Leitungen zwischen zwei Switches gbe, STP alle diese Verbindungen bis auf eine sperren. Mit EtherChannel knnen alle diese parallelen Leitungen gleichzeitig aktiv sein und eingesetzt werden, whrend STP weniger oft konvergieren muss, was wiederum die Verfgbarkeit des Netzwerks steigert. EtherChannel bietet auch mehr Netzwerkbandbreite. Alle in einem EtherChannel zusammengefassten Ports befinden sich entweder im Zustand Forwarding oder sind gesperrt, weil STP eben alle Ports im selben EtherChannel als einen Port behandelt. Befindet sich ein EtherChannel im Zustand Forwarding, dann fhren die Switches einen Lastausgleich zwischen allen Ports durch, wodurch die Bandbreite gesteigert wird.

PortFast
PortFast erlaubt es einem Switch, eine Schnittstelle direkt in den Zustand Forwarding zu versetzen, sobald sie physisch aktiv wird; die Ergebnisse der STP-Topologie werden dabei ebenso unterschlagen wie die Zustnde Listening und Learning. Allerdings knnen Sie PortFast nur fr solche Ports sicher aktivieren, bei denen Sie genau wissen, dass sie nicht an Bridges, Switches oder andere STP untersttzende Gerte angeschlossen sind. PortFast ist eher fr Verbindungen mit Endbenutzergerten geeignet. Wenn Sie PortFast auf Ports aktivieren, an die Endbenutzergerte angeschlossen sind, und ein Endbenutzer nun seinen PC hochfhrt, kann der Switch-Port in den Zustand Forwarding wechseln, sobald die Netzwerkkarte des PC aktiv ist, und dann auch sofort Daten weiterleiten. Ohne PortFast muss jeder Port abwarten, bis der Switch sichergestellt hat, dass der Port ein designierter Port ist, und dann die Zustnde Listening und Learning durchlaufen, bevor der Zustand Forwarding eingenommen werden kann.

Sicherheit bei STP


Switch-Schnittstellen, die an Endgerte im LAN angeschlossen sind, sind gewissen Sicherheitsrisiken ausgesetzt. Ein Angreifer knnte einen Switch, der eine niedrige STP-Prioritt aufweist, mit einem dieser Ports verbinden und Root-Switch werden. Auerdem knnte der Switch des Angreifers, indem er mit mehreren regulren Switches verbunden wird, eine Vielzahl an Daten in das LAN einspeisen. berdies knnte der Angreifer mit einem LAN-Analyzer eine groe Anzahl von Daten-Frames kopieren, die ber das LAN gesendet werden. Zudem wre es auch mglich, dass normale Benutzer das LAN ohne Absicht beschdigen. So knnte ein Benutzer etwa einen billigen LAN-

Kapitel 2 Das Spanning-Tree-Protokoll

129

Switch der Consumer-Klasse an einen vorhandenen Switch anschlieen und dadurch eine Schleife bilden oder womglich Schuld daran sein, dass der neue und relativ schwach ausgelegte Switch zum Root-Switch wird. Die Cisco-Funktion BPDU Guard vermindert derartige Probleme dadurch, dass sie einen Port deaktiviert, wenn auf diesem BPDUs empfangen werden. Insofern ist diese Funktion besonders praktisch bei Ports, die nur als AccessPort zum Einsatz kommen sollen und niemals an einen anderen Switch angeschlossen werden. Auerdem wird BPDU Guard hufig auf Schnittstellen eingesetzt, bei denen auch PortFast aktiviert ist, weil ein PortFast-fhiger Port bereits den Zustand Forwarding aufweist, was die Entstehung von Schleifen begnstigt. Eine weitere praktische Cisco-Funktion ist Root Guard. Sie verhindert, dass ein nicht zulssiger Switch zum Root-Switch wird. Root Guard gestattet den Anschluss eines anderen Switchs an die Schnittstelle und den Beitritt zur STP-Topologie durch Versenden und Empfangen von BPDUs. Sobald allerdings die Switch-Schnittstelle, fr die Root Guard aktiviert wurde, eine hherwertige BPDU (d. h. eine BPDU mit einer besseren BID) vom benachbarten Switch empfngt, reagiert Root Guard. Die hherwertige BPDU wird nicht nur ignoriert, sondern der Switch deaktiviert zustzlich die betreffende Schnittstelle, solange hherwertige BPDUs anliegen es werden also keine Frames mehr versendet oder empfangen. Sobald festgestellt wird, dass keine hherwertigen BPDUs mehr eintreffen, kann der Switch die Schnittstelle wieder normal verwenden.

2.4

Rapid STP (IEEE 802.1w)

Wie bereits weiter oben in diesem Kapitel erwhnt, ist das Spanning-TreeProtokoll im Standard 802.1d des IEEE definiert. Das IEEE hat das 802.1dProtokoll durch die Definition des RSTP-Protokolls (Rapid Spanning Tree Protocol) verbessert, welches im Standard 802.1w definiert ist. RSTP (802.1w) funktioniert in vielerlei Hinsicht genau wie STP (802.1d): Der Root-Switch wird mit denselben Parametern und Entscheidungshilfen bestimmt. Der Root-Port bei Nicht-Root-Switches wird nach denselben Regeln ermittelt. Die designierten Ports in den einzelnen LAN-Segmenten werden nach denselben Regeln ermittelt. Alle Ports erhalten entweder den Zustand Forwarding oder den Zustand Blocking (auch wenn dieser bei RSTP Discarding heit).
Wichtig!

130

CCNA ICND2-Prfungshandbuch

RSTP kann parallel zu traditionellen 802.1d-STP-Switches eingesetzt werden. RSTP-Funktionen kommen in solchen Fllen bei Switches zum Einsatz, die RSTP untersttzen, whrend die traditionellen STP-Prozesse auf Switches verwendet werden, die dies nicht knnen. Angesichts dieser hnlichkeit fragen Sie sich vielleicht, warum RSTP vom IEEE berhaupt standardisiert wurde. Das Unterscheidungsmerkmal ist die Konvergenz. STP bentigt hierzu relativ lange bei den Voreinstellungen sage und schreibe 50 Sekunden. RSTP verbessert die Netzwerkkonvergenz beim Auftreten topologischer nderungen. RSTP optimiert die Konvergenz dadurch, dass die Wartezeichen, die STP fr die Vermeidung von Schleifen einhalten muss, erheblich verringert oder sogar vollstndig aufgehoben werden. 802.1d-STP muss zunchst einmal das MaxAge-Intervall (Standard: 20 Sekunden) verstreichen lassen, bevor es berhaupt auf bestimmte Ereignisse reagieren darf; RSTP hingegen wartet nur drei Hello-Intervalle ab (Standard: 6 Sekunden). Auerdem wird bei RSTP kein Forward-Delay (Standard: 15 Sekunden) fr die Zustnde Listening und Learning bentigt. Die traditionelle STP-Konvergenz besteht im Wesentlichen aus drei Zeitabschnitten, die bei RSTP alle optimiert werden. Diese drei Intervalle von (standardmig) 20, 15 und 15 Sekunden sorgen fr eine relativ langsame Konvergenz unter 802.1d STP, whrend die Verkrzung bzw. Beseitigung dieser Wartezeiten bei RSTP eine schnelle Konvergenz ermglicht. In der Regel liegen die Konvergenzzeiten bei RSTP unter 10 Sekunden. In manchen Fllen erfolgt die Konvergenz sogar innerhalb von 12 Sekunden. Die nachfolgenden Abschnitte erlutern RSTP-spezifische Terminologie und Prozesse, mit denen sich die Nachteile von 802.1d-STP beseitigen lassen und die Konvergenz verbessert werden kann.

ANMERKUNG
Wie in vielen anderen Texten auch bezeichnen wir den lteren 802.1d-Standard als STP und das neuere 802.1w als RSTP.

2.4.1

Konnektivittstypen bei RSTP

RSTP kennt drei Arten der physischen Konnektivitt in einem CampusLAN: Point-to-Point-Link Shared-Link Edge

Kapitel 2 Das Spanning-Tree-Protokoll Abbildung 2.8 zeigt diese Konnektivittstypen.

131

Shared-Edge Hub

Point-to-PointLink

Shared-Link Hub

Edge

Point-to-PointEdge

Abbildung 2.8: Konnektivittstypen bei RSTP

Abbildung 2.8 zeigt zwei Beispielnetzwerke. Das Netzwerk auf der linken Seite ist ein typisches Campusdesign ohne Hubs, wie es heute alltglich ist. Alle Switches sind ber Ethernet-Kabel miteinander verbunden, und die Endgerte sind ebenfalls ber Ethernet-Kabel angeschlossen. In solchen Netzwerken soll RSTP nach Magabe des IEEE die Konvergenz verbessern. Im Netzwerk auf der rechten Seite der Abbildung werden zur Verbindung zwischen den Switches noch immer Hubs eingesetzt, desgleichen fr die Anbindung der Endgerte. Die meisten Netzwerke setzen heute keine Hubs mehr ein. Das IEEE hat deswegen gar nicht erst versucht, den Einsatz von RSTP in Netzwerken zu untersttzen, die Hubs integrieren in einem solchen Netzwerk wie dem auf der rechten Seite brchte RSTP fr die Konvergenz keinen Gewinn. Bei RSTP werden Ethernet-Verbindungen zwischen Switches als Links und Verbindungen mit Endbenutzergerten als Edges bezeichnet. Es gibt zwei Arten von Links: Point-to-Point-Links (Abbildung 2.8, linke Seite) und Shared-Links (Abbildung 2.8, rechte Seite). Bei Edge-Verbindungen wird nicht zwischen Point-to-Point- und Shared-Prinzip unterschieden. RSTP verringert die Konvergenz fr Point-to-Point-Links und Edge-Verbindungen. Bei Shared-Links lsst sich keine Optimierung der Konvergenz durch RSTP erzielen. Die meisten modernen Netzwerke verwenden keine Hubs mehr zwischen den Switches, weswegen das Fehlen einer Konvergenzoptimierung fr Shared-Links bei RSTP im Grunde genommen keinen Mangel darstellt.

132

CCNA ICND2-Prfungshandbuch

2.4.2

Port-Zustnde bei RSTP

Sie sollten auch die neuen RSTP-Termini zur Beschreibung des PortZustands kennen. Tabelle 2.9 listet zunchst die Zustnde auf. Im Anschluss folgen weitere Erklrungen.
Tabelle 2.9: Port-Zustnde bei RSTP und STP
Wichtig!

Betriebszustand Aktiviert Aktiviert Aktiviert Aktiviert Disabled

STP-Zustand Blocking Listening Learning Forwarding Disabled

RSTPZustand Discarding Discarding Learning Forwarding Discarding

Weiterleitung von Frames in diesem Zustand? Nein Nein Nein Ja Nein

hnlich wie STP befinden sich bei RSTP bei stabiler Netzwerktopologie alle Ports entweder im Zustand Forwarding oder im Zustand Discarding. Discarding bedeutet, dass der Port weder Frames weiterleitet noch empfangene Frames verarbeitet oder MAC-Adressen erlernt; BPDUs hingegen werden verarbeitet. Kurz gesagt, verhlt sich der Port wie im STP-Zustand Blocking. RSTP verwendet einen Zwischenzustand namens Learning, wenn eine Schnittstelle aus dem Discarding- in den Forwarding-Zustand wechselt. Allerdings whrt der Zustand Learning bei RSTP nur sehr kurze Zeit.

2.4.3

Port-Funktionen bei RSTP

Sowohl STP (802.1d) als auch RSTP (802.1w) verwenden das Konzept der Port-Zustnde und Port-Funktionen. Der STP-Prozess ermittelt die Funktionen der einzelnen Schnittstellen. So bestimmt STP beispielsweise, welche Schnittstellen gegenwrtig die Funktionen des Root- oder eines designierten Ports haben. Danach legt STP den stabilen Port-Zustand fest, den Schnittstellen annehmen, die bestimmte Funktionen ausfllen: Root-Ports und designierte Ports erhalten den Zustand Forwarding, Ports mit anderen Funktionen den Zustand Blocking. RSTP ergnzt drei weitere Port-Funktionen, von denen zwei in Abbildung 2.9 gezeigt sind. Die dritte neue Funktion (der deaktivierte oder DisabledPort) ist nicht abgebildet; sie wird fr deaktivierte Schnittstellen verwendet.

Kapitel 2 Das Spanning-Tree-Protokoll


Larry DP SW1 Gi0/2 DP Gi0/1 DP Gi0/2 RP DP SW2 Gi0/1 BDP DP

133

Archie

RP Gi0/1 SW3 DP Gi0/2

Alternativ-Port

Bob

Abbildung 2.9: Port-Funktionen bei RSTP

Als Alternativ-Port (engl. Alternate-Port) wird die beste Alternative eines Switchs zu seinem gegenwrtigen Root-Port bezeichnet. Mit anderen Worten ist ein Alternativ-Port ein alternativer Root-Port. So weist SW3 etwa seine Schnittstelle Gi0/1 als Root-Port aus, wei aber auch, dass er HelloBPDUs ber die Schnittstelle Gi0/2 empfngt. SW3 verfgt also wie bei STP auch ber einen Root-Port. (Sie knnen bei Bedarf noch einmal Abbildung 2.4 betrachten, um Ihr Wissen ber den BPDU-Fluss bei stabiler Netzwerktopologie aufzufrischen.) RSTP kennzeichnet Ports, die suboptimale BPDUs empfangen (also solche, die nicht so gut sind wie die ber den Root-Port erhaltenen), als Alternativ-Ports. Erhlt SW3 keine Hellos mehr vom RootSwitch, so whlt RSTP auf SW3 den besten Alternativ-Port als neuen RootPort aus, um den beschleunigten Konvergenzprozess zu starten. Der zweite neue RSTP-Port-Typ der Reserve-Port (engl. Backup-Port) wird nur zugewiesen, wenn ein Switch ber zwei Leitungen in dasselbe Segment (Kollisions-Domne) verfgt. Damit zwei Leitungen in dieselbe Kollisions-Domne vorhanden sein knnen, muss der Switch an einen Hub angeschlossen sein. In Abbildung 2.9 weist SW2 einem seiner beiden Ports die Funktion des designierten Ports zu (der den Zustand Forwarding erhlt), whrend die andere Schnittstelle zum Reserve-Port wird, fr die dann der Zustand Discarding ausgewhlt wird. SW2 leitet BPDUs ber den Forwarding-Port weiter und erhlt dieselben BPDUs dann ber den Port im Discarding-Zustand zurck. Daher wei SW2, dass eine zustzliche Verbindung in dieses Segment vorhanden ist ein Reserve-Port also. Falls der designierte Port ausfllt, kann SW2 den Reserve-Port sofort von Discarding ber Learning in den Zustand Forwarding umschalten.

134

CCNA ICND2-Prfungshandbuch

Tabelle 2.10 listet die Termini fr die Port-Funktionen fr STP und RSTP auf.
Tabelle 2.10: Port-Funktionen bei RSTP und STP
Wichtig!

RSTP-Funktion Root-Port

STP-Funktion Root-Port

Definition Port auf jedem Nicht-Root-Switch, ber den der Switch die beste aller eingehenden BPDUs empfngt

Designierter Port

Designierter Port Port, der von allen Switch-Ports der an dasselbe Segment (Kollisions-Domne) angeschlossenen Switches die beste BPDU ausweist Switch-Port, der suboptimale BPDUs empfngt Nichtdesignierter Switch-Port, der an dasselbe Segment (Kollisions-Domne) wie ein anderer Port desselben Switchs angeschlossen ist Port, der administratorseitig abgeschaltet wurde oder aus anderen Grnden nicht einsatzfhig ist

Alternativ-Port Reserve-Port

Deaktivierter Port

2.4.4

Konvergenz bei RSTP

Dieser Abschnitt zu RSTP begann zunchst mit einer Beschreibung hnlicher Aspekte von RSTP und STP: Beide whlen unter Verwendung desselben Ansatzes einen Root-Switch und designierte Ports aus usw. Wre RSTP allerdings identisch mit STP, dann htte es sicher keinen Anlass gegeben, den neueren 802.1w-Standard einzufhren. Der wesentliche Grund fr den neuen Standard ist die Verbesserung der Konvergenzzeit. Der Spanning-Tree-Algorithmus funktioniert bei RSTP etwas anders als beim Vorgnger. So generiert und sendet unter stabilen Bedingungen jeder Switch eigene Hello-BPDUs, statt die vom Root-Switch bermittelten Hellos nur anzupassen und dann weiterzuleiten. Allerdings ist, solange sich die Topologie nicht ndert, das Ergebnis das gleiche: Ein Switch, der stets dieselben Hellos mit demselben Kostenwert und derselben Root-Switch-BID erhlt, sieht keine Veranlassung, die STP-Topologie zu ndern. Die wesentlichen nderungen beim RSA-Algorithmus greifen erst, wenn es zu nderungen im Netzwerk kommt. RSTP kennzeichnet die einzelnen Schnittstellen je nach angeschlossenem Gert anders als STP, und der Algorithmus behandelt die Schnittstellen dementsprechend unterschiedlich.

Kapitel 2 Das Spanning-Tree-Protokoll

135

Edge-Verhalten und PortFast


RSTP verbessert die Konvergenz fr Edge-Verbindungen dadurch, dass der Port umgehend in den Zustand Forwarding versetzt wird, sobald die Verbindung physisch vorhanden ist. In dieser Hinsicht behandelt RSTP Ports genau so wie die proprietre PortFast-Funktion von Cisco. Folgerichtig mssen Sie, um RSTP auf Edge-Schnittstellen von Cisco-Switches zu aktivieren, dort einfach nur PortFast konfigurieren.

Shared-Links
Was Shared-Links angeht, unterscheidet sich RSTP nicht von STP. Da allerdings die meisten Verbindungen zwischen Switches heutzutage nicht mehr ber Hubs fhren, sondern gewhnlich Point-to-Point-Vollduplexverbindungen sind, spielt dies keine Rolle.

Point-to-Point-Links
RSTP verbessert die Konvergenz ber Vollduplexverbindungen zwischen Switches, also jenen Leitungen, die bei RSTP als Point-to-Point-Links bezeichnet werden. Die erste Optimierung vonseiten RSTP besteht bei diesen Verbindungstypen darin, wie der MaxAge-Timer gehandhabt wird. STP verlangt, dass ein Switch, der keine BPDUs mehr ber seinen Root-Port erhlt, das Verstreichen des MaxAge-Intervalls abwarten muss, bevor er die Konvergenz einleitet. Standardmig dauert dies 20 Sekunden. RSTP bemerkt den Verlust des Pfads zum Root-Switch ber den Root-Port innerhalb des dreifachen Hello-Intervalls (d. h. innerhalb von sechs Sekunden, sofern der Hello-Standardwert von zwei Sekunden nicht gendert wird). Im Endergebnis erkennt RSTP den Pfadverlust also wesentlich schneller. RSTP macht einen Listening-Zustand unntig und verkrzt auch die Learning-Phase, denn es erlaubt ein aktives Erkennen des neuen Netzwerkzustandes. STP hingegen wartet in den Zustnden Listening und Learning passiv auf das Eintreffen neuer BPDUs und verarbeitet diese dann. Bei RSTP verhandeln die Switches mit ihren Nachbarn durch Versenden von RSTPNachrichten. Diese Nachrichten ermglichen es den Switches, schnell festzustellen, ob eine Schnittstelle sofort in den Zustand Forwarding umgeschaltet werden kann. In vielen Fllen dauert der Vorgang fr die gesamte RSTP-Domne nur ein oder zwei Sekunden.

136

CCNA ICND2-Prfungshandbuch

Beispiel fr beschleunigte RSTP-Konvergenz


Statt jede einzelne Nuance der RSTP-Konvergenz zu beschreiben, wollen wir ein Beispiel anfhren, dem Sie eine Menge Informationen zum Vorgang entnehmen knnen. Abbildung 2.10 zeigt ein Netzwerk, welches die RSTPKonvergenz erklrt.
Schritt 1 SW1
Root

Schritt 2 SW1
Root

SW2

Bessere RootBPDU

SW2

SW3

SW3

Veraltet, wird nicht mehr als Root-BPDU verwendet.

SW4

SW4

Abbildung 2.10: Beispiel fr die RSTP-Konvergenz, Schritte 1 und 2

Abbildung 2.10 veranschaulicht das Problem. Links in Schritt 1 sehen wir ein nicht redundantes Netzwerk. RSTP hat alle Point-to-Point-Links in den Zustand Forwarding versetzt. Um Redundanz zu ermglichen, ergnzt der Netzwerktechniker einen weiteren Point-to-Point-Link zwischen SW1 und SW4 (Schritt 2). Es muss also eine RSTP-Konvergenz erfolgen. Die erste Konvergenzphase beginnt, wenn SW4 feststellt, das er eine bessere BPDU empfngt als die von SW3 gesendete. Da sowohl die alte als auch die neue BPDU denselben Switch (SW1) ausweisen, muss die neue, ber die Direktverbindung von SW1 kommende BPDU aufgrund der niedrigeren Kosten besser sein. Unabhngig vom vorliegenden Grund muss SW4 die neue Verbindung zu SW1 in den Zustand Forwarding versetzen, da diese Schnittstelle nun der Root-Port von SW4 ist. Ab diesem Punkt weicht das RSTP-Verhalten von STP ab. RSTP auf SW4 sperrt nun vorbergehend alle anderen Link-Schnittstellen. Auf diese Weise verhindert SW4 das Entstehen von Schleifen. Danach verhandelt SW4 mit seinem Nachbarn am neuen Root-Port (SW1). Hierbei kommen RSTP-Vorschlags- und -Vereinbarungsnachrichten zum Einsatz. Am Ende kommen SW4 und SW1 berein, dass sie ihre jeweiligen Ports der neuen Leitung direkt in den Zustand Forwarding versetzen knnen. Abbildung 2.11 zeigt diesen dritten Schritt.

Kapitel 2 Das Spanning-Tree-Protokoll


Schritt 3 SW1
Verhandlungen (Vorschlge und Vereinbarungen) Fhrt zu einem sofortigen Wechsel nach Forwarding. Root

137

Schritt 4 SW1
Root

SW2

SW2

Veraltet, wird nicht mehr als Root-BPDU verwendet. Bessere RootBPDU

SW3

Zustand Blocking (verhindert Schleifen whrend der Verhandlungen) SW4 ist immer noch im Zustand Blocking.

SW3

SW4

SW4

Abbildung 2.11: Beispiel fr die RSTP-Konvergenz, Schritte 3 und 4

Warum aber knnen SW1 und SW4 ihre mit der neuen Leitung verbundenen Ports in den Zustand Forwarding versetzen, ohne dass es zu einer Schleife kommt? Ganz einfach: weil SW4 alle anderen Link-Schnittstellen sperrt. Mit anderen Worten blockiert SW4 alle Ports, die mit anderen Switches verbunden sind. Dies ist der Schlssel zum Verstndnis der RSTP-Konvergenz. Ein Switch wei, dass er seinen Root-Port wechseln muss. Er sperrt alle anderen Leitungen und verhandelt dann, um den neuen Root-Port in den Zustand Forwarding zu versetzen. Im Wesentlichen fordert SW4 SW1 auf, ihm zu vertrauen und die Weiterleitung einzuleiten, da SW4 verspricht, alle anderen Ports zu sperren, bis diese wieder sicher in den Zustand Forwarding versetzt werden knnen. Der Vorgang ist dann allerdings noch nicht abgeschlossen. In der gegenwrtigen RSTP-Topologie ist SW4 gesperrt, was in diesem Fall nicht die finale also beste Topologie ist. SW4 und SW3 wiederholen denselben Vorgang, den SW1 und SW4 gerade durchgefhrt haben. In Schritt 4 sperrt SW4 immer noch, um Schleifen zu verhindern. Allerdings leitet SW4 die neue Root-BDPU an SW3 weiter, weswegen SW3 jetzt zwei BPDUs erhlt. In diesem Beispiel nehmen wir an, dass SW3 die von SW4 erhaltene BPDU fr besser hlt als die von SW2. Deswegen fhrt SW3 denselben Vorgang aus, den SW4 gerade ausgefhrt hat. Von diesem Punkt aus sieht der weitere Verlauf wie folgt aus: 1. SW3 beschliet, seinen Root-Port basierend auf der neuen BPDU von SW4 zu ndern. 2. SW3 sperrt alle anderen Link-Schnittstellen. (Bei RSTP wird dieser Vorgang als Synchronisierung bezeichnet.)

138

CCNA ICND2-Prfungshandbuch

3. SW3 und SW4 verhandeln miteinander. 4. Infolge der Verhandlungen versetzen SW4 und SW3 ihre Schnittstellen an den jeweiligen Enden des Point-to-Point-Links in den Zustand Forwarding. 5. SW3 behlt den Status Blocking fr alle anderen Link-Schnittstellen bei, bis der nchste Schritt erfolgt ist. Abbildung 2.12 zeigt einige dieser Manahmen im links dargestellten Schritt 5. Das Ergebnis stellt dann Schritt 6 auf der rechten Seite dar.
Schritt 5 SW1
Root

Schritt 6 SW1
Alte BPDU ist besser als die von SW3.

SW2

SW2
Nicht so gut wie die BPDU von SW1. Zustand Blocking (verhindert Schleifen whrend der Verhandlungen)

SW3
Verhandlungen (Vorschlge und Vereinbarungen)

SW3

SW4

SW4

Abbildung 2.12: Beispiel fr die RSTP-Konvergenz, Schritte 5 und 6

SW3 sperrt an dieser Stelle nach wie vor seine obere Schnittstelle. Beachten Sie, dass SW2 nun zwei BPDUs empfngt, dass aber die bereits zuvor empfangene BPDU nach wie vor die bessere ist. Also tut SW2 nichts. Und schon hat RSTP die Konvergenz abgeschlossen! Zwar erstreckt sich die Erluterung des Vorgangs ber mehrere Seiten, aber in Wirklichkeit dauert er nicht lnger als eine Sekunde. Fr die CCNA-Prfungen mssen Sie die RSTP-spezifische Terminologie und das Prinzip kennen, wie RSTP die Konvergenzdauer im Vergleich zu STP optimiert.

Kapitel 2 Das Spanning-Tree-Protokoll

139

2.5

STP-Konfiguration und -Verifizierung

Standardmig nutzen Cisco-Switches STP (IEEE 802.1d). Wenn Sie mehrere Switches erwerben und diese ber Ethernet-Kabel in einer redundanten Topologie miteinander verbinden, stellt STP sicher, dass keine Schleifen entstehen. Sie mssen sich im Grunde genommen nie wieder Gedanken darber machen, ob irgendwelche Einstellungen gendert werden mssen! Zwar funktioniert STP ohne Konfiguration, doch Sie sollten trotzdem wissen, wie STP funktioniert, wie STP-bezogene show-Befehle zu interpretieren sind und wie man STP durch Anpassung verschiedener Parameter optimieren kann. So verwenden beispielsweise alle Switches standardmig dieselbe Prioritt, das heit, der Switch mit der niedrigsten MAC-Adresse wird automatisch zum Root-Switch. Es lsst sich aber auch eine niedrigere Prioritt an einem zentralen Switch konfigurieren. Damit legt der Netzwerktechniker selbst fest, welcher Switch als Root-Switch agieren soll. Im folgenden Abschnitt wollen wir diverse Optionen fr den Lastausgleich durch Einsatz mehrerer STP-Instanzen erlutern und auerdem beschreiben, wie man STP optimal konfiguriert, um mehrere Instanzen auch wirklich nutzen zu knnen. Im weiteren Verlauf des Abschnitts werden wir dann verschiedene Konfigurationsbeispiele fr STP und RSTP zeigen.

2.5.1

Mehrere STP-Instanzen

Als das IEEE das Spanning-Tree-Protokoll standardisierte, gab es noch keine VLANs. Nach der spter erfolgten Standardisierung von VLANs definierte das IEEE auch keine neuen Standards, die mehr als eine STP-Instanz zulieen auch bei mehreren VLANs nicht. Zu jener Zeit wandte ein Switch, der sich an die IEEE-Normen hielt, nur eine STP-Instanz auf alle VLANs an. Mit anderen Worten: Wenn eine Schnittstelle Daten weiterleitete, erfolgte dies in allen VLANs, und wenn sie Daten blockierte, geschah dies ebenfalls fr alle VLANs. Standardmig verwenden Cisco-Switches IEEE 802.1d und nicht RSTP (802.1w), wobei eine proprietre Funktionalitt namens PVST+ (Per-VLAN Spanning Tree Plus) zum Einsatz kommt. PVST+ (welches heute oft einfach PVST genannt wird) erstellt fr jedes VLAN eine neue STP-Instanz. Bevor wir uns also die einstellbaren STP-Parameter ansehen, bentigen Sie Grundlagenwissen zu PVST+, weil die Konfigurationseinstellungen bei jeder STPInstanz anders aussehen knnen. PVST+ stellt fr den Netzwerktechniker ein Lastausgleichstool dar. Durch nderung einige STP-Konfigurationsparameter in verschiedenen VLANs

140

CCNA ICND2-Prfungshandbuch

kann der Techniker dafr sorgen, dass Switches in verschiedenen VLANs unterschiedliche Root-Ports und designierte Ports auswhlen. Infolgedessen lassen sich dann die Daten bestimmter VLANs ber den einen Trunk weiterleiten, whrend Daten anderer VLANs ber einen anderen Trunk bertragen werden. Abbildung 2.13 zeigt das Grundkonzept: SW3 leitet Datenverkehr ungeradzahliger VLANs ber den linken Trunk (Gi0/1) und Daten geradzahliger VLANs ber den rechten Trunk (Gi0/2) weiter.
Larry Gi0/1 Gi0/2 SW2 Gi0/1

Wichtig!

SW1 Gi0/2

Sperrt VLANs mit geradzahliger ID.

Sperrt VLANs mit ungeradzahliger ID.

Archie

Gi0/1 SW3

Gi0/2

Daten in VLANs mit ungeradzahliger ID


Bob

Daten in VLANs mit geradzahliger ID

Abbildung 2.13: Lastausgleich mit PVST+

Als spter RSTP eingefhrt wurde, verfgte das IEEE ber keinen Standard zur Verwendung mehrerer STP-Instanzen. Also implementierte Cisco eine weitere proprietre Lsung zur Untersttzung eines VLANs pro RSTP-Spanning-Tree. Diese wurde von Cisco als RPVST (Rapid Per-VLAN Spanning Tree) wie auch als PVRST (Per-VLAN Rapid Spanning Tree) bezeichnet. Ungeachtet der Akronyme ist die Idee die gleiche wie bei PVST+, nur eben auf RSTP bertragen: Ein VLAN wird jeweils durch eine eigene RSTPInstanz gesteuert. Sie erhalten also nicht nur eine schnelle Konvergenz, sondern knnen auch (wie in Abbildung 2.13) einen Lastausgleich durchfhren. Im Laufe der Zeit entwickelte das IEEE dann noch eine standardisierte Option fr mehrere Spanning-Trees. Dieser IEEE-Standard (802.1s) wird hufig entweder als MST (Multiple Spanning Trees) oder als MIST (Multiple Instances of Spanning Trees) bezeichnet. MIST ermglicht die Definition mehrerer RSTP-Instanzen, denen jeweils ein VLAN zugewiesen wird. Um etwa den Lastausgleichseffekt in Abbildung 2.13 zu erzielen, wrde MIST zwei RSTP-Instanzen erstellen: je eine fr die geradzahligen und fr die ungeradzahligen VLANs. Auch bei 100 VLANs wrden die Switches in diesem Fall nur zwei RSTP-Instanzen bentigen anders als die von PVRST

Kapitel 2 Das Spanning-Tree-Protokoll

141

verwendeten 100 Instanzen. Allerdings erfordert MIST mehr Konfigurationsarbeit auf den einzelnen Switches, und zwar in erster Linie zur Definition von RSTP-Instanzen und zur Verknpfung jedes VLANs mit einer STPInstanz. Tabelle 2.11 fasst diese drei Optionen fr mehrere Spanning-Trees zusammen.
Tabelle 2.11: Vergleich zwischen drei Optionen fr mehrere Spanning-Trees
Option PVST+ PVRST MIST STP-Unter- RSTP-Unter- Konfigurations- Nur eine Instanz pro redunsttzung sttzung aufwand dantem Pfad erforderlich? Ja Nein Nein Nein Ja Ja Gering Gering Moderat Nein Nein Ja
Wichtig!

2.5.2

Konfigurationsoptionen, die sich auf die SpanningTree-Topologie auswirken

Unabhngig davon, ob Sie PVST+, PVRST oder MIST verwenden, lassen sich hauptschlich zwei Konfigurationsoptionen einsetzen, um den im Zusammenhang mit Abbildung 2.13 beschriebenen Lastausgleichseffekt zu erzielen: die BID und die Port-Kosten. Diese Optionen wirken sich wie folgt auf die VLAN-spezifische STP-Topologie aus: Die BIDs beeinflussen die Auswahl des Root-Switchs sowie bei NichtRoot-Switches die Auswahl des Root-Ports. Die (VLAN-bezogenen) STP-Kosten einer Schnittstelle wirken sich auf die Auswahl des designierten Ports in jedem LAN-Segment aus. In den folgenden Abschnitten werden wir einige ber die allgemeinen, bislang behandelten allgemeinen Konzepte hinausgehende Details zur Implementierung von STP auf Cisco-Switches nher beleuchten.

BID und die System-ID-Erweiterung


Wie bereits weiter oben erwhnt, wird die BID eines Switchs durch Kombination der zwei Byte langen Prioritt und einer sechs Byte langen MACAdresse gebildet. In der Praxis verwenden Cisco-Switches jedoch ein ausgefeilteres IEEE-konformes BID-Format, das den Priorittswert aufgliedert. Abbildung 2.14 zeigt dieses Format in detaillierter Form: Das ursprnglich 16 Bit lange Priorittsfeld enthlt nun ein 12 Bit langes Teilfeld namens System-ID-Erweiterung.

142

CCNA ICND2-Prfungshandbuch
2 Bytes 6 Bytes System-ID (MAC-Adresse)

Wichtig!

Prioritt (0 65.535)

BID (Originalformat)

Prioritt Erweiterung der System-ID (Vielfaches (enthlt gewhnlich die VLAN-ID) von 4096) 4 Bits 12 Bits

Erweiterung der System-ID (Krzung der MAC-Adresse) 6 Bytes

Erweiterung der System-ID (Krzung der MAC-Adresse)

Abbildung 2.14: System-ID-Erweiterung bei STP

Um die BID eines Switchs fr eine bestimmte VLAN-bezogene STP-Instanz zu erstellen, muss der Switch eine Basispriorittseinstellung verwenden, die ein Vielfaches von 4096 ist. (Wenn solche Vielfache von 4096 in das BinrFormat konvertiert werden, enden sie stets auf 12 binren Nullen.) Um die ersten 16 Bits der BID fr ein bestimmtes VLAN zu konstruieren, beginnt der Switch mit einer 16-Bit-Version des Basispriorittswertes bei dem die letzten zwlf Binr-Stellen Nullen sind. Nun fgt der Switch seinen Basispriorittswert zur VLAN-ID hinzu. Die Folge ist, dass die niederwertigen 12 Bits des ursprnglichen Priorittsfeldes nun die VLAN-ID angeben. Ein angenehmer Nebeneffekt der System-ID-Erweiterung besteht darin, dass PVST+ fortan fr jedes VLAN eine andere BID verwendet. Wenn also etwa ein Switch fr die VLANs 1 bis 4 konfiguriert wurde und als Standardwert fr die Basisprioritt 32.768 aufweist, lautet die STP-Standardprioritt in VLAN 1 32.769, 32.770 in VLAN 2, 32.771 in VLAN 3 usw.

VLAN-spezifische Port-Kosten
Jede Switch-Schnittstelle weist standardmig die VLAN-spezifischen PortKosten auf, die oben in Tabelle 2.6 unter der Spaltenberschrift IEEE-Kostenwert (revidierte Version) aufgefhrt sind. Bei Cisco-Switches basieren die STP-Kosten auf der tatschlichen Geschwindigkeit der Schnittstelle, das heit, wenn eine Schnittstelle eine niedrigere bertragungsgeschwindigkeit aushandelt, spiegelt sich diese im STP-Standardkostenwert wider. Handelt die Schnittstelle spter eine andere Geschwindigkeit aus, so ndert der Switch auch die Port-Kosten auf dynamische Weise. Alternativ knnen die Port-Kosten eines Switchs auch konfiguriert werden und zwar wahlweise fr alle VLANs gemeinsam oder fr nur ein VLAN gleichzeitig. Nach einer solchen Konfiguration ignoriert der Switch die ausgehandelte Geschwindigkeit der Schnittstelle und verwendet stattdessen die konfigurierten Kosten.

Kapitel 2 Das Spanning-Tree-Protokoll

143

Zusammenfassung der STP-Konfigurationsoptionen


Tabelle 2.12 fasst die Voreinstellungen fr BID und Port-Kosten zusammen und listet zudem die optionalen Konfigurationsbefehle auf, die in diesem Kapitel behandelt werden.
Tabelle 2.12: STP-Voreinstellungen und Konfigurationsoptionen
Einstellung BID Default-Einstellung Befehle zur nderung der Voreinstellung
Wichtig!

Prioritt: 32.768 + VLAN ID spanning-tree vlan vlan-id root {primary | secondary}spanning-tree System: Festkonfigurierte MAC-Adresse auf dem Switch vlan vlan-id priority priority
spanning-tree vlan vlan-id cost cost

Schnittstellen- 100 fr 10 Mbit/s, 19 fr kosten 100 Mbit/s, 4 fr 1 Gbit/s, 2 fr 10 Gbit/s (entsprechend Tabelle 2.6) PortFast nicht aktiviert

spanning-tree portfast spanning-tree bpduguard enable

BPDU Guard nicht aktiviert

Im nchsten Abschnitt zeigen wir, wie man den Betrieb von STP in einem einfachen Netzwerk untersucht und dabei diese Einstellungsoptionen ndert.

2.5.3

STP-Default-Funktion verifizieren

Die folgenden Listings wurden in einem kleinen Netzwerk mit zwei Switches erstellt, das in Abbildung 2.15 dargestellt ist. In diesem Netzwerk sollten mit den Default-Einstellungen alle Schnittstellen mit Ausnahme einer einzigen, die sich am linken Switch befindet, Daten ber die Leitungen weiterleiten, an die die Switches angeschlossen sind. Listing 2.1 zeigt verschiedene showBefehle. Auf das Listing folgend, wird erlutert, wie man mithilfe der showAusgabe die Details der STP-Topologie ermittelt, die in diesem kleinen Netzwerk erstellt wird.
Trunks Fa 0/16 Larry Fa 0/11 VLAN 3 SW1 Fa 0/17 Fa 0/17 SW2 Fa 0/16 Fa 0/12 VLAN 3

Archie

Abbildung 2.15: Netzwerk mit zwei Switches

144

CCNA ICND2-Prfungshandbuch

Listing 2.1: STP-Status bei Verwendung der STP-Default-Einstellungen


SW1#show spanning-tree vlan 3 VLAN0003 Spanning tree enabled protocol ieee Root ID Priority 32771 Address 0019.e859.5380 Cost 19 Port 16 (FastEthernet0/16) Hello Time 2 sec Max Age 20 sec Bridge ID

Forward Delay 15 sec

Priority 32771 (priority 32768 sys-id-ext 3) Address 0019.e86a.6f80 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300

Interface 000000000000000000000000000 Type Role Sts Cost Prio.Nbr ---------------- ---- --- --------- -------- -------------------------------Fa0/11 0000 FWD 19 Desg 128.11 P2p Fa0/16 0000 FWD 19 Root 000000 128.16 P2p Fa0/17 Altn BLK 19 128.17 P2p SW1#show spanning-tree root Root 0000 Hello Max Fwd Vlan Root ID 0000000 0000 Cost Time Age Dly 000000000 Root Port ---------------- -------------------- --------- ----- --- --- -----------VLAN0001 32769 0019.e859.5380 19 2 20 15 Fa0/16 VLAN0002 32770 0019.e859.5380 19 2 20 15 Fa0/16 VLAN0003 00000000000000000000 32771 0019.e859.5380 19 00 2 20 15 Fa0/16 000000 VLAN0004 32772 0019.e859.5380 19 2 20 15 Fa0/16 ! Der nchste Befehl gibt die gleichen Informationen zum lokalen Switch wie ! der Befehl show spanning-tree vlan 3an, jedoch in einem krzeren Format. SW1#show span vlan 3 bridge Hello Max Fwd Vlan Bridge ID Time Age Dly Protocol ---------------- --------------------------------- ----- --- --- -------VLAN0003 000000000000000000000000000000000 32771 (32768, 3) 0019.e86a.6f80 2 20 15 ieee

Listing 2.1 beginnt mit der Ausgabe des Befehls show spanning-tree vlan 3 auf SW1. Dieser Befehl listet zunchst drei grere Nachrichtengruppen auf: eine Gruppe mit Informationen zum Root-Switch, eine zweite zum lokalen Switch und eine dritte mit Angaben zu Schnittstellenfunktion und -status. Durch Vergleich der hervorgehobenen Root-Switch-ID und der BID in den ersten beiden Nachrichtengruppen stellen Sie schnell fest, ob der lokale Switch Root-Switch ist in diesem Fall wren BID und Root-Switch-ID identisch. In unserem Beispiel ist dies jedoch nicht der Fall.

Kapitel 2 Das Spanning-Tree-Protokoll

145

Die dritte Nachrichtengruppe in der Ausgabe von show spanning-tree vlan 3 bezeichnet einen Teil der STP-Topologie in diesem Beispiel, denn sie listet alle Schnittstellen in diesem VLAN (d. h. Access-Schnittstellen wie auch Trunks, die das VLAN unter Umstnden untersttzen knnten), ihre STPPort-Funktionen und die STP-Port-Zustnde auf. So ermittelt SW1 beispielsweise, dass Fa0/11 die Funktion eines designierten Ports ausbt, weil kein andere Switch an diesem Port danach strebt, DP zu werden (erkennbar an der Funktionsangabe desg in der Ausgabe). Aus diesem Grund muss SW1 die Hello-BPDUs mit den niedrigsten Kosten in diesem Segment versenden. Also versetzt SW1 Fa0/11 in den Zustand Forwarding. Zwar zeigt die Ausgabe, dass SW1 die Schnittstelle Fa0/16 als Root-Port ausgewhlt hat, aber welche Logik dahinter steht, ist aus der Befehlsausgabe nicht offensichtlich. SW1 empfngt Hello-BPDUs von SW2 ber die Ports Fa0/16 und Fa0/17. Da Fa0/16 und Fa0/17 standardmig dieselben PortKosten aufweisen (19), sind die Pfade von SW1 zum Root-Switch ber beide Schnittstellen gleichwertig. Wenn es bei den Kosten zur Verbindungsaufnahme mit dem Root-Switch auf einem Switch zu einem Gleichstand kommt, verwendet dieser zuerst die Port-Prioritt der Schnittstellen als Entscheidungsgrundlage. Sind diese Werte ebenfalls gleich, dann nutzt der Switch die niedrigere interne Schnittstellennummer. Die Schnittstellenprioritt und die interne Port-Nummer sind in Listing 2.1 unter der berschrift Prio.Nbr aufgefhrt. In diesem Fall verwendet SW1 den Standardpriorittswert 128 fr alle Schnittstellen, das heit, die Schnittstelle mit der niedrigsten Port-Nummer Fa0/16 wird zum Root-Port. Fa0/16 wird also in den Zustand Forwarding versetzt. Beachten Sie auch, dass wie aus der Befehlsausgabe hervorgeht Fa0/17 die Funktion des Alternativ-Ports bernommen hat (dies zeigt die Abkrzung Altn in der Ausgabe). Die Funktion des Alternativ-Ports ist zwar eigentlich ein RSTP-Konzept, aber auch die Cisco-Implementierung von 802.1dSTP verwendet es, und aus diesem Grund ist es in der show-Ausgabe aufgefhrt. Allerdings versetzt SW1 diesen Port in den Zustand Blocking, da es sich weder um einen Root- noch um einen designierten Port handelt. Der nchste Befehl im Beispiel show spanning-tree root gibt die BID des Root-Switchs in den einzelnen VLANs an. Beachten Sie, dass beide Switches ausschlielich die Voreinstellungen verwenden, SW2 wird also zum RootSwitch in allen vier vorhandene VLANs. Dieser Befehl listet auch den Priorittsabschnitt der BID separat auf; er zeigt die verschiedenen Priorittswerte 32.769, 32.770, 32.771 und 32.772, die auf der System-ID-Erweiterung basieren, die wir bereits erklrt haben. Der letzte Befehl im Beispiel lautet show spanning-tree vlan 3 bridge id. Er gibt lediglich Informationen zur BID des lokalen Switchs in VLAN 3 an.

146

CCNA ICND2-Prfungshandbuch

2.5.4

STP-Port-Kosten und Switch-Prioritt konfigurieren

Listing 2.2 zeigt, wie man die STP-Topologie durch Konfiguration von PortKosten und Switch-Prioritt beeinflussen kann. Zunchst werden die PortKosten fr Fa0/17 auf SW1 gesenkt, wonach der Root-Pfad auf SW1 ber Fa0/17 besser ist als der Pfad ber Fa0/16; folgerichtig ndert sich der RootPort von SW1. Danach zeigt das Listing, wie SW1 zum Root-Switch gemacht wird, indem die Prioritt von SW1 gendert wird:
Listing 2.2: Port-Kosten und Prioritt manipulieren
SW1#debug spanning-tree events Spanning Tree event debugging is on SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#interface Fa0/17 SW1(config-if)#spanning-tree vlan 3 cost 2 00:45:39: STP: 0000000000000000000000000000000000000 VLAN0003 new root port Fa0/17, cost 2 00:45:39: STP: VLAN0003 0000000000000000000 00000 Fa0/17 -> listening 00:45:39: STP: VLAN0003 sent Topology Change Notice on Fa0/17 00:45:39: STP: VLAN0003 Fa0/16 -> blocking 00:45:54: STP: VLAN0003 000000000000000000 00000 Fa0/17 -> learning 00:46:09: STP: VLAN0003 sent Topology Change Notice on Fa0/17 00:46:09: STP: VLAN0003 00000000000000000000 00000 Fa0/17 -> forwarding SW1(config-if)#^Z SW1#show spanning-tree vlan 3 VLAN0003 Spanning tree enabled Root ID Priority Address Cost Port Hello Time Bridge ID

protocol ieee 32771 0019.e859.5380 2 17 (FastEthernet0/17) 2 sec Max Age 20 sec

Forward Delay 15 sec

Priority 32771 (priority 32768 sys-id-ext 3) Address 0019.e86a.6f80 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 15

Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------Fa0/11 Desg FWD 19 128.11 P2p Fa0/16 Altn BLK 19 128.16 P2p Fa0/17 000000000000000000000000000 Root FWD 2 128.17 P2p SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z.

Kapitel 2 Das Spanning-Tree-Protokoll


Listing 2.2: Port-Kosten und Prioritt manipulieren (Forts.)
SW1(config)#spanning-tree vlan 3 root primary 00:46:58: setting bridge id (which=1) prio 24579 prio cfg 24576 sysid 3 (on) id 6003.0019.e86a.6f80 00:46:58: STP: 00000000000000000000000000000000000000 VLAN0003 we are the spanning tree root 00:46:58: STP: VLAN0003 Fa0/16 -> listening 00:46:58: STP: VLAN0003 Topology Change rcvd on Fa0/16 00:47:13: STP: VLAN0003 Fa0/16 -> learning 00:47:28: STP: VLAN0003 Fa0/16 -> forwarding

147

Dieses Beispiel beginnt mit dem Befehl debug spanning-tree events auf SW1. Der Befehl weist den Switch an, stets informelle Log-Meldungen an die Konsole zu senden, wenn STP nderungen an der Funktion oder am Zustand einer Schnittstelle vornimmt. Diese Meldungen werden im Beispiel infolge der Befehle angezeigt, die weiter unten eingegeben werden. Als Nchstes werden die Port-Kosten der SW1-Schnittstelle Fa0/17 gendert jedoch nur in VLAN 3. Hierzu wird der Befehl spanning-tree vlan 3 cost 2 im Konfigurationsmodus fr die Schnittstelle Fa0/17 verwendet. Unmittelbar darauf zeigt SW1 die ersten aussagekrftigen Debug-Meldungen an. Diese Meldungen besagen im Wesentlichen, dass Fa0/17 nun zum Root-Port von SW1 geworden ist, Fa0/16 sofort in den Zustand Blocking umgeschaltet wird und fr Fa0/17 der bergangsprozess in den Zustand Forwarding (ber die Zustnde Listening und Learning) gestartet hat. Der der Voreinstellung fr den Forward-Delay-Wert entsprechende Zeitraum von 15 Sekunden wird jeweils fr die Listening- und Learning-Phase eingehalten (vgl. Hervorhebung im Listing).

ANMERKUNG
Bei den meisten Konfigurationsbefehlen zur Festlegung von STP-Parametern kann der Parameter vlan weggelassen werden; in diesem Fall wird die Einstellung fr alle VLANs gendert. So wrde etwa der Befehl spanningtree cost 2 die STP-Kosten fr eine Schnittstelle fr alle VLANs auf 2 setzen. Nach der ersten Gruppe mit Debug-Meldungen listet die Ausgabe von show spanning-tree die Zustnde Blocking fr Fa0/16 und Forwarding fr Fa0/17 auf. Der Kostenwert zum Root-Switch betrgt nur mehr 2 basierend auf den Kosten der Schnittstelle Fa0/17. Die nchste nderung findet statt, wenn der Befehl spanning-tree vlan 3 root primary auf SW1 abgesetzt wird. Dieser Befehl setzt die Prioritt auf 24.576, das heit, VLAN 3 auf SW1 erhlt den Priorittswert 24.576 + 3 = 24.579.

148

CCNA ICND2-Prfungshandbuch

Infolgedessen wird SW1 zum Root-Switch die nachfolgenden Debug-Meldungen zeigen dies. Der Befehl spanning-tree vlan vlan-id root primary weist einen Switch an, einen bestimmten Priorittswert nur in diesem VLAN zu verwenden. Dabei whlt der Switch einen Wert, der dazu fhrt, dass der Switch zum RootSwitch im betreffenden VLAN wird. Zu diesem Zweck legt der Befehl die Basisprioritt fest, also den Priorittswert, der zur VLAN-ID hinzuaddiert wird, um die Prioritt des Switchs zu berechnen. Der zugewiesene Wert ist niedriger als die aktuelle Basisprioritt des Root-Switchs. Dieser Befehl weist der Basisprioritt die folgenden Werte zu:
Wichtig!

24.576, wenn der aktuelle Root-Switch eine Basisprioritt grer als 24.576 hat 4096 weniger als die Basisprioritt des aktuellen Root-Switchs, wenn dieser eine Basisprioritt kleiner als oder gleich 24.576 hat Der Befehl spanning-tree vlan vlan-id root secondary weist einen Switch an, einen Basispriorittswert zu verwenden, bei dem der lokale Switch zum Root-Switch werden kann, sofern der primre Root-Switch ausfllt. Dieser Befehl legt unabhngig vom Priorittswert des aktuellen Root-Switchs 28.672 als Basisprioritt des Switchs fest. Beachten Sie, dass die Prioritt mit dem globalen Konfigurationsbefehl spanning-tree vlan vlan-id priority value explizit bestimmt werden kann. Der Befehl legt die Basisprioritt des Switchs fest. Allerdings werden, weil viele LAN-Designs auf einen bekannten Root-Switch mit einer Reserveeinheit angewiesen sind, die anderen Befehle gewhnlich vorgezogen.

2.5.5

PortFast und BPDU Guard konfigurieren

Die Funktionalitten PortFast und BPDU Guard lassen sich fr jede Schnittstelle relativ leicht konfigurieren. Zur PortFast-Konfiguration verwenden Sie einfach den Schnittstellenbefehl spanning-tree portfast. Wenn Sie auerdem BPDU Guard aktivieren wollen, so fgen Sie den Schnittstellenbefehl spanning-tree bpduguard enable hinzu.

2.5.6

EtherChannel konfigurieren

Die beiden Switches verfgen ber parallele Ethernet-Verbindungen, fr die EtherChannel konfiguriert werden knnte. Wenn Sie dies tun, werden die Schnittstellen durch STP nicht gesperrt, weil STP beide Schnittstellen auf beiden Switches als einen einzigen Link betrachtet. Listing 2.3 zeigt die Konfiguration von SW1 und die show-Befehle fr den neuen EtherChannel:

Kapitel 2 Das Spanning-Tree-Protokoll


Listing 2.3: EtherChannel konfigurieren und berwachen
SW1#configure terminal Enter configuration commands, one per line. SW1(config)#interface fa 0/16 SW1(config-if)#channel-group 1 mode on SW1(config)#int fa 0/17 SW1(config-if)#channel-group 1 mode on SW1(config-if)#^Z 00:32:27: STP: VLAN0001 Po1 -> learning 000 00:32:42: STP: VLAN0001 Po1 -> forwarding SW1#show spanning-tree vlan 3 VLAN0003 Spanning tree enabled protocol ieee Root ID Priority 28675 Address 0019.e859.5380 Cost 12 Port 000000000000000000000000000000 72 (Port-channel1) Hello Time 2 sec Max Age 20 sec Bridge ID End with CNTL/Z.

149

Forward Delay 15 sec

Priority 28675 (priority 28672 sys-id-ext 3) Address 0019.e86a.6f80 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300

Interface Role Sts Cost Prio.Nbr Type ---------------- ---- --- --------- -------- -------------------------------Fa0/11 Desg FWD 19 128.11 P2p Po1 Root FWD 12 128.72 P2p SW1#show etherchannel 1 summary Flags: D - down P - in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 1 Number of aggregators: 1 Group Port-channel Protocol Ports ------+-------------+-----------+-----------------------------------------1 Po1(SU) Fa0/16(P) Fa0/17(P)

150

CCNA ICND2-Prfungshandbuch

Auf 2960-Switches kann jeder Port Teil eines EtherChannels sein, und jeder EtherChannel kann bis zu acht Ports umfassen. Insofern sind EtherChannelBefehle Schnittstellenbefehle. Der Schnittstellenbefehl channel-group 1 mode on aktiviert EtherChannel jeweils auf den Schnittstellen Fa0/16 und Fa0/17. Beide Switches mssen sich ber die Nummer des EtherChannels (in diesem Fall 1) einig sein, das heit, die EtherChannel-Konfiguration von SW2 ist identisch mit der von SW1. Der Befehl channel-group gestattet die Konfiguration einer Schnittstelle dahingehend, dass sie entweder stets Bestandteil eines EtherChannels ist (hierzu wird das Schlsselwort on verwendet) oder aber mit dem anderen Switch dynamisch verhandelt wird (dies wird ber die Schlsselwrter auto oder desirable erreicht). Wenn das Schlsselwort on auf SW1 verwendet wird und SW2 aus irgendeinem Grund nicht korrekt fr EtherChannel konfiguriert wurde, knnen die Switches keine Daten ber die Schnittstellen weiterleiten. Alternativ kann der EtherChannel-Konfigurationsbefehl channelgroup auf allen Switches mit den Parametern auto oder desirable anstelle von on angegeben werden. Bei diesen Parametern handeln die Switches aus, ob EtherChannel verwendet wird oder nicht. Knnen sich die Switches einigen, dann wird ein EtherChannel gebildet. Andernfalls knnen die Ports auch ohne einen gebildeten EtherChannel verwendet werden, wobei STP dann einige Schnittstellen blockiert. Die Verwendung der Parameter auto und desirable kann jedoch trgerisch sein. Wenn Sie auto auf beiden Switches konfigurieren, wird der EtherChannel niemals aktiv. Das Schlsselwort auto weist den Switch nmlich an, darauf zu warten, dass der andere Switch die Verhandlungen einleitet. Solange auf einem der beiden Switches on oder desirable konfiguriert ist, kann der EtherChannel erfolgreich ausgehandelt werden. Im verbleibenden Teil von Listing 2.3 sehen Sie verschiedene Verweise auf
port-channel oder Po. Da STP den EtherChannel als eine einzige Verbindung

behandelt, bentigt der Switch eine Mglichkeit, den gesamten EtherChannel darzustellen. Die IOS-Software des 2960 verwendet den Begriff Po als Kurzform von port-channel, d. h. als Bezeichnung fr den EtherChannel. (EtherChannel wird manchmal auch als Port-Channel bezeichnet.) So verweist der Befehl show etherchannel 1 summary gegen Ende des Listings auf Po1, also auf den Port-Channel oder EtherChannel 1.

Kapitel 2 Das Spanning-Tree-Protokoll

151

2.5.7

RSTP konfigurieren

Wenn man die oben beschriebenen STP-Konfigurationsoptionen vollstndig begriffen hat, ist die Konfiguration und Verifizierung von RSTP ohne weitere Hhepunkte. Jeder Switch bentigt genau einen einzigen globalen Befehl: spanning-tree mode rapid-pvst. Wie Sie dem Befehl entnehmen knnen, wird hier nicht nur RSTP aktiviert, sondern auch PVRST, das heit, es wird eine RSTP-Instanz fr alle definierten VLANs ausgefhrt. Die brigen in diesem Abschnitt behandelten Konfigurationsbefehle gelten unverndert auch fr RSTP und PVRST. Es wirken sich jeweils dieselben Befehle auf die BID, die Port-Kosten und EtherChannels aus. Es funktioniert sogar der Schnittstellenbefehl spanning-tree portfast, der aus der Schnittstelle technisch gesehen eine RSTP-Edge-Schnittstelle (statt eines Link-Ports) macht und sie dann sofort in den Zustand Forwarding versetzt. Listing 2.4 zeigt exemplarisch, wie die Migration von STP und PVST+ auf RSTP und PVRST vonstatten geht und wie man feststellt, ob ein Switch RSTP oder STP verwendet:
Listing 2.4: RSTP und PVRST konfigurieren und verifizieren
SW1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#spanning-tree mode ? mst Multiple spanning tree mode pvst Per-Vlan spanning tree mode rapid-pvst Per-Vlan rapid spanning tree mode ! Die nchste Zeile konfiguriert an diesem Switch die Verwendung von RSTP und PVRST. ! SW1(config)#spanning-tree mode rapid-pvst SW1(config)#^Z ! Der hervorgehebene Text "protocol RSTP" bedeutet, dass dieser Switch RSTP und nicht IEEE-STP verwendet. SW1#show spanning-tree vlan 4 VLAN0004 Spanning tree enabled Root ID Priority Address Cost Port Hello Time

0000000000000 protocol rstp 32772 0019.e859.5380 19 16 (FastEthernet0/16) 2 sec Max Age 20 sec

Forward Delay 15 sec

152

CCNA ICND2-Prfungshandbuch

Listing 2.4: RSTP und PVRST konfigurieren und verifizieren (Forts.)


Bridge ID Priority 32772 (priority 32768 sys-id-ext 4) Address 0019.e86a.6f80 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Role Sts Cost ---- --- --------Root FWD 19 Altn BLK 19 Prio.Nbr Type -------- -------------------------------128.16 P2p Peer(STP) 128.17 P2p Peer(STP)

Interface ---------------Fa0/16 Fa0/17

Nehmen Sie sich bitte ein wenig Zeit, um die im Listing hervorgehobene Phrase protocol rstp mit der Ausgabe frherer Beispiele fr den Befehl show spanning-tree zu vergleichen. Die frheren Beispiele verwendeten nmlich alle die Default-Einstellungen fr STP und PVST+, das heit, es wurde protocol ieee angefhrt, was auf den ursprnglichen STP-Standard 802.1d des IEEE verwies.

2.6

Behebung von STP-Problemen

In den letzten Abschnitten wollen wir uns mit der Frage befassen, wie man das bislang in diesem Kapitel vermittelte Wissen auf neue Szenarios anwendet. Der nun folgende Abschnitt soll Sie nicht nur darauf vorbereiten, STPProbleme in echten Netzwerken zu beheben, sondern vor allem darauf, die STP-Fragen in den CCNA-Prfungen richtig zu beantworten. (Wir werden bis zum Ende des Kapitels keine neuen Informationen zu STP mehr kennenlernen.) STP-Fragen bereiten vielen Prfungsteilnehmern Kopfschmerzen. Ein Grund dafr, dass solche Fragen vielen Prflingen mehr Probleme als andere bereiten, besteht darin, dass sie in der Praxis noch niemals Probleme mit STP beheben mussten. STP luft in kleinen und mittleren Netzwerken von Hause aus und bei Verwendung der Konfigurationsvoreinstellungen auch einwandfrei, weswegen Netzwerktechniker nur selten mit entsprechenden Schwierigkeiten konfrontiert werden. Hinzu kommt, dass die in diesem Kapitel behandelten Theorien und Befehle zwar zunchst einmal verstndlich sind, aber ihre Anwendung zur Behandlung eines konkreten Problems in der Prfung Zeit bentigt. Dieser Abschnitt zeigt Ihnen Schritte zur Analyse und Bearbeitung verschiedener STP-Aufgaben in der Prfung auf. Einige Prfungsfragen verlangen beispielsweise, dass Sie ermitteln, welche Schnittstellen weiterleiten oder blockieren, whrend andere von Ihnen wissen wollen, welcher Switch der

Kapitel 2 Das Spanning-Tree-Protokoll

153

Root-Switch ist, welche Ports Root-Ports und welche designierte Ports. Natrlich gibt es auch andere Fragevarianten. Unabhngig vom vorliegenden Aufgabentyp lsst sich STP mithilfe der drei folgenden Schritte in jedem LAN analysieren, was dann auch die Beantwortung aller mglichen STPbezogenen Fragen in der Prfung gestattet: 1. Sie ermitteln den Root-Switch. 2. Sie ermitteln fr jeden Nicht-Root-Switch den Root-Port und die Kosten zum Erreichen des Root-Switchs ber diesen Root-Port. 3. Sie ermitteln fr jedes Segment den designierten Port und die Kosten, die von diesem designierten Port fr das betreffende Segment ausgewiesen sind. Die folgenden Abschnitte zeigen die einzelnen Schritte und enthalten auch Tipps, um die richtigen Antworten auf die Examensfragen schnell zu finden.
Wichtig!

2.6.1

Root-Switch bestimmen

Die Bestimmung des STP-Root-Switchs ist recht einfach, wenn Sie die BIDs aller Switches kennen: Whlen Sie einfach den niedrigsten Wert aus. Wenn in der Aufgabe Prioritt und MAC-Adresse separat aufgefhrt sind, wie es bei der Ausgabe von show-Befehlen die Regel ist, whlen Sie den Switch mit der niedrigsten Prioritt oder bei Gleichstand den mit der niedrigeren MACAdresse aus. Wie in der Praxis kann, wenn eine Aufgabe von Ihnen verlangt, show-Befehle auf mehreren Switches abzusetzen, um den Root-Switch zu ermitteln, eine Strategie zur Beantwortung der Frage durchaus hilfreich sein. Denken Sie zunchst daran, dass viele Varianten des Befehls show spanning-tree im ersten Teil ihrer Ausgabe die Root-BID auffhren, wobei die Prioritt in der ersten und die MAC-Adresse in der zweiten angegeben sind; die BID des lokalen Switchs taucht dann im nachfolgenden Abschnitt auf (vgl. die Hervorhebungen in Listing 2.1). Bedenken Sie zudem, dass Cisco-Switches standardmig PVST+ verwenden, das heit, Sie mssen sorgfltig nach STP-Details zum korrekten VLAN suchen. Die folgende Liste skizziert unter Bercksichtigung dieser Tatsachen eine empfehlenswerte Strategie: 1. Whlen Sie einen Switch aus, mit dem Sie anfangen wollen, und ermitteln Sie die BIDs des Root-Switchs und des lokalen Switchs im fraglichen VLAN mit dem EXEC-Befehl show spanning-tree vlan vlan-id. 2. Sind Root- und lokale BID gleich, dann ist der lokale Switch der RootSwitch.

154

CCNA ICND2-Prfungshandbuch

3. Wenn Root-BID und die BID des lokalen Switchs nicht gleich sind, gehen Sie wie folgt vor: a) Ermitteln Sie den Root-Port am lokalen Switch (in der Ausgabe von show spanning-tree enthalten). b) Ermitteln Sie mithilfe des CDP-Protokolls oder einer vorhandenen Dokumentation, welcher Switch sich am anderen Ende der in Schritt 3a ermittelten Schnittstelle befindet. c) Melden Sie sich am Switch am anderen Ende der RP-Schnittstelle an und wiederholen Sie den Vorgang beginnend mit Schritt 1. Listing 2.5 zeigt die Ausgabe des Befehls show spanning-tree vlan 1. Auch wenn Sie die Topologie des LAN nicht kennen, sollten Sie sich nun etwas Zeit nehmen, um diese Strategie anhand der Beispielausgabe auszuprobieren und Ihre Gedankengnge dann mit den Erluterungen zu vergleichen, die auf das Beispiel folgen.
Listing 2.5: Root-Switch bestimmen
SW2#show spanning-tree vlan 1 VLAN0001 Spanning tree enabled protocol ieee Root ID Priority 32769 Address 000a.b7dc.b780 Cost 19 Port 1 (FastEthernet0/1) Hello Time 2 sec Max Age 20 sec Bridge ID

Forward Delay 15 sec

Priority 32769 (priority 32768 sys-id-ext 1) Address 0011.92b0.f500 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Type -----------------------------P2p Shr Shr

Interface Role Sts Cost Prio.Nbr ---------------- ---- --- --------- -------Fa0/1 000000000000000000000 FWD 19 Root 128.1 Fa0/19 Desg FWD 100 128.19 Fa0/20 Desg FWD 100 128.20 SW2#show spanning-tree vlan 1 bridge id VLAN0001 8001.0011.92b0.f500

Die hervorgehobenen Teile des Listings verweisen auf die BID des RootSwitchs (Prioritt und Adresse) sowie die sich davon unterscheidende BID von SW2. Da ein Unterschied vorliegt, sollte der nchste Schritt darin bestehen, den Root-Port zu ermitteln, der in der Befehlsausgabe an zwei verschiedenen Stellen aufgefhrt ist (Fa0/1). Der nachfolgende Schritt wrde dann

Kapitel 2 Das Spanning-Tree-Protokoll

155

darin bestehen, den Vorgang auf dem Switch zu wiederholen, der mit der Schnittstelle Fa0/1 von SW2 verbunden ist. Aus dem Listing geht dieser Switch nicht hervor.

2.6.2

Root-Port auf Nicht-Root-Switches bestimmen

Jeder Nicht-Root-Switch hat genau einen Root-Port. (Root-Switches hingegen haben keinen Root-Port.) Um den Root-Port auszuwhlen, wertet ein Switch die eingehenden Hello-BPDUs aus. Fr jedes empfangene Hello addiert der Switch die in der BPDU aufgefhrten Kosten zu den Kosten des Ports hinzu, auf dem das Hello empfangen wurde. Die Auswahl erfolgt dann nach den niedrigsten Kosten. Liegt ein Gleichstand vor, so wird die Schnittstelle mit der niedrigsten Port-Prioritt und gegebenenfalls der niedrigsten internen Port-Nummer ausgewhlt. Der voranstehende Satz beschreibt zwar, wie ein Nicht-Root-Switch seinen Root-Port auswhlt, aber wenn in einer Prfungsaufgabe Informationen zum Root-Switch und zu den Schnittstellenkosten angegeben werden, knnen Sie die Antwort mglicherweise schneller liefern, wenn Sie einen anderen Ansatz verfolgen. Betrachten Sie etwa die folgende Frage, deren Gegenstand das in Abbildung 2.16 gezeigte Netzwerk ist: Im gezeigten geswitchten Netzwerk sind alle Switches und Segmente in Betrieb, wobei STP in VLAN 1 aktiviert ist. Als Root-Switch wurde SW1 ausgewhlt. Die Schnittstelle Fa0/1 von SW2 weist einen Kostenwert von 20 aus, whrend bei allen brigen Ports die Standardkostenwerte vorhanden sind. Bestimmen Sie den Root-Port auf SW4.
Root-Switch

SW1 Fa0/2 Fa0/4 Fa0/3

Fa0/1

PortKosten 20 Fa0/3 Fa0/2

Fa0/1

SW2 Fa0/4

SW3 Fa0/4

Fa0/1 Fa0/2 SW4 Fa0/3

Abbildung 2.16: STP-Analyse, Beispiel 1

156

CCNA ICND2-Prfungshandbuch

Eine Mglichkeit, dieses spezielle Problem zu beheben, besteht nun darin, die im ersten Absatz dieses Abschnitts zusammengefassten Konzepte anzuwenden. Sie finden die Lsung aber vielleicht ein bisschen schneller, wenn Sie ausgehend von einem Nicht-Root-Switch die folgende Vorgehensweise whlen: 1. Ermitteln Sie alle mglichen Pfade, ber die ein vom Nicht-Root-Switch gesendeter Frame den Root-Switch erreichen kann. 2. Zhlen Sie fr jeden in Schritt 1 ermittelten Pfad die Kosten aller Ausgangsschnittstellen in diesem Pfad zusammen. 3. Die niedrigsten ermittelten Kosten sind die Kosten zum Erreichen des Root-Switchs, und die zugehrige Ausgangsschnittstelle ist der Root-Port des Switchs. 4. Kommt es bei den Kosten zu einem Gleichstand, dann verwenden Sie die Prioritt und sofern erforderlich die niedrigste Port-Nummer als Entscheidungsgrundlage. Tabelle 2.13 zeigt die fr die Schritte 1 und 2 dieses Vorgangs erforderlichen Berechnungen. Sie listet die Pfade und die zugehrigen Kosten fr alle Pfade auf, ber die der Root-Switch erreicht werden kann. In diesem Netzwerk gibt es von SW4 ausgehend fnf mgliche Pfade zum Root-Switch. Die Spalte Kosten gibt die Schnittstellenkosten in derselben Reihenfolge wie in der ersten Spalte an und berechnet die Gesamtkosten.
Tabelle 2.13: Berechnung der Kosten zur Ermittlung des Root-Ports von SW4
Physischer Pfad (Ausgabeschnittstellen) SW4 (Fa0/2) > SW2 (Fa0/1) > SW1 SW4 (Fa0/3) > SW3 (Fa0/1) > SW1 SW4 (Fa0/1) > SW1 SW4 (Fa0/2) > SW2 (Fa0/3) > SW3 (Fa0/1) > SW1 SW4 (Fa0/3) > SW3 (Fa0/2) > SW2 (Fa0/1) > SW1 Kosten 19 + 20 = 39 19 + 19 = 38 19 = 19 19 + 19 + 19 = 57 19 + 19 + 20 = 58

Untersuchen Sie nur um sicherzustellen, dass Ihnen der Inhalt der Tabelle klar geworden ist einmal den physischen Pfad SW4 (Fa0/2) > SW2 (Fa0/1) > SW1. Bestandteile dieses Pfads sind die Ausgangsschnittstellen Fa0/2 (Standardkostenwert 19) an SW4 und Fa0/1 (konfigurierter Kostenwert 20) an SW2, was einen Gesamtkostenwert von 39 ergibt. Sie werden auch bemerkt haben, bei welchen Schnittstellen die Kosten bei diesem Vorgang ignoriert werden. Wenn wir dasselbe Beispiel zugrunde legen, wrde der von SW4 zum Root-Switch gesendete Frame von SW2 ber

Kapitel 2 Das Spanning-Tree-Protokoll

157

dessen Schnittstelle Fa0/4 empfangen und dann an die Schnittstelle Fa0/2 von SW1 weitergeleitet. Die Kosten dieser Schnittstellen blieben unbercksichtigt. In diesem Fall wre der Root-Port von SW4 die Schnittstelle Fa0/1, weil der Pfad mit den niedrigsten Kosten (19) bei dieser Schnittstelle beginnt. Hten Sie sich davor, voreilig Annahmen bei Aufgaben zu treffen, die von Ihnen die Ermittlung des Root-Ports eines Switchs verlangen. In diesem Fall etwa scheint es naheliegend, dass der Root-Port von SW4 die Schnittstelle Fa0/1 wre, denn diese ist ja direkt mit dem Root-Switch verbunden. Wenn allerdings fr die Schnittstellen Fa0/3 von SW4 und Fa0/1 von SW3 ein Kostenwert von jeweils 4 konfiguriert worden wre, htte der Pfad SW4 (Fa0/3) > SW3 (Fa0/1) > SW1 einen Gesamtkostenwert von 8 in diesem Fall wre Fa0/3 der Root-Port von SW4. Zwar stellt sich der direkte Pfad in der Abbildung optisch besser dar, aber Sie drfen nicht vergessen, dass der entscheidende Punkt die Gesamtkosten sind.

2.6.3

Designierten Port fr LAN-Segmente bestimmen

Jedes LAN-Segment verfgt ber einen einzelnen Switch, der mit einem designierten Port in diesem Segment agiert. In Segmenten, in denen ein Switch an ein Gert angeschlossen ist, das STP berhaupt nicht verwendet beispielsweise Segmente, die einen Switch mit einem PC oder einem Router verbinden , wird der Switch-Port als designierter Port ausgewhlt, weil er das einzige Gert ist, das Hellos in das Segment sendet. Bei Segmenten, die mehrere Switches verbinden, ist der Aufwand zur Ermittlung des designierten Ports hingegen etwas hher. Ein designierter Port fr ein Segment ist wie folgt definiert: Die Switch-Schnittstelle, die die Hello-BPDU zu den niedrigsten Kosten in das Segment weiterleitet, ist der designierte Port. Im Falle eines Gleichstandes wird derjenige der Hellos sendenden Switches ausgewhlt, der bei gleichem Kostenwert die niedrigere BID aufweist. Auch hier beschreibt die formale Definition, wie sich STP verhlt. Sie knnen das Prinzip auch auf jede andere denkbare STP-Aufgabe anwenden. Wenn es Ihnen in der Prfung gelungen ist, die Root-Ports der Nicht-RootSwitches zu ermitteln, und Sie sich die Pfadkosten fr die einzelnen Switches notiert haben (wie beispielsweise in Tabelle 2.13 gezeigt), dann knnen Sie den designierten Port wie folgt ermitteln: 1. Bei Switches, die an dasselbe LAN-Segment angeschlossen sind, ist der Switch mit den niedrigsten Kosten fr das Erreichen des Root-Switchs der designierte Port des Segments.

158

CCNA ICND2-Prfungshandbuch

2. Im Falle eines Gleichstandes wird derjenige Switch ausgewhlt, der bei gleichem Kostenwert die niedrigere BID aufweist. Betrachten Sie Abbildung 2.17. Die Abbildung zeigt dasselbe geswitchte Netzwerk wie Abbildung 2.16, hier jedoch mit gekennzeichneten Root- und designierten Ports sowie fr jeden Switch mit den niedrigsten Kosten fr das Erreichen des Root-Switchs ber den jeweiligen Root-Port.
Root-Switch

SW1 Fa0/2 BID: 30000:0200.2222.2222 RP Kosten fr das Erreichen des Root-Switchs: 20 Fa0/1

DP
PortKosten 20 Fa0/3

Fa0/4

Fa0/3

DP RP
Fa0/1 Fa0/2

DP

BID: 32768:0200.3333.3333 Kosten fr das Erreichen des Root-Switchs: 19

SW2 Fa0/4

DP DP RP
Fa0/1 Fa0/2 Fa0/3

SW3 Fa0/4

DP
SW4

BID: 32768:0200.4444.4444 Kosten fr das Erreichen des Root-Switchs: 19

Abbildung 2.17: Designierte Ports auswhlen

Konzentrieren wir uns zunchst auf die Segmente, an die die Nicht-RootSwitches angeschlossen sind. Im Segment SW2-SW4 gewinnt SW4 dank des Kostenwertes von 19 fr den Pfad (der beste Pfad von SW2 weist den Kostenwert 20 auf). Aus demselben Grund wird SW3 zum designierten Port im Segment SW2-SW3. Beim Segment SW3-SW4 kommt es kostenseitig zwischen SW3 und SW4 zum Gleichstand. Die Abbildung listet die BIDs der Nicht-Root-Switches auf; diesen knnen Sie entnehmen, dass die BID von SW3 niedriger ist. Also wird SW3 zum designierten Port auf diesem Segment. Beachten Sie auerdem, dass der Root-Switch (SW1) zum designierten Port aller seiner Segmente wird, denn Root-Switches weisen stets Hellos mit dem Kostenfaktor 0 aus, whrend die berechneten Kosten aller anderen Switches bei 1 liegen mssen (1 ist der kleinste zulssige Port-Kostenwert). Fr die Prfungen sollten Sie in der Lage sein, den Root-Switch, den RootPort jedes Switchs und den designierten Port aller Segmente zu nennen, nachdem Sie die BIDs und Port-Kosten und die Topologie des LAN ermittelt

Kapitel 2 Das Spanning-Tree-Protokoll

159

haben. An dieser Stelle wissen Sie auch, welche Schnittstellen weiterleiten (nmlich Root-Ports und designierte Ports) alle anderen Schnittstellen befinden sich im Zustand Blocking.

2.6.4

Konvergenz bei STP

Die STP-Topologie also die Summe der Schnittstellen im Zustand Forwarding sollte stabil bleiben, solange auch das Netzwerk stabil ist. Wenn Schnittstellen und Switches aktiv oder inaktiv werden, kann sich die resultierende STP-Topologie ndern es kommt zur STP-Konvergenz. Dieser Abschnitt weist auf einige Strategien hin, die die Behebung solcher Probleme in den Prfungen mit den Mitteln des gesunden Menschenverstandes ermglichen. Einige STP-Prfungsaufgaben ignorieren unter Umstnden die Details des Zustandsbergangs bei laufender Konvergenz und legen den Schwerpunkt stattdessen auf die Frage, welche Schnittstellen von Forwarding auf Blocking oder von Blocking auf Forwarding umschalten, wenn eine bestimmte nderung erfolgt. So knnten in einer Aufgabe etwa die Details eines bestimmten Szenarios aufgefhrt sein, an die sich folgende Frage anschliet: Welche Schnittstellen wechseln vom Zustand Blocking in den Zustand Forwarding?. Bei solchen Aufgaben, die die Topologien vor und nach einer nderung vergleichen, mssen Sie lediglich die in diesem Abschnitt beschriebenen Schritte abarbeiten dies allerdings zweimal, nmlich einmal fr die Bedingungen vor den Vernderungen und ein zweites Mal fr die Bedingungen, die die nderung verursacht haben. Andere STP-Fragen konzentrieren sich hingegen unter Umstnden direkt auf den bergangsprozess, d. h. auf Faktoren wie den Hello-, den MaxAge- und den Forward-Delay-Timer oder die Zustnde Listening und Learning und ihre Verwendung, wie sie weiter oben beschrieben wurde. Fr derartige Fragen mssen Sie die folgenden Fakten zur STP-Konvergenz kennen: Bei Schnittstellen, die sich im selben STP-Zustand verbleiben, ndert sich nichts. Bei Schnittstellen, die von Forwarding auf Blocking umschalten mssen, erfolgt diese Umschaltung direkt. Bei Schnittstellen, die von Blocking zu Forwarding wechseln mssen, erfolgt der bergang ber eine Listening- und eine Learning-Phase, deren Dauer jeweils durch den Forward-Delay-Timer angegeben wird (Standard: 15 Sekunden). Erst danach befindet sich die Schnittstelle im Zustand Forwarding.

160

CCNA ICND2-Prfungshandbuch

2.7
2.7.1
Wichtig!

Aufgaben zur Prfungsvorbereitung


Wiederholung

Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind in der Randspalte mit dem Symbol Schlsselthema gekennzeichnet. Tabelle 2.14 listet diese Themen sowie die Seitennummern auf, auf denen die Themen zu finden sind.
Tabelle 2.14: Schlsselthemen in Kapitel 2
Element Tabelle 2.2 Tabelle 2.3 Tabelle 2.4 Abbildung 2.5 Tabelle 2.6 Liste Tabelle 2.7 Liste Tabelle 2.8 Liste Tabelle 2.9 Tabelle 2.10 Beschreibung Probleme, die auftreten knnen, wenn STP in einem LAN mit redundanten Verbindungen nicht verwendet wird Grnde dafr, warum ein Switch eine Schnittstelle in den Zustand Forwarding oder Blocking umschaltet Felder in Hello-BPDUs Berechnung der Root-Kosten durch einen Switch STP-Standard-Port-Kosten fr verschiedene Schnittstellenraten Seite 113 116 117 120 122

Beschreibung der STP-Operationen bei stabiler Netzwerk- 123 topologie STP-Timer Definition der Vorgnge in den Zustnden Listening und Learning Zusammenfassung der 802.1d-Zustnde Gemeinsamkeiten von RSTP und STP Port-Zustnde bei 802.1d und 802.1w STP- und RSTP-Port-Funktionen 124 125 126 129 132 134 140 141 142 143 148 153

Abbildung 2.13 Lastverteilung von PVST+ Tabelle 2.11 Optionen fr mehrere Spanning-Trees

Abbildung 2.14 Format der System-ID-Erweiterung des STP-Priorittsfeldes Tabelle 2.12 Liste Liste Default-Einstellungen fr optionale STP-Konfigurationseinstellungen und zugehrige Konfigurationsbefehle Setzen einer neuen STP-Prioritt durch den Befehl
spanning-tree root primary

Lsung von STP-spezifischen Problemen in Prfungen

Kapitel 2 Das Spanning-Tree-Protokoll

161

2.7.2

Vervollstndigen Sie die Listen und Tabellen

Drucken Sie aus Anhang J, Tabellen zur bung (auf der CD vorhanden), den Abschnitt zu diesem Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls auf der CD enthaltene Anhang K, Lsungen zu den bungen, enthlt die vollstndigen Tabellen und Listen, mit denen Sie Ihre Lsungen berprfen knnen.

2.7.3

Wichtige Definitionen

Definieren Sie die folgenden Schlsselbegriffe aus diesem Kapitel und berprfen Sie Ihre Antworten anhand des Glossars: Alternativ-Port, Backup-Port, Blocking (Zustand), BPDU Guard, BID, BPDU (Bridge Protocol Data Unit), designierter Port, deaktivierter Port, Discarding (Zustand), EtherChannel, Forward-Delay, Forwarding (Zustand), Hello-BPDU, IEEE 802.1d, IEEE 802.1s, IEEE 802.1w, niederwertiges Hello, Learning (Zustand), Listening (Zustand), MaxAge, PortFast, RSTP (Rapid Spanning Tree Protocol), Root-Port, Root-Switch, STP (Spanning Tree Protocol)

2.7.4

Befehlsreferenz

Wir fhren an dieser Stelle eine Referenz fr die in diesem Kapitel behandelten Befehle aus dem Konfigurations- und dem EXEC-Modus an. Eigentlich sollten Sie die Befehle beim Studieren des Kapitels und beim Durchfhren der Aktivitten in diesem Abschnitt zur Prfungsvorbereitung quasi als Nebeneffekt bereits verinnerlicht haben. Um zu berprfen, wie gut Sie diese Befehle schon kennen, sollten Sie die linke Spalte der Tabelle mit einem Blatt Papier abdecken. Lesen Sie dann die Beschreibungen in der rechten Spalte und kontrollieren Sie, ob Sie den betreffenden Befehl kennen.

162

CCNA ICND2-Prfungshandbuch

Tabelle 2.15: Referenz der Konfigurationsbefehle aus Kapitel 2


Befehl
spanning-tree vlan vlan-number root primary

Beschreibung Globaler Konfigurationsbefehl, der diesen Switch zum Root-Switch macht. Die Prioritt des Switchs wird auf 24.576 oder den Priorittswert des beim Absetzen des Befehls aktuellen Root-Switchs abzglich 4076 gesetzt (je nachdem, welcher Wert niedriger ist). Globaler Konfigurationsbefehl, der die STP-Basisprioritt des Switchs auf 28.672 setzt Globaler Konfigurationsbefehl, der die Bridge-Prioritt des Switchs fr das angegebene VLAN ndert Schnittstellenbefehl, der die STP-Kosten auf den angegebenen Wert setzt Schnittstellenbefehl, der EtherChannel auf der Schnittstelle aktiviert Schnittstellenbefehl, der PortFast auf der Schnittstelle aktiviert Schnittstellenbefehl, der BPDU Guard auf der Schnittstelle aktiviert Globaler Befehl zur Aktivierung von PVST+ und 802.1d (pvst), PVRST und 802.1w (rapid-pvst) oder IEEE 802.1s (mehrere Spanning-Trees) und 802.1w (mst)

spanning-tree vlan vlan-number root secondary spanning-tree [vlan vlan-id] {priority priority} spanning-tree [vlan vlan-number] cost cost channel-group channel-group- number mode {auto | desirable | on} spanning-tree portfast spanning-tree bpduguard enable spanning-tree mode {mst | rapid-pvst | pvst}

Kapitel 2 Das Spanning-Tree-Protokoll


Tabelle 2.16: Referenz der EXEC-Befehle aus Kapitel 2
Befehl
show spanning-tree

163

Beschreibung Gibt Details zum STP-Status auf dem Switch und zu den Zustnden der einzelnen Ports an. Gibt STP-Informationen zum angegebenen Port aus. Gibt STP-Informationen zum angegebenen VLAN aus. aller VLANs oder nur des angegebenen VLAN aus.

show spanning-tree interface interface-id show spanning-tree vlan vlan-id

show spanning-tree [vlan vlan-id] root Gibt Informationen zum Root-Switch

show spanning-tree [vlan vlan-id] bridge debug spanning-tree events

Gibt STP-Informationen zum lokalen Switch fr jedes oder nur das angegebene VLAN an. Startet die Ausgabe von Informationsmeldungen zu nderungen der STPTopologie am Switch. Gibt Informationen zum Status von EtherChannels an diesem Switch an.

show etherchannel [channel-groupnumber] {brief | detail | port | portchannel | summary}

Dieses Kapitel behandelt die folgenden Themen


Allgemeine Anstze zur Problembehebung In diesem Abschnitt stellen wir Ihnen vor, wie man ein Netzwerkproblem am besten angeht, falls eine allgemeine Untersuchung des Problems nicht zgig zur eigentlichen Ursache fhrt. Problembehebung auf der LAN-Switching-Datenebene Dieser Abschnitt beschreibt verschiedene organisierte Schritte zur Behebung von Ethernet-LAN-Problemen einschlielich einer grndlichen Wiederholung von Befehlen und Methoden. Prognose des Normalbetriebs der LAN-Switching-Datenebene Dieser Abschnitt beschreibt, wie man die Ausgabe von show-Befehlen auf einem Switch analysiert und vorhersagt, wohin ein Frame in einem geswitchten Beispiel-LAN weitergeleitet wird.

Kapitel 3
Troubleshooting beim LAN-Switching
Gemeinsam mit den Kapiteln 7, Troubleshooting beim IP-Routing, und 11, Troubleshooting bei Routing-Protokollen, hat das vorliegende Kapitel eine wichtige Aufgabe: Es soll Ihnen dabei helfen, die zur Problembehebung erforderlichen Kenntnisse zu erlangen und die entsprechenden Prfungsaufgaben schnell und korrekt beantworten zu knnen. Gleichzeitig kann Sie dieses Kapitel hoffentlich auch besser auf Situationen vorbereiten, in denen Sie in der Praxis netzwerkspezifische Probleme beheben mssen.

ANMERKUNG
Warum die Problembehebung in den Prfungen so wichtig ist, finden Sie im Abschnitt Format der CCNA-Prfungen in der Einleitung zu diesem Buch. Die Kapitel zur Problembehebung in diesem Buch verfolgen ein etwas anderes Ziel als die brigen Kapitel. Einfach formuliert, konzentrieren sich alle Kapitel, die sich nicht explizit der Problembehebung widmen, auf einzelne Prinzipien und Eigenschaften zu einem Technologiebereich. Dagegen geht die Problembehebung wesentlich umfassender auf Konzepte und Strategien ein. Diese Kapitel zur Problembehebung betrachten die Welt der Netzwerktechnik mit einem greren Abstand: Sie legen den Schwerpunkt darauf, wie die einzelnen Teile miteinander agieren, und setzen dabei voraus, dass Sie die behandelten Einzelkomponenten bereits kennen. Dieses Kapitel bezieht sich auf dieselben Technologien, die in den vorherigen Kapiteln dieses Buches (Kapitel 1, VLANs, und Kapitel 2, Das Spanning-Tree-Protokoll) beschrieben wurden, sowie auf den bereits bekannten Stoff, wie er im CCENT/CCNA ICND1-Prfungshandbuch behandelt wurde. Zudem wird, da es sich hierbei um das erste Kapitel zur Problembehebung in diesem Buch handelt, auch die allgemeine Methodik bei der Problembehebung beschrieben.

166

CCNA ICND2-Prfungshandbuch

3.1

Fragen zur Einschtzung des Wissensstandes

Weil die Kapitel zur Problembehebung in diesem Buch Themen aus vielen anderen Kapiteln auch aus dem CCENT/CCNA ICND1-Prfungshandbuch in sich vereinen und zudem zeigen, wie man anspruchsvolleren Fragen in den CCNA-Prfungen angeht, sollten Sie diese Kapitel in jedem Fall unabhngig von Ihrem gegenwrtigen Kenntnisstand lesen. Aus diesen Grnden enthalten diese Kapitel keine Fragen zur Einschtzung des Wissensstandes. Sollten Sie jedoch der Meinung sein, dass Sie sich mit der Problembehebung beim LAN-Switching, wie sie in diesem Buch sowie im CCENT/CCNA ICND1-Prfungshandbuch beschrieben wird, wirklich gut auskennen, dann knnen Sie gerne den Groteil dieses Kapitels berspringen und mit dem Abschnitt Prfungsvorbereitung am Ende des Kapitels fortfahren.

3.2

Wissensgrundlage

Dieses Kapitel besteht aus drei Hauptteilen. Der erste Abschnitt legt den Schwerpunkt auf den Problembehebungsvorgang an und fr sich. Im zweiten Abschnitt wird erlutert, wie man die universellen Methoden der Problembehebung beim LAN-Switching auf der Datenebene anwendet, und der dritte Abschnitt fhrt Hinweise und Vorschlge zu bestimmten Problemen in Zusammenhang mit dem LAN-Switching auf.

3.3
ANMERKUNG

Allgemeine Anstze zur Problembehebung

Die hier beschriebenen allgemeinen Anstze und Methoden zur Problembehebung 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 unterbewusst immer irgendeine Methodik zur Problembehebung. Es gibt Menschen, die zunchst einmal die physische Verkabelung und den Schnittstellenzustand aller physischen Verbindungen berprfen, die Ursache des Problems sein knnten. Andere schicken anfangs stets PingBefehle an alle Systeme, um mehr zum Problem zu erfahren, und arbeiten sich dann nach und nach vor. Wieder andere probieren alle mglichen

Kapitel 3 Troubleshooting beim LAN-Switching

167

Schritte aus, bis sie am Ende intuitiv erfassen, worin das Problem genau 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, aber es kann jeder anhand eines systematischeren Ansatzes erlernen, wie man Schwierigkeiten mit besseren Aussichten auf Erfolg angeht. In den folgenden Abschnitten beschreiben wir einen solchen systematischen Ansatz, der Ihnen dabei helfen soll, in den CCNA-Prfungen Aufgaben mit Netzwerkproblemen zu lsen. Diese Methodik basiert auf drei wesentlichen Phasen, die gewhnlich in der folgenden Reihenfolge auftreten: Analyse bzw. Prognose des Normalbetriebs. Hierbei handelt es sich um die Beschreibung und Vorhersage der Vorgnge im Netzwerk, wenn es korrekt arbeitet. Das kann mithilfe der Dokumentation, der Konfiguration und der Ausgabe von show- und debug-Befehlen erfolgen. Eingrenzung des Problems. Wenn ein Problem auftritt, mssen Sie die Komponenten suchen, die im Vergleich zum Normalverhalten nicht korrekt funktionieren. Dieser Schritt basiert ebenfalls auf der Dokumentation, der Konfiguration und der Ausgabe von show- und debug-Befehlen. Ursachenanalyse. Sie ermitteln die Ursachen des im vorherigen Schritt erkannten Problems. Dabei geht es insbesondere um Ursachen, die sich durch bestimmte Manahmen beheben lassen. 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 der Problembehebung angehen kann.

3.3.1

Normalbetrieb des Netzwerks analysieren und prognostizieren

Aufgabe eines jeden Netzwerktechnikers ist es, dafr Sorge zu tragen, dass Daten von einem Endgert im Netzwerk zu einem anderen bertragen werden. Um ein Netzwerk analysieren zu knnen, muss der Techniker die Logik kennen, die von den einzelnen 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.

168

CCNA ICND2-Prfungshandbuch

Der Begriff Datenebene bezeichnet alle Vorgnge, die in Netzwerkgerten ablaufen, um einen einzelnen Frame oder ein Paket weiterzuleiten. Zur Weiterleitung wendet ein Gert die Logik und Funktionen seiner Datenebene auf den Frame oder das Paket an. Wenn ein LAN-Switch beispielsweise einen Frame ber eine Schnittstelle in VLAN 3 empfngt, trifft er seine Weiterleitungsentscheidung basierend auf den Eintrgen zu VLAN 3 in der MACAdresstabelle und leitet das Paket dann weiter. Diese Logik ist Bestandteil der Verarbeitung auf der Datenebene des Switchs. Der Begriff Steuerungsebene hingegen verweist auf zustzliche Vorgnge, die nicht fr jedes Paket oder jeden Frame durchzufhren sind. Stattdessen untersttzen einige Funktionen der Steuerungsebene nur den Weiterleitungsprozess. Beispiele fr die Steuerungsebene sind das VTP-Protokoll (VLAN Trunking Protocol) und das IP-Routing-Protokoll. Andere Funktionen der Steuerungsebene knnen nur indirekt auf die Datenebene bezogen werden. 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 Datenebene auswirken wrde. Um den voraussichtlichen Betrieb eines Netzwerks zu prognostizieren oder zu erlutern, wie ein korrekt funktionierendes Netzwerk gegenwrtig arbeitet, kann es hilfreich sein, sich zunchst mit der Steuerungs- oder der Datenebene zu beschftigen. Im Folgenden werden wir zwar zunchst die Datenebene behandeln, doch werden Sie bei echten Netzwerkstrungen je nach den vorliegenden Symptomen die eine oder die andere Ebene verwenden.

Datenebene analysieren
Bei der Problembehebung auf der Datenebene werden alle Gerte im angenommenen Weiterleitungspfad der Daten in der jeweiligen Reihenfolge untersucht. Die Analyse beginnt bei dem Host, auf dem der Datenfluss beginnt. Dieser Host sendet die Daten an ein anderes Gert, welches sie dann wieder an ein anderes Gert weiterleitet usw., bis die Daten schlielich beim endgltigen Empfnger eintreffen. Der empfangende Host sendet in der Regel irgendeine Antwort. Sie mssen also, um zu verstehen, wie die Kommunikation sinnvoll erfolgt, den Pfad auch in Gegenrichtung analysieren. Whrend die offensichtlichen Symptome lediglich zeigen, dass zwei Endgerte nicht miteinander kommunizieren knnen, bezieht sich das zugrunde liegende Problem hufig auf Frames oder Pakete einer Richtung. Sofern die Symptome nicht bereits Rckschlsse auf ein bestimmtes Problem zulassen, sollte die Problembehebung auf der Datenebene mit einer Analyse der Schicht 3 beginnen. Wenn Sie bei Schicht 3 anfangen, erkennen Sie die

Kapitel 3 Troubleshooting beim LAN-Switching

169

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 (Datenebene) in einem kleinen Netzwerk.
1 2 3

PC1 SW1 SW3 R1 R2 SW4

SW2 6

5 4

SW5

PC2

Abbildung 3.1: Wesentliche Schritte bei der IP-Weiterleitung

Nachdem Sie das voraussichtliche Verhalten der Schicht 3 in diesem Fall erfasst haben, 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: 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). 2. berprfen Sie die Ziel-IP-Adresse des Pakets in der Routing-Tabelle von R1 unter der Annahme, dass R1 das Paket als Nchstes an R2 weiterleitet. 3. Auf R2 sollten Sie dieselbe Zuordnung 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. 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 diese sich in verschiedenen Subnetzen befinden. Infolgedessen sollte PC2 das Paket an sein Default-Gateway R2 schicken.

170

CCNA ICND2-Prfungshandbuch

5. berprfen Sie, wie R2 fr Pakete, die an die IP-Adresse von PC1 gesendet werden, die passende Route fr R1 findet. 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).
PC1 SW1 1 2 3 SW3 4 R1

SW2

Abbildung 3.2: Wesentliche Schritte bei der LAN-Switching-Weiterleitung

Fr diese Analyse wrden Sie zunchst wieder bei PC1 beginnen. Diesmal berprfen Sie Ethernet-Header und -Trailer und dabei insbesondere die MAC-Adressen von Absender und Empfnger. In Schritt 2 verifizieren Sie dann die Weiterleitungslogik von SW1: Diese vergleicht die Ziel-MACAdresse 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.

Steuerungsebene analysieren
Viele Prozesse auf der Steuerungsebene wirken sich direkt auf den Datenebenenprozess aus. So funktioniert das IP-Routing beispielsweise nicht ohne geeignete IP-Routen, das heit, Router verwenden normalerweise ein dynamisches Routing-Protokoll ein Steuerungsebenenprotokoll zum Erlernen der Routen. Routing-Protokolle gelten teilweise deswegen als Protokolle der Steuerungsebene, weil die vom Routing-Protokoll durchgefhrten Schritte nicht fr jeden Frame oder jedes Paket wiederholt werden mssen.

Kapitel 3 Troubleshooting beim LAN-Switching

171

Die Prozesse der Datenebene eignen sich eher fr eine universelle Problembehebung, bei der die Weiterleitungslogik auf jedem Gert untersucht wird. Dagegen unterscheiden sich die Prozesse der Steuerungsebene zu deutlich voneinander, als dass sie eine allgemeingltige Problembehebung ermglichen wrden. Allerdings ist es sicher hilfreich, bestimmte Schritte der Problembehebung fr jedes Protokoll der Steuerungsebene in Betracht zu ziehen. So erklrt beispielsweise Kapitel 1, wie man verschiedene Arten von VTP-Problemen beheben kann.

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, sofern die Aufgabe keine konkreten Hinweise enthlt, der folgenden Liste eine empfohlene Vorgehensweise entnehmen: 1. Untersuchen Sie die Datenebene wie folgt: a) Ermitteln Sie die wesentlichen Schicht-3-Schritte also vom Ursprungs-Host zum Default-Gateway, von den einzelnen Routern zum jeweils nchsten Router und schlielich vom letzten Router bis zum Ziel-Host in beiden Richtungen. b) Analysieren Sie fr jedes Schicht-2-Netzwerk zwischen einem Host und einem Router oder zwischen zwei Routern die Weiterleitungsentscheidungen aller beteiligten Gerte. 2. Untersuchen Sie die Steuerungsebene wie folgt: a) Ermitteln Sie, welche Protokolle auf der Steuerungsebene fr die Weiterleitung zum Einsatz kommen und wichtig sind. b) Untersuchen Sie alle wichtigen Protokolle der Steuerungsebene auf korrekten Betrieb hin. Diese Analysen unterscheiden sich je nach Protokoll. c) Verschieben Sie die Analyse von Protokollen der Steuerungsebene, die den korrekten Betrieb der Datenebene nicht beeintrchtigen, auf einen spteren Zeitpunkt, wenn Sie sicher sind, dass Sie dieses Protokoll (z. B. CDP) brauchen, um die Aufgabe zu bearbeiten.

172

CCNA ICND2-Prfungshandbuch

3.3.2

Probleme eingrenzen

Die Problembehebung ist nur selten ein sequenzieller Vorgang. Aus organisatorischen Grnden greift dieses Kapitel die Problemeingrenzung als zweiten der drei Schritte einer Problembehebung auf. Allerdings erfolgt dieser Schritt meist sofort, sobald im ersten Schritt (Prognose des normalen Verhaltens) ein Problem erkannt wurde. Insofern helfen zwar die in diesem Abschnitt enthaltenen universellen Listen dabei, Struktur in die Problembehebung zu bringen, aber in der Praxis kann die Vorgehensweise schnell verfahren sein. Wenn Sie abgesehen von der Tatsache, dass zwei Hosts nicht miteinander kommunizieren knnen keine Anhaltspunkte dafr finden, wie Sie vorgehen sollen, beginnen Sie am besten wieder bei der Schicht-3-Datenebene, d. h. mit der IP-Weiterleitungslogik. Wenn Sie dann bei der IP-Weiterleitung einen Schritt ermitteln, der nicht funktioniert, berprfen Sie diesen genauer, um das Problemelement weiter einzugrenzen. 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 Paket erhlt, dieses aber nicht an PC2 ausgeliefert wird. Also sehen Sie sich alles, was zwischen R2 und PC2 passiert, nher an, um das Problem weiter einzugrenzen. 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 bei R2, SW4, SW5, PC2, 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 auf den Schichten des OSI-Modells erforderlich. Hierbei dreht es sich sowohl um die Daten- als auch um die Steuerungsebene. Fahren wir mit unserem beschriebenen Beispielszenario fort: Um Pakete an PC2 weiterleiten zu knnen, muss R2 die MAC-Adresse von PC2 kennen, die er mithilfe des ARP-Protokolls (Address Resolution Protocol) erlernt hat. Wenn Sie feststellen, dass R2 ber keinen ARP-Eintrag zu PC2 verfgt, knnten Sie versucht sein anzunehmen, dass ein IP-spezifisches Problem aufgetreten ist. Allerdings knnte dieses Problem durch einen Ausfall des Trunks zwischen SW4 und SW5 verursacht worden sein. Das bedeutet, dass die IP-ARP-Anforderung von R2 ein LAN-Broadcast von SW4 nicht an SW5 und dann an PC2 weitergeleitet werden kann. Insofern kann das Problem der Nichtweiterleitung von Paketen von R2 an PC2 zwar mit einem

Kapitel 3 Troubleshooting beim LAN-Switching

173

Steuerungsprotokoll (nmlich ARP) verknpft sein, aber die ausgefallene ARP-Anforderung kann durchaus von anderen Gerten (ausgefallener Trunk zwischen SW4 und SW5) verursacht worden sein. Dies knnte dann tatschlich ein Schicht-2- oder Schicht-1-Problem sein. Wenn eine Prfungsaufgabe keinerlei Hinweise darauf enthlt, wo man ansetzen knnte, bietet der folgende Ablauf eine systematische Problemeingrenzung: 1. Untersuchen Sie zunchst die Schicht-3-Datenebene (IP-Weiterleitung) und vergleichen Sie die Ergebnisse mit dem erwarteten Normalverhalten, bis Sie den ersten wichtigen Routing-Schritt erkennen, der fehlschlgt. 2. Grenzen Sie das Problem auf mglichst wenige Komponenten ein: a) Untersuchen Sie vor allem die OSI-Schichten 1, 2 und 3. b) Untersuchen Sie gleichermaen die Funktionen der Daten- und der Steuerungsebene. Denken Sie bei den Prfungen daran, dass Sie fr gute Problembehebungsmethoden keine Zusatzpunkte bekommen, d. h., Sie sollten die Antwort auf irgendeine Weise finden, auch wenn dies bedeutet, dass Sie auf der Basis des Aufgabenkontextes ein wenig raten mssen. So wird beispielsweise in Schritt 2a vorgeschlagen, dass Sie sich bei Ihren berlegungen auf die Schichten 1, 2 und 3 konzentrieren sollten. Dieser Vorschlag basiert darauf, dass die CCNA-Prfungen ebenfalls den Schwerpunkt auf diese drei Schichten legen. Sehen Sie aber zu, dass Sie diesen Vorgang so weit abkrzen, wie es die Frage gestattet.

3.3.3

Ursachenanalyse

Der letzte der drei Schritte die Ursachenanalyse steht am Abschluss der Problembehebung: Es geht darum, das Gert und die zugehrige Funktion zu ermitteln, die korrigiert werden mssen. Die Hauptursache ist der eigentliche Grund fr das Auftreten des Problems und was noch wichtiger ist die Fehlfunktion, deren Behebung das Problem beseitigt. Das Ermitteln der eigentlichen Ursache unseres Problems ist notwendig, weil es fr diese Ursache anders als bei vielen der im Rahmen der Eingrenzung erkannten Problemen nur eine bestimmte Lsung gibt. Vergegenwrtigen wir uns noch einmal unser Beispiel, bei dem R2 keine Pakete an PC2 weiterleiten konnte.

174

CCNA ICND2-Prfungshandbuch

Hierbei haben wir im Zuge der Eingrenzung die folgenden Probleme erkannt: R2 kann keine Pakete an PC2 weiterleiten. R2 erhlt keine ARP-Antworten von PC2. Die Schnittstelle von SW4 zum Trunk zu SW5 befindet sich im Zustand down/down. Das zwischen SW4 und SW5 verlegte Kabel ist fehlerhaft beschaltet. 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). Zwar sind die anderen Aussagen zutreffende und auch wichtige Aspekte, die whrend der Problemeingrenzung erkannt wurden, 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: 1. Fahren Sie mit der Problemeingrenzung fort, bis Sie die Hauptursache erkennen, fr die eine Lsung naheliegt. 2. Wenn Sie das Problem nicht auf eine echte Grundursache eingrenzen knnen, fhren Sie die Eingrenzung so weit wie mglich durch und verndern Sie Ihr Netzwerk, damit sich (hoffentlich) die Symptome ndern und Sie so weitere Einsichten in das Wesen des Problems gewinnen.

3.3.4

Prfungsaufgaben und die Praxis

Bei der Prfung sollten Sie nach Hinweisen suchen, etwa dem allgemeinen Thema, fr das die Problembehebung erfolgen soll. 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 VTP beziehen, dann sollten Sie sich zunchst die LAN-Umgebung ansehen. Trotzdem sollten Sie natrlich auch die Schichten 1 bis 3 sowie die Details der Daten- und der Steuerungsebene bercksichtigen, um die gewnschten Antworten zu finden.

ANMERKUNG
Dieser Abschnitt bezieht sich sehr allgemein auf die Problembehebung, ist aber nur in diesem Kapitel enthalten, weil es sich hierbei um das erste Kapitel in diesem Buch handelt, das sich dem Themenkreis der Problembehebung widmet.

Kapitel 3 Troubleshooting beim LAN-Switching

175

3.4

Problembehebung bei der LAN-SwitchingDatenebene

Die bislang in diesem Kapitel behandelten Strategien zur Problembehebung 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. Dabei muss auch der Zustand der zugrunde liegenden Schichten 1 und 2 bercksichtigt werden. In den folgenden Abschnitten werden wir die Werkzeuge und Verfahren untersuchen, mit denen man Probleme der LAN-Datenebene in den Schichten 1 und 2 behebt. Im weiteren Verlauf des Kapitels wird dann davon ausgegangen, dass in Schicht 3 kein Problem vorhanden ist (die Problembehebung in Schicht 3 ist Gegenstand der Kapitel 7 und 11). Im vorliegenden Kapitel wird auch auf Protokolle der Steuerungsebene verwiesen, und zwar insbesondere auf VTP und STP; diese beiden Protokolle waren allerdings bereits Gegenstand der beiden vorherigen Kapitel. Insofern knnen wir uns in den folgenden Abschnitten ganz auf die Datenebene des LANSwitchings konzentrieren. Wir rekapitulieren zunchst noch einmal die Weiterleitungsfunktionen beim LAN-Switch und stellen Ihnen die vier wichtigsten Schritte der Problembehebung beim LAN-Switching vor. Danach werden wir diese vier Schritte umfassend beschreiben. Am Ende steht ein Beispiel fr die praktische Anwendung der Problembehebung.

3.4.1

Der normale Weiterleitungsvorgang bei LAN-Switches

Der Weiterleitungsprozess bei LAN-Switches, der in Kapitel 7 des CCENT/ CCNA ICND1-Prfungshandbuches detailliert beschrieben wird, ist relativ einfach. Bevor wir mithilfe der show-Ausgabe den Normalbetrieb vorhersagen und die Ursache eines Weiterleitungsproblems eingrenzen, sollten wir noch einmal am Switch den normalen Weiterleitungsprozess betrachten, wenn kein Problem vorhanden ist. Die folgenden Schritte beschreiben diese Funktion: 1. Der Switch ermittelt das VLAN, in dem der Frame weitergeleitet werden soll, wie folgt: a) Wenn der Frame ber eine Access-Schnittstelle empfangen wird, wird das Access-VLAN der Schnittstelle verwendet. b) Wenn der Frame ber eine Trunk-Schnittstelle eingeht, ist es das VLAN, welches im Trunking-Header des Frames aufgefhrt ist.

176

CCNA ICND2-Prfungshandbuch

2. Wenn die Eingangsschnittstelle sich in diesem VLAN im STP-Zustand Learning oder Forwarding befindet, fgt der Switch die Absender-MACAdresse zu seiner MAC-Adresstabelle hinzu und vermerkt dort die Eingangsschnittstelle und die VLAN-ID (sofern die Angaben dort noch nicht vorhanden sind). 3. Falls die Eingangsschnittstelle sich in diesem VLAN nicht im STP-Zustand Forwarding befindet, wird der Frame verworfen. 4. Der Switch sucht nach der Ziel-MAC-Adresse des Frames in der MACAdresstabelle, jedoch nur fr Eintrge des in Schritt 1 ermittelten VLAN. Je nachdem, ob die MAC-Adresse gefunden wird oder nicht, werden die folgenden Schritte ausgefhrt: Die MAC-Adresse wird gefunden. Der Frame wird ber genau die Schnittstelle weitergeleitet, die im zur Adresse passenden Tabelleneintrag aufgefhrt ist. Die MAC-Adresse wird nicht gefunden. Der Frame wird ber alle anderen Access-Ports im selben VLAN, die sich im Zustand Forwarding befinden, sowie ber alle Trunk-Ports geflutet, die dieses VLAN weiterleiten (d. h. aktiver Zustand, in der Liste der erlaubten VLANs enthalten, kein Pruning, STP-Weiterleitung) . 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 MAC-Adresse an sein Default-Gateway R1.
0200.1111.1111

PC1

Access-VLAN 3
Fa0/11 Gi0/1 Gi0/2 Fa0/10 Fa0/1

PC2

SW1
Fa0/12 Gi0/2 Gi0/1

SW2

R1
0200.0101.0101

0200.2222.2222 Gi0/1 Gi0/2

SW3
Fa0/13

PC3

Abbildung 3.3: Geswitchtes Netzwerk zur Analyse der Datenebene in Kapitel 3

Kapitel 3 Troubleshooting beim LAN-Switching

177

Betrachten Sie den Frame, der von PC1 (Absender-MAC-Adresse 0200.1111.1111) an R1 (Ziel-MAC-Adresse 0200.0101.0101) gesendet wird. SW1 ermittelt ber den oben beschriebenen Schritt 1, ob die Schnittstelle Fa0/11 als Access-Schnittstelle oder als Trunk verwendet wird. In diesem Fall handelt es sich um eine Access-Schnittstelle, die VLAN 3 zugewiesen ist. In Schritt 2 fgt SW1 in seiner MAC-Adresstabelle einen Eintrag mit der MAC-Adresse 0200.1111.1111, der Schnittstelle Fa0/11 und dem VLAN 3 hinzu. In Schritt 3 vergewissert sich SW1, dass die Eingangsschnittstelle Fa0/11 sich im STP-Zustand Forwarding 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 den Port Gigabit 0/1 enthlt, dann leitet SW1 den Frame nur ber Gi0/1 weiter. Ist die Ausgangsschnittstelle Gi0/1 eine Trunk-Schnittstelle, dann fgt SW1 einen VLAN-TrunkingHeader hinzu, der das VLAN mit der in Schritt 1 ermittelten ID (also VLAN 3) kennzeichnet. Ein weiteres, etwas abgendertes Beispiel: Angenommen, PC1 sendet einen Broadcast. Die Schritte 1 bis 3 erfolgen wie oben beschrieben, doch in Schritt 4 flutet SW1 den Frame. SW3 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 die Switches nur ber Ports, die sich im STP-Zustand Forwarding befinden, eine Kopie des Frames weiterleiten. Obwohl diese Weiterleitungslogik relativ simpel gestrickt ist, erfordert eine Problembehebung die Anwendung fast aller LAN-Themen, die in den Bchern zu ICND1 und ICND2 beschrieben werden. Wenn man beispielsweise wei, dass PC1 zuerst Frames an SW1 schickt, ist es sinnvoll, den Zustand der Schnittstelle zu berprfen, sicherzustellen, dass die Schnittstelle up/up ist, und sollte dies nicht der Fall sein das Problem mit der Schnittstelle zu beheben. Um Probleme zu beseitigen, ist es oft notwendig, Dutzende einzelner Faktoren zu berprfen. Aus diesem Grund wird in diesem Kapitel ein Vorgang fr die Datenebene beschrieben, der alle Manahmen in vier verschiedene Schritte unterteilt: 1. Netzwerkdiagramme mit CDP verifizieren 2. Schnittstellenprobleme eingrenzen 3. Probleme der Filterung und Port-Security beheben 4. VLAN- und Trunking-spezifische Probleme beheben 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 die Grundlagen

178

CCNA ICND2-Prfungshandbuch

wurden entweder im CCENT/CCNA ICND1-Prfungshandbuch oder in den ersten beiden Kapiteln dieses Buches bereits behandelt. Das wesentliche Ziel der folgenden Abschnitte besteht darin, alle Konzepte zusammenzufhren. Das verkrzt die Analyse konkreter Szenarien, wie sie bei den Prfungen verlangt wird, und die Erfolgschancen erhhen sich.

ANMERKUNG
Die nchsten beiden Abschnitte Schritt 1: Netzwerkdiagramme mit CDP berprfen und Schritt 2: Schnittstellenprobleme eingrenzen werden auch in Kapitel 10 des ICND1-Buches behandelt. Wenn Sie beide Bcher lesen, um sich auf die CCNA-Prfung vorzubereiten, mssen Sie die betreffenden Abschnitte in diesem Kapitel nicht unbedingt lesen (diese haben hnliche Namen wie die entsprechenden Abschnitte in Kapitel 10 des ICND1-Buches). Sie knnen in diesem Fall direkt mit dem Abschnitt Schritt 3: Probleme in Zusammenhang mit Filterung und Port-Security beheben fortfahren.

3.4.2

Schritt 1: Netzwerkdiagramme mit CDP berprfen

Das CDP-Protokoll (Cisco Discovery Protocol) ist ntzlich, um die Informationen im Netzwerkdiagramm zu berprfen und weitere hilfreiche Angaben zu Gerten und zur Netzwerktopologie zu ermitteln. In der Praxis sind die 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; es ist jedoch 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 LANDatenebene lautet mithin: 1. berprfen Sie mithilfe von CDP die im Netzwerkdiagramm enthaltenen Angaben auf Richtigkeit und Vollstndigkeit.

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

Kapitel 3 Troubleshooting beim LAN-Switching

179

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 Schnittstellennummern an ihre Nachbarn zu bermitteln. Im Wesentlichen sind es die drei in Tabelle 3.1 aufgefhrten Befehle, welche die von den Nachbarn erlernten CDP-Informationen auflisten. Ist berhaupt kein Netzwerkdiagramm vorhanden, so kann ein Netzwerktechniker ein Diagramm der Router und Switches allein aus der Ausgabe des Befehls show cdp erstellen.
Tabelle 3.1: show cdp-Befehle, die Informationen zu Nachbargerten auffhren
Befehl
show cdp neighbors [type number]

Beschreibung Zeigt eine Informationszeile pro Nachbargert oder bei Angabe einer Schnittstellennummer zu den dort angeschlossenen Nachbarn an. Fhrt umfangreiche Informationen (ca. 15 Zeilen) pro Nachbargert auf. Zeigt dieselben Angaben wie show cdp neighbors detail an, jedoch nur zum benannten Nachbarn.

show cdp neighbors detail show cdp entry name

Vergleicht man die CDP-Ausgabe mit einem konkreten Diagramm, besteht das einzig Schwierige darin, dass die Ausgabe zwei Schnittstellen oder Ports ber eine lange Zeile hinweg auffhrt. 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 der eigenen lokalen Schnittstelle. Name und Nummer der Schnittstelle des Nachbargerts befinden sich rechts in der Ausgabe unter der berschrift Port ID. 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 Schnittstellen 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 000000000 Device ID SW1 000 R1 000 0000000000000 Local Intrfce Gig 0/2 0000000 Fas 0/10 Holdtme 173 139 Capability Platform 0000000 Port ID S I WS-C2960-2 0000000 Gig 0/1 R S I dddd 1841 dddddddFas 0/1

180

CCNA ICND2-Prfungshandbuch

Falls 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 Schnittstellen, bei denen kein spezieller Bedarf daran besteht. Schnittstellen, bei denen der Einsatz von CDP notwendig ist, sind solche, an die weitere Cisco-Router oder -Switches angeschlossen sind, sowie Schnittstellen, mit denen IP-Telefone von Cisco verbunden sind. Ansonsten kann CDP mit dem Schnittstellenbefehl no cdp enable deaktiviert werden. (Der Schnittstellenbefehl 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.

3.4.3

Schritt 2: Schnittstellenprobleme eingrenzen

Eine Schnittstelle an einem Cisco-Switch muss aktiv sein, damit der Switch Frames, die ber diese Schnittstelle empfangen wurden, verarbeiten oder Frames darber versenden kann. Insofern sollte ein (durchaus naheliegender) Schritt bei der Problembehebung darin bestehen, den Zustand der einzelnen Schnittstellen zu verifizieren. Dies gilt insbesondere fr diejenigen Schnittstellen, von denen man annimmt, dass sie bei der Weiterleitung von Frames verwendet werden; diese sollten darauf hin geprft werden, ob sie aktiv sind und funktionieren. In diesem Abschnitt untersuchen wir die mglichen Schnittstellenzustnde bei den IOS-basierten Switches, fhren Ursachen fr fehlerhafte Funktionen auf und behandeln ein verbreitetes Problem, das auch dann auftritt, wenn die Schnittstelle funktionsfhig zu sein scheint. Die wesentlichen Aufgaben fr diesen Schritt lassen sich wie folgt zusammenfassen: 2. berprfen Sie wie folgt auf Schnittstellenprobleme hin: a) Bestimmen Sie den Schnittstellenzustand fr jede erforderliche Schnittstelle. Befindet sich eine Schnittstelle nicht im Zustand connect (bzw. up/up), so beheben Sie alle Probleme, bis die Schnittstelle diesen Zustand erreicht. b) Prfen Sie bei Schnittstellen, die sich im Zustand connect (up/up) befinden, ferner auf zwei weitere Probleme hin: Duplexfehlanpassungen und Varianten der Port-Security, bei denen gezielt Frames verworfen werden.

Kapitel 3 Troubleshooting beim LAN-Switching

181

Zustandscodes bei Schnittstellen und Grnde fr fehlerhaften Betrieb


Cisco-Switches verwenden zwei Arten von Zustandscodes: Einen Satz aus zwei Codes (Wrtern), der dieselben Konventionen wie die Zustandscodes von Router-Schnittstellen benutzt, und einen anderen, nur aus einem Wort bestehenden Code. Beide Zustandscodes erlauben die Feststellung, ob eine Schnittstelle funktioniert. Die Switch-Befehle show interfaces und show interfaces description fhren wie bei Routern die Zweiwortcodes auf. Die beiden Codes heien Leitungszustand und Protokollzustand, und die Codes verweisen jeweils darauf, ob Schicht 1 bzw. Schicht 2 funktioniert. Bei LAN-Switch-Schnittstellen werden beide Codes entweder als up oder als down angegeben, weil alle Switch-Schnittstellen dieselben Ethernet-Protokolle fr die Sicherungsschicht verwenden, weswegen das Sicherungsschichtprotokoll niemals ein Problem aufweisen sollte.

ANMERKUNG
Dieses Buch gibt die beiden Zustandscodes in Kurzform an, indem sie getrennt durch einen Schrgstrich aufgefhrt werden (z. B. up/up). Der Befehl show interfaces status fhrt den Schnittstellenzustandscode 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 Zustand connect fr funktionierende Schnittstellen aus; dieser entspricht dem Zustand up/up, wie er mit den Befehlen show interfaces und show interfaces description ermittelt werden kann. Ein anderer Schnittstellenzustand als connect bzw. up/up bedeutet, dass der Switch Frames ber diese Schnittstelle weder empfangen noch weiterleiten kann. Fr jeden dieser Nichtbetriebszustnde gibt es jeweils eine kleine Anzahl von Ursachen. Beachten Sie auerdem, dass in den Prfungen durchaus eine Aufgabe auftauchen kann, bei der nur der eine oder andere Zustandscode angegeben wird. Bereiten Sie sich also gut auf die Prfungen vor, indem Sie die Bedeutungen der beiden Schnittstellenzustandscodes gewissenhaft studieren. Tabelle 3.2 fhrt die Codekombinationen sowie einige Ursachen fr den jeweiligen Schnittstellenzustand auf.

182

CCNA ICND2-Prfungshandbuch

Tabelle 3.2: Zustandscodes fr Schnittstellen bei LAN-Switches


Wichtig!

Leitungszustand admin. down down

Protokollzustand down down

Schnittstellen- Typische Ursache zustand disabled notconnect Fr die Schnittstelle wurde der Befehl shutdown konfiguriert. Fehlendes oder schadhaftes Kabel, falsche Kabelbeschaltung, fehlangepasste bertragungsraten bei zwei verbundenen Gerten, abgeschaltetes Gert oder deaktivierte Schnittstelle auf der Gegenseite Auftreten bei LAN-Switch-Schnittstellen ist unwahrscheinlich. Schnittstelle ist durch Port-Security deaktiviert. Schnittstelle ist funktionsfhig.

up down up

down

notconnect

down err-disabled (err-disabled) up connect

Der Zustand notconnect und die Kabelbeschaltung


Tabelle 3.2 fhrt verschiedene Grnde dafr auf, dass eine Schnittstelle sich im Zustand notconnect befindet. Viele dieser Grnde bedrfen keiner weiteren Erluterung: Wenn eine Schnittstelle mit einem anderen Switch verbunden ist und sich im Zustand notconnect befindet, mssen Sie berprfen, ob die Schnittstelle auf der anderen Seite der Verbindung abgeschaltet wurde. Einer der Grnde fr das Auftreten eines solchen Zustands die falsche Kabelbeschaltung 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 Beschaltung bei Ethernet-Kabeln wird in Kapitel 3 des CCENT/CCNA ICND1-Prfungshandbuches beschrieben.) Die Ethernet-Standards fr (U)TP-Kabel legen fest, wie die Kontakte des RJ45-Anschlusses an die einzelnen Leitungsdrhte am Kabelende angeschlossen werden mssen. Die Gerte bertragen Signale ber Leiterpaare, wobei 10BaseT und 100BaseTX zwei Paare verwenden: je eines fr Senden und Empfangen. Wenn man zwei Gerte miteinander verbindet, die fr den Signalversand dieselben Kontaktpaare verwenden, muss das verwendete Kabel ein Crossover-Kabel das Sendekontaktpaar des einen Gerts ber Kreuz mit dem Empfangskontaktpaar des anderen Gerts verbinden. Umgekehrt wird fr Gerte, bei dem die Leiterpaare fr den Datenversand bereits intern entgegengesetzt angeordnet sind, ein Straight-Through-Kabel bentigt, welches die Leitungen nicht ber Kreuz ausfhrt. Abbildung 3.4 zeigt exemplarisch ein Switch-LAN, in dem die beiden Kabeltypen zum Einsatz kommen.

Kapitel 3 Troubleshooting beim LAN-Switching

183

Gebude 1
Straight-ThroughKabel R1

Gebude 2

Wichtig!

StraightThroughKabel

Switch11

CrossoverKabel

Switch21 StraightThroughKabel Switch22

Switch12

Abbildung 3.4: Verwendung von Crossover- und Straight-Through-Kabeln

Fr eine schnelle Fehlersuche mssen Sie wissen, wie die Gerte die Daten ber die Leiterpaare bertragen. Tabelle 3.3 fhrt bei CCNA-Themen hufig 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 StraightThrough-Kabel zum Einsatz kommt.
Tabelle 3.3: Anschlussbeschaltungen bei 10BaseT und 100BaseTX
Gerte, die auf 1,2 senden und auf 3,6 empfangen PC-Netzwerkkarten Router WLAN-Access-Points (Ethernet-Schnittstelle) Netzwerkdrucker (ber Ethernet angebunden) Gerte, die auf 3,6 senden und auf 1,2 empfangen Hubs Switches
Wichtig!

Probleme mit Datenrate und Duplexmodus


Switch-Schnittstellen ermitteln ihre Geschwindigkeits- und Duplexeinstellungen auf unterschiedliche Weise. Standardmig verwenden kupferbasierte Schnittstellen, die unterschiedliche Datenraten und Duplexeinstellungen untersttzen, das Autonegotiating nach IEEE 802.3x. Alternativ lassen sich bestimmte Einstellungen an Switch-Schnittstellen, Routern und den meisten Netzwerkkarten auch gezielt festlegen. Auf Switches und Routern werden diese Werte mit den Schnittstellenbefehlen speed {10 | 100 | 1000} bzw. duplex {half | full} festgelegt. Beachten Sie, dass die explizite Konfiguration von Datenrate oder Duplexmodus auf einem Switch das Autonegotiating fr diese Schnittstelle deaktiviert.

184

CCNA ICND2-Prfungshandbuch

Die Befehle show interfaces und show interfaces status geben die Geschwindigkeits- und Duplexeinstellungen einer Schnittstelle an. Listing 3.2 zeigt ein Beispiel:
Listing 3.2: Anzeige von Datenraten- und Duplexeinstellungen von SwitchSchnittstellen
SW1#show interfaces status Port Name Status Vlan 0000000000000 Type Duplex Speed Fa0/1 notconnect 1 auto auto 10/100BaseTX Fa0/2 notconnect 1 auto auto 10/100BaseTX Fa0/3 notconnect 1 auto auto 10/100BaseTX Fa0/4 connected 1 a-full a-100 10/100BaseTX Fa0/5 connected 1 a-full a-100 10/100BaseTX Fa0/6 notconnect 1 auto auto 10/100BaseTX Fa0/7 notconnect 1 auto auto 10/100BaseTX Fa0/8 notconnect 1 auto auto 10/100BaseTX Fa0/9 notconnect 1 auto auto 10/100BaseTX Fa0/10 notconnect 1 auto auto 10/100BaseTX Fa0/11 connected 1 a-full 10 10/100BaseTX Fa0/12 connected 1 half 100 10/100BaseTX Fa0/13 connected 1 a-full a-100 10/100BaseTX Fa0/14 disabled 1 auto auto 10/100BaseTX Fa0/15 notconnect 3 auto auto 10/100BaseTX Fa0/16 notconnect 3 auto auto 10/100BaseTX Fa0/17 connected 1 a-full a-100 10/100BaseTX Fa0/18 notconnect 1 auto auto 10/100BaseTX Fa0/19 notconnect 1 auto auto 10/100BaseTX Fa0/20 notconnect 1 auto auto 10/100BaseTX Fa0/21 notconnect 1 auto auto 10/100BaseTX Fa0/22 notconnect 1 auto auto 10/100BaseTX Fa0/23 notconnect 1 auto auto 10/100BaseTX Fa0/24 notconnect 1 auto auto 10/100BaseTX Gi0/1 connected trunk full 1000 10/100/1000BaseTX Gi0/2 notconnect 1 auto auto 10/100/1000BaseTX SW1#show interfaces fa0/13 FastEthernet0/13 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 0019.e86a.6f8d (bia 0019.e86a.6f8d) MTU 1500 bytes, BW 100000 Kbit, 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, 00000000000000000000 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 00:00:05, output 00:00:00, output hang never Last clearing of "show interface" counters never

Kapitel 3 Troubleshooting beim LAN-Switching


Listing 3.2: Anzeige von Datenraten- und Duplexeinstellungen von SwitchSchnittstellen (Forts.)
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 85022 packets input, 10008976 bytes, 0 no buffer Received 284 broadcasts (0 multicast) 0000000 0 giants, 0 throttles 0 runts, 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 281 multicast, 0 pause input 0 input packets with dribble condition detected 95226 packets output, 10849674 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 000000000000 0 babbles, 0000000000000000 0 deferred 0 late collision, 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out

185

Zwar sind beide Befehle auf ihre Weise hilfreich, doch nur show interfaces status gibt an, wie der Switch Datenrate und Duplexmodus festgelegt hat. In der Ausgabe sind via Autonegotiating verhandelte Einstellungen durch ein vorangestelltes a- gekennzeichnet. So bezeichnet beispielsweise a-full einen automatisch ausgehandelten Vollduplexmodus, whrend full einen manuell konfigurierten Vollduplexmodus angibt. Im Listing ist hervorgehoben, dass Geschwindigkeit und Duplexmodus fr die Fa0/12-Schnittstellen nicht ber Autonegotiating ermittelt wurden, whrend das Autonegotiating fr Fa0/13 erfolgreich eingesetzt wurde. Beachten Sie, dass der Befehl show interfaces Fa0/13 (ohne die Option status) die Geschwindigkeits- und Duplexeinstellungen fr Fa0/13 auffhrt, ohne dass hierbei angegeben wird, dass die Werte via Autonegotiating ermittelt wurden. Cisco-Switches weisen in Bezug auf die Datenrate der Schnittstelle ein paar interessante Funktionalitten auf, mit denen Sie einige schnittstellenspezifische Probleme eingrenzen knnen. Wenn die Schnittstelle eines CiscoSwitchs mit einer bestimmten Datenrate konfiguriert wurde und diese Datenrate nicht zum Gert am anderen Ende des Kabels passt, befindet sich die Switch-Schnittstelle im Zustand notconnect bzw. down/down. Allerdings kann eine derartige Geschwindigkeitsfehlanpassung nur auftreten, wenn die Geschwindigkeit auf dem Switch manuell konfiguriert wurde. Switch-Schnittstellen, fr die der Befehl speed nicht konfiguriert wurde, erkennen die vom anderen Gert verwendete Datenrate automatisch (und zwar auch dann, wenn die Gegenseite das IEEE-Autonegotiating deaktiviert) und verwenden diese Datenrate dann auch.

186

CCNA ICND2-Prfungshandbuch

Nehmen wir etwa an, dass die Schnittstelle Gi0/2 von SW2 in Abbildung 3.3 mit den Befehlen speed 100 und duplex half konfiguriert wurde (was nebenbei erwhnt fr eine Gigabit-Schnittstelle keine empfehlenswerten Einstellungen sind). SW2 wird diese Einstellungen nun verwenden und das Autonegotiating abschalten, weil beide Befehle speed und duplex konfiguriert wurden. Wenn fr die Schnittstelle Gi0/1 von SW1 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 Falles auf SW1:
Listing 3.3: Anzeige von Geschwindigkeits- und Duplexeinstellungen fr SwitchSchnittstellen
SW1#show interfaces gi0/1 status Port Gi0/1 Name Status connected Vlan trunk Duplex Speed Type 0000000000000 10/100/1000BaseTX a-half a-100

In diesem Listing werden Datenrate und Duplexeinstellung mit dem Prfix a- angezeigt, was auf 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. Das Feststellen fehlangepasster Duplexeinstellungen kann wesentlich schwieriger sein als die Erkennung einer Geschwindigkeitsfehlanpassung, denn die Switch-Schnittstelle befindet sich auch dann im Zustand connect (up/up), wenn die Duplexeinstellungen an den Enden eines Ethernet-Segments nicht zueinander passen. In diesem Fall funktioniert die Schnittstelle zwar, aber ihre Leistung ist gering, und es kann vorbergehend immer wieder zu Problemen kommen. Der Grund hierfr besteht darin, dass das Gert, welches im Halbduplexmodus arbeitet, die CSMA/CD-Logik (Carrier Sense Multiple Access with Collision Detection) verwendet, das heit, es wartet mit dem Versand von Daten, solange Frames eingehen. Es nimmt also an, dass Kollisionen auftreten, auch wenn dies physisch nicht der Fall ist, und bricht den Versand eines Frames ab, weil der Switch glaubt, dass eine Kollision stattgefunden hat. Ist die Netzbelastung ausreichend hoch, dann befindet sich die Schnittstelle zwar im Zustand connect, ist aber fr die Weiterleitung von Daten weitgehend nutzlos und zudem sogar fr den Verlust wichtiger VTP- und STP-Nachrichten verantwortlich.

Kapitel 3 Troubleshooting beim LAN-Switching

187

Probieren Sie Folgendes aus, um Fehlanpassungen beim Duplexmodus zu erkennen: Verwenden Sie Befehle wie show interfaces an beiden Enden der Verbindung, um die jeweiligen Duplexeinstellungen zu kontrollieren. berprfen Sie bei Halbduplexschnittstellen bestimmte Zhler auf steigende Werte hin. 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 oben sind diese Zhler in der Ausgabe des Befehls show interfaces hervorgehoben. Die Grundursache fr fehlangepasste Duplexeinstellungen knnen 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 Datenrate aus. Nach Vorgabe des IEEE werden standardmig die folgenden Einstellungen gewhlt: Falls die Geschwindigkeit bei 10 oder 100 Mbit/s liegt, wird der Halbduplexmodus verwendet. Falls die Geschwindigkeit bei 1000 Mbit/s liegt, wird der Vollduplexmodus verwendet.
Wichtig! Wichtig!

ANMERKUNG
Ethernet-Schnittstellen mit Geschwindigkeiten von mehr als 1 Gbit/s verwenden stets den Vollduplexmodus.

3.4.4

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 eine Schnittstelle gesendet oder dort empfangen werden, untersuchen und gegebenenfalls verwerfen. Switch-ACLs sind nicht Gegenstand der CCNA-Prfungen, wohl aber eine hnliche Switch-Funktionalitt namens Port-Security. Wie im CCENT/ CCNA ICND1-Prfungshandbuch in Kapitel 9 beschrieben, ist es Aufgabe

188

CCNA ICND2-Prfungshandbuch

der Port-Security, dafr zu sorgen, dass der Switch bestimmte Frames verwirft, die ber eine bestimmte Schnittstelle eingehen oder versendet werden. Die Port-Security bietet drei Grundfunktionen, mit denen festgelegt werden kann, welche Frames gefiltert werden sollen:
Wichtig!

Sie kann festlegen, welche MAC-Adressen Frames ber eine SwitchSchnittstelle senden und empfangen knnen. Frames von oder an andere MAC-Adressen werden verworfen. Sie kann die Anzahl der MAC-Adressen festlegen, die die Schnittstelle verwenden. Frames von oder an MAC-Adressen, die nach Erreichen des Hchstwertes erlernt wurden, werden verworfen. Die beiden zuvor genannten Punkte knnen auch kombiniert werden. Der erste Schritt bei den Problemen mit der Port-Security besteht darin herauszufinden, fr welche Schnittstellen 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 Schnittstellenbefehl switchport port-security violation violation-mode; dieser Befehl legt auf dem Switch fest, was zu tun ist, wenn ein Sicherheitsversto festgestellt wird. Generell sieht die Syntax wie folgt aus: 3. berprfen Sie wie folgt auf Port-Security-Probleme hin: a) Ermitteln Sie mit show running-config oder show port-security alle Schnittstellen, fr die die Port-Security aktiviert wurde. b) Ermitteln Sie, ob gegenwrtig ein Sicherheitsversto im Sinne des in der Port-Security-Konfiguration angegebenen Parameters violation mode erfolgt: shutdown: Die Schnittstelle befindet sich im Zustand err-disabled. restrict: Die Schnittstelle befindet sich im Zustand connect, aber der Befehl show port-security interface zeigt einen ansteigenden Wert fr den Verstozhler. protect: Die Schnittstelle befindet sich im Zustand connect, und der Befehl show port-security interface zeigt keinen ansteigenden Wert fr den Verstozhler. c) Vergleichen Sie in jedem Fall die Konfiguration der Port-Security mit dem Diagramm und mit dem Feld last source address in der Ausgabe des Befehls show port-security interface. Eine der Schwierigkeiten besteht darin, dass bestimmte Konfigurationen der Port-Security die abzuweisenden Frames nur verwerfen, die Schnittstelle jedoch nicht deaktivieren. Alle drei Verstomodi verwerfen Daten entspre-

Kapitel 3 Troubleshooting beim LAN-Switching

189

chend der Konfiguration. Wenn beispielsweise nur die vordefinierte MACAdresse 0200.1111.1111 zulssig ist, verwirft der Switch an dieser Schnittstelle 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 das Verhalten in einer bersicht zusammen.
Tabelle 3.4: Reaktionen der Schnittstelle abhngig vom Port-Security-Modus
Parameter Verwirft Verwirft alle Daten Versto fhrt zum Zhler wird bei violation illegale nach Auftreten des Schnittstellenzustand jedem Versto mode Daten Verstoes err-disabled erhht shutdown restrict protect Ja Ja Ja Ja Nein Nein Ja Nein Nein Ja Ja Nein
Wichtig!

Schritt 3b des obigen Ablaufs bezieht sich auf den Schnittstellenzustand errdisabled (deaktiviert wegen Fehler). Dieser Zustand gibt an, dass die Schnittstelle mit aktivierter Port-Security einen Versto festgestellt hat und zum gegenwrtigen Zeitpunkt keine Daten ber die Schnittstelle gelangen. Er fhrt dazu, dass der Verstomodus shutdown verwendet wird, denn dies ist der einzige der drei Port-Security-Modi, der eine Abschaltung der Schnittstelle bewirkt. Um dieses Problem zu beheben, muss die Schnittstelle deaktiviert und nachfolgend mit dem Befehl no shutdown wieder reaktiviert werden. Listing 3.4 zeigt ein Beispiel, in dem sich die Schnittstelle im Zustand errdisabled befindet:
Listing 3.4: Schnittstelle im Zustand err-disabled
! Der erste Befehl listet alle Schnittstellen, fr die Port-Security aktiviert ! wurde, sowie den Verstomodus unter der berschrift "Security Action" auf. SW1#show port-security Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action 000000000000000 (Count) (Count) (Count) --------------------------------------------------------------------------000000 Fa0/13 1 1 1 Shutdown 00000000 --------------------------------------------------------------------------Total Addresses in System (excluding one mac per port) : 0 Max Addresses limit in System (excluding one mac per port) : 8320 ! ! Der nchste Befehl zeigt den Zustand err-disabled an, was einen ! Sicherheitsversto impliziert. SW1#show interfaces Fa0/13 status

190

CCNA ICND2-Prfungshandbuch

Listing 3.4: Schnittstelle im Zustand err-disabled (Forts.)


Port Name Status Vlan Duplex Speed Type Fa0/13 err-disabled 1 00000000000000 auto auto 10/100BaseTX ! ! In der Ausgabe des nchsten Befehls sind mehrere wichtige Tatsachen ! hervorgehoben. SW1#show port-security interface Fa0/13 Port Security : Enabled Port Status : Secure-shutdown Violation Mode : Shutdown Aging Time : 0 mins Aging Type : Absolute 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 bei der Problembehebung hilfreich sein knnen. Der Port-Zustand secureshutdown bedeutet, dass die Schnittstelle infolge eines Verstoes fr den gesamten Datenverkehr gesperrt wird und dass der Schnittstellenzustand err-disabled zugewiesen wird. Am Ende der Befehlsausgabe wird ein 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 die Schnittstelle in den Zustand err-disabled versetzt wird, weswegen der Zhler nachfolgend nicht mehr hochgezhlt kann, bis der Netzwerktechniker fr die Schnittstelle nacheinander die Befehle shutdown und no shutdown absetzt. Beachten Sie schlielich, dass auch die Absender-MACAdresse des letzten ber die Schnittstelle empfangenen Frames angezeigt wird. Dieser Wert kann ntzlich sein, um die MAC-Adresse des Gerts zu ermitteln, das den Versto verursacht hat. Auch die Verstomodi restrict und protect bewirken das Verwerfen von Frames, wenn auch mit einem ganz anderen Verhalten. Bei diesen Verstomodi verbleibt die Schnittstelle im Zustand connect (up/up), obwohl unzulssige Frames aufgrund der Port-Security weiterhin verworfen werden. Denken Sie also stets daran, dass bei einer Schnittstelle mit dem Zustand connect oder up/up auch andere Grnde fr eine Nichtweiterleitung der 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-

Kapitel 3 Troubleshooting beim LAN-Switching

191

Adresse 0200.3333.3333 Frames an Port Fa0/13. Dieser Port ist jedoch auf den Empfang von Frames beschrnkt, die von 0200.1111.1111 gesendet wurden.
Listing 3.5: Port-Security im protect-Modus
SW1#show running-config ! Zeilen zur Abkrzung weggelassen interface FastEthernet0/13 switchport mode access switchport port-security switchport port-security mac-address 0200.1111.1111 switchport port-security 00000000000000000 violation protect ! Zeilen zur Abkrzung weggelassen SW1#show port-security interface Fa0/13 Port Security : Enabled Port Status : Secure-up Violation Mode : Protect Aging Time : 0 mins Aging Type : Absolute 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 Anzahl Frames vom PC mit der MAC-Adresse 0200.3333.3333 gesendet wurde. Aufgrund der konfigurierten Port-Security wurden alle diese Frames verworfen. Die Befehlsausgabe zeigt die MAC-Adresse 0200.3333.3333 des unzulssigen PC als Absender-MAC-Adresse des zuletzt empfangenen Frames an. Beachten Sie jedoch, dass der Port-Status als secure-up aufgefhrt ist und der Verstozhler den Wert 0 hat; diese beiden Angaben knnten von Ihnen dahingehend interpretiert werden, dass alles in Ordnung ist. Leider 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 Daten vom Endgert des Benutzers nicht dahin gelangen, wohin sie sollen. Wre in diesem Beispiel der Verstomodus restrict verwendet worden, so wre ebenfalls der Port-Zustand secure-up angezeigt worden, aber der Verstozhler wre pro unzulssigem Frame um den Wert 1 erhht worden.

192

CCNA ICND2-Prfungshandbuch

Bei den Prfungen kann ein Versto gegen die Port-Security durchaus kein Problem, sondern vielmehr die gewnschte Funktion darstellen. Mglicherweise gibt der Aufgabentext ausdrcklich an, was genau die Port-Security bewirken sollte. In solchen Fllen knnen Sie die Aufgabe schneller lsen, indem Sie sofort einen Blick auf die Konfiguration werfen. Vergleichen Sie die Konfiguration dann mit den MAC-Adressen der an die Schnittstelle angeschlossenen Gerte. Das wahrscheinlichste Problem besteht bei den Prfungsaufgaben darin, dass die MAC-Adressen fehlerhaft konfiguriert wurden, oder die Hchstanzahl der MAC-Adressen zu gering eingestellt wurde. (Kapitel 9 des CCENT/CCNA ICND1-Prfungshandbuches erlutert die Details der Konfigurationsanweisungen.) Ein letztes Sicherheitsmerkmal, welches noch kurz erwhnt werden soll, ist die IEEE 802.1x-Authentifizierung. IEEE 802.1x nicht zu verwechseln mit dem IEEE 802.3x-Standard fr das Autonegotiating definiert einen Prozess zur Authentifizierung des Benutzers eines PC, der an einen Switch-Port angeschlossen ist. 802.1x kann als Bestandteil einer NAC-Gesamtstrategie (Network Admission Control, Netzzugangssteuerung) verwendet werden, bei der ein LAN-Benutzer sein LAN erst benutzen kann, nachdem er zur Authentifizierung Anmeldeinformationen eingegeben hat. Bei 802.1x tauscht jeder Benutzer mit einem AAA-Server eine Reihe von Authentifizierungsnachrichten aus. Der Access-Switch horcht auf die Nachrichten auf dieser Verbindung und verwirft alle Frames mit Ausnahme von 802.1x-Nachrichten, die vom PC kommen bzw. an diesen gerichtet sind. Sobald der Switch eine Nachricht des AAA-Servers erkennt, die besagt, dass der Benutzer erfolgreich authentifiziert wurde, gestattet er den freien Datenfluss ber diesen Port. Konnte der Benutzer nicht authentifiziert werden, lsst der Switch keinen Datenverkehr ber diese Schnittstelle zu. Die Einzelheiten der 802.1x-Konfiguration und die Erkennung einer fehlgeschlagenen Authentifizierung als Grundursache eines bestimmten Problems sind nicht Gegenstand dieses Buches.

3.4.5

Schritt 4: VLAN- und Trunking-Probleme beheben

Der Weiterleitungsprozess eines Switchs hngt sowohl von der Definition der Access-VLANs an den Access-Schnittstellen als auch von den VLANTrunks 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 berprfungen bei VLAN-Problemen. Dieser Schritt umfasst die folgenden Manahmen:

Kapitel 3 Troubleshooting beim LAN-Switching 4. berprfen Sie VLANs und VLAN-Trunks wie folgt:

193

a) Ermitteln Sie alle Schnittstellen und die ihnen zugeordneten AccessVLANs und weisen diesen gegebenenfalls das korrekte VLAN zu. 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-Schnittstellen 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-Schnittstellen sich in den richtigen VLANs befinden
Um sicherzustellen, dass jede Access-Schnittstelle dem korrekten VLAN zugeordnet wurden, muss der Netzwerktechniker lediglich feststellen, welche Switch-Ports Access-Schnittstellen (und nicht Trunk-Schnittstellen) sind und welche Access-VLANs den einzelnen Schnittstellen zugeordnet sind, und die Ergebnisse dann mit der Dokumentation vergleichen. Die in Tabelle 3.5 aufgefhrten show-Befehle knnen dabei recht hilfreich sein.
Tabelle 3.5: Befehle zur Ermittlung von Access-Ports und VLANs
EXEC-Befehl
show vlan [brief] show vlan show interfaces type number switchport show mac address-table dynamic

Beschreibung Fhrt alle VLANs und alle den VLANs jeweils zugeordneten Schnittstellen auf, zeigt aber keine Trunks an. Ermittelt fr eine Schnittstelle das Access- bzw. VoiceVLAN sowie den administrativen (konfigurierten) und den aktiven Modus (Access oder Trunk). Listet MAC-Tabelleneintrge auf, d. h. MAC-Adressen mit zugehrigen Schnittstellen und VLANs.

Wichtig!

Sofern mglich, beginnen Sie diesen Schritt mit den Befehlen show vlan und show vlan brief, denn diese fhren alle bekannten VLANs und die ihnen jeweils zugeordneten Access-Schnittstellen auf. Beachten Sie jedoch, dass die Ausgabe dieser Befehle auch alle gegenwrtig nicht betriebsbereiten Trunking-Schnittstellen enthlt. Insofern listen diese Befehle Schnittstellen im Zustand notconnect oder err-disabled oder was in diesem Fall das Wichtigste ist auch Schnittstellen auf, die nach der Aktivierung zu Trunking-

194

CCNA ICND2-Prfungshandbuch

Schnittstellen werden. So kann die Befehlsausgabe etwa die Schnittstelle Gi0/2 in der Liste der Schnittstellen in VLAN 1 enthalten. Sobald jedoch Gi0/1 aktiv wird, knnte die Schnittstelle mit Trunking-Verhandlungen beginnen und wre von nun an keine Access-Schnittstelle mehr. Nachfolgend wird Gi0/2 in der Ausgabe von show vlan brief nicht mehr auftauchen. Falls die Befehle show vlan und show interface switchport bei einer bestimmten Prfungsfrage nicht verfgbar sind, kann das Access-VLAN auch mithilfe des Befehls show mac address-table ermittelt werden. Dieser Befehl listet die MAC-Adresstabelle auf, und zwar jeden Eintrag mit MAC-Adresse, Schnittstelle und VLAN-ID. Wenn laut Prfungsaufgabe eine Switch-Schnittstelle an einen PC angeschlossen ist, sollte nur ein einzelner MAC-Tabelleneintrag aufgefhrt sein, der genau diese Access-Schnittstelle auflistet. Die fr diesen Eintrag angegebene VLAN-ID bezeichnet das Access-VLAN. (Bei TrunkingSchnittstellen sind derartige Annahmen jedoch nicht mglich.) Verwenden Sie, wenn die Schnittstelle dem falschen VLAN zugeordnet ist, den Schnittstellenbefehl switchport access vlan vlan-id zur Zuordnung der korrekten VLAN-ID.

Nicht definierte oder inaktive Access-VLANs


Im nchsten Schritt 4b wird die Tatsache untersucht, dass ein Switch keine Frames in ein undefiniertes VLAN oder ein VLAN weiterleitet, das zwar definiert, aber nicht aktiv ist. Dieser Abschnitt fasst die Mglichkeiten zusammen, die Existenz eines bestimmten VLAN und seinen Zustand festzustellen. VTP-Server und -Clients zeigen beim Absetzen des Befehls show vlan nur ihre aktuelle Liste bekannter VLANs an. Die Dateien running-config und startup-config enthalten weder globale Konfigurationsbefehle des Typs vlan vlan-id, die das VLAN definieren, noch name-Befehle, mit denen ein VLAN benannt wird. Switches im transparenten Modus hingegen legen diese Konfigurationsbefehle sowohl in der Datei vlan.dat als auch in running-config ab; Sie knnen die Konfiguration also mit show running-config anzeigen. Wenn Sie feststellen, dass ein VLAN nicht existiert, lsst sich das Problem unter Umstnden dadurch lsen, dass das VLAN einfach definiert wird. Sollte dies der Fall sein, so fhren Sie eine VLAN-Konfiguration durch, wie sie in Kapitel 1 beschrieben ist. Hier noch einmal eine Zusammenfassung: Auf VTP-Servern und -Clients, bei denen Sie von einem laufenden VTP ausgehen: Das VLAN muss auf einem VTP-Server erstellt werden, wozu normalerweise der Befehl vlan vlan-id zum Einsatz kommt. Die anderen VTP-Server und -Clients erlernen das VLAN nachfolgend. Das VLAN kann sofern noch nicht vorhanden auch als Folge des Schnittstellen-

Kapitel 3 Troubleshooting beim LAN-Switching

195

befehls switchport access vlan vlan-id automatisch auf dem VTP-Server erstellt werden. Auf VTP-Servern und -Clients, bei denen Sie nicht von einem laufenden VTP ausgehen: Fhren Sie die in Kapitel 1 beschriebene Behebung von VTP-Problemen durch. Auf einem Switch im transparenten VTP-Modus: Die Konfiguration ist identisch mit der auf einem Server, muss aber auf jedem Switch separat erfolgen, weil Switches im transparenten VTP-Modus das neue VLAN gegenber anderen Switches nicht bekannt geben. Prfen Sie bei vorhandenen VLANs auch, ob das VLAN aktiv ist. Der Befehl show vlan sollte einen von zwei VLAN-Zustandswerten ausgeben: active oder act/lshut. 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. Beachten Sie, dass dieser Befehl auf jedem Switch abgesetzt werden muss, weil der Zustand shutdown nicht via VTP weitergemeldet wird.

Trunks und darber weitergeleitete VLANs ermitteln


In Schritt 4c knnen Sie die Probleme zu Beginn der Eingrenzung in zwei allgemeine Kategorien unterteilen: Probleme bei der Funktion eines betriebsbereiten Trunks und Probleme, die dadurch verursacht werden, dass eine Schnittstelle, die eine Trunking-Schnittstelle sein sollte, nicht als solche 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 dieser Ausgabe, denn dort sind die VLANs aufgefhrt, deren Daten ber den Trunk weitergeleitet werden. VLANs, die es bis in diese abschlieende VLAN-Liste schaffen, weisen die folgenden Kriterien auf: Das VLAN ist auf dem 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, der mit dem Schnittstellenbefehl switchport trunk allowed vlan konfiguriert wurde. Das VLAN wurde nicht via VTP-Pruning aus dem Trunk entfernt (was automatisch geschieht, wenn das VTP-Pruning mit dem globalen Konfigurationsbefehl vtp pruning aktiviert wurde).
Wichtig!

196

CCNA ICND2-Prfungshandbuch

Der Trunk befindet sich in diesem LAN im STP-Zustand Forwarding. Dies geht auch aus der Ausgabe des Befehls show spanning-tree vlan vlanid 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.
Listing 3.6: Listen der zulssigen und der aktiven VLANs
SW1#show interfaces trunk Port Gi0/1 Port Gi0/1 Port Gi0/1 Port Gi0/1 Mode desirable Encapsulation Status 802.1q trunking Native vlan 1

Vlans allowed on trunk 1-2,4-4094 Vlans allowed and active in management domain 1,4 Vlans in spanning tree forwarding state and not pruned 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, sofern 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 drei in der Ausgabe von show interfaces trunk enthaltenen Listen zeigen in fortschreitender Form, warum ein VLAN gegebenenfalls nicht ber einen Trunk weitergeleitet wird. Um sich die Details in Gedchtnis zu rufen, wiederholen Sie noch einmal das zu Listing 1.4 in Kapitel 1 beschriebene Szenario einschlielich der einleitenden Abstze. Auch die native VLAN-Konfiguration eines Trunks sollte in diesem Schritt berprft werden. Die ID des nativen VLAN kann an beiden Enden des Trunks manuell auf unterschiedliche VLANs gesetzt werden. Falls sich die nativen VLANs 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 aus, dass der Frame zum fr SW2 kon-

Kapitel 3 Troubleshooting beim LAN-Switching

197

figurierten 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. Die zweite allgemeine Kategorie von Trunking-Problemen ist dadurch gekennzeichnet, dass eine Schnittstelle, fr die das Trunking konfiguriert wurde, kein Trunking durchfhrt. Die wahrscheinlichste Ursache dieses Problems ist eine unterschiedliche Trunking-Konfiguration an beiden Enden der Verbindung. Mit dem Schnittstellenbefehl switchport mode {access | trunk | dynamic {desirable | auto}} legen Sie fest, ob das Trunking fr die Schnittstelle aktiviert und wie es verhandelt werden soll. Mit dem Befehl show interface switchport zeigen Sie fr jede Schnittstelle den konfigurierten TrunkingModus an. Vergewissern Sie sich, dass Sie die Bedeutung aller Optionen dieses Konfigurationsbefehls (vgl. Kapitel 1, Tabelle 1.4) und die Kombinationen an den Enden des Segments, die zum Trunking fhren (vgl. Kapitel 1, Tabelle 1.5), verstanden haben. In einigen Fllen misslingt das Trunking fr eine Schnittstelle 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 TrunkingTypen (d. h. die Kapselung) nicht zueinander passen.

3.4.6

Problembehebung auf der Datenebene (Beispiel)

Dieser Abschnitt zeigt exemplarisch, wie man die beschriebenen Schritte auf ein bestimmtes Netzwerk anwendet. Das Szenario umfasst mehrere Probleme des in Abbildung 3.5 gezeigten Netzwerks. Anfangs knnen PC1, PC2 und PC3 nicht erfolgreich Ping-Befehle an das Default-Gateway R1 (IPAdresse 2.2.2.9) absetzen. Dieser Abschnitt zeigt, wie man die Probleme mithilfe der bislang in diesem Kapitel behandelten Verfahren erkennt und behebt. Zunchst wollen wir die einzelnen Schritte in einer bersicht zusammenfassen: 1. berprfen Sie mithilfe von CDP das Netzdiagramm auf Richtigkeit und Vollstndigkeit hin. 2. berprfen Sie wie folgt Schnittstellenprobleme: a) Bestimmen Sie den oder die Schnittstellenstatuscodes fr jede erforderliche Schnittstelle. Befindet sich eine Schnittstelle nicht im Verbindungszustand (up/up), so beheben Sie alle Probleme, bis die Schnittstelle diesen Zustand erreicht.
Wichtig!

198

CCNA ICND2-Prfungshandbuch

b) Prfen Sie bei Schnittstellen, die sich im Verbindungszustand (up/up) befinden, ferner auf zwei weitere Probleme hin: Duplexfehlanpassungen und Varianten der Port-Security, bei denen gezielt Frames verworfen werden. 3. berprfen Sie wie folgt die Port-Security-Funktion: a) Ermitteln Sie mit show running-config oder show port-security alle Schnittstellen, fr die die Port-Security aktiviert wurde. b) Ermitteln Sie, ob gegenwrtig ein Sicherheitsversto im Sinne des in der Port-Security-Konfiguration angegebenen Parameters violation mode erfolgt: shutdown: Die Schnittstelle befindet sich im Zustand err-disabled. restrict: Die Schnittstelle befindet sich im Zustand connect, aber der Befehl show port-security interface zeigt einen ansteigenden Wert fr den Verstozhler. protect: Die Schnittstelle befindet sich im Zustand connect, und der Befehl show port-security interface zeigt keinen ansteigenden Wert fr den Verstozhler. c) Vergleichen Sie in jedem Fall die Konfiguration der Port-Security mit dem Diagramm und mit dem Feld last source address in der Ausgabe des Befehls show port-security interface. 4. berprfen Sie VLANs und VLAN-Trunks wie folgt: a) Ermitteln Sie alle Schnittstellen und die ihnen zugeordneten AccessVLANs und weisen diesen gegebenenfalls das korrekte VLAN zu. 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-Schnittstellen an jedem Switch und bekommen Sie heraus, welche VLANs ber die jeweiligen Trunks weitergeleitet werden knnen.

Kapitel 3 Troubleshooting beim LAN-Switching


2.2.2.1 0200.1111.1111

199

PC1
Fa0/11 Gi0/1 Gi0/2 Fa0/10 Fa0/1

PC2

SW1
Fa0/12 Gi0/2 Gi0/1

SW2

R1
2.2.2.9 0200.0101.0101

2.2.2.2 0200.2222.2222 Gi0/1 Gi0/2

SW3
Fa0/13

PC3

2.2.2.3 0200.3333.3333

Abbildung 3.5: Netzwerk aus dem Problembehebungsbeispiel

Schritt 1: Richtigkeit des Netzwerkdiagramms mit CDP berprfen


Listing 3.7 zeigt einen Groteil der Befehlsausgabe fr 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 Schnittstellen in der Abbildung berprfen. Die einzige Abweichung besteht darin, dass auf SW2 die Schnittstelle Fa0/9 und nicht wie in der Abbildung gezeigt die Schnittstelle 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 Device ID d ddLocal Intrfce Holdtme Capability Platform Port ID SW2 Gig 0/1 122 S I WS-C2960-2 Gig 0/2 SW3 Gig 0/2 144 S I WS-C3550-2 Gig 0/1 ! Es folgen Befehle auf 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 Device ID d ddLocal Intrfce SW1 000 Gig 0/2 0000000 SW3 000 Gig 0/1 0000000 R1 000 Fas 0/9 0000000 Holdtme 125 170 157 Capability Platform Port ID S I dddddd WS-C2960-2 Gig 0/1 S I dddddd WS-C3550-2 Gig 0/2 R S I dd ddd1841 dddddddFas 0/1

200

CCNA ICND2-Prfungshandbuch

Listing 3.7: Abbildung 3.5 mit CDP verifizieren (Forts.)


SW2#show cdp entry R1 ------------------------Device ID: R1 Entry address(es): IP address: 2.2.2.10 Platform: Cisco 1841, Capabilities: Router Switch IGMP Interface: FastEthernet0/9, Port ID (outgoing port): FastEthernet0/1 0000000000000000000000000000000000000000 Holdtime : 150 sec Version : Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(9)T, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright 1986-2006 by Cisco Systems, Inc. Compiled Fri 16-Jun-06 21:26 by prod_rel_team advertisement version: 2 VTP Management Domain: Duplex: full Management address(es): ! Es folgen Befehle auf 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 Device ID d ddLocal Intrfce SW1 000 Gig 0/1 0000000 SW2 000 Gig 0/2 0000000 Holdtme 154 178 Capability Platform S I dddddd WS-C2960-2 S I dddddd WS-C2960-2 Port ID Gig 0/2 Gig 0/1

Dieser Fehler in der Dokumentation die statt Fa0/9 flschlicherweise angegebene Schnittstelle hat keine Auswirkungen auf den Netzwerkbetrieb. Wre allerdings zwischen SW2 und R1 ein Trunking erforderlich gewesen, dann htte dieses fr die Schnittstelle Fa0/9 nicht fr Fa0/10! explizit konfiguriert werden mssen, weil Router die Verwendung des Trunkings nicht automatisch verhandeln. Kapitel 4, IP-Routing: Statische und verbundene Routen, beschreibt die Trunking-Konfiguration fr Router ausfhrlich. Beachten Sie, dass CDP keine Fehler in der Dokumentation bei Schnittstellen erkennt, die mit PCs verbunden sind. Im vorliegenden Beispiel wollen wir davon ausgehen, dass die brigen in Abbildung 3.5 gezeigten Schnittstellen korrekt sind.

Kapitel 3 Troubleshooting beim LAN-Switching

201

Schritt 2: Auf Schnittstellenprobleme hin prfen


Im nchsten Schritt untersuchen wir den Status aller Schnittstellen, 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 Schnittstellen auf SW2 korrekt funktionieren.) Studieren Sie die Ausgabe, identifizieren Sie erkannte Probleme und erstellen Sie basierend auf der Ausgabe eine Liste weiterer schnittstellenbezogener Probleme, die Sie nher untersuchen wollen.
Listing 3.8: Schnittstellenprobleme auf SW1
SW1#show interfaces fa0/11 status Port Name Status Vlan Fa0/11 connected 3 SW1#show interfaces fa0/12 status Port Name Status Vlan Fa0/12 notconnect 3 SW1#show interfaces Gi0/1 status Port Name Status Vlan Gi0/1 connected trunk SW1#show interfaces Gi0/2 status Port Name Status Vlan Gi0/2 connected 1 ! Wechsel zu SW3 SW3#sh interfaces fa0/13 status Port Name Status Vlan Fa0/13 connected 3 SW3#show interfaces Gi0/1 status Port Name Status Vlan Gi0/1 connected 1 SW3#show interfaces Gi0/2 status Port Gi0/2 Name Status Vlan connected trunk Duplex a-full Speed Type a-100 10/100BaseTX

Duplex auto

Speed Type auto 10/100BaseTX

Duplex Speed Type a-full a-1000 10/100/1000BaseTX

Duplex Speed Type a-full a-1000 10/100/1000BaseTX

Duplex a-half

Speed Type a-100 10/100BaseTX

Duplex Speed Type a-full a-1000 1000BaseTX

Duplex Speed Type a-full a-1000 1000BaseTX

Ein auf SW1 vorhandenes Problem ist offensichtlich: Die Schnittstelle Fa0/ 12 hat den Zustand 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

202

CCNA ICND2-Prfungshandbuch

eingesteckten Kabel bis hinzu schwer ermittelbaren Problemen mit elektrischen Strungen. (Mgliche Ursachen knnen Sie Tabelle 3.2 entnehmen.) Fr die Schnittstellen von SW3 lassen sich offenbar keine Probleme feststellen. Allerdings weisen alle drei Schnittstellen eine Duplexeinstellung auf, die derjenigen entspricht, die ein Switch verwenden wrde, wenn das Autonegotiating fehlgeschlagen ist; auffllig ist die Verwendung der Halbduplexeinstellung auf Schnittstelle Fa0/3. Dies verweist auf die Mglichkeit eines der beiden im Verlauf dieses Kapitels erwhnten Schnittstellenprobleme, die auch dann auftreten knnen, wenn die Schnittstelle sich im connect-Zustand befindet genauer gesagt, um eine Fehlanpassung bei den Duplexeinstellungen. Eine Fehlanpassung der SW3-Schnittstellen Gigabit 0/1 und 0/2 knnen Sie ganz einfach ausschlieen, indem Sie den Befehl show interfaces am jeweils anderen Ende dieser beiden Verbindungen auf den Switches SW1 und SW2 absetzen. Allerdings sind Ports, die mit einem PC verbunden sind, bei der Problembehebung schwierig zu handhaben, weil Sie sich wahrscheinlich nicht gerade in der Nhe des betreffenden PC befinden, um den Benutzer bei der Durchfhrung der Schritte anzuleiten, die zu berprfung der Geschwindigkeits- und Duplexeinstellungen erforderlich sind. Trotzdem ist es sinnvoll, nach verrterischen Hinweisen auf Runts, Kollisionen und frhe Kollisionen zu suchen, wie sie in der Ausgabe des Befehls show interfaces in Listing 3.9 auftauchen.
Listing 3.9: Hinweise auf Fehlanpassung bei den Duplexeinstellungen
SW3#show interfaces fa0/13 FastEthernet0/13 is up, line protocol is up (connected) Hardware is Fast Ethernet, address is 000a.b7dc.b78d (bia 000a.b7dc.b78d) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set 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 108 packets input, 6946 bytes, 0 no buffer Received 3 broadcasts (0 multicast)

Kapitel 3 Troubleshooting beim LAN-Switching


Listing 3.9: Hinweise auf Fehlanpassung bei den Duplexeinstellungen (Forts.)
54 runts, 0 giants, 0 throttles 00000000 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 2 multicast, 0 pause input 0 input packets with dribble condition detected 722 packets output, 52690 bytes, 0 underruns 0 output errors, 114 collisions, 5 interface resets 00000000000000 0 babbles, 00000000000000000 19 deferred 78 late collision, 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out

203

In diesem Fall liegt tatschlich eine Fehlanpassung vor. 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 wurde die Konfiguration von SW3 so gendert, dass der Vollduplexbetrieb auf Fa0/13 verwendet wurde, um eine bereinstimmung mit der manuellen Einstellung auf PC3 zu erzielen.

Schritt 3: Port-Security prfen


Im nun folgenden Schritt untersuchen wir die Konfiguration der Port-Security 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 Schnittstellen 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 Port-Security aktiviert ist. Studieren Sie das Listing 3.10 und machen Sie sich vor dem Weiterlesen ein paar Notizen dazu, welche weiteren Schritte Port-Security als potenzielle Problemquelle ausschlieen, und/oder mit welchem Befehl Sie ein mgliches Problem eingrenzen wrden.
Listing 3.10: Port-Security auf SW1 und SW2
SW1#show port-security Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action (Count) (Count) (Count) --------------------------------------------------------------------------Fa0/11 1 1 97 Restrict --------------------------------------------------------------------------Total Addresses in System (excluding one mac per port) : 0 Max Addresses limit in System (excluding one mac per port) : 8320 ! Auf SW2 ist die Port-Security fr keine Schnittstelle aktiviert.

204

CCNA ICND2-Prfungshandbuch

Listing 3.10: Port-Security auf SW1 und SW2 (Forts.)


SW2#show port-security Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action (Count) (Count) (Count) ----------------------------------------------------------------------------------------------------------------------------------------------------Total Addresses in System (excluding one mac per port) : 0 Max Addresses limit in System (excluding one mac per port) : 8320

Die show port-security-Befehle im Listing fhren die Schnittstellen auf, auf denen die Port-Security aktiviert wurde. Es handelt sich lediglich um die Schnittstelle Fa0/11 auf SW1 Schnittstellen auf SW2 sind nicht betroffen. Auf SW1 sollten Sie zur Problembehebung zunchst einmal festgestellt haben, dass unter der berschrift, Security Action fr den Verstomodus die Aktion Restrict angegeben ist. Bei dieser Einstellung kann die Port-Security auch dann, wenn die SW1-Schnittstelle Fa0/11 sich im Zustand connect befindet (vgl. Listing 3.8), Daten verwerfen, die gegen die Port-SecurityKonfiguration 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 : 00000000 Restrict Aging Time : 0 mins Aging Type : Absolute 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 der MAC-Adresse von PC1 entspricht. SW1#show running-config interface fa0/11 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

Kapitel 3 Troubleshooting beim LAN-Switching


Listing 3.11: Port-Security auf SW1 und SW2 (Forts.)

205

! ! Die folgende Log-Nachricht signalisiert auch ein Port-Security-Problem. 01:46:58: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0200.1111.1111 on port FastEthernet0/11.

Das Listing beginnt mit Angaben zum Port-Security-Modus und zum Verstozhler und zeigt auch die letzte MAC-Adresse an, die einen Frame an die Schnittstelle Fa0/11 gesendet hat (nmlich 0200.1111.1111). Die MACAdresse von PC1 (0200.1111.1111) entspricht nicht der Port-Security-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 PortSecurity so umzukonfigurieren, dass sie die MAC-Adresse von PC1 angibt. Beachten Sie, dass der Netzwerktechniker die Befehle shutdown und nachfolgend no shutdown fr den Neustart dieser Schnittstelle nicht absetzen muss, denn die Konfiguration verwendet den Verstomodus restrict, der die Schnittstelle laufen lsst und nur Daten von und an PC1 verwirft. Am Ende des Listings schlielich findet sich eine Log-Nachricht, die vom Switch fr jeden Versto im restrict-Modus generiert wird. Diese Nachricht wrde normalerweise auf der Konsole ausgegeben. ber eine Telnet- oder SSH-Verbindung (Secure Shell) zum Switch wird sie nur dann ausgegeben, wenn der Remote-Benutzer den EXEC-Befehl terminal monitor eingibt.

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


Schritt 4a beginnt mit einer Untersuchung der Access-Schnittstellen, um sicherzustellen, dass diese den korrekten VLANs zugewiesen wurden. In diesem Fall sollten alle Schnittstellen 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.
Listing 3.12: VLAN-Zuordnung von Access-Schnittstellen berprfen
SW1#show interfaces fa0/11 status Port Name Status Fa0/11 connected SW1#show interfaces fa0/12 status Port Fa0/12 Name Vlan 3 Duplex Speed Type a-full a-100 10/100BaseTX

Status Vlan notconnect 3

Duplex Speed Type auto auto 10/100BaseTX

206

CCNA ICND2-Prfungshandbuch

Listing 3.12: VLAN-Zuordnung von Access-Schnittstellen berprfen (Forts.)


! Es folgt SW2 SW2#show interfaces status ! Zeilen zur Abkrzung weggelassen Fa0/9 connected 1 Fa0/10 notconnect 3 ! Es folgt SW3 SW3#show interfaces fa0/13 status Port Fa0/13 Name Status connected Vlan 3

a-full auto

a-100 10/100BaseTX auto 10/100BaseTX

Duplex Speed Type full a-100 10/100BaseTX

Das einzige Problem besteht in diesem Fall darin, dass zwar nach Vorgabe der Zeichnung die Schnittstelle 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). Schnittstelle Fa0/9 ist durch die Default-Einstellung Bestandteil von VLAN 1. Um dieses spezielle Problem zu beheben, setzen wir auf SW2 den Schnittstellenbefehl switchport access vlan 3 fr die Schnittstelle 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, das VLAN 3 tatschlich auf allen Switches bekannt ist. Suchen Sie beim Lesen des Listings nach Problemen mit VLAN 3.
Listing 3.13: Halbduplexproblem ermitteln
SW1#show vlan id 3 VLAN Name Status Ports ---- ---------------------------- --------- ------------------------------3 book-vlan3 active Fa0/11, Fa0/12, Gi0/1, Gi0/2 ! Zeilen zur Abkrzung weggelassen ! Es folgt SW2. SW2#show vlan brief VLAN Name Status Ports ---- ---------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/11, Fa0/12, Fa0/13, Fa0/14 Fa0/15, Fa0/16, Fa0/17, Fa0/18 Fa0/19, Fa0/20, Fa0/21, Fa0/22 Fa0/23, Fa0/24 3 VLAN0003 active Fa0/9, Fa0/10 ! Zeilen zur Abkrzung weggelassen

Kapitel 3 Troubleshooting beim LAN-Switching


Listing 3.13: Halbduplexproblem ermitteln (Forts.)
! Es folgt SW3. SW3#show vlan brief

207

VLAN Name Status Ports ---- ---------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/10, Fa0/11, Fa0/12 Fa0/14, Fa0/15, Fa0/16, Fa0/17 Fa0/18, Fa0/19, Fa0/20, Fa0/21 Fa0/22, Fa0/23, Fa0/24 3 book-vlan3 active Fa0/13 ! Zeilen zur Abkrzung weggelassen

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. Wie sich herausstellt, verwendet SW2 den transparenten VTP-Modus, wobei SW1 als VTP-Client und SW3 als VTPServer benutzt werden. Insofern ist der Name von VLAN 3 (book-vlan3) auf den Switches SW1 und SW3 identisch. Der letzte Teilschritt 4c schlielich empfiehlt, den Status aller vorgesehenen Trunk-Schnittstellen 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 Gi0/1 Gi0/2 Port Gi0/1 Gi0/2 Port Gi0/1 Gi0/2 Mode desirable desirable Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 1 1

Vlans allowed on trunk 1-4094 1-4094 Vlans allowed and active in management domain 1,3 1,3

208

CCNA ICND2-Prfungshandbuch

Listing 3.14: Trunking und VLAN 3 berprfen (Forts.)


Port Vlans in spanning tree forwarding state and not pruned Gi0/1 3 Gi0/2 1,3 ! Es folgt SW2. SW2#show interfaces trunk Port Gi0/1 Gi0/2 Port Gi0/1 Gi0/2 Port Gi0/1 Gi0/2 Mode auto auto Encapsulation 802.1q 802.1q Status trunking trunking Native vlan 1 1

Vlans allowed on trunk 1-4094 1-4094 Vlans allowed and active in management domain 1,3 1,3

Port Vlans in spanning tree forwarding state and not pruned Gi0/1 1,3 Gi0/2 1 ! Es folgt SW3. SW3#show interfaces trunk Port Gi0/1 Gi0/2 Port Gi0/1 Gi0/2 Port Gi0/1 Gi0/2 Port Gi0/1 Gi0/2 Mode auto desirable Encapsulation Status n-802.1q trunking n-802.1q trunking Native vlan 1 1

Vlans allowed on trunk 1-4094 1-4094 Vlans allowed and active in management domain 1,3 1,3 Vlans in spanning tree forwarding state and not pruned 1,3 1,3

Durch eine Untersuchung des letzten Teils der show interfaces trunk-Ausgabe auf den einzelnen Switches knnen Sie feststellen, dass von beiden TrunkingSchnittstellen auf den Switches nur die Schnittstelle Gi0/2 von SW2 keine Daten in VLAN 3 weiterleitet. Weiter oben in diesem Kapitel wurden unter

Kapitel 3 Troubleshooting beim LAN-Switching

209

der berschrift Trunks und darber weitergeleitete VLANs ermitteln vier Grnde dafr aufgefhrt, warum ein VLAN aus einem Trunk ausgeschlossen wird. Drei dieser vier Grnde knnen aufgrund der Ausgabe in Listing 3.14 und einigen anderen Listings in diesem Kapitel ausgeschlossen werden. Zunchst wrde VLAN 3, wenn es ausgeschlossen wrde, weil es sich nicht auf der Liste der zulssigen VLANs befindet, sich nicht auf den ersten beiden VLAN-Listen des auf SW2 abgesetzten Befehls show interfaces trunk befinden. Auch das VTP-Pruning lsst sich als Ursache ausschlieen, weil bereits frhere Listings gezeigt haben, dass alle drei Switches ber jeweils mindestens eine Schnittstelle in VLAN 3 und im Zustand connect verfgen. Das bedeutet, dass auch dann, wenn alle drei Switches VTP korrekt verwenden, VLAN 3 auch bei aktiviertem VTP-Pruning nicht entfernt wrde. Insofern wird VLAN 3 in diesem Fall aufgrund von STP nicht weitergeleitet. 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.

3.5

Prognose des Normalbetriebs der LAN-Switching-Datenebene

Ein Schritt bei der Problembehebung besteht darin, zu analysieren, was geschehen sollte, um das Ergebnis dann mit dem zu vergleichen, was tatschlich geschieht und auf diese Weise hoffentlich die Ursache vorhandener Probleme einzugrenzen. Dieser letzte Abschnitt in Kapitel 3 schliet unsere Untersuchung der Frage ab, wie LANs funktionieren sollten: Hier werden zwei Beispiele beschrieben, bei denen Frames ber eine funktionsfhige Version des Netzwerks weitergeleitet werden, das wir im vorangegangenen Abschnitt bereits verwendet haben. Das Ziel dieses Abschnitts besteht darin, zu erlutern, wie man die aktuelle show-Ausgabe bei Switches interpretiert. Damit lsst sich vorhersagen, wohin die Switches jeweils einen bestimmten Frame weiterleiten. Das erste Beispiel zeigt einen Broadcast, der von PC1 in Abbildung 3.5 gesendet wurde, das zweite stellt den Weiterleitungsprozess fr einen Unicast-Frame dar, der von R1 an die MAC-Adresse von PC1 bermittelt wurde.

3.5.1

Broadcast von PC1 in VLAN 1

Das erste funktionsfhige Beispiel der Datenebene untersucht den Pfad eines Broadcasts, der von PC1 gesendet wurde. PC1 verfgt in seinem ARP-Cache vielleicht nicht ber die MAC-Adresse von R1 und sendet deswegen einen ARP-Broadcast mit der IP-Zieladresse 255.255.255.255 und der Ethernet-

210

CCNA ICND2-Prfungshandbuch

Zieladresse FFFF.FFFF.FFFF. In diesem Abschnitt wollen wir untersuchen, was die verschiedenen Switches tun, um den Broadcast an alle Komponenten von VLAN 3 weiterzuleiten (siehe Abbildung 3.6).
0200.1111.1111

PC1
Fa0/11 Fa0/9 Fa0/1

SW1 PC2
Fa0/12

Gi0/1 Gi0/2

Gi0/2 Gi0/1

SW2

R1
0200.0101.0101

0200.2222.2222 Gi0/1 Gi0/2

SW3
Fa0/13

PC3

Abbildung 3.6: Weiterleitungspfad von PC1 an R1 entsprechend Listing 3.14

Um den Weg des Broadcasts zu analysieren, orientieren Sie sich am allgemeinen Weiterleitungsvorgang, wie er im Abschnitt Der normale Weiterleitungsvorgang bei LAN-Switches weiter oben in diesem Kapitel zusammengefasst wurde. Frhere Listings besttigten, dass der SW1-Port Fa0/11 VLAN 3 zugewiesen ist und es sich bei dieser Schnittstelle um einen AccessPort handelt. Da der Frame ein Broadcast ist, flutet SW1 diesen. Wenn Sie all dies wissen, vermittelt Ihnen Listing 3.15 ein Ausgabe des Befehls show spanning-tree vlan 3 active gengend Informationen um festzustellen, ber welche Schnittstellen SW1 diesen von PC1 gesendeten Broadcast-Frame weiterleitet.
Listing 3.15: Liste der aktiven Schnittstellen auf SW1
SW1#show spanning-tree vlan 3 active VLAN0003 Spanning tree enabled protocol ieee Root ID Priority 24579 Address 000a.b7dc.b780 Cost 1 Port 26 (GigabitEthernet0/2) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Kapitel 3 Troubleshooting beim LAN-Switching


Listing 3.15: Liste der aktiven Schnittstellen auf SW1 (Forts.)
Bridge ID Priority 32771 (priority 32768 sys-id-ext 3) Address 0019.e86a.6f80 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Role Sts Cost ---- --- --------Desg FWD 19 000 Desg FWD 4 000 Root FWD 1 000

211

Interface ---------------Fa0/11 000000 Gi0/1 000000 Gi0/2 000000

Prio.Nbr Type -------- -------------------------------128.11 P2p 128.25 P2p 128.26 P2p

Beachten Sie, dass SW1 den Frame nicht wieder ber Fa0/11 ausgibt, da er ber diese Schnittstelle empfangen wurde. Auerdem leitet SW1 den Frame ber seine beiden Trunk-Schnittstellen Gi0/1 und Gi0/2 weiter. Zudem zeigt Listing 3.14 weiter oben in diesem Kapitel, dass die beiden Trunks von SW1 802.1Q mit dem nativen VLAN 1 verwenden, das heit, 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 an der Schnittstelle Gi0/2 empfangene Kopie des Broadcast-Frames verworfen. SW2 verwirft den Frame aufgrund von Schritt 3 des allgemeinen Weiterleitungsprozesses (siehe oben), weil die SW2-Eingangsschnittstelle Gi0/2 sich im VLAN 3 im Zustand Blocking befindet. (Dies geht aus Listing 3.14 und dem sich an dieses Listing anschlieenden Text hervor.) Beachten Sie, dass der Zustand Blocking 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 seiner Schnittstelle 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 die eingehende Schnittstelle sich im STP-Zustand Forwarding befindet. Basierend auf diesen Tatsachen leitet SW3 den Frame innerhalb von VLAN 3 weiter. Listing 3.16 zeigt alle Informationen, die notwendig sind, um festzustellen, ber welche Schnittstellen SW3 den Broadcast aus VLAN 3 weiterleitet.

212

CCNA ICND2-Prfungshandbuch

Listing 3.16: SW3: Weiterleitung eines Broadcasts in VLAN 3


SW3#show mac address-table dynamic vlan 3 Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ------------------------3 0200.0101.0101 DYNAMIC Gi0/2 3 0200.1111.1111 DYNAMIC Gi0/1 3 0200.3333.3333 DYNAMIC Fa0/13 Total Mac Addresses for this criterion: 3 SW3#show spanning-tree vlan 3 active VLAN0003 Spanning tree enabled protocol ieee Root ID Priority 24579 Address 000a.b7dc.b780 This bridge is the root Hello Time 2 sec Max Age 20 sec Bridge ID

Forward Delay 15 sec

Priority 24579 (priority 24576 sys-id-ext 3) Address 000a.b7dc.b780 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 Role ---Desg Desg Desg Sts --FWD 000 FWD 000 FWD 000 Cost --------19 4 4 Prio.Nbr -------128.13 128.25 128.26 Type -----------------------------P2p P2p P2p

Interface ---------------Fa0/13 000000 Gi0/1 000000 Gi0/2 000000

Wie SW1 leitet auch SW3 den Broadcast nicht ber dieselbe Schnittstelle weiter, ber die der Frame empfangen wurde (in diesem Fall Gi0/1), flutet ihn aber ber alle andere Schnittstellen in diesem VLAN, die sich im STPZustand Forwarding befinden hier also Fa0/13 und Gi0/2. Auerdem fgt, weil seine Schnittstelle 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 seine Schnittstelle 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 die Eingangsschnittstelle im Zustand Forwarding befindet, und flutet den Broadcast ber alle Schnittstellen, die sich in VLAN 3 und im STP-Zustand Forwarding befin-

Kapitel 3 Troubleshooting beim LAN-Switching

213

den. In diesem Fall leitet SW2 den Frame nur ber die Schnittstelle Fa0/9 weiter, die mit dem Router R1 verbunden ist. Listing 3.17 zeigt die dazugehrigen Ausgaben.
Listing 3.17: Weiterleitung eines von SW3 empfangenen Broadcasts in VLAN 3 durch SW2
! Beachten Sie, dass die Broadcast-Adresse FFFF.FFFF.FFFF nicht in der ! MAC-Tabelle von VLAN 3 enthalten ist. SW2#show mac address-table dynamic vlan 3 Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ------------------------3 000a.b7dc.b79a DYNAMIC Gi0/1 3 0200.0101.0101 DYNAMIC Fa0/9 3 0200.1111.1111 DYNAMIC Gi0/1 3 0200.3333.3333 DYNAMIC Gi0/1 Total Mac Addresses for this criterion: 4 ! Beachten Sie nun, dass sich Fa0/9 und Gi0/1 im STP-Zustand Forwarding ! 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 zur Abkrzung weggelassen Interface ---------------Fa0/9 00000 Gi0/1 00000 Gi0/2 00000 Role ---Desg Root Altn Sts --000 FWD 000 FWD 000 BLK Cost --------19 4 4 Prio.Nbr -------128.9 128.25 128.26 Type -----------------------------P2p P2p P2p

SW2 leitet den Frame nicht ber Gi0/1 weiter, da der Frame an dieser Schnittstelle empfangen wurde.

3.5.2

Weiterleitungspfad eines Unicasts von R1 zu PC1

Das zweite Beispiel in der Datenebene untersucht, wie Switches UnicastFrames weiterleiten. Um den Weiterleitungsprozess fr Unicast-Frames zu analysieren, betrachten Sie zunchst die ARP-Antwort, die als Reaktion auf die ARP-Anfrage/den Broadcast von PC1 gesendet wird. Die IP- und MACZieladressen in der ARP-Antwort von R1 stimmen mit den entsprechenden Adressen von PC1 berein. Abbildung 3.7 zeigt den Weiterleitungspfad. Die nachfolgenden Listings veranschaulichen, wie der universelle Vorgang der Frame-Weiterleitung in diesem speziellen Fall angewendet wird.

214

CCNA ICND2-Prfungshandbuch

0200.1111.1111

PC1
Fa0/11

Gi0/1

Gi0/2

Fa0/9

Fa0/1

SW1
Fa0/12

SW2
Gi0/2 Gi0/1

R1
0200.0101.0101

PC2

0200.2222.2222

Gi0/1 Gi0/2

SW3
Fa0/13

PC3

Abbildung 3.7: Weiterleitungspfad von R1 an PC1 entsprechend Listing 3.15

Wenn SW2 den Frame von R1 erhlt, stellt er fest, dass der Frame ber die Schnittstelle Fa0/9 eingegangen ist, bei der es sich um eine Access-Schnittstelle im VLAN 3 handelt. Am Ende von Listing 3.17 befand sich Fa0/9 im STP-Zustand Forwarding in VLAN 3, das heit, SW2 wird versuchen, den Frame weiterzuleiten, statt ihn zu verwerfen. Im nun folgenden Listing 3.18 sehen wir, dass in der MAC-Adresstabelle von SW2 die MAC-Adresse von PC1 0200.1111.1111 als ber die Schnittstelle Gi0/1 erreichbar und in VLAN 3 befindlich aufgefhrt wird; SW2 leitet den Frame also ber Gi0/1 an SW3 weiter.
Listing 3.18: Logik von SW2 bei der Weiterleitung eines bekannten Unicasts an PC1
SW2#show mac address-table dynamic vlan 3 Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ------------------------3 000a.b7dc.b79a DYNAMIC Gi0/1 3 0200.0101.0101 DYNAMIC Fa0/9 3 0200.1111.1111 DYNAMIC Gi0/1 Total Mac Addresses for this criterion: 3

Wenn SW3 den Frame von SW2 erhlt, stellt er fest, dass der Frame ber die Schnittstelle Gi0/2 einging, bei der es sich um eine Trunking-Schnittstelle handelt; im Trunking-Header ist VLAN ID 3 aufgefhrt. Am Ende von Listing 3.16 befand sich Gi0/2 im STP-Zustand Forwarding in VLAN 3

Kapitel 3 Troubleshooting beim LAN-Switching

215

(Weiterleitungsschritt 3), SW3 wird somit den Frame aufgrund des STPZustandes nicht verwerfen. Im nachfolgenden Listing 3.19 sehen wir, dass in der MAC-Adresstabelle von SW3 die MAC-Adresse von PC1 0200.1111.1111 als ber die Schnittstelle Gi0/1 erreichbar und in VLAN 3 befindlich aufgefhrt wird; SW3 leitet den Frame also ber Gi0/1 an SW1 weiter.
Listing 3.19: Logik von SW3 bei der Weiterleitung eines bekannten Unicasts an PC1
SW3#show mac address-table dynamic vlan 3 Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ------------------------3 0200.0101.0101 DYNAMIC Gi0/2 3 0200.1111.1111 DYNAMIC Gi0/1 3 0200.3333.3333 DYNAMIC Fa0/13 Total Mac Addresses for this criterion: 3

Wenn SW1 den Frame von SW3 erhlt, stellt er fest, dass der Frame ber die Schnittstelle Gi0/2 einging, bei der es sich um eine Trunking-Schnittstelle handelt; im Trunking-Header ist VLAN ID 3 aufgefhrt. Am Ende von Listing 3.15 befand sich die SW1-Schnittstelle Gi0/2 im STP-Zustand Forwarding in VLAN 3 (Weiterleitungsschritt 3), das heit, SW1 verwirft den Frame nicht, weil sich die Schnittstelle im STP-Zustand Forwarding befindet. Im nun folgenden Listing 3.20 sehen wir, dass in der MAC-Adresstabelle von SW1 die MAC-Adresse von PC1 0200.1111.1111 als ber die Schnittstelle Fa0/11 erreichbar und in VLAN 3 befindlich aufgefhrt wird; SW1 leitet den Frame also ber Fa0/11 an PC1 weiter. Nun entfernt SW1 den 802.1Q-VLAN-Header, weil es sich bei der Schnittstelle Fa0/11 um eine Access-Schnittstelle handelt.
Listing 3.20: Logik von SW1 bei der Weiterleitung eines bekannten Unicasts an PC1
SW1#show mac address-table dynamic vlan 3 Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ------------------------3 000a.b7dc.b799 DYNAMIC Gi0/2 3 0200.0101.0101 DYNAMIC Gi0/2 3 0200.3333.3333 DYNAMIC Gi0/2 Total Mac Addresses for this criterion: 3

216

CCNA ICND2-Prfungshandbuch

Listing 3.20: Logik von SW1 bei der Weiterleitung eines bekannten Unicasts an PC1
SW1#show mac address-table vlan 3 Mac Address Table ------------------------------------------Vlan Mac Address Type Ports ------------------------All 0100.0ccc.cccc STATIC CPU All 0100.0ccc.cccd STATIC CPU All 0180.c200.0000 STATIC CPU All 0180.c200.0001 STATIC CPU All 0180.c200.0002 STATIC CPU All 0180.c200.0003 STATIC CPU All 0180.c200.0004 STATIC CPU All 0180.c200.0005 STATIC CPU All 0180.c200.0006 STATIC CPU All 0180.c200.0007 STATIC CPU All 0180.c200.0008 STATIC CPU All 0180.c200.0009 STATIC CPU All 0180.c200.000a STATIC CPU All 0180.c200.000b STATIC CPU All 0180.c200.000c STATIC CPU All 0180.c200.000d STATIC CPU All 0180.c200.000e STATIC CPU All 0180.c200.000f STATIC CPU All 0180.c200.0010 STATIC CPU All ffff.ffff.ffff STATIC CPU 3 000a.b7dc.b799 DYNAMIC Gi0/2 3 0200.0101.0101 DYNAMIC Gi0/2 3 0200.1111.1111 STATIC Fa0/11 Total Mac Addresses for this criterion: 23

Dieser letzte Schritt hebt eine wichtige Tatsache zur MAC-Adresstabelle und zur Port-Security hervor. Beachten Sie, dass der Befehl show mac address-table dynamic auf SW1 die Mac-Adresse 0200.1111.1111 von PC1 nicht 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 Schnittstellenbefehls switchport port-security mac-address 0200.1111.1111 konfiguriert hat, betrachtet das 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 die Schnittstelle Fa0/11 an 0200.1111.1111 weiterleitet.

Kapitel 3 Troubleshooting beim LAN-Switching

217

3.6
3.6.1

Prfungsvorbereitung
Wiederholung
Wichtig!

Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind in der Randspalte mit dem entsprechenden Symbol gekennzeichnet. Tabelle 3.6 listet diese Themen sowie die Seitennummern auf, auf denen die Themen zu finden sind.
Tabelle 3.6: Schlsselthemen in Kapitel 3
Element Tabelle 3.2 Abbildung 3.4 Tabelle 3.3 Liste Liste Liste Tabelle 3.4 Tabelle 3.5 Liste Liste Beschreibung Codekombinationen fr Schnittstellenzustnde und typische Ursachen Verwendung von Crossover- und Straight-ThroughKabeln Gerte und Leitungen, ber die Daten via 10BaseT und 100BaseTX bertragen werden Ermittlung von Duplexfehlanpassungen Optionsvorgaben fr das IEEE-Autonegotiating basierend auf der aktuellen bertragungsrate Eigenschaften der Port-Security Verstomodi bei der Port-Security einschlielich der verschiedenen Aktionen und der zugehrigen show-Befehle Seite 182 183 183 187 187 188 189

show-Befehle, die Access-Schnittstellen und die ihnen zuge- 193 ordneten VLANs ermitteln

Vier Grnde dafr, warum ein Switch die Daten eines VLAN nicht ber einen bestimmten Trunk weiterleitet Fhrt die in diesem Kapitel erluterten Schritte zur Problembehebung auf (diese mssen Sie sich nicht merken).

195 197

3.6.2

Vervollstndigen Sie die Listen und Tabellen

Drucken Sie aus Anhang J, Tabellen zur bung (auf der CD vorhanden), den Abschnitt zu diesem Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls auf der CD enthaltene Anhang K, Lsungen zu den bungen, enthlt die vollstndigen Tabellen und Listen, mit denen Sie Ihre Lsungen berprfen knnen.

Teil II
IP-Routing
4 5 6 7 IP-Routing: Statische und direkt verbundene Routen . . . . . . . . . . VLSM und Routenzusammenfassung . . . . . . . . . . . . . . . . . . . . . . . IP-ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting beim IP-Routing . . . . . . . . . . . . . . . . . . . . . . . . . 221 267 297 343

In diesem Teil behandelte offizielle1 Cisco-ICND2-Prfungsthemen: Switch mit VLANs und Switch-bergreifender Kommunikation konfigurieren und verifizieren und Problembehebung durchfhren VLAN-bergreifendes Routing konfigurieren und verifizieren und Problembehebung durchfhren IP-Adressierungsschema und IP-Dienste implementieren, um die Anforderungen an ein Zweigstellennetzwerk in einem mittelgroen Unternehmen zu erfllen VLSM-IP-Adressdesign berechnen und auf ein Netzwerk anwenden Geeignetes klassenloses Adressierungsschema unter Verwendung von VLSM und Routensummierung bestimmen, um die Adressierungsanforderungen in einer LAN-/WAN-Umgebung zu erfllen Allgemeine Probleme in Verbindung mit der IP-Adressierungs- und der Host-Konfiguration erkennen und beheben

1. Die aktuellen Versionen der Prfungsziele finden Sie stets unter http://www.cisco.com.

Grundlegenden Betrieb und Routing auf Cisco-Gerten konfigurieren und Problembehebung durchfhren Konfiguration und Konnektivitt mit ping, traceroute und telnet oder SSH berprfen Probleme der Routing-Implementierung beheben Betrieb von Router-Hardware und -Software mit show- und debug-Befehlen berprfen Grundlegende Router-Sicherheit implementieren NAT und ACLs im Netzwerk der Zweigstelle eines mittelgroen Unternehmens implementieren und berprfen und Problembehebung durchfhren Zweck und Typen von ACLs beschreiben ACLs basierend auf den Filteranforderungen konfigurieren und anwenden ACL konfigurieren und anwenden, um den Telnet- und SSH-Zugriff auf den Router einzuschrnken ACLs in einer Netzwerkumgebung verifizieren und berwachen Probleme der ACL-Implementierung beheben

Dieses Kapitel behandelt die folgenden Themen


IP-Routing und Adressierung Dieser Abschnitt wiederholt die Beziehung zwischen der IP-Adressierung und dem IP-Routing und beschreibt in Einzelheiten, wie das Routing bei mehreren einander berschneidenden Routen funktioniert. Routen zu direkt verbundenen Subnetzen Dieser Abschnitt untersucht, wie Router die Routen fr Subnetze hinzufgen, die direkt an die Router-Schnittstellen angeschlossen sind. Statische Routen Dieser Abschnitt beschreibt, wie man statische Routen einschlielich statischer Default-Routen konfiguriert.

Kapitel 4
IP-Routing: Statische und direkt verbundene Routen
Mit diesem Kapitel beginnt Teil II, IP-Routing. Die vier Kapitel in diesem Teil legen den Schwerpunkt auf die Fhigkeiten, die den IP-Routing-Prozess (auch IP-Weiterleitung genannt) bewirken, mit dem Hosts und Router Pakete von einem Absender- zu einem Ziel-Host bermitteln. Ferner werden in diesem Teil gelegentlich auch Themen im Zusammenhang mit IP-RoutingProtokollen erlutert. Das IP-Routing als Funktion der Datenebene ist in hohem Mae auf die Funktionalitt angewiesen, die von Routing-Protokollen auf der Steuerungsebene bereitgestellt wird. Das vorliegende Kapitel behandelt die direkt verbundenen Routen, d. h. Routen, ber die sich ein an eine Router-Schnittstelle angeschlossenes Subnetz erreichen lsst. Ferner erlutert das Kapitel statische Routen einschlielich von Default-Routen und wiederholt die grundlegenden miteinander zusammenhngenden Themenbereiche von IP-Adressierung und IP-Routing.

4.1

Fragen zur Einschtzung des Wissensstandes

Dieser Abschnitt gestattet es Ihnen zu ermitteln, ob Sie das gesamte Kapitel lesen mssen. Wenn Sie maximal eine der folgenden acht Fragen zur Selbsteinschtzung nicht oder falsch beantworten, knnen Sie mit dem Abschnitt Aufgaben zur Prfungsvorbereitung fortfahren. Tabelle 4.1 listet die wichtigsten berschriften dieses Kapitels und die Nummern der Fragen auf, die sich auf die betreffenden Abschnitte beziehen. Auf diese Weise knnen Sie Ihr Wissen in den jeweiligen Bereichen selbst einschtzen. Die Antworten zu den Fragen in diesem Abschnitt finden Sie in Anhang A.

222

CCNA ICND2-Prfungshandbuch

Tabelle 4.1: Zuordnung der folgenden Fragen zu den einzelnen Themengebieten


Grundlagenthema IP-Routing und Adressierung Routen zu direkt verbundenen Subnetzen Statische Routen Fragen 1 und 2 3 und 4 5 bis 8

1. Ein PC-Benutzer schaltet seinen Computer ein. Nach dem Hochfahren des Computers ffnet der Benutzer einen Webbrowser, um die Adresse http://www.ciscopress.com aufzurufen. Welches oder welche Protokolle kommen auf dem PC bei diesem Vorgang keinesfalls zum Einsatz? a) DHCP b) DNS c) ARP d) ICMP 2. Ein PC-Benutzer schaltet seinen Computer ein. Nach dem Hochfahren des Computers ffnet der Benutzer die Eingabeaufforderung. Dort setzt er den Befehl ping 2.2.2.2 ab. Eine Erfolgsrate von 100 Prozent wird angezeigt. Die IP-Adresse des PC lautet 1.1.1.1, die Subnetzmaske 255.255.255.0. Welche der folgenden Einstellungen wre auf dem PC erforderlich, um einen erfolgreichen ping-Befehl zu untersttzen? a) IP-Adresse eines DNS-Servers b) IP-Adresse eines Default-Gateways c) IP-Adresse eines ARP-Servers d) IP-Adresse eines DHCP-Servers 3. An Router 1 befindet sich die Fast Ethernet-Schnittstelle 0/0 mit der IPAdresse 10.1.1.1. Die Schnittstelle ist mit einem Switch verbunden. Diese Verbindung wird nun auf die Verwendung von 802.1Q-Trunking umgestellt. Welcher der folgenden Befehle knnte Bestandteil einer gltigen Konfiguration der Schnittstelle Fa0/0 von Router 1 sein? a) interface fastethernet 0/0.4 b) dot1q enable c) dot1q enable 4 d) trunking enable

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen e) trunking enable 4 f) encapsulation dot1q

223

4. Ein Router wird mit dem globalen Konfigurationsbefehl no ip subnet-zero konfiguriert. Welcher der folgenden Schnittstellenbefehle wrde von diesem Router nicht akzeptiert? a) ip address 10.1.1.1 255.255.255.0 b) ip address 10.0.0.129 255.255.255.128 c) ip address 10.1.2.2 255.254.0.0 d) ip address 10.0.0.5 255.255.255.252 5. Welche der folgenden Aussagen muss zutreffen, damit IOS eine Route als S in der Ausgabe des Befehls show ip route auffhrt? a) Die IP-Adresse muss an einer Schnittstelle konfiguriert sein. b) Der Router muss ein Routing-Update von einem benachbarten Router empfangen. c) Der Befehl ip route muss zur Konfiguration hinzugefgt werden. d) Der Befehl ip address muss das Schlsselwort special verwenden. e) Die Schnittstelle muss den Zustand up/up aufweisen. 6. Welcher der folgenden Befehle konfiguriert korrekt eine statische Route? a) ip route 10.1.3.0 255.255.255.0 10.1.130.253 b) ip route 10.1.3.0 serial 0 c) ip route 10.1.3.0 /24 10.1.130.253 d) ip route 10.1.3.0 /24 serial 0 7. Auf welche der folgenden Umstnde wirkt sich aus, ob ein Router klassenbezogenes oder klassenloses Routing durchfhrt? a) Wenn eine Default-Route verwendet wird b) Falls Subnetzmasken in Routing-Updates verwendet werden c) Wenn die Ziel-IP-Adresse eines Pakets in eine Netzwerkadresse konvertiert werden muss d) Falls basierend auf der Klassifizierung eines Pakets eine Einreihung in eine bestimmte Warteschlange erfolgt

224

CCNA ICND2-Prfungshandbuch

8. Ein Router wird mit dem globalen Konfigurationsbefehl ip classless konfiguriert. Der Router empfngt nun ein Paket, das an die IP-Adresse 168.13.4.1 gerichtet ist. Nachfolgend gezeigt ist der Inhalt der RoutingTabelle des Routers. Welche der folgenden Aussagen zur Weiterleitung des Pakets durch den Router ist zutreffend?
Gateway of last resort is 168.13.1.101 to network 0.0.0.0 168.13.0.0/24 is subnetted, 2 subnets C 168.13.1.0 is directly connected, FastEthernet0/0 R 168.13.3.0 [120/1] via 168.13.100.3, 00:00:05, Serial0.1

a) Es wird an 168.13.100.3 weitergeleitet. b) Es wird an 168.13.1.101 weitergeleitet. c) Es wird ber die Schnittstelle Fa0/0 direkt zum Ziel-Host gesendet. d) Der Router verwirft das Paket.

4.2

Wissensgrundlage

Dieses Kapitel stellt verschiedene Mglichkeiten vor, wie ein Router Routen zu seiner Routing-Tabelle hinzufgt, ohne ein dynamisches Routing-Protokoll zu verwenden. Es dreht sich insbesondere um direkt verbundene Routen einschlielich solcher, die bei Verwendung des LAN-Trunkings durch einen Router zum Einsatz kommen. Ferner werden statische Routen behandelt, wobei ein Schwerpunkt darauf gelegt wird, wie Router besondere statische Routen die sogenannten Default-Routen verwenden. Weil dieses Kapitel jedoch das erste in diesem Buch ist, welches IP behandelt, wollen wir zu Anfang zwei verwandte Themen kurz wiederholen: IP-Routing und IPAdressierung.

ANMERKUNG
In der Einleitung zu diesem Buch ist eine alternative Lesereihenfolge fr diejenigen Leser aufgefhrt, die die CCNA-Prfung 640-802 angehen wollen. Dabei wechseln Sie stndig zwischen diesem Buch und dem CCENT/ CCNA ICND1-Prfungshandbuch. Wenn dies bei Ihnen der Fall sein sollte, beachten Sie, dass der erste Hauptabschnitt Themen aus dem ICND1-Buch wiederholt. Sie knnen in diesem Fall mit dem Abschnitt IP-Weiterleitung durch Ermittlung der spezifischsten Route fortfahren.

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

225

4.3

IP-Routing und Adressierung

Das IP-Routing basiert auf den Regeln der IP-Adressierung, da eines der ursprnglichen Ziele bei der Entwicklung der IP-Adressierung in der Schaffung eines effizienten IP-Routings bestand. Das IP-Routing definiert, wie ein IP-Paket von dem Host, auf dem es erstellt wird, bis zum Ziel-Host bermittelt werden kann. Die Konventionen der IP-Adressierung sehen vor, dass Adressen zu fortlaufenden Adressgruppen sogenannten Subnetzen zusammengefasst werden, was die IP-Weiterleitung bzw. den IP-RoutingProzess untersttzt.

ANMERKUNG
In diesem Buch werden die Begriffe IP-Routing und IP-Weiterleitung synonym verwendet. Der Begriff IP-Routing-Protokolle bezeichnet RoutingProtokolle, mit deren Hilfe Router die besten Routen dynamisch in ihre Routing-Tabellen eintragen. Beachten Sie, dass einige Texte und Kurse den Begriff IP-Routing auch zur Bezeichnung des Paketweiterleitungsvorgangs und der Protokolle verwenden, mit denen Routen erlernt werden.

4.3.1

IP-Routing

Sowohl Hosts als auch Router nehmen am IP-Routing-Prozess teil. Die nachfolgende Liste fasst die Logik eines Hosts bei der Weiterleitung eines Pakets zusammen (hierbei wird vorausgesetzt, dass der Hosts sich in einem Ethernet-LAN oder einem WLAN befindet): 1. Beim Versand eines Pakets wird die Ziel-IP-Adresse mit dem Adressbereich des angeschlossenen Subnetzes verglichen, den der sendende Host basierend auf seiner IP-Adresse und Subnetzmaske erkennt. a) Wenn das Ziel sich im selben Subnetz wie der Host befindet, wird das Paket direkt an den Ziel-Host gesendet. Um die MAC-Adresse des Ziel-Hosts zu ermitteln, ist das ARP-Protokoll (Address Resolution Protocol) erforderlich. b) Wenn das Ziel sich nicht im selben Subnetz wie der Host befindet, wird das Paket direkt an das Default-Gateway (d. h. den vorgegebenen Router) des Hosts gesendet. ARP ist in diesem Fall erforderlich, um die MAC-Adresse des Default-Gateways zu ermitteln. Router verwenden die nachfolgend beschriebenen Schritte. Dabei ist zu beachten, dass das Paket bei Routern zunchst empfangen werden muss, whrend der sendende Host (wie oben angedeutet) das IP-Paket beim Starten des Versandvorgangs bereits in seinem Speicher hlt.
Wichtig!

226

CCNA ICND2-Prfungshandbuch

Wichtig!

1. Fr jeden empfangenen Frame wird anhand des FCS-Feldes (Frame Check Sequence, Rahmenprfzahl) im Sicherungsschicht-Trailer berprft, ob der Frame fehlerfrei empfangen wurde. Sind Fehler aufgetreten, wird der Frame verworfen, und es wird nicht mit dem nchsten Schritt fortgefahren. 2. Nun wird die Sicherungsschicht-Zieladresse des Frames berprft. Sie wird nur verarbeitet, wenn der Frame an diesen Router gerichtet wurde oder es sich um eine Broadcast- oder Multicast-Adresse handelt. 3. Die im eingehenden Frame vorhandenen Sicherungsschicht-Header und -Trailer werden verworfen. brig bleibt das IP-Paket. 4. Die Ziel-IP-Adresse des Pakets wird mit der Routing-Tabelle verglichen. Auf diese Weise wird die Route ermittelt, die zur Zieladresse passt. Diese Route bezeichnet die Ausgangsschnittstelle des Routers und unter Umstnden auch den nchsten Hop. 5. Die zur Weiterleitung von Paketen an den nchsten Router oder den ZielHost zu verwendende Sicherungsschichtadresse wird entsprechend den Angaben in der Routing-Tabelle bestimmt. 6. Das IP-Paket wird in einem neuen Sicherungsschicht-Header und -Trailer gekapselt, die zur Ausgangsschnittstelle passen, und dann ber die Schnittstelle weitergeleitet.
Subnetz 172.16.1.0, 255.255.255.0 Subnetz 172.16.2.0, 255.255.255.0 172.16.2.2 PC2 Subnetz 172.16.3.0, 255.255.255.0

172.16.1.1 PC1 FA0/0 172.16.1.251 Entkapseln R1 FA0/1 172.16.2.251 Neu kapseln IP-Paket

172.16.3.3 PC3 FA0/1 R2 IP-Paket 172.16.3.252 Neu kapseln

FA0/0 172.16.2.252 Entkapseln

A
Eth. IP-Paket Eth.

B
Eth. IP-Paket Eth.

C
Eth. IP-Paket Eth.

Absender-MAC-Adresse = PC1 Ziel-MAC-Adresse = R1 FA0/0

Absender-MAC-Adresse = R1 FA0/1 Ziel-MAC-Adresse = R2 FA0/0

Absender-MAC-Adresse = R2 FA0/1 Ziel-MAC-Adresse = PC3

ARP-Tabelle von PC1 A IP MAC 172.16.1.251 R1-FA0/0-MAC B

ARP-Tabelle von R1 IP MAC 172.16.2.252 R2-FA0/0-MAC C

ARP-Tabelle von R2 IP MAC 172.16..3.3 PC3-MAC

Routing-Tabelle auf R1 Netzwerk 172.16.3.0 Ausgangsschnittstelle Nchster Hop FA0/1 172.16.2.252 B

Routing-Tabelle auf R2 Subnetz 172.16.3.0 Ausgangsschnittstelle Nchster Hop FA0/1 N/A C

Abbildung 4.1: IP-Routing-Prozess (Beispiel)

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

227

Betrachten Sie exemplarisch Abbildung 4.1. Diese zeigt ein einfaches Netzwerk mit zwei Routern und drei Hosts. Jetzt erstellt PC1 ein Paket, das an die IP-Adresse von PC3 (172.16.3.3) gerichtet ist. Die Abbildung zeigt die drei wesentlichen Routing-Schritte A, B und C: Die Routing-Logik des Hosts PC1 schickt das Paket an R1, dessen Routing-Logik leitet das Paket an R2 weiter, und von dort aus gelangt es dank der Routing-Logik von R2 schlielich zu PC2. Betrachten wir zunchst den Schritt A in Abbildung 4.1. PC1 kennt seine eigene IP-Adresse 172.16.1.1 mit der Maske 255.255.255.0. (In diesem Beispiel verwenden alle Schnittstellen der Einfachheit halber die Maske 255.255.255.0.) PC1 kann seine Subnetznummer (172.16.1.0/24) und den Adressbereich (172.16.1.1-172.16.1.254) berechnen. Die Zieladresse 172.16.3.3 befindet sich nicht im Subnetz von PC1, weswegen Schritt 1b aus der Zusammenfassung der Host-Routing-Logik zum Einsatz kommt: PC1 schickt das Paket gekapselt in einen Ethernet-Frame an die IP-Adresse des Default-Gateways (172.16.1.251). Bereits dieser erste Schritt A, in dessen Verlauf PC1 das Paket an sein Default-Gateway sendet, ermglicht die Auffrischung einiger wichtiger Konzepte. Wie Sie dem unteren Teil der Abbildung entnehmen knnen, verwendet PC1 seine eigene MAC-Adresse als Absender-MAC-Adresse und die MAC-Adresse von R1 im LAN als Ziel-MAC-Adresse. Infolgedessen knnen gegebenenfalls vorhandene LAN-Switches den Frame korrekt an die Schnittstelle Fa0/0 von R1 bermitteln. Beachten Sie ferner, dass PC1 die MAC-Adresse von 172.16.1.251 in seinem ARP-Cache gesucht und auch gefunden hat. Wre die MAC-Adresse nicht gefunden worden, so htte PC1 mithilfe von ARP dynamisch die von 172.16.1.251 (R1) verwendete MACAdresse ermitteln mssen und erst dann den in Abbildung 4.1 gezeigten Frame senden knnen. Als Nchstes wollen wir Schritt B in Abbildung 4.1 betrachten. In seinem Verlauf leitet Router R1 das Paket weiter. Wenn wir die sechs oben zusammengefassten Routing-Schritte zugrunde legen, dann passiert auf R1 Folgendes (beachten Sie, dass in der Abbildung viele Teilschritte mit dem Buchstaben B gekennzeichnet sind): 1. R1 berprft die FCS. Der Frame ist fehlerfrei. 2. R1 findet im Feld der Ziel-MAC-Adresse die MAC-Adresse seiner eigenen Schnittstelle Fa0/0 vor, muss das gekapselte Paket also verarbeiten. 3. R1 verwirft die alten Sicherungsschicht-Header und -Trailer. brig bleibt das IP-Paket (wie direkt unter dem Symbol R1 in Abbildung 4.1 gezeigt). 4. R1 fragt die Ziel-IP-Adresse 172.16.3.3 in seiner Routing-Tabelle ab (unten in Abbildung 4.1 dargestellt) und findet die gezeigte passende Route

228

CCNA ICND2-Prfungshandbuch

mit der Ausgangsschnittstelle Fa0/1 und der Adresse 172.16.2.252 fr den nchsten Router. 5. R1 muss die MAC-Adresse des nchsten Routers im Pfad (R2) ermitteln und schlgt diese erfolgreich in seiner ARP-Tabelle nach. 6. R1 kapselt das IP-Paket in einen neuen Ethernet-Frame. Hierbei sind die MAC-Adresse der R1-Schnittstelle Fa0/1 als Absender-MAC-Adresse und die MAC-Adresse der R2-Schnittstelle Fa0/0 (laut ARP-Tabelle) als Ziel-MAC-Adresse angegeben. Nun sendet R1 den Frame. Diese Schritte scheinen etwas mhselig, und Sie knnen sich sicher bei Fllen, in denen eine Frage keine solche Detailliertheit erfordert, auch krzere Versionen dieses logischen Ablaufs vorstellen. Wenn Sie beispielsweise Routing-Probleme beheben wollen, ist Schritt 4 das Suchen der Ziel-IP-Adresse in der Routing-Tabelle eines Routers wahrscheinlich einer der wichtigeren Schritte. Insofern lsst sich der Routing-Vorgang wie folgt zusammenfassen: Der Router empfngt ein Paket, sucht dessen Zieladresse in der RoutingTabelle und leitet es dann ber die passende Route weiter. Zwar unterschlgt diese Kurzversion einige Details, kann die Problembehebung ebenso wie die Beschreibung von Schwierigkeiten mit dem Routing aber erheblich verkrzen. Um unser Beispiel abzuschlieen, betrachten wir dieselben sechs Schritte, die nun auch auf Router R2 stattfinden. Sie sind in Abbildung 4.1 mit dem Buchstaben C gekennzeichnet: 1. R2 berprft die FCS. Der Frame ist fehlerfrei. 2. R2 findet im Feld der Ziel-MAC-Adresse die MAC-Adresse seiner eigenen Schnittstelle Fa0/0 vor, muss das gekapselte Paket also verarbeiten. 3. R2 verwirft die alten Sicherungsschicht-Header und -Trailer. brig bleibt das IP-Paket (wie direkt unter dem Symbol R2 in Abbildung 4.1 gezeigt). 4. R2 fragt die Ziel-IP-Adresse 172.16.3.3 in seiner Routing-Tabelle ab (unten in Abbildung 4.1 dargestellt) und findet die gezeigte passende Route mit der Ausgangsschnittstelle Fa0/1 und ohne Adresse fr den nchsten Router. 5. Da kein weiterer Router im Pfad vorhanden ist, muss R2 die MACAdresse des Ziel-Hosts (PC3) ermitteln und schlgt diese erfolgreich in seiner ARP-Tabelle nach. 6. R2 kapselt das IP-Paket in einen neuen Ethernet-Frame. Hierbei sind die MAC-Adresse der R2-Schnittstelle Fa0/1 als Absender-MAC-Adresse und die MAC-Adresse von PC3 (laut ARP-Tabelle) als Ziel-MAC-Adresse angegeben. Nun sendet R2 den Frame.

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

229

Wenn der Frame dann schlielich bei PC3 eintrifft, erkennt PC3 die im Frame aufgefhrte Ziel-MAC-Adresse als seine eigene und beginnt mit der Verarbeitung des Frames. Derselbe Vorgang verluft grundstzlich auch bei WAN-Verbindungen so, wenn auch mit ein paar kleinen Unterschieden. Bei Point-to-Point-Verbindungen wie der in Abbildung 4.2 gezeigten ist eine ARP-Tabelle nicht erforderlich. Da maximal ein anderer Router Bestandteil einer Point-to-PointVerbindung ist, knnen Sie die Sicherungsschichtadressierung getrost vergessen. Bei Frame Relay hingegen bercksichtigt der Routing-Vorgang die Sicherungsschichtadressen, die hier DLCIs (Data Link Connection Identifiers) heien. Die Details des Frame Relay-Routings mit DLCIs werden in Kapitel 13 dieses Buches behandelt werden.
Subnetz 172.16.1.0, 255.255.255.0 172.16.1.1 PC1 FA0/0 172.16.1.251 Entkapseln R1 S0/0/0 S0/0/1 172.16.4.251 Neu kapseln IP-Paket PPP IP-Paket 172.16.4.252 Entkapseln R2 IP-Paket Eth. IP-Paket Eth. FA0/1 172.16.3.252 Neu kapseln Subnetz 172.16.4.0, 255.255.255.0 Subnetz 172.16.3.0, 255.255.255.0 172.16.3.3 PC3

Eth.

IP-Paket

Eth.

PPP

Absender-MAC-Adresse = PC1 Ziel-MAC-Adresse = R1 FA0/0

PPP-Adressierung irrelevant, weil eine Point-to-PointTopologie vorliegt

Absender-MAC-Adresse = R2 FA0/1 Ziel-MAC-Adresse = PC3

Abbildung 4.2: IP-Routing-Prozess (Beispiel)

Der IP-Routing-Vorgang auf Hosts und Routern beruht auf der Fhigkeit dieser Gerte, die IP-Adressierung zu verstehen und vorauszuberechnen, welche IP-Adressen sich in den einzelnen Gruppen oder Subnetzen befinden. Im nchsten Abschnitt werden wir IP-Adressen und Subnetzbildung noch einmal zusammenfassend wiederholen.

4.3.2

IP-Adressierung und Subnetzbildung

Die Regeln der IP-Adressierung untersttzen die IP-Routing-Prozesse, denn sie sehen vor, dass IP-Adressen zu Gruppen fortlaufend nummerierter IPAdressen den sogenannten Subnetzen zusammengefasst werden. Um ein Subnetz in unkomplizierter Form ansprechen zu knnen, definiert die IPAdressierung das Prinzip von Subnetzadresse und Subnetzmaske, die in Kombination den Adressbereich eines Subnetzes exakt definieren. So verwenden die Router in den Abbildungen 4.1 und 4.2 Routen, die die Subnetzadresse 172.16.3.0 fr die Weiterleitung des Pakets an PC3 (172.16.3.3) ein-

230

CCNA ICND2-Prfungshandbuch

setzen. In den Abbildungen wurden die Subnetzmasken weggelassen, um die bersichtlichkeit zu erhhen. Aber jedes Gert kennt die Subnetzadresse 172.16.3.0 mit der Subnetzmaske 255.255.255.0 und wei, dass diese beiden Angaben das folgende Subnetz korrekt darstellen: Subnetzadresse 172.16.3.0 Bereich der im 172.16.3.254 Subnetz verwendbaren Adressen: 172.16.3.1-

Broadcast-Adresse des Subnetzes (kann nicht zur Adressierung einzelner Hosts verwendet werden): 172.16.3.255 Die folgende Liste bietet einen kurzen berblick ber wichtige Funktionen der IP-Adressierung. Beachten Sie, dass wir den Schwerpunkt in diesem Kapitel ausschlielich auf IPv4-Adressen (IP Version 4) legen (IPv6 wird in Kapitel 17, IP Version 6 behandelt).
Wichtig!

Unicast-IP-Adressen sind IP-Adressen, die einer einzelnen Schnittstelle fr den Versand und Empfang von Paketen zugeordnet werden. Jede Unicast-IP-Adresse befindet sich in einem bestimmten Klasse-A-, Klasse-B- oder Klasse-C-Netzwerk, das als klassenbezogenes Netzwerk bezeichnet wird. Wenn die Subnetzbildung verwendet wird, was in der Praxis eigentlich immer der Fall ist, dann befindet sich jede Unicast-IP-Adresse ebenfalls in einem bestimmten Teilbereich des klassenbezogenen Netzwerks: dem sogenannten Subnetz. Die Subnetzmaske, die entweder im punktgetrennten Dezimalformat (z. B. 255.255.255.0) oder als Prfix notiert wird (z. B. /24), bezeichnet die Struktur der Unicast-IP-Adressen und gestattet Gerten und Benutzern die Ermittlung der Subnetzadresse, des Adressbereichs und der Broadcast-Adresse eines Subnetzes. Gerte im selben Subnetz sollten jeweils dieselbe Subnetzmaske verwenden, da sie sich andernfalls ber den Adressbereich des Subnetzes nicht einig sind, was den IP-Routing-Prozess gefhrdet. Gerte in einem einzelnen VLAN sollten sich im selben IP-Subnetz befinden. Gerte in verschiedenen VLANs sollten sich in unterschiedlichen IP-Subnetzen befinden. Damit Pakete zwischen Subnetzen weitergeleitet werden knnen, muss ein Gert eingesetzt werden, welches das Routing beherrscht. In diesem

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

231

Buch werden nur Router beschrieben. Multilayer-Switches Switches, die Routing-Funktionen durchfhren knnen lassen sich jedoch ebenfalls verwenden. Serielle Point-to-Point-Verbindungen verwenden ein anderes Subnetz als LAN-Subnetze, denn diese Subnetze bentigen nur zwei IP-Adressen: eine pro Router-Schnittstelle an den Enden der Verbindung. Hosts, die durch einen Router getrennt sind, mssen sich in separaten Subnetzen befinden. Abbildung 4.3 zeigt exemplarisch einen Netzwerkverbund, der viele dieser Merkmale aufweist. Switch SW1 legt alle seine Schnittstellen standardmig in VLAN 1 ab, d. h. alle Hosts auf der linken Seite (einschlielich PC1) befinden sich im selben Subnetz. Beachten Sie, dass die Management-IPAdresse von SW1 sich ebenfalls in VLAN 1 und damit im selben Subnetz befindet. Auch SW2 legt seine Ports vorgabeseitig in VLAN 1 ab, was ein zweites Subnetz erforderlich macht. Die Point-to-Point-Verbindung schlielich erfordert ein drittes Subnetz. Die Abbildung zeigt die Subnetzadressen, Subnetzmasken sowie die Adressbereiche. Beachten Sie, dass alle Adressen und Subnetze Bestandteil desselben klassenbezogenen Klasse-B-Netzwerks 172.16.0.0 sind und alle Subnetze die Maske 255.255.255.0 verwenden.
Subnetz Bereich 172.16.1.0 172.16.1.1 172.16.1.254 Broadcast-Adresse 172.16.1.255
172.16.1.1 255.255.255.0

Subnetz Bereich

172.16.4.0 172.16.4.1 172.16.4.254

Subnetz Bereich

172.16.3.0 172.16.3.1 172.16.3.254

Broadcast-Adresse 172.16.4.255

Broadcast-Adresse 172.16.3.255
172.16.3.3 255.255.255.0

PC1
FA0/0

172.16.4.251 255.255.255.0

PC3

SW1

R1

S0/0/0

172.16.4.252 255.255.255.0 S0/0/1

FA0/1

R2

SW2

Abbildung 4.3: IP-Adressentwurf (Beispiel)

Abbildung 4.3 fhrt die Subnetzadressen, die Adressbereiche und die Broadcast-Adressen der Subnetze auf. Allerdings kann jedes Gert in der Abbildung dieselben Informationen Subnetzadresse, Adressbereich und Broadcast-Adresse aus seiner jeweils eigenen IP-Adress- und Subnetzmaskenkonfiguration fr jedes angeschlossene Subnetz ableiten. Die CCNA-Prfungen verlangen die Beherrschung dieser IP-Adressierungsund Subnetzbildungskonzepte und was noch wichtiger ist der mathematischen Vorgnge, die erforderlich sind, um vorhandene IP-Netzwerke analysieren und neue erstellen zu knnen. Wenn Sie sich noch nicht die Zeit genommen haben, sich die Subnetzbildung in Fleisch und Blut bergehen zu

232

CCNA ICND2-Prfungshandbuch

lassen, dann sollten Sie dies nun ben und praktisch anwenden, bevor Sie mit der Lektre fortfahren. Zwar ist dieser Abschnitt des Buches eine Wiederholung der Grundlagen der IP-Adressierung, aber die einzelnen mathematischen Schritte werden nicht behandelt. Um etwas ber die Subnetzbildung und die zugehrigen mathematischen Schritte zu erfahren, stehen Ihnen verschiedene Mglichkeiten offen. Falls Sie auch das CCENT/CCNA ICND1-Prfungshandbuch erworben haben, lesen Sie bitte das dortige Kapitel 12 und lsen Sie die dort aufgefhrten Praxisaufgaben. Andererseits finden Sie alle im ICND1-Buch enthaltenen Ressourcen zum Erlernen der Subnetzbildung auch auf der CD zu diesem Buch. Es handelt sich um die folgenden Elemente: Anhang D, Subnetzbungen Anhang E, Subnetz-Referenzseiten Anhang H, ICND1, Kapitel 12: IP-Adressierung und Subnetzbildung Videos zur Subnetzbildung Damit Sie auf dem erforderlichen Stand sind, den Rest dieses Buches lesen zu knnen, ohne dass Ihnen die Subnetzbildung Schwierigkeiten bereitet, sollten Sie, bevor Sie weiterlesen, sicherstellen, dass Sie die nachfolgend aufgefhrten Aufgaben lsen knnen. Sie mssen die Antworten zu diesem Zeitpunkt nicht innerhalb kurzer Zeit finden, sollten aber wissen, dass Sie solche Aufgaben bei der Prfung innerhalb des vorgegebenen Zeitraums lsen mssen. Konvertieren Sie eine Subnetzmaske in punktgetrennter Dezimalnotation in die Prfixnotation oder umgekehrt (vorgegebener Zeitrahmen in der Prfungssituation: 5 Sekunden). Ermitteln Sie zu einer IP-Adresse und Subnetzmaske die Subnetzadresse, den Adressbereich sowie die Broadcast-Adresse des Subnetzes (vorgegebener Zeitrahmen: 15 Sekunden). Ermitteln Sie aus einer Subnetzmaske und der Klasse (A, B oder C) eines Netzwerks die Anzahl der Subnetze und der Hosts pro Subnetz (vorgegebener Zeitrahmen: 15 Sekunden). Bestimmen Sie aus einer vorgegebenen Netzwerkklasse (A, B oder C) und den gegebenen Designanforderungen hinsichtlich einer Anzahl von Subnetzen und einer Anzahl von Hosts pro Subnetz alle Masken, die diese Anforderungen erfllen, und whlen Sie diejenige Maske aus, bei der die Anzahl der Subnetze bzw. die Anzahl der Hosts pro Subnetz am hchsten ist (vorgegebener Zeitrahmen: 30 Sekunden).

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

233

Fhren Sie ausgehend von einem klassenbezogenen Netzwerk und einer einzelnen Subnetzmaske, die fr alle Subnetze verwendet werden soll, die Subnetzadressen auf und geben Sie das Subnetz Null und das BroadcastSubnetz an (vorgegebener Zeitrahmen: 30 Sekunden). Mit diesem Wissen zur Subnetzbildung werden wir im nchsten Abschnitt untersuchen, wie ein Router die richtige Route in einer Routing-Tabelle sucht, falls dort Subnetze aufgefhrt sind, die einander berlappen, sodass zum Ziel-Host eines Pakets mehrere Routen fhren.

IP-Weiterleitung durch Ermittlung der spezifischsten Route


Auf jedem Router erfordert der IP-Routing-Prozess, dass der Router die Ziel-IP-Adresse jedes Pakets mit der IP-Routing-Tabelle dieses Routers vergleicht. Hufig gibt es zu einer bestimmten Zieladresse nur eine passende Route. In manchen Fllen jedoch passen zu einer Zieladresse mehrere Routen auf dem Router. Es gibt mehrere Grnde fr eine solche berschneidung von Routen in einer Routing-Tabelle, die durchaus normal und auch zulssig sind: Automatische Zusammenfassung von Routen Manuelle Zusammenfassung von Routen Verwendung statischer Routen Falsch entworfene Subnetze, die sich in ihren Adressbereichen berschneiden Kapitel 5, VLSM und Routensummierung, erlutert diese Grnde im Detail. Whrend einige Flle berschneidender Routen problematisch sind, stellen andere Normalflle dar, die infolge irgendeiner anderen Funktionalitt entstehen. In diesem Abschnitt legen wir den Schwerpunkt auf die Frage, wie ein Router bestimmt, welche der sich berschneidenden Routen verwendet werden soll. (Die Merkmale, die solche berschneidungen verursachen, behandeln wir ebenfalls in Kapitel 5.) Die folgende Aussage fasst das Verhalten eines Routers bei sich berlappenden Routen zusammen: Wenn einer bestimmten Ziel-IP-Adresse mehrere Routen in der Routing-Tabelle eines Routers zugeordnet sind, verwendet der Router die genaueste Route, d. h. die Route mit der grten Prfixlnge. Um zu sehen, was dies genau bedeutet, betrachten Sie die in Listing 4.1 gezeigte Routing-Tabelle. Diese enthlt eine Folge sich berschneidender Routen. Bevor Sie nach dem Listing weiterlesen, versuchen Sie doch zunchst einmal selbst zu ermitteln, welche Route fr Pakete verwendet
Wichtig!

234

CCNA ICND2-Prfungshandbuch

wird, die an die IP-Adressen 172.16.1.1, 172.16.1.2, 172.16.2.3 und 172.16.4.3 gesendet werden.
Listing 4.1: Befehl show ip route bei sich berschneidenden Routen
R1#show ip route rip 172.16.0.0/16 is variably subnetted, 000000000000000000 5 subnets, 4 masks R 172.16.1.1/32 [120/1] via 172.16.25.2, 00:00:04, Serial0/1/1 R 172.16.1.0/24 [120/2] via 172.16.25.129, 00:00:09, Serial0/1/0 R 172.16.0.0/22 [120/1] via 172.16.25.2, 00:00:04, Serial0/1/1 R 172.16.0.0/16 [120/2] via 172.16.25.129, 00:00:09, Serial0/1/0 R 0.0.0.0/0 [120/3] via 172.16.25.129, 00:00:09, Serial0/1/0 R1#show ip route 172.16.4.3 Routing entry for 172.16.0.0/16 Known via "rip", distance 120, metric 2 Redistributing via rip Last update from 172.16.25.129 on Serial0/1/0, 00:00:19 ago Routing Descriptor Blocks: * 172.16.25.129, from 172.16.25.129, 00:00:19 ago, via Serial0/1/0 Route metric is 2, traffic share count is 1

Auch wenn bei einer entsprechenden Prfungsaufgabe ein Diagramm des zugehrigen Netzwerks angegeben sein knnte, bentigen Sie doch eigentlich nur zwei Informationen, um zu ermitteln, welche Route die passende ist: die Ziel-IP-Adresse des Pakets sowie den Inhalt der Routing-Tabelle des Routers. Durch Untersuchung der einzelnen Subnetze und Masken in der Routing-Tabelle knnen Sie dann die IP-Adressbereiche in den einzelnen Subnetzen bestimmen. In diesem Fall sehen die von den einzelnen Routen definierten Bereiche jeweils wie folgt aus: 172.16.1.1 (nur diese eine Adresse) 172.16.1.0-172.16.1.255 172.16.0.0-172.16.3.255 172.16.0.0-172.16.255.255 0.0.0.0-255.255.255.255 (alle Adressen)

ANMERKUNG
Die als 0.0.0.0/0 aufgefhrte Route ist die Default-Route, die mit allen IPAdressen bereinstimmt. Wir werden sie im weiteren Verlauf dieses Kapitels behandeln.

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

235

Wie Sie den Angaben entnehmen knnen, berschneiden sich einige der Adressbereiche dieser Routen. Wenn mehrere passende Routen vorhanden sind, wird die Route mit der grten Prfixlnge verwendet. Zum Beispiel: 172.16.1.1: Alle fnf Routen stimmen berein. Das lngste Prfix ist /32, die Route nach 172.16.1.1/32. 172.16.1.2: Die letzten vier Routen stimmen berein. Das lngste Prfix ist /24, die Route nach 172.16.1.0/24. 172.16.2.3: Die letzten drei Routen stimmen berein. Das lngste Prfix ist /22, die Route nach 172.16.0.0/22. 172.16.4.3: Die letzten beiden Routen stimmen berein. Das lngste Prfix ist /16, die Route nach 172.16.0.0/16. Man kann die mathematischen Vorgnge zur Subnetzbildung natrlich fr jede Route der Routing-Tabelle durchfhren, aber auch der Befehl show ip route ip-address kann in diesem Zusammenhang sehr hilfreich sein. Dieser Befehl listet detaillierte Angaben zu der Route auf, die der Router der im Befehl angegebenen IP-Adresse zuordnet. Sind mehrere passende Routen fr die Adresse vorhanden, so gibt der Befehl die beste Route an, nmlich die mit dem lngsten Prfix. So zeigt etwa Listing 4.1 die Ausgabe des Befehls show ip route 172.16.4.3 an. Die erste Zeile der (hervorgehobenen) Ausgabe zeigt die passende Route: 172.16.0.0/16. Der Rest der Ausgabe fhrt die Details dieser speziellen Route auf. Dieser Befehl kann sowohl in der Praxis als auch zur Beantwortung von Simulationsfragen in den Prfungen sehr ntzlich sein.

4.3.3

DNS, DHCP, ARP und ICMP

Der IP-Routing-Prozess verwendet diverse verwandte Protokolle, so auch das in diesem Kapitel bereits erwhnte ARP-Protokoll. Bevor wir mit den neuen Themen in diesem Kapitel fortfahren, wollen wir in diesem Abschnitt verschiedene Protokolle wiederholen. Bevor ein Host IP-Pakete verschicken kann, muss man ihm diverse IP-Parameter zuordnen. Hufig verwenden Hosts das Protokoll DHCP (Dynamic Host Configuration Protocol) zur automatischen Konfiguration der folgenden wichtigen Parameter: IP-Adresse des Hosts Zugehrige Subnetzmaske IP-Adresse des Default-Gateways (Routers) IP-Adresse(n) eines oder mehrerer DNS-Server
Wichtig!

236

CCNA ICND2-Prfungshandbuch

Um diese Angaben in Erfahrung zu bringen, sendet der Host ein DHCPClient einen Broadcast, der frher oder spter einen DHCP-Server erreicht. Der Server kann dann eine IP-Adresse an diesen Host leasen und die brigen in der obigen Liste aufgefhrten Angaben bereitstellen. Nun kennt der Host die IP-Adresse, die er als Absender-IP-Adresse verwenden muss, und verfgt ber gengend Informationen, um eine einfache Routing-Entscheidung auf Host-Ebene zu treffen: Sollen die Pakete direkt an einen anderen Host im selben Subnetz oder aber ber das Default-Gateway in ein anderes Subnetz bermittelt werden? (Unter Microsoft Windows XP listet der Befehl ipconfig /all die Schnittstellen des Hosts in einer Form auf, der sich alle oben angefhrten IP-Parameter entnehmen lassen.) Gewhnlich gibt der Benutzer bei seinen Aktionen direkt oder indirekt den Hostnamen eines anderen Hosts ein, was dazu fhrt, dass der Host ein Paket an einen anderen Host schicken muss. So wird beispielsweise beim ffnen eines Webbrowsers und der Eingabe von http://www.cisco.com als URL der Hostname eines Webservers ermittelt, der von Cisco betrieben wird. Das ffnen eines Mail-Clients wie Microsoft Outlook referenziert einen Hostnamen indirekt. Der Mail-Client ist nmlich wahrscheinlich so konfiguriert, dass er die Hostnamen eines eingehenden und eines ausgehenden Mail-Servers kennt; insofern muss der Benutzer nicht Tag fr Tag diese Einstellungen konfigurieren, denn die Mail-Client-Software speichert die Namen der Hosts, mit denen Mails ausgetauscht werden. Da Hosts keine Pakete an einen Ziel-Hostnamen senden knnen, lsen die meisten Hosts den Namen mithilfe von DNS (Domain Name System) in die zugehrige IP-Adresse auf. Der Host agiert dabei als DNS-Client und schickt Nachrichten an die Unicast-IP-Adresse des DNS-Servers. Die DNS-Anfrage enthlt den Namen (z. B. www.cisco.com), und der Server gibt die IPAdresse zurck, die diesem Hostnamen entspricht. Nachdem er die Adresse erhalten hat, kann der Host die Zuordnung von Name und Adresse in einem Cache ablegen und muss erst dann wieder eine neue Auflsung durchfhren, wenn die Gltigkeitsdauer des Eintrags abgelaufen ist. (Unter Windows XP fhrt der Befehl ipconfig /displaydns die aktuelle Liste der Namen und Adressen von Hosts im Cache auf.) ICMP (Internet Control Message Protocol) bietet viele verschiedene Funktionen mit Schwerpunkt auf der Steuerung und Verwaltung von IP. ICMP definiert eine Reihe von Nachrichten fr verschiedene Zwecke, z. B. ICMPEchoanforderungen und ICMP-Echoantworten. Der beliebte Befehl ping testet die Route zu einem entfernten Host sowie die Route zurck zum Ausgangs-Host, indem er Echoanforderungen an die Ziel-IP-Adresse sendet und der Ziel-Host auf alle diese Anforderungen mit einer Echoantwort reagiert.

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

237

Wenn ping die Echoantworten empfngt, wei der Befehl, dass die Route zwischen den beiden Hosts funktioniert. Alle diese Protokolle untersttzen gemeinsam den IP-Routing-Prozess, doch DHCP, DNS, ICMP und ARP treten gewhnlich nicht bei jedem Paket auf. Stellen Sie sich beispielsweise einen neuen Host vor, der an ein LAN angeschlossen ist. Nun gibt der Benutzer den Befehl ping www.cisco.com ein. DHCP kommt meist beim Starten des Betriebssystems zum Einsatz, wenn der PC mithilfe dieses Protokolls seine IP-Adresse und weitere Informationen ermittelt, wird danach unter Umstnden aber tagelang nicht mehr verwendet. Im nchsten Schritt lst der PC die Domne www.cisco.com mithilfe von DNS in eine IP-Adresse auf; nachfolgend wird DNS aber erst dann wieder bentigt, wenn ein neuer Hostname gesucht wird. Wenn der Host nun einen ping-Befehl sendet, erstellt er ein IP-Paket mit einer ICMP-Echoanforderung. Die Ziel-IP-Adresse entnimmt er den mithilfe der vorherigen DNS-Anforderung in Erfahrung gebrachten Adressen. Schlielich verfgt der Host ber keinen ARP-Eintrag fr sein Default-Gateway, weil er soeben erst eingeschaltet wurde. Insofern muss er mithilfe von ARP die IP-Adresse des Default-Gateways ermitteln. Erst jetzt kann das Paket so an den endgltigen Empfnger-Host geschickt werden, wie es im ersten Teil dieses Kapitels beschrieben wurde. Bei nachfolgenden Paketen, die an denselben Hostnamen gesendet werden, werden diese Protokolle mit hoher Wahrscheinlichkeit nicht wieder verwendet der lokale Host kann das neue Paket einfach versenden. Die folgende Liste fasst die auf dem Host ablaufenden Schritte zusammen, die im Bedarfsfall fr die in diesem Abschnitt beschriebenen Protokolle verwendet werden: 1. Sofern der Host seine eigene IP-Adresse und Subnetzmaske sowie die DNS-IP-Adressen und die IP-Adresse des Default-Gateways noch nicht kennt, ermittelt er diese mit DHCP. Sind die Angaben bereits bekannt, so berspringt der Host den Schritt. 2. Wenn der Benutzer einen Hostnamen eingibt, der gegenwrtig nicht im Namens-Cache des Hosts enthalten ist, setzt der Host eine DNS-Anforderung ab, um den Namen in die zugehrige IP-Adresse aufzulsen. Andernfalls berspringt der Host den Schritt. 3. Wenn der Benutzer den Befehl ping absetzt, enthlt das IP-Paket eine ICMP-Echoanforderung. (Wrde der Benutzer hingegen eine typische TCP/IP-Anwendung verwenden, so wrden die fr diese Anwendung passenden Protokolle eingesetzt werden.)
Wichtig!

238

CCNA ICND2-Prfungshandbuch

4. Zur Erstellung des Ethernet-Frames verwendet der Host den Eintrag fr das nchste Gert im Pfad im ARP-Cache: entweder das Default-Gateway (falls der Versand an einen Host in einem anderen Subnetz erfolgt) oder den entgltigen Ziel-Host (falls dieser sich im selben Subnetz befindet). Enthlt der ARP-Cache keinen entsprechenden Eintrag, erlernt der Host diese Information mithilfe von ARP.

4.3.4

Fragmentierung und MTU

TCP/IP definiert eine Maximallnge fr ein IP-Paket. Der Begriff, mit dem diese Maximallnge beschrieben wird, heit MTU (Maximum Transmission Unit, maximale bertragungsgre). Die MTU schwankt basierend auf der Konfiguration und den Schnittstelleneigenschaften. Standardmig berechnet ein Computer die MTU einer Schnittstelle basierend auf der maximalen Gre des Datenteils eines Sicherungsschicht-Frames (in dem das Paket abgelegt wird). So betrgt die MTUStandardgre bei Ethernet-Schnittstellen 1500. Wie jeder andere IP-Host knnen auch Router ein Paket nicht ber eine Schnittstelle weiterleiten, falls das Paket grer ist als die MTU. Ist dies der Fall, dann wird das weiterzuleitende Paket durch den Router in kleinere Pakete aufgeteilt, also fragmentiert. Unter der Fragmentierung versteht man den Vorgang der Aufteilung von Paketen in kleinere Pakete, die jeweils maximal so gro sind wie durch die MTU vorgegeben. Abbildung 4.4 zeigt exemplarisch die Fragmentierung in einem Netzwerk, wobei die MTU der seriellen Verbindung konfigurationsseitig auf einen Wert von 1000 Byte verringert wurde.
Koufax LA Boston Clemens

MTU 1000

Ethernet

IP (1500)

Ethernet

IP (750)

Ethernet HDLC IP (750)

IP (750)

HDLC

IP (750)

Abbildung 4.4: IP-Fragmentierung

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

239

Wie Abbildung 4.4 zeigt, sendet Koufax ein 1500 Byte langes Paket zum Router LA. LA entfernt den Ethernet-Header, kann das Paket aber in der vorliegenden Form nicht weiterleiten, da die HDLC-Verbindung (High Level Data Link Control) nur einen MTU-Wert von 1000 untersttzt. Insofern fragmentiert LA das Ursprungspaket in zwei Pakete, die jeweils 750 Byte lang sind. Der Router fhrt dabei die zur Ermittlung der Mindestanzahl von Fragmenten (in diesem Fall zwei) erforderlichen Berechnungen aus und unterteilt das Originalpaket dann in Pakete gleicher Lnge. Deswegen ist die Wahrscheinlichkeit gering, dass andere Router, die die Pakete passieren, ebenfalls eine Fragmentierung durchfhren mssen. Die beiden weitergeleiteten Pakete werden von Boston empfangen und weitergeleitet, ohne wieder zusammengesetzt zu werden. Die Zusammensetzung des Pakets erfolgt erst beim Ziel-Host, in diesem Fall also bei Clemens. Der IP-Header enthlt Felder, die fr die Wiederzusammensetzung der Fragmente zum Ursprungspaket ntzlich sind. Der Header enthlt einen IDWert, der bei allen Fragmenten gleich ist, sowie einen Offsetwert, der definiert, welcher Teil des Ursprungspakets im vorliegenden Fragment enthalten ist. Fragmentierte Pakete, die in der falschen Reihenfolge eintreffen, lassen sich so als Bestandteile desselben Originalpakets erkennen und dank des Offsetfeldes auch wieder korrekt zusammensetzen. Es gibt zwei Konfigurationsbefehle, mit denen sich die MTU-Gre fr eine Schnittstelle ndern lsst: die Schnittstellenbefehle mtu und ip mtu. Der Befehl mtu legt die MTU fr alle Schicht-3-Protokolle fest. Sofern keine Veranlassung besteht, die Einstellung spezifisch fr bestimmte Schicht-3-Protokolle anzupassen, ist dieser Befehl zu bevorzugen. Wenn Sie hingegen fr IP eine andere Einstellung bentigen, legt der Befehl ip mtu den fr IP verwendeten Wert fest. Werden beide Befehle fr eine Schnittstelle konfiguriert, so hat ip mtu Vorrang. Wird der Befehl mtu hingegen spter als ip mtu konfiguriert, so wird der ip mtu-Wert auf den Wert des mtu-Befehls zurckgesetzt. Gehen Sie mit Bedacht vor, wenn Sie diese Werte ndern. Damit ist die Wiederholung zu IP-Routing und Adressierung abgeschlossen. Im nchsten Abschnitt werden wir uns den direkt verbundenen Routen zuwenden. Dies schliet solche Routen, die in Zusammenhang mit dem VLAN-Trunking stehen, und sekundre IP-Adressen ein.

240

CCNA ICND2-Prfungshandbuch

4.4

Routen zu direkt verbundenen Subnetzen

Ein Router fgt seiner Routing-Tabelle fr jedes an eine seiner Schnittstellen angeschlossene Subnetz eine Route hinzu, sofern die beiden folgenden Voraussetzungen erfllt sind:
Wichtig!

Die Schnittstelle ist betriebsbereit, das heit, als Schnittstellenzustand wird in der Ausgabe des Befehls show interfaces up/up (fr Leitung und Protokoll) angegeben. Der Schnittstelle wurde entweder ber den Schnittstellenbefehl ip address oder ber die DHCP-Client-Dienste eine IP-Adresse zugewiesen. Das Prinzip angeschlossener Routen ist relativ simpel. Der Router muss die Subnetzadressen der Netzwerke, die physisch an seine einzelnen Schnittstellen angeschlossen sind, natrlich in Erfahrung bringen; falls die Schnittstelle nicht betriebsbereit ist, muss der Router die Route aus seiner RoutingTabelle entfernen. Der Befehl show ip route fhrt diese Routen mit dem Routen-Code c (fr connected) auf; der Befehl show ip route connected zeigt nur direkt verbundene Routen. Die nachfolgenden Abschnitte zu direkt verbundenen Routen behandeln schwerpunktmig einige Konfigurationsvarianten, die sich auch auf die Art und Weise auswirken, wie Router Pakete weiterleiten. Das erste Thema ist eine Funktionalitt, die als sekundre IP-Adressierung bezeichnet wird, das zweite Thema behandelt die Konfiguration eines Routers mit VLANTrunking.

4.4.1

Sekundre IP-Adressierung

Stellen Sie sich vor, Sie htten bereits ein IP-Adressierungsschema fr ein Netzwerk geplant. Im Nachhinein wird nun ein bestimmtes Subnetz vergrert, Sie haben aber alle gltigen IP-Adressen in diesem Subnetz bereits vergeben. Was sollen Sie tun? Es gibt grundstzlich drei Mglichkeiten: Sie vergrern das vorhandene Subnetz. Sie migrieren die Hosts in ein anderes, greres Subnetz. Sie verwenden die sekundre Adressierung. Alle drei Optionen sind sinnvoll, weisen aber auch den einen oder anderen Fallstrick auf.

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

241

Um das Subnetz zu vergrern, mssen Sie einfach nur die dafr verwendete Maske ndern. Allerdings entstehen hierdurch unter Umstnden einander berschneidende Subnetze. Wenn beispielsweise im Subnetz 10.1.4.0/24 keine Adressen mehr vorhanden sind und Sie nun zur Maske 255.255.254.0 wechseln (9 Hostbits, 23 Netzwerk-/Subnetzbits), enthlt das neue Subnetz die Adressen 10.1.4.0 bis 10.1.5.255. Haben Sie das Subnetz 10.1.5.0/24 mit den zuordenbaren Adressen 10.1.5.1 bis 10.1.5.254 bereits zugeordnet, so entsteht eine unzulssige berschneidung. Wenn nun jedoch die Adressen des Formats 10.1.5.x nicht verwendet werden, kann die Erweiterung des alten Subnetzes durchaus sinnvoll sein. Die zweite Option besteht darin, einfach ein neues, noch nicht verwendetes und vor allem greres Subnetz auszuwhlen. Es mssten jedoch alle IPAdressen gendert werden. Dies ist ein vergleichsweise einfacher Vorgang, wenn die meisten oder alle Hosts DHCP benutzen; setzen allerdings viele Hosts statisch konfigurierte IP-Adressen ein, dann sieht die Angelegenheit schon etwas anders aus. Beachten Sie, dass bei den ersten beiden Lsungen jeweils unterschiedliche Masken in verschiedenen Teilen des Netzwerks zum Einsatz kommen. Die Verwendung solcher unterschiedlicher Masken heit VLSM (Variable Length Subnet Masking). VLSM erhht die Komplexitt des Netzwerks insbesondere fr die Techniker, die das Netzwerk berwachen und Probleme beheben sollen. Die dritte wichtige Option ist die Verwendung einer Funktionalitt auf Cisco-Routern, die als sekundre IP-Adressierung bezeichnet wird. Die sekundre Adressierung verwendet mehrere Netzwerke oder Subnetze ber dieselbe Datenleitung. Durch Verwendung mehrerer Subnetze auf demselben Medium erhhen Sie die Anzahl der verfgbaren IP-Adressen. Damit dies funktioniert, bentigt der Router eine IP-Adresse in jedem Subnetz, damit die Hosts in jedem Subnetz ein nutzbares Default-Gateway ansprechen knnen. Das ist erforderlich, weil Pakete, die zwischen diesen Subnetzen ausgetauscht werden, an den Router gesendet werden mssen. In Abbildung 4.5 beispielsweise gibt es das Subnetz 10.1.2.0/24. Wir wollen einmal annehmen, dass alle seine IP-Adressen zugewiesen wurden. Wenn wir uns nun fr die sekundre Adressierung als Lsung entscheiden, knnte das Subnetz 10.1.7.0/24 im selben Ethernet verwendet werden. Listing 4.2 zeigt die Konfiguration der sekundren IP-Adressierung auf Yosemite.

242

CCNA ICND2-Prfungshandbuch
Bugs Daffy

10.1.1.0 10.1.1.251 10.1.128.251 s0


10 .1 .1 28 .0

Albuquerque s1 10.1.130.251
.0 30 .1 .1 10

10.1.128.252 s0

10.1.130.253 s0

10.1.129.0 Yosemite Primr 10.1.2.252, Sekundr 10.1.7.252 Sam Emma Elmer Red s1 10.1.129.252 10.1.7.0 s1 10.1.129.253 Seville 10.1.3.253 10.1.3.0

10.1.2.0

Abbildung 4.5: TCP/IP-Netzwerk mit sekundren Adressen


Listing 4.2: Konfiguration der sekundren IP-Adressierung und Ausgabe des Befehls show ip route auf Yosemite
! Auszug aus der Ausgabe von show running-config: Hostname Yosemite ip domain-lookup ip name-server 10.1.1.100 10.1.2.100 interface ethernet 0 ip address 10.1.7.252 255.255.255.0 secondary ip address 10.1.2.252 255.255.255.0 interface serial 0 ip address 10.1.128.252 255.255.255.0 interface serial 1 ip address 10.1.129.252 255.255.255.0 Yosemite# show ip route connected 10.0.0.0/24 is subnetted, 4 subnets C 10.1.2.0 is directly connected, Ethernet0 C 10.1.7.0 is directly connected, Ethernet0 C 10.1.129.0 is directly connected, Serial1 C 10.1.128.0 is directly connected, Serial0

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

243

Der Router hat angeschlossene Routen zu den Subnetzen 10.1.2.0/24 und 10.1.7.0/24, kann also Pakete in jedes Subnetz weiterleiten. Die Hosts in den einzelnen Subnetzen im selben LAN knnen je nachdem, in welchem Subnetz sie vorhanden sind, entweder 10.1.2.252 oder 10.1.7.252 als IPAdresse des Default-Gateways angeben. Der grte Nachteil der sekundren Adressierung besteht darin, dass Pakete, die zwischen Hosts im LAN bertragen werden, ineffizient geroutet werden. Wenn beispielsweise ein Host im Subnetz 10.1.2.0 ein Paket an einen Host in 10.1.7.0 schickt, dann besagt die Logik des sendenden Hosts, dass das Paket an das Default-Gateway gesendet werden muss, denn das Ziel befindet sich ja in einem anderen Subnetz. Insofern schickt der sendende Host das Paket an den Router, der es dann wieder zurck in dasselbe LAN bertrgt.

4.4.2

Direkt verbundene Routen in das Subnetz Null

IOS kann die Konfiguration des Befehls ip address mit einer Adresse im Subnetz Null durch den Router unterbinden. Das Subnetz Null (auch Nullsubnetz genannt) ist das einzige Subnetz in einem klassenbezogenen Netzwerk, dessen Subnetzteil der Subnetzadresse in der binren Version ausschlielich aus Nullen besteht. In dezimaler Schreibweise entspricht die Adresse des Subnetzes Null der klassenbezogenen Netzwerkadresse. Wenn der Befehl ip subnet-zero konfiguriert wurde, gestattet dies dem IOS, das Subnetz Null zu einer direkt verbundenen Route zu machen, indem man den Befehl ip address an einer Schnittstelle konfiguriert. Der Befehl ip subnet-zero ist seit der letzten IOS-Version 12.0 die Voreinstellung. (Die Version 12.0 ist bei Erscheinen dieses Buches bereits relativ alt.) Wenn Sie also bei einer Prfungsaufgabe den Befehl ip subnet-zero sehen oder die Frage nicht angibt, dass der Befehl no ip subnet-zero konfiguriert wird, knnen Sie davon ausgehen, dass das Nullsubnetz konfiguriert werden kann.

ANMERKUNG
In frheren Ausgaben dieses Buches wurde gesagt, dass Sie davon ausgehen sollten, dass das Subnetz Null nicht verwendet werden darf, sofern die Prfungsaufgabe nichts Gegenteiliges aussagte. Die aktuellen CCNA-Prfungen und damit auch dieses Buch gestatten hingegen die Verwendung des Subnetzes Null, sofern die Prfungsfrage nicht direkt oder indirekt aussagt, dass es nicht verwendet werden soll.

244

CCNA ICND2-Prfungshandbuch

Wurde der Befehl no ip subnet-zero nicht auf einem Router konfiguriert, dann weist der Router ip address-Befehle ab, die eine Adresse und Maske fr das Subnetz Null verwenden. Der Schnittstellenbefehl ip address 10.0.0.1 255.255.255.0 etwa konfiguriert das Subnetz Null 10.0.0.0/24, das heit, der Router wrde den Befehl abweisen, sofern der globale Konfigurationsbefehl no ip subnet-zero konfiguriert wrde. Beachten Sie, dass die Fehlermeldung lediglich bad mask lautet; es wird nicht gesagt, dass das Problem aufgrund des Subnetzes Null entstanden ist. Der Befehl no ip subnet-zero auf einem Router hat keine Auswirkungen auf anderen Routern und verhindert nicht, dass ein Router ein Subnetz Null ber ein Routing-Protokoll erlernt. Er sorgt lediglich dafr, dass der Router keine Schnittstelle als zu einem Subnetz Null gehrend konfiguriert. Beachten Sie, dass Sie in den aktuellen CCNA-Prfungen davon ausgehen knnen, dass eine Verwendung des Subnetzes Null gestattet ist, sofern die Aufgabe nichts Gegenteiliges besagt. Insbesondere eine Frage, die ein klassenbezogenes Routing-Protokoll verwendet (wie in Kapitel 5 beschrieben) oder den Befehl no ip subnet-zero einsetzt, impliziert, dass Null- und Broadcast-Subnetze nicht verwendet werden drfen.

4.4.3

ISL- und 802.1Q-Konfiguration auf Routern

Wie in Kapitel 1, VLANs, beschrieben, kann das VLAN-Trunking zwischen zwei Switches, aber auch zwischen einem Switch und einem Router eingesetzt werden. Indem man das Trunking statt einer physischen RouterSchnittstelle pro VLAN verwendet, verringert man die Anzahl der erforderlichen Router-Schnittstellen. Der Router verwendet dann statt einer physischen Schnittstelle pro auf dem Switch vorhandenen VLAN nur eine einzige physische Schnittstelle, kann aber Pakete trotzdem VLAN-bergreifend routen. Abbildung 4.6 zeigt einen Router mit einer Fast Ethernet-Schnittstelle und einer Verbindung mit einem Switch. Hier lassen sich wahlweise ISL- oder 802.1Q-Trunking verwenden, wobei die Unterschiede bei der Konfiguration gering sind. Bei Frames, welche der Router zwischen zwei VLANs routet, enthlt der eingehende Frame vom Switch eine VLAN-ID, whrend der ausgehende Frame vom Router mit der anderen VLAN-ID ausgezeichnet wird. Listing 4.3 zeigt die zur Untersttzung der ISL-Kapselung erforderliche Router-Konfiguration und die Weiterleitung zwischen diesen VLANs.

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen


VLAN 1 IP-Subnetz 10.1.1.0/24

245

Dino

Fred

Wilma Fa0/0 VLAN1 Frame VLAN2 Frame Barney VLAN 2 IP-Subnetz 10.1.2.0/24

VLAN 3 IP-Subnetz 10.1.3.0/24

Abbildung 4.6: Routing zwischen VLANs


Listing 4.3: Router-Konfiguration mit ISL-Kapselung fr Abbildung 4.6
interface fastethernet 0/0.1 ip address 10.1.1.1 255.255.255.0 encapsulation isl 1 ! interface fastethernet 0/0.2 ip address 10.1.2.1 255.255.255.0 encapsulation isl 2 ! interface fastethernet 0/0.3 ip address 10.1.3.1 255.255.255.0 encapsulation isl 3

Listing 4.3 zeigt die Konfiguration dreier Subschnittstellen der Fast Ethernet-Schnittstelle auf dem Router. Eine Subschnittstelle ist eine logische Unterteilung einer physischen Schnittstelle. Der Router weist jeder Subschnittstelle eine IP-Adresse zu und verknpft sie dann mit genau einem VLAN. Insofern verwendet der Router statt der drei physischen RouterSchnittstellen, die jeweils mit einem anderen Subnetz/VLAN verknpft sind, nur eine physische Schnittstelle mit drei logischen Subschnittstellen, die jeweils an ein anderes Subnetz/VLAN angeschlossen sind. Der Befehl encapsulation nummeriert die VLANs, die der Konfiguration der VLAN-IDs auf dem Switch entsprechen mssen.

246

CCNA ICND2-Prfungshandbuch

Dieses Beispiel verwendet Subschnittstellennummern, die zu den VLAN-IDs der jeweiligen Subschnittstelle passen. Eine solche Entsprechung ist eigentlich nicht erforderlich, wird aber meistens gewhlt, um die Konfiguration aussagekrftiger zu machen und die Problembehebung zu erleichtern. Die Subschnittstellen knnten also fr die VLAN-IDs 1, 2 und 3 durchaus 0.4, 0.5 und 0.6 lauten, denn die Nummern der Subschnittstellen werden nur intern vom Router verwendet. Listing 4.4 zeigt dasselbe Netzwerk, diesmal allerdings mit 802.1Q statt ISL konfiguriert. IEEE 802.1Q kennt das Konzept des nativen VLAN. Dies ist ein spezifisches VLAN, fr das den Frames auf dem Trunk keine 802.1QHeader hinzugefgt werden. Die Default-Einstellung betrachtet VLAN 1 als das native VLAN. Listing 4.4 zeigt die Unterschiede in der Konfiguration.
Listing 4.4: Router-Konfiguration mit 802.1Q-Kapselung fr Abbildung 4.6
interface fastethernet 0/0 ip address 10.1.1.1 255.255.255.0 ! interface fastethernet 0/0.2 ip address 10.1.2.1 255.255.255.0 encapsulation dot1q 2 ! interface fastethernet 0/0.3 ip address 10.1.3.1 255.255.255.0 encapsulation dot1q 3

Die Konfiguration erstellt drei VLANs auf der Router-Schnittstelle Fa0/0. Zwei der VLANs 2 und 3 sind wie in Listing 4.3 konfiguriert, allerdings gibt der Befehl encapsulation 802.1Q als Kapselungstyp an. Das native VLAN hier VLAN 1 kann auf zweierlei Weise konfiguriert werden. Listing 4.4 zeigt einen Ansatz, bei dem die IP-Adresse des nativen VLAN auf der physischen Schnittstelle konfiguriert wird. Infolgedessen verwendet der Router keine VLAN-Trunking-Header in diesem VLAN, wie es bei nativen VLANs ja auch vorgesehen ist. Alternativ knnte man die IPAdresse des nativen VLAN auch auf einer anderen Subschnittstelle konfigurieren und den Schnittstellenbefehl encapsulation dot1q 1 native verwenden. Dieser Befehl sagt dem Router, dass die Subschnittstelle mit VLAN 1 verknpft ist, und das Schlsselwort native weist darauf hin, dass fr diese Subschnittstelle keine 802.1Q-Header verwendet werden. Router verhandeln das Trunking nicht dynamisch. Aus diesem Grund muss ein Switch, der mit einer Router-Schnittstelle verbunden ist, das Trunking

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

247

wie in Kapitel 1 behandelt manuell konfigurieren. So wrde etwa ein Switch am anderen Ende der Router-Schnittstelle Fa0/0 zunchst den Schnittstellenbefehl switchport mode trunk konfigurieren (und so das Trunking manuell aktivieren). Falls der Switch beide Trunking-Typen beherrscht, knnte der Schnittstellenbefehl switchport trunk encapsulation dot1q abgesetzt werden, um die Verwendung von 802.1Q statisch festzulegen.

4.5

Statische Routen

Router verwenden im Wesentlichen drei Methoden, um Routen zu ihren Routing-Tabellen hinzuzufgen: direkt verbundene Routen, statische Routen und dynamische Routing-Protokolle. Direkt verbundene Routen werden stets hinzugefgt, wenn fr Schnittstellen IP-Adressen konfiguriert wurden und sie betriebsbereit sind. In den meisten Netzwerken verwenden die Netzwerktechniker bewusst dynamische Routing-Protokolle, damit alle Router die verbleibenden Routen in einem Netzwerkverbund erlernen. Die Verwendung statischer Routen also Routen, die durch direkte Konfiguration einer Routing-Tabelle hinzugefgt werden ist die am seltensten verwendete Variante der drei Mglichkeiten. Fr das statische Routing werden Routen auf einem Router mithilfe des globalen Konfigurationsbefehls ip route definiert. Der Konfigurationsbefehl enthlt einen Verweis auf das Subnetz (Subnetzadresse und -maske) sowie Angaben dazu, wohin Pakete weitergeleitet werden sollen, die an dieses Subnetz gerichtet sind. Um die Notwendigkeit statischer Routen zu verstehen und die Konfiguration zu erfassen, betrachten Sie bitte Listing 4.5. Hier werden zwei ping-Befehle gezeigt, mit denen die IP-Konnektivitt von Albuquerque nach Yosemite getestet wird (vgl. Abbildung 4.7).
Listing 4.5: EXEC-Befehle auf dem Router Albuquerque (nur direkt verbundene Routen)
Albuquerque#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set

248

CCNA ICND2-Prfungshandbuch

Listing 4.5: EXEC-Befehle auf dem Router Albuquerque (nur direkt verbundene Routen) (Forts.)
10.0.0.0/24 is subnetted, 3 subnets C 0000000000000000 is directly connected, Ethernet0 10.1.1.0 C 000000000000000000 is directly connected, Serial1 10.1.130.0 C 000000000000000000 is directly connected, Serial0 10.1.128.0 Albuquerque#ping 10.1.128.252 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.128.252, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms Albuquerque#ping 10.1.2.252 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.2.252, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Bugs Daffy

10.1.1.0 10.1.1.251 10.1.128.251 s0


.1 28 .0 .1

Albuquerque s1 10.1.130.251
10 .1

10

.1

10.1.128.252 s0

30 .0

10.1.130.253 s0

10.1.129.0 Yosemite 10.1.2.252 10.1.2.0 s1 10.1.129.252 s1 10.1.129.253 Seville 10.1.3.253 10.1.3.0

Sam

Emma

Elmer

Red

Abbildung 4.7: Beispielnetzwerk zur Erluterung des statischen Routings

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

249

Am Ende des Listings werden zwei verschiedene ping-Befehle auf dem Router Albuquerque abgesetzt: einer fr 10.1.128.252 (IP-Adresse der Schnittstelle S0 von Yosemite) und ein weiterer an 10.1.2.252 (IP-Adresse des an Yosemite angeschossenen LAN). Der IOS-Befehl ping sendet standardmig fnf ICMP-Echoanforderungspakete. In der Ausgabe erscheint fr jede empfangene Echoantwort ein Ausrufezeichen (!) und fr jede ausgebliebene Antwort ein Punkt (.). Beim ersten Befehl im Listing zeitigt ping 10.1.128.252 fnf Antworten (100 Prozent), whrend der zweite Befehl ping 10.1.2.252 keine Antworten erhlt (0 Prozent). Der erste ping-Befehl funktioniert, weil Albuquerque ber eine Route zu dem Subnetz verfgt, in dem sich 10.1.128.2 befindet (Subnetz 10.1.128.0/24). Der an 10.1.2.252 gesendete ping-Befehl schlgt hingegen fehl, weil Albuquerque keine passende Route fr 10.1.2.252 hat. Zum betreffenden Zeitpunkt verfgt Albuquerque lediglich ber Routen in die drei angeschlossenen Subnetze. Insofern erstellt der Befehl ping 10.1.2.252 zwar die entsprechenden Pakete, aber Albuquerque verwirft diese in Ermangelung einer passenden Route.

4.5.1

Statische Routen konfigurieren

Eine einfacher Ansatz gegen das Fehlschlagen von ping 10.1.2.252 besteht darin, auf allen drei Routern ein IP-Routing-Protokoll zu aktivieren. In einem echten Netzwerk wre dies sogar die wahrscheinlichste Lsung. Eine Alternative besteht in der Konfiguration statischer Routen. In vielen Netzwerken gibt es die eine oder andere statische Route, das heit, Sie mssen sie gelegentlich auch konfigurieren. Listing 4.6 zeigt den Befehl ip route auf dem Router Albuquerque. Mit diesem Befehl werden statische Routen hinzugefgt; anschlieend wird der in Listing 4.5 gezeigte ping-Befehl funktionieren.
Listing 4.6: Zu Albuquerque hinzugefgte statische Routen
ip route 10.1.2.0 255.255.255.0 10.1.128.252 ip route 10.1.3.0 255.255.255.0 10.1.130.253

Der Befehl ip route definiert eine statische Route zur Subnetzadresse ber die IP-Adresse des nchsten Hops. Ein ip route-Befehl definiert eine Route nach 10.1.2.0 (Maske 255.255.255.0). Dieses Netzwerk ist ber Yosemite zu erreichen, das heit, die auf Albuquerque konfigurierte Adresse des nchsten Hops lautet 10.1.128.252 die IP-Adresse der Schnittstelle S0 von Yosemite. hnlich verweist eine Route nach 10.1.3.0 dem Subnetz von Seville auf die IP-Adresse 10.1.130.253 der Schnittstelle S0 von Seville. Beachten Sie, dass die IP-Adresse des nchsten Hops eine IP-Adresse in einem direkt verbundenen Subnetz ist; das Ziel besteht darin, den nchsten Router zu definieren, an den das Paket gesendet wird. Nun kann Albuquerque Pakete an diese beiden Subnetze weiterleiten.

250

CCNA ICND2-Prfungshandbuch

Der Befehl ip route untersttzt zwei grundlegende Formate. Mglich ist zunchst die Angabe der Adresse des nchsten Hops, wie es in Listing 4.6 gezeigt ist. Alternativ kann der Befehl bei statischen Routen, die serielle Point-to-Point-Verbindungen nutzen, statt der IP-Adresse des nchsten Hops auch die Ausgangsschnittstelle angeben. Man htte in Listing 4.6 also statt des ersten ip route-Befehls auch den globalen Konfigurationsbefehl ip route 10.1.2.0 255.255.255.0 serial0 verwenden knnen. Leider lst das Hinzufgen zweier statischer Routen auf Albuquerque in Listing 4.6 nicht alle Routing-Probleme in unserem Netzwerk. Zwar untersttzen die statischen Routen Albuquerque bei der Auslieferung von Paketen an diese Subnetze, aber die beiden anderen Router verfgen nicht ber gengend Routing-Informationen, um Pakete wieder zurck an Albuquerque leiten zu knnen. So kann der PC Bugs beispielsweise auch nach Ergnzen der Befehle in Listing 4.6 keine ping-Befehle an PC Sam in diesem Netzwerk schicken. Das Problem besteht darin, dass zwar Albuquerque eine Route in das Subnetz 10.1.2.0 kennt, in dem Sam existiert, Yosemite jedoch ber keine Route nach 10.1.1.0 verfgt, in dem Bugs sich befindet. Das ping-Anforderungspaket gelangt also wie gewnscht von Bugs zu Sam, doch das Antwortpaket kann vom Router Yosemite nicht an Albuquerque geroutet (und von dort aus an Bugs weitergeleitet) werden, das heit, der ping-Befehl schlgt fehl.

4.5.2

Der erweiterte ping-Befehl

In der Praxis knnen Sie einen Benutzer wie Bugs unter Umstnden gar nicht ausfindig machen, um ihn zu einem ping-Test aufzufordern. Stattdessen knnen Sie jedoch den erweiterten ping-Befehl auf einem Router nutzen, um einen Test ebenso durchzufhren, als ob Bugs einen ping-Befehl an Sam senden wrde. Listing 4.7 zeigt auf Albuquerque den funktionierenden Befehl ping 10.1.2.252 und nachfolgend den erweiterten Befehl ping 10.1.2.252, der hnlich wie ein von Bugs an Sam abgesetzter ping-Befehl funktioniert und in diesem Fall fehlschlgt (zu diesem Zeitpunkt wurden erst die beiden statischen Routen aus Listing 4.6 ergnzt).
Listing 4.7: Funktionierender ping-Befehl auf Albuquerque nach dem Ergnzen von statischen Routen sowie ein fehlgeschlagener erweiterter ping-Befehl
Albuquerque#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

251

Listing 4.7: Funktionierender ping-Befehl auf Albuquerque nach dem Ergnzen von statischen Routen sowie ein fehlgeschlagener erweiterter ping-Befehl (Forts.)
Gateway of last resort is not set 10.0.0.0/24 is subnetted, 5 subnets S 10.1.3.0 [1/0] via 10.1.130.253 S 10.1.2.0 [1/0] via 10.1.128.252 C 10.1.1.0 is directly connected, Ethernet0 C 10.1.130.0 is directly connected, Serial1 C 10.1.128.0 is directly connected, Serial0 Albuquerque#ping 10.1.2.252 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.2.252, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms Albuquerque#ping Protocol [ip]: Target IP address: 0000000000 10.1.2.252 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: 0 y Source address or interface: 0000000000 10.1.1.251 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.2.252, timeout is 2 seconds: . . . . . Success rate is 0 percent (0/5)

Der einfache Befehl ping 10.1.2.252 funktioniert aus einem naheliegenden und einem weiteren, nicht ganz so naheliegenden Grund. Zunchst kann Albuquerque ein Paket aufgrund der statischen Route an das Subnetz 10.1.2.0 weiterleiten. Das von Yosemite gesendete Antwortpaket ist an die Adresse 10.1.128.251 (die IP-Adresse der Schnittstelle S0 von Albuquerque) gerichtet, und Yosemite verfgt ber eine direkt verbundene Route, ber die das Subnetz 10.2.128.0 erreicht werden kann. Aber warum sendet Yosemite die Echoantwort an 10.1.128.251 die IP-Adresse von Albuquerques

252

CCNA ICND2-Prfungshandbuch

Schnittstelle S0? Nun, Folgendes gilt fr einen ping-Befehl auf einem CiscoRouter:
Wichtig!

Der Cisco-Befehl ping verwendet standardmig die IP-Adresse der Ausgangsschnittstelle als Absenderadresse des Pakets, sofern in einem erweiterten ping-Befehl nichts anderes angegeben ist. Der erste ping-Befehl in Listing 4.7 nutzt die Absenderadresse 10.1.128.251, weil die zum Versand des Pakets an 10.1.2.252 verwendete Route ber die Schnittstelle S0 von Albuquerque verluft, deren IP-Adresse 10.1.128.251 lautet. ICMP-Echoantworten also die Antwortpakete tauschen die in der empfangenen Echoanforderung enthaltenen IP-Adressen gegeneinander aus. In unserem Beispiel verwendet also die von Yosemite als Reaktion auf den ersten ping-Befehl in Listing 4.7 gesendete Echoantwort als Zieladresse 10.1.128.251 und als Absenderadresse 10.1.2.252. Da der Befehl ping 10.1.2.252 auf Albuquerque als Absenderadresse des Pakets 10.1.128.251 einsetzt, kann Yosemite eine Antwort an 10.1.128.251 zurckschicken, denn Yosemite verfgt ber eine (direkt verbundene) Route nach 10.1.128.0. Die Gefahr bei der Behebung von Problemen mit dem einfachen ping-Befehl besteht darin, dass Sie sich aufgrund des erfolgreichen Befehls ping 10.1.2.252 in falscher Sicherheit wiegen, da nach wie vor Routing-Probleme vorhanden sein knnen. Eine umfassendere Alternative besteht in der Verwendung des erweiterten ping-Befehls. Dieser funktioniert so, als ob Sie einen ping-Befehl von einem Computer im betreffenden Subnetz abgesetzt htten, ohne dass Sie hierfr einen Benutzer kontaktieren und ihn zur Eingabe eines ping-Befehls auf seinem PC auffordern mssten. Die erweiterte Version von ping kann zur Eingrenzung der Grundursache eines Problems dienen, denn es lsst sich recht gut anpassen, was genau der Befehl in seiner Anforderung sendet. Mehr noch: Wenn ein ping-Befehl von einem Router ausgehend funktioniert, von einem Host aus jedoch fehlschlgt, dann knnen Sie das Problem mithilfe des erweiterten ping-Befehls simulieren, ohne berhaupt mit dem betreffenden Benutzer in Kontakt treten zu mssen. In Listing 4.7 beispielsweise sendet der erweiterte ping-Befehl auf Albuquerque ein Paket mit der Absenderadresse 10.1.1.251 (Ethernet-Adresse von Albuquerque) an 10.1.2.252 (Ethernet-Adresse von Yosemite). Aus der Ausgabe geht hervor, dass Albuquerque keine Antwort erhalten hat. Normalerweise wrde der ping-Befehl als Absenderadresse die IP-Adresse der Ausgangsschnittstelle erhalten. Bei der Verwendung der Absenderoption des erweiterten ping-Befehls wird als Absenderadresse jedoch die Ethernet-IPAdresse von Albuquerque (10.1.1.251) festgelegt. Weil das vom erweiterten

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

253

ping-Befehl generierte ICMP-Echo als Absenderadresse eine Adresse im Sub-

netz 10.1.1.0 erhlt, wirkt das Paket nun so, als stamme es von einem Endgert aus diesem Subnetz. Yosemite erstellt eine Echoantwort mit der Zieladresse 10.1.1.251, verfgt aber ber keine Route in dieses Subnetz. Insofern kann Yosemite das ping-Antwortpaket nicht zurck an Albuquerque schicken. Um dieses Problem zu beheben, kann auf allen Routern die Verwendung eines Routing-Protokolls konfiguriert werden. Alternativ knnen Sie auch einfach statische Routen auf allen Routern im Netzwerk definieren.

4.5.3

Statische Default-Routen

Eine Default-Route ist eine besondere Route, die zu allen Paketzielen passt. Default-Routen sind besonders ntzlich, falls nur ein einziger physischer Pfad von einem Teil des Netzwerks in einen anderen vorhanden ist, oder wenn ein einzelner Unternehmens-Router die Internetkonnektivitt fr das gesamte Unternehmen ermglichen soll. In Abbildung 4.8 etwa sind R1, R2 und R3 nur ber die LAN-Schnittstelle von R1 mit dem Rest des Netzwerks verbunden. Alle drei Router knnen Pakete an den Rest des Netzwerks weiterleiten, solange diese zu R1 gelangen; R1 seinerseits leitet die Pakete an Router Dist1 weiter.
168.13.200.1 168.13.1.0/24 Dist1 restliches Netz 168.13.1.101 168.13.2.0/24 R2

R1
168.13.100.1

10.1.1.1 168.13.100.0/24

Frame Relay 168.13.3.0/24 R3

Abbildung 4.8: Beispielnetzwerk mit Default-Route

In den folgenden Abschnitten werden wir zwei Optionen zur Konfiguration statischer Default-Routen behandeln: die Verwendung des Befehls ip route und den Einsatz des Befehls ip default-network.

254

CCNA ICND2-Prfungshandbuch

Default-Routen mit ip route definieren


Durch Konfiguration einer Default-Route auf R1 mit Dist1 als nchstem Hop und durch Bekanntmachung dieser Route gegenber R2 und R3 wird das Default-Routing umgesetzt. Wenn eine solche Default-Route vorhanden ist, sollten R1, R2 und R3 keine speziellen Routen zu den Subnetzen rechts von Dist1 bentigen. Listing 4.8 zeigt dieses Design und gibt dazu die Definition einer statischen Default-Route auf R1 und die resultierenden Informationen in der IP-Routing-Tabelle von R1 an.
Listing 4.8: Konfiguration einer statischen Default-Route auf R1 und die zugehrige Routing-Tabelle
R1(config)#ip route 0.0.0.0 0.0.0.0 168.13.1.101 0000000000000000000000000000000000000 R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is 168.13.1.101 to network 0.0.0.0 168.13.0.0/24 is subnetted, 4 subnets 168.13.1.0 is directly connected, FastEthernet0/0 168.13.3.0 [120/1] via 168.13.100.3, 00:00:05, Serial0.1 168.13.2.0 [120/1] via 168.13.100.2, 00:00:21, Serial0.1 168.13.100.0 is directly connected, Serial0.1 0.0.0.0/0 [1/0] via 168.13.1.101

C R R C S*

R1 definiert die Default-Route mit dem statischen Befehl ip route und gibt als Ziel 0.0.0.0 mit der Maske 0.0.0.0 an. Aufgrund dessen fhrt der Befehl show ip route auf R1 die statische Route 0.0.0.0 mit der Maske 0.0.0.0 und dem nchsten Hop 168.13.1.101 auf. Dies entspricht im Wesentlichen den Angaben im globalen Konfigurationsbefehl ip route 0.0.0.0 0.0.0.0 168.13.1.101. Per Konvention entspricht der Empfnger 0.0.0.0 mit der Maske 0.0.0.0 allen Empfngern. Ohne weitere Konfigurationsschritte verfgt R1 in diesem Fall ber eine statische Route, die den Zielen aller IPPakete entspricht. Beachten Sie auerdem in Listing 4.8, dass die Ausgabe von show ip route auf R1 ein Gateway of Last Resort (168.13.1.101) auffhrt. Wenn ein Router zumindest eine Default-Route kennt, kennzeichnet er sie in der Routing-

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

255

Tabelle mit einem Sternchen. Erlernt ein Router nun durch statische Konfiguration oder ber Routing-Protokolle weitere Default-Routen, so werden auch diese Routen mit einem Sternchen in der Routing-Tabelle gekennzeichnet. Danach whlt der Router die beste Default-Route aus und kennzeichnet diese als Gateway of Last Resort. (Die definierte administrative Distanz der Quelle der Routing-Daten hat gewisse Auswirkungen auf die Auswahl. Wir werden die administrative Distanz im Abschnitt Administrative Distanz in Kapitel 8, Theorie zu Routing-Protokollen, behandeln.) Zwar wird die RIP-Konfiguration (Routing Information Protocol) nicht angezeigt, jedoch macht R1 diese Default-Route auch gegenber R2 und R3 bekannt. Dies knnen wir der Ausgabe von show ip route auf R3 in Listing 4.9 entnehmen.
Listing 4.9: R3: Spuren der erfolgreichen Verwendung der statischen Route auf R1
R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is 168.13.100.1 to network 0.0.0.0 168.13.0.0/24 is subnetted, 4 subnets 168.13.1.0 [120/1] via 168.13.100.1, 00:00:13, Serial0.1 168.13.3.0 is directly connected, Ethernet0 168.13.2.0 [120/1] via 168.13.100.2, 00:00:06, Serial0.1 168.13.100.0 is directly connected, Serial0.1

R C R C

Verschiedene Routing-Protokolle machen Default-Routen auf unterschiedliche Weise bekannt. Wenn R3 beispielsweise via RIP eine Default-Route von R1 erlernt, fhrt R3 das Ziel der Default-Route (0.0.0.0) und den nchsten Router im Pfad auf in diesem Fall also R1 (168.13.100.1, siehe Hervorhebung in Listing 4.9). Wenn also R3 seine Default-Route verwendet, leitet er Pakete an R1 (168.13.100.1) weiter.

256

CCNA ICND2-Prfungshandbuch

Default-Routen mit ip default-network definieren


Eine weitere Mglichkeit der Konfiguration einer Default-Route basiert auf dem Befehl ip default-network. Dieser Befehl enthlt als Parameter ein klassenbezogenes IP-Netzwerk und weist den Router an, die Route fr dieses klassenbezogene Netzwerk als Weiterleitungsparameter einer Default-Route zu verwenden. Der Befehl ist vor allem ntzlich, wenn der Netzwerktechniker die DefaultRoute zum Erreichen von anderen als solchen Netzwerken verwenden will, die unternehmensintern verwendet werden. Nehmen wir etwa an, dass alle Subnetze des Klasse-B-Netzwerks 168.13.0.0 des Unternehmens in Abbildung 4.8 bekannt seien und smtlichst in der Nhe der Router R1, R2 und R3 stnden, und dass alle Routen in den Routing-Tabellen von R1, R2 und R3 vorhanden wren. Ferner wollen wir annehmen, dass keines der Subnetze von 168.13.0.0 sich rechts von Dist1 befindet. Falls der Netzwerktechniker nun eine Definition zur Weiterleitung von Paketen an Ziele rechts von Dist1 verwenden will, ist der Befehl ip default-network eine passende Wahl. Um den Befehl ip default-network zur Konfiguration einer Default-Route verwenden zu knnen, ist der Netzwerktechniker darauf angewiesen zu wissen, dass Dist1 bereits eine Route fr das klassenbezogene Netzwerk 10.0.0.0 dem Router R1 bekannt macht. Die Route von R1 in das Netzwerk 10.0.0.0 enthlt die Adresse 168.13.1.101 von Dist1 als Adresse des nchsten Hops. Weil er dies wei, kann der Techniker den Befehl ip default-network 10.0.0.0 auf R1 konfigurieren. Dieser Befehl weist R1 an, seine DefaultRoute basierend auf der erlernten Route fr das Netzwerk 10.0.0.0/8 zu erstellen. Listing 4.10 zeigt mehrere Details zu diesem Szenario auf R1.
Listing 4.10: Der Befehl ip default-network auf R1
R1#configure terminal R1(config)#ip default-network 10.0.0.0 000000000000000000000000000 R1(config)#exit R1#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen


Listing 4.10: Der Befehl ip default-network auf R1 (Forts.)
Gateway of last resort is 168.13.1.101 to network 10.0.0.0

257

R C R R C R*

168.13.0.0/24 is subnetted, 5 subnets 168.13.200.0 [120/1] via 168.13.1.101, 00:00:12, FastEthernet0/0 168.13.1.0 is directly connected, FastEthernet0/0 168.13.3.0 [120/1] via 168.13.100.3, 00:00:00, Serial0.1 168.13.2.0 [120/1] via 168.13.100.2, 00:00:00, Serial0.1 168.13.100.0 is directly connected, Serial0.1 10.0.0.0/8 [120/1] via 168.13.1.101, 00:00:12, FastEthernet0/0

R1 zeigt sowohl die Folge des Erlernens einer Route zum Netzwerk 10.0.0.0 ber RIP als auch die weiteren Ergebnisse des globalen Befehls ip defaultnetwork 10.0.0.0 an. Die RIP-Route von R1 nach 10.0.0.0/8 fhrt als Adresse des nchsten Routers im Pfad 168.13.1.101 die IP-Adresse von Dist1 im gemeinsamen LAN als normal auf. Wegen des Befehls ip default-network 10.0.0.0 entscheidet sich R1 dazu, diese Route zum Netzwerk 10.0.0.0 als Default-Route zu verwenden. Der letzte Teil der Zeile zum Gateway of Last Resort fhrt das Standardnetzwerk 10.0.0.0 auf. Auerdem zeigt R1 neben der mit dem Befehl ip default-network konfigurierten Route ein Sternchen an.

4.5.4

Zusammenfassung zu den Default-Routen

Die Einzelheiten zur Konfiguration von Default-Routen und insbesondere die resultierenden Details in der Ausgabe des Befehls show ip route zu kennen, kann eine Herausforderung darstellen. Allerdings sollten Sie zumindest die folgenden Schlsselpunkte zu Default-Routen kennen: Statische Default-Routen lassen sich mit den Befehlen ip route 0.0.0.0 0.0.0.0 next-hop-address oder ip default-network net-number konfigurieren. Wenn ein Paket ausschlielich zur Default-Route passt, verwendet der Router nachfolgend die Weiterleitungsangaben, die in der Zeile Gateway of Last Resort aufgefhrt sind. Unabhngig davon, wie die Standardroute sich darstellt als Gateway of Last Resort, als Route nach 0.0.0.0 oder als Route in ein anderes Netzwerk, die in der Routing-Tabelle mit einem Sternchen gekennzeichnet ist , wird sie stets entsprechend den Regeln des klassenlosen oder klassenbezogenen Routings verwendet, wie es im nchsten Abschnitt erklrt wird.
Wichtig!

258

CCNA ICND2-Prfungshandbuch

4.5.5

Klassenbezogenes und klassenloses Routing

Cisco-Router bieten zwei konfigurierbare Optionen dafr an, wie ein Router eine vorhandene Default-Route verwendet: das klassenlose und das klassenbezogene Routing. Das klassenlose Routing bewirkt, dass ein Router seine Default-Routen fr alle Pakete verwendet, fr die keine passende andere Route vorhanden ist. Das klassenbezogene Routing schrnkt die Verwendung der Default-Route durch einen Router in einer Hinsicht ein, was dazu fhren kann, dass ein Router zwar ber eine Default-Route verfgt, aber ein Paket trotzdem verwirft, statt es basierend auf dieser Default-Route weiterzuleiten. Die Begriffe klassenlos und klassenbezogen werden auch zur Charakterisierung von IP-Adressierung und IP-Routing-Protokollen verwendet, weswegen es hinsichtlich ihrer Bedeutung eine Menge Verwirrung gibt. Deswegen wollen wir, bevor wir uns den Details des klassenbezogenen und klassenlosen Routings zuwenden, die Definitionen dieser Begriffe erlutern.

Zusammenfassung zu den Begriffen klassenlos und klassenbezogen


Die Begriffe klassenlose Adressierung und klassenbezogene Adressierung bezeichnen zwei unterschiedliche Mglichkeiten, IP-Adressen aufzufassen. Die beiden Termini verweisen auf eine Sichtweise, die auf der Struktur einer in Subnetze unterteilten IP-Adresse basiert. Die klassenlose Adressierung verwendet eine zweigeteilte Darstellung von IP-Adressen, die klassenbezogene eine dreigeteilte. Bei der klassenbezogenen Adressierung umfasst die Adresse stets einen Netzanteil, der 8, 16 oder 24 Bit lang ist und auf den Adressierungsregeln fr Klasse-A-, Klasse-B- oder Klasse-C-Netzwerken basiert. Das Ende der Adresse ist dann ein Host-Anteil, der jeden Host in einem Subnetz eindeutig identifiziert. Die Bits zwischen dem Netz- und dem Host-Anteil bilden den dritten Teil: den Subnetzanteil der Adresse. Bei der klassenlosen Adressierung werden der Netz- und der Subnetzanteil der klassenbezogenen Adressierung zu einem Teil zusammengefasst, der meist als Subnetz oder Prfix bezeichnet wird. Auch hier endet die Adresse mit dem Host-Anteil. Die Begriffe des klassenlosen bzw. klassenbezogenen Routing-Protokolls verweisen auf Merkmale unterschiedlicher IP-Routing-Protokolle. Diese Merkmale knnen nicht aktiviert oder deaktiviert werden, sondern ein Routing-Protokoll ist seinem Wesen nach stets entweder klassenbezogen oder klassenlos. Klassenlose Routing-Protokolle zeichnen sich durch die Weitergabe von Maskendaten fr jedes Subnetz aus und ermglichen so die Untersttzung sowohl von VLSM als auch der Routensummierung. Klassenbezo-

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

259

gene Routing-Protokolle weisen keine Masken aus und untersttzen daher weder VLSM noch Summierung. Eine dritte Verwendung der Begriffe klassenlos und klassenbezogen hat damit zu tun, wie der IP-Routing-Prozess die Default-Route nutzt; die Rede ist vom klassenbezogenen bzw. klassenlosen Routing. Interessanterweise ist dies die einzige der drei Verwendungsformen dieser Begriffe, die basierend auf der Router-Konfiguration gendert werden kann. Tabelle 4.2 listet die drei Verwendungsmglichkeiten der Begriffe klassenlos und klassenbezogen mit jeweils einer kurzen Erluterung auf. Eine umfassendere Erluterung des klassenlosen und klassenbezogenen Routings nach der Tabelle. In Kapitel 5 erhalten Sie mehr Hintergrundinformationen zu den Begriffen klassenloses Routing-Protokoll sowie klassenbezogenes Routing-Protokoll.
Tabelle 4.2: Vergleich der Begriffe klassenlos und klassenbezogen
Zusammenhang Adressen Klassenbezogen Adressen bestehen aus drei Teilen, nmlich dem Netz-, dem Subnetz- und dem Host-Anteil. Das Routing-Protokoll weist weder Masken aus, noch untersttzt es VLSM. Betrifft RIPv1 und IGRP. Der IP-Weiterleitungsprozess ist dahingehend eingeschrnkt, wie er die Default-Route verwendet. Klassenlos Adressen bestehen aus zwei Teilen, nmlich dem Subnetzanteil (oder Prfix) und dem Host-Anteil. Das Routing-Protokoll weist Masken aus und untersttzt VLSM. Betrifft RIPv2, EIGRP und OSPF. Der IP-Weiterleitungsprozess weist keine Einschrnkungen in Bezug auf die Verwendung der DefaultRoute auf.
Wichtig!

Routing-Protokolle

Routing (Weiterleitung)

Klassenbezogenes und klassenloses Routing im Vergleich


Klassenloses IP-Routing funktioniert genau so, wie es sich die meisten Menschen vorstellen wrden, sofern der Router eine Default-Route kennt. Im Vergleich zum klassenbezogenen Routing sind die Kernkonzepte des klassenlosen Routings einfach gestrickt. Das klassenbezogene Routing schrnkt die Verwendung der Default-Route ein. Die folgenden zwei Aussagen liefern eine allgemeine Beschreibung der beiden Konzepte: Klassenloses Routing: Falls zum Ziel eines Empfngers nur die DefaultRoute eines Routers und keine andere Route passt, wird das Paket ber diese Default-Route weitergeleitet.
Wichtig!

260

CCNA ICND2-Prfungshandbuch

Klassenbezogenes Routing: Falls zum Ziel eines Empfngers nur die Default-Route eines Routers und keine andere Route passt, wird diese Default-Route nur dann verwendet, wenn der Router keine Routen in dem klassenbezogenen Netzwerk kennt, in dem die Ziel-IP-Adresse vorhanden ist. Die Verwendung des Begriffs klassenbezogen bezieht sich auf die Tatsache, dass die Logik die Regeln der klassenbezogenen IP-Adressierung bercksichtigt nmlich das klassenbezogene (Klasse-A-, -B- oder -C-)Netzwerk der Zieladresse des Pakets. Um dieses Prinzip zu veranschaulichen, betrachten wir Listing 4.11. Dieses zeigt einen Router mit einer Default-Route. Das klassenbezogene Routing gestattet die Verwendung der Default-Route zwar in einem Fall, in einem anderen jedoch nicht. Das Listing basiert auf den Beispielen zu Default-Routen, die wir bereits in diesem Kapitel behandelt haben (vgl. Abbildung 4.8). Sowohl R3 als auch R1 haben eine Default-Route, ber die Pakete an den Router Dist1 weitergeleitet werden knnen. Wie wir Listing 4.11 allerdings entnehmen knnen, funktioniert der Befehl ping 10.1.1.1 zwar, aber ping 168.13.200.1 schlgt fehl.

ANMERKUNG
Dieses Beispiel verwendet die Default-Route auf R1, wie sie mit dem Befehl ip route definiert und anhand der Listings 4.8 und 4.9 erlutert wurde. Es funktioniert allerdings unabhngig davon, wie die Default-Route erlernt wurde.
Listing 4.11: Fehlschlag eines ping-Befehls auf R3 aufgrund des klassenbezogenen Routings
R3#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is 168.13.100.1 to network 0.0.0.0 168.13.0.0/24 is subnetted, 4 subnets 168.13.1.0 [120/1] via 168.13.100.1, 00:00:13, Serial0.1 168.13.3.0 is directly connected, Ethernet0 168.13.2.0 [120/1] via 168.13.100.2, 00:00:06, Serial0.1 168.13.100.0 is directly connected, Serial0.1

R C R C

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen

261

Listing 4.11: Fehlschlag eines ping-Befehls auf R3 aufgrund des klassenbezogenen Routings (Forts.)
R3#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/89/114 ms R3# R3#ping 168.13.200.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 168.13.200.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Betrachten wir zunchst den Versuch von R3, fr die beiden Ziele (10.1.1.1 und 168.13.200.1) eine passende Route in der Routing-Tabelle zu finden. Die Routing-Tabelle von R3 enthlt jedoch abgesehen von der DefaultRoute keine Routen, die fr eine dieser IP-Adressen passend sind. Insofern ist die Verwendung der Default-Route die einzige Option fr R3. R3 ist fr die Verwendung des klassenbezogenen Routings konfiguriert. Beim klassenbezogenen Routing vergleicht der Router zunchst die Adresse des Klasse-A-, -B- oder -C-Netzwerks, in dem das Ziel vorhanden ist. Wird ein entsprechendes Netzwerk gefunden, dann sucht die Cisco IOS-Software nach der jeweiligen Subnetzadresse. Kann diese nicht gefunden werden, so wird das Paket verworfen. Dies ist beispielsweise der Fall bei den ICMPEchos, die mit dem Befehl ping 168.13.200.1 gesendet werden. Beim klassenbezogenen Routing hingegen wird, falls kein passendes Klasse-A-, -B- oder -C-Netzwerk gefunden wird, eine Default-Route jedoch vorhanden ist, diese auch verwendet. Deswegen kann R3 die ICMP-Echos weiterleiten, die vom erfolgreichen Befehl ping 10.1.1.1 generiert werden. Kurz gesagt, wird die Default-Route beim klassenbezogenen Routing nur verwendet, falls der Router keine Subnetze im Zielnetzwerk des Pakets kennt. Sie knnen zwischen klassenlosem und klassenbezogenem Routing mit den globalen Konfigurationsbefehlen ip classless bzw. no ip classless wechseln. Beim klassenlosen Routing sucht die Cisco IOS-Software nach dem passendsten Ergebnis und ignoriert dabei die Klassenregeln. Ist eine DefaultRoute vorhanden, dann ist zumindest diese beim klassenlosen Routing stets eine fr das Paket passende Route. Gibt es eine spezifischere Route fr den

262

CCNA ICND2-Prfungshandbuch

Empfnger des Pakets, so wird diese verwendet. Listing 4.12 zeigt R3 nach der Umstellung auf das klassenlose Routing sowie den erfolgreich an 168.13.200.1 abgesetzten ping-Befehl.
Listing 4.12: Dank klassenlosem Routing erfolgreich an 168.13.200.1 abgesetzter ping-Befehl
R3#configure terminal Enter configuration commands, one per line. R3(config)#ip classless 000000000000 R3(config)#^Z R3#ping 168.13.200.1 00000000000000000 End with CNTL/Z.

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 168.13.200.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/88/112 ms

4.6
4.6.1

Prfungsvorbereitung
Wiederholung

Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind in der Randspalte mit dem entsprechenden Symbol gekennzeichnet. Tabelle 4.3 listet diese Themen sowie die Seitennummern auf, auf denen die Themen zu finden sind.
Tabelle 4.3: Schlsselthemen in Kapitel 4
Element Liste Liste Liste Bemerkung Beschreibung Schritte, die ein Host bei der Weiterleitung von IP-Paketen durchfhrt Schritte, die ein Router bei der Weiterleitung von IP-Paketen durchfhrt Wiederholung der wichtigsten Aspekte der IP-Adressierung Zusammenfassende Aussage zu der von einem Router verwendeten Logik, sofern es zu einem Empfnger mehrere Routen gibt Angaben, die gewhnlich via DHCP erlernt werden Schritte und Protokolle, die ein Host bei der Kommunikation mit einem anderen Host verwendet Regeln dazu, wann ein Router eine angeschlossene Route erstellt Seite 225 226 230 233

Liste Liste Liste

235 237 240

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen


Tabelle 4.3: Schlsselthemen in Kapitel 4 (Forts.)
Element Liste Liste Tabelle 4.2 Beschreibung Regeln zur Absenderadresse, die fr mit dem IOS-Befehl ping generierte Pakete verwendet wird Schlsselfakten zur Definition statischer Default-Routen Zusammenfassung der drei gesonderten, aber verwandten Verwendungsformen fr die Begriffe klassenlos und klassenbezogen Definitionen zum klassenlosen und klassenbezogenen Routing

263

Seite 252 257 259

Liste

259

4.6.2

Vervollstndigen Sie die Listen und Tabellen

Drucken Sie aus Anhang J, Tabellen zur bung (auf der CD vorhanden), den Abschnitt zu diesem Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls auf der CD enthaltene Anhang K, Lsungen zu den bungen, enthlt die vollstndigen Tabellen und Listen, mit denen Sie Ihre Lsungen berprfen knnen.

4.6.3

Wichtige Definitionen

Definieren Sie die folgenden Schlsselbegriffe aus diesem Kapitel und berprfen Sie Ihre Antworten anhand des Glossars: erweiterter ping-Befehl, klassenbezogene Adressierung, klassenbezogenes Routing, klassenbezogenes Routing-Protokoll, klassenlose Adressierung, klassenloses Routing, klassenloses Routing-Protokoll, sekundre IP-Adresse, Subnetz Null

4.6.4

Befehlsreferenz

Wir fhren an dieser Stelle eine Referenz fr die in diesem Kapitel behandelten Befehle aus dem Konfigurations- und dem EXEC-Modus an. Eigentlich sollten Sie die Befehle beim Studieren des Kapitels und beim Durchfhren der Aktivitten in diesem Abschnitt zur Prfungsvorbereitung quasi als Nebeneffekt bereits verinnerlicht haben. Um zu berprfen, wie gut Sie diese Befehle schon kennen, sollten Sie die linke Spalte der Tabelle mit einem Blatt Papier abdecken. Lesen Sie dann bitte die Beschreibung in der rechten Spalte und kontrollieren Sie, ob Sie den betreffenden Befehl kennen.

264

CCNA ICND2-Prfungshandbuch

Tabelle 4.4: Referenz der Konfigurationsbefehle aus Kapitel 4


Befehl
encapsulation dot1q vlan-id [native]

Beschreibung Subschnittstellenbefehl, der den Router anweist, das 802.1Q-Trunking fr ein bestimmtes VLAN zu verwenden. Wird das Schlsselwort native angegeben, so erfolgt keine Kapselung in einem Trunking-Header. Subschnittstellenbefehl, der den Router anweist, das ISL-Trunking fr ein bestimmtes VLAN zu verwenden Globaler Befehl, der ein klassenloses Routing aktiviert (ip classless) bzw. deaktiviert (no ip classless) Globaler Befehl, der die Konfiguration einer IP-Adresse fr eine Schnittstelle im Subnetz Null gestattet (ip subnetzero) bzw. unterbindet (no ip subnetzero) Schnittstellenbefehl, der einer Schnittstelle eine IP-Adresse zuweist und diese Adresse optional zu einer sekundren Adresse macht Globaler Konfigurationsbefehl zur Erstellung einer statischen Route Globaler Befehl, der eine DefaultRoute basierend auf der Route erstellt, mit der der Router das im Befehl angegebene klassenbezogene Netzwerk erreicht

encapsulation isl vlan-identifier

[no] ip classless

[no] ip subnet-zero

ip address ip-address mask [secondary]

ip route prefix mask {ip-address | interface-type interface-number} [distance] [permanent] ip default-network network-number

Kapitel 4 IP-Routing: Statische und direkt verbundene Routen


Tabelle 4.5: Referenz der EXEC-Befehle aus Kapitel 4
Befehl
show ip route show ip route ip-address

265

Beschreibung Zeigt die gesamte Routing-Tabelle des Routers an. Fhrt detaillierte Angaben zu der Route auf, die zur angegebenen IP-Adresse passt. Testet IP-Routen durch Versenden von ICMP-Paketen an den Ziel-Host. Testet IP-Routen durch Ermittlung der IP-Adressen der Router auf dem Weg zum angegebenen Ziel.

ping {host-name | ip-address} traceroute {host-name | ip-address}

Dieses Kapitel behandelt die folgenden Themen


VLSM Dieser Abschnitt beschreibt die Probleme und zugehrigen Lsungen beim Design eines Netzwerks, das VLSM einsetzt. Manuelle Routenzusammenfassung Dieser Abschnitt erlutert das Prinzip der manuellen Routenzusammenfassung und veranschaulicht, wie man Netzwerke so gestaltet, dass sie eine einfachere Zusammenfassung ermglichen. Automatische Routenzusammenfassung und nicht zusammenhngende, klassenbezogene Netzwerke In diesem Abschnitt wird erklrt, was die automatische Routenzusammenfassung ist und wie sie bei einem Netzdesign bercksichtigt werden muss, das nicht zusammenhngende, klassenbezogene Adressbereiche im Netzwerk verwendet.

Kapitel 5
VLSM und Routenzusammenfassung
Whrend Kapitel 4, Problembehebung beim IP-Routing, den Schwerpunkt auf Themen in Verbindung mit dem IP-Routing legte, wollen wir uns in dem nun folgenden Kapitel auf Themen konzentrieren, die mit der IPAdressierung in Zusammenhang stehen: VLSM (Variable Length Subnet Masking) sowie die manuelle und die automatische Routenzusammenfassung. Diese Funktionen stehen in Verbindung mit dem IP-Adressbereich, der durch eine gegebene Adresse und Maske oder ein Subnetz definiert wird, das Bestandteil einer Summenroute ist. Aus diesem Grund erfordert dieses Kapitel ein umfassendes Verstndnis der IP-Adressierung, um die hier gegebenen Beispiele nachvollziehen zu knnen. In diesem Kapitel werden in erster Linie Konzepte beschrieben und showAusgaben gezeigt, whrend nur wenige neue Konfigurationsbefehle behandelt werden.

5.1

berprfen Sie Ihren Wissensstand

Dieser Abschnitt gestattet es Ihnen zu ermitteln, ob Sie das gesamte Kapitel lesen mssen. Wenn Sie maximal eine der folgenden acht Fragen zur Selbsteinschtzung nicht oder falsch beantworten, knnen Sie mit dem Abschnitt Aufgaben zur Prfungsvorbereitung fortfahren. Tabelle 5.1 listet die wichtigsten berschriften dieses Kapitels und die Nummern der Fragen auf, die sich auf die betreffenden Abschnitte beziehen. Auf diese Weise knnen Sie Ihr Wissen in den jeweiligen Bereichen selbst einschtzen. Die Antworten zu den Fragen in diesem Abschnitt finden Sie in Anhang A.
Tabelle 5.1: Zuordnung der folgenden Fragen zu den einzelnen Themengebieten
Grundlagenthema VLSM Manuelle Routenzusammenfassung Automatische Routenzusammenfassung und nicht zusammenhngende klassenbezogene Netzwerke Fragen 1 bis 3 4 bis 6 7 und 8

268

CCNA ICND2-Prfungshandbuch

1. Welches der folgenden Routing-Protokolle untersttzt VLSM? a) RIPv1 b) RIPv2 c) EIGRP d) OSPF 2. Wofr steht das Akronym VLSM? a) Variable Length Subnet Mask b) Very Long Subnet Mask c) Vociferous Longitudinal Subnet Mask d) Vector Length Subnet Mask e) Vector Loop Subnet Mask 3. Auf R1 wurde die Schnittstelle Fa0/0 mit dem Befehl ip address 10.5.48.1 255.255.240.0 konfiguriert. Welches der folgenden Subnetze wrde, wenn es auf einer anderen Schnittstelle von R1 konfiguriert wrde, nicht als berlappendes VLSM-Subnetz betrachtet werden? a) 10.5.0.0 255.255.240.0 b) 10.4.0.0 255.254.0.0 c) 10.5.32.0 255.255.224.0 d) 10.5.0.0 255.255.128.0 4. Welches der folgenden Subnetze stellt die kleinste zusammengefasste Route d. h. die Summenroute mit dem kleinsten Adressbereich dar, die die Subnetze 10.3.95.0, 10.3.96.0 und 10.3.97.0 (Subnetzmaske 255.255.255.0) enthlt? a) 10.0.0.0 255.0.0.0 b) 10.3.0.0 255.255.0.0 c) 10.3.64.0 255.255.192.0 d) 10.3.64.0 255.255.224.0 5. Welches der folgenden Subnetze ist keine gltige Zusammenfassung, welche die Subnetze 10.1.55.0, 10.1.56.0 und 10.1.57.0 (Subnetzmaske 255.255.255.0) enthlt? a) 10.0.0.0 255.0.0.0 b) 10.1.0.0 255.255.0.0

Kapitel 5 VLSM und Routenzusammenfassung c) 10.1.55.0 255.255.255.0 d) 10.1.48.0 255.255.248.0 e) 10.1.32.0 255.255.224.0

269

6. Welches der folgenden Routing-Protokolle untersttzt die manuelle Routenzusammenfassung? a) RIPv1 b) RIPv2 c) EIGRP d) OSPF 7. Welches oder welche Routing-Protokolle fhren in ihrer Default-Einstellung die automatische Routenzusammenfassung durch? a) RIPv1 b) RIPv2 c) EIGRP d) OSPF 8. In einem Netzwerk ist ein nicht zusammenhngendes Netzwerk 10.0.0.0 vorhanden. Nun gibt es Probleme mit diesem Netzwerk. Alle Router verwenden RIPv1 mit allen Standardeinstellungen. Welcher der folgenden Schritte kann ohne zustzliche Manahmen das Problem lsen und ein funktionsfhiges, im Adressbereich nicht zusammenhngendes Netzwerk ermglichen? a) Stellen Sie alle Router auf die Verwendung von OSPF um und belassen Sie soweit mglich die Default-Einstellungen. b) Deaktivieren Sie die Autosummierung mit dem RIP-Konfigurationsbefehl no auto-summary. c) Stellen Sie auf EIGRP um und belassen Sie soweit mglich die Voreinstellungen. d) Das Problem kann erst gelst werden, nachdem aus dem Netzwerk 10.0.0.0 ein durchgehendes Netzwerk gemacht wurde.

270

CCNA ICND2-Prfungshandbuch

5.2

Wissensgrundlage

Dieses Kapitel behandelt drei verwandte Themen: VLSM sowie manuelle und automatische Routenzusammenfassung. Diese Themen sind insofern miteinander verbunden, als ihnen hnliche mathematische Anstze zugrunde liegen. Beide setzen voraus, dass der Netzwerktechniker in der Lage ist, anhand einer Subnetzadresse und -maske schnell den zugehrigen Adressbereich zu bestimmen. Beginnen wollen wir dieses Kapitel mit VLSM. Spter werden wir uns der manuellen Routenzusammenfassung und schlielich der automatischen Routenzusammenfassung zuwenden.

5.3

VLSM

VLSM findet statt, wenn ein Netzwerk mehrere verschieden groe Subnetzmasken in den Subnetzen eines einzelnen Klasse-A-, -B- oder -C-Netzwerks benutzt. Mithilfe von VLSM kann ein Netzwerktechniker die Anzahl vergeudeter IP-Adressen in jedem Subnetz verringern; dies ermglicht die Bildung einer greren Zahl von Subnetzen, ohne dass man hierfr eine weitere registrierte IP-Netzwerkadresse von einer zentralen Registrierungsstelle beantragen msste. Aber auch bei Verwendung privater IP-Netzwerke (gem Definition in RFC 1918) mssen groe Unternehmen hufig Adressraum einsparen, was sich ebenfalls mit VLSM bewerkstelligen lsst. Abbildung 5.1 zeigt exemplarisch die Anwendung von VLSM im Klasse-ANetzwerk 10.0.0.0.
10.2.1.0 10.2.2.0 10.2.3.0 10.2.4.0 10.1.4.0/30 S0/0 S0/1

Albuquerque
10.1.6.0/30

10.3.4.0 10.3.5.0 10.3.6.0 10.3.7.0

Yosemite
10.1.1.0 Maske: 255.255.255.0, sofern nicht anders angegeben

Seville

Abbildung 5.1: VLSM im Netzwerk 10.0.0.0, Masken 255.255.255.0 und 255.255.255.252

Abbildung 5.1 zeigt eine typische Auswahl: die Verwendung des Prfixes /30 (Subnetzmaske 255.255.255.252) fr serielle Point-to-Point-Verbindungen und einer anderen Maske (in diesem Fall 255.255.255.0) in den LAN-Subnetzen. Alle Subnetze gehren zum Klasse-A-Netzwerk 10.0.0.0, und es werden zwei verschiedene Subnetzmasken verwendet, wodurch die Definition fr VLSM erfllt ist.

Kapitel 5 VLSM und Routenzusammenfassung

271

Eigentmlicherweise besteht ein hufig gemachter Fehler darin, dass angenommen wird, VLSM bedeute mehr als eine Subnetzmaske verwenden statt mehr als eine Maske in einem einzelnen klassenbezogenen Netzwerk verwenden. Beispielsweise werden auch dann, wenn in einem Netzwerkdiagramm alle Subnetze des Netzwerks 10.0.0.0 die Subnetzmaske 255.255.240.0 verwenden, whrend alle Subnetze des Netzwerks 11.0.0.0 die Maske 255.255.255.0 benutzen, zwei verschiedene Masken eingesetzt. Allerdings wird in den beiden klassenbezogenen Netzwerken jeweils nur eine Maske benutzt, was bedeutet, dass es sich nicht um VLSM handelt. Listing 5.1 zeigt die Routing-Tabelle von Albuquerque aus Abbildung 5.1. Albuquerque verwendet wie aus der hervorgehobenen Zeile hervorgeht im Netzwerk 10.0.0.0 zwei Masken.
Listing 5.1: Routing-Tabelle von Albuquerque mit VLSM
Albuquerque#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 11 subnets, 2 masks 10.2.1.0/24 [90/2172416] via 10.1.4.2, 00:00:34, Serial0/0 10.2.2.0/24 [90/2172416] via 10.1.4.2, 00:00:34, Serial0/0 10.2.3.0/24 [90/2172416] via 10.1.4.2, 00:00:34, Serial0/0 10.2.4.0/24 [90/2172416] via 10.1.4.2, 00:00:34, Serial0/0 10.3.4.0/24 [90/2172416] via 10.1.6.2, 00:00:56, Serial0/1 10.3.5.0/24 [90/2172416] via 10.1.6.2, 00:00:56, Serial0/1 10.3.6.0/24 [90/2172416] via 10.1.6.2, 00:00:56, Serial0/1 10.3.7.0/24 [90/2172416] via 10.1.6.2, 00:00:56, Serial0/1 10.1.1.0/24 is directly connected, Ethernet0/0 10.1.6.0/30 is directly connected, Serial0/1 10.1.4.0/30 is directly connected, Serial0/0

D D D D D D D D C C C

272

CCNA ICND2-Prfungshandbuch

5.3.1

Klassenbezogene und klassenlose Routing-Protokolle

Wenn ein Routing-Protokoll VLSM untersttzen will, muss es bei der Bekanntgabe von Routen nicht nur die Subnetzadresse, sondern auch die Subnetzmaske bekannt machen. Auerdem muss das Routing-Protokoll Subnetzmasken in seine Routing-Updates einbinden, um die manuelle Routenzusammenfassung zu ermglichen. Wenn ein Routing-Protokoll die Maske in Routing-Updates integriert, ist es klassenlos, andernfalls klassenbezogen. Jedes Routing-Protokoll ist seinem Wesen nach entweder klassenlos oder klassenbezogen es gibt keinen Befehl, mit dem man die Klassenbezogenheit eines Routing-Protokolls aktivieren oder deaktivieren knnte. Tabelle 5.2 fhrt die Routing-Protokolle auf und zeigt, welche klassenbezogen bzw. klassenlos sind. Auerdem enthlt sie Angaben zu den beiden Funktionen (VLSM und manuelle Routenzusammenfassung), die sich durch die Einbindung von Masken in die Routing-Updates aktivieren lassen.
Tabelle 5.2: Klassenbezogene und klassenlose interne Routing-Protokolle
Wichtig!

RoutingProtokoll RIPv1 IGRP RIPv2 EIGRP OSPF

Klassenlos? Sendet Masken Untersttzt in den Updates VLSM Nein Nein Ja Ja Ja Nein Nein Ja Ja Ja Nein Nein Ja Ja Ja

Untersttzt die manuelle Routenzusammenfassung Nein Nein Ja Ja Ja

5.3.2

berlappende VLSM-Subnetze

Die Adressbereiche von Subnetzen, die im Design eines IP-Netzwerkverbundes verwendet werden sollen, drfen sich nicht berlappen. Wenn in einem Netzwerk nur eine Subnetzmaske vorhanden ist, sind auftretende berschneidungen offenkundig; bei VLSM allerdings sind solche berschneidungen nicht unbedingt offensichtlich. Wenn sich mehrere Subnetze berschneiden, dann tun dies auch die Eintrge in der Routing-Tabelle eines Routers. Infolgedessen wird das Routing unvorhersehbar, und einige Hosts knnen nur aus bestimmten Teilen des Netzwerks heraus erreicht werden. Kurz gesagt, muss ein Adressentwurf, in dem berlappende Subnetze auftreten, als inkorrekt angesehen werden und darf nicht eingesetzt werden.

Kapitel 5 VLSM und Routenzusammenfassung

273

Es gibt sowohl in der Praxis als auch bei den Prfungen zwei allgemeine Kategorien von Problemen mit berlappenden Subnetzen: die Analyse eines vorhandenen Designs zur Ermittlung von berschneidungen sowie die Auswahl neuer VLSM-Subnetze derart, dass keine berlappende Subnetze auftreten. Um sich auf Aufgaben vorzubereiten, die in den Prfungen zum Thema VLSM und berlappende Subnetze vorkommen knnen, betrachten Sie bitte Abbildung 5.2. Hier wird ein einzelnes Klasse-B-Netzwerk 172.16.0.0 gezeigt, welches ein VLSM-Design mit drei verschiedenen Masken /23, /24 und /30 verwendet.
172.16.4.1/23 172.16.9.2/30 172.16.2.1/23 172.16.9.1/30 S0/0/1 Fa0/0 R1 S0/1/0 172.16.9.5/30 S0/0/1 172.16.9.6/30 R3 172.16.5.1/24 Fa0/0 R2 S0/0/1 Fa0/0

Abbildung 5.2: VLSM-Design mit mglicher berschneidung

Stellen wir uns nun vor, diese Abbildung erschiene in einer Prfungsaufgabe, in der direkt oder indirekt gefragt wird, ob berlappende Subnetze vorhanden sind. Bei einer solchen Aufgabe knnte beispielsweise angegeben sein, dass einige Hosts einander keine ping-Befehle senden knnen, und unter Umstnden ist noch nicht einmal erwhnt, dass eine berlappung der Subnetze als Ursache in Frage kommt. Um eine solche Frage zu beantworten, knnten Sie die folgenden Schritte abarbeiten, die zwar einfach, aber sehr arbeitsaufwendig sind: 1. Sie berechnen die Subnetzadresse und die Broadcast-Adresse aller Subnetze und erhalten als Ergebnis die Adressbereiche der einzelnen Subnetze. 2. Sie vergleichen die Adressbereiche in den einzelnen Subnetzen miteinander und suchen nach berschneidungen. In Abbildung 5.2 beispielsweise wrden Sie fnf Subnetze berprfen und in Schritt 1 zunchst die Subnetzadressen, Broadcast-Adressen und Adressbereiche berechnen. Die Ergebnisse sind in Tabelle 5.3 aufgefhrt.
Wichtig!

274

CCNA ICND2-Prfungshandbuch

Tabelle 5.3: Subnetze und Adressbereiche in Abbildung 5.2


Subnetzposition Subnetzadresse Erste Adresse Letzte Adresse Broadcast-Adresse LAN R1 LAN R2 LAN R3 Serielle Verbindung R1-R2 Serielle Verbindung R1-R3 172.16.2.0 172.16.4.0 172.16.5.0 172.16.9.0 172.16.9.4 172.16.2.1 172.16.4.1 172.16.5.1 172.16.9.1 172.16.9.5 172.16.3.254 172.16.3.255 172.16.5.254 172.16.5.255 172.16.5.254 172.16.5.255 172.16.9.2 172.16.9.6 172.16.9.3 172.16.9.7

Schritt 2 beschreibt den nun naheliegenden Schritt, die Adressbereiche zu vergleichen, um festzustellen, ob berschneidungen vorkommen. Beachten Sie, dass keine Subnetzadressen identisch sind; eine genauere berprfung von LAN R2 und LAN R3 zeigt aber, dass diese beiden Subnetze sich berlappen. In diesem Fall ist das Design aufgrund der berschneidung unbrauchbar, und eines der beiden Subnetze msste gendert werden.

5.3.3

Mit VLSM ein Subnetzschema bilden

Das CCENT/CCNA ICND1-Prfungshandbuch erlutert, wie man das IPAdressierungsschema fr einen neuen Netzwerkentwurf entwickelt, indem man nmlich IP-Subnetze mit einer einzigen Subnetzmaske fr ein vollstndiges klassenbezogenes Netzwerk einsetzt. Zu diesem Zweck werden zunchst die Designanforderungen analysiert, um die Anzahl der Subnetze und die Anzahl der Hosts im grten Subnetz zu bestimmen. Hierauf wird eine Subnetzmaske ausgewhlt. Schlielich werden alle bei Verwendung der Maske mglichen Subnetze des Netzwerks benannt. Aus dieser Liste werden dann die tatschlich zu benutzenden Subnetze ausgewhlt. Nehmen wir an, das Klasse-B-Netzwerk 172.16.0.0 bentigt ein Design mit mindestens zehn Subnetzen, deren grtes 200 Hosts untersttzen soll. Die Maske 255.255.255.0 erfllt diese Anforderungen, denn sie bietet je acht Subnetzund Hostbits und untersttzt so 256 Subnetze mit jeweils 254 Hosts. Die Subnetzadressen lauteten 172.16.0.0, 172.16.1.0, 172.16.2.0 usw. Wenn Sie VLSM in einem Design verwenden, steht am Anfang des Entwicklungsvorgangs die Frage, wie viele Subnetze welcher Gre gebraucht werden. So bentigen die meisten Installationen beispielsweise Subnetze mit dem Prfix /30 fr serielle Verbindungen, weil solche Subnetze genau zwei IP-Adressen untersttzen mehr braucht man fr eine Point-to-Point-Verbindung nun einmal nicht. LAN-basierte Subnetze stellen hufig unterschiedliche Anforderungen: krzere Prfixlngen (d. h. mehr Hostbits) fr

Kapitel 5 VLSM und Routenzusammenfassung

275

eine grere Zahl von Hosts pro Subnetz oder aber lngere Prfixe (also weniger Hostbits) fr eine kleinere Anzahl von Hosts im Subnetz.

ANMERKUNG
Um die Entwicklung von Subnetzen unter Verwendung von Subnetzmasken statischer Lnge (SLSM) zu wiederholen, lesen Sie noch einmal Kapitel 12 des CCENT/CCNA ICND1-Prfungshandbuches. (Sie finden das Kapitel auch als Anhang H auf der CD zu diesem Buch. Zudem enthlt auch der ebenfalls auf der CD vorhandene Anhang D, Praxis der Subnetzbildung, praxisrelevante Problemstellungen.) Nachdem die Anzahl der Subnetze pro Subnetzmaske ermittelt wurde, besteht der nchste Schritt darin, die Subnetzadressen festzustellen, die den Anforderungen entsprechen. Diese Aufgabe ist nicht besonders schwierig, da Sie bereits wissen, wie man mithilfe von Masken statischer Lnge die Subnetzadressen bestimmt. Allerdings kann auch eine formale Beschreibung hilfreich sein, wie sie nachfolgend aufgefhrt ist: 1. Bestimmen Sie basierend auf den Designanforderungen die Anzahl der Subnetze, die pro Maske/Prfix bentigt wird. 2. Ermitteln Sie beginnend mit der krzesten Prfixlnge (d. h. der grten Zahl von Hostbits) die Anzahl der Subnetze im klassenbezogenen Netzwerk bei Verwendung dieser Maske. Wiederholen Sie den Vorgang, bis die erforderliche Anzahl von Subnetzen festgestellt wird. 3. Ermitteln Sie die nchste numerische Subnetzadresse unter Verwendung derselben Maske wie im vorherigen Schritt. 4. Ermitteln Sie beginnend mit der im vorherigen Schritt ermittelten Subnetzadresse kleinere Subnetze basierend auf dem nchstlngeren fr das Design erforderlichen Prfix. Wiederholen Sie den Vorgang, bis am Ende die erforderliche Anzahl von Subnetzen der gewhlten Gre vorliegt. 5. Wiederholen Sie die Schritte 3 und 4, bis alle Subnetze aller Gren ermittelt wurden. Offen gestanden, erscheint die Verwendung der oben beschriebenen Anleitung ein wenig schwierig. Ein Beispiel wrde den Vorgang wahrscheinlich besser veranschaulichen. Stellen wir uns also ein Netzdesign vor, fr das die folgenden Designanforderungen ermittelt wurden, wie es in Schritt 1 vorgeschlagen wird.

276

CCNA ICND2-Prfungshandbuch

Bei diesem Design liegt die Verwendung des Klasse-B-Netzwerks 172.16.0.0 nahe: 3 Subnetze mit der Subnetzmaske /24 (255.255.255.0) 3 Subnetze mit der Subnetzmaske /26 (255.255.255.192) 4 Subnetze mit der Subnetzmaske /30 (255.255.255.252) Schritt 2 bedeutet in diesem Fall, dass die ersten drei Subnetze des Netzwerks 172.16.0.0 mit der Maske /24 ermittelt werden, denn /24 ist das krzeste der drei in den Anforderungen aufgefhrten Prfixe. Wir setzen dazu die im CCENT/CCNA ICND1-Prfungshandbuch detailliert beschriebene mathematische Methode ein und erhalten als erste drei Subnetze 172.16.0.0/ 24, 172.16.1.0/24 und 172.16.2.0/24: 172.16.0.0/24: Bereich 172.16.0.1172.16.0.254 172.16.1.0/24: Bereich 172.16.1.1172.16.1.254 172.16.2.0/24: Bereich 172.16.2.1172.16.2.254 Laut Schritt 3 mssen wir nun ein weiteres Subnetz mit der Maske /24 ermitteln, das heit, das nchste numerische Subnetz wre 172.16.3.0/24. Bevor wir mit Schritt 4 fortfahren, sehen wir uns einmal Abbildung 5.3 an. Der obere Teil der Abbildung zeigt die Ergebnisse von Schritt 2: Hier werden drei Subnetze aufgefhrt, die in diesem Schritt als Zugeordnet erkannt wurden, weil sie als Subnetze in diesem Design verwendet werden. Ebenfalls aufgefhrt ist das nchste Subnetz, das wir in Schritt 3 ermitteln. Es ist Nicht zugeordnet, weil es noch nicht als Bestandteil des Designs ausgewhlt wurde.
Schritt 2: Find subnets with /24 prefix Zugewiesen
172.16.0.0/24 172.16.0.0 172.16.0.255

Zugewiesen
172.16.1.0/24 172.16.1.1 172.16.1.255

Zugewiesen
172.16.29.0/25 172.16.2.1 172.16.2.255

Nicht zugewiesen
172.16.3.0/25 172.16.3.1 172.16.3.255

Schritte 3 und 4 (erster Durchlauf): Suchen Sie Subnetze mit dem Prfix /26.

Zugewiesen
172.16.3.0/26

Zugewiesen
172.16.3.64/26

Zugewiesen
172.16.3.128/26

Nicht zugewiesen
172.16.3.192/26

Schritte 3 und 4 (zweiter Durchlauf): Suchen Sie Subnetze mit dem Prfix /30.

Abbildung 5.3: Netzdesign mit VLSM-Subnetzen

Kapitel 5 VLSM und Routenzusammenfassung

277

Um in Schritt 4 die Subnetze zu finden, beginnen Sie mit der nicht zugeordneten Subnetzadresse, die Sie in Schritt 3 ermittelt haben. In Schritt 4 wenden Sie nun jedoch das nchstlngere Prfix an in unserem Beispiel /26. Dieser Prozess hat stets zum Ergebnis, dass die erste Subnetzadresse die im vorherigen Schritt gefundene Adresse ist (hier also 172.16.3.0). Die drei Subnetze sind die folgenden: 172.16.3.0/26: Bereich 172.16.3.1172.16.3.62 172.16.3.64/26: Bereich 172.16.3.65172.16.3.126 172.16.3.128/26: Bereich 172.16.3.129172.16.3.190 Schritt 5 schlielich besagt, dass die Schritte 3 und 4 zu wiederholen sind, bis alle Subnetze gefunden wurden. In diesem Fall wird durch Wiederholung von Schritt 3 das nchste Subnetz gefunden, das das Prfix /26 verwendet (nmlich 172.16.3.192/26). Das Subnetz gilt zu diesem Zeitpunkt als nicht zugeordnet. Um Schritt 4 fr das nchstlngste Prfix zu wiederholen, verwendet Schritt 4 das Prfix /30 und beginnt mit der Subnetzadresse 172.16.3.192. Das erste Subnetz ist 172.16.3.192 mit der Subnetzmaske /30, die nchsten drei Subnetze weisen dieselbe Maske auf: 172.16.3.192/30: Bereich 172.16.3.193172.16.3.194 172.16.3.196/30: Bereich 172.16.3.197172.16.3.198 172.16.3.200/30: Bereich 172.16.3.201172.16.3.202 172.16.3.204/30: Bereich 172.16.3.205172.16.3.206 Die Formulierung in diesem formalisierten Prozess mag etwas umstndlich erscheinen, hat jedoch VLSM-Subnetze zum Ergebnis, die sich nicht berschneiden. Mithilfe eines strukturierten Ansatzes, bei dem im Wesentlichen die greren und erst dann die kleineren Subnetze zugeordnet werden, knnen Sie die Subnetze so auswhlen, dass die Adressbereiche sich nicht berschneiden.

5.3.4

Neues Subnetz zu vorhandenem Design hinzufgen

Eine weitere Aufgabe, die bei der Arbeit mit VLSM-basierten Netzwerken erledigt werden muss, besteht in der Auswahl einer neuen, zustzlich erforderlichen Subnetzadresse fr einen vorhandenen Netzwerkentwurf. Spezielle Sorgfalt muss man insbesondere bei der Auswahl neuer Subnetzadressen walten lassen, um berschneidungen zwischen dem neuen Subnetz und den vorhandenen Subnetzen zu vermeiden. Betrachten Sie beispielsweise das Netzwerk in Abbildung 5.2 mit dem klassenbezogenen Netzwerk 172.16.0.0. In einer Prfungsaufgabe knnte etwa angegeben sein, dass zu

278

CCNA ICND2-Prfungshandbuch

diesem Design ein neues Subnetz mit dem Prfix /23 hinzugefgt werden muss. Die Frage knnte auch lauten: Whlen Sie die kleinste Subnetznummer aus, die fr dieses neue Subnetz verwendet werden kann. Insofern mssen zunchst die Subnetze ermittelt und nachfolgend ein Subnetz ohne berschneidungen ausgewhlt werden. Um ein solches Problem anzugehen, mssen Sie im Wesentlichen alle Subnetzadressen ermitteln, die sich in diesem klassenbezogenen Netzwerk erstellen lassen. Hierzu verwenden Sie die in der Aufgabe angegebene oder eine entsprechend erforderliche Maske. Danach mssen Sie sicherstellen, dass das neue Subnetz sich nicht mit den vorhandenen Subnetzen berschneidet. Hierzu knnten Sie wie folgt vorgehen:
Wichtig!

1. Sofern nicht bereits in der Frage aufgefhrt, whlen Sie die Subnetzmaske (Prfixlnge) basierend auf den beschriebenen Anforderungen aus, d. h. in den meisten Fllen auf der Anzahl der im Subnetz bentigten Hosts. 2. Berechnen Sie alle mglichen Subnetzadressen des klassenbezogenen Netzwerks unter Verwendung der in Schritt 1 bestimmten Maske. (Falls in der Aufgabe nach der numerisch grten oder kleinsten Subnetzadresse gefragt wird, knnten Sie die Berechnungen durchaus auf die ersten oder letzten paar Subnetze beschrnken.) 3. Berechnen Sie fr alle in Schritt 2 ermittelten, in Frage kommenden Subnetze die Broadcast-Adressen und den Adressbereich. 4. Vergleichen Sie die Listen der potenziellen und der tatschlich vorhandenen Subnetze und Adressbereiche. Schlieen Sie alle potenziellen Subnetze aus, bei denen eine berlappung mit einem vorhandenen Subnetz vorliegt. 5. Whlen Sie aus der in Schritt 2 ermittelten Liste eine Subnetzadresse aus, die keine berlappung mit vorhandenen Subnetzen aufweist, und achten Sie darauf, ob in der Aufgabe nach der kleinsten oder der grten Subnetzadresse gefragt wird. Im vor der Liste beschriebenen Beispiel wurde eine geforderte Prfixlnge von /23 fr das in Abbildung 5.2 gezeigte Netzwerk angegeben, was Schritt 1 entspricht. Tabelle 5.4 fhrt die Ergebnisse fr die Schritte 2 und 3 auf, d. h. die Subnetzadressen, Broadcast-Adressen und Adressbereiche fr die ersten fnf mglichen /23-Subnetze.

Kapitel 5 VLSM und Routenzusammenfassung


Tabelle 5.4: Die ersten fnf mglichen /23-Subnetze
Subnetz Subnetzadresse Erste Adresse 172.16.0.1 172.16.2.1 172.16.4.1 172.16.6.1 172.16.8.1

279

Letzte Adresse Broadcast-Adresse 172.16.1.254 172.16.3.254 172.16.5.254 172.16.7.254 172.16.9.254 172.16.1.255 172.16.3.255 172.16.5.255 172.16.7.255 172.16.9.255

Erstes (Null) 172.16.0.0 Zweites Drittes Viertes Fnftes 172.16.2.0 172.16.4.0 172.16.6.0 172.16.8.0

In Schritt 4 werden die Angaben aus der Tabelle mit den vorhandenen Subnetzen verglichen. In diesem Fall liegen beim zweiten, dritten, vierten und fnften Subnetz berschneidungen mit den in Abbildung 5.2 gezeigten vorhandenen Subnetzen vor. Schritt 5 schlielich ist eher fr Prfungsaufgaben als fr die Praxis relevant. Bei Multiple-Choice-Fragen sind manchmal auf genau eine Antwort beschrnkt, das heit, die Frage nach dem numerisch kleinsten oder grten Subnetz lst das Problem. Im vorliegenden Fall wurde nach der kleinsten Subnetzadresse gefragt, und das Subnetz Null ist noch vorhanden (172.16.0.0/23 mit der Broadcast-Adresse 172.16.1.255). Wenn die Aufgabe die Verwendung des Subnetzes Null gestattet, dann wre Subnetz Null (172.16.0.0/23) die korrekte Antwort. Wre das Subnetz Null hingegen von der Verwendung ausgeschlossen, so stnden die ersten vier in Tabelle 5.4 gezeigten Subnetze nicht zur Verfgung; in diesem Fall wre das sechste Subnetz (172.16.10.0/23) die richtige Antwort. Beachten Sie, dass das im Anhang F, Weitere Szenarien, auf der beiliegenden CD beschriebene Szenario 5 Ihnen die Mglichkeit bietet, genau diesen Vorgang zu ben.

ANMERKUNG
In der Prfung sollte das Subnetz Null nicht verwendet werden, falls a) die Frage auf die Verwendung klassenbezogener Routing-Protokolle hinweist, b) die Router mit dem globalen Konfigurationsbefehl no ip subnet-zero konfiguriert werden. Andernfalls knnen Sie davon ausgehen, dass das Subnetz Null eingesetzt werden darf.

280

CCNA ICND2-Prfungshandbuch

5.3.5

VLSM konfigurieren

Router knnen VLSM nicht aktivieren oder deaktivieren. Aus konfigurationstechnischer Sicht ist VLSM lediglich ein Nebeneffekt des Schnittstellenbefehls ip address. Router benutzen VLSM, weil sie ber mindestens zwei Router-Schnittstellen am selben Router oder ber alle Router im Verbund hinweg verfgen, die zwar IP-Adressen im selben klassenbezogenen Netzwerk aufweisen, aber mit unterschiedlichen Subnetzmasken arbeiten. Listing 5.2 zeigt ein einfaches Beispiel auf Router R3 aus Abbildung 5.2: Der Schnittstelle Fa0/0 wird die IP-Adresse 172.16.5.1/24 und der Schnittstelle S0/0/1 die Adresse 172.16.9.6/30 zugewiesen. Auf diese Weise kommen im Netzwerk 172.16.0.0 mindestens zwei unterschiedliche Masken zum Einsatz.
Listing 5.2: VLSM konfigurieren
R3#configure terminal R3(config)#interface Fa0/0 R3(config-if)#ip address 000000000000000000000000 172.16.5.1 255.255.255.0 R3(config-if)#interface S0/0/1 R3(config-if)#ip address 00000000000000000000000000 172.16.9.6 255.255.255.252

Klassenlose Routing-Protokolle, die VLSM untersttzen, mssen nicht fr die Aktivierung von VLSM konfiguriert werden: Die Untersttzung fr VLSM ist ein Merkmal, das diesen Routing-Protokollen eigen ist. Nun wollen wir mit dem zweiten groen Themenbereich des Kapitels fortfahren: der Zusammenfassung von Routen.

5.4

Manuelle Zusammenfassung von Routen

Bei kleinen Netzwerken verfgen die Router oft nur ber ein paar Dutzend Routen in den Routing-Tabellen. Je grer jedoch das Netzwerk ist, desto grer ist auch die Anzahl der Routen. Internet-Router verfgen in manchen Fllen ber 100.000 und mehr Routen. In umfangreichen IP-Netzwerken wird die Routing-Tabelle oft zu gro. Je strker die Routing-Tabellen an Umfang zunehmen, desto mehr Speicher bentigen sie im Router. Zudem bentigt jeder Router mehr Zeit, um ein Paket zu routen, da er zunchst eine passende Route in der Tabelle finden muss, was bei greren Tabellen naturgem lnger dauert. Auerdem dauert bei einer umfangreichen Routing-Tabelle auch die Behebung von Problemen lnger, da die mit dem Netzwerk befassten Techniker mehr Daten berprfen mssen.

Kapitel 5 VLSM und Routenzusammenfassung

281

Die Routenzusammenfassung verringert die Gre von Routing-Tabellen, behlt aber Routen zu allen Zielen im Netzwerk bei. Auf diese Weise lsst sich die Routing-Leistung verbessern, und auf dem Router kann Speicher eingespart werden. Zudem verbessert die Zusammenfassung auch die Konvergenz, denn ein Router, der die Routen summiert, muss nicht mehr alle nderungen am Status einzelner Subnetze bekannt geben. Dadurch, dass die gesamte Route entweder als aktiv oder inaktiv ausgewiesen wird, muss der Router mit der Summenroute nicht jedes Mal aufs Neue konvergieren, wenn eines der beteiligten Subnetze aktiv bzw. inaktiv wird. In diesem Kapitel wird die Zusammenfassung von Routen als manuelle Routenzusammenfassung bezeichnet im Gegensatz zum letzten groen Thema des Kapitels, der Autosummierung. Der Begriff manuell verweist auf die Tatsache, dass die manuelle Routenzusammenfassung nur erfolgt, falls ein Techniker sie mit einem oder mehreren Befehlen konfiguriert. Die Autosummierung hingegen findet automatisch und ohne Eingriff statt. In den folgenden Abschnitten werden wir zunchst die Zusammenfassung von Routen behandeln und die Frage betrachten, wie man gute Summenrouten ermittelt. Beachten Sie, dass wir zwar das Prinzip, nicht aber die Konfiguration manuell zusammengefasster Routen in diesem Buch behandeln.

5.4.1

Prinzip der Routenzusammenfassung

Techniker setzen die Routenzusammenfassung ein, um die Gre der Routing-Tabellen im Netzwerk zu verringern. Die Routenzusammenfassung bewirkt, dass eine Anzahl spezifischerer Routen durch eine Einzelroute ersetzt werden, die alle IP-Adressen enthlt, die von den Subnetzen der Ursprungsrouten abgedeckt wurden. Summenrouten, die mehrere Routen ersetzen, mssen von einem Netzwerktechniker konfiguriert werden. Zwar sieht der Konfigurationsbefehl nicht ganz genau so aus wie ein Befehl fr statische Routen, doch es werden dieselben Grundinformationen konfiguriert. Nun gibt das Routing-Protokoll nicht mehr die Originalrouten, sondern nur noch die Summenroute bekannt. Die Routenzusammenfassung funktioniert wesentlich besser, wenn das Netzwerk bereits in der Netzdesignphase darauf vorbereitet wird. So zeigt Abbildung 5.1 weiter oben in diesem Kapitel die Folgen guter geplanter Routenzusammenfassung. In diesem Netzwerk hat der Netzwerktechniker seine Entscheidungen bezglich der Subnetzadressen im Hinblick auf die Tatsache getroffen, dass die Routenzusammenfassung eingesetzt wird. Alle Subnetze, die vom Hauptstandort Albuquerque ausgehen (einschlielich der WAN-Verbindungen), beginnen mit 10.1. Alle von Yosemite ausgehenden

282

CCNA ICND2-Prfungshandbuch

LAN-Subnetze beginnen mit 10.2, und analog beginnen auch alle Subnetze von Seville mit 10.3. Listing 5.1 weiter oben in diesem Kapitel zeigte eine Kopie der RoutingTabelle von Albuquerque ohne Zusammenfassung. Dort waren vier Routen zu Subnetzen vorhanden, deren Adressen mit 10.2 beginnen und die alle ber die serielle Schnittstelle S0/0 zu Yosemite verlaufen. Weiter waren vier Routen zu Subnetzen vorhanden, deren Adressen mit 10.3 beginnen und die alle ber die serielle Schnittstelle S0/1 zu Seville verlaufen. Ein solches Design gestattet den Routern Yosemite und Seville die Bekanntmachung einer Einzelroute anstelle von jeweils vier Routen, die gegenwrtig gegenber Albuquerque bekannt gegeben werden. Listing 5.3 zeigt die Ergebnisse der Konfiguration einer manuellen Routenzusammenfassung auf Yosemite und Seville. In diesem Fall weist Yosemite eine Summenroute nach 10.2.0.0/16 aus, die den Adressbereich 10.2.0.010.2.255.255 darstellt (d. h. alle Adressen, die mit 10.2 beginnen). Seville weist eine Summenroute nach 10.3.0.0/16 aus, die den Adressbereich 10.3.0.0-10.3.255.255 darstellt (d. h. alle Adressen, die mit 10.3 beginnen).
Listing 5.3: Routing-Tabelle von Albuquerque nach der Routenzusammenfassung
Albuquerque#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks 10.2.0.0/16 [90/2172416] via 10.1.4.2, 00:05:59, Serial0/0 10.3.0.0/16 [90/2172416] via 10.1.6.3, 00:05:40, Serial0/1 10.1.1.0/24 is directly connected, Ethernet0/0 10.1.6.0/30 is directly connected, Serial0/1 10.1.4.0/30 is directly connected, Serial0/0

D D C C C

Die resultierende Routing-Tabelle routet die Pakete weiterhin korrekt, tut dies jedoch effizienter und mit geringerem Speicherverbrauch. Zugegeben: Eine Verbesserung von elf auf fnf Routen ist nicht besonders hilfreich. Aber wenn Sie das Konzept auf wesentlich grere Netzwerke anwenden, knnen Sie einen erheblichen Effekt durchaus feststellen.

Kapitel 5 VLSM und Routenzusammenfassung

283

Die Folgen der Routenzusammenfassung lassen sich auch auf den beiden anderen Routern in der Abbildung erkennen. Listing 5.4 zeigt die Konfiguration der Routenzusammenfassung und die Routing-Tabelle von Yosemite, Listing 5.5 dieselben Informationen zu Seville.
Listing 5.4: Konfiguration und Routing-Tabelle von Yosemite nach der Routenzusammenfassung
Yosemite#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Yosemite(config)#interface serial 0/0 Yosemite(config-if)#ip summary-address eigrp 1 10.2.0.0 255.255.0.0 00000000000000000000000000000000000000000000000 Yosemite(config-if)#^Z Yosemite#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks 10.2.0.0/16 is a summary, 00:04:57, Null0 10.3.0.0/16 [90/2684416] via 10.1.4.1, 00:04:30, Serial0/0 10.2.1.0/24 is directly connected, FastEthernet0/0 10.1.1.0/24 [90/2195456] via 10.1.4.1, 00:04:52, Serial0/0 10.2.2.0/24 is directly connected, Loopback2 10.2.3.0/24 is directly connected, Loopback3 10.2.4.0/24 is directly connected, Loopback4 10.1.6.0/30 [90/2681856] via 10.1.4.1, 00:04:53, Serial0/0 10.1.4.0/30 is directly connected, Serial0/0

D D C D C C C D C

Listing 5.5: Konfiguration und Routing-Tabelle von Seville nach der Routenzusammenfassung
Seville#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Seville(config)#interface serial 0/0 Seville(config-if)#ip summary-address eigrp 1 10.3.0.0 255.255.0.0 00000000000000000000000000000000000000000000000 Seville(config-if)#^Z Seville#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

284

CCNA ICND2-Prfungshandbuch

Listing 5.5: Konfiguration und Routing-Tabelle von Seville nach der Routenzusammenfassung (Forts.)
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks 10.2.0.0/16 [90/2684416] via 10.1.6.1, 00:00:36, Serial0/0 10.3.0.0/16 is a summary, 00:00:38, Null0 10.1.1.0/24 [90/2195456] via 10.1.6.1, 00:00:36, Serial0/0 10.3.5.0/24 is directly connected, Loopback5 10.3.4.0/24 is directly connected, FastEthernet0/0 10.1.6.0/30 is directly connected, Serial0/0 10.3.7.0/24 is directly connected, Loopback7 10.1.4.0/30 [90/2681856] via 10.1.6.1, 00:00:36, Serial0/0 10.3.6.0/24 is directly connected, Loopback6

D D D C C C C D C

Die Konfiguration der Routenzusammenfassung unterscheidet sich je nach Routing-Protokoll. Im vorliegenden Beispiel verwenden wir EIGRP (Enhanced IGRP). Die Summenrouten fr EIGRP werden auf Yosemite und Seville mit dem Schnittstellenbefehl ip summary-address erstellt. Dieser Befehl definiert jeweils eine neue zusammenfassende Route und weist EIGRP an, ber diese Schnittstelle nur die Summenroute und keine in ihr enthaltenen Einzelrouten bekannt zu geben. So definiert Yosemite beispielsweise eine Summenroute nach 10.2.0.0 mit der Maske 255.255.0.0. Diese Route hat als Ziel alle Hosts, deren IP-Adressen mit 10.2 beginnen. Im Endeffekt bewirkt dieser Befehl, dass Yosemite und Seville statt ihrer ursprnglichen vier LANSubnetze jeweils nur die Route 10.2.0.0 255.255.0.0 bzw. 10.3.0.0 255.255.0.0 bekannt machen. Beachten Sie, dass die Routing-Tabelle von Albuquerque in Listing 5.3 weiter oben eine Route nach 10.2.0.0 255.255.0.0 enthlt (die Maske wird als Prfix /16 angegeben), aber keines der ursprnglichen vier Subnetze, die auf 10.2 beginnen. Gleiches gilt fr die Route 10.3.0.0/16. Die Routing-Tabellen auf Yosemite und Seville sehen ein bisschen anders aus als die von Albuquerque. Wenn wir uns zunchst Yosemite (Listing 5.4) ansehen, stellen wir fest, dass die vier Routen in Subnetzen erscheinen, die mit 10.2 beginnen, da es sich um direkt angeschlossene Subnetze handelt. Die vier 10.3-Routen kennt Yosemite hingegen nicht. Stattdessen ist eine Summenroute angegeben, weil Albuquerque jetzt nur noch die Summenroute 10.3.0.0/16 bekannt macht. Das Gegenteil gilt fr Seville (Listing 5.5):

Kapitel 5 VLSM und Routenzusammenfassung

285

Hier sind, weil diese direkt angeschlossen sind, alle vier mit 10.3 beginnenden Routen sowie zustzlich eine Summenroute fr 10.2.0.0/16 angegeben. Der interessanteste Teil der Routing-Tabellen von Yosemite ist die Route nach 10.2.0.0/16, denn hier ist als Ausgangsschnittstelle null0 festgelegt. Wenn eine Route diese Ausgangsschnittstelle angibt, bedeutet dies, dass Pakete, die ber diese Route gesendet wrden, verworfen werden. EIGRP hat diese Route einschlielich der Schnittstelle null0 aufgrund des Befehls ip summary-address hinzugefgt. Logisch gesehen ist Folgendes passiert: Yosemite bentigt diese eigentlich abwegig erscheinende Route, weil er durchaus Pakete empfangen kann, die fr andere 10.2-Adressen als die vier vorhandenen 10.2-Subnetze vorgesehen sind. Wenn ein Paket eintrifft, das als Ziel eines der vier vorhandenen 10.2.x-Subnetze ausweist, verfgt Yosemite dafr immer ber eine korrekte, spezifischere Route. Wird hingegen ein Paket empfangen, dessen Empfngeradresse zwar mit 10.2 beginnt, aber kein Bestandteil der vier Subnetze ist, dann ist diese Nullroute die passende Route, und Yosemite verwirft das Paket. Genau so soll es sein. Die Routing-Tabelle von Seville sieht hinsichtlich der Tabelleneintrge und aufgrund ihres Vorhandenseins hnlich aus wie die von Yosemite.

5.4.2

Strategien der Routenzusammenfassung

Wie bereits erwhnt, funktioniert die Zusammenfassung von Routen am besten, wenn der Netzwerktechniker die Vergabe der Subnetzadressen bereits in dem Wissen durchfhrt, dass eine solche Zusammenfassung erfolgen wird. Die bisher aufgefhrten Beispiele gingen von einer wohldurchdachten Planung aus. So wurden etwa alle vom Router Yosemite abgehenden Subnetze mit dem Adressbereich 10.2.x versehen. Diese Konvention gestattete die Erstellung einer Summenroute fr alle Adressen, die mit 10.2 beginnen. Hierzu gibt Yosemite eine Route bekannt, die das Subnetz 10.2.0.0 mit der Maske 255.255.0.0 betrifft. Einige Summenrouten fassen mehrere Routen zu einer zusammen, aber dies muss nicht immer die beste Zusammenfassung sein. Die beste Summenroute ist im Zusammenhang mit der Konfiguration von Summenrouten diejenige, die alle erforderlichen Subnetze, aber so wenig andere Adressen wie mglich enthlt. In obigem Beispiel fasste Yosemite vier Subnetze (10.2.1.0, 10.2.2.0, 10.2.3.0 und 10.2.4.0, jeweils mit der Subnetzmaske 255.255.255.0) zur Summenroute 10.2.0.0/16 zusammen. Diese Zusammenfassung enthlt jedoch auch eine Menge IP-Adressen, die nicht Bestandteil dieser vier Subnetze sind. Funktioniert eine solche Kombination im Hinblick auf die Ziele des Netzdesigns? Gewiss. Doch statt einfach eine Zusammenfassung zu definieren, die zahlreiche in einem Netzwerk nicht

286

CCNA ICND2-Prfungshandbuch

vorhandene Adressen umfasst, sollte der Netzwerktechniker stets die knappste also beste Zusammenfassung whlen: diejenige, die alle erforderlichen, aber so wenig zustzliche (d. h. noch nicht zugeordnete) Subnetze wie mglich enthlt. In diesem Abschnitt wird eine Strategie beschrieben, um diese prgnanteste Summenroute zu finden. Die folgende Liste beschreibt einen allgemeinen binren Rechenweg, mit dem man fr eine Gruppe von Subnetzen die beste Summenroute ermittelt:
Wichtig!

1. Notieren Sie alle zu summierenden Subnetzadressen in Binrform. 2. Ermitteln Sie von links nach rechts die ersten n Bits, die bei allen Subnetzadressen gleich sind. (Dieser Teil wird im Folgenden als gemeinsamer Teil bezeichnet.) 3. Um die Netzwerkadresse des summierenden Routers zu ermitteln, notieren Sie die gemeinsamen Bits aus Schritt 2 und fllen die verbleibenden Bits mit binren Nullen auf. Konvertieren Sie den resultierenden Wert wieder in das Dezimalformat, und zwar jeweils acht Bits gleichzeitig. 4. Um die Netzmaske der Summenroute zu ermitteln, notieren Sie n binre Einsen; n ist dabei die Anzahl der in Schritt 2 ermittelten gemeinsamen Bits. Fllen Sie die Subnetzmaske dann mit binren Nullen auf. Konvertieren Sie den resultierenden Wert wieder in das Dezimalformat, und zwar jeweils acht Bits gleichzeitig. 5. berprfen Sie den Vorgang, indem Sie den Bereich der gltigen IPAdressen, die neue Summenroute impliziert, berechnen und ihn mit den zu summierenden Subnetzen vergleichen. Die neue Summenroute sollte alle IP-Adressen in den summierten Subnetzen umfassen. Durch die binre Darstellung knnen Sie die gemeinsamen Bits in allen Subnetzadressen schneller ausmachen. Die beste Summenroute finden Sie dann durch Ermittlung der grten Anzahl gemeinsamer Bits. In den nchsten beiden Abschnitten ermitteln wir exemplarisch die besten also prgnantesten Routen fr das in Abbildung 5.1 gezeigte Netzwerk.

Beste Summenroute fr Seville (Beispiel)


An Seville sind die Subnetze 10.3.4.0, 10.3.5.0, 10.3.6.0 und 10.3.7.0 angeschlossen, die alle die Subnetzmaske 255.255.255.0 haben. Notieren Sie zunchst alle Subnetzadressen in ihrer jeweiligen Binrform:
0000 0000 0000 0000 1010 1010 1010 1010 0000 0000 0000 0000 0011 0011 0011 0011 0000 0000 0000 0000 01 01 01 01 00 01 10 11 0000 0000 0000 0000 0000 0000 0000 0000 10.3.4.0 10.3.5.0 10.3.6.0 10.3.7.0

Kapitel 5 VLSM und Routenzusammenfassung

287

Schritt 2 sieht vor, dass Sie alle gemeinsamen Bits am Anfang aller Subnetze ermitteln. Noch bevor Sie sich die Binrzahlen genauer ansehen, wissen Sie bereits, dass die ersten beiden Oktette in allen vier Subnetzen identisch sind. Ein kurzer Blick auf die ersten 16 Bits aller vier Subnetzadressen besttigt diese Annahme. Dies bedeutet, dass der gemeinsame Anteil (Schritt 2) mindestens 16 Bit lang ist. Die weitere berprfung frdert zutage, dass die ersten sechs Bits des dritten Oktetts ebenfalls berall dieselben sind; das siebte Bit im dritten Oktett jedoch weist unterschiedliche Werte bei den verschiedenen Subnetzen auf. Insofern umfasst der gemeinsame Anteil der vier Subnetze die ersten 22 Bits. Schritt 3 sieht die Erstellung einer Subnetzadresse fr die Summenroute vor. Hierzu werden die ermittelten gemeinsamen Bits notiert und fr die verbleibenden Bits binre Nullen ergnzt. In diesem Fall sieht das wie folgt aus:
0000 1010 0000 0011 0000 01 00 0000 0000 - 10.3.4.0

In Schritt 4 wird die Maske erstellt. Hierzu werden fr den gemeinsamen Teil binre Einsen gesetzt, die verbleibenden Bits werden als Nullen notiert:
1111 1111 1111 1111 1111 11 00 0000 0000 - 255.255.252.0

Am Ende steht die Summenroute mit dem Subnetz 10.3.4.0 und der Subnetzmaske 255.255.252.0. Schritt 5 beschreibt eine Methode zur berprfung des Vorgangs. Die Summenroute sollte alle IP-Adressen in den zu summierenden Routen umfassen. In diesem Fall beginnt der Adressbereich fr die Summenroute bei 10.3.4.0. Die erste gltige IP-Adresse ist 10.3.4.1, die letzte 10.3.7.254. Als Broadcast-Adresse wird 10.3.7.255 verwendet. Die Summenroute enthlt alle IPAdressen in den vier zusammengefassten Routen und keine Fremdadressen.

Beste Summenroute fr Yosemite (Beispiel)


Die vier Subnetze auf Yosemite knnen nicht so effizient zusammengefasst werden wie bei Seville. Bei Seville erstreckt sich die Summenroute ber die gleiche Anzahl von IP-Adressen wie die vier Subnetze; zustzliche Adressen sind nicht vorhanden. Wie Sie feststellen werden, enthlt die beste Summenroute auf Yosemite doppelt so viele Adressen, wie in den ursprnglichen vier Subnetzen vorhanden sind. An Yosemite sind die Subnetze 10.2.1.0, 10.2.2.0, 10.2.3.0 und 10.2.4.0 angeschlossen, die alle die Subnetzmaske 255.255.255.0 besitzen. Der Vor-

288

CCNA ICND2-Prfungshandbuch

gang beginnt damit, dass Sie alle Subnetzadressen in ihrer jeweiligen Binrform notieren:
0000 0000 0000 0000 1010 1010 1010 1010 0000 0000 0000 0000 0010 0010 0010 0010 0000 0000 0000 0000 0 0 0 0 001 010 011 100 0000 0000 0000 0000 0000 0000 0000 0000 10.2.1.0 10.2.2.0 10.2.3.0 10.2.4.0

In Schritt 2 sind die ersten beiden Oktette in allen vier Subnetzen identisch. Hinzu kommen die ersten fnf Bits des dritten Oktetts, die ebenfalls berall dieselben sind. Also besteht der gemeinsame Teil aus den ersten 21 Bits der vier Subnetzadressen. Schritt 3 sieht die Erstellung einer Subnetzadresse fr die Summenroute vor. Hierzu werden die ermittelten gemeinsamen Bits notiert und fr die verbleibenden Bits binre Nullen ergnzt. In diesem Fall sieht das wie folgt aus:
0000 1010 0000 0010 0000 0 000 0000 0000 - 10.2.0.0

In Schritt 4 wird die Maske fr die Summenroute erstellt. Hierzu werden binre Einsen fr den gemeinsamen Teil gesetzt, die dann mit binren Nullen ergnzt werden. Der gemeinsame Teil umfasst in diesem Beispiel die ersten 21 Bits:
1111 1111 1111 1111 1111 1 000 0000 0000 - 255.255.248.0

Die beste Summenroute ist also 10.2.0.0 mit der Maske 255.255.248.0. Schritt 5 beschreibt eine Methode zur berprfung des Vorgangs. Die Summenroute sollte alle IP-Adressen in den summierten Routen umfassen. In diesem Fall beginnt der Adressbereich bei 10.2.0.0. Die erste gltige IPAdresse ist 10.2.0.1, die letzte 10.2.7.254. Als Broadcast-Adresse wird 10.2.7.255 verwendet. Die Summenroute fasst hier eine grere Menge von Adressen zusammen als nur die vier Subnetze. Enthalten sind aber alle Adressen aus den vier Subnetzen.

5.5

Autosummierung und nicht zusammenhngende klassenbezogene Netzwerke

Wie in den vorherigen Abschnitten beschrieben, kann die manuelle Routenzusammenfassung durch Verkrzen der Routing-Tabellen die Effizienz des Routings verbessern, den Speicherverbrauch verringern und die Konvergenz optimieren. Der letzte Abschnitt dieses Kapitels befasst sich mit der automatischen Zusammenfassung von Routen an den Grenzen klassenbezogener Netzwerke. Hierzu kommt eine als Autosummierung bezeichnete Funktionalitt zum Einsatz.

Kapitel 5 VLSM und Routenzusammenfassung

289

Da klassenbezogene Routing-Protokolle keine Angaben zu Subnetzmasken weitergeben, enthalten die Routing-Updates zwar Subnetzadressen, aber nicht die zugehrigen Masken. Ein Router, der ein Routing-Update mit einem klassenbezogenen Routing-Protokoll empfngt, berprft die Subnetzadresse im Update, muss aber dann selbst Vermutungen darber anstellen, welche Maske mit dem Subnetz verknpft ist. Wenn beispielsweise an die Cisco-Router R1 und R2 Subnetze desselben Klasse-A-, -B- oder -CNetzwerks angeschlossen sind und R2 nun ein Update von R1 empfngt, geht R2 davon aus, dass die Routen, die im Update von R1 beschrieben sind, dieselbe Maske verwenden wie R2. Mit anderen Worten erfordern klassenbezogene Routing-Protokolle eine SLSM (Static Length Subnet Mask, Subnetzmaske fester Lnge) im gesamten klassenbezogenen Netzwerk, damit jeder Router begrndet annehmen kann, dass die fr seine eigenen Schnittstellen konfigurierte Maske mit der in diesem klassenbezogenen Netzwerk verwendeten identisch ist. Verfgt ein Router ber Schnittstellen in mehreren Klasse-A-, -B- oder -CNetzwerken, dann kann er eine einzelne Route fr ein gesamtes Klasse-A-, -B- oder -C-Netzwerk im anderen klassenbezogenen Netzwerk bekannt geben. Diese Funktionalitt heit Autosummierung. Sie lsst sich wie folgt charakterisieren: Sofern Routen ber eine Schnittstelle bekannt gegeben werden, deren IP-Adresse sich nicht im Netzwerk X befindet, werden Routen in das Netzwerk X summiert und als einzelne Route weitergegeben. Die Route bezieht sich dann auf das gesamte jeweilige Klasse-A-, -B- oder -C-Netzwerk von X. Anders formuliert: Wenn R3 ber Schnittstellen in den Netzwerken 10.0.0.0 und 11.0.0.0 verfgt und nun Routing-Updates ber Schnittstellen bekannt gibt, deren IP-Adressen mit 11 beginnen, dann enthalten die Updates genau eine Route in das Netzwerk 10.0.0.0. hnlich gibt R3 genau eine Route nach 11.0.0.0 ber diejenigen seiner Schnittstellen bekannt, deren IP-Adressen mit 10 beginnen.
Wichtig!

5.5.1

Autosummierung: Ein Beispiel

Wie blich kann auch hier ein Beispiel das Prinzip wesentlich deutlicher veranschaulichen. Betrachten Sie Abbildung 5.4. Hier kommen zwei Netzwerke zum Einsatz: 10.0.0.0 und 172.16.0.0. Seville verfgt ber vier (angeschlossene) Routen in die Subnetze von 10.0.0.0. Listing 5.6 zeigt die Ausgabe des Befehls show ip route auf Albuquerque sowie die Ausgabe des RIPv1-Befehls debug ip rip.

290

CCNA ICND2-Prfungshandbuch
10.3.4.0 172.16.3.0 S0/1 10.3.5.0 10.3.6.0 10.3.7.0

Albuquerque
Ich kenne nur das Netzwerk 10.0.0.0, aber keine Subnetze!

Seville
172.16.1.0 Maske: 255.255.255.0

Abbildung 5.4: Autosummierung


Listing 5.6: Routen und RIP-Debugging auf Albuquerque
Albuquerque#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 2 subnets 172.16.1.0 is directly connected, Ethernet0/0 172.16.3.0 is directly connected, Serial0/1 10.0.0.0/8 [120/1] via 172.16.3.3, 00:00:28, Serial0/1

C C R

Albuquerque#debug ip rip RIP protocol debugging is on 00:05:36: RIP: received v1 update from 172.16.3.3 on Serial0/1 00:05:36: 10.0.0.0 in 1 hops

Wie aus Listing 5.6 hervorgeht, enthlt das von Albuquerque auf S0/1 empfangene Update, das von Seville stammt, nur das Klasse-A-Netzwerk 10.0.0.0, weil die Autosummierung auf Seville (standardmig) aktiviert ist. Infolgedessen gibt die Routing-Tabelle auf Albuquerque nur eine einzige Route in das Netzwerk 10.0.0.0 an. Dieses Beispiel veranschaulicht zudem noch einen anderen Faktor, aufgrund dessen klassenbezogene Routing-Protokolle Annahmen treffen. Albuquerque verfgt ber keine Schnittstelle im Netzwerk 10.0.0.0. Insofern nimmt Albuquerque beim Empfang des Routing-Updates an, dass die bei 10.0.0.0 verwendete Maske 255.0.0.0 sein muss, denn dies ist die Standardmaske eines Klasse-A-Netzwerks. Mit anderen Worten gehen klassenbezogene Routing-Protokolle davon aus, dass immer eine Autosummierung stattfindet.

Kapitel 5 VLSM und Routenzusammenfassung

291

5.5.2

Nicht zusammenhngende klassenbezogene Netzwerke

Die Autosummierung ist unproblematisch, solange das summierte Netzwerk zusammenhngend ist. In den Vereinigten Staaten beispielsweise kennt man das Konzept eines nicht zusammenhngenden Netzwerks: Es gibt den gngigen Begriff Contiguous 48, der auf die 48 zusammenhngenden US-Bundesstaaten verweist. Ausnahmen sind Alaska und Hawaii. Wenn Sie also aus den Contiguous 48 nach Alaska fahren wollen, mssen Sie ein Drittland durchqueren (nmlich Kanada nur fr den Fall, dass Sie Ihren Weltatlas gerade nicht zur Hand haben). Es gibt keine direkte Verbindung mit den 48 anderen Staaten Alaska ist also abgetrennt (engl. discontiguous). Um die Bedeutung der Begriffe zusammenhngend und nicht zusammenhngend in der Netzwerktechnik besser verstehen zu knnen, lesen Sie die beiden folgenden formalen Definitionen und behalten Sie sie beim Studieren des nachfolgenden Beispiels zu einem nicht zusammenhngenden Netzwerk im Hinterkopf: Zusammenhngendes Netzwerk: Ein klassenbezogenes Netzwerk, in dem Pakete, die zwischen zwei Subnetzen ausgetauscht werden, nur Subnetze desselben klassenbezogenen Netzwerks passieren knnen. Subnetze anderer klassenbezogener Netzwerke knnen nicht passiert werden. Nicht zusammenhngendes Netzwerk: Ein klassenbezogenes Netzwerk, in dem Pakete, die zwischen zwei Subnetzen ausgetauscht werden, Subnetze eines anderen klassenbezogenen Netzwerks passieren mssen. Abbildung 5.5 zeigt exemplarisch das nicht zusammenhngende Netzwerk 10.0.0.0. In diesem Fall werden Pakete, die aus den Subnetzen des Netzwerks 10.0.0.0 auf der linken Seite (bei Yosemite) in die Subnetze desselben Netzwerks auf der rechten Seite (bei Seville) gesendet werden mssen, ber Subnetze des Netzwerks 172.16.0.0 bertragen.
Wichtig!

Welcher Route in das Netzwerk 10.0.0.0 glaube ich? 10.2.1.0 10.2.2.0 10.2.3.0 10.2.4.0 172.16.2.0 S0/0 S0/1

Albuquerque
172.16.3.0

10.3.4.0 10.3.5.0 10.3.6.0 10.3.7.0

Yosemite
172.16.1.0 Maske: 255.255.255.0

Seville

Abbildung 5.5: Nicht zusammenhngendes Netzwerk 10.0.0.0

292

CCNA ICND2-Prfungshandbuch

Die Autosummierung verhindert das einwandfreie Funktionieren eines Netzwerkverbundes mit einem nicht zusammenhngenden Netzwerk. Listing 5.7 zeigt die Ergebnisse der Verwendung der Autosummierung im in Abbildung 5.5 gezeigten Netzwerk. In diesem Fall wurde das klassenbezogene Routing-Protokoll RIPv1 eingesetzt.
Listing 5.7: Routing-Tabelle von Albuquerque: Die Autosummierung verursacht Routing-Probleme mit dem nicht zusammenhngenden Netzwerk 10.0.0.0.
Albuquerque#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 3 subnets 172.16.1.0 is directly connected, Ethernet0/0 172.16.2.0 is directly connected, Serial0/0 172.16.3.0 is directly connected, Serial0/1 10.0.0.0/8 [120/1] via 172.16.3.3, 00:00:13, Serial0/1 [120/1] via 172.16.2.2, 00:00:04, Serial0/0

C C C R

Wie Listing 5.7 zeigt, verfgt Albuquerque nun ber zwei Routen in das Netzwerk 10.0.0.0/8: eine, die nach links in Richtung Yosemite weist, und eine zweite, die rechtsherum nach Seville fhrt. Doch statt Pakete, die an die Subnetze von Yosemite gerichtet sind, ber S0/0 zu versenden, schickt Albuquerque einige Pakete ber S0/1 an Seville! Albuquerque fhrt lediglich einen Lastausgleich des Paketversands ber zwei Routen durch, weil aus seiner Sicht die beiden Routen fr dasselbe Ziel das Gesamtnetzwerk 10.0.0.0 den gleichen Kostenwert aufweisen. Insofern knnen Anwendungen in diesem Netzwerk nicht mehr korrekt funktionieren. Die Lsung dieses Problems besteht im Abschalten der Autosummierung. Da klassenbezogene Routing-Protokolle immer die Autosummierung benutzen, verlangt diese Lsung eine Umstellung auf ein klassenloses RoutingProtokoll und die Deaktivierung der Autosummierung. Listing 5.8 zeigt den Netzwerkverbund aus Abbildung 5.5 und Listing 5.7, allerdings kommt hier das (klassenlose) EIGRP-Protokoll zum Einsatz, und die Autosummierung wurde deaktiviert.

Kapitel 5 VLSM und Routenzusammenfassung

293

Listing 5.8: Klassenloses Routing-Protokoll ohne Autosummierung zur Untersttzung nicht zusammenhngender Netzwerke
Albuquerque#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 3 subnets 172.16.1.0 is directly connected, Ethernet0/0 172.16.2.0 is directly connected, Serial0/0 172.16.3.0 is directly connected, Serial0/1 10.0.0.0/24 is subnetted, 8 subnets 10.2.1.0/24 [90/2172416] via 172.16.2.2, 00:00:01, 10.2.2.0/24 [90/2297856] via 172.16.2.2, 00:00:01, 10.2.3.0/24 [90/2297856] via 172.16.2.2, 00:00:01, 10.2.4.0/24 [90/2297856] via 172.16.2.2, 00:00:01, 10.3.5.0/24 [90/2297856] via 172.16.3.3, 00:00:29, 10.3.4.0/24 [90/2172416] via 172.16.3.3, 00:00:29, 10.3.7.0/24 [90/2297856] via 172.16.3.3, 00:00:29, 10.3.6.0/24 [90/2297856] via 172.16.3.3, 00:00:29,

C C C D D D D D D D D

Serial0/0 Serial0/0 Serial0/0 Serial0/0 Serial0/1 Serial0/1 Serial0/1 Serial0/1

Wird die Autosummierung sowohl auf Yosemite als auch auf Seville deaktiviert, dann gibt keiner der Router gegenber Albuquerque eine automatische Zusammenfassung des Netzwerks 10.0.0.0/8 bekannt. Stattdessen weist jeder Router die einzelnen bekannten Subnetze aus, das heit, Albuquerque kennt die vier von Yosemite abgehenden LAN-Subnetze ebenso wie die an Seville angeschlossenen LAN-Subnetze.

5.5.3

Untersttzung und Konfiguration der Autosummierung

Klassenbezogene Routing-Protokolle mssen die Autosummierung verwenden. Es gibt klassenlose Routing-Protokolle, die die Autosummierung untersttzen und auch standardmig verwenden, dazu jedoch mit dem RouterBefehl no autosummary die Mglichkeit der Abschaltung anbieten. Andere klassenlose Routing-Protokolle hingegen untersttzen die Autosummierung schlichtweg nicht. Unter diesen ist an erster Stelle OSPF (Open Shortest Path First) zu nennen. Tabelle 5.5 fasst die Fakten zur Autosummierung auf Cisco-Routern zusammen.

294

CCNA ICND2-Prfungshandbuch

Tabelle 5.5: Untersttzung und Default-Einstellung der Autosummierung


Wichtig!

Routing- Klassenlos? Untersttzt Protokoll Autosummierung? RIPv1 RIPv2 EIGRP OSPF Nein Ja Ja Ja Ja Ja Ja Nein

Verwendet die Autosummierung standardmig?* Ja Ja Ja

Autosummierung abschaltbar? Nein Ja Ja

* ab Cisco IOS Software IOS 12.4

Beachten Sie auerdem, dass sich die Autosummierung nur bei Routern auswirkt, an die Teile mehrerer klassenbezogener Netzwerke angeschlossen sind, nicht jedoch bei Routern, deren Schnittstellen alle mit demselben klassenbezogenen Netzwerk verbunden sind. In Abbildung 5.5 etwa erfordert die Lsung (wie in Listing 5.8 gezeigt) das Absetzen des EIGRP-Befehls no auto-summary auf den Routern Yosemite und Seville. Albuquerque hingegen, dessen Schnittstellen sich alle im selben Netzwerk (nmlich dem Klasse-BNetzwerk 172.16.0.0) befinden, wrde sein Verhalten in diesem Fall weder auf den Befehl auto-summary noch auf den Befehl no auto-summary ndern.

5.6
5.6.1
Wichtig!

Aufgaben zur Prfungsvorbereitung


Wiederholung

Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind in der Randspalte mit dem entsprechenden Symbol gekennzeichnet. Tabelle 5.6 listet diese Themen sowie die Seitennummern auf, auf denen die Themen zu finden sind.
Tabelle 5.6: Schlsselthemen in Kapitel 5
Element Tabelle 5.2 Liste Liste Liste Definition Beschreibung Liste der IP-Routing-Protokolle mit Angaben zu Klassenbezogenheit, VLSM-Support und Summierungsuntersttzung Strategie zur Ermittlung berlappender VLSM-Subnetze Strategie zur Auswahl eines neuen, nicht berlappenden Subnetzes Prozess zur Ermittlung der besten manuellen Summenroute Allgemeine Informationen zur Autosummierung Seite 272 273 278 286 289

Kapitel 5 VLSM und Routenzusammenfassung


Tabelle 5.6: Schlsselthemen in Kapitel 5 (Forts.)
Element Beschreibung

295

Seite 291 294

Definitionen Definitionen zu zusammenhngenden und nicht zusammenhngenden Netzwerken Tabelle 5.5 Liste der Routing-Protokolle und Angaben zur Autosummierung

5.6.2

Vervollstndigen Sie die Listen und Tabellen

Drucken Sie aus Anhang J, Tabellen zur bung (auf der CD vorhanden), den Abschnitt zu diesem Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls auf der CD enthaltene Anhang K, Lsungen zu den bungen, enthlt die vollstndigen Tabellen und Listen, mit denen Sie Ihre Lsungen berprfen knnen.

5.6.3

Wichtige Definitionen

Definieren Sie die folgenden Schlsselbegriffe aus diesem Kapitel und berprfen Sie Ihre Antworten anhand des Glossars: Autosummierung, klassenbezogenes Netzwerk, klassenbezogenes Routing-Protokoll, klassenloses Routing-Protokoll, nicht zusammenhngendes Netzwerk, berlappende Subnetze, Summenroute, VLSM, zusammenhngendes Netzwerk

5.6.4

Szenarien in Anhang F lesen

Anhang F, Weitere Szenarien, enthlt fnf detaillierte Szenarien, die Ihnen die Mglichkeit bieten, unterschiedliche Netzwerkentwrfe, Probleme und Befehlsausgaben zu analysieren, und Ihnen zeigen, wie Konzepte mehrerer unterschiedlicher Kapitel miteinander verwoben sind. Anhang F, Szenario 1, Teil A sowie das gesamte Szenario 5 erlauben Ihnen das ben und Entwickeln von Fertigkeiten in Verbindung mit VLSM.

5.6.5

Befehlsreferenz

Dieses Kapitel fhrt nur einen einzigen neuen Befehl ein, der zuvor noch nicht genannt wurde, nmlich den Router-Konfigurationsbefehl autosummary. Dieser Befehl aktiviert die Autosummierung. Wird die Option no vorangestellt, so wird die Autosummierung hingegen deaktiviert. Das Kapitel enthlt diese Befehlsreferenz lediglich, damit Sie diesen einen Befehl aus diesem Kapitel nicht vergessen.

Dieses Kapitel behandelt die folgenden Themen


Standard-ACLs Dieser Abschnitt erlutert, wie Standard-ACLs funktionieren und wie sie konfiguriert werden. Erweiterte ACLs In diesem Abschnitt wird die Komplexitt erweiterter IP-ACLs und ihre Konfiguration untersucht. Fortschritte beim Verwalten der ACL-Konfiguration Dieser Abschnitt behandelt die Details der beiden wichtigsten Erweiterungen, die die ACL-Konfiguration im Laufe der Jahre erfahren hat: ACLs mit Namen und Sequenznummern. Weitere ACL-spezifische Themen Dieser Abschnitt erlutert einige weitere ACL-Themen.

Kapitel 6
IP-ACLs
Sicherheit ist im Bereich der Netzwerktechnik gegenwrtig eines der wichtigsten Themen berhaupt. Zwar war Sicherheit schon immer wichtig, aber die explosionsartige Ausbreitung des Internets schafft immer neue Sicherheitsrisiken. Frher waren Unternehmen nicht stndig an ein globales Netzwerk angebunden ein Netzwerk, das subversive Subjekte einsetzen, um illegalen Zugriff auf die Firmennetze zu erhalten. Heute aber sind die meisten Firmen an das Internet angeschlossen und verdienen dank der Mglichkeiten des globalen Netzes eine Menge Geld. Diese Tatsache erhht nicht nur die Risiken, sondern verschlimmert auch die Folgen, wenn ein Einbruch in ein Unternehmensnetz erst einmal gelungen ist. Cisco-Router knnen als Komponenten einer guten allumfassenden Sicherheitsstrategie eingesetzt werden. Das fr den Einsatz dieser Strategie wichtigste Tool in der Cisco IOS-Software sind ACLs (Access Control Lists, Zugriffssteuerungslisten). ACLs definieren Regeln, mit denen sich verhindern lsst, dass Pakete mit bestimmten Eigenschaften das Netzwerk durchqueren. Wenn Sie etwa den Zugriff auf den Server mit den Gehaltsdaten auf Mitarbeiter der Buchhaltungsabteilung beschrnken oder auch Internethacker stoppen mssen, die Ihren Onlineshop-Server in die Knie zwingen wollen, so sind IOS-ACLs ein wesentliches Sicherheitswerkzeug, das als Bestandteil einer umfassenden Sicherheitsstrategie zum Einsatz kommt. Dieses Kapitel ist in Teil II dieses Buches enthalten, in dem es sich um das IPRouting dreht. Grund fr diese Platzierung des Kapitels ist die Tatsache, dass ACLs in den Aufgaben der CCNA-Prfung in allererster Linie zur Filterung von IP-Paketen eingesetzt werden. Whrend also die Kapitel 4 und 5 verschiedene Funktionalitten beschrieben, die mit der bertragung von Paketen im Rahmen des IP-Routing-Prozesses in Zusammenhang stehen, untersucht dieses Kapitel die ACLs, mit denen man verhindern kann, dass ausgewhlte Pakete berhaupt bertragen werden.

298

CCNA ICND2-Prfungshandbuch

6.1

berprfen Sie Ihren Wissensstand

Dieser Abschnitt gestattet es Ihnen zu ermitteln, ob Sie das gesamte Kapitel lesen mssen. Wenn Sie maximal eine der folgenden zehn Fragen zur Selbsteinschtzung nicht oder falsch beantworten, knnen Sie mit dem Abschnitt Aufgaben zur Prfungsvorbereitung fortfahren. Tabelle 6.1 listet die wichtigsten berschriften dieses Kapitels und die Nummern der Fragen auf, die sich auf die betreffenden Abschnitte beziehen. Auf diese Weise knnen Sie Ihr Wissen in den jeweiligen Bereichen selbst einschtzen. Die Antworten zu den Fragen in diesem Abschnitt finden Sie in Anhang A.
Tabelle 6.1: Zuordnung der folgenden Fragen zu den einzelnen Themengebieten
Grundlagenthema Standard-ACLs Erweiterte ACLs Fortschritte bei der ACL-Konfiguration Weitere ACL-spezifische Themen Fragen 1 bis 3 4 bis 6 7 und 8 9 und 10

1. Barney ist ein Host mit der IP-Adresse 10.1.1.1 im Subnetz 10.1.1.0/24. Welche der folgenden Manahmen lassen sich mit einer Standard-ACL konfigurieren? a) berprfen auf die exakte Absender-IP-Adresse hin b) berprfen auf die IP-Adressen 10.1.1.1 bis 10.1.1.4 hin mit nur einem access-list-Befehl ohne berprfung weiterer IP-Adressen c) berprfen aller IP-Adressen in Barneys Subnetz mit nur einem access-list-Befehl ohne berprfung weiterer IP-Adressen d) berprfen der Ziel-IP-Adresse des Pakets 2. Welche der folgenden Wildcard-Masken ist am geeignetsten fr das berprfen aller IP-Pakete im Subnetz 10.1.128.0 mit der Subnetzmaske 255.255.255.0? a) 0.0.0.0 b) 0.0.0.31 c) 0.0.0.240 d) 0.0.0.255 e) 0.0.15.0 f) 0.0.248.255

Kapitel 6 IP-ACLs

299

3. Welche der folgenden Wildcard-Masken ist am geeignetsten fr das berprfen aller IP-Pakete im Subnetz 10.1.128.0 mit der Subnetzmaske 255.255.240.0? a) 0.0.0.0 b) 0.0.0.31 c) 0.0.0.240 d) 0.0.0.255 e) 0.0.15.255 f) 0.0.248.255 4. Welches der folgenden Felder kann basierend auf einer erweiterten ACL nicht verglichen werden? a) Protokoll b) Absender-IP-Adresse c) Ziel-IP-Adresse d) TOS-Byte e) URL f) Dateiname fr FTP-bertragungen 5. Welcher der folgenden access-list-Befehle lsst den Versand von Daten vom Host 10.1.1.1 an alle Webserver zu, deren IP-Adressen mit 172.16.5 beginnen? a) access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www b) access-list 1951 permit ip host 10.1.1.1 172.16.5.0 0.0.0.255 eq www c) access-list 2523 permit ip host 10.1.1.1 eq www 172.16.5.0 0.0.0.255 d) access-list 2523 permit tcp host 10.1.1.1 eq www 172.16.5.0 0.0.0.255 e) access-list 2523 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www 6. Welcher der folgenden access-list-Befehle lsst Daten zu, die von Webservern, deren IP-Adressen mit 172.16.5 beginnen, an alle mglichen Webclients gesendet werden? a) access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255 eq www b) access-list 1951 permit ip host 10.1.1.1 172.16.5.0 0.0.0.255 eq www c) access-list 2523 permit tcp any eq www 172.16.5.0 0.0.0.255 d) access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq www 172.16.5.0
0.0.0.255

e) access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq www any

300

CCNA ICND2-Prfungshandbuch

7. Welches der folgenden Felder kann mithilfe einer erweiterten ACL mit Namen, nicht aber mit einer erweiterten nummerierten ACL verglichen werden? a) Protokoll b) Absender-IP-Adresse c) Ziel-IP-Adresse d) TOS-Byte e) Keine der vorgeschlagenen Antworten trifft zu. 8. Auf einem Router unter IOS 12.3 muss der Netzwerktechniker die zweite Zeile in der ACL 101 lschen, in der gegenwrtig vier Befehle konfiguriert sind. Welche der folgenden Optionen knnte er verwenden? a) Er lscht die gesamte ACL und konfiguriert die drei Anweisungen neu, die in der ACL verbleiben sollen. b) Er lscht mit dem Befehl no access-list... eine Zeile aus der ACL. c) Er wechselt in den ACL-Konfigurationsmodus der ACL und lscht dann lediglich die zweite Zeile basierend auf ihrer Sequenznummer. d) Er lscht im ACL-Konfigurationsmodus die letzten drei Zeilen aus der ACL und fgt dann die letzten beiden Anweisungen wieder zur ACL hinzu. 9. Welche allgemeine Richtlinie sollte man beim Implementieren erweiterter ACLs beachten? a) Sofern mglich, sollte die gesamte Filterung an der Ausgabe erfolgen. b) Allgemeiner formulierte Anweisungen sollten weiter oben in der ACL aufgefhrt werden. c) Pakete sollten mglichst nah an der Quelle gefiltert werden. d) Die ACL-Befehle sollten aufsteigend nach ihrer Absender-IP-Adresse sortiert werden, um die Leistung zu optimieren. 10. Welches der folgenden Werkzeuge verlangt vom Benutzer die Herstellung einer Telnet-Verbindung mit einem Router, um Zugriff auf die Host auf der anderen Seite des Routers zu erhalten? a) ACLs mit Namen b) Reflexive ACLs c) Dynamische ACLs d) Zeitbasierte ACLs

Kapitel 6 IP-ACLs

301

6.2

Grundlagenthemen

Cisco IOS untersttzt IP-ACLs, seitdem die ersten kommerziellen CiscoRouter in den spten 1980er-Jahren auf den Markt kamen. Anfangs kennzeichnete das IOS diese ACLs numerisch. Spter kam als Bestandteil von IOS 11.2 die Mglichkeit hinzu, ACLs mit Namen zu versehen. Solche ACLs mit Namen bieten verglichen mit nummerierten ACLs kleinere Vorteile, filtern allerdings letztendlich dieselben Pakete auf Basis derselben Regeln. Mit IOS 12.3 schlielich wurde die ACL-Untersttzung durch Cisco erneut optimiert. Dies betrifft insbesondere die Art und Weise, wie Netzwerktechniker vorhandene ACLs editieren knnen. Dieser letzte Schritt in der Entwicklung von ACLs sorgt dafr, dass nummerierte ACLs und ACLs mit Namen exakt die gleichen Funktionen untersttzen der einzige Unterschied besteht nun lediglich darin, dass bei der einen Variante eine Zahl, bei der anderen dagegen ein Name zur Kennzeichnung verwendet wird. Aufgrund der historischen Untersttzung fr ACLs behandeln die CCNAPrfungen auch heute noch eine Menge an Informationen und Konfigurationsbefehlen, die bereits vor fast 20 Jahren auf Cisco-Routern zum Einsatz kamen. Wir werden in diesem Kapitel in erster Linie IP-ACLs genauer gesagt, nummerierte IP-ACLs erlutern und dabei dieselben Befehle und die gleiche IOS-Syntax benutzen, die im IOS bereits seit langem vorhanden ist. Beginnen werden wir mit einer Beschreibung der einfachsten Arten nummerierter ACLs: Standard-ACLs. Im zweiten groen Abschnitt untersuchen wir dann die komplexeren erweiterten ACLs, mit denen sich wesentlich mehr Felder in einem IP-Paket berprfen lassen. Der darauf folgende Abschnitt beschreibt die fortgeschrittenen ACLs im IOS: die Einfhrung von Namen fr ACLs in IOS 11.2 und die spter in IOS 12.3 ergnzten ACLSequenznummern und Bearbeitungsmglichkeiten. Abgeschlossen wird das Kapitel mit verschiedenen weiteren ACL-Themen.

6.3

Standard-ACLs

IP-ACLs sorgen dafr, dass ein Router bestimmte Pakete basierend auf Kriterien, die vom Netzwerktechniker definiert wurden, verwirft. Der Zweck dieser Filter besteht darin, unerwnschten Datenverkehr im Netzwerk zu verhindern. Das knnen Daten sein, die Hacker in das Netzwerk einschleusen wollen, aber auch solche von Mitarbeitern, die Systeme benutzen wollen, auf die sie keinen Zugriff haben drfen. ACLs sollten grundstzlich Bestandteil der Sicherheitsrichtlinie einer Organisation sein. Auerdem knnen ACLs auch benutzt werden, um Routing-Updates zu filtern, die Priorisierung von Paketen zu realisieren, Pakete fr das VPN-

302

CCNA ICND2-Prfungshandbuch

Tunneling auszuwhlen und bestimmte QoS-Funktionalitten zu implementieren. In Kapitel 16, NAT, werden Sie auerdem erfahren, wie ACLs zur Konfiguration der Netzadressbersetzung (Network Address Translation, NAT) eingesetzt werden. Sie knnen sich also durchaus vorstellen, dass Sie im Laufe Ihres Berufsweges in Cisco-Zertifizierungsprfungen immer wieder auf ACLs treffen werden. Dieses Kapitel behandelt die beiden Hauptkategorien der IP-ACLs in IOS: Standard-ACLs und erweiterte ACLs. Standard-ACLs basieren auf einer einfacheren Logik, whrend erweiterte ACLs komplexere Bedingungen ermglichen. Wir werden also in diesem Kapitel zunchst die Standard-ACLs und danach die erweiterten ACLs behandeln. Abschnitte zu verschiedenen Themen in Zusammenhang mit beiden ACL-Typen runden das Kapitel ab.

6.3.1

Konzepte von Standard-ACLs

Fr jede ACL, die zur Filterung von IP-Paketen herangezogen wird, muss der Netzwerktechniker zwei grundstzliche Entscheidungen treffen: Welche Pakete sollen gefiltert werden, und wo im Netzwerk soll die ACL platziert werden? Abbildung 6.1 soll als Beispiel dienen. Stellen Sie sich vor, dass Bob anders als Larry nicht auf Server1 zugreifen darf.
Server1
SW2
S0 S0

Larry

R2
S1

E0

SW12 172.16.2.10

172.16.1.100

Server2
SW3 172.16.1.102

SW1

E0

R1
S1 S1 S0

Bob

R3

E0

SW13 172.16.3.10

Jimmy

Jerry

172.16.3.8 172.16.3.9

Abbildung 6.1: Positionen im Netzwerk, an denen die ACL-Logik greifen kann

Die Filter knnten auf jedem der drei Router und dort auf jeder Schnittstelle konfiguriert werden. Die gepunkteten Linien mit den Pfeilen in der Abbildung deuten die geeignetsten Stellen an, an denen eine solche Filterlogik in einer ACL angewendet werden knnte. Da lediglich von Bob kommende Daten gefiltert werden mssen, und das Ziel darin besteht, den Zugriff auf Server1 zu unterbinden, sollte die ACL entweder auf R1 oder auf R3 implementiert werden. R2 wre hierfr ungeeignet, weil Daten, die Bob an Server1 schicken sollte, R2 gar nicht erst passieren wrden. Wir wollen davon ausgehen, dass die ACL auf R1 implementiert wird.

Kapitel 6 IP-ACLs

303

Die Cisco IOS-Software wendet die Filterlogik einer ACL dann an, wenn das Paket an einer Schnittstelle eintrifft oder sie verlsst. Mit anderen Worten wendet das IOS eine ACL auf eine Schnittstelle an und legt dabei explizit fest, ob eingehender oder ausgehender Datenverkehr behandelt werden soll. Nachdem Sie den Router ausgewhlt haben, auf dem Sie die ACL implementieren wollen, mssen Sie festlegen, fr welche Schnittstelle und welche Datenbewegungen (eingehend oder ausgehend) diese gelten soll. Stellen wir uns etwa vor, Sie wollen Pakete filtern, die Bob an Server1 sendet. Abbildung 6.2 zeigt die Optionen fr die Paketfilterung.
Router R1
Wichtig!

Zulassen

RoutingLogik

Ausgehende ACL
Verweigern

Zulassen

E0

S1

Eingehende ACL

Verweigern

Datenmlleimer

IP-Paket

Abbildung 6.2: Interne Verarbeitung der Paketfilterung auf R1

Die Filterlogik kann Pakete, die bei S1 eintreffen, und solche, die ber E0 den Router verlassen, darauf hin prfen, ob sie von Bob stammen und an Server1 gesendet wurden. Generell knnen Sie Pakete filtern, indem Sie ACLs fr ein- und ausgehende Pakete auf allen Schnittstellen erstellen und aktivieren. Die Cisco-ACLs weisen einige besondere Eigenschaften auf: Pakete knnen beim Eintreffen an der Schnittstelle vor der Routing-Entscheidung gefiltert werden. Pakete knnen vor Verlassen der Schnittstelle nach der Routing-Entscheidung gefiltert werden.
deny (verweigern) heit der in der Cisco IOS-Software verwendete

Begriff, der angibt, dass das Paket ausgefiltert wird.

304

CCNA ICND2-Prfungshandbuch

permit (zulassen) heit der in der Cisco IOS-Software verwendete Begriff, der angibt, dass das Paket nicht ausgefiltert wird.

Die Filterlogik wird in der ACL konfiguriert. Am Ende jeder ACL befindet sich eine implizite deny all-Anweisung. Falls ein Paket also keiner der Anweisungen in unserer ACL entspricht, wird es blockiert. Sie knnen nun zum Beispiel eine ACL auf R1 erstellen und diese fr die Schnittstelle S1 aktivieren. Die ACL sucht nachfolgend nach Paketen, die von Bob stammen. Sie wre also fr eingehende Pakete aktiviert, weil Pakete von Bob in diesem Netzwerk ber S1 empfangen werden und Pakete an Bob den Router ber S1 verlassen. Die Logik einer ACL umfasst zwei wesentliche Schritte: Vergleich und Aktion. Die Vergleichslogik untersucht jedes Paket und stellt fest, ob es der access-list-Anweisung entspricht. Fr den Vergleich auf Pakete, die von Bob stammen, wrde beispielsweise dessen IP-Adresse herangezogen werden. IP-ACLs weisen den Router an, eine von zwei Aktionen durchzufhren, falls eine bereinstimmung festgestellt wurde: Zulassen oder Verweigern. Verweigern wrde bedeuten, dass das Paket verworfen wird, whrend es bei Zulassen seinen Weg fortsetzen darf. Insofern msste eine ACL, die verhindert, dass Daten von Bob zum Server gelangen, wie folgt formuliert werden: Suche nach Paketen mit Bobs Absender-IP-Adresse und der Ziel-IPAdresse von Server1. Verwerfe solche Pakete. Andere Pakete werden nicht verworfen. Es wird Sie nicht berraschen, dass IP-ACLs im wirklichen Leben wesentlich komplexer sein knnen. Sogar bei einer kurzen Liste von Vergleichskriterien knnen komplizierte ACLs fr eine Vielzahl von Schnittstellen auf einer Vielzahl von Routern entstehen. Ich habe sogar schon von sehr groen Firmennetzwerken gehrt, in denen einige Vollzeitmitarbeiter den ganzen Tag lang nichts anders zu tun haben, als ACLs zu planen und zu implementieren! Cisco nennt seine Paketfilterfunktionen auch deswegen Access-Listen, weil die Logik mithilfe mehrerer Konfigurationsbefehle erstellt wird, die zu ein und derselben Liste gehren. Wenn eine ACL ber mehrere Eintrge verfgt, durchsucht das IOS diese Liste von oben nach unten, bis der erste passende Eintrag gefunden wird. Dieser Eintrag bestimmt dann auch, welche Aktion durchgefhrt wird. Die beiden rautenfrmigen Verzweigungen in Abbildung 6.2 zeigen die Anwendung der ACL-Logik.

Kapitel 6 IP-ACLs

305

Die Logik, die das IOS bei ACLs mit mehreren Eintrgen verwendet, lsst sich wie folgt zusammenfassen: 1. Die Parameter der access-list-Anweisung werden mit dem Paket verglichen. 2. Liegt eine bereinstimmung vor, dann wird die in der access-list-Anweisung definierte Aktion (Zulassen oder Verweigern) ausgefhrt. 3. Liegt in Schritt 2 keine bereinstimmung vor, dann werden die Schritte 1 und 2 fr jede nachfolgende Anweisung in der ACL wiederholt, bis eine bereinstimmung gefunden wird. 4. Wird in der gesamten Liste keine bereinstimmung gefunden, dann wird die Aktion deny ausgefhrt.
Wichtig!

Wildcard-Masken
IOS-ACLs vergleichen Pakete durch berprfung der IP-, TCP- und UDPHeader im Paket. Erweiterte ACLs knnen die Absender- und Ziel-IP-Adressen, die Port-Nummern von Absender und Empfnger und diverse andere Felder vergleichen. Standard-ACLs hingegen untersuchen lediglich die Absender-IP-Adressen. Unabhngig davon, ob Sie Standard- oder erweiterte ACLs einsetzen, knnen Sie den Router anweisen, den Vergleich auf die gesamte IP-Adresse oder nur auf einen Teil davon anzuwenden. Wenn Sie etwa unterbinden wollen, dass Bob Pakete an Server1 bertrgt, wrden in der ACL die vollstndigen IP-Adressen von Bob und Server1 berprft. Was aber msste geschehen, damit alle Hosts aus Bobs Subnetz keinen Zugriff mehr auf Server1 erhalten? Weil bei allen Hosts in Bobs Subnetz die ersten drei Oktette identisch sind, msste die ACL lediglich diese Oktette berprfen, um alle Pakete erfolgreich vergleichen zu knnen. Hierzu gengt ein einzelner access-listBefehl. Wildcard-Masken definieren den Anteil der IP-Adresse, der untersucht werden soll. Wie Sie im nchsten Abschnitt dieses Kapitels sehen werden, knnen Sie beim Festlegen der ACL-Anweisungen in Verbindung mit der IPAdresse auch eine Wildcard-Maske definieren. Die Wildcard-Maske sagt dem Router, welcher Teil der IP-Adresse in der Konfigurationsanweisung und Paket-Header miteinander verglichen werden soll. Nehmen wir etwa an, eine Maske legt fest, dass das gesamte Paket berprft werden soll, whrend eine weitere Maske angibt, dass sich die Untersuchung auf die ersten drei Oktette beschrnkt. (Dies knnten Sie etwa tun, um alle IP-Hosts im selben Subnetz zu vergleichen, falls Sie die Subnetzmaske

306

CCNA ICND2-Prfungshandbuch

255.255.255.0 verwenden.) Zur Durchfhrung dieses Vergleichs verwenden Cisco-ACLs Wildcard-Masken. Wildcard-Masken sehen hnlich wie Subnetzmasken aus, sind aber mit diesen nicht identisch. Sie stellen zwar wie Subnetzmasken auch eine 32-BitZahl dar, doch die Nullbits einer Wildcard-Maske signalisieren dem Router, dass die entsprechenden Bits in der Adresse verglichen werden sollen. Binre Einsen in der Wildcard-Maske hingegen sorgen dafr, dass die entsprechenden Stellen in der Adresse nicht verglichen werden. Damit Sie einen Eindruck davon gewinnen, welches Prinzip hinter einer Wildcard-Maske steht, gibt Tabelle 6.2 einige der gngigsten Wildcard-Masken und ihre jeweilige Bedeutung an.
Tabelle 6.2: Wildcard-Masken (Beispiele)
Wichtig!

Wildcard-Maske 0.0.0.0

Binrversion der Maske 00000000.00000000.00000000.00000000

Beschreibung Die gesamte IP-Adresse muss bereinstimmen. Nur die ersten 24 Bits mssen bereinstimmen. Nur die ersten 16 Bits mssen bereinstimmen. Nur die ersten 8 Bits mssen bereinstimmen. bereinstimmung mit allen denkbaren Adressen. Nur die ersten 20 Bits mssen bereinstimmen. Nur die ersten 22 Bits mssen bereinstimmen.

0.0.0.255

00000000.00000000.00000000.11111111

0.0.255.255

00000000.00000000.11111111.11111111

0.255.255.255

00000000.11111111.11111111.11111111

255.255.255.255 11111111.11111111.11111111.11111111

0.0.15.255

00000000.00000000.00001111.11111111

0.0.3.255

00000000.00000000.00000011.11111111

Die ersten Beispiele zeigen typische Einsatzformen von Wildcard-Masken. Wie Sie sehen, handelt es sich nicht um eine Subnetzmaske. Die Wildcard 0.0.0.0 bedeutet, dass die gesamte IP-Adresse berprft wird und identisch sein muss, damit eine bereinstimmung erkannt wird. 0.0.0.255 bedeutet,

Kapitel 6 IP-ACLs

307

dass das letzte Oktett nicht beachtet wird, whrend die ersten drei Oktette geprft werden mssen usw. Allgemeiner formuliert hat die WildcardMaske folgende Bedeutung: Wird eine Bit-Position der Wildcard durch eine binre Null reprsentiert, so bedeutet dies, dass die ACL die entsprechende Bit-Position in der IP-Adresse vergleicht und sicherstellt, dass sie mit derselben Bit-Position in der Adresse identisch ist, wie diese in der access-listAnweisung konfiguriert wurde. Bit-Positionen, die durch binre Einsen dargestellt werden, spielen fr den Vergleich keine Rolle. Sie gelten immer als bereinstimmend. Die letzten beiden Zeilen von Tabelle 6.2 zeigen zwei sinnvolle, doch nicht unbedingt sofort verstndliche Wildcard-Masken. 0.0.15.255 hat in Binrform zwanzig Nullen gefolgt von zwlf Einsen. Also mssen nur die ersten 20 Bits bereinstimmen. hnlich bedeutet 0.0.3.255, dass die ersten 22 Bits auf bereinstimmung hin geprft werden mssen. Warum sind diese Masken sinnvoll? Nun, wenn die Subnetzmaske 255.255.240.0 lautet, und Sie eine bereinstimmung fr alle Hosts im selben Subnetz suchen, bedeutet die Wildcard 0.0.15.255, dass alle Netzwerk- und Subnetzbits bereinstimmen mssen, whrend die Hostbits generell als bereinstimmend betrachtet werden. hnlich fhrt, wenn Sie alle Hosts in einem Subnetz mit der Subnetzmaske 255.255.252.0 ausfiltern wollen, die Wildcard-Maske 0.0.3.255 den beabsichtigten Vergleich der Netzwerk- und Subnetzbits aus. Generell gilt: Falls Sie ein Wildcard-Maske bentigen, die eine bereinstimmung fr alle Hosts in einem Subnetz erzielt, so invertieren Sie einfach die Subnetzmaske, und schon erhalten Sie die korrekte Wildcard-Maske.

Eine schnellere Alternative zur Interpretation von Wildcard-Masken


Standard-ACLs (bei denen nur die Absender-IP-Adresse geprft wird) wie auch erweiterte ACLs (bei denen Absender- und Empfngeradresse verifiziert werden) lassen sich so konfigurieren, dass basierend auf der WildcardMaske die gesamte IP-Adresse oder nur ein Teil davon untersucht wird. Allerdings kann insbesondere in einer Prfung das Arbeiten mit Masken im Binrformat langwierig und aufwendig sein, sofern Sie die Konvertierungen zwischen Dezimal- und Binrformat nicht aus dem Effeff beherrschen. An dieser Stelle wollen wir eine einfachere Methode der Arbeit mit WildcardMasken vorstellen, die wenn Sie mit der Subnetzbildung zurechtkommen gut funktioniert.

308

CCNA ICND2-Prfungshandbuch

In vielen Fllen muss eine ACL alle Hosts in einem bestimmten Subnetz vergleichen. Hierzu knnen Sie die folgende Abkrzung verwenden:
Wichtig!

Sie geben die Subnetzadresse als Adresswert im Befehl access-list an. Sie verwenden eine Wildcard-Maske, die aus der Subtraktion der Subnetzmaske von 255.255.255.255 resultiert. Beim Subnetz 172.16.8.0 255.255.252.0 etwa verwenden Sie die Subnetzadresse (172.16.8.0) als Parameter address und ermitteln die WildcardMaske dann wie folgt:
255.255.255.255 255.255.252.0 0. 0. 3.255

Es gibt auch Prfungsaufgaben, in denen Sie nicht dazu aufgefordert werden, eine ACL zu ermitteln, die konfiguriert werden muss; vielmehr sollen Sie einige angegebene access-list-Befehle interpretieren. In der Regel sind in solchen Fragen vorkonfigurierte ACL-Anweisungen aufgefhrt, oder Sie zeigen den Inhalt einer ACL im Router-Simulator an. Sie mssen dann entscheiden, welche Anweisung ein gegebenes Paket filtert. Zu diesem Zweck mssen Sie den IP-Adressbereich ermitteln, der sich aus einer bestimmten Adresse und Wildcard-Maske ergibt. Wenn Sie die mathematischen Vorgnge der Subnetzbildung mit allen Dezimalverkrzungen beherrschen, knnen Sie unter Umgehung der Binrrechnung eine andere Verkrzung einsetzen. Um die vorhandenen Adress-Wildcard-Paare in den einzelnen ACL-Befehlen zu analysieren, gehen Sie wie folgt vor:
Wichtig!

1. Verwenden Sie die im Befehl access-list angegebene Adresse so, als handele es sich um eine Subnetzadresse. 2. Verwenden Sie die aus der Subtraktion der Wildcard-Maske von 255.255.255.255 resultierende Subnetzmaske. 3. Behandeln Sie die Werte der ersten beiden Schritte als Subnetzadresse und Subnetzmaske und suchen Sie fr dieses Subnetz die Broadcast-Adresse. Die ACL gilt dann fr den Adressbereich zwischen der Subnetzadresse und der Broadcast-Adresse (jeweils einschlielich). Der durch diesen Vorgang ermittelte Adressbereich entspricht dem Bereich der Adressen, die von der ACL geprft werden. Wenn Sie den Adressbereich eines Subnetzes also bereits schnell und problemlos feststellen knnen, ermitteln Sie die Antwort auf eine Prfungsaufgabe unter Umstnden einfacher, indem Sie die Berechnung der ACL auf diese Weise ndern. Bei dem

Kapitel 6 IP-ACLs

309

Befehl access-list 1 permit 172.16.200.0 0.0.7.255 etwa wrden Sie 172.16.200.0 sicher zunchst als Subnetzadresse erkennen. Sie knnen auf dieser Basis dann die dazugehrige Subnetzmaske 255.255.248.0 wie folgt berechnen:
255.255.255.255 0. 0. 7.255 255.255.248.0

Schlielich knnen Sie mit einem von Ihnen bevorzugten Rechenweg zur Subnetzermittlung bestimmen, dass die Broadcast-Adresse dieses Subnetzes 172.16.207.255 lautet. Der Adressbereich der ACL-Anweisung erstreckt sich mithin von 172.16.200.0 bis 172.16.207.255.

ANMERKUNG
Szenario 3 in Anhang F (auf der beiliegenden CD-ROM) bietet Ihnen die Mglichkeit, eine Wildcard-Maske auszuwhlen, die den Hosts in einem bestimmten Subnetz entspricht.

6.3.2

Standard-ACLs konfigurieren

Die Konfiguration einer ACL ist meist einfacher als die Interpretation der Aktionen dieser ACL. Aus diesem Grund wird in diesem Abschnitt zunchst die Konfiguration einer ACL dargestellt. Nachfolgend zeigen wir anhand einiger Beispiele die Konfiguration und Wirkung dieser ACLs. Die allgemeine Syntax zur Konfiguration von Standard-ACLs lautet:
access-list access-list-number {deny | permit} source [source-wildcard]

Eine Standard-ACL nutzt eine Anzahl von access-list-Befehlen, die dieselbe Nummer aufweisen. access-list-Befehle mit derselben Nummer werden als zur selben Liste gehrend betrachtet. Die Befehle werden in derselben Reihenfolge aufgefhrt, in der sie zur Konfiguration hinzugefgt wurden. Jeder access-list-Befehl kann einen Bereich von Absender-IP-Adressen vergleichen. Wird eine bereinstimmung festgestellt, dann lsst die ACL das Paket entweder seinen Weg fortsetzen (Aktion permit) oder verwirft es (Aktion deny). Jede Standard-ACL kann die gesamte Absender-IP-Adresse eines Pakets oder nur einen Teil davon vergleichen. Beachten Sie, dass der Nummernbereich fr Standard-ACLs bei 1 bis 99 sowie 1300 bis 1999 liegt. Die folgende Liste beschreibt den empfohlenen Konfigurationsvorgang. Fr die Prfung mssen Sie sich die einzelnen Schritte des Vorgangs nicht merken; er ist an dieser Stelle lediglich als Gedchtnissttze aufgefhrt.

310

CCNA ICND2-Prfungshandbuch

Wichtig!

1. Planen Sie die Position (Router und Schnittstelle) sowie die Richtung (eingehend oder ausgehend) fr die Schnittstelle: a) Standard-ACLs sollten mglichst nah am Empfnger der Pakete platziert werden, damit nicht versehentlich Pakete verworfen werden, die eigentlich weitergeleitet werden sollten. b) Da Standard-ACLs nur die Absender-IP-Adresse eines Pakets berprfen, geben Sie diese Absender-IP-Adresse von Paketen an, die sich in der Richtung bewegen, die die ACL untersucht. 2. Konfigurieren Sie einen oder mehrere globale access-list-Befehle zur Erstellung der ACL. Beachten Sie dabei Folgendes: a) Die Liste wird von oben nach unten abgearbeitet. Bei der ersten bereinstimmung wird die Abarbeitung beendet. Das bedeutet, dass, wenn ein Paket einer der access-list-Anweisungen entspricht, die Suche vorbei ist und zwar auch dann, wenn das Paket spter folgenden Anweisungen ebenfalls entsprechen sollte. b) Entspricht ein Paket keinem der access-list-Befehle, so steht am Ende die Standardaktion deny, das heit, das Paket wird verworfen. 3. Aktivieren Sie die ACL auf der gewhlten Router-Schnittstelle in der vorgesehenen Richtung. Hierzu verwenden Sie den Schnittstellenbefehl ip access-group number {in | out}. Nun wollen wir zwei Beispiele fr Standard-ACLs untersuchen.

Beispiel 1 zu den Standard-ACLs


In Listing 6.1 wird versucht, von Bob kommende und an Server1 gerichtete Daten zu blockieren. Wie Abbildung 6.1 zeigt, darf Bob nicht auf Server1 zugreifen. Im Listing wird eine ACL fr alle Pakete aktiviert, die den Router R1 ber die Schnittstelle Ethernet0 verlassen. Die ACL berprft die Absenderadresse im Paket darauf hin, ob sie mit Bobs IP-Adresse identisch ist. Beachten Sie, dass die access-list-Befehle sich unten im Listing befinden, weil auch der Befehl show running-config sie gegen Ende der Ausgabe im Anschluss an die Schnittstellenkonfigurationsbefehle auflistet.
Listing 6.1: Standard-ACL auf R1, mit der verhindert wird, dass Bob den Server1 erreicht
interface Ethernet0 ip address 172.16.1.1 255.255.255.0 ip access-group 1 out ! access-list 1 remark stop all traffic whose source IP is Bob access-list 1 deny 172.16.3.10 0.0.0.0 access-list 1 permit 0.0.0.0 255.255.255.255

Kapitel 6 IP-ACLs

311

Betrachten wir zunchst die grundlegende Syntax der Befehle. StandardACLs verwenden eine ACL-Nummer im Bereich zwischen 1 und 99 oder zwischen 1300 und 1999. In diesem Listing verwenden wird die ACL-Nummer 1. (Dafr gibt es allerdings keinen besonderen Grund: Solange sich die ACL-Nummer im korrekten Bereich befindet, besteht absolut kein Unterschied zwischen den einzelnen Nummern. Anders gesagt: Liste 1 ist nicht besser oder schlechter als Liste 99.) Die access-list-Befehle, mit denen die Vergleichs- und Aktionslogik definiert wird, sind globale Konfigurationsbefehle. Um die ACL fr eine Schnittstelle zu aktivieren und die Flussrichtung der Pakete festzulegen, auf die die ACL angewendet wird, wird der Befehl ip access-group verwendet. In diesem Fall wird ACL 1 auf Ethernet0 fr Pakete aktiviert, die den Router ber die Schnittstelle verlassen. Basierend auf der Vergleichslogik des Befehls access-list 1 deny 172.16.3.10 0.0.0.0 verhindert die ACL 1, dass Pakete, die von Bob gesendet wurden, die Ethernet-Schnittstelle von R1 verlassen. Die Wildcard-Maske 0.0.0.0 bedeutet alle 32 Bits vergleichen, das heit, nur solche Pakete, deren IP-Adresse exakt 172.16.3.10 lautet, rufen eine bereinstimmung hervor und werden verworfen. Der Befehl access-list 1 permit 0.0.0.0 255.255.255.255 also die letzte Anweisung in der Liste stimmt mit allen Paketen berein, weil die Wildcard-Maske 255.255.255.255 per Definition bereinstimmend fr alle 32 Bits bedeutet. Die Anweisung trifft damit auf alle Absender-IP-Adressen zu. Diese Pakete werden dann zugelassen. Beachten Sie schlielich, dass der Netzwerktechniker auch einen Befehl
access-list 1 remark zur ACL hinzugefgt hat. Dieser Befehl gestattet das

Hinzufgen eines Kommentartextes oder einer Anmerkung, damit sich gegebenenfalls der Zweck der ACL nachvollziehen lsst. Die Anmerkung erscheint lediglich in der Konfiguration, nicht aber in der show-Ausgabe. Zwar handelt es sich hier um ein scheinbar einfaches Beispiel, doch in diesem Fall sorgt ACL 1 auch dafr, dass Bobs Pakete an Server2 ebenfalls nicht ausgeliefert werden. Bei der in Abbildung 6.1 gezeigten Topologie ist es einer ausgehenden Standard-ACL auf der Schnittstelle E0 von R1 nicht mglich, den Zugriff von Bob auf Server1 zu unterbinden und den auf Server2 gleichzeitig zuzulassen. Hierzu wrde eine erweiterte ACL bentigt, die sowohl Absender- als auch Ziel-IP-Adresse berprfen kann. Interessanterweise ndert, wenn die Befehle in Listing 6.1 im Konfigurationsmodus eingegeben werden, das IOS die Syntax einer Reihe von Befehlen. Die Ausgabe des Befehls show running-config in Listing 6.2 zeigt, was genau durch das IOS in der Konfigurationsdatei ablegt wurde.

312

CCNA ICND2-Prfungshandbuch

Listing 6.2: Modifizierte Standard-ACL, mit der verhindert wird, dass Bob Server1 erreicht
interface Ethernet0 ip address 172.16.1.1 255.255.255.0 ip access-group 1 out access-list 1 remark stop all traffic whose source IP is Bob access-list 1 deny 0000000000000000 host 172.16.3.10 access-list 1 permit 000 any

Die Befehle in Listing 6.1 werden durch drei Gegebenheiten angepasst. Das Cisco IOS untersttzt sowohl die ltere als auch die neuere Form zur Konfiguration bestimmter Parameter. Listing 6.1 zeigt die ltere Darstellung. Der Router wechselt aber intern zur quivalente Konfiguration des neueren Stils, wie sie Listing 6.2 zeigt. Zunchst bedeutet die Wildcard-Maske 0.0.0.0 tatschlich, dass der Router auf genau die angegebene Host-IP-Adresse hin prfen soll. Die neuere Form der Konfiguration verwendet vor der betreffenden IP-Adresse das Schlsselwort host. Die zweite nderung der Konfiguration im Vergleich zum alten Stil betrifft die Verwendung der WildcardMaske 255.255.255.255 mit der Bedeutung alles stimmt. Die neue Form verwendet das Schlsselwort any anstelle der IP-Adresse und der WildcardMaske 255.255.255.255. Hierbei bedeutet any einfach, dass jede IP-Adresse passt.

Beispiel 2 zu den Standard-ACLs


Das zweite Beispiel zu Standard-ACLs veranschaulicht eine Reihe weiterer ACL-Aspekte. Abbildung 6.3 und die Listings 6.3 und 6.4 zeigen die grundlegende Verwendung von Standard-ACLs. Im ersten Versuch einer vollstndigen Lsung sind zwei typische Versehen enthalten. Die Kriterien fr die ACLs sind die folgenden: Sam darf nicht auf Bugs oder Daffy zugreifen. Hosts im Ethernet Seville sollen keinen Zugriff auf Hosts im Ethernet Yosemite erhalten. Alle anderen Kombinationen sind zulssig.

Kapitel 6 IP-ACLs
Bugs 10.1.1.1 Daffy 10.1.1.2

313

Subnet 10.1.1.0 E0 Albuquerque s0


8. 0 .1 .1 2

s1

b Su ne t1

10

13 1. 0.

bn

et

0 0.

s0 Subnet 10.1.129.0 Yosemite E0 Subnet 10.1.2.0 s1 s1

Su

s0 Seville E0 Subnet 10.1.3.0

Sam 10.1.2.1

Emma 10.1.2.2

Elmer 10.1.3.1

Red 10.1.3.2

Abbildung 6.3: Netzdiagramm fr das Standard-ACL-Beispiel


Listing 6.3: Konfiguration von Yosemite
interface serial 0 ip access-group 3 out ! access-list 3 deny host 10.1.2.1 access-list 3 permit any

Listing 6.4: Konfiguration von Seville


interface serial 1 ip access-group 4 out ! access-list 4 deny 10.1.3.0 access-list 4 permit any

0.0.0.255

314

CCNA ICND2-Prfungshandbuch

Auf den ersten Blick scheinen die beiden ACLs die gewnschte Funktion zu erfllen. ACL 3 ist fr Pakete zustndig, die Yosemite ber die Schnittstelle S0 verlassen. Sie behandelt das erste Kriterium, denn sie prft auf die exakte IP-Adresse von Sam. ACL 4 ist fr Pakete vorgesehen, die Seville ber die Schnittstelle S1 verlassen, und behandelt das zweite Kriterium, das heit, sie gilt fr alle Pakete, die aus dem Subnetz 10.1.3.0/24 eingehen. Beide Router erfllen Kriterium 3: Eine Wildcard permit any wird am Ende der jeweiligen ACL verwendet, um die Default-Einstellung das Verwerfen aller unpassenden Pakete auer Kraft zu setzen. Also werden offenbar alle Kriterien erfllt. Wenn allerdings eine der WAN-Verbindungen ausfllt, werden die ACLs unwirksam. Wird beispielsweise die Verbindung zwischen Albuquerque und Yosemite unterbrochen, dann erlernt Yosemite eine Route nach 10.1.1.0/24 ber Seville. Pakete von Sam, die von Yosemite weitergeleitet werden und fr Hosts in Albuquerque bestimmt sind, verlassen die Schnittstelle S1 von Yosemite, ohne gefiltert zu werden. Kriterium 1 ist in diesem Fall nicht mehr erfllt. hnlich routet, wenn die Verbindung zwischen Seville und Yosemite ausfllt, Seville Pakete ber Albuquerque, d. h. quasi um die ACL auf Seville herum; dann ist auch Kriterium 2 nicht mehr erfllt. Listing 6.5 veranschaulicht eine alternative Lsung, bei der die gesamte Konfiguration auf Yosemite stattfindet und die auch dann funktioniert, wenn eine der Verbindungen ausfallen sollte.
Listing 6.5: Konfiguration von Yosemite: Alternative Lsung zu den Listings 6.3 und 6.4
interface serial 0 ip access-group 3 out ! interface serial 1 ip access-group 3 out ! interface ethernet 0 ip access-group 4 out ! access-list 3 remark meets criteria 1 access-list 3 deny host 10.1.2.1 access-list 3 permit any ! access-list 4 remark meets criteria 2 access-list 4 deny 10.1.3.0 0.0.0.255 access-list 4 permit any

Kapitel 6 IP-ACLs

315

Die in Listing 6.5 gezeigte Konfiguration behebt das Problem aus den Listings 6.3 und 6.4. ACL 3 prft auf die Absender-IP-Adresse von Sam und wird auf beiden seriellen Verbindungen fr ausgehenden Datenverkehr aktiviert. Insofern werden Daten von Sam, die aufgrund des Ausfalls einer WAN-Verbindung umgeleitet werden, nach wie vor ausgefiltert. Um Kriterium 2 zu erfllen, filtert Yosemite die Pakete, wenn sie die EthernetSchnittstelle verlassen. Insofern werden Pakete aus dem Subnetz von Seville keinesfalls an das Ethernet von Yosemite weitergeleitet unabhngig davon, ber welche der beiden WAN-Verbindungen sie empfangen werden.

6.4

Erweiterte ACLs

Erweiterte ACLs weisen sowohl Gemeinsamkeiten als auch Unterschiede zu Standard-ACLs auf. Wie Standard-ACLs sollten erweiterte ACLs an Schnittstellen wahlweise ein- oder ausgehende Pakete untersuchen. IOS durchsucht die Liste von oben nach unten. Die erste passende Anweisung beendet das Durcharbeiten der Liste und definiert die durchzufhrende Aktion. Alle diese Merkmale gelten auch fr Standard-ACLs. Der wesentliche Unterschied zwischen den beiden ACL-Varianten besteht in der Anzahl der Felder im Paket, die auf bereinstimmungen hin verglichen werden knnen. Eine einzelne Anweisung in einer erweiterten ACL kann mehrere Teile der Paket-Header untersuchen. Es mssen alle Parameter bereinstimmen, damit die ACL-Anweisung eine bereinstimmung erkennt. Diese Vergleichslogik ist es, die erweiterte ACLs sowohl weitaus ntzlicher als auch erheblich komplexer als Standard-ACLs macht. Der vorliegende Abschnitt beschrieb anfangs Eigenschaften erweiterter ACLs, die sich von Standard-ACLs unterscheiden. Dies betrifft in erster Linie die Vergleichslogik. Nachfolgend werden wir uns den Konfigurationsdetails widmen.

6.4.1

Funktion erweiterter ACLs

Erweiterte ACLs benutzen eine leistungsfhige Vergleichslogik. Damit gestatten sie das Untersuchen zahlreicher Teile eines Pakets. Abbildung 6.4 zeigt mehrere Felder in den Paket-Headern, die verglichen werden knnen.

316

CCNA ICND2-Prfungshandbuch
IP-Header

9 1 2 4 4 variabel Verschiedene Protokoll- Header- AbsenderZielOptionen Headertyp Prfsumme IP-Adresse IP-Adresse Felder Definiert, was hier enthalten ist. IP-Header

TCP, UDP ICMP, IGRP, IGMP,

TCP

9 1 2 4 4 variabel 2 2 16+ Verschiedene Weitere Protocol Header- AbsenderZielOptionen Abs.- Ziel- TCPHeader6 (TCP) Prfsumme IP-Adresse IP-Adresse Port Port Felder Angaben

Abbildung 6.4: Vergleichsoptionen erweiterter ACLs

Im oberen Teil gibt es im Header den IP-Protokolltyp. Dieser definiert, was fr ein Header dem IP-Header folgt. Sie knnen, indem Sie das Protokollfeld abfragen, alle IP-Pakete festlegen oder die Auswahl auf TCP-Header, UDPHeader, ICMP usw. begrenzen. Ferner knnen Sie wie gezeigt die Absender- und Ziel-IP-Adressen berprfen. Im unteren Teil der Abbildung wird exemplarisch auf den IP-Header folgend ein TCP-Header gezeigt. Die Positionen der TCP-Absender- und TCP-Empfnger-Port-Nummern sind hervorgehoben. Diese Port-Nummern bezeichnen die Anwendung. Das Web etwa verwendet standardmig Port 80. Wenn Sie TCP oder UDP als Protokoll angeben, knnen Sie auch die Port-Nummern berprfen. Tabelle 6.3 fasst oft verwendete Felder, die mithilfe einer erweiterten IP-ACL verglichen werden knnen, zusammen und stellt diesen die Mglichkeiten von Standard-ACLs gegenber.
Tabelle 6.3: Vergleichsmglichkeiten bei Standard- und erweiterten IP-ACLs
Wichtig!

ACL-Typ Standard- und erweiterte ACLs Nur erweiterte ACLs

Vergleichsmglichkeiten Absender-IP-Adresse Teile der Absender-IP-Adresse mithilfe einer Wildcard-Maske Ziel-IP-Adresse Teile der Ziel-IP-Adresse mithilfe einer Wildcard-Maske Protokolltyp (TCP, UDP, ICMP, IGRP, IGMP u. a.) Absender-Port Ziel-Port Alle TCP-Datenstrme mit Ausnahme des ersten IP-TOS IP-Vorrang

Kapitel 6 IP-ACLs

317

Zu wissen, wonach Sie beim Vergleich suchen mssen, ist schon die halbe Miete. Das IOS berprft alle Vergleichsangaben, die in einem einzelnen access-list-Befehl konfiguriert sind. Damit eine bereinstimmung erkannt und die entsprechende Aktion ausgefhrt wird, mssen alle Angaben in diesem Befehl bereinstimmen. Zu den Optionen gehrt zuallererst der Protokolltyp (IP, TCP, UDP, ICMP u. a.), gefolgt von der Absender-IP-Adresse, dem Absender-Port, der Ziel-IP-Adresse und der Ziel-Port-Nummer. Tabelle 6.4 zeigt und erlutert exemplarisch verschiedene access-list-Befehle, in denen diverse Optionen konfiguriert sind. Es sind nur die Vergleichsoptionen hervorgehoben.
Tabelle 6.4: Befehle und Erluterungen zur Logik der erweiterten ACLs
access-list-Anweisung
access-list 101 deny 00000000000000000000 ip any host 10.1.1.1 access-list 101 deny 0000000000000000000000000000000000 tcp any gt 1023 host 10.1.1.1 eq 23

Was wird verglichen? Alle IP-Pakete mit beliebiger AbsenderIP-Adresse und der Zieladresse 10.1.1.1. Pakete mit einem TCP-Header, beliebiger Absender-IP-Adresse, einem Absender-Port grer als 1023 (gt), der Zieladresse 10.1.1.1 und dem Ziel-Port mit dem exakten (eq) Wert 23. Wie oben, wobei jedoch jeder AbsenderPort eine bereinstimmung erzielt, weil der entsprechende Parameter weggelassen wurde. Wie oben. Das Schlsselwort telnet wurde hier anstelle von Port 23 verwendet.

access-list 101 deny 00000000000000000000000000 tcp any host 10.1.1.1 eq 23

access-list 101 deny 000000000000000000000000000000 tcp any host 10.1.1.1 eq telnet

access-list 101 deny Paket mit einer Absenderadresse im 000000000000000000000000000000000000 Netzwerk 1.0.0.0, das UDP ber einen udp 1.0.0.0 0.255.255.255 lt 1023 any Absender-Port kleiner als (lt) 1023 ver-

wendet, und beliebiger Ziel-IP-Adresse.

6.4.2

Vergleich von TCP- und UDP-Port-Nummern

Erweiterte ACLs ermglichen einen Vergleich des IP-Header-Protokollfeldes sowie der Absender- oder Ziel-Port-Nummern fr TCP und UDP. Viele Anwender haben allerdings Schwierigkeiten, wenn sie erstmals ACLs konfigurieren mssen, die Port-Nummern vergleichen. Dies gilt insbesondere im Falle von Absender-Port-Nummern. Wenn Sie auf Prfungsfragen treffen, in denen TCP- oder UDP-Ports erwhnt werden, beachten Sie bitte die folgenden Gesichtspunkte:

318

CCNA ICND2-Prfungshandbuch

Wichtig!

Der access-list-Befehl muss einen Protokollparameter verwenden. Fr den Vergleich von TCP-Ports muss tcp genannt werden, fr UDP-Ports udp. Das Schlsselwort ip ermglicht keinen Vergleich von Port-Nummern. Die Parameter zu Absender- und Ziel-Port im access-list-Befehl sind positionsgebunden, d. h., ihre Platzierung im Befehl bestimmt, ob der Parameter den Absender- oder den Ziel-Port untersucht. Denken Sie daran, dass ACLs Pakete, die an einen Server gesendet werden, durch Vergleich des Ziel-Ports mit Well-Known-Port-Nummern berprft. Absender-Ports hingegen werden in Paketen berprft, die vom Server gesendet werden. Es ist ntzlich, die verbreitetsten TCP- und UDP-Anwendungen und ihre jeweiligen Well-Known-Ports zu kennen. Sie sind in Tabelle 6.5 enthalten, die weiter unten in diesem Kapitel folgt. Betrachten Sie das in Abbildung 6.5 gezeigte einfache Netzwerk. Der FTPServer ist rechts abgebildet, der Client links. Die Abbildung zeigt die Syntax einer ACL, die auf folgende bereinstimmungen hin prft: Pakete, die einen TCP-Header enthalten Pakete, die aus dem Subnetz des Clients gesendet werden Pakete, die in das Subnetz des Servers gesendet werden Pakete mit dem TCP-Ziel-Port 21
Absender 172.16.1.1 172.16.1.0/24 IN PC1 Fa0/0 R1 S0/0 S0/1 OUT IN R2 OUT Fa0/0 SVR Ziel 172.16.3.1 Absender-Port > 1023 Ziel-Port 21 172.16.3.0/24172.16.3.1

access-list 101 permit tcp 172.16.1.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21

Abbildung 6.5: Auf dem Ziel-Port basierende Paketfilterung

Um den Vergleich des Ziel-Ports durch den Parameter eq 21 nachvollziehen zu knnen, betrachten Sie zunchst Pakete, die sich von links nach rechts also von PC1 zum Server bewegen. Wenn der Server den Well-Known-Port 21 (Steuer-Port fr FTP) verwendet, steht im von PC1 gesendeten Paket der Ziel-Port 21. In der ACL-Syntax steht hinter der Ziel-IP-Adresse der Parameter eq 21; dadurch wird dieser Parameter mit dem Ziel-Port verglichen. Wrde die in der Abbildung gezeigte ACL-Anweisung an einer der vier Pfeilpositionen positioniert, kme es bei diesem Paket mit dem Ziel-Port 21 zu einer bereinstimmung,

Kapitel 6 IP-ACLs

319

Abbildung 6.6 zeigt den umgekehrten Datenfluss: Ein Paket wird vom Server zurck an PC1 geschickt. In diesem Fall hat der TCP-Header des Pakets den Absender-Port 21, das heit, die ACL muss den Absender-Port-Wert 21 berprfen und auf einer der vier Schnittstellen nun in der anderen Richtung implementiert werden.
Absender 172.16.3.1 172.16.1.0/24 OUT PC1 Fa0/0 R1 S0/0 S0/1 IN OUT R2 Ziel 172.16.1.1 Absender-Port 21 Ziel-Port > 1023 172.16.3.0/24 IN Fa0/0 172.16.3.1 SVR

access-list 101 permit tcp 172.16.3.0 0.0.0.255 eq 21 172.16.1.0 0.0.0.255

Abbildung 6.6: Auf dem Absender-Port basierende Paketfilterung

Bei Prfungsaufgaben mit ACLs und einem Vergleich von Port-Nummern sollten Sie sich zuerst fragen, ob die ACL zur Lsung der Aufgabe an einer bestimmten Position und in einer bestimmten Richtung platziert werden muss. Sollte dies der Fall sein, dann knnen Sie bestimmen, wie die ACL die Pakete verarbeiten wird, die entweder an den Server oder aber von ihm gesendet wurden. Danach knnen Sie entscheiden, ob Sie den Absenderoder den Ziel-Port im Paket berprfen mssen. Als Referenz listet Tabelle 6.5 viele bekannte Port-Nummern und die zugehrigen Transportschichtprotokolle und Anwendungen auf. Beachten Sie, dass die Syntax der access-list-Befehle sowohl Port-Nummern als auch eine Kurzangabe des Anwendungsnamens akzeptiert.
Tabelle 6.5: Verbreitete Anwendungen und ihre Well-Known-Ports
Port-Nummer(n) Protokoll Anwendung Schlsselwort fr die Anwendung in access-listBefehlen
ftp-data ftp

20 21 22 23 25 53 67, 68 69 80

TCP TCP TCP TCP TCP

FTP (Daten) FTP (Steuerung) SSH Telnet SMTP

telnet smtp domain nameserver tftp www

UDP, TCP DNS UDP UDP TCP DHCP TFTP HTTP (WWW)

320

CCNA ICND2-Prfungshandbuch

Tabelle 6.5: Verbreitete Anwendungen und ihre Well-Known-Ports (Forts.)


Port-Nummer(n) Protokoll Anwendung Schlsselwort fr die Anwendung in access-listBefehlen
pop3 snmp

110 161 443

TCP UDP TCP

POP3 SNMP SSL RTP-basierte Sprachdienste (VoIP) und Videodienste

16384 bis 32767 UDP

6.4.3

Erweiterte ACLs konfigurieren

Weil erweiterte ACLs sehr viel mehr unterschiedliche Felder in den verschiedenen Headern eines IP-Pakets berprfen knnen, lsst sich die Befehlssyntax nicht in einem einzelnen universellen Befehl zusammenfassen. Der bersicht halber fhrt Tabelle 6.6 die Syntax der beiden allgemeinen Befehlsversionen auf.
Tabelle 6.6: Befehle zur Konfiguration erweiterter ACLs
Befehl
access-list access-list-number {deny | permit} protocol source source-wildcard destination destination-wildcard [log | log-input]

Konfigurationsmodus und Beschreibung Globaler Befehl fr erweiterte nummerierte ACLs. Verwenden Sie eine Nummer zwischen 100 und 199 oder zwischen 2000 und 2699 (jeweils einschlielich). Version des access-list-Befehls mit TCP-spezifischen Parametern.

access-list access-list-number {deny | permit} {tcp | udp} source source-wildcard [operator [port]] destination destination-wildcard [operator [port]] [established] [log]

Die Konfiguration erweiterter ACLs entspricht weitgehend der Vorgehensweise bei Standard-ACLs. Zunchst mssen die Platzierung und Richtung und dann die Parameter der ACL basierend auf den Headern in den Paketen geplant werden. Die ACL wird mit access-list-Befehlen konfiguriert. Danach kann die ACL mit demselben Befehl ip access-group aktiviert werden, der auch bei Standard-ACLs zum Einsatz kommt. Alle diese Schritte sind mit der Vorgehensweise fr Standard-ACLs identisch. Die Unterschiede in der Konfiguration lassen sich wie folgt zusammenfassen:

Kapitel 6 IP-ACLs

321

Erweiterte ACLs sollten so nah wie mglich am Absender der zu filternden Pakete platziert werden, da sie sich so konfigurieren lassen, dass Pakete nicht flschlicherweise verworfen werden. Insofern ermglicht die Filterung der Pakete eine gewisse Bandbreiteneinsparung. Alle Felder im access-list-Befehl mssen bereinstimmen, damit ein Paket mithilfe der access-list-Anweisung ermittelt werden kann. Der erweiterte access-list-Befehl verwendet die Bereiche 100199 und 20002699. Auch hier wird keine Zahl bevorzugt behandelt. Die erweiterte Version des access-list-Befehls ermglicht einen Vergleich der Port-Nummern mithilfe verschiedener einfacher Operationen. Die Befehle verwenden die in Tabelle 6.7 aufgefhrten Abkrzungen.
Tabelle 6.7: Fr den Vergleich von Port-Nummern verwendete Operatoren
Operator im access-list-Befehl
eq neq lt gt range

Wichtig!

Bedeutung ist gleich ist ungleich ist kleiner als ist grer als Bereich der Port-Nummern

Wichtig!

Beispiel 1 zu den erweiterten ACLs


In unserem Beispiel liegt der Schwerpunkt auf dem Verstndnis der grundlegenden Syntax. In diesem Fall wird Bob der Zugriff auf alle FTP-Server im Ethernet von R1 verweigert. Ebenso wenig erhlt Larry Zugang zu den Webdiensten von Server1. Abbildung 6.7 stellt noch einmal die Netzwerktopologie dar. Listing 6.6 zeigt die Konfiguration auf R1.
Server1
SW2
S0 S0

Larry

R2
S1

E0

SW12 172.16.2.10

172.16.1.100

Server2
SW3 172.16.1.102

SW1

E0

R1
S1 S1 S0

Bob

R3

E0

SW13 172.16.3.10

Jimmy

Jerry

172.16.3.8 172.16.3.9

Abbildung 6.7: Beispiel zu erweiterten ACLs

322

CCNA ICND2-Prfungshandbuch

Listing 6.6: Beispiel 1 zu erweiterten ACLs


interface Serial0 ip address 172.16.12.1 255.255.255.0 ip access-group 101 in ! interface Serial1 ip address 172.16.13.1 255.255.255.0 ip access-group 101 in ! access-list 101 00000000000000000000000000000000000000000000000000000000 remark Stop Bob to FTP servers, and Larry to Server1 web access-list 101 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp access-list 101 deny tcp host 172.16.2.10 host 172.16.1.100 eq www access-list 101 permit ip any any

In Listing 6.6 verhindert die erste ACL-Anweisung, dass Bob auf die FTPServer im Subnetz 172.16.1.0 zugreift. Die zweite Anweisung unterbindet den Zugriff von Larry auf die Webdienste auf Server1. Die letzte Anweisung schlielich gestattet den gesamten weiteren Datenverkehr. Wenn wir uns fr einen Moment die Syntax ganz genau ansehen, stellen wir fest, dass es mehrere Elemente gibt, die wir erlutern mssen. Zunchst fllt auf, dass die Nummer der ACL im Bereich fr erweiterte ACLs (100199, 20002699) liegt. Auf die Aktion permit oder deny folgend definiert der Parameter protocol, ob Sie alle IP-Pakete oder nur solche mit TCP- oder UDPHeadern berprfen. Wenn Sie auf das Vorhandensein von bestimmten TCP- oder UDP-Port-Nummern hin prfen wollen, mssen Sie das TCPoder UDP-Protokoll angeben. Im Listing wird der Parameter eq verwendet, der die Bedeutung ist gleich hat; mit ihm werden hier die Ziel-Port-Nummern auf FTP-Pakete (Schlsselwort ftp) und HTTP-Daten (Schlsselwort www) berprft. Sie knnen die numerischen Werte oder zumindest bei den verbreiteteren Anwendungen die naheliegende Textvariante verwenden. (Beispielsweise knnten Sie statt eq 80 auch eq www angeben, wie es spter auch in der show-Ausgabe erscheinen wrde.) In unserem ersten Beispiel zu erweiterten ACLs htten diese statt auf R1 auch auf R2 und R3 platziert werden knnen. Wie Sie gegen Ende dieses Kapitels lesen werden, gibt Cisco einige besondere Empfehlungen zur Positionierung von IP-ACLs. So wird etwa dazu geraten, erweiterte ACLs so nahe wie mglich am Absender des Pakets zu platzieren. Aus diesem Grund erfllt Listing 6.7 die gleiche Aufgabe wie Listing 6.6 nmlich, Bobs Zugriff auf FTP-Server am Hauptstandort zu unterbinden mit einer ACL auf R3.

Kapitel 6 IP-ACLs

323

Listing 6.7: Erweiterte ACL auf R3, um Bobs Zugriff auf FTP-Server bei R1 zu unterbinden
interface Ethernet0 ip address 172.16.3.1 255.255.255.0 ip access-group 101 in access-list 101 remark deny Bob to FTP servers in subnet 172.16.1.0/24 access-list 101 deny tcp host 172.16.3.10 172.16.1.0 0.0.0.255 eq ftp access-list 101 permit ip any any

ACL 101 sieht zwar fast genauso aus wie ACL 101 aus Listing 6.6. doch fehlt hier eine berprfung von Larrys Datenverkehr, weil dieser in keinem Fall an der Schnittstelle Ethernet0 von R3 empfangen wird. Da die ACL auf R3 implementiert wurde d. h. in der Nhe von Bob , sucht sie nach von Bob gesendeten Paketen, die an der Schnittstelle Ethernet0 empfangen werden. Aufgrund der ACL werden FTP-Daten, die Bob an 172.16.1.0/24 sendet, abgewiesen, whrend alle anderen an der Schnittstelle E0 eingehenden Daten ins Netzwerk weitergeleitet werden. Listing 6.7 enthlt keine Logik zum Filtern von Daten, die von Larry kommen.

Beispiel 2 zu den erweiterten ACLs


Listing 6.8, welches auf dem in Abbildung 6.8 gezeigten Netzwerk basiert, zeigt ein weiteres Beispiel dafr, wie sich erweiterte ACLs einsetzen lassen. Das Beispiel verwendet dieselbe Zielstellung und Netzwerktopologie wie das zweite Beispiel zu den Standard-ACLs: Sam darf nicht auf Bugs oder Daffy zugreifen. Hosts im Ethernet Seville sollen keinen Zugriff auf Hosts im Ethernet Yosemite erhalten. Alle anderen Kombinationen sind zulssig.
Listing 6.8: Konfiguration einer erweiterten ACL auf Yosemite
interface ethernet 0 ip access-group 110 in ! access-list 110 deny ip host 10.1.2.1 10.1.1.0 0.0.0.255 access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255 access-list 110 permit ip any any

324

CCNA ICND2-Prfungshandbuch
Bugs 10.1.1.1 Daffy 10.1.1.2

Subnet 10.1.1.0 E0 Albuquerque s0


8. 0 .1 .1 2

s1

b Su ne t1

10

13 1. 0.

bn

et

0 0.

s0 Subnet 10.1.129.0 Yosemite E0 Subnet 10.1.2.0 s1 s1

Su

s0 Seville E0 Subnet 10.1.3.0

Sam 10.1.2.1

Emma 10.1.2.2

Elmer 10.1.3.1

Red 10.1.3.2

Abbildung 6.8: Beispiel 2 zu erweiterten ACLs

Diese Konfiguration lst das Problem mit wenigen Anweisungen und unter Beachtung von Ciscos Empfehlung, die besagt, dass erweiterte ACLs mglichst nah am Absender der zu prfenden Daten platziert werden sollen. Die ACL filtert Pakete, die an der Schnittstelle E0 von Yosemite empfangen werden. Dies ist die erste Router-Schnittstelle, an der von Sam gesendete Pakete landen. Das Problem, dass sich Pakete um ACLs auf seriellen Schnittstellen herumleiten lassen, wird dadurch behoben, dass die ACL auf der einzigen Ethernet-Schnittstelle von Yosemite platziert wird. Zudem wird der zweiten Bedingung dem Unterbinden des Zugriffs auf das LAN von Yosemite aus dem LAN von Seville heraus ber die zweite access-list-Anweisung Rechnung getragen. Durch Verhindern des Paketflusses aus dem LAN-Subnetz von Yosemite in das LAN-Subnetz von Seville wird die Kommunikation zwischen den beiden Subnetzen wirkungsvoll unterbunden. Alternativ htte die umgekehrte Logik auch auf Seville konfiguriert werden knnen.

Kapitel 6 IP-ACLs

325

6.5

Fortschritte bei der ACL-Konfiguration

Nachdem Sie das Prinzip der IP-ACLs nun kennen, wollen wir im folgenden Abschnitt eine Reihe von Erweiterungen beschreiben, die das IOS zur Untersttzung von ACLs bereitstellt: ACLs mit Namen und ACL-Sequenznummern. Beide Merkmale sind ntzlich und wichtig, erweitern aber nicht die bereits bei numerischen ACLs behandelten Funktionalitten eines Routers zur Filterung. Es ist vielmehr so, dass ACLs mit Namen und Sequenznummern es einfacher machen, sich die Bezeichnung der ACL zu merken und was besonders wichtig ist bestehende ACLs im Bedarfsfall zu editieren.

6.5.1

ACLs mit Namen

Die mit IOS 11.2 eingefhrten ACLs mit Namen werden genauso verwendet, um Pakete zu vergleichen, wie es auch mit Standard- oder erweiterten ACLs mglich ist. ACLs mit Namen haben jedoch besondere Fhigkeiten, die den Umgang mit ihnen erleichtern. Der offensichtlichste Unterschied besteht darin, dass das IOS solche ACLs anhand von Namen identifiziert, die Sie anstelle von Nummern vergeben. Dies erhht die Wahrscheinlichkeit, dass Sie sich die Namen merken knnen. Der zweite wichtige Vorteil benannter gegenber numerischen ACLs bestand zum Zeitpunkt ihrer Einfhrung darin, dass man in ihnen einzelne Zeilen lschen konnte. Davor war es in mit dem globalen Befehl ip accesslist erstellten numerischen ACLs nicht mglich gewesen, eine einzelne Zeile separat zu entfernen (dies wurde erst mit IOS 12.3 mglich). Wenn Sie beispielsweise frher mit dem Befehl ip access-list 101 permit tcp any any eq 80 eine ACL konfiguriert und spter den Befehl no ip access-list 101 permit tcp any any eq 80 eingegeben htten, wre die gesamte ACL 101 gelscht worden! Der Vorteil der Einfhrung von ACLs mit Namen besteht also darin, dass Sie einen Befehl eingeben knnen, der einzelne Zeilen aus einer solchen ACL lscht.

ANMERKUNG
Mit IOS 12.3 erweiterte Cisco das IOS um eine Funktionalitt zum Lschen einzelner Zeilen aus numerischen ACLs. Auf diese Weise wurde der IOS-Support fr die Editierung numerischer ACLs und von ACLs mit Namen auf die gleiche Stufe gestellt. Wir werden im nchsten Abschnitt darauf eingehen.

326

CCNA ICND2-Prfungshandbuch

Die Syntax ist bei Konfiguration von ACLs mit Nummern und solchen mit Namen sehr hnlich. Mit ihnen lassen sich jeweils dieselben Elemente vergleichen, das heit, was sich mit einer nummerierten Standard-ACL vergleichen lsst, kann auch mit einer Standard-ACL mit einem Namen verglichen werden. Analoges gilt fr nummerierte und benannte erweiterte ACLs. Allerdings gibt es zwischen den numerischen ACLs alten Stils und den neueren ACLs mit Namen zwei wichtige Konfigurationsunterschiede. Ein wesentlicher Gegensatz besteht darin, dass ACLs mit Namen einen besonderen globalen Konfigurationsbefehl kennen. Mit diesem Befehl kann der Benutzer in einen Untermodus fr benannte ACLs wechseln, in dem dann die Vergleichs- und Aktionslogik konfiguriert wird. Der zweite Unterschied fhrt dazu, dass eine Vergleichsanweisung in einer benannten ACL nun separat gelscht werden kann. Listing 6.9 zeigt ein Beispiel, in dem ACLs mit Namen eingesetzt werden. Es enthlt die neue Eingabeaufforderung, die signalisiert, dass sich der Benutzer im ACL-Konfigurationsmodus befindet. Ebenfalls vorhanden ist die Ausgabe des Befehls show running-configuration. Abschlieend sehen Sie ein Beispiel dafr, wie man einzelne Zeilen in einer ACL mit Namen lscht.
Listing 6.9: Konfiguration einer ACL mit Namen
conf t Enter configuration commands, one per line. End with Ctrl-Z. Router(config)#ip access-list extended barney Router(config-ext-nacl)#permit tcp host 10.1.1.2 eq www any Router(config-ext-nacl)#deny udp host 10.1.1.1 10.1.2.0 0.0.0.255 Router(config-ext-nacl)#deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255 ! Die nchste Anweisung wurde bewusst falsch formuliert, damit der Prozess ! der Listennderung offensichtlich wird. Router(config-ext-nacl)#deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255 Router(config-ext-nacl)#deny ip host 10.1.1.130 host 10.1.3.2 Router(config-ext-nacl)#deny ip host 10.1.1.28 host 10.1.3.2 Router(config-ext-nacl)#permit ip any any Router(config-ext-nacl)#interface serial1 Router(config-if)#ip access-group barney out Router(config-if)#^Z Router#show running-config Building configuration... Current configuration: . . (unwichtige Anweisungen weggelassen)

Kapitel 6 IP-ACLs
Listing 6.9: Konfiguration einer ACL mit Namen (Forts.)

327

. interface serial 1 ip access-group barney out ! ip access-list extended barney permit tcp host 10.1.1.2 eq www any deny udp host 10.1.1.1 10.1.2.0 0.0.0.255 deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255 deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255 deny ip host 10.1.1.130 host 10.1.3.2 deny ip host 10.1.1.28 host 10.1.3.2 permit ip any any Router#conf t Enter configuration commands, one per line. End with Ctrl-Z. Router(config)#ip access-list extended barney Router(config-ext-nacl)#no deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.0.255 000000000000000000000000000000000000000000000000 Router(config-ext-nacl)#^Z Router#show access-list Extended IP access list barney 10 permit tcp host 10.1.1.2 eq www any 20 deny udp host 10.1.1.1 10.1.2.0 0.0.0.255 30 deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255 50 deny ip host 10.1.1.130 host 10.1.3.2 60 deny ip host 10.1.1.28 host 10.1.3.2 70 permit ip any any

Listing 6.9 beginnt mit der Erstellung einer ACL namens barney. Der Befehl ip access-list extended barney erstellt die ACL, gibt ihr den Namen und wechselt in den ACL-Konfigurationsmodus. Auerdem kann das IOS dem Befehl entnehmen, dass barney eine erweiterte ACL ist. Nachfolgend definieren sieben verschiedene permit- und deny-Anweisungen die Vergleichslogik und die Aktionen, die bei einer bereinstimmung durchzufhren sind. Die Befehle permit und deny verwenden dieselbe Syntax wie nummerierte access-list-Befehle, die mit den Schlsselwrtern deny bzw. permit beginnen. In diesem Beispiel wird unmittelbar vor dem Befehl eine Anmerkung eingefgt, die im weiteren Verlauf des Listings wieder gelscht wird. Die Ausgabe von show running-config zeigt die Konfiguration der benannten ACL vor dem Lschen des Eintrags. Danach lscht der Befehl no deny ip einen einzelnen Eintrag aus der ACL. Beachten Sie, dass die Ausgabe des Befehls show running-config die ACL nach wie vor enthlt nun mit sechs statt mit sieben permit- und deny-Befehlen.

328

CCNA ICND2-Prfungshandbuch

6.5.2

ACLs mit Sequenznummern editieren

Nummerierte ACLs waren bereits in der Frhzeit der Cisco-Router im IOS vorhanden. Bis zur IOS-Version 12.2 bestand die einzige Mglichkeit, eine vorhandene nummerierte ACL zu editieren (um etwa eine Zeile zu lschen) darin, die gesamte ACL zu lschen und dann von Grund auf neu zu konfigurieren. Dies war nicht nur fr den Netzwerktechniker unpraktisch, sondern hatte auch einige weniger angenehme Nebeneffekte. Wenn man nmlich eine ACL entfernt, muss sie auf allen Schnittstellen zunchst deaktiviert und anschlieend gelscht werden. Danach muss sie neu konfiguriert und wieder auf der Schnittstelle aktiviert werden. Andernfalls fhrt die ACL whrend der Neukonfiguration also bevor alle Anweisungen neu konfiguriert wurden nicht alle erforderlichen berprfungen durch. Dies kann Konnektivittsprobleme verursachen oder das Netzwerk fr verschiedene Angriffstypen anfllig machen. Wie bereits im vorangegangenen Abschnitt erwhnt, lste die in IOS 11.2 neu eingefhrte Untersttzung fr ACLs mit Namen diese Probleme zumindest teilweise. Die Befehle fr ACLs mit Namen gestatteten dem Netzwerktechniker das Lschen einer Zeile aus einer ACL, wie wir es in Listing 6.9 weiter oben gesehen haben. Allerdings gestatteten die Konfigurationsbefehle es dem Benutzer nicht, einen neuen permit- oder deny-Befehl in die Liste einzufgen. Neue Befehle wurden stets am Ende der ACL angehngt. Mit IOS 12.3 fhrte Cisco dann einige neue Konfigurationsoptionen fr ACLs ein Optionen, die sowohl fr nummerierte ACLs als auch fr solche mit Namen gelten. Diese Optionen nutzen eine ACL-Sequenznummer, die jeder permit- oder deny-Anweisung in der ACL hinzugefgt wird. Diese Sequenznummern legen die Reihenfolge der Anweisungen in der ACL fest. ACL-Sequenznummern bieten die folgenden Funktionalitten fr nummerierte und benannte ACLs:
Wichtig!

Eine einzelne permit- oder deny-Anweisung kann durch eine einfache Angabe ihrer Sequenznummer entfernt werden, ohne den Rest der ACL zu lschen. Neu hinzugefgte permit- und deny-Befehle knnen mit einer Sequenznummer konfiguriert werden, die die Position der Anweisung innerhalb der ACL angibt. Neu hinzugefgte permit- und deny-Befehle knnen auch ohne Sequenznummer konfiguriert werden. In diesem Fall erstellt IOS selbst eine Sequenznummer und platziert diesen Befehl am Ende der ACL.

Kapitel 6 IP-ACLs

329

Damit sich die Mglichkeit, Zeilen aus einer ACL zu lschen bzw. in sie einzufgen, auch nutzen lsst, mssen sowohl nummerierte als auch benannte ACLs denselben Konfigurationsstil und dieselben Befehle verwenden. Der einzige Unterschied in der Syntax besteht in der Frage, ob ein Name oder eine Nummer benutzt wird. Listing 6.10 zeigt die Konfiguration einer nummerierten Standard-ACL mithilfe dieser alternativen Syntax. Das Listing veranschaulicht die Leistungsfhigkeit von ACL-Sequenznummern und deren Editierbarkeit. In diesem Beispiel finden die folgenden Vorgnge statt: 1. Die nummerierte ACL 24 wird mithilfe der neuen Syntax konfiguriert und enthlt drei permit-Befehle. 2. Der Befehl show ip access-list zeigt die drei permit-Befehle mit den Sequenznummern 10, 20 und 30 an. 3. Der Netzwerktechniker lscht nun den zweiten permit-Befehl mit dem ACL-Befehl no 20 (dieser verweist schlicht auf die Sequenznummer 20). 4. Der Befehl show ip access-list besttigt, dass die ACL jetzt nur noch zwei Zeilen (mit den Sequenznummern 10 und 30) enthlt. 5. Der Netzwerktechniker fgt am Anfang der ACL mit dem ACL-Befehl 5 deny 10.1.1.1 eine neue permit-Anweisung hinzu. 6. Der Befehl show ip access-list besttigt erneut das Vorhandensein dreier permit-Befehle mit den Sequenznummern 5, 10 und 30.

ANMERKUNG
Beachten Sie in diesem Beispiel, dass der Benutzer den Konfigurationsmodus nicht verlsst, sondern IOS stattdessen mit dem Befehl do anweist, den EXEC-Befehl show ip access-list im Konfigurationsmodus abzusetzen.
Listing 6.10: ACLs mit Sequenznummern editieren
! Schritt 1: Die dreizeilige nummerierte Standard-ACL wird konfiguriert. R1#configure terminal Enter configuration commands, one per line. End with Ctrl-Z. R1(config)#ip access-list standard 24 00000000000000000000000000 R1(config-std-nacl)#permit 10.1.1.0 0.0.0.255 R1(config-std-nacl)#permit 10.1.2.0 0.0.0.255 R1(config-std-nacl)#permit 10.1.3.0 0.0.0.255 ! Schritt 2: Der Inhalt der ACL wird angezeigt, ohne den Konfigurationsmodus ! zu verlassen. R1(config-std-nacl)#do show ip access-list 24 Standard IP access list 24 10 permit 10.1.1.0, wildcard bits 0.0.0.255 20 permit 10.1.2.0, wildcard bits 0.0.0.255 30 permit 10.1.3.0, wildcard bits 0.0.0.255

330

CCNA ICND2-Prfungshandbuch

Listing 6.10: ACLs mit Sequenznummern editieren (Forts.)


! Schritt 3: Noch immer im Konfigurationsmodus fr ACL 24 wird nun die Zeile ! mit der Sequenznummer 20 gelscht. R1(config-std-nacl)#no 20 ! Schritt 4: Der Inhalt der ACL wird erneut angezeigt, ohne den ! Konfigurationsmodus zu verlassen. Beachten Sie, dass die Zeile mit der ! Nummer 20 nicht mehr aufgefhrt wird. R1(config-std-nacl)#do show ip access-list 24 Standard IP access list 24 10 permit 10.1.1.0, wildcard bits 0.0.0.255 30 permit 10.1.3.0, wildcard bits 0.0.0.255 ! Schritt 5: Eine neue erste Zeile wird in die ACL eingefgt. R1(config-std-nacl)#5 deny 10.1.1.1 ! Schritt 6: Der Inhalt der ACL wird ein letztes Mal angezeigt, wobei die ! neue Anweisung (Sequenznummer 5) zuerst angezeigt wird. R1(config-std-nacl)#do show ip access-list 24 Standard IP access list 24 00000000000000000 5 deny 10.1.1.1 10 permit 10.1.1.0, wildcard bits 0.0.0.255 30 permit 10.1.3.0, wildcard bits 0.0.0.255

Interessanterweise knnen nummerierte ACLs wahlweise mit der neuen Syntax (wie in Listing 6.10 gezeigt) oder der alten Syntax mit globalen accesslist-Befehlen konfiguriert werden, wie wir es in frheren Beispielen in diesem Kapitel getan haben. Im Grunde genommen knnen Sie sogar beide Konfigurationsarten fr dieselbe ACL einsetzen. Allerdings zeigt die Ausgabe des Befehls show running-config unabhngig vom verwendeten Stil stets die Konfigurationsbefehle der alten Syntax an. Listing 6.11 veranschaulicht diese Tatsache. Es setzt an der Stelle fort, an der Listing 6.10 endete, und ergnzt die folgenden Schritte: 7. Der Netzwerktechniker zeigt mit show running-config die Konfiguration an, die im alten Konfigurationsstil angezeigt wird (obwohl die ACL selbst mit den Befehlen der neuen Syntax erstellt wurde). 8. Der Netzwerktechniker fgt eine neue Anweisung am Ende der ACL hinzu. Hierzu setzt er den globalen Konfigurationsbefehl access-list 24 permit 10.1.4.0 0.0.0.255 (nach altem Muster) ab. 9. Der Befehl show ip access-list zeigt, dass der access-list-Befehl tatschlich entsprechend den Vorgaben der alten Syntax am Ende der ACL angehngt wurde. 10. Der Netzwerktechniker listet die Konfiguration auf, um sich zu vergewissern, dass alle mit der neuen wie auch mit der alten Syntax konfigurierten Bestandteile der ACL 24 aufgefhrt werden (show running-config).

Kapitel 6 IP-ACLs
Listing 6.11: Numerische ACL-Konfiguration ergnzen und anzeigen
! Schritt 7: Konfigurationsausschnitt fr ACL 24. R1#show running-config ! Die einzigen Zeilen, die angezeigt werden, entstammen ACL 24. access-list 24 deny 10.1.1.1 access-list 24 permit 10.1.1.0 0.0.0.255 access-list 24 permit 10.1.3.0 0.0.0.255

331

! Schritt 8: Ein neuer Befehl access-list 24 wird hinzugefgt. R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#access-list 24 permit 10.1.4.0 0.0.0.255 0000000000000000000000000000000000000000 R1(config)#^Z ! Schritt 9: Der Inhalt der ACL wird ein weiteres Mal angezeigt, diesmal mit ! Sequenznummern. Beachten Sie, dass auch die neue Anweisung automatisch ! eine Sequenznummer erhalten hat. R1#show ip access-list 24 Standard IP access list 24 5 deny 10.1.1.1 10 permit 10.1.1.0, wildcard bits 0.0.0.255 30 permit 10.1.3.0, wildcard bits 0.0.0.255 40 permit 10.1.4.0, wildcard bits 0.0.0.255 ! ! Schritt 10: Die Konfiguration der nummerierten ACL behlt die ! Konfigurationsbefehle der alten Syntax bei. R1#show running-config ! Die einzigen Zeilen, die angezeigt werden, entstammen ACL 24. access-list 24 deny 10.1.1.1 access-list 24 permit 10.1.1.0 0.0.0.255 access-list 24 permit 10.1.3.0 0.0.0.255 access-list 24 permit 10.1.4.0 0.0.0.255

6.6

Weitere ACL-Themen

Dieser kurze Abschnitt behandelt ein paar untergeordnete Themen, beispielsweise die Filterung von Telnet- und SSH-Daten mit ACLs und einige allgemeine Richtlinien zur Implementierung.

6.6.1

Telnet- und SSH-Zugriff mit ACLs steuern

Ein Netzwerktechniker kann den Remotezugriff auf einen Router mithilfe von ACLs steuern, die nach den von Telnet und SSH verwendeten WellKnown-Ports (23 bzw. 22) suchen. Allerdings msste eine ACL, die man mit dem Schnittstellenbefehl ip access-group auf den Schnittstellen aktiviert, auf alle IP-Adressen der Router bzw. PCs und auf den Telnet- und den SSH-Port hin prfen. Zudem msste die ACL aktualisiert werden, wann immer Schnittstellen hinzugefgt werden.

332

CCNA ICND2-Prfungshandbuch

Das IOS bietet eine wesentlich einfachere Option zum Schutz des Zugriffs auf und von VTY-Ports (virtuelle Terminalverbindungen). Telnet- und SSHBenutzer stellen Verbindungen mit VTY-Ports auf einem Router her, das heit, um diesen Zugriff zu schtzen, kann eine ACL auf die VTY-Verbindungen angewendet werden. Sie knnen mithilfe von ACLs einschrnken, welche IP-Hosts Telnet-Verbindungen mit dem Router herstellen drfen und mit welchen Hosts ein Benutzer des Routers umgekehrt Telnet-Verbindungen herstellen darf. Nehmen wir etwa an, dass nur Hosts im Subnetz 10.1.1.0/24 Telnet-Verbindungen mit Cisco-Routern in einem Netzwerk herstellen drfen. In einem solchen Fall kann die in Listing 6.12 verwendete Konfiguration verwendet werden, um den Zugriff von IP-Adressen in anderen Subnetzen zu unterbinden.
Listing 6.12: VTY-Zugriffssteuerung mit dem Befehl access-class
line vty 0 4 login password cisco access-class 3 in ! ! Der nchste Befehl ist ein globaler Befehl. access-list 3 permit 10.1.1.0 0.0.0.255

Der Befehl access-class aktiviert die Vergleichslogik von access-list 3. Das Schlsselwort in verweist auf eingehende Telnet-Verbindungen (also TelnetDaten, die von diesem Router empfangen werden). Durch diese Konfiguration berprft ACL 3 die Absender-IP-Adresse in Paketen auf eingehende Telnet-Verbindungen hin. Wre der Befehl access-class 3 out verwendet worden, so wren ausgehende Daten nicht nur auf gesendete Telnet-Daten hin geprft worden, sondern es wre auch die Ziel-IP-Adresse bercksichtigt worden. Beim Filtern ausgehender Telnet- und SSH-Verbindungen wre die berprfung der Absenderadresse bei der es sich naturgem um eine der Schnittstellen-IP-Adressen des Routers gehandelt htte wenig sinnvoll gewesen. Die Filterung ausgehender Telnet-Sitzungen sollte vielmehr am besten auf der Ziel-IP-Adresse basieren. Insofern ist die Verwendung des Befehls access-class 3 out und insbesondere des Schlsselwortes out einer jener seltenen Flle, in denen eine Standard-ACL tatschlich die Ziel-IP-Adresse (und nicht die Absenderadresse) berprft.

Kapitel 6 IP-ACLs

333

6.6.2

Einsatz von ACLs

In IP-basierten Produktionsnetzwerken knnen die Erstellung und Aktualisierung von IP-ACLs und die Problembehebung eine Menge Zeit und Aufwand erfordern. In der ICND2-Prfung sind nicht allzu viele Fragen dazu vorhanden, worauf man bei der Implementierung von ACLs in laufenden Netzwerken achten muss. Es gibt allerdings ein paar wenige, doch wichtige Faktoren, die wir im Folgenden behandeln wollen. Cisco stellt in den Kursen, auf denen die CCNA-Prfungen basieren, die folgenden allgemeinen Empfehlungen auf: Erstellen Sie Ihre ACLs mit einem Texteditor zunchst auerhalb des Routers und kopieren Sie sie dann auf den Router. (Trotz der nun vorhandenen Mglichkeit, Zeilen aus einer ACL zu lschen bzw. in sie einzufgen, ist dies wahrscheinlich die einfachere Vorgehensweise.) Platzieren Sie erweiterte ACLs so nah wie mglich am Absender entsprechender Pakete, damit diese mglichst schnell verworfen werden. Platzieren Sie Standard-ACLs so nah wie mglich am Empfnger der entsprechenden Pakete, da andernfalls hufig Pakete verworfen werden, die nicht verworfen werden sollen. Je spezifischer eine Anweisung ist, desto weiter oben sollte sie in der ACL aufgefhrt werden. Deaktivieren Sie eine ACL auf der Schnittstelle (mit dem Befehl no ip access-group), bevor Sie nderungen an der ACL vornehmen. Der erste Vorschlag besagt, dass Sie die ACLs auerhalb des Routers mit einem Editor erstellen sollten. Auf diese Weise knnen Sie etwa Tippfehler direkt im Editor beheben. Dieser Vorschlag ist nicht mehr so wichtig wie noch vor IOS 12.3, denn seit dieser Version werden ACL-Zeilennummern und das Lschen und Hinzufgen einzelner Zeilen in einer ACL untersttzt (siehe oben unter ACLs mit Sequenznummern editieren).
Wichtig!

ANMERKUNG
Wenn Sie alle Ihre ACLs in einem Texteditor erstellen, ist es sinnvoll, jede Datei mit dem Befehl no access-list number einzuleiten, auf den dann die Konfigurationsbefehle der ACL folgen. Danach mssen Sie jedes Mal, wenn Sie die ACL durch Editieren der Textdatei ndern, lediglich den gesamten neuen Dateiinhalt einfgen. Die erste Zeile lscht die vorhandene ACL in diesem Fall vollstndig, die brigen Anweisungen erstellen Sie dann neu.

334

CCNA ICND2-Prfungshandbuch

Der zweite und der dritte Punkt behandeln die Positionierung von ACLs. Wenn Sie ein Paket filtern wollen, hat eine Filterung mglichst nahe am Absender des Pakets zur Folge, dass weniger Bandbreite bentigt wird, was nicht nur effizienter scheint, sondern es auch tatschlich ist. Aus diesem Grund empfiehlt Cisco, erweiterte ACLs so nah am Absender wie mglich zu platzieren. Gleichzeitig aber schlgt Cisco zumindest in CCNA-Kursen vor, Standard-ACLs mglichst nah am Empfnger zu positionieren. Warum dieses? Nun, Standard-ACLs berprfen nur die Absender-IP-Adresse und filtern deswegen, wenn sie sich nah am Absender befinden, unter Umstnden mehr, als Sie es eigentlich wnschen. Stellen wir uns etwa vor, Fred und Barney sind durch vier Router voneinander getrennt. Wenn Sie die von Barney an Fred gesendeten Daten auf dem ersten Router filtern, erreicht Barney keine an die anderen drei Router angeschlossenen Hosts mehr. Aus diesem Grund wird im Cisco-ICND2-Kurs pauschal empfohlen, Standard-ACLs nher am Empfnger zu platzieren, damit Daten nicht flschlicherweise ausgefiltert werden. Indem spezifischere Vergleichsparameter weiter oben in der Liste platziert werden, wird die Mglichkeit von Fehlern in der ACL verringert. Stellen Sie sich etwa vor, eine Anweisung erlaubt uneingeschrnkten Datenverkehr von 10.1.1.1 an 10.2.2.2 ber Port 80 (das Web), und eine weitere Anweisung verweigert alle anderen Pakete, die aus dem Subnetz 10.1.1.0/24 stammen. Diese beiden Anweisungen entsprechen Paketen, die vom Host 10.1.1.1 an einen Webserver in 10.2.2.2 gesendet werden. Allerdings sollte die spezifischere Anweisung (permit) offenbar zuerst geprft werden. Generell hat die frhere Platzierung spezifischerer Anweisungen zur Folge, dass Sie keine Bedingung vergessen. Abschlieend empfiehlt Cisco, dass Sie die ACLs auf den Schnittstellen deaktivieren, bevor Sie die Anweisungen in der Liste ndern. Zum Glck fhrt, falls Sie mit ip access-group eine ACL auf einer Schnittstelle aktiviert haben und diese nun vollstndig lschen, IOS keine Filterung von Paketen mehr durch. (Das war bei frheren IOS-Versionen beileibe nicht immer der Fall!) Nichtsdestoweniger beginnt IOS mit dem Filtern von Paketen, sobald Sie einen Befehl zur ACL hinzufgen. Angenommen, Sie haben auf S0 die ACL 101 fr ausgehende Pakete aktiviert. Nun lschen Sie die ACL, damit alle Pakete wieder passieren knnen. Danach geben Sie den Befehl accesslist 101 ein. Sobald Sie die Eingabetaste bettigen, ist die Liste vorhanden, und der Router filtert alle S0 verlassenden Pakete basierend auf dieser einzeiligen Liste. Wenn Sie eine umfangreiche ACL eingeben wollen, filtern Sie unter Umstnden vorbergehend Pakete, die Sie gar nicht filtern wollen! Aus diesem Grund ist es besser, die Liste auf der Schnittstelle zu deaktivieren, die

Kapitel 6 IP-ACLs

335

erforderlichen nderungen vorzunehmen und die ACL dann wieder zu reaktivieren.

6.6.3

Reflexive ACLs

Reflexive ACLs auch als IP-Sitzungsfilter bezeichnet stellen eine Mglichkeit dar, eine bestimmte Form von Angriffen zu verhindern, indem jede TCP- oder UDP-Sitzung auf individueller Basis erlaubt wird. Zu diesem Zweck reagiert der Router, sobald er das erste Paket einer neuen Sitzung zwischen zwei Hosts erkennt. Er fgt dann eine permit-Anweisung zur ACL hinzu, die den Datenverkehr dieser Sitzung basierend auf der Absender- und der Ziel-IP-Adresse sowie auf dem TCP- bzw. UDP-Port gestattet. Abbildung 6.9 zeigt den klassischen Fall, in dem traditionelle ACLs eine Sicherheitslcke ffnen, die jedoch mit reflexiven ACLs geschlossen werden kann. Die meisten Unternehmen gestatten Benutzern die Verwendung eines Webbrowsers zur Verbindung mit Webservern im Internet. Eine traditionelle erweiterte ACL realisiert dies, indem sie Datenverkehr zwischen zwei beliebigen IP-Adressen zulsst, aber auf die Verwendung des von HTTP benutzten TCP-Ports (Port 80) hin prft. In diesem Fall zeigt die Abbildung eine ACL, die auf dem Absender-Port 80 auf im Unternehmen eintreffende Pakete prft also Pakete, die von einem Webserver stammen.
Angreifer

Internet

Unternehmen 128.107.1.1

R2 ACL Webserver access-list 101 permit tcp any eq www any Absender-Port Endbenutzer

Abbildung 6.9: Warum reflexive ACLs notwendig sind

Die auf R2 verwendete ACL filtert den gesamten eingehenden Datenverkehr mit Ausnahme von Daten, die von Webservern stammen. Auf diese Weise kann der Webserver im Internet (in der Abbildung links) Pakete an den Benutzer im Unternehmen (auf der rechten Seite) schicken. Allerdings knnte auch ein Angreifer Pakete mit dem Absender-Port 80 schicken, die der Router dann passieren liee. Zwar mssen diese Pakete unter Umstnden nicht Bestandteil einer vorhandenen TCP-Verbindung sein, aber es gibt Angriffsformen, die auf solchen Paketen basieren von einfachen DoS-Atta-

336

CCNA ICND2-Prfungshandbuch

cken durch berfluten des Unternehmensnetzes mit Paketen bis hin zum Ausnutzen bekannter Fehler im Betriebssystem. Reflexive ACLs gestatten Benutzern das Senden und Empfangen von Paketen ber den Router, whrend sie Pakete anderer Hosts (wie etwa des in Abbildung 6.9 gezeigten Angreifers) verwerfen. Bei Verwendung reflexiver ACLs wird, wenn der Benutzer im Unternehmen eine neue Sitzung beginnt, diese vom Router erkannt, und er vermerkt die Absender- und Ziel-IPAdressen sowie die verwendeten Ports. Die reflexive ACL auf R2 wrde nicht den gesamten auf Port 80 eingehenden Datenverkehr zulassen, sondern nur solche Pakete, deren Absender- und Zieladressen mit den Angaben im ersten Paket dieser Verbindung bereinstimmen. Wenn also der PC auf der rechten Seite eine Sitzung mit dem zulssigen Webserver (AbsenderPort 1030) einleitet, drfen aus dem Internet stammende Pakete R2 nur dann passieren, wenn sie die folgenden Eigenschaften aufweisen: AbsenderIP-Adresse 64.100.2.2, Ziel-IP-Adresse 128.107.1.1, Absender-Port 80, Ziel-Port 1030. Es knnen also nur Pakete dieser zulssigen Sitzung den Router passieren vom Angreifer stammende Pakete dagegen werden verworfen. Reflexive ACLs erfordern hnlich wie erweiterte ACLs mit Namen einen zustzlichen Konfigurationsaufwand.

6.6.4

Dynamische ACLs

Dynamische ACLs lsen ein anderes Problem, das sich mit traditionellen ACLs ebenfalls nicht ganz einfach beheben lsst. Stellen Sie sich eine ServerFarm vor, auf die eine kleine Gruppe von Benutzern zugreifen muss. Mit ACLs knnen Sie die IP-Adressen der von den Benutzern verwendeten Hosts vergleichen. Wenn sich ein Benutzer allerdings einen anderen PC borgt, eine neue Adresse via DHCP zugeteilt bekommt oder seinen Laptop mit nach Hause nimmt usw., hat er eine andere IP-Adresse. In diesem Fall msste eine traditionelle ACL editiert werden, um die jeweils neue IP-Adresse zu untersttzen. Im Laufe der Zeit kann die Pflege einer solchen ACL, die auf Vorhandensein einer dieser zahlreichen IP-Adressen hin prft, sehr aufwendig werden. Zudem knnten Sicherheitslcken entstehen, wenn die Hosts anderer Benutzer bereits zuvor vergebene IP-Adressen verwenden. Dynamische ACLs auch unter der Bezeichnung Lock-and-Key bekannt lsen dieses Problem, indem die ACL an einen Benutzerauthentifizierungsvorgang gekoppelt wird. Statt direkt eine Verbindung mit einem Server herzustellen, muss der Benutzer zunchst eine Telnet-Verbindung mit einem Router aufbauen. Der Router fordert dann eine Kombination aus Benutzername und Passwort an. Ist diese authentisch, so ndert der Router seine ACL

Kapitel 6 IP-ACLs

337

dynamisch. Dies bedeutet, dass Daten, die von der IP-Adresse des Hosts stammen, der die Authentifizierungspakete gesendet hat, zugelassen werden. Nach eine gewissen Zeit der Inaktivitt entfernt der Router den dynamischen Eintrag aus der ACL und schliet so die potenzielle Sicherheitslcke. Abbildung 6.10 veranschaulicht das Prinzip.
Benutzer Fred Barney Passwrter $36%12 995^#7

Angreifer 64.100.1.1

. . . Internet
1 4 Telnet Benutzerdaten R2 2

. . . Unternehmen
128.107.1.1

ACL
Barney 64.100.2.2

Webserver 3

ACL auf R2 vor der Authentifizierung access-list 101 permit any any eq telnet access-list 101 deny any any

ACL auf R2 nach der Authentifizierung access-list 101 permit host 64.100.2.2 any access-list 101 permit any any eq telnet access-list 101 deny any any

Abbildung 6.10: Dynamische ACLs

Der in der Abbildung gezeigte Vorgang beginnt damit, dass der Router alle Daten mit Ausnahme von Telnet-Daten abweist. (Zwar zeigt die Abbildung eine ACL, die Telnet-Verbindungen mit beliebigen IP-Adressen gestattet, doch in der Praxis mssen die Telnet-Daten lediglich fr eine IP-Adresse des Routers zugelassen werden.) Um den Vorgang zu starten, werden die folgenden Schritte durchgefhrt: 1. Der Benutzer stellt via Telnet eine Verbindung mit dem Router her. 2. Der Benutzer schickt eine Kombination aus Benutzername und Passwort, die der Router mit einer Liste vergleicht. Sind die Angaben richtig, wird der Benutzer authentifiziert. 3. Nach der Authentifizierung fgt der Router dynamisch einen Eintrag am Anfang der ACL ein, der vom authentifizierten Host kommende Daten zulsst. 4. Pakete, die vom zulssigen Host stammen, werden vom Router an den Server weitergeleitet.

338

CCNA ICND2-Prfungshandbuch

6.6.5

Zeitbasierte ACLs

Der Begriff der zeitbasierten ACLs verweist auf ein Feature normaler ACLs, bei denen sich eine zeitliche Beschrnkung konfigurieren lsst. Dies gilt fr numerische und benannte ACLs gleichermaen. In manchen Fllen kann es sinnvoll sein, einen Paketvergleich durch eine ACL nur zu bestimmten Tageszeiten oder Wochentagen durchzufhren. Zeitbasierte ACLs ermglichen Befristungen, die von IOS zum jeweils korrekten Zeitpunkt hinzugefgt oder entfernt werden.

6.7
6.7.1
Wichtig!

Aufgaben zur Prfungsvorbereitung


Wiederholung

Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind in der Randspalte mit dem entsprechenden Symbol gekennzeichnet. Tabelle 6.8 listet diese Themen sowie die Seitennummern auf, auf denen die Themen zu finden sind.
Tabelle 6.8: Schlsselthemen in Kapitel 6
Element Abbildung 6.2 Liste Tabelle 6.2 Liste Liste Liste Tabelle 6.3 Liste Abbildung 6.6 Liste Beschreibung Logikdiagramm fr ACLs Verarbeitung einer mehrzeiligen ACL durch einen Router Wildcard-Masken und deren Bedeutung Verkrzte Ermittlung von Adress- und Maskenparametern im access-list-Befehl Verkrzte Interpretation von Adresse und WildcardMaske im access-list-Befehl Checkliste fr die Planung und Konfiguration von ACLs Liste der mit Standard- und erweiterten ACLs vergleichbaren IP-Paketfelder Vergleich von TCP- und UDP-Ports mit ACLs Absender- und Ziel-Port und die entsprechende Position des Absender-Port-Parameters im access-list-Befehl Unterschiede zwischen Standard- und erweiterten ACLs Seite 303 305 306 308 308 310 316 318 319 321

Kapitel 6 IP-ACLs
Tabelle 6.8: Schlsselthemen in Kapitel 6 (Forts.)
Element Tabelle 6.7 Beschreibung Operatoren, die beim Vergleich von Port-Nummern in erweiterten access-list-Befehlen verwendet werden knnen Durch ACL-Sequenznummern bereitgestellte Funktionalitten fr nummerierte und benannte ACLs Empfehlungen fr ACLs gem den autorisierten CiscoCCNA-Kursen

339

Seite 321

Liste Liste

328 333

6.7.2

Vervollstndigen Sie die Listen und Tabellen

Drucken Sie aus Anhang J, Tabellen zur bung (auf der CD vorhanden), den Abschnitt zu diesem Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls auf der CD enthaltene Anhang K, Lsungen zu den bungen, enthlt die vollstndigen Tabellen und Listen, mit denen Sie Ihre Lsungen berprfen knnen.

6.7.3

Szenarien in Anhang F lesen

Anhang F, Weitere Szenarien, enthlt fnf detaillierte Szenarien, die Ihnen die Mglichkeit bieten, unterschiedliche Designs, Probleme und Befehlsausgaben zu analysieren, und Ihnen zeigen, wie Konzepte mehrerer unterschiedlicher Kapitel miteinander verwoben sind. Szenario 3 legt den Schwerpunkt auf IP-ACLs. Hier knnen Sie ben, wie man Wildcard-Masken so auswhlt, dass eine bereinstimmung mit allen Hosts in einem Subnetz erzielt wird.

6.7.4

Wichtige Definitionen

Definieren Sie die folgenden Schlsselbegriffe aus diesem Kapitel und berprfen Sie Ihre Antworten anhand des Glossars: ACL mit Namen, dynamische ACL, erweiterte ACL, reflexive ACL, Standard-ACLs, Wildcard-Maske

340

CCNA ICND2-Prfungshandbuch

6.7.5

Befehlsreferenz

Wir fhren an dieser Stelle eine Referenz fr die in diesem Kapitel behandelten Befehle aus dem Konfigurations- und dem EXEC-Modus an. Eigentlich sollten Sie die Befehle beim Studieren des Kapitels und beim Durchfhren der Aktivitten in diesem Abschnitt zur Prfungsvorbereitung quasi als Nebeneffekt bereits verinnerlicht haben. Um zu berprfen, wie gut Sie diese Befehle schon kennen, sollten Sie die linke Spalte der Tabelle mit einem Blatt Papier abdecken. Lesen Sie dann die Beschreibungen in der rechten Spalte und kontrollieren Sie, ob Sie den betreffenden Befehl kennen.
Tabelle 6.9: Referenz der Konfigurationsbefehle aus Kapitel 6
Befehl
access-list access-list-number {deny | permit} source [source-wildcard] [log] access-list access-list-number {deny | permit} protocol source sourcewildcard destination destinationwildcard [log] access-list access-list-number {deny | permit} tcp source sourcewildcard [operator [port]] destination destination-wildcard [operator [port]] [log] access-list access-list-number remark text ip access-group {number | name [in | out]} access-class number | name [in | out] ip access-list {standard | extended} name

Beschreibung Globaler Befehl fr nummerierte Standard-ACLs. Verwenden Sie eine Nummer zwischen 1 und 99 oder zwischen 1300 und 1999 (jeweils einschlielich). Globaler Befehl fr erweiterte nummerierte ACLs. Verwenden Sie eine Nummer zwischen 100 und 199 oder zwischen 2000 und 2699 (jeweils einschlielich). Version des access-list-Befehls mit TCP-spezifischen Parametern

Anmerkung/Kommentar (z. B. fr die vorgesehene Aufgabe der ACL) Schnittstellenbefehl zur Aktivierung von ACLs Aktivierung von Standard- oder erweiterten ACLs Globaler Befehl zur Konfiguration einer Standard- oder einer erweiterten ACL mit Namen. Nachfolgend wird in den ACL-Konfigurationsmodus gewechselt Befehl im ACL-Modus zur Konfiguration der Vergleichsparameter und der Aktion fr eine Standard-ACL mit Namen

{deny | permit} source [sourcewildcard] [log]

Kapitel 6 IP-ACLs
Tabelle 6.9: Referenz der Konfigurationsbefehle aus Kapitel 6 (Forts.)
Befehl {deny | permit} protocol source
source-wildcard destination destination-wildcard [log]

341

Beschreibung Befehl im ACL-Modus zur Konfiguration der Vergleichsparameter und der Aktion fr eine erweiterte ACL mit Namen Befehl im ACL-Modus zur Konfiguration der Vergleichsparameter und der Aktion fr eine ACL mit Namen passend fr TCP-Segmente Befehl im ACL-Modus zur Konfiguration einer Beschreibung fr eine benannte ACL

{deny | permit} tcp source sourcewildcard [operator [port]] destination destination-wildcard [operator [port]] [log]
remark text

Tabelle 6.10: Referenz der EXEC-Befehle aus Kapitel 6


Befehl
show ip interface [type number] show access-lists [access-listnumber | access-list-name] show ip access-list [access-listnumber ]

Beschreibung Enthlt Angaben zu den auf der Schnittstelle aktivierten ACLs. Zeigt Details zu konfigurierten ACLs fr alle Protokolle an. Zeigt ACLs an.

Dieses Kapitel behandelt die folgenden Themen


Die Befehle ping und traceroute Dieser Abschnitt erlutert, wie die Befehle ping und traceroute funktionieren, und beschreibt, wie sich Routing-Probleme mit ihrer Hilfe besser lsen lassen. Probleme bei der Paketweiterleitung beheben Dieser Abschnitt untersucht den Vorgang der Paketweiterleitung und legt den Schwerpunkt dabei auf das Host-Routing und die Frage, wie Router Pakete routen. Ferner werden hier Fragen zur Weiterleitung von Paketen in beiden Richtungen zwischen zwei Hosts behandelt. Tools und Tipps zur Problembehebung Dieser Abschnitt beschreibt eine Vielzahl von Themen, die mit dem Paketweiterleitungsvorgang in Zusammenhang stehen. Er enthlt zahlreiche Tipps zu verschiedenen Befehlen und Konzepten, die die Problembehebung erleichtern.

Kapitel 7
Troubleshooting beim IP-Routing
Dieses Kapitel zur Problembehebung verfolgt mehrere Ziele. Zunchst werden diverse Tools und Funktionen erlutert, die in den Kapiteln 4 bis 6 nicht behandelt wurden. Insbesondere geht es um Tools, die bei der Analyse von Problemen extrem hilfreich sein knnen. Auerdem werden in diesem Kapitel Themen aus den drei anderen Kapiteln in Teil II (IP-Routing) wiederholt. Diese Themen werden zu einem Vorgang zusammengefasst, der eine Empfehlung fr die Behebung von Routing-Problemen darstellt. Auerdem werden wir anhand von Beispielen veranschaulichen, wie dieser Prozess eingesetzt wird. In der zweiten Hlfte des Kapitels legen wir den Schwerpunkt dann auf eine Reihe von Tipps zur Problembehebung in Verbindung mit vielen bereits in den Kapiteln 4 bis 6 behandelten Themen.

7.1

berprfen Sie Ihren Wissensstand

In den Kapiteln zur Problembehebung werden in diesem Buch die Themen vieler anderer Kapitel zusammengefasst. Hierzu gehren auch Kapitel aus dem CCENT/CCNA ICND1-Prfungshandbuch. Ferner soll hier gezeigt werden, wie Sie einige der eher herausfordernden Aufgaben in den CCNAPrfungen angehen knnen. Deswegen ist es sinnvoll, diese Kapitel unabhngig davon zu lesen, wie umfassend Ihre Kenntnisse bereits sind. Aus diesen Grnden enthalten diese Kapitel auch keine Fragen zur Einschtzung des Wissensstandes. Sollten Sie jedoch der Meinung sein, dass Sie sich mit der Problembehebung beim IP-Routing, wie sie in diesem Buch sowie im CCENT/CCNA ICND1-Prfungshandbuch beschrieben wird, wirklich gut auskennen, dann knnen Sie gerne den Groteil dieses Kapitels berspringen und mit dem Abschnitt Aufgaben zur Prfungsvorbereitung am Ende des Kapitels fortfahren.

7.2

Wissensgrundlage

In diesem Kapitel liegt der Schwerpunkt auf der Behebung von Problemen in Verbindung mit dem IP-Routing. Insofern beginnen wir mit einem Abschnitt ber zwei wichtige Tools zur Fehlersuche: ping und traceroute. Danach wird

344

CCNA ICND2-Prfungshandbuch

der IP-Routing-Prozess aus der Sicht des Problemlsers untersucht, wobei wir uns hauptschlich darauf konzentrieren wollen, wie man Routing-Probleme eingrenzt, um ihre Grundursache zu ermitteln. Der letzte Abschnitt schlielich behandelt eine Vielzahl weniger wichtiger Themen, die bei der Behebung von Routing-Problemen jedoch alle ihren Sinn haben.

ANMERKUNG
Sowohl dieses Kapitel als auch Kapitel 15 im CCENT/CCNA ICND1-Prfungshandbuch erlutern Details zur Behebung von Routing-Problemen. Das IP-Routing ist sowohl fr die ICND1- und die ICND2-Prfung als auch fr die CCNA-Prfung von erheblicher Bedeutung, weswegen es berschneidungen bei diesen Prfungen und in der Folge in den Bchern gibt. Allerdings behandelt dieses Kapitel auch zahlreiche Themen, die ber die Details hinausgehen, die fr die ICND1-Prfung verlangt werden. Um umfassend vorbereitet zu sein, sollten Sie dieses Kapitel vollstndig lesen. Allerdings knnen Sie bestimmte Passagen beruhigt berspringen, wenn Sie den Eindruck haben, dass sich der Stoff aus dem ICND1-Buch lediglich wiederholt.

7.3

Die Befehle ping und traceroute

Dieser Abschnitt beschreibt eine empfohlene Vorgehensweise zur Behebung von Problemen beim IP-Routing, d. h. dem Vorgang auf der Datenebene, bei dem Hosts und Router IP-Pakete weiterleiten. Zu diesem Zweck wollen wir anfangs eine Reihe ntzlicher Tools und Protokolle untersuchen, darunter insbesondere ping, traceroute und ICMP. Danach erhalten Sie einen berblick ber die Behebung von IP-Problemen einschlielich einiger praktischer Beispiele.

7.3.1

ICMP

Die TCP/IP-Familie umfasst auch ICMP (Internet Control Message Protocol), ein Protokoll, dessen Zweck darin besteht, die Administration und Steuerung eines TCP/IP-Netzwerks zu erleichtern. Das ICMP-Protokoll stellt eine Vielzahl von Informationen zum System- und Betriebsstatus eines Netzwerks bereit. Control Message (Steuernachricht) ist dabei der aussagekrftigste Teil des Namens: ICMP hilft dabei, die Arbeit von IP zu steuern und zu verwalten, denn es definiert eine Anzahl von Nachrichten und Prozeduren fr den IP-Betrieb. Aus diesem Grund gilt ICMP als Bestandteil der Netzwerkschicht von TCP/IP. Weil ICMP die Steuerung von IP untersttzt, liefert es auch Informationen, die fr die Problembehebung ntzlich sein

Kapitel 7 Troubleshooting beim IP-Routing

345

knnen. Die ICMP-Nachricht sitzt in einem IP-Paket ohne Transportschicht-Header, das heit, ICMP ist in der Tat eine Erweiterung der TCP/IPNetzwerkschicht. Definiert ist ICMP in RFC 792. Der folgende Auszug aus RFC 792 beschreibt das Protokoll recht gut: Gelegentlich kommuniziert ein Gateway (Router) oder ein Ziel-Host mit einem Quell-Host, um etwa einen Fehler in der Datagrammverarbeitung zu melden. Fr solche Zwecke wird das Internet Control Message Protocol (ICMP) verwendet. ICMP verwendet die Grundfunktion von IP, so als ob es sich um ein bergeordnetes Protokoll handelt; tatschlich aber ist ICMP ein integraler Bestandteil von IP und muss von jedem IP-Modul implementiert werden. ICMP definiert mehrere verschiedene Nachrichtentypen, um seine vielfltigen Aufgaben erledigen zu knnen. Diese sind in Tabelle 7.1 zusammengefasst.
Tabelle 7.1: ICMP-Nachrichtentypen
Nachricht Destination Unreachable (Ziel nicht erreichbar) Time Exceeded (Zeitberschreitung) Redirect (Umleitung) Beschreibung Meldet dem Absender-Host, dass ein Problem bei der Auslieferung des Pakets aufgetreten ist. Die fr die Auslieferung eines Pakets zulssige Zeit wurde berschritten. Das Paket wurde verworfen. Der Router, der diese Nachricht sendet, hat ein Paket empfangen, fr das ein anderer Router ber eine bessere Route verfgt. Die Nachricht fordert den Absender auf, die bessere Route zu verwenden.
Wichtig!

Echo Request, Echo Reply Wird von ping zur berprfung der Konnektivitt (Echoanforderung/-antwort) verwendet.

Der Befehl ping und ICMP-Echoanforderungen und -antworten


Der Befehl ping verwendet ICMP-Echoanforderungen und -antworten. Wenn also jemand sagt, er versende ein Ping-Paket, dann meint er eigentlich, dass er eine ICMP-Echoanforderung abschickt. Diese beiden Nachrichten sind weitgehend selbsterklrend. Die Echoanforderung weist den Host, an den sie gesendet wird, lediglich an, auf das Paket zu antworten. Die Echoantwort ist der ICMP-Nachrichtentyp, der zur Beantwortung der Anforderung verwendet wird. Die Echoanforderung enthlt einige Daten, die mit dem ping-Befehl festgelegt werden knnen. Daten, die in der Echoanforderung bermittelt wurden, werden mit der Echoantwort zurckgeschickt.

346

CCNA ICND2-Prfungshandbuch

Der ping-Befehl selbst bietet viele kreative Mglichkeiten, Echoanforderungen und -antworten zu verwenden. So knnen Sie mit dem ping-Befehl etwa die Lnge des Pakets sowie die Absender- und Zieladressen festlegen, und weitere Felder im IP-Header knnen eingestellt werden. Kapitel 4, IP-Routing: Statische und direkt verbundene Routen, zeigt exemplarisch den erweiterten ping-Befehl, der verschiedene Optionen auflistet.

ICMP-Meldungen zur Nichterreichbarkeit


Schwerpunkt dieses Buches ist IP. Wenn Sie Ihren Blickwinkel jedoch ein wenig ndern, werden Sie feststellen, dass es Aufgabe aller TCP/IP-Protokolle ist, Daten von einer sendenden zu einer empfangenden Anwendung zu bermitteln. Hosts und Router melden deshalb ICMP-Nachrichten des Typs Destination Unreachable zurck an den sendenden Host, falls ein Host oder Router die Daten der Anwendung auf dem Weg zum Ziel-Host nicht zustellen kann. Um die Problembehebung zu erleichtern, enthlt die ICMP-Nachricht Destination Unreachable fnf separate Funktionen (oder Codes), die die Ursache der Nichtzustellung eines Pakets nher spezifizieren. Alle fnf Codetypen beziehen sich direkt auf ein IP-, TCP- oder UDP-Merkmal. Das in Abbildung 7.1 gezeigte Netzwerk soll uns das Verstndnis dieser Codes erleichtern. Nehmen wir an, Fred versucht, eine Verbindung mit dem Webserver namens Web herzustellen. (Web verwendet HTTP, welches seinerseits TCP als Transportschichtprotokoll einsetzt.) Drei der ICMP-Nichterreichbarkeitscodes knnten bei Bedarf von den Routern A und B verwendet werden. Die beiden anderen Codes knnten vom Webserver benutzt werden. Diese ICMP-Codes wrden an Fred gesendet, weil Fred der ursprngliche Absender des Pakets ist.
10.1.1.0/24 A 10.1.3.0/24 Web B 10.1.2.0/24

Fred

10.1.2.14

Abbildung 7.1: Beispielnetzwerk zur Beschreibung der ICMP-Nichterreichbarkeitscodes

Tabelle 7.2 fasst die im Normalfall benutzten ICMP-Nichterreichbarkeitscodes zusammen. Im Anschluss an die Tabelle wird erlutert, in welchen Situationen die einzelnen ICMP-Codes im in Abbildung 7.1 gezeigten Netzwerk gesendet werden.

Kapitel 7 Troubleshooting beim IP-Routing


Tabelle 7.2: ICMP-Nichterreichbarkeitscodes
Nichterreichbarkeits- Zeitpunkt des Einsatzes code Network Unreachable (Netzwerk nicht erreichbar) Host Unreachable (Host nicht erreichbar) In der Routing-Tabelle ist keine Route zum Empfnger des Pakets verzeichnet. Das Paket kann an einen Router geroutet werden, der mit dem Empfngersubnetz verbunden ist, aber der Host antwortet nicht.

347

Normaler Absender der Codenachricht Router

Router

Cant Fragment Im Paket ist das Flag Dont Fragment (Fragmentierung nicht gesetzt; der Router msste es aber fragmglich) mentieren, um es weiterleiten zu knnen.

Router

Protocol Unreachable Das Paket wurde an den Empfnger-Host Host (Protokoll nicht ausgeliefert, aber das Transportschichterreichbar) protokoll steht auf diesem Host nicht zur Verfgung. Port Unreachable Das Paket wurde an den Empfnger-Host Host (Port nicht erreichbar) ausgeliefert, aber der Ziel-Port wurde von einer Anwendung nicht geffnet.

Die folgende Liste erlutert die einzelnen Codes aus Tabelle 7.2 im Detail (als Beispiel dient das in Abbildung 7.1 gezeigte Netzwerk): Network Unreachable: Router A verwendet diesen Code, wenn er keine Route kennt, ber die er das Paket weiterleiten kann. Im vorliegenden Fall muss Router A das Paket in das Subnetz 10.1.2.0/24 routen. Kann er dies nicht, so sendet er an Fred den ICMP-Nichterreichbarkeitscode Network Unreachable als Reaktion auf das von Fred fr 10.1.2.14 vorgesehene Paket. Host Unreachable: Dieser Code impliziert, dass der verlangte Ziel-Host nicht verfgbar ist. Wenn Router A eine Route nach 10.1.2.0/24 kennt, wird das Paket an Router B weitergeleitet. Wenn die LAN-Schnittstelle von Router B aktiv ist, verfgt B ber eine angeschlossene Route nach 10.1.2.0/24 und versucht deswegen, via ARP die MAC-Adresse des Webservers zu erlernen. Sollte der Webserver allerdings ausgefallen sein, dann erhlt Router B keine ARP-Antwort aus dem Web. Router B sendet dann die Nachricht wegen Nichterreichbarkeit mit dem Code Host Unreachable. Dies bedeutet, dass B ber eine Route verfgt, aber das Paket nicht direkt an 10.1.2.14 weiterleiten kann. Cant Fragment: Dieser Code ist der letzte der drei Nichterreichbarkeitscodes, die von Routern gesendet werden. Der Begriff Fragmentierung

348

CCNA ICND2-Prfungshandbuch

definiert einen Vorgang, der auftritt, weil ein Router ein Paket weiterleiten soll, aber die ausgehende Schnittstelle nur Pakete weiterleiten kann, die kleiner sind als das vorliegende Paket. Der Router darf das Paket dann in kleinere Teile aufteilen (fragmentieren). Allerdings besteht die Mglichkeit, dass im Paket-Header das Dont Fragment-Bit gesetzt ist. In einem solchen Fall verwirft der Router das Paket, weil er es nicht fragmentieren darf und deswegen auch nicht weitersenden kann. Er sendet an Fred den Nichterreichbarkeitscode Cant Fragment. Protocol Unreachable: Wenn das Paket erfolgreich beim Webserver eintrifft, knnen noch zwei weitere Codes wegen Nichterreichbarkeit auftreten. Der Code Protocol Unreachable bedeutet, dass das IP bergeordnete Protokoll meist TCP oder UDP auf dem Host nicht ausgefhrt wird. Dies ist hchst unwahrscheinlich, weil die meisten Betriebssysteme, die TCP/IP verwenden, ein integriertes Softwarepaket einsetzen, das IP-, TCP- und UDP-Funktionen bietet. Wenn jedoch der Host das IP-Paket empfngt und TCP bzw. UDP nicht verfgbar sind, sendet der WebserverHost an Fred eine ICMP-Nichterreichbarkeitsnachricht mit dem Code Protocol Unreachable als Reaktion auf das von Fred an 10.1.2.14 gerichtete Paket. Port Unreachable: Dieser letzte Code tritt im Gegensatz zum vorherigen mit einer hheren Wahrscheinlichkeit auf. Wenn der Server der Computer in Betrieb ist, die Webserver-Software jedoch nicht ausgefhrt wird, gelangt das Paket zwar bis zum Server, kann aber nicht an die Server-Software ausgeliefert werden. Im Endeffekt horcht der Server also nicht auf dem Well-Known-Port des Anwendungsprotokolls. Aufgrund dessen sendet der Host 10.1.2.14 an Fred die ICMP-Nichterreichbarkeitsnachricht Code Port Unreachable als Reaktion auf das von Fred fr 10.1.2.14 vorgesehene Paket.

ANMERKUNG
Heutzutage filtern die meisten Sicherheitsrichtlinien diese verschiedenen Nachrichten wegen Nichterreichbarkeit aus, um das Sicherheitsprofil des Netzwerks zu strken. Die Antworten auf einen ping-Befehl fhren zu verschiedenen Reaktionen, die in manchen Fllen Rckschlsse darauf zulassen, welche ICMP-Nachricht wegen Nichterreichbarkeit empfangen wurde. Tabelle 7.3 zeigt verschiedene Codes, die auf einen ping-Befehl der Cisco IOS-Software angezeigt werden knnen.

Kapitel 7 Troubleshooting beim IP-Routing

349

Tabelle 7.3: Codes, die ping auf eine gesendete ICMP-Echoanforderung erhlt und anzeigt
Antwortcode
! . U N M ?

Beschreibung ICMP-Echoantwort empfangen Zeitberschreitung beim Warten auf eine Antwort ICMP-Unreachable-Nachricht (Ziel) empfangen ICMP-Unreachable-Nachricht (Netzwerk/Subnetz) empfangen ICMP-Cant Fragment-Nachricht empfangen Unbekanntes Paket empfangen

ICMP-Redirect-Nachrichten
ICMP-Nachrichten des Typs Redirect (Umleitung) bieten Routern die Mglichkeit, Hosts mitzuteilen, dass sie einen anderen Router als Default-Gateway fr bestimmte Zieladressen verwenden sollen. Die meisten Hosts verwenden das Konzept einer Default-Gateway-IP-Adresse und senden Pakete, die fr Subnetze vorgesehen sind, an ihr jeweiliges Default-Gateway. Wenn allerdings mehrere Router an dasselbe Subnetz angeschlossen sind, ist das Default-Gateway des Hosts unter Umstnden fr bestimmte Empfnger nicht der beste Router in diesem Subnetz. Das Default-Gateway kann erkennen, dass ein anderer Router besser geeignet ist. In diesem Fall sendet ICMP Redirect-Nachrichten an den Host, um ihm mitzuteilen, dass er Pakete an die betreffende Zieladresse doch zuknftig an diesen anderen Router senden mge. In Abbildung 7.2 etwa verwendet der PC den Router B als Default-Gateway. Die Route ber Router A in das Netz 10.1.4.0 ist jedoch besser. (Wir gehen dabei von der Verwendung der Subnetzmaske 255.255.255.0 in allen Subnetzen in Abbildung 7.2 aus.) Der PC sendet ein Paket an Router B (Schritt 1 in Abbildung 7.2). Router B leitet das Paket basierend auf seiner RoutingTabelle weiter (Schritt 2). Diese Route fhrt ber Router A, der ber eine bessere Route verfgt. Schlielich (Schritt 3) sendet Router B eine RedirectNachricht an den PC und weist ihn an, von nun an alle an 10.1.4.0 gerichteten Pakete an Router A zu schicken. Ironischerweise knnte der Host die Redirect-Nachricht nun ignorieren und die Pakete weiterhin an Router B senden; in unserem Beispiel jedoch akzeptiert er die Richtigkeit der Nachricht und sendet sein nchstes Paket (Schritt 4) direkt an den Router A.

350

CCNA ICND2-Prfungshandbuch
A Subnetz 10.1.4.0 Paket 1
t ke Pa

2 3 Redirect
t ke Pa 1

Abbildung 7.2: ICMP-Redirect

Die ICMP-Nachricht Time Exceeded


Die ICMP-Nachricht Time Exceeded benachrichtigt einen Host, wenn ein von ihm gesendetes Paket aufgrund einer Zeitberschreitung verworfen wurde. Fr Pakete erfolgt keine Zeitnahme im eigentlichen Sinne. Aber um zu verhindern, dass Pakete unbegrenzt weitergeleitet werden (falls eine Routing-Schleife vorhanden ist), enthlt der IP-Header ein TTL-Feld (Time to Live). Jedes Mal, wenn ein Router ein Paket weiterleitet, verringert er den TTL-Wert um 1. Wird dabei der Wert 0 erreicht, so wird das Paket verworfen. Abbildung 7.3 zeigt den grundlegenden Vorgang.
Fred A

ICMP-Redirect: Router A verwenden Host

Wichtig!

10.1.3.254 10.1.3.253 TTL = 5 TTL = 4 TTL = 3 TTL = 2 TTL = 1 TTL 1 = 0! Stopp! Paket wird verworfen B

Barney

10.1.2.14

ICMP-Dauer berschritten, TTL berschritten

Abbildung 7.3: Herabzhlen der TTL auf 0 (Routing-Schleife)

Kapitel 7 Troubleshooting beim IP-Routing

351

Wie Sie der Abbildung entnehmen knnen, sendet der Router, der das Paket verwirft, zustzlich eine Time Exceeded-Nachricht an den Absender-Host des Pakets. Auf diese Weise erfhrt der Absender, dass das Paket nicht ausgeliefert wurde. Auch bei der Problembehebung im Netzwerk lsst der Empfang einer Nachricht ber TTL = 0 Rckschlsse zu. Hoffen wir jedoch, dass Sie nicht allzu viele derartige Nachrichten erhalten, denn sonst haben Sie ein Routing-Problem.

7.3.2

Der Befehl traceroute

Der ping-Befehl ist ein leistungsfhiges Werkzeug, mit dem sich die Frage beantworten lsst, ob eine Route vorhanden ist. Der Befehl traceroute hingegen stellt unzweifelhaft ein noch besseres Tool dar, denn mit ihm lsst sich nicht nur ermitteln, ob eine Route funktioniert, sondern auch, wie sie verluft, denn die Ausgabe zeigt die IP-Adressen aller Router im Pfad. Funktioniert eine Route nicht, dann kann mithilfe von traceroute ermittelt werden, wo man am besten mit der Problembehebung beginnt. Der traceroute-Befehl ermittelt anhand der Time Exceeded-Nachricht und des TTL-Feldes alle Router, die Bestandteil der Route sind. Er sendet eine Anzahl von Nachrichten, bei denen sich beginnend mit 1 der TTL-Wert fortlaufend erhht. Dabei wird davon ausgegangen, dass diese Nachrichten verworfen werden, wenn ein empfangender Router den TTL-Wert auf 0 herunterzhlt; dann sendet der betreffende Router ICMP-Nachrichten wegen Zeitberschreitung an den Absender des Befehls traceroute zurck. Die Absender-IP-Adressen der Zeitberschreitungsnachrichten geben nun die Router an, die die Nachrichten verworfen haben. Diese Adressen werden in der Ausgabe von traceroute angezeigt. Um zu sehen, wie dieser Befehl funktioniert, betrachten wir die erste Gruppe von Paketen, die traceroute sendet (standardmig sind es drei Pakete). Bei diesen Paketen handelt es sich um IP-Pakete mit einer UDP-Transportschicht und dem TTL-Wert 1. Erreichen die Pakete den ersten Router, dann zhlt dieser den TTL-Wert auf 0 herunter, verwirft die Pakete und sendet die Zeitberschreitungsnachricht an den Absender-Host zurck. traceroute entnimmt dem Time Exceeded-Paket dann die Absender-IP-Adresse des ersten Routers. Als Nchstes sendet der Befehl traceroute eine zweite Gruppe mit drei IPPaketen, diesmal jedoch mit dem TTL-Wert 2. Der erste Router verringert diesen Wert auf 1 und leitet das Paket weiter, der zweite setzt den TTL-Wert auf 0 und verwirft das Paket. Danach sendet er Time Exceeded-Nachrichten zurck an den Router, auf dem der traceroute-Befehl abgesetzt worden war.

352

CCNA ICND2-Prfungshandbuch

Aufgrund dessen kennt traceroute nun auch den zweiten Router in der Route.
traceroute erkennt, dass die Testpakete beim Ziel-Host eintreffen, weil der Host eine ICMP-Nichterreichbarkeitsnachricht mit dem Code Port Unreachable zurcksendet. Die ursprnglich von traceroute gesendeten Pakete verwenden eine UDP-Ziel-Port-Nummer, bei der die Wahrscheinlichkeit einer Verwendung auf dem Ziel-Host extrem gering ist. Wenn nun also der TTL-Wert gro genug ist, damit das Paket den Ziel-Host erreichen kann, stellt der Host fest, dass er keine Anwendung ausfhrt, die auf dem betreffenden UDP-Port horcht. Also schickt der Ziel-Host eine Port UnreachableNachricht, der traceroute entnehmen kann, dass die gesuchte Route vollstndig ermittelt wurde und traceroute die Bearbeitung nun beenden kann.

Abbildung 7.4 zeigt ein Beispiel, allerdings (um die bersicht nicht zu gefhrden) nur mit einer der drei Nachrichten pro TTL-Wert. Router A versucht, mithilfe von traceroute die Route zu Barney zu finden. Listing 7.1 zeigt diesen traceroute-Befehl auf Router A sowie Debug-Nachrichten von Router B sowie die drei resultierenden Time Exceeded-Nachrichten.
trace 10.1.2.14
Wichtig!

Fred A

10.1.3.254 10.1.3.253 B

Barney

10.1.2.14 TTL = 1

IP

UDP

Daten

ICMP-TTL berschritten

TTL = 2

IP

UDP

Daten

TTL = 1

IP

UDP

Daten

Zielport randomisiert
ICMP-Port nicht erreichbar

Zielport randomisiert
ICMP-Port nicht erreichbar

Abbildung 7.4: traceroute-Befehl in der Cisco IOS-Software: generierte Nachrichten

Kapitel 7 Troubleshooting beim IP-Routing

353

Listing 7.1: ICMP-Debugging auf Router B beim Ausfhren von traceroute auf Router A
RouterA#traceroute 10.1.2.14 Type escape sequence to abort. Tracing the route to 10.1.2.14 00000000000000 msec 4 msec 4 msec 1 10.1.3.253 8 00000000000000 msec 8 msec 4 msec 2 10.1.2.14 12 RouterA# ! Weiter geht es mit Router B ! Die folgende Ausgabe erscheint infolge des traceroute-Befehls RouterB#debug ip icmp RouterB# ICMP: time exceeded (time to live) sent to 10.1.3.254 (dest was ICMP: time exceeded (time to live) sent to 10.1.3.254 (dest was ICMP: time exceeded (time to live) sent to 10.1.3.254 (dest was

auf A:

10.1.2.14) 10.1.2.14) 10.1.2.14)

Der Befehl traceroute fhrt die IP-Adresse von Router B in der ersten und die IP-Adresse des Ziel-Hosts in der zweiten Zeile auf. Beachten Sie, dass hier die IP-Adresse der seriellen Schnittstelle auf der linken Seite von Router B angezeigt wird. B antwortet mit der Time Exceeded-Nachricht und verwendet in diesem Paket als Absenderadresse die IP-Adresse der ausgehenden Schnittstelle von Router B. Infolgedessen fhrt traceroute diese IP-Adresse auf. Wenn die Adresse einem DNS-Server bekannt ist oder sich in der Hostnamens-Tabelle von Router A befindet, kann der Befehl statt der IP-Adresse auch den Hostnamen ausgeben. hnlich wie der im Abschnitt Der erweiterte ping-Befehl in Kapitel 4 beschriebene erweiterte ping-Befehl leistet die erweiterte Version von traceroute wesentlich bessere Arbeit bei der Simulation von Paketen, die an einen Ziel-Host gesendet werden (dies gilt insbesondere fr die Verifizierung von Routen in Gegenrichtung). So verwendet in Listing 7.1 der Befehl traceroute auf A die IP-Adresse 10.1.3.254 als Absenderadresse, weil A diese Schnittstelle fr den Versand von Paketen benutzt, die von traceroute generiert werden. Insofern testet traceroute in Listing 7.1 die Route nach 10.1.2.14 und die Rckroute nach 10.1.3.254. Mithilfe des erweiterten traceroute-Befehls kann man eine geeignetere Rckroute testen, z. B. die zurckfhrende Route in das LAN-Subnetz auf der linken Seite von Router A. Das weiter unten aufgefhrte Listing 7.2 zeigt ein Beispiel fr den erweiterten tracerouteBefehl.

354

CCNA ICND2-Prfungshandbuch

ANMERKUNG
Der Befehl tracert unter Microsoft-Betriebssystemen funktioniert weitgehend wie der IOS-Befehl traceroute. Allerdings ist es wichtig anzumerken, dass tracert ICMP-Echoanforderungen sendet und UDP nicht verwendet. Insofern knnten traceroute-Befehle aufgrund von ACLs in Fllen fehlschlagen, in denen tracert funktioniert und umgekehrt.

7.4

Probleme bei der Paketweiterleitung beheben

Die Behebung von Problemen im IP-Routing-Prozess ist eine der komplexeren Aufgaben, mit denen ein Netzwerktechniker konfrontiert wird. Wie blich ist auch hier ein strukturierter Ansatz hilfreich. Besonders in Kapitel 4 aber auch in den Kapiteln 5 und 6 wurde bereits der erste wichtige Teil der Problembehebung erlutert, denn es wurde gesagt, wie das Netzwerk funktionieren sollte. In diesem Abschnitt konzentrieren wir uns auf den zweiten wichtigen Schritt: die Eingrenzung von Problemen. (Eine allgemeine Beschreibung von Techniken zur Fehlersuche finden Sie in Kapitel 3, Troubleshooting beim LAN-Switching.)

ANMERKUNG
Die Details zur Behebung von Problemen in Verbindung mit Routing-Protokollen finden Sie in Kapitel 11, Troubleshooting bei Routing-Protokollen.

7.4.1

Hostbezogene Routing-Probleme eingrenzen

Der in diesem Kapitel dargestellte Vorgang unterteilt die Schritte zur Problembehebung in zwei Teile: einen fr Hosts und einen zweiten fr Router. Im Wesentlichen untersucht der erste Teil dieses Vorgangs bei allen Situationen, in denen zwei Hosts nicht kommunizieren knnen, ob die Fhigkeit der jeweiligen Hosts zum Versenden von Paketen an das zugehrige DefaultGateway (und zurck) beeintrchtigt ist. Der zweite Teil grenzt dann Probleme der Router ein, Pakete weiterzuleiten.

Kapitel 7 Troubleshooting beim IP-Routing

355

Die folgende Liste skizziert die Schritte, die erforderlich sind, um die Konnektivitt zwischen Host und erstem Router zu testen: 1. berprfen Sie die Fhigkeit des Hosts, Pakete in das eigene Subnetz zu schicken. Senden Sie entweder vom Host aus einen ping-Befehl an die IPAdresse des Default-Gateways oder aber vom Default-Gateway aus an die IP-Adresse des Hosts. Schlgt der ping-Befehl fehl, dann berprfen Sie Folgendes: a) Stellen Sie sicher, dass die auf dem Default-Gateway verwendete Router-Schnittstelle sich im Zustand up/up befindet. b) Vergleichen Sie IP-Adresse und Subnetzmaske des Absender-Hosts mit der Schnittstelle des Routers, die als Default-Gateway verwendet wird. Vergewissern Sie sich, dass die Angaben zu Subnetzadresse und Maske bei beiden identisch sind, was auch eine bereinstimmung hinsichtlich des Bereichs gltiger Adressen im Subnetz bedingt. c) Wenn der Router VLAN-Trunking einsetzt, beheben Sie gegebenenfalls vorhandene Probleme mit der Trunk-Konfiguration. Stellen Sie sicher, dass der Router so konfiguriert ist, dass er dasselbe VLAN untersttzt, in dem der Host sich befindet. d) Sofern die brigen Schritte nicht zum Erfolg fhren, prfen Sie auf vorhandene Probleme hin in den Schichten 1 und 2 des LAN, wie in Kapitel 3 behandelt. Sie knnen beispielsweise nach einem undefinierten VLAN Ausschau halten. 2. Verifizieren Sie die Default-Gateway-Einstellung auf dem Host, indem Sie einen ping-Befehl an die IP-Adresse einer anderen Schnittstelle des Default-Gateways senden. Alternativ senden Sie auf dem Default-Gateway einen erweiterten ping-Befehl an die IP-Adresse des Hosts, wobei Sie als Absender eine andere Schnittstelle des Routers verwenden. In Abbildung 7.5 beispielsweise knnten die Symptome des Problems darin bestehen, dass PC1 den Webserver auf PC4 nicht kontaktieren kann. Um die Fhigkeit von PC1 zu testen, Pakete ber sein lokales Subnetz zu schicken, knnte PC1 mit dem Befehl ping 10.1.1.1 die Konnektivitt zum DefaultGateway im selben Subnetz berprfen. Alternativ knnte der Netzwerktechniker auch einfach ping 10.1.1.10 auf R1 absetzen (Schritt 1). Beide Ausgangspunkte fr den ping-Befehl sind gleichermaen geeignet, denn in jedem Fall wird ein Paket in jede Richtung gesendet. Wenn der ping-Befehl fehlschlgt, sollten die Schritte 1a bis 1c eine weitere Problemeingrenzung ermglichen. Andernfalls liegt das Problem wie in Kapitel 3 wahrscheinlich in den Schichten 1 oder 2 begrndet.
Wichtig!

356

CCNA ICND2-Prfungshandbuch

Default-Gateway 10.1.1.1 PC1


FA0/0 10.1.13.1 S0/0/1 10.1.13.3 172.16.1.4

SW1
10.1.1.10

10.1.1.1

R1

R3 PC2
FA0/0 10.1.23.2 S0/0/0 10.1.23.3 S0/1/0

172.16.1.3 FA0/0

R4
172.16.2.4

SW2
10.1.0.10

10.1.0.2

R2

SW4

172.16.2.7

PC4

Abbildung 7.5: Beispielnetzwerk fr Problembehebungsszenarien

Schritt 2 betont ein hufig bersehenes Problem: Es ist die Frage, ob die Default-Gateway-Einstellung auf dem PC funktioniert. Keine der in Schritt 1 aufgefhrten ping-Optionen verlangt vom Host die Verwendung dieser Default-Gateway-Einstellung, weil sich die Absender- und die Empfngeradresse in den Paketen im selben Subnetz befinden. Schritt 2 zwingt den Host, ein Paket an eine IP-Adresse in einem anderen Subnetz zu senden, und testet so dessen Default-Gateway-Einstellung. Auerdem blendet dieser Schritt die Komplexitt des IP-Routings in diesem Test aus, denn es wird ein ping-Befehl an eine IP-Adresse auf dem Default-Gateway (Router) und nicht an eine weit entfernte Host-IP-Adresse gesendet. Der Schwerpunkt in diesem Schritt liegt also darauf festzustellen, ob die Default-Gateway-Einstellung funktioniert. In Abbildung 7.5 beispielsweise zwingt der Befehl ping 10.1.13.1 den PC1 dazu, seine Default-Gateway-Einstellung zu verwenden, da sich 10.1.13.1 nicht im Subnetz von PC1 (10.1.1.0/24) befindet. Die IPAdresse befindet sich jedoch auf dem Router R1, wodurch das verbleibende Netzwerk als mgliche Ursache eines fehlgeschlagenen ping-Befehls entfllt.

7.4.2

Router-bezogene Routing-Probleme eingrenzen

Wenn die Host-bezogene Eingrenzung des Problems abgeschlossen ist und alle ping-Befehle auf allen sendenden und empfangenden Hosts funktionieren, sollten die Ursachen aller verbleibenden IP-Routing-Probleme zwischen dem ersten und dem letzten Router auf der Hin- oder der Rckroute liegen. Die folgende Liste nimmt die Fehlersuche am Default-Gateway/Router des Absender-Hosts wieder auf und nutzt dabei den traceroute-Befehl auf dem

Kapitel 7 Troubleshooting beim IP-Routing

357

Router. Beachten Sie, dass auch quivalente Befehle auf dem Hosts z. B. Microsofts tracert verwendet werden knnen.

ANMERKUNG
Die folgende Liste mag zum Nachschlagen ntzlich sein, ist aber recht umfangreich. Verstricken Sie sich nicht in Details, sondern lesen Sie die folgenden praktischen Beispiele, denn hierdurch sollten die durchgefhrten Schritte offensichtlich werden. Wie gewhnlich mssen Sie keinen der hier aufgefhrten Schritte auswendig lernen. Sie sind eher als Lernwerkzeuge gedacht, mit denen Sie Ihre Fertigkeiten vervollkommnen sollen. 3. Testen Sie die Konnektivitt zum Ziel-Host durch Verwendung des erweiterten traceroute-Befehls auf dem Default-Gateway des Hosts. Als IPAdresse der Pakete verwenden Sie die mit dem Absender-Host verbundene Router-Schnittstelle. Falls der Befehl erfolgreich ausgefhrt wird, gilt: a) Es sind keine Routing-Probleme auf der Hin- und der Rckroute vorhanden. b) Lassen sich die Daten des Benutzers trotzdem nicht bertragen (obwohl traceroute funktioniert), dann berprfen Sie die auf den Schnittstellen der Router im Pfad vorhandenen ACLs fr beide Richtungen. 4. Wenn der traceroute-Befehl in Schritt 3 nicht erfolgreich abgeschlossen wird, testen Sie die Vorwrtsroute wie folgt: a) Starten Sie eine Telnet-Sitzung mit dem letzten erkannten Router (d. h. dem letzten in der traceroute-Ausgabe angezeigten Router). b) Ermitteln Sie die Route dieses Routers zu der Ziel-IP-Adresse, die im ursprnglichen traceroute-Befehl verwendet wurde (show ip route, show ip route ip-address). c) Wird keine passende Route gefunden, dann untersuchen Sie, warum die erwartete Route fehlt. In der Regel handelt es sich entweder um ein Problem mit dem Routing-Protokoll oder eine fehlkonfigurierte statische Route. Auch eine fehlende direkt verbundene Route knnte die Ursache sein. d) Wird eine passende Route gefunden und handelt es sich um eine Default-Route, so kontrollieren Sie mithilfe der beiden Befehle ip classless und no ip classless, ob diese Route auch verwendet wird. e) Wird eine passende Route gefunden, dann senden Sie einen pingBefehl an die IP-Adresse des nchsten Hops, der in der Route aufge-

Wichtig!

358

CCNA ICND2-Prfungshandbuch fhrt ist. Handelt es sich um eine direkt verbundene Route, so senden Sie den ping-Befehl an die tatschliche Ziel-IP-Adresse. Schlgt der ping-Befehl fehl, so prfen Sie auf Vorhandensein von Schicht-2-Problemen zwischen diesem Router und der Ziel-IPAdresse des ping-Befehls sowie auf mgliche ACL-Probleme hin. Funktioniert der ping-Befehl, so prfen Sie auf Vorhandensein von ACL-Problemen hin, die zum Beispiel UDP betreffen knnen.

f) Wird eine passende Route gefunden und lassen sich keine anderen Probleme feststellen, so berprfen Sie, ob die Route nicht flschlicherweise in die falsche Richtung weist. 5. Lsst sich in Schritt 4 kein Problem auf der Route zum Ziel erkennen, dann mssen Sie die Rckroute testen: a) Wenn die Vorwrtsroute auf dem letzten mit traceroute ermittelten Router auf einen anderen Router als nchsten Hop verweist, wiederholen Sie die Manahmen von Schritt 3 auf diesem nchsten Router in die umgekehrte Richtung. Analysieren Sie die Rckroute, also die Route, mit der sich die Absender-IP-Adresse des fehlgeschlagenen traceroute-Befehls erreichen lsst. b) Wenn die Vorwrtsroute auf dem letzten erkannten Router auf ein angeschlossenes Subnetz verweist, berprfen Sie die IP-Einstellungen auf dem Ziel-Host. Achten Sie dabei insbesondere auf die Einstellungen von IP-Adresse, Subnetzmaske und Default-Gateway. Wenn beispielsweise PC1 in Abbildung 7.5 nicht mit PC4 kommunizieren kann, die Kommunikation ber ihre jeweiligen Default-Gateways jedoch mglich ist, knnte Schritt 3 der Router-bezogenen Problemeingrenzung mit einem Befehl traceroute 172.16.2.7 beginnen, der die IP-Adresse der Schnittstelle Fa0/0 von R1 (10.1.1.1) als Absenderadresse verwendet. Fhrt dieser traceroute-Befehl, statt abgeschlossen zu werden, 10.1.13.3 als letzte IPAdresse in der Befehlsausgabe auf, so wrden Sie mit Schritt 4 fortfahren, in dem die Vorwrtsroute von R3 nach 172.16.2.7 untersucht wird. Lsst sich das Problem mit Schritt 4 nicht ermitteln, so wrden Sie in Schritt 5 mit dem nchsten Router im Pfad in diesem Fall R4 fortfahren und die Rckroute von R4 untersuchen, d. h. die Route zurck zu der ursprnglichen Absenderadresse 10.1.1.1. Nun wollen wir anhand zweier separater Szenarien zeigen, wie man Probleme mithilfe dieser Vorgehensweise behebt.

Kapitel 7 Troubleshooting beim IP-Routing

359

Szenario 1: Problem in der Vorwrtsroute


Das erste Beispiel der Router-Problembehebung verwendet ebenfalls das in Abbildung 7.5 gezeigte Netzwerk. In diesem Fall kann PC1 mithilfe eines Webbrowsers keine Verbindung zu dem auf PC4 laufenden Webdienst herstellen. Wie wir durch eine weitere berprfung feststellen, kommt auch kein ping-Befehl bis zu 172.16.2.7 (PC4) durch. Listing 7.2 zeigt die auf R1 und R4 verwendeten Befehle fr die Schritte 1 und 2 der Host-Analyse sowie den Anfang von Schritt 3 zur Eingrenzung auf dem Router.
Listing 7.2: Szenario 1: Schritte 1 und 2 sowie der Anfang von Schritt 3
R1#ping 10.1.1.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max R1#ping Protocol [ip]: Target IP address: 000000000 10.1.1.10 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 000000000 10.1.13.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 Packet sent with a source address of 10.1.13.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max R1# ! Nun wird der Test auf R4 wiederholt. R4#ping 172.16.2.7

seconds: = 1/2/4 ms

seconds:

= 1/2/4 ms

Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.7, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

360

CCNA ICND2-Prfungshandbuch

Listing 7.2: Szenario 1: Schritte 1 und 2 sowie der Anfang von Schritt 3 (Forts.)
R4#show ip interface Interface FastEthernet0/0 FastEthernet0/1 Serial0/0/0 Serial0/0/1 Serial0/1/0 brief IP-Address 172.16.2.4 172.16.1.4 unassigned unassigned unassigned OK? Method Status YES manual administratively YES manual up YES unset administratively YES unset administratively YES unset administratively Protocol down down up down down down down down down

Die normalen und erweiterten ping-Befehle auf R1 am Anfang des Beispiels dienen im Wesentlichen der Durchfhrung der Schritte 1 und 2, also der Host-bezogenen Schritte, mit denen berprft wird, ob PC1 einwandfrei arbeitet. Allerdings zeigt das Listing dann, dass R4 den PC4 nicht erreichen kann, weil die LAN-Schnittstelle von R4 abgeschaltet wurde (wie wir am Ende des Listings erfahren). Dieses Szenario mag zwar ein wenig simpel erscheinen, stellt aber einen guten Ausgangspunkt zur Behebung des Problems dar. Um einen umfassenderen Blick auf die Problembehebung zu erhalten, wollen wir uns nun dasselbe Szenario ansehen; diesmal allerdings haben wir keinen Zugriff auf R4. Wir knnen zwar zunchst einmal die Schritte 1 und 2 fr PC1 durchfhren (die auch funktionieren), aber fr PC4 lassen sich dieselben Schritte nicht von R4 aus vollziehen. Insofern fhrt Listing 7.3 mit den Schritten 3 und 4 fort. Den Anfang des Listings zeigt Schritt 3, wo R1 den Befehl traceroute 172.16.2.7 mit der Absenderadresse 10.1.1.1 absetzt. Der Befehl wird nicht abgeschlossen, wobei 10.1.13.3 (R3) als letzter Router angegeben wird. Schritt 4 berprft nachfolgend, wie R3 Pakete routet, die fr 172.16.2.7 vorgesehen sind.
Listing 7.3: Szenario 1: Schritt 4
R1#traceroute Protocol [ip]: Target IP address: 0000000000 172.16.2.7 Source address: 00000000 10.1.1.1 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 172.16.2.7

Kapitel 7 Troubleshooting beim IP-Routing


Listing 7.3: Szenario 1: Schritt 4 (Forts.)

361

1 10.1.13.3 0 msec 4 msec 0 msec 2 10.1.13.3 !H * !H ! Beachten Sie oben, dass der Befehl von selbst beendet wurde, ohne den ! Zielhost 172.16.2.7 ausgegeben zu haben. R3#show ip route 172.16.2.7 000000000000000000000000 % Subnet not in table R3#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 1 subnets 172.16.1.0 is directly connected, FastEthernet0/0 10.0.0.0/24 is subnetted, 4 subnets 10.1.13.0 is directly connected, Serial0/0/1 10.1.1.0 [120/1] via 10.1.13.1, 00:00:04, Serial0/0/1 10.1.0.0 [120/1] via 10.1.23.2, 00:00:01, Serial0/1/0 10.1.23.0 is directly connected, Serial0/1/0

C C R R C

Der erweiterte traceroute-Befehl am Anfang des Listings zeigt in der Ausgabe R3 (10.1.13.3) als letztes erkanntes Gert (Schritt 3). Schritt 4 fhrt dann mit eine berprfung der Vorwrtsroute von R3 zur IP-Adresse 172.16.2.7 fort. Der Befehl show ip route 172.16.2.7 bringt uns direkt zum Ziel. Die Meldung subnet not in table bedeutet, dass R3 keine zur Zieladresse 172.16.2.7 passende Route kennt. Wenn eine Aufgabe keinen Zugang zum Simulator bietet, sondern nur die Ausgabe des show ip route-Befehls zeigt, mssten Sie die Routen untersuchen. Es knnte sein, dass keine von ihnen auf einen Adressbereich verweist, der 172.16.2.7 enthlt. Immer wenn am Ende der Problemeingrenzung eine fehlende Route steht, besteht der nchste Schritt darin zu ermitteln, wie der Router diese Route eigentlich erlernen sollte. In diesem Fall htte R3 RIPv2 zum Erlernen verwenden mssen. Der nchste Schritt bei der Problembehebung bestnde nun darin, das dynamische Routing-Protokoll zu berprfen. Die Hauptursache dieses Problems die auf R4 abgeschaltete Schnittstelle Fa0/0 hat sich nicht gendert, doch sind die Symptome recht interessant. Da die Schnittstelle abgeschaltet ist, weist R4 gegenber R3 keine Route fr

362

CCNA ICND2-Prfungshandbuch

das Subnetz 172.16.2.0/24 aus. R3 hingegen gibt gegenber R1 und R2 eine automatisch summierte Route zum Netzwerk 172.16.0.0/16 bekannt, das heit, R1 und R2 knnen (aufgrund der bei RIPv2 standardmig aktiven Autosummierung) fr 172.16.2.7 vorgesehene Pakete an R3 schicken. Also kann auch der traceroute-Befehl von R1 Pakete an R3 weiterleiten.

Szenario 2: Problem in der Rckroute


Das nachfolgende Beispiel basiert ebenfalls auf dem in Abbildung 7.5 gezeigten Netzdiagramm, wobei alle dort gezeigten Angaben nach wie vor zutreffen. Allerdings haben sich die im vorherigen Abschnitt erwhnten Details teilweise gendert. Dies betrifft in erster Linie das Problem, welches vorhanden ist, um das Beispiel interessanter zu machen. Insofern sollten Sie dieses zweite Problem nur auf der Basis der genannten Abbildung betrachten. In diesem Szenario kommt erneut kein ping-Befehl bis zu 172.16.2.7 (PC4) durch. Die in den Schritten 1 und 2 vorgeschlagenen berprfungen zum Default-Gateway des Hosts sind fr PC1 erfolgreich, doch in umgekehrter Richtung lassen sich keine Tests durchfhren, da ein Zugriff weder auf PC4 noch auf R4 besteht. Mithin nimmt Listing 7.4 den Faden bei Schritt 3 des Problembehebungsvorgangs auf und zeigt das Ergebnis des erweiterten traceroute-Befehls auf R1. Beachten Sie, dass der Befehl in diesem Fall die IPAdresse von R3 (10.1.13.3) nicht einmal angibt. Der verbleibende Teil von Listing 7.4 zeigt also die Manahmen, die aufgrund der einzelnen Teile von Schritt 4 durchgefhrt werden.
Listing 7.4: Szenario 2: Schritte 3 und 4
R1#traceroute ip 172.16.2.7 source fa0/0 0000000000000000000000000000000000000 Type escape sequence to abort. Tracing the route to 172.16.2.7 1 * * * 2 * * * 3 * R1#show ip route 172.16.2.7 Routing entry for 172.16.0.0/16 0000000000000 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 10.1.13.3 on Serial0/1/0, 00:00:05 ago Routing Descriptor Blocks: * 10.1.13.3, from 10.1.13.3, 00:00:05 ago, via Serial0/1/0 000000000 Route metric is 1, traffic share count is 1

Kapitel 7 Troubleshooting beim IP-Routing


Listing 7.4: Szenario 2: Schritte 3 und 4 (Forts.)
R1#ping 10.1.13.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.13.3, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms R1#show ip access-lists 00000000000000000000 ! Weiter geht es mit Router R3 R3#show ip access-lists 000 R3#

363

Das Listing zeigt anfangs Schritt 3 des Vorgangs, wobei der tracerouteBefehl nur Sterne auflistet. Das bedeutet, dass der Befehl noch nicht einmal den nchsten Router im Pfad erfolgreich erkennen konnte. Nun fahren wir mit Schritt 4 fort. Die folgende Liste zeigt die einzelnen Manahmen dieses Schrittes, wie sie hier zum Einsatz kommen: a) Die Telnet-Verbindung zu R1 wurde bereits anfangs hergestellt, weswegen keine weiteren Schritte notwendig sind. b) Der nchste Befehl show ip route 172.16.2.7 zeigt, dass R1 ber eine in das Netzwerk 172.16.0.0 fhrende Nicht-Default-Route verfgt, die R3 (10.1.13.3) als nchsten Hop angibt. c) Dieser Schritt ist in diesem Fall nicht anwendbar, da zuvor eine passende Route gefunden wurde. d) Dieser Schritt ist ebenfalls nicht anwendbar, weil die passende Route keine Route nach 0.0.0.0/0 (Default-Route) ist. e) Der nchste aufgefhrte Befehl ping 10.1.13.3 testet die Fhigkeit von R1, Pakete ber die Verbindung an den in Schritt 4b ermittelten nchsten Router im Pfad zu senden. Der ping-Befehl funktioniert. f) Auf R1 und dem nachfolgenden Router R3 zeigt der Befehl show ip access-lists jeweils an, dass keine ACLs auf den Routern konfiguriert wurden. Da alle Schritte zur berprfung der Vorwrtsroute abgeschlossen wurden, fhrt die Ermittlung jetzt mit Schritt 5 fort. Der ursprngliche tracerouteBefehl in Listing 7.4 verwendete die IP-Adresse der Schnittstelle Fa0/0 von R1 als Absenderadresse. In Schritt 5 beginnt die Fehlersuche bei R3. Hier wird zunchst analysiert, wie die Rckroute von R3 nach 10.1.1.1 verluft.

364

CCNA ICND2-Prfungshandbuch

Betrachten Sie die Ausgabe in Listing 7.5 und suchen Sie nach mglichen Problemen, bevor Sie weiterlesen.
Listing 7.5: Szenario 2: Schritt 5
! Der nchste Befehl zeigt die passende Route fr das Subnetz 10.1.1.0/26 ! mit dem nchsten Hop 10.1.23.2. R3#show ip route 10.1.1.1 Routing entry for 10.1.1.0/26 00000000000 Known via "static", 000000000000000000 distance 1, metric 0 Routing Descriptor Blocks: * 000000000 10.1.23.2 Route metric is 0, traffic share count is 1 ! Der nchste Befehl zeigt die berlappenden Subnetze: 10.1.1.0/26 und 10.1.1.0/24. R3#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 172.16.0.0/24 is subnetted, 2 subnets 172.16.1.0 is directly connected, FastEthernet0/0 172.16.2.0 [120/1] via 172.16.1.4, 00:00:18, FastEthernet0/0 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks 10.1.13.0/24 is directly connected, Serial0/0/1 10.1.1.0/26 [1/0] via 10.1.23.2 10.1.1.0/24 [120/1] via 10.1.13.1, 00:00:10, Serial0/0/1 10.1.0.0/24 [120/1] via 10.1.23.2, 00:00:11, Serial0/1/0 10.1.23.0/24 is directly connected, Serial0/1/0

C R C S R R C

R3 verfgt ber eine falsch konfigurierte statische Route zum Subnetz 10.1.1.0/26. Dieses Subnetz enthlt den Adressbereich 10.1.1.0 bis 10.1.1.63, der auch die IP-Adresse 10.1.1.1 enthlt. Wenn R3 nun versucht, ein Paket zurck an 10.1.1.1 zu schicken, gibt es zwei Routen, die der Zieladresse entsprechen. R3 whlt hiervon die spezifischere Route (d. h. die Route mit dem lngeren Prfix) zum Subnetz 10.1.1.0/26 aus. Diese Route bewirkt jedoch, dass R3 fr 10.1.1.1 vorgesehene Pakete an R2 statt an R1 weiterleitet.

Kapitel 7 Troubleshooting beim IP-Routing

365

Zwar lsst sich nicht genau ermitteln, warum diese statische Route eingerichtet wurde, doch die Ursache wurde erkannt: die statische Route nach 10.1.1.0/26 auf R3. Wenn das an R1 hngende LAN alle Adressen zwischen 10.1.1.0 und 10.1.1.255 enthlt, kann (und sollte) die statische Route einfach gelscht werden.

Alternativer Ansatz zu den Schritten 3, 4 und 5 der Problemeingrenzung


Die Router-bezogenen Schritte des Vorgangs zur Eingrenzung von RoutingProblemen hngen von traceroute ab, das heit, sie sind auf die Fhigkeit dieses Befehls angewiesen, den Router zu ermitteln, auf dem die Problembehebung beginnen soll. Alternativ knnen die Befehle ping und telnet verwendet werden. Weil mit diesen Befehlen jedoch nicht sehr schnell ermittelt werden kann, auf welchen Routern das Problem mglicherweise besteht, erfordern ping und telnet, dass Sie zunchst auf dem ersten Router im Pfad dem Default-Gateway des Hosts eine Reihe von Schritten ausfhren mssen. Diese Schritte sind fr alle nachfolgenden Router im Pfad zu wiederholen, bis das Problem erkannt ist. Der Vollstndigkeit halber sei deswegen hier erwhnt, dass Sie die in den Schritten 4 und 5 beschriebenen Manahmen alternativ mit ping auf jedem Router einzeln durchfhren knnen. Um etwa diesen Ansatz beim ersten der beiden beschriebenen Szenarien durchfhren zu knnen, msste der Vorgang zunchst beim Router R1 beginnen dem Default-Gateway von PC1. Im ersten Szenario gab es auf der Vorwrtsroute keine Probleme mit der Weiterleitung von Paketen an 172.16.2.7 (PC4), und ebenso wenig bestanden Probleme mit der Rckroute auf R1. Auch waren keine ACLs vorhanden. Bei der alternativen Vorgehensweise wrden Sie nun mit dem nchsten Router im Pfad (R3) fortfahren. Dadurch liee sich das Problem mit der Vorwrtsroute auf R3 das Fehlen einer fr die Zieladresse 172.16.2.7 passenden Route ebenfalls ermitteln.

7.5

Tools und Tipps zur Problembehebung

Die zweite Hlfte dieses Kapitels widmet sich einer Vielzahl von Tools und Hinweisen zur Problembehebung, die in echten Netzwerken hilfreich sein knnen. Einige der Angaben in diesem Abschnitt lassen sich zudem direkt auf die CCNA-Prfungen anwenden. Doch auch die anderen knnen fr die Prfungen von zumindest indirektem Nutzen sein. Das hier vermittelte Wissen ist unter Umstnden ntzlich, wenn Sie bei Ihrer beruflichen Ttigkeit mit Netzwerken arbeiten, was wiederum eine bessere Vorbereitung auf die in den Prfungen beschriebenen Szenarien darstellt.

366

CCNA ICND2-Prfungshandbuch

7.5.1

Host-bezogene Routing-Tools und Aspekte

Dieser Abschnitt behandelt zwei kurze Themen zu der Frage, wie Hosts IPPakete verarbeiten. Im ersten Teil sind diverse Hinweise zur Problembehebung bei Hosts aufgefhrt. Der zweite Teil stellt eine Wiederholung eines im CCENT/CCNA ICND1-Prfungshandbuch beschriebenen Sachverhalts dar: Die IP-Konfiguration eines LAN-Switchs verhlt sich wie ein Host.

Host-bezogene Hinweise zur Problembehebung


Wenn Sie versuchen, Ursachen von Netzwerkproblemen einzugrenzen, helfen Ihnen die in Tabelle 7.4 vorhandenen Hinweise zur Problembehebung bei Hosts. Diese sind nach Symptomen sortiert und geben typische Ursachen an. Beachten Sie bitte, dass die Tabelle nicht alle denkbaren Ursachen angibt, sondern nur hufig auftretende.
Tabelle 7.4: Hufig auftretende Probleme bei Hosts und typische Ursachen
Symptom Der Host kann Pakete an Hosts im selben Subnetz, aber nicht in andere Subnetze schicken. Der Host kann Pakete an Hosts im selben Subnetz, aber nicht in andere Subnetze schicken. Einige Hosts in einem Subnetz knnen mit Hosts in anderen Subnetzen kommunizieren, andere hingegen nicht. Einige Hosts im selben VLAN knnen Pakete an andere Hosts schicken, andere knnen dies hingegen nicht. Typische Ursache Auf dem Host ist kein Default-Gateway konfiguriert, oder die IP-Adresse des konfigurierten Default-Gateways ist falsch. Das Default-Gateway des Hosts befindet sich in einem anderen Subnetz als die IP-Adresse des Hosts (Sicht des Hosts auf das Subnetz). Das Default-Gateway arbeitet unter Umstnden mit einer anderen Maske als die Hosts. Das kann dazu fhren, dass die angeschlossene Route des Routers einige der Hosts im LAN nicht bercksichtigt. Die Hosts verwenden mglicherweise nicht dieselbe Maske.

Bei der Behebung von Netzwerkproblemen in der Praxis ist es sinnvoll, sich zunchst die Symptome anzusehen, denn hier beginnt in der Regel der Vorgang der Problemeingrenzung. Was die Prfungen betrifft, sind die meisten Probleme mit der Host-Kommunikation lediglich auf eine geringe Anzahl von Ursachen zurckzufhren:
Wichtig!

1. berprfen Sie alle Hosts und Router, die sich im selben Subnetz befinden sollten, um sicherzustellen, dass alle dieselbe Subnetzmaske verwenden und sich die Adressen tatschlich im selben Subnetz befinden. 2. Vergleichen Sie die Default-Gateway-Einstellungen aller Hosts mit der Router-Konfiguration, um zu gewhrleisten, dass die IP-Adresse stimmt.

Kapitel 7 Troubleshooting beim IP-Routing

367

3. Wenn die ersten beiden Aspekte korrekt sind, suchen Sie nach Problemen der Schichten 1 und 2, wie sie in den Kapiteln 1 bis 3 behandelt wurden.

Untersttzung von IP-Adressen fr LAN-Switches


Ethernet-Switches mssen nichts ber die Schicht 3 wissen, um die grundlegenden Schicht-2-Funktionen zur Weiterleitung von Ethernet-Frames ausfhren zu knnen. Trotzdem bentigen LAN-Switches eine IP-Adresse, um diverse wichtige Funktionalitten bieten zu knnen, z. B. die Mglichkeit der Herstellung einer Telnet- oder SSH-Verbindung zum Switch, um Fehler oder Probleme erkennen und beheben zu knnen . Wenn es um die IP-Konfiguration geht, verhalten sich Switches wie Hosts. Im Gegensatz zu einem PC verwendet ein Cisco-Switch jedoch keine Netzwerkkarte, sondern eine virtuelle Schnittstelle, die VLAN 1 zugeordnet ist, das heit, der Switch erhlt eine eigene Schnittstelle in VLAN 1. Danach lassen sich fr diese VLAN-Schnittstelle dieselben Eigenschaften konfigurieren, die sich fr IP auch auf einem Host festlegen lassen: IP-Adresse, Maske und Default-Gateway. Auch IP-Adressen von DNS-Servern lassen sich eingeben. Die folgende Liste ist eine Wiederholung der Checkliste fr die IP-Konfiguration von LAN-Switches aus dem CCENT/CCNA ICND1-Prfungshandbuch. Auf diese Liste folgend zeigt Listing 7.6 die IP-Adresskonfiguration fr den Switch SW1 in Abbildung 7.5 weiter oben in diesem Kapitel. 1. Wechseln Sie (aus einem beliebigen Konfigurationsmodus heraus) mit dem globalen Konfigurationsbefehl interface vlan 1 in den Konfigurationsmodus fr VLAN 1. 2. Weisen Sie mit dem Schnittstellenbefehl ip address ip-address mask eine IPAdresse und eine Subnetzmaske zu. 3. Aktivieren Sie die VLAN 1-Schnittstelle mit dem Schnittstellenbefehl no shutdown. 4. Fgen Sie den globalen Befehl ip default-gateway ip-address hinzu, um das Default-Gateway zu konfigurieren.
Listing 7.6: Statische Konfiguration einer IP-Adresse auf einem Switch
SW1#configure terminal SW1(config)#interface vlan 1 SW1(config-if)#ip address 10.1.1.200 255.255.255.0 00000000000000000000000000000000000 SW1(config-if)#no shutdown 00:25:07: %LINK-3-UPDOWN: Interface Vlan1, changed state to up 00:25:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up SW1(config-if)#exit SW1(config)#ip default-gateway 10.1.1.1
Wichtig!

368

CCNA ICND2-Prfungshandbuch

ANMERKUNG
Die VLAN-Schnittstelle auf einem Switch bleibt administrativ abgeschaltet, bis der Benutzer den Befehl no shutdown absetzt. Der Switch sendet erst dann IP-Pakete, wenn die VLAN 1-Schnittstelle aktiviert ist. Ein hufig bersehener Faktor bei der Konfiguration der IP-Konnektivitt oder der Behebung zugehriger Probleme steht im Zusammenhang mit dem VLAN-Trunking. Cisco empfiehlt generell, Endgerte der Benutzer nicht dem VLAN 1 zuzuordnen, whrend die IP-Adresse des Switchs durchaus im VLAN 1 konfiguriert werden kann. Damit die Switches Pakete an Hosts der Benutzer in verschiedenen Subnetzen senden und von diesen empfangen knnen (was Voraussetzung fr von diesen Subnetzen ausgehende TelnetVerbindungen mit diesem Switch ist), muss die Trunking-Konfiguration des Routers die Konfiguration fr VLAN 1 und die der Benutzer-VLANs enthalten.

7.5.2

Referenz zum Befehl show ip route

Der Befehl show ip route spielt eine gewichtige Rolle bei der Behebung von Problemen mit dem IP-Routing und Routing-Protokollen. Details zu diesem Befehl werden in vielen Kapiteln in diesem Buch wie auch im ICND1-Buch erwhnt. In diesem Abschnitt fassen wir das Thema der besseren bersicht wegen an zentraler Stelle zusammen. Abbildung 7.6 zeigt die Ausgabe des Befehls show ip route aus Listing 7.3. Die Abbildung kennzeichnet verschiedene Teile der Befehlsausgabe der Orientierung halber numerisch. Die einzelnen Elemente werden in Tabelle 7.5 beschrieben.
1 C R C R 4 2 3

10.0.0.0 /24 is subnetted, 4 subnets 10.1.13.0 is directly connected, Serial0/0/1 10.1.1.0 [120/1] via 10.1.13.1, 00:00:04, Serial0/0/1 10.1.23.0 is directly connected, Serial0/1/0 10.1.0.0 [120/1] via 10.1.23.2, 00:00:01, Serial0/1/0 5 6 7 8 9 10

Abbildung 7.6: Befehlsausgabe von show ip route

Kapitel 7 Troubleshooting beim IP-Routing


Tabelle 7.5: Beschreibungen der Elemente der show ip route-Ausgabe
Nr. 1 Element Wert in der Abbildung Beschreibung

369

Klassenbezoge- 10.0.0.0 nes Netzwerk

Die Routing-Tabelle ist nach klassenbezogenen Netzwerken sortiert. Diese Zeile ist die berschrift fr das klassenbezogene Netzwerk 10.0.0.0. Wenn dieser Router nur eine Subnetzmaske fr alle Subnetze des Netzwerks kennt, wird an dieser Stelle diese Maske (standardmig in der Prfixnotation) angezeigt. Gibt die Anzahl der Routen in Subnetzen des klassenbezogenen Netzwerks an, die der Router kennt. Dieser Code gibt die Herkunft der RoutingDaten an. R steht fr RIP, C fr angeschlossene Netzwerke. In der Abbildung wird die Legende ganz oben in der show ip routeAusgabe weggelassen (sie ist jedoch in Listing 7.3 vorhanden). Subnetzadresse der betreffenden Route Wenn ein Router eine Route fr das angegebene Subnetz aus mehreren Quellen mit Routing-Informationen erlernt, verwendet er die Quelle mit der kleinsten administrativen Distanz. Metrik der Route Bei Paketen, fr die diese Route vorgesehen ist, ist dies diejenige IP-Adresse des nchsten Routers, an den das Paket weitergeleitet werden soll. Zeit, die seit dem Erlernen dieser Route in einem Routing-Update verstrichen ist ist, ist dies diejenige Schnittstelle, ber die das Paket weitergeleitet werden soll.

Prfixlnge

/24

Anzahl der Subnetze Legendencode

4 subnets

R, C

5 6

Subnetzadresse 10.1.0.0 Administrative Distanz


120

7 8

Metrik Nchster Hop

1 10.1.23.2

9 10

Timer Ausgehende Schnittstelle

00:00:01

Serial0/1/0 Bei Paketen, fr die diese Route vorgesehen

Die Ausgabe des Befehls sieht ein wenig anders aus, sofern VLSM verwendet wird. Die Abbildung zeigt ein Beispiel, bei dem VLSM im Netzwerk 10.0.0.0 mit der Subnetzmaske /24 fr alle Subnetze dieses Netzwerks nicht verwendet wird. Insofern gibt IOS die Subnetzmaske (hier /24) nur einmal an: in der berschriftzeile. Wrde VLSM verwendet, so wrde die berschrift

370

CCNA ICND2-Prfungshandbuch

lediglich angeben, dass das Netzwerk variabel in Subnetze unterteilt wird, und jede Route wrde ihre Maske einzeln auffhren. Ein Beispiel hierfr sehen Sie in Kapitel 5, VLSM und Routensummierung, in Listing 5.1.

7.5.3

Schnittstellenzustand

Einer der Schritte zur Behebung von IP-Routing-Problemen, die wir weiter oben unter dem Punkt Probleme bei der Paketweiterleitung beheben beschrieben haben, ist die berprfung des Schnittstellenzustands. Dies ist erforderlich, um sicherzustellen, dass die erforderliche Schnittstelle funktioniert. Wenn eine Router-Schnittstelle in Betrieb sein soll, mssen beide Schnittstellenzustandscodes als up aufgefhrt werden. Dieser Kapitel erlutert keine Problembehebung fr Router-Schnittstellen, sondern setzt voraus, dass sich alle Schnittstellen tatschlich im Zustand up/ up befinden. Der Abschnitt Troubleshooting bei seriellen Verbindungen in Kapitel 12 erlutert zahlreiche Details zur Behebung von Problemen mit Router-Schnittstellen. Bei den LAN-Schnittstellen von Routern, die mit einem LAN-Switch verbunden sind, muss auf dem Router in erster Linie berprft werden, ob Router und Switch die gleichen Duplex- und Geschwindigkeitseinstellungen verwenden und sofern das Trunking konfiguriert ist dieses sowohl auf dem Router als auch auf dem Switch manuell konfiguriert wurde, da Router das LAN-Trunking nicht dynamisch aushandeln.

7.5.4

VLSM-Probleme

Dieser Abschnitt behandelt diverse Probleme beim Einsatz von VLSM: Erkennen, ob VLSM benutzt wird, und gegebenenfalls die verwendbaren Routing-Protokolle benennen Die Bedingungen verstehen, unter denen Router eine Fehlkonfiguration mit sich berlappenden VLSM-Subnetzen tolerieren knnen Die Symptome kennen, die bei sich berlappenden VLSM-Subnetzen auftreten

Die Verwendung von VLSM erkennen


Ein hufiger Fehler bei der Behebung eines Problems in einem nicht vertrauten Netzwerk besteht darin, dass nicht erkannt wird, ob VLSM benutzt wird. Wie in Kapitel 5 definiert wurde, verwendet ein Netzwerkverbund VLSM, falls mehrere Subnetzmasken fr verschiedene Subnetze eines einzelnen klassenbezogenen Netzwerks verwendet werden. Beispielsweise wird, wenn in einem Netzwerkverbund alle Subnetze des Netzwerks 10.0.0.0 die

Kapitel 7 Troubleshooting beim IP-Routing

371

Subnetzmaske 255.255.240.0 verwenden, whrend alle Subnetze des Netzwerks 172.16.0.0 die Maske 255.255.255.0 benutzen, VLSM im Design nicht eingesetzt. Wrden mehrere Masken fr Subnetze des Netzwerks 10.0.0.0 eingesetzt, wrde hingegen VLSM benutzt. Das Folgekonzept besagt, dass nur klassenlose Routing-Protokolle wie RIPv2, EIGRP und OSPF VLSM untersttzen knnen, nicht jedoch klassenbezogene Routing-Protokolle wie RIPv1, IGRP. Also knnen Sie nach der schnellen Feststellung, ob VLSM verwendet wird oder nicht, sagen, ob ein klassenloses Routing-Protokoll erforderlich ist. Beachten Sie, dass das Routing-Protokoll keine besondere Konfiguration bentigt, sondern VLSM direkt untersttzt. Es handelt sich dabei um eine feststehende Eigenschaft des jeweiligen Protokolls.

berlappende VLSM-Subnetze konfigurieren


Die Regeln der IP-Subnetzbildung sehen vor, dass sich die Adressbereiche in den Subnetzen, die in einem Netzwerk verwendet werden, nicht berschneiden drfen. Das IOS erkennt in manchen Fllen, wenn ein neuer ip addressBefehl ein berlappendes Subnetz erstellt. Der vorliegende Abschnitt beschreibt die Bedingungen, unter denen berlappende Subnetze konfiguriert werden knnen. Dabei beginnen wir mit den folgenden allgemeinen Anmerkungen zur Frage, wann mit dem IOS berschneidungen konfiguriert werden knnen und wann nicht: berlappungen vermeiden: IOS erkennt die berschneidung, wenn der Befehl ip address eine solche mit einem anderen ip address-Befehl auf demselben Router verursacht. Hat die konfigurierte Schnittstelle den Zustand up/up, so weist IOS den Befehl ip address zurck. Andernfalls akzeptiert IOS zwar den Befehl, setzt die Schnittstelle jedoch keinesfalls in Betrieb. berlappungen zulassen: Das IOS kann berschneidungen nicht erkennen, falls ein Befehl ip address sich mit einem ip address-Befehl auf einem anderen Router berschneidet. Der in Listing 7.7 gezeigte Router verhindert die Konfiguration eines berlappenden VLSM-Subnetzes. Das Listing zeigt den Router R3 bei der Konfiguration der Schnittstelle Fa0/0 mit der IP-Adresse 172.16.5.1/24 und der Schnittstelle Fa0/1 mit 172.16.5.193/26. Die Adressbereiche in den Subnetzen sehen wie folgt aus: Subnetz 172.16.5.0/24: 172.16.5.1 bis 172.16.5.254 Subnetz 172.16.5.192/26: 172.16.5.193 bis 172.16.5.254
Wichtig!

372

CCNA ICND2-Prfungshandbuch

Listing 7.7: Der Router weist berlappende Subnetze ab.


R3#configure terminal R3(config)#interface Fa0/0 R3(config-if)#ip address 000000000000000000000000 172.16.5.1 255.255.255.0 R3(config-if)#interface Fa0/1 R3(config-if)#ip address 0000000000000000000000000000 172.16.5.193 255.255.255.192 % 172.16.5.192 overlaps with FastEthernet0/0 R3(config-if)#

Das IOS wei, dass berschneidungen bei den Adressbereichen von Subnetzen nicht zulssig sind. Weil beide Subnetze in diesem Fall verbundene Subnetze wren, wei der Router, dass diese Subnetze nicht koexistieren knnen, weil hierdurch die Regeln der Subnetzbildung verletzt wrden. Deswegen weist das IOS den zweiten Befehl ab. Es ist allerdings trotzdem mglich, berschneidende Subnetze zu konfigurieren, sofern diese an verschiedene Router angeschlossen sind. Abbildung 7.7 hnelt sehr stark der Abbildung 5.2, die in Kapitel 5 zur Erluterung des Problems sich berschneidender Subnetze verwendet wurde. Listing 7.8 zeigt die Konfiguration der beiden sich berschneidenden Subnetze auf R2 und R3.
172.16.4.1/23 172.16.9.2/30

PC2

PC1

172.16.2.1/23

172.16.9.1/30 S0/0/1

R2
172.16.5.2

R1
S0/1/0 172.16.2.2 172.16.9.5/30 172.16.9.6/30

PC3

R3
172.16.5.1/24 172.16.5.3

Abbildung 7.7: Netzwerk, das die Konfiguration berlappender Subnetze gestattet


Listing 7.8: Zwei Router akzeptieren berschneidende Subnetze.
R2#configure terminal R2(config)#interface Fa0/0 R2(config-if)#ip address 000000000000000000000000 172.16.4.1 255.255.254.0 R3#configure terminal R3(config)#interface Fa0/0 R3(config-if)# ip address 000000000000000000000000 172.16.5.1 255.255.255.0

Kapitel 7 Troubleshooting beim IP-Routing

373

Merken Sie sich fr die Prfung, dass sich berschneidende Subnetze zunchst konfiguriert werden knnen, wenn sie nicht mit demselben Router verbunden sind. Nehmen wir an, dass Sie also in einer Aufgabe aufgefordert werden, eine neue Subnetzadresse auszuwhlen und eine Schnittstelle so zu konfigurieren, dass diese sich in diesem Subnetz befindet. Sie knnen daraus, dass der Router Ihren ip address-Befehl klaglos entgegennimmt, nicht unbedingt schlieen, dass Ihre Berechnungen korrekt waren. Das nchste Thema erlutert einige der Symptome, die Sie erkennen knnen, falls das Problem einer berschneidung vorhanden ist.

Symptome sich berschneidender Subnetze

ANMERKUNG
Der vorliegende Abschnitt ist eigentlich nur der Vollstndigkeit halber enthalten, denn die hier beschriebenen Probleme gehen ber den Stoff der CCNA-Prfungen hinaus. Die von auen sichtbaren Symptome des Problems unterscheiden sich abhngig davon, ob die fragliche Adresse sich im berschneidenden Bereich der Subnetze befindet und ob mehrere Hosts versuchen, exakt dieselbe IPAdresse zu verwenden. Die Adressen in den sich nicht berlappenden Bereichen des Subnetzes funktionieren in der Regel einwandfrei, whrend dies bei Adressen im berlappungsbereich der Fall sein kann, aber nicht muss. Wenn wir uns noch einmal Abbildung 7.6 ansehen, stellen wir beispielsweise fest, dass sich die Subnetze 172.16.4.0/23 und 172.16.5.0/24 berschneiden, und zwar im Bereich 172.16.5.0 bis 172.16.5.255. Hosts mit sich nicht berschneidenden Adressen im Bereich von 172.16.4.0 bis 172.16.4.255 funktionieren wahrscheinlich einwandfrei. Bei Adressen im berschneidungsbereich arbeiten Hosts im kleineren der beiden sich berschneidenden Subnetze in vielen Fllen korrekt, whrend dies bei Hosts im greren Subnetzen nicht der Fall ist. Um festzustellen, warum dies so ist, betrachten Sie noch einmal Abbildung 7.7: Hier versucht PC1, sowohl an 172.16.5.2 (PC2 an R2) als auch an 172.16.5.3 (PC3 an R3) ping-Befehle zu senden. (In diesem Beispiel nehmen wir an, dass die IPAdressen von PC2 und PC3 nicht im berschneidungsbereich der Subnetze liegen.) Wie Sie der Routing-Tabelle von R1 und der Ausgabe von traceroute 172.16.5.2 in Listing 7.9 entnehmen knnen, wrde das von PC1 and PC2 gesendete Paket tatschlich von R1 and R3 bermittelt und anschlieend in das LAN von R3 weitergeleitet.

374

CCNA ICND2-Prfungshandbuch

Listing 7.9: Zwei Router akzeptieren sich berschneidende Subnetze.


! Die Route von R1 nach 172.16.5.2, abgehend von R2, weist nach R3. R1#show ip route 172.16.5.2 Routing entry for 172.16.5.0/24 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 172.16.9.6 on 00000000000 00:00:25 ago Serial0/1/0, Routing Descriptor Blocks: * 0000000000 from 172.16.9.6, 00:00:25 ago, via Serial0/1/0 172.16.9.6, Route metric is 1, traffic share count is 1 ! Die Route von R1 nach 172.16.5.3, abgehend von R3, weist nach R3. R1#show ip route 172.16.5.3 Routing entry for 172.16.5.0/24 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 172.16.9.6 on 00000000000 00:00:01 ago Serial0/1/0, Routing Descriptor Blocks: * 0000000000 from 172.16.9.6, 00:00:01 ago, via Serial0/1/0 172.16.9.6, Route metric is 1, traffic share count is 1 ! Der Befehl traceroute nach PC2 zeigt R3 (und nicht R2) als ersten Router an, ! weswegen das Paket niemals PC2 erreicht und der Befehl vom Benutzer manuell ! beendet werden muss. R1#traceroute 172.16.5.2 Type escape sequence to abort. Tracing the route to 172.16.5.2 1 0000000000 4 msec 0 msec 4 msec 172.16.9.6 2 * * * 3 * * * 4 R1#traceroute 172.16.5.3 Type escape sequence to abort. Tracing the route to 172.16.5.3 1 172.16.9.6 0 msec 4 msec 0 msec 2 172.16.5.3 4 msec * 0 msec

Das Beispiel zeigt, dass R1 Pakete an die Hosts 172.16.5.2 (PC2) und 172.16.5.3 (PC3) weiterleitet, indem er sie an R3 schickt. R3 versucht nun, diese Pakete im eigenen LAN-Subnetz auszuliefern. Das klappt bei PC3 gut und bei PC2 nicht ganz so gut, weil PC2 sich im greren der beiden berschneidenden Subnetze befindet.

Kapitel 7 Troubleshooting beim IP-Routing

375

Die Symptome knnen sich noch verschlimmern, wenn Adressen doppelt vergeben wurden. Stellen Sie sich etwa vor, dass ein PC22 zum LAN-Subnetz von R2 hinzugefgt worden wre, der mit 172.16.5.3 die gleiche IP-Adresse aufweist wie PC3. Stellen wir uns nun vor, der Benutzer von PC22 meldet sich bei Ihnen, um mitzuteilen, dass sein Computer nicht mit anderen Gerten kommunizieren kann. Sie setzen den Befehl ping 172.16.5.3 ab, um dies zu berprfen und siehe da: Der Ping funktioniert! Was Sie nicht wissen: Der ping-Befehl ist bei der falschen Instanz von 172.16.5.3 gelandet. Die Symptome sind in einem solchen Fall also unter Umstnden sehr schwierig zu interpretieren. Eine weitere Schwierigkeit bei sich berschneidenden VLSM-Subnetzen besteht darin, dass Probleme oft nur sporadisch auftreten. Stellen Sie sich beim gleichen Beispiel nun vor, dass alle Adressen in beiden Subnetzen von einem DHCP-Server zugewiesen wrden. Dieser beginnt bei der Vergabe mit der kleinsten IP-Adresse. In den ersten sechs Monaten hat der Server im LAN-Subnetz von R2 nur Adressen vergeben, die mit 172.16.4 beginnen. Schlielich sind jedoch so viele Hosts im LAN an R2 installiert, dass von einem bestimmten Tag an auch Adressen vergeben werden, die mit 172.16.5 beginnen. In diesen Bereich fllt auch die Adresse von PC2 aus dem obigem Beispiel (172.16.5.2). Leider kann nun niemand Pakete an diese Hosts schicken. Die Tatsache, dass das Problem erst viele Monate nach der Installation und Konfiguration des Systems in Erscheinung trat, kann die Fehlerermittlung erheblich erschweren.

Zusammenfassung zur Behebung von VLSM-Problemen


Die folgende Liste fasst die wesentlichen Punkte zusammen, die zur Behebung mglicher Probleme in Verbindung mit VLSM in den Prfungen bercksichtigt werden mssen: Achten Sie genau darauf, ob VLSM tatschlich verwendet wird. Ist dies der Fall, so stellen Sie bitte fest, ob ein klassenloses Routing-Protokoll eingesetzt wird. Beachten Sie, dass sich berschneidende Subnetze tatschlich konfigurieren lassen. Erkennbare Symptome knnen darin bestehen, dass einige Hosts in einem Subnetz einwandfrei funktionieren, whrend andere keine Pakete aus dem Subnetz heraus verschicken knnen. Suchen Sie mit traceroute nach Routen, die Pakete in einen falschen Teil des Netzwerks leiten. Dies knnte Folge sich berschneidender Subnetze sein.
Wichtig!

376

CCNA ICND2-Prfungshandbuch

In den Prfungen knnen Aufgaben gestellt werden, von denen Sie annehmen, dass sie mit VLSM und IP-Adressen in Zusammenhang stehen. In solchen Fllen besteht der beste Ansatz darin, die Logik jedes einzelnen Subnetzes mathematisch zu analysieren und sicherzustellen, dass keine berlappungen vorhanden sind, statt die Problembehebung mit ping und traceroute zu versuchen.

7.5.5

Nicht zusammenhngende Netzwerke und Autosummierung

In Kapitel 5 wurde das Konzept der nicht zusammenhngenden Netzwerke erlutert und die Verwendung eines klassenlosen Routing-Protokolls mit deaktivierter Autosummierung als Lsung entsprechender Probleme beschrieben. Hier nun wollen wir einen bestimmten Fall untersuchen, bei dem ein nicht zusammenhngendes Netzwerk nur zeitweise vorhanden ist. Abbildung 7.8 zeigt ein Netzwerk mit zwei klassenbezogenen Netzwerken 10.0.0.0 und 172.16.0.0. Das Netzdesign stellt zwei zusammenhngende Netzwerke dar, da eine Route, die ausschlielich aus Subnetzen der einzelnen Netzwerke besteht, zwischen allen Subnetzen des jeweiligen Netzwerks vorhanden ist.

172.16.3.0/24 10.1.3.0/24 172.16.1.0/24

R2
172.16.2.0/24

172.16.4.0/24 10.1.4.0/24

R1
10.1.1.0/24 10.1.2.0/24

R4

R3

Abbildung 7.8: Netzwerk mit (derzeit) zusammenhngenden Netzwerken

In dieser Abbildung knnen, sofern alle Verbindungen betriebsbereit sind, bei Verwendung eines Routing-Protokolls mit aktivierter Autosummierung alle Hosts erfolgreich ping-Befehle an alle anderen Hosts schicken. Hierbei werden Pakete an das Netzwerk 172.16.0.0 ber die obere Route gesendet, Pakete an das Netzwerk 10.0.0.0 hingegen flieen unten entlang. Leider kann im Laufe der Zeit ein Problem entstehen, wenn eine der vier Verbindungen zwischen den Routern ausfllt. In diesem Fall wird nmlich eines der beiden klassenbezogenen Netzwerke unzusammenhngend. Fllt also etwa die Verbindung zwischen R3 und R4 aus, dann verluft die Route

Kapitel 7 Troubleshooting beim IP-Routing

377

von R1 nach R4 durch Subnetze des Netzwerks 172.16.0.0, das heit, das Netzwerk 10.0.0.0 hngt nicht mehr zusammen. Auch bei einer Verwendung eines klassenlosen Routing-Protokolls mit aktivierter Autosummierung weisen sowohl R1 als auch R4 eine Route nach 10.0.0.0/8 an R2 aus, und R2 erkennt seinerseits zwei Routen in das gesamte 10.0.0.0 eine ber R1 und eine zweite ber R4. Die Lsung besteht wie blich darin, ein klassenloses Routing-Protokoll mit deaktivierter Autosummierung zu verwenden. Zwar mag das Design in Abbildung 7.8 ein wenig theoretisch wirken, doch geschieht so etwas hufiger, als Sie vielleicht glauben und zwar vor allem dann, wenn Unternehmen den Besitzer wechseln. Denken Sie deswegen sowohl in der Praxis als auch bei den Prfungen stets an das Konzept der nicht zusammenhngenden Netzwerke. Dies gilt gleichermaen fr normale Arbeitsbedingungen wie auch fr Flle, in denen redundante Verbindungen ausfallen.

7.5.6

Hinweise zum Troubleshooting bei ACLs

Die Behebung von Problemen, die im Zusammenhang mit ACL entstehen, kann durchaus als eine der schwierigsten Aufgaben gelten, die in der Praxis auftreten knnen. Eine wesentliche Schwierigkeit besteht darin, dass traditionelle Hilfsmittel zur Problembehebung wie ping und traceroute keine Pakete senden, die den Paketen gleichen, die in erweiterten ACLs durch eine Vielzahl von Feldern verglichen werden knnen. Insofern kann ein Endgert auch bei einem funktionierendem ping-Befehl unter Umstnden keinen Zugriff auf die korrekte Anwendung erhalten (oder umgekehrt). Der vorliegende Abschnitt fasst einige Hinweise zusammen, mit denen sich ACL- Probleme in der Praxis und in den Prfungen lsen lassen. 1. Ermitteln Sie mit show running-config und show ip interfaces, auf welchen Schnittstellen und in welche Richtungen ACLs aktiviert sind. 2. Ermitteln Sie mit show access-lists und show ip access-lists, welche ACLAnweisungen mit testweise gesendeten Paketen bereinstimmen. 3. Analysieren Sie die ACLs, um prognostizieren zu knnen, welche Pakete der ACL entsprechen sollten. Beachten Sie dabei insbesondere folgende Punkte: a) Denken Sie an die Logik der ersten bereinstimmung, die ACLs verwenden.
Wichtig!

378

CCNA ICND2-Prfungshandbuch

b) Ziehen Sie die Verwendung des (mglicherweise) schnelleren mathematischen Ansatzes in Betracht, der in Kapitel 6, IP-ACLs beschrieben wurde. ACL-Paare aus Adressen und Wildcards werden in Paare aus Adressen und Subnetzmasken konvertiert, die die Nutzung derselben Berechnungen wie bei der Subnetzbildung ermglichen. c) Beachten Sie die Richtung des Pakets relativ zum Server (also ob das Paket zum Server geht oder von dort kommt). Vergewissern Sie sich, dass die Pakete spezielle Werte fr Absender-IP-Adresse und Absender-Port oder fr Ziel-IP-Adresse und Ziel-Port haben, wenn sie von der ACL in einer bestimmte Richtung (ein- oder ausgehend) verarbeitet werden. d) Vergessen Sie nicht, dass die Schlsselwrter tcp und udp verwendet werden mssen, wenn die ACL die Port-Nummern berprfen soll. (Eine Liste verbreiteter TCP- und UDP-Port-Nummern knnen Sie der Tabelle 6.5 in Kapitel 6 entnehmen.) e) Beachten Sie, dass ICMP-Pakete weder UDP noch TCP verwenden. ICMP gilt als eigenstndiges Protokoll, das mithilfe des Schlsselwortes icmp (anstelle von ip, tcp und udp) verglichen werden kann. f) Statt die implizite deny-Aktion zu verwenden, sollten Sie einen expliziten Konfigurationsbefehl angeben, um den gesamten Datenverkehr am Ende einer ACL zu verweigern, sodass die Zhler in den showBefehlen hochgezhlt werden, wenn diese Aktion ausgefhrt wird. Kapitel 6 behandelte die Hintergrundinformationen zu den Hinweisen in Schritt 3. Im verbleibenden Teil dieses Abschnitts legen wir den Schwerpunkt auf Befehle, mit denen Sie Probleme in den ersten beiden Schritten untersuchen knnen. Wenn ein Problem bei der Weiterleitung von IP-Paketen auftritt und vorhandene ACLs dieses Problem verursachen knnen, mssen Sie im Zuge der Eingrenzung zunchst einmal die Position und Richtung der ACLs ermitteln. Die schnellste Mglichkeit, dies zu tun, besteht darin, die Ausgabe des Befehls show running-config zu betrachten und dort nach ip access-groupBefehlen unter den einzelnen Schnittstellen zu suchen. In manchen Fllen ist der Zugriff im Enable-Modus jedoch nicht zulssig, weswegen die showBefehle bentigt werden. Die einzige Mglichkeit, die Schnittstellen und ihre Richtung fr IP-ACLs zu ermitteln, ist der Befehl show ip interface (Listing 7.10).

Kapitel 7 Troubleshooting beim IP-Routing


Listing 7.10: Befehl show ip interface (Beispiel)
R1>show ip interface s0/0/1 Serial0/0/1 is up, line protocol is up Internet address is 10.1.2.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.9 Outgoing access list is not set Inbound access list is 102 ! ...ca. 26 weitere Zeilen zwecks Abkrzung weggelassen

379

Beachten Sie, dass die Befehlsausgabe angibt, ob und in welcher Richtung eine ACL aktiviert ist und um welche ACL es sich handelt. Das Listing zeigt eine verkrzte Version des Befehls show ip interface S0/0/1, der Angaben nur fr diese eine Schnittstelle anzeigt. Der Befehl show ip interface wrde dieselben Angaben fr alle Schnittstellen auf dem Router anzeigen. Schritt 2 besagt nun, dass der Inhalt der ACL ermittelt werden muss. Auch hier besteht die zweckmigste Mglichkeit, nach der ACL zu suchen, in der Verwendung des Befehls show running-config. Wenn der Enable-Modus nicht zulssig ist, liefern die Befehle show access-lists und show ip access-lists dieselbe Ausgabe. Der einzige Unterschied besteht darin, dass, sofern andere Nicht-IP-ACLs konfiguriert wurden, der Befehl show access-lists auch diese Nicht-IP-ACLs anzeigt. Die Ausgabe enthlt dieselben Angaben, die auch in den Konfigurationsbefehlen angezeigt werden, sowie einen Zhler fr die Anzahl der Pakete, die den einzelnen Zeilen in der ACL entsprechen. Listing 7.11 zeigt ein Beispiel.
Listing 7.11: Befehl show ip access-lists (Beispiel)
R1#show ip access-lists Extended IP access list 102 10 permit ip 10.1.2.0 0.0.0.255 10.1.1.0 0.0.0.255 000000000000 (15 matches)

Nachdem Positionen, Richtungen und Konfigurationsdetails der verschiedenen ACLs in den Schritten 1 und 2 ermittelt wurden, beginnt nun der schwere Teil der Arbeit: zu interpretieren, was die ACL eigentlich bewirkt. Von besonderem Interesse ist dabei der letzte Eintrag in der Liste der Hinweise zum Troubleshooting (Schritt 3f). In der in Listing 7.11 gezeigten ACL entsprachen einige Pakete (bislang 15) der einzelnen konfigurierten accesslist-Anweisung in ACL 102. Allerdings wurden wahrscheinlich einige

380

CCNA ICND2-Prfungshandbuch

Pakete aufgrund der impliziten deny-Anweisung am Ende einer ACL abgewiesen. Durch Konfigurieren des Befehls access-list 102 deny ip any any am Ende der ACL lsst sich die Anzahl der abgewiesenen Pakete am Ende der ACL in der Ausgabe von show ip access-lists anzeigen. Dieser Befehl entspricht allen Paketen, und diese werden daraufhin verworfen. Cisco empfiehlt das Hinzufgen einer expliziten deny all-Anweisung am Ende einer ACL, um die Anzahl dieser Pakete zu erfahren und die Problembehebung zu erleichtern.

7.6
7.6.1
Wichtig!

Prfungsvorbereitung
Wiederholung

Wiederholen Sie die wichtigsten Themen aus diesem Kapitel. Diese sind in der Randspalte mit dem entsprechenden Symbol gekennzeichnet. Tabelle 7.6 listet diese Themen sowie die Seitennummern auf, auf denen die Themen zu finden sind.
Tabelle 7.6: Schlsselthemen in Kapitel 7
Element Tabelle 7.1 Abbildung 7.3 Abbildung 7.4 Liste Liste Beschreibung Hufig benutzte ICMP-Nachrichten und ihr Zweck Funktionsweise des TTL-Feldes im IP-Header und der Time Exceeded-Nachricht Verwendung des TTL-Feldes und der Time ExceededNachricht durch traceroute Eingrenzung von Host-bezogenen Routing-Problemen Eingrenzung von Router-bezogenen Routing-Problemen (Fortsetzung der Liste mit der Eingrenzung von Hostbezogenen Routing-Problemen) berprfung allgemeiner Aspekte bei der Behebung von Problemen mit der Host-Konnektivitt Schritte zur IP-Konfiguration von LAN-Switches Bedingungen, unter denen sich berschneidende Subnetze konfiguriert werden knnen, und wie das IOS diesen Fehler verhindert Beantwortung von Prfungsfragen, in denen VLSM Ursache eines Problems sein knnte ACL-Probleme lsen (auch dann, wenn die Konfiguration nicht angezeigt werden kann) Seite 345 350 352 355 357

Liste Liste Liste

366 367 371

Liste Liste

375 377

Kapitel 7 Troubleshooting beim IP-Routing

381

7.6.2

Vervollstndigen Sie die Listen und Tabellen

Drucken Sie aus Anhang J, Tabellen zur bung (auf der CD vorhanden), den Abschnitt zu diesem Kapitel aus und vervollstndigen Sie die Tabellen und Listen aus dem Gedchtnis. Der ebenfalls auf der CD enthaltene Anhang K, Lsungen zu den bungen, enthlt die vollstndigen Tabellen und Listen, mit denen Sie Ihre Lsungen berprfen knnen.

7.6.3

Wichtige Definitionen

Definieren Sie die folgenden Schlsselbegriffe aus diesem Kapitel und berprfen Sie Ihre Antworten anhand des Glossars: Vorwrtsroute, Rckroute

Teil III
Konfiguration und Problembehebung bei Routing-Protokollen
8 9 10 11 Theorie zu Routing-Protokollen . . . . . . . . . . . . . . . . . . . . . . . . . . OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EIGRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting bei Routing-Protokollen . . . . . . . . . . . . . . . . . . . 385 427 467 501

In diesem Teil behandelte offizielle1 Cisco-ICND2-Prfungsthemen IP-Adressierungsschema und IP-Dienste implementieren, um die Anforderungen an das Netzwerk der Zweigstelle eines mittelgroen Unternehmens zu erfllen Allgemeine Probleme in Verbindung mit der IP-Adressierungs- und der Host-Konfiguration erkennen und beheben Grundlegenden Betrieb und Routing auf Cisco-Gerten konfigurieren und Problembehebung durchfhren Routing-Methoden und -Protokolle vergleichen und gegenberstellen OSPF konfigurieren und verifizieren und Problembehebung durchfhren EIGRP konfigurieren und verifizieren und Problembehebung durchfhren Konfiguration und Konnektivitt mit ping, traceroute und telnet oder SSH berprfen Probleme der Routing-Implementierung beheben Betrieb von Router-Hardware und -Software mit show- und debug-Befehlen berprfen

1. Die aktuellen Versionen der Prfungsziele finden Sie stets unter http://www.cisco.com.

Dieses Kapitel behandelt die folgenden Themen


bersicht zu den dynamischen Routing-Protokollen Dieser Abschnitt stellt die Funktionsweise von Routing-Protokollen und viele Termini vor, die in diesem Zusammenhang verwendet werden. Funktion von Distanzvektor-Protokollen Dieser Abschnitt erlutert, wie Distanzvektor-Protokolle arbeiten, und legt dabei den Schwerpunkt auf die Funktionen zur Schleifenvermeidung. Funktion von Link-State-Protokollen Dieser Abschnitt zeigt auf, wie Link-State-Protokolle arbeiten. Als Beispiel wird OSPF verwendet.

Kapitel 8
Theorie zu Routing-Protokollen
Teil II, IP-Routing, behandelt schwerpunktmig die Vorgnge bei der Weiterleitung von IP-Paketen und nur im berblick die Frage, wie Router ihren Routing-Tabellen Eintrge hinzufgen. Mit diesem Kapitel beginnt Teil III, Konfiguration und Problembehebung bei Routing-Protokollen; wir werden diese Schwerpunktsetzung nun ndern und ausfhrlich erklren, wie Router ihre Routing-Tabellen durch dynamische Routing-Protokolle mit Daten fllen. IP-Routing-Protokolle arbeiten jeweils auf einer Gruppe von Routern gemeinsam. Nachrichten werden an benachbarte Router gesendet, damit diese die besten Routen zum Erreichen aller Subnetze kennenlernen. Dieses Hauptziel ist einfach formuliert, doch die Prozesse, die von Routing-Protokollen verwendet werden, gehren zu den eher komplexen und detailreichen Themen der CCNA-Prfung. Mit diesem Kapitel wollen wir die Erluterungen zu den IP-Routing-Protokollen in diesem Buch beginnen. Am Anfang stehen dabei die Arbeitsweise und Theorie von Routing-Protokollen. Die Kapitel 9 und 10 werden dann sehr detailliert beschreiben, wie OSPF und EIGRP funktionieren. Kapitel 11 schlielich beendet diesen Teil des Buches mit Darstellungen und Hinweisen zur Problembehebung in OSPF und EIGRP.

8.1

Fragen zur Einschtzung des Wissensstandes

Dieser Abschnitt gestattet es Ihnen zu ermitteln, ob Sie das gesamte Kapitel lesen mssen. Wenn Sie maximal eine der folgenden zehn Fragen zur Selbsteinschtzung nicht oder falsch beantworten, knnen Sie mit dem Abschnitt Aufgaben zur Prfungsvorbereitung fortfahren. Tabelle 8.1 listet die wichtigsten berschriften dieses Kapitels und die Nummern der Fragen auf, die sich auf die betreffenden Abschnitte beziehen. Auf diese Weise knnen Sie Ihr Wissen in den jeweiligen Bereichen selbst einschtzen. Die Antworten zu den Fragen in diesem Abschnitt finden Sie in Anhang A.

386

CCNA ICND2-Prfungshandbuch

Tabelle 8.1: Zuordnung der folgenden Fragen zu den einzelnen Themengebieten


Grundlagenthema bersicht zu den dynamischen Routing-Protokollen Eigenschaften von Distanzvektor-Protokollen Eigenschaften von Link-State-Protokollen Fragen 1 bis 5 6 bis 8 9 und 10

1. Welche der folgenden Routing-Protokolle gelten als Distanzvektor-Protokolle? a) RIPv1 b) RIPv2 c) EIGRP d) OSPF e) BGP f) Integriertes IS-IS 2. Welche der folgenden Routing-Protokolle gelten als Link-State-Protokolle? a) RIPv1 b) RIPv2 c) EIGRP d) OSPF e) BGP f) Integriertes IS-IS 3. Welche der folgenden Routing-Protokolle verwenden eine Metrik, die standardmig auch von der Verbindungsbandbreite beeinflusst wird? a) RIPv1 b) RIPv2 c) EIGRP d) OSPF e) BGP

Kapitel 8 Theorie zu Routing-Protokollen

387

4. Welche der folgenden inneren Routing-Protokolle untersttzen VLSM? a) RIPv1 b) RIPv2 c) EIGRP d) OSPF e) Integriertes IS-IS 5. Welche der folgenden Situationen wrde bewirken, dass ein Router, der RIPv2 verwendet, alle Routen entfernt, die er von einem bestimmten benachbarten Router erlernt hat? a) Ausfall von RIP-Keepalives b) Ausbleiben von Updates von diesem Nachbarn c) Eintreffen von Updates fnf oder mehr Sekunden, nachdem das letzte von diesem Nachbarn kommende Update empfangen wurde. d) Empfang von Updates von diesem Nachbarn, bei denen das globale Flag Route Bad gesetzt ist. 6. Welche der folgenden Eigenschaften von Distanzvektor-Protokollen verhindert Routing-Schleifen dadurch, dass das Routing-Protokoll nur einen Teil der bekannten Routen verffentlicht (statt der gesamten RoutingTabelle, wie es unter normalen Umstnden der Fall wre)? a) Count to Infinity b) Poison Reverse c) Holddown d) Split-Horizon e) Route-Poisoning 7. Welches der folgenden Distanzvektor-Merkmale verhindert RoutingSchleifen durch Verteilung eines Metrikwertes von unendlich fr eine ausgefallene Route? a) Holddown b) Vollstndige Updates c) Split-Horizon d) Route-Poisoning

388

CCNA ICND2-Prfungshandbuch

8. Ein Router, der ein Distanzvektor-Protokoll verwendet, hat gerade ein Routing-Update empfangen, das eine Route mit einem unendlichen Metrikwert auffhrt. Das vorherige Routing-Update dieses Nachbarn gab eine gltige Metrik an. Was wre keine normale Reaktion auf ein solches Szenario? a) Sofortiger Versand eines Teil-Updates, das eine Poison-Route fr die ausgefallene Route enthlt b) Versetzen der Route in den Holddown-Zustand c) Unterbinden von Split-Horizon fr diese Route und Versenden einer Poison-Reverse-Route d) Senden eines vollstndigen Updates mit einer Poison-Route anstelle der ausgefallenen Route 9. Ein Netzwerk setzt ein Link-State-Protokoll ein. Die Router haben alle LSAs geflutet, und das Netzwerk ist stabil. Was mssen die Router tun, um die LSAs neu zu fluten? a) Jeder Router flutet alle LSAs unter Verwendung eines Timers, der auf einen bestimmten Zeitraum festgelegt ist (hnlich einem UpdateTimer bei Distanzvektor-Protokollen). b) Jeder Router flutet alle LSAs unter Verwendung eines Timers, der jedoch auf einen wesentlich lngeren Zeitraum festgelegt ist als ein Update-Timer bei Distanzvektor-Protokollen. c) Die Router fluten die LSAs nicht neu, solange sich diese nicht ndern. d) Die Router fluten alle LSAs neu, wenn sich ein LSA ndert. 10. Wie whlt ein Router mit einem Link-State-Protokoll die beste Route zum Erreichen eines Subnetzes aus? a) Der Router entnimmt die beste Route einer Link-State-Datenbank. b) Der Router berechnet die beste Route, indem er den SPF-Algorithmus unter Verwendung der Daten in der Link-State-Datenbank ausfhrt. c) Der Router vergleicht die fr das betreffende Subnetz in den von den Nachbarn empfangenen Updates angegebenen Metriken und whlt die Route mit der besten (d. h. der niedrigsten) Metrik aus.

Kapitel 8 Theorie zu Routing-Protokollen

389

8.2

Wissensgrundlage

Routing-Protokolle definieren verschiedene Mglichkeiten, wie Router untereinander kommunizieren knnen, um die besten Routen zu jedem Ziel zu ermitteln. In dem Mae, wie Netzwerke im Laufe der Zeit immer komplexer wurden, wurden auch Router mit immer hheren Prozessorleistungen und mehr RAM ausgestattet. Infolgedessen entwickelten Techniker auch immer neue Routing-Protokolle, die die Vorteile schnellerer Verbindungen und schnellerer Router zu nutzen wussten. Das vorliegende Kapitel orientiert sich in gewissem Sinne an diesem Fortschritt. Am Anfang steht zunchst eine Einfhrung in die Routing-Protokolle. Nachfolgend steht eine Erklrung der Theorie zu den Distanzvektor-Protokollen, die mit den allerersten IP-Routing-Protokollen eingesetzt wurden. Der letzte Abschnitt dieses Kapitels erlutert die theoretischen Grundlagen zu Link-State-Protokollen. Auf diesen basierend arbeiten eine Reihe neuerer Routing-Protokolle.

8.3

bersicht zu den dynamischen Routing-Protokollen

ANMERKUNG
Wenn Sie anhand der in der Einleitung empfohlenen Lesereihenfolge vorgehen, sollten Sie Routing-Protokolle bereits aus dem CCENT/CCNA ICND1-Prfungshandbuch kennen. In diesem Fall sollten Sie den Text von hier bis einschlielich zur berschrift Zusammenfassung zu den IGP-Vergleichen berspringen, da die nun folgenden Seiten Themen behandeln, die bereits in Kapitel 14 des ICND1-Buches abgedeckt wurden. Router setzen drei Methoden ein, um IP-Routen zu ihren Routing-Tabellen hinzuzufgen: direkt angeschlossene Routen, statische Routen und mithilfe dynamischer Routing-Protokolle erlernte Routen. Bevor wir jedoch zu tief in die Materie einsteigen, ist es wichtig, ein paar wesentliche Termini zu definieren und mgliche Verstndnisprobleme bezglich der Begriffe RoutingProtokoll, geroutetes Protokoll und routbares Protokoll zu klren. Die Konzepte hinter diesen Termini sind eigentlich nicht besonders schwierig; da sich jedoch die Begriffe so sehr hneln und ihre Verwendung in vielen Dokumentationen eher nachlssig gehandhabt wird, knnen sie ein wenig verwirrend sein. Die Begriffe sind wie folgt definiert: Routing-Protokoll: Eine Anzahl von Nachrichten, Regeln und Algorithmen, die von Routern eingesetzt werden, um Routen zu erlernen. Dieser Vorgang umfasst den Austausch und die Analyse von Routing-Daten.
Wichtig!

390

CCNA ICND2-Prfungshandbuch

Jeder Router whlt die beste Route in jedes Subnetz aus (Pfadauswahl) und legt diese schlielich in seiner IP-Routing-Tabelle ab. Beispiele fr solche Protokolle sind RIP, EIGRP, OSPF und BGP. Geroutetes oder routbares Protokoll: Beide Begriffe bezeichnen ein Protokoll, das eine Paketstruktur und eine logische Adressierung definiert und Routern so die Weiterleitung das Routing von Paketen gestattet. Router leiten Pakete weiter, die von gerouteten bzw. routbaren Protokollen definiert sind. Beispiele fr geroutete Protokolle sind IP und IPX (ein Protokoll, das Bestandteil des Novell NetWare-Protokollmodells ist).

ANMERKUNG
Der Begriff Pfadauswahl bezeichnet manchmal den Teil der Funktionalitt eines Routing-Protokolls, in dessen Verlauf die beste Route ausgewhlt wird. Zwar unterscheiden sich Routing-Protokolle wie RIP und geroutete Protokolle wie IP voneinander, doch arbeiten beide Typen sehr eng zusammen. Der Routing-Prozess leitet IP-Pakete weiter; wenn ein Router aber keine Routen in seiner Routing-Tabelle hat, die der Zieladresse eines Pakets entsprechen, verwirft er das Paket. Router brauchen Routing-Protokolle, um alle mglichen Routen zu erlernen und diese zur Routing-Tabelle hinzuzufgen, damit beim Routing geroutete Protokolle wie IP weitergeleitet werden knnen.

8.3.1

Funktionen von Routing-Protokollen

Die Cisco IOS-Software untersttzt verschiedene IP-Routing-Protokolle, die alle die folgenden allgemeinen Funktionen untersttzen:
Wichtig!

1. Der Router erlernt Routing-Daten zu IP-Subnetzen, die er von anderen benachbarten Routern erhlt. 2. Der Router gibt Routing-Daten zu IP-Subnetzen an andere benachbarte Router weiter. 3. Sind mehrere Routen in ein bestimmtes Subnetz vorhanden, so whlt der Router die beste Route basierend auf einer Metrik aus. 4. Wenn sich etwa durch den Ausfall einer Verbindung die Netzwerktopologie ndert, reagiert der Router dadurch, dass er zunchst bekannt gibt, dass Routen ausgefallen sind. Dann whlt er eine neue beste Route aus. (Diesen Vorgang bezeichnet man als Konvergenz.)

Kapitel 8 Theorie zu Routing-Protokollen

391

ANMERKUNG
Wenn zwei Router an dieselbe Verbindung (z. B. eine WAN-Leitung oder dasselbe Ethernet-LAN) angeschlossen sind, sind diese Router benachbart. Abbildung 8.1 zeigt in einem Beispiel drei der vier genannten Funktionen. Sowohl R1 als auch R3 erlernen eine Route in das Subnetz 172.16.3.0/24 von R2 (Funktion 1). Nachdem R3 die Route nach 172.16.3.0/24 von R2 erlernt hat, gibt er diese Route gegenber R1 bekannt (Funktion 2). Danach muss R1 entscheiden, welche der beiden Routen, mit denen sich das Subnetz 172.16.3.0/24 erreichen lsst, die bessere ist: die Route mit der Metrik 1 von R2 oder die Route mit der Metrik 2 von R3. R1 whlt die Route mit der kleineren Metrik aus, die ber R2 verluft (Funktion 3).

172.16.5.253 FA0/0

R3
S0/1 S0/0 Ich kenne eine Route zu 172.16.3.0/24 mit der Metrik 2. Ich kenne eine Route zu 172.16.3.0/24 mit der Metrik 1.

Ich verwende die Route ber S0/0, weil sie die niedrigere Metrik aufweist. S0/1 FA0/0 172.16.1.251 S0/0 S0/0 172.16.2.252 S0/1 172.16.6.252 FA0/1 172.16.3.252

R1

R2
Ich kenne eine Route zu 172.16.3.0/24 mit der Metrik 1.

Routing-Tabelle auf R1 Subnetz Ausgangsschnittstelle Nchster Hop 172.16.3.0 S0/0 172.16.2.252 Metrik 1

Abbildung 8.1: Drei der vier Grundfunktionen von Routing-Protokollen

Konvergenz ist die vierte hier aufgefhrte Funktion eines Routing-Protokolls. Der Begriff verweist auf einen Vorgang, der stattfindet, wenn die Topologie sich ndert, das heit, wenn ein Router oder eine Verbindung ausfallen bzw. wieder online gehen. Bei nderungen knnen sich die besten Routen im Netzwerk ndern. Konvergenz bezeichnet einfach gesagt den Vorgang, in dessen Verlauf alle Router bemerken, dass etwas anders ist, die

392

CCNA ICND2-Prfungshandbuch

Informationen zu nderungen allen anderen Routen bekannt geben und abschlieend die jeweils besten Routen fr die Subnetze auswhlen. Die Fhigkeit der schnellen Konvergenz ohne Erstellung von Routing-Schleifen ist einer der wichtigsten Gesichtspunkte bei der Auswahl des zu verwendenden Routing-Protokolls. In Abbildung 8.1 knnte eine Konvergenz stattfinden, wenn die Verbindung zwischen R1 und R2 ausfllt. In diesem Fall sollte R1 die alte (direkt ber R2 verlaufende) Route in das Subnetz 172.16.3.0/24 nicht mehr verwenden, sondern Pakete stattdessen an R3 senden.

8.3.2

Interne und externe Routing-Protokolle

Es gibt zwei grundstzliche Kategorien von Routing-Protokollen: IGPs (Interior Gateway Protocols) und EGPs (Exterior Gateway Protocols). Diese sind wie folgt definiert:
Wichtig!

IGP: Ein Routing-Protokoll, das zur Verwendung innerhalb eines einzelnen autonomen Systems (AS) vorgesehen ist. EGP: Ein Routing-Protokoll, das zur Verwendung zwischen mehreren autonomen Systemen vorgesehen ist.

ANMERKUNG
Der Begriff Gateway ist in den Gattungsbezeichnungen vorhanden, da Router frher als Gateways bezeichnet wurden. Diese Definitionen verwenden einen neuen Begriff: das autonome System (AS). Ein AS ist ein Netzwerkverbund, der administrationsseitig unter Kontrolle einer einzigen Organisation steht. So ist ein Netzwerkverbund, der von einem einzelnen Unternehmen eingerichtet (und bezahlt) wird, ebenso wahrscheinlich ein AS wie einer, der von einer Lehranstalt betrieben wird. Weitere Beispiele sind Behrden, die ebenfalls eigene Netzwerke betreiben knnen, und auch ein Internetprovider verfgt meist ber ein eigenes AS. Einige Routing-Protokolle funktionieren konstruktionsbedingt am besten innerhalb eines AS; solche Protokolle bezeichnet man als IGPs. Umgekehrt werden Routing-Protokolle, deren Zweck der Austausch von Routen zwischen Routern in separaten autonomen Systemen ist, als EGPs bezeichnet. Gegenwrtig gibt es aber mit BGP (Border Gateway Protocol) nur ein echtes EGP. Jedem AS kann eine Nummer zugeordnet werden, die als ASN (AS-Nummer) bezeichnet wird. Die internationale Kontrolle ber die Vergabe von

Kapitel 8 Theorie zu Routing-Protokollen

393

ASNs ist hnlich wie bei IP-Adressen der ICANN (Internet Corporation for Assigned Network Numbers, http://www.icann.org) vorbehalten. Die ICANN delegiert diese Zustndigkeit an weitere Organisationen in aller Welt (meist diejenigen, die auch ffentliche IP-Adressen vergeben). In Nordamerika etwa ist die ARIN (American Registry for Internet Numbers, http://www.arin.net/) hierfr zustndig. Abbildung 8.2 zeigt einen kleinen Ausschnitt aus dem Internet. Dargestellt sind zwei Unternehmen und drei Internetprovider (ISPs), die in ihren Netzwerken IGPs (OSPF und EIGRP) verwenden; AS-bergreifend wird BGP eingesetzt.
ASN 100 ASN 200 BGP Unternehmen 1 Subnetze des Netzwerks 9.0.0.0 EIGRP BGP ASN 300 BGP ISP2 EIGRP ASN 500 BGP ISP4 EIGRP ISP3 OSPF BGP ASN 400

Unternehmen 5 Subnetze des Netzwerks 9.0.0.0 OSPF

Abbildung 8.2: Vergleich von Standorten fr die Verwendung von IGPs und EGPs

8.3.3

IGPs vergleichen

Gegenwrtig haben Sie bei der Auswahl eines EGP eigentlich keine Alternative: Sie verwenden schlicht und einfach BGP. Bei der Entscheidung fr ein IGP, das Sie innerhalb einer Organisation einsetzen wollen, haben Sie hingegen mehrere Optionen. Die sinnvollsten Auswahlmglichkeiten sind RIPv2, EIGRP und OSPF. Von diesen drei Routing-Protokollen wurde

394

CCNA ICND2-Prfungshandbuch

RIPv2 bereits ausfhrlich im CCENT/CCNA ICND1-Prfungshandbuch behandelt. OSPF und EIGRP werden wir detailliert in den Kapiteln 9 bzw. 10 beschreiben. Im vorliegenden Abschnitt wollen wir ein paar Aspekte vorstellen, mit denen sich die verschiedenen IGPs vergleichen lassen.

IGP-Algorithmen
Der einem Routing-Protokoll zugrunde liegende Algorithmus bestimmt, wie das Routing-Protokoll seine Aufgabe erledigt. Der Begriff Routing-Algorithmus verweist im Wesentlichen auf die Logik und die Prozesse, die verschiedene Routing-Protokolle einsetzen, um das Problem des Erlernens aller Routen, der Auswahl der jeweils besten Route zu den einzelnen Subnetzen und die Konvergenz infolge von nderungen im Netzwerk zu lsen. Es gilt bei den Algorithmen von IGP-Routing-Protokollen drei Hauptvarianten zu unterscheiden:
Wichtig!

Distanzvektor-Algorithmen (diese heien manchmal nach ihren Entdeckern auch Bellman-Ford-Algorithmen) Link-State-Algorithmen Hybrid-Algorithmen (werden gelegentlich auch erweiterte Distanzvektor-Algorithmen genannt) Historisch betrachtet waren die Distanzvektor-Protokolle die zuerst entwickelten Protokolle. Sie stammen in erster Linie aus den frhen 1980er-Jahren. RIP war das erste IP-Distanzvektor-Protokoll, das grere Verbreitung fand. Kurz darauf wurde dann das proprietre Cisco-Protokoll IGRP (Interior Gateway Routing Protocol) vorgestellt. Doch in den frhen Neunzigerjahren fhrten die eher langsame Konvergenz und eine gewisse Neigung zur Bildung von Routing-Schleifen bei Distanzvektor-Protokollen zur Entwicklung alternativer Routing-Protokolle, die neuartige Algorithmen einsetzten. Link-State-Protokolle insbesondere OSPF und integriertes IS-IS beseitigten die wesentlichen Probleme von Distanzvektor-Protokollen, erforderten aber zumindest in mittelgroen und groen Netzwerken einen erheblichen Planungsaufwand. Etwa zur gleichen Zeit, als OSPF vorgestellt wurde, entwickelte Cisco ein proprietres Routing-Protokoll namens EIGRP (Enhanced Interior Gateway Routing Protocol), das einige Funktionalitten des frheren IGRP-Protokolls aufgriff. EIGRP beseitigte dieselben Probleme wie die Link-State-Protokolle, erforderte aber bei der Implementierung des Netzwerks weitaus weniger Planung. Im Laufe der Zeit wurde EIGRP als eigener Routing-Protokolltyp klassifiziert, das heit, weder unter den Distanzvektor- noch unter den Link-State-Protokollen subsummiert; man bezeichnete EIGRP als Hybrid-Protokoll oder erweitertes Distanzvektor-Protokoll.

Kapitel 8 Theorie zu Routing-Protokollen

395

Der zweite und der dritte Hauptabschnitt dieses Kapitels behandeln Distanzvektor- bzw. Link-State-Algorithmen ausfhrlich. Kapitel 10 erlutert Hybrid-Konzepte im Rahmen der Beschreibung von EIGRP.

Metriken
Routing-Protokolle whlen die besten Router zum Erreichen eines Subnetzes basierend auf der niedrigsten Metrik aus. RIP beispielsweise verwendet einen Zhler fr die Anzahl der Router (Hops) zwischen einem Router und dem Zielsubnetz. Tabelle 8.2 listet die wichtigsten IP-Routing-Protokolle fr die CCNA-Prfungen auf und macht einige Angaben zu den jeweiligen Metriken.
Tabelle 8.2: IGP-Metriken
IGP Metrik Beschreibung

RIPv1, RIPv2 Anzahl der Hops Anzahl der Router (Hops) zwischen einem Router und dem Zielsubnetz OSPF Kosten Summe der Kostenwerte aller Schnittstellen fr alle Verbindungen einer Route (der Kostenwert basiert standardmig auf der Schnittstellenbandbreite) Basiert auf der langsamsten Verbindung der Route und der Gesamtlatenz aller Schnittstellen auf der Route.

EIGRP

Mischung aus Bandbreite und Latenz

Anders als RIPv1 und RIPv2 gibt es bei OSPF und EIGRP verschiedene bandbreitenspezifische Einstellungen, die sich auf die Metrik auswirken. Abbildung 8.3 vergleicht die Auswirkungen der von RIP und EIGRP verwendeten Metrik. Wie in der Abbildung oben gezeigt, verluft die RIP-Route von Router B nach 10.1.1.0 ber Router A, weil dessen Route eine kleinere Anzahl von Hops aufweist (1) als die Route ber Router C (2). In der unteren Hlfte der Abbildung hingegen whlt Router B bei Verwendung von EIGRP die Route mit den zwei Hops ber Router C aus, weil die Bandbreiten der beiden Verbindungen in der Route wesentlich hher (und damit besser) sind als die der Ein-Hop-Route. Beachten Sie, dass hier EIGRP die richtige Wahl trifft, weil der Netzwerktechniker die Schnittstellenbandbreite korrekterweise so konfiguriert hat, dass sie den tatschlichen Verbindungsgeschwindigkeiten entspricht. (Der Schnittstellenbefehl bandwidth ndert die tatschliche physische Geschwindigkeit nicht, sondern teilt dem IOS lediglich mit, welche Geschwindigkeit es fr die Schnittstelle ansetzen soll.)

396

CCNA ICND2-Prfungshandbuch
RIP (unabhngig von der Bandbreite)
Bandbreite 1544 S0

64 kbps

B
S1 Routing-Tabelle des Subnetzes

Subnetz 10.1.1..0
T/1 Bandbreite 1544 T/1

Subnetz Bandbreite 1544 10.1.1.0

Ausgangsschnittstelle S0

EIGRP
Bandbreite 64 S0

64 kbps

B
S1 Routing-Tabelle des Subnetzes

Subnetz 10.1.1..0
T/1 Bandbreite 1544 T/1

Subnetz Bandbreite 1544 10.1.1.0

Ausgangsschnittstelle S1

Abbildung 8.3: Vergleich der Metriken von RIP und EIGRP

IGPs im Vergleich: Zusammenfassung


Um einen bequemen Vergleich zu ermglichen und das Lernen zu erleichtern, fasst Tabelle 8.3 zahlreiche der von den verschiedenen IGPs untersttzten Merkmale zusammen. Die Tabelle enthlt Elemente, die in diesem oder in frheren Kapiteln dieses Buches erwhnt wurden.
Tabelle 8.3: IGPs im Vergleich
Wichtig!

Merkmal Klassenlos Untersttzt VLSM Sendet Maske im Update Distanzvektor-Protokoll Link-State-Protokoll Untersttzt Autosummierung

RIPv1 Nein Nein Nein Ja Nein Nein

RIPv2 Ja Ja Ja Ja Nein Ja Ja Nein

EIGRP OSPF Ja Ja Ja Nein* Nein Ja Ja Ja Ja Ja Ja Nein Ja Nein Ja Nein

IS-IS Ja Ja Ja Nein Ja Nein Ja Nein

Untersttzt die manuelle Summierung Nein Proprietr Nein

Kapitel 8 Theorie zu Routing-Protokollen


Tabelle 8.3: IGPs im Vergleich (Forts.)
Merkmal RIPv1 RIPv2 Ja Ja Langsam EIGRP OSPF Ja Ja Ja Ja Ja

397

IS-IS

Routing-Updates werden an eine Mul- Nein ticast-IP-Adresse gesendet Untersttzt eine Authentifizierung Konvergenz Nein Langsam

Sehr Schnell Schnell schnell

* EIGRP wird hufig als Hybrid-Protokoll bezeichnet. In einigen Dokumenten ist auch von einem erweiterten Distanzvektor-Protokoll die Rede.

Ergnzend zu Tabelle 8.3 fhrt Tabelle 8.4 verschiedene weitere Eigenschaften zu RIPv2, OSPF und EIGRP auf. Die dort genannten Eigenschaften werden in den Kapiteln 9 und 10 ausfhrlicher erklrt, sind aber der Vollstndigkeit halber hier bereits enthalten.
Tabelle 8.4: Vergleich der Merkmale von RIPv2, EIGRP und OSPF
Merkmale Metrik RIPv2 Anzahl der Hops Ja (alle 30 Sekunden) Vollstndiges Update 224.0.0.9* 16 Nein OSPF Verbindungskosten Nein Teil-Update 224.0.0.5, 224.0.0.6 224 1 Nein EIGRP Funktion aus Bandbreite und Latenz Nein Teil-Update 224.0.0.10 232 1 Ja

Sendet regelmige Updates Vollstndige oder TeilUpdates Wohin werden Updates gesendet? Als unendlich betrachtete Metrik Untersttzt Lastausgleich bei ungleichen Kosten

* Diese Tabelle bezieht sich zwar ausdrcklich auf RIPv2, aber der einzige Unterschied zwischen RIPv1 und RIPv2 besteht was die in der Tabelle aufgefhrten Eigenschaften angeht darin, dass RIPv1 Updates als Broadcasts an die IP-Adresse 255.255.255.255 schickt.

8.3.4

Administrative Distanz

Viele Unternehmen und Organisationen verwenden nur ein einziges Routing-Protokoll. In manchen Fllen allerdings muss ein Unternehmen mehrere Routing-Protokolle einsetzen. Beispielsweise mssen zwei Unternehmen, die Ihre Netzwerke miteinander verbinden, um Daten auszutauschen, auch

398

CCNA ICND2-Prfungshandbuch

Routing-Daten austauschen. Wenn das eine Unternehmen RIP, das andere jedoch auf mindestens einem Router EIGRP verwendet, dann mssen sowohl RIP als auch EIGRP benutzt werden. Der betreffende Router kann dann die via RIP erlernten Routen in EIGRP und umgekehrt bekannt machen. Diesen Vorgang bezeichnet man als Redistribution der Routen. Abhngig von der Netzwerktopologie erlernen die beiden Routing-Protokolle unter Umstnden Routen in dieselben Subnetze. Wenn ein einzelnes Routing-Protokoll mehrere Routen in dasselbe Subnetz kennt, entscheidet es anhand der Metrik, welche dieser Routen die beste ist. Erlernen allerdings zwei unterschiedliche Routing-Protokolle Routen in dasselbe Subnetz, dann kann IOS deren Metriken nicht vergleichen, da diese auf jeweils unterschiedlichen Daten basieren. Beispielsweise knnte RIP eine Route in das Subnetz 10.1.1.0 mit der Metrik 1 und EIGRP eine Route nach 10.1.1.0 mit der Metrik 2.195.416 erkennen, und doch knnte EIGRP die bessere Route bieten. Muss es aber nicht. Es gibt einfach keine Basis fr den Vergleich zwischen den zwei Metriken. Wenn das IOS zwischen Routen whlen muss, die es mithilfe verschiedener Routing-Protokolle erlernt hat, nutzt es das Konzept der administrativen Distanz. Die administrative Distanz ist eine Zahl, die angibt, wie glaubwrdig ein Routing-Protokoll auf einem einzelnen Router ist. Je niedriger der Zahlenwert, desto besser oder glaubwrdiger ist das Routing-Protokoll. RIP beispielsweise hat vorgabeseitig eine administrative Distanz von 120, EIGRP eine Distanz von 90. EIGRP ist also glaubwrdiger als RIP. Wenn also beide Routing-Protokolle Routen in dasselbe Subnetz erlernen, fgt der Router nur die EIGRP-Route zur Routing-Tabelle hinzu. Administrative Distanzwerte werden Router-bezogen konfiguriert, das heit, sie werden nicht mit anderen Routern ausgetauscht. Tabelle 8.5 fhrt die verschiedenen Quellen fr Routing-Daten sowie deren jeweilige standardmige administrative Distanz auf.
Tabelle 8.5: Administrative Standarddistanzen
Wichtig!

Routentyp Angeschlossene Route Statische Route BGP (externe Routen) EIGRP (interne Routen) IGRP OSPF

Administrative Distanz 0 1 20 90 100 110

Kapitel 8 Theorie zu Routing-Protokollen


Tabelle 8.5: Administrative Standarddistanzen (Forts.)
Routentyp IS-IS RIP EIGRP (externe Routen) BGP (interne Routen) Nicht nutzbar Administrative Distanz 115 120 170 200 255

399

ANMERKUNG
Der Befehl show ip route gibt die administrative Distanz als erste der beiden Zahlen in den Klammern an. (Die zweite Zahl in den Klammern ist die Metrik.) Die Tabelle zeigt die Standardwerte fr administrative Distanzen, aber im IOS kann die nderung der administrativen Distanz fr ein bestimmtes Routing-Protokoll, eine bestimmte Route oder sogar eine statische Route konfiguriert werden. Der Befehl ip route 10.1.3.0 255.255.255.0 10.1.130.253 beispielsweise definiert eine statische Route mit einer administrativen Standarddistanz von 1. Der Befehl ip route 10.1.3.0 255.255.255.0 10.1.130.253 210 definiert die gleiche Route, nun jedoch mit einer administrativen Distanz von 210.

8.4

Merkmale von Distanzvektor-Protokollen

Dieser Abschnitt beschreibt die Grundlagen zu Distanzvektor-Protokollen. Als Beispiel soll uns RIP dienen. Beginnen wollen wir diesen Abschnitt mit einer Beschreibung des Normalbetriebs von Distanzvektor-Protokollen, gefolgt von einer ausfhrlichen Erluterung der zahlreichen Funktionen von Distanzvektor-Protokollen zur Vermeidung von Routing-Schleifen.

8.4.1

Das Prinzip von Distanz und Vektor

Der Begriff Distanzvektor beschreibt, was ein Router ber jede Route wei. Nach Abschluss des Vorgangs, bei dem ein Router eine Route in ein Subnetz erlernt, kennt der Router lediglich ein Distanzma (die Metrik) und den nchsten Router im Pfad sowie die Ausgangsschnittstelle, die er verwenden muss, um diesen Router zu erreichen (dies ist ein Richtungspfeil oder Vektor). Damit Sie besser erfassen knnen, was ein Distanzvektor-Protokoll tut, zeigt Abbildung 8.4 eine Ansicht dessen, was der Router mit einem Distanzvektor-Protokoll erlernt.

400

CCNA ICND2-Prfungshandbuch

Die Abbildung zeigt ein Netzwerk, in dem R1 drei Routen zum Subnetz X erlernt: Eine ber R2 fhrende Route mit vier Hops Eine ber R5 fhrende Route mit drei Hops Eine ber R7 fhrende Route mit zwei Hops

R2
Subnetz X, Metrik 4 Subnetz X, Metrik 3

R3

R4

Subnetz X

R1

R5

R6

R8

Subnetz X, Metrik 2

R7
Routing-Update

Abbildung 8.4: Mithilfe von Distanzvektor-Protokollen erlernte Informationen

R1 erfhrt von der Existenz des Subnetzes und erhlt eine mit diesem Subnetz verknpfte Metrik und sonst nichts. Dann muss R1 die beste Route auswhlen, um Subnetz X zu erreichen. In diesem Fall whlt er die Route ber R7 mit zwei Hops aus, da diese Route die niedrigste Metrik aufweist. Um die Bedeutung des Begriffs Distanzvektor weiter zu verdeutlichen, betrachten Sie bitte Abbildung 8.5. Sie zeigt, was R1 wirklich ber das Subnetz X in Abbildung 8.4 wei.

Wichtig!

Distanzvektor-Topologie zum Hops Erreichen von Subnetz X R2, 4 Nach aus der Sicht von R1
Nach R5, 3 Hops

R2

R1
Nach R7, 2 Ho ps

R5

Subnetz X

R7

Abbildung 8.5: Grafische Darstellung des Distanzvektor-Prinzips

Kapitel 8 Theorie zu Routing-Protokollen

401

Letztendlich kennt R1 das Subnetz X lediglich als drei Vektoren. Die Lnge der Vektoren reprsentiert die Metrik, die beschreibt, wie gut (oder schlecht) die einzelnen Routen sind. Die Richtung des Vektors ist der nchste Router im Pfad. Mithin erlernen Routing-Protokolle bei Verwendung von Distanzvektoralgorithmen nicht allzu viel ber das Netzwerk, wenn sie RoutingUpdates erhalten. Sie kennen lediglich die Funktion eines Vektors: als Lnge die Distanz (Metrik), um das Subnetz zu erreichen, als Richtung den Nachbarn, der die Route ausgewiesen hat.

8.4.2

Betrieb von Distanzvektor-Protokollen in einem stabilen Netzwerk

Distanzvektor-Protokolle senden regelmig vollstndige Routing-Updates. Abbildung 8.6 veranschaulicht dieses Prinzip in einem einfachen Netzwerk mit zwei Routern, drei LAN-Subnetzen und einem WAN-Subnetz. Die Abbildung zeigt die vollstndigen Routing-Tabellen beider Router, in denen alle vier Routen aufgefhrt sind, und die von den Routern regelmig gesendeten vollstndigen Updates.
Routing-Tabelle von R1 Quelle Ausgangsschnittstelle RIP 172.30.21.0/24 S0/0 RIP 172.30.22.0/24 S0/0 Verbindung 172.30.1.0/24 S0/0 Verbindung 172.30.11.0/24 Fa0/0 Subnetz Nchster Hop 172.30.1.2 172.30.1.2 N/A N/A Metrik 1 1 0 0 Routing-Tabelle von R2 Quelle Verbindung Verbindung Verbindung RIP Subnetz 172.30.21.0/24 172.30.22.0/24 172.30.1.0/24 172.30.11.0/24 Ausgangsschnittstelle Fa0/0 Fa0/1 S0/1/0 S0/1/0 Nchster Hop N/A N/A N/A 172.30.1.1 Metrik 0 0 0 1

FA0/1 - 172.30.22.2/24 FA0/0 172.30.11.1 S0/0 172.30.1.1 S0/1/0 172.30.1.2

R1
172.30.11.0, Metrik 1

R2

FA0/0 - 172.30.21.2/24

RIP-Update

172.30.21.0, Metrik 1 172.30.22.0, Metrik 1

RIP-Update

RIP-Update

172.30.11.0, Metrik 1

172.30.21.0, Metrik 1 172.30.22.0, Metrik 1

RIP-Update

Abbildung 8.6: RIP-Normalbetrieb in einem stabilen Netzwerk

402

CCNA ICND2-Prfungshandbuch

Um den Betrieb des Distanzvektor-Protokolls in dieser Abbildung besser verstehen zu knnen, wollen wir uns auf die Frage konzentrieren, was Router R1 in Bezug auf das Subnetz 172.30.22.0/24 das an die Schnittstelle Fa0/ 1 von R2 angeschlossene Subnetz erlernt: 1. R2 wei, dass er ber eine Route mit null Hops in das Subnetz 172.30.22.0/24 verfgt, d. h., im von R2 gesendeten Routing-Update (welches unterhalb des Router-Symbols von R2 angezeigt ist) gibt R2 die Metrik 1 (ein Router im Pfad) fr die Route bekannt. 2. R1 empfngt das RIP-Update von R2, und weil R1 keine anderen mglichen Routen nach 172.30.22.0/24 erlernt hat, muss diese Route die beste Route von R1 in das Subnetz sein. 3. R1 fgt das Subnetz als via RIP erlernte Route zu seiner Routing-Tabelle hinzu. 4. Fr die erlernte Route verwendet R1 die Ausgangsschnittstelle S0/0, weil er das Routing-Update von R2 ber genau diese Schnittstelle empfangen hat. 5. Fr die erlernte Route verwendet R1 als nchsten Router im Pfad 172.30.1.2, weil er die Route ber ein RIP-Update erlernt hat, dessen Absender-IP-Adresse 172.30.1.2 lautete. Am Ende dieses Vorgangs hat R1 eine neue Route erlernt. Die verbleibenden via RIP erlernten Routen in diesem Beispiel folgen demselben Prozess. Neben dem Vorgang des Ausweisens und Erlernens von Routen beleuchtet Abbildung 8.6 auch einige andere wichtige Tatsachen zu Distanzvektor-Protokollen:
Wichtig!

Regelmige Updates: Das Sanduhrsymbol deutet die Tatsache an, dass die Updates auf regelmiger Basis versendet werden. Standardmig verwendet RIP ein Intervall von 30 Sekunden. Vollstndige Updates: Der Router sendet stets vollstndige Updates, nicht nur neue oder genderte Routing-Daten. Beschrnkung durch die Split-Horizon-Regeln: Das Routing-Protokoll lsst im Sinne der Split-Horizon-Regeln einige Routen in den regelmigen vollstndigen Updates weg. Split-Horizon ist eine Funktion zur Vermeidung von Routing-Schleifen, die wir weiter unten behandeln werden.

Kapitel 8 Theorie zu Routing-Protokollen

403

8.4.3

Routing-Schleifen verhindern

Wie Sie sehen, ist der eigentliche Betrieb von Distanzvektor-Protokollen relativ simpel. Leider ergibt sich aufgrund dieser Einfachheit die Mglichkeit, dass Routing-Schleifen entstehen. Routing-Schleifen treten auf, wenn Router Pakete so weiterleiten, dass dasselbe Pakete immer wieder beim selben Router landet, der es dann stets ber dieselbe Route weiterleitet. Hierdurch wird nicht nur Bandbreite vergeudet, sondern das Paket wird auch niemals an den Empfnger ausgeliefert. In Produktionsnetzwerken kann eine hohe Anzahl derart kreisender Pakete das Netzwerk so stark verstopfen, dass es unbrauchbar wird. Insofern mssen Routing-Schleifen unbedingt vermieden werden. Der Rest dieses Abschnitts widmet sich der Beschreibung diverser Funktionen von Distanzvektor-Protokollen zur Vermeidung solcher Schleifen.

Route-Poisoning
Wenn eine Route ausfllt, besteht bei Distanzvektor-Protokollen die Mglichkeit, dass Routing-Schleifen entstehen, solange nicht alle Router im Netzwerkverbund wissen, dass die ursprngliche Route ausgefallen ist. Also bentigen Distanzvektor-Protokolle eine Mglichkeit, genau festzustellen, welche Routen ausgefallen sind. Distanzvektor-Protokolle verbreiten die schlechten Nachrichten zum Ausfall einer Route mithilfe des Route-Poisonings. Dieser Begriff verweist auf die Praxis, die Route mit einem speziellen Metrikwert von unendlich auszuweisen. Einfach gesagt, betrachten Router Routen, fr die eine solche unendliche Metrik bermittelt wird, als ausgefallen. Beachten Sie, dass alle Distanzvektor-Protokolle einen Metrikwert kennen, der unendlich darstellt. RIP etwa definiert Unendlichkeit als 16. Abbildung 8.7 zeigt exemplarisch das Route-Poisoning mit RIP. Die Schnittstelle Fa0/1 von R2 und damit auch die Route von R2 nach 172.30.22.0/24 ist ausgefallen.

ANMERKUNG
Zwar haben Routen, die bei RIP Gegenstand des Route-Poisonings geworden sind, die Metrik 16, aber der Befehl show ip route zeigt diesen Metrikwert nicht an. Stattdessen erscheint die Meldung possibly down.

404

CCNA ICND2-Prfungshandbuch
Routing-Tabelle von R2 Nchster Hop 172.30.1.2 172.30.1.2 N/A N/A Metrik 1 16 0 0 Quelle Ausgangsschnittstelle Verbindung 172.30.21.0/24 Fa0/0 Verbindung 172.30.22.0/24 Fa0/1 Verbindung 172.30.1.0/24 S0/1/0 RIP 172.30.11.0/24 S0/1/0 1 FA0/1 - 172.30.22.2/24 FA0/0 172.30.11.1 S0/0 172.30.1.1 S0/1/0 172.30.1.2 Subnetz Nchster Hop N/A N/A N/A 172.30.1.1 Metrik 0 0 0 1

Routing-Tabelle von R1

Wichtig!

Quelle

Ausgangsschnittstelle RIP 172.30.21.0/24 S0/0 RIP 172.30.22.0/24 S0/0 Verbindung 172.30.1.0/24 S0/0 Verbindung 172.30.11.0/24 Fa0/0

Subnetz

R1
3

R2

FA0/0 - 172.30.21.2/24

172.30.21.0, Metrik 1 172.30.22.0, Metrik 16

Abbildung 8.7: Route-Poisoning

Abbildung 8.7 zeigt den folgenden Ablauf: 1. Die Schnittstelle Fa0/1 von R2 fllt aus. 2. R2 entfernt die angeschlossene Route nach 172.30.22.0/24 aus seiner Routing-Tabelle. 3. R2 macht 172.30.22.0 mit dem Metrikwert fr unendlich (im Falle von RIP 16) bekannt. 4. R1 behlt die Route mit dem unendlichen Metrikwert zunchst in seiner Routing-Tabelle und entfernt sie dann. Jeder Metrikwert, der kleiner ist als der Wert fr unendlich, kann als gltiger Metrikwert einer gltigen Route betrachtet werden. Bei RIP bedeutet dies, dass eine Route mit 15 Hops eine gltige Route ist. Bei den grten Unternehmensnetzwerken der Welt liegen maximal vier oder fnf Router zwischen zwei beliebigen Subnetzen. Der maximale Metrikwert von 15 Hops ist also durchaus ausreichend.

Das Count-to-Infinity-Problem bei einer Einzelverbindung


Bei Distanzvektor-Protokollen besteht in dem Zeitraum zwischen der Feststellung eines Routenausfalls durch einen ersten Router und dem Zeitpunkt, an dem alle Router wissen, dass die Route ausgefallen ist, das Risiko der Entstehung von Routing-Schleifen. Ohne die in diesem Kapitel erluterten Mechanismen zur Vermeidung von Schleifen kann bei einem DistanzvektorProtokoll ein Problem auftreten, das als Count to Infinity bezeichnet wird. Natrlich knnen Router niemals unendlich lange hochzhlen, doch ihre Version der Unendlichkeit (engl. Infinity) im Falle von RIP also etwa 16 knnen sie durchaus erreichen.

Kapitel 8 Theorie zu Routing-Protokollen

405

Count to Infinity verursacht zwei miteinander verwandte Probleme, die zu verhindern Aufgabe diverser Funktionen von Distanzvektor-Protokollen ist: Pakete knnen im Netzwerk kreisen, whrend die Router immer weiter hochzhlen. Hierdurch wird Bandbreite verbraucht, was die Betriebsfhigkeit des Netzwerks einschrnken kann. Der Count-to-Infinity-Vorgang dauert mehrere Minuten. Whrend dieses Zeitraums glauben Benutzer, dass das Netzwerk ausgefallen ist. Wenn das Count-to-Infinity-Problem auftritt, bedeutet dies, dass die Router ihre Ansicht zur Metrik der ausgefallenen Route stndig ndern. Die Metrik nimmt dann langsam an Wert zu, bis sie schlielich den Wert unendlich erreicht und erst jetzt erkennen die Router, dass die Route wohl ausgefallen sein muss. Am besten lsst sich dieses Konzept durch ein Beispiel veranschaulichen. Abbildung 8.8 zeigt den Beginn eines Count-to-Infinity-Problems.
Routing-Tabelle von R1 (nach Schritt 4) Quelle Ausgangsschnittstelle RIP 172.30.21.0/24 S0/0 RIP 172.30.22.0/24 S0/0 Verbindung 172.30.1.0/24 S0/0 Verbindung 172.30.11.0/24 Fa0/0 Subnetz Nchster Hop 172.30.1.2 172.30.1.2 N/A N/A Metrik 1 16 0 0 Routing-Tabelle von R2 (nach Schritt 4) Quelle Ausgangsschnittstelle Verbindung 172.30.21.0/24 Fa0/0 RIP 172.30.22.0/24 Fa0/1 Verbindung 172.30.1.0/24 S0/1/0 RIP 172.30.11.0/24 S0/1/0 1 FA0/1 - 172.30.22.2/24 FA0/0 172.30.11.1 S0/0 172.30.1.1 S0/1/0 172.30.1.2 Subnetz Nchster Hop N/A 172.30.1.1 N/A 172.30.1.1 Metrik 0 2 0 1

R1
2 172.30.22.0, Metrik 2 (andere Routen werden nicht angezeigt) 2

R2
172.30.22.0, Metrik 16 (andere Routen werden nicht angezeigt) Ausgefallene Route

FA0/0 - 172.30.21.2/24

Meine alte 1-Hop-Route nach 172.30.22.0 ist ausgefallen. Routing-Tabelle bitte ndern!

Hier ist eine neue 2-Hop-Route nach 172.30.22.0. Bitte zu meiner Routing-Tabelle hinzufgen!

Abbildung 8.8: R2 nimmt flschlicherweise an, dass R1 ber eine Route nach 172.16.22.0/24 verfgt.

Der Schlssel zu diesem Beispiel besteht darin, dass das regulre Update, das R1 an R2 sendet (in Abbildung 8.8 von links nach rechts), in praktisch demselben Moment erfolgt wie das Route-Poisoning von R2. Abbildung 8.8 zeigt den folgenden Ablauf: 1. Die Schnittstelle Fa0/1 von R2 fllt aus, das heit, R2 entfernt die angeschlossene Route nach 172.30.22.0/24 aus seiner Routing-Tabelle. 2. R2 macht die Route gegenber R1 als ausgefallene Route (mit dem Metrikwert 16 bei RIP) bekannt, aber im gleichen Moment luft der Update-

406

CCNA ICND2-Prfungshandbuch

Timer auf R1 ab, d. h., R1 sendet sein regulres Update. Dieses liefert unter anderem eine Route nach 172.30.22.0 mit der Metrik 2. 3. R2 erhlt auf diese Weise Kenntnis von der Route nach 172.30.22.0 mit der Metrik 2. Da R2 nicht mehr ber eine Route in das Subnetz 172.30.22.0 verfgt, trgt er die erhaltenen Routeninformationen fr dieses Subnetz (zwei Hops, nchster Hop R1) in seine Routing-Tabelle ein. 4. Etwa zur gleichen Zeit wie Schritt 3 empfngt R1 das Update von R2, welches besagt, dass die vormals vorhandene Route nach 172.30.22.0 ber R2 nun ausgefallen ist. Insofern trgt R1 in seine Routing-Tabelle den Metrikwert 16 fr die Route nach 172.30.22.0 ein. An diesem Punkt nun leiten R1 und R2 Pakete, die fr 172.30.22.0/24 vorgesehen sind, an den jeweils anderen Router weiter. R2 enthlt eine Route nach 172.30.22.0/24, die auf R1 verweist, und auf R2 finden wir die umgekehrte Konfiguration. Die Schleife bleibt bestehen, bis die Zhler beider Router den Wert unendlich erreichen. Abbildung 8.9 zeigt nun den nchsten Schritt auf dem gemeinsamen Weg in die Unendlichkeit.
Routing-Tabelle von R1 Quelle Ausgangsschnittstelle RIP 172.30.21.0/24 S0/0 RIP 172.30.22.0/24 S0/0 Verbindung 172.30.1.0/24 S0/0 Verbindung 172.30.11.0/24 Fa0/0 Subnetz Nchster Hop 172.30.1.2 172.30.1.2 N/A N/A Metrik 1 3 0 0 Routing-Tabelle von R2 Quelle Ausgangsschnittstelle Verbindung 172.30.21.0/24 Fa0/0 RIP 172.30.22.0/24 S0/1/0 Verbindung 172.30.1.0/24 S0/1/0 RIP 172.30.11.0/24 S0/1/0 Subnetz Nchster Hop N/A 172.30.1.1 N/A 172.30.1.1 Metrik 0 16 0 1

FA0/1 - 172.30.22.2/24 FA0/0 172.30.11.1 S0/0 172.30.1.1 S0/1/0 172.30.1.2

R1
1 172.30.22.0, Metrik 2 (andere Routen werden nicht angezeigt) 1 172.30.22.0, Metrik 3 (andere Routen werden nicht angezeigt)

R2

FA0/0 - 172.30.21.2/24

Ich habe gerade von einer neuen gltigen Route mit der Metrik 3 gehrt. Bitte zu meiner Routing-Tabelle hinzufgen!

Meine 2-Hop-Route ist ausgefallen. Bitte als ausgefallen kennzeichnen (Metrik 16)!

Abbildung 8.9: Count to Infinity auf R1 und R2

Abbildung 8.9 zeigt die nachfolgenden regulren Updates auf beiden Routern: 1. Die Update-Timer von R1 und R2 laufen etwa um dieselbe Zeit ab. R1 gibt eine ausgefallene Route (Metrik 16) bekannt, R2 eine Route mit der Metrik 3. (Sie wissen ja noch, dass bei RIP der Wert 1 zur Metrik hinzugezhlt wird, bevor die Route weitergegeben wird.)

Kapitel 8 Theorie zu Routing-Protokollen

407

2. R2 erhlt das Update von R1 und stellt seine Route nach 172.30.22.0 folgerichtig auf den Metrikwert 16 um. 3. Etwa zur gleichen Zeit wie Schritt 2 erhlt R1 das Update von R2 und stellt seine Route nach 172.30.22.0 ebenso konsequent auf den Metrikwert 3 um. Der Prozess setzt sich bei jedem regulren Update-Zyklus fort, bis beide Router am Ende beim Metrikwert 16 ankommen. An dieser Stelle knnen die Router die Routen ungltig werden lassen und aus ihren Routing-Tabellen entfernen.

Split-Horizon
In dem einfachen in den Abbildungen 8.8 und 8.9 verwendeten Netzwerk verfgt Router R2 ber eine direkt angeschlossene Route nach 172.30.22.0, und R1 erlernt diese Route aus einem Routing-Update, das von R2 gesendet wurde. Allerdings ist es nicht notwendig, dass R1 dieselbe Route wieder gegenber R2 bekannt macht, da R1 die Informationen ja ursprnglich von R2 erhalten hat. Insofern besteht eine Mglichkeit zur Verhinderung des in diesen Abbildungen gezeigten Count-to-Infinity-Problems darin, dass R1 das Subnetz 172.30.22.0 einfach nicht bekannt gibt. Hierbei kommt eine Funktion namens Split-Horizon zum Einsatz, die wie folgt definiert ist: Aus Routing-Updates, die ber die Schnittstelle X gesendet werden, sind Routing-Informationen zu Routen auszuklammern, die die Schnittstelle X als Ausgangsschnittstelle benutzen. Distanzvektor-Protokolle funktionieren nach einem hnlichen Prinzip wie die Verbreitung von Gerchten in der Nachbarschaft. Menschen erzhlen ihren Nachbarn irgendetwas, die es dann wiederum ihren Nachbarn weitererzhlen usw., bis die gesamte Nachbarschaft ber das neueste Gercht im Bilde ist. Entsprechend dieser Analogie wrden Sie ein Gercht, das Sie von Ihrem Nachbarn im Haus nebenan erfahren haben, diesem auch nicht noch einmal erzhlen. hnlich bedeutet Split-Horizon, dass, wenn Router R1 eine Route von R2 erlernt, keine Notwendigkeit besteht, dieselbe Route wieder an R2 zu melden. Abbildung 8.10 zeigt die Auswirkungen von Split-Horizon auf den Routern R1 und R2 im bekannten Netzwerk. Die Routing-Tabelle von R1 (oben in der Abbildung) zeigt vier Routen, von denen drei die Schnittstelle S0/0 als Ausgangsschnittstelle verwenden. Insofern verhindert Split-Horizon, dass R1 diese drei Routen in das ber die Schnittstelle S0/0 gesendete Update einbindet.
Wichtig!

408

CCNA ICND2-Prfungshandbuch
Routing-Tabelle von R2 Nchster Hop 172.30.1.2 172.30.1.2 N/A N/A Metrik 1 16 0 0 Quelle Ausgangsschnittstelle Verbindung 172.30.21.0/24 Fa0/0 Verbindung 172.30.22.0/24 Fa0/1 Verbindung 172.30.1.0/24 S0/1/0 RIP 172.30.11.0/24 S0/1/0 3 FA0/1 - 172.30.22.2/24 FA0/0 172.30.11.1 S0/0 172.30.1.1 S0/1/0 172.30.1.2 Subnetz Nchster Hop N/A N/A N/A 172.30.1.1 Metrik 0 0 0 1

Routing-Tabelle von R1 Quelle Ausgangsschnittstelle RIP 172.30.21.0/24 S0/0 RIP 172.30.22.0/24 S0/0 Verbindung 172.30.1.0/24 S0/0 Verbindung 172.30.11.0/24 Fa0/0 Subnetz

R1

R2
1 2

FA0/0 - 172.30.21.2/24

Vollstndiges 172.30.11.0, Metrik 1 Update, eingeschrnkt durch Split-Horizon

172.30.21.0, Metrik 1 172.30.22.0, Metrik 1

Vollstndiges Update, eingeschrnkt durch Split-Horizon

5 7 172.30.22.0, Metrik 16 (andere Routen werden nicht angezeigt)

172.30.11.0, Metrik 1

Abbildung 8.10: Auswirkungen von Split-Horizon ohne Poison-Reverse

Abbildung 8.10 zeigt den folgenden Ablauf: 1. R1 sendet sein regulres vollstndiges Update, das aufgrund der SplitHorizon-Regeln nur eine Route enthlt. 2. R2 sendet sein regulres vollstndiges Update, das aufgrund der SplitHorizon-Regeln nur zwei Routen enthlt. 3. Die Schnittstelle Fa0/1 von R2 fllt aus. 4. R2 entfernt die direkt angeschlossene Route nach 172.30.22.0/24 aus seiner Routing-Tabelle. 5. R2 macht 172.30.22.0 mit dem Metrikwert fr unendlich (im Falle von RIP 16) bekannt. 6. R1 hlt die Route nach 172.30.22.0 vorlufig noch in seiner RoutingTabelle, entfernt sie aber spter daraus. 7. Im nchsten regulren Update gibt R1 die Route nach 172.30.22.0 aufgrund von Split-Horizon weiterhin nicht bekannt. Split-Horizon verhindert das Auftreten des in den Abbildungen 8.8 und 8.9 gezeigten Count-to-Infinity-Problems, weil R1 die Route nach 172.30.22.0 gegenber R2 berhaupt nicht bekannt gibt. Insofern erfhrt R2 niemals von einer (falschen) alternativen Route nach 172.30.22.0. Das Cisco IOS setzt Split-Horizon per Default auf den meisten Schnittstellen ein.

Ausgefallene Route

Kapitel 8 Theorie zu Routing-Protokollen

409

ANMERKUNG
Die RIP-Implementierung durch das Cisco IOS arbeitet nicht ganz genau so wie in Schritt 7 dieses speziellen Beispiels beschrieben. Sie verwendet stattdessen eine Funktion namens Poison-Reverse, die nachfolgend beschrieben wird.

Poison-Reverse und Triggered-Updates


Distanzvektor-Protokolle knnen das Count-to-Infinity-Problem auch lsen, indem sie sicherstellen, dass jeder Router unter allen Umstnden schnellstmglich davon erfhrt, dass die Route ausgefallen ist. Die folgenden beiden Funktionen zur Verhinderung von Schleifen tun genau dieses. Sie sind wie folgt definiert: Triggered-Update: Wenn eine Route ausfllt, wird nicht auf das nchste regulre Update gewartet, sondern es wird sofort ein Update gesendet (das Triggered-Update), welches Angaben zur ausgefallenen Route enthlt. Poison-Reverse: Wenn ein Router erfhrt, dass eine Route ausgefallen ist, werden die Split-Horizon-Regeln fr diese Route vorbergehend auer Kraft gesetzt, und eine ausgefallene Route wird verteilt. Abbildung 8.11 zeigt Beispiele fr diese Funktionen. Ausgefallen ist erneut die Schnittstelle Fa0/1 von R2. Beachten Sie, dass anfangs noch alle Schnittstellen funktionieren und alle Routen bekannt sind. Abbildung 8.11 veranschaulicht die folgenden Schritte: 1. Die Schnittstelle Fa0/1 von R2 fllt aus. 2. R2 sendet sofort ein Teil-Update als Triggered-Update, welches nur die genderten Informationen enthlt in diesem Fall also die ausgefallene Route nach 172.30.22.0. 3. R1 reagiert mit einer nderung seiner Routing-Tabelle und sendet sofort ein (Triggered-)Teil-Update zurck, welches nur die Route nach 172.30.22.0 mit der Metrik unendlich (16) enthlt. Dies ist eine PoisonReverse-Route. 4. Im nchsten regulren Update von R2 sind alle typischen Routen auch die Poison-Route nach 172.30.22.0 einmalig enthalten. 5. Im nchsten regulren Update von R1 sind alle typischen Routen sowie die Poison-Route nach 172.30.22.0 einmalig enthalten.
Wichtig!

410

CCNA ICND2-Prfungshandbuch
Routing-Tabelle von R2 Nchster Hop 172.30.1.2 172.30.1.2 N/A N/A Metrik 1 16 0 0 Quelle Ausgangsschnittstelle Verbindung 172.30.21.0/24 Fa0/0 Verbindung 172.30.22.0/24 Fa/0/1 Verbindung 172.30.1.0/24 S0/1/0 RIP 172.30.11.0/24 S0/1/0 1 FA0/1 - 172.30.22.2/24 FA0/0 172.30.11.1 S0/0 172.30.1.1 S0/1/0 172.30.1.2 Subnetz Nchster Hop N/A N/A N/A 172.30.1.1 Metrik 0 0 0 1

Routing-Tabelle von R1 Quelle Ausgangsschnittstelle RIP 172.30.21.0/24 S0/0 RIP 172.30.22.0/24 S0/0 Verbindung 172.30.1.0/24 S0/0 Verbindung 172.30.11.0/24 Fa0/0 Subnetz

R1
2 3 172.30.22.0, Metrik 16 (NUR diese Route Triggered-Teil-Update)

R2

FA0/0 - 172.30.21.2/24

172.30.22.0, Metrik 16 (NUR diese Route Triggered-Teil-Update)

TriggeredTeil-Update

Nchstes regulres Update

172.30.11.0, Metrik 1 172.30.22.0, Metrik 16

172.30.21.0, Metrik 1 172.30.22.0, Metrik 16

Nchstes regulres Update

Abbildung 8.11: R2 sendet ein Triggered-Update, whrend R1 Poison-Reverse anwendet.

In diesem Beispiel reagiert R2 sofort durch Versenden des TriggeredUpdates. Auch R1 zeigt eine direkte Reaktion: Die Split-Horizon-Regeln werden fr die ausgefallene Route auer Kraft gesetzt, um eine PoisonReverse-Route zu senden. Eigentlich gilt die Poison-Route von R2 nicht als Poison-Reverse-Route, weil R2 bereits eine Route nach 172.30.22.0 ausgewiesen hat. Die Poison-Route von R1 hingegen ist eine Poison-ReverseRoute, weil sie an den Router zurckgeschickt wurde, ber den R1 von der ausgefallenen Route erfahren hat. Deswegen bezeichnen manche Bcher Poison-Reverse auch als Split-Horizon mit Poison-Reverse, weil der Router die Split-Horizon-Regel fr die ausgefallene Route auer Kraft setzt.

Das Count-to-Infinity-Problem in einem redundanten Netzwerk


Split-Horizon verhindert das Auftreten des Count-to-Infinity-Problems zwischen zwei Routern. Bei Netzwerken mit redundanten Pfaden die heute wohl eher die Regel als die Ausnahme bilden kann Split-Horizon alleine das Auftreten dieses Problems nicht verhindern. Um dieses Problem zu veranschaulichen, zeigt Abbildung 8.12 das neue funktionsfhige Netzwerk in seinem normalen Zustand: Alles funktioniert. In den Abbildungen 8.13 und 8.14 hingegen ist das Netzwerk in einem Moment dargestellt, in dem das Count-to-Infinity-Problem auftritt und zwar trotz aktivierten Split-Horizons.

Kapitel 8 Theorie zu Routing-Protokollen


Alle Adressen beginnen mit 172.30.
31.3/24 FA0/0

411

2.3 172.30.3.0, Metrik 1 172.30.21.0, Metrik 2 172.30.22.0, Metrik 2 172.30.31.0, Metrik 1

R3
S0/1 S0/0

3.3 172.30.2.0, Metrik 1 172.30.11.0, Metrik 2 172.30.31.0, Metrik 1

172.30.1.0, Metrik 1 172.30.11.0, Metrik 1 172.30.21.0, Metrik 2 172.30.22.0, Metrik 2 2.1 FA0/0 11.1

172.30.1.0, Metrik 1 172.30.11.0, Metrik 1 172.30.21.0, Metrik 1 172.30.22.0, Metrik 1 S0/1/1 3.2 FA0/1 - 22.2/24

S0/1 S0/0 1.1 S0/1/0 1.2

R1

R2

FA0/0 - 21.2/24

172.30.2.0, Metrik 1 172.30.11.0, Metrik 1 172.30.31.0, Metrik 2

172.30.3.0, Metrik 1 172.30.21.0, Metrik 1 172.30.22.0, Metrik 1 172.30.31.0, Metrik 2

Abbildung 8.12: Regulre Updates in einem stabilen, drei Router umfassenden Netzwerk

ANMERKUNG
In Abbildung 8.12 wurden der bersichtlichkeit halber die RIP-Updates weggelassen, die an die LAN-Schnittstellen bermittelt wrden. Abbildung 8.12 zeigt nicht nur den normalen Betrieb eines anderen Netzwerks, sondern stellt auch ein gutes Beispiel fr den Einsatz von Split-Horizon dar. Wenn wir das Subnetz 172.30.22.0 erneut als Beispiel verwenden, so finden in diesem Netzwerk die folgenden Vorgnge statt: 1. R2 macht gegenber R1 und R3 eine Route mit der Metrik 1 in den Updates bekannt. 2. R1 weist nachfolgend eine Route nach 172.30.22.0 mit dem Metrikwert 2 gegenber R3 aus, und R3 weist eine Route nach 172.30.22.0 mit der Metrik 2 gegenber R2 aus. 3. Sowohl R1 als auch R3 fgen die Route mit dem Wert 1, die sie direkt von R2 erlernt haben, zu ihren jeweiligen Routing-Tabellen hinzu und ignorieren die Routen mit den zwei Hops, die sie voneinander erlernt haben. So legt beispielsweise R1 die Route nach 172.30.22.0 ber die

412

CCNA ICND2-Prfungshandbuch

Ausgangsschnittstelle S0/0 und den nchsten Router 172.30.1.2 (R2) im Pfad in seiner Routing-Tabelle fest. Split-Horizon verhindert, dass R1 und R3 das Subnetz 172.30.22.0 gegenber R2 erneut ausweisen. Beachten Sie, dass Abbildung 8.12 alle RoutingUpdates fr 172.30.22.0 fettgedruckt zeigt. R1 und R3 fhren 172.30.22.0 nicht in den an R2 gesendeten Updates auf. Genau genommen weisen also alle in Abbildung 8.12 aufgefhrten Routing-Updates Auswirkungen von Split-Horizon auf. Nachdem Sie sich das in Abbildung 8.12 gezeigte Netzwerk verinnerlicht haben, betrachten Sie bitte Abbildung 8.13. Diese zeigt dasselbe Netzwerk, jedoch mit einem beginnenden Count-to-Infinity-Problem und dies trotz aktivierten Split-Horizons. Auch hier fllt zunchst die Schnittstelle Fa0/1 von R2 aus.
Alle Adressen beginnen mit 172.30.
31.3/24 FA0/0 Routing-Tabelle von R3 (nach Schritt 6) Quelle RIP Subnetz Ausgangs- Nchster Metrik schnittstelle Hop 172.30.22.0/24 S0/0 172.30.2.1 2

R3
S0/1 S0/0 3.3 2.3 3

4 172.30.22.0, Metrik 2

172.30.22.0, Metrik 16

1 S0/1 2.1 FA0/0 11.1 S0/0 1.1 S0/1/1 FA0/1 - 22.2/24 3.2 S0/1/0 1.2

R1
5

R2
2

FA0/0 - 21.2/24

172.30.22.0, Metrik 16

Routing-Tabelle von R1 (nach Schritt 5) Quelle RIP Ausgangs- Nchster Metrik schnittstelle Hop 172.30.22.0/24 S0/0 172.30.1.2 16 Subnetz

Abbildung 8.13: Count-to-Infinity-Problem in einem redundanten Netzwerk

Abbildung 8.13 veranschaulicht die nachfolgend beschriebenen Schritte. Wie gewhnlich basiert das Beispiel auf einem etwas unglcklichen Timing der regelmigen Updates, die mit dem Zeitpunkt des Routenausfalls zusammenfallen.

Kapitel 8 Theorie zu Routing-Protokollen 1. Die Schnittstelle Fa0/1 von R2 fllt aus.

413

2. R2 sendet sofort ein Teil-Update als Triggered-Update, welches nur eine Poison-Route fr 172.30.22.0 enthlt. R2 sendet das Update ber alle noch funktionierenden Schnittstellen. 3. R3 empfngt das Triggered-Update von R2, das 172.30.22.0 als PoisonRoute ausweist, und aktualisiert seine Routing-Tabelle mit einem Metrikwert von 16 fr diese Route. 4. Bevor R1 das in Schritt 2 beschriebene Update empfngt, hat er bereits sein regulres Update an R3 geschickt, in dem die Route 172.30.22.0 mit dem Metrikwert 2 als normal gesendet wird. (Beachten Sie, dass in Abbildung 8.13 der bersichtlichkeit halber ein Teil des regulren Updates von R1 weggelassen wurde.) 5. R1 empfngt das (in Schritt 2 beschriebene) Triggered-Update von R2, das 172.30.22.0 als Poison-Route ausweist, und aktualisiert seine Routing-Tabelle mit einem Metrikwert von 16 fr diese Route. 6. R3 empfngt das (in Schritt 4) von R1 gesendete regulre Update, welches eine Route mit dem Metrikwert 2 nach 172.30.22.0 angibt. Infolgedessen trgt R3 nun eine Route mit der Metrik 2 in seine Routing-Tabelle ein, die ber die Ausgangsschnittstelle S0/0 und R1 als nchsten Router im Pfad verluft. Von diesem Punkt an arbeitet R3 mit einer falschen Route nach 172.30.22.0 mit der Metrik 2, die an R1 zurckverweist. Je nachdem, zu welchem Zeitpunkt Eintrge in die Routing-Tabelle gelangen bzw. daraus gestrichen werden, leiten die Router am Ende ber das Netzwerk Pakete weiter, die an das Subnetz 172.30.22.0/24 gerichtet sind; dabei ist es durchaus mglich, dass einige Pakete eine Zeit lang im Netzwerk kreisen, solange der Count-to-Infinity-Prozess nicht abgeschlossen ist.

Holddown-Prozess und Holddown-Timer


Das letzte in diesem Kapitel behandelte Feature ist eine Funktion namens Holddown, die Schleifen und Count-to-Infinity-Probleme wie in Abbildung 8.13 verhindern soll. Distanzvektor-Protokolle verwenden den HolddownProzess in erster Linie, um die Entstehung von Schleifen infolge von Countto-Infinity-Problemen zu verhindern, die in redundanten Netzwerken auftreten. Der Begriff ist wie folgt definiert: Wenn eine Route als ausgefallen betrachtet wird, wird diese eine Zeit lang nicht beachtet, damit alle Router Gelegenheit haben, zu erfahren, dass diese Route ausgefallen ist.

414

CCNA ICND2-Prfungshandbuch

Der Holddown-Prozess weist einen Router also an, neue Angaben zur ausgefallenen Route zu ignorieren. Der Zeitraum hierfr wird durch den sogenannten Holddown-Timer bestimmt. Der Holddown-Prozess kann wie folgt zusammengefasst werden:
Wichtig!

Sobald der Router von einer ausgefallenen Route erfhrt, startet er den Holddown-Timer fr die betreffende Route. Bis zum Ablaufen des Timers ignoriert der Router dann alle Routing-Daten zur ausgefallenen Route, da andernfalls eine Routing-Schleife auftreten knnte. Informationen, die hingegen von dem Nachbarn stammen, der die Route ursprnglich ausgewiesen hat, sind glaubhaft und knnen auch vor Ablauf des Holddown-Timers verarbeitet werden. Wir wollen das Holddown-Prinzip anhand eines Beispiels veranschaulichen. Abbildung 8.14 stellt eine Wiederholung von Abbildung 8.13 dar. Hier jedoch verhindert der Holddown-Prozess auf R3 das Count-to-Infinity-Problem. Die Abbildung zeigt, wie R3 aufgrund des Holddowns alle neuen Informationen zum Subnetz 172.30.22.0 ignoriert. Wie gewhnlich sind anfangs alle Schnittstellen funktionsfhig und in Betrieb sowie alle Routen bekannt. In Schritt 1 tritt dann erneut der Ausfall der wiederholt unzuverlssigen Schnittstelle auf Router R2 auf.
Alle Adressen beginnen mit 172.30.
3 Start Holddown timer for route 172.30.22.0! 31.3/24 FA0/0 Routing-Tabelle von R3 (nach Schritt 6) Quelle RIP 6 Subnetz Ausgangs- Nchster Metrik schnittstelle Hop 172.30.22.0/24 S0/1 172.30.3.2 16

R3
S0/1 S0/0 3.3 2.3 3

4 172.30.22.0, Metrik 2 2 172.30.22.0, Metrik 16 1 S0/1 2.1 FA0/0 11.1 S0/0 1.1 2 5 Routing-Tabelle von R1 (nach Schritt 5) Quelle RIP Ausgangs- Nchster Metrik schnittstelle Hop 172.30.22.0/24 S0/0 172.30.1.2 16 Subnetz 172.30.22.0, Metrik 16 S0/1/0 1.2 S0/1/1 3.2 FA0/1 - 22.2/24

R1

R2

FA0/0 - 21.2/24

Abbildung 8.14: Mit dem Holddown-Timer Count-to-Infinity-Probleme verhindern

Kapitel 8 Theorie zu Routing-Protokollen

415

Der in Abbildung 8.14 gezeigte Ablauf ist der folgende (hierbei unterscheiden sich die Schritte 3 und 6 von Abbildung 8.13): 1. Die Schnittstelle Fa0/1 von R2 fllt aus. 2. R2 sendet sofort ein Teil-Update als Triggered-Update, welches nur eine Poison-Route fr 172.30.22.0 enthlt. R2 sendet das Update ber alle noch funktionierenden Schnittstellen. 3. R3 empfngt das Triggered-Update von R2, das 172.30.22.0 als PoisonRoute ausweist, und aktualisiert seine Routing-Tabelle mit einem Metrikwert von 16 fr diese Route. R3 aktiviert zudem den HolddownTimer fr die Route nach 172.30.22.0 (bei RIP dauert es standardmig 180 Sekunden bis zum Ablauf des Timers). 4. Bevor R1 das in Schritt 2 beschriebene Update empfngt, hat er bereits sein regulres Update an R3 geschickt, in dem die Route 172.30.22.0 mit dem Metrikwert 2 als normal gesendet wird. (Beachten Sie, dass in Abbildung 8.14 der bersichtlichkeit halber ein Teil des regulren Updates von R1 weggelassen wurde.) 5. R1 empfngt das (in Schritt 2 beschriebene) Triggered-Update von R2, das 172.30.22.0 als Poison-Route ausweist, und aktualisiert seine Routing-Tabelle mit einem Metrikwert von 16 fr diese Route. 6. R3 empfngt das (in Schritt 4) von R1 gesendete Update, welches eine Route mit dem Metrikwert 2 nach 172.30.22.0 angibt. Weil R3 diese Route jedoch in den Holddown-Zustand versetzt hat und diese neue Metrik 2 von einem anderen Router als dem erlernt hat, der die Ursprungsroute angab (nmlich R1 statt R2), ignoriert R3 die neuen RoutingDaten. Infolge d