--- title: "About Assurance Sensor Module Discovery" slug: "about-assurance-module-discovery" tags: ["Module Discovery Trigger", "Assurance Sensor Modules", "Legacy Orchestrator", "Module Discovery", "discovery"] updated: 2025-02-14T16:18:09Z published: 2025-02-14T16:18:09Z canonical: "docs.crossworkassurance.cisco.com/about-assurance-module-discovery" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.crossworkassurance.cisco.com/llms.txt > Use this file to discover all available pages before exploring further. # About Assurance Sensor Module Discovery Legacy Orchestrator's Module Discovery Trigger feature extends the Cisco Inventory system. This feature reduces the operational effort required to install new modules to a minimum. New devices go from the box to being managed in minutes. Here are the components involved in the discovery process: - **Provider Connectivity Assurance Sensor Control with Discovery instance**: Provider Connectivity Assurance Sensor Control can be configured to discover the module with discovery instance. A discovery instance detects new modules advertising themselves and adds them to its inventory - **Inventory modules**: Assurance Sensor Module can be discovered by Assurance Sensor Control; a field technician only needs to install a unit, power it up and connect those modules in the networks. - **Legacy Orchestrator**: The Module Discovery Trigger feature allows Legacy Orchestrator to discover new modules and execute configuration jobs or flow profile on the discovered modules. ## Discovery Modules Here is how a new Assurance Sensor Module is installed on the network and configures its connection to the network: 1. New Assurance Sensor Module is installed on the network and powered on. 2. Create discovery instances to specify how to discover the remote devices of the Assurance Sensor Control. 3. The Assurance Sensor Control is able to quickly and reliably discover the remote devices to be linked with an instance of the Assurance Sensor Control and adds new modules to its inventory. ## Module Discovery Trigger Workflow This section describes the Discovery Trigger workflow: how to set it up in Legacy Orchestrator and how it triggers execution of configuration jobs and flow profiles on discovered modules. 1. Network administrator prepares for installation of new Assurance Sensors as follows: - Ensures that at least one Assurance Sensor Control on the network has enabled discovery instances. - Ensures that one or more modules have a presence on the network. - Prepares one or more ME Reference dataset files that list the new Assurance Sensor Module that will be installed on the network. - With configuration jobs: - With flow profiles: 1. Field technician installs the new modules and powers them on. 2. The newly installed modules advertise their presence on the network. 3. Discovery of the Assurance Sensor Control detects the new modules on the network and adds them to its inventory. 4. Legacy Orchestrator: - Polls inventory modules and adds modules in their inventory to the **Unmanaged Modules & SFPs** list. - Scans the **Unmanaged Modules & SFPs** list periodically (every five minutes) to identify any modules whose properties (serial number or name or IP address or subnet) match a module listed in an ME Reference file associated with a configuration job that is selected in the Module Discovery Trigger. - Runs the configuration job(s) or flow profile on modules matching the conditions defined in the ME Reference file for the particular job. ## Operational Considerations The following operational considerations apply to the Module Discovery Trigger: - A maximum of 20 devices can be processed per scan of the **Unmanaged Modules & SFPs** list. - In order to move a device to the **Managed** state, Legacy Orchestrator must first be able to establish an SSH connection to the device and log in. - Legacy Orchestrator retains a history of the devices that were scanned and moved to the **Managed Modules & SFPs** list by the Module Discovery Trigger. - If no matching modules are found, the executor result will be empty. Only one empty executor result (the most recent) is stored in the history. - Errors may prevent the configuration job from executing successfully.