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

[Fernando Frediani]

Olá Ricardo,
Sou mais simpático a esse design também embora não ignoro os méritos do 
PPPoE.
Acho que foi falado brevemente nas mensagens anteriores, mas você 
poderia descrever com um pouco mais de detalhes como você faz para:

- Evitar que um cliente configure um (ou mais) IP(s) estático(s) no seu 
PC/ROTEADOR ao invés de utilizar o DHCP.
- Evitar que os clientes utilizem a rede PON como uma 'rede local'. A 
OLT tem algo equivalente a um "AP Isolation" ? E aonde você faz o 
controle de banda, na OLT ou em cima dela ?

Obrigado
Fernando

On 30/03/2015 20:13, Ricardo Oliveira wrote:
> 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
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter