14
Mikrotik-WAN-Failover
Schönes WE in die Runde,
isch hab da nen Problemchen und vermutlich ist es nur ne Kleinigkeit. Gewünscht ist ein WAN-Failover von Vodafone-Cable auf ether1 (WAN1_Cable) zu LTE-Modem auf ether2 (WAN2_LTE).
Man landet bei dem Thema - neben unendlich vielen Optionen auf z.T. Skript-Basis - am Ende auch hier im Forum bei:
https://help.mikrotik.com/docs/pages/viewpage.action?pageId=26476608
Soweit so gut. Beim übertragen auf mein Setup:
8.8.8.8 > 1.1.1.1
8.8.4.4 > 1.0.0.1
to_ISP1 > to_WAN1
to_ISP2 > to_WAN2
10.111.0.1 > WAN1_Cable
10.112.0.1 > WAN2_LTE
sehen die routing-Befehle entsprechend so aus:
/ip/route/
add dst-address=1.1.1.1 scope=10 gateway=WAN1_Cable
add dst-address=1.0.0.1 scope=10 gateway=WAN2_LTE
add distance=1 gateway=1.1.1.1 routing-table=to_WAN1 check-gateway=ping
add distance=2 gateway=1.0.0.1 routing-table=to_WAN1 check-gateway=ping
add distance=1 gateway=1.0.0.1 routing-table=to_WAN2 check-gateway=ping
add distance=2 gateway=1.1.1.1 routing-table=to_WAN2 check-gateway=ping
Die Folge:
Das Immediate Gateway: unknown
Liegt wohl daran, dass ich die IP-Adressen (10.111.0.1, 10.112.0.1 )als Gateway durch WAN1_Cable und WAN2_LTE als Variable ersetzt habe. Das sind ja nicht die am Router-anliegenden WAN-Adressen, sondern die (vermutlich) Gateway-IP des ISPs. Oder?
Wie ließe sich das denn Mikrotik-konform lösen? Denn zumindest die WAN-Adresse des Cable-Modems ist nicht komplett fix.
VG
isch hab da nen Problemchen und vermutlich ist es nur ne Kleinigkeit. Gewünscht ist ein WAN-Failover von Vodafone-Cable auf ether1 (WAN1_Cable) zu LTE-Modem auf ether2 (WAN2_LTE).
Man landet bei dem Thema - neben unendlich vielen Optionen auf z.T. Skript-Basis - am Ende auch hier im Forum bei:
https://help.mikrotik.com/docs/pages/viewpage.action?pageId=26476608
Soweit so gut. Beim übertragen auf mein Setup:
8.8.8.8 > 1.1.1.1
8.8.4.4 > 1.0.0.1
to_ISP1 > to_WAN1
to_ISP2 > to_WAN2
10.111.0.1 > WAN1_Cable
10.112.0.1 > WAN2_LTE
sehen die routing-Befehle entsprechend so aus:
/ip/route/
add dst-address=1.1.1.1 scope=10 gateway=WAN1_Cable
add dst-address=1.0.0.1 scope=10 gateway=WAN2_LTE
add distance=1 gateway=1.1.1.1 routing-table=to_WAN1 check-gateway=ping
add distance=2 gateway=1.0.0.1 routing-table=to_WAN1 check-gateway=ping
add distance=1 gateway=1.0.0.1 routing-table=to_WAN2 check-gateway=ping
add distance=2 gateway=1.1.1.1 routing-table=to_WAN2 check-gateway=ping
Die Folge:
Das Immediate Gateway: unknown
Liegt wohl daran, dass ich die IP-Adressen (10.111.0.1, 10.112.0.1 )als Gateway durch WAN1_Cable und WAN2_LTE als Variable ersetzt habe. Das sind ja nicht die am Router-anliegenden WAN-Adressen, sondern die (vermutlich) Gateway-IP des ISPs. Oder?
Wie ließe sich das denn Mikrotik-konform lösen? Denn zumindest die WAN-Adresse des Cable-Modems ist nicht komplett fix.
VG
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3237156061
Url: https://administrator.de/forum/mikrotik-wan-failover-3237156061.html
Ausgedruckt am: 05.04.2025 um 17:04 Uhr
14 Kommentare
Neuester Kommentar
Die Frage ist WIE diese WAN1 und WAN1 IP Adressen zustande kommen??
Die 1er Adressen können niemals als Gateway Adressen von den WAN1 und WAN2 Providern kommen, da sie ja im Internet offiziell vergeben sind z.B. 1.1.1.0-255 an Cloudflare!
Damit scheidet die 1.1.1.1 als Gateway IP ja schonmal völlig aus, denn das ist ja eine niemals direkt erreichbare next Hop IP Gateway Adresse von deinem Mikrotik. Gleiches gilt für das 1.0.0.0er Segment.
Da stimmt also generell mal schon etwas grundsätzlich mit deinen Default Routen nicht. Genau deshalb sind die auch alle rot weil nicht erreichbar.
Bleibt also die Frage WIE WAN1 und WAN2 angebunden sind? WAN2 (LTE) vermutlich mit einem Router via Koppelnetz. Dann wäre die Koppelnetz IP des LTE Routers der next Hop aber niemals einen offizielle IANA IP wie die 1.0.0.1!
Gleiches gilt für WAN1 das Kabel TV. Hier müsste als next Hop eine öffentliche v4 IP des Providers Vodafone stehen sofern es ein reines Modem ist und diese Route dynamisch über DHCP oder PPPoE gelernt wurde. 1.1.1.1 gehört aber nicht zu Vodafone sondern Cloudflare in den USA, kann also niemals Gateway IP des MTs sein.
Oder eben auch wie oben wenn WAN1 einen Koppelrouter nutzt dann über die Router IP als next Hop.
Irgendwas kann da also nicht so wirklich stimmen an deinem o.a. Routing Setup?!
Die 1er Adressen können niemals als Gateway Adressen von den WAN1 und WAN2 Providern kommen, da sie ja im Internet offiziell vergeben sind z.B. 1.1.1.0-255 an Cloudflare!
Damit scheidet die 1.1.1.1 als Gateway IP ja schonmal völlig aus, denn das ist ja eine niemals direkt erreichbare next Hop IP Gateway Adresse von deinem Mikrotik. Gleiches gilt für das 1.0.0.0er Segment.
Da stimmt also generell mal schon etwas grundsätzlich mit deinen Default Routen nicht. Genau deshalb sind die auch alle rot weil nicht erreichbar.
Bleibt also die Frage WIE WAN1 und WAN2 angebunden sind? WAN2 (LTE) vermutlich mit einem Router via Koppelnetz. Dann wäre die Koppelnetz IP des LTE Routers der next Hop aber niemals einen offizielle IANA IP wie die 1.0.0.1!
Gleiches gilt für WAN1 das Kabel TV. Hier müsste als next Hop eine öffentliche v4 IP des Providers Vodafone stehen sofern es ein reines Modem ist und diese Route dynamisch über DHCP oder PPPoE gelernt wurde. 1.1.1.1 gehört aber nicht zu Vodafone sondern Cloudflare in den USA, kann also niemals Gateway IP des MTs sein.
Oder eben auch wie oben wenn WAN1 einen Koppelrouter nutzt dann über die Router IP als next Hop.
Irgendwas kann da also nicht so wirklich stimmen an deinem o.a. Routing Setup?!
Ich greife hier mal die Grafik von Mikrotiks Anleitung heraus, für Leute, die die Anleitung nicht gelesen haben 
Und hier das Original des Befehls:
/ip/route/
add dst-address=8.8.8.8 scope=10 gateway=10.111.0.1
add dst-address=8.8.4.4 scope=10 gateway=10.112.0.1
/ip/route/
add distance=1 gateway=8.8.8.8 routing-table=to_ISP1 check-gateway=ping
add distance=2 gateway=8.8.4.4 routing-table=to_ISP1 check-gateway=ping
Keine Ahnung was die da machen. Das 1.1.1.1 Cloudflare gehört ist mir schon klar. Aber ich habe ne Alternative zu den von Mikrotik angegebenen 8.8.8.8 und 8.8.4.4 gesucht.
Nicht wegen irgendwelcher Abhöraktionen, sondern weil ich potenzielle Probleme mit einem intern genutzten Google-TV-Stick unterbinden will. Dieser erreicht "seinen" Google-DNS (8.8.8.8) alle paaar Monate mal nicht. Keine Ahnung - schien mir bisher ein temporäres Routing-Problem von Vodafone zu sein.
MMn. gehts doch nur darum, dass der Mikrotik die DNS angepingt um zu sehen ob die Leitung noch da ist? Und für den Befehl benötige er ein - valides - Gateway. Ether1 (bei mir umbenannt in WAN1_Cable) ist es ganz offenbar nicht.
Und während ich die Threaderöffnung schrieb, ist mir aufgefallen, dass es in der Zeichnung von Mikrotik auch nicht die von außen anliegende WAN-IP ist, sondern nur eine IP aus dessen jeweiligen IP-Bereich.
Und hier das Original des Befehls:
/ip/route/
add dst-address=8.8.8.8 scope=10 gateway=10.111.0.1
add dst-address=8.8.4.4 scope=10 gateway=10.112.0.1
/ip/route/
add distance=1 gateway=8.8.8.8 routing-table=to_ISP1 check-gateway=ping
add distance=2 gateway=8.8.4.4 routing-table=to_ISP1 check-gateway=ping
Keine Ahnung was die da machen. Das 1.1.1.1 Cloudflare gehört ist mir schon klar. Aber ich habe ne Alternative zu den von Mikrotik angegebenen 8.8.8.8 und 8.8.4.4 gesucht.
Nicht wegen irgendwelcher Abhöraktionen, sondern weil ich potenzielle Probleme mit einem intern genutzten Google-TV-Stick unterbinden will. Dieser erreicht "seinen" Google-DNS (8.8.8.8) alle paaar Monate mal nicht. Keine Ahnung - schien mir bisher ein temporäres Routing-Problem von Vodafone zu sein.
MMn. gehts doch nur darum, dass der Mikrotik die DNS angepingt um zu sehen ob die Leitung noch da ist? Und für den Befehl benötige er ein - valides - Gateway. Ether1 (bei mir umbenannt in WAN1_Cable) ist es ganz offenbar nicht.
Und während ich die Threaderöffnung schrieb, ist mir aufgefallen, dass es in der Zeichnung von Mikrotik auch nicht die von außen anliegende WAN-IP ist, sondern nur eine IP aus dessen jeweiligen IP-Bereich.
Nach der Konfig ist die MT Zeichnung unvollständig, denn deren beiden WAN Leitungen gehen von je einem /30er Koppelnetz aus an beiden WAN Ports, also mit je 2 IP Adressen pro Netz. Dort verbergen sich also sehr wahrscheinlich noch Router dazwischen.
Du hast Recht was die Healthchecks anbetrifft. Dort muss man natürlich eine Internet IP pingen um zu merken ob einer der beiden WAN Provider ausgefallen ist um dann ggf. umzuschalten.
Das ist oben richtig und muss man über beide Anschlüsse machen, denn das Verfahren nutzt rekursives Routing.
Das ist bei dir ja etwas anders zumindestens wenn du die Provider Gateway Adressen dynamisch bekommst. Daher die Frage WIE die WAN Ports angebunden sind.
Wenn du einen LTE Router mit Koppelnetz betreibst ist zumindestens da die Router IP einzutragen.
Beim Vodafone ist die Frage ob dort dann auch ein Router mit Koppelnetz im Einsatz ist oder ein Modem direkt am MT hängt und die Provider Gateway IP dann direkt am MT hängt.
Hier wird das ganz gut mit einem Beispiel beschrieben:
https://forum.mikrotik.com/viewtopic.php?t=182209
Bzw. als Filmchen:
https://www.youtube.com/watch?v=QWPCMNMF-jI
Du hast Recht was die Healthchecks anbetrifft. Dort muss man natürlich eine Internet IP pingen um zu merken ob einer der beiden WAN Provider ausgefallen ist um dann ggf. umzuschalten.
Das ist oben richtig und muss man über beide Anschlüsse machen, denn das Verfahren nutzt rekursives Routing.
dass es in der Zeichnung von Mikrotik auch nicht die von außen anliegende WAN-IP ist
10.111.0.1 und 10.112.0.1 sind ja die jeweiligen Router Adressen in den Netzen. Das MT Tutorial geht davon aus das das die Provider Router sind.Das ist bei dir ja etwas anders zumindestens wenn du die Provider Gateway Adressen dynamisch bekommst. Daher die Frage WIE die WAN Ports angebunden sind.
Wenn du einen LTE Router mit Koppelnetz betreibst ist zumindestens da die Router IP einzutragen.
Beim Vodafone ist die Frage ob dort dann auch ein Router mit Koppelnetz im Einsatz ist oder ein Modem direkt am MT hängt und die Provider Gateway IP dann direkt am MT hängt.
Hier wird das ganz gut mit einem Beispiel beschrieben:
https://forum.mikrotik.com/viewtopic.php?t=182209
Bzw. als Filmchen:
https://www.youtube.com/watch?v=QWPCMNMF-jI
Wenn du einen LTE Router mit Koppelnetz betreibst ist zumindestens da die Router IP einzutragen. Beim Vodafone ist die Frage ob dort dann auch ein Router mit Koppelnetz im Einsatz ist oder ein Modem direkt am MT hängt und die Provider Gateway IP dann direkt am MT hängt.
Das ist ne spannende Frage und klingt plausibel. Und in der Tat, bei LTE ist der Router aus meinem vLAN erreichbar unter 192.168.8.1 und bei Vodafone-Cable eigentlich auch. Dieser arbeitet zwar transparent im Bridge-Mode - ist aber von mir aufrufbar unter 192.168.100.1:
/ip/route/
add dst-address=1.1.1.1 scope=10 gateway=192.168.100.1
add dst-address=1.0.0.1 scope=10 gateway=192.168.8.1
add distance=1 gateway=1.1.1.1 routing-table=to_WAN1 check-gateway=ping
add distance=2 gateway=1.0.0.1 routing-table=to_WAN1 check-gateway=ping
rekursiv:
add distance=1 gateway=1.0.0.1 routing-table=to_WAN2 check-gateway=ping
add distance=2 gateway=1.1.1.1 routing-table=to_WAN2 check-gateway=pingKlappt aber ebenso nicht.
Hm, es steht und fällt mit diesem "Gateway":
a) Trage ich hier WAN1_Cable (ether1) ein, dann wird zwar das Feld blau, die Rule insgesamt schwarz und damit augenscheinlcih akzeptiert ABER ich kann die dst-Adressse (8.8.8.8 oder 1.1.1.1) aus dem lokalen Netz nicht mir pingen UND wenn ich die Rule nochmal öffne ist das Immediate Gateway: unknown
b) Trage ich als Gateway die IP vom jeweiligen WAN-Port (178.26.xxx.254) ein wird auch alles bestätigt aber hier ebenso Immediate Gateway: unknown ABER ich kann den hinterlegten DNS pingen
c) Trage ich als Gateway eine abgewandelte - vermeintliche Vodafone-Router-IP (178.26.xxx.1) ein wird auch alles bestätigt aber hier ebenso Immediate Gateway: unknown ABER ich kann den hinterlegten DNS pingen
d) Trage ich als Gateway die IP des vorgelagtern "Modems" ein (192.168.100.1) übernimmt das Immediate Gatway sogar die WAN-Adresse und erkennt den Port: 178.26.xxx.254%WAN1_Cable. Die Rule wird aber rot "!IUSH"
In allen(!) Fällen bleibt die Regel:
Dst. 0.0.0.0/0
Gateway 8.8.8.8
Check: ping
Routing Table: to_WAN1
rot mit Immidiate Gateway: unknown
a) Trage ich hier WAN1_Cable (ether1) ein, dann wird zwar das Feld blau, die Rule insgesamt schwarz und damit augenscheinlcih akzeptiert ABER ich kann die dst-Adressse (8.8.8.8 oder 1.1.1.1) aus dem lokalen Netz nicht mir pingen UND wenn ich die Rule nochmal öffne ist das Immediate Gateway: unknown
b) Trage ich als Gateway die IP vom jeweiligen WAN-Port (178.26.xxx.254) ein wird auch alles bestätigt aber hier ebenso Immediate Gateway: unknown ABER ich kann den hinterlegten DNS pingen
c) Trage ich als Gateway eine abgewandelte - vermeintliche Vodafone-Router-IP (178.26.xxx.1) ein wird auch alles bestätigt aber hier ebenso Immediate Gateway: unknown ABER ich kann den hinterlegten DNS pingen
d) Trage ich als Gateway die IP des vorgelagtern "Modems" ein (192.168.100.1) übernimmt das Immediate Gatway sogar die WAN-Adresse und erkennt den Port: 178.26.xxx.254%WAN1_Cable. Die Rule wird aber rot "!IUSH"
In allen(!) Fällen bleibt die Regel:
Dst. 0.0.0.0/0
Gateway 8.8.8.8
Check: ping
Routing Table: to_WAN1
rot mit Immidiate Gateway: unknown
die IP des vorgelagtern "Modems" ein (192.168.100.1)
Ein reines Modem hat KEINE IP. Es macht kein IP Forwarding.
Das glaube ich gerne, weshalb ich oben ja auch gebridged geschrieben habe.
Ist aber auch keine Lösung für das Problem?! Mir als Anwender ist doch wumpe, wie die Router-IP meines Providers lautet? Es muss doch möglich sein die Interfaces für den Failover auszuwählen?!
Wieder nen halber Tag für nix.
Erinnert an diese Wireguard-Implementierung, wo Du am Ende keine DNS Namen eintragen kannst. Und die Leute frickeln dann mit Skripten rum um das zum Laufen zu bringen. Ach ne, per CLI gehts dann ja trotzdem angeblich irgendwie. Und so nen Kleinkram ist ja seit Monaten nicht behoben.
Ist aber auch keine Lösung für das Problem?! Mir als Anwender ist doch wumpe, wie die Router-IP meines Providers lautet? Es muss doch möglich sein die Interfaces für den Failover auszuwählen?!
Wieder nen halber Tag für nix.
Erinnert an diese Wireguard-Implementierung, wo Du am Ende keine DNS Namen eintragen kannst. Und die Leute frickeln dann mit Skripten rum um das zum Laufen zu bringen. Ach ne, per CLI gehts dann ja trotzdem angeblich irgendwie. Und so nen Kleinkram ist ja seit Monaten nicht behoben.
Das Forum hat noch einen Thread zu dem Thema:
Zweites Gateway erreichbar machen
Zweites Gateway erreichbar machen
Na, da hat er aber doch auch Koppelnetze (die beiden DSL-Fritzen) und zudem keinen Failover, sondern er möchte die beiden vLANs bzw. Teilnetze jeweils einer Fritze zuordnen.
Aber trotzdem Danke. Evtl. hat ja jemand noch ne Idee. Bzw. ich werde mal wieder den Support anschreiben, was die sich dabei gedacht haben. Das scheint bei MT ja ne besondere Art des CRM zu sein 😒
PS: Schade, auch der sonst recht umtriebige Berg scheint in 2022 noch mit der 6er-Version zu arbeiten:
https://www.youtube.com/watch?v=c9ybewdi3qk&t=35s
Aber trotzdem Danke. Evtl. hat ja jemand noch ne Idee. Bzw. ich werde mal wieder den Support anschreiben, was die sich dabei gedacht haben. Das scheint bei MT ja ne besondere Art des CRM zu sein 😒
PS: Schade, auch der sonst recht umtriebige Berg scheint in 2022 noch mit der 6er-Version zu arbeiten:
https://www.youtube.com/watch?v=c9ybewdi3qk&t=35s
Ish hab da ne Frage:
Vorab: Das Problem vom Thread-Anfang ist noch nicht gelöst, der MT-Support hat mir bisher nur gezeigt, wo ich die Priorisierung der 2 WAN-Ports bei nem Router als DHCP-Client vornehme:
IP > DHCP Client > WAN-Port > Default Router Distance
Mir ist aber in dem Kontext folgendes aufgefallen und ich bitte diesbezüglich um eine Erklärung:
Folgendes Teil-Setup ist noch aktiv!
Damit steigert sich der Datendurchsatz (NAT-Durchsatz) bei (fast.com) von ca. 400 Mbit/s auf rund 900 Mbit/s. Ich vermute, das hängt an der Mangle-Rule?!
Umgehe ich damit evtl. einen Teil der Firewall? Bzw. ist das ggfs. sicherheitsrelevant? Irgendwas wird ja augenscheinlich umschifft, bzw. nicht mehr gemacht. Deaktiviere ich alle oben gelisteten Befehle, gehts wieder zurück auf 400 Mbit/s NAT-Durchsatz.
Vorab: Das Problem vom Thread-Anfang ist noch nicht gelöst, der MT-Support hat mir bisher nur gezeigt, wo ich die Priorisierung der 2 WAN-Ports bei nem Router als DHCP-Client vornehme:
IP > DHCP Client > WAN-Port > Default Router Distance
Mir ist aber in dem Kontext folgendes aufgefallen und ich bitte diesbezüglich um eine Erklärung:
Folgendes Teil-Setup ist noch aktiv!
/ip/firewall/nat
add chain=srcnat action=masquerade out-interface=ether1
add chain=srcnat action=masquerade out-interface=ether2
/routing/table
add fib name=to_ISP1
add fib name=to_ISP2
/ip/firewall/mangle
add chain=output connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=ISP1_conn out-interface=ether1
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 out-interface=ether1
add chain=output connection-state=new connection-mark=no-mark action=mark-connection new-connection-mark=ISP2_conn out-interface=ether2
add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2 out-interface=ether2Damit steigert sich der Datendurchsatz (NAT-Durchsatz) bei (fast.com) von ca. 400 Mbit/s auf rund 900 Mbit/s. Ich vermute, das hängt an der Mangle-Rule?!
Umgehe ich damit evtl. einen Teil der Firewall? Bzw. ist das ggfs. sicherheitsrelevant? Irgendwas wird ja augenscheinlich umschifft, bzw. nicht mehr gemacht. Deaktiviere ich alle oben gelisteten Befehle, gehts wieder zurück auf 400 Mbit/s NAT-Durchsatz.
So, ich möchte das Ganze erstmal hier beenden!
IP > DHCP Client > WAN-Port > Default Router Distance
War in meinem Augen eine Lösung für mein Problem. Beide WANs laufen, ziehe ich den Stecker von WAN1 geht der Traffic nach kurzer Pause auf WAN2 weiter und wenn ich ihn wieder einstecke geht das ganze zurück.
In meinen Augen passt das erstmal so. Auch wenn das in meinen Augen nicht das ist, was ich aus der MT-Anleitung rauslese. Die ganze Mangle-Rule usw. ist dafür eigentlich nicht relevant.
Viele Grüße
IP > DHCP Client > WAN-Port > Default Router Distance
War in meinem Augen eine Lösung für mein Problem. Beide WANs laufen, ziehe ich den Stecker von WAN1 geht der Traffic nach kurzer Pause auf WAN2 weiter und wenn ich ihn wieder einstecke geht das ganze zurück.
In meinen Augen passt das erstmal so. Auch wenn das in meinen Augen nicht das ist, was ich aus der MT-Anleitung rauslese. Die ganze Mangle-Rule usw. ist dafür eigentlich nicht relevant.
Viele Grüße
Hier ist übrigens noch ein interessanter Ansatz wie man das mit Routing Marks statt mit Reverse Routing löst:
https://www.youtube.com/watch?v=3R6GloC-Ltk
Mir erscheint diese Option etwas sinnvoller und passt auch besser auf dein o.a. Design!
Mit der Distance (Metric) geht das natürlich auch.
https://www.youtube.com/watch?v=3R6GloC-Ltk
Mir erscheint diese Option etwas sinnvoller und passt auch besser auf dein o.a. Design!
Mit der Distance (Metric) geht das natürlich auch.
Jo aber auch der macht das über Koppelnetze. Und wegen denen benötigst Du vermutlich auch diese Pings auf DNS-Server.
Aber ist alles völlig unnötig! Ich habe gerade nochmal bzgl. der Mangle-rule, routing table, laufender Pings usw. nachgefragt.
Zitat Support:
"No, it is not necessary, "distance=1" will have priority over "distance=2" and the route will be active till the interface goes down or DHCP client lost its IP, then the second route with distance=2 will become active."
ois izy - aber sowas von. Zumindest ohne Koppelnetz
Aber ist alles völlig unnötig! Ich habe gerade nochmal bzgl. der Mangle-rule, routing table, laufender Pings usw. nachgefragt.
Zitat Support:
"No, it is not necessary, "distance=1" will have priority over "distance=2" and the route will be active till the interface goes down or DHCP client lost its IP, then the second route with distance=2 will become active."
ois izy - aber sowas von. Zumindest ohne Koppelnetz
Und wegen denen benötigst Du vermutlich auch diese Pings auf DNS-Server.
Die o.a. Konfig kommt OHNE DNS Pings aus. Der macht das auch nur über die Metric.DNS Pings benötigt man für das Reverse Routing. Man kann da aber auch beliebig andere IPs pingen.
Google, Cloudflare, Quad9 und Co sind sicherlixh noch very amused wenn Millionen von Mikritiks ihre Server pingen. OK, Google schon die wissen dann wo MT User sind, was die machen und verdienen mit dem Wissen mehr Geld als MT selber wert ist... 😉
