[GTER] Servidor PPPoE - Accel-PPP

[Andre Almeida]

E ainda dispensa logs.... se bem feito.

Andre

Em 29 de novembro de 2017 16:47, Levi Lins <levilins at acessotelecom.digital>
escreveu:

> Uma alternativa é usar o netmap que tira essa decisão do kernel e joga para
> aplicação. Agiliza muito.
>
>
>
> Em 28 de novembro de 2017 16:47, Rubens Marins Schner <
> rubens at brisanet.com.br> escreveu:
>
> > Rubens Marins
> > Administrador de Sistemas
> > rubens.marins at gmail dot com
> >
> > 2017-11-28 14:33 GMT-03:00 Marcelo Gondim <gondim at bsdinfo.com.br>:
> >
> > > Olá Rubens,
> > >
> > > Mas você pode fazer um cpu affinity no Linux. Não tão trivial quanto no
> > > FreeBSD mas dá pra fazer sim e assim você inibe a migração de contexto
> > > entre os cores.
> > > Outra coisa interessante é tornar o sistema stateless usando NOTRACK do
> > > Netfilter.
> > >
> >
> > Sim você faz o cpu affinity, mas quando a CPU não aguentar mais, e esse
> dia
> > chega cedo quando você fala de ISP, você não tem CPU mais potente no
> > mercado, por que as CPUs mais potentes, tem mais cores o que não ajuda no
> > problema da escala por caixa.
> > Supondo que você tem duas placas de rede, uma de entrada e outra de
> saida,
> > vai ficar limitado a dois cores. Colocar mais placa de rede não resolve,
> > não é barato uma placa-mãe com dois slot PCIe 16x ( supondo que você usa
> > uma placa com duas portas fisicas)
> >
> >
> > > Uma coisa legal é usar interfaces de rede boas como as Chelsio
> T520-SO-CR
> > > (10GbE óptica) ou se for giga as Intel I350-T2 também são boas.
> > > O hardware vai influenciar com certeza.
> > >
> >
> > Uma placa de rede ruim vai colocar tudo a perder, mas uma boa não vai
> > resolver o problema.
> > Cada vez que chega um pacote, e existe controle de banda, a placa de rede
> > vai fazer um IRQ ( dae o processo ksoftirqd),o cabeçalho do pacote é
> > copiado para a placa-mãe, e dela para a CPU, para decidir o que fazer com
> > ele, todo esse processo demora tempo, e quanto você precisa fazer milhões
> > de vezes por segundo, você descobre que a placa-mãe não é tão rapida
> assim.
> > O PCIe 16x ou 8x faz muito mais diferença nesse caso.
> >
> > Essa placa  Chelsio T520-SO-CR e outras, não fazem milagres nesse caso, o
> > tão famoso off-loads TCP/IP, é util somente em Windows, devido a
> limitações
> > especificas da plataforma, em Linux a coisa já é super otimizada, além do
> > fato que o controle de banda é feito na CPU, o suposto offload vai pro
> > vinagre, por que o cabeçalho precisar ser copiado para a CPU decidir o
> que
> > fazer com o pacote, mesmo caso do NAT/Firewall.
> >
> > Se desabilitar NOTRACK do Netfilter, pode dar adeus ao NAT.
> >
> >
> > > André estou esperando chegar umas interfaces aqui pra gente fazer um
> lab
> > > também.
> > >
> > >
> > > Em 27/11/2017 23:48, Rubens Marins Schner escreveu:
> > >
> > >> O gargalo é o controle de banda, e não o PPPOE em si, isso tambem quer
> > >> dizer que quanto mais banda passar na caixa menos sessões vai fazer.
> > >> Um linux fazendo isso, vai ter o ksoftirqd consumindo a maior parte da
> > >> CPU,
> > >> e quando o consumo da CPU passar de 50%, a transmissão de pacotes vai
> > >> deixar de ser "real-time", causando delay consideravel e perda de
> > pacotes.
> > >>
> > >> Não adianta colocar muitos cores, por que cada placa de rede deve
> estar
> > >> idealmente em 1 core ( sem HT) para máxima performance na transmissão
> de
> > >> pacotes, se você deixar a placa de rede/ksoftirdq migrando de cores,
> vai
> > >> perder performance. O problema não é o Linux, nem o Accel-PPP, mas o
> > >> hardware que não é otimizado para essa tarefa nessa escala industrial
> (
> > >> ISP
> > >> ), um PC é um Multi-Purpose hardware.
> > >>
> > >> Com isso, é normal pensar, mas e se eu colocar uma placa de rede com
> > >> acelerador de hardware para controle de banda/forward de pacotes?
> > >> É exatamente isso que a Juniper faz ( com FreeBSD) e Cisco na
> plataforma
> > >> NX-OS ( com Linux )
> > >>
> > >> Além do mais, uma solução Cisco vai fazer GCNAT/NAT64 além do
> > >> PPPOE/Controle de Banda na mesma caixa.
> > >>
> > >>
> > >> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>