.
BLOCO
Blog dos Coordenadores ou Blog Comunitário
da
ComUnidade
WirelessBrasil
Julho 2008 Índice Geral do BLOCO
O conteúdo do BLOCO tem forte vinculação com os debates nos Grupos de Discussão Celld-group e WirelessBR. Participe!
• Como funciona a Internet (24) - Mapeando os "nossos" backbones (13) - Smolka comenta as explicações da Telefonica
----- Original Message -----
From:
José de Ribamar Smolka Ramos
To:
Celld-group@yahoogrupos.com.br
Sent: Monday, July 28, 2008 11:03 AM
Subject: [Celld-group] Re: Apagão - TEM QUE SER LIDO!
--- Em
Celld-group@yahoogrupos.com.br,
"luiz sergio lindenberg nacinovic" <lsnvic@...> escreveu ("em
azul")
> Grande Mestre. É o Luixsergio! Lembra de mim?
Lembro sim...
> Aqui estou eu novamente te chateando com minhas perguntas mal formuladas.
Não se preocupe com isso. É melhor uma pergunta mal-formulada do que uma dúvida não esclarecida.
> 1)No seu entender, qual a
hipótese mais provável a respeito do "caladão" da Telefónica?
> 2) Esses roteadores não são auto-reprogramáveis- a exemplo daqueles D-Links
domésticos?
> 3) O sr. acredita em falha de software?
Vamos com calma... Segundo o noticiário, A Telefónica comunicou à Anatel o laudo do CPqD, e deverá ter uma reunião com o CGI.br sobre o assunto. Embora o laudo não tenha sido publicado, o que vazou na imprensa é que o problema originou-se em uma interface ótica no roteador de Sorocaba, que fazia o link dele com outro roteador em Campinas. Então, vamos tentar aplicar um pouco de raciocínio lógico nisto.
Primeiro, pouco importa o fato da interface ser ótica (porque eles insistem em escrever "óptica?), elétrica, ou mesmo através de sinais de fumaça ou pombos-correio. A alegação é que a interface sofreu um problema de hardware. Muito bem... Se a interface tivesse simplesmente saído do ar, então não haveria problema (pelo menos não deste tamanho). O roteador de Campinas perceberia a queda do link para Sorocaba, alteraria suas tabelas de rotas para o caminho alternativo (que certamente existe; esta história que a rede não possuía "plano B" é bullshit), e em alguns minutos, no máximo, tudo estaria funcionando normalmente. E só a região servida pelo roteador de Sorocaba sentiria o problema, enquanto o restante da rede seguiria em frente sem transtornos.
Então o que deve ter acontecido é que a interface de Sorocaba não caiu, mas ficou em um estado instável onde, do ponto de vista do roteador em Campinas, o link ficava flutuando aleatoriamente entre os estados up e down. Isto faria que o roteador de Campinas ficasse tentando, sucessivas vezes, estabelecer uma rota alternativa (quando ele visse o link down) e voltar para a rota primária (quando ele visse o link up novamente). O nome técnico desta situação é route flapping.
No caso, ocorreria um LSP (label switching path) flapping entre os roteadores de Sorocaba e Campinas. Se o roteador de Sorocaba for (como disseram) um roteador de borda MPLS (denominação técnica: um provider edge router - PE), então muito provavelmente (porque acredito que a rede tem um projeto decente) ele estaria conectado a outro roteador do core MPLS (denominação técnica: um provider router - P), além do roteador de Campinas (que deve ser P). Ainda assim, nas CNTP o problema ficaria localizado entre os roteadores P (em Campinas e em outro site) e o roteador PE (em Sorocaba).
O que não está bem explicado é porque um problema de LSP flapping que deveria ficar localizado tornou-se generalizado. Para entender isto é preciso conhecer uma série de detalhes da rede da Telefónica: topologia, fornecedores dos roteadores P e PE envolvidos na raiz do problema (e as versões de SO em cada um deles), forma de distribuição dos labels na rede (I-BGP, LDP ou ambos), qual o IGP utilizado (OSPF ou IS-IS), se os roteadores MPLS também fazem full routing com a Internet, und so weiter... Provavelmente tudo isto está no laudo do CPqD, que não foi publicado.
Em resumo (supondo que o que foi divulgado procede), uma falha de hardware evoluiu para um completo meltdown do software responsável pelo roteamento global na rede. E porque demorou tanto tempo para isolar a falha? Acho que é o seguinte: o gerenciamento de falhas na rede é feito remotamente, a partir dos NOCs (network operations centers) da Telefónica, usando SNMP. Se todo o roteamento falhou catastroficamente, então as aplicações de gerência SNMP não conseguiam estabelecer contato com os objetos gerenciados, nem dava para acessá-los remotamente via sessões telnet. A única alternativa era despachar gente para cada site para intervir localmente. Como (provavelmente) a maioria dos sites funciona em regime lights-out operation, e os técnicos responsáveis pelo atendimento remoto são terceirizados, isto demorou. Ainda assim, não deveria ter demorado dois dias. Seis a doze horas eu consigo entender. Dois dias não.
Para terminar, um pouco de bom humor. Nos
lugares que funcionam em regime lights-out operation, costuma-se
dizer que são necessárias duas coisas: um operador e um cachorro. O cachorro é
para vigiar o site e não deixar o operador mexer em nada (porque tudo
é automático). E o operador é para dar comida e água ao cachorro
.
> Meu nome real é Luiz Sergio Nacinovic. Obrigado por ter me respondido daquela outra vez. Um abraço.
Pra vc também Luiz.
J. R. Smolka
[Procure "posts" antigos e novos sobre este tema no Índice Geral do BLOCO]