In der Cisco IOS® Softwareversion 11.2 wurden als Reaktion auf die OSPF RFC 1793 Optionen für die Nachfragesteuerung für Open Shortest Path First (OSPF) eingeführt. OSPF sendet alle 10 Sekunden Hellos und aktualisiert seine LSAs (Link-State Advertisements) alle 30 Minuten. Diese Funktionen wahren Nachbarbeziehungen und stellen sicher, dass die Link-State-Datenbanken korrekt sind und deutlich weniger Bandbreite als vergleichbare Funktionen in Routing Information Protocol (RIP) und Interior Gateway Routing Protocol (IGRP) nutzen. Aber selbst diese Menge an Datenverkehr ist bei Bedarf nicht wünschenswert. Die Verwendung von OSPF-Optionen für die Nachfragespeicherung unterdrückt Hello- und LSA-Aktualisierungsfunktionen. OSPF kann eine Anforderungsverbindung herstellen, um eine Adjacency zu bilden und die anfängliche Datenbanksynchronisierung durchzuführen. Die Adjacency bleibt auch nach dem Ausfall von Layer 2 des Lastkreislaufs aktiv.
Die Cisco IOS-Version 12.1(2)T bietet eine neue Funktion zur Reduzierung von Flooding-Vorgängen für OSPF. Diese Funktion soll den Datenverkehr durch eine regelmäßige Aktualisierung von LSAs in OSPF-Domänen mit einer großen Anzahl von LSAs minimieren. Anders als bei der OSPF-Laststromführung wird die Reduzierung von Überschwemmungen in der Regel auf Mietleitungen konfiguriert. Bei der Reduzierung von Überflutungen wird dieselbe Technik wie bei den Nachfragesekulturen verwendet, um die regelmäßige LSA-Aktualisierung zu unterdrücken. Diese Funktion wird zur Standardisierung in die IETF OSPF-Arbeitsgruppe eingereicht.
Die Leser dieses Dokuments sollten folgende Themen kennen:
OSPF
IGRP
RIP
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
Cisco IOS Version 12.1(2)T und höher
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
OSPF-over-Demand-Schaltungen zeichnen sich durch zwei Hauptmerkmale aus, die es von einem normalen Schaltkreis unterscheiden.
Unterdrückte regelmäßige Hellos
Unterdrückte regelmäßige LSA-Aktualisierung
Wenn eine OSPF-Laststromführung für eine Verbindung konfiguriert wird, werden die periodischen OSPF-Hellos unterdrückt. Regelmäßige Hellos werden nur in einem Point-to-Point- und Point-to-Multipoint-Netzwerktyp unterdrückt. Bei jedem anderen Netzwerktyp werden OSPF-Hellos weiterhin über die Schnittstelle gesendet.
Regelmäßige LSA-Aktualisierungen, die alle 30 Minuten stattfinden, treten bei der OSPF-Laststromführung nicht auf. Wenn eine Nachfragesplitter eingerichtet ist, wird ein eindeutiges Optionbit (das DC-Bit) zwischen benachbarten Routern ausgetauscht. Wenn zwei Router das DC-Bit erfolgreich aushandeln, notieren sie es und legen ein bestimmtes Bit im LSA-Zeitalter fest, das als DoNotAge-Bit (DNA) bezeichnet wird. Das DNA-Bit ist das bedeutendste Bit im Feld LS Age. Durch die Einstellung dieses Bits wird das Altern des LSA beendet, und es werden keine regelmäßigen Updates gesendet.
Es gibt nur zwei Szenarien, in denen die regelmäßige LSA-Aktualisierung bei Verwendung der OSPF-Laststromkreis-Funktion erfolgt:
Wenn sich die Netzwerktopologie ändert
Wenn sich ein Router in der OSPF-Domäne befindet, der die Nachfragemissionen nicht verstehen kann
Erstens kann nicht viel getan werden, um die LSA-Aktualisierung zu beenden, da der Router die neuen LSA-Informationen senden muss, um den Nachbarn über die Topologieänderung zu aktualisieren.
Es gibt jedoch eine besondere Möglichkeit, das zweite Szenario zu behandeln. Der Area Border Router (ABR), der Router D im Netzwerkdiagramm unten ist, weiß, dass Router C keine DNA-LSAs verstehen kann, da das DC-Bit im Optionsfeld des von Router C generierten LSA eindeutig ist. In diesem Fall benachrichtigt der ABR, Router D, die nachfragefähigen Router, das LSA nicht mit dem DNS-Bit-Satz zu generieren, da ein Router das Bit nicht versteht ...
Dieses Netzwerkdiagramm zeigt ein Szenario, in dem die periodische LSA-Aktualisierung über einen Lastkreis gesendet wird:
Der ABR, Router D, erzeugt eine LSA-Indikation im Backbone, die alle Router im Backbone auffordert, keine DNA-LSAs zu generieren. Wenn Router A (ein anderer ABR) diese Anzeige erkennt, generiert LSA die Indikation LSA in andere Bereiche, mit Ausnahme des Backbone und eines Stub- oder nicht so-stubby Area (NSSA)-Bereichs. Diese Anzeige LSA für Router D ist unten dargestellt. Bei der Anzeige LSA handelt es sich um einen Typ-4-Summary-LSA, bei dem die Link-State-ID der ABR selbst und nicht der ASBR (Autonomous System Boundary Router) ist. Das heißt, dass sowohl die Link-State-ID als auch das Feld für den Werberouter identisch sind, wie hier gezeigt:
RouterD# show ip ospf database asbr-summary Adv Router is not-reachable LS age: 971 Options: (No TOS-capability, No DC) LS Type: Summary Links(AS Boundary Router) Link State ID: 141.108.1.129 (AS Boundary Router address) Advertising Router: 141.108.1.129 LS Seq Number: 80000004 Checksum: 0xA287 Length: 28 Network Mask: /0 TOS: 0 Metric: 16777215
Die Kennzahl einer Indikation LSA ist auf unendlich eingestellt. Die Link-State-ID und das Feld für den Werberouter ist immer die Router-ID des ABR, der die LSA-Angabe auslöst. Im obigen Netzwerkdiagramm ist die Verbindung zwischen den Routern A und B als Laststromkreis konfiguriert. Da es in Bereich 1 jedoch einen Router gibt, der nicht in der Lage ist, die DNA-LSAs zu verstehen, gibt es keine DNA-LSAs, die aus Bereich 1 stammen. Daher werden die regelmäßigen LSA-Aktualisierungen, die aus Bereich 1 stammen, über den Laststromkreis gesendet.
Es gibt nur zwei Bedingungen, die dazu führen, dass ein OSPF-ABR eine LSA-Anzeige generiert:
Im Netzwerk befindet sich ein Router, auf dem IOS 11.2 oder früher ausgeführt wird.
Im Netzwerk gibt es einen Router, der nicht von Cisco stammt und die die Nachfrageseite nicht unterstützt.
Konfigurieren Sie Area 2 als Stub oder NSSA-Bereich. Dadurch wird verhindert, dass die von Router D ausgehende Anzeige LSA von Router A in Bereich 2 gesendet wird, da Bereich 2 ein Stub-Bereich ist und die Angabe LSA (Typ 4 Summary LSA) nicht in den Stub-Bereich überflutet werden kann. Da für Bereich 2 keine LSA-Angabe angezeigt wird, werden die DNA-LSAs in Bereich 2 weiter generiert, und die Verbindung zwischen Routern A und B wird nicht angezeigt, da die regelmäßige LSA-Aktualisierung unterdrückt wird.
Cisco empfiehlt, die OSPF-Laststromkreise in Bereichen zu konfigurieren, die keine Backbone-Elemente sind, und diese Bereiche mit NSSA, Stub oder komplett stubby zu versehen (letztere sind vorzuziehen). Dadurch sollen die Informationen, die von anderen Bereichen in das Gebiet injiziert werden, das Verbrauchskreise enthält, auf ein Minimum reduziert werden. Dadurch wird der Umfang der Änderungen minimiert, was die OSPF-Nachfragemarkierung erhöhen kann. Weitere Informationen zur Fehlerbehebung in Szenarien, die die OSPF-Laststromfunktion beinhalten, finden Sie unter Why OSPF Demand Circuit Keeps Bringing The Link.
Wenn Sie eine ähnliche Situation wie oben haben und die Nachfrageseite ebenfalls Teil des Backbone ist, können Sie diese Lösung nicht verwenden, da der Backbone-Bereich nicht als Stub oder NSSA konfiguriert werden kann.
Das Konfigurationsaufgabenbeispiel in diesem Abschnitt zeigt die erforderliche Konfiguration zum Erstellen eines Abfragekreises. Nur eine Seite muss über die Schnittstelle den Befehl für die Nachfragemarkierung verfügen, da diese Funktion im Hello-Paket automatisch ausgehandelt wird, wenn die andere Seite die Nachfragemarkierung verstehen kann. Wenn die Nachfragemarke nicht verstanden werden kann, ignoriert sie diese Option.
RouterA# show run interface Serial0 interface Serial 0 encapsulation frame-relay ip address 141.108.1.1 255.255.255.0 ip ospf network-type point-to-mutipoint ip ospf demand-circuit !
Hinweis: Sie können die Verbrauchsschaltung für jeden Netzwerktyp verwenden, obwohl Hellos nur in Point-to-Point- oder Point-to-Multipoint-Netzwerktypen unterdrückt werden.
Die Funktion zur Reduzierung von OSPF-Flooding ist eine geringfügige Änderung der Nachfragemissionen, die darauf ausgelegt ist, den zusätzlichen Datenverkehr bei Verbindungen zu reduzieren, die durch eine regelmäßige LSA-Aktualisierung entstehen. Es wird derselbe Mechanismus verwendet, um eine regelmäßige LSA-Aktualisierung zu vermeiden. Im Allgemeinen sind Router nicht sofort mit der Verbindung verbunden und können nicht identifizieren, ob sie als Nachfragemarke oder als Flooding Reduction Link konfiguriert ist. Die Datenbankdarstellung beider Verbindungstypen ist identisch.
Der Hauptunterschied zwischen Hochwasserreduzierung und Nachfragemissionen besteht darin, dass frühere LSA-Aktualisierungen nur in regelmäßigen Abständen unterdrückt werden. Es werden keine periodischen Hello-Pakete unterdrückt. Daher wird durch die Flooding-Funktion die Erkennung eines ausfallenden Nachbarrouters nicht beeinträchtigt.
Flooding Reduction Links haben dieselben Einschränkungen wie Nachfragemissionen. Insbesondere müssen alle Router in diesem Bereich die Demand Circuit-Funktion unterstützen, damit die Flooding-Reduzierung funktioniert. Auch Fehlerbehebungsverfahren für Nachfragemarken und Hochwasserreduktionsverbindungen sind üblich.
Dieses Beispiel zeigt eine Konfiguration für eine Funktion zur Reduzierung von OSPF-Flooding:
interface POS 0/0 ip address 192.168.122.1 255.255.255.0 ip ospf flood-reduction
Wie oben, ist Schnittstelle POS 0/0 des Routers für die Reduzierung der OSPF-Flooding konfiguriert. Über den Link werden keine regelmäßigen LSA-Aktualisierungen gesendet, aber Hellos werden gesendet.