Início
Introdução
Dividiremos esse assunto em diversas partes. Antes das próximas partes será necessário falar sobre outros recursos do BGP. Por exemplo, na Parte III falaremos sobre Filtros em BGP. Não seria oportuno falar sobre filtros, sem antes abordar Comunidades em BGP. O foco da Parte I e a II é a implementação do BGP em Mikrotik. Ela pretende facilitar a implementação do BGP e para isso iremos trabalhar com uma topologia que irá 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 => Laborátório Virtual de Roteamento, apresentado há algum tempo aqui nesse blogue. Nosso exemplo supõe que há um fornecedor de trânsito, o MK1 ou AS65531 (representado na Figura 1), que é detentor de um bom pedaço do bloco 10.0.0.0/8 (bloco prefereido do FFE). Inicialmente ele é, unicamente, fornecedor de tráfego de trânsito. Nos outros textos que seguirão, o MK1 ou outro membro qualquer do FFE será fornecedor de tráfego de transporte. Na oportunidade, iremos acrescentar PTTs, que irão fornecer tráfego de “peering” e acordos multilaterais/bilaterais, também. O que será útil para ampliarmos as perspectivas do protocolo BGP.
O MK2 (AS65532) está interessado em trânsito e combina as condições comerciais com MK1. 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
Para nossa informação, 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 as informações, o próximo passo é ajustar os dados em Routing, BGP, Instance, como mostra a Figura 3, para o MK1 e MK2. Alteramos AS e Router ID, nos respectivos roteadores.
As escolhas do Router ID, também são arbritrárias. O usual é usar um dos IPs do MK em questão, como por exemplo, o IP da interface que está dando origem ao BGP. O próximo passo está na Figura 4, que exibe as modificações feitas. Tais modificações foram:
Ao dar OK, o BGP imediatamente se relaciona entre os dois pares e resulta 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, se formos em New Terminal, eis o resultado que encontramos em dois comandos importantes, que nos diz o quê o MK1 está anunciando e o quê ele está recebendo de MK2:
O mesmo pode ser feito no MK2. Vejamos abaixo:
Com os testes acima podemos afirmar que o BGP entre MK1 e MK2 está funcionando. Uma dúvida entrentanto, surge quando olhamos os anúncios que chegam de MK1 para MK2. Onde estão os anúncios das rotas da Internet? Ah! Bem lembrado. Por enquanto iremos justificar que a ausência delas está associada ao fato de que o FFE é experimental. Ele NÃO está na Internet! Por isso deixaremos para falar de 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 com MK2 ficou sabendo que MK2 já estava na Internet. Então, o MK3 informa ao MK2 que seria mais fácil ele comprar trânsito do MK2. E se entendem no sentido de decidir. MK3, também é um AS. Seu ASN é o 65533 e possui o bloco 10.203.0.0/23. Após essa decisão do MK3, o FFE fica com a seguinte topologia, mostrada na Figura 7, abaixo.
Vejam que MK2 forneceu o bloco 10.202.0.4/30, para efetivar a conexão. O esquema é o mesmo que foi feito no MK1 e MK2. Eis as etapas, para lembrarmos:
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. Vejamos os testes, via o Terminal do MK para cada um deles.
Abaixo, os testes para o MK3. Veja o que ele anuncia para MK3 e o que recebe do MK3:
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:
Agora, os testes para o MK1. Veja que ele está recebendo o bloco do MK3
Epílogo da Parte I
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 nas próximas partes do assunto. Entretanto, o autor não sente 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. Provavelmente forçados pelos pecados da nossa economia de mercado. Ahn!
A referência [1] é uma ótima leitura para o que virá, apesar de ser um documento da Cisco. Na Internet, em uma guglada encontraremos muita informação. Boa e ruim. Naturalmente, as questões postas pelos leitores podem ajudar nas atualizações dessa parte e ajudará muito durante o desenvolvimento das outras partes do assunto.
Finalmente, o autor não acha o BGP seja 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.
Fonte: http://juliaobraga.wordpress.com/2011/03/07/bgp-em-mikrotik-parte-i/
Dividiremos esse assunto em diversas partes. Antes das próximas partes será necessário falar sobre outros recursos do BGP. Por exemplo, na Parte III falaremos sobre Filtros em BGP. Não seria oportuno falar sobre filtros, sem antes abordar Comunidades em BGP. O foco da Parte I e a II é a implementação do BGP em Mikrotik. Ela pretende facilitar a implementação do BGP e para isso iremos trabalhar com uma topologia que irá 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 => Laborátório Virtual de Roteamento, apresentado há algum tempo aqui nesse blogue. Nosso exemplo supõe que há um fornecedor de trânsito, o MK1 ou AS65531 (representado na Figura 1), que é detentor de um bom pedaço do bloco 10.0.0.0/8 (bloco prefereido do FFE). Inicialmente ele é, unicamente, fornecedor de tráfego de trânsito. Nos outros textos que seguirão, o MK1 ou outro membro qualquer do FFE será fornecedor de tráfego de transporte. Na oportunidade, iremos acrescentar PTTs, que irão fornecer tráfego de “peering” e acordos multilaterais/bilaterais, também. O que será útil para ampliarmos as perspectivas do protocolo BGP.
O MK2 (AS65532) está interessado em trânsito e combina as condições comerciais com MK1. 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
Para nossa informação, 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 as informações, o próximo passo é ajustar os dados em Routing, BGP, Instance, como mostra a Figura 3, para o MK1 e MK2. Alteramos AS e Router ID, nos respectivos roteadores.
As escolhas do Router ID, também são arbritrárias. O usual é usar um dos IPs do MK em questão, como por exemplo, o IP da interface que está dando origem ao BGP. 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 dar OK, o BGP imediatamente se relaciona entre os dois pares e resulta 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, se formos em New Terminal, eis o resultado que encontramos em dois comandos importantes, que nos diz o quê o MK1 está anunciando e o quê ele está recebendo de MK2:
- Código:
[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:
- Código:
[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 podemos afirmar que o BGP entre MK1 e MK2 está funcionando. Uma dúvida entrentanto, surge quando olhamos os anúncios que chegam de MK1 para MK2. Onde estão os anúncios das rotas da Internet? Ah! Bem lembrado. Por enquanto iremos justificar que a ausência delas está associada ao fato de que o FFE é experimental. Ele NÃO está na Internet! Por isso deixaremos para falar de 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 com MK2 ficou sabendo que MK2 já estava na Internet. Então, o MK3 informa ao MK2 que seria mais fácil ele comprar trânsito do MK2. E se entendem no sentido de decidir. MK3, também é um AS. Seu ASN é o 65533 e possui o bloco 10.203.0.0/23. Após essa decisão do MK3, o FFE fica com a seguinte topologia, mostrada na Figura 7, abaixo.
Vejam que MK2 forneceu o bloco 10.202.0.4/30, para efetivar a conexão. O esquema é o mesmo que foi feito no MK1 e MK2. Eis as etapas, para lembrarmos:
- 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. MK2 não faz isso porque já fez!
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. Vejamos os testes, via o Terminal do MK para cada um deles.
Abaixo, os testes para o MK3. Veja o que ele anuncia para MK3 e o que recebe do MK3:
- Código:
[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:
- Código:
[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
- Código:
[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
Epílogo da Parte I
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 nas próximas partes do assunto. Entretanto, o autor não sente 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. Provavelmente forçados pelos pecados da nossa economia de mercado. Ahn!
A referência [1] é uma ótima leitura para o que virá, apesar de ser um documento da Cisco. Na Internet, em uma guglada encontraremos muita informação. Boa e ruim. Naturalmente, as questões postas pelos leitores podem ajudar nas atualizações dessa parte e ajudará muito durante o desenvolvimento das outras partes do assunto.
Finalmente, o autor não acha o BGP seja 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.
Fonte: http://juliaobraga.wordpress.com/2011/03/07/bgp-em-mikrotik-parte-i/
