[GTER] A saga: Razões para migrar de PPPoE para DHCP

[Marcelo Gondim]

Bom dia pessoal,

Outro detalhe. Até agora só vi autenticação usando o mac como login e 
sem senha no DHCP option 82 via radius. Quantidade de gente fazendo 
clonagem e tentando burlar o sistema vai ser muito alta. Não podemos 
esquecer que vivemos no Brasil. O país que é PhD em safadezas. Não 
estamos na Europa, nosso povo não é educado o suficiente e quer sempre 
tirar vantagem de tudo quanto é lado.

Com certeza precisa haver isolamento de cliente. Em hipótese alguma 
qualquer assinante que seja deve chegar em outro assinante pela L2. Tem 
várias coisas que preciso testar antes de uma mudança como essa.
Realmente eu gostaria muito de excluir da minha vida o PPPoE, mas 
enquanto eu não conseguir uma forma com custo x benefício, segurança, 
mantendo toda minha estrutura funcionando com o mínimo desejado, vou 
continuar mantendo o PPPoE.  :)

O assunto é muito interessante e gostaria de ter mais opiniões inclusive 
de quem já está funcionando assim. Se puder informar quais sistemas está 
usando e como foi implementado. Coisas como:

- Autenticação com radius é possível como já vimos mas existe alguma 
forma de autenticação (login + senha + mac), como temos no PPPoE, mas 
sem mexer na ponta do assinante? Acredito que não.
- Dual stack IPv4/IPv6 enviando IPs dinamicamente e como fixos. Está 
funcionando OK?
- Logs de assinantes como IP, data e hora. Muito importante quando 
recebemos intimações da Justiça para identificar o assinante.
- O que impediria um assinante de fixar um IP da rede e usá-lo causando 
problemas como IPs duplicados na rede?

A ideia de arrancar o PPPoE fora é muito boa mas a coisa tem que ser 
viável. No lab é uma coisa mas na rua, com todo tipo de assinante, o 
universo muda e muito.  :)   vamos por em prática! Ideias?

Em 30/12/2016 01:41, Fernando Frediani escreveu:
> No caso do DHCP acredito que o Radius não e mandatório mas útil 
> dependendo do cenário.
> Para saber qual usuário pegou qual IP em determinado momento o DHCP 
> Option 82 resolve indicando de qual porta do switch, ONU ou porta do 
> DSLAM veio a solicitação.
>
> Outros detalhes que devem ser levados em consideração são:
>
> - Forçar o usuário a pegar IP apenas por DHCP proibindo assim que ele 
> configure um IP fixo.
> - Isolar usuários. Toda comunicação entre usuários deve ser feita 
> através do gateway, caso contrario e dependendo da arquitetura do 
> provedor os clientes poderão usar a sua rede metropolitana como 
> transporte sem você saber. Isso previne também que o usuário 
> erroneamente conecte o cabo na porta LAN dele ao invés da WAN e 
> 'injete' outro DHCP de volta para seus outros clientes.
> - Controlar o numero máximo de MAC addresses aprendidos por vez na 
> porta do switch, atrás da ONU ou do modem xDSL para evitar que o 
> usuário ligue o cabo em um switch interno e sim na WAN do roteador dele.
>
> Fernando Frediani
>
> On 29/12/2016 13:18, Rafael Galdino wrote:
>> Ao meu ver a melhoria de migrar para PPPoe para DHCP já foi amplamente
>> discutida no post.
>> mas resalto:
>>
>> * PPPoe
>> - Mais recurso do BRAS
>> - precisa de uma rede bem definida L2 para não ficar caindo o pppoe....
>> - Dependendo do Cenário mais BRAS para prover redudância
>>
>> * DHCP
>> - Mais simples, porém necessita de maior gerência
>> - Ter um Radius que realmente lhe prover a autenticação boa 
>> "principalmente
>> se for dual stack"
>> - Ver qual forma será a redudância na rede de distribuição, STP,RSTP,
>> alguma espécie de LACP etc..
>> - lembrar qual vai ser o CPE usado, se não tem possibilidade de ficar em
>> bridge e vim um DHCP maluco ai na rede, " prever a proteção dessa 
>> situação,
>> acredito que nada que umas vlans ajude.
>>
>> mas acredito que tendo a empresa: Provedor/operadora controle total 
>> da CPE,
>> fica legal a utilização de DHCP
>>
>> Em 29 de dezembro de 2016 00:49, Tiago SR <listas at tiagosr.com> escreveu:
>>
>>> Não vejo diferença no trabalho em centralizar PPPoE e centralizar 
>>> DHCP. Em
>>> ambos casos é preciso apenas garantir comunicação em L2 entre os 
>>> clientes e
>>> o concentrador. Na verdade, centralizar DHCP é até mais fácil, já que o
>>> overhead de um túnel/VLAN/VPLS/etc. será um problema bem menor sem 
>>> ter que
>>> considerar o overhead do PPPoE também.
>>>
>>> E não entendi o motivo para fazer controle e contabilização no CPE 
>>> no caso
>>> de DHCP e no que isso facilita.
>>> Na verdade, vejo que introduz mais complexidade, uma vez que terá que
>>> gerenciar centenas e até milhares de equipamentos para fazer esses
>>> processos, enquanto que deixar isso por conta do roteador do ISP 
>>> resulta em
>>> uma quantidade bem menor. Isso sem falar que duvido haver um sistema
>>> comercial de controle pronto para trabalhar assim e tem também as
>>> limitações e variações de recursos de diferentes CPEs (imagine um 
>>> provedor
>>> com rede mista: wireless, FTTH, FTTC/UTP, xDSL, etc.).
>>>
>>> Minha opinião resumida sobre uso de DHCP: não vejo motivos 
>>> plausíveis para
>>> alguém continuar usando PPPoE. Se é rede nova, começa já no DHCP, se 
>>> é rede
>>> existente, trabalhe com as duas formas, com PPPoE para clientes 
>>> atuais e
>>> DHCP para os novos. Se quiser fazer melhor ainda, vá migrando os 
>>> clientes
>>> PPPoE para DHCP.
>>>
>>>
>>>   ---- On Wed, 28 Dec 2016 15:46:36 -0200 Douglas Fischer <
>>> fischerdouglas at gmail.com> wrote ----
>>>   > E minha modesta opinião a questão vai além do PPPoE vs IPoE(DHCP).
>>>   > O âmago da questão é no modelo de rede que se vai adotar.
>>>   >
>>>   > Com PPP, compulsoriamente necessita-se de um ponto de concentração.
>>>   > E é nesse ponto de concentração que o local mais conveniente para
>>>   > aplicar-se todos os controles e contabilizações que se deseje.
>>>   >
>>>   > Com IPoE pode-se também fazer essa centralização, lançando-se 
>>> mão de
>>>   > Tunelamentos/Vlan/VPLS/etc/etc/etc...
>>>   > Mas isso torna-se muito trabalhoso e até oneroso(dependendo 
>>> fabricante),
>>>   > tendo em vista que são feature-sets específicos.
>>>   >
>>>   > O IPoE passa a ficar interessante quando o Dispositivo de
>>> Demarcação(CPE,
>>>   > no caso) passa a ser o elemento que vai fazer todo esse controle e
>>>   > contabilização.
>>>   > Mas isso tem alguns requisitos que podem ser contras dependendo do
>>> ambiente
>>>   > de cada um, como é o caso da gerência, que tem que ser exclusiva do
>>>   > provedor.
>>>   >
>>>   >
>>>   > Em resumo, o "tcham" está em decidir se confiará nos CPEs para 
>>> fazer o
>>>   > controle e contabilização.
>>>   >
>>>   >
>>>   >
>>>   > Em 22 de dezembro de 2016 15:10, Welisson Tomé 
>>> <welissontome at ig.com.br>
>>>   > escreveu:
>>>   >
>>>   > >
>>>   > >
>>>   > > Concordo plenamente quando se fala sobre o overhead do protocolo
>>> pppoe e
>>>   > > que isto no final de tudo poderia significar em mais banda, menos
>>>   > > consumo de cpu de equipamentos e blablabla.
>>>   > >
>>>   > > Mas veja, isto é um ponto de vista e no que tange a custo, hoje
>>> podemos
>>>   > > montar stacks de RB Mikrotik ou plataformas Linux/BSD rodando 
>>> RP-pppoe
>>>   > > ou accel-ppp a um custo muito inferior as plataformas Cisco.
>>>   > >
>>>   > > Dhcp tem seus prós concordo plenamente, só pelo simples fato de
>>>   > > ligou/navegou, mas o que vejo no modelo de pppoe x dhcp para 
>>> ISP é que
>>>   > > no PPPoE temos muito mais gerencia do que no dhcp, e a 
>>> possibilidade
>>> de
>>>   > > integração com o radius e logs acho que isto se sobrepõe ao dhcp,
>>> visto
>>>   > > que ainda não vi um modelo onde podemos ter armazenamento das 
>>> info
>>> mais
>>>   > > consistente do que simplesmente ip+mac(facilmente 
>>> cloned)+caller-id,
>>>   > > diferente do pppoe que podemos ter controles do tipo,
>>>   > > username+password+mac+caller-id+nas-id etc...
>>>   > >
>>>   > > Agora uma coisa que me chamou muito a atenção neste artigo é 
>>> que no
>>>   > > final ele enfatiza que a mudança se dá muito mais na camada 
>>> econômica
>>> do
>>>   > > que técnica, e como dito acima, hoje em dia não é bem assim se
>>> pensarmos
>>>   > > com a cabeça fora das caixinhas prontas.
>>>   > >
>>>   > > Att,
>>>   > >
>>>   > > --
>>>   > > Welisson Tomé
>>>   > > br.linkedin.com/in/welissontome/
>>>   > >
>>>   > > --
>>>   > > gter list https://eng.registro.br/mailman/listinfo/gter
>>>   > >
>>>   >
>>>   >
>>>   >
>>>   > --
>>>   > Douglas Fernando Fischer
>>>   > Engº de Controle e Automação
>>>   > --
>>>   > gter list https://eng.registro.br/mailman/listinfo/gter