Déclencheurs SONET

Introduction

Un déclencheur est tout événement qui remplit le rôle de cause dans la relation de cause à effet dans une interface SONET (Synchronous Optical Network) dans IOS. Parfois, vous pouvez utiliser la commande pos delay triggers. Dans d'autres cas, Cisco vous recommande de ne pas utiliser la commande pos delay triggers, en particulier lorsque vous tentez de respecter des contrats de niveau de service (SLA) serrés. Les fournisseurs de services vendent des niveaux de service différenciés en fonction de certains accords. Les accords traitent de la manière dont le réseau achemine, protège ou hiérarchise le trafic client en interne. Ces commandes aident les fournisseurs à configurer les réseaux pour qu'ils respectent les contrats de service.

Ce document examine les déclencheurs qui se rapportent aux événements d'interface actif et inactif. Ce document explique également comment déployer Packet Over SONET (POS) et prend en compte les SLA et les temps de convergence au niveau de la couche 3.

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.

Événements qui arrêtent une interface POS

Cette section décrit les événements qui désactivent une interface POS et répertorie les commandes associées.

Déclencheurs de niveau section et ligne

La liste des déclencheurs de cette section fait référence aux systèmes de transport SONET (Synchronous Optical Network) GR-253-CORE : Spécification Common Generic Criteria :

• Section Loss of Signal (SLOS) : la spécification indique que vous devez détecter au moins 2,5 us et au plus 100 us (6.2.1.1.1).

• Section Loss of Frame (SLOF) : la spécification indique que vous devez le détecter dans un minimum de 3 ms (ou 24 patchs de tramage en erreur consécutifs) (6.2.1.1.2).

• Signal d'indication d'alarme - Ligne (AIS-L) : l'AIS-L doit être envoyé le cas échéant, dans un délai de 125 secondes à compter de la détection. Un périphérique doit détecter la réception de l'AIS-L si le périphérique voit 5 trames consécutives où les bits 6,7 et 8 de K2 sont définis sur 111 (6.2.1.2.1).

• Taux d'erreur de bit de dégradation du signal (SD-BER) : SD-BER est un déclencheur uniquement sur les interfaces avec la commutation de protection automatique (APS) (liée au calcul BER B2).

• Fréquence d'erreur de bit de défaillance du signal (SF-BER) : SF-BER est un déclencheur pour les interfaces APS et non APS (lié au calcul BER B2).

• Remote Defect Indication - Line (RDI-L) : RDI-L n'est pas un déclencheur pour POS ou APS. (Toutefois, RDI-L est un déclencheur pour la FRR MPLS) (section 5.3.3.1).

Pour plus d'informations sur les sections mentionnées dans cette liste, consultez le site Telcordia Information SuperStore .

Commandes associées

La commande pos delay triggers line n désactive LOS/LOF/AIS pendant n ms avant que la commande ne déclenche la ligne vers le bas :

Si vous configurez la commande sans valeur numérique, le délai est de 100 ms par défaut. Vous pouvez utiliser des déclencheurs de ligne sur n'importe quelle interface POS non APS. Vous ne pouvez pas utiliser de déclencheurs de ligne sur les interfaces qui participent à APS, car les déclencheurs de ligne interfèrent avec le fonctionnement d'APS. La commande pos delay triggers line n ne permet pas à la ligne de descendre sur le court LOS qui provient de l'équipement DWDM (Dense Wavelength-Division Multiplexing) protégé en interne, à partir du moment où un commutateur de protection DWDM interne se produit. Si le défaut se dissipe pendant la période de retenue, c'est comme si le défaut n'était jamais survenu.

La commande pos delay triggers line retient toute action basée sur le défaut (sauf pour incrémenter le compteur de défaut) jusqu'à la fin de la période de retenue spécifiée.

Si vous n'activez pas cette commande, APS et la liaison descendante à partir des défauts SONET ci-dessus sont déclenchés immédiatement dans le processeur de routage (RP).

Déclencheurs de chemin

Ces défauts de niveau PATH spécifiques déclenchent un changement d'état uniquement si vous avez activé le chemin des déclencheurs de délai post sur l'interface :

• AIS-P : ce défaut doit être déclenché dans un délai de 125usec à partir de la détection du défaut qui entraîne l'AIS-P. Le PTE (Path Terminating Equipment) doit détecter ce défaut lorsque les octets H1 et H2 d'un chemin STS contiennent tous des 1 pour 3 trames consécutives. Les chemins concaténés doivent observer uniquement les premiers octets H1 et H2. Pour plus d'informations, reportez-vous à la section 6.2.1.2.2 de R6-175 et R6-176.

• RDI-P : si RDI-P est présent, le défaut doit être détecté dans les 10 trames. Voir 6.2.1.3.2 de R6-221.

• B3-TCA (Threshold Crossing Alarms) pour B3 : cette alarme est liée au calcul BIP (Bisync) B3.

• LOP-P (Path Loss of Pointer) (si la version IOS inclut CSCdx58021)—Voir la section 6.2.1.1.3 de GR-253.

Pour plus d'informations sur les sections mentionnées dans cette liste, consultez le site Telcordia Information SuperStore .

Commande associée

La commande pos delay triggers path <msec> active le déclenchement de liaison descendante sur les erreurs AIS-P, RDI-P et B3 excessives. Par défaut, le déclenchement de liaison descendante pour les erreurs de chemin est désactivé.

La commande spécifie également un temps d'arrêt compris entre 0 et 511 ms (la valeur par défaut est 100 ms). Les défauts de déclenchement du chemin (AIS-P, RDI-P) qui s'effacent avant la fin de la période de retenue ne provoquent pas de déclenchement. Lorsque vous n'avez pas explicitement configuré cette commande sur une interface POS, aucune action ne se produit si les défauts de niveau PATH sont traités. Contrairement aux déclencheurs de ligne, les interfaces APS autorisent les déclencheurs de chemin, car les déclencheurs de chemin n'interfèrent pas avec l'activité au niveau de la ligne d'APS. Les déclencheurs de chemin n'ont pas été autorisés à être configurés avec APS dans des versions antérieures à la version 12.0(28)S du logiciel Cisco IOS®. Des déclencheurs de chemin ont été ajoutés afin d'accélérer le comportement de liaison ascendante/descendante des interfaces POS lorsqu'elles sont connectées aux réseaux SONET. Cela a permis une convergence de couche 3 plus rapide en présence d'erreurs distantes.

Résumé du comportement CLI des déclencheurs POS

Ce tableau répertorie les conditions des déclencheurs POS et les résultats associés :

Condition	Résultat
Si vous n'avez configuré aucun élément explicitement lié aux déclencheurs POS.	Les déclencheurs de niveau de ligne sont traités immédiatement.
Si vous avez configuré la commande de ligne de déclencheurs de délai post.	Les déclencheurs de niveau de ligne sont traités après un délai de 100 ms.
Si vous avez configuré la commande pos delay triggers line x.	Les déclencheurs de niveau de ligne sont traités après x msecs, où x est compris entre 0 et 511.
Si vous n'avez configuré aucun élément explicitement lié aux déclencheurs de chemin.	Les déclencheurs de chemin ne sont pas traités et n'entraînent aucune action.
Si vous avez configuré la commande pos delay triggers path.	Les déclencheurs de niveau de chemin sont traités après un délai de 100 ms.
Si vous avez configuré la commande pos delay triggers path x.	Les déclencheurs de niveau de chemin sont traités après x msecs, où x est compris entre 0 et 511.

Débat des alarmes SONET

Les alarmes SONET résultant de défauts sont conservées pendant 10 secondes (10,5 +-,5) après le nettoyage du défaut.

Gestion des défauts

Dans IOS, les cartes POS changent d'état LINE en raison de déclencheurs différents, via deux moyens généraux de traitement des défauts. Bien que cela dépend de la configuration spécifique de l'interface (APS ou non-APS), il existe en général deux types de défaillances :

• Géré

• Non géré

Vous devez comprendre les termes spécifiques à la gestion des alarmes utilisés dans ce document :

• Defect : condition de défaillance reconnue par le matériel.

• Défaillance : défaut qui a été détecté pendant environ 2,5 secondes, puis signalé par les messages SONET-4-ALARM. Tout défaut qui est un déclencheur n'est pas trempé.

• Échecs non gérés : événements tels que LOS, LOF, etc. Ils sont détectés par le trameur SONET par un ensemble de paramètres défini et ne nécessitent aucun calcul. Il y a soit un défaut présent et affirmé par le matériel, soit il n'y a aucun défaut. Les pannes graves comme celles-ci, en général, sont traitées par des interruptions. LOS, LOF, AIS-L, et dans certains cas, AIS-P et RDI-P sont immédiatement affirmés. Celles-ci dépendent du concepteur et des règles définies pour détecter chacun de ces défauts. L'effet de ces défauts est immédiat. Cependant, vous pouvez demander au routeur de retarder l'assertion de ce défaut en tant qu'échec. Il y a deux temporisateurs qui déterminent la valeur de délai, pos delay triggers [chemin] | line] et le délai de porteuse. Ces questions sont abordées plus loin dans le document.

• Alarmes gérées : événements tels que les TCA et les calculs SD/SF-BER. Ces éléments nécessitent un certain calcul pour déterminer s'ils sont présents, s'ils sont en augmentation ou en diminution, etc. Par exemple, vous ne pouvez pas avoir un LOS qui augmente sa ” de LOS “ du point de vue du routeur. Cependant, vous pouvez avoir un BER en augmentation ou en diminution ; les mesures prises peuvent être différentes. Les échecs logiciels, tels que BER et TCA, nécessitent un certain calcul, car ils dépendent d'un certain nombre de facteurs, par exemple les seuils qu'un utilisateur peut configurer, le débit binaire et le nombre maximal de CV BIP (car ils sont différents pour B1, B2 et B3). Ces défaillances prennent également plus de temps à être détectées, car le matériel est interrogé pour les compteurs BIP, et aussi parce que ces types de défauts sont de nature progressive et cumulés au fil du temps. Il est également vrai qu'en général, vous ne passez pas de 0 BIP directement à une dégradation du signal (SD) ou à une défaillance du signal (SF) sans qu'un autre type de défaillance matérielle ne soit présent dans le réseau. Ces défauts sont plus lents à se produire que les pannes dures.

Voici une approche générale des calculs de base qui décrit comment calculer le BER :

Après chaque redémarrage des calculs et jusqu'à ce que BER_Period atteigne Required_BER_Period (la fenêtre d'intégration n'est pas entièrement déployée), l'algorithme fonctionne strictement comme un algorithme d'intégration ou de moyenne :

• BER_Period = BER_Period + 1 sec.

• Current_BIP = Current_BIP + BIP_new.

• Current_BER = Current_BIP/BER_Period.

Après que BER_Period ait atteint Required_BER_Period (la fenêtre d'intégration a été entièrement déployée et commence à glisser), l'algorithme fonctionne comme un segment fuyant :

• BER_Period = Required_BER_Period.

• Current_BIP = Current_BIP + BIP_new - Current_BER * 1 sec.

• Current_BER = Current_BIP/BER_Period.

La valeur Required_BER_Period est déterminée uniquement en fonction du débit de ligne et du seuil BER configuré, conformément aux normes (voir figure 5-5, Critères de temps d'initialisation du commutateur, GR-253). Cependant, il est inférieur à 1 seconde, notre taux d'échantillonnage.

Ainsi, la fenêtre BER_Period (intégration) se déplace avec chaque sondage, et un nouveau BER est calculé avec chaque sondage. Si Current_BER dépasse une limite définie, nous soulevons immédiatement le défaut approprié au cours du même sondage ou intervalle de calcul, et nous conservons la réponse minimale. Nous répétons ces calculs chaque seconde et vérifions si l'un des trois événements s'est produit :

• Le BER se situe toujours dans la même plage. Il n'y a pas de nouvelle action.

• Le BER a à nouveau augmenté et a franchi un seuil SD ou SF (pour B2). Soulève une nouvelle alarme.

• Le BER a diminué en dessous d'un seuil BER. Effacez l'alarme.

Pour l'affirmation d'une TCA ou d'un SD/SF, vous devez attendre jusqu'à ce que vous ayez franchi une limite à cet intervalle d'interrogation respectif. Au moment du calcul, vérifiez si le paramètre Current_BER a franchi un seuil et, s'il l'a fait, vous pouvez aller de l'avant et insérer l'alarme immédiatement via le logiciel.

Ceci est valide car, si Current_BER est suffisamment grand pour déclencher l'alarme initialement, la condition est toujours vraie à la fin de BER_Period. Cela dépend de la façon dont les valeurs sont définies et comparées par rapport à la fenêtre de calcul.

Lorsque vous effacez une alarme, vous devez attendre la fin de la fenêtre de calcul BER_Period. Ceci permet de s'assurer qu'aucun nouveau BIP n'est cumulé au cours de la dernière partie de la fenêtre qui pourrait vous garder au-dessus d'un seuil.

Note : Selon GR-253, SD-BER et SF-BER sont tous deux strictement liés au nombre de BIP B2. Les seuils par défaut actuels sont les suivants :

• Seuils BER—SF = 10e-3 SD = 10e-6

• Seuils TCA—B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

Remarque : Les cartes Engine2 OC-48 ont les seuils par défaut suivants :

• Seuils BER—SF = 10e-4 SD = 10e-6

• Seuils TCA—B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

Si vous voulez que le déclencheur du chemin TCA B3 soit similaire à SF, le seuil B3 doit être défini sur le même seuil, 10e-3. Vous pouvez le faire via la commande pos threshold b3-tca 3 à l'invite router(config-if)#.

Remarque : Comme l'intervalle d'interrogation est d'une seconde, c'est la durée minimale pendant laquelle nous remarquerons et soulèverons un défaut TCA ou SD/SF. En outre, en raison de la nature cumulée de TCA/SD/SF, ces types de défaillances sont accompagnés d'autres défaillances lorsqu'elles se produisent rapidement dans des défaillances typiques. Ceci maintient un équilibre entre l'utilisation du processeur du routeur et les performances. Impossible de configurer l'intervalle d'interrogation.

Déclencheurs en action

Cette section fournit des informations de base pour examiner l'interaction de certains boutons réglables de l'utilisateur dans IOS :

Les déclencheurs du délai post [ligne] | path] retarde brièvement le signalement et l'action d'un défaut.

Ligne de déclenchement de délai POS est la durée d'attente avant de réagir à une alarme de ligne. La valeur par défaut est la réaction immédiate, ce qui signifie que la ligne 0 du déclencheur de délai post est définie. Si vous configurez directement la ligne de déclenchement de délai post sans aucune valeur, la valeur par défaut de 100 ms est prise en compte. Cela permet une réponse immédiate ou différée, en fonction de l'effet souhaité. Avec l'une ou l'autre de ces configurations, le défaut ne s'affiche pas en tant qu'alarme active tant que la période de retenue n'est pas terminée.

Chronologie :

|----------|----------|----------|----------|----------|
T0         T1         T2         T3         T4         T5

Ici :

• t0 : heure à laquelle le défaut se produit.

• t1 : heure à laquelle le matériel détecte le défaut.

• t2 : heure à laquelle le défaut est signalé comme une défaillance.

• t2-t3 : temps qui est mis hors tension pour tous les déclencheurs configurés.

• t3-t4 : durée pendant laquelle vous attendez en raison d'un retard de porteuse.

• t4 : heure à laquelle l'interface s'arrête dans IOS.

• t5 : heure à laquelle toute contiguïté pour un protocole de routage tombe en panne.

Examinez la chronologie pour voir comment ajuster les différents boutons pour obtenir différents résultats.

La commande Post delay triggers affecte la durée entre t2 et t3 et, en fait, masque le défaut de l'IOS, jusqu'à ce que la période de retenue soit terminée. Bien sûr, si le défaut est effacé avant que vous atteigniez t3, rien ne se produit, et c'est comme si rien ne s'était passé. La valeur par défaut des déclencheurs de ligne et de chemin est de 100 ms et la plage est de 0 à 511 ms. Les déclencheurs de chemin ne sont pas activés (en d'autres termes, ils n'effectuent aucune action), sauf si le chemin des déclencheurs de délai post est configuré pour la première fois. le chemin du déclencheur de retard post est le temps d'attente avant de réagir à une alarme de chemin. La valeur par défaut n'est pas une réaction. Si vous configurez directement le chemin du déclencheur de retard post sans valeur, la valeur par défaut 100 ms sera affectée automatiquement. Cela inclut AIS-P, RDI-P et B3-TCA. Cette fonctionnalité a été ajoutée via CSCds82814 (vers 12.0(15.5)S/ST).

Carrier-delay est le temps d'attente entre la fin du délai POS et il désactive l'interface IOS. La valeur par défaut est 2 000 ms. Le délai de porteuse est le délai entre t3 (lorsque l’IOS est informé d’une panne) et t4 (lorsque l’interface est désactivée). Par défaut, cette valeur est définie sur 2 secondes et peut être configurée pour les valeurs ms. Comme l'indique la chronologie, il s'agit d'une fonction additive au-dessus des compteurs de retenue de niveau SONET. Il se comporte de la même manière que les déclencheurs POS : si l'alarme se déclenche avant la fin de la période de retenue, l'interface n'est pas désactivée. Cependant, il y a un casse-tête ici. Le compteur de débit SONET ne supprime pas le défaut avant l'activation du délai de l'opérateur, sauf si le délai de l'opérateur est important (bien plus de 10 secondes). Cela se traduit par une situation où le délai de porteuse est presque toujours activé et doit donc être considéré comme assez faible lors d'un déploiement avec des interfaces POS. Le délai de porteuse est également ajouté une fois l'alarme effacée, avant que l'interface ne soit également déclarée. Par conséquent, vous pouvez compter la valeur du délai de porteuse deux fois avant que l'interface ne redémarre.

Avec certaines interfaces et certains supports physiques, ceci est utile. Cependant, avec les interfaces POS, vous pouvez utiliser un certain nombre de déclencheurs et de temporisateurs, et les combiner pour créer l'effet souhaité, sans délai porteur prenant un rôle si important. Une valeur de délai de porteuse de 0 à 8 ms est un bon point de départ pour les clients lorsqu'ils testent ces boutons par eux-mêmes. En général, une bonne stratégie consiste à utiliser la commande pos delay triggers pour absorber tout problème et fournir l'effet de retenue souhaité. Le délai de transmission peut être réduit pour minimiser son impact.

Le compteur de rebond SONET mentionné ci-dessus est défini à 10 secondes (+/- 0,5 sec) et est requis par GR-253 pour s'assurer qu'une période de rabattement inférieure à 10 secondes ne se produit pas. Le minuteur démarre une fois le défaut résolu. Le compteur est réinitialisé si un autre événement de défaut se produit avant l'expiration de la fenêtre du compteur.

Chronologie :

|----------|----------|----------|----------|----------|---------|
T0         T1         T2         T3         T4         T5        T6

Ici :

• t0 : le défaut s'efface.

• t0 : le compteur de rebond démarre.

• t4—t0 + 10sec (par conséquent, la défaillance doit être effacée si aucun nouveau défaut ne se produit entre t0 et t4).

Si un événement se produit avant t4, (disons) à t2 (il peut s'agir d'un autre défaut, ou d'une réoccurrence du même type de défaut), le compteur est arrêté jusqu'à ce que ce nouveau défaut soit effacé. À t3, le compteur recommence, lorsqu'il n'y a pas de défauts actifs, et compte pour environ 10 secondes. Si aucun nouvel événement n'est détecté, effacez l'alarme à t5, puis démarrez le temporisateur de délai de porteuse. Lorsque le délai de porteuse a été effacé à t6, réactivez l’interface.

Ces informations devraient permettre au client de comprendre plus clairement comment les interfaces POS réagissent aux différentes conditions SONET/SDH. Cela permet de configurer l'équipement plus précisément en fonction du comportement prévu par le client.

Pourquoi utiliser des déclencheurs ?

Cette section explique quand vous devez utiliser les déclencheurs de délai post [ligne] | path] et lorsque vous ne devez pas l'utiliser.

Voici les scénarios dans lesquels vous ne devez pas utiliser de déclencheurs de délai post. Il existe plusieurs scénarios :

• Vous ne pouvez pas utiliser de déclencheurs de ligne avec des interfaces configurées APS. Les versions antérieures à la version 12.0(28)S du logiciel Cisco IOS n'autorisaient même pas l'utilisation de déclencheurs de chemin.

• Lorsque vous ne voulez pas explicitement que les défauts de niveau PATH désactivent l'interface, vous ne pouvez pas utiliser ces déclencheurs.

• Lorsque vous souhaitez que les déclencheurs de niveau ligne désactivent l'interface sans délai, vous ne pouvez pas utiliser cette commande.

Voici les scénarios dans lesquels vous pouvez utiliser la commande pos delay triggers :

• Lorsque vous souhaitez suspendre temporairement l'effet d'un défaut de niveau de ligne.

• Pour permettre aux défauts de niveau PATH de mettre immédiatement l'interface hors tension.

• Pour activer les défauts de niveau PATH pour faire tomber l'interface, mais avec une certaine retenue incluse.

SLA et déclencheurs POS

Examinez cette chronologie :

|----------|--------------------|
T0         T1                   T2

• Time t=0 (t0) : lorsque le défaut est détecté.

• Time t2 : heure de restauration SLA requise.

• Time t1 : toute retenue de la commande pos delay triggers qui est configurée (la valeur par défaut pour LINE est 0 et la valeur par défaut pour PATH n'est pas activée).

• X est la valeur de retenue (donc X = la valeur de t1).

• Y est le temps nécessaire à la couche 3 pour restaurer le service.

Théorie

Parfois, vous pouvez utiliser la commande pos delay triggers, alors que d'autres fois, vous ne pouvez pas le faire, surtout lorsque vous essayez de respecter des contrats de niveau de service (SLA) serrés.

Postulat

• Si Y > (t2-t1) pour une valeur quelconque de t1, une retenue n'est pas une bonne idée car vous ne pouvez pas respecter votre SLA si vous configurez une retenue.

• Si Y <= (t2-t1), vous pouvez envisager la mise en oeuvre d'une retenue. Si la durée de la panne est inférieure à (t1-t0), vous pouvez suspendre car, vous n'avez pas besoin d'utiliser les ressources du routeur et vous pouvez respecter le SLA souhaité. Si le défaut persiste au-delà du délai t1, vous pouvez toujours respecter le contrat de niveau de service, même si vous perdez un certain temps avant d'initier la restauration au niveau IP.

Vous devez connaître le réseau de transport sous-jacent et les temps de convergence du réseau de couche 3 afin de connaître les valeurs que vous pouvez utiliser dans ces formules. Vous devez également effectuer des tests.

Voici comment fonctionnent les déclencheurs :

• La commande pos delay triggers line n désactive LOS/LOF/AIS pendant n ms avant que la commande ne déverrouille la ligne. La valeur par défaut est 100 ms. Vous pouvez utiliser cette commande sur n'importe quelle interface POS non APS. La commande pos delay triggers line n ne permet pas à la ligne de descendre sur le LOS court qui provient de l'équipement DWDM protégé en interne, à partir du moment où un commutateur de protection DWDM interne se produit. Si le défaut se dissipe pendant la période de retenue, c'est comme si le défaut n'était jamais survenu.

• La commande pos delay triggers line arrête toute action basée sur le défaut (sauf pour incrémenter le compteur de défaut), jusqu'à la fin de la période de retenue spécifiée.

  Si vous n'activez pas cette commande, l'APS et la liaison inactive sont déclenchées immédiatement dans le RP.

Déploiement des déclencheurs SONET

Cette section décrit le déploiement des déclencheurs SONET.

Réseau SONET protégé : Pas d'APS sur les routeurs

Figure 1 - Réseau SONET protégé en interne

Le réseau SONET bénéficie d'une protection interne, ce qui signifie qu'une panne à l'intérieur du réseau SONET déclenche un commutateur de protection pour restaurer le service très rapidement. Par conséquent, vous devez déterminer si vous voulez mettre l’interface hors tension et notifier la couche 3. Dans la plupart des cas, lorsqu’un commutateur de protection se produit à l’intérieur du réseau SONET, les routeurs voient un AIS de ligne ou de chemin court pendant que le réseau effectue une action réparatrice. Cependant, cela se produit uniquement si la défaillance se situe à un saut de l'un ou l'autre des routeurs. Le réseau SONET peut être de plusieurs NE de diamètre, chaque routeur considère les défaillances de LIGNE uniquement comme des défaillances de PATH. Dans ce cas, prenez en compte les déclencheurs de chemin et de niveau de ligne si vous voulez une retenue.

Pour prendre cette décision, vous devez comprendre le coût associé aux deux approches. En tant qu'opérateur réseau, vous devez tenir compte des questions suivantes :

• Le réseau converge-t-il assez rapidement ? Sinon, cette approche n'est pas appropriée.

• Quel est l’impact du routage sur une telle défaillance ? L’impact sur le routeur est-il si important que les performances tombent en dessous d’un niveau acceptable ?

En fin de compte, vous devez décider si vous pouvez ignorer un choc potentiel d'environ 60 ms ou si vous préférez parcourir un tel événement. Si vous pouvez ignorer le résultat, vous devez identifier la quantité d'un facteur de “ fudge ” à ajouter car, vous ne voulez pas retenir ce défaut seulement pour attendre quelques millisecondes trop peu, et ainsi retarder les mesures correctives.

Dans ce scénario, la ligne et le chemin des déclencheurs de délai sont probablement suffisants. En outre, si une retenue est justifiée, il faut tenir compte de valeurs d'au moins 60 ms. Si le réseau est suffisamment large et que vous souhaitez prendre des mesures immédiates sur les défauts de ligne et de chemin, vous n'avez pas besoin de configurer des déclencheurs de niveau ligne. Cependant, vous devez configurer le chemin des déclencheurs de délai post avec une valeur de 0 pour permettre le traitement immédiat des défauts de niveau PATH.

Réseau SONET non protégé en interne

Figure 2 - Réseau SONET non protégé en interne

Dans un réseau SONET non protégé, vous exécutez les mêmes risques que dans le premier scénario, plus quelques autres. Si le réseau est suffisamment grand, les routeurs peuvent ne jamais voir de défaut de niveau LIGNE en cas de défaillance, car tous les défauts sont filtrés. Les routeurs peuvent voir des défauts de niveau PATH en amont et en aval. Ainsi, dans certaines situations, où une défaillance se produit au sein du réseau, le routeur ne voit que des événements de niveau PATH et il n’y a pas de continuité de bout en bout entre les routeurs. Pire encore, il n'y a pas de restauration au niveau SONET pour remédier à cette situation.

Dans ce scénario, vous devez configurer les déclencheurs de chemin simplement pour permettre aux routeurs de chaque extrémité d'agir lorsque les routeurs rencontrent un défaut de chemin d'accès, même si les routeurs ne veulent pas d'effet de blocage. Lorsque vous avez configuré des déclencheurs de chemin, en tant qu'opérateur réseau, vous devez vérifier s'il est préférable de suspendre ou de déclencher une restauration de couche 3.

Réseau SONET protégé ou non protégé

Figure 3 - Réseau SONET non protégé en interne

Dans le logiciel Cisco IOS Version 12.0(28)S, vous pouvez activer les déclencheurs PATH sur les circuits APS. Lorsque vous déployez l'APS sur les routeurs locaux ou distants, un commutateur APS entraîne un défaut de niveau PATH bref pour les routeurs de travail et de protection distants. Avec une petite valeur de déclenchement, les interfaces sont désactivées et cette situation n'est pas souhaitable. Une interface qui tombe en panne retarde la restauration du service déjà en cours. Une défaillance momentanée survenant dans le cloud peut également retarder la restauration du service. Cependant, l’occurrence d’une erreur persistante de niveau PATH indique que la protection du circuit (au sein du réseau ou à l’extrémité distante) n’a pas pu rétablir la connectivité. Dans ce cas, les routeurs APS doivent agir et initier la reconvergence du routage. Vous pouvez configurer des valeurs de délai de déclenchement du chemin d'accès de >= 100 ms. Avec cette configuration, lorsqu’une erreur persistante se produit au sein du réseau SONET ou à l’extrémité distante, les routeurs mettent les deux interfaces APS hors service. Par conséquent, les routeurs lancent un routage et une restauration plus rapides du service.

Réseau DWDM protégé

Figure 4 - Réseau DWDM protégé

Dans ce scénario, nous n'avons pas besoin d'utiliser les déclencheurs de chemin, car le réseau DWDM ne participe pas au niveau du protocole SONET. Le routeur détecte toute défaillance au niveau de la SECTION ou de la LIGNE.

Encore une fois, comme le réseau DWDM est protégé en interne, une défaillance interne au réseau entraîne une restauration prochaine. Le routeur voit généralement une très brève LOS, LOF ou une rafale d’erreurs BIP.

Par conséquent, vous n'avez qu'à décider si un blocage est souhaitable dans ce réseau.

La commande pos delay triggers line est suffisante dans cette situation, si vous choisissez un délai.

Réseau DWDM non protégé

Figure 5 : Réseau DWDM non protégé

Avec un réseau DWDM non protégé dans le transport, vous devez résoudre toute défaillance au sein des routeurs. Dans ce cas, la configuration par défaut permettrait une réponse immédiate à toute défaillance constatée sur l'un ou l'autre des routeurs, car le DWDM ne participe pas au protocole SONET. Si vous souhaitez cet effet, la configuration par défaut d'aucun déclencheur POS configuré est appropriée.

Si vous avez besoin d'une mise hors service, la commande pos delay triggers line suffit pour fournir cette fonctionnalité.

Routeurs connectés dos à dos

Figure 6 - Routeurs connectés dos à dos

Deux routeurs connectés dos à dos entre deux interfaces POS doivent fonctionner comme le dernier scénario. Vous pouvez voir immédiatement des défaillances sur l’un ou l’autre des routeurs, car aucun équipement intermédiaire ne fonctionne sur la surcharge SONET ou ne termine aucune partie du signal de niveau SONET.

Une situation intéressante est lorsque R1 voit S-LOS et R2 voit L-RDI et P-RDI, car R1 est à la fois un équipement de terminaison de ligne (LTE) et un équipement de terminaison de chemin (PTE). Puisque L-RDI désactive explicitement toute action résultante à la réception, R2 ne supprime pas l'interface en conséquence. Ce problème peut potentiellement conduire à une situation où une interface de R1 est désactivée, mais l'interface de R2 est toujours active et transfère le trafic. Bien sûr, tout keepalive de couche 2 (comme HDLC (High-Level Data Link Control) fournit) expire et déclare la liaison arrêtée, généralement en 30 secondes, en fonction des temporisateurs configurés. Cependant, plusieurs opérateurs désactivent ces keepalives de couche 2 et ne peuvent pas empêcher cette situation. Afin de résoudre ce problème, vous pouvez adopter plusieurs approches, et chaque approche aborde ce problème d'une perspective différente, comme expliqué ici :

• Activer les déclencheurs de chemin : lorsque P-RDI désactive une interface avec les déclencheurs de chemin activés, vous pouvez utiliser cette méthode pour générer une réponse rapide et supprimer l'interface. Il est intéressant de noter que L-RDI masque le P-RDI en fonctionnement normal conformément au GR-253. Lorsque les déclencheurs POS sont gérés au niveau du défaut, les déclencheurs sont traités avant le masquage d'alarme, et l'interface reste abandonnée en fonction du délai configuré.

• Enable Layer 2 Keepalives : cette option provoque l'expiration de l'interface sur R2 après 3 keepalives manqués. En règle générale, cette valeur est de 30 secondes au total (3 x 10) et Cisco ne recommande généralement pas cette option comme outil pour régler la convergence de liaison rapide.

• Enable a Link-State Routing Protocol : lorsque l'interface de R1 est désactivée en raison de S-LOS, un message d'état de liaison est envoyé immédiatement. Même si l’interface sur R2 peut toujours être active, lorsque le message d’état de la liaison est reçu dans toute la zone, SPF est exécuté et la liaison est supprimée de la topologie car la liaison échoue à la vérification de la connectivité bidirectionnelle. Cela empêche le réseau d’essayer de router à travers ce scénario simplex.

Notification à distance basée sur la qualité du signal

Lorsque vous connectez deux routeurs, dos à dos ou sur un réseau SONET, l'architecture OAM fournie couvre la détection d'une majorité de scénarios de panne.

En général, il existe des notifications locales et des notifications à distance. Cependant, lorsqu'un nombre élevé d'erreurs BIP franchissent un seuil (SD, SF ou B3-TCA), aucune notification à distance n'est envoyée pour indiquer que cette condition s'est produite. Ainsi, lorsque vous utilisez la protection de routage rapide MPLS (Multi Protocol Label Switching), aucun déclencheur n'active un commutateur de protection immédiat. Le trafic continue d'être bloqué jusqu'à ce qu'un trafic suffisant soit perdu pour provoquer une défaillance des keepalives de couche 2 sur la liaison ou les relations de voisinage entre homologues IGP (Interior Gateway Protocol). Parfois, cela ne se produit jamais et continue à noircir le trafic.

Pour répondre à ce scénario, CSCec85117 introduit la commande pos action b3-ber prdi à la structure de commandes POS et SONET.

Cette commande permet à l'opérateur de configurer l'interface pour envoyer un P-RDI lorsque le seuil B3 a été franchi. Cette option vous permet de surveiller la liaison de bout en bout de manière optimale, quelle que soit la topologie. Si le chemin des déclencheurs de délai post est activé sur les routeurs, la commande pos action b3-ber prdi active la liaison qui tombe en panne (et la réinitialisation rapide (FRR) ou la mise à jour de routage correspondante). Cela évite l'effet de trou noir sur les liaisons dégradées.

Pour modifier la sensibilité de cette action, réglez la b3-tca comme indiqué ici :

router(config-if)# pos threshold b3-tca ?

La valeur fournie est le composant exponentiel pour le calcul BER (par exemple, pos threshold b3-tca 3 définit le B3-TCA à un taux de 1x10^-3).

Informations connexes

• Magasin d'informations Telcordia
• Support et documentation techniques - Cisco Systems

Historique de révision