Arquivo

Archive for março \22\-03:00 2011

BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup

Atualizado em 12/05/2001: Deixar claro que weight não é um atributo do BGP.

Introdução

O FFE é um ambiente dinâmico! MK3 decide que o enlace com MK1 deve ficar como alternativa de tráfego somente se o tráfego via MK2 falhar. As justificativas dessa escolha são muitas: enlace para o MK1 tem banda pequena ou está com falhas intermitentes ou … A Figura 1, que segue mostra como ficaria a topologia do FFE com a decisão de MK3. Na figura, o enlace alternativo esta em vermelho.

 

Figura 1: Topologia do FFE do enlace de backup do MK3.

 

Análise da situação anterior

Um traceroute do MK5 até a Loopback do MK3, mostra que o tráfego passa no menor caminho de MK1 para MK3, que é o enlace direto (sem o MK2 na jogada).

[admin@MK5] > tool traceroute 10.203.0.1
   1     10.204.0.21 30ms 1ms 1ms 
   2     10.201.0.17 3ms 1ms 1ms 
   3     10.203.0.1 3ms 6ms 3ms

Mais claro ainda, se verificássemos as rotas em MK1. A rota ativa para o MK3 é via o enlace sobre o qual se deseja como alternativo.

[admin@MK1] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 7 ADb  10.203.0.0/23                      10.201.0.14        20      
 8  Db  10.203.0.0/23                      10.201.0.6         20

O inverso, isso é, o tráfego saindo de MK3, também passa pelo enlace direto de MK3 a MK1. Por exemplo, as rotas ativas em MK3 apontam diretamente para MK1, ignorando MK2:

[admin@MK3] > ip route print
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.201.0.13        20      
 1  Db  10.201.0.0/23                      10.202.0.9         20      
 2 ADC  10.201.0.12/30     10.201.0.14     ether2             0

Já o traceroute para a Loopback do MK5, por exemplo é mais claro:

[admin@MK3] > tool traceroute 10.205.0.1
     ADDRESS 
   1     10.202.0.9 4ms 1ms 1ms 
   2     10.201.0.5 1ms 1ms 1ms 
   3     10.201.0.18 2ms 2ms 1ms 
   4     10.205.0.1 4ms 2ms 1ms

O caminho inverso, do MK5 para o MK3 mostra o que ocorre com um traceroute na direção da Loopback do MK3:

[admin@MK5] > tool traceroute 10.203.0.1
     ADDRESS  
   1     10.204.0.21 5ms 1ms 1ms 
   2     10.201.0.17 3ms 1ms 1ms 
   3     10.203.0.1 3ms 1ms 1ms

Finalmente vamos repetir, pela terceira vez, o fato do BGP não anunciar para um empareado vizinho, os blocos pertencentes a tal vizinho. Um comportamento (ou propriedade), que pode ser visto na tabela de anúncios, do MK1, o principal foco do desejo de MK3, onde MK1 não anuncia para MK3, o bloco 10.203.0.0/23. Uma propriedade, que faz parte do processo de decisão do BGP descrito em complexo detalhamento, na RFC4271, em [1], novamente a principal referência. Não há como entrar em detalhes nesse texto, exclusivamente prático. Lembrar, entretanto é fundamental, para o que segue.

Filtros no BGP

Atender ao MK3 significa usar filtros, no BGP nele implementado. Umas das formas de filtrar, no BGP é indicar, para cada par, os respectivos nomes dos filtros de entrada e de saída. A Figura 2 mostra onde fazer isto, no Mikrotik.

 

Figura 2: Especificando filtros no BGP.

 

MK3 tem dois vizinhos BGP, o MK1 e o MK2. A Figura 3 mostra os respectivos nomes escolhidos.

 

Figura 3: Nomes escolhidos para os filtros BGP do MK3, para cada empareado vizinho.

 

Onde especificar os filtros

Nomeado os filtros, o próximo passo é defini-los. O local, no Mikrotik, onde isso é feito, está mostrado na Figura 4. (OBS: Leia-se MK1_out ao invés de MK2_out no lado esquerdo da figura).

 

Figura 3: Nomes escolhidos para os filtros BGP do MK3, para cada empareado vizinho.

 

Planejando os filtros do MK3 com vistas ao enlace de backup

Se desfizermos o enlace para MK1, teríamos o desejo de MK3, exceto pelo fato de não haver um backup. O enlace para MK1 estaria fora definitivamente. Mas podemos, no FFE, fazer isso e mostrar o traceroute do e para o MK5.

Do MK5:

[admin@MK5] > tool traceroute 10.203.0.1
     ADDRESS 
   1     10.204.0.21 5ms 1ms 1ms 
   2     10.201.0.17 1ms 1ms 2ms 
   3     10.201.0.6 6ms 1ms 1ms 
   4     10.203.0.1 3ms 1ms 1ms


Para o MK5:

[admin@MK3] > tool traceroute 10.205.0.1       
     ADDRESS
   1     10.202.0.9 2ms 1ms 1ms 
   2     10.201.0.5 1ms 1ms 1ms 
   3     10.201.0.18 2ms 2ms 2ms 
   4     10.205.0.1 3ms 2ms 2ms

Os dois traceroutes acima, com a parada do BGP do MK3 para o MK1 foi somente para ilustrar e, não resolve o problema do MK3. Retornamos o BGP entre MK3 e MK1 e começamos a pensar dividindo-o em dois outros: nenhum tráfego sai de MK3 diretamente via MK1 e, nenhum tráfego entra em MK3 diretamente via MK1 exceto se o enlace de MK2 a MK3 for rompido involuntariamente.

 

Nenhum tráfego entra em MK3 diretamente via MK1

Com o tempo veremos que existem diversas alternativas de filtros que causam o efeito que se deseja. A diversidade de filtros está diretamente ligada à experiência do adiministrador do BGP. O FFE é um excelente instrumento para exercitar.

Sabemos que o MK1 envia tráfego para o MK3 pelo menor caminho ou menor as_path. Vamos ver os anúncios e as rotas atuais e ativas, em alguns dos MKi, em relação ao MK3:

Rota do MK1 para MK3:

[admin@MK3][admin@MK1] > ip route print where active              
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 ...     
 6 ADb  10.203.0.0/23                      10.201.0.14        20      
 ...      


Anúncios do MK1 para MK4, dos blocos de MK3 e de MK2:

[admin@MK1] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH
...    
MK4      10.203.0.0/23        10.201.0.17      65533       
...      
MK4      10.202.0.0/23        10.201.0.17      65532
...


Anúncios do MK2 para MK1, dos blocos de MK3 e de MK2:

[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      
...      
MK1      10.202.0.0/23        10.201.0.6
...

Na última listagem acima, quando o MK2 anunciar para MK1, ele irá preceder o as_path com o seu ASN, como é do nosso conhecimento. Então, o anúncio do bloco do MK3, terá dois ASNs e o do bloco do MK2, somente um ASN. Continuando …

Anúncios do MK2 como chegam no MK1, somente para os blocos de MK2 e MK3. E, não estamos interessados no next_hop, pois já sabemos que irá indicar a interface do MK2:

10.203.0.0/23  vindo de MK2  65532, 65533         
10.202.0.0/23  vindo de MK2  65532

Agora, podemos pensar nos anúncios feitos do MK3 para o MK1. O MK3 precede o as_path de seu bloco com seu próprio ASN. Então, o anúncio de MK3 chega da seguinte forma em MK1:

10.203.0.0/23  vindo de MK3  65533         

Observando as duas últimas referências do bloco de MK3, o tráfego vai de MK1 para MK3 porque é sempre o menor caminho (ou menor as_path). Claro, não é nenhuma novidade para nós!

Por outro lado, também sabemos que podemos preceder o ASN de MK3, em todos os anúncios feitos pelo MK3, tantas vezes quanto desejarmos. Para fazer isto, usamos os filtros. Em resumo, queremos que todos os anúncios feitos do MK3 para o MK1 sejam precedidos por tantos ASN do MK3 de tal maneira que o menor as_path para o MK3 seja via o MK2! Quantas vezes devemos preceder o ASN de MK3? Boa pergunta. O FFE permite o exercício, facilmente. Vamos preceder somente uma vez. Em TODOS os anúncios de MK3 para MK1. Isso implica que a saida para MK1 deve ser violada. Ou seja, via um filtro sobre MK1_out. Usando as figuras que seguem vamos ilustrar tais filtros. Mas antes, vamos preceder o anúncio, somente, no bloco 10.203.0.1/23 e testar com o traceroute.

 

Figura 4: Precedendo o ASN de MK3 em seu próprio bloco.

 

Na Figura 4, exibimos três componentes de um mesmo filtro. O primeiro, na aba Matchers, onde escolhemos Chain, com o nome de MK1_out (há uma lista que não nos deixa errar). Na mesma aba, incluímos o bloco do MK3, em Prefix. Na aba Actions, mantemos passthrough como a ação a ser executada e falaremos sobre ações em outro momento. Finalmente, na aba BGP Actions, em Set BGP Prepend Path, incluimos o ASN de MK3.

Um traceroute, já é suficiente para percebermos que o resultado está como desejávamos:

[admin@MK5] > tool traceroute 10.203.0.1
     ADDRESS  
   1     10.204.0.21 1ms 1ms 1ms 
   2     10.201.0.17 3ms 1ms 1ms 
   3     10.201.0.6 1ms 1ms 1ms  <== Via MK2
   4     10.203.0.1 2ms 1ms 2ms 

Com o objetivo de responder á pergunta de quantas precedências, vamos bloquear o enlace para MK1 via MK2 e dar uma olhada no anúncio de MK3. Não há necessidade de verificar a tabela de rotas porque já sabemos que se não existe MK2 a rota para MK3 é feita via o enlace MK1/MK3.

O anúncio mais ilustrativo é o do MK5.

[admin@MK5] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH 
MK4      10.206.0.0/23        10.204.0.22      65536   
MK4      10.226.0.0/24        10.204.0.22      65536  
MK4      10.226.1.0/24        10.204.0.22      65536
MK4      10.205.0.0/23        10.204.0.22 
MK6      10.207.0.0/23        10.205.0.25      65534,65531,65533,65532,65537 <=== **
MK6      10.201.0.0/23        10.205.0.25      65534,65531
MK6      10.203.0.0/23        10.205.0.25      65534,65531,65533,63533   <=== Precedência do ASN MK3
MK6      10.202.0.0/23        10.205.0.25      65534,65531,65533,65532
MK6      10.204.0.0/23        10.205.0.25      65534
MK6      10.205.0.0/23        10.205.0.25

Como indicado, o anúncio para o MK6 inclui duas vezes o ASN de MK3. Mais interessante, entretanto, está o anúncio do MK5 do anúncio para MK6, com **. Antes de retornarmos o enlace de MK1/MK2 vamos alterar a precedência em MK3, retirando o Prefixo 10.203.0.0/23 do filtro estabelecido. Ao fazermos isso, o filtro será para qualquer bloco. Em seguida repetimos a lista de anúncios em MK5:

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

O ** indica uma dupla repetição do ASN do MK3. Como MK1/MK2 está fora do ar, o caminho para o MK2 é via MK3. Voltaremos, nesse instante o enlace MK1/MK2 à normalidade.

Resolvemos, então, a primeira parte da equação que atende à expectativa de MK2. Vamos à outra! Mas antes vale lembrar que poderíamos ter feito o mesmo usando o atributo MED, conforme vimos no texto anterior. Quando maior o valor do MED, maior a prioridade do tráfego. O valor do MED influencia o vizinho do BGP que fala (neste contexto, o MK3). Se desejamos que o tráfego venha todo por MK2, então devemos filtrar a saída para MK2, aumentando o MED, cujo valor padrão no Mikrotik é zero. Em outro exemplo usaremos o atributo MED, para ilustrar.

Há uma outra observação importante e final, sobre o que fizemos no MK3, alterando o as_path. Ao fazer isso, alteramos a política de roteamento, do MK3. Tal lembrança será muito importante ao comentarmos sobre o IRR e o FFE.

Nenhum tráfego sai do MK3 diretamente via MK1.

Não queremos resolver esse problema pedindo ajuda a MK1 e/ou MK2, vizinhos imediatos de MK3. Queremos que MK3 resolva esse problema, impedindo tráfego de saída pelo MK1, exceto se MK2 falhar. Assim com vimos acima que os atributos as_path e MED influenciam o tráfego de entrada, dois outros mecanismos influenciam o tráfego de saída do BGP que fala. São: o atributo local_pref e o não-atributo weight. Vamos falar sobre eles agora.

O atributo local_pref e o mecanismo weight

Estes dois mecanismos influenciam o tráfego de saída. O local_pref é um atributo definido na RFC4271, [1], como sendo um atributo que pode ser incluído em mensagens de UPDATE enviadas pelo BGP que fala para seus empareados internos (iBGP!). Mensagens de UPDATE enviadas pelo BGP que fala para seus pares externos NÃO pode conter o atributo local_pref exceto se estiver estabelecido uma Confederação (sobre o qual discutiremos em outra oportunidade). Assim, não será possível usarmos o local_pref na topologia atual do FFE, pois só temos eBGP

Felizmente, a Cisco criou o mecanismo weight (que não é um atributo!). Esse mecanismo não está definido na RFC4271, [1]. Como falamos, ele influencia no tráfego sai e seu valor padrão é zero (tal valor pode ser outro, dependendo da implementação). Então, podemos usá-lo pois quase todos outro fabricantes o implementam, também, face à sua imensa utilidade. Para isso iremos definir um filtro de entrada para o MK2, com o valor, abritrário 100, no parâmetro Set BGP Weight da aba BGP Actions, em filtros de roteamento BGP. Podemos ver esse caminho do Mikrotik, na figura 4, acima.

Antes da aplicação do mecanismo weight, o resultado de um traceroute a partir do MK3 na direção da Loopback do MK5 é o seguinte:

[admin@MK3] > tool traceroute 10.205.0.1
     ADDRESS 
   1     10.201.0.13 2ms 1ms 1ms   <== Direto por MK1
   2     10.201.0.18 1ms 1ms 1ms 
   3     10.205.0.1 2ms 1ms 1ms

Após a aplicação do weight (com o valor 100, em MK1), o resultado de um traceroute a partir do MK3 na direção da Loopback do MK5 é o seguinte:

[admin@MK3] > tool traceroute 10.205.0.1
     ADDRESS
   1     10.202.0.9 35ms 1ms 1ms   <=== Via MK2
   2     10.201.0.5 20ms 1ms 1ms 
   3     10.201.0.18 4ms 4ms 2ms 
   4     10.205.0.1 2ms 2ms 2ms

Assim, resolvemos o problema de MK3. O tráfego não sai e nem entra via, diretamente, o MK1, exceto se MK2 estiver fora em ambos os enlaces que ele possui.

Talvez haja uma dúvida no ar: porque foi usado o weight em um filtro de entrada para o MK3 (no caso filtro sobre o MK2_in)? A questão é importante. Portanto, vale a pena pensar a respeito!

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, IRR, Mikrotik, TCP/IP

BGP no Mikrotik (V): Analisando anúncios de implementações de BGP

Introdução

Para avançarmos é necessário entender o comportamento do BGP em um cenário como o da Figura 1, originado no texto (IV).

 

Figura 1: Topologia do FFE com o empareamento acordado entre MK7 e MK2.

 

O BGP possui dois comportamentos diferenciados. Um é o eBGP, que basicamento é quem estamos analisando até agora e só existe ele na topologia da Figura 1. O outro é o iBGP. O eBGP é o protocolo para as relações inter-AS e, portanto, o alicerce da Internet. O iBGP é o protocolo responsável pelas relações entre roteadores dentro de um mesmo AS. É um pouco difícil separar os dois, mas nesse texto estamos forçando a abstração do iBGP. Não há na topologia da Figura 1, nenhum AS com infraestrutura interna visível. Mas, no devido tempo iremos tratar de iBGP. As dificuldades são – (a) os atributos do BGP possuem características de comportamento diferenciadas para cada um deles e (b) o BGP implementa os dois protocolos, automaticamente. Tais dificuldades implicam que quando retornarmos ao iBGP teremos de descrever novamente os atributos que estamos agora comentando somente para o eBGP.

Por outro lado, iremos usar um termo da RFC4271, em [1], que é usado para referenciar o roteador que implementa o BGP, nomeado por BGP speaker. Iremos insistir no Português, chamando-o de BGP que fala. No plural, BGPs que falam.

O teste de conectividade da topologia

A primeira coisa a fazer é verificar a conectividade de nossa topologia. Uma alternativa simples é o ping. O resultado desse teste está na Tabela 1.

 

MKi MKI MK2 MK3 MK4 MK5 MK6 MK7
MK1 S S S S S S S
MK2 S S S S S N S
MK3 S S S S S S S
MK4 S S S S S S S
MK5 S S S S S S S
MK6 S S S S S S S
MK7 N S N N S S S
Tabela 1: Resultado de pings para Loopbacks

 

O ping de MKi para sua própria Loopback é, realmente, um excesso de zêlo. O resultado final, não foi o esperado. Do MK2 não se consegue pingar a Loopback do MK6. E, do MK7, não se consegue pingar as Loopbacks de MK1, MK3 e MK4. À primeira vista parece estranho, principalmente considerando os anúncios e as tabelas de rotas de cada MKi. Sendo necessário uma verificação, entre as diversas alternativas, a primeira foi retirar o enlace MK7 com MK2. Feito isso, o resultado da tabela de pings foi completamente positivo. Retornamos com a conexão MK7/MK2. Eis algumas reflexões, que ocorreram depois do primeiro teste:

  • A topologia atual do FFE é bastante intuitiva. Sabemos exatamente qual é o melhor caminho em cada MKi para um outro MKj qualquer.

  • Não há nenhum filtro de BGP, até porque não tratamos disso ainda.

  • Muito menos havia firewall, pois nem estamos pensando nele, nesse momento.

  • Repassamos todas as configurações. Nenhum erro de configuração foi encontrado… Processo cansativo …

  • Cada um dos MKi da topologia do FFE, Figura 1, possue configuração BGP multihoming, isto é, conecta-se a pelo menos dois diferentes provedores de trânsito. Nessa proposta de topologia, não estamos interessados em identificar quem é provedor de trânsito e/ou quem é cliente. Em tese, todos são provedores de trânsito ou clientes (exceto o MK1), mas estamos nos abstraindo dessa questão, sem importância no momento. Multihoming possui características técnicas interessantes pois permite pensarmos em redundância e otimização das diversas interconexões. Por outro lado, há uma importante consideração a ser feita em uma topologia multihoming: um AS pode eventualmente se tornar um operador de tráfego de trânsito, sem que ele o queira. Ou saiba… Um documento interessante a esse respeito, entre muitos outros é o [4].

  • Na topologia, não há implementação de iBGP, que será tratado em outra oportunidade, como já foi dito. Somente eBGP, sobre o qual focaremos nossas preocupações.

  • Não se pode, infelizmente, descartar a hipótese de falha no Mikrotik. O mesmo pensaríamos em outros roteadores. Isso, sempre, nos é lembrado.

  • A melhor alternativa é avaliar, em detalhes, os anúncios e rotas geradas .

Análise das rotas

Antes de partir para a análise das rotas, propriamente ditas, há algumas informações importantes que devemos ter em mente.

Loop no BGP

No final da Parte IV chamei atenção para o laço formado em dois pontos da topologia apresentada na Figura 1, acima. A razão disso era para lembrar, aqui, o fato de que o BGP possui um mecanismo muito importante e eficaz de prevenção de laços infinitos (loops). Para executar esta função, o BGP usa o atributo as_path. Por exemplo, um BGP que fala não aceita um anúncio onde seu ASN está presente no as_path.

Devemos ficar tranquilos em relação à eficácia do mecanismo de prevenção de loop do BGP, mas atentos em relação ao fato de que o mecanismo é um software (mesmo o firmware). Software envolve o ser humano. Juntando esse fato com o Teorema da Parada, a noção de Gödel sobre sistemas formais e o fato de que as linguagens de programação são sistemas formais, então há necessidade de uma prevenção mental.

Ficaremos, portanto, com uma preocupação em mente em relação ao Mikrotik e a sua implementação da prevenção de loop no BGP. Sem estresse, contudo.

O atributo next_hop

A cada vez que um anúncio é recebido por um BGP que fala, o atributo next_hop é alterado para o endereço IP do par vizinho, que enviou o anúncio.

Um BGP que fala, nunca anuncia uma rota para o par que deu origem à rota. E, também, nunca, em uma tabela de roteamento do BGP que fala haverá uma rota para si mesmo (isto é, um next_hop com endereço de qualquer uma de suas interfaces). Aliás, já falamos sobre isto.

Conforme descrito em [1], o atributo next_hop é usado pelo BGP que fala, para determinar a interface e o próximo endereço que será usado para transmitir pacotes. O próximo endereço é determinado através de uma análise recursiva sobre o endereço IP que está especificado no atributo next_hop de cada rota contida na tabela de roteamento.

O atributo multi_exit_disc (MED)

O atributo multi_exit_disc ou, simplesmente MED provê um mecanismo para BGPs que falam influenciar sobre tráfego que chega a ele. Ele permite que um AS informe a outro AS sobre suas preferências em relação às alternativas de entrada. Um exemplo que veremos mais à frente usaremos o atributo MED para estabelecer uma rota de backup, oportunidade em que abordaremos mais detalhes.

MED é um atributo opcional. Há muita variação nas implementações entre um fabricante e outro, de roteadores. O valor do atributo MED é denominado métrica. Quando menor a métrica, maior a prioridade. O valor padrão da métrica varia por fabricante, embora as RFCs recomendem o valor equivalente a 0. Esse é o valor padrão para o Mikrotik. Há uma certa imprecisão nas informações sobre valores da métrica.

A RFC4451, em [5], trata exclusivamente desse atributo.

O atributo as_path

É um atributo que faz parte de uma mensagem UPDATE com o objetivo de anunciar prefixos/rotas. O as_path é representado, na mensagem UPDATE, por uma lista que indica ao BGP que fala, qual o caminho que deve ser percorrido, até que se chegue ao AS que originou o anúncio. A lista começa à esquerda com o ASN do AS que por último encaminhou o anúncio do prefixo/rota e termina à direita, com o ASN do AS que originou o anúncio. Um outro segmento da mensagem UPDATE, contem o endereço do next_hop, isto é, o endereço do AS que tem seu ASN mais à esquerda, da lista que compõe o as_path. O endereço do next_hop foi alterado pelo BGP vizinho que enviou a mensagem UPDATE. O BGP que fala instala as informações da rota na tabela de rotas, com alterações relacionadas ao melhor caminho para a rota, por exemplo.

O as_path é, portanto, uma lista que pode ser bem extensa. Na topologia do FFE não aparece, mas podemos imaginar quando o BGP que fala receber a tabela completa de rotas, da Internet. Para lidar com isto, a implementação do BGP divide a lista que compõe o segmento, em dois componentes, chamados de AS_SET e AS_SEQUENCE, respectivamente.

Tomado conhecimento desses fatos poderemos entender o mecanismo de propagação de rotas do BGP descrito em [1]. Quando um BGP que fala propaga uma rota, ele aprendeu tal rota via uma mensagem de UPDATE de um outro BGP que fala. Então, ele modifica o atributo as_path baseado na localização do BGP que fala (externo) para o qual a rota será enviada, da seguinte maneira:

  • Se o primeiro componente do segmento as_path for do tipo AS_SEQUENCE (um conjunto ordenado), o sistema local precede o seu próprio ASN no último elemento da sequência (mais à esquerda da lista). Se tal operação fizer com que o número de ASNs dessa lista ultrapasse de 255, ele então inclui um novo segmento do tipo AS_SEQUENCE no qual ele insere seu próprio ASN a esse novo segmento.

  • Se o primeiro segmento do as_path é do tipo AS_SET (um conjunto não-ordenado), o sistema local precede com um novo segmento do tipo AS_SEQUENCE, incluindo nele, seu próprio ASN.

  • Se o as_path está vazio, o sistema local cria um segmento do tipo AS_SEQUENCE, e coloca nele o seu próprio ASN.

Quando um BGP que fala origina uma rota, ele inclui seu próprio ASN no segmento (do tipo AS_SEQUENCE), do as_path de todas as mensagens de UPDATE enviadas para seus pares externos. Neste caso, o ASN do BGP que fala originador é a única entrada nesse segmento e, também, esse segmento é único no as_path.

Relembramos que só estamos abordando o comportamento do atributo as_path para eBGP. Também, um recurso precioso é aquele que permite ao BGP que fala, incluir mais de uma instância do seu próprio ASN. Usaremos em breve esse recurso para ilustrar uma outra alternativa de implementar caminhos alternativos para a entrada de pacotes em ambientes multihoming.

Finalmente, o atributo as_path ajuda na prevenção de loop já que o próprio ASN do BGP que fala não pode estar presente no as_path. Há um debate interessante sobre isso em [6], gerado a partir de uma pergunta intuitiva. Vale a pena olhar.

Rota padrão em BGP

Em BGP, quando pensamos em rota padrão (default) associamos logo à tal questão de tabela completa e tabela parcial de rotas recebidas pelos BGPs que falam. Se um BGP que fala recebe tabelas de roteamente de vários pares vizinhos, isso para nós não incomoda muito, pois o ASN de cada vizinho vem no as_path do anúncio feito por ele e, portanto, como veremos podemos separá-las. Se recebemos uma tabela completa imaginamos que qualquer destino desejado pelo BGP que fala está na tabela de roteamento (FIB). Se, entretanto, o BGP que fala recebe uma tabela parcial é provavel que um destino NÂO esteja na tabela de roteamento. Então é necessário a rota padrão nesse BGP que fala, sob o risco de um pacote ser encaminhado para um buraco negro.

Quando usamos rota padrão no BGP, diversas outras questões aparecem ou devemos pensar sobre. Eis alguma delas, com pequenas avaliações:

  • Devemos anunciar a rota padrão?
    Depende da topologia. Se você possui clientes, que estabelecem BGP e não deve receber nada mais do que as rotas locais (estáticas e padrão), então a rota padrão deve ser anunciada. Esse é um caso raro em alguns ambientes e comuns em outros. Depende muito do plano de negócios.

  • Como se anuncia a rota padrão, em BGP?
    Para anunciar a rota padrão no BGP, devemos usar o comando default-originate. No Mikrotik:

     

    /routing bgp peer set par_de_destino default-originate=always
    

     

    As indicações são de que o comando default-originate não obedece aos filtros de saida do BGP. Vale lembrar disso, portanto. Recomendamos as referências [3] e [4].

  • Deve-se anunciar rotas estáticas, em BGP?
    Depende dos interesses de negócios do vizinho BGP, em questão. Usualmente, quando se anuncia uma rota padrão deseja-se anunciar as rotas estáticas.

  • Deve-se filtrar a rota padrão na entrada de anúncios de todos os pares BGP vizinhos?
    Se o BGP que fala é uma implementação normal, sem as restrições anteriores, sim! Faz parte das boas práticas filtrar a rota padrão na entrada de anúncios vindos de todos os pares vizinhos. Mesmo que se saiba que o BGP não anuncia a rota padrão por livre e espontânea vontade.

Análise final dos problemas de conectividade

Problema: MK2 não pinga a Loopback de MK6

Vamos começar a análise pelas rotas ativas de MK2. Eis a listagem, das rotas ativas e que nos interessa, obtida via o comando /ip route print where active:

 

 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.201.0.5         20           
 5 ADb  10.203.0.0/23                      10.202.0.10        20      
 6 ADb  10.204.0.0/23                      10.201.0.5         20      
 7 ADb  10.205.0.0/23                      10.201.0.5         20      
 8 ADb  10.206.0.0/23                      10.227.0.9         20      
 9 ADb  10.207.0.0/23                      10.227.0.9         20      
10 ADb  10.226.0.0/24                      10.227.0.9         20      
11 ADb  10.226.1.0/24                      10.227.0.9         20
12 ADC  10.227.0.8/30      10.227.0.10     MK7                0      

 

Há um IP estranho nas rotas 8, 9 e 12 (estática). Do bloco 10.227.0.8/30. Esse bloco faz parte de uma rota estática entre MK2 e MK7 e, portanto, somente visíveis entre os dois, já que não anunciamos as rotas estáticas (embora isso possa ser feito). Na topologia do FFE, esse bloco não existe. Houve um erro no segundo octeto do IPv4, projetado para ser usado o bloco 10.207.0.8/30, agregado ao bloco /23 do MK7. É um erro muito comum e involuntário. Geralmente é percebido logo e fácil de corrigir. A falha, contudo, pode gerar problemas de conectividade e afetar a infraestrutura da Internet. Provavelmente ao corrigí-lo, resolve-se o impasse da Tabela 1. Vamos deixar assim, por enquanto e listar as rotas de MK7, pois o ping para a Loopback do MK6 tem de passar pelo MK7 (o melhor caminho):

 

  #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.227.0.10        20      
 1 ADb  10.202.0.0/23                      10.227.0.10        20      
 2 ADb  10.203.0.0/23                      10.227.0.10        20      
 3 ADb  10.204.0.0/23                      10.227.0.10        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            
 8 ADb  10.226.0.0/24                      10.206.0.29        20      
 9 ADb  10.226.1.0/24                      10.206.0.29        20      
10 ADC  10.227.0.8/30      10.227.0.9      MK2                0        

 

A rota para o MK6 está correta, isto é, o next_hop confere com a topologia. Pela Tabela 1, MK7 não pinga MK1, MK3 e MK4. Para ambos, o melhor caminho é o MK2. Mas, os IPs do empareamento MK7 com MK2 estão errados. Os vizinhos do MK7 e MK2 não recebem a rota de 10.277.0.8/30. Vamos corrigir e ver o resultado.

 

[admin@MK2] > ping 10.206.0.1
10.206.0.1 64 byte ping: ttl=63 time=15 ms
10.206.0.1 64 byte ping: ttl=63 time=2 ms
10.206.0.1 64 byte ping: ttl=63 time=1 ms
10.206.0.1 64 byte ping: ttl=63 time<1 ms
4 packets transmitted, 4 packets received, 0% packet loss

 

MK2, agora pinga a Loopback do MK6 e os resultados dos ping a partir de MK7, mostram que a topologia tem conectividade.

 

[admin@MK7] > ping 10.201.0.1
10.201.0.1 64 byte ping: ttl=63 time=3 ms
10.201.0.1 64 byte ping: ttl=63 time=2 ms
10.201.0.1 64 byte ping: ttl=63 time<1 ms
10.201.0.1 64 byte ping: ttl=63 time=2 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/1.7/3 ms


[admin@MK7] > ping 10.203.0.1 
10.203.0.1 64 byte ping: ttl=63 time=10 ms
10.203.0.1 64 byte ping: ttl=63 time<1 ms
10.203.0.1 64 byte ping: ttl=63 time<1 ms
10.203.0.1 64 byte ping: ttl=63 time=2 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0/3.0/10 ms


[admin@MK7] > ping 10.204.0.1 
10.204.0.1 64 byte ping: ttl=62 time=14 ms
10.204.0.1 64 byte ping: ttl=62 time=1 ms
10.204.0.1 64 byte ping: ttl=62 time=1 ms
10.204.0.1 64 byte ping: ttl=62 time=1 ms
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1/4.2/14 ms

 

Próximas mudanças no FFE

Eis a movimentação já em andamento no FFE:

  • O MK3 decide que a interconexão com MK1 deve ser mantida, somente como backup, na hipótese de falha no trânsito via MK2. Portanto, não quer tráfego em nenhuma direção, sob o enlace com o MK1, enquanto o trânsito via MK2 estiver vivo.

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

  • MK7 está com uma outra questão a ser resolvida. Ele quer tráfego para/via MK2 somente para seus clientes. E deseja balancear o tráfego de trânsito entre MK2 e MK6, pois tudo está saíndo via MK2.

  • O FFE foi solicitado a abrir as portas para terceiros com vistas a exercícios de simulação. Essa é uma questão reconhecidamente complicada, mas considerada extremamente importante!

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

  2. BGP default route. Disponível em: http://wiki.nil.com/BGP_default_route. Acessado em 16/03/2011.

  3. BGP DEFAULT ROUTE. 2007. Disponível em: http://blog.ioshints.info/2007/11/bgp-default-route.html. Acessado em 16/03/2011.

  4. Cisco. Sample Configuration for BGP with Two Different Service Providers (Multihoming). Document ID: 23675. Disponível em: http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a008009456d.shtml. Acessado em 16/03/2011.

  5. RFC4451, BGP MULTI_EXIT_DISC (MED) Considerations D. McPherson, V. Gill [ March 2006 ] (TXT = 28435) (Status: INFORMATIONAL) (Stream: IETF, Area: ops, WG: grow).

  6. Networking Blog, BGP loop prevention with AS_PATH. Disponível em: http://www.networkingblog.in/bgp-loop-prevention-with-as_path-8718. Acessado em 17/03/2011.

Categorias:BGP, Mikrotik, TCP/IP

BGP no Mikrotik (IV): Anúncios e rotas no FFE

Introdução

Nessa parte, o foco é firmar a noção de anúncios, no BGP. Para isso, repetimos de uma maneira mais clara os anúncios de cada membro do FFE. A Figura 1 reproduz a topologia atual do FFE, pois será importante, ao avaliar as tabelas de anúncios de cada MKi. Antes de prosseguir, devemos lembrar que as tabelas de anúncios não são tabelas de roteamento, propriamente dita. Anúncios dão origem às rotas. Isso deve estar claro pois, como vimos, não há rota padrão (default) em nenhum MKi.

 

Figura 1: Topologia do FFE para discutir anúncios.

 

Nos itens de cada MK1 que seguem iremos discutir as questões relevantes que encontramos na tabela de anúncios. A principal referência e leitura complementar é, obrigatoriamente, [1]. Cada tabela foi obtida executanto o comando routing bgp advertisements print , no terminal do respectivo MKi. Vamos recordar o significado de cada tópico do cabeçalho lembrando que por razões didáticas as linhas estão numeradas (#) e, que o anúncio está sendo feito PELO MKi, PARA o par vizinho. Em outras palavras, o MKi está anunciando o que ele recebeu e, na oportunidade, anunciando. também, SEU prefixo.

PEER

Vizinho do empareamento PARA o qual, o anúncio está sendo feito.

PREFIX

Prefixo, no contexto do TCP/IP é o nome dado a uma faixa de endereços IP, contíguos. Como já sabemos, um prefixo é especificado por dois componentes: um endereço IP e um valor que representa quantos bits do endereço IP é relevante. No caso do MK6, por exemplo, ele anuncia dois prefixos: 10.206.0.0/23 e o 10.226.0.0/23. O 10.226.0.0/23, indica que o MK6 está anunciando os IPs : 10.226.0.0, 10.226.0.1, …, 10.226.0.255, 10.226.1.0, 10.226.1.1, …, 10.226.1.255. Vale observar que, por exemplo, o IP 10.226.1.10, faz parte do prefixo 10.226.0.0/23. Dizemos, então, que o IP 10.226.1.10 (~ ao prefixo 10.226.1.10/32) está agregado ao prefixo 10.226.0.0/23. Da mesma forma, o prefixo 10.226.0.0/24 é um agregado do 10.226.0.0/23.

Então, o IP de destino de um pacote está agregado a um prefixo anunciado ou não haverá condições de atingir o destino. Dito de outra forma, agregado a um prefixo que está presente na tabela de rotas do roteador, o qual precisa tomar a decisão para onde enviar o pacote, já que ele não lhe pertence. A noção de agregação é muito importante para entendermos tabela de roteamento, pois o BGP tem a função, também, de agregar prefixos, quando ele for encaminhar anúncios. Um ótimo exemplo, está em [2], o qual ilustramos, para o FFE, na Figura 2. Nesse caso estamos supondo que MK6 anunciou o 10.226.0.0/23 em dois prefixos 10.226.0.0/24 e 10.226.0.0/24. Como bom administrador de infraestrutura, o responsável pelo MK5, agiu corretamente e a tabela de rotas do FFE, agradece.

 

Figura 2: Agregando o anúncio do MK6 (dois /24).

Antes, eis os anúncios do MK5:

[admin@MK5] > routing bgp advertisements print
PEER     PREFIX           NEXTHOP      AS-PATH                  ORIGIN     LOCAL-PREF
MK4      10.226.0.0/24    10.204.0.22  65536                    igp       
MK4      10.226.1.0/24    10.204.0.22  65536                    igp       
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.203.0.0/23    10.205.0.25  65534,65531,65533        igp       
MK6      10.204.0.0/23    10.205.0.25  65534                    igp       
MK6      10.201.0.0/23    10.205.0.25  65534,65531             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

 

Depois:

 

[admin@MK5] > routing bgp advertisements print
PEER     PREFIX           NEXTHOP      AS-PATH                   ORIGIN     LOCAL-PREF
MK4      10.226.0.0/23    10.204.0.22  65536                     igp       
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.203.0.0/23    10.205.0.25  65534,65531,65533         igp       
MK6      10.204.0.0/23    10.205.0.25  65534                     igp       
MK6      10.201.0.0/23    10.205.0.25  65534,65531               igp       
MK6      10.226.0.0/23    10.205.0.25  65536                     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

 

Sempre falaremos sobre agregação, ao longo do texto, tamanha sua importância na tabela de rotas do BGP. A noção de agregação estende-se ao as-path, também. Por razões didáticas retornamos à posição original do FFE, sem a agregação no MK5. No momento certo falaremos sobre o fato de ter havido a agregação no MK5 mas sem ter feito isso no MK7.

Prefixos são muito usados em filtros. Existem muitas formas de filtros, no BGP. Acima vimos uma delas, ao usarmos agregação no MK5. Outra forma de filtro envolvendo prefixos é um atributo do BGP chamado Max Prefix Limit. Pouco usado, mas muito útil em relação à perspectiva de estancar, automaticamente, uma falha inesperada, vinda de algum parceiro de BGP. A Figura 3, onde o MK6 resolve cancelar o empareamento com MK5, se ele ultrapassar o anúncio de 3 prefixos. Como o MK5 envia mais do que 3 prefixos, o estado do BGP passa a idle, imediatamente.

 

Figura 3: MK6 bloqueando seu vizinho de BGP por anunciar mais do que 3 prefixos.

NEXHOP

Se refere ao atributo next_hop, do BGP. Cada vez que o MKi anuncia um prefixo para um empareado (peer), o atributo next_hop (próximo salto, vizinho de destino ou próximo endereço de destino) é alterado para o endereço do roteador de borda que anunciou esse prefixo. Esse IP é a rota que indica para onde devem ser encaminhados os pacotes que fazem referência a algum IP contido no prefixo anunciado.

Compare os item 1 das Tabelas 1 e 2, observando a mudança do next_hop.

O next_hop nos faz lembrar de uma limitação muito grande do BGP. Limitação de projeto e que deu origem às bases IRR, e atualmente, em debates o RPKI. O BGP somente consegue se entender com seus vizinhos imediatos. No exemplo final do tópico sobre prefixos, somente para ilustrar, o MK6 não consegue usar o Max Limit Prefix, contra o MK1, pois este não é seu vizinho de BGP.

 

AS-PATH

O as_path é realmente complexo, como já foi dito. É uma opinião geral e reflete a sabedoria das multidões que lidam com BGP. Em [3], na Introdução podemos ler, em uma tradução livre, desse autor: “… Idealmente, como um protocolo, deveria haver uma sólida compreensão sobre o comportamento do BGP, sua estabilidade, sua resposta a falhas e vulnerabilidades a ataques. Mas, na prática, a infraestrutura do BGP representa um sistema de grande porte e exibe comportamentos complexos sob diversas condições. Portanto, compreender o comportamento dinâmico do BGP, continua sendo um desafio aberto. …”. Existem muitos outros tabalhos sobre as_path e de como o BGP trata esse atributo. Ele é um dos mais importantes atributos e merece ser apreciado no limite de nossa capacidade de estudar e aprender. Como, nesse texto, a abordagem sobre as-path é curta, então, não se pode esgotar por aqui.

Alguns atributos do BGP possuem a propriedade da transitividade. Esta propriedade indica que se o atributo é transmitido (enviado) através de uma mensagem UPDATE, mas não reconhecida pelo receptor, então ela pode ser enviada para o próximo AS, na sequência do as_path. Dois outros atributos do BGP possuem essa mesma propriedade: agregação e comunidades. Já o as_path é um atributo mandatório, no BGP, isto é, um atributo que segue sempre para os vizinhos, vizinhos de vizinhos, com algumas alterações. Classificam-se, também, como mandatórios, os atributos next_hop e origin.

O as_path é uma lista de números de ASes especificando o caminho que deverá ser seguido para que um pacote atinja seu destino. As rotas, algumas derivadas dos anúncios são armazenadas na RIB (a tabela de rotas de um roteador). O roteador, ao enviar um anúncio, adiciona o seu ASN, no inicio do as_path (à esquerda). Como os anúncios passam de um roteador para outro é fácil perceber que o as_path cresce em cada etapa, isto é, em cada next_hop. E pode ficar muito grande, o as_path

Vamos ver exemplos. A Tabela 1, dos anúncios feitos pelo MK1, para cada vizinho de BGP, mostra o anúncio de seus próprios prefixos (linhas 7, 10 e 17). Como tais prefixos pertencem ao MK1, não há nenhum caminho a ser seguido. Agora, vamos à Tabela 2, do MK2. Na linha 3 está o anúncio que o MK2 faz ao MK3, por força do anúncio recebido de MK1.

Na realidade, o as_path é codificado como uma sequência de segmentos de as_path. Cada segmento é caracterizado por: “tipo” (veja abaixo, seu significado), “comprimento” (número de ASes do segmento) e “valor” (lista de ASNs). O “tipo” do segmento é um campo octeto que contem dois possíveis valores: AS-SET (contendo um conjunto não ordenado de ASNs) e o AS-SEQUENCE (contendo um conjunto ordenado de ASNs). O objetivo do AS-SET é suportar a agregação de rotas identificadas por as_path diferentes. Stewart, em [4], página 46 exibe um exemplo interessante: imagine que um roteador anuncie 138.39.0.0/17, com o as_path, “100 200 15”, e um outro roteador anuncie 138.39.128.0/17, com as_path “47 200 15”, e que este roteador precise anunciar um agregado 138.39.0.0/16. Por serem os as_path, diferentes o as_path do agregado será “[100, 47] 200 15”, onde “[100, 47]” é um AS-SET e o “200 15” é um AS-SEQUENCE.

ORIGIN

Se refere ao atributo origin e indica onde o BGP aprendeu um determinado anúncio, através de três possíveis valores:

  • igp: Indica que o anúncio tem origem no interior de um AS. Esse atributo aparece quando incluímos o prefixo a ser anunciado, no Routing, BGP, Network. Foi isso que fizemos em cada MKi do FFE. O resultado pode ser visto em todas as Tabelas apresentadas.
  • egp: A rota é aprendida via o eBGP. Faremos uma abordagem sobre esse valor do atributo origin em outro momento, já que o atributo origin em nossos exemplos, são anunciados via Networks.
  • incomplete: A origem do anúncio/rota é desconhecida ou aprendido de uma outra forma, que não as duas anteriores. Geralmente ocorre quando há uma redistribuição de rota dentro do BGP. Veremos isso mais à frente.

LOCAL-PREF

Se refere ao atributo local_pref e tem o valor padrão 100. É um atributo que se caracteriza por não ser propagado para outros roteadores que não pertençam a um mesmo AS (em outras palavras, que não sejam iBGP). A política de roteamento dos roteadores do iBGP é a de priorizar a rota com o maior valor de local_pref. A topologia (ou configuração) do FFE não possui nenhuma interconexão iBGP, ainda, pois todos os ASNs são diferentes.

MK1

as-path prepend;

O MK1 é o principal operador do FFE. Tem a maior tabela de rotas, além de ser o único fornecedor de trânsito. Embora não apareça, já falamos que MK1 recebe todos os anúncios da Internet e distribui para seus clientes de trânsito, dentro do FFE. Estamos, para facilitar nossa vida, abstraindo-nos desses anúncios que vem da Internet.

# PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
1 MK2 10.203.0.0/23 10.201.0.5 65533 igp
2 MK2 10.206.0.0/23 10.201.0.5 65534,65535,65536 igp
3 MK2 10.205.0.0/23 10.201.0.5 65534,65535 igp
4 MK2 10.207.0.0/23 10.201.0.5 65534,65535,65536,65537 igp
5 MK2 10.226.0.0/23 10.201.0.5 65534,65535,65536 igp
6 MK2 10.204.0.0/23 10.201.0.5 65534 igp
7 MK2 10.201.0.0/23 10.201.0.5 igp

8 MK4 10.203.0.0/23 10.201.0.17 65533 igp
9 MK4 10.202.0.0/23 10.201.0.17 65532 igp
10 MK4 10.201.0.0/23 10.201.0.17 igp

11 MK3 10.206.0.0/23 10.201.0.18 65534,65535,65536 igp
12 MK3 10.205.0.0/23 10.201.0.18 65534,65535 igp
13 MK3 10.202.0.0/23 10.201.0.6 65532 igp
14 MK3 10.207.0.0/23 10.201.0.18 65534,65535,65536,65537 igp
15 MK3 10.226.0.0/23 10.201.0.18 65534,65535,65536 igp
16 MK3 10.204.0.0/23 10.201.0.18 65534 igp
17 MK3 10.201.0.0/23 10.201.0.13 igp

Tabela 1. Prefixos anunciados pelo MK1

 

É interessante comparar a tabela de anúncios, gerada por routing bgp advertisements print e a tabela de rotas, produzida pelo comando ip route print, apresentado abaixo, com uma diferença de que em Networks do MK6 estão os dois blocos do /24, mantidos por interesse didático:


[admin@MK1] > ip route print                        
Flags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADC  10.201.0.1/32      10.201.0.1      LoopBack-MK3       0       
 1 ADC  10.201.0.4/30      10.201.0.5      MK2                0       
 2 ADC  10.201.0.12/30     10.201.0.13     MK3                0       
 3 ADC  10.201.0.16/30     10.201.0.17     MK4                0       
 4 ADC  10.201.1.0/24      10.201.1.1      LAN                0       
 5 ADb  10.202.0.0/23                      10.201.0.6         20      
 6  Db  10.202.0.0/23                      10.202.0.9         20      
 7 ADb  10.203.0.0/23                      10.201.0.14        20      
 8  Db  10.203.0.0/23                      10.201.0.6         20      
 9 ADb  10.204.0.0/23                      10.201.0.18        20      
10 ADb  10.205.0.0/23                      10.201.0.18        20      
11 ADb  10.206.0.0/23                      10.201.0.18        20      
12 ADb  10.207.0.0/23                      10.201.0.18        20      
13 ADb  10.226.0.0/24                      10.201.0.18        20      
14 ADb  10.226.1.0/24                      10.201.0.18        20

Na tabela de rotas acima, temos um total de 15 rotas. Destas 15 rotas, somente 10 foram produzidas a partir dos 17 anúncios que o MK1 faz para seus diversos vizinhos (e que foram anunciados pelos seus vizinhos, também …). Se usarmos o recurso de agregação no MK6, como foi mostrado acima, economizaríamos mais 1 rota. Certo?

MK2

Observando a tabela abaixo, a qual mostra o MK2 anunciando para seus vizinhos MK1 e MK2, o anúncio do bloco gerado internamente ao MK1 não é anunciado para ele. Nem o bloco do MK3. Esse bom comportamento do BGP será lembrado mais na frente, quando falarmos de filtros, pois há uma recomendação de boas práticas, na voz do povo, de que se deve filtrar o seu próprio bloco. Veremos, se é necessário. Em tese, olhando todas as tabelas, não há necessidade desse filtro.

# PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
1 MK1 10.203.0.0/23 10.201.0.6 65533 igp
2 MK1 10.202.0.0/23 10.201.0.6 igp

3 MK3 10.201.0.0/23 10.202.0.9 65531 igp
4 MK3 10.206.0.0/23 10.201.0.5 65531,65534,65535,65536 igp
5 MK3 10.204.0.0/23 10.202.0.9 65531,65534 igp
6 MK3 10.207.0.0/23 10.202.0.9 65531,65534,65535,65536,65537 igp
7 MK3 10.226.0.0/23 10.202.0.9 65531,65534,65535,65536 igp
8 MK3 10.205.0.0/23 10.202.0.9 65531,65534,65535 igp
9 MK3 10.202.0.0/23 10.202.0.9 igp

Tabela 2. Prefixos anunciados pelo MK2

 

MK3

Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.

# PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
1 MK1 10.205.0.0/23 10.202.0.9 65532,65531,65534,65535 igp
2 MK1 10.207.0.0/23 10.202.0.9 65532,65531,65534,65535,65536,65537 igp
3 MK1 10.226.0.0/23 10.202.0.9 65532,65531,65534,65535,65536 igp
4 MK1 10.204.0.0/23 10.202.0.9 65532,65531,65534 igp
5 MK1 10.206.0.0/23 10.202.0.9 65532,65531,65534,65535,65536 igp
6 MK1 10.203.0.0/23 10.201.0.14 igp

7 MK2 10.201.0.0/23 10.202.0.10 65531 igp
8 MK2 10.203.0.0/23 10.202.0.10 65531,65534,65535 igp

Tabela 3. Prefixos anunciados pelo MK3

 

MK4

Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.

# PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
1 MK1 10.206.0.0/23 10.201.0.18 65535,65536 igp
2 MK1 10.205.0.0/23 10.201.0.18 65535 igp
3 MK1 10.207.0.0/23 10.201.0.18 65535,65536,65537 igp
4 MK1 10.226.0.0/23 10.201.0.18 65535,65536 igp
5 MK1 10.204.0.0/23 10.201.0.18 igp

6 MK5 10.201.0.0/23 10.204.0.21 65531 igp
7 MK5 10.202.0.0/23 10.204.0.21 65531,65532 igp
8 MK5 10.203.0.0/23 10.204.0.21 65531,65533 igp
9 MK5 10.204.0.0/23 10.204.0.21 igp

Tabela 4. Prefixos anunciados pelo MK4

 

MK5

Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.

# PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
1 MK4 10.206.0.0/23 10.204.0.22 65536 igp
2 MK4 10.226.0.0/23 10.204.0.22 65536 igp
3 MK4 10.207.0.0/23 10.204.0.22 65536,65537 igp
4 MK4 10.205.0.0/23 10.204.0.22 igp

5 MK6 10.203.0.0/23 10.205.0.25 65534,65531,65533 igp
6 MK6 10.202.0.0/23 10.205.0.25 65534,65531,65532 igp
7 MK6 10.204.0.0/23 10.205.0.25 65534 igp
8 MK6 10.201.0.0/23 10.205.0.25 65534,65531 igp
9 MK6 10.205.0.0/23 10.205.0.25 igp

Tabela 5. Prefixos anunciados pelo MK5

 

MK6

Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.

# PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
1 MK5 10.207.0.0/23 10.205.0.26 65537 igp
2 MK5 10.206.0.0/23 10.205.0.26 igp
3 MK5 10.226.0.0/23 10.205.0.26 igp

4 MK7 10.203.0.0/23 10.206.0.29 65535,65534,65531,65533 igp
5 MK7 10.205.0.0/23 10.206.0.29 65535 igp
6 MK7 10.202.0.0/23 10.206.0.29 65535,65534,65531,65532 igp
7 MK7 10.204.0.0/23 10.206.0.29 65535,65534 igp
8 MK7 10.201.0.0/23 10.206.0.29 65535,65534,65531 igp
9 MK7 10.206.0.0/23 10.206.0.29 igp
10 MK7 10.226.0.0/23 10.206.0.29 65534,65531 igp

Tabela 6. Prefixos anunciados pelo MK6

 

MK7

Há uma experiência que gostaríamos de acrescentar ao MK7. Vamos supor que haja um interesse especial do MK7 sobre a rede interna de MK2 que tem uma conexão direta com MK1 e MK3, para os quais MK7 tem de percorrer um longo caminho.

 

# PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
1 MK6 10.207.0.0/23 10.206.0.30 igp

Tabela 7. Prefixos anunciados pelo MK7

 

MK7 fala com MK2 e tudo fica acertado. MK7 reserva o bloco 10.207.0.8/32 para um empareamento BGP com MK2, informando-lhe que coloque o IP 10.207.0.10 na sua interface do BGP com o AS65537. Então, nosso diagrama da nova topologia do FFE ficará como a Figura 4.

 

Figura 4: Topologia do FFE com o empareamento acordado entre MK7 e MK3.

 

As repectivas tabelas de anúncios (sem as colunas ORIGIN e LOCAL-PREF) e as tabelas de roteamento, todas atualizadas em 14/03/2011 às 22:46 podem ser vistas aqui! É bom pensar que a topologia do FFE, muito pequena, torna visível dois laços de anúncios, ambos a partir de MK1, onde o primeiro é: MK1 -> MK4 -> MK5 -> MK6 -> MK7 -> MK2 -> MK1 (retornando) e o outro: MK1 -> MK2 -> MK3 -> MK1. Ambos podem ser qualificados, também, de forma inversa …

 

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

  2. BGP Case Studies. Disponível em: http://wiki.mikrotik.com/wiki/Manual:BGP_Case_Studies. Acessado em 10/03/2011.

  3. Xiaoliang Zhao , Beichuan Zhang , Dan Massey , Lixia Zhang, A Study on BGP AS Path Characteristics. Disponível em: http://www.cs.colostate.edu/~massey/pubs/tr/massey_usctr04-818.pdf. Acessado em 10/03/2011.

  4. John W. Stewart III. BGP4: Inter-Domain Routing in the Internet. Addison-Wesley, 1999.
Categorias:BGP, Mikrotik, TCP/IP

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

BGP em Mikrotik – Parte I

The best way to have a good idea is to have lots of ideas.
Linus Pauling

Atualizado em 17/07/2011

Introdução

 

Este assunto será dividido em várias partes. Antes das próximas partes será necessário falar sobre outros recursos do BGP. Por exemplo, na Parte III a abordagem é sobre Filtros em BGP. Não seria oportuno falar sobre filtros, sem antes apresentar Comunidades em BGP. O foco, tanto da Parte I como da Parte II é a implementação do BGP em Mikrotik. Ela pretende facilitar a implementação do BGP e para isto será usada uma topologia que evoluirá do simples, para o complexo.

A topologia será construida sobre o FFE. Para quem não se lembra, FFE = [1111 1111 1110] => Fábrica Fictícia de Encaminhamento ~ LVR => Laboratório Virtual de Roteamento, apresentado há algum tempo aqui nesse blogue. O modelo supõe a existência de um fornecedor de trânsito (operadora), o MK1 ou AS65531 (representado na Figura 1), que se supõe seja detentor de um bom pedaço do bloco 10.0.0.0/8 (bloco preferido do FFE). Nos outros textos que seguirão, o MK1 ou outro membro qualquer do FFE será fornecedor de tráfego de transporte. Oportunamente serão acrescentaados PTTs, que irão fornecer tráfego de “peering” em acordos multilaterais, e tráfego de trânsito, ou outro qualquer, em acordos bilaterais. O que será útil para ampliar a perspectiva, ou aplicabilidade, do protocolo BGP.

 

Figura 1: O ávido fornecedor de trânsito.

 

Adicionando o MK2 no FFE

 

O MK2 (AS65532) está interessado em trânsito e combina as condições comerciais com MK1. Via de regra isto é feito juntamente com um formulário padrão que o MK1 envia ao MK2, para ser preenchido. Negócio fechado, MK1 reserva o bloco 10.201.0.4/30 para a interconexão com o MK2, cujas interfaces estão ilustradas na Figura 2, abaixo.

 

Figura 2: Ilustração do esquema atual de trânsito do MK1.

 

Preparando o MK1 para o MK2 e vice versa

 

O MK2 ou AS65532 é detentor (escolha arbitrária!), do bloco 10.202.0.0/23, que pode ser dividido nos dois blocos 10.202.0.0/24 e 10.202.1.0/24. Tendo tais informações, o próximo passo é ajustar os dados em Routing, BGP, Instance, como mostra a Figura 3, para o MK1 e MK2. Altera-se o AS e Router ID, nos respectivos roteadores.

 

Figura 3: Ajustando a instância em cada um dos pares (MK1 e MK2).

 

As escolhas do Router ID, também são arbitrárias. É comum usar um dos IPs das interfaces do respectivo MK em questão, como por exemplo, o IP da interface que está dando origem ao BGP. Preferencialmente, entretanto, a escolha deve ser um IP de interface, que seja parte do bloco do respectivo AS. O próximo passo está na Figura 4, que exibe as modificações feitas. Tais modificações foram:

 

  • Name: Identificamos o par remoto do BGP (arbitrário).
  • Remote Address: O IP do par remoto. No caso, os IPs das respectivas interfaces, provenientes do bloco separado pelo MK1.
  • Remote AS: O ASN (ou número do AS) do respectivo par remoto.

 

Figura 4: Implementando o BGP entre MK1 e MK2.

 

Ao clicar em OK, o BGP dos pares começam a ser relacionar resultando no estado established.

 

Figura 5: BGP funcionando entre o MK1 e MK2.

 

Nesse momento, sabemos que há um relacionamento entre MK1 e MK2 através do protocolo BGP. Mas está faltando a informação sobre quem deve anunciar o quê. O MK1 é o trânsito, logo ele deve anunciar para MK2, toda a tabela de rotas da Internet, mais o bloco de IPs que ela detem. O MK2 deve anunciar para MK1 os blocos IPs que ela detem, para que o MK1 repasse para a Internet e a Internet saiba qual o caminho que deve seguir para chegar até MK2. Vejamos como resolver o problema do lado do MK2. Anunciamos o bloco de MK2 colocando, ainda em BGP, Network, o bloco desejado. A Figura 6 mostra como fazemos isso no MK2 e como fazemos o mesmo para que MK1 anuncie seus blocos para MK2 (que é da mesma maneira).

 

Figura 6: Anunciando respectivos blocos entre os membros (MK1 e MK2) do empareamento BGP.

 

No MK1, em New Terminal, eis o resultado de dois comandos importantes, que diz o quê o MK1 está anunciando e o quê ele está recebendo do MK2:

 

[admin@MK1] > routing bgp advertisements print
PEER     PREFIX               NEXTHOP          AS-PATH    ORIGIN     LOCAL-PREF
MK2      10.201.0.0/23        10.201.0.5                  igp 
      
[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      

 

O mesmo pode ser feito no MK2. Vejamos abaixo:

[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=MK1 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADb  10.201.0.0/23                      10.201.0.5         20      

 

Com os testes acima pode-se afirmar que o BGP entre MK1 e MK2 está funcionando, adequadamente. Uma dúvida entretanto surge, quando se observa os anúncios que chegam do MK1 para MK2. Onde estão os anúncios das rotas da Internet? Ah! Bem lembrado. Por enquanto justifica-se que a ausência delas está associada ao fato de que o FFE é experimental. Ele NÃO está na Internet! Por isso, o que pode ser dito é que o anúncios de tabelas de rotas da Internet, um pouco mais pela frente. Por hora basta acreditar que o MK1 anuncia tudo o que ele recebe, para o MK2.

 

Adicionando o MK3 no FFE

 

O MK3, que já possui uma conexão experimental, estática, com MK2 ficou sabendo que MK2 já estava na Internet. Então, o MK3 pede ao MK2 que lhe venda trânsito. E se entendem neste sentido. MK3, também é um AS. Seu ASN é o 65533 e possui o bloco 10.203.0.0/23. Assim, o FFE fica como a topologia, mostrada na Figura 7.

 

Figura 7: Entrada do MK3 na Internet via trânsito oferecido pelo MK2.

 

Vejam que MK2 forneceu o bloco 10.202.0.4/30, para efetivar a conexão. O esquema é o mesmo que foi implementado no MK1 e MK2. Eis as etapas:

 

  • MK2 inclui um Peer, com o ASN de MK3 e o IP remoto 10.202.0.6/30.
  • MK3 inclui um Peer com o ASN de MK2 e o IP remoto 10.202.0.5/30.
  • MK3 inclui seu bloco em Network, o que já tinha feito!

 

Pronto! MK3 está na Internet via MK2 que tem trânsito via MK1. Os respectivos blocos estão sendo anunciados. O que MK2 recebe de anúncio do MK3, passo diretamente para MK1. Pode-se ver isto, através do Terminal, para cada um deles.

Abaixo, os testes para o MK3. Veja o que ele anuncia para MK3 e o que recebe do 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                  igp
       
[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      

 

A seguir, os testes para o MK2. Ele tem duas conexões. Não há nenhuma restrição (aka, filtro) que impeça ele anunciar tudo que recebe para o MK1:

 

[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       
MK3    10.201.0.0/23        10.202.0.5       65531      igp       
MK3    10.202.0.0/23        10.202.0.5                  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      

 

Agora, os testes para o MK1. Veja que ele está recebendo o bloco do MK3

 

[admin@MK1] > routing bgp advertisements print      
PEER     PREFIX               NEXTHOP          AS-PATH                          ORIGIN     LOCAL-PRE
MK2      10.201.0.0/23        10.201.0.5                                        igp 
      
[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       

 

Observações complementares

 

Há algumas questões que devem ser levantadas. Por exemplo, não usamos rota default, em nenhum momento. Insistentemente e, para efeitos didáticos, não usamos e nem falamos sobre filtros, o que nos induz a imaginar a necessidade de não colocar as implementações acima em produção, sem que se tenha o conhecimento adequado. Contudo, em uma implementação com um só operador de trânsito, isso não importará muito e não precismos ter medo de implementá-las. BGP é um protocolo muito poderoso e versátil. Foi feito para relacionar com pelo menos com um vizinho. A exigência de se dar um AS para somente quem tem no mínimo duas conexões de trânsito com operadoras diferentes, não tem nada a ver com BGP.

Todos os MKs do FFE estão com a versão R5.0rc10. Candidatos ao release 5, antereriores ao rc10, não funcionam. A razão de estar usando essa versão é pela necessidade de usar o IPv6 nos próximos textos. Entretanto, não se pode sentir firmeza com o Mikrotik, infelizmente. O que ele tem de bom nas facilidades tem de mau na confiabilidade. Mas não há dúvida que o Mikrotik, como roteador é a grande vedete brasileira. Provavelmente, os brasileiros são mais corajosos do que o resto do mundo. Talvez forçados pelas restrições ou imposições oficiais sobre nosso mercado. Ahn!

A referência [1] é uma ótima leitura para o que virá, apesar de ser um documento da Cisco. Na Internet, encontra-se muita informação. Boa e ruim. Naturalmente, as questões postas pelos leitores podem ajudar nas atualizações dessa parte e auxiliará em muito durante o desenvolvimento das outras partes do assunto.

Finalmente, nota-se que o BGP não um protocolo fácil, no conjunto de todos seus recursos e na diversidade das topologias encontradas na Internet. BGP é difícil e dá trabalho para manter. Exige estudo intensivo e aprendizagem constante. Ele é um protocolo mais propício a mudanças do que uma lingua natural, como o Português.

 

Assuntos relacionados, neste blogue

 

  1. BGP no Mikrotik: Dois operadores de trânsito. Versão anterior a este artigo.
  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)

 

Referências

 

  1. Cisco, BGP Case Studies. Disponível aqui: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml#BGPloopbackinter. Acessado em 07/03/2011.
Categorias:BGP, Mikrotik, TCP/IP