BGP no Mikrotik VII - Mesmo AS em empareamentos remotos e independentes

Felipe Marques

Felipe Marques

Especialista

Mensagens : 65
Pontos : 4890
Reputação : 500
Data de inscrição : 10/01/2013

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.

BGP no Mikrotik VII - Mesmo AS em empareamentos remotos e independentes Rotaba10

BGP no Mikrotik VII - Mesmo AS em empareamentos remotos e independentes Rotaba10

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.

BGP no Mikrotik VII - Mesmo AS em empareamentos remotos e independentes Vishma11

BGP no Mikrotik VII - Mesmo AS em empareamentos remotos e independentes Vishma11

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:

Código:: [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

Código:: [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

Código:: [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

Código:: [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

Código:: [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

Código:: [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%

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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:

Código:: [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!

Fonte: http://ii.blog.br/

BGP no Mikrotik VII - Mesmo AS em empareamentos remotos e independentes

1 BGP no Mikrotik VII - Mesmo AS em empareamentos remotos e independentes Qua 20 Fev - 7:37

Felipe Marques

Últimos assuntos