Introdução

A figura 3, abaixo representa um cenário onde e estabeleceram um enlace privativo (em vermelho), através de um acordo bilateral :

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. e gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Esse tráfego nunca poderá passar por . Além disso, o enlace privativo nunca poderia ser usado para trânsito, originado de e de . Eis como ficariam os objetos aut-num para cada um dos :

      aut-num:   
      as-name:   -NET
      descr:     Autonomous System
      remarks:   ===============================================
      remarks:   http://www.exemplo.com.br
      remarks:   ===============================================
      remarks:   Security Note
      remarks:   Any Notification about  security please
      remarks:   e-mail to: asx.ABUSE@exemplo.com.br
      remarks:   ===============================================
      import:    from  action pref = 100; accept NOT 
      export:    to  announce 
      import:    from  action pref = 50; accept 
      export:    to  announce 
      admin-c:   IDASx-NICBR
      tech-c:    IDASx-NICBR
      notify:    asx-admin@exemplo.com.br
      mnt-by:    MAINT-
      changed:   asx-admin@exemplo.com.br
      remarks:   **************************
      remarks:   Test only.
      remarks:   **************************
      source:    PEGASUS
      password:  senha_decriptografada_do_mantenedor_
   
      aut-num:   
      ...
      import:    from  action pref = 100; accept 
      export:    to  announce ANY
      import:    from  action pref = 100; accept 
      export:    to  announce ANY
      ...
      
   
      aut-num:   
      ...
      import:    from  pref = 100; accept NOT 
      export:    to  announce 
      import:    from  action pref = 50; accept 
      export:    to  announce 
      ...
   
   

   Olhando a política definida para o há uma visível inconsistência: ele anuncia para (export: to announce ANY) e, também, anuncia para (export: to announce ANY). Tal inconsistência está sendo resolvida nas políticas de e , 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. e gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o enlace privativo falhar, a troca de tráfego entre e poderia ser feita via . Mas nunca, os enlaces para poderiam ser usados para trânsito.Eis como ficariam os objetos aut-num para cada um dos :

      aut-num:   
      ...
      import:  from  action pref = 100; accept ANY
      export:    to  announce 
      import:  from  action pref = 50; accept 
      export:     
      ...
   
      aut-num:   
      ...
      import:  from  action pref = 100; accept 
      export:     announce ANY
      import:  from  action pref = 100; accept 
      export:    to  announce ANY
      
      ...
   
      aut-num:   
      ...
      import:  from  action pref = 100; accept ANY
      export:    to  announce 
      import:  from  action pref = 50; accept 
      export:    to  announce 
      ...
   

   Neste exemplo, ao imaginar as politicas operacionais, receberá anúncios de tanto do como do . No caso específico do anúncio para , 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 pois, esse não aceita anúncio de um via o outro.

3. e gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o enlace privativo falhar, a troca de tráfego entre e poderia ser feita via . Se a conexão entre e falhar, o tráfego originado em , o tráfego originado em com objetivo de trânsito via poderia usar o enlace privativo e a conexão de com .

      aut-num:  
      ...
      import:   from  action pref = 100; accept ANY
      export:   to  announce 
      import:   from  action pref = 50; accept 
      import:   from  action pref = 110; accept ANY
      export:   to  
      ...
   
      aut-num:  
      import:   from  action pref = 1; accept 
      export:   to  announce ANY
      import:   from  action pref = 1; accept 
      import:   from  action pref = 2; accept 
      export:   to  announce ANY
      
   
      aut-num:  
      import:   from  100 accept ANY
      export:   to   announce 
      import:   from  action pref = 50; accept 
      export:   to  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 e falhar, terá seu tráfego de trânsito via e, vice-versa.

4. e gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o link privativo falhar, o tráfego entre e poderia ser roteado via . Se tal enlace também falhar ele poderia passar através de outras conexões de trânsito (digamos, com conexão com ).

      aut-num:  
      ...
      import:   from  action pref = 100; accept ANY
      export:   to  announce 
      import:   from  action pref = 50; accept 
      import:   from  action pref = 110; accept ANY
      export:   to  
      ...
      source: PEGASUS
   
      aut-num:  
      ...
      import:   from  action pref = 1; accept 
      export:   to  announce ANY
      import:   from  action pref = 1; accept 
      import:   from  action pref = 2; accept 
      export:   to  announce ANY
      ...
      source: PEGASUS
   
      aut-num:  
      ...
      import:   from  action pref = 100; accept ANY
      import:   from  action pref = 100; accept ANY
      export:   to   announce ASy
      export:   to   announce 
      import:   from  action pref = 50; accept 
      export:   to  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:

• Curso IRR – Parte I: Introdução
• Curso IRR – Parte II: O que é o IRR
• Curso IRR – Parte III: Inserindo dados na base IRR
• Curso IRR – Parte IV: Exercitando o whois
• Curso IRR – Parte V: Objetos route e route6
• Curso IRR – Parte VI: Políticas de roteamento
• Curso IRR – Parte VII: Planos de roteamento
• Curso IRR: Aula complementar I – Espelhamento e segurança nos IRRs
• Curso IRR – Parte VIII: objetos inet(6)num
• Curso IRR – Parte IX: objeto aut-num
• Curso IRR – Parte X: Relações entre objetos

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!