Waarom vormt OSPF geen nabijheid op een PRI, BRI of Kiezerinterface?

Inleiding

Deze technische opmerking legt een probleem uit met de vorming van OSPF-nabijheid wanneer de dialerinterfaces zijn geconfigureerd als point-to-point links.

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.

Het probleem

Het OSPF-netwerk-type op Primaire Rate Interface (PRI), Basic Rate Interface (BRI) en dialer interfaces zijn point-to-point, wat betekent dat een interface geen nabijheid met meer dan één buurman kan vormen. Een gemeenschappelijk probleem wanneer een PRI, BRI, of dialer interfaces proberen een nabijheid te vormen OSPF is de buur die in het uiteinde/uitwisselingsproces wordt vastgehouden. Laten we naar een voorbeeld kijken.

Met de opdracht om ip ospf buurland te tonen, kunnen we zien dat de buurstaat vast zit in "EXSTART".

RTR-A# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23
3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23

RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0

RTR-C# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

De configuratie van RTR-Bs toont het netwerktype punt-tot-punt:

RTR-B# show ip ospf interface bri0 
     BRI0 is up, line protocol is up (spoofing) 
       Internet Address 3.3.3.3/24, Area 2 
       Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562 
       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:06 
       Index 1/1, flood queue length 0 
       Next 0x0(0)/0x0(0) 
       Last flood scan length is 1, maximum is 1 
       Last flood scan time is 0 msec, maximum is 0 msec 
       Neighbor Count is 1, Adjacent neighbor count is 0 
       Suppress hello for 0 neighbor(s) 

We kunnen deze situatie oplossen met de opdracht debug ip ospf adj. Laten we kijken naar een aantal voorbeelduitvoer die is genomen tijdens het uitvoeren van deze opdracht op RTR-B in de afbeelding hierboven:

1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXSTART 
3: First DBD and we are not SLAVE 
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu 
   1500 state EXSTART 
5: NBR Negotiation Done. We are the MASTER 
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 
7: Database request to 3.3.3.2 
8: sent LS REQ packet to 3.3.3.2, length 12 
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXCHANGE 
10: EXCHANGE - inconsistent in MASTER/SLAVE 
11: Bad seq received from 3.3.3.2 on BRI0 
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92 
    mtu 1500 state EXSTART 
14: Unrecognized dbd for EXSTART 
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32 
    mtu 1500 state EXSTART 
16: Unrecognized dbd for EXSTART 

Lijnen 1 - 3: RTR-B verstuurt de eerste DBD naar 3.3.3.2 (RTR-A) met reeks 0xB41 en ontvangt de eerste DBD van 3.3.3.2 (RTR-A) met reeks# 0x1D06. De buurlandenonderhandeling is nog niet voltooid.

Lijnen 4 - 6: RTR-B ontvangt een antwoord van 3.3.3.2 (RTR-A) waarin staat dat RTR-A de eerste DBD van RTR-B heeft ontvangen. Aangezien RTR-B de hogere router-ID heeft, selecteert RTR-A zichzelf als slaaf. Na het ontvangen van de ontvangstbevestiging van RTR-A, verklaart RTR-B zichzelf de baas en stuurt de eerste DBD met gegevens erin. Let op het volgnummer, dat 0xB42 is. Aangezien RTR-B de master is, kan alleen het sequentienummer worden verhoogd.

Lijn 7: RTR-B vraagt om gegevens van RTR-A aangezien RTR-A heeft aangegeven dat het meer gegevens te verzenden heeft (vlag ingesteld op 0x2 in laatste DBD ontvangen van RTR-A).

Lijn 8: RTR-B stuurt een link-state aanvraagpakket naar 3.3.3.2 (RTR-A). Dit is een OSPF-pakkettype 3. Dit pakket wordt gewoonlijk naar het IP-adres van de buurman verzonden. In dit geval is het IP-adres van de buur zijn router-ID.

Lijnen 9 - 11: RTR-B ontvangt een antwoord van slave (RTR-A) met een volledig ander volgnummer en een vlag van 0x7, de binnenvlag. Deze DBD was bedoeld voor een andere router (zeer waarschijnlijk RTR-C), maar RTR-B heeft deze onjuist ontvangen. RTR-B verklaart dat er een discrepantie bestaat omdat een vlag van 0x7 betekent dat de slavin zijn status heeft gewijzigd in de vorm van een masterbek door het MS (Master/Slave) bit te bepalen tijdens de nabijheidsuitwisseling. RTR-B klaagt ook over het sequentienummer omdat het niet werkt. De slavin moet altijd het sequentienummer van de kapitein volgen.

Lijn 12: RTR-B herinitialiseert de nabijheid door de eerste DBD naar 3.3.3.2 te verzenden om meester en slaaf opnieuw te selecteren.

Lijnen 13 - 14: RTR-B ontvangt een DBD van 3.3.3.2 (RTR-A), wat aangeeft dat het een slaaf is, zonder RTR-B's sequentienummer te herkennen. RTR-B verklaart dat het deze DBD niet herkent omdat de master- en slavenonderhandeling nog niet voltooid is. Dit DBD-pakket was bedoeld voor een andere router.

Lijn 15: RTR-B ontvangt een antwoord van 3.3.3.2 (RTR-A) voor de oude DBD, maar het is te laat omdat RTR-B het nabijheidsproces al herinitialiseert.

Lijn 16: RTR-B herkent deze DBD niet omdat dit een 'oude' nabijheid is, die RTR-B al heeft afgebroken.

Dit proces zal eindeloos herhalen.

De oplossing

Volgens sectie 8.1 van RFC 2328 , stuurt OSPF een multicast pakket voor een point-to-point netwerk-type zelfs nadat de interface de 2-way status bereikt heeft. Aangezien RTR-A probeert om nabijheid met zowel RTR-B als RTR-C te vormen, ontvangt RTR-B pakketten die voor RTR-C bedoeld zijn en RTR-C DBD pakketten die voor RTR-B bedoeld zijn ontvangen.

Om dit probleem op te lossen, wijzigt u het netwerktype op alle routers in punt-to-multipoint. Dit verandert het gedrag van OSPF om unicast pakketten na de 2-weg staat te verzenden. Nu ontvangt RTR-B alleen pakketten die voor zichzelf bestemd zijn en RTR-C ontvangt pakketten die voor zichzelf bestemd zijn. Door het netwerk-type op deze manier te veranderen verzekert dat de router OSPF nabijheid op een PRI, BRI, of dialer interface zal vormen.

Wilt u het netwerktype wijzigen, dan voert u de volgende configuratieopdrachten in, waarbij u elke regel eindigt door op ENTER te drukken. We veranderen RTR-B als voorbeeld.

RTR-B# configure terminal 
RTR-B(config)# int bri 0 
RTR-B(config-if)# ip ospf network point-to-multipoint 
RTR-B(config-if)# end 

Als we nu naar de opdrachten voor RTR-B kijken, kunnen we controleren of het netwerktype point-to-multipoint is en de staat vol is.

RTR-B# show ip ospf interface bri0 
BRI0 is up, line protocol is up (spoofing) 
  Internet Address 3.3.3.3/24, Area 2 
  Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562 
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, 
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 
    Hello due in 00:00:16 
  Index 1/1, flood queue length 0 
  Next 0x0(0)/0x0(0) 
  Last flood scan length is 1, maximum is 1 
  Last flood scan time is 0 msec, maximum is 0 msec 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 172.16.141.10 
  Suppress hello for 0 neighbor(s) 
  
RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0 

Gerelateerde informatie

• BRI-to-BRI bellen met DDR Dialer-kaarten configureren
• OSPF-ondersteuningspagina
• Technische ondersteuning - Cisco-systemen

Revisiegeschiedenis