Introdução

Desde que iniciei com este blogue, no final de 2005, muitos amigos e leitores encaminham-me, sistematicamente, sugestões e críticas, construtivas, de vários tipos. Alguns dizem que os textos estão muito longos e pedem para que os segmente, outros indicam falhas ou conteúdo que geram dúvidas, principalmente de interpretação, por não estarem suficientemente claros. Outros insistem para que os textos sejam transformados em livro. Há uns três anos atrás pensei, seriamente, nesta possibilidade. Portanto, recentemente decidi que isto seria feito. Na realidade, pensei em dois livros. Um com a exposição dos textos do blogue, refinados e organizados em forma e conteúdo adequados, a preservar a tese de conhecimento auxiliar àqueles que precisam de uma referência imediata e simples.

Entretanto, durante um ano “quase” sabático que me dei, refleti e imaginei a possibilidade de escrever o segundo livro, no qual a simplicidade do conhecimento e experiências que acumulei ao longo dos muitos anos de trabalho pudessem ser expostos a partir de uma topologia que fosse capaz de exibir a aplicação de problemas de interconexões e de decisões sobre quais protocolos usar, principalmente, orientados aos pequenos e médios provedores.

Desde então, comecei a me preparar para este segundo livro, já que a decisão sobre o primeiro livro estava tomada e em andamento, com a ajuda do Deivison Moraes, o qual participou, remotamente, de diversas experiências necessárias à consolidação do conhecimento envolvido. Para o segundo livro, escolhi uma arquitetura, que a princípio parece complexa (mas, não é), contendo tudo aquilo necessário para que o administrador de um pequeno e médio provedor deve conhecer, para construir uma infraestrutura da Internet melhor. Ao dizer isto estou fazendo apologia à estrutura e missão do IETF, que pode ser adaptada do RFC3935: “É uma comunidade internacional de pessoas interessadas em cumprir a missão de produzir, com alta qualidade e relevância técnica, documentos de engenharia, que influenciam a maneira como as pessoas projetam, usam e gerenciam a Internet, de tal maneira, que ela possa funcionar cada vez melhor.”

O título escolhido, para o segundo livro, “Topologias, Interconexões e Protocolos” insiste no fato de que estas três palavras evidenciam questões inter-relacionadas que exigem decisões corretas e seguras, de implementação. A arquitetura (no sentido de uma topologia ou de diversas topologias) é o planejamento ou projeto, com base nas disponibilidade de recursos e facilidades disponíveis, no cenário em que se insere. As Interconexões exigem ou são exigidas na escolha dos Protocolos. Protocolos dependem de Interconexões e são tratados, pelo livro, em um sentido mais amplo, ao adotar componentes necessários ao funcionamento da Infraestrutura da Internet, local ou não. Observações anotadas e retiradas das listas do IETF (de grupos de trabalhos ou independentes), das listas dos RIRs (Regional Internet Registers), de listas internacionais independentes, das listas brasileiras (GTER, a peculiar, finada prematuramente, GT-AS, entre outras), dos cursos de IPv6 do Nic.br e outros (como o recente curso para ASes), tudo, foi usado para compor a proposta do livro. Adicionalmente, uma extensa referência bibliográfica coletada e lidas por mim, ao longo dos anos (artigos, livros, RFCs e equivalentes) expande a estrutura fundamental, do conhecimento exigido e exposto. O que faltava era ajustar tudo isto de forma simples, atento ao ponto de vista de Alfred North Whitehead: “Seek simplicity, but distrust it”.

Abaixo seguem extratos dos dois primeiros capítulos do livro (Introdução e Topologias), que orienta o sobre como será o conteúdo dos capítulos restantes. Vamos esperar para uma avaliação dos autores.

1. Introdução

A Infraestrutura da Internet está, sistematicamente, em movimento. Há poucos anos atrás, a perspectiva da escassez do IPv4 trouxe o IPv6 para resolver o problema. Foi um impacto radical, em particular, sobre a mente dos administradores da Infraestrutura da Internet. Assim, antes da chegada do IPv6 e durante muitos anos, a Internet era representada nos textos, de forma abstrata, como se fosse um nuvem, em variações diversas, semelhante à Figura 1.1.

Figura 1.1. Representação abstrata da Internet.

Com a chegada do IPv6, até podemos representar a Internet como a Figura 1.1, desde que fique claro que a Internet, na realidade é composta de dois ambientes bem definidos: o ambiente IPv4 e o ambiente IPv6. Uma possível representação desta nova abstração é a Figura 1.2.

Figura 1.2. Nova representação abstrata da Internet.

Neste livro, por razões didáticas iremos preferir uma representação mais apropriada para escapar das imagens confusas, ao associarmos topologias, interconexões e protocolos. A Figura 1.3 exibe a nossa proposta, onde o fundo branco servirá para desenhar os modelos propostos.

Figura 1.3. A representação abstrata da Internet, para efeitos deste livro.

Se a Internet está envolvida, qualquer roteador colocado na área branca da Figura 1.3, que esteja conectado a outro roteador de um Sistema Autônomo (AS) tornará, imediatamente, membro da Internet, juntamente com toda a sua rede interna de usuários e/ou computadores. Portanto, o espaço em branco é outra abstração, que estamos usando, para facilitar a exploração didática dos conceitos abordados.

O livro está estruturado em quatro capítulos básicos: Introdução, Topologias, Interconexões e Protocolos. Completam o livro, um considerável glossário, seguido de uma Referência Bibliográfica bastante completa e de índices (analítico, remissivo e figuras), além de Anexos abordando equipamentos, roteadores, ferramentas e servidores essenciais à Infraestrutura da Internet. Os anexos sobre outros roteadores que não aqueles usados no capítulo de Protocolos, adicionam alternativas de usá-los, por alguma razão específica do leitor.

2. Topologias

2.1 Tráfego, trânsito e transporte

Topologia é o recurso inicial, que um administrador da Infraestrutura da Internet tem disponível, para planejar e desenvolver o projeto de uma ou mais interconexão e os respectivos protocolos necessários. Geralmente, usamos um processo de modelagem (ou desenho) de uma topologia, usando a técnica de refinamentos sucessivos para chegarmos ao modelo final esperado, ou melhor, o modelo ótimo. Por outro lado, a apresentação das diversas topologias neste texto, nos dá a impressão de que foi imediato, o desenvolvimento do projeto. Não foi! Levou-se um bom tempo para chegar à etapa descrita, inicialmente, neste capítulo e, outras mudanças virão na sequência. Na prática percebe-se de que a oportunidade de usar a técnica de refinamentos sucessivos é fundamental e fortemente recomendada, pois ela permite o entendimento completo do problema, etapa por etapa. Em cada refinamento, ou cada etapa, a utilização de ferramentas de simulação representaram uma decisão de projeto extremamente eficaz, mas reconhecidamente trabalhosa. Várias outras ferramentas foram utilizadas, sobre as quais comentamos nos Anexos.

2.2 Topologia da Localidade 1

O exemplo escolhido para ilustrar as questões que encontramos em nosso dia a dia, envolvendo topologia, interconexões e protocolos foi o de uma empresa, que possui filiais em seis localidades remotas e principais, além de quatro outras localidades “secundárias”, mas também remotas. O objetivo da empresa é atender suas demandas de tráfego de dados dentro de cada localidade e entre todas as localidades. Como qualquer empresa, custo é um componente importante e a máxima é minimizá-lo.

A Localidade 1 possui uma característica importante: nela estão os recursos necessários para administrar toda a infraestrutura de tráfego de dados. Por recursos entende-se pessoal, equipamentos, software, ferramentas e tudo mais necessário para atender a este objetivo. A Figura 2.1 exibe a topologia da Localidade 1, a qual passamos a descrever.

Figura 2.1. Topologia da Localidade 1.

Na topologia da Figura 2.1, vemos a rede interna (azul claro) e o seu roteador de borda identificado pelo número 1. Este roteador tem três conexões. A conexão em verde, com o roteador T11 é a oferta de tráfego de dados para a Internet. Dizemos, então, que T11 pertence a um provedor que oferece trânsito. Reforçando, tráfego de dados para a Internet, chamamos de trânsito. Esta conexão de trânsito, entre 1 e T11 é direta, no sentido de que existe um meio físico conectando os dois roteadores. Há, entretanto, uma curiosidade neste trânsito: ele é assíncrono, isto é, as velocidade de subida e descida, do tráfego de dados, são diferentes. Verde é a cor que usaremos para identificar conexão assíncrona. O fornecedor de trânsito para a Localidade 1, somente oferece trânsito para a Internet IPv4. Foi necessário conseguir um trânsito IPv6 usando um túnel (“tunnelbroker”), com a Hurricane Electric (HE), que oferece tal facilidade, sem custo. A conexão com a HE não é direta e, portanto, exige interconexão com a Internet, em IPv4. Embora a HE não exija, a empresa usou seu ASN para fazer um empareamento (“peering”) com o HE1 (roteador da HE que atende ao trânsito IPv6 para a empresa, na Localidade 1. Como a empresa precisa de trânsito IPv6, em todas as localidades, a equipe técnica resolveu solicitar um empareamento com o Team Cymru (TCY), com o objetivo de receber os blocos IPv6 que não são anunciados na Internet, informação muito útil para os administradores da empresa, ao eliminar um considerável esforço extra de gerenciamento. O TCY estabelece o empareamento através de ASNs privativos, o que indica que não é necessário possuir um ASN para o empareamento com eles.

O trânsito assíncrono com T11 é uma aDSL. Os fornecedores de aDSL no Brasil, não possuem o hábito de estabelecer empareamento em seus roteadores com os clientes.

Não estamos interessados em avaliar o mérito do significado de um trânsito assíncrono. A escolha foi feita partindo das premissas: baixíssimo custo e interesse técnico.

Há diferenças entre o tráfego de dado estabelecido com o Team Cymru e com a HE. O primeiro é somente tráfego de dados (em uma única direção) e o segundo é trânsito! Tráfego de dados como o do Team Cymru, é dito tráfego de empareamento (ou tráfego de “peering”), ou mais simplesmente, tráfego (quando não há custos envolvidos, como é o caso). A conexão com o Team Cymru não é direta, razão pela qual usamos a cor vermelha.

Já é possível perceber, que não estamos interessados em questões de implementação ou outros detalhes de cada fornecedor de tráfego. Isto acontecerá nos Capítulos 3 e 4. Por hora, nossa preocupação são as topologias. Claro é, entretanto, que os envolvidos na topologia possuem um conhecimento técnico anterior. Até o final do livro, isto será transmitido para aqueles que ainda não detêm tal conhecimento.

A importância da Localidade 1, para a equipe técnica está caracterizada pelo retângulo, no desenho.

2.2 Topologia da Localidade 2

A Figura 2.2, apresenta a topologia da Localidade 2.

Figura 2.2. Topologia das Localidades 1 e 2.

A topologia da Localidade 2 mostra uma conexão de trânsito em T21 (via fibra ótica), agora síncrona. T21 é um AS, o que implica em um trânsito com empareamento entre os roteadores 2 e T21. Este empareamento com T21 recebe a tabela completa de rotas disponível da Internet e, o roteador 1, não faz nenhuma restrição do que chega até ele, nesta tabela, exceto a rotas padrões (ou, “default”) e seus blocos anunciados. Também, trânsito IPv6 não é oferecido por T21 e, portanto, suprido pela HE (HE2). Como temos agora, IPv4 e IPv6 sendo oferecidos foi conveniente fazer dois empareamentos com o TCY, para receber os blocos IPv4 e IPv6, não anunciados (chamado de “bogon”, em ambos os casos). O TCY exige dois empareamentos (para segurança adicional da conexão), para cada tipo de “bogon”: dois para o IPv4 e dois para o IPv6. Então, o roteador 2 tem quatro empareamentos com o TCY (no roteador 1, são dois empareamentos).

A novidade na Localidade 2 é a conexão com um dos Pontos de Troca de Tráfego (PTTs) brasileiros. Nesta Localidade temos o PTT1, com uma conexão de tráfego, parecida com a do Team Cymru e por isto, conexões a PTTs são chamadas simplesmente de tráfego (ou tráfego de empareamento). Ao PTT1, está conectado o T22, com o qual a empresa resolveu fazer um acordo bilateral dentro do PTT1, para seu trânsito redundante na Localidade 2, à Internet. Há entretanto, uma conexão de trânsito, entre o T21 e o T22 indicando que o trânsito da empresa na Localidade 2 é feita, na realidade, somente pelo T22. Este aparente excesso será analisado detalhadamente no Capítulo 3 (Interconexões). A conexão do roteador 2 com o PTT1 é direta (local, para sermos mais precisos).

2.3 Topologia da Localidade 3

Nossa abordagem agora será sobre a Figura 2.3, que expõe a topologia da Localidade 3.

Figura 2.3. Topologias das Localidades 1, 2 e 3.

A Localidade 3 tem trânsito IPv6 e IPv4, diretamente de T31. O fornecedor T31 recebe trânsito IPv6 de T32 do qual, também. recebe trânsito IPv4 e transporte até o PTT4. O T31 recebe trânsito IPv4 de T33, o qual fornece transporte até o PTT2. Nesta topologia, o roteador 3 possui um empareamento em pilha dupla (IPv4 + IPv6) com seu único fornecedor de trânsito, o T31. O TCY é usado, com quatro empareamentos para receber os “bogons” IPv4 e IPv6. É do nosso conhecimento, que T31 possui trânsitos com bandas diferentes, de T32 e T33. O conexão de 3 com T31 é local, o que favorece, no empareamento, somente o recebimento da rota padrão, sem necessidade de tabelas de roteamento.

Vamos à topologia da Localidade 4, mostrada na Figura 2.4.

2.4 Topologia da Localidade 4

Figura 2.4. Topologias das localidades 1, 2, 3 e 4.

A topologia para a Localidade 4 é parecida com a da Localidade 3, exceto pelo fato de possuir trânsito somente com um fornecedor, o T41, que por sua vez, também possui uma única conexão de trânsito, com o T411. Um pouco mais elaborada, a topologia mostra que o roteador 2 recebe trânsito IPv6, através de uma conexão com o PTT2, em um acordo bilateral com um fornecedor por lá conectado. Com podemos observar, o PTT2 é também, uma conexão da Localidade 3 mas, que não recebe trânsito IPv6, por lá. O Team Cymru está, também, empareado nesta localidade (TCY).

O desenho ilustra que o tráfego do roteador 4 ao PTT2 é invisível aos fornecedores de trânsito. Bem como o trânsito IPv6.

A topologia da Localidade 5 é discutida no tópico abaixo.

2.5 Topologia da Localidade 5

A Figura 2.5 exibe a topologia da penúltima localidade.

Figura 2.5.

Sem redundância, o T51 fornece trânsito para a empresa, através de T52. Como T52 não é uma conexão direta, é a localidade com a pior deficiência na segurança de tráfego para a Internet, muito embora isto não aconteça nos trânsitos construídos por T52. Um novo PTT, o PTT1 está acessível aproveitando a oportunidade de transporte que T52 oferece para T51.

2.6 Topologia da Localidade 6

A Figura 2.6 mostra uma topologia preliminar da Localidade 6.

Figura 2.6.

É a única em que o trânsito não é direto com o roteador de borda da Internet. Mas, isto não representa uma insegurança para a conexão, porque o roteador T61 está em uma rede diretamente conectada. Além do mais, o T61 está diretamente conectado a diversos trânsitos redundantes. Embora um dos trânsitos de T61 ofereçam IPv6, não foi possível, ainda, usar esta facilidade. Por esta razão, o trânsito IPv6 é feito via túnel, com a HE (HE6). Via T61, conseguiu-se acesso a um outro PTT, o PTT5. A troca de tráfego multilateral no PTT1 é muito interessante para a Localidade 6. Insistentemente, o TCY é usado, também.

A Localidade 6 possui uma característica especial, no contexto da empresa, que é o controle sobre atividades de quatro outras localidades próximas, mas remotas. Esta relação está exibida na Figura 2.7. O trânsito de Internet para estas localidades é feito pela Localidade 6. Por outro lado, a Localidade 6 possui uma série de outros recursos especialmente úteis para atender a sua demanda remota.

Figura 2.7. Topologias de todas as localidades e a extensão da Localidade 6.

2.9 A arquitetura final

Cada localidade da empresa está acessível através da Internet. Logo, a empresa ESTÁ na Internet, pois ela usa seus ASNs, em cada localidade, para que isto aconteça (exceto a Localidade 1). A Figura 2.8 ilustra bem este fato.

O pessoal de administração da rede da empresa, presentes, em sua quase totalidade, na Localidade 1, gerencia todos os recursos, principalmente usando o IPv6.

Figura 2.8. Visão final da topologia global da empresa.

Mas, há algumas pequenas dificuldades, a maioria delas identificadas quando toda a arquitetura (o conjunto das seis topologias) se tornou operacional. Como não eram problemas graves foi prudente esperar algum tempo para iniciar um processo de otimização e refinamento granular da arquitetura. O que foi feito estará descrito nos Capítulos 3 e 4, deste livro.

2.10 ASNs, IPv4 e IPv6 usados neste documento

O RFC5398 indica os seguintes números para identificar ASNs privativos:

64496 - 64511 e 65536 - 65551

O RFC5735 (página 5), apresenta o quadro reproduzido abaixo, os IPv4 indicados para uso específico:

Address Block       Present Use                Reference
------------------------------------------------------------------
0.0.0.0/8           "This" Network             RFC 1122, Section 3.2.1.3
10.0.0.0/8          Private-Use Networks       RFC 1918
127.0.0.0/8         Loopback                   RFC 1122, Section 3.2.1.3
169.254.0.0/16      Link Local                 RFC 3927
172.16.0.0/12       Private-Use Networks       RFC 1918
192.0.0.0/24        IETF Protocol Assignments  RFC 5736
192.0.2.0/24        TEST-NET-1                 RFC 5737
192.88.99.0/24      6to4 Relay Anycast         RFC 3068
192.168.0.0/16      Private-Use Networks       RFC 1918
198.18.0.0/15       Network Interconnect
                    Device Benchmark Testing   RFC 2544
198.51.100.0/24     TEST-NET-2                 RFC 5737
203.0.113.0/24      TEST-NET-3                 RFC 5737
224.0.0.0/4         Multicast                  RFC 3171
240.0.0.0/4         Reserved for Future Use    RFC 1112, Section 4
255.255.255.255/32  Limited Broadcast          RFC 919, Section 7
                                               RFC 922, Section 7

O RFC3849 recomenda o uso do bloco IPv6

2001:DB8::/32

em documentos. Contudo, há em andamento, no IETF um Internet-Draft (I-D) propondo disponibilizar o bloco DDDD:D000::/20, para documentação (draft-moreiras-v6ops-rfc3849bis-00.txt). Embora o I-D esteja em fase de obtenção do consenso no IETF usaremos endereçamento IPv6 retirado deste bloco.

Arbitrariamente, vamos supor que a empresa abordada possua o AS64500 e tenha recebido, associados a este ASN, do Registro.br, os blocos 10.1.0.0/20 e DDDD:D000::/32. Suponha, também, que esta empresa obteve um outro ASN (AS65536), sem nenhum bloco IPv6 ou IPv4. Para efeito didático, o conteúdo deste livro abstrai-se das restrições privativas dos números escolhidos, isto é, a noção de uso privado não será considerado, nestes casos.

Agradecimentos

Foram muitas as pessoas que me deram suporte para o desenvolvimento deste trabalho. De várias maneiras, direta e indiretamente. Isto inclui meus inúmeros clientes, velhos amigos e novos amigos. A eles, meus agradecimentos. Em particular, gostaria de nomear algumas pessoas que colocaram recursos físicos, materiais, experiências incomuns e incentivos, permitindo incondicionalmente, que a topologia pudesse ser testada e simulada de forma integral, sistemática e intensivamente, em suas diversas etapas, mesmo sem conhecimento do objetivo final. São elas, em ordem alfabética: Éder Zagui (IBL Telecom, Guaratinguetá, SP), Fabrício Mota Camargo (MutumNet, Mutum, MG), José Marconi de Almeida (Cooperabaeté, Abaeté, MG), Luciano Inácio (Jupiter Telecom, Imperatriz, MA), Luciano Rampanelli (Comodoro, MT), Marcelo Micucci (BM Promoções, Belém, PA), Marcos Paulo Fernandes (Heliodora Online, Heliodora, MG), Samyr Bechelane (Netcetera, Betim, BH).