If we disable L3 mapping in Discovery, will sa_network_paths still get populated by Service Mapping

[Martin Grosskop]

We are currently running Discovery with glide.discovery.L3_mapping = true.
And this in turn is creating a high volume of IP Connection::IP Connection relationships.
Which in turn brings in lots of Impacted Services to our Changes when we Refresh Impacted Services.

Whilst the links are genuine, our users don't quite get why their services are listed as impacted, when the link is quite a tenuous link via L3 - in some cases to routers running in other countries.

But we do not want to lose the ability for Service Mapping to display the Network Path between servers when you click on "Show Network Path".

From the digging we have done, it appears that the Network Path in Service Mapping is produced by reading the sa_networks_path table.

So if we set glide.discovery.L3_mapping = false, will we then stop creating IP Connection::IP Connection relationships, but Service Mapping will still be able to display the Network Path between two servers based on the trace route command Service Mapping issues while building a Service Map?

[johnnyjava]

I believe that you are correct, the network paths will not be populated if you do not collect this data.

[Larry Youngqui2]

We're facing the same issue.   Voluminous and tenuous links are captured.   We'd like to whittle it down to displaying the impactful connections, but are unsure how to throw the bath water out and still keep the baby. 

I'd also like to know if the trace route captured during Service Mapping can be effectively utilized to display a narrow, yet accurate set of connections.

[Martin Grosskop]

Hi Larry,

Feedback from a HI ticket on the same subject is that if we disable L3 mapping in Discovery, then Service Mapping will not be able to produce Network Paths.

So I guess it is time to long an Enhancement Request 

[Martin Grosskop]

Latest development on this matter:

I have logged an enhancement with ServiceNow to allow customers to be able to choose whether IP Connection:IP Connection relationships should be included or not when running the Refresh Impacted Services function in CIUtils.

In the meantime, this is what we have temporarly done to reduce "Noise" from the very tenuous Impacted Services determined from IP Connection:IP Connection relationships.

I wrote an alternative to CIUtils, which "front ends" the OOB CIUtils.

The idea is to work through the CIs on the task_ci table, and if the CI is a Switch or a Router, then to check whether that CI is mapped to any service via the service mapping table svc_ci_assoc.

If the router/switch is not mapped to any CIs via svc_ci_assoc, then don't put that into the array of CIs that will be used to determine impacted services.

Because we also have made use of Technical Services/Query Based Services, and many of our routers and switches are in these, hence to have entries in svc_ci_assoc anyway, I then checked whether any of the services that the router/switch maps to are Discovered Application Services.

If they do map to a Discovered Application Service, then they are included in the array of CIs that will be used to determine impacted services. If not, they are excluded.

Code snippet below: Apologies for lack of indentation - don't know how to copy and paste and still preserve indentation:( 

//Function to get all affected CIs for a specific task
getAffectedCIs: function (task_sysID) {
var affectedCIs = [];
var gr = new GlideRecord('task_ci');
//Get all affected CIs for the given task
gr.addQuery('task',task_sysID);
gr.query();
while (gr.next()) {

//check whether the CI is a Router or a Switch
var device = new GlideRecord('cmdb_ci');
device.addQuery('sys_id', gr.getValue('ci_item'));
device.query();
if (device.next()) {

if (device.sys_class_name == 'cmdb_ci_ip_router' || device.sys_class_name == 'cmdb_ci_ip_switch') {

//Now that we know the device is a Router or a Switch,
//check whether it is mapped to any Service via Service Mapping

if (this.mapsToDiscoveredApplication(gr.getValue('ci_item')))
//device is a Router or Switch that is mapped to one or more Services via Service Mapping,
//so add to the list of CIs for determining Impacted Services
affectedCIs.push(gr.getValue('ci_item'));
}

//CI is not a Router or Switch, so add to the list of CIs for determining Impacted Services
else {
affectedCIs.push(gr.getValue('ci_item'));
}
}

}
return affectedCIs;
},

//Function to check whether a CI maps to a Discovered Application Service
mapsToDiscoveredApplication: function(ciSysID) {
var mappedCI = new GlideRecord('svc_ci_assoc');
mappedCI.addQuery('ci_id', ciSysID);
mappedCI.query();

//Loop through services and check if any services are Discovered Application Services
while (mappedCI.next()) {
var svc = new GlideRecord('cmdb_ci_service_discovered');
svc.addQuery('sys_id',mappedCI.getValue('service_id'));
svc.query();
if (svc.next()) {
//Discovered Application Service found
return true;
}
}

//No Discovered Application Services found
return false;
},


//Add all impacted services for each CI in affected CIs
addAffectedServices: function(ciSysID, taskSysID){
var ciu = new CIUtils();
var services = ciu.servicesAffectedByCI(ciSysID);
var m2m = new GlideRecord('task_cmdb_ci_service');
for (var i = 0; i < services.length; i++) {
m2m.initialize();
m2m.task = taskSysID;
m2m.cmdb_ci_service = services[i];
m2m.manually_added = 'false';
m2m.insert();
}
},