Device broker support
Itential Automation Gateway (IAG) facilitates device broker functionality within Itential Platform by implementing a standardized set of API calls and translating them into Ansible role executions.
Device broker
The device broker is an abstraction layer in Itential Platform that allows applications (such as Configuration Manager) and workflows to send requests and receive responses from network devices, including those that don’t provide a native API. It defines a set of common API calls (i.e., getDevice, getConfig, runCommand, etc.) to standardize interactions with diverse device types through different interfaces. Having a standardized approach to managing devices is essential as organizations rely on an increasingly varied range of network devices.
The following table shows the mapping from the device broker call to the adapter function that implements the Ansible role.
Role of IAG
IAG implements the device broker calls through the IAG Adapter. When a device broker API call is made, the adapter maps that call to an Ansible role using the IAG API. The Ansible roles execute the logic required to fulfill the broker API request — such as retrieving device configuration, running commands, or checking device state.
Role selection and execution flow
When a device broker call is made, IAG follows a specific sequence to select and execute the appropriate Ansible role for the target device.
Ansible native module path
If the device inventory includes the ansible_network_os variable and its value matches a supported device OS (such as IOS, Junos, NX-OS, etc.), IAG loads and executes the corresponding predefined Ansible role.
These roles use device-specific modules provided by the Ansible community to interact with the device.
This is the preferred and most fully integrated path, enabling the use of all IAG and Platform features.
Netmiko path
If ansible_network_os is not set, or if it doesn’t match a supported device OS, but the inventory includes netmiko_device_type (or provider.device_type), IAG uses an Ansible role that implements the generic Netmiko Ansible module.
The Netmiko module provides support for a wide range of devices via SSH, even if there is no native, device-specific Ansible module.
Custom role path
If neither ansible_network_os nor netmiko_device_type/provider.device_type are set, IAG attempts to load a custom role.
The custom role is mapped to the value of ansible_network_os (which should be a unique, non-standard value for your custom device/role).
These custom roles are user-extensible and reside in a directory specified in the IAG configuration as the “Extended Device Role Path”.
This approach ensures that IAG can support a wide range of devices out of the box, while also allowing you to extend support to new or custom devices by creating your own custom Ansible roles.
Summary table
Device connectivity support
IAG 4 provides SSH (CLI) support for connecting to devices that don’t natively support API interfaces, enabling their integration into Itential Platform workflows and device broker calls. IAG uses SSH as a secure transport mechanism for sending and receiving data, allowing CLI commands to be executed on devices for communication and management tasks.
Testing and support
IAG thoroughly tests device connectivity over SSH using CLI commands and works to provide the best possible experience across a wide range of devices. Given the number of devices, network operating systems, CLI syntax variations, and command sets involved, it isn’t possible to test every combination thoroughly. Itential takes a methodical approach to testing against the most widely deployed systems and provides support to ensure that transport capabilities follow best practices and standards implementations.
Generally, functions work natively, but certain combinations of hardware, network operating systems, and versions may introduce bugs. In those cases, Itential works jointly with customers to find resolutions using every reasonable means. Test IAG thoroughly in your own environment before deploying to production.