Início > BGP, Mikrotik, TCP/IP > BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes

BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes



“Eu sou o senhor de meu destino.
Eu sou o capitão da minha alma.”

Tata Madiba Mandela.

Introdução

Conforme descrito, o MK6 é contratado para atender trânsito em um cliente nas proximidades do MK2 com o qual faz um acordo de fornecimento de trânsito. MK6 irá emparear com MK2, localmente. MK6 planeja usar seu próprio ASN (65536) e solicita um novo bloco /23, pois enxerga perspectiva para o futuro. Em adição a tais novas facilidades, MK6 propõe a MK2 um acordo de troca de tráfego bilateral, entre eles. Nessa expectativa, surge uma questão, pois MK2 e MK6 estão geograficamente distantes (MK2 está em Imperatriz, MA e MK6, em São Paulo, SP, por exemplo). A nova topologia do FFE está na Figura 1, abaixo.

 

Figura 1: Empareamento independente do MK6 (AS65536) ao MK2 (AS65532).

 

O BGP que fala da nova interconexão do MK6 é o MK8-6, que recebeu um novo bloco: 10.236.0.0/23 e à sua Loopback, a qual será usada em testes foi designado o IP 10.236.0.1/32.

Implementando o BGP no MK8-6 empareado com MK2

 

No MK8.6

A Figura 2 exibe algumas janelas do Winbox mostrando a implementação do empareamento do MK8.6 com o MK2.

Figura 2: Implementação do empareamento do MK8.6 com o MK2.

 

A janela 1, mostra a implementação e a janela 2 confirma que o empareamento foi estabelecido. Os endereços, respectivos, das interfaces para MK2 e da Loopback do MK8 estão na janela 3. A janela 4 mostra que MK8.6 está anunciando o novo /23 para MK2.

Analises da implementação

A partir de MK8.6, vamos pingar todas as Loopbacks do FFE. Eis os resultados:

[admin@MK8-6] > ping 10.201.0.1
HOST                                    SIZE  TTL TIME  STATUS                       
10.201.0.1                              56    63  1ms  
10.201.0.1                              56    63  6ms  
10.201.0.1                              56    63  9ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=5ms max-rtt=9ms 

[admin@MK8-6] > ping 10.202.0.1  
HOST                                    SIZE  TTL TIME  STATUS                   
10.202.0.1                              56    64  0ms  
10.202.0.1                              56    64  0ms  
10.202.0.1                              56    64  0ms  
    sent=3 received=3 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms 

[admin@MK8-6] > ping 10.203.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
10.203.0.1                              56    63  5ms  
10.203.0.1                              56    63  2ms  
10.203.0.1                              56    63  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=2ms max-rtt=5ms 

[admin@MK8-6] > ping 10.204.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
10.204.0.1                              56    62  4ms  
10.204.0.1                              56    62  1ms  
10.204.0.1                              56    62  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=2ms max-rtt=4ms 

[admin@MK8-6] > ping 10.205.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
10.205.0.1                              56    61  4ms  
10.205.0.1                              56    61  2ms  
10.205.0.1                              56    61  2ms  
    sent=3 received=3 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=4ms 

[admin@MK8-6] > ping 10.206.0.1 
HOST                                    SIZE  TTL TIME  STATUS           
                                                        no route to host 
                                                        no route to host 
                                                        no route to host 
    sent=3 received=0 packet-loss=100% 

[admin@MK8-6] > ping 10.207.0.1 
HOST                                    SIZE  TTL TIME  STATUS                   
10.207.0.1                              56    63  1ms  
10.207.0.1                              56    63  2ms  
10.207.0.1                              56    63  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=2ms 

Todas as Loopbacks do FFE pingam, exceto a do MK6. Enquanto lembramos porque isso acontece, vamos examinar alguns anúncios. MK8.6 está empareado com o MK2, únicamente. Assim, era de se esperar que MK2 anunciasse os blocos de MK6 para o MK8.6. Podemos ver, pela listagem abaixo, que isso, realmente, acontece:

Anúncios do MK2:

[admin@MK2] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK1      10.206.0.0/23        10.201.0.6       65537,65536 
MK1      10.226.0.0/24        10.201.0.6       65537,65536 
MK1      10.207.0.0/23        10.201.0.6       65537
MK1      10.236.0.0/23        10.201.0.6       65536
MK1      10.203.0.0/23        10.201.0.6       65533
MK1      10.226.1.0/24        10.201.0.6       65537,65536
MK1      10.202.0.0/23        10.201.0.6
MK3      10.206.0.0/23        10.202.0.9       65537,65536
MK3      10.204.0.0/23        10.202.0.9       65531,65534
MK3      10.226.0.0/24        10.202.0.9       65537,65536
MK3      10.201.0.0/23        10.202.0.9       65531
MK3      10.207.0.0/23        10.202.0.9       65537
MK3      10.236.0.0/23        10.202.0.9       65536
MK3      10.205.0.0/23        10.202.0.9       65531,65534,65535
MK3      10.226.1.0/24        10.202.0.9       65537,65536
MK3      10.202.0.0/23        10.202.0.9 
MK7      10.204.0.0/23        10.207.0.10      65531,65534
MK7      10.201.0.0/23        10.207.0.10      65531
MK7      10.236.0.0/23        10.207.0.10      65536
MK7      10.203.0.0/23        10.207.0.10      65533 
MK7      10.205.0.0/23        10.207.0.10      65531,65534,65535
MK7      10.202.0.0/23        10.207.0.10
MK8.6    10.206.0.0/23        10.202.0.13      65537,65536
MK8.6    10.204.0.0/23        10.202.0.13      65531,65534
MK8.6    10.226.0.0/24        10.202.0.13      65537,65536 
MK8.6    10.201.0.0/23        10.202.0.13      65531
MK8.6    10.207.0.0/23        10.202.0.13      65537
MK8.6    10.203.0.0/23        10.202.0.13      65533
MK8.6    10.205.0.0/23        10.202.0.13      65531,65534,65535
MK8.6    10.226.1.0/24        10.202.0.13      65537,65536
MK8.6    10.202.0.0/23        10.202.0.13

Também constatamos que, como esperávamos, o MK2 anúncia o bloco 10.236.0.0/23 pertencente ao MK8.6 para MK1, MK3 e MK7, seus respectivos pares vizinhos, BGP.

Listando a tabela de roteamento do MK8.6 podemos chegar a conclusão de que o mecanismo de prevenção de loop do BGP funciona perfeitamente bem, não admitindo tráfego de rotas com o próprio ASN do MK6 (e/ou MK8.6) presente no as_path, como podemos ver a seguir.

Rotas do MK8.6:

[admin@MK8-6] > ip route print 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0   S  0.0.0.0/0                          10.101.1.2         1       
 1 ADb  10.201.0.0/23                      10.202.0.13        20      
 2 ADb  10.202.0.0/23                      10.202.0.13        20      
 3 ADC  10.202.0.12/30     10.202.0.14     MK2                0       
 4 ADb  10.203.0.0/23                      10.202.0.13        20      
 5 ADb  10.204.0.0/23                      10.202.0.13        20      
 6 ADb  10.205.0.0/23                      10.202.0.13        20      
 7 ADb  10.207.0.0/23                      10.202.0.13        20      
 8 ADC  10.236.0.1/32      10.236.0.1      LoopBack           0 

O mesmo comportamente pode ser visto entre MK5/MK6 e MK7/MK6. As listagens abaixo ilustram os movimentos do bloco 10.236.0.0/23, de MK8.6 passando por MK1, MK4 e MK5.

Anúncios do MK1:

[admin@MK1] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH
MK2      10.205.0.0/23        10.201.0.5       65534,65535
MK2      10.204.0.0/23        10.201.0.5       65534 
MK2      10.201.0.0/23        10.201.0.5 
MK4      10.203.0.0/23        10.201.0.17      65532,65533 
MK4      10.206.0.0/23        10.201.0.17      65532,65537,65536
MK4      10.236.0.0/23        10.201.0.17      65532,65536 
MK4      10.226.0.0/24        10.201.0.17      65532,65537,65536
MK4      10.202.0.0/23        10.201.0.17      65532
MK4      10.207.0.0/23        10.201.0.17      65532,65537
MK4      10.226.1.0/24        10.201.0.17      65532,65537,65536
MK4      10.201.0.0/23        10.201.0.17
MK3      10.203.0.0/23        10.201.0.13      65532,65533
MK3      10.205.0.0/23        10.201.0.13      65534,65535
MK3      10.206.0.0/23        10.201.0.13      65532,65537,65536
MK3      10.236.0.0/23        10.201.0.13      65532,65536
MK3      10.226.0.0/24        10.201.0.13      65532,65537,65536 
MK3      10.202.0.0/23        10.201.0.13      65532
MK3      10.207.0.0/23        10.201.0.13      65532,65537
MK3      10.204.0.0/23        10.201.0.13      65534 
MK3      10.226.1.0/24        10.201.0.13      65532,65537,65536
MK3      10.201.0.0/23        10.201.0.13


Anúncios do MK4:

[admin@MK4] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK1      10.206.0.0/23        10.201.0.18      65535,65536
MK1      10.226.0.0/24        10.201.0.18      65535,65536
MK1      10.205.0.0/23        10.201.0.18      65535
MK1      10.226.1.0/24        10.201.0.18      65535,65536
MK1      10.204.0.0/23        10.201.0.18    
MK5      10.201.0.0/23        10.204.0.21      65531
MK5      10.202.0.0/23        10.204.0.21      65531,65532 
MK5      10.207.0.0/23        10.204.0.21      65531,65532,65537 
MK5      10.236.0.0/23        10.204.0.21      65531,65532,65536 
MK5      10.203.0.0/23        10.204.0.21      65531,65532,65533 
MK5      10.204.0.0/23        10.204.0.21


Anúncios do MK5:

[admin@MK5] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK4      10.226.1.0/24        10.204.0.22      65536
MK4      10.206.0.0/23        10.204.0.22      65536
MK4      10.226.0.0/24        10.204.0.22      65536
MK4      10.205.0.0/23        10.204.0.22 
MK6      10.201.0.0/23        10.205.0.25      65534,65531
MK6      10.203.0.0/23        10.205.0.25      65534,65531,65532,65533
MK6      10.236.0.0/23        10.205.0.25      65534,65531,65532,65536 
MK6      10.202.0.0/23        10.205.0.25      65534,65531,65532 
MK6      10.207.0.0/23        10.205.0.25      65534,65531,65532,65537
MK6      10.204.0.0/23        10.205.0.25      65534 
MK6      10.205.0.0/23        10.205.0.25 

Olhando a tabela de rotas do MK6 confirmamos, claramente, o respeito ao mecanismo de prevenção de loop do BGP.

Tabela de rotas do MK6:

[admin@MK6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.206.0.30        20      
 1  Db  10.201.0.0/23                      10.205.0.25        20      
 2 ADb  10.202.0.0/23                      10.206.0.30        20      
 3  Db  10.202.0.0/23                      10.205.0.25        20      
 4 ADb  10.203.0.0/23                      10.206.0.30        20      
 5  Db  10.203.0.0/23                      10.205.0.25        20      
 6 ADb  10.204.0.0/23                      10.205.0.25        20      
 7  Db  10.204.0.0/23                      10.206.0.30        20      
 8 ADb  10.205.0.0/23                      10.205.0.25        20      
 9 ADC  10.205.0.24/30     10.205.0.26     MK5                0       
10 ADC  10.206.0.1/32      10.206.0.1      LoopBack           0       
11 ADC  10.206.0.28/30     10.206.0.29     MK7                0       
12 ADb  10.207.0.0/23                      10.206.0.30        20      
13  Db  10.207.0.0/23                      10.205.0.25        20

Contornando o mecanismo de prevenção de loop do BGP

O BGP é bastante flexível. Se por uma lado isso é ótimo, por outro, tal flexibilidade pode induzir a falhas humanas, particularmente. Portanto é importante, redobrada atenção ao usarmos recursos que anulam as propostas formais do BGP, definidas em [1].

O recurso que permite ao BGP que fala, ignorar o mecanismo de prevenção de loop é o atributo informal allow_as_in. Na janela 1 da Figura 2, acima, podemos ver onde se situa tal parâmetro. Ao usá-lo, devemos informar o número de blocos que desejamos receber no BGP que fala, que contenha seu próprio ASN, no as_path. O allow_as_in será ativado no MK8.6, com o objetivo de receber os anúncios de MK6 e, também nesse, autorizando o recebimento dos anúncios de MK8.6. O MK8.6 somente recebe tais anúncios do MK2, mas o MK6 pode receber anúncios tanto do MK5 como do MK7. Em todos os casos, o número de blocos a ser recebido será 1. Ativando-o em MK8.6, conseguimos pingar a Loopback de MK6:

[admin@MK8-6] > ping 10.206.0.1
HOST                                    SIZE  TTL TIME  STATUS               
10.206.0.1                              56    62  2ms  
10.206.0.1                              56    62  1ms  
10.206.0.1                              56    62  1ms  
    sent=3 received=3 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=2ms

E, as rotas para MK6 aparecem, serenamente:

[admin@MK8-6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0   S  0.0.0.0/0                          10.101.1.2         1       
 1 ADb  10.201.0.0/23                      10.202.0.13        20      
 2 ADb  10.202.0.0/23                      10.202.0.13        20      
 3 ADC  10.202.0.12/30     10.202.0.14     MK2                0       
 4 ADb  10.203.0.0/23                      10.202.0.13        20      
 5 ADb  10.204.0.0/23                      10.202.0.13        20      
 6 ADb  10.205.0.0/23                      10.202.0.13        20      
 7 ADb  10.206.0.0/23                      10.202.0.13        20      
 8 ADb  10.207.0.0/23                      10.202.0.13        20      
 9 ADb  10.226.0.0/24                      10.202.0.13        20      
10 ADb  10.226.1.0/24                      10.202.0.13        20      
11 ADC  10.236.0.1/32      10.236.0.1      LoopBack           0

Muito interessante é observar a tabela de rotas do MK6. Ele acaba preferindo MK7, entre MK5, para chegar em suas instalações encabeçadas pelo MK8.6:

[admin@MK6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.206.0.30        20      
 1  Db  10.201.0.0/23                      10.205.0.25        20      
 2 ADb  10.202.0.0/23                      10.206.0.30        20      
 3  Db  10.202.0.0/23                      10.205.0.25        20      
 4 ADb  10.203.0.0/23                      10.206.0.30        20      
 5  Db  10.203.0.0/23                      10.205.0.25        20      
 6 ADb  10.204.0.0/23                      10.205.0.25        20      
 7  Db  10.204.0.0/23                      10.206.0.30        20      
 8 ADb  10.205.0.0/23                      10.205.0.25        20      
 9 ADC  10.205.0.24/30     10.205.0.26     MK5                0       
10 ADC  10.206.0.1/32      10.206.0.1      LoopBack           0       
11 ADC  10.206.0.28/30     10.206.0.29     MK7                0       
12 ADb  10.207.0.0/23                      10.206.0.30        20      
13  Db  10.207.0.0/23                      10.205.0.25        20      
14 ADb  10.236.0.0/23                      10.206.0.30        20      
15  Db  10.236.0.0/23                      10.205.0.25        20       

Mudaríamos tal preferência se o parâmetro allow_as_in fosse retirado do empareamento de MK6 com MK7. Vejam:

[admin@MK6] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.206.0.30        20      
 1  Db  10.201.0.0/23                      10.205.0.25        20      
 2 ADb  10.202.0.0/23                      10.206.0.30        20      
 3  Db  10.202.0.0/23                      10.205.0.25        20      
 4 ADb  10.203.0.0/23                      10.206.0.30        20      
 5  Db  10.203.0.0/23                      10.205.0.25        20      
 6 ADb  10.204.0.0/23                      10.205.0.25        20      
 7  Db  10.204.0.0/23                      10.206.0.30        20      
 8 ADb  10.205.0.0/23                      10.205.0.25        20      
 9 ADC  10.205.0.24/30     10.205.0.26     MK5                0       
10 ADC  10.206.0.1/32      10.206.0.1      LoopBack           0       
11 ADC  10.206.0.28/30     10.206.0.29     MK7                0       
12 ADb  10.207.0.0/23                      10.206.0.30        20      
13  Db  10.207.0.0/23                      10.205.0.25        20      
14 ADb  10.236.0.0/23                      10.205.0.25        20

Uma forma de alterar rumos do tráfego. Bastante interessante, a flexibilidade/poder do BGP que fala, nesse caso!

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr).

Categorias:BGP, Mikrotik, TCP/IP
  1. 11/08/2016 às 17:03

    Boa tarde, gostaria de saber se os erros nas informações são intencionais, caso não o pq desse ASN de MK08-6 se o mesmo do MK6

    • juliaobraga
      11/08/2016 às 17:30

      Olá Carlos,

      Erros nas informações não são intencionais. Portanto, qualquer erro, se não anotado no contexto é não intencional. Veja no primeiro parágrafo, que “Mk6 planeja usar seu próprio ASN…”. O uso de um mesmo ASN em pareamentos diversos, local ou remoto é permitido. É o que se pretende ilustrar, com este exemplo.

  1. 18/04/2011 às 19:21
  2. 08/08/2011 às 16:37
  3. 21/08/2011 às 17:47
  4. 23/03/2012 às 00:17

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

%d blogueiros gostam disto: