Início > BGP, Mikrotik, TCP/IP > BGP no Mikrotik (IV): Anúncios e rotas no FFE

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

Deixe uma resposta

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s