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
