Arquivo

Archive for 08/03/2011

BGP em Mikrotik – Parte III

Há duas possibilidades:
Se o resultado confirma a hipótese, então você fez uma medição.
Se o resultado for contrário à hipótese, então você fez uma descoberta.
Enrico Fermi, físico e prêmio Nobel (1901-1954)

Introdução

O MK3 andou preocupado com a sua conexão com a Internet via MK2. Completa ausência de redundância. Trânsito é mais barato, via MK2, mas não suficientemente confiável. Não propriamente, por MK2, mas pelos dois enlaces até MK1. Então, MK3 resolveu negociar trânsito com MK1 (uma banda menor, talvez) e assim agregar valor ao seu serviço. Isso que MK3 fez chama-se inovação de valor. A Figura 1, abaixo, exibe a conexão desejada por MK3 e a inserção de uma interface Loopback em cada MKi, para i=1, …, 7. Servirá para exercícios, principalmente de conectividade.

 

Figura 1: A alternativa do MK3 para preservar a confiabilidade do trânsito para seus Clientes e interfaces Loopback em cada MKi.

 

Conectando MP3 a MP1, via Loopback.

Essa é uma alternativa ilustrativa somente. Primeiro porque é possível uma conexão, em BGP, via Loopback por haver acessibilidade. Segundo, não é uma conexão que resolve os interesses de MK3 sob o ponto de vista da confiabilidade do trânsito. Uma conexão via Loopback manterá o mesmo risco, pois o tráfego de trânsito segue o mesmo caminho dos BGPs construídos entre MK3, MK2 e MK1.

Mas, o interesse didático insiste no BGP via Loopback. Antecipando alguns problemas, vamos lembrar sobre os 6 estados que o BGP assume, para tomar decisões sobre suas operações. São eles: Idle, Connect, Active, OpenSent, OpenConfirm e Established. Tudo está explicado na RFC42711, a partir do item 8, e não repetiremos aqui, exceto o esquema da Máquina de Estado Finito (MEF), que o BGP usa para transitar entre seus diversos estados, durante o processo de entendimento com seus pares. O esquema está na Figura 2, e não é muito comum ver uma versão atualizada da MEF do BGP.

 

Figura 2: Autômato finito do BGP (desenhado pelo autor).

 

Vamos então usar o mesmo esquema para estabelecer a sessão BGP entre MK3 e MK1, via Loopback. Eis o resultado na Figura 3.

 

Figura 3: BGP via Loopback entre MK3 e MK1.

 

O estado (State) tanto no MK1 como no MK3, está active. Recorrendo à Figura 2 e à referência [1], podemos reconhecer alguma pista sobre porque o estado final, Established, não foi atingido. Os problemas que estão fazendo com que o BGP retorne insistemente ao estado active, podem ser:

  1. Porta TCP 179 não está aberta
  2. Portas TCP, randômicas, acima de 1023 não estão abertas
  3. Configuração errada do BGP
  4. Instabilidade da interface de rede

Podemos descartar (1) e (2), pois não há firewall, nem em MK1 e nem em MK3. Podemos, também eliminar o item (4), já que usamos uma interface Loopback e, uma de suas vantagens é a de não produzir instabilidades. Além do mais, o BGP de MK1 para MK2 está Established. O mesmo acontece com o BGP de MK2 para MK3. Então, só nos resta o item (3): Configuração errada do BGP!! Essa é a alternativa mais difícil pois depende de prática. Mas, nesse caso o erro é bem comum e ocorreu por provocação didática. Temos um caso típico de uma sessão BGP entre dois pares não diretamente conectados! Tal fato é visível, pois os IPs das respectivas Loopbacks estão em redes diferentes (não conectadas diretamente), apesar de acessíveis entre si. Em outras palavras, temos um BGP multi-hop. Então podemos alterar a configuração dos MK1 e MK2. Após a inclusão do Multi-hop, o problema ainda não fica resolvido e os estados do BGP ficam trocando entre Idle, Active e OpenSent. A presença do estado Active, em nosso cenário, induz ao fato de que continua havendo um erro na nossa configuração BGP. Não é uma falha tão óbvia, como a do Multi-hop. Uma olhada nos possíveis problemas quando o estado OpenSent aparece, não ajuda a posição de quem não tem muita experiência em BGP. Mas vejamos as indicações expostas em [2]:

  1. O autômato do BGP está aguardando uma mensagem de Open de seu par
  2. Recebida a mensagem de Open, o roteador verifica a sua validade
  3. Se há um erro, um dos campos da mensagem de Open é incompatível entre os pares (versão do BGP, senha MD5 incompatível, informação de AS incompatível). O fato é que o roteador envia uma mensagem para o par, indicando o erro.
  4. Não há erro. Uma mensagem de Keepalive é enviada várias vezes e o estado é alterado para OpenConfirm

Em uma reflexão simplista podemos eliminar o item (4), pois não recebemos indicação de mudança de estado para OpenConfirm. Podemos ir em Logging e incluir uma opção de mensagens vindas do BGP. Veremos quase nenhuma indicação para nos auxiliar. Melhor alternativa talvez seja ir no Google e procurar por três palavras “bgp loopback opensent”. A referência da Cisco, na Parte I, desse tópico, também mostra a solução. Quando usamos Loopback para estabelecer um empareamento BGP é necessário forçar o BGP a usar a interface Loopback. Isso é feito com o recurso Update-source, na aba Advanced do BGP Peer, como nos mostra a Figura 4, logo abaixo.

 

Figura 4: Forçando o BGP a usar a Loopback.

 

BGP direto entre o MK1 e o MK3

Iremos supor que a Figura 1 está agora com o BGP entre MK1 e MK2, usando o bloco passado pelo MK1: 10.201.0.14/30 e assim daremos a continuidade na parte IV, onde veremos as bases iniciais do longo debate sobre filtros, em BGP. Então, a Figura 5 mostra essa configuração final de nossos membros da FFE.

 

Figura 5: Configuração final da FFE.

 

Conclusão da Parte III

A FFE sempre irá representar topologias que estão na mesma rede. Mesmo que estejamos criando interfaces com IPs de redes diferentes, como foi o caso do exemplo da Loopback. Basta simplesmente nos abstrair desse fato, que tudo irá parecer como sendo roteadores interconectados remotamente.

Outra questão muito importante é que quando nos expressamos com a palavra BGP, com foi feito até o presente momento, a referência é exclusiva ao eBGP. Quem está acostumado com Cisco, verá que os comandos sempre conterão ebgp. Quando fizermos abordagens a iBGP não deixaremos o contexto nos confundir. Por outro lado, em iBGP os ASNs dos pares são sempre os mesmos.

 

Referências

  1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 26/08/2012.
  2. Wikipedia, Border Gateway Protocol. Disponível em: http://en.wikipedia.org/wiki/Border_Gateway_Protocol. Acessado em 08/03/2011.

Categorias:BGP, Mikrotik, Protocolos, TCP/IP

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