Início > BGP, Mikrotik, TCP/IP > BGP em Mikrotik – Parte I

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
  1. 23/09/2011 às 17:56

    Amigo… tenho um micro provedor de acesso a Internet e estou muito agradecido em ler os seus artigos. São de uma clareza absurda! Fantástica a forma e o conteúdo do seu texto.

    Muito Bom.

    Sds,

    Roralberto Evangelista da Silva.

    • juliaobraga
      23/09/2011 às 22:35

      Obrigado, Roralberto.

      []s, Julião

  2. 19/11/2011 às 16:38

    Boa tarde !

    Muito Obrigado Julio, excelente material, de muita qualidade e bem esclarecedor !
    Estou iniciando com BGP e estou me baseando 100% em seu material em meu laboratório !

    Surgiu uma duvida, Possuo 2 link’s de 100Mbit de dois AS diferente, chegando em meu provedor, meu AS está para sair e irei começar com o tão falado BGP, a duvida é a seguinte, o BGP irá somar meus 2 links ? ou usar só como contingência ?

    Obrigado

    • juliaobraga
      19/11/2011 às 17:19

      Olá Alan,

      O BGP não possui recursos para balanceamento. Contingência ou backup é o foco dele. Embora seja possível anúncios de prefixos diferentes de seu bloco haverá dificuldades quando um dos enlaces ficar indisponível, perdendo o melhor do BGP que seria transferir, automaticamente, o trânsito para o enlace ativo. Este é o propósito do BGP. Balanceamento ou divisão do tráfego deve ser feito através de marcação de pacotes. Isto exige um planejamento e alguma experiência. Nada impossível, entretanto. Implemente o BGP e passe a exercitar com as facilidades adicionais que todo roteador possui. No início irá ficar ansioso por conta da lógica perversa de que nosso cérebro possui uma enorme dificuldade em questões que ainda não lidamos, mas é assim mesmo. Não tem outro jeito. Ou pede ajuda de alguém que tenha bastante experiência ou aprende, você mesmo (melhor alternativa!).

      []s, Julião

  3. 20/11/2011 às 00:27

    Obrigado pela dica Juliao !!

    Hoje ja trabalho com balanceamento de link com o PCC do mikrotik, mas apenas com Nat, vou tentar trabalhar com ele em modo bridge e repassar os ip’s, ai posteriormente tentarei implantar o bgp nesse equipamento hehe

    Obrigado, bom agora acho que é comigo né .. vou estudar !! bom fds

  4. 23/11/2011 às 19:24

    Boa noite Juliao, eu denovo hehe

    Qual o link no teu blog sobre LVR FEE, nao encontrei, obrigado

    • juliaobraga
      25/11/2011 às 13:25

      Olá Alan,

      O sítio do FEE (antigo LVR), ainda não está operacional. Estamos dependendo do tempo… Assim que estiver pronto divulgaremos no blogue.

      Obrigado e []s,

      Julião

  5. 29/02/2012 às 09:52

    Bom dia Juliao.

    Seguinte, estudei o bgp etc.. e estou colocando em pratica, fui colocar em produção o equipamento e gerou um problema, eu vou receber a full routing table do meu provedor de transito, pois tenho 2 links e não tem como eu ficar com parcial routing table, mas a RB que possuo acho que não tem memoria suficiente para isto.
    Você saberia me informar qual o tamanho da full routing table ? ou recomendar um RB que possa fazer isto,

    Obs, hoje uso uma rb 750 com 32mb de memoria interna.

    Obrigado

    • juliaobraga
      29/02/2012 às 16:56

      Um bom lugar para você ver os tamanhos das tabelas é no Potaroo, IPv4 e IPv6 => clique nos ASes que aparecem. Já tive “full route” em uma RB1000. Estou instalando uma RB750 por estes dias para ver se ela aguenta. As bandas dos enlaces irão influenciar, mais do que a tabela de rotas. Verifique a possibilidade de usar o Mikrotik em uma máquina e não em uma RB. Talvez seja o melhor, para seu cenário.

  6. 29/02/2012 às 17:10

    Pois é, estou comprando um RB 1200 já. pedi Hoje. vamos ver

    Obrigado

    • juliaobraga
      29/02/2012 às 19:18

      Temos uma RB1100 e chegamos à conclusão que ela não se aproxima da RB1000 (esta, bem melhor). Muitos conhecidos tem importado soluções customizadas. Irei confirmar, uma destas soluções e informarei aqui, amanhã.

  7. 01/03/2012 às 07:04

    Bom dia Juliao.

    Fazendo uns testes com a RB aqui e conversando com amigos que trabalham com Cisco, me indicaram para não trabalhar com full routing , ou ao menos , não preciso disto, pelas coisas que irei fazer.

    Me informaram que é usual no cisco utilizarem partial routing, e limitar para ele receber 0.0.0.0/18 .
    Fiquei meio “boiando” , pois não sei onde defino estas opções no mikrotik, você saberia me informar ?
    onde defino partial routing , ou faço o filtro para este /18 ?

    Obrigado

    • juliaobraga
      01/03/2012 às 10:45

      Bom dia Alan.

      Você pode controlar/filtrar as rotas de entrada do operador de trânsito em questão usando o BGP AS Path Lenght (Routing => Filter (Add) => BGP), em um filtro de entrada. Com isto você decide o tamanho da tabela de rotas (em tese). Experimente “0-1”, veja o que recebe. Depois “0-2” e assim por diante. “0-3” eu usava em um trânsito que tinha na borda do PTT-SP.

  8. 05/03/2012 às 18:42

    Estranho Julio, fiz o filtro, e mesmo assim no Prefix Count no Bgp, continua recebendo 390 mil … não era para ter diminuído ? estou usando 0-1

    • juliaobraga
      06/03/2012 às 09:58

      É estranho. Difícil avaliar, entretanto, sem uma avaliação/visão das configurações globais. Você tem de continuar pesquisando.

  9. stribus
    21/03/2013 às 18:24

    tenho 2 redes diferentes(192.168.2.0/24 e 192.168.1.0/24) interconectadas com o MK e gostaria que seus computadores se comunicassem sem nat. saberia me dizer como faço isso? ou onde consigo como fazer?

    • juliaobraga
      21/03/2013 às 18:50

      Rota estática. Um MK roteia sua rede para o outro e vice-versa. NAT só para a Internet.

  10. 06/08/2015 às 11:18

    Olá, gostaria de tirar uma dúvida, estando em um cenário, onde se tem 1 Link dedicado, onde, e 2 Links VDSL, com PCC Mikrotik, fazendo NAT para baixo, para um autenticador PPPOE, digamos que vai ser utilizado essa operadora do link dedicado para transportar o AS, seria obrigado tirar este link fora do PCC, pois acredito que sete cenário é da grande maioria dos provedores. OBrigado desde já.

  1. 08/08/2011 às 16:36
  2. 21/08/2011 às 17:47
  3. 05/09/2012 às 09:47

Deixe uma resposta

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s