Device Life-Cycle Management Overview
Device Life-Cycle Management consists of planning, onboarding or adoption, provisioning, operational monitoring, maintenance, and decommissioning. Routing Director supports each of these stages through automated workflows and operational tools.
Device Life-Cycle Management (LCM) in Routing Director provides a phase-based workflow (Day -2, Day -1, Day 0, Day 1, and Day 2) for planning, connecting, provisioning, monitoring, and retiring network devices. The activities for managing a device life-cycle are divided as:
-
Day -2 activities and Day -1 activities in which a network architect plans the device role and device configuration for that device role. See Prepare for Device Onboarding (Day -2 and Day -1 Activities).
- Day 0 activities in which a field technician installs the device. The field technician or a network administrator establishes connectivity between the device and Routing Director so that Routing Director can manage the device. See Install and Onboard a Device (Day 0 Activities).
- Day 1 and Day 2 activities in which a network administrator monitors the health and functioning of the device and moves the device to production. See Move a Device to Production (Day 1 and Day 2 Activities).
The Day -2, Day -1, Day 0, Day 1, and Day 2 workflow primarily applies to device onboarding where Routing Director provisions and manages devices through a network implementation plan. For devices already existing in the network, the device is adopted by committing outbound SSH commands. A network implementation plan can be created and the adopted device added to the network implementation plan for managing the adopted device.
Devices can be brought under management in Routing Director by first adopting the device and then onboarding them.
Adoption is the use of outbound SSH commands to connect with Routing Director. Configurations existing on the device while establishing connectivity to Routing Director are preserved.
Onboarding is the use of a network implementation plan to commit and manage configurations on a device after the device is adopted.
The following section compares onboarding and adoption in more detail.
Device Onboarding Versus Device Adoption
You can bring devices under management by using onboarding or adoption.
Device Onboarding
With onboarding, you configure outbound SSH connectivity from the device to Routing Director and define configuration intent by using device and interface profiles and a network implementation plan. Routing Director uses the plan to provision configuration, collect inventory, and automatically enable monitoring and assurance that align with the features and protocols defined in the plan. See Device Onboarding Overview. After onboarding, you manage the device through the plan.
When using a network implementation plan to manage devices, to upgrade software, you simply update the software version to be applied on the device in the device profile or the plan used to manage the device. Similarly, links and basic configurations that were committed on a device by using the plan can be updated by editing the plan and profiles used to manage the device.
Besides the network implementation plan, you can also use configuration templates to apply advanced configurations on the device and use the Software Upgrade option (Observability > Health > Troubleshoot Devices > More > Upgrade) to upgrade the software.
In addition, Routing Director executes a predetermined set of tasks (based on the configurations in the plan and profiles) for automatic monitoring and operations of the devices right from when the device is onboarded. For example, when you enable BGP or RSVP protocols in the profiles, Routing Director monitors the functioning of the BGP and RSVP protocols and displays any alerts or alarms related to the functioning of the protocols, right after the device is onboarded.
Device Adoption
With adoption, you configure outbound SSH connectivity on a device while keeping the existing device configuration. Because Routing Director does not treat the existing configuration as declared intent, you can apply changes by using configuration templates and configure monitoring and assurance explicitly. See Adopt a Device for information. After adopting a device, you can manage the device manually or by using conventional tools.
Table 1 lists the differences between device adoption and device onboarding.
| Device Adoption | Device Onboarding | |
|---|---|---|
| Routing Director establishes a connection with device | Uses Outbound SSH commands | Uses outbound SSH commands |
| Configuration Management | Uses configuration templates | Uses network implementation plan |
| Bulk device management | Apply the configuration templates on multiple devices using the Routing Director GUI. | Allows multiple devices to be managed simultaneously through a network implementation plan. |
| Device and Health monitoring | Rules must be created and installed in Routing Director manually or through scripts. | Uses AI-ML to monitor device health, interface statistics, and protocol performance, enabling proactive anomaly detection. |
| AI-ML use cases | Not available | The following AI-ML use cases are available:
|
| Active Assurance testing | Test agents must be manually installed on devices and tests must be created manually. | Test agents are automatically configured on devices and connectivity tests are automatically performed after the device is onboarded. |
| Decommissioning a device | Delete the outbound SSH configuration from the device. | Delete the device from the plan or delete the plan and then delete the outbound SSH configuration from the device. |
| Service Orchestration | Cannot use the service orchestration feature | Can use the service orchestration feature |
| When to use | Recommended for basic EMS features (device inventory view, configuration backup and restore, software upgrade, and so on). | Recommended for all deployments that need more than the basic EMS features such as, intent-based management, automated monitoring, and standardized configuration. |
Transition from Adoption to Onboarding
An adopted device can be transitioned to an onboarded device when you want Routing Director to manage the device through device profiles, interface profiles, and a network implementation plan. The plan is the source of configuration intent and the existing device configuration is changed to that present in the plan.
You may want to transition from adoption to onboarding to take advantage of onboarding-specific management, monitoring, assurance, and AI-ML capabilities described in Table 1.
Before transitioning an adopted device to onboarding, review the existing device configuration and the configuration generated by the network implementation plan. Any overlapping configuration should be carefully validated to avoid unintended changes to operational services.
To transition from adoption to onboarding:
- Create a network implementation plan if a suitable one does not exist already. See Add a Network Implementation Plan.
- (Optional) Create the required device and interface profiles. See Add a Device Profile and Add an Interface Profile.
- Add the adopted device to the plan. See Devices Tab.
- Review the configuration changes that will be applied by looking at the summary of the plan.
- Save and provision the plan to onboard the device.
Verify that the device is onboarded from the Plan-Name details pane (More > Details). Onboarded status indicates that the device is onboarded.
After the transition, the device assumes the characteristics of an onboarded device and is managed through the plan. See Table 1 for the capabilities provided by onboarding.
Transition from Onboarding to Adoption
An onboarded device can be transitioned to an adopted device when you no longer want Routing Director to provision and manage the device through profiles and network implementation plan, but still want Routing Director to maintain connectivity to the device for viewing inventory, upgrading software, taking configuration backups, restoring configuration, or managing configurations using templates.
To transition a device from onboarding to adoption, delete the device from the plan. See Tasks you can perform on the Devices tab.
After the device is removed from the plan, the device assumes the characteristics of an adopted device and is no longer managed through the network implementation plan. See Table 1 for a comparison of capabilities available through adoption and onboarding.:
Manage and Monitor a Device
After a device is onboarded or adopted, Routing Director provides a common set of life-cycle management capabilities for inventory management, software maintenance, configuration management, licensing, and operational troubleshooting. See Device Onboarding Workflow.
Routing Director GUI provides an integrated view of all the information about a device. On the Device-Name page. You can access the Device-Name page from:
-
Inventory > Onboarding Dashboard > Device-Hostname when the device is being onboarded.
-
Observability > Health > Troubleshoot Devices when the device is in production.
On the Device-Name, you can view general details, connectivity details, results of trust scans, and key performance indicators (KPIs), and assess the functioning of the device. You can also upgrade software and perform a back up of the device configurations from the same page.
For devices, Routing Director provides options for software upgrade, adding licenses, applying configurations by using configuration templates, and backing up configurations under the Observability > Health > Troubleshoot Devices menu.
Decommission a Device
When you want to decommission (offboard) a device managed using a network implementation plan, you can:
-
Use the network implementation plan that you are using to manage a device to decommission the device. See Offboard a Network Implementation Plan.
When you use a network implementation plan to offboard, configurations applied from the plan are deleted, but the outbound SSH configuration is retained. You must explicitly delete the outbound SSH configuration for Routing Director to disconnect from the device. See Release a Device.
-
Use the Release option to delete the outbound SSH configuration so that Routing Director disconnects from the device, See Release a Device.
In this case, the other configurations committed on the device are retained. You must access the device CLI and manually delete the configurations.
To decommission a device not managed by a network implementation plan, you simply use the Release option in Routing Director to delete the outbound SSH configuration on the device. See Release a Device.
Benefits of Device Life-Cycle Management
-
Provides an automated solution for managing the life-cycle of new devices procured for a network.
-
The profiles and network implementation plan that are used to onboard and manage multiple devices considerably reduce the time and effort taken to onboard and manage devices.