[GTER] RES: PPPoe no Mikrotik

[Shine]

Jonatas,

Se pensarmos que o pool é local, sempre haveria um desperdício, concordo.
Mas fazendo adequadamente o dimensionamento, é possível não se desperdiçar
muito.
Penso que em contingências fora da média diária poderia ser utilizado
alguns pools de rodízio, que seriam comuns em todos os sites e alocados
conforme o esgotamento dos pools de rede pelo atributo do Radius. Esses
pools teriam então rotas sumarizadas nos sites e anunciadas por algum
protocolo de roteamento, acredito que por ser link-state, OSPF seja a
melhor alternativa.
Concordo que o OSPF fica onerado quando carregado com rotas curtas (/32) e
frequentes mudanças de links, mas acho que no caso de trabalhar excedentes
de tráfego ocasionais, funcionaria bem para anunciar blocos menores que
contingenciem esse excedente.

O maior trabalho é trabalhar a base do Radius para que ele saiba quais
pools foram alocados para não enviar um atributo framed-pool que já tenha
sido usado. Isso depende de cada implementação do radius.
Também não sei se MK suporta framed-pools ou pools múltiplos, recomendo
verificar.


Em 6 de dezembro de 2013 09:00, Jonatas M. Victor <jonatasmv at gmail.com>escreveu:

>  Bom dia,
>
>     Mas com os concentradores separados por torre como fica a distribuíção
> de IPs válidos em questão ao disperdício. Pois eu vejo dificuldade na
> designação do tamanho de rede de cada torre para se
> otimizar o IPv4. Como todos tem trabalhado essa questão? Transportar tudo
> via OSPF eu vejo que sobrecarrega a rede com trocas de rotas e anúncios
> repetidos.
>
>
>
> 2013/11/29 Shine <eshine at gmail.com>
>
> > Gosto da idéia do PPPoE server descentralizado, acho que
> operacionalmente é
> > mais fácil para depurar e corrigir eventuais disparidades.
> > Private VLAN é uma opção, mas não sei se é suportado em switches de
> acesso
> > de pequeno porte. De qualquer forma fica limitado a um grupo, 4096
> (número
> > que ninguém chega) é um escopo limitado para um acesso.
> > Usar técnicas de rede metro para transportar uma conexão de acesso eu já
> > acho complicar demais, cai em uma série de planejamentos que acabam
> tirando
> > o foco do serviço final. É só mesmo para ISPs maiores, que tem mais
> > desafios em orquestrar o parque do que fornecer o acesso propriamente.
> >
> >
> >
> > Em 28 de novembro de 2013 15:06, Bruno Cabral <bruno at openline.com.br
> > >escreveu:
> >
> > > Se voce tem pppoe server em cada site, nao precisa levar nada ate a
> > borda.
> > > Apos o pppoe server terá trafego real. A nao ser que queira "esconder a
> > > rede", mas se for por esse caminho lembre de problemas de MTU, PMTU
> > > discovery e de carga (principalmente se usar EoIP)
> > >
> > > Se por outro lado decidir fazer centralizado, ai precisa levar o
> trafego
> > > de cada wireless dos seus APs até a LAN dos servidores PPPoE, tomando
> os
> > > citados cuidados com MTU, PMTU discovery e de carga (ou usar MPLS/VPLS)
> > >
> > > Sem contar eventuais custos de suporte na instalação de clientes PPPoE
> > > (que podem ser minimizados se o rádio no cliente for de sua gerência)
> > >
> > > !3runo Cabral
> > >
> > > --
> > > Cursos e Consultoria BGP
> > > http://f2link.f2b.com.br/impressora3d
> > >
> > >
> > > > Levando em consideração tudo que foi dito, tenho que a melhor opção
> > > > seria pppoe-server em cada site fazendo autenticação em um radius
> > > > centralizado. Até ai tranquilo...
> > > >
> > > > O que me pergunto é, a idéia não é trazer o tunel até a borda? Dessa
> > > > maneira o túnel não seria até o rádio que atende o cliente?
> > >
> > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> .:Abraços:.
>
> <<< Jonatas M. Victor >>>
> jonatas at jmv.eti.br
> jonatasmv at gmail.com
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>