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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2931599274
Url: https://administrator.de/contentid/2931599274
Ausgedruckt am: 14.11.2024 um 11:11 Uhr
32 Kommentare
Neuester Kommentar
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.
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.
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.
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 @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.
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
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.
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.
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" ?!
Sagen Dir doch alle die ganze Zeit.
lks
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.
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.
Bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?