[GTER] Evitando LSP Storms em IS-IS

[GIULIANO (UOL)]

Parece um caso recente do cenario nacional.


> 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
> 
> 
> ------------------------------------------------------------------------
> 
> 
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com 
> Version: 8.0.169 / Virus Database: 270.6.21/1668 - Release Date: 12/09/2008 06:56
>