[GTER] Fwd: RES: RES: Concentrador PPPoE

Wed May 7 11:54:25 -03 2014

Aqui inclusive os clientes que recebem IP Fixo são entregues pelo radius e
anunciados via OSPF para os outros concentradores e para a Borda.

Tenho uma classe grande chegando na borda e ela é anunciada no software
para entregar dinamicamente por exemplo:
10.5.0.0/19.. (10.5.0.0-10.5.31.255)
O radius entrega dinamicamente de: 10.5.0.1-10.5.29.255
E para os que foram setados no sistema sobrou: 10.5.30.0-10.5.31.254
E mesmo assim não foi quebrado nada da classe.

Mas sim... cada cliente que loga ele informa a rota novamente, mas não vi
problemas com isso..
Não aumenta os tempos.. não da perda.. até agora.. 100%.

Em 7 de maio de 2014 10:11, Douglas Fischer <fischerdouglas at gmail.com>escreveu:

> E os clientes com reserva de IPs(o famoso ip fixo)?
>
> Já vi e gostei da abordagem de deixar um range para pool sem reserva de IP.
> E esse range com rota específica.
> E os clientes com reserva de IP(vindo pelo radius) anunciando rota /32.
>
> Isso reduziu estupidamente o anuncio de rotas e o barrulho que o OSPF tava
> fazendo na rede.
>
>
>
> Em 7 de maio de 2014 09:52, Joester Brondani <
> contato at joesterbrondani.com.br
> > escreveu:
>
> > Eu concordo com o uso do ospf porem nao distribuindo conecteds (/32) e
> sim
> > segmentando redes entre os concentradores (pois a cada conexão de
> cliente,
> > uma nova rota /32 é distribuida)...Para fins de redundancia, é só
> anunciar
> > todas as redes em todos os concentradores porem com maior/menor
> > especificidade entre eles.
> >
> >
> > Em 06/05/2014 11:21, Fernando Klabunde escreveu:
> >
> >> Não utilizei ainda com BGP..
> >> Até tenho curiosidade de montar um Laboratório para ver..
> >> O OSPF tem se comportado bem.. informa as rotas certinho sem problema.
> >>
> >>
> >> Em 6 de maio de 2014 11:15, NOC VCNet <noc at vcnet.com.br> escreveu:
> >>
> >>  Fernando,
> >>>
> >>> Eu utilizo esse cenário aqui, porém usando BGP ao invés de OSPF.
> >>> Existe alguma vantagem em usar OSPF ao invés de BGP?
> >>>
> >>> ----- Mensagem original -----
> >>> De: "Fernando Klabunde" <fernandoklabunde at gmail.com>
> >>> Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
> >>> gter at eng.registro.br>
> >>> Enviadas: Terça-feira, 6 de maio de 2014 10:40:24
> >>> Assunto: Re: [GTER] Fwd: RES: RES: Concentrador PPPoE
> >>>
> >>> Fabrício, considerando que você tenha uma borda e depois dela os
> >>> servidores
> >>> PPPoE...
> >>> Estabelece OSPF entre os equipamentos e redistribui as rotas, neste
> caso
> >>> se
> >>> você tiver um /20.. /19 você não perde IPs.. o OSPF vai distribuir as
> >>> rotas
> >>> com /32..
> >>> Tenha um sistema bom de gerencia que distribui por pool os ips e você
> >>> pode
> >>> usar em qualquer concentrador.. qualquer IP dessa classe.
> >>> Cria uma range dentro do sistema que vai ficar fixa para quem
> precisar..
> >>> e
> >>> mesmo assim não vai precisar "quebrar" a classe..
> >>>
> >>> Funciona bem.
> >>>
> >>>
> >>> Em 6 de maio de 2014 10:31, Fabrício F Kammer <fknet at conchalnet.com.br
> >>>
> >>>> escreveu:
> >>>> Pessoal, só pra relatar, tenho algumas CCR-1036 rodando concentrador
> >>>> PPPoE, com vlans e NUNCA tive nenhum problema. Além disto tenho OSPF e
> >>>> firewall nelas. Não tenho bridge nenhuma, os servidores PPPoE ficam
> nas
> >>>> interfaces físicas e/ou vlans.
> >>>>
> >>>> Rubens, nesta proposta de usar vários concentradores PPPoE como
> ficaria
> >>>> a
> >>>> questão de distribuição de IPs (especialmente IPv4, pois temos muitos
> >>>> eqptos que não permitem uso de IPv6 ainda) tendo N servidores Mikrotik
> >>>> rodando??? Teria que delagar redes para cada servidor e correria o
> risco
> >>>>
> >>> de
> >>>
> >>>> algm ficar sem IP, ou estou enganado?
> >>>>
> >>>> []s
> >>>>
> >>>> Fabrício F Kammer
> >>>> skype: ffkammer
> >>>> 19 3866-1100
> >>>>
> >>>>
> >>>>
> >>>> Início da mensagem encaminhada:
> >>>>
> >>>>  De: Bruno Cabral <bruno at openline.com.br>
> >>>>> Assunto: Re: [GTER] RES: RES: Concentrador PPPoE
> >>>>> Data: 5 de maio de 2014 19:56:57 BRT
> >>>>> Para: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >>>>>
> >>>> gter at eng.registro.br>
> >>>>
> >>>>> Responder A: Grupo de Trabalho de Engenharia e Operacao de Redes <
> >>>>>
> >>>> gter at eng.registro.br>
> >>>>
> >>>>> Ele estava comparando com consumo de energia de um R450. Routermaxx e
> >>>>>
> >>>> Powerrouter sao x86 com consumo bem mais baixo
> >>>>
> >>>>> Por outro lado *eu* nao acho honesto comprar um equipamento de 20Gbps
> >>>>>
> >>>> por R$35 mil para um provedor de 1-2Gbps, sabendo que o equipamento de
> >>>> 20Gbps na verdade tem 80Gbps com limitacao por software (a famigerada
> >>>> "licença") e que o equipamento de 2 a 5 mil reais faz um bom trabalho
> >>>>
> >>> para
> >>>
> >>>> os 1-2Gbps propostos.
> >>>>
> >>>>> É como comprar o ruindows starter e só poder abrir 3 programas ao
> mesmo
> >>>>>
> >>>> tempo. Melhor usar o linux
> >>>>
> >>>>> Por que a linha J (x86 com 4GE) foi tirada do mercado se atendia bem?
> >>>>>
> >>>> Abriu espaço para o crescimento do Mikrotik... E a despeito das
> >>>> reclamações, tem muita gente usando mikrotik com sucesso, em redes até
> >>>> grandes. Não são usuários point e clique, são pessoas que se
> dispuseram
> >>>> a
> >>>> aprender a plataforma e a contornar as limitações dela, em nome da
> >>>>
> >>> economia
> >>>
> >>>> gerada com a escolha
> >>>>
> >>>>> E ninguem ainda falou dos ciscos 7200 VXR com processador 2GE para
> >>>>>
> >>>> essas
> >>>
> >>>> capacidades mais baixas que o MX5
> >>>>
> >>>>> !3runo Cabral
> >>>>>
> >>>>> --
> >>>>> Cursos e Consultoria BGP
> >>>>>
> >>>>>  Comparar esses Routermaxx e Powerrouter com ASR1001 é um tanto
> >>>>>>
> >>>>> desparelho,
> >>>>
> >>>>> não acha?
> >>>>>>
> >>>>>>
> >>>>>> Em 5 de maio de 2014 14:04, Bruno Cabral escreveu:
> >>>>>>
> >>>>>>> Routermaxx 84W
> >>>>>>> http://www.balticnetworks.com/docs/RouterMaxx_10port_fiber.pdf
> >>>>>>> Powerrouter 732 80W
> >>>>>>>
> >>>>>> http://www.wlan1.com/product_p/powerrouter-732.htm
> >>>
> >>>>
> >>>>>>>  Um ASR1001 consome, na média, 158W (janela de 20 minutos de
> medição
> >>>>>>>>
> >>>>>>> em
> >>>
> >>>>  operação estável em um cenário com 2/4 interfaces up). MX-5 eu não
> >>>>>>>> conheço, mas creio que seja melhor que o ASR (pq a Cisco não é
> >>>>>>>>
> >>>>>>> famosa
> >>>
> >>>> por
> >>>>
> >>>>>  ser lá tão econômica).
> >>>>>>>>
> >>>>>>>> Quando medi (já a 1 ano pelo menos), o DELL R450 à época consumia
> >>>>>>>>
> >>>>>>> ~300W
> >>>>
> >>>>>  na média (não lembro bem as configs, precisaria de novos testes -
> >>>>>>>>
> >>>>>>> tinhas uns
> >>>>
> >>>>>  4GB de RAM, e uns 2 ou 3 discos near line sas, em raid. 2x portas
> >>>>>>>> Ethernet onboard usadas, mas não era roteador e era a geração
> >>>>>>>>
> >>>>>>> passada
> >>>
> >>>>  da Intel -
> >>>>>>>> realmente *precisa de uma medição decente para esses cálculos*).
> >>>>>>>>
> >>>>>>>> Como somos técnicos precavidos, sempre especificamos 2 né? Então
> >>>>>>>> ASRs=316W, 227kWh/mes  /  DELLs=600W, 432kwh/mes
> >>>>>>>> 227kWh = ~R$ 98
> >>>>>>>> 432kWh = ~R$ 187
> >>>>>>>> ( já com tarifa e imposto, segundo:
> >>>>>>>>
> >>>>>>>>  http://www.ceee.com.br/pportal/ceee/Component/
> >>> Controller.aspx?CC=1221)
> >>>
> >>>>  Em 3 anos, a economia de ~R$3.200,00 entre as soluções é
> >>>>>>>>
> >>>>>>> considerável
> >>>
> >>>>  pra diminuir um pouco a conta do roteador. E com aumentos de energia
> >>>>>>>> elétrica previstos ad eternum, talvez piore...
> >>>>>>>>
> >>>>>>>> Só como referência (porque está em outra categoria de
> equipamento) a
> >>>>>>>> CloudCore CCR1016 diz que o consumo máximo é 38W. Então o médio
> deve
> >>>>>>>> ficar na casa de 30W para baixo. *Se* ela fizesse o mesmo serviço
> do
> >>>>>>>>
> >>>>>>> DELL
> >>>>
> >>>>>  acima, aí estaríamos falando de uma diferença de ~R$6.156 em 3 anos,
> >>>>>>>> o que já seria bem considerável pelo preço dos equipamentos em
> >>>>>>>>
> >>>>>>> questão.
> >>>>
> >>>>> --
> >>>>>> Douglas Fernando Fischer
> >>>>>> Engº de Controle e Automação
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>>
> >>>> --
> >>>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>>
> >>>>
> >>>
> >>> --
> >>> Fernando Klabunde
> >>> (54) 8429-2429
> >>>
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>>
> >>>
> >>
> >>
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
> > --
> > 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