![](https://secure.gravatar.com/avatar/23e49e42733da1026ac2bbfcda0c85df.jpg?s=120&d=mm&r=g)
Hello.
Running Observium CE 0.13.10.4586.
I've run into a strange situation with a single device that I am unable to discover and get added into observium's inventory. The device is an F5 Load-balancer. I have 51 other F5's all working beautifully, yet this one seems to be giving me grief for some reason when I try to discover it.
I am able to ping and snmpwalk the device beautifully from the observium server, yet every attempt to run add_device.php returns with the following: ========= root@observium:~# ./add_device.php lb1-prod-c-qcy examplecommunitystring v2c Trying v2c community examplecommunitystring ... No reply on community examplecommunitystring using v2c Could not reach lb1-prod-c-qcy with given SNMP community using v2c Trying v2c community examplecommunitystring ... No reply on community examplecommunitystring using v2c Could not reach lb1-prod-c-qcy with given SNMP community using v2c Observium v0.13.10.4586 Add Device
USAGE: add_device.php <hostname> [community] [v1|v2c] [port] [udp|udp6|tcp|tcp6] add_device.php <hostname> [any|nanp|anp|ap] [v3] [user] [password] [enckey] [md5|sha] [aes|des] [port] [udp|udp6|tcp|tcp6]
EXAMPLE: SNMPv1/2c: add_device.php <hostname> [community] [v1|v2c] [port] [udp|udp6|tcp|tcp6] SNMPv3 : Defaults : add_device.php <hostname> any v3 [user] [port] [udp|udp6|tcp|tcp6] No Auth, No Priv : add_device.php <hostname> nanp v3 [user] [port] [udp|udp6|tcp|tcp6] Auth, No Priv : add_device.php <hostname> anp v3 <user> <password> [md5|sha] [port] [udp|udp6|tcp|tcp6] Auth, Priv : add_device.php <hostname> ap v3 <user> <password> <enckey> [md5|sha] [aes|des] [port] [udp|udp6|tcp|tcp6] =========
yet, as you can see, when I snmpwalk this device, I get responses back just fine.
========= root@observium:~# snmpwalk -v2c -c examplecommunitystring lb1-prod-c-qcy | head SNMPv2-MIB::sysDescr.0 = STRING: Linux lb1-prod-c-qcy 2.6.18-164.11.1.el5.1.0.f5app #1 SMP Mon Mar 5 12:40:48 PST 2012 x86_64 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (3523019831) 407 days, 18:09:58.31 SNMPv2-MIB::sysContact.0 = STRING: NOC SNMPv2-MIB::sysName.0 = STRING: lb1-prod-c-qcy SNMPv2-MIB::sysLocation.0 = STRING: QDC-C SNMPv2-MIB::sysServices.0 = INTEGER: 78 SNMPv2-MIB::sysORLastChange.0 = Timeticks: (2) 0:00:00.02 SNMPv2-MIB::sysORID.1 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance SNMPv2-MIB::sysORID.3 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance ... =========
I've tried the discovery via v1 as well as v2c, no difference. Every time I try a walk, I get results back consistently...so it's not like I'm seeing intermittent responses or anything.
I was able to get it to finally discover when I specified the port & transport fields to add_device.php.
Any thoughts as to what might be failing or not satisfying the add_device.php utility that it would flag this host as not replying? Why would port/transport being specified make a difference if it's still just standard 161/udp?
Any hints or suggestions are appreciated.
Cheers, -Chris