Using the IP Address/DNS name/MAC Address/Serial Number fields on the Main CMDB CI is problematic<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Table of Contents IntroductionPrimary IP / Management IP / Administrative IPWhere the data is supposed to be / Source of truthWhich Relationships/References tie these together Relationships (cmdb_rel_ci):References: CMDB IRE IdentificationReconciliation / committing the Payloads Discovery BehaviourService Graph Connector behavior Introduction There is a fundamental problem with the following fields on the Main CI for a device such as a Computer, Network gear, appliance, etc. because the fields hold a single value, when the device is likely to have a set of values for each. Serial Number [serial_number]MAC Address [mac_address]IP Address [ip_address]DNS Domain [dns_domain]FQDN [fqdn] Where more than one value exist, by definition the single value in these fields is 'wrong'. You could argue that where the multiple values exist elsewhere, linked/related to the CI, these fields should not be populated at all, and could even be considered legacy. Primary IP / Management IP / Administrative IP IP Address is the main problem. ServiceNow has never documented this field as being the Primary/Management/Administrative IP, but this is a common assumption by customers. These are human concepts that don't technically exist in the device itself. The OS simply has multiple serial numbers, multiple Network adapters with different MAC addresses, which have multiple IP addresses and DNS names for those IPs. From the point of view of the device configuration, there is no difference between any of those. There is no 'correct' value. Sometimes network devices might define a physical interface on the box as being the management interface, but it appears as just another port from the SNMP data point of view. A Cluster, comprising several boxes or servers, may have a single Management IP. But that's not the IP of all the devices. A stacked switch will be managed by one unit in the stack, but that is also only an IP of the master unit.. A DNS Lookup of an FQDN will return an single IP address, but that also isn't necessarily the Primary IP. If operationally within your organisation you do have a single IP address that you refer to the device with, when managing it, logging into it for maintenance, or making changes, then that's not something we can discover automatically. But it is still a valid use case that ServiceNow should cater for. It is true for many customers that once these values in the main CI have been set, or 'corrected' manually, you don't want anything changing them, or it breaks processes and integrations. Where the data is supposed to be / Source of truth Serial Number [cmdb_serial_number] table, Serial Number, with a Serial Number TypeMAC Address is on the Network Adapter [cmdb_ci_network_adapter] table, MAC Address fieldIP Address is cmdb_ci_ip_address. Note: A Network Adapter CI record may also have an IP Address entered, but that is also an ambiguous field.FQDN is the DNS Name [cmdb_ci_dns_name] table, Name field.DNS Domain is part of the DNS Name [cmdb_ci_dns_name] table, Name field. Which Relationships/References tie these together Relationships (cmdb_rel_ci): Hardware 'Owns' Network AdapterHardware 'Owns' IP AddressNetwork Adapter 'Owns' IP AddressDNS Name 'Uses' IP Address Note: There is no Relationship for the serial number, as that's a standalone table. References: Network Adapter references the Server in the cmdb_ci fieldIP Address references the Network Adapter in the nic field. The main CI is not referenced directly.Serial Number references the CI in the cmdb_ci field The example payload given in this KB article helps shows the relationships and references expected between a Server and its Network adapter and IP addresses.KB1284595 CMDB IRE API and Business Rules CMDB IRE Identification CMDB Identification and Reconciliation has out-of-box rules for Hardware, which starts with the Serial Numbers related list, and only falls back to the Serial number field if those are missing from the payload or existing records are missing. That is because you will only have all the serial numbers in the related list. MAC address of Network Adapters are generally unique too, however less so more recently with many devices being Virtual. Network Adapter [cmdb_ci_network_adapter] related list is used. IRE no longer uses the ip_address and mac_address fields of the main CI for identification. IP Address is no longer used at all. Reconciliation / committing the Payloads After matching the existing CI using Identification rules, whatever values are in the IRE payload will replace the existing values in the CI record, unless something prevents that. Reconciliation rules can prevent one data source's value being overwritten by another data source. However there is no mechanism to prevent manually updated values from then being overwritten. e.g. an update to the record by a user via a form is not being tracked by IRE (discovery_datasource_last_update) and so isn't going to prevent a manually updated value being overwritten, even if a reconciliation rule for "Manual Entry" is created. The "Manual Entry" is for use as a data source name when putting IRE payload through the APIs only - It does not mean Manual Entry.KB1893055 Discovery Source, First Discovered, Most recent Discovery and Manual Entry don't mean what you think Discovery Behaviour As a general rule, where there are multiple possible values, the value in these fields is left alone unless the existing value is no longer one of the current set of values. For example, if a Switch CI's IP Address field has a value that is no longer seen by Discovery, then it is substituted for one of the others. This behaviour is implemented in the For patterns, it used to be that the IP Address value is replaced by the IP address that happens to be the one used to scan the device on that discovery run. A Pattern is passed the IP address being scanned as an input, and that's what ends up in the IRE payload from the pattern. Now, it is only changed if the IP is no longer valid for the device. This KB article explains how things used to happen before and after Orlando Patch 5, but that just explains what happened with Probes. It does not apply to Patterns. The glide.discovery.enforce_ip_sync property does not apply to Discovery Patterns.KB0687602 Discovery Device IP Address Service Graph Connector behavior The current CMDB Model is more-or-less derived from how Discovery patterns create CIs. Service Graph Connectors should also follow the same model when putting their IRE payloads together. If a transform were to deliberately leave the Main CI fields alone if it didn't have to change them, then that would be done by special scripts implemented in the transform. The author isn't aware of any that currently do that - TBC. First, the transforms would have to create items in the payloads for the related list records in the first place, and not just populate main CI fields. Some don't even do that, forcing IRE to rely on the ambiguous Serial Number field. It may even be a legacy Import Set transform that relies on Coalescing on Serial number field only for the matching (which has often been the customer requirement that meant Discovery support cases were opened).