-
PPPOE :: %CPU alto
Patrick,
Eu já anderi xeretando no seu sistema de autenticação/crm e achei que ele era baseado no MyCatAuth, não sabia que era baseado no PPPoE.
Agora tu falou uma coisa que me interessou, como deixo o suporte ao PPPoE nativo no kernel? Podes indicar alguma fonte de pesquisa?
Minha idéia de segmentar meus servidores não será tão util pois tenho dois POPs que terão servidores segmentados e cada um atende a um máximo de 60 clientes (o que não dá 30 simultâneos). Meu problema real está no POP principal que atualmente atende mais de 120 clientes e um único servidor para aguentar umas 80 conexões PPPoE terá que ser extremamente rápido.
Att,
Nataniel Klug
-
pppoe em kernel
No kernel 2.4 vá em:
Network Device Suporte
Coloque todas as opcoes PPP dentro do kernel (marcando com *) e recompile o kernel (não esqueça de marcar outras opcoes para dar suporte a placa de rede, sistema de arquivos, etc..)
# make
# make modules
# make modules_install
# make bzImage
# cp arch/i386/boot/bzImage /boot/NOMEDOKERNEL
Coloque o nome que vc escolheu como NOMEDOKERNEL no /etc/lilo.conf e execute o lilo:
# lilo
reboot!
Isso deve melhorar as coisas um pouco!
-
PPPOE :: %CPU alto
Patrick,
Ahhh bom... Eu uso o kernel 2.6 e já deixei todo acesso PPP nativo no kernel. Como disse ainda não fiz testes de grande porte, apenas em laboratório e se mostrou estável a utilização do CPU (entre 0,4~2% por conexão, sendo que coloquei um máximo de 10 conexões e ficaram online durante umas 3 horas).
Att,
Nataniel Klug
-
PPPOE :: %CPU alto
Olá Patrick, obrigado pela resposta, vou testar no modo kernel para ver a diferença. Eu ja dividi os servidores, mas mesmo assim eles estão no maximo, e não da para dividir mais. Estou tentando desenvolver um cluster para isso, pois deve ser a unica saida.
Sobre o seu sistema Myauth, eu pensei em trocar o sistema pppoe, para o Chillispot, fiz algumas modificações no fonte, para atender algumas necessidades, mas deparei com a possibilidade dos micros que estiverem na rede, enxergarem uns aos outros, que no meu casso isso não poderia acontecer, e a unica forma de limitar isso seria nos AP's, que nos meus não tem esse recurso. No seu sistema isso acontece também, de um micro enxergar o outro?
Eric
-
clientes
Olá Eval,
o problema dos clientes se enxergarem é:
imagine que vc está na rede 192.168.10.0 mascara 255.255.255.0
o broadcast dessa rede é 192.168.10.255, as maquinas windows enviam broadcast udp (portas 137, 138, 139 e 445) e as estaçoes windows que tem como broadcast esse mesmo endereço irão responder e o ambiente de rede será formado.
Logo, a solução para os clientes não se verem é muda-los de rede, ou seja, imagine:
cliente 1: 192.168.10.2 mascara 255.255.255.0 (broadcast 192.168.10.255)
cliente 2: 192.168.11.2 mascara 255.255.255.0 (broadcast 192.168.11.255)
veja que os endereços de broadcast são diferentes pois eles estão em rede diferentes, logo, o cliente 2 não responderá aos broadcast do cliente 1 e vice versa. No seu gateway voce colocará endereços ips adicionais (alias por exemplo: eth0:1, eth0:2, ...) em cada rede, assim voce isolaria de certa forma os clientes (logicamente, nao fisicamente) e evitaria esse problema.
Como em conexoes PPPoE o broadcast e o ARP são desabilitados depois do estabelecimento da conexao, os clientes não se enxergarão (pois nao ha broadcast, o windows nao achará ninguem).
Mesmo assim é possivel os clientes se enxergaram, no exemplo acima, se o cliente 2 digitasse: \\192.168.10.2
ele verá os compartilhamentos do cliente 1, mas nesse caso, os pacotes serão roteados (pois estão em redes diferentes) passando pelo gateway, bloquear o FORWARD das portas 137, 138, 139 e 445 resolveria isso.
Outra solução mais comum é bloquear o relay entre clientes no Access Point, isso não envolve software de aplicação, o AP funcionaria como um swith gerenciavel onde o administrador proibiu o trafego entre portas.