Wenn eine OSPF-Verbindung (Open Shortest Path First) als Lastschaltung konfiguriert wird, werden OSPF-Hellos unterdrückt, und es werden keine regelmäßigen LSA-Aktualisierungen über die Verbindung gesendet. Diese Pakete stellen die Verbindung nur dann her, wenn sie zum ersten Mal ausgetauscht werden oder wenn eine Änderung der darin enthaltenen Informationen eintritt. Auf diese Weise kann die zugrunde liegende Sicherungsschicht geschlossen werden, wenn die Netzwerktopologie stabil ist. Ein Bedarfsstromkreis, der auf- und abgeschaltet wird, weist auf ein Problem hin, das untersucht werden muss. Dieses Dokument zeigt einige mögliche Ursachen auf und bietet Lösungen.
Weitere Informationen zu Demand Circuit finden Sie unter OSPF Demand Circuit Feature.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Das oben erwähnte Problem wird anhand des folgenden Netzwerkdiagramms und der folgenden Netzwerkkonfiguration beschrieben.
Router 1 | Router 2 |
---|---|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 ip ospf demand-circuit router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Hinweis: Sie müssen die Verbrauchsschaltung nur an einem Ende der Verbindung konfigurieren. Wenn Sie diesen Befehl jedoch auf beiden Seiten konfigurieren, verursacht er keinen Schaden.
Im obigen Diagramm wird auf den Routern 1 und 2 die OSPF-Bedarfsschaltung für die ISDN-Verbindung ausgeführt. Die Verbindung zwischen den Routern 1 und 2 wird fortgesetzt, wodurch der Zweck der OSPF-Bedarfsschaltung verfehlt wird. Die Ausgabe des Befehls show dialer zeigt an, dass die Verbindung aufgrund des OSPF-Multicast-Hello-Pakets hergestellt wurde.
Router1# show dialer BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up Dial reason: ip (s=192.168.254.13, d=224.0.0.5)
Der Link kann aus mehreren Gründen hochgefahren werden. Im Folgenden werden einige gängige Fälle erläutert und Lösungen angeboten.
Bei jeder Änderung der OSPF-Netzwerktopologie müssen die OSPF-Router benachrichtigt werden. In diesem Fall sollte der OSPF-Lastkreis aktiviert werden, damit die Nachbarn die neuen Informationen austauschen können. Sobald die neue Datenbank ausgetauscht wurde, kann die Verbindung wieder unterbrochen werden, und die Adjacency bleibt im Status "FULL" (Voll).
Um festzustellen, ob die Verbindung aufgrund einer Änderung der Netzwerktopologie aktiviert wird, verwenden Sie den Befehl debug ip ospf monitor. Es wird angezeigt, welche LSAs sich ändern (siehe unten):
Router1# debug ip ospf monitor OSPF: Schedule SPF in area 0.0.0.0 Change in LS ID 192.168.246.41, LSA type R, OSPF: schedule SPF: spf_time 1620348064ms wait_interval 10s
Die Ausgabe oben zeigt eine Änderung des Router-LSA mit der Router-ID 192.168.246.41, wodurch die Datenbank re-synchronisiert wird. Wenn das Netzwerk stabil ist, zeigt diese Debug-Ausgabe nichts an.
Um die Auswirkungen von Verbindungsklappen auf den Laststromkreis zu reduzieren, konfigurieren Sie den Bereich, der den Laststromkreis enthält, als vollständig Stub (Stub). Wenn dies nicht machbar ist und es im Netzwerk eine konstante Verbindungsflatterfläche gibt, ist die Bedarfsschaltung möglicherweise keine gute Wahl für Sie.
Wenn Sie die Verbrauchsschaltung für eine Verbindung konfigurieren, muss der Verbindungstyp als Point-to-Point oder Point-to-Multipoint definiert werden. Jeder andere Verbindungstyp kann dazu führen, dass die Verbindung unnötig hochgefahren wird, da die OSPF-Hellos nicht unterdrückt werden, wenn es sich um einen anderen Netzwerktyp als Point-to-Point oder Point-to-Multipoint handelt. Nachfolgend finden Sie eine Beispielkonfiguration, um dieses Problem auf den Routern 1 und 2 zu veranschaulichen.
Router 1 | Router 2 |
---|---|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 ip ospf network broadcast router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 ip ospf network broadcast router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Wenn der Netzwerktyp als Broadcast definiert ist, wird die Verbindung von den OSPF-Hellos in jedem Hello-Intervall hochgefahren. Die Ausgabe von show dialer zeigt, dass der letzte Aufruf der Verbindung auf ein OSPF Hello zurückzuführen war.
Router1# show dialer BRI1/1:1 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (20 secs) Wait for carrier (30 secs), Re-enable (2 secs) Dialer state is data link layer up Dial reason: ip (s=192.168.254.13, d=224.0.0.5) Interface bound to profile Di1 Current call connected 00:00:08 Connected to 57654 (R2)
Um dieses Problem zu beheben, ändern Sie entweder den Netzwerktyp in Point-to-Point oder Point-to-Multipoint. Hier wird der Netzwerktyp "broadcast" entfernt, sodass er standardmäßig als Point-to-Point konfiguriert ist.
Router 1 | Router 2 |
---|---|
interface BRI1/1 ip address 192.158.254.13 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface BRI1/0 ip address 192.158.254.14 255.255.255.252 router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Wenn der Netzwerktyp in Point-to-Point oder Point-to-Multipoint geändert wird, werden die OSPF-Hellos für die Verbindung unterdrückt, und das Flapping der Verbindung des Verbraucherkreises wird beendet.
Wenn ein oder mehrere Router in der OSPF-Domäne die Verbrauchsschaltung nicht verstehen, erfolgt eine regelmäßige LSA-Aktualisierung. Im Abschnitt Wann wird eine regelmäßige LSA-Aktualisierung über einen OSPF-Bedarfsstromkreis gesendet? dieses Dokuments erfahren Sie, wie Sie dieses Problem beheben.
Betrachten wir das folgende Netzwerkdiagramm als Beispiel:
Die Verbindung zwischen den Routern 1 und 2 ist 131.108.1.0/24, und die Verbrauchsschaltung ist zwischen den Routern 1 und 2 konfiguriert. Router 1 verteilt Routen des Routing Information Protocol (RIP) auf OSPF um.
Router 1 |
---|
router ospf 1 redistribute rip subnets network 131.108.1.0 0.0.0.255 area 1 ! router rip network 131.108.0.0 |
Da der Link-Kapselungstyp PPP ist, installieren beide Router eine Host-Route für die andere Seite der Verbindung, wie unten gezeigt.
Router1# show ip route 131.108.1.2 Routing entry for 131.108.1.2/32 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via BRI1/1 Route metric is 0, traffic share count is 1
Interior Gateway Routing Protocol (IGRP) und RIP sind klassenbezogene Routing-Protokolle. Daher gilt die Netzwerkanweisung in der Konfiguration für ein klassenbezogenes Netzwerk mit der Adresse 131.108.0.0. Aus diesem Grund wird davon ausgegangen, dass die Host-Route 131.108.1.2/32 von RIP stammt und wie unten dargestellt als externe Route in OSPF neu verteilt wird.
Router1# show ip ospf database external 131.108.1.2 OSPF Router with ID (131.108.3.1) (Process ID 1) Type-5 AS External Link States LS age: 298 Options: (No TOS-capability, DC) LS Type: AS External Link Link State ID: 131.108.1.2 (External Network Number ) Advertising Router: 131.108.3.1 LS Seq Number: 80000001 Checksum: 0xDC2B Length: 36 Network Mask: /32 Metric Type: 2 (Larger than any link state path) TOS: 0 Metric: 20 Forward Address: 0.0.0.0 External Route Tag: 0
Wenn die Verbindung ausfällt, verschwindet /32, und OSPF versteht dies als Änderung der Topologie. Die Bedarfsschaltung bringt die Verbindung wieder hoch, um die MAXAGE-Version der /32-Maske an ihren Nachbarn weiterzugeben. Wenn die Verbindung wieder hergestellt wird, wird die /32-Maske wieder gültig, sodass das LSA-Alter zurückgesetzt wird. Dann, nachdem der Dead-Timer der Verbindung eintritt, geht die Verbindung wieder herunter. Dieser Vorgang wiederholt sich, und die Verbindung der Verbrauchsschaltung flattert weiter. Es gibt drei Möglichkeiten, dieses Problem zu lösen.
Konfigurieren Sie unter der BRI-Schnittstelle, auf der die Verbrauchsschaltung ausgeführt wird, keine Peer-Nachbar-Route. Dadurch wird verhindert, dass die /32-Maske installiert wird. Sie können die unten gezeigte Konfiguration nur auf Router 1 verwenden. Aus Konsistenzgründen wird jedoch empfohlen, diesen Befehl auf beiden Seiten zu konfigurieren.
R1# configure terminal R1(config)# interface BRI1/1 R1(config-if)# no peer neighbor-route
Bei der Neuverteilung von RIP in OSPF verwenden Sie den Befehl route-map und deny /32, damit dieser nicht in die OSPF-Datenbank eingefügt wird. Dieser Konfigurationsbefehl ist nur für den Router erforderlich, der die Neuverteilung durchführt, in unserem Beispiel Router 1.
Zuerst müssen wir eine Zugriffsliste erstellen, die mit der /32-Maske übereinstimmt. Anschließend wenden wir diese Zugriffsliste auf die Routenübersicht an und verwenden die Routenübersicht, wenn wir den Befehl zur Neuverteilung anwenden (siehe unten).
R1# configure terminal R1(config)# access-list 1 deny host 131.108.1.2 R1(config)# access-list 1 permit any R1# configure terminal R1(config)# route-map rip-ospf R1(config-route-map)# match ip address 1 R1(config)# router ospf 1 R1(config-router)# redistribute rip subnets route-map rip-ospf
Verwenden Sie für die RIP- oder OSPF-Domäne ein anderes Hauptnetz. Die Idee ist, ein anderes Haupt-Netz auf der Lastschaltungsverbindung zu haben, sodass, wenn die Verbindung unter PPP-Kapselung kommt, sie die Host-Route für die andere Seite der Verbindung installiert. Wenn sich die Hostroute in einem anderen Haupt-Netzwerk befindet als dem, das in RIP verwendet wird, besitzt RIP diese PPP-installierte Hostroute nicht, da sie keine Netzwerkanweisung für das Haupt-Netzwerk besitzt. Das folgende Netzwerkdiagramm zeigt ein Beispiel.
Die RIP-Domäne befindet sich jetzt im Netzwerk 141.108.0.0, die OSPF-Domäne (und die Verbindung für die Verbrauchsschaltung) im Netzwerk 131.108.0.0.
Wenn Sie eine Verbrauchsschaltung über eine asynchrone Schnittstelle konfigurieren, fällt beim Ausfall von Layer 2 die physische Schnittstelle aus. Dies löst eine Änderung in der OSPF-Datenbank aus, und die asynchrone Schnittstelle wird erneut aktiviert, um die Datenbank auszutauschen. Layer 2 fällt wieder aus, und dies löst die Änderung in der Datenbank erneut aus, sodass sich dieser Prozess immer wieder wiederholt.
Das folgende Szenario wird verwendet, um das obige Problem zu reproduzieren.
Die folgende Konfiguration wird für das obige Szenario verwendet.
Router 1 | Router 2 |
---|---|
interface Async 1 ip address 192.158.254.13 255.255.255.252 encapsulation ppp ip ospf demand-circuit dialer in-band async default routing async mode dedicated ppp authentication chap ppp chap hostname Router1 ppp chap password 7 13061E010803 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
interface Async 1 ip address 192.158.254.14 255.255.255.252 encapsulation ppp ip ospf demand-circuit dialer in-band dialer map ip 192.158.254.13 broadcast 12345 dialer-group 2 async default routing async mode dedicated ppp authentication chap callin ! dialer-list 2 protocol ip permit ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
Der OSPF-Standardnetzwerktyp ist "Point-to-Point" auf einer asynchronen Schnittstelle, die Verbindung wird jedoch weiterhin von der Verbrauchsschaltung aktiviert.
Rouer1# show ip ospf interface Async1 Async1 is up, line protocol is up (spoofing) Internet Address 192.158.254.13/32, Area 1 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:869 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:02 Index 1/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s)
Der Grund dafür, dass der Bedarfsstromkreis die Verbindung immer wieder aktiviert, ist, dass die gesamte Schnittstelle ausfällt, wenn Layer 2 nach Ablauf der Leerlaufzeitüberschreitung ausfällt. Bei BRI oder PRI bleibt die Schnittstelle jedoch aktiv, wenn einer der Kanäle ausfällt (im Spoofing-Modus). Um das Problem zu lösen, müssen Sie eine Dialer-Schnittstelle konfigurieren, da diese nie ausfällt. Eine Dialer-Schnittstelle bleibt aktiv (im Spoofing-Modus).
Router 1 | Router 2 |
---|---|
interface Async 1 no ip address encapsulation ppp async default routing async mode dedicated dialer in-band dialer rotary-group 0 ! interface Dialer0 ip address 192.158.254.13 255.255.255.252 encapsulation ppp ip ospf demand-circuit ppp authentication chap ppp chap hostname Router1 ppp chap password 7 13061E010803 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
interface Async 1 no ip address encapsulation ppp async default routing async mode dedicated dialer in-band dialer rotary-group 0 ! interface Dialer0 ip address 192.158.254.14 255.255.255.252 encapsulation ppp ip ospf demand-circuit dialer map ip 192.158.254.13 broadcast 12345 dialer-group 2 ppp authentication callin ! dialer-list 2 protocol ip permit ! router ospf 20 network 192.158.254.0 0.0.0.255 area 0 |
Da die Dialer-Schnittstelle niemals ausfällt, wird das Problem nicht verursacht, das beim Ausfall einer asynchronen Schnittstelle auftritt.
Die PPP-Funktion für mehrere Verbindungen kann zum Lastenausgleich verwendet werden, wenn mehrere WAN-Verbindungen vorhanden sind. OSPF sollte unbedingt die Bandbreite des Multilink-PPP berücksichtigen. Wenn mehrere Verbindungen kombiniert werden, ändert sich die Bandbreite der Schnittstelle mit mehreren Verbindungen.
Das folgende Szenario wird verwendet, um das obige Problem zu reproduzieren.
Die folgende Konfiguration wird für das obige Szenario verwendet.
Router 1 | Router 2 |
---|---|
interface Multilink1 ip address 192.158.254.1 255.255.255.0 no cdp enable ppp multilink no ppp multilink fragmentation multilink-group 1 ! interface Serial0/1/0:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/1:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/2:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
interface Multilink1 ip address 192.158.254.2 255.255.255.0 no cdp enable ppp multilink no ppp multilink fragmentation multilink-group 1 ! interface Serial0/1/0:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/1:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! interface Serial0/1/2:0 no ip address ip route-cache distributed encapsulation ppp tx-queue-limit 26 no fair-queue ppp multilink multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
Die folgende Ausgabe zeigt, dass drei serielle Schnittstellen in der Multilink-PPP gebündelt sind.
Router1# show ppp multilink Multilink1, bundle name is Router2 Bundle up for 00:05:35 Bundle is Distributed 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 3/255 load 0x1226 received sequence, 0x1226 sent sequence Member links: 3 active, 0 inactive (max not set, min not set) Serial1/0/0:0, since 00:05:35, no frags rcvd Serial1/0/1:0, since 00:05:35, no frags rcvd Serial1/0/2:0, since 00:05:35, no frags rcvd
Die Schnittstellenbandbreite stellt die aggregierte Bandbreite der Verbindung dar. Diese Bandbreite wird bei der OSPF-Kostenberechnung verwendet.
Router1# show interface multilink 1 Multilink1 is up, line protocol is up Hardware is multilink group interface Internet address is 192.168.254.1/24 MTU 1500 bytes, BW 5952 Kbit, DLY 100000 usec, reliability 255/255, txload 3/255, rxload 3/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 2 seconds on reset LCP Open, multilink Open Open: IPCP Last input 00:00:00, output never, output hang never Last clearing of "show interface" counters 00:06:39 Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 241000 bits/sec, 28 packets/sec 5 minute output rate 241000 bits/sec, 28 packets/sec 6525 packets input, 9810620 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 6526 packets output, 9796112 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions
Die Ausgabe der show ip ospf-Schnittstelle zeigt die aktuellen OSPF-Kosten an, die 16 betragen.
Router1# show ip ospf interface multilink 1 Multilink1 is up, line protocol is up Internet Address 192.158.254.13/24, Area 1 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:16 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:02 Index 1/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s)
Nun wird ein Link heruntergefahren, und wir können sehen, dass im Protokoll:
Router1# show log | include down %LINK-3-UPDOWN: Interface Serial1/0/0:0, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:0, changed state to down
Wenn wir die Bandbreite erneut prüfen, wird sie sich von der vorherigen unterscheiden. Jetzt wird 3968 angezeigt, und das Paket hat nur zwei statt drei Schnittstellen, da eine Schnittstelle ausgefallen ist. Hinweis unterhalb der Schnittstelle ist noch aktiv:
Router1# show ppp multilink Multilink1, bundle name is Router2 Bundle up for 00:05:35 Bundle is Distributed 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 3/255 load 0x1226 received sequence, 0x1226 sent sequence Member links: 2 active, 1 inactive (max not set, min not set) Serial1/0/1:0, since 00:05:35, no frags rcvd Serial1/0/2:0, since 00:05:35, no frags rcvd Serial1/0/0:0 (inactive)
Auch wird die PPP-Multilink immer noch angezeigt, aber die OSPF-Kosten wurden auf 25 geändert, da eine Verbindung ausgefallen ist.
Router1# show ip ospf interface multilink 1 Multilink1 is up, line protocol is up Internet Address 192.158.254.13/24, Area 1 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:25 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:02 Index 1/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s)
Dadurch wird die SPF-Berechnung ausgelöst, und OSPF aktiviert den Bedarfsstromkreis. Wenn die Verbindung weiter flattert, kann es sein, dass die Bedarfsschaltung weiter flattert, da die Kosten jedes Mal geändert werden, wenn eine Verbindung aufaddiert oder aus dem PPP-Bündel mit mehreren Verbindungen gelöscht wird.
Die PPP-Multilink wird in OSPF unterstützt. Solange jedoch die Verbindung innerhalb des Bündels erhalten bleibt, ist die Verbrauchsschaltung stabil. Sobald eine Verbindung ausfällt, obwohl keine IP-Adresse mit ihr verknüpft ist, wirkt sich dies auf die OSPF-Kostenberechnung aus. Daher führt OSPF den SPF aus, um die besten Pfade neu zu berechnen. Die einzige Lösung zur Lösung dieses Problems besteht darin, die OSPF-Kosten manuell mit dem folgenden Befehl zu konfigurieren.
Router 1 | Router 2 |
---|---|
interface Multilink1 ip address 192.158.254.1 255.255.255.0 no cdp enable ip ospf cost 10 ppp multilink no ppp multilink fragmentation multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
interface Multilink1 ip address 192.158.254.2 255.255.255.0 no cdp enable ip ospf cost 10 ppp multilink no ppp multilink fragmentation multilink-group 1 ! router ospf 20 network 192.158.254.0 0.0.0.255 area 1 |
Mit diesem Befehl wird sichergestellt, dass die OSPF-Kosten nicht beeinträchtigt werden, wenn im PPP-Bündel mit mehreren Verbindungen ein Link hinzugefügt oder gelöscht wird. Dadurch wird der OSPF-Bedarfsstromkreis über die PPP-Multilink stabilisiert.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
03-Oct-2001 |
Erstveröffentlichung |