Arquivo

Archive for the ‘IPv6’ Category

XML na Infraestrutura da Internet

Jewish law prohibited farmers from harvesting every last item from their fields.
If something was missed in the first pass, they were to leave it for the poor to harvest.
This was called gleaning. Gleaning provides a metaphor for good writing and teaching.
Don’t explain everything in complete detail. Leave something for the reader or student to harvest on their own.
From John Cook => https://plus.google.com/u/0/+JohnCook/posts/4UpWuws59oU

 

Introdução

 

Tenho insistido na ideia da aplicação de Web Semântica na Infraestrutura da Internet. Durante o, ainda em desenvolvimento desta ideia, uma questão parece evidente: o domínio da Infraestrutura da Internet é enorme e inexplorado sob a ótica da Web Semântica! Basta uma olhada na Figura 1, uma representação simplificada e parcial deste domínio, na qual, os principais agentes aparecem com algumas relações básicas. Tais agentes são os produtores das informações, isto é, dados que são produzidos e guardados em repositórios, geralmente, no formato texto com uma estrutura mínima. Há um texto em inglês, Preliminaries essays to research in Semantic Web applied to Internet Infrastructure, disponível em PDF, no qual, entre outras coisas, esclarece como os administradores de Sistemas Autônomos consomem estes dados, através de ferramentas orientadas a este fim. No “Preliminaries essays…”, a localização de alguns dos repositórios está representado em um cenário mais abrangente.

 

VisaoEntrelaçadaIPv6

Figura 1. Representação simplificada e parcial do domínio da Infraestrutura da Internet.

 

Ao procurar fixar o cenário, a maneira de pensar varia do geral para o particular e muitas vezes, também, do particular para o geral. Uma troca, sem limites usando refinamentos sucessivos, tanto no pensamento “top->down” como no “bottom->up”. Neste vai e vem da forma de pensar, o Mapa de Conceito4, exerce um papel fundamental, já que sua característica principal é a facilidade de representar o domínio do problema (ou do conhecimento), visualmente, simplificado e, direto. Existem vários mapas de conceito disponíveis, nos quais incluem os mapas mentais, que também fazem um bom trabalho. Neste texto, usamos o CMaps8 descrito sob o ponto de vista de suas aplicações. A Figura 1 e muitas outras que seguem foram, também produzidas, no CMaps.

Além das preocupações com o tamanho do domínio, a ausência de um vocabulário direto e aplicável ao domínio há outras. Entre estas outras, a linguagem para representar e permitir fácil acesso aos repositórios é um dos aspectos mais importantes. A base para tratar as aplicações de Web Semântica está na eXtensible Markup Language (XML), definida em [6] e é sobre ela que trataremos neste primeiro artigo.

 

A XML e a aplicação na delegação de IPv6

 

Sistemas Autônomos6 na Internet são identificados por um número denominado ASN (Autonomous System Number). Este número é controlado e distribuído pelo IANA (Internet Assigned Numbers Authority). A IANA (http://www.iana.org/about) é um departamento do ICANN (Internet Corporation for Assigned Names and Numbers). A IANA, também controla a distribuição de números IPv4 e IPv6, entre outras funções. O mecanismo de distribuição do IANA é do tipo atacado, isto é, ela distribui os números de AS, IPv4 e IPv6 para os RIR (Regional Internet Register), que por sua vez distribuem para os NIR (National Internet Register) ou diretamente para os interessados, quando não existir um NIR. Os RIRs são em número de cinco, cada um responsável por uma região do mundo (http://www.iana.org/numbers). Os RIRs são: AfriNIC, APNIC, ARIN, LACNIC e RIPE NCC. A IANA está, também, intimamente conectado com o IETF9. ICANN, IANA, IETF, números IPv4, números IPv6, números de ASes, RIRs, NIRs, Empresas, Instituições, Países, Pessoas e muitas outras coisas são parte dos “conceitos” associados ao domínio Infraestrutura da Internet, ou em outras palavras, ao vocabulário do domínio.

Para a aplicação da XML trabalharemos sobre um sub-domínio da representação exibida na Figura 1 (em laranja). Com o CMaps obtemos facilmente a derivação que pode ser vista na Figura 2.

 

DetalheIPv6

Figura 2. Detalhe da destinação de um bloco IPv6.

 

A representação fala por si mesmo. Em resumo, uma Empresa (digamos, um provedor) recebe um bloco de IPv6 sobre o qual estamos interessados. De posse deste bloco, um /32, o provedor planeja e designa sub-blocos a seus clientes e/ou usuários. Partindo da premissa de que a empresa tem muitos clientes, há necessidade de se criar um repositório do recurso (bloco IPv6) recebido, juntamente com as informações a ele associadas. Sobre este repositório uma série de operações conhecidas devem estar disponíveis. Uma abstração deste repositório e suas relações podem ser vistos na Figura 3.

 

RepositorioAbstrato

Figura 3. Representação abstrata de um repositório de registro de designação IPv6 e suas respectivas operações.

 

A abstração indica que o tal repositório pode ser, desde folhas de papel até um local (digital), onde se pode usar processos mais so fisticados, que tenham, por exemplo, um gerenciador de banco de dados relacional (digamos, MySQL). Vamos eliminar as soluções trabalhosas, como as folhas de papel, para procurar alternativas mais apropriadas sob o ponto de vista do acesso ao repositório e proporcionais a expectativa de tamanho deste repositório.

Faremos uma incursão sobre as soluções tradicionais, para depois seguirmos as técnicas que envolvem Web Semântica, nosso objetivo neste texto. Passemos, então, à descrição do contexto do problema desejado, com alguns detalhes importantes descobertos no planejamento.

 

Planejamento da distribuição de um bloco /32

 

Então, o provedor recebeu, do Registro.br, um bloco IPv6, que iremos supor como sendo o bloco dddd:dd00::/32. Depois de ler o artigo “Preparing an IPv6 Address”5 e o RFC 59321, cuidadosamente planejou a sua distribuição. Ele trabalhou tendo em mãos o Guia didático de Endereçamento IPv6. Assim, os números envolvidos tornaram fáceis de encontrar.

Ele dividiu este /32 em 65.536 blocos /48. Em seguida, achou adequado separar os primeiros 32.768 blocos para uso futuro e passou a pensar na segunda metade. Insistente reservou a primeira metade deste conjunto de blocos /48 (16.384), também, para uso futuro e passou a pensar sobre a divisão dos outros 16.384, da segunda metade, para que fosse distribuida a seus Clientes. O provedor calculou que na sequência deste conjunto de /48s, ele teria 1.024 x 16 blocos /48. Chamou cada um destes /48 de Disponibilidades e montou o seguinte esquema de distribuição:

  • Disponibilidade 0: dddd:dd00:c000::/48 a dddd:dd00:c00f::/48
    • dddd:dd00:c000::/48 ) Uso interno
    • dddd:dd00:c001::/48 ) Liberado
    • dddd:dd00:c00f::/48 ) Liberado
  • Disponibilidade 1: dddd:dd00:c010::/48 a dddd:dd00:c01f::/48
    • dddd:dd00:c010::/48 ) Cliente/Localidade 1
    • dddd:dd00:c011::/48 ) Liberado
    • dddd:dd00:c01f::/48 ) Liberado
  • Disponibilidade 2: dddd:dd00:c020::/48 a dddd:dd00:c02f::/48
    • dddd:dd00:c020::/48 ) Cliente/Localidade 2
    • dddd:dd00:c021::/48 ) Liberado
    • dddd:dd00:c02f::/48 ) Liberado
  • Disponibilidade 3: dddd:dd00:c030::/48 a dddd:dd00:c03f::/48
    • dddd:dd00:c030::/48 ) Cliente/Localidade 3
    • dddd:dd00:c031::/48 ) Liberado
    • dddd:dd00:c03f::/48 ) Liberado
  • 

  • Disponibilidades 4 ate 511
  • Disponibilidade 512: dddd:dd00:c2f0::/48 a dddd:dd00:c2 ::/48
    • dddd:dd00:c2f0::/48 ) Cliente/Localidade 512
    • dddd:dd00:c2f1::/48 ) Liberado
    • dddd:dd00:c2 ::/48 ) Liberado
  • 

  • Disponibilidades 513 ate 1022
  • Disponibilidade 1023: dddd:dd00: f0::/48 a dddd:dd00: ::/48
    • dddd:dd00: f0::/48 ) Cliente/Localidade 1023
    • dddd:dd00: f1::/48 ) Liberado
    • dddd:dd00: ::/48 ) Liberado

Quando esta divisão foi feita, o provedor tinha em mente o RFC 61773, não deixando de pensar que um de seus clientes poderia dividir o bloco /48 em /56 ou /60. Indo um pouco mais além fez recomendações para que seus clientes distribuíssem a seus usuarios, blocos /64. Como em cada /48 estão disponveis 65.536 redes /64, ele fez as seguintes recomendacões a seus Clientes:

    

  • Usar o primeiro bloco /64 para Loopback.
  • 

  • Deixar pelo menos 15 redes contíguas ao /64 designado (da mesma forma que o /48, acima).
  • 

  • Avaliar o uso de su fíxos relativamente fáceis de lembrar, para a rede interna (por exemplo: CA5A, FACA, …).

Tudo isto está mostrado gráfi camente na Figura 4, onde P é o prefixo dddd:dd00 e, h, i, j são dígitos hexadecimais dentro dos limites escolhidos. Por outro lado, a base de um planejamento em Infraestrutura da Internet é a topologia. Neste caso usamos a topologia da Figura 2.8 do texto Topologias, Interconexões e Protocolos.

E assim, a divisão do IPv6 deixou de ser um problema. Agora, a questão é identifi car uma maneira de como controlar as informações relacionadas com a designação dos IPv6 aos Clientes. Sem dúvida, qualquer solução envolve um local de armazenamento das informações, isto é, um repositório para os dados. A visão mais abstrata capaz de ilustrar tal ambiente, onde pessoas (usuários) possuem acesso, é a mostrada na Figura 3.

 

DivisaoIPv6

Figura 4. Representando o plano de divisão do bloco /32, graficamente.

 

Construindo o repositório com a XML

 

XML é uma linguagem livre. São poucas as restrições (sintáticas!) sobre ela. Desta forma, o estilo, a experiência e a criatividade individuais determinam a estrutura do repositório. Para este texto, o repositório em XML foi proposto como abaixo, de forma parcial e resumida:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<empresaX>
  <designacao_ipv6>
    <ip prefixo="dddd:dd00::" masc="/32">
      <ip prefixo="dddd:dd00::" masc="/48">
        <designado_para>Livre</designado_para>
      </ip>
      <!-- ... -->
      <ip prefixo="dddd:dd00:8::" masc="/48">
        <ip prefixo="dddd:dd00:8000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c000::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <!-- 
            Grupo dos /48 designados 
        -->
        <ip prefixo="dddd:dd00:c001::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c002::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <ip prefixo="dddd:dd00:c003::" masc="/48">
          <designado_para>Livre</designado_para>
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c010::" masc="/48">      
          <designado_para>Localidade 1</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c010:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 1</comentarios>          
          </ip>
          <ip prefixo="dddd:dd00:c010:0001::" masc="/64">
            <designado_para>Cliente 1</designado_para>
            <fone>37-xxxx-xxxx</fone>
            <responsavel_t>Fulano de Tal</responsavel_t>
            <email>nome AT SPAMFREE exemplo DOT com DOT br</email>
            <comentarios>Cliente do Provedor</comentarios>          
          </ip>
          <!-- ... -->
          <ip prefixo="dddd:dd00:c010:CA5A:" masc="/64">
            <designado_para>Rede Local</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Utilizado na rede local</comentarios>   
          </ip>
          <!-- ... -->
        </ip>
        <!-- ... -->
        <ip prefixo="dddd:dd00:c020::" masc="/48">      
          <designado_para>Localidade 2</designado_para>
          <fone>12-3922-xxxx</fone>
          <responsavel_t>Julião Braga</responsavel_t>
          <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
          <comentarios>Utilizado na rede Interna</comentarios>        
          <ip prefixo="dddd:dd00:c020:0000::" masc="/64">
            <designado_para>Loopback</designado_para>
            <fone>12-3922-xxxx</fone>
            <responsavel_t>Julião Braga</responsavel_t>
            <email>juliao AT SPAMFREE braga DOT eti DOT br</email>
            <comentarios>Borda da Localidade 2</comentarios> 
          </ip>
          <!-- ... -->
        </ip>
      </ip>
    </ip>
  </designacao_ipv6>
</empresaX>

Pode-se concluir que o repositório tende-se a tornar muito grande. Entretanto, a partir da escolha inicial da estrutura (ou conjunto de marcadores), da XML, o processo é repetitivo, o que facilita o trabalho. As linguagens de programação (qualquer uma e em especial JavaScript) estão preparadas para trabalhar de maneira trivial sobre repositórios XML, o que facilitaria em muito as operações desejadas (Figura 3). Da mesma forma, os navegadores, imediatamente, representam de forma estruturada um arquivo XML, como pode ser visto na Figura 5.

 

XMLnoChrome

Figura 5. Repositório XML exibido no Chrome.

 

Não se pode esquecer que a W3C possui um recurso para validar um texto XML, bastante útil, que pode ser usado em Markup Validation Service.

Por outro lado, um banco de dados (repositório) XML possui uma organização hierárquica, como mostra a Figura 6.

 

XML-hierarquia

Figura 6. Organização hierárquica de um repositório XML.

 

A eficiência sobre um repositório com tais características depende não somente da hierarquia (ou arranjo dos marcadores) mas, também, do sistema de gerenciamento (programa) do repositório. Durante a etapa de programação, eventualmente, a hierarquia poderá ser aperfeiçoada.

 

Aperfeiçoando as ideias e, o projeto

 

Suponhamos que a ideia de um repositório XML para controlar as designações de IPv6 de um provedor tenha sido um sucesso. A notícia se espalha e um habilidoso programador, digamos, o Pedro Paulo (nosso programador fictício preferido…) resolve desenvolver um repositório para:

  • Atender a vários provedores e,
  • Controlar IPv6 e IPv4

Em uma primeira tentativa, a organização do repositório poderia ter a seguinte organização

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP>
    <empresaX>
        <blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <cliente id="201311281745">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaX>
    
    <empresaY>
        <blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <cliente id="201311281754">
            <nome></nome>
            <responsaveltecnico></responsaveltecnico>
            <fonenoc></fonenoc>
            <endereco>
                <logradouro></logradouro>
                <numero></numero>
                <complemento></complemento>
                <bairro></bairro>
                <cep></cep>
                <cidade></cidade>
                <estado></estado>
            </endereco>
            <ipv6designado></ipv6designado>
            <ipv4designado></ipv4designado>
            <observacoes></observacoes>
        </cliente>  
    
    </empresaY>
</repositorioIP>

 

Este segundo modelo altera a hierarquia do primeiro. O componente mais importante do repositório é o marcador <cliente>, mas exige-se que os blocos delegados de IPv6 e IPv4 estejam presentes, mas dando liberdade em relação à presença dos marcadores debaixo do marcador mais importante. Uma visão mas agradável é a do navegador, mostrada na Figura 7, logo abaixo.

 

XML-RepositorioPedroPaulo

Figura 7. O novo repositório exibido no Chrome.

 

Ou, mais agradável ainda, a visão gráfica da hierarquia mostrada na Figura 8.

 

XML-hierarquia-PedroPaulo

Figura 8. Visão gráfica da hierarquia do segundo modelo (Pedro Paulo).

 

Embora imediado é oportuno observar, que a Figura 8 representa uma árvore (estrutura de dados). Navegar nesta árvore é um processo eficiente. Por exemplo, se procuramos pelas informações da Empresa 1, basta seguir os ramos abaixo dela, ignorando o restante dos nós à sua direita. Ou seja, qualquer operação a ser feita sobre o repositório (indicadas pela Figura 3) é estritamente localizada, portanto, muitíssimo eficiente.

Há, contudo, uma questão importunando ao Pedro Paulo. Os nomes dos marcadores de cada empresa / provedor são os mesmos e isto pode causar problemas de consistência ou de conflitos. Se o repositório fosse controlado à mão (por um ser humano), certamente poderíamos trocar um marcador, sem perceber, já que eles são idênticos. Mesmo desenvolvendo procedimentos para manipular automaticamente o repositório, a inconsistência prevalecerá. A linguagem XML possui na sua especificação, um mecanismo importante para garantir a consistência dos marcadores. É a técnica denominada espaço de nomes (do inglês, namespaces). Falaremos sobre ela em seguida, mas uma ótima introdução ao conceito pode ser visto em XML Namespaces.

 

Espaço de nomes em XML

 

O objetivo do espaço de nomes em XML é eliminar conflitos entre marcadores ou, em outras palavras, estabelecer a unicidade dos marcadores. Isto é feito através do atributo xmlns que distinguirá os prefixos a serem usados nos marcadores. O formato deste atributo é, xmlns:prefixo=”URI” colocado(s) no marcador inicial (raiz). URI (Uniform Resource Identifier) é uma cadeia de caracteres que identifica um Recurso da Internet. A URL (Uniform Resource Locator), usualmente usado por nós é um caso particular da URI. Na XML, a URI é simplesmente a caracterização da unicidade e não transporta nenhuma informação adicional.

Nos artigos seguintes veremos um papel mais preponderante do espaço de nomes. Por hora, o segundo modelo do repositório proposto e, a Figura 9, ilustram como ele se transforma, ao usar espaço de nomes, que comparando com a Figura 7 torna-se o entendimento imediatamente intuitivo.

 

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<repositorioIP 
    xmlns:x="http://ws.org.br/empresa/X"
    xmlns:y="http://ws.org.br/empresa/Y">
    
    <x:empresa>
        <x:blocoipv6 prefixo="dddd:dd00::" mascara="32" />
        <x:blocoipv4 prefixo="192.168.0.0/20" mascara="20" />
        <x:cliente id="201311281745">
            <x:nome></x:nome>
            <x:responsaveltecnico></x:responsaveltecnico>
            <x:fonenoc></x:fonenoc>
            <x:endereco>
                <x:logradouro></x:logradouro>
                <x:numero></x:numero>
                <x:complemento></x:complemento>
                <x:bairro></x:bairro>
                <x:cep></x:cep>
                <x:cidade></x:cidade>
                <x:estado></x:estado>
            </x:endereco>
            <x:ipv6designado></x:ipv6designado>
            <x:ipv4designado></x:ipv4designado>
            <x:observacoes></x:observacoes>
        </x:cliente>  
    
    </x:empresa>
    
    <y:empresa>
        <y:blocoipv6 prefixo="dddd:dd06::" mascara="32" />
        <y:blocoipv4 prefixo="192.168.16.0/20" mascara="20" />
        <y:cliente id="201311281754">
            <y:nome></y:nome>
            <y:responsaveltecnico></y:responsaveltecnico>
            <y:fonenoc></y:fonenoc>
            <y:endereco>
                <y:logradouro></y:logradouro>
                <y:numero></y:numero>
                <y:complemento></y:complemento>
                <y:bairro></y:bairro>
                <y:cep></y:cep>
                <y:cidade></y:cidade>
                <y:estado></y:estado>
            </y:endereco>
            <y:ipv6designado></y:ipv6designado>
            <y:ipv4designado></y:ipv4designado>
            <y:observacoes></y:observacoes>
        </y:cliente>  
    
    </y:empresa>
</repositorioIP>

 

Olhando um pouco mais atentamente a XML acima, surge uma questão sobre a qual vale a pena pensar: será que o atributo id, incluído nos marcadores <cliente> faz sentido diante da presença do espaço de nomes?

 

XML-NS-RepositorioPedroPaulo

Figura 9. O segundo modelo, com a unicidade dos marcadores garantida pelo espaço de nomes, visto pelo Chrome.

 

Considerações finais

 

Nada foi dito no artigo sobre as técnicas de programação para manipular repositórios em XML. Foge do escopo do texto, que se preocupou em mostrar algumas facilidades para planejar o uso dos recursos de numeração (IPv6 / IPv4) e a alternativa de estrutura-los em um repositório usando XML. A XML é uma linguagem orientada, principalmente, ao entendimento computador-computador (ou melhor, programa-programa), muito embora ela seja acessível a humanos. Dada à sua forma livre de expressão, presta-se a inúmeras aplicações úteis, como a do exemplo, documentar a distribuição de IPv6.

Sob o ponto de vista da Web Semântica, a XML é muito restrita para a necessária expressividade semântica, apesar de ser a base para as alternativas que serão abordadas nos próximos textos.

 

Referências

  1. S. Kawamura amd M. Kawashima. A Recommendation for IPv6 Address Text Representation. RFC5952. December 2008. Disponível em: http://www.rfc-editor.org/rfc/rfc5952.txt. Acessado em 02/10/2013.
  2. IHMC. Cmap tools. http://ftp.ihmc.us/. Acessado em 02/10/2013.
  3. T. Narten and G. Huston ant L. Roberts. IPv6 Address Assignment to End Sites, March 2011. RFC6117.
  4. Joseph D. Novak and D. Bob Gowin. Learning how to learn. Cambridge University Press, Cambridge, UK, 1 edition, 1984.
  5. SurfNet. Preparing an IPv6 Address Plan. Disponível em: https://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf. Acessado em: 02/10/2013.
  6. BRAY, T. et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). W3C, 26 November 2008. Disponivel em: http://www.w3.org/TR/REC-xml/. Acesso em: 22 maio 2013.
  7. BRAGA, J. Sistemas Autonomos, Empresas Autônomas. Infraestrutura da Internet, 03 mar. 2006. Disponivel em: https://ii.blog.br/2006/03/03/sistemas-autonomos-empresas-autonomas/. Acesso em: 22 maio 2013.
  8. CAÑAS, A. J. et al. A Summary of Literature Pertaining to the Use of Concept Mapping Techniques and Technologies for Education and Performance Support. The Institute for Human and Machine Cognition. Pensacola, FL: The Chief of Naval Education and Training. 2003. p. 108.
  9. BRAGA, J. A ISOC, o IETF e a infraestrutura da Internet. Infraestrutura da Internet, 03 Janeiro 2013. Disponivel em: https://ii.blog.br/2013/01/03/a-isoc-o-ietf-e-a-infraestrutura-da-infraestrutura-da-internet/. Acesso em: 22 maio 2013.

Anúncios

Cenas do IPv6: NTP

Introdução

Retorno ao tema, pela ênfase que estamos dando à transição IPv6. Uma das opções é trocar a topologia dos nossos servidores de ntp. Embora existam inúmeras boas referências sobre o ntp, somente três delas são citadas. Nossos servidores de ntp sempre foram baseados no texto do Nic.br (NTP.br), que a principal referência. O texto da RNP (RNP), é bastante completo, com informações exclusivas sobre o ntp em alguns roteadores, e é uma boa referência. Já (Windl Ulrich et al.) é a mais completa das referências disponíveis, com análises significativas sobre cada comando do ntp e respectivos parâmetros. É uma ótima fonte de consultas.

A topologia

Já que nossos servidores são baseados nos servidores do NTP.br, estes são para nós, os servidores stratum 1. Os servidores de acesso pelos Clientes e outros Servidores (não ntp) são stratum 3, os quais são servidos pelos servidores stratum 2.

A figura abaixo é a fonte de nosso debate neste texto.

 

 

Três servidores do NTP.br estão em pilha dupla (laranja e verde). Outros cinco, dos oitos são somente IPv4. Como veremos mais adiante, conhecer o IP de cada um será fundamental para nossa configuração. A tabela abaixo, adaptada de (NTP.br) mostra tais IPs:

 

Nome IPv6 IPv4
a.st1.ntp.br 2001:12ff:0:7::186 200.160.7.186
b.st1.ntp.br NA 201.49.148.135
c.st1.ntp.br NA 200.186.125.195
d.st1.ntp.br NA 200.192.232.8
a.ntp.br 2001:12ff::8 200.160.0.8
b.ntp.br NA 200.189.40.8
c.ntp.br NA 200.192.232.8
gps.ntp.br 2001:12ff:0:7::193 200.160.7.193

 

Os nossos servidores stratum 2 são em número de cinco. Pela topologia vê-se que o S01 é unicamente IPv6, S02 e S03 são em pilha dupla, enquanto S04 e S05 são unicamente IPv4. Eles estão localizados em diversas regiões do País, e os IPv4 brevemente estarão em pilha dupla.

Na base da topologia há uma mistura de Clientes e Servidores. Alguns dos Servidores atendem os Clientes locais em ntp. Estes formam o stratum 3, como já explicado.

Eis a síntese de nossa implementações, que servem com observações para interessados:

  • Servidores de ntp, unicamente em IPv6 devem referenciar servidores IPv6 (mesmo em pilha dupla, claro). É o caso do S01 que sincroniza com os servidores a.st1.ntp.br, a.ntp.br e gps.ntp.br, do NTP.br.
  • Servidores em pilha dupla sincronizam com todos os servidores em pilha dupla, e com IPv4 e IPv6 simples. Isto serve para os servidores stratum 2 e stratum 3.
  • Servidores/clientes IPv4 sincronizam com os IPv4 e os de pilha dupla.
  • Os servidores de cada stratum são empareados entre si (através do peer). Neste caso deve-se manter a compatibilidade entre pilha dupla, simples IPv6 e simples IPv4. Em IPv4 simples, nos comandos server, peer e restrict recomendamos o uso do IP ao invés do domínio, pois haverá maior rapidez na sincronização. Principalmente, no caso de um IPv6 simples ao sincronizar com pilha dupla. O exemplo abaixo ilustra o que foi dito, onde o servidor é IPv4 em pilha simples:
    server 200.160.7.186 iburst    # a.st1.ntp.br
    server b.st1.ntp.br iburst
    server c.st1.ntp.br iburst
    server d.st1.ntp.br iburst
    server 200.160.7.193 iburst    # gps.ntp.br
    server 200.160.0.8 iburst      # a.ntp.br
    server b.ntp.br iburst
    server c.ntp.br iburst
    
    peer abc.def.ghi.jkl        # S01
    peer mno.pqr.stu.vyx        # S02
    peer S03
    #peer S04                   # sem peer com S04 que é somente IPv6
    peer S05                    # S05 é somente IPv4
    
    restrict 200.160.7.186    # a.st1.ntp.br
    restrict b.st1.ntp.br
    restrict c.st1.ntp.br
    restrict d.st1.ntp.br
    restrict 200.160.7.193    # gps.ntp.br
    restrict 200.160.0.8      # a.ntp.br
    restrict b.ntp.br
    restrict c.ntp.br
    restrict abc.def.ghi.jkl        # S01
    restrict mno.pqr.stu.vyx        # S02
    restrict S03
    #restrict S04
    restrict S05
    
    
  • O IPv6 está implementado em “tunnel broker” com a HE. Não encontramos nenhum problema de sincronização.

Referências

Categorias:IPv6, ntp, TCP/IP

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.

A Seta IPv6: adaptando a complexidade do IPv6 à mente humana

Visualizar, calcular, manipular, registrar, organizar e documentar o IPv6

 

Pense um pouco sobre a figura.
Ache os prefixos empareados verticalmente, acima e abaixo da linha divisória (exceto o /64).

 

Uma boa companhia (inclusive, complementar) à Seta IPv6 é o Guia didático de Endereçamento IPv6 (GDEI), desenvolvido pelo pessoal do IPv6.br.

Como usar


É necessário um planejamento inicial. Talvez responder algumas perguntas como:

  1. Qual o bloco recebido do Registro.br? R: Por exemplo, o 2001:0DB8::/32.
  2. Como dividir/conquistar este bloco? R: Depende exclusivamente da experiência e da influência de experiências de terceiros. Digamos que divida em dois /33 e use o primeiro deles, deixando o segundo para outra oportunidade futura.
  3. Quais os recursos disponíveis para documentar o IPv6? R: Quem sabe um editor de textos, qualquer. Ou o Plone, razão pela qual a Seta IPv6 é um esquema favorável. Em ambos os casos pode-se expandir a Seta e colocar o nome dos Clientes, os quais serão os “donos” das redes. A expansão da Seta é a grande motivação para seu uso. Muitas pessoas já devem fazer isto.

Então, na Seta IPv6:

2001:0DB8::/33
2001:0DB8:8000::/33 (Deixar para quando esgotar o primeiro bloco /33)

 

Concentremos no bloco (ou rede, ou prefixo) 2001:0DB8::/33. Digamos, vamos distribuir /48s para nossos Clientes. Empareados (abaixo e acima da Seta IPv6):

2001:0DB8::/48
2001:0DB8:3::/48

 


Aqui precisa-se pensar um pouco sobre o prefixo /48: 48/4 = 12 dígitos hexadecimais.

a. Primeiro conjunto => 2
b. Segundo conjunto  => 0
c. Terceiro conjunto => 0
d. Quarto conjunto   => 1
e. Quinto conjunto   => 0
f. Sexto conjunto    => D
g. Sétimo            => B
h. Oitavo            => 8
i. Nono              => 0
j. Décimo            => 0
k. Décimo primeiro   => 0
l. Décimo segundo    => 0 ou 3

 


Assim, mais claramente, uma representação didática dos dois blocos /48:

2001:0DB8:0000::/48
2001:0DB8:0003::/48

 

O 3 é um dígito hexadecimal representado em binário por [0011]. Sempre colocaremos binários, entre [].

Vale lembrar que o prefixo 48 é um múltiplo de 4 (ou de 8). Mas isto nem sempre contece. Por exemplo, o prefixo /47. Dividindo por 4, temos 11 dígitos hexadecimais e um resto de 3 bits. Para efeitos didáticos, o segundo bloco acima pode ser representado como:

2001:0DB8:000[0011]::/48 

 

Os blocos /47 empareados na Seta, são:

2001:0DB8::/47
2001:0DB8:2::/47

 

O segundo bloco, 2001:0DB8:2::/47, sob a ótica didática:

2001:0DB8:000[001]::/47 

 

onde à direita vê-se 3 bits e não 4, para completar 47 bits (da esquerda para a direita). Pode-se, entretanto, exibir os 4 bits:

2001:0DB8:000[0010]::/47

 

Retornando aos dois blocos /48:

2001:0DB8::/48
2001:0DB8:3::/48

 

O primeiro bloco, contem todos os IPs entre 2001:0DB8:0000::/48 a 2001:0DB8:FFF2::/48. De uma forma mais completa, e didática, os IPs do primeiro bloco /48 são:

2001:0DB8:0000:0000:0000:0000:0000:0000
2001:0DB8:0000:0000:0000:0000:0000:0001
2001:0DB8:0000:0000:0000:0000:0000:0002
...
2001:0DB8:0000:0000:0000:0000:0000:000F
2001:0DB8:0000:0000:0000:0000:0000:0010
2001:0DB8:0000:0000:0000:0000:0000:0020
...
2001:0DB8:0000:0000:0000:0000:0000:00F0
2001:0DB8:0000:0000:0000:0000:0000:00F1
2001:0DB8:0000:0000:0000:0000:0000:00F2
...
2001:0DB8:FFF0:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF1:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF2:FFFF:FFFF:FFFF:FFFF:FFFF

 

e o segundo bloco, 2001:0DB8:3::/48, contem os IPs:

2001:0DB8:0003:0000:0000:0000:0000:0000
2001:0DB8:0003:0000:0000:0000:0000:0001
2001:0DB8:0003:0000:0000:0000:0000:0002
...
2001:0DB8:0003:0000:0000:0000:0000:000F
2001:0DB8:0003:0000:0000:0000:0000:0010
2001:0DB8:0003:0000:0000:0000:0000:0020
...
2001:0DB8:0003:0000:0000:0000:0000:00F0
2001:0DB8:0003:0000:0000:0000:0000:00F1
2001:0DB8:0003:0000:0000:0000:0000:00F2
...
2001:0DB8:FFF3:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF4:FFFF:FFFF:FFFF:FFFF:FFFF
...
2001:0DB8:FFF5:FFFF:FFFF:FFFF:FFFF:FFFF

2001:0DB8:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF

 

É intuitivo, principalmente consultando o GDEI, que os dois blocos

2001:0DB8::/48
2001:0DB8:3::/48

 

pertencem a um único bloco do prefixo /48 que, também é representado por:

2001:0DB8::/48

 

A Seta divide este bloco em dois conjuntos com o mesmo número de IPs, para facilitar nossa vida. Poderíamos dividir os blocos deste prefixo em vários outros /48s deste que fosse respeitado os 48 bits da máscara. Como os primeiros 32 bits são intocáveis, pois pertencem ao bloco /32 original. Os /48s são vistos da seguinte forma, didáticamente:

2001:0DB8:0000::/48
2001:0DB8:0001::/48
2001:0DB8:0002::/48
2001:0DB8:0003::/48
2001:0DB8:0004::/48
...
2001:0DB8:000F::/48
2001:0DB8:0010::/48
...
2001:0DB8:00FF::/48
2001:0DB8:0100::/48
2001:0DB8:0101::/48
...
2001:0DB8:FFFF::/48

 

ou sejam, 65.536 blocos (ou redes) /48, conforme diz o GDEI. Mais ainda: para cada /48 acima, os 48 bits iniciais são intocáveis, pois cada um é uma rede independente.

Imagine que a linha divisória da Seta deixa abaixo dela tudo o que iremos usar em outro momento, já que divide os prefixos em duas metades. É uma forma de organizar nossas habilidades para uma imensidão de IPs, “nunca dantes” imaginado!

Decidindo repassar aos Clientes, blocos com prefixo /64, conforme as sugestões iniciais. Cada um dos blocos /48 acima, pode ser divididos em outras 65.536 redes (veja o GDEI) com prefixo /64. O /64 implicam 64 bits de máscara (e intocáveis). Então, usando o primeiro bloco (2001:0DB8:0000:/48), como exemplo, eis os blocos /64 possíveis:

2001:0DB8:0000:0000::/64 => 2001:0DB8::/64
2001:0DB8:0000:0001::/64 => 2001:0DB8:0:1::/64
2001:0DB8:0000:0002::/64 => 2001:0DB8:0:2::/64
...
2001:0DB8:0000:000F::/64 => 2001:0DB8:0:F::/64
2001:0DB8:0000:0010::/64 => 2001:0DB8:0:10::/64
...
2001:0DB8:0000:001F::/64 => 2001:0DB8:0:1F::/64
2001:0DB8:0000:0020::/64 => 2001:0DB8:0:20::/64
...
2001:0DB8:0000:FFFF::/64 => 2001:0DB8:0:FFFF::/64

 

Supondo que o primeiro bloco /64 seja utilizado na empresa detentora do /32, tem-se os seguintes IPs, disponíveis:

2001:0DB8:0000:0000:0000:0000:0000:0000 => 2001:0DB8::/64
2001:0DB8:0000:0000:0000:0000:0000:0001 => 2001:0DB8::1/64
2001:0DB8:0000:0000:0000:0000:0000:0002 => 2001:0DB8::2/64
...
2001:0DB8:0000:0000:0000:0000:0000:000F => 2001:0DB8::F/64
2001:0DB8:0000:0000:0000:0000:0000:0010 => 2001:0DB8::10/64
2001:0DB8:0000:0000:0000:0000:0000:0011 => 2001:0DB8::11/64
...
2001:0DB8:0000:0000:FFFF:FFFF:FFFF:FFFF => 2001:0DB8::FFFF:FFFF:FFFF:FFFF/64

 

Intocável o prefixo 2001:0DB8:0000:0000, portanto! O ambiente que for o “dono” do bloco /64, com seu intocável prefixo de 64 bits pode dividir em outras redes com prefixos maiores: /65, /66/, /67, …, /128. O GDEI recomenda cuidados ao dividir em blocos menores (ou prefixos maiores), do que /64.

Variações do tema

Pode-se usar metade da Seta para documentar as redes que são distribuídas. Se necessário adicionar segmentos da parte de baixo da linha divisória. Se já tem-se a Seta completa, então:

abcd:efgh::/32
 abcd:efgh::/33
  abcd:efgh::/34
   abcd:efgh::/35
    abcd:efgh::/36
     abcd:efgh::/37
      abcd:efgh::/38
       abcd:efgh::/39
        abcd:efgh::/40
         abcd:efgh::/41
          abcd:efgh::/42
           abcd:efgh::/43
            abcd:efgh::/44
             abcd:efgh::/45 
              abcd:efgh::/46
               abcd:efgh::/47
                abcd:efgh::/48

 

Ou quem sabe, começar a documentação a partir de simplesmente:

abcd:efgh::/48

 

e, continuar:

abcd:efgh:0000::/48 - Rede Interna
abcd:efgh:0001::/48 - Reservado
abcd:efgh:0002::/48 - Cliente 1
abcd:efgh:0003::/48 - Reservado
abcd:efgh:0004::/48 - Cliente 2
abcd:efgh:0005::/48 - Reservado
abcd:efgh:0006::/48 - Cliente 3
abcd:efgh:0007::/48 - Reservado
abcd:efgh:0008::/48 - Cliente 4
abcd:efgh:0009::/48 - Reservado
abcd:efgh:000A::/48 - Cliente 5
abcd:efgh:000B::/48 - Reservado
abcd:efgh:000C::/48 - Cliente 6
abcd:efgh:000D::/48 - Reservado
abcd:efgh:000E::/48 - Cliente 7
abcd:efgh:000F::/48 - Reservado
...

 

São 65.536 redes /48. No esquema acima, dá-se ao luxo de reservar as redes ímpares para futuras demandas, e quem sabe, garantir agregação. Se 32.768 redes não satisfaz a demanda, com criatividade pode-se encontrar outra arrumação. De qualquer forma, o esquema acima é uma das possibilidades, entre muitas outras. Por exemplo, deixar duas redes de reservas em cada sequência de distribuição. Ou quatro…

A Internet agradece as preocupações com a agregação.

A propósito, a Seta IPv6 é uma metáfora, puramente, didática!

Categorias:BGP, IPv6, TCP/IP

BGP no Mikrotik (VIII): Alterando a política de roteamento

Dai ao roteador o que é do roteador e ao firewall o que é do firewall.
Autor desconhecido


Atualizado em: 03/11/2012: Inclusão da foto do Moreiras, registrando seu competente trabalho na implementação do IPv6, no Brasil, junto com sua Equipe.
Atualizado em: 10/04/2011: Inclusão da referência 10 relacionada com rota ping-pong.

Introdução

As razões pelas quais nos levam a alterar a política de roteamento, criada originalmente pelo BGP podem ser classificadas nas seguintes categorias:

  • Interesses internos ao Sistema Autônomo
  • Interesses bilaterias do empareamento
  • Interesses multilaterais do empareamento
  • Segurança das sessões BGP

Os recursos disponíveis para alterar a política de roteamento, nas categorias acima são:

  • Manipulação de atributos
  • Estabelecimentos de filtros

Manipulação de atributos

No texto anterior (Parte VII) vimos um exemplo, no qual o atributo allow_as_in foi usado para alterar (ou forçar) o rumo do tráfego. Naquele exemplo a política do BGP, ao usarmos allow_as_in no BGP que fala MK6, era o melhor caminho, através do MK7. Ao retirarmos o atributo allow_as_in do empareamento com o MK7, o tráfego passou a ser encaminhado através do MK5. Em textos anteriores lembramos o uso de outros parâmetros, como o as_path, através do qual inibimos (isto é, bloqueamos), tráfego vindo de MK1 na direção de MK2. Oportunamente veremos atributos poderosos e transitivos* (ultrapassam a barreira da limitação hop_by_hop), como comunidades e confederações. Manipulação de atributos do BGP para alterar políticas de roteamento dependem, demasiadamente, do conhecimento e sobretudo, da experiência do administrador do AS. Um dos componentes mais complexos do BGP!

Filtros em BGP

Filtros representam uma poderosa opção para alterar política de roteamento e, em particular, são muito utilizados para garantir segurança do BGP que fala (ou roteador de borda), seus dependentes e seus vizinhos. Quando falamos em segurança, há uma natural confusão com firewall. Embora filtro no BGP seja uma forma de firewall, não podemos confundir as duas técnicas. Filtro é mais especializado, no sentido de que é um recurso do BGP, direcionado a alterações de roteamento (isto é, manipulação da tabela de roteamento), seja por interesse específico do administrador do AS ou por razões de segurança. É de uso imediado e mais fácil do que firewall. Nada mais verdadeiro do que a máxima citada no início deste texto.

 



* A transitividade é opcional no BGP. Pode ou não ser reconhecida por alguns BGPs que falam. A transitividade é preservados e anunciados para todos os empareados vizinhos, através de mensagens UPDATE e nela permanecerá enquanto durar. ([2]).


 

Relacionamentos bilaterais e multilaterais no BGP

Face a restrição do mecanismo hop-by-hop os relacionamentos entre BGPs que falam só existem, automaticamente, com outros BGPs que falam vizinhos.

Atributos transitivos podem ser usados para relacionamento entre BGPs que falam não vizinhos. Devemos lembrar, entretanto, que em ambos os casos (vizinhos e não vizinhos), geralmente é necessário contato com os respectivos administradores uma vez que atributos transitivos não são obrigatórios. Mas são mantidos, nas mensagens de UPDATE do BGP.

A forte integração entre os BGPs que falam empareados contrasta com a falta de integração com os outros, não vizinhos. Não fosse isso, muitos dos problemas da Infraestrutura da Internet estariam resolvidos, tal como o sequestro de IPs, por exemplo. Existem vários recursos disponíveis para aliviar a falta de integração entre administradores de ASes. Entre eles, se destacam:

  • O telefone do INOC, uma iniciativa do PCH (Packet Clearing House), que o Nic.br oferece gratuitamente para todos os ASes brasileiros e iniciativas semelhantes existem no mundo inteiro. Há uma lista disponível no sítio do PCH (http://www.pch.net). Infelizmente, muitos ASes brasileiros nem sabem de tal facilidade e, pior, a grande maioria dos telefones existentes, não funcionam. No Brasil, provavelmente será necessário intervensão forte do Nic.br, para o uso eficaz e, divulgação intensiva sobre o propósito do INOC.
  • O IRR, cujas informações detalhadas podem ser encontradas em http://irr.abranet.org.br (primeira base de IRR brasileira, neutra e de uso gratuíto). Um instrumento poderoso de relacionamento constituido de bases de dados distribuidas, onde os administradores de ASes inserem suas políticas de roteamento, que se tornam disponíveis para outros administradores de ASes. Apesar de sua genialidade o IRR sofre pelo desprezo/desinteresse dos administradores de ASes e não em sido usado de maneira eficiente e eficaz.
  • Outras bases de integração tais como: Whois, LG (Looking Glass), PeeringDB (do PCH), RIS, BGPMon, CIDR Report, BGP Update Report, Weekly Routing Table Report e outras reconhecidas pela comunidade internacional. Boa parte delas podem ser usadas para apoio ao monitoramento necessário aos administradores de ASes, também.

Etapas para o uso de filtros, em BGP

Cada administrador de AS tem seu próprio estilo ou acaba tendo um estilo próprio, para administrar e cuidar de seu Sistema Autônomo. Geralmente isso é o que vale. Mas, o ser humano precisa de ajuda. Há discursões filosóficas dizendo que vivemos sob uma lógica perversa: o que não sabemos é mais relevante do que sabemos** e, também, só aprendemos o que já conhecemos. Nossas experiências pessoais comprovam isso. Quantas vezes não temos de ler um artigo (técnico, principalmente), várias vezes, para entendermos com segurança um assunto novo?

Também para nós, administradores de AS, o imponderável é mais importante do que o previsível. Quando se trata do BGP, o imponderável pode ser, uma falha involuntária causada por um administrador (experiente ou inexperiente), por exemplo***.

Achamos que é sempre bom lembrar, face à complexidade do BGP, cinco tópicos importantes quando formos estabelecer um BGP que fala:

  • Planejar
  • Documentar
  • Testar
  • Implementar
  • Monitorar

A seguir faremos rápidos comentários abordagem sobre cada um. Em mente o fato de que não estamos escrevendo um compêndio sobre administração de recursos. Como Infraestrutura da Internet é algo muito parecido com uma disciplina da Logística, denominada “PCP – Planejamento e Controle da Produção”, a base do debate foi retirada e adaptada de [4], um texto suave, completo e fácil de ler/entender. A motivação é a aprendizagem: onde podemos encontrar recursos/conhecimento que nos ajudem atravessar os cinco tópicos?

 



** É a lógica do Cisne Negro, proposta por Nassim Nicholas Taleb, em [3]. Parece ser, realmente, um interessante paradigma. Na recente (07/04/2011) e incompreensível tragédia que ocorreu na escola de Realengo, RJ o que nos interessa é avaliar nossa tradicional incapacidade de prever o curso da história. Se o episódio fosse por nós concebível, a polícia estaria logo cedo na escola. Segundo Taleb nossa fraqueza reside no fato não analizarmos os dados espúrios resultantes das estatísticas (outliers). Mas, Taleb, não consegue responder ao imponderável, ainda. Dor imensa e infinita, a Escola Municipal Tasso da Silveira, foi citada porque permanecerá presente, em nossa memória, pelo resto de nossos dias. É possível citar um exemplo específico e prático, associado ao Sequestro de IPs. O roteador que primeiro recebeu o anúncio de um possível sequestro, não deveria permitir a progressão da mensagem de UPDATE ou, marcaria a mensagem UPDATE como suspeita. Uma consulta (confiável). a uma base IRR (confiável) ou ao PeeringDB (confiável) assimilaria tal expectativa. Acabaríamos com os riscos inerentes ao Sequestro de IPs.


*** Outra ilustração que fortalece a noção do imponderável, no BGP é o que denominamos rota ping-pong (do inglês, route flapping). Rota ping-pong é o anúncio de prefixo e retirada desse anúncio, de forma repetitiva, pelo BGP que fala. Um exemplo que pode causar a rota ping-pong é a interrupção intermitente em uma interconexão do roteador de borda. A RFC4271, [1], no Apêndice F, recomenda que as implementações de BGP devem disponilizar mecanismos ao gerador da rota ping-pong (BGP que fala) para atenuar ou identificá-la. A RFC2439, [9] recomenda as técnicas para implementar. A rota ping-pong pode causar danos graves no processo de convergência do BGP, [5]. Os problemas gerados pela rota ping-pong podem ser graves a ponto de afetar a estabilidade da Internet. Tal fato tem levado a algumas intituições no estudo de problemas relacionados, usando uma metodologia denominada BGP Beacons e que se refere ao registro do comportamento de anúncios e retiradas de anúncios de prefixos, [6]. Tais comportamentos são registrados em bases de dados a partir da coleta de mensagens de UPDATE do BGP e disponibilizados para estudos, pesquisas e avanços na defesa do imponderável, em BGP, entre outros. Tais bases são geralmente públicas, como Oregon’s Route Views [7] e a base RIS, do RIPE Routing Service (em [8], para maiores informações). Vários fabricantes de roteadores implementaram mecanismos de prevenção contra rota ping-pong. Eles são chamados de route flap damping [9], ou route flap dampening, por alguns autores e, implementam um mecanismo de penalidades para anúncios que estejam provocando o que poderia vir a ser um ping-pong de prefixos. Tal mecanismo, avalia a frequência dos anúncios ou retiradas de anúncios, na tentativa de identificar se está ocorrendo excessos ou intermitência Até a data de publicação deste texto, não conseguimos referências precisas, de tais implementações no Mikrotik. Oportunamente haverá um texto a respeito do roteamento ping-pong e as bases de dados de BGP Beacons.


 

Planejamento

O Planejamento do BGP que fala é um bom momento para aumentar nosso conhecimento sobre o BGP. A sugestão é focar em dois pontos importantes:

  • Segurança
  • Filtros

Um dos melhores locais para ambas as alternativas acima é o sítio do Team-Cymru. Eis uma relação de material muito útil:

Outro excelente ambiente é o sítio do PCH. Responsável pelo INOC-DBA, possui um vasto material. Em particular iremos usar BGP Best Practices for ISPs Prefix List, AS PATH filters, Bogon Filters, Anycast, Mailing Lists, INOC DBA, referente a uma palestra dada por Gaurab Raj Upadhaya, do PCH, em um encontro da ARIN.

Destaque para documentos da Cisco, Juniper e outros. Todos úteis e interessantes. A Juniper tem um glossário excelente, que pode ser obtido aqui.

Documentação

O tipo de documentação em uma implementação de BGP é muito variada. Temos anotações sobre uso de IPs, Loopbacks (que um BGP que fala pode usar muito), e-mails, contratos de empareamento, senhas, acordos bilaterais e multilaterais. Para cada uma existe uma ferramente interessante. Uma ótima alternativa é o Zope+Plone. Há várias vantagens neste recurso: possui base de dados relacional, é fácil de mexer, tem um sistema de autenticação bastante sofisticado e um mecantismo de pesquisa poderoso e rápido.

O problema de ferramentas como o Plone acima é que estamos adicionando mais um componente que deve ser vigiado ou mantido, embora o Plone seja bastante estável e rode em Windows, *BSD e qualquer distribuição Linux. Muito fácil de instalar e usar. Já vimos exemplo de uso de sistemas de blogue como o WordPress instalado em uma máquina local ou blogue do Google, fechado e privativo. o Google Apps parece ser, uma ótima escolha, também.

Mas são sugestões já que o estilo e experiência de cada um irão conduzir as alternativas mais adequadas.

Teste

Há excelentes ferramentas de simulação de redes, com BGP, sob as quais podemos exercitar o que pensamos/planejamos em relação a uma implementação BGP. A melhor delas é sem dúvida a do pessoal do Nic.br responsável pelos cursos de IPv6. Aprende-se muitíssimo nos cursos de IPv6, ministrados pelo Antonio Moreiras, Rodrigo Santos e Equipe. Toda a documentação do laboratório e muitas outras excelentes informações podem ser encontradas no sítio do IPv6.br.

 

Com o Antônio “IPv6” Moreiras, no aeroporto de Montevidéu.
Retornando do LACNIC18.

Monitoramento

Uma ferramenta da Cisco muito interessante, mas com orientação restrita a seus roteadores e, limitações em relação ao BGP. Inclui, wireless e VoIP. Informações detalhadas estão aqui. Ele é distribuido gratuitamente!

O destaque fica com o FFE (Fábrica Fictícia de Encaminhamento ou 111111111110). O FFE está descrito aqui neste blogue e a grande vantagem está na simplicidade de implementação, diversidade e escalabilidade. O FFE já tem roteadores Cisco, 3Com, Quagga, Mikrotik e outros planejados. Sua integração remota é um dos pontos fortes. Ele foi desenhado tendo como base a experiência no laboratório do Nic.br e no espírito do projeto Geni, guardada as devidas proporções! O FFE tem sido muito útil no desenvolvimento dos textos sobre BGP no Mikrotik, em testes e deve sua principal motivação em um projeto de aplicação da Logística na Infraestrutura da Internet. O FFE possui licença CrativeCommons, assim como tudo o que se apresenta de original aqui no blogue de Infraestrutura da Internet.

Implementação

A implementação concentrará, nos filtros do BGP, já que a implementação do BGP, em si, já foi abordada. Virá nos artigos subsequentes, com o objetivo de evitar textos longos e maçantes. A base para pensar nos filtros foi descrita faltando a abordagem sobre a tecnologia de uso dos roteadores para que eles sejam implementados. Em particular, do Mikrotik.

Monitoramento de nossa implementação de BGP difere das formas tradicionais que usamos para monitorar conexões e conectividade nas implementações tradicionais. Nossa implementação BGP precisa ser olhada, também, nos confins da Internet, fora de nosso limite de ação.

Eis as ferramentas recomendadas:

  • Diversas ferramentas disponíveis para implementações locais: http://www.bgp4.as/tools
  • LG (Lookin Glass):
  • MyASN: É um serviço oferecido pelo RIPE, como um alarme para acontecimentos anormais em relação a um AS específico e seus prefixos. Informações em: http://ttm.ripe.net/alarms/docs.
  • BGPMon: É um outro serviço de monitoramento de AS e prefixos. Semelhante ao MyASN. Informações em: http://bgpmon.net/.
  • Route Views: Um dos mais famosos coletores é o University of Oregon Route Views Project, que atualmente estabeleceu um coletor no PTTMetro-SP: http://www.routeviews.org/saopaulo.html. Na realidade existem coletores espalhados pelo mundo inteiro onde os interessados em ajudar, estabelecem um empareamento. O caso de São Paulo, no PTT-Metro o esquema difere, pois a coleta é direta no RouteServer.
  • PeeringDB: É uma base de dados de ASes interessados em registrar seus empareamentos e outras informações sobre políticas de roteamento. Um AS, assim que estabelecer um empareamento via BGP deve se cadastrar no PeeringDB, tamanha sua importância como recurso de pesquisa e monitoramento. Informações: http://www.peeringdb.com.
  • The CIDR Report: Interessante ferramenta de pesquisa e monitoramento mantida pelo Geoff Huston. http://www.cidr-report.org/as2.0/. Semanalmente ele publica em algumas listas, um resumo das atividades da Internet no mundo. O documento é postado nesse blogue, também toda semana. Geoff Huston mantem um outro sítio muito interssante: http://www.potaroo.net/.
  • Weekly Routing Report: Relatório estatística e semanal que também é postado no blogue de Infraestrutura da Internet oritinado pelo roteador do APNIC no Japão. Dados históricos podem ser encontrados aqui: http://thyme.rand.apnic.net
  • BGP Update Report: Outra iniciativa do Geoff Huston, semanalmente postado no blogue Infraestrutura da Internet e maiores informações podem ser obtidas aqui: http://bgpupdates.potaroo.net
  • Robtex: Outra alternativa ao CIDR-Report: http://www.robtex.com/

Naturalmente existem outras referências que já existem ou foram criadas. Sempre que possível, manteremos atualizada a lista acima. Algumas não merecem, entretanto o registro. Essas faremos comentários precisos, como anunciado em epílogos de alguns dos textos do blogue na oportunidade de nossa abordagem sobre Sequestro de IPs. Infelizmente, serão abordagens inusitadamente desagradáveis, mas que não podem deixar de ser expostas, face a origem de suas iniciativas e os danos provocados.

Referências

  1. 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).
  2. Russ White, Danny McPherson, Srihari Sangli, Practical BGP, Jul 6, 2004,Addison-Wesley Professional.
  3. Nassim Nicholas Taleb, A lógica do Cisne Negro – O Impacto do altamente improvável. Editora Best Seller.
  4. Idalberto Chiavenato, Planejamento e Controle de Produção. Manole 2008.
  5. Julião Braga, Convergência, no BGP. Infraestrutura da Internet em 20/01/2011. Disponível em: https://juliaobraga.wordpress.com/2011/01/20/convergencia-no-bgp/. Acessado em 09/04/2011, 09:32.
  6. Z. Morley Mao, Randy Bushy, Timothy G. Griffinz, Matthew Roughanx, BGP Beacons.IMC ’03 Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement ACM New York, NY, USA ©2003.
  7. University of Oregon Route Views Archive Project. Disponível em: http://www.routeviews.org. Acessado em 09/04/2011, 10:41.
  8. Erik Romijn, Routing Information Service (RIS) raw Dataset. Disponível em: http://labs.ripe.net/datarepository/data-sets/routing-information-service-ris-raw-data-set. Acessado em 09/04/2011, 10:41.
  9. RFC2439, BGP Route Flap Damping C. Villamizar, R. Chandra, R. Govindan [ November 1998 ] (TXT = 86376) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  10. Christian Panigl, Joachim Schmitz, Philip Smith, Cristina Vistoli, RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parametershttp (RIPE-229). Disponível em: http://ftp.bme.hu/documents/ripe/ripe-229.txt. Acessado em 10/04/2011 08:28.