[GTER] Servidor PPPoE - Accel-PPP

André Carlim andre at stubnet.info
Tue Nov 28 22:14:43 -02 2017


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...




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

-- 
Enviado de meu dispositivo Android com Open Mailmail. Desculpe-me pela brevidade.



More information about the gter mailing list