[FUG-BR] [Meio-off] OpenBGPD + carp
Patrick Tracanelli
eksffa em freebsdbrasil.com.br
Quarta Abril 21 12:46:42 BRT 2010
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.
Mais detalhes sobre a lista de discussão freebsd