Arquivo

Archive for agosto \21\-03:00 2011

BGP no Mikrotik: Dois operadores de trânsito (Visão genérica)


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


Últimas atualizações:
22/08/2011 19:33 => Descrição sumária do modelo.
22/08/2011 17:21 => Nova figura 1. Modelo mais completo.
22/08/2011 12:27 => Processo de decisão do BGP (refinamento).

Um modelo mais genérico no FFE para dois operadores de trânsito.

O artigo anterior, sobre o mesmo assunto (dois provedores de trânsito), não foi escrito de forma genérica para permitir diversos exercícios sobre a complexidade do BGP. À medida que este for evoluindo, o antigo desaparecerá, já que perderá o sentido. Eis nosso modelo, na Figura 1. Na sequência o uso do VMWare é mostrado com detalhes suficientes para se assegurar a independência das máquinas virtuais.

 

Figura 1. Modelo genério para dois servidores de trânsito

 

Sumário descritivo do modelo.

A seguir, algumas informações descritivas do modelo da Figura 1.

  • O AS65533 é o Mikrotik virtual, representado por Internet é aquele que dará “acesso” à Internet. Na prática isto não acontecerá, mas os IPs dentro do bloco 10.33.0.0/19 representarão a Internet. Se necessário iremos divulgar outras redes para dentro do modelo.
  • O AS65531 é o primeiro fornecedor de trânsito para o Provedor, reconhecido como Transito1.
  • O AS65532 é o segundo fornecedor de trânsito para o Provedor, reconhecido como Transito2.
  • O AS65530 é o Provedor, proprieamente dito, cuja rede local só possui o Notebook. O Notebook tem acesso direto ao Mikrotik Provedor e somente terá acesso aos outros Mikrotiks virtuais através do BGP que fala do Provedor.
  • Em casos especiais, já que as máqinas virtuais estão instaladas no Notebook será permitido o acesso a todos os Mikrotiks virtuais, através do console do VMWare, descrito logo abaixo. Até o momento e salvo dito ao contrário, o único acesso foi feito no início, para instalação dos IPs das interfaces de cada um e respectivo BGP. O objetivo sempre será o de preservar o modelo, contra interferências externas sobre a rede construida e, assim, sua integridade funcional.
  • Em preto, os IPs das respectivas interfaces, compatíveis com os anúncios de cada Mikrotik virtual (em vermelho).
  • Na configuração inicial não há rota padrão no ambiente e nem, tampouco, filtros. A ausência de rota padrão somente permite acessibilidade aos IPs anunciados (e, utilizados…). Com isso a simulação de TODA a Internet no AS65533, está prejudicada, nesse momento. O espírito didático do modelo permitirá que isto esteja completo no momento oportuno. Entretanto, nada impede que se pense como será feito…
  • Uma consideração importante que vale a pena antecipar é o fato de que, apesar da ausência de filtros, cada AS não recebe seu próprio anúncio de qualquer BGP que fala empareado a ele. Isto é uma característica do próprio BGP, como forma de garantir a ausência de laços infinitos (“loop”).

O modelo do FFE e o VMWare

Sabe-se que o FFE é construído sob o VMWare. A estrutura do VMWare nos oferce o conceito de switches virtuais. A Figura 2, obtida de [2] – página 3 – exibe o modelo conceitual de switches virtuais, no VMWare.

Figura 2. Switches virtuais no VMWare

 

A Figura 3 exibe o “console” do VMWare quando se agrupam as 4 máquinas virtuais do modelo em um “team”. É através do console que se tem acesso inicialmente aos respectivos Mikrotiks que preenchem o modelo da Figura 1.

Figura 3 - Console do VMWare quando agrupamos as 4 máquinas virtuais.

Da descrição detalhada, no documento [2] é suficiente lembar que os switches virtuais trabalham na Camada 2 e são invioláveis em relação a eventuais tentativas de compartilhamento, uma vez que para cada placa de rede virtual (de cada máquina virtual) associamos um único switch virtual. A tabela abaixo exibe a associação unívoca, de cada umas das três placas de rede (interfaces 0, 1 e 2), disponíveis em cada máquina virtual (MV, e o ASN), com um dos 8 switches criados para o modelo do FFE, da Figura 1:

  Switch 0 Switch 1 Switch 2 Switch 3 Switch 4 Switch 5 Switch 6 Switch 7
 MV 65530  LAN (0)  Transito1 (1)   Transito2 (2) 
 MV 65531  Provedor (1) Internet (2) LAN (0)
 MV 65532   Provedor (1)   Internet (2)  LAN (0)
 MV 65533   Transito1 (1)   Transito2 (2)  Internet (0)

Tabela 1. Switches virtuais e respectivas associações aos membros do FFE.

 

As figuras 4 e 5, abaixo mostram, respectivamente, as interfaces (virtuais) do Notebook e as rotas do Notebook.

 

Figura 4 - Interfaces virtuais, criadas no Notebook.

 

Figura 5 - Rotas do Notebook, após alterações.

 

Na Figura 4 vê-se que somente as interfaces da rede local e “VMnet0” estão ativas. Na Figura 5, retirou-se a rota padrão para “VMnet0”, estabelecida automaticamente pelo Windows e acrescentou-se a rota 10.0.0.0/8 para a interface da LAN do Provedor. De ambas, pode-se concluir que a Rede Local do Notebook não é compartilhada com as máquinas virtuais, já que ela é a saída para a Internet via NAT.

O processo de decisão do BGP

Eis uma relação, praticamente completa, que ilustra o comportamento do mecanismo de decisão do BGP.

  1. Não considere como sendo caminho (“path”), se não há rota para o próximo caminho. Em outras palavras, selecione somente as rotas cujo “next_hop” seja atingível.
  2. Maior valor de “Weight”. O valor padrão do “Weight” é zero. Embora seja um parâmetro da Cisco, já está implementado no Mikrotik.
  3. Maior valor no “Local Preference”, cujo padrão é 100.
  4. Rotas geradas localmente sendo que as rotas geradas localmente pelo próprio BGP têm a preferência.
  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. Caminho com menor custo IGP para o “next_hop”.
  9. Para caminhos eBGP: (a) se o “multipath” está habilidtado, instala n caminhos paralelos na tabela de encaminhamento; (b) se o “router-id” é o mesmo, vá para a próxima alternativa; (c) se o “router-id” não é o mesmo, selecione o caminho mais antigo.
  10. Rota com o caminho cujo empareado tiver menor “router_id” (“originator-id” para rotas refletidas).
  11. Menor “cluster-list”. Atenção aos atributos de “Route Reflector”.
  12. Menor endereço de vizinhança se o “router_id” for o mesmo.

Após o processo acima terminar, uma rota somente é colocada na tabela de rotas se não há outra rota com prefixo maior ou com distância administrava melhor. A decisão relacionada com o prefixo maior, leva muitos administradores a desagregar anúncios como “lei do menor esforço” no sentido de estabelecer prioridades de rotas. Esta ação agride frontalmente as preocupações de agregação, que reduziriam a tabela de roteamento, entre outras questões já abordadas. Um exemplo é a facilidade em induzir rotas ping-pong, afetando drasticamente a convergência do BGP.

O item em negrito na relação acima, justificará porque o tráfego que vai e volta para a Internet considera o operador Transito1, na implementação sem filtro.

Pelo que se observa, o BGP que fala sempre estabelecerá um único caminho para uma rota (o melhor!!). É uma característica, inerente ao comportamento do BGP. Assim ele foi projetado. Pergunta 1: é possível fazer balanceamento, com o BGP? Pergunta 2: é possível fazer distribuição de tráfego, no BGP? Se sim, qual seria o conflito com as melhores práticas e recomendações gerais da comunidade?

Comportamento do modelo

As Tabelas 2, 3 e 4 exibem as configurações implementadas em cada um dos Mikrotiks virtuais, nos quais não foram usados nenhum filtro.

Máquina Virtual Interface IP Address
Provedor
0 R S0_LAN
1 R S1_Transito1
2 R S2_Transito2

0 10.1.0.2/30 10.1.0.0 S1_Transito1
1 10.0.0.1/30 10.0.0.0 S0_LAN
2 10.2.0.2/30 10.2.0.0 S2_Transito2
Transito1
0 R S1_Provedor
1 R S3_Internet
2 R S4_LAN

0 10.1.0.1/30  10.1.0.0  S1_Provedor

1 10.33.1.2/30 10.33.1.0 S3_Internet
Transito2
0 R S2_Provedor
1 R S5_Internet
2 R S6_LAN

0 10.2.0.1/30  10.2.0.0  S2_Provedor

1 10.33.2.2/30 10.33.2.0 S5_Internet
Internet
0 R S3_Transito1
1 R S5_Transito2
2 R S7_LAN

0 10.33.1.1/30 10.33.1.0 S3_Transito1

1 10.33.2.1/30 10.33.2.0 S5_Transito2

Tabela 2. Interfaces e respectivos IPs, de cada componente.

MVirtual Instância Peer Network Anúncios
Provedor
name=”default”
as=65530
router-id=10.0.0.1

0 E default 10.1.0.1 65531

1 E default 10.2.0.1 65532

0 10.0.0.0/19 no

T1 10.2.0.0/19 10.1.0.2 65532 igp

T1 10.0.0.0/19 10.1.0.2 igp

T2 10.33.0.0/19 10.2.0.2 65531,65533 igp

T2 10.1.0.0/19 10.2.0.2 65531 igp

T2 10.0.0.0/19 10.2.0.2 igp
Transito1
name=”default”
as=65531
router-id=10.1.0.1

0 E default 10.33.1.1 65533

1 E default 10.1.0.2 65530

0 10.1.0.0/19 no

I 10.0.0.0/19 10.33.1.2 65530 igp

I 10.2.0.0/19 10.33.1.2 65530,65532 igp

I 10.1.0.0/19 10.33.1.2 igp

P 10.33.0.0/19 10.1.0.1 65533 igp

P 10.1.0.0/19 10.1.0.1 igp
Transito2
name=”default”
as=65532
router-id=10.2.0.1

0 E default 10.2.0.2 65530

1 E default 10.33.2.1 65533

0 10.2.0.0/19 no

P 10.33.0.0/19 10.2.0.1 65533 igp

P 10.2.0.0/19 10.2.0.1 igp

I 10.1.0.0/19 10.33.2.2 65530,65531 igp

I 10.0.0.0/19 10.33.2.2 65530 igp

I 10.2.0.0/19 10.33.2.2 igp
Internet
name=”default”
as=65533
router-id=10.33.1.1

0 E default 10.33.1.2 65531

1 E default 10.33.2.2 65532

0 10.33.0.0/19 no

T1 10.2.0.0/19 10.33.1.1 65532 igp

T1 10.33.0.0/19 10.33.1.1 igp

T2 10.0.0.0/19 10.33.2.1 65531,65530 igp

T2 10.1.0.0/19 10.33.2.1 65531 igp

T2 10.33.0.0/19 10.33.2.1 igp

Tabela 3. Implementação dos MKs virtuais no FFE (P~Provedor, T1~Transito1, T2~Transito2 e I~Internet).

Máquina Virtual

Rotas

Flags: X – disabled, A – active, D – dynamic,
C – connect, S – static, r – rip, b – bgp,
o – ospf, m – mme, B – blackhole,
U – unreachable, P – prohibit

Provedor
0 ADC 10.0.0.0/30  10.0.0.1 S0_LAN        0
1 ADb 10.1.0.0/19  10.1.0.1              20
2 ADC 10.1.0.0/30  10.1.0.2 S1_Transito1  0
3 ADb 10.2.0.0/19  10.2.0.1              20
4 ADC 10.2.0.0/30  10.2.0.2 S2_Transito2  0
5 ADb 10.33.0.0/19 10.1.0.1              20
6  Db 10.33.0.0/19 10.2.0.1              20
Transito1
0 ADb 10.0.0.0/19  10.1.0.2              20
1 ADC 10.1.0.0/30  10.1.0.1  S1_Provedor  0
2 ADb 10.2.0.0/19  10.1.0.2              20
3  Db  10.2.0.0/19 10.33.1.1             20
4 ADb 10.33.0.0/19 10.33.1.1             20
5 ADC 10.33.1.0/30 10.33.1.2 S3_Internet  0
Transito2
0 ADb 10.0.0.0/19  10.2.0.2              20
1  Db 10.0.0.0/19  10.33.2.1             20
2 ADb 10.1.0.0/19  10.2.0.2              20
3  Db 10.1.0.0/19  10.33.2.1             20
4 ADC 10.2.0.0/30  10.2.0.1 S2_Provedor   0
5 ADb 10.33.0.0/19 10.33.2.1             20
6  Db 10.33.0.0/19 10.2.0.2              20
7 ADC 10.33.2.0/30 10.33.2.2 S5_Internet  0
Internet
0 ADb 10.0.0.0/19  10.33.1.2              20
1  Db 10.0.0.0/19  10.33.2.2              20
2 ADb 10.1.0.0/19  10.33.1.2              20
3  Db 10.1.0.0/19  10.33.2.2              20
4 ADb 10.2.0.0/19  10.33.2.2              20
5  Db 10.2.0.0/19  10.33.1.2              20
6 ADC 10.33.1.0/30 10.33.1.1 S3_Transito1  0
7 ADC 10.33.2.0/30 10.33.2.1 S5_Transito2  0

Tabela 4. Tabela de roteamento dos componentes do modelo.

 

O “traceroute” abaixo foi feito do Notebook que está com o IP 10.0.0.2/30, na diração de Internet. Ele indica que o tráfego passa pelo operador Transito1

tracert 10.33.2.1

Rastreando a rota para 10.33.2.1 com no máximo 30 saltos

  1    <1 ms    <1 ms    <1 ms  10.0.0.1
  2    13 ms    <1 ms    <1 ms  10.1.0.1
  3     2 ms     1 ms    <1 ms  10.33.2.1

Rastreamento concluído.

 

O “traceroute” que segue é de Internet na direção do Notebook. Apesar de um possível “loop” em seu resultado é possível ver que o tráfego de entrada passa pelo Trânsito1. Nesta configuração o tráfego via Transito2 somente ocorrerá se houver uma ruptura nas conexões via Transito1.

[admin@Internet] > tool traceroute 10.0.0.2
 # ADDRESS                                 RT1   RT2   RT3   STATUS              
 1 10.33.1.2                               1ms   1ms   1ms                       
 2 10.1.0.2                                1ms   1ms   1ms                       
 3 0.0.0.0                                 0ms   0ms   0ms                       
 4 0.0.0.0                                 0ms   0ms   0ms                       
 5 0.0.0.0                                 0ms   0ms   0ms                       
 6 0.0.0.0                                 0ms   0ms   0ms
 ...

 

Duas questões aparecem na configuração padrão e sem filtros: (a) porque a escolha de Transito1 e, (b) porque o loop no “traceroute” de entrada. Pergunta 3: Alguém poderia responder (b)?

Filtros

Ao pensar em filtros deve-se ter em mente as preocupações do BGP que fala sobre o qual temos o controle. No nosso modelo, em tese, só temos controle sobre o Provedor. Entretanto, vale pensar o resto do mundo para que se possa exercitar as melhores prática em BGP. Vamos enumerar e executar os filtros, caracterizando os dois respectivos ambientes: o BGP local – L -, Provedor e o BGP do resto do modelo – RDM -, Transito1, Transito2 e Internet. Vale algumas observações: (a) o RDM são os provedores de trânsito (“upstream”); (b) o Provedor é o “downstream” de Transito1 e Transito2 e estes, “downstreams” do Internet, que por sua vez é o “upstream” de ambos os provedores de trânsito do Provedor.

  1. RDM: Os provedores de trânsito não deveriam aceitar prefixos que não os acordados com seus clientes. Esta é uma das razões pelas quais as operadoras de trânsito encaminham um formulário, como pré-requisito, para a implementação do empareamento. A outra razão é que as operadoras precisam de encaminhar para seus empareados a informação de que um novo anúncio será feito (isto, também, o Provedor terá de fazer, caso ele venha a se tornar um operador de trânsito!). E, imagina-se, que o provedor de trânsito, ao receber o formulário tome algumas providências como, por exemplo verificar no “whois” se o bloco informado pertence mesmo ao “downstream”. Ultimamente, isso deve estar acontecendo, pois os provedores de trânsito esperam que o AS empareado – ASE – esteja com suas políticas registradas em algum IRR (“Internet Routing Register”). Pergunta 4: Se o “Provedor” passa a fornecer trânsito para terceiros, como será o anúncio para seus pares, dos blocos de terceiros?
  2. RDM: Um Provedor de trânsito com o objetivo de interagir com a Internet. Portanto o Provedor precisa receber para que a interação completa seja possível. É uma exigência contratual. Entretanto, deve-se ter em mente o componente humano envolvido na cadeia de suprimentos do BGP e, portanto faz parte do trabalho do admnistrador de um BGP que fala, se dispor a verificar se tudo está conforme as especificações e, em particular, se as informações estão disponíveis nessa cadeia. Há muitas falhas na cadeia, pois a Internet tem crescido com tamanha rapidez que os seres humanos envolvidos podem se perder em algum momento. Um dos principais alvos da inadequada interferência humana é a convergência do BGP.
  3. ASE: Um ASE somente deve aceitar prefixos que tenham sido previamente acordados com o outro ASE. Se um ASEi acordou em receber uma tabela de roteamento parcial de um ASEj, então o ASEi deve imaginar a possibilidade do ASEj estar lhe mandando uma tabela de rotas completa.
  4. ASE: Somente se deve anunciar prefixos acordados com o outro empareado.
  5. L: Não aceite prefixos especificados na RFC3330.
  6. L: Não aceite os próprios prefixos.
  7. L: Somente anuncie os próprios prefixos. Ou de seus “downstreams” associados aos respectivos ASes.
  8. L: Não aceite a rota padrão, exceto se ela for necessária.
  9. L: Não aceite prefixos especificados na RFC3330.
  10. L: Não aceite prefixos da relação de “Bogon”. Faça isso, inicialmente, manualmente mas não deixe de implementar um empareamento com o Team Cymru, [5], para tornar o processo automatico e, consequentemente, bem menos trabalhoso.
  11. L: Ative a opção de remover ASN privativos do anúncios. No nosso modelo isso não será possível. Mas o nosso modelo é um simples modelo.
  12. L: Limite o comprimento do AS_path (20, ou avalie outro valor, com base na experiência do dia a dia). Tal restrição, geralmente é feita quando se quer receber somente a tabela de roteamento parcial.
  13. L: Usar a técnica do TTL hack especificando, nos empareamentos, o TTL 255. Maiores informações em [4].

 

Assuntos relacionados, neste blogue

  1. BGP no Mikrotik: Dois operadores de trânsito. Versão anterior a este artigo.
  2. BGP em Mikrotik – Parte I
  3. BGP em Mikrotik – Parte II
  4. BGP em Mikrotik – Parte III
  5. BGP no Mikrotik (IV): Anúncios e rotas no FFE
  6. BGP no Mikrotik (V): Analisando anúncios de implementações de BGP
  7. BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup
  8. BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
  9. BGP no Mikrotik (VIII): Alterando a política de roteamento
  10. BGP no Mikrotik (IX): Filtros
  11. Atributos do BGP
  12. BGP: Tabelas de roteamento
  13. Convergência, no BGP
  14. A Seta IPv6: Preparando para trabalhar com IPv6 no Mikrotik
  15. Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)
  16. BGP: topologias, abstrações, eBGP e iBGP (Parte 1)

 

Referências

  1. Russ White, Danny McPherson, Srihari Sangli. Practical BGP. Pearson Education, Inc. 2005.
  2. VMware Virtual Networking Concepts. Disponível em: http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf. Acessado em 19/08/2011 10:28.
  3. Cisco. BGP Attributes and Policy Control. ISP/IXP Workshops Disponível em: http://www.pacnog.org/pacnog2/track2/routing/b1-1up.pdf. Acessado em 21/08/2011 11:50.
  4. Jeff Doyle. Protecting Your Network Edge with TTL Security. Disponível em: http://www.networkworld.com/community/node/18760. Acessado em 21/08/2011 16:43.
  5. Team Cymru. Disponível em: http://www.team-cymru.org/. Acessado em 21/08/2011 16:43.
Categorias:BGP, Loopback, Mikrotik, TCP/IP

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
%d blogueiros gostam disto: