15/11/2016

Cisco – IGMP v2

Membership Queries: Das ist die (regelmaessige) Anfrage vom Router ins LAN mit der Bitte um Info WER diesen Traffic empfangen will.
Membership Report: Das ist die Info vom Client die aussagt, dass er (oder das LAN) diesen Traffic will (JOIN) – keine Ahnung warum man das als Report bezeichnet… Vielleicht weil sie reporten dass sie den Traffic wollen. Als Non Native Speaker finde ich die Uebersetzung trotzdem unlogisch.

Membership Queries werden an 224.0.0.1 (ALL HOSTS address) gesendet mit einer TTL von 1 und normal macht das nur ein Router im LAN (jede Minute).
Membership Reports werden vom Client gesendet und wenn die anderen Clients das mitbekommen (was so sein soll), dann schicken andere Clients keinen Membership Report mehr – sprich ein Report pro Multicast Gruppe und LAN (ausgenommen wenn ein Client zum ersten Mal joinen will, dann schickt er den Report auf jeden Fall, egal ob dies in seinem LAN schon passiert ist).

Der Mechanismus, dass nur einer Router Queries schickt und nur ein Client Reports schickt ist eine Optimierung, da es nicht bringen wuerde, wenn mehrere Router im selben LAN permanent die Clients mit Anfragen nerven, ob sie diesen Traffic noch wollen, daher wird ein Router als Querier gewaehlt – in der Regel der Multicast Router mit der niedrigsten IP Adresse (faellt dieser aus uebernimmt natuerlich ein anderer Router).

Wenn ein Client den Mutlicast Stream nicht mehr will, dann sendet er ein LEAVE and 224.0.0.2 (ALL ROUTERS). Sollte es im selben LAN fuer diese Gruppe noch andere Interessenten geben, dann schicken die einen Report, damit der Stream weiterlaeuft. Gibt es wirklich keinen mehr, dann wird der Traffic auch nicht mehr geschickt (time out). Bekommt der Router kein LEAVE, aber auch keine Antwort mehr auf seine Queries, dann kommt es ebenfalls zu einem Time out und der Traffic wird (danach) nicht mehr gesendet.

 

Ein paar nuetzliche Commands:
 sh ip igmp interface
 sh ip igmp group
 sh ip igmp group detail

 

 

Das Ganze nochmal in Bildern:


Die Topolgoie. Es laeuft IPv4, OSPFv2 und PIM sparse-mode. R3 ist RP. Ausserdem sieht man links oben einen Multicast Sender (VLC) und rechts unten einen Multicast Empfaenger bzw einer der das Video sehen will (ebenfalls VLC).
 

 

Der Multicast Sender sendet das Video. Er gibt es aber lokal nicht aus (gewollt).
 

 

Und der Multicast Empfaenger kann es erfolgreich empfangen und ansehen.
 

 

Wie weiter oben im Text erwaehnt sehen wir dass R5 regelmaessig von seiner eigenen Unicast IPv4 Adresse in das LAN des Empfaengers (192.168.100.0/24) bzw auf eben diesem Interface an die Adresse 224.0.0.1 und fragt ob noch jemand den Stream sehen will (QUERY).
 

 

Unmittelbar danach sendet der Client von seiner normalen Unicast IPv4 Adresse einen REPORT an die Multicast Adresse der Gruppe und signalisiert somit, dass er den Stream weiterhin sehen will.
 

 

Das sehen wir auf R5.
 

 

Wenn wir VLC nun auf dem Multicast Client beenden sehen wir, dass vom Client ein LEAVE an R5 geschickt wird.
 

 

R5 schickt daraufhin fuer die Gruppe fuer welche er das LEAVE erhalten hat nochmal ein Query mit einer Max Response Time von 1 Sekunde und pruned, falls er nix mehr hoert.