Problemen oplossen bij "Line Protocol is Down"-problemen op POS-interfaces

Downloadopties

  • PDF     (247.9 KB)
    Met Adobe Reader op diverse apparaten bekijken
  • ePub     (108.9 KB)
    Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
  • Mobi (Kindle)     (153.7 KB)
    Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken
Bijgewerkt:19 mei 2006
Document-id:16152

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inleiding

Dit document beschrijft hoe u een pakket-over-SONET (POS) router-interface (Packet-over-SONET) kunt oplossen die een status van een lijnprotocol van "Down" heeft.

Naast het helpen om te identificeren dat het lijnprotocol omlaag is, verklaart het de show en debug opdrachten om te gebruiken om de kwestie voor zowel Point-to-Point Protocol (PPP) als de controle van het hoge niveau van de datalink (HDLC) insluiting te oplossen. Het loopt u ook door een typisch scenario van het opsporen en verhelpen van problemen gebaseerd op een gedocumenteerd lab opstelling.

Tolk de opdracht van de tonen interfacepunten

Ten behoeve van het document is de uitvoer van de interface-pos van de show zoals deze uitvoer toont. Let op de gemarkeerde onderdelen 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 van Cisco IOS® bepaalt dat de status van het lijnprotocol "aangeeft of de softwareprocessen die het lijnprotocol behandelen de lijn bruikbaar (dat wil zeggen, keepalives succesvol zijn) of of door een beheerder zijn neergehaald."

Andere belangrijke velden in de show interface pos output zijn:

  • Insluiting-insluitingsmethode die aan de interface is toegewezen.

  • loopback—Geeft aan of de loopback is ingesteld.

  • Duidt op het instellen van de keepalives.

POS-protocoloverzicht

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

gspos_a0.gif

POS-interfaces ondersteunen meerdere indelingen - 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 met elkaar verbonden en delen deze kenmerken:

  • Zorg voor een oploopstructuur met koppen en aanhangwagens. De aanhangwagen bevat foutcontrole.

  • Geef een kaderafbakening op, die voor een ontvanger precies definieert waar een pakket en kader beginnen en eindigen. In HDLC en PPP, wordt de kaderafbakening verschaft door middel van een speciaal vulpatroon met interframe of een leeg patroon. Het patroon is 0x7E, of 0111 110.

  • Bepaal een minimum en maximum pakketlengte.

  • IP-pakketten transport en een methode voor ontvangers om het nauwkeurige type van pakket in het aankomende frame te bepalen.

Hoewel nauw verwant, zijn PPP en HDLC echter niet het zelfde, en verschillende debug opdrachten worden gebruikt om de problemen van het lijnprotocol van de oplossing aan te pakken.

Opdrachten debug gebruiken

De output van verschillende debug bevoorrechte EXEC opdrachten verstrekt diagnostische informatie met betrekking tot de status van een protocol en netwerkactiviteit voor veel internet-workgebeurtenissen.

caution Waarschuwing: aangezien het debuggen uitvoer wordt toegewezen aan een hoge prioriteit in het CPU-proces, kan dit het systeem onbruikbaar maken. Om deze reden, gebruik de opdrachten debug alleen om specifieke problemen op te lossen of tijdens sessies met technische ondersteuning van Cisco. Bovendien, is het best om te gebruiken debug bevelen tijdens periodes van laag netwerkverkeer en minder gebruikers. Het breken tijdens deze periodes vermindert de waarschijnlijkheid dat de vergrote overhead van de bevelverwerking debug systeemgebruik beïnvloedt. Als u een debug-opdracht hebt gebruikt, vergeet dan deze uit te schakelen met de specifieke opdracht no debug of met de opdracht no debug all.

Deze debug opdrachten zijn handig voor het geval u problemen met de POS-interface oplost. Meer informatie over de functie en output van elk van deze opdrachten wordt gegeven in de publicaties van Cisco Debug Opdracht Referentie:

  • debug seriële interface-verifieert of de pakketten met de bedrijfsvoering van HDLC steeds beter worden. Als dit niet het geval is, bestaat er een mogelijk tijdprobleem op de interfacekaart of in het netwerk.

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

  • bug van het pakje PPP-toont PPP-pakketten die worden verzonden en ontvangen. Deze opdracht geeft pakjes op een laag niveau weer.

  • bug van PPP fouten-toont PPP fouten (zoals illegale of misvormde frames) die bij PPP-verbindingsonderhandeling en -handeling zijn geassocieerd.

Raadpleeg Problemen oplossen bij seriële lijnproblemen voor meer informatie.

Het lijnprotocol is gesloten met DLC

HDLC is het standaard insluitingstype op een POS-routerinterface. HDLC is een internationale standaard, maar de implementaties van leveranciers variëren één of meer velden of de kop of aanhangwagen in grootte en formaat. In de specificatie Telecordia GR-253, die SONET definieert, wordt de toewijzing van HDLC-over-SONET besproken (zie punt 3, punt 3.4.2.3, blz. 3-59). Het specificeert dat het HDLC-frame byte-uitgelijnd is op het SONET-frame en ook een zichzelf-synchroniserende scrambler specificeert, een cyclische redundantie-controle (CRC) en het gebruik van het HDLC-vlaggenpatroon als de interframe-vulling om rekening te houden met de variabele aard van aankomende HDLC-frames.

Als de opdracht Show interface pos toont dat de lijn en het protocol met HDLC insluiting zijn, 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-stijgt met één elke keer dat de router een keeplevend pakket naar de afstandsrouter stuurt.

  • mineseen-waarde van de minesentieteller reflecteert het laatste myseq sequentienummer de verre router heeft erkend dat van de router ontvangt. De afstandsrouter slaat deze waarde op in zijn teller en stuurt die waarde in een keeplevend pakket naar de router.

  • uw-weerspiegelt de waarde van het myseq opeenvolgingsnummer de router in een keeplevend pakket van de verre router heeft ontvangen.

Als de waarden die in mineseq blijven overeind blijven, worden je gezien en de myseen velden niet bij elke daaropvolgende productielijn hoger, is er aan één kant van de verbinding een probleem. Wanneer het verschil in de waarden in de mijnenvelden en in de mijnenvelden drie groter is, gaat de lijn omlaag en wordt de interface gereset.

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

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 een voorbeelduitvoer van de optie seriële interface definiëren voor een HDLC-verbinding wanneer de externe interface wordt uitgeschakeld 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 niet compatibel met PPP

RFC 1661 leaving cisco.com definieert PPP als een protocol. POS-interfaces ondersteunen PPP in HDLC-achtig framing (High-Level Data Link Control), zoals gespecificeerd in RFC 1662 leaving cisco.com, voor gegevensinsluiting op Layer 2. Het frame-formaat voor PPP in een HDLC-achtig framing wordt in deze afbeelding weergegeven.

gspos_a2.gif

RFC 2615 specificeert het gebruik van PPP encapsulation over SONET of SDH-links. PPP werd ontworpen voor gebruik op point-to-point links en is geschikt voor SONET of SDH links, die als point-to-point circuits worden aangeboden zelfs in ring topologieën.

Wanneer u een point-to-point link maakt, gaat PPP door verschillende fasen die in een staatsdiagram kunnen worden getekend. Wanneer een externe gebeurtenis, zoals de detectie van dragers of de configuratie van de netwerkbeheerder, aangeeft dat de fysieke laag klaar is om te worden gebruikt, gaat PPP naar de fase van de verbindingsinrichting. Een overgang naar deze fase veroorzaakt een UP-gebeurtenis naar het protocol voor link control (LCP), dat verschillende functies biedt. Eén functie is het bepalen wanneer een link goed functioneert en wanneer het faalt. Om communicatie over een point-to-point link in te stellen, moet elk einde van de PPP-link eerst LCP-pakketten verzenden om de datalink te configureren en testen.

Vervolgens moet PPP netwerkbeheerprotocol (NCP)-pakketten verzenden om een of meer netwerklaagprotocollen te kiezen en te configureren. Zodra elk van de gekozen netwerk-laag protocollen is geconfigureerd kunnen datagrammen uit elk protocol op de netwerklaag via de link worden verzonden.

Deze tabel toont de drie klassen LCP-pakketten:

LCP-pakketklasse LCP-pakkettypen doel
Link-configuratie Aanvragen, configuratie-aak, Nak configureren en neerzetten Gebruikt om een link in te stellen en te configureren.
Link-beëindiging Terminalaanvraag en -aansluiting Gebruikt om een link te beëindigen.
Koppelonderhoud Codetabel, protocol-afkeuring, echo-aanvraag, echo-antwoord en aanvraag tot verwijdering Gebruikt om een link te beheren en te zuiveren.

Link-configuratie

LCP wordt gebruikt om de verbinding tot stand te brengen door een uitwisseling van pakketten configureren. Deze uitwisseling is voltooid, en de LCP Geopende staat ging binnen, zodra een pakket Configure-Ack werd verzonden en ontvangen.

Deze voorbeelduitvoer neemt het stadium van de LCP-netwerkconfiguratie op een POS-interface op:

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 met PPP-insluiting wordt geconfigureerd, probeert voortdurend een PPP-sessie te opzetten. Het lijnprotocol komt dus op gezette tijden kort aan de orde wanneer er een duurzaam probleem is, zelfs wanneer de vezel wordt verwijderd.

Link-onderhoud (met Keepalives)

LCP Echo-Application en Echo-reactie pakketten bieden een Layer 2 loopback mechanisme in beide richtingen van de link. Na ontvangst van een echo-verzoek in de geopende toestand van de LCP moet een echo-antwoord worden verstuurd.

Dit diagram van RFC 1661 illustreert het formaat van een PPP keeplevingspakket.

16152a.gif

Deze LCP-pakketten bevatten deze belangrijke velden:

  • Code-9 voor Echo-aanvraag en 10 voor Echo-antwoord.

  • Identificatiecode: Bij verzending moet het veld Identifier worden gewijzigd wanneer de inhoud van het veld Gegevens verandert en wanneer een geldig antwoord voor een eerder verzoek is ontvangen. Voor terugzendingen kan de identificator ongewijzigd blijven. Na ontvangst wordt het veld Identifier van de Echo-aanvraag gekopieerd naar het veld Identifier van het pakket Echo-reacties.

  • Magic-Number-Het veld Magic-Number is vier octetten, en hulp bij het detecteren van verbindingen die in de achterwaartse conditie zijn. Totdat de optie Magic-Number Configuration met succes is overeengekomen, moet het Magic-Number als nul worden verzonden. Zie de Magic-Number Configuration optie in RFC 1661 voor nadere uitleg.

  • Data-Het veld Gegevens is 0 of meer octetten, en bevat niet-geïnterpreteerde gegevens voor gebruik door de zender. De gegevens kunnen uit elke binaire waarde bestaan. Het uiteinde van het veld wordt aangegeven door de lengte.

Hier is een voorbeeld van debug ppp onderhandeling wanneer de keepalives zijn geactiveerd:

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 drager, mislukking van authenticatie, gebrek aan link, het verlopen van de ongebruikte tijdspanne of het administratief afsluiten van de link.

LCP gebruikt Terminate pakketten om de link te sluiten. De afzender van de Terminate-Aanvraag zou moeten loskoppelen na het ontvangen van een Terminate-Ack, of nadat de Teller van het Herstart verstrijkt. De ontvanger van een Terminate-request moet wachten tot de peer wordt losgekoppeld, en moet niet loskoppelen totdat ten minste één herstarttijd is verstreken na het verzenden van een Terminate-Ack.

16152a.gif

Beëindiging van LCP-pakketten bevat deze belangrijke velden:

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

  • Identifier-On transmissie, moet het veld Identifier worden gewijzigd wanneer de inhoud van het veld Gegevens verandert, en wanneer een geldig antwoord voor een eerder verzoek is ontvangen. Voor terugzendingen kan de Identifier ongewijzigd blijven. Na ontvangst wordt het veld Identifier van de Terminate-aanvraag gekopieerd naar het veld Identifier van het pakket Terminate-Ack.

Het veld Gegevens is 0 of meer octetten en bevat niet-geinterpreteerde gegevens voor gebruik door de zender. De gegevens kunnen uit elke binaire waarde bestaan. Het uiteinde van het veld wordt aangegeven door de lengte.

Hier is een voorbeeld van debug ppp onderhandeling wanneer u een TERMREQ-pakket 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

Monster van probleemoplossing

In deze sectie worden een scenario voor het oplossen van voorbeelden beschreven voor een POS-link met PPP-insluiting. Het gebruikt deze configuraties:

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

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

N.B.: Deze apparaten werden op twee routers opgenomen in een back-to-back-labo. Zo wordt de vergrendeling ingesteld op inwendig aan de ene kant en standaard op lijn aan de andere kant.

debug van PPP-onderhandeling

Deze uitvoer illustreert de pakketuitwisseling die met debug ppp onderhandeling wordt gevangen tijdens de lCP's link ingestelde fase.

router A Debug-uitvoer 
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

Router B debug-uitvoer 
(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

pap deken

Deze uitvoer illustreert de pakketuitwisseling die met het debug-pakje wordt opgenomen terwijl een link wordt gelegd. Dit debug neemt de waarde van het protocolveld in het PPP-pakket op. RFC 1661 definieert het protocolveld als een of twee octetten. De waarde in dit veld identificeert het datagram dat in het veld Informatie van het pakket is opgenomen.

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

router A Debug-uitvoer 
(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

Router B debug-uitvoer 
(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 behoudt en SONET-laag alarmen. Keepalives duren langer om een probleem te melden dan de inherente SONET alarmeringsstructuur. Layer 2 keepalives zijn echter handig omdat ze het pad van lijnkaart CPU naar lijnkaart CPU controleren, in plaats van framer naar framer zoals SONET-alarmsystemen dat doen. PPP handelt sneller om staatsveranderingen te verbinden aangezien LCP onmiddellijk daalt. HDLC moet daarentegen de keepalives uit de kast halen.

In een back-to-back instelling tussen twee routers, breekt het trekken van een van de glasvezelbanden Layer 1-connectiviteit. Beide POS-interfaces veranderen de status in een lagere of lagere waarde. Wanneer echter twee router POS interfaces via een Telco-cloud verbinden met SONET/SDH-apparatuur, wordt Layer 1-verliesinformatie niet verspreid naar het externe einde. In deze configuratie zijn keepalives het mechanisme om de link naar beneden te brengen.

Neem deze instelling.

16152b.gif

Dit gebeurt wanneer u de reeks van de verzendvezel op de verbinding van SDHb aan SDHa trekt:

  • router 7507a ontvangt geen keepaliven.

  • Router 7507b ziet keepalives van 7507a aangezien het ontvangen vezel nog werkt. Gebruik debug seriële interface om dit te bevestigen.

In plaats daarvan voert u bij het uitvoeren van deze test de opdracht Show controller pos uit, die SONET-alarmen weergeeft. U dient een signaal voor een padalarm-indicatie (P-AIS) te zien op router 7507a en een indicatie voor een padfout-signaal (P-RDI) op router 7507b.

Loopback Tests

Als de uitvoer van de show interfaces pos opdracht aangeeft dat de serielijn omhoog is maar het lijnprotocol omlaag is, gebruikt u loopback testen om de bron van het probleem te bepalen. Voer eerst een test van het aansluitnetwerk uit en daarna een test op afstand. Raadpleeg Inzicht op Loopback-modi op Cisco-routers voor advies.

Opmerking: Verander de insluiting van PPP naar HDLC wanneer u loopbacks gebruikt. Het lijnprotocol op een interface die met PPP wordt ingesteld, verschijnt alleen wanneer alle LCP- en NCP-sessies met succes zijn overeengekomen.

Status voor lijnprotocol en APS

Een POS-interface die is geconfigureerd voor automatische Protection Switching (APS) brengt het lijnprotocol omlaag als de interface het beveiligingskanaal is en niet het werkkanaal. Overweeg deze voorbeeldtopologie:

16152c.gif

Deze voorbeeldloguitvoer werd opgenomen nadat de glasvezelkabel 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-omschakeling plaatsvindt. Let ook op de veranderingen in open kortste weg eerste (OSPF) nabijheidsstaten. (Raadpleeg de pagina voor ondersteuning van APS-technologie 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

Configureer APS op een POS-interface met PPP-insluiting. PPP is niet op de hoogte van APS. Als een interface wegens APS deselectie omhoog/omlaag is, probeert PPP het resetten van de interface en brengt continu PPP onderhandelingspakketten over.

Afsluiten bovendien om onnodige lijnprotocolflaps te voorkomen. Keepalives worden automatisch uitgeschakeld op de meeste POS-routerhardware.

Een Cisco 12000 Series POS-interface in APS-werkings- of beveiligingsmodus kan in een omhoog/omlaag-status (zelfs met een loopback) blijven staan wanneer APS uitgeschakeld is. Een andere kaart die in dezelfde sleuf is ingebracht, ervaart dit probleem. Verplaats de kaart naar een nieuwe sleuf om de juiste status van het lijnprotocol te herstellen. Dit probleem wordt opgelost in Cisco IOS-softwarerelease 12.0(19)S onder Cisco bug-ID CSCdt43759 (alleen geregistreerde klanten).

Gebruik deze stappen als een tijdelijke oplossing:

  1. Configureer de aps de opdracht ter bescherming.

  2. Geef de commando van aps 1 uit.

  3. Configureer de opdracht niet door de kranen beschermd.

Bekende problemen

Let op deze voorbehouden wanneer u problemen met het lijnprotocol bij POS-interfaces hebt opgelost:

Gerelateerde informatie

Revisiegeschiedenis

Revisie Publicatiedatum Opmerkingen
1.0
19-May-2006
Eerste vrijgave

Was dit document nuttig?

FeedbackFeedback

Contact Cisco

Dit document is van toepassing op deze producten