Fehlerbehebung: "Line Protocol is Down" an POS-Schnittstellen

Einleitung

In diesem Dokument wird die Fehlerbehebung für eine Packet-over-SONET (POS)-Router-Schnittstelle mit dem Line-Protocol-Status "Down" beschrieben.

Neben der Unterstützung bei der Feststellung, dass das Leitungsprotokoll ausgefallen ist, werden die Befehle show und debug erläutert, mit denen das Problem bei der Kapselung von Point-to-Point Protocol (PPP) und High-Level Data Link Control (HDLC) behoben werden kann. Außerdem wird ein typisches Fehlerbehebungsszenario erläutert, das auf einer dokumentierten Übung beruht.

Den Befehl show interface pos interpretieren

Für die Zwecke des Dokuments ist die Ausgabe von show interface pos so, wie diese Ausgabe zeigt. Beachten Sie die hervorgehobenen Bereiche 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

In der Cisco IOS® Befehlsreferenz heißt es, dass der Feldstatus für das Zeilenprotokoll angibt, ob die Softwareprozesse, die das Zeilenprotokoll verarbeiten, die Leitung als verwendbar betrachten (d. h. Keepalives sind erfolgreich) oder ob sie von einem Administrator entfernt wurde.

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

• Encapsulation (Kapselung): Der Schnittstelle zugewiesene Kapselungsmethode.

• Loopback - Gibt an, ob Loopback festgelegt ist.

• keepalive: Gibt an, ob Keepalives gesetzt sind.

POS-Protokollstapel - Übersicht

In diesem Diagramm wird der Protokollstapel einer POS-Schnittstelle veranschaulicht.

POS-Schnittstellen unterstützen mehrere Kapselungen - HDLC, PPP und Frame Relay. Daher ist Packet-over-SONET eine genauere PPP-over-SONET- oder HDLC-over-SONET-Methode. In diesem Dokument wird die Frame Relay-Kapselung nicht behandelt.

PPP und HDLC sind eng miteinander verbunden und weisen folgende Merkmale auf:

• Stellen Sie eine Rahmenstruktur mit Headern und Trailern bereit. Der Trailer bietet eine Fehlerüberprüfung.

• Stellen Sie eine Frame-Abgrenzung bereit, die für einen Empfänger genau definiert, wo ein Paket und ein Frame beginnen und enden. Bei HDLC und PPP erfolgt die Rahmenabgrenzung mittels eines speziellen Interframe-Füllmusters oder Leerlaufmusters. Das Muster ist 0x7E oder 0111 1110.

• Definieren Sie eine minimale und eine maximale Paketlänge.

• Transport von IP-Paketen und Bereitstellung eines Verfahrens für Empfänger zur Bestimmung des genauen Pakettyps im ankommenden Frame

PPP und HDLC sind zwar eng miteinander verwandt, unterscheiden sich jedoch voneinander, und verschiedene Debug-Befehle werden zur Fehlerbehebung bei Problemen mit dem Leitungsprotokoll verwendet.

Debug-Befehle verwenden

Die Ausgabe verschiedener Befehle des privilegierten Debugging-EXEC-Modus liefert Diagnoseinformationen zum Protokollstatus und zur Netzwerkaktivität für viele Netzwerkinteraktionen.

Achtung: Da die Debug-Ausgabe im CPU-Prozess eine hohe Priorität erhält, kann sie das System unbrauchbar machen. Verwenden Sie daher nur zur Fehlerbehebung bei bestimmten Problemen oder während der Fehlerbehebung mit dem technischen Support von Cisco die Befehle debug. Darüber hinaus ist es am besten, Debug-Befehle in Zeiten geringen Netzwerkverkehrs und mit weniger Benutzern zu verwenden. Das Debuggen in diesen Zeiträumen verringert die Wahrscheinlichkeit, dass sich der erhöhte Aufwand für die Debugbefehlsverarbeitung auf die Systemnutzung auswirkt. Wenn Sie einen debug-Befehl fertig haben, denken Sie daran, ihn mit dem spezifischen Befehl no debug oder mit dem Befehl no debug all zu deaktivieren.

Diese Debug-Befehle sind nützlich, wenn Sie Probleme mit POS-Schnittstellen beheben möchten. Weitere Informationen zur Funktion und Ausgabe der einzelnen Befehle finden Sie in den folgenden Publikationen der Cisco Debug Command Reference:

• debug serial interface (Serielle Schnittstelle debuggen): Überprüft, ob HDLC-Keepalive-Pakete inkrementiert werden. Andernfalls liegt ein mögliches Zeitproblem auf der Schnittstellenkarte oder im Netzwerk vor.

• debug ppp negotiation - Zeigt PPP-Pakete an, die während des PPP-Starts übertragen wurden, wobei PPP-Optionen ausgehandelt werden.

• debug ppp packet: Zeigt an, wie PPP-Pakete gesendet und empfangen werden. Dieser Befehl zeigt Paketabbilder auf niedriger Ebene an.

• debug ppp errors (PPP-Fehler debuggen): Zeigt PPP-Fehler (z. B. ungültige oder falsch formatierte Frames) an, die mit der PPP-Verbindungsaushandlung und -operation verknüpft sind.

Weitere Informationen finden Sie unter Troubleshooting Serial Line Problems (Problembehebung bei seriellen Leitungen).

Das Leitungsprotokoll ist mit HDLC ausgefallen.

HDLC ist der Standardverkapselungstyp an einer POS-Router-Schnittstelle. HDLC ist ein internationaler Standard, bei Anbieterimplementierungen variiert jedoch die Größe und das Format eines oder mehrerer Felder oder des Headers oder Trailers. Die Telecordia GR-253-Spezifikation, die SONET definiert, behandelt die HDLC-over-SONET-Zuordnung (siehe Issue 3, Abschnitt 3.4.2.3, S.3-59). Es legt fest, dass der HDLC-Frame byteorientiert mit dem SONET-Frame sein soll, und gibt außerdem einen selbstsynchronisierenden Scrambler, eine zyklische Redundanzprüfung (CRC) und die Verwendung des HDLC-Flag-Musters als Interframe-Füllung an, um die variable Natur eingehender HDLC-Frames zu berücksichtigen.

Wenn der Befehl show interface pos anzeigt, dass die Leitung und das Protokoll mit HDLC-Kapselung ausgefallen sind, können Sie mit dem Befehl debug serial interface (Serielle Schnittstelle debuggen) ein Zeilenproblem als Ursache eines Verbindungsfehlers isolieren. HDLC verwendet Keepalives und meldet die Werte von drei Zählern in der Debugausgabe:

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

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

• yourseen: Gibt den Wert der myseq-Sequenznummer an, die der Router in einem Keepalive-Paket vom Remote-Router empfangen hat.

Wenn die Keepalive-Werte in den mineseq-, yourseen- und myseen-Feldern nicht in jeder nachfolgenden Ausgabezeile inkrementiert werden, liegt an einem Ende der Verbindung ein Problem vor. Wenn die Differenz zwischen den Werten in den Feldern myseq und mineseen drei überschreitet, wird die Leitung heruntergefahren und die Schnittstelle zurückgesetzt.

Dies ist eine Beispielausgabe des Befehls debug serial interface für eine HDLC-Verbindung, wenn Keepalives von beiden Seiten richtig 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 eine Beispielausgabe des Befehls debug serial interface für eine HDLC-Verbindung, wenn die Remote-Schnittstelle ausgeschaltet 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 Leitungsprotokoll ist mit PPP ausgefallen.

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

RFC 2615 legt die Verwendung der PPP-Kapselung über SONET- oder SDH-Verbindungen fest. PPP wurde für den Einsatz auf Point-to-Point-Verbindungen entwickelt und eignet sich für SONET- oder SDH-Verbindungen, die selbst in Ringtopologien als Point-to-Point-Schaltkreise bereitgestellt werden.

Beim Aufbauen einer Punkt-zu-Punkt-Verbindung durchläuft PPP mehrere verschiedene Phasen, die in einem Zustandsdiagramm gezeichnet werden können. Wenn ein externes Ereignis, wie z. B. die Carrier-Erkennung oder die Konfiguration des Netzwerkadministrators, anzeigt, dass die physische Ebene einsatzbereit ist, geht PPP zur Phase der Verbindungseinrichtung über. Ein Übergang in diese Phase erzeugt ein UP-Ereignis zum Link Control Protocol (LCP), das mehrere Funktionen bereitstellt. Eine Funktion ist die Feststellung, wann eine Verbindung ordnungsgemäß funktioniert und wann sie ausfällt. Um die Kommunikation über eine Point-to-Point-Verbindung herzustellen, muss jedes Ende der PPP-Verbindung zunächst LCP-Pakete senden, um die Datenverbindung zu konfigurieren und zu testen.

Anschließend muss PPP Netzwerksteuerungsprotokoll (Network Control Protocol, NCP)-Pakete senden, um ein oder mehrere Protokolle der Netzwerkschicht auszuwählen und zu konfigurieren. Nach der Konfiguration der einzelnen Netzwerkschichtprotokolle können Datagramme von 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 Status "LCP Open" (LCP geöffnet) wurde eingegeben, sobald ein Configure-Ack-Paket gesendet und empfangen wurde.

Diese Beispielausgabe erfasst die Konfiguration der LCP-Verbindung 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. So sehen Sie das Leitungsprotokoll kommen kurz auf einer periodischen Basis, wenn es ein anhaltendes Problem, auch wenn die Faser entfernt.

Link-Wartung (mit Keepalives)

LCP-Echo-Request- und Echo-Reply-Pakete bieten einen Layer-2-Loopback-Mechanismus für beide Verbindungsrichtungen. Beim Empfang einer Echoanforderung im LCP-Öffnungszustand muss eine Echoantwort gesendet 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-Anforderung und 10 für Echo-Antwort.

• Identifier (Kennung) - Bei der Übertragung muss das Feld Identifier (Kennung) geändert werden, wenn sich der Inhalt des Datenfelds ändert und wenn eine gültige Antwort auf eine vorherige Anfrage eingegangen ist. Bei wiederholten Übertragungen kann die Kennung unverändert bleiben. Beim Empfang wird das Kennfeld der Echo-Anforderung in das Kennfeld des Echo-Reply-Pakets kopiert.

• Magic-Number (Magische Nummer): Das Feld "Magic-Number" enthält vier Oktetts und erleichtert die Erkennung von Verbindungen, die sich im Loopback-Zustand befinden. Bis die Magic-Number-Konfigurationsoption erfolgreich ausgehandelt wurde, muss die Magic-Number als 0 (null) übertragen werden. Weitere Erläuterungen finden Sie in der Konfigurationsoption für die Magic Number (Magic-Number-Konfiguration) in RFC 1661.

• Data (Daten): Das Feld "Data" (Daten) enthält 0 (null) oder mehr Oktetts und nicht interpretierte Daten, die vom Absender verwendet werden können. Die Daten können aus einem beliebigen Binärwert bestehen. Das Ende des Felds wird durch die Länge angezeigt.

Hier ist ein Beispiel für debug ppp negotiation bei aktivierten 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 

Link-Terminierung

PPP kann die Verbindung jederzeit beenden. Mögliche Auslöser sind z. B. Verlust des Mobilfunkanbieters, Authentifizierungsfehler, Fehler bei der Verbindungsqualität, Ablauf der Inaktivitätsdauer oder administrative Schließung der Verbindung.

LCP verwendet Terminate-Pakete, um die Verbindung zu schließen. Der Absender der "Terminate-Request"-Nachricht sollte die Verbindung trennen, nachdem er ein "Terminate-Ack" erhalten hat oder der Zähler "Restart" abgelaufen ist. Der Empfänger einer Terminate-Request sollte auf das Trennen der Peer-Verbindung warten und darf die Verbindung nicht trennen, bis nach dem Senden einer Terminate-Ack mindestens eine Restart-Zeit verstrichen ist.

Terminierende LCP-Pakete enthalten die folgenden Schlüsselfelder:

• Code: 5 für "Terminate-Request" und 6 für "Terminate-Ack".

• Identifier (Kennung) - Bei der Übertragung muss das Feld Identifier (Kennung) geändert werden, wenn sich der Inhalt des Datenfelds ändert und wenn eine gültige Antwort auf eine vorherige Anfrage eingegangen ist. Bei wiederholten Übertragungen kann die Kennung unverändert bleiben. Beim Empfang wird das Identifizierungsfeld des "Terminate-Request" in das Identifizierungsfeld des "Terminate-Ack"-Pakets kopiert.

Das Datenfeld ist 0 (null) oder mehr Oktette und enthält nicht interpretierte Daten, die vom Absender verwendet werden können. Die Daten können aus einem beliebigen Binärwert bestehen. Das Ende des Felds wird durch die Länge angezeigt.

Hier sehen Sie ein Beispiel für eine Ausgabe von debug ppp negotiation, wenn Sie ein TERMREQ-Paket empfangen:

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. Folgende Konfigurationen werden 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 Fehlerbehebungen wurden auf zwei Routern in einer Back-to-Back-Laborumgebung erfasst. Daher ist die Taktgebung auf einer Seite auf "Intern" und auf der anderen Seite auf "Line" eingestellt.

debug ppp negotiation

Diese Ausgabe zeigt den Paketaustausch, der mit debug ppp negotiation während der Verbindungsherstellung 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 Paketaustausch, der mit dem debug ppp-Paket erfasst wurde, während eine Verbindung hergestellt wird. Dieses Debugging erfasst den Wert des Protokollfelds im PPP-Paket. RFC 1661 definiert das Protokollfeld als ein oder zwei Oktette. Der Wert in diesem Feld gibt das Datagramm an, das in das Informationsfeld des Pakets gekapselt ist.

Protokollfeldwerte im Bereich "0***" bis "3***" identifizieren das Netzwerkschichtprotokoll bestimmter Pakete, und Werte im Bereich "8***" bis "b***" identifizieren Pakete, die zu den zugehörigen Netzwerksteuerungsprotokollen (Network Control Protocols, NCPs) gehören, falls vorhanden. Protokollfeldwerte im Bereich "c***" bis "f***" identifizieren Pakete als Control Protocols auf Verbindungsebene (wie LCP). Es gibt auch verschiedene anbieterspezifische Werte. Klicken Sie hier, um eine vollständige Liste der PPP-Protokollfeldwerteanzuzeigen.

(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 auf einen Verbindungsausfall hinzuweisen: Layer-2-Keepalive und SONET-Layer-Alarme Keepalives benötigen mehr Zeit, 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 und nicht, wie bei SONET-Alarmen, den Pfad von einem Frame zum anderen. PPP reagiert schneller auf Verbindungsstatusänderungen, da das LCP sofort ausfällt. Im Gegensatz dazu muss HDLC die Keepalives zeitlich aussetzen.

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

Berücksichtigen Sie diese Konfiguration.

Folgendes geschieht, wenn Sie den Übertragungs-Glasfaserstrang auf der Verbindung von SDHb nach SDHa ziehen:

• Router 7507a empfängt keine Keepalives.

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

Wenn Sie diesen Test durchführen, können Sie auch den Befehl show controller pos ausführen, der SONET-Alarme anzeigt. Auf dem Router 7507a sollte ein Warnsignal für den Pfad (P-AIS) und auf dem 7507b ein Warnsignal für den Pfad (P-RDI) angezeigt werden.

Loopback-Tests

Wenn die Ausgabe des Befehls show interfaces pos anzeigt, dass die serielle Leitung aktiv ist, das Leitungsprotokoll jedoch nicht verfügbar ist, verwenden Sie Loopback-Tests, um die Ursache des Problems zu ermitteln. Führen Sie zuerst einen Test der lokalen Schleife und dann einen Remote-Test durch. Weitere Informationen finden Sie unter Understanding Loopback Modes on Cisco Routers (Verstehen der Loopback-Modi auf Cisco Routern).

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

Status des Leitungsprotokolls mit APS

Eine für automatisches Protection Switching (APS) konfigurierte POS-Schnittstelle deaktiviert das Leitungsprotokoll, wenn es sich bei der Schnittstelle um den Schutzkanal und nicht um den funktionierenden Kanal handelt. Betrachten Sie diese Beispieltopologie:

Diese Protokollausgabe wurde erfasst, nachdem die Glasfaserverkabelung an der POS 1/0-Schnittstelle von GSRb entfernt wurde. Beachten Sie die Änderungen des Line-Protocol-Status an beiden Schnittstellen, wenn der APS-Switchover stattfindet. Beachten Sie auch die Änderungen der OSPF-Adjacency-Zustände (Open Shortest Path First). (Weitere Informationen finden Sie auf der Support-Seite für 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 kennt APS nicht. Wenn eine Schnittstelle aufgrund der APS-Deaktivierung aktiv/inaktiv ist, versucht PPP, die Schnittstelle zurückzusetzen, und sendet kontinuierlich PPP-Aushandlungspakete.

Deaktivieren Sie Keepalives, um unnötige Zeilenprotokoll-Flaps zu vermeiden. Keepalives sind auf den meisten POS-Router-Hardware automatisch deaktiviert.

Eine POS-Schnittstelle der Cisco Serie 12000 im APS-Betriebs- oder Schutzmodus kann bei deaktiviertem APS in einem Hoch-/Herunterzustand (selbst bei Loopback) hängen bleiben. Dieses Problem tritt bei einer anderen Karte auf, die in denselben Steckplatz eingesetzt ist. Setzen Sie die Karte in einen neuen Steckplatz ein, um den korrekten Status des Leitungsprotokolls wiederherzustellen. Dieses Problem wurde in Version 12.0(19)S der Cisco IOS-Software unter der Cisco Bug-ID CSCdt43759 (nur registrierte Kunden) behoben.

Verwenden Sie diese Schritte als Problemumgehung:

1. Konfigurieren Sie den Befehl aps protect.

2. Führen Sie den Befehl aps force 1 aus.

3. Konfigurieren Sie den Befehl no aps protect.

Bekannte Probleme

Beachten Sie die folgenden Hinweise, wenn Sie Probleme mit Leitungsprotokollen bei POS-Schnittstellen beheben:

• Eine PA-POS-Schnittstelle wird möglicherweise kontinuierlich zurückgesetzt, nachdem die Kapselung von PPP in HDLC geändert wurde. Dieses Problem wird für den PA-POS in Cisco Bug-ID CSCdk30893 (nur registrierte Kunden) gemeldet und in Cisco Bug-ID CSCdk18777 (nur registrierte Kunden) und Cisco Bug-ID CSCdk13757 () nur für 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 durchläuft wiederholte Schnittstellen-Flaps, anstatt das Leitungsprotokoll zu deaktivieren, wenn Keepalives nicht vom Remote-Ende empfangen werden. Dieses Problem wurde mit der Cisco Bug-ID CSCdp86387 behoben (nur für registrierte Kunden).

Zugehörige Informationen

• Optische Technologie-Unterstützung
• Technischer Support und Dokumentation für Cisco Systeme