Das PIM-Protokoll ist eine Gruppe von Protokollen zur Übertragung von Multicast im Netzwerk zwischen Routern. Die Nachbarschaftsbeziehungen werden ähnlich wie bei dynamischen Routing-Protokollen aufgebaut. 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-mal so lange wie der Hello Timer sind, also standardmäßig 105 Sekunden.
PIM verwendet zwei Hauptarbeitsmodi: Dense und Sparse mode. Beginnen wir mit dem Dense mode.
Source-Based Distribution Trees.
Der Dense-Mode ist sinnvoll, wenn es viele Clients in verschiedenen Multicast-Gruppen gibt. Wenn ein Router Multicast-Verkehr empfängt, prüft er zunächst das RPF-Regelwerk. RPF — diese Regel wird verwendet, um die Quelle des Multicasts mit der Unicast-Routing-Tabelle zu überprüfen. Der Verkehr muss an dem Interface ankommen, 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 Quelle des Multicasts (Source IP) und überprüft zwei Streams von R1 und R2 anhand seiner Unicast-Tabelle. Der Stream von dem Interface, auf das die Tabelle verweist (R1 zu R3), wird weitergeleitet, während der Stream von R2 verworfen wird, da zur Erreichung der Multicast-Quelle Pakete über S0/1 gesendet werden müssen.
Die Frage ist, was passiert, wenn Sie zwei äquivalente Routen mit derselben Metrik haben? In diesem Fall wählt der Router basierend auf dem Next-Hop dieser Routen. Der Router mit der höheren IP-Adresse gewinnt. Wenn dieses Verhalten geändert werden soll, kann ECMP verwendet werden. Mehr erfahren .
Nachdem die RPF-Regel überprüft wurde, sendet der Router das Multicast-Paket an alle seine PIM-Nachbarn, mit Ausnahme desjenigen, von dem das Paket empfangen wurde. Die übrigen PIM-Router wiederholen diesen Prozess. Der Pfad, den das Multicast-Paket von der Quelle zu den endgültigen Empfängern durchlaufen hat, bildet einen Baum, der als source-based distribution tree, shortest-path tree (SPT) oder source tree bezeichnet wird. Drei verschiedene Namen, wählen Sie beliebigen aus.
Wie man das Problem löst, dass einigen Routern ein bestimmter Multicast-Stream nicht gelungen ist und es niemanden gibt, an den er gesendet werden kann, während der übergeordnete Router ihn weiterhin sendet. Zu diesem Zweck wurde der Prune-Mechanismus entwickelt.
Prune-Nachricht.
Zum Beispiel wird R2 weiterhin Multicast an R3 senden, obwohl R3 ihn laut der RPF-Regel verwirft. Warum den Kanal belasten? R3 sendet eine PIM Prune-Nachricht, und R2 entfernt, beim Empfang dieser Nachricht, das Interface S0/1 aus der Liste (Outgoing Interface List) für diesen Stream, also aus der Liste der Interfaces, von denen der Traffic 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, aus einem bestimmten (S,G) SPT zu entfernen.
Nach dem Empfang der Prune-Nachricht stellt R2 den Prune-Timer auf 3 Minuten ein. Nach drei Minuten beginnt er wieder, Traffic zu senden, bis er eine weitere Prune-Nachricht erhält. Dies gilt für PIMv1.
In PIMv2 wurde der State Refresh-Timer hinzugefügt (standardmäßig 60 Sekunden). Sobald eine Prune-Nachricht von R3 gesendet wurde, wird dieser 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 Versenden einer Prune-Nachricht:
- Wenn ein Multicast-Paket die RPF-Prüfung nicht bestanden hat.
- Wenn keine lokal verbundenen Clients vorhanden sind, die eine Multicast-Gruppe (IGMP Join) angefordert haben, und es keine PIM-Nachbarn gibt, an die Multicast-Verkehr (Non-prune Interface) gesendet werden kann.
Graft-Nachricht.
Angenommen, R3 wollte keinen Verkehr von R2 und hat ein Prune gesendet, während es Multicast von R1 empfangen hat. Plötzlich fiel die Verbindung zwischen R1 und R3, sodass R3 ohne Multicast blieb. Man könnte 3 Minuten warten, bis der Prune-Timer auf R2 abläuft. 3 Minuten sind lang, um nicht warten zu müssen, sollte eine Nachricht gesendet werden, die diesen S0/1-Port auf R2 sofort aus dem pruned Zustand holt. Diese Nachricht wäre eine Graft-Nachricht. Nach Erhalt der Graft-Nachricht sendet R2 im Gegenzug eine Graft-ACK.
Prune-Override.
Werfen wir einen Blick auf dieses Schema. R1 sendet Multicast in ein Segment mit zwei Routern. R3 empfängt und sendet den Datenverkehr, R2 empfängt, hat aber niemanden, an den er den Verkehr senden kann. Er sendet eine Prune-Nachricht an R1 in dieses Segment. R1 muss Fa0/0 aus der Liste entfernen und aufhören, in dieses Segment zu senden, aber was passiert mit R3? R3 befindet sich im selben Segment, hat ebenfalls diese Prune-Nachricht erhalten und versteht die Tragik der Situation. Bevor R1 aufhört zu senden, stellt er einen Timer auf 3 Sekunden ein und wird in 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 daran, das Senden einzustellen. Zu den Join-Nachrichten unten.
Assert-Nachricht.
Stellen Sie sich folgendes Szenario vor: In dasselbe Netzwerk senden zwei Router gleichzeitig. Sie empfangen denselben Datenstrom von einer Quelle und beide übertragen diesen über das Interface e0 in ein und dasselbe Netzwerk. Daher müssen sie bestimmen, welcher von ihnen der einzige Sender für dieses Netzwerk sein wird. Hierfür kommen Assert-Nachrichten zum Einsatz. Wenn R2 und R3 eine Duplikation des Multicast-Traffics erkennen, d.h. sowohl R2 als auch R3 empfangen den Multicast, den sie selbst übertragen, verstehen die Router, dass etwas nicht stimmt. In diesem Fall senden die Router Assert-Nachrichten, die die Administrative Distance und die Metrik der Route enthalten, über die der Multicast-Quell erreicht wird – 10.1.1.10. Der Gewinner wird folgendermaßen bestimmt:
- Derjenige mit der niedrigeren AD.
- Wenn die AD gleich sind, dann derjenige mit der niedrigeren Metrik.
- Wenn auch hier Gleichstand herrscht, entscheidet derjenige mit der höheren IP-Adresse im Netzwerk, in das sie diesen Multicast senden.
Der Siegertyp in dieser Abstimmung wird der Designated Router. Auch zur Auswahl des DR werden Pim Hello-Nachrichten verwendet. Zu Beginn des Artikels wurde eine PIM Hello-Nachricht gezeigt, in der das DR-Feld zu erkennen ist. Derjenige mit der höheren IP-Adresse auf diesem Link gewinnt.
Nützliche Tabelle:
MROUTE-Tabelle.
Nach der ersten Überprüfung der Funktionsweise des PIM-Protokolls müssen wir klären, wie wir mit der Multicast-Routing-Tabelle umgehen. In der mroute-Tabelle werden Informationen gespeichert, welche Streams von den Clients angefordert wurden und welche Streams von den Multicast-Servern fließen.
Zum Beispiel wird beim Erhalt eines IGMP Membership Reports oder eines PIM Join auf einem bestimmten Interface ein Eintrag des Typs (*, G) zur Routing-Tabelle hinzugefügt:
Dieser Eintrag bedeutet, dass eine Anfrage für den Traffic mit der Adresse 238.38.38.38 empfangen wurde. Das DC-Flag zeigt an, dass Multicast im Dense Mode betrieben wird, und das C bedeutet, dass der Empfänger direkt mit dem Router verbunden ist, d.h. der Router hat den IGMP Membership Report und das PIM Join erhalten.
Wenn es einen Eintrag des Typs (S,G) gibt, bedeutet das, dass wir einen Multicast-Stream haben:
Im Feld S — 192.168.1.11 geben wir die IP-Adresse des Multicast-Quells an, die Regel RPF wird an dieser Adresse überprüft. Bei Problemen sollten Sie zuerst die Unicast-Tabelle auf eine Route zur Quelle überprüfen. Im Feld Incoming Interface geben Sie das Interface an, über das der Multicast empfangen wird. In der Unicast-Routing-Tabelle sollte die Route zur Quelle auf das hier angegebene Interface verweisen. Im Feld Outgoing Interface wird angegeben, wohin der Multicast weitergeleitet wird. Wenn es leer ist, bedeutet dies, dass keine Anfragen für diesen Datenverkehr an den Router gesendet wurden. Weitere Informationen zu allen Flags finden Sie. .
PIM Sparse-mode.
Die Sparse-mode-Strategie ist das Gegenteil des Dense-mode. Wenn der Sparse-mode Multicast-Datenverkehr empfängt, wird der Datenverkehr nur über die Interfaces gesendet, an denen Anfragen für diesen Datenstrom vorhanden sind, z. B. Pim Join oder IGMP Report-Nachrichten mit Anfragen für diesen Datenverkehr.
Ähnliche Elemente in SM und DM:
- Nachbarschaftsbeziehungen werden genauso aufgebaut wie im PIM DM.
- Die RPF-Regel funktioniert.
- Die Auswahl des DR ist ähnlich.
- Der Mechanismus Prune Overrides und die Assert-Nachrichten sind ähnlich.
Um zu kontrollieren, wer, wo und welchen Multicast-Verkehr im Netzwerk benötigt, ist ein zentrales Informationszentrum erforderlich. Dieses Zentrum wird unser Rendezvous Point (RP) sein. Alle, die einen Multicast-Verkehr anfordern oder von einer Quelle empfangen wollen, senden diesen an das RP.
Sobald das RP den Multicast-Verkehr erhält, leitet es diesen an die Router weiter, die zuvor nach diesem Verkehr gefragt haben.
Stellen wir uns eine Topologie vor, in der RP R3 ist. Sobald R1 Verkehr von S1 empfängt, kapselt es dieses Multicast-Paket in eine Unicast-PIM-Register-Nachricht ein und sendet es an das RP. Wie weiß es, wo das RP ist? In diesem Fall ist es statisch konfiguriert, und wir werden später über die dynamische Konfiguration des RP sprechen.
ip pim rp-address 3.3.3.3
RP wird prüfen – gab es Informationen von jemandem, der diesen Traffic erhalten möchte? Nehmen wir an, das gab es nicht. Dann wird RP R1 eine Nachricht PIM Register-Stop senden, was bedeutet – niemand benötigt diesen Multicast, die Registrierung ist abgelehnt. R1 wird den Multicast nicht senden. Aber die Host-Quelle des Multicast wird ihn weiter senden, sodass R1 nach Erhalt von Register-Stop einen Register-Suppression-Timer von 60 Sekunden startet. Fünf Sekunden vor Ablauf dieses Timers wird R1 eine leere Register-Nachricht mit dem Null-Register-Bit (also ohne inkapsuliertes Multicast-Paket) in Richtung RP senden. RP wird in der Folge so agieren:
- Wenn es keine Empfänger gegeben hat und immer noch keine gibt, wird er mit einer Register-Stop-Nachricht antworten.
- Wenn Empfänger erschienen sind, wird er nicht darauf reagieren. R1, der innerhalb von fünf Sekunden keine Ablehnung seiner Registrierung erhält, wird sich freuen und eine Register-Nachricht mit inkapsuliertem Multicast an RP senden.
Nachdem wir verstanden haben, wie der Multicast zum RP gelangt, wollen wir nun die Frage beantworten, wie das RP den Verkehr zu den Empfängern bringt. Hierbei ist es wichtig, ein neues Konzept einzuführen – den Root-Path-Baum (RPT). Der RPT ist ein Baum, der seinen Ursprung im RP hat und sich in Richtung der Empfänger erstreckt, wobei er an jedem PIM-SM-Router verzweigt. Das RP erstellt diesen Baum, indem es PIM Join-Nachrichten empfängt und einen neuen Zweig hinzufügt. Dies geschieht dann auch bei jedem nachgeschalteten Router. Die allgemeine Regel lautet wie folgt:
- Wenn ein PIM-SM-Router eine PIM Join-Nachricht an einem beliebigen Interface empfängt, mit Ausnahme des Interfaces, das das RP verbirgt, fügt er dem Baum einen neuen Zweig hinzu.
- Ein Zweig wird auch hinzugefügt, wenn der PIM-SM-Router einen IGMP Membership Report von einem direkt angeschlossenen Host erhält.
Stellen wir uns vor, wir haben einen Multicast-Kunden am Router R5 für die Gruppe 228.8.8.8. Sobald R5 den IGMP Membership Report vom Host erhält, sendet R5 einen PIM Join in Richtung RP und fügt den Interface, der zum Host zeigt, zum Baum hinzu. Danach erhält R4 den PIM Join von R5, fügt den Interface Gi0/1 zum Baum hinzu und sendet den PIM Join in Richtung RP. Schließlich erhält RP (R3) den PIM Join und fügt Gi0/0 zum Baum hinzu. Damit wird der Multicast-Empfänger registriert. Es entsteht ein Baum mit R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Daraufhin wird ein PIM Join an R1 gesendet, und R1 beginnt, Multicast-Traffic zu senden. Es ist wichtig zu beachten, dass, wenn der Host den Traffic angefordert hat, bevor das Multicast-Streaming begann, RP keinen PIM Join senden und generell nichts an R1 senden wird.
Wenn der Host während des Multicast-Streamings plötzlich aufhört, ihn empfangen zu wollen, wird RP, sobald es einen PIM Prune auf dem Interface Gi0/0 erhält, sofort einen PIM Register-Stop direkt an R1 senden und anschließend die PIM Prune-Nachricht über das Interface Gi0/1. PIM Register-Stop wird unicast an die Adresse gesendet, von der das PIM Register empfangen wurde.
Wie bereits erwähnt, sobald der Router PIM Join an einen anderen Router, wie zum Beispiel R5 an R4, sendet, wird auf R4 ein Eintrag hinzugefügt:
Ein Timer wird gestartet, und R5 muss ständig PIM Join-Nachrichten senden, da sonst R4 R5 aus der Ausgabeliste ausschließt. R5 wird alle 60 Sekunden PIM Join-Nachrichten senden.
Wechsel des kürzesten Pfades.
Wir fügen eine Schnittstelle zwischen R1 und R5 hinzu und beobachten, wie der Datenverkehr bei dieser Topologie fließt.
Angenommen, der Datenverkehr wurde gemäß dem alten Schema R1-R2-R3-R4-R5 gesendet und erhalten, und jetzt haben wir die Schnittstelle zwischen R1 und R5 angeschlossen und konfiguriert.
Zuerst müssen wir die Unicast-Routing-Tabelle auf R5 umstellen, sodass das Netzwerk 192.168.1.0/24 nun über das Interface R5 Gi0/2 erreichbar ist. Da R5 Multicast über das Interface Gi0/1 erhält, erkennt er, dass die RPF-Regel nicht erfüllt ist, und es sinnvoller wäre, Multicast über Gi0/2 zu empfangen. Er sollte sich von der RPT abmelden und einen kürzeren Baum aufbauen, der als Shortest-Path Tree (SPT) bekannt ist. Dazu sendet er über Gi0/2 eine PIM Join-Nachricht an R1, und R1 beginnt, Multicast auch über Gi0/2 zu senden. Jetzt muss sich R5 von der RPT abmelden, um keine doppelten Kopien zu erhalten. Dafür sendet er eine Prune-Nachricht, die die IP-Adresse des Quellgeräts angibt und ein spezielles Bit - RPT-Bit - einfügt. Das bedeutet, dass ich keinen Traffic mehr empfangen möchte, da ich hier einen besseren Baum habe. Der RP sendet ebenfalls PIM Prune-Nachrichten in Richtung R1, allerdings kein Register-Stop-Nachricht. Eine weitere Besonderheit: R5 wird nun ständig PIM Prune an den RP senden, da R1 weiterhin jede Minute PIM Register an den RP sendet. Solange es keine neuen Interessenten für diesen Traffic gibt, wird der RP ihm eine Ablehnung schicken. R5 informiert den RP, dass er weiterhin Multicast über SPT empfängt.
Dynamische Suche nach RP.
Auto-RP.
Diese Technologie ist proprietär von Cisco und erfreut sich nicht allzu großer Beliebtheit, ist jedoch nach wie vor präsent. Die Funktionsweise von Auto-RP besteht aus zwei Hauptphasen:
1) Der RP sendet RP-Announce-Nachrichten an die reservierte Adresse — 224.0.1.39 und erklärt sich entweder für alle oder für bestimmte Gruppen als RP. Diese Nachricht wird jede Minute gesendet.
2) Es wird ein RP-Mapping-Agent benötigt, der RP-Discovery-Nachrichten sendet, in denen angegeben wird, für welche Gruppen welcher RP gehört. Anhand dieser Nachricht werden normale PIM-Router ihren RP bestimmen. Der Mapping-Agent kann sowohl der RP-Router selbst als auch ein separater PIM-Router sein. RP-Discovery wird an die Adresse 224.0.1.40 mit einem Timer von einer Minute gesendet.
Lassen Sie uns den Prozess genauer betrachten:
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 Routern warten wir auf RP über Auto-RP:
ip pim autorp listener
Sobald wir R3 konfiguriert haben, wird er beginnen, RP-Announce-Nachrichten zu senden:
Und R2 wird nach der Konfiguration als Mapping-Agent beginnen, auf RP-Announce-Nachrichten zu warten. Erst wenn er mindestens einen RP findet, beginnt er, RP-Discovery zu senden:
Sobald herkömmliche Router (PIM RP Listener) diese Nachricht erhalten, wissen sie, wo sie den RP suchen müssen.
Ein zentrales Problem von Auto-RP ist, dass zur Empfängnis der RP-Announce- und RP-Discovery-Nachrichten PIM Join auf die Adressen 224.0.1.39-40 gesendet werden muss, aber dafür muss bekannt sein, wo sich der RP befindet. Es handelt sich um ein klassisches Huhn-und-Ei-Problem. Um dieses Problem zu lösen, wurde der PIM Sparse-Dense-Mode entwickelt. Wenn der Router den RP nicht kennt, arbeitet er im Dense-Mode, wenn er ihn kennt, im Sparse-Mode. Wenn auf den Schnittstellen der herkömmlichen Router PIM Sparse-Mode und der Befehl ip pim autorp listener eingestellt sind, arbeitet der Router nur für das Multicast-Auto-RP-Protokoll (224.0.1.39-40) im Dense-Mode.
BootStrap Router (BSR).
Diese Funktion ähnelt Auto-RP. Jeder RP sendet eine Nachricht an den Mapping-Agent, der die Mapping-Informationen sammelt und dann allen anderen Routern mitteilt. Lassen Sie uns den Prozess analog zu Auto-RP beschreiben:
1) Sobald wir R3 als Kandidaten für den RP konfigurieren, mit dem Befehl:
ip pim rp-candidate loopback 0
Der R3 wird nichts tun, um spezielle Nachrichten zu senden. Zunächst muss er einen Mapping-Agent finden. Somit gehen wir zum zweiten Schritt über.
2) Richten Sie R2 als Mapping-Agent ein:
ip pim bsr-candidate loopback 0
R2 beginnt, PIM Bootstrap-Nachrichten zu versenden, in denen er sich als Mapping-Agent angibt:
Diese Nachricht wird an die Adresse 224.0.0.13 gesendet, die das PIM-Protokoll auch für andere Nachrichten verwendet. Diese werden in alle Richtungen gesendet, sodass das Problem von Huhn und Ei, wie bei Auto-RP, 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:
Daraufhin sendet der BSR, nachdem er die Informationen über den RP erhalten hat, diese per Multicast an die Adresse 224.0.0.13, die von allen PIM-Routern abgehört wird. Daher gibt es keinen direkten Befehl von ip pim autorp listener für herkömmliche Router im BSR.
Anycast RP mit Multicast Source Discovery Protocol (MSDP).
Auto-RP und BSR ermöglichen es uns, die Last auf RP wie folgt zu verteilen: Jede Multicast-Gruppe hat nur einen aktiven RP. Eine Lastverteilung auf mehrere RPs für eine einzige Multicast-Gruppe ist nicht möglich. MSDP erreicht dies, indem es den RPs die gleiche IP-Adresse mit der Maske 255.255.255.255 zuweist. MSDP erfasst Informationen durch einen der Methoden: Statische Konfiguration, Auto-RP oder BSR.
Das Bild zeigt unsere Auto-RP-Konfiguration mit MSDP. Beide RPs sind mit der IP-Adresse 172.16.1.1/32 am Loopback-Interface 1 konfiguriert und werden für alle Gruppen verwendet. Bei RP-Announce informieren beide Router über sich selbst und verweisen auf diese Adresse. Der Auto-RP-Mapping-Agent, der diese Informationen erhält, verteilt die RP-Discovery über den RP mit der Adresse 172.16.1.1/32. Den Routern vermitteln wir Informationen über das Netzwerk 172.16.1.1/32 mithilfe von IGP. Somit fordern PIM-Router Streams vom RP an, der als nächster Hop für die Route zum Netzwerk 172.16.1.1/32 angegeben ist. Das Protokoll MSDP selbst ist dafür gedacht, dass sich die RPs untereinander austauschen und Informationen über Multicast-Streams kommunizieren.
Betrachten wir eine solche Topologie:
Switch6 sendet den Verkehr an die Adresse 238.38.38.38, und nur RP-R1 ist darüber informiert. Switch7 und Switch8 haben diese Gruppe angefordert. Die Router R5 und R4 werden PIM Join an R1 und R3 senden, entsprechend. Warum? Die Route zu 13.13.13.13 wird für R5 auf R1 mit dem IGP-Metrik verweisen, genauso wie für R4.
RP-R1 ist über den Datenstrom informiert und wird ihn in Richtung R5 weiterleiten, während R4 nichts darüber weiß, da R1 ihn nicht einfach so senden wird. Daher ist MSDP erforderlich. Wir konfigurieren es auf R1 und R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 auf R1
ip msdp peer 1.1.1.1 connect-source Loopback3 auf R3
Sie werden eine Sitzung zwischen einander aufbauen und bei Erhalt eines Datenstroms diesem ihrem benachbarten RP mitteilen.
Sobald RP-R1 den Datenstrom von Switch6 empfängt, wird er sofort eine unicast MSDP Source-Active Nachricht senden, die Informationen in der Art von (S, G) — Informationen über Quelle und Ziel des Multicast enthält. Jetzt, wo RP-R3 weiß, dass es eine Quelle wie Switch6 gibt, wird er bei Erhalt der Anfrage von R4 zu diesem Datenstrom PIM Join in Richtung Switch6 senden, basierend auf der Routing-Tabelle. Folglich wird R1, nachdem er einen solchen PIM Join erhält, beginnen, den Verkehr in Richtung RP-R3 zu senden.
MSDP arbeitet ü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 bestimmten Domäne angegeben wird. In dieser Topologie wurde auch eine Konfiguration mit verschiedenen Domänen getestet – dabei gab es keine Unterschiede im Betrieb.
Wenn jemand Klarheit schaffen kann, freue ich mich über Kommentare.
Quelle: habr.com
