10 Konfiguration von IP-Multicast-Netzen

Transkript

1 79 10 Konfiguration von IP-Multicast-Netzen Nachdem in den letzten Kapiteln die Grundlagen von IP-Multicast behandelt wurden, wird hier nun der Aufbau und die Konfiguration eigener Multicast-Netze beschrieben. Dabei wird sowohl die lokale Konfiguration eines eigenen Multicast-Netzes erläutert als auch wie eine Verbindung mit dem weltweiten MBone hergestellt werden kann. Für den Aufbau von Multicast-Netzen stehen prinzipiell zwei verschiedene Möglichkeiten zur Verfügung. Entweder die vorhandenen Unicast-Router im Netz werden um Multicast-Fähigkeiten erweitert oder es werden dedizierte Multicast-Router parallel zur Unicast- Infrastruktur eingesetzt. Die Wahl eines dedizierten Routers kann verschiedene Gründe haben. So sind manche Kern-Router eines Interoder Intranets nicht Multicast-fähig oder die Multicast-Implementierung ist noch nicht stabil genug. So passiert es häufig, dass Software- Versionen, die optimal für das Unicast-Routing funktionieren, bestimmte Eigenschaften des Multicast-Routings nur mangelhaft unterstützen. Da die Kern-Router das Rückgrat des Netzes darstellen, herrschen hier auch besondere Anforderungen hinsichtlich Zuverlässigkeit, Sicherheit und Performanz. Es ist verständlich, dass Administratoren an diesen kritischen Punkten nur ungern etwas ändern. Darüber hinaus wird durch das Multicast-Routing die bestehende Netzwerkkonfiguration komplexer. Das heißt, der Einsatz von Multicast führt auch zu einem höheren Verwaltungsaufwand. Werkzeuge und Hinweise zum Management von Multicast-Netzen werden im Kapitel 11 vorgestellt. Werden dedizierte Multicast-Router eingesetzt, so müssen in der Regel Multicast-Tunnel aufgesetzt werden, um die Multicast-Router im Netz über die existierende Unicast-Infrastruktur miteinander zu verbinden. In der Tat basieren die meisten Konfigurationen im derzeitigen MBone auf dedizierten Routern und den entsprechenden Tunneln. Für die Realisierung eines Multicast-Routers stehen zwei Alternativen offen, ein»echter«router (z.b. Cisco, Nortel/BayNetworks, 3com) oder eine UNIX-basierte Lösung mit entsprechendem Routing- Prozess. Um beide Möglichkeiten abzudecken, wird in den folgenden Beispielen sowohl die Konfiguration des UNIX-basierten mrouted als Multicast-Router

2 80 10 Konfiguration von IP-Multicast-Netzen mrouted Cisco Multicast auch die Konfiguration eines Cisco-Routers als Alternativen zur Realisierung der Szenarien erläutert. Die Auswahl dieser beiden Varianten hat verschiedene Gründe. Für den Multicast-Routing-Prozess mrouted spricht, dass er zur Zeit die größte Verteilung im MBone erfährt und auch die Entwicklung des MBones einleitete. Seine Handhabung gestaltet sich sehr einfach und er ist für einen Vielzahl von UNIX-Derivaten (z.b. Linux) verfügbar. Für die Betrachtung von Cisco-Routern spricht, dass diese Router im Vergleich zu anderen Routern die meisten Multicast-Funktionalitäten besitzen und unter anderem die ersten Implementierungen des PIM-Protokolls zur Verfügung stellen. Das liegt sicher auch daran, dass sich die Cisco-Ingenieure sehr stark in der Multicast-Entwicklung der IETF engagieren und PIM maßgeblich von Cisco-Mitarbeitern mitentwickelt wurde. Weiterhin gestaltet sich die Kommandosprache des Cisco-Betriebssystems IOS als sehr anschaulich für die verschiedenen Konfigurationen, so dass die Konfigurationsschritte leicht auf andere Router übernommen werden können. Weitere Links zu anderen Herstellern von Routern, die IP-Multicast unterstützen, sind im Anhang zu finden. Provider in Deutschland 10.1 Anbindung an den MBone Im Gegensatz zu den USA, wo bereits mehrere Internet Provider Multicast-Dienste und eine Anbindung an den MBone anbieten (siehe [PROVID] im Anhang C.3), sieht es in Deutschland diesbezüglich zurzeit noch relativ schlecht aus. Neben dem Deutschen Forschungsnetz (DFN-Verein) gibt es so gut wie keinen Provider, der heute schon IP-Multicast als Dienst bereitstellt. Es ist jedoch zu erwarten, dass sich dies in naher Zukunft ändert. Provider aus den USA (wie UUNET (siehe [UCAST] im Anhang C.3), Sprint (siehe [SPRINT] im Anhang C.3), usw.) bieten ihre Dienste auch zunehmend in Deutschland an und es ist zu erwarten, dass damit früher oder später auch das Multicast-Angebot auf Deutschland ausgeweitet wird. Einige deutsche Provider experimentieren derzeit mit dem MBone. Der Münchener Provider SpaceNet betreibt beispielsweise einen experimentellen Anschluss an den MBone, der nach einer Testphase auch den Kunden zur Verfügung stehen soll (siehe [Space] im Anhang C.9). Ebenso beteiligen sich die großen Telekommunikationsdiensteanbieter wie die Deutsche Telekom seit Jahren an Forschungsvorhaben mit dem Schwerpunkt IP-Multicast, beispielsweise im Rahmen des Eurescom-Programms in den Projekten P911 oder P1010 (siehe

3 10.2 Der Multicast-Routingdämon, mrouted 81 [EURES] im Anhang C.9). Eine baldige Markteinführung ist deshalb auch von dieser Seite aus zu erwarten. Spätestens wenn immer mehr Nutzer über breitbandigere Zugangstechnologien, wie z.b. ADSL, an das Internet angebunden sind und hochratige Multimedia-Applikationen nutzen, werden auch deutsche Provider Multicast einsetzen müssen, um die Überlastung ihrer Netze zu verhindern. Eine gute Anbindung an den MBone bietet heute schon das Deutsche Forschungsnetz (DFN), das jedoch hauptsächlich Forschungsinstitute und Universitäten miteinander verbindet. Falls Sie also in einer Forschungseinrichtung oder Universität arbeiten, besteht die Möglichkeit, dass diese bereits über das DFN mit dem MBone verbunden ist. Auch große Firmen verfügen teilweise über einen Anschluss an das DFN. Eine aktuelle Liste der am DFN beteiligten Mitgliedsinstitutionen ist unter [DFNME] im Anhang C.3 zu finden. Ein einfacher Weg, um festzustellen, ob bereits eine Verbindung zum MBone besteht, ist es, das Session Directory Tool SDR aufzurufen. Werden nach einiger Zeit (spätestens nach ca. 10 Minuten) MBone-Sessions angezeigt, so kann der Multicast-Verkehr das lokale Netz erreichen, d.h. eine Verbindung zum MBone existiert bereits. Füllt sich das SDR-Hauptfenster nicht, so besteht vermutlich noch keine Verbindung zum MBone. Es lohnt sich auf jeden Fall, sich beim zuständigen Systemadministrator zu erkundigen, ob eine Verbindung zum MBone besteht oder geplant ist. Sind Sie selbst Administrator oder Einzelanwender, fragen Sie bei Ihrem Provider nach, ob dieser Multicast-Dienste anbietet oder in Zukunft unterstützen wird. Sind Sie selbst Provider, nutzen Sie die Chance, Ihren Kunden die Möglichkeiten des MBones zu erschließen. Falls Ihr Provider eine Anbindung an den MBone unterstützt und ein lokales Netz an den Multicast-Backbone angebunden werden soll, so muss ein Zugangs-Router konfiguriert werden. Die dazu nötigen Schritte werden in Kapitel beschrieben. Schon drin? Fragen Sie nach! Konfiguration des Zugangsrouters 10.2 Der Multicast-Routingdämon, mrouted Der mrouted wurde 1989 von Steve Deering an der Stanford University entwickelt (siehe [Dee91] im Anhang D.3) und war Bestandteil der IP-Multicast-Erweiterungen Version 1.1 für das BSD und SunOS UNIX. Die Weiterentwicklung lag danach in den Händen des Palo Alto Research Centers der Firma Xerox. Die neueste Version, zur Zeit der Drucklegung des Buches, Version 3.9 (beta 3) (siehe [PARCX] im Anhang C.5), hat seitdem etliche Verbesserungen durchlaufen. Xerox Parc

4 82 10 Konfiguration von IP-Multicast-Netzen Merit Kernel Patches Für viele Jahre war der mrouted der einzige vorhandene Multicast-Router. Er wurde verstärkt in Universitäten und Forschungseinrichtungen eingesetzt und führte damit zu der kontinuierlichen Verbreitung des MBones. Ohne den mrouted hätte sich der MBone vermutlich nicht zu seiner heutigen Größe entwickeln können. Die letzte offizielle Vollversion ist die Version 3.8. Es existiert darüber hinaus eine von Merit um SNMP-Fähigkeiten erweiterte Version (siehe [MERIT] im Anhang C.6). Beim Einsatz des mrouted sollte auf keinen Fall auf ältere Versionen zurückgegriffen werden, da diese gerade beim Pruning noch erhebliche Probleme bereiteten. Der mrouted ist für eine Vielzahl von UNIX-Systemen, wie z.b. Solaris, HP-UX, Irix oder Linux, verfügbar. Ältere Betriebssysteme unterstützen oft jedoch nicht alle Multicast-Funktionalitäten, die vom mrouted vorausgesetzt werden. Es sind deshalb von vielen Herstellern Multicast-Patches verfügbar, die den Betriebssystemkern (Kernel) entsprechend erweitern. Hierzu gehören u.a. Solaris 2.5, oder Irix 5.3. Einige dieser Patches befinden sich auch auf der beiliegenden CD-ROM. Neuere Betriebssystemversionen unterstützen inzwischen alle geforderten Eigenschaften (in diesem Beispiel Solaris 2.6 und Irix 6.5). Die Installation des mrouted selbst ist relativ einfach und wird von einem beiliegenden Skript übernommen Konfiguration des mrouted Virtuelle Interfaces (Vifs) Der mrouted implementiert das DVMRP-Routingverfahren gemäß RFC1075 (siehe auch Kapitel 5 ) und beherrscht IGMP in der Version 2. Er besteht aus zwei Komponenten, dem eigentlichen Dämonprogramm mrouted (normalerweise in /usr/multicast/ abgelegt) und einer zugehörigen Konfigurationsdatei mrouted.conf im /etc/- Verzeichnis. mrouted unterstützt sowohl Multicast-Routing auf physikalischen Interfaces als auch über Multicast-Tunnel, die beide transparent über so genannte virtuelle Interfaces (Vifs) angesprochen werden. Damit der mrouted startet, müssen mindestens zwei Vifs vorhanden sein. Das können entweder mehrere Netzwerkkarten oder als weiteres Beispiel ein Ethernet Interface plus ein oder mehrere Tunnel sein. Der mrouted reagiert auf die folgenden Signale, die beim Betrieb des Routers unter anderem sehr nützlich für die Fehlersuche sind: USR1 schreibt die internen Routingtabellen in /usr/tmp/mrouted.dump. USR2 schreibt den Inhalt des internen Cache in /usr/tmp/mrouted.cache. HUP reinitialisiert und started den mrouted neu.

5 10.2 Der Multicast-Routingdämon, mrouted 83 INT bzw. TERM beendet den mrouted ordentlich, inklusive Abmeldung vom Netz bei den Nachbar-Routern. QUIT schreibt die internen Routing-Tabellen nach stderr. Dazu muss der mrouted jedoch mit einem Debug-Level ungleich 0 gestartet worden sein. Die Prozess-ID des mrouted ist in der Datei /etc/mrouted.pid zu finden. Die Verwendung der Signale und der Inhalt der Dateien mrouted.dump und mrouted.cache werden im Kapitel über die Fehlersuche beschrieben (siehe 11 Management von Multicast-Netzen, S. 111). Der mrouted lässt sich ferner mit dem Parameter»-d«in einem Debug-Modus starten, was zu zusätzlichen Kontroll- und Statusinformationen am Bildschirm führt. Mit der Debug-Option lässt sich auch genau die Fülle der Ausgaben definieren, indem eine durch Komma getrennte Liste der gewünschten Subsysteme mit übergeben wird. Beispiele hierfür sind: packet, pruning, routing, membership, neighbours oder igmp. Eine komplette Liste ist in [MROUT] im Anhang C.5 zu finden. mrouted Debug-Modus Aufbau der Datei mrouted.conf Die Konfigurationsdatei mrouted.conf ist eine einfache ASCII-Datei, die aus drei Abschnitten besteht: mrouted.conf Allgemeine Angaben zum Verhalten des mrouted Angaben zu den physikalische Interfaces Angaben zu den Multicast-Tunneln Allgemeine Angaben sind optional, ebenso die Angaben der physikalischen Interfaces. Für jeden Tunnel muss allerdings verständlicherweise ein Eintrag existieren. Die allgemeinen Konfigurationsdaten und die Angaben zu den physikalischen Schnittstellen müssen dabei vor allen Tunneleinträgen in der Datei erscheinen. Die Parameter für die physikalischen Schnittstellen werden mit dem Schlüsselwort phyint, die der Tunnel mit tunnel eingeleitet. Alle Parameter sind im Folgenden aufgeführt und kurz erklärt. Eine ausführlichere Darstellung aller Optionen ist in [MROUT] im Anhang C.5 zu finden.

6 84 10 Konfiguration von IP-Multicast-Netzen Allgemeine Konfigurationsparameter Angaben mit (*) werden erst ab Version 3.9 mrouted unterstützt Länge der Netzmaske ist 24 (die ersten 24 Bits spezifizieren das Netz) cache_lifetime <wert> prune_lifetime <wert> * noflood * rexmit_prunes [on off] * name <boundary-name> <scoped-addr/ masklen> Spezifiziert, wie lange Cache-Einträge gehalten werden, bevor sie neu überprüft werden. Angabe in Sekunden, Default ist 300. Spezifiziert die Lebensdauer der Prune-Zustände, Angabe in Sekunden, Default ist Verhindert das Flooding beim Startup des Routers. Kann dann relevant werden, wenn mehrere Router im gleichen Subnetz sind. Kann auch per Interface gesetzt werden. Wiederversenden von Prune-Nachrichten. Kann für alle Interfaces global ein- bzw. ausgeschaltet werden. Auch per Interface möglich. Adress-Boundaries lassen sich hiermit mit einem symbolischen Namen versehen; für die leichtere Handhabung. Syntax: Symbolischer Name, Adressbereich/Netzmaskenlänge Konfigurationsparameter für die physikalischen Interfaces Syntax: phyint <lokale-adr> para1 para2... disable netmask altnet <netmask/masklen> igmpv1 * force_leaf * Deaktivieren des Multicast, kann nützlich sein bei Punkt-zu-Punkt-Interfaces, die Multicast nicht ausreichend implementiert haben, z.b. ATM. Das Interface kann aber jederzeit als Tunnelendpunkt benutzt werden. Falls die Netzmaske nicht richtig verarbeitet wird, kann sie hier nochmals explizit an den mrouted übermittelt werden. Wenn ein physikalisches Interface an mehrere Subnetze angeschlossen ist (z.b. in einem virtuellen privaten Netz), kann hier jedes dieser Subnetze beschrieben werden. Befinden sich Router im gleichen lokalen Netz, die nur IGMP V1 implementiert haben, muss der mrouted ebenfalls auf Version 1 umgeschaltet werden. Veranlasst den mrouted, alle anderen Router in diesem lokalen Netz zu ignorieren.

7 10.2 Der Multicast-Routingdämon, mrouted 85 Anstelle der lokalen IP-Adresse, kann auch die Interfacebezeichnung für phyint benutzt werden (z.b. le0 des Ethernets bei Solaris). Zusätzlich zu den oben genannten Parametern können auch alle Tunnelparameter auf die physikalischen Schnittstellen angewandt werden. Konfigurationsparameter für Multicast-Tunnel Syntax: tunnel <lokale-adr> <entfernte-adr> para1... Tunnelkonfiguration metric <wert> advert_metric <wert> threshold <wert> rate_limit <wert> boundary <boundary-name> <scoped-addr/ masklen> passive * noflood * prune_lifetime <wert> * rexmit_prunes [on off] * allow_nonpruners * accept deny (<route/masklen> [exact]) [bidir] * Repräsentiert die Kosten für den Empfang von Multicast-Daten auf diesem Link. Standardwert: 1 Repräsentiert die Kosten für das Versenden von Multicast-Daten auf diesem Link. Standardwert: 0 Gibt die untere Grenze für den TTL-Wert eines Multicast-Pakets an. Die Daten werden nur über diesen Link gesendet, wenn der TTL-Wert den Threshold übersteigt. Standardwert: 1 Maximale Bandbreite, mit welcher über diesen Link gesendet werden darf. Standardwert: 0, keine Limitierung. Definiert Grenzen von Multicast-Adressbereichen, die nicht über diesen Link weiterversendet werden dürfen. Es werden keine Pakete über diesen Link versendet, solange der Gegenpunkt des Tunnels nicht aktiv ist und keine Probes schickt (nützlich bei Dial-up-Verbindungen). siehe oben, hier nur per Interface/Tunnel siehe oben siehe oben Normalerweise akzeptiert der mrouted keine Nachbarn als Router, die nicht prunen. Diese Option lässt sich hiermit ausschalten. Routen-Filter, akzeptiert bzw. verweigert Routen zu den spezifizierten Netzen, die von anderen Routern annonciert werden. Exact beschränkt den Filter genau auf das durch route/masklen gegebene Netz, ansonsten wird der gesamte Bereich gefiltert.

8 86 10 Konfiguration von IP-Multicast-Netzen notransit * Routen, die über ein Interface gelernt werden, das mit notransit markiert ist, werden nicht an ein anderes notransit-interface weitergegeben. Verhindert, dass der Router als Durchgangs-Router für bestimmte Netze fungiert. Zusatzwerkzeuge Die Distribution des mrouted enthält noch ein paar nützliche Werkzeuge zur Administration und Fehlersuche des Routers. Hierzu gehören mrinfo zur Konfigurationsabfrage und mtrace zur Routenverfolgung und -analyse. Beide Programme werden in Kapitel 11.1 im Detail erklärt. Cisco IOS Multicast aktivieren 10.3 Die Multicast-Erweiterungen des Cisco-Routers Das Betriebssystem von Cisco unterstützt IP-Multicast mit den Protokollen PIM Dense Mode (entspricht DVMRP) und PIM Sparse Mode seit der Version Die Version 10.2 ist jedoch sehr ungenügend implementiert und sollte besser nicht eingesetzt werden. Cisco selbst bezeichnet die Versionen ab 11.1(9) als stabil. Erfahrungen zeigen jedoch, dass im Allgemeinen die neuesten Versionen bevorzugt herangezogen werden sollten (11.2 und höher). Im Folgenden werden daher die Befehlssyntax und die wichtigsten Konfigurationsmöglichkeiten der Version 12 erläutert. Ein Cisco-Router stellt für die Administration von IP-Multicast verschiedene Befehlsgruppen zur Verfügung. Das sind Konfigurations-, Lese- und Debug-Befehle, die sich wiederum auf Untergruppen beziehen können. Bevor jedoch überhaupt ein Multicast-Paket durch einen Cisco-Router übertragen wird, muss mit dem globalen Kommando ip multicast-routing das Multicast-Routing zuerst aktiviert werden. Im Folgenden sollen die wichtigsten Befehle kurz erläutert werde, da diese für die späteren Beispielkonfigurationen von Bedeutung sind.

9 10.3 Die Multicast-Erweiterungen des Cisco-Routers 87 Auswahl der Konfigurationsparameter Cisco IOS ip igmp access-group ip igmp join-group ip igmp query-interval ip igmp version ip dvmrp accept-filter ip dvmrp summary-address ip dvmrp default-information ip dvmrp metric ip dvmrp metric-offset ip dvmrp reject-non-pruners ip dvmrp route-limit ip dvmrp unicast-routing Diese Befehlsgruppe konfiguriert das Verhalten von IGMP, wie die Abfragefrequenz des Routers, Zugriffsrechte und die Version. Weiterhin erlaubt der Router auch eine aktive Teilnahme in einer Multicast- Gruppe. Erlaubt die Filterung von Unicast- Routen. Bei einer großen Anzahl von Netzen innerhalb eines Administrationsbereiches des Routers können Routen zusammengefasst werden und dann nach außen annonciert werden (Reduktion der Routing- Tabellen im MBone). Erlaubt die Annoncierung einer Default-Route für Multicast-Adressen ( ). Spezifizierung einer bestimmten Metrik bezogen auf Netzadressen (in Verbindung mit Access Listen). Allgemeiner Wert, der alle Metriken entsprechend erhöht (kann in und out definiert werden). Verweigert die Weiterleitung von Multicast-Pakete an Router, die nicht prunen. Limitiert die maximale Größe der Multicast-Routingtabellen. Erzwingt die Erzeugung von separaten Unicast-Routingtabellen für das DVMRP-Routing auf dem MBone (s.u.).

10 88 10 Konfiguration von IP-Multicast-Netzen ip pim accept-rp ip pim message-interval ip pim query-interval ip pim rp-address ip pim rp-announce-filter ip pim send-rp-announce Die Konfiguration eines PIM- Sparse-Mode-Netzes lässt sich mittels des Cisco-Befehlsatzes sehr gezielt und individuell gestalten. Einige der nebenstehenden Befehle werden in einem konkreten Beispiel später in diesem Text genauer erläutert. ip pim send-rp-discovery ip pim spt-threshold show ip dvmrp route show ip igmp groups show ip igmp interface show ip mcache show ip mroute show ip pim interface show ip pim neighbor Das Cisco-Betriebssystem stellt mehrere Befehle zur Verfügung, mit denen sich sehr gut der aktuelle Zustand der Routingkonfiguration, der -tabellen sowie der Interfaces anzeigen lässt. Die Befehle beginnen alle mit show und sollten zum besseren Verständnis einfach einmal ausprobiert werden. show ip pim rp Für alle Beispiele werden private IP-Adressen benutzt, die im Internet nicht geroutet werden. Für weiterführende Informationen zu diesen und weiteren Multicastrelevanten Befehlen des Cisco-Betriebssystems sei auf [CISCO] im Anhang C.5 und [Cla97] im Anhang D.3 verwiesen. Nachdem auf den vorhergehenden Seiten die Grundlagen für die Konfiguration des mrouted Multicast-Routers und die eines Cisco- Routers erklärt wurden, wird nun der Aufbau von Multicast-Netzen anhand von Beispielkonfigurationen praktisch illustriert. Hierzu gehören einfache DVMRP-Netze, der Einsatz von privaten Multicast- Adressen, PIM-Konfigurationen und die Anbindung an den MBone DVMRP-Konfigurationen Die sicher einfachste Möglichkeit, ein Multicast-Netz zu realisieren, ist die auf Basis des DVMRP-Protokolls. Der MBone basierte lange ausschließlich nur auf diesem Protokoll. Die Realisierung in Form des frei verfügbaren mrouted ermöglicht es auch auf einfachem Weg, die ersten Experimente mit IP-Multicast durchzuführen, ohne einen echten Router einsetzen zu müssen.

11 10.4 DVMRP-Konfigurationen Verbindung dreier LANs mit mrouted In der ersten Netzkonfiguration sollen drei lokale Netze über ein Intranet oder über das Internet per Multicast verknüpft werden. Dies kann z.b. dadurch nötig werden, dass drei Entwicklungsgruppen einer Firma verteilt zusammenarbeiten müssen und dazu Videokonferenzwerkzeuge einsetzen wollen. An jedem der drei Standorte wird eine Workstation mit dem mrouted entsprechend Abb konfiguriert. mrouted A, Tunnel 1 mrouted B, LAN B ( ) Abb Multicast-Netz zwischen drei LANs Inter-/Intranet LAN A ( ) mrouted C, Tunnel 2 LAN C ( ) Die Eintragungen in der mrouted.conf gestalten sich wie folgt: Konfiguration mrouted A tunnel metric 1 threshold 16 rate_limit 1000 tunnel metric 1 threshold 16 rate_limit 1000 Konfiguration mrouted B tunnel metric 1 threshold 16 rate_limit 1000

12 90 10 Konfiguration von IP-Multicast-Netzen Konfiguration mrouted C tunnel metric 1 threshold 16 rate_limit 1000 Tunnelmetriken Im praktischen Einsatz bedeutet dies, dass Multicast-Daten von Sendern aus dem Netz über mrouted A ins Netz geleitet werden. Der Threshold wurde auf den Wert 16 gesetzt, was zur Folge hat, dass alle Sessions in den jeweiligen LANs, die mit einem TTL-Wert kleiner oder gleich 16 gesendet werden, das lokale Netz nicht verlassen. Damit ist gewährleistet, dass lokal begrenzte Sessions die Weitverkehrsverbindungen nicht belasten. Der Multicast-Verkehr ist begrenzt auf eine Bandbreite von maximal 1000 Kbit/s. Die Metriken für beide Verbindungen ist»1«, d.h., beide Verbindungen sind gleich»teuer«. Sie haben in dieser Konfiguration noch keinen Einfluss auf das Routingverhalten. Mit einem weiteren Tunnel zwische LAN B und LAN C kann ein Backup-Pfad zur Verbesserung der Ausfallsicherheit der Konfiguration eingerichtet werden oder eine Entlastung der existierenden Verbindungen erreicht werden. Je nachdem welche dieser beiden Möglichkeiten durch die Einrichtung des zusätzlichen Tunnels realisiert werden soll, müssen die jeweiligen Metriken in der Konfiguration gesetzt werden Zusätzlicher Tunnel als Backup Backup-Tunnel Um die Ausfallsicherheit der oben beschriebenen Konfiguration zu erhöhen, kann ein weiterer Tunnel zwischen LAN B und LAN C eingerichtet werden (Abb. 10 2). Dieser zusätzliche Tunnel übernimmt die Weiterleitung des Verkehrs, falls Tunnel 1 oder Tunnel 2 ausfallen. LAN B und LAN C können sich dann beim Ausfall von Tunnel 1 oder Tunnel 2 direkt über den Tunnel 3 erreichen. LAN A und LAN B bleiben bei Ausfall von Tunnel 1 über Tunnel 2 und Tunnel 3 verbunden. LAN A und LAN C können sich beim Ausfall von Tunnel 2 über Tunnel 1 und Tunnel 3 erreichen. In der normalen ungestörten Situation, wenn Tunnel 1 und Tunnel 2 korrekt arbeiten, wird kein Multicast- Verkehr über den Tunnel 3 geleitet.

13 10.4 DVMRP-Konfigurationen 91 mrouted A, Tunnel 1 Inter-/Intranet mrouted B, LAN B ( ) zusätzlicher Tunnel 3 Abb Multicast-Netz zwischen drei LANs mit drei Tunneln unter Berücksichtigung unterschiedlicher Metriken LAN A ( ) mrouted C, Tunnel 2 LAN C ( ) Um einen Backup-Tunnel einzurichten, müssen die folgenden Befehle zur Konfiguration des zusätzlichen Tunnels 3 verwendet werden. Zu beachten ist hierbei, dass die Metriken des neuen Tunnels korrekt gesetzt werden. mrouted B tunnel metric 3 threshold 16 rate_limit 1000 mrouted C tunnel metric 3 threshold 16 rate_limit 1000 Bei der Ermittlung der Routen berechnen die mrouted die Gesamtmetrik entlang der verschiedenen Routen und bestimmen daraus den optimalen Weg. Als Beispiel diene der mrouted C aus obiger Konfiguration. Dieser hat zwei Möglichkeiten, Multicast-Daten an mrouted B zu schicken, einmal direkt über den Tunnel 3 und zum anderen über Tunnel 1 und Tunnel 2. Der letztere Weg hat eine Gesamtmetrik von 2 (1 + 1), der erstere eine Metrik von 3. Der Multicast- Verkehr nimmt daher den Weg über Tunnel 1 und 2, da dieser»kostengünstiger«ist, d.h. eine niedrigere Metrik besitzt. Fällt einer der Tunnel jedoch aus (z.b. aufgrund von Leitungsproblemen), wird der Verkehr automatisch über Tunnel 3 geleitet, da er (trotz der hohen Metrik) die einzige Multicast-Verbindung zwischen LAN B und LAN C darstellt.

14 92 10 Konfiguration von IP-Multicast-Netzen Zusätzlicher Tunnel als Entlastung der vorhandenen Verbindungen Leitungsentlastung Reichweitenbegrenzung Bilden sich verstärkt Arbeitsgruppen zwischen LAN B und LAN C, die ohne Involvierung von Teilnehmern aus LAN A konferieren, bietet es sich an, den Multicast-Verkehr direkt an die entsprechenden Multicast-Router B und C zu leiten, um den mrouted A zu entlasten. Daher wird ebenfalls, wie schon in Abb gezeigt, ein zusätzlicher Tunnel etabliert, der beide LANs über Multicast verbindet. Im Unterschied zur oben beschriebenen Konfiguration als Backup-Tunnel wird hier jedoch auf dem neuen Tunnel 3 eine Metrik von 1 konfiguriert. Damit existieren dann von LAN C (mrouted C) aus zwei Wege zu LAN B (mrouted B). Der eine führt über mrouted A mit einer Metrik von 2 (1+1). Der andere führt über den neuen Tunnel 3 direkt von LAN C zu LAN B mit einer Metrik von 1. Pakete von LAN C nach LAN B werden also in diesem Fall direkt über Tunnel 3 gesendet, da dieser mit Metrik 1 kostengünstiger als die Alternative mit Metrik 2 über Tunnel 1 und 2 ist. Dieses erste Beispiel zeigt deutlich, wie mit Hilfe von Metriken die Weiterleitung von Multicast-Daten entsprechend den lokalen Voraussetzungen gezielt beeinflusst werden kann. Es lassen sich Backup-Verbindungen erzeugen, um eine höhere Ausfallsicherheit zu erhalten, oder auch zusätzliche Verbindungen aktivieren, um eine bessere Performanz zu erzielen. Während die Metrik bestimmt, welchen Weg ein Multicast-Paket einschlägt, legt der Threshold fest, wie weit (d.h. über wie viele Router-Übergänge) das Paket auf diesem Weg weitervermittelt wird. Diese Reichweitenbegrenzung ist dann von Nutzen, wenn verhindert werden soll, dass Multicast-Verkehr von lokalen Sessions unnötig über die WAN-Leitungen verschickt wird. Das entsprechende initiale Setzen des TTL-Werts beim Versenden von Multicast- Daten wird auf der Ebene der Anwendung beeinflusst und in späteren Kapiteln näher beschrieben Verbindung der drei LANs mit Cisco-Routern Um die Multicast-Konfiguration von Cisco-Routern zu erläutern, werden in diesem Beispiel die drei bereits im vorherigen Abschnitt beschriebenen LANs über zwei Cisco-Router und einen mrouted verbunden. Daraus ergibt sich die Konfiguration entsprechend Abb Hier treten zwei Fälle auf, die unterschieden werden müssen: ein Multicast-Tunnel zwischen zwei Cisco-Routern und ein Tunnel zwischen einem Cisco- und einem mrouted-router. Um die Unterschiede zu illustrieren, reicht die Angabe der Konfiguration von Router Cisco

15 10.4 DVMRP-Konfigurationen 93 A aus. Cisco B wird entsprechend der Tunneleinstellung in Router A konfiguriert. Beim mrouted muss nicht unterschieden werden, welcher Routertyp (Cisco oder mrouted) am anderen Ende des Tunnels installiert ist. Die Konfiguration des mrouted ändert sich also im Vergleich zum vorherigen Beispiel nicht. Cisco A, Tunnel 1 Cisco B, LAN B Abb Multicast-Netz zwischen drei LANs mit zwei Cisco- Routern und einem mrouted Inter-/Intranet LAN A mrouted C, Tunnel 2 LAN C Konfiguration auf Router Cisco A für einen Tunnel zu Router Cisco B: ip multicast-routing... interface tunnel1 ip unnumbered Ethernet1 ip pim dense-mode ip multicast ttl-threshold 16 ip multicast rate-limit out 1000 ip multicast rate-limit in 1000 ip dvmrp metric-offset in 1 ip dvmrp unicast-routing tunnel source tunnel destination Tunnel zwischen Cisco- Routern

16 94 10 Konfiguration von IP-Multicast-Netzen Konfiguration auf Router Cisco A für einen Tunnel zum mrouted C: Tunnel zwischen Cisco- Router und mrouted interface tunnel2 ip unnumbered Ethernet1 ip pim dense-mode ip multicast ttl-threshold 16 ip multicast rate-limit out 1000 ip multicast rate-limit in 1000 ip dvmrp metric-offset in 1 tunnel source tunnel destination tunnel mode dvmrp Aktivieren des Multicast- Routings Bevor das Multicast-Routing auf einem Cisco-Router funktionieren kann, muss es zuerst über das globale Kommando ip multicast-routing aktiviert werden. Erst dann kann über die Interface-spezifischen Befehle das Multicast-Routing pro Interface konfiguriert werden. Ein Tunnel wird hierbei wie ein physikalisches Interface behandelt und benötigt entweder eine eigene IP-Adresse oder wird einem Netzinterface zugeordnet. Im obigen Fall wurden die Tunnel dem Interface Ethernet1 zugewiesen, welches als Zugang zum Internet fungiert. Die eigentliche Multicast-Konfiguration beginnt mit der Auswahl des Routingverfahrens. Hier besteht die Wahl zwischen PIM Dense und Sparse Mode (siehe 6 Protocol Independent Multicast (PIM), S. 39). Bei der obigen Konfiguration wird als Routingprotokoll DVMRP eingesetzt, welches im Cisco-Router durch den PIM-Dense- Modus realisiert wird. Dieses Protokoll wird über den Befehl ip pim dense-mode Cisco DVMRP Cisco GRE-Tunnel konfiguriert. Die folgenden Eintragungen sind äquivalent zu der Konfiguration im mrouted (Threshold, Rate Limit, Metrik, Tunnel Source und Destination). Die Datenrate muss allerdings in Hin- und Rückrichtung getrennt spezifiziert werden. Neu sind zwei Befehle, die in jeweils einer der Tunnelkonfigurationen vorkommen: ip dvmrp unicast-routing und tunnel mode dvmrp. Der Letztere ist notwendig für die Etablierung eines DVMRP-Tunnels zu einem Router anderer Art als Cisco (im obigen Beispiel ist das der mrouted-dämon). Für Tunnel untereinander verwendet Cisco dagegen ein eigenes Tunnelformat (so genannte GRE-Tunnel). Wie bereits erwähnt realisiert ein Cisco-Router das DVMRP-Verhalten über das