BGP no Mikrotik: Dois operadores de trânsito (Visão genérica)
“Sistematicamente, evito colocar meu pensamento na Religião
quando trato de Ciência,
assim como o faço em relação à moral,
quando trato de assuntos referentes à Sociedade.
Charles Darwin: A Origem das Espécies
(último parágrafo).
Últimas atualizações:
22/08/2011 19:33 => Descrição sumária do modelo.
22/08/2011 17:21 => Nova figura 1. Modelo mais completo.
22/08/2011 12:27 => Processo de decisão do BGP (refinamento).
Um modelo mais genérico no FFE para dois operadores de trânsito.
O artigo anterior, sobre o mesmo assunto (dois provedores de trânsito), não foi escrito de forma genérica para permitir diversos exercícios sobre a complexidade do BGP. À medida que este for evoluindo, o antigo desaparecerá, já que perderá o sentido. Eis nosso modelo, na Figura 1. Na sequência o uso do VMWare é mostrado com detalhes suficientes para se assegurar a independência das máquinas virtuais.
Figura 1. Modelo genério para dois servidores de trânsito
Sumário descritivo do modelo.
A seguir, algumas informações descritivas do modelo da Figura 1.
- O AS65533 é o Mikrotik virtual, representado por Internet é aquele que dará “acesso” à Internet. Na prática isto não acontecerá, mas os IPs dentro do bloco 10.33.0.0/19 representarão a Internet. Se necessário iremos divulgar outras redes para dentro do modelo.
- O AS65531 é o primeiro fornecedor de trânsito para o Provedor, reconhecido como Transito1.
- O AS65532 é o segundo fornecedor de trânsito para o Provedor, reconhecido como Transito2.
- O AS65530 é o Provedor, proprieamente dito, cuja rede local só possui o Notebook. O Notebook tem acesso direto ao Mikrotik Provedor e somente terá acesso aos outros Mikrotiks virtuais através do BGP que fala do Provedor.
- Em casos especiais, já que as máqinas virtuais estão instaladas no Notebook será permitido o acesso a todos os Mikrotiks virtuais, através do console do VMWare, descrito logo abaixo. Até o momento e salvo dito ao contrário, o único acesso foi feito no início, para instalação dos IPs das interfaces de cada um e respectivo BGP. O objetivo sempre será o de preservar o modelo, contra interferências externas sobre a rede construida e, assim, sua integridade funcional.
- Em preto, os IPs das respectivas interfaces, compatíveis com os anúncios de cada Mikrotik virtual (em vermelho).
- Na configuração inicial não há rota padrão no ambiente e nem, tampouco, filtros. A ausência de rota padrão somente permite acessibilidade aos IPs anunciados (e, utilizados…). Com isso a simulação de TODA a Internet no AS65533, está prejudicada, nesse momento. O espírito didático do modelo permitirá que isto esteja completo no momento oportuno. Entretanto, nada impede que se pense como será feito…
- Uma consideração importante que vale a pena antecipar é o fato de que, apesar da ausência de filtros, cada AS não recebe seu próprio anúncio de qualquer BGP que fala empareado a ele. Isto é uma característica do próprio BGP, como forma de garantir a ausência de laços infinitos (“loop”).
O modelo do FFE e o VMWare
Sabe-se que o FFE é construído sob o VMWare. A estrutura do VMWare nos oferce o conceito de switches virtuais. A Figura 2, obtida de [2] – página 3 – exibe o modelo conceitual de switches virtuais, no VMWare.
Figura 2. Switches virtuais no VMWare
A Figura 3 exibe o “console” do VMWare quando se agrupam as 4 máquinas virtuais do modelo em um “team”. É através do console que se tem acesso inicialmente aos respectivos Mikrotiks que preenchem o modelo da Figura 1.
Figura 3 - Console do VMWare quando agrupamos as 4 máquinas virtuais.
Da descrição detalhada, no documento [2] é suficiente lembar que os switches virtuais trabalham na Camada 2 e são invioláveis em relação a eventuais tentativas de compartilhamento, uma vez que para cada placa de rede virtual (de cada máquina virtual) associamos um único switch virtual. A tabela abaixo exibe a associação unívoca, de cada umas das três placas de rede (interfaces 0, 1 e 2), disponíveis em cada máquina virtual (MV, e o ASN), com um dos 8 switches criados para o modelo do FFE, da Figura 1:
| Switch 0 | Switch 1 | Switch 2 | Switch 3 | Switch 4 | Switch 5 | Switch 6 | Switch 7 | |
| MV 65530 | LAN (0) | Transito1 (1) | Transito2 (2) | — | — | — | — | — |
| MV 65531 | — | Provedor (1) | — | Internet (2) | LAN (0) | — | — | — |
| MV 65532 | — | — | Provedor (1) | — | — | Internet (2) | LAN (0) | — |
| MV 65533 | — | — | — | Transito1 (1) | — | Transito2 (2) | — | Internet (0) |
Tabela 1. Switches virtuais e respectivas associações aos membros do FFE.
As figuras 4 e 5, abaixo mostram, respectivamente, as interfaces (virtuais) do Notebook e as rotas do Notebook.
Figura 4 - Interfaces virtuais, criadas no Notebook.
Figura 5 - Rotas do Notebook, após alterações.
Na Figura 4 vê-se que somente as interfaces da rede local e “VMnet0” estão ativas. Na Figura 5, retirou-se a rota padrão para “VMnet0”, estabelecida automaticamente pelo Windows e acrescentou-se a rota 10.0.0.0/8 para a interface da LAN do Provedor. De ambas, pode-se concluir que a Rede Local do Notebook não é compartilhada com as máquinas virtuais, já que ela é a saída para a Internet via NAT.
O processo de decisão do BGP
Eis uma relação, praticamente completa, que ilustra o comportamento do mecanismo de decisão do BGP.
- Não considere como sendo caminho (“path”), se não há rota para o próximo caminho. Em outras palavras, selecione somente as rotas cujo “next_hop” seja atingível.
- Maior valor de “Weight”. O valor padrão do “Weight” é zero. Embora seja um parâmetro da Cisco, já está implementado no Mikrotik.
- Maior valor no “Local Preference”, cujo padrão é 100.
- Rotas geradas localmente sendo que as rotas geradas localmente pelo próprio BGP têm a preferência.
- Rota com menor ORIGIN, na ordem: IGP, EGP e INCOMPLETE.
- Rota com o menor MED (“Multiple Exit Discriminator”).
- Preferência por rotas geradas por eBGP, sobre rotas recebidas por iBGP.
- Caminho com menor custo IGP para o “next_hop”.
- Para caminhos eBGP: (a) se o “multipath” está habilidtado, instala n caminhos paralelos na tabela de encaminhamento; (b) se o “router-id” é o mesmo, vá para a próxima alternativa; (c) se o “router-id” não é o mesmo, selecione o caminho mais antigo.
- Rota com o caminho cujo empareado tiver menor “router_id” (“originator-id” para rotas refletidas).
- Menor “cluster-list”. Atenção aos atributos de “Route Reflector”.
- Menor endereço de vizinhança se o “router_id” for o mesmo.
Após o processo acima terminar, uma rota somente é colocada na tabela de rotas se não há outra rota com prefixo maior ou com distância administrava melhor. A decisão relacionada com o prefixo maior, leva muitos administradores a desagregar anúncios como “lei do menor esforço” no sentido de estabelecer prioridades de rotas. Esta ação agride frontalmente as preocupações de agregação, que reduziriam a tabela de roteamento, entre outras questões já abordadas. Um exemplo é a facilidade em induzir rotas ping-pong, afetando drasticamente a convergência do BGP.
O item em negrito na relação acima, justificará porque o tráfego que vai e volta para a Internet considera o operador Transito1, na implementação sem filtro.
Pelo que se observa, o BGP que fala sempre estabelecerá um único caminho para uma rota (o melhor!!). É uma característica, inerente ao comportamento do BGP. Assim ele foi projetado. Pergunta 1: é possível fazer balanceamento, com o BGP? Pergunta 2: é possível fazer distribuição de tráfego, no BGP? Se sim, qual seria o conflito com as melhores práticas e recomendações gerais da comunidade?
Comportamento do modelo
As Tabelas 2, 3 e 4 exibem as configurações implementadas em cada um dos Mikrotiks virtuais, nos quais não foram usados nenhum filtro.
| Máquina Virtual | Interface | IP Address |
| Provedor | 0 R S0_LAN 1 R S1_Transito1 2 R S2_Transito2 |
0 10.1.0.2/30 10.1.0.0 S1_Transito1 1 10.0.0.1/30 10.0.0.0 S0_LAN 2 10.2.0.2/30 10.2.0.0 S2_Transito2 |
| Transito1 | 0 R S1_Provedor 1 R S3_Internet 2 R S4_LAN |
0 10.1.0.1/30 10.1.0.0 S1_Provedor 1 10.33.1.2/30 10.33.1.0 S3_Internet |
| Transito2 | 0 R S2_Provedor 1 R S5_Internet 2 R S6_LAN |
0 10.2.0.1/30 10.2.0.0 S2_Provedor 1 10.33.2.2/30 10.33.2.0 S5_Internet |
| Internet | 0 R S3_Transito1 1 R S5_Transito2 2 R S7_LAN |
0 10.33.1.1/30 10.33.1.0 S3_Transito1 1 10.33.2.1/30 10.33.2.0 S5_Transito2 |
Tabela 2. Interfaces e respectivos IPs, de cada componente.
| MVirtual | Instância | Peer | Network | Anúncios |
| Provedor | name=”default” as=65530 router-id=10.0.0.1 |
0 E default 10.1.0.1 65531 1 E default 10.2.0.1 65532 |
0 10.0.0.0/19 no |
T1 10.2.0.0/19 10.1.0.2 65532 igp T1 10.0.0.0/19 10.1.0.2 igp T2 10.33.0.0/19 10.2.0.2 65531,65533 igp T2 10.1.0.0/19 10.2.0.2 65531 igp T2 10.0.0.0/19 10.2.0.2 igp |
| Transito1 | name=”default” as=65531 router-id=10.1.0.1 |
0 E default 10.33.1.1 65533 1 E default 10.1.0.2 65530 |
0 10.1.0.0/19 no |
I 10.0.0.0/19 10.33.1.2 65530 igp I 10.2.0.0/19 10.33.1.2 65530,65532 igp I 10.1.0.0/19 10.33.1.2 igp P 10.33.0.0/19 10.1.0.1 65533 igp P 10.1.0.0/19 10.1.0.1 igp |
| Transito2 | name=”default” as=65532 router-id=10.2.0.1 |
0 E default 10.2.0.2 65530 1 E default 10.33.2.1 65533 |
0 10.2.0.0/19 no |
P 10.33.0.0/19 10.2.0.1 65533 igp P 10.2.0.0/19 10.2.0.1 igp I 10.1.0.0/19 10.33.2.2 65530,65531 igp I 10.0.0.0/19 10.33.2.2 65530 igp I 10.2.0.0/19 10.33.2.2 igp |
| Internet | name=”default” as=65533 router-id=10.33.1.1 |
0 E default 10.33.1.2 65531 1 E default 10.33.2.2 65532 |
0 10.33.0.0/19 no |
T1 10.2.0.0/19 10.33.1.1 65532 igp T1 10.33.0.0/19 10.33.1.1 igp T2 10.0.0.0/19 10.33.2.1 65531,65530 igp T2 10.1.0.0/19 10.33.2.1 65531 igp T2 10.33.0.0/19 10.33.2.1 igp |
Tabela 3. Implementação dos MKs virtuais no FFE (P~Provedor, T1~Transito1, T2~Transito2 e I~Internet).
| Máquina Virtual |
Rotas
Flags: X – disabled, A – active, D – dynamic, |
| Provedor | 0 ADC 10.0.0.0/30 10.0.0.1 S0_LAN 0 1 ADb 10.1.0.0/19 10.1.0.1 20 2 ADC 10.1.0.0/30 10.1.0.2 S1_Transito1 0 3 ADb 10.2.0.0/19 10.2.0.1 20 4 ADC 10.2.0.0/30 10.2.0.2 S2_Transito2 0 5 ADb 10.33.0.0/19 10.1.0.1 20 6 Db 10.33.0.0/19 10.2.0.1 20 |
| Transito1 | 0 ADb 10.0.0.0/19 10.1.0.2 20 1 ADC 10.1.0.0/30 10.1.0.1 S1_Provedor 0 2 ADb 10.2.0.0/19 10.1.0.2 20 3 Db 10.2.0.0/19 10.33.1.1 20 4 ADb 10.33.0.0/19 10.33.1.1 20 5 ADC 10.33.1.0/30 10.33.1.2 S3_Internet 0 |
| Transito2 | 0 ADb 10.0.0.0/19 10.2.0.2 20 1 Db 10.0.0.0/19 10.33.2.1 20 2 ADb 10.1.0.0/19 10.2.0.2 20 3 Db 10.1.0.0/19 10.33.2.1 20 4 ADC 10.2.0.0/30 10.2.0.1 S2_Provedor 0 5 ADb 10.33.0.0/19 10.33.2.1 20 6 Db 10.33.0.0/19 10.2.0.2 20 7 ADC 10.33.2.0/30 10.33.2.2 S5_Internet 0 |
| Internet | 0 ADb 10.0.0.0/19 10.33.1.2 20 1 Db 10.0.0.0/19 10.33.2.2 20 2 ADb 10.1.0.0/19 10.33.1.2 20 3 Db 10.1.0.0/19 10.33.2.2 20 4 ADb 10.2.0.0/19 10.33.2.2 20 5 Db 10.2.0.0/19 10.33.1.2 20 6 ADC 10.33.1.0/30 10.33.1.1 S3_Transito1 0 7 ADC 10.33.2.0/30 10.33.2.1 S5_Transito2 0 |
Tabela 4. Tabela de roteamento dos componentes do modelo.
O “traceroute” abaixo foi feito do Notebook que está com o IP 10.0.0.2/30, na diração de Internet. Ele indica que o tráfego passa pelo operador Transito1
tracert 10.33.2.1 Rastreando a rota para 10.33.2.1 com no máximo 30 saltos 1 <1 ms <1 ms <1 ms 10.0.0.1 2 13 ms <1 ms <1 ms 10.1.0.1 3 2 ms 1 ms <1 ms 10.33.2.1 Rastreamento concluído.
O “traceroute” que segue é de Internet na direção do Notebook. Apesar de um possível “loop” em seu resultado é possível ver que o tráfego de entrada passa pelo Trânsito1. Nesta configuração o tráfego via Transito2 somente ocorrerá se houver uma ruptura nas conexões via Transito1.
[admin@Internet] > tool traceroute 10.0.0.2 # ADDRESS RT1 RT2 RT3 STATUS 1 10.33.1.2 1ms 1ms 1ms 2 10.1.0.2 1ms 1ms 1ms 3 0.0.0.0 0ms 0ms 0ms 4 0.0.0.0 0ms 0ms 0ms 5 0.0.0.0 0ms 0ms 0ms 6 0.0.0.0 0ms 0ms 0ms ...
Duas questões aparecem na configuração padrão e sem filtros: (a) porque a escolha de Transito1 e, (b) porque o loop no “traceroute” de entrada. Pergunta 3: Alguém poderia responder (b)?
Filtros
Ao pensar em filtros deve-se ter em mente as preocupações do BGP que fala sobre o qual temos o controle. No nosso modelo, em tese, só temos controle sobre o Provedor. Entretanto, vale pensar o resto do mundo para que se possa exercitar as melhores prática em BGP. Vamos enumerar e executar os filtros, caracterizando os dois respectivos ambientes: o BGP local – L -, Provedor e o BGP do resto do modelo – RDM -, Transito1, Transito2 e Internet. Vale algumas observações: (a) o RDM são os provedores de trânsito (“upstream”); (b) o Provedor é o “downstream” de Transito1 e Transito2 e estes, “downstreams” do Internet, que por sua vez é o “upstream” de ambos os provedores de trânsito do Provedor.
- RDM: Os provedores de trânsito não deveriam aceitar prefixos que não os acordados com seus clientes. Esta é uma das razões pelas quais as operadoras de trânsito encaminham um formulário, como pré-requisito, para a implementação do empareamento. A outra razão é que as operadoras precisam de encaminhar para seus empareados a informação de que um novo anúncio será feito (isto, também, o Provedor terá de fazer, caso ele venha a se tornar um operador de trânsito!). E, imagina-se, que o provedor de trânsito, ao receber o formulário tome algumas providências como, por exemplo verificar no “whois” se o bloco informado pertence mesmo ao “downstream”. Ultimamente, isso deve estar acontecendo, pois os provedores de trânsito esperam que o AS empareado – ASE – esteja com suas políticas registradas em algum IRR (“Internet Routing Register”). Pergunta 4: Se o “Provedor” passa a fornecer trânsito para terceiros, como será o anúncio para seus pares, dos blocos de terceiros?
- RDM: Um Provedor de trânsito com o objetivo de interagir com a Internet. Portanto o Provedor precisa receber para que a interação completa seja possível. É uma exigência contratual. Entretanto, deve-se ter em mente o componente humano envolvido na cadeia de suprimentos do BGP e, portanto faz parte do trabalho do admnistrador de um BGP que fala, se dispor a verificar se tudo está conforme as especificações e, em particular, se as informações estão disponíveis nessa cadeia. Há muitas falhas na cadeia, pois a Internet tem crescido com tamanha rapidez que os seres humanos envolvidos podem se perder em algum momento. Um dos principais alvos da inadequada interferência humana é a convergência do BGP.
- ASE: Um ASE somente deve aceitar prefixos que tenham sido previamente acordados com o outro ASE. Se um ASEi acordou em receber uma tabela de roteamento parcial de um ASEj, então o ASEi deve imaginar a possibilidade do ASEj estar lhe mandando uma tabela de rotas completa.
- ASE: Somente se deve anunciar prefixos acordados com o outro empareado.
- L: Não aceite prefixos especificados na RFC3330.
- L: Não aceite os próprios prefixos.
- L: Somente anuncie os próprios prefixos. Ou de seus “downstreams” associados aos respectivos ASes.
- L: Não aceite a rota padrão, exceto se ela for necessária.
- L: Não aceite prefixos especificados na RFC3330.
- L: Não aceite prefixos da relação de “Bogon”. Faça isso, inicialmente, manualmente mas não deixe de implementar um empareamento com o Team Cymru, [5], para tornar o processo automatico e, consequentemente, bem menos trabalhoso.
- L: Ative a opção de remover ASN privativos do anúncios. No nosso modelo isso não será possível. Mas o nosso modelo é um simples modelo.
- L: Limite o comprimento do AS_path (20, ou avalie outro valor, com base na experiência do dia a dia). Tal restrição, geralmente é feita quando se quer receber somente a tabela de roteamento parcial.
- L: Usar a técnica do TTL hack especificando, nos empareamentos, o TTL 255. Maiores informações em [4].
Assuntos relacionados, neste blogue
- BGP no Mikrotik: Dois operadores de trânsito. Versão anterior a este artigo.
- BGP em Mikrotik – Parte I
- BGP em Mikrotik – Parte II
- BGP em Mikrotik – Parte III
- BGP no Mikrotik (IV): Anúncios e rotas no FFE
- BGP no Mikrotik (V): Analisando anúncios de implementações de BGP
- BGP no Mikrotik (VI): Estabelecendo enlaces (rotas) backup
- BGP no Mikrotik (VII): Mesmo AS em empareamentos remotos e independentes
- BGP no Mikrotik (VIII): Alterando a política de roteamento
- BGP no Mikrotik (IX): Filtros
- Atributos do BGP
- BGP: Tabelas de roteamento
- Convergência, no BGP
- A Seta IPv6: Preparando para trabalhar com IPv6 no Mikrotik
- Conectando-se a um PTT, em Mikrotik (IPv4 e IPv6)
- BGP: topologias, abstrações, eBGP e iBGP (Parte 1)
Referências
- Russ White, Danny McPherson, Srihari Sangli. Practical BGP. Pearson Education, Inc. 2005.
- VMware Virtual Networking Concepts. Disponível em: http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf. Acessado em 19/08/2011 10:28.
- Cisco. BGP Attributes and Policy Control. ISP/IXP Workshops Disponível em: http://www.pacnog.org/pacnog2/track2/routing/b1-1up.pdf. Acessado em 21/08/2011 11:50.
- Jeff Doyle. Protecting Your Network Edge with TTL Security. Disponível em: http://www.networkworld.com/community/node/18760. Acessado em 21/08/2011 16:43.
- Team Cymru. Disponível em: http://www.team-cymru.org/. Acessado em 21/08/2011 16:43.
| Follow @juliaobraga |
Sobre a questão do balanceamento em BGP
A questão do balanceamento em BGP tem muitos equívocos. Temos de serpará-lo em duas partes: balanceamento de saída e balanceamento de entrada.
O primeiro grande equívoco é pensar que o tráfego é simétrico: o caminho da saída será o caminho da entrada. O tráfego NÂO É simétrico. É assimétrico. Russ White et alli, no Practical BGP mostra a assimetria, na página 53 e faz uma abordagem bastante completa, no capítulo 3.
Geralmente, a sugestão tem sido em dividir o bloco anunciado pelo BGP que fala, em prefixos maiores, fazendo anúncios separados. O usual é anunciar o bloco inteiro (bloco original do ASN) para garantir a redundância, caso ocorra uma falha em um dos enlaces.
Isto está correto, mas somente com o “Multi-Home” com uma mesma operadora de trânsito e, desde que não se deixe de solicitar à operadora de trânsito que faça a agregação dos prefixos divididos (é de se esperar que isto seja feito automaticamente).
Se, por outro lado, o “Multi-Home” é feito com operadoras diferentes, a divisão do bloco não é recomendável como boa prática, pois a agregação não ocorrerá tão próximo como se desejaria (na realidade, não sabemos onde ela ocorrerá e, se ocorrerá), inundando a tabela de rotas. Não que um Provedor faça verão, mas uma imensidão de Provedores fará.
A divisão do bloco em prefixos maiores tende facilitar o estabelecimento de rotas ping-pong uma vez que muito facíl ficar mudando a tal divisão de blocos, gerando problemas na convergência global do BGP.
A recomendação é ser mais criativo. Inovador, quem sabe. Para isso é preciso estudar bastante e eliminar a falta de habilidade humana em entender questões que são vistas pela primeira vez.
Juliao boa noite !!!
Tenho um cenario aqui parecido, com esse FFE com 2 operadoras de transito, como ja comentei anteriomente em outro post eu mesmo tenho implementar esse protocolo.
Facilmente consegui subir a sessão com cada operadora em separado, anunciando uma parte do meu bloco em cada operadora, mais ai surgiu a questao de redundancia, e ligarmos os 2 links em apenas um mikrotik.
O que acontece é que são link de tamanhos diferentes, o que ao meu ver (por falta de experiencia) se torna um pouco complicado.
Li em muitos lugares que poderia quebrar em 2 blocos e anunciar cada bloco em uma operadora, e anunciar o bloco inteiro nas 2 operadoras.
Criar filtros para fazer prepend, e setar o local pref e weight, olhando acima como é o processo de decisão do bgp, eu quero que uma parte desse bloco saia somente pela operadora A, e a outra parte pela B, e quando uma delas cair saia tudo pela que esta funcioando.
Isso é possivel mesmo ?
Outra duvida que tenho é quando falamos em trafego de saida e entrada no BGP, seria o mesmo significado quando estamos falando de upload (Saida para Internet) e download (O que vem da internet) ou é algo totalmente diferente ?
Eu posso postar algum exemplo de filtro que penso que funcionaria da forma que quero para ver se na sua opiniao funciona ?
Agradeço a atenção dada de antemão.
Abraços.
Olá Rocha,
Pode postar o que você desejar, em particular, questões técnicas pertinentes. São bem vindos, inclusive, as conjecturas…
Algumas observações:
1. Ao quebrar o bloco de IP: (a) o bloco com maior prefixo tem maior prioridade (/21 é maior do que /20, embora com menos IPs). (b) se você anunciar o bloco inteiro (também), em ambas as portas, se uma falhar o tráfego sai pela outra.
2. Upload ~ tráfego de saída. Download ~ tráfego de entrada.
3. Em algum lugar cito (inclusive uma referência), de que se o tráfego sai pelo provedor A, não necessáriamente o retorno se dá pelo mesmo provedor A.
4. BGP não faz balanceamento. Você pode “manipular” o tráfego de saída, através de anúncio de blocos diferentes e através do uso de atributos. Balanceamento de saída efetivo e/ou aproveitamento ótimo das bandas (mesmo que diferentes, como o seu caso) devem ser feitos usando os recursos de marcação de pacotes. São procedimentos que dependem das características locais (banda, número de provedores de trânsito e interesses do administrador – principalmente). E são, também, procedimentos não triviais que exigem o entendimento da estrutura do Mikrotik. Scripts, geralmente ajudam muito em desvios de tráfego de saída (upload). Mas, pouco se pode fazer em relação à entrada (download), pois esta é dependente dos acertos e erros do BGP que fala de terceiros (sobre os quais você não consegue interferir). Se há erros dos terceiros (o que é muito comum), conseguimos avaliar através de análises sistemáticas, algumas vezes demoradas e cansativas usando ferramentas como os LGs, por exemplo.
Distância administrativa (“administrative distance”)
É um termo cunhado pela Cisco, que diz ser a medida de confiabilidade da fonte de uma rota.Se um roteador aprende sobre o destino de uma rota a partir de diversos protocolos de roteamento, a distância administrativa é comparada e a preferência será dada às rotas com menor distância administrativa.
Há pequenas variações do valor da distãncia administrativa indicada pelos diversos fabricantes. As referências abaixo apresentam as propostas da Cisco, Juniper e Mikrotik:
1. http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094195.shtml
2. http://wiki.mikrotik.com/wiki/Manual:Route_Selection_Algorithm_in_RouterOS
3. http://www.net-gyver.com/?p=776
Conectividade entre os empareados
Um empareamento entre dois BGPs que falam é feito via IP (IPv4 ou IPv6). É necessário haver conectividade dos IPs usados pelos respectivos pares. A forma tradicional é um /30, geralmente, do “upstream”, pois supostamente seus IPs já estão anunciados. Mas, uma boa alternativa é usar o Loopback, em ambos os lados. Do lado do “upstream” conseguimos imaginar a facilidade, pois basta ele informar um de seus IPs que estão anunciados. Mas do lado do “downstream” digamos, o Provedor não é imediado. Faz-se o seguinte: o Provedor separa um pedaço de seu bloco IP, por exemplo, um /28 (os operadores de trânsito sempre separam um pequeno bloco para Loopback!). Informe ao operador de trânsito, o IP da Loopback e assim que o empareamento for estabelecido e o anúncio do bloco inteiro ocorrer, o IP da Loopback terá conectividade.
A pergunta interessante a ser respondida é: Por que usar interfaces Loopback é uma boa alternativa?
Obrigado pela atenção Juliao.
Bom nos meus teste realizados aqui, utilizando um cenario real, fechei o BGP com as duas operadoras no mesmo router, anunciando um /21 (que é nosso bloco inteiro) nas 2 operadoras, e em cada uma um /22.
Ficando assim minha conf:
“/routing bgp peer
add address-families=ip as-override=no comment=”BGP HOST” default-originate=never disabled=no hold-time=3m in-filter=in_host instance=default multihop=yes name=HOST nexthop-choice=default out-filter=peer-out-host passive=no remote-address=189.xx.x.93 remote-as=2xxxx6 remove-private-as=no route-reflect=no tcp-md5-key=”” ttl=default update-source=189.xx.x.94 use-bfd=no
add address-families=ip as-override=no comment=”BGP AL” default-originate=never disabled=no hold-time=3m in-filter=perr-in instance=default multihop=yes name=PERR_AL nexthop-choice=default out-filter=out_al passive=no remote-address=200.xxx.xx.145 remote-as=1xxxx remove-private-as=no route-reflect=no tcp-md5-key=”” ttl=default update-source=200.xxx.xx.26 use-bfd=no”
Filtros:
/routing filter
add action=accept chain=peer-out-host disabled=no invert-match=no prefix=1xx.72.128.0/22 (Anuncia o /22 na operadora H)
add action=accept chain=out_al disabled=no invert-match=no prefix=1xx.72.132.0/22 (outro /22 na operadora A)
add action=accept chain=peer-out-host disabled=no invert-match=no prefix=1xx.72.128.0/21 ( /21 na H)
add action=accept chain=out_al disabled=no invert-match=no prefix=1xx.72.128.0/21 (/21 na A)
add action=discard chain=peer-out-host disabled=no invert-match=no (Nao anuncia nada se nao for meu prefixo Na H)
add action=discard chain=out_al disabled=no invert-match=no (mesma coisa do filtro de cima so que na A)
Com essa conf, nos teste com LG’s e traceroute, eu consigo chegar de fora para dentro da rede com a operadora certa como estipulado nos blocos de IP’s. ou pelo menos me parece isso. Só nao fiz testes ainda com desktops para ver se o funcionamento realmente é o que quero.
Agora sobre o upload, e ainda pensando na decisão que o BGP toma, setando o local-pref e o weight poderia forçar a sair por onde eu quero, mais a complexidade do protocolo em si nao me garante que isso funcione como deveria ou como eu quero, no meu caso é uma questão cansativa de tentaiva e erro, pra se acertar isso.
Abraços e mais uma vez obrigado pela atenção dispensada a todos que lê esse blog.