1. The Problem
If you are running ServiceNow ITOM alongside Infoblox for DDI (DNS, DHCP, IPAM), you have probably already discovered the out-of-the-box Service Graph Connector (SGC) for Infoblox. It is a solid starting point — it pulls IP addresses, subnets, and DNS aliases into your CMDB cleanly.
But here is the gap: it stops there. The SGC knows your IP topology. It does not know your network devices.
If you have Infoblox deployed at scale with the Network Insight module actively discovering your network estate, the question is: can ServiceNow consume that richer dataset?
The answer is yes — but not out of the box yet. The steps below explain how to build this from scratch. If you find this useful and believe it would benefit others, please vote on the idea to make this an out-of-the-box extension to the existing Service Graph Connector for Infoblox.
Link to the idea:
Vote: Extend SGC for Infoblox to support Network Insight Module
2. Infoblox Data Retrieval Options
Infoblox supports multiple ways of sending or pulling data from its database:
- REST API — The full API reference is available at https://ipam.illinois.edu/wapidoc/index.html. It covers different endpoints and methods to retrieve information for different object types.
- Events — You can trigger events from Infoblox towards ServiceNow for real-time change detection, including CMDB changes for scenarios such as new additions, updates, or removals.
The following REST API endpoints were used to retrieve device, interface, VLAN, and hardware component data:
/wapi/v2.x/discovery/device
Network device records with OS, serial number, model, and more.
/wapi/v2.x/discovery/deviceinterface
Interface-level data, IP assignments, VLAN membership, and more.
/wapi/v2.x/discovery/devicecomponent
Chassis and hardware component records.
3. Data Flow Architecture
The integration uses five parallel data pipelines, each targeting a different CI class family. All pipelines flow through IntegrationHub ETL into the IRE (Identification and Reconciliation Engine) before committing records to the CMDB.
Figure 1: Infoblox DDI integration architecture — data flow from source to CMDB
4. CMDB Data Model: What Gets Populated
The following CMDB tables are populated as a result of this integration. All tables listed are out-of-the-box ServiceNow tables except VLAN Mapping, which is a custom one-to-many table with references to both devices and interfaces.
1. Network Gear (Routers and Switches)
- Name, IP Address, Serial Number, Type, MAC Address, Model, Description
2. Network Adapter (Interfaces)
- Interface Name, Network Mask, Speed, Duplex
3. IP Address
- IP Address, IP Version
4. VLAN Mapping (Custom Table)
- VLAN Name, VLAN ID, Description
- One-to-many relationship with references to devices and interfaces
5. Implementation Approach
Standard ServiceNow data retrieval, transormation and parsing methods were used throughout:
1. REST Interface
- Data Stream Action — with built-in parsing in the action.
- Data Source Action — using script-based parsing in the data source.
2. Data Sourcing and Importing
- Data Sources with Data Stream Action.
- Data Sources with IntegrationHub REST option.
3. Data Transformation
- IntegrationHub ETL.
IRE rules are used to validate the payload and identify CIs. This integration uses Infoblox as a rich secondary discovery source, feeds it through IH ETL into IRE, and lets the CMDB become the single source of truth. The approach is applicable to any organisation running Infoblox at scale with the Network Insight module.
6. Results
The following screenshots demonstrate the data successfully populated in ServiceNow from Infoblox Network Insight.
Figure 2: CI relationship map — IP Switch with Hardware and Chassis components
Figure 3: Network Adapter (interface) records linked to parent device CI
Figure 4: IP Address records linked to network adapters and configuration items
Figure 5: VLAN Mapping records — device, interface, VLAN ID and VLAN name
7. Lessons Learned and Best Practices
1. IRE identification rules make or break the integration
Spend time upfront defining your CI identification rules. For network devices, using serial number as the primary identifier (where available) with hostname as fallback prevented duplicate CIs when the same device was also partially discovered by ITOM Discovery.
2. Use Data Stream for large payloads, REST IH for supplemental data
For the main device and interface lists (potentially thousands of records), Data Stream with pagination is essential. For IP addresses and VLANs, which are per-interface, a simpler REST IH action sufficed and was faster to implement.
3. Reconciliation between Infoblox and ITOM Discovery needs explicit precedence
If you are running both Infoblox custom integration and ITOM Discovery, configure IRE reconciliation precedence rules carefully. Infoblox Network Insight can be highly reliable for serial numbers and OS versions; ITOM Discovery may be more accurate for uptime and interface state.
4. VLAN mapping benefits from a custom CI class in complex environments
Depending on your VLAN volume and whether you need VLAN CIs to participate in Service Maps, consider whether cmdb_ci_ip_network suffices or a custom class better reflects your data model requirements.
5. Align your data model to CSDM before building pipelines
The most impactful upfront decision was aligning the target CI classes to the CSDM. This paid dividends in avoiding schema debt and ensuring compatibility with future ServiceNow upgrades and ITOM Health integrations.
8. Questions and Further Help
Drop questions in the comments below. Happy to discuss IRE rule configuration, Data Stream parsing scripts, or CSDM alignment decisions in more detail.
If you need further help, please reach out to ServiceNow Expert Services.
Don't forget to vote on the idea to make this an out-of-the-box extension to the existing or a new Service Graph Connector for Infoblox.
Link to the idea:
Vote: Extend SGC for Infoblox to support Network Insight Module
