Pessoal, bom dia! Desculpem o cross-posting, mas a PFSENSE-PT e FUG é lugar de gente fera neste assunto e meu email faz referência a ambos.
Vamos lá, já peço perdão pelo email grande! No FREEBSD/OPENBSD, com OPENBGPD e PF, eu posso fazer isto: 1 - criar uma table no PF, por exemplo: table <ctbc> persist 2 - lá no openbgpd.conf, eu entrego todas as redes aprendidas da sessão BGP desta operadora para a table criada, por exemplo: match from 189.x.x.x set pftable ctbc #onde 189.x.x.x é o peer BGP 3 - por fim, lá no pf.conf, eu posso fazer um PBR de saída, forçando, por exemplo, que toda a rede 200.1.1.0/24 saia pela ctbc, mesmo que um outro peer BGP(por exemplo, um PTT), entregue uma rota mais específica: pass out quick route-to ($ctbc_if $ctbc_gw) from200.1.1.0/24 to <ctbc> keep state Porque eu faço este processo todo e não faço simplesmente um: pass out quick route-to ($ctbc_if $ctbc_gw) from200.1.1.0/24 to any keep state Para garantir que quando o link com a ctbc cair(e obviamente a sessão bgp parar), a table ctbc vai ficar vazia e a rede 200.1.1.0/24 vai sair ou pela rota padrão(que vai usar outra operadora), ou por outra sessão BGP(que vai ter as rotas injetadas no kernel). Também garante que se por algum motivo a ctbc não enviar todo o fullrouting(por problemas do tipo rompimento de fibra internacional, etc), estas redes que não forem aprendidas serão enxergadas por alguma outra operadora. Se eu usasse a segunda sintaxe (to any), o PBR ficaria estático. Dei exemplo aqui de CTBC mas isto é aplicado a qq BGP. Porque em alguns casos eu faço isto e não deixo que o BGP faça o papel dele de achar a rota mais curta para um destino? Porque muitas vezes, eu tenho um cenário de links de backup assimétricos, por exemplo: CTBC 300Mb GVT 100Mb e eu poderia ocorrer em uma situação de usar 90% GVT e só 30% CTBC. Então analiso a rede com netflow e as origens com maior tráfego são forçadas para a CTBC, por exemplo. É o feijão com arroz de qq ISP. Isto funciona muito bem e a gora vem a questão: A ideia é usar isto também no PFSENSE, sabem como é, a interface gráfica é algo muito útil. Porém me deparei com algumas dúvidas e não tenho como testar isto em laboratório: No pfsense, o que a interface gráfica chama de "aliases de firewall" são tables <table1> ou aliases mesmo $alias1? Para replicar o cenário que eu tenho hoje, pensei em configurar o bgpd.conf pela interface web, deixaria ele gerar um bgpd.conf "padrão" e depois, ativaria a opção de editar o bgpd.conf manualmente pela interface WEB e colocaria a linha "match"? Notei que ao fazer isto ele avisa que as alterações via WEB não serão usadas mais até eu apagar o que eu fiz manualmente. o que acham? Outra coisa, notei que no pfsense, as table do pf criada não são "persist". Assim, se o "alias de firewall" está vazio, não é criada a table, certo? Qual seria um truque, criar o alias e lá digitar um IP qualquer tipo 1.1.1.1, prá ela sempre ser criada(lembrando que esta table o bgp que vai popular) O que eu notei é que quando a table não tem nenhum IP, o PF não a cria, daí o openbgpd não preenche ela(claro, ela não existe) e só volta a preencher se eu matar e voltar o bgpd(nem um rbgpctl eload resolve). Por fim, a última dúvida: ao aplicar as alterações feitas na regra de firewall via web, o que o PF vai fazer com esta table, zerar ela e preencher com o que tem nos aliases, sobrescrevendo o que o bgpd populou? o problema todo, que me leva a fazer isto é que muitas vezes, meu gateway que fecha a sessão com a operadora está UP(então não posso usar os TIERS do PFSENSE em roundroubin/redundância), ou pior, até a sessão BGP estar UP, mas com 0 rotas recebidas. E aí o PBR de saída não vai chegar a lugar nenhum, eu teria que ter um técnico 24h alterando o route-to, hehe Como eu falei, o PBR de saída eu uso para fazer um uso mais racional de links de tamanhos diferentes(para o tráfego de volta eu tento fazer uma otimização divulgando redes específicas, usando no-export e famigerados prepends e por aí vai). Este PBR também pode ser usado para estratégias do tipo operadoras com SLA maior serão usadsa para clientes comerciais, etc, etc Obrigado e desculpem o email gigante novamente! ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
