BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
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.
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.
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
-
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).
| Follow @juliaobraga |
Infraestrutura da Internet 
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
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.