If you are experiencing device polling problems, use the probity utility to check if a device has been discarded by the poller. If it has been discarded, then the device polling time will be deemed to be too long for management within the ENA environment.
Troubleshooting the cause of SNMP polling failures for a device:
You should interrogate the prole log file (which is located in entuity_home/log/prole.log, and look for any messages generated against the device name. Typical causes of SNMP polling failure include:
- ENA could not communicate with the device via IP (caused by either a network problem or the fact that the device is down).
- an invalid SNMP read community string, e.g. the string has been changed on the device but not in ENA.
- the SNMP access list for the device has been modified, blocking access to the management server.
- one or more SNMP response packets retrieved from the device are invalid (caused either by a bug in the device’s SNMP agent, or the corruption of UDP (User Datagram Protocol) packets by the network - turning on the UDP checksum may highlight the cause of the problem).
- the routing table of the management server indicates no route to the IP address of the device.
- the device name could not be resolved to an IP address (check the local hosts file or the applicable name service).
SNMPv3 and end host discovery:
ENA may be unable to discover all end host information from devices being managed via SNMPv3. This is due to a lack of support for VLANs in the SNMP agent of the device. Only end hosts (MACs) on default VLANs are discovered. This is a known limitation in several device agents, including Cisco.
Areas in ENA that can be impacted by the lack of end-host information are:
- Maps - may not be able to accurately determine uplink connections between layer 2 switches and layer 3 routers.
- end host configuration changes - may not be detected.
You can configure some newer SNMPv3 Cisco devices to provide VLAN information using SNMPv3 contexts. For example, the following command configures a device to automatically create an SNMPv3 context for each VLAN:
snmp-server group mygroup V3 auth context vlan- match prefix read myread write mywrite notify mynotify
For older Cisco devices you can explicitly configure a context for each VLAN, for example:
snmp-server group mygroup v3 noauth context vlan-99
Consult the device documentation on which command is appropriate for a particular device.
When you have configured these devices, ENA will use SNMPv3 contexts to extract VLAN host information. Note, if ENA is managing a device through its SNMPv3 context, then you cannot also use the SNMPv3 contexts to extract VLAN information.
You can change the vlan- prefix by setting snmpVlanContextPrefix in entuity_home\entuity.cfg, for example:
If a device does not support SNMPv3 contexts, then to access the VLAN host information you could manage the device using SNMPv2.