[GTER] Servidor PPPoE - Accel-PPP

[HugLeo]

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
>