Início
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.
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.
Antes, eis os anúncios do MK5:
Depois:
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.
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.
ORIGIN
Se refere ao atributo origin e indica onde o BGP aprendeu um determinado anúncio, através de três possíveis valores:
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
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.
É 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:
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.
MK3
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
MK4
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
MK5
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
MK6
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
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.
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.
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 …
Fonte: http://juliaobraga.wordpress.com/2011/03/11/bgp-no-mikrotik-iv-anuncios-e-rotas-no-ffe/
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.
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.
Antes, eis os anúncios do MK5:
- Código:
[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:
- Código:
[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.
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.
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
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.
É 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:
- Código:
[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.
MK3
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
MK4
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
MK5
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
MK6
Nenhum comentário, exceto o de analizar a tabela sob os comentários feitos para MK1 e MK2.
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.
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.
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 …
Fonte: http://juliaobraga.wordpress.com/2011/03/11/bgp-no-mikrotik-iv-anuncios-e-rotas-no-ffe/
