Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Beispielnetzwerk

Grund 1: Änderung der Netzwerktopologie

Lösung

Grund 2: Netzwerktyp definiert als Broadcast

Lösung

Grund 3: Ein oder mehrere Router verstehen den Demand Circuit nicht.

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

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

Lösung 2: Verwenden des Befehls route-map

Lösung 3: Verwenden eines anderen Hauptnetzwerks

Grund 5: Der OSPF-Demand-Circuit wird über eine asynchrone Schnittstelle konfiguriert.

Lösung

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

Lösung

Zugehörige Informationen

Einführung

Wenn eine OSPF-Verbindung (Open Shortest Path First) als Demarkreis konfiguriert wird, werden OSPF-Hellos unterdrückt, und regelmäßige LSA-Aktualisierungen werden nicht über die Verbindung geflutet. 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 Data Link Layer geschlossen werden, wenn die Netzwerktopologie stabil ist. Eine Verbrauchsschaltung, die nach oben und unten wechselt, weist auf ein Problem hin, das untersucht werden muss. Dieses Dokument zeigt einige mögliche Ursachen und bietet Lösungen.

Weitere Informationen zu Demand Circuit-Systemen finden Sie unter OSPF Demand Circuit Feature.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

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

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Beispielnetzwerk

Das oben genannte Problem wird im folgenden Netzwerkdiagramm und in der folgenden Konfiguration 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 den Verbrauchskreis 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 der OSPF-Lastkreislauf über die ISDN-Verbindung ausgeführt. Die Verbindung zwischen den Routern 1 und 2 geht weiter, was den Zweck der OSPF-Laststromführung zunichte macht. Die Ausgabe des Befehls show dialer zeigt, 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 aufgerufen werden. Im Folgenden werden einige gängige Fälle untersucht und Lösungen angeboten.

Grund 1: Änderung der Netzwerktopologie

Bei Änderungen in einer OSPF-Netzwerktopologie müssen die OSPF-Router benachrichtigt werden. In dieser Situation sollte der OSPF-Lastkreislauf aktiviert werden, damit die Nachbarn die neuen Informationen austauschen können. Sobald die neue Datenbank ausgetauscht wurde, kann der Link erneut deaktiviert werden, und die Adjacency bleibt im VOLLSTÄNDIGEN Zustand.

Lösung

Um zu bestimmen, ob die Verbindung aufgrund einer Änderung der Netzwerktopologie aktiviert wird, verwenden Sie den Befehl debug ip ospf monitor. Es zeigt, 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 obige Ausgabe zeigt, dass sich die Router-LSAs mit der Router-ID 192.168.246.41 geändert haben, wodurch die Datenbank re-synchronisiert wird. Wenn das Netzwerk stabil ist, zeigt diese Debug-Ausgabe nichts an.

Um die Auswirkungen von Verbindungs-Flaps auf den Laststromkreis zu reduzieren, konfigurieren Sie den Bereich, der den Lastkreis enthält, als "total Stub". Wenn dies nicht möglich ist und im Netzwerk eine ständige Link-Flapping vorhanden ist, ist die Demand Circuit möglicherweise keine gute Wahl für Sie.

Grund 2: Netzwerktyp definiert als Broadcast

Wenn Sie die Nachfragespeicherung für eine Verbindung konfigurieren, muss der Verbindungstyp als Point-to-Point- oder Point-to-Multipoint-Verbindung definiert werden. Jeder andere Verbindungstyp kann dazu führen, dass der Link unnötigerweise angezeigt wird, da die OSPF Hellos nicht unterdrückt werden, wenn es sich bei dem Netzwerktyp um einen anderen Verbindungstyp als Point-to-Point oder Point-to-Multipoint handelt. Im Folgenden 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 der Link von OSPF Hellos in jedem Hello-Intervall aktiviert. Die Ausgabe des Show Dialer zeigt an, dass der Link zum letzten Mal durch einen OSPF Hello ausgelöst 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)

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 Punkt-zu-Punkt 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

Durch die Änderung des Netzwerktyps in Point-to-Point oder Point-to-Multipoint werden die OSPF-Hellos auf der Verbindung unterdrückt, und die Nachfragemanagement-Verbindung hört auf zu blinken.

Grund 3: Ein oder mehrere Router verstehen den Demand Circuit nicht.

Wenn ein oder mehrere Router in der OSPF-Domäne die Nachfrageseite nicht verstehen, findet eine regelmäßige LSA-Aktualisierung statt. Siehe Wann wird eine regelmäßige LSA-Aktualisierung über einen OSPF Demand Circuit gesendet? in diesem Dokument erfahren Sie, wie Sie dieses Problem beheben können.

Grund 4: Die 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 Demand Circuit wird zwischen den Routern 1 und 2 konfiguriert. Router 1 verteilt Routing Information Protocol (RIP)-Routen an OSPF weiter.

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 Hostroute 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 klassische Routing-Protokolle. Daher gilt die Netzwerkanweisung in der Konfiguration für ein klassisches Netzwerk mit 131.108.0.0. Daher wird die Hostroute von 131.108.1.2/32 als von RIP initiiert angesehen und wie unten gezeigt als externe Route in OSPF neu verteilt.

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 Demand Circuit führt die Verbindung wieder hoch, um die MAXAGE-Version der /32-Maske an den Nachbarn weiterzugeben. Wenn die Verbindung hochgefahren wird, wird die /32-Maske wieder gültig, sodass das LSA-Alter zurückgesetzt wird. Wenn der Dead-Timer der Verbindung eingeht, wird die Verbindung wieder unterbrochen. Dieser Prozess wiederholt sich, und die Nachfragemarke flattert weiter. Es gibt drei Möglichkeiten, dieses Problem zu beheben, wie im Folgenden dargestellt.

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

Konfigurieren Sie unter der BRI-Schnittstelle, auf der der Nachfragemarkt ausgeführt wird, keine Peer-Nachbar-Route. Dadurch wird die Installation der /32-Maske verhindert. Sie können die unten gezeigte Konfiguration nur auf Router 1 verwenden. Wir empfehlen jedoch, diesen Befehl aus Konsistenzgründen 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

Verwenden Sie bei der Neuverteilung von RIP in OSPF den Befehl route-map und deny /32, damit er nicht in die OSPF-Datenbank eingespeist wird. Dieser Konfigurationsbefehl ist nur auf dem Router erforderlich, der die Neuverteilung durchführt. Im vorliegenden Beispiel ist dies Router 1.

Zuerst müssen wir eine Zugriffsliste erstellen, die der /32-Maske entspricht. Anschließend wenden wir diese Zugriffsliste auf die Routenübersicht an und verwenden die Routenübersicht, wenn wir den Befehl zur Neuverteilung wie unten gezeigt anwenden.

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: Verwenden eines anderen Hauptnetzwerks

Verwenden Sie für die RIP- oder OSPF-Domäne ein anderes Hauptnetz. Es wird ein anderes Hauptnetz für die Nachfragemanagement-Verbindung vorgesehen, sodass die Host-Route für die andere Seite der Verbindung installiert wird, wenn die Verbindung unter der PPP-Kapselung auftaucht. Wenn sich die Hostroute in einem anderen Hauptnetz befindet als das, das im RIP verwendet wird, besitzt RIP diese auf dem PPP installierte Hostroute nicht, da sie über keine Netzwerkanweisung für das Hauptnetz verfügt. Das Netzwerkdiagramm unten zeigt ein Beispiel.

Die RIP-Domäne befindet sich nun unter dem Netzwerk 141.108.0.0, während die OSPF-Domäne (und die Nachfragespunktion) unter dem Netzwerk 131.108.0.0 steht.

Grund 5: Der OSPF-Demand-Circuit wird über eine asynchrone Schnittstelle konfiguriert.

Wenn Sie eine Nachfrageseite über eine asynchrone (async) Schnittstelle konfigurieren, fällt bei einem Ausfall von Layer 2 die physische Schnittstelle aus. Dies löst eine Änderung in der OSPF-Datenbank aus, und die async-Schnittstelle wird erneut zum Austausch der Datenbank wiederhergestellt. Layer 2 fällt wieder aus, und dies löst die Datenbankänderung wieder aus, sodass sich dieser Prozess ständig wiederholt.

Das folgende Szenario wird zur Reproduktion des oben genannten Problems verwendet.

Für das obige Szenario wird die folgende Konfiguration 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, aber der Nachfrageswitch ruft die Verbindung weiterhin auf.

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, warum die Nachfragemarkie die Verbindung immer wieder anzeigt, 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 bei einem Ausfall eines der Kanäle aktiv (im Spoofing-Modus). Um das Problem zu lösen, müssen Sie eine Dialer-Oberfläche konfigurieren, weil sie nie ausfällt. Eine DFÜ-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 nie ausfällt, wird das Problem, das beim Ausfall einer asynchronen Schnittstelle entsteht, nicht verursacht.

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

Die PPP-Funktion für mehrere Verbindungen kann für den Lastenausgleich verwendet werden, wenn mehrere WAN-Verbindungen vorhanden sind. Ein wichtiger Aspekt bei OSPF ist die Bandbreite der Multilink-PPP. Wenn mehrere Verbindungen kombiniert werden, ändert sich die Bandbreite der Multilink-Schnittstelle.

Das folgende Szenario wird zur Reproduktion des oben genannten Problems verwendet.

Für das obige Szenario wird die folgende Konfiguration 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 einem 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 interface zeigt die aktuellen OSPF-Kosten von 16 an.

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 deaktiviert, und wir sehen das 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 überprüfen, wird es anders sein als zuvor. Jetzt wird der 3968 angezeigt, und das Paket hat nur zwei Schnittstellen statt drei, da eine Schnittstelle ausgefallen ist. Beachten Sie, dass die Schnittstelle noch aktiv ist:

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)

Die PPP-Multilink-Funktion wird weiterhin angezeigt, aber die OSPF-Kosten werden jetzt auf 25 geändert, da eine Verbindung nicht verfügbar 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)

Dies löst die SPF-Berechnung aus, und OSPF ruft den Nachfragemarkt auf. Wenn die Verbindung weiter flattert, wird möglicherweise die Nachfrage-Schaltung weiter flapping angezeigt, da die Kosten bei jedem Hinzufügen einer Verbindung oder Löschen aus dem Multilink-PPP-Paket geändert werden.

Lösung

Die PPP-Multilink-Funktion wird in OSPF unterstützt. Solange jedoch die gesamte Verbindung innerhalb des Pakets verfügbar bleibt, ist die Nachfragemarkierung stabil. Sobald eine Verbindung ausfällt, obwohl keine IP-Adresse mit ihr verknüpft ist, wirkt sich dies auf die OSPF-Kostenberechnung aus. Aus diesem Grund wird OSPF zur Neuberechnung der besten Pfade ausgeführt. Um dieses Problem zu beheben, ist die einzige Lösung, 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 OSPF-Kosten nicht beeinträchtigt werden, wenn im Multilink-PPP-Paket eine Verbindung hinzugefügt oder gelöscht wird. Dadurch wird der OSPF-Lastkreislauf über die PPP-Multilink stabilisiert.

Zugehörige Informationen

- OSPF-Support-Seite

- Technischer Support - Cisco Systems