3 Subnetze, 2 OSPF-Bereiche - Funktioniert das?

Treten Probleme auf, wenn ich eine Topologie mit 3 Subnetzen und zwei OSPF-Bereichen habe, in denen sich ein Subnetz in BEREICH 0 und die anderen beiden Subnetze in BEREICH 1 befinden?

Zum Beispiel:

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]

In Bezug auf die Frage der Aufteilung von Bereich 1 über das Backbone (Bereich 0):

[Bereich 1, Subnetz 1] --- [ABR # 1] --- [Bereich 0, Subnetz 2] --- [ABR # 2] --- [Bereich 1, Subnetz 3]

[Bereich 1, Subnetz 1] --- [Router Nr. 1] --- [Bereich 0, Subnetz 2, Endgerät Nr. 1] --- [Router Nr. 2] --- [Bereich 0, Subnetz 2, Endgerät # 2] --- [Router # 3] --- [Bereich 1, Subnetz 3]

Kurze Antwort: Es gibt kein Problem mit Ihrem Vorschlag ...

Lange Antwort:

Selbst Peters Antwort, die argumentiert, dass die Wiederverwendung von Bereichsnummern ein schlechtes Design ist, bietet keinen Beweis dafür, dass dies ein schlechtes Design ist. Wenn Sie die von ihm verwendeten Hyperlinks untersuchen, gibt es keine Erklärung für unerwünschte Konsequenzen für dieses Design. Darüber hinaus ist das Argument, dass Sie möglicherweise Probleme beim Verbinden von R1 und R3 haben, unzureichend, da die Verbindung von R1 zu R3 in Bereich 0 oder Bereich 1 legitim konfiguriert werden kann, je nachdem, welchen Verkehr Sie übertragen möchten. Die Schwierigkeiten, die er erwähnt, sind ein falsches Dilemma.

In RFC 2328 können Sie in Abschnitt 3.7 OSPF explizit nicht zusammenhängende Nicht-Backbone-Bereiche verwenden (die im Folgenden als "Bereichspartitionen" bezeichnet werden):

    OSPF does not actively attempt to repair area partitions.  When
    an area becomes partitioned, each component simply becomes a
    separate area.  The backbone then performs routing between the
    new areas.  Some destinations reachable via intra-area routing
    before the partition will now require inter-area routing.
    ...  Also, the backbone itself must not partition.

Ob Sie also den vorgeschlagenen nicht zusammenhängenden Bereich 1 verwenden, ist nur eine Frage des Geschmacks. Einige Leute finden es unlogisch, die Konfiguration in Ihrem Diagramm zu verwenden. Diese Personen schlagen möglicherweise vor, dass Sie die OSPF-Bereichsnummern zusammenhalten. Sie müssten also [Bereich 1, Subnetz 3] auf Router 3 in [Bereich 3, Subnetz 3] ändern. Andere Leute sehen kein Problem bei der Wiederverwendung von Bereich 1, da OSPF-Bereichsnummern nur lokal für den Router von Bedeutung sind, der OSPF-Höllen erzeugt.

In jedem Fall sollten wir zugeben, dass OSPF ein bemerkenswert flexibles Protokoll ist. unabhängig von der Wahl der einen oder anderen Seite in dieser Debatte.

Dies wird funktionieren, aber es wäre eine schlechte Wahl für das Design (IMHO), es sei denn, Sie haben einen bestimmten Grund dafür.

Siehe diese Diskussion: Doppelte OSPF-Bereichs-IDs

Best Practices für OSPF

Empfohlene Best Practices für die OSPF-Konfiguration (anhand des SSM-Beispiels)

Best Practices für die OSPF-Bereichskonfiguration

Update Nr. 1 :

Der Vollständigkeit halber habe ich diese Situation mit Dyanmips nachgeahmt. Die Plattform war Cisco 3725s mit IOS Version 12.4 (15) T13.

R1 (lo0 1.1.1.1, f0 / 0 10.12.0.1) <-> R2 (lo0 2.2.2.2, f0 / 0 10.12.0.2, f0 / 1 10.23.0.2) <-> R3 (lo0 3.3.3.3, f0 / 0 10.23.0.3).

Loopback-Schnittstellen von R1 und R3 wurden in Bereich 1 platziert, alle anderen Schnittstellen befinden sich in Bereich 0.

Anschließend wurden Pings zwischen den Boxen R1 und R3 durchgeführt (z. B. R3 # ping ip 1.1.1.1 source 3.3.3.3), um die Konnektivität zu bestätigen.

Meiner Meinung nach würde ich diese Architektur immer noch scheuen. Mike macht absolut gültige Punkte (und Tests bestätigen), dass dies funktioniert. OSPF-Bereiche sind nützliche Tools zur Steuerung der Routenausbreitung und zur Reduzierung der Größe der Verbindungsstatusdatenbank des Routers. Sie dokumentieren jedoch (zumindest für mich), dass "dieser" Teil des Netzwerks architektonisch von "diesem" getrennt sein soll. aus irgendeinem Grund Teil des Netzwerks.

Wenn Sie sich in Zukunft dafür entscheiden, R1 mit R3 zu verbinden und denselben Bereich # verwenden, haben Sie Glück gehabt und sich viele Probleme mit dem Ändern von Bereichsnummern oder der Verwendung virtueller Links erspart. Vielleicht ist dies ein Argument für die Verwendung von zwei Bereichs-IDs (0 und 1) überall - aber andererseits hatten Sie ursprünglich nicht die Absicht, dass R1 und R3 direkt kommunizieren können. zucken

Dies ist eine Frage des Stils und der persönlichen Vorlieben - es scheint keinen technischen Grund zu geben, warum dies nicht funktionieren sollte, und ich hatte nie vor, etwas anderes darzustellen.

Update Nr. 2

Hinzufügen von Nicht-ASCII-Kunstdiagrammen von Verbindungen - linear und als Dreieck gezeichnet. Was ist zwischen R1 & R3 vorgesehen? Soll area1 zusammenhängend oder getrennt sein?

Normalerweise müssen Sie virtuelle Links verwenden, um über einen anderen Bereich außerhalb von Bereich 0 mit Bereich 0 zu sprechen, oder Sie verbinden 2 Teile von Bereich 0 über einen Bereich ungleich Null. Virtuelle Links gelten also nicht. Sie können einen nicht zusammenhängenden Bereich haben, wenn er nicht Bereich 0 ist, aber wie oben angedeutet, keine wirklich gute Idee. Davon abgesehen funktioniert die von Ihnen vorgeschlagene Topologie ohne virtuelle Links.