como sendo os limites do mundo.
Arthur Schopenhauer
Introdução
Nesse momento, estamos com o FFE completo. Usando o mesmo esquema do artigo anterior, podemos imaginar que seja fácil implementar a topologia, da Figura 1, abaixo, em BGP. O mesmo padrão de distribuição dos blocos IPs continua aqui. MK4 compra trânsito de MK1, também. MK5 negocia trânsito via MK4. MK6 via MK5 e MK7 via MK6.
Analisando a topologia da Figura 1
Vejamos cada um dos MKs sob o pondo de vista de anúncios e recebimentos de rotas (i.e., a tabela de rotas de cada MK).
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
[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
2 ADb 10.204.0.0/23 10.202.0.5 20
3 ADb 10.205.0.0/23 10.202.0.5 20
4 ADb 10.206.0.0/23 10.202.0.5 20
5 ADb 10.207.0.0/23 10.202.0.5 20
Para ficar mais claro, a leitura, retiramos algumas linhas do Flags. MK3 está anunciando seu bloco, para o MK2. MK3 está recebendo os anúncios dos blocos de MK1, MK2, MK4, MK5, MK6 e MK7. Obedientemente, não recebe o seu próprio bloco! Vale lembrar, nesse ponto, de que não estamos usando filtros ou firewall.
MK2
MK2 recebe o anuncio de MK3 e envia para MK1. Recebe de MK1 todos os anúncios dos membros ativos do FFE, exceto seu próprio anúncio.
[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=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
2 ADb 10.204.0.0/23 10.201.0.5 20
3 ADb 10.205.0.0/23 10.201.0.5 20
4 ADb 10.206.0.0/23 10.201.0.5 20
5 ADb 10.207.0.0/23 10.201.0.5 20
MK7
MK7 recebe os anúncios de todos os membros do FFE, exceto o dele.
[admin@MK7] > routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PRE
MK6 10.207.0.0/23 10.206.0.30 igp
[admin@MK7] > ip route print where received-from=MK6
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 10.201.0.0/23 10.206.0.29 20
1 ADb 10.202.0.0/23 10.206.0.29 20
2 ADb 10.203.0.0/23 10.206.0.29 20
3 ADb 10.204.0.0/23 10.206.0.29 20
4 ADb 10.205.0.0/23 10.206.0.29 20
5 ADb 10.206.0.0/23 10.206.0.29 20
Há um teste mais efetivo para confirmar a existência da conectividade. O ping. Vamos criar uma interface Loopback no MK7 e pingar essa interface, do MK3 (o mais distante membro do MK7. No Mikrotik, para criar uma interface de Loopback, primeiro criamos uma Bridge e depois associamos um endereço a essa Bridge. Os passos estão mostrados na Figura 2, abaixo.
Criada a interface, vamos no MK3 para dar um ping na Loopback do MK7. O resultado está ilustrado na Figura 3.
Onde houver acessibilidade podemos implementar o BGP. Acessibilidade é um termo mais amplo do que conectividade. Conectividade implica acessibilidade local. Fixar essa idéia em nossa mente é importante para lidar com o BGP e para o que virá na Parte III.
MK6
O importante é observar os anúncios enviados e recebidos do MK6.
[admin@MK6] > routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PR
MK5 10.207.0.0/23 10.205.0.26 65537 igp
MK5 10.206.0.0/23 10.205.0.26 igp
MK7 10.202.0.0/23 10.206.0.29 65535,65534,65531,65532 igp
MK7 10.204.0.0/23 10.206.0.29 65535,65534 igp
MK7 10.203.0.0/23 10.206.0.29 65535,65534,65531,65532,65533 igp
MK7 10.205.0.0/23 10.206.0.29 65535 igp
MK7 10.201.0.0/23 10.206.0.29 65535,65534,65531 igp
MK7 10.206.0.0/23 10.206.0.29 igp
[admin@MK6] > ip route print where received-from=MK7
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 10.207.0.0/23 10.206.0.30 20
[admin@MK6] > ip route print where received-from=MK5
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
1 ADb 10.201.0.0/23 10.205.0.25 20
2 ADb 10.202.0.0/23 10.205.0.25 20
3 ADb 10.203.0.0/23 10.205.0.25 20
4 ADb 10.204.0.0/23 10.205.0.25 20
5 ADb 10.205.0.0/23 10.205.0.25 20
Para ilustrar, vamos supor que MK6 tenha recebido um novo bloco /23. Digamos o bloco 10.226.0.0/23. Se MK6 deseja anunciar esse bloco, então ele coloca-o em Networks, como ilustra a Figura 4, que segue.
Repetindo as pesquisas via o Terminal verifica-se de que houve mudanças, assim como em todos os outros membros do FFE. Tais mudanças não são exibidas nos exemplos do MK5, MK4 e MK1 que seguem.
[admin@MK6] > routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
MK5 10.207.0.0/23 10.205.0.26 65537 igp
MK5 10.206.0.0/23 10.205.0.26 igp
MK5 10.226.0.0/23 10.205.0.26 igp
MK7 10.203.0.0/23 10.206.0.29 65535,655... igp
MK7 10.205.0.0/23 10.206.0.29 65535 igp
MK7 10.202.0.0/23 10.206.0.29 65535,655... igp
MK7 10.204.0.0/23 10.206.0.29 65535,65534 igp
MK7 10.201.0.0/23 10.206.0.29 65535,655... igp
MK7 10.206.0.0/23 10.206.0.29 igp
MK7 10.226.0.0/23 10.206.0.29 igp
[admin@MK6] > ip route print where received-from=MK5
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 10.201.0.0/23 10.205.0.25 20
1 ADb 10.202.0.0/23 10.205.0.25 20
2 ADb 10.203.0.0/23 10.205.0.25 20
3 ADb 10.204.0.0/23 10.205.0.25 20
4 ADb 10.205.0.0/23 10.205.0.25 20
[admin@MK6] > ip route print where received-from=MK7
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
5 ADb 10.207.0.0/23 10.206.0.30 20
MK5
No MK5 a observação é ficar atendo aos anúncios que chegam e que saem. O novo bloco do MK6. não está presente.
[admin@MK5] > routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
MK4 10.207.0.0/23 10.204.0.22 65536,65537 igp
MK4 10.206.0.0/23 10.204.0.22 65536 igp
MK4 10.205.0.0/23 10.204.0.22 igp
MK6 10.201.0.0/23 10.205.0.25 65534,65531 igp
MK6 10.204.0.0/23 10.205.0.25 65534 igp
MK6 10.203.0.0/23 10.205.0.25 65534,65531,65532,65533 igp
MK6 10.202.0.0/23 10.205.0.25 65534,65531,65532 igp
MK6 10.205.0.0/23 10.205.0.25 igp
[admin@MK5] > ip route print where received-from=MK6
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 10.206.0.0/23 10.205.0.26 20
1 ADb 10.207.0.0/23 10.205.0.26 20
[admin@MK5] > ip route print where received-from=MK4
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
2 ADb 10.201.0.0/23 10.204.0.21 20
3 ADb 10.202.0.0/23 10.204.0.21 20
4 ADb 10.203.0.0/23 10.204.0.21 20
5 ADb 10.204.0.0/23 10.204.0.21 20
MK4
Importante notar que o novo bloco do MK6. não está presente. O teste foi feito antes da aquisição do MK6.
[admin@MK4] > routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
MK1 10.206.0.0/23 10.201.0.18 65535,65536 igp
MK1 10.205.0.0/23 10.201.0.18 65535 igp
MK1 10.207.0.0/23 10.201.0.18 65535,65536,65537 igp
MK1 10.204.0.0/23 10.201.0.18 igp
MK5 10.201.0.0/23 10.204.0.21 65531 igp
MK5 10.202.0.0/23 10.204.0.21 65531,65532 igp
MK5 10.203.0.0/23 10.204.0.21 65531,65532,65533 igp
MK5 10.204.0.0/23 10.204.0.21 igp
[admin@MK4] > ip route print where received-from=MK5
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
0 ADb 10.205.0.0/23 10.204.0.22 20
1 ADb 10.206.0.0/23 10.204.0.22 20
2 ADb 10.207.0.0/23 10.204.0.22 20
[admin@MK4] > ip route print where received-from=MK1
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
3 ADb 10.201.0.0/23 10.201.0.17 20
4 ADb 10.202.0.0/23 10.201.0.17 20
5 ADb 10.203.0.0/23 10.201.0.17 20
MK1
O MK1 é o operador de trânsito, propriamente dito. Assim, tudo chega nele e del devem partir os anúnicos para a Internet. Assim, todos os membros do FFE ficarão visíveis.
[admin@MK1] > routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
MK2 10.207.0.0/23 10.201.0.5 65534,65535,65536,65537 igp
MK2 10.204.0.0/23 10.201.0.5 65534 igp
MK2 10.206.0.0/23 10.201.0.5 65534,65535,65536 igp
MK2 10.205.0.0/23 10.201.0.5 65534,65535 igp
MK2 10.201.0.0/23 10.201.0.5 igp
MK4 10.203.0.0/23 10.201.0.17 65532,65533 igp
MK4 10.202.0.0/23 10.201.0.17 65532 igp
MK4 10.201.0.0/23 10.201.0.17 igp
[admin@MK1] > ip route print where received-from=MK4
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE
2 ADb 10.204.0.0/23 10.201.0.18 20
3 ADb 10.205.0.0/23 10.201.0.18 20
4 ADb 10.206.0.0/23 10.201.0.18 20
5 ADb 10.207.0.0/23 10.201.0.18 20
[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 II
Na versão V5.0rc10, um comportamento estranho ocorreu após a inclusão dos parâmetros no MK2. Isso pode ser visto abaixo, nas seis últimas linhas:
[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
peer1 10.201.0.0/23 10.202.0.5 65531 igp
peer1 10.206.0.0/23 10.202.0.5 65531,65534,65535,65536 igp
peer1 10.204.0.0/23 10.202.0.5 65531,65534 igp
peer1 10.207.0.0/23 10.202.0.5 65531,65534,65535,65536,65537 igp
peer1 10.205.0.0/23 10.202.0.5 65531,65534,65535 igp
peer1 10.202.0.0/23 10.202.0.5 igp
O resultado do comando mudou, após um reboot. Pouco tempo depois, a versão foi atualizada para o rc11.
[...] BGP em Mikrotik – Parte II [...]
Pingback por BGP no Mikrotik: Dois operadores de trânsito « Infraestrutura da Internet — 08/08/2011 @ 16:36
[...] BGP em Mikrotik – Parte II [...]
Pingback por BGP no Mikrotik: Dois operadores de trânsito (Visão genérica) « Infraestrutura da Internet — 21/08/2011 @ 17:47