Junos TCP

In this task, a Test Agent Application connects to one or several Junos devices (defined as network devices in Paragon Active Assurance) via the NETCONF protocol and accesses TCP sessions running on these devices (these sessions have not been configured in Paragon Active Assurance). The Test Agent collects measurement results from the TCP sessions, evaluates errored second thresholds, and reports all results back to Control Center.

Each TCP session running on a Junos device is identified as a “test” belonging to an “owner” (specified as services rpm probe <owner> test <test> in the Junos CLI). The test and owner are shown along with the results in Control Center so that you can correlate them with the TCP sessions on the Junos device.

Note

A Test Agent Application is required for this task; the Test Agent Appliance does not support it. The Junos TCP task is also different from regular TCP in that the Test Agent does not itself conduct the measurements.

IPv6 is supported in the communication between the Test Agent and the Junos device.

../../_images/junos-tcp.png

Prerequisites

To perform Junos TCP measurements, you need to install at least one Test Agent. For guidance on how to deploy a new Test Agent, see the installation guides found here.

As regards each targeted Junos device, the following holds:

  • The functionality has been verified to work on the following Juniper device models, but it might also work on other devices:

    • vMX

    • MX204

  • The functionality has been verified for Junos versions 18.3–20.2. Junos Evolved is not supported.

  • There must be network connectivity from the Test Agent to the device (default TCP port: 830).

  • You must have a user account on the device to be able to log in to it and retrieve measurement data. How to create a user account is described here.

  • The Junos device must be configured as a network device in the Paragon Active Assurance inventory.

  • The probe of Junos device 1 (see diagram) must be configured with the correct probe type:

    set services rpm probe <owner> test <test> probe-type tcp-ping

  • The probe of Junos device 1 must also be configured with the target address:

    set services rpm probe <owner> test <test> target <address_type> <address>

    Example (IPv4):

    set services rpm probe owner1 test t1 target address 192.168.0.1

    Example (IPv6):

    set services rpm probe owner1 test t1 target inet6-address 2070::1

  • Junos device 2 (see diagram) must have a TCP server port configured. Run this command in edit mode:

    set services rpm probe-server tcp port <port number>

  • To start Junos TCP, the probe of Junos device 1 (see diagram above) must be configured with the port number of Junos device 2 (see preceding bullet):

    set services rpm probe <owner> test <test> destination-port <port number>

  • The Junos device must be running TCP measurements when you execute the Junos TCP task. The relevant Junos documentation is found here.

Once you have finished the above preparations, you can add a Junos TCP task to your test or monitor and fill in the mandatory parameters as shown below.

Junos device configuration

This section is about suitable configuration of the Junos device. This needs to be done directly on the device and cannot be performed in the Paragon Active Assurance task. For details, please refer to Junos device documentation.

Creating a user account on a Junos device

The user account should have limited permissions and can be created as follows:

configure
set system login user <username> class read-only
set system login user <username> authentication plain-text-password
New password: <password>
commit

Configuring TCP history size

The configuration parameter services rpm probe <owner> test <test> history-size in the Junos device specifies how many historical probe results are stored for each owner and test. (Regarding these concepts, see the introductory section above.)

The Test Agent will fetch new probe results from this result set every 5 seconds. To have some margin for communication delays between the Test Agent and the Junos device, we recommend that you configure history-size to correspond to at least 1 minute. For example, with probe-interval set to 10 seconds, we recommend a history-size of at least 6.

Parameters

See the common parameters page for the following:

  • Parameters that are set on the test step level: Duration, Fail threshold, and Wait for ready.

  • SLA thresholds for monitors: SLA Good and SLA Acceptable.

  • Advanced settings common to all test tasks: Delayed start.

General

  • Client: Test Agent interface that will connect to the Junos device.

  • Network devices: Junos devices that are running TCP tasks and will be accessed by the Test Agent.

  • Filter based on owner: Only collect results from the specified owner as configured on the Junos device. If you leave this blank, results will be collected from all owners.

  • Filter test session: Only collect results from the specified test as configured on the Junos device. If you leave this blank, results will be collected from all tests.

Thresholds for errored seconds (ES)

  • RTT threshold (ms): Round-trip time threshold for triggering an errored second. If the round-trip time exceeds this value during one second, an ES will be indicated. Min: 0.001 ms. Max: 1000 ms. No default.

  • Jitter threshold (ms): Jitter threshold for triggering an errored second. If the jitter (delay variation) exceeds this value during one second, an ES will be indicated. Min: 0.001 ms. Max: 1000 ms. No default.

Note

Loss will always trigger an errored second.

Advanced

  • Collection interval (s): The interval at which results are collected from the Junos devices. Min: 5s Max: 300s Default: 5s.

  • Session timeout (s): The time after which idle sessions will be removed.

Result metrics

  • RTT (ms): Delay between the transmission of a probe and the arrival of its response.

  • Round-trip jitter (ms): Difference between the current round-trip time and the previous measurement.

  • Round-trip interarrival jitter (ms): Estimate of the statistical variance of a packet’s interarrival time as defined in IETF RFC 1889, calculated for the full round-trip.

Note

Jitter and interarrival jitter are calculated differently from what is called “delay variation” in other tasks.

  • Loss (%): Round-trip packet loss in percent.

  • ES (s): Aggregated number of errored seconds (ES), taking into account all types of error.

  • ES loss (s): Number of errored seconds caused by loss.

  • ES RTT (s): Number of errored seconds caused by round-trip time.

  • ES jitter (s): Number of errored seconds for caused by jitter.