[GTER] Router para BGP

Mon Jun 5 21:39:02 -03 2017

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