BGP em Mikrotik – Parte I
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.
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.
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.
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.
Ao clicar em OK, o BGP dos pares começam a ser relacionar resultando no estado established.
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).
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.
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
- BGP no Mikrotik: Dois operadores de trânsito. Versão anterior a este artigo.
- BGP em Mikrotik – Parte I
- BGP em Mikrotik – Parte II
- BGP em Mikrotik – Parte III
- BGP no Mikrotik (IV): Anúncios e rotas no FFE
- BGP no Mikrotik (V): Analisando anúncios de implementações de BGP
- BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup
- BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
- BGP no Mikrotik (VIII): Alterando a política de roteamento
- BGP no Mikrotik (IX): Filtros
- Atributos do BGP
- BGP: Tabelas de roteamento
- Convergência, no BGP
- A Seta IPv6: Preparando para trabalhar com IPv6 no Mikrotik
- Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)
- BGP: topologias, abstrações, eBGP e iBGP (Parte 1)
Referências
- 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.
| Follow @juliaobraga |
Infraestrutura da Internet 
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.
Obrigado, Roralberto.
[]s, Julião
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
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
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
Boa noite Juliao, eu denovo hehe
Qual o link no teu blog sobre LVR FEE, nao encontrei, obrigado
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
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
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.
Pois é, estou comprando um RB 1200 já. pedi Hoje. vamos ver
Obrigado
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ã.
Eis o detalhamento de um equipamento com boas referências práticas:
http://www.balticnetworks.com/routermaxx-6-port-gigabit-router-dual-core.html
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
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.
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
É estranho. Difícil avaliar, entretanto, sem uma avaliação/visão das configurações globais. Você tem de continuar pesquisando.
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?
Rota estática. Um MK roteia sua rede para o outro e vice-versa. NAT só para a Internet.
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á.
Despõem desse material em PDF?
Olá Victor. Não está disponível em PDF.
Material incrível, claro e esclarecedor. Parabéns.
Obrigado, Bruno!
Excelente post! Muitíssimo detalhado, diferente de tudo que encontrei na internet. Muito obrigado.
Obrigado, Cleber, pelo seu agradável comentário.