![](https://secure.gravatar.com/avatar/52482c5f8de61368e37aadec4da64cc6.jpg?s=120&d=mm&r=g)
Hello,
We use the stable licensed SVN version of Observium.
Since the beginning of April, we have several times a day those messages:
2016-04-07 12:37:24 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-04-07 06:35:19 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-04-07 00:41:10 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. (... more of the same ...) 2016-05-25 12:37:02 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-05-25 06:36:33 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-05-25 00:38:06 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged.
Routers (we have this on several) are Juniper MX5. Analysis of the logs reveals that nothing has moved on the bgp side, no flap, no event, peers are steady.
I've tried to look into what pushes Observium to emit those messages, but I'm a bit lost. Any ideas ?
Thanks, Arnaud.
![](https://secure.gravatar.com/avatar/0fa97865a0e1ab36152b6b2299eedb49.jpg?s=120&d=mm&r=g)
Run the bgp-peers poller module for that host in debugging mode:
./poller.php -h <device_id> -m bgp-peers -d
Sounds like it may be a SQL update issue causing it to retry the update each time.
Adam.
Sent from BlueMail
On 25 May 2016, 12:23, at 12:23, Arnaud Launay asl@launay.org wrote:
Hello,
We use the stable licensed SVN version of Observium.
Since the beginning of April, we have several times a day those messages:
2016-04-07 12:37:24 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-04-07 06:35:19 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-04-07 00:41:10 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. (... more of the same ...) 2016-05-25 12:37:02 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-05-25 06:36:33 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged. 2016-05-25 00:38:06 edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged.
Routers (we have this on several) are Juniper MX5. Analysis of the logs reveals that nothing has moved on the bgp side, no flap, no event, peers are steady.
I've tried to look into what pushes Observium to emit those messages, but I'm a bit lost. Any ideas ?
Thanks, Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/52482c5f8de61368e37aadec4da64cc6.jpg?s=120&d=mm&r=g)
Le Wed, May 25, 2016 at 12:33:49PM +0100, Adam Armstrong a écrit:
Run the bgp-peers poller module for that host in debugging mode: ./poller.php -h <device_id> -m bgp-peers -d Sounds like it may be a SQL update issue causing it to retry the update each time.
Done... Eventlog has *not* been updated :/
I dispatched the result in a text file, but as it's brightly colored, it's not very readable in vim :) Is there a way to have a "flat" output ?
Also, do you want me to send you the result ?
Arnaud.
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
Hi,
please do other debug:
./discovery.php -d -m bgp-peers -h <device>
and sent (attach os pastebin) this output.
/P.S. Make sure that you have updated observium (svn up)./
On 25.05.16 14:50, Arnaud Launay wrote:
Le Wed, May 25, 2016 at 12:33:49PM +0100, Adam Armstrong a écrit:
Run the bgp-peers poller module for that host in debugging mode: ./poller.php -h <device_id> -m bgp-peers -d Sounds like it may be a SQL update issue causing it to retry the update each time.
Done... Eventlog has *not* been updated :/
I dispatched the result in a text file, but as it's brightly colored, it's not very readable in vim :) Is there a way to have a "flat" output ?
Also, do you want me to send you the result ?
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/52482c5f8de61368e37aadec4da64cc6.jpg?s=120&d=mm&r=g)
Le Wed, May 25, 2016 at 03:09:50PM +0300, Mike Stupalov a écrit:
please do other debug: ./discovery.php -d -m bgp-peers -h <device> and sent (attach os pastebin) this output. /P.S. Make sure that you have updated observium (svn up)./
Just upped it: Observium 0.16.5.7872 Discovery results enclosed.
I confirm that eventlog noted the message at the discovery:
8s edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged.
Arnaud.
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
Try with latest revision (r7888), after ./discovery.php -u both issues should be gone.
On 25.05.16 16:15, Arnaud Launay wrote:
Le Wed, May 25, 2016 at 03:09:50PM +0300, Mike Stupalov a écrit:
please do other debug: ./discovery.php -d -m bgp-peers -h <device> and sent (attach os pastebin) this output. /P.S. Make sure that you have updated observium (svn up)./
Just upped it: Observium 0.16.5.7872 Discovery results enclosed.
I confirm that eventlog noted the message at the discovery:
8s edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged.
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/f859a4b11c74d3ea6e405973c642d2fd.jpg?s=120&d=mm&r=g)
Confirmed my issue gone ☺ Thanks
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Mike Stupalov Sent: onsdag 25. mai 2016 15.38 To: Observium Network Observation System observium@observium.org Subject: Re: [Observium] BGP peers updated
Try with latest revision (r7888), after ./discovery.php -u both issues should be gone.
On 25.05.16 16:15, Arnaud Launay wrote:
Le Wed, May 25, 2016 at 03:09:50PM +0300, Mike Stupalov a écrit:
please do other debug:
./discovery.php -d -m bgp-peers -h <device>
and sent (attach os pastebin) this output.
/P.S. Make sure that you have updated observium (svn up)./
Just upped it: Observium 0.16.5.7872
Discovery results enclosed.
I confirm that eventlog noted the message at the discovery:
8s edge.dc2 edge.dc2.dom.tld Bgp-peers: 6 updated, 49 unchanged.
Arnaud.
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
--
Mike Stupalov
NOTICE: Please immediately e-mail back to sender if you are not the intended recipient. Thereafter delete the e-mail along with any attachments without making copies. The sender reserves all rights of privilege, confidentiality and copyright.
![](https://secure.gravatar.com/avatar/52482c5f8de61368e37aadec4da64cc6.jpg?s=120&d=mm&r=g)
Le Wed, May 25, 2016 at 04:45:27PM +0200, Arnaud Launay a écrit:
Confirmed here too, issue has disappear. Peers have been reimported by IP address, and all is working nicely ™
I spoke a bit too fast, I still have the
14m41s edge.pa2 edge.pa2.domain.tld Bgp-peers: 1 updated, 58 unchanged.
on one Juniper.
/srv/www/observium/discovery.php -d -m bgp-peers -h edge.pa2.domain.tld >/tmp/discovery-pa2-7889.txt
included, Observium r7889.
Arnaud.
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
On 26.05.16 11:55, Arnaud Launay wrote:
Le Wed, May 25, 2016 at 04:45:27PM +0200, Arnaud Launay a écrit:
Confirmed here too, issue has disappear. Peers have been reimported by IP address, and all is working nicely ™
I spoke a bit too fast, I still have the
14m41s edge.pa2 edge.pa2.domain.tld Bgp-peers: 1 updated, 58 unchanged.
on one Juniper.
Here seems as really updated peer: SQL[UPDATE `bgpPeers` set `bgpPeerIdentifier` ='37.77.34.0',`bgpPeerLocalAddr` ='37.77.92.45' WHERE `device_id` = '9' AND `bgpPeerRemoteAddr` = '37.77.92.44']
Updated: bgpPeerIdentifier and bgpPeerLocalAddr
Hrm, but I see something strange in SNMP output for BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerRemoteAddr
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11.0.1.37.77.34.45.1.37.77.34.44 = "","
please attach additionally poller debug for these device: ./poller.php -d -m bgp-peers -h <device>
/srv/www/observium/discovery.php -d -m bgp-peers -h edge.pa2.domain.tld >/tmp/discovery-pa2-7889.txt
included, Observium r7889.
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/52482c5f8de61368e37aadec4da64cc6.jpg?s=120&d=mm&r=g)
Le Thu, May 26, 2016 at 01:05:06PM +0300, Mike Stupalov a écrit:
Confirmed here too, issue has disappear. Peers have been reimported by IP address, and all is working nicely ™
I spoke a bit too fast, I still have the 14m41s edge.pa2 edge.pa2.domain.tld Bgp-peers: 1 updated, 58 unchanged. on one Juniper.
Here seems as really updated peer: SQL[UPDATE `bgpPeers` set `bgpPeerIdentifier` ='37.77.34.0',`bgpPeerLocalAddr` ='37.77.92.45' WHERE `device_id` = '9' AND `bgpPeerRemoteAddr` = '37.77.92.44']
Updated: bgpPeerIdentifier and bgpPeerLocalAddr
Seems strange, it is not updated every few minutes ;)
1m 9s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 26m 40s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 2h 22m 26s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 2h 47m 16s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 6h 24m 57s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 12h 22m 58s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged.
Hrm, but I see something strange in SNMP output for BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerRemoteAddr
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11.0.1.37.77.34.45.1.37.77.34.44 = "","
please attach additionally poller debug for these device: ./poller.php -d -m bgp-peers -h <device>
I just redid discovery + poller:
/srv/www/observium/discovery.php -d -m bgp-peers -h edge.pa2.dom.tld >/tmp/discovery-pa2-7889-3.txt /srv/www/observium/poller.php -d -m bgp-peers -h edge.pa2.dom.tld >/tmp/poller-pa2-7889-3.txt
Files enclosed.
Arnaud.
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
On 26.05.16 14:05, Arnaud Launay wrote:
Le Thu, May 26, 2016 at 01:05:06PM +0300, Mike Stupalov a écrit:
Confirmed here too, issue has disappear. Peers have been reimported by IP address, and all is working nicely ™
I spoke a bit too fast, I still have the 14m41s edge.pa2 edge.pa2.domain.tld Bgp-peers: 1 updated, 58 unchanged. on one Juniper.
Here seems as really updated peer: SQL[UPDATE `bgpPeers` set `bgpPeerIdentifier` ='37.77.34.0',`bgpPeerLocalAddr` ='37.77.92.45' WHERE `device_id` = '9' AND `bgpPeerRemoteAddr` = '37.77.92.44']
Updated: bgpPeerIdentifier and bgpPeerLocalAddr
Ok, I think in r7893 it should be complete fixed (for your devices). /(But next discovery anyway should display such message one more time)./
Seems strange, it is not updated every few minutes ;)
1m 9s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 26m 40s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 2h 22m 26s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 2h 47m 16s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 6h 24m 57s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged. 12h 22m 58s edge.pa2 edge.pa2.dom.tld Bgp-peers: 1 updated, 58 unchanged.
Hrm, but I see something strange in SNMP output for BGP4-V2-MIB-JUNIPER::jnxBgpM2PeerRemoteAddr
.1.3.6.1.4.1.2636.5.1.1.2.1.1.1.11.0.1.37.77.34.45.1.37.77.34.44 = "","
please attach additionally poller debug for these device: ./poller.php -d -m bgp-peers -h <device>
I just redid discovery + poller:
/srv/www/observium/discovery.php -d -m bgp-peers -h edge.pa2.dom.tld >/tmp/discovery-pa2-7889-3.txt /srv/www/observium/poller.php -d -m bgp-peers -h edge.pa2.dom.tld >/tmp/poller-pa2-7889-3.txt
Files enclosed.
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/52482c5f8de61368e37aadec4da64cc6.jpg?s=120&d=mm&r=g)
Le Thu, May 26, 2016 at 05:38:06PM +0300, Mike Stupalov a écrit:
Updated: bgpPeerIdentifier and bgpPeerLocalAddr
Ok, I think in r7893 it should be complete fixed (for your devices). /(But next discovery anyway should display such message one more time)./
It's kinda better, but there's a new problem :)
14s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 41s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 10m 16s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 10m 42s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 20m 15s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 20m 41s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 30m 15s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 30m 42s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 40m 14s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 40m 41s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 50m 15s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 50m 42s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers
Strangely, it appears "only" every 10 minutes, but the poller is ran every five...
Ah, got it from the debug log.
BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9'] SQL RUNTIME[0.07306910s]
and every other five minutes, discovery.php is ran too.
poller.php debug log enclosed.
Arnaud.
![](https://secure.gravatar.com/avatar/7230842680987adb55db304b2fdbf3e6.jpg?s=120&d=mm&r=g)
Same here.
Thanks Basile
2016-05-26 23:03 GMT+02:00 Arnaud Launay asl@launay.org:
Le Thu, May 26, 2016 at 05:38:06PM +0300, Mike Stupalov a écrit:
Updated: bgpPeerIdentifier and bgpPeerLocalAddr
Ok, I think in r7893 it should be complete fixed (for your devices). /(But next discovery anyway should display such message one more time)./
It's kinda better, but there's a new problem :)
14s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 41s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers
10m 16s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 10m 42s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 20m 15s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 20m 41s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 30m 15s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 30m 42s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 40m 14s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 40m 41s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 50m 15s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 50m 42s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers
Strangely, it appears "only" every 10 minutes, but the poller is ran every five...
Ah, got it from the debug log.
BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9'] SQL RUNTIME[0.07306910s]
and every other five minutes, discovery.php is ran too.
poller.php debug log enclosed.
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
Hi, Arnaud and Basile,
thanks for your help and reports. I think in r7894 it should be fixed finally.
Say "thank you" to your vendor of devices ;) I not know, what data it reported sometime in snmp (with points, random strings and so on).
On Fri, May 27, 2016 at 6:56 PM, Basile Bluntschli < basile.bluntschli@gmail.com> wrote:
Same here.
Thanks Basile
2016-05-26 23:03 GMT+02:00 Arnaud Launay asl@launay.org:
Le Thu, May 26, 2016 at 05:38:06PM +0300, Mike Stupalov a écrit:
Updated: bgpPeerIdentifier and bgpPeerLocalAddr
Ok, I think in r7893 it should be complete fixed (for your devices). /(But next discovery anyway should display such message one more time)./
It's kinda better, but there's a new problem :)
14s edge.dc2 edge.dc2.domain.tld Forced discovery module(s):
bgp-peers 41s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 10m 16s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 10m 42s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 20m 15s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 20m 41s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 30m 15s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 30m 42s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 40m 14s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers 40m 41s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 50m 15s edge.dc2 edge.dc2.domain.tld Forced discovery module(s): bgp-peers 50m 42s edge.pa2 edge.pa2.domain.tld Forced discovery module(s): bgp-peers
Strangely, it appears "only" every 10 minutes, but the poller is ran every five...
Ah, got it from the debug log.
BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9'] SQL RUNTIME[0.07306910s]
and every other five minutes, discovery.php is ran too.
poller.php debug log enclosed.
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/52482c5f8de61368e37aadec4da64cc6.jpg?s=120&d=mm&r=g)
Le Sat, May 28, 2016 at 01:11:56AM +0300, Mike Stupalov a écrit:
Hi, Arnaud and Basile,
thanks for your help and reports. I think in r7894 it should be fixed finally.
Say "thank you" to your vendor of devices ;) I not know, what data it reported sometime in snmp (with points, random strings and so on).
I no longer have the message, but if I run discovery, then poller, I have this in poller debug:
BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9']
If I do another discovery, followed by another poller, the forced rediscovery is done every time...
Arnaud.
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
Fixed in r7896, now really complete. :)
On Sat, May 28, 2016 at 4:47 PM, Arnaud Launay asl@launay.org wrote:
Le Sat, May 28, 2016 at 01:11:56AM +0300, Mike Stupalov a écrit:
Hi, Arnaud and Basile,
thanks for your help and reports. I think in r7894 it should be fixed finally.
Say "thank you" to your vendor of devices ;) I not know, what data it reported sometime in snmp (with points, random strings and so on).
I no longer have the message, but if I run discovery, then poller, I have this in poller debug:
BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9']
If I do another discovery, followed by another poller, the forced rediscovery is done every time...
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/0fa97865a0e1ab36152b6b2299eedb49.jpg?s=120&d=mm&r=g)
15th time lucky :)
Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbird&utm_medium=email&utm...] On 29/05/2016 16:40:00, Mike Stupalov mike@observium.org wrote:
Fixed in r7896, now really complete. :)
On Sat, May 28, 2016 at 4:47 PM, Arnaud Launay <asl@launay.org [mailto:asl@launay.org]> wrote:
Le Sat, May 28, 2016 at 01:11:56AM +0300, Mike Stupalov a écrit:
Hi, Arnaud and Basile,
thanks for your help and reports. I think in r7894 it should be fixed finally.
Say "thank you" to your vendor of devices ;) I not know, what data it reported sometime in snmp (with points, random strings and so on).
I no longer have the message, but if I run discovery, then poller, I have this in poller debug:
BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9']
If I do another discovery, followed by another poller, the forced rediscovery is done every time...
Arnaud. _______________________________________________ observium mailing list observium@observium.org [mailto:observium@observium.org] http://postman.memetic.org/cgi-bin/mailman/listinfo/observium [http://postman.memetic.org/cgi-bin/mailman/listinfo/observium]
--
Mike Stupalov http://observium.org/ [http://observium.org/] _______________________________________________ observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/7230842680987adb55db304b2fdbf3e6.jpg?s=120&d=mm&r=g)
hm not for me... still see every 5 minutes: Forced discovery module(s): bgp-peers
it's not Juniper tough but Brocade CER Router
2016-05-29 17:39 GMT+02:00 Mike Stupalov mike@observium.org:
Fixed in r7896, now really complete. :)
On Sat, May 28, 2016 at 4:47 PM, Arnaud Launay asl@launay.org wrote:
Le Sat, May 28, 2016 at 01:11:56AM +0300, Mike Stupalov a écrit:
Hi, Arnaud and Basile,
thanks for your help and reports. I think in r7894 it should be fixed finally.
Say "thank you" to your vendor of devices ;) I not know, what data it reported sometime in snmp (with points, random strings and so on).
I no longer have the message, but if I run discovery, then poller, I have this in poller debug:
BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9']
If I do another discovery, followed by another poller, the forced rediscovery is done every time...
Arnaud.
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
-- Mike Stupalov http://observium.org/
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/3bbbd945c333b8013d0dfa23058f65b9.jpg?s=120&d=mm&r=g)
Ok, 16th iteration :)
Now your situation also fixed in r7898.
(Your device not always report correct remote peer ip, now used index instead).
On 29.05.16 23:38, Basile Bluntschli wrote:
hm not for me... still see every 5 minutes: Forced discovery module(s): bgp-peers
it's not Juniper tough but Brocade CER Router
2016-05-29 17:39 GMT+02:00 Mike Stupalov <mike@observium.org mailto:mike@observium.org>:
Fixed in r7896, now really complete. :) On Sat, May 28, 2016 at 4:47 PM, Arnaud Launay <asl@launay.org <mailto:asl@launay.org>> wrote: Le Sat, May 28, 2016 at 01:11:56AM +0300, Mike Stupalov a écrit: > Hi, Arnaud and Basile, > > thanks for your help and reports. > I think in r7894 it should be fixed finally. > > Say "thank you" to your vendor of devices ;) > I not know, what data it reported sometime in snmp (with points, random > strings and so on). I no longer have the message, but if I run discovery, then poller, I have this in poller debug: BGP peers list for this device changed, force rediscover BGP. SQL[UPDATE `devices` set `force_discovery` ='1' WHERE `device_id` = '9'] If I do another discovery, followed by another poller, the forced rediscovery is done every time... Arnaud. _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium -- Mike Stupalov http://observium.org/ _______________________________________________ observium mailing list observium@observium.org <mailto:observium@observium.org> http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
![](https://secure.gravatar.com/avatar/f859a4b11c74d3ea6e405973c642d2fd.jpg?s=120&d=mm&r=g)
Hi,
I debugged this on our systems some time ago. Our reason was because we had multiple reverse dns lookup for the remote hostname, so on every run the revers_dns colum in db would update, thus triggering this log.
Ex Run1: UPDATE `bgpPeers` set `reverse_dns` =’router1.fqdn.net’ WHERE `device_id` = '21' AND `bgpPeerRemoteAddr` = xxx.xxx.xxx.252' Run 2: UPDATE `bgpPeers` set `reverse_dns` ='wan-loc01.fqdn.net’ WHERE `device_id` = '21' AND `bgpPeerRemoteAddr` = xxx.xxx.xx.252'
Could be same issue or not ☺
From: observium [mailto:observium-bounces@observium.org] On Behalf Of Mike Stupalov Sent: onsdag 25. mai 2016 14.10 To: observium@observium.org Subject: Re: [Observium] BGP peers updated
Hi,
please do other debug:
./discovery.php -d -m bgp-peers -h <device>
and sent (attach os pastebin) this output.
P.S. Make sure that you have updated observium (svn up).
On 25.05.16 14:50, Arnaud Launay wrote:
Le Wed, May 25, 2016 at 12:33:49PM +0100, Adam Armstrong a écrit:
Run the bgp-peers poller module for that host in debugging mode:
./poller.php -h <device_id> -m bgp-peers -d
Sounds like it may be a SQL update issue causing it to retry
the update each time.
Done... Eventlog has *not* been updated :/
I dispatched the result in a text file, but as it's brightly
colored, it's not very readable in vim :) Is there a way to have
a "flat" output ?
Also, do you want me to send you the result ?
Arnaud.
_______________________________________________
observium mailing list
observium@observium.orgmailto:observium@observium.org
http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
--
Mike Stupalov
NOTICE: Please immediately e-mail back to sender if you are not the intended recipient. Thereafter delete the e-mail along with any attachments without making copies. The sender reserves all rights of privilege, confidentiality and copyright.
participants (5)
-
Adam Armstrong
-
Arnaud Launay
-
Basile Bluntschli
-
Kent Johannessen
-
Mike Stupalov