[GTER] Evitando LSP Storms em IS-IS

[Ricardo Tavares]

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