Problemen met "Line Protocol is Down" op POS-interfaces oplossen

Inleiding

Dit document beschrijft hoe u problemen kunt oplossen met een Packet-over-SONET (POS) routerinterface die de status van een lijnprotocol van "Down" heeft.

Naast het helpen om te identificeren dat het lijnprotocol neer is, verklaart het de show en debug bevelen om te gebruiken om de kwestie voor zowel Point-to-Point Protocol (PPP) als inkapseling op hoog niveau van de datalink controle (HDLC) problemen op te lossen. Het leidt u ook door een typisch die het oplossen van probleemscenario op een gedocumenteerde laboratoriumopstelling wordt gebaseerd.

Interpreteer de show interface pos Command

Ten behoeve van het document, is de output van show interface pos zoals deze output toont. Let op de gemarkeerde delen van het display en de opmerkingen:

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

De referentie voor Cisco IOS^® Command zegt dat de veldstatus van het lijnprotocol "aangeeft of de softwareprocessen die het lijnprotocol behandelen als de bruikbare regel moeten worden beschouwd (dat wil zeggen, keepalives zijn succesvol) of dat de regel door een beheerder is uitgeschakeld."

Andere belangrijke velden in de show interface pos output zijn:

• De insluiting-insluiting methode die aan de interface is toegewezen.

• loopback—Geeft aan of loopback is ingesteld.

• keepalive-wijst erop of keepalives worden geplaatst.

POS-protocolstack - Overzicht

Dit diagram illustreert de protocolstack die op een POS-interface wordt gebruikt.

POS-interfaces ondersteunen meerdere insluitingen - HDLC, PPP en Frame Relay. Packet-over-SONET is dus nauwkeuriger PPP over SONET of HDLC over SONET. Dit document heeft geen betrekking op Frame Relay-insluiting.

PPP en HDLC zijn nauw verwant en delen deze kenmerken:

• Zorg voor een framingstructuur met kopregels en aanhangwagens. De trailer biedt foutcontrole.

• Verstrek kaderafbakening, die voor een ontvanger precies bepaalt waar een pakket en een kader beginnen en beëindigen. In HDLC en PPP, wordt de kaderafbakening verstrekt door middel van een speciaal interframe vulpatroon of nutteloos patroon. Het patroon is 0x7E, of 0111 110.

• Definieer een minimum- en maximumpakketlengte.

• IP-pakketten transporteren en een methode bieden voor ontvangers om het precieze type pakket binnen het aankomende frame te bepalen.

Hoewel nauw verwant, zijn PPP en HDLC niet hetzelfde, en verschillende debug commando's worden gebruikt om problemen met het lijnprotocol op te lossen.

Gebruik debug commando's

De output van divers debug bevoorrechte EXEC-opdrachten biedt diagnostische informatie met betrekking tot protocolstatus en netwerkactiviteit voor vele internetwerkgebeurtenissen.

Waarschuwing: omdat aan debugging van uitvoer een hoge prioriteit wordt toegekend in het CPU-proces, kan het systeem onbruikbaar worden. Om deze reden kunt u debug-opdrachten alleen gebruiken om specifieke problemen op te lossen of tijdens probleemoplossingssessies met de technische ondersteuning van Cisco. Bovendien is het het beste om debug commando's te gebruiken tijdens perioden met weinig netwerkverkeer en minder gebruikers. Het zuiveren tijdens deze periodes vermindert de waarschijnlijkheid dat de verhoogde debug bevel verwerking overheadkosten systeemgebruik beïnvloedt. Wanneer u klaar bent met het gebruiken van een debug opdracht, vergeet niet om het uit te schakelen met zijn specifieke no debug opdracht of met no debug all commando.

Deze debug opdrachten zijn handig voor wanneer u problemen met de POS-interface oplossen. Meer informatie over de functie en de uitvoer van elk van deze opdrachten wordt gegeven in de publicaties van de Cisco Debug Command Reference:

• debug seriële interface-verifieert of HDLC keepalive-pakketten aan het toenemen zijn. Als zij niet zijn, bestaat een mogelijk timingsprobleem op de interfacekaart of in het netwerk.

• debug ppp onderhandeling-toont PPP-pakketten die tijdens PPP-opstarten worden verzonden, waar PPP-opties worden onderhandeld.

• debug ppp-pakket—Toont PPP-pakketten die worden verzonden en ontvangen. Deze opdracht geeft pakketstortplaatsen op laag niveau weer.

• debug ppp fouten-toont PPP fouten (zoals illegale of misvormde frames) geassocieerd met PPP-verbindingsonderhandeling en -bewerking.

Raadpleeg Problemen met seriële lijnen oplossen voor meer informatie.

Het protocol van de lijn is neer met HDLC

HDLC is het standaard inkapselingstype op een POS router interface. HDLC is een internationale standaard, maar leverancier implementaties variëren een of meer velden of de header of trailer in grootte en formaat. De Telecordia GR-253 specificatie die SONET definieert, bespreekt HDLC-over-SONET mapping (zie editie 3, paragraaf 3.4.2.3, blz. 3-59). Het geeft aan dat het HDLC frame byte-uitgelijnd is met het SONET frame, en specificeert ook een zelfsynchroniserende scrambler, een cyclische redundantiecontrole (CRC) en het gebruik van het HDLC-vlagpatroon als de interframe vulling om rekening te houden met de variabele aard van aankomende HDLC-frames.

Als de opdracht show interface pos aantoont dat de lijn en het protocol met HDLC-insluiting zijn uitgeschakeld, kunt u de debug seriële interface-opdracht gebruiken om een lijnprobleem als oorzaak van een verbindingsfout te isoleren. HDLC gebruikt keepalives en rapporteert de waarden van drie tellers in de debug uitvoer:

• myseq—Verhoogt met één telkens als de router een keepalive pakket naar de verre router verzendt.

• mineseen-waarde van de mineseen-teller weerspiegelt het laatste myseq volgnummer de verre router het ontvangen van de router heeft erkend. De externe router slaat deze waarde op in zijn yourseen teller en stuurt die waarde in een keepalive-pakket naar de router.

• yourseen-reflecteert de waarde van het myseq volgnummer dat de router heeft ontvangen in een keepalive pakket van de externe router.

Als de keepalive waarden in mineseq, yourseen, en myseen velden niet groeien in elke volgende lijn van output, is er een probleem aan de ene kant van de verbinding. Wanneer het verschil in de waarden in de myseq- en mijnenvelden groter is dan drie, gaat de lijn omlaag en wordt de interface opnieuw ingesteld.

Dit is voorbeelduitvoer van de debug seriële interface opdracht voor een HDLC verbinding wanneer keepalives goed worden ontvangen door beide einden.

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. 

Dit is voorbeelduitvoer van de debug seriële interfaceopdracht voor een HDLC-verbinding wanneer de externe interface is gesloten en de lokale interface meer dan drie keepalives mist.

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.
 

Het lijnprotocol is neer met PPP

RFC 1661 definieert PPP als een protocol. POS-interfaces ondersteunen PPP in High-Level Data Link Control (HDLC)-achtige framing, zoals gespecificeerd in RFC 1662, voor gegevensinkapseling op Layer 2. Het frameformaat voor PPP in HDLC-achtige framing wordt in dit getal weergegeven.

RFC 2615 specificeert het gebruik van PPP-insluiting via SONET- of SDH-koppelingen. PPP is ontworpen voor gebruik op point-to-point links en is geschikt voor SONET- of SDH-links, die worden geleverd als point-to-point circuits, zelfs in ringtopologieën.

Wanneer het omhoog brengen van een punt om verbinding te richten, gaat PPP door verscheidene verschillende fasen die in een staatsdiagram kunnen worden getrokken. Wanneer een externe gebeurtenis, zoals de configuratie van de dragerdetectie of van de netwerkbeheerder, erop wijst dat de fysieke laag klaar om is worden gebruikt, gaat PPP op de fase van de verbindingsonderneming voort. Een overgang naar deze fase produceert een UP-gebeurtenis naar het Link Control Protocol (LCP), dat verschillende functies biedt. Eén functie is de bepaling wanneer een verbinding naar behoren functioneert en wanneer deze faalt. Om de communicatie via een point-to-point link tot stand te brengen, moet elk uiteinde van de PPP-link eerst LCP-pakketten verzenden om de datalink te configureren en te testen.

Dan, moet PPP pakketten verzenden van Network Control Protocol (NCP) om één of meerdere netwerklaagprotocollen te kiezen en te configureren. Zodra elk van de gekozen netwerklaagprotocollen is geconfigureerd, kunnen datagrammen van elk netwerklaagprotocol via de link worden verzonden.

Deze tabel toont de drie klassen van LCP-pakketten:

Koppelingsconfiguratie

LCP wordt gebruikt om de verbinding door een uitwisseling van Configure pakketten te vestigen. Deze uitwisseling is voltooid en de status LCP Opened is ingevoerd nadat een Configuration-Ack-pakket is verzonden en ontvangen.

Deze voorbeelduitvoer legt de LCP-linkconfiguratiefase op een POS-interface vast:

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 

Opmerking: een POS-interface die geconfigureerd is met PPP-insluiting probeert voortdurend een PPP-sessie te starten. Aldus, ziet u het lijnprotocol kort op een periodieke basis komen wanneer er een aanhoudend probleem is, zelfs wanneer de vezel wordt verwijderd.

Link-onderhoud (met keepalives)

LCP Echo-Verzoek en Echo-Antwoord de pakketten verstrekken een Layer 2 loopbackmechanisme voor beide richtingen van de verbinding. Bij ontvangst van een Echo-Verzoek in de staat LCP Opened moet een Echo-Antwoord worden verzonden.

Dit diagram van RFC 1661 illustreert het formaat van een PPP keepalive-pakket.

Deze LCP-pakketten omvatten deze belangrijke velden:

• Code—9 voor Echo-Verzoek en 10 voor Echo-Antwoord.

• Identificator-bij-doorgifte moet het veld Identificator worden gewijzigd telkens wanneer de inhoud van het gegevensveld verandert en telkens wanneer een geldig antwoord voor een eerder verzoek is ontvangen. Voor heruitzendingen kan de identificatiecode ongewijzigd blijven. Bij ontvangst wordt het veld Identifier van het Echo-request gekopieerd naar het veld Identifier van het Echo-Response-pakket.

• Het veld Magic-Number is vier octetten en helpt bij de detectie van links die zich in de herleide toestand bevinden. Totdat de Magic-Number Configuration-optie met succes is overeengekomen, moet het Magic-Number als nul worden verzonden. Zie de configuratieoptie magisch-nummer in RFC 1661 voor meer informatie.

• Gegevens—Het veld Gegevens is nul of meer octetten en bevat niet-geïnterpreteerde gegevens voor gebruik door de afzender. De gegevens kunnen uit om het even welke binaire waarde bestaan. Het einde van het veld wordt aangegeven door de lengte.

Hier is een voorbeeld van debug ppp-onderhandeling wanneer keepalives zijn ingeschakeld:

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-beëindiging

PPP kan de link op elk moment beëindigen. Mogelijke triggers zijn verlies van de drager, authenticatiefout, link quality failure, het verlopen van de periode inactief timer of het administratief sluiten van de link.

LCP gebruikt Eindpakketten om de link te sluiten. De verzender van de Terminate-request dient de verbinding te verbreken na ontvangst van een Terminate-Ack, of nadat de Herstart-teller verloopt. De ontvanger van een Terminate-request moet wachten tot de peer de verbinding verbreekt en mag de verbinding niet verbreken tot ten minste één herstarttijd is verstreken na het verzenden van een Terminate-Ack.

Afsluitend LCP-pakketten omvatten deze belangrijke velden:

• Code—5 voor Terminate-request en 6 voor Terminate-Ack.

• Identifier—Bij verzending moet het veld Identifier worden gewijzigd telkens wanneer de inhoud van het gegevensveld verandert en telkens wanneer een geldig antwoord is ontvangen voor een eerder verzoek. Voor heruitzendingen kan het identificatiekenmerk ongewijzigd blijven. Bij ontvangst wordt het veld Identifier van het Terminate-request gekopieerd naar het Identifier-veld van het Terminate-Ack-pakket.

Het veld Gegevens is nul of meer octetten en bevat niet-geïnterpreteerde gegevens voor gebruik door de afzender. De gegevens kunnen uit om het even welke binaire waarde bestaan. Het einde van het veld wordt aangegeven door de lengte.

Hier is een voorbeeld van debug ppp onderhandelingsoutput wanneer u een pakket TERMREQ ontvangt:

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 

Probleemoplossing als voorbeeld

Deze sectie beschrijft een voorbeeld van een probleemoplossing scenario voor een POS-link met behulp van PPP-insluiting. Het gebruikt deze configuraties:

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

Opmerking: deze debugs zijn opgenomen op twee routers in een back-to-back lab setup. Aldus, het klokken wordt geplaatst aan intern op één kant en aan gebrek aan lijn op het andere eind.

debug ppp-onderhandeling

Deze output illustreert de pakketuitwisseling die met debug ppp-onderhandeling is opgenomen tijdens de fase van de linkinstelling in LCP.

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-pakket

Deze output illustreert de pakketuitwisseling die met debug ppp-pakket is opgenomen terwijl een link wordt tot stand gebracht. Met deze debug wordt de waarde van het protocolveld in het PPP-pakket opgenomen. RFC 1661 definieert het protocolveld als een of twee octetten. De waarde in dit veld identificeert het datagram dat is ingesloten in het veld Informatie van het pakket.

De protocolveldwaarden in het bereik "0***" tot "3***" identificeren het netwerklaagprotocol van specifieke pakketten, en de waarden in het bereik "8***" tot "b***" identificeren pakketten die behoren tot de gekoppelde Network Control Protocols (NCP’s), indien van toepassing. De protocolveldwaarden in het bereik "c***" tot "f***" identificeren pakketten als link-layer Control Protocols (zoals LCP). Er zijn ook verschillende leverancierspecifieke waarden. Klik hier voor een volledige lijst met PPP-protocolveldwaarden.

(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

Opmerkingen over probleemoplossing

Een POS-interface met PPP- of HDLC-insluiting ondersteunt twee mechanismen om u te waarschuwen voor een koppelingsfout: Layer 2-handleidingen en SONET-laagalarmen. Keepalives duurt langer om een probleem te melden dan de inherente SONET alarmstructuur. Layer 2-keepalives zijn echter nuttig omdat ze het pad controleren van lijnkaart CPU naar lijnkaart CPU, in plaats van framer naar framer zoals alarmen op SONET-niveau. PPP reageert sneller op wijzigingen in de koppelingsstatus omdat LCP onmiddellijk omlaag komt. In tegenstelling, moet HDLC uit de keepalives.

In een back-to-back configuratie tussen twee routers, breekt het trekken van één van de vezelstrengen Layer 1 connectiviteit, en beide POS interfaces veranderen staat in down/down. Wanneer echter twee router POS-interfaces verbinding maken via een Telco-cloud met SONET/SDH-apparatuur, wordt Layer 1-verliesinformatie niet doorgegeven naar het externe einde. In deze configuratie, zijn keepalives het mechanisme om de verbinding neer te halen.

Denk aan deze instelling.

Dit gebeurt er als u de zendervezeldraad op de link van SDHb naar SDHa trekt:

• Router 7507a ontvangt geen keepalives.

• Router 7507b ziet keepalives van 7507a omdat de ontvangstvezel nog werkt. Gebruik debug seriële interface om dit te bevestigen.

Afwisselend, wanneer het uitvoeren van deze test, voer het bevel van de show controlemechanisme pos uit, dat SONET alarmen toont. U moet een padalarmsignaal (P-AIS) zien op router 7507a en een pad afstandsindicatie van defecten (P-RDI) op 7507b.

Loopback-tests

Als de output van de show interfaces pos bevel erop wijst dat de seriële lijn omhoog is maar het lijnprotocol neer is, gebruik loopback tests om de bron van het probleem te bepalen. Voer eerst een lokale-lustest en vervolgens een test op afstand uit. Raadpleeg Inzicht in backmodi op Cisco-routers voor richtlijnen.

Opmerking: Verander de inkapseling van PPP naar HDLC wanneer u loopbacks gebruikt. Het lijnprotocol op een interface die met PPP is geconfigureerd, wordt alleen beschikbaar als alle LCP- en NCP-sessies succesvol worden besproken.

Lijnprotocolstatus met SAP

Een POS-interface geconfigureerd voor automatische beschermingsswitching (APS) verlaagt het lijnprotocol als de interface het beveiligingskanaal is en niet het werkkanaal. Overweeg deze steekproeftopologie:

Deze voorbeeldlogoutput werd opgenomen nadat de vezelbekabeling op de POS 1/0-interface van GSRb was verwijderd. Let op de veranderingen in de status van het lijnprotocol op beide interfaces wanneer de APS-overschakeling plaatsvindt. Let ook op de veranderingen in open kortste weg eerste (OSPF) nabijheidsstaten. (Raadpleeg de pagina voor JBS-ondersteuning voor meer informatie.)

*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 

Vermijd het configureren van APS op een POS-interface met PPP-insluiting. PPP is niet bekend met APS. Als een interface omhoog/omlaag is vanwege APS-deselectie, probeert PPP de interface te herstellen en verzendt continu PPP-onderhandelingspakketten.

Schakel bovendien keepalives uit om onnodige regelprotocolflappen te voorkomen. Keepalives zijn automatisch uitgeschakeld op de meeste POS router hardware.

Een Cisco 12000 Series POS-interface in de APS-werkmodus of de beschermingsmodus kan vastlopen in een up/down-modus (zelfs met een loopback) wanneer de APS is uitgeschakeld. Een andere kaart in dezelfde sleuf ervaart dit probleem. Verplaats de kaart naar een nieuwe sleuf om de juiste lijnprotocolstatus te herstellen. Dit probleem wordt opgelost in Cisco IOS-softwarerelease 12.0(19)S onder Cisco bug-id CSC43759 (alleen geregistreerde klanten).

Gebruik deze stappen als tijdelijke oplossing:

1. Configureer de opdracht Aspen beveiligen.

2. Geef het AP force 1 commando af.

3. Configureer de opdracht Geen toewijzingen beveiligen.

Bekende problemen

Neem nota van deze voorbehouden wanneer u problemen met het lijnprotocol met POS interfaces problemen oplost:

• Een PA-POS interface kan continu opnieuw worden ingesteld nadat de inkapseling is gewijzigd van PPP in HDLC. Dit probleem wordt gemeld tegen de PA-POS in Cisco bug-id CSCdk30893 (alleen geregistreerde klanten) en opgelost in Cisco bug-id CSCdk1877 (alleen geregistreerde klanten) en Cisco bug-id CSCdk13757 (alleen geregistreerde klanten) voor verschillende interfaces die PPP- en HDLC-insluiting ondersteunen. Het probleem wordt veroorzaakt wanneer PPP niet volledig wordt gesloten toen de inkapseling werd veranderd.

• Een POS-interface geconfigureerd met HDLC-insluiting en keepalives ondergaat herhaalde interfaceklaps in plaats van het lijnprotocol omlaag te halen wanneer keepalives niet worden ontvangen van het eindpunt op afstand. Dit probleem wordt opgelost in Cisco bug-id CSCdp86387 (alleen geregistreerde klanten).

Gerelateerde informatie

• Ondersteuning voor optische technologie
• Technische ondersteuning en documentatie – Cisco Systems