Résolution des problèmes « Line Protocol is Down » sur les interfaces POS

Introduction

Ce document décrit comment effectuer le dépannage d'une interface de routeur de paquet sur SONET (POS) qui a un état du protocole de ligne de « inactif ».

En plus d'aider à identifier que le protocole de ligne est désactivé, il explique les commandes show et debug à utiliser pour résoudre le problème d'encapsulation PPP (Point-to-Point Protocol) et HDLC (High-Level Data Link Control). Il vous guide également dans un scénario de dépannage type basé sur une configuration de TP documentée.

Interpréter la commande show interface pos

Pour les besoins du document, la sortie de show interface pos est comme le montre cette sortie. Notez les parties mises en surbrillance de l'affichage et des commentaires :

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 référence de commande Cisco IOS^® indique que l'état du champ de protocole de ligne indique si les processus logiciels qui gèrent le protocole de ligne considèrent que la ligne est utilisable (c'est-à-dire que les keepalives ont réussi) ou si elle a été supprimée par un administrateur.

Les autres champs importants de la sortie show interface pos sont les suivants :

• Encapsulation : méthode d'encapsulation affectée à l'interface.

• loopback : indique si le bouclage est défini.

• keepalive : indique si les keepalives sont définis.

Présentation de la pile de protocoles POS

Ce schéma illustre la pile de protocoles utilisée sur une interface POS.

Les interfaces POS prennent en charge plusieurs encapsulations : HDLC, PPP et Frame Relay. Ainsi, Packet over SONET est plus précisément PPP sur SONET ou HDLC sur SONET. Ce document ne couvre pas l’encapsulation Frame Relay.

PPP et HDLC sont étroitement liés et partagent ces caractéristiques :

• Fournir une structure de tramage avec des en-têtes et des remorques. La queue de bande permet de vérifier les erreurs.

• Fournir une délimitation de trame, qui définit pour un récepteur exactement l’endroit où un paquet et une trame commencent et se terminent. Dans les protocoles HDLC et PPP, la délimitation des trames est assurée par un motif de remplissage intertrame spécial ou un motif inactif. Le modèle est 0x7E ou 0111 1110.

• Définissez une longueur de paquet minimale et maximale.

• Transport des paquets IP et fourniture d’une méthode permettant aux récepteurs de déterminer le type précis de paquet à l’intérieur de la trame entrante.

Cependant, bien que étroitement liés, PPP et HDLC ne sont pas les mêmes, et différentes commandes de débogage sont utilisées pour résoudre les problèmes de protocole de ligne.

Utiliser les commandes debug

Le résultat de diverses commandes debug en mode d’exécution privilégié fournit des informations de diagnostic relatives à l’état du protocole et à l’activité du réseau pour de nombreux événements d’interconnexion de réseaux.

Attention : Puisque la sortie de débogage se voit attribuer une priorité élevée dans le processus du processeur, elle peut rendre le système inutilisable. Pour cette raison, utilisez les commandes debug uniquement pour résoudre des problèmes spécifiques ou lors de sessions de dépannage avec le personnel d'assistance technique de Cisco. En outre, il est préférable d'utiliser les commandes debug pendant les périodes de faible trafic réseau et de moins d'utilisateurs. Le débogage au cours de ces périodes réduit la probabilité que l'augmentation de la surcharge de traitement des commandes debug affecte l'utilisation du système. Lorsque vous avez fini d'utiliser une commande debug, n'oubliez pas de la désactiver avec sa commande spécifique no debug ou avec la commande no debug all.

Ces commandes debug sont utiles lorsque vous dépannez des problèmes d'interface POS. Pour plus d'informations sur la fonction et la sortie de chacune de ces commandes, reportez-vous aux publications Cisco Debug Command Reference :

• debug serial interface - Vérifie si les paquets de keepalive HDLC sont incrémentés. Dans le cas contraire, un problème de synchronisation peut se produire sur la carte d’interface ou sur le réseau.

• debug ppp negotiation - Affiche les paquets PPP transmis lors du démarrage PPP, où les options PPP sont négociées.

• debug ppp packet - Affiche les paquets PPP envoyés et reçus. Cette commande affiche les vidages de paquets de bas niveau.

• debug ppp errors - Affiche les erreurs PPP (telles que les trames illégales ou mal formées) associées à la négociation et au fonctionnement de la connexion PPP.

Référez-vous à Dépannage des problèmes de ligne série pour plus d'informations.

Protocole de ligne désactivé avec HDLC

HDLC est le type d’encapsulation par défaut sur une interface de routeur POS. HDLC est une norme internationale, mais les mises en oeuvre des fournisseurs varient d'un ou de plusieurs champs ou de l'en-tête ou de la queue de bande en taille et en format. La spécification Telecordia GR-253, qui définit SONET, traite du mappage HDLC-over-SONET (voir Édition 3, Section 3.4.2.3, pp.3-59). Elle spécifie que la trame HDLC doit être alignée sur octet avec la trame SONET, et spécifie également un brouilleur auto-synchronisateur, un contrôle de redondance cyclique (CRC) et l'utilisation du modèle d'indicateur HDLC comme remplissage intertrame pour tenir compte de la nature variable des trames HDLC entrantes.

Si la commande show interface pos indique que la ligne et le protocole sont désactivés avec l'encapsulation HDLC, vous pouvez utiliser la commande debug serial interface pour isoler un problème de ligne comme cause d'une défaillance de connexion. HDLC utilise des keepalives et rapporte les valeurs de trois compteurs dans la sortie de débogage :

• myseq : augmente d'une fois chaque fois que le routeur envoie un paquet keepalive au routeur distant.

• mineseen - La valeur du compteur mineseen reflète le dernier numéro de séquence myseq reçu du routeur distant. Le routeur distant stocke cette valeur dans son compteur que vous voyez et envoie cette valeur dans un paquet keepalive au routeur.

• yoursee - Reflète la valeur du numéro de séquence myseq que le routeur a reçu dans un paquet keepalive du routeur distant.

Si les valeurs keepalive dans les champs mineseq, votrevue et mivisée ne s'incrémentent pas dans chaque ligne de sortie suivante, il y a un problème à une extrémité de la connexion. Lorsque la différence entre les valeurs des champs myseq et mineseen dépasse trois, la ligne s'arrête et l'interface est réinitialisée.

Voici un exemple de sortie de la commande debug serial interface pour une connexion HDLC lorsque des messages de test d'activité sont reçus correctement par les deux extrémités.

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. 

Voici un exemple de sortie de la commande debug serial interface pour une connexion HDLC lorsque l'interface distante est fermée et que l'interface locale manque plus de trois keepalives.

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.
 

Protocole de ligne désactivé avec PPP

RFC 1661 définit PPP comme un protocole. Les interfaces POS prennent en charge le protocole PPP dans un tramage de type HDLC (High-Level Data Link Control), comme spécifié dans RFC 1662 , pour l'encapsulation de données au niveau de la couche 2. Le format de trame du protocole PPP en tramage de type HDLC est illustré dans cette figure.

La RFC 2615 spécifie l'utilisation de l'encapsulation PPP sur des liaisons SONET ou SDH. Le protocole PPP a été conçu pour être utilisé sur des liaisons point à point et convient aux liaisons SONET ou SDH, qui sont provisionnées en circuits point à point même dans des topologies en anneau.

Lors de l’établissement d’une liaison point à point, le protocole PPP passe par plusieurs phases distinctes qui peuvent être tracées dans un diagramme d’état. Lorsqu’un événement externe, tel que la détection de porteuse ou la configuration de l’administrateur réseau, indique que la couche physique est prête à être utilisée, le protocole PPP passe à la phase d’établissement de liaison. Une transition vers cette phase produit un événement UP vers le protocole de contrôle de liaison (LCP), qui fournit plusieurs fonctions. Une fonction consiste à déterminer si une liaison fonctionne correctement et si elle échoue. Afin d'établir une communication sur une liaison point à point, chaque extrémité de la liaison PPP doit d'abord envoyer des paquets LCP pour configurer et tester la liaison de données.

Ensuite, le protocole PPP doit envoyer des paquets NCP (Network Control Protocol) pour choisir et configurer un ou plusieurs protocoles de couche réseau. Une fois que chacun des protocoles de couche réseau sélectionnés a été configuré, les datagrammes de chaque protocole de couche réseau peuvent être envoyés via la liaison.

Ce tableau répertorie les trois classes de paquets LCP :

Configuration de la liaison

LCP est utilisé pour établir la connexion par un échange de paquets Configure. Cet échange est terminé et l'état LCP Ouvert est entré, une fois qu'un paquet Configure-Ack a été envoyé et reçu.

Cet exemple de sortie capture l'étape de configuration de la liaison LCP sur une interface 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 

Remarque : Une interface POS configurée avec l'encapsulation PPP tente continuellement d'établir une session PPP. Ainsi, vous voyez le protocole de ligne apparaître brièvement sur une base périodique en cas de problème persistant, même lorsque la fibre est retirée.

Maintenance De La Liaison (Avec Des Keepalives)

Les paquets LCP Echo-Request et Echo-Reply fournissent un mécanisme de bouclage de couche 2 pour les deux directions de la liaison. À la réception d'une requête d'écho dans l'état LCP Ouvert, une réponse d'écho doit être transmise.

Ce diagramme du document RFC 1661 illustre le format d'un paquet de keepalive PPP.

Ces paquets LCP incluent les champs clés suivants :

• Code : 9 pour Echo-Request et 10 pour Echo-Reply.

• Identificateur : lors de la transmission, le champ Identificateur doit être modifié chaque fois que le contenu du champ Données change et chaque fois qu'une réponse valide a été reçue pour une demande précédente. Pour les retransmissions, l'identificateur peut rester inchangé. À la réception, le champ Identificateur de la requête d'écho est copié dans le champ Identificateur du paquet de réponse d'écho.

• Magic-Number : le champ Magic-Number comporte quatre octets et permet de détecter les liaisons qui sont en mode bouclé. Jusqu'à ce que l'option de configuration Magic-Number soit négociée avec succès, le numéro Magic doit être transmis avec zéro. Pour plus d'informations, reportez-vous à l'option de configuration Magic-Number de la RFC 1661.

• Données : le champ Données est égal à zéro ou plus et contient des données non interprétées à utiliser par l'expéditeur. Les données peuvent être constituées de n'importe quelle valeur binaire. La fin du champ est indiquée par la longueur.

Voici un exemple de négociation debug ppp lorsque les keepalives sont activés :

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 

Terminaison de liaison

PPP peut mettre fin à la liaison à tout moment. Les déclencheurs possibles sont la perte de porteuse, l'échec d'authentification, la défaillance de qualité de la liaison, l'expiration du compteur de période d'inactivité ou la fermeture administrative de la liaison.

LCP utilise des paquets Terminate pour fermer la liaison. L'expéditeur de Terminate-Request doit se déconnecter après avoir reçu un Terminate-Ack ou après l'expiration du compteur Restart. Le destinataire d'une requête de fin doit attendre que l'homologue se déconnecte et ne doit pas se déconnecter tant qu'au moins une heure de redémarrage ne s'est pas écoulée après l'envoi d'une requête de fin.

Les paquets LCP terminés incluent les champs clés suivants :

• Code : 5 pour Terminate-Request et 6 pour Terminate-Ack.

• Identificateur : lors de la transmission, le champ Identificateur doit être modifié chaque fois que le contenu du champ Données change et chaque fois qu'une réponse valide a été reçue pour une demande précédente. Pour les retransmissions, l'identificateur peut rester inchangé. À la réception, le champ Identificateur de la requête de terminaison est copié dans le champ Identificateur du paquet Terminate-Ack.

Le champ Données est égal ou supérieur à zéro octets et contient des données non interprétées à utiliser par l'expéditeur. Les données peuvent être composées de n'importe quelle valeur binaire. La fin du champ est indiquée par la longueur.

Voici un exemple de sortie debug ppp negotiation lorsque vous recevez un paquet 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 

Exemple de séquence de dépannage

Cette section décrit un exemple de scénario de dépannage pour une liaison POS utilisant l’encapsulation PPP. Il utilise les configurations suivantes :

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

Remarque : ces débogages ont été capturés sur deux routeurs dans une configuration de TP de retour à retour. Ainsi, la synchronisation est définie sur interne d'un côté et sur line de l'autre extrémité par défaut.

debug ppp negotiation

Cette sortie illustre l'échange de paquets capturé avec la négociation debug ppp pendant la phase d'établissement de liaison de 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 packet

Cette sortie illustre l'échange de paquets capturé avec debug ppp packet pendant qu'une liaison est établie. Ce débogage capture la valeur du champ de protocole dans le paquet PPP. Le document RFC 1661 définit le champ Protocol comme un ou deux octets. La valeur de ce champ identifie le datagramme encapsulé dans le champ Information du paquet.

Les valeurs des champs de protocole de la plage « 0***" à « 3***" identifient le protocole de couche réseau de paquets spécifiques, et les valeurs de la plage « 8***" à « b***" identifient les paquets appartenant aux protocoles NCP (Network Control Protocol) associés, le cas échéant. Les valeurs des champs de protocole de la plage « c***" à « f***" identifient les paquets comme protocoles de contrôle de couche de liaison (tels que LCP). Il existe également différentes valeurs propres aux fournisseurs. Cliquez ici pour obtenir une liste complète des valeurs des champs du protocole PPP.

(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

Notes de dépannage

Une interface POS avec encapsulation PPP ou HDLC prend en charge deux mécanismes pour vous alerter d'une défaillance de liaison : keepalives de couche 2 et alarmes de couche SONET. Les keepalives prennent plus de temps à signaler un problème que la structure d'alarme SONET inhérente. Cependant, les keepalives de couche 2 sont utiles car ils vérifient le chemin entre le processeur de la carte de ligne et le processeur de la carte de ligne, plutôt qu'entre le trameur et le trameur comme le font les alarmes de niveau SONET. Le protocole PPP réagit plus rapidement aux changements d’état de liaison depuis que le protocole LCP est immédiatement désactivé. En revanche, HDLC doit expirer les keepalives.

Dans une configuration dos à dos entre deux routeurs, le fait de tirer l’un des brins de fibre rompt la connectivité de couche 1 et les deux interfaces POS passent de l’état down/down. Cependant, lorsque deux interfaces POS de routeur se connectent sur un cloud Telco avec un équipement SONET/SDH, les informations de perte de couche 1 ne sont pas propagées vers l'extrémité distante. Dans cette configuration, les keepalives sont le mécanisme permettant de mettre la liaison hors service.

Considérez cette configuration.

Voici ce qui se passe lorsque vous tirez le fil de transmission sur la liaison de SDHb à SDHa :

• Le routeur 7507a ne reçoit aucun test de test d'activité.

• Le routeur 7507b voit des keepalives de la gamme 7507a, car la fibre de réception fonctionne toujours. Utilisez l'interface série de débogage pour confirmer cela.

Vous pouvez également exécuter la commande show controller pos, qui affiche les alarmes SONET lors de ce test. Vous devriez voir un signal d'alarme de chemin (P-AIS) sur le routeur 7507a et une indication de défaut à distance de chemin (P-RDI) sur 7507b.

Tests de bouclage

Si le résultat de la commande show interfaces pos indique que la ligne série est active mais que le protocole de ligne est désactivé, utilisez des tests de bouclage pour déterminer la source du problème. Effectuez d'abord un test de boucle locale, puis un test à distance. Référez-vous à Présentation des modes de bouclage sur les routeurs Cisco pour obtenir des conseils.

Remarque : modifiez l'encapsulation PPP en HDLC lorsque vous utilisez des boucles. Le protocole de ligne sur une interface configurée avec PPP apparaît uniquement lorsque toutes les sessions LCP et NCP sont négociées avec succès.

État du protocole de ligne avec APS

Une interface POS configurée pour la commutation de protection automatique (APS) désactive le protocole de ligne si l'interface est le canal de protection et non le canal de travail. Considérez cet exemple de topologie :

Cet exemple de sortie de journal a été capturé après la suppression du câblage à fibre optique sur l'interface POS 1/0 de GSRb. Notez les modifications apportées à l’état du protocole de ligne sur les deux interfaces lors de la commutation APS. Notez également les modifications apportées aux états de contiguïté OSPF (Open Shortest Path First). (Reportez-vous à la page d'assistance technique APS pour plus d'informations.)

*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 

Évitez de configurer APS sur une interface POS avec encapsulation PPP. PPP ne connaît pas le protocole APS. Si une interface est activée/désactivée en raison de la désélection d’APS, PPP tente de réinitialiser l’interface et transmet continuellement les paquets de négociation PPP.

En outre, désactivez les keepalives pour éviter les volets inutiles du protocole de ligne. Les keepalives sont désactivés automatiquement sur la plupart des routeurs POS.

Une interface POS de la gamme Cisco 12000 en mode APS actif ou protégé peut être bloquée dans un état up/down (même avec un bouclage) lorsque l'APS est désactivé. Une autre carte insérée dans le même logement rencontre ce problème. Déplacez la carte dans un nouveau logement pour rétablir l'état correct du protocole de ligne. Ce problème est résolu dans le logiciel Cisco IOS Version 12.0(19)S sous l'ID de bogue Cisco CSCdt43759 (clients enregistrés uniquement) .

Utilisez ces étapes comme solution de contournement :

1. Configurez la commande ap Protect.

2. Émettez la commande aps force 1.

3. Configurez la commande no ap Protect.

Problèmes identifiés

Notez ces mises en garde lorsque vous dépannez des problèmes de protocole de ligne avec les interfaces POS :

• Une interface PA-POS peut se réinitialiser en continu après que l’encapsulation soit passée de PPP à HDLC. Ce problème est signalé par rapport au PA-POS dans l'ID de bogue Cisco CSCdk30893 (clients enregistrés uniquement) et résolu dans l'ID de bogue Cisco CSCdk187777 (clients enregistrés uniquement) et Cisco CSCdk1377777777777777 ( seulement clients enregistrés ) pour diverses interfaces prenant en charge l’encapsulation PPP et HDLC. Le problème est causé lorsque le protocole PPP n’est pas complètement arrêté lors de la modification de l’encapsulation.

• Une interface POS configurée avec encapsulation HDLC et keepalives subit des basculements d'interface répétés plutôt que de mettre le protocole de ligne hors service lorsque des keepalives ne sont pas reçus de l'extrémité distante. Ce problème est résolu dans l'ID de bogue Cisco CSCdp86387 (clients enregistrés uniquement).

Informations connexes

• Prise en charge de la technologie optique
• Support et documentation techniques - Cisco Systems

Historique de révision