[GTER] ServerU L-800+FreeBSD 10.1+OpenBGPD+Netmap

Wed May 20 14:14:52 -03 2015

Patrick,

       Muito obrigado por essa resposta, atendeu ao que precisava e
inclusive já me poupou um tempo bom de trabalho pois estava me
familiarizando com o PF nos meus testes :-)

Mais uma vez obrigado. Um abraço.

Em 18 de maio de 2015 11:00, Patrick Tracanelli <eksffa at freebsdbrasil.com.br
> escreveu:

> Fabiano,
>
> Sendo bem pragmático, minhas sugestões:
>
> 1 - na borda, *se* tiver real necessidade de filtragem use ipfw
> 2 - apenas regras stateless
> 3 - seus interrupt requests na placa de rede aumentam na proporção
> IRQ-RATE=(pps*nro_regras) então tenha a menor quantidade possível de regras
> de firewall, meia dúzia na borda é suficiente
> 4 - use e abuse de tables e especialmente tablearg pra fazer com 1 só
> regra o que você precisaria de várias (sumarizar regras, isso não é
> iptables… quanto menos melhor)
>
> Essas recomendações não tem nada a ver com FreeBSD+OpenBGPD, tem a ver com
> a borda. Você não vai fazer PBR nateado na borda, não vai usar route-to, se
> for usar algo será um ipfw fwd ou setfib com múltiplas tabelas FIB do
> kernel do FreeBSD, ou seja PBR sem tradução, então pare de pensar em PF. A
> integração do PF com OpenBGP permite coisas legais como
>
> match from any source-as 15169 set pftable google
>
> E pronto na table google voce terá todos os CIDR anunciados pelo AS do
> Google. Legal, talvez útil, mas não use PF pra isso, mantenha o filtro
> desligado se precisar dessa “facilidade” use um trigger qualquer pra jogar
> o que tem na table do PF pra uma table do ipfw e use-a com ipfw pro bem da
> sua caixa e sua performance. Apesar da integração ser legal é também pouco
> provável que voce va precisar e de fato usar.
>
> Ja o uso de netmap-ipfw não tem a ver com seu cenário, você teria que
> mudar a topologia e colocar outra caixa com netmap-ipfw protegendo a caixa
> com BGP :)
>
> Enfim, resumindo, o custo de ter firewall, mesmo meia dúzia de regras,
> será de 40% da performance. Quanto mais regras, pior esse custo. Com 400
> regras de firewall por exemplo, sua caixa que roteia 5Gbit/s não passará de
> 2Gbit/s.
>
> De volta ao PBR, fwd e setfib são muito mais leves que pf route-to e não
> onerará sua caixa mais do que uma regra de filtro convencional oneraria.
> Diferente da maior parte das outras implementações de PBR, normalmente
> divididas em etapas (route-mark, route-map, match de ACL no route-mark,
> tradução e tracking). Então um motivo a mais pra ipfw e não pf.
>
> Mas claro, estou assumindo que voce esteja na borda com perfil de uso de
> borda e venha a precisar de algo proximo de toda a capacidade da caixa pra
> funções… de borda ;) Mas se voce tem uma L-800 e não precisará tirar o
> máximo da caixa, talvez estejamos com preciosismo. Temos clientes, cidades,
> estados, que tem L800 com BGP e seus 300Mbit/s, 400Mbit/s de upstream e a
> mesma caixa faz firewall stateful, NAT, controle de banda, etc, cenários
> onde perder 40% ou 80% da capacidade de troughput da caixa não faz
> diferença pois ainda assim teria sobras pra necessidade do cliente nesse
> cenário.
>
> Bom ainda que seja um caso desses, continue preferindo ipfw.
>
> IPFW tem melhor performance em todos aspectos, e tem melhores capacidades
> de filtragem também, ipoptions, icmp administrative responses, IPv6, ou até
> mesmo um simples “iplen 0-19” é algo que você sequer, consegue fazer com
> PF. Veja bem não é que ipfw faz melhor, pf sequer faz… e na borda isso e
> recursos como antispoof, verify return path, verify source path
> reachability, são recursos que na hora que você precisar, é bom ter.
>
> Particularmente olho pro PF não como um firewall mas como um mecanismo
> poderoso pra fazer NAT ;) e todos os xunxos e gambiarras intrínsecas ao NAT
> como PBR traduzido, tracking de sessões traduzidas, gerenciamento de pools
> etc. Ou seja o melhor que o PF tem a oferecer, deve ficar longe de uma
> caixa de borda. Se precisa de NAT avançado e PBR traduzido provavelmente
> essa função deve estar em uma caixa mais pra dentro da sua infra, mais
> perto dos clientes, POPs, bem mais longe da borda. Ou seja voltando ao
> início, tudo se resume ao ponto 1 no começo do e-mail.
>
>
> > On 16/05/2015, at 18:36, Fabiano Ribeiro <
> fabiano.ribeiro at gerenciatec.com.br> wrote:
> >
> > Rubens,
> >
> >   Então, como disse hoje não preciso de PBR, mas quero já testar o
> recurso
> > caso seja preciso direcionar um tráfego para algum link. Como ela está
> aqui
> > em laboratório dando sopa já quero deixar testado a capacidade para saber
> > se posso contar com o recurso em alguma situação. Não preciso chegar ao
> > máximo da capacidade da ServerU agora.
> >
> >   Estamos fugindo da discussão inicial, que é saber qual o melhor
> firewall
> > para trabalhar no freebsd+openbgpd. Algum colega da lista trabalha com
> PBR
> > e qual firewall usa ?
> >
> > Em 16 de maio de 2015 18:21, Rubens Kuhl <rubensk at gmail.com> escreveu:
> >
> >> 2015-05-16 18:03 GMT-03:00 Fabiano Ribeiro <
> >> fabiano.ribeiro at gerenciatec.com.br>:
> >>
> >>>    Agora eu entendi porque que é difícil encontrar relatos de uso do
> >>> openbgpd+pf, pois no core não se utiliza firewall para filtragem de
> DDoS
> >>> (no meu caso está na camada de distribuição), mas para utilizar PBR
> >> baseado
> >>> em routing mark é necessário o mesmo, ou estou enganado ?
> >>>    Além disso, os colegas deixam desativado os recursos de firewall
> >> (seja
> >>> ipfw ou PF) no sistema ? Há realmente essa necessidade ? Sei que será
> >>> necessário threads a mais para processar o firewall, mas não vejo
> motivo
> >> de
> >>> deixá-lo desativado se eu quiser dropar um input na minha porta SSH. A
> >>> menos que se queira chegar ao máximo de Mpps da caixa.
> >>>
> >>
> >> Firewall de proteção do plano de controle é algo a deixar ligado,
> inclusive
> >> com stateful. Tráfego só de passagem pela caixa que é melhor deixar
> >> normalmente intocado, só filtrando quando for ataque à sua
> infra-estrutura
> >> (não a clientes, que você deve filtrar nos dispositivos que atendem os
> >> clientes).
> >>
> >>
> >> Rubens
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> Patrick Tracanelli
>
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> 316601 at sip.freebsdbrasil.com.br
> http://www.freebsdbrasil.com.br
> "Long live Hanin Elias, Kim Deal!"
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>