Risoluzione dei problemi di "Protocollo di linea inattivo" sulle interfacce POS

Opzioni per il download

PDF (213.6 KB)
Visualizza con Adobe Reader su diversi dispositivi
ePub (108.5 KB)
Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (153.9 KB)
Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi

Aggiornato:19 maggio 2006

ID documento:16152

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Sommario

Introduzione

Interpretare il comando show interface pos

Panoramica sullo stack del protocollo POS

Usa comandi di debug

Il protocollo di linea non è attivo con HDLC

Il protocollo di linea non è attivo con PPP

Configurazione collegamento

Manutenzione Collegamento (Con Mantenimento Attività)

Terminazione collegamento

Sequenza di esempio per la risoluzione dei problemi

Note sulla risoluzione dei problemi

Test di loopback

Stato protocollo di linea con APS

Problemi noti

Informazioni correlate

Introduzione

Questo documento descrive come risolvere i problemi di un pacchetto sull'interfaccia del router SONET (POS) con stato del protocollo di linea "inattivo".

Oltre a indicare che il protocollo di linea non è attivo, vengono illustrati i comandi show e debug da utilizzare per risolvere il problema dell'incapsulamento del protocollo PPP (Point-to-Point Protocol) e HDLC (High-Level Data Link Control). Viene inoltre descritto un tipico scenario di risoluzione dei problemi basato su una configurazione di laboratorio documentata.

Interpretare il comando show interface pos

Ai fini del documento, l'output di show interface pos è come mostrato in questo output. Prendere nota delle parti evidenziate della visualizzazione e dei commenti:

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

La guida di riferimento ai comandi di Cisco IOS^® indica che lo stato del campo del protocollo di linea "indica se i processi software che gestiscono il protocollo di linea considerano la linea utilizzabile (ovvero, se i pacchetti keepalive hanno esito positivo) o se è stata disattivata da un amministratore."

Altri campi importanti nell'output show interface pos sono:

Encapsulation - Metodo di incapsulamento assegnato all'interfaccia.
loopback - Indica se è impostato il loopback.
keepalive - Indica se i keepalive sono impostati.

Panoramica sullo stack del protocollo POS

Il diagramma mostra lo stack di protocolli utilizzato su un'interfaccia POS.

Le interfacce POS supportano più incapsulamenti - HDLC, PPP e Frame Relay. Pertanto, packet over SONET è più accuratamente PPP over SONET o HDLC over SONET. Questo documento non copre l'incapsulamento Frame Relay.

PPP e HDLC sono strettamente correlati e condividono queste caratteristiche:

Fornire una struttura di struttura con intestazioni e rimorchi. Il trailer fornisce il controllo degli errori.
Fornire una definizione del frame, che definisce per il destinatario esattamente il punto in cui il pacchetto e il frame iniziano e terminano. In HDLC e PPP, la definizione dei fotogrammi viene fornita mediante uno speciale motivo di riempimento o di inattività interframe. Il modello è 0x7E o 0111 1110.
Definire la lunghezza minima e massima del pacchetto.
Trasportare i pacchetti IP e fornire ai riceventi un metodo per determinare il tipo preciso di pacchetto all'interno del frame in arrivo.

Tuttavia, anche se strettamente correlati, PPP e HDLC non sono gli stessi e i comandi di debug sono diversi per risolvere i problemi del protocollo di linea.

Usa comandi di debug

L'output di vari comandi debug privileged EXEC fornisce informazioni diagnostiche relative allo stato del protocollo e all'attività di rete per molti eventi di internetworking.

caution Attenzione: poiché all'output di debug viene assegnata una priorità alta nel processo CPU, il sistema potrebbe diventare inutilizzabile. Per questo motivo, usare i comandi di debug solo per risolvere problemi specifici o durante le sessioni di risoluzione dei problemi con il personale del supporto tecnico Cisco. Inoltre, è meglio usare i comandi di debug nei periodi di traffico di rete ridotto e un numero inferiore di utenti. Il debug eseguito in questi periodi riduce la probabilità che un aumento del sovraccarico di elaborazione dei comandi di debug influisca sull'utilizzo del sistema. Dopo aver terminato di usare un comando debug, disabilitarlo con il comando no debug specifico o con il comando no debug all.

Questi comandi di debug sono utili per quando si risolvono i problemi dell'interfaccia POS. Per ulteriori informazioni sulla funzione e l'output di ciascuno di questi comandi, consultare le pubblicazioni di riferimento dei comandi di debug di Cisco:

debug serial interface - Verifica se i pacchetti keepalive HDLC sono in aumento. In caso contrario, è possibile che esista un problema di temporizzazione sulla scheda di interfaccia o nella rete.
debug ppp negotiation: visualizza i pacchetti PPP trasmessi durante l'avvio del protocollo PPP, in cui vengono negoziate le opzioni PPP.
debug ppp packet: visualizza i pacchetti PPP inviati e ricevuti. Con questo comando vengono visualizzati i dump di pacchetti di basso livello.
debug ppp errors: visualizza gli errori PPP (ad esempio frame non validi o in formato non corretto) associati alla negoziazione e al funzionamento della connessione PPP.

per ulteriori informazioni, fare riferimento a Risoluzione dei problemi della linea seriale.

Il protocollo di linea non è attivo con HDLC

HDLC è il tipo di incapsulamento predefinito su un'interfaccia di router POS. HDLC è uno standard internazionale, ma le implementazioni dei fornitori variano uno o più campi o l'intestazione o il trailer in dimensioni e formato. La specifica Telecordia GR-253, che definisce SONET, descrive la mappatura HDLC-over-SONET (vedere Numero 3, Sezione 3.4.2.3, pp.3-59). Specifica che il frame HDLC deve essere allineato a byte con il frame SONET e specifica inoltre uno scrambler auto-sincronizzato, un controllo di ridondanza ciclico (CRC) e l'uso del modello di flag HDLC come riempimento interframe per tenere conto della natura variabile dei frame HDLC in arrivo.

Se il comando show interface pos indica che la linea e il protocollo non sono attivi con l'incapsulamento HDLC, è possibile usare il comando debug serial interface per isolare un problema della linea come causa di un errore di connessione. HDLC utilizza i pacchetti keepalive e restituisce i valori di tre contatori nell'output di debug:

myseq: aumenta di uno ogni volta che il router invia un pacchetto keepalive al router remoto.
mineseen: il valore del contatore mineseen riflette l'ultimo numero di sequenza myseq che il router remoto ha riconosciuto di aver ricevuto dal router. Il router remoto memorizza questo valore nel contatore visualizzato e lo invia al router in un pacchetto keepalive.
yourseen: riflette il valore del numero di sequenza myseq che il router ha ricevuto in un pacchetto keepalive dal router remoto.

Se i valori keepalive nei campi mineseq, yourseen e myseen non aumentano in ciascuna riga di output successiva, si verifica un problema a un'estremità della connessione. Quando la differenza nei valori dei campi myseq e mineseen supera tre, la linea si interrompe e l'interfaccia viene reimpostata.

Di seguito viene riportato un esempio di output del comando debug serial interface per una connessione HDLC quando i pacchetti keepalive vengono ricevuti correttamente da entrambe le estremità.

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.

Di seguito viene riportato un esempio di output del comando debug serial interface per una connessione HDLC quando l'interfaccia remota viene chiusa e l'interfaccia locale non riesce a rilevare più di tre pacchetti keepalive.

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.

Il protocollo di linea non è attivo con PPP

La RFC 1661 definisce il protocollo PPP come un protocollo. Le interfacce POS supportano il PPP in modalità di framing simile a HDLC (High-Level Data Link Control), come specificato nella RFC 1662 , per l'incapsulamento dei dati sul layer 2. Il formato di frame per PPP in modalità di framing simile a HDLC è mostrato nella figura.

La RFC 2615 specifica l'uso dell'incapsulamento PPP sui collegamenti SONET o SDH. Il protocollo PPP è stato progettato per l'utilizzo su collegamenti point-to-point ed è adatto ai collegamenti SONET o SDH, forniti come circuiti point-to-point anche nelle topologie degli anelli.

Quando si visualizza un collegamento point-to-point, il protocollo PPP passa attraverso diverse fasi distinte che è possibile tracciare in un diagramma di stato. Quando un evento esterno, ad esempio il rilevamento della portante o la configurazione dell'amministratore di rete, indica che il livello fisico è pronto per essere utilizzato, PPP passa alla fase di creazione del collegamento. Una transizione a questa fase produce un evento UP per il protocollo LCP (Link Control Protocol), che fornisce diverse funzioni. Una funzione è determinare quando un collegamento funziona correttamente e quando si verifica un errore. Per stabilire la comunicazione su un collegamento point-to-point, ciascuna estremità del collegamento PPP deve prima inviare i pacchetti LCP per configurare e provare il collegamento dati.

Quindi, il PPP deve inviare pacchetti NCP (Network Control Protocol) per scegliere e configurare uno o più protocolli a livello di rete. Dopo aver configurato ognuno dei protocolli di rete scelti, è possibile inviare i datagrammi di ciascun protocollo di rete attraverso il collegamento.

Nella tabella seguente vengono elencate le tre classi di pacchetti LCP:

Classe pacchetto LCP	Tipi di pacchetto LCP	Scopo
Configurazione collegamento	Configure-Request, Configure-Ack, Configure-Nak e Configure-Reject	Utilizzato per stabilire e configurare un collegamento.
Terminazione collegamento	Terminate-Request e Terminate-Ack	Utilizzato per terminare un collegamento.
Manutenzione collegamento	Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply e Discard-Request	Utilizzato per gestire ed eseguire il debug di un collegamento.

Configurazione collegamento

Il protocollo LCP viene usato per stabilire la connessione tramite uno scambio di pacchetti Configure. Questo scambio è completo e lo stato LCP aperto è stato immesso una volta inviato e ricevuto un pacchetto Configure-Ack.

In questo output di esempio viene acquisita la fase di configurazione del collegamento LCP su un'interfaccia POS:

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

Nota: un'interfaccia POS configurata con incapsulamento PPP tenta continuamente di stabilire una sessione PPP. Così, vedete che il protocollo di linea compare brevemente su base periodica quando c'è un problema sostenuto, anche quando la fibra viene rimossa.

Manutenzione Collegamento (Con Mantenimento Attività)

I pacchetti LCP Echo-Request e Echo-Reply forniscono un meccanismo di loopback di layer 2 per entrambe le direzioni del collegamento. Al ricevimento di una richiesta echo nello stato aperto LCP, deve essere trasmessa una risposta echo.

Lo schema della RFC 1661 mostra il formato di un pacchetto keepalive PPP.

I pacchetti LCP includono i seguenti campi chiave:

Codice—9 per Richiesta echo e 10 per Risposta echo.
Identificatore: durante la trasmissione, il campo Identificatore deve essere modificato ogni volta che il contenuto del campo Dati cambia e ogni volta che viene ricevuta una risposta valida per una richiesta precedente. Per le ritrasmissioni, l'identificatore può rimanere invariato. Alla ricezione, il campo Identificatore della richiesta echo viene copiato nel campo Identificatore del pacchetto di risposta echo.
Magic-Number - Il campo Magic-Number è di quattro ottetti e consente di rilevare i link che si trovano nella condizione di loopback. Finché l'opzione di configurazione Magic-Number non viene negoziata correttamente, il Magic-Number deve essere trasmesso come zero. Per ulteriori informazioni, vedere l'opzione di configurazione Magic-Number nella RFC 1661.
Dati: il campo Dati è pari a zero o più ottetti e contiene dati non interpretati utilizzabili dal mittente. I dati possono essere costituiti da qualsiasi valore binario. La fine del campo è indicata da Length.

Di seguito è riportato un esempio di negoziazione di debug ppp quando i pacchetti keepalive sono abilitati:

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

Terminazione collegamento

Il protocollo PPP può terminare il collegamento in qualsiasi momento. I possibili trigger includono perdita della portante, errore di autenticazione, errore di qualità del collegamento, scadenza del timer di periodo di inattività o chiusura amministrativa del collegamento.

LCP usa i pacchetti Terminate per chiudere il collegamento. Il mittente di Terminate-Request deve disconnettersi dopo la ricezione di Terminate-Ack o dopo la scadenza del contatore di riavvio. Il destinatario di una Terminate-Request deve attendere la disconnessione del peer e non deve disconnettersi finché non è trascorso almeno un tempo di riavvio dopo l'invio di una Terminate-Ack.

I pacchetti Terminate LCP includono questi campi chiave:

Codice—5 per Terminate-Request e 6 per Terminate-Ack.
Identificatore: durante la trasmissione, il campo Identificatore deve essere modificato ogni volta che cambia il contenuto del campo Dati e ogni volta che viene ricevuta una risposta valida per una richiesta precedente. Per le ritrasmissioni, l'identificatore può rimanere invariato. Alla ricezione, il campo Identificatore di Termina-Richiesta viene copiato nel campo Identificatore del pacchetto Termina-Ack.

Il campo Dati è pari a zero o più ottetti e contiene dati non interpretati che il mittente può utilizzare. I dati possono essere costituiti da qualsiasi valore binario. La fine del campo è indicata da Length.

Di seguito è riportato un esempio di output della negoziazione PPP di debug quando si riceve un pacchetto TERMREQ:

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

Sequenza di esempio per la risoluzione dei problemi

In questa sezione viene descritto uno scenario di esempio per la risoluzione dei problemi di un collegamento POS che utilizza l'incapsulamento PPP. Vengono utilizzate le seguenti configurazioni:

Configurazione 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

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

Nota: questi debug sono stati acquisiti su due router in una configurazione lab back-to-back. In questo modo, la temporizzazione è impostata su interna su un lato e su riga predefinita sull'altra estremità.

negoziazione ppp di debug

Questo output mostra lo scambio di pacchetti acquisito con la negoziazione PPP di debug durante la fase di creazione del collegamento del protocollo LCP.

Output del comando debug del router A
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

Output debug router B
(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 packet

Questo output mostra lo scambio di pacchetti acquisito con il pacchetto debug ppp durante la definizione di un collegamento. Questo debug acquisisce il valore del campo protocol nel pacchetto PPP. La RFC 1661 definisce il campo Protocol come uno o due ottetti. Il valore in questo campo identifica il datagramma incapsulato nel campo Information del pacchetto.

I valori dei campi del protocollo nell'intervallo da "0***" a "3***" identificano il protocollo a livello di rete di pacchetti specifici, mentre i valori nell'intervallo da "8***" a "b***" identificano gli eventuali pacchetti appartenenti ai NCP (Network Control Protocol) associati. I valori dei campi di protocollo nell'intervallo da "c***" a "f***" identificano i pacchetti come protocolli di controllo a livello di collegamento (ad esempio LCP). Sono inoltre disponibili diversi valori specifici del fornitore. Fare clic qui per un elenco completo dei valori dei campi del protocollo PPP.

Output del comando debug del router A
(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

Output del comando debug del router A

(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

Output debug router B
(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

Output debug router B

(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

Note sulla risoluzione dei problemi

Un'interfaccia POS con incapsulamento PPP o HDLC supporta due meccanismi per avvisare l'utente di un errore di collegamento: keepalive di livello 2 e allarmi di livello SONET. La funzionalità keepalive richiede più tempo per la segnalazione di un problema rispetto alla struttura di allarme SONET. Tuttavia, i keepalive di layer 2 sono utili perché controllano il percorso dalla CPU della scheda di linea alla CPU della scheda di linea, anziché da framer a framer come fanno gli allarmi a livello SONET. Il PPP reagisce più rapidamente ai cambiamenti di stato del collegamento, poiché il LCP si blocca immediatamente. Al contrario, HDLC deve eseguire il timeout dei keepalive.

In una configurazione back-to-back tra due router, il pull di uno dei fili di fibra interrompe la connettività di layer 1 e entrambe le interfacce POS cambiano lo stato in down/down. Tuttavia, quando due interfacce POS router si connettono tramite un cloud Telco con apparecchiature SONET/SDH, le informazioni sulla perdita di layer 1 non vengono propagate all'estremità remota. In questa configurazione, i pacchetti keepalive rappresentano il meccanismo per interrompere il collegamento.

Considerate questa configurazione.

Ecco cosa succede quando si tira la cinghia della fibra ottica sul collegamento da SDHb a SDHa:

Il router 7507a non riceve pacchetti keepalive.
Il router 7507b vede keepalive da 7507a poiché la fibra ricevente è ancora in funzione. Per verificare questa condizione, utilizzare l'interfaccia seriale di debug.

In alternativa, quando si esegue questo test, eseguire il comando show controller pos per visualizzare gli allarmi SONET. Dovrebbe essere visualizzato un segnale di indicazione di allarme percorso (P-AIS) sul router 7507a e un segnale di errore remoto percorso (P-RDI) sul router 7507b.

Test di loopback

se l'output del comando show interfaces pos indica che la linea seriale è attiva ma il protocollo della linea non è attivo, usare i test di loopback per determinare l'origine del problema. Eseguire prima un test del loop locale, quindi un test remoto. per ulteriori informazioni, fare riferimento a Descrizione delle modalità di loopback sui router Cisco.

Nota: modificare l'incapsulamento da PPP a HDLC quando si utilizzano i loopback. Il protocollo di linea su un'interfaccia configurata con PPP viene attivato solo quando tutte le sessioni LCP e NCP vengono negoziate correttamente.

Stato protocollo di linea con APS

Un'interfaccia POS configurata per la commutazione di protezione automatica (APS) interrompe il protocollo di linea se l'interfaccia è il canale di protezione e non quello funzionante. Considerare la topologia di esempio seguente:

Questo esempio di output del log è stato acquisito dopo la rimozione del cablaggio in fibra sull'interfaccia POS 1/0 di GSRb. Notare i cambiamenti nello stato del protocollo di linea su entrambe le interfacce quando si verifica il passaggio all'APS. Notare inoltre le modifiche negli stati di adiacenza OSPF (Open Shortest Path First). (per ulteriori informazioni, fare riferimento alla pagina di supporto della tecnologia APS).

*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

Evitare di configurare l'APS su un'interfaccia POS con incapsulamento PPP. Il PPP non è a conoscenza dell'APS. Se un'interfaccia è attiva/inattiva a causa della deselezione dell'APS, il protocollo PPP tenta di reimpostare l'interfaccia e trasmette continuamente i pacchetti di negoziazione PPP.

Inoltre, disabilitare l'opzione keepalive per evitare inutili flap del protocollo di linea. I pacchetti keepalive vengono disabilitati automaticamente sulla maggior parte dei router POS.

Un'interfaccia POS Cisco serie 12000 in modalità APS funzionante o protetta può bloccarsi in uno stato attivo/inattivo (anche con un loopback) quando l'APS è disabilitato. Il problema si verifica in un'altra scheda inserita nello stesso slot. Spostare la scheda in un nuovo slot per ripristinare lo stato corretto del protocollo di linea. Il problema è stato risolto nel software Cisco IOS versione 12.0(19)S con ID bug Cisco CSCdt43759 (solo utenti registrati).

Per risolvere il problema, procedere come segue:

Configurare il comando aps protect.
Eseguire il comando ap force 1.
Configurare il comando no ap protect.

Problemi noti

Tenere presenti le seguenti avvertenze quando si risolvono i problemi del protocollo di linea con le interfacce POS:

Un'interfaccia PA-POS può essere reimpostata continuamente dopo che l'incapsulamento è stato modificato da PPP a HDLC. Questo problema viene segnalato con il PA-POS nell'ID bug Cisco CSCdk30893 (solo utenti registrati) e risolto nell'ID bug Cisco CSCdk18777 (solo utenti registrati) e nell'ID bug Cisco CSCdk13757 (solo utenti registrati) per diverse interfacce che supportano l'incapsulamento PPP e HDLC. Il problema è causato da un arresto non completo del protocollo PPP quando è stato modificato l'incapsulamento.
Un'interfaccia POS configurata con incapsulamento HDLC e keepalive viene sottoposta a ripetuti flap di interfaccia anziché disattivare il protocollo di linea quando i keepalive non vengono ricevuti dall'estremità remota. Il problema è stato risolto nell'ID bug Cisco CSCdp86387 (solo utenti registrati).

Informazioni correlate

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
1.0	19-May-2006	Versione iniziale

Questo documento ti è stato utile?

Feedback

Contattaci

Apri una richiesta di assistenza
(Occorre un contratto di servizio Cisco)