In diesem Dokument wird ein Problem mit OSPF, EIGRP, RIP und IGRP über Frame-Relay beim Upgrade von Cisco IOS® 10.3 auf 11.2 oder höher für die Einhaltung der Bestimmungen des Jahres 2000 beschrieben.
Nach einem Upgrade auf Cisco IOS 11.2 oder höher, um die Anforderungen von Jahr 2000 zu erfüllen, wird beim Betrieb über eine Frame-Relay-Verbindung ein zeitweiliger Verlust von Routen beobachtet, die über diese Routing-Protokolle erfasst wurden.
Die Leser dieses Dokuments sollten über folgende Punkte Bescheid wissen:
Grundlegende Kenntnisse der Routing-Protokolle OSPF, EIGRP, IGRP und RIP
Die Informationen in diesem Dokument basieren auf den Versionen Software und Hardware:
Geräte mit Cisco IOS 11.2 oder höher
Die angezeigte Ausgabe basiert auf der Cisco IOS-Version 12.3(3).
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.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Dieses Problem tritt auf, weil Broadcasts in Frame Relay von einer separaten Warteschlange behandelt werden, die als Frame Relay-Broadcast-Warteschlange bezeichnet wird. Der Befehl Frame-Relay Broadcast-Queue wird im Schnittstellenmodus verwendet, um eine spezielle Warteschlange für Broadcast-Datenverkehr zu erstellen.
OSPF- und EIGRP-Hellos können in die Broadcast-Warteschlange fallen, was den Verlust des Nachbarn verursacht.
Hinweis: Ein ähnliches Problem kann auch bei RIP- und IGRP-Netzwerken auftreten. Wenn die Updates für einen bestimmten Zeitraum nicht empfangen werden, können die Routen kontinuierlich in den Holdown-Modus versetzt werden.
Die Ausgabe des Befehls show interface serial zeigt eine erhebliche Anzahl von Verlusten in der Broadcast-Warteschlange für Frame-Relay an. Nachfolgend finden Sie eine Beispielausgabe:
Serial0 is up, line protocol is up Hardware is MK5025 Description: Charlotte Frame Relay Port DLCI 100 MTU 1500 bytes, BW 1024 Kbit, DLY 20000 usec, reliability 255/255, txload 44/255, rxload 44/255 Encapsulation FRAME-RELAY, loopback not set, keepalive set (10 sec) LMI enq sent 7940, LMI stat recvd 7937, LMI upd recvd 0, DTE LMI up LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 LMI DLCI 1023 LMI type is CISCO frame relay DTE Broadcast queue 64/64, broadcasts sent/dropped 1769202/1849660, interface broadcasts 3579215 !--- Output suppressed
Passen Sie die Broadcast-Warteschlange entsprechend an, um dieses Problem zu vermeiden. Weitere Informationen finden Sie im Abschnitt Frame Relay Broadcast Queue zur Konfiguration und Fehlerbehebung von Frame Relay.
Weitere Informationen finden Sie in den Versionshinweisen für den Bug CSCdk45863 (nur registrierte Kunden).
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
01-Jan-2008 |
Erstveröffentlichung |