[GTER] BGP Vyatta e RB1100

Márcio Elias Hahn do Nascimento marcio at sulonline.net
Mon Nov 10 08:56:34 -02 2014


 

Bom, o CARA em VyOS é o Uesley, mais deixa eu dar uns pitacos.


Primeiro não precisa da regra de Deny no route-map, ela é existe por
padrão no final do mesmo, vc não vê mais ela está lá. Bom mais isso não
chega a ser um problema e certamente não é a causa do que vc relatou.


Sobre a política de publicação de prefixos, também faço anuncios
diferenciados de blocos mais e menos específicos para balancear os
upstreans, embora vc possa fazer isso com preped e as-path, podendo
publicar os blocos idênticos a todos seus upstreans. 

Agora uma
pergunta, no momento dos testes de failover, vc verificou algum looking
glass para atestar se seus prefixos mais específicos ainda não estavam
presos ao upstrean que caiu? Isso é muito comum, principalmente se seu
fornecedor usar RouterOS. 

Muito provavelmente a causa seja isso, por
que assim se algum peer ainda enxergar o seu prefixo mais específico
anunciado na operadora que caiu, vai tentar mandar tráfego para lá e não
irá funcionar. 

---

Att 

Márcio Elias Hahn do Nascimento
(48)
8469-1819 / 3524-0700 - marcio at sulinternet.net
GERÊNCIA DE RECURSOS DE
TIC - Sul Internet [2] 

 [2] 

Em 10/11/2014 00:50, Jeffrey . escreveu:


> Bom - primeira vez que configuro o BGP no VyOS.. resultado, tomei
uma surra bem dolorida..No fim, parece que funcionou, mas como sempre
aparecem umas coisas diferentes...Vou tentar explicar da melhor forma
possível, é um pouco extenso..Tenho 3 upstreams que chamarei de A, B e
C.tenho um /22 anunciado para os 3 upstreams, para nao usar o real,
usarei, 1.1.220.0/22No upstream A, tenho 90MB, no upstream B tenho 50MB,
no upstream C tenho 20MB.recebo lista full de todos eles.Anuncio os
prefixos desta maneira:Upstream
A:1.1.220.0/221.1.220.0/231.1.222.0/231.1.220.0/241.1.223.0/24
>
Upstream B:1.1.220.0/221.1.220.0/231.1.222.0/231.1.222.0/24
> Upstream
C:1.1.220.0/221.1.221.0/24
> Desta maneira controle o download, os /24
220.0 e 223.0 saem pelo UP A, o 221.0/24 sai pelo UP C, e o 222.0/22 sai
pelo UP B...criei uma prefix list para cada upstream e associei a um
route-map que possui na primeira regra um permit, match ip address
prefix-list XXXXa proxima regra é uma deny que faz match ip address de
outro prefix-list chamado all que possui o prefixo 0.0.0.0/0 le 32essa é
a parte acredito pra ng me usar de transito.uma vez pronto o route map,
associei ele no export do neighbor de cada um dos meus peersTambém fiz
um route-map para associar no import, a primeira regra tem um deny dando
um ip address match prefix-list em todos os meus prefixos, mais um
prefixo 0.0.0.0/0 para que eu descarte a rota padrao de meus UPS. Depois
dessa regra, tenho uma regra que permite tudo (0.0.0.0/0 le 24)e logo
depois eu seto o local-pref de cada um deles.. Meu UP A possui 120 de
local-pref, UP B = 100 e UP C = 80Dessa maneira forço todo o upload no
UP A.Para todos os peers eu coloquei o soft-reconfiguration inbound para
manter tudo na memória.
> Subi tudo, configurei tudo e tudo funcionou
como esperado, até eu testar o failover...fui lá e tirei o cabo do UP A,
depois de uns 2 minutos, tudo voltou ao AR, MAS ao fazer o teste de
banda, a banda nao passa de 6 ou 7MB, mesmo saindo pelo UP B que possui
50MB de banda...Quando ponho o micro na classe 222.0/24, e os 3 UPS
estao no ar, eu consigo os 50MB de down sem problemas, e posso ver que
realmente tá vindo pelo UP B....Quando tiro o UP A, começa a prejudicar
o download do UP B, mas o interessante é que o upload fica normal
(consigo os 50MB)...nao consegui entender... depois que coloco o cabo do
UP A e espero baixar as rotas e atualizar, tudo volta ao normal.
>
Alguém tem alguma idéia do que pode estar ocorrendo? Isso só acontece qd
tiro o cabo do UP A, se tirar do B ou do C, o comportamento de failover
é o esperado....
> Qualquer sugestao é mto bem vinda... se precisar de
mais detalhe é só falar.Obrigado e boa semana a todos.
> Jeffrey
> 
>>
To: gter at eng.registro.br Date: Mon, 27 Oct 2014 10:23:21 -0200 From:
marcio at sulonline.net Subject: Re: [GTER] BGP Vyatta e RB1100 Jeffrey,
pensando no menor tempo de convergência acredito que o melhor seja vc
usar OSPF, BGP (tanto IBGP quanto EBGP) pelo próprio design tem uma
convergência mais lenta (vc pode mudar os timers é claro, mais ainda não
acho o mais indicado para o seu caso). IBGP usaria para conectar 2 ou
mais routers rodando EBGP. Não acho muito interessante vc misturar IP's
públicos e privados, se vc vai fornecer um IP público ao seu cliente e o
mesmo vai passar por routers com IPs privados, esses IPs vão aparecer em
um traceroute e não fica legal (minha opinião), se vc usasse tuneis
entre o cliente e sua borda, ai sim poderia colocar IPs privados que os
mesmos não apareceriam para o cliente. Bom partindo do principio que vc
tem um bloco /24 por exemplo, atribua um IP para a interface interna do
seu router de borda e outro na interface do MK conectado a ele. Divida
esse bloco no MK e o OSPF vai se encarregar de propagar essas sub-redes
a todos os outros routers (inclusive sua borda). No MK vc tem a opção de
distribuir a roda default, desta forma se os clientes pegam os seus
blocos por OSPF, a rota default pode ser distribuída em conjunto, não
necessitando setar um default gateway manualmente. --- Att Márcio Elias
Hahn do Nascimento (48) 8469-1819 / 3524-0700 -
marcio at sulinternet.netGERÊNCIA DE RECURSOS DE TIC - Sul Internet [2] [2]
Em 26/10/2014 18:31, Jeffrey . escreveu: 
>> 
>>> Srs,
>> há algum tempo
postei aqui e pedi dicas de como ter 2 upstreams em uma das localidades
que atendo.Tive problemas como tantos outros com MK e descontando as
soluções de mais de 20 mil reais, de longe, o melhor custo benefício foi
a implementação do Vyatta para o BGP. 
>> 
>>> Tomei esta
>> decisão em
função do bug de rota presa do MK e também do tempo de convergência alto
(cerca de 3 min) no MK.
> 
> --
> gter list
https://eng.registro.br/mailman/listinfo/gter [1]
 

Links:
------
[1]
https://eng.registro.br/mailman/listinfo/gter
[2]
http://www.sulinternet.net



More information about the gter mailing list