Blog Detail
In the rapidly evolving world of network automation, the need for efficient management and seamless integration between different tools has become paramount. Device42 and Nautobot are two powerful applications that, when combined, offer enhanced capabilities for network engineers. We’re excited to announce the latest addition to our portfolio of Nautobot apps, the Single Source of Truth (SSoT) App for Device42! In this post, we’ll explore the capabilities of Device42 and how Nautobot SSoT for Device42 can augment its functionality, revolutionizing the way network infrastructure is managed and automated.
To learn more about Nautobot SSoT Apps (aka plugins), please see this blog post.
Nautobot SSoT for Device42 Overview
Device42 is a comprehensive infrastructure management platform that provides a holistic view of your network environment. It offers a range of features and capabilities designed to simplify infrastructure management and streamline the automation process. Some key capabilities of Device42 include:
Discovery and Inventory: Device42 automates the discovery and inventory process, allowing you to gain a complete understanding of your network infrastructure. It automatically discovers devices and their configurations and associated dependencies, providing accurate and up-to-date information. It is able to utilize multiple discovery mechanisms from Active Directory synchronization to SNMP polling. It also has the capability to integrate with other orchestration and ITSM products, such as Cisco ACI, Cisco UCS, and ServiceNow.
IP Address Management (IPAM): Device42 offers robust IPAM capabilities, enabling efficient management of IP addresses, subnets, VLANs, and DHCP/DNS services. It helps eliminate IP conflicts, simplifies subnet allocation, and improves overall network efficiency.
Dependency Mapping: Device42 maps dependencies between devices and applications, providing a clear understanding of the relationships and interactions within your infrastructure. This mapping enables better troubleshooting, change management, and capacity planning.
Rack and Cable Management: Device42 provides tools for managing rack layouts, cable connections, and data center infrastructure. This feature ensures accurate documentation of physical connections, simplifies troubleshooting, and aids in effective capacity planning.
With the wealth of information that Device42 contains, it serves as the perfect System of Record for network inventory and address allocations. With Nautobot acting as your Single Source of Truth, pulling network data from Device42 enables a continuously accurate inventory and reflection of the network state.
The Nautobot SSoT for Device42 application focuses on ingesting all network devices and related data from Device42. A full list of the supported objects is found in the following section. When utilized with Nautobot and its library of Apps, it enables multiple unique use cases, from utilizing Nautobot ChatOps framework to get information about your network to doing configuration compliance with the Nautobot Golden Config App.
Nautobot SSoT for Device42 Capabilities
The SSoT App for Device42 currently synchronizes the following objects:
Device42 | Nautobot |
---|---|
Building | Site |
Room | RackGroup |
Rack | Rack |
Vendor | Manufacturer |
Hardware Model | DeviceType |
Device | Device |
Cluster | VirtualChassis |
Port | Interface |
VRF Group | VRF |
Subnet | Prefix |
IP Address | IP Address |
VLAN | VLAN |
Provider | Provider |
Telco Circuit | Circuit |
Patch Panel | Device |
Custom Fields and Tags are both supported on all applicable models from Device42 into Nautobot.
Currently the synchronization is one-way from Device42 to Nautobot. While it is possible to push data from Nautobot to Device42, the focus for this release was to only pull data from Device42 in order to have an accurate reflection of the network state.
Building
The Device42 SSoT App will pull in all location-related data for Building objects including the following:
- Building name
- Building address
- Facility*
- Latitude
- Longitude
- Contact name and phone
The
facility
field will be imported into Nautobot only if thedefault42_facility_prepend
application settings is enabled with a corresponding Tag applied to the Building in Device42. The Site status can be updated by specifying the name of the Status in thedevice42_defaults["site_status"]
option. The default setting isActive
.
Room
The Device42 SSoT App treats Room as a child of a Building and requires that the Building be defined for the Room and that the Room name be unique. It will import the Room name and any notes applied to the Room.
Rack
The Device42 SSoT App treats Rack as a child of a Room and requires that the Building and Room are defined for the Rack. The name of the Rack must also be unique.
The Rack status can be updated by specifying the name of the Status in the
device42_defaults["rack_status"]
option.
Vendor
The SSoT App imports all entries for Vendor, and each must have a unique name.
Hardware Model
Hardware Model objects are required to have a Vendor specified for the Device42 SSoT import.
Device
The SSoT App imports all Devices marked as a network device, ie with the is_switch
field set to True. It imports the following data for network Devices:
- Device name
- Building
- Room
- Rack
- Rack position and orientation
- Hardware model
- Operating System
- Operating System version
- In Service
- Serial number
The Device role can be updated by specifying the name of the Role in the
device42_defaults["device_role"]
option. The default isUnknown
.
For a network device to be imported by the SSoT App, it must have the following defined:
- Device name
- Building (or Customer)*
- Hardware model
Customer is used if the
device42_customer_is_facility
setting is True. It is also required that thedevice42_facility_prepend
setting for the imported Building.
In addition to the standard import, there are multiple application settings that can influence how Device objects are synchronized and/or modify the data as it is imported. Those settings are detailed below:
role_prepend: This setting is for specifying the role for a Device. It defines the string prepended in a Tag that defines the role name. For example, if a Tag is found with nautobot-core_router
, then the role would be defined as core_router
for all Device objects with that Tag.
ignore_tag: ignore_tag defines a Tag that, if found, will have the Device skipped from the import. This is helpful if there are specific Device objects you wish to exclude from the synchronization process.
hostname_mapping: This option enables the capability for a Device to be assigned to a Site based upon its hostname. The value is expected to be a list of dictionaries with the key being the regex used to match the hostname. The value is the slug of the Site to assign to the Device. This option takes precedence over the device42_customer_is_facility
determination of a Device’s Site, with the Building denoted in Device42 being the last resort.
delete_on_sync: This option allows you to prevent data from being deleted when it’s missing from a sync. This is useful in situations where the data is inaccurate in Device42 and you want to control what is removed automatically.
Cluster
The Device42 SSoT application treats all clustered networking Devices as stacked devices importing them into Nautobot as a Virtual Chassis. Due to the way that Nautobot allows data to be stored, an additional “master” Device is created for each cluster to act as the control plane for all data specific to the cluster. The master device should be in the first position in the Virtual Chassis, with each cluster member added in subsequent order based off the order indicator in its name; e.g., a Device with Switch 1
in its hostname will be in position 2. All Ports that are discovered assigned to the Cluster will be created on the master Device, while the member stacks should be assigned their Port objects as shown in Device42. The operating system and version for the cluster will be duplicated from the first cluster member. Otherwise, Cluster objects are treated the same as Device objects.
Port
The SSoT App imports all information about a Device’s Port objects that are provided including:
- Port name
- Enabled
- MTU
- Description
- MAC Address
- Port Type
- Port Mode
- Port Speed
- Port Status
- Tagged/Untagged VLANs
For a Port to be imported into Nautobot, it must have an assigned Device and a unique name. The Port’s speed is attempted to be determined by the interface name or the discovered speed from Device42.
VRF Group
All VRF Group objects in Device42 will be imported as long as names are unique. It will pull in the description on the VRF Group, if defined.
Subnet
All Subnet objects in Device42 will be synchronized to Nautobot. This includes any defined description and associated VRF Group.
IP Address
All IP Address objects documented in Device42 are synchronized and associated to Device interfaces as discovered. The following information about an IP Address is imported:
- Address
- Availability
- Label
- VRF Group
If the IP Address is found on a Port with Management in the name, e.g., mgmt or Management, it should be assigned as primary IP for the associated Device. This behavior can be modified with the device42_use_dns
setting. Enabling this setting will have the import process perform a DNS query for all Device hostnames that follow a standard fully qualified domain name pattern, e.g., router.company.tld. If a DNS record is found for the hostname, then the answered address will be set as the primary IP address for the Device. If it is unable to determine the associated Port, a new Management port will be created and associated to the Device.
VLAN
Due to the way that SNMP auto-discovery can return data about VLANs, the Device42 SSoT application handles VLAN objects in a special manner. It is advised to clean up all VLAN records in Device42 and ensure there is only a single VLAN ID per Building with the correct name. The SSoT App will load the first non-zero VLAN ID and VLAN name that it finds, along with associated Building or Customer. The first VLAN ID shown assigned to a Port will be the one added to the Port.
Provider
Any Provider that is attached to a Circuit will be synchronized to Nautobot. The following data about a Provider will be imported:
- Provider Name
- Provider Notes
- Provider URL
- Provider Account
- Provider Contacts
Telco Circuit
The SSoT App will attempt to import all Telco Circuit objects from Device42 into Nautobot. The following information will be imported:
- Circuit ID
- Circuit Provider
- Notes
- Status of Circuit
- Install Date
- Bandwidth
Patch Panel
Patch Panel objects are treated like simple Devices with identical front and rear ports for the passthrough.
Using the App
The instructions for installing and configuring the Device42 SSoT integration are detailed in the SSoT project’s documentation. At this time, the App supports only a single instance of Device42 to import data from. The connection and authentication information is defined in the PLUGINS
and PLUGINS_CONFIG
section of the nautobot_config.py
file under the nautobot_ssot
key, as shown below:
PLUGINS = ["nautobot_ssot"]
PLUGINS_CONFIG = {
"nautobot_ssot": {
"enable_device42": True,
"device42_host": os.getenv("NAUTOBOT_SSOT_DEVICE42_HOST", ""),
"device42_username": os.getenv("NAUTOBOT_SSOT_DEVICE42_USERNAME", ""),
"device42_password": os.getenv("NAUTOBOT_SSOT_DEVICE42_PASSWORD", ""),
"device42_verify_ssl": False,
"device42_defaults": {
"site_status": "Active",
"rack_status": "Active",
"device_role": "Unknown",
},
"device42_delete_on_sync": False,
"device42_use_dns": False,
"device42_customer_is_facility": False,
"device42_facility_prepend": "",
"device42_role_prepend": "",
"device42_ignore_tag": "",
"device42_hostname_mapping": []
}
}
Each setting is explained, with the specific usage, in the README.md and in the object notes above.
Running the App
Once the Device42 SSoT App is configured and initialized, it can be accessed by navigating to the Plugins menu, going to the Single Source of Truth section, and clicking on Dashboard. This should show you all of your Single Source of Truth–specific Apps you have installed.
From here you can get more information about the Device42 SSoT App by clicking on the Device42 Data Source link. This will show you the mapping of Device42 import objects to Nautobot objects along with configuration details and Sync history.
Clicking on the Sync Now button will take you to a Job form to start the synchronization.
If you wish to just test the synchronization but not have any data created in Nautobot, you’ll want to select the Dry run
toggle. Clicking the Debug
toggle will enable more verbose logging to inform you of what is occurring behind the scenes. Finally, the Bulk import
option will enable bulk create and update operations to be used when the synchronization is complete. This can improve performance times for the App by skipping validation of the imported data. Be aware that this could cause bad data to be pushed into Nautobot.
Once the Job has been started, you will be shown the Job Result
screen. This screen will have log entries as the Job performs the synchronization, along with SSoT Sync Details
, Export
, and Delete
buttons.
Once the synchronization has been completed, the SSoT Sync Details
page will display all of the relevant information about the Job, including execution times for the various parts, the number of objects that were created, updated, deleted, or had failures or errors and a diff of the loaded data from Device42 and Nautobot indicating what would be synchronized from Device42.
Special Integrations
The Device42 SSoT App has been written to support integration with the Device Lifecycle Management App. If the Device Lifecycle Management App is found to be installed in the same environment as the Device42 SSoT App, a new Software object will be created for each Operating System version that is imported from Device42. That Software will then be assigned to the specific Device to enable easy tracking of the Software versions in use for your fleet.
Conclusion
While the Device42 SSoT App is currently set up only to import data from Device42 into Nautobot, it is perfectly capable of also pushing data from Nautobot to Device42. We’d love to hear your use cases for this data flow and how you utilize the Device42 SSoT App! Please let us know in the comments, or hit us up on Slack.
If you are curious about building your own Single Source of Truth App with the SSoT framework, you can find more details in the Building a Nautobot SSoT App and the Advanced Options for Building a Nautobot SSoT App blog posts. You can also find out more information about Device42 at the Device42 homepage.
-Justin
Contact Us to Learn More
Share details about yourself & someone from our team will reach out to you ASAP!