[GTER] ServerU L-800 - Primeiros Passos

Tue Aug 18 18:10:59 -03 2015

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