#  > Telecomunicações >  > Mikrotik >  >  DHCP do jeito certo

## eduardomazolini

Pessoal muitos falam que é legal usar DHCP em provedor, sabendo usar.
Alguém pode dar as dicas?

No wireless o essencial seria ter o wireless com usuários senha individual, não PSK.
Aí faz um bind do Mac e atribui velocidade usando radius, igual no PPPoE.
Ainda da pra atribuir máscara 32 pra isolar, igual em Hotspot.

Séria isso tem mais dicas?
Eu ainda uso PPPoE.

----------


## TsouzaR

É essencial colocar a interface que vai para os clientes em modo ARP reply-only e ativar no servidor DHCP o Add ARP for Leases. Isso vai impedir que alguém coloque IP estático e funcione.

No Wireless dá para usar chave individual, em PON tem que autorizar a ONU, rede puramente em cabo de par trançado usando switches com isolamento de portas (vulgo "VLAN fixa") juntamente com o ARP reply-only fica bem segura (não comunica nem com outros clientes nem com o gateway sem ser autorizado) e rede FTTC (PACPON e afins) dá para controlar a porta elétrica onde conecta o cliente além de fazer as mesmas técnicas da pura em par trançado.

O que sobra é o que sempre questionam: alguém que já foi autorizado a conectar na rede (porque com essas técnicas que listei, se não for autorizado nem tem chance) clonar o MAC de outro. Bom, para isso podemos usar a opção 82 do DHCP como parte da identificação do assinante. O problema é que todo equipamento para ponto de acesso wireless que conheço (MikroTik, Ubiquiti e acho que Cambium também) usa o MAC do cliente como Remote ID na opção 82, ou seja: inútil. O máximo que limita é que a clonagem só possa ser feita entre clientes servidos pelo mesmo ponto de acesso, devido ao Circuit ID identificando a porta física.

Já propus uma solução desse problema para a MikroTik, uma feature request no fórum, mas sem resposta até agora, então acho que vou enviar para o e-mail de suporte deles. Minha proposta resolve o problema independente do fabricante usado no ponto de acesso.

De qualquer forma, os riscos são MUITO pequenos, insuficientes para justificar a preferência por PPPoE, frente aos benefícios que o DHCP proporciona por ser uma forma totalmente fora do plano de encaminhamento de pacotes: mais robustez com menor consumo de hardware, sem adição de overhead, insensível a falhas (se um servidor DHCP para, pode convergir para outro sem derrubar a conexão do cliente, como acontece com o PPPoE)...

Ah, e antes que digam: dá para fazer accounting de tráfego com DHCP normalmente. PPPoE não é vantagem nisso. E quem acha complicado configurar tudo isso é pre-gui-ço-so! Negócio simples desse...

----------


## andrecarlim

Pois é, tô eu aqui querendo defender o PPPoE novamente! Olha a principal pergunta que eu vou fazer é: quem está mantendo redes aí com mais de 500 usuários, segmentada, com IP válido usando DHCP?

É fácil tacar o pau no PPPoE e exaltar o DHCP... Mas...

----------


## andrecarlim

E por favor, nem vamos falar de Mikrotik, vamos esquecer os produtos aqui...

----------


## TsouzaR

> Pois é, tô eu aqui querendo defender o PPPoE novamente! Olha a principal pergunta que eu vou fazer é: quem está mantendo redes aí com mais de 500 usuários, segmentada, com IP válido usando DHCP?
> 
> É fácil tacar o pau no PPPoE e exaltar o DHCP... Mas...


Eu não tenho. Hoje, infelizmente, uso Hotspot com autenticação por MAC, mas qual é o problema que você está imaginando com esse cenário (mais de 500 assinantes, segmentado e IP válido)?

----------


## andrecarlim

Problema nenhum! Só quero saber se alguém mantém para dizer pra gente se existe problema... Porque deve ser ótimo economizar ipv4 com DHCP, uma maravilha! Muito fácil mesmo! Mamão com açúcar! Pensando em segmentar a rede é claro, porque até onde sei loop também afeta rede com DHCP, então dizer que PPPoE é um malefício é algo que tem que ser analisado bem antes falar merda.

Eu tenho um pouquinho de experiência com PPPoE, por exemplo, eu tenho um cliente que tem 22k (isso mesmo VINTE E DUAS MIL CONEXÕES PPPOE de assinantes) e eu atendo tudo com accel-ppp em 6 caixas e não passo por esses problemas aí que falam, isso me leva a crer que tem gente burra tentando usar PPPoE dá forma errada!

Isso é só um cliente, tenho muitos provedores, sem falar das empresas que atendo que tem aquelas VLANs podres dá OI que pra funcionar tive que ter servidor PPPoE exclusivo sobre a rede dá oi e funciona em mais de 15 estados do país, para atender aproximadamente 500 filiais com trabalhos de missão crítica, tendo servidores que estão ligados a mais de 600 dias com o processo do rp-pppoe sem travar, isso mesmo, nem tive coragem de trocar para accel ainda!

E isso que falam que PPPoE não funciona!

----------


## TsouzaR

> Problema nenhum! Só quero saber se alguém mantém para dizer pra gente se existe problema... Porque deve ser ótimo economizar ipv4 com DHCP, uma maravilha! Muito fácil mesmo! Mamão com açúcar! Pensando em segmentar a rede é claro, porque até onde sei loop também afeta rede com DHCP, então dizer que PPPoE é um malefício é algo que tem que ser analisado bem antes falar merda.


Consigo ter o mesmo efeito de economia de IPs que o PPPoE, usando DHCP, sem absolutamente nenhum problema! Basta imitar o comportamento do PPPoE nessa parte.




> Eu tenho um pouquinho de experiência com PPPoE, por exemplo, eu tenho um cliente que tem 22k (isso mesmo VINTE E DUAS MIL CONEXÕES PPPOE de assinantes) e eu atendo tudo com accel-ppp em 6 caixas e não passo por esses problemas aí que falam, isso me leva a crer que tem gente burra tentando usar PPPoE dá forma errada!


Aposto que atenderia com metade da quantidade de caixas se usasse DHCP, hehehe.


No meu caso, ao menos, tem também um pouco de motivação filosófica para não usar isso: simplesmente não vou usar algo de que não preciso nem trás vantagem aparente, que resolve um problema que não existe mais (não estamos mais na era do ATM, lá tinha justificativa para PPPoA, mas qual é a do PPPoE hoje?), que em teoria é desvantajoso (faça prejuízo significativo ou não, o overhead está lá, bem como o comportamento stateful sem ganho algum) e que está mais propício a problemas.

Sim, é mais propício a problemas: quantos bugs você já viu surgirem no RouterOS que deixaram o DHCP instável e quantos fizeram isso com o PPPoE? Tem que sair catando versão (você falou para não citar fabricantes, mas queira ou não, MikroTik é a realidade para provedores e isso pesa na análise)... Quando um roteador com firmware de fábrica perde configuração, para qual modo ele volta e que fará o acesso à Internet continuar funcionando, ao menos no cabo? Qual dos dois métodos trará mais problemas se for mal implementado por seja lá qual for o fabricante? Exemplo: servidor DHCP singlethreaded funciona bem e com muita capacidade, mas e o PPPoE? A implantação (na programação) e manutenção (balanceamento ou binding entre núcleos, IRQs...) do multithreading é mais suscetível a erros por demandar mais trabalho.

----------


## andrecarlim

Ótima resposta! Você está especulando, vamos falar de realidade, talvez aguardar algum colega que use isso em produção para compartilhar as dificuldades.

P.S.: qualquer provedor que depender de mikrotik, seja para transporte do link até o cliente ou no "core" da rede, deve fechar e deixar pra alguém que saiba o que está fazendo. Mikrotik jamais deve ser levado em consideração quando falamos de missão crítica ou qualquer serviço um pouco mais complexo, por favor...

----------


## andrecarlim

Queria saber porque você não usa DHCP? Defende, mas não usa, lembrando que Hotspot não é propriamente dhcp, a autenticação é por Mac ou Pap/Chap no navegador. Quero saber de DHCP! Puro e simples com IPv4 público, como faz pra "imitar" o PPPoE (sério mano, você falou imitar, a ideia não era deixar de lado o PPPoE?), Sabe me dizer? Tecnicamente falando.

----------


## TsouzaR

> Ótima resposta! Você está especulando, vamos falar de realidade, talvez aguardar algum colega que use isso em produção para compartilhar as dificuldades.
> 
> P.S.: qualquer provedor que depender de mikrotik, seja para transporte do link até o cliente ou no "core" da rede, deve fechar e deixar pra alguém que saiba o que está fazendo. Mikrotik jamais deve ser levado em consideração quando falamos de missão crítica ou qualquer serviço um pouco mais complexo, por favor...


Nem tudo aí é especulação, não estou chutando, estou dizendo o que sei com base no meu conhecimento, relatos e noites viradas fazendo pesquisas pela Internet.

Concordo quanto a não depender de MikroTik, mas qual outra solução com baixo Capex e Opex você conhece? O cara tem que gastar mais caro para usar PPPoE, se pode ter uma solução estável pagando menos?




> Queria saber porque você não usa DHCP? Defende, mas não usa, lembrando que Hotspot não é propriamente dhcp, a autenticação é por Mac ou Pap/Chap no navegador. Quero saber de DHCP! Puro e simples com IPv4 público, como faz pra "imitar" o PPPoE (sério mano, você falou imitar, a ideia não era deixar de lado o DHCP?), Ave me dizer? Tecnicamente falando.


Não uso ainda por 3 razões:

1) Legado. Peguei essa rede aqui em uma mistura de PPPoE e Hotspot com usuário e senha. PPPoE foi saindo aos poucos porque era inútil e por pressão minha. Por incômodo com usuário e senha no Hotspot, começou-se a fazer bypass dos assinantes e controlar banda via rate-limit manual no DHCP. Por inconsistência de IPs entre o ERP e os roteadores de autenticação e todos problemas decorrentes disso, bem como pelo excesso de trabalho manual e a inutilidade do Hotspot nessa forma, adotamos autenticação por MAC.

2) Outros focos. Está funcionando bem hoje e estamos focados e ocupados em outras questões. Não há no momento tempo para eu estudar a implantação disso no FreeRadius e adaptação do ERP, nem para lidar com o processo de migração e possíveis problemas que possam ocorrer. Imagino que talvez a adaptação pode ter obstáculos, não ser possível, e tenhamos que trocar de ERP, aí aumenta custo, o que não é bem vindo agora também (ou então eu desenvolvo um, mas o provedor não vai esperar).

3) Não é o momento. Estamos prestes a iniciar uma nova rede em outra tecnologia e nela, do zero, vamos já adotar o DHCP + Radius. Talvez, nesse momento, eu aproveite para migrar a rede atual e padronizar tudo. Vou abandonar Hotspot + MAC basicamente por filosofia, não é a solução correta, e também porque é praticamente preso a MikroTik.


Sobre imitar: que tal "seguir o exemplo"? kkkkk. Não que seja algo inventado pelo PPPoE, mas a forma como ele proporciona a economia de IPs é a única que conheço com tamanha eficiência, então tem que fazer igual. Se é apenas uma das formas como DHCP pode ser configurado, qual o problema? Eu já tinha essa ideia antes, mas ela foi apresentada na lista GTER há pouco tempo como solução para um problema parecido. Consegue se lembrar?

----------


## andrecarlim

Ótimo, espero que eu esteja por aqui para conversarmos quando você "mexer" nisso! Espero ansiosamente que compartilhe a sua experiência com o DHCP em nível 'carrier-grade'.

P.S.: sobre valor de equipamentos, hoje em dia, tenho clientes com 2000 sessões PPPoE sobre Core i3 passando ~ 900mbps, com 4gb de memória, alguns ajustes no kernel, Debian e accel-ppp... Muito tranquilo e confiável, preço bom para toda a tranquilidade e nível de "profissionalismo" da solução, claro ainda tem a energia e tal, mas isso para 2000 clientes que não incomodam, nem conta, e o melhor, depois do iptables bem configurado não preciso atualizar muito não, fica lá ligado uns 400 dias até trocar de máquina... Aí que entra o grande ponto da discussão... Vale a pena usar equipamento "super" barato e sacrificar essas noites de sono que você perdeu para vim me dizer que Mikrotik leva peso na decisão? Ou até mesmo dizer que o PPPoE é obsoleto em frente ao dhcp? Quem se importa com o overhead se tudo está funcionando bem e o provedor ativando cliente de vento em poupa? Pense nisso que falei.

----------


## eduardomazolini

Modo ARP reply-only e ativar no servidor DHCP o Add ARP for Leases isso eu entendi e uso em Hotspot.

Eu não entendi a questão do circuito id, pode explicar melhor?

O remote id seria o nome no caso de PC e celulares, correto?

Eu tenho vários concentradores, um em cada torre o que me leva ao problema de ter muitos ranges de IPs pra fazer NAT, não consigo dividir meus IPs Públicos em tantos concentradores.
Como meus concentradores estão dispersos não tenho problema de overhead.
Como tenho muitos concentradores é difícil usar o conceito de banda mínima quando o Link fica lotado, as filas estão em caixas diferentes, não da pra somar.
Eu confesso que já usei ver tempo que o PPPoE está ativo pra achar muitos problemas de baixo nível (cabos de antena com problema, interferência, CCQ baixo).
Eu penso que não acharia esses problemas com DHCP. Mas aí é questão de experiência.

----------


## delegato

Outra vantagem do dhcp, sobre o pppoe, é o quesito de configuração de equipamento, se um cliente reseta seu roteador não ficará sem internet se usar dhcp, já pppoe terá que deslocar um técnico até o local para reconfigurar, ou seja dhcp é bem prático, aqui sempre usei dhcp, com pppoe nunca tive muito sucesso apesar de hoje estar usando as duas formas, pppoe sempre tem umas quedas inexplicáveis.

No dhcp consigo distribuir ips com /30 ou seja clientes não se enxergam, esses ips podem ser dinâmicos ou fixados em mark static, com alguns filtros nas lans (bridge), client isolation nos aps, fica bem segura a rede.

Comecei a usar bastante pppoe em depois de uma rede cabeada alguns roteadores que não pegaram o ip automaticamente ae colocava pppoe, hoje tenho bastante pppoe, mais volta e meia algum cliente burro reseta um roteador ae temos que reconfigurar...

----------


## eduardomazolini

> No dhcp consigo distribuir ips com /30 ou seja clientes não se enxergam, esses ips podem ser dinâmicos ou fixados em mark static, com alguns filtros nas lans (bridge), client isolation nos aps, fica bem segura a rede.


Aí vai a minha primeira coisa que já tinha falado. Você pode usar um Gateway comum a todos e atribuir máscara /32.

----------


## TsouzaR

> Vale a pena usar equipamento "super" barato e sacrificar essas noites de sono que você perdeu para vim me dizer que Mikrotik leva peso na decisão?


Preço não é o único fator. Me diga outra plataforma que possibilite implantar PCQ e Hotspot com todos recursos, sem um trabalho insano ou muito manual e sem gambiarras, bem como possua uma interface de scripting flexível e ilimitada, integrada a boa parte dos recursos, além de ser tão automatizada via Radius (exemplo: parâmetros Radius para adicionar IP a address list), que largo MikroTik no controle/autenticação de assinantes.

Se é possível continuar usando MikroTik e usufruindo de todos esses recursos, por que trocaria apenas devido a uma forma de autenticação que não funciona tão bem com esse fabricante?

_Adição:_ ah, o que eu falei é que a *realidade dos provedores*, que é de bastante uso de equipamentos MikroTik, pesa na análise, não que vou escolher algo pensando em um fabricante em específico.




> Ou até mesmo dizer que o PPPoE é obsoleto em frente ao dhcp? Quem se importa com o overhead se tudo está funcionando bem e o provedor ativando cliente de vento em poupa? Pense nisso que falei.


Eu disse que PPPoE resolve um problema que não existe mais. Se isso é chamar de obsoleto, então é obsoleto, porque é um fato.

Funcionar, até rede toda em bridge funciona. Mas é escalável? Sei que PPPoE escala, mas é a forma MAIS escalável? Talvez seja meu perfeccionismo, mas não me conformo em usar algo, mesmo que funcione bem, sabendo que há uma alternativa ainda melhor disponível sem gerar mais custos nem ter que trocar equipamentos. Isso é parte da motivação filosófica de que falei.

----------


## eduardomazolini

Pcq no PPPoE é possível de forma simples. Não sei exatamente o que faz mas eu uso.

----------


## AndrioPJ

> Outra vantagem do dhcp, sobre o pppoe, é o quesito de configuração de equipamento, se um cliente reseta seu roteador não ficará sem internet se usar dhcp, já pppoe terá que deslocar um técnico até o local para reconfigurar, ou seja dhcp é bem prático, aqui sempre usei dhcp, com pppoe nunca tive muito sucesso apesar de hoje estar usando as duas formas, pppoe sempre tem umas quedas inexplicáveis.
> 
> No dhcp consigo distribuir ips com /30 ou seja clientes não se enxergam, esses ips podem ser dinâmicos ou fixados em mark static, com alguns filtros nas lans (bridge), client isolation nos aps, fica bem segura a rede.
> 
> Comecei a usar bastante pppoe em depois de uma rede cabeada alguns roteadores que não pegaram o ip automaticamente ae colocava pppoe, hoje tenho bastante pppoe, mais volta e meia algum cliente burro reseta um roteador ae temos que reconfigurar...


uma falsa premissa que muitos provedores tem ao usar ppoe é que por ele usar usuario/senha já estão seguros.
Sinto dizer-lhes, mas não estão...
Não importa se usa dhcp, hotspot ou ppoe... a segurança da rede é sempre bem vinda.
E isso não é algo que um unico protocolo via resolver, mas sim um conjunto de técnicas, sendo algumas delas fisicas.





> Conversa de gente grande aqui, hein? Eu prefiro ficar quietinho, só esperando a hora certa para argumentar.
> 
> Mas, agora eu vim pra perguntar: Hoje tenho a minha disposição um Juniper MX104 (que por sinal, todos nós sabemos que é muito robusto, né?) somente para trabalhar como concentrador PPPoE, quais as vantagens que eu teria - *utilizando essa caixa* - mudando de PPPoE para DHCP?
> 
> Alguém que já tenha aplicado o "option 82" para poder nos mostrar e compartilhar experiência? Isso tá igual filhote de pombo, só ouço/leio falar, mas ainda não pude ver e contemplar com meus olhos.


Se levar em consideração o overhead do protocolo pppoe, já é um belo motivo para migrar para dhcp.

----------


## TsouzaR

> Pcq no PPPoE é possível de forma simples. Não sei exatamente o que faz mas eu uso.


Sim, o que eu quis dizer é que não há PCQ fora do RouterOS, ou ao menos não há sem um trabalho enorme e um monte de coisas manuais e Shell Scripts, principalmente em Linux ou BSD puro. O fato do RouterOS ter esse recurso em um nível de usabilidade condicente com sistemas de rede valoriza bastante ele.




> Mas, agora eu vim pra perguntar: Hoje tenho a minha disposição um Juniper MX104 (que por sinal, todos nós sabemos que é muito robusto, né?) somente para trabalhar como concentrador PPPoE, quais as vantagens que eu teria - *utilizando essa caixa* - mudando de PPPoE para DHCP?


- vai conseguir manter o MTU padrão da Internet, de 1500, até os dispositivos de seus clientes, ou seja: sem fragmentação, que aumenta os pacotes por segundo para uma mesma quantidade de tráfego e demanda mais trabalho de processamento.

- vai remover uma máquina de estados inútil para a utilização de serviços de rede, Internet, etc., que é a das sessões PPPoE.

Esses dois itens vão prolongar um pouco a chegada ao limite da capacidade do equipamento. Ainda mais um MX104, que para chegar no limite vão milhares de assinantes encima, quantidade em que o ganho em escala é maior ainda. Só não tenho números exatos, procurei benchmark e não achei, então me baseio na teoria.

- se chegar a colocar outra caixa fazendo redundância no DHCP um dia, um problema vai ser muito menos imperceptível (talvez totalmente) para o assinante na convergência do que no caso de sessões PPPoE caindo e reconectando no outro concentrador. VRRP/HSRP no gateway para o cliente é possível, bem como acho que há outras tecnologias proprietárias que sincronizam até as conexões (talvez exista algo que sincronize sessões PPPoE, mas também deve ser só em solução top de tudo, até preço - se existir, esse MX104 deve ter...). Até uma máquina virtual pode rodar um servidor DHCP à parte para milhares de assinantes... Resumindo: vejo muito mais flexibilidade com DHCP.

----------


## eduardomazolini

Quanto ao MTU os rádios e Mikrotik de hoje suportam MTU maiores justamente pra passar MPLS e PPPoE e no final continuar com 1500, não é?

A máquina de estado não vejo problema por enquanto. A vantagem da redundância sem queda acho que seja pequena perante ao problema que elevou a mudar de caixa. Ela inclusive me ajudou a perceber situações de má qualidade ou problemas de baixo nível.

Mas essa questão de circuit id e/ou opção 82 alguém pode me explicar?

----------


## gregorypv

> Problema nenhum! Só quero saber se alguém mantém para dizer pra gente se existe problema... Porque deve ser ótimo economizar ipv4 com DHCP, uma maravilha! Muito fácil mesmo! Mamão com açúcar! Pensando em segmentar a rede é claro, porque até onde sei loop também afeta rede com DHCP, então dizer que PPPoE é um malefício é algo que tem que ser analisado bem antes falar merda.
> 
> Eu tenho um pouquinho de experiência com PPPoE, por exemplo, eu tenho um cliente que tem 22k (isso mesmo VINTE E DUAS MIL CONEXÕES PPPOE de assinantes) e eu atendo tudo com accel-ppp em 6 caixas e não passo por esses problemas aí que falam, isso me leva a crer que tem gente burra tentando usar PPPoE dá forma errada!
> 
> Isso é só um cliente, tenho muitos provedores, sem falar das empresas que atendo que tem aquelas VLANs podres dá OI que pra funcionar tive que ter servidor PPPoE exclusivo sobre a rede dá oi e funciona em mais de 15 estados do país, para atender aproximadamente 500 filiais com trabalhos de missão crítica, tendo servidores que estão ligados a mais de 600 dias com o processo do rp-pppoe sem travar, isso mesmo, nem tive coragem de trocar para accel ainda!
> 
> E isso que falam que PPPoE não funciona!


Rpz....vc já tentou acessar a rb via Mac?
Vc percebeu que a conexão as vezes cai? Nao eh pppoe mas é camada 2. E olha que eh ponto a ponto de fato. Cabo na rb e outra ponta no note.
Pppoe funciona na camada 2. Se funciona com 500 usuários ou 22k usuários deve funcionar sim. Agora aposto com vc que muitos ficam caindo. Muitos dizem que funciona normal pq não acompanha e o usuário não reclama. Pq a queda leva de 4 a 10 segundos. Muito desses caras nem sabem da active connection.
Camada 2 não tem controle de fluxo nem retransmissão e aí já viu

----------


## TsouzaR

> Quanto ao MTU os rádios e Mikrotik de hoje suportam MTU maiores justamente pra passar MPLS e PPPoE e no final continuar com 1500, não é?


De fato, é uma solução, mas nem sempre é uma possibilidade: talvez não queiram ou saibam mexer nisso, talvez a rede seja muito grande para sair mudando MTU em todo lugar, talvez algum equipamento não suporte o aumento de mais 8 bytes ou talvez já esteja no máximo com o PPPoE passando dentro de VLANs, VPLS, etc. (até EoIP tem que considerar, já que o @*andrecarlim* diz que gosta dele)... DHCP é uma solução que não requer muitas intervenções/alterações na rede nem equipamentos, e eu gosto disso.




> Mas essa questão de circuit id e/ou opção 82 alguém pode me explicar?


Nas mensagens de requisição e resposta do DHCP as informações são enviadas em campos (ou "opções", embora eu não veja sentido no porquê de chamarem assim), que são identificados por um ID conhecido, definido pela IANA para cada tipo de dado: https://www.iana.org/assignments/boo....xhtml#options

A opção 82 é chamada Relay Agent Information e é dividia em 2 sub-campos, preenchidos pelo relay DHCP: Circuit-ID e Remote-ID. Circuit-ID identifica basicamente ou circuito ou rede em que a requisição DHCP chegou, enquanto Remote-ID identifica quem a originou. Cada relay preenche isso de uma forma: em uma OLT podem ser dados derivados da identificação da ONU na rede, com número do slot da placa e porta PON e identificador da ONU na porta, - FiberHome faz assim, pelo que sei - enquanto na maioria dos dispositivos (é o caso de MikroTik e acho que UBNT e todos switches também), Circuit-ID vai ser a porta física em que chegou a requisição e Remote-ID vai ser o endereço MAC de quem originou.

No caso de Remote-ID sendo MAC eu acho meio inútil, como já falei em um post anterior, mas se for usada outra informação, até mesmo definida manualmente, ou algo como as OLTs FiberHome fazem, é extremamente útil para identificar os assinantes na hora entregar o IP, pois o servidor DHCP vai enviar esses valores da opção 82 como parâmetros da Access-Request para o servidor Radius, que pode fazer comparações contra eles.

----------


## andrecarlim

> Rpz....vc já tentou acessar a rb via Mac?
> Vc percebeu que a conexão as vezes cai? Nao eh pppoe mas é camada 2. E olha que eh ponto a ponto de fato. Cabo na rb e outra ponta no note.
> Pppoe funciona na camada 2. Se funciona com 500 usuários ou 22k usuários deve funcionar sim. Agora aposto com vc que muitos ficam caindo. Muitos dizem que funciona normal pq não acompanha e o usuário não reclama. Pq a queda leva de 4 a 10 segundos. Muito desses caras nem sabem da active connection.
> Camada 2 não tem controle de fluxo nem retransmissão e aí já viu



Não, não fica caindo, funciona bem porque a rede é boa!

----------


## andrecarlim

Vou ser honesto, estou de saco cheio de ver o povo aqui analisando protocolo, se é ruim ou bom, baseado nas experiencias com mikrotik! Alguém aqui já tentou "rodar" o provedor sem mikrotik, como eu faço nos meus clientes? Pelo menos no "core"?

----------


## eduardomazolini

> Vou ser honesto, estou de saco cheio de ver o povo aqui analisando protocolo, se é ruim ou bom, baseado nas experiencias com mikrotik! Alguém aqui já tentou "rodar" o provedor sem mikrotik, como eu faço nos meus clientes? Pelo menos no "core"?


Eu tô pensando em colocar na borda um edgRouter mas ainda não comprei. O Mikrotik ainda é o melhor custo benefício. Quero muito precisar de juniper um dia. Hoje uso só uma CCR.
Mas não acho um protocolo bom ou ruim abri o tópico pra aprender mesmo.
Vejo muita gente falar de usar DHCP como o melhor pra quem sabe de verdade, pra quem sabe o que faz. Então quero que quem sabe mesmo dívida comigo esse conhecimento.

Eu mesmo to dizendo que eu não sei direito e não sei se é por que não uso cabo então não precisei. Nunca usei circuit id. To começando achar que isso tem haver com DHCP relay que eu não uso e não vejo por que usar.

----------


## eduardomazolini

@*TsouzaR* obrigado pela resposta eu achei certo então. Comecei a ler o tópico de baixo pra cima.
E que como uso Mikrotik pra mim seria mais vantagem usar radius no DHCP do que fazer relay.

----------


## gregorypv

> Não, não fica caindo, funciona bem porque a rede é boa!


É como exemplifiquei o problema não eh uma rede boa. Eh a tecnologia usada que eh limitada.

----------


## saviomarques

> Ótima resposta! Você está especulando, vamos falar de realidade, talvez aguardar algum colega que use isso em produção para compartilhar as dificuldades.
> 
> P.S.: qualquer provedor que depender de mikrotik, seja para transporte do link até o cliente ou no "core" da rede, deve fechar e deixar pra alguém que saiba o que está fazendo. Mikrotik jamais deve ser levado em consideração quando falamos de missão crítica ou qualquer serviço um pouco mais complexo, por favor...


Caro Anderson, 

Me permita Discordar, sendo que cada caso é um caso, mais eu utilizo Mikrotik em soluções críticas e não tenho problemas, servidores com uptime alto, sem nenhum , problema.

Pessoalmente acredito que muita gente não estuda e faz qualquer coisa que vê na internet e não sabe nem fazer um update de um equipamento corretamente.

Então é mais fácil falar mal do equipamento do que entender qual o problema.]

Att..

----------


## andrecarlim

> Caro Anderson, 
> 
> Me permita Discordar, sendo que cada caso é um caso, mais eu utilizo Mikrotik em soluções críticas e não tenho problemas, servidores com uptime alto, sem nenhum , problema.
> 
> Pessoalmente acredito que muita gente não estuda e faz qualquer coisa que vê na internet e não sabe nem fazer um update de um equipamento corretamente.
> 
> Então é mais fácil falar mal do equipamento do que entender qual o problema.]
> 
> Att..


Meu nome é André!

Amigo estamos mantendo a discussão com foco em provedores de acesso, no que concerne mais a parte de roteamento e controle de autenticações, não estou falando de outros trabalhos que o mikrotik pode ser útil, eu também uso muito mikrotik em VPN e trabalhos que não exigem tanto do hardware, mas que demandam "confiabilidade" e "segurança", quando digo depender de mikrotik, quero dizer em provedores de acesso!

Eu uso até OpenWRT em mikrotik (sacanagem com o RouterOS, haha)! E não me incomodo, mikrotik é bom, mas aplicado na função correta!

----------


## TsouzaR

> Vou ser honesto, estou de saco cheio de ver o povo aqui analisando protocolo, se é ruim ou bom, baseado nas experiencias com mikrotik! Alguém aqui já tentou "rodar" o provedor sem mikrotik, como eu faço nos meus clientes? Pelo menos no "core"?


Você está ignorando tudo que falei e focando apenas na parte que cito MikroTik. Olha, não tenho certeza, mas acho que se eu pesquisar encontro até o nome dessa falácia argumentativa.

Mas já que não quer falar de MikroTik, vamos então falar de EdgeRouter: será que a quantidade de clientes que posso colocar com PPPoE em um ERPRo-8 vai ser a mesma que ele suporta de clientes trafegando com uso de DHCP? Pesquisei informações sobre isso (um comparativo ou benchmark, talvez) e não encontrei, mas baseado na teoria tenho quase certeza de que ele não mantém os 1.2Gbps de capacidade com a mesma quantidade de assinantes. Ainda tem que ver quantas sessões dá para manter, mas tenho certeza que é BEM menos que leases DHCP (o servidor DHCP pode estar até em outra máquina, inclusive virtual, se for preciso).

O que quero mostrar é que, independente de fabricante, PPPoE vai fazer uso menos eficiente dos recursos (mais uso sem trazer vantagens). Vai ser a mesma coisa em x86 ou qualquer outra plataforma. Quantos porcentos isso representa? Não sei, mas certamente vai haver algo, que em grande escala poderá ter muita representatividade na operação toda. Visão de longo prazo é isso.

Fazendo um comparativo com o mundo do desenvolvimento de software, o que você está defendendo é aumentar a capacidade de hardware, ao invés de tornar o software mais eficiente para demandar menos recursos. "Tem uma funçãozinha ou outra que não está performando bem, mas é pouca coisa, vamos deixar para lá." Daqui a pouco essa deficiência aumenta junto com a demanda e já era. Não é o melhor caminho por custo, sustentabilidade ecológica e outras razões.

Não entenda como uma flamewar nem nada pessoal, isso aqui é uma discussão saudável e estou apenas apresentando meus pontos. Talvez para alguns isso tudo que falei não seja suficiente para justificar, mas para mim é, toda discussão ou análise é assim: prós e contras em ambos lados. Você é que parece condenar MikroTik cegamente em ambiente ISP; eu não acho interessante para borda com mais de 1 full routing nem para núcleo de roteamento, dependendo dos protocolos usados, e como concentrador PPPoE também não é algo que se chame de "rock solid", mas como um ponto de controle de banda e autenticação com DHCP + Radius é uma boa plataforma.




> @*TsouzaR* obrigado pela resposta eu achei certo então. Comecei a ler o tópico de baixo pra cima.
> E que como uso Mikrotik pra mim seria mais vantagem usar radius no DHCP do que fazer relay.


Quem adiciona o Circuit-ID e Remote-ID é o relay, por isso a opção 82 se chama Relay Agent Information. Não tem como fazer apenas com o servidor DHCP, ao menos não com MikroTik. Se houver alguma implementação disso que não precise de relay, deve ser fora do padrão.

----------


## delegato

> Aí vai a minha primeira coisa que já tinha falado. Você pode usar um Gateway comum a todos e atribuir máscara /32.


Não sabia dessa informação, aqui com /30 crio um gateway para cada cliente adicionando um ip na faixa lá em ip address

----------


## andrecarlim

@*TsouzaR* mas é claro, nem eu quero que fique ofendido comigo, estamos expondo nossas ideias, eu é que me passo um pouco nos comentários, hehe, mas gosto muito do pppoe!

Sobre falar de equipamentos, eu quero dizer roteadores de verdade, usando hardware x86, Juniper ou Cisco. EdgeRouter e mikrotik, do meu ponto de vista, para pppoe, não servem, pelo menos não pra mais de 1000 sessões.

----------


## eduardomazolini

> Não sabia dessa informação, aqui com /30 crio um gateway para cada cliente adicionando um ip na faixa lá em ip address


Tenta aí! Não funciona com alguns Linux. Pessoalmente não funciona na tv dá minha sala kkk tive que fixar o IP dela, pois mudei o DHCP pra essa forma.
Deixando claro o roteador você configura normal com /24 ou o que estiver usando. Depois de tudo pronto dá forma normal vai em DHCP Server / Network e abre o campo máscara e coloca o valor 32.

----------


## eduardomazolini

> @*TsouzaR* mas é claro, nem eu quero que fique ofendido comigo, estamos expondo nossas ideias, eu é que me passo um pouco nos comentários, hehe, mas gosto muito do pppoe!
> 
> Sobre falar de equipamentos, eu quero dizer roteadores de verdade, usando hardware x86, Juniper ou Cisco. EdgeRouter e mikrotik, do meu ponto de vista, para pppoe, não servem, pelo menos não pra mais de 1000 sessões.


Eu uso no máximo 180 por caixa e tenho vários.
E não uso EoIP ou semelhantes pra unir as caixas pois também não confio no procolo em situação que preciso de retransmissão, como pode ocorrer em um link PTP eventualmente engargalado ou com interferência, ou qualquer situação normal dá rede ethernet.
Eu uso cliente --> AP --> PPPoE server, nada de caminhos longos.

----------


## Batmam

Galera acompanhando esse tópico aqui, trabalho com pppoe hj. Fiquei com um dúvida, trabalhando com dhcp o ideal é criar um /32 pra cada cliente? E cada cliente tenho que add esse ip lá am address? Entendi isso bem mesmo.

----------


## eduardomazolini

> Galera acompanhando esse tópico aqui, trabalho com pppoe hj. Fiquei com um dúvida, trabalhando com dhcp o ideal é criar um /32 pra cada cliente? E cada cliente tenho que add esse ip lá am address? Entendi isso bem mesmo.


Deixando claro o roteador você configura normal com /24 ou o que estiver usando. Depois de tudo pronto dá forma normal vai em DHCP Server --> Networks e abre o campo Netmask e coloca o valor 32.

----------


## eduardomazolini

Eu testei agora o DHCP Server com Radius e funcionou de boa, não usei Agent Relay.
Meu Radius ficou assim:

radreply:
"00:F4:6F :Big Grin: 6:35:5B";"Framed-IP-Address";":=";"192.168.3.10" --> IP que entreguei para o meu celular
"00:F4:6F :Big Grin: 6:35:5B";"Mikrotik-Rate-Limit";"==";"768K/3072K 1536K/6144K 192K/768K 48/48 7 461K/1843K"
"00:F4:6F :Big Grin: 6:35:5B";"Session-Timeout";"==";"216000"
"00:F4:6F :Big Grin: 6:35:5B";"Acct-Interim-Interval";"==";"900" --> não sei se funciona no DHCP
"00:F4:6F :Big Grin: 6:35:5B";"Mikrotik-Address-List";"==";"teste" --> só pra testar se atribui


Ao invés do IP (Framed-IP-Address) consigo informar o pool da RB.
"00:F4:6F :Big Grin: 6:35:5B";"Framed-Pool";":=";"pool1-LAN"

radcheck:
"00:F4:6F :Big Grin: 6:35:5B";"Simultaneous-Use";":=";"1"
"00:F4:6F :Big Grin: 6:35:5B";"Service-Type";":=";"Framed-User"
"00:F4:6F :Big Grin: 6:35:5B";"Auth-Type";":=";"Accept"
"00:F4:6F :Big Grin: 6:35:5B";"NAS-IP-Address";"==";"10.150.51.240" --> ip do meu roteador
"00:F4:6F :Big Grin: 6:35:5B";"Called-Station-Id";"==";"server1" --> nome do meu servidor dhcp no mikrotik


Então resumindo rolou sem precisar trabalhar com dhcp relay.
Meu problema é o MKSolutions ele não quer aceitar IP por ATRIBUIÇÃO no IP-Binding (Framed-IP-Address) por algum bug funcionou, depois ficou reclamando "Os ips das conexões IP-Bindings, só podem ser do tipo Requisito ou Dinâmico"
O tipo requisito é pra ele conferir o IP de origem, mas em DHCP isso não entendo o sentido.
O tipo dinâmico é o Framed-Pool funciona de boa

----------


## TsouzaR

> Eu testei agora o DHCP Server com Radius e funcionou de boa, não usei Agent Relay.
> Meu Radius ficou assim:
> 
> radreply:
> "00:F4:6F6:35:5B";"Framed-IP-Address";":=";"192.168.3.10" --> IP que entreguei para o meu celular
> "00:F4:6F6:35:5B";"Mikrotik-Rate-Limit";"==";"768K/3072K 1536K/6144K 192K/768K 48/48 7 461K/1843K"
> "00:F4:6F6:35:5B";"Session-Timeout";"==";"216000"
> "00:F4:6F6:35:5B";"Acct-Interim-Interval";"==";"900" --> não sei se funciona no DHCP
> "00:F4:6F6:35:5B";"Mikrotik-Address-List";"==";"teste" --> só pra testar se atribui
> ...


Você não usou opção 82 aí, que seriam os atributos *Redback-Agent-Remote-Id* e *Redback-Agent-Circuit-Id* na _radcheck_. Pode até inspecionar aí e ver que esses atributos nem estão sendo enviados na Access-Request para o Radius, porque para o servidor DHCP, que se comunica com ele, esses campos estão vazios - quem preenche é o relay.

Mas também dá para usar DHCP + Radius sem verificar pela opção 82 sem problemas, ainda mais com o Remote-ID sendo tão inútil na maioria dos relays. Nesse caso, o atributo Remote-ID é a mesma coisa do User-Name, e o Circuit-ID pode ser substituído pelo Called-Station-Id (o valor vai ser diferente, a não ser que você nomeie o servidor DHCP com o nome da interface onde ele está rodando, mas dá pra ter perfeitamente o mesmo efeito).

O Interim Update não funciona com DHCP mesmo, até porque a utilidade dele é para accounting, se não me engano, e DHCP nada tem a ver com o tráfego na rede. Para accounting tem que usar Traffic Flow; um pouquinho mais de trabalho, mas a maioria vive bem sem isso e quem realmente precisar não deve se importar.

----------


## eduardomazolini

Agora a questão minha é mudar de WPA-PSK para WPA-EAP e assim ter usuário e senha no wireless.
Ver se a Mksolutions libera a atribuição.
No futuro além de consumir menos processador por usar DHCP e não PPPoE ainda vou pagar menos em caixas que trabalham com DHCP relay e não precisam ser Mikrotik.

Espera ..... se for DHCP relay com switch comum, como você cria as filas pra limitar o plano?

----------


## TsouzaR

> Espera ..... se for DHCP relay com switch comum, como você cria as filas pra limitar o plano?


Switches gerenciáveis decentes geralmente suportam controle de banda e possuem cliente Radius. É o caso de Datacom DM3xxx e DM4xxx. É esperado que eles tenham um atributo que o Radius pode enviar e que vai possibilitar criar a fila de controle de banda, funcionalmente semelhante ao Mikrotik-Rate-Limit. Tem que verificar com o fabricante e na documentação.

Switch layer 3 certamente permite controlar por IP, agora os layer 2 eu não tenho certeza se todos vão inspecionar o pacote até essa camada para a limitação (acho que os Datacom L2 fazem isso) ou se vai ser possível criar fila apenas para porta física ou VLAN...

----------


## eduardomazolini

Eu como usuário de Mikrotik penso em duas coisas diferentes juntas
- autenticação
- limite de velocidade

Se é usado DHCP relay o switch não faz o controle de banda pois pra isso precisa do radius.

Pode ter um switch que recebe o relay e esse ter radius. Se ele ficar no meio do caminho pode ser que a banda seja atribuída nele, mesmo a entrega tendo sido feita na ponta por um DHCP relay.

Como vocês que usam DHCP Relay, como e onde fazem o controle de banda?

----------


## TsouzaR

> Eu como usuário de Mikrotik penso em duas coisas diferentes juntas
> - autenticação
> - limite de velocidade
> 
> Se é usado DHCP relay o switch não faz o controle de banda pois pra isso precisa do radius.
> 
> Pode ter um switch que recebe o relay e esse ter radius. Se ele ficar no meio do caminho pode ser que a banda seja atribuída nele, mesmo a entrega tendo sido feita na ponta por um DHCP relay.
> 
> Como vocês que usam DHCP Relay, como e onde fazem o controle de banda?


Realmente, a função do switch nessa parte seria apenas atuar como relay e eu tinha me esquecido de que relay não recebe os parâmetros da resposta do Radius para poder criar limite de banda ou qualquer outra coisa. O servidor DHCP tem que estar em outro equipamento por onde o tráfego vai passar, geralmente o roteador (RB...) do PoP ou um "concentrador". Poderia ser até em outro switch gerenciável com servidor DHCP e cliente Radius com os parâmetros adequados...

Um método que provavelmente possibilita fazer o controle de banda no relay, quer seja um switch ou qualquer outro equipamento, é usar o módulo "exec" do FreeRADIUS para executar um script assim que é feito login ou logout, sendo que esse script faria o acesso por SSH, Telnet, API ou qualquer outro método ao equipamento do relay e adicionaria/removeria lá a fila e quaisquer outras coisas. A vantagem é que vai dar para fazer controle de banda no equipamento do relay mesmo que ele não suporte Radius ou não tenha parâmetro para isso.

----------


## eduardomazolini

Então mas alguém aqui na lista defendeu o DHCP deve usar e pelo que entendi sempre falando dos parâmetros do Relay. Não lembro quem foi.
Como alguém que já usa esta usando?

@TsousaR obrigado pela resposta a questão do exec, vou pesquisar pois como disse uso concentradores separados.
Eu queria criar as regras em um roteador perto de borda pra poder gerenciar melhor a banda. Vou usar o exec pra fazer isso no roteador que não participa diretamente do login.

----------


## eduardomazolini

Morreu o tópico, todo mundo ficou quieto. Como vocês do DHCP que fizeram posts a favor fazem o controle de banda? Vou chamar o pessoal que defendeu DHCP aqui pelo nome pra pedir ajuda.

----------


## eduardomazolini

@*andrecarlim* vi em algum lugar você falando do accer-pppoe algo assim. Um dia dei uma procurada é um software livre de PPPoE gostei da ideia.
Como você faz o controle de banda? Como costuma ser sua estrutura?

Eu acho Mikrotik legal em:
- pcq
- burst
- preço
- facilidade de usar firewall netfiler (comandos iptables)
- preguiçoso que sou, tá tudo junto, não é por que faz tudo que tem que fazer tudo na mesma caixa.

----------


## andrecarlim

> @*andrecarlim* vi em algum lugar você falando do accer-pppoe algo assim. Um dia dei uma procurada é um software livre de PPPoE gostei da ideia.
> Como você faz o controle de banda? Como costuma ser sua estrutura?
> 
> Eu acho Mikrotik legal em:
> - pcq
> - burst
> - preço
> - facilidade de usar firewall netfiler (comandos iptables)
> - preguiçoso que sou, tá tudo junto, não é por que faz tudo que tem que fazer tudo na mesma caixa.


Já uso accel em meus clientes a mais de um ano, está bem "sólido" o funcionamento.

O accel-ppp já tem módulo de shaper "built-in", não que ele controle a banda, mas ele aplica as queues lá no kernel através do TC (que eu usava antes com scripts). Mesmo assim eu queria um Burst semelhante ao do mikrotik, eu fiz isso no ip-up do accel-ppp. Quanto a preço, qualquer Core i3 com placa mãe Asus e 4gb de ram atende tranquilamente 2000 sessões PPPoE, claro, isso não depende somente do accel, mas de um ajuste fino do kernel, o único custo mais elevado ao se usar accel-ppp é com boas placa de rede, falo isso porque essas placas comuns não tem o maravilhoso recurso de multi-queue, e esse recurso ajuda muito quando se passa dos 300mbps, na verdade é indispensável.

Sobre facilidade de uso, com Linux a gente sofre um pouco, mas a satisfação/tranquilidade é incalculável depois de pronto!

----------


## deson00

Uma coisa é uma coisa outra coisa é outra coisa.
Se vc quer ter login e senha vai de pppoe se não quer vai de dhcp.
Poco importa o protocolo ou tecnologia, q importa é o q vc quer fazer ai basta implantar as seguranças necessárias.
Se lhe atender satisfatoriamente bola pra frente.
Tem coisas não suportadas ao pppoe como central Alcatel.
Já tive um caso q na rede atendia vários pontos públicos e usava central Alcatel q não tem suporte a pppoe ai só DHCP, ou seja depende de cada caso.

----------


## eduardomazolini

@*deson00*,

E quais as seguranças necessárias? Como você faz?

Hoje entrei em contato com a MKSOLUTIONS pra ajudar meu cenário, explicar o que eu iria fazer.

"""
No início no chat foi meio difícil, mas depois um cara bom me atendeu deu atenção e procurou entender o que eu queria, 1vez que vou elogiar a Mksolutions. Eu sempre digo que eles são uns patos, nada, voa e anda mais ou menos. Em cima de uma plataforma de janelas horrível, "Maker" velhão.
Mas do que tem no mercado dos ruins é o menos pior.
Também tem coragem de assumir o suporte do radius, um outro produto queria que eu montassem o radius eles indicavam um consultor pra configurar o radius que não seria de responsabilidade deles.
"""

Eles me alertaram sobre a falta de accouting que impede registro do IP usado pelo cliente.
Também impede guardar o consumo de dados do cliente, exibir a velocidade de consumo atual(no sistema deles), na RB não vai ter interface vai ter que olhar direito na queue.

O usuário e senha vou ter no caso do wireless com WPA-EAP

Lógico que toda solução depende dos hardwares e softwares envolvidos.
Eu apesar de adorar software livre não sei se posso usar accell-ppp com Mksolutions, vou estudar.
VyOS me parece maravilhoso e agora uma versão acessível nos roteadores da Ubiquiti, vou estudar também.

Agora pra quem está iniciando fazer uma arquitetura certa ajuda muito.

A MKSolutions me deu a dica de usar Hotspot por autenticação de Mac. Não é o DHCP puro mas é sem o protocolo PPPoE seja a vantagem que isso for realmente.

----------


## andrecarlim

> Eu apesar de adorar software livre não sei se posso usar accell-ppp com Mksolutions, vou estudar.


Cara tenho alguns clientes que quando comecei a atender já usavam o mk-solutions, aí eu coloquei o dicionário do Mikrotik pra rodar no accel, ativei o script no ip-up de cada conexão PPPoE, acertei os atributos, e voilá, temos o controle de banda!

Também tratei de cuidar daqueles que estão bloqueados, pelo atributo de address-list que o mk-solutions envia, e configurei uma interface web no servidor que roda o accel, para poder desconectar usuário, ver a banda em tempo real e etc.

Contudo tenho um cliente que conhece um dos proprietários dá mk-solutions que fez uma pressão lá e parece que estão trabalhando para suportar "nativamente" o accel, já até passei a listagem de comandos para poderem administrar as sessões PPPoE diretamente pelo suporte do mk-solutions, espero ansiosamente que façam isso!

Enfim, com um pouco de imaginação e criatividade as possibilidades com o accel-ppp são bem abrangentes!

----------


## AndrioPJ

> Morreu o tópico, todo mundo ficou quieto. Como vocês do DHCP que fizeram posts a favor fazem o controle de banda? Vou chamar o pessoal que defendeu DHCP aqui pelo nome pra pedir ajuda.


Da para fazer normalmente, o mk suporta isso.
Para fazer manualmente, abra o DHCP-Server > Leases
Crie um cadastro ali, em RATE LIMIT coloque a velocidade que vc quer que o cliente tenha.
Ai sempre que o cliente receber um IP, o controle de banda será criado automatiamente.

Ou use Radius para passar essas informações.




> @*deson00*,
> 
> E quais as seguranças necessárias? Como você faz?
> 
> Hoje entrei em contato com a MKSOLUTIONS pra ajudar meu cenário, explicar o que eu iria fazer.
> 
> """
> No início no chat foi meio difícil, mas depois um cara bom me atendeu deu atenção e procurou entender o que eu queria, 1vez que vou elogiar a Mksolutions. Eu sempre digo que eles são uns patos, nada, voa e anda mais ou menos. Em cima de uma plataforma de janelas horrível, "Maker" velhão.
> Mas do que tem no mercado dos ruins é o menos pior.
> ...


Para ser sincero?
Accounting de tráfego com atribuição DHCP, apesar de trabalhoso, ainda é possível.
Mas dizer que usar DHCP impede o registro do IP é um absurdo.
Ou o sistema deles que não tem capacidade para tal OU é o técnico deles que não sabe o que está falando...

----------


## eduardomazolini

Accounting que me refiro é usando Radius Accounting.
Mikrotik não tem isso no DHCP é um fato. Da pra fazer com Hotspot do MT como eles disseram.
Da pra fazer de diversas formas? com certeza. Pra um produto do tamanho do deles, garantindo suporte e com alta confiabilidade? .... ai já complica vai ter que encher o MT de configurações e scripts?

Uma coisa é uma solução pra você outra é pra todos. Acho bem razoável a ideia de ativar o Hotspot pra fazer isso. Eu não tinha tido esta idéia.

Nesse tópico quero explorar e desmistificar as piadas que me incomodaram muito de diversos palestrantes dizendo que DHCP é mil maravilhas e quem "é bom usa DHCP".

Como vimos tem consequências praticas que precisa ser bom mesmo pra contornar.
- queue
- accouting
- conformidade com sistema de gestão

Como você faria de forma trabalhosa? Pra sairmos um pouco do hipotético e desenharmos a solução que "os bons fazem".

Até agora aqui participou bem mesmo foi @*TsouzaR* e o @*andrecarlim* que defende o PPPoE na verdade, mas mesmo assim ta aqui pra ver como seria.
Eu uso PPPoE pois não sou "BOM MESMO" mas quem sabe alguém mostra na pratica como fazer com todos os detalhes e lacunas que estão aparecendo.

Me mostrando eu mudo, tenho até um cenário bom pra iniciar e por em produção, um condomínio "popular" onde o roteador que o cliente tiver na casa dele que disca. Tive vários problemas como PPPoE nesses roteadores domésticos. Os roteadores travam, demoram pra rediscar, perdem a configuração. Os rádios ubnt e mikrotik não tem problema com PPPoE. Se um radio reseta não conecta no wireless então não é vantagem.
Não transporto o PPPoE por vários enlaces então não tenho vantagem de ganhar 8 bytes por pacote ou de ter problemas de perda do pacote.

Acho que talvez seja viável na fibra com OLT que tem configurações que nem conheço, pois não uso fibra no meu provedor.

Desculpe mas o que mais vejo é gente dizendo que "tudo da" mas na hora mesmo deixa no vácuo.
Como o pessoal diz "mata a cobra e mostra o pau" pra mim é bobeira. Pau qualquer um pega no meio do mato e diz que matou uma cobra. Quero ver é a cobra morta, sangue da cobra no pau pra saber que foi o pau usado. kkkk

----------


## AndrioPJ

> Accounting que me refiro é usando Radius Accounting.
> Mikrotik não tem isso no DHCP é um fato. Da pra fazer com Hotspot do MT como eles disseram.
> Da pra fazer de diversas formas? com certeza. Pra um produto do tamanho do deles, garantindo suporte e com alta confiabilidade? .... ai já complica vai ter que encher o MT de configurações e scripts?


Quanto ao DHCP...
Por isso disse que o accounting DHCP, seria trabalhoso, mas daria para fazer.

Quanto ao Hotspot...
Nunca testei... o accounting dele funciona legal?
Se funcionar, poderia ser usado o DHCP-Server para atribuir os IPs e o Hotspot apenas para accounting.




> Nesse tópico quero explorar e desmistificar as piadas que me incomodaram muito de diversos palestrantes dizendo que DHCP é mil maravilhas e quem "é bom usa DHCP".
> 
> Como vimos tem consequências praticas que precisa ser bom mesmo pra contornar.
> - queue
> - accouting
> - conformidade com sistema de gestão


Se levar em consideração o overhead do ppoe, perdemos um belo throughput.
Esse é um dos principais motivos de vários palestrantes defenderem o DHCP, bem como muitos grandes provedores pelo mundo usar ele é quanto ao desempenho da rede.

Quanto ao queue, dá para passar o atributo via radius para o dhcp-server mk.
Assim, sempre que o cliente recebe o IP, uma queue é criada.

Já o accounting, esse é complicado, até daria para implementar, mas é trabalhoso.
Uma forma de obter e registrar esses dados seria via algum sistema de monitoramento (zabbix por exemplo).
De qualquer forma, a menos que queira implementar franquia de dados, não vejo esse quesito como um empecilho.

Quanto a conformidade do sistema de gestão, ai sim é complicado.
A maioria não suporta dhcp via radius.
Alias, até hoje desconheço um (nacional) que suporte.

----------


## eduardomazolini

@*AndrioPJ* você usa DHCP?

----------


## andrecarlim

Tá vamo lá, o povo aqui fala demais de overhead em PPPoE, pelo menos sabem o que é isso? Ou qual seria o "belo troughput" que se perde ao usar PPPoE?

Veja bem, normalmente qualquer equipamento de rede deve ser apto a transitar pacotes de até 1500 bytes, sendo que o frame PPPoE gasta 8 bytes para ele, isso representa 0.53%, isso que dizer que a cada 100mb de trânsito que estiver passando na sua rede, teremos 533kb gasto com frames PPPoE. Realmente é um absurdo!

Agora quanto a roteador ruim, aí acho injusto condenar o PPPoE, meus clientes usam, tp-link, trendnet, d-link, airlive (os que ficam mais ao oeste do Paraná e santa Catarina, hehe), ubnt e etc e não passo por esses problemas aí, acho melhor começar a revisar a rede para não levar um tremendo susto ao mudar para DHCP e ver que a "vaca foi pro brejo de vez", aí quando a rede estiver boa, ninguém mais vai reclamar do PPPoE!

----------


## eduardomazolini

A distância do PTP da base (caixa de água) até os prédios não da 50mts. Na mesma base tenho outros painéis com 140 clientes. Só reclamam os que usam roteador, tanto que agora estou dando um hAP prós clientes. Aí não tive problema com PPPoE no hAP.
Eu também achei o discurso do outro colega, neste ponto do tópico, justamente o que estamos dizendo sempre lendo e ninguém mostra, não adicionou nada que já não foi dito e esclarecido aqui mesmo e ainda dito que é o que não precisamos ouvir.

----------


## eduardomazolini

> Hoje eu li o tópico inteiro novamente, analisando bem cada postagem e ainda não consegui encontrar tantas vantagens no DHCP, principalmente pelo fato de dificuldade de integração com nosso sistema de gestão.
> 
> Contando que a nossa rede aqui é boa, não temos nenhum problema, acredito que o tal aclamado "overhead" do PPPoE não seja prejudicial, até porquê não usamos tunelamento para centralizar autenticação, cada POP tem seu concentrador PPPoE, então não vejo problemas. A minha intensão é sim centralizar a autenticação PPPoE até o MX104, mas ainda não entrei nessa onda de usar VPLS ou EoIP, VLAN aqui tá me satisfazendo muito bem em alguns pontos.


E a mesma situação minha. Exatamente!
Mas tô aqui na esperança do povo que usa e fala tanto dívida o grande pulo do gato. Alguém que defenda que realmente use, e não fala por falar.

Falando um pouco de bobeira esse pessoal me lembra:
- um filho de professora de história que defendia comunismo e queria ir pra Disney.
- O rei pelado que usava roupa tão especial que só poucos viam.

----------


## andrecarlim

Tá virando nostalgia ler isso, haha! Me lembra até um conhecido mais velho, que fuma 2 maços de cigarro por dia e bebe até espumar pela boca, dizendo: "André, faça o que eu digo, não o que faço".

----------


## AndrioPJ

> @*AndrioPJ* você usa DHCP?


Dependendo do local, sim.
No provedor, ainda não, devido a falta de um Gerenciador de Provedor com suporte a DHCP via radius, etc e tal.




> Tá vamo lá, o povo aqui fala demais de overhead em PPPoE, pelo menos sabem o que é isso? Ou qual seria o "belo troughput" que se perde ao usar PPPoE?
> 
> Veja bem, normalmente qualquer equipamento de rede deve ser apto a transitar pacotes de até 1500 bytes, sendo que o frame PPPoE gasta 8 bytes para ele, isso representa 0.53%, isso que dizer que a cada 100mb de trânsito que estiver passando na sua rede, teremos 533kb gasto com frames PPPoE. Realmente é um absurdo!


Que bom seria se fosse apenas os 8 bytes, mas infelizmente, 90% dos ppoe server são configurados com um MTU bem menor, no final, um cliente que poderia estar funcionando com com até 1472 de mtu, está funcionando com 1452, 1440 ou até mesmo 1412.

Isso acaba gerando uma fragmentação maior dos pacotes, somado ao encapsulamento e desencapsulamento do tunel ppoe, acaba elevando o uso do processador, consequentemente diminuindo a quantidade de clientes que um Servidor poderia atender.

PS: vale salientar que eu apenas expus alguns dos motivos do pq alguns palestrantes indicar o uso do DHCP, bem como grandes provedores no mundo usar o DHCP.
Em nenhum momento disse que você deve "obrigatoriamente" usar DHCP, cabe a cada um analisar seus prós e contras.

----------


## andrecarlim

> Que bom seria se fosse apenas os 8 bytes, mas infelizmente, 90% dos ppoe server são configurados com um MTU bem menor, no final, um cliente que poderia estar funcionando com com até 1472 de mtu, está funcionando com 1452, 1440 ou até mesmo 1412.


Agora uma coisa me chamou a atenção, porque alguns provedores acabam usando a mtu menor? Tirando o fato de terem configurado sem saber, algum motivo real para isso? Tirando o fato de estarem usando EoIP e etc...

Adendo: não vamos voltar ao meio da discussão, não se pode condenar um protocolo por burrice de configuração, além de ser injusto é bem idiota e amador! Porque os mesmos caras que erram na hora de configurar o PPPoE podem mudar o MTU da interface, ou não?

----------


## AndrioPJ

> Agora uma coisa me chamou a atenção, porque alguns provedores acabam usando a mtu menor? Tirando o fato de terem configurado sem saber, algum motivo real para isso? Tirando o fato de estarem usando EoIP e etc...
> 
> Adendo: não vamos voltar ao meio da discussão, não se pode condenar um protocolo por burrice de configuração, além de ser injusto é bem idiota e amador! Porque os mesmos caras que erram na hora de configurar o PPPoE podem mudar o MTU da interface, ou não?


No mikrotik, por padrão, ao criarmos um ppoe server, ele já começa com o MTU em 1480, quando esse valor poderia estar em até 1492.
Acredito que por padrão ele vem assim devido a "maior compatibilidade" dos equipamentos clientes.
Por experiencia e apenas como exemplo do pq eu acho ele vem assim por padrão...: Já cheguei a configurar ppoe server com MTU 1492, mas alguns roteadores simplesmente não funcionavam a contento.
Já com MTU em 1480 no ppoe server a compatibilidade era maior.

Também já vi casos onde o próprio Mikrotik criou a regra de Change MSS com valor em 1412.

----------


## eduardomazolini

> No mikrotik, por padrão, ao criarmos um ppoe server, ele já começa com o MTU em 1480, quando esse valor poderia estar em até 1492.
> Acredito que por padrão ele vem assim devido a "maior compatibilidade" dos equipamentos clientes.
> Por experiencia e apenas como exemplo do pq eu acho ele vem assim por padrão...: Já cheguei a configurar ppoe server com MTU 1492, mas alguns roteadores simplesmente não funcionavam a contento.
> Já com MTU em 1480 no ppoe server a compatibilidade era maior.
> 
> Também já vi casos onde o próprio Mikrotik criou a regra de Change MSS com valor em 1412.


Você já olhou o MTU do wireless? Dá até pra ser 1500.

----------


## TsouzaR

> Eu como usuário de Mikrotik penso em duas coisas diferentes juntas
> - autenticação
> - limite de velocidade
> 
> Se é usado DHCP relay o switch não faz o controle de banda pois pra isso precisa do radius.
> 
> Pode ter um switch que recebe o relay e esse ter radius. Se ele ficar no meio do caminho pode ser que a banda seja atribuída nele, mesmo a entrega tendo sido feita na ponta por um DHCP relay.
> 
> Como vocês que usam DHCP Relay, como e onde fazem o controle de banda?


Realmente, a função do switch nessa parte seria apenas atuar como relay e eu tinha me esquecido de que relay não recebe os parâmetros da resposta do Radius para poder criar limite de banda ou qualquer outra coisa. O servidor DHCP tem que estar em outro equipamento por onde o tráfego vai passar, geralmente o roteador (RB...) do PoP ou um "concentrador". Poderia ser até em outro switch gerenciável com servidor DHCP e cliente Radius com os parâmetros adequados...

Um método que provavelmente possibilita fazer o controle de banda no relay, quer seja um switch ou qualquer outro equipamento, é usar o módulo "exec" do FreeRADIUS para executar um script assim que é feito login ou logout, sendo que esse script faria o acesso por SSH, Telnet, API ou qualquer outro método ao equipamento do relay e adicionaria/removeria lá a fila e quaisquer outras coisas. A vantagem é que vai dar para fazer controle de banda no equipamento do relay mesmo que ele não suporte Radius ou não tenha parâmetro para isso.

----------


## eduardomazolini

Então mas alguém aqui na lista defendeu o DHCP deve usar e pelo que entendi sempre falando dos parâmetros do Relay. Não lembro quem foi.
Como alguém que já usa esta usando?

@TsousaR obrigado pela resposta a questão do exec, vou pesquisar pois como disse uso concentradores separados.
Eu queria criar as regras em um roteador perto de borda pra poder gerenciar melhor a banda. Vou usar o exec pra fazer isso no roteador que não participa diretamente do login.

----------


## eduardomazolini

Morreu o tópico, todo mundo ficou quieto. Como vocês do DHCP que fizeram posts a favor fazem o controle de banda? Vou chamar o pessoal que defendeu DHCP aqui pelo nome pra pedir ajuda.

----------


## eduardomazolini

@*andrecarlim* vi em algum lugar você falando do accer-pppoe algo assim. Um dia dei uma procurada é um software livre de PPPoE gostei da ideia.
Como você faz o controle de banda? Como costuma ser sua estrutura?

Eu acho Mikrotik legal em:
- pcq
- burst
- preço
- facilidade de usar firewall netfiler (comandos iptables)
- preguiçoso que sou, tá tudo junto, não é por que faz tudo que tem que fazer tudo na mesma caixa.

----------


## andrecarlim

> @*andrecarlim* vi em algum lugar você falando do accer-pppoe algo assim. Um dia dei uma procurada é um software livre de PPPoE gostei da ideia.
> Como você faz o controle de banda? Como costuma ser sua estrutura?
> 
> Eu acho Mikrotik legal em:
> - pcq
> - burst
> - preço
> - facilidade de usar firewall netfiler (comandos iptables)
> - preguiçoso que sou, tá tudo junto, não é por que faz tudo que tem que fazer tudo na mesma caixa.


Já uso accel em meus clientes a mais de um ano, está bem "sólido" o funcionamento.

O accel-ppp já tem módulo de shaper "built-in", não que ele controle a banda, mas ele aplica as queues lá no kernel através do TC (que eu usava antes com scripts). Mesmo assim eu queria um Burst semelhante ao do mikrotik, eu fiz isso no ip-up do accel-ppp. Quanto a preço, qualquer Core i3 com placa mãe Asus e 4gb de ram atende tranquilamente 2000 sessões PPPoE, claro, isso não depende somente do accel, mas de um ajuste fino do kernel, o único custo mais elevado ao se usar accel-ppp é com boas placa de rede, falo isso porque essas placas comuns não tem o maravilhoso recurso de multi-queue, e esse recurso ajuda muito quando se passa dos 300mbps, na verdade é indispensável.

Sobre facilidade de uso, com Linux a gente sofre um pouco, mas a satisfação/tranquilidade é incalculável depois de pronto!

----------


## deson00

Uma coisa é uma coisa outra coisa é outra coisa.
Se vc quer ter login e senha vai de pppoe se não quer vai de dhcp.
Poco importa o protocolo ou tecnologia, q importa é o q vc quer fazer ai basta implantar as seguranças necessárias.
Se lhe atender satisfatoriamente bola pra frente.
Tem coisas não suportadas ao pppoe como central Alcatel.
Já tive um caso q na rede atendia vários pontos públicos e usava central Alcatel q não tem suporte a pppoe ai só DHCP, ou seja depende de cada caso.

----------


## eduardomazolini

@*deson00*,

E quais as seguranças necessárias? Como você faz?

Hoje entrei em contato com a MKSOLUTIONS pra ajudar meu cenário, explicar o que eu iria fazer.

"""
No início no chat foi meio difícil, mas depois um cara bom me atendeu deu atenção e procurou entender o que eu queria, 1vez que vou elogiar a Mksolutions. Eu sempre digo que eles são uns patos, nada, voa e anda mais ou menos. Em cima de uma plataforma de janelas horrível, "Maker" velhão.
Mas do que tem no mercado dos ruins é o menos pior.
Também tem coragem de assumir o suporte do radius, um outro produto queria que eu montassem o radius eles indicavam um consultor pra configurar o radius que não seria de responsabilidade deles.
"""

Eles me alertaram sobre a falta de accouting que impede registro do IP usado pelo cliente.
Também impede guardar o consumo de dados do cliente, exibir a velocidade de consumo atual(no sistema deles), na RB não vai ter interface vai ter que olhar direito na queue.

O usuário e senha vou ter no caso do wireless com WPA-EAP

Lógico que toda solução depende dos hardwares e softwares envolvidos.
Eu apesar de adorar software livre não sei se posso usar accell-ppp com Mksolutions, vou estudar.
VyOS me parece maravilhoso e agora uma versão acessível nos roteadores da Ubiquiti, vou estudar também.

Agora pra quem está iniciando fazer uma arquitetura certa ajuda muito.

A MKSolutions me deu a dica de usar Hotspot por autenticação de Mac. Não é o DHCP puro mas é sem o protocolo PPPoE seja a vantagem que isso for realmente.

----------


## andrecarlim

> Eu apesar de adorar software livre não sei se posso usar accell-ppp com Mksolutions, vou estudar.


Cara tenho alguns clientes que quando comecei a atender já usavam o mk-solutions, aí eu coloquei o dicionário do Mikrotik pra rodar no accel, ativei o script no ip-up de cada conexão PPPoE, acertei os atributos, e voilá, temos o controle de banda!

Também tratei de cuidar daqueles que estão bloqueados, pelo atributo de address-list que o mk-solutions envia, e configurei uma interface web no servidor que roda o accel, para poder desconectar usuário, ver a banda em tempo real e etc.

Contudo tenho um cliente que conhece um dos proprietários dá mk-solutions que fez uma pressão lá e parece que estão trabalhando para suportar "nativamente" o accel, já até passei a listagem de comandos para poderem administrar as sessões PPPoE diretamente pelo suporte do mk-solutions, espero ansiosamente que façam isso!

Enfim, com um pouco de imaginação e criatividade as possibilidades com o accel-ppp são bem abrangentes!

----------


## AndrioPJ

> Morreu o tópico, todo mundo ficou quieto. Como vocês do DHCP que fizeram posts a favor fazem o controle de banda? Vou chamar o pessoal que defendeu DHCP aqui pelo nome pra pedir ajuda.


Da para fazer normalmente, o mk suporta isso.
Para fazer manualmente, abra o DHCP-Server > Leases
Crie um cadastro ali, em RATE LIMIT coloque a velocidade que vc quer que o cliente tenha.
Ai sempre que o cliente receber um IP, o controle de banda será criado automatiamente.

Ou use Radius para passar essas informações.




> @*deson00*,
> 
> E quais as seguranças necessárias? Como você faz?
> 
> Hoje entrei em contato com a MKSOLUTIONS pra ajudar meu cenário, explicar o que eu iria fazer.
> 
> """
> No início no chat foi meio difícil, mas depois um cara bom me atendeu deu atenção e procurou entender o que eu queria, 1vez que vou elogiar a Mksolutions. Eu sempre digo que eles são uns patos, nada, voa e anda mais ou menos. Em cima de uma plataforma de janelas horrível, "Maker" velhão.
> Mas do que tem no mercado dos ruins é o menos pior.
> ...


Para ser sincero?
Accounting de tráfego com atribuição DHCP, apesar de trabalhoso, ainda é possível.
Mas dizer que usar DHCP impede o registro do IP é um absurdo.
Ou o sistema deles que não tem capacidade para tal OU é o técnico deles que não sabe o que está falando...

----------


## eduardomazolini

Accounting que me refiro é usando Radius Accounting.
Mikrotik não tem isso no DHCP é um fato. Da pra fazer com Hotspot do MT como eles disseram.
Da pra fazer de diversas formas? com certeza. Pra um produto do tamanho do deles, garantindo suporte e com alta confiabilidade? .... ai já complica vai ter que encher o MT de configurações e scripts?

Uma coisa é uma solução pra você outra é pra todos. Acho bem razoável a ideia de ativar o Hotspot pra fazer isso. Eu não tinha tido esta idéia.

Nesse tópico quero explorar e desmistificar as piadas que me incomodaram muito de diversos palestrantes dizendo que DHCP é mil maravilhas e quem "é bom usa DHCP".

Como vimos tem consequências praticas que precisa ser bom mesmo pra contornar.
- queue
- accouting
- conformidade com sistema de gestão

Como você faria de forma trabalhosa? Pra sairmos um pouco do hipotético e desenharmos a solução que "os bons fazem".

Até agora aqui participou bem mesmo foi @*TsouzaR* e o @*andrecarlim* que defende o PPPoE na verdade, mas mesmo assim ta aqui pra ver como seria.
Eu uso PPPoE pois não sou "BOM MESMO" mas quem sabe alguém mostra na pratica como fazer com todos os detalhes e lacunas que estão aparecendo.

Me mostrando eu mudo, tenho até um cenário bom pra iniciar e por em produção, um condomínio "popular" onde o roteador que o cliente tiver na casa dele que disca. Tive vários problemas como PPPoE nesses roteadores domésticos. Os roteadores travam, demoram pra rediscar, perdem a configuração. Os rádios ubnt e mikrotik não tem problema com PPPoE. Se um radio reseta não conecta no wireless então não é vantagem.
Não transporto o PPPoE por vários enlaces então não tenho vantagem de ganhar 8 bytes por pacote ou de ter problemas de perda do pacote.

Acho que talvez seja viável na fibra com OLT que tem configurações que nem conheço, pois não uso fibra no meu provedor.

Desculpe mas o que mais vejo é gente dizendo que "tudo da" mas na hora mesmo deixa no vácuo.
Como o pessoal diz "mata a cobra e mostra o pau" pra mim é bobeira. Pau qualquer um pega no meio do mato e diz que matou uma cobra. Quero ver é a cobra morta, sangue da cobra no pau pra saber que foi o pau usado. kkkk

----------


## AndrioPJ

> Accounting que me refiro é usando Radius Accounting.
> Mikrotik não tem isso no DHCP é um fato. Da pra fazer com Hotspot do MT como eles disseram.
> Da pra fazer de diversas formas? com certeza. Pra um produto do tamanho do deles, garantindo suporte e com alta confiabilidade? .... ai já complica vai ter que encher o MT de configurações e scripts?


Quanto ao DHCP...
Por isso disse que o accounting DHCP, seria trabalhoso, mas daria para fazer.

Quanto ao Hotspot...
Nunca testei... o accounting dele funciona legal?
Se funcionar, poderia ser usado o DHCP-Server para atribuir os IPs e o Hotspot apenas para accounting.




> Nesse tópico quero explorar e desmistificar as piadas que me incomodaram muito de diversos palestrantes dizendo que DHCP é mil maravilhas e quem "é bom usa DHCP".
> 
> Como vimos tem consequências praticas que precisa ser bom mesmo pra contornar.
> - queue
> - accouting
> - conformidade com sistema de gestão


Se levar em consideração o overhead do ppoe, perdemos um belo throughput.
Esse é um dos principais motivos de vários palestrantes defenderem o DHCP, bem como muitos grandes provedores pelo mundo usar ele é quanto ao desempenho da rede.

Quanto ao queue, dá para passar o atributo via radius para o dhcp-server mk.
Assim, sempre que o cliente recebe o IP, uma queue é criada.

Já o accounting, esse é complicado, até daria para implementar, mas é trabalhoso.
Uma forma de obter e registrar esses dados seria via algum sistema de monitoramento (zabbix por exemplo).
De qualquer forma, a menos que queira implementar franquia de dados, não vejo esse quesito como um empecilho.

Quanto a conformidade do sistema de gestão, ai sim é complicado.
A maioria não suporta dhcp via radius.
Alias, até hoje desconheço um (nacional) que suporte.

----------


## eduardomazolini

@*AndrioPJ* você usa DHCP?

----------


## andrecarlim

Tá vamo lá, o povo aqui fala demais de overhead em PPPoE, pelo menos sabem o que é isso? Ou qual seria o "belo troughput" que se perde ao usar PPPoE?

Veja bem, normalmente qualquer equipamento de rede deve ser apto a transitar pacotes de até 1500 bytes, sendo que o frame PPPoE gasta 8 bytes para ele, isso representa 0.53%, isso que dizer que a cada 100mb de trânsito que estiver passando na sua rede, teremos 533kb gasto com frames PPPoE. Realmente é um absurdo!

Agora quanto a roteador ruim, aí acho injusto condenar o PPPoE, meus clientes usam, tp-link, trendnet, d-link, airlive (os que ficam mais ao oeste do Paraná e santa Catarina, hehe), ubnt e etc e não passo por esses problemas aí, acho melhor começar a revisar a rede para não levar um tremendo susto ao mudar para DHCP e ver que a "vaca foi pro brejo de vez", aí quando a rede estiver boa, ninguém mais vai reclamar do PPPoE!

----------


## eduardomazolini

A distância do PTP da base (caixa de água) até os prédios não da 50mts. Na mesma base tenho outros painéis com 140 clientes. Só reclamam os que usam roteador, tanto que agora estou dando um hAP prós clientes. Aí não tive problema com PPPoE no hAP.
Eu também achei o discurso do outro colega, neste ponto do tópico, justamente o que estamos dizendo sempre lendo e ninguém mostra, não adicionou nada que já não foi dito e esclarecido aqui mesmo e ainda dito que é o que não precisamos ouvir.

----------


## eduardomazolini

> Hoje eu li o tópico inteiro novamente, analisando bem cada postagem e ainda não consegui encontrar tantas vantagens no DHCP, principalmente pelo fato de dificuldade de integração com nosso sistema de gestão.
> 
> Contando que a nossa rede aqui é boa, não temos nenhum problema, acredito que o tal aclamado "overhead" do PPPoE não seja prejudicial, até porquê não usamos tunelamento para centralizar autenticação, cada POP tem seu concentrador PPPoE, então não vejo problemas. A minha intensão é sim centralizar a autenticação PPPoE até o MX104, mas ainda não entrei nessa onda de usar VPLS ou EoIP, VLAN aqui tá me satisfazendo muito bem em alguns pontos.


E a mesma situação minha. Exatamente!
Mas tô aqui na esperança do povo que usa e fala tanto dívida o grande pulo do gato. Alguém que defenda que realmente use, e não fala por falar.

Falando um pouco de bobeira esse pessoal me lembra:
- um filho de professora de história que defendia comunismo e queria ir pra Disney.
- O rei pelado que usava roupa tão especial que só poucos viam.

----------


## andrecarlim

Tá virando nostalgia ler isso, haha! Me lembra até um conhecido mais velho, que fuma 2 maços de cigarro por dia e bebe até espumar pela boca, dizendo: "André, faça o que eu digo, não o que faço".

----------


## AndrioPJ

> @*AndrioPJ* você usa DHCP?


Dependendo do local, sim.
No provedor, ainda não, devido a falta de um Gerenciador de Provedor com suporte a DHCP via radius, etc e tal.




> Tá vamo lá, o povo aqui fala demais de overhead em PPPoE, pelo menos sabem o que é isso? Ou qual seria o "belo troughput" que se perde ao usar PPPoE?
> 
> Veja bem, normalmente qualquer equipamento de rede deve ser apto a transitar pacotes de até 1500 bytes, sendo que o frame PPPoE gasta 8 bytes para ele, isso representa 0.53%, isso que dizer que a cada 100mb de trânsito que estiver passando na sua rede, teremos 533kb gasto com frames PPPoE. Realmente é um absurdo!


Que bom seria se fosse apenas os 8 bytes, mas infelizmente, 90% dos ppoe server são configurados com um MTU bem menor, no final, um cliente que poderia estar funcionando com com até 1472 de mtu, está funcionando com 1452, 1440 ou até mesmo 1412.

Isso acaba gerando uma fragmentação maior dos pacotes, somado ao encapsulamento e desencapsulamento do tunel ppoe, acaba elevando o uso do processador, consequentemente diminuindo a quantidade de clientes que um Servidor poderia atender.

PS: vale salientar que eu apenas expus alguns dos motivos do pq alguns palestrantes indicar o uso do DHCP, bem como grandes provedores no mundo usar o DHCP.
Em nenhum momento disse que você deve "obrigatoriamente" usar DHCP, cabe a cada um analisar seus prós e contras.

----------


## andrecarlim

> Que bom seria se fosse apenas os 8 bytes, mas infelizmente, 90% dos ppoe server são configurados com um MTU bem menor, no final, um cliente que poderia estar funcionando com com até 1472 de mtu, está funcionando com 1452, 1440 ou até mesmo 1412.


Agora uma coisa me chamou a atenção, porque alguns provedores acabam usando a mtu menor? Tirando o fato de terem configurado sem saber, algum motivo real para isso? Tirando o fato de estarem usando EoIP e etc...

Adendo: não vamos voltar ao meio da discussão, não se pode condenar um protocolo por burrice de configuração, além de ser injusto é bem idiota e amador! Porque os mesmos caras que erram na hora de configurar o PPPoE podem mudar o MTU da interface, ou não?

----------


## AndrioPJ

> Agora uma coisa me chamou a atenção, porque alguns provedores acabam usando a mtu menor? Tirando o fato de terem configurado sem saber, algum motivo real para isso? Tirando o fato de estarem usando EoIP e etc...
> 
> Adendo: não vamos voltar ao meio da discussão, não se pode condenar um protocolo por burrice de configuração, além de ser injusto é bem idiota e amador! Porque os mesmos caras que erram na hora de configurar o PPPoE podem mudar o MTU da interface, ou não?


No mikrotik, por padrão, ao criarmos um ppoe server, ele já começa com o MTU em 1480, quando esse valor poderia estar em até 1492.
Acredito que por padrão ele vem assim devido a "maior compatibilidade" dos equipamentos clientes.
Por experiencia e apenas como exemplo do pq eu acho ele vem assim por padrão...: Já cheguei a configurar ppoe server com MTU 1492, mas alguns roteadores simplesmente não funcionavam a contento.
Já com MTU em 1480 no ppoe server a compatibilidade era maior.

Também já vi casos onde o próprio Mikrotik criou a regra de Change MSS com valor em 1412.

----------


## eduardomazolini

> No mikrotik, por padrão, ao criarmos um ppoe server, ele já começa com o MTU em 1480, quando esse valor poderia estar em até 1492.
> Acredito que por padrão ele vem assim devido a "maior compatibilidade" dos equipamentos clientes.
> Por experiencia e apenas como exemplo do pq eu acho ele vem assim por padrão...: Já cheguei a configurar ppoe server com MTU 1492, mas alguns roteadores simplesmente não funcionavam a contento.
> Já com MTU em 1480 no ppoe server a compatibilidade era maior.
> 
> Também já vi casos onde o próprio Mikrotik criou a regra de Change MSS com valor em 1412.


Você já olhou o MTU do wireless? Dá até pra ser 1500.

----------

