SONET triggers

Inleiding

Een trigger is een gebeurtenis die de rol van oorzaak in de oorzaak-en-effect relatie in een synchrone Optical Network (SONET) interface in IOS vervult. Soms kunt u de pos vertragingsopdracht gebruiken. Bij andere tijden, raadt Cisco u aan om de opdracht van de POS vertragingstriggers niet te gebruiken, vooral wanneer u probeert te voldoen aan dichte Service Level Agreements (SLA’s). Dienstverleners verkopen gedifferentieerde serviceniveaus op basis van bepaalde overeenkomsten. De overeenkomsten gaan over hoe het netwerk intern routes, beschermt, of prioriteert klantverkeer. Deze opdrachten helpen providers netwerken af te stemmen om aan serviceovereenkomsten te voldoen.

Dit document onderzoekt de triggers die betrekking hebben op gebeurtenissen omhoog en omlaag. Dit document legt ook uit hoe u Packet over SONET (POS) kunt implementeren en nadenkt over SLA's en conversietijden op Layer 3.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Gebeurtenissen die een POS-interface omlaag brengen

In deze sectie worden de gebeurtenissen beschreven die een POS-interface oproepen en worden de bijbehorende opdrachten weergegeven.

Trigers op niveau voor sectie en lijnniveau

De lijst met triggers in deze sectie verwijst naar de GR-253-CORE Synchronous Optical Network (SONET) transportsystemen: specificatie van gemeenschappelijke generieke criteria:

• Section Loss of Signal (SLOS) - De specificatie geeft aan dat u niet minder dan 2,5us en niet meer dan 100us (6.2.1.1.1) moet detecteren.

• Section Loss of Frame (SLOF) - De specificatie geeft aan dat u dit minimaal 3 ms (of 24 opeenvolgende foutmeldingen bij het vormgeven van patronen) moet detecteren (6.2.1.1.2).

• Alarmindicatielampje - Lijn (AIS-L)—AIS-L moet indien nodig binnen 125 uur na de detectie worden verzonden. Een apparaat moet de ontvangst van AIS-L detecteren indien het apparaat 5 achtereenvolgende frames ziet waarbij de bits 6,7 en 8 van K2 op 111 zijn ingesteld (6.2.1.2.1).

• Signal Degrade Bit Error Rate (SD-BER)—SD-BER is alleen een trigger op interfaces met Automatic Protection Switching (APS) (gekoppeld aan de B2 BER-berekening).

• Signaalfouten bit Error Rate (SF-BER)—SF-BER is een trigger voor zowel APS- als niet-APS-interfaces (gekoppeld aan B2 BER-berekening).

• Indicatie van de afstandsbediening - Lijn (RDI-L)—RDI-L is geen activum voor POS of APS. (RDI-L is echter een activum voor MPLS FRR) (paragraaf 5.3.3.1).

Zie de website van Telcordia Information SuperStore voor meer informatie over de in deze lijst genoemde secties.

Verwante opdrachten

De POS vertragingslijn n opdracht blokkeert LOS/LOF/AIS voor n ms voordat de opdracht de regel naar beneden start:

Als u de opdracht zonder numerieke waarde configureren is de vertragingstijd standaard 100 ms. U kunt lijntriggers gebruiken op elke niet-APS POS-interface. U kunt geen lijntriggers op interfaces gebruiken die aan APS deelnemen, omdat de lijntriggers de APS-werking verstoren. De POS-vertragingsfunctie voor lijn n-opdracht staat niet toe dat de lijn daalt op de korte LOS die afkomstig is van een intern beschermd Dense Wavelength Division Multiplexing (DWDM)-gereedschap, vanaf het moment dat er een interne DWDM-switch voor bescherming optreedt. Als het defect tijdens de ‘holdoff’-periode wordt gedemonteerd, is het alsof het defect nooit is opgetreden.

De opdracht pos-vertragingstriggers zorgt ervoor dat elke handeling op basis van het defect (behalve om de teller van het defect te verhogen) wordt stopgezet tot de opgegeven wachttijd eindigt.

Als u deze opdracht niet uitschakelt, worden APS en link naar beneden vanaf de bovengenoemde SONET-defecten direct in de routeprocessor (RP) geactiveerd.

Padtriggers

Deze specifieke tekortkomingen van het PATH-niveau leiden alleen tot een statuswijziging als u pos-vertragingstriggers pad op de interface hebt ingeschakeld:

• AIS-P—Dit defect moet binnen 125 uur na de detectie van het defect dat in AIS-P resulteert, worden verhoogd. Het Path Terminating Equipment (PTE) moet dit defect detecteren wanneer de H1 en H2 bytes voor een STS-pad alle 1s voor 3 opeenvolgende frames bevatten. Geïntegreerde paden moeten alleen de eerste H1- en H2-bytes observeren. Voor meer informatie, zie rubriek 6.2.1.2.2 van R6-175 en R6-176.

• RDI-P-Als RDI-P aanwezig is, moet het defect binnen 10 frames worden gedetecteerd. Zie 6.2.1.3.2 van R6-221.

• B3-TCA (Drempel Crossing Alarms) voor B3-Dit alarm is gekoppeld aan de B3 Binary Synchronous Communications (Bisync) IP (BIP)-berekening.

• LOP-P (Path Loss of Pointer) (als de IOS-versie CSCdx58021 bevat) - zie sectie 6.2.1.1.3 van GR-253.

Zie de website van Telcordia Information SuperStore voor meer informatie over de in deze lijst genoemde secties.

Verwante opdracht

De POS vertragingsoptie pad <msec> opdracht maakt link-down activeren op AIS-P, RDI-P en buitensporige B3-fouten mogelijk. Standaard is de link-down die wordt geactiveerd voor padfouten uitgeschakeld.

De opdracht specificeert ook een wachttijd in het bereik van 0 tot 511 ms (de standaard is 100 ms). Pad-trigger defects (AIS-P, RDI-P) die vóór het einde van de periode van het uitstel vrij zijn, veroorzaken geen teweegbrengen. Wanneer u deze opdracht niet expliciet op een POS-interface hebt ingesteld, levert dit geen actie op als de tekortkomingen van het PATH-niveau worden verwerkt. In tegenstelling tot de lijntriggers staan APS interfaces Path triggers toe, omdat Path triggers niet interfereren met de lijnlevel activiteit van APS. Pad triggers mochten niet eerder met APS worden geconfigureerd dan Cisco IOS® softwarerelease 12.0(28)S. Pad triggers werden toegevoegd om het link up/down gedrag van POS interfaces te versnellen wanneer verbonden met SONET netwerken. Dit maakte een snellere Layer 3 convergentie mogelijk in de aanwezigheid van externe fouten.

Samenvatting van POS-triggers CLI-gedrag

Deze tabel toont de POS-triggervoorwaarden en de bijbehorende resultaten:

conditionering	Resultaat
Als u niets hebt ingesteld dat expliciet te maken heeft met POS-triggers.	Regelniveau triggers worden direct verwerkt.
Als u de opdracht pos vertrager triggers line hebt ingesteld.	Regelniveau triggers worden verwerkt na een vertraging van 100 ms.
Als u de pos vertragingslijn x opdracht hebt ingesteld.	Regelniveau triggers worden verwerkt na x msecs, waarbij x tussen 0 en 511 ligt.
Als u niets hebt ingesteld dat expliciet te maken heeft met Pad triggers.	Pad triggers worden niet verwerkt en zullen geen actie veroorzaken om te nemen.
Als u de pos vertragingsoptie hebt ingesteld, wordt de opdracht pad geactiveerd.	Padlevel-triggers worden verwerkt na een vertraging van 100 ms.
Als u de pos-vertraging hebt ingesteld, wordt pad x opdracht geactiveerd.	Padniveau triggers worden verwerkt na x msecs, waarbij x tussen 0 en 511 ligt.

Schuldbewijzen van SONET

SONET-alarmen als gevolg van defecten worden gedurende 10 seconden (10.5 +-.5) na het defect bewaard.

Defect Handeling

In IOS veranderen de POS kaarten hun LINE staat door verschillende triggers, door twee algemene middelen voor defecte verwerking. Hoewel dit afhankelijk is van de specifieke configuratie van de interface (APS of niet-APS), zijn er in het algemeen twee soorten storingen:

• Beheerd

• onbeheerd

U dient de termen te begrijpen die specifiek zijn voor alarmverwerking die in dit document worden gebruikt:

• Defect-de mislukkingsvoorwaarde die de hardware herkent.

• Fout-een defect dat is geweekt voor de vereiste ~2,5 sec, en wordt vervolgens gemeld door de SONET-4-ALARM berichten. Elk defect dat een oorzaak is, raakt niet geweekt.

• Niet-beheerde fouten — gebeurtenissen zoals LOS, LOF, enz. Ze worden gedetecteerd door de SONET framer door een gedefinieerde set parameters, en vereisen geen berekening. Er is ofwel een defect dat aanwezig is en door de hardware wordt aangedaan, ofwel er is geen defect. Harde storingen zoals deze worden in het algemeen behandeld door onderbrekingen. LOS, LOF, AIS-L, en in speciale gevallen worden AIS-P en RDI-P meteen aangeklaagd. Deze zijn afhankelijk van de landbouwer en de vastgestelde regels om elk van deze gebreken op te sporen. Deze defecten hebben onmiddellijk effect. U kunt de router echter opdracht geven om de bewering van dit defect als een mislukking uit te stellen. Er zijn twee timers die de vertragingswaarde bepalen, pos vertragingstriggers [pad] | lijn] en transportvertraging. Deze worden later in het document behandeld.

• Beheerde alarmen—gebeurtenissen zoals TCA’s en SD/SF-BER berekeningen. Dit vereist enige berekening om te bepalen of ze aanwezig zijn, of ze in toename of afname zijn, enz. U kunt bijvoorbeeld geen LOS hebben dat de "LOS-ness" van de router verhoogt. U kunt echter BER hebben die toeneemt of afneemt; de genomen maatregelen kunnen verschillen . Zachte mislukkingen, zoals de BER en de TCA, hebben enige berekening nodig, omdat ze afhankelijk zijn van een aantal factoren, bijvoorbeeld de drempels die een gebruiker kan configureren, de bit rate en het maximale aantal BIP CV's (omdat ze verschillen voor de B1, B2 en B3). Het duurt ook langer om deze fouten op te sporen, omdat de hardware voor de OBP-tellers wordt ondervraagd, en ook omdat dit soort gebreken geleidelijk van aard zijn en zich in de loop der tijd hebben opgestapeld. Het is ook zo dat u in het algemeen niet van 0 BIP direct naar een signaaldegrafie (SD) of signaalstoring (SF) gaat zonder een ander type harde storing aanwezig in het netwerk. Deze gebreken treden trager op in vergelijking met de harde defecten.

Hier is een algemene benadering van basisberekeningen die beschrijft hoe BER wordt berekend:

Na elke start van de berekeningen en totdat BER_Period SHALL_BER_Period (het integratievenster wordt niet volledig uitgevoerd) bereikt, functioneert de algoritme strikt als een integreer of middelend.

• BER_Period = BER_Period + 1 sec.

• Current_BIP = Current_BIP + BIP_new.

• Current_BER = Current_BIP/BER_Period.

Nadat BER_Period SHALL_BER_Period (het integratievenster is volledig geactiveerd en start om te schuiven) functioneert de algoritme als een lekke emmer één:

• BER_Period = Requirements_BER_Period.

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

• Current_BER = Current_BIP/BER_Period.

De requested_BER_Period wordt bepaald op basis van alleen het lijntarief en de geconfigureerde BER-drempel, volgens de standaarden (zie figuur 5-5, Switch Initiation Time Criteria, GR-253). Maar het is minder beperkt tot 1 seconde, onze steekproeffractie.

Dus beweegt de BER_Period (integratievenster) met elke enquête en wordt er een nieuwe BER berekend met elke enquête. Als de Current_BER ooit boven een bepaalde grens is, verhogen we het juiste defect onmiddellijk tijdens dezelfde enquête of rekeninterval en houden we de respons minimaal. We herhalen deze berekeningen elke seconde en gaan na of er een van de drie gebeurtenissen heeft plaatsgevonden:

• BER valt nog steeds binnen hetzelfde bereik. Er is geen nieuwe actie.

• BER is weer toegenomen en overschrijdt een SD of SF drempel (voor B2). Maak een nieuw alarm.

• BER is onder de BER-drempel gedaald. Laat het alarm los.

Voor het verkrijgen van een TCA of SD/SF hoeft u alleen te wachten totdat u een limiet hebt overschreden op dat respectievelijke poll interval. Op het moment van berekening, controleer of Current_BER een drempel heeft overschreden en als dit is gebeurd, kunt u onmiddellijk het alarm starten en via software bevestigen.

Dit is geldig omdat, als Current_BER groot genoeg is om het alarm aanvankelijk te activeren, de conditie nog steeds waar is aan het eind van de BER_Period. Dit is gebaseerd op de manier waarop de waarden worden gedefinieerd en vergeleken met het rekenvenster.

Als u een alarm verwijdert, moet u wachten tot het einde van het rekenvenster BER_Period. Dit om er zeker van te zijn dat er geen nieuwe BIP's worden verzameld tijdens het laatste gedeelte van het venster dat u boven een drempel zou kunnen houden.

Opmerking: volgens GR-253 zijn SD-BER en SF-BER beide alleen gebonden aan het B2-BIP-getal. De huidige wanbetalingsdrempels zijn:

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

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

Opmerking: Engine2 OC-48 kaarten hebben deze standaardinstellingen:

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

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

Als u een B3 TCA Pad trigger act gelijkend op SF wilt hebben moet de B3 drempel worden ingesteld op dezelfde drempel, 10e-3. U kunt dit doen door de pos drempelwaarde b3-tca 3 opdracht bij de router (configuratie-als)#prompt.

Opmerking: aangezien het steminterval één seconde is, is dat de minimumtijd waarin we ooit een TCA- of SD/SF-defect zullen opmerken en vaststellen. Bovendien gaan deze typen storingen, gezien de geaccumuleerde aard van TCA/SD/SF, gepaard met een andere storing wanneer ze snel optreden bij typische storingen. Dit zorgt voor een evenwicht tussen het gebruik en de prestaties van de routerprocessor. Het steminterval kan niet worden ingesteld.

Activerende triggers

Deze sectie verschaft enige achtergrondinformatie om de interactie van enkele van de verschillende gebruikers die tunable knopen in IOS te onderzoeken:

De pos vertragingstriggers [line] | path] opdracht vertraagt de rapportage en actie van een defect kort.

POS-vertragingstrigger is de aanhoudtijd voordat u op een lijnalarm reageert. De standaardinstelling is een onmiddellijke reactie, wat betekent dat pos-vertragingsactiviteitslijn 0 wordt geactiveerd. Als u direct de pos vertragingslijn vormt zonder enige waarde, dan wordt de standaardwaarde van 100ms in aanmerking genomen. Dit maakt een onmiddellijke of vertraagde reactie mogelijk, gebaseerd op het gewenste effect. Als een van deze formaten is uitgevoerd, verschijnt het defect pas als een actief alarm nadat de wachttijd is verstreken.

Tijdlijn:

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

Hier:

• t0-tijd wanneer het defect optreedt.

• t1-tijd wanneer de hardware het defect detecteert.

• t2—tijdstip waarop het defect wordt gemeld als een fout.

• t2-t3 - tijd die voor om het even welke geconfigureerde triggers wordt uitgeschakeld.

• t3-t4—tijd waarvoor u wacht vanwege vertraging bij de vervoerder.

• t4-tijd wanneer de interface daadwerkelijk in IOS neerkomt.

• t5-tijd waarbij om het even welke nabijheid voor een routeringsprotocol neerkomt.

Bekijk de tijdlijn om te observeren hoe u de verschillende knoppen kunt bijsturen om verschillende resultaten te bereiken.

De opdracht postvertragingstriggers beïnvloedt de duur tussen t2 en t3, en in feite verbergt het defect van IOS, tot de Holdoff periode is voorbij. Als het defect wordt gewist voordat u t3 bereikt, gebeurt er niets en is het alsof er niets is gebeurd. De standaardwaarde voor zowel lijn als pad triggers is 100ms, en het bereik is 0 tot 511 ms. Pad triggers zijn niet ingeschakeld (met andere woorden, ze nemen geen actie), tenzij pos vertragingstriggers pad eerst wordt ingesteld. POS-vertragingstrigger is de wachttijd voordat u op een padalarm reageert. De standaardinstelling is geen reactie. Als u POS direct POS-vertragingstrigger zonder waarde aanpast, dan wordt de standaardwaarde 100ms automatisch toegewezen. Hiertoe behoren AIS-P, RDI-P en B3-TCA. Deze functionaliteit werd toegevoegd via CSCds82814 (ongeveer 12.0(15.5)S/ST).

De vertraging van de Carrier is de houdtijd tussen het eind van de vertraging POS en het zal de IOS interface verminderen. De standaard is 2000 msec. De vertraging van de Carrier is de tijd tussen t3 (wanneer IOS van een mislukking bewust wordt) en t4 (wanneer de interface daalt). Standaard wordt deze ingesteld op 2 seconden en kan deze worden ingesteld voor msec-waarden. Zoals de tijdlijn aangeeft, is het een extra functie bovenop de SONET-shelf timers. Het gedraagt zich op dezelfde manier als de POS-triggers - als het alarm voor het eind van de ‘holdoff'-periode wordt afgevoerd. Hier is echter een raadsel. De SONET debounce timer wist het defect niet voordat de transportvertraging geactiveerd wordt, tenzij de transportvertraging groot is (veel langer dan 10 seconden). Dit resulteert in een situatie waarin de vertraging van de transportverbinding vrijwel altijd wordt geactiveerd, en moet daarom als vrij klein worden beschouwd wanneer deze wordt ingezet met POS-interfaces. De vertraging van de lading wordt ook toegevoegd nadat het alarm is gewist, voordat de interface ook wordt verklaard. Daarom kan je de waarde van de carriervertraging twee keer tellen voordat de interface weer omhoog komt.

Voor sommige interfaces en fysieke media is dit behulpzaam. Met POS-interfaces zijn er echter een aantal triggers en timers die u kunt gebruiken en combineren om het gewenste effect te creëren, zonder carriervertraging die zo'n grote rol speelt. Een transportervertragingswaarde van 0-8 msec is een goed startpunt voor klanten om te overwegen wanneer ze deze knoppen zelf testen. In het algemeen is een goede strategie om de opdracht van de POS vertragingstriggers te gebruiken om enige problemen op te vangen en het gewenste onthoudingseffect te bieden. Vertraging van carriers kan klein worden gehouden om de impact ervan te minimaliseren.

De hierboven genoemde SONET debounce timer wordt ingesteld op 10 seconden (+/- 0,5sec) en wordt vereist door GR-253 om er zeker van te zijn dat er geen flap-periode van minder dan 10 seconden optreedt. De timer start nadat het defect is gewist. De timer wordt opnieuw ingesteld als er een andere defecte gebeurtenis optreedt voordat het timer venster is verlopen.

Tijdlijn:

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

Hier:

• t0—defect schoonmaken.

• t0—De timer start.

• t4—t0 + 10sec (dus moet de storing wissen als er geen nieuwe defecten tussen t0 en t4 optreden).

Als een gebeurtenis plaatsvindt vóór t4, (bijvoorbeeld) bij t2 (het kan een ander defect zijn of een herhaling van hetzelfde soort defect), wordt de timer gestopt tot dit nieuwe defect is gewist. Op t3 start de timer opnieuw, als er geen actieve defecten zijn, en telt deze voor de ~10 seconden. Als er geen nieuwe gebeurtenissen bekend zijn, moet u het alarm bij t5 wissen en de startvertraging starten. Wanneer de vertraging van de drager op t6 is opgeheven, omhoog dan de interface.

Deze informatie zou de klant in staat moeten stellen om helderder te begrijpen hoe de POS interfaces op verschillende SONET/SDH voorwaarden reageren. Hierdoor kan de apparatuur preciezer worden geconfigureerd volgens het door de klanten beoogde gedrag.

Waarom gebruiken we triggers?

Deze sectie legt uit wanneer u de POS vertragingstriggers moet gebruiken [line] | pad] opdracht, en wanneer u deze niet moet gebruiken.

Dit zijn de scenario's wanneer u geen pos vertragingstriggers moet gebruiken. Er zijn verschillende scenario's:

• U kunt geen lijntriggers gebruiken met APS-geconfigureerde interfaces. Versies eerder dan Cisco IOS-softwarerelease 12.0(28)S hebben zelfs het gebruik van Path-triggers niet toegestaan.

• Wanneer u expliciet niet wilt dat PATH-niveaudefecten de interface naar beneden brengen, kunt u deze triggers niet gebruiken.

• Wanneer u lijnequalizers wilt hebben om de interface onmiddellijk omlaag te brengen, kunt u deze opdracht niet gebruiken.

Dit zijn de scenario's wanneer u pos vertragingstriggers kunt gebruiken opdracht:

• Wanneer u het effect van een lijnvlakke defect tijdelijk wilt stoppen.

• Om de mogelijkheid voor tekortkomingen in het PATH-niveau in staat te stellen de interface onmiddellijk omlaag te brengen.

• Om tekortkomingen in PATH-niveau in staat te stellen de interface naar beneden te brengen, maar met een H4-waarde meegeleverd.

SLA’s en POS-triggers

Bekijk deze tijdlijn:

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

• Tijd t=0 (t0)—als het defect is gedetecteerd.

• Tijd t2 - de vereiste SLA restauratietijd.

• Tijd t1—Elke vertraging van de pos-vertraging zorgt voor een opdracht die is ingesteld (de standaard voor LIJN is 0 en de standaard voor PATH is niet ingeschakeld).

• X is de waarde van de holdoff (dus X = de waarde van t1).

• Y is het moment waarop Layer 3 nodig is om de service te herstellen.

Theorem

Soms kunt u de opdracht POS-vertragingstriggers gebruiken, terwijl u op andere tijden dat niet kunt, vooral wanneer u probeert te voldoen aan strakke Service Level Agreements (SLA’s).

Postulaten

• Als Y > (t2-t1) voor een waarde van t1 is een holdoff geen goed idee, omdat, kunt u uw SLA niet ontmoeten als u een holdoff vormt.

• Als Y <= (t2-t1), kunt u de implementatie van een "holdoff" overwegen. Als de duur van de mislukking minder is dan (t1-t0) kunt u uitzetten omdat, u geen routerbronnen hoeft te gebruiken, en u kunt aan de gewenste SLA voldoen. Als het defect zich na t1 blijft voordoen, kunt u nog steeds aan de SLA voldoen, ook al verliest u enige tijd voordat u op IP-niveau de restauratie start.

U moet enige kennis hebben over het onderliggende transportnetwerk en de convergentietijden van het Layer 3-netwerk, om de waarden te kennen die u in deze formules kunt gebruiken. Je moet ook wat testen doen.

Dit is hoe de triggers werken:

• De pos vertragingstriggers line n opdracht blokkeert LOS/LOF/AIS voor n ms voordat de opdrachtregel wordt neergezet. De standaardwaarde is 100 ms. U kunt deze opdracht gebruiken op een niet-APS POS-interface. De POS vertragingslijn n opdracht staat de lijn niet toe om te dalen op de korte LOS die uit intern beschermd DWDM tandwiel komt, vanaf het moment dat er een interne DWDM bescherming switch plaatsvindt. Als het defect tijdens de ‘holdoff’-periode wordt gedemonteerd, is het alsof het defect nooit is opgetreden.

• De opdracht POS-vertragingstriggers zorgt ervoor dat elke handeling op basis van het defect wordt opgeschort (behalve om de teller van het defect te verhogen), totdat de opgegeven wachttijd is afgelopen.

  Als u deze opdracht niet uitschakelt, worden APS en link down direct in de RP geactiveerd.

Plaatsing van SONET-triggers

In deze sectie wordt de inzet van SONET triggers beschreven.

Beschermd SONET-netwerk: Geen PS op de routers

Afbeelding 1 - Intern beveiligd SONET-netwerk

Het SONET netwerk heeft interne bescherming, wat betekent dat een mislukking binnen het SONET netwerk een zekere switch van de bescherming veroorzaakt om de dienst zeer snel te herstellen. Daarom moet u overwegen of u de interface wilt omlaag brengen en Layer 3 op de hoogte willen stellen. In de meeste gevallen, wanneer een switch ter bescherming binnen het SONET-netwerk optreedt, zien de routers een korte lijn of pad AIS terwijl het netwerk herstelmaatregelen neemt. Dit gebeurt echter alleen als de fout één hop weg van een van beide router is. Het SONET netwerk kan meerdere NU's in diameter zijn, één van beide router ziet LIJN mislukkingen slechts als PATH mislukkingen. In dit geval, overweeg pad en regelniveau triggers als u een holdoff wilt.

Om dit besluit te nemen, moet u de verbonden kosten met beide benaderingen begrijpen. Als netwerkbeheerder moet u deze vragen in overweging nemen:

• Komt het netwerk snel genoeg samen? Zo niet, dan is deze aanpak niet geschikt.

• Wat is het effect van het routeren rond zo'n mislukking? Is de impact zo groot op de router dat de prestaties dalen onder een acceptabel niveau?

Uiteindelijk moet je beslissen of je een mogelijke ~60msec hit kunt negeren, of dat je liever rond een dergelijke gebeurtenis wijst. Als je de hit kunt negeren, moet je identificeren hoeveel van een ‘fudge factor' om er aan toe te voegen omdat, je dit defect niet alleen wilt uitstellen om meerdere milliseconden te weinig te wachten en daarmee corrigerende actie uitstellen.

In dit scenario zijn de postvertragingslijn en pad waarschijnlijk toereikend. Bedenk bovendien waarden van minstens 60 msec als een schuldeiser is opgegeven. Als het netwerk breed genoeg is, en u wilt onmiddellijk actie ondernemen op zowel lijn als pad niveau defects, hebt u geen lijn niveau triggers nodig. U moet echter wel de pos-vertragingstranspad met een waarde van 0 configureren om onmiddellijke verwerking van tekortkomingen op PATH-niveau mogelijk te maken.

Intern onbeschermd SONET-netwerk

Afbeelding 2 - Intern onbeschermd SONET-netwerk

In een onbeschermd SONET netwerk, leidt u de zelfde risico's zoals in het eerste scenario, plus een paar meer. Als het netwerk groot genoeg is, kunnen de routers in geval van een defect nooit een LINE-niveau zien, omdat de defecten allemaal gefilterd zijn. De routers kunnen tekortkomingen in het PATH-niveau in de automatische processtroom zien. In sommige situaties, waar een mislukking binnen het netwerk voorkomt, ziet de router alleen gebeurtenissen op het niveau PATH en is er geen end-to-end continuïteit tussen de routers. Erger nog, er vindt geen herstel plaats op SONET niveau om deze situatie te verhelpen.

In dit scenario moet u Path triggers configureren om de routers aan elk eind toe te staan om actie te ondernemen wanneer de routers een PATH defect tegenkomen, zelfs als de routers geen holdoff-effect willen hebben. Wanneer u Path triggers hebt ingesteld, als een netwerkoperator, moet u controleren of het beter is om Layer 3 te stoppen of te activeren.

Beschermd of onbeschermd SONET-netwerk

Afbeelding 3 - Intern onbeschermd SONET-netwerk

In Cisco IOS-softwarerelease 12.0(28)S kunt u PATH-triggers inschakelen op APS-circuits. Wanneer u APS op de lokale routers of op externe routers implementeert, veroorzaakt een APS-switch de externe arbeids- en beveiligingsrouters om een kort defect op PATH-niveau te zien. Met een kleine trekker gaan de interfaces naar beneden, en deze situatie is niet wenselijk. Een interface die gaat naar de restauratie van de dienst die reeds in uitvoering is. Een tijdelijke storing die zich binnen de cloud voordoet kan ook het herstel van de service vertragen. Wanneer er echter een fout optreedt die op het PATH-niveau aanhoudt, wijst dit erop dat de stroombeveiliging (of binnen het netwerk, of op het einde) de connectiviteit niet heeft kunnen herstellen. In dit geval moeten de APS routers actie ondernemen en routing opnieuw converteren initiëren. U kunt de vertragingswaarden voor pad trigger >= 100ms configureren. Wanneer er bij deze configuratie een persistente fout optreedt binnen het SONET-netwerk of op het externe einde, brengen de routers beide APS-interfaces naar een lagere status van de link. Daarom initiëren de routers snellere routing en herstel van de service.

Beschermd DWDM-netwerk

Afbeelding 4 - beschermde DWDM-netwerkmodule

In dit scenario moeten we geen Path triggers gebruiken, omdat het DWDM netwerk niet op het SONET protocol niveau deelneemt. De router detecteert een storing op het niveau SECTIE of LIJN.

Opnieuw, omdat het DWDM-netwerk intern beschermd is, veroorzaakt een mislukking intern van het netwerk dat restauratie spoedig plaatsvindt. De router ziet doorgaans een zeer korte LOS, LOF of een barst van BIP-fouten.

Daarom hoeft u alleen te beslissen of een holdoff wenselijk is in dit netwerk.

De opdracht vertragingstriggers is in deze situatie voldoende, als u een vertraging kiest.

Onbeschermde DWDM-netwerk

Afbeelding 5 - onbeschermd DWDM-netwerk

Met een onbeschermd DWDM-netwerk in het transport moet u elke fout in de routers aanpakken. In deze situatie zou de standaardconfiguratie een onmiddellijke reactie op elk defect mogelijk maken dat bij een van beide routers wordt gezien, omdat de DWDM niet deelneemt aan het SONET-protocol. Als u dit effect wilt hebben, is de standaardconfiguratie van geen geconfigureerde POS-triggers geschikt.

Als u wat holdoff nodig hebt, is de opdracht POS vertragingstriggers line voldoende om deze functionaliteit te bieden.

Routers verbonden back-to-back

Afbeelding 6 - Routers Connected Grid-to-back

Twee routers die back-to-back tussen twee POS-interfaces zijn verbonden, moeten net zoals het laatste scenario werken. U kunt fouten onmiddellijk bij een van beide router zien, omdat er geen intermediair apparaat is dat op SONET overhead werkt of een deel van het SONET level-signaal beëindigt.

Een interessante situatie is wanneer R1 S-LOS ziet en R2 zowel L-RDI als P-RDI ziet, aangezien R1 zowel LTE-afsluitapparatuur (Line-Terminating Equipment) als PTE (Path-Terminating Equipment) is. Aangezien L-RDI elke resulterende actie na ontvangst expliciet verbieden, laat R2 de interface daardoor niet vallen. Deze kwestie kan mogelijk leiden tot een situatie waarin een interface van R1 is weggevallen, maar de interface van R2 is nog steeds in de goede richting. Natuurlijk biedt elke Layer 2 keeplevend (zoals High-Level Data Link Control (HDLC) tijden uit en verklaart de link omlaag, doorgaans in 30 seconden, op basis van de geconfigureerde timers. Een aantal exploitanten schakelt deze Layer 2-keepaliven echter uit en kan deze situatie niet voorkomen. Om dit probleem aan te pakken, kunt u verschillende benaderingen volgen en elke benadering richt dit vanuit een ander perspectief, zoals hier wordt uitgelegd:

• Schakel Path Triggers in—terwijl P-RDI een interface naar beneden brengt met enabled-triggers, kunt u deze methode gebruiken om een snelle respons te veroorzaken en de interface te laten vallen. Het interessante is dat L-RDI bij normaal gebruik de P-RDI maskeert volgens de GR-253. Als de POS-triggers op het defectniveau worden verwerkt, worden de triggers verwerkt voordat het alarm afgaat, en de interface daalt nog steeds volgens de ingestelde vertragingstijd.

• Layer 2 Keepalives inschakelen—Deze optie veroorzaakt de interface op R2 om uit te stappen nadat 3 keepalives zijn gemist. Dit is normaal 30 seconden totaal (3x10), en Cisco raadt deze optie over het algemeen niet aan als gereedschap om de snelle convergentie van verbindingen af te stemmen.

• Schakel een Link-State Routing Protocol-Wanneer de interface op R1 is verlaagd vanwege de S-LOS, wordt er direct een bericht van de verbindingsstaat verzonden. Zelfs al kan de interface op R2 nog steeds omhoog zijn, wanneer het bericht van de verbindingsstaat door het gebied wordt ontvangen, wordt SPF uitgevoerd, en de verbinding wordt verwijderd uit de topologie omdat de verbinding de controle van de bidirectionele connectiviteit mislukt. Dit voorkomt dat het netwerk door dat simplex scenario probeert te leiden.

Remote-melding op basis van signaalkwaliteit

Wanneer u twee routers verbindt, terug-aan-terug, of over een SONET netwerk, bestrijkt de meegeleverde OAM architectuur de detectie van een meerderheid van mislukkingsscenario's.

Meestal zijn er plaatselijke meldingen en meldingen op afstand. Wanneer echter een hoog aantal BIP-fouten een drempel overschrijdt (SD of SF, of B3-TCA), wordt geen melding op afstand verzonden om aan te geven dat deze voorwaarde is opgetreden. Wanneer u MPLS (Multi Protocol Label Switching) maakt, wordt er dus geen switch voor onmiddellijke beveiliging geactiveerd. Er blijft verkeer geblokkeerd totdat voldoende verkeer verloren gaat om een storing van Layer 2 keepalives op de link of buurrelaties tussen IGP-peers (Interior Gateway Protocol) te veroorzaken. Soms gebeurt dit nooit en blijft het verkeer geblokkeerd.

Om dit scenario aan te pakken, introduceert CSCec85117 de POS actie b3-ber prdi opdracht aan de POS en SONET opdrachtstructuur.

Met deze opdracht kan de operator de interface configureren om een P-RDI te verzenden nadat de B3-drempel is overschreden. Deze optie stelt u in staat om de verbinding end-to-end optimaal te controleren, ongeacht topologie. Als POS vertragingspad is geactiveerd op de routers, wordt de POS actie b3-ber prdi opdracht geactiveerd de link die neerkomt (en de corresponderende Fast RRoute (FRR) of routingupdate). Dit vermijdt het zwarte gat-effect op aangetaste links.

Om de gevoeligheid van deze actie te veranderen, moet u de b3-tca zoals hieronder wordt getoond aanpassen:

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

De verschafte waarde is de exponentiële component voor de berekening van de BER (bijvoorbeeld pos drempelwaarde b3-tca 3 stelt de B3-TCA in op een percentage van 1x10^-3).

Gerelateerde informatie

• Digitale informatiedrager - Opslagplek
• Technische ondersteuning en documentatie – Cisco Systems

Revisiegeschiedenis