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.

 

 

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.

 

 

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.

 

 

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.

 

 

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.

 

 

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?”.

 

 

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

 

 

Configuração do AS65530 (Provedor)

 

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

 

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

 

 

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!

 

 

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.

Follow @juliaobraga