Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Appendix: Description of the vTA VNF and Its Requirements

  1. The vTA VNF is capable of running in a plain, “vanilla” environment using a standard cloud configuration and orchestration based on Azure. There might be some limitations in terms of performance and also some minor limitations in terms of jitter and delay accuracy, depending on your Azure infrastructure and how heavily loaded it is. However, for early proof-of-concepts and evaluations, this should not be a major issue. To obtain line rate packet generation and optimal usage of your specific hypervisor environment, an integration project would be required.
  2. The vTA VNF consists of a single stand-alone VNF. However, the VNF must be able to connect and communicate securely with Paragon Active Assurance Control Center, which is not a VNF. Control Center is readily available in the public cloud (in addition to private cloud installations), something which simplifies test and evaluation projects.
  3. Interfaces trust the natural OS bootstrap order in terms of how they are identified.
  4. The performance is dependent on the underlying hardware. The more powerful the hardware, the higher the performance. For a 3 GHz quad-core processor, achievable performance is up to 10 Gbit/s using five concurrent unidirectional TCP streams.
  5. The minimum recommended specification is: 1 vCPU, 512 MB RAM, and 2 GB of block storage.
  6. It is assumed that a generic VNF manager which is not part of the Paragon Active Assurance solution does the instantiation, scaling, and termination of the vTA VNF.
  7. The vTA VNF needs to register with Control Center to receive commands. For public cloud Control Center scenarios, the VNF needs connectivity to the Internet from the eth0 interface. For plug-and-play configuration of the VNF, DHCP should be used for IP addressing of the vTA’s interfaces, as well as for assignment of an available DNS server.
  8. The VNF will resolve the Control Center address and initiate an outbound connection using TCP. (For details, see the Paragon Active Assurance support documentation.) To successfully connect and authenticate itself to the correct Paragon Active Assurance account, the VNF needs to have credentials provided to it during initialization. In the Azure environment, these credentials can be entered in a YAML file supplied via the command line interface (see section Creating a Virtual Machine). Once the VNF has connected to Control Center, it can be controlled either via a web browser or through the Netrounds cloud API to start monitoring user experience KPIs, conduct a service turn-up test, or perform on-demand troubleshooting tests. The connection is an encrypted OpenVPN connection.
  9. The vTA VNF also requires synchronization to an NTP server in order to achieve accurate delay and jitter measurements. By default, Test Agents will synchronize their internal clock to an NTP server provided by Netrounds (; however, any NTP server (internal or external) can be used.
  10. Rescaling of the VNF again needs to be handled by a generic VNF manager (compare paragraph 6). For example, if the available connection bandwidth is increased, the VNF might need to be scaled up to be able to push enough bandwidth through the link for testing purposes.