+ Responder ao Tópico



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



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

  3. Citação Postado originalmente por edmilson2709 Ver Post
    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

  4. Citação Postado originalmente por edmilson2709 Ver Post
    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

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

  6. Citação Postado originalmente por andrecarlim Ver Post
    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 Ver Post
    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...

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

  8. Citação Postado originalmente por andrecarlim Ver Post
    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.

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

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






Tópicos Similares

  1. Pppoe mikrotik deslogando pessoas aleatoriamente
    Por edmilson2709 no fórum Mikrotik
    Respostas: 60
    Último Post: 09-05-2017, 21:25
  2. 2 Concentrador PPPOE - Mikrotik
    Por Luciana-Martins no fórum Redes
    Respostas: 2
    Último Post: 15-04-2008, 12:37
  3. Respostas: 7
    Último Post: 30-01-2008, 11:15
  4. Respostas: 2
    Último Post: 24-11-2007, 03:08
  5. Respostas: 1
    Último Post: 07-04-2006, 15:33

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L