[GTER] rede 40G para vmware e gbic qsfp+

[Fernando Frediani]

Obrigado Patrick. Bastante esclarecedor.

Acredito que um sonho de consumo que falta hoje é:

- ServerU + VyOS + DPDK/Netmap/PF_RING

Ou qualquer coisa parecida que faça o VyOS ter performance semelhante ao
FreeBSD com netmap.

Fernando

2016-10-03 13:27 GMT-03:00 Patrick Tracanelli <eksffa at freebsdbrasil.com.br>:

>
> > On 03/10/2016, at 10:45, Eduardo Schoedler <listas at esds.com.br> wrote:
> >
> > Em segunda-feira, 3 de outubro de 2016, Fernando Frediani <
> > fhfrediani at gmail.com> escreveu:
> >
> >>
> >> Tem um case conhecido na NANOG em que a pessoa descreve o uso de ServerU
> >> L-800 com portas de 40G e picos se não me engano de 11Gb. Alguém se
> lembra
> >> qual marca de placa foi utilizada ?
> >>
> >
> > Chelsio T580-CR
> > https://mailman.nanog.org/pipermail/nanog/2015-May/075351.html
> >
> > Forwarding todo em hardware.
>
> Fernando / Eduardo,
>
> Sim, esse cliente especificamente usa a T580-SO-CR no caso. Ambas tem
> forwarding por hardware, line rate sem encostar na CPU. Pra atividades como
> roteamento, firewall, as chelsio -SO-CR tem melhor custo beneficio
> (Stateless Offload), as que tem os offload stateful são importantes pros
> outros recursos, normalmente associados a virtualizacao, data center, HPC,
> infiniband etc.
>
> Nós não “anunciamos” a L-800 com portas 40G porque não faz sentido, na
> prática. A L-800 não tem torque pra empurrar mais do que 5.5G sem netmap e
> sem DPDK, ou seja 2x10G ou 4x10G é a melhor combinação de densidade de
> portas e capacidades que faz sentido. Claro que dependendo do cenário tem
> quem precise de 2x40G mas é bem específico e ai informamos que até pode,
> mas é uma completa subutilização das portas por “falta de torque” da caixa.
>
> Outro ponto que surge muito interesse, e-mails em particular, é sobre o
> roteamento direto no ASICS.
>
> Funciona muito bem pra OSPF, rotas estáticas e afins. Esse cliente em
> específico que é da SU America, é um cliente que usa uma versão de um
> daemon “experimental” do ProApps. As Chelsio tem um limite de 2000 “regras”
> que podem ser escritas no firmware nas -SO-CR e “10.000” nas com memória
> externa. Em ambos os casos, é suficiente pra 90% dos casos de uso, mas pra
> BGP não. Cada regra de roteamento tem que ter uma rule no firmware. Ou
> seja, com isso temos limite de 2k ou 10k rotas instaladas direto no ASICS.
>
> O que nós fazemos em alguns casos, incluindo esse cliente, é usar um
> mecanismo parecido com o que temos no netmap-rt, onde algumas threads do
> daemon atuam em modo monitor e ficam aguardando o daemon BGP escrever as
> rotas na FIB, e quando isso acontece nós consultamos a FIB e olhamos o
> routing counter, que o kernel do FreeBSD tem, indicando quantas vezes cada
> rota foi usada. Com base nesses eventos, periodicamente o que nós fazemos é
> elencar as 10k ou 2k rotas mais “populares” que usam portas ou vlans
> chelsio, e esse daemon escreve essas rotas no ASICS.
>
> Claro que na prática, alivia muito, afinal 2k rotas mais “usadas”
> representam por baixo 80% do que o roteador faz em frequência / pps, então
> é essa a taxa de offload que se consegue. Essa thread ao levantar o route
> count tem que considerar que só pode instalar nas chelsio o que envolve
> chelsio com chelsio. Ou seja as rotas que envolvam as portas 1G Intel da
> ServerU tem que continuar em kernel, fora do ASICS, mesmo que sejam
> populares.
>
> Outro ponto é que a convergência de rotas na Chelsio é bem mais lenta,
> enquanto a gente coloca 600k rotas na FIB em um tapa, no ASICS levo ate 30
> segundos pra 2k rotas. A consequência é que funciona bem em ambientes com
> BGP mais “calmos” onde existe certa estabilidade e as mensagens de UPDATE
> ou WITHDRAW não acontecem na pancada (ja que um update ou remoção de rota,
> se estava na Chelsio, tem que ser feito na hora, não pode esperar). Mas em
> situações com BGP caindo, subindo, o tempo todo, a potencial demora pra
> tirar a rota do ASICs pode implicar em problema, mais expressivo do que a
> demora em rever as novas rotas mais populares.
>
> Portanto, infelizmente, não chegamos em um meio termo pra ter uma solução
> profissional e ofertar / divulgar o roteamento em ASICS para ambiente BGP,
> poucos clientes usam, alguns tiveram problemas e preferiram tirar e ficar
> só em kernel ou netmap. Outros continuam usando e estão felizes da vida
> roteando 8Mpps, 9Mpps com 2 ou 3 sessões BGP estáveis e fazem até a
> propaganda boca-a-boca que é esse caso na NANOG. Mas está longe de ser “one
> size fits all”.
>
> Achei importante esclarecer aqui porque muita gente vem até nós e quer
> usar isso também que os satisfeitos estão usando. Podem ser que voce goste
> do resultado, pode ser que não seja viável, cada caso é um caso pra BGP
> FULL multihomed. Claro que tem aqueles casos que o cidadão tem BGP FULL mas
> um partial seria suficiente, casos que tem PTT + um FULL com uma operadora
> só (que portanto deveria ser default route mas é “chique” ter full, nesses
> casos todos o cenário é altamente viável e o índice de satisfação com o
> resultado é alto. Mas claro, de novo, não se aplica a todos.
>
> Outra solução porém que tem se tornado muito popular la fora, é o uso do
> vRouter 5600. Me parte o peito ehhauhauha eu preferiria poder ja estar
> nesse nível com o netmap-rt mas ainda não estamos, o vRouter porém está
> muito estável e maduro. Olha os números:
>
> http://www.serveru.us/en/netmapl800 (Performance => Routing performance)
>
> - ProApps, FreeBSD, pfSense     2.89Gbit/s forwarding rate on DUT1;
> 1.35Mpps/s forwarding rate on DUT1;
> - Linux (RHE & Fedora)  2.89Gbit/s forwarding rate on DUT1; 1.35Mpps/s
> forwarding rate on DUT1;
> - Brocade vRouter 5600 (DPDK)   23Gbit/s forwarding rate on DUT1; 6.8Mpps
> forwarding rate on DUT1;
>
> Não, esses números não são “números mágicos do comercial”, não é
> propaganda política. São reais, e essa taxa é a real conseguida em vários
> provedores e empresas nos EUA, Canada, México e Australia. E sim a
> diferença é gritante, de 1.3Mpps (2.7Mpps com portas 10G) em FreeBSD/Linux
> pra 6.8Mpps, de 2.9Gbps (5.6Gbps máximo, com expansões 10G) pra 23Gbit/s.
>
> O trabalho que a Brocade fez no Vyatta ao rescrever o dataplane em DPDK é
> de impressionar, e o vRouter 5600 entrega isso tudo com DPDK. Com netmap-rt
> eu consigo entregar mais que isso hoje, mas ainda não é um produto
> pronto/estavel, consideramos ele ainda experimental:
>
> http://support.serveru.us/index.php?/ServerU/
> Knowledgebase/Article/View/91/20/proapps-routing-in-netmap-
> mode-with-netmap-rt
>
> Nos EUA a Brocade certificou a L-800 como “bare metal” compatível, e a
> ServerU suporta o vRouter oficialmente, inclusive com uma imagem propria,
> os drivers de bypass, LCM ja instalados e o dataplane “unshielded” (que é
> uma proteção contra sobrecarga e bugs nos Hypervisor pra evitar que todas
> as vCPU fiquem dedicadas ao dataplane e falte CPU pro control plane e
> kernel mesmo com affinity). Na L-800 não precisa desse CPU Shield e tem
> máxima performance quando vem unshielded. o vRouter 5600 pra L-800 ja vem
> “pronta” bastando a pessoa entrar com a licença trial ou a definitiva se
> resolver usar.
>
> Ainda não divulgamos pesado no Brasil essa possibilidade, mas fica a
> consideração. O custo do vRouter 5600 está na casa de 6k dólares. Não é a
> coisa mais cara do mundo, mas não é uma decisão de olho fechado também. Por
> outro lado os 30 a 90 dias de trial com o 5600 permitem tomar essa decisão
> com segurança.
>
> Por motivos exclusivamente comerciais, o vRouter 5600 ainda não funciona
> em Chelsio, só Intel.
>
> Em 100% dos casos que esses clientes estão usando vRouter 5600 com
> ServerU, são pessoas que vem de VyOS e ja estavam acostumados, e procuram
> um roteador “bare metal” certificado pro vRouter. Em diversas revendas nos
> EUA em especial os distribuidores Brocade da Costa Oeste, eles ja
> recomendam ServerU. A ServerU em contra-partida não é integradora Brocade
> então quem decide comprar o vRouter compra com os parceiros Brocade e quem
> quer metal e não vCPU compra ServerU. Tem funcionado bem.
>
> Então, estou aproveitando esse e-mail (inclusive erroneamente até numa
> thread inadequada hehe, de tanto que fugiu do assunto) pra tentar elucidar
> esses “use cases” possíveis, com ServerU + alta performance. Que da pra
> sumarizar:
>
> 1) ServerU + Chelsio + Roteamento no ASICS: limitado a 2k ou 10k rotas no
> ASICS, até 30s pra convergência total, adequado pra OSPF, estatico e setups
> BGP mais simples, line rate garantido (ou 13Mpps pra ser honesto, 14.8Mpps
> na Chelsio só com portas individuais - sem rotear entre si e sem bridge).
>
> 2) ServerU + Chelsio/Intel + Roteamento Netmap com netmap-rt: grandes
> taxas, grandes numeros, ainda prematuro/preliminar. É uma solução em estado
> -BETA sendo ativamente trabalhada.
>
> 3) ServeU + Mellanox: não tem benefício nenhum, prefira Chelsio. Maior
> compromisso com Netmap, com drivers nos SOs, e offload comprovadamente
> funcional em Linux/BSD.
>
> 4) ServerU + FreeBSD/Linux kernel-path (leia-se Linux/VyOS/BSDRT/FreeBSD/ProApps,
> etc): estável, bom pra até 5.6Gbit/s e 2.7Mpps (requer expansões de 10 pra
> conseguir esses numeros, claro)
>
> 5) ServerU + Intel DPDK + Brocade vRouter 5600: sonho de consumo
> (literalmente), espero um dia chegar nesse nível com netmap-rt, taxas até
> 6.8Mpps/23Gbit/s, estável, poucos bugs (que eu saiba tem umas coisas
> irritantes no firewall do vRouter, mas pra roteamento sem notícia de
> problemas), custo de software expressivo (~6k Obamas licença pra 3
> dataplanes/vCPUs).
>
> 6) ServerU + Chelsio DPDK +  Brocade vRouter 5600: ainda não suportado
> oficialmente. Se voce instalar na unha o driver de Linux no vRouter, o
> dataplane reconhece, e usa, a performance chega a 8Mpps, mas não é
> oficialmente suportado pela Brocade então o risco é seu. Não temos clientes
> que toparam o risco, nenhum foi pra produção com Chelsio só o que temos são
> números de laboratório. É promissor, tomara que a Brocade faça isso.
>
> Abraços.
>
> --
> 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
>