Re: PPPOE Mikrotik deslogando pessoas aleatoriamente
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.
Re: PPPOE Mikrotik deslogando pessoas aleatoriamente
Citação:
Postado originalmente por
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.
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 ...
Re: PPPOE Mikrotik deslogando pessoas aleatoriamente
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).
Re: PPPOE Mikrotik deslogando pessoas aleatoriamente
Citação:
Postado originalmente por
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).
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.
Re: PPPOE Mikrotik deslogando pessoas aleatoriamente
Citação:
Postado originalmente por
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.
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.