[FUG-BR] [Meio-off] OpenBGPD + carp

[Patrick Tracanelli]

Renato Frederick wrote:
> Pessoal,
> 
> Apesar de ser meio off, mas como sempre rola assunto relativo a BGP e afins 
> aqui, vamos lá.. :)
> 
> Andei migrando o quagga para o openbgpd, sem maiores complicações, porém o 
> motivo desta migração é a integração com o carp.
> 
> Para fazê-lo encontrei algumas opções:
> 
> 1 - Subir o peer com a flag "depend on carpX"[1] e local-address, sendo a 
> carpX a interface que é conectada ao ISP e local-address o IP de 
> loopback(que antes ficava la lo0 mas agora é atrelado a uma interface carp);
> 2 - Subir 2 sessões com o ISP[2];
> 3 - Fazer um ibgp[3].;
> 
> Pelos testes, a opção 1 parece ser a mais simples e efetiva.
> 
> 
> Se alguém tem este cenário, poderia trocar as experiências de qual opção usa 
> e qual trabalha melhor?
> 
> Abraços

Todas as opcoes sao efetivas ;-) Mas a 3 por exemplo é um saco. O 
proprio autor do OpenBGP sugere cenarios com iBGP. Eu evito.

Eu faco a Opcao 2. Mantenho 2 peering simultaneos com cada operadora, 
dou prepend-self +2 no de backup e localpref -10 no de backup tambem.

Ai coloco carp na(s) interface(s) LAN do cliente. Dessa forma, nao tenho 
carp na WAN.

Por outro lado todos os peerings no BGP master tem depend on carp0 pois 
se por algum motivo o carp virar pra outra maquina, e a master não 
travou por inteiro, preciso garantir que todos os peers passem a 
trafegar exclusivamente pelo outro BGP. Afinal la que esta a LAN.

So que tem nuances. Em alguns setups com as operadoras o Cisco dos 
camarada piram o cabecão ao ter 2 sessões BGP com mesmo AS, mesmos 
anuncios, em IPs diferente e tendem a dar bixeira. Com Juniper ou outro 
OpenBGP isso nao gera problema. Pra corrigir indico pra operadora por 
nexthop 2 no Cisco delas.

Se voce fizer a opcao #1 nao fica transparente. Na falha do MASTER o seu 
BGP BACKUP tem que anunciar e receber as rotas do peering. O que pode 
ser ate OK se voce so tem um peering, afinal enquanto as rotas não 
chegam voce vai de default route static e a demora se limita ao seu 
anuncio (seus CIDR) estabelecer com a outra ponta. Mas se voce tem 
varios peers, esperar todos eles fechar, anunciar pra todos, receber os 
full ou partial de todos, e depender de um default route static que 
provavelmente vai congestionar seu nexthop default por alguns minutos 
ate a putaria acabar e todas as rotas forem recebidas, vai gerar transtorno.

A opcao #3 é a mais chata de manter, mas é a mais funcional. Só depende 
de você, não tem nuances que dependam de você ensinar o que tem que ser 
feito pro seu upstream, e tem efeito imediato (sem janela de default 
route). No tempo do Carp. Seus clientes podem nem sacar que o BGP Master 
falhou.

Além disso é a opcão mais clean. Ja que BGP é um protocolo projetado pra 
ser hierárquico, e não paralelo.

Eu vou de #1, mas #1 do meu jeito, com carp só na LAN e os peerings 
dependendo desse carp.

Se voce for por carp nas interfaces WAN nao adianta nada. Da na mesma 
que a opcao #2 pois seu upstream vai fazer peering com apenas 1 IP, o 
virtual (carp), e ao falhar o CARP BACKUP tera que receber de novo as 
rotas e enviar os seus anuncios. Eu nunca implantei desse jeito pois 
quando pensei ja vi que nao seria uma boa. Sei que teriam outros 
problemas, alguns dos poucos eu ja previ, como a necessidade de dar um 
clear quando o backup assumir, pra ele informar o peer que é pra comecar 
de novo pois simplesmente mudar de IP o upstream vai se negar a reenviar 
as rotas, ele nao vai perceber que voce nao recebeu, vai ficar fora de 
sync vai dar uma lambanca só.

Eu tenho apenas um cenario com o setup #3 e o resto é #1 do meu jeito, 
como descrito.

E a proposito, faz bem em se livrar dessa caca. Digo, quagga hehehe. Sei 
que seu costume com cisco-like inclinava ao cavalo branco listrado, mas 
esse cavalo é manco. Quando voce usar pftables pela primeira vez e tuxar 
um route-to so na table que o OpenBGP popula dinamicamente pra voce, ou 
um probability com route-to e keep-state so praquele dado AS, voce vai 
estar feliz por estar no OpenBGP.

Se bem que trocar uma penca de "permit X" e "route map out" por um único 
"set X" no neighbor ja é bacana hehe. Pode ser besteira em cenarios 
pequenos, mas quando voce passa a ter muitos neighbors e fazer transito 
com muitos outros peers, so Deus sabe como é bom poder fazer todas as 
coisas com 1 linha ou 1 match de filtro.