Mikrotik-WAN-Failover

visucius
Goto Top
article-picture
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

Content-Key: 3237156061

Url: https://administrator.de/contentid/3237156061

Ausgedruckt am: 07.08.2022 um 17:08 Uhr

Mitglied: aqui
aqui 02.07.2022 aktualisiert um 14:27:55 Uhr
Goto Top
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?!
Mitglied: Visucius
Visucius 02.07.2022 aktualisiert um 16:37:51 Uhr
Goto Top
Ich greife hier mal die Grafik von Mikrotiks Anleitung heraus, für Leute, die die Anleitung nicht gelesen haben face-wink

bildschirmfoto 2022-07-02 um 15.39.40

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.
Mitglied: aqui
aqui 02.07.2022 aktualisiert um 16:39:07 Uhr
Goto Top
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.
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
Mitglied: Visucius
Visucius 02.07.2022 aktualisiert um 16:56:38 Uhr
Goto Top
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:


Klappt aber ebenso nicht.
bildschirmfoto 2022-07-02 um 16.52.48
bildschirmfoto 2022-07-02 um 16.53.20
Mitglied: Visucius
Visucius 02.07.2022 um 19:03:33 Uhr
Goto Top
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
Mitglied: aqui
aqui 03.07.2022 um 00:53:12 Uhr
Goto Top
die IP des vorgelagtern "Modems" ein (192.168.100.1)
Ein reines Modem hat KEINE IP. Es macht kein IP Forwarding.
Mitglied: Visucius
Visucius 03.07.2022 aktualisiert um 12:14:33 Uhr
Goto Top
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.
Mitglied: aqui
aqui 04.07.2022 um 12:25:34 Uhr
Goto Top
Mitglied: Visucius
Visucius 04.07.2022, aktualisiert am 05.07.2022 um 09:48:06 Uhr
Goto Top
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
Mitglied: Visucius
Visucius 08.07.2022 aktualisiert um 08:55:17 Uhr
Goto Top
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.
Mitglied: Visucius
Lösung Visucius 09.07.2022 um 15:04:51 Uhr
Goto Top
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
Mitglied: aqui
aqui 09.07.2022 um 17:50:24 Uhr
Goto Top
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.
Mitglied: Visucius
Visucius 13.07.2022 aktualisiert um 11:09:04 Uhr
Goto Top
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 face-wink
Mitglied: aqui
aqui 13.07.2022 um 13:52:34 Uhr
Goto Top
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... 😉