WirelessBR

WirelessBR		WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade comercial, feito por voluntários, para divulgação de tecnologia em telecomunicações
Debate: Mapeando nossos backbones
Bruno - Carlos - Julião - Rodolfo - Rogério - Smolka

Esta página contém seis figuras grandes. Aguarde a carga se a conexão estiver lenta.

----- Original Message -----
From: J.R.Smolka
To: wirelessbr@yahoogrupos.com.br
Sent: Friday, July 11, 2008 2:31 AM
Subject: [wireless.br] Mapeando os "nossos" backbones
Oi Julião e demais colegas do grupo.

Vou usar a sua principal pergunta como "gancho" para este post.

Não entendi bem a intenção em "mapear", mas talvez os links abaixo podem lhe exibir o fato de que há muita informação disponível. Pessoalmente diria que a infra-estrutura da Internet está no protocolo BGP e não propriamente nos ASNs (embora seja o pré-requisito para o BGP).

Realmente (como vc mesmo disse mais adiante no seu post) vc "pegou o bonde andando" e, por isso, talvez não tenha entendido bem o objetivo. Em linhas gerais é o seguinte: o Hélio vem publicando uma série de posts com artigos e comentários sob o título geral Como funciona a Internet. Entre outras coisas, ele levantou a lebre do desconforto da comunidade de usuários de Internet no Brasil (especialmente depois do meltdown da rede MPLS da Telefónica em SP) em não entender quem realmente é responsável pelos problemas de conectividade que podem acontecer (e acontecem, pelos mais variados motivos). Ou seja, quando a "vaca vai pro brejo", os usuários ficam perguntando: who´s in charge over here? Who´s accountable? E a resposta, como o próprio Hélio costuma dizer, é um "estrondoso silêncio".

Daí que, no 5° post da série ele fez a seguinte proposição:

"De repente", com este incidente, descobrimos que não sabemos muito sobre esta infra-estrutura no Brasil, tanto em relação à "hierarquia de hardware" como em relação à "hierarquia de responsabilidade" pela segurança e governança da rede. [...] Quem administra, coordena, articula, enfim, "toma continha" desta infra-estrutura, não no papel, mas pra valer? Ou é tudo "ad hoc" e se auto-organiza?

Meu post, ao qual vc respondeu, era uma primeira tentativa de explorar possibilidades nesta área. E os links que vc deu são certamente úteis, mas gostei especialmente a ferramenta BGPlay (http://www.ris.ripe.net/bgplay) no site da RIPE NCC (Réseaux IP Européens Network Coordination Centre), que é um dos cinco RIRs (Regional Internet Registry) autorizados pela IANA (Internet Assigned Numbers Authority) para redistribuição de recursos (blocos CIDR de endereçamento IPv4 e IPv6, números de AS, nomes de domínio DNS, etc.). O CGI.br, que executa este papel no Brasil, é autorizado por outro RIR, o LACNIC (Latin America and Caribbean Network Information Center).

A ferramenta produz um mapa gráfico da "árvore" de conexões a partir de um AS. O único inconveniente é que vc precisa informar um prefixo CIDR que pertença àquele AS. Mas, se vc já souber o ASN, uma consulta no whois do registro.br informa todos os blocos CIDR associados àquele AS. BTW, quem tiver curiosidade em ver um "mapa" de toda a Internet, tem um (ilegível nesta escala) aqui: http://en.wikipedia.org/wiki/Image:Internet_map_1024.jpg.

Mas permita-me discordar um pouco da sua colocação. Os AS são, efetivamente, os blocos básicos para a garantia de conectividade da Internet. Eles tem que cooperar, de um modo federativo, para que as rotas de acesso para cada prefixo CIDR sejam divulgadas para toda a Internet da forma mais eficiente possível.

A interconexão entre AS é feita através de links entre seus roteadores de borda (ASBR - autonomous system border router). O roteamento dinâmico entre os ASBR é mediado por um EGP (exterior gateway protocol), em oposição ao roteamento dinâmico dentro de cada AS, que é mediado por um ou mais IGP (interior gateway protocol). Enquanto a escolha do IGP é uma decisão local de cada AS, o EGP tem de ser comum a todos os AS. No momento (e sem perspectiva de mudança a curto prazo) o EGP padrão para a Internet é o BGP-4 (border gateway protocol version 4) conforme a RFC 4271 do IETF (Internet Engineering Task Force).

Então, os AS interconectam-se livremente, conforme as suas conveniências, e, pelo uso judicioso dos parâmetros de configuração do BGP-4 nos seus ASBR, os administradores de cada AS implementam estes acordos de roteamento na prática.

[ ]'s
J. R. Smolka

----- Original Message -----
From: Julião Braga
To: wirelessbr@yahoogrupos.com.br
Sent: Friday, July 11, 2008 2:17 PM
Subject: Re: [wireless.br] Mapeando os "nossos" backbones

Olá Smolka,

Contribuindo ao debate, tenho algumas considerações pessoais, sobre seus esclarecimentos. A primeira delas se refere ao mapeamento de nossos backbones ou da Internet brasileira. Acho uma tarefa de Hércules. Quase impossível, penso. Basta olhar o "mapa" que você passou.

A governança da Internet brasileira está bem definida: Comitê Gestor (cgi.br). Sob o ponto de vista técnico, o cgi.br faz um bom trabalho, às vezes, com excessivo rigor acadêmico (já tinha dito isso, antes), ignorando um pouco a necessidade prática daqueles que realmente constroem a Internet brasileira. Em relação aos componentes políticos, administrativos e abusos sobre Internet brasileira, o cgi.br é quase inócuo. Por exemplo, não vi nenhum pronunciamento formal sobre o episódio da Telefônica. Nem tampouco, sobre o recente projeto de lei do Senador mineiro, aprovado no Senado Federal, na calada, como realmente parece. No inicio da Internet, por volta de 1992 (época em que ela já era possível, por força da inflexível atuação do Betinho, no IBASE), já se comentava que a Internet era o "caos mais organizado do mundo". A Internet foi criada para não ter dono. A Internet brasileira, de uns tempos para cá, está destoando um pouco dos princípios fundamentais, seguindo os passos de poucos países no mundo. Como um prodígio, ela está em constante transformação e, certamente, cuidados especiais devem ser tomados. Geralmente, também por ser um prodígio, ela acaba se ajustando aos desvios, na sua imensa capacidade de se auto-regulamentar.

Leis são desrespeitadas, regras sobre-estabelecidas. Nada melhor do que ler os textos do Rogério para se ter ciência disso.

O Silvio Meira (http://smeira.blog.terra.com.br/2008/07/06/parou-por-que-o-domino-de-sorocaba/), que deve ser lido atento às entre-linhas, como sempre foi de uma precisão perfeita na abordagem do problema da Telefônica, entre outras questões.

Sobre BGP x AS, permita-me novamente bater na mesma tecla. O BGP (i.e., BGP-4) representa a infra-estrutura da Internet. O conceito de Autonomous System apareceu, explicando metaforicamente, com a intenção de dividir para conquistar a conectividade da imensidão da Internet.

São considerações pessoais, como eu disse. É comum se equivocar. Por exemplo, meu ponto de vista a respeito do Comitê Gestor.

[]s,
Julião

----- Original Message -----
From: bruno@openline.com.br
To: wirelessbr@yahoogrupos.com.br
Sent: Friday, July 11, 2008 6:30 PM
Subject: Re: [wireless.br] Mapeando os "nossos" backbones

Olá

Muito interessante essa discussão, gostaria de tecer um ou dois comentários mais pragmáticos a respeito sobre AS e interconexão e sobre "de quem é a culpa quando tudo cai".

Nos Estados Unidos e também no Brasil, há um esforço centralizador dos grandes players, que se recusam a interconectar (trocar tráfego) com players menores sem cobrar deles o trânsito (explico o que é trânsito no final, para quem ainda não conhece o termo). Por exemplo aqui no Nordeste um cliente da Embratel em João Pessoa para acessar um cliente Telemar (ADSL) na mesma cidade geralmente passeia bastante, indo até Recife, as vezes Salvador, Rio de Janeiro ou mesmo São Paulo para trocar tráfego com o outro backbone e vir pela rede do mesmo até o cliente destino.

E a volta sofre do mesmo problema.

Os usuários de Internet nem imaginam que isso acontece, é bom frisar, mas pode ser facilmente verificado através do TRACEROUTE (Iniciar, executar, cmd, tracert nos Windows), que mostra algumas informações incompreensíveis para leigos mas entre elas o endereço IP (e nome, quando existe) de cada roteador por onde o pacote passa enquanto caminha pela Internet.

Por que os backbones não tem interconexão em mais locais? Porque manter mais pontos de troca de tráfego pressupõe maior gerência de rede, custo de portas
de interconexão (físicas), e tira poder de fogo do fornecedor de backbone em forçar os menores a pagarem trânsito consigo: Por que um provedor de serviços
de internet pagaria caro por link da tele se pode trocar tráfego sem pagar nada ou pagando pouco, localmente?

Portanto, a "culpa" quando há uma queda de link é da operadora, que centraliza para economizar custos ganhando pela escala ao invés de fazer rotas redundantes para minimizar possíveis problemas. E quem precisa de mais resistência se vê obrigado a manter 2 (as vezes mais) fornecedores de Internet para que a queda do principal não interrompa completamente sua comunicação.

Os PTTs (Pontos de Troca de Trafego) que a RNP tem (muito timidamente, IMHO) criado são um esforço para contrabalançar esse interesse privado das teles
face ao interesse público de melhor funcionamento da Internet. Com mais PTTs, no caso de uma queda, os caminhos alternativos automaticamente surgiriam e a
comunicação fluiria, um pouco mais lenta talvez, mas não interromperia de todo.

Por sinal acho que cabe dizer aqui que o pessoal da Abranet, na Presidência do Eduardo Parajós, quer replicar a experiência de PTTs nas demais regiões, onde qualquer um que chegue com meios próprios possa trocar tráfego com os outros e com isso diminuir a dependência de um backbone para que sua Internet
funcione. Um sonho para os provedores independentes.

Eu acho essa idéia louvável e deveria ter mais apoio, mas está sofrendo, digamos, "resistência" por parte das teles em vender os links (sem IP) de São Paulo até cada local em preços acessíveis. Algo como ofertar por R$3 mil um mega de MPLS quando o preço de um link de um mega com a própria tele custa na faixa R$179, por exemplo. As grandes redes de dados (tirando a da Eletronet) já estão nas mãos das teles (por ex. a Rede Pegasus comprada pela Oi, a Geodex comprada pela GVT etc.), o que limita bastante a oferta de fibras para cobrir nosso gigantesco pais (essa é a seara do Rogério *risos*)

Aqui com meus botões eu me pergunto se a rede "gigaflops" da RNP (mapa no endereço abaixo), que tem bastante ociosidade nos links principais, não poderia "hospedar" essa troca de tráfego entre os core routers (no sp.ptt.br) em São Paulo e os provedores independentes nas diversas capitais, já que se
depender das teles isso não sairá do papel nunca...

http://www.rnp.br/ceo/trafego/panorama.php

[]s,
!3runo Cabral

* Trânsito é tráfego internet com o mundo exterior. É diferente de peering pois neste caso este se apresenta como troca apenas com endereços dentro das respectivas redes. Por ex. se eu sou cliente da Embratel faço peering com todos os clientes dela (sem mudar de backbone, embora ela cobre por isso).
Para atingir clientes conectados em outros backbones, como da BrT por exemplo, ou mesmo internacionais, precisaria comprar trânsito. Conectado a um PTT o provedor não pagaria o peering, o que diminui sua conta e com isso possibilita menores preços e mais oferta de serviços aos seus usuários.

----- Original Message -----
From: J.R.Smolka
To: WirelessBR
Sent: Sunday, July 13, 2008 2:37 AM
Subject: [wireless.br] Mapeando os "nossos" backbones (2)

Julião, !3runo (legalzinho esse negócio de leetspeak :-) ) e demais colegas,

Vou tentar me limitar às questões técnicas, e deixas ar discussões sobre política e legislação para a troca de posts com o Rogério :-) .

Primeiro a questão "quem veio primeiro o ovo ou a galinha?" do BGP-4 versus AS. Vou transcrever a introdução da RFC 1930 - Guidelines for creation, selection and registration of an Autonomous System (AS) - que pode ser consultada em http://tools.ietf.org/html/rfc1930:

This memo discusses when it is appropriate to register and utilize an Autonomous System (AS), and lists criteria for such. ASes are the unit of routing policy in the modern world of exterior routing, and are specifically applicable to protocols like EGP (Exterior Gateway Protocol, now at historical status; see [EGP]), BGP (Border Gateway Protocol, the current de facto standard for inter-AS routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the Internet is expected to adopt when BGP becomes obsolete; see [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or Routing Domain Identifier.

Nesta mesma RFC, na seção 3 (definitions), está escrito que:

The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol and common metrics to route packets within the AS, and using an exterior gateway protocol to route packets to other ASes. Since this classic definition was developed, it has become common for a single AS to use several interior gateway protocols and sometimes several sets of metrics within an AS. The use of the term Autonomous System here stresses the fact that, even when multiple IGPs and metrics are used, the administration of an AS appears to other ASes to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it.

To rephrase succinctly: An AS is a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy.

Routing policy here is defined as how routing decisions are made in the Internet today. It is the exchange of routing information between ASes that is subject to routing policies.

Portanto para mim é claro que:

a) O conceito de AS foi criado para definir unidades administrativas que controlam segmentos lógicos (isto é, uma parte do espaço de endereçamento IPv4 ou IPv6) da Internet e a forma de roteamento no seu interior. Sem isto seria impossível que a Internet atingisse a escala mundial que ela tem hoje;

b) Cada AS deve apresentar aos demais AS (isto é, para o restante da Internet) uma política de roteamento única e claramente definida (isto é, como o tráfego destinado a endereços IP no seu interior deve ser encaminhado até a sua "fronteira"). Já o roteamento dentro da "fronteira" de cada AS é de sua exclusiva opção e responsabilidade;

c) A forma como estas políticas de roteamento entre AS são comunicadas entre eles é através das mensagens de um protocolo de exterior routing, compartilhado em comum acordo por toda a comunidade dos AS. Este protocolo já foi o EGP (RFC 904), hoje é o BGP-4 (RFC 4271), e um dia (talvez, when the hell freezes over :-) ) venha a ser o IDRP (ISO/IEC 10747).

Mas as interconexões AS-AS mostram apenas a organização lógica da Internet. Por baixo disto (e muito mais obscura) está a estrutura física de encaminhamento do tráfego. É um fato (e não só no Brasil) que a posse física dos meios de conexão interfere muito na maneira como as coisas ocorrem na prática. Vamos ver, como exemplo, a RNP (ASN 1916). Ela é dona dos seus roteadores, mas os links que os conectam certamente não são de sua propriedade. Então, no mapa que mostra a topologia da RNP (e também o seu "estado de saúde") em http://www.rnp.br/ceo/trafego/panorama.php, podemos ver que no nó principal de tráfego SP existem conexões para a Embratel (ASN 4230) e para a Global Crossing (ASN 3549). Supondo que os roteadores destes dois AS também estejam localizados em SP, existe uma forte possibilidade que os dois links passem pela infra-estrutura da rede MPLS da Telefónica, e tenham caído juntos durante o meltdown.

O caminho alternativo de tráfego mais óbvio seria a conexão SP-RJ, mas se alguma parte física deste link também depender da rede MPLS da Telefónica, adiós. Próxima alternativa seria rotear o tráfego via DF e MG (desde que o link SP-DF também não tenha caído junto com os outros), mas existe a possibilidade de congestionamento se a falha ocorrer em HMM. Conclusão: se os administradores da RNP não planejarem com cuidado de quem eles contratam os seus links, a esperada resiliência do projeto lógico da rede vai pras cucuias.

Se este problema existe no nível urbano das maiores cidades do país, imagine o resto. Quando se trata se provimento de enlaces interestaduais a quantidade de escolhas se reduz a meia dúzia de operadores, e nem todos os trechos que alguém gostaria de conectar possuem mais de um operador com caminhos físicos completamente distintos. Saídas internacionais? Se vc precisa de banda de verdade (digamos, assim, algumas centenas de Mbps) a única alternativa prática são os cabos submarinos de fibras óticas. No mapa disponível em http://www1.alcatel-lucent.com/submarine/refs/World_Map_2007_LR.pdf eu contei sete cabos de conexão internacional e um cabo de uso puramente doméstico. A administração destes cabos geralmente é feita por consórcios, e aposto alguns destes consórcios operam mais de um cabo.

A conseqüência final é que os pontos de interconexão das redes tendem a ser colocados apenas nos locais onde o agregado de tráfego justifique o custo. E é por isto que os grandes provedores de interconexão, que operam os AS de "passagem" para os pequenos provedores de interconexão (que fazem o varejo do negócio de acesso à Internet), cobram "pedágio". Enquanto o tráfego da Internet for composto principalmente por aplicações best effort (ex.: http e smtp) estas "voltas do mar" que o tráfego tem de fazer para passar de um AS para outro não chegam a comprometer a performance (alguns milissegundos a mais ou a menos? No big deal). Mas, quando houver um volume considerável de tráfego real-time, isto será um problema. Será um problema grande o suficiente a ponto de forçar uma mudança neste estado de coisas? Depende de vários fatores, mas isto é assunto para outro post.

Ah! Só para terminar... Alguém aí sabe quais seriam os impedimentos técnicos de lançar um trecho de cabo submarino de Fortaleza a Belém, e um trecho "subfluvial" de Belém a Manaus? Isto daria um desafogo e tanto para a região norte, onde praticamente só se chega por satélite.

[ ]'s

J. R. Smolka

----- Original Message -----
From: Julião Braga
To: wirelessbr@yahoogrupos.com.br
Sent: Sunday, July 13, 2008 5:23 PM
Subject: Re: [wireless.br] Mapeando os "nossos" backbones (2)

Olá Smolka,

Certamente, quem veio primeiro, foi o BGP. Intuitivamente, o conceito de AS veio com o objetivo de facilitar a conectividade, como já disse ("dividir para conquistar"). Não sou um especialista em BGP, ainda. Nem se precisa ser um especialista para implementá-lo. Felizmente, pois o BGP é um protocolo complexo. No inicio, o EGP ficou tão complicado para se alterar que resolveram abandoná-lo, criando o BGP-4. Internamente a uma rede, além dos protocolos internos (OSPF, etc.) é comum usar o próprio BGP (=>BGP-4), criando outros ASs, usando para isso os ASNs falsos (assim como os IPs falsos, para serem usados internamente).

Sua descrição está muito interessante, no que diz respeito aos AS. Se procurar nos traceroutes ou nos Looking Glass, alguns dos quais o !3runo citou ou, por exemplo, http://lg.alog.com.br, verá que a escola do melhor caminho é uma componente inerente ao BGP.

Sobre backbones físicos, não vou comentar nada, pois não estou muito preparado para isso. Há outros, aqui na lista, mais habilitados.

Gostaria, entretanto,adicionar comentário sobre um componente extremamente importante para a infra-estrutura da Internet e, conseqüentemente para a Internet brasileira. Tão importante que, caso não seja dado a devida atenção, poderá causar problemas maiores do o da Telefônica. Talvez tenha até, colateralmente produzido um efeito favorável ao "tranco". Trata-se dos servidores de DNS, ou servidores de nomes. Acho que todos sabem o que é.

Um estudo curioso está em http://mydns.bboy.net/survey/, apresentando um levantamento sobre servidores de nomes no mundo inteiro. Seria interessante um estudo desses no Brasil, identificando as versões de servidores usados. Recentemente, no início desse mês (dia 8,me parece), um conhecido técnico da área de segurança, alardeou um problema que poderia causar um quebra de serviço em servidores de DNS. Eis o site blog do Kaminsky (http://www.doxpara.com / , o cara que, aparentemente, deu o primeiro aviso. Tem, lá nesse blog, um teste para o servidor de DNS que você usa. Felizmente, as equipes competentes e abnegadas, fizeram as alterações necessárias nos softwares, rapidamente. Mas a comunidade da Internet, com raras exceções, parece que não tomou conhecimento do problema. Não entendi bem se o que o Kaminsky estava dizendo era sobre o que está em http://www.kb.cert.org/vuls/id/800113. De qualquer forma, o teste do Kaminsky indicou problemas antes da atualização que fizemos por aqui. Depois não, mas com ressalvas.

Um bom lugar para passear e ver algo sobre servidores de DNS está em http://www.isc.org incluindo algumas estatísticas interessantes.

Mas, deixe o Helio Rosa avaliar ou não sobre a importância dos servidores de DNS para a infra-estrutura da Internet para que falemos mais. A questão principal do DNS é o fato dele possuir uma arquitetura distribuída. Com isso, a responsabilidade de criar servidores que tenham a função de "traduzir" nomes para endereços IPs fica à mercê de técnicos não tão bem preparados. E, na minha opinião, o CGI.br deveria ser mais atento, não sendo suficiente a belíssima e invejável estrutura para controlar domínios brasileiros, disponível no Registro.br.

[]s,
Julião

----- Original Message -----
From: bruno@openline.com.br
To: wirelessbr@yahoogrupos.com.br
Sent: Sunday, July 13, 2008 8:47 PM
Subject: Re: [wireless.br] Mapeando os "nossos" backbones (2)
Prezados Prof. Smolka e demais colegas,

> Mas as interconexões AS-AS mostram apenas a organização lógica da
> Internet. Por baixo disto (e muito mais obscura) está a estrutura
> física de encaminhamento do tráfego. É um fato (e não só no Brasil)
> que a posse física dos meios de conexão interfere muito na maneira
> como as coisas ocorrem na prática. Vamos ver, como exemplo, a RNP
> (ASN 1916). Ela é dona dos seus roteadores, mas os links que os
> conectam certamente não são de sua propriedade. Então, no mapa que
> mostra a topologia da RNP (e também o seu "estado de saúde") em
> http://www.rnp.br/ceo/trafego/panorama.php, podemos ver que no nó
> principal de tráfego SP existem conexões para a Embratel (ASN 4230)
> e para a Global Crossing (ASN 3549). Supondo que os roteadores destes
> dois AS também estejam localizados em SP, existe uma forte possibilidade
> que os dois links passem pela infra-estrutura da rede MPLS da Telefónica,
> e tenham caído juntos durante o meltdown.

Sim, os links podem ser de propriedade de outras teles. Por outro lado, como exemplifiquei ao falar sobre o movimento de concentração de tráfego de cada tele dentro sua própria rede, elas costumeiramente não "alugam" portas MPLS das outras, se utilizando de links fisicos dedicados para comunicação (o antigo SLDD, em menor escala, ou espaço em fibra ótica, quer "apagada" ou na hierarquia SDH, onde há isolamento entre as conexões, em maior escala)

Felizmente(?) então a suposta pane no MPLS da Telefônica não afetou os outros backbones, mas apenas a comunicação destes com a rede IP daquela empresa. Como a rede da Telefônica é gigante, claro, muita coisa "caiu" junto, mas não "toda" a Internet do Brasil (eu tenho um POP em SP e ele sobreviveu ao evento, assim como todos que mantêm ligação com os PTT de lá).

Por outro lado a pouco tempo houve um problema com outra rede IP, menos (ou nada) noticiado, onde ela inadvertidamente se anunciou como trânsito nacional para o exterior. Como os links dela não aguentaram o tranco do tráfego de todos os outros baclbones (nem poderiam, a tele não era tão grande) houve uma parada por saturação do tráfego internacional, esta felizmente identificada e sanada com o isolamento do AS em questão até que a configuração do mesmo foi consertada e sem causar o celeuma deste episódio (quem quiser saber mais sobre esse caso deve consultar o histórico da lista GTER do Grupo de Engenharia de Redes do registro.br)

Eu não me sinto conhecedor o suficiente para sugerir ao NIC.BR, ao Comitê Gestor ou a quem quer que seja uma intervenção maior nessa questão dos PTTs, mas me admira bastante a ANATEL ter feito pressão pelo peering entre a Intelig e a Embratel no berço da privatização (quando todas ainda tinham "medo" da LGT, o que
hoje já não tem) e não ter faito o mesmo entre as outras teles fixas (não só em IP, acho o mesmo na interconexão STFC) ou entre estas e as empresas detentoras de licenças SCM.

Com isso chegamos ao absurdo da tarifa de interconexão Classe V (*) de IP custar de mais de R$1200 por mega enquanto as teles cobram dos usuários finais (de ADSL) cerca de 10 a 15% desse valor. Ou existirem SCM pagando R$450 o mega enquanto outros pagam de R$1500 (no Nordeste) a R$14000 (em Manaus!) pelo mesmo mega de Internet.

Dá para criar um ambiente de competição sério e benéfico para o consumidor com tanto disparate no preço do insumo? E a solução para a competição será concentrar ainda mais o mercado?

[]s,
!3runo Cabral

(*) o nome pomposo de uma tele trocar tráfego com a outra, onde a que tem maior tamanho cobra uma tarifa pelo excedente do que fornecer para a menor. A tele que não tem o volume para justificar interconexão precisa pagar trânsito como um cliente qualquer.

----- Original Message -----
From: Rogerio Gonçalves
To: wirelessbr@yahoogrupos.com.br
Sent: Monday, July 14, 2008 12:17 AM

Subject: [wireless.br] Re: Mapeando os "nossos" backbones (2) Alô Bruno, Smolka, Julião (é bom te ver por aqui Chefia) e demais participantes que estão tocando tão bem esse tópico, que é uma verdadeira aula sobre backbones tupiniquins.

Para não poluir o tópico com minhas sandices político-legislativas, vou ser breve, fazendo apenas algumas perguntinhas pro pessoal pensar na cama:

1) Cadê aquele backbone IP público, operado pela Embratel, que foi financiado com recursos do extinto FNT e boa parte da grana dos milhões de planos de expansão comercializados no período 95-97? Por acaso teria ele virado fumaça quando a estatal se tornou concessionária de telefonia fixa em junho de 98?

2) Não parece óbvio que o objetivo dessa pajelança promovida pelo governo (criação da Broi, alteração no PGO e novo PGMU) é impedir que a Telefonica e a Embratel duopolizem o mercado de backbones?

3) Quem quer apostar uma bananada que, assim que o governo emplacar a pajelança, a Broi vai comprar a rede da Eletronet usando a grana do FUST?

4) Como as concessionárias do STFC poderiam estar comercializando "links IP", se esse tipo de atividade, inerente aos serviços de comunicação de dados, não envolve os tais "processos de telefonia"?

5) Por que não existe uma classe de interconexão específica para as redes de comunicação de dados, se a existência dessa modalidade de serviço é prevista expressamente pela LGT?

Ao Prof. Smolka, eu sugiro que dê uma conferida no projeto Navega Pará (http://www.navegapara.pa.gov.br/ ), que pretende utilizar a rede SDH da Eletronorte (Eletronet) para ligar o backhaul metro ethernet do projeto ao cabo submarino que sai de Fortaleza, em velocidade de 2.5 gigas (STM-16).

Sugiro também que o pessoal dê uma conferida na inusitada união Telemar/Embratel para tentar melar o projeto da governadora Ana Júlia que por acaso, é do PT. (http://www.jesocarneiro.com/governo-ana-julia/telemar-contra-o-navega-para.html).

Enquanto a gente discute, os caras vão lá e... créééuuuuu.

Um abraço

Rogério
P.S. Caso alguém queira discutir o assunto, por favor o faça em outro
tópico.
Valeu?

----- Original Message -----
From: bruno@openline.com.br
To: wirelessbr@yahoogrupos.com.br
Sent: Monday, July 14, 2008 11:14 AM
Subject: Re: [wireless.br] Re: Mapeando os "nossos" backbones (2)
Alô pessoal

Rogerio_Gonçalvesescreveu:

> Alô Bruno, Smolka, Julião (é bom te ver por aqui Chefia) e demais
> participantes que estão tocando tão bem esse tópico, que é uma
> verdadeira aula sobre backbones tupiniquins.
>
> Para não poluir o tópico com minhas sandices político-legislativas,
> vou ser breve, fazendo apenas algumas perguntinhas pro pessoal pensar
> na cama:
(...)
> 2) Não parece óbvio que o objetivo dessa pajelança promovida pelo
> governo (criação da Broi, alteração no PGO e novo PGMU) é impedir que
> a Telefonica e a Embratel duopolizem o mercado de backbones?
>
> 3) Quem quer apostar uma bananada que, assim que o governo emplacar a
> pajelança, a Broi vai comprar a rede da Eletronet usando a grana do
> FUST?

Eu não duvido em nada que a Eletronet seja arrebatada em breve, tendo em vista que os órgãos de defesa da concorrência (CADE e SDE) não viram nenhum problema na concentração das outras redes de fibra pelas teles (Rede Pegasus pela Oi, Geodex pela GVT etc.). Minha esperança é a Dilma.

Por outro lado, vou resumir aqui uma teoria que já circula nos meios especializados a algum tempo, sobre a possivel nova estratégia da Telmex com a Embratel e as compras constantes das redes de TV a cabo pela NET (da qual a Telmex é acionista).

A teoria é que a Embratel estaria deliberadamente fagocitando sua carteira de clientes IP dedicado, ofertando preços maiores em expansões ou no fim dos contratos, para que os clientes saiam e ela não tenha que fazer investimento em upgrade de backbone. Parece estranho, mas ao "livrar" a rede dos clientes médios ela pode colocar mais usuários finais (wimax, claro 3g, embratel "pme") que são teoricamente mais rentáveis que os exigentes clientes de IP dedicado, ainda mais que estes podem se tornar empresas de telecom (com licença SCM por exemplo) e concorrer com a Telmex na oferta de última milha, VoIP e mesmo STFC.

Acredito que essa atitude não seja apenas da Telmex. Conheço várias empresas com SCM com contratos assinados com a Oi cujas instalações não acontecem sem nenhum tipo de satisfação por parte da empresa.
Na Telefônica e BrT não tenho informações sobre acontecer isso.

A agência, quando acionada, não faz absolutamente nada, como de costume.

[]s,
!3runo Cabral

----- Original Message -----
From: Carlos Carneiro
To: wirelessbr@yahoogrupos.com.br
Sent: Monday, July 14, 2008 12:02 PM
Subject: Re: [wireless.br] Re: Mapeando os "nossos" backbones (2)
Bruno,

2008/7/14 bruno@openline.com.br bruno@openline.com.br:

Por outro lado, vou resumir aqui uma teoria que já circula nos meios
especializados a algum tempo, sobre a possivel nova estratégia da
Telmex com a Embratel e as compras constantes das redes de TV a cabo
pela NET (da qual a Telmex é acionista).

A teoria é que a Embratel estaria deliberadamente fagocitando sua
carteira de clientes IP dedicado, ofertando preços maiores em expansões
ou no fim dos contratos, para que os clientes saiam e ela não tenha que
fazer investimento em upgrade de backbone. Parece estranho, mas ao
"livrar" a rede dos clientes médios ela pode colocar mais usuários finais
(wimax, claro 3g, embratel "pme") que são teoricamente mais rentáveis
que os exigentes clientes de IP dedicado, ainda mais que estes podem
se tornar empresas de telecom (com licença SCM por exemplo) e concorrer
com a Telmex na oferta de última milha, VoIP e mesmo STFC.

Acredito que essa atitude não seja apenas da Telmex. Conheço várias
empresas com SCM com contratos assinados com a Oi cujas instalações
não acontecem sem nenhum tipo de satisfação por parte da empresa.
Na Telefônica e BrT não tenho informações sobre acontecer isso.

Ou fazem isso por saberem que a grande maioria daqueles que precisam e solicitam os link não tem a quem recorrer, sendo empresas se veem obrigadas a aceitar, se são provedores inviabilizam suas operações e aqueles que possuem SCM eles sabem que essa licensa é mais uma sopa de letrinhas criada com o objetivo de arrecadar do que regular pois apenas as obrigações para aqueles que possuem a licensa estão reguladas a numeração por exemplo para as empresas SCM nem se sabe quando (isso é se um dia acontecer) vai se ter.

A agência, quando acionada, não faz absolutamente nada, como de costume.

Para não fazer diferente do Cade e do SDE e nada fazem a MUITO tempo seguindo a um belo exemplo a JUSTIÇA que permitiu a renovação do contrato com as operadoras sob a alegação de que a não renovação traria um imagem negativa para o país. (Lasque-se o povo em detrimendo da imagem do país lá fora)

Seremos mais felizes o dia em que assumirmos o nosso papel de palhaço nisso que chamamos de sociedade brasileira e passarmos a sair todos com o nariz vermelho para trabalhar, passear, viajar e incorporarmos de vez as vestimentas de palhaço no nosso dia a dia. Pois é isso que somos.
Os palhaços desse país.

Atenciosamente,
Carlos Roberto Maciel Carneiro
carlos.roberto.maciel@gmail.com
Macaé/RJ
Tel.: (22) 9869-5054

----- Original Message -----

From: Rodolfo Daniel Gross Villanova
To: wirelessbr@yahoogrupos.com.br
Sent: Monday, July 14, 2008 6:11 PM
Subject: RES: [wireless.br] Mapeando os "nossos" backbones

Senhores,
Utilizando a ferramenta "bgplay" veiculada aqui na lista, examinei e comparei os tráfegos antes, durante e após o "apagão".
Parece claro que durante o período da "tempestade" houve diversas rajadas de tráfego intenso e anormal de pacotes BGP entre roteadores vizinhos e o AS centro da crise.
Não cheguei a examinar o conteúdo dos referidos pacotes, pois não tive acesso a eles.
Mas, o que isso parece significar?

O BGP é um protocolo utilizado entre roteadores adjacentes para indicar caminhos conhecidos de fluxo de tráfico de pacotes IP.

Os roteadores, com base nos dados recebidos de roteadores vizinhos, atualizam suas próprias tabelas de roteamento em função dessas informações de rotas. E assim, sucessivamente, cada roteador propaga a seus roteadores vizinhos indicadores dessas rotas para encaminhamento do fluxo de pacotes IP na internet.

Apenas uma única rota configurada de forma equivocada num roteador de borda pode causar uma tempestade como a que ocorreu naquele período.

Se o referido roteador não estava configurado para armazenar logs das trocas de informações entre os roteadores para atualização de suas respectivas tabelas de roteamento (o que é muito comum), dificilmente se terá como coletar vestígios, pois o roteador apontado como a fonte do problema, segundo noticiado, foi desligado, substituído e encaminhado para perícia. Os dados das tabelas de roteamento normalmente ficam armazenados em memória do tipo RAM, que perde seu conteúdo ao se desligar a alimentação elétrica do equipamento.

Ressalto que o que expus acima é fruto de dedução e possibilidades levantadas a partir de informação colhida através da ferramenta (aliás, muito útil e fácil de usar) referida no "caput" desta mensagem, bem como de vivência em ambientes de interconexão de redes.

Grato pela atenção,
Rodolfo Villanova

De: wirelessbr@yahoogrupos.com.br [mailto:wirelessbr@yahoogrupos.com.br]
Em nome de Julião Braga
Enviada em: terça-feira, 15 de julho de 2008 08:35
Para: wirelessbr@yahoogrupos.com.br
Assunto: Re: [wireless.br] Mapeando os "nossos" backbones

Olá Rodolfo,

Registrou esta análise que fez? Tem como nos mandar? Ou mandar em PVT?

Obrigado e []s,

Julião

De: Rodolfo Daniel Gross Villanova [mailto:rodvilla@ig.com.br]
Enviada em: terça-feira, 15 de julho de 2008 17:00
Para: wirelessbr@yahoogrupos.com.br
Assunto: RES: [wireless.br] Mapeando os "nossos" backbones

Caro Julião.

Eu somente havia visualizado os gráficos quando emiti minha impressão; porém, a seu pedido, refiz as consultas e registrei "snapshots" de tráfego em momentos significativos.

Os mais curiosos perceberão que é bem mais interessante visualizar no próprio bgplay a dinâmica da evolução das alterações das rotas de tráfego no tempo.

Os arquivos com as imagens estão em anexo.

Num primeiro momento, por volta das 20h do dia 25/06, surge uma intermitente e esporádica alternância de rotas entre o AS da Telefonica e o AS da Sprintlink, em que várias vezes o salto, que normalmente é único, passa a ser intermediado através do AS da Level 3 Communications. Essa intermitência se acentua a partir do dia 28/06. (arquivos BGPlay_20080629_?.bmp)

A partir do dia 02/07, por volta das 13:36, inicia então uma espécie de "broadcast storm", com uma seqüência quase interminável de troca de rotas seguidas entre o AS foco de nossa atenção e os AS vizinhos. (arquivo BGPlay_20080701.bmp)

Essa tempestade dura até por volta das 22:33 do dia 03/07, quando inicia a estabilização. (BGPlay_20080703.bmp)

Na última imagem (BGPlay_20080705.bmp) já se percebe claramente que a rede voltou a se estabilizar, cujo registro histórico apresenta raras atualizações de rotas.

Os dados que serviram de base para essa análise foram obtidos no site http://registro.br e configurados no site http://www.ris.ripe.net/bgplay, conforme o prof. Smolka havia indicado.

Grato,

Rodolfo Villanova

----- Original Message -----
From: Rodolfo - GMAIL
To: juliao@braga.eti.br
Cc: rosahelio@gmail.com
Sent: Tuesday, July 15, 2008 6:26 PM
Subject: ENC: [wireless.br] Mapeando os "nossos" backbones

Caros Helio e Julião,

Encaminho a mensagem pras contas de vocês em razão de o Yahoo não permitir o envio de mensagens maiores que 1MB, o que ocorre em razão dos arquivos de imagens em anexo.

Não estou tendo tempo pra tentar reduzir esses tamanhos.

Façam o melhor que conseguirem.

Grato,
Rodolfo

----- Original Message -----
From: J.R.Smolka
To: Helio Rosa
Cc: Rodolfo - GMAIL ; juliao@braga.eti.br
Sent: Wednesday, July 16, 2008 1:19 AM
Subject: Re: P/ Rodolfo, Julião e Smolka - Mapeando os "nossos" backbones

Hélio, Rodolfo e Julião,

Achei muito interessante observar o advertisement storm que, muito provavelmente, foi desencadeado pelo problema na rede MPLS da Telefónica em SP. Mas não sei se vcs notaram duas coisas:

1. Consultando o CIDR Report (os links levam aos relatórios específicos), encontramos que o ASN 12956 pertence ao backbone internacional da Telefónica. Ele está conectado downstream com o ASN 10429, que pertence à Telefónica Empresas (já no Brasil) e que, por sua vez, está conectado downstream com o ASN 27699, este sim pertencente à Telefónica SP (operadora de telefonia fixa), e que é um "fim de linha". Se o backbone internacional da Telefónica recebeu esta "pancada" é porque nem o pessoal da Telefónica SP, nem o pessoal da Telefónica Empresas tiveram o bom-senso de bloquear temporariamente os advertisements do E-BGP para seus ASs neighbor. Então estas figuras estão mostrando efeitos, ruins com certeza, mas não causas. Estranho que os administradores do backbone internacional da Telefónica não tenham percebido o route flapping e isolado a fonte de advertisements malucos, ou, pelo menos, dado um "puxão de orelha" nos administradores da Telefónica Empresas.

2. Se eu tivesse projetado a rede MPLS da Telefónica SP, eu jamais colocaria um mesmo roteador fazendo o papel de PE e de ASBR. O mais sensato seria manter a rede MPLS "estanque", configurar o AS da Telefónica SP como uma VRF (e o AS da Telefónica Empresas também, se ele tiver que cursar tráfego pela rede MPLS), onde cada ASBR seria um roteador CE.

Então, quando a Telefónica SP divulgou para a imprensa que a causa era "um roteador de borda" em Taubaté, ela poderia estar se referindo a um roteador PE da rede MPLS. Neste caso a confusão de roteamento na rede MPLS causou o "enlouquecimento" dos ASBR do AS Telefónica SP (porque eles ficavam vendo as rotas entre eles apagando e acendendo conforme os LDPs da rede MPLS entravam e saiam do ar). Os ASBR do AS Telefónica SP propagaram seus advertisements para o AS da Telefónica Empresas e esta para o AS do backbone internacional Telefónica. Este cenário supõe, em princípio, que todos os ASs que tenham seus ASBRs conectados através da rede MPLS sejam, cada um, uma VRF separada, e que os papéis de PE e ASBR não convivem no mesmo roteador. O ponto contra este cenário é: porque os ASs upstream ao problema não isolaram o AS da Telefónica SP, suposto ponto de origem da falha?

Mas existe um cenário alternativo (duro de provar). Suponhamos que o projeto da rede MPLS da Telefónica SP não separou os papéis, e que os ASBRs de peering com a Telefónica Empresas sejam também PEs da rede MPLS. E suponhamos também que o route flapping fosse iniciado não na Telefónica SP, mas no AS backbone internacional da Telefónica. Então os advertisements doidos vindos de cima poderiam corromper o I-BGP dos ASBRs do AS Telefónica SP, porque eles também seriam PEs. E, se o I-BGP de um PE endoidar você pode arrastar toda a rede MPLS junto, porque a redistribuição de rotas para os CEs das várias VRFs depende que os PEs e Ps da rede MPLS falem I-BGP entre eles. Plausível?

[ ]'s

J. R. Smolka