Automated IP Addition for VM discovery post Cloud Discovery

[srikanthnelapud]

Overview

Recently I've dealt with a few cases that are resulted due to the confusion or the knowledge gap regarding how the IP Discovery Schedule works after the Cloud Discovery when opted for, during the Cloud Discovery Schedule creation so the purpose of this article is to broadcast the knowledge to a wider audience to help out the user at the earliest time possible.

This article addresses customer concerns like:

• Script pointers for the IP information fetching for the IP discovery post-Cloud Discovery run
• How the IPs are considered for various Clouds
• Possible Situations when an IP Discovery Run can go to Cancelled state

Please note this article provides the data pointers which are sufficient enough to understand the configuration detail and not the in-depth walkthrough.

Script pointers for IP information fetching for the IP Discovery post-Cloud Discovery run

Once the Cloud Discovery is complete, the flow goes to the method "populateIPAddressList" method in the "CloudDiscoveryScheduleConfig" Script Include (sys_id=96891f3953f313007f3c48f153dc348b).
 

How the IPs are considered for various Clouds

We've separate flow for VMWare and others (AWS / Azure / GCP). As we dealing with the "Azure" Cloud, let me elaborate on the flow.

For Non-VMWare:

STEP 1: Query the VM Instance table whose STATE==On
STEP 2: Now get the respective "cmdb_ci_endpoint_vnic" entries for above VMs
**STEP 3: From the endpoint vnic information, get the NIC entries ("cmdb_ci_nic") and gather the IP
STEP 4: Once all the IPs are gathered for all the VMs, pass the same list to the IP Schedule dynamically.

For VMWare:

STEP 1: Query the vCenter Datastore table ("cmdb_ci_vcenter_datastore") based on the Datacenter selected
STEP 2: For each datastore, Query the associated VMs i.e., entries from the VMWare Instance table ("cmdb_ci_vm_instance")
**STEP 3: For each VM, Query the associated NIC ("cmdb_ci_nic") entries
STEP 4: From each filtered NIC entry, grab the ip_address
STEP 5: Once all the ip_addresses are gathered for all the VMs, pass the same list to the IP Schedule dynamically.

Please note that the above discovery works for  private_ip starting "Quebec" and "Paris Patch5"  onwards. The issue for private IPs is fixed via defect (PRB1433691).

With the above-mentioned detail, the IP addresses are fetched dynamically i.e., Once the Cloud Schedule finishes its execution, we take all the VMs that are discovered for the datacenters selected and IP addresses are gathered and provided to the IP Schedule for that run. This is how the addition of IP ranges of the VMs discovered via Cloud Discovery is automated. That's the reason when you open the respective IP Schedule from the Discovery Schedules list, the IP ranges will be empty, in that stand-alone/static platform UI screen.

Possible Situations when an IP Discovery Run can go to Cancelled state

USE CASE - 1: None of the VMs have the IPs thus no IPs are inputted for IP Schedule to scan/discover.
[POSSIBLE SOLUTION]: Have an IP associated, via the Cloud Console, for the VM(s) deployed and rerun the Cloud Discovery.

** USE CASE-1 is applicable only for Paris Patch 4 and earlier releases.

USE CASE - 2: IPs are available but not reachable by the MID/MID Cluster selected
[POSSIBLE SOLUTION]: Check where the MID is located and if the host is reachable via a simple "ping" test

USE CASE - 3: IPs available, Host is reachable to VM, but no Credentials available
[POSSIBLE SOLUTION]: Ensure the credentials are created in the SN Instance.
Please note, in this situation, the discovery status will stop at the Classification stage only

USE CASE - 4: IPs available, Host is reachable to VM, but ports aren't configured properly
[POSSIBLE SOLUTION]: Ensure the ports of the hosts are properly configured
Please note, in this situation, the discovery status will stop at the Shazzam stage only

USE CASE - 5: IPs of a few are considered but not others during the IP schedule
[POSSIBLE SOLUTION]: We do run the IP discovery only on the ACTIVE VMs i.e., Vm's state==on but not on Retired/Terminated VMs so please double-check.

Apart from the above use cases, please keep an eye on the ECC Queue(s) of the Discovery Status of IP Schedule because the IP schedule may fail for various reasons while the IPs of the VMs are still included in the Discovery Status. You can observe in the Payload of the ECC Queue entry whose topic is Shazzam / Classification Stage.

[shank1]

Hi - I don't think customers will allow Public IPs to be pingable and discoverable. Any reason for considering public IP rather than Private IPs

[srikanthnelapud]

Hello Shank,

One primary reason for considering the public IP is to avoid dependency with the MID Server and to reach out to those VMs/Hosts deployed in the Cloud. If we associate Public IPs to those target machines then no matter where the MID server is installed, MID will be able to ping the hosts and run discovery over then but that's not the same case when you consider Private IPs because for MID server should be in the same Network/Subnet in order to ping those VMs and proceed further with the discovery.

Above all, based on the multiple customer(s) request(s), the private IPs are also considered along with the public IP during the IP Discovery post Cloud Discovery Schedule. This enhancement is available out of the box when the customer(s) upgrades to the Quebec release

The same is backported to Paris Patch 5 release.

I hope the above answers your question. Please let me know if you need any more related information.

Thanks,

Srikanth N.

[Runjay Patel]

Check out this video, it will clear all your doubts and help you to understand Cloud Discovery queries in details.

Link: https://www.youtube.com/watch?v=GWAvGbnCmlQ&ab_channel=ServiceNowHelpdesk

It help you to understand below points.

• Cloud Discovery
• Cloud Service Mapping vs Discovery
• Steps by step setup
• Practice with real world scenario
• Troubleshooting
• CI Class Tables and Attributes
• Amazon AWS Cloud Discovery Step by Step Configuration
• Azure Cloud Discovery Step by Step Configuration

Please mark reply as Helpful/Correct, if applicable. Thanks!!

[Bob D]

Why does this feature run IP discovery only on IP addresses of Virtual Machines?  What about other cloud resources that have IP addresses that need IP discovery (cloud firewall, for example)

It would seem this After Discovery IP scan feature is a way to avoid creating IP-based Discovery Schedules for cloud subnets.  This would be a wonderful feature.  However, we have cloud-based firewalls.  If these devices are not included in the After Discovery schedule, then we must still create IP-based schedules for all of our cloud subnets. And this defeats the point of having the After Discovery feature.  In fact, then we should not run the After Discovery since then the servers hosted on Virtual Machines are scanned twice.

Do I properly understand how this works?  If so, then the After Discovery IP scan feature is not useful to us.

thank you