eHealth fails to discover CPU, Virtual Server and HTTP Proxy elements on F5 version 9 devices

Document ID : KB000023405
Last Modified Date : 14/02/2018
Show Technical Document Details

Problem:

eHealth cannot discover Virtual CPU servers and HTTP proxy on devices that are F5 with the firmware version 9.


Environment:
eHealth 6.2.x and above
All supported platforms


Causes:
eHealth Discover does not work for the f5-bigip-system.mib because it is a non-compliant SNMPv2C agent. F5 BigIP is able to respond to SNMPv1 requests for most MIBs, but fails to respond to SNMPv1 requests for specific OIDs in the MIB "F5-BIGIP-SYSTEM-MIB". This MIB responds only to SNMPv2c. eHealth discovery sends SNMP queries to the agent to determine what version of SNMP to use. eHealth then invokes finder code with the determined SNMP version. In the case of the devices used in the investigation, this version is SNMPv1. At this point, eHealth is able to discover various parts of the agent with SNMPv1, but it cannot discover those parts of the agent that respond only to SNMPv2c. eHealth cannot handle mixed versions of SNMP in the same agent.

During discovery, the finder sends SNMP queries to the device to make sure the required statistics exist on the device. The finder receives a "noSuchName" response error because the queried mib object, sysHttpStatNumberReqs (1.3.6.1.4.1.3375.2.1.1.2.4.7), is unable to respond to the SNMPv1 query. All three missing elements are using MIB objects from the same MIB, and have same problem. This results in eHealth's inability to discover "F5 HTTP Proxy", "F5 BigIP CPU v9", and "F5 BigIP Virtual Server-Side" elements.

This problem was confirmed with sniffer capture of the request and response packets between eHealth and F5 BigIP. A third party MIB walk tool (getif) also confirmed the problem ? F5-BIGIP-SYSTEM-MIB is unable to respond to SNMPv1 requests while most MIBs do.

Resolutions:

Long Term Resolution

F5 will review RFC 1452 and RFC 3584 to see what needs to be done to make this agent SNMPv1/v2c compliant. Once the main issue is fixed by F5, eHealth will be able to discover the three types of elements without problem.

Short Term Resolution

Finder code has been added to eHealth to work around the problem starting in the February 2007 Verification kit found at: https://support.ca.com. This will correlate to eH 5.7 SP7 and eH 6.0 SP2. Setting "NH_DISCOVER_SNMPv2c_ONLY=yes" will cause the finder to check the environment variable and the target OID in F5-BIGIP-SYSTEM-MIB. If both conditions have been met, eHealth will make an exception to the discover process and look for F5 devices with SNMPv2c, even if eHealth discovery passes the SNMP version to the finder as SNMPv1. With this workaround, eHealth will be able to discover all elements.

To apply the short term resolution, please do the following:

  1. Apply the February 2007 verification kit (or a later kit) after it comes out.
  2. Set the environmental variable: NH_DISCOVER_SNMPv2c_ONLY=yes (SEE BELOW LINKS for directions on setting environment variables)
  3. Re-discover the F5 device and make sure elements such as F5 BigIP CPU v9, F5 BigIP Virtual are discovered
  4. Make sure no polling error occur on the F5 elements
  5. For a Certification request, allow eHealth to poll for at least an hour after rediscovery, then send in sample AAG reports and discover logs)

Additional Information: