[GTER] Servidor PPPoE - Accel-PPP

[César Kallas]

Eu tb n gosto de soluções que usam servidores, muito menos daquelas que
usam processador de desktop como servidores.

1. Gasto energia
2. Espaço rack
3. Soluções especiais não encaixam em estrutura de suporte e substituições
eficientes
4. Dor de cabeça para manter atualizado
5. Amigo meu montou e só ele sabe mexer
6. Quando os problemas aparecem, quem montou some ou joga culpa em outro

Enfim, poderia citar mais pontos do meu ponto de vista, já que aqui serve
pra isso.

Também prefiro parede de CCR, se esta for a outra opção.

Meus 2 cruzeiro.

Att







Em ter, 28 de nov de 2017 às 22:14, André Carlim <andre at stubnet.info>
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...
>
>
>
>
> 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
>
-- 
.............................................................
*César Kallas*
Avançar - Engenharia de Computação
Telefone: (35) 3529 0400
Web Site: www.avançar.eng.br <http://www.avancar.eng.br>