Arquivo

Archive for the ‘PTT’ Category

Topologias, Interconexões e Protocolos

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.

capaLivro-1

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

capa

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.



 

Topologias, Interconexões e Protocolos

 

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.

 

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

 

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

 

Topologia-01
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.

 

Topologia-02
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.

 

Topologia-031

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.

 

Topologia-043

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

 

 

Topologia-052

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.

Topologia-062

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.

 

Topologia-072

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.

 

Topologia-07.12

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.

 

Topologia-Final4

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



Anúncios
Categorias:Bogon, eBGP, iBGP, IPv4, MPTCP, PTT, RPKI, TCP/IP

O DNS solidário

 

Introdução

 

Muitos são os processos que tornam a Internet um ambiente mais confortável. Confortável no sentido de segurança e, principalmente, qualidade. O DNS é um deles. Sob o ponto de vista do bem estar geral, o DNS é um dos mais importantes componentes. Servidores de DNS são gerenciados por empresas e provedores de serviço de Internet (pequenos, médios e grandes). Não é somente o sistema autônomo o pré-requisito para a existência de servidores de DNS. O pré-requisito é que a organização tenha pelo menos um domínio registrado.

Este texto está interessado em abordar a questão da qualidade do DNS sob a ótica de sua disponibilidade (com foco na topologia), e propõe um mecanismo criativo para diminuir significativamente a sua indisponibilidade, melhorando a qualidade da Internet e aumentando um pouco mais sua segurança.

Se a organização é pequena, mesmo que tenha diversos domínios, a recomendação é não pensar duas vezes e usar os servidores de DNS do Registro.br. Há duas restrições, entretanto, que impediriam o uso daqueles servidores: se o domínio tiver mais de 15 registros (digamos, subdomínios) ou se for necessário a implementação de reversos de IPv4 e/ou IPv6 (que é o caso dos sistemas autônomos). A proposta criativa está orientada para aquelas organizações que não podem usar os DNSs do Registro.br, na totalidade de suas demandas.

 

Topologia de servidores de DNS

 

A recomendação técnica mínima é que se tenha pelo menos dois servidores autoritativos de DNS: um primário e outro secundário. E, também, que haja outros servidores de DNS do tipo recursivos, disponíveis para consultas de nomes e reversos de IPv6/IPv4. Na maioria das vezes, isto não acontece. Primeiro, não é usual a disponibilidade de recursivos. Isto não representa um problema técnico se são usados recursivos disponíveis na Internet, como os do Google. O ruim, na história dos recursivos é não usar nenhum e deixar que o autoritativo aceite consultas e se torne um autoritativo-recursivo. Usar um servidor autoritativo como recursivo é possível, deste que isto seja feito através de visões, como permite o Bind. Uma visão é autoritativa e outra é recursiva. Mas, neste texto, a demanda para recursivos é abstrata, embora não se deixe de pensar que os recursivos depende de autoritativos disponíveis, para funcionarem. A preocupação é o respeito às melhores práticas, de no mínimo dois autoritativos. O uso do servidores DNS solidários permite a aplicação das melhores práticas e representar uma topologia conforme a Figura 1.

 

Topologia para um DNS Solidário

Figura 1. Topologia de um DNS Solidário.

 

Governança do DNS Solidário

 

Recorrendo à Figura 1 destaca-se:

  • A visão do Registro.br está restrita aos dois servidores à esquerda (secundário e primário). O nome primário, neste caso é dado ao servidor que irá transferir a zona para todos os outros secundários. Na realidade, o único primário (ou “master”), na acepção técnica de servidores DNS é o escondido, sobre o qual as zonas são manipuladas.
  • O dois servidores registrados no Registro.br devem estar em redes física e logicamente distintas.
  • O primário escondido pode e deve estar localizado em uma rede remota distante. Por exemplo, em uma empresa de hospedagem, preferencialmente disponível em um PTT. As facilidades de conexão aos PTTs, via transporte, devem ser consideradas, agora ou no futuro.
  • O recursivo, que pode ser mais de um (dado à sua facilidade de implementação), deve estar nas proximidades das redes solidárias.
  • O DNSSEC é um pré-requisito fundamental!

A governança do DNS Solidário deve ser no estilo “várias partes interessadas”. Em outras palavras, a governança deve ser uma organização independente, onde a administração é dada a algum membro da rede de provedores solidários, por um período de tempo pequeno e com participação efetiva de todos os envolvidos para que a estrutura/topologia estejam bem cuidada, focada no interesse comum, respeitando algumas particularidades de membros específicos. Não há necessidade de uma organização formal e a imagem que melhor se adapta é a estrutura da Internet Society (ISOC), especificamente, o IETF.

Custos serão os fatores fundamentais da organização solidária. Eventuais responsáveis não devem receber por seu trabalho. Entretanto, admite-se que o pessoal técnico seja remunerado. Níveis de dedicação variam em função da complexidade da estrutura.

Organizações solidárias, principalmente em pequenos e médios provedores tendem ao aperfeiçoamento ao criativamente evoluírem para o ASN Solidário, Trânsito e Transporte Solidários, etc. Há exemplos práticos funcionando, embora sem uma organização efetiva, o que atrai alguns problemas, principalmente, no que diz respeito à qualidade de seus serviços de infraestrutura da Internet. Outros exemplos mostram a criação de organizações formais que aumentam consideravelmente os custos e a complexidade operacional tornando-se ineficientes. O modelo atual da Governança da Internet é um exemplo imperturbável!

Meu ambiente de trabalho

Introdução

O tempo anda escasso, ultimamente. O de todo mundo, pelo que parece. Estou com dois artigos na agulha, um deles a continuação do último, sobre a conexão aos PTTs em IPv4 e IPv6. O outro é sobre um ano “quase” sabático, que me dei de presente, a partir de março de 2011. O ano “quase” sabático obrigou-me a preparar adequadamente o ambiente de trabalho. E vou descrevê-lo, por pura curiosidade, organização das idéias e reconher que, nas entrelinhas, será útil para muita gente. O bloque tem a vantagem de você escrever o que desejar para que leiam as pessoas que desejarem ler. No passado, chamávamos de “livre arbítrio”. Hoje seria mais prudente chamar de “escolha pessoal”. Geralmente, a “escolha pessoal” é baseada, EMHO, no conjunto de informações que um ser humano possui em sua cabeça, adquirida ao longo dos anos. Mas, o conjunto é complementado pela manipulação que o ser humano fez e faz, sistematicamente, do conhecimento adquirido. É uma questão um pouco mais complicada, pois vê-se, no dia-a-dia e na história, que este conjunto de conhecimento pode ser usado para o bem e para o mal.

O comentário da “escolha” aparece, a propósito de uma opinião que vi em um dos artigos do Silvio Meira onde, no debate alguém diz que uma pessoa é míope porque decide usar o Facebook. Em linhas gerais, justificou a miopia, pelo fato de que usar o Facebook está tornando mais rico o seu criador. É uma observação, a meu ver, sem propósito. Mas, trata-se de uma opinião. Não é possível preocupar-se com uma opinião (quando ela não é técnica), que você simplesmente não concorda. Minha escolha nestes casos é o da relevância. Se a opinião não técnica não for relevante ou não contribuir para o enriquecimento de minhas próximas escolhas, ignoro-a, no sentido de não participar do debate. Prefiro a visão shakesperiana: “A vida é uma simples sombra que passa (…); é uma história contada por um idiota, cheia de ruído e de furor e que nada significa”. Por outro lado, não acho que a história da miopia acima, qualifique um idiota. Pessoalmente, aperfeiçoei meu conhecimento, com a abordagem da opinião e na simples leitura. Sempre acontece, mesmo que inusitada.

Os recursos físicos

Tenho um “notebook” Dell Vostro 1320, com 8 GRam e um HD de 230 Gbytes. Localmente, tenho um “desktop” Intel Core 2 duo com 8 GRam e 2 HDs de 520 Gbytes. Remotamente, tenho uma outra máquina semelhante a este “desktop”. Para a Internet uso a Net com 10M de banda, que chega a 800 Kbps, medidos no SIMET do Nic.br. Para mim, a Net é uma provedora de serviços, no mínimo, irresponsável! Conectado à Net tenho um Mikrotik em uma máquina simples, com HD em “flash”, já há muitos anos.

No meu “notebook” tenho o Windows 7 Professional, em IPv4 e IPv6. O IPv6 é um túnel com a HE, que faço via anúncio de um /48 através do AS de minha empresa. Eventualmente, ativo uma VPN com um dos roteadores apropriados. Assim, consigo manter minhas configurações originais, onde estiver, em qualquer parte do mundo. Se não tenho Internet, mas há disponibilidade de celular, uso-a via meu iPhone. Complementarmente, tenho um “tablet” Samsung 8.1, que suporta alguns casos extremos e usado muito para leitura dos trabalhos em .pdf. Este conjunto de facilidades me satisfaz plenamente, no quesito de interconexão á Internet, que é o componente fundamental de trabalho e, via de regra, não me deixa ocioso, exceto quando for minha escolha. Fico ocioso, sempre, quando estou com meu neto querido.

As outras facilidade

Naturalmente, minhas maiores facilidades estão no “notebook”. Eis algumas delas:

  • Thunderbird: meu atual cliente de correio eletrônico. Não é meu preferido, infelizmente, mas dá para o gasto. Ele tem uma facilidade muito interessante que é o uso do PGP.
  • Browsers: Tenho quase todos, Chrome, Firefox, Explorer e Safari. Meu preferido é o Chrome. Antes era o Firefox, mas ultimamente com muitos problemas. Explorer só para alguns bancos, que não respeitam escolhas de seus clientes. Safari uso muito pouco, principalmente em testes de desenvolvimento.
  • Putty: minha principal ferramenta de ssh. É também, uma das mais importantes ferramentas de trabalho. Tenho outros, como o SCP, mas uso pouco.
  • Zope/Plone/Zeo: Uso pouco, no “notebook”. Somente para segurança de outros servidores, os quais uso muito.
  • Warftp: Insubstituível servidor de ftp. Entre outras funções ele é o principal componente de integração com o “tablet”. E, naturalmente, como integrador com os outros servidores.
  • PHPDesigner: Depois de muitos anos, há 5 uso-o preferencialmente. Está instalada, a versão 8. Não somente os programas em PHP, mas também, com editor de outras linguagens com C, Java e Perl, particularmente.
  • Wamp: Aplicação fantástica e simples, que implementa os servidores de MySQL, PHP, Apache em suas diversas versões, o que é muitíssimo útil.
  • Clientes para o MySQL: Tenho instalado o MuSQL Workbench, o MySQL Administrator e o MySQL-Front. Cada um com sua utilidade.
  • MikTex: Ferramenta preferida para os textos que preciso escrever em Latex. Ando me afastando um pouco do Latex e preferindo o Word. O Word é muito mais fácil para lidar, nos textos técnicos. O Latex é cansativo gerando muita perda de tempo na procura de compatibilidades. Mas, é insubstituível em alguns casos.
  • Office: Ótima ferramenta, pois domino-a. Além do Word sou usuário permanente do PowerPoint. Como não sou especialista em imagens, uso-o como intermediário para o aperfeiçoamento do que preciso, no Adobe Photoshop.
  • Adobe Photoshop: Para quem entende, deve ser uma maravilhosa ferramenta. Para mim resolve milhares de problemas relacionado com figuras, imagens, etc., que preciso no dia-a-dia.
  • eyeBean: Meu “softphone” preferido para testes e uso do FaleOK. Hoje tenho-o instalado no iPhone, também, e uso-o para receber e fazer chamadas via o FaleOK. Tenho números fixos em algumas cidades.
  • Wireshark: Eventualmente uso-o para avaliações e diagnósticos de problemas em redes. Pouca atividade, mas uma fantástica ferramenta, quando necessária.
  • Camtasia: Este e outros recursos estão associados a um Bamboo da Wacon, plugado em uma das USBs do “notebook”.
  • Enterprise Architect: Minha principal ferramenta de projetos e apoio ao desenvolvimento de idéias. Indescritível, os recursos disponíveis! É complexa e ao longo do tempo pode aperfeiçoar o uso.
  • FileZilla: Cliente preferido para ftp. Fica aberto o tempo todo no “notebook”.
  • Adobe Acrobat X: É um software de apoio. Usei-o muito quando meu orientador solicitou que os textos fossem feitos em Word e eu os fazia em Latex. Não entendi muito bem a razão dessa preferência já que existe hoje, o Adobe Reader X. Tal exigência, fez-me mudar em definitivo para o Word. No final, a mudança foi melhor e mais prática.
  • Skype: Há muito abandonei o MSN pelo Skype. Este é muito mais confortável e estável (pelo menos era, na época da escolha). Só uso o Skype para me comunicar com outros Skypes. Telefonia prefiro o FaleOK, muito mais flexível…
  • Segurança: Tenho vários anti-vírus e uso intensivamente o “firewall” do Windows 7.
  • VMWare: Ferramenta versátil e simples para criação de máquinas virtuais. Não fosse o VMWare não sei como poderia criar ambientes de testes, verificação de comportamento e integração (usualmente, em rede), de diferentes sistemas operacionais, tais como: Windows, Mikrotik, BSDs, Linux, etc. Cada um deles nas suas diversas versões.
  • CygWin: Ah! Grande achado! Tornou muito mais fácil lidar com o Windows, ao sair fora do “prompt”. Bem mais fácil!! Não se pode prescindir do CygWin, principalmente se você desenvolve com o apoio de “framework”, no Windows. Para se ter um exemplo, as duas figuras abaixo mostram o whois no CygWin e no Windows, respectivamente:

    Também, um recurso bastante valioso é o servidor sshd. Não tem preço!!

Finalmente, para ilustrar, eis a barra de tarefas do “notebook”:


Nos servidores local e remoto uso o FreeBSD (versão 9). Ambos possuem Apache2, MySQL5 e PHP5. Em ambos, como no “notebook” está instalado o Zope/Plone/Zeo. O Zeo admite perfeita integração entre os três, o que me deixa despreocupado em relação à segurança dos dados. No Plone local, mantenho toda e qualquer documentação de todos os servidores sob minha responsabilidade. Incluo todos os trabalhos em .pdf que mantenho em minha bibliografia no Word. Senhas (codificadas), IPs, v4 e v6 (uso a flecha para documentar), informações pessoais, agenda, etc., etc. O Plone é algo, também indescritível. Uso o Zope desde que ele apareceu pela primeira vez.

O servidor remoto tem um DNS escondido (Bind), que é “master” para um “master”, de um conjunto de outros servidores de dominio (autoritativos). Como recursivo, uso o Unbound no servidor local e em um outro servidor remoto.

Conclusão

O “notebook” tem suportado com altivez a demanda sobre ele. É claro que 16 GRam, no mínimo, com um processado I5 ou I7 seria o desejável. É o que provavelmente acontecerá em breve, espero. De resto estou muito feliz com meu ambiente, cuja foto parcial do local, segue abaixo!


BGP: topologias, abstrações, eBGP e iBGP (Parte 1)

Introdução

Este artigo tem o propósito de evoluir o entendimento do BGP, que se está procurando dar, ao longo dos artigos anteriores. Neles a abordagem foi dada sobre o Mikrotik, um roteador (entre outras funções) simples e versátil de lidar. De agora em diante será rompida a forte vinculação única e, abandonaremos, também, o FFE, para ampliarmos a complexidade do BGP em abordagens mais práticas, do dia-a-dia.

Finalmente iremos apreciar o iBGP, componente inseparável do BGP. O outro componente inseparável é o eBGP. A completude do BGP exige ênfase na topologia, como iremos verificar. Desenhar a topologia adequada para o planejamento do BGP é uma questão fundamental, pois deve-se perseguir a simplicidade das representações para contornar a sua complexidade, como um todo.

A topologia, que na prática apresenta-se em formas semelhantes, mas dificilmente idênticas tem sido relegada a um plano secundário, já que a tendência é evitar projetos ou planejamentos em redes, que demandam imenso esforços, mas extremamente importantes para bons resultados na implementação de um BGP. Geralmente, a partir do instante em que o BGP se comporta de forma aceitável é comum deixar de lado as preocupações com sua otimização sob o ponto de vista da eficiência. No Brasil, aparentemente, tem-se uma curiosa tendência em permitir que as grandes operadoras façam o que bem entenderem em relação à topologia, facilitando seus interesses e não os de seus clientes, e até mesmo, os interesses da própria Internet. É um cenário abusivo, monopolista, oligopolista e, pior, um cenário de oportunistas a soldo de interesses pessoais, de grupos muito bem articulados e econômicos predatórios. Tais questões, por demais importantes serão tratadas em outro momento.

Um autor será muito referenciado, inclusive nas entrelinhas: John W. Stewart III, ou simplesmente, John Stewart. Ele escreveu o imperdível, fascinante e único romance sobre o BGP41, disponível para leitura contínua e de cabeceira. Mas, nossa bíblia continuará sendo a RFC42712. Em um sentido mais amplo, completo e detalhado, nada como o livro de Radia Perlman7 que exibe sua intensa experiência. Mais recente, atualizado e imperdível é o livro de Russ White e outros9. Uma referência prática e específica é o artigo de Caesar e Rexford6 que propõem dicas importantes para quem precisa trabalhar, de forma sistemática, com políticas de roteamento, principais preocupações dos administradores de BGP. Finalmente, não se pode esquecer que o BGP é constantemente ampliado e atualizado pelas RFCs.

Uma topologia para o debate

A Figura 1, abaixo, exibe uma topologia para iniciar o debate. São três pontos independentes de conexão estática à Internet, uma interconexão ao PTT-Belém, três pontos de empareamento em túneis IPv6 com um mesmo operador de trânsito e dois empareamentos (IPv4 e IPv6), com o Team-Cymru, para recebimento dos “bogons” (Belém).

 

Figura 1. Visão inicial da topologia.

 

As observações que nos interessam sobre a Figura 5, são:

  1. Tudo está funcionando a contento.
  2. Embora não mostrada na Figura 1 há uma VPN entre Guará e SJCampos.
  3. Há três túneis 6to4, com a Hurricane Eletric, para o mesmo AS6939 (Belém, Guará e SJCampos).
  4. Face a independência das conexões seria necessário o empareamento com o Team Cymru, também, em Guará, onde terá BGP.

Talvez refinando um pouco mais a topologia da Figura 1, com base nas observações de 1 a 4, acima, algo mais virá a tona. Por exemplo, a representação da Internet está fora do lugar, na Figura 1.

 

Figura 2. Refinando a topologia da Figura 1.

 

Figura 2 exige outras observações, mais detalhadas:

  1. As setas em vermelho, representam empareamentos BGP. Neste caso temos eBGP pois as conexões são entre Sistemas Autõnomos com ASNs diferentes. Em outras palavras, eBGP é um protocolo EGP5. O eBGP é um dos dois principais componentes do BGP. O outro é o iBGP, que é um protocolo do tipo IGP5. O iBGP é usado para as interconexões entre roteadores de um mesmo AS e, existem diversos protocolos que exercem funções equivalentes ao iBGP (RIP, OSPF, etc.).
  2. As setas pretas são interconexões de trânsito.
  3. A conexão de trânsito em Belém é estática. Será transformada para um trânsito em BGP quando houver outro trânsito através do PTT, em acordo bilateral com um fornecedor de trânsito, claro, também, no PTT. Na oportunidade de implementação de um trânsito “multihoming”, já espera-se que a tabela de roteamento seja do tipo “full routing”.
  4. O trânsito em Guará é estático, também. Brevemente será dinâmica, via BGP, com um único operador.
  5. Embora não mostrada na Figura 1 há uma VPN entre Guará e SJCampos.
  6. Há três túneis 6to4, com a Hurricane Eletric (AS6939): Belém, Guará e SJCampos.
  7. Face a independência das conexões seria necessário empareamento com o Team Cymru, também, em Guará, onde terá BGP. O empareamento com o Team Cymru é somente em uma direção (unicamente para recebimento das tabelas de bogon (IPv4 e IPv6).
  8. Embora a figura apresente somente uma Internet é bom lembrar que são duas: IPv4 e IPv6.
  9. Seria interessante empareamento BGP em SJCampos, mas há um impedimento comercial, pois a conexão com a Internet é uma aDSL. BGP (isto é, eBGP), entre ASes, tipicamente exige conectividade física. Não que interconexões assíncronas impeçam o eBGP.

Procurando uma topologia sem os detalhes irrelevantes

Na Figura 3, mostramos uma topologia idêntica à da Figura 2, mas totalmente abstrata, sem mostrar as questões irrelevantes, tais como, IPs, ASNs, formas de conectividade, localidades, anúncios, etc.

 

Figura 3. Topologia abstrata da Figura 2.

 

Veremos que pensar/planejar em uma topologia abstrata ficará mais fácil. Podemos melhorar mais ainda se pensarmos que as respectivas conexões de R!, R2 e R3, com os roteadores externos ao domínio local, RA, RB, …, RG são todas via BGP, isto é, eBGP. Portanto, a Figura 4 torna mais simples e adequada a topologia na qual iremos trabalhar. Realmente, em uma implementação de BGP, na qual esperamos anunciar nossos IPs e receber anúncios de vizinhos, tanto faz pensar em uma única implementação ou em várias. Na primeira implementação de um BGP sabemos que tratamentos diferenciados com vizinhos distintos, serão feitos através de filtros. Recursos mais elaborados serão feitos através de políticas de roteamento mais sofisticadas. Filtros fazem parte da política de roteamento, mas não são suficientes para outros tratamentos, eventualmente necessários, que não seriam atendidos pela política do melhor caminho (“shortest-path policy”), inerente ao BGP.

 

Figura 4. Topologia com a abstração máxima.

 

A topologia da Figura 4 é nossa melhor representação, sem dúvida. Mas, existem questões didáticas que remete-nos à Figura 5, para lembar que cada roteador do Domínio Local (DL) possui sua própria rede local (basta ver nossa topologia original, da Figura 2, representadas pelas localidades. Na oportunidade vale lembrar que cada um dos roteadores externos e vizinhos dos roteadores DL, possui seus respectivos domínios, sobre os quais o administrador do DL não consegue interferir diretamente.

 

Figura 5. Topologia sob efeito didático: as redes de cada Ri (i=1, 2 e 3).

 

Tipicamente, o DL possui diversos roteadores internos, em cada rede. Tais roteadores estão interconectados, a partir do roteador Ri. Cada um destes roteadores internos, constroem sua própria rede, muito embora alguns roteadores possam ser transformados em “bridge”. Mas, “bridge” não é um roteador! Então não estamos interessados nelas, nesta etapa de entendimento sobre o BGP. Portanto, a força da didática nos induz a um aperfeiçoamento, mostrado na Figura 5, e na Figura 6, onde estão representados os inúmeros roteadores de cada rede local. Inúmeros é força de expressão, pois por razões práticas representaremos uns poucos, para depois representarmos somente um.

 

Figura 6. Topologia sob efeito didático: os roteadores, Rij (i=1, 2,… 3; j=1, 2, …, n), de cada Ri.

 

Há detalhes irrelevantes na Figura 6. Por exemplo, a representação das redes internas a cada Ri e a especificação dos domínios dos vizinhos. A Figura 7, que segue, abstrai-se de tais detalhes, pois intuitivamente induz-nos a imaginar as redes locais de cada Ri e, também, as redes locais dos Rij.

 

Figura 7. Topologia sem os detalhes irrelevantes da topologia da Figura 6.

 

Neste ponto, fixaremos na Figura 7 e passaremos a entender sobre os protocolos EGPs e IGPs.

Protocolos EGPs e IGPs.

eBGP é um protocolo EGP (“Exterior Gateway Protocol”). iBGP é um protocolo IGP (“Interior Gateway Protocol). O mais famoso protocolo do tipo EGP é o BGP4. Existem outros, como o BGP (versão anterior do BGP4, às vezes chamado de BGP3), o GGP (“Gateway to Gateway Protocol”), o protocolo Hello, o protocolo EGP (conflitando com o nome do tipo EGP). Já os protocolos do tipo IGP são vários: RIP (“Routing Information Protocol”), OSPF (“Open Shortest Path First”), IS-IS (“Intermediate System do Intermediate System”), IGPR e EIGPR. Estes dois últimos são protocolos proprietários da Cisco. O RIP é muito usado em pequenas redes com topologia não complexas. Esta lembrança sobre o RIP se deve ao fato de ser um dos protocolos muito usados no mundo inteiro e para lembrar que topologia exerce uma influência muito grande na escolha do protocolo. Por outro lado, percebe-se que o RIP é pouco usado no Brasil, onde se dá preferência ao OSPF, independente da topologia ser simples ou não. O BGP tem seu próprio IGP, como já sabemos: o iBGP.

Ao escolher um protocolo, a preocupação está na capacidade de que um ponto da rede possa alcançar qualquer outro ponto (interno ou externo), e vice-versa. Esta é a propriedade da atingibilidade, do inglês “reachability”. Neste ponto, vale lembrar que Sistema Autônomo (AS) exerce um efeito significativo, principalmente quando lembramos o que diz Stewart1, na página 18: “… um AS é uma coleção de roteadores e não uma coleção de prefixos IPs”. Stewart1 diz isto para esclarecer que o objetivo de um protocolo EGP é o de permitir que dois diferentes ASes possam trocar informações de roteamento de tal forma que tráfego de dados possa atravessar entre eles, em ambas as direções. Para que tal tráfego seja eficaz, em todos os sentidos, um protocolo EGP deve incluir mecanismos que permitam os administradores de ambos os ASes definir suas regras de comportamento do tráfego, independentemente, já que ambos estão em domínios administrativo e técnicos diferentes, que em tese, mal se conhecem. Tais mecanismos são o que conhecemos como política de roteamento. Filtros do BGP (eBGP!) fazem parte da política de roteamento quando, decidimos quais prefixos podem ser anunciados ou não. Um bom exemplo, que amplia esta noção de política de roteamento para além dos filtros (mas com a ajuda deles) é a opção de empareamento com o Team Cymru para garantir a prática desejável de não transferir “bogons” para os vizinhos do empareamento BGP.

Neste momento, podemos identificar algumas questões que devem ser resolvidas e outras observações que podem influenciar nosso planejamento:

  • A atingibilidade entre os roteadores, R1i, R2j e R3k, só acontecem via Internet (IPv4 e IPv6).
  • A atingibilidade de R14, por exemplo, só é possível com rotas estáticas. Sem um protocolo dinâmico, o trabalho pode ser muito grande. Imagine um ambiente interno com mais de 50 roteadores, como é o caso de Belém.
  • Considerando o DL com 3 pontos de presença separados, a redundância só pode ser conseguida em cada ponto. É possível alterar tal condição? Sob o ponto de vista econômico/financeiro como deve ser tratada tal questão? Aqui entrará um outro componente competindo com a topologia: o componente econômico. Caesar e Rexford6 chamam o componente econômico de relações de negócios, como uma das quatro outras políticas que um administrador de AS deve considerar: escalabilidade, engenharia de tráfego e segurança. Na política relações de negócios eles incluem as relações políticas, além das econômicas. Na política de engenharia de tráfego incluem as necessidades de controle do fluxo de tráfego e preocupações relacionadas com congestionamento e qualidade de serviços, tanto internamente quanto externamente. Na política de escalabilidade, as preocupações estão ligadas à redução do controle do tráfego e eliminação de sobrecarga dos roteadores. Finalmente, a política de segurança, relaciona-se com as proteções contra ataques maliciosos ou acidentais.
  • Podemos pensar em “manutenção móvel” com roteadores móveis? Por exemplo, um roteador em uma VM de um notebook, digamos, openBSD.

O principal dilema, para seguir as preocupações acima é identificar o melhor protocolo do tipo IGP a ser usado na topologia da Figura 7. Em seguida, entender, profundamente, o escolhido. É claro que a escolha recai sobre o iBGP. Mas, porque? Para responder a esta pergunta, precisamos ir um pouco além do que sabemos atualmente sobre protocolos (na realidade só conhecemos um pouco do BGP). Ir um pouco além significa abordar:

  • A diferença entre EGP e IGP.
  • O que se sabe e não se sabe, até agora, sobre o BGP.

Diferenças entre EGP e IGP


Protocolo é uma palavra que referencia múltiplas atividades em uma rede. Por exemplo, protocolo IP é um protocolo que trata do formato de informações que são encaminhadas de um ponto de origem até um ponto de destino de uma rede que trabalha sob as características do protocolo TCP/IP. Protocolo TCP/IP é a designação genérica de um conjunto de atividades que são manipuladas em uma instância do modelo de camadas que conhecemos como OSI. A literatura, às vezes, chama o protocolo IP, que estamos usando como exemplo, de protocolo roteado (“routed protocol”). Já o BGP é um protocolo de roteamento, ou mais formalmente, um protocolo que implementa um algoritmo de roteamento. Protocolos, como o BGP, que implementam um algoritmo de roteamento são reconhecidos protocolos de roteamento dinâmicos, em contraste com os protocolos de roteamento estáticos, onde o ser humano é o agente de sua implementação, isto é, as rotas são implementadas manualmente, nos roteadores.

Há, infelizmente, uma outra confusão na literatura sobre o BGP ser ou não um protocolo dinâmico. Alguns dizem que ele não é dinâmico, nem estático (!?). Outros dizem, como Perlman7, que ele é um protocolo estático. Mais à frente, quando falarmos sobre o BGP, o contexto irá indicar-nos onde ele se insere.

Os protocolos dinâmicos (exceto o BGP…), são implementados usando um dos dois tipos de algoritmos: distance vector e link state. A análise de tais algoritmos nos dará base para a escolha de nosso protocolo inter-domínio. Não iremos entrar em muitos detalhes sobre eles, exceto o necessário para nossas decisões, mas estão muito bem descritos em Perlman7.

Roteamento do tipo “distance vector”

O algoritmo “distance vector” (DV), conhecido também como algoritmo de Bellman-Ford exige que cada nó (ou roteador) da rede envie para seus vizinhos, parte ou toda a informação de sua tabela de roteamento. Para ver seu funcionamento usaremos a rede formada pelo roteador R1, da Figura 7, sobre a qual incluímos uma identificação do enlace (caminho), em vermelho, para efeito didática.

 

Figura 8. Modelo para explicar os tipos de algoritmos.

 

A tabela de roteamento de cada roteador, no início, contem as informações relacionadas com os anúncios que ele deve informar para seus vizinhos, com o único objetivo de que os vizinhos possam atingir toda sua rede. Para entendermos o funcionamento do DV, eis os prefixos de cada um dos 5 roteadores presentes na rede:

R1 abcd:efgh:1::/48
R11 abcd:efgh:11::/48
R12 abcd:efgh:12::/48
R13 abcd:efgh:13::/48
R14 abcd:efgh:14::/48

No início, quando todos os 5 roteadores forem simultaneamente ligados e o algoritmo começar a funcionar (operação conhecida como “cold start” => partida fria), cada um deles terá uma tabela de roteamento construída pelas seguintes informações: para quem anuncia, o quê anuncia, qual o caminho e a distância para atingir (custo), a partir do caminho indicado. Abaixo, eis a imagem de cada tabela de roteamento quando da partida fria, à qual inserimos uma indicação do momento em que isto ocorreu (T). Quando T = 1, o item da tabela foi criado na partida fria. Também, por razões didáticas será acrescentada uma coluna de observações para facilitar o entendimento do algoritmo:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0  
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0  
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  

Cada tabela acima está informando ao seu respectivo roteador, para onde ele deve seguir quando desejar alcançar (atingir), sua própria rede e quanto isto irá custar. O quanto irá custar é o resultado mais importante do algoritmo e recebe o nome do próprio algoritmo: vetor de distância, isto é, “distance vector”.

O próximo passo é cada roteador informar para seus vizinhos o conteúdo de toda sua tabela de roteamento. Por exemplo, o R1 informará para seu único vizinho, R11, o conjunto (R1;abcd:efgh:1::/48;local;0). O R11 irá então instalar em sua tabela de roteamento esta informação de R1 e, consequentemente, aumentará seu conhecimento de atingibilidade, dentro da rede. E assim o nosso T=2 ficará da seguinte forma:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 3 1 Recebida de R11. Criada em T=1.
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0 Criado na partida fria
    2 R1 abcd:efgh:1::/48 1 1 Recebida de R1. Criada em T=1.
    2 R13 abcd:efgh:13::/48 2 1 Recebida de R13. Criada em T=1.
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0 Criada na partida fria.
    2 R13 abcd:efgh:13::/48 4 1 Recebida de R13. Criada em T=1.
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0 Criada na partida fria.
    2 R12 abcd:efgh:12::/48 4 1 Recebida de R12. Criada em T=1.
    2 R11 abcd:efgh:11::/48 2 1 Recebida de R11. Criada em T=1.
    2 R14 abcd:efgh:14::/48 3 1 Recebida de R14. Criada em T=1.
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0 Criada na partida fria.
    2 R13 abcd:efgh:13::/48 3 1 Recebida de R13. Criada em T=1.

Embora o processo de mensagens de um roteador para seus vizinhos esteja sempre acontecendo nossa visão passo a passo observa que a tabela de R11 tem algumas entradas que ocorreram no T=2 que não estão em R1 (a informação sobre o anúncio de R13). O mesmo se pode dizer de R11 em relação a R13 (a entrada de R1) e assim por diante. O algoritmo envia todos os componentes de uma tabela de roteamento. Ao receber a tabela inteira, ele verifica se já existe alguma entrada e se houver, compara o custo com a existente. Se o custo for igual ou maior ignora a entrada. Se for menor, substitui a entrada anterior por esta. Vamos ao passo T=3 e ver o estado de cada tabela, a seguir:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 1 1  
    3 R13 abcd:efgh:13::/48 1 2 Recebida de R11 (T=2).
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0  
    2 R1 abcd:efgh:1::/48 1 1  
    2 R13 abcd:efgh:13::/48 2 1  
    3 R12 abcd:efgh:12::/48 2 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:13::/48 2 2 Recebida de R13 (T=2)
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
    2 R13 abcd:efgh:13::/48 4 1  
    3 R11 abcd:efgh:11::/48 4 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:14::/48 4 2 Recebida de R13 (T=2)
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0  
    2 R12 abcd:efgh:12::/48 4 1  
    2 R11 abcd:efgh:11::/48 2 1  
    2 R14 abcd:efgh:14::/48 3 1  
    3 R1 abcd:efgh:1::/48 2 2 Recebida de R11 (T=2)
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  
    2 R13 abcd:efgh:13::/48 3 1  
    3 R12 abcd:efgh:12::/48 3 2 Recebida de R13 (T=2)
    3 R11 abcd:efgh:11::/48 3 2 Recebida de R13 (T=2)

Vamos ao passo 4. Se nesse ponto houver dúvida sobre o que o algoritmo decide quando recebe uma entrada com um “Para” igual ao destino, basta lembar que na partida fria ele recebe o DV com valor do custo zero.

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 1 1  
    3 R13 abcd:efgh:13::/48 1 2 Recebida de R11 (T=2).
    4 R12 abcd:efgh:12::/48 1 3 Recebida de R11 (T=3).
    4 R14 abcd:efgh:14::/48 1 3 Recebida de R11 (T=3).
  • Tabela do R11: Sem alteração!
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
    2 R13 abcd:efgh:13::/48 4 1  
    3 R11 abcd:efgh:11::/48 4 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:14::/48 4 2 Recebida de R13 (T=2)
    3 R1 abcd:efgh:1::/48 4 3 Recebida de R13 (T=3)
  • Tabela do R13: Sem alteração!
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  
    2 R13 abcd:efgh:13::/48 3 1  
    3 R12 abcd:efgh:12::/48 3 2 Recebida de R13 (T=2)
    3 R11 abcd:efgh:11::/48 3 2 Recebida de R13 (T=2)
    3 R1 abcd:efgh:1::/48 3 3 Recebida de R13 (T=3)

A tabela de roteamento de cada roteador está completa. É possível perceber que cada roteador tem, em sua tabela de roteamento a imagem de toda a rede da Figura 8. Logo, os anúncios recebidos dos nodos vizinhos garante a visibilidade completa da rede, o que garante uma conectividade completa (ou total), pois consegue-se atingir qualquer um dos IPs anunciados. Uma outra conclusão a ser tirada é de que o algoritmo DV é fácil de entender e implementar. Por outro lado, tabelas de roteamento são trocadas entre os nós, de tempos em tempos, e retransmitidas em intervalos regulares. Dependendo do número de roteadores da rede, os protocolos que implementam o algoritmo DV pode nos trazer sérios problemas. Tais problemas são derivados de uma particularidade no algoritmo chamada de contagem até o infinito, do inglês, “counting to infinity”. Para entender, retornemos à Figura 8, imaginando que a houve um rompimento no enlace entre R14 e R13, como pode ser visto na Figura 9, abaixo:

 

Figura 9. Rompimento de um enlace da topologia.

 

Os roteadores R13 e R14 irão detectar o rompimento do caminho 3, quase que imediatamente. Então eles irão alterar suas respectivas tabelas de roteamento, informando que o custo de tudo aquilo que referencia o caminho afetado (3) terá um custo “infinito”. Vejamos as duas tabelas após o rompimento (agora sem as colunas T e Observações.

  • Tabela do R13 após o rompimento:
    Para O quê Caminho Custo
    R13 abcd:efgh:13::/48 local 0
    R12 abcd:efgh:12::/48 4 1
    R11 abcd:efgh:11::/48 2 1
    R14 abcd:efgh:14::/48 3 infinito
    R1 abcd:efgh:1::/48 2 2
  • Tabela do R14 após o rompimento:
    Para O quê Caminho Custo
    R14 abcd:efgh:14::/48 local 0
    R13 abcd:efgh:13::/48 3 infinito
    R12 abcd:efgh:12::/48 3 infinito
    R11 abcd:efgh:11::/48 3 2
    R1 abcd:efgh:1::/48 3 infinito

Mas, os roteadores R12, R11 e R1 não conseguem enxergar tal rompimento imediatamente, e consequentemente não sabem que o R14 está isolado. Eles dependem de uma atualização do R13. Suponha que R12 ainda não tenha sido atualizado por R13. Então, a tabela de roteamento de R12 continua a mesma, isto é:

  • Tabela do R12, ainda sem conhecimento do rompimento:
    Para O quê Caminho Custo
    R12 abcd:efgh:12::/48 local 0
    R13 abcd:efgh:13::/48 4 1
    R11 abcd:efgh:11::/48 4 2
    R14 abcd:efgh:14::/48 4 2
    R1 abcd:efgh:1::/48 4 3

O procedimento de atualização das tabelas é automático e não sabemos o momento e quais vizinhos são notificados por quem. Vamos então, supor que R12 encaminhe sua tabela para R13. Ao recebê-la, R13 verifica que o seu registro atual do anuncio de R14 está com o valor infinito (ou maior do que o registro de R12, para R14). Então, ele troca o registro de R14 pelo que R12 enviou. A nova tabela de R13 fica assim:

  • Tabela do R13 após o rompimento:
    Para O quê Caminho Custo
    R13 abcd:efgh:13::/48 local 0
    R12 abcd:efgh:12::/48 4 1
    R11 abcd:efgh:11::/48 2 1
    R14 abcd:efgh:14::/48 3 infinito
    R1 abcd:efgh:1::/48 4 3

Com este arranjo na tabela de roteamento de R13, teremos os seguintes cenários:

  • Qualquer pacote, vindo de fora, com destino final R14 passará por R13. R13 o encaminhará para R12. R12 devolve-o para R13, que por sua vez envia de volta a R12 e assim por diante, até que o tempo de vida (“TTL”) do pacote expire. Qualquer pacote tem um TTL, mas quem decide sobre ele é outro protocolo. Este efeito saltitante, do pacote formando “loop” é denominado “bouncing effect”.
  • Se R13 enviar uma atualização de tabela para R11, a entrada para R14 nunca será alterada, pois o custo atual de R14 na tabela de R11 é menor. Logo, qualquer pacote vindo de fora, na direção de R14 passará por R13.
  • As atualizações de tabelas de roteamento provocadas por R12 e R13, sempre irão aumentar, rapidamente, na direção do infinito. Este efeito é denominado contagem até o infinito, ou “counting to infinity”.

Este cenário, muito conhecido, fez com que as implementações do algoritmo DV incorporassem técnicas para responderem tanto ao efeito saltitante quanto o efeito da contagem para o infinito. O RIP, que implementa o DV, possui tais técnicas, que fogem de nosso propósito. Em redes internas pequenas, o RIP funciona muito bem. Em grandes redes (muitos roteadores), certamente haverá queda sensível na eficiência do tráfego, se o algoritmo DV for usado. O dilema, então está construído: fácil de entender, mas restrito em cenários de falha. Em redes redundantes, entretanto, ele se mostra uma bela alternativa.

Conclusão

Protocolos que implementam o algoritmo distance vector, não estão nos nossos planos para a topologia da Figura 7. Portanto, precisamos analisar o algoritmo link state. Um protocolo muito usado que implementa esse algoritmo é o OSPF.

Após tal análise é necessário justificar a escolha do iBGP. Para implementá-lo deve-se ampliar o conhecimento sobre ele. Em particular há duas questões importantes no BGP que devem ser apreciadas: route reflection e confederações.

Feito isto estaremos prontos para o conhecimento prático do iBGP, que é sua implementação. Estas questões serão motivos para os próximos documentos aqui do blogue.

 

Referências

  1. John W. Stewart III. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley.
  2. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).

  3. RFC6286, Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen, J. Yuan [ June 2011 ] (TXT = 7497) (Updates RFC4271) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  4. Xiaoliang Zhao , Beichuan Zhang , Dan Massey , Lixia Zhang, A Study on BGP AS Path Characteristics. Disponível em: http://www.cs.colostate.edu/~massey/pubs/tr/massey_usctr04-818.pdf. Acessado em 10/03/2011.

  5. Braga, J. (2008). Glossário da Infraestrutura da Internet. Disponível em: https://juliaobraga.wordpress.com/2008/12/01/glossario/. Acessado em 05/11/2011.

  6. Caesar, M., & Rexford, J. (21 de novembro de 2005). BGP routing policies in ISP networks. Acesso em 25 de novembro de 2011, disponível em Princenton University: http://www.cs.princeton.edu/~jrex/papers/policies.pdf

  7. Perlman, R. (1999). Interconnection: bridges, routers, switches and internetworking protocols (2a. ed.). Addison-Wesley.
  8. RFC4456,BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates, E. Chen, R. Chandra [ April 2006 ] (TXT = 23209) (Obsoletes RFC2796, RFC1966) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  9. Russ White, D. M. (2005). Practical BGP. Boston, MA, USA: Pearson Education, Inc.
Categorias:BGP, Bogon, eBGP, iBGP, IPv4, IPv6, PTT, TCP/IP

Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)


Todos os infortúnios que vivi me tornaram um homem mais forte,
me ensinaram lições importantes. Aprendi a tolerar os medíocres;
afinal, Deus deve amá-los, porque fez vários deles.

ABRAHAM LINCOLN
16o presidente norte-americano
Prefácio Póstumo
Em “Oportunidades Disfarçadas”, Carlos Domingos.
Editora Sextante 2009

Introdução

O objetivo deste artigo é apresentar a experiência de conexão a um PTT (PTT Belém), através de um Mikrotik incluindo as preocupações, cuidados e o necessário planejamento para que isto seja feito.

Uma ótima referência para o que será dito aqui está em [1].

Planejamento

Os recursos e facilidades envolvidos na conexão e no entorno do PTT Belém são:

  1. Estado inicial.
  2. Conexão ao PTT, propriamente dita.
  3. Rede local, anúncios IPv4 e IPv6 para o PTT e empareados.
  4. Filtros
  5. Trânsito IPv4 via o PTT, em acordo bilateral com o fornecedor do trânsito.
  6. Trânsito IPv6 via Tunnel Broker
  7. Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.
  8. Outras providências

O cenário fica mais claro com a Figura 1, com os comentários a seguir.

 

Figura 1. Cenário existente e projetado, no entorno do PTT Belém.

 

O comentários sobre a Figura 1 são:

  • Está sendo usada uma RB750 com versão 5.7 do Mikrotik. Há um trânsito (considerado como temporário) através da FAEPA. A Tabela 1 exibe o plano das 5 interfaces da RB750 e antecipa as VLANs que serão necessárias para os respectivos empareamentos IPv4 e IPv6. Também, a VLAN de trânsito com a FAEPA através do PTT, que irá substituir o trânsito estático através da interface 1, por um trânsito BGP.

     

    # Nome Tipo
    1 E1-FaepaTemp Ethernet1
    2 E2-PTTBelem Ethernet2
    3 E3-Disponivel Ethernet3
    4 E4-Disponivel4 Ethernet
    5 E5-Disponivel Ethernet5
    6 VLAN-PTTIPv4 VLAN
    7 VLAN-PTTIPv6 VLAN
    8 VLAN-TransitoIPv4-FAEPA VLAN
    9 HE Túnel 6to4

    Tabela 1. Interfaces atuais e projetadas.

  • Sabe-se que o administrador do PTT (aPTT) exigirá VLANs para a conexão no “switch” do PIX. Uma para cada protocolo (IPv4 e IPv6), para as quais ele informará o respectivo ID. Criamos as VLANs (#6 e #7, Tabela 1), na espera do ID. O aPTT irá nos enviar um ID inicial, para cada VLAN, que corresponderá ao período de quarentena (que pode durar até uns 10 dias, aproximadamente). Passado a quarentena e eventuais ajustes de interconexão, o aPTT nos enviará os IDs definitivos. Após a implementação definitiva solicitaremos ao aPTT o ID da VLAN de trânsito via o PTT Belém, tudo com conhecimento do parceiro de trânsito. O cenário com as duas VLANs iniciais pode ser visto conforme a Figura 2 abaixo.

     

    Figura 2. Cenário com as VLANs IPv4 e IPv6.

     

    Importante lembrar que as VLANs são possíveis porque a conexão do Mikrotik está, diretamente, com o “switch” do PIX, em L2 (muitas vezes vê-se, sem sucesso, tentativas usar VLANs em conexões não Ethernet). Na Figura 2, acima, as duas VLANs estão definidas sob a interface 2 do Mikrotik. Também, não se pode esquecer que o Mikrotik estabelece as VLANs em modo transparente (recomendado pelo aPTT). A Figura 3, abaixo, mostra a presença da VLAN para trânsito, criada sob a VLAN IPv4 (Q-in-Q). Neste momento, não estamos seguros se há ou não restrições nesta forma, e portanto, o melhor é confirmar com o aPTT.

     

    Figura 3. VLAN para trânsito via PTT.

     

  • A interface 2 da RB está conectada, como já foi dito, diretamente à porta do “switch” do PIX Faepa. Esta conexão é local, pois nossos servidores estão hospedados no centro de dados da Faepa. No mesmo centro de dados está localizado o PIX Central do PTT Belém. O material do José Eduardo, em [1] permite extrapolar a visão da topologia do PTT Belém.

Estado inicial

A Figura 4, na sequência, exibe o estado inicial da nossa topologia. O Mikrotik já foi configurado de acordo com a Tabela 1.

 

Figura 4. Configuração inicial.

 

O tráfego de trânsito será mantido por algum tempo, mesmo depois da interconexão com o PTT Belém.

Conexão ao PTT

As informações iniciais para conexão em um PTT está em http://sp.ptt.br/adesao.html. Mesmo que o PTT Metro escolhido ainda não esteja divulgado, mas sabe-se que está em fase final.

Dai para frente, siga a sequência das mensagens, e sempre que surgir alguma dúvida, não se acanhe a perguntar ao aPTT. Embora seja perceptível um alto grau de ocupação do pessoal do PTT, já usei o INOC-BR. Por outro lado, se já sabe o caminho das pedras, prepare-se do lado de cá. Já estabeleci um empareamento com o PTT-SP em menos de 5 dias. O PTT Belém, na oportunidade, em construção, levou uns 30 dias ou mais. Como já sabia, não tive pressa.

Rede local, mecanismos de acesso remoto e respectivos anúncios IPv4 e IPv6 para o PTT e empareados.

Para o Belém, o empareamento com a HE via “tunnel broker” levou menos de 15 minutos, pois já havia outro estabelecido. A HE permite até 5 túneis, a princípio. Anunciamos um /48.

O anúncio do IPv4 foi de um /23, pois haviam outros pontos de presença de nossa empresa. Para o PTT Belém o /23 foi dividido em dois /24 e para o trânsito externo (fora do PTT) será anunciado o /23. O trânsito externo é trânsito redundante, simplesmente. Foi incluída, nesta fase, uma interface de “loopback” IPv6, para túneis a serem construídos em futuro próximo. A seguir, as interfaces até o momento disponíveis:

Flags: D - dynamic, X - disabled, R - running, S - slave 
 #     NAME                    TYPE               MTU L2MTU  MAX-L2MTU
 0  R  E1-FaepaTemp            ether             1500  1526       1526
 1  R  E2-PTTBelem             ether             1500  1524       1524
 2     E3-Disponivel           ether             1500  1524       1524
 3     E4-Disponivel           ether             1500  1524       1524
 4     E5-Disponivel           ether             1500  1524       1524
 5  R  VLAN-PTTIPv4            vlan              1500  1520
 6  R  VLAN-PTTIPv6            vlan              1500  1520
 7  R  VLAN-TransitoIPv4-FAEPA vlan              1500  1516
 8  R  ;;; Hurricane Electric IPv6 Tunnel Broker
       HE                     sit               1280
 9  R  Loopback-IPv6-Interno  bridge            1500 65535

A interface de “loopback” em IPv6 pode ser construida, no Mikrotik, de várias maneiras. A recomendável é apresentada logo abaixo, onde o MAC administrativo utilizado foi: 01:01:01:01:01:01, pois a “loopback” exige-o. Se precisar de outro, usa-se os MACs do tipo: 02:02:02:02:02:02 e assim, sucessivamente.

/interface bridge add name=Loopback-IPv6-Interno auto-mac=no admin-mac=01:00:00:00:01:00
/ipv6 address add address=abcd:efgh::1/64 advertise=no interface=Loopback-IPv6-Interno

Percebe-se que do /48 anunciado separamos um /64 somente para “loopbacks”.

Filtros

Eis a listagem dos filtros, até o momento:

[admin@Belem] > routing filter print detail 
Flags: X - disabled 
 0   ;;; Route Server 1 IPv4
     chain=RS1-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 1   chain=RS1-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 2   chain=RS1-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 3   chain=RS1-PTT-IPv4_out invert-match=no action=discard 
 4   ;;; Route Server 2 IPv4
     chain=RS2-PTT-IPv4_in prefix=0.0.0.0/0 invert-match=no action=discard 
 5   chain=RS2-PTT-IPv4_out prefix=abc.def.0.0/24 invert-match=no action=accept 
 6   chain=RS2-PTT-IPv4_out prefix=abc.def.1.0/24 invert-match=no action=accept 
 7   chain=RS2-PTT-IPv4_out invert-match=no action=discard 
 8   ;;; Route Server 1 IPv6
     chain=RS1-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
 9   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
10   chain=RS1-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
11   chain=RS1-PTT-IPv6_out invert-match=no action=discard 
12   ;;; Route Server 2 IPv6
     chain=RS2-PTT-IPv6_in prefix=::/0 invert-match=no action=discard 
13   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1::/49 invert-match=no action=accept 
14   chain=RS2-PTT-IPv6_out prefix=rstu:vxyz:1:8000::/49 invert-match=no action=accept 
15   chain=RS2-PTT-IPv6_out invert-match=no action=discard 
16   ;;; LG IPv4
     chain=LG-PTT-IPv4_in invert-match=no action=discard 
17   chain=LG-PTT-IPv4_out invert-match=no action=accept 
18   ;;; LG IPv6
     chain=LG-PTT-IPv6_in invert-match=no action=discard 
19   chain=LG-PTT-IPv6_out invert-match=no action=accept 
20   ;;; HE Tunel Broker
     chain=Tunel-IPv6-HE_in prefix=::/0 invert-match=no action=discard 
21   chain=Tunel-IPv6-HE_out prefix=rstu:vxyz:1::/48 invert-match=yes action=discard

Comentários sobre os filtros:

  1. De 0 a 15 estão as regras para os dois “Route Servers” de cada protocolo (IPv4 e IPv6). Cada um com 4 regras: (a) não recebe rota default (e recebe tudo mais…); (b) encaminha o bloco desagregado (duas regras); (d) não envia mais nada.
  2. De 16 até 19, duas regras para cada LG: (a) não recebe nada; (b) envia tudo.
  3. De 20 a 21, duas regras para o “tunnel broker”: (a) não recebe rota default; (b) só anuncia o /48. Vale observar o “invert-match=yes” da regra 21 => descarta tudo, menos o /48.

Acordo bilateral de trânsito IPv4 via o PTT

Já foi solicitada a VLAN (tag) para o trânsito via o PTT. Assim que for implementado, as informações serão incluídas neste texto.

Trânsito IPv6 via Tunnel Broker

A referência para o “Tunnel Broker” com a Hurricane Eletric é http://tunnelbroker.net/. É gratuito e há o esquema de implementação para o Mikrotik, disponível no sítio.

Empareamento com o Team-Cymru, para receber “full bogon”, IPv4 e IPv6.

Os filtros não estão garantindo que IPs (v4 e v6), não estejam sendo encaminhados para o PTT, em particular, nas regras dos “Route Servers”. Existem duas soluções para isto:

  • Identificar, manualmente, os bogons no IRR ou outros locais. Construir uma lista de IPs (v4 e v6) e incluir as regras correspondentes. A complicação a a revisão destas listas, em particular, de cada um dos RIRs, pois IPs são liberados sem maiores avisos.
  • Mais confortável, estabelecer um empareamento com o Team-Cymru que enviará as listas atualizadas para serem encaminhadas ao “blackhole” do Mikrotik.

As informações do Team-Cymru, incluindo esquema de implementação no Mikrotik pode ser encontrada em http://www.team-cymru.org/, com muitas outras informações disponíveis. Como o Team-Cymru faz um ótimo trabalho e é de longe a melhor opção. A sugestão no sítio do Team-Cymru, para o Mikrotik é:

# Empareamento
/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru1 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

/routing bgp peer add address-families=ip,ipv6 disabled=no in-filter=TeamCymru_in \
 instance=default multihop=yes name=TeamCymru2 out-filter=Teamcymru_out \
 remote-address=IPV4_INFORMADO_PELO_TEAM-CYMRU remote-as=65332 \
 tcp-md5-key=INFORMADO_PELO_TEAM-CYMRU

# Filtros
/routing filter add action=accept bgp-communities=65332:888 \
 chain=TeamCymru_in comment="" disabled=no invert-match=no \
 set-type=blackhole
/routing filter add action=discard chain=TeamCymru_in comment="" \
 disabled=no invert-match=no
/routing filter add action=discard chain=TeamCymru_out comment="" \
 disabled=no invert-match=no

Eis os comentários e observações úteis sobre as sugestões acima:

  • São dois empareamentos (dois servidores, diferentes), para efeitos de redundância.
  • O empareamento é “multihop” e, com um ASN privativo(!).
  • Um BGP que fala com chave MD5, para adicionar segurança.
  • Os três filtros, na ordem: (a) recebe somente os IPs que chegam associados à comunidade 65332:888, do AS65332. O Team-Cymru diferencia o “full bogon” e o “tradicional bogon”, por comunidades. Todas as rotas que chegam associadas à comunidade 65332:888, são marcadas como “blackhole”. (b) Nada mais é recebido do empareamento com o AS65332. (c) Nada será enviado via o empareamento com o AS65332.
  • As rotas marcadas como “blackhole” são “silenciosamente” descartadas na FIB (uma das tabelas de roteamento), e portanto, nada mais precisa ser feito. As regras de descarte de rotas nas tabelas de roteamento são muitas e complexas para lembra a todo momento, mas podem ser estudadas com carinho, nas seguintes referências:
  • Após o estudo das referências acima, para adquirir mais intimidade com o BGP e sua incrível complexidade, que tal identificar uma outra forma de lidar com os bogons (ainda usando o Team-Cymru)? Por exemplo, sem marcar como “blakhole”? Uma dica: sem necessidade de filtrar a saída em cada empareamento.

 

Implementação

A Figura 5, que segue, mostra o estado dos empareados no nosso Mikrotik. Ainda não foi implementado o empareamento com o Team-Cymru. Portanto, ele não aparece, ainda.

 

Figura 5. Estado dos empareamentos.

 

A visibilidade externa ainda é pequena, mas já pode ser vista em aqui. Por exemplo, o empareamento multilateral com a RNP, no PTT-Belém e dois blocos IPv6, /48, anunciados nos empareamento de Belém e SJCampos.

 

Comentários Finais

A nova versão do Mikrotik está com quase todas as facilidades implementadas em IPv6. Isto significa que é possível deixar de usar o IPv4 nas interconexões inter AS e, também, intra ASes. E os acessos via SSH estão disponíveis a qualquer interface IPv6 (inclusive wireless), vantagem, neste caso para os ISPs. Nos próximos ensaios daremos preferência ao IPv6

Referências

[1] José Eduardo de Oliveira, PTT Metro, 03/01/2011, Disponível em http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/introducao-ao-pttmetro.pdf. Acessado em 29/10/2011 08:08.

Laboratório virtual de roteamento – LVR (I)

Atualizado em: 30/01/2011.

Introdução

Ultimamente tenho gasto meu tempo no aperfeiçoamento do meu conhecimento na RPSL (com foco no Abranet IRR, [1]) e na construção da infraestrutura de rede da minha empresa. São dois projetos muito interessantes, que exigem uma enorme dedicação.

O Abranet IRR já possui uma equipe muito boa e breve teremos novidades. Acho que esse projeto da Abranet, que não é exclusivamente o IRR trará muitos benefícios para os administradores de ASes brasileiros. É um projeto de médio/longo prazos, com uma característica de neutralidade que somente uma instituição como a Abranet poderia proporcionar.

Dos trabalhos relacionados com a demanda da empresa, onde um conceito renovado de Voz sobre IP está sendo implementado chegam os principais desafios. São vários e, principalmente na parte relacionada com BGP, PTTs, túneis MPLSs e infraestrutura da Internet reside o mais apaixonante interesse do autor, eterno aprendiz em roteamento. Provavelmente, todos nós somos.

Um dos maiores problemas que tenho encontrado está no exercício de uma determinada teoria em relação ao que se está planejando. Geralmente o exercício está ligado em como fazer ou, como aplicar nos equipamentos disponíveis. A falta de padrão e a tentativa de estabelecer como padrão, equipamentos da Cisco aumenta mais ainda a dificultade e esforço. Esse esforço é redobrado quando, uma vez entendido a teoria tenta-se ir à prática.

Com tais preocupações em mente ao estudar um excelente curso, em [2], imaginei a hipótese de construir um laboratório apropriado para testar e aprender o que se precisa. Essa hipótese já tinha sido pensada, logo após o treinamento de IPv6, no Nic.br, [3]. Quem teve essa oportunidade sabe muito bem o quão bem elaborado foi o esforço do Antônio Moreiras (responsável pelo treinamento IPv6, do Nic.br). O laboratório engendrado para o treinamento é algo muito interessante. Invejável e perfeito. Sei que houve uma equipe envolvida na construção desse laboratório de IPv6, na qual o Eduardo Ascenço teve participação significativa, entre muitos outros.

Resolvi então, montar um laboratório pessoal, que chamei de Laboratório Virtual de Roteamento (LVR). O modelo desse laboratório deveria ter as seguintes características:

  • Ser ilimitadamente escalável: tanto sob o ponto de vista do crescimento físico, como do crescimento lógico. Escalabilidade lógica implica na possibilidade de ampliar o exercício para a prática. Por exemplo, o laboratório poderia se conectar a um PTT. Nunca houve a pretensão de fazer algo como o projeto GENI, [4], mas o GENI sempre esteve no foco.
  • Flexível: permitir a inclusão de novos recursos e facilidades. Há aqui, no escritório, diversos roteadores que eventualmente pudesse ser interconectados ao projeto para permitir experiências práticas.
  • Mobilidade: o projeto deve permitir acesso remoto ou acompanhar as viagens pessoais.
  • Ser barato! Sem comentários.

Foi então, que ao terminar o treinamento [2], a base do LVR foi estabelecida. Nesse texto e nos outros que virão pretende-se contar as experiências.

O modelo do LVR

A idéia inicial foi feita sobre 7 (sete) servidores Mikrotiks (MKs), implementados em máquinas virtuais, em um notebook. Usando o esquema simples de roteamento estático, o que foi feito está na figura 1, abaixo. Na figura está um modelo de representar a Internet concebido em [5], onde os ASes estão representados em laranja e PTTs em verde. Vem a calhar, tal representação, para o que iremos falar no futuro.

Figura 1. Modelo original do LVR, baseado em rede local.

A implementação de rotas estáticas permitiu experimentar o resultado. Tendo sido positivo, a preocupação agora era criar uma topologia que permitisse transformações de forma, sem dificuldade. Então, abstraiu-se das rotas estáticas influenciadas pela rede onde o notebook estava. Em outras palavras, a conectividade foi estabelecida e a figura 2 mostra que a pretensão era uma abstração dessa conectividade para se pensar em outra.

Figura 2. Abstraindo-se das interconexões.

Cada Mikrotik do LVR está identificado como MKn, para n de 0 a 7. O MK0 não é virtual. É um gateway com acesso à Internet. A versalidade do Mikrotik é incrível! Por isso ele foi preferido, inicialmente. Mas, a possibilidade de uma máquina virtual, não limita nenhuma possibilidade, tais como Quagga, Bird [5] e outros. Um hospedeiro poderoso permite asas à imaginação.

Iniciou-se a implementação de VLANs, para ligar os MKn. Na medida quem que as VLANs foram criadas, pode-se, finalmente, abstrair-se das rotas estáticas originais. Só abstração. Elas não foram retiradas, com o objetivo de manter a conectividade. Mas, podem ser ignoradas, já que não participam como “gateway” em cada MKn. A figura 3 exibe a primeira VLAN.

Figura 3. Construindo as VLANs.

Em seguida, os outros MKs tiveram suas VLANs estabelecidas, conforme mostra as figuras que seguem. Note-se a numeração das VLANs. Por exemplo, a VLAN que conecta o MK0 ao MK1, tem o número 10. O mesmo acontece com os IPs definidos para as VLANs. Sempre são 10.1.n.0/30, onde n é o número da VLAN. Isso obrigou uma rota estática do 10.1.0.0/17 para os vizinhos. Tudo para facilitar a implementação.

Próximas atividades

Eis alguma das próximas atividades sobre o LVR:

  • IPv6: nesse caso pode-se até mesmo viabilizar os MK virtuais, quando da implementação do BGP.
  • Seguir a proposta do Greg: RIP, OSPF, eBGP e iBGP
  • Novas topologias para que se possa fazer experiências.
  • Manter as experiências descritas sumariamente aqui nesse blogue e em detalhes, na Base de Conhecimento da Abranet.
  • Estimular a criação de outros LVRs para troca de experiências e interconexões. O LVR acima tem a identificação LVR28182.
  • Em 7 de novembro de 2010 resolvi trocar o nome do LVR para, Fábrica Fictícia de Encaminhamento (FFE ou 1111 1111 1110).

E o notebook, com estas 7 máquinas virtuais? Nem piou!

Referências

[1]. Abranet IRR.
[2]. Greg Sowell, Routing. Vídeo disponível aqui. Acessado em 02/11/2010.
[3]. Curso IPv6 Básico (Presencial). Nic.br, CEPTRO.br, IPv6.br. Material disponível aqui. Acessado em 02/11/2010.
[4]. Projeto GENI. Acessado em 02/11/2010.
[5]. Julião Braga, Tráfego, trânsito, transporte e peering (uma proposta de definição). Março 9, 2010, Disponível aqui. Acessado em 02/11/2010.
[5]. BIRD. Acessado em 02/11/2010.

Internet Routing Register (IRR)

Introdução

Alguns de meus amigos que trabalham com infraestrutura da Internet e administradores de redes, em particular, usam com uma certa frequência, o CIDR-Report. Pessoalmente, mantenho-o, permanentemente, no meu desktop. O CIDR-Report gerou um equívoco para estes amigos e para mim, também. O problema é que quando se pesquisava o CIDR-Report para qualquer ASN que tenha sido destinado pelo Nic.br (após a transferência das funções pelo LACNIC), aparecia a mensagem no cabeçalho “–No AS Description–“. Todos diziam que faltava o registro do AS no RADB, a principal base de dados do Internet Routing Register (IRR). E eu, repetia isso para outros. Então, passei a procurar uma maneira de registrar os ASs que administro no RADB. O primeiro impasse, nesta tentativa, foi o fato do registro no RADB custar US$495.00/ano. Uma pergunta do !3runo, na GTER, sobre o ALTDB, deu a pista para o registro do AS no RADB, em bases que eram espelhadas. Minhas tentativas de registro no ALTDB foram de pura frustação. Mas, mesmo percebendo que muitos já tinham registrado no ALTDB acabei usando os serviços do pessoal da Infraestrutura.IP. Em menos de um dia, os ASs estavam na RADB. Sem a anualidade! Recentemente (agosto/2009) a Pegasus implementou a primeira base de dados IRR no Brasil: http://irr.redepegasus.net.br.

Logo fui no CIDR-Report e percebi que, o No AS description, continuava lá. Esperei alguns dias e nada. Logo percebi que não era a inexistência no RADB que gerava a mensagem. Então fiz o que deveria ter feito desde o início: entender o IRR. A conclusão foi de que é uma peça muito importante para a consistência de rotas publicadas pelos ASs, em particular, para detetar o MOAS (acrônimo de Multiple Origin Autonomous Systems), automaticamente. Os conflitos de MOAS acontecem pelo simples problema de que um AS pode “injetar” qualquer prefixo, por configuração correta, incorreta ou maliciosamente*. A história do No AS description deixarei para o final.

O que é o IRR e para que serve?

Existem inúmeras definições na literatura que pesquisei. Uma delas diz que IRR é um conjunto de bases de dados que permitem ao BGP, documentar suas rotas e políticas de roteamento, com o objetivo de dar consistência às configurações de um roteador. Dizia ainda que o BGP fazia isto “conversando” em uma linguagem chamada RPSL. É a linguagem comum dos whois, jwhois, etc. E a mesma que motivou a construção de uma autômata de pilha em artigo que pode ser visto aqui.

Nada de errado com a definição acima. Mas não era muito precisa. Cheguei então, à página oficial do IRR, em [5]. Há várias informações importantes, incluindo as bases de dados ligadas ao RADB. A relação das bases de dados é quase uma piada, mostrando que alguma coisa não estava sendo levada a sério. A última vez que estive por lá foi no mes de março/2009.

Mais á frente, percebi que muitos RIRs possuem ofertas de bases de IRR, espelhadas no RADB, para os usuários de sua região, mas não vi nada em relação ao LACNIC, exceto propostas, inclusive do Nic.br. Aqui, uma notícia do LACNIC a respeito. O APINIC [6] tem o APIRR e é capitaneado pelo Japão, também com um serviço IRR para seus usuários, como pode ser visto em [3].

Europa (RIPE) e Japão (membro do RIPE), levaram a sério o IRR. E, principalmente no Japão, estão os trabalhos mais consistentes sobre IRR. Em um dos trabalhos que li, [7], uma definição completa sobre o que é, e para que serve o IRR reproduzo, no original: “The Internet Routing Registry (IRR) … is a large distributed repository of information, containing the routing policies of many of the networks that compose the Internet. The IRR was born about ten years ago with the main purpose to promote stability, consistency, and security of the global Internet routing. It consists of several registries that are maintained on a voluntary basis. The routing policies are expressed in the Routing Policy Specification Language (RPSL) … The IRR can be used by operators to look up peering agreements, to study optimal policies, and to (possibly automatically) configure routers.”

Logo a seguir, o trabalho ressalta: “There is a wide discussion about the current role of the IRR … Some people consider it outdated and almost useless. Others have put in evidence its importance to understand the Internet routing and that it contains unique and significant information. Anyway, it is undeniable that the IRR keeps on being fed by many operators, that useful tools have been developed to deal with the IRR (see, e.g., IRRToolSet [3]), …”.

Queria chegar, na citação acima, no IRRToolSet. Acabei implementando a IRRToolSet em FreeBSD e tem realmente algumas ferramentas interessantes. Por exemplo a peval, com a qual descobri que um punhado de gente boa publica blocos /24. Aos montões! Outra que seria interessante, é a prtraceroute, que inclui o ASN e a política de roteamento, em cada etapa do traceroute. Sobre a instalação do IRRToolSet, veja aqui. Há uma lista pouco movimentada, mas interessante, que pode ser assinada aqui.

A história do –No AS Description–, no CIDR-Report

Eu não percebi, de imediato, que a mensagem, tecnicamente incômoda, do CIDR-Report somente ocorria para os ASs distribuídos pelo Nic.br, a partir da mudança do LACNIC, em meados de 2007. Escrevi ao LACNIC a respeito do problema e a resposta que obtive não foi muito clara e resolvi escrever para o Geoff Huston, responsável pelo CIDR-Report. Ele me respondeu de pronto, dizendo que o problema estava relacionado com o jwhois, que o LACNIC não estava autorizando a consulta em suas bases de whois. Três ou quatro mensagens se seguiram para o LACNIC, sendo que na penúltima, finalmente, percebi que o problema eram somente os atuais ASs liberados pelo Nic.br. Por fim, o LACNIC em uma das respostas informou que o problema do proxy seria resolvido nos primeiros 4 meses de 2010, já que o CIDR-Report não era tão importante assim, para os administradores de sistemas.

Mais recentemente, ando desconfiado que outros além do CIDR-Report estão com o mesmo problema. Por exemplo, o Google Analytics. A grande maioria dos acessos de rede (93%), são registrados como comite gestor da internet no brasil.

Últimas notícias sobre IRRToolSet

Há cerca de dois ou três dias atrás (a partir de hoje, 15/05/2009) tem havido um debate interessante sobre as ferramentas do IRRToolSet. Em particular, val a pena ver aqui, a descrição que Nick Hilliard, faz sobre cada uma delas. Para frente e para trás, na sequência dessa mensagem o debate é interessante.

* Usar a base do IRR para detetar conflitos de MOAS, não é a única técnica disponível. Há uma corrente recomendando o bgp.in.addr.arpa.. Esse grupo, provavelmente está preocupado com a falta de confiabilidade das informações armazenadas na RADB. Como elas são atualizadas pelos próprios responsáveis pelos ASs, observa-se um certo descuido. Entretanto, nota-se que o pessoal que faz peering ou pretende fazer, está cuidando de forma correta das suas informações lá armazenadas.

Referências


[1] Siganos G., Faloutsos, M., Analazing BGP policies: methodology and tool, INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, Vol. 3 (2004), pp. 1640-1651 vol.3.
[2] Alaettinoglu C. et alii, Routing Policy Specification Language (RPSL), The Internet Society, RFC2622, 1999.
[3] JPNIC IRR (JPIRR) Operation Policies and User Guideline, Japan Network Information Center, IRR-Planning Team, July 2003.
[4] Nagahashi, K., Esaki, H. & Murai, J., An integrity check for the conflit Origin AS Prefixes in the inter-domain routing, IEICE Trans. Commun., Vol. E86-B, no. 2, February 2003.
[5] Internet Routing Register
[6] APIRR resource guide
[7] Battista, G. di, Refice, T., Rimondini, M., How to Extract BGP Peering Information from the Internet Routing Registry

Últimas atualizações:
29/04/2009 09:00