Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Steekproef-netwerk

Reden 1: Verandering in de netwerktopologie

Oplossing

Reden 2: Netwerktype gedefinieerd als broadcast

Oplossing

Reden 3: Een of meer routers begrijpen geen Demand circuit

Reden 4: Host Route wordt herverdeeld in de OSPF-database

Oplossing 1: Gebruik de geen peer buurland-route Opdracht

Oplossing 2: Gebruik de route-map-opdracht

Oplossing 3: Gebruik een ander belangrijk net

Reden 5: OSPF-Demand circuit is ingesteld via een asynchrone interface

Oplossing

Reden 6: OSPF-Demand circuit is ingesteld via een multilink-PPP

Oplossing

Gerelateerde informatie

Inleiding

Wanneer een Open Shortest Path First (OSPF)-link als verbruikscircuit is geconfigureerd, worden OSPF-Hellos onderdrukt en worden periodieke LSA-drempels niet via de link overstroomd. Deze pakketten brengen de verbinding slechts op wanneer zij voor het eerst worden geruild, of wanneer een verandering in de informatie optreedt die zij bevatten. Dit staat toe de onderliggende Laag van de Koppeling van Gegevens te worden gesloten wanneer de netwerktopologie stabiel is. Een stroomcircuit dat op en neer gaat wijst op een probleem dat moet worden onderzocht. In dit document worden enkele mogelijke oorzaken aangegeven en oplossingen aangedragen.

Raadpleeg voor meer informatie over het circuit waarop de eis is gebaseerd, de OSPF-On-Demand circuit-functie.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

Conventies

Zie de Cisco Technical Tips Convention voor meer informatie over documentconventies.

Steekproef-netwerk

Het bovenstaande probleem wordt beschreven in het volgende netwerkdiagram en de volgende configuratie.

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

Opmerking: u hoeft het vraagcircuit alleen aan één kant van de link te configureren. Als u deze opdracht echter op beide eindpunten instelt, veroorzaakt deze geen schade.

In het bovenstaande diagram werken Routers 1 en 2 OSPF-vraagcircuit via de ISDN-link. Het verband tussen Routers 1 en 2 blijft omhoog komen, wat het doel van OSPF-verbruikscircuit verslaat. De uitvoer van het tonen dialer bevel toont dat de verbinding wegens het pakket OSPF multicast Hallo kwam.

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)

De link kan om verschillende redenen worden aangehaald. Hieronder zoeken we naar meerdere vaak voorkomende gevallen en bieden we oplossingen.

Reden 1: Verandering in de netwerktopologie

Wanneer er een verandering in een OSPF netwerktopologie is, moeten de OSPF routers worden gemeld. In deze situatie moet het OSPF-vraagcircuit worden opgevoed zodat de buren de nieuwe informatie kunnen uitwisselen. Zodra de nieuwe database wordt uitgewisseld kan de link opnieuw naar beneden gaan en blijft de nabijheid in de FULL-status.

Oplossing

Om te bepalen als de verbinding omhoog wegens een verandering in netwerktopologie wordt gebracht, gebruik het debug ip ospf monitor bevel. Het laat zien welke LSA aan het veranderen is, zoals hieronder te zien is:

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

De bovenstaande uitvoer toont een verandering in de router LSA met de router-ID van 192.168.246.41, waardoor de database opnieuw wordt gesynchroniseerd. Als het netwerk stabiel is, dan toont deze debug uitvoer niets.

Om het effect van de lijnkranen op het vraagcircuit te verminderen, moet u het gebied dat het vraagcircuit bevat als een volledig naadje configureren. Als dit niet kan, en er een constante verbindingsflap in het netwerk is, zou de vraag circuit geen goede keuze voor u kunnen zijn.

Reden 2: Netwerktype gedefinieerd als broadcast

Wanneer u vraagcircuit op een link instelt, moet het type link worden gedefinieerd als point-to-point of point-to-multipoint. Elk ander type link kan de verbinding onnodig veroorzaken om naar voren te komen omdat de OSPF-Hellos niet zijn onderdrukt als het netwerktype iets anders is dan point-to-point of point-to-multipoint. Hierna volgt een voorbeeldconfiguratie om dit probleem op routers 1 en 2 te illustreren.

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

Met het netwerktype dat als uitzending wordt gedefinieerd, brengt de OSPF Hellos de verbinding op elk interval van Hallo. De show dialer uitvoer toont aan dat de laatste keer dat de link naar voren werd gebracht door een OSPF Hallo was.

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)

Oplossing

Om dit probleem op te lossen, verandert u het netwerktype in point-to-point of point-to-multipoint. Hier verwijderen we de uitzending van het netwerktype zodat deze standaard is ingesteld als point-to-point.

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

Door het netwerktype in punt-tot-punt of punt-tot-multipoint te veranderen, worden de OSPF Hellos op de link onderdrukt en stopt de verbinding met het vraagcircuit met flappelen.

Reden 3: Een of meer routers begrijpen geen Demand circuit

Wanneer één of meer routers in het OSPF-domein geen vraagcircuit begrijpen, wordt een periodieke LSA-vernieuwing uitgevoerd. Zie Wanneer wordt een periodieke LSA-verfrissing verzonden over een OSPF-Demand circuit? In dit document vindt u informatie over de oplossing van dit probleem.

Reden 4: Host Route wordt herverdeeld in de OSPF-database

Laten we het volgende netwerkdiagram als voorbeeld nemen:

Het verband tussen Routers 1 en 2 is 131.108.1.0/24, en het stroomcircuit van de vraag wordt gevormd tussen Routers 1 en 2. Router 1 is het herverdelen van de routes van het Routing Information Protocol (RIP) in OSPF.

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

Aangezien het type insluiting van de verbinding PPP is, installeren beide routers een host-route voor de andere kant van de link zoals hieronder wordt weergegeven.

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) en RIP zijn klastige routingprotocollen, en daarom is de netwerkverklaring in de configuratie voor een klastisch netwerk van 131.108.0.0. Daarom wordt de host-route van 131.108.1.2/32 geacht bedacht te zijn door RIP en wordt herverdeeld in OSPF als een externe route zoals hieronder wordt getoond.

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

Wanneer de verbinding lager wordt/32 verdwijnt en OSPF begrijpt dit als een verandering in topologie. Het vraagcircuit brengt de link opnieuw naar voren om de MAXAGE-versie van het /32-masker aan zijn buurman te propageren. Wanneer de link omhoog komt, wordt het /32 masker opnieuw geldig zodat de LSA pagina wordt gereset. Nadat de dode timer van de link naar binnen knikt, gaat de link weer naar beneden. Dit proces herhaalt zich en de link naar een gebruikerscircuit blijft flappelen. Hieronder worden drie manieren getoond om dit probleem op te lossen.

Oplossing 1: Gebruik de geen peer buurland-route Opdracht

Onder de BRI interface die vraagcircuit in werking stelt, moet u geen peer buurroute configureren. Dit voorkomt de installatie van het /32 masker. U kunt de configuratie hieronder slechts op router 1 gebruiken, maar wij adviseren om deze opdracht aan beide kanten voor consistentie te configureren.

R1# configure terminal

R1(config)# interface BRI1/1

R1(config-if)# no peer neighbor-route

Oplossing 2: Gebruik de route-map-opdracht

Wanneer het herverdelen van RIP in OSPF, gebruik de route-kaart bevel en ontken /32 zodat het niet in de OSPF gegevensbestand wordt ingespoten. Deze configuratieopdracht is alleen vereist op de router die de herdistributie doet, wat in ons voorbeeld router 1 is.

Eerst moeten we een toegangslijst maken om het /32 masker aan te passen. Vervolgens passen we deze toegangslijst toe op de routekaart en gebruiken we de routekaart bij het toepassen van de herverdelingsopdracht zoals hieronder getoond.

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

Oplossing 3: Gebruik een ander belangrijk net

Gebruik een ander belangrijk net voor of het RIP of OSPF domein. Het idee is om een ander belangrijk net op de verbinding van het vraagcircuit te hebben zodat wanneer de link onder PPP insluiting omhoog komt, het de host route voor de andere kant van de link installeert. Als de host-route in een ander groot net is dan de route die in RIP wordt gebruikt, is RIP niet eigenaar van deze PPP-geïnstalleerde host-route omdat deze geen netwerkverklaring voor het hoofdnet heeft. In het onderstaande netwerkdiagram wordt een voorbeeld getoond.

Het RIP domein is nu onder het netwerk 141.108.0.0 terwijl het OSPF domein (en de verbinding van het vraagcircuit) onder het 131.108.0.0 netwerk is.

Reden 5: OSPF-Demand circuit is ingesteld via een asynchrone interface

Wanneer u een vraagcircuit vormt over een asynchrone (asynchrone) interface, dan wanneer Layer 2 omlaag gaat, daalt de fysieke interface. Dit veroorzaakt een verandering in de OSPF gegevensbestand en de asynchrone interface komt terug omhoog om de gegevensbank te ruilen. Layer 2 gaat weer omlaag en dit zal de verandering in de database opnieuw teweegbrengen, dus dit proces blijft zichzelf herhalen.

Het volgende scenario wordt gebruikt om het bovenstaande probleem te reproduceren.

Voor het bovenstaande scenario wordt de volgende configuratie gebruikt.

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

Het OSPF standaard netwerktype is point-to-point op een asynchrone interface, maar het vraagcircuit blijft de link omhoog brengen.

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)

Oplossing

De reden dat het vraagcircuit de link blijft omhoog brengen is omdat wanneer Layer 2 omlaag gaat nadat de inactiviteitstimer verloopt, de hele interface omlaag gaat. Maar in het geval van BRI of PRI, wanneer een van de kanalen omlaag gaat, blijft de interface omhoog (in spoofing modus). Om het probleem op te lossen moet u een dialerinterface configureren omdat het nooit lager wordt. Er blijft een dialerinterface omhoog (in spoofingmodus).

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

Aangezien de dialerinterface nooit naar beneden gaat, zal het geen probleem creëren dat wordt gecreëerd wanneer een asynchrone interface daalt.

Reden 6: OSPF-Demand circuit is ingesteld via een multilink-PPP

De functie Multilink PPP kan worden gebruikt voor taakverdeling in gevallen waarin er meerdere WAN-koppelingen zijn. Eén belangrijk ding om in termen van OSPF te onthouden is de bandbreedte van de multilink PPP. Wanneer meerdere links worden gecombineerd, zal de bandbreedte van de multilink interface veranderen.

Het volgende scenario wordt gebruikt om het bovenstaande probleem te reproduceren.

Voor het bovenstaande scenario wordt de volgende configuratie gebruikt.

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

De volgende uitvoer toont aan dat er drie seriële interfaces bij elkaar zijn gebundeld in de multilink-PPP.

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

De interfacebandbreedte zal de geaggregeerde bandbreedte van de link vertegenwoordigen, en deze bandbreedte zal in de OSPF-kostenberekening worden gebruikt.

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

De output van tonen IP ospf interface toont de huidige OSPF kosten, die 16 zijn.

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)

Nu gaat er een link naar beneden en dat zien we in het logboek:

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

Als we de bandbreedte opnieuw controleren zal het anders zijn dan wat we eerder zagen. Nu is dat 3968 en de bundel heeft slechts twee interfaces in plaats van drie omdat één interface naar beneden ging. Opmerking onder de interface is nog steeds aanwezig:

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)

Ook, de PPP multilink is nog steeds zichtbaar, maar de OSPF-kosten zijn nu veranderd in 25 sinds één link is ingedrukt

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)

Dit wat zal de berekening van SPF teweegbrengen, en OSPF zal het vraagcircuit omhoog brengen. Als de link blijft knipperen, kunnen we het vraagcircuit zien flappen omdat de kosten zullen worden gewijzigd elke keer dat een link wordt toegevoegd of uit de bundel van de multilink PPP wordt verwijderd.

Oplossing

De PPP multilink wordt ondersteund in OSPF, maar zolang alle link binnen de bundel omhoog blijft, zal het vraagcircuit stabiel zijn. Zodra een link naar beneden gaat, ook al is er geen IP-adres dat hieraan gekoppeld is, zal het de OSPF-kostenberekening beïnvloeden en daarom zal OSPF de SPF uitvoeren om de beste paden opnieuw te berekenen. Om dit probleem op te lossen, is de enige oplossing om de OSPF-kosten handmatig te configureren met de volgende opdracht.

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

Deze opdracht zal ervoor zorgen dat elke keer dat er een link is die in de bundel van multilink PPP wordt toegevoegd of verwijderd, de OSPF-kosten niet worden beïnvloed. Dit zal het OSPF-vraagcircuit via de PPP-multilink stabiliseren.

Gerelateerde informatie

- OSPF-ondersteuningspagina

- Technische ondersteuning - Cisco-systemen