Início
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 a sequir 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
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:
Fonte: http://juliaobraga.wordpress.com/2011/08/07/bgp-no-mikrotik-dois-operadores-de-transito/
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 a sequir 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:
- a. 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.
b. 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.
c. Estamos usando ASNs e blocos de IPs privativos. Portanto, devemos nos abstrair do fato de que isto não é uma realidade, também.
d. 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.
e. 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.
Fonte: http://juliaobraga.wordpress.com/2011/08/07/bgp-no-mikrotik-dois-operadores-de-transito/
