Gateway Monitoring está travando
-
Ressucitando o tópico, estou com o mesmo problema em um dos servidores que uso FailOver. Meu link principal é adsl gvt de 35mb, o ip monitorado está o dns do google 8.8.8.8. De vez em quando o apinger pára, fazendo acionar o failover errado, mesmo eu estando com gvt à 100%. Meu link de reserva é uma Oi com pppoe direto no pfsense.
Se reinicio o seriço do apinger em Status>Services>apinger "clico no restart service" tudo volta ao normal por um tempo.Alguém tem ideia do que possa ser isso?
-
Ressucitando o tópico, estou com o mesmo problema em um dos servidores que uso FailOver. Meu link principal é adsl gvt de 35mb, o ip monitorado está o dns do google 8.8.8.8. De vez em quando o apinger pára, fazendo acionar o failover errado, mesmo eu estando com gvt à 100%. Meu link de reserva é uma Oi com pppoe direto no pfsense.
Se reinicio o seriço do apinger em Status>Services>apinger "clico no restart service" tudo volta ao normal por um tempo.Alguém tem ideia do que possa ser isso?
Eu ia abrir uma thread agora sobre isso.
Estou com o mesmo problema. Em algum momento um de meus links é marcado como offline (Quando na verdade não está)
Estou utilizando a versão 2.1.5 amd64E os logs não informam muita coisa
pinger: ALARM: GW_VIRTUA(208.67.222.222) *** down ***
Sep 26 13:40:48 apinger: ALARM: GW_GVT(8.8.4.4) *** down ***
Sep 26 14:00:27 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** down ***
Sep 26 14:06:12 apinger: SIGHUP received, reloading configuration.
Sep 26 14:06:12 apinger: alarm canceled (config reload): GW_GVT(8.8.4.4) *** down ***
Sep 26 14:07:25 apinger: ALARM: GW_GVT(8.8.8.8) *** down ***
Sep 26 14:08:37 apinger: alarm canceled: GW_GVT(8.8.8.8) *** down ***
Sep 26 16:09:17 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:09:36 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:09:48 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:10:06 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:10:30 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:11:21 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:11:30 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:12:47 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:13:29 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:13:58 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:14:22 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:14:51 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:15:02 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:16:18 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:16:34 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:23:00 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:23:13 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:23:26 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:23:48 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 16:23:57 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 17:09:28 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 17:09:49 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 17:24:00 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 26 17:24:28 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 27 01:09:15 apinger: ALARM: GW_GVT(8.8.8.8) *** down ***
Sep 27 01:09:17 apinger: alarm canceled: GW_GVT(8.8.8.8) *** down ***
Sep 27 12:04:34 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 27 12:04:46 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 27 17:48:04 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 27 17:49:12 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 28 09:18:16 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 28 09:18:31 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 28 09:48:41 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 28 09:49:07 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 28 10:52:51 apinger: ALARM: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 28 10:53:53 apinger: alarm canceled: GW_VIRTUA(208.67.222.222) *** delay ***
Sep 28 14:08:39 apinger: ALARM: GW_GVT(8.8.8.8) *** down ***
Sep 29 11:26:47 apinger: Exiting on signal 15.
Sep 29 11:26:48 apinger: Starting Alarm Pinger, apinger(54247)o Link simplesmente cai e não volta.
-
Sim victorfmaraujo, problema sério pra quem usa FailOver né :-[
Mas ficamos no aguardo sobre uma solução.
Será que se rodar um cron pra dar restart no seviço de 2 em dois minutos não contorna o problema por enquanto até sair uma solução definitiva? -
Sim victorfmaraujo, problema sério pra quem usa FailOver né :-[
Mas ficamos no aguardo sobre uma solução.
Será que se rodar um cron pra dar restart no seviço de 2 em dois minutos não contorna o problema por enquanto até sair uma solução definitiva?
[/quote]fiz isso e não resolveu :(
-
fiz isso e não resolveu :(
tamo na merda então…...ahurehuahuehuhaue
-
Tente utilizar ips da própria operadora, de um tracert e verifica um router no caminho de cada link. Ips google tem ICMP controlado.
-
Tente utilizar ips da própria operadora, de um tracert e verifica um router no caminho de cada link. Ips google tem ICMP controlado.
caraca man….não sabia disso não.
Troquei agora o monitoring para o ip 177.97.164.1 , que acredito que seja o primeiro gateway que atende a minhão região da GVT segundo o tracert. -
santello, mudei os ips ontem e até agora tá funfando certinho, vamos ver se não dá pau de novo, se resolver mesmo já fica aqui meu agradecimento pela dica ;D :) ;D :)
-
santello, mudei os ips ontem e até agora tá funfando certinho, vamos ver se não dá pau de novo, se resolver mesmo já fica aqui meu agradecimento pela dica ;D :) ;D :)
Não deu, agora falha menos, mas quando o monitoring pára ele não volta mais à funcionar, só indo na mão mesmo e reiniciando o serviço do apinger :-[
-
solução bem boqueta para o apinger ficar reinciando de 5 em 5 mim.
pkill -15 apinger | ping -c 5 localhost | /usr/local/sbin/apinger -c /var/etc/apinger.conf
configurar no cron.
-
Tenho dois links monitorados pelo apinger, pf versão 2.1.5-RELEASE (amd64).
Funcionamento normal no meu caso.
-
solução bem boqueta para o apinger ficar reinciando de 5 em 5 mim.
pkill -15 apinger | ping -c 5 localhost | /usr/local/sbin/apinger -c /var/etc/apinger.conf
configurar no cron.
Henriquejensen, o comando é pkill ou kill ?
-
pelo oque eu segui nesse tópico é pkill mesmo https://forum.pfsense.org/index.php?topic=69533.30
No manual do linux pkill seria isso:
pkill will send the specified signal (by default SIGTERM) to each process instead of listing them on stdout.
-
Sabe o que é mais esquisito?
Em meu cliente onde esse problema está ocorrendo possuo 2 Pfsenses configurados com CARP
nos dois ocorre esse problema. Não sei mais o que fazer.
-
Chato isso né cara, um serviço tão básico essencial pra quem trabalha com multiplos links dando problema desse jeito :-[
-
Chato isso né cara, um serviço tão básico essencial pra quem trabalha com multiplos links dando problema desse jeito :-[
[/quote]Experimente instalar o pacote Service Watchdog. Ele monitora os daemons e reinicia caso eles travem e envia uma notificação por email.
Lembre-se de configurar o envio de emails em System > advanced > notifications.
-
Experimente instalar o pacote Service Watchdog. Ele monitora os daemons e reinicia caso eles travem e envia uma notificação por email.
Lembre-se de configurar o envio de emails em System > advanced > notifications.
Obrigado pela dica victorfmaraujo, mas o problema é que o serviço apinger continua funcionando mas detectando o gateway como offline, creio eu que o Watchdog nesse caso não vai surtir efeito, mas mesmo assim vou baixar e testar ;)
-
Fez o teste colocando o IP da sua interface no monitor?
Lembrando que não é regra, mas pode acontecer do gateway default estar impossibilitando a rota para tal ip, tente colocar 4.2.2.2 em uma interface e 4.2.2.1 em outra, caso falhe, adicione rotas estáticas para garantir que a saída vai ser pelo gw correto.
-
Fez o teste colocando o IP da sua interface no monitor?
Lembrando que não é regra, mas pode acontecer do gateway default estar impossibilitando a rota para tal ip…
Ja testei colocando ip do dns do google, openDNS e ip da própria GVT (no caso o ip mais proximo do dslam seguindo o tracert), mesmo assim do nada o ip monitorado fica em estado offline, aí reinicia o serviço do apinger e volta tudo ao normal :(
-
Continuo com o mesmo problema após atualizar da versão 2.1.4, depois pra 2.1.5 e agora na 2.2 :-[
Será que pode ser as placas de rede?
O gateway fica como offline, mesmo assim continuo acessando o pfsense através deste mesmo link, aí vou na aba system> Routing> e clico em restart apinger service e tudo volta ao normal >:(Alguma idéia?