The CreatorCon Call for Content is officially open! Get started here.

Disable data collection on router interface and next hop routing table while discovery

shrutivsriv
Tera Contributor

Hey Everyone,

I need some help in stopping the data collection in dscy_router_interface and dscy_route_next_hop tables. These are used by several patterns like network switch, Linux server etc. Although I tried a resolution given by dough in one of the posts and removed the route field value from the SNMP routing probe but it is still discovering. I even tried to disable sensors, that's also not working. Also, I tried to disable identifier altogether but that is resulting in failing of parent pattern and stopping the discovery of ip_router, ip_switch, linux server etc. Please let me know if anyone was able to fix this as we need to stop the discovery as these tables have 900K+ data in the environment and we no longer want to have it.
Thanks in advance!

3 REPLIES 3

dbook
Kilo Sage

You can create IRE Data Source Rules. No customisations of Patterns required, just using OOB functionality. 

 

You'll need at least one rule for each table. 

 

Example:

Applies to: dscy_router_interface

Data Source: ServiceNow

Insert not allowed: True

 

This will result in any Insert attempting to be made by ServiceNow Discovery to not occur. If you have multiple Discovery sources, than create a rule for each source per table. 

Hi @dbook 

Thanks for your input, but this is also not working may be due to the non cmdb table values. PLease suggest if you have any other suggestions.
Thanks in advance.

dbook
Kilo Sage

dscy_router_interface is a CMDB table and can be found in CI Class Manager here: Configuration Item>Network Infrastructure Item>Router Interface. 

 

  1. What rule(s) have you set up for IRE Data Source Rules? 
  2. Does the rule actually match the insert you are trying to prevent? E.g. is the Discovery source on the CI actually 'ServiceNow' or is it a different source, e.g. Azure Service Graph? 

Note; this will only prevent inserts. So to fully test this once fully configured you'll need to delete the CI and rerun the relevant Discovery schedule / job.