Infraestrutura da Internet

04/04/2011

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

Filed under: BGP, Mikrotik, TCP/IP — juliaobraga @ 16:02


“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).

3 Comentários »

  1. [...] AS em empareamentos remotos e independentes. Infraestrutura da Internet. 2011. Disponível em: http://juliaobraga.wordpress.com/2011/04/04/bgp-no-mikrotik-vii-mesmo-as-em-empareamentos-remotos-e-…. Acessado em 15/04/2011 [...]

    Pingback por BGP no Mikrotik (IX): Filtros « Infraestrutura da Internet — 18/04/2011 @ 19:21

  2. [...] BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes [...]

    Pingback por BGP no Mikrotik: Dois operadores de trânsito « Infraestrutura da Internet — 08/08/2011 @ 16:37

  3. [...] BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes [...]

    Pingback por BGP no Mikrotik: Dois operadores de trânsito (Visão genérica) « Infraestrutura da Internet — 21/08/2011 @ 17:47


Feed RSS para comentários sobre este post. URI de trackback

Deixe uma resposta

Faça o login usando um destes métodos para comentar:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Sair / Alterar )

Imagem do Twitter

You are commenting using your Twitter account. ( Sair / Alterar )

Foto do Facebook

You are commenting using your Facebook account. ( Sair / Alterar )

Cancelar

Connecting to %s

Tema: WordPress Classic. Blog no WordPress.com.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.