Home > IRR, TCP/IP > Curso IRR – Parte VI: Políticas de roteamento

Curso IRR – Parte VI: Políticas de roteamento

14/04/2010 Leave a comment Go to comments

Atualizado em 17/05/2010, com base em [6].

Introdução

Política de roteamento é a troca de informações de roteamento entre ASes.

Nas Referências, iremos observar que o RIPE é o principal RIR atento a políticas de roteamento. O grupo europeu é insistente e, provavelmente, quem cuida melhor de sua infraestrutura de Internet. Ele é, realmente, o melhor nesse aspecto. Há várias razões para isso mas, certamente a participação da comunidade (os ASes europeus!) é a principal. Assim, pode-se notar que há recursos adicionais no RIPE, para facilitar nossa vida como administrador de AS, que não estão disponíveis em outros RIRs ou NIRs. Face a isso, recomendo evitar ansiedades quando um recurso ou facilidade não estiver disponível no Brasil. Muitas facilidades do RIPE podem ser usados por nós, como por exemplo, o MyASN. Por outro lado, mais cedo ou mais tarde, as facilidades do RIPE chegarão por aqui.

NOTA:Sempre que buscar por uma RFC (principalmente, vindo de referências), primeiro vá ao índice do RFC-Editor. Nesse índice, garante-se a última versão da RFC e, também, se há atualizações. É um bom hábito!

Considerações importantes

Um AS é um grupo de redes IP com políticas de roteamento bem definidas por um ou mais operadores de rede. Dentro de um AS, os pacotes IPs são roteados através de protocolos IGPs (iBGP, OSPF, IS-IS, RIP, etc). Os ASes trocam informações de rotas com outros ASes, através dos protocolos EGPs (\text{BGP4}, por exemplo). As decisões de rotas entre ASes, são baseadas em políticas de rotas (definidas por regras, nos EGPs). Pequenos ASes necessitam de políticas simples. A complexidade das políticas é diretamente proporcional ao tamanho do AS. Mas ambos (o pequeno e o grande) possuem a mesma responsabilidade de garantir o funcionamento adequado de toda a Internet. Um pequeno AS pode gerar uma confusão imensa em um setor regional da Internet ou em toda ela. O BGP, possui recursos para implementar políticas de roteamento através de filtros (ou regras). MAS, não possuem facilidades para anunciar ou aceitar as políticas, propriamente ditas. O trabalho é manual, estabelecendo as regras (e filtros). Não é um trabalho trivial. É muito trabalhoso e carrega as dificuldades naturais inerentes à fragilidade do ser humano. Essa é a questão mais importante, pois um erro trivial numa regra, um pequeno esquecimento, gera um resultado grave na Internet como um todo. Assim, um AS com uma pequena rede ou um AS com uma rede complexa, não se diferenciam, nesse aspecto.

Aqui entra o IRR e ferramentas associadas, para garantir facilidades e funcionalidades efetivas na criação de regras para os protocolos, que eliminem as preocupações inseridas no contexto das dificuldades acima. Imagino que nesse ponto, já começa a ficar mais claro o objetivo do IRR.

A limitações das políticas de roteamento da tecnologia atual (“hop-by-hop”)

Suponha a topologia representada na figura abaixo:

Figura 1. Rede ideal entre dois ASes.

As seguintes observações se aplicam à figura acima:

  1. As nuvens com \textbf{ ? } representam topologias desconhecidas. Não sabemos nada sobre sua estrutura (redes, subredes, ASes, etc.). Sabemos que são topologias que fazem parte da Internet.
  2. \textbf{AS} _ \textbf{x } sabe como chegar na Rede 1.
  3. \textbf{AS} _ \textbf{y } sabe como chegar na Rede 2.
  4. Para haver tráfego da Rede 2 na direção da Rede 1 é necessário que tal tráfego flua entre \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }. Portanto, \textbf{AS} _ \textbf{x } TEM de anunciar a Rede 1 para \textbf{AS} _ \textbf{y }.
  5. Há uma disposição de \textbf{AS} _ \textbf{x } em aceitar o tráfego dirigido à Rede 1. Na figura, esse tráfego vem de \textbf{AS} _ \textbf{y }

Com base nas posições acima é possível definir a primeira política de roteamento do nosso modelo exibido na Figura 1: \textbf{AS} _ \textbf{x } anuncia a Rede 1 para \textbf{AS} _ \textbf{y }.

Por outro lado, \textbf{AS} _ \textbf{y } deve aceitar essa informação de roteamento e usá-la. Também, \textbf{AS} _ \textbf{y } tem o privilégio de reconhecer ou de ignorar, a prédisposição de \textbf{AS} _ \textbf{x } em aceitar tráfego para a Rede 1. Com isso, \textbf{AS} _ \textbf{y } pode, eventualmente, decidir enviar tráfego para a Rede 1, através de uma outra rota mais apropriada. Do que foi dito nesse parágrafo pode-se inferir a segunda política de roteamento: \textbf{AS} _ \textbf{y } aceita o anúncio feito pelo \textbf{AS} _ \textbf{x }.

O inverso também é semelhante, produzindo as, terceira e quarta políticas de roteamente, respectivamente: \textbf{AS} _ \textbf{y } anuncia a Rede 2 para \textbf{AS} _ \textbf{x } e, \textbf{AS} _ \textbf{x } aceita o anúncio feito pelo \textbf{AS} _ \textbf{y }

É incomum que as políticas de anúncio e aceitação do \textbf{AS} _ \textbf{x } e do \textbf{AS} _ \textbf{y } não sejam idênticas e, portanto, configuradas separadamente para cada rede. Na prática, são feitas por grupos de redes (através dos respectivos administradores), que formam um ou mais ASes (retirando as abstrações das nuvens \textbf{ ? } tornaria compreensível a afirmação). E, também, não é comum, que existam somente políticas unilaterais. Portanto, é necessário a integração dos ASes, em sua grande maioria, como sabemos, desconhecidos entre si.

Mas, o parágrafo anterior é verdade, para ASes que estejam diretamente conectados entre si e, também, diretamente conectados com suas respectivas redes. A figura 2, abaixo, ilustra tais conexões adjacentes.

Figura 2. Interconexões adjacentes

Nesse momento é importante lembrar como pacotes são encaminhados pelos roteadores da Internet. Eles passam, no caminho entre a origem e o destino, no esquema “hop-by-hop” (ponto-por-ponto ou, roteador-por-roteador). Os roteadores que fazem o trânsito (e que estão no caminho origem -> destino), avaliam cada cabeçalho do pacote e presquisam uma tabela chamada FIB (Forward Information Base). Esta tabela é construida por cada nó (hop ou roteador) do caminho, cada um de maneira própria e, eventualmente, diferente do outro (adjacente ou não). Ao consultar a FIB, o nó toma a decisão e define o próximo salto a ser dado em direção ao destino. A figura 3 abaixo ilustra como é construida a FIB em cada roteador da Internet.

Figura 4. Como a base de dados FIB é construída em cada roteador.

As rotas estáticas alimentam a base OSPF (quando houver) e a RIB (Route Information Base). A tabela de rotas do BGP, também alimenta a RIB. A RIB, portanto, tem um conjunto de informações sobre rotas, originadas de várias fontes. Em particular, tem uma relação de todos os próximos nós (ou hops, ou roteadores) que podem levar ao destino de acordo com a proposta especificada pelo nó de origem. Mas, somente a informação do melhor próximo nó (“next-hop”) será colocado na FIB. Baseada na FIB, o roteador toma a decisão, que pode ser diferente do caminho traçado inicialmente pelo roteador de origem do pacote.

Por tal razão, a tecnologia atual, não consegue tratar políticas em termos de ANÚNCIOS de redes e de ACEITAÇÃO de redes em toda sua extensão, já que cada roteador (o próximo nó – “next-hop”) é quem dá a palavra final e não há nenhuma comunicação dessa decisão para o resto da rede. Olhando a figura, não se pode intervir, nas decisões tomadas pelos roteadores que estão entre \textbf{AS} _ \textbf{a } e \textbf{AS} _ \textbf{z }, mostrados na figura 5, abaixo, agora mais completa.

Figura 5. Ilustração completa do problema dos enlaces azuis e vermelhos

Reflexões adicionais

Tem-se, até esse momento, a seguinte questão em pauta: políticas baseadas em ANÚNCIO e ACEITAÇÃO, não são implementáveis na tecnologia de roteamento disponíveis atualmente.

Com essa abordagem queremos fixar o fato de que, as políticas de roteamento (incluindo políticas de acesso) podem ser implementadas nos IRR e as ferramentas associadas irão auxiliar a transformar tais políticas nas regras de implementação disponíveis na tecnologia atual do ”hop-by-hop” que é um impedimento tecnológico.

A interconexão ideal, também, exibe um fato importante para efeito do entendimento de política de roteamento: um lado anuncia e o outro lado aceita. Anúncio e aceitação estão em lados contrários. Essa é a caracterização ideal de uma conexão efetiva.Mas, na atual tecnologia de roteamente, não é possível estabelecer políticas de roteamente na base de anúncio e aceitação. A tecnologia atual é o hop-by-hop. Um pacote segue um caminho da origem até o destino, passando em roteadores, no caminho, que tomam suas próprias decisões sem, absolutamente, nenhuma cooperação entre si.

Duas questões como exercício: A política de roteamento, sobre conexões azul e vermelho, para tráfego vindo dos ASes vermelhos e azuis, poderia ou não ser implementada? O que acontece com o tráfego, quando ele passa no \textbf{AS} _ \textbf{a }?

Itens relacionados:

Referências

[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] 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)
[4] 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)
[5] JPNIC: IRR (JPIRR) Operation Policies and User Guideline
[6] Braga, J., Politicas de roteamento: Como resolver a impossibilidade de implementação na tecnologia “hop-by-hop” e o futuro. GTER 29. Disponível em: ftp://ftp.registro.br/pub/gter/gter29/01-PoliticasRoteamento.pdf”. Acessado em 17/05/2010.

Categories: IRR, TCP/IP