Änderung Routingtabelle greift erst bei neuen Verbindungen

[mme]

Hallo,

es geht hier um folgendes Szenario. Über die Aktionstabelle wird bei Ausfall einer WAN-Verbindung dynamisch eine Gegenstelle in der Routingtabelle angepasst. Diese Lösung habe ich hier im Forum gefunden. Ich verwende sie, weil die Backup-Gegenstelle für bestimmten Datenverkehr permanent verwendet wird (per Routing-Tag), die Backuptabelle als einfacherer Lösungsansatz jedoch die Backupverbindung abbaut, wenn sie nicht mehr als Backup benötigt wird.

Nun zum Problem: Nach Umschalten der Gegenstelle in der Routingtabelle bleiben unter /Setup/IP-Router/Firewall/Connection-List Verbindungen mit der alten Gegenstelle als Source Route oder Destination Route bestehen. So kommt es z. B. nach einer Rückumschaltung nach einem Ausfall vor, dass Verbindungen weiter über die zweite, langsamere Gegenstelle laufen.

Kann man dagegen etwas tun, außer die komplette Connection-List zu leeren?

[Bernie137]

Hallo,

ja, ebenfalls über die Aktionstabelle, Ereignis Aufbau der Hauptverbindung und als Aktion die Routingtabelle wieder in den "Normalzustand" schreiben lassen.

vg Bernie

[backslash]

Hi Bernie137,

das funktioniert so nicht, da der Session-Eintrag ja trotzdem erhalten bleibt und auf die Backup-Verbindung zeigt...
Das einzige, was hier helften würde, wäre ein Trennen der Backup-Verbindung, da das auch zum Löschen der Session-Einträge führt.

@mme:
Ein Wechsel eine bestehenden Session auf eine andere Internet-Verbindung führt aber zum sofortigen Abbruch der Session, da sich deine IP-Adresse ändert und somit die Gegenseite deine Pakete nicht mehr annimmt... Daher ist es eigentlich besser, einfach damit zu leben, daß die Sessions weiter über die "Backup"-Verbindung laufen...

Gruß
Backslash

[mme]

Vielen Dank für die schnellen Antworten!

Ein Wechsel eine bestehenden Session auf eine andere Internet-Verbindung führt aber zum sofortigen Abbruch der Session, da sich deine IP-Adresse ändert und somit die Gegenseite deine Pakete nicht mehr annimmt... Daher ist es eigentlich besser, einfach damit zu leben, daß die Sessions weiter über die "Backup"-Verbindung laufen...

Ich hatte auch schon überlegt, ob das Verhalten aus dem von Dir genannten Grund sogar das bessere ist. Dagegen sprechen aus meiner Sicht die folgenden Argumente.

• Möglicherweise kommen manche Anwendungen, die über mehrere Sessions mit einem Kommunikationspartner Daten austauschen, nicht damit klar, wenn die Sessions über unterschiedliche Adressen laufen (zum einen über solche, die die Rückumschaltung vom Backup überlebt haben, zum anderen über neu aufgebaute). Vielleicht ist das aber auch eher ein theoretisches Problem. Ein konkreter Fall ist mir nicht bekannt. Es dürften ja eigentlich keine Probleme auftreten, die nicht auch beim Einsatz von Load Balancing auftreten würden.
• Die Daten werden weiterhin mit niedriger Geschwindigkeit übertragen (bei langsamerer Backup-Verbindung). Das habe ich bei einer TeamViewer-Verbindung erlebt.
• Das Verhalten ist aus Nutzersicht nur schwer nachvollziehbar.

Dafür spricht aus meiner Sicht noch das folgende Argument.

• Bei häufigeren Ausfällen bleiben Sessions bei der stabilen Verbindung und sind nicht von weiteren Ausfällen betroffen.

Für Anwendungen mit geringen Anforderungen an die Geschwindigkeit ist das Verhalten wahrscheinlich eher günstig und bei solchen mit höheren Anforderungen an die Geschwindigkeit potenziell problematisch.

[backslash]

Hi mme,

Möglicherweise kommen manche Anwendungen, die über mehrere Sessions mit einem Kommunikationspartner Daten austauschen, nicht damit klar, wenn die Sessions über unterschiedliche Adressen laufen (zum einen über solche, die die Rückumschaltung vom Backup überlebt haben, zum anderen über neu aufgebaute). Vielleicht ist das aber auch eher ein theoretisches Problem. Ein konkreter Fall ist mir nicht bekannt. Es dürften ja eigentlich keine Probleme auftreten, die nicht auch beim Einsatz von Load Balancing auftreten würden.

Hier wirfst du jetzt zwei Dinge zusammen: Beim den Loadbalancing werden immer wieder neue TCP-Sessions aufgemacht, die von unterschiedlichen IP-Adressen kommen. Da muß dann der Server anhand von z.B. Cookies feststellen, daß es die gleiche User-Session ist.
Hier ist es aber so, daß du eine bestehende TCP-Session umschalten willst - und genau das wird nicht funktionieren. Die Gegenseite wird die TCP-Pakete ablehnen, weil sie keine Session zu deiner neuen IP-Adresse hat. Das ganze wird in einen Timeout laufen und du mußt die Session neu starten - mit viel Glück bekommst du bei TCP ein RST-Paket zurück und die Session bricht sofort ab, statt in einen Timeout zu laufen.

Die Daten werden weiterhin mit niedriger Geschwindigkeit übertragen (bei langsamerer Backup-Verbindung). Das habe ich bei einer TeamViewer-Verbindung erlebt.

Du kommst sowieso nicht umhin, die Teamviewer-Session neu zu starten - aus eben dem oben genannten Grund. Und die neue Session wird dann wieder über die schnelle Leitung laufen. Die Frage ist letztendlich: willst du einen sofortigen Abbruch der Teamviewer-Session oder ist es nicht sinnvoller diese doch - wenn auch langsamer - solange weiterlaufen zu lassen, bist du sie manuell trennst und wieder neu aufbaust.

Das Verhalten ist aus Nutzersicht nur schwer nachvollziehbar.

In wie weit ist es schwer nachzuvollziehen, daß bestehende TCP-Sessions nicht abgebrochen werden, wenn das Ziel noch erreichbar ist? Das ist das allgemeine Verhalten der Firewall: Eine einmal aufgebaute Session bleibt solange erhalten, bis sie normal beendet wird (TCP FIN), sie herausaltert oder bis die von ihr genutzte WAN-Verbindung getrennt wird. Anders herum wäre es m.E. weniger nachvollziehbar...

Beim normalen Backup-Szenario (also mit Abbau der Backup-Verbindung) würde die Firewall die TCP-Session schließen und das nächste Paket würde zum Abbruch der Session auf deinem PC führen, was dich dann auch wieder dazu zwingt die Teamviewer-Session neu zu starten - ggf. würdest du dich dann aber über die abbrechende Teamviewer-Session beklagen...

Es bleibt also letztendlich keines deiner Kontra-Argumente übrig...

Gruß
Backslash

[mme]

Möglicherweise kommen manche Anwendungen, die über mehrere Sessions mit einem Kommunikationspartner Daten austauschen, nicht damit klar, wenn die Sessions über unterschiedliche Adressen laufen (zum einen über solche, die die Rückumschaltung vom Backup überlebt haben, zum anderen über neu aufgebaute). Vielleicht ist das aber auch eher ein theoretisches Problem. Ein konkreter Fall ist mir nicht bekannt. Es dürften ja eigentlich keine Probleme auftreten, die nicht auch beim Einsatz von Load Balancing auftreten würden.

Hier wirfst du jetzt zwei Dinge zusammen: Beim den Loadbalancing werden immer wieder neue TCP-Sessions aufgemacht, die von unterschiedlichen IP-Adressen kommen. Da muß dann der Server anhand von z.B. Cookies feststellen, daß es die gleiche User-Session ist.
Hier ist es aber so, daß du eine bestehende TCP-Session umschalten willst - und genau das wird nicht funktionieren. Die Gegenseite wird die TCP-Pakete ablehnen, weil sie keine Session zu deiner neuen IP-Adresse hat. Das ganze wird in einen Timeout laufen und du mußt die Session neu starten - mit viel Glück bekommst du bei TCP ein RST-Paket zurück und die Session bricht sofort ab, statt in einen Timeout zu laufen.

Dass bestehende TCP-Verbindungen einen Wechsel von einer zu einer anderen WAN-Verbindung nicht überleben, ist mir klar. Ich habe das Gefühl, dass wir aneinander vorbei reden. Deswegen versuche ich mal, mich etwas genauer auszudrücken. Ich habe mich auf den Fall bezogen, dass bestehende Sessions bei der gleichen WAN-Verbindung bleiben, also konkret z. B. das folgende Szenario:

• Die WAN-Verbindung 1 fällt aus. In der Routing-Tabelle wird sie durch die WAN-Verbindung 2 ersetzt.
• Ein Rechner A im lokalen Netz baut eine TCP-Verbindung zu einem Rechner B über das Internet auf. Die Session wird der WAN-Verbindung 2 zugeordnet.
• Die WAN-Verbindung 1 ist wieder verfügbar. WAN-Verbindung 2 wird in der Routing-Tabelle durch WAN-Verbindung 1 ersetzt.
• Rechner A (gleiche Anwendung wie zuvor) baut eine zweite TCP-Verbindung zu Rechner B auf. Die Session wird der WAN-Verbindung 1 zugeordnet.
• Jetzt gibt es zwei TCP-Verbindungen einer Anwendung auf Rechner A zu Rechner B, eine über WAN-Verbindung 1 und eine über WAN-Verbindung 2. Diese Konstellation ist es, die ich bei dem Load Balancer - Vergleich meinte. Dabei meine ich einen Load Balancer wie bei Lancom, der die Anfragen aus dem lokalen Netz auf mehrere WAN-Verbindungen verteilt. Die Befürchtung war, dass Rechner B nicht erkennt, dass es sich um die gleiche User-Session handelt, sondern z. B. die zweite TCP-Verbindung beendet, weil eine erste TCP-Verbindung von der Absender-IP-Adresse von Rechner A erwartet wird. Rechner A würde es dann vielleicht wieder mit einer neuen zweiten TCP-Verbindung versuchen, wieder ohne Erfolg. Es kann sein, dass das ein konstruierter Fall ist. Das habe ich ja auch schon oben geschrieben.

Die Daten werden weiterhin mit niedriger Geschwindigkeit übertragen (bei langsamerer Backup-Verbindung). Das habe ich bei einer TeamViewer-Verbindung erlebt.

Du kommst sowieso nicht umhin, die Teamviewer-Session neu zu starten - aus eben dem oben genannten Grund. Und die neue Session wird dann wieder über die schnelle Leitung laufen. Die Frage ist letztendlich: willst du einen sofortigen Abbruch der Teamviewer-Session oder ist es nicht sinnvoller diese doch - wenn auch langsamer - solange weiterlaufen zu lassen, bist du sie manuell trennst und wieder neu aufbaust.

Da stimme ich zu, dass das die Frage ist. Wenn man die Session von der Seite des Routers weiter laufen lässt, hat der Nutzer die Freiheit selbst zu bestimmen, wann er sie unterbrechen möchte. So hat er z. B. Möglichkeiten zu vermeiden, dass er durch eine Unterbrechung Arbeit wiederholen muss. Wenn er allerdings nicht weiß, dass er die Session neu starten muss, um die normale Geschwindkeit wiederherzustellen (und die WAN-Verbindung wieder für mögliche andere Zwecke frei zu machen), wird er vermutlich mit der niedrigen Geschwindigkeit weiterarbeiten. Auf diesen Fall bezieht sich das Argument der nierigeren Geschwindigkeit.

Das Verhalten ist aus Nutzersicht nur schwer nachvollziehbar.

In wie weit ist es schwer nachzuvollziehen, daß bestehende TCP-Sessions nicht abgebrochen werden, wenn das Ziel noch erreichbar ist? Das ist das allgemeine Verhalten der Firewall: Eine einmal aufgebaute Session bleibt solange erhalten, bis sie normal beendet wird (TCP FIN), sie herausaltert oder bis die von ihr genutzte WAN-Verbindung getrennt wird. Anders herum wäre es m.E. weniger nachvollziehbar...

Beim normalen Backup-Szenario (also mit Abbau der Backup-Verbindung) würde die Firewall die TCP-Session schließen und das nächste Paket würde zum Abbruch der Session auf deinem PC führen, was dich dann auch wieder dazu zwingt die Teamviewer-Session neu zu starten - ggf. würdest du dich dann aber über die abbrechende Teamviewer-Session beklagen...

Das Problem der Nachvollziehbarkeit sehe ich darin, für den nicht eingeweihten Nutzer zu verstehen, dass die Datenübertragung weiterhin langsam ist, obwohl die Haupt-WAN-Verbindung wieder verfügbar ist. Mit dem Nutzer meine ich nicht den Admin, der den Router konfiguriert, sondern den, der im lokalen Netz hinter dem Router an einem Rechner arbeitet. Der muss ja erstmal wissen, dass er die Session neu starten muss, damit es wieder schnell wird. Ein normaler Nutzer könnte sich das Umschalten z. B. so vorstellen wie bei einer Weiche bei Zügen. Wer sich das so vorstellt, dem wird es wahrscheinlich nicht unmittelbar einleuchten, warum manche Züge noch über die doppelt so lange Ersatzstrecke fahren, obwohl die Hauptstrecke schon wieder frei ist. Wenn die Empfängeradressen für das Routing im Internet nicht providerabhängig wären, märe das ja auch gar nicht nötig, oder?

Ich will damit nicht sagen, dass die Unterbrechung einer Session eine gute Sache ist. Mir erscheint es eher so, als wenn es bei dem ganzen Thema eher um das kleinere Übel geht statt um ein perfektes Verhalten. Perfekt fände ich es, wenn das Internet irgendwann sowas wie http://de.wikipedia.org/wiki/Locator/Id ... n_Protocol sprechen würde.

[backslash]

Hi mme,

über all das läßt sich wunderbar streiten, aber es gibt nunmal für beide Ansätze gute Argumente... Und wie ich schon schrieb: Würde die Session beendet, würdest du dich (oder auch ein Anderer) wahrscheinlich darüber beschweren...

Perfekt fände ich es, wenn das Internet irgendwann sowas wie http://de.wikipedia.org/wiki/Locator/Id ... n_Protocol sprechen würde.

nun, ja... das wäre dann die mittlerweile 5. Reinkarnation von Mobile-IP oder IP-Mobility oder HIP oder wie auch immer das in der Vergangenheit hieß... Es hat sich niemals durchgesetzt und wird es vermutlich auch in Zukunft nicht...

Gruß
Backslash