Arquivo

Posts Tagged ‘irr’

Curso IRR – Parte I: Introdução

Vou reproduzir o treinamento virtual que dei recentemente para cerca de 46 inscritos. Um pouco mais aperfeiçoado. Haverá no mínimo uma postagem por semana.

Os tópicos a serem abordados serão:

  • As bases de dados.
  • Pesquisas às bases com o objetivo de avaliar as tabelas de rotas e eventuais consistências das tabelas.
  • A utilização da base para ajustar de forma adequada os filtros dos roteadores.
  • Ferramentas de apoio.

Cada postagem, com o título começando por “Curso IRR”, refere-se a uma mensagem do treinamento virtual. São poucas mensagens, complementadas pela documentação, disponível e/ou a ser inserida na Base de Conhecimento da Pegasus, em .

Muito importante serão os exercícios. Para isso, o PEGASUS IRR estará disponível para os interessados, por um período de 30 dias, sem ônus. Se alguém estiver em alguma base que não a do PEGASUS IRR pode, assim mesmo usar nosso registro e, portanto, executar os exercícios. Estar registrado em mais de uma base IRR, não é recomendável mas, não há problemas que isso aconteça por pouco tempo. Os interessados podem solicitar o uso temporário a j at braga dot net dot br, indicando o ASN.

Sintam-se à vontade para, através dos comentários participar de cada segmento. Assim, todos se beneficiarão. Nenhuma dúvida deve ser evitada e é menor ou maior do que a outra. Portanto, não se acanhem, por favor.

O whois será a nossa principal ferramenta de pesquisas. Os hosts podem ser tanto o irr.redepegasus.net.br como outro qualquer (p. ex.: whois.radb.net). Eis alguns exemplos de pesquisas:

. whois -h irr.redepegasus.com.br juliao
. whois -h irr.redepegasus.com.br fltr-unallocated
. whois -h irr.redepegasus.com.br AS28182
. whois -h irr.redepegasus.com.br fltr-bogons
. whois -h irr.redepegasus.com.br MAINT-BOGON-FILTERS
. whois -h irr.redepegasus.com.br MAINT-AS28182
. whois -h whois.radb.net MAINT-AS28182

Exercícios para esse segmento

Podem enviar os exercícios para j at braga dot net dot br que serão avaliados em Comentários de cada segmento. Daremos uma declaração de participação no treinamento com base nos exercícios resolvidos, nos enviado.

  1. Quais os hosts possíveis de serem pesquisados via whois e estejam espelhadas pela base do RADB?
  2. Executar as pesquisas acima e pensar sobre os resultados. Fazer as pesquisas em mais de um host.
  3. Dê uma demorada olhada no sítio do RADB.

 

Textos relacionados:

 

Anúncios
Categorias:IRR, Sem categoria Tags:,

Soluções simples para melhorar a Internet

Algumas coisas básicas, me incomodam como administrador de sistemas associados à Internet. E nada posso fazer, pois depende de atitudes de terceiros. A maior parte delas, depende dos RIRs ou do nosso NIR. Abaixo, algumas sugestões que, na medida do possível e por sugestões de colaboradores, serão incrementadas. Nenhuma delas agride o espírito da Internet.

  1. O reverso deve ser obrigatório. Quem não tiver o reverso deve ser punido.
  2. O Registro.br deve permitir a renúncia de blocos IPs, pelos ID Técnicos. Essa facilidade é pré-requisito para a proposta do item anterior. Atualmente, os responsáveis técnicos por blocos de IPs de terceiros, não conseguem se livrar deles, a partir do momento que não são mais responsáveis.
  3. O DNSSEC deve ser obrigatório para todos as DPNs. Quem não fizer isso, deverá ser punido. Quem não atualizar as chaves na época do vencimento, também será punido. O Registro.br deveria indicar nos avisos em que houver quebra de respostas no DNSSEC, QUAIS os servidores de DNS envolvidos, assim como ele fazia quando não havia respostas de servidores de DNS. Esse problema não é grave para quem possui, somente dois servidores de DNS, mas é complicado para quem possui o máximo permitido (5). Se a identificação do servidor específico de DNS não for possível, por alguma razão, então que informe aos administradores que eles devem cuidar dessa questão, monitorando cada um deles. O estado do domínio com DNSSEC implementado, também poderia aparecer por lá, o que nos ajudaria bastante.
  4. ASN deve ser liberado, livremente. Para quem provar que tem uma rede. As restrições somente para a liberação de blocos IPv4. Blocos IPv6 deveriam ser liberados para os ASs, mesmo sem IPv4. Isso anteciparia as implementações de IPv6. Muitos ASs com IPv6 estimulariam os fornecedores a implementar tal funcionalidade, já que o mercado estaria disponível. Por outro lado, o LACNIC deveria rever os preços relativos ao IPv6, que pretende cobrar no futuro.
  5. Instalação de uma base do IRR espelhada na RADB. De graça e com suporte a IPv6! E o Nic.br (ou LACNIC) pode criar, à semelhança do RIPE NCC, orientações de uso, inclusive das ferramentas disponíveis (IRRTools, p. ex.).
  6. Propostas para o tratamento das punições. Sempre haverá avisos, antecedendo a punição. As punições, após os avisos, não devem ser brandas. Os critérios de punição deveriam considerar a reincidência. Quem possui um ID Técnico, pressupõe-se que seja um administrador, conhecedor dos fundamentos da Internet. Os avisos e punições, podem se estender aos outros IDs.

Internet Routing Register (IRR)

Introdução

Alguns de meus amigos que trabalham com infraestrutura da Internet e administradores de redes, em particular, usam com uma certa frequência, o CIDR-Report. Pessoalmente, mantenho-o, permanentemente, no meu desktop. O CIDR-Report gerou um equívoco para estes amigos e para mim, também. O problema é que quando se pesquisava o CIDR-Report para qualquer ASN que tenha sido destinado pelo Nic.br (após a transferência das funções pelo LACNIC), aparecia a mensagem no cabeçalho “–No AS Description–“. Todos diziam que faltava o registro do AS no RADB, a principal base de dados do Internet Routing Register (IRR). E eu, repetia isso para outros. Então, passei a procurar uma maneira de registrar os ASs que administro no RADB. O primeiro impasse, nesta tentativa, foi o fato do registro no RADB custar US$495.00/ano. Uma pergunta do !3runo, na GTER, sobre o ALTDB, deu a pista para o registro do AS no RADB, em bases que eram espelhadas. Minhas tentativas de registro no ALTDB foram de pura frustação. Mas, mesmo percebendo que muitos já tinham registrado no ALTDB acabei usando os serviços do pessoal da Infraestrutura.IP. Em menos de um dia, os ASs estavam na RADB. Sem a anualidade! Recentemente (agosto/2009) a Pegasus implementou a primeira base de dados IRR no Brasil: http://irr.redepegasus.net.br.

Logo fui no CIDR-Report e percebi que, o No AS description, continuava lá. Esperei alguns dias e nada. Logo percebi que não era a inexistência no RADB que gerava a mensagem. Então fiz o que deveria ter feito desde o início: entender o IRR. A conclusão foi de que é uma peça muito importante para a consistência de rotas publicadas pelos ASs, em particular, para detetar o MOAS (acrônimo de Multiple Origin Autonomous Systems), automaticamente. Os conflitos de MOAS acontecem pelo simples problema de que um AS pode “injetar” qualquer prefixo, por configuração correta, incorreta ou maliciosamente*. A história do No AS description deixarei para o final.

O que é o IRR e para que serve?

Existem inúmeras definições na literatura que pesquisei. Uma delas diz que IRR é um conjunto de bases de dados que permitem ao BGP, documentar suas rotas e políticas de roteamento, com o objetivo de dar consistência às configurações de um roteador. Dizia ainda que o BGP fazia isto “conversando” em uma linguagem chamada RPSL. É a linguagem comum dos whois, jwhois, etc. E a mesma que motivou a construção de uma autômata de pilha em artigo que pode ser visto aqui.

Nada de errado com a definição acima. Mas não era muito precisa. Cheguei então, à página oficial do IRR, em [5]. Há várias informações importantes, incluindo as bases de dados ligadas ao RADB. A relação das bases de dados é quase uma piada, mostrando que alguma coisa não estava sendo levada a sério. A última vez que estive por lá foi no mes de março/2009.

Mais á frente, percebi que muitos RIRs possuem ofertas de bases de IRR, espelhadas no RADB, para os usuários de sua região, mas não vi nada em relação ao LACNIC, exceto propostas, inclusive do Nic.br. Aqui, uma notícia do LACNIC a respeito. O APINIC [6] tem o APIRR e é capitaneado pelo Japão, também com um serviço IRR para seus usuários, como pode ser visto em [3].

Europa (RIPE) e Japão (membro do RIPE), levaram a sério o IRR. E, principalmente no Japão, estão os trabalhos mais consistentes sobre IRR. Em um dos trabalhos que li, [7], uma definição completa sobre o que é, e para que serve o IRR reproduzo, no original: “The Internet Routing Registry (IRR) … is a large distributed repository of information, containing the routing policies of many of the networks that compose the Internet. The IRR was born about ten years ago with the main purpose to promote stability, consistency, and security of the global Internet routing. It consists of several registries that are maintained on a voluntary basis. The routing policies are expressed in the Routing Policy Specification Language (RPSL) … The IRR can be used by operators to look up peering agreements, to study optimal policies, and to (possibly automatically) configure routers.”

Logo a seguir, o trabalho ressalta: “There is a wide discussion about the current role of the IRR … Some people consider it outdated and almost useless. Others have put in evidence its importance to understand the Internet routing and that it contains unique and significant information. Anyway, it is undeniable that the IRR keeps on being fed by many operators, that useful tools have been developed to deal with the IRR (see, e.g., IRRToolSet [3]), …”.

Queria chegar, na citação acima, no IRRToolSet. Acabei implementando a IRRToolSet em FreeBSD e tem realmente algumas ferramentas interessantes. Por exemplo a peval, com a qual descobri que um punhado de gente boa publica blocos /24. Aos montões! Outra que seria interessante, é a prtraceroute, que inclui o ASN e a política de roteamento, em cada etapa do traceroute. Sobre a instalação do IRRToolSet, veja aqui. Há uma lista pouco movimentada, mas interessante, que pode ser assinada aqui.

A história do –No AS Description–, no CIDR-Report

Eu não percebi, de imediato, que a mensagem, tecnicamente incômoda, do CIDR-Report somente ocorria para os ASs distribuídos pelo Nic.br, a partir da mudança do LACNIC, em meados de 2007. Escrevi ao LACNIC a respeito do problema e a resposta que obtive não foi muito clara e resolvi escrever para o Geoff Huston, responsável pelo CIDR-Report. Ele me respondeu de pronto, dizendo que o problema estava relacionado com o jwhois, que o LACNIC não estava autorizando a consulta em suas bases de whois. Três ou quatro mensagens se seguiram para o LACNIC, sendo que na penúltima, finalmente, percebi que o problema eram somente os atuais ASs liberados pelo Nic.br. Por fim, o LACNIC em uma das respostas informou que o problema do proxy seria resolvido nos primeiros 4 meses de 2010, já que o CIDR-Report não era tão importante assim, para os administradores de sistemas.

Mais recentemente, ando desconfiado que outros além do CIDR-Report estão com o mesmo problema. Por exemplo, o Google Analytics. A grande maioria dos acessos de rede (93%), são registrados como comite gestor da internet no brasil.

Últimas notícias sobre IRRToolSet

Há cerca de dois ou três dias atrás (a partir de hoje, 15/05/2009) tem havido um debate interessante sobre as ferramentas do IRRToolSet. Em particular, val a pena ver aqui, a descrição que Nick Hilliard, faz sobre cada uma delas. Para frente e para trás, na sequência dessa mensagem o debate é interessante.

* Usar a base do IRR para detetar conflitos de MOAS, não é a única técnica disponível. Há uma corrente recomendando o bgp.in.addr.arpa.. Esse grupo, provavelmente está preocupado com a falta de confiabilidade das informações armazenadas na RADB. Como elas são atualizadas pelos próprios responsáveis pelos ASs, observa-se um certo descuido. Entretanto, nota-se que o pessoal que faz peering ou pretende fazer, está cuidando de forma correta das suas informações lá armazenadas.

Referências


[1] Siganos G., Faloutsos, M., Analazing BGP policies: methodology and tool, INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, Vol. 3 (2004), pp. 1640-1651 vol.3.
[2] Alaettinoglu C. et alii, Routing Policy Specification Language (RPSL), The Internet Society, RFC2622, 1999.
[3] JPNIC IRR (JPIRR) Operation Policies and User Guideline, Japan Network Information Center, IRR-Planning Team, July 2003.
[4] Nagahashi, K., Esaki, H. & Murai, J., An integrity check for the conflit Origin AS Prefixes in the inter-domain routing, IEICE Trans. Commun., Vol. E86-B, no. 2, February 2003.
[5] Internet Routing Register
[6] APIRR resource guide
[7] Battista, G. di, Refice, T., Rimondini, M., How to Extract BGP Peering Information from the Internet Routing Registry

Últimas atualizações:
29/04/2009 09:00

%d blogueiros gostam disto: