4
Fallback WAN mit Bintec RS120
Hallo,
ich bin neu hier und komme gleich mit einer wohl recht einfachen Problemstellung ums Eck, die sich dann aber im Detail doch recht kniffelig ist. Ich hoffe der eine oder andere Spezialist hat entsprechenden Input für mich.
Worum geht es?
Tausendfach schon hier besprochen, ich habe schon einiges dazu gelesen und habe hier auch schon die entsprechende Antwort gefunden. Allerdings tritt dabei am Ende ein unschönes Problem auf, dazu später. Zunächst mal die Problemstellung.
Es soll über eine 2. WAN Leitung ein redundantes WAN aufgebaut werden. Dabei soll die 1. WAN Verbindung primär genutzt werden, die 2. WAN Verbdindung dient als Backup/Fallbackk, wenn die Primärverbindung versagt. Wenn die Primärverbindung wieder steht, soll diese dann auch wieder wie vorher genutzt werden. Das Umschalten sollte dabei vollautomatisch erfolgen.
Folgende Architektur/Geräte sind vorhanden:
1. WAN (primär) über Kabelmodem und daran angeschlossener FritzBox 4020 als Zugangsrouter.
2. WAN (Failback) über ADSL mit FritzBox 7360 als Zugangsrouter.
HP 1920 24G als Hauptswitch/Router für das LAN
Bintec RS120 als Verknüpfungsrouter zwischen den beiden FritzBoxen und dem Hauptswitch
Betrachtet werden soll nur das Zusammenspiel zwischen Bintec und den Fritzboxen, damit am Ende aus dem Bintec das raus kommt, was ich gerne haben möchte.
So sieht das auf dem Reißbrett aus:
FritzBox 1 hat die IP 192.168.10.1
FritzBox 2 hat die IP 192.168.20.1
Die Bintec hört auf die IP 10.0.0.1
An Switchport 1 der Bintec hängt FritzBox 1, Interface 192.168.10.0 mit der IP 192.168.10.254.
An Switchport 2 der Bintec hängt FritzBox 2, Interface 192.168.20.0 mit der IP 192.168.20.254.
Die anderen Switchports sind auf dem Interface 10.0.0.0 und machen DHCP
Stöpselt man das zusammen, dann erhalte ich folgende funktionierte Konstellation mit folgendem relevanten Routing:
default route 0.0.0.0, Netmask 0.0.0.0 destination 192.168.10.1, Metrik 1
default route 0.0.0.0, Netmask 0.0.0.0 destination 192.168.20.1, Metrik 2
Das funktioniert und wenn ich einen traceroute mache, dann erhalte ich auch wie zu erwarten die 1. FritzBox über 192.168.10.1 als letzten Hop ins WAN. Trenne ich diese FritzBox, dann ist wie zu erwarten der Fallbackfall eingetreten und das ganze geht über die 2. Fritzbox, was man am traceroute auch sieht. Da ist dann der letzte Hop ins WAN 192.168.20.1
Perfekt, denkste.... nun kommt das feine Detail, was ich bisher zu sagen wir mal 80% habe lösen können, auch mit dem Input von hier.
Das Problem ist, wie man sich denken kann, dass seltenst die FritzBox als solche Ausfällt, sondern eher die WAN Verbindung abbricht. Damit ist die FritzBox ganz normal erreichbar und die Fallbackroute greift nicht, da der Bintec Router zunächst keinen Fehlerfall feststellt und damit die default route mit Metrik 1 aktiv bleibt.
Selbst wenn beide default routen auf derselben Metrik stehen, spielt das keine Rolle.
Damit kommen wir zu dem netten Unterpunkt Überwachung in dem Bintec. Mit ist klar, dass man hier nur aktiv herausfinden kann, was Sache ist. Also muss man eben Pingen. Ist ja auch so hier zu lesen in Bezug auf Mikrotik und anderen. Es gibt auch eine Software dafür, die eigens das machen soll. Also geht das. Nun hat der kleine Bintec ja auch so was an Bord. Also habe ich eine Überwachung eingerichtet, welche in 30 Sekunden intervallen einen Ping nach 8.8.8.8 absetzt. Sobald 8.8.8.8 nicht mehr erreichbar ist wird das Interface 192.168.10.0 heruntergefahren und damit greift automatisch der Fallbackfall und der Verkehr geht über die 2. Fritzbox 192.168.20.1. Auch das zurückschalten funktioniert, nur eben das ist nun der Knackpunkt und hier hänge ich.
Der Bintec schaltet grundsätzlich nach dem 30 Sekunden Intervall für ebenfalls 30 Sekunden auf die tote 192.168.10.1 Route. Das habe ich mit unterschiedlichen Intervallen geprüft.
Pingintervall 10 Sekunden: 10 Sekunden Fallback, 10 Sekunden die tote Route.
Pingintervall 60 Sekunden: 60 Sekunden Fallback, 60 Sekunden die tote Route.
Wenn die 192.168.10.1 steht, dann geht der Verkehr dauerhaft auch darüber. Es wird also im "Normalbetrieb" nicht zwischen beiden Routen hin- und hergeschaltet, sondern wirklich nur im Fallbackfall. Tritt dann der Fallbackfall ein, schaltet die Kiste immer wieder zwischen der 192.168.10.1 (die ja tot ist) und der 192.168.20.1 um. Nun die Frage: Wie bring ich der Kiste bei, dass das so nicht läuft?
Es scheint offensichtlich zu sein, dass der Bintec am Ende des Intervalls zur Prüfung der 192.168.10.1 Route darauf zurückschaltet und pingt. Das ist ja auch OK. Nur warum braucht es dann wiederum ein 2. Intervall, damit auf die Fallbackroute 192.168.20.1 geschaltet wird und nicht gleich, denn die Pings laufen ja weiterhin ins Leere. Ich hoffe jemand weiß dazu Rat.
Was ich auch noch nebenbei andenke ist, die 1. FritzBox per SNMP abfrage, ob denn eine WAN Verbindung besteht. Doch wie übergebe ich das Ergbnis dann dem Bintec und wie kann ich da dann darauf reagieren? Auch könnte es sein, dass das Kabelmodem abstürzt und die FritzBox dennoch der Meinung ist, dass eine Verbindung besteht oder eben im Kabelnetz selbst der Hund begraben liegt. Die Pingmethode erscheint mir bislang als die beste Prüfmethode hierfür. Daher wäre ich sehr glücklich, wenn jemand hier einen Tip/Lösung zu dem oben geschilderten Problemchen hat. Danke und schöne Weihnachten.
PS:
Achso.... alle Geräte haben die aktuelle Firmware drauf.
ich bin neu hier und komme gleich mit einer wohl recht einfachen Problemstellung ums Eck, die sich dann aber im Detail doch recht kniffelig ist. Ich hoffe der eine oder andere Spezialist hat entsprechenden Input für mich.
Worum geht es?
Tausendfach schon hier besprochen, ich habe schon einiges dazu gelesen und habe hier auch schon die entsprechende Antwort gefunden. Allerdings tritt dabei am Ende ein unschönes Problem auf, dazu später. Zunächst mal die Problemstellung.
Es soll über eine 2. WAN Leitung ein redundantes WAN aufgebaut werden. Dabei soll die 1. WAN Verbindung primär genutzt werden, die 2. WAN Verbdindung dient als Backup/Fallbackk, wenn die Primärverbindung versagt. Wenn die Primärverbindung wieder steht, soll diese dann auch wieder wie vorher genutzt werden. Das Umschalten sollte dabei vollautomatisch erfolgen.
Folgende Architektur/Geräte sind vorhanden:
1. WAN (primär) über Kabelmodem und daran angeschlossener FritzBox 4020 als Zugangsrouter.
2. WAN (Failback) über ADSL mit FritzBox 7360 als Zugangsrouter.
HP 1920 24G als Hauptswitch/Router für das LAN
Bintec RS120 als Verknüpfungsrouter zwischen den beiden FritzBoxen und dem Hauptswitch
Betrachtet werden soll nur das Zusammenspiel zwischen Bintec und den Fritzboxen, damit am Ende aus dem Bintec das raus kommt, was ich gerne haben möchte.
So sieht das auf dem Reißbrett aus:
FritzBox 1 hat die IP 192.168.10.1
FritzBox 2 hat die IP 192.168.20.1
Die Bintec hört auf die IP 10.0.0.1
An Switchport 1 der Bintec hängt FritzBox 1, Interface 192.168.10.0 mit der IP 192.168.10.254.
An Switchport 2 der Bintec hängt FritzBox 2, Interface 192.168.20.0 mit der IP 192.168.20.254.
Die anderen Switchports sind auf dem Interface 10.0.0.0 und machen DHCP
Stöpselt man das zusammen, dann erhalte ich folgende funktionierte Konstellation mit folgendem relevanten Routing:
default route 0.0.0.0, Netmask 0.0.0.0 destination 192.168.10.1, Metrik 1
default route 0.0.0.0, Netmask 0.0.0.0 destination 192.168.20.1, Metrik 2
Das funktioniert und wenn ich einen traceroute mache, dann erhalte ich auch wie zu erwarten die 1. FritzBox über 192.168.10.1 als letzten Hop ins WAN. Trenne ich diese FritzBox, dann ist wie zu erwarten der Fallbackfall eingetreten und das ganze geht über die 2. Fritzbox, was man am traceroute auch sieht. Da ist dann der letzte Hop ins WAN 192.168.20.1
Perfekt, denkste.... nun kommt das feine Detail, was ich bisher zu sagen wir mal 80% habe lösen können, auch mit dem Input von hier.
Das Problem ist, wie man sich denken kann, dass seltenst die FritzBox als solche Ausfällt, sondern eher die WAN Verbindung abbricht. Damit ist die FritzBox ganz normal erreichbar und die Fallbackroute greift nicht, da der Bintec Router zunächst keinen Fehlerfall feststellt und damit die default route mit Metrik 1 aktiv bleibt.
Selbst wenn beide default routen auf derselben Metrik stehen, spielt das keine Rolle.
Damit kommen wir zu dem netten Unterpunkt Überwachung in dem Bintec. Mit ist klar, dass man hier nur aktiv herausfinden kann, was Sache ist. Also muss man eben Pingen. Ist ja auch so hier zu lesen in Bezug auf Mikrotik und anderen. Es gibt auch eine Software dafür, die eigens das machen soll. Also geht das. Nun hat der kleine Bintec ja auch so was an Bord. Also habe ich eine Überwachung eingerichtet, welche in 30 Sekunden intervallen einen Ping nach 8.8.8.8 absetzt. Sobald 8.8.8.8 nicht mehr erreichbar ist wird das Interface 192.168.10.0 heruntergefahren und damit greift automatisch der Fallbackfall und der Verkehr geht über die 2. Fritzbox 192.168.20.1. Auch das zurückschalten funktioniert, nur eben das ist nun der Knackpunkt und hier hänge ich.
Der Bintec schaltet grundsätzlich nach dem 30 Sekunden Intervall für ebenfalls 30 Sekunden auf die tote 192.168.10.1 Route. Das habe ich mit unterschiedlichen Intervallen geprüft.
Pingintervall 10 Sekunden: 10 Sekunden Fallback, 10 Sekunden die tote Route.
Pingintervall 60 Sekunden: 60 Sekunden Fallback, 60 Sekunden die tote Route.
Wenn die 192.168.10.1 steht, dann geht der Verkehr dauerhaft auch darüber. Es wird also im "Normalbetrieb" nicht zwischen beiden Routen hin- und hergeschaltet, sondern wirklich nur im Fallbackfall. Tritt dann der Fallbackfall ein, schaltet die Kiste immer wieder zwischen der 192.168.10.1 (die ja tot ist) und der 192.168.20.1 um. Nun die Frage: Wie bring ich der Kiste bei, dass das so nicht läuft?
Es scheint offensichtlich zu sein, dass der Bintec am Ende des Intervalls zur Prüfung der 192.168.10.1 Route darauf zurückschaltet und pingt. Das ist ja auch OK. Nur warum braucht es dann wiederum ein 2. Intervall, damit auf die Fallbackroute 192.168.20.1 geschaltet wird und nicht gleich, denn die Pings laufen ja weiterhin ins Leere. Ich hoffe jemand weiß dazu Rat.
Was ich auch noch nebenbei andenke ist, die 1. FritzBox per SNMP abfrage, ob denn eine WAN Verbindung besteht. Doch wie übergebe ich das Ergbnis dann dem Bintec und wie kann ich da dann darauf reagieren? Auch könnte es sein, dass das Kabelmodem abstürzt und die FritzBox dennoch der Meinung ist, dass eine Verbindung besteht oder eben im Kabelnetz selbst der Hund begraben liegt. Die Pingmethode erscheint mir bislang als die beste Prüfmethode hierfür. Daher wäre ich sehr glücklich, wenn jemand hier einen Tip/Lösung zu dem oben geschilderten Problemchen hat. Danke und schöne Weihnachten.
PS:
Achso.... alle Geräte haben die aktuelle Firmware drauf.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 359062
Url: https://administrator.de/contentid/359062
Ausgedruckt am: 07.11.2024 um 12:11 Uhr
4 Kommentare
Neuester Kommentar
Generell ist deine Vorgehensweise richtig. Physisch geht der Failover nur nach dem Linkstatus und das der auf Down geht zw. Bintec WAN und FB LAN Port ist, wie du sehr richtig sagst, eher unwahrscheinlich, deshalb der Ping Check. Alles richtig also. Der Teufel liegt vermutlich im Detail.
Das liegt daran das du dem SLA Check, also der Leitungs Überprüfung durch Ping vermutlich im Bimntec nicht sagen kannst (oder nicht gesagt hast) über welches Interface er zwangsweise gehen soll.
Wenn du also nur auf die 8.8.8.8 pingst, aber das Source Interface nicht definierst, wird der Bintec natürlich dann nach dem Failover Timeout auf die .20.0 auch die 8.8.8.8 pingen, was ihm dann ja auch über WAN 2 gelingt.
Dadurch "denkt" der Bintec dann das sie wieder erreichbar ist und versucht auf den primären Link umzuschalten.
Das würde dieses obige Verhalten erklären.
Normal ist es auch so das der SLA Check auf ein Interface fixiert sein muss. Also müsstest du immer zwei Ping Checks durchführen, einen statisch über WAN 1 auf die 8.8.8.8 z.B. und einen statisch über WAN 2 auf 9.9.9.9
Wenn 8.8.8.8 fehlschlägt und bitte nur dann, schalte um auf sekundär. Da der 8.8.8.8 Pingcheck aber jetzt festgenagelt ist auf WAN 1 wird der erst wieder aktiv wenn die 8.8.8.8 auch nur über WAN 1 erreichbar ist.
Das ist vermutlich das Dilemma in dem du steckst bzw. so müsste es richtig konfiguriert werden damit es fehlerfrei klappt.
Viel besser wäre hier auch immer pingbare Hosts des jeweiligen Providers zu nehmen um Antwortszeiten klein zu halten !! Es geht ja nur um die Erreichbarkeit des jeweiligen Providers und nicht des gesamten Internets.
Abgesehen davon ist die reine Failover Lösung nicht besonders intelligent, es sei denn du hast andere, bessere Gründe.
Der gravierende Nachteil ist ja das deine xDSL Leitung für die du bezahlst gänzlich tot ist und ungenutzt.
Erheblich sinnvoller wäre es doch diese mit in eine aktive Bandbreitenverteilung zu integrieren. Und zwar auch wenn die DSL Leitung langsamer ist.
Das macht man dann über eine prozentuale Wichtung der Leitungen was gute Load Balancing Router auch im Consumer Bereich supporten sollten.
Je nach Bandbreite legt der Router dann jede x-te Session aufs DSL oder macht Round Robin sollte die Bandbreite gleich sein.
Auch so eine Wichtung ist mit gegenseitigem Failover konfigurierbar so das du keinerlei Nachteile hast. Im Gegenteil so nutzt du sehr optimal beide Leitungen aktiv und hast optimale Bandbreiten Performance.
Nur mal so zum Nachdenken....
Das liegt daran das du dem SLA Check, also der Leitungs Überprüfung durch Ping vermutlich im Bimntec nicht sagen kannst (oder nicht gesagt hast) über welches Interface er zwangsweise gehen soll.
Wenn du also nur auf die 8.8.8.8 pingst, aber das Source Interface nicht definierst, wird der Bintec natürlich dann nach dem Failover Timeout auf die .20.0 auch die 8.8.8.8 pingen, was ihm dann ja auch über WAN 2 gelingt.
Dadurch "denkt" der Bintec dann das sie wieder erreichbar ist und versucht auf den primären Link umzuschalten.
Das würde dieses obige Verhalten erklären.
Normal ist es auch so das der SLA Check auf ein Interface fixiert sein muss. Also müsstest du immer zwei Ping Checks durchführen, einen statisch über WAN 1 auf die 8.8.8.8 z.B. und einen statisch über WAN 2 auf 9.9.9.9
Wenn 8.8.8.8 fehlschlägt und bitte nur dann, schalte um auf sekundär. Da der 8.8.8.8 Pingcheck aber jetzt festgenagelt ist auf WAN 1 wird der erst wieder aktiv wenn die 8.8.8.8 auch nur über WAN 1 erreichbar ist.
Das ist vermutlich das Dilemma in dem du steckst bzw. so müsste es richtig konfiguriert werden damit es fehlerfrei klappt.
Viel besser wäre hier auch immer pingbare Hosts des jeweiligen Providers zu nehmen um Antwortszeiten klein zu halten !! Es geht ja nur um die Erreichbarkeit des jeweiligen Providers und nicht des gesamten Internets.
Abgesehen davon ist die reine Failover Lösung nicht besonders intelligent, es sei denn du hast andere, bessere Gründe.
Der gravierende Nachteil ist ja das deine xDSL Leitung für die du bezahlst gänzlich tot ist und ungenutzt.
Erheblich sinnvoller wäre es doch diese mit in eine aktive Bandbreitenverteilung zu integrieren. Und zwar auch wenn die DSL Leitung langsamer ist.
Das macht man dann über eine prozentuale Wichtung der Leitungen was gute Load Balancing Router auch im Consumer Bereich supporten sollten.
Je nach Bandbreite legt der Router dann jede x-te Session aufs DSL oder macht Round Robin sollte die Bandbreite gleich sein.
Auch so eine Wichtung ist mit gegenseitigem Failover konfigurierbar so das du keinerlei Nachteile hast. Im Gegenteil so nutzt du sehr optimal beide Leitungen aktiv und hast optimale Bandbreiten Performance.
Nur mal so zum Nachdenken....
Danke für die Antwort.
Das ganze soll zunächst wriklich nur als Fallback funktionieren. Load Balancing wäre dann die Kür, wenn der Fallbackfall voll und ganz funktioniert, denn in diesem Fall hätte ich auch gleich einen DualWAN Router nehmen können. Dies ist aber aufgrund der am Ort gegebenen Konstellation nicht so einfach durchführbar. Daher bitte zunächst so wie gegeben.
Ich habe nun heute nochmals daran rumgeochst und mich quer durch alle von mir erdenklichen Szenarien gearbeitet. Dabei habe ich es auch mal so weit geschafft, dass die Fallbackroute betand hatte, diese aber nicht wieder auf die ursprüngliche Route zurück gesprungen ist, sobald diese wieder da war. Shit happens.
Ich habe mittlerweile auch das gesamte Routing manuell konfiguriert. Vorher war das mehr oder minder automatisch, d.h. die beiden Router zur Simulation der beiden Zugänge machten DHCP und der Bintec hat sich auf der entsprechenden Schnittstelle per DHCP eine IP gezogen und machte dann NAT. Im Nachhinein macht das aber irgendwie nix aus, denn das Ergebnis ist dasselbe.
Also nochmals das gesamte Routing in diesem Fall nun Manuell eingerichtet:
In den beiden FritzBox sind statische Routen für die Rückroute in den Bintec, jeweils
FritzBox1: 10,0,0,0 / 255.255.255.0 üer 192.168.10.254
FritzBox2: 10,0,0,0 / 255.255.255.0 üer 192.168.20.254
In dem Bintec sieht es so aus:
Schnittstellendefinition
Routing
Erweiteretes Routing für Host, um Ping abzusetzen - so denke ich mir das???
Überwachung
Zieh ich jetzt den WAN an FritzBox 1 (192.168.10.0) dann schaltet der Bintec auch brav nach ein paar Sekunden auf die Fallbackroute um. Leider fällt er dann ebenfalls nach ein paar Sekunden wieder auf die imer noch tote Hauptroute zurück und wechselt dann wieder entsprechend des Überwachungsintervalls auf die Fallbackroute. So weit war ich ja schon und das ist so nicht brauchbar.
Nun ändere ich in der Überwachung die Quell IP von 10.0.0.1 auf 192.168.10.254. Damit schaltet der Bintec auf Fallback im Fehlerfall und bleibt auch da, selbst wenn die Hauptroute wieder funktioniert.
Sieht dann so aus
Ist mittlerweile logisch.... warum?
Im Fallbackfall wird per Überwachung das Interface En1-1 deaktiviert. Damit ist die Hauptroute über 192.168.10.0 weg und es geht über die Fallbackroute 192.168.20.0. Damit erreicht der Ping 10.0.0.1 ja wieder den Host und alles ist gut und das deaktivierte Interface wird wieder aktiviert. Deswegen schaltet der Bintec auch immer wieder hin- und her. Das wurde ja auch so kommuniziert.
Im zweiten Fall ist die Quelle aber 192.168.10.254, was ja auf dem dann deaktivierten Intferface sitzt und deswegen geht dann auch kein Ping mehr raus und damit kann auch nicht mehr geprüft werden, ob nun diese Route wieder frei ist oder nicht.
Nun kam mir die Idee ein zweites Interface in das 192.168.10.0 zu setzen und dieses als reines Prüfinterface für den Ping zu nutzen.... mal sehen ob das fruchtet. Ich bin gespannt.
Das ganze soll zunächst wriklich nur als Fallback funktionieren. Load Balancing wäre dann die Kür, wenn der Fallbackfall voll und ganz funktioniert, denn in diesem Fall hätte ich auch gleich einen DualWAN Router nehmen können. Dies ist aber aufgrund der am Ort gegebenen Konstellation nicht so einfach durchführbar. Daher bitte zunächst so wie gegeben.
Ich habe nun heute nochmals daran rumgeochst und mich quer durch alle von mir erdenklichen Szenarien gearbeitet. Dabei habe ich es auch mal so weit geschafft, dass die Fallbackroute betand hatte, diese aber nicht wieder auf die ursprüngliche Route zurück gesprungen ist, sobald diese wieder da war. Shit happens.
Ich habe mittlerweile auch das gesamte Routing manuell konfiguriert. Vorher war das mehr oder minder automatisch, d.h. die beiden Router zur Simulation der beiden Zugänge machten DHCP und der Bintec hat sich auf der entsprechenden Schnittstelle per DHCP eine IP gezogen und machte dann NAT. Im Nachhinein macht das aber irgendwie nix aus, denn das Ergebnis ist dasselbe.
Also nochmals das gesamte Routing in diesem Fall nun Manuell eingerichtet:
In den beiden FritzBox sind statische Routen für die Rückroute in den Bintec, jeweils
FritzBox1: 10,0,0,0 / 255.255.255.0 üer 192.168.10.254
FritzBox2: 10,0,0,0 / 255.255.255.0 üer 192.168.20.254
In dem Bintec sieht es so aus:
Schnittstellendefinition
Routing
Erweiteretes Routing für Host, um Ping abzusetzen - so denke ich mir das???
Überwachung
Zieh ich jetzt den WAN an FritzBox 1 (192.168.10.0) dann schaltet der Bintec auch brav nach ein paar Sekunden auf die Fallbackroute um. Leider fällt er dann ebenfalls nach ein paar Sekunden wieder auf die imer noch tote Hauptroute zurück und wechselt dann wieder entsprechend des Überwachungsintervalls auf die Fallbackroute. So weit war ich ja schon und das ist so nicht brauchbar.
Nun ändere ich in der Überwachung die Quell IP von 10.0.0.1 auf 192.168.10.254. Damit schaltet der Bintec auf Fallback im Fehlerfall und bleibt auch da, selbst wenn die Hauptroute wieder funktioniert.
Sieht dann so aus
Ist mittlerweile logisch.... warum?
Im Fallbackfall wird per Überwachung das Interface En1-1 deaktiviert. Damit ist die Hauptroute über 192.168.10.0 weg und es geht über die Fallbackroute 192.168.20.0. Damit erreicht der Ping 10.0.0.1 ja wieder den Host und alles ist gut und das deaktivierte Interface wird wieder aktiviert. Deswegen schaltet der Bintec auch immer wieder hin- und her. Das wurde ja auch so kommuniziert.
Im zweiten Fall ist die Quelle aber 192.168.10.254, was ja auf dem dann deaktivierten Intferface sitzt und deswegen geht dann auch kein Ping mehr raus und damit kann auch nicht mehr geprüft werden, ob nun diese Route wieder frei ist oder nicht.
Nun kam mir die Idee ein zweites Interface in das 192.168.10.0 zu setzen und dieses als reines Prüfinterface für den Ping zu nutzen.... mal sehen ob das fruchtet. Ich bin gespannt.
n den beiden FritzBox sind statische Routen für die Rückroute in den Bintec, jeweils
Das ist Quatsch, denn der Bintec macht ja NAT. Die FritzBoxen als Internet Router wissen ja gar nicht das das 10er Netz hinter dem Bintec ist. Müssen sie auch nicht ! Es reicht wenn sie ihr jeweiliges Koppelsubnetz kennen. Aus Routing Sicht existiert für sie nur dieses IP Netz. Niemals aber das 10er.Diese Routen sind ziemlich kontraproduktiv und solltest du besser löschen.
Leider fällt er dann ebenfalls nach ein paar Sekunden wieder auf die imer noch tote Hauptroute
Vermutlich weil du im Bintec wieder keinen Port spezifischen SLA Check machst.Der SLA Check ist auch in sich falsch. Die 10.0.0.1 als Source zu nehmen ist ja Unsinn.
Hier brauchst du wie oben schon gesagt zwei Port spezifische SLA Checks !
Z.B. von Port 1 mit der Quell IP 192.168.10.254 auf die 8.8.8.8 und
von Port 2 mit der Quell IP 192.168.20.254 auf die 8.8.4.4
So hast du die 2 unterschiedlichen Ping Checks pro Port.
Mit deiner falschen 10.0.0.1 die ja so oder so Unsinn ist weil sie geNATet wird bleibst du ja in dem Dilemma das der Bintec dann das Ziel wieder über den Backup checkt. So kann das niemals gehen.
Du musst ja WAN Link spezifisch checken.
Bau das also um und nimm vor allem die richtigen Quell IPs pro WAN Port und dann klappt das auch.
Zitat von @aqui:
Hier brauchst du wie oben schon gesagt zwei Port spezifische SLA Checks !
Z.B. von Port 1 mit der Quell IP 192.168.10.254 auf die 8.8.8.8 und
von Port 2 mit der Quell IP 192.168.20.254 auf die 8.8.4.4
So hast du die 2 unterschiedlichen Ping Checks pro Port.
Hier brauchst du wie oben schon gesagt zwei Port spezifische SLA Checks !
Z.B. von Port 1 mit der Quell IP 192.168.10.254 auf die 8.8.8.8 und
von Port 2 mit der Quell IP 192.168.20.254 auf die 8.8.4.4
So hast du die 2 unterschiedlichen Ping Checks pro Port.
So habe ich das auch gemacht, nur mit einem kleinen Unterschied.
Da mir das Backup egal ist, da ich davon ausgehe, dass dies tut, muss/will ich nur die Hauptroute über das 10er Netz prüfen.
Also habe ich im Bintec ein zweites Interface mit 192.168.10.253 angelegt (En1-3)
In der Üerwachung gab ich als Quelle 192.168.10.254 an. Das umschalten im Fehlerfalle hat auch dauerhaft funktioniert, nur kam das deaktivierte Interface En1-1, 192.168.10.254 nicht mehr online, da es ja nun nicht mehr verfügbar ist und prüfen kann. Ast abgesägt.
Daher die Idee, wie auch von dir erwähnt, mit einem zweiten, immer offenen Interface - En1-3, 192.168.10.253
Als Quelle in der Überwachung gebe ich nun 192.168.10.253 an und schalte darübe das Interface En1-1. Abschalten geht, nur kommt es eben wieder nicht, obwohl das Prüfinterface ja online ist (das sehe ich auch im Status der Bintec), wieder online. Warum?
