Início > IRR, Sem categoria > Curso IRR – Parte VII: Planos de roteamento

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

Deixe uma resposta

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: