+ Responder ao Tópico



  1. Na empresa que trabalho, possuímos um cliente que é uma fazenda e tem sua própria torre, nossa internet chega lá através de um ponto a ponto, dois Rockets.
    Na fazenda sempre funcionou da seguinte forma, o Rocket recebe o link e o cabo vai para dentro da sala onde tem o Rack e lá ele passa por um protetor de surto Ubiquiti, a fonte e disso vai para uma RB750, dela sai um cabo para um computador que é servidor deles.

    Sempre funcionou ok assim, mas após um raio que queimou tanto a RB e o Rocket e mesmo após trocarmos tudo incluindo cabo novo (blindado), protetor de surto, RB, tudo mesmo, começou um problema muito chato que é o seguinte:
    Em um intervalo de tempo aleatório, as vezes dias, as vezes horas, a Rb 750 trava e perdemos o acesso e o cliente fica sem internet, e se reiniciarmos o Rocket daqui ela volta normalmente como se nada tivesse acontecido.
    Para tentar resolver trocamos novamente a RB por uma novinha, trocamos o Cabo novamente e também a rocket por outra nova e o problema persiste.

    Também foi tentado travar a negociação da porta Eth da RB para 100Mbs e não deixar na Auto. Unica coisa que não foi trocado foi: Pigtails e a antena.

    Alguém ja enfrentou algo parecido? Qual a solução no seu caso? Deem dicas, agradeço desde já.

  2. Faltou você analisar o enlace: no momento que seu tráfego cai, como está o CCQ do enlace?


    Enviado do meu iPhone usando Tapatalk



  3. Então, o Enlace está perfeito, não cai ccq, sinal está ótimo e nem é tão longe, tanto que o acesso à Rocket fica normal. O problema é que a RB que vem "depois" dele que simplesmente trava, não comunica mais. Como se tivesse tirado o cabo da porta Eth2 dela. E reiniciando o Rocket ela volta a comunicar com ele.
    o CCQ não fica a abaixo de 95%

  4. Desculpa, disse não estar tão longe, na verdade são 36Km de distância. o Sinal é de -69dBm, Ruído de fundo a -99dBm, e CCQ fica sempre na média de 95% mesmo quando a RB cai.
    A outra ponta do Enlace é uma Rocket com Base Station, mas só tem essa fazenda conectada como cliente, nada mais.

    O mais estranho é que antes de ter queimado os equipamentos num raio tempos atrás, nunca houve nenhum problema, era sem dor de cabeça 24/7



  5. Esse sinal de -69dbm não é dos melhores, mas não acha que seria muito melhor colocar uma dish no lugar dessa BaseStation?
    Essa antena não foi projetada pra essa finalidade.

    Citação Postado originalmente por natalpj Ver Post
    Desculpa, disse não estar tão longe, na verdade são 36Km de distância. o Sinal é de -69dBm, Ruído de fundo a -99dBm, e CCQ fica sempre na média de 95% mesmo quando a RB cai.
    A outra ponta do Enlace é uma Rocket com Base Station, mas só tem essa fazenda conectada como cliente, nada mais.

    O mais estranho é que antes de ter queimado os equipamentos num raio tempos atrás, nunca houve nenhum problema, era sem dor de cabeça 24/7

  6. Citação Postado originalmente por lleonardo Ver Post
    Esse sinal de -69dbm não é dos melhores, mas não acha que seria muito melhor colocar uma dish no lugar dessa BaseStation?
    Essa antena não foi projetada pra essa finalidade.
    Bom a gente está pensando em trocar realmente e fazer um ponto a ponto de fato, porque realmente não é o modelo mais correto. Mas será que é esse o problema que leva a perder totalmente o acesso da RB?
    Mas com certeza estamos planejando em mudar para melhorar o enlace.



  7. Não sei se é esse o caso aí, mas quando tem data rate alto demais pro nível de sinal (-69dBm é sinal excelente pra MCS0, mas é lixo pra MCS15) o uso de CPU sobe, o chipset de RF aquece muito porque fica reenviando pacote perdido, e as vezes algum módulo do software trava mesmo. Com MK já tive muito isso, com UBNT não porque é um firware capado que não permite ver muita coisa, mas o hardware é praticamente o mesmo (Mesmos chipsets em UBNT e MK) então deve ter efeitos similares no software.

    (Tipo quando o Windows tem tanto lixo rodando, que ao plugar uma impressora nova parece que a porta USB tem defeito e não reconhece, é simples questão de processador afogado processando outras coisas)

    PTP ruim gera mais calor em chipset, mais uso de CPU as vezes (O chipset de RF é separado da CPU, por isso é bom ver o calor do chipset de RF quando possível), até mais uso de Ram, porque muito pacote precisa ser reenviado 2 ou 3x até que chegue intacto. Essa info do CCQ ajuda, mas teria que ver qual o CCQ durante tráfego de dados. Se as vezes o cliente navega consumindo 4 ou 5Mbps por alguns minutos, teria que manter uma troca de arquivos fixa nessa velocidade (Gosto do SuperCopier 2.2 beta no Windows porque tem limitador de velocidade) e então ver o ping real (Ping com pacote de 1400 bytes), o ack timeout real que pega nesse momento (Se estiver em auto) e o CCQ nesse momento, porque quando não tem tráfego no ptp, o CCQ se baseia nos poucos pacotes de sincronia de poucos bytes de tamanho, é situação bem diferente de quando está trafegando muita coisa (Centenas de pacotes de 1500 bytes por segundo). É tipo motor, de carro ou moto, sem marcha engatada você mal toca no acelerador e a rotação sobe, só que... hora que engata marcha e precisa empurrar o peso enorme do veículo, aí a rotação demooooora a subir, então sempre tem que medir os fatores com carga, nunca em aberto (Incrível como isso vale pra tanta coisa, eletrônica, mecânica, telecom, e semana passada notamos que até na nutrição animal isso vale, o cálculo teórico é lindo, mas criando em bando eles brincam entre si, brigam até na hora de comer, de modo que despendem muito mais energia que o cálculo metabólico teórico do animal sossegado dentro de baia de laboratório).

  8. Pelo que entendi, a RB não está travando certo?

    Você perde o acesso, mas reiniciando o rocket que está na basestation a comunicação volta.

    Deve ser problema no enlace mesmo.



  9. Ja vi esse problema e era o enlace ruim acontecia algumas perdas de pacote e o roteador do cliente mostrava conectado porem não trafegava, era so reinicia que voltava a funfa normal por um período, foi ai que percebi o roteador ficava com conecçao presa, a rb entedia que estava conectado e nao deixava o cliente autenticar novamente. melhoramos o enlace nao apresentou mais o problema.

  10. Citação Postado originalmente por fhayashi Ver Post
    Pelo que entendi, a RB não está travando certo?

    Você perde o acesso, mas reiniciando o rocket que está na basestation a comunicação volta.

    Deve ser problema no enlace mesmo.
    Corrigindo: quando eu reinicio o Rocket que está no cliente, que usa uma dish. O da basestation que fica na torre nem precisa mexer.



  11. Citação Postado originalmente por rubem Ver Post
    Não sei se é esse o caso aí, mas quando tem data rate alto demais pro nível de sinal (-69dBm é sinal excelente pra MCS0, mas é lixo pra MCS15) o uso de CPU sobe, o chipset de RF aquece muito porque fica reenviando pacote perdido, e as vezes algum módulo do software trava mesmo. Com MK já tive muito isso, com UBNT não porque é um firware capado que não permite ver muita coisa, mas o hardware é praticamente o mesmo (Mesmos chipsets em UBNT e MK) então deve ter efeitos similares no software.

    (Tipo quando o Windows tem tanto lixo rodando, que ao plugar uma impressora nova parece que a porta USB tem defeito e não reconhece, é simples questão de processador afogado processando outras coisas)

    PTP ruim gera mais calor em chipset, mais uso de CPU as vezes (O chipset de RF é separado da CPU, por isso é bom ver o calor do chipset de RF quando possível), até mais uso de Ram, porque muito pacote precisa ser reenviado 2 ou 3x até que chegue intacto. Essa info do CCQ ajuda, mas teria que ver qual o CCQ durante tráfego de dados. Se as vezes o cliente navega consumindo 4 ou 5Mbps por alguns minutos, teria que manter uma troca de arquivos fixa nessa velocidade (Gosto do SuperCopier 2.2 beta no Windows porque tem limitador de velocidade) e então ver o ping real (Ping com pacote de 1400 bytes), o ack timeout real que pega nesse momento (Se estiver em auto) e o CCQ nesse momento, porque quando não tem tráfego no ptp, o CCQ se baseia nos poucos pacotes de sincronia de poucos bytes de tamanho, é situação bem diferente de quando está trafegando muita coisa (Centenas de pacotes de 1500 bytes por segundo). É tipo motor, de carro ou moto, sem marcha engatada você mal toca no acelerador e a rotação sobe, só que... hora que engata marcha e precisa empurrar o peso enorme do veículo, aí a rotação demooooora a subir, então sempre tem que medir os fatores com carga, nunca em aberto (Incrível como isso vale pra tanta coisa, eletrônica, mecânica, telecom, e semana passada notamos que até na nutrição animal isso vale, o cálculo teórico é lindo, mas criando em bando eles brincam entre si, brigam até na hora de comer, de modo que despendem muito mais energia que o cálculo metabólico teórico do animal sossegado dentro de baia de laboratório).
    Obrigado por essa resposta, muito bem fundamentada. Farei testes

  12. Citação Postado originalmente por Mti Ver Post
    Ja vi esse problema e era o enlace ruim acontecia algumas perdas de pacote e o roteador do cliente mostrava conectado porem não trafegava, era so reinicia que voltava a funfa normal por um período, foi ai que percebi o roteador ficava com conecçao presa, a rb entedia que estava conectado e nao deixava o cliente autenticar novamente. melhoramos o enlace nao apresentou mais o problema.
    Parece muito com meu caso



  13. Acredite ou nao, outro dia um cliente estava assim na rede cabeada conectado mas nao navegava, troquei ate Switch antes do mesmo e nada de resolver, so foi trocar o rj45 e tudo normalizou.

  14. Voltei aqui para informar que nenhuma das dicas funcionou.
    -Trocamos para um ponto a ponto, duas rockets com antena Oiw de 34Dbi (sem shield ou radome mesmo, é área rural), problema de enlace foi totalmente solucionado, ccq sempre acima de 98% mesmo com tráfego e com teste de velocidade. Não resolveu. E tem o fato de que usamos uma torre mais próxima para o enlace.
    -Trocamos novamente conectores RJ45 (um cabo blindado recém colocado e da mesma marca que usamos em todas torres), trocamos por conectores normais pois ja tivemos problema com conectores blindados que vieram meio oxidados... Não resolveu.
    -Troquei todos os pathcords por aqueles Cat5e já feitos... Não resolveu
    -Desconfiava da régua de tomada do rack da fazenda estar tendo mal contato por ser meio antiga e realmente tive mal contato ao tentar carregar meu notebook, troquei por uma novinha, padrão novo. não resolveu (Obs: é ligada à um nobreak profissional deles, com aterramento e tudo mais)
    -Sobre a dica que o @rubem deu sobre MCS, a gente já aplica desde que li o tópico https://under-linux.org/showthread.php?t=174554&page=4 Meses atrás, e ali está e estava travado em MCS8

    A topologia no local é: Rocket > (protetor de surto, fonte) > RB750 > Servidor deles que usa FreeBSD (nunca mexemos nele).
    O problema é: Em um intervalo de tempo variável (a ultima vez foram 11 horas) perdemos o acesso à RB750, ela "cai" no monitoramento do Zabbix e não deixa acessar, reiniciando o Rocket (no qual o acesso está normal), a RB volta como se nada tivesse acontecido e assim vai novamente por mais algumas horas até perder acesso novamente.

    Hoje recebi uma informação nova e meio inquietante, os rapazes da outra empresa que fornece internet para a fazenda também (para redundância e tal) estavam lá mexendo no link deles, e ao conversar com eles me contaram que estão enfrentando o mesmo e exato problema. São redes diferentes, são radios diferentes (powerbeam m400), eles usam painel solar, e ocorre o mesmo exato problema. Mas com eles começou a menos tempo, até por que o principal link é o nosso.



  15. Ah, foi trocado pela 4ª vez a RB750, e meu Chefe fez o downgrade do firmware para um que um amigo nosso que trabalha na Teleturbo disse ser mais estável. Infelizmente eu não lembro a versão agora, amanhã falarei.

    Há alguma possibilidade de o servidor deles estar causando o travamento das RB's? Os outros técnicos também levantaram essa possibilidade.

  16. Acho difícil o servidor estar causando esse tipo de travamento na conexão (note que você precisa reiniciar o ponto a ponto e não a RB750, então ela não está travando), mas nada que os logs não te ajudem.


    Enviado do meu iPhone usando UnderLinux






Tópicos Similares

  1. Problema com RB 433 e r52h.
    Por alissonwm no fórum Redes
    Respostas: 11
    Último Post: 30-06-2009, 17:28
  2. problema com Rb 433
    Por ederamboni no fórum Redes
    Respostas: 13
    Último Post: 28-11-2008, 22:47
  3. Problema com RB 153
    Por juliohalima no fórum Redes
    Respostas: 1
    Último Post: 03-10-2008, 15:19
  4. Problemas com rb 433
    Por correarct no fórum Redes
    Respostas: 2
    Último Post: 31-07-2008, 09:06
  5. Problemas com RB+Setoriais
    Por cooperrj no fórum Redes
    Respostas: 7
    Último Post: 17-05-2008, 17:13

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L