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

Nota da Coordenação:
Este "post" no BLOCO - Blog ComUnitário, pode conter material que complementa o assunto:
• Como funciona a Internet (24) - Mapeando os "nossos" backbones (13) - Smolka comenta as explicações da Telefonica