Warum OSPF Demand Circuit die Verbindung immer wieder aktiviert

Einleitung

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.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Beispielnetzwerk

Das oben erwähnte Problem wird anhand des folgenden Netzwerkdiagramms und der folgenden Netzwerkkonfiguration beschrieben.

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.

1. Änderung der Netzwerktopologie

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).

Lösung

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.

2. Grund: Netzwerktyp definiert als Broadcast

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.

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)

Lösung

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.

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.

3. Grund: Ein oder mehrere Router verstehen die Nachfrageschaltung nicht.

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.

4. Grund: Hostroute wird in die OSPF-Datenbank umverteilt

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 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.

Lösung 1: Verwenden des Befehls no peer neighbor-route

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

Lösung 2: Verwenden des Befehls route-map

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

Lösung 3: Verwendung eines anderen Hauptnetzes

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.

5. Grund: Die OSPF-Demand-Schaltung wird über eine asynchrone Schnittstelle konfiguriert.

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.

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)

Lösung

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).

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.

6. Grund: OSPF-Demand-Circuit wird über eine Multilink-PPP konfiguriert

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.

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.

Lösung

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.

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.

Zugehörige Informationen

• OSPF-Supportseite
• Technischer Support – Cisco Systems