Archive
Curso IRR – Parte V: Objetos route e route6
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:
- 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 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
Infraestrutura da Internet 