Device agent architecture
This topic provides information about the device agents.
Architecture
The following diagram illustrates the device agent architecture:
Local device agent
When is installed, a single local device agent is created. This local device agent runs within the application server and is always present.
Remote device agent
A remote device agent is a separate application installed on a remote system. supports up to 50 remote device agents. A remote device agent offers the following capabilities:
- Managing devices behind firewalls or in a demilitarized zone (DMZ) where you cannot enable Telnet/SSH and TFTP/FTP/SCP ports, but can enable an SSL port.
- Managing multiple networks that have duplicate IP address ranges.
- Improving performance and reduce WAN bandwidth when loading software images to devices in a region site/region. The OS image is transferred once to the device agent for distribution locally to the devices.
- For managed service providers, securely managing customer networks through a dedicated device agent that is co-located at the customer premises. Customer devices are managed over a single SSL connection.
At installation, all devices by default are assigned to the local device agent.
Remote Method Invocation (RMI) is used for all communication between application server and agent. All communication is initiated from the application server. The remote device agent then uses Telnet/SSH and TFTP/FTP/SCP to manage configurations on the devices. Device agents can also be configured to receive and filter syslog events from network devices.
The application server gathers the syslog messages from a queue at the agent. The server pings the agent once every two minutes. Handshaking calls initially push syslog filters down to the agent. During job execution, the server calls the agent to execute each step of the connection session—open connection to the remote device, log on to the remote device, discover core on the remote device, backup the configuration from the remote device, and log off from the remote device. The amount of data in these additional RMI arguments is trivial (less than 1K per device) compared to the sizes of the configuration and image arguments, which includes device address, file server credentials, timeouts, NAT address, and other parameters, in addition to file transfers involved.
The remote device agents use a single secure connection (default port 1099, which can be configured) for all communication with the application server. Configuration or image files sent to the device or collected from it are sent over port 1099 along with all the other RMI data. There is no database at the agent. A TFTP/FTP/SCP file server at the agent is involved in exchanging files between the agent and the network devices being managed.
When the remote device agent is installed, the installer creates a set of bootstrap files and services that enable the remote device agent to be started, stopped, and to listen for connections from the application server. See Installing-the-remote-device-agent-on-Linux and Installing-the-remote-device-agent-on-Windows for more information about installing a remote device agent.
When the application server makes the initial connection, it passes down to the remote device agent an updated set of configuration and binary files that are used by the agent to run. When the application server is upgraded, it passes the newly upgraded files to the remote device agents. If you are upgrading the application server, you must also upgrade all remote device agents to the same version as TrueSight Network Automation.
Managing multiple customer networks through a single Device Agent
Management of devices with multiple customer networks at the agent layer is normally done by deploying a separate agent dedicated to managing the devices in a network. However, if you require a single agent to be able to manage multiple customer networks, each network needs to be reachable via a different network interface card (NIC) at the agent.
When you configure an agent at the application server, you specify the address of the server-facing NIC which is used for RMI communication. In addition, you specify one or more device-facing NICs to be used for device communication. Among the device-facing NICs, there must be at least one default NIC defined. If there is only one NIC present in the underlying agent platform, then the server-facing NIC and device-facing NIC will have the same address. However, if the agent platform has one NIC for management traffic, and a separate NIC for data traffic, then these addresses would be different.
For the case, where a single agent is deployed to manage multiple networks, you must define a separate device-facing NIC for each different network. When the agent communicates with devices belonging to a given network, all traffic (both device action traffic and syslog traffic) pass through the NIC for that network.
Proxy file server
You can configure a device agent to use a proxy file server, which is separated from the device agent. With this file server, you do not need to configure FTP, SCP, and TFTP on the device agent. The inbound connections are now relegated to the proxy file server instead of the device agent, thus making the device agent more secure.
You can configure FTP, SCP, and TFTP on the proxy file server and provide these details to the device agent. After you configure a device agent to use the proxy file server, all the configuration and images are transferred through the proxy file server.
Actions during snapshot and deploy operations
The following diagram illustrates how the proxy file server is used during a snapshot operation:
The sequence of actions during a snapshot operation is as follows:
- The device agent (local or remote) instructs the device to copy a configuration or an image file to the proxy file server.
- The device copies the configuration or image file to the proxy file server using the TFTP, FTP, or SCP transfer mode .
- The device agent establishes the SSH connection with the proxy file server and copies the configuration or image file to the device agent using SFTP.
The following diagram illustrates how the proxy file server is used during a deploy operation:
The sequence of actions during a deploy operation is as follows:
- The device agent (local or remote) establishes the SSH connection with the proxy file server and copies a configuration or an image file that you want to deploy on the device to the proxy file server using SFTP.
- The device agent instructs the device to copy the configuration or image file from the proxy file server.
- The device gets the configuration or image file to the proxy file server using the TFTP, FTP, or SCP transfer mode.
Parameters used by device agents and devices
The device agent uses the following parameters while establishing an SSH connection with the proxy file server depending on the transfer mode configured on the device. The device agent uses the SFTP protocol to transfer files to and from the proxy file server.
Transfer mode configured on the device | Parameters for the device agent to proxy file server communication |
|---|---|
TFTP/FTP/SCP | Proxy file server address |
SFTP port | |
SFTP/FTP/SCP transfer account user name | |
SFTP/FTP/SCP transfer account password |
A device uses the following parameters to copy a file to and from the proxy file server after it receives instructions from the device agent. Also, note that the proxy file server never establishes connections to the device. Instead, the device establishes connections to the proxy file server.
Transfer mode configured on the device | Parameters for the device to the proxy file server communication |
|---|---|
TFTP/FTP/SCP | (For all the modes) Proxy file server IPv4 address |
(For all the modes) Proxy file server IPv6 address | |
(For TFTP mode only) TFTP transfer directory | |
(For FTP and SCP modes only)
|
Management of device agents
Device agents are managed under the Admin tab. The local device agent is always present and cannot be deleted. After installing a remote device agent, go to the Admin > Device Agent page to create the device agent record in the product.
The following figure shows the Edit Device Agent page for an existing agent. It has the same fields as the Add Device Agent page.
You must specify the name of the device agent, the host name or IP address, and the port. The port is specified during the device agent installation and must match the port entered on the device agent editor.
Optionally, you can enable the protocols supported by the device agent (TFTP, FTP, or SCP), and enable syslog support. You can also specify the device agent protocol parameters such as directories, user names, and passwords. These same optional fields are also available on the local device agent.
Name resolution
You can control whether should attempt to perform host name resolution as needed at the agent, both when connecting to devices the agent manages and when parsing syslog messages received from those devices.
File transfer
You can specify the IPv4 address, IPv4 Subnet Mask (CIDR), IPv6 address, and the IPv6 prefix length which the device would use to talk to remote device agent for file transfer. You should be able to make use of these IPv4 and IPv6 attributes in templates to configure routing for a remote device agent. See About-substitution-parameters for more information.
Each remote device agent has its own TFTP, FTP and SCP parameter settings (for example, access credentials and transfer directories). You can enable or disable file transfer protocols for a remote device agent.
Syslog listening
Syslog events can be routed directly to the application server, or can be routed to the device agent. The device agent can receive syslog events directly from the managed devices and from syslog relays. The device agent applies the External Event filters to reduce the number of events that are transferred to the application server. In addition, you can configure the device agent to log syslog events to a local file.
Device agent states
The Device Agents page lists all the device agents that are defined in the system. The State column shows the current state of the device agent.
Valid device agent states
The most common state transitions are as follows:
- Device agent is located and no upgrades are needed:
Unknown > Locating > Located > Inspecting > Ready - Device agent is not located:
Unknown > Locating > Unreachable - Device agent is located, but installed files are incompatible with the software version on the server:
Unknown > Locating > Located > Inspecting > Incompatible - Device agent is located, but imported files are incompatible with the software version on the server, so the device agent is upgraded:
Unknown > Locating > Located > Inspecting > Upgrading > Restarting
Unknown > Locating > Located > Inspecting > Ready
Related topics
Adding-or-editing-device-agents
Adding-a-device
About-IPv6-support