BGP em Mikrotik – Parte II
como sendo os limites do mundo.
Arthur Schopenhauer
Introdução
Nesse momento, o FFE completo. Usando o mesmo esquema do artigo anterior, pode-se 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 se usa 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 cria-se uma Bridge e depois associa-se um endereço a essa Bridge. Os passos estão mostrados na Figura 2, abaixo.
Criada a interface, pinga-se no MK3 a Loopback do MK7. O resultado está ilustrado na Figura 3.
Onde houver conectividade pode-se implementar o BGP. Fixar essa ideia simples é 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, suponha 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.
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
O novo bloco do MK6, realmente 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 dels 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
Considerações finais 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.
Assuntos relacionados, neste blogue
- BGP no Mikrotik: Dois operadores de trânsito.
- 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)
-
08/08/2011 at 16:36BGP no Mikrotik: Dois operadores de trânsito « Infraestrutura da Internet
-
21/08/2011 at 17:47BGP no Mikrotik: Dois operadores de trânsito (Visão genérica) « Infraestrutura da Internet
-
23/03/2012 at 00:17BGP em Mikrotik – Parte I « Infraestrutura da Internet
Infraestrutura da Internet 