[fli4l] DSL Failover

[kay]

Am 28.11.2016 um 16:23 schrob Peter Schiefer:
> Am Mon, 28 Nov 2016 15:32:13 +0100 schrieb Markus Homburg:
> 
>>> Ich muss zugeben das ich es nicht verfolgt habe ob/was FLI da jetzt
>>> kann. Bei DSL-Ausfall manuell (per imonc/imond) auf einen ISDN oder
>>> gar
>>> Modem-Link runter zu schalten - das ging schon früher!
>>
>> Ich bin verwundert, dass außer mir niemand das gerne hätte :roll:

@Markus: Dann ENTwundere dich. Mich interessiert es auch. Das heißt aber
nicht das ich es sofort brauche. Denn ich bin aktuell in der Glücklichen
Lage mindestens 3 unterschiedlich umständliche Alternativen zu haben -
für den Ausfall-Fall.

>> Konkret fände ich es gut, wenn man z.B. einen LTS Stick per USB
>> ansteckt und nur im Ausfall des DSLs  der Traffic über LTE
>> abgewickelt wird. Sobald DSL wieder zur Verfügung steht, soll wieder

Da LTE wohl in den meisten Fällen am Ort mehr Leistung bringt werden
viele das wohl eher ungekehrt haben wollen. D.h. Eine wählbare
Priorisierung der Verbindungen ist nötig. Das KANN eine einfache
änderung der Defaultroute sein - wenn man KEIN Multilink-ppp benutzt.


> mehrere Internet-Zugangswege sind mit fli4l 4.0 (Enwicklerversion) möglich
> - sogeanannte Cicuits 

Gleichzeitig (Multilink) oder abgestuft nach Priorität und verfügbarkeit?

> 
>> automatisch zurück gewechselt werden. Die Kür wäre es natürlich,
> 
> das Themas ist, wie erkennt man 100% sicher, wann der Weg ausagefallen ist
> und man auf einen anderen wechselt.

Dazu standen in dem Artikel zwei hinweise. pfsense benutzt nur ping für
jedes gateway, cisco dagegen die Sprachqualität eines simulierten
VoIP-Calls. Dabei ging es aber eher um Features eines guten Loadbalancers.

Ein IpFire hat mich am Sonntag überrascht mit einem "no response to 5
echos" und danach die EINE DSL-Verbindung neu aufgebaut. Ich kam grad
rein, sah die DSL-Led blinken und wieder dauerleuchten. Da war aber
alles schon wieder gut.

Sind im RRDTOOL-Paket nicht standardmäßig ein paar ziele für die
ping-graphen eingetragen? fli4l.de ist da IMHO einer von.



>> wenn 
>> die Connections nicht abreißen. Aber es würde schon vollkommen
>> reichen, wenn 
> 
> da bei verschieden Wegen sich die WAN-IP - somit also die Source-IP der
> Verbindung ändert reissen die connection definitiv ab.

Das muss aber nicht sein. Multilink-ppp braucht m.W. zwangsläufig eine
Gegenstelle beim Provider die hier nicht gegeben ist. Aber ein
loadbalancer kann die sessions auf mehrere (verfügbare) WAN-Verbindungen
aufteilen (wenn man es so einsetzen will) und damit mehr als einen Link
"bündeln".

Und im Artikel heißt es das Radware bei seinen Produkten einen "no new
session" Mode kennt bei dem ein Gateway zwar aktiv bleibt, bei der
wegewahl aber nicht mehr berücksichtigt wird. Damit enden die sessions
darüber irgendwann bis es idle ist und man es deaktivieren kann.

Ich denke das müsste über den paketfilter, routing-prioritäten/Metrik
o.ä. erreichbar sein.


>> der User nach ein paar Sekunden wieder Zugriff auf das Internet hätte,
>> ohne das er aktiv etwas tun muss.

Das ist hier mom. so gelöst.

On Error
1. Verbinde mit Nachbar-WLAN.
 On Error
  Starte ISDN-Router.
   On Error
    Krame Analog-Modem raus.
     On Error
      Prüfe Stromversorgung/Offline-Modus!
:)

Kay
-- 
Posted via SN