- DCA Version 2.x
In some cases dcacheck or snmpwalk will report the following symptoms
DCA_CHECK_ERROR host(etl1.gphd.local): [Status=>error] [Upgrade State=>SNMP configuration issue on host] [oid=>.126.96.36.199.4.1.1188.8.131.52.1.6]
[root@sdw1 ~]# !snmp snmpwalk -v 2c -c public etl1 184.108.40.206.4.1.1220.127.116.11.1.6 NMPv2-SMI::enterprises.118.104.22.168.1.6 = No more variables left in this MIB View (It is past the end of the MIB tree)
The most common reason for this type of error is a mismatch between hostname resolution and /etc/snmp/snmpd.conf configuration
After enabling the vlan overlay it is common for customers to force /etc/hosts to use the external interaface. Lets assume the following environment
- Local DCA subnet is 172.28.0.0/20
- External Vlan subnet is 10.30.0.0/24
Given the subnets we configure mdw and etl1 /etc/hosts as followed
- mdw:/etc/hosts has host entry of "10.30.8.201 etl1.gphd.local"
- etl1:/etc/hosts has host entry of "172.28.8.201 etl1.gphd.local"
- /etc/snmp/snmpd.conf configured with the following
com2sec internalUser 10.30.0.0/24 public
In the above diagram we can see the snmpd is configured to allow acces via the 10.x network, however the local hostname resolution is configured to use 172.x subnet. Because of this the lsi and snmpd daemons will not be able to communicate with eachout and snmp walk will fail.
Make sure the hostname to ip resolution are the same for all nodes in the cluster. The solution is to enforce the use of only the 172 netowrk or 10 network for etl1 host and update the /etc/snmp/snmpd.conf subnet range accordingly.
By setting the snmpd.conf to use a subnet of "0.0.0.0/0" both local and external agents will be able to execute snmp queries. This imposes a security risk given that any subnet can connumincate with the snmp agent
com2sec internalUser 0.0.0.0/0 public
Please see this instructions for restarting snmpd after changes to the configuration are complete