8
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 177850
Url: https://administrator.de/contentid/177850
Ausgedruckt am: 23.11.2024 um 12:11 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.
Hallo,
eben das geht ja nicht. R2 macht praktisch gar nichts mehr (kein Ping, kein Zugriff, kein Routing) - außer OSPF.
Die Frage ist aber allgemeiner Natur. Es könnte ja auch mal passieren, dass das Kabel was ich mit dem X markiert habe kaputt geht - der Effekt wäre ja der selbe.
Mikrotik
Du hast die Router verwechselt. R2 ist hier der Problemfall
Das fällt bei Mikrotik leider weg - müsste ich den Herren mal vorschlagen.
Ich hab mal überlegt: 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 (es gibt ja noch andere Router in den Netzen). Was würde dann passieren wenn R2 keinen DR mehr findet?
Grüße
erstens könntest du OSPF auf Router R2 deaktivieren.
eben das geht ja nicht. R2 macht praktisch gar nichts mehr (kein Ping, kein Zugriff, kein Routing) - außer OSPF.
Die Frage ist aber allgemeiner Natur. Es könnte ja auch mal passieren, dass das Kabel was ich mit dem X markiert habe kaputt geht - der Effekt wäre ja der selbe.
Mit was für Geräte hast du es zu tun?
Mikrotik
Vermutlich ist der Port an R1 physisch aktiv
Du hast die Router verwechselt. R2 ist hier der Problemfall
wenn die am Port angeschlossensn Komponenten UDLD oder ein anderes Link Detection protokoll supporten.
Das fällt bei Mikrotik leider weg - müsste ich den Herren mal vorschlagen.
Ich hab mal überlegt: 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 (es gibt ja noch andere Router in den Netzen). Was würde dann passieren wenn R2 keinen DR mehr findet?
Grüße
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
So wie ich es verstanden habe weigert sich ein Router mit Priority 0 DR/BDR zu werden.
R2 wäre dann also bei der Situation oben in einem Netzwerk ohne DR/BDR.
Der Sinn ist folgende Überlegung: "Wenn du als Router allein in einer Area bist, dann betrachte die Area als Down".
Das ist IMHO das einzig sinnvolle was auch in der Zukunft bei Problemen dieser Art helfen würde.
Sicher.
Aber da die anderen > 20 Router mit AFAIR selber Softwareversion teilweise schon monatelang laufen scheint das ein eher seltenes Problem zu sein.
Grüße
Max
A priority value of zero indicates an interface which is not to be elected as DR or BDR. The state of the interface with priority zero will be DROTHER
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a008 ...R2 wäre dann also bei der Situation oben in einem Netzwerk ohne DR/BDR.
Richtig. Die Frage ist was du damit bezwecken möchtest? Hängt eigentlich von Netzwerkdesign ab.
Der Sinn ist folgende Überlegung: "Wenn du als Router allein in einer Area bist, dann betrachte die Area als Down".
Das ist IMHO das einzig sinnvolle was auch in der Zukunft bei Problemen dieser Art helfen würde.
Hmm... d.h. das Problem könnte an einem anderen Standort auch noch auftauchen?
Sicher.
Aber da die anderen > 20 Router mit AFAIR selber Softwareversion teilweise schon monatelang laufen scheint das ein eher seltenes Problem zu sein.
Grüße
Max
Moin,
hast du neue Informationen zu dem Thread?
Grüße,
Dani
hast du neue Informationen zu dem Thread?
Grüße,
Dani
Nein, ich habe es momentan so "gelöst", dass R1 und R2 nicht DR/BDR werden können (es gibt in area1 noch weitere Router).
