Fehlerbehebung bei "Line Protocol is Down"-Problemen an POS-Schnittstellen

Einführung

In diesem Dokument wird die Fehlerbehebung für eine Paket-over-SONET (POS)-Routerschnittstelle mit dem Leitungsprotokollstatus "Down" beschrieben.

Es hilft nicht nur, festzustellen, ob das Line-Protokoll ausgefallen ist, sondern erläutert auch die Befehle zum Anzeigen und Debuggen, die zur Fehlerbehebung für die Kapselung von Point-to-Point Protocol (PPP)- und High-Level Data Link Control (HDLC)-Kapselung verwendet werden. Darüber hinaus führt er Sie durch ein typisches Fehlerbehebungsszenario, das auf einer dokumentierten Laboreinrichtung basiert.

Interpretiert den Befehl show interface pos

Für die Zwecke des Dokuments wird die Ausgabe von show interface pos wie in dieser Ausgabe dargestellt angezeigt. Beachten Sie die hervorgehobenen Teile des Displays und die Kommentare:

RTR12410-2#show interface pos 6/0 
   POS6/0 is up, line protocol is down 

!--- The line protocol is down
.
     Hardware is Packet over SONET 
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 1/255 
     Encapsulation HDLC, crc 32, loopback not set 

!--- The loopback has not been set.

     Keepalive set (10 sec) 

!--- The keepalive is set as every ten seconds.

     Scramble disabled 
  Last input never, output 00:00:05, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     0 packets input, 0 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
              0 parity 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     3 packets output, 1074 bytes, 0 underruns 
     0 output errors, 0 applique, 1 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     2 carrier transitions

Die Cisco IOS^® Command Reference gibt an, dass der Leitungsprotokollfeldstatus "angibt, ob die Softwareprozesse, die das Leitungsprotokoll behandeln, die Leitung als nutzbar (d. h. Keepalives sind erfolgreich) ansehen oder ob sie von einem Administrator deaktiviert wurde."

Weitere wichtige Felder in der Ausgabe der show interface pos sind:

• Kapselung - Die der Schnittstelle zugewiesene Kapselungsmethode.

• Loopback: Gibt an, ob der Loopback festgelegt ist.

• keepalive: Gibt an, ob Keepalives eingestellt sind.

POS-Protokoll-Stack - Übersicht

Dieses Diagramm zeigt den Protokollstapel, der auf einer POS-Schnittstelle verwendet wird.

POS-Schnittstellen unterstützen mehrere Kapselungen - HDLC, PPP und Frame Relay. Daher ist Packet over SONET genauer PPP over SONET oder HDLC over SONET. Dieses Dokument behandelt keine Frame-Relay-Kapselung.

PPP und HDLC sind eng miteinander verbunden und weisen die folgenden Merkmale auf:

• Stellen Sie eine Rahmenstruktur mit Headern und Anhängern bereit. Der Trailer bietet Fehlerprüfung.

• Bereitstellen einer Frame-Definition, die für einen Empfänger genau definiert, wo ein Paket und Frame beginnt und endet. In HDLC und PPP wird die Rahmentrennung durch ein spezielles Interframe-Füllmuster oder Leerlaufmuster realisiert. Das Muster ist 0x7E oder 0111 1110.

• Definieren Sie eine minimale und maximale Paketlänge.

• Transport-IP-Pakete und Bereitstellung einer Methode, mit der Empfänger den genauen Pakettyp im ankommenden Frame ermitteln können.

Obwohl PPP und HDLC eng miteinander verknüpft sind, sind sie jedoch nicht identisch, und es werden verschiedene Debug-Befehle zur Behebung von Verbindungsprotokollproblemen verwendet.

Debugbefehle verwenden

Die Ausgabe verschiedener debug-privilegierter EXEC-Befehle stellt Diagnoseinformationen zum Protokollstatus und zur Netzwerkaktivität für viele Internetworking-Ereignisse bereit.

Achtung: Da die Debugausgabe im CPU-Prozess eine hohe Priorität erhält, 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.

Diese Debug-Befehle sind nützlich, wenn Sie POS-Schnittstellenprobleme beheben. Weitere Informationen zur Funktion und Ausgabe dieser Befehle finden Sie in den Veröffentlichungen zu Cisco Debug Command Reference:

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

• debug ppp negotiation (PPP-Aushandlung): Zeigt 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 (ppp-Fehler) - Zeigt PPP-Fehler (z. B. illegale oder falsch formatierte Frames) an, die mit der Verhandlung und dem Betrieb einer PPP-Verbindung verknüpft sind.

Weitere Informationen finden Sie unter Fehlerbehebung bei Problemen mit seriellen Leitungen.

Das Verbindungsprotokoll ist mit HDLC ausgefallen.

HDLC ist der Standardkapselungstyp für eine POS-Router-Schnittstelle. HDLC ist ein internationaler Standard, aber die Implementierungen der Anbieter variieren in Größe und Format je nach Feld oder Header oder Anhänger. Die Telecordia GR-253-Spezifikation, die SONET definiert, behandelt HDLC-over-SONET-Mapping (siehe Issue 3, Abschnitt 3.4.2.3, S. 3-59). Er legt fest, dass der HDLC-Frame byte-abgestimmt auf den SONET-Frame sein soll, und legt außerdem einen selbst synchronisierenden Scrambler, eine zyklische Redundanzprüfung (CRC) und die Verwendung des HDLC-Flagmusters als Frame-Interframe-Füllung fest, um der Variabilität der ankommenden HDLC-Frames Rechnung zu tragen.

Wenn der Befehl show interface pos anzeigt, dass Leitung und Protokoll bei der HDLC-Kapselung nicht verfügbar sind, können Sie den Befehl debug Serial Interface verwenden, um ein Verbindungsproblem als Ursache für einen Verbindungsfehler zu isolieren. HDLC verwendet Keepalives und meldet die Werte von drei Zählern in der Debugausgabe:

• myseq - Erhöht sich jedes Mal, wenn der Router ein Keepalive-Paket an den Remote-Router sendet.

• mineseen - Der Wert des Zählers für Minen gibt die letzte myseq-Sequenznummer wieder, die der Remote-Router vom Router erhalten hat. Der Remote-Router speichert diesen Wert im eigenen Zähler und sendet diesen Wert in einem Keepalive-Paket an den Router.

• Ihrseen (Ihr gesehen) - gibt den Wert der myseq-Sequenznummer wieder, die der Router in einem Keepalive-Paket vom Remote-Router erhalten hat.

Wenn die Keepalive-Werte in den mineseq-Feldern, den angezeigten und myseen-Feldern nicht in jeder nachfolgenden Ausgabezeile inkrementieren, besteht ein Problem an einem Ende der Verbindung. Wenn der Unterschied in den Werten in den Feldern myseq und mineseen drei überschreitet, wird die Zeile deaktiviert, und die Schnittstelle wird zurückgesetzt.

Dies ist eine Beispielausgabe des Befehls serielle Debugschnittstelle für eine HDLC-Verbindung, wenn Keepalives an beiden Enden ordnungsgemäß empfangen werden.

hswan-12008-2a#debug serial interface 
Serial network interface debugging is on 
hswan-12008-2a# 
Oct 31 11:47:16: POS4/0: HDLC myseq 180, mineseen 0*, yourseen 1, line up 
Oct 31 11:47:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- Local router sees a remote keepalive with a sequence number of 1. 

Oct 31 11:47:26: POS4/0: HDLC myseq 181, mineseen 181*, yourseen 2, line up 
Oct 31 11:47:36: POS4/0: HDLC myseq 182, mineseen 182*, yourseen 3, line up 
Oct 31 11:47:46: POS4/0: HDLC myseq 183, mineseen 183*, yourseen 4, line up 
Oct 31 11:47:56: POS4/0: HDLC myseq 184, mineseen 184*, yourseen 5, line up 
Oct 31 11:48:06: POS4/0: HDLC myseq 185, mineseen 185*, yourseen 6, line up 

!--- Keepalives are sent every 10 seconds by default. !--- Both sides report incrementing sequence numbers. 

Dies ist die Beispielausgabe des Befehls serielle debug Schnittstelle für eine HDLC-Verbindung, wenn die Remote-Schnittstelle geschlossen wird und die lokale Schnittstelle mehr als drei Keepalives übersieht.

hswan-12008-2a# 
Oct 31 11:49:46: POS4/0: HDLC myseq 195, mineseen 192, yourseen 13, line down 
Oct 31 11:49:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to down 

!--- The local router has failed to receive three keepalives and !--- brings down the line protocol. Note the difference between !--- "myseq 195" and "mineseen 192". 

Oct 31 11:49:56: POS4/0: HDLC myseq 196, mineseen 192, yourseen 13, line down 
Oct 31 11:50:06: POS4/0: HDLC myseq 197, mineseen 192, yourseen 13, line down 
Oct 31 11:50:16: POS4/0: HDLC myseq 198, mineseen 192, yourseen 13, line down 
Oct 31 11:50:26: POS4/0: HDLC myseq 199, mineseen 192, yourseen 13, line down 
Oct 31 11:50:36: POS4/0: HDLC myseq 200, mineseen 0*, yourseen 1, line up 
Oct 31 11:50:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!--- After you execute the no shut command on the remote router, !--- the local router receives a keepalive again and brings up !--- the line protocol. 

Oct 31 11:50:46: POS4/0: HDLC myseq 201, mineseen 201*, yourseen 2, line up 
Oct 31 11:50:56: POS4/0: HDLC myseq 202, mineseen 202*, yourseen 3, line up 
Oct 31 11:51:06: POS4/0: HDLC myseq 203, mineseen 203*, yourseen 4, line up 
Oct 31 11:51:16: POS4/0: HDLC myseq 204, mineseen 204*, yourseen 5, line up 
Oct 31 11:51:26: POS4/0: HDLC myseq 205, mineseen 205*, yourseen 6, line up 
Oct 31 11:51:36: POS4/0: HDLC myseq 206, mineseen 206*, yourseen 7, line up 

!--- After the shut/no shut, the remote router re-initialized its !--- sequence number.
 

Das Verbindungsprotokoll ist mit PPP nicht verfügbar.

RFC 1661 definiert PPP als Protokoll. POS-Schnittstellen unterstützen PPP in High-Level Data Link Control (HDLC)-ähnlichem Framing (wie in RFC 1662 spezifiziert) für die Datenkapselung auf Layer 2. Das Frame-Format für PPP in HDLC-ähnlichem Rahmen wird in dieser Abbildung gezeigt.

RFC 2615 legt die Verwendung von PPP-Kapselung über SONET- oder SDH-Links fest. PPP wurde für die Verwendung auf Point-to-Point-Verbindungen entwickelt und eignet sich für SONET- oder SDH-Verbindungen, die auch in Ringtopologien als Punkt-zu-Punkt-Schaltungen bereitgestellt werden.

Wenn eine Point-to-Point-Verbindung aufgerufen wird, durchläuft PPP mehrere verschiedene Phasen, die in einem Zustandsdiagramm gezeichnet werden können. Wenn ein externes Ereignis, z. B. die Carrier-Erkennung oder die Konfiguration des Netzwerkadministrators, darauf hinweist, dass die physische Ebene einsatzbereit ist, wird PPP zur Verbindungsphase fortgeführt. Beim Übergang zu dieser Phase wird ein UP-Ereignis zum Link Control Protocol (LCP) erzeugt, das mehrere Funktionen bereitstellt. Eine Funktion besteht darin, festzustellen, wann eine Verbindung ordnungsgemäß funktioniert und wann sie fehlschlägt. Um die Kommunikation über eine Point-to-Point-Verbindung herzustellen, muss jedes Ende der PPP-Verbindung zuerst LCP-Pakete senden, um die Datenverbindung zu konfigurieren und zu testen.

Anschließend muss PPP NCP-Pakete (Network Control Protocol) senden, um ein oder mehrere Netzwerkschichtprotokolle auszuwählen und zu konfigurieren. Nach der Konfiguration der einzelnen Netzwerkschichtprotokolle können Datagramme aus jedem Netzwerkschichtprotokoll über die Verbindung gesendet werden.

In dieser Tabelle sind die drei Klassen von LCP-Paketen aufgeführt:

Link-Konfiguration

LCP wird verwendet, um die Verbindung durch den Austausch von Configure-Paketen herzustellen. Dieser Austausch ist abgeschlossen, und der LCP-Open-Status wird eingegeben, sobald ein Configure-Ack-Paket gesendet und empfangen wurde.

Diese Beispielausgabe erfasst die LCP-Link-Konfigurationsphase an einer POS-Schnittstelle:

4d01h: PO3/1 LCP: State is Open 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 LCP_UP 
(0x639FCAD8) id 0 (0s.) queued 1/1/2 
4d01h: PO3/1 PPP: Phase is UP 
4d01h: PO3/1 IPCP: O CONFREQ [Closed] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 
4d01h: PO3/1 IPCP: I CONFREQ [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: O CONFACK [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: I CONFACK [ACKsent] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 IPCP: State is Open 
4d01h: PO3/1 IPCP: Install route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to up 

Hinweis: Eine mit PPP-Kapselung konfigurierte POS-Schnittstelle versucht kontinuierlich, eine PPP-Sitzung herzustellen. Sie sehen also, dass das Leitungsprotokoll bei einem anhaltenden Problem, auch wenn die Glasfaser entfernt wird, regelmäßig für kurze Zeit auftaucht.

Link-Wartung (mit Keepalives)

LCP-Echo-Request- und Echo-Reply-Pakete bieten einen Layer-2-Loopback-Mechanismus für beide Verbindungsrichtungen. Beim Empfang einer Echo-Anforderung im LCP-Opened-Zustand muss eine Echo-Antwort übertragen werden.

Dieses Diagramm aus RFC 1661 veranschaulicht das Format eines PPP-Keepalive-Pakets.

Diese LCP-Pakete enthalten die folgenden Schlüsselfelder:

• Code: 9 für Echo-Request und 10 für Echo-Reply.

• Identifier: Bei der Übertragung muss das Identifikationsfeld bei jeder Änderung des Inhalts des Datenfelds und bei jedem Eingang einer gültigen Antwort für eine vorherige Anfrage geändert werden. Bei Neuübertragungen kann die Kennung unverändert bleiben. Beim Empfang wird das Identifikationsfeld des Echo-Request in das Identifikationsfeld des Echo-Reply-Pakets kopiert.

• Magic-Number (Magic-Number): Das Magic-Number-Feld ist vier Oktette und unterstützt die Erkennung von Links, die sich im Looped-Back-Zustand befinden. Bis die Konfigurationsoption für die Magic-Nummer erfolgreich ausgehandelt wurde, muss die Magic-Nummer als Null übertragen werden. Weitere Erläuterungen finden Sie in der Magic-Number-Konfigurationsoption in RFC 1661.

• Data (Daten): Das Datenfeld ist 0 (null) oder mehr Oktette und enthält uninterpretierte Daten für die Verwendung durch den Absender. Die Daten können aus einem beliebigen Binärwert bestehen. Das Ende des Felds wird durch die Länge angegeben.

Im Folgenden finden Sie ein Beispiel für die Debugging-ppp-Aushandlung bei Aktivierung von Keepalives:

4d01h: PO3/1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x1A45933B 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 16 
4d01h: PO3/1 LCP: I ECHOREP [Open] id 1 len 12 magic 0x00000002 
4d01h: PO3/1 LCP: Received id 1, sent id 1, line up 

Verbindungsabbruch

PPP kann die Verbindung jederzeit beenden. Mögliche Auslöser sind beispielsweise Carrier-Verlust, Authentifizierungsfehler, Verbindungsqualitätsfehler, Ablauf des Inaktivitäts-Timers oder das administrative Schließen der Verbindung.

LCP verwendet Terminate-Pakete, um die Verbindung zu schließen. Der Absender der Terminate-Request sollte die Verbindung trennen, nachdem er ein Terminate-Ack erhalten hat oder der Restart-Zähler abläuft. Der Empfänger einer Terminate-Request sollte warten, bis der Peer die Verbindung trennt. Die Verbindung darf nicht unterbrochen werden, bis mindestens eine Neustartzeit nach dem Senden einer Terminate-Ack vergangen ist.

LCP-Pakete beenden umfasst folgende Schlüsselfelder:

• Code: 5 für Terminierungsanfrage und 6 für Abschlussanforderung.

• Identifier: Bei der Übertragung muss das Identifikationsfeld bei jeder Änderung des Inhalts des Datenfelds und bei jedem Eingang einer gültigen Antwort für eine vorherige Anfrage geändert werden. Bei erneuten Übertragungen kann die Kennung unverändert bleiben. Beim Empfang wird das Identifikationsfeld der Abschlussanforderung in das Identifikationsfeld des Terminate-Ack-Pakets kopiert.

Das Feld Daten ist 0 oder mehr Oktette und enthält uninterpretierte Daten, die vom Absender verwendet werden sollen. Die Daten können aus einem beliebigen Binärwert bestehen. Das Ende des Felds wird durch die Länge angegeben.

Im Folgenden finden Sie ein Beispiel für die Ausgabe von Debug-ppp-Aushandlung, wenn Sie ein TERMREQ-Paket erhalten:

4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 8 
4d01h: PO3/1 LCP: I TERMREQ [Open] id 4 len 4 
4d01h: PO3/1 LCP: O TERMACK [Open] id 4 len 4 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 18 
4d01h: PO3/1 IPCP: State is Closed 
4d01h: PO3/1 PPP: Phase is TERMINATING 
4d01h: PO3/1 LCP: I CONFREQ [TERMsent] id 1 len 14 
4d01h: PO3/1 LCP:    MRU 1500 (0x010405DC) 
4d01h: PO3/1 LCP:    MagicNumber 0x00000002 (0x050600000002) 
4d01h: PO3/1 LCP: Dropping packet, state is TERMsent 

!--- While in the TERMsent state, PPP should drop all other packets. 

4d01h: PO3/1 IPCP: Remove route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to down 

Beispiel für eine Fehlerbehebungssequenz

In diesem Abschnitt wird ein Beispielszenario zur Fehlerbehebung für eine POS-Verbindung mit PPP-Kapselung beschrieben. Dabei werden folgende Konfigurationen verwendet:

interface POS1/0 
 ip address 1.1.1.6 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16 
 clock source internal

interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

Hinweis: Diese Debugging-Meldungen wurden in einer Back-to-Back-Laboreinrichtung auf zwei Routern erfasst. Daher ist die Taktgebung auf der einen Seite auf intern und auf der anderen auf line gesetzt.

Debug-ppp-Aushandlung

Diese Ausgabe veranschaulicht den Paketaustausch, der mit der Debug-PPP-Aushandlung während der Verbindungsphase des LCP erfasst wurde.

Router A Debug Output  
(1)  

!--- The router sends an outgoing confreq.

hswan-12008-2a#
*Nov  7 08:27:00: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 08:27:00: PO1/0 PPP: Treating connection as a dedicated line
*Nov  7 08:27:00: PO1/0 PPP: Phase is ESTABLISHING, Active Open
*Nov  7 08:27:00: PO1/0 LCP: O CONFREQ [Closed] id 7 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D)

(4)  

!--- Router A receives an incoming confreq from router B. 

*Nov  7 08:27:00: PO1/0 LCP: I CONFREQ [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2)

(5) 

!--- Router A responds with a confack and receives a !--- confack from Router B. The LCP state is open. 
 
*Nov  7 08:27:00: PO1/0 LCP: O CONFACK [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
*Nov  7 08:27:00: PO1/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176)
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
*Nov  7 08:27:00: PO1/0 LCP: State is Open
*Nov  7 08:27:00: PO1/0 PPP: Phase is UP

(7) 

!--- Router A begins the IPCP stage and negotiates an IP address. !--- In this setup, the peer router already has an address and !--- sends it in a confreq. If the peer router accepts the address, !--- it responds with a confack.

*Nov  7 08:27:00: PO1/0 IPCP: O CONFREQ [Closed] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFREQ [Closed] id 7 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFREQ [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 IPCP: O CONFACK [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFREQ [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFACK [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFACK [ACKsent] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 IPCP: State is Open
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFACK [ACKsent] id 7 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: State is Open
*Nov  7 08:27:00: PO1/0 IPCP: Install route to 1.1.1.5
*Nov  7 08:27:01: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS1/0, changed state to up

(2) 

!--- Router B receives an incoming confrq from Router A. 

hswan-12008-2b#
Nov  7 10:29:19.043: PO2/0 LCP: I CONFREQ [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 CDPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 PPP: Phase is TERMINATING
Nov  7 10:29:19.043: PO2/0 PPP: Phase is ESTABLISHING

(3) 

!--- Router B sends its own LCP confreq.
  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFREQ [Open] id 45 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2)

(6) 

!--- Router B responds with a confack and receives a confack from Router A. 
 
The LCP state is open.  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFACK [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: Remove route to 1.1.1.6
Nov  7 10:29:19.047: PO2/0 LCP: I CONFACK [ACKsent] id 45 len 14 
Nov  7 10:29:19.047: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.047: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
Nov  7 10:29:19.047: PO2/0 LCP: State is Open
Nov  7 10:29:19.047: PO2/0 PPP: Phase is UP

(8) 

!--- Router B also begins the IPCP stage and negotiates an IP address.
  
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFREQ [Closed] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFREQ [Closed] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFREQ [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFACK [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFREQ [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFACK [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFACK [ACKsent] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 IPCP: State is Open
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFACK [ACKsent] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: State is Open
Nov  7 10:29:19.047: PO2/0 IPCP: Install route to 1.1.1.6
*Nov  7 10:29:19.048: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS2/0, changed state to up

Debug-ppp-Paket

Diese Ausgabe veranschaulicht den mit dem Debug-ppp-Paket erfassten Paketaustausch während der Herstellung einer Verbindung. Dieser Debugger erfasst den Wert des Protokollfelds im PPP-Paket. RFC 1661 definiert das Protokollfeld als ein oder zwei Oktette. Der Wert in diesem Feld identifiziert das im Informationsfeld des Pakets gekapselte Datagramm.

Die Protokollfeldwerte im Bereich "0****" bis "3***" bezeichnen das Netzwerkschichtprotokoll bestimmter Pakete, und die Werte im Bereich "8***" bis "b***" identifizieren, falls vorhanden, Pakete, die zu den zugehörigen Netzwerksteuerungsprotokollen (NCPs) gehören. Protokollfeldwerte im Bereich "c***" bis "f***" identifizieren Pakete als Link-Layer-Control-Protokolle (z. B. LCP). Es gibt auch verschiedene anbieterspezifische Werte. Klicken Sie hier, um eine vollständige Liste der PPP-Protokollfeldwerte anzuzeigen.

(1) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 

!--- 0xC021 identifies LCP. 

*Nov  7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 
*Nov  7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 

!--- 0x8021 identifies IPCP, PPP internet protcol control protocol. 
 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 

!--- 0x8207 identifies Cisco discovery protocol control.
  
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 

!--- 0x0207 identifies Cisco Discovery Protocol (CDP). 
 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
POS1/0, changed state to up

(3) 

!--- ECHOREQand ECHOREP packets for PPP keepalives use packet type values !--- of 0xC021.
 
*Nov  7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 
*Nov  7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up

(2) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
Nov  7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 
Nov  7 12:22:16.947: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 
Nov  7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up

(4) 

!--- ECHOREQ and ECHOREP packets for PPP keepalives use packet type !--- values of 0xC021. 

Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
Nov  7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 
Nov  7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
Nov  7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up
Nov  7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16

Hinweise zur Fehlerbehebung

Eine POS-Schnittstelle mit PPP- oder HDLC-Kapselung unterstützt zwei Mechanismen, um Sie vor einem Verbindungsausfall zu warnen: Layer-2-Keepalives und SONET-Layer-Alarme. Keepalives brauchen länger, um ein Problem zu melden als die inhärente SONET-Alarmstruktur. Layer-2-Keepalives sind jedoch nützlich, da sie den Pfad von der Linecard-CPU zur Linecard-CPU überprüfen, anstatt den Frame zu Framer, wie dies bei SONET-Alarmen der Fall ist. PPP reagiert schneller auf Link-Statusänderungen, da das LCP sofort ausfällt. Im Gegensatz dazu muss die HDLC die Keepalives löschen.

Bei einer Back-to-Back-Konfiguration zwischen zwei Routern wird durch Ziehen eines der Glasfaserstränge die Layer-1-Verbindung unterbrochen, und beide POS-Schnittstellen ändern den Zustand in "Down/Down". Wenn jedoch zwei Router-POS-Schnittstellen über eine Telco-Cloud mit SONET/SDH-Geräten verbunden sind, werden Informationen zu Layer-1-Verlusten nicht an das Remote-Ende weitergeleitet. In dieser Konfiguration sind Keepalives der Mechanismus, um die Verbindung herunter zu bringen.

Betrachten Sie diese Konfiguration.

Folgendes passiert, wenn Sie den Datenstrang der Übertragungsfaser an der Verbindung von SDHb zu SDHa ziehen:

• Der Router 7507a empfängt keine Keepalives.

• Der Router 7507b erkennt Keepalives von 7507a, da die Empfangsfaser noch funktioniert. Verwenden Sie die serielle Debug-Schnittstelle, um dies zu bestätigen.

Führen Sie bei diesem Test auch den Befehl show controller pos aus, der SONET-Alarme anzeigt. Auf dem Router 7507a sollte ein Alarm-Pfadanzeigesignal (P-AIS) und auf dem 7507b ein Pfad-Remote-Fehleranzeige (P-RDI) angezeigt werden.

Loopback-Tests

Wenn die Ausgabe des Befehls show interfaces pos anzeigt, dass die serielle Leitung aktiv ist, aber das Verbindungsprotokoll ausgefallen ist, verwenden Sie Loopback-Tests, um die Ursache des Problems zu ermitteln. Führen Sie zuerst einen Test der lokalen Schleife und dann einen Remotetest durch. Informationen hierzu finden Sie unter Understanding Loopback Modes on Cisco Routers.

Hinweis: Ändern Sie die Kapselung von PPP in HDLC, wenn Sie Loopbacks verwenden. Das Leitungsprotokoll auf einer mit PPP konfigurierten Schnittstelle wird nur aktiviert, wenn alle LCP- und NCP-Sitzungen erfolgreich ausgehandelt wurden.

Leitungsprotokollstatus mit APS

Eine POS-Schnittstelle, die für das automatische Protection Switching (APS) konfiguriert ist, führt zum Abbruch des Leitungsprotokolls, wenn es sich bei der Schnittstelle um den Schutzkanal und nicht um den funktionierenden Kanal handelt. Betrachten Sie die folgende Beispieltopologie:

Diese Beispiel-Protokollausgabe wurde erfasst, nachdem die Glasfaserkabel an der POS 1/0-Schnittstelle des GSRb entfernt wurden. Beachten Sie die Änderungen des Leitungsprotokollstatus auf beiden Schnittstellen, wenn der APS-Switchover erfolgt. Beachten Sie auch die Änderungen in den OSPF-Adjacency-Zuständen (Open Shortest Path First). (Weitere Informationen finden Sie auf der Support-Seite für die APS-Technologie.)

*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: SLOS 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS2/0: APS enabling channel 
*Sep  5 17:41:46: %SONET-6-APSREMSWI: POS2/0: Remote APS status now Protect 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: APS disabling channel 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, 
changed state to down 
*Sep  5 17:41:48: %LINK-3-UPDOWN: Interface POS1/0, changed state to down 
*Sep  5 17:41:48: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS1/0 
from FULL to DOWN, Neighbor Down: Interface down or detached 
*Sep  5 17:41:56: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS2/0 
from LOADING to FULL, Loading Done 

Vermeiden Sie die Konfiguration von APS auf einer POS-Schnittstelle mit PPP-Kapselung. PPP ist von APS nicht bekannt. Wenn eine Schnittstelle aufgrund der APS-Deaktivierung aktiv/inaktiv ist, versucht PPP, die Schnittstelle zurückzusetzen und überträgt kontinuierlich PPP-Verhandlungspakete.

Deaktivieren Sie außerdem Keepalives, um unnötige Zeilenprotokollflaps zu vermeiden. Keepalives werden auf der meisten POS-Router-Hardware automatisch deaktiviert.

Eine POS-Schnittstelle der Cisco Serie 1200 im Arbeits- oder Schutzmodus von APS kann bei deaktiviertem APS in einen Ein-/Ausschaltzustand (auch mit Loopback) versetzt werden. Bei einer anderen Karte, die in denselben Steckplatz eingesetzt ist, tritt dieses Problem auf. Setzen Sie die Karte in einen neuen Steckplatz ein, um den korrekten Leitungsprotokollstatus wiederherzustellen. Dieses Problem wurde in Cisco IOS Software Release 12.0(19)S unter der Cisco Bug ID CSCdt43759 behoben (nur registrierte Kunden).

Verwenden Sie diese Schritte als Problemumgehung:

1. Konfigurieren Sie den Befehl aps protect.

2. Geben Sie den Befehl aps force 1 ein.

3. Konfigurieren Sie den Befehl no aps protect.

Bekannte Probleme

Beachten Sie diese Hinweise, wenn Sie Probleme mit dem Verbindungsprotokoll an POS-Schnittstellen beheben:

• Eine PA-POS-Schnittstelle kann fortlaufend zurückgesetzt werden, nachdem die Kapselung von PPP in HDLC geändert wurde. Dieses Problem wird in Bezug auf PA-POS in der Cisco Bug-ID CSCdk30893 (nur registrierte Kunden) gemeldet und in der Cisco Bug-ID CSCdk1877 (nur registrierte Kunden) und der Cisco Bug-ID CSC13775775775177751 7 (nur registrierte Kunden) für verschiedene Schnittstellen, die PPP- und HDLC-Kapselung unterstützen. Das Problem wird verursacht, wenn PPP nicht vollständig heruntergefahren wird, wenn die Kapselung geändert wurde.

• Eine mit HDLC-Kapselung und Keepalives konfigurierte POS-Schnittstelle wird wiederholten Schnittstellen-Flaps unterzogen, anstatt das Leitungsprotokoll zu deaktivieren, wenn Keepalives nicht vom Remote-Ende empfangen werden. Dieses Problem wurde unter Cisco Bug ID CSCdp86387 behoben (nur registrierte Kunden).

Zugehörige Informationen

• Unterstützung optischer Technologien
• Technischer Support und Dokumentation - Cisco Systems

Revisionsverlauf