Mehrere Rechenzentren und HTTP-Datenverkehr: DNS Round Robin ist der EINZIGE Weg, um ein sofortiges Failover zu gewährleisten?

78

Mehrere A-Einträge, die auf dieselbe Domäne verweisen, werden anscheinend fast ausschließlich zum Implementieren von DNS Round Robin als billige Lastausgleichstechnik verwendet.

Die übliche Warnung vor DNS RR ist, dass es nicht gut für eine hohe Verfügbarkeit ist. Wenn eine IP-Adresse ausfällt, wird sie von den Clients minutenlang verwendet.

Ein Load Balancer wird häufig als bessere Wahl vorgeschlagen.

Beide Behauptungen sind nicht ganz richtig:

  1. Wenn der Datenverkehr dann HTTP ist, können die meisten HTML-Browser automatisch den nächsten A-Eintrag versuchen, wenn der vorherige nicht verfügbar ist, ohne dass eine neue DNS-Suche durchgeführt wird. Lesen Sie hier Kapitel 3.1 und hier .

  2. Wenn mehrere Rechenzentren beteiligt sind, ist DNS RR die einzige Option, um den Datenverkehr auf diese zu verteilen.

Stimmt es also, dass die Verwendung von DNS RR bei mehreren Rechenzentren und HTTP-Datenverkehr die EINZIGE Möglichkeit ist, ein sofortiges Failover zu gewährleisten, wenn ein Rechenzentrum ausfällt?

Vielen Dank,

Valentino

Bearbeiten:

  • Selbstverständlich verfügt jedes Rechenzentrum über einen lokalen Load Balancer mit Hot Spare.
  • Es ist in Ordnung, die Sitzungsaffinität für ein sofortiges Failover zu opfern.
  • AFAIK Die einzige Möglichkeit für einen DNS, ein Rechenzentrum anstelle eines anderen vorzuschlagen, besteht darin, nur mit der IP (oder den IPs) zu antworten, die diesem Rechenzentrum zugeordnet sind. Wenn das Rechenzentrum nicht mehr erreichbar ist, sind auch alle diese IP-Adressen nicht mehr erreichbar. Dies bedeutet, dass alle Versuche fehlschlagen, bis der lokale Cache - Eintrag abläuft und eine neue DNS - Suche durchgeführt wird und die neuen funktionierenden IP - Adressen abgerufen werden (ich nehme an, DNS schlägt a automatisch vor) neues Rechenzentrum, wenn einer ausfällt). "Smart DNS" kann also kein sofortiges Failover gewährleisten.
  • Umgekehrt erlaubt ein DNS-Round-Robin dies. Wenn ein Rechenzentrum ausfällt, versuchen die (meisten) intelligenten HTML-Browser sofort, die anderen zwischengespeicherten A-Datensätze in ein anderes (funktionierendes) Rechenzentrum zu verschieben. DNS Round-Robin sichert also nicht die Sitzungsaffinität oder die niedrigste RTT, sondern scheint die einzige Möglichkeit zu sein, ein sofortiges Failover zu gewährleisten, wenn die Clients "intelligente" HTML-Browser sind.

Bearbeiten 2:

  • Einige Leute schlagen TCP Anycast als endgültige Lösung vor. In diesem Artikel (Kapitel 6) wird erklärt, dass Anycast-Failover mit der BGP-Konvergenz zusammenhängt. Aus diesem Grund kann Anycast zwischen 15 Minuten und 20 Sekunden Zeit in Anspruch nehmen. In Netzwerken, in denen die Topologie dafür optimiert wurde, sind 20 Sekunden möglich. Wahrscheinlich können nur CDN-Betreiber solche schnellen Ausfälle gewähren.

Edit 3: *

  • Ich habe ein paar DNS-Lookups und Traceroutes durchgeführt (vielleicht kann ein Experte dies noch einmal überprüfen) und:
    • Das einzige CDN, das TCP Anycast verwendet, scheint CacheFly zu sein, andere Betreiber wie CDN-Netzwerke und BitGravity verwenden CacheFly. Scheint, dass ihre Kanten nicht als Reverse-Proxys verwendet werden können. Sie können daher nicht zum Gewähren eines sofortigen Failovers verwendet werden.
    • Akamai und LimeLight scheinen geobewusstes DNS zu verwenden. Aber! Sie geben mehrere A-Datensätze zurück. Aus Traceroutes geht hervor, dass sich die zurückgegebenen IPs im selben Rechenzentrum befinden. Ich bin verwirrt darüber, wie sie eine 100% SLA anbieten können, wenn ein Rechenzentrum ausfällt.
Valentino Miazzo
quelle
Bei hoher Verfügbarkeit implizierte ich ein fast sofortiges Failover. Der Client sollte kein Problem bemerken, auch wenn ein Rechenzentrum ausfällt. Ich habe die Frage verfeinert.
Valentino Miazzo
MaxCDN verwendet Anycast-TCP und seine Ränder können im Caching-Proxy-Modus verwendet werden ("Origin Fetch" in der CDN-Branchenterminologie).
Malayter
@vmiazzo, Ihr PDF-Link ist nicht verfügbar. Meinen Sie 15 Minuten oder 20 Sekunden bis 15 Minuten?
Pacerier

Antworten:

34

Wenn ich den Begriff "DNS Round Robin" verwende, meine ich im Allgemeinen im Sinne der "billigen Lastausgleichstechnik", wie sie OP beschreibt.

Dies ist jedoch nicht die einzige Möglichkeit, DNS für eine globale Hochverfügbarkeit zu verwenden. Meist fällt es Menschen mit unterschiedlichem (technischem) Hintergrund schwer, gut zu kommunizieren.

Die beste Lastverteilungsmethode (wenn Geld kein Problem ist) wird im Allgemeinen als:

  1. Ein Anycast'ed globales Netzwerk von "intelligenten" DNS-Servern,
  2. und eine Reihe von global verteilten Rechenzentren,
  3. wo jeder DNS-Knoten Split Horizon DNS implementiert,
  4. und Überwachung der Verfügbarkeit und des Verkehrsflusses sind in gewisser Weise für die "intelligenten" DNS-Knoten verfügbar,
  5. Damit die DNS-Anforderung des Benutzers über IP Anycast an den nächsten DNS-Server weitergeleitet wird ,
  6. und dieser DNS-Server verteilt über 'intelligentes' Split-Horizon-DNS einen Low-TTL-A-Record / Satz von A-Records für das nächstgelegene / beste Datencenter für diesen Endbenutzer.

Die Verwendung von Anycast für DNS ist im Allgemeinen in Ordnung, da DNS-Antworten zustandslos und fast extrem kurz sind. Wenn sich die BGP-Routen ändern, ist es sehr unwahrscheinlich, dass eine DNS-Abfrage unterbrochen wird.

Anycast ist weniger für längere und zustandsbehaftete HTTP-Konversationen geeignet, daher verwendet dieses System Split-Horizon-DNS. Eine HTTP-Sitzung zwischen einem Client und einem Server wird in einem Datencenter gespeichert. Es kann im Allgemeinen nicht auf ein anderes Datencenter umgeschaltet werden, ohne die Sitzung zu unterbrechen.

Wie ich mit "set of A Records" angegeben habe, kann das, was ich als "DNS Round Robin" bezeichne, zusammen mit dem obigen Setup verwendet werden. Es wird in der Regel verwendet, um die Datenverkehrslast auf mehrere hochverfügbare Load-Balancer in jedem Rechenzentrum zu verteilen (damit Sie eine bessere Redundanz erzielen, kleinere / billigere Load-Balancer verwenden und die Unix-Netzwerkpuffer eines einzelnen Host-Servers nicht überfordern usw.).

Stimmt es also, dass bei mehreren Rechenzentren und HTTP-Datenverkehr die Verwendung von DNS RR die EINZIGE Möglichkeit ist, um eine hohe Verfügbarkeit sicherzustellen?

Nein, es ist nicht wahr, nicht wenn wir mit "DNS Round Robin" einfach mehrere A-Einträge für eine Domain verteilen wollen. Es ist jedoch richtig, dass der kluge Einsatz von DNS eine entscheidende Komponente in jedem globalen Hochverfügbarkeitssystem ist. Das Obige zeigt einen gemeinsamen (oft besten) Weg.

Bearbeiten: Das Google-Papier "Über End-to-End-Pfadinformationen hinausgehen, um die CDN-Leistung zu optimieren" scheint mir bei der globalen Lastverteilung auf dem neuesten Stand zu sein, um die bestmögliche Leistung für Endbenutzer zu erzielen.

Edit 2: Ich habe den Artikel "Why DNS Based .. GSLB .. Does not Works" gelesen, der mit OP verlinkt ist, und er bietet einen guten Überblick - ich empfehle, ihn anzuschauen . Lesen Sie es von oben.

Im Abschnitt "Die Lösung für das Browser-Caching-Problem" werden DNS-Antworten mit mehreren A-Einträgen empfohlen, die auf mehrere Rechenzentren verweisen. Dies ist die einzig mögliche Lösung für ein sofortiges Failover.

Im Abschnitt "Verwässern" im unteren Bereich wird deutlich, dass das Senden mehrerer A-Datensätze nicht geeignet ist, wenn sie auf Datencenter auf mehreren Kontinenten verweisen, da der Client eine zufällige Verbindung herstellt und daher häufig eine "langsame" Verbindung erhält. Gleichstrom auf einem anderen Kontinent. Damit dies wirklich gut funktioniert, sind mehrere Rechenzentren auf jedem Kontinent erforderlich.

Dies ist eine andere Lösung als meine Schritte 1 - 6. Ich nicht eine perfekte Antwort auf diese liefern kann, denke ich , ein DNS - Spezialist von den Gleichen von Akamai oder Google ist erforderlich, weil ein großer Teil davon läuft darauf hinaus, praktisches Know-how auf die Einschränkungen der heute bereitgestellten DNS-Caches und Browser. AFAIK, meine Schritte 1-6 sind das, was Akamai mit seinem DNS macht (kann das jemand bestätigen?).

Ich habe das Gefühl, als PM auf mobilen Browser-Portalen (Mobiltelefonen) gearbeitet zu haben, dass die Vielfalt und der Grad der totalen Zerstörung der Browser dort draußen unglaublich ist. Ich persönlich würde einer HA-Lösung nicht vertrauen, bei der das Endbenutzerterminal das Richtige tun muss. Aus diesem Grund glaube ich, dass ein globales sofortiges Failover ohne Unterbrechung einer Sitzung heute nicht möglich ist.

Ich denke, meine Schritte 1-6 oben sind die besten, die mit der Commodity-Technologie verfügbar sind. Diese Lösung bietet kein sofortiges Failover.

Ich würde es begrüßen, wenn einer dieser DNS-Spezialisten von Akamai, Google usw. vorbeikommt und mir das Gegenteil beweist. :-)

Jesper Mortensen
quelle
Ich habe der Frage weitere Erklärungen hinzugefügt. Wenn ich Ihre "beste Lastausgleichstechnik" (Punkt 6) verstehe, werden nur die A-Datensätze des "besten" Rechenzentrums angekündigt. Wie ich in der Frage versucht habe zu erklären, ermöglicht dies kein sofortiges Failover auf dem Client.
Valentino Miazzo
@vmiazzo: Ja, du hast mich richtig verstanden. Ich füge meinem Beitrag eine zweite Änderung hinzu, um dies zu verdeutlichen. Grundsätzlich halte ich das sofortige Failover für unpraktisch / unmöglich.
Jesper Mortensen
Was ich interessant finde, ist, dass niemand vorgeschlagen hat, die beiden Ansätze miteinander zu kombinieren. Es ist zwar nicht ideal, bietet aber eine angemessene Geschwindigkeit, wenn die Dinge richtig funktionieren, und eine zusätzliche Ausfallsicherheit, wenn sie nicht funktionieren. Die Strafe wäre eine große Verzögerung, da Clients von einer Anycast-basierten DNS-Adresse zu einer anderen wechseln.
Avery Payne
@JesperMortensen, Wenn Sie "intelligentes" DNS sagen, meinen Sie damit Split-Horizon-DNS? Oder meinen Sie etwas anderes (basierend auf Faktoren jenseits der Quell-IP)?
Pacerier
18

Ihre Frage lautet: "Ist DNS Round Robin der EINZIGE Weg, um ein sofortiges Failover zu gewährleisten?"

Die Antwort lautet: "DNS Round Robin ist NIE der richtige Weg, um ein sofortiges Failover zu gewährleisten."

(zumindest nicht alleine)

Der richtige Weg, um ein sofortiges Failover zu erreichen, besteht darin, das BGP4-Routing so zu verwenden, dass beide Standorte die gleichen IP-Adressen verwenden. Auf diese Weise werden die zentralen Routing- Technologien des Internets verwendet, um die Anforderungen an das richtige Rechenzentrum weiterzuleiten, anstatt die zentralen Adressierungstechnologien des Internets zu verwenden.

In der einfachsten Konfiguration wird nur ein Failover bereitgestellt. Es kann auch verwendet werden, um Anycast bereitzustellen, mit dem Vorbehalt, dass TCP-basierte Protokolle zum Zeitpunkt der Umschaltung fehlschlagen, wenn das Routing instabil ist.

Alnitak
quelle
Es wurden einige Informationen zu Anycast-Failover zu der Frage hinzugefügt. Grundsätzlich ist auch TCP Anycast keine perfekte Lösung.
Valentino Miazzo
@vmiazzo re TCP Anycast - in der Tat, daher der Hinweis in meiner Antwort über Routing-Instabilität und wie es TCP beeinflusst.
Alnitak
6

Stimmt es also, dass bei mehreren Rechenzentren und HTTP-Datenverkehr die Verwendung von DNS RR die EINZIGE Möglichkeit ist, um eine hohe Verfügbarkeit sicherzustellen?

Dies ist eindeutig eine falsche Behauptung - Sie müssen sich nur Google, Akamai und Yahoo ansehen, um festzustellen, dass sie keine Round-Robin-Antworten [*] als einzige Lösung verwenden (einige verwenden sie möglicherweise teilweise, zusammen mit anderen Ansätzen) .)

Es gibt viele mögliche Optionen, aber es hängt wirklich davon ab, welche anderen Einschränkungen Sie haben und welchen Dienst / welche Anwendung Sie auswählen.

Es ist möglich, Round-Robin-Techniken auf einem einfachen, lokalisierten Server-Ansatz anzuwenden, und Sie müssen sich keine Gedanken über Serverausfälle machen, wenn Sie auch das 'Failover' der IP-Adresse veranlassen. (Die meisten entscheiden sich jedoch für Load-Balancing-Techniken, eine einzelne IP-Adresse und Failover zwischen Load-Balancern.)

Möglicherweise benötigen Sie alle Anforderungen für eine einzelne Sitzung, um zu denselben Servern zu gelangen, möchten jedoch, dass die Anforderungen auf verschiedene regionale Servercluster verteilt werden? Round Robin ist dafür nicht geeignet: Sie müssen etwas tun, um sicherzustellen, dass ein bestimmter Client jedes Mal auf denselben physischen Servercluster zugreift (es sei denn, es treten Ausnahmen auf, z. B. ein Serverausfall). Entweder erhalten sie eine konsistente IP-Adresse von einer DNS-Abfrage oder sie werden an denselben physischen Servercluster weitergeleitet. Lösungen hierfür sind verschiedene kommerzielle und nichtkommerzielle DNS- "Load Balancer" oder (wenn Sie mehr Kontrolle über Ihr Netzwerk haben) BGP-Netzwerkwerbung. Sie könnten einfach dafür sorgen, dass die Nameserver Ihrer eigenen Domain ganz andere Antworten geben (aber da DNS-Anfragen überall gesendet werden können, haben Sie gewonnen).

[* Ich werde "Round-Robin" verwenden, da "RR" in der DNS-Terminologie "Ressourceneintrag" bedeutet.]

jrg
quelle
Ich habe der Antwort weitere Erklärungen hinzugefügt. Ihr Vorschlag, DNS "Load Balancer" zu verwenden, lässt IMHO kein sofortiges Failover zu. Beziehen Sie sich bezüglich des BGP auf eine Anycast TCP-Lösung?
Valentino Miazzo
Ich schlage keine bestimmte Lösung vor - ich sage, dass Sie die richtige Lösung für Ihr Problem (das Sie in Ihrer Frage nicht angegeben haben) und für Ihre Einschränkungen (dito.) Auswählen müssen, die DNS Round-Robin bietet Bieten Sie kein sofortiges Failover mehr als DNS LB, da Browser nicht garantiert "das Richtige" tun (hauptsächlich, weil das "Richtige" nicht genau definiert oder vorgeschrieben ist. Ich glaube nicht, dass es genug "Smart" gibt HTML-Browser ", auch jetzt noch - Ich stimme Jesper zu, dass sie sich in ihrem Verhalten zu unterschiedlich verhalten, um sich überhaupt auf sie zu verlassen.)
jrg 30.09.09
Ich verstehe deine Skepsis. Wie Sie hier lesen können, ist crypto.stanford.edu/dns/dns-rebinding.pdf in den meisten aktuellen HTML-Browsern bereits "intelligent".
Valentino Miazzo
5

Sehr schöne Beobachtung vmiazzo +1 für Sie! Ich stecke genau da fest, wo du bist. Verblüfft darüber, wie diese CDN ihre Magie vollbringen.

Nachfolgend meine Vermutung, wie CDN sein Netzwerk betreibt:

  • Verwenden Sie Anycast DNS (von Jesper Mortensen erwähnt), um das nächstgelegene Rechenzentrum zu ermitteln
  • Sie betreiben ein lokales Netzwerk, das sich über verschiedene Rechenzentren erstreckt, sodass sie auf ihren Hosts in verschiedenen Rechenzentren so etwas wie CARP ausführen können

Oder

  • Sie verwenden das Gateway Load Balancing Protocol auf ihren Routern oder das Hot Standby Router Protocol (HSRP) . die sich mit Datencenter-Ausfällen befassen.
  • Der Grund dafür, dass mehrere IP-Adressen enthalten sind, besteht darin, dass der Client es erneut versucht. Zum Zeitpunkt des erneuten Versuchs des Clients hat sich der Routing-Pfad möglicherweise geändert.

Im Moment funktioniert folgende Lösung für mich: - DNS gibt mehrere IP zurück, zB:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy
  • Letzter Einstiegspunkt für einen Reverse-Proxy in der Amazon Cloud, der intelligent an den verfügbaren Server weitergeleitet wird (oder auf der Wartungsseite bereitgestellt wird)

Reverse Proxy wird immer noch getroffen, aber der Bot ist so schwer wie der Hauptproxy.

Rianto Wahyudi
quelle
Die Reihenfolge mehrerer DNS-Einträge, die Clients erhalten, ist absichtlich zufällig festgelegt, sodass Ihr Reverse-Proxy wahrscheinlich etwa 1/6 der Zeit (1/2 von 1/3) getroffen wird. Wie ist das besser oder anders als mit 6 A Aufzeichnungen?
ColinM
3

Warum ist RFC 2782 (gilt für Services wie http, imap, ... wie MX / priority) in keinem Browser implementiert? Dinge wären einfacher ... Es gibt einen Bug, der seit zehn Jahren in Mozilla geöffnet ist !!! weil es das Ende der Industrie des kommerziellen Load-Balancers sein wird ??? Das enttäuscht mich sehr.


quelle
2

2 - Sie können dies mit Anycast mit Quagga tun

(Auch wenn es Informationen gibt, dass Anycast mit TCP nicht kompatibel ist, gibt es einige große Unternehmen, die es verwenden, wie CacheFly)

rkthkr
quelle
Auf jeden Fall, aber bei gemieteten Servern ist das nicht möglich. Sie benötigen ein eigenes Netzwerk.
Julien Tartarin
Es wurden einige Informationen zu Anycast-Failover zu der Frage hinzugefügt. Grundsätzlich ist auch TCP Anycast keine perfekte Lösung.
Valentino Miazzo
2

Ich frage mich, wie viele Personen, die diese Fragen beantworten, tatsächlich ein großes weltweites Netzwerk von Servern betreiben. Google verwendet Round Robin und mein Unternehmen verwendet es seit Jahren. Es kann ziemlich gut funktionieren, mit einigen Einschränkungen. Ja, es muss mit anderen Maßnahmen ergänzt werden.

Der eigentliche Schlüssel ist, bereit zu sein, ein oder zwei Schluckauf zu akzeptieren, wenn ein Server ausfällt. Wenn ich den Stecker auf einen Server ziehe und ein Browser versucht, auf diesen Server zuzugreifen, tritt eine Verzögerung von ungefähr einer Minute auf, während der Browser erfährt, dass die IP-Adresse inaktiv ist. Es geht dann aber sehr schnell auf einen anderen Server.

Es funktioniert großartig und Leute, die behaupten, dass es viele Probleme verursacht, wissen nicht, wovon sie sprechen. Es braucht nur das richtige Design.

Failover ist scheiße. Die beste HA nutzt die ganze Zeit alle Ressourcen.

Ich arbeite seit 1986 mit HA. Ich habe umfangreiche Schulungen zum Erstellen von Failover-Systemen absolviert und bin überhaupt kein Fan von Failover.

RR verteilt die Last auch dann, wenn sie eher passiv als aktiv ist. In unseren Server-Protokollen wird der entsprechende Prozentsatz des Datenverkehrs auf jedem Server deutlich angezeigt - und das innerhalb eines angemessenen Rahmens.

Alter Mann
quelle
1

Eine andere sehr einfache Option ist die Verwendung einer niedrigen TTL (wie niedrig diese von Ihren Anforderungen abhängt) im DNS A- oder CNAME-Eintrag und die Aktualisierung dieses Eintrags, um auszuwählen, welche IP verwendet wird.

Wir haben 2 ISP und mehrere öffentliche Dienste und verwenden diese Methode erfolgreich für Hochverfügbarkeit ab 3 Jahren.

lg.
quelle
Ich habe der Frage weitere Erklärungen hinzugefügt. Viele HTML-Browser ignorieren DNS TTL (DNS Pinning), siehe das in der Frage verlinkte Papier. Ändern Sie die DNS-Konfiguration, wenn ein Rechenzentrum ausfällt. Dies ermöglicht kein sofortiges Failover auf dem Client.
Valentino Miazzo
1

Ein Schlüssel in der Arbeit ist, dass eine Reihe von ISPs Resolver schlecht konfiguriert haben, die Datensätze für ein festgelegtes Intervall zwischenspeichern und TTL-Einstellungen vollständig ignorieren. Es sollte nicht so sein und es gibt keine Entschuldigung dafür, aber leider aufgrund meiner Erfahrung mit der Migration zahlreicher Websites und Dienste.

Twirrim
quelle
2
Dafür gibt es eine Entschuldigung. Niedrige TTLs wirken sich in hohem Maße auf die Leistung ausgelasteter DNS-Server aus. Wenn sie permanent und nicht nur vorübergehend verwendet werden, wenn eine Änderung fällig ist, werden das System und ihre Ressourcen missbraucht. Die meisten ISPs erzwingen eine minimale TTL erst, wenn sie länger als einen angemessenen Zeitraum auf niedrig gesetzt wurde.
James Ryan
-1

Mehrere A-Datensätze sind die einzige Möglichkeit, einen möglichen Single Point of Failure zu beseitigen. Jede andere Lösung erzwingt, dass alle eingehenden Anforderungen ein einzelnes Gerät zwischen Server und Client durchlaufen.

Für absolute Redundanz ist es also notwendig. Das ist der Grund, warum Google es tut oder jeder andere, der sich auf eine kontinuierliche Verfügbarkeit des Dienstes verlassen möchte.

Es ist ziemlich offensichtlich, warum dies der Fall ist ... Mehrere A-Datensätze sind die einzige Möglichkeit, den Punkt zu verschieben, an dem Anforderungen an den Client-Browser weitergeleitet werden. Jede andere Methode basiert auf einem einzelnen Punkt zwischen dem Client-Browser und dem Server, an dem ein Fehler auftreten kann, der Ihren Dienst beeinträchtigt. Wenn Sie A-Datensätze verwenden, wird der Client selbst zum einzigen Fehlerpunkt von Client zu Server.

Wenn Sie nicht mehrere A-Datensätze eingerichtet haben, fragen Sie nach Ausfallzeiten ...

Diese Methode kann jedoch offensichtlich nicht für den Lastenausgleich herangezogen werden.


quelle
1
Was? Mehrfach-A-Rekoerdungen beseitigen keine einzelne Fehlerstelle! es fragt nach Problemen. Sie verwenden eine virtuelle "Floating" -IP in einem Datencenter oder Routing-Tricks, wenn Sie schnell ein Failover zwischen mehreren Datencentern durchführen möchten.
pQd
Es ist absolut nicht erforderlich, dass eine einzelne IP-Adresse ein einzelnes Gerät durchläuft.
Sandman4