Home > BGP, IRR, Peering, Protocolos, TCP/IP, Whois > Curso IRR – Parte X: Relações entre objetos

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!

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