[GTER] Controle de acesso (era: Duvida elementar sobre PPPoE)

[Ricardo Oliveira]

Boa noite,

Eu sou um dos adeptos do DHCP no lugar do PPPoE (Culpa do Rubens), quando
iniciamos o projeto PON um dos pontos que foi avaliado era qual tecnologia
iriamos usar e adotamos o DHCP, numa rede GPON é mais tranquilo de filtrar
e delimitar a rede (Com um pouco mais de trabalho também é possível fazer
no rádio). Atualmente usamos um Cisco 7604 para fazer o processo de
autenticação e concessão de IPs, tudo autenticado e contabilizado via
Radius.
Em termos de suporte economizamos muito tempo em clientes no modo BRIDGE
onde na maioria dos casos, apenas plugam o PC/ROTEADOR e já saem usando. A
autenticação pode ser baseada numa combinação de circuit-id,
remote-circuit-id, MAC e recursos de autenticação da propria OLT. Quem
quiser fazer uma LAB com autenticação DHCP, por aqui testamos com sucesso o
módulo IPoE  do Accel-PPP (Similar ao Cisco ISG IP Unnumbered).

Obs. Está em Russo.
http://accel-ppp.org/wiki/doku.php?id=ru:ipoe

Obrigado.
Ricardo Freitas.

Em 30 de março de 2015 12:03, Rubens Kuhl <rubensk at gmail.com> escreveu:

> 2015-03-30 10:18 GMT-03:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:
>
> > PPPoE tem muito em comum com outra tecnologia 'controversa', que é o NAT:
> >
> > - Ambos surgiram para resolver problemas práticos de gente que tinha um
> > problema para resolver, e (na época) não podia se dar ao luxo de esperar
> > pela solução perfeita;
> >
>
> O que é um bom motivo para redes que fizeram escolhas à época, não quando
> hoje é possível fazer com mais ou menos estado na rede... o caso que citei
> nesta thread é bem prático: substituição de x86s por RB-450G num papel de
> BRAS numa rede com uns 15 mil assinantes. Não teria sido possível com
> PPPoE, que exigiria um empilhamento e granularidade bem chatos de
> implementar... com DHCP, foi só alegria.
>
>
> > - Ambos são soluções 100% implementáveis em software, com todos prós e
> > contras que isso traz.
> >
>
> Há hardware fazendo NAT e PPPoE, dentro de limitações... e eu não duvido
> que seja possível criar soluções 100% hardware, mesmo que isso custe
> desenvolver ASICs específicos e armazenar estado em memória associativa. Se
> isso realmente resolver o problema de um número significativo de clientes
> com potencial de compra, vai surgir.
>
>
>
> > - Por fim, acusar soluções em software de serem ineficientes
> economicamente
> > é um argumento fadado ao fracasso.
>
>
> Pelo contrário, é mais fácil o software engolir o que normalmente se
> faz/fazia em hardware...
>
>
> > Que o diga o protocolo IP, que durante
> > décadas viveu sob a constante ameaça de "não escalar" porque dependia de
> > software. O bom ia ser o ATM, depois o MPLS, que poderiam teoricamente
> ser
> > otimizados mais facilmente em hardware, e por aí vai. Vejam que o MPLS
> > pegou, mas vive apoiado na infra IP...
> >
>
> A lembrança do ATM é interessante, pois ele é um primo do PPPoE em tunelar
> algo que nativamente não é daquele jeito em outro jeito, e em algum momento
> alguém coçou a cabeça e perguntou "Por quê ?", e acabou se livrando dele.
>
> O MPLS pegou, na minha opinião, pois permite níveis selecionados de
> armazenamento de estado a gosto do freguês... quem quer apenas virtualizar
> o plano IP, consegue isso com basicamente o mesmo nível de estado do IGP;
> quem quer colocar RSVP controlando cada coisinha, pode também, outros usos
> como AToM idem. Ser apoiado no IP ajudou por aproveitar sinalizações já
> existentes, mas tem muito backbone grande MPLS usando IS-IS que não é IP...
>
>
> Rubens
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>