[GTER] Router para BGP

T Dutra tarcio_dutra at hotmail.com
Tue Jun 6 21:26:47 -03 2017 

Boa noite, amigos.

Uesley,
Entendi, conforme comentei, havia pegado essa informação de 5,6G agregado no meu contato com o fornecedor, ai pelo entendimento são 2,7G de tráfego passante e, portanto, 5,6G agregado/somado nas duas interfaces que estão sendo utilizadas. Então, num resumo, ele suporta um tráfego real de 2,7G que pode estar em uma única interface ou somada/agregada nas outras interfaces. Espero que eu esteja errado, pois ele está mais acessível $$$$$


Att,
Dutra
________________________________
De: gter <gter-bounces at eng.registro.br> em nome de Uesley Correa <uesleycorrea at gmail.com>
Enviado: terça-feira, 6 de junho de 2017 07:11:22
Para: Grupo de Trabalho de Engenharia e Operacao de Redes
Assunto: Re: [GTER] Router para BGP

Tácio,

O serveru via datasheet é 5.6 agregado no padrão. Agora em porta de 10g eu
ainda não testei, e também não testei com netmap e dpdk. Onde eu consigo
mais de 5G por interface é no VyOS do meu sócio com placa intel.

Att,

Uesley Corrêa - Analista de Telecomunicações
Instrutor Oficial UBNT UBRSS, UBRSA, UBWS & UBWA

Em 5 de junho de 2017 21:39, T Dutra <tarcio_dutra at hotmail.com> escreveu:

> Uesley,
>
> muito animador seu depoimento sobre o ServerU, se ele suportar os 5,6Gbps
> de download em uma única interface 10Gbps, pra mim vai ser ótimo.
>
>
>
> Att,
>
> Dutra
>
> ________________________________
> De: gter <gter-bounces at eng.registro.br> em nome de Gustavo Santos <
> gustkiller at gmail.com>
> Enviado: sábado, 3 de junho de 2017 15:02:25
> Para: Grupo de Trabalho de Engenharia e Operacao de Redes
> Assunto: Re: [GTER] Router para BGP
>
> Sobre este case que vai e volta do MX5 ou MX104 caindo e o SERV-U
> segurando, é como um colega comentou, equipamento mal configurado, no caso
> o MX..
> Lembrem-se que o MX5 / 104 utilizam control plane com CPU bem parecida com
> a utilizada na RB1100AHx2.
>
> Inclusive a alguns anos atrás, quando começou a popularizar o MX5 no
> Brasil, muita gente tinha problema de cair todas sessões BGP do "nada". O
> problema era default arp policer , que normalmente quem estava conectado ao
> PTT-SP, recebia uma quantidade maior do que o permitido na politica default
> que é compartilhada com todas as interfaces da caixa.
>
> Na época enviei compartilhei aqui no GTER, como aplicar politica por
> interface , e resolver o "problema" do equipamento.
>
> Hoje acredito que utilizando a  routing engine RE-S-X6-64G que senão me
> engano é um Intel Xeon 6 Core com 64GB de ram, que vem nos novos MX240 pra
> cima, seja bem difícil a caixa cair tão fácil, mesmo sem um filtro básico.
>
>
> Em 3 de junho de 2017 08:02, Fred Pedrisa <pedrisa at hyperfilter.com>
> escreveu:
>
> > Luigi,
> >
> > Confiar ou não confiar é contigo, mas vou reafirmar que isso é algo
> > empírico, não adianta falar se não fazer. Como disse, eu fiz os testes em
> > ambiente ligeiramente superior, utlizando um E5-2699v3 dual, e os números
> > não foram esses não, infelizmente, alias conversando com o Luigi nem ele
> > soube responder o "porque" da disparidade, mas no fim, é apenas
> relacionado
> > com o ipfw mesmo, o netmap em si, sempre foi rápido e entregou o que
> > prometeu. Agora as implementações "combinadas" são outra discussão, rs...
> >
> > Por isso nem sempre os "readmes" estão certos, ok, eles vão deixar as
> > pessoas "curiosas" mas pode observar que no caso do ipfw-fwd (netmap),
> > nenhum "paper" foi lançado (até porquê a metodologia de testes foi muito
> > mais simples), rs...
> >
> >
> > On 03/06/2017 00:17, Luiz Otavio O Souza wrote:
> >
> >> Ok Fred, obrigado pelas explicações, mas eu conheço bem os detalhes da
> >> implementação do netmap (e talvez do ipfw..).
> >>
> >> Errr, algo me diz que eu ainda confio mais nos números do Luigi:
> >>
> >> "On my i7-3400 I get about 6.5 Mpps with a single rule, and about 2.2
> Mpps
> >> when going through a dummynet pipe. This is for a single process
> handling
> >> the traffic."
> >>
> >> Mas sim, os 4Mpps com netmap-ipfw do Patrick e os meus 1.4Mpps (por
> >> CPU, C2000, 2 copias por pacote) com o netmap-fwd são apenas teoria ;)
> >>
> >> A comunidade em torno do DPDK é muito maior (Linux) e bem mais
> >> desenvolvida (powered by: Intel).
> >>
> >> -l
> >>
> >>
> >>
> >> 2017-06-02 8:58 GMT-03:00 Fred Pedrisa:
> >>
> >>> Olá,
> >>>
> >>> Apenas com as versões 8, 9, 10 e 11. :) (Netmap sempre a master do
> >>> github).
> >>>
> >>> Além do mais, o netmap em si é muito rápido e entrega sim, velocidades
> >>> linerate, desde que você utilize o "zerocopy" que move pacotes entre a
> >>> mesma
> >>> interface, caso você utilize mmap/dma daí a coisa muda de figura, mas
> >>> mesmo
> >>> assim ainda é bem rápido. Porém se você for introduzir um código tão
> >>> complexo quanto o ipfw o rendimento cai bastante, o certo mesmo seria
> >>> reescrever o ipfw (lockless) daí sim a performance seria melhor, mas
> não
> >>> seria linerate de qualquer forma, pois quanto mais regras você
> adicionar,
> >>> mais lento vai ficar uma vez que "cada pacote" precisará correr entre
> >>> todas
> >>> as regras tentando encontrar um "match".
> >>>
> >>> Enfim, não é apenas confiar no que está disponibilizado, e sim saber
> >>> realmente do que se trata, e quais objetivos a sua aplicação se propõe
> ao
> >>> usar isso, para que você não tenha surpresas depois. E existem outras
> >>> alternativas também, tais como o DPDK da Intel. Mas se quer algo bem
> >>> simples
> >>> e fácil de lidar, com certeza é o netmap. :)
> >>>
> >>>
> >>> On 02/06/2017 00:58, Luiz Otavio O Souza wrote:
> >>>
> >>>> Tudo teoria Fred, tudo teoria ;)
> >>>>
> >>>> E você testou com FreeBSD ? Que versão do FreeBSD e do netmap ?
> >>>>
> >>>> -l
> >>>>
> >>>> 2017-06-01 12:36 GMT-03:00 Fred Pedrisa <pedrisa at hyperfilter.com>:
> >>>>
> >>>>> Você fez os testes na prática ou está falando baseado em conceito ?
> >>>>> Porque
> >>>>> eu fiz os testes na pratica, e conversei muito com o Luigi Rizzo e o
> >>>>> Vincenzo Maffione... Participei muito no netmap. ;)
> >>>>>
> >>>>>
> >>>>> On 01/06/2017 11:31, Luiz Otavio O Souza wrote:
> >>>>>
> >>>>>> 2017-06-01 8:59 GMT-03:00 Fred Pedrisa:
> >>>>>>
> >>>>>>> Esse soft-netmap ipfw, consegue apenas 1.5 Mpps (com uma regra de
> >>>>>>> firewall),
> >>>>>>> se você adicionar mais regras a performance cai mais ainda.
> >>>>>>>
> >>>>>>> O problema não é o netmap, e sim o ipfw que não é prepaprado para
> >>>>>>> trabalhar
> >>>>>>> neste cenário.
> >>>>>>>
> >>>>>> Você provavelmente esta se baseando na versão in-kernel do IPFW.
> Essa
> >>>>>> versão é levemente diferente, com muito menos locks (a aplicação
> final
> >>>>>> é single thread) mas a diferença é significativa (extraído do README
> >>>>>> do projeto no github):
> >>>>>>
> >>>>>> This directory contains a version of ipfw and dummynet that can
> >>>>>> run in userland, using NETMAP as the backend for packet I/O.
> >>>>>> This permits a throughput about 10 times higher than the
> >>>>>> corresponding in-kernel version. I have measured about 6.5 Mpps
> >>>>>> for plain filtering, and 2.2 Mpps going through a pipe.
> >>>>>> Some optimizations are possible when running on netmap pipes,
> >>>>>> or other netmap ports that support zero copy.
> >>>>>>
> >>>>>> Basta ver os 4Mpps filtrados nesse case do Patrick.
> >>>>>>
> >>>>>> 1.4Mpps é o que faz o netmap-fwd, por CPU, rodando nos C2000 da
> vida.
> >>>>>> E da bem mais trabalho pra rotear do que pra filtrar pacotes em uma
> >>>>>> bridge.
> >>>>>>
> >>>>>> Att.,
> >>>>>> -l
> >>>>>> --
> >>>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Fred Pedrisa - CEO/CTO
> >>>>> HyperFilter DDoS Protection Solutions
> >>>>> A FNXTEC, Company.
> >>>>> https://www.hyperfilter.com
> >>>>>
> >>>>> --
> >>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>
> >>>> --
> >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>
> >>>
> >>> --
> >>> Fred Pedrisa - CEO/CTO
> >>> HyperFilter DDoS Protection Solutions
> >>> A FNXTEC, Company.
> >>> https://www.hyperfilter.com
> >>>
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> > --
> > Fred Pedrisa - CEO/CTO
> > HyperFilter DDoS Protection Solutions
> > A FNXTEC, Company.
> > https://www.hyperfilter.com
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>
--
gter list    https://eng.registro.br/mailman/listinfo/gter

More information about the gter mailing list