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

[Osvaldo T Crispim Filho]

@Ricardo Oliveira no caso do IPoE, poderia dar mais detalhes? Como funciona
do lado do cliente?

Em 31 de março de 2015 09:03, Osvaldo T Crispim Filho <osvaldotcf at gmail.com>
escreveu:

> Interessante isto.
> mas vai um pouco pro PPPoE.
>
> No caso dos Rádios é bem mais simples, pelo menos nos UBNT, e é envolvido
> apenas o Rádio e o Radius.
>
> Mas no cabo pode ser bem interessante.
>
> *Sobre o ACCEL-PPP*
>
> ACCEL-PPP is a high performance VPN server application for linux.
> Since version 1.8 it is also IPoE server.
> Its goal is aggregation of various popular VPN techniques to a single
> application.
> There are many open source projects which provides VPN services,
> but they are specialized to a specific VPN technique: only PPPoE, only
> PPtP, only L2TP.
> And you have to learn, configure and manage each one separately to build
> multi-service VPN server.
> With ACCEL-PPTP you have all-in-one with single configuration, single
> management, single monitoring.
>  Features:
>
>    - Extensible modular architecture
>    - High-performance multi-threaded I/O core
>    - Supported PPTP
>    - Supported PPPoE (including TR-101 extension)
>    - Supported L2TPv2
>    - Suppopted IPoE (start session by DHCPv4 or unclassified packet)
>    - Radius authentication/accounting
>    - Radius DM/CoA extention
>    - Supported authentication types: PAP, CHAP (md5), Microsoft CHAP
>    Extentions (including version 2), not supported - EAP
>    - Supported MPPE
>    - Compression is not supported
>    - Extensible logging engine with per session logging support,
>    implemented log to file, log to remote host and log to PostgreSQL targets
>    - Extensible user/password database, implemented Radius, pppd
>    compatible chap-secrets sources
>    - Extensible IP pool, implemented Radius, chap-secrets and static pools
>    - Supported pppd compatible ip-up/ip-down scripts
>    - Builtin shaper manager
>    - Command line interface via telnet
>    - SNMP support (master or subagent via AgentX)
>    - IPv6 support including builtin Neighbor Discovery and DHCPv6
>
>  All PPTP, PPPoE, L2TP tunnels are kernel-mode so don't produce system
> overhead like user-space mode tunnels.
>
>
> Em 30 de março de 2015 20:13, Ricardo Oliveira <ricardo.btu at gmail.com>
> escreveu:
>
>> 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
>>
>
>
>
> --
>              - Osvaldo T Crispim Filho -
>



-- 
             - Osvaldo T Crispim Filho -