Hallo,
ich hatte hier heute einen eigenartigen Fall und bin der Meinung, dass das Verhalten ein durchaus schwerwiegender Bug ist.
So eine Konfig lebt ja mitunter, d. h. ist Änderungen unterworfen, muss für kurze Zeiträume übergangsweise angepasst werden und enthält evt. auch alte Konfigurationsbestandteile. So kann man z. B. Gegenstellen definieren wie man will, so lange diese nicht in der IP-Routing-Tabelle auftauchen, sind sie zwar Bestandteil der Konfig und können jederzeit zum Einsatz kommen, aber sie werden aktuell eben nicht verwendet und bleiben somit aktuell unberücksichtigt. Nicht so ist das allerdings mit dem Load-Balancer. Selbst wenn dieser nicht in der IP-Routing-Tabelle angesprochen wird, kommt er zum Einsatz. Sobald eine der beiden Verbindungen aufgebaut ist, folgen im Syslog Ausschriften wie "Successfully connected to peer WIZ_LOADBAL" oder "Start load balancing for peer WIZ_LOADBAL".
Im konkreten Fall hatte jemand ohne Erfahrung einen LANCOM 1781VA-4G (seinerzeit 10.20-RU1, aktuell 10.20-RU3) eingerichtet. DSL-Verbindung konfiguriert, LTE-Verbindung konfiguriert. Bei letzterer muss beim Assistenten wohl Ersetzen der Default-Route durch Loadbalancer ausgewählt worden sein. Was aber eigentlich nicht sinnvoll war im konkreten Fall. Nachdem dann hier und da Probleme auftraten, habe ich telefonisch dazu geraten vom Load-Balancer Abstand zu nehmen, da der hier auch gar nicht sinnvoll ist. Vielmehr sollten zwei getaggte Routen angelegt werden, auf die dann per Policy Based Routing zurückgegriffen werden kann. Es gab also die Default-Route mit Tag 0 für DSL und zwei getaggte Default-Routen für DSL und LTE. Allerdings wurde der Load-Balancer nicht ausgeschaltet. Das hat jetzt dazu geführt, dass die DSL-Verbindung nicht mehr aufgebaut wurde, als sie heute nach 2 Monaten mal getrennt wurde. Es führte kein Weg rein. Zudem hatte er sich in die Fallstricke eines angelegten Admins und der 10.20 begeben, so dass am Ende so gut wie gar nichts mehr ging. Es war folgende Situation: Die LTE-Verbindung war aufgebaut, die DSL-Verbindung kam nicht wieder hoch, die Einwahl blieb beim Benutzernamen hängen, PPP-Trace liegt vor. Egal was, Neustart usw., es änderte sich nichts. Die Probleme im Trace beginnen wie geschrieben ab der Stelle der Übergabe des Benutzernamens (@t-online.de). Darauf kommt anscheinend keine Antwort, ich vermute sie kommt jedoch, wird aber im Gerät nicht richtig zugeordnet. Sobald der Load-Balancer ausgeschaltet/deaktiviert wird, funktioniert sofort die Einwahl. Die Konfiguration mit dem eingeschalteten Load-Balancer ist definitiv nicht schön, aber dass sie so falsch ist und Auswirkungen auf den Aufbau anderer Verbindungen hat, ist schon sehr heftig. Nach Angaben des Kunden entstand durch die ganze Sache natürlich ein Schaden. Gut, der hätte jetzt natürlich verhindert werden können, wenn man ein wenig Geld investiert hätte und das Gerät von jemandem einrichten lassen hätte, der mit den Geräten Erfahrung hat...
Gibt es hierzu eine Meinung? Von Backslash vielleicht?
Vielen Dank und viele Grüße,
Jirka
Loadbalancer verhindert PPP-Einwahl
Moderator: Lancom-Systems Moderatoren
-
- Beiträge: 3236
- Registriert: 12 Jan 2010, 14:10
Re: Loadbalancer verhindert PPP-Einwahl
Hi Jirka,
gibt es vielleicht einen Zusammenhang mit https://www2.lancom.de/kb.nsf/b8f10fe56 ... enDocument ?
Gruß Dr.Einstein
gibt es vielleicht einen Zusammenhang mit https://www2.lancom.de/kb.nsf/b8f10fe56 ... enDocument ?
Gruß Dr.Einstein
Re: Loadbalancer verhindert PPP-Einwahl
Hi Jirka,
was soll ich dazu sagen... Der Loadbalancer hat erstmal nichts mit der jeweiligen Einwahl als solches zu tun - die Einwahlen ind vollkommen unabhängig voneinander. Der Loadbalancer ist erstmal eine virtuelle Klammer um die Verbindungen, damit die gemeinsam aufgebaut werden können (-> wenn eine aufgebaut wurde, werden die anderen nachgezogen - wie du ja selbst schin bemerkt hast). Ansonsten dient er nur dazu die Sessions der Firewall auf die einzelnen Kanäle zu verteilen.
Es gab in der 10.20 bis zur RU3 "nur" das Problem, daß es einen Deadlock zwischen Loadbalancer-Selektor und Kontentfilter gab - aber auch der sollte die PPP-Verhandlung nicht beeiträchtigen, da er "nur" das Routing lahmgelegt hat... In der RU3 ist das aber behoben
BTW: Ob eine Antwort vom PPP-Einwahlserver kam oder nicht, kannst du im VDSL-Data-Trace sehen - da mußt du keine Vermutungen anstellen
Gruß
Backslash
was soll ich dazu sagen... Der Loadbalancer hat erstmal nichts mit der jeweiligen Einwahl als solches zu tun - die Einwahlen ind vollkommen unabhängig voneinander. Der Loadbalancer ist erstmal eine virtuelle Klammer um die Verbindungen, damit die gemeinsam aufgebaut werden können (-> wenn eine aufgebaut wurde, werden die anderen nachgezogen - wie du ja selbst schin bemerkt hast). Ansonsten dient er nur dazu die Sessions der Firewall auf die einzelnen Kanäle zu verteilen.
Es gab in der 10.20 bis zur RU3 "nur" das Problem, daß es einen Deadlock zwischen Loadbalancer-Selektor und Kontentfilter gab - aber auch der sollte die PPP-Verhandlung nicht beeiträchtigen, da er "nur" das Routing lahmgelegt hat... In der RU3 ist das aber behoben
BTW: Ob eine Antwort vom PPP-Einwahlserver kam oder nicht, kannst du im VDSL-Data-Trace sehen - da mußt du keine Vermutungen anstellen
Gruß
Backslash