Óptica : Synchronous Optical NETwork (SONET)

Disparadores SONET

15 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Um disparador é todo o evento que cumprir o papel da causa no relacionamento do causa-e-efeito em uma relação do Synchronous Optical NETwork (SONET) nos IO. Às vezes, você pode usar o comando pos delay triggers. Em outras épocas, Cisco recomenda que você não usa o comando pos delay triggers, especialmente quando você tenta encontrar o Service Level Agreements apertado (SLA). Os provedores de serviços vendem os níveis diferenciados do serviço baseados em determinados acordos. Os acordos tratam como a rede internamente distribui, protege, ou dá a prioridade ao tráfego de cliente. Estes comandos ajudam a fornecedores a ajustar redes para encontrar contratos de prestação de serviços.

Este documento examina os disparadores que se relacionam para conectar para cima e para baixo eventos. Este documento igualmente explica como distribuir o Pacote sobre SONET (POS), e considera SLA e tempo de convergência na camada 3.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Eventos que derrubam uma interface pos

Esta seção descreve os eventos que derrubam uma interface pos, e alista os comandos relacionados.

Disparadores da seção e do nível de linha

A lista de disparadores nesta seção refere os sistemas de transporte do Synchronous Optical NETwork (SONET) GR-253-CORE: Criações genéricas comuns da especificação:

  • Perda de sinal da seção (SLOS) — A especificação indica que você deve detectar nenhum menos do que 2.5us, e no máximo de 100us (6.2.1.1.1).

  • Perda do frame da seção (SLOF) — A especificação indica que você deve detectar este em um mínimo de 3ms (ou de 24 alinhadores longitudinais de quadro) do erro consecutivo (6.2.1.1.2).

  • Sinal de indicação de alarme - Linha (AIS-L) — O AIS-L deve ser mandado quando apropriado, dentro de 125usec da detecção. Um dispositivo deve detectar o recibo do AIS-L se o dispositivo vê os frames consecutivos 5 onde os bit 6,7, e 8 do K2 estão ajustados a 111 (6.2.1.2.1).

  • Taxa de erro de bit de degradação de sinal (SD-BER) — O SD-BER é um disparador somente em relações com o Automatic Protection Switching (APS) (amarrado ao cálculo de BER B2).

  • Taxa de erros de bits da falha de sinal (SF-BER) — O SF-BER é um disparador para as relações APS e NON-APS (amarradas ao cálculo de BER B2).

  • Indicação de defeito remoto-linha (RDI-L) — O RDI-L não é um disparador para o POS ou o APS. (Contudo, o RDI-L é um disparador para MPLS FRR) (seção 5.3.3.1).

Para obter mais informações sobre das seções mencionadas nesta lista, veja o siteleavingcisco.com do Telcordia Information SuperStore.

Comandos relacionados

O comando pos delay triggers line n guarda fora o LOS/LOF/AIS para a Senhora n antes do comando provoca a linha para baixo:

Se você configura o comando sem nenhum valor numérico, o tempo de retardo é 100ms à revelia. Você pode usar a linha disparadores em toda a interface pos NON-APS. Você não pode usar a linha disparadores nas relações que participam no APS, porque a linha disparadores interfere com a operação de APS. O comando pos delay triggers line n não permite que a linha vá para baixo no breve LOS que vem da engrenagem internamente protegida do Dense Wavelength Division Multiplexing (DWDM), do tempo onde um switch de proteção interno DWDM ocorre. Se o defeito cancela durante o período de não-suspensão, é como o defeito nunca ocorreu.

O comando pos delay triggers line mantém fora toda a ação baseada no defeito (exceto para incrementar o contador do defeito) até que o período de não-suspensão especificado termine.

Se você não permite este comando, o APS e o link para baixo dos defeitos acima SONET estão provocados imediatamente no route processor (RP).

Disparadores do trajeto

Estes defeitos específicos do nível PATH iniciam uma mudança de estado somente se você permitiu o trajeto dos disparadores de retardo posição na relação:

  • AIS-P — Este defeito deve ser levantado dentro de 125usec da detecção do defeito esse resultados no AIS-P. O Path Terminating Equipment (PTE) deve detectar este defeito quando os bytes H1 e de H2 para um trajeto STS contêm todo o 1s para 3 frames consecutivos. Os trajetos concatenados precisam de observar bytes somente os primeiros H1 e de H2. Para mais informação, veja a seção 6.2.1.2.2 do R6-175 e do R6-176.

  • RDI-P — Se o RDI-P esta presente, o defeito deve ser detectado dentro dos quadros 10. Veja 6.2.1.3.2 do R6-221.

  • B3-TCA (Threshold Crossing Alarms) para o B3 — Este alarme é amarrado ao cálculo IP das comunicações sincrônica binárias B3 (Bisync) (BIP).

  • LOP-P (perda de caminho de ponteiro) (se a Versão do IOS inclui CSCdx58021) — veja a seção 6.2.1.1.3 do GR-253.

Para obter mais informações sobre das seções mencionadas nesta lista, veja o siteleavingcisco.com do Telcordia Information SuperStore.

Comando relacionado

O comando pos delay triggers path <msec> permite a queda do serviço de links que provoca no AIS-P, no RDI-P, e nos erros B3 excessivos. À revelia, a queda do serviço de links que provoca para erros do trajeto é desabilitada.

O comando igualmente especifica uma estadia do holdoff na escala de 0 à Senhora 511 (o padrão é 100ms). Defeitos do disparador do trajeto (AIS-P, RDI-P) que claros antes que o fim do período de não-suspensão não causar a provocação. Quando você não configurou explicitamente este comando em uma interface pos, nenhuma ação resulta se os defeitos do nível PATH são processados. Ao contrário da linha disparadores, as relações APS permitem disparadores do trajeto, porque os disparadores do trajeto não interferem com a atividade do nível de linha do APS. Os disparadores do trajeto não foram permitidos ser configurados mais cedo com o APS nas versões do que o Software Release 12.0(28)S do ½ do ¿  de Cisco IOSïÂ. Os disparadores do trajeto foram adicionados a fim acelerar o comportamento up/down do link das interfaces pos quando conectados às redes de SONET. Isto permitiu uma convergência mais rápida da camada 3 na presença dos erros remotos.

Sumário de comportamento de CLI de Disparadores POS

Esta tabela alista as condições dos disparadores POS e os resultados associados:

Condição Resultado
Se você não configurou nada relativo explicitamente aos disparadores POS. Os disparadores do nível de linha são processados imediatamente.
Se você configurou o comando pos delay triggers line. Os disparadores do nível de linha são processados após um atraso de 100ms.
Se você configurou o comando pos delay triggers line x. Os disparadores do nível de linha são processados após o msecs x, onde x está entre 0 e 511.
Se você não configurou nada relativo explicitamente aos disparadores do trajeto. Os disparadores do trajeto não são processados e não causarão nenhuma ação a ser tomada.
Se você configurou o comando pos delay triggers path. Os disparadores de nível de caminho são processados após um atraso de 100ms.
Se você configurou o comando pos delay triggers path x. Os disparadores de nível de caminho são processados após o msecs x, onde x está entre 0 e 511.

Debouncing dos alarmes SONET

Os alarmes SONET que resultam dos defeitos são guardados pelos segundos 10 (10.5 +-.5) depois que o defeito cancela.

Manipulação do defeito

Nos IO, os cartões POS mudam sua LINHA estado devido aos disparadores diferentes, com dois meios gerais para o processamento do defeito. Quando isto depender da configuração específica da relação (APS ou NON-APS), no general há dois tipos de falhas:

  • Controlado

  • Unmanaged

Você deve compreender os termos específicos à alarme-manipulação que este documento se usa:

  • Defeito — A condição de falha que o hardware reconhece.

  • Falha — Um defeito que seja embebido para o ~2.5sec exigido, e é relatado então através das mensagens SONET-4-ALARM. Nenhum defeito que for um disparador não obtém embebido.

  • Falhas não gerenciada — Eventos tais como o LOS, o LOF, etc. São detectados pelo sonet framer por um conjunto de parâmetro definido, e não exigem nenhum cálculo. Há ou um presente do defeito e afirmado pelo hardware, ou não há nenhum defeito. As falhas graves tais como estes, são tratadas geralmente com as interrupções. O LOS, LOF, AIS-L, e em casos especiais, AIS-P e RDI-P obtém afirmado imediatamente. Estes são dependentes do conspirador e das regras definidas detectar cada um destes defeitos. O efeito destes defeitos é imediato. Contudo, você pode instruir o roteador atrasar a afirmação deste defeito como uma falha. Há dois temporizadores que determinam o valor de atraso, disparadores de retardo posição [trajeto | linha] e atraso do portador. Estes são endereçados mais tarde no documento.

  • Alarmes controlados — Eventos tais como TCA e cálculos SD/SF-BER. Estes exigem algum cálculo determinar se estam presente, estão no aumento ou diminuição, etc. por exemplo, você não pode ter um LOS que aumente seu “LOS-Ness” da perspectiva do roteador. Contudo, você pode ter o BER que está no aumento ou na diminuição; a ação tomada pode ser diferente. Os erros leves, como o BER e o TCA, precisam alguns cálculo, porque dependem de um número de fatores, por exemplo, os pontos iniciais que um usuário pode configurar, taxa de bits, e o número máximo de BIP CV (porque são diferentes para o B1, o B2, e o B3). Estas falhas igualmente tomam mais por muito tempo para ser detectadas, porque o hardware é votado para os contadores BIP, e igualmente porque estes tipos de defeitos são graduais na natureza e são acumulados ao longo do tempo. É igualmente verdadeiro que no general você não vai de 0 BIP direto a uma redução de sinal (SD) ou a uma falha de sinal (SF) sem algum outro tipo de falha grave atual na rede. Estes defeitos são mais lentos ocorrer quando comparados às falhas graves.

Está aqui uma aproximação generalizada aos cálculos básicos que descreva como calcular o BER:

Após cada reinício dos cálculos e até o Required_BER_Period dos alcances do BER_Period (a janela de integração não é distribuída completamente), o algoritmo funciona restritamente como de integração ou de cálculo da média:

  • BER_Period = BER_Period + 1 segundo.

  • Current_BIP = Current_BIP + BIP_new.

  • Current_BER = Current_BIP/BER_Period.

Depois que o BER_Period alcança o Required_BER_Period (a janela de integração completamente esteve distribuída e começa deslizar), o algoritmo funciona como um vazamento de bucket um:

  • BER_Period = Required_BER_Period.

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

  • Current_BER = Current_BIP/BER_Period.

O Required_BER_Period é determinado com base somente na linha taxa e o limiar de BER configurado, depois dos padrões (veja figura 5-5, critérios do tempo da iniciação do interruptor, GR-253). Contudo, é limitado mais baixo a 1 segundo, nossa taxa de amostragem.

Assim, o BER_Period (janela de integração) move-se com cada votação, e um BER novo obtém calculado com cada votação. Se o Current_BER está nunca sobre um limite definido, nós levantamos o defeito apropriado imediatamente durante esse mesmo votação ou intervalo de cálculo, e mantemos a resposta mínima. Nós repetimos estes cálculos cada segundo, e verificação para ver se um de três eventos ocorreu:

  • O BER ainda cai dentro dessa mesma escala. Não há nenhuma ação nova.

  • O BER aumentou outra vez, e cruzou um ponto inicial SD ou de SF (para o B2). Levante um alarme novo.

  • O BER diminuiu abaixo de um limiar de BER. Cancele o alarme.

Para a afirmação de um TCA ou de um SD/SF, você precisa de esperar somente até que você cruze um limite nesse intervalo respectivo de eleição. Na altura do cálculo, verificação se o Current_BER cruzou um ponto inicial, e se tem, você pode ir adiante e afirmar o alarme imediatamente através do software.

Isto é válido porque, se o Current_BER é grande bastante provocar inicialmente o alarme, a circunstância é ainda verdadeira no fim do BER_Period. Isto é baseado em como os valores são definidos e comparados com relação à janela de cálculo.

Quando você cancela um alarme, você precisa de esperar até o final da janela de cálculo do BER_Period. Este é assegurar-se de que nenhum BIP novo esteja acumulado durante a última parcela do indicador que pôde o manter acima de um ponto inicial.

Nota: De acordo com o GR-253, o SD-BER e o SF-BER ambos são amarrados restritamente à contagem B2 BIP. Os limiares padrão atual são:

  • Limiares de BER — SF = 10e-3 SD = 10e-6

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

Nota: Os cartões Engine2 OC-48 têm estes pontos iniciais do padrão:

  • Limiares de BER — SF = 10e-4 SD = 10e-6

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

Se você quer ter o ato do disparador do trajeto B3 TCA similar ao SF, o ponto inicial B3 deve ser estabelecido ao mesmo ponto inicial, 10e-3. Você pode fazer assim através do comando pos threshold b3-tca 3 no roteador (config-if) # alerta.

Nota: Porque o intervalo de polling é segundo, aquele é o tempo mínimo em que nós nunca observaremos e levantaremos o defeito TCA ou SD/SF. Adicionalmente, devido à natureza acumulada do TCA/SD/SF, estes tipos de falhas estão acompanhados de alguma outra falha quando ocorrem rapidamente nas falhas típicas. Isto mantém um equilíbrio entre a utilização do processador de roteador e o desempenho. O intervalo de polling não pode ser configurado.

Disparadores na ação

Esta seção fornece alguma informações de fundo para examinar a interação de alguns dos botões ajustáveis do vário usuário nos IO:

Os disparadores de retardo posição [linha | o comando do trajeto] atrasa momentaneamente o relatório e a ação de um defeito.

A linha do disparador de retardo POS é o tempo de contenção antes de reagir a um alarme de linha. O padrão é a reação imediata, que significa a linha 0 do disparador de retardo posição. Se você configura diretamente a linha do disparador de retardo posição sem nenhum valor, a seguir o valor padrão de 100ms está levado em consideração. Isto permite um imediato ou uma resposta atrasada, com base no defeito desejado. Com o qualquer uma destes configurados, o defeito não aparece como um alarme ativo até que o período de não-suspensão se acabe.

Período:

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

Aqui:

  • t0 — Tempo em que o defeito ocorre.

  • T1 — Tempo em que o hardware detecta o defeito.

  • t2 — Tempo em que o defeito obtém relatado como uma falha.

  • t2-t3 — Cronometre que é guardado fora para todos os disparadores configurados.

  • t3-t4 — Tempo por que você espera devido ao atraso do portador.

  • t4 — Tempo em que a relação vem realmente para baixo nos IO.

  • t5 — Tempo em que toda a adjacência para um protocolo de roteamento vem abaixo.

Examine o período para observar como à emenda os botões diferentes conseguir vários resultados.

O comando post delay triggers afeta a duração entre o t2 e o T3, e de fato, esconde o defeito dos IO, até que o período de não-suspensão se acabe. Naturalmente, se o defeito é cancelado antes que você alcance o T3, nada ocorre, e é como se nada aconteceu. O valor padrão para a linha e os disparadores do trajeto é 100ms, e a escala é a Senhora 0 a 511 os disparadores do trajeto que não estão permitidos (ou seja não tomam nenhuma ação) a menos que o trajeto dos disparadores de retardo posição for configurado primeiramente. o trajeto do disparador de retardo posição é o tempo de contenção antes de reagir a um alarme de caminho. O padrão não é nenhuma reação. Se você configura diretamente o trajeto do disparador de retardo posição sem nenhum valor, a seguir o valor padrão 100ms estará atribuído automaticamente. Isto inclui o AIS-P, o RDI-P, e o B3-TCA. Esta funcionalidade foi adicionada com CSCds82814 (em torno do 12.0(15.5)S/ST).

o Portador-atraso é o tempo de contenção entre o fim do tempo de contenção do atraso POS e derrubará a interface IOS. O padrão é 2000 milissegundos. O atraso do portador é o tempo entre o T3 (quando os IO se tornam cientes de uma falha) e t4 (quando a relação for para baixo). À revelia, isto é ajustado a 2 segundos, e podido ser configurado para valores milissegundo. Porque o período indica, é uma função aditiva sobre os temporizadores sem espera de nível SONET. Comporta-se da mesma forma enquanto os disparadores POS – se o alarme cancela antes que o fim do período de não-suspensão, a relação não estiver derrubado. Contudo, há um enigma aqui. O temporizador de SONET debounce faz não claro o defeito antes que o atraso do portador ative, a menos que o atraso do portador for grande (bem sobre os segundos 10). Isto conduz a uma situação onde o atraso do portador seja ativado quase sempre, e deve consequentemente ser considerado para ser um pouco pequeno quando distribuído com as interfaces pos. O atraso do portador está adicionado igualmente depois que o alarme está cancelado, antes que a relação esteja declarada acima de também. Daqui, você pode contar o valor do atraso do portador duas vezes antes que a relação venha apoio.

Com alguns relações e meios físicos isto é útil. Contudo, com interfaces pos há um número disparadores e de temporizadores que você pode usar, e combinado para criar o defeito desejado, sem o atraso do portador que toma tal papel principal. Um valor de atraso do portador de 0-8 milissegundo é um bom ponto de início para que os clientes considerem quando testam estes botões no seus próprios. Geralmente, uma boa estratégia é usar o comando pos delay triggers absorver todos os problemas, e fornece o efeito desejado do holdoff. O atraso do portador pode ser mantido pequeno para minimizar seu impacto.

O temporizador de SONET debounce mencionado acima é ajustado nos segundos 10 (+/- .5sec), e exigido pelo GR-253 para assegurar-se de que um período do flap menos do que os segundos 10 não ocorra. O temporizador começa depois que o defeito é cancelado. O temporizador está restaurado se um outro evento do defeito ocorre antes que a janela de temporizador expire.

Período:

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

Aqui:

  • t0 — Espaços livres do defeito.

  • t0 — Começos do temporizador de Debounce.

  • t4 — t0 + 10sec (daqui, a falha deve cancelar se nenhum defeito novo ocorre entre t0 e t4).

Se um evento ocorre antes de t4, (diga) no t2 (poderia ser um outro defeito, ou um recorrente do mesmo tipo de defeito), o temporizador é parado até que este defeito novo esteja cancelado. No T3, o temporizador começa outra vez, quando não há nenhum defeito do active, e conta para os ~10 segundos. Se nenhum evento novo é encontrado, cancele o alarme em t5, e ligue então o temporizador de retardo do portador. Quando o atraso do portador foi cancelado em t6, traga acima a relação outra vez.

Esta informação deve permitir que o cliente compreenda mais claramente como as interfaces pos reagem às várias condições SONET/SDH. Isto permite que o equipamento seja configurado mais precisamente de acordo com o comportamento pretendido dos clientes.

Por que use disparadores?

Esta seção explica quando você deve usar os disparadores de retardo posição [linha | comando do trajeto], e quando você não dever o usar.

Estão aqui as encenações quando você não deve usar disparadores de retardo posição. Há diversas encenações:

  • Você não pode usar a linha disparadores com relações APS-configuradas. As versões mais cedo do que o Cisco IOS Software Release 12.0(28)S não permitiram mesmo o uso de disparadores do trajeto.

  • Quando você explicitamente não quer o nível PATH defects para derrubar a relação, você não pode usar estes disparadores.

  • Quando você quer disparadores do nível de linha derrubar a relação sem o atraso, você não pode usar este comando.

Estão aqui as encenações quando você pode usar o comando pos delay triggers:

  • Quando você quer guardar fora o efeito de um nível de linha defect temporariamente.

  • Para permitir a capacidade para que os defeitos do nível PATH derrubem a relação imediatamente.

  • Para permitir defeitos do nível PATH de derrubar a relação, mas com algum holdoff incluído.

SLA e disparadores POS

Examine este período:

|----------|--------------------|
T0         T1                   T2
  • Tempo t=0 (t0) — Quando o defeito for detectado.

  • T2 do tempo — O tempo de restauração exigido SLA.

  • T1 do tempo — Todo o holdoff do comando pos delay triggers que é configurado (o padrão para a LINHA é 0 e o padrão para o PATH não é permitido).

  • X são o valor do holdoff (assim X = o valor do T1).

  • Y é o tempo onde tomará a camada 3 para restaurar o serviço.

Teorema

Às vezes, você pode usar o comando pos delay triggers, quando em outras épocas, você não puder, especialmente quando você tenta encontrar o Service Level Agreements apertado (SLA).

Postulados

  • Se Y > (t2-t1) para nenhum valor do T1, um holdoff não é uma boa ideia porque, você não pode encontrar seu SLA se você configura qualquer holdoff.

  • Se o <= Y (t2-t1), você pode considerar a aplicação de um holdoff. Se a duração da falha é menos do que (t1-t0), você pode guardar fora porque, você não tem que utilizar recursos de roteador, e você pode encontrar o SLA desejado. Se o defeito persiste após o T1 do tempo, você pode ainda encontrar o SLA, mesmo que você perca alguma hora antes que você inicie a restauração a nível IP.

Você deve ter algum conhecimento sobre a rede de transporte subjacente, e o tempo de convergência da rede da camada 3, a fim conhecer os valores que você pode usar nestas fórmulas. Você igualmente precisa de executar alguns testes.

É aqui como os disparadores trabalham:

  • O comando pos delay triggers line n guarda fora o LOS/LOF/AIS para a Senhora n antes dos disparadores do comando alinha para baixo. O valor padrão é 100ms. Você pode usar este comando em toda a interface pos NON-APS. O comando pos delay triggers line n não permite que a linha vá para baixo no breve LOS que vem da engrenagem interno-protegida DWDM, do tempo onde um switch de proteção interno DWDM ocorre. Se o defeito cancela durante o período de não-suspensão, é como o defeito nunca ocorreu.

  • O comando pos delay triggers line manterá fora toda a ação baseada no defeito (exceto para incrementar o contador do defeito), até as extremidades especificadas do período de não-suspensão.

    Se você não permite este comando, o APS e o link estão provocados para baixo imediatamente no RP.

Desenvolvimento de disparadores SONET

Esta seção descreve o desenvolvimento de disparadores SONET.

Rede de SONET protegida: Nenhum APS no Roteadores

Figura 1 – Rede de SONET internamente protegida

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

A rede de SONET tem a proteção interna, assim que significa que uma falha dentro da rede de SONET provoca algum switch de proteção para restaurar muito rapidamente o serviço. Consequentemente, você precisa de considerar se você quer derrubar a relação e notificar na maioria dos casos a camada 3., quando um switch de proteção ocorre dentro da rede de SONET, o Roteadores vê uma breve linha ou trajeto AIS quando a rede tomar a ação de restauração. Contudo, isto ocorre somente se a falha é um salto longe de um ou outro roteador. A rede de SONET pode possivelmente ser diversos NE no diâmetro, um ou outro roteador considera a LINHA falhas somente como falhas de caminho. Neste caso, considere disparadores do trajeto e do nível de linha se você quer um holdoff.

Para fazer esta decisão, você precisa de compreender os custos associados com ambas as aproximações. Como um operador de rede, você deve considerar estas perguntas:

  • A rede convirge rapidamente bastante? Se não, esta aproximação não é apropriada.

  • Que é o impacto do roteamento em torno de tal falha? É o impacto tão grande no roteador esse as quedas de desempenho abaixo de um nível aceitável?

Finalmente, você precisa de decidir se você pode ignorar uma batida do potencial ~60msec, ou se você prefere distribuir em torno de tal evento. Se você pode ignorar a batida, você deve identificar quanto de “de um fator caramelo” a adicionar dentro porque, você não quer guardar fora neste defeito para esperar somente diversos milissegundos demasiado poucos, e atrase desse modo a ação corretiva.

Nesta encenação, os disparadores de retardo posição alinham e o trajeto é provavelmente suficiente. Além, considere valores pelo menos de 60msec se um holdoff é justificado. Se a rede é largamente bastante, e você quer tomar a ação imediata em defeitos nivelados da linha e do trajeto, você não precisa de configurar disparadores do nível de linha. Contudo, você precisa de configurar o trajeto dos disparadores de retardo posição com um valor de 0 para permitir o processamento imediato de defeitos do nível PATH.

Rede de SONET internamente desprotegida

Figura 2 – Rede de SONET internamente desprotegida

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

Em uma rede de SONET desprotegida, você corre os mesmos riscos que na primeira encenação, mais alguns mais. Se a rede é grande bastante, o Roteadores pode potencialmente nunca ver um defeito do nível de linha no caso de uma falha, porque todos os defeitos são filtrados. O Roteadores pode ver defeitos do nível PATH para cima e para baixo o córrego. Assim, em algumas situações, onde uma falha ocorre dentro da rede, o roteador vê somente eventos do nível PATH, e não há nenhuma continuidade fim-a-fim entre o Roteadores. Mesmo mais ruim, nenhuma restauração ocorre a nível SONET para remediar esta situação.

Nesta encenação, você deve configurar disparadores do trajeto simplesmente para permitir que o Roteadores em uma ou outra extremidade tome a ação quando o Roteadores encontra um defeito PATH, mesmo se o Roteadores não quer nenhum efeito do holdoff. Quando você tem disparadores do caminho configurado, como um operador de rede, você deve verificar se seja melhor guardar fora ou provocar uma restauração da camada 3.

Rede de SONET protegida ou desprotegida

Figura 3 – Rede de SONET internamente desprotegida

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

No Cisco IOS Software Release 12.0(28)S, você pode permitir disparadores PATH em circuitos APS. Quando você distribui o APS nos roteadores locais ou remotos, um interruptor APS causa o funcionamento remoto e protege o Roteadores para considerar um breve defeito do nível PATH. Com um valor pequeno do disparador as relações vão para baixo, e esta situação não é desejável. Uma relação que vá abaixo da restauração do serviço dos atrasos que é já em andamento. Uma falha momentânea que ocorra dentro da nuvem pode igualmente atrasar a restauração do serviço. Contudo, a ocorrência de um erro de nível de caminho persistente indica que a proteção de circuito (dentro da rede, ou na ponta oposta) foi incapaz de restaurar a Conectividade. Neste caso, os roteadores de APS devem tomar a ação, e iniciam a reconvergência do roteamento. Você pode configurar valores de atraso do disparador do trajeto do >= 100ms. Com esta configuração, quando um erro persistente ocorre dentro da rede de SONET ou na extremidade remota, o Roteadores derruba ambas as relações APS a um estado de link. Consequentemente, o Roteadores inicia mais rapidamente redistribuir e restauração do serviço.

Rede DWDM protegida

Figura 4 – Rede DWDM protegida

K3.gif

Nesta encenação, nós não precisamos de usar disparadores do trajeto, porque a rede DWDM não participa a nível do protocolo SONET. O roteador detecta toda a falha a SEÇÃO ou nível de linha.

Além disso, porque a rede DWDM é protegida internamente, uma falha interna à rede causa restauração a ocorrer logo. O roteador vê tipicamente um LOS muito breve, o LOF, ou uma explosão dos erros de BIP.

Consequentemente, você precisa somente de decidir se um holdoff é desejável nesta rede.

O comando pos delay triggers line é suficiente nesta situação, se você escolhe um atraso.

Rede DWDM não protegida

Figura 5 – Rede DWDM não protegida

K4.gif

Com uma rede DWDM não protegida no transporte, você precisa de endereçar toda a falha dentro do Roteadores. Nesta situação, a configuração padrão permitiria uma resposta imediata a todas as falhas consideradas em um ou outro roteador porque o DWDM não participa no protocolo SONET. Se você deseja este efeito, a configuração padrão de nenhuns disparadores configurados POS é apropriada.

Se você exige algum holdoff, o comando pos delay triggers line é suficiente para fornecer esta funcionalidade.

O Roteadores conectou lado a lado

A figura 6 Router conectou lado a lado

K5.gif

Dois Roteadores conectaram lado a lado entre duas interfaces pos devem operar-se apenas como a última encenação. Você pode ver falhas imediatamente em um ou outro roteador, porque não há nenhum equipamento intermediário que opera sobre a carga adicional SONET ou termina parte do sinal do nível SONET.

Uma situação interessante é quando o r1 vê o S-LOS, e o R2 vê o L-RDI e o P-RDI, como o r1 é o equipamento de terminação de linha (LTE) e o Path Terminating Equipment (PTE). Desde que o L-RDI recusa explicitamente toda a ação a ser tomada resultante em cima do recibo, o R2 não deixa cair a relação em consequência. Esta edição pode potencialmente conduzir a uma situação onde uma relação do r1 esteja para baixo, mas a relação do R2 é ainda ascendente e trafica para a frente. Naturalmente, todas as vezes do keepalive da camada 2 (como o High-Level Data Link Control (HDLC) fornece) para fora e declaram o link para baixo, tipicamente em 30 segundos, com base nos temporizadores configurados. Contudo, um número de operadores desabilitam estes Keepalives da camada 2, e não podem impedir esta situação. A fim endereçar este problema, você pode tomar diversas aproximações, e cada aproximação endereça esta de uma perspectiva distinta, como explicado aqui:

  • Gire sobre disparadores do trajeto — Porque o P-RDI derruba uma relação com os disparadores do trajeto permitidos, você pode usar este método para causar uma resposta rápida, e deixa cair a relação. O ponto interessante a notar é que o L-RDI mascara para fora o P-RDI sob a operação normal conforme o GR-253. Enquanto os disparadores POS são segurados a nível do defeito, os disparadores estão processados antes do mascaramento do alarme, e a relação ainda deixa cair de acordo com o tempo de retardo configurado.

  • Permita o Keepalives da camada 2 — Esta opção faz com que a relação no R2 cronometre para fora depois que 3 Keepalives são faltados. Este tem tipicamente 30 segundos total (3x10), e Cisco não recomenda geralmente esta opção como uma ferramenta ajustar a convergência rápida do link.

  • Permita um protocolo de roteamento de estado de enlace — Quando a relação no r1 é trazida abaixo de devido ao S-LOS, uma mensagem do estado do link está enviada imediatamente. Mesmo que a relação no R2 possa ainda estar acima, quando a mensagem do estado do link é recebida durante todo a área, o SPF está executado, e o link é removido da topologia porque o link falha a verificação em dois sentidos da Conectividade. Isto impede que a rede tente distribuir através desse cenário simples.

Notificação remota baseada na qualidade de sinal

Quando você conecta dois Roteadores, ou lado a lado, ou através de uma rede de SONET, a arquitetura fornecida OAM cobre a detecção de uma maioria dos cenários de falha.

Tipicamente, há umas notificações local e umas notificações remotas. Contudo quando um alto número de erros de BIP cruza um ponto inicial (SD ou SF, ou B3-TCA), nenhuma notificação remota é enviada para indicar que esta circunstância ocorreu. Assim, quando você emprega o Multi Protocol Label Switching (MPLS) rápido redistribua a proteção, nenhum disparador ativa um switch de proteção imediato. O tráfego continua a ser blackholed até que o suficiente tráfego esteja para causado uma falha do Keepalives da camada 2 no link ou dos relacionamentos vizinho entre pares do Interior Gateway Protocol (IGP). Às vezes isto nunca ocorre, e continua ao blackhole o tráfego.

Para endereçar esta encenação, CSCec85117 introduz o comando pos action b3-ber prdi à estrutura POS e de comando sonet.

Este comando permite que o operador configure a relação para enviar um P-RDI quando o ponto inicial B3 foi cruzado. Esta opção permite-o de monitorar otimamente o link fim-a-fim, apesar da topologia. Se o trajeto dos disparadores de retardo posição é permitido no Roteadores, o comando pos action b3-ber prdi ativa o link que vem para baixo (e o Fast ReRoute correspondente (FRR) ou atualização de roteamento). Isto evita o efeito do buraco negro nos links degradados.

Para mudar a sensibilidade desta ação, ajuste o b3-tca como mostrado aqui:

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

O valor fornecido é o componente exponencial para o cálculo de BER (por exemplo, o ponto inicial b3-tca 3 posição ajusta o B3-TCA para ser equivalente a uma taxa de 1x10^-3).


Informações Relacionadas


Document ID: 62622