Waarom OSPF Demand Circuit de link blijft omhoog brengen

Inleiding

Wanneer een Open Shortest Path First (OSPF)-link is geconfigureerd als vraagcircuit, worden OSPF Hellos onderdrukt en worden periodieke LSA-vernieuwing niet via de link doorgegeven. Deze pakketten brengen de link alleen ter sprake wanneer ze voor het eerst worden uitgewisseld of wanneer er een wijziging optreedt in de informatie die ze bevatten. Dit maakt het mogelijk de onderliggende Data Link Layer te sluiten wanneer de netwerktopologie stabiel is. Een vraagkring die op en neer gaat wijst op een probleem dat moet worden onderzocht. Dit document laat een aantal mogelijke oorzaken zien en biedt oplossingen.

Raadpleeg voor meer informatie over Demand Circuit Functie OSPF Demand Circuit.

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

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Voorbeeldnetwerk

Het hierboven vermelde probleem wordt beschreven met het volgende netwerkdiagram en de volgende configuratie.

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 dient het vraagcircuit alleen aan één uiteinde van de link te configureren. Als u deze opdracht echter aan beide uiteinden vormt, veroorzaakt het geen schade.

In het bovenstaande schema stellen routers 1 en 2 OSPF-vraagcircuit via de ISDN-link in werking. Het verband tussen Routers 1 en 2 blijft omhoog komen, die het doel van OSPF vraagkring verslaat. De output van het bevel van de showdialer toont aan dat de verbinding wegens het OSPF multicast pakket van Hello omhoog 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 naar voren worden gebracht. Hieronder onderzoeken we verschillende veelvoorkomende gevallen en bieden we oplossingen aan.

Reden 1: Verandering in de netwerktopologie

Wanneer er een verandering in een OSPF-netwerktopologie is, moeten de OSPF-routers worden aangemeld. In deze situatie zou het OSPF vraagcircuit moeten worden gebracht zodat de buren de nieuwe informatie kunnen uitwisselen. Zodra het nieuwe gegevensbestand wordt uitgewisseld kan de verbinding opnieuw dalen en de nabijheid blijft in de VOLLEDIGE staat.

Oplossing

Om te bepalen als de verbinding wegens een verandering in netwerktopologie wordt opgevoed, gebruik het bevel van de debug ip ospf monitor. Het laat zien welke LSA verandert, zoals hieronder wordt getoond:

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 output hierboven toont dat er een verandering in router LSA met router-ID van 192.168.246.41 was, die veroorzaakt dat het gegevensbestand wordt opnieuw gesynchroniseerd. Als het netwerk stabiel is, dan toont deze debug uitvoer niets.

Om het effect van linkflappen op de vraagkring te verminderen, moet u het gebied dat de vraagkring bevat als volledig stompje configureren. Als dit niet uitvoerbaar is en er een constante link flap in het netwerk is, is het mogelijk dat het vraagcircuit geen goede keuze voor u is.

Reden 2: netwerktype gedefinieerd als uitzending

Wanneer u het vraagcircuit op een link configureert, moet het koppelingstype worden gedefinieerd als point-to-point of point-to-multipoint. Een ander koppelingstype kan ervoor zorgen dat de koppeling onnodig opduikt omdat de OSPF-helikopters niet worden onderdrukt als het netwerktype iets anders is dan point-to-point of point-to-multipoint. Na is een steekproefconfiguratie om dit probleem op Routers 1 en 2 te illustreren.

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 omhoog bij elk interval van Hello. De output van de showdialer toont aan dat de laatste keer dat de verbinding werd gebracht wegens een OSPF Hello 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

Als u dit probleem wilt oplossen, wijzigt u het netwerktype in point-to-point of point-to-multipoint. Hier verwijderen we het netwerktype uitzending dus standaard is het ingesteld als point-to-point.

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 te wijzigen in point-to-point of point-to-multipoint, worden de OSPF-helikopters op de link onderdrukt en stopt de vraagschakeling met flappen.

Reden 3: een of meer routers begrijpen het vraagcircuit niet

Wanneer één of meerdere routers in het OSPF-domein de vraagkring niet begrijpen, treedt een periodieke LSA-vernieuwing op. Zie Wanneer wordt een periodieke LSA-vernieuwing verzonden via een OSPF-vraagcircuit? gedeelte van dit document voor informatie over het oplossen van dit probleem.

Reden 4: de hostrouter wordt opnieuw gedistribueerd in de OSPF-database

Neem het volgende netwerkdiagram als voorbeeld:

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

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 van verbindingsinkapseling PPP is, installeren beide routers een gastheerroute voor de overkant van de verbinding zoals hieronder getoond.

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 klassieke routingprotocollen. Daarom is de netwerkverklaring in de configuratie bedoeld voor een klassiek netwerk van 131.108.0.0. Wegens dit wordt de gastheerroute van 131.108.1.2/32 beschouwd om door RIP zijn voortgekomen en wordt opnieuw verdeeld in OSPF als externe route zoals hieronder 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 daalt verdwijnt /32 en OSPF begrijpt dit als verandering in topologie. De vraagkring brengt de verbinding opnieuw ter sprake om de MAXAGE versie van het /32 masker aan zijn buur te verspreiden. Wanneer de link omhoog komt, wordt het /32 masker opnieuw geldig zodat de LSA-leeftijd wordt gereset. Nadat de dode timer van de link inschakelt, gaat de link weer naar beneden. Dit proces herhaalt zich en de vraagschakeling blijft fladderen. Er zijn drie manieren om dit probleem op te lossen.

Oplossing 1: Gebruik de opdracht no-peer buur-route

Onder de interface BRI die de vraagkring in werking stelt, vorm geen peer buur-route. Dit voorkomt dat het /32 masker wordt geïnstalleerd. U kunt de configuratie gebruiken die hieronder alleen op router 1 wordt getoond, maar we raden aan om deze opdracht aan beide zijden te configureren voor consistentie.

R1# configure terminal
R1(config)# interface BRI1/1
R1(config-if)# no peer neighbor-route

Oplossing 2: Gebruik de opdracht routekaart

Wanneer het opnieuw verdelen van RIP in OSPF, gebruik het route-kaart bevel en ontken /32 zodat wordt het niet ingespoten in het OSPF- gegevensbestand. Dit configuratiebevel wordt vereist slechts op de router die de herdistributie doet, die 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 wanneer we de herverdelingsopdracht toepassen zoals hieronder wordt 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 hoofdnet

Gebruik een ander hoofdnet voor het RIP- of OSPF-domein. Het idee is om een ander belangrijk net op de vraagkringsverbinding te hebben zodat wanneer de verbinding omhoog onder PPP inkapseling komt installeert het de gastheerroute voor de overkant van de verbinding. Als de hostroute zich in een ander hoofdnetwerk bevindt dan de route die in RIP wordt gebruikt, is RIP niet eigenaar van deze PPP-geïnstalleerde hostroute omdat er geen netwerkverklaring voor het hoofdnetwerk is. Het netwerkdiagram hieronder toont een voorbeeld.

Het RIP-domein valt nu onder het 141.108.0.0-netwerk terwijl het OSPF-domein (en de vraagschakeling) zich onder het 131.108.0.0-netwerk bevindt.

Reden 5: OSPF-vraagcircuit is geconfigureerd via een asynchrone interface

Wanneer u een vraagkring over een asynchrone (async) interface vormt, dan wanneer Layer 2 daalt, daalt de daadwerkelijke fysieke interface. Dit brengt een verandering in het OSPF- gegevensbestand teweeg en de asynchrone interface komt terug omhoog opnieuw om het gegevensbestand te ruilen. Layer 2 gaat weer naar beneden, en dit zal de verandering in database opnieuw teweegbrengen, zodat dit proces blijft zichzelf herhalen.

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

De volgende configuratie wordt gebruikt voor het bovenstaande scenario.

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 standaard OSPF-netwerktype is point-to-point op een asynchrone interface, maar toch blijft het vraagcircuit 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 de vraagkring de link blijft opbrengen is omdat wanneer Layer 2 daalt nadat de ongebruikte tijd verloopt, de hele interface daalt. Maar in het geval van BRI of PRI, wanneer één van de kanalen daalt, blijft de interface nog omhoog (in spoofingmodus). Om het probleem op te lossen moet u een dialer interface configureren omdat het nooit daalt. Een dialerinterface blijft omhoog (in spoofingmodus).

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 dialer interface nooit daalt, zal het niet tot het probleem leiden dat wordt gecreëerd wanneer een asynchrone interface daalt.

Reden 6: OSPF Demand Circuit is geconfigureerd via een Multilink PPP

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

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

De volgende configuratie wordt gebruikt voor het bovenstaande scenario.

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 output toont aan dat er drie seriële interfaces zijn die in de multilink PPP zijn gebundeld.

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 verbinding 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 toont ip ospf interface toont de huidige kosten OSPF, 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 kunnen we zien 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 het tonen van 3968 en de bundel heeft slechts twee interfaces in plaats van drie omdat één interface daalde. Opmerking onder de interface is nog steeds actief:

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 is de PPP-multilink nog steeds zichtbaar, maar de OSPF-kosten zijn nu veranderd in 25 omdat één link niet actief is

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 SPF berekening zal teweegbrengen, en OSPF zal de vraagkring omhoog brengen. Als de link blijft flappen dan kunnen we zien dat het vraagcircuit blijft flappen omdat de kosten zullen worden gewijzigd telkens als een link opgeteld of verwijderd wordt uit de multilink PPP-bundel.

Oplossing

PPP multilink wordt ondersteund in OSPF, maar zolang alle link binnen de bundel omhoog blijft, zal het vraagcircuit stabiel zijn. Zodra een verbinding daalt, alhoewel er geen IP adres verbonden aan het is, zal het de OSPF kostenberekening beïnvloeden, en wegens dat, zal OSPF SPF SPF SPF de beste wegen opnieuw berekenen in werking stellen. Om dit probleem op te lossen, is de enige oplossing om de OSPF-kosten handmatig te configureren met de volgende opdracht.

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

Dit bevel zal ervoor zorgen dat telkens als er een verbinding is die wordt toegevoegd of in de multilink PPP bundel geschrapt, de kosten OSPF niet zullen worden beïnvloed. Dit zal het OSPF-vraagcircuit via de PPP-multilink stabiliseren.

Gerelateerde informatie

• Ondersteuningspagina voor OSPF
• Technische ondersteuning – Cisco Systems