[GTER] Evitando LSP Storms em IS-IS

[Marcio Miguel]

Essa discussão é muito interessante, pois não trata de jogar pedras na
operadora x ou no fabricante y e sim nos fazer lembrar das boas
práticas, que são antigas, mas às vezes menosprezadas. Neste caso
específico, lembro de uma boa prática, dentro do "Protocolo de Crise"
que o Ricardo citou:
Uma pasta para situações de crise em papel ou em discos locais em mais
de um centro de controle contendo:
- Documentação física e lógica;
- Documentação da gerência out-of-band;
- Lista de contatos atualizada;
- Senhas dos administradores locais de cada equipamento, não
dependendo do Radius ou Tacacs para autenticação.

Abraço,
Márcio


2008/9/12 Rubens Kuhl Jr. <rubensk at gmail.com>:
> 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
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>