OSPF und seine Verwendung von Multicast

Wenn es um OSPF und die Verwendung von Multicast geht, bin ich zu Recht der Ansicht, dass IGMP-Weiterleitung und ein IGMP-Abfrager im lokalen Segment weiterhin erforderlich sind?

Mein Verständnis wäre ohne dies, die Frames würden als Sendung behandelt und an alle gesendet. Entfernen Sie daher den Vorteil der Verwendung von Multicast.

Auf dieser Grundlage gibt es einen Mechanismus, mit dem auf Unicast zurückgegriffen werden kann, um das oben Genannte zu verhindern. Entschuldigung, wenn mein Verständnis hier weit entfernt ist :)

In Bezug auf das, was mit OSPF-Hallo / Discovery-Multicast-Paketen passiert, haben Sie Recht. Die Switches senden sie an alle Mitglieder der Subnetz- / VLAN- / Broadcast-Domäne, da IGMP für 224.0.0.0/24 nicht ausgeführt wird, wie Ron erklärt hat.

Allerdings - und ich glaube, das ist der Teil, den Sie nicht in Betracht gezogen haben - kann ein Host diese Multicasts immer noch früher verwerfen, als wenn sie gesendet würden. Wenn der Host nicht an (einer / dieser) Multicast-Gruppe (n) interessiert ist, kann er den Ethernet-Frame (bei L2) oder das IPv4 / IPv6-Paket (bei L3) löschen, ohne auch nur die innere Nutzlast zu betrachten. Ein Broadcast-Paket müsste jedoch "weiter oben im Stapel" weitergeleitet werden, um festzustellen, ob es für eine der laufenden Anwendungen / Dienste / Deamons von Interesse ist.

So fügen Sie Rons Liste der OSPF-Netzwerktypen / Betriebsmodi hinzu:

Es wird empfohlen, Edge-Netzwerke mit passiven Schnittstellen zu betreiben, die mit OSPF-Routern verbunden sind , insbesondere wenn der OSPF-Netzwerktyp von Natur aus "Broadcast" ist. Dies ist beispielsweise bei den sprichwörtlichen "25 Client-VLANs" eines großen Campus der Fall, von denen jeder mindestens ein paar Dutzend Hosts enthält:

passive Schnittstelle

• hält das Geschwätz im Campus-LAN niedrig
• Reduziert die Exposition von Routern gegenüber Endsystemen (skriptfreudige CompSci-Studenten, irgendjemand?) - es werden weder Hellos noch LSAs ausgetauscht, weder rein noch raus.
• spart einige Ressourcen auf den Routern (was passiert, wenn in Dutzenden von VLANs nicht dieselbe DR / BDR-Wahl mit demselben Peer durchgeführt werden muss)
• Ermöglicht weiterhin die Weitergabe der Routing-Informationen zu diesen Netzwerken als interne Routen an den Rest des OSPF AS. Wenn sie als externe Routen (aufgrund von "verbundener Neuverteilung") verwendet werden, hat dies einige Auswirkungen (wünschenswert oder unerwünscht), z. B. beim Aggregieren, Umverteilen oder Filtern von Routen in anderen Ecken des AS.

Der Vorteil von Multicast besteht darin, dass Hosts, die die Multicast-Gruppe nicht abonnieren, Frames ignorieren, die sie an die Multicast-Gruppe senden. Bei Broadcast können sie die Frames nicht ignorieren.

Die OSPF-Multicast-Gruppe ist ein verbindungslokaler Multicast, der an jede Switch-Schnittstelle gesendet wird, auch wenn IGMP-Snooping auf dem Switch aktiviert ist. OSPF verwendet Multicast nur in Broadcast-Netzwerken, und es ist erforderlich, um DR und BDR zu verwenden, die sich nur in Broadcast-Netzwerken befinden. Für Punkt-zu-Punkt-Verbindungen verwendet OSPF Unicast, und für Nicht-Broadcast-Netzwerke verwenden Sie die neighborAnweisung und Unicast.

OSPF-Multicast verwendet die Adressen 224.0.0.5und 224.0.0.6, die sich im verbindungslokalen Adressbereich befinden. Switches mit IGMP-Snooping sollen alle verbindungslokalen Multicasts an jede Schnittstelle weiterleiten, unabhängig vom IGMP-Snooping. Dieses Verhalten ist in RFC 4541, Überlegungen zu IGMP- (Internet Group Management Protocol) und MLD-Snooping-Switches (Multicast Listener Discovery) definiert :

2. Pakete mit einer Ziel-IP-Adresse (DIP) im Bereich 224.0.0.X, die nicht IGMP sind, müssen an allen Ports weitergeleitet werden.

   Diese Empfehlung basiert auf der Tatsache, dass viele Hostsysteme keine Join-IP-Multicast-Adressen in diesem Bereich senden, bevor IP-Multicast-Pakete gesendet oder abgehört werden. Da der Adressbereich 224.0.0.X als verbindungslokal definiert ist (nicht weiterzuleiten), erscheint es außerdem unnötig, den Status für jede Adresse in diesem Bereich beizubehalten. Darüber hinaus arbeiten einige Router im Adressbereich 224.0.0.X, ohne IGMP-Joins auszugeben, und diese Anwendungen würden unterbrochen, wenn der Switch sie bereinigen würde, da vom Router keine Join-Gruppennachricht angezeigt wurde.

Wenn es um OSPF und die Verwendung von Multicast geht, bin ich zu Recht der Ansicht, dass IGMP-Weiterleitung und ein IGMP-Abfrager im lokalen Segment weiterhin erforderlich sind?

OSPF verwendet Multicast für eine verbindungslokale Bereichsgruppe, wobei IP-TTL auf 1 gesetzt ist, um sicherzustellen, dass verbindungslokal angegeben ist. [224.0.0.5 und 224.0.0.6 ( RFC2328, S. 185-186 )]

Abgesehen von OSPF, damit die Multicast-Bereinigungsfunktionen von Switches funktionieren, muss etwas Gruppenmitgliedschaftsberichte verursachen. Alle IGMP-Beitritte (unaufgeforderter Mitgliedschaftsbericht) laufen schließlich ab ( RFC 2236 IGMP v2, S.18 ). Wenn der Switch keine regelmäßigen Berichte anzeigt (z. B. IGMP-Snooping von Mitgliedschaftsberichten), wird diese Multicast-Gruppe möglicherweise beschnitten oder an alle Ports übertragen. (abhängig davon, wie Ihr Switch konfiguriert ist)