Arquivo

Archive for the ‘Sem categoria’ Category

Os números de 2010

A equipe de estatísticas do WordPress.com analisou o desempenho deste blog em 2010 e, eis o resumo sobre o nível da saúde desse blog:

Healthy blog!

O Blog-Health-o-Meter™ indica: Este blog é fantástico!.

Números

Este blog foi visitado cerca de 9.200 vezes em 2010, equivalente a cerca de 22.747 segundos cheios.

Em 2010, foram escritos 117 novos artigos, aumentando o arquivo total para 140 artigos. Um total de 52 imagens, ocupando 2 MBytes. Isso equivale a cerca de 4 imagens por mês.

O dia mais ativo de 2010 foi 22 de janeiro com 101 visitas. O artigo mais popular desse dia foi Idéias sobre o que fazer com um bloco /32 do IPv6 – II.

A figura ao lado foi obtida do artigo “Orbis: Rescaling Degree Correlations to Generate Annotated Internet Topologies” e publicado no “Proceedings of the ACM SIGCOMM Conference, Kyoto, Japan, August 2007”. cujos autores são:

  • Priya Mahadevan
  • Calvin Hubble
  • Amin Vahdat
  • Bradley Huffaker
  • Dimitri Krioukov

Os três primeiros, do “UCSD’s Department of Computer Science and Engineering”, e os dois últimos, do “CAIDA, the Cooperative Association for Internet Data Analysis”, o qual é baseado no Centro de Supercomputador da Universidade de São Diego, USA. A figura é uma versão de 2.000 nós, reescalonada de uma versão original de 939 nós, mas mantendo as características fundamentais dessa versão original. Outros comentários podem ser vistos em Digital Dandelions: The flowering of network research

De onde vieram?

Os sites que mais tráfego enviaram em 2010 foram google.com.br, linhadefensiva.org, twitter.com, pt-br.wordpress.com e search.conduit.com.

Alguns visitantes vieram dos motores de busca, sobretudo por implementação de dnssec com bind, dns autoritativo, dnssec-keygen, tipos de dns e servidor autoritativo.

Atrações em 2010

Artigos e páginas mais visitados em 2010.

1

Idéias sobre o que fazer com um bloco /32 do IPv6 – II agosto, 2009

2

Tipos de DNS e suas aplicações maio, 2009

3

Tráfego, trânsito, transporte e peering (uma proposta de definição) março, 2010
4 comentários

4

Linha Defensiva, o selo site seguro e o Teorema da Parada fevereiro, 2009
1 comentário

5

DNS: Um exemplo de topologia janeiro, 2009

Anúncios
Categorias:BGP, Sem categoria, TCP/IP

Laboratório virtual de roteamento – LVR (I)

Atualizado em: 30/01/2011.

Introdução

Ultimamente tenho gasto meu tempo no aperfeiçoamento do meu conhecimento na RPSL (com foco no Abranet IRR, [1]) e na construção da infraestrutura de rede da minha empresa. São dois projetos muito interessantes, que exigem uma enorme dedicação.

O Abranet IRR já possui uma equipe muito boa e breve teremos novidades. Acho que esse projeto da Abranet, que não é exclusivamente o IRR trará muitos benefícios para os administradores de ASes brasileiros. É um projeto de médio/longo prazos, com uma característica de neutralidade que somente uma instituição como a Abranet poderia proporcionar.

Dos trabalhos relacionados com a demanda da empresa, onde um conceito renovado de Voz sobre IP está sendo implementado chegam os principais desafios. São vários e, principalmente na parte relacionada com BGP, PTTs, túneis MPLSs e infraestrutura da Internet reside o mais apaixonante interesse do autor, eterno aprendiz em roteamento. Provavelmente, todos nós somos.

Um dos maiores problemas que tenho encontrado está no exercício de uma determinada teoria em relação ao que se está planejando. Geralmente o exercício está ligado em como fazer ou, como aplicar nos equipamentos disponíveis. A falta de padrão e a tentativa de estabelecer como padrão, equipamentos da Cisco aumenta mais ainda a dificultade e esforço. Esse esforço é redobrado quando, uma vez entendido a teoria tenta-se ir à prática.

Com tais preocupações em mente ao estudar um excelente curso, em [2], imaginei a hipótese de construir um laboratório apropriado para testar e aprender o que se precisa. Essa hipótese já tinha sido pensada, logo após o treinamento de IPv6, no Nic.br, [3]. Quem teve essa oportunidade sabe muito bem o quão bem elaborado foi o esforço do Antônio Moreiras (responsável pelo treinamento IPv6, do Nic.br). O laboratório engendrado para o treinamento é algo muito interessante. Invejável e perfeito. Sei que houve uma equipe envolvida na construção desse laboratório de IPv6, na qual o Eduardo Ascenço teve participação significativa, entre muitos outros.

Resolvi então, montar um laboratório pessoal, que chamei de Laboratório Virtual de Roteamento (LVR). O modelo desse laboratório deveria ter as seguintes características:

  • Ser ilimitadamente escalável: tanto sob o ponto de vista do crescimento físico, como do crescimento lógico. Escalabilidade lógica implica na possibilidade de ampliar o exercício para a prática. Por exemplo, o laboratório poderia se conectar a um PTT. Nunca houve a pretensão de fazer algo como o projeto GENI, [4], mas o GENI sempre esteve no foco.
  • Flexível: permitir a inclusão de novos recursos e facilidades. Há aqui, no escritório, diversos roteadores que eventualmente pudesse ser interconectados ao projeto para permitir experiências práticas.
  • Mobilidade: o projeto deve permitir acesso remoto ou acompanhar as viagens pessoais.
  • Ser barato! Sem comentários.

Foi então, que ao terminar o treinamento [2], a base do LVR foi estabelecida. Nesse texto e nos outros que virão pretende-se contar as experiências.

O modelo do LVR

A idéia inicial foi feita sobre 7 (sete) servidores Mikrotiks (MKs), implementados em máquinas virtuais, em um notebook. Usando o esquema simples de roteamento estático, o que foi feito está na figura 1, abaixo. Na figura está um modelo de representar a Internet concebido em [5], onde os ASes estão representados em laranja e PTTs em verde. Vem a calhar, tal representação, para o que iremos falar no futuro.

Figura 1. Modelo original do LVR, baseado em rede local.

A implementação de rotas estáticas permitiu experimentar o resultado. Tendo sido positivo, a preocupação agora era criar uma topologia que permitisse transformações de forma, sem dificuldade. Então, abstraiu-se das rotas estáticas influenciadas pela rede onde o notebook estava. Em outras palavras, a conectividade foi estabelecida e a figura 2 mostra que a pretensão era uma abstração dessa conectividade para se pensar em outra.

Figura 2. Abstraindo-se das interconexões.

Cada Mikrotik do LVR está identificado como MKn, para n de 0 a 7. O MK0 não é virtual. É um gateway com acesso à Internet. A versalidade do Mikrotik é incrível! Por isso ele foi preferido, inicialmente. Mas, a possibilidade de uma máquina virtual, não limita nenhuma possibilidade, tais como Quagga, Bird [5] e outros. Um hospedeiro poderoso permite asas à imaginação.

Iniciou-se a implementação de VLANs, para ligar os MKn. Na medida quem que as VLANs foram criadas, pode-se, finalmente, abstrair-se das rotas estáticas originais. Só abstração. Elas não foram retiradas, com o objetivo de manter a conectividade. Mas, podem ser ignoradas, já que não participam como “gateway” em cada MKn. A figura 3 exibe a primeira VLAN.

Figura 3. Construindo as VLANs.

Em seguida, os outros MKs tiveram suas VLANs estabelecidas, conforme mostra as figuras que seguem. Note-se a numeração das VLANs. Por exemplo, a VLAN que conecta o MK0 ao MK1, tem o número 10. O mesmo acontece com os IPs definidos para as VLANs. Sempre são 10.1.n.0/30, onde n é o número da VLAN. Isso obrigou uma rota estática do 10.1.0.0/17 para os vizinhos. Tudo para facilitar a implementação.

Próximas atividades

Eis alguma das próximas atividades sobre o LVR:

  • IPv6: nesse caso pode-se até mesmo viabilizar os MK virtuais, quando da implementação do BGP.
  • Seguir a proposta do Greg: RIP, OSPF, eBGP e iBGP
  • Novas topologias para que se possa fazer experiências.
  • Manter as experiências descritas sumariamente aqui nesse blogue e em detalhes, na Base de Conhecimento da Abranet.
  • Estimular a criação de outros LVRs para troca de experiências e interconexões. O LVR acima tem a identificação LVR28182.
  • Em 7 de novembro de 2010 resolvi trocar o nome do LVR para, Fábrica Fictícia de Encaminhamento (FFE ou 1111 1111 1110).

E o notebook, com estas 7 máquinas virtuais? Nem piou!

Referências

[1]. Abranet IRR.
[2]. Greg Sowell, Routing. Vídeo disponível aqui. Acessado em 02/11/2010.
[3]. Curso IPv6 Básico (Presencial). Nic.br, CEPTRO.br, IPv6.br. Material disponível aqui. Acessado em 02/11/2010.
[4]. Projeto GENI. Acessado em 02/11/2010.
[5]. Julião Braga, Tráfego, trânsito, transporte e peering (uma proposta de definição). Março 9, 2010, Disponível aqui. Acessado em 02/11/2010.
[5]. BIRD. Acessado em 02/11/2010.

IANA IPv4 allocations and bogon update 177/8 and 181/8

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings Everyone,

The numerous Team Cymru bogon projects have been updated as of 02 JUNE 2010 to
reflect the following IANA allocation made on 02 June 2010:

   177/8  LACNIC            2010-06  whois.lacnic.net   ALLOCATED
   181/8  LACNIC            2010-06  whois.lacnic.net   ALLOCATED

IANA allocations change over time, so please check regularly to ensure you have
the latest filters if you are not using the bogon BGP feed(s). We do announce
updates to the bogon projects to sundry lists, such as the bogon-announce list.
We can not stress this point strongly enough - these allocations change. If you
do not adjust your filters, you will be unable to access perhaps large portions
of the Internet. Worse yet, you may end up blocking access for people who
transit through you.

Please do not apply any filters or blocks to your network without carefully
considering the ramifications of doing so.

As a point of reference, the Team Cymru master Bogon Reference Page can be found
here:

  

A quick summary of the documents and projects that have been updated include the
following:

* HTTP
  - The Bogon Lists via HTTP
    - http://www.team-cymru.org/Services/Bogons/http.html
  - The Text Bogon Lists
    - http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt
    - http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt
  - Ingress Prefix Filter Templates, Loose and Strict (Cisco)
    - ftp://ftp-eng.cisco.com/cons/isp/security/Ingress-Prefix-Filter-Templates/
* BGP
  - Bogon route-server for AUTOMATED updates of bogon filters
    - All bogon route-server peers have already received the
      appropriate BGP prefix updates.
    - http://www.team-cymru.org/Services/Bogons/bgp.html
* RADb
  - fltr-unallocated fltr-martian fltr-bogons
    - http://www.team-cymru.org/Services/Bogons/rr.html
* RIPE NCC
  - fltr-unallocated fltr-martian fltr-bogons
    - http://www.team-cymru.org/Services/Bogons/rr.html
* DNS
  - Bogon (bogons.cymru.com) zone
    - http://www.team-cymru.org/Services/Bogons/dns.html
* Monitoring
  - Bogon prefix monitoring
    - http://www.cymru.com/BGP/bogons.html
  - Bogus ASN monitoring
    - http://www.cymru.com/BGP/asnbogusrep.html

Please feel free to contact Team Cymru  with any comments,
questions, or concerns.

Thank you for your continued support.

Team Cymru NOC

+1-630-230-5401
noc@cymru.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkwG5GgACgkQgZnvMVELnNG6TwCgy8D2T6PRDIRm6NoxsvLtnbee
XQUAn3xa2FKdUSPNuUEaPsVWGT7R2XoA
=kr4w
-----END PGP SIGNATURE-----
Categorias:Sem categoria

Curso IRR – Parte VII: Planos de roteamento

Introdução

Mais de 37.000 \textbf{ASes} formam a Internet, operados por diferentes dominios administrativos tais como provedores de acesso à Internet (ISPs), empresas, universidades, etc. [1]. Embora não tenhamos interesse direto, os aspectos econômicos que envolvem um \textbf{AS} representam componentes importantes, que afetam as atividades operacionais do \textbf{AS}. Recomeda-se a leitura de [3] onde respostas a perguntas dos tipos abaixo, poderão ser encontradas:

  • Porque os preços da banda estão se aproximando de R$0,00?
  • Será que as concessionárias fazem peering entre elas, estritamente fechado?
  • As concessionárias nos vendem trânsito, mas lucram muito com o tráfego local?

O artigo foi escrito em 2003, mas mantém sua atualidade. Também, recomenda-se inscrever no grupo da Abranet sobre Sistemas Autônomos [4].

Voltando aos interesses desse curso, as Partes VI e VII, tem o objetivo de relembrar conceitos importantes para a compreensão dos outos objetos usados pela base IRR. Nessa linha, vamos recordar algumas noções importantes sobre o BGP, no que diz respeito a planos de roteamento (alguns autores chamam, também, de políticas de roteamento). Nos textos que antecederam a este fizemos questão de deixar claro que no nosso contexto, políticas de roteamento estão em um patamar que muitas vezes não são representáveis diretamente nos planos de roteamento do BGP, quando interconectamos pelo menos dois \textbf{ASes} Quando trabalhamos com o IRR devemos nos abstrair de eventuais dificultades que possam surgir quando da implementação efetiva em um protocolo como o BGP (o exemplo dos \textbf{ASes} azuis e vermelhos, discutidos na Parte VI). Há um bom material em [1] onde, em particular, recomendo o [2], disponível na BC. Em [2], os autores argumentam que pouco se sabe sobre quais as políticas de roteamento são usadas pelos administradores para configurar suas redes, além de outras conclusões interessantes como, por exemplo, o fato deles acharem que as informações contidas no IRR são, incompletas ou não atualizadas de forma sistematica pelos seus responsáveis.

Fatos a serem relembrados

Vamos lembrar de alguns fatos conhecidos e, considerar a Figura 1, adaptada de [2]:

Figura 1. Uma representação formal de um grafo \textbf{AS}.
  • A Internet é formada por \textbf{ASes} interconectados (mais de 37.000, no mundo todo).
  • Cada \textbf{AS} é representado por um número único conhecido como \textbf{ASN}.
  • Um \textbf{AS} pode anunciar um ou mais prefixos de IP.
  • Os prefixos anunciados pelos \textbf{ASes} devem ter sido previamente alocados pelo Registro.br (no nosso caso).
  • Se um \textbf{AS} anuncia um prefixo não associado a ele pelo Registro.br, ocorre o que chamamos de “sequestro do prefixo” (“prefix hijacking”). Vale lembrar que quando falamos em um AS “emprestar” um bloco de IP para outro \textbf{AS} está implícito o fato de que este empréstimo deve ser reconhecido pelo Registro.br. Caso contrário, seria interpretado com sequestro.
  • “Interpretado como sequestro” porque há mecanismos na Internet (por exemplo, “route views”, “looking glass” e outros), que ficam monitorando a infraestrutura da Internet. Melhor dizer, ficam tentando monitorar. Mais de 37.000 \textbf{ASes} são complicados de monitorar. Por isso existem tantas ferramentas de montitoramente e, muitas vezes precisamos recorrer a várias delas para localizar um problema. O núcleo da Internet (formado pelos provedores de backbone nacional/internacional) está aparentemente bem monitorado, pois são pouco \textbf{ASes} que o formam. Há protocolos proprietários desconhecidos, entretanto, nas interconexões de peering entre concessionárias que abusam dos interesses econômicos envolvidos. Há alguns anos atrás, em uma conversa no Nic.br entendi que o peering construido entre as concessionárias brasileiras não era legal e estavam sendo monitorados. Mas, até hoje não ficou bem claro as implicações, exceto algumas conclusões de que talvez por isso, os preços da banda estejam reduzindo rapidamente. Algo como, as operadoras vendem trânsito (para a Internet), mas concentram uma boa parte do tráfego ao redor de um espaço de interconexão limitado. E boa parte delas se recusam aos acordos de peering com pequenos provedores de trânsito. Questões como essa implicam no esforço do Nic.br na direção dos PTTs.
  • Na Figura 1, \textbf{AS} _ \textbf{1 }, \textbf{AS} _ \textbf{2 }, …, \textbf{AS} _ \textbf{6 } são \textbf{ASes} ou simplesmente, nós do grafo (representação formal).
  • Roteamento dentro dos \textbf{ASes} se torna operacional através do iBGP. Informações de roteamento entre \textbf{AS} _ \textbf{1 } é ddeterminado pelo BGP, que inclui o iBGP e o eBGP. O eBGP troca informações de acesso entre \textbf{ASes} e o iBGP troca tais informações dentro de um \textbf{AS}.
  • O BGP usa mensagens de “update” para propagar alterações de roteamento (ou de rotas). O BGP usa um AS-path completo para chegar a um prefixo de destino, informado nas alterações de rotas.
  • Seleção e anúncio de rotas no BGP são determinadas pelos planos de roteamento das redes (ou políticas de roteamento, dentro do contexto da interconexão). Tais planos dependem das relações comerciais estabelecidas quando da conexão de um \textbf{AS} com outro \textbf{AS}.
  • As relações comerciais, são basicamente de dois tipos:
    • \textbf{Cliente}-----\textbf{Provedor}
    • \textbf{Peer}-----\textbf{Peer}
  • Há uma outra relação comercial denominada “siblings” (relações comerciais familiares …), onde dois \textbf{ASes} pertencem à mesma organização.
  • Na relação \textbf{Cliente}-----\textbf{Provedor}, o cliente paga ao provedor, pelo serviço de acesso ao resto da Internet.
  • Na relação \textbf{Peer}-----\textbf{Peer}, não há envolvimente financeiro (usualmente). Os dois \textbf{ASes} envolvidos no peering trocam tráfego entre seus clientes, somente. Tradicionalmente, um \textbf{AS} cliente não encaminha tráfego de peering entre seus provedores e nem tampouco deixa que um \textbf{AS} peer encaminhe, através dele, tráfego de peering entre dois outros pares. Na Figura 1, o \textbf{AS} _ \textbf{1 } é cliente do \textbf{AS} _ \textbf{2 } e do \textbf{AS} _ \textbf{3 }. O \textbf{AS} _ \textbf{1 } não gostaria de servir trânsito entre \textbf{AS} _ \textbf{2 } e \textbf{AS} _ \textbf{3 } evitando assim, pagar pela troca de tráfego entre \textbf{AS} _ \textbf{2 } e \textbf{AS} _ \textbf{3 }. Entrentanto, vale lembrar que essa troca de tráfego existe na Internet e é chamado de “vale livre”. Em 2000, a Profa. Linxin Gao, em [2], comenta esse tipo de tráfego além de outros tráfegos estabelecidos no esquema de relações familiares e, nas configurações mal feitas por eminentes técnicos que não sabem o que estão fazendo.
  • Quando \textbf{ASes} escolhem seu melhor caminho, usualmente fazem na seguinte ordem: rotas de clientes, rotas de peer e rotas de provedores de trânsito. Muitos caracterizam um “deny” para evitar o “vale livre” entre clientes (“no valley prefer customer”). Veremos um exemplo mais à frente pois é muito importante para a questão do sequestro de prefixos. Quem não está atento a esse “deny”? Aliás, será que é uma preocupação dos mais de 700 \textbf{ASes} brasileiros?

Seleção de rotas

  • Vejamos como a Figura 1 ilustra a seleção e propagação de rotas.
    • O \textbf{AS} _ \textbf{1 } anuncia um prefixo (por ex.; 189.89.0.0/20) para seus provedores de trânsito (ou provedores de “upstream”), \textbf{AS} _ \textbf{2 } e \textbf{AS} _ \textbf{3 }. O \textbf{AS} _ \textbf{1 } é chamado de \textbf{AS} de origem para o prefixo 189.89.0.0/20 (origin \textbf{AS}).
    • Cada um dos provedores de trânsito do \textbf{AS} _ \textbf{1 }, prefixa o seu \textbf{ASN} ao AS-path e propaga para seus ASes vizinhos.
    • o \textbf{AS} _ \textbf{3 } recebe o caminho {1} do seu cliente \textbf{AS} _ \textbf{1 } e anuncia {3;1} para seus pares \textbf{AS} _ \textbf{4 } e \textbf{AS} _ \textbf{5 }.
    • O \textbf{AS} _ \textbf{5 } recebe rotas do \textbf{AS} _ \textbf{3 } e \textbf{AS} _ \textbf{2 } (peerings, talvez melhor, pares). O administrador do \textbf{AS} _ \textbf{5 } decide por anunciar {5;3;1} para seu cliente \textbf{AS} _ \textbf{6 }. Um \textbf{AS} escolhe quais as rotas serão importadas por seus vizinhos e quais aquelas a serem exportadas para seus vizinhos. Um \textbf{AS} que recebe inúmeras rotas escolhe a melhor rota, baseada no plano de preferência. A seleção do melhor caminho deve ser previamente estabelecida em parâmetros do BGP e, pode ser um pouco trabalhoso e sujeito a erros pelo ser humano. Aqui, vale lembrar, entram as ferramentas de apoio do IRR para traduzir as políticas de roteamento definidas em regras do BGP (para os diversos equipamentos).
  • Muito importante, como já disse, são os coletores de informações sobre os roteadores operacionais. Como falei, basicamente, as coletas são feitas sobre os roteadores dos provedores de trânsito (que segundo a literatura devem ser pouco mais 10% => ~3.700). São os tais membros do chamado Tier-1, na hierarquia dos ASes. Estes provedores (Tier-1) estão interconectados em uma malha fortemente estabelecida e compõem o núcleo (“core”) da infraestrutura de roteamento da Internet.

Itens relacionados:

Referências

[1] Gao, Lixin, Página pessoal.
[2] Wang, F., Gao, L., Inferring and Characterizing Internet Routing Policies, ACM SIGCOMM Internet Measurement Conference 2003.
[3] Huston, G., Interconnection, Peering, and Settlements.
[4] Lista GT-AS, Abranet. Grupo de debates sobre Sistemas Autônomous.

Categorias:IRR, Sem categoria

Curso IRR – Parte V: Objetos routeroute6

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:

 

Categorias:IRR, Sem categoria

Curso IRR – Parte IV: Exercitando o whois

O whois é uma importante ferramenta para consulta às bases do IRR. Há duas variações de formato do whois que nos interessa:

  • whois -m parametro_de_consulta
  • whois -h host_com base_irr parametro_de_consulta

No primeiro formato, a consulta é feita diretamente no RADB. Equivale ao formato do segundo caso:

whois -h whois.radb.net parametro_de_consulta

onde especificamos o host que contem a base IRR sobre a qual o whois deverá agir. Assim, o segundo formato será usado quando desejarmos um teste à base que nos interessa ou àquela na qual estamos inserindo nossos objetos. Se for a base do Pegasus IRR, então:

whois -h irr.redepegasus.net.br parametro_de_consulta

A pergunta que surge ao usar o whois é: quais os valores possíveis para parametro_de_consulta? A resposta é deixada como exercício e, vale lembrar, equivalente a um exercício de aula anterior.

Como comentário final, quando alguma alteração for feita na base do Pegasus IRR, não mais do que 5 minutos depois, tal alteração já está na base RADB.

 

Itens relacionados:

 

Categorias:IRR, Sem categoria, TCP/IP

Curso IRR – Parte II: O que é o IRR

Introdução

 

O IRR (Internet Routing Registry) é um repositório de políticas de roteamento. Os dados do IRR podem ser usados por qualquer pessoa com o objetivo de obter informações para depurar, configurar e planejar endereçamento e política de roteamento. Resumidamente, o IRR e ferramentas associadas:

  • facilitam a validação do conteúdo de mensagens dos anúncios BGP
  • permitem mapear um ASN em suas respectivas redes
  • permitem a definição de políticas de roteamento bem mais amplas do que através de filtros, nos roteadores
  • gera configurações para roteadores

O IRR foi criado em 1995 na época em que os provedores de acesso à Internet do mundo estavam se preparando para o final da atividade do backbone da NSFNET e, comemorando o primeiro aniversário da Internet comercial. Por volta de 1999, haviam os seguintes repositórios: CA*Net, no Canadá, o ANS, CW e RADB nos EEUU e o RIPE na Europa. Os três primeiros eram privativos e os dois últimos, públicos. Atualmente, os repositórios cresceream e uma lista das bases de dados IRR pode ser vista, preferencialmente, na página do sítio oficial do IRR reproduzidas abaixo.

  • ALTDB
  • AOLTW
  • APNIC
  • ARIN
  • BCNET
  • BELL
  • DERU
  • DIGITALREALM
  • EASYNET
  • EBIT
  • EPOCH
  • GT
  • GW
  • HOST
  • JPIRR
  • LEVEL3
  • REACH
  • RETINA
  • RGNET
  • RIPE
  • RISQ
  • ROGERS
  • SAVVIS
  • WVFIBER

A principal base é o RADB. As outras bases são periféricas e usam o RADB de duas possíveis maneiras:

  1. Espelhamento bi-direcional.
  2. Espelhando o RADB e outras bases (espelhamento unidirecional).

Em ambos os casos, usa-se o servidor IRRd. O espelhamento unidirecional nem sempre é somente com o RADB para o IRRd e é muito usado por grandes concessionárias para manter os servidores, disponíveis mais próximos de seus clientes.

Algumas bases são de uso gratuito, como a ALTDB e são bidirecionais. Não mais do que 10 minutos são necessários para que o RADB atualize uma inclusão ou alteração sobre seus servidores homologados, como o caso do Pegasus IRR.

Os dados do IRR podem ser obtidos, também, via whois, como já vimos. Os recursos para obter informação do IRR via o whois são enormes e ao longo do treinamento estudaremos os diversos formatos.

É possível obter os dados atualizados das bases que são espelhadas e da própria base do RADB, [1] e, usar diversas ferramentas disponíveis gratuitamente, na Internet para pesquisá-las.

Em [2] é possível pesquisar todos os objetos disponíveis nas bases IRR, para um mesmo mantenedor. Testem, por exemplo, com MAINT-AS28182. MAINT-ASn é o formato preferido (e recomendado) para o nome de um mantenedor, embora não seja um formato obrigatório. Sendo o formato preferido, todo mundo usa. Vamos usá-lo, portanto apesar de não ser a sugestão do artigo “Some practical advice on using the IRR”, do Merit. Alternativamente, em [3] , ainda em desenvolvimento pode-se pesquisar de maneira simples.

Recomendamos a leitura da apresentação “APNIC Internet Routing Registry”. Na sequência vale a pena ler uma interessante avaliação em “A Survey On Utilization of IRR’s Route Objects”. Ambos na BC.

Eis algumas ferramentas para usar/pesquisar uma base IRR, de forma inegrada:

  • IRRToolSet: ferramenta para análise de políticas de roteamento e geração de configurações para roteadores a partir das informações contidas no IRR. A versão, 4.8.6, pode ser obtida aqui e, em [4], muitas informações adicionais e o candidato à versão 5.0.
  • IRR Power Tools: é uma coleção de utilitários que permite facilmente pesquisar, gerenciar e utilizar as informações de roteamento contida no IRR (http://sourceforge.net/projects/irrpt/)
  • ASLookup: é uma ferramenta para pesquisar a sequência de um ASN que esteja registrado no IRR e o retorno da primeira linha de descrição de um objeto AS. Através do ASLookup podemos pesquisar diversos números de AS, usar o resultado do “show ip bgp” e, descobrir um AS a partir de um endereço IP. Obtenham em http://aslookup.bgpview.org/index-e.html.

Conhecer as ferramentas disponíveis será importante para que possamos definir de forma correta as configurações dos objetos que deveremos incluir na base IRR. Nas próximas aulas iremos começar a atividade prática. As recomendações de leitura não precisam ser consultadas, sob o ponto de vista prático, É recomendação adicional para os que fazem do BGP uma ferramenta de trabalho. Nesse caso seria bom enfrentar o curso do RIPE, “Routing Register Training Course”. Recomenda-se o uso do PEGASUS IRR. É a melhor maneira de compreender as entre-linhas das aulas, nesse treinamento. Não se deve preocupar em errar, eventualmente. Em computação, o erro, contribui para a aprendizagem (a não ser que tenha sorte, [5]). Finalmente, uma geral sobre o sítio Overview of the IRR é o exercício desse segmento.

 

Itens relacionados:

 

 

Referências

 

[1] Bases de dados do IRR, associadas ao RADB.
[2] Whois do RADB.
[3] Whois do Pegasus IRR.
[4] Wiki do IRRToolSet
[5] Erl, T., SOA Princípios de design de serviços, Pearson Prentice Hall, São Paulo, 2009.

Categorias:IRR, Sem categoria
%d blogueiros gostam disto: