Ich suche nach einer Technologie, mit der TCP-Verbindungsfehlertoleranz mithilfe von zwei Verbindungen zwischen Hosts und ohne Zeitverzögerungen für die Erkennung von Routenfehlern erreicht werden kann. Etwas wie das:
link1 packet1copy1->
--------------------------
packet1-> / \ packet1copy1/packet1copy2->
host1--------router1 router2 ------------------------host2
\ link2 packet1copy2-> /
--------------------------
host1und host2sind über router1und router2mit zwei Verbindungen zwischen ihnen verbunden. Jeder Router dupliziert jedes von Hosts kommende Paket, bevor er sie gleichzeitig an beide Verbindungen weiterleitet. Dann sorgen entweder der Peer-Router oder der IP-Stack des Zielhosts für die Beseitigung redundanter Pakete.
Bearbeiten: Dies ist in der Tat eine Suche nach einer universellen Lösung für die Fehlertoleranz durch Replikation für den TCP (IP) -Transport. Die Lösung sollte nicht wiederherstellbar sein, im Gegensatz zu relativ schnell wiederherstellbaren Ansätzen wie BGP / OSPF / Cisco IP SLA usw. Einige proprietäre Paketredundanzlösungen sind bereits bekannt, jedoch nicht ausreichend universell. Engage Communication bietet insbesondere IP Tube Protector für VoIP an. Leider handelt es sich bei dieser Lösung 1) mehr um Geräte als um Standardtechnologie und 2) nur um VoIP-Domänen. Es kann auch erwähnenswert sein, die Juniper Packet Redundancy- Technologie zu erwähnen , obwohl sie anscheinend nur auf einzelne Links und nicht auf redundante Links beschränkt ist.
Ich frage mich, warum ich bei Cisco nichts Ähnliches finden kann ... Behebt dies eine Standard- oder zumindest Allzwecktechnologie?
quelle
Antworten:
Mit Mikrotik-Routern können Sie Bonding im Broadcast-Modus verwenden, siehe Bonding . Ich habe einige Tests über eine 4G-Verbindungsverbindung durchgeführt. Dadurch wird der Paketverlust von 1 auf 2 reduziert, und ich profitiere von Verbesserungen der TCP-Geschwindigkeit. Paketverluste werden nicht vollständig beseitigt, aber das Wechseln zu 3 Verbindungen verbessert sich nicht weiter. Ich würde als nächstes in netzwerkcodiertem TCP nachforschen.
quelle
Es gibt ein paar Dinge, die gegen Ihren Vorschlag sprechen ...
Ich werde mit dem gleichen Kommentar antworten, den ich gemacht habe, da Ihre Anforderungen an die Fehlererkennung zwanzig Sekunden betragen ...
Erstellen Sie nach Bedarf 2 IPSec-Tunnel mit ISP-Diversity. Führen Sie ein Routing-Protokoll durch Ihre IPSec-Tunnel und optimieren Sie die Protokoll-Timer so, dass sie bei anhaltendem Verlust von Infrastrukturpaketen fehlschlagen. Wenn Sie Cisco End-to-End haben, hat EIGRP seit langem eine sehr schnelle Konvergenz bei Fehlern, obwohl die Verbindungsstatusprotokolle heutzutage mit den IETF-schleifenfreien alternativen Implementierungen gleich sind.
Verwenden Sie optional IP SLA auf beiden Seiten, um einen Tunnel abzubauen, der keine Anforderungen an Jitter / Verzögerung / Paketverlust erfüllt.
quelle
With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.OK, von oben;
Stimmen Sie über Ihre Frage von mir ab. Ihre Frage ist aufgrund Ihrer Antworten in Kommentaren zur Antwort anderer nicht klar genug. Sie haben angenommen, dass die Lösung netzwerktechnisch ist, scheinen es aber nicht zu wissen, und erwecken den Eindruck, dass Sie hoffen, dass Ihnen jemand die Antwort gibt, die Sie benötigen.
Sie haben die folgende Problemanforderung;
router1undrouter2, wie Sie nicht erwähnt haben, benötigen Ihre Hosts zwei Verbindungen zu ihrem lokalen Router. Es gibt KEINE native Software oder ein natives Produkt , das auf einem Endhost ausgeführt werden kann und zwei TCP-Streams über dieselbe oder zwei separate NICs entfernt und aus einem alternativen Stream fehlende Pakete aus dem ersten Stream abruft . Woher weiß ich das? Da das Networking nicht so funktioniert, waren IP & TCP einfach nicht so konzipiert. Es gibt vielleicht Produkte zum Duplizieren von Paketen, aber diese sind eine Nische, nicht weit verbreitet, weil es die falsche Antwort auf die Frage ist.Warum ist das so eine verrückte Bitte?
Sie scheinen zu versuchen, einen runden Stift in ein quadratisches Loch zu stecken. Mein Verständnis Ihrer Problemanforderung besteht darin, dass Sie Redundanz für die Daten Ihrer Anwendung wünschen, die zwischen Remote-Hosts übertragen werden. Bei einem Verbindungsfehler werden die Daten zweimal Ende an Ende gesendet. Das ist alles, wovor Sie sich hier mit zwei TCP-Flows schützen, einem Ausfall der physischen Schicht 1. Wenn das Senden eines Pakets von einem Host zum anderen unterbrochen wird, kommt es zu einem verspäteten Eintreffen auf beiden Router-zu-Router-Verbindungen. Wenn ein vorübergehendes Problem auf einer Verbindung auftritt, jedoch nicht auf der anderen, wie z. B. eine Überlastung, muss der Router am Ende der Verbindung beide TCP-Streams gleichzeitig verfolgen, um festzustellen, ob ein Paket auf Verbindung 2 mit der fortlaufenden Sequenznummer in der Verbindung ankommt Header, und auf Link1 ist nichts angekommen, dann ist das Paket auf Link1 zu spät, und wenn es auftaucht, muss es verworfen werden.
Was ist, wenn Sie sich in einer Situation befinden, in der Link1 überlastet ist, aber aufgrund eines guten QoS-Schemas kein Datenverkehr unterbrochen wird, es sich jedoch um Warteschlangen handelt? Pakete nach Link1 befinden sich jetzt immer hinter Link2. Was passiert, wenn Link2 jetzt ausfällt und der Router Pakete auf Link1 an die Endhosts weiterleitet, Dup-Pakete empfängt, stoppt und erneut überträgt usw. und eine Verzögerung verursacht. Hier wurde nichts erreicht.
Weiter zu einer Lösung;
Eine bessere Idee wäre meiner Meinung nach, Dual-Layer-2-Verbindungen zwischen den beiden Endhosts zu haben und ihre Broadcast-Domänen so zu erweitern, dass sie jeweils die NIC einschließen. Sie können dies über direkte Layer-2-Verbindungen, MPLS / VPLS-Erweiterung, Carrier-Layer-2-Service tun, treffen Sie Ihre Wahl, das ist hier nicht unbedingt relevant. Wenn Sie das Layer-2-Netzwerk zwischen Hosts erweitern, müssen Sie sich nicht mit TCP herumschlagen oder verrückte Korrekturen in Form von schwarzer Magie oder Pflaster vornehmen. TCP ist völlig unabhängig von der zugrunde liegenden Technologie und Sie haben weiterhin die Redundanz von Schicht 1 / physischer Verbindung.
Wenn Sie eine MPLS-basierte Lösung verwenden, können Sie Funktionen wie Traffic Engineering (MPLS-TE) verwenden, um die Latenz über die Verbindungen hinweg zu überwachen und immer die Verbindung mit der niedrigsten Latenz zu verwenden. Sie können BFD mit MPLS FRR verwenden, wodurch Sie im Laufe der Zeit zwischen den Links 50 ms ~ ausfallen können. Ich weiß, dass Sie gesagt haben, Sie wollen keine Redundanz-Failover-Lösung, aber 50 ms sind meiner Meinung nach ziemlich schnell. Wenn Ihre Anwendung einen Konnektivitätsverlust von 50 ms nicht bewältigen kann, müssen Sie zum Zeichenbrett der Anwendung zurückkehren. Kein System ist zu 100% in Betrieb. Sie müssen Ausfälle, geplante Wartungsarbeiten und Ausfälle durch böswillige Absichten / Sicherheitsmaßnahmen planen. zu allen irgendwann auftreten. Sie müssen realistisch sein.
In einem Kommentar sagten Sie Folgendes:
Keine solche Sache; Es muss Zeit vergehen, bis mögliche Ereignisse Wirklichkeit werden. Sie müssen dies auf ein "akzeptables" Verzögerungsniveau überdenken.
Auch in einem anderen Kommentar sagten Sie;
BGP hat einen Hallo-Timer, der die Anwesenheit seines unmittelbaren Nachbarn erkennt. Die Standardeinstellung ist 30 Sekunden. Ich vermute, dass Sie sich auch darauf beziehen. Wenn beide Router in Ihrer Topologie BGP mit dem ISP an jedem Standort oder sogar direkt miteinander sprechen, erstellen Sie über diese Peerings IP-in-IP-Tunnel von GRE- oder L2TP (v3) -Tunneln zwischen den beiden Routern, über diese Tunnel wird BFD oder ausgeführt IP SLA. Jetzt können Sie einen End-to-End-Konnektivitätsverlust in 1 oder 2 Sekunden erkennen und mithilfe von Tacking-Objekten zum anderen Tunnel umleiten.
Alles in allem scheinen Sie verschiedene Ebenen der Technologie zu verwechseln. BGP soll kein schnelles Umleiten ermöglichen, TCP soll nicht dupliziert werden und so weiter. Sie suchen nach den falschen Abstraktionsebenen, um dieses Problem anzugehen. Ich hoffe das hat geholfen.
quelle
Time must pass for possible events to become actualities- es gibt keine Nullzeit. Die Box muss nach Verlusten, Verzögerungen, Stürzen usw. suchen, was einige Zeit in Anspruch nimmt. Es kann Mili- oder Mikrosekunden sein, aber es dauert einige Zeit. Genau wie bei BFD müssen Sie beispielsweise 150 ms auf ein Failover warten, wenn Sie die Hallo-Zeit auf 50 ms mit einer Standard-Haltezeit von 3x Hallo einstellen. Hören Sie jetzt bitte auf, eine TDM-Sicherungslösung mit Ihrem Szenario zu vergleichen. Es ist von Natur aus möglich, einen TDM-Dienst wie die von Ihnen benötigte TCP-Redundanz zuDies ist ein Problem auf Anwendungsebene und kein Problem auf Netzwerkebene. Dies liegt daran, dass eines der Kernprinzipien von IP darin besteht, Duplikate zu verhindern, insbesondere wenn die TCP-Neuübertragung aufgerufen wird.
In hochkritischen Umgebungen besteht der Ansatz darin, zwei Netzwerkkarten auf den Endhosts zu haben und die Anwendung dazu zu bringen, zwei eindeutige Pakete zu generieren. Mit diesem Ansatz können Sie vorhandene Technologien und Netzwerkprinzipien mithilfe variabler Pfade und Metriken verwenden.
quelle
Mir sind keine Tricks oder Protokolle bekannt, die diese Art der Vorwärtsreplikation auf den betreffenden Netzwerkgeräten durchführen können. Für diese Art von Anwendung würde ich Redundanz und schnelle Fehlererkennung mit BGP Fast-Failover, BFD und anderen Tools empfehlen. Ich bin jedoch auf dieses Open-Source-Projekt namens "Tunnel Splitter" gestoßen. Http://coderrr.wordpress.com/2010/01/10/tunnel-splitter-accelerating-a-single-tcp-connection-over-multiple-isps/das scheint zu passen, wonach Sie suchen. Kurz gesagt, die an jedem Standort installierten TS-Boxen stellen die TCP-Verbindungen zwischen Host1 und Host2 dar und teilen dann den Datenverkehr zwischen ihnen über Tunnel auf. Da jeder Tunnel eine eindeutige Quelladresse hat, kann PBR (richtlinienbasiertes Routing) an den Routern verwendet werden, um den Verkehr für Tunnel1 über Link1 und Tunnel2 über Link2 zu leiten. Die TS-Boxen beenden die Tunnel und haben eine einzige TCP-Verbindung zu Host1 und Host2. Natürlich müssten Sie das wirklich, wirklich testen, aber es scheint auf dem Whiteboard zu funktionieren!
quelle