Optique : Réseau optique synchrone (SONET)

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

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


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 ».

Aussi bien que l'aide pour identifier que la ligne protocole est en baisse, il explique les commandes d'exposition et de débogage de utiliser pour dépanner la question pour le Protocole point à point (PPP) et l'encapsulation de High-Level Data Link Control (HDLC). Il marche également vous par un scénario typique de dépannage basé sur une installation documentée de laboratoire.

Interprétez la commande d'interface pos d'exposition

Aux fins du document, la sortie de l'interface pos d'exposition est pendant que cette sortie affiche. Notez les parties mises en valeur 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 commandes de Ý de Cisco IOS déclare que la ligne état de champ de protocole « indique si les processus de logiciel qui manipulent la ligne protocole considèrent la ligne utilisable (c'est-à-dire, le Keepalives est réussi) ou s'il a été pris vers le bas par un administrateur. »

D'autres importants champs dans la sortie d'interface pos d'exposition sont :

  • Encapsulation — Méthode d'encapsulation assignée à l'interface.

  • bouclage — Indique si le bouclage est placé.

  • keepalive — Indique si le Keepalives est placé.

Aperçu de pile de protocoles de POS

Ce diagramme montre la pile de protocoles utilisée sur une interface de POS.

/image/gif/paws/16152/gspos_a0.gif

Encapsulations de support d'interfaces de POS plusieurs - HDLC, PPP et Relais de trames. Ainsi, le Paquet sur SONET est plus exactement PPP au-dessus de SONET ou de HDLC au-dessus de SONET. Ce document ne couvre pas l'Encapsulation de relais de trames.

Le PPP et le HDLC sont étroitement associés et partagent ces caractéristiques :

  • Fournissez à une structure de trame des en-têtes et des remorques. La remorque fournit le contrôle d'erreurs.

  • Fournissez la délinéation de trame, qui définit pour un récepteur exactement où un paquet et une trame commence et finit. Dans le HDLC et le PPP, la délinéation de trame est fournie au moyen de schéma de remplissage interframe spécial ou modèle d'inactif. Le modèle est 0x7E, ou 0111 1110.

  • Définissez une longueur de paquet minimum et maximum.

  • Transportez les paquets IP et fournissez une méthode pour des récepteurs pour déterminer le type précis de paquet à l'intérieur de la trame de arrivée.

Cependant, bien qu'étroitement lié, le PPP et le HDLC ne sont pas identique, et différentes commandes de débogage sont utilisées de dépanner la ligne problèmes de protocole.

Commandes de débogage d'utilisation

La sortie de divers mettent au point des commandes de privileged exec fournit relatif à l'information diagnostique à l'état du protocole et à l'activité réseau pour beaucoup d'événements d'interconnexion de réseaux.

attention Attention : Puisque la sortie de débogage est assignée une haute priorité dans le cpu process, elle peut rendre le système inutilisable. Pour cette raison, commandes de débogage d'utilisation de dépanner seulement des problèmes spécifiques ou pendant les sessions de dépannage avec le personnel de support technique de Cisco. D'ailleurs, il est le meilleur d'utiliser des commandes de débogage au cours des périodes du bas trafic réseau et de moins utilisateurs. L'élimination des imperfections au cours de ces périodes diminue la probabilité qui a augmenté l'utilisation de système d'affects de temps système de traitement de commande de débogage. Quand vous finissez d'utiliser une commande de débogage, souvenez-vous pour la désactiver avec sa particularité aucune commande de débogage ou avec l'aucun mettez au point toute la commande.

Ces commandes de débogage sont utiles pour quand vous dépannez des problèmes d'interface de POS. Plus d'informations sur la fonction et la sortie de chacune de ces commandes sont fournies dans les publications de référence de débogage des commandes de Cisco :

  • mettez au point l'interface série — Vérifie si les paquets keepalive HDLC incrémentent. S'ils ne sont pas, un problème de synchronisation possible existe sur la carte d'interface ou dans le réseau.

  • debug ppp negotiation — Paquets PPP d'expositions transmis pendant le startup de PPP, où des options PPP sont négociées.

  • paquet de debug ppp — Paquets PPP d'expositions étant envoyés et reçus. Cette commande affiche des vidages mémoire de paquet à bas niveau.

  • erreurs de debug ppp — Erreurs de PPP d'expositions (telles que les trames illégales ou mal formées) associées avec la négociation et l'exécution de connexion PPP.

Référez-vous au pour en savoir plus de problèmes de ligne série de dépannage.

La ligne Protocol est en baisse avec le HDLC

Le HDLC est le type d'encapsulation par défaut sur une interface de routeur de POS. Le HDLC est une norme internationale, mais les réalisations de constructeur varient un ou plusieurs champs ou l'en-tête ou la remorque dans la taille et formatent. La spécification de Telecordia GR-253, qui définit le SONET, discute le mappage HDLC-au-dessus-SONET (voir la question 3, la section 3.4.2.3, pp.3-59.) Il spécifie que la trame HDLC octet-soit alignée avec la trame SONET, et spécifie également un embrouilleur autosynchronisant, un contrôle de redondance cyclique (CRC), et l'utilisation du modèle d'indicateur HDLC comme remplissage interframe d'expliquer la nature variable des trames HDLC de arrivée.

Si la commande d'interface pos d'exposition prouve que la ligne et le protocole sont en baisse avec l'encapsulation HDLC, vous pouvez utiliser la commande d'interface série de débogage d'isoler une ligne problème comme cause d'une panne de connexion. Le HDLC utilise le Keepalives et signale les valeurs de trois compteurs dans la sortie de débogage :

  • myseq — Augmente d'un chaque fois que le routeur envoie un paquet keepalive au routeur distant.

  • mineseen — La valeur du compteur de mineseen reflète le dernier numéro de séquence de myseq que le routeur distant a reconnu la réception du routeur. Le routeur distant enregistre cette valeur dans le son yourseen le compteur et envoie cette valeur dans un paquet keepalive au routeur.

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

Si les valeurs de keepalive dans le mineseq, yourseen, et myseen les champs n'incrémentent pas dans chaque ligne ultérieure de sortie, il y a un problème à une extrémité de la connexion. Quand la différence en valeurs dans le myseq et mineseen des champs dépasse trois, la ligne descend et l'interface est remise à l'état initial.

C'est sortie témoin de la commande d'interface série de débogage pour une connexion HDLC quand le Keepalives est reçu 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. 

C'est sortie témoin de la commande d'interface série de débogage pour une connexion HDLC quand l'interface distante est fermée et 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.
 

La ligne Protocol est en baisse avec le PPP

RFC 1661leavingcisco.com définit le PPP comme protocole. Les interfaces de POS prennent en charge le PPP dans le tramage comme de High-Level Data Link Control (HDLC), comme spécifié dans RFC 1662leavingcisco.com , pour l'emballage des données à la couche 2. Le format de trame pour le PPP dans le tramage HDLC HDLC est affiché dans cette figure.

gspos_a2.gif

RFC 2615 spécifie l'utilisation de l'encapsulation PPP au-dessus des liens SONET ou SDH. Le PPP a été conçu pour l'usage sur les liens point par point et convient aux liens SONET ou SDH, qui provisioned car les circuits point par point même dans des topologies de sonnerie.

En évoquant un lien point par point, le PPP passe par plusieurs phases distinctes qui peuvent être dessinées dans un diagramme d'état. Quand un événement externe, tel que la détection de transporteur ou la configuration d'administrateur réseau, indique que la couche physique est prête à être utilisée, le PPP poursuit à la phase d'établissement de liaison. Une transition à cette phase produit un événement HAUT au Link Control Protocol (LCP), qui fournit plusieurs fonctions. Une fonction est détermination quand un lien fonctionne correctement et quand il manque. Afin d'établir la transmission au-dessus d'un lien point par point, chaque fin du lien de PPP doit d'abord envoyer des paquets LCP pour configurer et tester la liaison de données.

Puis, le PPP doit envoyer des paquets de protocole de contrôle de réseau (NCP) pour choisir et configurer un ou plusieurs protocoles de couche réseau. Une fois chacun des protocoles de couche réseau choisis a été configuré, des datagrammes de chaque protocole de couche réseau peut être envoyé au-dessus du lien.

Ce tableau présente les trois classes des paquets LCP :

Classe de paquet LCP Types de paquet LCP But
Configuration de lien Configurer-demande, Configurer-ACK, Configurer-NAK et Configurer-anomalie Utilisé pour établir et configurer un lien.
Arrêt de lien Terminer-demande et Terminer-ACK Utilisé pour terminer un lien.
Maintenance de lien Code-anomalie, Protocol-anomalie, requête d'écho, réponse d'écho, et Écart-demande Utilisé pour gérer et mettre au point un lien.

Configuration de lien

LCP est utilisé pour établir la connexion par un échange des paquets Configure. Cet échange est complet, et le LCP a ouvert l'état écrit, une fois qu'un paquet Configurer-ACK a été envoyé et reçu.

Cette sortie témoin capture l'étape de configuration de lien LCP sur une interface de 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 de POS configurée avec des essais d'encapsulation PPP continuellement pour établir une session PPP. Ainsi, vous voyez la ligne protocole être soulevé brièvement sur une base périodique quand il y a un problème soutenu, même lorsque la fibre est enlevée.

Maintenance de lien (avec le Keepalives)

La requête d'écho et les paquets de réponse d'écho LCP fournissent un mécanisme de bouclage de la couche 2 pour les deux directions du lien. À la réception d'une requête d'écho dans le LCP a ouvert l'état, une réponse d'écho doit être transmis.

Ce diagramme de RFC 1661 montre le format d'un paquet keepalive de PPP.

/image/gif/paws/16152/16152a.gif

Ces paquets LCP incluent ces zones de tri :

  • Code — 9 pour la requête d'écho et 10 pour la réponse d'écho.

  • Identifiant — Sur la transmission, le champ d'identification doit être changé toutes les fois que le contenu de la zone d'information change et toutes les fois qu'une réponse valide a été reçue pour une demande précédente. Pour des retransmissions, l'identifiant peut rester sans changement. À la réception, le champ d'identification de la requête d'écho est copié dans le champ d'identification du paquet de réponse d'écho.

  • Nombre magique — Le gisement de nombre magique est quatre octets, et aides dans la détection des liens qui sont en état fait une boucle-de retour. Jusqu'à ce que l'option de configuration de nombre magique soit avec succès négociée, le nombre magique doit être transmis en tant que zéro. Voyez l'option de configuration de nombre magique dans RFC 1661 pour davantage d'explication.

  • Données — La zone d'information est zéro octets ou plus, et contiennent des données ininterpr3tées à l'usage de l'expéditeur. Les données peuvent se composer de n'importe quelle valeur binaire. L'extrémité du champ est indiquée par la longueur.

Voici un exemple de debug ppp negotiation quand le Keepalives est activé :

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 

Arrêt de lien

Le PPP peut terminer le lien à tout moment. Les déclencheurs possibles incluent la perte de transporteur, d'échec d'authentification, de panne de qualité de lien, de l'expiration du temporisateur d'inactif-période, ou de la fermeture administrative du lien.

Les utilisations LCP terminent des paquets pour fermer le lien. L'expéditeur de la Terminer-demande devrait déconnecter après réception d'un Terminer-ACK, ou après reprise le compteur expire. Le récepteur d'une Terminer-demande devrait attendre le pair pour déconnecter, et ne doit pas déconnecter jusqu'à ce qu'au moins une fois de reprise ait passé après envoi d'un Terminer-ACK.

/image/gif/paws/16152/16152a.gif

Terminez les paquets LCP incluent ces zones de tri :

  • Code — 5 pour la Terminer-demande et 6 pour le Terminer-ACK.

  • Identifiant — Sur la transmission, le champ d'identification doit être changé toutes les fois que le contenu de la zone d'information change, et toutes les fois qu'une réponse valide a été reçue pour une demande précédente. Pour des retransmissions, l'identifiant peut rester sans changement. À la réception, le champ d'identification de la Terminer-demande est copié dans le champ d'identification du paquet Terminer-ACK.

La zone d'information est zéro octets ou plus, et contiennent des données ininterpr3tées à l'usage de l'expéditeur. Les données peuvent se composer de n'importe quelle valeur binaire. L'extrémité du champ est indiquée par la longueur.

Voici un exemple de debug ppp negotiation sorti quand 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 

Ordre de dépannage d'échantillon

Cette section décrit un scénario de dépannage d'échantillon pour un lien de POS utilisant l'encapsulation PPP. Il utilise ces configurations :

Configuration du routeur 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

Configuration du routeur B
interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

Remarque: Ceux-ci met au point ont été capturés sur deux Routeurs dans une installation dos à dos de laboratoire. Ainsi, la synchronisation est placée à interne d'un côté et pour se transférer pour rayer sur l'autre extrémité.

debug ppp negotiation

Cette sortie illustre l'échange de paquet capturé avec le debug ppp negotiation pendant la phase d'établissement de liaison de LCP.

Routeur une sortie de débogage
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

Sortie de débogage du routeur 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

paquet de debug ppp

Cette sortie illustre l'échange de paquet capturé avec le paquet de debug ppp tandis qu'un lien est établi. Ceci mettent au point des captures la valeur du champ de protocole dans le paquet PPP. RFC 1661 définit le champ de Protocol en tant qu'un ou deux octets. La valeur dans ce domaine identifie le datagramme encapsulé dans la zone d'informations du paquet.

Les valeurs de champ de Protocol dans la plage de "0***" à de "3***" identifient le protocole de couche réseau des paquets spécifiques, et les valeurs dans le "8***" à la plage « de *** b » en identifient des paquets appartenant aux protocoles de contrôle de réseau associés (NCPs), si. Les valeurs de champ de Protocol dans « *** c » à la plage « de *** f » identifient des paquets comme Controls Protocol de couche de liaison (tels que LCP). Il y a également de diverses valeurs de constructeur-particularité. A cliquez ici pour une liste complète de valeurs de champ de protocole PPPleavingcisco.com .

Routeur une sortie de débogage
(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

Sortie de débogage du routeur 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

Dépannage des notes

Une interface de POS avec l'encapsulation de PPP ou HDLC prend en charge deux mécanismes pour vous alerter d'une panne de lien : Keepalives de la couche 2 et alarmes de SONET-couche. Le Keepalives prend plus long pour signaler un problème que la structure inhérente d'alarme SONET. Cependant, le Keepalives de la couche 2 est utile parce qu'ils vérifient le chemin de la CPU de linecard à la CPU de linecard, plutôt que l'auteur à l'auteur comme le font les alarmes niveau de la SONET. Le PPP réagit plus rapidement aux modifications d'état de lien puisque LCP descend immédiatement. En revanche, le HDLC doit chronométrer le Keepalives.

En configuration dos à dos entre deux Routeurs, tirant une des ruptures de brins de fibre posez 1 Connectivité, et les deux interfaces de POS changent l'état à vers le bas/vers le bas. Cependant, quand deux interfaces de POS de routeur se connectent à travers une entité de l'opérateur de téléphonie au matériel SONET/SDH, posez les 1 informations de perte n'est pas propagé à l'extrémité distante. Dans cette configuration, le Keepalives est le mécanisme pour réduire le lien.

Considérez cette installation.

/image/gif/paws/16152/16152b.gif

Voici ce qui se produit quand vous tirez le brin de fibre de transmission sur le lien de SDHb à SDHa :

  • Le routeur 7507a ne reçoit aucun Keepalives.

  • Le routeur 7507b voit le Keepalives de 7507a puisque la fibre de réception fonctionne toujours. L'utilisation mettent au point l'interface série pour confirmer ceci.

Alternativement, en exécutant ce test, exécutez la commande de POS de show controller, qui affiche des alarmes SONET. Vous devriez voir un signal d'indication d'alarme de chemin (P-AIS) sur le routeur 7507a et une indication distante de défaut de chemin (P-RDI) sur 7507b.

Tests de bouclage

Si la sortie de la commande de show interfaces pos indique que la ligne série est en hausse mais la ligne protocole est en baisse, employez les tests de bouclage pour déterminer la source de problème. Réalisez un test de boucle locale d'abord, et puis un essai distant. Référez-vous compréhension derrière des modes de bouclage sur des Routeurs de Cisco pour des conseils.

Remarque: Changez l'encapsulation du PPP au HDLC quand vous utilisez des bouclages. La ligne protocole sur une interface configurée avec le PPP est soulevée seulement quand toutes les sessions LCP et de NCP sont négociées avec succès.

État du protocole de ligne avec des aps

Une interface de POS configurée pour le Fonction Automatic Protection Switching (APS) réduit la ligne protocole si l'interface est le canal de protection et pas le canal fonctionnant. Considérez cet exemple de topologie :

/image/gif/paws/16152/16152c.gif

Cette sortie de log témoin a été capturée après que le câblage de fibre sur l'interface du POS 1/0 de GSRb ait été enlevé. Notez les changements de l'état du protocole de ligne sur les deux interfaces quand le basculement aps se produit. Notez également les changements des états de contiguïté de Protocole OSPF (Open Shortest Path First). (Référez-vous au pour en savoir plus de page de support technologique 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 

Évitez de configurer des aps sur une interface de POS avec l'encapsulation PPP. Le PPP ne se rend pas compte des aps. Si une interface est haut/bas en raison du deselection aps, le PPP essaye remettre à l'état initial l'interface et transmet continuellement des paquets de négociation PPP.

En outre, le Keepalives de débronchement pour éviter la ligne protocole inutile s'agite. Le Keepalives est désactivé automatiquement sur la plupart de matériel de routeur de POS.

Une interface de POS de gamme Cisco 12000 dans l'aps working ou protègent le mode peut devenir collée dans un état haut/bas (même avec un bouclage) quand des aps est désactivés. Une autre carte insérée dans la même chose rainent des expériences ce problème. Déplacez la carte à un nouvel emplacement pour restaurer l'état du protocole de ligne approprié. 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 seulement).

Utilisez ces étapes comme contournement :

  1. Configurez la commande d'aps protect.

  2. Émettez la commande de l'aps force 1.

  3. Ne configurez l'aucune commande d'aps protect.

Problèmes identifiés

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

  • Une interface PA-POS pourrait remettre à l'état initial continuellement après que l'encapsulation soit changée du PPP au HDLC. Ce problème est signalé contre le PA-POS dans l'ID de bogue Cisco CSCdk30893 (clients enregistrés seulement) et résolu dans l'ID de bogue Cisco CSCdk18777 (clients enregistrés seulement) et l'ID de bogue Cisco CSCdk13757 (clients enregistrés seulement) pour différentes interfaces qui prennent en charge l'encapsulation de PPP et HDLC. Le problème est provoqué par quand le PPP n'est pas complètement arrêté quand l'encapsulation a été changée.

  • Une interface de POS configurée avec l'encapsulation et le Keepalives HDLC subit les instabilités répétées d'interface plutôt qu'apportant en bas de la ligne protocole quand le Keepalives n'est pas reçu de l'extrémité distante. Ce problème est résolu dans l'ID de bogue Cisco CSCdp86387 (clients enregistrés seulement).

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 16152