F5 Big IP in a wrong Class after ITOM Discovery

[Community Alums]

Hi.
After a Discovery i reviewed imports and my F5 Big is under class server

I undertood that Discovery don't create o modify class structure or Hierachy.

So why my F5 Big IP is under Server ?

I believe that is not because the SSH has preference above SNMP in Discovery.

I guess that the class hierachy already exists 

So the cass Hierachy was wrong from begin ? 

[kmohammed]

You are right on one point, and that point is also the clue: Discovery does not create or change the class hierarchy. It selects a class from the hierarchy that already exists in your CMDB. So a Server result does not, by itself, mean the hierarchy was wrong from the start. It usually means Discovery classified this device as a Server, or identified it as an existing Server CI, instead of matching it as an F5 device.

Classification and identification are two separate steps, and that distinction matters here:

1. Classification decides what kind of device Discovery thinks it found, based on the probes and patterns that actually ran and matched.

2. Identification then matches that result to an existing CI, for example by serial number, IP, or hostname. If it matches a pre-existing Server CI, the record stays a Server even if the device is really an F5.

That is also why SSH versus SNMP is not simply a preference setting. If the SNMP credential fails, the device does not respond as expected to the SNMP probe, or the F5 pattern does not match, a generic SSH-based Server pattern can match first and win. The result is a Server CI, not a broken hierarchy.

Where to check, in order:

1. Check the Discovery run for that IP: which probes succeeded, which pattern ran, what classification it produced, and whether there were credential or pattern errors. That log tells you whether the F5 pattern ever ran, or whether Discovery fell back to a generic Server pattern.

2. Check whether the Server CI existed before this Discovery run, and what its discovery source and last discovered date are. A pre-existing manually created or imported Server CI is a strong hint that identification matched the wrong record.

3. Check the F5 pattern and the SNMP credential for that device: is the pattern active and applicable to this device, does the SNMP credential test successfully for this IP, and does the device respond with the identifying information the pattern expects? If any of those fail, Discovery cannot reliably classify it as an F5.

What not to do: do not just change sys_class_name on the CI by hand. The next Discovery run can reclassify or re-identify it back to Server, and the attributes and relationships collected for a Server will still not match an F5 device.

Fix the cause, then re-discover: correct the pattern, credential, or identification match, then run Discovery again for that IP and verify that the CI changes to the F5 / load balancer class in your instance. If a separate correct F5 CI already exists, handle that as a CMDB de-duplication case under your normal CMDB governance, rather than creating another CI by hand.

If you can share what the Discovery log shows for that IP, specifically which pattern ran and whether the SNMP probe succeeded, that will narrow it down to a pattern problem, a credential problem, or an identification match to a pre-existing Server CI.