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

[Marcos Tadeu]

Basta fazer a pergunta certa: número de regras vezes PPS. E ainda assim, 
depende de quem configurou. Por exemplo, se está ativo o SYN Cookie, que 
ao chavear devido a muito SYN num serviço, e se não tiver 
respostas/continuação da conexão, interrompe a alocação de memória e 
manda o pkt para /dev/null...
Também temos o NETMAP framework, com módulo kernel p/ freeBSD e Linux, 
que muda muito este cenário.
Claro, com IP spoofing pode-se gerar um DoS. Mas não senta por falta de 
memória.

On 02/25/2015 12:54 PM, Patrick Tracanelli wrote:
>> 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