Redundante IP-Link-Aggregation für den Failover-Betrieb ohne Erkennung von Routenfehlern

7

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?

Sergey Ushakov
quelle
3
TCP überträgt verlorene Segmente erneut. Wenn Sie ohne erneute Übertragung keinen Paketverlust wünschen, benötigen Sie neben TCP eine andere Technologie. Welches Geschäftsproblem lösen Sie?
Mike Pennington
1
Ja, TCP überträgt verlorene Segmente erneut. Bei Routing-Protokollen wie BGP dauert es jedoch einige Zeit, bis festgestellt wird, dass die als betriebsbereit erachtete Route jetzt nicht verfügbar ist. Schließlich erkennen die Router dies und wechseln die aktiven Routen, aber es braucht Zeit, und das Protokoll auf Anwendungsebene kann darunter leiden ... Mein Geschäftsproblem ist die Online-Verarbeitung von Finanztransaktionen.
Sergey Ushakov
1
Das Standardzeitlimit auf Anwendungsebene beträgt 40 Sekunden. Tatsächlich können wir nur etwa 20 Sekunden für die Erkennung von Routenfehlern einplanen, um Transaktionsfehler zu vermeiden. ja, der Antrag ist bereits geschrieben, kann aber geändert werden; Es wird keine Verschlüsselung auf Anwendungsebene verwendet. Nur die redundanten Fernverbindungen sind mit IPsec gesichert
Sergey Ushakov
4
Führen Sie Ihr eigenes IgP-Routing-Protokoll durch die IPSec-Tunnel, optional mit IP-Sla, und schlagen Sie nach Bedarf fehl ... Dies ist ein ziemlich standardmäßiges Design
Mike Pennington
1
Was verwenden Sie zum Beenden der IPSec-Links? Cisco ASA oder ein Router oder ??? Sie können sich nicht auf einseitige Erkennung verlassen ... IP SLA auf beiden Seiten oder ein Routing-Protokoll beheben Ihre Fehlererkennungsprobleme, wenn Sie die Hallo-Timer entsprechend anpassen
Mike Pennington

Antworten:

0

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.

Netflow
quelle
Produkt- oder Ressourcenempfehlungen sind hier ausdrücklich nicht zum Thema, ebenso wie Geräte für Endverbraucher, z. B. MikroTik.
Ron Maupin
@Netflow Vielen Dank, dass Sie Bonding im Broadcast-Modus bemerkt haben, unabhängig von Mikrotik :) Ich bin mir nicht sicher, ob ich es in naher Zukunft versuchen kann, aber es ist trotzdem gut zu wissen, dass es einen auf Standards basierenden Ansatz zu geben scheint. ..
Sergey Ushakov
10

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->  /
                     --------------------------

Es gibt ein paar Dinge, die gegen Ihren Vorschlag sprechen ...

  1. Sie werden dafür sorgen, dass Host1 und Host2 sehr hart arbeiten, um Ihr absichtliches Paketduplikationsschema ohne guten Grund zu entwirren
  2. Sie verbrauchen ohne guten Grund PS an Ihren IPSec-Verschlüsselungspunkten
  3. TCP wurde seit über drei Jahrzehnten weiterentwickelt, um Infrastrukturfehler und -ausfälle automatisch zu beheben. Das "Helfen" von TCP auf diese Weise behebt das falsche Problem. Sie müssen dafür sorgen, dass Ihre Infrastruktur reagiert, um Probleme zu mindern. Sie sollten kein Klebeband-TCP verwenden, um eine problematische Infrastruktur zu überleben.

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.

Mike Pennington
quelle
Mike, bei allem Respekt kann ich Ihre Kritik aus folgenden Gründen nicht akzeptieren: 1) Meine Frage strebt eine Fehlertoleranz nach Replikationstyp der Lösung an, während Ihre Lösungen nach Redundanztyp fehlertolerant sind. Beide Ansätze werden normalerweise als gültig angesehen, führen jedoch tendenziell zu unterschiedlichen Servicequalitätsniveaus, und ich strebe ein besseres Serviceniveau an. 2) Fehlertoleranz durch Replikation ist tendenziell teurer, aber ich würde das Wort "teuer" hier nicht zu ernst nehmen :) Das heißt, bitte akzeptieren Sie mein "Danke" und stimmen Sie für einen guten Überblick ab, aber ich akzeptiere Ihre Antwort nicht
Sergey Ushakov
1
@ sn-ushakov, wie gesagt ... wenn Sie Fehlertoleranz durch Replikation wünschen, verwenden Sie das falsche Protokoll. TCP wurde zur Fehlertoleranz durch Redundanz erstellt. Wenn Sie Fehlertoleranz durch Replikation wünschen, darf ich Sie unserem Freund vorstellen, der als UDP bekannt ist . UDP ist viel besser für das geeignet, was Sie wollen; Dies bedeutet jedoch, dass Sie Ihre primäre Geschäftsanwendung neu schreiben werden, nur weil Sie in ein seltsames Netzwerkdesign verliebt sind (ohne bekannte Hardware zur Implementierung dieser bidirektionalen Paketreplikation, könnte ich hinzufügen)
Mike Pennington
Nun, manchmal ist das Protokoll auf Anwendungsebene nicht unsere Wahl ... und das Wissen über Ihre Peer-Infrastruktur kann in der Geschäftswelt begrenzt sein ... und es kann cool sein, beispielsweise HTTP über UDP zu entwerfen und zu implementieren :) und zu sprechen Im Ernst, danke, dass Sie auf Verbindungsstatusprotokolle hingewiesen haben. Sie können eine Erleichterung sein, sind aber nicht die endgültige Lösung. Übrigens hat TCP selbst bereits zumindest einen Teil der gesuchten Lösung vorgesehen: Der TCP muss Daten wiederherstellen, die ... dupliziert sind ... - RFC 793, Abschnitt 1.5, Unterabschnitt "Zuverlässigkeit"
Sergey Ushakov
6
Fühlen Sie sich frei, RFC 793, Abschnitt 1.5 zu zitieren ... als Antwort werde ich RFC 1925, Abschnitt (3) zitieren :With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea.
Mike Pennington
2
Engage Communications verkauft eine TDM-over-IP-Lösung. Sie fragen nach einer TCP-über-IP-Lösung ... Sie könnten IP über TDM über IP legen, aber auch hier ... das ist wirklich verrückt. Sie sollten einen echten Netzwerktechniker einstellen
Mike Pennington
4

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;

Host1 und Host2 sind über Router1 und Router2 mit 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.

  • Sofern die Verbindung Ihres Endhosts zu seinem lokalen Router nicht doppelt so schnell ist wie der Datenverkehr über eine einzelne Verbindung zwischen router1und router2, 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:

Nun, IP SLA ist die Technologie, die bisher mindestens an einem Ende verwendet wird ... :) Trotzdem dauert es ziemlich lange, bis beide Enden einen Verbindungsfehler erkennen, und die Anwendung ist manchmal nicht mehr synchron ... und die Verbindungen können manchmal funkeln ... deshalb suchen wir etwas ohne Verzögerung

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 Es dauert eine ganze Weile, bis festgestellt wird, dass die als betriebsbereit geltende Route jetzt nicht mehr verfügbar ist. Schließlich erkennen die Router dies und wechseln die aktiven Routen, aber es braucht Zeit, und das Protokoll auf Anwendungsebene kann darunter leiden

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.

jwbensley
quelle
2
Er braucht sie nicht, er kann MPLS über GRE ausführen, zum Beispiel MPLS über IPSEC. Er könnte möglicherweise in L2-Links investieren? Wer weiß oder kümmert sich um sein Budget, nicht ich; Ich sage nicht, dass meine Ideen die besten sind, ich versuche einfach, Lösungen für das Problem zu finden, die vernünftig und zuverlässig sind, unabhängig von Kosten oder Verfügbarkeit, und die Probleme, mit denen er konfrontiert ist, und die Gründe für eine Entscheidung gegenüber einer anderen näher zu erläutern. Es ist eine rein technische Antwort.
Jwbensley
1
@ sn-ushakov Es gibt keine Null-Zeit
jwbensley
1
In diesem Dokument heißt es nicht, mich selbst zu wiederholen 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 zu
betreiben
1
... weil Sie wissen, wann ein TDM-Paket genau eintreffen sollte. Wenn Sie nicht genau verstehen, wie E1s / T1s funktionieren, sollten Sie zuerst darüber lesen. Dann werden Sie verstehen, dass ein Grund für TDM-Verbindungen die Zuverlässigkeit wie die garantierte Latenz ist. Sie laufen mit einer festen Geschwindigkeit und Bildrate pro Sekunde. IP / TCP ist überall auf der Skala. TDM ist viel vorhersehbarer und läuft auf einer niedrigeren Ebene als TCP. Es wäre, als würde man Ethernet-Frames über zwei Verbindungen duplizieren. Die Tatsache, dass auf diesen Boxen TDM über IP ausgeführt wird,
erhöht das
1
... diese Boxen haben Skew-Timer und Frame-Detektoren außerhalb der Reihenfolge (Lesen von Sequenznummern).
Jwbensley
1

Dies 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.

tdops
quelle
Entschuldigung, kann aber nicht zustimmen, dass dies ein Problem auf Anwendungsebene ist. Die Anwendung hat das Recht, nur eine TCP-Verbindung von ausreichender Qualität zu erwarten. TCP selbst bietet Bestimmungen für die Wiederherstellung nach geringfügigen Netzwerkfehlern, und es gibt zahlreiche Lösungen, die Netzwerkfehlertoleranz durch alternatives Routing bieten. Leider sind alle, die ich kenne, eher von der Art der schnellen Wiederherstellung nach einem Ausfall als von der Art, dass sie nicht wiederhergestellt werden müssen . Ich empfinde diese Aufgabe nur als eine redundante Aufgabe der Netzwerktechnik. Wenn wir ein RAID haben können, warum können wir dann kein RAIN haben? :)
Sergey Ushakov
Zwei NICs mit zwei TCP-Sitzungen bedeuten, dass das OP entscheiden muss, welche TCP-Sitzung zuverlässiger ist.
Radio-Free-Europe
Nur um Missverständnisse zu vermeiden: Ich habe nie zwei TCP-Sitzungen gemeint. Die TCP-Sitzung sollte eine sein. Dies ist die Aufgabe der Router, sich um Redundanz und ein TCP-Verkehrsfailover ohne Verzögerung zu kümmern.
Sergey Ushakov
0

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!

glattbSE
quelle
klingt vielversprechend und passt zur Rechnung (obwohl nicht in Industriequalität), aber leider antwortet GitHub bereits mit 404 für dieses Projekt ... wissen Sie, was danach mit diesem Projekt passiert ist?
Sergey Ushakov
leider nicht. Möglicherweise müssen Sie sich direkt an die Autoren wenden.
SmoothbSE