fragen stichworte

Warum sollten IGMP und MLD nicht registrierte Pakete an alle Ports weiterleiten?

Zunächst ein kleiner Hintergrund: Mein Verständnis ist, dass der Zweck von IGMP (und dessen IPv6-Cousin, MLD) darin besteht, verschwendete Bandbreite zu vermeiden, indem sichergestellt wird, dass Multicast-Pakete nur an Ziele gesendet werden, die tatsächlich an diesen Paketen interessiert sind. Diese Logik ist eine Verfeinerung eines älteren/einfacheren Switch-Verhaltens, bei dem eingehende Multicast-Pakete auf alle anderen Ports übertragen werden sollten und es den angeschlossenen Geräten überlassen sollte, Multicast-Pakete zu verwerfen, an denen sie nicht interessiert waren.

IGMP und MLD tun dies, indem der Switch eine Tabelle führt, in der nachverfolgt wird, welche verbundenen Geräte derzeit mit welchen Multicast-Gruppen verbunden sind. Wenn ein Multicast-Paket eingeht, leitet der Switch dieses nur an die Ports weiter, die der Gruppe angehören angegeben durch die Zieladresse des Pakets. So weit, ist es gut.

Laut meinem Kollegen gibt es jedoch einen Sonderfall: Wenn keine -Geräte einer bestimmten Multicast-Gruppe beigetreten sind, muss der Switch alle ankommenden Multicast-Pakete an alle Ports weiterleiten (naja, technisch gesehen an allen Ports mit angeschlossenem IGMP-Router, aber er sagt, dass es sich um dasselbe handelt, da die meisten Switches nicht wissen, welche Ports einen IGMP-Router angeschlossen haben und daher auf alle überfluten werden Häfen).

Dies scheint mir sehr uninteressant zu sein - warum sollte ein Algorithmus, dessen vollständiger Zweck darin besteht, zu vermeiden, dass Multicast-Überschwemmungen absichtlich alle Ports überschwemmen, in einem Szenario, an dem niemand interessiert ist beim Empfang der Multicast-Daten? Wird dies getan, um die Abwärtskompatibilität mit fehlerhaften Multicast-Implementierungen sicherzustellen, von denen erwartet wird, dass sie nie angeforderte Multicast-Pakete erhalten? Wenn nein, was ist die Motivation dafür? Es scheint, als würde dies den Nutzen des Algorithmus erheblich verringern.

Die Richtlinien, auf die mein Mitarbeiter verweist, sind in Abschnitt 2.1.2 von RFC 4541:

zu finden
3) An unregistered packet is defined as an IPv4 multicast packet with
   a destination address which does not match any of the groups
   announced in earlier IGMP Membership Reports.

  If a switch receives an unregistered packet, it must forward that
  packet on all ports to which an IGMP router is attached.  A switch
  may default to forwarding unregistered packets on all ports.
  Switches that do not forward unregistered packets to all ports
  must include a configuration option to force the flooding of
  unregistered packets on specified ports.

Ich denke, der folgende Absatz kann die Motivation erklären, aber ich verstehe das nicht:

In an environment where IGMPv3 hosts are mixed with snooping
switches that do not yet support IGMPv3, the switch's failure to
flood unregistered streams could prevent v3 hosts from receiving
their traffic.  Alternatively, in environments where the snooping
switch supports all of the IGMP versions that are present,
flooding unregistered streams may cause IGMP hosts to be
overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports for
their own groups.

Das heißt, warum verhindert ein Fluten nicht registrierter Streams, dass v3-Hosts ihren Datenverkehr empfangen? (Würden nicht v3-Hosts wissen, dass sie sich einer Gruppe anschließen möchten, in der sie Datenverkehr empfangen möchten?) Und im alternativen Szenario wäre ein Verkehrsverlust aufgrund von Überflutung nicht genauso ein Problem wie ein Verkehrsverlust durch Überschwemmungen?

antworten

Das Problem ist im Besprechungsbericht beschrieben, auf den in RFC4541 als [IETF56] verwiesen wird:

Problem - Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host

Router sends IGMPv3 query, which tells the host to use IGMPv3 Hosts send IGMPv3 reports

What then happens ?

Switch does one of these 3 :

  1. Doesn’t forward reports
  2. Forwards reports but does not forward data
  3. Forwards reports and data but no queries, data then times out

Result - Multicast breaks when you upgrade a router or host (whichever is last) to IGMPv3.

Das Fluten nicht registrierter Streams funktioniert im Fall 1 um das Problem (wenn der alte Switch IGMPv3-Berichte nicht weiterleitet) und sollte keinen Unterschied in den Fällen 2 und 3 machen (wenn IGMPv3-Berichte über den alten Switch laufen).

Was für ein Problem (Verkehrsabfall oder übermäßige Überschwemmung) schlimmer ist, hängt stark von einer bestimmten Situation ab. In einigen Fällen kann das Überfluten schlimmer sein, da es im Gegensatz zum fallen gelassenen Verkehr nicht sofort während des Tests bemerkt wird und wenn das Verkehrsvolumen zu einem späteren Zeitpunkt so stark ansteigt, dass Überflutung ein Problem darstellt, kann die zerbrochene Konfiguration weit verbreitet sein und viel benötigen der Arbeit, um es zu beheben.

First, a little background: My understanding is that the purpose of IGMP (and its IPv6 cousin, MLD) is to avoid wasted bandwidth by ensuring that multicast packets only get transmitted to destinations that are actually interested in those packets. This logic is a refinement of an older/simpler switch behavior, which was to broadcast incoming multicast packets to all other ports no matter what, and leave it up to the connected devices to drop multicast packets that they weren't interested in.

Nein. IGMP/MLD hat zum Ziel, dass Router wissen, welcher Multicast-Gruppe ein lokal angeschlossener Host beigetreten ist (es ist ihnen auch egal, zu welchem ​​Host), da zu diesem Zeitpunkt gemeinsam genutzte Medien erwartet wurden. Der Router leitet diese Informationen dann an einen Multicast-Routing-Algorithmus weiter, der diese Informationen über Router austauscht, um Multicast-Routing-Tabellen zu erstellen. Auf diese Weise kann eine an einen Router A angeschlossene Maschine X Multicast-Verkehr an die Gruppe G senden, und eine an einen anderen Router B angeschlossene Maschine Y empfängt ihn, wenn sie sich G angeschlossen hat.

IGMP wurde erfunden, bevor Switches existierten, und erwartete, dass die Medien zwischen Hosts und Routern gemeinsam genutzt werden. IGMP wurde sogar für gemeinsam genutzte Medien optimiert, da für den Fall, dass viele Hosts an derselben Gruppe interessiert waren, Optimierungen vorgenommen wurden, indem nur ein Host den Mitgliedschaftsbericht nur einmal senden ließ (da alle Hosts ohnehin Datenverkehr von dieser Multicast-Gruppe erhalten würden).

This seems very counterintuitive to me -- why would an algorithm whose entire purpose is to avoid multicast flooding deliberately flood to all ports in the a scenario where nobody is interested in receiving the multicast data?

IGMP/MLD-Router sind immer an Multicast-Daten interessiert. Es ist ihre Aufgabe, sie trotzdem weiterzuleiten. Wenn ein Host Multicast-Daten an die Gruppe X sendet, muss der Router das Paket an alle anderen Router weiterleiten, bei denen mindestens ein Host der Gruppe X beigetreten ist. Der Switch ist sich dieser Situation nicht bewusst, wenn er also keinen unbekannten Datenverkehr vom Host weiterleitet zum Router würde es nur das Multicast-Routing unterbrechen.

Für die Weiterleitung unregistrierter Pakete an alle Ports kann es technische Gründe geben. Ich persönlich halte Switches jedoch für eine Optimierung im Vergleich zu Hubs. Ich möchte, dass sie in ihrer Standardkonfiguration Dinge optimieren, ohne sie zu beschädigen. Wenn der Switch unzulässige oder unerwartete Pakete erhält, möchte ich, dass er sie trotzdem weiterleitet, da das Paket wahrscheinlich aus einem bestimmten Grund gesendet wurde. Das Letzte, was ich möchte, ist, dass mein Switch Pakete löscht.

Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host

Hier denke ich, Standard erklärt,

Das nicht registrierte Igmpv3-Paket wird an den Snooping-Switch (IGMPv2) gesendet. Es sollte das Igmp-Paket nicht erkennen und dann das Igmp-Paket zurückschalten, dann fließt das Igmpv3-Multicast-Paket nicht zum Igmpv3-Host.