54,95 €
Dieses Lehrbuch vermittelt Grundkenntnisse und gibt darüber hinaus tiefgehenden und fundierten Einblick in Techniken, die zum Aufbau und Betrieb großer LANs erforderlich sind. Hierbei ist auch die historische Entwicklung der LAN-Technik berücksichtigt, damit der Leser versteht, warum Multilayer-Switches heute bevorzugt eingesetzt werden. Ausgehend von der Wiederholung einiger Grundlagen aus 'Basic Internetworking, Band 2', werden diese Themen vertieft. Insbesondere das Spanning-Tree-Protokoll wird hier besonders detailliert dargestellt. Auch Layer-3-Funktionen wie Inter-VLAN-Routing und HSRP bilden einen wesentlichen Teil des Lehrbuchs. Zuletzt wird noch das IP-Multicasting, das aufgrund seiner Übertragungseffizienz immer häufiger eingesetzt wird, ausführlich behandelt. Dieses eBook eignet sich sehr gut zur Vorbereitung der Prüfung CCNP von Cisco. Aus dem Inhalt: • Entwicklung des LAN-Bereichs • Spanning-Tree und Layer-2-Switching im Detail • Spanning-Tree-Erweiterungen von Cisco und dem IEEE • Inter-VLAN- und Layer-3-Routing • Spanning-Tree-Optionen • Cisco Hot Standby Routing Protocol • Grundlagen von IP-Multicasting • IP-Multicasting im Detail • Protocol Independant Multicast (PIM-DM und PIM-SM) • Switch-Security
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 281
Veröffentlichungsjahr: 2010
This eBook has been created using the ePub-Converter of eLML (eLesson Markup Language). See www.eLML.org for more details about creating platform-independent online content.
Cover
Inhaltsverzeichnis
1. Advanced Switching
1.1. Entwicklung des LAN-Bereichs
1.1.1. 10Base2, 10Base5
1.1.2. Erweiterung durch Repeater
1.1.3. 5-4-3-2-1 Repeater-Regel
1.1.4. Erweiterung durch Bridges
1.1.5. Erweiterung durch Router
1.1.6. Erweiterung durch Switches
1.1.7. VLAN-Implementierung
1.1.8. VLAN-Implementierung mit einem Router
1.1.9. Multilayer-Switch
1.1.10. Multilayer-Switches – Netzwerkdesign
1.1.11. Netzwerkausfall 1 und 2
1.2. Grundfunktion einer Transparent-Bridge
1.2.1. Lernfunktion
1.2.2. Filtering-Funktion
1.2.3. Forwarding
1.2.4. Unknown-Unicast-Flooding
1.2.5. Broadcast-Flooding
1.2.6. Multicast-Flooding
1.2.7. Beispiel eines Kommunikationsablaufs
1.2.8. Beispiel eines Kommunikationsablaufs
1.2.9. Beispiel eines Kommunikationsablaufs
1.2.10. Beispiel eines Kommunikationsablaufs
1.2.11. Beispiel eines Kommunikationsablaufs
1.2.12. Aging-Parameter-Werte
1.2.13. Überprüfen der MAC-Adress-Tabelle
1.2.14. Bridge Redundanz
1.2.15. Duplizierte Frames
1.2.16. Inkonsistenz der MAC-Adress-Tabelle
1.2.17. Bridging-Loop
1.2.18. Spanning-Tree-Protokoll
1.2.19. Aushandlung der Root-Bridge
1.2.20. Auswahl der Root-Bridge
1.2.21. Port-Parameter
1.2.22. STP-Port-Zustände (Port States)
1.2.23. Forward-Delay-Timer des STP
1.2.24. Max-Age-Timer vom STP
1.2.25. Funktion des Max-Age-Timers
1.2.26. Ohne Max-Age-Timer
1.2.27. Layout Beispielnetzwerk
1.2.28. Verifizieren des Spanning-Tree-Protokolls - G1S1
1.2.29. Verifizieren des Spanning-Tree-Protokolls - G1S2
1.2.30. Verifizieren des Spanning-Tree-Protokolls - G1S3
1.2.31. STP-Topologie 2
1.2.32. STP-Topologie 3
1.2.33. STP-Topologie 4
1.2.34. STP-Topologie 5
1.2.35. BPDU – Paketinhalt
1.2.36. Konfigurations-BPDUs
1.2.37. Topology-Change-BPDUs
1.2.38. Beispielnetzwerk mit STP-Topologie
1.2.39. Verifizieren des Spanning-Tree Protokolls – G1S1 Detail
1.2.40. Verifizieren des Spanning-Tree-Protokolls – G1S2 Detail
1.2.41. Verifizieren des Spanning-Tree-Protokolls - G1S3 Detail
1.3. Der Layer-2-Switch
1.3.1. Der Switch im Schichtenmodell
1.3.2. Vergleich zwischen Bridges und Switches
1.3.3. Switch mit einem einzigen VLAN
1.3.4. Switch mit zwei VLANs
1.3.5. Physikalische LANs
1.3.6. Virtuelle LANs
1.3.7. Nachteile einer Switching-Umgebung
1.3.8. Vorteil von VLANs
1.3.9. Switchübergreifende VLANs
1.3.10. Nachteil von VLAN-Umgebungen
1.3.11. Cisco-ISL
1.3.12. IEEE 802.1Q
1.3.13. Statische VLANs
1.3.14. Dynamische VLANs
1.3.15. Dynamische VLANs
1.3.16. Eigenschaften des VTP-Protokolls
1.3.17. VTP-Terminologie
1.3.18. VTP-Transparent-Modus
1.3.19. Verhalten der VTP-Modi
1.3.20. VTP-Advertisements
1.3.21. VTP-Advertisement-Request
1.3.22. VTP-Summary-Advertisement
1.3.23. VTP-Subset-Advertisement
1.3.24. Configuration-Revision-Nummer
1.3.25. Einfügen eines neuen Switches
1.3.26. Nachteil von VLAN-Umgebungen
1.3.27. Nachteil von VLAN-Umgebungen
1.3.28. Lösung: VTP-Pruning
1.3.29. Layout Beispielnetzwerk
1.3.30. IP-Konfiguration
1.3.31. Schnittstelle VLAN 1
1.3.32. Trunk-Konfiguration – G1S1
1.3.33. Trunk-Verifikation – G1S1
1.3.34. VTP-Konfiguration – G1S1
1.3.35. VTP-Verifikation – G1S2
1.3.36. VTP-Konfiguration – G1S3
1.3.37. VTP-Verifikation – G1S3
1.3.38. VLAN-Konfiguration – G1S1
1.3.39. VLAN-Verifikation – G1S1
1.3.40. VLAN-Konfiguration – G1S3
1.3.41. VLAN-Verifikation – G1S3
1.3.42. Weitere Verifikationsbefehle
1.3.43. Verifikation des Schnittstellen-Status – G1S3
1.3.44. Verifikation des Switchports - G1S3
1.3.45. Komplette Konfiguration - G1S1
1.3.46. Quell-MAC-basiertes Load-Balancing
1.3.47. Ziel-MAC-basiertes Load-Balancing
1.3.48. Etherchannel-Technik
1.3.49. Zusammenfassen von Schnittstellen
1.3.50. Konfiguration des Fast-Etherchannels
1.3.51. Verifikation des Fast-Etherchannels – G1S1
1.3.52. Trunk-Verifikation – G1S1
1.3.53. Komplette Konfiguration – G1S1
1.3.54. Verifikation des Spanning-Trees – G1S1
1.3.55. Verifikation des Spanning-Trees – G1S2
1.3.56. Verifikation des Spanning-Trees – G1S3
1.3.57. Aktivieren des VTP-Prunings
1.3.58. Verifizieren des VTP-Prunings
1.4. Layer-3-Routing
1.4.1. Layout Beispielnetzwerk
1.4.2. Konfiguration des Cisco ISL
1.4.3. Konfiguration des IEEE 802.1Q
1.4.4. Layout des Beispielnetzwerks
1.4.5. Konfiguration des IP-Routings – G1S1
1.4.6. Konfiguration des IP-Routings – G1S2
1.4.7. VLAN-Schnittstellen – G1S1
1.4.8. Verifikation des IP-Routings - G1S1
1.4.9. Logische Sichtweise
1.4.10. Layout Beispielnetzwerk
1.4.11. Routing und Switching
1.4.12. Core-Routing-Konfiguration – G1S1
1.4.13. Core-Routing-Konfiguration – G1S2
1.4.14. Core-Routing-Verifikation – G1S1
1.5. Spanning-Tree-Erweiterungen -- Cisco
1.5.1. Status Blocking
1.5.2. Netzausfall 1
1.5.3. Netzausfall 2
1.5.4. Neustart einer Endstation
1.5.5. Uplinkfast
1.5.6. Uplinkfast – Eigenschaften
1.5.7. Eigenschaften von Uplinkfast
1.5.8. Eigenschaften von Uplinkfast
1.5.9. Backbonefast
1.5.10. Backbonefast
1.5.11. Portfast
1.5.12. Restriktionen von Portfast
1.5.13. Mehrere STP-Instanzen
1.5.14. Vorteil von PVST
1.5.15. Eindeutige Bridge-ID pro VLAN (früher)
1.5.16. Eindeutige Bridge-ID pro VLAN (heute)
1.5.17. Extended-System-ID im Detail
1.5.18. Eigenschaften der Extended-System-ID
1.5.19. Aktivieren von Uplinkfast
1.5.20. Aktivieren von Backbonefast
1.5.21. Aktivieren von Portfast
1.5.22. Optimieren von PVST
1.5.23. Spanning-Tree-Verifikation – G1S3
1.5.24. Spanning-Tree-Verifikation – G1S1 und G1S2
1.5.25. Spanning-Tree-Schnittstellen-Verifikation – G1S3 und G1S1
1.5.26. Spanning-Tree-Schnittstellen-Verifikation – G1S2
1.6. Spanning-Tree-Erweiterungen – IEEE
1.6.1. Aushandlung der Root-Bridge
1.6.2. Port-Rollen (Port Roles)
1.6.3. Port-Zustände (Port States)
1.6.4. RSTP-BPDU
1.6.5. Alternate-Port/Discarding- bzw. Blocking-Zustand
1.6.6. Netzausfall 1
1.6.7. Netzausfall 2
1.6.8. Proposal-Flag
1.6.9. Agreement-Flag
1.6.10. Konvergenzverhalten von RSTP
1.6.11. Proposal-/Agreement-Funktion
1.6.12. Link-Typen
1.6.13. Edge-Port
1.6.14. Portkosten-Parameter
1.6.15. Aktivieren des Rapid-PVST
1.6.16. MST-Instanzen
1.6.17. MST-Regionen
1.6.18. MST-Instanz 0 und STP-Kompatibilität
1.6.19. Aktivieren von RSTP und MST
1.6.20. Bridge-Priorität
1.6.21. Root-Funktion
1.6.22. Verifizieren von MST und RSTP
1.6.23. Verifizieren des MST
1.6.24. Spanning-Tree-Verifikation – G1S3
1.6.25. Spanning-Tree-Verifikation – G1S1 und G1S2
1.6.26. Spanning-Tree-Schnittstellen-Verifikation - G1S3 und G1S1
1.6.27. Spanning-Tree-Schnittstellen-Verifikation - G1S2
1.7. Spanning-Tree-Optionen
1.7.1. Problembeschreibung
1.7.2. Anwendung des BPDU-Guards
1.7.3. Konfigurieren des BPDU-Guards
1.7.4. Problembeschreibung
1.7.5. Anwendung des Root-Guards
1.7.6. Konfigurieren des Root-Guards
1.8. Hot-Standby-Routing-Protokoll
1.8.1. Standard-Gateway
1.8.2. Proxy-ARP-Funktion
1.8.3. Proxy-ARP-Funktion
1.8.4. Grundfunktionalität des HSRP
1.8.5. HSRP-Failover
1.8.6. Interface-Tracking im HSRP
1.8.7. Interface-Tracking und Failover
1.8.8. Lastverteilung mit dem HSRP
1.8.9. Lastverteilung und Failover
1.8.10. Aktivieren des HSRP
1.8.11. Konfigurieren von mehreren HSRP-Gruppen
1.8.12. Konfigurieren des Interface-Trackings
1.8.13. Verändern der HSRP-Timer
1.8.14. HSRP-Verifikation im Detail – R1 und R2
1.8.15. Zusammengefasste HSRP-Verifikation – R1 und R2
1.8.16. Debugging des HSRP
1.8.17. Layout Beispielnetzwerk
1.8.18. HSRP-Konfiguration – G1S1
1.8.19. HSRP-Konfiguration – G1S2
1.8.20. HSRP-Verifikation – G1S1 und G1S2
1.8.21. HSRP-Verifikation im Detail – G1S1 und G1S2
1.9. Grundlagen des IP-Multicastings
1.9.1. Unicast-Verkehrsbeziehungen
1.9.2. Broadcast-Verkehrsbeziehung
1.9.3. Multicast-Verkehrsbeziehung 1 (one-to-many, Audio-/Video-Server)
1.9.4. Multicast-Verkehrsbeziehung 2 (many-to-many, Videokonferenz)
1.9.5. Videokonferenz durch Unicasts
1.9.6. Videokonferenz durch Broadcasts
1.9.7. Videokonferenz durch Multicasts
1.9.8. Cisco IP/TV Server und IP/TV Client
1.9.9. UCL-Anwendungen
1.9.10. UCL-Anwendung – Multicast Session Directory (SDR)
1.9.11. Lokale Gruppenregistrierung
1.9.12. Lokale Gruppenregistrierung
1.9.13. Verwaltung lokaler Gruppen
1.9.14. Multicast-Flooding gemäß IEEE 802.1D
1.9.15. Multicast-Registrierungsprotokolle
1.9.16. Globale Gruppenbekanntgabe
1.9.17. Globale Gruppenverwaltung und Gruppenbekanntgabe
1.9.18. Multicast-Routing-Protokolle
1.9.19. Komplexität des Multicast-Routings
1.9.20. Distribution-Tree
1.9.21. Distribution-Tree – neuer Empfänger und ehemaliger Empfänger bzw. weiterer neuer Empfänger
1.9.22. Shortest-Path-Tree (SPT) / Source-Distribution-Tree
1.9.23. SPT-Eigenschaften
1.9.24. SPT-Eigenschaften
1.9.25. Shared-Distribution-Tree
1.9.26. Eigenschaften eines Shared-Distribution-Trees
1.9.27. Eigenschaften eines Shared-Distribution-Trees
1.9.28. Multicast-Routing-Protokolle
1.9.29. PIM-DM
1.9.30. PIM-DM
1.9.31. PIM-DM
1.9.32. PIM-DM
1.9.33. PIM-DM
1.9.34. PIM-SM
1.9.35. PIM-SM
1.9.36. PIM-SM
1.9.37. PIM-SM
1.9.38. PIM-SM
1.9.39. PIM-SM-SPT-Switchover
1.9.40. Multicast-Scoping
1.9.41. TTL-Schwellenwerte
1.9.42. TTL-Schwellenwerte
1.9.43. TTL-Schwellenwerte
1.9.44. TTL-Schwellenwerte
1.9.45. Klasse-D-Adressbereich
1.9.46. Adressstruktur des IP-Multicastings
1.9.47. Zuordnung von Multicast-IP- zu Multicast-MAC-Adresse
1.9.48. Zuordnung von Multicast-IP- zu Multicast-MAC-Adresse
1.9.49. Adress-Überschneidungs-Verhältnis von 32:1
1.10. IP-Multicasting im Detail
1.10.1. General IGMP Membership Query
1.10.2. IGMP Membership Report
1.10.3. Keine explizite Gruppenbekanntgabe durch PIM-DM
1.10.4. Fluten von Multicast-Daten
1.10.5. Multicast-Status (Forwarding)
1.10.6. Assert-Funktion
1.10.7. Schnittstelle Prune
1.10.8. SPT-Zustand
1.10.9. Prune-Meldung
1.10.10. SPT-Endzustand
1.10.11. Reflooding-Intervall von 3 Minuten
1.10.12. Assert-Meldung
1.10.13. Prune-Meldung
1.10.14. Graft-Meldung
1.10.15. Graft-Ack-Meldung – SPT-Erweiterung
1.10.16. IGMP-Leave-Group-Meldung
1.10.17. IGMP Membership Query
1.10.18. IGMP-Group-Timeout – Prune-Meldung
1.10.19. Layout Beispielnetzwerk
1.10.20. Aktivieren von IP-Multicasting und PIM-Dense-Modus
1.10.21. Verifizieren des IP-Multicastings
1.10.22. PIM-Schnittstellen-Parameter
1.10.23. Neighbor-Tabelle des PIM
1.10.24. IGMP-Schnittstellen-Parameter
1.10.25. Neustart von SDR ohne Multicast-Sitzungen
1.10.26. IGMP-Gruppeninformation
1.10.27. IGMP-Gruppeninformation
1.10.28. Multicast-Routing-Tabelle – R1
1.10.29. Multicast-Routing-Tabelle – R4
1.10.30. SDR-Session-Announcement
1.10.31. Multicast-Routing-Tabelle – R1
1.10.32. Multicast-Routing-Tabelle – R4
1.10.33. WBD-Sitzung / 1. Member Join
1.10.34. IGMP-Gruppeninformation
1.10.35. WBD-Sitzung / Fluten von Multicast-Daten
1.10.36. Multicast-Routing-Tabelle – R1 und R2
1.10.37. WBD-Sitzung / 2. Member Join
1.10.38. Multicast-Routing-Tabelle – R1 und R2
1.10.39. WBD-Sitzung / Multicast-Daten
1.10.40. Multicast-Routing-Tabelle – R1 und R2
1.10.41. Anmeldung eines Multicast-Empfängers
1.10.42. Shared-Distribution-Tree
1.10.43. Anmeldung eines Multicast-Senders
1.10.44. Anmeldung eines Multicast-Senders
1.10.45. Anmeldung eines Multicast-Senders
1.10.46. Endzustand des Shared-Distribution-Trees
1.10.47. Übertragung der Multicast-Daten
1.10.48. Shortest-Path-Tree-Switchover
1.10.49. Shortest-Path-Tree (S, G)
1.10.50. (S, G)-Prune-Meldung (Shared-Distribution-Tree)
1.10.51. Endzustand der Distribution-Trees
1.10.52. IGMP-Leave-Group-Meldung
1.10.53. IGMP-Membership-Query
1.10.54. IGMP-Group-Timeout
1.10.55. (*, G)- & (S, G)-Prune
1.10.56. (*, G)- & (S, G)-Prune
1.10.57. (*, G)- und (S, G)-Prune und Endzustand von PIM-SM
1.10.58. Layout Beispielnetzwerk
1.10.59. Aktivieren von IP-Multicasting und PIM-Sparse-Modus
1.10.60. Verifizieren des IP-Multicastings
1.10.61. PIM-Schnittstellen-Parameter – R1 und R4
1.10.62. IGMP-Gruppeninformation
1.10.63. Multicast-Routing-Tabelle – R1 und R2
1.10.64. Multicast-Routing-Tabelle – R4
1.10.65. Multicast-Routing-Tabelle – R1 und R3
1.10.66. Multicast-Routing-Tabelle – R5
1.10.67. Multicast-Routing-Tabelle – R1 und R2
1.10.68. Multicast-Routing-Tabelle – R4
1.10.69. Multicast-Routing-Tabelle – R3
1.10.70. Multicast-Routing-Tabelle – R5
1.10.71. Konfigurieren des IGMP-Snoopings
1.10.72. Verifizieren des IGMP-Snoopings
1.10.73. Verifizieren des IGMP-Snoopings
1.10.74. RP-Kandidaten und Mapping-Agents
1.10.75. Konfiguration eines RP-Kandidaten
1.10.76. Konfiguration eines Mapping-Agents
1.10.77. Verifikation des Auto-RP
1.10.78. Optimieren des Auto-RP
1.11. Switch-Security
1.11.1. Konfigurieren der Port-Security
1.11.2. Verifizieren der Port-Security
1.11.3. Verifizieren der Port-Security
1.11.4. Konfigurieren von VLAN-Access-Control-Lists
1.11.5. Verifizieren von VLAN-Access-Control-Lists
1.12. Glossar
1.13. Stichwortverzeichnis
1.14. Metadaten "Advanced Switching"
Während in den Lehrbüchern Basic Internetworking, Band 1 und Basic Internetworking, Band 2 die Grundlagen von Computernetzwerken behandelt werden, lernen wir in diesem Lehrbuch, wie man große Campus-LANs aufbaut und betreibt. Dabei wurde die Entwicklung des LAN-Bereichs auch historisch aufgegriffen, damit dem Studierenden klar wird, wie es angefangen bei den Bridges über die Router und Layer-2-Switches zu den heutigen Multilayer-Switches gekommen ist.
Dieses Buch beginnt mit einigen Wiederholungen aus den obigen Titeln und geht dann auf alle erforderlichen Tiefen der einzelnen Protokolle ein, die in komplexen LANs benötigt werden.
In der Hoffnung, dass es uns gelungen ist, ein praxisnahes, übersichtlichen und gut leserliches Buch zu veröffentlichen, wünschen wir dem Leser viel Spaß!
Rukhsar KhanAirnet Technologie- und Bildungszentrum GmbHSeptember 2010
Die Entwicklung des LAN-Bereichs in den letzten zwei Jahrzehnten war gigantisch. Während Ende der 1980er Jahre bzw. sogar bis Mitte der 1990er Jahre noch viele LANs auf der Grundlage von Koaxialkabeln mit einer Übertragungsgeschwindigkeit von gerade einmal 10 Mbit/s für alle angeschlossenen Komponenten aufgebaut waren, existieren heute bereits dedizierte Verbindungen mit mehreren Gigabit pro Sekunde. Die Übertragungsgeschwindigkeit allein ist jedoch nicht ausschlaggebend. Die Effizienz eines Netzwerks wird von vielen weiteren Faktoren bestimmt.
Vom Koaxsegment zum Multilayer-Switch
Der Aufbau großer Campus-LANs
Die Abbildung zeigt die zwei klassischen Koaxialkabel 10Base2 und 10Base5. 10Base2 – aufgrund des geringen Kabeldurchmessers oft auch Thin-Ethernet genannt – unterstützt eine maximale Segmentlänge von ca. 2 * 100 m (genau 185 m). 10Base5 – aufgrund des größeren Kabeldurchmessers auch Thick-Ethernet genannt – hat eine maximale Segmentlänge von 5 * 100 m. Es handelt sich hierbei jeweils um Segmente, die allen angeschlossenen Komponenten eine gemeinsame (shared) Übertragungsgeschwindigkeit von 10 Mbit/s zur Verfügung stellen.
Wird die maximale Segmentlänge erreicht, kann durch sogenannte Repeater eine Verlängerung des Segmentes vorgenommen werden. Repeater sind Signalverstärker, die lediglich das elektrische Signal auf der physikalischen Schicht verstärken. Bis zu fünf Segmente können durch vier Repeater miteinander verbunden werden. Ein weiterer Repeater ist hiernach nicht mehr zulässig.
Es gibt eine bekannte Repeater-Regel, die 5-4-3-2-1 genannt wird. Diese Regel besagt, dass fünf Segmente über vier Repeater miteinander verbunden werden dürfen. Lediglich drei der insgesamt fünf Segmente dürfen aktiv sein, was bedeutet, dass nur auf drei Segmenten Komponenten angeschlossen sein dürfen. Auf zwei Segmenten dürfen keine Komponenten angeschlossen werden. Diese Segmente dienen lediglich der Verlängerung des Gesamtnetzwerks. Das Gesamtnetzwerk stellt eine große Kollisionsdomäne dar.
Der Hauptnachteil der obigen Netzwerkumgebung besteht darin, dass keine logische Trennung vorgenommen wurde. Jede Komponente, die in einer Kollisionsdomäne angeschlossen ist, teilt sich die Bandbreite mit jeder anderen angeschlossenen Komponente. In einer Kollisionsdomäne darf zu einer gegebenen Zeit nur ein einziges Signal existieren. Versenden zwei Komponenten gleichzeitig Daten, kommt es zu einer Kollision. Diese muss anschließend bereinigt werden. Um die 1990er Jahre herum gab es viele solcher Netzwerkumgebungen. Diese wuchsen damals überproportional, bis gewaltige Überlastsituationen auftraten. Als Lösung hierzu wurden Bridges eingesetzt. Diese nahmen eine logische Trennung des Netzwerks auf der Sicherungsschicht (Data Link Layer) vor. So stellte zum Beispiel jeder Port einer Bridge eine eigenständige Kollisionsdomäne dar. Hierdurch war ein paralleles Datenaufkommen möglich, was zu einem effektiv höheren Durchsatz des Gesamtnetzwerks führte. Bridges hatten jedoch einen Nachteil: Sie mußten gemäß der Spezifikation IEEE 802.1d empfangene Broadcasts auf jeden Port – außer dem empfangenden Port – weiterleiten. Daher bildete die Bridge eine einzige Broadcast-Domäne. (Abbildung).
Da die LAN-Protokolle, die um die 1990er Jahre eingesetzt wurden, sehr broadcastintensiv waren, gab es in den damaligen Bridging-Umgebungen eine sehr hohe Broadcastlast. Je größer die Netzwerke wurden, umso größer wurde auch die Broadcastlast. Die Antwortzeiten im Netzwerk stiegen enorm an, bis eine vernünftige Kommunikation nicht mehr möglich war. Als Lösung hierfür wurden Anfang bis Mitte der 1990er Jahre verstärkt Router eingesetzt. Router bilden pro Schnittstelle eine eigenständige Broadcast-Domäne. Die Broadcasts einer Broadcast-Domäne x werden nicht in eine Broadcast-Domäne y übertragen. Der Router ist sozusagen eine Broadcast-Barriere.
Ein Hauptnachteil von Routern ist die Verzögerungszeit während der Übertragung von Datenpaketen. Router sind Komponenten, die auf der Netzwerkschicht arbeiten, und müssen daher alle Datenpakete, die sie weiterleiten, bis zu dieser Schicht verarbeiten. Dies bedeutet im Einzelnen, dass die Datenpakete an der empfangenden Schnittstelle bis zum IP-Header zunächst entkapselt werden. Anschließend wird die IP-Adresse des Ziels aus dem IP-Header ausgelesen. Dann wird die Routing-Tabelle nach einem passenden Eintrag durchsucht. Sollte eine Route für die Ziel-IP-Adresse vorhanden sein, wird ermittelt, auf welcher Ausgangsschnittstelle das Datenpaket versendet werden muss. Anschließend wird das IP-Paket neu gekapselt und über die Ausgangsschnittstelle versendet. Dieser Prozess war bei den damaligen Routern softwarebasierend und löste mehrere CPU-Interrupts aus. Auch diese Tatsache trug zu der höheren Verzögerungszeit während der Datenübertragung bei.
Mitte der 1990er Jahre wurden Switches entwickelt. Im Prinzip funktionieren sie wie ihre Vorgänger, die Bridges. In der Abbildung ist zu sehen, dass auch Switches pro Interface eine eigenständige Kollisionsdomäne bilden und der gesamte Switch eine einzige Broadcast-Domäne ist. Der Hauptunterschied zu den Bridges besteht jedoch in der Übertragungszeit. Bridges waren, genauso wie Router, softwarebasierend. Dementsprechend hatten sie hohe Verzögerungszeiten während der Übertragung von Datenframes. Switches hingegen sind hardwarebasierend. Sie haben sogenannte ASIC-Chips, die das Weiterleiten von Datenframes aus der Hardware ermöglichen. Switches sind in anderen Worten „hardwarebasierende Bridges“. Der Datendurchsatz eines Switches ist um ein Vielfaches höher als der Durchsatz der alten Bridges.
Durch die VLAN-Implementierung werden anstelle einer großen Broadcast-Domäne viele kleine Broadcast-Domänen aufgebaut. Hierdurch kann die Broadcastlast zwar besser kontrolliert werden, jedoch besteht auch in jedem Netzwerk die Anforderung, dass viele VLANs miteinander kommunizieren müssen. An dieser Stelle ist wieder ein Router erforderlich. In der Abbildung ist ein externer Router zu sehen, der jeweils ein Interface in jedem VLAN hat. Somit ist er in der Lage, zwischen den VLANs zu routen. Diese Implementierung hat jedoch wieder den Nachteil, dass der Router softwarebasierend ist und somit sehr hohe Verzögerungszeiten während der Datenübertragung anfallen.
Eine endgültige Lösung, die allen heutigen Anforderungen im LAN-Bereich gerecht wird, stellen Multilayer-Switches bzw. Layer-3-Switches dar. Diese sind seit Ende der 1990er Jahre verfügbar. Bei einem Multilayer-Switch handelt es sich um eine Komponente, die sowohl Daten auf der Sicherungsschicht (Layer 2) als auch auf der Vermittlungsschicht (Layer 3) weiterleiten kann. Sowohl die Layer-2- als auch die Layer-3-Daten werden sehr schnell durch die Hardware verarbeitet. Hierfür stehen die bereits erwähnten ASIC-Chips zur Verfügung. Somit ist ein langsamer, externer Router für die Layer-3-Funktion nicht mehr erforderlich. Die Abbildung zeigt unsere bekannte VLAN-Umgebung, bestehend aus vier VLANs. Daten innerhalb eines VLANs werden vom Multilayer-Switch über den Layer 2, Daten zwischen VLANs werden über den Layer 3 weitergeleitet. Anders als bei externen Routern entspricht der Datendurchsatz des Layer-3-Forwardings dem des Layer-2-Forwardings.
Ein aktuelles Netzwerkdesign, das heute in vielen LANs eingesetzt wird, ist in der Abbildung oben zu sehen. Es besteht aus einer Netzzugangsschicht (Access Layer), kurz Zugangsschicht, und einer Verteilungsschicht (Distribution Layer). Die Zugangsschicht stellt den Zugangspunkt zum Netzwerk zur Verfügung. Hier werden Etagen-Switches eingesetzt, die den Endstationen eine optimale Anbindung an das Unternehmensnetzwerk ermöglichen. Bei den Switches der Zugangsschicht handelt es sich in der Regel um Layer-2-Switches. Die Verteilungsschicht könnte aus zwei Multilayer-Switches bestehen. Hierbei handelt es sich um die Switches, die für die Gebäudeverteilung verantwortlich sind. Die Switches der Zugangsschicht werden redundant an die beiden Multilayer-Switches angeschlossen. Die Multilayer-Switches haben auch untereinander eine oder mehrere Verbindungen. Dies könnte das Netzwerkdesign innerhalb eines Gebäudes sein. Man spricht hierbei von einem Switch-Block.
Sollte die Anforderung bestehen, einen großen Campus zu vernetzen, könnte das Netzwerkdesign aus der Abbildung oben zu einer Kernschicht (Core Layer) erweitert werden. Die Kernschicht wäre für die Anbindung der einzelnen Gebäude innerhalb des Campus verantwortlich. Die Abbildung unten zeigt zwei Switch-Blöcke, die über zwei Switches auf der Kernschicht redundant miteinander verbunden sind. Jeder weitere Switch-Block würde auf die gleiche Weise angebunden werden.
So ergibt sich eine Drei-Stufen-Hierarchie, bestehend aus Zugangs-, Verteilungs- und Kernschicht (Access-, Distribution- und Core-Layer). Jede Schicht hat eine bestimmte Aufgabe. Wie bereits erwähnt, hat die Zugangsschicht die Aufgabe, Endstationen optimal anzubinden. Auf der Verteilungsschicht sollten die rechenintensiven Funktionen durchgeführt werden. Hierzu zählt zum Beispiel die VLAN-Terminierung und somit das Inter-VLAN-Routing sowie komplexe Access-Control-Lists (Filter). Auch die Root- und die Backup-Root-Funktion des Spanning-Tree-Protokolls sollten sich auf der Verteilungsschicht abspielen. Im Normalfall wird zwischen der Verteilungs- und der Zugangsschicht über Layer 2 weitergeleitet und zwischen der Verteilungs- und der Kernschicht über Layer 3 geroutet. Jegliche Layer-2-Funktionen wie z. B. die VLANs und die Spanning-Tree-Topologie sollten an der Verteilungsschicht enden und nicht zur Kernschicht weitergereicht werden. Es soll also zwischen den einzelnen Switch-Blöcken immer über Layer 3 geroutet werden. Hierdurch wird die Broadcastlast stark eingeschränkt. Was dies alles nun genau zu bedeuten hat, wird im Laufe des Lehrbuchs näher erläutert.
AIRNET Technologie- und Bildungszentrum GmbH – http://www.airnet.deBei diesem Design handelt es sich um ein mehrfach redundantes Netzwerk. Ein derartiges Netzwerkdesign hat den Vorteil, dass mehrere Teilstrecken ausfallen können, das Netzwerk aber weiterhin funktionsfähig bleibt. Auch die Konvergenzzeit spielt eine wesentliche Rolle im Falle eines Ausfalls. Unter Konvergenzzeit wird die Zeit verstanden, die ein Netzwerk benötigt, nach Ausfall einer Teilstrecke Alternativpfade zu aktivieren. Je geringer die Konvergenzzeit in einem Netzwerk ist, umso schneller können die Komponenten die aufgrund des Ausfalls unterbrochene Kommunikation wieder aufnehmen. Die beiden Abbildungen (oben und unten) zeigen zwei verschiedene Netzwerkausfälle. Die Daten werden dann über einen Alternativpfad übertragen.
Bevor jedoch auf die Einzelheiten dieses Netzwerkdesigns eingegangen werden kann, müssen wir uns noch viele Grundlagen erarbeiten. Diese werden in den nächsten Kapiteln vermittelt. Weiter hinten in diesem Buch wird auf die Feinheiten eines solchen Netzwerkdesigns eingegangen.
AIRNET Technologie- und Bildungszentrum GmbH – http://www.airnet.deTransparent-Bridges sind die Vorgänger der heutigen Layer-2-Switches und wurden von DEC entwickelt. Sie werden seit Anfang der 1990er Jahre nicht mehr hergestellt und wurden durch die Layer-2-Switches abgelöst. Die Grundfunktion beider Komponenten ist jedoch identisch und wurde im Standard IEEE 802.1d definiert. Dies ist auch der Grund, weswegen wir mit einem Kapitel namens Grundfunktion einer Transparent-Bridge beginnen, bevor wir näher auf die Layer-2-Switches eingehen. Die Terminologie, die wir in diesem Kapitel vorstellen, wurde auf Layer-2-Switches unverändert übernommen.
Transparent-Bridging gemäß IEEE 802.1d
Redundanzen in Bridging-Umgebungen
Verifizieren des Spanning-Tree-Protokolls
Erweiterte Spanning-Tree-Parameter
Erweiterte STP-Verifizierung
Eine Bridge ist eine Plug-and-Play-Komponente, d.h., alle erforderlichen Segmente werden einfach angeschlossen. Anschließend wird sie eingeschaltet. Nachdem das Betriebssystem geladen wurde, muss die Bridge zunächst die Lernfunktion, das sogenannte Learning ausführen, da sie noch keine Kenntnis über die angeschlossenen Stationen im Netzwerk hat. Hierzu wird aus allen ankommenden Datenframes die Quell-MAC-Adresse ausgelesen und anschließend mit der zugehörigen Portbezeichnung in eine MAC-Adress-Tabelle aufgenommen. Die MAC-Adress-Tabelle ist das Herz einer Bridge. Sie wird benötigt, um später die Datenframes an die richtigen Ziel-Ports weiterzuleiten. Wurde wie in der Abbildung eine MAC-Adresse 123 am Port E0 (Ethernet0) gelernt, leitet die Bridge alle Datenframes, die an diese MAC-Adresse adressiert sind, auf den entsprechenden Port weiter. Die MAC-Adress-Tabelle wird nicht abgespeichert. Wird die Bridge neu gestartet, müssen alle Adressen erneut gelernt werden.
In unserem Beispiel sendet Station A einen Datenframe an Station B. Beide Stationen befinden sich zwar auf dem gleichen Segment, jedoch werden Datenframes, die auf ein Ethernet-Segment versendet werden, von allen angeschlossenen Stationen und auch von der Bridge empfangen. Die Bridge liest in diesem Fall lediglich die Quell-MAC-Adresse aus dem Frame aus, nimmt sie in die MAC-Adress-Tabelle auf und verwirft ihn anschließend. Station B sendet zusätzlich einen Datenframe an Station C. Dieser Frame kommt auch bei der Bridge an, und die Quell-MAC-Adresse von Station B wird ausgelesen. Das gleiche passiert mit dem Frame, der von Station C versendet wird. Alle Quell-MAC-Adressen werden mit ihrer zugehörigen Portbezeichnung in die MAC-Adress-Tabelle aufgenommen.
Wenn nun Station A und Station B miteinander kommunizieren, handelt es sich um eine lokale Kommunikation auf dem linken Segment. Die Bridge erhält zwar alle Datenframes, leitet sie aber nicht an andere Segmente weiter. Sie weiß anhand der MAC-Adress-Tabelle, dass in diesem Fall sowohl die Quellstation als auch die Zielstation auf dem gleichen Segment angeschlossen sind. Das wirkt wie ein Filter, weshalb man diese Funktion Filtering nennt.
Während Station A und Station B auf dem linken Segment miteinander kommunizieren, könnte gleichzeitig eine lokale Datenkommunikation auf dem rechten Segment stattfinden.
Das Forwarding ist für das korrekte Weiterleiten von Datenframes zuständig. Wenn aus einem ankommenden Datenframe anhand der Ziel-MAC-Adresse ersichtlich ist, dass sich die Zielstation auf einem anderen Segment befindet, wird der Frame an den entsprechenden Port weitergeleitet.
In der Abbildung sendet Station A einen Datenframe an Station C. Der Frame kommt bei der Bridge an. Diese sieht in ihrer MAC-Adress-Tabelle nach, ob die MAC-Adresse 789 vorhanden ist, und findet einen Eintrag, der über Port E1 (Ethernet1) gelernt wurde. Der Frame wird an diesen Port weitergeleitet und erreicht somit die Zielstation. Der Rückverkehr läuft in der gleichen Weise ab.
Da die Bridge nach einem Neustart noch keine Information über die angeschlossenen Stationen hat, ist die initiale MAC-Adress-Tabelle leer. Das Forwarding ist daher noch nicht möglich, denn hierfür werden Einträge in der MAC-Adress-Tabelle benötigt. Dies hätte zur Folge, dass eine Endstation solange nicht erreichbar wäre, bis sie nicht mindestens 1 Datenframe auf das Netzwerk versendet hätte. Da ein derartiges Verhalten sehr praxisfremd wäre, gibt es beim Transparent-Bridging eine Ausnahmeregelung. Sollte an einem Quellport der Bridge ein Frame mit einer unbekannten Ziel-MAC-Adresse ankommen, wird das Flooding durchgeführt. In der Fachsprache spricht man hier von einem Unknown-Unicast-Flooding.
Der Datenframe wird, in der Erwartung, dass die Zielstation antwortet, an alle angeschlossenen Segmente weitergeleitet. Sollte die Zielstation den Frame erhalten, wird sie antworten. Durch die Antwort kann die Bridge die MAC-Adresse mit der zugehörigen Portnummer in ihre MAC-Adress-Tabelle aufnehmen. Für alle weiteren Datenframes zwischen den Kommunikationspartnern ist nun kein Unknown-Unicast-Flooding mehr erforderlich, da die Bridge nun Informationen über beide MAC-Adressen besitzt.
Wenn in einem Netzwerk alle Stationen gleichzeitig adressiert werden sollen, wird von einer Quellstation ein Broadcast versendet. Die Bridge ist verpflichtet, einen empfangenen Broadcast an jeden Zielport (der Quellport ist hiervon ausgenommen) weiterzuleiten. Dies wird von jeder Bridge durchgeführt. Somit ist sichergestellt, dass der Broadcast alle Stationen, die sich in derselben Broadcast-Domäne befinden, erreicht. Dies ist unter dem Fachbegriff Broadcast-Flooding bekannt.
Das Flooding von Broadcasts stellt in einer Bridging-Umgebung die größte Belastung dar. Da LAN-Protokolle von Haus aus sehr broadcastintensiv sind, muss besonders darauf geachtet werden, dass Bridging-Umgebungen nicht zu groß werden.
Multicast-Adressen sind vordefinierte Gruppenadressen. Sie beginnen im Ethernet mit einer MAC-Adresse, in der das niederwertigste Bit des 1. Bytes gesetzt ist. Durch sie kann eine Quellstation Daten an eine Gruppe schicken. Alle Stationen, die in dieser Gruppe Mitglied sind, erhalten die Daten. Multicast-Adressen können nur als Zieladressen auftreten, Quelladressen hingegen sind immer Unicast-Adressen. Frames, die eine Multicast-Adresse enthalten, werden umgangssprachlich einfach Multicasts genannt.
Soll an einem Quellport der Bridge ein Multicast empfangen werden, muss er an jeden Zielport weitergeleitet werden. Das heißt, es findet auch hier Flooding statt.
Nachfolgend wird anhand mehrerer Abbildungen ein Kommunikationsablauf beispielhaft dargestellt.
In dieser Abbildung sendet Station A einen Frame an Station C. Wir gehen in diesem Beispiel davon aus, dass die MAC-Adresse von Station C bei Station A bereits bekannt ist. Bei den meisten Kommunikationsprotokollen müsste die MAC-Adresse der Zielstation zunächst ermittelt werden. In der Regel ist es so, dass alle Stationen eine eindeutige Adresse auf der Vermittlungsschicht (Network Layer) haben. Diese Adresse wird dann durch einen Broadcast angesprochen mit der Anforderung der Zusendung der MAC-Adresse. Alle Stationen erhalten diesen Broadcast, allerdings antwortet nur die Station mit der angegebenen Adresse. Sie sendet die angeforderte MAC-Adresse an die Quellstation zurück. Alle anderen Stationen verwerfen den Broadcast, nachdem sie feststellen, dass sie nicht angesprochen wurden.
In der Praxis würde bereits durch das Ausfindigmachen der MAC-Adresse die MAC-Adress-Tabelle der Bridge aktualisiert. Zur Veranschaulichung gehen wir in unserem Beispiel von einer leeren MAC-Adress-Tabelle der Bridge aus.
Nachdem der von Station A gesendete Datenframe bei der Bridge ankommt, liest sie die Quell-MAC-Adresse 123 aus (Learning) und schreibt sie zusammen mit der Portnummer E0 in die MAC-Adress-Tabelle. Da die Bridge die Ziel-MAC-Adresse nicht kennt, führt sie das Unknown-Unicast-Flooding aus. Das heißt, dass der Frame an jeden angeschlossenen Port (außer dem Quellport) weitergeleitet wird.
Wie in dieser Abbildung zu sehen ist, kommt der Frame aufgrund des Floodings bei Station C an. Er wurde jedoch, wie bereits beschrieben, auch an alle anderen Zielports weitergeleitet. Diese Ports wurden also unnötigerweise durch den Frame belastet. Der Flooding-Prozess muss dennoch durchgeführt werden, da ansonsten die Zielstation C nie gefunden werden kann.
In der Abbildung oben ist dargestellt, dass Station C eine Antwort an Station A sendet. Der Antwortframe kommt bei der Bridge an. Diese liest die Quell-MAC-Adresse 789 aus (Learning) und nimmt sie zusammen mit der Portbezeichnung in die MAC-Adress-Tabelle auf. Anschließend wird durch Einblick in diese Tabelle die Ziel-MAC-Adresse 123 ermittelt. Da diese MAC-Adresse über den Port E0 gelernt wurde, wird der Frame gezielt an diesen Port weitergeleitet. Dieser Vorgang ist in der Abbildung unten dargestellt.
AIRNET Technologie- und Bildungszentrum GmbH – http://www.airnet.deWie hier zu sehen ist, erreicht der Antwortframe Station A. Die weiteren Datenframes zwischen diesen beiden Stationen werden durch die Bridge direkt von Port E0 zu Port E1 und umgekehrt übertragen. Das Unknown-Unicast-Flooding findet zunächst nicht mehr statt.
Jede Bridge hat einen sogenannten Aging-Timer. Sollte eine Station für eine bestimmte Zeit keine Kommunikation mehr durchführen, wird ihre MAC-Adresse samt Portbezeichnung aus der MAC-Adress-Tabelle entfernt. Dies hat den Vorteil, dass die Tabelle so klein wie möglich gehalten wird und somit der Forwarding-Prozess schneller stattfinden kann. Es würde auch keinen Sinn ergeben, die Einträge für viele Stunden oder Tage zu pflegen, da zum Beispiel eine ausgeschaltete Station überhaupt nicht erreichbar ist. Bei den meisten Bridges und auch Switches ist der Aging-Timer auf 300 Sekunden (5 Minuten) eingestellt. Die Tabelle zeigt einen Auszug aus dem Standard IEEE 802.1d-1998. Hier ist zu sehen, dass es sich bei diesem Wert um einen empfohlenen Standardwert handelt. Sollte eine Station 300 Sekunden lang keine Kommunikation durchführen (Idle-Zeit), wird ihre MAC-Adresse aus der MAC-Adress-Tabelle entfernt. Zum erneuten Erreichen dieser Station wird bei Bedarf wieder ein Unknown-Unicast-Flooding durchgeführt. Der Aging-Timer kann jedoch von einem Bridgehersteller angepasst werden. Ein möglicher Bereich von 10 - 1 000 000 Sekunden kann gemäß dem Standard genutzt werden.
In der Abbildung ist die Ausgabe des Befehls show mac-address-table dynamic zu sehen. Dies ist der Befehl zum Überprüfen der MAC-Adress-Tabelle. Der Befehlszusatz ...dynamic sagt aus, dass lediglich die dynamisch gelernten Einträge angezeigt werden sollen. Es gibt auch einen Befehlszusatz ...static. Dieser zeigt die statischen Einträge an. Statische Einträge werden durch manuelle Konfiguration erstellt. In der ersten Spalte ist auch eine VLAN-Nummer 1 zu sehen. VLANs gab es bei den alten Bridges natürlich nicht. Da wir jedoch mit Switches arbeiten, ist diese zusätzliche Information Bestandteil der MAC-Adress-Tabelle. Standardmäßig befinden sich sämtliche Ports im VLAN 1. Näheres hierzu folgt später.
Wie in der Abbildung zu sehen, können Bridging-Umgebungen redundant ausgelegt werden. Sollte dann zum Beispiel eine Bridge ausfallen, können die Daten über die noch verfügbare Bridge übertragen werden.
Würden zwei Transparent-Bridges ohne Berücksichtigung zusätzlicher Verfahren bzw. Protokolle einfach parallel betrieben, gäbe es enorme Netzwerkprobleme. Eines der Probleme ist in der Abbildung dargestellt: Station A schickt einen Unicast-Frame an Station B. Beide Bridges leiten diesen Frame weiter. Es kommen zwei gleiche Frames bei Station B an. Dieser Fall zählt noch zu den kleineren Problemen, da die meisten Kommunikationsprotokolle auf höheren Schichten in der Lage sind, duplizierte Frames zu erkennen und anschließend zu verwerfen.
Die Abbildung zeigt das nächste Problem, das entsteht. Unicast-Frames, die von einer Bridge weitergeleitet werden, kommen über den weitergeleiteten Pfad bei der Nachbar-Bridge an. Diese lernt nun die Quell-MAC-Adresse von Station A sowohl über den oberen als auch über den unteren Port. Dies führt zu Inkonsistenzen der MAC-Adress-Tabelle.
