How to Populate CI Location Based on IP Address

[spaceyjacey]

We would like to populate our CIs based on the ip address. For instance, if the CI's ip address is 10.6.4.16, the ".6" means that CI is physically located in our Washington DC office.

[dturner]

Hello,

We've done this with a little scripting on the hardware and relationship tables. This may be of use:

// Get the Location and Company of the CI from the network it's on

CILocation();

function CILocation(){

  var CI = current.sys_id.toString();

  var CiIp = current.ip_address;

      if (JSUtil.nil(CiIp))

              return;

      var network = this._getNetwork(CiIp);

  if (network.next()){

  this._createRelationship(network.sys_id, CI, "IP Connection::IP Connection");

  }

  var CISubnet = "";

  var rel = new GlideRecord('cmdb_rel_ci');

  rel.addQuery('parent', CI);

  rel.addQuery('type.name', 'IP Connection::IP Connection');

  rel.query();

  while (rel.next()){        

  CISubnet = rel.child;

  }

  var CILocation = CISubnet.router.location;

  current.location = CILocation;

}

  _getNetwork: function(ip) {

              var intIP = this._IPToNum(ip);   // Convert the IP dot-decimal to integer

              if (!isNaN(intIP)) {

                      //find the Network that this IP is a part of

                      var grNet = new GlideRecord('cmdb_ci_ip_network');

                      grNet.addQuery('lo_ip', '<=', intIP);

                      grNet.addQuery('hi_ip', '>=', intIP);

                      grNet.addNotNullQuery('router');

                      grNet.query();

                      return grNet;

              }else{

                      return;

              }

      },

_createRelationship: function(parent, child, pDescription, cDescription) {

              if (JSUtil.nil(parent) || JSUtil.nil(child))

                      return;

              var parentId = parent;

              var childId   = child;

              //If parent or child is a GlideRecord object, we need to extract the sys_id

              if (parent instanceof GlideRecord)

                      parentId = parent.sys_id;

              if (child instanceof GlideRecord)

                      childId   = child.sys_id;

              if (!cDescription && pDescription.indexOf("::") > -1) {

                      var parts = pDescription.split("::");

                      pDescription = parts[0];

                      cDescription = parts[1];

              }

              var ECMDBUtil = Packages.com.glideapp.ecmdb.ECMDBUtil;

              return ECMDBUtil.createCIRelationship("cmdb_rel_ci", parentId, childId, pDescription, cDescription);

      },

Please let me know if anything's amiss.

[Rick Mann]

I set the location value when we run discovery, but we also set a CI data center value based on the IP address.   I have a Before Insert and Update business rule that runs on the cmdb_ci table.   Probably not the most sophisticated way of doing this, but it works for us.   Here a sample of my script:

var ip = current.ip_address.getDisplayValue();

if(ip.indexOf("10.96")== 0) {

    current.u_data_center = '763050d10a0a3c490181bf047fb5cd39';   //Docklands Data Center

}

if(ip.indexOf("10.102")== 0) {

    current.u_data_center = '763050d10a0a3c490181bf047fb5cd39';   //Docklands Data Center

}

[john_duchock]

Another solution would be to manage the discovery schedules more tightly.   This would mean partnering with your LAN/WAN folks to get the right IP ranges.   An example would be:

Schedule Name	IP Range	Location	Comments
DCAZ-5	10.192.5.0/24	Datacenter A, Zone 5	Unix / Linux / AIX zone
DCAZ-7	10.192.7.0/24	Datacenter A, Zone 7	Windows / MSSQL zone
DCAZ-9	10.192.9.0/24	Datacenter A, Zone 8	Avaya / Cisco Phone
WCA1-14	10.192.14.0/24	Wiring Closet, Building A first floor	Client Systems / Printers
WCA2-15	10.192.15.0/24	Wiring Closet, Building A second floor	Client Systems / Printers

This allows you to populate the location field with the building/floor information, and if you are discovering user devices (laptops and desktops), you are probably already getting the "assigned to" field populated with last logged in user.   Finally, you can update the user file with a field for "desk location" which could be validated using Data Certification (if you can find a user/desk relationship owner).   The end result (with a bit of extra work for data center CI's and related lists) is a pretty nice BSM map...

[phsdm]

When we upgraded to Istanbul, we built out our MID Server IP Ranges to support Service Mapping.   At that point, designing discovery schedules seems like an unnecessary bother.   We can use large ranges and throttle the ECC queues.

At that point, importing subnet/location information into IP Networks [cmdb_ci_ip_network] seems less labor intensive.

I suppose you could script a rebuild of your schedules and IP ranges based on the subnet/location information, but that feels like a redundant duplication of effort over a BR directly against the Configuration Item table.

[glennpinto]

If you have the ability to create schedules based on target IP ranges that relate to a specific location, you can then set the appropriate location value in the Discovery Schedule record without any need to script anything. Just another option some of our customers have implemented.