Problema com RB x Rocket

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

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


Enviado do meu iPhone usando Tapatalk

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%

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

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

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

---

Citação:

---

Postado originalmente por lleonardo

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.

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

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.

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.

Citação:

---

Postado originalmente por fhayashi

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.

Citação:

---

Postado originalmente por rubem

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

Citação:

---

Postado originalmente por Mti

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

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.

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.

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.

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