Load-Balancer + Policy-based Routing mit Fallback?

[Maurice]

Moin,

Folgende Situation: Dual-WAN an einem 1781VA (LCOS 10.30). IPv4-Load-Balancing ist konfiguriert und funktioniert. Default-Route für Routing-Tag 0 geht über den Load-Balancer.
Bestimmte Rechner im LAN sollen bevorzugt WAN1 verwenden. Dazu habe ich eine zweite Default-Route angelegt (Routing-Tag 123 via WAN1). Mittels Firewall-Regel wird das Routing-Tag für alle Pakete, die von den betroffenen Rechnern kommen in 123 geändert. Funktioniert soweit.

Wenn nun aber WAN1 ausfällt sind diese Rechner offline. Der Wunsch ist, dass in diesem Fall WAN2 verwendet wird. Kennt jemand eine clevere Methode um das umzusetzen?

Grüße

Maurice

[ecox]

Hallo,

schreib die in der Aktionstabelle einen Eintrag, der bei Abbruch von WAN1 die Firewall-Rule auf das Tag von WAN anpasst, fertig, natürlich noch das Fallback auf WAN1 in die Aktionstabelle...

Grüße
ecox

[GrandDixence]

Für Aktionstabellen-Beispiele siehe:
lancom-systems-router-aeltere-modelle-z ... tml#p75861

[Maurice]

Danke euch zwei. Da ich bisher weder die Aktionstabelle noch die Konfiguration via Konsole verwendet habe: Passt das so?

Code: Alles auswählen

Name: WAN1_ABBRUCH
Gegenstelle: WAN1
Verbindungs-Ereignis: Abbruch mit Fehler
Aktion: exec:set /Setup/IP-Router/Firewall/Regel-Tabelle/MEINE_FW_REGEL/Rtg-Tag 0

Name: WAN1_AUFBAU
Gegenstelle: WAN1
Verbindungs-Ereignis: Aufbau
Aktion: exec:set /Setup/IP-Router/Firewall/Regel-Tabelle/MEINE_FW_REGEL/Rtg-Tag 123

WAN1 verwendet PPPoE (Haltezeit 9999) und läuft über das interne VDSL-Modem. Verstehe ich das richtig, dass ein Eintrag in die Polling-Tabelle daher nicht erforderlich ist?

Grüße

Maurice

[ecox]

Danke euch zwei. Da ich bisher weder die Aktionstabelle noch die Konfiguration via Konsole verwendet habe: Passt das so?

Code: Alles auswählen

Name: WAN1_ABBRUCH
Gegenstelle: WAN1
Verbindungs-Ereignis: Abbruch mit Fehler
Aktion: exec:set /Setup/IP-Router/Firewall/Regel-Tabelle/MEINE_FW_REGEL/Rtg-Tag 0

Name: WAN1_AUFBAU
Gegenstelle: WAN1
Verbindungs-Ereignis: Aufbau
Aktion: exec:set /Setup/IP-Router/Firewall/Regel-Tabelle/MEINE_FW_REGEL/Rtg-Tag 123

Sieht gut aus, aber sehr ungewöhnlich auf Deutsch also ja, wenn der Pfad so passt, gut , bzw wenn du das auf der CLI auch mal getestet hast, ob der Befehl gefressen wird...

WAN1 verwendet PPPoE (Haltezeit 9999) und läuft über das interne VDSL-Modem. Verstehe ich das richtig, dass ein Eintrag in die Polling-Tabelle daher nicht erforderlich ist?

Wenn du über das interne VDSL-Modem online gehst, hast du ja da noch LCP, das übernimmt für dich "sozusagen" das polling ^^

Grüße
ecox

[Maurice]

Ich habe die Bezeichnungen aus der Doku (LCOS-Menüreferenz) übernommen. Aber Du hast Recht, die Konsolensprache ist Englisch. Dort heißt es "Rules" statt "Regel-Tabelle", sonst identisch.
Habe mich mal auf der Konsole umgesehen, aber so ganz klar ist es mir noch nicht. Ich möchte ja keine neue Firewall-Regel anlegen, sondern nur einen einzelnen Wert einer vorhandenen Regel ändern ("setze Rtg-tag in MEINE_FW_REGEL auf 123"). Die Werte haben ja alle Namen und Nummern, aber ich verstehe nicht wie man die referenziert. Muss man wirklich immer alle Werte angeben? Und alleine deren Reihenfolge sorgt für die richtige Zuordnung? Und mit "*" übernimmt man die vorhandenen Werte? Also in der Art:

Code: Alles auswählen

exec:set /Setup/IP-Router/Firewall/Rules MEINE_FW_REGEL * * * * * * * * * * 123 *

Uh-oh... Da kann ja auch absolut gar nichts schief gehen.

Grüße

Maurice

[backslash]

Hi Maurice

Code: Alles auswählen

exec:set /Setup/IP-Router/Firewall/Rules MEINE_FW_REGEL * * * * * * * * * * 123 *

Uh-oh... Da kann ja auch absolut gar nichts schief gehen.

Zwischen "Rules" und "MEINE_FW_REGEL" mußt du einen / einfügen, weil "MEINE_FW_REGEL" noch zum Pfad gehört.
Die Sternchen brauchst du nicht zu machen, weil du alle Spalten banamt ansteuern kannst, indem du ihren Namen in geschweifte Klammern setzt. In deinem Fall lautet die Aktion also

Code: Alles auswählen

exec:set /Setup/IP-Router/Firewall/Rules/MEINE_FW_REGEL {rtg-tag} 123

In der Aktion WAN1_ABBRUCH sollest du als Ereignis statt "Abbruch" besser "Ende (Abbau oder Abbruch)" wählen, weil du sonst ggf. doch wieder in Fälle rennen könntest, in denen die Regel nicht umgeschaltet wird.

Gruß
Backslash

[ecox]

Hallo Maurice,

da du relativ frisch im LANCOM Business bist, kommt mir jedenfalls so vor , hier mal ein Link für dich der mir zu Anfangszeiten viel geholfen hat und vor allem viel Licht ins dunkle gebracht hat

Das was Backslash erwähnt hat mit den {}-Klammern - ist dort auch sehr gut beschrieben

https://www2.lancom.de/kb.nsf/bf0ed2a4d ... enDocument

Viel Spaß
ecox

[Maurice]

Danke @backslash, genau das habe ich gesucht! Teste ich dann nachher mal wenn die Kollegen weg sind.
Habe absichtlich nur "Abbruch" gewählt, da ich davon ausging, dass mit "Ende (Abbau oder Abbruch)" die Aktion auch beim Reboot ausgelöst wird. Ist das so?

Danke @ecox, den KB-Link habe ich mir gleich gebookmarkt! Ich bin nicht im "Lancom-Business", sondern Endanwender (betreue unser überschaubares Netzwerk). Bisher bin ich gut mit LANconfig, LANmonitor und Webinterface ausgekommen und habe da mittlerweile einen einigermaßen guten Überblick. Mit der LCOS-Konsole musste ich mich einfach noch nicht näher auseinanderzusetzen.

Grüße

Maurice

[backslash]

Hi Maurice,

Habe absichtlich nur "Abbruch" gewählt, da ich davon ausging, dass mit "Ende (Abbau oder Abbruch)" die Aktion auch beim Reboot ausgelöst wird. Ist das so?

prinzipiell ja, aber wo ist das Problem? Nach dem Reboot wird die Verbindung ja auch wieder aufgebaut und somit wird die Firewall-Regel von der Aufbau-Aktion auch wieder zurückgeschaltet...

Gruß
Backslash

[Maurice]

Nach dem Reboot wird die Verbindung ja auch wieder aufgebaut und somit wird die Firewall-Regel von der Aufbau-Aktion auch wieder zurückgeschaltet...

Hehe... ja, aber. Nach einem Router-Reboot kommt WAN2 (externes Modem) immer zuerst hoch. Das interne VDSL-Modem (WAN1) muss ja erstmal booten und synchronisieren. Die betroffenen Rechner würden daher ca. zwei Minuten über WAN2 geroutet werden und dann wieder über WAN1. Wenn man in diesem Zeitfenster z. B. ein VoIP-Telefonat startet ist die Verbindung gleich wieder weg. Das scheint mir nicht sinnvoll, dann besser zwei Minuten länger offline.

Grüße

Maurice

[Maurice]

Es funktioniert! Fast.

Das Setzen des Routing-Tags auf 0 bei WAN1-Abbruch klappt, anschließend wird über den Load-Balancer (und damit WAN2) geroutet.

Bei WAN1-Aufbau werden das Routing-Tag auf 123 zurückgesetzt und neue Verbindungen wieder über WAN1 geroutet. Aber: Offene TCP-Verbindungen bleiben bestehen (über WAN2). Dadurch bekommt man genau die Probleme, die das Client-Binding beim Load-Balancer verhindern soll. Ich habe dann eine dritte Default-Route angelegt (Routing-Tag 321 via WAN2) und in der WAN1-Abbruch-Aktion das Routing-Tag von 0 auf 321 geändert. Ändert aber nichts am Verhalten.

Noch eine Idee?

Grüße

Maurice

[cpuprofi]

Hallo Maurice,

als Beispiel:

WAN1 = T-COM mit Routing-Tag 10

WAN2 = KD mit Routing-Tag 20

Default-Route mit Routing-Tag 0

So weit so gut, dann in der Actions-Tabelle bei der Default-Route (0) nicht das Routing-Tag ändern, sondern die Route zur Gegenstelle, also T-COM oder KD.

Somit kannst Du sowohl Routen direkt ansprechen, als auch Deinen selbstgebauten Load-Balancer nutzen.

Grüße
Cpuprofi

[backslash]

Hi Maurice,

Aber: Offene TCP-Verbindungen bleiben bestehen (über WAN2). Dadurch bekommt man genau die Probleme, die das Client-Binding beim Load-Balancer verhindern soll.

Wieso sollte das LANCOM auch offene Verbindungen trennen? Und vor allem: woher soll es wissen, welche es trennen soll...

Da hast du eigentlich nur eine einzige Möglichkeit: Sobald die bevorzugte Verbindung (WAN2) wieder hochkommt und du die Firewallregel umtaggst, mußt du die andere WAN-Verbindung hart trennen (do /other/manual/disconnect WAN1). Das löscht dann die Sessions, die auf WAN1 laufen... Dann darfst du aber nur Rechner haben, die WAN2 bevorzugen, denn hättest du auch Rechner die WAN1 bevorzugen sollen, würde das in einem Dauer-Ping-Pong von Verbindungsabbauten enden...

Aber unabhängig von solch kruden Lösungen hast du das Problem des Adreßwechsels doch auch, wenn die bevorzugte Leitung wegfällt und die Verbindungen auf die andere Leitung gezwungen werden. Wenn du das alles nicht haben willst, dann bleiben dir nur zwei Möglichkeiten:

• Du bevorzugst rein gar nichts und verwendest Client-Binding
• Du verzichtest auf das Umschalten und lebst damit, daß die betroffenen Rechner "offline" sind, solange die bevorzugte Leitung down ist

Gruß
Backslash

[Maurice]

Hi Backslash!

Wieso sollte das LANCOM auch offene Verbindungen trennen? Und vor allem: woher soll es wissen, welche es trennen soll...

Ich ging davon aus, dass durch das Ändern des Routing-Tags in der Firewall-Regel sofort alle matchenden Pakete über das andere WAN geroutet werden. Offene Verbindungen würden dann zwangsläufig abbrechen. Das scheint aber nicht der Fall zu sein.

Da hast du eigentlich nur eine einzige Möglichkeit: Sobald die bevorzugte Verbindung (WAN2) wieder hochkommt und du die Firewallregel umtaggst, mußt du die andere WAN-Verbindung hart trennen (do /other/manual/disconnect WAN1). Das löscht dann die Sessions, die auf WAN1 laufen... Dann darfst du aber nur Rechner haben, die WAN2 bevorzugen, denn hättest du auch Rechner die WAN1 bevorzugen sollen, würde das in einem Dauer-Ping-Pong von Verbindungsabbauten enden...

Anders herum: Die bevorzugte Verbindung für einige Rechner ist WAN1 und es gibt keine Rechner, die WAN2 bevorzugen. Aber ansonsten klingt das plausibel und so werde ich es jetzt testen. Der Nachteil ist natürlich, dass dann unnötigerweise die Verbindungen aller Rechner abgebrochen werden. Aber das ist das kleinere Übel.

Aber unabhängig von solch kruden Lösungen hast du das Problem des Adreßwechsels doch auch, wenn die bevorzugte Leitung wegfällt und die Verbindungen auf die andere Leitung gezwungen werden.

Der "harte" Adresswechsel ist viel weniger problematisch als das Verteilen von Verbindungen eines einzelnen Rechners auf zwei WANs. Beispiel: Ein Rechner hält eine SIP-über-TCP-Verbindung offen (über WAN2, da WAN1 gerade down ist). Dann kommt WAN1 wieder hoch und das Routing wird entsprechend geändert. Dann wird ein Anruf getätigt. Das SIP-Signaling geht über die noch offene Verbindung über WAN2, die RTP-Pakete werden aber über WAN1 geroutet... Nicht ausgedacht; heute hatten wir tatsächliche eine kurze Unterbrechung von WAN1 (wenige Minuten). Anschließend kamen prompt Beschwerden über "ich höre nix beim Telefonieren". Das renkt sich dann auch von selbst nicht wieder ein. Einmal kurz WAN2 getrennt und es ging wieder.

Du bevorzugst rein gar nichts und verwendest Client-Binding

Funktioniert das z. B. mit dem SIP/RTP-Szenario zuverlässig? Einer der Gründe, warum ich das "Spezial-Routing" für einige Rechner überhaupt mache ist, dass ich dem Client-Binding für mehr als HTTP(S) nicht wirklich traue.

Danke & Grüße

Maurice