#  > Telecomunicações >  > Mikrotik >  >  PPPOE Mikrotik deslogando pessoas aleatoriamente

## edmilson2709

Olá pessoal, aqui estou eu de novo, procurando uma solução para esse bendito problema que o titula cita, por que bulhufas o PPPOE desconecta pessoas de forma aleatoria? Ja estou com dor de cabeça aqui, clientes à 2 km, de outro bairro, caem, e junto deles alguns à 1 km cai, no mesmo bairro que moro. Alguns ficam logados com internet, creio eu. Quando utilizava HOTSPOT isso nunca tinha acontecido, pessoas ligadas diretamente na central em cabeamentos separados caem também, possuo uma rede separada da principal ligada direto na minha ROUTERBOARD e ela se mantem normal, pessoas no wifi caem, no cabo caem, agora, pessoas após ou atras dessas continuam. Irei mandar um print do ultimo que aconteceu agora a pouco:


Alguns conectados à 4 dias enquanto outros cairam faz 1 hora, por exemplo, Marcilene, na primeira imagem está conectada à 4 dias, na segunda imagem, Alexsimone, que fica antes dela caiu faz 1 hora. Isso chega à ser, me desculpem a expressão, estupido!

Ja cortei a rede ao meio e coloquei um PTP para a outra torre para ver se resolvia, na 1009, ao colocar o PTP, o problema persistiu, quando coloquei ele separado na minha outra RB (1100 AHX2) o problema sumiu, porém eu ja usava o PPPOE nela e o problema ja existia, já comprei a 1009 pensando que seria a 1100, porém não é, ja refiz configurações e tudo mais. Só falta agora eu infartar!

A topologia está assim, RB1009, sobe um cabo e entra num switch GIGA, que repassa para os clientes na rede. Ai o que vocês podem dizer que seja: "a rapaz, se tem 200 pessoas num cabo e não quer ter problemas?" R: Então me explique como no PTP que é um cabo só para isso também tem este problema? Sinal? Já chequei, está perfeito. Configurações? Já refiz tudo e sem sucesso.

Passou um tempo sem isto acontecer, acho que coisa de 5 dias, até pensei que tinha resolvido, mas quem disse? Só vi o pessoal do nada caindo.

Utilizo switchs VLAN, rede em bridge, já refiz cabeamentos, verifiquei a rede que leva até os clientes, já verifiquei sinal ...

Sugestões? Alguém já passou por isso? Me ajudem por que estou perdido aqui já. Só mudei para esse bendito PPPOE por que no HOTSPOT sofria muito com clientes colocando o famigerado cabinho na porta LAN, e botando DHCP pra rodar na rede, deixando alguns sem internet.  :Banghead:

----------


## andrecarlim

Aparece algo no log? Algo do tipo "peer is not responding"? Se usa radius, no radacct, caso seja freeradius, deve aparecer o motivo da desconexão.

Assim eu tenho tenho partido para accel-ppp em estruturas maiores, não sei se é o seu caso, mas uma coisa posso garantir, é paz! É muito robusto e escalonável se bem configurado, eu tenho contato direto com os russos que desenvolvem o projeto, tenho colaborado com várias idéias e o último commit ficou perfeito, eles acataram minhas idéias e integraram com parâmetros que podem ser ligados e desligados, ficou muito bom, estou usando em mais de 10 provedores que atendo e não tenho problema!

Enviado via XT1563 usando UnderLinux App

----------


## edmilson2709

Sim, aparece exatamente isto, "peer is not responding" e logo em seguida "terminating", demora 2 minutos e volta ao normal o cliente. Não utilizo RADIUS ... Só o PPPOE.

Isso é muito estranho pois acontece de forma totalmente aleatoria, não tem hora, não tem dia, simplesmente cai e volta depois de um tempo, as vezes demora, outras vezes não, hoje mesmo caiu 2 vezes em um curto periodo de tempo, cerca de 2 quedas em 30 minutos.

----------


## JonasMT

> Aparece algo no log? Algo do tipo "peer is not responding"? Se usa radius, no radacct, caso seja freeradius, deve aparecer o motivo da desconexão.
> 
> Assim eu tenho tenho partido para accel-ppp em estruturas maiores, não sei se é o seu caso, mas uma coisa posso garantir, é paz! É muito robusto e escalonável se bem configurado, eu tenho contato direto com os russos que desenvolvem o projeto, tenho colaborado com várias idéias e o último commit ficou perfeito, eles acataram minhas idéias e integraram com parâmetros que podem ser ligados e desligados, ficou muito bom, estou usando em mais de 10 provedores que atendo e não tenho problema!
> 
> Enviado via XT1563 usando UnderLinux App


Show hem, tenho o mesmo problema aqui. E ocorre principalmente quando usado ccr, to pra migrar pra um server.u

----------


## andrecarlim

Jonas, se precisar de ajuda para colocar em produção um accel-ppp avise, eu não gosto de software proprietário, quero deixar isso claro! Vou além, eu tenho clientes que tem conexão no ptt-sp e mais de 4k sessões pppoe simultâneas, e a estrutura desde tratamento de link até autenticação é feito com software livre, sou fã de Debian desde que me lembro, nunca saí do padrão do Debian, apenas conheço bem o sistema e sei usar, hoje para autenticar isso eu uso uma estrutura usando MySQL + freeradius + Debian, e detalhe, o pool de ip válidos fica no radius, os servidores Debian + accel-ppp são totalmente passivos! É o que posso dizer é que nunca fiquei na mão por causa do sistema operacional, as vezes a gente encontra problemas, mas resolvo com facilidade e até hoje nunca me arrependi de usar essa estrutura.

Enviado via XT1563 usando UnderLinux App

----------


## andrecarlim

Explique melhor a sua estrutura.

Enviado via XT1563 usando UnderLinux App

----------


## andfonsek

Acompanhando

----------


## Danusio

então usando o accel-ppp, não precisaria do Mikrotik?

----------


## ronei10

Qual versão vc usa?

----------


## ronei10

Existe relatos desse problema na versão 6.35

----------


## 1929

> Jonas, eu estou perdendo a fé no RouterOS para servidor PPPoE. Já colocamos em pauta Juniper ou Cisco como concentrador, mas por conta dos valores altos demais, estou pensando em correr pra outra alternativa, até lá suportando o RouterOS. 
> 
> 
> Sent from my iPhone.


Aleluia.... eu penso isso faz muito tempo. Mas como não sou entendido em MK só posso expressar opinião leiga... No entanto é isso que se vê. Cada alteração em uma linha de programação do RouterOS não se sabe o que vai acontecer lá na frente.
Eu desisti do pppoe exatamente por causa destas desconexões. E não é com a versão, pois acontece aleatoriamente em qualquer das versões que já usamos.
Muitos me indicaram praticamente de tudo, mas nada resolveu. Até paguei para pessoa entendida fazer o pppoe. Sem resultados.
Então , para mim fica opinião de leigo, mas também de observador... "não é estável"

----------


## egservice

Bom dia pessoal! alguém usando ubiquiti como concentrador pppoe?

----------


## ronei10

@*1929* o que vc usa pra fazer autenticação?

----------


## 1929

> @*1929* o que vc usa pra fazer autenticação?


Aqui, desde 2008 é utilizado o hotspot. Tentei o pppoe mas acontecia a mesma coisa. Desconecta e volta. E isso de forma aleatória. E a mensagem que vinha era esta mesma que citaram. Daí desativamos o pppoe.

Logo que começamos a mudar achei que seria uma excelente opção pois eliminava a questão do login e senha de uma forma bem simples. Deixava gravado na CPE. 

Estamos para mudar para o MKSolutions e daí parece que vai ser por pppoe novamente. Como não sou mais o dono, não sei sobre estes detalhes ainda... Na matriz já foi mudado.

Sei lá, se sou apegado as coisas... mas pelo tempo que estamos com hotspot eu não posso me queixar dele... mas sei que tem muita gente que não gosta... alguns por causa de um broadcasting que ele gera na rede. Isso poderia ser controlado se faz autenticação em cada AP e não centralizado.
Outros não gostam porque não usaram e por aí vai.

----------


## joceliomarques

Cara tem que ver o MTU e o keepalive Timeout e tbm se o cliente estiver com sinal ruim fica só desconectando, meus problemas eram só estes.

----------


## ronei10

Hotspot tem suas vantagens, uma delas eh tela de aviso que sinto falta.
Mas pra usar em roteador e celular ter que fazer login eh horrível. Entao so resta pppoe. Sem falar nos roteadores fa tp- link e intelbras que ficam saindo de pppoe direto.

----------


## joceliomarques

Tp link não tenho experiencia mas intelbras cai direto mesmo.

----------


## ronei10

Pois eh. O da tp- link eh o modelo 740n

----------


## andrecarlim

> então usando o accel-ppp, não precisaria do Mikrotik?


Correto. Para usar o accel-ppp tem que instalar em um servidor com Linux. Tem uma galera usando Ubuntu instalado em Dell r210 e diz que fica perfeito, eu acredito. Contudo uso servidores HP de todo tipo, instalado com Debian e pra mim é uma experiência inigualável! Recentemente comecei a usar placas de rede Intel I350-T4, e elas impressionam pela estabilidade e confiabilidade!

Enviado via XT1563 usando UnderLinux App

----------


## 1929

> Cara tem que ver o MTU e o keepalive Timeout e tbm se o cliente estiver com sinal ruim fica só desconectando, meus problemas eram só estes.


Tentamos tudo isso. Cliente de cara para torre com 100% de sinal e 100% de CCQ.
Aparece de forma aleatória.




> Hotspot tem suas vantagens, uma delas eh tela de aviso que sinto falta.
> Mas pra usar em roteador e celular ter que fazer login eh horrível. Entao so resta pppoe. Sem falar nos roteadores fa tp- link e intelbras que ficam saindo de pppoe direto.


Daí complica. É que aqui não deixamos o cliente conectar direto com smartphone na rede. CPE roteada no cliente e daí ele conecta com os dispositivos pelo roteador dele.

----------


## JonasMT

> Jonas, se precisar de ajuda para colocar em produção um accel-ppp avise, eu não gosto de software proprietário, quero deixar isso claro! Vou além, eu tenho clientes que tem conexão no ptt-sp e mais de 4k sessões pppoe simultâneas, e a estrutura desde tratamento de link até autenticação é feito com software livre, sou fã de Debian desde que me lembro, nunca saí do padrão do Debian, apenas conheço bem o sistema e sei usar, hoje para autenticar isso eu uso uma estrutura usando MySQL + freeradius + Debian, e detalhe, o pool de ip válidos fica no radius, os servidores Debian + accel-ppp são totalmente passivos! É o que posso dizer é que nunca fiquei na mão por causa do sistema operacional, as vezes a gente encontra problemas, mas resolvo com facilidade e até hoje nunca me arrependi de usar essa estrutura.
> 
> Enviado via XT1563 usando UnderLinux App


Opa vamos conversar quero sim, nao aguento mais essa dor de cabeça! E a cada versao piora

----------


## gigahertzinformatica

Logo quando comecei a usar mikrotik pppoe tive problemas na wireless pois não usava wds ativo no ap e cli por isso sugiro que faça isso ative em todos os rádios envolvidos o wds, tenho certeza que seu problema pode ser resolvido pois deve ser algo peculiar em sua rede.
Imagina que no Brasil a maioria de provedores que começa suas atividades, começam usando mikrotik com autenticações pppoe em conjunto com radius, em redes mistas como cabo, wifi, fibra.
Aqui por exemplo na minha pequena rede com cerca de 350 clientes sendo 280 simultâneos, faço uso do servidor x86 mikrotik e atendo esta rede que é mista wireless e cabo com roteamentos ospf/mpls/vpls e vlan.

Observe neste print, tem cerca de 280 conectados pppoe, a maioria quase 5 dias, Pois fiz uma atualização e reiniciei o mikrotik com planos entre 3, 4, 5, 6mb. Processamento 14% + ou - .
Então acho que este sistema merece credibilidade sim, pois existem provedores com cerca de 2500 e até mais clientes pppoe simultâneos em redes mistas.

----------


## sgnetararuama

> Pois eh. O da tp- link eh o modelo 740n


TP-Link 740n, V4 e V5 com DDW-RT nao tenho este problema, tenho cliente que fica ate 15 dias conectado direto

----------


## ronei10

Vou testar

----------


## JonasMT

> Logo quando comecei a usar mikrotik pppoe tive problemas na wireless pois não usava wds ativo no ap e cli por isso sugiro que faça isso ative em todos os rádios envolvidos o wds, tenho certeza que seu problema pode ser resolvido pois deve ser algo peculiar em sua rede.
> Imagina que no Brasil a maioria de provedores que começa suas atividades, começam usando mikrotik com autenticações pppoe em conjunto com radius, em redes mistas como cabo, wifi, fibra.
> Aqui por exemplo na minha pequena rede com cerca de 350 clientes sendo 280 simultâneos, faço uso do servidor x86 mikrotik e atendo esta rede que é mista wireless e cabo com roteamentos ospf/mpls/vpls e vlan.
> 
> Observe neste print, tem cerca de 280 conectados pppoe, a maioria quase 5 dias, Pois fiz uma atualização e reiniciei o mikrotik com planos entre 3, 4, 5, 6mb. Processamento 14% + ou - .
> Então acho que este sistema merece credibilidade sim, pois existem provedores com cerca de 2500 e até mais clientes pppoe simultâneos em redes mistas.


Foi justamente oque eu citei acima, pessoas com servidor x86 nao constumao reclamar de tal fato.

Aqui a rede é toda roteada tbm, 90% dos ptp sao curtos menos de 2km e feitos com cambium. Praticamente todos os painel sao com tdma ativa nv2/airmax clientes 99% com sinal entre -50 a -63 enfim, com rb1100 x2 acontecia menos na ccr ta uma desgraça!

----------


## JonasMT

> Jonas, eu já fiquei em mente de mudar tudo para IPxMAC.
> 
> Recentemente compramos um provedor aqui da cidade, bem grande por sinal, e todos seus clientes são IPxMAC (usando Gerenet, que me interessou também), e a quantidade de reclamações por quedas de conexão é assustadoramente menor que a que recebemos, quando 90% das vezes é o PPPoE que desconecta.
> 
> Estou super cansado e chateado de RouterOS, e não estou com vontade de investir R$:0,01 em um PC para concentrador PPPoE com RouterOS. Depois que passamos a usar Juniper na borda e Extreme/HP/Cisco como switch gerenciável, RouterOS só nos resta para concentrador, o que está prestes a ser substituído.


Eu tbm nao gasto 1 real pra montar um x86, a minha duvida é como accel-ppp se integraria aos sistema de gestao.

----------


## andrecarlim

Nossa cara, difícil é conseguir grana para comprar um Juniper MX5! Cara o Accel-PPP tem scripts que rodam na conexão e desconexão do usuário, se for um pouquinho disposto a olhar o script, vai se surpreender com o resultado, esses caras só querem dizer "A cisco é bom, juniper e bom" cara qual o objetivo de estarmos aqui discutindo soluções se vai sugerir compra infra proprietário, se ligue cara!

Jonas, accel-ppp com debian e bom hardware funciona bem, vai conseguir colocar com folga umas 1500 sessões pppoe por caixa, esses caras aqui são muito sem noção!

----------


## JonasMT

> Nossa cara, difícil é conseguir grana para comprar um Juniper MX5! Cara o Accel-PPP tem scripts que rodam na conexão e desconexão do usuário, se for um pouquinho disposto a olhar o script, vai se surpreender com o resultado, esses caras só querem dizer "A cisco é bom, juniper e bom" cara qual o objetivo de estarmos aqui discutindo soluções se vai sugerir compra infra proprietário, se ligue cara!
> 
> Jonas, accel-ppp com debian e bom hardware funciona bem, vai conseguir colocar com folga umas 1500 sessões pppoe por caixa, esses caras aqui são muito sem noção!


Maquina eu tenho um xeon 1230 c/ 16gb ecc e hd nao é o problema tenho alguns ssd e hds convecional parados aqui.

Minha demanda atual é para pouco mais de 600 conexoes!

----------


## andrecarlim

Nossa, da pra colocar umas 3000 sessões num computador desses, me ligue aí que te ajudo, 49 9138-3956!

----------


## JonasMT

> Nossa, da pra colocar umas 3000 sessões num computador desses, me ligue aí que te ajudo, 49 9138-3956!


Po serio? Bom de mais so!

E como fica a integraçao com os sistema de gerenciamento radius? Atualmente to saindo do controllr e indo para CNTsistema. Posso manter autenticaçao centralizada?

----------


## andrecarlim

Nossa cara que conhecidência, em 3 dos meus clientes temos integrado a minha estrutura ao CONadmin! Se quiser vou poder te atender com perfeição!

----------


## JonasMT

> Nossa cara que conhecidência, em 3 dos meus clientes temos integrado a minha estrutura ao CONadmin! Se quiser vou poder te atender com perfeição!


Entao to migrando tem 20d para o CNT, financeiro até ja passo pelo treimando acho meio dificil ela querer migrar dinovo. E tbm o custo de implantaçao ja foi pago

----------


## andrecarlim

Deixei meu número ali em cima, se puder me ligar eu vou te explicar como funciona a estrutura com o CONadmin, estou no meu escritório ainda.

----------


## edmilson2709

> Qual versão vc usa?


Versão mais atualizado do MK 6.35.2.

----------


## edmilson2709

> Cara tem que ver o MTU e o keepalive Timeout e tbm se o cliente estiver com sinal ruim fica só desconectando, meus problemas eram só estes.


Ja mexi em tudo isto, keepalive timeout já coloquei 300. 60, ja deixei inativo e não senti diferenças, o mesmo vale para o MTU 1500, 1400, 1492, não vi diferenças também.

----------


## edmilson2709

> Existe relatos desse problema na versão 6.35


Já atualizei o sistema justamente para 6.35 para ver se iria resolver tal problema, continuou a mesma coisa, sistema então, creio que não seja.

----------


## edmilson2709

> Aparece algo no log? Algo do tipo "peer is not responding"? Se usa radius, no radacct, caso seja freeradius, deve aparecer o motivo da desconexão.
> 
> Assim eu tenho tenho partido para accel-ppp em estruturas maiores, não sei se é o seu caso, mas uma coisa posso garantir, é paz! É muito robusto e escalonável se bem configurado, eu tenho contato direto com os russos que desenvolvem o projeto, tenho colaborado com várias idéias e o último commit ficou perfeito, eles acataram minhas idéias e integraram com parâmetros que podem ser ligados e desligados, ficou muito bom, estou usando em mais de 10 provedores que atendo e não tenho problema!
> 
> Enviado via XT1563 usando UnderLinux App


No momento creio que o RouterOS supre minhas necessidades, mudei para PPPOE por conta do DHCP externo que os clientes me causavam as vezes. Mas a proposta parece ser promissora ...

----------


## joceliomarques

O meu uso 1480 e altero na cpe do cliente tbm.

----------


## edmilson2709

> Aqui, desde 2008 é utilizado o hotspot. Tentei o pppoe mas acontecia a mesma coisa. Desconecta e volta. E isso de forma aleatória. E a mensagem que vinha era esta mesma que citaram. Daí desativamos o pppoe.
> 
> Logo que começamos a mudar achei que seria uma excelente opção pois eliminava a questão do login e senha de uma forma bem simples. Deixava gravado na CPE. 
> 
> Estamos para mudar para o MKSolutions e daí parece que vai ser por pppoe novamente. Como não sou mais o dono, não sei sobre estes detalhes ainda... Na matriz já foi mudado.
> 
> Sei lá, se sou apegado as coisas... mas pelo tempo que estamos com hotspot eu não posso me queixar dele... mas sei que tem muita gente que não gosta... alguns por causa de um broadcasting que ele gera na rede. Isso poderia ser controlado se faz autenticação em cada AP e não centralizado.
> Outros não gostam porque não usaram e por aí vai.


Realmente, sempre utilizei HOTSPOT e adorava o sistema, só mudei para PPPOE por conta de DHCP externo, mesmo utilizando switch VLAN na rede isto acontecia, estou de saco cheio deste sistema, pensando em voltar tudo novamente para o HOTSPOT já!

----------


## ronei10

Olha eu vejo muita reclamação deste tipo na versão 6.35 eh so pesquisar na net que vc vai ver.

----------


## ronei10

Eu uso a 6.34.6 bugfix. Ta redondo. Sem esse problema

----------


## edmilson2709

> Olha eu vejo muita reclamação deste tipo na versão 6.35 eh so pesquisar na net que vc vai ver.


Mas como pode explicar que mesmo na antiga versão, 6.26 se não me engano, acontecia o mesmo...

----------


## Zucchi

> Não é questão de ser burro ou metido, é que já temos Juniper MX5 na borda e sabemos como é bom a tranquilidade. :-)


Isso é fato.

Quanto ao problema de PPPoE tenho ele em todas as versões 6xx do Router OS. O que reduziu os problemas foi resetar a RB e deixar ela em 6.28 e nunca mais mexer.

2 anos, fizemos isso 4x. Do resto já cansamos de tentar tudo quanto é tipo de opção. Desistimos.

----------


## VAGNER

Uso aqui 6.19 sem problema nenhum

Enviado via SM-J500M usando UnderLinux App

----------


## TsouzaR

Ah, o PPPoE... problemas, problemas, problemas, hardware barato não funciona bem, hardware que funciona bem é muito caro...

Experta foi a Verizon em largar essa tralha pra lá e migrar para DHCP + Radius no FiOS.  :Smile:

----------


## andrecarlim

> Ah, o PPPoE... problemas, problemas, problemas, hardware barato não funciona bem, hardware que funciona bem é muito caro...
> 
> Experta foi a Verizon em largar essa tralha pra lá e migrar para DHCP + Radius no FiOS.


Cara, acho que você nunca teve experiência de verdade com pppoe server, eu trabalho à mais de 11 anos com provedores internet e sempre usei pppoe, a diferença é configurei bem.

Segundo, não vamos classificar hardware como barato ou caro, e sim como decente, eu não acho que um servidor que custa em torno de 3.5k é barato, e com um desses da pra segurar umas 2k sessões pppoe tranquilo, claro, não com BugOS.

Outra coisa, acho que o propósito do fórum é software livre, esse negócio de ficar arrastando asa pro lado de hardware/software proprietário é coisa de quem não sabe nada de rede e quer se garantir, é o que acho, se estiver errado me desculpe, mas eu estudei o protocolo pppoe, até fiz mudanças no código fonte do velho rp-pppoe, quando usava ele, para ficar do jeito que eu queria, então por favor, matar mosquito com bala de canhão não cola pra mim!

Enviado via XT1563 usando UnderLinux App

----------


## TsouzaR

> Cara, acho que você nunca teve experiência de verdade com pppoe server, eu trabalho à mais de 11 anos com provedores internet e sempre usei pppoe, a diferença é configurei bem.
> 
> Segundo, não vamos classificar hardware como barato ou caro, e sim como decente, eu não acho que um servidor que custa em torno de 3.5k é barato, e com um desses da pra segurar umas 2k sessões pppoe tranquilo, claro, não com BugOS.
> 
> Outra coisa, acho que o propósito do fórum é software livre, esse negócio de ficar arrastando asa pro lado de hardware/software proprietário é coisa de quem não sabe nada de rede e quer se garantir, é o que acho, se estiver errado me desculpe, mas eu estudei o protocolo pppoe, até fiz mudanças no código fonte do velho rp-pppoe, quando usava ele, para ficar do jeito que eu queria, então por favor, matar mosquito com bala de canhão não cola pra mim!
> 
> Enviado via XT1563 usando UnderLinux App


Será que a Verizon também não tem experiência de verdade com PPPoE? Será que eles não configuravam bem? Será que somente você sabe configurar bem e todo mundo que tem problemas com PPPoE mal sabe o que está fazendo?

Embora eu já tenha sim gerenciado rede que usava PPPoE (felizmente migramos tudo para DHCP), basta ver os relatos pela Internet, inclusive no fórum da MikroTik, de como soluções baratas não são confiáveis. A empresa e o profissional é quem deve definir o padrão de qualidade da rede e buscar equipamentos que o atendam, não o contrário. O que ocorre é que muitos se ajustaram ao equipamento e estão acostumados com seus problemas e reduzem seus critérios para aceitar algo barato na rede.

A questão do hardware é a seguinte: o mesmo hardware que aguenta X clientes usando DHCP + Radius (único processamento significativo é roteamento e controle de banda), aguenta apenas aproximadamente a metade com PPPoE, isso sem ter vantagem nenhuma (isolamento pode ser feito no equipamento de acesso)! Quer jogar dinheiro fora, gastar com hardware mais potente desnecessariamente? Use PPPoE!

Ah, não sabia que todas implementações de DHCP, muito menos de Radius, eram proprietárias...

"Matar mosquito com bala de canhão" é uma frase que se aplica muito bem a PPPoE. A ideia por trás dela é justamente usar algo que faz muito mais do que o necessário para obter um dado resultado. Considerando o custo (hardware, overhead, etc.) do PPPoE, ele é realmente a forma mais eficiente de isolar os clientes, que é talvez sua única utilidade?

----------


## andrecarlim

> Será que a Verizon também não tem experiência de verdade com PPPoE? Será que eles não configuravam bem? Será que somente você sabe configurar bem e todo mundo que tem problemas com PPPoE mal sabe o que está fazendo?
> 
> Embora eu já tenha sim gerenciado rede que usava PPPoE (felizmente migramos tudo para DHCP), basta ver os relatos pela Internet, inclusive no fórum da MikroTik, de como soluções baratas não são confiáveis. A empresa e o profissional é quem deve definir o padrão de qualidade da rede e buscar equipamentos que o atendam, não o contrário. O que ocorre é que muitos se ajustaram ao equipamento e estão acostumados com seus problemas e reduzem seus critérios para aceitar algo barato na rede.
> 
> A questão do hardware é a seguinte: o mesmo hardware que aguenta uns 1000 clientes usando DHCP + Radius (único processamento significativo é roteamento e controle de banda), aguenta apenas uns 500 com PPPoE, isso sem ter vantagem nenhuma (isolamento pode ser feito no equipamento de acesso)! Quer jogar dinheiro fora, gastar com hardware mais potente desnecessariamente? Use PPPoE!
> 
> Ah, não sabia que todas implementações de DHCP, muito menos de Radius, eram proprietárias...
> 
> "Matar mosquito com bala de canhão" é uma frase que se aplica muito bem a PPPoE. A ideia por trás dela é justamente usar algo que faz muito mais do que o necessário para obter um dado resultado. Considerando o custo (hardware, overhead, etc.) do PPPoE, ele é realmente a forma mais eficiente de isolar os clientes, que é talvez sua única utilidade?


Meu amigo, você fala tanta besteira que tenho que rir de suas idéias! Maluco se apoie em suas idéias e não nas dos outros. Essa sua conversa muito amadora sobre pppoe consumir mais hardware não tem o menor fundamento, faça um favor pra todos vá estudar! E pare de confundir os outros com suas teorias mirabolantes, se entendesse alguma coisa de Linux e hardware não estaria falando m****!

Enviado via XT1563 usando UnderLinux App

----------


## 1929

Presados, ninguém até agora criticou o pppoe em si. O que está sendo conversado é sobre as dificuldades de fazer o pppoe no mikrotik funcionar tranquilo... é só olhar o título do tópico. 
Por outro lado alguns não encontram problemas. Sinceramente eu não sei o que pode ser... Só não aceito sugestões de cabo, fonte, mtu, sinal e coisas do gênero pois tudo isso já foi tentado.

----------


## andrecarlim

> Presados, ninguém até agora criticou o pppoe em si. O que está sendo conversado é sobre as dificuldades de fazer o pppoe no mikrotik funcionar tranquilo... é só olhar o título do tópico. 
> Por outro lado alguns não encontram problemas. Sinceramente eu não sei o que pode ser... Só não aceito sugestões de cabo, fonte, mtu, sinal e coisas do gênero pois tudo isso já foi tentado.


Claro, é isso aew. Tem casos onde parece que o problema é o equipamento de autenticação. Eu sempre estou disposto a ajudar, naquilo que diz respeito a redes e Linux!

Enviado via XT1563 usando UnderLinux App

----------


## TsouzaR

> Meu amigo, você fala tanta besteira que tenho que rir de suas idéias! Maluco se apoie em suas idéias e não nas dos outros. Essa sua conversa muito amadora sobre pppoe consumir mais hardware não tem o menor fundamento, faça um favor pra todos vá estudar! E pare de confundir os outros com suas teorias mirabolantes, se entendesse alguma coisa de Linux e hardware não estaria falando m****!
> 
> Enviado via XT1563 usando UnderLinux App


Nossa, belo argumento o seu. Quando o indivíduo não tem mais o que falar, ataca a outra pessoa, ainda mais sem ao menos conhecê-la. Não tenho paciência com isso.

Não sei se você é cego, tem algum problema mental que lhe impede de interpretar um texto completamente, ou algo assim (esse tipo de problema tem se tornado comum entre viciados em WhatsApp), mas a parte da Verizon foi um exemplo e apenas uma pequena parte do post que fiz. Se você reler o post, notará que além disso citei minha experiência com redes usando PPPoE. O que estou falando tem base técnica e a Verizon é um exemplo de que está correto.

Pelo visto é você quem não entende coisa alguma aqui, camarada. Todo tipo de encapsulamento e tunelamento adiciona overhead e exige mais trabalho dos roteadores nas pontas para tratar os pacotes, adicionando ou removendo cabeçalhos (no caso, 8 bytes de cabeçalhos do PPP encima do protocolo Ethernet). Por consequência, há um maior uso dos processadores e um tempo maior para tratar cada pacote que resulta em maior latência em _software routers_, que se você for esperto, vai entender em como influencia em throughput TCP, há até uma fórmula para isso.

Quem não entende isso é do tipo que acha que pode colocar um túnel EoIP para trafegar centenas de megabits por segundo que não vai ter problema. Assim é fácil fazer VPN L2, Lan-to-Lan, transporte, etc., né? Pena que não funcione bem e não é a solução correta para essas situações, _"o buraco é mais embaixo"_.

A aplicação prática do modelo OSI, que é conhecimento básico para qualquer um na área de redes é basicamente isso: adição e remoção de cabeçalhos. Se entendesse isso eu não precisaria estar explicando sobre tunelamento e encapsulamento aqui.

Lembre-se que estamos em um fórum. Você achar que sabe alguma coisa e de fato saber são bem diferentes. Você é quem está vomitando asneira aqui e todo mundo que tem o conhecimento suficiente está vendo que você está falando sem base alguma. Pergunte sobre isso lá na lista [GTER] e você vai ver que há gente renomada no setor que também é contra o uso de PPPoE. Quero ver seu pseudo conhecimento servir de algo para argumentar contra esse pessoal.

Desculpe-me o fórum pelo post agressivo. É meu último nesse tópico sobre esse assunto.

----------


## TsouzaR

> Ja mexi em tudo isto, keepalive timeout já coloquei 300. 60, ja deixei inativo e não senti diferenças, o mesmo vale para o MTU 1500, 1400, 1492, não vi diferenças também.


E quanto ao Session Timeout e Idle Timeout no profile do servidor PPPoE? Já verificou se não tem algum valor configurado nesses atributos?

Se usasse Radius, iria recomendar também verificar esses atributos de timeout nele, já que sobrescrevem o configurado no RouterOS.

----------


## edmilson2709

> E quanto ao Session Timeout e Idle Timeout no profile do servidor PPPoE? Já verificou se não tem algum valor configurado nesses atributos?
> 
> Se usasse Radius, iria recomendar também verificar esses atributos de timeout nele, já que sobrescrevem o configurado no RouterOS.


Em ambos não tem nada ... já sei o que fazem, o primeiro desconecta o cliente apos um periodo, e o outro é quando o cliente fica sem utilizar por determinado periodo é deslogado, porém não tem nada neles ... Fora que é + de 100 usuarios que desconectam, não somente 1 ou 2 ... as vezes são 8, outras 20, outra 30 e por ai vai ...

Sinceramente, PPPOE está só me dando dor de cabeça, até mesmo mais do que quando os clientes faziam a bendita ação de trocar o cabo da WAN para LAN antigamente ...

E só para ter uma ideia, isso vai e volta, por exemplo, já tenho pessoas com + de 7 dias, enquanto tem locais distintos que já cairam 2-3 ao mesmo tempo, mesmo morando distantes e em cabeamentos distintos.

----------


## edmilson2709

Amigos, por favor, não se exaltem, estamos em um ambiente publico, não é por que não estamos nos vendo que não vamos respeitar o espaço e uns aos outros ...
Obrigado por estarem colaborando, já faz um bom tempo que participo de fórum e sempre que tenho uma duvida ou uma "solução" corro pra cá.

----------


## andrecarlim

Peço desculpas a todos do post, realmente tenho que aprender a respeitar a opinião dos outros, vamos acabar um dia indo para cisco ou juniper mesmo, é melhor comprar agora um MX5 atender 1000 sessões pppoe, abandonemos Linux e Mikrotik.

Enviado via XT1563 usando UnderLinux App

----------


## andrecarlim

Me passe seu nick do Skype, o meu Skype é andre.carlim e meu whats é 4991383956. Abs.

Enviado via XT1563 usando UnderLinux App

----------


## viatel

na minha rede não acontecia isso, agora uns dias pra ca começou a cair os ppoe e depois volta, não sei se esta relacionado, mas veja bem.. Tem um vizinho meu que é* serralheiro* e sempre trabalhou em obras e não fazia serviços na casa dele, ha 2 semanas ele esta fazendo uns portões na sua casa mesmo, justamente no mesmo período que começou a dar problemas de desconexão do ppoe.

Como os amigos dizem que já tentaram de tudo, acredito que seja alguma coisa envolvendo interferência. No meu caso vou tentar mudar o modelo do AP que estes clientes estão caindo . Acredito que não seja um defeito, por isso não adianta trocar o equipamento por outro do mesmo modelo e tecnologia, pois se trata de uma característica.

----------


## JonasMT

> na minha rede não acontecia isso, agora uns dias pra ca começou a cair os ppoe e depois volta, não sei se esta relacionado, mas veja bem.. Tem um vizinho meu que é* serralheiro* e sempre trabalhou em obras e não fazia serviços na casa dele, ha 2 semanas ele esta fazendo uns portões na sua casa mesmo, justamente no mesmo período que começou a dar problemas de desconexão do ppoe.
> 
> Como os amigos dizem que já tentaram de tudo, acredito que seja alguma coisa envolvendo interferência. No meu caso vou tentar mudar o modelo do AP que estes clientes estão caindo . Acredito que não seja um defeito, por isso não adianta trocar o equipamento por outro do mesmo modelo e tecnologia, pois se trata de uma característica.


Vai gastar dinheiro e tempo atoa.

----------


## andrecarlim

> Vai gastar dinheiro e tempo atoa.


Jonas, se quiser podemos bolar a ideia do Debian com Accel-ppp, deixei meus contatos mais acima, meu email é [email protected]

Enviado via XT1563 usando UnderLinux App

----------


## leonardoads

Com certeza é um problema de loop na rede , ja passei por isso era um cabo fechando curto na rede .

Enviado via LG-D805 usando UnderLinux App

----------


## tassiofk2

amigo primeiro no server-pppoe olha o mtu e mru para 1480 e mrru 1600 keepalive 60 s após isso, verifica o mtu dos clientes sempre uso 1452, se o meio físico ta ok, verifica os ptp wireles cmg aconteceu que uns powerbeam dava esse problema usei radio mk rb 912 cmg resolveu.

----------


## andrecarlim

Boa noite gente!

Vou deixar abaixo o link do meu canal do youtube, fiz 3 videos recentes ensinando como instalar o Accel-PPP no Debian!

https://www.youtube.com/channel/UCXp...3WVVLrk-9vURFw

P.S.: Nos videos é mostrado como configurar levando em conta que já seja usado radius, tem como usar arquivos chap/pap com usuário e senha, nunca usei, mas uma boa lida no faq do accel-ppp deve ensinar como fazer isso!

Home Page Accel-PPP
Accel-PPP Configuration
Accel-PPP Compilation HowTo

----------


## edmilson2709

Gente, descobri algo estranho, nos momentos que ocorre essa queda de usuarios, 2 usuarios ficam com o trafego de upload extrapolado o que isso significa? Eles até mesmo quebram o bloqueio de banda que eu coloco nos profiles, um deles é recente, outro já tenho faz um bom tempo ...
Irei fazer um teste deixando todas as minhas portas na aba ARP em reply-only, alguns me disseram que poderia ser isto ...

----------


## edmilson2709

> Com certeza é um problema de loop na rede , ja passei por isso era um cabo fechando curto na rede .
> 
> Enviado via LG-D805 usando UnderLinux App


Como descobriste o loop? Saiu de caixa em caixa? Eu mesmo ja fiz um loop aqui na rede, e ele deixou a rede inteira lenta, so se tiver alguem maluco chegando em uma das minhas caixas, junta um cabo com outro e ta dando isso, mas como explicar que até mesmo em uma porta que é unica para um bairro, as pessoas deste bairro caem também? Se fosse loop, coisa que acho que não seja, ele parava a rede inteira, e não só certos pontos. Fora que isto é aleatorio, tem dias que isso ataca mesmo, outros que sequer aparece, ontem mesmo foram 2 vezes, hoje 1 antes de eu vir aqui no fórum, que foi quando percebi o alto upload destes 2 clientes.

----------


## leonardoads

Tinha um cabo que encostou no fio elétrico e estava em curto 

Enviado via LG-D805 usando UnderLinux App

----------


## rimaraujo

Prometo que quando leio esse tópico, vejo pessoas mais loucas que outras dizendo que PPPOE não funciona. Aqui utilizo o PPPOE a 8 anos. Nunca tivemos esses problemas. Clientes conectam no pppoe e ficam 30 50 100 dias conectados. Torres que estão ligadas à 900 dias sem um sequer reboot.
Vocês confundem protocolo com estabilidade e/ou equipamentos.
A conexão mais segura é o pppoe. Não existe mais HS, Mac IP,. 
Trabalhem na rede, arrumem suas redes, se não tiverem backbone não terá nada.
Provedor que usa Mac IP cliente não reclama e porque a conexão cai e retorna muito rapidamente. Já o protocolo pppoe tem que dar o timeout para realizar a nova conexão, não existe problemas no pppoe. Não existe problemas na RB. Não existe problemas no mikrotik.
Existe problemas nas pessoas em dizer que uma máquina da um desempenho melhor que uma RB.
Pegue a maquina que quiser ela não tem melhor desempenho que uma CCR.

Você sem que aprender as coisas e ter certeza na hora de afirmarem algo absurdo desse.

Comparar processador risk com processador cisc. É Hilário uma coisa dessa....




Enviado via GT-I9515L usando UnderLinux App

----------


## TsouzaR

> Prometo que quando leio esse tópico, vejo pessoas mais loucas que outras dizendo que PPPOE não funciona. Aqui utilizo o PPPOE a 8 anos. Nunca tivemos esses problemas. Clientes conectam no pppoe e ficam 30 50 100 dias conectados. Torres que estão ligadas à 900 dias sem um sequer reboot.
> Vocês confundem protocolo com estabilidade e/ou equipamentos.
> A conexão mais segura é o pppoe. Não existe mais HS, Mac IP,. 
> Trabalhem na rede, arrumem suas redes, se não tiverem backbone não terá nada.
> Provedor que usa Mac IP cliente não reclama e porque a conexão cai e retorna muito rapidamente. Já o protocolo pppoe tem que dar o timeout para realizar a nova conexão, não existe problemas no pppoe. Não existe problemas na RB. Não existe problemas no mikrotik.
> Existe problemas nas pessoas em dizer que uma máquina da um desempenho melhor que uma RB.
> Pegue a maquina que quiser ela não tem melhor desempenho que uma CCR.
> 
> Você sem que aprender as coisas e ter certeza na hora de afirmarem algo absurdo desse.
> ...


Eu não disse que PPPoE não funciona, disse que não é a melhor solução em custo-benefício por demandar mais hardware, e consequentemente mais investimento, sendo que não provê *nenhuma vantagem real* em comparação a outras opções que usam menos recursos do equipamento. O único benefício é o isolamento L2, mas isso pode ser obtido com uma configuração simples no equipamento do ponto acesso e em um switch ou firewall do roteador, de forma bem, mas BEM menos onerosa.

Provedor pequeno não tem muito dinheiro, não deveria usar uma tecnologia que vai demandar que ele gaste desnecessariamente com concentradores "parrudos". Às vezes o provedor é tão pequeno que o concentrador "parrudo", adquirido para suportar trabalhar com muitas sessões PPPoE, vale mais que o restante rede inteira dele, sendo que se usasse uma tecnologia mais leve, poderia investir em outros pontos mais críticos e que trarão real avanço ou melhoria nos serviços.

E quando a empresa cresce, como vai fazer para suportar, digamos, uns 3k ou mais de sessões PPPoE simultâneas? Ou compra um Cisco ou Juniper caríssimos, ou monta um servidor x86 devorador de energia (caríssimo a longo prazo), ou faz um balanceamento entre várias CCRs, que é a solução mais barata, mas ao mesmo tempo cara no total e não 100% estável/confiável (ou seja, baixo ou no máximo médio custo-benefício), sendo que se não usasse PPPoE, resolveria isso de forma muito mais fácil, barata e escalável. E descentralizar não muda nada para melhor nessa questão, já que onde poderia usar uma RB2011 no PoP, vai ter que colocar uma RB1100AHx2 ou CCR1009 para suportar o trabalho de (des)encapsulamento para a mesma quantidade de tráfego.

Entende meu ponto? Realmente gostaria que fosse apresentado onde está o erro no meu raciocínio, se houver.

Aff, eu tinha dito que não iria postar mais sobre isso aqui, mas já que o assunto original parece estar andando a passos lentos, tem um espacinho.  :Smile:

----------


## 1929

Obrigado pelo "louco"....não me abalo. Apesar de eu também não dizer que o pppoe não funciona. Eu até citei que para alguns funciona mas para outros não... E não é questão de cabo, fonte, sinal, interferência ou coisas do gênero. Pois tudo isso já foi tentado aqui.
É muito estranho, pois as vezes cliente com sinal não tão bom não cai e cliente com sinal excelente cai. Também não é keepalive time out...
Sinceramente com a minha loucura não pude identificar onde é. 

Quanto a segurança, tem um vídeo do Wardner Maia sobre segurança onde ele afirma que a segurança não depende do método de autenticação, seja pppoe, seja hotspot...
Segurança em wireless é criptografia WPA2 AES. 

Pppoe ou hotspot é somente uma opção comercial, ele explica no vídeo... E ainda cita que usa hotspot em rede com mais de mil usuários. Não quero com isso defender o uso do hotspot. Cada um tem as opções na "mesa" para escolher.

----------


## edmilson2709

> Tinha um cabo que encostou no fio elétrico e estava em curto 
> 
> Enviado via LG-D805 usando UnderLinux App


Quando isto aconteceu, a rede parou naquela hora ou simplesmente ficava da forma que expliquei no post? Caia e depois de um tempo voltava à funcionar? E além do mais caindo de forma aleatoria?

----------


## edmilson2709

> Prometo que quando leio esse tópico, vejo pessoas mais loucas que outras dizendo que PPPOE não funciona. Aqui utilizo o PPPOE a 8 anos. Nunca tivemos esses problemas. Clientes conectam no pppoe e ficam 30 50 100 dias conectados. Torres que estão ligadas à 900 dias sem um sequer reboot.
> Vocês confundem protocolo com estabilidade e/ou equipamentos.
> A conexão mais segura é o pppoe. Não existe mais HS, Mac IP,. 
> Trabalhem na rede, arrumem suas redes, se não tiverem backbone não terá nada.
> Provedor que usa Mac IP cliente não reclama e porque a conexão cai e retorna muito rapidamente. Já o protocolo pppoe tem que dar o timeout para realizar a nova conexão, não existe problemas no pppoe. Não existe problemas na RB. Não existe problemas no mikrotik.
> Existe problemas nas pessoas em dizer que uma máquina da um desempenho melhor que uma RB.
> Pegue a maquina que quiser ela não tem melhor desempenho que uma CCR.
> 
> Você sem que aprender as coisas e ter certeza na hora de afirmarem algo absurdo desse.
> ...


Entendo seu lado, porém me explique como pessoas em uma rede unica, separada de todas as outras tem tal problema? Um unico cabo só para fazer a conexão em um enlace para a outra torre para mandar para os clientes do bairro, pessoas no pé da torre caem porém as pessoas após as mesmas ficam normais? Não quero dizer que PPPOE não funciona, só estou dizendo que em meu caso ele funcionou, porém desta forma, coisa que acho engraçada, pois no HOTSPOT isto nunca aconteceu, mas como você mesmo disse, pelo protocolo ser fino ele cai e volta, coisa que os outros não são, mas como me explica pessoas ligadas coisa de 500 metros da minha RB caindo? ...

----------


## edmilson2709

Alguém pode me explicar o motivo de cerca de 4 usuarios nos momentos de desconexões, ficam com a taxa de upload lá em cima, as vezes são 4, outras vezes são 2, 2 já tenho à algum tempo, os outros foram recentes. O que isso poderia significar? Alguém atacando a minha rede?

----------


## andrecarlim

Fácil! Esses usuários devem estar contaminados de vírus e etc, como sabemos bem, no caso da ccr, as sessões pppoe rodam todos os processos em um único núcleo, quando esses dois "arrebentam" o upload provavelmente ela sobre o processamento e aí começa a desconectar as sessões pppoe, e esse é um problema conhecido.

Enviado via XT1563 usando UnderLinux App

----------


## rimaraujo

> Entendo seu lado, porém me explique como pessoas em uma rede unica, separada de todas as outras tem tal problema? Um unico cabo só para fazer a conexão em um enlace para a outra torre para mandar para os clientes do bairro, pessoas no pé da torre caem porém as pessoas após as mesmas ficam normais? Não quero dizer que PPPOE não funciona, só estou dizendo que em meu caso ele funcionou, porém desta forma, coisa que acho engraçada, pois no HOTSPOT isto nunca aconteceu, mas como você mesmo disse, pelo protocolo ser fino ele cai e volta, coisa que os outros não são, mas como me explica pessoas ligadas coisa de 500 metros da minha RB caindo? ...


Não conheço sua rede mas te garanto. O problema é nela.

Enviado via GT-I9515L usando UnderLinux App

----------


## rimaraujo

> Alguém pode me explicar o motivo de cerca de 4 usuarios nos momentos de desconexões, ficam com a taxa de upload lá em cima, as vezes são 4, outras vezes são 2, 2 já tenho à algum tempo, os outros foram recentes. O que isso poderia significar? Alguém atacando a minha rede?


Broacast. Consumo. Bridge. Rede ou até mesmo uma máquina zumbi

Enviado via GT-I9515L usando UnderLinux App

----------


## inquiery

Loop na rede causa problemas fodásticos, mesmo quando você usa switchs VLAN desses para isolar tráfego entre clientes e/ou dispositivos da sua rede. Pois se fechar o loop no switchs VLAN, você ainda vai ter trafego infinito correndo na rede, para um lado só por causa dos switchs VLAN, mas vai ter, e ele vai fazer a rede senta em toda a extensão onde esse loop se propaga.

Outra coisa que acho que muita gente ainda não percebeu, é que em vários desses roteadores que são usados para cliente final, eles implementam no firmware um keepalive que funciona fora do contexto do PPPoE, eles simplesmente colocam um PING executando de tempos em tempos para a outra ponta do túnel, e se a outra ponta não responde por determinado tempo ou quantidade de PINGs, o próprio roteador derruba a conexão PPPoE e reconecta. Portanto, se você tem políticas de bloqueio de ICMP na rede, provavelmente muitos dos clientes vão desconectar devido a esse problema, e se você não tem política de bloqueio porém não tem políticas de priorização de trafego ICMP nos queues, então quando o usuário estiver usando toda a banda dele ele vai perder pacotes ICMP, o que vai acarretar na desconexão do cliente, e isso não é problema na RB, é os roteadorzinho que são burros e não veem que aquele PING é desnecessário visto que há trafego rolando no túnel (o que quer dizer que O TUNEL TA FUNCIONANDO).

Voltando pro contexto do PPPoE, em redes wireless é mais complicado, pois mesmo todos os clientes estando perfeitinho, com banda sobrando, sempre tem aquela perdinha de pacote aqui e lá, e por mais que você desabilite o Keepalive no Mikrotik, alguns roteadores vão continuar mandando mensagens de Keepalive, e se der coincidencia desses keepalive serem perdidos, lá sei vai a conexão novamente, e neste caso novamente é o roteador que reconecta.

----------


## TsouzaR

> Fácil! Esses usuários devem estar contaminados de vírus e etc, como sabemos bem, no caso da ccr, as sessões pppoe rodam todos os processos em um único núcleo, quando esses dois "arrebentam" o upload provavelmente ela sobre o processamento e aí começa a desconectar as sessões pppoe, e esse é um problema conhecido.
> 
> Enviado via XT1563 usando UnderLinux App


Aí, André, você acabou de dar um exemplo do que eu estava falando ao dizer que equipamentos baratos não são confiáveis como concentrador PPPoE, hehehehe.




> Loop na rede causa problemas fodásticos, mesmo quando você usa switchs VLAN desses para isolar tráfego entre clientes e/ou dispositivos da sua rede. Pois se fechar o loop no switchs VLAN, você ainda vai ter trafego infinito correndo na rede, para um lado só por causa dos switchs VLAN, mas vai ter, e ele vai fazer a rede senta em toda a extensão onde esse loop se propaga.


Então seria melhor que a porta uplink desses switches VLAN fosse usada para conectar o próximo switch da cascata, não o anterior que vem da central. Dessa forma um loop derrubaria apenas daquele switch em diante, não pra frente, em direção à central (e consequentemente parando todo mundo no ramal), certo? Se o raciocínio estiver correto, está aí a razão por muita gente falar que switch VLAN não isola nada quando tem loop: tem feito uso errado da porta uplink...

----------


## andrecarlim

Claro que comparando uma CCR1009 a um MX5, chegaremos a conclusão que a CCR é "barata", só que hoje em dia quais soluções profissionais tem um bom custo benefício? Honestamente acho que nenhuma, se levarmos a solução com Debian + Accel-PPP para a produção, vamos gastar entre hardware bom e mão de obra qualificada pelo menos 1/5 a 1/7 do valor de um Juniper MX5, logo fica do gosto de cada um!

Eu tenho uns conhecidos que não trocam os MX5 por nada, exceto por um MX10, do mesmo modo que tenho alguns conhecidos que administram o seu próprio provedor usando Ubuntu Server + Accel-PPP em vários pontos da rede, isto é, vários servidores com VLANs, e que não abrem mão dessa solução, até tem um caso recente que pude participar e ver um chegado que tem no provedor dele umas 10 caixas, com ~ 2.5k sessões pppoe em cada, é um cálculo fácil, eles atendem cerca de ~ 25k sessões simultâneas no total, um misto entre rádio e fibra, mas a maior parte do trânsito ainda vem do rádio, neste caso temos que levar em conta que eles tinham dentro do provedor a mão de obra e os desenvolvedores do sistema de suporte para integração com o banco de dados/senhas e os servidores pppoe, então se pedirmos a opinião dele, claro que será inclinada ao Accel-PPP, mas em outros casos onde precisa de mão obra qualificada... Pode sair caro, ainda assim pela experiência que tenho gosto de soluções que levem Linux e software open source! Claro que quem tiver grana para gastar com hardware/licença/mão de obra/tempo pra aprender, deve ir fundo nas soluções proprietárias que não tem erro, dificilmente vai dar problema ou dor de cabeça, enfim até aqui saí caro uma boa solução, seja hardware ou mão de obra.

----------


## TsouzaR

> Claro que comparando uma CCR1009 a um MX5, chegaremos a conclusão que a CCR é "barata", só que hoje em dia quais soluções profissionais tem um bom custo benefício? Honestamente acho que nenhuma, se levarmos a solução com Debian + Accel-PPP para a produção, vamos gastar entre hardware bom e mão de obra qualificada pelo menos 1/5 a 1/7 do valor de um Juniper MX5, logo fica do gosto de cada um!


E por que a solução para ter estabilidade e confiabilidade tem que ser um equipamento mais caro, e não o uso de outra tecnologia que use menos recursos e que funcione melhor no hardware barato? CCR funciona muito bem, sem problema algum conhecido e relevante, e dura muito mais tempo na rede sem precisar de upgrade, se usar Hotspot* ou melhor ainda, meu preferido: DHCP + Radius...



*Obs.: Hotspot com autenticação por MAC, claro. Ter que fornecer login e senha em navegador é anti-intuitivo (Internet não é só navegação há muito tempo, principalmente em dispositivos móveis, então requerer abrir navegador somente para autenticar é um absurdo) e não funciona bem por causa do HTTPS.

----------


## andrecarlim

Assim hoje em dia se a rede for camada 2 não tem como usar algo diferente de pppoe, aaahhh mas a Verizon usa... Cara nem achei a informação para validar isso, o que achei é que um lado do país usam DHCP e do outro PPPoE, e se o cliente quiser pode escolher, mediante carta assinada... Outra coisa, hoje em dia tá cheio de espertinho clonando MAC logo, recorrer para autenticação pelo MAC é morte súbita, ahhh mas a gente vai ter VLAN individual para cada ONU espetada na OLT, vai lá amigão colocar teu hotspot em cada Vlan. Não estou aqui para rebater ninguém mas gente, pensem bem DHCP sempre vai entregar o IP antes da autenticação, não tem outra forma, sempre vai depender do MAC. E eu não acho uma boa ideia depender de MAC, gosto muito de amarrar tudo ao login, inclusive o IP! TsouzaR não quero que me entenda mau mas eu tenho muito conhecido, muito mesmo, já até participei de grupos de trabalho para redes que atendem mais de 50k usuários, ninguém mais usa hotspot ou dhcp, sem contar que essas soluções em camada 3 gastam IP de varde. Sei que tem argumentos bons, mas vou ser honesto esse overhead que é teu principal argumento, eu gastei tempo esse fim semana analisando, cara não chega e ser 5% de um processador core 2 duo, não acho que isso vá impactar toda a rede, agora uma rede bem configurada posso garantir que não dá problema no pppoe, não em ccr, é claro, ela por si só da problema! Haha.

Enviado via XT1563 usando UnderLinux App

----------


## TsouzaR

Hm... ainda não me convenceu, hehehe.

A rede de acesso é sempre camada 2, não entendi seu ponto quanto a isso. Se for pela questão do broadcast e comunicação entre clientes, basta configurar isolamento no equipamento do ponto de acesso e alguns filtros no switch e/ou firewall do roteador...

Sobre a autenticação, ao menos para DHCP + Radius, MAC é o de menos. Dá para usar a opção 82, onde a OLT informa o ID único da ONU na rede (slot, porta PON e ID da ONU na porta), por exemplo. MikroTik, e acho que qualquer switch, infelizmente vão usar a porta física e o MAC como valor para opção 82, então uma alternativa é configurar usuário e senha na opção 82 no roteador do cliente (já se faz isso para PPPoE, então não é trabalho a mais). É possível ainda usar o MAC, em conjunto à opção 82, para fortalecer a autenticação, e isso é especialmente interessante quando se usa PACPON, onde a opção 82 vai identificar a ONU/PACPON e o MAC identifica o roteador do cliente (ele vai conseguir clonar no máximo o MAC de outro usuário do mesmo PACPON).

Há como dificultar a clonagem de MAC, se você não deixa o usuário ter acesso ao CPE: VLAN com MAC alterado. O usuário pode até conectar algo na porta WAN e pegar o MAC dela, mas não vai ser o mesmo usado para a autenticação e ele terá que adivinhar o ID da VLAN. Ou o cara pode ser muito esperto e rodar um Wireshark e pegar o ID da VLAN, mas com todo esse esforço já está merecendo conseguir fazer essa clonagem, hehehehe. Nesse caso seria um VLAN ID comum para todos clientes, nada bizarro com um ID por cliente.

De qualquer forma, também não acho que deva usar exclusivamente o MAC como identificador na autenticação. A opção 82, seja fornecida pelo equipamento do ponto de acesso (quando é uma informação confiável, não baseada em MAC), seja fornecida em forma de usuário e senha no roteador do cliente, é a melhor solução, embora no caso de fornecer no roteador, é preciso que ele seja algo mais avançado (uma RB ou ER) ou tenha OpenWrt/DD-WRT/etc. instalado (o trabalho de provisionar isso é o preço por uma rede de acesso melhor  :Big Grin:  ). Isso não é problema para mim, uma vez que no meu ver, o CPE deve ser fornecido pelo provedor, visando que o cliente não tenha acesso a ele (cliente acessando CPE é o inferno!).

*Atualização:* sobre a eficiência no uso de IPs, basta dimensionar bem o tamanho de cada rede de acesso e do prefixo IPv4 a ser usado nela. Se tem muitas redes de acesso pequenas, junte por meio de VLAN ou VPLS algumas delas (não vai ser problema com filtros e isolamento configurados) para usar faixas de IPv4 maiores e evitar o desperdício com endereço de rede e broadcast. Esse caso que você mencionou, das 10 redes de 2.5K de clientes, basta usar em cada uma um prefixo /21 + prefixo /23 (configurado o próximo pool), ou algo semelhante. De qualquer forma, todo mundo vai acabar partindo para CGNAT em IPv4, então vai ser IP privado para todo lado mesmo, não há com que se preocupar com economia de endereços, muitos menos em IPv6.

----------


## andrecarlim

Só para alimentar mas a discussão, esperamos que o IPoE venha para

Enviado via XT1563 usando UnderLinux App

----------


## andrecarlim

Cara, concordo com tudo que você falou, em grau até de acentuação! Alto nível, na verdade até tenho uma curiosidade... Já teve problema em controlar a banda em casos onde o cliente estava com P2P estourando o upload, usando IPoE? Digo isso pois tenho uns testes aqui onde presto suporte e percebi que o controle de banda não é tão eficiente nessa estrutura, claro que não estou usando mikrotik, mas pelo que vi pelos fóruns no mikrotik é pior ainda...

P.S.1: se o cara conseguir adivinhar ou descobrir a VLAN merece mesmo internet de graça!

P.S.2: acho que não dar acesso a CPE para o cliente é o caminho correto para todo provedor!

P.S.3: usar OpenWrt fica bom demais, tem usado bastante isso?

Enviado via XT1563 usando UnderLinux App

----------


## TsouzaR

> Cara, concordo com tudo que você falou, em grau até de acentuação! Alto nível, na verdade até tenho uma curiosidade... Já teve problema em controlar a banda em casos onde o cliente estava com P2P estourando o upload, usando IPoE? Digo isso pois tenho uns testes aqui onde presto suporte e percebi que o controle de banda não é tão eficiente nessa estrutura, claro que não estou usando mikrotik, mas pelo que vi pelos fóruns no mikrotik é pior ainda...


Se refere ao IPoE do accel-ppp? Se for, nunca usei isso, hehehe.
Agora, se for como se chama essa forma que defendi nos meus posts, nunca tive problemas de controle não, mas talvez seja porque as redes que gerencio são no interior, onde o pessoal não é muito acostumado a usar torrent devido às pequenas bandas ofertadas desde sempre.




> P.S.3: usar OpenWrt fica bom demais, tem usado bastante isso?


Onde já sugeri essa solução com opção 82 definida no roteador do cliente, não aceitaram justamente por causa do trabalho de substituir o firmware dos roteadores, hehehehe. E também porque usavam MK-Auth, não queriam mudar e ele não está adaptado para opção 82. Acabou-se usando o MAC mesmo para a autenticação e até hoje nunca tivemos problema com clonagem ou nunca fiquei sabendo.

Estou projetando uma nova rede, minha mesmo, e nela vou usar hAP Lite ou algum TP-Link/D-Link (quase decidindo pelo DIR-615) com OpenWrt em todos clientes.

----------


## 1929

> ...
> ...
> 
> Outra coisa que acho que muita gente ainda não percebeu, é que em vários desses roteadores que são usados para cliente final, eles implementam no firmware um keepalive que funciona fora do contexto do PPPoE, eles simplesmente colocam um PING executando de tempos em tempos para a outra ponta do túnel, e se a outra ponta não responde por determinado tempo ou quantidade de PINGs, o próprio roteador derruba a conexão PPPoE e reconecta. Portanto, se você tem políticas de bloqueio de ICMP na rede, provavelmente muitos dos clientes vão desconectar devido a esse problema, e se você não tem política de bloqueio porém não tem políticas de priorização de trafego ICMP nos queues, então quando o usuário estiver usando toda a banda dele ele vai perder pacotes ICMP, o que vai acarretar na desconexão do cliente, e isso não é problema na RB, é os roteadorzinho que são burros e não veem que aquele PING é desnecessário visto que há trafego rolando no túnel (o que quer dizer que O TUNEL TA FUNCIONANDO).
> 
> Voltando pro contexto do PPPoE, em redes wireless é mais complicado, pois mesmo todos os clientes estando perfeitinho, com banda sobrando, sempre tem aquela perdinha de pacote aqui e lá, e por mais que você desabilite o Keepalive no Mikrotik, alguns roteadores vão continuar mandando mensagens de Keepalive, e se der coincidencia desses keepalive serem perdidos, lá sei vai a conexão novamente, e neste caso novamente é o roteador que reconecta.


Companheiro, esta é a primeira vez que leio uma possível causa de desconexão com pppoe, explicada com fundamentação e clareza. Não temos agora ninguém ativado com pppoe para testar mas ficou bem claro porque a coisa ocorre de forma aleatória. Nem sempre no mesmo cliente vai sempre acontecer, pois pode depender do "momento" pelo qual passa o roteador no cliente.

----------


## inquiery

> Aí, André, você acabou de dar um exemplo do que eu estava falando ao dizer que equipamentos baratos não são confiáveis como concentrador PPPoE, hehehehe.
> 
> 
> 
> Então seria melhor que a porta uplink desses switches VLAN fosse usada para conectar o próximo switch da cascata, não o anterior que vem da central. Dessa forma um loop derrubaria apenas daquele switch em diante, não pra frente, em direção à central (e consequentemente parando todo mundo no ramal), certo? Se o raciocínio estiver correto, está aí a razão por muita gente falar que switch VLAN não isola nada quando tem loop: tem feito uso errado da porta uplink...


Não funciona TsouzaR. Imagina que se você pegar uma porta da CCR e ligar na porta 8 de um Switch VLAN, e a porta 1 no próximo Switch e assim por diante, os clientes conectados nos Switchs nunca "enxergar" a CCR, pois eles só tem forward para a porta 1 (uplink), e qual está indo ao fim daquela rede, um "beco sem saida".

Mas mesmo assim, aquele seguimento de rede só vai derrubar aquele seguimento de rede, mesmo sem fazer o que você disse, basta para isso ser esperto e não conectar o ponto de chegada no concentrador varios cabos em um switch normal. O Switch onde interconecta varias redes também precisa ser no mínimo VLAN fixa. De resto, Assim, se fechar loop naquele seguimento, é só aquele seguimento que fica prejudicado; além disso, se existir por alguma razão trafego entre as redes ethernet indevido, basta bloquear no firewall.

Mas... tem que considerar os radios nessa história, ou seja, digamos que você tem varias extensões de rede cabeada, e liga na ponta dessa rede um radio para conectar na sua torre/central, então você por alguma erro fecha um loop (ja vi acontecer) lgando antenas AS DUAS PONTAS desse backbone remoto em dreção a sua torre/central. Da pra perceber que você fechou um loop aqui, porém, o trafego desse loop chega na sua torre/central e se propaga devolta para a ponta inicial daquele segumento vai até o final e volta novamente pra torre/central que vai pra ponta inicial do seguimento e assim por diante infinitamente (malditos broadcasts...). E AQUI é que ta um grande vilão, pois você tendo varias enlaces de radio ligando essas redes cabeadas na torre/central, assim que um loop desse se inicia, o trafego aereo daquela antena vai ser o máximo possível daquele enlace, causando uma interferencia absurda nos canais adjacentes dependendo da largura de banda. E em regiões onde o uso do espectro já é bem alto, um único loop desse pode acabar derrubando MUITAS partes da rede que depende do radio, por estarem próximos.

----------


## edmilson2709

Bem, pelo jeito consegui resolver, porém todas as pessoas com o roteador Greatek WR-1500L estão com problemas, o roteador conecta na minha RB e tudo porém na casa do cliente ele tenta conectar no wifi e o roteador não entrega o ip dele mesmo para a pessoa, quando retiro o cabo da internet do roteador, funciona, quando coloco, reinicio e tento conectar, só "identificando", não utilizo mais hotspot nesse sistema, separei cada porta, antes utilizava uma bridge, já não estou utilizando mais, DHCP server já retirei, a nova CCR está puramente PPPOE. Engraçado que pessoas com os roteadores TP Link acessam normalmente, já mudei MTU, MRU, MRRU dos PPPOE Servers, já mudei o MTU das portas e nada surtiu efeito, simplesmente conecta, porém não funciona, agora se eu pegar o cabo, retirar, desligar o roteador, religar ele sem o cabo, conectar no wifi, e em seguida colocar o cabo da internet, os dispositivos funcionam, e ficam com internet! Isto não acontecia na antiga configuração, já fiz o teste de pegar um na bancada e ligar diretamente na RB, ele funcionou tranquilamente, conectei normalmente e ficou com internet, levei ele até a casa de um cliente, chegando lá, coloquei ele e não funcionou.

----------


## leonardoads

Tenta setar ip manual 

Enviado via LG-D805 usando UnderLinux App

----------


## edmilson2709

> Tenta setar ip manual 
> 
> Enviado via LG-D805 usando UnderLinux App


No roteador > cliente? Eles sequer conectam, e são muitos Greatek, não consigo pegar o MAC de nenhum que está conectado para reservar ...

----------


## edmilson2709

Existe um topico aqui no Under Linux também com o mesmo problema que eu, alguns dizem para mudar o MTU para 1400 só que já mudei tudo e ficou da mesma forma ...
Antes da nova configuração, funcionava normalmente, com a nova fica desta forma ... agora somente em pessoas com roteador Greatek. 
Alguns aparecem que estão com pessoas conectadas porém não aparece nada na DHCP deste modelo. Algo que achei interessante, no gateway dos Greatek eles pegam a da faixa que criei para liberar internet para o pessoal, e nos TP link o gateway é o da faixa que liberei de IP para as pessoas porém eles aparecem no POOL>Used adresses com a outra faixa também, mesma coisa do Greatek.
Fotos do PPPOE Servers, dos PROFILES e dos roteadores:

----------


## inquiery

Buenas @Edimilson2709

Por acaso a maioria desses casos com problema não são de clientes que ja não tem mais a fonte original do produto? 

Isso ja aconteceu comigo algumas vezes, e era problemas de energia. Até mesmo com a fonte original as vezes, mas a energia na casa do cliente sendo uma m... dava isso. Se colocar uma fonte melhor, ou de repente que suporte mais corrente (pois se ela suporta mais corrente, tem grandes chances de ela ter um ripple menor se a corrente utilizada estiver mais longe do máximo).

Qualquer coisa, leva uma bateriazinha dessas de nobreak e liga o roteador direto nela (se ela for de 12v) no cliente pra testar. Se funcionar, você ja sabe com certeza que o problema é alimentação.

----------


## edmilson2709

> Buenas @Edimilson2709
> 
> Por acaso a maioria desses casos com problema não são de clientes que ja não tem mais a fonte original do produto? 
> 
> Isso ja aconteceu comigo algumas vezes, e era problemas de energia. Até mesmo com a fonte original as vezes, mas a energia na casa do cliente sendo uma m... dava isso. Se colocar uma fonte melhor, ou de repente que suporte mais corrente (pois se ela suporta mais corrente, tem grandes chances de ela ter um ripple menor se a corrente utilizada estiver mais longe do máximo).
> 
> Qualquer coisa, leva uma bateriazinha dessas de nobreak e liga o roteador direto nela (se ela for de 12v) no cliente pra testar. Se funcionar, você ja sabe com certeza que o problema é alimentação.


Mas não são alguns clientes, e sim todos os roteadores da rede em geral que são Greatek, ou seja, bairros diferentes, redes diferentes porém a mesma coisa, sem conexão pelo wifi.Já estou com dor de cabeça aqui de tanto cliente me ligando por que já uso deste modelo a um tempo, desde de manhã com este problema e não obtive solução...

----------


## edmilson2709

Continuou o mesmo problema, o coisa chata viu, to navegando normalmente aqui na NET vou da uma olhada no MK, ta lá um monte de gente deslogando, tudo de forma aleatoria, na antena, no cabo, como isso é possivel? O pior de tudo isso é que, na antena que leva para outro bairro, que esta separada de todo o resto da rede, também cai, ela tem uma porta só para ela e mesmo assim os usuarios caem também. Utilizo uma rede com bridge, sera que é por isto? Mas mesmo na nova configuração que fiz, que os Greateks estavam sem pegar, separei todas as portas, cada uma com seu PPPOE Server, e continuou da mesma forma, caindo de forma aleatoria!

----------


## inquiery

Buenas @*edmilson2709*

Quando cai, qual o motivo de cair? Keep-alive timeout? Idle timeout? Ou você tem habilitou 1 sessão só por host e o cliente solicita uma conexão sem ter caído (o que resulta na desconexão do túnel pppoe antigo)?

----------


## edmilson2709

> Buenas @*edmilson2709*
> 
> Quando cai, qual o motivo de cair? Keep-alive timeout? Idle timeout? Ou você tem habilitou 1 sessão só por host e o cliente solicita uma conexão sem ter caído (o que resulta na desconexão do túnel pppoe antigo)?


Eu ainda não sei, não informa nada, só diz peer is not responding ... e desconecta, já mexi em todas estas configurações, keep alive padrão, idle timeout não tem nada, habilitei o 1 sessão só por host por que eu amarro ip ao user, e se fica 2 logados ao mesmo tempo o cliente não navega, já desativei para ver o que poderia ocorrer e ativei nos profiles o only one, mas tem alguns clientes que desconectam, o usuario fica conectado, porém ele fica tentando autenticar, vejo no LOG e está lá, user is already active, deslogo o usuario que está logado, e a solicitação entra normalmente. Já chequei problemas fisicos como switch, cabos, RJ's, energia e tudo mais, e até agora não obtive uma solução. E o mais estranho ainda é que isso se dá de forma aleatoria, não tem um horario especifico, não tem aquele usuario que loga e derruba todos, não tem local para ocorrer, pode acontecer em um bairro e no outro está normal, pode acontecer no primeiro cliente e depois dele estar normal, por isso é estranho, fora que algumas vezes os usuarios ficam logados por 1 dia ou mais, e em outros momentos que eles deslogam de forma seguida, por exemplo, cai agora, daqui a 10 minutos cai denovo, depois de 30 cai denovo, não acontece com 1,2 ou 3 usuarios e sim com 10 ou bem mais, como já foi o caso de cair + de 100. Atualmente tenho cerca de 240 usuarios logados, já teve casos de só 88 se manterem conectados.

----------


## inquiery

E você ja desabilitou o Keepalive timeout para testar se continuam caindo?

----------


## inquiery

Ja desabilitou o Keepalive timeout para testar?

Os que dão mensagem "user is already active" não vai resolver com isso, quando da essa mensagem, é o próprio roteador do CLIENTE que solicita a reconexão, não é a routerboard que desconecta ele. Esse problema pode ser tanto por problemas físicos na rede, pois alguns roteadores vao enviar pacotes keepalive mesmo que você desative no Mikrotik, e outros vão cair por perder pacotes ICMP (pings) que eles enviam para testar o túnel. Se você bloqueia ICMP, varios roteadores vão ficar caindo pois eles implementaram isso no software daqueles roteadores, pings para testar o túnel ao inves de mensagens keepalive do pppoe. Se você não bloqueia ICMP, faz umas regras de priorização de trafego ICMP dos clientes até a RB na routerboard. Para simples testes, você pode simplesmente marcar TODOS os pacotes ICMP vindos dos clientes com destino a RB com por exemplo "PING-CLIENTE", e criar uma regra no queue simple, acima das de PPPoE, com target 0.0.0.0/0 e packet-mark "PING-CLIENTE" com banda bem alta, tipo 100M de down e up, assim, os pacotes ICMP não vão cair nos queues das interfaces PPPoE, porém, tem que cuidar que se deixar assim o cliente pode dar um flood ICMP na rede, mas para testes serve.

----------


## edmilson2709

> E você ja desabilitou o Keepalive timeout para testar se continuam caindo?


Foi o que fiz hoje, agora a pouco, desabilitei o keep alive, mas antes estava para 300 segundos.

----------


## edmilson2709

> Ja desabilitou o Keepalive timeout para testar?
> 
> Os que dão mensagem "user is already active" não vai resolver com isso, quando da essa mensagem, é o próprio roteador do CLIENTE que solicita a reconexão, não é a routerboard que desconecta ele. Esse problema pode ser tanto por problemas físicos na rede, pois alguns roteadores vao enviar pacotes keepalive mesmo que você desative no Mikrotik, e outros vão cair por perder pacotes ICMP (pings) que eles enviam para testar o túnel. Se você bloqueia ICMP, varios roteadores vão ficar caindo pois eles implementaram isso no software daqueles roteadores, pings para testar o túnel ao inves de mensagens keepalive do pppoe. Se você não bloqueia ICMP, faz umas regras de priorização de trafego ICMP dos clientes até a RB na routerboard. Para simples testes, você pode simplesmente marcar TODOS os pacotes ICMP vindos dos clientes com destino a RB com por exemplo "PING-CLIENTE", e criar uma regra no queue simple, acima das de PPPoE, com target 0.0.0.0/0 e packet-mark "PING-CLIENTE" com banda bem alta, tipo 100M de down e up, assim, os pacotes ICMP não vão cair nos queues das interfaces PPPoE, porém, tem que cuidar que se deixar assim o cliente pode dar um flood ICMP na rede, mas para testes serve.


Mas isto acontece não é em 1 ou 2 e sim 10 ou mais e bem dizer ao mesmo tempo ...
Eu arrumei isto do user already active, foi só ativar o one session por host e ficou normal. Problemas fisicos da rede creio que não seja, clientes com ping de 0-1 ms caem também, é muito improvavel que seja isto ...

----------


## andrecarlim

Cara não me lembro se já foi sugerido, mas vamos lá, se estiver usando a ultima versão do ROS, tente colocar um mais antiga, olhei e tenho uma 6.34.4 rodando a bastante tempo, outro teste seria pegar um setor menor de sua rede, para sair da dúvida, e colocar uma outra RB autenticando os PPPoEs, desconsidere se já fez isso, mas fica a ideia, veja aí o que da pra fazer e fala pra gente! Boa sorte!

Abs!

----------


## edmilson2709

> Cara não me lembro se já foi sugerido, mas vamos lá, se estiver usando a ultima versão do ROS, tente colocar um mais antiga, olhei e tenho uma 6.34.4 rodando a bastante tempo, outro teste seria pegar um setor menor de sua rede, para sair da dúvida, e colocar uma outra RB autenticando os PPPoEs, desconsidere se já fez isso, mas fica a ideia, veja aí o que da pra fazer e fala pra gente! Boa sorte!
> 
> Abs!


A outra que eu tinha uma 1100 AHX2 com 6.24 nela acontecia o problema, eu já atualizei o soft pensando que poderia ser isto, sobre o teste, uma coisa interessante que acontece é que, numa rede muito proxima, mas muito proxima mesmo de onde eu moro isto não ocorre, o que ela tem de diferente das outras? Absolutamente nada, sai um cabo da mesma forma que as outras e manda para ela, já no PTP que eu tenho para o outro POP e na rede cabeada isto ocorre, sendo que já troquei cabeamento, switchs, chequei a energia e nada ...

----------


## inquiery

Mas é exatamente assim que acontece nas redes que tem esse problema. É aleatório, sem explicação, espiritual, mágico e de natureza diabólica.

Quando você diz que "arrumou" a questão do "user already active", você quer dizer que fez parar de aparecer no log não é? Pois então, o problema por que gerava isso na realidade não deve ter sido resolvido. Se você desabilita o "One Session Per Host", quando o usuário reconecta pelo roteador dele ter "percebido" que caiu, ele simplesmente cria um túnel novo com a RB, e a RB não sabe que o antigo era do mesmo roteador e deixa ele lá. Esse túnel antigo, que ficou sem parceiro, vai ser fechado no futuro então por 2 motivos: ou por você ter keepalive timeout ativo e o uptime do túnel ja é maior que o tempo de keepalive timeout, ou se por você ter iddle timeout ativo e o tempo em que ele ja ta sem uso alcançou o iddle timeout. Você por acaso não tem interfaces PPPoE-Client com nomes tipo "<pppoe-cliente-1>", onde aquele "-1" não existe no login do cliente?

A rede estar em 1 ou 2, ou até mesmo 0ms de ping não quer dizer absolutamente nada nesse caso. Não quer dizer nem que a rede não tenha problemas físicas. Você pode ficar pingando MUITOS pacotes a 0ms 1ms e de repente PAH!, perdeu um pacote. Pois então, se as mensagens de Keepalive se perdem (mesmo numa rede de 1ms acontece), você ja vai ter desconexões. E tem os casos dos roteadores que inplemental PINGS, caso o PINGS seja perdido, o próprio roteador desconecta.

Fica com um PING aberto para um cliente qualquer, e outras janelas de PINGs para todas as antenas pela qual passa aquele cliente até chegar no seu concentrador. Verifica se não há nenhuma perda de pacote em nenhum enlace nos momentos da queda. Você pode ter que ficar observando durante varias quedas para ter uma ideia boa, pois uma perde de uma mensagem keepalive não quer dizer que o pacote ICMP vai ser perdido tb, mas tem chances de acontecer ao mesmo tempo.

Outra coisa, procure verificar se não existe a possibilidade de ter um loop na rede. As antenas Ubnt eu acho que só consideram pacotes IP naquele graficosinho de uso de banda na pagina inicial, e um loop gera um trafego ARP muito grande, fazendo varios enlaces próximos dar problemas.

----------


## edmilson2709

> Mas é exatamente assim que acontece nas redes que tem esse problema. É aleatório, sem explicação, espiritual, mágico e de natureza diabólica.
> 
> Quando você diz que "arrumou" a questão do "user already active", você quer dizer que fez parar de aparecer no log não é? Pois então, o problema por que gerava isso na realidade não deve ter sido resolvido. Se você desabilita o "One Session Per Host", quando o usuário reconecta pelo roteador dele ter "percebido" que caiu, ele simplesmente cria um túnel novo com a RB, e a RB não sabe que o antigo era do mesmo roteador e deixa ele lá. Esse túnel antigo, que ficou sem parceiro, vai ser fechado no futuro então por 2 motivos: ou por você ter keepalive timeout ativo e o uptime do túnel ja é maior que o tempo de keepalive timeout, ou se por você ter iddle timeout ativo e o tempo em que ele ja ta sem uso alcançou o iddle timeout. Você por acaso não tem interfaces PPPoE-Client com nomes tipo "<pppoe-cliente-1>", onde aquele "-1" não existe no login do cliente?
> 
> A rede estar em 1 ou 2, ou até mesmo 0ms de ping não quer dizer absolutamente nada nesse caso. Não quer dizer nem que a rede não tenha problemas físicas. Você pode ficar pingando MUITOS pacotes a 0ms 1ms e de repente PAH!, perdeu um pacote. Pois então, se as mensagens de Keepalive se perdem (mesmo numa rede de 1ms acontece), você ja vai ter desconexões. E tem os casos dos roteadores que inplemental PINGS, caso o PINGS seja perdido, o próprio roteador desconecta.
> 
> Fica com um PING aberto para um cliente qualquer, e outras janelas de PINGs para todas as antenas pela qual passa aquele cliente até chegar no seu concentrador. Verifica se não há nenhuma perda de pacote em nenhum enlace nos momentos da queda. Você pode ter que ficar observando durante varias quedas para ter uma ideia boa, pois uma perde de uma mensagem keepalive não quer dizer que o pacote ICMP vai ser perdido tb, mas tem chances de acontecer ao mesmo tempo.
> 
> Outra coisa, procure verificar se não existe a possibilidade de ter um loop na rede. As antenas Ubnt eu acho que só consideram pacotes IP naquele graficosinho de uso de banda na pagina inicial, e um loop gera um trafego ARP muito grande, fazendo varios enlaces próximos dar problemas.


Então o que eu poderia fazer para tentar solucionar tal problema? Sobre o cliente-1, aqui não tem isto, creio que por que sempre utilizei o one session per host, só vim desativar ontem para testes + o only one ativado, e hoje reativei por este problema do user already active ...

----------


## inquiery

Você não resolve nenhum problema marcando ou desmarcando a opção "One Session per Host". Você tem que fazer uma análise lógica, olha só.

Se você tem "One Session per Host" marcado, você vai ter mensagens de "was already connected" quando o CLIENTE identificar que a conexão cair e reconectar sem a ciencia da RB. A RB vai receber um pedido de conexão de um MAC que ja tem uma conexão ativa, então a RB derruba a antiga pra deixar só a nova; PORÉM caso você tenha o "Only One" ativo, isso não vai acontecer pois a RB não vai aceitar que um usuário já logado logue novamente.

Ou seja, caso "Only One" esteja ativado, e "Keepalive Timeout" e "Idle Timeout" desativado, a RB jamais vai reconhecer se aquela conexão parou de funcionar ou não, e se o cliente simplesmente pensou que desconectou e tentou reconectar sem antes enviar um PADT, ou se o PADT foi perdido (PADT é a mensagem PPPoE solicitando o fim da conexão), então aquele usuário não vai mais conseguir logar e vai ficar sem internet até que uma intervenção manual seja feita, deletando a conexão dele na RB.

Então, como no seu caso você tem "Keepalive" ativado, "One Session Per Host" e "Only One", o que vai acontecer é que, quando o cliente decidir que caiu e reconectar, ele não vai conseguir, e vai continuar tentando. Enquanto isso, a RB vai mandar as mensagens Keepalive dela para aquela conexão, que não vai responder pois o roteador do cliente ja descartou aquela conexão, e ta la tentando reconectar e não ta conseguindo pois a RB não aceita por causa do "Only One", mas depois de um tempo sem receber resposta Keepalive, a RB derruba aquela conexão e mostra no log "peer is not responding" e como o cliente está alucinado tentando reconectar, neste momento ele consegue, pq a RB derrubou a conexão que estava la e ja nao funcionava.


Então a única coisa que eu tenho falado aqui nesse post, e ja falei em outro sobre o mesmo problema, é pra cuidar o trafego ICMP. Bloquear ele gera problema com alguns modelos de roteadores. Agora se o ICMP ta rolando tranquilo, então as desconexões ocorrem por problemas físicos, de transmissão. Esses problemas físicos podem ser variados, quando envolve enlaces de radio esses problemas muitas vezes podem ser simplesmente considerados aceitáveis visto que em alguns casos é impossível resolver por total as perdas. Um loop em um ponto remoto da rede, no qual na ponta existe um enlace de radio para uma torre sua pode acabar gerando grande quantidade de trafego wireless que você simplesmente não ve em lugar nenhum, pois não é trafego IP, e por ai vai.

Pra concluir, você mexendo nas configurações o máximo que você vai fazer é mudar as mensagens que aparece no log, o problema que gera elas você nunca vai resolver mexendo nas configurações. Se você ja verificou TODA a rede e tem certeza que esta tudo certo e não tem problema nenhum, e isto esta acontecendo com muita frequência, verifique de novo pois não é que não exista o problema, é simplesmente você que não achou ainda (mas não é configuração na RB).

----------


## edmilson2709

> Você não resolve nenhum problema marcando ou desmarcando a opção "One Session per Host". Você tem que fazer uma análise lógica, olha só.
> 
> Se você tem "One Session per Host" marcado, você vai ter mensagens de "was already connected" quando o CLIENTE identificar que a conexão cair e reconectar sem a ciencia da RB. A RB vai receber um pedido de conexão de um MAC que ja tem uma conexão ativa, então a RB derruba a antiga pra deixar só a nova; PORÉM caso você tenha o "Only One" ativo, isso não vai acontecer pois a RB não vai aceitar que um usuário já logado logue novamente.
> 
> Ou seja, caso "Only One" esteja ativado, e "Keepalive Timeout" e "Idle Timeout" desativado, a RB jamais vai reconhecer se aquela conexão parou de funcionar ou não, e se o cliente simplesmente pensou que desconectou e tentou reconectar sem antes enviar um PADT, ou se o PADT foi perdido (PADT é a mensagem PPPoE solicitando o fim da conexão), então aquele usuário não vai mais conseguir logar e vai ficar sem internet até que uma intervenção manual seja feita, deletando a conexão dele na RB.
> 
> Então, como no seu caso você tem "Keepalive" ativado, "One Session Per Host" e "Only One", o que vai acontecer é que, quando o cliente decidir que caiu e reconectar, ele não vai conseguir, e vai continuar tentando. Enquanto isso, a RB vai mandar as mensagens Keepalive dela para aquela conexão, que não vai responder pois o roteador do cliente ja descartou aquela conexão, e ta la tentando reconectar e não ta conseguindo pois a RB não aceita por causa do "Only One", mas depois de um tempo sem receber resposta Keepalive, a RB derruba aquela conexão e mostra no log "peer is not responding" e como o cliente está alucinado tentando reconectar, neste momento ele consegue, pq a RB derrubou a conexão que estava la e ja nao funcionava.
> 
> 
> ...


Só recapitulando, não tenho o KeepAlive ativado, eu desativei o mesmo, o one session per host está ativado, e o only one também, quando ocorre a desconexão do pessoal, como já havia falado, são e locais completamente remotos, se fosse 1 ou 2 ou até umas 6 pessoas, tudo bem, mas são 10 ou mais, dá a mensagem peer is not responding, demora coisa de 3 minutos e relogam novamente, isto se dá de forma aleatoria, sem aparentemente motivo algum até por que se fosse ocorrer quando chovesse por exemplo eu poderia até deduzir que pudesse ser cabo ou coisa do tipo, mas não é o que acontece. Não entendo muito bem sobre o PPPoE, mas sei que colegas meus não tem tal problema, isto se deu após a minha troca de Hotspot para PPPoE, que ocorreu já faz uns meses.

----------


## lleonardo

> Mas é exatamente assim que acontece nas redes que tem esse problema. É aleatório, sem explicação, espiritual, mágico e de natureza diabólica.
> 
> Quando você diz que "arrumou" a questão do "user already active", você quer dizer que fez parar de aparecer no log não é? Pois então, o problema por que gerava isso na realidade não deve ter sido resolvido. Se você desabilita o "One Session Per Host", quando o usuário reconecta pelo roteador dele ter "percebido" que caiu, ele simplesmente cria um túnel novo com a RB, e a RB não sabe que o antigo era do mesmo roteador e deixa ele lá. Esse túnel antigo, que ficou sem parceiro, vai ser fechado no futuro então por 2 motivos: ou por você ter keepalive timeout ativo e o uptime do túnel ja é maior que o tempo de keepalive timeout, ou se por você ter iddle timeout ativo e o tempo em que ele ja ta sem uso alcançou o iddle timeout. Você por acaso não tem interfaces PPPoE-Client com nomes tipo "<pppoe-cliente-1>", onde aquele "-1" não existe no login do cliente?
> 
> A rede estar em 1 ou 2, ou até mesmo 0ms de ping não quer dizer absolutamente nada nesse caso. Não quer dizer nem que a rede não tenha problemas físicas. Você pode ficar pingando MUITOS pacotes a 0ms 1ms e de repente PAH!, perdeu um pacote. Pois então, se as mensagens de Keepalive se perdem (mesmo numa rede de 1ms acontece), você ja vai ter desconexões. E tem os casos dos roteadores que inplemental PINGS, caso o PINGS seja perdido, o próprio roteador desconecta.
> 
> Fica com um PING aberto para um cliente qualquer, e outras janelas de PINGs para todas as antenas pela qual passa aquele cliente até chegar no seu concentrador. Verifica se não há nenhuma perda de pacote em nenhum enlace nos momentos da queda. Você pode ter que ficar observando durante varias quedas para ter uma ideia boa, pois uma perde de uma mensagem keepalive não quer dizer que o pacote ICMP vai ser perdido tb, mas tem chances de acontecer ao mesmo tempo.
> 
> Outra coisa, procure verificar se não existe a possibilidade de ter um loop na rede. As antenas Ubnt eu acho que só consideram pacotes IP naquele graficosinho de uso de banda na pagina inicial, e um loop gera um trafego ARP muito grande, fazendo varios enlaces próximos dar problemas.


Em relação ao ping, gostaria de contribuir dizendo que muitas vezes vc não acha um problema na rede utilizando o ping com seu tamanho padrão (32 bytes no windows e 64 bytes no linux). Muitas das vezes vc não perde um pacote sequer "pingando" dessa forma, porém quando você aumenta o tamanho do pacote, começam as perdas e assim fica mais fácil de descobrir.

----------


## xyunamx

Cara, sei q vc vai dizer q n é... mas tenho mais num total de meus clientes somados tenho mais de 500RBs autenticando PPPoE, e isso de "a rb esta desconectando o cliente" não acontece...

O que acontence é a conexao entre o cliente e o servidor cair...(um ponto a ponto, o wirelles do cliente... )

"peer is not responding" significa que o cliente parou de responder...

Verifica ai na sua rede, todos os seus ponto a ponto... Tempo ligado, tempo conectado
verifique tambem os aps onde os clientes conectam, se n esta reiniciando e se o cliente n esta desconectando....

OBS:
Vc tem algum programa q monitora sua rede? 
Se tiver muda o tempo de monitoramento pra tipo 1 teste a cada 2 ou 3 segundos 
e ficar off com 3 percas consecutivas...

Se n tiver instala ai pelo menos um Dude....

----------


## VAGNER

> Bem, pelo jeito consegui resolver, porém todas as pessoas com o roteador Greatek WR-1500L estão com problemas, o roteador conecta na minha RB e tudo porém na casa do cliente ele tenta conectar no wifi e o roteador não entrega o ip dele mesmo para a pessoa, quando retiro o cabo da internet do roteador, funciona, quando coloco, reinicio e tento conectar, só "identificando", não utilizo mais hotspot nesse sistema, separei cada porta, antes utilizava uma bridge, já não estou utilizando mais, DHCP server já retirei, a nova CCR está puramente PPPOE. Engraçado que pessoas com os roteadores TP Link acessam normalmente, já mudei MTU, MRU, MRRU dos PPPOE Servers, já mudei o MTU das portas e nada surtiu efeito, simplesmente conecta, porém não funciona, agora se eu pegar o cabo, retirar, desligar o roteador, religar ele sem o cabo, conectar no wifi, e em seguida colocar o cabo da internet, os dispositivos funcionam, e ficam com internet! Isto não acontecia na antiga configuração, já fiz o teste de pegar um na bancada e ligar diretamente na RB, ele funcionou tranquilamente, conectei normalmente e ficou com internet, levei ele até a casa de um cliente, chegando lá, coloquei ele e não funcionou.


Manos corajosos trabalhando com roteador greatek.kkkk vai de drink dir610

Enviado via SM-J500M usando UnderLinux App

----------


## alyssonmeister

Estou com o mesmo problema pessoal...

Enviado via SM-T116BU usando UnderLinux App

----------


## alyssonmeister

> Estou com o mesmo problema pessoal...
> 
> Enviado via SM-T116BU usando UnderLinux App


Tenho apenas 30 clientes na minha rede. Toda cabeada nenhuma antena.

Enviado via SM-T116BU usando UnderLinux App

----------


## azul

Aqui foi um cabo de cliente com problema

Enviado via XT1069 usando UnderLinux App

----------


## wesleylima

quando aconteceu comigo era versão da rb

----------


## muttley

Eu tbm tenho esse problemo do pppoe desconectar os clientes! 
Mas estou desconfiado da versão do firmware aqui nos nanoloco dos meus clientes. 
.
XS2.ar2316.v3.6.1.4866.110330.1244 nanoloco 2
XS2.ar2316.v4.0.4.5074.150724.1340 bullet 2
XM.v5.3.5 nanoloco m2
XS2.ar2316.v4.0.4.5074.150724.1340 nanostation 2 - 10dbi
XS2.ar2316.v3.5.4494.091109.1451 nanoloco 2
cpe tplink
XS2.ar2316.v3.6.1.4866.110330.1244
XS2.ar2316.v4.0.4.5074.150724.1340 nanostation 2 - 10 dbi





XM.v5.3.5 nanoloco m2 - Este aqui tbm cai. E eu só tenho 3 nanos M2 na minha rede.
E os outros estao off, vou esperar os clientes conectar pra eu da uma olhada.
.
XS2.ar2316.v4.0.4.5074.150724.1340 nanoloco2 - Estou achando que versão 4 cai mais!
XS2.ar2316.v4.0.4.5074.150724.1340 nanostation 2
.
Versao 3 deve se mais estavel

----------


## Luspmais

> Entao to migrando tem 20d para o CNT, financeiro até ja passo pelo treimando acho meio dificil ela querer migrar dinovo. E tbm o custo de implantaçao ja foi pago


Então amigo, você está usando o accel-ppp, resolveu os problemas ?

----------


## leosmendes

> Correto. Para usar o accel-ppp tem que instalar em um servidor com Linux. Tem uma galera usando Ubuntu instalado em Dell r210 e diz que fica perfeito, eu acredito. Contudo uso servidores HP de todo tipo, instalado com Debian e pra mim é uma experiência inigualável! Recentemente comecei a usar placas de rede Intel I350-T4, e elas impressionam pela estabilidade e confiabilidade!
> 
> Enviado via XT1563 usando UnderLinux App


ola boa noite, vc esta usando placa com chipset i350 com mikrotik?

----------


## andrecarlim

> ola boa noite, vc esta usando placa com chipset i350 com mikrotik?


Nunca usei Mikrotik em produção sobre hardware x86. Eu só uso Mikrotik para funções que não demandem muito processamento ou... mantenho estruturas que tinham Mikrotik, até o limite de cada caso. Não me lembro de ter visto esse cenário. Mas acho que não compensa, essas CCRs são boas, não acho que com hardware x86 você vai ter melhor aproveitamento, até porque um dos pontos fortes desses equipamentos "embarcados" é o consumo de energia...

----------


## avatar52

MikroTik x86 é uma piada, mesmo tendo MultiCPU. Hoje tem o CHR, que é 64 bits.

----------


## andrecarlim

Só explicando o possível problema, em situações onde você tem muitas rajadas de conexões, e por acaso estiver com a conntrack ativa, a cada inclusão/exclusão de uma nova interface, o route-engine tem que recalcular toda a conntrack... Aí já viu né... É fácil contornar isso, desativa a conntrack no teu BRAS e deixa o nat para uma caixa melhor...

----------


## wld.net1

> Só explicando o possível problema, em situações onde você tem muitas rajadas de conexões, e por acaso estiver com a conntrack ativa, a cada inclusão/exclusão de uma nova interface, o route-engine tem que recalcular toda a conntrack... Aí já viu né... É fácil contornar isso, desativa a conntrack no teu BRAS e deixa o nat para uma caixa melhor...


só lembrando se tiver nat com a contrack desativa não navega

----------


## fhayashi

Por isso o Nat será feito em outra caixa

----------

