PPPOE Mikrotik deslogando pessoas aleatoriamente

[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.


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).

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