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

Fri Dec 30 01:41:00 -02 2016

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
>>
>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>
>