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

BGP em Mikrotik – Parte II

Cada homem interpreta os limites do seu campo de visão
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.

 

Figura 1: O FFE completo e pronto para outras alterações.

 

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.

 

Figura 2: Criando uma interface Loopback no MK7.

 

Criada a interface, pinga-se no MK3 a Loopback do MK7. O resultado está ilustrado na Figura 3.

Figura 3: Pingando a Loopback do MK7 a partir de MK3.

 

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.

 

Figura 4: Novo bloco para o MK6

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

 

  1. BGP no Mikrotik: Dois operadores de trânsito.
  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)
Categorias:BGP, Mikrotik, TCP/IP

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