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

[Fabricio Archanjo]

Eu não tenho experiencia com BGP somente em labs.
Eu queria saber se o OpenBGPD é melhor que o Quagga ??
Esse deamon já acompanha o bsd faz tempo, eu uso muito o openospfd no lugar
do quagga, e não tenho problemas..

Att.

2010/4/21 Patrick Tracanelli <eksffa em freebsdbrasil.com.br>

> 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.
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>