Optique : Réseau optique synchrone (SONET)

Déclencheurs SONET

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


Contenu


Introduction

Un déclencheur est n'importe quel événement qui remplit le rôle de la cause dans les relations de cause et l'effet dans une interface de Réseau optique synchrone (SONET) dans l'IOS. Parfois, vous pouvez utiliser la commande de pos delay triggers. À d'autres fois, Cisco recommande que vous n'utilisiez pas le pos delay triggers commandiez, particulièrement quand vous tentez de rencontrer les accords de niveau de service serrés (SLA). Les fournisseurs de services vendent les niveaux différenciés du service en fonction sur certains accords. Les accords traitent la façon dont le réseau intérieurement conduit, protège, ou donne la priorité au trafic de client. Ces commandes aident des fournisseurs pour accorder des réseaux pour rencontrer des contrats de service.

Ce document examine les déclencheurs qui associent pour relier à travers des événements. Ce document explique également comment déployer le Paquet sur SONET (POS), et considère le SLA et les temps de convergence à la couche 3.

Conditions préalables

Conditions requises

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

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

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

Événements qui réduisent une interface de POS

Cette section décrit les événements qui réduisent une interface de POS, et répertorie les commandes relatives.

Section et déclencheurs de niveau à corde

La liste de déclencheurs dans cette section se rapporte aux systèmes de transport de Réseau optique synchrone (SONET) GR-253-CORE : Spécification générique commune de critères :

  • Perte de signal de section (SLOS) — La spécification indique que vous devez détecter aucun moins que 2.5us, et pas plus grand que 100us (6.2.1.1.1).

  • Perte de trame de section (SLOF) — La spécification indique que vous devez détecter ceci dans un minimum de 3ms (ou 24 bagouts errored consécutifs de tramage) (6.2.1.1.2).

  • Signal d'indication d'alarme - Ligne (AIS-L) — AIS-L doit être envoyé si approprié, dans 125usec de détection. Un périphérique doit détecter la réception d'AIS-L si le périphérique voit 5 trames consécutives où les bits 6,7, et 8 de K2 sont placés à 111 (6.2.1.2.1).

  • Taux d'erreurs sur les bits de dégradation de signal (SD-BER) — SD-BER est un déclencheur seulement sur des interfaces avec le Fonction Automatic Protection Switching (APS) (attaché au calcul de JUJUBES B2).

  • Taux d'erreurs sur les bits de panne de signal (SF-BER) — SF-BER est un déclencheur pour les deux interfaces aps et non-aps (attachées au calcul de JUJUBES B2).

  • Indication distante de défaut - Ligne (RDI-L) — RDI-L n'est pas un déclencheur pour le POS ou les aps. (Cependant, RDI-L est un déclencheur pour MPLS FRR) (section 5.3.3.1).

Pour plus d'informations sur les sections mentionnées dans cette liste, voyez le site Web d'hypermarché de l'informationleavingcisco.com de Telcordia.

Commandes associées

La ligne commande de pos delay triggers n tient hors fonction LOS/LOF/AIS pour le ms n avant la commande déclenche la ligne vers le bas :

Si vous configurez la commande sans n'importe quelle valeur numérique, le temps de retard est 100ms par défaut. Vous pouvez utiliser la ligne déclencheurs sur n'importe quelle interface du POS NON-aps. Vous ne pouvez pas utiliser la ligne déclencheurs sur les interfaces qui participent aux aps, parce que la ligne déclencheurs gênent l'exécution aps. La ligne commande de pos delay triggers n ne permet pas à la ligne pour aller vers le bas sur la visibilité directe de brief qui provient l'équipement intérieurement protégé de Multiplexage en longueur d'onde dense (DWDM), du temps où un commutateur interne de protection DWDM se produit. Si le défaut efface au cours de la période de holdoff, il est comme le défaut ne s'est jamais produit.

La ligne commande de pos delay triggers juge hors fonction n'importe quelle action basée sur le défaut (à moins que pour incrémenter le compteur de défaut) jusqu'aux extrémités spécifiées de période de holdoff.

Si vous n'activez pas cette commande, des aps et le lien vers le bas des défauts ci-dessus SONET sont déclenchés immédiatement dans le processeur d'artère (RP).

Déclencheurs de chemin

Ces défauts spécifiques de niveau de CHEMIN initient une modification d'état seulement si vous avez activé le chemin de pos delay triggers sur l'interface :

  • AIS-P — Ce défaut doit être augmenté dans 125usec de la détection du défaut ce des résultats dans l'AIS-P. Le matériel de terminaison de chemin (PRIVÉE) doit détecter ce défaut quand les octets H1 et H2 pour un chemin de STS contiennent tout le 1s de 3 trames consécutives. Les chemins concaténés doivent observer seulement les premiers octets H1 et H2. Le pour en savoir plus, voient la section 6.2.1.2.2 de R6-175 et de R6-176.

  • RDI-P — Si RDI-P est présent, le défaut doit être détecté à moins de 10 trames. Voyez 6.2.1.3.2 de R6-221.

  • B3-TCA (alarmes de croisement de seuil) pour B3 — cette alarme est attachée au calcul IP des communications binaires synchrones B3 (BISYNC) (BIP).

  • LOP-P (la déperdition en circuit de pointeur) (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, voyez le site Web d'hypermarché de l'informationleavingcisco.com de Telcordia.

Commande relative

Le lien-vers le bas de commandes enables de <msec> de chemin de pos delay triggers déclenchant sur AIS-P, RDI-P, et erreurs B3 excessives. Par défaut, le lien-vers le bas déclenchant pour des erreurs de chemin est désactivé.

La commande spécifie également un temps de holdoff de l'ordre de 0 à 511 ms (le par défaut est 100ms). Défauts de déclencheur de chemin (AIS-P, RDI-P) qui clairs avant que la fin de la période de holdoff n'entraînent pas le déclenchement. Quand vous n'avez pas explicitement configuré cette commande sur une interface de POS, aucune action ne résulte si les défauts de niveau de CHEMIN sont traités. À la différence de la ligne déclencheurs, les interfaces aps permettent des déclencheurs de chemin, parce que les déclencheurs de chemin ne gênent pas activité de niveau à corde des aps. On n'a pas permis à des des déclencheurs de chemin pour être configuré avec des aps dans les versions plus tôt que la version de logiciel 12.0(28)S de Cisco IOSÝ. Des déclencheurs de chemin ont été ajoutés afin d'accélérer le comportement haut/bas de lien des interfaces de POS une fois connectés aux réseaux SONET. Cette convergence plus rapide permise de la couche 3 en présence des erreurs distantes.

Le résumé du POS déclenche le comportement CLI

Ce tableau présente les conditions de déclencheurs de POS et les résultats associés :

Condition Résultat
Si vous n'avez configuré rien explicitement lié aux déclencheurs de POS. Déclencheurs de niveau à corde sont traités immédiatement.
Si vous avez configuré le pos delay triggers raye la commande. Déclencheurs de niveau à corde sont traités après un retard de 100ms.
Si vous avez configuré le pos delay triggers raye la commande x. Déclencheurs de niveau à corde sont traités après des msecs x, où x est entre 0 et 511.
Si vous n'avez configuré rien explicitement lié aux déclencheurs de chemin. Des déclencheurs de chemin ne sont pas traités et n'entraîneront aucune action d'être pris.
Si vous avez configuré la commande de chemin de pos delay triggers. Des déclencheurs de niveau de chemin sont traités après un retard de 100ms.
Si vous avez configuré la commande du chemin X de pos delay triggers. Des déclencheurs de niveau de chemin sont traités après des msecs x, où x est entre 0 et 511.

Debouncing des alarmes SONET

Des alarmes SONET qui résultent des défauts sont tenues pendant 10 secondes (10.5 +-.5) après que le défaut efface.

Manipulation de défaut

Dans l'IOS, les cartes de POS changent leur état de la ligne dû à différents déclencheurs, par deux moyens généraux de le traitement de défaut. Tandis que ceci dépend de la configuration spécifique de l'interface (des aps ou des non-aps), en général il y a deux types de pannes :

  • Géré

  • Non pris en charge

Vous devez comprendre les termes spécifiques à l'alarme-manipulation que ce document l'utilise :

  • Défaut — La condition de panne que le matériel identifie.

  • Panne — Un défaut qui a été imbibé pour le ~2.5sec exigé, et alors est signalé par les messages SONET-4-ALARM. Aucun défaut qui est un déclencheur n'obtient imbibé.

  • Pannes de non pris en charge — Événements tels que la visibilité directe, le LOF, etc. Ils sont détectés par l'auteur SONET par un ensemble de paramètres défini, et n'exigent aucun calcul. Il y a ou un présent de défaut et affirmé par le matériel, ou il n'y a aucun défaut. Des pannes dures de ce type, généralement sont manipulées par des interruptions. La visibilité directe, LOF, AIS-L, et dans des cas particuliers, AIS-P et RDI-P obtiennent affirmé immédiatement. Ce dépendent de l'auteur et des règles définies de détecter chacun de ces défauts. L'effet de ces défauts est immédiat. Cependant, vous pouvez instruire le routeur retarder l'assertion de ce défaut comme panne. Il y a des infidèles qui déterminent la valeur de retard, pos delay triggers [chemin | ligne] et retard de transporteur. Ceux-ci sont adressés plus tard dans le document.

  • Alarmes gérées — Événements tels que des calculs de TCAs et SD/SF-BER. Ceux-ci exigent d'un certain calcul de déterminer s'ils sont présents, sont en augmentation ou diminution, etc. par exemple, vous ne pouvez pas avoir une visibilité directe qui augmente son « Visibilité-ness » de la perspective du routeur. Cependant, vous pouvez prendre le JUJUBE qui est en augmentation ou la diminution ; la mesure prise peut être différente. Les pannes douces, comme les JUJUBES et l'ACIDE TRICHLORACÉTIQUE, ont besoin d'un certains calcul, parce qu'elles dépendent d'un certain nombre de facteurs, par exemple, les seuils qu'un utilisateur peut configurer, débit binaire, et le nombre maximal de BIP CVs (parce qu'elles sont différentes pour B1, B2, et B3). Ces pannes prennent également plus long pour être détectées, parce que le matériel est voté pour les compteurs BIP, et également parce que ces types de défauts sont progressifs en nature et sont accumulés au fil du temps. Il est également vrai qu'en général vous n'alliez pas de 0 BIP directement à une dégradation de signal (écart-type) ou à la panne de signal (SF) sans un autre type de panne dure actuel dans le réseau. Ces défauts sont plus lents pour se produire une fois comparés aux pannes dures.

Voici une approche généralisée aux calculs de base qui décrit comment calculer des JUJUBES :

Après chaque reprise des calculs et jusqu'aux portées Required_BER_Period de BER_Period (la fenêtre d'intégration n'est pas complètement déployée), l'algorithme fonctionne strictement en tant qu'intégrant ou de établissement d'une moyenne :

  • BER_Period = BER_Period + 1 sec.

  • Current_BIP = Current_BIP + BIP_new.

  • Current_BER = Current_BIP/BER_Period.

Après que BER_Period atteigne Required_BER_Period (la fenêtre d'intégration a été complètement déployée et des débuts pour glisser), l'algorithme fonctionne comme saut percé un :

  • BER_Period = Required_BER_Period.

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

  • Current_BER = Current_BIP/BER_Period.

Le Required_BER_Period est déterminé basé sur seulement la ligne débit et le seuil configuré de JUJUBES, après les normes (voir la figure 5-5, les critères de temps d'initiation de commutateur, GR-253). Cependant, il est limité inférieur à 1 seconde, notre fréquence d'échantillonnage.

Ainsi, le BER_Period (fenêtre d'intégration) se déplace avec chaque balayage, et un nouveau JUJUBE obtient calculé avec chaque balayage. Si le Current_BER est jamais au-dessus d'une limite définie, nous soulevons le défaut approprié immédiatement pendant cet même intervalle de balayage ou de calcul, et maintenons la réponse minimale. Nous répétons ces calculs chaque seconde, et contrôle pour voir si un de trois événements s'est produit :

  • Le JUJUBE fait partie toujours de cette même marge. Il n'y a aucune nouvelle action.

  • Le JUJUBE a augmenté de nouveau, et a franchi un seuil écart-type ou SF (pour B2). Donnez une nouvelle alarme.

  • Le JUJUBE a diminué au-dessous d'un seuil de JUJUBES. Effacez l'alarme.

Pour l'assertion d'un ACIDE TRICHLORACÉTIQUE ou d'un SD/SF, vous devez attendre seulement jusqu'à ce que vous avez croisé une limite à cet intervalle entre deux invitations à émettre respectif. Au moment du calcul, contrôle si le Current_BER a franchi un seuil, et s'il a, vous peut avancer et affirmer l'alarme immédiatement par le logiciel.

C'est valide parce que, si le Current_BER est assez grand pour déclencher l'alarme au commencement, la condition est encore vraie à la fin du BER_Period. Ceci est basé sur la façon dont les valeurs sont définies et comparées par rapport à la fenêtre de calcul.

Quand vous effacez une alarme, vous devez attendre jusqu'à l'extrémité de la fenêtre de calcul de BER_Period. C'est de s'assurer qu'aucun nouveau BIPs ne sont accumulés pendant la dernière partie de la fenêtre qui pourrait vous garder au-dessus d'un seuil.

Remarque: Selon GR-253, SD-BER et SF-BER chacun des deux sont attachés strictement au compte B2 BIP. Les seuils par défaut en cours sont :

  • Seuils de JUJUBES — SF = 10e-3 ÉCART-TYPE = 10e-6

  • Seuils d'ACIDE TRICHLORACÉTIQUE — B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

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

  • Seuils de JUJUBES — SF = 10e-4 ÉCART-TYPE = 10e-6

  • Seuils d'ACIDE TRICHLORACÉTIQUE — B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

Si vous voulez avoir l'acte de déclencheur de chemin de l'ACIDE TRICHLORACÉTIQUE B3 semblable à SF, le seuil B3 doit être établi au même seuil, 10e-3. Vous pouvez faire ainsi par la commande du pos threshold b3-tca 3 au routeur (config-si) # demande.

Remarque: Car l'intervalle de sondage est une seconde, c'est le temps minimum l'où nous jamais noterons et soulèverons le défaut d'ACIDE TRICHLORACÉTIQUE ou SD/SF. Supplémentaire, en raison de la nature accumulée de TCA/SD/SF, ces types de pannes sont accompagnés d'une autre panne quand ils se produisent rapidement dans des pannes typiques. Ceci met à jour un équilibre entre l'utilisation de processeur du routeur et la représentation. L'intervalle de sondage ne peut pas être configuré.

Déclencheurs dans l'action

Cette section fournit une certaine information générale pour examiner l'interaction de certaines des molettes réglables de divers utilisateur dans l'IOS :

Le pos delay triggers [ligne | la commande de chemin] retarde brièvement l'enregistrement et l'action d'un défaut.

La ligne de delay trigger de POS est la durée d'attente avant de réagir à une ligne alarme. Le par défaut est une réaction immédiate, qui signifie la ligne 0 de delay trigger de POS. Si vous configurez directement la ligne de delay trigger de POS sans n'importe quelle valeur, alors la valeur par défaut de 100ms est prise en considération. Ceci tient compte d'un immédiat ou d'une réaction différée, basé sur l'effet désiré. Avec l'un ou l'autre de ces derniers configurés, le défaut n'apparaît pas comme alarme active jusqu'à ce que la période de holdoff soit terminée.

Chronologie :

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

Ici :

  • t0 — Moment où le défaut se produit.

  • t1 — Moment où le matériel détecte le défaut.

  • T2 — Moment où le défaut obtient signalé comme panne.

  • t2-t3 — Chronométrez qui est tenu hors fonction pour tous les déclencheurs configurés.

  • t3-t4 — Temps l'où vous attendez en raison du retard de transporteur.

  • t4 — Moment où l'interface descend réellement dans l'IOS.

  • t5 — Temps à l'où n'importe quelle contiguïté pour un protocole de routage descend.

Examinez la chronologie pour observer comment tordre les différentes molettes pour réaliser de divers résultats.

Les delays triggers de courrier commandent des affects la durée entre le T2 et le T3, et en effet, masque le défaut de l'IOS, jusqu'à ce que la période de holdoff soit terminée. Naturellement, si le défaut est effacé avant que vous atteigniez le T3, rien ne se produit, et il est comme si rien ne s'est produit. La valeur par défaut pour la ligne et les déclencheurs de chemin est 100ms, et la plage est Mme de 0 à 511 que des déclencheurs de chemin ne sont pas activés (en d'autres termes, ils ne prennent aucune mesure) à moins que le chemin de pos delay triggers soit d'abord configuré. le chemin de delay trigger de POS est la durée d'attente avant de réagir à une alarme de chemin. Le par défaut n'est aucune réaction. Si vous configurez directement le chemin de delay trigger de POS sans n'importe quelle valeur, alors la valeur par défaut 100ms sera assignée automatiquement. Ceci inclut AIS-P, RDI-P, et B3-TCA. Cette fonctionnalité a été ajoutée par CSCds82814 (autour du 12.0(15.5)S/ST).

Le carrier-delay est la durée d'attente entre la fin de la durée d'attente de retard de POS et elle réduira l'interface IOS. Le par défaut est de 2000 millisecondes. Le retard de transporteur est le temps entre le T3 (quand l'IOS se rend compte d'une panne) et t4 (quand l'interface descend). Par défaut, ceci est placé à 2 secondes, et peut être configuré pour des valeurs milliseconde. Car la chronologie indique, c'est une fonction additive sur les temporisateurs de holdoff de niveau SONET. Il se comporte de la même manière que les déclencheurs de POS ? si l'alarme efface avant que la fin de la période de holdoff, l'interface ne soit pas réduite. Cependant, il y a une énigme ici. Le temporisateur de debounce SONET fait pas clair le défaut avant que le retard de transporteur lance, à moins que le retard de transporteur soit grand (bien plus de 10 secondes). Ceci a comme conséquence une situation où le retard de transporteur est presque toujours lancé, et doit donc être considéré plutôt petit une fois déployé avec des interfaces de POS. Le retard de transporteur est également ajouté après que l'alarme soit effacée, avant que l'interface soit déclarée vers le haut d'aussi bien. Par conséquent, vous pouvez compter la valeur du retard de transporteur deux fois avant que l'interface se réactive.

Avec quelques interfaces et medias physiques c'est utile. Cependant, avec des interfaces de POS il y a un certain nombre de déclencheurs et de temporisateurs que vous pouvez utiliser, et combiné pour créer l'effet désiré, sans retard de transporteur jouant un rôle si important. Une valeur de retard de transporteur de 0-8 milliseconde est un bon point commençant pour que les clients considèrent quand ils testent ces molettes sur leurs propres moyens. Généralement une bonne stratégie est d'utiliser le pos delay triggers commandent d'absorber tous les problèmes, et fournissent l'effet désiré de holdoff. Le retard de transporteur peut être maintenu petit pour réduire son incidence.

Le temporisateur de debounce SONET mentionné ci-dessus est placé à 10 secondes (+/- .5sec), et est exigé par GR-253 pour s'assurer qu'une période d'instabilité moins de 10 secondes ne se produit pas. Les débuts de temporisateur après le défaut est effacés. Le temporisateur est remis à l'état initial si un autre événement de défaut se produit avant que la fenêtre de temporisateur ait expiré.

Chronologie :

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

Ici :

  • t0 — Espaces libres de défaut.

  • t0 — Débuts de temporisateur de Debounce.

  • t4 — t0 + 10sec (par conséquent, la panne doit effacer si nouveau défaut ne se produit pas entre t0 et t4).

Si un événement se produit avant t4, (dites) au T2 (ce pourrait être un autre défaut, ou un reoccurrence du même type de défaut), le temporisateur est arrêté jusqu'à ce que ce nouveau défaut soit effacé. Au T3, aux reprendre de temporisateur, quand il n'y a aucun défaut d'active, et aux comptes pour les ~10 secondes. Si aucun nouvel événement n'est produit, effacez l'alarme à t5, et puis mettez en marche le temporisateur de délai de transporteur. Quand le retard de transporteur a été effacé à t6, évoquez l'interface de nouveau.

Ces informations devraient permettre au client pour comprendre plus clair comment les interfaces de POS réagissent à de divers états SONET/SDH. Ceci permet le matériel à configurer plus avec précision selon le comportement destiné par clients.

Pourquoi déclencheurs d'utilisation ?

Cette section explique quand vous devez utiliser le pos delay triggers [ligne | commande de chemin], et quand vous ne devez pas l'utiliser.

Voici les scénarios quand vous ne devez pas utiliser le pos delay triggers. Il y a plusieurs scénarios :

  • Vous ne pouvez pas utiliser la ligne déclencheurs avec les interfaces Aps-configurées. Les versions plus tôt que le Logiciel Cisco IOS version 12.0(28)S n'ont pas permis même l'utilisation des déclencheurs de chemin.

  • Quand vous explicitement ne voulez pas que les défauts de niveau de CHEMIN réduisent l'interface, vous ne pouvez pas utiliser ces déclencheurs.

  • Quand vous voulez que déclencheurs de niveau à corde réduise l'interface sans le retard, vous ne pouvez pas utiliser cette commande.

Voici les scénarios quand vous pouvez utiliser la commande de pos delay triggers :

  • Quand vous voulez tenir hors fonction l'effet de niveau à corde désertez temporairement.

  • Pour activer la capacité pour le CHEMIN nivelez les défauts pour réduire l'interface immédiatement.

  • Pour permettre aux défauts de niveau de CHEMIN de réduire l'interface, mais avec un certain holdoff inclus.

SLA et déclencheurs de POS

Examinez cette chronologie :

|----------|--------------------|
T0         T1                   T2
  • Temps t=0 (t0) — Quand le défaut est détecté.

  • T2 de temps — Le temps requis de restauration de SLA.

  • T1 de temps — N'importe quel holdoff du pos delay triggers commandent qui est configuré (le par défaut pour la LIGNE est 0 et le par défaut pour le CHEMIN n'est pas activé).

  • X est la valeur de holdoff (ainsi X = la valeur du t1).

  • Y est le temps où il prendra la couche 3 pour restaurer le service.

Théorème

Parfois, vous pouvez utiliser le pos delay triggers commandez, alors qu'à d'autres fois, vous ne pouvez pas, particulièrement quand vous tentez de rencontrer les accords de niveau de service serrés (SLA).

Postulats

  • Si Y > (t2-t1) pour aucune valeur de t1, un holdoff n'est pas une bonne idée parce que, vous ne pouvez pas rencontrer votre SLA si vous configurez n'importe quel holdoff.

  • Si le <= Y (t2-t1), vous peut considérer l'implémentation d'un holdoff. Si la durée de la panne est moins que (t1-t0), vous pouvez se tenir hors fonction parce que, vous ne devez pas utiliser des ressources en routeur, et vous pouvez rencontrer SLA désiré. Si le défaut persiste après le t1 de temps, vous pouvez encore rencontrer SLA, quoique vous perdiez une certaine heure avant que vous initiiez la restauration au niveau IP.

Vous devez avoir de la connaissance au sujet du réseau de transport sous-jacent, et les temps de convergence du réseau de la couche 3, afin de connaître les valeurs que vous pouvez utiliser dans ces formules. Vous devez également réaliser de l'essai.

Voici comment les déclencheurs fonctionnent :

  • Le pos delay triggers que la ligne commande n tient hors fonction LOS/LOF/AIS pour le ms n avant les déclencheurs de commande raye vers le bas. La valeur par défaut est 100ms. Vous pouvez utiliser cette commande sur n'importe quelle interface du POS NON-aps. La ligne commande de pos delay triggers n ne permet pas à la ligne pour aller vers le bas sur la visibilité directe de brief qui provient l'équipement interne-protégé DWDM, du temps où un commutateur interne de protection DWDM se produit. Si le défaut efface au cours de la période de holdoff, il est comme le défaut ne s'est jamais produit.

  • La ligne commande de pos delay triggers jugera hors fonction n'importe quelle action basée sur le défaut (à moins que pour incrémenter le compteur de défaut), jusqu'à la période spécifiée de holdoff finit.

    Si vous n'activez pas cette commande, des aps et le lien vers le bas sont déclenchés 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é : Aucun aps sur les Routeurs

Figure 1 ? Réseau SONET intérieurement protégé

/image/gif/paws/62622/K1.gif

Le réseau SONET a la protection interne, ainsi il signifie qu'une panne à l'intérieur du réseau SONET déclenche un certain commutateur de protection pour restaurer le service très rapide. Par conséquent, vous devez considérer si vous voulez réduire l'interface et informer la couche 3. dans la plupart des cas, quand un commutateur de protection se produit à l'intérieur du réseau SONET, les Routeurs voyez une brève ligne ou chemin AIS tandis que le réseau prend une mesure fortifiante. Cependant, ceci se produit seulement si la panne est un saut à partir de l'un ou l'autre de routeur. Le réseau SONET peut probablement être plusieurs NEs de diamètre, l'un ou l'autre de routeur voit la LIGNE pannes seulement comme pannes de CHEMIN. Dans ce cas, considérez le chemin et déclencheurs de niveau à corde si vous voulez un holdoff.

Pour prendre cette décision, vous devez comprendre le coût associé avec les deux approches. En tant qu'opérateur réseau, vous devez considérer ces questions :

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

  • Quelle est l'incidence du routage autour d'une telle panne ? L'incidence est-elle si grande sur le routeur ce les chutes de performances au-dessous d'un taux acceptable ?

Finalement, vous devez décider si vous pouvez ignorer un hit du potentiel ~60msec, ou si vous préférez conduire autour d'un tel événement. Si vous pouvez ignorer le hit, vous devez identifier quelle quantité de « facteur de fondant » à ajouter dedans parce que, vous ne voulez pas se tenir hors fonction sur ce défaut pour attendre seulement plusieurs millisecondes un trop petit nombre, et retardez de ce fait l'action corrective.

Dans ce scénario, le pos delay triggers raye et le chemin sont probablement suffisant. En outre, considérez les valeurs au moins de 60msec si un holdoff est justifié. Si le réseau est assez au loin, et vous voulez agir l'action immédiate sur les défauts de niveau de ligne et de chemin, vous n'avez pas besoin de configurer déclencheurs de niveau à corde. Cependant, vous devez configurer le chemin de pos delay triggers avec une valeur de 0 pour activer le traitement immédiat des défauts de niveau de CHEMIN.

Réseau SONET intérieurement non protégé

Figure 2 ? Réseau SONET intérieurement non protégé

/image/gif/paws/62622/K1.gif

Dans un réseau SONET non protégé, vous courez les mêmes risques que dans le premier scénario, plus des quelques plus. Si le réseau est assez grand, les Routeurs peuvent ne potentiellement jamais voir niveau à corde déserter en cas d'une panne, parce que tous les défauts sont filtrés. Les Routeurs peuvent voir les défauts de niveau de CHEMIN à travers le flot. Ainsi, dans certaines situations, où une panne se produit dans le réseau, le routeur voit seulement des événements de niveau de CHEMIN, et il n'y a aucune continuité de bout en bout entre les Routeurs. Encore plus mauvais, aucune restauration ne se produit au niveau SONET pour remédier à de cette situation.

Dans ce scénario, vous devez configurer des déclencheurs de chemin simplement pour permettre aux Routeurs à l'un ou l'autre d'extrémité pour agir quand les Routeurs rencontrent un défaut de CHEMIN, même si les Routeurs ne veulent aucun effet de holdoff. Quand vous avez configuré des déclencheurs de chemin, comme un opérateur réseau, vous devez vérifier s'il vaut mieux de tenir hors fonction ou déclencher une restauration de la couche 3.

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

Figure 3 ? Réseau SONET intérieurement non protégé

/image/gif/paws/62622/K2.gif

Dans le Logiciel Cisco IOS version 12.0(28)S, vous pouvez activer des déclencheurs de CHEMIN sur des circuits aps. Quand vous déployez des aps sur les Routeurs locaux ou distants, les aps commutent des causes le fonctionnement distant et protègent des Routeurs pour voir un bref niveau de CHEMIN déserter. Avec une petite valeur de déclencheur les interfaces descendent, et cette situation n'est pas desirable. Une interface qui descend la restauration de service de retards qui est déjà en cours. Une panne momentanée qui se produit dans le nuage peut également retarder la restauration de service. Cependant, l'occurrence d'une erreur persistante de niveau de CHEMIN indique que la protection de circuit (dans le réseau, ou à l'extrémité) a ne pu pas restaurer la Connectivité. Dans ce cas, les Routeurs aps doivent agir, et la re-convergence de routage d'initié. Vous pouvez configurer des valeurs de retard de déclencheur de chemin du >= 100ms. Avec cette configuration, quand une erreur persistante se produit dans le réseau SONET ou à l'extrémité distante, les Routeurs réduisent les deux interfaces aps à un état de lien. Par conséquent, les Routeurs initient plus vite le reroutage et la restauration du service.

Réseau protégé DWDM

Figure 4 ? Réseau protégé DWDM

K3.gif

Dans ce scénario, nous n'avons pas besoin d'utiliser des déclencheurs de chemin, parce que le réseau DWDM ne participe pas au niveau de protocole SONET. Le routeur détecte n'importe quelle panne à la SECTION ou niveau à corde.

De nouveau, parce que le réseau DWDM est intérieurement protégé, une panne interne à la restauration de causes de réseau à se produire bientôt. Le routeur voit typiquement une visibilité directe très brève, LOF, ou une rafale des erreurs BIP.

Par conséquent, vous devez seulement décider si un holdoff est desirable dans ce réseau.

La ligne commande de pos delay triggers est suffisante dans cette situation, si vous choisissez un retard.

Réseau non protégé DWDM

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

K4.gif

Avec un réseau non protégé DWDM dans le transport, vous devez adresser n'importe quelle panne chez les Routeurs. Dans cette situation, la configuration par défaut tiendrait compte d'une réponse immédiate à toutes les pannes vues à l'un ou l'autre de routeur parce que le DWDM ne participe pas au protocole SONET. Si vous désirez cet effet, la configuration par défaut sans déclencheurs configurés de POS est appropriée.

Si vous avez besoin d'un certain holdoff, la ligne commande de pos delay triggers est suffisante pour fournir cette fonctionnalité.

Les Routeurs ont connecté dos à dos

Figure 6 ? Les Routeurs ont connecté dos à dos

K5.gif

Deux Routeurs ont connecté dos à dos entre deux interfaces de POS doivent opérer juste comme le dernier scénario. Vous pouvez voir des pannes immédiatement à l'un ou l'autre de routeur, parce qu'il n'y a aucun matériel intermédiaire qui traite le temps système SONET ou termine n'importe quelle partie du signal de niveau SONET.

Une situation intéressante est quand R1 voit S-LOS, et R2 voit L-RDI et P-RDI, comme R1 Ligne-termine le matériel (LTE) et Chemin-termine le matériel (PRIVÉE). Puisque L-RDI rejette explicitement n'importe quelle action résultante d'être pris sur la réception, R2 ne relâche pas l'interface en conséquence. Cette question peut potentiellement mener à une situation où une interface de R1 est en baisse, mais l'interface de R2 est encore haute et trafique en avant. Naturellement, en posent 2 fois de keepalive (comme le High-Level Data Link Control (HDLC) fournit) et déclarent le lien vers le bas, typiquement en 30 secondes, basées sur les temporisateurs configurés. Cependant, un certain nombre d'opérateurs désactivent ce Keepalives de la couche 2, et ne peuvent pas empêcher cette situation. Afin d'aborder ce problème, vous pouvez adopter plusieurs approches, et chaque approche adresse ceci d'un point de vue différent, comme expliqué ici :

  • Activez les déclencheurs de chemin — Car P-RDI réduit une interface avec des déclencheurs de chemin activés, vous pouvez employer cette méthode pour entraîner une réponse rapide, et relâchez l'interface. Le point intéressant à noter est que L-RDI masque le P-RDI sous le fonctionnement normal selon GR-253. Pendant que les déclencheurs de POS sont manipulés au niveau de défaut, les déclencheurs sont traités avant l'alarme masquant, et l'interface chute toujours selon le temps de retard configuré.

  • Keepalives de la couche 2 d'enable — Cette option fait chronométrer l'interface sur R2 après que 3 Keepalives soient manqués. C'est d'en général 30 secondes de totale (3x10), et Cisco ne recommande pas généralement cette option car un outil d'accorder la convergence rapide de lien.

  • Activez un protocole de routage d'État de lien — Quand l'interface sur R1 est apportée en bas d'en raison du S-LOS, un message d'état de lien est envoyé immédiatement. Quoique l'interface sur R2 puisse encore être en hausse, quand le message d'état de lien est reçu dans toute la zone, la SPF est exécutée, et le lien est retiré de la topologie parce que le lien échoue le contrôle bi-directionnel de Connectivité. Ceci empêche le réseau d'essayer à conduire par ce scénario recto.

Notification distante basée sur la qualité du signal

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

Typiquement, il y a des notifications locales et des notifications distantes. Cependant quand un nombre élevé d'erreurs BIP franchissent un seuil (écart-type ou SF, ou B3-TCA), aucune notification distante n'est envoyée pour indiquer que cette condition s'est produite. Ainsi, quand vous utilisez la commutation par étiquette multi de Protocol (MPLS) rapide reroutez la protection, aucun déclencheur actionne un commutateur immédiat de protection. Le trafic continue à blackholed jusqu'à ce que le suffisamment de trafic soit perdu pour entraîner une panne de Keepalives de la couche 2 sur les relations de lien ou de voisin parmi des pairs de Protocole IGP (Interior Gateway Protocol). Parfois ceci ne se produit jamais, et continue au blackhole le trafic.

Pour adresser ce scénario, CSCec85117 introduit la commande de prdi de l'action b3-ber de POS structure de POS et SONET à commande.

Cette commande permet à l'opérateur pour configurer l'interface pour envoyer un P-RDI quand le seuil B3 a été franchi. Cette option te permet de surveiller le lien de bout en bout de façon optimale, indépendamment de la topologie. Si le chemin de pos delay triggers est activé sur les Routeurs, la commande de prdi de l'action b3-ber de POS lance le lien qui descend (et la correspondance rapide reroutent (FRR) ou l'acheminement de la mise à jour). Ceci évite l'effet de trou noir sur les liens dégradés.

Pour changer la sensibilité de cette action, accordez le b3-tca comme affiché ici :

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

La valeur fournie est le composant exponentiel pour le calcul de JUJUBES (par exemple, le pos threshold b3-tca 3 place le B3-TCA pour être équivalent à un débit de 1x10^-3).

Conversations connexes de la communauté de soutien de Cisco

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


Informations connexes


Document ID: 62622