[GTER] Servidor PPPoE - Accel-PPP

Fri Dec 1 17:17:46 -02 2017

Entendi tudo que você disse mas te digo que na prática não é bem assim 
como você acha que é.

Vou te dar um exemplo meu. Ok? Exemplo que está em produção, funcionando 
perfeitamente.
Esse meu exemplo não é uma caixa PPPoE e sim um router. Na cidade matriz 
aqui temos um router de borda Juniper que segura 3 cidades nossas, sendo 
que em cada cidade temos um router/firewall que fecha sessão BGP com o 
Juniper.
Só em uma cidade aqui temos tráfego de mais de 5Gbps, passando em Dell 
R720 rodando FreeBSD e com capacidade pra segurar muito mais tráfego que 
tem hoje e usando placas Intel X520-SR2 que não são boas!

hw.machine: amd64
hw.model: Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz
hw.ncpu: 12
hw.byteorder: 1234
hw.physmem: 17114636288
hw.usermem: 14456246272

Existem outras pessoas aqui na lista que já reportaram a mesma coisa 
usando Linux inclusive com tráfego de 11Gbps, um provedor chamado Bogus.

Outra coisa você pode usar o NOTRACK direcionado sem perder o NAT, basta 
fazer o NOTRACK para os blocos públicos apenas. Se você usar um Juniper 
pra fazer o PPPoE inclusive uma solução é jogar o NAT pra outro 
equipamento ao invés de gastar com um hardware adicional pro Juniper.

O fato é que existem soluções de caixas PPPoE baseadas em Linux e 
FreeBSD que funcionam muito bem.

A proposta que o André tá colocando é justamente crescer com soluções 
que permitam um provedor crescer com opções mais "baratas" que possam 
dar um fôlego pra ele. Quando começamos aqui há 16 anos atrás atendíamos 
em uma sala pequena dentro de uma galeria e hoje temos uma sede própria 
que é um prédio de 3 andares. Só chegamos aqui onde estamos justamente 
por usarmos soluções mais em conta, mas sem perder a qualidade. Hoje 
temos Netflix, GGC, Juniper, FiberHome, Huawei, etc, etc mas ainda temos 
em mente que: onde pudermos usar uma solução mais em conta sem perda de 
qualidade, vamos usar.

Boa iniciativa André! Assim que chegarem minhas interfaces aqui, já vou 
separar um Dell pra começarmos os testes.
Quem for participar show, quem quiser partir pra um Juniper show também.  :)

Em 28/11/2017 17:47, Rubens Marins Schner escreveu:
> Rubens Marins
> Administrador de Sistemas
> rubens.marins at gmail dot com
>
> 2017-11-28 14:33 GMT-03:00 Marcelo Gondim <gondim at bsdinfo.com.br>:
>
>> Olá Rubens,
>>
>> Mas você pode fazer um cpu affinity no Linux. Não tão trivial quanto no
>> FreeBSD mas dá pra fazer sim e assim você inibe a migração de contexto
>> entre os cores.
>> Outra coisa interessante é tornar o sistema stateless usando NOTRACK do
>> Netfilter.
>>
> Sim você faz o cpu affinity, mas quando a CPU não aguentar mais, e esse dia
> chega cedo quando você fala de ISP, você não tem CPU mais potente no
> mercado, por que as CPUs mais potentes, tem mais cores o que não ajuda no
> problema da escala por caixa.
> Supondo que você tem duas placas de rede, uma de entrada e outra de saida,
> vai ficar limitado a dois cores. Colocar mais placa de rede não resolve,
> não é barato uma placa-mãe com dois slot PCIe 16x ( supondo que você usa
> uma placa com duas portas fisicas)
>
>
>> Uma coisa legal é usar interfaces de rede boas como as Chelsio T520-SO-CR
>> (10GbE óptica) ou se for giga as Intel I350-T2 também são boas.
>> O hardware vai influenciar com certeza.
>>
> Uma placa de rede ruim vai colocar tudo a perder, mas uma boa não vai
> resolver o problema.
> Cada vez que chega um pacote, e existe controle de banda, a placa de rede
> vai fazer um IRQ ( dae o processo ksoftirqd),o cabeçalho do pacote é
> copiado para a placa-mãe, e dela para a CPU, para decidir o que fazer com
> ele, todo esse processo demora tempo, e quanto você precisa fazer milhões
> de vezes por segundo, você descobre que a placa-mãe não é tão rapida assim.
> O PCIe 16x ou 8x faz muito mais diferença nesse caso.
>
> Essa placa  Chelsio T520-SO-CR e outras, não fazem milagres nesse caso, o
> tão famoso off-loads TCP/IP, é util somente em Windows, devido a limitações
> especificas da plataforma, em Linux a coisa já é super otimizada, além do
> fato que o controle de banda é feito na CPU, o suposto offload vai pro
> vinagre, por que o cabeçalho precisar ser copiado para a CPU decidir o que
> fazer com o pacote, mesmo caso do NAT/Firewall.
>
> Se desabilitar NOTRACK do Netfilter, pode dar adeus ao NAT.
>
>
>> André estou esperando chegar umas interfaces aqui pra gente fazer um lab
>> também.
>>
>>
>> Em 27/11/2017 23:48, Rubens Marins Schner escreveu:
>>
>>> O gargalo é o controle de banda, e não o PPPOE em si, isso tambem quer
>>> dizer que quanto mais banda passar na caixa menos sessões vai fazer.
>>> Um linux fazendo isso, vai ter o ksoftirqd consumindo a maior parte da
>>> CPU,
>>> e quando o consumo da CPU passar de 50%, a transmissão de pacotes vai
>>> deixar de ser "real-time", causando delay consideravel e perda de pacotes.
>>>
>>> Não adianta colocar muitos cores, por que cada placa de rede deve estar
>>> idealmente em 1 core ( sem HT) para máxima performance na transmissão de
>>> pacotes, se você deixar a placa de rede/ksoftirdq migrando de cores, vai
>>> perder performance. O problema não é o Linux, nem o Accel-PPP, mas o
>>> hardware que não é otimizado para essa tarefa nessa escala industrial (
>>> ISP
>>> ), um PC é um Multi-Purpose hardware.
>>>
>>> Com isso, é normal pensar, mas e se eu colocar uma placa de rede com
>>> acelerador de hardware para controle de banda/forward de pacotes?
>>> É exatamente isso que a Juniper faz ( com FreeBSD) e Cisco na plataforma
>>> NX-OS ( com Linux )
>>>
>>> Além do mais, uma solução Cisco vai fazer GCNAT/NAT64 além do
>>> PPPOE/Controle de Banda na mesma caixa.
>>>
>>>
>>> Rubens Marins
>>> Administrador de Sistemas
>>> rubens.marins at gmail dot com
>>>
>>> 2017-11-27 20:46 GMT-03:00 André Carlim <andre at stubnet.info>:
>>>
>>> Pessoal sei que é meio contra producente o que vou fazer aqui, mas eu
>>>> limitado a recursos para testar o potencial das ultimas mudanças que fiz
>>>> no
>>>> meu esquema de PPPoE. Alguns clientes grandes que estava atendendo
>>>> acabaram
>>>> migrando para Cisco/Juniper e fiquei na mão! Todavia, queria saber se
>>>> alguém topa usar e medir o quanto pode ser útil essa estrutura. Eu penso
>>>> na
>>>> faixa que fica entre as CCRs e um Juniper, nos provedor que tem algo em
>>>> torno de 6000 ~ 9000 clientes. Sei que com essa quantidade já da pra
>>>> pensar
>>>> nessas caixas, mas acho atrativo o baixo custo que o Debian + Accel-PPP
>>>> podem trazer para quem quer atender umas 7000 sessões PPPoE em no máximo
>>>> dois servidores (que nem precisa ser servidor mesmo). Eu já tive por
>>>> algumas vezes experiência de rodar até 2200 sessões PPPoE sobre um Core
>>>> i3
>>>> com uso de processador abaixo de 15% e banda próxima a 1Gbit. Se alguém
>>>> se
>>>> interessar estou a disposição!
>>>>
>>>> --
>>>>
>>>> Atenciosamente,
>>>> André Carlim
>>>> StubNetwork
>>>> --
>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>>