Archive

Archive for November, 2011

BGP: topologias, abstrações, eBGP e iBGP (Parte 1)

05/11/2011 2 comments

Introdução

Este artigo tem o propósito de evoluir o entendimento do BGP, que se está procurando dar, ao longo dos artigos anteriores. Neles a abordagem foi dada sobre o Mikrotik, um roteador (entre outras funções) simples e versátil de lidar. De agora em diante será rompida a forte vinculação única e, abandonaremos, também, o FFE, para ampliarmos a complexidade do BGP em abordagens mais práticas, do dia-a-dia.

Finalmente iremos apreciar o iBGP, componente inseparável do BGP. O outro componente inseparável é o eBGP. A completude do BGP exige ênfase na topologia, como iremos verificar. Desenhar a topologia adequada para o planejamento do BGP é uma questão fundamental, pois deve-se perseguir a simplicidade das representações para contornar a sua complexidade, como um todo.

A topologia, que na prática apresenta-se em formas semelhantes, mas dificilmente idênticas tem sido relegada a um plano secundário, já que a tendência é evitar projetos ou planejamentos em redes, que demandam imenso esforços, mas extremamente importantes para bons resultados na implementação de um BGP. Geralmente, a partir do instante em que o BGP se comporta de forma aceitável é comum deixar de lado as preocupações com sua otimização sob o ponto de vista da eficiência. No Brasil, aparentemente, tem-se uma curiosa tendência em permitir que as grandes operadoras façam o que bem entenderem em relação à topologia, facilitando seus interesses e não os de seus clientes, e até mesmo, os interesses da própria Internet. É um cenário abusivo, monopolista, oligopolista e, pior, um cenário de oportunistas a soldo de interesses pessoais, de grupos muito bem articulados e econômicos predatórios. Tais questões, por demais importantes serão tratadas em outro momento.

Um autor será muito referenciado, inclusive nas entrelinhas: John W. Stewart III, ou simplesmente, John Stewart. Ele escreveu o imperdível, fascinante e único romance sobre o BGP41, disponível para leitura contínua e de cabeceira. Mas, nossa bíblia continuará sendo a RFC42712. Em um sentido mais amplo, completo e detalhado, nada como o livro de Radia Perlman7 que exibe sua intensa experiência. Mais recente, atualizado e imperdível é o livro de Russ White e outros9. Uma referência prática e específica é o artigo de Caesar e Rexford6 que propõem dicas importantes para quem precisa trabalhar, de forma sistemática, com políticas de roteamento, principais preocupações dos administradores de BGP. Finalmente, não se pode esquecer que o BGP é constantemente ampliado e atualizado pelas RFCs.

Uma topologia para o debate

A Figura 1, abaixo, exibe uma topologia para iniciar o debate. São três pontos independentes de conexão estática à Internet, uma interconexão ao PTT-Belém, três pontos de empareamento em túneis IPv6 com um mesmo operador de trânsito e dois empareamentos (IPv4 e IPv6), com o Team-Cymru, para recebimento dos “bogons” (Belém).

 

Figura 1. Visão inicial da topologia.

 

As observações que nos interessam sobre a Figura 5, são:

  1. Tudo está funcionando a contento.
  2. Embora não mostrada na Figura 1 há uma VPN entre Guará e SJCampos.
  3. Há três túneis 6to4, com a Hurricane Eletric, para o mesmo AS6939 (Belém, Guará e SJCampos).
  4. Face a independência das conexões seria necessário o empareamento com o Team Cymru, também, em Guará, onde terá BGP.

Talvez refinando um pouco mais a topologia da Figura 1, com base nas observações de 1 a 4, acima, algo mais virá a tona. Por exemplo, a representação da Internet está fora do lugar, na Figura 1.

 

Figura 2. Refinando a topologia da Figura 1.

 

Figura 2 exige outras observações, mais detalhadas:

  1. As setas em vermelho, representam empareamentos BGP. Neste caso temos eBGP pois as conexões são entre Sistemas Autõnomos com ASNs diferentes. Em outras palavras, eBGP é um protocolo EGP5. O eBGP é um dos dois principais componentes do BGP. O outro é o iBGP, que é um protocolo do tipo IGP5. O iBGP é usado para as interconexões entre roteadores de um mesmo AS e, existem diversos protocolos que exercem funções equivalentes ao iBGP (RIP, OSPF, etc.).
  2. As setas pretas são interconexões de trânsito.
  3. A conexão de trânsito em Belém é estática. Será transformada para um trânsito em BGP quando houver outro trânsito através do PTT, em acordo bilateral com um fornecedor de trânsito, claro, também, no PTT. Na oportunidade de implementação de um trânsito “multihoming”, já espera-se que a tabela de roteamento seja do tipo “full routing”.
  4. O trânsito em Guará é estático, também. Brevemente será dinâmica, via BGP, com um único operador.
  5. Embora não mostrada na Figura 1 há uma VPN entre Guará e SJCampos.
  6. Há três túneis 6to4, com a Hurricane Eletric (AS6939): Belém, Guará e SJCampos.
  7. Face a independência das conexões seria necessário empareamento com o Team Cymru, também, em Guará, onde terá BGP. O empareamento com o Team Cymru é somente em uma direção (unicamente para recebimento das tabelas de bogon (IPv4 e IPv6).
  8. Embora a figura apresente somente uma Internet é bom lembrar que são duas: IPv4 e IPv6.
  9. Seria interessante empareamento BGP em SJCampos, mas há um impedimento comercial, pois a conexão com a Internet é uma aDSL. BGP (isto é, eBGP), entre ASes, tipicamente exige conectividade física. Não que interconexões assíncronas impeçam o eBGP.

Procurando uma topologia sem os detalhes irrelevantes

Na Figura 3, mostramos uma topologia idêntica à da Figura 2, mas totalmente abstrata, sem mostrar as questões irrelevantes, tais como, IPs, ASNs, formas de conectividade, localidades, anúncios, etc.

 

Figura 3. Topologia abstrata da Figura 2.

 

Veremos que pensar/planejar em uma topologia abstrata ficará mais fácil. Podemos melhorar mais ainda se pensarmos que as respectivas conexões de R!, R2 e R3, com os roteadores externos ao domínio local, RA, RB, …, RG são todas via BGP, isto é, eBGP. Portanto, a Figura 4 torna mais simples e adequada a topologia na qual iremos trabalhar. Realmente, em uma implementação de BGP, na qual esperamos anunciar nossos IPs e receber anúncios de vizinhos, tanto faz pensar em uma única implementação ou em várias. Na primeira implementação de um BGP sabemos que tratamentos diferenciados com vizinhos distintos, serão feitos através de filtros. Recursos mais elaborados serão feitos através de políticas de roteamento mais sofisticadas. Filtros fazem parte da política de roteamento, mas não são suficientes para outros tratamentos, eventualmente necessários, que não seriam atendidos pela política do melhor caminho (“shortest-path policy”), inerente ao BGP.

 

Figura 4. Topologia com a abstração máxima.

 

A topologia da Figura 4 é nossa melhor representação, sem dúvida. Mas, existem questões didáticas que remete-nos à Figura 5, para lembar que cada roteador do Domínio Local (DL) possui sua própria rede local (basta ver nossa topologia original, da Figura 2, representadas pelas localidades. Na oportunidade vale lembrar que cada um dos roteadores externos e vizinhos dos roteadores DL, possui seus respectivos domínios, sobre os quais o administrador do DL não consegue interferir diretamente.

 

Figura 5. Topologia sob efeito didático: as redes de cada Ri (i=1, 2 e 3).

 

Tipicamente, o DL possui diversos roteadores internos, em cada rede. Tais roteadores estão interconectados, a partir do roteador Ri. Cada um destes roteadores internos, constroem sua própria rede, muito embora alguns roteadores possam ser transformados em “bridge”. Mas, “bridge” não é um roteador! Então não estamos interessados nelas, nesta etapa de entendimento sobre o BGP. Portanto, a força da didática nos induz a um aperfeiçoamento, mostrado na Figura 5, e na Figura 6, onde estão representados os inúmeros roteadores de cada rede local. Inúmeros é força de expressão, pois por razões práticas representaremos uns poucos, para depois representarmos somente um.

 

Figura 6. Topologia sob efeito didático: os roteadores, Rij (i=1, 2,… 3; j=1, 2, …, n), de cada Ri.

 

Há detalhes irrelevantes na Figura 6. Por exemplo, a representação das redes internas a cada Ri e a especificação dos domínios dos vizinhos. A Figura 7, que segue, abstrai-se de tais detalhes, pois intuitivamente induz-nos a imaginar as redes locais de cada Ri e, também, as redes locais dos Rij.

 

Figura 7. Topologia sem os detalhes irrelevantes da topologia da Figura 6.

 

Neste ponto, fixaremos na Figura 7 e passaremos a entender sobre os protocolos EGPs e IGPs.

Protocolos EGPs e IGPs.

eBGP é um protocolo EGP (“Exterior Gateway Protocol”). iBGP é um protocolo IGP (“Interior Gateway Protocol). O mais famoso protocolo do tipo EGP é o BGP4. Existem outros, como o BGP (versão anterior do BGP4, às vezes chamado de BGP3), o GGP (“Gateway to Gateway Protocol”), o protocolo Hello, o protocolo EGP (conflitando com o nome do tipo EGP). Já os protocolos do tipo IGP são vários: RIP (“Routing Information Protocol”), OSPF (“Open Shortest Path First”), IS-IS (“Intermediate System do Intermediate System”), IGPR e EIGPR. Estes dois últimos são protocolos proprietários da Cisco. O RIP é muito usado em pequenas redes com topologia não complexas. Esta lembrança sobre o RIP se deve ao fato de ser um dos protocolos muito usados no mundo inteiro e para lembrar que topologia exerce uma influência muito grande na escolha do protocolo. Por outro lado, percebe-se que o RIP é pouco usado no Brasil, onde se dá preferência ao OSPF, independente da topologia ser simples ou não. O BGP tem seu próprio IGP, como já sabemos: o iBGP.

Ao escolher um protocolo, a preocupação está na capacidade de que um ponto da rede possa alcançar qualquer outro ponto (interno ou externo), e vice-versa. Esta é a propriedade da atingibilidade, do inglês “reachability”. Neste ponto, vale lembrar que Sistema Autônomo (AS) exerce um efeito significativo, principalmente quando lembramos o que diz Stewart1, na página 18: “… um AS é uma coleção de roteadores e não uma coleção de prefixos IPs”. Stewart1 diz isto para esclarecer que o objetivo de um protocolo EGP é o de permitir que dois diferentes ASes possam trocar informações de roteamento de tal forma que tráfego de dados possa atravessar entre eles, em ambas as direções. Para que tal tráfego seja eficaz, em todos os sentidos, um protocolo EGP deve incluir mecanismos que permitam os administradores de ambos os ASes definir suas regras de comportamento do tráfego, independentemente, já que ambos estão em domínios administrativo e técnicos diferentes, que em tese, mal se conhecem. Tais mecanismos são o que conhecemos como política de roteamento. Filtros do BGP (eBGP!) fazem parte da política de roteamento quando, decidimos quais prefixos podem ser anunciados ou não. Um bom exemplo, que amplia esta noção de política de roteamento para além dos filtros (mas com a ajuda deles) é a opção de empareamento com o Team Cymru para garantir a prática desejável de não transferir “bogons” para os vizinhos do empareamento BGP.

Neste momento, podemos identificar algumas questões que devem ser resolvidas e outras observações que podem influenciar nosso planejamento:

  • A atingibilidade entre os roteadores, R1i, R2j e R3k, só acontecem via Internet (IPv4 e IPv6).
  • A atingibilidade de R14, por exemplo, só é possível com rotas estáticas. Sem um protocolo dinâmico, o trabalho pode ser muito grande. Imagine um ambiente interno com mais de 50 roteadores, como é o caso de Belém.
  • Considerando o DL com 3 pontos de presença separados, a redundância só pode ser conseguida em cada ponto. É possível alterar tal condição? Sob o ponto de vista econômico/financeiro como deve ser tratada tal questão? Aqui entrará um outro componente competindo com a topologia: o componente econômico. Caesar e Rexford6 chamam o componente econômico de relações de negócios, como uma das quatro outras políticas que um administrador de AS deve considerar: escalabilidade, engenharia de tráfego e segurança. Na política relações de negócios eles incluem as relações políticas, além das econômicas. Na política de engenharia de tráfego incluem as necessidades de controle do fluxo de tráfego e preocupações relacionadas com congestionamento e qualidade de serviços, tanto internamente quanto externamente. Na política de escalabilidade, as preocupações estão ligadas à redução do controle do tráfego e eliminação de sobrecarga dos roteadores. Finalmente, a política de segurança, relaciona-se com as proteções contra ataques maliciosos ou acidentais.
  • Podemos pensar em “manutenção móvel” com roteadores móveis? Por exemplo, um roteador em uma VM de um notebook, digamos, openBSD.

O principal dilema, para seguir as preocupações acima é identificar o melhor protocolo do tipo IGP a ser usado na topologia da Figura 7. Em seguida, entender, profundamente, o escolhido. É claro que a escolha recai sobre o iBGP. Mas, porque? Para responder a esta pergunta, precisamos ir um pouco além do que sabemos atualmente sobre protocolos (na realidade só conhecemos um pouco do BGP). Ir um pouco além significa abordar:

  • A diferença entre EGP e IGP.
  • O que se sabe e não se sabe, até agora, sobre o BGP.

Diferenças entre EGP e IGP


Protocolo é uma palavra que referencia múltiplas atividades em uma rede. Por exemplo, protocolo IP é um protocolo que trata do formato de informações que são encaminhadas de um ponto de origem até um ponto de destino de uma rede que trabalha sob as características do protocolo TCP/IP. Protocolo TCP/IP é a designação genérica de um conjunto de atividades que são manipuladas em uma instância do modelo de camadas que conhecemos como OSI. A literatura, às vezes, chama o protocolo IP, que estamos usando como exemplo, de protocolo roteado (“routed protocol”). Já o BGP é um protocolo de roteamento, ou mais formalmente, um protocolo que implementa um algoritmo de roteamento. Protocolos, como o BGP, que implementam um algoritmo de roteamento são reconhecidos protocolos de roteamento dinâmicos, em contraste com os protocolos de roteamento estáticos, onde o ser humano é o agente de sua implementação, isto é, as rotas são implementadas manualmente, nos roteadores.

Há, infelizmente, uma outra confusão na literatura sobre o BGP ser ou não um protocolo dinâmico. Alguns dizem que ele não é dinâmico, nem estático (!?). Outros dizem, como Perlman7, que ele é um protocolo estático. Mais à frente, quando falarmos sobre o BGP, o contexto irá indicar-nos onde ele se insere.

Os protocolos dinâmicos (exceto o BGP…), são implementados usando um dos dois tipos de algoritmos: distance vector e link state. A análise de tais algoritmos nos dará base para a escolha de nosso protocolo inter-domínio. Não iremos entrar em muitos detalhes sobre eles, exceto o necessário para nossas decisões, mas estão muito bem descritos em Perlman7.

Roteamento do tipo “distance vector”

O algoritmo “distance vector” (DV), conhecido também como algoritmo de Bellman-Ford exige que cada nó (ou roteador) da rede envie para seus vizinhos, parte ou toda a informação de sua tabela de roteamento. Para ver seu funcionamento usaremos a rede formada pelo roteador R1, da Figura 7, sobre a qual incluímos uma identificação do enlace (caminho), em vermelho, para efeito didática.

 

Figura 8. Modelo para explicar os tipos de algoritmos.

 

A tabela de roteamento de cada roteador, no início, contem as informações relacionadas com os anúncios que ele deve informar para seus vizinhos, com o único objetivo de que os vizinhos possam atingir toda sua rede. Para entendermos o funcionamento do DV, eis os prefixos de cada um dos 5 roteadores presentes na rede:

R1 abcd:efgh:1::/48
R11 abcd:efgh:11::/48
R12 abcd:efgh:12::/48
R13 abcd:efgh:13::/48
R14 abcd:efgh:14::/48

No início, quando todos os 5 roteadores forem simultaneamente ligados e o algoritmo começar a funcionar (operação conhecida como “cold start” => partida fria), cada um deles terá uma tabela de roteamento construída pelas seguintes informações: para quem anuncia, o quê anuncia, qual o caminho e a distância para atingir (custo), a partir do caminho indicado. Abaixo, eis a imagem de cada tabela de roteamento quando da partida fria, à qual inserimos uma indicação do momento em que isto ocorreu (T). Quando T = 1, o item da tabela foi criado na partida fria. Também, por razões didáticas será acrescentada uma coluna de observações para facilitar o entendimento do algoritmo:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0  
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0  
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  

Cada tabela acima está informando ao seu respectivo roteador, para onde ele deve seguir quando desejar alcançar (atingir), sua própria rede e quanto isto irá custar. O quanto irá custar é o resultado mais importante do algoritmo e recebe o nome do próprio algoritmo: vetor de distância, isto é, “distance vector”.

O próximo passo é cada roteador informar para seus vizinhos o conteúdo de toda sua tabela de roteamento. Por exemplo, o R1 informará para seu único vizinho, R11, o conjunto (R1;abcd:efgh:1::/48;local;0). O R11 irá então instalar em sua tabela de roteamento esta informação de R1 e, consequentemente, aumentará seu conhecimento de atingibilidade, dentro da rede. E assim o nosso T=2 ficará da seguinte forma:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 3 1 Recebida de R11. Criada em T=1.
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0 Criado na partida fria
    2 R1 abcd:efgh:1::/48 1 1 Recebida de R1. Criada em T=1.
    2 R13 abcd:efgh:13::/48 2 1 Recebida de R13. Criada em T=1.
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0 Criada na partida fria.
    2 R13 abcd:efgh:13::/48 4 1 Recebida de R13. Criada em T=1.
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0 Criada na partida fria.
    2 R12 abcd:efgh:12::/48 4 1 Recebida de R12. Criada em T=1.
    2 R11 abcd:efgh:11::/48 2 1 Recebida de R11. Criada em T=1.
    2 R14 abcd:efgh:14::/48 3 1 Recebida de R14. Criada em T=1.
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0 Criada na partida fria.
    2 R13 abcd:efgh:13::/48 3 1 Recebida de R13. Criada em T=1.

Embora o processo de mensagens de um roteador para seus vizinhos esteja sempre acontecendo nossa visão passo a passo observa que a tabela de R11 tem algumas entradas que ocorreram no T=2 que não estão em R1 (a informação sobre o anúncio de R13). O mesmo se pode dizer de R11 em relação a R13 (a entrada de R1) e assim por diante. O algoritmo envia todos os componentes de uma tabela de roteamento. Ao receber a tabela inteira, ele verifica se já existe alguma entrada e se houver, compara o custo com a existente. Se o custo for igual ou maior ignora a entrada. Se for menor, substitui a entrada anterior por esta. Vamos ao passo T=3 e ver o estado de cada tabela, a seguir:

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 1 1  
    3 R13 abcd:efgh:13::/48 1 2 Recebida de R11 (T=2).
  • Tabela do R11:
    T Para O quê Caminho Custo Observações
    1 R11 abcd:efgh:11::/48 local 0  
    2 R1 abcd:efgh:1::/48 1 1  
    2 R13 abcd:efgh:13::/48 2 1  
    3 R12 abcd:efgh:12::/48 2 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:13::/48 2 2 Recebida de R13 (T=2)
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
    2 R13 abcd:efgh:13::/48 4 1  
    3 R11 abcd:efgh:11::/48 4 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:14::/48 4 2 Recebida de R13 (T=2)
  • Tabela do R13:
    T Para O quê Caminho Custo Observações
    1 R13 abcd:efgh:13::/48 local 0  
    2 R12 abcd:efgh:12::/48 4 1  
    2 R11 abcd:efgh:11::/48 2 1  
    2 R14 abcd:efgh:14::/48 3 1  
    3 R1 abcd:efgh:1::/48 2 2 Recebida de R11 (T=2)
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  
    2 R13 abcd:efgh:13::/48 3 1  
    3 R12 abcd:efgh:12::/48 3 2 Recebida de R13 (T=2)
    3 R11 abcd:efgh:11::/48 3 2 Recebida de R13 (T=2)

Vamos ao passo 4. Se nesse ponto houver dúvida sobre o que o algoritmo decide quando recebe uma entrada com um “Para” igual ao destino, basta lembar que na partida fria ele recebe o DV com valor do custo zero.

  • Tabela do R1:
    T Para O quê Caminho Custo Observações
    1 R1 abcd:efgh:1::/48 local 0  
    2 R11 abcd:efgh:11::/48 1 1  
    3 R13 abcd:efgh:13::/48 1 2 Recebida de R11 (T=2).
    4 R12 abcd:efgh:12::/48 1 3 Recebida de R11 (T=3).
    4 R14 abcd:efgh:14::/48 1 3 Recebida de R11 (T=3).
  • Tabela do R11: Sem alteração!
  • Tabela do R12:
    T Para O quê Caminho Custo Observações
    1 R12 abcd:efgh:12::/48 local 0  
    2 R13 abcd:efgh:13::/48 4 1  
    3 R11 abcd:efgh:11::/48 4 2 Recebida de R13 (T=2)
    3 R14 abcd:efgh:14::/48 4 2 Recebida de R13 (T=2)
    3 R1 abcd:efgh:1::/48 4 3 Recebida de R13 (T=3)
  • Tabela do R13: Sem alteração!
  • Tabela do R14:
    T Para O quê Caminho Custo Observações
    1 R14 abcd:efgh:14::/48 local 0  
    2 R13 abcd:efgh:13::/48 3 1  
    3 R12 abcd:efgh:12::/48 3 2 Recebida de R13 (T=2)
    3 R11 abcd:efgh:11::/48 3 2 Recebida de R13 (T=2)
    3 R1 abcd:efgh:1::/48 3 3 Recebida de R13 (T=3)

A tabela de roteamento de cada roteador está completa. É possível perceber que cada roteador tem, em sua tabela de roteamento a imagem de toda a rede da Figura 8. Logo, os anúncios recebidos dos nodos vizinhos garante a visibilidade completa da rede, o que garante uma conectividade completa (ou total), pois consegue-se atingir qualquer um dos IPs anunciados. Uma outra conclusão a ser tirada é de que o algoritmo DV é fácil de entender e implementar. Por outro lado, tabelas de roteamento são trocadas entre os nós, de tempos em tempos, e retransmitidas em intervalos regulares. Dependendo do número de roteadores da rede, os protocolos que implementam o algoritmo DV pode nos trazer sérios problemas. Tais problemas são derivados de uma particularidade no algoritmo chamada de contagem até o infinito, do inglês, “counting to infinity”. Para entender, retornemos à Figura 8, imaginando que a houve um rompimento no enlace entre R14 e R13, como pode ser visto na Figura 9, abaixo:

 

Figura 9. Rompimento de um enlace da topologia.

 

Os roteadores R13 e R14 irão detectar o rompimento do caminho 3, quase que imediatamente. Então eles irão alterar suas respectivas tabelas de roteamento, informando que o custo de tudo aquilo que referencia o caminho afetado (3) terá um custo “infinito”. Vejamos as duas tabelas após o rompimento (agora sem as colunas T e Observações.

  • Tabela do R13 após o rompimento:
    Para O quê Caminho Custo
    R13 abcd:efgh:13::/48 local 0
    R12 abcd:efgh:12::/48 4 1
    R11 abcd:efgh:11::/48 2 1
    R14 abcd:efgh:14::/48 3 infinito
    R1 abcd:efgh:1::/48 2 2
  • Tabela do R14 após o rompimento:
    Para O quê Caminho Custo
    R14 abcd:efgh:14::/48 local 0
    R13 abcd:efgh:13::/48 3 infinito
    R12 abcd:efgh:12::/48 3 infinito
    R11 abcd:efgh:11::/48 3 2
    R1 abcd:efgh:1::/48 3 infinito

Mas, os roteadores R12, R11 e R1 não conseguem enxergar tal rompimento imediatamente, e consequentemente não sabem que o R14 está isolado. Eles dependem de uma atualização do R13. Suponha que R12 ainda não tenha sido atualizado por R13. Então, a tabela de roteamento de R12 continua a mesma, isto é:

  • Tabela do R12, ainda sem conhecimento do rompimento:
    Para O quê Caminho Custo
    R12 abcd:efgh:12::/48 local 0
    R13 abcd:efgh:13::/48 4 1
    R11 abcd:efgh:11::/48 4 2
    R14 abcd:efgh:14::/48 4 2
    R1 abcd:efgh:1::/48 4 3

O procedimento de atualização das tabelas é automático e não sabemos o momento e quais vizinhos são notificados por quem. Vamos então, supor que R12 encaminhe sua tabela para R13. Ao recebê-la, R13 verifica que o seu registro atual do anuncio de R14 está com o valor infinito (ou maior do que o registro de R12, para R14). Então, ele troca o registro de R14 pelo que R12 enviou. A nova tabela de R13 fica assim:

  • Tabela do R13 após o rompimento:
    Para O quê Caminho Custo
    R13 abcd:efgh:13::/48 local 0
    R12 abcd:efgh:12::/48 4 1
    R11 abcd:efgh:11::/48 2 1
    R14 abcd:efgh:14::/48 3 infinito
    R1 abcd:efgh:1::/48 4 3

Com este arranjo na tabela de roteamento de R13, teremos os seguintes cenários:

  • Qualquer pacote, vindo de fora, com destino final R14 passará por R13. R13 o encaminhará para R12. R12 devolve-o para R13, que por sua vez envia de volta a R12 e assim por diante, até que o tempo de vida (“TTL”) do pacote expire. Qualquer pacote tem um TTL, mas quem decide sobre ele é outro protocolo. Este efeito saltitante, do pacote formando “loop” é denominado “bouncing effect”.
  • Se R13 enviar uma atualização de tabela para R11, a entrada para R14 nunca será alterada, pois o custo atual de R14 na tabela de R11 é menor. Logo, qualquer pacote vindo de fora, na direção de R14 passará por R13.
  • As atualizações de tabelas de roteamento provocadas por R12 e R13, sempre irão aumentar, rapidamente, na direção do infinito. Este efeito é denominado contagem até o infinito, ou “counting to infinity”.

Este cenário, muito conhecido, fez com que as implementações do algoritmo DV incorporassem técnicas para responderem tanto ao efeito saltitante quanto o efeito da contagem para o infinito. O RIP, que implementa o DV, possui tais técnicas, que fogem de nosso propósito. Em redes internas pequenas, o RIP funciona muito bem. Em grandes redes (muitos roteadores), certamente haverá queda sensível na eficiência do tráfego, se o algoritmo DV for usado. O dilema, então está construído: fácil de entender, mas restrito em cenários de falha. Em redes redundantes, entretanto, ele se mostra uma bela alternativa.

Conclusão

Protocolos que implementam o algoritmo distance vector, não estão nos nossos planos para a topologia da Figura 7. Portanto, precisamos analisar o algoritmo link state. Um protocolo muito usado que implementa esse algoritmo é o OSPF.

Após tal análise é necessário justificar a escolha do iBGP. Para implementá-lo deve-se ampliar o conhecimento sobre ele. Em particular há duas questões importantes no BGP que devem ser apreciadas: route reflection e confederações.

Feito isto estaremos prontos para o conhecimento prático do iBGP, que é sua implementação. Estas questões serão motivos para os próximos documentos aqui do blogue.

 

Referências

  1. John W. Stewart III. (1999). BGP4: Inter-Domain Routing in the Internet. Addison-Wesley.

  2. 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).

  3. RFC6286, Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen, J. Yuan [ June 2011 ] (TXT = 7497) (Updates RFC4271) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr)

  4. Xiaoliang Zhao , Beichuan Zhang , Dan Massey , Lixia Zhang, A Study on BGP AS Path Characteristics. Disponível em: http://www.cs.colostate.edu/~massey/pubs/tr/massey_usctr04-818.pdf. Acessado em 10/03/2011.

  5. Braga, J. (2008). Glossário da Infraestrutura da Internet. Disponível em: https://juliaobraga.wordpress.com/2008/12/01/glossario/. Acessado em 05/11/2011.

  6. Caesar, M., & Rexford, J. (21 de novembro de 2005). BGP routing policies in ISP networks. Acesso em 25 de novembro de 2011, disponível em Princenton University: http://www.cs.princeton.edu/~jrex/papers/policies.pdf

  7. Perlman, R. (1999). Interconnection: bridges, routers, switches and internetworking protocols (2a. ed.). Addison-Wesley.
  8. RFC4456,BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) T. Bates, E. Chen, R. Chandra [ April 2006 ] (TXT = 23209) (Obsoletes RFC2796, RFC1966) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr)
  9. Russ White, D. M. (2005). Practical BGP. Boston, MA, USA: Pearson Education, Inc.
Categories: BGP, Bogon, eBGP, iBGP, IPv4, IPv6, PTT, TCP/IP