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

Osvaldo T Crispim Filho osvaldotcf at gmail.com
Tue Mar 31 17:17:39 -03 2015 

O mpd não faz IPoE, que a tônica da questão:

Uma alternativa ao PPPoE.

Em 31 de março de 2015 16:37, Raimundo Santos <raitech at gmail.com> escreveu:

> curiosidade off-topic: muito do que o accel-ppp se propõe o mpd pra freebsd
> faz :)
>
> 2015-03-31 9:03 GMT-03:00 Osvaldo T Crispim Filho <osvaldotcf at gmail.com>:
>
> > 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 -
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
             - Osvaldo T Crispim Filho -

More information about the gter mailing list