Multicast, Streaming

Transcription

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
philippe.manner@stud.hslu.ch
Andy Abgottspon
Tel. +41 79 703 75 15
andy.abgottspon@stud.hslu.ch
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
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
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
. . . . . . . . . . . . . . . . . . . . . .
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.
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.
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.
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)
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.
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
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.
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:
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.
Seite 13/50
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)
Seite 14/50
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
Seite 15/50
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.
Seite 16/50
Multicast/Streaming
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.
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))
Seite 17/50
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
Seite 18/50
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)
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
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
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).
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
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
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
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
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
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
Seite 28/50
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
Seite 29/50
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.
Seite 30/50
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.
Seite 31/50
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.
Seite 32/50
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).
Seite 33/50
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
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.
Seite 35/50
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.
Seite 36/50
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
Seite 37/50
Multicast/Streaming
Station B – Kubuntu
Station C – Mac OS X
Station D – Microsoft Windows
Seite 38/50
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
Seite 39/50
Multicast/Streaming
Abb. 9: http://www.videolan.org/vlc/streaming.html [Stand 27.05.2008]
Seite 40/50
Multicast/Streaming
Anhang
A
Impressionen
Hier einige Eindrücke vom Aufbau des Netzwerkes im Cisco Lab ...
Seite 41/50
Multicast/Streaming
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
!
d e s c r i p t i o n t o London
ip address 131.111.0.1 255.255.255.0
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
password c i s c o
login
end
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
!
!
!
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 sap l i s t e n
no shutdown
!
ip address 147.88.0.2 255.255.255.0
no shutdown
!
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
password c i s c o
login
l i n e vty 0 4
password c i s c o
login
end
B.3
Router London
version 12.3
!
hostname London
!
!
!
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 n t e r f a c e Tunnel0
ip address 192.168.1.2 255.255.255.0
i p sap l i s t e n
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
!
ip address 131.111.10.1 255.255.255.0
i p sap l i s t e n
no shutdown
!
ip address 131.111.0.2 255.255.255.0
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
!
permit 2 2 4 . 0 . 0 . 0 1 5 . 2 5 5 . 2 5 5 . 2 5 5
!
l i n e con 0
password c i s c o
login
l i n e vty 0 4
password c i s c o
login
end
B.4
Router Luzern
version 12.3
!
hostname Luzern
!
Seite 46/50
B.4 Router Luzern
Multicast/Streaming
!
!
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 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 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 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
!
permit 2 2 4 . 0 . 0 . 0 1 5 . 2 5 5 . 2 5 5 . 2 5 5
!
l i n e con 0
password c i s c o
Seite 47/50
B.5 Switch England
Multicast/Streaming
login
l i n e vty 0 4
password c i s c o
login
end
B.5
Switch England
version 12.1
!
hostname England
!
!
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 Vlan1
no i p r o u t e −c a c h e
!
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
password c i s c o
login
l i n e vty 0 4
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
!
!
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
!
Seite 49/50
B.6 Switch Schweiz
Multicast/Streaming
!
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
password c i s c o
login
l i n e vty 0 4
password c i s c o
login
l i n e vty 5 15
login
end
Seite 50/50

Multicast, Streaming

Transcription

Similar documents

Kommunikation – Labor Begleithandbuch zu den Versuchen 1-4

USB Storage Device Class -- Überblick und

Netzwerk-Attacken Glossar Netzwerk

Leopold Franzens - Universität Genauere Analyse des

HXR-NX5E Brochure