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

[Renato Frederick]

>> 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.

Pesquisando um pouco mais, achei esta interessante discussão[1], o trecho 
abaixo:

> > with the carp integration, bgpd will keep all bgp sessions
> > marked as depending on a particular carp interface in IDLE, and once
> > the carp interface becomes master they immediately go to CONNECT (or
> > ACTIVE for passive sessions), reduncing the failover time muchos.


Acho que resolveria, não? NÃO declarar no bgpd.conf a sessão como "passive".
no firewall BACKUP vai ficar IDLE a sessão BGP. Quando ele virar MASTER, vai 
mandar comando CONNECT para a operadora.
Se a operadora não tiver muita frescura, ela vai entender que a sessão 
caiu(Já que foi enviando um connect pra lá), vai ficar como active e depois 
established e vai enviar as rotas.

Se ela recusar isto, vai mandar a conexão de novo pro state IDLE, talvez dê 
certo.


[1]: http://monkey.org/openbsd/archive/misc/0411/msg03661.html