[GTER] Evitando LSP Storms em IS-IS

[Rubens Kuhl Jr.]

Eu conversei bastante sobre esse episódio em PVT com mais gente da
área, e toda vez eu apontava que o culpado não era o equipamento mas o
garoto-propaganda dessa grande operadora brasileira, simbolizando as
causas macro. Mesmo com o conhecimento do problema técnico específico,
minha impressão permanece e vai de encontro ao que você disse.



Rubens



2008/9/12 Ricardo Tavares <curupas at gmail.com>:
> Mas vale lembrar que os equipamentos em si e suas RFCs devem ter sido o
> menor dos fatores para a [resoluçao] do problema.
>
> Vira e mexe temos meltdowns em backbones, mas esse durou um tempo
> extremamente alto para os padroes das Telecomunicacoes, nao acham?
>
> Tem uma coisa chamada "Gerencia In-Band" tambem. E tambem tem uma coisa
> chamada "Protocolo de Crise" entre outros "pequenos fatores" que devem ser
> tambem precisamente mapeados.
>
> Um grande problema quando olhado a partir de seu futuro mostra que,
> invariavelmente, sua causa de origem nao foi unica. Foram varias e as vezes
> pequenas circunstancias que colaboraram para a crise final.
>
> IMHO.
>
> Essa licao nunca podemos esquecer.
>
> Abraços,
> Ricardo Tavares.
>
> 2008/9/12 Rubens Kuhl Jr. <rubensk at gmail.com>
>
>> Quando uma operadora sofre um outage prolongado, uma das coisas em que
>> a comunidade pode se beneficiar são as "learned lessons"... gostei de
>> saber o que evitar relativo a um outage recente, duradouro e de grande
>> repercussão, e divido aqui com vocês o que aprendi.
>>
>> Era uma vez a RFC 1142, que especificava o IS-IS; ela seguia a norma
>> ISO que dizia que se você receber um anúncio corrompido de LSP, deve
>> enviar para frente um LSP Purge. Porém, quando quem gera o LSP recebe
>> um Purge, vai tentar anunciar de novo, para dizer ao mundo "os boatos
>> sobre minha morte são exagerados"... isso gera um moto contínuo de
>> anúncios. Isso foi mudado na RFC 3719, que especifica que ao receber
>> LSPs corrompidos, descarte. Vide:
>>
>> http://www.ietf.org/mail-archive/web/isis-wg/current/msg01800.html
>>
>> A outra parte da história depende do comportamento do equipamento;
>> verificar se o equipamento foi escrito pensando da RFC 1142 ou na
>> 3719, e qual é o default. Um certo equipamento chinês tem a RFC 1142
>> como default mas tem opção para atuar como na RFC 3719... que não
>> estava ligada.
>>
>>
>> Rubens
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>
>
> --
> __________________________________________
> Vai Encarar? http://www.vaiencarar.com.br
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>