[GTER] Servidor PPPoE - Accel-PPP

Douglas Fischer fischerdouglas at gmail.com
Wed Nov 29 10:58:49 -02 2017


Vou complicar ainda mais uma thread que já está complicada...

E se o ambiente do B-RAS for virtual?
Como fica isso tudo?

Em 28 de novembro de 2017 18:20, 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
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação



More information about the gter mailing list