Probleme mit dem Ausführen von OSPF im NBMA- und Broadcast-Modus über Frame Relay

Download-Optionen

  • PDF     (190.3 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (104.6 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (122.2 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:29. Dezember 2005
Dokument-ID:13696

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

In dieser technischen Anmerkung wird ein Problem mit OSPF-Routen erläutert, die in der Link State-Datenbank, jedoch nicht in der Routing-Tabelle in einer vollständig vernetzten Frame-Relay-Umgebung angezeigt werden. Weitere Szenarien finden Sie unter Warum befinden sich einige OSPF-Routen in der Datenbank, aber nicht in der Routing-Tabelle?

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

  • OSPF

  • Frame-Relay

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt. Die Konfiguration in diesem Dokument wurde jedoch mithilfe der folgenden Software- und Hardwareversionen getestet und aktualisiert:

  • Cisco Router der Serie 2500

  • Cisco IOS® Version 12.2(24a)

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

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

Hintergrundtheorie

Im folgenden Beispiel wird eine vollständig vernetzte Frame-Relay-Umgebung verwendet. Das Netzwerkdiagramm und die Konfigurationen sind im Folgenden dargestellt:

24a.gif

Dokument 
interface Ethernet0 
 ip address 50.50.50.50 255.255.255.0 

interface Serial0 
 encapsulation frame-relay 

!--- Enables Frame Relay encapsulation on the interface.

interface Serial0.1 multipoint 

!--- The subinterface is configured as a multipoint link.

 ip address 10.10.10.5 255.255.255.0 
 ip ospf network broadcast 

!--- This command is used to define the network type as broadcast.


!--- The network type is defined on nonbroadcast networks to
 

!--- avoid configuring the neighbors explicitly.

 frame-relay map ip 10.10.10.6 101 broadcast 
 frame-relay map ip 10.10.10.10 100 broadcast 

!--- To define the mapping between a destination protocol address


!--- and the data-link connection identifier (DLCI) used to
 

!--- connect to the destination address.
  

!--- The broadcast keyword is used to forward broadcasts to
 

!--- this address when broadcast/multicast is
 

!--- disabled because of non-broadcast medium.

router ospf 1 
 network 0.0.0.0 255.255.255.255 area 0

Schlaflosigkeit 
interface Ethernet0 
  ip address 70.70.70.70 255.255.255.0 

 interface Serial0 
  encapsulation frame-relay

!--- Enables Frame Relay encapsulation on the interface. 
interface Serial0.1 multipoint 

!--- The subinterface is configured as a multipoint link. 
  ip address 10.10.10.6 255.255.255.0 
  ip ospf network broadcast

!--- This command is used to define the network type as broadcast. 
!--- The network type is defined on nonbroadcast networks to 

!--- avoid configuring the neighbors explicitly. 
  frame-relay map ip 10.10.10.5 101 broadcast 
  frame-relay map ip 10.10.10.10 102 broadcast 

!--- To define the mapping between a destination protocol address !--- and the DLCI used to connect to the destination address. !--- The broadcast keyword is used to forward broadcasts to !--- this address when broadcast/multicast is !--- disabled because of non-broadcast medium.

 router ospf 1 
  network 0.0.0.0 255.255.255.255 area 0

neugierig 
interface Ethernet0 
  ip address 60.60.60.60 255.255.255.0 

 interface Serial0 
  encapsulation frame-relay 

!--- Enables Frame Relay encapsulation on the interface.

 interface Serial0.1 multipoint

!--- The subinterface is configured as a multipoint link. 

  ip address 10.10.10.10 255.255.255.0 
  ip ospf network broadcast

!--- This command is used to define the network type as broadcast. !--- The network type is defined on nonbroadcast networks to !--- avoid configuring the neighbors explicitly.
 


  frame-relay map ip 10.10.10.5 100 broadcast 
  frame-relay  map ip 10.10.10.6 102 broadcast 

!--- To define the mapping between a destination protocol address !--- and the DLCI used to connect to the destination address. !--- The broadcast keyword is used to forward broadcasts to !--- this address when broadcast/multicast is !--- disabled because of non-broadcast medium.

 router ospf 1 
  network 0.0.0.0 255.255.255.255 area 0

Problem

Zunächst haben alle Router alle Routen in ihren Nachbartabellen. Es tritt ein Ereignis auf, das Doc und Sleepy dazu veranlasst, sich gegenseitig aus ihren jeweiligen Nachbartabellen zu entfernen. Aus den Nachbar-Tabellen in diesem Abschnitt können wir sehen, dass die Doc Neighbor-Tabelle nicht den Eintrag 70.70.70.70 hat und die Sleepy Neighbor-Tabelle nicht den Eintrag 50.50.50.50 hat.

Doc Neighbor-Tabelle 
doc# 
show ip ospf neighbor

  
 Neighbor ID Pri State        Dead Time Address     Interface
 60.60.60.60 1   FULL/DR      00:00:33 10.10.10.10  Serial0.1
Schläfrige Nachbartabelle 
sleepy# show ip ospf neighbor

 Neighbor ID Pri State        Dead Time Address     Interface
 60.60.60.60 1   FULL/BDR     00:00:32 10.10.10.10  Serial0.1
Sneezy Neighbor-Tabelle 
sneezy# show ip ospf neighbor

 Neighbor ID Pri State        Dead Time Address     Interface
 50.50.50.50 1   FULL/DROTHER 00:00:36  10.10.10.5  Serial0.1
 70.70.70.70 1   FULL/DR      00:00:31  10.10.10.6  Serial0.1

Darüber hinaus verliert Doc alle OSPF-Routen aus seiner Routing-Tabelle, und Sleepy und Sneezy haben in ihren Routing-Tabellen nicht mehr 50.50.50.0 (Doc's LAN Subnet).

Dokument-Routing-Tabelle 
doc# 
show ip route

 Gateway of last resort is not set
      10.0.0.0 255.255.255.0 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      50.0.0.0 255.255.255.0 is subnetted, 1 subnets
 C       50.50.50.0 is directly connected, Ethernet0
Leepy Routing Table 
sleepy# show ip route
 Gateway of last resort is not set
      10.0.0.0/ 24 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      60.0.0.0/ 24 is subnetted, 1 subnets
 O       60.60.60.0 [110/ 11175] via 10.10.10.10, 00: 07: 25, Serial0.1
      70.0.0.0/ 24 is subnetted, 1 subnets
 C    70.70.70.0 is directly connected, Ethernet0
Sneezy Routing-Tabelle 
sneezy# show ip route
 Gateway of last resort is not set
      10.0.0.0/ 24 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      60.0.0.0/ 24 is subnetted, 1 subnets
 C       60.60.60.0 is directly connected, Ethernet0
      70.0.0.0/ 24 is subnetted, 1 subnets
 O       70.70.70.0 [110/ 11175] via 10.10.10.6, 00: 07: 53, Serial0.1

Obwohl Doc keine OSPF-Routen in seiner Routing-Tabelle hat, wird in der unten stehenden Ausgabe angezeigt, dass es über eine vollständige OSPF-Datenbank verfügt.

Dokumentdatenbank 
doc# 
show ip ospf database


                               OSPF Router with ID (50.50.50.50) (Process ID 1)

                                          Router Link States (Area 0)

 Link ID       ADV Router    Age    Seq#        Checksum Link count
 50.50.50.50   50.50.50.50   169    0x80000030  0x3599   2
 60.60.60.60   60.60.60.60   1754   0x8000002F  0xD26D   2
 70.70.70.70   70.70.70.70   1681   0x8000002D  0xFDD9   2

                                           Net Link States (Area 0)

 Link ID       ADV Router    Age    Seq#        Checksum
 10.10.10.6    70.70.70.70   569    0x8000002B  0x8246

Der Netzwerk-Verbindungsstatus ist ein vom designierten Router (DR) generierter Verbindungsstatus, der alle Router beschreibt, die mit dem Netzwerk verbunden sind. In der unten stehenden Ausgabe wird im DR nicht die Doc Router-ID (50.50.50.50) als angeschlossener Router aufgeführt, der das Broadcast-Modell unterbricht. Aus diesem Grund installiert Doc keine OSPF-Routen, die über das Frame-Relay-Netzwerk erfasst wurden.

Verbindungsstatus des Netzwerks 
doc# 
show ip ospf database network 10.10.10.6


                                           Net Link States (Area 0)

 LS Type: Network Links
 Link State ID: 10.10.10.6 (address of Designated Router)
 Advertising Router: 70.70.70.70

 Network Mask: 255.255.255.0
       Attached Router: 70.70.70.70
       Attached Router: 60.60.60.60

Eine weitere Möglichkeit ist, dass Doc Sneezy als DR deklariert und erwartet, dass Sneezy einen Netzwerk-Verbindungsstatus generiert. Da Sneezy jedoch kein DR ist, wird kein Link-State für das Netzwerk generiert. Dies wiederum ermöglicht Doc nicht, Routen in seiner Routing-Tabelle zu installieren.

Doc Neighbor-Tabelle 
doc# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
60.60.60.60       1   FULL/DR         00:00:29    10.10.10.10     Serial0.1

Ursachen

Laut Datenbank ist der DR für die Frame Relay Cloud "Sleepy". Allerdings sieht Sleepy Doc nicht als OSPF-Nachbarn an. Wie in diesem Beispiel gezeigt, schlägt der Ping von Sleepy zu Doc fehl:

sleepy# ping 10.10.10.5

Type escape sequence to abort.
Sending 5, 100- byte ICMP Echos to 10.10.10.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/ 5)

Aus der Ausgabe des Befehls show frame-relais map in Sleepy geht hervor, dass das DLCI, das zu Doc wechselt, inaktiv ist. Das erklärt, warum Sleepy Doc nicht pingen kann und warum sie einander nicht als Nachbarn betrachten. Dies ist das Ereignis, das das Problem ausgelöst hat:

sleepy# show frame-relay map
Serial0.1 (up): ip 10.10.10.5 dlci 101( 0x65,0x1850), static,
              broadcast,
              CISCO, status defined, inactive

Serial0.1 (up): ip 10.10.10.10 dlci 102( 0x66,0x1860), static,
              broadcast,
              CISCO, status defined, active

Da die PVC-Verbindung zwischen Doc und Sleepy unterbrochen ist und die Verbindung von Doc mit dem designierten Router (DR) defekt ist, erklärt Doc alle LSAs von Sneezy (was kein DR ist) als nicht erreichbar. Das Broadcast-Modell über Frame Relay funktioniert einwandfrei, wenn die Frame Relay Cloud vollständig vermascht ist. Wenn permanente virtuelle Schaltungen (PVCs) defekt sind, kann dies zu Problemen in der OSPF-Datenbank führen. Dies wird aus der Befehlsausgabe des show ip ospf database router unten deutlich, in der angezeigt wird, dass der Adv-Router nicht erreichbar ist.

Doc Neighbor-Tabelle 
doc# 
show ip ospf database router

             OSPF Router with ID (50.50.50.50) (Process ID 1)

                Router Link States (Area 0)

  LS age: 57
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 50.50.50.50
  Advertising Router: 50.50.50.50
  LS Seq Number: 800000D4
  Checksum: 0x355D
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.10
     (Link Data) Router Interface address: 10.10.10.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 50.50.50.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10


  Adv Router is not-reachable
  LS age: 367
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 60.60.60.60
  Advertising Router: 60.60.60.60
  LS Seq Number: 800000C9
  Checksum: 0xC865
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.6
     (Link Data) Router Interface address: 10.10.10.10
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 60.60.60.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10


  Adv Router is not-reachable
  LS age: 53
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 70.70.70.70
  Advertising Router: 70.70.70.70
  LS Seq Number: 800000CA
  Checksum: 0xEDD4
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.6
     (Link Data) Router Interface address: 10.10.10.6
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 70.70.70.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

Lösung

Wenn Sie OSPF so konfigurieren, dass es über ein Broadcast-fähiges oder nicht-Broadcast-fähiges Multizugriffsnetzwerk ausgeführt wird, müssen alle Geräte in der Lage sein, direkt (mindestens) mit dem designierten Router zu kommunizieren. Das Broadcast- und NBMA-Modell beruht darauf, dass die Frame-Relay-Cloud vollständig vernetzt ist. Wenn ein permanenter Virtual Circuit (PVC) ausfällt, ist die Cloud nicht mehr vollständig vernetzt, und OSPF funktioniert nicht ordnungsgemäß.

Wenn Layer 2 in einer Frame-Relay-Umgebung instabil ist (wie in unserem Beispiel), wird kein OSPF-Broadcast-Netzwerktyp empfohlen. Verwenden Sie stattdessen OSPF Point-to-Multipoint.

Zugehörige Informationen

Revisionsverlauf

Überarbeitung Veröffentlichungsdatum Kommentare
1.0
29-Dec-2005
Erstveröffentlichung

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.