Multicast, Streaming
Transcription
Multicast, Streaming
Hochschule Luzern – Technik & Architektur Multicast/Streaming Advanced ICT Betrieb und Nutzung Horw, den 2. Juni 2008 Teammitglieder Philippe Manner Tel. +41 76 390 88 16 [email protected] Andy Abgottspon Tel. +41 79 703 75 15 [email protected] Verantwortliche & Dozierende Werner Odermatt Modulverantwortlicher Beat Hämmerli Modulverantwortlicher Nicola Lardieri Assistent Multicast/Streaming Inhalt Abbildungsverzeichnis 4 1 Einführung 5 2 Theoretische Abhandlung 6 2.1 2.2 2.3 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1 Protocol Independent Multicast (PIM) . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 Internet Group Management Protocol (IGMP) . . . . . . . . . . . . . . . . . 8 Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 Das Problem beim Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2 User Datagram Protocol (UDP) . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3 Real-Time Transport Protocol (RTP) . . . . . . . . . . . . . . . . . . . . . . 13 Ergänzende Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 Dynamic Host Configuration Protocol (DHCP) . . . . . . . . . . . . . . . . . 13 2.3.2 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.3 Service Advertising Protocol (SAP) . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.4 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . 18 3 Vorgegebener Laborversuch 20 3.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.2 DHCP-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.3 Multicast/IGMP Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4 Verbinden der Inseln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.5 Kontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4 Vertiefung 4.1 25 Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1 Serielle Verbindung vs. (Fast)Ethernet . . . . . . . . . . . . . . . . . . . . . . 25 4.1.2 Konfiguration der DHCP-Pools . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2 VLC media player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3 Multicast-Streaming mit SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4 4.3.1 Router-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.2 Den Stream einrichten ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.3 Auswahl der Streaming-Methode . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.4 Transcoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3.5 Weitere Streaming-Optionen 4.3.6 Den Stream empfangen ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.7 Kontrolle auf dem Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Video-Streaming über HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 2/50 INHALT Multicast/Streaming 4.4.1 Konfiguration der Streaming-Station A . . . . . . . . . . . . . . . . . . . . . . 35 4.4.2 Konfiguration Router Horw . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.4.3 Empfang auf den Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Anhang 41 A Impressionen 41 B Konfigurationen 43 B.1 Router ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 B.2 Router Zürich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 B.3 Router London . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 B.4 Router Luzern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.5 Switch England . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 B.6 Switch Schweiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 3/50 Multicast/Streaming Abbildungsverzeichnis 1 Streaming im Alltag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 Typischer Aufbau einer Multicastverbindung 6 3 UDP-Datagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4 DHCP Session Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 Vorgegebener Versuchsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6 Serielle Verbindungen (blaue Kabel) – zu langsam für Streaming . . . . . . . . . . . 25 7 Vereinfachter Versuchsaufbau mit Ethernet-Verbindungen . . . . . . . . . . . . . . . 26 8 VLC Hauptfenster unter Mac OS X . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9 Übersicht diverser Streaming-Lösungen mit VLC . . . . . . . . . . . . . . . . . . . . 28 10 Versuchsaufbau Videostreaming über SAP . . . . . . . . . . . . . . . . . . . . . . . . 29 11 Erstellen eines neuen Streams in VLC . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12 Auswahl der Streaming-Methode in VLC . . . . . . . . . . . . . . . . . . . . . . . . . 31 13 Abfrage der über SAP verfügbaren Streams in VLC . . . . . . . . . . . . . . . . . . . 34 14 Versuchsaufbau Streaming über HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . 35 15 Port-Forwarding (NAT) auf einem Zyxel P-320W . . . . . . . . . . . . . . . . . . . . 37 Hochschule Luzern – T&A . . . . . . . . . . . . . . . . . . . . . . ICT Betrieb und Nutzung Seite 4/50 Multicast/Streaming 1 Einführung Streaming erfreut sich immer grösserer Beliebtheit. Jedermann hat schon davon gehört und hat es, wenn auch nicht ganz bewusst, schon oft benutzt. Mehr und mehr Webseiten binden StreamingObjekte ein, immer mehr Live-Schaltungen existieren im Internet und immer mehr Menschen nutzen die Möglichkeit des Fernsehens oder Radiohörens übers Internet. Man denke zum Beispiel auch an YouTube oder Skype, welche von Millionen von Leuten täglich genutzt werden. All diese Gebiete basieren auf dem Prinzip des Streamings. Doch wie funktioniert es eigentlich? Was steckt softwareund hardwaremässig dahinter? Abbildung 1: Streaming im Alltag Heutzutage wird alles pfannenfertig zur Verfügung gestellt und niemand interessiert sich, wieso es eigentlich funktioniert. Der Benutzer muss meist nur noch auf einen Link klicken oder ein kleines Programm herunterladen und der Datenstrom steht bereits. Doch so einfach wie das auf den ersten Blick aussieht, ist es allerdings doch nicht. Es steckt ein enormes Know-how und etliche Arbeitsstunden dahinter, bis endlich alles zufriedenstellend läuft. Diese Arbeit soll dabei helfen, ein vertieftes Hintergrundwissen über Streaming und Multicast zu erlangen. Dies geht über das korrekte Vernetzen der Infrastruktur bis zur Einrichtung von so genannten Tunnels. Zusätzlich wird am Schluss noch das Tool VLC genauer vorgestellt, wenn es um Streaming über HTTP und das Session Announcement Protocol (SAP) geht. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 5/50 Multicast/Streaming 2 2.1 Theoretische Abhandlung Multicast Multicast oder Gruppenruf bezeichnet in der Telekommunikation eine Nachrichtenübertragung von einem Punkt zu einer Gruppe (auch Mehrpunktverbindung genannt). Der Vorteil von Multicast besteht darin, dass gleichzeitig Nachrichten an mehrere Teilnehmer oder an eine geschlossene Teilnehmergruppe übertragen werden können, ohne dass sich beim Sender die Bandbreite mit der Zahl der Empfänger multipliziert. Der Sender braucht beim Multicasting nur die gleiche Bandbreite wie ein einzelner Empfänger. Handelt es sich um paketorientierte Datenübertragung, findet die Vervielfältigung der Pakete an jedem Verteiler (Switch, Router) auf der Route statt. Abbildung 2: Typischer Aufbau einer Multicastverbindung Neben Multicast-Verbindungen gibt es die Punkt-zu-Punkt-Verbindung, auch Unicast genannt, die Broadcast- und die Anycast-Übertragung. Eine spezielle Ausprägung von Multicast ist Geocast, bei dem in einen räumlich abgegrenzten Bereich gesendet wird. Multicast ist die übliche Bezeichnung für IP-Multicast, das es ermöglicht, in IP-Netzwerken effizient Daten an viele Empfänger zur gleichen Zeit zu senden. Das passiert mit einer speziellen Multicast-Adresse. In IPv4 ist hierfür der Adress-Bereich 224.0.0.0 bis 239.255.255.255 (Klasse D), in IPv6 jede mit FF00::/8 beginnende Adresse reserviert. Zusätzlich wird zur Koordination bei IPv4 das Protokoll IGMP oder CGMP (nur CiscoKomponenten) benutzt. In IPv6 übernimmt ICMPv6 die Steuerungsfunktion. Da Multicast-Pakete von den meisten Routern im Internet nicht verarbeitet werden, wurden multicastfähige Teilnetze über Tunnel zum Multicast Backbone (MBone) verbunden. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 6/50 2.1 Multicast Multicast/Streaming Um Multicast-Pakete zwischen mehreren Netzen zu koordinieren, werden spezielle MulticastRouting-Protokolle verwendet. Traditionell sind dies die Verfahren DVMRP, ein Distanzvektorverfahren ähnlich RIP, und MOSPF, ein Link-State-Verfahren ähnlich OSPF. Beide Verfahren sind auf Netze mit homogener Leitungskapazität und Regionen mit starker Multicast-Nutzung ausgelegt. Da beide Voraussetzungen nur selten erfüllt sind, hat ein drittes Verfahren mit der Bezeichnung PIM an Bedeutung gewonnen. Es existieren allerdings bei Verwendung bestimmter Adressbereiche einiger Switches Probleme bei der Weiterleitung von Multicastnachrichten. Die Adressen von 224.0.0.0 bis 224.255.255.255 sind für Routingprotokolle reserviert und für diese Adressen sendet der Router keine IP-Multicast-Datagramme. Die Adressen von 239.0.0.0 bis 239.255.255.255 sind für scoping reserviert, eine Weiterleitung innerhalb dieses Adressbereichs ist ebenfalls Switch abhängig. Adressen im Bereich 225.x.x.x bis 238.x.x.x sind frei verfügbar. (Wikipedia: Multicast) 2.1.1 Protocol Independent Multicast (PIM) Protocol Independent Multicast (PIM) ist ein Verfahren in der Netzwerktechnik, das dynamisches Routing von Multicast-Paketen im Internet ermöglicht. Anders als traditionelle Verfahren wie DVMRP oder MOSPF ist PIM auch bei stark verstreuten Teilnehmern bzw. Multicast-Gruppen und bei extrem heterogener Netz-Infrastruktur noch leistungsfähig. Aus diesem Grund ist PIM vermutlich das einzige noch verwendete Multicast-Routingverfahren. PIM unterscheidet zwischen zwei Funktionsmodi: Dense-Mode Im so genannten Dense-Mode erzeugt die Initiierung eines Multicasts einen Broadcast an sämtliche bekannten Multicast-Gruppen. Daraufhin melden sich die Router vom Multicast ab, in deren Teilnetzen es keine Interessenten gibt. Der Dense-Mode ist daher für Netze mit hoher Teilnehmerdichte gedacht. Sparse-Mode Für Netze mit sehr niedriger Teilnehmerdichte oder grosser Streuung der Teilnehmer über verschiedene Teilnetze wird der Sparse-Mode eingesetzt. Dies beinhaltet die Vereinbarung eines Rendezvous-Punkt-Routers, der Multicast-Veröffentlichungen entgegennimmt. Andere Router können bei diesem Rendezvous-Punkt anfragen, ob Multicasts für entsprechende Interessengruppen eingegangen sind. Ist dies der Fall, vermittelt der Rendezvous-Punkt zwischen dem Absender des Multicasts und dem Router, in dessen Teilnetz sich ein interessierter Teilnehmer befindet, eine Verbindung. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 7/50 2.1 Multicast Multicast/Streaming (Wikipedia: PIM) 2.1.2 Internet Group Management Protocol (IGMP) Das Internet Group Management Protocol (IGMP) ist ein Netzwerkprotokoll der Internetprotokollfamilie und dient zur Organisation von Multicast-Gruppen. IGMP benutzt wie ICMP das Internet Protocol (IP) und ist integraler Bestandteil von IP auf allen Hosts, die den Empfang von IP-Multicasts unterstützen. Verwendung Das Internet Group Management Protocol basiert auf dem Internet Protocol (IP) und ermöglicht IP-Multicasting (Gruppenkommunikation) im Internet. IP-Multicasting ist die Verteilung von IP-Paketen unter einer IP-Adresse an mehrere Stationen gleichzeitig. IGMP bietet die Möglichkeit, dynamisch Gruppen zu verwalten. Die Verwaltung findet nicht in der Sende-Station statt, sondern in den Routern, an denen Empfänger einer Multicast-Gruppe direkt angeschlossen sind. IGMP bietet Funktionen, mit denen eine Station einem Router mitteilt, dass sie Multicast-IP-Pakete einer bestimmten Multicast-Gruppe empfangen will. Multicast-Routing-Protokolle (DVMRP, MOSPF, PIM) übernehmen die Koordination der Übertragung zwischen den Routern. Der Sender von Multicast-IP-Paketen weiss dabei nicht, welche und wie viele Stationen seine Pakete empfangen. Denn er verschickt nur ein einziges Datenpaket an seinen übergeordneten Router. Der dupliziert das IP-Paket bei Bedarf, wenn er mehrere ausgehende Schnittstellen mit Empfängern hat. Es gibt 3 Versionen von IGMP, mit folgenden prinzipiellen Eigenschaften IGMPv1 Der Host kann zu einer MC Gruppe beitreten, ein Abmelden ist hier nicht implementiert. Nach einem Time Out ist der Host wieder ausgetragen. IGMPv2 Der Host kann sich jetzt von der MC Gruppe abmelden (Leave Message implementiert). Damit können auch Multicasts mit grosser Bandbreite behandelt werden. IGMPv3 Hier kann nun vorgegeben werden von welcher Quelle der Multicast-Stream gewünscht wird. Dies ist ein wesentlicher Sicherheitsaspekt, wenn auch nicht der Optimale. (Wikipedia: Internet Group Management Protocol) Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 8/50 2.2 Streaming Multicast/Streaming IGMP Snooping IGMP Snooping ist die Art und Weise, wie der IGMP Verkehr beachtet wird. IGMP Snooping, wie der Name es bereits verrät, ist eine Möglichkeit für den Switch, die IGMP Konversation in einem Multicast-Netzwerk zwischen Host und Routers abzuhören, indem es die Layer 3 IGMP Pakete analysiert. Wenn IGMP Snooping bei einem Switch aktiv ist, analysiert dieser alle IGMP Pakete zwischen den am Switch angeschlossenen Hosts und den Multicast-Routern im Netzwerk. Wenn der Switch eine Anfrage eines Hosts nach einer Multicast-Gruppe registriert, fügt dieser die Portnummer des Hosts in die Multicast-Liste dieser Gruppe. Und wenn der Switch eine IGMP Anfrage zum Verlassen einer Gruppe bemerkt, löscht er die Portnummer des Hosts wieder aus der Liste. IGMP Snooping kann den Multicast-Verkehr von Streaming und anderen bandbreitenintensiven IP Applikationen sehr effizient reduzieren. Während ein Switch, welcher kein Multicast versteht, den ganzen Multicast-Verkehr via Broadcast an alle Ports in einer Broadcast-Domain (LAN) weiterleitet, sendet ein Switch, welcher IGMP Snooping verwendet, die Multicast-Pakete nur an diejenigen Hosts weiter, die auch wirklich daran interessiert sind. Diese Reduktion des Multicast-Verkehrs reduziert die Paketverwaltung auf dem Switch (mit den zusätzlichen Kosten für zusätzlichen Speicher um die MulticastTabellen verwalten zu können) und auch die Arbeitsbelastung eines jeden Hosts, da dessen Netzwerkkarte (oder Betriebssystem) den generierten Multicast-Verkehr im Netzwerk nicht mehr empfangen und filtern muss. (Wikipedia: IGMP Snooping) 2.2 Streaming Der Begriff Streaming bezeichnet eine Internet-Technologie, bei der Film- oder Audiodateien in Echtzeit im Inter- oder Intranet abgespielt werden. Es wird im Gegensatz zum herkömmlichen Download ein Streamingserver benötigt, der auf Anfrage Datenpakete versendet. Neu an der Streaming-Technik ist, dass lange Wartezeiten entfallen. Die Film- oder Audiodateien müssen nicht mehr als ganzes heruntergeladen werden, sondern können direkt beim Download abgespielt werden. Um Streaming-Media-Angebote nutzen zu können, ist auf der Empfängerseite eine spezielle Software erforderlich. Dies kann ein Plug-in sein, das in einen Web-Browser integriert ist, aber auch ein eigenständiges Wiedergabeprogramm. Ersteres wird automatisch aufgerufen, sobald eine angeforderte Seite Streaming-Media-Daten enthält. Diese Plug-ins und Wiedergabeprogramme (engl. Player) werden in der Regel kostenlos angeboten, im Gegensatz zu den Servern, die dazugehören und die Daten senden. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 9/50 2.2 Streaming Multicast/Streaming On-demand-Streaming • Daten werden vom Server über das Netz an den Client übertragen • die Wiedergabe erfolgt bereits während der Übertragung • Zwischenpufferung für lückenlose Wiedergabe • Vor- Zurückspulen und Pausieren möglich • Protokolle: HTTP, FTP Live-Streaming • Bereitstellung des Angebotes in Echtzeit • Protokolle: RTP, RTCP, RTSP 2.2.1 Das Problem beim Streaming Während klassische Broadcasting-Angebote (Rundfunk, Radio usw.) aus ökonomischer Sicht eine möglichst grosse Reichweite anstreben, werden Streaming-Media-Angebote mit wachsender Teilnehmerzahl teurer, denn die Daten müssen an jeden Empfänger einzeln versandt werden. In der Netzwerktechnik ist zwar der Multicast-Modus bekannt, bei dem ein vom Streaming-Server ausgehender Datenstrom bei geringer Netzbelastung gleichzeitig an verschiedene Empfänger gesendet werden kann; dieser wird jedoch bis heute praktisch nicht benutzt, weil ihn viele Router im Internet nicht unterstützen. Stattdessen werden für Streaming-Angebote mit einem Massenpublikum (etwa Übertragungen der Fussballbundesliga oder Popkonzerte), so genannte Overlay-Netze (Netzwerke, die auf ein bestehendes Netzwerk aufsetzt) genutzt, welche die zu übertragenden Daten netztopologisch betrachtet an vielen Orten gleichzeitig zur Verfügung stellen. Da Streaming Media besondere Stärken in der Echtzeitübertragungen besitzt, und diese Übertragung nicht in jedem Fall parallel für die dauerhafte Speicherung konzipiert wird, kann die Qualität oftmals eher niedrig ausfallen, um bei den heute üblichen Datenübertragungsraten eine flüssige Übertragung zu gewährleisten. Aus dieser Perspektive erscheint die Verwendung der Streaming-Technologie bei Inhalten, bei denen es nicht auf eine Echtzeitübertragung ankommt (etwa bei Film-Trailern) eher fraglich. Viele grosse Anbieter setzen die Übertragung per Streaming aber dennoch ein, um von den weiteren Vorteilen der Technologie gebrauch machen zu können. Bspw. erlauben aktuelle Internetvideotechnologien das freie Spulen innerhalb von Videos (ohne Vorladezeiten) nur über Streaming Server. Diverse Inhalte-Anbieter setzen die Streaming-Technik auch mit dem Ziel ein, es den Endbenutzern zu erschweren, die empfangenen Daten dauerhaft zu speichern. Dies ist Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 10/50 2.2 Streaming Multicast/Streaming nämlich nur mit spezieller Software möglich und kann durch weitere Massnahmen erschwert werden. Dadurch muss der Stream ständig neu geladen werden, was wiederum unnötigen Datentransfer auf Seiten des Servers und auch des Benutzers verursacht. (Wikipedia: Streaming Media, Uni Bern: Streaming) 2.2.2 User Datagram Protocol (UDP) Das User Datagram Protocol (UDP) ist ein minimales, verbindungsloses Netzprotokoll, das zur Transportschicht der Internetprotokollfamilie gehört. Aufgabe von UDP ist es, Daten, die über das Internet übertragen werden, der richtigen Anwendung zukommen zu lassen. Die Entwicklung von UDP begann 1977, als man für die Übertragung von Sprache ein einfacheres Protokoll benötigte als das bisherige verbindungsorientierte TCP. Es wurde ein Protokoll benötigt, das nur für die Adressierung zuständig war, ohne die Datenübertragung zu sichern, da dies zu Verzögerungen bei der Sprachübertragung führen würde. Funktionsweise Um die Daten, die mit UDP versendet werden, dem richtigen Programm auf dem Zielrechner zukommen zu lassen, werden bei UDP so genannte Ports verwendet. Dazu wird bei UDP die Portnummer des Dienstes mitgesendet, der die Daten erhalten soll. Diese Erweiterung der Host-zu-Host- auf eine Prozess-zu-Prozess-Übertragung wird als Anwendungsmultiplexen und -demultiplexen bezeichnet. Zusätzlich bietet UDP die Möglichkeit einer Integritätsüberprüfung an, indem eine Prüfsumme mitgesendet wird. Dadurch kann eine fehlerhafte Übertragung erkannt werden. Eigenschaften UDP stellt einen verbindungslosen, nicht-zuverlässigen Übertragungsdienst bereit. Das bedeutet, dass es keine Garantie gibt, dass ein einmal gesendetes Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden oder dass ein Paket nur ein Mal am Empfänger eintrifft. Eine Anwendung, die UDP nutzt, muss daher gegenüber verloren gegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmassnahmen beinhalten. Da vor Übertragungsbeginn nicht erst eine Verbindung aufgebaut werden muss, können die Hosts schneller mit dem Datenaustausch beginnen. Dies fällt vor allem bei Anwendungen ins Gewicht, bei denen nur kleine Datenmengen ausgetauscht werden müssen. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 11/50 2.2 Streaming Multicast/Streaming Einfache Frage-Antwort-Protokolle wie das Domain Name System verwenden UDP um die Netzwerkbelastung gering zu halten und damit den Datendurchsatz zu erhöhen. Ein Drei-Wege-Handshake wie bei TCP für den Aufbau der Verbindung würde unnötigen Overhead erzeugen. Daneben bietet die ungesicherte Übertragung auch den Vorteil von geringen Übertragungsverzögerungsschwankungen: Geht bei einer TCP-Verbindung ein Paket verloren, so wird es automatisch erneut angefordert. Dies braucht Zeit, die Übertragungsdauer kann daher schwanken, was für Multimediaanwendungen schlecht ist. Bei VoIP z.B. würde es zu plötzlichen Aussetzern kommen bzw. die Wiedergabepuffer müssten grösser angelegt werden. Bei verbindungslosen Kommunikationsdiensten bringen verlorengegangene Pakete dagegen nicht die gesamte Übertragung ins Stocken sondern vermindern lediglich die Qualität. UDP übernimmt die Eigenschaften der darunterliegenden Netzwerkschicht. Im Falle des Internet Protocols IP können Datenpakete maximal 65535 Bytes lang sein, wovon der IP-Header und UDP-Header insgesamt mindestens 28 Bytes belegen. UDP-Datagramme haben daher maximal 65507 Nutzdatenbytes. Solche Pakete werden jedoch von IP fragmentiert übertragen. IP löscht Pakete etwa bei Übertragungsfehlern oder bei Überlast. Datagramme können daher fehlen. Das UDP-Protokoll bietet hierfür keine Erkennungs- oder Korrekturmechanismen wie etwa TCP. Im Falle von mehreren möglichen Routen zum Ziel kann IP bei Bedarf neue Wege wählen. Hierdurch ist es in seltenen Fällen möglich, dass später gesendete Daten früher gesendete überholen. Ausserdem ist es möglich, dass ein einmal abgesendetes Datenpaket mehrmals beim Empfänger eintrifft. (Wikipedia: User Datagram Protocol) Abbildung 3: UDP-Datagramm UDP-Datagramm Der UDP-Header besteht aus vier Datenfeldern, die alle jeweils 16 Bit gross sind: Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 12/50 2.3 Ergänzende Technologien Multicast/Streaming Quell-Port Gibt die Portnummer des sendenden Prozesses an. Diese Information wird benötigt, damit der Empfänger auf das Paket antworten kann. Da UDP verbindungslos ist, ist der Quell-Port optional und kann auf den Wert "0"gesetzt werden. Ziel-Port Gibt an, welcher Prozess das Paket empfangen soll. Länge Gibt die Grösse des Paketes, bestehend aus den Daten und dem Header, in Oktetten an. Der kleinstmögliche Wert sind 8 Oktette. Prüfsumme Es kann eine 16 Bit grosse Prüfsumme mitgesendet werden. Die Prüfsumme wird über den Header, den so genannten Pseudo-Header und die Daten gebildet. Die Prüfsumme ist optional, wird aber in der Praxis fast immer benutzt (falls nicht, wird diese auf "0"gesetzt). 2.2.3 Real-Time Transport Protocol (RTP) Das Real-Time Transport Protocol (RTP) ist ein Protokoll zur kontinuierlichen Übertragung von audiovisuellen Daten (Streams) über IP-basierte Netzwerke. Es dient dazu, Multimedia-Datenströme (Audio, Video, Text, etc.) über Netzwerke zu transportieren, d.h. die Daten zu kodieren, zu paketieren und zu versenden. RTP ist ein Paket-basiertes Protokoll und wird normalerweise über UDP betrieben. RTP kann sowohl für UnicastVerbindungen als auch für Multicast-Kommunikation im Internet eingesetzt werden. Das RealTime Control Protocol arbeitet mit RTP zusammen und dient der Aushandlung und Einhaltung von Quality-of-Service-Parametern (QoS). Es findet Anwendung in vielen Bereichen, u.a. wird es bei den IP-Telefonie-Technologien H.323 und SIP dazu verwendet, die Audio-/Videoströme des Gespräches zu übertragen. Die Funktion von RTP besteht hauptsächlich in der Übertragung echtzeitsensitiver Datenströme, während das Real-Time Streaming Protocol (RTSP) der Steuerung und Kontrolle der Datenübertragung dient. (Wikipedia: Real-Time Transport Protocol) 2.3 2.3.1 Ergänzende Technologien Dynamic Host Configuration Protocol (DHCP) Das Dynamic Host Configuration Protocol (DHCP) ermöglicht die Zuweisung der Netzwerkkonfiguration an Geräte durch einen Server. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 13/50 2.3 Ergänzende Technologien Multicast/Streaming Konzept Durch DHCP ist die automatische Einbindung eines neuen Computers in ein bestehendes Netzwerk ohne dessen manuelle Konfiguration möglich. Am Client muss im Normalfall lediglich der automatische Bezug der IP-Adresse eingestellt sein. Beim Start des Rechners am Netz kann er die IP-Adresse, die Netzmaske, das Gateway, DNS-Server und gegebenenfalls WINS-Server von einem DHCP-Server beziehen. Ohne DHCP sind dazu – abhängig vom Netzwerk, an das der Rechner angeschlossen werden soll – relativ aufwändige Einstellungen nötig. DHCP ist eine Erweiterung des Bootstrap Protocol (BOOTP), mit dem sich laufwerklose Workstations realisieren lassen, die sich zunächst eine IP-Adresse vom BOOTP-Server holen. Anschliessend laden sie ein startbares Betriebssystem aus dem Netz, mit dem sie dann starten. DHCP ist weitgehend kompatibel zu BOOTP und kann mit BOOTPClients und -Servern eingeschränkt zusammenarbeiten. Das Dynamic Host Configuration Protocol wurde im Hinblick auf zwei Einsatzszenarien entwickelt: 1. Für grosse Netzwerke mit häufig wechselnder Topologie 2. Für Anwender, die „einfach nur eine Netzwerkverbindung“ haben und sich nicht näher mit der Netzwerkkonfiguration beschäftigen möchten In Netzwerken bietet DHCP den Vorteil, dass bei Topologieänderungen nicht mehr alle betroffenen Workstations von Hand umkonfiguriert werden müssen, sondern die entsprechenden Vorgaben vom Administrator nur einmal in der Konfigurationsdatei des DHCP-Servers geändert werden. Auch für Rechner mit häufig wechselndem Standort (z. B. Notebooks) entfällt die fehleranfällige Konfiguration – der Rechner wird einfach ans Netzwerk gesteckt und erfragt alle relevanten Parameter vom DHCP-Server. Dies wird manchmal auch als Plug ’n Play für Netzwerke bezeichnet. (Wikipedia: DHCP) Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 14/50 2.3 Ergänzende Technologien Multicast/Streaming Abbildung 4: DHCP Session Schema Funktionsweise Der typische DHCP-Vorgang sieht so aus: • Der Klient schickt per Broadcast eine DHCPDISCOVER-Abfrage (‘hallo, hört mich jemand? Ich brauche eine IP-Adresse!’). • Alle mithörenden DHCP-Server schicken ein Angebot (DHCPOFFER) an den Klienten (‘hier ist eine IP-Adresse, möchtest du sie haben?’). • Der Klient wählt ein Angebot aus, und schickt eine DHCPREQUEST (‘ja bitte, ich nehme die IP-Adresse’) zurück an den anbietenden DHCP-Server. • Der angesprochene DHCP-Server schickt schliesslich ein DHCPACK an den Klienten zurück (‘OK, hier ist deine IP-Adresse, du darfst sie X Sekunden lang benützen’). 2.3.2 Tunnel Tunnel bzw. Tunneling bezeichnet den Gebrauch eines Netzwerkprotokolls als Transportmittel für artfremde Daten, ohne dabei den Standard des Protokolls zu verletzen. Entweder werden in einem Tunnel die Daten eines Dienstes im Protokoll eines anderen Dienstes eingebettet (z. B. HTTP-Tunnel) oder zumindest das Protokoll eines Dienstes mit dienstfremden Daten versehen und somit funktionell erweitert (z. B. DNS-Tunnel). Dafür benötigt man auf beiden Kommunikationsseiten zwingend einen Konverter, welcher z. B. die Daten eines ursprünglichen Dienstes abfängt, konvertiert und über das Protokoll eines anderen Netzwerkdienstes an das Zielsystem weiterreicht. Auf dem Zielsystem werden die empfangenen Daten in das ursprüngliche Format zurückgewandelt Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 15/50 2.3 Ergänzende Technologien Multicast/Streaming und an den Dienst weitergereicht, für den die Daten tatsächlich bestimmt sind. Tunnel werden verwendet, um unsichere Netzwerkprotokolle mithilfe eines gesicherten und verschlüsselten Netzwerkprotokolls abhör- und manipulationssicher zu transportieren (z. B. SSH-Tunnel). Sie können auch dazu dienen, ganze Rechnernetze durch ein inkompatibles Netz hindurch miteinander zu verbinden (z. B. VPN-Tunnel) oder um das Regelwerk einer Firewall und andere Sicherheitsmassnahmen zu umgehen. Prinzipiell lassen sich alle Protokolle für einen Tunnel gebrauchen. Sie müssen sich nur durch das Netzwerk routen lassen und die Möglichkeit bieten, die zu transportierenden Daten einbetten zu können. So lassen sich z. B. auch ping-Pakete (ICMP) für den Datentransport verwenden. Es sind auch asymmetrische Tunnel möglich, in dem zwei unterschiedliche Protokolle für den Hin- und Rückweg eingesetzt werden. (Wikipedia: Tunnel (Rechnernetz)) Funktionsweise Tunneling is a way in which data is transferred between two networks securely. All the data that is being transferred are fragmented into smaller packets or frames and then passed through the tunnel. This process is different from a normal data transfer between nodes. Every frame passing through the tunnel will be encrypted with an additional layer of tunneling encryption and encapsulation which is also used for routing the packets to the right direction. This encapsulation would then be reverted at the destination with decryption of data which is later sent to the desired destined node. A tunnel is a logical path between the source and the destination endpoints between two networks. Every packet is encapsulated at the source will be de-capsulated at the destination. This process will keep happening as long as the logical tunnel is persistent between the two endpoints. (techFAQ: What is Tunneling?) Point-to-Point Tunneling Protocol (PPTP) PPTP encapsulates PPP frames in IP datagram for transmission over an IP internetwork, such as the Internet. PPTP can be used for remote access and router-to-router VPN connections. PPTP or Point-to-Point tunneling protocol works over TCP port which is also used for tunnel management and GRE or Generic Routing Encapsulation protocol to encapsulate any PPP frames which will later be used in sending data through the tunnel. Compression or encryption will depend on the tunnel configuration. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 16/50 2.3 Ergänzende Technologien Multicast/Streaming (techFAQ: What is Tunneling?) Layer Two Tunneling Protocol (L2TP) L2TP was first proposed by Cisco Systems Inc which used a combination Layer 2 Forwarding (L2F) with PPTP. The IP frames can be encapsulated by L2TP to be sent over X.25, FR (Frame Relay), ATM (Asynchronous Transfer Mode) networks. And L2TP based IP tunnel over the internet is the safest way of data transfer today which uses the compression and/or encryption as required to protect the data from intruders. (techFAQ: What is Tunneling?) 2.3.3 Service Advertising Protocol (SAP) Das Service Advertising Protocol, oder kurz SAP, ist ein in IPX-Netzwerken verwendetes Protokoll zur Dienstauffindung. Es wurde ursprünglich, wie auch IPX, von Novell Inc. für Netware entwickelt. Das SAP funktioniert nach dem Broadcast-Prinzip. Jeder Server oder Host, der einen Netzwerkdienst anbietet, sendet periodisch einen IPX-Broadcast ins Netz. Das SAPPaket enthält dabei die Informationen, welcher Dienst angeboten wird, wie die Route zum Host ist und welche IPX-Adresse der Host hat der diesen Dienst anbietet. Die Clients cachen diese Informationen lokal, so dass wenn Sie einen der angebotenen Dienste benötigen sofort die entsprechende Netzwerkadresse haben. Alternativ besteht für den Client auch die Möglichkeit über einen SAP-Request, ebenfalls ein Broadcast, netzweit anzufragen ob ein bestimmter Dienst angeboten wird. Die Besonderheit an SAP-Broadcasts ist, dass diese geroutet werden, und nicht wie allgemein üblich auf das jeweilige lokale Netzwerksegment begrenzt sind. Bei seiner Einführung war das SAP eine gute Erfindung, die eine gewisse Art des Plug and Play darstellte, da man sich über die Konfiguration der Clients in einem IPXNetzwerk keine Gedanken machen musste. Einige Zeit später zeigte sich aber auch das Problem, das hinter dem Prinzip der netzwerkweiten Broadcasts lag. Der standard Zeitraum für einen SAP Broadcast war von Novell auf 60 Sekunden festgelegt worden. In den immer weiter wachsenden Netzwerken kam es also bald zu regelrechten Broadcaststürmen, da jeder Netzwerkdrucker, jeder Server, jeder Router und teilweise auch einige Clients Dienste im Netz anboten. In späteren TCP/IP-gestützten Versionen von Netware wurde das SAP daher durch das Service Location Protocol abgelöst. (Wikipedia: SAP (Protokoll)) Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 17/50 2.3 Ergänzende Technologien 2.3.4 Multicast/Streaming Network Address Translation (NAT) Network Address Translation (NAT) ist in Rechnernetzen der Sammelbegriff für Verfahren, um automatisiert und transparent Adressinformationen in Datenpaketen durch andere zu ersetzen. Diese kommen typischerweise auf Routern und Firewalls zum Einsatz. Man unterscheidet zwei grundsätzliche Typen von NAT: Outbound NAT (Traditional NAT), bei dem Verbindungen nur in eine Richtung initiiert werden können Two-Way NAT (Bi-directional NAT), bei dem neue Verbindungen von beiden Seiten aufgebaut werden können Outbound NAT wird zusätzlich in zwei Kategorien eingeteilt: Basic NAT , bei dem nur IP-Adressen umgesetzt werden Network Address Port Translation (NAPT), bei dem auch eine Umsetzung von IP-Adressen und Port-Nummern stattfindet Darüber hinaus werden noch zwei Spezialfälle von NAT eingeführt: Twice NAT , bei dem sowohl Quell- als auch Zieladresse umgeschrieben werden Multihomed NAT , bei dem mehrere NAT-Router parallel eingesetzt werden, etwa um die Ausfallsicherheit zu erhöhen Network Address Port Translation (NAPT) stellt mittlerweile die häufigste Form des NAT dar und wird daher oft als Synonym gebraucht. Da es neben der Umsetzung von IPAdressen auch eine Umsetzung von Port-Nummern gestattet, wird es oft eingesetzt, um durch sogenanntes „maskieren“ (masquerading) eine Reihe von (privaten) IP-Adressen und zugeordneten Port-Nummern zur Nutzung nur einer (öffentlichen) IP-Adresse zu verwenden. Grosse Verbreitung fand NA(P)T durch die Knappheit öffentlicher IPv4-Adressen und die Tendenz, private Subnetze über Einwahlverbindungen mit dem Internet zu verbinden. Die einfachste Lösung des Problems beschränkter IP-Adressen war oft die durch NAT mögliche Verwendung mehrerer privater IP-Adressen mit nur einer öffentlichen IP-Adresse. Gerade in privaten oder möglichst preisgünstig ausgeführten Netzinstallationen wird NAT als eine Art Sicherheitsfeature und zur Trennung von internem und externem Netz eingesetzt. Während eine NAT-Installation oberflächlich tatsächlich diese gewünschte Wirkung erzielt, kann sie jedoch weder Sicherheitsinfrastruktur noch wirksame Massnahmen zur Trennung von Netzen ersetzen. So wird die NAT-Funktion eines Routers im Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 18/50 2.3 Ergänzende Technologien Multicast/Streaming Allgemeinen stets durch ein zusätzlich betriebenes Application Level Gateway (ALG) unterstützt, welches den NAT-Router entsprechend der Informationen der Applikationsschicht konfiguriert, um komplexere Protokolle (FTP, VoIP) zu unterstützen. Dazu wird kurzzeitig, doch von Angreifern jederzeit reproduzierbar, die angesprochene Trennung der Netze durch das ALG aufgehoben. Es gilt zu beachten, dass die Aufgabe von NAT ist, Netzwerke zu verbinden, nicht sie zu trennen. (Wikipedia: Network Address Translation) Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 19/50 Multicast/Streaming 3 3.1 Vorgegebener Laborversuch Aufbau Der vorgegebene Versuch soll einem MBone ähneln. MBone (Multicast Backbone) ist eine Erweiterung des IP-Protokolls zur Unterstützung von Multicasting. MBone ist nicht mit dem Internet vergleichbar, baut jedoch auf dem Internet auf. Das im Internet verwendete TCP/IP Protokoll teilt Daten in Pakete ein, die ihren Weg unabhängig zum Zielort finden und dort wieder zur Ausgangsinformation zusammengesetzt werden. Diese Übertragungsmethode ist sehr gut für statische Informationen geeignet, weniger aber für Multimediadaten wie Video oder Audio. MBone vermeidet es so lange wie möglich, solche Daten in kleine Pakete zu unterteilen, damit die Daten alle Empfänger möglichst gleichzeitig erreichen. Abbildung 5: Vorgegebener Versuchsaufbau Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 20/50 3.2 DHCP-Konfiguration Multicast/Streaming Bei diesem Versuch geht es darum, zwei Multicast-Inseln über ein multicastunfähiges Netzwerk zu verbinden. Um dies zu realisieren ist das Erstellen eines IP-Tunnels von Nöten. Für den Router ISP sind somit die Multicast-Daten nichts weiter als zu routende IP-Pakete, da der wahre Inhalt durch den realisierten Tunnel versteckt wird. Der Router Zürich wird zusätzlich als Rendezvous-Point konfiguriert. Dies ist notwendig, da der Router das PIM-SM-Protokoll (Protocol Independent Multicast sparse mode) verwenden soll. Dies bedeutet, dass jeder Benutzer explizit nach den Multicast-Daten nachfragen muss. (Es wird also nichts geflutet!) Der Rendezvous-Point übernimmt dabei die Rolle des Treffpunkts, wo sich der Sender und Empfänger treffen. Der Sender, d.h. derjenige, der die Daten streamt, sendet alle Daten zum RendezvousPoint. Diese Daten werden dann an alle Empfänger weitergeleitet, die in dessen Verteilerbaum gespeichert sind. Der Rendezvous-Point wird manuell konfiguriert. Auf die automatische Suche wird verzichtet. 3.2 DHCP-Konfiguration Die beiden Router Zürich und London besitzen einen so genannten DHCP-Pool, damit sie den Computern im eigenen Netz eine IP und alle wichtigen Angaben zum Netz zur Verfügung stellen können. Dies geschieht mit folgenden Befehlen: Z u e r i c h ( c o n f i g )# i p dhcp p o o l C l i e n t s Z u e r i c h ( dhcp−c o n f i g )#network 1 4 7 . 8 8 . 1 0 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 Z u e r i c h ( dhcp−c o n f i g )# d e f a u l t −r o u t e r 1 4 7 . 8 8 . 1 0 . 1 London ( c o n f i g )# i p dhcp p o o l C l i e n t s London ( dhcp−c o n f i g )#network 1 3 1 . 1 1 1 . 1 0 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 London ( dhcp−c o n f i g )# d e f a u l t −r o u t e r 1 3 1 . 1 1 1 . 1 0 . 1 Somit ist die Konfiguration der einzelnen Computer nicht mehr nötig und es können nachträglich mehrere Computer ohne Konfigurationsaufwand dem Netz hinzugefügt werden. 3.3 Multicast/IGMP Konfiguration Multicast und Streaming sind zwei völlig unabhängige Technologien. Jedoch passen sie hervorragend zusammen, denn Streaming über Multicast ist effizienter als über Unicast und der Einsatz von Multicast kann anhand von Streaming sehr gut gezeigt werden. Multicast ist das Senden von Informationen, die an mehrere Ziele in einem Netzwerk gleichzeitig Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 21/50 3.4 Verbinden der Inseln Multicast/Streaming gerichtet ist. Der riesige Vorteil dabei ist, dass der Leitungsressourcenverbrauch nicht linear zu den Streaming-Anfragen ansteigt. Einfach gesagt: Egal wie viele Benutzer einen Multicast-Stream empfangen – die Netzauslastung bleibt gleich. Z u e r i c h ( c o n f i g )# i p m u l t i c a s t −r o u t i n g Z u e r i c h ( c o n f i g )# i n t e r f a c e f a s t E t h e r n e t 0/0 Z u e r i c h ( c o n f i g − i f )# i p pim s p a r s e −dense−mode Mit diesen Befehlen wird die Unterstützung von Multicast-Weiterleitungen aktiviert. Diese Einstellung ist bei der Grundkonfiguration inaktiv. (Das Ganze muss natürlich auch beim Router London gemacht werden!) Des Weiteren muss IGMP (Internet Group Management Protocol) auf dem ensprechenden Interface konfiguriert werden. IGMP ist ein Netzwerkprotokoll der IP-Familie und ermöglicht IP-Multicasting im Internet. Wenn also ein Paket an eine Multicast-IP-Adresse geschickt wird, erhalten dieses Paket mehrere Stationen gleichzeitig. Folgender IP-Adressbereich ist für Multicast reserviert: Klasse A 1.x.x.x 127.x.x.x Klasse B 128.x.x.x 191.x.x.x Klasse C 192.x.x.x 223.x.x.x Klasse D 224.x.x.x 239.x.x.x Klasse E 240.x.x.x 255.x.x.x Switchs, welche kein Multicast verstehen, werden den ganzen Multicast-Verkehr an alle vorhandenen Ports fluten. Kennt ein Switch IGMP Snooping, werden nur den interessierten Hosts diese Pakete zugestellt. IGMP Snooping kann somit ziemlich effizient den Multicast-Verkehr von gestreamten und anderen bandbreiten-intensiven Applikationen reduzieren. Es wird im Switch jedoch zusätzlicher Speicher gebraucht, um die zusätzliche Multicast-Tabelle verwalten zu können. Switch ( c o n f i g )# i p igmp s n o o p i n g v l a n 1 immediate−l e a v e Switch ( c o n f i g )#end Switch England und Schweiz haben nun beide die obige Konfiguration und leiten somit MulticastPakete weiter. 3.4 Verbinden der Inseln Da der Router ISP kein Multicasting kennt, muss ein Tunnel zwischen Router Zürich und London erstellt werden. Der Tunnel erhält eine private IP, die im Netz nicht routbar ist. Es muss einerseits das Empfangs- und Zielinterface angegeben werden, andererseits das Tunnelprotokoll (hier PIM). Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 22/50 3.4 Verbinden der Inseln Multicast/Streaming Durch den Tunnel werden die Multicast-Pakete in normale IP-Pakete eingepackt, welche somit durch den ISP routbar werden. Z u e r i c h ( c o n f i g )# i n t e r f a c e t u n n e l 0 Z u e r i c h ( c o n f i g − i f )# i p a d d r e s s 1 9 2 . 1 6 8 . 1 . 1 2 5 5 . 2 5 5 . 2 5 5 . 0 Z u e r i c h ( c o n f i g − i f )# t u n n e l s o u r c e s e r i a l 0/0 Z u e r i c h ( c o n f i g − i f )# t u n n e l d e s t i n a t i o n 1 3 1 . 1 1 1 . 0 . 2 Z u e r i c h ( c o n f i g − i f )# i p pim s p a r s e −dense−mode London ( c o n f i g )# i n t e r f a c e t u n n e l 0 London ( c o n f i g − i f )# i p a d d r e s s 1 9 2 . 1 6 8 . 1 . 2 2 5 5 . 2 5 5 . 2 5 5 . 0 London ( c o n f i g − i f )# t u n n e l s o u r c e s e r i a l 0/1 London ( c o n f i g − i f )# t u n n e l d e s t i n a t i o n 1 4 7 . 8 8 . 0 . 2 London ( c o n f i g − i f )# i p pim s p a r s e −dense−mode Der letzte Befehl aktiviert das PIM Protokoll auf dem Tunnel0. Im Zusammenhang mit dem Rendezvous-Point läuft das Protokoll im Sparse-Modus. Der Rendezvous-Point läuft auf dem Interface Loopback0. Er wird somit als logisches Routerinterface konfiguriert und ist vom Internet ansprechbar. Z u e r i c h ( c o n f i g )# i n t e r f a c e l o o p b a c k 0 Z u e r i c h ( c o n f i g − i f )# i p a d d r e s s 1 4 7 . 8 8 . 8 8 . 8 8 2 5 5 . 2 5 5 . 2 5 5 . 0 Z u e r i c h ( c o n f i g )# i p pim rp−a d d r e s s 1 4 7 . 8 8 . 8 8 . 8 8 m u l t i c a s t −a c l Z u e r i c h ( c o n f i g )# i p a c c e s s − l i s t s t a n d a r d m u l t i c a s t −a c l Z u e r i c h ( c o n f i g −std−n a c l )#p e r m i t 2 2 4 . 0 . 0 . 0 1 5 . 2 5 5 . 2 5 5 . 2 5 5 Mit diesen Einstellungen werden alle Pakete an den Rendezvous-Point gesendet, welche von der Zugriffsliste multicast-acl erlaubt werden. Dies ist in unserem Fall das Netzwerk 224.0.0.0/4, was somit alle IP-Adressen der Klasse D umfasst. Weiter muss Router London noch bekanntgegeben werden, dass er alle IGMP-Pakete an den RendezvousPoint von Router Zürich weiterleiten soll. London ( c o n f i g )# i p pim rp−a d d r e s s 1 4 7 . 8 8 . 8 8 . 8 8 m u l t i c a s t −a c l London ( c o n f i g )# i p a c c e s s − l i s t s t a n d a r d m u l t i c a s t −a c l London ( c o n f i g −std−n a c l )#p e r m i t 2 2 4 . 0 . 0 . 0 1 5 . 2 5 5 . 2 5 5 . 2 5 5 Doch diese Einstellungen genügen noch nicht um bereits Multicast-Pakete versenden zu können. Denn das wichtigste fehlt noch. Es existieren keine Routen durch den Tunnel! Diese werden nun statisch in die Tabellen eingetragen. Z u e r i c h ( c o n f i g )# i p mroute 1 3 1 . 1 1 1 . 0 . 0 2 5 5 . 2 5 5 . 0 . 0 Tunnel0 Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 23/50 3.5 Kontrolle Multicast/Streaming London ( c o n f i g )# i p mroute 0 . 0 . 0 . 0 0 . 0 . 0 . 0 Tunnel0 Da London in diesem Szenario nur mit Zürich verbunden ist, wird beim Router London nur eine Default-Multicast-Route zu Zürich eingerichtet. 3.5 Kontrolle Mit dem Befehl show ip interface brief kann gut erkannt werden, dass alle Interfaces richtig konfiguriert wurden und korrekt arbeiten. Router Zürich Interface IP-Address OK? Method Status Protocol FastEthernet0/0 147.88.10.1 YES manual up up Serial0/0 147.88.0.2 YES manual up up Serial0/1 unassigned YES unset administratively down down Loopback0 147.88.88.88 YES manual up up Tunnel0 192.168.1.1 YES manual up up Interface IP-Address OK? Method Status Protocol FastEthernet0/0 131.111.10.1 YES manual up up Serial0/0 unassigned YES unset administratively down down Serial0/1 131.111.0.2 YES manual up up Tunnel0 192.168.1.2 YES manual up up Router London Auch die PIM Interfaces wurden korrekt aufgesetzt. (show ip pim interface) Router Zürich Address Interface Ver/Mode Nbr Count Query Intvl DR Prior DR 147.88.10.1 FastEthernet0/0 v2/SD 0 30 1 147.88.10.1 192.168.1.1 Tunnel0 v2/SD 1 30 1 0.0.0.0 Router London Address Interface Ver/Mode Nbr Count Query Intvl DR Prior DR 131.111.10.1 FastEthernet0/0 v2/SD 0 30 1 131.111.10.1 192.168.1.2 Tunnel0 v2/SD 1 30 1 0.0.0.0 Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 24/50 Multicast/Streaming 4 Vertiefung 4.1 Ausgangslage 4.1.1 Serielle Verbindung vs. (Fast)Ethernet Da die Router London und Zürich über eine serielle Verbindung mit dem ISP verbunden sind, ist diese Verbindung sehr langsam. Die Verbindung konnte serverseitig mit maximal 128 kbit/s betrieben werden. Einen höheren Wert liess die Test-Hardware im Lab nicht zu. Bei einer solchen Datenrate stösst man mit Videostreaming schnell an seine Grenzen. Aus diesem Grund haben die Versuche beim vorgegebenen Laborversuch auch nur bedingt funktioniert. Die mangelnde Bandbreite machte sich beim Streamen vor allem in Form von massiven Verzögerungen bemerkbar. Oft wurde auch nur das erste Bild übertragen und das Video blieb dann stehen. Deshalb haben wir den Aufbau des Netzwerks auf ein Minimum reduziert und besonderen Wert auf die Verbindungsgeschwindigkeit gelegt. Somit wurden zwei Router und die beiden seriellen Verbindungen bei Seite gelassen und auf normale Ethernet-Verbindungen zurückgegriffen (Infrastruktur für Fast-Ethernet-Verbindungen war leider nicht vorhanden). Doch diese Einschränkung wird die Versuche nicht wesentlich beeinflussen, da es nicht das Ziel ist, hochauflösende Videos zu streamen. Immerhin können wir jetzt netzübergreifend mit 10 Mbit/s kommunizieren, was ungefähr das 80-fache der vorherigen Geschwindigkeit ist. Abbildung 6: Serielle Verbindungen (blaue Kabel) – zu langsam für Streaming Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 25/50 4.1 Ausgangslage Multicast/Streaming Abbildung 7: Vereinfachter Versuchsaufbau mit Ethernet-Verbindungen Neu an diesem Aufbau (Abb. 7) ist, dass die beiden Switches direkt über Ethernet mit dem selben Router verbunden sind. Wir nennen diesen Luzern. An der Konfiguration der Switches hat sich nichts geändert, da aus deren Sicht alles gleich bleibt. 4.1.2 Konfiguration der DHCP-Pools Da der Router Luzern nun neuer Dreh- und Angelpunkt des Netzwerks ist, dient er als DHCP-Server für die Seiten Schweiz und England. Um dies zu erreichen, wurden neu 2 DHCP Pools definiert, PoolA und PoolB. Luzern#c o n f i g u r e t e r m i n a l Luzern ( c o n f i g )# i p dhcp p o o l PoolA Luzern ( c o n f i g −dhcp)#network 1 9 2 . 1 6 8 . 1 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 Luzern ( c o n f i g −dhcp)# d e f a u l t −r o u t e r 1 9 2 . 1 6 8 . 1 . 1 Luzern ( c o n f i g −dhcp)# e x i t Luzern ( c o n f i g )# i p dhcp p o o l PoolB Luzern ( c o n f i g −dhcp)#network 1 9 2 . 1 6 8 . 2 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 Luzern ( c o n f i g −dhcp)# d e f a u l t −r o u t e r 1 9 2 . 1 6 8 . 2 . 1 Luzern ( c o n f i g −dhcp)# e x i t Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 26/50 4.2 VLC media player 4.2 Multicast/Streaming VLC media player Als Streaming-Software wurde der VLC media player eingesetzt. Er bietet alle nötigen StreamingFunktionen und ist auf Linux/Unix, Windows, Mac OS X und weiteren Plattformen verfügbar. Er ist kostenlos unter www.videolan.org downloadbar. Der VLC media player (anfänglich VideoLAN Client) ist ein portabler, freier Media Player sowohl für diverse Audio-, Videocodecs und Dateiformate als auch DVDs, VideoCDs und unterstützt unterschiedliche Streaming-Protokolle. Er kann auch als Server zum Streaming in Uni- oder Multicast in IPv4 und IPv6 verwendet werden. Besonders hervorzuheben ist die sehr hohe Robustheit des Programms, das nahezu jedes Format und jede Datei abspielt, auch unvollständige oder bruchstückhafte AVI-Dateien, was z. B. bei nicht vollständig heruntergeladenen Dateien der Fall sein kann. Dabei sind alle Standardfunktionen kommerzieller Produkte verfügbar. Zusätzlich können über Filter verschiedene Effekte in Echtzeit angewandt werden. So kann z. B. ein Video, das im Hochformat aufgenommen wurde, um 90◦ gedreht, und Farbfilter usw. können angewandt werden. Der VLC media player kommt sowohl bei Privatnutzern, in Schulen und Universitäten, aber auch bei professionellen Anwendern zum Einsatz. Geschätzt wird vor allem die hohe Kompatibilität mit einer Großzahl von Formaten und Codecs, wodurch VLC beinahe alles wiedergeben kann. (Wikipedia: VLC media player) Abbildung 8: VLC Hauptfenster unter Mac OS X Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 27/50 4.3 Multicast-Streaming mit SAP Multicast/Streaming Abbildung 9: Übersicht diverser Streaming-Lösungen mit VLC 4.3 4.3.1 Multicast-Streaming mit SAP Router-Konfiguration Mit SAP (Session Announcement Protocol) ist es möglich, ein Verzeichnis von Streams zu erhalten, ohne dabei irgendwelche IP-Adressen oder Pfade zu den jeweiligen Streams zu kennen. Auf den Routern wird keine zusätzliche Konfiguration benötigt, da SAP von Haus aus funktioniert. Will man auch auf den Routern die angekündigten SAP-Streams sehen, müssen die betroffenen Interfaces mit dem Befehl ip sap listen konfiguriert werden. In unserem Fall sind das – da wir nur noch einen Router verwenden ohne Tunnel – die Interfaces Ethernet0/0 und Ethernet0/1 des Routers Luzern. Verwendet man mehrere Router, die mit einem Tunnel verbunden sind, wird der Befehl auch auf das Tunnel-Interface angewandt. Luzern#c o n f i g u r e t e r m i n a l Luzern ( c o n f i g )# i n t e r f a c e E t h e r n e t 0 /0 Luzern ( c o n f i g − i f )# i p sap l i s t e n Luzern ( c o n f i g − i f )# e x i t Luzern ( c o n f i g )# i n t e r f a c e E t h e r n e t 0 /1 Luzern ( c o n f i g − i f )# i p sap l i s t e n Luzern ( c o n f i g − i f )# e x i t Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 28/50 4.3 Multicast-Streaming mit SAP 4.3.2 Multicast/Streaming Den Stream einrichten ... Wie in Abbildung 10 dargestellt, soll nun ein SAP-Stream von PC2 über das Netzwerk von PC3 empfangen werden. In einem weiteren Schritt soll der Stream auch von PC4 aus empfangen werden können. Auf Seiten der Router und Switches sind dafür bereits alle Einstellungen vorgenommen. Abbildung 10: Versuchsaufbau Videostreaming über SAP Um das Einrichten eines Streams zu erleichtern, bietet VLC einen Assistenten an. PC2 soll als Streaming-Station dienen, dort starten wir VLC. Über File –> Streaming/Exporting Wizard kann ein neuer Stream erstellt werden (Abb. 11). Abbildung 11: Erstellen eines neuen Streams in VLC Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 29/50 4.3 Multicast-Streaming mit SAP 4.3.3 Multicast/Streaming Auswahl der Streaming-Methode UDP Unicast Streaming direkt an eine IP-Adresse eines einzelnen Computers. Der Empfänger auf der anderen Seite muss nur noch den Port angeben, an dem der Stream ankommt. UDP Multicast Streaming an eine dynamische Gruppe von Computern in einem multicast-fähigen Netzwerk MMS Streaming über das Microsoft MMS protocol, welches von vielen Microsoft-Programmen eingesetzt wird RTP Unicast Streaming an einen einzelnen Computer, RTP (Real-Time Transport Protocol) Header werden dem Stream hinzugefügt RTP Multicast Streaming an eine dynamische Gruppe von Computern in einem multicast-fähigen Netzwerk, RTP (Real-Time Transport Protocol) Header werden dem Stream hinzugefügt HTTP Streaming an mehrere Computer über das Web (HTTP) UDP und RTP Multicast funktionieren nicht über das Internet, dazu ist HTTP vorgesehen, welches die breiteste Kompatibilität bietet. Auf der anderen Seite ist HTTP nicht gerade die effizienteste Streaming-Methode. In unserem Fall verwenden wir darum UDP Multicast. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 30/50 4.3 Multicast-Streaming mit SAP Multicast/Streaming Abbildung 12: Auswahl der Streaming-Methode in VLC Es spielt grundsätzlich keine Rolle, welche Multicast-Adresse man auswählt, so lange sich diese im verlangten Adressbereich zwischen 224.0.0.0 und 239.255.255.255 befindet. Für den privaten Einsatz wird jedoch eine Adresse beginnend mit 239.255 empfohlen. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 31/50 4.3 Multicast-Streaming mit SAP 4.3.4 Multicast/Streaming Transcoding Das Transkodieren von Audio und Video ist für diesen Versuch nicht von Bedeutung, es werden die Standardwerte benutzt. Es ist aber trotzdem gut zu wissen, dass VLC ‘on-the-fly’ in der Lage ist, einen Stream zu komprimieren bzw. transkodieren. Soll nämlich beispielsweise ein möglichst breites Publikum erreicht werden, ist es sinnvoll die Bitrate herunterzuschrauben und/oder einen Kompressionscodec wie DivX zu verwenden. So haben auch Benutzer mit vergleichsweise langsamen Verbindungen die Möglichkeit, den Stream flüssig zu sehen. Zum Vergleich: Die Bandbreite eines ISDN-Users entspricht ungefähr derer unserer seriellen Verbindung aus dem Laborbeispiel, also rund 128 kbit/s (unter Verwendung beider Leitungen). In diesem Fall wäre eine Bitrate von 64 bzw. 128 kbit/s angebracht, da sonst keine akzeptable VideoÜbertragung zu Stande kommt (insofern man bei ISDN überhaupt von akzeptablem Streaming reden kann). Auf der anderen Seite können auch moderne Codecs wie H.264 verwendet werden, die vor allem für HD-Videos sinnvoll sind. Abhängig vom gewählten Audio/Video-Codec stehen verschiedene Container-Formate zur Verfügung, so genannte Encapsulation Formats. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 32/50 4.3 Multicast-Streaming mit SAP 4.3.5 Multicast/Streaming Weitere Streaming-Optionen Time-To-Live (TTL) legt die maximale Anzahl Router fest, welche der Stream passieren kann. In unserem Fall kann dieser Wert auf 1 gesetzt werden, da nicht mehr als ein Router im Spiel ist. Wenn SAP Announce aktiviert ist, müssen die Clients keine Multicast-Adresse eingeben, sondern können den Stream direkt in der Playlist sehen. Hier kann auch ein Name gesetzt werden, ansonsten gilt der Default-Name. 4.3.6 Den Stream empfangen ... Die Clients sind über den Router Luzern verbunden (Abb. 10). PC3 möchte nun den Stream empfangen. Dank SAP muss keine IP-Adresse oder URL eingegeben werden: die Streams können bequem über das SAP-Verzeichnis gewählt werden. Auf PC3 den VLC media player und die Wiedergabeliste öffnen (über das Menü Ansicht). Dort Datei –> Services-Discovery –> SAP-Ankündigungen anklicken. Nach ein paar Sekunden werden die gesendeten Streams angezeigt und können sogleich abgespielt werden (Abb. 13). Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 33/50 4.3 Multicast-Streaming mit SAP Multicast/Streaming Abbildung 13: Abfrage der über SAP verfügbaren Streams in VLC Für PC4 gilt genau die gleiche Prozedur und genau so könnten noch viele weitere Clients den Stream von PC2 empfangen. Wie viele Clients sich verbinden, spielt für den Server keine Rolle, seine Auslastung wird deshalb nicht grösser. Das gleiche gilt für das Netzwerk. 4.3.7 Kontrolle auf dem Router Da unser Router Luzern mit dem Befehl ip sap listen konfiguriert wurde (siehe Kapitel 4.3.1), ist es nun auch möglich, die SAP-Ankündigung direkt auf dem Router zu kontrollieren. Luzern#show i p sap d e t a i l SAP Cache − 1 e n t r i e s S e s s i o n Name : MyStream Description : Group : 2 3 9 . 1 1 . 2 2 . 3 3 , t t l : 7 , Contiguous a l l o c a t i o n : 0 Uptime : 0 0 : 0 5 : 5 7 , Last Heard : 0 0 : 0 0 : 0 2 Announcement s o u r c e : 1 . 2 . 3 . 4 , d e s t i n a t i o n : 2 2 4 . 2 . 1 2 7 . 2 5 4 Created by : − 67712668194 2911 IN IP4 1 2 7 . 0 . 0 . 1 Phone number : Email : URL: Media : v i d e o 1234 udp 33 Attribute : tool : vlc 0.8.2 A t t r i b u t e : type : b r o a d c a s t Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 34/50 4.4 Video-Streaming über HTTP 4.4 Multicast/Streaming Video-Streaming über HTTP Wie in Kapitel 4.3.3 vorgestellt, existieren verschiedene Streaming-Methoden. Um Videos einfach über das Internet an einen oder mehrere Empfänger streamen zu können, bietet sich vor allem HTTP an. In unserem Versuch haben wir einen Kinofilm von einer Station A in Horw über das Internet an zwei Stationen in Cham gestreamt (Stationen C und D). Zudem soll auch noch Station B, die sich im selben Netzwerk wie A befindet, miteinbezogen werden. Ziel ist es, den Film auf allen drei Empfänger-Stationen gleichzeitig und ohne grössere Verzögerung zu sehen. Abbildung 14: Versuchsaufbau Streaming über HTTP 4.4.1 Konfiguration der Streaming-Station A Auf Station A wird der Streaming/Exporting Wizard in VLC ausgeführt. Im Gegensatz zum Versuch in Kapitel 4.3.2 wird diesmal HTTP als Streaming-Methode gewählt. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 35/50 4.4 Video-Streaming über HTTP 4.4.2 Multicast/Streaming Konfiguration Router Horw Der Standard-Port für das HTTP-Streaming ist 8080. Will nun ein Computer über das Internet mit der Station A kommunizieren, kommt er nur bis zum Router Horw. Doch wie weiss der Router nun, für wen die Pakete bestimmt sind? Hier kommt das sogenannte Port-Forwarding (NAT) zum Einsatz. Im Konfigurationspanel des Routers kann angegeben werden, welche Ports an welche Stationen im lokalen Netzwerk weitergeleitet werden sollen. In unserem Fall wollen wir sämtlichen Verkehr über Port 8080 an die Station A leiten (Abb. 15). Anmerkung: Die Prozedur zum Vornehmen dieser Einstellungen kann von Hersteller zu Hersteller abweichen. Grundsätzlich unterstützen aber alle modernen Router/Wireless-Access-Points diese Funktion. Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 36/50 4.4 Video-Streaming über HTTP Multicast/Streaming Abbildung 15: Port-Forwarding (NAT) auf einem Zyxel P-320W 4.4.3 Empfang auf den Clients Das Empfangen auf den Stationen C und D gestaltet sich mit VLC denkbar einfach. Über das Menü Datei –> Netzwerk öffnen ... wird die öffentliche IP-Adresse des Netzwerks in Horw, zusammen mit dem Streaming-Port 8080 angegeben: 80.219.5.66:8080. Station B, die sich im lokalen Netzwerk mit A befindet, gibt statt der öffentlichen lediglich die lokale IP-Adresse an: 192.168.1.33:8080 Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 37/50 4.4 Video-Streaming über HTTP Multicast/Streaming Station B – Kubuntu Station C – Mac OS X Station D – Microsoft Windows Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 38/50 4.4 Video-Streaming über HTTP Multicast/Streaming Literatur- und Quellenverzeichnis Web Configuring a Rendezvous Point, CISCO, http://www.cisco.com/en/US/docs/ios/solutions_docs/ ip_multicast/White_papers/rps.html [Stand: 26.05.2008] Dynamic Host Configuration Protocol, Wikipedia, http://de.wikipedia.org/wiki/Dynamic_Host_ Configuration_Protocol [Stand: 28.05.2008] IGMP snooping, Wikipedia, http://en.wikipedia.org/wiki/IGMP_snooping [Stand: 28.05.2008] IGMP, Wikipedia, http://de.wikipedia.org/wiki/Internet_Group_Management_ Protocol [Stand: 28.05.2008] Network Address Translation, Wikipedia, http://de.wikipedia.org/wiki/Network_Address_Translation [Stand: 29.05.2008] PIM Sparse Mode, Wikipedia, http://en.wikipedia.org/wiki/PIM_Sparse_Mode [Stand: 28.05.2008] Protocol Independent Multicast, Wikipedia, http://de.wikipedia.org/wiki/Protocol_Independent_ Multicast [Stand: 28.05.2008] Real-Time Transport Protocol, Wikipedia, http://de.wikipedia.org/wiki/Real-Time_Transport_ Protocol [Stand: 28.05.2008] SAP (Protokoll), Wikipedia, http://de.wikipedia.widearea.org/wiki/SAP_(Protokoll) [Stand: 28.05.2008] SAP-Streaming, mayah.com, http://www.mayah.com/content/download/programs/centauri2webhelp/german/index.html?hid_howto_ip_sap.htm [Stand: 28.05.2008] Streaming Media, Wikipedia, http://de.wikipedia.org/wiki/Streaming_Media [Stand: 28.05.2008] Tunnel (Netzwerktechnik), Wikipedia, http://de.wikipedia.org/wiki/Tunnel_(Netzwerktechnik) [Stand: 28.05.2008] User Datagram Protocol, Wikipedia, http://de.wikipedia.org/wiki/User_Datagram_Protocol [Stand: 28.05.2008] Streaming, Uni Bern, http://www.mmz.unibe.ch/streaming.php [Stand: 23.06.2008] What is Tunneling?, techFAQ, http://www.tech-faq.com/tunneling.shtml [Stand: 24.06.2008] Literatur PC Lexikon 2004.; ARP Datacon, Das neue PC Lexikon 2004, Markt+Technik, 2004 Andrew S. Tanenbaum, Computernetzwerke, 4. Überarbeitete Auflage, 2004 Abbildungen Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 39/50 4.4 Video-Streaming über HTTP Multicast/Streaming Abb. 9: http://www.videolan.org/vlc/streaming.html [Stand 27.05.2008] Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 40/50 Multicast/Streaming Anhang A Impressionen Hier einige Eindrücke vom Aufbau des Netzwerkes im Cisco Lab ... Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 41/50 Multicast/Streaming Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 42/50 Multicast/Streaming B Konfigurationen B.1 Router ISP version 12.3 ! hostname ISP ! enable s e c r e t 5 c i s c o ! no i p domain lookup ! i n t e r f a c e S e r i a l 0 /0 d e s c r i p t i o n to Zuerich ip address 147.88.0.1 255.255.255.0 e n c a p s u l a t i o n ppp c l o c k r a t e 128000 no shutdown ! i n t e r f a c e S e r i a l 0 /1 d e s c r i p t i o n t o London ip address 131.111.0.1 255.255.255.0 e n c a p s u l a t i o n ppp c l o c k r a t e 128000 no shutdown ! i p r o u t e 1 3 1 . 1 1 1 . 0 . 0 2 5 5 . 2 5 5 . 0 . 0 S e r i a l 0 /1 i p r o u t e 1 4 7 . 8 8 . 0 . 0 2 5 5 . 2 5 5 . 0 . 0 S e r i a l 0 /0 ! l i n e con 0 exec−t i me o u t 360 0 password c i s c o login l i n e vty 0 4 exec−t i me o u t 360 0 password c i s c o login end Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 43/50 B.2 Router Zürich B.2 Multicast/Streaming Router Zürich version 12.3 ! hostname Z u e r i c h ! enable s e c r e t 0 c i s c o ! no i p domain lookup ! i p dhcp p o o l C l i e n t s network 1 4 7 . 8 8 . 1 0 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 d e f a u l t −r o u t e r 1 4 7 . 8 8 . 1 0 . 1 ! i p m u l t i c a s t −r o u t i n g i p sap cache−t i m e o u t 1 ! i n t e r f a c e Loopback0 d e s c r i p t i o n Rendezvouz−Point ip address 147.88.88.88 255.255.255.0 ! i n t e r f a c e Tunnel0 d e s c r i p t i o n Tunnel t o London ip address 192.168.1.1 255.255.255.0 i p pim s p a r s e −dense−mode i p sap l i s t e n t u n n e l s o u r c e S e r i a l 0 /0 tunnel destination 131.111.0.2 ! i n t e r f a c e F a s t E t h e r n e t 0 /0 ip address 147.88.10.1 255.255.255.0 i p pim s p a r s e −dense−mode i p sap l i s t e n no shutdown ! i n t e r f a c e S e r i a l 0 /0 ip address 147.88.0.2 255.255.255.0 e n c a p s u l a t i o n ppp no shutdown ! Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 44/50 B.3 Router London Multicast/Streaming ip c l a s s l e s s i p r o u t e 0 . 0 . 0 . 0 0 . 0 . 0 . 0 S e r i a l 0 /0 ! i p pim rp−a d d r e s s 1 4 7 . 8 8 . 8 8 . 8 8 m u l t i c a s t −a c l i p mroute 1 3 1 . 1 1 1 . 0 . 0 2 5 5 . 2 5 5 . 0 . 0 Tunnel0 ! i p a c c e s s − l i s t s t a n d a r d m u l t i c a s t −a c l permit 2 2 4 . 0 . 0 . 0 1 5 . 2 5 5 . 2 5 5 . 2 5 5 ! l i n e con 0 exec−t i me o u t 360 0 password c i s c o login l i n e vty 0 4 exec−t i me o u t 360 0 password c i s c o login end B.3 Router London version 12.3 ! hostname London ! enable s e c r e t 0 c i s c o ! no i p domain lookup ! i p dhcp p o o l C l i e n t s network 1 3 1 . 1 1 1 . 1 0 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 d e f a u l t −r o u t e r 1 3 1 . 1 1 1 . 1 0 . 1 ! i p m u l t i c a s t −r o u t i n g i p sap cache−t i m e o u t 1 ! i n t e r f a c e Tunnel0 ip address 192.168.1.2 255.255.255.0 i p pim s p a r s e −dense−mode i p sap l i s t e n Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 45/50 B.4 Router Luzern Multicast/Streaming t u n n e l s o u r c e S e r i a l 0 /1 tunnel destination 14 7. 8 8. 0. 2 ! i n t e r f a c e F a s t E t h e r n e t 0 /0 ip address 131.111.10.1 255.255.255.0 i p pim s p a r s e −dense−mode i p sap l i s t e n no shutdown ! i n t e r f a c e S e r i a l 0 /1 ip address 131.111.0.2 255.255.255.0 e n c a p s u l a t i o n ppp no shutdown ! ip c l a s s l e s s i p r o u t e 0 . 0 . 0 . 0 0 . 0 . 0 . 0 S e r i a l 0 /1 i p r o u t e 1 4 7 . 8 8 . 8 8 . 8 8 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5 Tunnel0 ! i p pim rp−a d d r e s s 1 4 7 . 8 8 . 8 8 . 8 8 m u l t i c a s t −a c l i p mroute 0 . 0 . 0 . 0 0 . 0 . 0 . 0 Tunnel0 ! i p a c c e s s − l i s t s t a n d a r d m u l t i c a s t −a c l permit 2 2 4 . 0 . 0 . 0 1 5 . 2 5 5 . 2 5 5 . 2 5 5 ! l i n e con 0 exec−t i me o u t 360 0 password c i s c o login l i n e vty 0 4 exec−t i me o u t 360 0 password c i s c o login end B.4 Router Luzern version 12.3 ! hostname Luzern ! Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 46/50 B.4 Router Luzern Multicast/Streaming enable s e c r e t 0 c i s c o ! no i p domain lookup ! i p dhcp p o o l PoolA network 1 9 2 . 1 6 8 . 1 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 d e f a u l t −r o u t e r 1 9 2 . 1 6 8 . 1 . 1 ! i p dhcp p o o l PoolB network 1 9 2 . 1 6 8 . 2 . 0 2 5 5 . 2 5 5 . 2 5 5 . 0 d e f a u l t −r o u t e r 1 9 2 . 1 6 8 . 2 . 1 ! i p m u l t i c a s t −r o u t i n g i p sap cache−t i m e o u t 1 ! i n t e r f a c e Loopback0 d e s c r i p t i o n Rendezvouz−Point ip address 192.168.10.10 255.255.255.0 ! i n t e r f a c e E t h e r n e t 0 /1 ip address 192.168.1.1 255.255.255.0 i p pim s p a r s e −dense−mode i p sap l i s t e n no shutdown ! i n t e r f a c e E t h e r n e t 0 /0 ip address 192.168.2.1 255.255.255.0 i p pim s p a r s e −dense−mode i p sap l i s t e n no shutdown ! i p pim rp−a d d r e s s 1 9 2 . 1 6 8 . 1 0 . 1 0 m u l t i c a s t −a c l ! i p a c c e s s − l i s t s t a n d a r d m u l t i c a s t −a c l permit 2 2 4 . 0 . 0 . 0 1 5 . 2 5 5 . 2 5 5 . 2 5 5 ! l i n e con 0 exec−t i me o u t 360 0 password c i s c o Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 47/50 B.5 Switch England Multicast/Streaming login l i n e vty 0 4 exec−t i me o u t 360 0 password c i s c o login end B.5 Switch England version 12.1 ! hostname England ! enable s e c r e t 0 c i s c o ! i p igmp s n o o p i n g v l a n 1 immediate−l e a v e ! no i p domain−lookup ! spanning−t r e e mode p v s t no spanning−t r e e o p t i m i z e bpdu t r a n s m i s s i o n spanning−t r e e extend system−i d no spanning−t r e e v l a n 1 ! i n t e r f a c e F a s t E t h e r n e t 0 /1 i n t e r f a c e F a s t E t h e r n e t 0 /2 i n t e r f a c e F a s t E t h e r n e t 0 /3 i n t e r f a c e F a s t E t h e r n e t 0 /4 i n t e r f a c e F a s t E t h e r n e t 0 /5 i n t e r f a c e F a s t E t h e r n e t 0 /6 i n t e r f a c e F a s t E t h e r n e t 0 /7 i n t e r f a c e F a s t E t h e r n e t 0 /8 i n t e r f a c e F a s t E t h e r n e t 0 /9 i n t e r f a c e F a s t E t h e r n e t 0 /10 i n t e r f a c e F a s t E t h e r n e t 0 /11 i n t e r f a c e F a s t E t h e r n e t 0 /12 ! i n t e r f a c e Vlan1 no i p r o u t e −c a c h e ! Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 48/50 B.6 Switch Schweiz Multicast/Streaming ip http s e r v e r no cdp run ! l i n e con 0 exec−t i me o u t 360 0 password c i s c o login l i n e vty 0 4 exec−t i me o u t 360 0 password c i s c o login l i n e vty 5 15 login end B.6 Switch Schweiz version 12.1 ! hostname Schweiz ! enable s e c r e t 0 c i s c o ! i p igmp s n o o p i n g v l a n 1 immediate−l e a v e ! no i p domain−lookup ! spanning−t r e e mode p v s t no spanning−t r e e o p t i m i z e bpdu t r a n s m i s s i o n spanning−t r e e extend system−i d no spanning−t r e e v l a n 1 ! i n t e r f a c e F a s t E t h e r n e t 0 /1 i n t e r f a c e F a s t E t h e r n e t 0 /2 i n t e r f a c e F a s t E t h e r n e t 0 /3 i n t e r f a c e F a s t E t h e r n e t 0 /4 i n t e r f a c e F a s t E t h e r n e t 0 /5 i n t e r f a c e F a s t E t h e r n e t 0 /6 i n t e r f a c e F a s t E t h e r n e t 0 /7 i n t e r f a c e F a s t E t h e r n e t 0 /8 Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 49/50 B.6 Switch Schweiz Multicast/Streaming i n t e r f a c e F a s t E t h e r n e t 0 /9 i n t e r f a c e F a s t E t h e r n e t 0 /10 i n t e r f a c e F a s t E t h e r n e t 0 /11 i n t e r f a c e F a s t E t h e r n e t 0 /12 ! i n t e r f a c e Vlan1 no i p r o u t e −c a c h e ! ip http s e r v e r no cdp run ! l i n e con 0 exec−t i me o u t 360 0 password c i s c o login l i n e vty 0 4 exec−t i me o u t 360 0 password c i s c o login l i n e vty 5 15 login end Hochschule Luzern – T&A ICT Betrieb und Nutzung Seite 50/50