[GTER] Evitando LSP Storms em IS-IS

Leonardo Souza nomeiodabalada at yahoo.com.br
Thu Nov 6 14:01:23 -02 2008


A filosofia atual de tentar fazer o máximo com o mínimo não dá espaço para planejamento, ITIL, disaster recovery, business continuity planning...
O que existe é apagar incêndio, ainda mais nesses tempos de crescimento constante.
 
Além dos 'lessons learned' abaixo expostos, acredito que existiram outros:
 
1. Sempre adote mecanismos de controle de fluxo e limitação na geração e anúncio de LSP's (decaimento exponencial, intervalo de anúncio, intervalo de retransmissão etc..).
2. Sempre adote a máxima "Cagadas locais devem ter efeito local, não global" no projeto e implementação do IS-IS, segmentando a rede em diversas áreas L1 e um backbone L2.
3. Sempre tente realizar um benchmarking. Nem sempre o que está funcionando atualmente é o melhor. 

É isso.
 
[]´s
 
Leonardo Gama.

--- Em sáb, 13/9/08, Ricardo Tavares <curupas at gmail.com> escreveu:

De: Ricardo Tavares <curupas at gmail.com>
Assunto: Re: [GTER] Evitando LSP Storms em IS-IS
Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" <gter at eng.registro.br>
Data: Sábado, 13 de Setembro de 2008, 21:01

Sim.

Temos varias questoes. Procedimentos escritos, como você já disse. E quanto
a cadeia de comando e a tomada de decisões, a sequencia de ações, timing?

Em meu longo tempo na area já vi varias crises se arrastarem por horas
apesar de estar sendo coduzida por, a maioria das vezes, pessoas muito
capacitadas. Porém muitas dessas pessoas não podiam tomar decisões e toda
hora alguém tinha que ligar para um gerente, um diretor, e depois para outra
area e por fim uma outra pessoa da quase multidao ao redor do problema,
tinha uma outra idéia e tudo começava novamente....muitas vezes vi também
alguém tomar o problema para sí enquanto que várias pessoas que podiam
ajudar eram só platéia porque não sabiam qual era seu papel naquele raro
contexto.

Muitas de nossas equipes estao acostumadas somente a realizar suas tarefas
em CNTP gostaria de saber se alguem alguma vez já viu um Protocolo de Crise
escrito que não fosse o Americano e seus antigos estados "DEFCON"
voltados
para a guerra fria.


2008/9/13 Marcio Miguel
<marcio.miguel+gter at gmail.com<marcio.miguel%2Bgter at gmail.com>
>

> 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
> >
> --
> 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



      Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses



More information about the gter mailing list