Arquivo

Archive for the ‘Protocolos’ Category

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
%d blogueiros gostam disto: