[GTER] Concentrador PPPOE

Thu May 29 18:34:12 -03 2014

No meu caso, chego dos meus outros pop com fibra/radio, fecho meus VPLS em
uma CCR, e mando pra outra CCR em uma unica interface com vlan. Outra
interface vai pra minha borda (em trunk), onde ficam as vlans de clientes
com link dedicado, que roteio diretamente na borda...

Em 29 de maio de 2014 18:24, Fernando Klabunde <fernandoklabunde at gmail.com>
escreveu:

> Deixa eu ver se entendi.. vocês chegam com os VPLS em uma ou mais ether em
> uma CCR e então ligam vários cabos dessa CCR em outra e fazem VLANs
> distribuidas entre essas portas e jogam os PPPoE server nas VLANs?
>
>
> Em 29 de maio de 2014 17:44, Douglas Fischer <fischerdouglas at gmail.com>
> escreveu:
>
> > Sobre esses Kernel Panic.
> >
> > Uma idéia que me bateu lendo seu e-mail é uma solução que já vi ser
> > implementada no passado em WebServers com muita carga.
> >
> > Subir vários Jails desse mesmo serviço de PPP no mesmo hardware.
> > E deixe o proprio protocolo do PPP se virar em fazer o LoadBalance.
> >
> >
> >
> > Em 26 de maio de 2014 12:43, Flávio Costa <fjcosta at gmail.com> escreveu:
> >
> > >
> > >
> > > Em 09/05/2014 09:28, Luiz Fernando Dazzi escreveu:> Bom dia Srs. !
> > >
> > > >
> > > > O que vocês indicam de software e hardware para autenticar na casa de
> > > > 2000 pppoe simultaneamente em um mesmo equipamento?
> > > >
> > >
> > > Já fiz testes com FreeBSD+MPD, Linux+RP-PPPoE, RouterOS e recentemente
> > > Linux+Accel-PPP.
> > >
> > > FreeBSD+MPD sempre foi nosso porto seguro, mas com certas ressalvas. O
> > > netgraph, subsistema do kernel onde é implementado o PPPoE, sempre se
> > > mostrou meio instável para alto volume de conexões, dando kernel panics
> > > constantes. Batalhamos muito onde trabalho contra isso porque era uma
> > > solução barata, elegante, eficiente e na época em que comecei a mexer
> com
> > > isso, lá em meados de 2007, não havia nenhum concorrente a altura.
> > >
> > > Troquei e-mails com o desenvolvedor, passei os core dumps, abri meus
> > > manuais de programação Intel, meus livros de assembly para x86. Tudo em
> > > vão. Felizmente o desenvolvedor achou um bug no código, consertou e
> > tivemos
> > > êxito. Desde então utilizamos FreeBSD 7.x com MPD como nossa solução
> > > principal para PPPoE.
> > >
> > > O problema está aí, saindo da série 7.x temos os mesmos problemas de
> > 2007:
> > > kernel panics constantes. Cheguei a mandar dumps novamente para o
> > > desenvolvedor mas ele alegou que provavelmente era memória ruim no
> > > servidor. Trocamos a memória, trocamos o hardware, tentamos x86-64,
> > > testamos x86, testamos com SMP, testamos sem SMP, testamos com IPv6,
> > > testamos sem IPv6, sincronizamos com STABLE, sincronizamos com HEAD.
> > Nada.
> > > Séries 8.x, 9.x e agora 10 com panics.
> > >
> > > Pelo menos ainda temos servidores rodando 7.4 sem problemas, alguns com
> > > estabilidade de meses. Fiz inclusive algumas alterações no código do
> MPD
> > > para termos controle de franquia com redução da velocidade em tempo
> real
> > e
> > > checagem de usuários conectados. Mas a versão 7.4 está muito defasada e
> > > isso começou a se mostrar um obstáculo para nós.
> > >
> > > De qualquer forma já vi FreeBSD 7.4 e MPD autenticar 1800 usuários em
> um
> > > servidor nosso (Intel Core2Quad com 4GB de RAM e placas de rede Intel).
> > >
> > > O Linux+RP-PPPoE foi minha primeira experiência com servidores PPPoE,
> lá
> > > em 2006. Eu até consegui fazer funcionar, mas após alguns dias a
> > > performance da máquina descia pelo ralo: latências altíssimas e o
> > controle
> > > de banda falhava entregando velocidades bem abaixo do configurado.
> > Parecia
> > > ser algum memory leak porque o RP-PPPoE, pelo menos naquela época,
> embora
> > > utilizasse o módulo do kernel para PPPoE, dependia muito do pppd, que
> por
> > > sua vez dependia de scripts if-up e if-down para configurar o controle
> de
> > > banda. Era uma gambiarra sem fim.
> > >
> > > Foi por causa de problemas nessa implementação que fui pesquisar outras
> > > soluções até achar o FreeBSD.
> > >
> > > Ano passado tivemos uma breve experiência com um CCR e RouterOS.
> Pareceu
> > > ser uma solução prática e eficiente. Mas tivemos uns problemas de
> reboots
> > > aleatórios, era algo relativo a versão do RouterOS, não me recordo com
> > > precisão. Acho que estávamos utilizando a 7.x e a mais estável era uma
> da
> > > série 6.x. Fiz o downgrade e até que se comportou bem.
> > >
> > > Mas não simpatizo muito com o Mikrotiks e RouterOS, é uma questão
> > pessoal.
> > > Simplesmente não me sinto a vontade. Acho que ainda tenho isso de
> orgulho
> > > de sysadmin: comprar uma caixinha pronta que faz o que você quer, basta
> > > apertar um botão (configurar PPPoE no RouterOS é estupidamente fácil) é
> > > quase uma injúria para mim. Obviamente isso não é uma boa estratégia de
> > > negócios. Mas posso ainda dizer que os CCRs são caros e ele é sua única
> > > chance de chegar perto de 2000 sessões. Com o preço de um CCR você pode
> > > montar acho que dois computadores com processadores AMD cheios de
> > núcleos,
> > > 2 GB de RAM mais um SSD.
> > >
> > > Recentemente (antes de ontem, para ser mais preciso) estávamos
> batalhando
> > > contra um ServerU que compramos. Pedi para colocarem o FreeBSD 10.
> Seria
> > um
> > > novo BRAS (Broadband Remote Access Server) nosso.
> > > Para variar mais kernel panics. Levantei um outro FreeBSD 10 em uma
> > > máquina de confiança nossa. Kernel panic. Foi aí que descobri que a
> > versão
> > > 10 do FreeBSD ainda tinha suas pegadas com o netgraph. Comecei a
> procurar
> > > uma nova solução é achei o Accel-PPP no Linux. Instalei-o em nossa
> > máquina
> > > de confiança e posso dizer que estou muito empolgado com suas
> > > funcionalidades e desempenho. Por favor, sublinhe o _muito empolgado_.
> > Acho
> > > que não ficava assim há muito tempo com um novo software.
> > >
> > > Qual a estabilidade dessa solução somente o tempo dirá.
> > >
> > > Abraços.
> > >
> > >
> > >
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Fernando Klabunde
> (54) 8429-2429
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 

*Jean Carlos Bartzen*

*Delta Telecomunicações LtdaAv. Gov. Moises Lupion, 114 SL1*
F: (45) 3241-1747
*www.deltatele.com.br <http://www.deltatele.com.br>*

*Esta mensagem e qualquer arquivo transmitido anexo, pode
conter informação confidencial e/ou legalmente privilegiada.
Esta informação é direcionada exclusivamente ao destinatário.
Se você não for o destinatário ou a pessoa autorizada a receber esta
mensagem, não podera utilizar, revelar, copiar, distribuir, ou tomar
qualquer ação baseada no conteúdo dessa informação, por ser estritamente
proibido. Se você recebeu esta mensagem por engano, por favor, avise
imediatamente o remetente respondendo o e-mail e em seguida apague a
mensagem. *