[GTER] ServerU L-800 - Primeiros Passos

[Paulo Henrique - BSDs Brasil]

On 18/08/2015 23:28, Fernando Frediani wrote:
> 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

Valeu Patrick, por fazer eu perder mais de 20 minutos lendo esse monte 
de coisas interessantes que saltou-me aos olhos de querer estudar mais, 
mesmo não tenho aplicação inicial para isso ou estrutura !!

Mas deixamos de puxa-saquismo ( não sei como se escreve ) e vamos as 
duvidas.

Netmap é simplesmente uma interface de comunicação não assistida pelo 
kerneland entre o hardware e uma aplicação distinta, userland, ( isso 
ficou muito claro o hardware processa e o software toma a decisão ) 
agora com relação a segurança ( não me informei nada sobre isso, netmap 
é novo para minha pessoa ), se tiramos metades dos atributos de 
segurança que o kerneland oferece diretamente fica a pergunta, é de 
responsabilidade da aplicação lidar com tais potenciais falhas de 
segurança ou do hardware ? A partir daqui surge mais uma infinidade de 
perguntas !! Algumas abaixo.
  - Como se corrige um bug no hardware quanto algo muito importante é o 
alvo, ele é calcanhar de Aquiles da solução pelo que notei,  visto que 
todo o processamento da chelsio está no hardware um bug ou falha de 
segurança poderá impactar negativamente uma area ( recurso ) enorme !!! 
como seria tais condições tratadas ? troca do hardware? desativação do 
modo netmap? ativação de backup que poderá lidar com a carga no qual o 
netmap conteve ?
- Ainda na parte de hardware e relacionado a segurança. Não tenho 
claramente o conhecimento e vivência do Sr. para questionar isso, mas o 
netmap não seria um potencial backdoor para falhar de segurança no qual 
o FreeBSD poderá não estar evoluído para lidar ( hardware ultrapassando 
kerneland sem vigília ) ? essa pergunta é interessante visto que 
conforme a pergunta anterior o netmap ultrapassa significativamente os 
recursos on-kernel de segurança deixando toda a carga de decisão para 
uma aplicação userland que poderá ser comprometida através do netmap. ( 
acho que é a mesma pergunta anterior com palavras diferentes. )
- Essa questão não é mais com relação a tecnologia diretamente, mas 
mercadológica. A principal diferença dos atuais fabricantes de hardware 
de comutação e roteamento é a capacidade de encaminhamento de pacotes e 
nos últimos 10 anos sistemas open-sources começaram a encomodar um nicho 
de mercado muito seleto, em pouco tempo uma caixa MX-5 da Juniper ou um 
Cisco ASR9001 serão 4 vezes mais caras que um L800 que possui 8 vezes 
mais recursos ( Inicialmente observados ). Há riscos de tais fabricantes 
começarem uma campanha negativa para tais inovações ? sempre considero 
que dinheiro fazem humanos a fazerem ações inumanas e não compreendo 
como o mercado está lidando com uma caixa que tira os seus produtos de 
entrada do foco, e isso é claro a dois anos atrás Juniper MX5 e Cisco 
ASR 9000 series era a primeira indicação de quem ultrapassava a barreira 
dos 1 Mpps tanto na GTER, FUG e demais listas, hoje é o L800 que 
diferente do mikrotik veio para concorrer de igual para igual com 
grandes nomes e que em determinado momento superou as expectativas de um 
MX-5.

Gosto de questionar e possuo uma gama bem grande de pontos negativos a 
salientar para colaborar, no aguardo da resposta do Sr. ou de quem se 
prontificar para continuar o debate.

Uma ótima noite e semana pela frente, essa thread ficará longa se 
depender de mim. :-D !!!

-- 
Paulo Henrique.
Grupo Brasileiro de Usuários de FreeBSD.
Fone: (21) 96713-5042