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.

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.

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

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

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.

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