Fehlerbehebung bei Problemen mit seriellen Leitungen

Einführung

In diesem Kapitel werden allgemeine Informationen zur Fehlerbehebung sowie Tools und Techniken zur Fehlerbehebung bei seriellen Verbindungen vorgestellt. Das Kapitel besteht aus den folgenden Abschnitten:

• Fehlerbehebung mit dem Befehl show interfaces serial Command

• Befehl show controller verwenden

• Verwenden von Debug-Befehlen

• Verwenden erweiterter Ping-Tests

• Fehlerbehebung bei Problemen mit der Taktgebung

• Anpassen von Puffern

• Serielle Sondertests

• Detaillierte Informationen zum Befehl show interfaces serial Command

• Fehlerbehebung bei T1-Problemen

• Problembehebung bei E1-Problemen

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten mit den folgenden Definitionen vertraut sein.

• DTE = Datenendgeräte

• CD = Carrier Detection

• CSU = Channel Service Unit

• DSU = Digital Service Unit

• SCTE = Serial Clock Transmit externem Datenverkehr

• DCE = Data Circuit-Terminating Equipment

• CTS = Clear-to-Send

• DSR = Data Set Ready

• SAP = Service Advertising Protocol

• IPX = Internetwork Packet Exchange

• FDDI = Fiber Distributed Data Interface

• ESF = Erweitertes Superframe-Format

• B8ZS = binäre 8-Null-Substitution

• LBO = Line Build Out

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Konventionen

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

Fehlerbehebung mithilfe des seriellen Befehls show interfaces

In der Ausgabe des Befehls show interfaces serial EXEC werden Informationen zu seriellen Schnittstellen angezeigt. Abbildung 15-1 zeigt die Ausgabe des Befehls show interfaces Serial EXEC für eine serielle Schnittstelle der High-Level Data Link Control (HDLC).

In diesem Abschnitt wird beschrieben, wie Sie den Befehl show interfaces serial verwenden, um Verbindungsprobleme bei seriellen Leitungen in einer WAN-Umgebung (Wide Area Network) zu diagnostizieren. In den folgenden Abschnitten werden einige der wichtigsten Felder der Befehlsausgabe beschrieben.

Weitere in der Anzeige angezeigte Felder werden im Abschnitt "Detaillierte Informationen zum Befehl show interfaces serial Command" weiter unten in diesem Kapitel ausführlich beschrieben.

Serielle Posten: Serielle Statuszeilenbedingungen anzeigen

In der Schnittstellenstatuszeile der seriellen Anzeige der Bedienoberflächen können Sie fünf mögliche Problemzustände identifizieren (siehe Abbildung 15-1):

• Serial x ist ausgefallen, das Leitungsprotokoll ist ausgefallen.

• Serial x ist aktiv, Leitungsprotokoll ist ausgefallen.

• Serial x ist aktiv, Leitungsprotokoll ist aktiv (Looped)

• Serial x ist aktiv, Leitungsprotokoll ist inaktiv (deaktiviert)

• Serial x ist administrativ ausgefallen, das Verbindungsprotokoll ist ausgefallen.

Abbildung 15-1 Ausgabe von HDLC show interface serial Command

Tabelle 15-1: Serielle Posten: show interfaces Serial Status Line Conditions - Diese Tabelle zeigt die Schnittstellenstatusbedingungen, mögliche Probleme im Zusammenhang mit den Bedingungen und Lösungen für diese Probleme.

Status Line Condition	Mögliche Probleme	Lösung
Serial x ist aktiv, Verbindungsprotokoll ist aktiv.		Dies ist der korrekte Status-Leitungszustand. Keine Aktion erforderlich.
Serial x ist ausgefallen, Leitungsprotokoll ist ausgefallen (DTE-Modus)	Zeigt normalerweise an, dass der Router kein CD-Signal erkennt (d. h., die CD ist nicht aktiv). Telefongesellschaft Problem Line ist inaktiv oder Leitung ist nicht an CSU/DSU angeschlossen Fehlerhafte oder falsche Verkabelung Hardwarefehler (CSU/DSU)	Überprüfen Sie die LEDs auf dem CSU/DSU, ob die CD aktiv ist, oder legen Sie ein Breakout-Feld an der Leitung ein, um das CD-Signal zu überprüfen. Überprüfen Sie, ob Sie das richtige Kabel und die richtige Schnittstelle verwenden (siehe Hardwareinstallationsdokumentation). Setzen Sie ein Breakout-Feld ein, und überprüfen Sie alle Kontrollpunkte. Wenden Sie sich an Ihren Mietleitungsdienst oder einen anderen Carrier-Service, um festzustellen, ob ein Problem vorliegt. Tauschen Sie fehlerhafte Teile aus. Wenn Sie den Verdacht haben, dass die Router-Hardware defekt ist, wechseln Sie die serielle Leitung zu einem anderen Port. Wenn die Verbindung hergestellt wird, besteht ein Problem mit der zuvor verbundenen Schnittstelle.
Serial x ist aktiv, Leitungsprotokoll ist ausgefallen (DTE-Modus)	Lokaler oder Remote-Router ist falsch konfiguriert Keepalives werden nicht von einem Remote-Router gesendet. Service-Problem: Mietleitung oder anderer Carrier-Service, Störgeräusche oder falsch konfigurierter oder ausgefallener Switch Zeitproblem am Kabel (SCTE nicht auf CSU/DSU eingestellt) Fehlgeschlagene lokale oder Remote-CSU/DSU Fehlgeschlagene lokale oder Remote-CSU/DSU Router-Hardwarefehler (lokal oder remote)	Setzen Sie das Modem, die CSU oder die DSU in den lokalen Loopback-Modus, und verwenden Sie den Befehl show interfaces serial, um festzustellen, ob das Leitungsprotokoll aktiviert wird. Wenn das Verbindungsprotokoll aktiviert wird, ist das wahrscheinliche Problem ein Problem mit der Telefongesellschaft oder ein ausgefallener Remote-Router. Wenn das Problem am Remote-Ende zu liegen scheint, wiederholen Sie Schritt 1 auf dem Remote-Modem, der CSU oder der DSU. Überprüfen Sie alle Kabel. Vergewissern Sie sich, dass das Kabel an die richtige Schnittstelle, die richtige CSU/DSU und den richtigen Terminierungspunkt im Telefonnetzwerk angeschlossen ist. Verwenden Sie den Befehl show controller EXEC, um festzustellen, welches Kabel an welche Schnittstelle angeschlossen ist. Aktivieren Sie den Befehl debug Serial interface EXEC. Vorsicht: Da die Debugausgabe im CPU-Prozess eine hohe Priorität erhält, kann das System unbrauchbar gemacht werden. Verwenden Sie deshalb Debugging-Befehle nur zur Fehlerbehebung bei bestimmten Problemen oder bei Sitzungen zur Fehlerbehebung mit dem technischen Support von Cisco. Darüber hinaus empfiehlt es sich, Debug-Befehle in Zeiträumen zu verwenden, in denen der Netzwerkverkehr niedrig und die Anzahl der Benutzer reduziert ist. Das Debuggen während dieser Zeiträume verringert die Wahrscheinlichkeit, dass sich ein erhöhter Overhead bei der Debug-Befehlsverarbeitung auf die Systemnutzung auswirkt. Wenn das Line-Protokoll nicht im lokalen Loopback-Modus verfügbar ist und die Ausgabe des Befehls Serielle Debugschnittstelle EXEC zeigt, dass der Keepalive-Zähler nicht inkrementiert, ist ein Problem mit der Router-Hardware wahrscheinlich. Tauschen Sie die Router-Schnittstellenhardware aus. Wenn das Leitungsprotokoll aktiviert wird und der Keepalive-Zähler inkrementiert wird, liegt das Problem nicht im lokalen Router. Führen Sie eine Fehlerbehebung für die serielle Leitung durch, wie in den Abschnitten "Fehlerbehebung bei Blockierungsproblemen" und "CSU- und DSU-Loopback-Tests" weiter unten in diesem Kapitel beschrieben. Wenn Sie den Verdacht haben, dass die Router-Hardware defekt ist, ändern Sie die serielle Leitung in einen nicht verwendeten Port. Wenn die Verbindung hergestellt wird, besteht ein Problem mit der zuvor verbundenen Schnittstelle.
Serial x ist aktiv, Leitungsprotokoll ist ausgefallen (DCE-Modus)	Schnittstellenkonfigurationsbefehl für die Taktfrequenz fehlt Das DTE-Gerät unterstützt den SCTE-Modus nicht oder ist nicht dafür eingerichtet. Fehlgeschlagene Remote-CSU oder DSU Fehlerhaftes Kabel Router-Hardwarefehler	Fügen Sie den Befehl zur Konfiguration der Taktfrequenz-Schnittstelle an der seriellen Schnittstelle hinzu. Syntax: Beschreibung der Taktfrequenz bps: bps-gewünschte Taktrate in Bit pro Sekunde: 1200, 2400, 4800, 9600, 19200, 38400, 56000, 64000, 72000, 12500, 148 000, 250000, 500000, 800000, 100000, 130000, 2000000, 400000 oder 8 000000. Stellen Sie das DTE-Gerät so weit wie möglich auf SCTE-Modus ein. Wenn Ihr CSU/DSU SCTE nicht unterstützt, müssen Sie möglicherweise SCTE auf der Cisco Router-Schnittstelle deaktivieren. Siehe Abschnitt "Umkehren der Übermittlungszeit" weiter unten in diesem Kapitel. Überprüfen Sie, ob das richtige Kabel verwendet wird. Wenn das Verbindungsprotokoll immer noch ausgefallen ist, besteht ein mögliches Hardware- oder Verkabelungsproblem. Setzen Sie eine Breakout-Box ein, und beobachten Sie Leads. Ersetzen Sie bei Bedarf fehlerhafte Teile.
Serial x ist aktiv, Leitungsprotokoll ist aktiv (Looped)	Eine Schleife existiert in der Schaltung. Die Sequenznummer im Keepalive-Paket ändert sich zu einer zufälligen Zahl, wenn eine Schleife erstmals erkannt wird. Wenn dieselbe Zufallsnummer über die Verbindung zurückgegeben wird, existiert eine Schleife.	Suchen Sie mithilfe des Befehls show running-config des privilegierten EXEC-Modus nach Befehlseinträgen für die Loopback-Schnittstellenkonfiguration. Wenn Sie einen Befehl zur Loopback-Schnittstellenkonfiguration finden, entfernen Sie die Schleife mit dem Befehl no loopback interface configuration. Wenn Sie den Befehl Loopback-Schnittstellenkonfiguration nicht finden, überprüfen Sie die CSU/DSU, um festzustellen, ob sie im manuellen Loopback-Modus konfiguriert sind. Ist dies der Fall, deaktivieren Sie das manuelle Loopback. Setzen Sie die CSU oder DSU zurück, und überprüfen Sie den Leitungsstatus. Wenn das Leitungsprotokoll aktiviert wird, ist keine andere Aktion erforderlich. Wenn die CSU oder DSU nicht im manuellen Loopback-Modus konfiguriert ist, wenden Sie sich an den Mietleitungsdienst oder einen anderen Carrier-Service, um Unterstützung bei der Behebung von Leitungsfehlern zu erhalten.
Serial x ist aktiv, Leitungsprotokoll ist inaktiv (deaktiviert)	Hohe Fehlerrate aufgrund von Serviceproblemen in der Telefongesellschaft Problem mit CSU- oder DSU-Hardware Falsche Router-Hardware (Schnittstelle)	Fehlerbehebung für die Leitung mit einem seriellen Analyzer und Breakout-Box Achten Sie auf umschalten CTS- und DSR-Signale. Schleife CSU/DSU (DTE-Schleife). Wenn das Problem weiterhin besteht, besteht wahrscheinlich ein Hardwareproblem. Wenn das Problem nicht weitergeht, besteht wahrscheinlich ein Problem mit der Telefongesellschaft. Auslagern defekter Hardware nach Bedarf (CSU, DSU, Switch, lokaler oder Remote-Router).
Serial x ist administrativ ausgefallen, das Verbindungsprotokoll ist ausgefallen.	Die Router-Konfiguration beinhaltet den Schnittstellenkonfigurationsbefehl shutdown Doppelte IP-Adresse	Überprüfen Sie die Router-Konfiguration auf den Befehl shutdown. Verwenden Sie den Befehl no shutdown interface configuration, um den Befehl shutdown zu entfernen. Stellen Sie sicher, dass mit dem Befehl show running-config des privilegierten EXEC-Modus oder dem Befehl show interfaces EXEC keine identischen IP-Adressen vorhanden sind. Wenn doppelte Adressen vorhanden sind, beheben Sie den Konflikt, indem Sie eine der IP-Adressen ändern.

Serielle Posten: Erhöhte Ausgabegeschwindigkeit bei serieller Verbindung

In der Ausgabe des Befehls show interfaces serial (siehe Abbildung 15-1) werden Ausgabetropfen angezeigt, wenn das System versucht, ein Paket an einen Übertragungspuffer zu übergeben, jedoch keine Puffer verfügbar sind.

Symptom: Eine steigende Anzahl von Ausgabepunkten wird bei serieller Verbindung ausfallen.

Tabelle 15-2 Serielle Posten: Erhöhte Ausgabe bei serieller Verbindung - In dieser Tabelle wird das mögliche Problem beschrieben, das zu diesem Symptom führen kann, und es werden Lösungen vorgeschlagen.

Mögliche Probleme

Lösung

Die Eingangsrate der seriellen Schnittstelle überschreitet die verfügbare Bandbreite für serielle Verbindungen.

Minimieren des regelmäßigen Broadcast-Datenverkehrs (z. B. Routing und SAP-Updates) mithilfe von Zugriffslisten oder auf andere Weise Um beispielsweise die Verzögerung zwischen SAP-Updates zu erhöhen, verwenden Sie den Schnittstellenkonfigurationsbefehl ipx sap-interval. Erhöhen Sie die Größe der Ausgabewarteschlange in kleinen Schritten (z. B. 25 Prozent) mithilfe des Schnittstellenkonfigurationsbefehls Hold-Queue Out. Deaktivieren Sie auf betroffenen Schnittstellen das schnelle Switching für häufig verwendete Protokolle. Um z. B. das IP Fast Switching zu deaktivieren, geben Sie den Schnittstellenkonfigurationsbefehl no ip route-cache ein. Die Befehlssyntax für andere Protokolle finden Sie in den Cisco IOS-Konfigurationsanleitungen und Befehlsreferenzen. Implementieren Sie Prioritätswarteschlangen auf langsameren seriellen Verbindungen, indem Sie Prioritätslisten konfigurieren. Informationen zum Konfigurieren von Prioritätslisten finden Sie in den Cisco IOS-Konfigurationsanleitungen und Befehlsreferenzen. Hinweis: Unter bestimmten Bedingungen sind Ausgabeverluste akzeptabel. Wenn beispielsweise bekannt ist, dass eine Verbindung überbeansprucht wird (ohne Abhilfe zu schaffen), ist es oft vorzuziehen, Pakete zu verwerfen, anstatt sie zu halten. Dies gilt für Protokolle, die Flusskontrolle unterstützen und Daten erneut übertragen können (z. B. TCP/IP und Novell IPX). Einige Protokolle, wie DECnet und Local Area Transport, reagieren jedoch empfindlich auf verworfene Pakete und ermöglichen eine schlechte Wiederübertragung.

Serielle Posten: Erhöhte Eingangsverluste bei seriellen Verbindungen

In der Ausgabe des Befehls show interfaces Serial EXEC (siehe Abbildung 15-1) werden Eingabeverluste angezeigt, wenn noch zu viele Pakete dieser Schnittstelle im System verarbeitet werden.

Symptom: Eine steigende Anzahl von Eingängen wird bei serieller Verbindung verworfen.

Tabelle 15-3: Serielle Posten: Erhöhte Eingangsverluste bei seriellen Verbindungen: In dieser Tabelle werden mögliche Probleme beschrieben, die zu diesem Symptom führen können, und Lösungsvorschläge unterbreitet.

Mögliche Probleme

Lösung

Die Eingangsrate überschreitet die Kapazität des Routers oder die Anzahl der Eingangswarteschlangen überschreitet die Größe der Ausgabewarteschlangen.

Hinweis: Beim Routing von Datenverkehr zwischen schnelleren Schnittstellen (z. B. Ethernet, Token Ring und FDDI) und seriellen Schnittstellen treten häufig Probleme beim Input-Drop auf. Bei geringem Datenverkehr besteht kein Problem. Wenn die Datenverkehrsraten steigen, beginnen Backups. Router verwerfen während dieser überlasteten Zeiten Pakete. Erhöhen Sie die Größe der Ausgabewarteschlange an allgemeinen Zielschnittstellen für die Schnittstelle, die Pakete verwirft. Verwenden Sie den Schnittstellenkonfigurationsbefehl Hold-Queue out. Erhöhen Sie diese Warteschlangen um kleine Erhöhungen (z. B. um 25 Prozent), bis die Ausgabe der Anzeigeschnittstellen nicht mehr verworfen wird. Der Grenzwert für die Warteschlangenwareneinstellung für die Ausgabe beträgt standardmäßig 100 Pakete. Reduzieren Sie die Größe der Eingabewarteschlange mithilfe des Schnittstellenkonfigurationsbefehls, um zu erzwingen, dass Eingabetaste zu Ausgabeverlusten werden. Ausgabeverwerfungen haben weniger Auswirkungen auf die Leistung des Routers als Eintrittseinbrüche. Die Standard-Warteschlange für die Warteschlange für die Warteschleifeneingabe beträgt 75 Pakete.

Serielle Posten: Zunahme von Eingangsfehlern bei mehr als einem Prozent des gesamten Schnittstellendatenverkehrs

Wenn Eingabefehler in der Ausgabe der seriellen Schnittstellen angezeigt werden (siehe Abbildung 15-1), gibt es mehrere mögliche Ursachen für diese Fehler. Die wahrscheinlichsten Quellen sind in Tabelle 15-4 zusammengefasst.

Hinweis: Jeder Eingabefehlerwert für CRC-Fehler, Framing-Fehler oder Abbruch von mehr als einem Prozent des gesamten Schnittstellendatenverkehrs deutet auf ein Verbindungsproblem hin, das isoliert und repariert werden sollte.

Symptom: Immer mehr Eingabefehler machen mehr als ein Prozent des gesamten Schnittstellendatenverkehrs aus.

Tabelle 15-4: Serielle Posten: Zunahme von Eingangsfehlern bei mehr als einem Prozent des gesamten Schnittstellendatenverkehrs

Mögliche Probleme

Lösung

Folgende Probleme können zu diesem Symptom führen: Fehlerhafte Telefonanlage Geräusche serielle Leitung Falsche Konfiguration der Taktgebung (SCTE nicht eingestellt) Falsches Kabel oder zu langes Kabel Schlechtes Kabel oder fehlerhafte Verbindung Falsche CSU oder DSU Falsche Router-Hardware Datenkonverter oder anderes Gerät, das zwischen Router und DSU verwendet wird

Hinweis: Cisco empfiehlt dringend, keine Datenkonverter zu verwenden, wenn Sie einen Router mit einem WAN oder seriellen Netzwerk verbinden. Verwenden Sie einen seriellen Analyzer, um die Quelle der Eingabefehler zu isolieren. Wenn Sie Fehler erkennen, ist es wahrscheinlich, dass ein Gerät, das nicht zum Router gehört, ein Hardwareproblem oder eine Uhrzeitinkongruenz aufweist. Verwenden Sie die Loopback- und Ping-Tests, um die spezifische Problemquelle zu isolieren. Weitere Informationen finden Sie in den Abschnitten "Using the trace Command" und "CSU and DSU Loopback Tests" weiter unten in diesem Kapitel. Suchen Sie nach Mustern. Wenn beispielsweise Fehler in einem konsistenten Intervall auftreten, können sie mit einer periodischen Funktion zusammenhängen, z. B. dem Senden von Routing-Updates.

Serielle Posten: Fehlerbehebung bei Eingangsfehlern in der seriellen Leitung

Tabelle 15-5: In dieser Tabelle werden die verschiedenen Typen von Eingabefehlern beschrieben, die durch den Befehl show interfaces serial (siehe Abbildung 15-1) angezeigt werden, mögliche Probleme, die zu den Fehlern führen können, sowie die Lösungen für diese Probleme.

Eingabefehlertyp (Feldname)	Mögliche Probleme	Lösung
CRC-Fehler (CRC)	CRC-Fehler treten auf, wenn die CRC-Berechnung nicht erfolgreich verläuft und darauf hinweist, dass Daten beschädigt sind - aus einem der folgenden Gründe: Geräusche serielle Leitung Das serielle Kabel ist zu lang, oder das Kabel vom CSU/DSU zum Router ist nicht abgeschirmt. Der SCTE-Modus ist auf DSU nicht aktiviert. Die CSU-Leitungs-Uhr ist falsch konfiguriert. Eines Dichteproblem auf T1-Verbindung (falsche Framing- oder Codierungsspezifikation)	Stellen Sie sicher, dass die Leitung sauber genug für die Übertragungsanforderungen ist. Falls erforderlich, das Kabel abschirmen. Vergewissern Sie sich, dass das Kabel die empfohlene Länge hat - nicht mehr als 15,24 Meter oder 7,62 Meter für T1-Verbindungen. Stellen Sie sicher, dass alle Geräte ordnungsgemäß für eine gemeinsame Leitungs-Uhr konfiguriert sind. Legen Sie SCTE auf der lokalen und Remote-DSU fest. Wenn Ihr CSU/DSU SCTE nicht unterstützt, lesen Sie den Abschnitt "Invertieren der Übertragungs-Uhr" weiter unten in diesem Kapitel. Stellen Sie sicher, dass die lokale und Remote-CSU/DSU für dasselbe Framing- und Codierungsschema konfiguriert sind, das auch von der Mietleitung oder anderen Betreiberdiensten (z. B. ESF/B8ZS) verwendet wird. Kontaktieren Sie Ihren Mietleitungsdienst oder einen anderen Carrier-Service, und lassen Sie ihn Integritätsprüfungen auf der Leitung durchführen.
Framing-Fehler (Frame)	Ein Framing-Fehler tritt auf, wenn ein Paket nicht an einer 8-Bit-Bytegrenze endet, und zwar aus einem der folgenden Gründe: Geräusche serielle Leitung Falsch ausgelegtes Kabel; Das serielle Kabel ist zu lang. Das Kabel vom CSU oder DSU zum Router ist nicht abgeschirmt. Der SCTE-Modus ist auf der DSU nicht aktiviert. Die CSU-Leitungs-Uhr ist falsch konfiguriert. Eine der Uhren ist für die lokale Taktgebung konfiguriert. Eines Dichteproblem auf T1-Verbindung (falsche Framing- oder Codierungsspezifikation)	Stellen Sie sicher, dass die Leitung sauber genug für die Übertragungsanforderungen ist. Falls erforderlich, das Kabel abschirmen. Stellen Sie sicher, dass Sie das richtige Kabel verwenden. Vergewissern Sie sich, dass das Kabel die empfohlene Länge hat - nicht mehr als 15,24 Meter oder 7,62 Meter für T1-Verbindungen. Stellen Sie sicher, dass alle Geräte ordnungsgemäß für die Verwendung einer einheitlichen Leitungs-Uhr konfiguriert sind. Legen Sie SCTE auf der lokalen und Remote-DSU fest. Wenn Ihr CSU/DSU SCTE nicht unterstützt, lesen Sie den Abschnitt "Invertieren der Übertragungs-Uhr" weiter unten in diesem Kapitel. Stellen Sie sicher, dass der lokale und Remote-CSU/DSU für dasselbe Framing- und Codierungsschema konfiguriert ist, das auch von der Mietleitung oder anderen Betreiberdiensten (z. B. ESF/B8ZS) verwendet wird. Kontaktieren Sie Ihren Mietleitungsdienst oder einen anderen Carrier-Service, und lassen Sie ihn Integritätsprüfungen auf der Leitung durchführen.
Abgebrochene Übertragung (Abbruch)	Aborte weisen auf eine illegale Abfolge von ein Bits hin (mehr als sieben aufeinander). Folgende Gründe können für dieses Auftreten vorliegen: Der SCTE-Modus ist auf DSU nicht aktiviert. Die CSU-Leitungs-Uhr ist falsch konfiguriert. Das serielle Kabel ist zu lang, oder das Kabel vom CSU oder DSU zum Router ist nicht abgeschirmt. Eines Dichteproblem auf T1-Verbindung (falsche Framing- oder Codierungsspezifikation) Das Paket wird mitten in der für die Übertragung typischen Ursache als Schnittstellenrücksetzung oder Framing-Fehler beendet. Hardware-defekte Schaltung, fehlerhafte CSU/DSU oder fehlerhafte Sendeschnittstelle auf dem Remote-Router	Stellen Sie sicher, dass alle Geräte ordnungsgemäß für die Verwendung einer einheitlichen Leitungs-Uhr konfiguriert sind. Legen Sie SCTE auf der lokalen und Remote-DSU fest. Wenn Ihr CSU/DSU SCTE nicht unterstützt, lesen Sie den Abschnitt "Invertieren der Übertragungs-Uhr" weiter unten in diesem Kapitel. Falls erforderlich, das Kabel abschirmen. Vergewissern Sie sich, dass das Kabel die empfohlene Länge hat - nicht mehr als 15,24 Meter oder 7,62 Meter für T1-Verbindungen. Stellen Sie sicher, dass alle Verbindungen gut sind. Überprüfen Sie die Hardware an beiden Enden des Links. Tauschen Sie fehlerhafte Geräte bei Bedarf aus. Geringere Datenraten und eine Abnahme der abgebrochenen Nachrichten. Verwenden Sie lokale und Remote-Loopback-Tests, um festzustellen, wo Abtreibungen auftreten. Siehe Abschnitt "Serielle Sondertests" weiter unten in diesem Kapitel. Kontaktieren Sie Ihren Mietleitungsdienst oder einen anderen Carrier-Service, und lassen Sie ihn Integritätsprüfungen auf der Leitung durchführen.

Serielle Posten: Erhöhen der Schnittstellenrücksetzung auf serielle Verbindung

Schnittstellenrücksetzer, die in der Ausgabe des Befehls show interfaces erscheinen (siehe Abbildung 15-1), sind das Ergebnis verpasster Keep-Alive-Pakete.

Symptom: Immer mehr Schnittstellen werden auf die serielle Verbindung zurückgesetzt.

Tabelle 15-6: Diese Tabelle zeigt die möglichen Probleme, die zu diesem Symptom führen können, und schlägt Lösungen vor.

Mögliche Probleme

Lösung

Folgende Probleme können zu diesem Symptom führen: Link-Überlastung (normalerweise verbunden mit Ausgabeverwerfen) Fehlerhafte Leitung verursacht Wechsel von CDs Mögliches Hardwareproblem bei CSU, DSU oder Switch

Wenn die Schnittstellenwiederherstellung erfolgt, überprüfen Sie andere Felder der Ausgabe des seriellen Befehls show interfaces, um die Ursache des Problems zu ermitteln. Unter der Annahme, dass eine Erhöhung der Anzahl der Zurücksetzungen für Schnittstellen aufgezeichnet wird, überprüfen Sie die folgenden Felder: Wenn bei der seriellen Ausgabe der Schnittstellen eine hohe Anzahl von Ausgabeausfällen auftritt, lesen Sie den Abschnitt "Serielle Posten: Increasing Output Drops on Serial Link" (Steigerung der Ausgabe bei serieller Verbindung), weiter oben in diesem Kapitel. Überprüfen Sie das Feld Carrier Transition (Carrier Transition) in der seriellen Anzeige der Schnittstellen. Wenn bei der Registrierung der Schnittstellenwiederherstellung die Übergänge zwischen den Betreibern hoch sind, ist das Problem wahrscheinlich eine fehlerhafte Verbindung oder eine fehlerhafte CSU oder DSU. Wenden Sie sich an Ihren Mietleitungen- oder Carrier-Service, und tauschen Sie ggf. fehlerhafte Geräte aus. Überprüfen Sie das Feld Eingabefehler in der seriellen Anzeige der Schnittstellen. Wenn die Eingabefehler hoch sind und die Anzahl der Schnittstellenwiederherstellungen zunimmt, ist das Problem wahrscheinlich ein schlechter Link oder eine fehlerhafte CSU/DSU. Wenden Sie sich an Ihren Mietleitung oder einen anderen Carrier-Service, und tauschen Sie ggf. fehlerhafte Geräte aus.

Serielle Posten: Erhöhte Anzahl von Carrier-Übergängen durch serielle Verbindung

Carrier-Übergänge erscheinen in der Ausgabe des Befehls show interfaces Serial EXEC, wenn das Trägersignal unterbrochen wird (z. B. Zurücksetzen der Schnittstelle am Remote-Ende einer Verbindung).

Symptom: Immer mehr Carrier-Übergänge werden von seriellen Verbindungen erwartet.

In Tabelle 15-7 sind mögliche Probleme aufgeführt, die zu diesem Symptom führen können, und es werden Lösungsvorschläge unterbreitet.

Tabelle 15-7: Serielle Posten: Erhöhte Anzahl von Carrier-Übergängen durch serielle Verbindung

Mögliche Probleme	Lösung
Folgende Probleme können zu diesem Symptom führen: Leitungsunterbrechungen aufgrund einer externen Quelle (z. B. physische Trennung der Verkabelung, rote oder gelbe T1-Alarme oder Blitzschlag irgendwo im Netzwerk) Fehlerhafte Switch-, DSU- oder Router-Hardware	Überprüfen Sie die Hardware an beiden Enden des Links. Schließen Sie eine Breakout-Box oder einen seriellen Analyzer an, und testen Sie die Problemursache. Wenn ein Analyzer oder ein Breakout-Feld keine externen Probleme identifizieren kann, überprüfen Sie die Router-Hardware. Tauschen Sie fehlerhafte Geräte bei Bedarf aus.

Verwenden des Befehls show controller

Der Befehl show controller EXEC ist ein weiteres wichtiges Diagnosetool bei der Fehlerbehebung von seriellen Leitungen. Die Befehlssyntax variiert je nach Plattform:

• Für serielle Schnittstellen auf Cisco Routern der Serie 7000 verwenden Sie den Befehl show controller cbus EXEC.

• Verwenden Sie für Cisco Access-Produkte den Befehl show controller EXEC.

• Verwenden Sie für AGS, CGS und MGS den Befehl show controller mci EXEC.

Abbildung 15-2 zeigt die Ausgabe des Befehls show controller cbus EXEC. Dieser Befehl wird auf Cisco Routern der Serie 7000 mit der FSIP-Karte (Fast Serial Interface Processor) verwendet. Überprüfen Sie die Befehlsausgabe, um sicherzustellen, dass das Kabel zur Kanaldiensteinheit/digitalen Diensteinheit (CSU/DSU) an die richtige Schnittstelle angeschlossen ist. Sie können auch die Mikrocodeversion überprüfen, um festzustellen, ob sie aktuell ist.

Abbildung 15-2: show controller cbus Command-Ausgabe

Bei Zugriffsprodukten wie den Cisco Access Servern und Routern der Serien 2000, 2500, 3000 und 4000 verwenden Sie den Befehl show controller EXEC. Abbildung 15-3 zeigt die Ausgabe des Befehls show controller über die Basic Rate Interface (BRI) und die seriellen Schnittstellen eines Cisco 2503 Access Servers. (Beachten Sie, dass einige Ausgaben nicht angezeigt werden.)

Die Ausgabe der show controller gibt den Zustand der Schnittstellenkanäle und die Frage an, ob ein Kabel an die Schnittstelle angeschlossen ist. In Abbildung 15-3 ist an der seriellen Schnittstelle 0 ein RS-232 DTE-Kabel angeschlossen. Die serielle Schnittstelle 1 hat kein Kabel angeschlossen.

Abbildung 15-4 zeigt die Ausgabe des Befehls show controller mci. Dieser Befehl wird nur auf AGS-, CGS- und MGS-Routern verwendet. Wenn die elektrische Schnittstelle als UNKNOWN (anstelle von V.35, EIA/TIA-449 oder einem anderen elektrischen Schnittstellentyp) angezeigt wird, ist ein falsch angeschlossenes Kabel das wahrscheinliche Problem. Ein falsches Applique oder ein Problem mit der internen Verkabelung der Karte ist ebenfalls möglich. Wenn die elektrische Schnittstelle unbekannt ist, zeigt die entsprechende Anzeige für den Befehl show interfaces serial EXEC an, dass Schnittstelle und Leitungsprotokoll ausgefallen sind.

Abbildung 15-3: show controller Command-Ausgabe

Abbildung 15-4: show controller mci-Befehlsausgabe

Verwenden von Debugbefehlen

Die Ausgabe der verschiedenen debug privilegierten EXEC-Befehle liefert Diagnoseinformationen zum Protokollstatus und zur Netzwerkaktivität für viele Internetworking-Ereignisse.

Vorsicht: Da der Debugausgabe im CPU-Prozess eine hohe Priorität zugewiesen wird, kann das System unbrauchbar gemacht werden. Verwenden Sie deshalb nur Debug-Befehle, um spezifische Probleme zu beheben oder während Sitzungen zur Fehlerbehebung mit dem technischen Support von Cisco. Darüber hinaus empfiehlt es sich, Debug-Befehle in Zeiträumen zu verwenden, in denen der Netzwerkverkehr niedrig und die Anzahl der Benutzer reduziert ist. Das Debuggen während dieser Zeiträume verringert die Wahrscheinlichkeit, dass sich ein erhöhter Overhead bei der Debug-Befehlsverarbeitung auf die Systemnutzung auswirkt. Wenn Sie mit einem debug-Befehl fertig sind, sollten Sie ihn mit dem spezifischen Befehl no debug oder dem Befehl no debug all deaktivieren.

Die folgenden Debug-Befehle sind bei der Fehlerbehebung von seriellen und WAN-Problemen nützlich. Weitere Informationen zur Funktion und Ausgabe dieser Befehle finden Sie in der Veröffentlichung Debug Command Reference:

• debug Serial interface - Überprüft, ob HDLC-Keepalive-Pakete inkrementieren. Ist dies nicht der Fall, besteht ein potenzielles Zeitproblem auf der Schnittstellenkarte oder im Netzwerk.

• debug x25 events - Erkennt X.25-Ereignisse, z. B. das Öffnen und Schließen von SVCs (Switched Virtual Circuits). Die resultierenden "Ursache- und Diagnoseinformationen" sind im Ereignisbericht enthalten.

• debug lapb - Gibt Informationen zu Link Access Procedure, Balanced (LAPB) oder Level 2 X.25 aus.

• debug arp: Gibt an, ob der Router Informationen über Router (mit ARP-Paketen) auf der anderen Seite der WAN-Cloud sendet oder diese erkennt. Verwenden Sie diesen Befehl, wenn einige Knoten in einem TCP/IP-Netzwerk reagieren, andere jedoch nicht.

• debug frame-relais lmi - Ruft LMI-Informationen (Local Management Interface) ab, die nützlich sind, um festzustellen, ob ein Frame Relay-Switch und ein Router LMI-Pakete senden und empfangen.

• debug frame-Relay-Ereignisse - Bestimmt, ob zwischen einem Router und einem Frame-Relay-Switch ein Austausch stattfindet.

• debug ppp negotiation - Zeigt Point-to-Point Protocol (PPP)-Pakete an, die während des PPP-Starts übertragen werden und über die PPP-Optionen ausgehandelt werden.

• debug ppp packet - Zeigt die gesendeten und empfangenen PPP-Pakete an. Dieser Befehl zeigt Low-Level Packet Dumps an.

• debug ppp errors - Zeigt PPP-Fehler (z. B. illegale oder falsch formatierte Frames) an, die mit der Verhandlung und dem Vorgang der PPP-Verbindung verknüpft sind.

• debug ppp chap: Zeigt Paketaustausch zwischen PPP Challenge Handshake Authentication Protocol (CHAP) und Password Authentication Protocol (PAP) an.

• debug Serial Packet - Zeigt Switched Multimegabit Data Service (SMDS)-Pakete, die gesendet und empfangen werden. Diese Anzeige gibt auch Fehlermeldungen aus, um anzugeben, warum ein Paket nicht gesendet oder falsch empfangen wurde. Bei SMDS wird der gesamte SMDS-Header und einige Payload-Daten ausgelesen, wenn ein SMDS-Paket übertragen oder empfangen wird.

Verwenden erweiterter Ping-Tests

Der Ping-Befehl ist ein nützlicher Test, der auf Cisco Internetworking-Geräten sowie auf vielen Hostsystemen verfügbar ist. In TCP/IP wird dieses Diagnosetool auch als ICMP-Echo-Anforderung (Internet Control Message Protocol) bezeichnet.

Hinweis: Der Ping-Befehl ist besonders nützlich, wenn in der seriellen Anzeige der Schnittstellen hohe Eingabefehler registriert werden. Siehe Abbildung 15-1.

Cisco Internetworking-Geräte bieten einen Mechanismus zur Automatisierung des Sendens vieler Ping-Pakete in Folge. Abbildung 15-5 zeigt das Menü zum Angeben erweiterter Ping-Optionen. In diesem Beispiel werden 20 aufeinander folgende Pings angegeben. Beim Testen der Komponenten auf der seriellen Leitung sollten Sie jedoch eine deutlich größere Zahl angeben, z. B. 1000 Pings.

Abbildung 15-5: Erweitertes Ping-Spezifikationsmenü

Durchführen von Ping-Tests

Führen Sie die Ping-Tests für die serielle Leitung im Allgemeinen wie folgt aus:

1. Setzen Sie die CSU oder DSU in den lokalen Loopback-Modus.

2. Konfigurieren Sie den Befehl für das erweiterte Ping, um verschiedene Datenmuster und Paketgrößen zu senden. Abbildung 15-6 und Abbildung 15-7 veranschaulichen zwei nützliche Ping-Tests: ein All-Zeros-Ping (1500 Byte) und ein All-One-Ping (1500 Byte) Ping.

3. Überprüfen Sie die Ausgabe des Befehls show interfaces (siehe Abbildung 15-1), und stellen Sie fest, ob die Eingabefehler zugenommen haben. Wenn die Eingabefehler nicht erhöht wurden, befindet sich die lokale Hardware (DSU, Kabel, Router-Schnittstellenkarte) wahrscheinlich in gutem Zustand.

   Wenn man davon ausgeht, dass diese Testsequenz durch das Auftreten einer großen Anzahl von CRC- und Framing-Fehlern ausgelöst wurde, ist ein Taktproblem wahrscheinlich. Prüfen Sie die CSU oder DSU auf ein Timing-Problem. Weitere Informationen finden Sie im Abschnitt "Problembehandlung bei der Taktgebung" weiter unten in diesem Kapitel.

4. Wenn Sie feststellen, dass die Konfiguration der Taktgebung korrekt ist und ordnungsgemäß funktioniert, setzen Sie die CSU oder DSU in den Remote-Loopback-Modus.

5. Wiederholen Sie den Ping-Test, und suchen Sie nach Änderungen in den Eingabefehlerstatistiken.

6. Wenn die Eingabefehler zunehmen, liegt entweder ein Problem in der seriellen Leitung oder im CSU/DSU vor. Wenden Sie sich an den WAN-Dienstanbieter, und tauschen Sie die CSU oder die DSU aus. Wenn die Probleme weiterhin bestehen, wenden Sie sich an Ihren Mitarbeiter der technischen Unterstützung.

Abbildung 15-6: ALl-Zeros 1500-Byte-Ping-Test

Abbildung 15-7 All-One 1500-Byte-Ping-Test

Fehlerbehebung bei Problemen mit der Taktgebung

Die Blockierung von Konflikten bei seriellen Verbindungen kann zu einem chronischen Ausfall des Verbindungsservices oder zu Leistungseinbußen führen. In diesem Abschnitt werden die wichtigsten Aspekte der Überwachung von Problemen beschrieben: Probleme zu beobachten, Probleme zu erkennen, zu beobachten, Probleme zu isolieren und Problemlösungen zu beobachten.

Übersicht über die Taktgebung

Die CSU/DSU leitet die Datenuhr von den Daten ab, die sie durchlaufen. Um die Uhr wiederherzustellen, muss die CSU/DSU-Hardware mindestens einen 1-Bit-Wert pro 8 Bit durchlaufende Daten erhalten. Dies wird als Einheitsdichte bezeichnet. Durch die Aufrechterhaltung der Datendichte kann die Hardware die Datenuhr zuverlässig wiederherstellen.

Neuere T1-Implementierungen verwenden häufig das Extended Superframe Format (ESF)-Framing mit der B8ZS-Codierung (Binary Acht-Zero Substitution). B8ZS stellt ein Schema bereit, mit dem ein besonderer Code ersetzt wird, wenn acht aufeinander folgende Nullen über die serielle Verbindung gesendet werden. Dieser Code wird dann am Remote-Ende der Verbindung interpretiert. Diese Technik garantiert eine vom Datenstrom unabhängige Dichte.

Ältere T1-Implementierungen verwenden das D4-Frame-Format (SF) und die AMI-Codierung (Alternate Mark Inversion). AMI verwendet kein Codierungsschema wie B8ZS. Dadurch wird der Datentyp eingeschränkt, der übertragen werden kann, da die Dichte nicht unabhängig vom Datenstrom aufrechterhalten wird.

Ein weiteres wichtiges Element der seriellen Kommunikation ist die Terminalsteuerung für die Übertragung externer serieller Uhren (SCTE). Der SCTE ist die Uhr, die vom DTE-Gerät (z. B. einem Router) an das DCE-Gerät (z. B. das CSU/DSU) zurückgeleitet wird.

Wenn das DCE-Gerät SCTE anstelle der internen Uhr verwendet, um Daten von der DTE zu testen, ist es besser, die Daten fehlerfrei zu testen, selbst wenn das Kabel eine Phasenverschiebung zwischen der CSU/DSU und dem Router aufweist. Die Verwendung von SCTE wird für serielle Übertragungen mit einer Geschwindigkeit von mehr als 64 Kbit/s dringend empfohlen. Wenn Ihr CSU/DSU SCTE nicht unterstützt, lesen Sie den Abschnitt "Invertieren der Übertragungs-Uhr" weiter unten in diesem Kapitel.

Blockieren von Problemfällen

Im Allgemeinen können Taktierungsprobleme bei seriellen WAN-Verbindungen auf eine der folgenden Ursachen zurückgeführt werden:

• Falsche DSU-Konfiguration

• Falsche CSU-Konfiguration

• Kabel außerhalb der Spezifikationen, d. h. länger als 15,24 Meter oder ungeschirmt

• Geräusche oder schlechte Verbindungen an den Patchfeldern

• Mehrere aufeinander folgende Kabel

Erkennen von Taktungsproblemen

Um Taktungskonflikte auf einer seriellen Schnittstelle zu erkennen, achten Sie auf Eingabefehler:

1. Verwenden Sie den Befehl show interfaces serial EXEC auf den Routern an beiden Enden der Verbindung.

2. Untersuchen der Befehlsausgabe auf CRC, Framing-Fehler und Abbruch

3. Wenn einer dieser Schritte auf Fehler hinweist, die einen ungefähren Bereich von 0,5 Prozent des 2,0 Prozent des Datenverkehrs auf der Schnittstelle überschreiten, sind im WAN-Bereich vermutlich Probleme mit der Taktgebung aufgetreten.

4. Identifizieren Sie die Quelle der Taktungskonflikte, wie im folgenden Abschnitt "Isolieren von Taktproblemen" beschrieben.

5. Umgehen oder reparieren Sie fehlerhafte Patchfelder.

Isolierung von Taktungsproblemen

Nachdem Sie festgestellt haben, dass Taktungskonflikte die wahrscheinlichste Ursache für Eingabefehler sind, können Sie mithilfe der folgenden Prozedur die Ursache dieser Fehler ermitteln:

1. Führen Sie eine Reihe von Ping-Tests und Loopback-Tests (lokal und remote) durch, wie im Abschnitt "CSU und DSU Loopback Tests" weiter oben in diesem Kapitel beschrieben.

2. Bestimmen Sie das Ende der Verbindung, die die Ursache des Problems ist, oder ob das Problem in der Leitung liegt. Führen Sie im lokalen Loopback-Modus bei den Ping-Tests verschiedene Muster und Größen aus (z. B. 1500-Byte-Datagramme verwenden). Bei Verwendung eines einzigen Musters und einer Paketgröße treten möglicherweise keine Fehler auf, insbesondere dann nicht, wenn ein serielles Kabel an den Router oder eine CSU/DSU das Problem darstellt.

3. Verwenden Sie den Befehl show interfaces serial EXEC, um festzustellen, ob die Anzahl der Eingabefehler zunimmt und wo diese sich ansammeln.

Wenn sich an beiden Enden der Verbindung Eingabefehler anhäufen, ist die CU-Taktgebung das wahrscheinlichste Problem.

Wenn nur an einem Ende Eingabefehler auftreten, liegt möglicherweise ein Problem mit der DSU-Taktgebung oder der Verkabelung vor.

Aborts an einem Ende deuten darauf hin, dass das andere Ende schlechte Informationen sendet oder dass es ein Leitungsproblem gibt.

Hinweis: Verwenden Sie immer die Ausgabe des Befehls show interfaces serial (siehe Abbildung 15-1), und protokollieren Sie alle Änderungen bei den Fehlerzählungen, oder beachten Sie, dass sich die Fehleranzahl nicht ändert.

Problemlösungen blockieren

Tabelle 15-8 Serielle Leitungen: Probleme und Lösungen eingrenzen: Diese Tabelle enthält Vorschläge zur Behebung von Taktproblemen, die auf der Ursache des Problems basieren.

Mögliche Probleme	Lösung
Falsche CSU-Konfiguration	Stellen Sie fest, ob die CSUs an beiden Enden mit der Taktquelle (lokal oder Leitung) übereinstimmen. Wenn die CSUs nicht zustimmen, konfigurieren Sie sie so, dass sie dies tun. Normalerweise ist die Leitung die Quelle. Überprüfen Sie die LBO-Einstellung auf dem CSU, um sicherzustellen, dass die Impedanz mit der der physischen Leitung übereinstimmt. Informationen zur Konfiguration der CSU finden Sie in der Hardware-Dokumentation der CSU.
Falsche DSU-Konfiguration	Stellen Sie fest, ob der SCTE-Modus für die DSUs an beiden Enden aktiviert ist. Wenn SCTE an beiden Enden der Verbindung nicht aktiviert ist, aktivieren Sie es. Stellen Sie sicher, dass die Dichte der Telefone erhalten bleibt. Dies erfordert, dass die DSU die gleichen Rahmen- und Kodierungssysteme (z. B. ESF und B8ZS) verwendet, die auch von der Mietleitung oder anderen Betreiberdiensten verwendet werden. Informieren Sie sich bei Ihrem Mietleitungsanbieter über dessen Rahmen- und Kodierungssysteme. Wenn Ihr Carrier-Service AMI-Kodierung verwendet, invertieren Sie entweder die Übertragungs-Uhr auf beiden Seiten der Verbindung oder führen Sie die DSU im Bit-Zustand-Modus aus. Weitere Informationen zur Konfiguration der DSU finden Sie in der DSU-Hardwaredokumentation.
Kabel an Router ist nicht spezifiziert	Wenn das Kabel länger als 15,24 m ist, verwenden Sie ein kürzeres Kabel. Wenn das Kabel nicht abgeschirmt ist, ersetzen Sie es durch abgeschirmtes Kabel.

Umkehren der Übertragungs-Uhr

Wenn Sie versuchen, serielle Verbindungen mit einer Geschwindigkeit von mehr als 64 Kbit/s mit einer CSU/DSU, die SCTE nicht unterstützt, zu verwenden, müssen Sie möglicherweise die Übertragungs-Uhr auf dem Router invertieren. Durch die Umkehrung der Übertragungs-Uhr werden Phasenverschiebungen zwischen den Daten- und Uhrensignalen kompensiert.

Der spezifische Befehl zum Umkehren der Übertragungs-Uhr variiert von Plattform zu Plattform. Geben Sie auf einem Router der Cisco 7000-Serie den Befehl Schnittstellenkonfiguration für die Umkehrübertragungs-Übertragungs-Uhr ein. Für Cisco Router der Serie 4000 verwenden Sie den Schnittstellenkonfigurationsbefehl dte-invert-txc.

Um sicherzustellen, dass Sie die richtige Befehlssyntax für Ihren Router verwenden, lesen Sie das Benutzerhandbuch für Ihren Router oder Zugriffsserver sowie die Cisco IOS-Konfigurationsanleitungen und Befehlsreferenzen.

Hinweis: Bei älteren Plattformen kann es erforderlich sein, einen physikalischen Jumper zu verschieben, wenn Sie die Übertragungs-Uhr invertieren.

Anpassen von Puffern

Eine übermäßig hohe Bandbreitennutzung (über 70 Prozent) führt zu einer insgesamt niedrigeren Leistung und kann zeitweilige Ausfälle verursachen. Beispielsweise kann die DECnet-Dateiübertragung fehlschlagen, weil Pakete irgendwo im Netzwerk verworfen werden.

Wenn die Situation schlecht genug ist, müssen Sie die Bandbreite der Verbindung erhöhen. Eine Erhöhung der Bandbreite ist jedoch möglicherweise nicht notwendig oder sofort praktisch. Eine Möglichkeit, Probleme bei der Überlastung von seriellen Nebenstellen zu beheben, besteht darin, zu steuern, wie der Router Datenpuffer verwendet.

Vorsicht: Passen Sie im Allgemeinen keine Systempuffer an, es sei denn, Sie arbeiten eng mit einem Mitarbeiter des technischen Supports von Cisco zusammen. Wenn Sie die Systempuffer auf Ihrem Router falsch anpassen, können Sie die Leistung Ihrer Hardware und Ihres Netzwerks erheblich beeinträchtigen.

Verwenden Sie eine der folgenden drei Optionen, um die Verwendung von Puffern zu steuern:

• Anpassen von Parametern für Systempuffer

• Geben Sie die Anzahl der in Eingabe- oder Ausgabewarteschlangen gehaltenen Pakete an (Warteschlangen halten).

• Priorisierung der Warteschlangenverwaltung von Datenverkehr für die Übertragung (Priority Output Queuing)

Die diesen Optionen zugeordneten Konfigurationsbefehle werden in den Cisco IOS-Konfigurationsanleitungen und Befehlsreferenzen beschrieben.

Im folgenden Abschnitt werden Situationen beschrieben, in denen diese Optionen wahrscheinlich angewendet werden, und es wird erläutert, wie Sie diese Optionen verwenden können, um Verbindungs- und Leistungsprobleme bei seriellen/WAN-Verbindungen zu beheben.

Optimieren der System-Puffer

Auf Cisco Routern gibt es zwei allgemeine Puffertypen: Hardware-Puffer und Systempuffer. Nur die Systempuffer können von Systemadministratoren direkt konfiguriert werden. Die Hardware-Puffer werden speziell als Empfangs- und Übertragungspuffer für jede Schnittstelle verwendet und (bei Fehlen einer speziellen Konfiguration) dynamisch von der Systemsoftware selbst verwaltet.

Die Systempuffer sind dem Hauptspeicher des Systems zugeordnet und werden Speicherblöcken unterschiedlicher Größe zugewiesen. Ein nützlicher Befehl zur Bestimmung des Status Ihrer Systempuffer ist der Befehl show buffers EXEC. Abbildung 15-8 zeigt die Ausgabe des Befehls show buffers.

Abbildung 15-8: Ausgabe des Befehls "buffers"

In der Ausgabe show buffers:

• total: Gibt die Gesamtzahl der Puffer im Pool an, einschließlich verwendeter und nicht verwendeter Puffer.

• Permanent- Gibt die permanente Anzahl der zugewiesenen Puffer im Pool an. Diese Puffer befinden sich immer im Pool und lassen sich nicht abstellen.

• in der freien Liste - Gibt die Anzahl der Puffer an, die derzeit im Pool vorhanden sind.

• min: Gibt die Mindestanzahl an Puffern an, die der Routingprozessor (RP) in der freien Liste beibehalten soll:

  • Der min-Parameter dient dazu, die Nachfrage nach Puffern aus dem Pool jederzeit vorherzusehen.

  • Wenn die Anzahl der Puffer in der freien Liste unter den minimalen Wert fällt, versucht der RP, mehr Puffer für diesen Pool zu erstellen.

• max allowed - Gibt die in der freien Liste zulässige maximale Anzahl an Puffern an:

  • Der max allowed Parameter verhindert, dass ein Pool Puffer monopolisiert, die er nicht mehr benötigt, und gibt diesen Speicher für die weitere Verwendung zurück an das System.

  • Wenn die Anzahl der Puffer in der freien Liste den maximal zulässigen Wert überschreitet, sollte der RP versuchen, Puffer aus dem Pool zu entfernen.

• Hits: Gibt die Anzahl der vom Pool angeforderten Puffer an. Der Hits-Zähler bietet einen Mechanismus zur Bestimmung, welcher Pool die höchste Nachfrage nach Puffern erfüllen muss.

• Fehlzeiten: Gibt an, wie oft ein Puffer angefordert wurde und der RP erkannte, dass zusätzliche Puffer erforderlich waren. (Anders ausgedrückt: Die Anzahl der Puffer in der freien Liste ist unter min gefallen.) Der Fehlerkennungszähler stellt die Anzahl der Male dar, in denen der RP gezwungen wurde, zusätzliche Puffer zu erstellen.

• trims: Gibt die Anzahl der Puffer an, die der RP aus dem Pool entfernt hat, wenn die Anzahl der Puffer in der freien Liste die Anzahl der maximal zulässigen Puffer überschreitet.

• created: Gibt die Anzahl der im Pool erstellten Puffer an. Der RP erstellt Puffer, wenn die Nachfrage nach Puffern angestiegen ist, bis die Anzahl der Puffer in der freien Liste weniger als Min. Puffer beträgt und/oder ein Fehler auftritt, weil die Anzahl der Puffer in der freien Liste null beträgt.

• failure - Identifiziert die Anzahl der Fehler, die einem Anforderer einen Puffer zuweisen, auch nachdem versucht wurde, einen zusätzlichen Puffer zu erstellen. Die Anzahl der Ausfälle stellt die Anzahl der Pakete dar, die aufgrund von Pufferknappheit verworfen wurden.

• no memory (Kein Speicher) - Identifiziert die Anzahl der Ausfälle, die durch unzureichenden Speicher verursacht werden, um zusätzliche Puffer zu erstellen.

Die Befehlsausgabe des Befehls show buffers in Abbildung 15-8 zeigt hohe Zahlen in den Trims und erstellte Felder für große Puffer. Wenn Sie in diesen Feldern hohe Nummern erhalten, können Sie die Leistung Ihrer seriellen Verbindung erhöhen, indem Sie den maximalen freien Wert erhöhen, der für Ihre Systempuffer konfiguriert wurde. trims gibt die Anzahl der Puffer an, die der RP aus dem Pool entfernt hat, wenn die Anzahl der Puffer in der freien Liste die Anzahl der maximal zulässigen Puffer überschreitet.

Verwenden Sie den globalen Konfigurationsbefehl puffer max free number, um die Anzahl der freien Systempuffer zu erhöhen. Der Wert, den Sie konfigurieren, sollte ungefähr 150 Prozent der im gesamten Feld der Befehlsausgabe show buffers angegebenen Zahl betragen. Wiederholen Sie diesen Vorgang, bis die Ausgabe von show buffers keine Trims und erstellten Puffer mehr anzeigt.

Wenn die Befehlsausgabe show buffers eine große Anzahl von Fehlern im Feld kein Speicher (siehe die letzte Zeile der Ausgabe in Abbildung 15-8) anzeigt, müssen Sie die Auslastung der Systempuffer reduzieren oder die Menge des gemeinsam genutzten oder Hauptspeichers (physischer RAM) auf dem Router erhöhen. Wenden Sie sich an Ihren Mitarbeiter des technischen Supports.

Grenzwerte für Warteschlangen implementieren

Warteschlangen sind Puffer, die von jeder Router-Schnittstelle zum Speichern ausgehender oder eingehender Pakete verwendet werden. Erhöhen Sie mit dem Befehl hold-queue interface configuration die Anzahl der Datenpakete, die in die Warteschlange gestellt werden, bevor der Router Pakete verwirft. Erhöhen Sie diese Warteschlangen um kleine Erhöhungen (z. B. um 25 Prozent), bis die Ausgabe der Anzeigeschnittstellen nicht mehr verworfen wird. Der Grenzwert für die Warteschlangenwareneinstellung für die Ausgabe beträgt standardmäßig 100 Pakete.

Hinweis: Der Befehl hold-queue wird für prozessgesteuerte Pakete und regelmäßige vom Router generierte Updates verwendet.

Mit dem Befehl hold-queue können Sie verhindern, dass Pakete verworfen werden, und die Leistung der seriellen Verbindung unter den folgenden Bedingungen verbessern:

• Sie haben eine Anwendung, die Verwerfen nicht tolerieren kann, und das Protokoll kann längere Verzögerungen tolerieren. DECnet ist ein Beispiel für ein Protokoll, das beide Kriterien erfüllt. Der Nahverkehr (Local Area Transport, LAT) toleriert keine Verzögerungen.

• Die Schnittstelle ist sehr langsam. Die Bandbreite ist gering, oder die erwartete Auslastung wird die verfügbare Bandbreite sporadisch übersteigen.

Hinweis: Wenn Sie die für eine Ausgabewarteschlange angegebene Anzahl erhöhen, müssen Sie möglicherweise die Anzahl der Systempuffer erhöhen. Der verwendete Wert hängt von der Größe der Pakete ab, die dem für das Netzwerk erwarteten Datenverkehr zugeordnet sind.

Reduzierung von Engpässen durch Priority Queuing

Prioritätswarteschlange ist ein listenbasierter Steuerungsmechanismus, der die Priorisierung des Datenverkehrs auf Schnittstellenbasis ermöglicht. Die Prioritätswarteschlange umfasst zwei Schritte:

1. Erstellen Sie eine Prioritätsliste nach Protokolltyp und Prioritätsstufe.

2. Weisen Sie der Prioritätsliste eine bestimmte Schnittstelle zu.

In beiden Schritten werden Versionen des globalen Konfigurationsbefehls der Prioritätsliste verwendet. Darüber hinaus kann eine weitere Datenverkehrskontrolle durchgeführt werden, indem auf die globalen Konfigurationsbefehle der Zugriffslisten aus den Spezifikationen der Prioritätsliste verwiesen wird. Beispiele zum Definieren von Prioritätslisten und Details zur Befehlssyntax für Prioritätswarteschlangen finden Sie in den Cisco IOS-Konfigurationsanleitungen und Befehlsreferenzen.

Hinweis: Bei Prioritätswarteschlangen werden automatisch vier Warteschlangen unterschiedlicher Größe erstellt. Dadurch werden alle in der Konfiguration enthaltenen Spezifikationen für Warteschlangen außer Kraft gesetzt.

Verwenden Sie Prioritätswarteschlangen, um zu verhindern, dass Pakete verworfen werden, und um die Leistung der seriellen Verbindung unter den folgenden Bedingungen zu verbessern:

• Wenn die Schnittstelle langsam ist, werden verschiedene Datenverkehrstypen übertragen, und Sie möchten die Leistung des Terminalverkehrs verbessern.

• Wenn Sie eine serielle Verbindung verwenden, die häufig sehr stark belastet wird (z. B. zu bestimmten Zeiten Dateitransfers), können Sie mithilfe von Prioritätswarteschlangen auswählen, welche Arten von Datenverkehr in Zeiträumen mit hohem Datenverkehr verworfen werden sollen.

Im Allgemeinen beginnen Sie bei der Implementierung von Prioritätswarteschlangen mit der Standardanzahl der Warteschlangen. Nach der Aktivierung der Prioritätswarteschlange wird die Ausgabe des Monitors mit dem Befehl show interfaces serial EXEC verworfen. Wenn Sie bemerken, dass in der von Ihnen angegebenen Datenverkehrswarteschlange Ausgabeverluste mit hoher Priorität auftreten, erhöhen Sie die Anzahl der Pakete, die in die Warteschlange gestellt werden können (mithilfe der Schlüsselwortoption queue-limit des globalen Konfigurationsbefehls priority-list). Die Warteschlangenlimit-Standardargumente sind 20 Pakete für die Warteschlange mit hoher Priorität, 40 für den mittleren Bereich, 60 für den normalen Modus und 80 für den niedrigen Wert.

Hinweis: Beim Bridging von LAT-Datenverkehr der Digital Equipment Corporation (DEC) muss der Router nur sehr wenige Pakete verwerfen, oder LAT-Sitzungen können unerwartet enden. Eine Warteschlangentiefe mit hoher Priorität von ca. 100 (spezifiziert mit dem queue-limit-Schlüsselwort) ist ein typischer Arbeitswert, wenn der Router Ausgabepakete verwirft und die seriellen Leitungen einer Bandbreitennutzung von ca. 50 % unterzogen werden. Wenn der Router Pakete verwirft und zu 100 Prozent ausgelastet ist, benötigen Sie eine andere Leitung.

Ein weiteres Tool zur Reduzierung von Überlastungen beim Bridging einer DEC LAT ist die LAT-Komprimierung. Sie können die LAT-Komprimierung mithilfe des Befehls Schnittstellenkonfiguration Bridge-Group Lat-Komprimierung implementieren.

Serielle Sondertests

Zusätzlich zu den grundlegenden Diagnosefunktionen, die auf Routern verfügbar sind, können eine Reihe zusätzlicher Tools und Techniken eingesetzt werden, um die Bedingungen für Kabel, Switching-Geräte, Modems, Hosts und Remote-Hardware für das Internetworking zu bestimmen. Weitere Informationen finden Sie in der Dokumentation zu Ihrem CSU, DSU, seriellen Analysator oder anderen Geräten.

CSU- und DSU-Loopback-Tests

Wenn die Ausgabe des Befehls show interfaces serial EXEC anzeigt, dass die serielle Leitung aktiv ist, das Leitungsprotokoll jedoch nicht verfügbar ist, ermitteln Sie mithilfe der CSU/DSU-Loopback-Tests die Ursache des Problems. Führen Sie zuerst den Test der lokalen Schleife und dann den Remote-Test durch. Abbildung 15-9 zeigt die grundlegende Topologie der lokalen und Remote-Loopback-Tests von CSU/DSU.

Abbildung 15-9: Lokale und Remote-Loopback-Tests von CSU/DSU

Hinweis: Diese Tests sind allgemein gehalten und setzen voraus, dass das Internetworking-System an eine CSU oder DSU angebunden wird. Die Tests sind jedoch im Wesentlichen die gleichen für die Verbindung mit einem Multiplexer mit integrierter CSU/DSU-Funktion. Da es in X.25- oder Frame Relay Packet-Switched Network (PSN)-Umgebungen kein Loopback-Konzept gibt, gelten Loopback-Tests nicht für X.25- und Frame Relay-Netzwerke.

CSU- und DSU-Lokale Loopback-Tests für HDLC- oder PPP-Verbindungen

Im Folgenden finden Sie ein allgemeines Verfahren zum Durchführen von Loopback-Tests in Verbindung mit integrierten Systemdiagnosefunktionen:

1. Stellen Sie die CSU/DSU in den Modus für die lokale Schleife (weitere Informationen hierzu finden Sie in der Dokumentation Ihres Anbieters). Im Modus für die lokale Schleife wird die Verwendung der Uhr (vom T1-Dienst) beendet, und die DSU muss die lokale Uhr verwenden.

2. Mit dem Befehl show interfaces serial EXEC prüfen Sie, ob der Leitungsstatus von "line protocol is down" (Leitungsprotokoll ist aktiv (Schleife)) in "line protocol is up (Looped)" (Leitungsprotokoll ist aktiv) geändert wird oder ob er inaktiv bleibt.

3. Wenn das Leitungsprotokoll aktiviert wird, wenn sich die CSU oder DSU im lokalen Loopback-Modus befindet, deutet dies darauf hin, dass das Problem am Remote-Ende der seriellen Verbindung auftritt. Wenn die Statuszeile den Status nicht ändert, liegt ein mögliches Problem beim Router, dem Anschlusskabel oder der CSU/DSU vor.

4. Wenn das Problem lokal scheint, verwenden Sie den Befehl debug Serial interface privilegierter EXEC-Modus.

5. Nehmen Sie die CSU/DSU aus dem Modus für die lokale Schleife. Wenn das Zeilenprotokoll nicht verfügbar ist, gibt die Befehlsausgabe für die serielle Debugschnittstelle an, dass die Keepalive-Zähler nicht inkrementieren.

6. Setzen Sie die CSU/DSU wieder in den lokalen Loop-Modus. Dies sollte dazu führen, dass die Keepalive-Pakete inkrementell beginnen. Insbesondere die Werte für Minen und Ihre Keepalives erhöhen sich alle 10 Sekunden. Diese Informationen werden in der Ausgabe der seriellen Debugschnittstelle angezeigt.

   Wenn die Keepalives nicht inkrementiert werden, kann auf der Schnittstellenkarte oder im Netzwerk ein Timing-Problem auftreten. Informationen zur Behebung von Zeitgeberproblemen finden Sie im Abschnitt "Problembehebung bei Taktproblemen" weiter oben in diesem Kapitel.

   Wenn die Keepalives nicht inkrementiert werden, kann auf der Schnittstellenkarte oder im Netzwerk ein Timing-Problem auftreten. Informationen zur Behebung von Zeitgeberproblemen finden Sie im Abschnitt "Problembehebung bei Taktproblemen" weiter oben in diesem Kapitel.

7. Überprüfen Sie den lokalen Router, die CSU/DSU-Hardware und alle angeschlossenen Kabel. Vergewissern Sie sich, dass die Kabel die empfohlenen Längen einnehmen - nicht mehr als 15,24 Meter oder 7,62 Meter (7,62 Meter) für eine T1-Verbindung. Vergewissern Sie sich, dass die Kabel an die richtigen Anschlüsse angeschlossen sind. Tauschen Sie fehlerhafte Geräte bei Bedarf aus.

Abbildung 15-10 zeigt die Ausgabe des Befehls für die serielle Debug-Schnittstelle für eine serielle HDLC-Verbindung, wobei verpasste Keepalives dazu führen, dass die Leitung ausfällt und die Schnittstelle zurückgesetzt wird.

Abbildung 15-10: Befehlsausgabe der seriellen Schnittstelle debuggen

CSU und DSU Remote Loopback Tests für HDLC- oder PPP-Links

Wenn Sie feststellen, dass die lokale Hardware ordnungsgemäß funktioniert, Sie jedoch immer noch auf Probleme stoßen, wenn Sie versuchen, Verbindungen über die serielle Verbindung herzustellen, versuchen Sie, den Remote-Loopback-Test zu verwenden, um die Problemursache zu isolieren.

Hinweis: Bei diesem Remote-Loopback-Test wird davon ausgegangen, dass die HDLC-Kapselung verwendet wird und dass der vorherige Test der lokalen Schleife unmittelbar vor diesem Test durchgeführt wurde.

Die folgenden Schritte sind erforderlich, um Loopback-Tests durchzuführen:Die folgenden Schritte sind erforderlich, um Loopback-Tests durchzuführen:

1. Setzen Sie die Remote-CSU oder -DSU in den Remote-Loopback-Modus (siehe Herstellerdokumentation).

2. Stellen Sie mithilfe des Befehls show interfaces Serial EXEC fest, ob das Verbindungsprotokoll mit der Statuszeile "Serial x is up, line protocol is up (looped)" oder mit der Statuszeile, die angibt, dass das Verbindungsprotokoll ausgefallen ist, verfügbar bleibt.

3. Wenn das Leitungsprotokoll weiterhin aktiv ist (Schleife), liegt das Problem wahrscheinlich am Remote-Ende der seriellen Verbindung (zwischen dem Remote-CSU/DSU und dem Remote-Router). Führen Sie sowohl lokale als auch Remote-Tests am Remote-Ende durch, um die Problemquelle zu isolieren.

4. Wenn sich der Leitungsstatus bei Aktivierung des Remote-Loopback-Modus in "Line Protocol is down" (Leitungsprotokoll ist nicht verfügbar) ändert, stellen Sie sicher, dass die Dichte der Leitungen korrekt beibehalten wird. Die CSU/DSU muss so konfiguriert werden, dass die gleichen Framing- und Codierungssysteme verwendet werden, die auch von der Mietleitung oder anderen Betreiberdiensten (z. B. ESF und B8ZS) verwendet werden.

5. Wenn weiterhin Probleme auftreten, wenden Sie sich an Ihren WAN-Netzwerkmanager oder die WAN-Serviceorganisation.

Detaillierte Informationen über den Befehl show interfaces serial Command

In den folgenden Unterabschnitten werden die Parameter des Befehls show interfaces, die Syntaxbeschreibung, die Beispielausgabeanzeige und die Feldbeschreibungen erläutert.

Serielle Parameter anzeigen

Um Informationen über eine serielle Schnittstelle anzuzeigen, verwenden Sie den Befehl show interfaces Serial privilegierter EXEC-Modus:

show interfaces serial [number] [accounting]
show interfaces serial [number [:channel-group] [accounting] (Cisco 4000 series)
show interfaces serial [slot | port [:channel-group]] [accounting] (Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [serial] 
(ports on VIP cards in the Cisco 7500 series)
show interfaces serial [type slot | port-adapter | port] [:t1-channel] [accounting | crb]
(CT3IP in Cisco 7500 series)

Syntaxbeschreibung

• Nummer optional. Portnummer

• Accounting-Optional. Zeigt die Anzahl der Pakete jedes Protokolltyps an, die über die Schnittstelle gesendet wurden.

• :channel-group - Optional. Auf der Cisco Serie 4000 mit einem NPM oder einer Cisco Serie 7500 mit einem MIP gibt die T1-Channel-Gruppennummer im Bereich von 0 bis 23 an, die mit dem Konfigurationsbefehl für einen Channel-Controller definiert wird.

• Steckplatz: Informationen zu Steckplätzen finden Sie im entsprechenden Hardware-Handbuch.

• port: Informationen zu den Ports finden Sie im entsprechenden Hardware-Handbuch.

• port-adapter: Weitere Informationen zur Kompatibilität von Port-Adaptern finden Sie im entsprechenden Hardware-Handbuch.

• :t1-channel-Optional. Für das CT3IP ist der T1-Kanal eine Zahl zwischen 1 und 28.

• T1-Kanäle auf dem CT3IP sind 1 bis 28 nummeriert, nicht das herkömmlichere Zero-Based-Schema (0 bis 27), das mit anderen Cisco Produkten verwendet wird. Auf diese Weise wird die Konsistenz mit Telco-Nummerierungsschemata für T1-Kanäle innerhalb kanalisierter T3-Geräte sichergestellt.

• crb-Optional. Zeigt Informationen über Schnittstellenrouting und -Bridging an.

Befehlsmodus

Privilegierter EXEC

Nutzungsrichtlinien

Dieser Befehl wurde erstmals in Cisco IOS Release 10.0 für die Cisco Serie 4000 veröffentlicht. Sie wurde erstmals in Cisco IOS Release 11.0 für die Cisco 7000-Serie veröffentlicht und in Cisco IOS Release 11.3 geändert, um das CT3IP einzuschließen.

Beispielanzeigen

Nachfolgend finden Sie eine Beispielausgabe des Befehls show interfaces für eine synchrone serielle Schnittstelle:

Router# show interfaces serial
Serial 0 is up, line protocol is up
   Hardware is MCI Serial
   Internet address is 150.136.190.203, subnet mask is 255.255.255.0
   MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
   Encapsulation HDLC, loopback not set, keepalive set (10 sec)
   Last input 0:00:07, output 0:00:00, output hang never
   Output queue 0/40, 0 drops; input queue 0/75, 0 drops
   Five minute input rate 0 bits/sec, 0 packets/sec
   Five minute output rate 0 bits/sec, 0 packets/sec
       16263 packets input, 1347238 bytes, 0 no buffer
       Received 13983 broadcasts, 0 runts, 0 giants
       2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
1 carrier transitions 
     22146 packets output, 2383680 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts

Feldbeschreibung

Tabelle 15-9: Serielle Feldbeschreibungen für Schnittstellen anzeigen: In dieser Tabelle werden die in der Ausgabe aufgeführten Felder beschrieben.

Feld	Beschreibung
Seriell ...{up} | Nach unten}..ist administrativ deaktiviert	Gibt an, ob die Schnittstellenhardware derzeit aktiv ist (Carrier-Erkennung ist vorhanden) oder ob sie von einem Administrator deaktiviert wurde.
line protocol is {up | Down}	Gibt an, ob die Softwareprozesse, die das Verbindungsprotokoll behandeln, die Leitung für nutzbar halten (d. h. Keepalives sind erfolgreich) oder ob sie von einem Administrator deaktiviert wurde.
line protocol is {up | Down}	Gibt an, ob die Softwareprozesse, die das Verbindungsprotokoll behandeln, die Leitung für nutzbar halten (d. h. Keepalives sind erfolgreich) oder ob sie von einem Administrator deaktiviert wurde.
Hardware ist	Gibt den Hardwaretyp an.
Die Internetadresse ist	Gibt die Internetadresse und die Subnetzmaske an.
MTU	Maximale Übertragungseinheit der Schnittstelle.
BW	Gibt den Wert des für die Schnittstelle konfigurierten Bandbreitenparameters an (in Kilobit pro Sekunde). Der Parameter "bandwidth" wird nur zur Berechnung von IGRP-Metriken verwendet. Wenn die Schnittstelle an eine serielle Leitung mit einer Leitungsgeschwindigkeit angeschlossen ist, die nicht der Standardeinstellung entspricht (1536 oder 1544 für T1 und 56 für eine synchrone Standardserieleitung), geben Sie mithilfe des Befehls "Bandbreite" die richtige Leitungsgeschwindigkeit für diese serielle Leitung an.
KLEIN	Verzögerung der Schnittstelle in Mikrosekunden.
vertrauen	Die Zuverlässigkeit der Schnittstelle als Bruchteil von 255 (255/255 ist zu 100 Prozent zuverlässig), berechnet als exponentieller Durchschnitt über fünf Minuten.
Laden	Die Zuverlässigkeit der Schnittstelle als Bruchteil von 255 (255/255 ist zu 100 Prozent zuverlässig), berechnet als exponentieller Durchschnitt über fünf Minuten.
Kapselung	Die der Schnittstelle zugewiesene Kapselungsmethode.
Loopback	Gibt an, ob Loopback festgelegt ist.
Keepalive	Gibt an, ob Keepalives festgelegt wurden.
Letzte Eingabe	Anzahl der Stunden, Minuten und Sekunden seit dem erfolgreichen Empfang des letzten Pakets durch eine Schnittstelle. Hilfreich, um zu erfahren, wann eine Schnittstelle ausgefallen ist.
Letzte Ausgabe	Anzahl der Stunden, Minuten und Sekunden seit der erfolgreichen Übertragung des letzten Pakets über eine Schnittstelle.Anzahl der Stunden, Minuten und Sekunden seit der erfolgreichen Übertragung des letzten Pakets über eine Schnittstelle.
Ausgabedatei	Anzahl der Stunden, Minuten und Sekunden (oder nie) seit dem letzten Zurücksetzen der Schnittstelle aufgrund einer zu langen Übertragung. Wenn die Anzahl der Stunden in einem der letzten Felder 24 überschreitet, wird die Anzahl der Tage und Stunden gedruckt. Wenn dieses Feld überfließt, werden Sternchen gedruckt.
Ausgabewarteschlange, Ablegen der Eingangswarteschlange, Verwerfen	Anzahl der Pakete in den Ausgabe- und Eingangswarteschlangen Auf jede Nummer folgen ein Schrägstrich, die maximale Größe der Warteschlange und die Anzahl der Pakete, da die Warteschlange voll ist.
Ausgangsrate von 5 Minuten 5 Minuten	Durchschnittliche Anzahl von Bits und Paketen, die pro Sekunde in den letzten fünf Minuten übertragen wurden. Die Ein- und Ausgangsraten von fünf Minuten sollten nur als Annäherung des Datenverkehrs pro Sekunde während eines bestimmten Zeitraums von fünf Minuten verwendet werden. Diese Raten sind exponentiell gewichtete Durchschnittswerte mit einer Zeitkonstante von fünf Minuten. Ein Zeitraum von vier Zeitkonstanten muss überschritten werden, bevor der Durchschnitt innerhalb von 2 % der momentanen Rate eines einheitlichen Datenverkehrs in diesem Zeitraum liegt.
Paketeingang	Gesamtzahl fehlerfreier Pakete, die vom System empfangen wurden.
Byte	Gesamtanzahl der Bytes, einschließlich Daten- und MAC-Kapselung, in den fehlerfreien Paketen, die vom System empfangen werden.
kein Puffer	Anzahl der verworfenen empfangenen Pakete, da im Hauptsystem kein Pufferspeicher vorhanden war Vergleichen Sie die Anzahl ignorierter Wörter. Broadcast-Stürme in Ethernet-Netzwerken und Rauschspitzen auf seriellen Leitungen sind häufig für keine Eingabepufferereignisse verantwortlich.
Empfangen... Sendungen	Gesamtzahl der Broadcast- oder Multicast-Pakete, die von der Schnittstelle empfangen wurden
Risse	Anzahl der Pakete, die verworfen werden, weil sie kleiner als die minimale Paketgröße des Mediums sind.
Riesen	Anzahl der Pakete, die verworfen werden, weil sie die maximale Paketgröße des Mediums überschreiten.
Eingabefehler	Gesamtanzahl der Zähler ohne Puffer, Runts, Riants, CRCs, Frames, Overrun, ignoriert und Abort. Andere Fehler im Zusammenhang mit der Eingabe können den Zähler ebenfalls erhöhen, sodass diese Summe möglicherweise nicht mit den anderen Zählern ausgeglichen wird.
CRC	Die von der Ursprungsstation oder dem Gegenstelle generierte zyklische Redundanzprüfung stimmt nicht mit der aus den empfangenen Daten berechneten Prüfsumme überein. Auf einer seriellen Verbindung zeigen CRCs in der Regel Rauschen, Treffer oder andere Übertragungsprobleme an der Datenverbindung an.
Rahmen	Die Anzahl der falsch empfangenen Pakete mit einem CRC-Fehler und einer nicht ganzzahligen Oktettanzahl. Bei einer seriellen Leitung ist dies in der Regel auf Rauschen oder andere Übertragungsprobleme zurückzuführen.
überziehen	Anzahl der Male, die die Hardware des seriellen Empfängers die empfangenen Daten nicht an einen Hardware-Puffer übergeben konnte, da die Eingangsrate die Fähigkeit des Empfängers zur Verarbeitung der Daten übertraf.
ignoriert	Anzahl der empfangenen Pakete, die von der Schnittstelle ignoriert werden, da die Schnittstellenhardware bei internen Puffern niedrig ausgeführt wurde. Broadcast-Stürme und Rauschspitzen können dazu führen, dass die Anzahl der ignorierten Inhalte erhöht wird.
abbrechen	Illegale Abfolge von ein Bit auf einer seriellen Schnittstelle. Dies weist in der Regel auf ein Taktungsproblem zwischen der seriellen Schnittstelle und den Geräten der Datenverbindung hin.
Trägerwechsel	Anzahl der vom Carrier erkannten Signale, die an einer seriellen Schnittstelle gesendet werden, hat den Status geändert. Wenn beispielsweise Data Carrier Detection (DCD) ausfällt und aktiviert wird, erhöht sich der Carrier Transition Counter zweimal. Weist auf Modem- oder Leitungsprobleme hin, wenn die Leitung des Carriers den Status häufig ändert.
Paketausgabe	Gesamtzahl der Nachrichten, die vom System übertragen wurden
Byteausgabe	Gesamtzahl der Bytes, einschließlich Daten- und MAC-Kapselung, die vom System übertragen werden.
Untergrenze	Anzahl der Male, die der Sender schneller ausgeführt hat, als der Router verarbeiten kann. Dies wird auf einigen Schnittstellen möglicherweise nie gemeldet.
Ausgabefehler	Summe aller Fehler, die die endgültige Übertragung von Datagrammen aus der zu untersuchenden Schnittstelle verhindert haben. Beachten Sie, dass dies möglicherweise nicht mit der Summe der aufgelisteten Ausgabefehler ausgeglichen wird, da einige Datagramme mehr als einen Fehler aufweisen können und andere Fehler aufweisen können, die nicht in eine der speziell tabellarisch dargestellten Kategorien fallen.
Kollisionen	Anzahl der Nachrichten, die aufgrund einer Ethernet-Kollision erneut übertragen wurden Dies ist in der Regel das Ergebnis eines übererweiterten LAN (d. h. ein zu langes Ethernet- oder Transceiver-Kabel, mehr als zwei Repeater zwischen den Stationen oder zu viele kaskadierte Multiport-Transceiver). Einige Kollisionen sind normal. Wenn Ihre Kollisionsrate jedoch auf etwa 4 oder 5 Prozent ansteigt, sollten Sie prüfen, ob das Segment über keine fehlerhaften Geräte verfügt und/oder einige vorhandene Stationen in ein neues Segment verlagern. Ein Paket, das kollidiert, wird nur einmal in Ausgabepaketen gezählt.
Schnittstellenrücksetzer	Anzahl der vollständigen Zurücksetzung einer Schnittstelle. Dies kann vorkommen, wenn Pakete, die zur Übertragung in die Warteschlange gestellt wurden, nicht innerhalb von mehreren Sekunden gesendet wurden. Bei einer seriellen Leitung kann dies durch ein defektes Modem verursacht werden, das das Übertragungszeitsignal nicht liefert, oder durch ein Kabelproblem. Wenn das System feststellt, dass die Carrier-Erkennungszeile einer seriellen Schnittstelle aktiv ist, das Leitungsprotokoll jedoch nicht verfügbar ist, setzt es die Schnittstelle regelmäßig zurück, um sie neu zu starten. Schnittstellenrückstellungen können auch auftreten, wenn eine Schnittstelle ein Loopback zurückgibt oder heruntergefahren wird.
Neustart	Anzahl der Neustarts des Controllers aufgrund von Fehlern
Warnmeldungen, Remote-Alarme, rx LOF, rx LOS	Anzahl der CSU/DSU-Alarme und Anzahl der Vorkommen von Bildverlusten und Signalverlust beim Empfang.
BER inaktiv, NELR inaktiv, FELR inaktiv	Status der G.703-E1-Zähler für Bitfehlerrate (BER)-Alarm, Near-End Loop Remote (NELR) und Remote-Loop-Remote (FELR). Beachten Sie, dass Sie den NELR oder FELR nicht festlegen können.

Fehlerbehebung T1

In diesem Abschnitt werden die Techniken und Verfahren zur Fehlerbehebung bei T1-Schaltungen für Einwahlkunden beschrieben.

Fehlerbehebung mit dem Befehl show controller t1

Dieser Befehl zeigt den Controller-Status an, der für die Controller-Hardware spezifisch ist. Die angezeigten Informationen sind im Allgemeinen nur für Diagnoseaufgaben nützlich, die von Mitarbeitern des technischen Supports durchgeführt werden.

Der NMP (Network Management Processor) oder MIP (MultiChannel Interface Processor) kann die Port-Adapter abfragen, um ihren aktuellen Status zu bestimmen. Geben Sie einen Befehl show controller t1 ein, um Statistiken zur T1-Verbindung anzuzeigen.

Wenn Sie einen Steckplatz und eine Anschlussnummer angeben, werden Statistiken für jeden Zeitraum von 15 Minuten angezeigt. Der Befehl show controller t1 EXEC enthält Informationen zur logischen Fehlerbehebung bei Problemen mit der physischen Ebene und der Sicherungsschicht. In diesem Abschnitt wird beschrieben, wie Sie mit dem Befehl show controller t1 eine logische Fehlerbehebung durchführen.

Die meisten T1-Fehler werden durch falsch konfigurierte Leitungen verursacht. Stellen Sie sicher, dass die Konfiguration von Verkabelung, Framing und Uhrenquelle entsprechend den Empfehlungen des Service Providers erfolgt.

Show Controller t1 Bedingungen

Der T1-Controller kann sich in einem der folgenden drei Zustände befinden.

• Administrationseinstellung

• Nach unten

• Nach oben

Ist der T1-Controller administrativ ausgefallen?

Der Controller wurde vom Administrator deaktiviert, wenn er manuell heruntergefahren wurde. Sie sollten den Controller neu starten, um diesen Fehler zu beheben.

1. Aktivieren Sie den Modus.

   maui-nas-03>en
   Password: 
   maui-nas-03#

2. Wechseln in den globalen Konfigurationsmodus

   maui-nas-03#configure terminal
   Enter configuration commands, one per line. End with CNTL/Z.
   maui-nas-03(config)#

3. Rufen Sie den Controller-Konfigurationsmodus auf.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#

4. Starten Sie den Controller neu.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

Ist die Leitung besetzt?

Wenn der T1-Controller und die Leitung nicht aktiv sind, überprüfen Sie, ob eine der folgenden Meldungen in der Ausgabe show controller t1 EXEC angezeigt wird:

• Empfänger hat Frame-Verlust

• Signalverlust beim Empfänger

Wenn T1-Empfänger Frame-Verlust hat:

Gehen Sie folgendermaßen vor, wenn der T1-Receiver Frame-Verlust aufweist:

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Sie können das Framing-Format des Controllers in der aktuellen Konfiguration oder in der Ausgabe des Befehls show controller t1 überprüfen.

   Um das Framing-Format zu ändern, verwenden Sie das Framing {SF | ESF}-Befehl im Controller-Konfigurationsmodus wie unten gezeigt:

   maui-nas-03#configure terminal
   

   Geben Sie die Konfigurationsbefehle ein (eine pro Zeile). Beenden Sie mit CNTL/Z.

   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#framing esf
   

2. Testen Sie das andere Frame-Format, um zu sehen, ob der Alarm gelöscht wird.

3. Ändern Sie die Einstellung für das Zeilenaufbau mithilfe der Kabellänge {long | short}-Befehl.

Line Build Out (LBO) kompensiert den Verlust in Dezibel, basierend auf der Entfernung vom Gerät zum ersten Repeater im Schaltkreis. Für eine größere Entfernung vom Gerät zum Repeater muss die Signalstärke des Schaltkreises erhöht werden, um Verluste über diesen Abstand auszugleichen.

Weitere Informationen zu Buildeinstellungen erhalten Sie bei Ihrem Dienstanbieter und in der Cisco IOSreffzeile für Befehlsreferenzen.

Wenn das Problem dadurch nicht behoben wird, fahren Sie unten mit dem Abschnitt "If T1 Receiver Has Loss of Signal" (Wenn T1-Empfänger Signalverlust hat) fort.

Wenn der T1-Empfänger einen Signalverlust aufweist:

Gehen Sie folgendermaßen vor, wenn der T1-Empfänger ein Signal-Verlust hat:

1. Stellen Sie sicher, dass das Kabel zwischen dem Schnittstellenanschluss und dem Gerät des T1-Dienstanbieters (oder T1-Endgerät) richtig angeschlossen ist. Überprüfen Sie, ob das Kabel an die richtigen Ports angeschlossen ist. Korrigieren Sie ggf. die Kabelverbindungen.

2. Überprüfen Sie die Kabelintegrität. Suchen Sie im Kabel nach Pausen oder anderen physischen Abweichungen. Stellen Sie sicher, dass die Pinbelegung korrekt eingestellt ist. Tauschen Sie das Kabel bei Bedarf aus.

3. Überprüfen Sie die Kabelanschlüsse. Eine Umkehr der Sende- und Empfangspaare oder ein offenes Empfangspaar können Fehler verursachen. Legen Sie für das Empfangspaar die Zeilen 1 und 2 fest. Legen Sie für das Transmit-Paar die Leitungen 4 und 5 fest.

   Die Pins an einer RJ-45-Buchse sind von 1 bis 8 nummeriert. Pin 1 ist der linke Stift, wenn man die Buchse mit den Metallstiften betrachtet, die zu Ihnen gerichtet sind. Die folgende Abbildung zeigt:

   Abbildung 15-10: RJ-45-Kabel

   

4. Verwenden Sie ein Rollover-Kabel.

Führen Sie nach jedem Schritt den Befehl show controller t1 EXEC aus, um zu überprüfen, ob der Controller Fehler aufweist.

Überprüfen Sie, ob sich die Leitung in der Ausgabe show controller t1 im Loopback-Modus befindet. Eine Leitung sollte sich nur zu Testzwecken im Loopback-Modus befinden.

Verwenden Sie zum Deaktivieren des Loopbacks den Befehl no loopback im Controller-Konfigurationsmodus, wie unten gezeigt:

maui-nas-03(config-controlle)#no loopback

Wenn der Controller Alarme anzeigt:

Überprüfen Sie die Ausgabe des Befehls show controller, um festzustellen, ob vom Controller Alarme angezeigt werden.

Wir werden nun über verschiedene Alarme und das Verfahren sprechen, das erforderlich ist, um sie zu korrigieren.

Empfang (RX) Alarm Indication Signal (AIS) (Blau):

Ein empfangenes Alarm Indication Signal (AIS) bedeutet, dass ein Alarm auf der Leitung auftritt, die sich vor dem Gerät befindet, das mit dem Port verbunden ist.

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Wenn nicht, ändern Sie das Frame-Format auf dem Controller so, dass es mit dem Format der Leitung übereinstimmt.

2. Wenden Sie sich an Ihren Service Provider, um eine fehlerhafte Konfiguration im Telco zu überprüfen.

Remote Alarm Indication (RAI) Receive (RX) (Gelb):

Ein empfangener RAI bedeutet, dass die Gegenstelle ein Problem mit dem Signal hat, das sie von ihren Upstream-Geräten erhält.

1. Schließen Sie ein externes Loopback-Kabel an den Port an. Informationen zum Erstellen eines Loopback-PlugIns finden Sie im Abschnitt "Erstellen eines Loopback-Plug-Ins" weiter unten im Kapitel "".

2. Überprüfen Sie, ob Alarme vorliegen. Wenn Sie keine Alarme sehen, ist die lokale Hardware wahrscheinlich in gutem Zustand. In diesem Fall

   1. Überprüfen Sie die Verkabelung. Weitere Informationen finden Sie im Abschnitt "Wenn der T1-Empfänger einen Signalverlust hat".

   2. Überprüfen Sie die Einstellungen am Remote-Ende, und stellen Sie sicher, dass sie mit den Porteinstellungen übereinstimmen.

   3. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Dienstanbieter.

3. Entfernen Sie den Loopback-Stecker, und schließen Sie die T1-Leitung wieder an.

4. Überprüfen Sie die Verkabelung. Weitere Informationen finden Sie im Abschnitt "Wenn der T1-Empfänger einen Signalverlust hat".

5. Schalten Sie den Router aus und wieder ein.

6. Verbinden Sie die T1-Leitung mit einem anderen Port. Konfigurieren Sie den Port mit den gleichen Einstellungen wie die Leitung. Wenn das Problem nicht weiter besteht, liegt der Fehler beim einen Port:

   1. Schließen Sie die T1-Leitung wieder an den ursprünglichen Port an.

   2. Fahren Sie mit dem Abschnitt "Problembehandlung bei T1-Fehlerereignissen" fort.

      Wenn das Problem weiterhin besteht, gehen Sie wie folgt vor:

7. Führen Sie einen Hardware-Schleifentest durch, wie im Abschnitt "Durchführen des Hardware-Loopback-Plug-Tests" beschrieben.

8. Ersetzen Sie die T1-Controllerkarte.

9. Fahren Sie mit dem Abschnitt "Problembehandlung bei T1-Fehlerereignissen" fort.

Transmitter sendet Remote-Alarm (rot):

Ein Roter Alarm wird deklariert, wenn der CSU nicht mit dem Framinguster auf der T1-Leitung synchronisiert werden kann.

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Wenn Sie das Frame-Format auf dem Controller nicht ändern, um es mit dem Format der Leitung abzustimmen.

2. Überprüfen Sie die Einstellungen am Remote-Ende, und stellen Sie sicher, dass sie mit den Porteinstellungen übereinstimmen.

3. Wenden Sie sich an Ihren Dienstanbieter.

Transmit(TX) Remote Alarm Indication (RAI) (Gelb):

Ein an der Schnittstelle übertragenes RAI weist darauf hin, dass die Schnittstelle ein Problem mit dem Signal hat, das sie von den Gegenstücken empfängt.

1. Überprüfen Sie die Einstellungen am Remote-Ende, und stellen Sie sicher, dass sie mit den Porteinstellungen übereinstimmen.

2. Ein RAI für Übertragungen sollte mit einem anderen Alarm versehen sein, der auf das Problem hinweist, das der T1-Port/die T1-Karte mit dem Signal der Gegenstelle hat.

Führen Sie eine Fehlerbehebung für diese Bedingung durch, um die RAI für die Übertragung zu beheben.

Transmit(Tx) AIS (Blau):

Führen Sie die unten aufgeführten Schritte aus, um Transmit (Tx) AIS (Blau) zu korrigieren.

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Ist dies nicht der Fall, korrigieren Sie die Nichtübereinstimmung.

2. Schalten Sie den Router aus und wieder ein.

3. Verbinden Sie die T1-Leitung mit einem anderen Port. Konfigurieren Sie den Port mit den gleichen Einstellungen wie die Leitung.

4. Führen Sie einen Hardware-Schleifentest durch, wie im Abschnitt "Durchführen des Hardware-Loopback-Plug-Tests" beschrieben.

5. Ersetzen Sie die T1-Controllerkarte.

6. Fahren Sie mit dem Abschnitt "Problembehandlung bei T1-Fehlerereignissen" fort.

Fehlerbehebung bei T1-Fehlerereignissen

Der Befehl show controller t1 EXEC enthält Fehlermeldungen, die zur Fehlerbehebung verwendet werden können. Wir werden nun mehrere Fehlermeldungen und die Behebung der Fehler besprechen.

Um festzustellen, ob die Fehlerzähler ansteigen, führen Sie den Befehl show controller t1 wiederholt aus. Beachten Sie die Werte der Zähler für das aktuelle Intervall.

Fragen Sie Ihren Service Provider nach Framing- und Linked-Einstellungen. Eine gute Faustregel ist die Verwendung von B8ZS-Linecding mit ESF-Framing und AMI-Linecding mit SF-Framing.

Der Zähler für Slip Secs nimmt zu:

Das Vorhandensein von Schlupfen auf einer T1-Leitung weist auf ein Taktproblem hin. Der T1-Anbieter (Telco) stellt die Uhr bereit, mit der die Ausrüstung am Kundenstandort (Customer Premises Equipment, CPE) synchronisiert werden soll.

1. Überprüfen Sie, ob die Taktquelle vom Netzwerk abgeleitet ist. Dies kann durch die Suche nach Clock Source is Line Primary (Quelle für Leitung Primär) ermittelt werden.

   Hinweis: Wenn ein Zugriffsserver mehrere T1-Geräte umfasst, kann nur einer der primären Geräte sein, während die anderen T1-Geräte die Uhr vom primären Server ableiten. Überprüfen Sie in diesem Fall, ob die T1-Leitung als primäre Taktquelle konfiguriert wurde.

2. Stellen Sie die T1-Taktquelle im Controller-Konfigurationsmodus richtig ein.

   maui-nas-03(config-controlle)#clock source line primary
   

Zähler für Framing-Verlustsekunden steigt:

Führen Sie diese Schritte aus, wenn der Zähler für die Framing-Verlustsekunden größer wird.

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Sie können dies überprüfen, indem Sie den Framing {ESF|SF} in der Ausgabe des Show-Controllers t1 suchen.

2. Um das Framing-Format zu ändern, verwenden Sie das Framing {SF | ESF}-Befehl im Controller-Konfigurationsmodus wie unten gezeigt:

   maui-nas-03(config-controlle)#framing esf
   

3. Ändern Sie die Zeilenausführung mithilfe der Kabellänge {long | short}-Befehl.

Weitere Informationen zu Buildeinstellungen erhalten Sie bei Ihrem Dienstanbieter und in der Cisco IOSreffzeile für Befehlsreferenzen.

Verstöße gegen den Leitungscode nehmen zu:

Führen Sie diese Schritte aus, wenn die Anzahl der Verstöße gegen den Leitungscode zunimmt.

1. Überprüfen Sie, ob die auf dem Port konfigurierte Verkabelung mit dem Frame-Format der Leitung übereinstimmt. Sie können dies überprüfen, indem Sie in der Ausgabe des Anzeigecontrollers t1 nach {B8ZS|AMI} suchen.

2. Verwenden Sie den Linecode {ami, um das Linecode zu ändern. | b8zs}-Befehl im Controller-Konfigurationsmodus wie unten gezeigt:

   maui-nas-03(config-controlle)#linecode b8zs
   

3. Ändern Sie die Zeilenausführung mithilfe der Kabellänge {long | short}-Befehl.

Weitere Informationen zu Buildeinstellungen erhalten Sie von Ihrem Service Provider und in der Cisco IOS®-Befehlsreferenz.

Überprüfen der korrekten Konfiguration des ISDN-Switch-Typs und der PRI-Gruppe

Mit dem Befehl show running-config können Sie überprüfen, ob der ISDN-Switch-Typ und die Timeslots der PRI-Gruppe korrekt konfiguriert sind. Wenden Sie sich an Ihren Dienstanbieter, um korrekte Werte zu erhalten.

So ändern Sie den ISDN-Switch-Typ und die PRI-Gruppe:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-5ess
maui-nas-03(config)#controller t1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-24

Überprüfen des Signalisierungskanals

Wenn die Fehlerzähler nicht ansteigen, das Problem jedoch weiterhin besteht, stellen Sie sicher, dass der Signalisierungskanal korrekt eingerichtet und konfiguriert ist.

1. Führen Sie den Befehl show interface serial x:23 aus, wobei x durch die Schnittstellennummer ersetzt werden sollte.

2. Überprüfen Sie, ob die Schnittstelle aktiv ist. Wenn die Schnittstelle nicht aktiv ist, können Sie die Schnittstelle mit dem Befehl no shutdown aktivieren.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

3. Stellen Sie sicher, dass die Kapselung PPP ist. Wenn die Schnittstelle PPP nicht verwendet, verwenden Sie den Befehl encapsulation ppp im Schnittstellenkonfigurationsmodus, um dies zu korrigieren.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Überprüfen Sie, ob Loopback eingestellt ist. Loopback sollte nur zu Testzwecken eingestellt werden. Verwenden Sie den Befehl no loopback, um Loopbacks zu entfernen.

   maui-nas-03(config-if)#no loopback
   

5. Schalten Sie den Router aus und wieder ein.

6. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Service Provider oder das Cisco TAC

Fehlerbehebung bei PRI

Bei jeder Fehlerbehebung bei einem PRI müssen Sie überprüfen, ob das T1 auf beiden Seiten ordnungsgemäß ausgeführt wird. Wenn Layer-1-Probleme wie oben beschrieben behoben wurden, sollten Sie Layer-2- und Layer-3-Probleme berücksichtigen.

Fehlerbehebung Verwenden des Befehls show isdn status

Der Befehl show isdn status wird verwendet, um einen Snapshot aller ISDN-Schnittstellen anzuzeigen. Es zeigt den Status der Layer 1, 2 und 3 an.

1. Überprüfen Sie, ob Layer 1 aktiv ist.

   Der Layer-1-Status sollte immer ACTIVE (aktiv) heißen, es sei denn, der T1-Status ist ausgefallen. Wenn der SIDN-Status anzeigt, dass Layer 1 DEAKTIVIERT ist, besteht ein Problem mit der physischen Verbindung auf der T1-Leitung. Siehe Abschnitt "Ist der T1-Controller T1 ausgefallen?"

   Überprüfen Sie außerdem, ob die T1 vom Administrator deaktiviert wurde. Verwenden Sie den Befehl no shutdown, um den T1-Controller hochzufahren.

2. Überprüfen Sie, ob der Layer-2-Status "MULTIPLE_FRAME_ESTABLISHED" lautet.

Der gewünschte Layer-2-Status ist Multiple_Frame_Established. Dies bedeutet, dass wir Layer-2-Frames austauschen und die Layer-2-Initialisierung abgeschlossen haben.

Wenn Layer 2 nicht Multiple_Frame_Established ist, können Sie das Problem mit dem Befehl show controller t1 EXEC diagnostizieren. In diesem Kapitel finden Sie Informationen im Abschnitt Fehlerbehebung mit dem Befehl show controller t1 Command.

Da der "show isdn"-Status ein Snapshot des aktuellen Status ist, kann es passieren, dass Layer 2 trotz der Angabe von "Mulitple_Frame_Established" auf- und abspringt. Verwenden Sie debug isdn q921, um zu überprüfen, ob Layer 2 stabil ist.

Der Befehl debug isdn q921 zeigt die Zugriffsverfahren für die Sicherungsschicht (Layer 2) an, die auf dem Router auf dem D-Kanal ausgeführt werden.

Stellen Sie sicher, dass Sie so konfiguriert sind, dass Sie Debugmeldungen mithilfe des Befehls Protokollierungskonsole oder Terminalmonitor anzeigen können.

Hinweis: Überprüfen Sie in einer Produktionsumgebung, ob die Konsolenprotokollierung deaktiviert ist. Geben Sie den Befehl show logging ein. Wenn die Protokollierung aktiviert ist, kann es vorkommen, dass der Zugriffsserver periodisch abstürzt, sobald der Konsolenport mit Protokollmeldungen überlastet wird. Geben Sie den Befehl no logging console ein.

Hinweis: Wenn debug isdn q921 aktiviert ist und Sie keine Debug-Ausgaben erhalten, tätigen Sie einen Aufruf oder setzen Sie den Controller zurück, um Debug-Ausgaben zu erhalten.

1. Stellen Sie sicher, dass Layer 2 stabil ist.

   Sie sollten die Debug-Ausgaben für Meldungen beobachten, die darauf hinweisen, dass der Dienst nicht nach oben oder unten bounce. Wenn Sie die folgenden Typen von Debug-Ausgaben sehen, ist die Zeile nicht stabil.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:23, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:23, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:23, TEI 0 changed 
   to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller T1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:23, changed state to up
   
   

   Wenn Layer 2 nicht stabil erscheint, siehe "Problembehandlung bei T1-Fehlerereignissen" weiter oben in diesem Kapitel.

2. Stellen Sie sicher, dass Sie nur SAPI-Nachrichten auf beiden Seiten Transmit (TX) und Receive (RX) sehen.

   Mar 20 10:06:52.505: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:23: TX ->  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRp sapi = 0  tei = 0 nr = 0 
   Mar 20 10:07:22.509: ISDN Se0:23: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:23: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Vergewissern Sie sich, dass keine SABME-Meldungen angezeigt werden, was darauf hinweist, dass Layer 2 versucht, die Initialisierung durchzuführen. Dies ist in der Regel der Fall, wenn wir Umfrageanfragen (Polll Requests, RRp) übertragen und keine Antwort vom Switch (RRf) oder umgekehrt erhalten. Nachfolgend finden Sie ein Beispiel für SABME-Nachrichten.

   Mar 20 10:06:21.702: ISDN Se0:23: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:23: TX ->  SABMEp sapi = 0  tei = 0

   Wenn Sie SABME-Meldungen sehen, verwenden Sie den Befehl show running-config, um festzustellen, ob der ISDN-Switch-Typ und die Timeslots der PRI-Gruppe korrekt konfiguriert sind. Wenden Sie sich an Ihren Dienstanbieter, um korrekte Werte zu erhalten.

   So ändern Sie den ISDN-Switch-Typ und die PRI-Gruppe:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-5ess
   maui-nas-03(config)#controller t1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-24
   

4. Stellen Sie sicher, dass der D-Kanal mit dem Befehl show interfaces serial x:23 eingeschaltet ist.

   Wenn der D-Kanal nicht aktiv ist, führen Sie den Befehl no shutdown aus:

   maui-nas-03(config)#interface serial 0:23
   maui-nas-03(config-if)#no shutdown
   

5. Überprüfen Sie, ob Kapselung PPP ist. Wenn nicht, verwenden Sie den Befehl encapsulation ppp, um die Kapselung festzulegen.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Überprüfen Sie, ob sich die Schnittstelle im Loopback-Modus befindet. Im Normalbetrieb sollte sich die Schnittstelle nicht im Loopback-Modus befinden.

   maui-nas-03(config-if)#no loopback
   

7. Schalten Sie den Router aus und wieder ein.

8. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Service Provider oder das Cisco TAC.

Durchführen des Hardware-Loopback-Plug-Tests

Der Hardware-Loopback-Stecker-Test kann verwendet werden, um zu testen, ob der Router Fehler aufweist. Wenn ein Router einen Hardware-Loopback-Steckertest besteht, liegt das Problem an einer anderen Stelle der Leitung vor.

Loopback-Plug erstellen:

Gehen Sie folgendermaßen vor, um einen Loopback-Stecker zu erstellen.

1. Verwenden Sie Drahtzange, um ein funktionierendes RJ-45- oder RJ-48-Kabel so zu schneiden, dass es 15 Zoll Kabel gibt und der Anschluss daran angeschlossen ist.

2. Ziehen Sie die Kabel ab.

3. Ziehen Sie die Drähte aus den Pins 1 und 4 zusammen.

4. Ziehen Sie die Drähte aus den Pins 2 und 5 zusammen.

Die Pins an einer RJ-45/48-Buchse sind von 1 bis 8 nummeriert. Pin 1 ist der am weitesten links liegende Pin, wenn Sie die Buchse mit den Metallstiften betrachten, die zu Ihnen gerichtet sind.

Durchführen des Loopback-Plug-Tests

Führen Sie die folgenden Schritte aus, um den Loopback-Plug-Test durchzuführen.

1. Stecken Sie den Stecker in den betreffenden T1-Port.

2. Speichern Sie die Router-Konfiguration mit dem Befehl write memory (Arbeitsspeicher schreiben).

   maui-nas-03#write memory
   Building configuration...
   [OK]

3. Stellen Sie die Kapselung auf HDLC ein.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0
   maui-nas-03(config-if)#enc
   maui-nas-03(config-if)#encapsulation HDLC 
   maui-nas-03(config-if)#^Z
   

4. Mit dem Befehl show running-config können Sie überprüfen, ob die Schnittstelle über eine IP-Adresse verfügt.

   Wenn die Schnittstelle keine IP-Adresse hat, rufen Sie eine eindeutige Adresse ab, und weisen Sie sie der Schnittstelle mit der Subnetzmaske 255.255.255.0 zu.

   maui-nas-03(config)#ip address 172.22.53.1 255.255.255.0
   

5. Löschen Sie die Schnittstellenindikatoren mit dem Befehl clear counter.

   maui-nas-03#clear counters
   Clear "show interfaces" counters on all interfaces [confirm]
   maui-nas-03#

6. Führen Sie den erweiterten Ping-Test wie im Abschnitt "Verwenden erweiterter Ping-Tests" weiter oben in diesem Kapitel beschrieben durch.

Fehlerbehebung E1

In diesem Abschnitt werden die Techniken und Verfahren zur Fehlerbehebung bei E1-Schaltungen für Einwahlkunden beschrieben.

Fehlerbehebung mit dem Befehl show controller e1

Dieser Befehl zeigt den Controller-Status an, der für die Controller-Hardware spezifisch ist. Die angezeigten Informationen sind im Allgemeinen nur für Diagnoseaufgaben nützlich, die von Mitarbeitern des technischen Supports durchgeführt werden.

Der NMP oder MIP kann die Port-Adapter abfragen, um ihren aktuellen Status zu bestimmen. Geben Sie einen Befehl show controller e1 ein, um Statistiken zur E1-Verbindung anzuzeigen. Wenn Sie einen Steckplatz und eine Portnummer angeben, werden Statistiken für jeden Zeitraum von 15 Minuten angezeigt.

Der Befehl show controller e1 EXEC enthält Informationen zur logischen Fehlerbehebung bei Problemen mit der physischen Ebene und der Sicherungsschicht. In diesem Abschnitt wird beschrieben, wie Sie mit dem Befehl show controller e1 eine logische Fehlerbehebung durchführen.

Die meisten E1-Fehler werden durch falsch konfigurierte Leitungen verursacht. Stellen Sie sicher, dass die Konfigurationen von Verkabelung, Framing, Taktquelle und Leitungsabschluss (mit oder ohne Ausgleich) den Empfehlungen des Service Providers entsprechen.

show controller e1-Bedingungen

Der E1-Controller kann sich in einem der folgenden drei Zustände befinden.

• Administrationseinstellung

• Nach unten

• Nach oben

Ist der E1-Controller administrativ ausgefallen?

Der Controller wurde vom Administrator deaktiviert, wenn er manuell heruntergefahren wurde. Sie sollten den Controller neu starten, um diesen Fehler zu beheben.

1. Aktivieren Sie den Modus.

   maui-nas-03>enable
   Password: 
   maui-nas-03#

2. Wechseln in den globalen Konfigurationsmodus

   maui-nas-03#configure terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#

3. Rufen Sie den Controller-Konfigurationsmodus auf.

   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#

4. Starten Sie den Controller neu.

   maui-nas-03(config-controlle)#shutdown
   maui-nas-03(config-controlle)#no shutdown
   

Ist die Leitung besetzt?

Wenn die E1-Leitung nicht aktiv ist, überprüfen Sie, ob die Leitungskonfiguration korrekt ist und mit den Einstellungen des Remote-Endgeräts übereinstimmt.

1. Überprüfen Sie das Framing der Leitung und das Remote-Ende. Bei E1-Leitungen ist das Framing entweder CRC4 oder noCRC4.

2. Überprüfen Sie die Verkabelung der Leitung und des Remote-Endgeräts. Die Verbindung erfolgt entweder über AMI oder HDB3.

3. Überprüfen Sie, ob die Leitungsterminierung für ausgeglichene oder unausgeglichene Verbindungen (75 Ohm oder 120 Ohm) eingestellt ist.

Weitere Informationen zu den richtigen Einstellungen erhalten Sie von Ihrem Dienstanbieter. Nehmen Sie ggf. Änderungen an lokalen oder Remote-Endgeräten vor.

Wenn der E1-Controller und die Leitung nicht aktiv sind, überprüfen Sie, ob eine der folgenden Meldungen in der Ausgabe e1 EXEC des Controllers anzeigen erscheint:

• Empfänger hat Frame-Verlust

• Signalverlust beim Empfänger

Wenn der E1-Empfänger Frame-Verlust hat:

Gehen Sie wie folgt vor, wenn der E1-Empfänger einen Frame-Verlust aufweist.

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Sie können das Framing-Format des Controllers anhand der aktuellen Konfiguration oder der Befehlsausgabe des show controller e1 überprüfen.

   Um das Framing-Format zu ändern, verwenden Sie das Framing {CRC4 | kein CRC4}-Befehl im Controller-Konfigurationsmodus wie unten gezeigt:

   maui-nas-03#configure terminal 
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#controller E1 0
   maui-nas-03(config-controlle)#framing CRC4
   

2. Testen Sie das andere Frame-Format, um zu sehen, ob der Alarm gelöscht wird.

   Wenn das Problem dadurch nicht behoben wird, fahren Sie unten mit dem Abschnitt "Wenn der E1-Empfänger einen Signalverlust hat" fort.

3. Überprüfen Sie das Bildformat am Remote-Ende.

4. Überprüfen Sie die Verbindungsherstellung am Remote-Ende.

Wenn der E1-Empfänger einen Signalverlust hat:

Gehen Sie folgendermaßen vor, wenn der E1-Empfänger ein Signalverlust aufweist.

1. Stellen Sie sicher, dass das Kabel zwischen dem Schnittstellenanschluss und dem Gerät des E1-Dienstanbieters (oder E1-Endgerät) richtig angeschlossen ist. Überprüfen Sie, ob das Kabel an die richtigen Ports angeschlossen ist. Korrigieren Sie ggf. die Kabelverbindungen.

2. Überprüfen Sie die Kabelintegrität. Suchen Sie im Kabel nach Pausen oder anderen physischen Abweichungen. Stellen Sie sicher, dass die Pinbelegung korrekt eingestellt ist. Tauschen Sie das Kabel bei Bedarf aus.

3. Überprüfen Sie die Kabelanschlüsse. Eine Umkehr der Sende- und Empfangspaare oder ein offenes Empfangspaar können Fehler verursachen. Legen Sie für das Empfangspaar die Zeilen 1 und 2 fest. Legen Sie für das Transmit-Paar die Leitungen 4 und 5 fest.

   Die Pins an einer RJ-48-Buchse sind von 1 bis 8 nummeriert. Pin 1 ist der linke Stift, wenn man die Buchse mit den Metallstiften betrachtet, die zu Ihnen gerichtet sind. Weitere Informationen finden Sie in der folgenden Abbildung.

   Abbildung 15-11: RJ-45-Kabel

   

4. Verwenden Sie ein Rollover-Kabel.

5. Überprüfen Sie, ob Blockfehler am anderen Ende vorliegen. Wenn dies der Fall ist, liegt das Problem mit dem EmpfängerLead am lokalen Ende vor. Weitere Unterstützung erhalten Sie vom TAC.

Führen Sie nach jedem Schritt den Befehl show controller e1 EXEC aus, um zu überprüfen, ob der Controller Fehler aufweist.

Wenn sich die Leitung im Loopback-Modus befindet:

Überprüfen Sie, ob sich die Leitung in der Ausgabe des show controller e1 im Loopback-Modus befindet. Eine Leitung sollte sich nur zu Testzwecken im Loopback-Modus befinden.

Verwenden Sie zum Deaktivieren des Loopbacks den Befehl no loopback im Controller-Konfigurationsmodus, wie unten gezeigt:

maui-nas-03(config-controlle)#no loopback

Wenn der Controller Alarme anzeigt:

Überprüfen Sie die Ausgabe des Befehls show controller, um festzustellen, ob vom Controller Alarme angezeigt werden.

Wir werden nun über verschiedene Alarme und das Verfahren sprechen, das erforderlich ist, um sie zu korrigieren.

Empfänger (RX) hat Remote-Alarm:

Ein empfangener Remote-Alarm bedeutet, dass ein Alarm auf der Leitung vor dem mit dem Port verbundenen Gerät auftritt.

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Wenn nicht, ändern Sie das Frame-Format auf dem Controller so, dass es mit dem Format der Leitung übereinstimmt.

2. Überprüfen Sie die Einstellung für die Verkabelung der Remote-Endgeräte. Wenden Sie sich an Ihren Dienstanbieter, um die richtigen Einstellungen zu erhalten. Korrigieren Sie ggf. Fehlkonfigurationen.

3. Schließen Sie ein externes Loopback-Kabel an den Port an. Informationen zum Erstellen eines Loopback-Steckers finden Sie im Abschnitt "Durchführen eines Hardware-Loopback-Plug-Tests" weiter oben im Abschnitt.

4. Überprüfen Sie, ob Alarme vorliegen. Wenn Sie keine Alarme sehen, ist die lokale Hardware wahrscheinlich in gutem Zustand. In diesem Fall

   1. Überprüfen Sie die Verkabelung. Weitere Informationen finden Sie im Abschnitt "Wenn der E1-Empfänger einen Signalverlust hat".

   2. Überprüfen Sie die Einstellungen am Remote-Ende, und stellen Sie sicher, dass sie mit den Porteinstellungen übereinstimmen.

   3. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Dienstanbieter.

5. Entfernen Sie den Loopback-Stecker, und schließen Sie Ihre E1-Leitung wieder an.

6. Überprüfen Sie die Verkabelung. Weitere Informationen finden Sie im Abschnitt "Wenn der E1-Empfänger einen Signalverlust hat".

7. Schalten Sie den Router aus und wieder ein.

8. Schließen Sie die E1-Leitung an einen anderen Port an. Konfigurieren Sie den Port mit den gleichen Einstellungen wie die Leitung. Wenn das Problem nicht weiter besteht, liegt der Fehler beim einen Port:

   1. Schließen Sie die E1-Leitung wieder an den ursprünglichen Port an.

   2. Fahren Sie mit dem Abschnitt "Problembehandlung bei E1-Fehlerereignissen" fort.

      Wenn das Problem weiterhin besteht, gehen Sie wie folgt vor:

9. Führen Sie einen Hardware-Schleifentest durch, wie im Abschnitt "Durchführen des Hardware-Loopback-Plug-Tests" beschrieben.

10. Ersetzen Sie die E1-Controllerkarte.

11. Fahren Sie mit dem Abschnitt "Problembehandlung bei E1-Fehlerereignissen" fort.

Transmitter sendet Remote-Alarm (rot):

Ein Roter Alarm wird deklariert, wenn der CSU nicht mit dem Framinguster auf der E1-Leitung synchronisiert werden kann.

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Wenn Sie das Frame-Format auf dem Controller nicht ändern, um es mit dem Format der Leitung abzustimmen.

2. Überprüfen Sie die Einstellungen am Remote-Ende, und stellen Sie sicher, dass sie mit den Porteinstellungen übereinstimmen.

3. Schließen Sie ein externes Loopback-Kabel an den Port an. Informationen zum Erstellen eines Loopback-Steckers finden Sie im Abschnitt "Durchführen eines Hardware-Loopback-Plug-Tests" weiter oben im Abschnitt.

4. Überprüfen Sie, ob Alarme vorliegen. Wenn Sie keine Alarme sehen, ist die lokale Hardware wahrscheinlich in gutem Zustand. In diesem Fall

   1. Überprüfen Sie die Verkabelung. Weitere Informationen finden Sie im Abschnitt "Wenn der E1-Empfänger einen Signalverlust hat".

   2. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Dienstanbieter.

5. Schließen Sie die E1-Leitung an einen anderen Port an. Konfigurieren Sie den Port mit den gleichen Einstellungen wie die Leitung. Wenn das Problem nicht weiter besteht, liegt der Fehler beim einen Port.

   1. Schließen Sie die E1-Leitung wieder an den ursprünglichen Port an.

   2. Fahren Sie mit dem Abschnitt "Problembehandlung bei E1-Fehlerereignissen" fort.

      Wenn das Problem weiterhin besteht, gehen Sie wie folgt vor:

6. Führen Sie einen Hardware-Schleifentest durch, wie im Abschnitt "Durchführen des Hardware-Loopback-Plug-Tests" beschrieben.

7. Ersetzen Sie die E1-Controllerkarte.

8. Fahren Sie mit dem Abschnitt "Problembehandlung bei E1-Fehlerereignissen" fort.

9. Wenden Sie sich an Ihren Dienstanbieter.

Problembehandlung bei E1-Fehlerereignissen

Der Befehl show controller e1 EXEC enthält Fehlermeldungen, die zur Fehlerbehebung verwendet werden können. Wir werden nun mehrere Fehlermeldungen und die Behebung der Fehler besprechen.

Um festzustellen, ob die Fehlerzähler ansteigen, führen Sie den Befehl show controller e1 wiederholt aus. Beachten Sie die Werte der Zähler für das aktuelle Intervall. Fragen Sie Ihren Service Provider nach Framing- und Linked-Einstellungen.

Der Zähler für Slip Secs nimmt zu:

Das Vorhandensein von Schlüpfen auf E1-Leitungen weist auf ein Taktproblem hin. Der E1-Anbieter (Telco) stellt die Uhr bereit, mit der die Ausrüstung am Kundenstandort (Customer Premises Equipment, CPE) synchronisiert werden soll.

1. Überprüfen Sie, ob die Taktquelle vom Netzwerk abgeleitet ist. Dies kann durch die Suche nach Clock Source is Line Primary (Quelle für Leitung Primär) ermittelt werden.

   Hinweis: Wenn sich auf einem Zugriffsserver mehrere E1 befinden, kann nur einer der primären sein, während die anderen E1 die Uhr vom primären Server ableiten. Überprüfen Sie in diesem Fall, ob die E1-Leitung, die als primäre Taktquelle festgelegt wurde, korrekt konfiguriert ist.

2. Stellen Sie die E1-Taktquelle im Controller-Konfigurationsmodus korrekt ein.

   maui-nas-03(config-controlle)#clock source line primary
   

Zähler für Framing-Verlustsekunden steigt:

Gehen Sie folgendermaßen vor, wenn der Zähler für Verlustsekunden größer wird:

1. Überprüfen Sie, ob das auf dem Port konfigurierte Bildformat mit dem Bildformat der Leitung übereinstimmt. Sie können dies überprüfen, indem Sie in der Ausgabe des Show-Controllers e1 nach dem Framing {CRC4|no CRC4} suchen.

2. Um das Framing-Format zu ändern, verwenden Sie das Framing {CRC4 | Kein CRC4}-Befehl im Controller-Konfigurationsmodus wie unten gezeigt:

   maui-nas-03(config-controlle)#framing crc4
   

Verstöße gegen Leitungscode nehmen zu:

Führen Sie diese Schritte aus, wenn die Anzahl der Verstöße gegen den Leitungscode zunimmt.

1. Überprüfen Sie, ob die auf dem Port konfigurierte Verkabelung mit dem Frame-Format der Leitung übereinstimmt. Sie können dies überprüfen, indem Sie in der Ausgabe des Anzeigecontrollers e1 nach {AMI/HDB3} suchen.

2. Verwenden Sie den Linecode {ami}, um das Linked zu ändern. | hdb3} im Controller-Konfigurationsmodus wie unten gezeigt:

   maui-nas-03(config-controlle)#linecode ami
   

Überprüfen der korrekten Konfiguration des ISDN-Switch-Typs und der PRI-Gruppe

Mit dem Befehl show running-config können Sie überprüfen, ob der ISDN-Switch-Typ und die Timeslots der PRI-Gruppe korrekt konfiguriert sind. Wenden Sie sich an Ihren Dienstanbieter, um korrekte Werte zu erhalten.

So ändern Sie den ISDN-Switch-Typ und die PRI-Gruppe:

maui-nas-03#configure terminal
maui-nas-03(config)#isdn switch-type primary-net5
maui-nas-03(config)#controller e1 0
maui-nas-03(config-controlle)#pri-group timeslots 1-31

Überprüfen des Signalisierungskanals

Wenn die Fehlerzähler nicht ansteigen, das Problem jedoch weiterhin besteht, stellen Sie sicher, dass der Signalisierungskanal korrekt eingerichtet und konfiguriert ist.

1. Führen Sie den Befehl show interface serial x:15 aus, wobei x durch die Schnittstellennummer ersetzt werden sollte.

2. Überprüfen Sie, ob die Schnittstelle aktiv ist. Wenn die Schnittstelle nicht aktiv ist, können Sie die Schnittstelle mit dem Befehl no shutdown aktivieren.

   maui-nas-03#config terminal
   Enter configuration commands, one per line.  End with CNTL/Z.
   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

3. Stellen Sie sicher, dass die Kapselung PPP ist. Wenn die Schnittstelle PPP nicht verwendet, korrigieren Sie diese mit dem Befehl encapsulation ppp im Schnittstellenkonfigurationsmodus.

   maui-nas-03(config-if)#encapsulation ppp
   

4. Überprüfen Sie, ob Loopback eingestellt ist. Loopback sollte nur zu Testzwecken eingestellt werden. Verwenden Sie den Befehl no loopback, um Loopbacks zu entfernen.

   maui-nas-03(config-if)#no loopback
   

5. Schalten Sie den Router aus und wieder ein.

6. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Service Provider oder das Cisco TAC.

Fehlerbehebung bei PRI

Bei der Fehlerbehebung bei einem PRI müssen Sie feststellen, ob das E1 auf beiden Seiten einwandfrei funktioniert. Wenn Layer-1-Probleme wie oben beschrieben behoben wurden, sollten Sie Layer-2- und Layer-3-Probleme berücksichtigen.

Fehlerbehebung Verwenden des Befehls show isdn status

Der Befehl show isdn status wird verwendet, um einen Snapshot aller ISDN-Schnittstellen anzuzeigen. Es zeigt den Status der Layer 1, 2 und 3 an.

1. Überprüfen Sie, ob Layer 1 aktiv ist.

   Der Layer-1-Status sollte immer ACTIVE (aktiv) heißen, es sei denn, der E1-Status ist ausgefallen.

   Wenn der SIDN-Status anzeigt, dass Layer 1 DEAKTIVIERT ist, besteht ein Problem mit der physischen Verbindung auf der E1-Leitung. Siehe Abschnitt "Ist der E1-Controller administrativ ausgefallen?"

   Überprüfen Sie außerdem, ob das E1 administrativ nicht deaktiviert ist. Verwenden Sie den Befehl no shutdown, um den E1-Controller hochzufahren.

2. Überprüfen Sie, ob der Layer-2-Status "MULTIPLE_FRAME_ESTABLISHED" lautet.

Der gewünschte Layer-2-Status ist Multiple_Frame_Established. Dies bedeutet, dass das Startprotokoll zwischen dem ISDN-Switch und dem Endgerät eingerichtet wurde und wir Layer-2-Frames austauschen.

Wenn Layer 2 nicht Multiple_Frame_Established ist, können Sie das Problem mit dem Befehl show controller e1 EXEC diagnostizieren. Siehe Abschnitt "Fehlerbehebung mit dem Befehl show controller e1" in diesem Kapitel und Abschnitt "Problembehandlung bei E1-Fehlerereignissen".

Da der Anzeigestatus "show isdn" eine Momentaufnahme des aktuellen Status ist, kann es vorkommen, dass Layer 2 trotz der Angabe von "Mulitple_Frame_Established" hochfährt und abspringt. Verwenden Sie den Befehl debug isdn q921, um zu überprüfen, ob Layer 2 stabil ist.

Verwenden von debug q921

Der Befehl debug isdn q921 zeigt Zugriffsverfahren für die Datenlinkschicht (Layer 2) an, die auf dem Router auf dem D-Kanal durchgeführt werden.

Stellen Sie sicher, dass Sie so konfiguriert sind, dass Sie Debugmeldungen anzeigen, indem Sie bei Bedarf den Befehl logging console oder terminal monitor verwenden.

Hinweis: Überprüfen Sie in einer Produktionsumgebung, ob die Konsolenprotokollierung deaktiviert ist. Geben Sie den Befehl show logging ein. Wenn die Protokollierung aktiviert ist, kann es vorkommen, dass der Zugriffsserver periodisch abstürzt, sobald der Konsolenport mit Protokollmeldungen überlastet wird. Geben Sie den Befehl no logging console ein.

Hinweis: Wenn debug isdn q921 aktiviert ist und Sie keine Debug-Ausgaben erhalten, tätigen Sie einen Aufruf oder setzen Sie den Controller zurück, um Debug-Ausgaben zu erhalten.

1. Stellen Sie sicher, dass Layer 2 stabil ist. Sie sollten die Debug-Ausgaben für Meldungen beobachten, die darauf hinweisen, dass der Dienst nicht nach oben oder unten bounce. Wenn Sie die folgenden Typen von Debug-Ausgaben sehen, ist die Zeile nicht stabil.

   Mar 20 10:06:07.882: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0:15, TEI 0 
   changed to down
   Mar 20 10:06:09.882: %LINK-3-UPDOWN: Interface Serial0:15, changed state to down
   Mar 20 10:06:21.274: %DSX1-6-CLOCK_CHANGE: Controller 0  clock is now selected 
   as clock source
   Mar 20 10:06:21.702: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0:15, TEI 0 
   changed to up
   Mar 20 10:06:22.494: %CONTROLLER-5-UPDOWN: Controller E1 0, changed state to up
   Mar 20 10:06:24.494: %LINK-3-UPDOWN: Interface Serial0:15, changed state to up
   
   

   Wenn Layer 2 nicht stabil erscheint, siehe "Problembehandlung bei E1-Fehlerereignissen" weiter oben in diesem Kapitel.

2. Stellen Sie sicher, dass Sie nur SAPI-Nachrichten auf beiden Seiten Transmit (TX) und Receive (RX) sehen.

   Mar 20 10:06:52.505: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:06:52.505: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.505: ISDN Se0:15: TX ->  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRp sapi = 0  tei = 0 nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: TX ->  RRf sapi = 0  tei = 0  nr = 0
   Mar 20 10:07:22.509: ISDN Se0:15: RX <-  RRf sapi = 0  tei = 0  nr = 0

3. Vergewissern Sie sich, dass keine SABME-Meldungen angezeigt werden, was darauf hinweist, dass Layer 2 versucht, die Initialisierung durchzuführen. Dies ist in der Regel der Fall, wenn wir Umfrageanfragen (Polll Requests, RRp) übertragen und keine Antwort vom Switch (RRf) oder umgekehrt erhalten. Nachfolgend finden Sie ein Beispiel für SABME-Nachrichten. Wir sollten eine Antwort vom ISDN-Switch für unsere SABME-Nachrichten erhalten (UA-Frame wird empfangen).

   Mar 20 10:06:21.702: ISDN Se0:15: RX <-  SABMEp sapi = 0  tei = 0
   Mar 20 10:06:22.494: ISDN Se0:15: TX ->  SABMEp sapi = 0  tei = 0

   Wenn Sie SABME-Meldungen sehen, verwenden Sie den Befehl show running-config, um zu überprüfen, ob der ISDN-Switch-Typ und die Timeslots der PRI-Gruppe korrekt konfiguriert sind. Wenden Sie sich an Ihren Dienstanbieter, um korrekte Werte zu erhalten.

   So ändern Sie den ISDN-Switch-Typ und die PRI-Gruppe:

   maui-nas-03#configure terminal
   maui-nas-03(config)#isdn switch-type primary-net5
   maui-nas-03(config)#controller e1 0
   maui-nas-03(config-controlle)#pri-group timeslots 1-31
   

4. Überprüfen Sie, ob der D-Kanal mit dem Befehl show interfaces serial x:15 eingeschaltet ist.

   Wenn der D-Kanal nicht aktiv ist, können Sie ihn mit dem Befehl no shutdown aktivieren:

   maui-nas-03(config)#interface serial 0:15
   maui-nas-03(config-if)#no shutdown
   

5. Überprüfen Sie, ob Kapselung PPP ist. Wenn nicht der Befehl encapsulation ppp zum Festlegen der Kapselung verwendet wird.

   maui-nas-03(config-if)#encapsulation ppp
   

6. Überprüfen Sie, ob sich die Schnittstelle im Loopback-Modus befindet. Im Normalbetrieb sollte sich die Schnittstelle nicht im Loopback-Modus befinden.

   maui-nas-03(config-if)#no loopback
   

7. Schalten Sie den Router aus und wieder ein.

8. Wenn das Problem weiterhin besteht, wenden Sie sich an Ihren Service Provider oder das Cisco TAC.

Zugehörige Informationen

• Technischer Support - Cisco Systems

Revisionsverlauf