Dépannage de la carte Cisco ONS 15454 ML

Options de téléchargement

  • PDF     (228.2 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (144.2 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (208.3 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:14 novembre 2005
ID du document:59863

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document utilise une topologie de test simple pour décrire comment dépanner des cartes multicouches (ML) sur Cisco ONS 15454. La section Annexe fournit quelques commandes de configuration de base et des informations détaillées sur la topologie.

Le test utilise une approche empirique pour comprendre les pannes de réseau associées aux cartes ML. Le test injecte des erreurs ou des configurations connues afin de capturer et d'analyser les résultats attendus. Les études de cas d'isolement des défaillances présentent ces résultats.

Le document suit les méthodologies de dépannage classiques. Le document présente un symptôme, décrit les étapes d'isolation des pannes pertinentes et fournit également des procédures de dépannage génériques.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

  • Cisco ONS 15454

  • Cartes Ethernet Cisco ONS 15454 ML-Series

  • Cisco IOS

  • Pontage et routage IP

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Routeur Cisco 7603 qui exécute le logiciel Cisco IOS® Version 12.1(13)E13

  • Cisco ONS 15454 qui exécute Cisco ONS version 4.1.3

  • ML (inclus dans la version 4.1.3 de l'ONS) qui exécute le logiciel Cisco IOS Version 12.1(19)EO1

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Architecture ML de base

Les cartes de la gamme Cisco ML pour la plate-forme ONS 15454 fournissent une connectivité Ethernet 10/100/1000 Mbits/s sur SONET/SDH aux couches 2 et 3. Chaque carte ML du châssis exécute une image IOS indépendante. La création d'un circuit d'interconnexion dans le contrôleur de transport Cisco (CTC) entre les ports ML crée des ports POS (Packet over SONET) dorsaux virtuels. Dans les versions 4.6 et ultérieures du logiciel, la création de ports POS se produit toujours, mais les ports ne s'activent que lorsqu'un circuit d'interconnexion est créé dans CTC.

La carte ML1000-2 comporte deux ports POS (0 et 1). Chaque port dispose d'une bande passante STS (Synchronous Transport Signal)-24c et d'un total de STS-48c par carte. Chaque port POS prend en charge les sous-interfaces pour autoriser l’agrégation de VLAN. Le mappage physique d'un port POS à un port optique se produit pendant la phase de création du circuit et peut changer lors du changement de portée optique. Ainsi, deux ports POS situés à deux extrémités du circuit sont des homologues et leurs configurations doivent correspondre.

Le mappage entre un port Ethernet et un port POS dépend de la topologie requise. La topologie de commutation de couche 2 relie ces deux types de ports au même numéro de groupe de ponts. La topologie de couche 3 achemine les paquets entre ces interfaces.

Topologie de test de base

La Figure 1 représente la topologie de test :

Figure 1 - Topologie de test

f1_59863.gif

Afin de configurer la topologie de test :

  1. Connectez deux routeurs Cisco 7603 aux noeuds ONS via Gigabit Ethernet et assurez-vous que les deux ports des deux routeurs se trouvent sur le même sous-réseau IP. Ici, chaque noeud ONS possède une carte ML1000-2 dans le logement 12.

  2. Configurez un groupe de ponts 100 pour Gig0 et POS0 sur les deux noeuds ONS.

    Remarque : vous n'avez pas besoin d'utiliser POS1 dans ce test.

    Le circuit entre les deux ports POS0 ML est STS-12c.

  3. Désactivez le routage IP sur les cartes ML.

  4. Offrez une protection OC12 1+1 entre les deux noeuds ONS. Voir Figure 1 pour les informations pertinentes.

    Remarque : les deux noeuds ONS exécutent Cisco ONS version 4.1.3.

Études de cas d'insertion de pannes

Cette section examine les résultats de diverses défaillances connues et de certaines opérations courantes. Chaque étude de cas décrit l'opération et les résultats sur ML et ONS.

Informations générales

Quelques commandes pertinentes pour résoudre des problèmes sur ML IOS 

show ons alarm
show ip interface brief
clear counters
show interface summary
show interface 
      
      
        show controller pos show cdp neighbor show bridge verbose show vlans 
       
         show sdm l2-switching forwarding show ons provisioning-agent message ports show running show log show tech-support

Assurez-vous que l'horodatage est correct pour la journalisation de la mémoire tampon et vérifiez si le contrôle de communication et de contrôle de temporisation (TCC) est défini avec la date et l'heure correctes. Voici un exemple de sortie de configuration sur ML :

service timestamps debug uptime
 service timestamps log datetime msec localtime
 logging buffered 4096 debugging

Ces alarmes déclenchent automatiquement la modification de l'état de la liaison POS :

PAIS
PLOP
PTIM 
PUNEQ 
PRDI 
PPLM 
PPDI 
BER_SF_B3

Remarque : la plate-forme ONS 15454 utilise deux formats pour signaler les alarmes. Par exemple, PAIS apparaît dans IOS (ML), tandis que AIS-P apparaît dans CTC. Le PAIS et l'AIS-P représentent le même type d'alarme.

Vérifications courantes dans CTC 

Alarms
Conditions
History
Circuit
Inventory
Port PM counters
Diagnostics file
Audit trail

  • Sur carte ML :

    • Ports Ether Maintenance/Performance : recherchez les erreurs.

    • Ports POS de maintenance/performances : recherchez les erreurs.

  • Sur la carte de travail OC12 :

    • Activez IPPM sur Provisioning/SONET STS.

    • Performances : recherchez les erreurs.

Études de cas

Cette section décrit divers points de défaillance potentiels et explique comment capturer les informations correctes pour la résolution des problèmes.

Déconnexion Ethernet

Cette alarme apparaît sur .225 lorsque vous tirez le câble Ethernet :

.225ML12#show ons alarm
Equipment Alarms
Active: None 
Port Alarms 
  POS0  Active: None 
  POS1  Active: None 
  GigabitEthernet0  Active: CARLOSS 
  GigabitEthernet1  Active: None 

POS0
Active Alarms : None
Demoted Alarms: None 

POS1 Interface not provisioned

Note : Si vous forcez l'interface ML GigE, ML ne remarque pas que la liaison est désactivée.

La même alarme apparaît dans CTC de 0,225 (voir Figure 2).

Figure 2 - Alarme à la CTC

f2_59863.gif

La perte du voisin CDP (Cisco Discovery Protocol) 7603a confirme le problème.

Remarque : l'état de GigE 0 n'affecte pas l'interface POS 0 (l'interface est toujours activée/activée).

Commutateur de protection OC12

Le commutateur de protection OC12 ne crée aucune alarme ou erreur.

OC12 hors service (OOS)

Lorsque les deux ports OC12 sur le noeud .252 passent à OOS, .225 signale AIS-P, ce qui entraîne la désactivation de l'interface POS 0 et conduit à TPTFAIL.

.225ML12#show ons alarm
Equipment Alarms
Active: RUNCFG-SAVENEED
  
Port Alarms
  POS0  Active: TPTFAIL
  POS1  Active: None
  GigabitEthernet0  Active: None  
  GigabitEthernet1  Active: None 

POS0 
Active Alarms : PAIS 
Demoted Alarms: None
 
POS1
Interface not provisioned

Commutateur latéral XC

Cette entrée de journal apparaît sur le point ML du noeud que XC est commuté. Notez que XCON B est le logement 10 XC.

May 24 09:55:27.402: %CARDWARE-5-XCON_SWITCH: Switched XCON to B
May 24 09:55:27.406: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, 
Port = 0

Commutateur latéral TCC

La Figure 3 affiche l'alarme enregistrée.

Figure 3 - Alarme du commutateur latéral TCC

f3_59863.gif

Note : Si vous utilisez CTC ou inversez telnet pour vous connecter à la carte ML, vous perdez la connexion à la carte ML.

Au bout de quelques minutes, l'alarme doit se dissiper. Ces entrées de journal apparaissent dans ML :

May 24 10:29:09.258: %CARDWARE-5-SOCKET_INFO: closed socket to TCC: 
changed active TCC 
May 24 10:29:09.766: %ONS-6-VTY: All Vty lines cleared 
May 24 10:29:14.762: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B 
May 24 10:29:20.270: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B 
May 24 10:29:25.770: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B 
May 24 10:29:31.270: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B 
May 24 10:29:36.370: %CARDWARE-5-SOCKET_INFO: open socket to TCC: B 
May 24 10:29:41.166: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, 
Port = 0.

Le TCC actif actuel apparaît également dans cette sortie. Le logement 11 TCC est TCC B, tandis que le logement 7 est TCC A.

.252ML12#show ons equipment-agent status
EQA ---- phySlot: 12, eqptType: EQPT_L2SC, eqptID: 0x2403 ----
     curTCC: Tcc B
linkStatus:    Full    dbReq/Recv: 7  /  7   msgVerToEQM: 2
   socketFd:       0    pipeMsgAct:   No     hdrSizeToEQM: 28
  connTries:       0 connTimerFast:   No   hdrSizeFromEQM: 28
timingProv:   No
clock auto 1

Suppression et création de circuits

La suppression du circuit d'interconnexion crée les entrées de journal suivantes :

May 27 17:40:48.459: %VIRTUAL_PA-6-PAREMOVED: 
POS interface [0] has been removed due to circuit deletion 
May 27 17:40:48.511: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, 
Backplane = 0, Port = 0.

La configuration des ports est modifiée lorsque vous l'affichez à partir de ML.

.225ML12#show ons provisioning-agent m ports all
  ----- Backend Port (00) Data ----- 
  prov:  no   sts: xx   vt: xx   type: xxx   name: xxxxx 
  ----- Backend Port (01) Data -----   
  prov:  no   sts: xx   vt: xx   type: xxx   name: xxxxx

La création d'un circuit STS3c met à jour les informations de port sur ML. La taille du circuit apparaît également dans la sortie du contrôleur POS 0.

.225ML12#show ons provisioning-agent m ports all
  ----- Backend Port (00) Data -----
  prov: yes   sts: 00   vt: 255   type: DOS   name:                                  
  ----- STS (00) Term Strip -----
  Admin State: IS        Direction: TX_RX_EQPT
  Type: 3 Sf: 1E-4 Sd: 1E-7 C2 tx/exp: 0x01 / 0x01
  PathTrace Format: 64Byte  Mode: OFF 
   expected: (not valid)
   send: valid: "\000\000\000\000" 
  ----- VT (255) Term Strip not provisioned ----- 
  ----- STS (00) Xc Strip -----   
  rate: 3  Admin: IS  
  Src  Port/STS: 0x09/0x00  STS Eqpt: 0x01
  Dest Port/STS: 0x06/0x00  UPSR STS Cont Dest: 0x00 
  Prev STS Stich Dest Port/STS: 0xFF/0x00 
  Next STS Stich Dest Port/STS: 0xFF/0x00 

  ----- Backend Port (01) Data -----  
  prov:  no   sts: xx   vt: xx   type: xxx   name: xxxxx

Ces entrées de journal apparaissent :

May 27 17:47:08.711: %VIRTUAL_PA-6-PAPLUGGEDIN: 
POS interface [0] has been created due to circuit creation
May 27 17:47:08.715: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, 
Backplane = 0, Port = 0. 
May 27 17:47:08.915: %LINK-3-UPDOWN: 
Interface POS0, changed state to up 
May 27 17:47:09.927: %LINEPROTO-5-UPDOWN: 
Line protocol on Interface POS0, changed state to up

Boucles

L'application d'une boucle d'installation au port OC12 actif sur le .225 provoque le signalement de l'alarme TPTFAIL par .225 ML. Cette alarme apparaît également dans les listes d'alarmes ML.

Remarque : si vous activez les boucles sur un chemin actif, la perte de trafic se produit. 

.225ML12#show ons alarm
Equipment Alarms
Active: None 
Port Alarms
  POS0  Active: TPTFAIL    
  POS1  Active: None
  GigabitEthernet0  Active: None
  GigabitEthernet1  Active: None 
POS0 
Active Alarms : PAIS
Demoted Alarms: None 

POS1
Interface not provisioned

Remarque : lorsque vous utilisez un anneau de paquets résilient (RPR) au lieu de l'OC-12 1+1 comme dans ce test, arrêtez les interfaces POS avant d'activer les boucles. Un tel bouclage sur RPR entraîne une perte de trafic, car le chemin de protection ne réachemine pas le trafic.

Changement de date et d'heure

Les paramètres de date et d'heure incorrects du TCC créent cette entrée dans le journal :

2d23h: %CARDWARE-5-CLOCK_ERR: cannot set time-of-day, 
(invalid IOS time set on TCC)

Lorsque vous modifiez la date et l'heure, cette entrée apparaît dans le journal ML.

2d23h: %CARDWARE-5-CLOCK_INFO: system clock, timezone, 
and summertime configured

Une mise à jour automatique se produit sur l'horloge système IOS en fonction de l'horloge de TCC. Vous pouvez vérifier cette mise à jour via la commande show clock.

Remarque : Vous pouvez utiliser la commande service timestamps pour configurer les horodatages de débogage et de journalisation afin d'utiliser les nouvelles informations d'horloge.

Arrêt d'une interface POS

Lorsque l'interface POS 0 sur .225 ML est arrêtée, certaines alarmes et conditions se produisent (voir Figure 4).

Figure 4 - Alarmes et conditions qui se produisent lors de l'arrêt de l'interface POS 0

f4_59863.gif

AIS-P se produit pour les deux ports OC12 sur .252. Ensuite, TPTFAIL se produit pour ML le .252. Sur le chemin de retour, .225 signale le protocole PPDI (Path Payload Defect Indication), également appelé PDI-P, pour les deux ports OC-12 et RFI-P pour le port OC-12 fonctionnel.

Sur .225 ML, ces alarmes apparaissent :

.225ML12#show ons alarm
Equipment Alarms
Active: RUNCFG-SAVENEED 
 
Port Alarms  
  POS0  Active: None  
  POS1  Active: None 
  GigabitEthernet0  Active: None
  GigabitEthernet1  Active: None
 
POS0
Active Alarms : PRDI PPDI 
Demoted Alarms: None 

POS1 
Interface not provisioned

Ces entrées de journal apparaissent également sur .225 :

May 24 10:52:01.802: %LINK-5-CHANGED: Interface POS0, 
changed state to administratively down 
May 24 10:52:02.801: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, 
changed state to down 
May 24 10:52:04.021: %SONET-4-ALARM:  POS0: PRDI    
May 24 10:52:04.269: %SONET-4-ALARM:  POS0: PPDI

Sur .252, ces alarmes se produisent :

.252ML12#show ons alarm
Equipment Alarms
Active: None 

Port Alarms
  POS0  Active: TPTFAIL 
  POS1  Active: None 
  GigabitEthernet0  Active: None
  GigabitEthernet1  Active: None
 
POS0 
Active Alarms : PAIS
Demoted Alarms: None 

POS1
Interface not provisioned

De même, les entrées des journaux sur .252 indiquent que la raison de l'événement POS 0 down est PAIS. Cela correspond aux alarmes ou aux conditions signalées par la CCT.

May 24 10:51:48.969: %VIRTUAL_PA-6-UPDOWN: 
POS0 changed to down due to PAIS defect trigger changing state 
May 24 10:51:49.169: %LINK-3-UPDOWN: 
Interface POS0, changed state to down 
May 24 10:51:50.169: %LINEPROTO-5-UPDOWN: 
Line protocol on Interface POS0, changed state to down 
May 24 10:51:51.169: %SONET-4-ALARM:  POS0: PAIS

Vous pouvez confirmer ce fait à l'aide de cette sortie :

.252ML12#show contro pos 0 | inc Active
Active Alarms : PAIS
Active Defects: PAIS

Lorsque vous activez l'interface POS 0, ces entrées de journal apparaissent sur .252 ML :

May 24 11:16:17.509: %VIRTUAL_PA-6-UPDOWN: 
 POS0 changed to up due to PAIS defect trigger changing state
 May 24 11:16:17.709: %LINK-3-UPDOWN:
 Interface POS0, changed state to up
 May 24 11:16:18.709: %LINEPROTO-5-UPDOWN:
 Line protocol on Interface POS0, changed state to up
 May 24 11:16:27.309: %SONET-4-ALARM: 
 POS0: PAIS  cleared

Voici les entrées du journal sur .225 ML :

May 24 11:16:30.607: %VIRTUAL_PA-6-UPDOWN: 
POS0 changed to up due to PPDI defect trigger changing state 
May 24 11:16:30.807: %LINK-3-UPDOWN: 
Interface POS0, changed state to up 
May 24 11:16:31.555: %SYS-5-CONFIG_I: 
Configured from console by vty0 (127.0.0.100) 
May 24 11:16:31.807: %LINEPROTO-5-UPDOWN: 
Line protocol on Interface POS0, changed state to up
May 24 11:16:40.175: %SONET-4-ALARM:  POS0: PRDI  cleared 
May 24 11:16:40.415: %SONET-4-ALARM:  POS0: PPDI  cleared

Maintenant le trafic revient à la normale.

Non-correspondance de CRC POS

Lorsque le CRC ne correspond pas sur les deux ports POS du même circuit (par exemple, un côté 16 bits, tandis que l'autre côté 32 bits), aucune alarme ne se produit sur TCC, ni sur ML. Les deux ports POS sont toujours actifs, mais le trafic ne circule pas. Voici quelques symptômes :

  1. Les deux compteurs d'erreur d'entrée de l'interface POS s'incrémentent de 100 % en raison du CRC. Dans ce cas, le CRC passe à 16 bits sur .225 ML alors que .252 ML a toujours le CRC de 32 bits par défaut. L'interface POS0 sur .252 ML affiche un nombre d'erreurs d'entrée et de CRC similaire.

    .225ML12#show int pos 0
POS0 is up, line protocol is up  
  Hardware is Packet/Ethernet over Sonet, 
address is 000f.2475.8c00 (bia 000f.2475.8c00) 
  MTU 1500 bytes, BW 622080 Kbit, DLY 100 usec,   
     reliability 149/255, txload 1/255, rxload 1/255   
Encapsulation ONS15454-G1000, crc 16, loopback not set   
Keepalive set (10 sec)   
Scramble enabled    
ARP type: ARPA, ARP Timeout 04:00:00   
Last input 00:06:57, output never, output hang never   
Last clearing of "show interface" counters 00:04:28   
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0   
Queueing strategy: fifo   
Output queue: 0/40 (size/max)   
5 minute input rate 0 bits/sec, 0 packets/sec   
5 minute output rate 0 bits/sec, 0 packets/sec   
   0 packets input, 11190 bytes  
   Received 0 broadcasts (0 IP multicast)   
   0 runts, 0 giants, 0 throttles             
            0 parity      138 input errors, 
   138 CRC, 0 frame, 0 overrun, 0 ignored    
   0 input packets with dribble condition detected   
   178 packets output, 15001 bytes, 0 underruns  
   0 output errors, 0 applique, 0 interface resets    
   0 babbles, 0 late collision, 0 deferred   
   0 lost carrier, 0 no carrier  
   0 output buffer failures, 0 output buffers swapped out  
   0 carrier transitions

  2. Incrémentation du nombre d'erreurs CRC d'entrée du contrôleur POS.

    .225ML12#show contro pos 0 | inc input
8841 total input packets,  46840204 post-HDLC bytes 
0 input short packets,  46840993 pre-HDLC bytes 
0  input long packets , 3893  input runt packets 
2165  input CRCerror packets , 0  input drop packets 
0 input abort packets 
0 input packets dropped by ucode

  3. Le voisin CDP sur le chemin optique tombe en panne. Même si POS0 est activé et que CDP fonctionne, le voisin sur POS0 ne s'affiche pas.

    225ML12#show cdp neighbor
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge    
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone 
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID 
7603a            Gig 0              170         R S I     Cat 6000  Gig 1/1 

.225ML12#show cdp int | be POS0
POS0 is up, line protocol is up 
  Encapsulation  
  Sending CDP packets every 60 seconds 
  Holdtime is 180 seconds

Non-correspondance de débordement POS

Avec l’encapsulation PPP, vous pouvez activer le brouillage SPE (par défaut, le brouillage SPE est désactivé). Dans cet exemple, le brouillage du POS0 .225ML est activé alors que le POS0 .252ML a le paramètre par défaut.

.225ML12#show int pos 0 | in Scramble
   Scramble enabled

La non-correspondance du brouillage modifie la valeur C2. Si vous activez le brouillage, les interfaces POS utilisent une valeur C2 de 0x16. Si vous désactivez le brouillage, les interfaces POS utilisent une valeur C2 de 0xCF. Lorsque vous activez le brouillage sur le port .252 POS 0, voici le résultat (la configuration .225 POS 0 ne change pas) :

.252ML12#show contr pos 0 | in C2
C2 (tx / rx)           : 0x16 / 0xCF

Sur le noeud .252, PLM-P se produit sur le port actif OC12 de CTC, puis sur le port POS0. Cela déclenche la désactivation du port POS0, ce qui déclenche l'alarme TPTFAIL.

.252ML12#show ons alarm
Equipment Alarms 
Active: RUNCFG-SAVENEED  

Port Alarms 
  POS0  Active: TPTFAIL    
  POS1  Active: None  
  GigabitEthernet0  Active: None 
  GigabitEthernet1  Active: None 
POS0 
Active Alarms : PPLM  
Demoted Alarms: None 

POS1
Interface not provisioned

Sur le noeud .225, PDI-P se produit pour les deux ports OC12 dans CTC. Cette alarme est le résultat de POS0 désactivé en .252. La même alarme (appelée PPDI [Path Payload Defect Indication] dans IOS) se produit pour POS0, ce qui est dû au fait que l'interface reçoit la valeur C2 de 0xFC (plus d'informations à ce sujet plus loin dans le document).

.225ML12#show control pos 0 | inc C2
C2 (tx / rx)           : 0xCF / 0xFC

L'alarme PPDI désactive l'interface POS0. L’interface POS0 descendante déclenche ensuite TPTFAIL.

.225ML12#show ons alarm
Equipment Alarms 
Active: RUNCFG-SAVENEED  
Port Alarms  
  POS0  Active: TPTFAIL    
  POS1  Active: None 
  GigabitEthernet0  Active: None 
  GigabitEthernet1  Active: None 

POS0 
Active Alarms : PPDI  
Demoted Alarms: None 

POS1 
Interface not provisioned

Changement d'octet POS C2

La valeur C2 par défaut est 0x01 pour l'encapsulation LEX (encapsulation par défaut pour POS) et 0xCF pour l'encapsulation PPP/HDLC. Si vous modifiez cette valeur de manière incohérente en une autre valeur, les alarmes PLM-P et TPTFAIL peuvent se produire, ce qui affecte le service. Les deux ports POS du même circuit peuvent utiliser la même valeur C2. L'exception est 0xFC. Une valeur de 0xFC indique un chemin d'accès Payload Defect. Ainsi, même si les valeurs C2 correspondent (0xFC/0xFC), PDI-P se produit.

Vous pouvez modifier la valeur POS C2 à l'aide de cette commande :

pos c2 flag <value in decimal>

Vous pouvez représenter les valeurs C2 réelles comme indiqué ici (au format hexadécimal) :

.225ML12#show contro pos 0 | inc C2
C2 (tx / rx)           : 0x16 / 0x16

Dans ce cas, les deux valeurs C2 correspondent. Par conséquent, aucune alarme ne se produit.

Modifier l'état du circuit en OOS

Lorsque vous changez le circuit OC-12 en OOS, aucune alarme ne peut se produire immédiatement sur TCC ou sur ML. L'état du circuit affiche OOS sur la fenêtre du circuit dans CTC. Les entrées de journal sont insérées dans ML :

.225ML12#show log …
May 27 14:22:15.114: %CARDWARE-6-CIRCUIT_STATE: 
Circuit state on POS 0 change from IS to OOS_AS 
May 27 14:22:15.114: %CARDWARE-6-BTC_DRV: 
Init BTC, BTC Rev = 2, Backplane = 0, Port = 0.

Les ports POS peuvent passer à l'état Up/Down. Par conséquent, l'alarme TPTFAIL se produit aux deux extrémités. Le trafic ne circule pas, comme vous pouvez vous y attendre.

Alarme PDI-P bloquée

Parfois, une alarme est bloquée, et ne s'efface pas automatiquement, même après que l'état qui a causé l'alarme s'efface. Un exemple PPDI (ou PDI-P) est présenté ici :

May 27 18:41:15.339: %CARDWARE-6-CIRCUIT_STATE: 
Circuit state on POS 0 change from IS to OOS_AS 
May 27 18:42:11.871: %LINEPROTO-5-UPDOWN: 
Line protocol on Interface POS0, changed state to down 
May 27 19:17:48.507: %SYS-5-CONFIG_I: 
Configured from console by vty2 (127.0.0.100) 
May 28 11:57:33.387: %CARDWARE-6-CIRCUIT_STATE: 
Circuit state on POS 0 change from OOS_AS to IS 
May 28 11:57:33.391: %CARDWARE-6-BTC_DRV: 
Init BTC, BTC Rev = 2, Backplane = 0, Port = 0.  
May 28 11:57:35.879: %VIRTUAL_PA-6-UPDOWN: 
POS0 changed to down due to PPDI defect trigger changing state 
May 28 11:57:36.079: %LINK-3-UPDOWN: 
Interface POS0, changed state to down 
May 28 11:57:36.279: %SONET-4-ALARM:  
POS0: PPDI

Lorsqu'un état de circuit précédent passe à OOS, .225 POS signale PPDI même après le retour du circuit à l'état In-Service (IS). L’interface POS0 reste donc inactive. CTC signale également PDI-P sur le noeud .225. Les compteurs PM des interfaces OC12 sur .225 ne présentent aucune erreur et indiquent que le chemin OC-12 est propre.

Ce résultat indique que PPDI est coincé :

.225ML12#show contro pos 0
Interface POS0 
Hardware is Packet/Ethernet over Sonet  
PATH 
  PAIS      = 0         PLOP      = 0         PRDI    = 0         PTIM = 0 
  PPLM      = 0         PUNEQ     = 0         PPDI    = 0        
  BER_SF_B3 = 0         BER_SD_B3 = 0         BIP(B3) = 0          REI = 0 
  NEWPTR    = 0         PSE       = 0         NSE     = 0        
Active Alarms : PPDI  
Demoted Alarms: None 
Active Defects: PPDI  
Alarms reportable to CLI: 
PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3 
Link state change defects: 
PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3  

Link state change time   : 200 (msec)
 
DOS FPGA channel number  : 0 
Starting STS (0 based)   : 0 
VT ID (if any) (0 based) : 255 
Circuit size           : STS-3c 
RDI Mode               : 1 bit 
C2 (tx / rx)           : 0xCF / 0xFC 
Framing                : SONET

Rappelez-vous de la version précédente de ce document, la valeur C2 0xFC entraîne le signalement de PPDI par POS.

Remarque : Lorsque le noeud .252 est exempt d'alarmes et d'erreurs et que les valeurs C2 correspondantes de 0xCF/0xCF pour POS0 sont identiques, vous devez considérer un problème d'alarme bloqué. Si vous réinitialisez l'interface POS0 sur le noeud .225, l'alarme s'efface, qui inclut le PDI-P signalé dans CTC. Cette anomalie doit être corrigée dans une version ultérieure.

May 28 14:34:16.967: %LINK-5-CHANGED: 
Interface POS0, changed state to administratively down 
May 28 14:34:18.675: %LINK-3-UPDOWN: 
Interface POS0, changed state to down 
May 28 14:34:18.939: %VIRTUAL_PA-6-UPDOWN: 
POS0 changed to up due to PPDI defect trigger changing state 
May 28 14:34:19.139: %LINK-3-UPDOWN: 
Interface POS0, changed state to up 
May 28 14:34:20.127: %SYS-5-CONFIG_I: 
Configured from console by vty2 (127.0.0.100) 
May 28 14:34:20.147: %LINEPROTO-5-UPDOWN: 
Line protocol on Interface POS0, changed state to up 
May 28 14:34:28.739: %SONET-4-ALARM:  
POS0: PPDI  cleared

Maintenant, les valeurs C2 correspondent et le noeud est exempt d'alarmes.

.225ML12#show control pos 0 
Interface POS0 
Hardware is Packet/Ethernet over Sonet  
PATH  
  PAIS      = 0         PLOP      = 0         PRDI    = 1         PTIM = 0 
  PPLM      = 0         PUNEQ     = 0         PPDI    = 0     
  BER_SF_B3 = 0         BER_SD_B3 = 0         BIP(B3) = 0          REI = 16 
  NEWPTR    = 0         PSE       = 0         NSE     = 0         
Active Alarms : None 
Demoted Alarms: None 
Active Defects: None 
Alarms reportable to CLI: 
PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3 
Link state change defects: 
PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3  
Link state change time: 200 (msec) 

DOS FPGA channel number  : 0 
Starting STS (0 based)   : 0 
VT ID (if any) (0 based) : 255 
Circuit size           : STS-3c 
RDI Mode               : 1 bit 
C2 (tx / rx)           : 0xCF / 0xCF 
Framing                : SONET

Remarque : Parfois, une ou plusieurs alarmes peuvent également être bloquées sur des cartes optiques. Vous devez réinitialiser le TCC actif pour effacer ces alarmes bloquées. Par conséquent, le TCC de secours devient actif, et l'opération est sans heurts (c'est-à-dire qu'il n'y a pas d'impact sur le trafic), bien que vous puissiez perdre le trafic de gestion (session CTC, par exemple) pendant quelques minutes.

Non-correspondance du numéro du groupe de ponts

Ce test utilise le même groupe de 100 ponts sur les deux cartes ONS ML. Cependant, les groupes de ponts ne doivent pas être identiques, tant que POS 0 et GigE 0 sont sur le même ML, ou dans le même groupe de ponts. Par exemple, une modification du groupe de pontage 101 sur .252 ML n'affecte pas le trafic.

.252ML12#show bridge ver
Total of 300 station blocks, 298 free 
Codes: P - permanent, S - self 

Maximum dynamic entries allowed: 1000 
Current dynamic entry count: 0 

Flood ports  
        
Maximum dynamic entries allowed: 1000 
Current dynamic entry count: 2 
BG Hash      Address      Action  Interface    VC    Age   RX count   TX count 
101 02/0   000b.45b0.484a forward  Gi0                  -     
101 BC/0   0009.b7f4.76ca forward  POS0 
                -     
Flood ports          
GigabitEthernet0     
POS0

Liste partielle des bogues ML en suspens

Voici une liste partielle des bogues qui s'appliquent à la configuration dans ce document :

Remarque : ces bogues sont documentés dans les notes de version sur cisco.com.

ID DDTS Status (état) Version trouvée Version corrigée *********************Notes de version**********************************************************************************************************************************************************************************************************************************
CSCeb56287 V 4.1 4.6 Lorsque vous provisionnez l'état d'un circuit de série ML de In-Service (IS) à Out-of-Service (OOS), puis revenez à IS, le trafic de données ne se rétablit pas. Afin d'éviter ce problème, avant de modifier l'état de IS, définissez le port POS sur shutdown sur la CLI. Après avoir rétabli l'état IS à partir d'OOS, réglez le port POS sur no shutdown.
CSCeb24757 V 4.1 4.6 Si vous déconnectez une fibre de transmission sur un port ML1000, seul le port adjacent arrête la liaison. Idéalement, les deux ports doivent identifier que la liaison est tombée en panne afin que les protocoles de couche supérieure puissent router le trafic vers un port différent. Afin de contourner cette situation, émettez shutdown et no shutdown sur le port dont la fibre de transmission est déconnectée ou défectueuse.
CSCdy31775 V 4 4.6 Aucun nombre d'abandons ne comprend les paquets qui sont rejetés en raison de l'encombrement de la file d'attente de sortie. Ce problème se produit dans l'une ou l'autre des conditions suivantes :
  • Trafic sur les cartes de série ML entre les ports Ethernet et SONET, avec sursouscription de la bande passante de circuit disponible configurée, ce qui conduit à l'encombrement de la file d'attente de sortie.
  • Trafic de SONET à Ethernet, avec sursouscription de la bande passante Ethernet disponible.
CSCdz49700 C 4 - Les cartes de la série ML transmettent toujours des paquets DTP (Dynamic Trunking Protocol) entre des périphériques connectés. Si le protocole DTP est activé sur les périphériques connectés (ce qui peut être le paramètre par défaut), le protocole DTP peut négocier des paramètres, par exemple, ISL, que les cartes de la série ML ne prennent pas en charge. La carte de série ML compte tous les paquets sur une liaison négociée pour utiliser ISL comme paquets de multidiffusion, et les paquets STP et CDP sont pontés entre les périphériques connectés qui utilisent ISL sans être traités. Afin d'éviter ce problème, désactivez DTP et ISL sur les périphériques connectés. Cette fonctionnalité est conçue comme prévu.
CSCdz68649 C 4 - Dans certaines conditions, l'état de contrôle de flux peut indiquer que le contrôle de flux fonctionne, lorsque le contrôle de flux ne fonctionne pas. Le contrôle de flux sur les cartes de la série ML ne fonctionne que lorsque vous configurez un régulateur de niveau port. Un régulateur de niveau de port est un régulateur sur la classe par défaut et seule d'une carte de stratégie d'entrée. Le contrôle de flux ne fonctionne également que pour limiter le débit source au taux d'abandon du régulateur configuré. Le contrôle de flux n'empêche pas les rejets de paquets en raison de l'encombrement de la file d'attente de sortie. Par conséquent, si vous ne disposez pas d'un régulateur de niveau port ou si la file d'attente de sortie est encombrée, la réglementation ne fonctionne pas. Cependant, la police peut toujours apparaître par erreur comme activée dans ces conditions. Afin d'éviter ce problème, configurez un régulateur de niveau port et évitez l'encombrement de la file d'attente de sortie.
CSCdz69700 C 4 - Si vous émettez une séquence de commandes shutdown/no shutdown sur un port ML1000, les compteurs sont effacés. Il s’agit d’une partie normale du processus de démarrage et cette fonctionnalité ne changera pas.
CSCea11742 V 4 4.6 Lorsque vous provisionnez un circuit entre deux ports POS ML en tant qu'OOS, l'un des ports peut signaler par erreur TPTFAIL. Ce problème existe pour les cartes ML100T-12 et ML1000-2. Si ce problème survient, ouvrez une fenêtre de console sur chaque carte ML et configurez le port POS pour qu'il se ferme.
CSCea20962 V 4 5 Aucun avertissement ne s'affiche lorsque vous appliquez OOS aux ports d'abandon ML dans la fenêtre de mise en service du circuit.
CSCdy47284 C 4 - Le MTU FastEthernet ML-100 n'est pas appliqué. Cependant, les trames de plus de 9 050 octets peuvent être ignorées et provoquer des erreurs Rx et Tx.
Codes d'état :
  • V - Vérifié (le correctif est vérifié dans les travaux pratiques)
  • C - Fermé (il n'y aura pas de correction pour le bogue pour différentes raisons)
  • Version trouvée : la version du logiciel qui a été signalée pour la première fois
  • Version corrigée : La version logicielle que le bogue a été corrigé

Dépannage et isolation des pannes

Avec les informations présentées jusqu'à présent, cette section vise à créer des cas d'isolation des pannes. En fonction des symptômes signalés par le système, cette section fournit des conseils pas à pas pour résoudre le problème. Ces études de cas portent sur certains symptômes courants associés à la carte ML sur ONS 15454.

En règle générale, vous devez suivre les étapes suivantes pour résoudre un problème :

  • Collecter des informations générales et des symptômes de panne.

  • Analyser les informations.

  • Isolez le problème.

  • Identifiez le problème.

  • Résolvez le problème.

Certaines de ces étapes sont répétées plusieurs fois.

Informations générales

Collecte d'informations de base

Recueillez des informations avant de recharger ou de réinitialiser la carte ML en raison d'une erreur. Un rechargement manuel rejette des informations potentiellement utiles. Les rechargements manuels réinitialisent tous les compteurs et vous perdez tous les journaux stockés en mémoire. Cisco vous recommande d'émettre la commande show tech-support et toute autre commande de collecte de données pour récupérer les informations du journal avant d'émettre des commandes de dépannage sur le routeur. Si vous redémarrez ou réinitialisez la carte ML, vous pouvez perdre l'accès console/telnet, ainsi que les informations pertinentes.

Les journaux de la console qui mènent à l'événement peuvent fournir une image de ce qui a conduit à l'erreur ou au plantage. En cas d'erreur, vous devez tenter d'enregistrer les messages enregistrés sur la console ou la mémoire tampon. Ces derniers messages de console peuvent s'avérer essentiels pour détecter le problème. Selon le type de problème, tous les messages ne sont pas écrits sur le serveur SYSLOG.

Utilisez la commande show tech-support pour collecter une grande variété de données. Cette commande est souvent le meilleur outil pour obtenir l'état du routeur, après l'erreur à un moment donné.

Voici une liste de base des commandes que la commande show tech-support exécute. Ce que vous captez varie en fonction de la version de l'IOS, du matériel et des options que vous sélectionnez.

show version
show running-config 
show stacks 
show interfaces 
show controllers 
show file systems 
dir nvram: 
show flash: all 
show process memory 
show process cpu 
show context 
show sdm internal all-regions 
show sdm ip-adjacency all 
show sdm ip-mcast all 
show sdm ip-prefix all 
show sdm l2-switching forwarding 
show sdm l2-switching interface-macs 
show sdm qos all 
show ons alarm defect 
show ons alarm failure 
show ons hwp defects 
show ons hwp reframe 
show ons hwp tci 
show ons hwp xcon 
show ons equipment-agent status 
show ons provisioning-agent message ports all 
show ons provisioning-agent message node-element 
test mda conn dump connections 
test mda ppe global reg dump 0 
test mda ppe global reg dump 1 Mempool statistics 
show region 
show buffers

En plus de ces commandes, capturez d'autres sorties de commande qui ont une pertinence particulière pour la carte ML, comme décrit dans les sections précédentes de ce document. Par exemple, show log, show ons alarme et ainsi de suite. À partir de CTC, capturez et exportez les informations pertinentes décrites précédemment, par exemple les alarmes, les conditions, les circuits, les inventaires et les compteurs de particules.

Quelques outils IOS utiles pour résoudre les problèmes

Après avoir recueilli les informations requises, vous devez déchiffrer les informations à la recherche d'erreurs. Cette tâche peut être difficile avec la sortie d'une commande show-tech. Ce sont des outils qui peuvent déchiffrer la sortie de la commande show-tech, et de nombreuses autres commandes.

  • Output Interpreter Tool (clients enregistrés uniquement) : Collez la sortie de la commande show tech-support dans cet outil. Cet outil fournit un résumé rapide des problèmes détectés. C'est un excellent outil qui fournit un bref résumé des problèmes les plus simples que vous rencontrez. Cet outil interprète diverses entrées. Vous pouvez utiliser la liste déroulante Technologie pour naviguer. Cependant, l'outil n'est pas parfait et nécessite toujours une interprétation pour valider l'information.

  • Outil de recherche de commandes : Sélectionnez l'un des guides de référence suivants pour rechercher une commande et la syntaxe :

    • Référence de commande IOS

    • Guide de configuration IOS

    • Référence de commande Catalyst

    • référence de commande de pare-feu PIX

  • Décodeur de message d'erreur : Cet outil vous aide à rechercher et à résoudre les messages d'erreur pour le logiciel Cisco IOS, le logiciel des commutateurs Catalyst et le logiciel pare-feu Cisco Secure PIX. Collez les messages d'erreur dans les fichiers journaux et assurez-vous de cocher la case Suggérer les documents associés dans les résultats.

  • Boîte à outils des bogues : Recherchez des résultats en fonction d'une ou plusieurs des options suivantes :

    • Version IOS.

    • Fonctionnalités ou composants.

    • Mots clés.

    • Gravité des bogues (vous pouvez sélectionner une gravité spécifique ou spécifier une plage).

  • Collecte de dossiers TAC : Vous pouvez diagnostiquer de manière interactive les problèmes courants liés au matériel, à la configuration et aux performances grâce aux solutions fournies par les ingénieurs du centre d'assistance technique.

Note : Certains outils ne sont pas compatibles à 100% pour la carte ML.

Études de cas

Cette section décrit certaines des conditions de panne courantes et les étapes possibles à suivre pour isoler ces conditions. Reportez-vous au Guide de dépannage de Cisco ONS 15454, versions 4.1.x et 4.5 pour obtenir des informations détaillées sur les alarmes.

Alarme CARLOSS signalée sur un port Ethernet ML

Major (MJ) et Service-Affecting (SA), une alarme Carrier Loss sur la carte de trafic Ethernet série ML est l'équivalent de données de l'alarme « LOS (OC-N)« . Le port Ethernet a perdu la liaison et ne reçoit pas de signal valide.

Une alarme CARLOSS se produit lorsque le port Ethernet a été configuré à partir de l'interface de ligne de commande IOS en tant que port no shutdown, et l'une de ces conditions est également remplie :

  • Le câble n'est pas correctement connecté au port proche ou éloigné.

  • Échec de la négociation automatique.

  • La vitesse (pour les ports 10/100 uniquement) n'est pas définie correctement.

Comme indiqué dans ce test entre la carte ML de noeud 7603b et .252, désactivez la négociation automatique pour activer les ports.

Alarme TPTFAIL signalée pour POS

Il s'agit d'une alarme majeure (MJ), qui affecte le service (SA). L'alarme TPT Layer Failure indique une interruption de la fonction d'intégrité de liaison POS de bout en bout des cartes POS de la gamme ML. TPTFAIL indique une condition d'extrémité ou une configuration incorrecte du port POS.

L'alarme TPTFAIL indique un problème sur le chemin SONET, le port POS distant ou une mauvaise configuration du port POS qui empêche le fonctionnement du chemin POS de bout en bout.

Si des alarmes de chemin SONET, par exemple, « AIS-P », « LOP-P », « PDI-P » ou « UNEQ-P » existent sur le circuit que le port POS utilise, le port affecté peut signaler une alarme TPTFAIL.

Si le port POS de la série ML distante est désactivé par l'administrateur, le port insère une condition « AIS-P » que le port de la série ML distante détecte. Le port de fin proche peut signaler TPTFAIL dans cet événement. Le port POS distant signale les protocoles PRDI et PPDI. Vous pouvez afficher toutes ces alarmes à l'aide de la commande show ons alarme. Si le port POS n'est pas correctement configuré au niveau de l'interface de ligne de commande IOS, la configuration incorrecte entraîne la désactivation du port et le signalement de TPTFAIL.

Complétez ces étapes afin d'effacer l'alarme TPTFAIL (série ML) :

  1. Si aucune alarme SONET ne se produit sur le circuit de port POS, vérifiez si vous avez correctement configuré les deux ports POS.

  2. Si seule l'alarme « PLM-P » se produit sur le circuit de port POS, vérifiez si vous avez correctement configuré les deux ports POS.

  3. Si seule la condition « PDI-P » se produit sur le circuit de port POS et que le circuit est terminé par une carte série G, vérifiez si une alarme « CARLOSS (Ethernet série G)" se produit sur la carte série G. Si c'est le cas, exécutez la procédure « Clear the CARLOSS (G-Series Ethernet) Alarm ».

  4. Si l'alarme « AIS-P », l'alarme « LOP-P » ou l'alarme « UNEQ-P » est présente, dépannez le chemin SONET (le chemin entre les deux interfaces POS sur le même circuit) pour effacer ces alarmes.

L'interface Gigabit Ethernet reste inactive

Voir Alarme CARLOSS signalée sur un port Ethernet ML.

Rapports d'interface POS Erreurs CRC

Ce problème est généralement dû à une non-correspondance CRC sur les configurations POS.

Rapports POS PPDI

PDI-P est un ensemble de codes spécifiques aux applications contenus dans la surcharge de chemin STS (POH) que le noeud ONS génère. L'alarme indique à l'équipement en aval qu'il y a un défaut dans une ou plusieurs charges utiles directement mappées contenues dans cette enveloppe de charge utile synchrone STS.

Une condition PDI-P sur le port d'une carte OC-N prenant en charge un circuit de carte de série ML peut résulter de la fonctionnalité d'intégrité de liaison Ethernet de bout en bout de la carte de série ML. Si le problème est dû à l'intégrité de la liaison, l'alarme « TPTFAIL (G-Series Ethernet)" ou l'alarme signalée contre un ou les deux ports POS terminant le circuit se produit également. Si TPTFAIL se produit sur l'un des ports POS ou les deux, dépannez l'alarme qui accompagne TPTFAIL pour effacer la condition PDI-P. L'alarme PDI-P peut également être le symptôme d'une alarme bloquée.

Voici un exemple d'alarmes qui se produisent en raison de l'arrêt administratif de POS0 sur .225 :

.225 POS 0 (fermé) .252 POS 0
PPDI, PRDI PAIS, TPTFAIL

Dans cet exemple, PAIS indique que la racine du problème est le noeud .225. Si vous effacez PAIS, le TPTFAIL, PPDI et PRDI sont également effacés.

Rapports POS PRDI

Le protocole PRDI indique que le problème se situe à l'extrémité éloignée. Ce problème peut se produire parce que l'extrémité distante reçoit l'alarme AIS. Voir Rapports POS PPDI pour plus d'informations.

PAIS Rapports POS

La condition AIS Path signifie que ce noeud détecte AIS dans le chemin entrant.

En règle générale, un AIS est un signal SONET spécial qui indique au noeud récepteur que le noeud expéditeur n’a pas de signal valide disponible à envoyer. AIS n'est pas une erreur. Le noeud récepteur déclenche l’AIS de condition de panne sur chaque entrée où le noeud voit l’AIS du signal au lieu d’un signal réel. Dans la plupart des cas, lorsque cette situation se produit, un noeud en amont déclenche une alarme pour indiquer une défaillance du signal ; tous les noeuds en aval génèrent uniquement un type d’AIS. Cette condition s'efface lorsque vous résolvez le problème sur le noeud en amont.

Rapports POS PPLM

Ce problème est critique (CR) et affecte les services (SA)

Une alarme de non-correspondance d'étiquette de charge utile de chemin d'accès sur un noeud indique que le signal entrant ne correspond pas à l'étiquette provisionnée localement. La condition se produit en raison d'une valeur d'octet C2 non valide dans la surcharge du chemin SONET. Le brouillage et l’encapsulation peuvent modifier les valeurs C2.

L'interface POS reste inactive

Plusieurs alarmes peuvent désactiver l'interface POS. Par défaut, ces alarmes provoquent la désactivation de la liaison POS : PAIS, PLOP, PTIM, PUNEQ, PRDI, PPLM, PPDI, BER_SF_B3. Afin de modifier la liste, utilisez la commande interface pos trigger défauts. Lorsque l'interface POS est activée ou désactivée, la cause est consignée (show log). Vous pouvez récupérer toutes les alarmes ou défauts actifs à l'aide de la commande show ons alarme. Dépannez la cause de l'activation de l'interface POS. Lorsque l'interface POS tombe en panne, une alarme TPTFAIL se produit.

Lorsque vous vous connectez aux interfaces POS d'autres fournisseurs, assurez-vous que ces éléments correspondent aux deux extrémités :

  1. Écrasant

  2. Valeur C2

  3. CRC

Erreurs d'entrée des rapports d'interface POS

Les erreurs d'entrée qui s'accumulent sur une interface POS (show interface POS and CTC PM counters) indiquent que les paquets entrants sont mal formés. Diverses causes peuvent entraîner des paquets d'erreur d'entrée.

Dépannez les alarmes si elles existent.

Si les erreurs CRC s'incrémentent le long des erreurs d'entrée, les erreurs CRC peuvent être la cause des erreurs d'entrée. Dépannez les configurations CRC.

Vérifiez les configurations de l'interface POS.

Dépannez les composants de chemin entre les deux ports POS. Si les erreurs d'entrée s'incrémentent sans incrément correspondant dans d'autres erreurs de composants, considérez un problème matériel. Avant de remplacer le matériel, effectuez ces étapes sur les deux côtés du circuit (un à la fois) pour voir si le problème persiste :

  • Commutateur latéral TCC

  • Commutateur latéral XC

  • Commutateur de protection sur les ports SONET, s'il existe une protection

  • réinitialisation logicielle de carte ML

  • Réinstallation de la carte ML

Le voisin CDP ne s'affiche pas

Vérifiez si vous avez activé le protocole CDP sur les deux interfaces.

Dépannez les alarmes et les erreurs d'interface si elles existent.

Pas de flux de trafic de bout en bout

Vérifiez les configurations sur les deux périphériques finaux.

Dépannez les alarmes et les erreurs si elles existent.

Annexe : Configuration des tests de base et informations de commande

Cette section capture les informations de configuration de base pour tous les périphériques de ce test, qui sont utilisées comme base de référence pour le dépannage des problèmes.

7603a 

7603a#show run
Building configuration...

Current configuration : 3136 bytes
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 7603a
!
!
ip subnet-zero
!
!
!
mls flow ip destination
mls flow ipx destination
spanning-tree extend system-id
!
redundancy
 mode rpr-plus
 main-cpu
  auto-sync running-config
  auto-sync standard
!
!
!
interface GigabitEthernet1/1
 ip address 10.0.0.1 255.0.0.0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.1 0.0.0.0 area 0
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
!
end

7603a#show ip int bri
Interface              IP-Address     OK? Method Status                 Protocol
Vlan1                  unassigned     YES unset  administratively down  down

GigabitEthernet1/1     10.0.0.1       YES manual up                     up


7603a#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

7603a#show int gigabitEthernet 1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 0009.b7f4.76ca (bia 0009.b7f4.76ca)
  Internet address is 10.0.0.1/8
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is autonegotiation, media type is SX
  output flow-control is unsupported, input flow-control is unsupported, 1000Mb/s
  Clock mode is auto
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:01, output 00:00:45, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  L2 Switched: ucast: 5482 pkt, 516472 bytes - mcast: 1 pkt, 64 bytes
  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 0 pkt, 0 bytes
     5145 packets input, 405866 bytes, 0 no buffer
     Received 5107 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     332 packets output, 111641 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

7603a#show ip ospf neig

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.2          1   FULL/DR         00:00:38    10.0.0.2        GigabitEtherne
t1/1

7603b 

7603b#show run
Building configuration...

Current configuration : 1102 bytes
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 7603b
!
enable password cisco
!
ip subnet-zero
!
!
!
mls flow ip destination
mls flow ipx destination
spanning-tree extend system-id
!
redundancy
 mode rpr-plus
 main-cpu
  auto-sync running-config
  auto-sync standard
!
!
!
interface GigabitEthernet1/1
 ip address 10.0.0.2 255.0.0.0
 speed nonegotiate
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.2 0.0.0.0 area 0
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
 no login
!
end

Note that if GigE link does not come up, auto-negotiation may not be working. 
Auto-negotiation can be turned off to force the link to come up. 
Ensure both sides of the link are matching.

7603b#show ip int bri
Interface              IP-Address      OK? Method Status                Protocol
Vlan1                  unassigned      YES NVRAM  administratively down down

GigabitEthernet1/1     10.0.0.2        YES manual up                    up

7603b#show int gig 1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 000b.45b0.484a (bia 000b.45b0.484a)
  Internet address is 10.0.0.2/8
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX
  output flow-control is unsupported, input flow-control is unsupported, 1000Mb/s
  Clock mode is auto
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:01, output 00:00:04, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue :0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  L2 Switched: ucast: 5695 pkt, 534143 bytes - mcast: 3 pkt, 192 bytes
  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 0 pkt, 0 bytes
     5319 packets input, 395772 bytes, 0 no buffer
     Received 5172 broadcasts, 4 runts, 0 giants, 0 throttles
     4 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     413 packets output, 139651 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

7603b#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

C    10.0.0.0/8 is directly connected, GigabitEthernet1/1

7603b#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

.225ML 

.225ML12#show run
Building configuration...
Current configuration : 580 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname .225ML12
!
logging buffered 4096 debugging 
enable password cisco
!
ip subnet-zero
no ip routing
no ip domain-lookup
!
!
bridge 100 protocol ieee
!
!
interface GigabitEthernet0
 no ip address
 no ip route-cache
 bridge-group 100
!
interface GigabitEthernet1
 no ip address
 no ip route-cache
 shutdown
!
interface POS0
 no ip address
 no ip route-cache
 crc 32
 bridge-group 100
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
 exec-timeout 0 0
 no login
!
end

.225ML12#show ip int bri
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0       unassigned      YES unset  up                    up      
GigabitEthernet1       unassigned      YES unset  administratively down down    
POS0                   unassigned      YES unset  up                    up      

.225ML12#show int gig 0
GigabitEthernet0 is up, line protocol is up 
  Hardware is xpif_port, address is 000f.2475.8c04 (bia 000f.2475.8c04)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, 1000BaseSX, Auto-negotiation
  output flow-control is off, input flow-control is on
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:53, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     336 packets input, 111810 bytes
     Received 1 broadcasts (0 IP multicast)
     1 runts, 0 giants, 0 throttles
     1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 244 multicast
     0 input packets with dribble condition detected
     5369 packets output, 422097 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

.225ML12#show int pos 0
POS0 is up, line protocol is up 
  Hardware is Packet/Ethernet over Sonet, address is 000f.2475.8c00 
(bia 000f.2475.8c00)
  MTU 1500 bytes, BW 622080 Kbit, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ONS15454-G1000, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled 
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:32, output never, output hang never
  Last clearing of "show interface" counters 02:16:40
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     152 packets input, 26266640 bytes
     Received 0 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
              0 parity
     1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     4250 packets output, 351305 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

.225ML12#show ons alarm
Equipment Alarms
Active: None
Port Alarms
  POS0  Active: None
  POS1  Active: None
  GigabitEthernet0  Active: None
  GigabitEthernet1  Active: None

POS0
Active Alarms : None
Demoted Alarms: None

POS1
Interface not provisioned

This command shows all the defects that can be reported to CLI and TCC (via CTC).

.225ML12#show ons alarm defect
Equipment Defects
Active: None
Reportable to TCC/CLI: CONTBUS-IO-A CONTBUS-IO-B CTNEQPT-PBWORK
 CTNEQPT-PBPROT EQPT RUNCFG-SAVENEED ERROR-CONFIG 
Port Defects
  POS0 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 
  POS1 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 
  GigabitEthernet0 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 
  GigabitEthernet1 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 

POS0
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3

POS1
Interface not provisioned

This command shows all the active alarms.

.225ML12#show ons alarm failure
Equipment Alarms
Active: None
Port Alarms
  POS0  Active: None
  POS1  Active: None
  GigabitEthernet0  Active: None
  GigabitEthernet1  Active: None
POS0
Active Alarms : None
Demoted Alarms: None
POS1
Interface not provisioned

.225ML12#show control pos 0
Interface POS0
Hardware is Packet/Ethernet over Sonet 
PATH
  PAIS      = 0         PLOP      = 0         PRDI    = 0         PTIM = 0
  PPLM      = 0         PUNEQ     = 0         PPDI    = 0       
  BER_SF_B3 = 0         BER_SD_B3 = 0         BIP(B3) = 0          REI = 0
  NEWPTR    = 0         PSE       = 0         NSE     = 0       
Active Alarms : None
Demoted Alarms: None
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3
Link state change defects: PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3 
Link state change time   : 200 (msec)

DOS FPGA channel number  : 0
Starting STS (0 based)   : 0
VT ID (if any) (0 based) : 255
Circuit size           : STS-12c
RDI Mode               : 1 bit
C2 (tx / rx)           : 0x01 / 0x01
Framing                : SONET

Path Trace
 Mode            : off          
 Transmit String : 
 Expected String : 
 Received String : 
 Buffer          : Unstable
 Remote hostname :                         
 Remote interface:               
 Remote IP addr  :                 
B3 BER thresholds: 
SFBER = 1e-4,   SDBER = 1e-7

231 total input packets,  26294392 post-HDLC bytes
0 input short packets,  26294465 pre-HDLC bytes
0  input long packets , 0  input runt packets
1  input CRCerror packets , 0  input drop packets
0 input abort packets
0 input packets dropped by ucode

6392  total output packets, 527660  output pre-HDLC bytes
527812 output post-HDLC bytes

Carrier delay is 200 msec

.225ML12#show cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
.252ML12         POS0               148           T       ONS-ML1000POS0
7603a            Gig 0              121         R S I     Cat 6000  Gig 1/1

The following command  shows the detail bridge table. Note that 000b.45b0.484a
 is the address of Gig0 on 7603b.

.225ML12#show bridge ver
Total of 300 station blocks, 298 free
Codes: P - permanent, S - self
Maximum dynamic entries allowed: 1000
Current dynamic entry count: 2

BG Hash      Address      Action  Interface      VC    Age   RX count   TX count
100 02/0   000b.45b0.484a forward  POS0                 -    
100 BC/0   0009.b7f4.76ca forward  Gi0                  -    

Flood ports         
GigabitEthernet0    
POS0                

This command shows the same type of info as the above.

.225ML12#show sdm l2-switching forwarding bridge-group 100
MAC-Address   B-Group l3_int punt_da Out-int SPR-NodeId CAM-ADDR  STATE
-----------   ------- ------ ------- ------- ---------- --------  -----
0009B7F476CA  100     0      0       Gi0     ***        11        Used   
000B45B0484A  100     0      0       PO0     ***        12        Used   

.225ML12#show interface summary
 *: interface is up
 IHQ: pkts in input hold queue     IQD: pkts dropped from input queue
 OHQ: pkts in output hold queue    OQD: pkts dropped from output queue
 RXBS: rx rate (bits/sec)          RXPS: rx rate (pkts/sec)
 TXBS: tx rate (bits/sec)          TXPS: tx rate (pkts/sec)
 TRTL: throttle count

  Interface           IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
---------------------------------------------------------------------
* GigabitEthernet0      0     0    0     0     0    0     0    0    0
  GigabitEthernet1      0     0    0     0     0    0     0    0    0
* POS0                  0     0    0     0     0    0     0    0    0

NOTE:No separate counters are maintained for subinterfaces
     Hence Details of subinterface are not shown

.225ML12#show ons equipment-agent status 
EQA ---- phySlot: 12, eqptType: EQPT_L2SC, eqptID: 0x2403 ----
    curTCC: Tcc B
linkStatus:    Full    dbReq/Recv: 1  /  4   msgVerToEQM: 2
  socketFd:       0    pipeMsgAct:   No     hdrSizeToEQM: 28
 connTries:       0 connTimerFast:   No   hdrSizeFromEQM: 28
timingProv:   No
clock auto 1

.225ML12#show ons provisioning-agent message ports all
  ----- Backend Port (00) Data -----
  prov: yes   sts: 00   vt: 255   type: DOS   name:                                 
  
  ----- STS (00) Term Strip -----
  Admin State: IS        Direction: TX_RX_EQPT
  Type: 12 Sf: 1E-4 Sd: 1E-7 C2 tx/exp: 0x01 / 0x01
  PathTrace Format: 64Byte  Mode: OFF       
   expected: (not valid)
   send: valid: "\000\000\000\000"

  ----- VT (255) Term Strip not provisioned -----

  ----- STS (00) Xc Strip -----
  rate: 12  Admin: IS     
  Src  Port/STS: 0x09/0x00  STS Eqpt: 0x01
  Dest Port/STS: 0x06/0x00  UPSR STS Cont Dest: 0x00
  Prev STS Stich Dest Port/STS: 0xFF/0x00
  Next STS Stich Dest Port/STS: 0xFF/0x00

  ----- Backend Port (01) Data -----
  prov:  no   sts: xx   vt: xx   type: xxx   name: xxxxx

The following command retrieves the ONS provisioning information
 that is done via CTC.

.225ML12#show ons provisioning-agent message node-element 
  ----- NE Data -----
  Node Name: R27-15454c
  MAC Addr : 00 10 CF D2 70 92
  IP Addr      : 10.89.244.225
  Sub Net Mask : 255.255.255.192
  Dflt Router  : 10.89.244.193
  Lan IP Addr  : 10.89.244.225
  Lan Sub Mask : 255.255.255.192
  Day Savings  : 0x01
  Min from UTC : 480
  Node ID      : 0xFF
  Sync Msg Ver : 0x01
  Sync Msg Res Delta : -1
  Sync Msg Res Quality : 0x06
  XConA Eqpt ID : 0x00000201
  XConB Eqpt ID : 0x00000201   OSPF Node ID  : 0xCFD27092
  SDH Mode      : SONET

.252ML12 

The auto negotiation was turned off on Gig0 (see later).

.252ML12#show run
Building configuration...
Current configuration : 643 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname .252ML12
!
logging buffered 4096 debugging
enable password cisco
!
ip subnet-zero
no ip routing
no ip domain-lookup
!
!
bridge 100 protocol ieee
!
!
interface GigabitEthernet0
 no ip address
 no ip route-cache
 no speed
 no negotiation auto
 bridge-group 100
!
interface GigabitEthernet1
 no ip address
 no ip route-cache
 shutdown
!
interface POS0
 no ip address
 no ip route-cache
 crc 32
 bridge-group 100
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
 exec-timeout 0 0
 no login
!
end

.252ML12#show ip int brie
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0       unassigned      YES manual up                    up      
GigabitEthernet1       unassigned      YES NVRAM  administratively down down    
POS0                   unassigned      YES unset  up                    up      

The Gig0 interface showed carrier loss until it was forced up by turning off
 auto negotiation.

.252ML12#show int gig 0
GigabitEthernet0 is up, line protocol is up 
  Hardware is xpif_port, address is 000f.2475.8c4c (bia 000f.2475.8c4c)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, 1000BaseSX, Force link-up
  output flow-control is off, input flow-control is on
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:06, output 00:00:01, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     391 packets input, 125375 bytes
     Received 1 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 282 multicast
     0 input packets with dribble condition detected
     8489 packets output, 637084 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

.252ML12#show int pos 0
POS0 is up, line protocol is up 
  Hardware is Packet/Ethernet over Sonet, address is 000f.2475.8c48
 (bia 000f.2475.8c48)
  MTU 1500 bytes, BW 622080 Kbit, DLY 100 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ONS15454-G1000, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled 
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters 03:58:02
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     7396 packets input, 608413 bytes
     Received 0 broadcasts (0 IP multicast)
     0 runts, 0 giants, 0 throttles
              0 parity
     1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     267 packets output, 96676 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

.252ML12#show ons alarm
Equipment Alarms
Active: None
Port Alarms
  POS0  Active: None
  POS1  Active: None
  GigabitEthernet0  Active: None
  GigabitEthernet1  Active: None

POS0
Active Alarms : None
Demoted Alarms: None

POS1
Interface not provisioned

.252ML12#show ons alarm defect
Equipment Defects
Active: None
Reportable to TCC/CLI: CONTBUS-IO-A CONTBUS-IO-B CTNEQPT-PBWORK
 CTNEQPT-PBPROT EQPT RUNCFG-SAVENEED ERROR-CONFIG 
Port Defects
  POS0 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 
  POS1 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 
  GigabitEthernet0 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 
  GigabitEthernet1 
  Active: None
  Reportable to TCC: CARLOSS TPTFAIL 

POS0
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3

POS1
Interface not provisioned

.252ML12#show ons alarm failure
Equipment Alarms
Active: None
Port Alarms
  POS0  Active: None
  POS1  Active: None
  GigabitEthernet0  Active: None
  GigabitEthernet1  Active: None

POS0
Active Alarms : None
Demoted Alarms: None

POS1
Interface not provisioned

.252ML12#show contro pos 0
Interface POS0
Hardware is Packet/Ethernet over Sonet 
PATH
  PAIS      = 0         PLOP      = 0         PRDI    = 0         PTIM = 0
  PPLM      = 0         PUNEQ     = 0         PPDI    = 0       
  BER_SF_B3 = 0         BER_SD_B3 = 0         BIP(B3) = 0          REI = 0
  NEWPTR    = 0         PSE       = 0         NSE     = 0       
Active Alarms : None
Demoted Alarms: None
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3
Link state change defects: PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3 
Link state change time   : 200 (msec)

DOS FPGA channel number  : 0
Starting STS (0 based)   : 0
VT ID (if any) (0 based) : 255
Circuit size           : STS-12c
RDI Mode               : 1 bit
C2 (tx / rx)           : 0x01 / 0x01
Framing                : SONET

Path Trace
 Mode            : off          
 Transmit String : 
 Expected String : 
 Received String : 
 Buffer          : Unstable
 Remote hostname :                         
 Remote interface:               
 Remote IP addr  :                 

B3 BER thresholds: 
SFBER = 1e-4,   SDBER = 1e-7

7425 total input packets,  610493 post-HDLC bytes
0 input short packets,  610501 pre-HDLC bytes
0  input long packets , 0  input runt packets
1  input CRCerror packets , 0  input drop packets
0 input abort packets
0 input packets dropped by ucode

268  total output packets, 97061  output pre-HDLC bytes
97061 output post-HDLC bytes

Carrier delay is 200 msec

.252ML12#show cdp neigh
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                  S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
.225ML12         POS0               168           T       ONS-ML1000POS0
7603b            Gig 0              158         R S I     Cat 6000  Gig 1/1

.252ML12#show bridge verbose
Total of 300 station blocks, 300 free
Codes: P - permanent, S - self

Total of 300 station blocks, 298 free Codes: P - permanent, S – self

Maximum dynamic entries allowed: 1000 Current dynamic entry count: 2 
BG Hash       Address        Action  Interface    VC    Age   RX count   TX count 
100 02/0      000b.45b0.484a forward  Gi0             -     
100 BC/0      0009.b7f4.76ca forward  POS0            -      
Flood ports   GigabitEthernet0        POS0

.252ML12#show sdm l2-switching forwarding bridge-group 100
MAC-Address   B-Group l3_int punt_da Out-int SPR-NodeId CAM-ADDR  STATE
-----------   ------- ------ ------- ------- ---------- --------  -----
000B45B0484A  100     0      0       Gi0     ***        11        Used   
0009B7F476CA  100     0      0       PO0     ***        16        Used   

.252ML12#show int summ
 *: interface is up
 IHQ: pkts in input hold queue     IQD: pkts dropped from input queue
 OHQ: pkts in output hold queue    OQD: pkts dropped from output queue
 RXBS: rx rate (bits/sec)          RXPS: rx rate (pkts/sec)
 TXBS: tx rate (bits/sec)          TXPS: tx rate (pkts/sec)
 TRTL: throttle count
  Interface           IHQ   IQD  OHQ   OQD  RXBS RXPS  TXBS TXPS TRTL
---------------------------------------------------------------------
* GigabitEthernet0      0     0    0     0     0    0     0    0    0
  GigabitEthernet1      0     0    0     0     0    0     0    0    0
* POS0                  0     0    0     0     0    0     0    0    0
NOTE:No separate counters are maintained for subinterfaces
     Hence Details of subinterface are not shown

.252ML12#show ons equipment-agent status
EQA ---- phySlot: 12, eqptType: EQPT_L2SC, eqptID: 0x2403 ----
    curTCC: Tcc A
linkStatus:    Full    dbReq/Recv: 1  /  5   msgVerToEQM: 2
  socketFd:       0    pipeMsgAct:   No     hdrSizeToEQM: 28
 connTries:       0 connTimerFast:   No   hdrSizeFromEQM: 28
timingProv:   No
clock auto 1

.252ML12#show ons provisioning-agent message ports all
  ----- Backend Port (00) Data -----
  prov: yes   sts: 00   vt: 255   type: DOS   name:                                 
  
  ----- STS (00) Term Strip -----
  Admin State: IS        Direction: TX_RX_EQPT
  Type: 12 Sf: 1E-4 Sd: 1E-7 C2 tx/exp: 0x01 / 0x01
  PathTrace Format: 64Byte  Mode: OFF       
   expected: (not valid)
   send: valid: "\000\000\000\000"

  ----- VT (255) Term Strip not provisioned -----

  ----- STS (00) Xc Strip -----
  rate: 12  Admin: IS     
  Src  Port/STS: 0x09/0x00  STS Eqpt: 0x01
  Dest Port/STS: 0x06/0x00  UPSR STS Cont Dest: 0x00
  Prev STS Stich Dest Port/STS: 0xFF/0x00
  Next STS Stich Dest Port/STS: 0xFF/0x00

  ----- Backend Port (01) Data -----
  prov:  no   sts: xx   vt: xx   type: xxx   name: xxxxx

.252ML12#show ons provisioning-agent message node-element 
  ----- NE Data -----
  Node Name: r26-15454a
  MAC Addr : 00 10 CF D2 40 52
  IP Addr      : 10.89.244.252
  Sub Net Mask : 255.255.255.192
  Dflt Router  : 10.89.244.193
  Lan IP Addr  : 10.89.244.252
  Lan Sub Mask : 255.255.255.192
  Day Savings  : 0x01
  Min from UTC : 480
  Node ID      : 0xFF
  Sync Msg Ver : 0x01
  Sync Msg Res Delta : 0
  Sync Msg Res Quality : 0x00
  XConA Eqpt ID : 0x00000201
  XConB Eqpt ID : 0x00000201
  OSPF Node ID  : 0xCFD24052
  SDH Mode      : SONET

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
14-Nov-2005
Première publication

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco

Ce document s’applique à ces produits