Hi @SRSkaggs ,
1. lets Understand what’s likely happening as per my understanding :-
By default, the Identification and Reconciliation Engine (IRE) uses Identification rules to decide if an incoming CI matches an existing one or should create a new one.
For the Load Balancer class (cmdb_ci_lb or subclass like F5), there may be:
* A hybrid identifier rule (mix of serial number + name + other attributes)
* Or a rule that treats each discovered record as separate if some part of the identifier set is missing
If the same serial number & name come in but on separate discovery runs, from different discovery sources, or with slightly different data, and the identifier rule isn’t strict enough, IRE may treat them as separate CIs.
2. Step to what to check
Step 1: Review the Identification Rule
* Go to:
CMDB → Identification Rules
* Filter for rules related to:
cmdb_ci_lb_f5
or parent cmdb_ci_lb if that’s where the rule lives.
Check:
* Which fields are used as identifiers? (e.g., serial number, name, discovery source)
* Is it a hybrid rule? Hybrid rules combine multiple sets (e.g., match on serial number + name OR on management IP).
If the rule says:
* “Match on serial number + name” → these should merge.
* If it's hybrid: “serial number + name” OR “management IP” → and you have different management IPs → it may create new CIs.
Step 2: Check the Discovery logs and IRE logs
* Go to:
CMDB → Identification Log
* Look at the log entries when these CIs were created.
* See why IRE decided it was a new CI instead of matching the existing one.
Step 3: Validate incoming data
* From Discovery logs, check if the serial number or name values coming from each run really are exactly identical.
* Sometimes:
* Name may have an extra space or case difference (LB-01 vs lb-01)
* Serial number may have different format (e.g., uppercase vs lowercase, dashes)
Even small differences → no match.
Step 4: Check Data Source priorities
If the same CI comes from multiple discovery sources (e.g., SNMP Discovery, Network Discovery, or manual import):
* IRE may create separate CIs if the identifier rule doesn’t fully unify them.
* Check the Data Source field on CIs; if one source sends different values, that may cause the duplicate.
3. How to fix it
Option 1: Adjust the Identification Rule
* Make the rule stricter: require serial number + name always
* Or simplify: rely on unique serial number only (if that’s truly globally unique)
Option 2: Normalize data
* Use Transform Maps or Data Sources to clean up names (case, spaces)
* Use Data Normalization if you have Data Certification or Data Manager
Option 3: Use reconciliation to merge
* Use the Reconciliation definition to ensure only one active CI wins
4. Common cause
* Hybrid rule: if it has "OR" logic and Discovery brings in different attributes each time, IRE may not match correctly.
* Same name & serial number but different management IPs → may cause multiple CIs.
5. Quick summary solution
* Check & adjust the Identification Rule on the F5 class or parent load balancer class
* Make sure serial number + name is always used together (and data is clean)
* Check Identification Logs to see why IRE didn’t merge
* Normalize incoming data to remove formatting differences
* Reconcile if duplicates already exist
Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025
