This is Part 3 of an ongoing series about using Nautobot and Nautobot’s Lifecycle Management Application to help you with your device hardware and software planning. We will be looking at v1.0.2, which is the latest version at the time of writing this blog.

If you haven’t read Part 1 or Part 2, please give them a quick glance. These parts examine the basic building blocks that Nautobot’s Lifecycle Management Application uses to manage the device and software objects in Nautobot.

In this part we will dive into how Nautobot can help you by looking at various aspects of the Lifecycle Management Application.

What Does the Application Provide?

Throughout my time as a network engineer, device/software lifecycle was a major financial and time-consuming task. Usually my time was spent looking through our source of record for devices and parsing out the devices that were a certain hardware or making a filter to find out what devices were on a certain software, to see what needed to be replaced/upgraded. If not that, it would be a spreadsheet or an email that had a list of hardware that just said we need to upgrade or update these devices.

I would have loved to have had a centralized place that had all the software/hardware end-of-life (EoL) dates along with various other EoL data. During that time I had to go to Cisco’s website or Juniper’s website to gather all the information I needed to get EoL data for the devices/software I was working with.

This application helps to manage life cycle[en dash]related data, such as end-of-life dates, viable software versions, and maintenance contract information. All of this helps to provide valuable life cycle planning including maintenance events and hardware events.

Getting Started with DLM Application

First, you will need to add the application to your Nautobot instance. There is a guide here.

Once you have the application installed, you will see that you now have a drop-down menu that you can click on, and it should look like the one below.

There are various items that make up the application, as you can see. So let’s dive into some of these!

Hardware Notices

Hardware notices are a great way to have a centralized location for EoL data for specific hardware. Let’s look at example hardware notices from demo.nautobot.com. You can assign device model objects or inventory item objects to these hardware notices either through the GUI or through the ORM using something such as a Nautobot job or Nautobot’s API.

• Devices – This will autopopulate once you assign device model objects or inventory item objects to the hardware notice. If you click on the individual device, you will be forwarded to the device’s summary page (required when creating notice).
• Device Type – If a device type object is assigned to the hardware notice, you will see that here. If you click on the device type, you will be directed to the summary page of that type; and from there you can click on instances to view all objects associated to the device type.
• Inventory Item – If an inventory item object is assigned to the hardware notice, you will see that here.
• End of Sale – Date of the vendor’s end of sale. When using an automated approach, you need to populate with “YYYY-MM-DD” format (required when creating notice).
• End of Support – Date of the vendor’s end support. When using an automated approach, you need to populate with “YYYY-MM-DD” format (required when creating notice).
• End of Software Releases – Date of the vendor’s end of software releases for the hardware. When using an automated approach, you need to populate with “YYYY-MM-DD” format.
• End of Security Patches – Date of the vendor’s end of security patches for the hardware. When using an automated approach, you need to populate with “YYYY-MM-DD” format.
• Documentation URL – Vendor’s URL or in-house URL that engineers can read over about the hardware dates and information.
• Comments – You can fill in any comments regarding the hardware notice that can be filtered by using a GraphQL query or other filter in Nautobot’s ORM.
• Tags – You can assign tags that you have created to tie in other objects, if needed.

Once you have assigned the hardware notice to either a device model or inventory item, you will see on the device’s page the linked hardware notice.

You will also see the hardware notice tied to the device type object:

Software (Notices)

The same goes for software notices. These are a great way to have a centralized location for EoL data for specific software. Let’s look at example software from demo.nautobot.com. You can assign software Nautobot objects to devices either through the GUI or through the ORM using something such as a Nautobot job.

Let’s look at what the software object has to offer.

• Device Platform – The Nautobot platform object that is attached to the software (required when creating).
• Software Version – This is the version of the software (required when creating).
• Release Date – Date of the vendor’s software release. When using an automated approach, you need to populate with “YYYY-MM-DD” format.
• End of Support – Date that the vendor’s support for the software will end. When using an automated approach, you need to populate with “YYYY-MM-DD” format.
• Documentation URL – Vendor’s URL or in-house URL that engineers can read over about the hardware dates and information.
• Long-Term Support – You can pick (True) or (False) regarding the software having long-term support in the network.
• Pre Release – If the software is in testing or evaluation you can state that here.
• Running on Devices – You will need to assign the software to devices when creating the software object. This is easier using Nautobot’s ORM in, for instance, a Nautobot job, which I will be talking about in Part 4.
• Running on Inventory Items – You will need to assign the software to inventory items (if any) when creating the software object.
• Corresponding CVEs – Any CVEs that vendor has can be listed here when you create the software object.
• Tags – You can assign tags that you have created to tie in other objects, if needed.
• Alias – This is not shown in the above screenshot, but you can add this when creating the software object. Some vendors have same version name; so when you are using the ORM to update software information, you will need to filter on the Alias, which should be unique. For example: – (e.g., Cisco IOS – 12.2(33)SXI14).

Once you have assigned the software object to either devices or inventory items, you will see the linked software object (notice) on the device’s page. We will explain validated software further down in the blog.

Software Images

Software images is a location where you can store various attributes for the software images you are currently using in the network. This software image object can be used in Nautobot’s API or ORM when you want to build jobs around automating software upgrades or validations.

Once you select your software image, you will be sent to all the attributes tied to that software image.

• Software Version – This is the Nautobot Software object that will be tied to the software image (required when creating).
• Image File Name – Name of the software image (required when creating).
• Download URL – Vendor’s URL or in-house URL where the software file can be downloaded. Only HTTP and HTTPS are currently supported, as of 1.4.0.
• Image File Checksum – Checksum of the file to use as validation when the file is downloaded.
• Default Image – You can set this as a default image to be used on, say, specific hardware model types.
• Tags – You can assign tags that you have created to tie in other objects, if needed.
• Device assignments – Devices that are assigned this software image. This will be done when the software image object is created. (At least one assignment is needed.)
• Inventory Items assignments – Inventory items that are assigned this software image. This will be done when the software image object is created. (At least one assignment is needed.)
• Object Tags assignments – Object tags that are assigned this software image. This will be done when the software image object is created. (At least one assignment is needed.)

Now you can see that the software object has its software image tab populated.

Validated Softwares

Validated softwares is the software that has been vetted by the teams and approved to be used in the network. Validated softwares are also used in the lifecycle job to compare software versions of devices to the validated softwares that should be on that device. If the software is not Preferred Version, then it will not be targeted by the software validation job.

• Software Version – This is the Nautobot Software object that will be tied to the software image (required when creating).
• Valid Start – The date that the software is valid for the network (required when creating).
• Valid End – Date when the software should be looked at to be replaced. This can be left blank and updated later.
• Valid Now – This will be updated automatically if the server date is greater than the Valid Start and Valid End dates.
• Preferred Version – This flag will be set so that when the software validation job is run, it will compare the software on device/inventory item to this specific software.
• Tags – You can assign tags that you have created to tie in other objects, if needed.
• Device assignments – Devices, Device Types, or Device Roles that are assigned this validated software. (At least one assignment is needed.)
• Inventory Items assignments – Inventory items that are assigned this software image. (At least one assignment is needed.)
• Object Tags assignments – Object tags that are assigned this software image. (At least one assignment is needed.)

A good way to tie the devices to the validated softwares is using tags, just in case you did not want to assign a device individually.

For one use case, I created the tag cisco_c6500_access; and every device that had that tag was meant to be on that validated software.

More about the validated software lifecycle job will appear in Part 4.

CVEs (Common Vulnerabilities and Exposures)

CVEs is a notice for vulnerabilities and exposures in either the hardware or software that you put in your network. This is potentially a security issue and should be assigned the highest urgency.

• Name – Name of the corresponding CVE (required when creating).
• Publish Date – The date that the CVE was published by the vendor (required when creating).
• Link – URL to the Vendor’s website regarding the CVE (required when creating).
• Status – Is the CVE active or not?
• Description – Description of the CVE.
• Severity – The current severity of the CVE, so that the teams can focus on higher-priority CVEs.
• CVSS Base Score – This will be given by the vendor in regard to the severity of the vulnerabilities or exposures.
• CVSSv2 Score – Different standards of severity levels.
• CVSSv3 Score – Different standards of severity levels.
• Fix – Any information on fixes for the software/hardware affected.
• Comments – Comments on what can be done, work-arounds, or next steps regarding software/hardware items that are affected by the CVE.
• Affected Softwares – This is not shown in the screenshot above; but when creating the CVE, you can assign it to certain softwares. Inventory Items and Device Types will be added to a later release.

Contracts

This is a centralized location for all the maintenance contracts that you have for various vendors. It includes start and end dates along with cost and support levels.

As you can see, there is quite a bit of information that you can assign to the contracts. You can assign devices to this contract when it is created, or you can create tags, as before, to link them.

Reports

The Device Lifecycle Application offers two different reports at the time of this writing.

• Device Software Validation – This page will give you a graphical summary of the device validation job that Nautobot has. This job runs against all the devices and compares them to the validated software that is assigned to each device or device type.
• Inventory Item Software Validation – This page will give you a graphical summary of the inventory item validation job that Nautobot has. This is a report that runs against all the inventory items and compares them to the validated software that is assigned to each device or device type.

The job that runs this is located in the Jobs tab, as shown below:

GraphQL Examples

I wanted to give a GraphQL example to look at the device software and validated software, since they were good learning headaches points I went through.

At the bottom of your Nautobot GUI there is a GraphQL link where you can test out queries if you like. Here is a sample query that will get you quite a bit of information if used in a GraphQL query. There are many more parameters that you can add if you want to gather more information.

query {
  devices {
    name
    rel_device_soft {
      version
      end_of_support
      documentation_url
      rel_soft_cve {
        name
        severity
      }
    }
  device_software_validation {
    software {
      version
      software_images {
        image_file_name
        download_url
      }
    }
    is_validated
  }
  }
}

With the query above, you will get a list of all the devices with the parameters queried. If there isn’t any data, it will show blank.

{
  "data": {
    "devices": [
      {
        "name": "ams01-dist-01",
        "rel_device_soft": {
          "version": "12.2(33)SXI14",
          "end_of_support": "2017-08-31",
          "documentation_url": "https://www.cisco.com/c/en/us/support/ios-nx-os-software/ios-software-releases-12-2-sx/series.html",
          "rel_soft_cve": [CVE-2022-3580]
        },
        "device_software_validation": {
          "software": {
            "version": "12.2(33)SXI14",
            "software_images": [
              {
                "image_file_name": "cat6k_caa-universalk9.12.2.33.SPA.bin",
                "download_url": "https://software.cisco.com/download/home/268437753/type/280805680/release/12.2.33SXI14?releaseIndicator=DEFERRED"
              }
            ]
          },
          "is_validated": true
        }
      },

Nautobot API Examples

Nautobot’s API can be leveraged to gather Device Lifecycle Application data.

Various endpoints below can be sent a GET, PUT, DELETE, PATCH. Also, with each URI endpoint /{id}/ can be attached to the end to get more specific.

/plugins/nautobot-device-lifecycle-mgmt/contact/
/plugins/nautobot-device-lifecycle-mgmt/contract/
/plugins/nautobot-device-lifecycle-mgmt/cve/
/plugins/nautobot-device-lifecycle-mgmt/hardware/
/plugins/nautobot-device-lifecycle-mgmt/provider/
/plugins/nautobot-device-lifecycle-mgmt/software/
/plugins/nautobot-device-lifecycle-mgmt/software-image/
/plugins/nautobot-device-lifecycle-mgmt/validated-software/
/plugins/nautobot-device-lifecycle-mgmt/vulnerability/

Example API Call

Using cURL:

curl -X 'GET' \
  'https://demo.nautobot.com/api/plugins/nautobot-device-lifecycle-mgmt/software-image/?device_name=ams01-dist-01' \
  -H 'accept: application/json'

Using Python Requests:

https://demo.nautobot.com/api/plugins/nautobot-device-lifecycle-mgmt/software-image/?device_name=ams01-dist-01

Output:

{
  "count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "display": "cat6k_caa-universalk9.12.2.33.SPA.bin",
      "id": "26c6c38a-102f-4ccc-8ace-308148f06de6",
      "url": "https://demo.nautobot.com/api/plugins/nautobot-device-lifecycle-mgmt/software-image/26c6c38a-102f-4ccc-8ace-308148f06de6/",
      "image_file_name": "cat6k_caa-universalk9.12.2.33.SPA.bin",
      "software": {
        "display": "Cisco IOS - 12.2(33)SXI14",
        "id": "cfe75355-e5b5-4d67-a4dd-a6fcf59e9cd8",
        "url": "https://demo.nautobot.com/api/plugins/nautobot-device-lifecycle-mgmt/software/cfe75355-e5b5-4d67-a4dd-a6fcf59e9cd8/",
        "device_platform": "df107d2a-b84f-4a30-9e48-093e9ad9a550",
        "version": "12.2(33)SXI14",
        "end_of_support": "2017-08-31"
      },
      "device_types": [
        "09dbb4e4-b258-4614-a85a-125f5c5caa9e"
      ],
      "inventory_items": [],
      "object_tags": [],
      "download_url": "https://software.cisco.com/download/home/268437753/type/280805680/release/12.2.33SXI14?releaseIndicator=DEFERRED",
      "image_file_checksum": "5de9de43040184c7de2de60456027f8c",
      "default_image": false,
      "custom_fields": {},
      "tags": [],
      "created": "2022-11-15",
      "last_updated": "2022-11-15T18:09:03.760005Z"
    }
  ]
}

What’s Next?

In the coming months I will be creating a specific blog post on each of the concepts mentioned below.

• Nautobot and Device Lifecycle – Hardware (Part 1)
• Nautobot and Device Lifecycle – Software (Part 2)
• Nautobot and Device Lifecycle – Nautobot’s Lifecycle Application (Part 3)
• Nautobot and Device Lifecycle – Vendor APIs and Nautobot Jobs (Part 4)

-Zack