PPPOE Mikrotik deslogando pessoas aleatoriamente

Citação:

---

Postado originalmente por andrecarlim

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.

Citação:

---

Postado originalmente por edmilson2709

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.

Citação:

---

Postado originalmente por TsouzaR

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.

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

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

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

Enviado via XT1563 usando UnderLinux App

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.

Citação:

---

Postado originalmente por 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.

---

Vai gastar dinheiro e tempo atoa.

Citação:

---

Postado originalmente por JonasMT

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

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

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.

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

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

Citação:

---

Postado originalmente por 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

---

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.

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

Enviado via LG-D805 usando UnderLinux App

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

Citação:

---

Postado originalmente por 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

---

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

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.

Citação:

---

Postado originalmente por leonardoads

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?

Citação:

---

Postado originalmente por 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

---

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

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?

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

Citação:

---

Postado originalmente por edmilson2709

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

Citação:

---

Postado originalmente por 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?

---

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

Enviado via GT-I9515L usando UnderLinux App

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.

Citação:

---

Postado originalmente por 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

---

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.

Citação:

---

Postado originalmente por 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.

---

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

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.

Citação:

---

Postado originalmente por 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!

---

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.

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

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

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

Citação:

---

Postado originalmente por 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...

---

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.

Citação:

---

Postado originalmente por andrecarlim

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.

Citação:

---

Postado originalmente por inquiery

...
...

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.

Citação:

---

Postado originalmente por TsouzaR

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.

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

Citação:

---

Postado originalmente por leonardoads

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

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:

Anexo 64538Anexo 64539Anexo 64540Anexo 64541Anexo 64542

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.

Citação:

---

Postado originalmente por 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.

---

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

Citação:

---

Postado originalmente por 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)?

---

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.

Citação:

---

Postado originalmente por inquiery

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.

Citação:

---

Postado originalmente por 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.

---

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!

Citação:

---

Postado originalmente por 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!

---

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