Início > BGP, Mikrotik, TCP/IP > BGP no Mikrotik: Dois operadores de trânsito

BGP no Mikrotik: Dois operadores de trânsito


“Sistematicamente, evito colocar meu pensamento na Religião
quando trato de Ciência,
assim como o faço em relação à moral,
quando trato de assuntos referentes à Sociedade.

Charles Darwin: A Origem das Espécies
(último parágrafo).

 

Introdução

 

Duas consultas me foram feitas e ambas relacionadas com uma topologia em que haviam dois operadores de trânsito (digamos, Trânsito1 e Trânsito2). A primeira consulta estava preocupada com o fato de que um dos operadores de trânsito somente seria usado por demanda, isto é: o Trânsito1 seria usado normalmente e o Transito2, somente se falhasse o Trânsito1. A segunda consulta era mais simples: ambos os operadores de trânsito seriam usados com tráfeto de saída balanceado. Embora simples, a segunda consulta envolvia maior complexidade do que a primeira, em tese. Principalmente, se a preocupação do balanceamento envolvesse o tráfego de entrada.

Além de responder às duas consultas iremos abordar o máximo possível de alternativas envolvendo a topologia com dois operadores de trânsito. Isto será feito em diversas etapas, embora as informações aqui presentes já sejam suficientes para resolver todos os problemas, desde que adicione conhecimento das informações disponíveis nos sítios de consulta.

 

A topologia

 

Para simular esta topologia no FFE precisaremos da representação de toda a Internet. Vejamos a proposta do modelo, na Figura 1 e depois sua caracterização, no FFE.

 

Figura 1. Um provedor, dois operadores de trânsito e a Internet.

 

Para facilitar nosso modelo da Internet, vamos colocar os dois provedores de trânsito fazendo empareamento com o AS65333 e este falando com a Internet. O AS65333 é quem recebe qualquer anúncio e envia-os aos seus pares, sem restrições. Para simular tabelas de roteamento completa e parcial, acrescentaremos em Networks do AS65333 quantos blocos desejarmos ou forem necessários para cumprir o efeito didádico da Internet, no FFE, incluindo IPs privativos e bogons.

 

A configuração do AS65533

 

A primeira parte da configuração do AS65533 (que representa para nós, a Internet) está representadas na Figura 2, abaixo.

 

Figura 2. Configuração do AS65533 (I).

 

Há um único comentário a ser feito, neste momento, em relação à Figura 2. Trata-se da janela da lista de rotas e anotada por uma seta em vermelho. Ela faz referência à rota do bloco 10.0.0.0/24 que pertence ao Provedor, apresentado na Figura 1. O Winbox exibe rotas alternativas em azul, pois há duas (1a. e 2a. linhas, da mesma janela). A rota preferencial é via o provedor de Trânsito 2. A grande maioria esquece porque acontece isto. Porque? Mais adiante daremos a resposta. Em prosseguimento, a Figura 3, que segue, exibe o restante da configuração do AS65533, que nos interessa conhecer.

 

Figura 3. Configuração do AS65533 (II).

 

Configuração do AS65531 (Trânsito 1)

 

A Figura 4, abaixo, exibe a primeira parte da configuração do AS65531 (provedor de Trânsito 1) e a Figura 5, o restante da configuração e resultados.

 

Figura 4. Configuração do AS65531 (I).

 

Na última janela da Figura 4, o “Router ID” está com uma lembrança em vermelho. O “Router ID” tem um significado importante para nosso entendimento da razão pela qual o BGP escolhe as rotas alternativas. Vamos lembrar disso, pois poucos dão explicações claras sobre o “Router ID”. Sempre ouvimos: “coloque um IP de uma de suas interfaces”. Esta resposta não é suficientemente apropriada, pois o “Router ID” é um dos componentes importantes para a decisão do BGP em relação a escolha do roteamento, como veremos logo abaixo.

 

Figura 5. Configuração do AS65531 (II).

 

Configuração do AS65532 (Trânsito 2)

 

A Figura 6 apresenta a primeira parte da configuração do AS65532 (Trânsito 2). Novamente a seta vermelha questionando: “porque a escolha como rota não preferencial?”.

 

Figura 6. Configuração do AS65532 (I).

 

A Figura 7 exibe o restante da configuração do AS65532.

 

Figura 7. Configuração do AS65532 (II).

 

Configuração do AS65530 (Provedor)

 

As figuras que seguem, mostram as configurações do roteador do Provedor.

 

Figura 8. Configuração do AS65530 (I).

Indicações em vermelho, as rotas não preferenciais. Portanto, o tráfego do Provedor está saindo todo pelo provedor de Trânsito 1.

 

Figura 9. Configuração do AS65530 (II).

 

A Figura 9, acima, mostra as configurações do BGP para o Provedor e exibe que seu bloco está sendo anunciado para ambos, Trânsito 1 e Trânsito 2, muito embora tenha sido mostrado que tráfego esteja saindo somente pelo Trânsito 1. O anúncio para ambos os provedores de trânsito garantem que estamos corretos no filtro mostrado na Figura 10, onde está sendo marcado o “Invert Match” com o “Discard” no “Action”: tudo é bloqueado exceto o bloco 10.0.0.0/24!

 

Figura 9. Configuração do AS65530 (II).

 

O processo de decisão do BGP

 

  1. Rota com o maior valor de “Weight”. O valor padrão do “Weight” é zero.
  2. Rota com o maior valor no “Local Preference”, cujo valor padrão é 100.
  3. Rotas geradas localmente (rotas estáticas).
  4. Rota com menor “as_path”.
  5. Rota com menor ORIGIN, na ordem: IGP, EGP e INCOMPLETE.
  6. Rota com o menor MED (“Multiple Exit Discriminator”).
  7. Preferência por rotas geradas por eBGP, sobre rotas recebidas por iBGP.
  8. Rota recebida por anúncio vindo do “next_hop” do IGP mais próximo (de menor custo).
  9. Rota com o caminho cujo empareado tiver menor “ROUTER_ID”.

 

O último item responde à questão das rotas não preferenciais, razão pela qual está em negrito. Não lembrar disto, tem sido motivo, sistemático, de imenso desespero para os responsáveis pelo BGP.

Outra questão importante a ser observada na implementação dos BGPs que falam acima é o fato de não ter sido usado rota padrão (“default”) em nenhum dos Mikrotiks envolvidos.

 

Deficiências do modelo

 

Há várias deficiências no modelo da Figura 1 e das informações sobre cada um dos roteadores. Vamos enumerar tais deficiências:

  1. Há um excesso de visibilidade das informações sobre cada roteador do modelo. Na prática, o Provedor, não conhece como ou o quê está implementado nos roteadores de outros BGPs que falam, empareados ou não. Portanto, não devemos ter a ilusão de alterar o estado de coisas neles apresentadas. Geralmente nossa preocupação é com o tráfego que entra (“inbound”) e que sai (“outbound”). Nossa interferência sobre os provedores de trânsito, em particular, somente poderá ser feita via parâmetros do BGP. Boa parte de tais possíveis interferências foram descritas nos textos que estão apresentados nas referências abaixo.
  2. Estamos simplificando bastante o modelo ao colocarmos somente Mikrotiks. A realidade é diferente. Há uma variedade imensa de roteadores na Internet. Trata-se de um modelo estritamente didático.
  3. Estamos usando ASNs e blocos de IPs privativos. Portanto, devemos nos abstrair do fato de que isto não é uma realidade, também.
  4. O modelo somente implementa o eBGP. Vale lembrar de que não teremos iBGP, o que alteraria a forma de pensar e, acrescentaria maior complexidade.
  5. O modelo é extremamente simples e orientado para pequenos/médios Provedores. O BGP é, por outro lado, extremamente complexo e incorpora outros procolos, como o iBGP, além de se interagir com o OSPF, RIP, MPLS entre outros. O texto de Russ White et alii[1] é completo para topologias que se estendem acima da simplicidade do que está sendo dito aqui.

 

Comentários rápidos e adicionais

 

  • As observações acima, juntamente com os textos anteriores do BGP em Mikrotik (listados abaixo) são suficientes para resolver o problema do trânsito por demanda (trânsito de redundância ou de “backup”). Embora, não tão intuitivamente, responderiam à questão do balanceamento do tráfego de saída (e de entrada, como consequência direta). Na sequência, aqui no blogue faremos esforços para explicar as impossibilidades técnicas para que o Provedor implemente soluções que desejaria, como por exemplo, o balanceamento usando todo o seu bloco de IPs.
  • A implementação do BGP de maneira simples, com filtros básicos cria o cenário de enlace redundante, imediatamente, como é o caso do tráfego saindo pelo Trânsito 1, por força da escolha pelo menor “Router ID”. O anúncio do bloco inteiro é necessário para os dois enlaces de trânsito. Assim, em dois enlaces de trânsito, a solução mais razoável é que um deles seja por demanda.
  • A melhor forma de balanceamento em cenários onde o Provedor não se comunica bem com seus trânsitos é dividir o anúncio dos blocos. Para manter o fluxo redundante é necessário anunciar, também, o bloco inteiro para ambos operadores de trânsito.
  • Dois provedores de trânsito com bandas diferentes, a melhor alternativa é o uso de comunidades e, neste caso, ótimo relacionamento com os provedores de trânsito para implementar iBGP, complementarmente. Veja em [1], página 265.
  • A principal conclusão quando lidamos com a implementação de BGP em mais de um enlace de trânsito é de que o planejamento é fundamental e, portanto, imprescindível. O administrador da infraestrutura de Internet do Provedor precisa manter um conhecimento atualizado e profundo do BGP e protocolos associados.

 

Iremos alterar este texto, na medida do tempo possível, para incluir abordagens mais específicas e, eventuais correções. Isto ocorrerá tantas vezes quanto necessário, para exibir maior clareza e entendimento do texto. Neste aspecto, a ajuda do leitor será extremamente útil!!!

 

Assuntos relacionados, neste blogue

 

  1. BGP em Mikrotik – Parte I
  2. BGP em Mikrotik – Parte II
  3. BGP em Mikrotik – Parte III
  4. BGP no Mikrotik (IV): Anúncios e rotas no FFE
  5. BGP no Mikrotik (V): Analisando anúncios de implementações de BGP
  6. BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup
  7. BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
  8. BGP no Mikrotik (VIII): Alterando a política de roteamento
  9. BGP no Mikrotik (IX): Filtros
  10. Atributos do BGP
  11. BGP no Mikrotik (IX): Filtros
  12. BGP: Tabelas de roteamento
  13. Convergência, no BGP

 

Referências

 

  1. Russ White, Danny McPherson, Srihari Sangli. Practical BGP. Pearson Education, Inc. 2005.

Categorias:BGP, Mikrotik, TCP/IP
  1. 08/08/2011 às 11:21

    Maravilha esse post amigo, veio podemos dizer que na hora certa heheheh.

    Estamos com AS nas mãos e dando inicio no bgp com as operadoras (No caso 2), to revirando a internet em busca de informações sobre o bgp.
    So que no caso o tamanho dos links são bem diferentes um de 10 mega e outro de 35.

    Você pode me indicar algum documentos sobre o bgp a mais?
    (deprefencial que seja em PT-BR), sei que o ingles hoje é essencial mais ainda to engatinhado nisso e s tradutores nao ajudam muito ne.

    De mais obrigado pelo post esta otimo .

    Abraços.

    • juliaobraga
      08/08/2011 às 16:41

      Olá Rocha,

      Acrescentei o conjunto de textos sobre BGP em Mikrotik, do bloque. Cada um tem referências adicionais.

      Obrigado.

      Julião

  2. alexasouza
    03/04/2014 às 11:03

    Gostaria de saber se tenho como colocar um link ADSL como Backup ou balancear no BGP? Obrigado.

    • juliaobraga
      03/04/2014 às 13:49

      Olá Alex,

      1. BGP não faz balanceamento. Portanto, a segunda pergunta é não.
      2. Primeira pergunta: Sim você pode colocar um link ADSL como redundância do seu BGP. Entretanto, dificilmente você conseguirá que seu trânsito aDSL faça um “peering” com você. Assim, a alternativa viável para isto é você fazer uma VPN com alguém que admita este empareamento.

      • alexasouza
        04/04/2014 às 09:07

        Tenho um novo projeto que é o seguinte;
        Dois (2) Link ADSL de 50Mbps cada, só que em cidade diferentes interligados via WI-FI (Enlace), esses dois link se encontra no final, tenho como configurar esses enlaces em BGP só para ter redundância, usando AS privadas?
        Obs: ADSL em bridge ou router tanto faz, posso utilizar dos dois modos.

      • juliaobraga
        04/04/2014 às 11:14

        Alex,

        BGP usando AS privativo entre os dois links, você pode fazer. Redundância? Ah! Desenhe a topologia e pense, para responder a você mesmo. Dica: qualquer protocolo só irá funcionar, se houver conectividade! Pensando sobre a topologia, você fará, também a si próprio, outras perguntas… E terá as respostas.

  3. alexasouza
    03/04/2014 às 11:04

    OBS: Já tenho um BGP em funcionamento

  4. 05/08/2015 às 10:09

    Olá. Tenho um link de uma operadora em BGP e quero colocar uma redundância saindo por outra operadora, porem esta redundancia será fornecida em um /30. Como posso fazer esa configuração numa CCR1036? Obrigado

  1. 21/08/2011 às 17:47
  2. 23/03/2012 às 00:17

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: