[GTER] Hardware ServerU L-100 / L-800

[Jonatas M. Victor]

 Srs,

   E na questão de redundância de hardware eles não tem fonte redundante.
Então eu trabalharia com eles como trabalho hoje, sempre com 2 caixas
operando em nobreaks separados e com operadoras
separadas  falando bgp entre si e entregando os 2 como gw no igp.
  Como vcs tem trabalhado esse cenário?


2015-02-25 12:54 GMT-03:00 Patrick Tracanelli <eksffa at freebsdbrasil.com.br>:

>
> > On 24/02/2015, at 20:32, Rubens Kuhl <rubensk at gmail.com> wrote:
> >
> > Qualquer x86 vai comer isso com farinha. O ServerU é legal pela
> integração,
> > consumo etc.,  mas 200 regras stateful é pouco para um PC.
> >
> >
> > Rubens
>
> Maais ou menos, mais ou menos. Infelizmente não é bem assim pra x86 ou
> qualquer outra arquitetura.
>
> O casfre perguntou sobre regras e não states. E uma regra é tudo que você
> precisa pra gerar milhões de states e esgotar sua RAM. Vira e mexe essa
> discussão acontece no NANOG, e os pontos sempre dão pano pra manga. Mas
> vamos simplificar, IPTables vai consumir 4K por state sem contará, 5 a 6K
> com conntrack. PF e IPFW vão gastar 4K de memória por state sem NAT. Dai ja
> é fácil observar que tenha 2G, 4G, 8G ou 128G de RAM, o recurso e finito e
> pode esgotar mesmo com 1 única regra.
>
> Isso independe da máquina, nada específico de ServerU, no site cada
> ServerU tem seus limites informados.
>
> Da mesma forma 1 regra é tudo que você precisa pra acabar com a CPU de
> qualquer máquina. Mesmo máquinas com mais processamento. Por exemplo, tenho
> um cliente, provedor (que está aqui na lista inclusive) que desvia um
> tráfego em paralelo tão alto de pro PeerApp que ele apenas 4 regras de fwd
> fazem uma máquina com quase o dobro de processamento da ServerU sentar (na
> prática, um Xeon 16 CPU @2.2Ghz) com apenas 4 regras de fwd. A solução pra
> isso existe, poderia-se fazer com netmap-ipfw ou com uma placa que faça o
> trabalho sujo ao invés de exaurir as CPU. Nesse cliente em específico o
> segundo caso foi que fizemos. Antes disso ele tentou com uma caixa cisco
> que também sentou, e uma caixa brocade que nem sei pra que ela se destina,
> mas também sentou. Uma máquina com mais CPU que a L-800 sentou, então a
> L-800 sentaria exceto se usasse a mesma estratégia de offload em hardware
> próprio, que no caso da SU teria pelo menos 3 opções a mais de expansões.
>
> Ou seja 50 mil regras num x86 pode não fazer nem cócegas; 4 regras (ou até
> menos) pode ser suficiente pra acabar com qualquer máquina. Na prática
> pouco importa o número de regras, um firewall muito mal feito com 50 mil
> regras que são sempre processadas e os pacotes só dão match na última, vai
> gastar menos CPU pra evaluation do kernel (system) do que a ação vai gastar
> de CPU com interrupções, principalmente se a ação não for um drop simples.
> Ações mais elaboradas como fwd, divert, tee, nat, route-to, mangle, serão
> mais CPU-intensive na efetivação da ação do que no evaluation das regras.
>
> Os limites de fato são sessões simultâneas e PPS filtrado. No caso das
> ServerU, estão no datasheet e está no site. Testamos individualmente com os
> sistemas de referência, e esses valores vão variar de sistema pra sistema,
> por exemplo:
>
> Aba “Firewall & IDS” - http://www.serveru.us/pt/netmapl800
>
> No caso da L-100 por exemplo (http://www.serveru.us/pt/netmapl100)
> podemos ver que um Linux vai suportar mais que o pfSense. E ambos vão
> suportar mais que um ROS.
>
> Se você esperar mais PPS e mais sessões do que está la, a máquina pode não
> dar conta. Independente do numero de regras carregada.
>
> Infelizmente a maioria dos fabricantes pouco se importam em testar e
> deixar claro onde estão os limites. Exceto iXsystems mas o foco deles acaba
> sendo outro. Nós tentamos ser o mais transparente possível pra indicar qual
> o limite das ServerU. E no caso de firewall o limite certamente não está no
> numero de regras.
>
> --
> Patrick Tracanelli
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
.:Abraços:.

<<< Jonatas M. Victor >>>
jonatas at jmv.eti.br
jonatasmv at gmail.com