[GTER] Socorro! 3.1Mpps UDP len 34-46 matando Juniper/MX5-T-DC

[Patrick Tracanelli]

> On 18/12/2014, at 14:04, Fernando Frediani <fhfrediani at gmail.com> wrote:
> 
> Ola João Carlos / Patrick,
> 
> Obrigado por compartilhar conosco a solução do seu problema, bastante discutido aqui na lista. Certamente sao esses tipos de experiências compartilhadas que fazem valer a pena participar deste fórum de discussão.
> 
> Com relacao ao equipamento esse Server-U ja conhecia porém nao a placa Chelsio T5.
> A ultima vez que olhei este ServerU estava em dúvida se ele ja possuía hardware built-in capaz de fazer packet processing afinal de contas no site diz que possui a tecnologia Netmap (similar ao Intel DPDK), mas pelo que entendi é necessário colocar a placa Chelsio T5 para isso ?
> 
> Diz também no website do fabricante que o equipamento é "Netmap ready" apenas para FreeBSD.
> Alguém tem experiência com a utilização deste equipamento com Linux (ou VyOS) e como isso se compara em termos de processamento de pacotes ? Alguma maneira de ter o Linux sendo capaz de utilizar Netmap (ou DPDK) mesmo que utilizando uma outra placa ?

Opa, boa tarde.

Só vi esse e-mail agora.

Alguns pontos importantes a notar é que a solução foi sim 100% Netmap, pra essa taxa de pps se fosse filtrar em kernel-path teria que ter uma máquina mais poderosa do que a L-800 e consequentemente aumentar o TCO. Então é sim algo possível por conta do hardware com esse recurso específico de software.

Fernando, por padrão o ServerU L-800 não tem hardware de processamento especial, não além de 8 processadores Rangeley de 2.4Ghz. No entanto temos expansões Napatech, Cavium e claro, minhas preferidas, Chelsio based. Nesses casos sim o ServerU ganha processamento especial asics para funções específicas, de ToE a firewall direto no hardware, passando claro por coisas bem mais comuns como aceleração de criptografia, etc. Tudo 100% testado e suportado em FreeBSD e sim, em Linux também. 

No caso do Netmap, nós só garantimos as métricas de performance pro FreeBSD (pfSense por consequência).

Existe Netmap pra Linux e é mantido pelo mesmo autor do FreeBSD (Luigi Rizzo), inclusive o Suricata funciona com Netmap em Linux tão bem quanto em FreeBSD. Mas nós não garantimos pra Linux pq normalmente o código é um pouco atrasado, commitado depois do que é terminado no FreeBSD então claro, nossa recomendação pra quem precisar de Netmap é que vá de FreeBSD.

Da mesma forma Linux tem suas opções próprias, essas sim amplamente testadas pela equipe de Miami no ServerU com ênfase em PF_RING e DNA (Direct NIC Access), tecnologias típicas do Linux, preferenciais pra Linux acima do que seria no FreeBSD onde ou elas não existem ou existem de forma experimental ou não oficial. Então cada tecnologia tem sua base primária e recomendamos que o que é de Linux que se use em Linux e o que é de FreeBSD que se use no FreeBSD. Quando existem opções portadas o cliente decide usar um Netmap em Linux ou DNA em FreeBSD, ele tem que entender e assumir que as métricas de performance podem (e provavelmente vão) ser diferentes.

Sobre ser necessário placa específica pra Netmap: não não é.

A Chelsio colocou em seu driver as instruções pra Netmap por conta própria mas o suporte a netmap é algo específico de cada driver/chipset. No caso da L-100 elas rodam com em(4), no melhor chipset da série em termos de I/O e non-blockness e todas as portas da L-100 suportam Netmap sem qualquer outro hardware (mesmo pq a L-100 não tem expansões de portas), e a L-800 roda com igb(4), com até 8 queues/threads por porta, e todas também com suporte pleno a Netmap, por isso ambos tem “Netmap” no nome. No caso das L-800 todas as expansões, sem exceção, suportam Netmap, DNA e DPDK.

Nossas expansões 1G/10G, elétrica (cobre), SFP e SFP+ são todas por padrão com chipset Intel então o suporte DPDK é requisito fácil de cumprir. E o suporte DNA/Netmap são requisitos complementares nos nossos critérios de homologação do equipamento na fase de projeto. O que acontece é que algumas expansões específicas podem ter ainda mais recursos. São o caso das citadas, Cavium, Napatech e Chelsio.

Netmap completamente diferente de DPDK na implementação, flexibilidade e “nível” de implementação, associado ao sistema operacional e drivers específicos. Por outro lado em arquitetura, é similar a DPDK mas não é a mesma coisa nem sinônimos. Sob aspecto de desenvolvimento e toda de decisão são concorrentes. Um projeto de alta performance de redes que queira tirar máximo proveito de processadores não específicos teria que optar. 

É algo mais pro lado “OpenCL vs CUDA” se fosse pra fazer uma analogia com GPU. 

Pra considerações técnicas mais respaldas que a minha sobre as tecnologias, tem um comentário do Luigi Rizzo aqui:

https://www.linkedin.com/groups/Just-wanted-understand-more-about-4842610.S.5857491307676594177

Onde chama atenção o trecho:

"Given that your application will be spending at the very least 100ns/pkt doing actual work (as opposed to I/O), so it does matter that you use some accelerated framework (netmap, DPDK, DNA) rather than a slow device driver, but the difference in performance between them is completely in the noise, and the choice should be on convenience of use and resource efficiency rather than performance.” 

Ou seja seja como for, se você for de DPDK, Netmap ou DNA/PF_RING, a ServerU vai te atender.

Só que na prática ou você é desenvolvedor, ou vai buscar tecnologia pronta. 

Nesse sentido onde existe implementado mais de uma dessas tecnologias, Netmap se destaca (Suricata suporta as 3, e Suricata com Netmap tem capacidade de captura superior a DPDK ou DNA segundo seus autores). Com netmap você tem um firewall completo, um scheduler de pacotes. Se for DPDK fora Suricata eu não sei se você tem alguma coisa de fato pronta pra usar e ai não adianta o hardware ServerU ou XYZ_ABC suportar não é mesmo? A gente nem cita o suporte  a DPDK no ServerU como um diferencial, ja que na prática você tem poucos serviços/recursos disponível pra uso geral/produção que tirem real vantagem do framework.

No caso do João Carlos na frente do Juniper tinha/tem uma Chelsio com firewall netmap filtrando a porta WAN dele com maior taxa de pps, e mais 2 portas WAN filtradas pelas interfaces nativas da L-800, não Chelsio (intel) mas também com firewall sobre netmap.

Filtrar 4Mpps com netmap foi mole! ;-)

Em kernel-path não seria possível com FreeBSD (ou Linux) na mesma máquina.
Por outro lado, sem netmap, a Chelsio na L-800 com FreeBSD livraria o João Carlos da pancadaria de qualquer forma.

E eu que agradeço ao João Carlos pela oportunidade ja que um cenário prático, de produção, é uma coisa; a teoria, na bancada, é outra. Então é sempre bom poder comparar os testes de bancada com a vida real, que foi o que tivemos a oportunidade.

--
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!"


> 
> Att.
> Fernando
> 
> On 17/12/2014 21:13, Joao Carlos Peixoto Ponce wrote:
>> Em quarta-feira, 3 de dezembro de 2014, Márcio Elias Hahn do Nascimento <
>> 
>>> marcio at sulonline.net <javascript:_e(%7B%7D,'cvml','marcio at sulonline.net
>>> ');>>
>>> escreveu:
>>> 
>>>> 
>>>> João, a título de curiosidade, que tipo de solução de firewall vc
>>>> colocou na frente do seu router?
>>>> 
>>>> Imagino que para barrar isso e não
>>>> causar atrasos seja uma solução bem robusta.
>>>> 
>>>> ---
>>>> 
>>>> Att
>>>> 
>>>> Márcio Elias
>>>> Hahn do Nascimento
>>>> (48) 8469-1819 / 3524-0700 -
>>>> marcio at sulinternet.net
>>>> GERÊNCIA DE RECURSOS DE TIC - Sul Internet [2]
>>> Boa pergunta, tbm fiquei curio$o.
>>> 
>>> 
>> Olá e
>> Desculpem a demora.
>> 
>> Aproveito a pergunta para agradecer publicamente ao Patrick Tracanelli que
>> se dispos a muito para me ajudar.
>> Quando meu problema estava sério e eu com uma boa conta diária a pagar por
>> uma box alugada da GLBX ele interviu e conseguiu emprestado uma placa
>> Chelsio T5 direto do Fabricante.
>> Se dispos a vir até minha empresa, sem custos (paguei apenas
>> transporte/hospedagem) e trouxe uma máquina dele, a famosa e aqui citada
>> várias vezes ServerU L-800.
>> Bom o resultado foi que eu consegui segurar e fazer muito mais com essa
>> dupla L800+T5 em um FreeBSD.
>> Então respondendo as dúvidas, esse é o meu firewall, um freebsd, que depois
>> dos 3.1Mpps já filtrou um novo pico de 4Mpps quando o ataque mais se
>> consolidou.
>> No meu cenário, eu só precisava de algo segurando o ataque contra meu
>> Juniper e resolveu.
>> Meu negócio fim é voz sobre IP e SalesForce. Na verdade não o meu mas o de
>> meu maior cliente, uma multi-nacional. O entupimento da minha largura de
>> banda na entrada nunca foi um problema então um firewall "em casa"
>>  resolveu meu problema.
>> 
>> Sugiro ao Patrick fortemente que exponha ao grupo, quem sabe em um futuro
>> encontro GTER, essa solucão. Pode contar comigo no estudo de caso.
>> 
>> Aproveito também para ajudar todos os demais que me ajudaram ou tentaram
>> ajudar. Temos ótimos especialistas em Juniper por aqui e fico feliz. Meu
>> problema se resolveu quase que em sua totalidade após downgrade do Juniper.
>> O que me acometeu não consta em nenhum bug formal da Juniper mas ao fazer
>> downgrade como sugerido/instruito pelo Rodrigo, resolveu o maior problema
>> de excesso de CPU/interrupcão quando desativava o firewall.
>> Depois o Diogo, e outros tantos tentaram me ajudar diagnosticar o problema
>> residual quando a taxa de pps ficava acima de 600Kpps mas a verdade é que
>> ontem fez exatamente 1 semana que os ataques simplesmente pararam.
>> Ou seja com ou sem firewall o volume de ataque não chega mais.
>> Então os últimos comandos e tentativas de ajuda eu não consegui até hoje
>> executar.
>> Já que sem ataque ou com firewall ligado o MX/5 segue de vento em poupa.
>> Hoje já fiz a aquisicão tanto da L800 quanto da Chelsio e fazem parte do
>> meu arsenal de crise.
>> Espero nunca mais precisar usar esses equipamentos pra essa finalidade mas
>> se precisar sei que bastará ligar a energia.
>> Pois está em bridge na frente do meu router.
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter