Failover-System mit EdgeRouter - Routingfehler?
Hi!
Ich habe im Moment ein improvisiertes Failover-System am laufen. Wen interessiert, was genau passiert ist und warum das nötig ist, möge den kursiven Abschnitt lesen. Wer nur am Problem interessiert ist, möge ihn überspringen.
Also. Wir sind ein mittelständisches Unternehmen mit knapp 50 Mitarbeitern. Natürlich macht auch vor uns die Moderne nicht halt, sodass auch wir irgendwann einmal von ISDN auf VoIP umstellen mussten. Dazu sollte einer unser Anschlüsse (ISDN-Mehrgeräteanschluss für Fax/Internet) Anfang Februar umgestellt werden, während der andere Anschluss (ISDN-Anlagenanschluss mit drei Amtsleitungen für Telefonie) erst im April folgen sollte bzw. komplett gestrichen werden sollte. So weit, so gut. Ich hatte für den Mehrgeräteanschluss schon Anfang Februar einen Nachfolgeauftrag bei unserem Telekommunikationspartner aufgegeben. Sogar ne Auftragsbestätigung habe ich bekommen. Zwei Tage vor der angedrohten Abschaltung des ISDN-Anschlusses hatte ich dann einen netten Anruf von der Telekom, dass ja kein Nachfolgeauftrag vorläge. Das saß erstmal. Also schnell noch einen beim Telekom-Direktvertrieb aufgegeben. Tja, und trotzdem saßen wir zwei Tage später ohne Internetanschluss hier. Das ging noch weiter, heute habe ich dann schließlich die Zugangsdaten für einen Anschluss bekommen, der am 14. März geschaltet werden soll. Das war insgesamt der 6. (?) Auftrag, der dann endlich mal nicht verschludert worden ist oder anderweitig verloren gegangen ist. Also... NIE (!!!) wieder Deutsche Telekom. Sobald ich eine Alternative habe (=> UnityMedia), wird das sofort gemacht, ungeachtet der Kosten. Denn seit besagter geplanter "Umstellung" sind wir jetzt per Mobilfunk mit dem Internet verbunden. Und kaufen jeden Tag fleißig eine DayFlat für 4.95 EUR. Mittlerweile habe ich extra für diesen Zweck einen TP-Link-UMTS-Router gekauft (AC750), damit kein extra Rechner mit Surfstick laufen muss. Unser eigentlicher Router (irgendein gräßliches Lancom-Teil) ist jetzt erstmal außer Betrieb.
Da wir davon abgesehen auch schon öfter Probleme mit der Internetanbindung hatten, möchte ich jetzt generell ein Failover-System einrichten. Zu diesem Zweck wollte ich einen Ubiquiti EdgeRouter X (der kleine mit 5 RJ45-Buchsen) benutzen, der hier eh noch rumflog. Also eben per Wizard auf Failover (benutze generell eth0, falls das nicht geht, weiche auf eth1 aus) eingestellt, den eigentlichen Router (LANCOM) auf eth0 gehängt, den UMTS-Router auf eth1 (TP-Link AC750 Wireless), das restliche Netzwerk (also Verbindung zum Hauptswitch) auf eth2. Dann eben noch die Netze richtig angepasst, sodass auf eth2/3/4 die IP-Einstellung 192.168.123.254/24 mit dem EdgeRouter als DHCP benutzt wird, sowie auf eth0 und eth1 je eine Adresse vom jeweiligen DHCP-Server im entsprechenden Netz geholt wird. Dann habe ich die Adressen von LANCOM (192.168.124.254/24, fungiert als DHCP) und TP-Link (192.168.125.254/24, fungiert als DHCP) entspechend eingestellt. Das funktioniert auch alles wunderbar, der EdgeRouter hat auch eigenständig entsprechende Routen angelegt, sodass ich nach den o.g. Anpassungen direkt über den TP-Link Internetzugriff hatte. Auch kann ich aus dem 123er-Netz über die 192.168.125.254 auf die Web-Oberfläche von dem TP-Link zugreifen. ALLERDINGS, und das ist mein Problem, kann ich nicht auf das LANCOM-Interface zugreifen (192.168.124.254). Mit tracert unter Windows 7 kurz überprüft, siehe da, der EdgeRouter schickt die Anfrage zum TP-Link auf der 192.168.125.254. Das ist natürlich falsch. Die automatisch eingerichteten Routen im EdgeRouter sehen so aus:
Und nochmal kurz eine Zusammenfassung der Netze:
Nun, bisher dachte ich eigentlich, dass die Routen nach der Netzgröße abgearbeitet werden. Also, zuerst die kleinsten Netze (hier die /24er-Netze), dann das /8er-Netz (localhost) und schließlich die WAN-Netze (mit dem 0er-Suffix). Aber scheinbar greift hier zuerst die zweite Route in der Tabelle und sorgt dafür, dass meine Anfrage an 192.168.124.254 über eth1 an 192.168.125.254 geroutet wird.
Also, wie man vielleicht merkt, habe ich etwas Ahnung von Netzwerktechnik. Aber ich bin eigentlich Software-Entwickler im Studium und Routing etc. war mal im ersten Semester in "Rechnernetze und ihre Anwendung" Thema... Etwas ist hängen geblieben, so ist's nicht. Aber leider nicht genug, um das hier lösen zu können. Denn natürlich möchte ich auch, wenn der Internetzugang über eth1 funktioniert, über eth0 auf den LANCOM-Router zugreifen können. Allein schon, um den Fehler diagnostizieren zu können. Ich hoffe mal, ich habe mein Problem klar und deutlich geschildert...
Auf Hilfe hoffend
chesstiger
Ich habe im Moment ein improvisiertes Failover-System am laufen. Wen interessiert, was genau passiert ist und warum das nötig ist, möge den kursiven Abschnitt lesen. Wer nur am Problem interessiert ist, möge ihn überspringen.
Also. Wir sind ein mittelständisches Unternehmen mit knapp 50 Mitarbeitern. Natürlich macht auch vor uns die Moderne nicht halt, sodass auch wir irgendwann einmal von ISDN auf VoIP umstellen mussten. Dazu sollte einer unser Anschlüsse (ISDN-Mehrgeräteanschluss für Fax/Internet) Anfang Februar umgestellt werden, während der andere Anschluss (ISDN-Anlagenanschluss mit drei Amtsleitungen für Telefonie) erst im April folgen sollte bzw. komplett gestrichen werden sollte. So weit, so gut. Ich hatte für den Mehrgeräteanschluss schon Anfang Februar einen Nachfolgeauftrag bei unserem Telekommunikationspartner aufgegeben. Sogar ne Auftragsbestätigung habe ich bekommen. Zwei Tage vor der angedrohten Abschaltung des ISDN-Anschlusses hatte ich dann einen netten Anruf von der Telekom, dass ja kein Nachfolgeauftrag vorläge. Das saß erstmal. Also schnell noch einen beim Telekom-Direktvertrieb aufgegeben. Tja, und trotzdem saßen wir zwei Tage später ohne Internetanschluss hier. Das ging noch weiter, heute habe ich dann schließlich die Zugangsdaten für einen Anschluss bekommen, der am 14. März geschaltet werden soll. Das war insgesamt der 6. (?) Auftrag, der dann endlich mal nicht verschludert worden ist oder anderweitig verloren gegangen ist. Also... NIE (!!!) wieder Deutsche Telekom. Sobald ich eine Alternative habe (=> UnityMedia), wird das sofort gemacht, ungeachtet der Kosten. Denn seit besagter geplanter "Umstellung" sind wir jetzt per Mobilfunk mit dem Internet verbunden. Und kaufen jeden Tag fleißig eine DayFlat für 4.95 EUR. Mittlerweile habe ich extra für diesen Zweck einen TP-Link-UMTS-Router gekauft (AC750), damit kein extra Rechner mit Surfstick laufen muss. Unser eigentlicher Router (irgendein gräßliches Lancom-Teil) ist jetzt erstmal außer Betrieb.
Da wir davon abgesehen auch schon öfter Probleme mit der Internetanbindung hatten, möchte ich jetzt generell ein Failover-System einrichten. Zu diesem Zweck wollte ich einen Ubiquiti EdgeRouter X (der kleine mit 5 RJ45-Buchsen) benutzen, der hier eh noch rumflog. Also eben per Wizard auf Failover (benutze generell eth0, falls das nicht geht, weiche auf eth1 aus) eingestellt, den eigentlichen Router (LANCOM) auf eth0 gehängt, den UMTS-Router auf eth1 (TP-Link AC750 Wireless), das restliche Netzwerk (also Verbindung zum Hauptswitch) auf eth2. Dann eben noch die Netze richtig angepasst, sodass auf eth2/3/4 die IP-Einstellung 192.168.123.254/24 mit dem EdgeRouter als DHCP benutzt wird, sowie auf eth0 und eth1 je eine Adresse vom jeweiligen DHCP-Server im entsprechenden Netz geholt wird. Dann habe ich die Adressen von LANCOM (192.168.124.254/24, fungiert als DHCP) und TP-Link (192.168.125.254/24, fungiert als DHCP) entspechend eingestellt. Das funktioniert auch alles wunderbar, der EdgeRouter hat auch eigenständig entsprechende Routen angelegt, sodass ich nach den o.g. Anpassungen direkt über den TP-Link Internetzugriff hatte. Auch kann ich aus dem 123er-Netz über die 192.168.125.254 auf die Web-Oberfläche von dem TP-Link zugreifen. ALLERDINGS, und das ist mein Problem, kann ich nicht auf das LANCOM-Interface zugreifen (192.168.124.254). Mit tracert unter Windows 7 kurz überprüft, siehe da, der EdgeRouter schickt die Anfrage zum TP-Link auf der 192.168.125.254. Das ist natürlich falsch. Die automatisch eingerichteten Routen im EdgeRouter sehen so aus:
Selected | Destination | Next Hop | Interface | Route Type | in FIB |
---|---|---|---|---|---|
No | 0.0.0.0/0 | 192.168.124.254 | eth0 | static | Yes |
Yes | 0.0.0.0/0 | 192.168.125.254 | eth1 | static | Yes |
Yes | 127.0.0.0/8 | lo | connected | Yes | |
Yes | 192.168.123.0/24 | switch0 | connected | Yes | |
Yes | 192.168.124.0/24 | eth0 | connected | Yes | |
Yes | 192.168.125.0/24 | eth1 | connected | Yes |
Und nochmal kurz eine Zusammenfassung der Netze:
Ports | Adresse | Bemerkung |
---|---|---|
eth0 | 192.168.124.108/24 | Verbindung zu LANCOM-Router (DSL), Adresse per DHCP an EdgeRouter vergeben |
eth1 | 192.168.125.100/24 | Verbindung zu TP-Link-Router (UMTS), Adresse per DHCP an EdgeRouter vergeben |
eth2, eth3, eth4 (intern switch0) | 192.168.123.254/24 | Statisch, EdgeRouter vergibt an andere Geräte per DHCP Adressen |
Nun, bisher dachte ich eigentlich, dass die Routen nach der Netzgröße abgearbeitet werden. Also, zuerst die kleinsten Netze (hier die /24er-Netze), dann das /8er-Netz (localhost) und schließlich die WAN-Netze (mit dem 0er-Suffix). Aber scheinbar greift hier zuerst die zweite Route in der Tabelle und sorgt dafür, dass meine Anfrage an 192.168.124.254 über eth1 an 192.168.125.254 geroutet wird.
Also, wie man vielleicht merkt, habe ich etwas Ahnung von Netzwerktechnik. Aber ich bin eigentlich Software-Entwickler im Studium und Routing etc. war mal im ersten Semester in "Rechnernetze und ihre Anwendung" Thema... Etwas ist hängen geblieben, so ist's nicht. Aber leider nicht genug, um das hier lösen zu können. Denn natürlich möchte ich auch, wenn der Internetzugang über eth1 funktioniert, über eth0 auf den LANCOM-Router zugreifen können. Allein schon, um den Fehler diagnostizieren zu können. Ich hoffe mal, ich habe mein Problem klar und deutlich geschildert...
Auf Hilfe hoffend
chesstiger
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 366613
Url: https://administrator.de/forum/failover-system-mit-edgerouter-routingfehler-366613.html
Ausgedruckt am: 14.04.2025 um 00:04 Uhr