Só para alimentar mas a discussão, esperamos que o IPoE venha para
Enviado via XT1563 usando UnderLinux App
Só para alimentar mas a discussão, esperamos que o IPoE venha para
Enviado via XT1563 usando UnderLinux App
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
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.
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.
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.
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.
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.
Tenta setar ip manual
Enviado via LG-D805 usando UnderLinux App
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:
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...
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!
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.
E você ja desabilitou o Keepalive timeout para testar se continuam caindo?
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 ...
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 ...