Das PIM-Protokoll ist eine Sammlung von Protokollen zur Übertragung von Multicast in Netzwerken zwischen Routern. Die Nachbarschaftsbeziehungen werden ähnlich aufgebaut wie bei dynamischen Routing-Protokollen. PIMv2 sendet alle 30 Sekunden Hello-Nachrichten an die reservierte Multicast-Adresse 224.0.0.13 (All-PIM-Routers). Die Nachricht enthält Hold Timers, die normalerweise 3,5 * Hello Timer betragen, also standardmäßig 105 Sekunden.
PIM verwendet zwei Hauptbetriebsmodi – Dense und Sparse mode. Lassen Sie uns mit dem Dense mode beginnen.
Quellbasierte Verteilung Bäume.
Der Dense-Mode ist sinnvoll, wenn eine große Anzahl von Clients verschiedener Multicast-Gruppen vorhanden ist. Wenn der Router Multicast-Verkehr erhält, überprüft er zunächst die RPF-Regel. RPF – diese Regel wird verwendet, um die Quelle des Multicasts mit der Unicast-Routing-Tabelle zu überprüfen. Der Verkehr muss an das Interface kommen, hinter dem dieser Host gemäß der Unicast-Routing-Tabelle verborgen ist. Dieser Mechanismus löst das Problem von Schleifenbildung bei der Übertragung von Multicast.
R3 erfährt aus der Multicast-Nachricht die Multicast-Quelle (Source IP) und überprüft zwei Ströme von R1 und R2 anhand seiner Unicast-Routing-Tabelle. Der Strom von dem Interface, auf das die Tabelle verweist (R1 an R3), wird weitergeleitet, während der Strom von R2 verworfen wird, da die Pakete über S0/1 gesendet werden müssen, um die Multicast-Quelle zu erreichen.
Die Frage ist, was passiert, wenn Sie zwei äquivalente Wege mit der gleichen Metrik haben? In diesem Fall wählt der Router den nächster-Hop der angegebenen Routen aus. Derjenige mit der höheren IP-Adresse setzt sich durch. Wenn dieses Verhalten geändert werden soll, kann ECMP verwendet werden. Weitere Informationen. .
Nach Überprüfung der RPF-Regel sendet der Router das Multicast-Paket an alle seine PIM-Nachbarn, mit Ausnahme desjenigen, von dem das Paket empfangen wurde. Die anderen PIM-Router wiederholen diesen Prozess. Der Weg, den das Multicast-Paket von der Quelle zu den endgültigen Empfängern zurückgelegt hat, bildet einen Baum, der als quellbasierter Verteilungsbaum, kürzester Pfadbaum (SPT) oder Quellbaum bezeichnet wird. Drei verschiedene Namen, wählen Sie einen aus.
Wie geht man mit der Situation um, dass einige Router einen bestimmten Multicast-Strom nicht akzeptiert haben und ihm niemand senden kann, während ihn ein übergeordneter Router sendet? Dafür wurde der Prune-Mechanismus entwickelt.
Prune-Nachricht.
Zum Beispiel wird R2 weiterhin R3 Multicast senden, obwohl R3 gemäß der RPF-Regel das ignoriert. Warum die Bandbreite belasten? R3 sendet eine PIM Prune-Nachricht, und R2 entfernt bei Erhalt dieser Nachricht die Schnittstelle S0/1 aus der Liste der ausgehenden Schnittstellen für diesen Datenstrom, der Schnittstellenliste, von denen der Verkehr gesendet werden soll.
Die folgende Definition einer PIM Prune-Nachricht ist formeller:
Die PIM Prune-Nachricht wird von einem Router an einen zweiten Router gesendet, um den zweiten Router zu veranlassen, die Verbindung, über die das Prune empfangen wird, von einem bestimmten (S,G) SPT zu entfernen.
Nach Erhalt der Prune-Nachricht setzt R2 den Prune-Timer auf 3 Minuten. Nach drei Minuten wird er wieder mit dem Senden des Verkehrs beginnen, bis er eine weitere Prune-Nachricht erhält. Das gilt für PIMv1.
In PIMv2 wurde ein State Refresh-Timer hinzugefügt (standardmäßig 60 Sekunden). Sobald eine Prune-Nachricht von R3 gesendet wurde, wird der Timer auf R3 gestartet. Nach Ablauf dieses Timers wird R3 eine State Refresh-Nachricht senden, die den 3-minütigen Prune-Timer auf R2 für diese Gruppe zurücksetzt.
Gründe für das Senden einer Prune-Nachricht:
- Wenn ein Multicast-Paket die RPF-Prüfung nicht bestanden hat.
- Wenn es keine lokal angeschlossenen Clients gibt, die eine Multicast-Gruppe angefragt haben (IGMP Join), und keine PIM-Nachbarn vorhanden sind, an die Multicast-Verkehr gesendet werden kann (Non-prune Interface).
Graft-Nachricht.
Angenommen, R3 wollte keinen Verkehr von R2, hat Prune gesendet und erhielt Multicast von R1. Aber plötzlich fiel die Verbindung zwischen R1 und R3 aus, und R3 blieb ohne Multicast. Man kann 3 Minuten warten, bis R2 der Prune-Timer abläuft. 3 Minuten zu warten ist lang, um nicht warten zu müssen, sollte eine Nachricht gesendet werden, die sofort die Schnittstelle S0/1 auf R2 aus dem Pruned-Zustand holt. Diese Nachricht wäre die Graft-Nachricht. Nach Erhalt der Graft-Nachricht wird R2 als Antwort eine Graft-ACK senden.
Prune Override.
Lassen Sie uns dieses Diagramm betrachten. R1 sendet Multicast in ein Segment mit zwei Routern. R3 empfängt und sendet den Verkehr, R2 empfängt, hat jedoch keine Möglichkeit, den Verkehr weiterzusenden. Er sendet eine Prune-Nachricht an R1 in dieses Segment. R1 muss Fa0/0 aus der Liste entfernen und stoppen, in dieses Segment zu senden, aber was geschieht mit R3? Und R3 befindet sich im selben Segment, hat ebenfalls diese Prune-Nachricht erhalten und versteht die Tragik der Situation. Bevor R1 aufhört zu senden, setzt er einen Timer auf 3 Sekunden und wird nach 3 Sekunden aufhören zu senden. 3 Sekunden – genau so viel Zeit hat R3, um seinen Multicast nicht zu verlieren. Daher sendet R3 so schnell wie möglich eine Pim Join-Nachricht für diese Gruppe, und R1 denkt nicht mehr daran, das Senden zu stoppen. Infos zu Join-Nachrichten folgen unten.
Assert-Nachricht.
Stellen wir uns folgende Situation vor: In ein Netzwerk senden gleichzeitig zwei Router. Sie empfangen denselben Datenstrom von einer Quelle und beide senden ihn über das Interface e0 in dasselbe Netzwerk. Daher müssen sie bestimmen, wer der einzige Sender für dieses Netzwerk sein wird. Zu diesem Zweck werden Assert-Nachrichten verwendet. Wenn R2 und R3 die Duplizierung des Multicast-Verkehrs feststellen, d.h. auf R2 und R3 kommt ein Multicast an, den sie selbst senden, verstehen die Router, dass hier etwas nicht stimmt. In diesem Fall senden die Router Assert-Nachrichten, in denen die Administrative Distance und die Metrik der Route, über die die Quelle des Multicast erreicht wird – 10.1.1.10 – enthalten sind. Der Sieger wird wie folgt ermittelt:
- Derjenige mit der niedrigeren AD.
- Wenn die AD gleich sind, dann derjenige mit der niedrigeren Metrik.
- Wenn auch hier Gleichstand besteht, dann derjenige mit der höheren IP in dem Netzwerk, in das sie diesen Multicast senden.
Der Sieger dieser Wahl wird zum Designated Router. Für die Auswahl des DR werden ebenfalls Pim Hello-Nachrichten verwendet. Zu Beginn des Artikels wurde die PIM Hello-Nachricht gezeigt; dort kann das DR-Feld gesehen werden. Derjenige mit der höheren IP-Adresse auf diesem Link gewinnt.
Nützliche Tabelle:
MROUTE-Tabelle.
Nach der ersten Betrachtung der Funktionsweise des PIM-Protokolls müssen wir uns mit der Funktionsweise der Multicast-Routing-Tabelle vertraut machen. In der mroute-Tabelle wird information gespeichert, welche Datenströme von den Clients angefordert wurden und welche Ströme von den Multicast-Servern übertragen werden.
Zum Beispiel wird beim Erhalten eines IGMP Membership Reports oder einer PIM Join-Nachricht an einem bestimmten Interface ein Eintrag des Typs ( *, G ) in die Routing-Tabelle hinzugefügt:
Dieser Eintrag bedeutet, dass eine Anfrage für den Datenverkehr von der Adresse 238.38.38.38 empfangen wurde. Das DC-Flag bedeutet, dass das Multicast im Dense-Mode arbeitet, und das C bedeutet, dass der Empfänger direkt mit dem Router verbunden ist, d.h. der Router hat einen IGMP Membership Report erhalten und PIM Join.
Wenn es einen Eintrag vom Typ (S,G) gibt, bedeutet das, dass wir einen Multicast-Stream haben:
Im Feld S – 192.168.1.11 haben wir die IP-Adresse des Multicast-Quellgeräts angegeben. Diese wird durch die RPF-Regel überprüft. Bei Problemen sollte zuerst die Unicast-Tabelle auf einen Pfad zur Quelle überprüft werden. Im Feld Incoming Interface wird das Interface angegeben, über das der Multicast eintrifft. In der Unicast-Routing-Tabelle sollte der Pfad zur Quelle auf das hier angegebene Interface verweisen. Im Outgoing Interface wird angegeben, wohin der Multicast weitergeleitet wird. Wenn es leer ist, bedeutet dies, dass der Router keine Anfragen für diesen Datenverkehr erhalten hat. Weitere Informationen zu allen Flags finden Sie .
PIM Sparse-Mode.
Die Sparse-Mode-Strategie ist das Gegenteil des Dense-Modes. Wenn Sparse-Mode Multicast-Datenverkehr erhält, sendet es den Datenverkehr nur über die Interfaces, für die Anfragen für diesen Stream vorlagen, z.B. Pim Join oder IGMP Report-Nachrichten mit Anfragen für diesen Datenverkehr.
Ähnliche Elemente bei SM und DM:
- Nachbarschaftsbeziehungen werden ebenfalls wie im PIM DM aufgebaut.
- Die RPF-Regel funktioniert.
- Die Auswahl von DR ist ähnlich.
- Der Prune Overrides-Mechanismus und die Assert-Nachrichten sind ähnlich.
Um zu kontrollieren, wem, wo und welcher Multicast-Datenverkehr im Netzwerk benötigt wird, ist ein zentrales Informationszentrum erforderlich. Dieses Zentrum wird unser Rendezvous Point (RP) sein. Alle, die Multicast-Datenverkehr wünschen oder begonnen haben, Multicast-Datenverkehr von der Quelle zu erhalten, senden ihn an das RP.
Wenn das RP den Multicast-Datenverkehr erhält, sendet es ihn an die Router, die diesen Datenverkehr zuvor angefordert haben.
Stellen wir uns eine Topologie vor, in der das RP R3 ist. Sobald R1 den Datenverkehr von S1 erhält, kapselt es dieses Multicast-Paket in eine Unicast-PIM-Register-Nachricht ein und sendet es an das RP. Wie weiß es, wer das RP ist? In diesem Fall ist es statisch konfiguriert, und wir werden später über die dynamische Konfiguration des RPs sprechen.
ip pim rp-address 3.3.3.3
RP wird prüfen, ob es Informationen von jemandem gab, der diesen Traffic erhalten möchte. Angenommen, das war nicht der Fall. Dann wird RP R1 die Nachricht PIM Register-Stop senden, was bedeutet, dass dieser Multicast nicht benötigt wird und die Registrierung abgelehnt wurde. R1 wird keinen Multicast senden. Aber die Quelle des Multicasts wird ihn weiterhin senden, sodass R1 nach dem Erhalt von Register-Stop den Register-Suppression-Timer auf 60 Sekunden startet. Fünf Sekunden vor Ablauf dieses Timers wird R1 die leere Register-Nachricht mit dem Null-Register-Bit (d. h. ohne den gekapselten Multicast-Paket) in Richtung RP senden. RP wird daraufhin wie folgt handeln:
- Wenn es keine Empfänger gab, wird er mit einer Register-Stop-Nachricht antworten.
- Wenn Empfänger erscheinen, wird er nicht darauf reagieren. R1, das innerhalb von 5 Sekunden keine Ablehnung seiner Registrierung erhält, wird sich freuen und eine Register-Nachricht mit dem gekapselten Multicast an RP senden.
Wie der Multicast zu RP gelangt, haben wir anscheinend geklärt, nun versuchen wir zu beantworten, wie RP den Traffic zu den Empfängern weiterleitet. Hier müssen wir ein neues Konzept einführen — das Root-Path-Tree (RPT). RPT ist ein Baum mit der Wurzel in RP, der sich in Richtung der Empfänger erstreckt und sich an jedem PIM-SM-Router verzweigt. RP erstellt es, indem es PIM Join-Nachrichten empfängt und einen neuen Zweig zum Baum hinzufügt. So verfahren auch die nachgelagerten Router. Die allgemeine Regel lautet:
- Wenn ein PIM-SM-Router eine PIM Join-Nachricht an einem beliebigen Interface erhält, mit Ausnahme des Interfaces, das RP verbirgt, fügt er dem Baum einen neuen Zweig hinzu.
- Ein weiterer Zweig wird hinzugefügt, wenn der PIM-SM-Router einen IGMP Membership Report von einem direkt angeschlossenen Host erhält.
Stellen wir uns vor, ein Multicast-Client hat sich am Router R5 für die Gruppe 228.8.8.8 angemeldet. Sobald R5 den IGMP Membership Report von einem Host erhält, sendet R5 ein PIM Join in Richtung RP und fügt das Interface, das auf den Host zeigt, dem Baum hinzu. Dann erhält R4 ein PIM Join von R5, fügt das Interface Gi0/1 zum Baum hinzu und sendet ein PIM Join in Richtung RP. Schließlich erhält RP (R3) das PIM Join und fügt Gi0/0 zum Baum hinzu. So entsteht die Registrierung des Multicast-Empfängers. Wir bilden einen Baum mit der Wurzel R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Nach diesem Schritt wird ein PIM Join an R1 gesendet, und R1 beginnt, Multicast-Traffic zu versenden. Es ist wichtig zu beachten, dass, wenn der Host den Traffic angefordert hat, bevor das Multicast-Streaming beginnt, der RP keinen PIM Join senden und überhaupt nichts an R1 senden wird.
Falls während des Multicast-Versands der Host aufhört, den Traffic empfangen zu wollen, wird der RP, sobald er ein PIM Prune am Schnittstelle Gi0/0 erhält, sofort ein PIM Register-Stop direkt an R1 senden und danach die PIM Prune-Nachricht über die Schnittstelle Gi0/1. PIM Register-Stop wird unicast an die Adresse gesendet, von der das PIM Register kam.
Wie bereits zuvor erwähnt, wird, sobald der Router einen PIM Join zu einem anderen, beispielsweise R5 an R4, sendet, ein Eintrag auf R4 hinzugefügt:
Und ein Timer wird gestartet, dass R5 das PIM Join-Nachrichten ständig senden muss, sonst wird R4 es aus der Ausgabeliste ausschließen. R5 wird alle 60 PIM Join-Nachrichten senden.
Entscheidung des kürzesten Pfades.
Wir fügen eine Schnittstelle zwischen R1 und R5 hinzu und schauen, wie der Traffic bei dieser Topologie fließen wird.
Angenommen, der Traffic wurde nach dem alten Schema R1-R2-R3-R4-R5 gesendet und hier haben wir die Schnittstelle zwischen R1 und R5 angeschlossen und konfiguriert.
Zunächst wird die Unicast-Routing-Tabelle auf R5 neu aufgebaut und nun wird das Netzwerk 192.168.1.0/24 über die Schnittstelle R5 Gi0/2 erreicht. Nun erkennt R5, dass er Multicast über die Schnittstelle Gi0/1 erhält, dass die RPF-Regel nicht erfüllt ist und der Multicast logischerweise über Gi0/2 empfangen werden sollte. Er muss sich von RPT abmelden und einen kürzeren Baum aufbauen, der als Shortest-Path Tree (SPT) bekannt ist. Dazu sendet er über Gi0/2 einen PIM Join an R1, und R1 beginnt, auch über Gi0/2 Multicast zu senden. Nun muss sich R5 von RPT abmelden, um keine zwei Kopien zu empfangen. Dazu sendet er eine Prune-Nachricht, gibt die IP-Adresse des Quellgeräts an und fügt ein spezielles Bit ein – RPT-Bit. Das bedeutet, dass ich keinen Traffic empfangen möchte, ich habe hier einen besseren Baum. RP sendet auch PIM Prune-Nachrichten an R1, sendet jedoch keine Register-Stop-Nachricht. Eine weitere Besonderheit: R5 wird nun ständig PIM Prune an RP senden, da R1 weiterhin jede Minute PIM Register an RP sendet. RP wird, solange es keine neuen Anfragen für diesen Traffic gibt, mit einer Ablehnung antworten. R5 informiert RP, dass er weiterhin Multicast über SPT empfängt.
Dynamische RP-Suche.
Auto-RP.
Diese Technologie ist proprietär von Cisco und erfreut sich nicht besonders großer Beliebtheit, besteht jedoch weiterhin. Die Funktionsweise von Auto-RP besteht aus zwei Hauptschritten:
1) Der RP sendet RP-Announce-Nachrichten an die reservierte Adresse — 224.0.1.39, um sich entweder als RP für alle oder für bestimmte Gruppen zu deklarieren. Diese Nachricht wird jede Minute gesendet.
2) Ein RP-Mapping-Agent ist erforderlich, der RP-Discovery-Nachrichten sendet, mit der Angabe, für welche Gruppen welcher RP angehört werden soll. Aus dieser Nachricht werden die üblichen PIM-Router ihren RP ermitteln. Der Mapping-Agent kann entweder der RP-Router selbst oder ein separater PIM-Router sein. RP-Discovery wird an die Adresse 224.0.1.40 mit einem Timer von einer Minute gesendet.
Schauen wir uns den Prozess genauer an:
Konfigurieren wir R3 als RP:
ip pim send-rp-announce loopback 0 scope 10
R2 als Mapping-Agent:
ip pim send-rp-discovery loopback 0 scope 10
Und auf allen anderen werden wir auf den RP über Auto-RP warten:
ip pim autorp listener
Sobald wir R3 konfiguriert haben, wird er beginnen, RP-Announce zu senden:
Und R2 wird nach der Konfiguration als Mapping-Agent beginnen, die RP-Announce-Nachrichten zu erwarten. Nur wenn er mindestens einen RP findet, wird er anfangen, RP-Discovery zu senden:
So werden die üblichen Router (PIM RP Listener), sobald sie diese Nachrichten erhalten, wissen, wo sie nach dem RP suchen müssen.
Eines der Hauptprobleme von Auto-RP besteht darin, dass zur Erhaltung von RP-Announce- und RP-Discovery-Nachrichten PIM-Join an die Adressen 224.0.1.39-40 gesendet werden muss, und um zu senden, muss der RP bekannt sein. Ein klassisches Hühner-und-Ei-Problem. Um dieses Problem zu lösen, wurde der PIM Sparse-Dense-Modus erfunden. Wenn der Router den RP nicht kennt, arbeitet er im Dense-Modus, kennt er ihn, dann im Sparse-Modus. Wenn die Schnittstellen der üblichen Router auf PIM Sparse-Modus eingestellt sind und der Befehl ip pim autorp listener aktiv ist, wird der Router nur für den Multicast des Auto-RP-Protokolls (224.0.1.39-40) im Dense-Modus arbeiten.
BootStrap Router (BSR).
Diese Funktion funktioniert ähnlich wie Auto-RP. Jeder RP sendet eine Nachricht an den Mapping-Agenten, der die Mapping-Informationen sammelt und dann allen anderen Routern mitteilt. Beschreiben wir den Prozess ähnlich wie bei Auto-RP:
1) Sobald wir R3 als Kandidaten für einen RP konfiguriert haben, mit dem Befehl:
ip pim rp-candidate loopback 0
wird R3 nichts tun. Um spezielle Nachrichten zu senden, muss er zuerst den Mapping-Agenten finden. Daher gehen wir zum zweiten Schritt über.
2) Konfigurieren wir R2 als Mapping-Agent:
ip pim bsr-candidate loopback 0
R2 beginnt, PIM Bootstrap-Nachrichten zu versenden, in denen es sich selbst als Mapping-Agent anzeigt:
Diese Nachricht wird an die Adresse 224.0.0.13 gesendet, die das PIM-Protokoll auch für andere Nachrichten verwendet. Sie werden in alle Richtungen gesendet, sodass das Henne-und-Ei-Problem, wie es bei Auto-RP der Fall war, nicht besteht.
3) Sobald der RP eine Nachricht vom BSR-Router erhält, sendet er sofort eine Unicast-Nachricht an die Adresse des BSR-Routers:
Danach wird der BSR, nachdem er die Informationen über den RP erhalten hat, diese multicast an die Adresse 224.0.0.13 verbreiten, die alle PIM-Router abhören. Daher gibt es keinen analogen Befehl ip pim autorp listener für normale Router in BSR.
Anycast RP mit Multicast Source Discovery Protocol (MSDP).
Auto-RP und BSR ermöglichen es uns, die Last auf den RP wie folgt zu verteilen: Jede Multicast-Gruppe hat nur einen aktiven RP. Es ist nicht möglich, die Last für eine Multicast-Gruppe auf mehrere RPs zu verteilen. MSDP erledigt dies, indem es RPs dieselbe IP-Adresse mit der Maske 255.255.255.255 zuweist. MSDP erfährt die Informationen durch eine der Methoden: statisch, Auto-RP oder BSR.
In der Abbildung haben wir eine Auto-RP-Konfiguration mit MSDP. Beide RPs sind mit der IP-Adresse 172.16.1.1/32 auf dem Loopback1-Interface konfiguriert und werden für alle Gruppen verwendet. Bei RP-Announce berichten beide Router über sich und beziehen sich auf diese Adresse. Der Auto-RP-Mapping-Agent sendet, nachdem er die Informationen erhalten hat, RP-Discovery über den RP mit der Adresse 172.16.1.1/32 aus. Über das Netzwerk 172.16.1.1/32 informieren wir die Router über IGP und entsprechend. So fordern PIM-Router Streams vom RP an oder registrieren sich bei dem RP, der als nächster Sprung für die Route zum Netzwerk 172.16.1.1/32 angegeben ist. Das MSDP-Protokoll selbst ist dafür gedacht, dass die RPs Informationen über Multicast austauschen.
Betrachten wir eine solche Topologie:
Switch6 sendet Daten an die Adresse 238.38.38.38 und bisher weiß nur RP-R1 davon. Nun haben Switch7 und Switch8 diese Gruppe angefordert. Die Router R5 und R4 werden PIM Join an R1 bzw. R3 senden. Warum? Die Route zu 13.13.13.13 wird bei R5 auf R1 mit IGP-Metrik verweisen, ebenso wie bei R4.
RP-R1 kennt den Stream und wird ihn in Richtung R5 verbreiten, während R4 nichts darüber weiß, da R1 ihn nicht einfach so senden wird. Daher ist MSDP erforderlich. Wir konfigurieren es an R1 und R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 an R1
ip msdp peer 1.1.1.1 connect-source Loopback3 an R3
Sie werden eine Sitzung miteinander aufbauen und beim Erhalt eines Streams ihrem benachbarten RP darüber berichten.
RP-R1 wird, sobald er einen Stream von Switch6 erhält, sofort eine MSDP Source-Active-Nachricht per Unicast senden, die Informationen vom Typ (S, G) enthält – Informationen über die Quelle und das Ziel des Multicast. Jetzt, da RP-R3 weiß, dass eine Quelle wie Switch6 vorhanden ist, wird er bei Erhalt einer Anfrage von R4 für diesen Stream PIM Join in Richtung Switch6 senden, basierend auf der Routingtabelle. Folglich wird R1, der diesen PIM Join erhält, beginnen, den Verkehr in Richtung RP-R3 zu senden.
MSDP funktioniert über TCP, RP senden sich gegenseitig Keepalive-Nachrichten zur Überprüfung der Lebensfähigkeit. Der Timer beträgt 60 Sekunden.
Die Funktion der Trennung von MSDP-Peers in verschiedene Domänen bleibt unklar, da in den Keepalive- und SA-Nachrichten keine Zuordnung zu einer Domäne angegeben wird. In dieser Topologie wurde auch eine Konfiguration getestet, die verschiedene Domänen angibt – es gab keinen Unterschied im Betrieb.
Wenn jemand Klarheit schaffen kann, lese ich gerne in den Kommentaren mit.
Quelle: habr.com
