Arquivo

Archive for the ‘IRR’ Category

BGP no Mikrotik (VIII): Alterando a política de roteamento

Dai ao roteador o que é do roteador e ao firewall o que é do firewall.
Autor desconhecido


Atualizado em: 03/11/2012: Inclusão da foto do Moreiras, registrando seu competente trabalho na implementação do IPv6, no Brasil, junto com sua Equipe.
Atualizado em: 10/04/2011: Inclusão da referência 10 relacionada com rota ping-pong.

Introdução

As razões pelas quais nos levam a alterar a política de roteamento, criada originalmente pelo BGP podem ser classificadas nas seguintes categorias:

  • Interesses internos ao Sistema Autônomo
  • Interesses bilaterias do empareamento
  • Interesses multilaterais do empareamento
  • Segurança das sessões BGP

Os recursos disponíveis para alterar a política de roteamento, nas categorias acima são:

  • Manipulação de atributos
  • Estabelecimentos de filtros

Manipulação de atributos

No texto anterior (Parte VII) vimos um exemplo, no qual o atributo allow_as_in foi usado para alterar (ou forçar) o rumo do tráfego. Naquele exemplo a política do BGP, ao usarmos allow_as_in no BGP que fala MK6, era o melhor caminho, através do MK7. Ao retirarmos o atributo allow_as_in do empareamento com o MK7, o tráfego passou a ser encaminhado através do MK5. Em textos anteriores lembramos o uso de outros parâmetros, como o as_path, através do qual inibimos (isto é, bloqueamos), tráfego vindo de MK1 na direção de MK2. Oportunamente veremos atributos poderosos e transitivos* (ultrapassam a barreira da limitação hop_by_hop), como comunidades e confederações. Manipulação de atributos do BGP para alterar políticas de roteamento dependem, demasiadamente, do conhecimento e sobretudo, da experiência do administrador do AS. Um dos componentes mais complexos do BGP!

Filtros em BGP

Filtros representam uma poderosa opção para alterar política de roteamento e, em particular, são muito utilizados para garantir segurança do BGP que fala (ou roteador de borda), seus dependentes e seus vizinhos. Quando falamos em segurança, há uma natural confusão com firewall. Embora filtro no BGP seja uma forma de firewall, não podemos confundir as duas técnicas. Filtro é mais especializado, no sentido de que é um recurso do BGP, direcionado a alterações de roteamento (isto é, manipulação da tabela de roteamento), seja por interesse específico do administrador do AS ou por razões de segurança. É de uso imediado e mais fácil do que firewall. Nada mais verdadeiro do que a máxima citada no início deste texto.

 



* A transitividade é opcional no BGP. Pode ou não ser reconhecida por alguns BGPs que falam. A transitividade é preservados e anunciados para todos os empareados vizinhos, através de mensagens UPDATE e nela permanecerá enquanto durar. ([2]).


 

Relacionamentos bilaterais e multilaterais no BGP

Face a restrição do mecanismo hop-by-hop os relacionamentos entre BGPs que falam só existem, automaticamente, com outros BGPs que falam vizinhos.

Atributos transitivos podem ser usados para relacionamento entre BGPs que falam não vizinhos. Devemos lembrar, entretanto, que em ambos os casos (vizinhos e não vizinhos), geralmente é necessário contato com os respectivos administradores uma vez que atributos transitivos não são obrigatórios. Mas são mantidos, nas mensagens de UPDATE do BGP.

A forte integração entre os BGPs que falam empareados contrasta com a falta de integração com os outros, não vizinhos. Não fosse isso, muitos dos problemas da Infraestrutura da Internet estariam resolvidos, tal como o sequestro de IPs, por exemplo. Existem vários recursos disponíveis para aliviar a falta de integração entre administradores de ASes. Entre eles, se destacam:

  • O telefone do INOC, uma iniciativa do PCH (Packet Clearing House), que o Nic.br oferece gratuitamente para todos os ASes brasileiros e iniciativas semelhantes existem no mundo inteiro. Há uma lista disponível no sítio do PCH (http://www.pch.net). Infelizmente, muitos ASes brasileiros nem sabem de tal facilidade e, pior, a grande maioria dos telefones existentes, não funcionam. No Brasil, provavelmente será necessário intervensão forte do Nic.br, para o uso eficaz e, divulgação intensiva sobre o propósito do INOC.
  • O IRR, cujas informações detalhadas podem ser encontradas em http://irr.abranet.org.br (primeira base de IRR brasileira, neutra e de uso gratuíto). Um instrumento poderoso de relacionamento constituido de bases de dados distribuidas, onde os administradores de ASes inserem suas políticas de roteamento, que se tornam disponíveis para outros administradores de ASes. Apesar de sua genialidade o IRR sofre pelo desprezo/desinteresse dos administradores de ASes e não em sido usado de maneira eficiente e eficaz.
  • Outras bases de integração tais como: Whois, LG (Looking Glass), PeeringDB (do PCH), RIS, BGPMon, CIDR Report, BGP Update Report, Weekly Routing Table Report e outras reconhecidas pela comunidade internacional. Boa parte delas podem ser usadas para apoio ao monitoramento necessário aos administradores de ASes, também.

Etapas para o uso de filtros, em BGP

Cada administrador de AS tem seu próprio estilo ou acaba tendo um estilo próprio, para administrar e cuidar de seu Sistema Autônomo. Geralmente isso é o que vale. Mas, o ser humano precisa de ajuda. Há discursões filosóficas dizendo que vivemos sob uma lógica perversa: o que não sabemos é mais relevante do que sabemos** e, também, só aprendemos o que já conhecemos. Nossas experiências pessoais comprovam isso. Quantas vezes não temos de ler um artigo (técnico, principalmente), várias vezes, para entendermos com segurança um assunto novo?

Também para nós, administradores de AS, o imponderável é mais importante do que o previsível. Quando se trata do BGP, o imponderável pode ser, uma falha involuntária causada por um administrador (experiente ou inexperiente), por exemplo***.

Achamos que é sempre bom lembrar, face à complexidade do BGP, cinco tópicos importantes quando formos estabelecer um BGP que fala:

  • Planejar
  • Documentar
  • Testar
  • Implementar
  • Monitorar

A seguir faremos rápidos comentários abordagem sobre cada um. Em mente o fato de que não estamos escrevendo um compêndio sobre administração de recursos. Como Infraestrutura da Internet é algo muito parecido com uma disciplina da Logística, denominada “PCP – Planejamento e Controle da Produção”, a base do debate foi retirada e adaptada de [4], um texto suave, completo e fácil de ler/entender. A motivação é a aprendizagem: onde podemos encontrar recursos/conhecimento que nos ajudem atravessar os cinco tópicos?

 



** É a lógica do Cisne Negro, proposta por Nassim Nicholas Taleb, em [3]. Parece ser, realmente, um interessante paradigma. Na recente (07/04/2011) e incompreensível tragédia que ocorreu na escola de Realengo, RJ o que nos interessa é avaliar nossa tradicional incapacidade de prever o curso da história. Se o episódio fosse por nós concebível, a polícia estaria logo cedo na escola. Segundo Taleb nossa fraqueza reside no fato não analizarmos os dados espúrios resultantes das estatísticas (outliers). Mas, Taleb, não consegue responder ao imponderável, ainda. Dor imensa e infinita, a Escola Municipal Tasso da Silveira, foi citada porque permanecerá presente, em nossa memória, pelo resto de nossos dias. É possível citar um exemplo específico e prático, associado ao Sequestro de IPs. O roteador que primeiro recebeu o anúncio de um possível sequestro, não deveria permitir a progressão da mensagem de UPDATE ou, marcaria a mensagem UPDATE como suspeita. Uma consulta (confiável). a uma base IRR (confiável) ou ao PeeringDB (confiável) assimilaria tal expectativa. Acabaríamos com os riscos inerentes ao Sequestro de IPs.


*** Outra ilustração que fortalece a noção do imponderável, no BGP é o que denominamos rota ping-pong (do inglês, route flapping). Rota ping-pong é o anúncio de prefixo e retirada desse anúncio, de forma repetitiva, pelo BGP que fala. Um exemplo que pode causar a rota ping-pong é a interrupção intermitente em uma interconexão do roteador de borda. A RFC4271, [1], no Apêndice F, recomenda que as implementações de BGP devem disponilizar mecanismos ao gerador da rota ping-pong (BGP que fala) para atenuar ou identificá-la. A RFC2439, [9] recomenda as técnicas para implementar. A rota ping-pong pode causar danos graves no processo de convergência do BGP, [5]. Os problemas gerados pela rota ping-pong podem ser graves a ponto de afetar a estabilidade da Internet. Tal fato tem levado a algumas intituições no estudo de problemas relacionados, usando uma metodologia denominada BGP Beacons e que se refere ao registro do comportamento de anúncios e retiradas de anúncios de prefixos, [6]. Tais comportamentos são registrados em bases de dados a partir da coleta de mensagens de UPDATE do BGP e disponibilizados para estudos, pesquisas e avanços na defesa do imponderável, em BGP, entre outros. Tais bases são geralmente públicas, como Oregon’s Route Views [7] e a base RIS, do RIPE Routing Service (em [8], para maiores informações). Vários fabricantes de roteadores implementaram mecanismos de prevenção contra rota ping-pong. Eles são chamados de route flap damping [9], ou route flap dampening, por alguns autores e, implementam um mecanismo de penalidades para anúncios que estejam provocando o que poderia vir a ser um ping-pong de prefixos. Tal mecanismo, avalia a frequência dos anúncios ou retiradas de anúncios, na tentativa de identificar se está ocorrendo excessos ou intermitência Até a data de publicação deste texto, não conseguimos referências precisas, de tais implementações no Mikrotik. Oportunamente haverá um texto a respeito do roteamento ping-pong e as bases de dados de BGP Beacons.


 

Planejamento

O Planejamento do BGP que fala é um bom momento para aumentar nosso conhecimento sobre o BGP. A sugestão é focar em dois pontos importantes:

  • Segurança
  • Filtros

Um dos melhores locais para ambas as alternativas acima é o sítio do Team-Cymru. Eis uma relação de material muito útil:

Outro excelente ambiente é o sítio do PCH. Responsável pelo INOC-DBA, possui um vasto material. Em particular iremos usar BGP Best Practices for ISPs Prefix List, AS PATH filters, Bogon Filters, Anycast, Mailing Lists, INOC DBA, referente a uma palestra dada por Gaurab Raj Upadhaya, do PCH, em um encontro da ARIN.

Destaque para documentos da Cisco, Juniper e outros. Todos úteis e interessantes. A Juniper tem um glossário excelente, que pode ser obtido aqui.

Documentação

O tipo de documentação em uma implementação de BGP é muito variada. Temos anotações sobre uso de IPs, Loopbacks (que um BGP que fala pode usar muito), e-mails, contratos de empareamento, senhas, acordos bilaterais e multilaterais. Para cada uma existe uma ferramente interessante. Uma ótima alternativa é o Zope+Plone. Há várias vantagens neste recurso: possui base de dados relacional, é fácil de mexer, tem um sistema de autenticação bastante sofisticado e um mecantismo de pesquisa poderoso e rápido.

O problema de ferramentas como o Plone acima é que estamos adicionando mais um componente que deve ser vigiado ou mantido, embora o Plone seja bastante estável e rode em Windows, *BSD e qualquer distribuição Linux. Muito fácil de instalar e usar. Já vimos exemplo de uso de sistemas de blogue como o WordPress instalado em uma máquina local ou blogue do Google, fechado e privativo. o Google Apps parece ser, uma ótima escolha, também.

Mas são sugestões já que o estilo e experiência de cada um irão conduzir as alternativas mais adequadas.

Teste

Há excelentes ferramentas de simulação de redes, com BGP, sob as quais podemos exercitar o que pensamos/planejamos em relação a uma implementação BGP. A melhor delas é sem dúvida a do pessoal do Nic.br responsável pelos cursos de IPv6. Aprende-se muitíssimo nos cursos de IPv6, ministrados pelo Antonio Moreiras, Rodrigo Santos e Equipe. Toda a documentação do laboratório e muitas outras excelentes informações podem ser encontradas no sítio do IPv6.br.

 

Com o Antônio “IPv6” Moreiras, no aeroporto de Montevidéu.
Retornando do LACNIC18.

Monitoramento

Uma ferramenta da Cisco muito interessante, mas com orientação restrita a seus roteadores e, limitações em relação ao BGP. Inclui, wireless e VoIP. Informações detalhadas estão aqui. Ele é distribuido gratuitamente!

O destaque fica com o FFE (Fábrica Fictícia de Encaminhamento ou 111111111110). O FFE está descrito aqui neste blogue e a grande vantagem está na simplicidade de implementação, diversidade e escalabilidade. O FFE já tem roteadores Cisco, 3Com, Quagga, Mikrotik e outros planejados. Sua integração remota é um dos pontos fortes. Ele foi desenhado tendo como base a experiência no laboratório do Nic.br e no espírito do projeto Geni, guardada as devidas proporções! O FFE tem sido muito útil no desenvolvimento dos textos sobre BGP no Mikrotik, em testes e deve sua principal motivação em um projeto de aplicação da Logística na Infraestrutura da Internet. O FFE possui licença CrativeCommons, assim como tudo o que se apresenta de original aqui no blogue de Infraestrutura da Internet.

Implementação

A implementação concentrará, nos filtros do BGP, já que a implementação do BGP, em si, já foi abordada. Virá nos artigos subsequentes, com o objetivo de evitar textos longos e maçantes. A base para pensar nos filtros foi descrita faltando a abordagem sobre a tecnologia de uso dos roteadores para que eles sejam implementados. Em particular, do Mikrotik.

Monitoramento de nossa implementação de BGP difere das formas tradicionais que usamos para monitorar conexões e conectividade nas implementações tradicionais. Nossa implementação BGP precisa ser olhada, também, nos confins da Internet, fora de nosso limite de ação.

Eis as ferramentas recomendadas:

  • Diversas ferramentas disponíveis para implementações locais: http://www.bgp4.as/tools
  • LG (Lookin Glass):
  • MyASN: É um serviço oferecido pelo RIPE, como um alarme para acontecimentos anormais em relação a um AS específico e seus prefixos. Informações em: http://ttm.ripe.net/alarms/docs.
  • BGPMon: É um outro serviço de monitoramento de AS e prefixos. Semelhante ao MyASN. Informações em: http://bgpmon.net/.
  • Route Views: Um dos mais famosos coletores é o University of Oregon Route Views Project, que atualmente estabeleceu um coletor no PTTMetro-SP: http://www.routeviews.org/saopaulo.html. Na realidade existem coletores espalhados pelo mundo inteiro onde os interessados em ajudar, estabelecem um empareamento. O caso de São Paulo, no PTT-Metro o esquema difere, pois a coleta é direta no RouteServer.
  • PeeringDB: É uma base de dados de ASes interessados em registrar seus empareamentos e outras informações sobre políticas de roteamento. Um AS, assim que estabelecer um empareamento via BGP deve se cadastrar no PeeringDB, tamanha sua importância como recurso de pesquisa e monitoramento. Informações: http://www.peeringdb.com.
  • The CIDR Report: Interessante ferramenta de pesquisa e monitoramento mantida pelo Geoff Huston. http://www.cidr-report.org/as2.0/. Semanalmente ele publica em algumas listas, um resumo das atividades da Internet no mundo. O documento é postado nesse blogue, também toda semana. Geoff Huston mantem um outro sítio muito interssante: http://www.potaroo.net/.
  • Weekly Routing Report: Relatório estatística e semanal que também é postado no blogue de Infraestrutura da Internet oritinado pelo roteador do APNIC no Japão. Dados históricos podem ser encontrados aqui: http://thyme.rand.apnic.net
  • BGP Update Report: Outra iniciativa do Geoff Huston, semanalmente postado no blogue Infraestrutura da Internet e maiores informações podem ser obtidas aqui: http://bgpupdates.potaroo.net
  • Robtex: Outra alternativa ao CIDR-Report: http://www.robtex.com/

Naturalmente existem outras referências que já existem ou foram criadas. Sempre que possível, manteremos atualizada a lista acima. Algumas não merecem, entretanto o registro. Essas faremos comentários precisos, como anunciado em epílogos de alguns dos textos do blogue na oportunidade de nossa abordagem sobre Sequestro de IPs. Infelizmente, serão abordagens inusitadamente desagradáveis, mas que não podem deixar de ser expostas, face a origem de suas iniciativas e os danos provocados.

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).
  2. Russ White, Danny McPherson, Srihari Sangli, Practical BGP, Jul 6, 2004,Addison-Wesley Professional.
  3. Nassim Nicholas Taleb, A lógica do Cisne Negro – O Impacto do altamente improvável. Editora Best Seller.
  4. Idalberto Chiavenato, Planejamento e Controle de Produção. Manole 2008.
  5. Julião Braga, Convergência, no BGP. Infraestrutura da Internet em 20/01/2011. Disponível em: https://juliaobraga.wordpress.com/2011/01/20/convergencia-no-bgp/. Acessado em 09/04/2011, 09:32.
  6. Z. Morley Mao, Randy Bushy, Timothy G. Griffinz, Matthew Roughanx, BGP Beacons.IMC ’03 Proceedings of the 3rd ACM SIGCOMM conference on Internet measurement ACM New York, NY, USA ©2003.
  7. University of Oregon Route Views Archive Project. Disponível em: http://www.routeviews.org. Acessado em 09/04/2011, 10:41.
  8. Erik Romijn, Routing Information Service (RIS) raw Dataset. Disponível em: http://labs.ripe.net/datarepository/data-sets/routing-information-service-ris-raw-data-set. Acessado em 09/04/2011, 10:41.
  9. RFC2439, BGP Route Flap Damping C. Villamizar, R. Chandra, R. Govindan [ November 1998 ] (TXT = 86376) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  10. Christian Panigl, Joachim Schmitz, Philip Smith, Cristina Vistoli, RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parametershttp (RIPE-229). Disponível em: http://ftp.bme.hu/documents/ripe/ripe-229.txt. Acessado em 10/04/2011 08:28.
Anúncios

BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup

Atualizado em 12/05/2001: Deixar claro que weight não é um atributo do BGP.

Introdução

O FFE é um ambiente dinâmico! MK3 decide que o enlace com MK1 deve ficar como alternativa de tráfego somente se o tráfego via MK2 falhar. As justificativas dessa escolha são muitas: enlace para o MK1 tem banda pequena ou está com falhas intermitentes ou … A Figura 1, que segue mostra como ficaria a topologia do FFE com a decisão de MK3. Na figura, o enlace alternativo esta em vermelho.

 

Figura 1: Topologia do FFE do enlace de backup do MK3.

 

Análise da situação anterior

Um traceroute do MK5 até a Loopback do MK3, mostra que o tráfego passa no menor caminho de MK1 para MK3, que é o enlace direto (sem o MK2 na jogada).

[admin@MK5] > tool traceroute 10.203.0.1
   1     10.204.0.21 30ms 1ms 1ms 
   2     10.201.0.17 3ms 1ms 1ms 
   3     10.203.0.1 3ms 6ms 3ms

Mais claro ainda, se verificássemos as rotas em MK1. A rota ativa para o MK3 é via o enlace sobre o qual se deseja como alternativo.

[admin@MK1] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 7 ADb  10.203.0.0/23                      10.201.0.14        20      
 8  Db  10.203.0.0/23                      10.201.0.6         20

O inverso, isso é, o tráfego saindo de MK3, também passa pelo enlace direto de MK3 a MK1. Por exemplo, as rotas ativas em MK3 apontam diretamente para MK1, ignorando MK2:

[admin@MK3] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.201.0.13        20      
 1  Db  10.201.0.0/23                      10.202.0.9         20      
 2 ADC  10.201.0.12/30     10.201.0.14     ether2             0

Já o traceroute para a Loopback do MK5, por exemplo é mais claro:

[admin@MK3] > tool traceroute 10.205.0.1
     ADDRESS 
   1     10.202.0.9 4ms 1ms 1ms 
   2     10.201.0.5 1ms 1ms 1ms 
   3     10.201.0.18 2ms 2ms 1ms 
   4     10.205.0.1 4ms 2ms 1ms

O caminho inverso, do MK5 para o MK3 mostra o que ocorre com um traceroute na direção da Loopback do MK3:

[admin@MK5] > tool traceroute 10.203.0.1
     ADDRESS  
   1     10.204.0.21 5ms 1ms 1ms 
   2     10.201.0.17 3ms 1ms 1ms 
   3     10.203.0.1 3ms 1ms 1ms

Finalmente vamos repetir, pela terceira vez, o fato do BGP não anunciar para um empareado vizinho, os blocos pertencentes a tal vizinho. Um comportamento (ou propriedade), que pode ser visto na tabela de anúncios, do MK1, o principal foco do desejo de MK3, onde MK1 não anuncia para MK3, o bloco 10.203.0.0/23. Uma propriedade, que faz parte do processo de decisão do BGP descrito em complexo detalhamento, na RFC4271, em [1], novamente a principal referência. Não há como entrar em detalhes nesse texto, exclusivamente prático. Lembrar, entretanto é fundamental, para o que segue.

Filtros no BGP

Atender ao MK3 significa usar filtros, no BGP nele implementado. Umas das formas de filtrar, no BGP é indicar, para cada par, os respectivos nomes dos filtros de entrada e de saída. A Figura 2 mostra onde fazer isto, no Mikrotik.

 

Figura 2: Especificando filtros no BGP.

 

MK3 tem dois vizinhos BGP, o MK1 e o MK2. A Figura 3 mostra os respectivos nomes escolhidos.

 

Figura 3: Nomes escolhidos para os filtros BGP do MK3, para cada empareado vizinho.

 

Onde especificar os filtros

Nomeado os filtros, o próximo passo é defini-los. O local, no Mikrotik, onde isso é feito, está mostrado na Figura 4. (OBS: Leia-se MK1_out ao invés de MK2_out no lado esquerdo da figura).

 

Figura 3: Nomes escolhidos para os filtros BGP do MK3, para cada empareado vizinho.

 

Planejando os filtros do MK3 com vistas ao enlace de backup

Se desfizermos o enlace para MK1, teríamos o desejo de MK3, exceto pelo fato de não haver um backup. O enlace para MK1 estaria fora definitivamente. Mas podemos, no FFE, fazer isso e mostrar o traceroute do e para o MK5.

Do MK5:

[admin@MK5] > tool traceroute 10.203.0.1
     ADDRESS 
   1     10.204.0.21 5ms 1ms 1ms 
   2     10.201.0.17 1ms 1ms 2ms 
   3     10.201.0.6 6ms 1ms 1ms 
   4     10.203.0.1 3ms 1ms 1ms


Para o MK5:

[admin@MK3] > tool traceroute 10.205.0.1       
     ADDRESS
   1     10.202.0.9 2ms 1ms 1ms 
   2     10.201.0.5 1ms 1ms 1ms 
   3     10.201.0.18 2ms 2ms 2ms 
   4     10.205.0.1 3ms 2ms 2ms

Os dois traceroutes acima, com a parada do BGP do MK3 para o MK1 foi somente para ilustrar e, não resolve o problema do MK3. Retornamos o BGP entre MK3 e MK1 e começamos a pensar dividindo-o em dois outros: nenhum tráfego sai de MK3 diretamente via MK1 e, nenhum tráfego entra em MK3 diretamente via MK1 exceto se o enlace de MK2 a MK3 for rompido involuntariamente.

 

Nenhum tráfego entra em MK3 diretamente via MK1

Com o tempo veremos que existem diversas alternativas de filtros que causam o efeito que se deseja. A diversidade de filtros está diretamente ligada à experiência do adiministrador do BGP. O FFE é um excelente instrumento para exercitar.

Sabemos que o MK1 envia tráfego para o MK3 pelo menor caminho ou menor as_path. Vamos ver os anúncios e as rotas atuais e ativas, em alguns dos MKi, em relação ao MK3:

Rota do MK1 para MK3:

[admin@MK3][admin@MK1] > ip route print where active              
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 ...     
 6 ADb  10.203.0.0/23                      10.201.0.14        20      
 ...      


Anúncios do MK1 para MK4, dos blocos de MK3 e de MK2:

[admin@MK1] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH
...    
MK4      10.203.0.0/23        10.201.0.17      65533       
...      
MK4      10.202.0.0/23        10.201.0.17      65532
...


Anúncios do MK2 para MK1, dos blocos de MK3 e de MK2:

[admin@MK2] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH                                         ORIGIN     LOCAL-PREF
...    
MK1      10.203.0.0/23        10.201.0.6       65533      
...      
MK1      10.202.0.0/23        10.201.0.6
...

Na última listagem acima, quando o MK2 anunciar para MK1, ele irá preceder o as_path com o seu ASN, como é do nosso conhecimento. Então, o anúncio do bloco do MK3, terá dois ASNs e o do bloco do MK2, somente um ASN. Continuando …

Anúncios do MK2 como chegam no MK1, somente para os blocos de MK2 e MK3. E, não estamos interessados no next_hop, pois já sabemos que irá indicar a interface do MK2:

10.203.0.0/23  vindo de MK2  65532, 65533         
10.202.0.0/23  vindo de MK2  65532

Agora, podemos pensar nos anúncios feitos do MK3 para o MK1. O MK3 precede o as_path de seu bloco com seu próprio ASN. Então, o anúncio de MK3 chega da seguinte forma em MK1:

10.203.0.0/23  vindo de MK3  65533         

Observando as duas últimas referências do bloco de MK3, o tráfego vai de MK1 para MK3 porque é sempre o menor caminho (ou menor as_path). Claro, não é nenhuma novidade para nós!

Por outro lado, também sabemos que podemos preceder o ASN de MK3, em todos os anúncios feitos pelo MK3, tantas vezes quanto desejarmos. Para fazer isto, usamos os filtros. Em resumo, queremos que todos os anúncios feitos do MK3 para o MK1 sejam precedidos por tantos ASN do MK3 de tal maneira que o menor as_path para o MK3 seja via o MK2! Quantas vezes devemos preceder o ASN de MK3? Boa pergunta. O FFE permite o exercício, facilmente. Vamos preceder somente uma vez. Em TODOS os anúncios de MK3 para MK1. Isso implica que a saida para MK1 deve ser violada. Ou seja, via um filtro sobre MK1_out. Usando as figuras que seguem vamos ilustrar tais filtros. Mas antes, vamos preceder o anúncio, somente, no bloco 10.203.0.1/23 e testar com o traceroute.

 

Figura 4: Precedendo o ASN de MK3 em seu próprio bloco.

 

Na Figura 4, exibimos três componentes de um mesmo filtro. O primeiro, na aba Matchers, onde escolhemos Chain, com o nome de MK1_out (há uma lista que não nos deixa errar). Na mesma aba, incluímos o bloco do MK3, em Prefix. Na aba Actions, mantemos passthrough como a ação a ser executada e falaremos sobre ações em outro momento. Finalmente, na aba BGP Actions, em Set BGP Prepend Path, incluimos o ASN de MK3.

Um traceroute, já é suficiente para percebermos que o resultado está como desejávamos:

[admin@MK5] > tool traceroute 10.203.0.1
     ADDRESS  
   1     10.204.0.21 1ms 1ms 1ms 
   2     10.201.0.17 3ms 1ms 1ms 
   3     10.201.0.6 1ms 1ms 1ms  <== Via MK2
   4     10.203.0.1 2ms 1ms 2ms 

Com o objetivo de responder á pergunta de quantas precedências, vamos bloquear o enlace para MK1 via MK2 e dar uma olhada no anúncio de MK3. Não há necessidade de verificar a tabela de rotas porque já sabemos que se não existe MK2 a rota para MK3 é feita via o enlace MK1/MK3.

O anúncio mais ilustrativo é o do MK5.

[admin@MK5] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK4      10.206.0.0/23        10.204.0.22      65536   
MK4      10.226.0.0/24        10.204.0.22      65536  
MK4      10.226.1.0/24        10.204.0.22      65536
MK4      10.205.0.0/23        10.204.0.22 
MK6      10.207.0.0/23        10.205.0.25      65534,65531,65533,65532,65537 <=== **
MK6      10.201.0.0/23        10.205.0.25      65534,65531
MK6      10.203.0.0/23        10.205.0.25      65534,65531,65533,63533   <=== Precedência do ASN MK3
MK6      10.202.0.0/23        10.205.0.25      65534,65531,65533,65532
MK6      10.204.0.0/23        10.205.0.25      65534
MK6      10.205.0.0/23        10.205.0.25

Como indicado, o anúncio para o MK6 inclui duas vezes o ASN de MK3. Mais interessante, entretanto, está o anúncio do MK5 do anúncio para MK6, com **. Antes de retornarmos o enlace de MK1/MK2 vamos alterar a precedência em MK3, retirando o Prefixo 10.203.0.0/23 do filtro estabelecido. Ao fazermos isso, o filtro será para qualquer bloco. Em seguida repetimos a lista de anúncios em MK5:

[admin@MK5] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH
MK4      10.206.0.0/23        10.204.0.22      65536 
MK4      10.226.0.0/24        10.204.0.22      65536
MK4      10.226.1.0/24        10.204.0.22      65536
MK4      10.205.0.0/23        10.204.0.22 
MK6      10.207.0.0/23        10.205.0.25      65534,65531,65533,63533,65532,65537 <== **
MK6      10.201.0.0/23        10.205.0.25      65534,65531
MK6      10.203.0.0/23        10.205.0.25      65534,65531,65533,63533 <== **
MK6      10.202.0.0/23        10.205.0.25      65534,65531,65533,63533,65532  <== **
MK6      10.204.0.0/23        10.205.0.25      65534 
MK6      10.205.0.0/23        10.205.0.25

O ** indica uma dupla repetição do ASN do MK3. Como MK1/MK2 está fora do ar, o caminho para o MK2 é via MK3. Voltaremos, nesse instante o enlace MK1/MK2 à normalidade.

Resolvemos, então, a primeira parte da equação que atende à expectativa de MK2. Vamos à outra! Mas antes vale lembrar que poderíamos ter feito o mesmo usando o atributo MED, conforme vimos no texto anterior. Quando maior o valor do MED, maior a prioridade do tráfego. O valor do MED influencia o vizinho do BGP que fala (neste contexto, o MK3). Se desejamos que o tráfego venha todo por MK2, então devemos filtrar a saída para MK2, aumentando o MED, cujo valor padrão no Mikrotik é zero. Em outro exemplo usaremos o atributo MED, para ilustrar.

Há uma outra observação importante e final, sobre o que fizemos no MK3, alterando o as_path. Ao fazer isso, alteramos a política de roteamento, do MK3. Tal lembrança será muito importante ao comentarmos sobre o IRR e o FFE.

Nenhum tráfego sai do MK3 diretamente via MK1.

Não queremos resolver esse problema pedindo ajuda a MK1 e/ou MK2, vizinhos imediatos de MK3. Queremos que MK3 resolva esse problema, impedindo tráfego de saída pelo MK1, exceto se MK2 falhar. Assim com vimos acima que os atributos as_path e MED influenciam o tráfego de entrada, dois outros mecanismos influenciam o tráfego de saída do BGP que fala. São: o atributo local_pref e o não-atributo weight. Vamos falar sobre eles agora.

O atributo local_pref e o mecanismo weight

Estes dois mecanismos influenciam o tráfego de saída. O local_pref é um atributo definido na RFC4271, [1], como sendo um atributo que pode ser incluído em mensagens de UPDATE enviadas pelo BGP que fala para seus empareados internos (iBGP!). Mensagens de UPDATE enviadas pelo BGP que fala para seus pares externos NÃO pode conter o atributo local_pref exceto se estiver estabelecido uma Confederação (sobre o qual discutiremos em outra oportunidade). Assim, não será possível usarmos o local_pref na topologia atual do FFE, pois só temos eBGP

Felizmente, a Cisco criou o mecanismo weight (que não é um atributo!). Esse mecanismo não está definido na RFC4271, [1]. Como falamos, ele influencia no tráfego sai e seu valor padrão é zero (tal valor pode ser outro, dependendo da implementação). Então, podemos usá-lo pois quase todos outro fabricantes o implementam, também, face à sua imensa utilidade. Para isso iremos definir um filtro de entrada para o MK2, com o valor, abritrário 100, no parâmetro Set BGP Weight da aba BGP Actions, em filtros de roteamento BGP. Podemos ver esse caminho do Mikrotik, na figura 4, acima.

Antes da aplicação do mecanismo weight, o resultado de um traceroute a partir do MK3 na direção da Loopback do MK5 é o seguinte:

[admin@MK3] > tool traceroute 10.205.0.1
     ADDRESS 
   1     10.201.0.13 2ms 1ms 1ms   <== Direto por MK1
   2     10.201.0.18 1ms 1ms 1ms 
   3     10.205.0.1 2ms 1ms 1ms

Após a aplicação do weight (com o valor 100, em MK1), o resultado de um traceroute a partir do MK3 na direção da Loopback do MK5 é o seguinte:

[admin@MK3] > tool traceroute 10.205.0.1
     ADDRESS
   1     10.202.0.9 35ms 1ms 1ms   <=== Via MK2
   2     10.201.0.5 20ms 1ms 1ms 
   3     10.201.0.18 4ms 4ms 2ms 
   4     10.205.0.1 2ms 2ms 2ms

Assim, resolvemos o problema de MK3. O tráfego não sai e nem entra via, diretamente, o MK1, exceto se MK2 estiver fora em ambos os enlaces que ele possui.

Talvez haja uma dúvida no ar: porque foi usado o weight em um filtro de entrada para o MK3 (no caso filtro sobre o MK2_in)? A questão é importante. Portanto, vale a pena pensar a respeito!

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).

Categorias:BGP, IRR, Mikrotik, TCP/IP

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!

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

Curso IRR – Parte IX: objeto aut-num

Introdução

A referência [2] é uma descrição da RPSL (Routing Policy Specification Language) e foi atualizada por [3], que estende para IPv6. É uma linguagem muito poderosa, que permite aos administradores e operadores de redes especificarem políticas de roteamento em vários níveis e, escalável, ou seja, preparada para receber especificações de novos protocolos que, eventualmente, surjam no futuro. Finalmente, foi projetada com a expectativa de estabelecer políticas de roteamento globalmente que permitissem, cooperativamente, sua manutenção através de bases de dados distribuídas devidamente homologadas ou reconhecidas.

Definindo políticas de roteamento através da RPSL os administradores de ASes:

  • Melhorariam, cada vez mais, a integridade do roteamento na Internet.
  • Usariam ferramentas, que a partir do alto nível de especificação da RPSL, gerassem as configurações necessárias aos diversos roteadores disponíveis.
  • Teriam uma documentação de toda a política de roteamento, da topologia de suas redes e, fácil de ser lida, entendida e mantida, com visão de conjunto.
  • Teriam disponível uma linguagem baseada em objetos, que representam informações de política de roteamente e informações administrativas, extremamente importantes para todos os administradores de redes. Tais objetos são registrados no IRR por pessoas autorizadas.
  • Estariam confiantes (como consequência da cooperação), de que é uma ferramenta capaz de contribuir para que as configurações dos roteadores onde, a pouca intervenção humana protegeria adequadamente seus ambientes, de informações pouco precisas por motivações acidentais ou maliciosas. Vide [3].

As referências [1] e [2], são respeitadas pelos servidores do IRR, que fazem uma análise sintática e semântica sobre os atribustos e seus respectivos valores (como os compiladores). Mais recentemente, os servidores do IRR se ajustaram aos novos objetos propostos na RPSL e estão mais poderosos ao dar sustentação às ferramentas de manipulação das informações da base de dados do RADB (também, as homoladas – intermediárias – e, as privadas). Ganharam os administradores de ASes.

Recomenda-se a leitura do item 2 de [1]: “RPSL Names, Reserved Words, and Representation”.

O objeto aut-num

O objeto aut-num descreve as informações sobre um AS e suas políticas de roteamento, tanto sob o ponto de vista dos anúncios, como da aceitação de redes. Ele se aplica tanto ao IPv4 como ao IPv6.

Um dos mais importantes objetos de uma base IRR usa, intensivamente, a capacidade de relacionamento dos objetos, entre si. Alguns já vistos e outros a serem descritos nesse treinamento nos próximos segmentos. Assim, o objeto aut-num é combinado com o objeto que caracteriza o roteador (inet-rtr) e que fornece o número do sistema autônomo, indica as interfaces do roteador e que por sua vez é combinado com o objeto que mapeia os ASes envolvidos (as-set) e, finalmente se estendem aos objetos route(6) e route-set, dando segurança à informação dos prefixos que são anunciados. Os objetos as-set, route-set e inet-rtr serão discutidos nos próximos segmentos, mas podem ser encontrados em [1] e [2]

Os atributos do objeto aut-num

aut-num:        [obrigatório]  [único]      [primary/look-up key]
as-name:        [obrigatório]  [único]      [ ]
descr:          [obrigatório]  [único]      [ ]
member-of:      [opcional]     [multiplo]   [inverse key]
import:         [opcional]     [multiplo]   [ ]
export:         [opcional]     [multiplo]   [ ]
default:        [opcional]     [multiplo]   [ ]
remarks:        [opcional]     [multiplo]   [ ]
admin-c:        [obrigatório]  [multiplo]   [inverse key]
tech-c:         [obrigatório]  [multiplo]   [inverse key]
cross-mnt:      [opcional]     [multiplo]   [inverse key]
cross-nfy:      [opcional]     [multiplo]   [inverse key]
notify:         [opcional]     [multiplo]   [inverse key]
mnt-by:         [obrigatório]  [multiplo]   [inverse key]
changed:        [obrigatório]  [multiplo]   [ ]
source:         [obrigatório]  [único]      [ ]

Usando o objeto aut-num

No que segue, algumas adaptações foram feitas de [4].

Um cenário simples, para começar

A figura 1 exibe esse cenário simples e, razoavelmente comum:

Figura 1: Uma representação simples de uma conexão usando o BGP

Na figura 1, acima, a política de roteamento tendo em vista o conceito básico de anúncio e aceitação, para que dados da \textbf{Rede 1 } possam trafegar na direção da \textbf{Rede 2 } e vice-versa, está resumida nos seguintes pontos:

  1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{y }.
  2. \textbf{AS} _ \textbf{y } deve aceitar o anúncio de \textbf{AS} _ \textbf{x } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 2 } para a \textbf{Rede 1 }.
  3. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{x }.
  4. \textbf{AS} _ \textbf{x } deve aceitar o anúncio de \textbf{AS} _ \textbf{y } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 1 } para a \textbf{Rede 2 }.

O objeto aut-num é quem nos permitirá explicitar a política acima no IRR, através dos atributos import e export. Os respectivos objetos aut-num relativos aos sistemas autônomos \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, enviados para \textbf{email\_automatico@} \textbf{redepegasus.net.br} seriam:

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 ASx security please
remarks:    e-mail to: asx.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
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{y }
as-name:    \textbf{AS} _ \textbf{y }-NET
descr:      \textbf{AS} _ \textbf{y } Autonomous System
remarks:    ===============================================
remarks:    http://www.exemplo.com.br
remarks:    ===============================================
remarks:    Security Note
remarks:    Any Notification about ASx security please
remarks:    e-mail to: asy.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:     to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
admin-c:    IDASy-NICBR
tech-c:     IDASy-NICBR
notify:     asy-admin@exemplo.com.br
mnt-by:     MAINT-\textbf{AS} _ \textbf{y }
changed:    asy-admin@exemplo.com.br
remarks:    **************************
remarks:    Test only.
remarks:    **************************
source:     PEGASUS
password:   senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{y }

Simplificando a apresentação

Para efeito didático, iremos suprimir os atributos já conhecidos e, assim, representaremos nosso objeto, da seguinte forma, com o nome de “Configuração”:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
...
aut-num: \textbf{AS} _ \textbf{y }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
...

Configuração 1. Cenário simples

Um cenário não tão simples

Vamos ampliar para o cenário representado na figura 2, abaixo, onde agora podemos identificar a Internet:

Figura 2. Um cenário não tão simples

Em tese são quatro, os administradores de ASes envolvidos nesse cenário. Pouco se conhecem e devem pensar de maneira independente. O caráter colaborativo do IRR, entretanto induz a pensarmos que cada um deles estará atento às especificações dos outros em relação à política de roteamento. Tal atenção ocorre de três maneiras: (a) pela pesquisa à base IRR em relação aos ASes que fazem “peering” (seja qual for o tipo de tráfego), (b) durante o uso das ferramentas de apoio (p.ex., RTConfig), momento em que possíveis inconsistências podem ser encontradas e, (c) através de ferramentas de monitoramento próprias ou de terceiros (p.ex., MyASN). Vale um comentário de que tais ferramentas estão cada vez mais interessantes e eficazes, com mudanças nos protocolos e nos equipamentos (em especial roteadores). Um dos indutores dessas transformações é a área de conhecimento que está sendo chamada de “route analytics”. Eis as observações que caracterizam a política de roteamento do cenário exibido na figura 2, sob o ponto de vista de cada um dos sistemas autônomos envolvidos:

  • Sob o ponto de vista do \textbf{AS} _ \textbf{w }:
    1. \textbf{AS} _ \textbf{w } fornece trânsito para \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }.
    2. \textbf{AS} _ \textbf{w } fornece rotas locais para \textbf{AS} _ \textbf{z }.
    3. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{x }.
    4. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para para o resto do mundo.
    5. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para \textbf{AS} _ \textbf{y }.
    6. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{y }.
    7. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para para o resto do mundo.
    8. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para \textbf{AS} _ \textbf{x }.
    9. \textbf{AS} _ \textbf{w } deve anunciar a rede do \textbf{AS} _ \textbf{y } para para o \textbf{AS} _ \textbf{z }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{x }
    1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{x } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{y }
    1. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{y } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{z }
    1. \textbf{AS} _ \textbf{z } deve aceitar todos os anúncios vindos de \textbf{AS} _ \textbf{w }.

O objeto aut-num sob a ótica do \textbf{AS} _ \textbf{w }

Vamos nos abstrair de alguns pontos da política de roteamento, nesse exemplo. Primeiro, não iremos definir a política para os itens 4 e 6. Isso porque nos falta algumas considerações sobre outros objetos e recursos dos respectivos atibutos. Portanto, deixaremos para abordar no próximo segmento. Segundo, não estamos interessados em em detalhes do \textbf{AS} _ \textbf{z } exceto o fato de que ele recebe anúncios do \textbf{AS} _ \textbf{w }.

Dito isso, eis o objeto aut-num para o \textbf{AS} _ \textbf{w }:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{x }
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{y }
import:  from \textbf{AS} _ \textbf{z } accept \textbf{AS} _ \textbf{z }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{z } announce \textbf{AS} _ \textbf{w }
...

Configuração 2. Sob a ótica do \textbf{AS} _ \textbf{w }

Uma pergunta que pode surgir, ao olhar a configuração 2 é: os anúncios de \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } já não fazem parte dos anúncios de \textbf{AS} _ \textbf{w }? Boa pergunta! Fica como exercício. Assim, também, os objetos aut-num para os demais ASes envolvidos.

Adicionando mais complexidade ao cenário

A figura 3, abaixo representa um cenário onde \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, através de um acordo bilateral estabeleceram um enlace privativo (em vermelho):

Figura 3: Um enlace privativo no cenário.

Iremos abordar esse novo cenário, na Parte X. A figura foi colocada antes, para se pensar sobre quais preocupações devem ser inseridas na política de roteamente. Por exemplo, se o enlace para o provedor de trânsito falhar, os \textbf{ASes} do acordo bilateral irão permitir o acesso ao trânsito pela conexão privativa?

Itens relacionados:

Referências do segmento

[1] \textbf{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 \textbf{RFC2280}) (Updated-By \textbf{RFC4012}) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[2] \textbf{RFC4012 }, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates \textbf{RFC2725 }, \textbf{RFC2622 }) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP).

[3] \textbf{RFC2725 }, Routing Policy System Security C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By \textbf{RFC4012 }) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[4] Wijayatunga, C. (Part I) e Upadhaya, G. R. (Part II), APNIC Internet Routing Registry Tutorial. Disponível em http://www.sanog.org/resources/sanog4-IRR-Tutorial-champs.pdf. Acessado em: 29/04/2010.

[5] Cisco, BGP Best Path Selection Algorithm. Disponível em: http://www.ciscopartner.biz/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml. Acessado em: 29/04/2010.

Categorias:IRR, Peering, Protocolos, TCP/IP, Whois

Curso IRR – Parte VIII: objetos inet(6)num

Introdução

Ao longo desse segmento faremos referência a inet(6)num para falar tanto do objeto inetnum, como do objeto inet6num. Quando for necessário esclarecer questões particulares, faremos referência a cada objeto, individualmente.

Os objetos inetnum ou inet6num representam as alocações e atribuições de endereços IPv4 ou IPv6 definidos pelos RIRs/NIRs ao AS em questão. O objeto inetnum, originalmente existia antes do objeto route. Já o objeto inet6num apareceu depois, juntamente com o route6.A diferença é que o objeto route(6) explicita o prefixo enquanto que o int(6)num explicita o espaço de endereçamento.

Atributos do objeto inetnum

inetnum:       [obrigatório]  [único]      [chave primária e de pesquisa]
netname:       [obrigatório]  [único]      [pesquisa]
descr:         [obrigatório]  [único]      [ ]
country:       [obrigatório]  [múltiplo]   [ ]
admin-c:       [obrigatório]  [múltiplo]   [chave inversa]
tech-c:        [obrigatório]  [múltiplo]   [chave inversa]
rev-srv:       [opcional]     [múltiplo]   [chave inversa]
status:        [obrigatório]  [único]      [ ]
remarks:       [opcional]     [múltiplo]   [ ]
notify:        [opcional]     [múltiplo]   [chave inversa]
mnt-by:        [obrigatório]  [múltiplo]   [chave inversa]
changed:       [obrigatório]  [múltiplo]   [ ]
source:        [obrigatório]  [único]      [ ]

Atributos do objeto inet6num

inet6num:  [obrigatório] [único]    [chave primária e de pesquisa]
netname:   [obrigatório] [único]    [pesquisa]
descr:     [obrigatório] [múltiplo]
country:   [obrigatório] [múltiplo]
admin-c:   [obrigatório] [múltiplo] [chave inversa]
tech-c:    [obrigatório] [múltiplo] [chave inversa]
rev-srv:   [opcional]    [múltiplo] [chave inversa]
status:    [opcional]    [único]
remarks:   [opcional]    [múltiplo]
notify:    [opcional]    [múltiplo] [chave inversa]
mnt-by:    [opcional]    [múltiplo] [chave inversa]
changed:   [obrigatório] [múltiplo]
source:    [obrigatório] [único]

Descrição dos atributos mais importantes

inet(6)num

O atributo inetnum do objeto inetnum contem a faixa de endereços IPv4 para o qual o objeto está dando informações. Há várias formas de representar a faixa de endereços, item 2 de [1], vejamos:

  • Uma classe IP:
    inetnum: 192.168.10.0
    

    onde a rede pode ser uma classe A, B ou C.

  • Duas classes IP:
    inetnum: 192.168.10.0 - 192.168.11.0
    

    onde a rede pode ser uma classe A, B ou C. Nesse caso o hífen (“-“) deve estar presente, juntamente com o IP final que representa a classe. No exemplo, a representação de uma classe C.

  • Representação “classeless” => opção preferida!:
    inetnum: 192.168.10.0 > 192.168.11.255
    

    No exemplo, a representação de duas classes C, pelas especificações dos endereços IPv4, inicial e final. Poderia ser qualquer representação de endereços inicial e final.

O atributo inet6num do objeto inet6num, por outro lado, tem o formato de seu valor simplificado. É a representação IPv6, em CIDR. Por exemplo:

inet6num: 2001:DB8::/32

Uma boa referência está em [3], onde alguns padrões de objetos excedem os padrões representados nos segmentos. Estes devem ser considerados!

netname

É um nome simbólico para o espaço de endereçamento especificado no atributo inet(6)num. Não há restrições, cf. [3], quanto ao nome escolhido. Entretanto, recomenda-se algo parecido com a proposta do RIPE, que seja o nome do objeto conforme descrito no item 2 da RFC2622, atualizada por [3]. A sugestão é: nome_curto_da_empresa-NET. É importante lembrar, que o atributo netname é um atributo de pesquisa. Se não houver uma padronização, dificilmente o usaremos em pesquisa. A recomendação é de que as instituições responsáveis recomendem uma padronização, pelo menos no âmbito de um país ou região.

mnt-by

Esse atributo é múltiplo, o que significa que pode haver diversos mantenedores para o objeto. Então, o atributo mnt-by é quem será usado para identificar o(s) mantenedor(es) autorizado(s) a fazer solicitações de alterações. O mecanismo de autenticação irá verificar no respectivo objeto mntner se o mantenedor está com autoridade para a inclusão, alteração ou exclusão.

O ponto principal a ser lembrado das observações acima é de que há um inter-relacionamento entre os objetos da base IRR, através de seus atributos. Em particular, o atributo mnt-by é quem identifica se a intervenção está devidamente autorizada.

Itens relacionados:

Referências do segmento

[1] Lord, A., Terpstrahttp, M., RIPE Database Template for Networks and Persons, \textbf{RIPE-119}.

[2] \textbf{RFC2772}, 6Bone Backbone Routing Guidelines R. Rockell, R. Fink [ February 2000 ] (TXT = 28565) (Obsoletes \textbf{RFC2546}) (Updated-By \textbf{RFC3152}) (Status: INFORMATIONAL) (Stream: IETF, Area: ops, WG: ngtrans).

[3] \textbf{RFC4012}, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates \textbf{RFC2725}, \textbf{RFC2622}) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP).

Categorias:IRR, TCP/IP

Curso IRR: Aula complementar I – Espelhamento e segurança nos IRRs

Atualização em 30/05/2010.
Atualização em 25/05/2010.
Atualização em 22/05/2010.

Como é feito o espelhamento

Os grandes provedores de backbone estão usando, sistematicamente, o IRR por razões de segurança, principalmente. Então, cada um estabeleceu um servidor IRR e muitos deles são espelhadas pelo RADB e, também, espelham o RADB. Mas, não necessariamente espelham TODOS os IRRs(1).

Cada IRR gera uma base (texto) populada por seus respectivos objetos. Geralmente leva o nome da base, como por exemplo, radb.db, level3.db, pegasus.db, etc. O whois e/ou ferramentas quando dirigidos a uma base específica, podem não encontrar um objeto pelo fato da base na qual ele foi inserido não existir naquele servidor. Se ela não existe é porque o servidor não espelha aquele IRR e nem armazena a base do IRR (via ftp, p. ex.).

As razões pelas quais nem todos os servidores IRR espelham ou mantem muitas das bases IRRs, a exemplo do RADB, não interessa no debate. Não merece o debate porque, nesse caso há ausência do princípio da cooperação (estima-se umas 60 bases descentralizadas de IRR). Cooperação contribui, significativamente, para Internet mais saudável. Para ilustrar a questão do espelhamento, o exemplo abaixo é interessante, além de exibir uma incoerência técnica:

     whois -m 187.49.0.0/20
     route:      187.49.0.0/20
     descr:      Proxy Registration for PCCW Global customer Brazil Telecom
     origin:     AS28138
     remarks:  This route object is for a PCCW Global customer route which is being exported under this origin AS.  
     This route object was created because no existing route object with the same origin was found, and since 
     some PPCW global peers filter based on these objects this route may be rejected if this object is not 
     created. Please contact peering@pccwglobal.com if you have any questions regarding this object.
     mnt-by:     MAINT-AS3491
     changed:    sajwani@pccwbtn.com 20090326  #23:18:47Z
     source:     RADB

     route:      187.49.0.0/20
     descr:      SCW Telecom - IPv4 CIDR block
     origin:     AS28138
     mnt-by:     MAINT-AS28138
     remarks:    Sat Apr 10 12:58:25 BRT 2010
     changed:    herbert@scw.net.br 20100410
     source:     PEGASUS

O whois da PCCW, na relação de IRRs é rr.ntt.net. O resultado da mesma consulta naquele servidor é:

     whois -h whois.pccwbtn.com 187.49.0.0/20    
     route:      187.49.0.0/20
     descr:      Proxy Registration for PCCW Global customer Brazil Telecom
     origin:     AS28138
     remarks:  This route object is for a PCCW Global customer route which is being exported under this origin AS.  
     This route object was created because no existing route object with the same origin was found, and since 
     some PPCW global peers filter based on these objects this route may be rejected if this object is not 
     created. Please contact peering@pccwglobal.com if you have any questions regarding this object.
     mnt-by:     MAINT-AS3491
     changed:    sajwani@pccwbtn.com 20090326  #23:18:47Z
     source:     RADB

Uma tentativa de consultar o AS28138, tem o resultado abaixo:

    whois -h rr.ntt.net AS28138
    %  No entries found for the selected source(s).

De onde pode-se concluir:

  1. O IRR da NTTCOM é espelhado pelo RADB.
  2. O IRR da NTTCOM não espelha o RADB.
  3. A NTTCOM registra seus objetos na sua própria base IRR e usa como valor do atributo source, o RADB.
  4. À incoerência técnica junte-se inconsitência da informação contida no atributo descr.

A Level3, por exemplo, não adota tal postura.

Entretanto há outras razões para tal comportamento: segurança e confiabilidade.

Segurança e confiabilidade do IRR

Recentemente, na lista Alumni (ex-alunos do curso de IPv6 do Nic.br – Alumni at ceptro dot br) houve um rápido debate sobre segurança nos IRRs. Tal debate envolvia RPKI (“Resource Public Key Infrastructure”), IRR e, por tabela, roteadores. Não iremos entrar no mérito das técnicas usadas pelo RPKI. Para quem se interessar em detalhes, os engenhos de pesquisas, são ótimos amigos. Um trabalho recente, sobre os padrões RPKI em desenvolvimento está em [7]. Também não iremos abordar nada relacionado a roteadores, mas há um sentimento de que o futuro deles passará por computações pervasiva e ubíqua. O conhecimento inicial para acompanhar as noções de criptografia para entender RPKI está vastamente exposto em [8] e [9].

Uma questão que tem sido lembrada mas, não tanto enfaticamente como deveria é a confiabilidade da base IRR. Por um lado, o fator custo da manutenção e, por outro, a razoável complexidade da linguagem de especificação (RPSL) das políticas de roteamento, que enfraquecem o espírito da atualização sistemática. Confiabilidade passa necessariamente por processos de aquisição de conhecimento e, naturalmente, orientação permanente uma vez que o cenário é muito dinâmico. Há um visível crescimento, em especial no Brasil, de novos ASes, com perspectiva de maior intensidade à medida que o IPv6 for aumentando a presença.

Desde uns dois anos atrás tem sido debatido e exposto(2) e, mais recentemente(3), a questão da segurança nas bases IRR. Randy Bush e outros colaboradores(3), têm insistido em um modelo interessante. Segurança muito mais atenta à confiabilidade do IRR e sua importância na direção de manter a Internet funcionando sem os problemas causados por erros de configuração, de originação (AS de origem) e na prevenção de ataques maliciosos. Tal proposta tem recebido aplausos e indicações de que os fundamentos que deram origem à RPSL, que especifica os objetos formadores da base IRR. Os seguintes pontos e motivações retiram eventuais dúvidas de interpretação da proposta:

  • Garantir a qualidade dos dados dos IRRs.
  • Criação de mecanismos formais de verificação da legitimidade dos objetos criados no IRR.
  • Criação de mecanismos formais para verificar as políticas de roteamento e respectivos anúncios.
  • Verificar a ORIGEM das políticas.
  • Verificar a corretude das políticas de roteamento criadas nos IRRs.
  • Administradores de ASes não compreendem ou, simplesmente, não querem usar IRRs.
  • A dependência pela disponibilidade da Internet tem crescido vertiginosamente.
  • Segurança dos sistemas de roteamento tem piorado, ao invés de melhorar(6).
  • A implementação completa do RPKI está disponível em “open source”(5).
  • Foco na validação dos anúncios de prefixos e não na proteção do transporte das conexões.
  • Toda e qualquer implementação do projeto deve ser “openSource”.

Finalmente, a figura abaixo, retirada de [6], indica que não se está pensando em substituir o IRR.

Figura 1: IP Address Allocation, Assignment, and IRR Conceptual Model(6).

Comentários finais

Os pequenos e médios provedores devem ficar atentos ao fato de que as propostas estão na mesa, com testes sendo feitos e disponíveis. A iniciativa é dos grandes provedores, principalmente os de backbone. Portanto, é preciso ficar atento e participar do debate, sob pena de haver consequências indesejáveis nas decisões que forem tomadas, à revelia e envolvendo interesses que podem afetar a futura infraestrutura da Internet. Mudanças que podem desagradar somente aos troianos. Os gregos querem, naturalmente, resolver o seu problema. E, rapidamente!

Eis algumas lembranças que devemos ter no processo do debate:

  • Evitar a descentralização de IRRs. Não se deve impor restrições na criação de uma base, mas não deveriam ser reconhecidas (digamos, homologadas), as bases criadas com características exclusivas.
  • Como as políticas de roteamento representam um componente importante para o funcionamento da Internet, não deveriam incorrer a custos. Em particular custos de certificação. Há um ponto de vista sensível sobre o debate: “uso do IRR custa dinheiro”. No LACNIC, aparente fato consumado está em [10]: “The objective is for all RIRs to be ready to start issuing
    certificates by no later than 01 January 2011.” . O que é bom, principalmente se os ASes puderem usar sem custo. Mas, os ASes, que possuem voz e voto no LACNIC devem se movimentar, principalmente, porque já existem custos sobre o ASN.
  • Evitar a centralização e controle excessivo sobre políticas de roteamento. O administrador de um AS está, em tese, preparado para gerenciar sua rede. Caso contrário devem ser estimulados a se preparar.
  • Evitar a classificação de um AS pelo sua dimensão. Para a Internet, quanto mais for descentralizada a competência e administração da rede, melhor. O modelo da governança atual da Internet deve ser mantido, a qualquer preço. Portanto, não se deve permitir que uma questão importante (como é o caso de políticas de roteamento), influencie negativamente, com reflexos em eventuais mudanças de gestão.
  • O Brasil, com um único IRR (aparentemente) é dono de uma rara oportunidade de desenvolver experiências de cooperação enfática, no momento em que a operação do Pegasus IRR ficará sob responsabilidade da Abranet.

Epílogo do segmento

Uma pergunta em palestra no GTER29(11), não foi bem respondida. A pergunta se referia a questões de segurança do IRR atual. Eis as respostas e comentários adicionais, fazendo uma referência à relação IRR x RPKI:

  1. A inclusão dos objetos mnter e person é, obrigatoriamente, feita pelo administrador da base IRR. Somente um descuido muito grande ou má fé poderiam permitir que tais objetos fossem manipulados por não administradores de ASes.
  2. A base principal do IRR, o RADB é sistematicamente atenta a abusos. Portanto, qualquer um pode enviar um e-mail para eles que serão imediatamente respondidos! É pura responsabilidade, por estar cuidando de uma comunidade sensível.
  3. O administrador de um AS pode manipular seus objetos sem nenhuma autenticação. Por pura opção pessoal. Nâo se tem notícias de que alguém faça isso. Até porque, dificilmente um administrador de IRR incluiria o objeto mntner, sem autenticação e, sem o objeto person.
  4. Há duas formas de autenticação: via senha criptografada e via PGP. Ambos são seguros dentro dos limites conhecidos. Na remota hipótese de sequestro de senhas ou chaves, a reação pode ser imediata. O telefone do INOC está ai com esse objetivo, por exemplo.
  5. O RPKI é semelhante ao DNSSEC. No final, seu objetivo é estabelecer a cadeia de confiança. A cadeia de confiança é mais problemática nos processos automáticos que transmitem informações em redes inseguras (aka Internet), no caso do IRR, unidirecional.
  6. Deveriam haver estudos na direção de identificar como será o comportamento dos administores de ASes e as propostas dos fabricantes que estão trabalhando em diversas direções. A tendência vem mostrando que técnicas associadas a SOA podem se tornar vitoriosas. Nesse caso, pensa-se em outras técnicas e tecnologias que não o RPKI.
  7. O RPKI sobre o IRR é um paradigma, no conceito de Kuhn(12). A origem da proposta de RPKI no IRR, provavelmente veio de uma recomendação no item 8 (último parágrafo), da RFC2725(13), como alternativa no fortalecimento da autenticação mas, não única alternativa. Duas constatações que induzem à ampliação do debate com a participação insistente, dos administradores de ASes.

Itens relacionados:

Referências do segmento

1. List of Routing Registries. IRR. Disponível em: http://www.irr.net/docs/list.html. Acessado em: 18/05/2010.

2. Bush, R. e McPherson, D., Using the RPKI to Construct Validated IRR Data, em mensagem de McPherson, D., Policy Proposal: Minimum Allocation in the Caribbean Region , Disponível em: http://lists.arin.net/pipermail/arin-ppml/2008-May/010788.html. Acessado em 18/05/2010.

3. Bush, R., Austein, R. Austein, Bellovin, S., The RPKI \& Origin Validation, RIPE-60, Praga 03/05/2010. Disponível em: http://www.ripe.net/ripe/meetings/ripe-60/presentations/Bush-The\_RPKI\_Origin\_Validation.pdf. Acessado em: 18/05/2010.

4. Bush, R., Austein, R., “The RPKI/Router Protocol”, Randy Bush, Rob Austein, 20-Feb-10. Disponível em http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-05. Acessado em: 18/05/2010.

5. Implementação em OpenSSL, do RPKI.

6. Steenbergen, R.,Volk, R., Kumari, W., Blunk, L. e McPherson, D., ISP Route Filtering: Responsibilities & Technical Challenges. Disponível em: http://www.nanog.org/meetings/nanog43/presentations/DanMcP_Route_Filter_Panel_N43.pdf. Acessado em 18/05/2010.

7. Patara, R., RPKI: Actualización sobre estándares en desarrollo, LACSEC, LACNIC XIII, 19/05/2010. Disponível em: http://lacnic.net/documentos/lacnicxiii/presentaciones/LACSEC/03-rpki-5seguridad.pdf. Acessado em: 19/05/2010.

8. Carlos, M. C., Sutil, J. M., Moecke, C. T., Kohler, J. G., Introdução a Infraestrutura de Chaves Públicas e Aplicações (ICPEDU), ESP/RNP, 2010. Disponível em: http://esr.rnp.br/leitura/icpedu?categoria=3&download=44f683a84163b3523afe57c2e008bc8c. Acessado em: 20/05/2010.

9. Moreira, E. Q., Foscarini, E. D., Silva Junior, G. C. da, Alixandrina, L. A. O., Vieira Neto, L. P. V., Federação CAFe: Implantação do Provedor de Identidade, ESP/RNP, 2010. Disponível em: http://esr.rnp.br/leitura/cafe?categoria=3&download=03afdbd66e7929b125f8597834fa83a4. Acessado em: 20/05/2010.

10. Rada, G., Sistema de Certificación de Recursos vBetaRPKI-LACNIC, LACNIC XIII, 19/05/2010, Disponível em: http://lacnic.net/documentos/lacnicxiii/presentaciones/tutoriales/rpkivbeta.pdf. Acessado em: 20/05/2010.

11. Braga, J., Políticas de roteamentos: como resolver a impossibilidade de implementação na tecnologia “hop-by-hop” e o futuro. Disponível em: ftp://ftp.registro.br/pub/gter/gter29/01-PoliticasRoteamento.pdf. Acessado em: 25/05/2010.

12. Kuhn, Thomas S., A Estrutura das Revoluções Científicas, Editora Perspectiva, São Paulo, 1996.

12. RFC2725, Routing Policy System Security C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By RFC4012) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

Categorias:IRR, RPKI, TCP/IP

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
%d blogueiros gostam disto: