Blocker Description
- Hi,
We identified what seems to be a regression in our last update:
Observium updated: 22.4.11952 (stable) -> 22.5.12000 (stable)
On several devices, the Local AS is discovered wrong.
Running discovery.php -m bgp-peers -d for a Cisco ASR920 device leads me to think the following commands are used in order to determine bgpLocalAs:
CMD[/usr/bin/snmpget -t '3' -r '5' -v2c -c *** -Pud -OQUv -m BGP4-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp 'udp':'frgre-cog-a9h1.as29075.net':'161' bgpLocalAs.0]
|
CMD[/usr/bin/snmpget -t '3' -r '5' -v2c -c *** -Pud -OQUv -m CISCO-BGP4-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp:/opt/observium/mibs/cisco 'udp':'frgre-cog-a9h1.as29075.net':'161' cbgpLocalAs.0]
|
CMD[/usr/bin/snmpgetnext -t '3' -r '5' -v2c -c *** -Pud -OQUs -m CISCO-BGP4-MIB -M /opt/observium/mibs/rfc:/opt/observium/mibs/net-snmp:/opt/observium/mibs/cisco 'udp':'frgre-cog-a9h1.as29075.net':'161' cbgpPeer2LocalAs]
|
These commands yield, respectively:
- 29075, which is correct and the expected value
- No Such Instance currently exists at this OID
- cbgpPeer2LocalAs.ipv4."185.96.184.156" = 50618, which is the local AS for the first BGP peer (that is also in a VRF)
This issue is critical for us because we rely on Observium discovery for configuring our monitoring tools and we can't currently update these tools to reflect the current network status.
Thanks for your help.
Attachments
Activity
This fixed in Rolling train.
You can temporary switch to rolling updates:
https://docs.observium.org/updating/#switch-between-rolling-and-stable-trains
Thanks but r12032 seems empty. Maybe my SVN skills are lacking.
The behavior is unchanged, from my point of view.
Hi Mike,
Thanks for your prompt answer.
As I tried to explain in original description, the device returns 29075 for bgpLocalAs.0 (standard MIB), which is the correct and expected value.
It returns nothing for cbgpLocalAs.0 (Cisco MIB). I would agree to prefer this value if it was defined.
However, the retained value is from a specific peer.
I understand that in some cases it could be useful to infer the Local AS from that.
But it is wrong to prefer an inferred value over information that has clear meaning.
I will attach discovery output.
Ok, I changed select Device LocalAs in r12032 (rolling).
But anyway I waiting for device discovery output.
I can write same as Bot requested 
As minimum discovery debug required:
./discovery.php -d -h <device>
|
But snmpdump will be very helpful, because your device return different ASes (and seems as different peers information), not sure which correct.
By default for Cisco devices we prefer information from Cisco vendor specific MIBs.
Hello Bot,
I feel I've been specific enough and that so much detail is not needed.
General questions and device support can be discussed in our Discord channel, click here to join.
Please make and attach additional information about the device:
- full snmp dump from device:
snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1 > myagent.snmpwalksnmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalkIf device not support SNMP version 2c, replace -v2c with -v1.
- If you have problems with discovery or poller processes, please do and attach these debugs:
./discovery.php -d -h <device>./poller.php -d -h <device>
- additionally attach device and/or vendor specific MIB files
This comment is added automatically.
OK, I can see the change now.
This fixes my issue. Many thanks !
I've updated the discovery outputs.