Release notes, March 3, 2016

Important information

New names for Probes and Agents
 
The nomenclature for Netrounds Probes and Agents will be changed as outlined below.
  1. SW Probes that are downloaded by end users and installed on x86 HW will be renamed SW Test Agents.
  2. HW Probes that are delivered from Netrounds with preinstalled SW will be renamed HW Test Appliances.
  3. SW Agents that are downloaded by end users and installed as an application on Windows/Linux computers will be renamed Embedded Test Agents.
  4. Virtual Test Agent is introduced to run as Virtual Machine (VM) on any hypervisor. This type of agent is suitable as a virtual network function (VNF) in ETSI NFV MANO (Network Function Virtualization Management & Orchestration).

New features

Added support for management via HTTP proxy

It is now possible to connect a Test Agent to the Netrounds Control Center through a standard HTTP proxy. This is necessary if Test Agents are located behind a firewall in your network environment and if access to the Internet is required to pass through an HTTP proxy.

For HTTP proxy authentication, the modes "none" and "basic" are both supported.

Please note that you cannot register a Test Agent with the Control Center via an HTTP proxy; the registration must be done in the usual manner. Once registered, however, the Test Agent can use an HTTP proxy to connect.

Test Agent Management over mobile interface

Test Agents can now be managed from the Netrounds Control Center over a mobile network (4G/3G/2G) connection. This enables control of Test Agents deployed in isolated network environments that do not have a connection to the Internet.

IPv6 transparency test

This additional transparency test verifies that the network does not block various IPv6 protocols. Specifically, the following IPv6 protocols are tested:

  • Multicast Listener Discovery (MLD), Versions 1 and 2
  • ICMPv6 with packet types
    • Router Solicitation
    • Router Advertisement
    • Neighbor Solicitation
    • Neighbor Advertisement
  • DHCPv6 Solicit

The link is considered transparent if IPv6 packet go through. No verification is done of packet content.

This feature is available to customers on our Professional subscription.

Improvements

Virtual Test Agent image: config-drive option added

Support has been added for config-drive as a datasource for initial setup of the Virtual Test Agent. This complements the existing cloud-init option which uses HTTP Get. It is now also possible to set static IP, GW, DNS, NTP, and HTTP Proxy as part of the instance metadata.

Learn more about cloud-init and config-drive here: https://github.com/jriguera/ansible-ironic-standalone/wiki/Cloud-Init-and-Config-Drive

IP/MAC source spoofing test extended to Layer 3 networks

In the IP/MAC source spoofing test, the customer Test Agent previously specified the MAC address of the ISP Test Agent directly. To adapt this test to Layer 3 networks, the customer Test Agent now sends an IP address in an ARP request instead, which resembles the behavior of a normal user.

Set NTP server via local console

The NTP server can now be set from the local console configuration menu.

Improved response times when creating large full-mesh monitorings

The process of initiating full-mesh monitorings with a large number of Test Agents has been speeded up thanks to a more efficient implementation.

Improved API documentation

Miscellaneous improvements have been made to the API documentation, including improved descriptions and examples.

The new version is dated February 18, 2016. The API documents are provided on request.

Bug fixes

L2 transparency: MAC address limit test

This test used to fail due to high delay in Test Agent management. – Scripts have now been optimized to lower the number of remote calls and reduce the delay.

L2 Transparency: Custom VLAN

This test failed if the direction of the transmission was changed within 300 seconds. – The implementation was improved so that it uses the Test Agents' real IP/MAC addresses instead of random ones, which were the same for both directions.

L2 Transparency: Multicast

This test failed in the same circumstances and for the same reason as the Custom VLAN test. – Again, the remedy was to use the Test Agents' real IP/MAC addresses.

RFC6349 test (Framework for TCP Throughput Testing)

This test failed if it was not possible to start as many concurrent TCP sessions as required by the link speed. – To allow for a sufficient number of TCP sessions, the maximum buffer size per socket was increased from 160 KB to 10 MB.

DHCP starvation test

The DHCP starvation test did not release the IP addresses in a correct way. This caused the test to fail after some reruns, because all available addresses had been allocated.

Not possible to configure Test Agent management over VLAN

Trying to configure a Test Agent for management over a VLAN interface failed with the error message "'Failed to apply interface configuration ...". 

 

Have more questions? Submit a request

Comments

Powered by Zendesk