Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Examples: Test Agents

Overview of Test Agent Orchestration

Test Agents in Paragon Active Assurance are considered as "configuration" in the context of orchestration. This means that creation, control, and deletion of Test Agents should be done via the orchestrator and NETCONF rather than via the Paragon Active Assurance GUI.


If a Test Agent is installed by a technician and registered to Control Center without first being created via the NETCONF & YANG API, the Test Agent will not exist in the configuration database, and the system will get out of sync. For ConfD to become aware of the Test Agent in this case, it will be necessary to perform a new synchronization with Control Center, as detailed in the section Synchronizing the Configuration Database with Control Center.

Orchestration of Virtual Test Agents (vTAs) should therefore rather be done in the following steps:

  1. Create the Virtual Test Agent, including its interface configuration, using the NETCONF & YANG interface to Control Center. The name of the Test Agent will be its unique key.
  2. Deploy the vTA using a generic VNF manager (G-VNFM). The basic interface configuration that allows the vTA to connect to Control Center, as well as credentials for authentication, is provided into the vTA using cloud-init user data. Once the vTA has booted, it will automatically connect to Control Center using an encrypted OpenVPN connection. A NETCONF notification is sent since the value of the vTA's test-agent-status-change parameter has now changed to "online".

    Since the name of the vTA is its identifier in Control Center, this name must be the same as that defined in Control Center in step 1.

  3. Once the vTA has connected and authenticated to Control Center, the interface configuration is pushed to the vTA. This is the interface configuration provided in step 1 when the vTA was created in Control Center.
  4. After the vTA has served its purpose, delete the vTA.

Creating and Deploying a New Test Agent

We first need to create a Test Agent using the NETCONF & YANG interface to Control Center. When a Test Agent is created in this way, no synchronization with Control Center is needed.

The YANG model for a Test Agent is as depicted below. It is obtained as output from the command

The full YANG model is given in Appendix: Tree Structure of Full YANG Model, which also contains a legend explaining the conventions used in this and other YANG model illustrations in the present document.

We proceed in the following steps, which are detailed in the following:

  1. At the outset, the Paragon Active Assurance account "demo" has no Test Agents in its inventory.
  2. A Test Agent called "vta1" is created using ncclient. At this stage, no real Test Agent exists yet (that is, it has not yet been started).
  3. The Test Agent is deployed in OpenStack. (Deployment on that platform is chosen here as one possibility among others.)
  4. The Test Agent connects to the Control Center account "demo" and is now ready for use.

Step 1: At the outset, there are no Test Agents in the account "demo". See the screenshot below from the Control Center GUI.

Step 2: A Test Agent is created in Control Center using the Python NETCONF client "ncclient". Below is ncclient code for creating a Test Agent having one physical interface with a DHCP address:


The code preceding with manager.connect(...) is omitted from subsequent example code snippets.

An NTP server is configured on eth0, and eth0 is also the management interface (that is, the interface that connects to Control Center).

A Test Agent Application does not currently allow configuring interfaces. For this reason, from version 2.34.0 onward, it is possible to omit the interface configuration in the YANG schema. The corresponding XML is therefore radically simplified in this case:

Once the Test Agent has been created, it exists in the configuration database and in Control Center. See the screenshot below of the Test Agent inventory, showing the Test Agent "vta1":

Step 3: It is now time to deploy the Test Agent "vta1" in OpenStack.

The Test Agent will use cloud-init user data to retrieve the information on how to connect to Control Center. Specifically, the user data text file has the following contents (Note that the #cloud-config and netrounds_test_agent lines must be present, and that the remaining lines must be indented):

For further information, please refer to the document "How to Deploy Virtual Test Agents in OpenStack", available at

Once the Test Agent has been deployed and has connected to Control Center, the configuration will be pushed from Control Center to the Test Agent.

Step 4: The Test Agent is now online in Control Center and has obtained its configuration. The Test Agent is ready for use in tests and monitoring. See these sections:

Listing the Test Agents in Your Paragon Active Assurance Account

Below is example ncclient Python code for listing the Test Agents in a Paragon Active Assurance account:

Running this code gives output like that below:

Deleting a Test Agent

After a test has completed, it might be relevant in some use cases to delete the Test Agent.

Below is a code snippet showing how to do this with ncclient:

NETCONF Notifications

Below, we present a simple example script for listening to all incoming NETCONF notifications from Control Center. These notifications are sent whenever certain events take place, such as a Test Agent going offline or a user-initiated test being completed. Based on the information carried in the notifications, users can assign automated follow-up actions in the orchestrator.

When the above script is executed, ncclient will present the received notification in structured XML. See the example output below, which shows a Test Agent going offline unexpectedly.