[GTER] Concentrador PPP-OE

Fernando Frediani fhfrediani at gmail.com
Thu Jun 9 19:44:20 -03 2016


Depende. Não vejo nessariamente sempre assim Emerson.

Talvez isso seja válido para uma borda, uma necessidade maior de portas,
mas não para BRAS.

De que adianta colocar lá um negócio de 20 mil dólares (um só) parrudão que
se parar para tudo se é possivel ter vários menores que no geral funcionam
bem e  de forma redundante por menos de 1/3 do valor ?
Além do que adicionar redundância + escalabilidade para um cluster de BRAS
é tão simples quanto deixar um ping rodando.

Usar algo maior (no mínimo em par) é valido, mas esse maior tem que ser bem
grande pra vale a pena.

Abraços
Fernando
On 9 Jun 2016 17:08, "Emerson Adriano Moraes Catarina" <
emerson.catarina at cianet.ind.br> wrote:

> Quando a estrutura cresce demais, não seria a hora de pensar em migrar de
> MK para uma solução como um BRAS (MX da Juniper, por exemplo)?
>
> Não tenho nada contra MK, pelo contrário, acho q relação custoxbenefício é
> imbatível, mas chega uma hora em que é necessário subir de nível.
>
> *Att,*
>
> *Emerson*
>
>
>
>
>
> Em 8 de junho de 2016 19:07, Rôney Eduardo <roneyeduardosantos at gmail.com>
> escreveu:
>
> > Ainda tenho algumas CCR1036-8G-2S+ rodando aqui pra autenticar PPPoE.
> > Sem problemas, travamentos nem nada..
> >
> > Rodo:
> >
> >  - Até 2048 autenticações PPPoE;
> >  - Simple-queue para cada túnel PPPoE;
> >  - 4171 regras de CG-NAT (com jumps, para reduzir a qtde de regras
> > necessárias para dar "match");
> >  - iBGP exportando os /32 dos túneis;
> >  - v6.32.1 e 6.33.5
> >
> > Nesse momento:
> >
> > [admin at PPPoE-nas20] > /ppp active print count-only
> > 2084
> > [admin at PPPoE-nas20] > /queue simple print count-only
> > 2089
> > [admin at PPPoE-nas20] > /ip firewall filter print count-only
> > 16
> > [admin at PPPoE-nas20] > /ip firewall nat print count-only
> > 4171
> > [admin at PPPoE-nas20] > /system resource monitor
> >           cpu-used: 32%
> >   cpu-used-per-cpu:
> >
> >
> 13%,52%,53%,33%,47%,9%,15%,14%,27%,56%,13%,18%,40%,14%,60%,35%,12%,54%,14%,57%,8%,22%,36%,23%,22%,45%,28%,52%,49%,58%,13%,50%,18%,38%,
> >                     58%,20%
> >        free-memory: 3209472KiB
> >
> > --
> > Rôney Eduardo
> >
> > Em 8 de junho de 2016 14:46, João Butzke <lista-gter at tbonet.net.br>
> > escreveu:
> > > Teve algumas melhorias no 6.35 em relação a PPPOE.
> > >
> > > Agora, aqui para ficar legal para os clientes não passa de 1.500
> sessões
> > na
> > > CCR 1036. isso com queue na rb e planos de até 10mbps.
> > >
> > >
> > > Em 08/06/2016 14:28, Leonardo Amaral - Listas escreveu:
> > >>
> > >> Em 7 de junho de 2016 14:23, Neuri Yasawa <neuri.yasawa at uol.com.br>
> > >> escreveu:
> > >>
> > >>> utilizo 6.14, além de algumas travadas ocasionais que me obriga a
> > >>> reiniciar a ccr na mão
> > >>> alguns clientes desconectam sozinhos e não reconectam até que seu
> > >>> equipamento seja
> > >>> desligado e religado. Os clientes estão distribuídos em 3 ccr e isso
> > >>> acontece em todas
> > >>> sem ter horário ou um motivo.
> > >>>
> > >> Isso porque não tem abaixo da 6.27 mais:
> > http://pastebin.com/raw/YRR7Mmsw
> > >>
> > >> TL,DR: Panela velha faz comida boa, software velho, não.
> > >> --
> > >> 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



More information about the gter mailing list