32
Routen auf ein gleiches Netz mit 2 Metriken und GWs?
Ich habe auf zwei EdgeRoutern ein VRRP laufen. Nun ist zum ersten Mal der "Haupt-Router" aktiv und routet auch wunderbar. Nur habe ich auf meinen Clients sowieso das Problem das ich dort statische Routen für die Netze hinter den Routern eintragen muss weil diese nicht mein Default GW sind. Aber nun mal zum eigentlichen Problem: Wenn nur der eine "Backup"-EdgeRouter aktiv ist funktioniert Ping und SSH auf die Geräte in den Netzen hinter dem ER. Wenn jetzt aber der "Haupt-Router" die GW-IPs übernimmt sollte eigentlich, dadurch das der "Backup-Router" auch Adressen in den Netzen haben muss/hat meine statische Route weiter funktionieren. (Auf die Idee war ich vorher nicht gekommen) Was allerdings nur halbwegs funktioniert, habe dann erstmal mit einer größeren Metric noch mal statische Routen für die Netze eingetragen mit der "WAN"-IP des Haupt-Router als GW. Pingen kann ich die Geräte wunderbar, nur SSH geht nicht mehr. Auch nicht mit nur einer Route auf den Backup-Router. ????
Kann mir einer von euch helfen? (Stichwort: Murphy und Schwarmintelligenz
) )
Danke schonmal im vorraus
Kann mir einer von euch helfen? (Stichwort: Murphy und Schwarmintelligenz
) )Danke schonmal im vorraus
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2931599274
Url: https://administrator.de/contentid/2931599274
Printed on: April 19, 2024 at 19:04 o'clock
32 Comments
Latest comment
Nutzt du die Geräte-IP als Gateway-IP oder die VRRP-IP? Es muss nämlich die VRRP-IP sein.
Und es muss auf beiden Seiten des Routers erfolgen. Es funktioniert nämlich nicht, wenn im einen Netzwerk der Master-Router das aktive Gateway ist und im anderen Netzwerk der Backup-Router.
Da scheinbar noch ein dritter Router im Spiel zu sein scheint, zumindest deiner Beschreibung nach, wäre erstmal Reorganisation an dieser Stelle wichtiger als die Inbetriebnahme von VRRP, welches bei funktionierendem Routing unbemerkbar erfolgen kann.
Und es muss auf beiden Seiten des Routers erfolgen. Es funktioniert nämlich nicht, wenn im einen Netzwerk der Master-Router das aktive Gateway ist und im anderen Netzwerk der Backup-Router.
Da scheinbar noch ein dritter Router im Spiel zu sein scheint, zumindest deiner Beschreibung nach, wäre erstmal Reorganisation an dieser Stelle wichtiger als die Inbetriebnahme von VRRP, welches bei funktionierendem Routing unbemerkbar erfolgen kann.
Ja das mit dem dritten Router spielt hier erstmal keine Rolle und kann auch nicht verändert werden. Und ich muss die geräte-IP nehmen da in meinem normalen LAN die Geräte kein VRRP machen nur in den Netzen dahinter.
Zitat von @melectronics:
Und ich muss die geräte-IP nehmen da in meinem normalen LAN die Geräte kein VRRP machen nur in den Netzen dahinter.
Und ich muss die geräte-IP nehmen da in meinem normalen LAN die Geräte kein VRRP machen nur in den Netzen dahinter.
Nein, du musst die VRRP-IP nehmen. Diese wird im Failover-Fall automatisch auf den aktiven Router gebunden.
Für deine Clients im LAN ist immer die VRRP-IP das Gateway - denn deine Clients im LAN bekommen so nicht mit, welcher Router gerade aktiv ist und welcher nicht.
Ich muss glaube ich mal etwas zeichnen das versteht man sonst nicht😅
Aber danke für die Erklärungsansätze
Aber danke für die Erklärungsansätze
Zitat von @melectronics:
Ja das mit dem dritten Router spielt hier erstmal keine Rolle und kann auch nicht verändert werden. Und ich muss die geräte-IP nehmen da in meinem normalen LAN die Geräte kein VRRP machen nur in den Netzen dahinter.
Ja das mit dem dritten Router spielt hier erstmal keine Rolle und kann auch nicht verändert werden. Und ich muss die geräte-IP nehmen da in meinem normalen LAN die Geräte kein VRRP machen nur in den Netzen dahinter.
Dann funktioniert das nicht.
lks
Wenn du auf der WAN-Seite kein VRRP fahren kannst, dann klappt es einfach nicht. Du brauchst für deine Konstruktion in jedem Fall volle Verfügungsgewalt über alle betroffenen Router, damit es überhaupt funktionieren kann.
Statt VRRP könnte man wan-seitig auch ein Routingprotokoll sprechen und müsste dann auf den ER dafür sorgen, dass die nur propagieren, wenn die lan-seitig der VRRP-Master sind, aber der Konfigurationsaufwand schließt auch wieder den dritten Router ein und ist deutlich größer. Alle drei Router müssen dann auch ein gemeinsames Routingprotokoll beherrschen, was schnell genug konvergiert.
Statt VRRP könnte man wan-seitig auch ein Routingprotokoll sprechen und müsste dann auf den ER dafür sorgen, dass die nur propagieren, wenn die lan-seitig der VRRP-Master sind, aber der Konfigurationsaufwand schließt auch wieder den dritten Router ein und ist deutlich größer. Alle drei Router müssen dann auch ein gemeinsames Routingprotokoll beherrschen, was schnell genug konvergiert.
Soo hier kommt die Zeichnung
Soo hier kommt die Zeichnung
Das mit Routing Protokoll wird auf einem Speedport schonmal nichts
Zitat von @tikayevent:
Wenn du auf der WAN-Seite kein VRRP fahren kannst, dann klappt es einfach nicht. Du brauchst für deine Konstruktion in jedem Fall volle Verfügungsgewalt über alle betroffenen Router, damit es überhaupt funktionieren kann.
Statt VRRP könnte man wan-seitig auch ein Routingprotokoll sprechen und müsste dann auf den ER dafür sorgen, dass die nur propagieren, wenn die lan-seitig der VRRP-Master sind, aber der Konfigurationsaufwand schließt auch wieder den dritten Router ein und ist deutlich größer. Alle drei Router müssen dann auch ein gemeinsames Routingprotokoll beherrschen, was schnell genug konvergiert.
Wenn du auf der WAN-Seite kein VRRP fahren kannst, dann klappt es einfach nicht. Du brauchst für deine Konstruktion in jedem Fall volle Verfügungsgewalt über alle betroffenen Router, damit es überhaupt funktionieren kann.
Statt VRRP könnte man wan-seitig auch ein Routingprotokoll sprechen und müsste dann auf den ER dafür sorgen, dass die nur propagieren, wenn die lan-seitig der VRRP-Master sind, aber der Konfigurationsaufwand schließt auch wieder den dritten Router ein und ist deutlich größer. Alle drei Router müssen dann auch ein gemeinsames Routingprotokoll beherrschen, was schnell genug konvergiert.
Das mit Routing Protokoll wird auf einem Speedport schonmal nichts
Zitat von @tikayevent:
Wenn du auf der WAN-Seite kein VRRP fahren kannst, dann klappt es einfach nicht. Du brauchst für deine Konstruktion in jedem Fall volle Verfügungsgewalt über alle betroffenen Router, damit es überhaupt funktionieren kann.
Statt VRRP könnte man wan-seitig auch ein Routingprotokoll sprechen und müsste dann auf den ER dafür sorgen, dass die nur propagieren, wenn die lan-seitig der VRRP-Master sind, aber der Konfigurationsaufwand schließt auch wieder den dritten Router ein und ist deutlich größer. Alle drei Router müssen dann auch ein gemeinsames Routingprotokoll beherrschen, was schnell genug konvergiert.
Wenn du auf der WAN-Seite kein VRRP fahren kannst, dann klappt es einfach nicht. Du brauchst für deine Konstruktion in jedem Fall volle Verfügungsgewalt über alle betroffenen Router, damit es überhaupt funktionieren kann.
Statt VRRP könnte man wan-seitig auch ein Routingprotokoll sprechen und müsste dann auf den ER dafür sorgen, dass die nur propagieren, wenn die lan-seitig der VRRP-Master sind, aber der Konfigurationsaufwand schließt auch wieder den dritten Router ein und ist deutlich größer. Alle drei Router müssen dann auch ein gemeinsames Routingprotokoll beherrschen, was schnell genug konvergiert.
Ich dachte halt einfach das man zwei Routen mit unterschiedlicher Metrik anlegen kann und dann nimmt er wenn die erste funktioniert (192.168.3.4) halt die erste und wenn nicht die zweite (192.168.3.5)
Und warum kannst Du zum Speedport hin kein VRRP machen?
Und warum liegt da
lks
Der Fehler liegt auf der Hand! Ist wie Kollege @LordGurke schon sagt, der TO hat das Grundprinzip von VRRP vermutlich nicht verstanden und fälschlicherweise die physischen IPs der VRRP Member unsinnigerweise in den Routes der Clients eingetragen.
Next Hop Gateway für die Clients bei Gateway oder Routen ist aber immer die VRRP VIP Adresse der Systeme!
Siehe dazu auch HIER!
Next Hop Gateway für die Clients bei Gateway oder Routen ist aber immer die VRRP VIP Adresse der Systeme!
Siehe dazu auch HIER!
Zitat von @aqui:
Der Fehler liegt auf der Hand! Ist wie Kollege @LordGurke schon sagt, der TO hat das Grundprinzip von VRRP vermutlich nicht verstanden und fälschlicherweise die physischen IPs der VRRP Member unsinnigerweise in den Routes der Clients eingetragen.
Next Hop Gateway für die Clients bei Gateway oder Routen ist aber immer die VRRP VIP Adresse der Systeme!
Siehe dazu auch HIER!
Der Fehler liegt auf der Hand! Ist wie Kollege @LordGurke schon sagt, der TO hat das Grundprinzip von VRRP vermutlich nicht verstanden und fälschlicherweise die physischen IPs der VRRP Member unsinnigerweise in den Routes der Clients eingetragen.
Next Hop Gateway für die Clients bei Gateway oder Routen ist aber immer die VRRP VIP Adresse der Systeme!
Siehe dazu auch HIER!
Das weiß ich, die Clients in den Netzen dahinter funktionieren ja auch ohne Probleme aber ich kann sie halt über die Routen von dem äußeren LAN nicht erreichen. und was ist der "TO"
Zitat von @Lochkartenstanzer:
Und warum kannst Du zum Speedport hin kein VRRP machen?
Und warum liegt daStroh-Rum ein Speedport rum? Der ist da fehlt am Platz.
lks
Und warum kannst Du zum Speedport hin kein VRRP machen?
Und warum liegt da
lks
Weil er es nicht unterstützt? Und weil der da sein muss wegen Internet und Telefon von mit-Hausbewohnern.
Zitat von @melectronics:
Ich dachte halt einfach das man zwei Routen mit unterschiedlicher Metrik anlegen kann und dann nimmt er wenn die erste funktioniert (192.168.3.4) halt die erste und wenn nicht die zweite (192.168.3.5)
Ich dachte halt einfach das man zwei Routen mit unterschiedlicher Metrik anlegen kann und dann nimmt er wenn die erste funktioniert (192.168.3.4) halt die erste und wenn nicht die zweite (192.168.3.5)
Nein, woher soll der Router denn wissen, welches Gateway denn jetzt zuständig ist? Der Router könnte es nur anhand des Interfacestatus machen, aber da beide über das gleiche Interface gehen, wird ein Ausfall gar nicht erkannt. Dafür wäre dann ein Routingprotokoll nötig, welches ja nicht verfügbar ist.
Also muss die ER dafür sorgen, dass im Fehlerfall wanseitig nur das Interface des Master oben ist.
Das ist ja mein Problem das beide Router Up sind aber der eine die IP Adressen übernimmt (192.168.x.1)
Und ich dachte mein Windows Laptop ist dann anhand der metric so daß er schaut: erreiche ich das Ziel über die erste route --> wenn nicht versuche ich es über die zweite?
Und ich dachte mein Windows Laptop ist dann anhand der metric so daß er schaut: erreiche ich das Ziel über die erste route --> wenn nicht versuche ich es über die zweite?
Zitat von @tikayevent:
Nein, woher soll der Router denn wissen, welches Gateway denn jetzt zuständig ist? Der Router könnte es nur anhand des Interfacestatus machen, aber da beide über das gleiche Interface gehen, wird ein Ausfall gar nicht erkannt. Dafür wäre dann ein Routingprotokoll nötig, welches ja nicht verfügbar ist.
Also muss die ER dafür sorgen, dass im Fehlerfall wanseitig nur das Interface des Master oben ist.
Zitat von @melectronics:
Ich dachte halt einfach das man zwei Routen mit unterschiedlicher Metrik anlegen kann und dann nimmt er wenn die erste funktioniert (192.168.3.4) halt die erste und wenn nicht die zweite (192.168.3.5)
Ich dachte halt einfach das man zwei Routen mit unterschiedlicher Metrik anlegen kann und dann nimmt er wenn die erste funktioniert (192.168.3.4) halt die erste und wenn nicht die zweite (192.168.3.5)
Nein, woher soll der Router denn wissen, welches Gateway denn jetzt zuständig ist? Der Router könnte es nur anhand des Interfacestatus machen, aber da beide über das gleiche Interface gehen, wird ein Ausfall gar nicht erkannt. Dafür wäre dann ein Routingprotokoll nötig, welches ja nicht verfügbar ist.
Also muss die ER dafür sorgen, dass im Fehlerfall wanseitig nur das Interface des Master oben ist.
Aber Ping geht ja durch ohne Probleme. Auch nur mit einer Route auf den Router der die IP Adressen gar nicht hat momentan
Also muss die ER dafür sorgen, dass im Fehlerfall wanseitig nur das Interface des Master oben ist.
Das ist bei VRRP ein relativ primitiver Algorithmus.Beide Router sind ja völlig identisch konfiguriert. Sie routen also beide parallel in ihre Zielnetze, da ja auch die Routen dahin auf ihnen völlig identisch konfiguriert ist.
Ein Client der als Gateway jeweils die eine oder andere physische IP des Member Routers nutzt kommt also immer ans Ziel. Logisch, denn beide Member Router routen ja gleich.
Genau deshalb ist es auch zwingend erforderlich das die VRRP Member Router immer gleiche Routing Tabellen haben!! Logisch, denn beide müssen bei einem etwaigen Ausfalls eines Members ja ebenso alle Ziele erreichen können.
Es wäre ja Blödsinn wenn die Routing Tabelle unterschiedlich wäre. VRRP sorgt nicht dafür das die Routing Tabelle der Systeme synchrionisiert wird. Das muss der NetzAdmin mit der Konfig machen. Wie bereits oben gesagt: VRRP sorgt lediglich für die IP Gateway Adressen Redundanz. Nicht mehr und nicht weniger...
Relevant ist immer nur die VRRP VIP IP für den Client. Denn nur der Master Router hält diese, sprich antwortet auf einem ARP Request des Clients auf diese IP, nicht der Backup Router.
Deshalb ist es essentiell das die Clients immer die VRRP VIP als Gateway oder next Hop Gateway definiert haben!!
Der Master routet dann den Traffic.
Fällt der Master aus oder ist der Heartbeat Link zwischen den beiden VRRP Membern unterbrochen wechselt die VIP auf den Standby Router, sprich der antwortet jetzt auf ARPs nach der VIP IP und dann routet der.
VRRP ist nichts anderes als eine simple Gateway IP Adress Redundanz und hat nicht das Geringste mit intelligentem Routing nach Metriken usw. zu tun wie es dynamische Routing Protokolle machen. Kollege @tikayevent hat absolut Recht mit seinem obigen Hinweis darauf.
Statt "denken" sollte der TO besser einmal in Ruhe nachdenken und sich die Mechanismen und Funktion des VRRP Protokolls noch einmal in aller Ruhe durchlesen und vor allem auch verstehen...!
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
Zitat von @aqui:
Beide Router sind ja völlig identisch konfiguriert. Sie routen also beide parallel in ihre Zielnetze, da ja auch die Routen dahin auf ihnen völlig identisch konfiguriert ist.
Ein Client der als Gateway jeweils die eine oder andere physische IP des Member Routers nutzt kommt also immer ans Ziel. Logisch, denn beide Member Router routen ja gleich.
Genau deshalb ist es auch zwingend erforderlich das die VRRP Member Router immer gleiche Routing Tabellen haben!! Logisch, denn beide müssen bei einem etwaigen Ausfalls eines Members ja ebenso alle Ziele erreichen können.
Es wäre ja Blödsinn wenn die Routing Tabelle unterschiedlich wäre. VRRP sorgt nicht dafür das die Routing Tabelle der Systeme synchrionisiert wird. Das muss der NetzAdmin mit der Konfig machen. Wie bereits oben gesagt: VRRP sorgt lediglich für die IP Gateway Adressen Redundanz. Nicht mehr und nicht weniger...
Relevant ist immer nur die VRRP VIP IP für den Client. Denn nur der Master Router hält diese, sprich antwortet auf einem ARP Request des Clients auf diese IP, nicht der Backup Router.
Deshalb ist es essentiell das die Clients immer die VRRP VIP als Gateway oder next Hop Gateway definiert haben!!
Der Master routet dann den Traffic.
Fällt der Master aus oder ist der Heartbeat Link zwischen den beiden VRRP Membern unterbrochen wechselt die VIP auf den Standby Router, sprich der antwortet jetzt auf ARPs nach der VIP IP und dann routet der.
VRRP ist nichts anderes als eine simple Gateway IP Adress Redundanz und hat nicht das Geringste mit intelligentem Routing nach Metriken usw. zu tun wie es dynamische Routing Protokolle machen. Kollege @tikayevent hat absolut Recht mit seinem obigen Hinweis darauf.
Statt "denken" sollte der TO besser einmal in Ruhe nachdenken und sich die Mechanismen und Funktion des VRRP Protokolls noch einmal in aller Ruhe durchlesen und vor allem auch verstehen...!
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
Also muss die ER dafür sorgen, dass im Fehlerfall wanseitig nur das Interface des Master oben ist.
Das ist bei VRRP ein relativ primitiver Algorithmus.Beide Router sind ja völlig identisch konfiguriert. Sie routen also beide parallel in ihre Zielnetze, da ja auch die Routen dahin auf ihnen völlig identisch konfiguriert ist.
Ein Client der als Gateway jeweils die eine oder andere physische IP des Member Routers nutzt kommt also immer ans Ziel. Logisch, denn beide Member Router routen ja gleich.
Genau deshalb ist es auch zwingend erforderlich das die VRRP Member Router immer gleiche Routing Tabellen haben!! Logisch, denn beide müssen bei einem etwaigen Ausfalls eines Members ja ebenso alle Ziele erreichen können.
Es wäre ja Blödsinn wenn die Routing Tabelle unterschiedlich wäre. VRRP sorgt nicht dafür das die Routing Tabelle der Systeme synchrionisiert wird. Das muss der NetzAdmin mit der Konfig machen. Wie bereits oben gesagt: VRRP sorgt lediglich für die IP Gateway Adressen Redundanz. Nicht mehr und nicht weniger...
Relevant ist immer nur die VRRP VIP IP für den Client. Denn nur der Master Router hält diese, sprich antwortet auf einem ARP Request des Clients auf diese IP, nicht der Backup Router.
Deshalb ist es essentiell das die Clients immer die VRRP VIP als Gateway oder next Hop Gateway definiert haben!!
Der Master routet dann den Traffic.
Fällt der Master aus oder ist der Heartbeat Link zwischen den beiden VRRP Membern unterbrochen wechselt die VIP auf den Standby Router, sprich der antwortet jetzt auf ARPs nach der VIP IP und dann routet der.
VRRP ist nichts anderes als eine simple Gateway IP Adress Redundanz und hat nicht das Geringste mit intelligentem Routing nach Metriken usw. zu tun wie es dynamische Routing Protokolle machen. Kollege @tikayevent hat absolut Recht mit seinem obigen Hinweis darauf.
Statt "denken" sollte der TO besser einmal in Ruhe nachdenken und sich die Mechanismen und Funktion des VRRP Protokolls noch einmal in aller Ruhe durchlesen und vor allem auch verstehen...!
https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
Was ist ein "TO"?
Das weiß ich ja, die Clients hinter den Routern haben auch die VIP als GW. Es geht darum das ich die Clients zwar pingen kann aber sie nicht mehr per SSH erreiche.
Und nach Metriken routen sollen ja auch nicht die ER´s sondern mein Windows Laptop
Bitte nicht immer alles zitieren, wie sind hier nicht senil! 
T= Thread Owner = Ersteller des Threads = Solche Akronyme sollte man als Forennutzer aber langsam mal kennen...
Es könnte natürlich auch an einer Accessliste im Hin- oder Rückroutenpfad liegen die zwar ICMP (Ping) erlaubt aber TCP 22 (SSH) blockiert. Dazu machst du aber keine Angaben.
T= Thread Owner = Ersteller des Threads = Solche Akronyme sollte man als Forennutzer aber langsam mal kennen...
das ich die Clients zwar pingen kann aber sie nicht mehr per SSH erreiche.
Dann rennt auf den Clients, wie üblich, eine lokale Firewall die den SSH Zugriff verbietet! Mit Routing hat das wenig zu tun, denn das die Rückroute ja stimmt siehst du an deinen erfolgreichen Pings.Es könnte natürlich auch an einer Accessliste im Hin- oder Rückroutenpfad liegen die zwar ICMP (Ping) erlaubt aber TCP 22 (SSH) blockiert. Dazu machst du aber keine Angaben.
Ich habe aber keine Firewall aktiviert oder eingerichtet, und wenn nur der eine Router aktiv geht es ja auch.
Deswegen verstehe ich das ja nicht, weil an der route kann es ja wie du sagst nicht liegen wenn Pings durchgehen. Aber es ging halt erst nicht mehr als ich den anderen Router mal in Betrieb hatte (hat andere Gründe wieso nicht)
Deswegen verstehe ich das ja nicht, weil an der route kann es ja wie du sagst nicht liegen wenn Pings durchgehen. Aber es ging halt erst nicht mehr als ich den anderen Router mal in Betrieb hatte (hat andere Gründe wieso nicht)
Ok, das mit zitieren wusste ich nicht, sorry. Ich wollte nur das man weiß auf was für eine Nachricht sich meine bezieht. Weil antworten wie in einem Chat gibt es hier ja nicht. Und das Akronym TO kannte ich tatsächlich noch nicht (
(und wenn nur der eine Router aktiv geht es ja auch.
Zeigt aber klar das beide Router dann unterschiedliche Routing Tabellen haben, ergo einen Konfig Fehler.Beide Router sollten unabhängig voneinenader zu den Zielen routen können.
Kannst du ganz einfach testen und verifizieren indem du jeweils einen Router mal stromlos machst.
Der Client sollte egal mit welchem Router immer zum Ziel geroutet werden.
Wenn nicht haben die Router unterschiedliche Routing Tabellen was dann ein Fehler ist.
Habe das jetzt mal getestet
Folgendes ist dabei rausgekommen:
Nur der ER-12 aktiv + Route auf dessen "WAN"-IP = Funktioniert
Nur der ER-X aktiv + Route auf dessen "WAN"-IP = Funktioniert
Beide aktiv + Zwei Routen auf dessen "WAN"-IPs + unterschiedliche Metriken bei den Routen = Funktioniert nicht weil immer die erste genommen wird zum ER-X. Und von dem kann ich nicht/bzw. sehr sehr instabil auf die Geräte hinter den Router(n) kommen wenn der ER-12 VRRP-Master ist.
(Ping geht trotzdem aber SSH nicht)
Folgendes ist dabei rausgekommen:
Nur der ER-12 aktiv + Route auf dessen "WAN"-IP = Funktioniert
Nur der ER-X aktiv + Route auf dessen "WAN"-IP = Funktioniert
Beide aktiv + Zwei Routen auf dessen "WAN"-IPs + unterschiedliche Metriken bei den Routen = Funktioniert nicht weil immer die erste genommen wird zum ER-X. Und von dem kann ich nicht/bzw. sehr sehr instabil auf die Geräte hinter den Router(n) kommen wenn der ER-12 VRRP-Master ist.
(Ping geht trotzdem aber SSH nicht)
Wozu auch 2 Routen? Das ist bei VRRP doch völliger Blödsinn und kontraproduktiv.
Eine einzige Route auf die VIP und gut iss. Alles andere ist bei VRRP ja unsinnig.
Vermutlich ist deine VRRP und Client bzw. Routing Konfig, wie oben schon, vermutet falsch oder fehlerhaft durch diese "Denkfehler" ?!
Eine einzige Route auf die VIP und gut iss. Alles andere ist bei VRRP ja unsinnig.
Funktioniert nicht weil immer die erste genommen wird
Logisch bei gleichen Routen wenn die "erste" eine bessere Metrik hat und die Gateway IP immer erreichbar ist.Vermutlich ist deine VRRP und Client bzw. Routing Konfig, wie oben schon, vermutet falsch oder fehlerhaft durch diese "Denkfehler" ?!
Achso du meinst also die "WAN-Seite" auch noch als VRRP ausbauen?
Sagen Dir doch alle die ganze Zeit.
lks
Ja, ich muss jetzt erstmal nachdenken. Das wollte ich eigentlich verhindern
Aber danke erstmal
Aber danke erstmal
Das wollte ich eigentlich verhindern
Muss ja auch nicht sein. Bringt auch gar nichts denn am WAN Segment ist ja nur ein dummer Speedport der noch nichteinmal statische Routen kann.Der "sieht" so oder so die 2 Router durch deren NAT an ihren Ports in dem Netz nur als dumme Endgeräte. Der rafft ja gar nicht das das Router sind.
Dumm und blöd ist das nur wenn in diesem "WAN/Speedport" Segment noch Endgeräte sind. Das wäre vom Design ziemlich dumm, denn diese Endgeräte bräuchten dann statische Permanentrouten und können nicht damit umgehen das VRRP die Gateways umstellen kann.
Sehr schlecht geplantes Design also.
Da gehören keine Endgeräte rein.
Wenn man es unbedingt dennoch will oder nicht anders kann, dann ist es wie Kollege @Lochkartenstanzer schon sagt: Dann ist auch auf dem WAN Segment VRRP Pflicht, denn wie sollten die Endgeräte sonst mit den doppelten Gateways umgehen?!
Sinnvoller vom Design ist es aber diese Endgeräte in ein separates VLAN an die VRRP Router zu packen.
Dumm und blöd ist das nur wenn in diesem "WAN/Speedport" Segment noch Endgeräte sind. Das wäre vom Design ziemlich dumm, denn diese Endgeräte bräuchten dann statische Permanentrouten und können nicht damit umgehen das VRRP die Gateways umstellen kann.
Diese Permanent-Routen versuche ich ja die ganze Zeit einzurichten. Aber eben für beide Router gleichzeitig damit ich mich nicht ständig drum kümmern muss aber das geht wohl nicht so einfach wie ich es gerne hätte.Die GWs auf der WAN-Seite der beiden Router stellen sich ja nicht um. Aber was ich nicht verstehe ist wieso ich wenn der ER-12 die "x.1"-Addresse per VRRP hat und ich trotzdem nur eine statische Route auf den ER-X einrichte ich die Geräte hinter den Routern pingen kann aber nicht anders erreichen kann. (Firewall ist alles frei)
Sehr schlecht geplantes Design also.
Das weiß ich. Das ist auch nicht so wie ich es gerne hätte, aber da sind so Leute noch mit im Haus die dann Stress machen würden wenn ich das umbaue...weil die ER´s nicht 24/7 laufen können/dürfen/sollen wie auch immer.Wenn man es unbedingt dennoch will oder nicht anders kann, dann ist es wie Kollege @Lochkartenstanzer schon sagt: Dann ist auch auf dem WAN Segment VRRP Pflicht, denn wie sollten die Endgeräte sonst mit den doppelten Gateways umgehen?!
Wieso doppelte GWs? Wegen der beiden Routen auf die zwei unterschiedlichen Router oder wie?Diese Permanent-Routen versuche ich ja die ganze Zeit einzurichten.
Das ist ziemlich blöd, den normal kommt Traffic ja immer nur vom Master Router.Es sei denn du hast ein gutes Design und verteilst die Master Router zwischen deinen 3 Segmenten um die Bandbreite und Performance sinnvoll zwischen den 2 Systemen auszunutzen. Das machst du mit der VRRP Priority. Siehe Mikrotik Tutorial oben...
Wenn du also nur stumpf und banal einen als Master betreibst kommt ja nur von dem Traffic im WAN Segment an. Es würde also reichen wenn Clients einen Route dahin haben.
Hat aber den gravierenden Nachteil das im Falle des master Ausfalls nichts mehr geht.
2 statische Routen würden ein Session basiertes Balancing machen. Ist aber sinnfrei denn die Route hält ja immer nur der Master und sowas führt dann zu asymetrischen Routing.
Unterschiedliche Metriken greifen nicht solange das Gateway physisch erreichbar ist.
Alles Mist also mit so einem kranken und falschen Design was kein Netzwerker so machen würde. Es bleibt also dabei:
- Entweder VRRP auch im WAN Segment mit einer VIP
- Oder: Alle Endgeräte raus und in ein separates IP Segment an den VRRP Routern und NUR den Router an den WAN Ports.
Ja ich weiß das dass momentan grottig ist. Will das so auch eigentlich nicht, aber wie gesagt ich entscheide das (noch) nicht. Ich werde jetzt erstmal mein altes Konstrukt wieder herstellen ohne VRRP in den Routernetzen und dann läuft das erstmal wieder.
Das dass dann unnötig gewesen wäre, diese Frage hier zu stellen ist mir klar. Aber danke trotzdem für eure Mühe! 😀😀😀
Will das so auch eigentlich nicht, aber wie gesagt ich entscheide das (noch) nicht. Ich werde jetzt erstmal mein altes Konstrukt wieder herstellen ohne VRRP in den Routernetzen und dann läuft das erstmal wieder.Das dass dann unnötig gewesen wäre, diese Frage hier zu stellen ist mir klar. Aber danke trotzdem für eure Mühe! 😀😀😀
Bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!!
How can I mark a post as solved?
How can I mark a post as solved?
