Arquivo

Archive for agosto \21\-03:00 2011

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

21/08/2011 6 comentários

“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