Home > IRR, Sem categoria > Curso IRR – Parte V: Objetos route e route6

Curso IRR – Parte V: Objetos route e route6

04/04/2010 Leave a comment Go to comments

Introdução

Há uma linguagem por trás dos objetos que formam o repositório IRR. Trata-se da RPSL (Routing Policy Specification Language). Definida na RFC2622 a atualizada pela RFC4012, adicionando IPv6 e famílias de endereços multicast. Através da RPSL, o administrador estará habilitado a especificar as políticas de roteamento em detalhes suficientes para que, posteriormente possa representá-las nas configurações de baixo nível dos roteadores. Portanto, os construtores do repositório IRR são os objetos, definidos pela RPLS. Alguns objetos inserem informações sobre políticas de roteamento e outros inserem informações administrativas. Já vimos dois objetos, o mntner e o person, que caracterizam informações administrativas: um indica o “dono” da cadeia de informações que será construida e, também, qual o mecanismo de autenticação, enquanto o outro, indica “quem” é(são) o(s) ser(es) humano(s) que está(ão) por trás do “dono”.

O objeto route e route6

O objeto route especifica uma rota que pode ser anunciada pelo AS e somente por ele. O objeto descreve um endereço IPv4, sua máscara de rede e associa o AS a partir do qual a rota pode se originar (atributo origin). Já o objeto route6 faz a mesma coisa para o IPv6!

Abaixo o padrão do objeto route que é idêntico para o objeto route6: 

route:          [mandatory]  [single]     [primary/look-up key]
descr:          [mandatory]  [multiple]   [ ]
origin:         [mandatory]  [single]     [primary/inverse key]
holes:          [optional]   [multiple]   [ ]
member-of:      [optional]   [multiple]   [inverse key]
inject:         [optional]   [multiple]   [ ]
aggr-mtd:       [optional]   [single]     [ ]
aggr-bndry:     [optional]   [single]     [ ]
export-comps:   [optional]   [single]     [ ]
remarks:        [optional]   [multiple]   [ ]
cross-mnt:      [optional]   [multiple]   [inverse key]
cross-nfy:      [optional]   [multiple]   [inverse key]
notify:         [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Eis o exemplo do bloco /20 da TeleSA:

route:      189.89.0.0/20
descr:      TeleSA cidr block
origin:     AS28182
remarks:
remarks:    TeleSA IPv4 bloks
remarks:    ===========================================================
remarks:    http://www.TeleSA.com.br
remarks:    ===========================================================
remarks:    Security Note
remarks:    Any Notification about AS28182 security please e-mail to:
remarks:    ABUSE@TeleSA.com.br
remarks:    ===========================================================
remarks:    ===========================================================
remarks:
mnt-by:     MAINT-AS28182
changed:    jb@telesa.net.br 20090607
changed:    jb@PEGASUS.com.br 20090607
remarks:    Sun Jun  7 17:02:52 BRT 2009
changed:    jb@PEGASUS.com.br 20090905
remarks:    Sat Sep  5 18:23:52 BRT 2009
source:     PEGASUS

e o route6:

route6:     2001:1294::/32
descr:      TeleSA IPv6 blocks
origin:     AS28182
remarks:
remarks:    ===========================================================
remarks:    http://www.TeleSA.com.br
remarks:    ===========================================================
remarks:    Security Note
remarks:    Any Notification about AS28182 security please e-mail to:
remarks:    ABUSE@TeleSA.com.br
remarks:    ===========================================================
remarks:    ===========================================================
remarks:
mnt-by:     MAINT-AS28182
changed:    jb@PEGASUS.com.br 20090902
remarks:    Wed Sep  2 10:41:38 BRT 2009
changed:    jb@PEGASUS.com.br 20090905
remarks:    Sat Sep  5 18:23:52 BRT 2009
changed:    jb@PEGASUS.com.br 20091217
remarks:    Thu Dec 17 14:15:45 BRST 2009
source:     PEGASUS

Eis algumas observações interessantes, que se aplicam aos dois objetos route e route6:

  • O objeto route é extremamente simples em sua indicação. Ele não expressa uma política genérica. Ele é bem específico: define quais anúncios irão acontecer a partir de um AS. É preciso ficar bem claro, uma vez que existem outros objetos que complementam as informações de roteamento.
  • Fixando a idéia, o objeto route somente exibe os blocos que podem originar do AS definido no atributo origin.
  • É necessário atenção à agregação. Se seu AS tem vários pontos de interconexão na Internet, remotamente localizados, não interessa identificar tais pontos através do objeto route e, portanto agregar é a melhor recomendação.
  • Não há atributo no objeto route que permita estender a política de roteamento além da simples indicação dos blocos que o AS está habilitado a anunciar.
  • Pode-se criar quantos objetos route forem necessários, para representar os anuncios de blocos limitados pela agregação.
  • A noção de agregação é muito importante para atender à preocupação, quase doentia, de minimizar a tabela de rotas no BGP. Um bom texto sobre agregação está em “Understanding Route Aggregation in BGP” e, “BGP Case Studies”, já disponíveis na BC (em Referências).
  • Preocupação quase doentia para chamar atenção para o fato de que insistir na minimização de rotas parece um excesso pois, na prática, a tendência é desagregar, por necessidade operacional. Quem é o maior desagregador brasileiro? Um bom exemplo é a topologia da TeleSA (que não tem nada de original). Na realidade, exigência imposta por restrições da infraestrutura da Internet brasileira, obrigando a desagregação em blocos /24. Quando usarmos as ferramentas poderemos ver que tal realidade parece não ser nosso privilégio. A desagregação está generalizada. Curiosamente, a expectativa seria anunciar blocos /25, /26, etc. pois, economizaria algumas centenas de IPs (v4!). Raramente alguém fala sobre o fato de que a tabela “full” no BGP gera ineficiência. Ouço falar que elas geram demanda de memória dos roteadores de borda e, que memória é MUITO caro. Ora, memória não é caro! Então porque não posso anunciar blocos /25, por exemplo? Porque, boa parte dos ASes do mundo, restrigem o /25. Mas, no passado, essa boa parte bloqueava o /24 (poucos, ainda o fazem) e deixaram de fazê-lo quando perceberam a importância desse anúncio em ambientes onde interconexões remotas possuem restrições. Pelo que se lê na literatura, as técnicas de routing analytics, do SOA e outras, que se concentram no conceito de computação pervasiva + ubíqua, devem nos levar à centralização das bases de políticas de roteamento. Pensando bem, já temos algo a caminho, com o MyASN do RIPE e o BGMON, sem falar em outras. Provavelmente é uma questão de tempo, pois dependemos, unicamente, da ubiquidade presente na infraestrutura da Internet. São, em tese, conjeturas.
  • O IRR não tem problema de eficiência ou, de memória. E nem tem o poder de restringir rotas não definidas no objeto route. Ou seja, o IRR não tem influência sobre as funcionalidades do BGP, incluíndo as políticas de roteamento. O IRR é uma base de dados que lhe entrega informações com dois objetivos básicos: captura de políticas de roteamento e, não menos importante, documentação da subrede sobre a qual você tem, como administrador, influência única.

Atributo holes

Durante o planejamento de algumas redes, três blocos não são anunciados para nenhum dos ASes empareados ao AS28182:

189.89.4.0/22
189.89.6.0/23
189.89.12.0/22

Essa informação deve ser colocada no atributo holes, do objeto route (ou route6). Vejam em:

whois -h irr.redepegasus.net.br 189.89.0.0/20

O uso do atributo holes é interessante, muito embora ele não seja um atributo obrigatório e nem seja “pesquisável”. Vejam por exemplo o caso do AS18782. Este AS não está ativo e, na época, quando atribuido ficou sem bloco IPv4 associado. Afinal, poderia-se fazer a seguinte política de roteamento, explicitamente:

route:      189.89.0.0/20
descr:      TeleSA cidr block
origin:      AS28182
holes:      189.89.4.0/22
holes:      189.89.6.0/23
holes:      189.89.12.0/22
...

route:      189.89.0.0/20
descr:      Pegasus x TeleSA cidr block
origin:     AS18782
holes:      189.89.0.0/22
holes:      189.89.8.0/22
...

Provavelmente, iríamos fazer uma economia razoável de IPv4, usando a cooperação entre ASes. E, sob o ponto de vista técnico a alternativa é endossada pela RFC1786, com categoria “informational”, escrita em 1995, à luz da RIPE81++, antecedente da RPSL.

 

Itens relacionados:

 

Categories: IRR, Sem categoria