Best Way to block the data insertion for Discovery tables

[Shubham_Jain]

I would like to block the data insertion for discovery tables as these tables does not gives any valuable data and it clutter the CMDB. 

Some example table is: Dscy_route_next_hop table. 

Suggest me best apporach to block the data insertion. 

The important point is that this should not write an message on system logs or any other tables in the platform. It just block the insertion. 

[Ram Devanathan1]

this is not a discovery table - Dscy_route_next_hop table

[Shubham_Jain]

@Ram Devanathan1  I have seen that these tables are getting populated from discovery. One of the example is - when we do the discovery of computer - it gets create some entities on these respective tables from discovery as source. 

[Ram Devanathan1]

You are right, i am sorry for the wrong information above without checking.. Thank you for correcting me.

The Dscy_route_next_hop table stores Next Hop Routing Rules, which are collected during the horizontal discovery of network devices such as routers and switches.

The data in the Dscy_route_next_hop table is typically gathered through SNMP using the IP Management Information Base (MIB) during the discovery of network devices. This data collection is integral to populating relationship information for IP Routers (cmdb_ci_ip_router) and IP Switches (cmdb_ci_ip_switch) that use Next Hop Routing Rules.

To stop data from being written to the Dscy_route_next_hop table, you need to disable the underlying mechanism responsible for discovering and populating network routing rules. Below are the primary methods supported by the sources to disable this data collection:

1. Disable Layer 3 (L3) Mapping System Property

The collection of routing and IP connectivity information relies on the L3 mapping functionality.

• Mechanism: The system property glide.discovery.L3_mapping controls whether servers and network devices are mapped to their associated routers and layer-3 switches. The discovery of routers and layer 3 switches that populate the Dscy_route_next_hop table requires this property to be set to true.
• Disablement Steps: Set the glide.discovery.L3_mapping property to false.
  1. Navigate to sys_properties.list.
  2. Search for and select the property glide.discovery.L3_mapping.
  3. Change the Value field to false.
  4. Select Update.

2. Disable Network Device Exploration via Configuration Console

If the data is being collected through traditional probes or patterns launched as part of the overall device information gathering process, you can disable the relevant exploration category.

• Mechanism: Disabling a Device Info category in the Discovery Configuration Console disables the related probes and pattern libraries that perform identification and exploration of the Configuration Item (CI). The discovery process for network devices generally includes Network Device Exploration.
• Disablement Steps: Disable the Network Device Exploration feature.
  1. Navigate to Discovery > Discovery Definition > Configuration Console.
  2. Expand the category for the device types (e.g., Network Devices).
  3. Locate and click the toggle button to turn off the specific device information you do not want to discover, such as Network Device Exploration.

3. Deactivate or Customize Network Router/Switch Patterns

If network routing data is collected via patterns, deactivating the patterns or modifying their content will stop the population of the table. The Dscy_route_next_hop table is referenced in relationships created by the Network Router pattern and the Network Switch pattern.

• Mechanism: Discovery uses the Network Router pattern and Network Switch pattern during horizontal discovery, which creates relationships that use the Dscy_route_next_hop table.

• Disablement Steps (Deactivation - Comprehensive but may halt core device discovery):

  1. Navigate to Discovery Definition > CI Classification > SNMP.
  2. Locate the classifier (e.g., for Routers or Switches) and ensure that the associated pattern is used (by checking the Horizontal Pattern probe in the Trigger probes related list).
  3. Navigate to the specific pattern in Pattern Designer > Discovery Patterns.
  4. To completely stop the pattern from running, clear the Active checkbox and select Update.

• Disablement Steps (Customization - Recommended Best Practice): A best practice is to duplicate the default probes/patterns and customize the copy, rather than modifying the out-of-box configuration.

  1. Duplicate the relevant Network Router or Network Switch pattern.
  2. Modify the duplicated pattern in the Pattern Designer to remove the steps (usually found in the Exploration phase) responsible for querying and collecting the next hop routing rule data from the network device.
  3. Update the corresponding CI Classification for the router/switch to use your custom pattern instead of the default pattern. You do this by selecting the Horizontal Pattern probe and specifying your custom pattern.

Analogy for Understanding Disablement

Stopping data flow into the Dscy_route_next_hop table is like controlling the input valves to a specific measurement gauge on a control panel.

• Disabling L3 Mapping (Method 1) is like shutting off the main plumbing line feeding all network connectivity gauges in that section of the building. It stops all layer 3 data collection globally.
• Disabling Network Device Exploration (Method 2) is like isolating the set of instruments specifically related to network configuration (the Network Device Exploration category), ensuring those particular gauges stop receiving updates.
• Customizing the Pattern (Method 3) is the most precise method, equivalent to modifying the specific sensor inside the gauge for "Next Hop Routing Rules" so that even if the line is open, that particular sensor simply ignores the incoming flow of data.

[VivekSattanatha]

These records are sometimes important for the Network team to understand Level 2 and Level 3 relationships for Routers and Layer 3 switches. While they are generated by the Network Switch and Network Router patterns, specifically using the 'SNMP-Routing' pattern library, disabling this pattern would solve the issue but is not recommended.

Instead, a better approach is to control which CMDB records are displayed to users. For example, we never expose the base cmdb_ci table records directly to users; similarly, you can filter visibility for these specific records rather than blocking their creation outright