Dépannage des alarmes de la couche physique sur les liaisons SONET et SDH

Introduction

Ce document explique les alarmes communes SONET et comment les résoudre.

La surveillance des alarmes utilise deux termes :

• État : condition signalée ou détectée. Un périphérique SONET entre dans un état lorsque le périphérique détecte l'occurrence d'un événement. Un périphérique SONET quitte cet état lorsque le périphérique ne détecte plus l'événement. Ce document traite de la perte du signal (LOS) et de l’état de perte de trame (LOF).

• Indication : déclenchée par un changement d'état. Indique la présence d'une condition. Ce document traite du signal d'indication d'alarme (AIS), de l'indicateur de défaut distant (RDI) et des indications de défaillance de réception distante (FERF).

Les alarmes ou défauts actifs maintiennent une interface en état down/down. Le processus utilisé pour dépanner les interfaces SONET down/down est similaire à celui des interfaces numériques, telles que T1 et T3.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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.

Alarmes sur les couches SONET

L'équipement SONET détecte les événements et les alarmes sur chacune des trois couches de SONET : section, ligne et chemin. En règle générale, un périphérique SONET envoie des alarmes en amont et en aval afin d'informer les autres périphériques de l'état du problème.

Émettez la commande pos report afin de configurer les alarmes que l'interface POS (packet over SONET) peut activer.

RTR12410-1(config)#interface pos 2/1
   RTR12410-1(config-if)#pos report ? 
  all     all Alarms/Signals 
  b1-tca  B1 BER threshold crossing alarm 
  b2-tca  B2 BER threshold crossing alarm 
  b3-tca  B3 BER threshold crossing alarm 
  lais    Line Alarm Indication Signal 
  lrdi    Line Remote Defect Indication 
  pais    Path Alarm Indication Signal 
  plop    Path Loss of Pointer 
  prdi    Path Remote Defect Indication 
  rdool   Receive Data Out Of Lock 
  sd-ber  LBIP BER in excess of SD threshold 
  sf-ber  LBIP BER in excess of SF threshold 
  slof    Section Loss of Frame 
  slos    Section Loss of Signal

La commande show controllers affiche le nombre de fois qu'une alarme est déclarée et si des alarmes sont actives sur une interface POS et ATM sur SONET. Ce résultat a été capturé sur un routeur de commutation Gigabit (GSR). La section Active Defects indique ce que l'interface locale voit. La section Alarmes actives indique ce que le périphérique en amont signale.

RTR12410-1#show controller pos 1/0
POS1/0 
SECTION 
  LOF = 1         LOS    = 1                       BIP(B1) = 31165 
LINE 
  AIS = 1         RDI    = 0     FEBE = 0          BIP(B2) = 0 
PATH 
  AIS = 1         RDI    = 1     FEBE = 0          BIP(B3) = 25614 
  LOP = 0         NEWPTR = 1     PSE  = 0          NSE     = 0 
Active Defects: SLOF SLOS B1-TCA LAIS PAIS PRDI B3-TCA 
Active Alarms:  SLOS B1-TCA B3-TCA 
Alarm reporting enabled for: SF SLOS SLOF B1-TCA B2-TCA PLOP B3-TCA

Cet exemple de sortie a également été capturé à partir d'un GSR. Le message LINK-3-UPDOWN indique que la couche physique est active et que toutes les alarmes actives sont maintenant claires. Le message LINEPROTO-5-UPDOWN indique que le protocole de ligne est actif ; le protocole de ligne sur les interfaces POS est Frame Relay, HDLC (High-Level Data Link Control) ou PPP (Point-to-Point Protocol).

Aug  7 05:14:37 BST: %LINK-3-UPDOWN: Interface POS4/7, changed state 
     to up 
     Aug  7 05:14:38 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
     POS4/7,changed state to up 
     Aug  7 05:14:49 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:14:52 BST: %SONET-4-ALARM:  POS4/7: LRDI 
     Aug  7 05:15:02 BST: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
     POS4/7, changed state to down 
     
! --- Router receives the Line Remote Defect Indicator (LRDI) ! --- and brings down the line protocol.
 
      
     Aug  7 05:15:13 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:16:42 BST: %SONET-4-ALARM:  POS4/7: LRDI 
     Aug  7 05:16:45 BST: %SONET-4-ALARM:  POS4/7: SLOS 
     Aug  7 05:16:47 BST: %LINK-3-UPDOWN: Interface POS4/7, changed state 
     to down 
     Aug  7 05:16:56 BST: %SONET-4-ALARM:  POS4/7: LRDI cleared      
     Aug  7 05:16:56 BST: %SONET-4-ALARM:  POS4/7: PRDI 
     Aug  7 05:17:49 BST: %SONET-4-ALARM:  POS4/7: LRDI

Remarque : afin de capturer des horodatages granulaires sur les messages de journal, configurez la commande service timestamps log datetime msec.

Un routeur avec des interfaces ATM sur SONET signale également des alarmes actives avec ces messages de journal :

Feb 18 16:34:22.309: %SONET-4-ALARM: ATM5/0: ~SLOF SLOS LAIS ~LRDI PAIS PRDI ~PLOP

Le caractère "~" indique que l'alarme particulière n'est pas active et l'absence du caractère ~ indique que l'alarme est active. Dans cet exemple de sortie, ~SLOF indique qu'il n'y a pas de perte de section d'erreurs de trame. Cependant, l'interface rencontre plusieurs autres alarmes actives, notamment la perte de section du signal (SLOS) et le signal d'alarme de ligne (LAIS).

Indicateurs d'alarme

En règle générale, une condition de défaillance détectée par un périphérique SONET entraîne une ou plusieurs conditions d’erreur envoyées en amont et en aval sur le réseau. Un AIS est envoyé afin d'alerter les périphériques en aval d'un problème et d'empêcher les défaillances ou alarmes en aval qui en découlent d'être déclenchées. Une alarme RDI est envoyée en amont en tant que mécanisme de contrôle et de rétroaction pour le réseau. RDI était auparavant appelé FERF.

Le RDI est différent du REI (Remote Error Indicator). Le REI communique les valeurs de surveillance des performances, telles que les taux d'erreur de bit.

Dépannage

Utilisez ce tableau pour isoler et dépanner les alarmes SONET. Notez la couche SONET sur laquelle les erreurs et les alarmes sont détectées lors du dépannage. Par exemple, exécutez un test étendu de la liaison de bout en bout si les interfaces POS signalent uniquement des erreurs de couche de chemin. Notez également ce que les périphériques en amont et distants voient.

router(config-if)# [no] pos framing-sdh

Dépannage avec les commandes de bouclage

Le test de bouclage vous permet de tester la connexion entre l'interface OC-3 et un périphérique distant afin de dépanner, détecter et isoler les dysfonctionnements de l'équipement. La commande loopback place une interface en mode bouclage interne (également appelé bouclage local) ou en mode bouclage de ligne, ce qui permet aux paquets de test générés à partir de la commande ping de passer en boucle par un périphérique distant ou un câble. Si les paquets terminent la boucle, la connexion est bonne. Si ce n'est pas le cas, vous pouvez isoler une panne sur le périphérique distant ou sur le câble dans le chemin du test de bouclage.

Avec le bouclage interne, notez :

• Lorsque vous configurez un bouclage, assurez-vous de configurer l'interface pour la synchronisation interne à l'aide de la commande clock source internal. Le trameur attend les trames valides entrantes avec lesquelles synchroniser et utilise ces trames pour chronométrer sa transmission, lorsqu'il est configuré pour la ligne source d'horloge. Sans trames de réception, vous n'avez pas de synchronisation pour envoyer des trames.

• Si vous faites une boucle matérielle — en d'autres termes, vous retournez la fibre sur l'interface — assurez-vous d'utiliser un atténuateur si vous utilisez une interface monomode. Si ce n'est pas le cas, vous pouvez faire exploser l'interface avec trop de puissance ou même endommager l'optique de la carte s'il s'agit d'une carte longue portée ou si la transmission envoie des données supérieures à ses niveaux nominaux.

Configurer une interface pour le bouclage interne

Le paramètre de bouclage par défaut est pour no loopback. Avec le bouclage interne (ou local), les paquets du routeur sont bouclés de nouveau dans le trameur. Les données sortantes sont renvoyées en boucle au récepteur sans être réellement transmises. Le bouclage interne est utile pour vérifier que l'interface POS fonctionne. Afin de configurer une interface pour le bouclage interne, émettez la commande loop internal :

Router(config)#interface pos 3/0
Router(config-if)#loop internal

Configurer une interface pour le bouclage de ligne

Le paramètre de bouclage par défaut est pour no loopback. Avec le bouclage de ligne, la fibre de réception (Rx) est logiquement connectée au câble à fibre optique de transmission (Tx), de sorte que les paquets du routeur distant y sont renvoyés en boucle. Les données entrantes sont bouclées et retransmises sans être réellement reçues. Afin de configurer une interface pour le bouclage de ligne, émettez la commande loop line line :

Router(config)#interface pos 3/0
Router(config-if)#loop line

Remarque : La commande loopback line fait boucler le signal avant le trameur SONET.

Configurer les déclencheurs de délai SONET

Un déclencheur est une alarme qui, lorsqu'elle est affirmée, entraîne la désactivation du protocole de ligne. Ces sections traitent des déclencheurs de ligne et de chemin, que vous configurez avec la commande pos delay triggers.

RTR12410-1(config)#interface pos 1/0 
   RTR12410-1(config-if)#pos delay triggers ? 
  line  Specify delay for SONET LINE level triggers (S-LOS, S-LOF, L-AIS) 
  path  Enable SONET PATH level triggers (P-AIS, P-RDI), with optional delay 
RTR12410-1(config-if)#pos delay triggers line ? 
  <0-511>  Holdoff time, in msec 
  <cr>

Déclencheurs de ligne et de section

Utilisez la commande pos delay triggers line pour les interfaces POS de routeur Internet connectées aux systèmes DWDM (Dense Wavelength Division Multiplexing) protégés en interne (documentés sous CSCdm36033 et CSCdp65436 sur les routeurs de la gamme Cisco 12000 et CSCdr79 41 sur les routeurs des gammes Cisco 7200 et 7500). Cette commande n'est pas valide pour les interfaces configurées comme APS fonctionnant ou protégées. Normalement, même quelques microsecondes d'alarmes au niveau de la ligne ou de la section (SLOS, SLOF ou LAIS) mettent la liaison hors tension jusqu'à ce que l'alarme soit dégagée pendant dix secondes. Si vous configurez la mise hors service, ce déclencheur de liaison descendante est retardé de 100 ms. Si l'alarme reste allumée pendant plus de 100 ms, la liaison est désactivée telle quelle. Si l'alarme se déclenche avant 100 ms, la liaison n'est pas désactivée.

Par défaut, ces alarmes de ligne et de section sont des déclencheurs pour que le protocole de ligne tombe en panne :

• Perte de section du signal

• Perte de section de trame

• Signal d'alarme de ligne

Le protocole de ligne de l’interface s’arrête sans délai lorsqu’une ou plusieurs de ces alarmes sont affirmées. Vous pouvez émettre la commande pos delay triggers line afin de retarder l'arrêt du protocole de ligne de l'interface. Vous pouvez définir le délai de 0 à 511 ms. Le délai par défaut est défini sur 100 ms si vous ne spécifiez pas d'intervalle de temps.

Déclencheurs de niveau de chemin

Ces alarmes de chemin ne sont pas des déclencheurs par défaut. Vous pouvez configurer ces alarmes de chemin en tant que déclencheurs et également spécifier un délai :

• Signal d'indication d'alarme de chemin

• Indication du défaut distant du chemin

• Perte de chemin du pointeur

Vous pouvez émettre la commande pos delay triggers path afin de configurer diverses alarmes de chemin comme déclencheurs et afin de spécifier un délai d'activation compris entre 0 et 511 ms. La valeur de délai par défaut est 100 ms.

La configuration du chemin des déclencheurs de délai post peut également faire tomber le protocole de ligne lorsque le plus haut des taux d'erreur B2 et B3 est comparé au seuil de défaillance du signal (SF). Si le seuil SF est franchi, le protocole de ligne de l’interface tombe en panne.

La commande pos delay triggers path a été introduite dans le logiciel Cisco IOS® Version 12.0(16)S.

MIB SONET

Les interfaces SONET de Cisco prennent également en charge la base MIB SONET, définie dans RFC (Request for Comments ). La RFC utilise la même terminologie afin de décrire les conditions d'erreur sur un circuit SONET que les normes ANSI pour SONET et sur un circuit SDH (Synchronous Digital Hierarchy) par la spécification G.783 de l'UIT-T (International Telecommunications Union).

Pour la prise en charge de la base MIB SONET sur les interfaces Cisco POS et ATM sur SONET, reportez-vous aux ressources suivantes :

• MIB Cisco - Répertorie les MIB prises en charge par plate-forme, ainsi que les chaînes d'ID d'objet et les fichiers .my pour la MIB SONET.

• Gamme Cisco 7000 et 12000 - Notes de version pour la version 12.0 S - Décrit les améliorations apportées à la prise en charge de la base MIB SONET par Cisco.

Informations connexes

• Pages de support matériel optique
• Pages de soutien de la technologie optique
• Support technique - Cisco Systems

Historique de révision