Arquivo

Archive for the ‘Peering’ Category

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.

Anúncios

Convergência, no BGP

Introdução

Convergência é um problema relacionado com o tempo em que toda uma rede se estabiliza após a ocorrência de um evento qualquer. Rede no contexto desse artigo é, a Internet.

Sabemos que logo na infância da Internet, ela foi dividida em sub-redes não isoladas, cada uma identificada e denominada Sistema Autônomo (AS, de Autonomous System). O objetivo foi o de facilitar a entrega de pacotes ou o roteamento dos pacotes da origem para o destino. Pouco tempo depois, foi criado um protocolo, conhecido por todos nós, o BGP (Border Gateway Protocol) com o objetivo de facilitar o mecanismo de roteamento entre os ASes (nos livrar do processo manual de estabelecer as rotas estáticas. O BGP, em sua versão original mostrou-se frágil diante da velocidade do crescimento da a Internet e antes dela se tornar de uso geral ou “comercial” (em 1993), já havia uma nova versão do BGP na praça: o BGP-4. Interessante lembrar, um fato histórico: o AS veio antes do BGP!

O BGP-4, apesar de ser um protocolo robusto começou a apresentar algumas deficiências de origem. Uma delas, impossível de solucionar sem alterações radicais é a sua estratégia de roteamento: hop-by-hop. De uma forma simples, no BGP, um parceiro (“peer”) só sabe o que acontece na Internet através de seus vizinhos imediatos. Parceiro nesse caso é um AS e, tambem, os vizinhos o são. Vamos imaginar o tamanho da Internet e, por razões de simplicidade, usar a Figura 1 para modelar a Internet. A Figura 1 foi retirada do artigo de Russ WhiteWhite, escrito em 2005, com o objetivo de propor uma solução para a questão do tempo de convergência do BGP-4 sob a ótica da estratégia hop-by-hop.

Exemplo de convegência no BGP

Figura 1. Ilustração do problema da convergência no BGPWhite

O problema da convergência

Na figura de Russ White os números dentro dos círculos representam ASes, de 1 a 12. A figura representa uma pequena rede de 12 ASes deve ser extrapolada para a Internet, com mais de 35.000 ASes (isto é, nós como os da pequena figura). A escolha da figura do trabalho de Russ White é simplesmente uma aplicação da navalha de OccamOccam. É de uma genialidade e simplicidade sem igual.

Na figura, vamos supor que o AS12 anuncia o bloco 10.1.1.0/24. Se AS12 anuncia esse bloco, ele é o único na rede que sabe como atingí-lo. Assim, o AS1 para enviar um pacote para um IP do bloco 10.1.1.0/24, o caminho deve seguir a direção do AS12. Vamos supor que AS1 atinja o bloco, com o menor caminho [AS6, AS12]. Muito embora, na tabela de roteamento de AS1, esteja a informação de que ele poderia enviar pelo caminho [AS2, AS9, AS12], por exemplo. A escolha pode não ser pelo menor caminho. Há vários parâmetros que podem afetar a escolhaCisco. Lembramos que caminho é o mesmo que ASPath, no BGP.

Eis um problema de convergência: suponha que o AS12 pare de anunciar o bloco 10.1.1.0/24, subitamente. Como AS12 era o único que sabia onde chegar aos IPs do bloco fatídico, o que ocorre com as informações na tabela de roteamento de AS1? Ops! O que acontece na Internet, quando ocorre uma falha dessa natureza?

Analisando o problema da convergência

Na tabela que segue, vamos exibir o caminho escolhido (escolha arbritrária!), por cada AS para chegar ao bloco 10.1.1.0/24:

AS Caminho
AS1 [AS6, AS12]
AS2 [AS9, AS12]
AS3 [AS7, AS10, AS12]
AS4 [AS5, AS8, AS11, AS12]
AS5 [AS8, AS11, AS12]
AS6 [AS12]
AS7 [AS10, AS12]
AS8 [AS11, AS12]
AS9 [AS12]
AS10 [AS12]
AS11 [AS12]

Vamos supor que AS12 não saiba mais como chegar ao bloco 10.1.1.0/24. O AS12 envia uma mensagem BGP para todos seus vizinhos, AS6, AS9, AS10 e AS11 retirarem o referido anúncio. Esses vizinhos, imeditatamente avisam seus respectivos vizinhos para retirarem o anúncio do bloco 10.1.1.0/24. No mesmo momento, recebem essa mensagem: AS1, AS2, AS7 e AS8. Então, AS1, ao receber seu primeiro pedido de retirada do bloco, analisa sua tabela de rotas locais e procura pelo próximo melhor caminho. Como ele não recebeu ainda nenhuma mensagem de retirada do AS2, ele muda a tabela para o outro caminho, digamos [AS3, AS7, AS10, AS12] e continua a enviar pacotes para o bloco 10.1.1.0/24.

Nesse momento, AS2, AS7 e AS8 enviam mensagens de retirada para seus parceiros vizinhos: AS1, AS3 e AS5. AS1 recebe uma nova mensagem de retirada e procura outra rota continuando a enviar tráfego para o bloco 10.1.1.0/24, pois ele tem uma outra rota, [AS3, AS7, AS12] já que seu vizinho AS3 não lhe disse nada.

Na sequência, AS3 e AS5 pedem a retirada a seus vizinhos, AS1 e AS4. E, AS1, novamente altera sua tabela, descobrindo outro caminho, [AS4,AS5,AS8,AS11,AS12] e encaminha pacotes para o bloco 10.1.1.0/24, sem saber que AS4 acabou de receber a mensagem de retirada.

Finalmente, AS4 envia a mensagem de retirada a AS1 que agora remove a última informação sobre como chegar ao bloco 10.1.1.0/24. Então para de encaminhar pacotes para esse bloco. Finalmente! Nesse ponto, a pequena rede converge. Ops! Queríamos dizer, a Internet, presumivelmente, converge.

Conclusões e Atualizações

Assim funciona o esquema da convergência do BGP. De tempos em tempos aparecem recomendações para alterações no BGP que são aceitas e virão na próxima versão. Como por exemplo, a sugestão que motiva o artigo de Russ White, onde ele recomendou que quando o AS1 recebesse a primeira mensagem de retirada, do seu vizinho AS6, ele pesquisaria toda a sua tabela de rotas, localmente e retiraria as referências ao bloco 10.1.1.0/24, evitando tráfego inútil.

Algum tempo depois de escrito esse pequeno artigo, encontrei uma referência bem mais completa na Internet Lapukhov, que recomendo aos interessados.

Em 14/02/2011, Vasco Asturiano fez um experimento e exibiu alguns gráficos relacionados com a convergência do BGP quando se anunciava e retirava o anúncio de um prefixo Asturiano. Muito interessante o artigo, onde ele conclui que é mais fácil (~rápido), para o BGP, a convergência quando se anuncia um prefixo, do que a convergência quando se retira o anúncio de um prefixo.

Em 19/07/2013, Randy Busch escreveu um curto e-mail na lista, com algumas frase interessantes, entre as quais: “global bgp never converges (and how would you know if it did?)“. Lembrando-me deste artigo e a última frase no final da seção anterior, onde dizia que a “…a Internet, presumivelmente, converge” escrevi um e-mail para Randy dizendo-lhe que achei muito interessante a sua frase. Gentilmente, ele retornou-me com a indicação do artigo [Roughan, Willinger, Maennel, Perouli & Bush]. É um texto imperdível! Com uma imensa referência, cito abaixo o último parágrafo, com a promessa de brevemente fazer uma resenha aqui no blogue:

The lessons of this paper will hopefully form a checklist for any student or new researcher in this area that will enable them to avoid the pitfalls which have reduced the value of some past research. Simply stated, to ensure value of future research in this area, any work on the structure and evolution of the Internet’s Autonomous System has to account for the economic, technological, and social forces that shape this critical element of the Internet.

Referências

White, Russ, Graph Overlays on Path Vector: A Possible Next Step in BGP, The Internet Protocol Journal, Volume 8, Number 2, Junho 2005. Disponível em http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-2/graph_overlays.html. Acessado em: 20/01/2011.

Wikipedia, Navalha de Occam. Disponível em http://pt.wikipedia.org/wiki/Navalha_de_Occam. Acessado em: 20/01/2011.

Cisco, BGP Best Path Selection Algorithm. Disponível em: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml#bestpath. Acessado em: 27/01/2011.

Petr Lapukhov, Understanding BGP Convergence. Disponível em: http://blog.ine.com/2010/11/22/understanding-bgp-convergence/. Acessado em: 27/01/2011.

Vasco Asturiano, The Shape of a BGP Update. Disponível em: http://labs.ripe.net/Members/vastur/the-shape-of-a-bgp-update. Acessado em: 14/02/2011.

Matthew Roughan, Walter Willinger, Olaf Maennel, Debbie Perouli, and Randy Bush. 10 Lessons from 10 Years of Measuring and Modeling the Internet’s Autonomous Systems. IEEE Journal on Selected Areas in Communications, Vol. 29, No. 9, October 2011.

Categorias:BGP, Peering, Protocolos, TCP/IP

Laboratório virtual de roteamento – LVR (I)

Atualizado em: 30/01/2011.

Introdução

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

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

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

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

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

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

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

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

O modelo do LVR

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

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

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

Figura 2. Abstraindo-se das interconexões.

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

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

Figura 3. Construindo as VLANs.

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

Próximas atividades

Eis alguma das próximas atividades sobre o LVR:

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

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

Referências

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

Curso IRR – Parte X: Relações entre objetos

Introdução

A figura 3, abaixo representa um cenário onde \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } estabeleceram um enlace privativo (em vermelho), através de um acordo bilateral :

 

Figura 1: Um enlace privativo no cenário.

 

Ao desenvolver as políticas de roteamento para o cenário da figura 1, duas novidades aparecem. A primeira delas é o uso de ações nos atributos import e export do objeto aut-num. No exemplo abaixo, a ação utilizada é pref de preference, parâmetro já nosso conhecido, do BGP4. Ações e outros parâmetros permitidos nos atributos atributos serão discutidos formalmente nos segmentos da sequência desse treinamento. A outra novidade, na realidade é uma questão que aparece associada a possíveis inconsistências, ao definir ou projetar as políticas de roteamento. No contexto em que aparece uma inconsistência será elaborada uma orientação. Eis as políticas possíveis e suas especificações para o IRR, no cenário da figura 1:

  1. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Esse tráfego nunca poderá passar por \textbf{AS} _ \textbf{w }. Além disso, o enlace privativo nunca poderia ser usado para trânsito, originado de \textbf{AS} _ \textbf{x } e de \textbf{AS} _ \textbf{y }. Eis como ficariam os objetos aut-num para cada um dos \textbf{ASes}:
       aut-num:   \textbf{AS} _ \textbf{x }
       as-name:   \textbf{AS} _ \textbf{x }-NET
       descr:     \textbf{AS} _ \textbf{x }Autonomous System
       remarks:   ===============================================
       remarks:   http://www.exemplo.com.br
       remarks:   ===============================================
       remarks:   Security Note
       remarks:   Any Notification about \textbf{AS} _ \textbf{x } security please
       remarks:   e-mail to: asx.ABUSE@exemplo.com.br
       remarks:   ===============================================
       import:    from \textbf{AS} _ \textbf{w } action pref = 100; accept NOT \textbf{AS} _ \textbf{y }
       export:    to \textbf{AS} _ \textbf{w } announce \textbf{AS} _ \textbf{x }
       import:    from \textbf{AS} _ \textbf{y } action pref = 50; accept \textbf{AS} _ \textbf{y }
       export:    to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
       admin-c:   IDASx-NICBR
       tech-c:    IDASx-NICBR
       notify:    asx-admin@exemplo.com.br
       mnt-by:    MAINT-\textbf{AS} _ \textbf{x }
       changed:   asx-admin@exemplo.com.br
       remarks:   **************************
       remarks:   Test only.
       remarks:   **************************
       source:    PEGASUS
       password:  senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{x }
    
       aut-num:   \textbf{AS} _ \textbf{w }
       ...
       import:    from \textbf{AS} _ \textbf{x } action pref = 100; accept \textbf{AS} _ \textbf{x }
       export:    to \textbf{AS} _ \textbf{x } announce ANY
       import:    from \textbf{AS} _ \textbf{y } action pref = 100; accept \textbf{AS} _ \textbf{y }
       export:    to \textbf{AS} _ \textbf{y } announce ANY
       ...
       
    
       aut-num:   \textbf{AS} _ \textbf{y }
       ...
       import:    from \textbf{AS} _ \textbf{w } pref = 100; accept NOT \textbf{AS} _ \textbf{x }
       export:    to \textbf{AS} _ \textbf{w } announce \textbf{AS} _ \textbf{y }
       import:    from \textbf{AS} _ \textbf{x } action pref = 50; accept \textbf{AS} _ \textbf{x }
       export:    to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }
       ...
    
    

    Olhando a política definida para o \textbf{AS} _ \textbf{w } há uma visível inconsistência: ele anuncia \textbf{AS} _ \textbf{x } para \textbf{AS} _ \textbf{y } (export: to \textbf{AS} _ \textbf{y } announce ANY) e, também, anuncia \textbf{AS} _ \textbf{y } para \textbf{AS} _ \textbf{x } (export: to \textbf{AS} _ \textbf{x } announce ANY). Tal inconsistência está sendo resolvida nas políticas de \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, respectivamente, com o uso da ação accept NOT, em um claro relacionamento entre objetos (nesse caso, uma inter-relação entre três objetos aut-num). Mas, quem está definindo a política é um ser humano e, consequentemente, muito sujeito a erros. Sobretudo, se a política for complexa! Felizmente, as ferramentas, cujas abordagens serão feitas nos próximos segmentos auxiliam-nos na tarefa de analisar a consistência de cada objeto e respectivos relacionamentos. O que elimina as preocupações associadas a consistências (ou inconsistências).

  2. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o enlace privativo falhar, a troca de tráfego entre \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } poderia ser feita via \textbf{AS} _ \textbf{w }. Mas nunca, os enlaces para \textbf{AS} _ \textbf{w } poderiam ser usados para trânsito.Eis como ficariam os objetos aut-num para cada um dos \textbf{ASes}:
       aut-num:   \textbf{AS}_\textbf{x }
       ...
       import:  from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       export:    to \textbf{AS}_\textbf{w } announce \textbf{AS}_\textbf{x }
       import:  from \textbf{AS}_\textbf{y } action pref = 50; accept \textbf{AS}_\textbf{y }
       export:    \textbf{AS} _ \textbf{x } \textbf{AS} _ \textbf{y }
       ...
    
       aut-num:   \textbf{AS}_\textbf{w }
       ...
       import:  from \textbf{AS} _ \textbf{x } action pref = 100; accept \textbf{AS} _ \textbf{x }
       export:    \textbf{AS} _ \textbf{x } announce ANY
       import:  from \textbf{AS}_\textbf{y } action pref = 100; accept \textbf{AS}_\textbf{y }
       export:    to \textbf{AS}_\textbf{y } announce ANY
       
       ...
    
       aut-num:   \textbf{AS}_\textbf{y }
       ...
       import:  from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       export:    to \textbf{AS} _ \textbf{w } announce \textbf{AS}_\textbf{y }
       import:  from \textbf{AS}_\textbf{x } action pref = 50; accept \textbf{AS}_\textbf{x }
       export:    to \textbf{AS}_\textbf{x } announce \textbf{AS}_\textbf{y }
       ...
    

    Neste exemplo, ao imaginar as politicas operacionais, \textbf{AS}_\textbf{x } receberá anúncios de \textbf{AS}_\textbf{y } tanto do \textbf{AS} _ \textbf{w } como do \textbf{AS}_\textbf{y }. No caso específico do anúncio para \textbf{AS}_\textbf{y }, a preferência é de menor custo, permitindo o uso do enlace privativo sempre que for necessário (tráfego de demanda entre eles), exceto tráfego de trânsito se falhar um dos respectivos enlaces com \textbf{AS} _ \textbf{w } pois, esse não aceita anúncio de um via o outro.

  3. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o enlace privativo falhar, a troca de tráfego entre \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } poderia ser feita via \textbf{AS} _ \textbf{w }. Se a conexão entre \textbf{AS} _ \textbf{y } e \textbf{AS} _ \textbf{w } falhar, o tráfego originado em \textbf{AS} _ \textbf{y }, o tráfego originado em \textbf{AS} _ \textbf{y } com objetivo de trânsito via \textbf{AS} _ \textbf{w } poderia usar o enlace privativo e a conexão de \textbf{AS} _ \textbf{x } com \textbf{AS} _ \textbf{w }.
       aut-num:  \textbf{AS} _ \textbf{x }
       ...
       import:   from \textbf{AS}_\textbf{w } action pref = 100; accept ANY
       export:   to \textbf{AS}_\textbf{w } announce \textbf{AS} _ \textbf{x }
       import:   from \textbf{AS}_\textbf{y } action pref = 50; accept \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{y } action pref = 110; accept ANY
       export:   to \textbf{AS}_\textbf{y } \textbf{AS} _ \textbf{x }
       ...
    
       aut-num:  \textbf{AS}_\textbf{w }
       import:   from \textbf{AS} _ \textbf{x } action pref = 1; accept \textbf{AS} _ \textbf{x }
       export:   to \textbf{AS} _ \textbf{x } announce ANY
       import:   from \textbf{AS}_\textbf{y } action pref = 1; accept \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{y } action pref = 2; accept \textbf{AS} _ \textbf{x }
       export:   to \textbf{AS}_\textbf{y } announce ANY
       
    
       aut-num:  \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{w } 100 accept ANY
       export:   to \textbf{AS}_\textbf{w } \textbf{AS}_\textbf{y } announce \textbf{AS} _ \textbf{x }
       import:   from \textbf{AS} _ \textbf{x } action pref = 50; accept \textbf{AS} _ \textbf{x }
       export:   to \textbf{AS} _ \textbf{x } announce ANY
    

    O exemplo ilustra a importância de propagar informação de roteamento em todas as direções quanto existir um cenário em que essa política é exigida. Não é usual conectividade em uma única direção. Para efeito do próximo exemplo, vale lembrar que se a conexão entre \textbf{AS}_\textbf{y } e \textbf{AS}_\textbf{w } falhar, \textbf{AS}_\textbf{y } terá seu tráfego de trânsito via \textbf{AS} _ \textbf{x } e, vice-versa.

  4. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o link privativo falhar, o tráfego entre \textbf{AS} _ \textbf{y } e \textbf{AS} _ \textbf{x } poderia ser roteado via \textbf{AS} _ \textbf{w }. Se tal enlace também falhar ele poderia passar através de outras conexões de trânsito (digamos, \textbf{AS} _ \textbf{z } com conexão com \textbf{AS}_\textbf{y } ).
       aut-num:  \textbf{AS}_\textbf{y }
       ...
       import:   from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       export:   to \textbf{AS} _ \textbf{w } announce \textbf{AS}_\textbf{y }
       import:   from \textbf{AS} _ \textbf{x } action pref = 50; accept \textbf{AS}_\textbf{y }
       import:   from \textbf{AS} _ \textbf{x } action pref = 110; accept ANY
       export:   to \textbf{AS} _ \textbf{x } \textbf{AS}_\textbf{y }
       ...
       source: PEGASUS
    
       aut-num:  \textbf{AS} _ \textbf{w }
       ...
       import:   from \textbf{AS}_\textbf{y } action pref = 1; accept \textbf{AS}_\textbf{y }
       export:   to \textbf{AS}_\textbf{y } announce ANY
       import:   from \textbf{AS} _ \textbf{x } action pref = 1; accept \textbf{AS} _ \textbf{x }
       import:   from \textbf{AS} _ \textbf{x } action pref = 2; accept \textbf{AS}_\textbf{y }
       export:   to \textbf{AS} _ \textbf{x } announce ANY
       ...
       source: PEGASUS
    
       aut-num:  \textbf{AS} _ \textbf{x }
       ...
       import:   from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       import:   from \textbf{AS} _ \textbf{z } action pref = 100; accept ANY
       export:   to \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{x } announce ASy
       export:   to \textbf{AS} _ \textbf{z } \textbf{AS} _ \textbf{x } announce \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{y } action pref = 50; accept \textbf{AS}_\textbf{y }
       export:   to \textbf{AS}_\textbf{y } announce ANY
       ...
       source: PEGASUS
    

    O exemplo acima é uma das variações alternativas. Fica como exercício imaginar outras.

Outros objetos

Os objetos do IRR relacionam-se entre si e há particularidades nesse relacionamento, dependendo dos objetos envolvidos. Nos próximos segmentos estaremos de uma maneira formal, descrevendo todos os objetos com base, principalmente, das referências [2] e [3].

Há uma boa referência no RIPE [4] onde uma interface amigável permite a criação de objetos, com ajuda, inclusive. Devemos lembrar duas coisas ao usar tal ferramenta: (a) não enviar o objeto para o RIPE e sim visualizá-lo e, (b) nem todos os objetos são compatíveis com as bases IRR tradicionais. Por exemplo, o objeto limerik, entre outros.

Manutenção do ASN no Registro.br

Esse segmento se baseou em [1] que foi atualizada por [2] e [3]. Mesmo assim é um excelente tutorial e recomenda-se para uma agressiva leitura. Ela é uma RFC tão útil que existe uma versão em português (de Portugal). Não perdeu sua utilidade entretanto. Para ver um exemplo que todos sempre procuram, começamos pelo whois -c br AS22548, do Nic.br. O resultado é o seguinte:

   aut-num:     AS22548
   owner:       Núcleo de Informação e Coordenação do Ponto BR
   ownerid:     005.506.560/0001-36
   responsible: Demi Getschko
   country:     BR
   owner-c:     FAN
   routing-c:   FAN
   abuse-c:     FAN
   created:     20011016
   changed:     20050531
   inetnum:     200.160.0/20
   inetnum:     2001:12ff::/32
   as-in:       from AS3549 100 accept ANY
   as-in:       from AS10429 100 accept ANY
   as-in:       from AS16735 100 accept ANY
   as-out:      to AS3549 announce AS22548
   as-out:      to AS10429 announce AS22548
   as-out:      to AS16735 announce AS22548

As linhas em negrito é que o que interessa nessa abordagem. Ela representa o que foi informado nos espaços correspondente a as-in e as-out do ambiente do ASN na área privativa do Registro.br. Está de acordo com a especificação da RFC1786, [1] e ainda não foi atualizada.

O aut-num do AS22548 está cadastrado no RADB e um whois -m AS22548, nos trás o seguinte:

   whois -m AS22548

   aut-num:    AS22548
   as-name:    REGISTROBRNET
   descr:      Registro.BR the .br registry
   import:     from AS3549   accept ANY
   import:     from AS10429   accept ANY
   import:     from AS16735   accept ANY
   import:     from AS112   accept AS112 AND {192.175.48.0/24}
   import:     from AS30122   accept AS30122 AND {192.228.80.0/24}
   import:     from AS30122   accept AS3557 AND {192.5.5.0/24}
   import:     from AS31529   accept AS31529 AND {194.246.96.0/24} AND {194.0.0.0/24}
   export:     to AS3549   announce AS22548 AND {200.160.0.0/20}
   export:     to AS3549   announce AS30122 AND {192.228.80.0/24}
   export:     to AS3549   announce AS31529 AND {194.246.96.0/24} AND {194.0.0.0/24}
   export:     to AS10429
               action community = { 10429:110 };
               announce AS22548 AND { 200.160.0.0/20 }
   export:     to AS10429
               action community = { 10429:110 };
               announce AS112 AND { 192.175.48.0/24 }
   export:     to AS10429
               action community = { 10429:110 };
               announce AS30122 AND { 192.228.80.0/24 }
   export:     to AS10429
               action community = { 10429:110 };
               announce AS31529 AND { 194.246.96.0/24 } AND { 194.0.0.0/24 }
   export:     to AS10429
               action community = { 10429:122 };
               announce AS3557 AND { 192.5.5.0/24 }
   export:     to AS16735   announce AS22548 AND {200.160.0.0/20}
   export:     to AS16735   announce AS112 AND {192.175.48.0/24}
   export:     to AS16735   announce AS30122 AND {192.228.80.0/24}
   export:     to AS16735   announce AS31529 AND {194.246.96.0/24} AND {194.0.0.0/24}
   export:     to AS16735
               action community = { 16735:900 };
               announce AS3557 AND { 192.5.5.0/24 }
   ...
   

A especificação das políticas do AS22548 no IRR está perfeita e já usa as recomendações da RFC2622, em [2]. Os atributos import e export representam, respectivamente, as-in e as-out, na nova sintaxe da RPSL, [2]. Assim, na área de informações do AS no Registro.br é construido com as políticas de roteamento do respectivo AS. Quase ninguém preenche tais espaços mas, o exemplo ilustra como deve ser feito.

O exemplo, ilustra, também uma política de roteamento quase completa (falta o IPv6). Olhar políticas já criadas no IRR é uma boa maneira de consolidar o conhecimento necessário.

Itens relacionados:

Referências do segmento

[1] RFC1786, Representation of IP Routing Policies in a Routing Registry (ripe-81++) T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu [ March 1995 ] (TXT = 133643) (Status: INFORMATIONAL) (Stream: Legacy)
[2] RFC2622, Routing Policy Specification Language (RPSL) C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra [ June 1999 ] (TXT = 140811) (Obsoletes RFC2280) (Updated-By RFC4012) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps)
[3] RFC4012, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates RFC2725, RFC2622) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP)
[4] Updating RIPE Database. Disponível aqui!

Categorias:BGP, IRR, Peering, Protocolos, TCP/IP, Whois

Curso IRR – Parte IX: objeto aut-num

Introdução

A referência [2] é uma descrição da RPSL (Routing Policy Specification Language) e foi atualizada por [3], que estende para IPv6. É uma linguagem muito poderosa, que permite aos administradores e operadores de redes especificarem políticas de roteamento em vários níveis e, escalável, ou seja, preparada para receber especificações de novos protocolos que, eventualmente, surjam no futuro. Finalmente, foi projetada com a expectativa de estabelecer políticas de roteamento globalmente que permitissem, cooperativamente, sua manutenção através de bases de dados distribuídas devidamente homologadas ou reconhecidas.

Definindo políticas de roteamento através da RPSL os administradores de ASes:

  • Melhorariam, cada vez mais, a integridade do roteamento na Internet.
  • Usariam ferramentas, que a partir do alto nível de especificação da RPSL, gerassem as configurações necessárias aos diversos roteadores disponíveis.
  • Teriam uma documentação de toda a política de roteamento, da topologia de suas redes e, fácil de ser lida, entendida e mantida, com visão de conjunto.
  • Teriam disponível uma linguagem baseada em objetos, que representam informações de política de roteamente e informações administrativas, extremamente importantes para todos os administradores de redes. Tais objetos são registrados no IRR por pessoas autorizadas.
  • Estariam confiantes (como consequência da cooperação), de que é uma ferramenta capaz de contribuir para que as configurações dos roteadores onde, a pouca intervenção humana protegeria adequadamente seus ambientes, de informações pouco precisas por motivações acidentais ou maliciosas. Vide [3].

As referências [1] e [2], são respeitadas pelos servidores do IRR, que fazem uma análise sintática e semântica sobre os atribustos e seus respectivos valores (como os compiladores). Mais recentemente, os servidores do IRR se ajustaram aos novos objetos propostos na RPSL e estão mais poderosos ao dar sustentação às ferramentas de manipulação das informações da base de dados do RADB (também, as homoladas – intermediárias – e, as privadas). Ganharam os administradores de ASes.

Recomenda-se a leitura do item 2 de [1]: “RPSL Names, Reserved Words, and Representation”.

O objeto aut-num

O objeto aut-num descreve as informações sobre um AS e suas políticas de roteamento, tanto sob o ponto de vista dos anúncios, como da aceitação de redes. Ele se aplica tanto ao IPv4 como ao IPv6.

Um dos mais importantes objetos de uma base IRR usa, intensivamente, a capacidade de relacionamento dos objetos, entre si. Alguns já vistos e outros a serem descritos nesse treinamento nos próximos segmentos. Assim, o objeto aut-num é combinado com o objeto que caracteriza o roteador (inet-rtr) e que fornece o número do sistema autônomo, indica as interfaces do roteador e que por sua vez é combinado com o objeto que mapeia os ASes envolvidos (as-set) e, finalmente se estendem aos objetos route(6) e route-set, dando segurança à informação dos prefixos que são anunciados. Os objetos as-set, route-set e inet-rtr serão discutidos nos próximos segmentos, mas podem ser encontrados em [1] e [2]

Os atributos do objeto aut-num

aut-num:        [obrigatório]  [único]      [primary/look-up key]
as-name:        [obrigatório]  [único]      [ ]
descr:          [obrigatório]  [único]      [ ]
member-of:      [opcional]     [multiplo]   [inverse key]
import:         [opcional]     [multiplo]   [ ]
export:         [opcional]     [multiplo]   [ ]
default:        [opcional]     [multiplo]   [ ]
remarks:        [opcional]     [multiplo]   [ ]
admin-c:        [obrigatório]  [multiplo]   [inverse key]
tech-c:         [obrigatório]  [multiplo]   [inverse key]
cross-mnt:      [opcional]     [multiplo]   [inverse key]
cross-nfy:      [opcional]     [multiplo]   [inverse key]
notify:         [opcional]     [multiplo]   [inverse key]
mnt-by:         [obrigatório]  [multiplo]   [inverse key]
changed:        [obrigatório]  [multiplo]   [ ]
source:         [obrigatório]  [único]      [ ]

Usando o objeto aut-num

No que segue, algumas adaptações foram feitas de [4].

Um cenário simples, para começar

A figura 1 exibe esse cenário simples e, razoavelmente comum:

Figura 1: Uma representação simples de uma conexão usando o BGP

Na figura 1, acima, a política de roteamento tendo em vista o conceito básico de anúncio e aceitação, para que dados da \textbf{Rede 1 } possam trafegar na direção da \textbf{Rede 2 } e vice-versa, está resumida nos seguintes pontos:

  1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{y }.
  2. \textbf{AS} _ \textbf{y } deve aceitar o anúncio de \textbf{AS} _ \textbf{x } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 2 } para a \textbf{Rede 1 }.
  3. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{x }.
  4. \textbf{AS} _ \textbf{x } deve aceitar o anúncio de \textbf{AS} _ \textbf{y } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 1 } para a \textbf{Rede 2 }.

O objeto aut-num é quem nos permitirá explicitar a política acima no IRR, através dos atributos import e export. Os respectivos objetos aut-num relativos aos sistemas autônomos \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, enviados para \textbf{email\_automatico@} \textbf{redepegasus.net.br} seriam:

aut-num:    \textbf{AS} _ \textbf{x }
as-name:    \textbf{AS} _ \textbf{x }-NET
descr:      \textbf{AS} _ \textbf{x } Autonomous System
remarks:    ===============================================
remarks:    http://www.exemplo.com.br
remarks:    ===============================================
remarks:    Security Note
remarks:    Any Notification about ASx security please
remarks:    e-mail to: asx.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
export:     to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
admin-c:    IDASx-NICBR
tech-c:     IDASx-NICBR
notify:     asx-admin@exemplo.com.br
mnt-by:     MAINT-\textbf{AS} _ \textbf{x }
changed:    asx-admin@exemplo.com.br
remarks:    **************************
remarks:    Test only.
remarks:    **************************
source:     PEGASUS
password:   senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{x }

aut-num:    \textbf{AS} _ \textbf{y }
as-name:    \textbf{AS} _ \textbf{y }-NET
descr:      \textbf{AS} _ \textbf{y } Autonomous System
remarks:    ===============================================
remarks:    http://www.exemplo.com.br
remarks:    ===============================================
remarks:    Security Note
remarks:    Any Notification about ASx security please
remarks:    e-mail to: asy.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:     to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
admin-c:    IDASy-NICBR
tech-c:     IDASy-NICBR
notify:     asy-admin@exemplo.com.br
mnt-by:     MAINT-\textbf{AS} _ \textbf{y }
changed:    asy-admin@exemplo.com.br
remarks:    **************************
remarks:    Test only.
remarks:    **************************
source:     PEGASUS
password:   senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{y }

Simplificando a apresentação

Para efeito didático, iremos suprimir os atributos já conhecidos e, assim, representaremos nosso objeto, da seguinte forma, com o nome de “Configuração”:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
...
aut-num: \textbf{AS} _ \textbf{y }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
...

Configuração 1. Cenário simples

Um cenário não tão simples

Vamos ampliar para o cenário representado na figura 2, abaixo, onde agora podemos identificar a Internet:

Figura 2. Um cenário não tão simples

Em tese são quatro, os administradores de ASes envolvidos nesse cenário. Pouco se conhecem e devem pensar de maneira independente. O caráter colaborativo do IRR, entretanto induz a pensarmos que cada um deles estará atento às especificações dos outros em relação à política de roteamento. Tal atenção ocorre de três maneiras: (a) pela pesquisa à base IRR em relação aos ASes que fazem “peering” (seja qual for o tipo de tráfego), (b) durante o uso das ferramentas de apoio (p.ex., RTConfig), momento em que possíveis inconsistências podem ser encontradas e, (c) através de ferramentas de monitoramento próprias ou de terceiros (p.ex., MyASN). Vale um comentário de que tais ferramentas estão cada vez mais interessantes e eficazes, com mudanças nos protocolos e nos equipamentos (em especial roteadores). Um dos indutores dessas transformações é a área de conhecimento que está sendo chamada de “route analytics”. Eis as observações que caracterizam a política de roteamento do cenário exibido na figura 2, sob o ponto de vista de cada um dos sistemas autônomos envolvidos:

  • Sob o ponto de vista do \textbf{AS} _ \textbf{w }:
    1. \textbf{AS} _ \textbf{w } fornece trânsito para \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }.
    2. \textbf{AS} _ \textbf{w } fornece rotas locais para \textbf{AS} _ \textbf{z }.
    3. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{x }.
    4. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para para o resto do mundo.
    5. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para \textbf{AS} _ \textbf{y }.
    6. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{y }.
    7. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para para o resto do mundo.
    8. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para \textbf{AS} _ \textbf{x }.
    9. \textbf{AS} _ \textbf{w } deve anunciar a rede do \textbf{AS} _ \textbf{y } para para o \textbf{AS} _ \textbf{z }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{x }
    1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{x } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{y }
    1. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{y } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{z }
    1. \textbf{AS} _ \textbf{z } deve aceitar todos os anúncios vindos de \textbf{AS} _ \textbf{w }.

O objeto aut-num sob a ótica do \textbf{AS} _ \textbf{w }

Vamos nos abstrair de alguns pontos da política de roteamento, nesse exemplo. Primeiro, não iremos definir a política para os itens 4 e 6. Isso porque nos falta algumas considerações sobre outros objetos e recursos dos respectivos atibutos. Portanto, deixaremos para abordar no próximo segmento. Segundo, não estamos interessados em em detalhes do \textbf{AS} _ \textbf{z } exceto o fato de que ele recebe anúncios do \textbf{AS} _ \textbf{w }.

Dito isso, eis o objeto aut-num para o \textbf{AS} _ \textbf{w }:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{x }
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{y }
import:  from \textbf{AS} _ \textbf{z } accept \textbf{AS} _ \textbf{z }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{z } announce \textbf{AS} _ \textbf{w }
...

Configuração 2. Sob a ótica do \textbf{AS} _ \textbf{w }

Uma pergunta que pode surgir, ao olhar a configuração 2 é: os anúncios de \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } já não fazem parte dos anúncios de \textbf{AS} _ \textbf{w }? Boa pergunta! Fica como exercício. Assim, também, os objetos aut-num para os demais ASes envolvidos.

Adicionando mais complexidade ao cenário

A figura 3, abaixo representa um cenário onde \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, através de um acordo bilateral estabeleceram um enlace privativo (em vermelho):

Figura 3: Um enlace privativo no cenário.

Iremos abordar esse novo cenário, na Parte X. A figura foi colocada antes, para se pensar sobre quais preocupações devem ser inseridas na política de roteamente. Por exemplo, se o enlace para o provedor de trânsito falhar, os \textbf{ASes} do acordo bilateral irão permitir o acesso ao trânsito pela conexão privativa?

Itens relacionados:

Referências do segmento

[1] \textbf{RFC2622}, Routing Policy Specification Language (RPSL) C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra [ June 1999 ] (TXT = 140811) (Obsoletes \textbf{RFC2280}) (Updated-By \textbf{RFC4012}) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[2] \textbf{RFC4012 }, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates \textbf{RFC2725 }, \textbf{RFC2622 }) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP).

[3] \textbf{RFC2725 }, Routing Policy System Security C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By \textbf{RFC4012 }) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[4] Wijayatunga, C. (Part I) e Upadhaya, G. R. (Part II), APNIC Internet Routing Registry Tutorial. Disponível em http://www.sanog.org/resources/sanog4-IRR-Tutorial-champs.pdf. Acessado em: 29/04/2010.

[5] Cisco, BGP Best Path Selection Algorithm. Disponível em: http://www.ciscopartner.biz/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml. Acessado em: 29/04/2010.

Categorias:IRR, Peering, Protocolos, TCP/IP, Whois