ServiceNow Network Router Discovery — Troubleshooting - Support and Troubleshooting

ServiceNow Network Router Discovery — Troubleshooting Summary

ServiceNow Discovery › Network Device Patterns › Network Router Network Router Discovery — Complete Troubleshooting Guide 📅 June 2026 🔧 Zurich / Xanadu 🔌 SNMP Pattern-Based 📋 cmdb_ci_ip_router 📄 Contents Overview & How It Works Pre-Discovery Checklist Troubleshoot by Symptom Error Message Reference System Properties Reference Pattern Deep Dive & Step-by-Step Debugging Known Issues & Limitations

1. Overview & How It Works ServiceNow Discovery uses the Network Router pattern to automatically find, classify, and populate Layer-3 routing devices in the CMDB. Like all network device patterns, it communicates exclusively over SNMP (UDP port 161) and does not require SSH, WMI, or agent access. The discovered CI class is cmdb_ci_ip_router .

Scope This guide covers the out-of-box Network Router horizontal discovery pattern and the companion Create connections to dynamic cmdb_ci_ip_router table pattern. It does not cover Service Mapping (top-down), Traffic-Based Discovery, or custom patterns unless noted. The Four Discovery Phases All four phases must succeed in order. Diagnose from Phase 1 forward — do not skip ahead.

Phase Engine What Happens Failure Symptom ① Scanning Shazzam probe Sends a UDP packet to port 161. Any SNMP response (even a generic error reply) means the device is reachable and SNMP is open. No credentials are used at this stage. No discovery log entry at all for this IP address. ② Classification SNMP Classify probe + sensor Queries sysObjectID and sysDescr . Matches against the SNMP Classifications table (Discovery → Administration → SNMP Classification). Selects the Network Router pattern. Classification order: sysObjectID first → sysDescr contains → sysName (first match wins). Device discovered as wrong type (e.g., as switch instead of router), or "No classifier found" error. ③ Identification IRE (Identification & Reconciliation Engine) Checks if a cmdb_ci_ip_router CI already exists using serial_number + ip_address as identifier keys. Creates a new CI or updates an existing one. Uses the CIIdentification and CIIdentifier script includes. Duplicate CIs, CI created with no data, or silent IRE failure (see glide.discovery.ire_err_exclusion_list ). ④ Exploration Network Router pattern Full SNMP pattern runs on the MID Server. Collects hardware inventory, all interfaces, IP addresses, ARP table, LLDP/CDP neighbors, routing protocol data. Writes results to CMDB. Also runs the companion connections pattern to link the router to adjacent devices. CI exists but fields are blank (serial, model, interfaces missing or incorrect). Important Each phase depends on the previous one. If Classification fails, the pattern never runs. Always start troubleshooting from Phase 1. Router vs. Switch: Key Differences Both patterns are SNMP-only and share the same 4-phase engine. These are the specific differences that affect troubleshooting:

Aspect Network Router Network Switch CI class cmdb_ci_ip_router cmdb_ci_ip_switch Child interface CIs cmdb_ci_network_adapter cmdb_ci_network_adapter Routing table queried Yes — ipRouteTable / ipForwarding OID No FDB / bridge table queried No Yes — dot1dBasePortTable VLAN table queried No (unless device is also a switch) Yes — dot1qVlanStaticTable Network ownership property glide.discovery.network_owner_method N/A Unique CI fields can_route, default_gateway, range can_switch, can_partitionvlans Key SNMP OIDs Queried by the Pattern OID MIB / Name Data Collected .1.3.6.1.2.1.1.1 SNMPv2-MIB: sysDescr System description (used in classification) .1.3.6.1.2.1.1.2 SNMPv2-MIB: sysObjectID Unique device type OID (primary classification key) .1.3.6.1.2.1.1.3 SNMPv2-MIB: sysUpTime Uptime in hundredths of a second .1.3.6.1.2.1.1.4 SNMPv2-MIB: sysContact Contact string configured on device .1.3.6.1.2.1.1.5 SNMPv2-MIB: sysName Hostname (used as CI name when SNMP trusted) .1.3.6.1.2.1.1.6 SNMPv2-MIB: sysLocation Physical location string configured on device .1.3.6.1.2.1.2.2 IF-MIB: ifTable Interface inventory: name, MAC, speed, admin/oper status .1.3.6.1.2.1.31.1.1 IF-MIB: ifXTable Extended interface data (ifName, ifHighSpeed, ifAlias) .1.3.6.1.2.1.4.1 IP-MIB: ipForwarding Confirms device is forwarding IP (1=forwarding, 2=not) .1.3.6.1.2.1.4.20 IP-MIB: ipAddrTable IP addresses bound to each interface (with ifIndex) .1.3.6.1.2.1.4.21 IP-MIB: ipRouteTable Routing table: destination, gateway, metric, interface .1.3.6.1.2.1.4.22 IP-MIB: ipNetToMediaTable ARP table: IP-to-MAC mappings for connected devices .1.3.6.1.2.1.47.1.1.1 ENTITY-MIB: entPhysicalTable Hardware inventory: serial number, model, manufacturer .1.0.8802.1.1.2.1.4 LLDP-MIB: lldpRemTable LLDP neighbor chassis ID, port ID, system name .1.3.6.1.4.1.9.9.23.1.2.1 CISCO-CDP-MIB: cdpCacheTable Cisco-only: CDP neighbor device ID, addresses, capabilities CI Fields Populated on cmdb_ci_ip_router Field Source OID / MIB Notes name sysName (.1.3.6.1.2.1.1.5) Used when snmp_trusted=true ; otherwise DNS reverse lookup serial_number entPhysicalSerialNum (.1.3.6.1.2.1.47.1.1.1.1.11) From ENTITY-MIB chassis row; blank if device doesn't support ENTITY-MIB model_number entPhysicalModelName (.1.3.6.1.2.1.47.1.1.1.1.13) Hardware model string (e.g., "ISR4451-X/K9") manufacturer entPhysicalMfgName (.1.3.6.1.2.1.47.1.1.1.1.12) Manufacturer reference to core_company firmware_version sysDescr (parsed) Extracted from sysDescr string; vendor-format varies ports ifNumber (.1.3.6.1.2.1.2.1) Total number of interfaces reported by ifTable physical_interface_count ifTable (physical type filter) Count of physical (non-loopback, non-tunnel) interfaces default_gateway ipRouteTable (default route) Next hop for the 0.0.0.0/0 route entry can_route ipForwarding (.1.3.6.1.2.1.4.1) Set to true when ipForwarding=1 can_switch Pattern logic (bridging MIBs) Set to true if device also reports bridge/switching capability bandwidth ifSpeed / ifHighSpeed (max interface) Estimated bandwidth in Mbps from fastest physical interface fqdn DNS reverse lookup / sysName Set from DNS when hostname.include_domain=true discovery_source Platform Set to "ServiceNow" by Discovery last_discovered Platform Timestamp of most recent successful exploration Child CIs Created In addition to the router CI itself, Discovery creates cmdb_ci_network_adapter records for each physical interface (with MAC address, IP, speed, and admin/oper status) and links them as "Owns" relationships to the parent router CI. These adapters are the source for CMDB topology and L2/L3 connection mapping.

2. Pre-Discovery Checklist Run through all items below before opening a support case or spending time debugging pattern steps. Most router discovery failures trace back to one of these prerequisites.

▶ SNMP Access & Credentials ☐ UDP port 161 is open from the MID Server to the device IP Test: snmpwalk -v2c -c 1.3.6.1.2.1.1 ☐ SNMP credential is defined in Discovery → Credentials with the correct community string or SNMPv3 auth/priv keys Navigate to: Discovery → Administration → Credentials ☐ Credential is assigned to the correct IP range or MID Server affinity Credentials with no IP range apply globally; verify no conflicting credential exists ☐ SNMPv3 devices: auth protocol and priv protocol match what is configured on the device Common mismatch: device uses SHA-256 but credential is set to SHA (SHA-1) ☐ SNMP read access is enabled on the router for the MID Server's source IP Many routers have ACLs limiting which hosts can query SNMP. Confirm with the network team. ▶ Discovery Schedule Configuration ☐ Schedule type is set to "IP Networks" or "IP Ranges" (not "Computers") Navigate to: Discovery → Discovery Schedules; check the Type field ☐ Network Device Exploration is Active (ON) Critical: If this toggle is off, the Network Router pattern never runs — the CI is created but all fields stay blank. Check: Discovery Schedule → Network Device Exploration = Active. ☐ Router's IP address is within the schedule's target IP range Check all IP ranges defined on the schedule; loopback addresses (127.x, ::1) are excluded by default ☐ MID Server is active and assigned to the correct schedule or IP range Navigate to: MID Server → MID Servers; check Status = Up. Also verify MID Server can reach the router IP (no firewall blocking between MID and device). ☐ The ITOM Visibility plugin (sn_itom_pattern) is activated Required for horizontal patterns to run. Navigate to: System Applications → All Available Applications and verify "ITOM Visibility" shows as active. ▶ SNMP Classification Check The device must be classified as Network Router for this pattern to run. Classification depends entirely on the device's sysObjectID .

☐ A Classification rule exists for the device's sysObjectID pointing to the Network Router pattern Navigate to: Discovery → Administration → SNMP Classification; search by OID prefix or sysDescr contains string ☐ Classification CI type matches cmdb_ci_ip_router (not cmdb_ci_ip_switch) A mismatch here causes "Not exploring device because record was not created for main CI type" — see Section 4. ☐ Device sysObjectID can be retrieved: run snmpget -v2c -c 1.3.6.1.2.1.1.2.0 The OID returned (e.g., .1.3.6.1.4.1.9.1.xxx) must match a classification rule. If not, create a new rule.

3. Troubleshoot by Symptom ▶ Router not discovered at all (no log entry for this IP) Root cause: Scanning (Phase 1) failed. The Shazzam probe could not get any SNMP response from UDP 161.

Verify UDP 161 is open: nc -zuv 161 from the MID Server host. Check if a firewall between the MID Server and the router blocks SNMP traffic. Confirm the IP is within the schedule's target range. Confirm the MID Server is assigned to and actively processing this schedule. Check the Discovery log (Discovery → Discovery Log): filter by IP, look for "Shazzam" entries. ▶ Router discovered as wrong CI type (created as switch instead of router) Root cause: Classification matched the wrong rule. This is common with multi-layer switches (Layer-3 switches) that both route and switch, or with vendor OIDs not present in the SNMP Classifications table.

Get the device's sysObjectID : snmpget -v2c -c 1.3.6.1.2.1.1.2.0 Navigate to Discovery → Administration → SNMP Classification. Search for that OID. If the classification rule points to Network Switch, change it to Network Router (or create a new rule with higher priority). Classification rule fields: OID (the sysObjectID prefix), CI Type (must be cmdb_ci_ip_router ), Pattern (Network Router). Re-run Discovery. The existing CI class will not change automatically — you may need to delete the incorrectly classified CI first. Note: If the device legitimately does both routing and switching (e.g., Cisco Catalyst with routing enabled), classify it as cmdb_ci_ip_router and set can_switch=true on the CI manually, or extend the pattern to set it. ▶ CI created but serial number and model are blank Root cause (most common): The device does not support ENTITY-MIB, or SNMP read access to the entPhysicalTable OID (.1.3.6.1.2.1.47) is blocked by the device ACL.

Test ENTITY-MIB directly: snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1 If that returns nothing, the device does not support ENTITY-MIB. Some older or low-end routers do not. In that case, serial and model will always be blank from Discovery — populate them manually or via a custom SNMP probe targeting vendor-specific OIDs. If the walk returns data, check the pattern debug log (Section 6 → How to debug) for errors in the ENTITY-MIB collection step. Verify "Network Device Exploration" is ON on the schedule — without it, the pattern never collects ENTITY-MIB data. ▶ Network interfaces (network adapters) are missing or incomplete Root cause options:

ifTable walk fails: Community string has no access to the IF-MIB OID (.1.3.6.1.2.1.2). Test: snmpwalk -v2c -c 1.3.6.1.2.1.2.2 Loopback-only interfaces: Pattern may filter out virtual/loopback interfaces. Only physical interfaces matching ifType=ethernetCsmacd(6) or similar are typically created as CIs. Known defect KB0955160: SNMP Identity library bug causes the pattern to not list all network adapters. See Section 7 — Known Issues. Known defect KB0966460: Adapter CIs are created but MAC Address and Name fields are blank. See Section 7 — Known Issues. IRE identification failure: Adapter CIs may be silently dropped if the IRE cannot generate identifier keys. Check glide.discovery.ire_err_exclusion_list — NO_IDENTIFIER_KEYS_GENERATED is excluded by default, so failures are silent. ▶ Duplicate router CIs created Root cause: IRE cannot match the new discovery data to the existing CI. This typically happens when the serial number is blank (ENTITY-MIB not supported) and the management IP changes between discovery runs.

Check: does the device have a serial number? If not, IRE falls back to IP-address-only matching. If the IP changes (e.g., DHCP or re-IP event), a new CI is created. Review the IRE identifier rules for cmdb_ci_ip_router : navigate to CMDB → CI Class Manager → cmdb_ci_ip_router → Identification Rules. If the router is in glide.discovery.ire_err_exclusion_list exclusion scenarios, the creation silently fails — remove INSERT_FAILED from that list temporarily to surface the error. Merge duplicate CIs using CMDB → Suggested Remediations or manually via the CI record's Duplicate CI related list. ▶ Router CI name changes on every discovery run Root cause: Conflict between glide.discovery.hostname.snmp_trusted and DNS reverse lookup, combined with hostname.always_update=true .

If snmp_trusted=true (default), the name is taken from sysName SNMP OID (.1.3.6.1.2.1.1.5). Verify what the router reports: snmpget -v2c -c 1.3.6.1.2.1.1.5.0 If the router's sysName is inconsistent (e.g., includes domain on some runs and not others), set hostname.include_domain=false (currently: false on your instance). To lock the name after first discovery, set glide.discovery.hostname.always_update=false . ▶ Wrong router selected as "network owner" for an IP subnet Root cause: The glide.discovery.network_owner_method property controls which router is associated with each discovered IP network when multiple routers are found on the same subnet.

Value Behavior First Router First router to discover the network is the owner (non-deterministic in parallel discovery) Last Router Most recently discovered router wins Most Networks Router with the most attached networks is selected: Least Networks Router with the fewest attached networks is selected To change: navigate to Discovery → Administration → Properties and search for network_owner_method .

4. Error Message Reference These errors appear in the Discovery Log (Discovery → Discovery Log) and the Pattern Debug Log (Discovery → Discovery Schedules → [run] → Pattern Log).

▶ Failed Exploring CI Pattern, Pattern name: Network Router, Not exploring device because record was not created for main CI type. Phase: Exploration (Phase 4)

Cause: The SNMP Classification rule that matched this device has a CI Type that does not match cmdb_ci_ip_router . IRE creates the wrong CI type; the pattern then refuses to run against it.

Fix:

Navigate to Discovery → Administration → SNMP Classification. Find the rule matching this device's sysObjectID and change CI Type to cmdb_ci_ip_router . Delete the incorrectly typed CI, then re-run Discovery. ▶ No classifier found for device at Phase: Classification (Phase 2). No SNMP Classification rule matches this device's sysObjectID or sysDescr.

Get the sysObjectID: snmpget -v2c -c 1.3.6.1.2.1.1.2.0 Create a new SNMP Classification rule: OID = sysObjectID prefix, CI Type = cmdb_ci_ip_router, Pattern = Network Router. ▶ SNMP: Request timeout for / SNMP: Authentication failure Timeout: SNMP query sent but no response. Wrong community string or ACL blocks this OID range. Test: snmpwalk -v2c -c 1.3.6.1.2.1.1

Auth failure: SNMPv3 credentials mismatch (wrong auth password, wrong priv protocol, wrong security level). Test SNMPv3: snmpwalk -v3 -l authPriv -u -a SHA -A -x AES -X 1.3.6.1.2.1.1

Update the credential in Discovery → Credentials and use the "Test Credential" button to validate before re-running Discovery.

▶ IRE Error: NO_IDENTIFIER_KEYS_GENERATED (silent by default) Phase: Identification (Phase 3). IRE cannot generate identifier keys (serial_number blank, no valid IP). CI is not created. Silently suppressed because NO_IDENTIFIER_KEYS_GENERATED is in glide.discovery.ire_err_exclusion_list by default.

To surface it: Temporarily remove NO_IDENTIFIER_KEYS_GENERATED from that property, re-run Discovery, and check the pattern log.

▶ TypeError: Cannot convert null to an object (NetworkDevicesPostSensor) Phase: Exploration (Phase 4). Occurs on modular/stacked routers (e.g., Cisco 4500/6500) where the ENTITY-MIB does not contain a well-formed chassis parent row. The NetworkDevicesPostSensor script include encounters a null object when traversing the component hierarchy.

Check the ECC Queue output record for the full stack trace. Verify that a chassis row (entPhysicalClass=3) exists: snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1.1.5

5. System Properties Reference Navigate to: Discovery → Administration → Properties . Changes take effect on the next Discovery run.

Property Value Effect & When to Change glide.discovery.network_owner_method Most Networks Router-specific. Controls which router "owns" an IP Network CI when multiple routers are on the same subnet. Most Networks (recommended) picks the router with the most attached subnets — typically the core/distribution device. Options: First Router | Last Router | Most Networks | Least Networks . glide.discovery.hostname.snmp_trusted true When true , CI name is set from SNMP sysName instead of DNS reverse lookup. Recommended for network devices. Set false only if your routers have unreliable or generic sysName values. glide.discovery.hostname.always_update true When true , Discovery overwrites the CI name on every run. Manually entered names will be overwritten. Set false to preserve hand-entered names after first discovery. glide.discovery.ire_err_exclusion_list ABANDONED, INSERT_FAILED, UPDATE_FAILED, NO_IDENTIFIER_KEYS_GENERATED IRE errors in this list are suppressed from the pattern log. Caution: NO_IDENTIFIER_KEYS_GENERATED masks silent CI creation failures. Temporarily remove it when troubleshooting missing router CIs. glide.discovery.network_discovery.functionality SNMP only Defines the protocol used for network discovery. Default and recommended value. Do not change unless directed by ServiceNow Support. glide.discovery.hostname.case Lower case Applies case conversion to all discovered hostnames. Options: Lower case | Upper case | No change . Set to No change if your naming conventions require uppercase router names. glide.discovery.hostname.include_domain false When true , appends the DNS domain to the CI name (e.g., rtr-01.corp.example.com). Only affects DNS-sourced names; SNMP sysName is used as-is regardless.

6. Pattern Deep Dive & Step-by-Step Debugging How to enable pattern debug logging Navigate to: Discovery → Discovery Schedules → [your schedule] → Debug and set Network Device Exploration debug = ON. After the next run, open Discovery → Discovery Log → [run] → Pattern Log to see step-by-step execution, SNMP query results, and step-level errors. Disable after use — it significantly increases log volume. Group A: Session Initialization ▶ Step A1 Initialize SNMP session and test connectivity What it does: Establishes the SNMP session between the MID Server and the target router. Selects the SNMP version (v1/v2c/v3) and credential based on what was validated during Classification.

Requirements: UDP 161 open to MID Server. Valid credential assigned to this IP range. MID Server Up and network-reachable to the device.

OIDs queried: None (session establishment only).

Failure signs: "SNMP Request timeout" or "Authentication failure" in the pattern log. Pattern aborts here.

▶ Step A2 Resolve CI from IRE and verify CI type What it does: Retrieves the cmdb_ci_ip_router record created by IRE in Phase 3. Confirms the CI class matches the pattern's expected type.

Requirements: IRE must have successfully created a CI. SNMP Classification rule CI Type must be cmdb_ci_ip_router .

Failure signs: "Not exploring device because record was not created for main CI type." Fix: correct the classifier CI Type field.

Group B: System Information ▶ Step B1 Query SNMPv2-MIB system group What it does: Bulk GET on the system group OIDs (.1.3.6.1.2.1.1.1 through .6). Retrieves sysDescr, sysObjectID, sysUpTime, sysContact, sysName, sysLocation. sysName becomes the CI name when snmp_trusted=true .

OIDs: .1.3.6.1.2.1.1.1 through .1.3.6.1.2.1.1.6

CI fields set: name , short_description , firmware_version (parsed from sysDescr)

Debug: snmpwalk -v2c -c 1.3.6.1.2.1.1 — all 6 OIDs should return data.

▶ Step B2 Check IP forwarding status (ipForwarding) What it does: Queries the ipForwarding OID to confirm the device is actively forwarding IP packets. Value 1 = forwarding (router); value 2 = not forwarding (host). Sets can_route boolean on the CI.

OID: .1.3.6.1.2.1.4.1.0

CI field set: can_route

Note: Even if ipForwarding returns 2 (not forwarding), the pattern continues. The CI is still created.

Group C: Hardware Inventory (ENTITY-MIB) ▶ Step C1 Walk ENTITY-MIB entPhysicalTable What it does: Walks the entire ENTITY-MIB physical component table (.1.3.6.1.2.1.47.1.1.1). Returns a row for every component: chassis, modules, power supplies, fans, ports. Each row has an entPhysicalClass value identifying the component type (chassis=3, module=9, port=10).

OID: .1.3.6.1.2.1.47.1.1.1 (full table walk)

Requirements: Device must support ENTITY-MIB (RFC 2737). Test: snmpwalk -v2c -c 1.3.6.1.2.1.47.1.1.1 . Many low-end or older routers return nothing.

Failure signs: Empty response. Pattern continues — this step is non-blocking. Serial and model will be blank.

▶ Step C2 Extract serial number from chassis row What it does: Filters the ENTITY-MIB table for the row where entPhysicalClass=3 (chassis). Extracts entPhysicalSerialNum . For stacked/modular chassis (e.g., Cisco 4451-X with multiple line cards), only the first chassis row's serial is used.

OID: .1.3.6.1.2.1.47.1.1.1.1.11 (entPhysicalSerialNum, chassis row)

CI field set: serial_number

Failure signs: serial_number blank. Most common on virtual routers (CSR 1000v, IOS-XRv) and some Huawei/older devices that don't populate entPhysicalSerialNum.

▶ Step C3 Extract model name and manufacturer What it does: From the same chassis row, extracts entPhysicalModelName (e.g., "ISR4451-X/K9") and entPhysicalMfgName . The manufacturer string is matched against core_company to create or reuse a manufacturer reference.

OIDs: .1.3.6.1.2.1.47.1.1.1.1.13 (model), .1.3.6.1.2.1.47.1.1.1.1.12 (manufacturer)

CI fields set: model_number , manufacturer (reference to core_company)

Group D: Interface and IP Address Collection ▶ Step D1 Walk ifTable (interface inventory) What it does: SNMP walk of the entire ifTable . One row per interface indexed by ifIndex . Collects ifDescr, ifType, ifSpeed, ifPhysAddress (MAC), ifAdminStatus, ifOperStatus. The ifIndex is the JOIN key used in Step D3 to correlate with IP addresses and ifXTable.

OIDs: .1.3.6.1.2.1.2.2 (full walk), sub-OIDs: .2.1.1 (ifIndex), .2.1.2 (ifDescr), .2.1.3 (ifType), .2.1.5 (ifSpeed), .2.1.6 (MAC), .2.1.7 (ifAdminStatus), .2.1.8 (ifOperStatus)

CI fields fed into: ports , physical_interface_count

Failure signs: No network adapters created. Test: snmpwalk -v2c -c 1.3.6.1.2.1.2.2 . Large ASR/ISR routers with thousands of sub-interfaces may time out on this walk.

▶ Step D2 Walk ifXTable (extended interface data) What it does: Extends ifTable data with the ifXTable . Most importantly retrieves ifName (the configured interface name, e.g., "GigabitEthernet0/0/0") and ifHighSpeed in Mbps for interfaces where ifSpeed wraps at 4.29 Gbps. Also retrieves ifAlias (the interface description set by the network team).

OIDs: .1.3.6.1.2.1.31.1.1 including .1.1.1 (ifName), .1.1.6 (ifHighSpeed), .1.1.18 (ifAlias)

Failure signs: Adapter CI name shows numeric index instead of "GigabitEthernet0/0/0". Speed shows 0 or wrong value on 10G+ interfaces.

▶ Step D3 Walk ipAddrTable (IP to interface mapping) What it does: Walks the IPv4 address table to get every IP address configured on the router, the ifIndex it is bound to, and the subnet mask. This data is joined with ifTable in Step D4 to associate IPs with interface names.

OIDs: .1.3.6.1.2.1.4.20 including .1.1 (ipAdEntAddr), .1.2 (ipAdEntIfIndex), .1.3 (ipAdEntNetMask)

Failure signs: Adapter CIs have no ip_address. IPv6-only interfaces are not captured here (ipAddrTable is IPv4-only — see Known Issues).

▶ Step D4 (5.38) Match interfaces to IP addresses Referenced in known bug KB0955160. An SNMP Identity library issue at this step causes some adapters to be dropped from the output. What it does: In-memory JOIN of ifTable/ifXTable (Steps D1/D2) with ipAddrTable (Step D3) using the shared ifIndex key. Result is a merged list where each interface has: name (ifName), MAC address (ifPhysAddress), IP address (ipAdEntAddr), subnet mask (ipAdEntNetMask). Interfaces with no IP (loopbacks, unconfigured ports) are still included but have no IP associated.

No new SNMP query — pure in-memory data processing using results from D1–D3.

Failure signs: Fewer adapters than expected. If Steps D1 or D3 returned incomplete data, the merged list is also incomplete.

Group E: Routing Table and ARP ▶ Step E1 Walk ipRouteTable (routing table) What it does: Walks the routing table. Each row: destination network, subnet mask, next-hop gateway, metric, interface index, and routing protocol. Discovery uses this to: (1) set default_gateway from the 0.0.0.0/0 default route; (2) calculate which router "owns" each IP Network CI per glide.discovery.network_owner_method .

OIDs: .1.3.6.1.2.1.4.21 including .1.1 (ipRouteDest), .1.6 (ipRouteNextHop), .1.7 (ipRouteType), .1.8 (ipRouteProto), .1.11 (ipRouteMask)

CI field set: default_gateway

Caution: Internet-edge routers receiving a BGP full table (700K+ routes) may cause this walk to time out. See Known Issues — BGP full-table routers.

▶ Step E2 Walk ARP table (ipNetToMediaTable) What it does: Walks the ARP cache to get IP-to-MAC mappings for directly connected devices. Used by the dynamic connections companion pattern to build L2/L3 topology relationships between the router and adjacent CMDB-registered devices.

OIDs: .1.3.6.1.2.1.4.22 including .1.2 (ipNetToMediaPhysAddress/MAC), .1.3 (ipNetToMediaNetAddress/IP)

Failure signs: No connection CIs created between the router and servers. ARP table empty if the router recently rebooted or SNMP has no access to the ip MIB group.

Group F: Neighbor Discovery (LLDP / CDP) ▶ Step F1 Query LLDP neighbor table (all vendors) What it does: Walks the LLDP Remote Systems Table to discover adjacent network devices announced via IEEE 802.1AB Link Layer Discovery Protocol. Returns: neighbor chassis ID (usually MAC), port ID, system name, system description. Supported across all major vendors (Cisco, Juniper, Arista, HPE, etc.).

OIDs: .1.0.8802.1.1.2.1.4.1 (lldpRemTable) including .1.4 (ChassisIdSubtype), .1.5 (ChassisId), .1.6 (PortIdSubtype), .1.7 (PortId), .1.9 (SysName), .1.10 (SysDesc)

Non-blocking: If LLDP is disabled on the router, the pattern continues. Verify LLDP is enabled on the device and the SNMP community can read this OID tree.

▶ Step F2 Query CDP neighbor table (Cisco devices only) What it does: For Cisco IOS/IOS-XE/IOS-XR devices, queries the CDP neighbor table. CDP provides richer Cisco-specific data than LLDP: device ID, IP addresses, platform string, port ID, and capabilities bitmap. If both LLDP and CDP data are available for Cisco-to-Cisco neighbors, CDP data takes precedence.

OIDs: .1.3.6.1.4.1.9.9.23.1.2.1 (cdpCacheTable) including .1.5 (DeviceId), .1.6 (DevicePort), .1.7 (Platform), .1.8 (Capabilities), .1.11 (Address)

Non-blocking: CDP is Cisco-only and may be disabled ( no cdp run in IOS). Non-Cisco routers will simply return empty results at this step.

Group G: CI Creation and CMDB Write ▶ Step G1 Create or update cmdb_ci_ip_router CI What it does: Writes all collected data to the router's cmdb_ci_ip_router record. The CI was pre-created by IRE in Phase 3 with minimal data; this step fills all hardware and configuration fields. IRE is invoked again here to handle deduplication before the write.

Fields written: name, serial_number, model_number, manufacturer, firmware_version, ports, physical_interface_count, default_gateway, can_route, can_switch, bandwidth, last_discovered, discovery_source

Failure signs: Router CI fields remain blank. Check the ECC Queue for job errors. Check IRE log (enable via glide.discovery.ire_logs_in_patterns=true ).

▶ Step G2 (5.40) Create cmdb_ci_network_adapter CIs per interface Referenced in known bug KB0966460: In affected versions, adapter CIs are created but MAC Address and Name fields are blank, causing IRE identification failures on subsequent runs. What it does: For each interface in the merged list from Step D4, creates one cmdb_ci_network_adapter CI linked to the parent router via an "Owns" CI relationship. The adapter CI stores: name (ifName), MAC address (ifPhysAddress), IP address (ipAdEntAddr), subnet mask, speed, admin status, and operational status.

Fields written to adapter CI: name, mac_address, ip_address, netmask, speed, operational_status, admin_status

Failure signs: Blank Name/MAC (KB0966460). No adapters at all (Step D1 failed). Fewer adapters than expected (Step D4 matching bug KB0955160).

▶ Step G3 Create dynamic connections (companion pattern) What it does: The companion pattern "Create connections to dynamic cmdb_ci_ip_router table" runs after the main Network Router pattern. Uses ARP (Step E2) and LLDP/CDP neighbor data (Steps F1/F2) to create L2/L3 connection CIs linking the router to other network devices and servers already in the CMDB. Used for network topology visualization.

CI types created: sn_cmp_connection (connection CIs), dscy_router_interface (routing interface entries)

Failure signs: No topology/connection records for this router. Connections are only created to devices already in the CMDB — the router's ARP neighbors must have been previously discovered.

7. Known Issues & Limitations ▶ KB0955160 — Network Router pattern not listing all network adapters (SNMP Identity library) Pattern step Step D4 (5.38) — interface-to-address matching Symptom Router CI created but only a subset of network adapter CIs are created. Not all physical interfaces appear in the CMDB. Root cause Bug in the SNMP Identity library causes the interface-to-address JOIN to drop valid interfaces when certain ifIndex values are present. Workaround Apply the fix version noted in KB0955160. Until patched, verify interface count: snmpwalk -v2c -c 1.3.6.1.2.1.2.2.1.2 and compare to CMDB adapter count. ▶ KB0966460 — Network Router pattern creates network adapters with blank MAC Address and Name Pattern step Step G2 (5.40) — cmdb_ci_network_adapter creation Symptom Adapter CIs created for router interfaces but name and mac_address fields are blank. Subsequent runs create duplicate adapter records (IRE cannot match by MAC). Root cause The adapter CI creation step does not correctly pass ifName and ifPhysAddress values from the merged interface list into the IRE input payload. Impact Topology connections cannot be built by MAC. CMDB search by MAC will not find router interfaces. Duplicate adapter CIs on every run. Workaround Apply the fix version in KB0966460. Until patched, manually populate Name and MAC on adapter CIs and flag them as managed_manually to prevent Discovery from blanking them. ▶ Router / Switch misclassification (multi-layer switches classified as router or vice versa) Devices that both route and switch (Cisco Catalyst 9000/4500/6500, Nexus, Juniper EX) may be classified as either router or switch depending on which SNMP Classification rule matches first. Two separate rules may both match the same sysObjectID prefix.

Get the exact sysObjectID: snmpget -v2c -c 1.3.6.1.2.1.1.2.0 In SNMP Classification, find and adjust the matching rule CI Type and Pattern. If the device legitimately routes and switches, classify as cmdb_ci_ip_router and set can_switch=true on the CI. Delete the misclassified CI and re-run Discovery. ▶ BGP full-table routers: ipRouteTable walk times out Internet-edge routers receiving a BGP full table (700K+ IPv4 routes) may cause the ipRouteTable walk to time out or return incomplete data. The MID Server's default SNMP timeout is insufficient for a walk of hundreds of thousands of OID rows.

Symptoms: default_gateway blank; wrong router selected as network owner; SNMP timeout in the routing table step of the pattern log.

Options:

Increase SNMP timeout in MID Server config: mid.snmp.timeout (default 5000ms). Limit Discovery to a non-BGP management interface on the router using a specific IP range in the schedule. If routing table data is not needed, consider customizing the pattern to skip the ipRouteTable step. ▶ Virtual routers (CSR 1000v, IOS-XRv, vMX) have blank serial numbers Virtual router appliances on hypervisors have no physical chassis and do not report a hardware serial number via ENTITY-MIB. Without a serial number, IRE uses only the IP address as the identifier.

Impact: If the virtual router's IP changes (re-deploy, re-IP), a duplicate CI is created.

Options:

For CSR 1000v: a Cisco UDI may be available from .1.3.6.1.4.1.9.9.176.1.1.3 . Create a custom sensor to read this OID and populate serial_number . Manually populate the serial number field and add it to the IRE identifier rule. For VMs with stable IPs, IP-only identification is acceptable. ▶ IPv6-only interfaces not captured in ipAddrTable The standard ipAddrTable (.1.3.6.1.2.1.4.20) is IPv4-only (RFC 1213). Dual-stack or IPv6-only interfaces are enumerated in ifTable but have no IP address associated in the adapter CIs.

Impact: Network adapter CIs for IPv6 interfaces have no ip_address populated. L3 topology is incomplete for IPv6 networks.

Resolution: The newer ipAddressTable (.1.3.6.1.2.1.4.34, RFC 4293) supports both IPv4 and IPv6. A custom pattern extension is required to query this OID and map IPv6 addresses to interfaces.

ServiceNow Discovery — Network Router Pattern | Zurich / Xanadu | cmdb_ci_ip_router | June 2026 For questions or corrections, use the feedback button on this article. Related guide: Network Switch Discovery — Complete Troubleshooting Guide .