Multicast
aus ANOther Wiki, der freien Wissensdatenbank
Inhaltsverzeichnis |
Übersicht
Multicast Gruppen
Warum Multicast?
Multicast wird verwendet, wenn die selben Datenpakete verschiedenen Empfängern zugestellt werden sollen. Wird ein Paket zu Multicast-Empfängern gesendet, wird dies nicht für jeden Empfänger versendet, sondern als einzelner Stream. Dieser Sream wird von den Downlevel-Routern danach auf die jeweiligen Empfängern zugestellt. Der Stream wird also vervielfältigt, an den jeweils letzten Knoten vor der "Abzweigung". Dadurch wird einiges an Last von den Routern, der Leitung genommen, da nur ein einzelnes Paket von der Quelle ausgesendet werden muss.
Da erst die Downlevel-Router die Paketverteilung vornehmen, kann/muss der Sender die IP-Adresse des Empfängers nicht kennen.
Ein Anwendungsgebiet für Multicast sind Video/Audiostreams
Vorteile von Multicast
Annahme: Ein Netzwerk, 100 User. Diese 100 Userhören einen 16kbps-Audiostream. Das Netzwerk wird mit 16kbps belastet. Würde dieser Stream anstatt mit Multicast mit Unicast verbreitet, wird das Netz mit 100x16=1.6mbps belastet
Vorteile also:
- erhöhte Effizienz
- optimale Performance
- ideal für die Anwendungsverteilung
Video on Demand (VoD) wäre ohne Multicast nicht denkbar
Nachteile von Multicast
Multicast ist UDP-basierend, d.h. es kann durchaus passieren, dass Pakete verloren gehen. Ausserdem gilt eine UDP-Übertragung nicht als vertrauenswürdig.
Arten von Multicast-Anwendungen
- one-to-many: wird zb. bei Videostreams verwendet
- many-to-many: hier arbeiten zB. einige Empfänger auch als Sender
Weiters gibt es einige Anwendungen für many-to-one, wo zb. Hosts zum Zwecke einer Datensammlung an einen zentralen Empfänger schicken
Anwendungsgebiete
Neben Realtime-Anwendungen kann wird Multicast auch zb. für das Simultanaufsetzen von PCs verwendet
IP-Multicast-Adressen
IP-Multicast Adressierung
Multicast-Adressen nutzen die Klasse-D-Adressen (1110) Multicasts in dieser Range werden nur im lokalen Netz weitergeleitet. Die TTL liegt in der Regel auf 1.
Einige lokale Multicast-Adressen:
- 224.0.0.1 alle Hosts
- 224.0.0.2 alle Multicast-Router
- 224.0.0.4 alle DVMPR (Distance Vector Multicast Routing Protocol)-Router
- 224.0.0.5 alle OSPF-Router
- 224.0.0.6 alle OSPF- DR
- 224.0.0.9 alle RIPv2-Router
- 224.0.0.10 alle EIGRP-Router
Für Multicastanwendungen werden vorübergehende Adressen verwendet, die nach Gebrauch wieder verworfen werden. Man unterscheidet zwischen zwei Typen
- globale Adressen: 224.0.1.0 - 238.255.255.255. So ist zb. der Bereich 224.2.x.x für MBone (Multicast Backbone) reserviert
- administrative Adressen: 239.0.0.0 - 239.255.255.255, welche reserviert sind für private Domains
Der Administrative Bereich ist wiederum in zwei Bereiche unterteilt
- side-local: 239.255.0.0/16, 239.252.0.0/16, 239.254.0.0/16
- organisation-local: 239.192.0.0 - 239.251.255.255
Multicast-Sessions
Wenn eine Multicastanwendung auf einem Empfänger gestartet wird, muss die Anwendung wissen, welcher Multicast-Gruppe sie beitreten muss. Die Anwendung muss informationen über die verfügbaren Streams/Sessions lernen
Es gibt verschiedene Möglichkeiten für die Applikationen, diese Informationen zu lernen:
- die Anwendung verwendet bekannte, vordefinierte Gruppen
- ein Directory-Service ist verfügbar, über diesen die Anwendung die Infos erhält
- die Anwendung wird über einen Link gestartet. Auch ein via Mail verbreiteter Link ist möglich
Die Session-Directory-Application (sd) fungiert als Guide, welcher den Multicast-Content anzeigt. Eine Clientanwendung läuft am PC und informiert den User über den verfügbaren Content. Diese Verzeichnisanwendung verwendet entweder SDP (Session Description Protocol) oder SAP (Session Announcement Protocol), um über dn Content zu lernen. (SAP und SDP werden auch als SDR oder sdr bezeichnet)
IGMP und Layer2
Einführung IGMP2
IGMP ist ein Host-zu-Router-Protokoll, welches verwendet wird, wenn Hosts einer Multicastgruppe beitreten wollen. In IGMPv1 senden Router periodische Mitgliedschaftsabfragen an die Multicastadresse 224.0.0.1. Hosts senden die gewünschte Gruppe an die jeweilige Gruppen-Multicastadresse; Hosts verschwinden leise, still und heimlich aus den Gruppen
Aufgrund einiger Einschränkungen bei v1 wurde IGMPv2 entworfen. Die wichtigsten Unterschiede sind
- Gruppenspezifische Queries: nun können Router auch einzelne Gruppen abfragen
- Leave-Group-Message: die Hosts teilen dem Router das Verlassen der Gruppe mit. So wird die Last von einem Segment genommen, wenn der letzter Member aus der Gruppe ausgetreten ist
Beitreten einer Gruppe
Beim Betreten einer Gruppe muss ein Member nicht auf eine Query warten, es wird einfach das Interesse bekundet Mit show ip igmp group können einige Informationen die Gruppen betreffend abgefragt werden. So zb. der letzte beigetretene Host, sowie die Zeit des "Entstehens" und des "Auflösens" der Gruppe
Befinden sich zwei IGMP-Router im selben Ethernetsegment (Broadcast-Domain), wird der Router mit der höheren IP der designierte Querier
Verlassen einer Gruppe
In v1 verlässt der Host die Gruppe, ohne einen Hinweis auf das Verlassen zu hinterlassen. IGMPv2 hinterlässt einen solchen Hinweis
Wenn ein v2-Router eine Leave-Message erhält, antwortet er mit dem Senden einer gruppenspezifischen Anfrage. Damit kann der Router feststellen, ob noch Hosts in seinem Segment verbleiben
IGMPv3
Der Zweck für v3, welches den Antrag auf einen Standard gestellt hat, ist hauptsächlich, dass Hosts er erkennen geben können, von wem sie Traffic empfangen wollen
Bestimmen der IGMP-Version
Die Version wird mit
show ip igmp interface
ausgegeben
Multicast, Layer-2-Switching
Für die meisten Switches bedeutet Multicast-Verkehr das selbe wie unbekannte MAC-Adressen: es wird gefloodet, an allen Ports, in allen VLANs
Eine Möglichkeit, wie Cisco-Catalysts dieses Problem angehen ist, dass der Administrator Multicast-Adressen verschiedenen Ports zuweist. So kann er die Ports 2, 3 und 8 so konfigurieren, dass nur diese den Multicast-Verkehr für die jeweilige Gruppe erhalten. Dies funktioniert, ist aer nicht skalierbar. IP-Multicast-Hosts betreten und verlassen Gruppen dynamisch, unter Verwendung von IGMP um den Multicast-Routern zu signalisieren. Dynamische Konfiguration der Forardingtables der Switches ist daher effizienter und spart administrative Arbeit
Auf Schicht-3 kann ein User auch mittels des PIM (Protocol-Independent Multicast) über das Internet multicasten. Dies ist eine Familie von Multicast Routing Protokollen, die one-to-many und many-to-many Datenverteilung über das Internet beherrschen. Der "protokollunabhängige" Teil beruht auf dem Fakt, dass PIM keinen eigenen topologieerforschenden Mechanismus hat, aber die Routinginformationen von traditionellen Routingprotokollen wie BGP verwendet
Schicht-2 Multicast Switchinglösungen
- CGMP: Cisco Group Management Protocol ist ein proprietäres Protokoll, welches zwischen einem Multicast-Router und einem Switch läuft.
- IGMP snooping: hier schnüffelt der Switch mit, und passt laufend seine MAC-Tabelle entsprechend an
CGMP
CGMP basiert auf einem Client/Servermodell, wobei dem Router die Server-, dem Switch die Clientrolle zugewiesen wird. Softwarekomponenten auf beiden Seiten wandeln IGMP in CGMP-Befehle um, mit denen dann die Forwardingtabellen des Switches gesteuert werden
Die Grundlage von CGMP ist, dass ein Multicastrouter alle IGMP-Pakete sieht, und daher den Switch informieren kann, wenn ein Host einer Gruppe beitritt oder eine Gruppe verlässt. Router verwenden bekannte CGMP-Multicast MAC-Adressen, um die CGMP-Steuerpakete zum Swtch zu senden. Der Switch verwendet diese Information dann, um seine Forwardingtabelle dementsprechend zu programmieren
Wenn ein Router ein IGMP-Steuerpaket sieht, erstellt er ein CGMPPaket, welches die Art des Requests beinhaltet (beitreten/verlassen), die L2-Multicast MAC-Adresse und die MAC-Adresse des Clients
Dieses Paket wird zur bekannten CGMP Multicast MAC-Adresse 0x0100.0cdd.dddd zu allen lauschenden Switches geschickt. Die CGMP-Steuernachricht wird interpretiert, und die Einträge werden im Swich-CAM (content-addressable memory) erstellt. So wird der Multicast-Verkehr für diese Gruppe eingeschränkt
IGMP snooping
Die zweite Möglichkeit ist das IGMP-Snooping. Wie der Name schon sagt, wird hier geschnüffelt, und zwar nach den IGMP-Membershp reports und den IGMP leaves.
Bei der Implementierung sollte vorsichig vorgegangen werden, denn wenn ein Switch alle L2-Multicast-Pakete überprüfen muss hat dies starke Auswirkungen auf die Leistung des Switch
Multicast-Routingprotokolle
Verwendete Protokolle
Multicast Protokolle: Grundlagen
Multicast Distribution Trees definieren den Pfad von der Quelle bis zum Empfänger, den der Multicasttraffic fließt
Es gibt zwei Typen von Multicast-Trees:
- source-routed tree
- shared tree
Beim Source-Routed-Tree wird ein separater Zweig für jede Quelle zu allen Mitgliedern dieser Gruppe gebaut. Da dieser Weg der direkte, der kürzeste ist, wird dieser Typ auch SPT, Short Path Tree, genannt
Shared Tree Protocols stützen sich beim Erstellen der Multicast-Forwardingpfade auf zentrale Knotenrouter, die einen Rendezvous-Punkt (RP) zwischen den Mulitcast-Quellen und Zielen bieten. Quellen senden erst die Mulicast-Pakete zum RP, welcher sie dann als shared-tree zu den jeweiligen Empfängern weiterleitet. Shared Tree ist weniger effizienter als SPT, aber schont Speicher und CPU
Grundsätzlich gibt es zwei Arten von Multicast-Routingprotokollen:
- dense mode protocols: sie flooden Multicasttraffic über das ganze Netzwerk und beschneiden ihn da, wo keine Clients dahinter sind. Hierfür wird ein periodischer flood-and-prune-Mechanismus verwendet
- sparse mode protocols: sie verwenden einen extrigen Auswahlmechanismus, bei dem die Verteilerbäume nur bei Bedarf aufgbaut werden. Dies passiert, wenn direkt angeschlossene Empfänger an den Routern eine Tree-Join-Message auslösen
Identifizierung von Multicast Distributiontrees
Die Multicast-Forwardungeinträge, die in einer Multicast-Forwardingtabelle aufscheinen, können wie folgt gelesen werden
- (S, G): Für die Quelle (S), welche an die Gruppe (G) sendet; diese Einträge zeigen in der Regen SPT, können aber auch zu einem Shared Tree gehören
- (*, G): Für jede Quelle (*), welche an die Gruppe G sendet; reflektieren für gewöhnlich Shared Trees, werden aber (in Cisco-Routern) auch für alle existierenden (S, G) einträge erstellt
SPT-Einträge benötigen mehr Router-Speicher, da für jedes Sender-Empfängerpaar ein eigener Eintrag existiert. Allerdings kann der Verkehr dann auch für jeden Empfänger direkt am besten Weg zugestellt werden. Dies minimiert das Delay
Shared Distribution Tree-Einträge hingegen benötigen wesentlich weniger Routermemory, allerdings können suboptimale Pfade zwischen Quelle und Ziel verwendet werden, mit allen verbundenen Nachteilen
IP Multicast Routing
Multicast Forwarding
Beim Unicastrouting trifft der Router die Entscheidung, wohin das Paket zu senden ist, anhand der Empfängeradresse im Paket. Beim Multicastrouting ist die Entscheidung hingegen von der Quelle abhängig
Multicastrouter müssen den Ursprung des Paketes kennen, was der Unterschied zum Unicast-Routing ist
Multicastrouting verwendet einen Mechanismus, Reverse Path Forwarding (RPF), um vor Loops zu schützen und sicherzustellen, dass der kürzeste Pfad zu den Empfängern verwendet wird.
Einführung PIM
Der PIM-dense mode (PIM-DM) initialisiert einen Multicasttraffic, der über alle Netzwerkteile gefloodet wird. PIM-DM initialisiert flood-traffic aus allen nicht-RPF-Interfaces, an denen ein weiterer PIM-DM Nachbar hängt, bzw ein direkt angeschlossenes Member der Gruppe
Multicast: Konfiguration und Überprüfung
Konfigurieren von PIM-SM und PIM Sparse-Dense-Mode an einem Interface
router(config)# ip multicast-routing
mit diesem Befehl wird Multcast-Routing auf einem Router aktiviert
router(config-if)# ip pim {sparse-mode | sparse-dense-mode}
ip pim sparse-mode
aktiviert die PIM-SM-Operation am gewählten Interface. Der Befehl
ip pim sparse-dense-mode
lässt das Interface im PIM-SM für sparse-mode-groups (die mit belannten Rendezvous points [RP]) und im dense-mode (für alle anderen Gruppen) operieren
router(config)# ip pim send-rp-announce {Interfacetyp} scope {ttl} group-ist {acl}
Das globale Kommando wird auf dem Router ausgeführt, der ein RP werden soll. Dieser Router sendet eine Auto-RP-Nachricht an 224.0.1.39, in der die Bereitschaft des Routers steht, als RP zu fungieren, für die Gruppen, die lt. Accesslists definiert sind
router(config)# ip pim send-rp-discovery {Interfacetyp} scope {ttl}
Dieses globale Kommando konfiguriert einen Router als RP-Mapping-Agent.; er lauscht auf 224.0.1.39 und sendet eine RP-zu-Gruppen-Mappingsachricht nach 224.0.1.40. Andere PM router lauschen auf 224.0.1.40, und erkennen den RP so automatisch
router(config)# ip pim spt-threshold {rate | infinity}
kontrolliert den Switchover vom shared-distribution-tree zum SPT. "infinity" bedeutet, dieser Wechsel passiert nie
Überprüfen der Multicast-Routingtabelle
router# show ip mroute [group-adress] [summary] [count] [active kbps]
Der show ip mroute-Befehl ist das brauchbarste Kommando, um den Status von Multicastquellen und ~gruppen zu bestimmen, aus der Sicht des Routers, auf dem der efehl ausgeführt wir
Der Output dieses Befehls repräsentiert einen Teil des Multicast-Verteilerbaums, mit einem eingehenden und einer Liste von ausgehenden Interfaces. Die Optionen sind folgende:
- Summary: zeigt eine online, gekürzte Übersicht über jeden Eintrag in der IP-Multicast-Routingtabelle
- Count: liefert eine Statistik über Gruppen und Quellen, inklusive Paketanzahl, Pakete pro Sekunde, durchschnittliche Paketgröße und Bita pro Sekunde
- Active: zeigt, welche Quellen an welche Gruppen senden. Aktive Gruppen sind jene, die mit einer Rate oder mehr senden, die im kbps-Argument angegeben sind. Für dieses Argument liegt der Defaltwert bei 4 kbps
Finden von PIM-Nachbarn
router# show ip pim interface [type number] [count] zeigt Informationen über die für PIM konfigurierten Interfaces
router# show ip pim neighbor [typ number] listet die PIM-Nachbarn auf, die vom Cisco-IOS gefunden wurden
router# mrinfo [hostname | address] zeigt Informationen über Multicastrouter, die mit dem lokalen Router peeren
router# show ip pim interface
Dieser Befehl liefert folgende Informationen
- Address: IP-Adresse des Inerfaces
- Interface: Typ und Numemr des PIM-Interfaces
- Ver/Mode: konfigurierte PIM-Version (1/2) und der Modus (dense mode, sparse mode oder sparse-dense-mode)
- Nbr Count: Anzahl der Nachbarn an diesem Link
- Query Intvl: Frequenz, mit der PIM-Hellos und PIM-Queries gesendet werden (default ist 30 Sekunden)
- DR Prior: Priorität, sie wird für die Wahl des DR (designated router) verwendet. Wenn zwei Router an einem Link die selbe IP haben, gewinnt der mit der höheren IP
- DR: IP des DR. Bei Punkt-zu-Punkt-Verbindungen gibt es keinen DR, dies wird mit 0.0.0.0 dargestellt
router# show ip pim neighbor
Dieser Befekl zeigt Informationen über:
- Neighbor Address: IP-Adresse des PIM-Nachbarn
- Interface: das Interface, über das das PIM-Hello von dem Nachbarn empfangen wurde
- Uptime: Zeit, die der PIM-NAchbar aktiv ist
- Expires: Nach Ablauf dieser Zeit gilt der Nachbar nicht mehr aktiv. Ein neues PIM-Hello oder eine PIM-Query setzt den Counter wieder zurück
- Ver: PIM-Version des Nachbars, (1/2)
- DR Priority: wenn der Nachbar diese unterstützt wird die Priorität hier angezeigt. Wenn er es nicht unterstützt erscheint ein "none"
Überprüfen von RP-Informationen
router(config)# sh ip pim rp [group-name | group-address | mapping]
zeigt aktive RPs, die in den assiziierten Multicast-Routingeinträgen
- mapping zeigt alle group-to-RP-Mappings des Routers
router(config)# sh ip rpf {address | name)
zeigt Informationen über Reverse Path Forwarding (RPF) für einen RP
router# show ip pim rp
Der Output des show ip pim rp Befehls listet alle altiven Gruppen und deren zugehörigen PPs auf. Dieser Befehl ist veraltet, denn er bietet nur eingeschränkte Informationen
Stattdessen wird meist der Befehl show ip pim rp mapping verwendet, er liefert einige Details über den aktuellen Inhalt der Gruppen-zu-RP-Mappings im Cache, wie folgendes:
- IP-Adressen eines Routers, der die Informationen verteilt oder lokal - wenn die Quelle der Informationen ein lokaler Router ist, der entweder eine manuelle RP-Konfiguration besitzt, oder eine Quelle einer automatisch verteilten Information ist.
- Mechanismus, mit dem die Informationen ermittelt werde - auto-RP, BSR oder statisch
- ob der Router ein Kanditat für RP, Mapping-Agent oder BSR ist
show ip rpf [IP]
Der Output dieses Befehls liefert RPF-Informationen in Verbindung mit den Quelladressen. Die spezifizierten Adressen müssen nicht zwangsläufig eine aktive Quelle sein. Es kann eine IP angegeben werden, auch die Adresse eines RPs. Das spezifizieren der IP des RPs ist sehr nützlich um die RPF-Informationen fpr den Shared Tree zu bestimmen.
"RPF interface" ist das Interface in Richtung Source (oder RP), während "RPF neighbor" die Adresse des next-hop-Routers in diese Richtung ist
"RPF-Type" weist auf die Quelle der Information. So weist zb. "unicast" darauf hin, dass die Information mittels einer Unicast-Routingtabelle zugestellt wurde, zb mit OSPF. Andere RPF-Typen inkludieren Distance Vector Multicast Routing Protokolle (DVMRP), Multiprotokcol Border Gateway Protocol (BGP)-Erweiterungen für IP oder staisch
RPF-Informationen sind unverzichtbar für Multicastrouting,
Überprüfen von IGMP-Gruppen und IGMP-Snooping
Überprüfen des Group-State
router# show ip igmp interface [type number]
zeigt die Multicast-Informationen zum zugehörigen Interface
router# show ip igmp groups [group-address type number]
zeigt die Multicastgruppen, die direkt am Router angeschlossen sind und vie IGMP gelernt wurden
Konfigurieren eines Routers, um ein Member einer Gruppe oder ein Static Connected Member zu sein
Manchmal ist entweder kein Gruppenmitglied in einem Netzwerksegment oder ein Host kann seine Gruppenmitgliedschaft mittels IGMP reporten. Trotzdem soll Multicasttraffic in dieses Segment gelangen. Diese Befehle werden oft in Lab-Umgebungen verwendet, in denen kein Multicast-Server konfiguriert ist. Das folgende sind zwei Arten, Multicasttraffic in ein Netzwerksegment zu bringen:
- ip igmp join-group [group-address]
- ip igmp static group [goup-address]
sh ip igmp interface
Dieser Befehl zeigt die Multicastgruppen, die direkt an den Router angeschlossen sind und via IGMP gelernt wurden. Mit diesem Befehl erhält man folgende Informationen:
- Interfacekonfiguration für Milticast und IGMP
- Version, für welche das IGMP-Interface konfiguriert wurde
- IGMPv2-Querier des Multiaccessnetzwerk
- Multicast Designated Router (DR)
- beigetretenen Multicastgruppen des jeweiligen Routers
Überprüfen von IGMP Snooping
switch> show multicast gruop [igmp] [mac-addr] [vlan_id]
- zeigt Informationen über Multicastgruppen
- wenn das Schlüsselwort igmp benutzt wird, werden nur IGMP-gelernte Informationen gezeigt
switch> show multicast router [igmo] [mod_num/port_num] [vlan_id]
- zeigt Informationen über dynamisch gelernte und manuell konfigurierte Routerports
- wenn das Schlüsselwort igmp benutzt wird, werden nur IGMP-gelernte Informationen gezeigt
switch> show igmp statistics 10
Dieser Befehl liefert Informationen über das Vlan 10. Es wird die Anzahl der Gruppenspezifischen Queries und der generellen Queries gezeigt, weiters die Anzahl der Hostmitgliedschaften und der Group-Leavingmessages
Der Output ist geteilt zwischen gesendet und empfangen
show multicast router igmp
zeigt Informationen über das IGMP Routerport und die VLAN-Konfiguration auf einem Switch
show multicast group igmp
dieses Kommando listet Informationen über VLAN, Multicastgruppen und Ports, die Multicastgruppen auf einem Switch beigetreten sind auf