[GTER] ServerU L-800 - Primeiros Passos

[Fabiano Ribeiro]

Patrick,

     Excelente texto e inclusive me explicou certos pontos que eu estava
confundindo.
      Na expectativa do desenrolar do netmap-fwd e pode contar comigo no
que for preciso para testar a solução.

Que venha a BSDCON.

Grande abraço.
Em 18/08/2015 23:33, "Fernando Frediani" <fhfrediani at gmail.com> escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter