BLOCO - BLOg dos COordenadores ou BLOg COmunitário da ComUnidade WirelessBRASIL

07/07/09

• Como funciona a Internet (4) - Mais "Ecos" do "Apagão"... e MPLS ... e Framerelay...

----- Original Message -----
From: Helio Rosa
To: Celld-group@yahoogrupos.com.br ; wirelessbr@yahoogrupos.com.br
Sent: Monday, July 07, 2008 10:29 AM
Subject: Com funciona a Internet (4) - Mais "Ecos" do "Apagão"... e MPLS ... e Framerelay...

Olá, ComUnidade WirelessBRASIL!

O "Serviço ComUnitário" está acompanhando os "ecos" e as providências referentes ao recente "apagão" da Telefônica.

01.

Conforme prometido hoje vamos "baixar o nível"...

Calma! Não vamos atacar o "ministro", sem o presidente "destepaís" nem o valente presidente da "nossa" Telefônica! :-)
Vamos tentar baixar para as "profundezas técnicas"...
Ou seja, aproveitar o "apagão" para dar um "clarão" nos nossos conhecimentos. :-)

Encaremos, pois, o MPLS citado pelo presidente Valente, da Telefonica: :-)
(...) O problema afetou a rede de dados chamada de Multi Protocol Label Switching (MPLS), que responde por 45% de todos os circuitos da Telefônica, incluindo clientes empresariais, residenciais e órgãos públicos (...)

O nosso José Smolka publicou uma série de artigos sobre VoiP na ComUnidade:

[09/01/06]   Métodos de Codificação de Voz – Uma Introdução

Artigo 01:
[04/05/06]   Voip - Introdução
Artigo 02:
[11/05/06]   TCP/IP for not-so dummies
Artigo 03:
[18/05/06]   Roteadores e QoS
Artigo 04
[23/05/06]   Dimensionamento VoIP (WAN)
Artigo 05
[02/05/06]   Sinalização

---------------------------------

Fonte: Estadão
[05/07/08] Empresa não descarta erro humano e sabotagem por Rodrigo Brancatelli

Telefônica localizou e isolou roteador com defeito em Sorocaba

Comparando o problema que afetou a rede de dados da empresa Telefônica com uma doença - e valorizando o trabalho dos técnicos em informática como se fossem médicos -, o presidente da empresa Antônio Carlos Valente ainda procura explicações para o apagão na internet. Ontem à tarde, ele explicou que a "anomalia" surgiu de um roteador defeituoso em Sorocaba, no interior de São Paulo. Ainda assim, Valente não sabe explicar por que todo o sistema replicou o erro e falhou em uníssono.

"Isolamos esse roteador, ele está lacrado e passará por perícia técnica do Centro de Pesquisa do Desenvolvimento (CPqD)", disse. "Ainda não sabemos por que a segurança de todos os equipamentos acima desse roteador falhou, isso possivelmente estará neste laudo, que deverá ser entregue em até dez dias. O que posso afirmar é que nosso sistema não é vulnerável, temos equipamentos de ponta, os melhores do mundo. Foi uma anomalia rara e complexa. Infelizmente isso acontece, faz parte da vida."

O presidente da Telefônica ainda afirmou que não acredita que o erro tenha sido causado por um ataque de hacker, mas não descarta "falha humana" ou sabotagem de algum funcionário demitido recentemente. "Não temos indícios para acusar, mas isso será investigado pela perícia", disse. Na noite de ontem, a Telefônica informou que a sua rede de dados estava reestruturada e funcionando plenamente, apenas com problemas pontuais - das 1.600 delegacias afetadas pelo apagão anteontem, quatro ainda estavam sem internet até as 20 horas de ontem. O Tribunal de Justiça também permaneceu sem conexão em seis das suas 560 unidades.

INSTABILIDADE

Valente afirmou que a empresa percebeu a instabilidade na rede por volta do meio-dia de anteontem. O problema afetou a rede de dados chamada de Multi Protocol Label Switching (MPLS), que responde por 45% de todos os circuitos da Telefônica, incluindo clientes empresariais, residenciais e órgãos públicos - a outra rede da empresa, chamada de Framerelay, não sofreu com o apagão.

Técnicos terceirizados da Telefônica ficaram, até as 20 horas de anteontem, isolando e analisando cada área do sistema até achar o roteador defeituoso no município de Sorocaba. "Por causa da expansão no número de assinantes e do aumento da largura da banda, esses equipamentos se atualizam a toda hora, interminavelmente", explicou Valente. "Esse roteador estava emitindo um código falso, que acabou prejudicando o sistema. Isolamos então esse roteador e tudo foi retomado. "

----------------------

Fonte: Estadão

[05/07/08] ''O que houve foi excepcional. O sistema foi para o espaço''

O contrato exclusivo com a Telefônica deixou a Companhia de Processamento de Dados do Estado de São Paulo (Prodesp), responsável pelo gerenciamento de informações de órgãos como a Polícia Civil, Detran e Poupatempo, praticamente inoperante no apagão online de anteontem. Ao Estado, o diretor-presidente da Prodesp, Leão Roberto Machado de Carvalho, disse que o órgão já preparava a contratação de um segundo provedor.

Faltou um plano B para evitar o caos de ontem?

Não existiu falta de plano B. Talvez o formato não fosse o melhor. Há dois anos, quando foi montado o contrato, havia um plano de contingência e solicitação de redundância. Quando a Telefônica proveu o serviço à Prodesp, o fez com as devidas redundâncias. Esse sistema tem funcionado razoavelmente. O que houve foi excepcional. Foi para o espaço o sistema, foi a redundância, tudo. A gente estaria talvez discutindo o plano C.

A Prodesp estuda mudanças?

No começo deste ano, já começamos a pensar que era uma fragilidade que não queremos ter mais. A gente já tinha pensado nisso, mas imaginando que nunca ia acontecer o que aconteceu.Tanto que, para renovação da licitação, até 2010, já estamos prevendo dois lotes (de prestação de serviços). O que aconteceu até confirmou nossa intenção de, na próxima licitação, já ter dois fornecedores.

Qual o balanço do apagão?

Usamos como parâmetro o Poupatempo. A média diária em 2008 é de 90 mil atendimentos nos 11 postos fixos do Estado. Anteontem, não conseguimos fechar 30%. A ordem de desgraça foi de 67%. No datacenter da Prodesp, só recebemos 10% do volume de informações e emitimos 37%. Tínhamos o processamento, mas não conseguíamos transmitir informações.

------------------------------

Fonte: Roteadores e QoS por José Smolka

Multi-Protocol Label Switching (MPLS):

O Segundo maior fator que afeta a latência de um roteador é o tempo necessário para que o protocolo IP decida para qual interface física o pacote deve ser encaminhado, através da inspeção da sua tabela de rotas (buscando o largest prefix match do CIDR).

É evidente que, quanto maior for a tabela de rotas, maior será o tempo necessário para a tomada desta decisão, e, conseqüentemente, maior será a latência.

Os protocolos de dynamic routing, tanto para exterior routing quanto para interior routing, preocupam-se com isto, tentando minimizar o número de entradas na tabela de rotas pelo uso de rotas-sumário (summary routes). Mesmo assim, na Internet é comum encontrarmos roteadores cujas tabelas de rotas tem alguns milhares de entradas.

É desejável, então, algum mecanismo que permita simplificar o processo de roteamento de pacotes através de grandes redes, evitando o custo computacional de pesquisa em grandes tabelas de rotas. O método predileto, hoje em dia, para conseguir isto é o MPLS (multi-protocol label switching).

O MPLS surgiu como uma proposta proprietária da Cisco Systems, chamada tag switching. Posteriormente foi padronizada pelo IETF na RFC 3031. A idéia básica é acelerar o encaminhamento (forwarding) dos pacotes, através do uso de rotas pré-definidas (chamadas label paths).

Ao ingressar na rede MPLS, o pacote recebe um header MPLS, que pode conter um ou mais labels. A identificação no label permite que os roteadores MPLS associem o pacote a uma forwarding equivalence class (FEC), e cada FEC está associada a um label path na rede. Os protocolos para troca de informações de associação de FECs aos label paths, e configuração (o termo bellhead para isto é provisionamento) dos label paths entre os roteadores MPLS são o LDP (label distribution protocol) e o RSVP-TE (resource reservation protocol – traffic engineering extension).

Hum... meu headiness index meter está descendo... descendo... estabilizou no –4. Um fato sobre o MPLS precisa ser bem compreendido: ele não foi desenvolvido com o objetivo principal de acelerar o roteamento em redes IP. O objetivo real era posicionar uma rede de roteadores como alternativa viável ao frame-relay e ao ATM para a construção de redes multi-serviço (leia-se: capazes de transportar voz e dados como entidades separadas). E, especialmente com os acréscimos do PWE3 (pseudo-wire emulation edge-to-edge, também conhecido como martini drafts), esta vocação fica mais que evidente.

Tenho minhas dúvidas se o desempenho de roteamento no core de uma rede TCP/IP de grande porte será significativamente melhor com o uso do MPLS do que, por exemplo, uma política agressiva de sumarização de rotas via dynamic routing associada ao uso de roteadores que armazenem a routing table em CAM (content-addressable memory). Querendo ou não, o processo de adicionar e remover labels aos pacotes IP vai exigir algum aumento de latência nos pontos onde isto ocorra. Se o aumento da latência for maior que a diminuição no delay para atravessar a rede MPLS (comparado com o delay do roteamento IP convencional) então não há ganho.

O que o MPLS tem de realmente bom, especialmente para os provedores de serviço, são duas coisas: a possibilidade de configurar VPNs (virtual private networks), que neste caso atendem pelo acrônimo VRF (virtual routing/forwarding facility); e mecanismos de reconvergência em caso de falha tão rápidos quanto nas redes SDH/Sonet – FRR (fast reroute).

Enfim... Uma vez que o MPLS está aí para ficar, vamos ver como ele funciona. Os roteadores na borda da rede MPLS, chamados LER (label edge router) ou PE (provider edge), são os responsáveis pela inserção e remoção dos labels associados aos pacotes IP. Os roteadores PE são os que “carregam o piano” em uma rede MPLS, porque precisam inspecionar a tabela de rotas local e definir a FEC que será inserida no label.

O core de uma rede MPLS é formada por roteadores LSR (label switching routers), também conhecidos como roteadores P (provider), cuja única função é fazer o forwarding dos pacotes, com base na FEC informada no label e em uma tabela simples de associação entre FECs e label paths.

Outro conceito errado sobre MPLS é que ele é de grande ajuda (ou até indispensável) para a garantia de QoS em redes TCP/IP. Então vamos à próxima seção, para vermos como o QoS é tratado em redes MPLS.

MPLS e QoS:

No label MPLS existem três bits EXP (experimental), que são utilizados para associar informação de prioridade de forwarding aos pacotes. O fato de serem chamados “experimental” dá uma boa idéia do que a proposta original do MPLS dizia sobre QoS.

A forma mais comum para trasladar a informação dos DSCPs DiffServ dos pacotes para o MPLS é repetir, nos bits EXP do label, os bits DS5, DS4 e DS3 do byte DS no header IP.

Não tenho nenhuma informação objetiva sobre isso, mas não vejo porque um algoritmo como o WFQ não pudesse ser utilizado no tratamento da fila de pacotes associada a cada label path. De qualquer forma, assim podem ser criadas até oito classes de prioridade para forwarding MPLS, compatíveis com as classes de prioridade do DiffServ.

Uma confusão comum é achar que, configurando VRFs MPLS, é possível fazer redes virtuais “mais prioritárias” do que outras (isto é especialmente comum em operadoras de telecom). Só que não é verdade. O conceito de VRF serve apenas para que as VPNs configuradas compartilhem a mesma infra-estrutura de transmissão de forma logicamente independente, mas todos os pacotes, de todas as VRFs, que tenham a mesma configuração nos bits EXP serão encaminhados com a mesma prioridade.

Vamos a um exemplo prático (e comum na praça). A operadora XYZ telecom quer implementar um core multi-serviço MPLS para poder implementar duas VRFs TCP/IP separadas: uma para o tráfego de serviços aos assinantes, e outra para a sua rede corporativa (tráfego administrativo interno). Suponhamos que na VRF de serviços existam hosts que implementam serviços VoIP para os assinantes, e que na VRF corporativa existam hosts que implementam um PABX (private automatic branch exchange) VoIP.

O mais provável é que ocorra o seguinte: tanto na VRF de serviços quanto na VRF corporativa, os pacotes de voz e de sinalização recebam os mesmos DSCPs (EF e AF43, respectivamente). Enquanto os tráfegos fiquem segregados, tudo bem. Mas, no momento que eles passam a trafegar pelo core MPLS, eles receberão as mesmas configurações de bits EXP, portanto o tráfego VoIP dos assinantes irá competir diretamente com o tráfego VoIP corporativo.

O MPLS (Multiprotocol Label Switching) é um protocolo de roteamento baseado em pacotes rotulados, onde cada rótulo representa um índice na tabela de roteamento do próximo roteador. Pacotes com o mesmo rótulo e mesma classe de serviço são indistingüiveis entre si e por isso recebem o mesmo tipo de tratamento.

O objetivo de uma rede MPLS não é o de se conectar diretamente a sistemas finais. Ao invés disto ela é uma rede de trânsito, transportando pacotes entre pontos de entrada e saída.

Ele é chamado de multiprotocolo pois pode ser usado com qualquer protocolo da camada 3, apesar de quase todo o foco estar voltado no uso do MPLS com o IP.

Este protocolo é na verdade um padrão que foi feito com base em diversas tecnologias similares desenvolvidas por diferentes fabricantes. Ele é referido por documentos do IETF como sendo uma camada intermediária entre as camadas 2 e 3, fazendo com que estas se “encaixem” melhor.

O MPLS surgiu como uma resposta de fabricantes de equipamentos e centros de pesquisa a várias necessidades que surgiram com a popularização da internet e diversificação de seus serviços.

Talvez a mais primordial destas necessidades seja a sobrecarga que esta sendo aplicada aos roteadores da rede devido ao sempre crescente número de usuários. Os roteadores IP possuem um algoritmo de roteamento que é ineficiente a medida que o tamanho da rede cresce pois para definir qual será o próximo salto (hop) do pacote, cada roteador tem que analisar mais informações do que é realmente necessário.

Além disso cada roteador tem que realizar o mesmo processo, que é muito semelhante para todos os roteadores, para cada um dos pacotes, sem guardar nenhum tipo de memória sobre cada pacote. Isto é especialmente ineficiente devido ao fato de que a maioria dos pacotes IP pertencem na verdade a fluxos de pacotes com mesmas origens e destinos.

Outro fator extremamente importante é o custo dos roteadores. Esse custo é em geral muito elevado, o que exige grandes investimentos quando surge a necessidade de se aumentar a rede.

Com base nestes fatores pode-se chegar a conclusão de que uma rede baseada no algoritmo de roteamento padrão das redes IP não é escalonável. Ou seja, não é possível aumentar-se o tamanho de uma rede indefinidamente pois por mais rápidos que os roteadores sejam individualmente, a repetição excessiva de tarefas semelhantes torna o atraso da rede proibitivo.

Ficou claro então a necessidade de novos algoritmos de roteamento. Porém, agora entra em cena um outro fator. Mesmo que fosse desenvolvido um algoritmo de roteamento extremamente eficiente, este não seria muito útil se não fosse compatível com os protocolos e equipamentos já existentes.

Obs. de Helio Rosa: Sugestão de leitura no TELECO: Asynchronous Transfer Mode (ATM)

Este de certo modo foi o maior problema com as redes ATM. Para se implementar redes ATM é necessário grandes investimentos em equipamentos além do que existem grandes dificuldades na interoperabilidade entre o ATM e o IP, principalmente no tocante a redes de grande porte, retornando novamente ao problema de escalonabilidade.

Junto a todos estes fatores pode-se somar a necessidade de novas funcionalidades de roteamento como por exemplo as classes de serviço. Isto decorre do aparecimento de tecnologias como vídeo e voz sobre IP que são extremamente sensíveis ao atraso, em especial atrasos diferenciados para pacotes de um mesmo fluxo. Para ajudar a resolver este problema é necessário se dar prioridade a esses tipos de pacotes, e essa priorização não é suportada por roteadores IP padrão. Ler muito mais em MPLS