Início > BGP, Loopback, Mikrotik, TCP/IP > BGP no Mikrotik: Dois operadores de trânsito (Visão genérica)

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.

  1. 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.
  2. Maior valor de “Weight”. O valor padrão do “Weight” é zero. Embora seja um parâmetro da Cisco, já está implementado no Mikrotik.
  3. Maior valor no “Local Preference”, cujo padrão é 100.
  4. Rotas geradas localmente sendo que as rotas geradas localmente pelo próprio BGP têm a preferência.
  5. Rota com menor ORIGIN, na ordem: IGP, EGP e INCOMPLETE.
  6. Rota com o menor MED (“Multiple Exit Discriminator”).
  7. Preferência por rotas geradas por eBGP, sobre rotas recebidas por iBGP.
  8. Caminho com menor custo IGP para o “next_hop”.
  9. 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.
  10. Rota com o caminho cujo empareado tiver menor “router_id” (“originator-id” para rotas refletidas).
  11. Menor “cluster-list”. Atenção aos atributos de “Route Reflector”.
  12. 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,
C – connect, S – static, r – rip, b – bgp,
o – ospf, m – mme, B – blackhole,
U – unreachable, P – prohibit

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.

  1. 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?
  2. 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.
  3. 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.
  4. ASE: Somente se deve anunciar prefixos acordados com o outro empareado.
  5. L: Não aceite prefixos especificados na RFC3330.
  6. L: Não aceite os próprios prefixos.
  7. L: Somente anuncie os próprios prefixos. Ou de seus “downstreams” associados aos respectivos ASes.
  8. L: Não aceite a rota padrão, exceto se ela for necessária.
  9. L: Não aceite prefixos especificados na RFC3330.
  10. 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.
  11. 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.
  12. 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.
  13. L: Usar a técnica do TTL hack especificando, nos empareamentos, o TTL 255. Maiores informações em [4].

 

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. Russ White, Danny McPherson, Srihari Sangli. Practical BGP. Pearson Education, Inc. 2005.
  2. VMware Virtual Networking Concepts. Disponível em: http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf. Acessado em 19/08/2011 10:28.
  3. 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.
  4. 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.
  5. Team Cymru. Disponível em: http://www.team-cymru.org/. Acessado em 21/08/2011 16:43.

Categorias:BGP, Loopback, Mikrotik, TCP/IP
  1. juliaobraga
    23/08/2011 às 14:53

    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.

    • 15/09/2011 às 20:28

      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.

      • juliaobraga
        15/09/2011 às 22:38

        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.

  2. juliaobraga
    24/08/2011 às 08:33

    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

  3. juliaobraga
    25/08/2011 às 15:40

    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?

  4. 19/09/2011 às 22:02

    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.

  1. No trackbacks yet.

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

%d blogueiros gostam disto: