OSPF Split Broadcast Network Problem
Hallo,
ich habe vereinfach dargestellt folgendes Netzwerk mit OSPF:
Durch einen Softwarebug hat jetzt R2 zwar weiter an OSPF teilgenommen, aber keine Pakete mehr weitergeleitet, also musste ich ihn aus der Ferne aus dem Netz bekommen.
Dazu habe ich den entsprechenden Switch-Port deaktiviert (war die einzige Möglichkeit):
Das hat leider mein Problem nicht gelöst, denn jetzt ging zwar aller Traffic in area1 über R1, aber in area 0 haben immer noch alle anderen Router den Weg über R2 benutzt, da er ja scheinbar noch mit area 1 verbunden war.
Sogesehen haben also immer noch die beiden Router area 1 veröffentlicht, aber nur einer hätte es gedürft.
Wie kann ich das Problem lösen?
Grüße
Max
ich habe vereinfach dargestellt folgendes Netzwerk mit OSPF:
Durch einen Softwarebug hat jetzt R2 zwar weiter an OSPF teilgenommen, aber keine Pakete mehr weitergeleitet, also musste ich ihn aus der Ferne aus dem Netz bekommen.
Dazu habe ich den entsprechenden Switch-Port deaktiviert (war die einzige Möglichkeit):
Das hat leider mein Problem nicht gelöst, denn jetzt ging zwar aller Traffic in area1 über R1, aber in area 0 haben immer noch alle anderen Router den Weg über R2 benutzt, da er ja scheinbar noch mit area 1 verbunden war.
Sogesehen haben also immer noch die beiden Router area 1 veröffentlicht, aber nur einer hätte es gedürft.
Wie kann ich das Problem lösen?
Grüße
Max
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 177850
Url: https://administrator.de/forum/ospf-split-broadcast-network-problem-177850.html
Ausgedruckt am: 24.12.2024 um 20:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
erstens könntest du OSPF auf Router R2 deaktivieren.
Bis zum beheben des Software Bugs sollte das ja nicht viel ausmachen da durch dem Route nichts erreichbar ist.
Die Area an R2 solltest du am R2 direkt deaktivieren und die gekappte Verbindung in Area 1 am Switch wieder aktivieren.
Somit kannst du die Area 1 zwar nur noch über den R1 erreichen aber immerhin vollständig.
Mit was für Geräte hast du es zu tun?
Cisco?
area 2 stub no-summary
area 2 default cost 1-65535
!interface-cost : Unsigned integer value expressed as the link-state metric. It can be a value in the range from 1 to 65535.
<code/>
sollte dazu führen das die Netze weiter propagiert werden, aber mit höheren Kosten und somit nicht genutzt werden.
brammer
erstens könntest du OSPF auf Router R2 deaktivieren.
Bis zum beheben des Software Bugs sollte das ja nicht viel ausmachen da durch dem Route nichts erreichbar ist.
Die Area an R2 solltest du am R2 direkt deaktivieren und die gekappte Verbindung in Area 1 am Switch wieder aktivieren.
Somit kannst du die Area 1 zwar nur noch über den R1 erreichen aber immerhin vollständig.
Mit was für Geräte hast du es zu tun?
Cisco?
area 2 stub no-summary
area 2 default cost 1-65535
!interface-cost : Unsigned integer value expressed as the link-state metric. It can be a value in the range from 1 to 65535.
<code/>
sollte dazu führen das die Netze weiter propagiert werden, aber mit höheren Kosten und somit nicht genutzt werden.
brammer
Hallo Max !
Vermutlich ist der Port an R1 physisch aktiv und damit ist das Netzwerk dann aktiv am Router und er annouced das weiterhin im OSPF Prozess, was dann zu diesem Effekt führt. Leider sagst du nicht wie die Anbindung an die Area 1 Wolke ist aber vermutlich ist das der Fall. Der Router verhält sich dann aus seiner sicht korrekt.
Lösen kann man das wenn die am Port angeschlossensn Komponenten UDLD oder ein anderes Link Detection protokoll supporten.
Wenn das der Fall ist dann geht der Netzwerk Status auf Down wenn der Link unterprochen wurde, egal ob der Port noch physisch einen Link hat.
Ansonsten hilft es nur den Port an R1 zu deaktivieren. Wenn das nicht geht ein temporäres Redesign wie Kollege brammer schon angedeutet hat. Einfacer ist es dann aber die Pfad Kosten am R1 Port künstlich hochzusetzen.
Damit wird zwar der Link noch announced aber der Weg via R2 hat dann eine bessere Cost und sollte dann preferiert werden.
Vermutlich ist der Port an R1 physisch aktiv und damit ist das Netzwerk dann aktiv am Router und er annouced das weiterhin im OSPF Prozess, was dann zu diesem Effekt führt. Leider sagst du nicht wie die Anbindung an die Area 1 Wolke ist aber vermutlich ist das der Fall. Der Router verhält sich dann aus seiner sicht korrekt.
Lösen kann man das wenn die am Port angeschlossensn Komponenten UDLD oder ein anderes Link Detection protokoll supporten.
Wenn das der Fall ist dann geht der Netzwerk Status auf Down wenn der Link unterprochen wurde, egal ob der Port noch physisch einen Link hat.
Ansonsten hilft es nur den Port an R1 zu deaktivieren. Wenn das nicht geht ein temporäres Redesign wie Kollege brammer schon angedeutet hat. Einfacer ist es dann aber die Pfad Kosten am R1 Port künstlich hochzusetzen.
Damit wird zwar der Link noch announced aber der Weg via R2 hat dann eine bessere Cost und sollte dann preferiert werden.
Wenn ich bei R1 und R2 die OSPF DR Priority auf 0 setze sollten die beiden ja nicht mehr an der DR/BDR Election teilnehmen
Richtig. Die Frage ist was du damit bezwecken möchtest? Hängt eigentlich von Netzwerkdesign ab.Was würde dann passieren wenn R2 keinen DR mehr findet?
Er würde versuchen den BDR zu erreichen.Mikrotik
Hmm... d.h. das Problem könnte an einem anderen Standort auch noch auftauchen?Hast du eigentlich die Möglichkeit einen direkten Crosslink zwischen R1 und R2 zu schalten? Hätte den Vorteil, dass du egal welcher der beiden Router z.B. den Link ins WAN verliert oder aber Probleme mit dem Routing hast, von Rx auf Ry zugreifen kannst.
Grüße.
Dani
Wenn die Router Priority beidseitig auf 0 gesetzt wird nimmt OSPF ein anderes Kriterium um den DR/BDR zu bestimmen. Meist gewinnt dann der mit der niedrigsten IP Adresse sofern nicht noch eine Router ID oder Loopback vergeben ist die immer Priorität vor der physischen IP hat.
Wenn R2 keinen DR mehr findet also ganz allein und isoliert ist, dann deklariert er sich selber als DR.
Du solltest den Versuch mit der Path Cost machen und einfach den Pfad verschlechtern für die Übergangszeit. Das sollte dann reichen um einen eindeutigen Pfad zu wählen
Wenn R2 keinen DR mehr findet also ganz allein und isoliert ist, dann deklariert er sich selber als DR.
Du solltest den Versuch mit der Path Cost machen und einfach den Pfad verschlechtern für die Übergangszeit. Das sollte dann reichen um einen eindeutigen Pfad zu wählen