[GTER] Servidor PPPoE - Accel-PPP

[Caiu]

Boa dia HugLeo,

por favor, conte-me mais sobre redirecionar as rotas de nat.

Seria uma dádiva pra mim aqui.


Att,

Darlan Ullmann


Em 29/11/2017 10:05, HugLeo escreveu:
> Dica:
> rps ativado
> firewall stateless (se precisar de nat basta redirecionar as rotas de nat
> pra um mikrotik e fazer por lá,  funciona perfeito)
>
> Aguenta muito mais que 2000 sessões.
> Roda perfeitamente umas 5000 sessões e 4 GB de tráfego e pede por mais.
>
> O próprio mikrotik rodando em x86 chega perto disso.
>
> 2017-11-28 22:14 GMT-02:00 André Carlim <andre at stubnet.info>:
>
>> 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.
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter