[GTER] Servidor PPPoE - Accel-PPP

[Marcelo Gondim]

Em 28/11/2017 22:14, André Carlim escreveu:
> Meu irmão, você não faz a menor ideia do que está falando. Eu tenho servidores PPPoE com 2000 sessões com controle de banda, cgnat, IPv6, controle de banda e ospf, com processador core i5 com trânsito de 1.2gbit em horário de pico que não usa mais que 15% dos núcleos...
>
> Eu acho que você não tá por dentro do hardware x86...
Eu ainda acho que ele deve ter sido muito infeliz nas escolhas de 
hardware dele, assim como eu fui em 2008 e acredito que ele tenha levado 
isso como padrão eterno.

>
>
>
>
> Em 28 de novembro de 2017 18:20:36 BRST, Rubens Marins Schner <rubens.marins at gmail.com> escreveu:
>> 2017-11-28 14:53 GMT-03:00 André Carlim <andre at stubnet.info>:
>>
>>> Antes de mais nada, só quero saber se o amigo aqui já teve
>> experiência com
>>> linux e pppoe em larga escala?
>>>
>>>
>>> Concordo plenamente, se estiver usando placa de rede "realtreco" ou
>>> aquelas intel pro/1000! Com boas placas de rede isso é eliminado.
>>
>> Claro que já é implicito que para isso você vai usar um placa de rede
>> "boa".
>> O problema não é placa de rede, e sim a velocidade de copia do
>> cabeçalho da
>> placa de rede para a CPU, e a velocidade que a CPU demora para decidir
>> o
>> que fazer com o pacote.
>>
>> Com placas de rede que usam o driver igb ou tg3 é só NÃO usar o
>> irqbalance
>>> e fazer o irq affinity manualmente que vai funcionar perfeitamente!
>>>
>> Vai funcionar perfeitamente até o limite de processamento de 1 Core, o
>> que
>> nesse caso, não é um limite lá muito alto.
>>
>> Bom, aqui não pude entender mesmo o objetivo do comentário, com um
>> pouco de
>>>> tempo qualquer um faz CGNAT (ou seja lá qual for) usando iptables...
>>>>
>> O problema não é saber o comando de Iptables, é a caixa que já esta no
>> gargalo fazendo controle de banda, agora precisar fazer NAT, que também
>> é
>> feito em CPU.
>>
>> E você não consegue fazer o controle de banda em um core e NAT em outro
>> core, depois que setou o CPU affinity já era.
>> Até por que o NAT precisa esperar o controle de banda decidir se vai
>> transmitir o pacote ou não, antes de operar o mascaramento. Esse baile
>> não
>> da para dançar em dois cores separados.
>> Não dá para fazer a divisão de pacotes por cores, os pacotes da mesma
>> conexão precisam sair mais na mesma ordem que chegaram, pacotes fora de
>> ordem vai tornar Voip e Jogos online inviaveis.
>>
>> O problema é Hardware
>>
>>
>> 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
>>>
>>> --
>> 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


--