[GTER] ServerU L-800 - Primeiros Passos

[Fernando Frediani]

Patrick, obrigado pela aula. Fantástico !

Acho que um dos melhores emails que ja li na GTER desde que estou na lista.

E quando tiver coisas prontas como netmap-fwd, pra quem não puder estar na
BSDCon, se puder mandar um resumo aqui ou publicar em algum lugar tenho
certeza que vai interessar a muita gente.

Abraços.
Fernando
On 18 Aug 2015 23:00, "Patrick Tracanelli" <eksffa at freebsdbrasil.com.br>
wrote:

>
> > On 14/08/2015, at 13:38, Danilo Bedani <dbedani at gmail.com> wrote:
> >
> > Boa tarde pessoal,
> >
> > Adquiri um ServerU L-800 após várias buscas nesta lista, e constatar que
> > falam muito bem do equipamento.
> >
> > Já utilizo FreeBSD há um bom tempo, mas não possuo conhecimentos
> avançados,
> > e hoje quem faz roteamento BGP em minha rede é um server DELL R210 com
> > FreeBSD e Quaga.
> >
> > Gostaria de pedir aos que já possuem experiência, tanto em BSD como no
> > próprio ServerU, como tirar o máximo de proveito deste equipamento. Ele
> > veio na configuração padrão, 6giga ethernet e 4Gb de memoria RAM.
> >
> > Minha intenção é usar para roteamento BGP, com 2 operadoras Full Routing
> +
> > PTT-SP.
> >
> > Sei que o interessante deste equipamento é usar com o netmap, mas como
> faço
> > isso? Basta compilar um kernel com o device netmap e basta?
> >
> > O que mais é necessário para "tunar" o FreeBSD?
> >
> > Aos que puderem colaborar, agradeço!
> >
>
> Danilo, boa noite.
>
> So agora vi essa thread na GTER, desculpe a demora.
>
> Em primeiro lugar, acho importante ressaltar, todos os números que você vê
> no datasheet das máquinas ServerU, tanto nas métricas de roteamento quanto
> nos testes de RFC-2544, são números que envolvem encaminhamento de pacotes
> numa topologia tipica sender<->DUT1<->receiver conforme a RFC em questão,
> ou seja fluxos bidirecionais de encaminhamento nas combinações de portas
> discriminadas na RFC.
>
> Resumindo, os números que você vê são kernel-path, e você vai conseguir
> esses números em um FreeBSD convencional, ou Linux, com as diferenças de
> performance, onde houver, documentadas nas abas específicas do site e do
> datasheet. Mesma coisa pras diferenças de performance com firewall, sem
> firewall, etc. Ou seja em primeiro lugar você precisa saber que os números
> divulgados não dependem de Netmap e não dependem de nenhum hardware
> especial. Exceto claro que pra alcançar os 5.5Gbit/s bidirecional que a
> caixa em questão (L800) comporta, você vai precisar de um par de portas
> 10G, uma expansão mínima que não acompanha a maquina e ai sim seria algum
> hardware a mais, mas não especial. Sem a expansão você consegue performance
> a máxima documentada no teste da RFC-2544 envolvendo os 3 pares (6 portas)
> giga default da caixa.
>
> Tendo isso em vista, vamos ao Netmap.
>
> Netmap não é algo que você liga, e turn-key, está funcionando. Muito pelo
> contrário. É uma abordagem nova que por natureza é completamente diferente
> de tudo que é feito hoje no kernel do FreeBSD. É uma tecnologia que,
> simplificando ao extremo, permite o mapeamento dos rings do hardware
> diretamente no backplane pra uma camada de abstração exposta pra userland
> (o device netmap), oferecendo um ring individual pra cada queue (fila) da
> placa de rede. Envolve-se um mínimo de kernel na exposição desse device, e
> envolve malloc() nativa pra impor controles e separação de privilégios
> (isolamento), sem permitir acesso direto e não controlado à memória -
> primitivas de segurança mínima cumpridas.
>
> Em essência, em modo Netmap a interface “pula” o kernel e tudo que se
> conhece no sistema operacional e que passe/dependa do kernel. Por isso não
> tem como ser absolutamente nada turn-key. Eu dei uma palestra recentemente
> sobre isso no BHack em Belo Horizonte, no The Lab em Miami e planejo
> repetir essa visão e entendimento geral na BSDCon BR. Essencialmente tudo
> que voce precisa em modo netmap precisa ser feito. Desenvolvido mesmo,
> “show me the code”. Se quer vlan em modo netmap, tem que codar. Se quer
> filtro, tem que codar, e claro se quer roteamento, mesma coisa.
>
> Mesmo estatísticas simples como RX, TX, colisão, drop, você não tem. O
> netstat (kernel-path) não “vê” nada, por exemplo, de uma interface em modo
> Netmap.
>
> Essa abordagem é de longa data vista e discutida por “cientistas”,
> pesquisadores, researchers em geral. Existem várias visões, similares,
> discrepantes, ou muito similares.
>
> A saber, PF_RING no Linux, DNA (Direct Nic Access) também no Linux, ambas
> abordagens essencialmente mantidas e defendidas (criada originalmente) pelo
> italiano Luca Deri, (autor do ntop), que hoje trabalha na mesma
> Universidade de Pisa, na Itália, no mesmo departamento onde o Luigi Rizzo
> manda/coordena (the Boss hehe), Rizzo é o autor do Netmap, e picobsd,
> dummynet, ipfw2, QFQ, e tantas coisas expressivas no FreeBSD.
>
> O que esses italianos fizeram, eventualmente sem trocar figurinhas e sem
> se conhecer, a Intel também resolveu pensar e abordar do jeito dela, e
> criou um conjunto de libs e um tool kit pra acesso direto ao Data Plane das
> placas de rede dela pois ela também acredita que consegue tirar muito mais
> de um chip Intel do que os sistemas tiram hoje. Veio ao mundo o DPDK (Intel
> Data Plane Dev Kit).
>
> Como Netmap se compara ao DPDK por exemplo vc pode ler nas palavras do
> próprio Luigi Rizzo:
>
> https://www.linkedin.com/grp/post/4842610-5857491307676594177
>
> Um paper recente feito em conjunto pelo Luigi Rizzo e o Luca Deri agora
> que eles trabalham juntos, sugere que o Luca está adotando Netmap e
> colocando um pouco das ideias que ele teve com DNA e PF_RING em trabalhos
> recentes (http://luca.ntop.org/).
>
> Bom pulando a parte cientifica, research, etc, vamos a prática. O que é
> interessante no Netmap, além de, na minha opinião, ser um framework mais
> simples, paupável - com 12 linhas de código voce coloca a interface em modo
> netmap e começa circular o ring e tem acesso aos pacotes na queue, a 13a
> linha já é seu próprio código e o inicio da solução que você busca - ele ja
> nasceu com aplicações e bibliotecas base de referência que mostraram e
> provaram o potencial do Netmap:
>
> - bridge (como nome sugere, uma bridge em line-rate com uma CPU de 1Ghz)
> - pkt-gen (gerador e receptor de pacotes em line-rate com menos de 1Ghz de
> CPU)
> - libpcap (todo programador Linux abre um pcap ao invés de um bpf, ou seja
> modo promiscuo, interceptação de pacotes em modo netmap, está pronto basta
> usar)
>
> Nao bastasse isso em algum tempo o Luigi Rizzo evoluiu a aplicação do
> Netmap e colocou:
>
> - vale (interfaces virtuais em modo netmap)
> - click modular router
> - openvswitch
>
> E finalmente o ápice até agora:
>
> - netmap-ipfw
>
> Ou seja hoje, com Netmap você consegue com apenas 4 CPU Rangeley 2.4Ghz
> (ServerU L-800) ou 4 Xeon de 2.2Ghz, fazer firewall line-rate com 4 threads
> em 4 queues (de 8 padrão de uma porta igb(4) ou ix(4) e filtrar quase
> Line-rate. Eu tenho em produção, 3 clientes que ja chegaram a filtrar
> 9Mpps, incluindo com Dummynet, perto dos 14.8Mpps de line-rate num setup
> que te custa menos de 7 mil reais (ou menos se a Dilma parar de
> atrapalhar), isso é expressivo. Da pra chegar em 14Mpps? De acordo com o
> Rizzo da pra chegar a 12Mpps, eu nunca cheguei, nunca tomamos um ataque
> desse nível, mas 9Mpps tenho aqui rodando no pico.
>
> Eu pessoalmente tomo muito cuidado com números. Pra não criar expectativa
> demais, por exemplo isso que eu estou dizendo alguns clientes no Brasil e
> nos EUA ja mencionaram e expuseram. Quando eles se expuseram, eu reproduzo,
> mas tomo esse cuidado porque por não ser turn-key e sempre depender de
> alguma mudança ou ter dependências específicas inclusive tipológicas, é
> sempre delicado criar expectativas sem antes deixar claro que é preciso
> antes de mais nada preparar o ambiente pro Netmap, e não adotar Netmap no
> seu ambiente. Além disso os limites e números por serem altos, da pra
> testar até onde da pra testar em lab, mas em produção sabemos que diverge
> dos labs mesmo dos testes mais seguros. Então certeza base é que em modo
> Netmap se vai bem mais longe que em kernel mode, mas até onde é esse mais
> longe vai variar e precisa ser quantificado estatisticamente em diversos
> cenários. Os que eu trabalho por exemplo não são típicos, são de ataque,
> são de alto pps e baixo avg len de pacote. É preciso mapear onde estão os
> limites e as linhas de divergência na performance pra ter expectativa
> segura, e pra isso existe a necessidade da maior adoção.
>
> Hoje no ProApps (“nosso” FreeBSD, da FreeBSD Brasil) temos uma versão
> própria do netmap-ipfw que ja sobe multithread conforme queues
> configuradas, etc.
>
> Na interface visual (GUI) o cliente faz as regras dele e escolhe se quer
> kernel-path ou netmap-mode e escolhe os port-pairs e pronto. Envolve
> topologia, o netmap-ipfw depende da topologia ser em bridge, não pode
> rotear, não vai fazer fwd pra uma porta fora do port-pair, etc. Tem n
> “detalhes” que precisam ser considerados no projeto, mesmo estando pronto e
> tendo uma GUI, não é turn-key. Mas é plenamente funcional. E bem facilitado
> no ProApps por exemplo.
>
> Bem e o que mais temos com Netmap?
>
> - Suricata (Detecção de Intrusão) roda em modo Netmap, muito bem obrigado.
> Line rate pleno com 14Mpps de interceptações em porta de 10G com apenas 1
> CPU de 2Ghz Rangeley. Todas as outras CPU ficam pro engine processar as
> regras, mas a captura é line-rate; obrigado; de nada; e funciona
> lindamente. Se você vai ter CPU suficiente pro resto do que um IDS precisa
> fazer depende da arquitetura e projeto de segurança. Não querer abraçar o
> mundo, Defense in Depth, Security Layers, conceitos básicos quase sempre
> negligenciados, mas que envolve escolher as regras certas, no Tier certo de
> defesa. Mas o modo Netmap cria um alívio consideravel no Suricata.
>
> OK e o que provavelmente a maioria aqui quer saber, roteamento.
>
> Hoje é possível rotear em modo Netmap, tanto no click (click modular
> router), quanto no openvswitch. Como pouca gente usa o primeiro e nele a
> coisa é mais legal que no segundo, fica um buraco negro de desconhecimento
> e pouca gente se da ao trabalho de clicar no Link no site do Rizzo e ver
> como montar um cfg com click roteando, provavelmente pq a pessoa ja conclui
> que não é aquilo que ela quer e provavelmente não é mesmo.
>
> Enquanto se consegue rotear com click em modo netmap, bem, é o click. E
> tudo tem que ser do jeito dele, da aplicação. Quase sempre voce envolve
> limites, rotas apenas estáticas ou “adaptacoes" pra importar rota de outra
> origem, como um OSPF da vida.
>
> E então não da pra rotear em modo BGP com Netmap na L-800? Da, claro que
> da. Com click e o limitado BGP do click. Pro seu daemon de referencia a
> resposta é não, não dá. Não ainda.
>
> Bom ai vem a segunda parte da conversa. Pra tentar resolver essa questão,
> nós “estamos trabalhando nisso”.
>
> Há algum tempo o loos@ e eu começamos um projeto, design de uma solução
> pra roteamento, que fosse uma interface simples, parecida com o que temos
> com o netmap-ipfw, mas algo mais flexível, podendo definir diversas
> interfaces, e que claro implementasse todas as primitivas necessárias pra
> encaminhamento de pacote. E ai estamos falando de fato de começar coisas do
> zero, subsistemas mínimos como ARP, icmp, tem que ser implementados em modo
> Netmap. Requisitos funcionais como filtros, vlan, também precisam ser
> implementados. Bom, bla bla bla a parte, não quero entrar nos detalhes
> ainda pois as honras vão ficar com o Loos no momento adequado, ele está
> aqui na lista e alinhamos até que ponto iríamos expor as informações antes
> do “show me the code” -- e depois a gente deve escrever um paper sobre isso
> hehehe ;-)
>
> O fato é que hoje temos algo, em algum nível de funcionamento, chamado
> netmap-fwd. Ele faz o roteamento em modo netmap, tem uma interface que
> permite atualização da FIB do netmap-fwd com alguma aplicação externa (seu
> daemon BGP certamente, em algum momento, ou um trigger do kernel mantendo a
> FIB do kernel em sincronia com a FIB do netmap-fwd, enfim algo em design
> ainda).
>
> Esse trabalho está sendo financiado pela ServerU e o Loos vai apresentar o
> netmap-fwd pro mundo na BSDCon Brasil, em fortaleza.
>
> Hoje ja temos alguns números, esperamos ter mais números e mais cenários e
> esperançosamente ótimas noticias até Fortaleza. Em algum momento esse
> codigo vai claro, todo pra base do FreeBSD sob licença BSD. E ai vai ser
> possível ter uma “receita de bolo” ou um “por onde começar” ficando em
> aberto as possíveis variações de como fazer da melhor forma possível. E
> como todo software livre depois de exposto, a esperança é que outros
> desenvolvedores aprimorem, dêem boas ideias e implementem novos recursos.
>
> Mas por hora existe essa nossa tentativa de tentar fazer algo novo, do
> zero, da melhor maneira possível pois assim como muitos aqui eu também
> quero meu BGP em modo Netmap. E diferente da maioria, que não deve ter
> testadoa interação BGP com click, a última coisa que eu quero é abandonar
> “meu daemon" de referencia hehehe, seja ele OpenBGP ou BIRD (tem que goste
> de Quagga, kkk eu prefiro os olhos… :P).
>
> Ou seja o que existe hoje existe, funciona, mas não me agrada, e se não me
> agrada eu não recomendo. Mas pode haver quem discorde de mim e se sinta a
> vontade e confortável pra usar o click router, então se alguém quiser
> tentar fica a dica: click, no site do Luigi. Essa seria a resposta final
> pra thread :-)
>
> Eu tenho esperança que consigamos algo bem bacana e com o nível de
> funcionalidade e integração que a comunidade BSD mereça. Mas ainda assim,
> se tudo sair exatamente como planejamos, e em alguns meses tivermos um
> netmap-fwd funcional por ai, ele certamente não será turn-key, a proposto
> do Netmap não é essa. Talvez existam distinções topológicas fundamentais.
> Por exemplo a gente não vai implementar coisas como Q-in-Q em modo Netmap,
> ou CARP que seja. Então é provável que existam situações onde a sessão BGP
> é fechada por fora do modo Netmap, em interfaces kernel-path, mas o
> roteamento em si (next-hop e reachability) aconteça em portas em modo
> Netmap. Inclusive essa é minha linha de trabalho de escolha, senão preciso
> hackaer meu daemon pra ele ouvir e bindar em modo netmap, a porta TCP/179
> do BGP. E eu não quero ter um daemon em modo BGP dando trabalho pra ser
> mantido so pra sessão BGP fechar. BGP é algo que por natureza é simples,
> leve, e o ideal é que continue assim (especialmente simples).
>
> Bom é isso. Espero ter ajudado a esclarecer as duvidas que, compreendo,
> são grandes, e é normal não ter muitos retornos mesmo sobre isso.
>
> Apesar do Netmap em si não ser mais algo “novo” (alguns anos ai) ainda é
> uma dessas coisas que existem no FreeBSD (tipo MAC, Capsicum, OpenCL)
> extremamente poderosas mas que pouca gente está explorando. Sabe como é em
> 1999 no FreeBSD 3.4 com IPv6 era assim também (IPv6? E o v5 pulou? era a
> brincadeira infame — “ha ha”, by Nelson) ou em 2005 quando o -CURRENT
> ganhou SCTP, que so virou -STABLE em 2008, e mesmo a comunidade tendo
> conhecimento dos limites do UDP/TCP olha a adesão do SCTP, quase nula e
> ainda científica mesmo estando até no GENERIC. O Netmap não está nessa fase
> ainda, de estar no GENERIC. Aos poucos isso evolui.
>
> Como uma tecnologia nova e promissora, é preciso fomentar e acima de tudo,
> explorar. O que a gente fez quando decidimos colocar “Netmap” no nome das
> ServerU foi uma estratégia para, em primeiro lugar, divulgar a tecnologia e
> o potencial de se conseguir ir além. Em diversos pontos ja com sucesso
> (firewall, IDS, ..) em outros ainda trabalhando (BGP), e principalmente
> chamar a atenção pra algo novo, com grande potencial. Nosso objetivo sempre
> foi ter um hardware que suporte e atenda requisitos pra melhor das
> tecnologias. Claro, mas máquinas ServerU por uma questão indireta também
> suporta plenamente DNA, DPDK, mas nós por motivo óbvios preferimos divulgar
> e temos melhores expectativas com Netmap. Como demorou pra ter uma boa
> opção agora estamos tentando inverter e ter um pedaço de software que tire
> melhor proveito desse hardware também pra roteamento não estático.
>
> E tem muito mais pra explorar depois do mundo Intel.
>
> Depois da Intel, veio a Chelsio, e hoje os chip T5 inverteram a lógica da
> jogada e é o próprio fabricante (Chelsio) quem suporta, oficialmente
> Netmap, e não é um Netmap qualquer, é acelerado por hardware (ASICS). Ou
> seja tem muito campo promissor a ser explorado, mas antes precisamos passar
> da fase PoC e terminar os fundamentos da ideia e validar de verdade isso
> tudo sem depender do click modular router.
>
> Então é isso. A continuação e desenrolar dos próximos capítulos é com o
> Loos em Outubro em Fortaleza. Claro que todos vão pra Fortaleza certo?
> Então combinado...
>
> Bora pra Fortaleza então :D www.bsdcon.com.br ;-)
>
> --
> 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