Arquivo

Archive for 07/03/2011

BGP em Mikrotik – Parte I

The best way to have a good idea is to have lots of ideas.
Linus Pauling

Atualizado em 17/07/2011

Introdução

 

Este assunto será dividido em várias partes. Antes das próximas partes será necessário falar sobre outros recursos do BGP. Por exemplo, na Parte III a abordagem é sobre Filtros em BGP. Não seria oportuno falar sobre filtros, sem antes apresentar Comunidades em BGP. O foco, tanto da Parte I como da Parte II é a implementação do BGP em Mikrotik. Ela pretende facilitar a implementação do BGP e para isto será usada uma topologia que evoluirá do simples, para o complexo.

A topologia será construida sobre o FFE. Para quem não se lembra, FFE = [1111 1111 1110] => Fábrica Fictícia de Encaminhamento ~ LVR => Laboratório Virtual de Roteamento, apresentado há algum tempo aqui nesse blogue. O modelo supõe a existência de um fornecedor de trânsito (operadora), o MK1 ou AS65531 (representado na Figura 1), que se supõe seja detentor de um bom pedaço do bloco 10.0.0.0/8 (bloco preferido do FFE). Nos outros textos que seguirão, o MK1 ou outro membro qualquer do FFE será fornecedor de tráfego de transporte. Oportunamente serão acrescentaados PTTs, que irão fornecer tráfego de “peering” em acordos multilaterais, e tráfego de trânsito, ou outro qualquer, em acordos bilaterais. O que será útil para ampliar a perspectiva, ou aplicabilidade, do protocolo BGP.

 

Figura 1: O ávido fornecedor de trânsito.

 

Adicionando o MK2 no FFE

 

O MK2 (AS65532) está interessado em trânsito e combina as condições comerciais com MK1. Via de regra isto é feito juntamente com um formulário padrão que o MK1 envia ao MK2, para ser preenchido. Negócio fechado, MK1 reserva o bloco 10.201.0.4/30 para a interconexão com o MK2, cujas interfaces estão ilustradas na Figura 2, abaixo.

 

Figura 2: Ilustração do esquema atual de trânsito do MK1.

 

Preparando o MK1 para o MK2 e vice versa

 

O MK2 ou AS65532 é detentor (escolha arbitrária!), do bloco 10.202.0.0/23, que pode ser dividido nos dois blocos 10.202.0.0/24 e 10.202.1.0/24. Tendo tais informações, o próximo passo é ajustar os dados em Routing, BGP, Instance, como mostra a Figura 3, para o MK1 e MK2. Altera-se o AS e Router ID, nos respectivos roteadores.

 

Figura 3: Ajustando a instância em cada um dos pares (MK1 e MK2).

 

As escolhas do Router ID, também são arbitrárias. É comum usar um dos IPs das interfaces do respectivo MK em questão, como por exemplo, o IP da interface que está dando origem ao BGP. Preferencialmente, entretanto, a escolha deve ser um IP de interface, que seja parte do bloco do respectivo AS. O próximo passo está na Figura 4, que exibe as modificações feitas. Tais modificações foram:

 

  • Name: Identificamos o par remoto do BGP (arbitrário).
  • Remote Address: O IP do par remoto. No caso, os IPs das respectivas interfaces, provenientes do bloco separado pelo MK1.
  • Remote AS: O ASN (ou número do AS) do respectivo par remoto.

 

Figura 4: Implementando o BGP entre MK1 e MK2.

 

Ao clicar em OK, o BGP dos pares começam a ser relacionar resultando no estado established.

 

Figura 5: BGP funcionando entre o MK1 e MK2.

 

Nesse momento, sabemos que há um relacionamento entre MK1 e MK2 através do protocolo BGP. Mas está faltando a informação sobre quem deve anunciar o quê. O MK1 é o trânsito, logo ele deve anunciar para MK2, toda a tabela de rotas da Internet, mais o bloco de IPs que ela detem. O MK2 deve anunciar para MK1 os blocos IPs que ela detem, para que o MK1 repasse para a Internet e a Internet saiba qual o caminho que deve seguir para chegar até MK2. Vejamos como resolver o problema do lado do MK2. Anunciamos o bloco de MK2 colocando, ainda em BGP, Network, o bloco desejado. A Figura 6 mostra como fazemos isso no MK2 e como fazemos o mesmo para que MK1 anuncie seus blocos para MK2 (que é da mesma maneira).

 

Figura 6: Anunciando respectivos blocos entre os membros (MK1 e MK2) do empareamento BGP.

 

No MK1, em New Terminal, eis o resultado de dois comandos importantes, que diz o quê o MK1 está anunciando e o quê ele está recebendo do MK2:

 

[admin@MK1] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH    ORIGIN     LOCAL-PREF
MK2      10.201.0.0/23        10.201.0.5                  igp 
      
[admin@MK1] > ip route print where received-from=MK2
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.202.0.0/23                      10.201.0.6         20      

 

O mesmo pode ser feito no MK2. Vejamos abaixo:

[admin@MK2] > routing bgp advertisements print      
PEER     PREFIX               NEXTHOP          AS-PATH    ORIGIN     LOCAL-PREF
MK1      10.202.0.0/23        10.201.0.6                  igp 
      
[admin@MK2] > ip route print where received-from=MK1 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.201.0.5         20      

 

Com os testes acima pode-se afirmar que o BGP entre MK1 e MK2 está funcionando, adequadamente. Uma dúvida entretanto surge, quando se observa os anúncios que chegam do MK1 para MK2. Onde estão os anúncios das rotas da Internet? Ah! Bem lembrado. Por enquanto justifica-se que a ausência delas está associada ao fato de que o FFE é experimental. Ele NÃO está na Internet! Por isso, o que pode ser dito é que o anúncios de tabelas de rotas da Internet, um pouco mais pela frente. Por hora basta acreditar que o MK1 anuncia tudo o que ele recebe, para o MK2.

 

Adicionando o MK3 no FFE

 

O MK3, que já possui uma conexão experimental, estática, com MK2 ficou sabendo que MK2 já estava na Internet. Então, o MK3 pede ao MK2 que lhe venda trânsito. E se entendem neste sentido. MK3, também é um AS. Seu ASN é o 65533 e possui o bloco 10.203.0.0/23. Assim, o FFE fica como a topologia, mostrada na Figura 7.

 

Figura 7: Entrada do MK3 na Internet via trânsito oferecido pelo MK2.

 

Vejam que MK2 forneceu o bloco 10.202.0.4/30, para efetivar a conexão. O esquema é o mesmo que foi implementado no MK1 e MK2. Eis as etapas:

 

  • MK2 inclui um Peer, com o ASN de MK3 e o IP remoto 10.202.0.6/30.
  • MK3 inclui um Peer com o ASN de MK2 e o IP remoto 10.202.0.5/30.
  • MK3 inclui seu bloco em Network, o que já tinha feito!

 

Pronto! MK3 está na Internet via MK2 que tem trânsito via MK1. Os respectivos blocos estão sendo anunciados. O que MK2 recebe de anúncio do MK3, passo diretamente para MK1. Pode-se ver isto, através do Terminal, para cada um deles.

Abaixo, os testes para o MK3. Veja o que ele anuncia para MK3 e o que recebe do MK3:

 

[admin@MK3] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH    ORIGIN     LOCAL-PREF
MK2      10.203.0.0/23        10.202.0.6                  igp
       
[admin@MK3] > ip route print where received-from=MK2
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.202.0.5         20      
 1 ADb  10.202.0.0/23                      10.202.0.5         20      

 

A seguir, os testes para o MK2. Ele tem duas conexões. Não há nenhuma restrição (aka, filtro) que impeça ele anunciar tudo que recebe para o MK1:

 

[admin@MK2] > routing bgp advertisements print      
PEER     PREFIX               NEXTHOP          AS-PATH    ORIGIN     LOCAL-PREF
MK1      10.203.0.0/23        10.201.0.6       65533      igp       
MK1      10.202.0.0/23        10.201.0.6                  igp       
MK3    10.201.0.0/23        10.202.0.5       65531      igp       
MK3    10.202.0.0/23        10.202.0.5                  igp 
      
[admin@MK2] > ip route print where received-from=MK3
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.203.0.0/23                      10.202.0.6         20   
   
[admin@MK2] > ip route print where received-from=MK1
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 1 ADb  10.201.0.0/23                      10.201.0.5         20      

 

Agora, os testes para o MK1. Veja que ele está recebendo o bloco do MK3

 

[admin@MK1] > routing bgp advertisements print      
PEER     PREFIX               NEXTHOP          AS-PATH                          ORIGIN     LOCAL-PRE
MK2      10.201.0.0/23        10.201.0.5                                        igp 
      
[admin@MK1] > ip route print where received-from=MK2
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.202.0.0/23                      10.201.0.6         20      
 1 ADb  10.203.0.0/23                      10.201.0.6         20       

 

Observações complementares

 

Há algumas questões que devem ser levantadas. Por exemplo, não usamos rota default, em nenhum momento. Insistentemente e, para efeitos didáticos, não usamos e nem falamos sobre filtros, o que nos induz a imaginar a necessidade de não colocar as implementações acima em produção, sem que se tenha o conhecimento adequado. Contudo, em uma implementação com um só operador de trânsito, isso não importará muito e não precismos ter medo de implementá-las. BGP é um protocolo muito poderoso e versátil. Foi feito para relacionar com pelo menos com um vizinho. A exigência de se dar um AS para somente quem tem no mínimo duas conexões de trânsito com operadoras diferentes, não tem nada a ver com BGP.

Todos os MKs do FFE estão com a versão R5.0rc10. Candidatos ao release 5, antereriores ao rc10, não funcionam. A razão de estar usando essa versão é pela necessidade de usar o IPv6 nos próximos textos. Entretanto, não se pode sentir firmeza com o Mikrotik, infelizmente. O que ele tem de bom nas facilidades tem de mau na confiabilidade. Mas não há dúvida que o Mikrotik, como roteador é a grande vedete brasileira. Provavelmente, os brasileiros são mais corajosos do que o resto do mundo. Talvez forçados pelas restrições ou imposições oficiais sobre nosso mercado. Ahn!

A referência [1] é uma ótima leitura para o que virá, apesar de ser um documento da Cisco. Na Internet, encontra-se muita informação. Boa e ruim. Naturalmente, as questões postas pelos leitores podem ajudar nas atualizações dessa parte e auxiliará em muito durante o desenvolvimento das outras partes do assunto.

Finalmente, nota-se que o BGP não um protocolo fácil, no conjunto de todos seus recursos e na diversidade das topologias encontradas na Internet. BGP é difícil e dá trabalho para manter. Exige estudo intensivo e aprendizagem constante. Ele é um protocolo mais propício a mudanças do que uma lingua natural, como o Português.

 

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. Cisco, BGP Case Studies. Disponível aqui: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#BGPloopbackinter. Acessado em 07/03/2011.
Categorias:BGP, Mikrotik, TCP/IP