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

[Renato Frederick]

Olá Patrick

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

iBGP  é coisa que a gente só faz na vida quando tem que tirar certificação 
cisco ou trabalha em uma operadora de Internet com cenários diversificados. 
Fora isto 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.

Correto. No meu caso ainda tenho que ver como faria pois o servidor em 
questão tem clientes em várias interfaces carp, não tem só carp0(WAN) e 
carp1. Tem outras interfaces atendendo a diferentes perfis de cliente.

Aliás coisa que o carp não funciona correto aqui:

carp0(WAN)->bge0
carp1(LAN) -> bge1
carp2(DMZ) -> bge2

FIREWALL1 (MASTER)
FIREWALL2(BACK)

Suponha que somente o cabo que liga a bge2 do firewall1 quebre.

Neste hora o carp vai entrar em ação na carp2 e vai eleger firewall2 como 
master.

ficaremos então com:
carp0 -> firewall1 -> master
carp1 -> firewall1 -> master
carp2 -> firewall2 -> master

Então o pacote da DMZ vai chegar para o firewall2(master), mas porém é o 
firewall1 que está com a carp0 ativa na WAN. Aì neste ponto o pacote se 
perde :(
Da mesma maneira, um pacote na Internet vai chegar pela WAN para o 
firewall1(MASTER), mas ele não enxerga mais a DMZ, porque o carp2 nele está 
slave.

Só funciona neste caso se colocar carp0/1/2 como slave em firewall1, aí tudo 
funciona pelo 2.


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

Então, o problema é fazer algumas operadoras, que já demoraram 8 meses para 
ativar 1 sessão BGP fazer a alteração :)
Aliás, poucas são as operadoras que fecham o BGP usando mais de um IP do 
lado deles, grande maioria fecha no endereço WAN e pronto.

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

Vi uma discussão destas que a pessoa queria mudar os tempos padrão do 
openbgp para garantir que em caso de falha o openbgp subisse no backup mais 
rápido que o padrão. Talvez ajude

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

Vou analisá-la com mais atenção, quem sabe...
>
> 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ó.


:-/ Pensei que ele era esperto o suficiente para no BACKUP fazer algo do 
tipo "clear ip bgp *" , que sobe a sessão toda.
Tem outro porém também, ficar fazendo isto vai contar pontos e pode colocar 
o AS como dampened

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

Tadinho, o quagga é gente boa, hehehhee, só me deu dor de cabeça quando as 
operadoras começaram a divulgar AS de 32bits e o ports do free não tava 
atualizado, foi muito bom todos os clientes ligarem ao mesmo tempo com o 
mesmo problema :)

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

Pois é, como já comentamos aqui, hoje faço via "fwd to" (ou FIB no BSD 8), 
mas integrando com pf as coisas ficam mais simples.

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

É tudo questão de costume, tem também os prefix-list e match e 
community-list, tudo é questão de aprender a sintaxe, por ex:

ip prefix-list BOGONS seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 15 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 20 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS seq 25 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS seq 30 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS seq 35 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS seq 40 deny 224.0.0.0/3 le 32
ip prefix-list BOGONS seq 1000 deny 187.X.X.0/20 le 32
ip prefix-list BOGONS seq 9999 permit 0.0.0.0/0 le 24

fica:

deny from any prefix 10.0.0.0/8 prefixlen >= 8
deny from any prefix 172.16.0.0/12 prefixlen >= 12
deny from any prefix 192.168.0.0/16 prefixlen >= 16
deny from any prefix 169.254.0.0/16 prefixlen >= 16
deny from any prefix 192.0.2.0/24 prefixlen >= 24
deny from any prefix 224.0.0.0/4 prefixlen >= 4
deny from any prefix 240.0.0.0/4 prefixlen >= 4

etc, etc

Abraços