Hawkeye User Guide

Hawkeye
User Guide
Version 2.4 EA
February 2018
Notices
Copyright Notice
© Keysight Technologies 2017-2018
No part of this document may be reproduced in any form or by any means (including electronic storage and retrieval
or translation into a foreign language) without prior agreement and written consent from Keysight Technologies, Inc.
as governed by United States and international copyright laws.
Warranty
The material contained in this document is provided “as is,” and is subject to being changed, without notice, in future
editions. Further, to the maximum extent permitted by applicable law, Keysight disclaims all warranties, either
express or implied, with regard to this manual and any information contained herein, including but not limited to the
implied warranties of merchantability and fitness for a particular purpose. Keysight shall not be liable for errors or
for incidental or consequential damages in connection with the furnishing, use, or performance of this document or
of any information contained herein. Should Keysight and the user have a separate written agreement with warranty
terms covering the material in this document that conflict with these terms, the warranty terms in the separate
agreement shall control.
Technology Licenses
The hardware and/or software described in this document are furnished under a license and may be used or copied
only in accordance with the terms of such license.
U.S. Government Rights
The Software is "commercial computer software," as defined by Federal Acquisition Regulation ("FAR") 2.101. Pur-
suant to FAR 12.212 and 27.405-3 and Department of Defense FAR Supplement ("DFARS") 227.7202, the U.S. gov-
ernment acquires commercial computer software under the same terms by which the software is customarily
provided to the public. Accordingly, Keysight provides the Software to U.S. government customers under its standard
commercial license, which is embodied in its End User License Agreement (EULA), a copy of which can be found at
http://www.keysight.com/find/sweula or https://support.ixiacom.com/support-services/warranty-license-agree-
ments. The license set forth in the EULA represents the exclusive authority by which the U.S. government may use,
modify, distribute, or disclose the Software. The EULA and the license set forth therein, does not require or permit,
among other things, that Keysight: (1) Furnish technical information related to commercial computer software or
commercial computer software documentation that is not customarily provided to the public; or (2) Relinquish to, or
otherwise provide, the government rights in excess of these rights customarily provided to the public to use, modify,
reproduce, release, perform, display, or disclose commercial computer software or commercial computer software
documentation. No additional government requirements beyond those set forth in the EULA shall apply, except to the
extent that those terms, rights, or licenses are explicitly required from all providers of commercial computer soft-
ware pursuant to the FAR and the DFARS and are set forth specifically in writing elsewhere in the EULA. Keysight
shall be under no obligation to update, revise or otherwise modify the Software. With respect to any technical data
as defined by FAR 2.101, pursuant to FAR 12.211 and 27.404.2 and DFARS 227.7102, the U.S. government acquires no
greater than Limited Rights as defined in FAR 27.401 or DFAR 227.7103-5 (c), as applicable in any technical data.
52.227-14 (June 1987) or DFAR 252.227-7015 (b)(2) (November 1995), as applicable in any technical data.
ii Hawkeye User Guide

Contacting Ixia
Contacting Ixia
Corporate Ixia Worldwide Headquarters Web site: www.ixiacom.com
Headquarters 26601 W. Agoura Rd. General: [email protected]
Calabasas, CA 91302
USA Investor Relations: [email protected]
+1 877 FOR IXIA (877 367 4942) Training: [email protected]
+1 818 871 1800 (International) Support: [email protected]
(FAX) +1 818 871 1805 +1 818 595 2599
[email protected]
EMEA Ixia Europe Limited Support: support-emea@ixi-

Part 2nd floor, acom.com
Clarion House, Norreys Drive
Maidenhead, UK SL6 4FL +40 21 301 5699
+44 (1628) 408750
FAX +44 (1628) 639916
[email protected]
Asia Pacific Ixia Pte Ltd Support: support-asiapac@ixi-

210 Middle Road acom.com
#08-01 IOI Plaza
Singapore 188994 +91 80 4939 6410
Japan Ixia KK Support: support-japan@ixi-

Nishi-Shinjuku Mitsui Bldg 11F acom.com
6-24-1, Nishi-Shinjuku, Shinjuku-ku
Tokyo 160-0023 +81 3 5326 1980
Japan
India Ixia Technologies Pvt Ltd Support: support-indi-

Tower 1, 7th Floor, UMIYA Business Bay [email protected]
Cessna Business Park
Survey No. 10/1A, 10/2, 11 & 13/2 +91 80 4939 6410
Outer Ring Road, Varthur Hobli
Kadubeesanahalli Village
Bangalore East Taluk
Bangalore-560 037, Karnataka, India
+91 80 42862600
China Ixia Technologies (Shanghai) Company Ltd Support: support-chin-

[email protected]
Unit 3, 11th Floor, Raffles City, Beijing 400 898 0598 (Greater China
Beijing, 100007 P.R.C.
Region)
+86 10 5732 3932 (Hong Kong)
Hawkeye User Guide iii

This page intentionally left blank.
iv
CONTENTS
Notices ii
Contacting Ixia iii
CONTENTS v
Introduction 1
Configure Hawkeye Endpoints 2
XRPi 2
XR2000 18
XR Docker 50
Software endpoints 54
Routing and Ports management 57
Hawkeye ports for automatic endpoints 57
Hawkeye ports for manual endpoints 60
Managing Probes Behind NAT 62
Hawkeye scenarios for endpoints 65
Debugging routing issues 72
Hawkeye User Guide v

CONTENTS
System Optimization 75
Hawkeye Services 75
Manage MySQL Database 76
Generation of Reports 79
Parameters effecting Performance 80
Security 84
Secure access to Hawkeye server 84
Hawkeye User Authentication 87
Users and Groups Management 89
Change Passwords 96
Captive Portal Support for WiFi 98
Security audit logging of users 105
Configure Hawkeye 106
Interface Presentation 106
Probes Management 106
Test Execution 115
Threshold management 122
Alarms management 125
Mesh Management 127
MAP configuration and probe location configuration 131
Floorplan Management 136
Hawkeye preferences 140
Explore results 163
vi Hawkeye User Guide

CONTENTS
Going through dashboard test results 164
WiFi Dashboard 173
Metric Status 177
Metric Graph 178
Path Discovery 181
Test Results screens 187
Map Status 194
Hawkeye Reports 196
Hawkeye Test types 204
Test type general description 204
Node to Node test types 219
Real Services 326
Real Service endpoint support matrix 357
Replicating tests across multiple endpoints 359
Test types reporting WiFi statistics 360
Supported Protocols and standards 367
Advanced administrator Guide Introduction 372
OSS (Operations Support System) Integration 372
MySQL database Management 374
Hawkeye folder structure 390
SNMP configuration and verification 390
Speed Test using Global Servers 402
Set long TDRID 403
Hawkeye User Guide vii

CONTENTS
SOAP web services API 404
INDEX i
viii Hawkeye User Guide

This is a shared document for Hawkeye and Hawkeye Express.
Hawkeye Express is a scaled down simple to use version of
Hawkeye so all components in this User Guide will not apply to
Hawkeye Express.
Introduction
Hawkeye User Guide page 1

Configure Hawkeye Endpoints

In Hawkeye terminology, an endpoint is sometimes referred to as probe and represents
a device inserted at a key juncture in a network for the purpose of monitoring or col-
lecting performance data about network activity. The test traffic generated conforms to
applicable standards. For example, Voice traffic conforms to selected codecs with cor-
rect packet sizes and packet timings and contains generated data, The Hawkeye end-
point for Corporate security will generate its own test data and will not monitor or
analyze Corporate private transmitted data.The Hawkeye endpoints are available as
Ixia hardware endpoints (XR2000 and XRPi), XR software endpoints (XR2000_VM and
XR Docker) and Software endpoints (Android EP and windows EP). Different flavors of
Software endpoints for various platforms are supported and can be downloaded from an
Ixia website defined in the section on Software endpoints.
The Real Services testing is only available with XR2000, XR2000 VM

(linux Software), XR Docker and XRPi endpoints. WiFi mon-
itoring/performance testing can only be performed using XRPi.
XRPi
The XRPi is a low-profile ultra-small form factor unit ideal for use as an endpoint. It con-
tains an ultralow voltage CPU, one integrated Ethernet port, and no fan. The optional
WiFi dongle supports both 2.4 and 5 Mhz. The WiFi dongle also supports the latest state
802.1ac with 80 Mhz.
XRPi Hardware
Package Contents
The XRPi ships with the following components:
2 Hawkeye User Guide

l XRPi unit
l Dual-voltage (110/220) AC power adapter
l Ixia WiFi dongle
l Non-powered 2.0 USB hub
l HDMI-to-DVI cable
l Quick Start Guide
Ethernet and USB Ports
Component Description
Ethernet port Use these ports to connect the XRPi to other Ethernet devices.
LAN LEDs
Green: Connection speed.
On 100Mbps
Off 10Mbps
Yellow: Activity.
On port is active
Blinking port is sending or receiving traffic
USB ports USB 2.0 ports.

Keyboards, mice, USB 2.0 hub, Wi-Fi dongle are the only sup-
ported accessories that can be plugged into these ports.
Hawkeye User Guide 3

Power and HDMI Ports
Power port Micro-USB power port. Connect the supplied AC power adapter to
this port.
HDMI HDMI 1.4 video output port. Connect the supplied HDMI cable to
this port.
Stereo 3.5 mm stereo output port (disabled)

Micro SD slot
Micro SD slot Micro SD card slot. The Hawkeye operating system and application
software is supplied on a micro SD card. The micro SD card is the
only permanent storage on the Hawkeye.
Inserting the Micro SD card

To insert the micro SD card, position the micro SD card with the contacts facing upwards
and insert the card into the slot until you hear a click.
Removing the Micro SD card

To remove the micro SD card, press the card inwards with a fingernail until you hear a
click, and then withdraw the card from the slot.

System Information
Current Draw ~650 mA, (3.0 W)
Temperature (ambient) Operating: 0ºC ~70ºC

Storage: -20ºC~70ºC
Humidity (RH), ambient 5 ~ 95%, non condensing
Dimensions (WxHxD) 92mm x 29mm x 67mm

3.63" x 1.13" x 2.63"
Weight 100g
Approvals & Compliance CE Emission, FCC Class A, RoHS
XRPi configuration
The device can be connected through HDMI and keyboard via USB port

Log into the XRPi using the following default credentials:
Username - root
Password - Ixia!123
Default configuration (as shipped from factory)
Physical port Logical port Address
LAN1 eth0 DHCP
Port Configuration
DHCP IP address configuration
DHCP is defined by default for eth0
Static IP address configuration

Setting up a static IP address and DNS server address
Static IP address can be used for eth0 but is not preferred. DHCP IP address must
always be used for WLAN0.
1. Use the nano command to edit the following files to configure static IP and DNS
server information:
nano /etc/network/interfaces
iface lo inet loopback Loopback interface configuration
iface eth0 inet static for setting static IP address
address 192.168.1.100 IP address
netmask 255.255.255.0 Subnet mask
network 192.168.1.0 Network address
broadcast 192.168.1.255 Network broadcast address
gateway 192.168.1.1 Default gateway

nano /etc/resolv.conf
domain ixiacom.com Network domain
search ixiacom.com DNS search domain
nameserver 192.168.1.4 DNS name server 1
nameserver 192.168.1.40 DNS name server 2
2. Reboot the XRPi for changes to take effect (use the command reboot 0).
Checking the IP address locally and testing connectivity (DHCP or static)
1. Using the attached keyboard and monitor, access the XRPi 's console and use the
following command to check the XRPis IP address:
ifconfig eth0
2. Use the following command to test connectivity:
ip route
Look for: default via [gateway IP]. Ensure that ping [gateway IP] suc-
ceeds.
3. Use the following command to test that the XRPi can reach the Internet and that
DNS resolution is working:
ping www.ixiacom.com
The ping should succeed, not timeout.
If either the connectivity or name resolution fails, check the static IP information
you entered and confirm that the DHCP server is available.
For XRPi wifi, when setting up static IP addresses and connect both
wlan0 and eth0 interface, XRPi automatic routing scripts that
ensure proper communications with the server will not be enabled
therefore the routing configuration is full responsibility of the user.
It is highly recommended to use DHCP configuration in this context.
4. The default hostname for the XRPi will be xrpi2-<last 5 digit of MAC address>. The
MAC address is on the label at the bottom of the XRPi.

Registering with a Hawkeye Server
Automatic endpoint - Configure XRPi with Hawkeye Server

It is recommended to configure XRPi with Hawkeye server as automatic endpoint.
If the XRPi is registered to the Hawkeye server, the upgrades are performed auto-
matically. If the XRPi was Hawkeye Server 1.0 (or registered as a manual endpoint),
you need to upgrade the end point by using probeConfigure, and it will be auto-
matically upgraded (see below). For Hawkeye users it is recommended to use this
upgrade strategy.
To update automatically, do the following:
1. Connect to the XRPi with ssh
2. Type the following command to start the script: probeConfigure
3. When the script prompts you, enter the following:
l A name for the probe. You can use letters, numbers and hyphens (_) in the name.
This option will set the host name and the name as displayed into Hawkeye. The
name can be edited on the Hawkeye GUI.
l The host name or IP address of the Hawkeye server (public IP if in cloud)
4. When the script ends, the XRPi will automatically try to register.
Enable WiFi interface

You can enable the WiFi interface on the XRPi2 device. Before you enable the WiFi inter-
face on the XRPi2, ensure that you have the following:
l WiFi dongle provided by Ixia.

l Network connection for XRPi eth0 (LAN) interface.
l The XRPi has image with version 2.0.9062115 or later. To see you XRPi version,
use command XRPi2_version once you have ssh to probe or use Hawkeyeserver -
Probe Management.
l For 2.2 onwards releases, XRPi supports static IP address being used for eth0 but
DHCP must be used for wifi interface (WLAN0). The user is responsible for con-
figuring the static IP address for eth0, which is used for Hawkeye management,
and the automatic wifi scripts will take care of WLAN0 interface routes.

n Default routes for traffic will be over wifi interface (wlan0) if enabled.
However if eth0 and wlan0 interface are on different subnetworks for
Mesh tests a parameter in Preferences (Advanced Options – Set test IP
that matches default gateway) needs to be enabled so that when mesh
tests are made traffic will be made on the interface that has default
gateway defined. When wlan0 is defined, default gateway is configured
in the routing tables to be on wlan0.
n It is highly recommended not to configure the XRPi with just the Wifi
interface, as eth0 is used for Hawkeye management and is a more reli-
able interface.
To enable the WiFi interface on XRPi, do the following:
1. Connect the network cable to the XRPi ethernet port.

2. Connect AC power supply using micro USB power connector.
3. SSH to XRPi eth0 interface using putty or other client.
The default username is root and password is Ixia!123.
4. Connect the Ixia WiFi dongle to any available USB port on XRPi device.
The WiFi interface (wlan0) automatically configures on XRPi when you connect the
WiFi dongle.

5. Run the ifconfig command to confirm wlan0 present.

If you want to use WiFi for Wifi Inspect and Wifi connect, you
can skip the steps below.

Routing for eth0 and wlan0

Reboot:
When eth0 and wlan0 interfaces present for XRPi reboot the following occurs:
l The eth0 interface is brought up by system, the dhcp client runs first then XRPis-
cripts. The dhcp query obtains def GW, NTP server, dhcp lease, NIS servers, DNS
servers, DHCP IP.
l The XRPi specific scripts, overwrite default GW, save some details on routes (i.e.
netmask, IP, def GW), Set routes to Hawkeye server and configure per interface
routing tables.
l The wlan0 interface brought up by system connects to AP: DHCP runs, then custom
XRPi scripts configures the routing tables. specifically the global default route
(default GW for DHCP) is changed from eth0 to wlan0, then the default routes and
network routes are set in the global tables and per interface table. The above is
not impacted if eth0 and wlan0 are on different subnets.
Traffic:
Node to Node tests:
Interface to be used for traffic is specified as part of test creation on Hawkeye server.
Mesh and Real services tests:
if eth0 and wlan0 are on same subnet, default route applies, traffic for destination will go
over subnet for wlan0
If eth0 and wlan0 are on different sub nets, (network routes apply) so if destination IP
for test is on subnet for eth0, traffic will go on eth0.
If destination IP for test is on subnet for wlan0, traffic will go on wlan0.
WiFi connectivity lost:
If XRPi receives disconnect from AP or a dhcp release, XRPi will re-attempt re-con-
nection using wpa_default.cfg, as long as DHCP lease has not expired.

If XRPi receives no message/event for lost connectivity (eg AP looses power), XRPi will
attemp reconnection every 10 seconds
Rebooting triggers re-establishment of wlan0.
Connect to WiFi
You can connect to WiFi using three methods.
l Use Hawkeye Server GUI option for WiFi Connect.

l Use a script (wifiConnect) to connect to specific SSID.
l Using Real Service Wifi Connect test.
The double quote symbol is not supported in the password. It is advised

that if manually editing the wpa_default.cfg file to not use the double
quote symbol for comments as it is used by the parser to denote para-
meters.
Use Hawkeye server GUI option for WiFi Connect

The Hawkeye server supports the ability to configure the WiFi interface for an XRPi,
assumming eth0 is present. Once XRPi is configured as an automatic endpoint on the
Hawkeye server in the "Probe Management Automatic" web GUI, if the user drills down
on a specific XRPi, there is a pop-up for "WiFi - Connect" which allows the user to enter
details for the AP. When the "connect" is selected the XRPi uses these details to connect
to the AP and if successful, saves the changes on the XRPi in the wpa_default.cfg file.
Using Real Service Wifi Connect test

The Real Service WiFi Connect test is explained in the Hawkeye User Guide, Real ser-
vices section for the WiFi Connect test type. When the WiFi Connect test is run, the XRPi
receives commands to directly configure the WiFi dongle. XRPi releases wlan0 con-
nection (routes updated) then attempts connection to AP defined for WiFi Connect test.
The connection details from the WiFi Connect test are not saved in a file on the XRPi,
they are temporary. If connection successful, routes are updated for wlan0 and results
sent to Hawkeye Server. Once test finished, if WiFi Connect Test parameter “reset Inter-
face” is set to “yes”, wlan0 is released and WiFi re-establishment occurs to the AP
defined in wpa_default.cfg (if file exists). If WiFi Connect Test parameter “reset Inter-

face” is set to “no”, wlan0 will remain with temporary test configuration until XRPi is
restarted.
Script to connect to specific SSID

The XRPi has a custom WiFi connection script that can be used to connect to an access
point (SSID). The script is located in /home/ixia directory and is named wifiConnect.py.
The script scans for available AP's in range then prompt for the selection of a
SSID/BSSID. The user can then enter popular authentication parameters. If the wifiCon-
nect script runs with the "-D" option to save the connection as default, it saves in the dir-
ectory /etc/wpa_supplicant as wpa_default.cfg if only the connection is successful. If
the "-D" option is not used with the wifiConnect script command it prompts if you want
to save settings as default. If an AP has a configuration that is not addressed by the
wifiConnect script, you have to manually edit the parameters in the wpa_default.cfg file.
See WPA Supplicant file configuration
The command "wifiConnect -h" will list several options that can be used with the script.
The two most popular options are "wifiConnect -D" to save the AP connection details as
default and the "wifiConnect --config /etc/wpa_supplicant/wifi_ixia_guest.cfg" to use a
pre-existing AP configuration file.
Custom WiFi Configuration

Hawkeye Server supports the use of WiFi custom parameters (defined by wpa_sup-
plicant). However the specific parameter must be supported by the wpa_supplicant and
the physical WiFi USB dongle.
When a user performs a WiFi connect to an AP, following steps occur.
1. The configuration including custom WiFi configuration is saved into the wpa_
default.cfg file on the XRPi.
2. The wpa_supplicant, which is an IEEE 802.1 cross platform compliant application
(third party linux app), reads the configuration from wpa_default.cfg and sends
information to the WiFi driver (specific to WiFi USB dongle). After WiFi dongle is
configured, the wpa_supplicant negotiates connection with the AP and radius
server for authentication.
Important to note Hawkeye can only take custom WiFi parameters store them in the
wpa_default.cfg file to be read by the linux wpa_supplicant application. For user’s cus-
tom WiFi parameters to be successful the version of wpa_supplicant must support the
parameters and the WiFi driver must also support the custom parameter. Refer online to

all parameters supported by the wpa_supplicant. Contact Ixia Customer support if you
need confirmation that a specific parameter is implemented or supported. Ixia recom-
mends to use the minimum amount of configuration in the wpa_default file (eg. key man-
agement, user, password, SSID).
Troubleshoot WiFi issues

This section provides you information with scenarios where you can troubleshoot the
WiFi issues.
1. Confirm hardware and drivers are okay for WiFi.
a. Confirm WiFi dongle is plugged into XRPi USB port and has ini-
tialized by checking the LED on the Edimax labelled WiFi dongle. A
blue flash from the LED indicates the dongle is working.
b. Run the following Linux command to confirm WiFi dongle detected
in USB port. After detecting the dongle, the name of the dongle that
is Edimax appears in list of devices.
# lsusb -t | grep Edimax
c. Confirm driver for Edimax dongle is running, use the following com-
mand:
# lsmod | grep 8812au.

2. Confirm WLAN0 interface for WiFi is operational
a. To confirm if tere is an entry and wlan0 interface is operational, use

the following command:
# "ifconfig wlan0".
b. To check the status of WLAN use the following command:
# ip link show wlan0.

c. To bring up the WiFi interface use the following command:
# ip link set wlan0 up command.

d. To check the log files for time stamp for wifi connectivity and
release events, use the following command:
# cat /var/log/Ixia.
3. Check if the WiFi interface is connected to an AP by using the following command:
# iw wlan0 link.
4. Confirm if the XRPi WiFi can see all AP in range using the following command:
# iw wlan0 scan.
5. Confirm IP assigned to WLAN0, using the following command:
# ifconfig wlan0.
6. After an IP is assigned to wlan0, confirm all routes including the default route is
using wlan0 using the following command:
# route -n.
7. If an XRPi WiFi endpoint is moved from one location to another, the IP addresses
for wlan0 and eth0 changes. After the XRPi WiFi endpoint is located in its new loc-
ation, use the following commands in the given sequence to optimize the routes:
# route -n
# ip route flush table main
# rm -rf /etc/wpa_supplicant/wpa_default.cfg
# wlan0 down
# wlan0 up
# route -n
# ifconfig
8. Schedule the real service test WiFi Inspect on the Hawkeye server at an interval
of 5 or 10 minutes for one or two hours to find problems with different AP. View res-
ults in the WiFi Dashboard. The results show the stability of each AP signal
strength over the period. Graphical representation of the results, channels, and sig-
nal strength of each selected AP issues of all AP is available, which helps you to
view the overlapping interference.
l Different WiFi devices report signal strength at different layers in the

WiFi stack, so sometimes there can be differences when comparing.

l The Edimax dongle considers a weak signal to be below -65dbm. Pack-

ets can become corrupted and lost at this weak signal strength. The
Edimax dongle may have difficulty connecting to an AP with a very
weak signal strength of -70db.
l The WiFi scan may have issues detecting and reporting older AP if
they do not provide primary channel information and/or frequency.
9. If connection to an AP is unsuccessful, perform the following steps to troubleshoot:

a. Perform a wifiConnect test from the XRPi CLLI and enable debug logs using
one of the following commands, to see message sequences and reason
codes.
# wifiConnect --debug=6
# wifiConnect --debug=6 2>&1 |tee /tmp/myLog.txt
Set debug flag to 7 for most detailed logs which includes mes-
saging and state changes. Second command saves trace to a file:
b. Perform a detailed WiFi scan to find other AP using the same channel as the
one previously attempting to connect to. The noise interference for an AP is
affected by the relative signal strength of other AP’s using the same channel
and the signal strength of those AP.The bandwidth used by an AP usually
spans the channel number above and below the reported channel number.
The following command will perform a detailed wifi scan and save results to a
file:
# /home/ixia/wifiScan.py -d 4 -u 2>&1 |tee /tmp/myScan.log
10. Fails to connect or drop from specific BSSID. If you specify BSSID with wifiConnect
command or test the connection may drop or lose. A disconnect from an AP
(BSSID) may be due to a local generation event or remote generation event. A loc-
ally generated event for disconnect can be due to XRPi WiFi inability to see the
beacon or keep it alive from its connected AP (BSSID). Ixia recommends you to
use different signal channels for each AP (BSSID) of an SSID with multiple AP. It is
possible that an AP for the same SSID, but different BSSID may have a stronger
signal and drown out the beacon of the weaker BSSID when using the same signal
channel.
The connection can also drop due to remote generation of events. The Radius
server may realize that the XRPi WiFi is connected to an AP (BSSID) but an AP
(BSSID) belonging to the same SSID (i.e. Corporate WiFi) may have a stronger sig-
nal. The Radius server will often inform the currently connected AP to send a dis-

connect and optionally perform a handover to a different stronger signal strength

AP (BSSID).
11. If XRPi has eth0 and wlan0 on the same subnetwork, this may cause routing issues
as this is not a supported configuration. The below is just a suggestion as each
user’s network is different. It is expected the user will know what routes are expec-
ted. However, the user can manually adjust routes. One suggestion is to first
check if default route missing.
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 wlan0
172.16.0.76 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
Above output shows missing route.
# ifdown wlan0; ifup wlan0
Then, verify routes with
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 wlan0
172.16.0.0 0.0.0.0 255.255.255.128 U 0 0 0 wlan0
172.16.0.76 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
Finally, confirm additional route for wlan0 is present and routes are as expected.
XR2000
The XR2000 is a low-profile small form factor unit ideal for use as an endpoint. It con-
tains an ultra-low voltage CPU, six integrated Ethernet ports (one PXE-enabled, allowing
remote diagnostics and reboot), and no fan.

XR2000 Hardware
Package Contents
The XR2000 ships with the following components:
l XR2000 unit
l Dual-voltage (110/220) AC power adapter
l Quick Start Guide
Front Panel
Antenna socket Not supported.
Power switch / LED Green indicates that the system is powered on. Red indicates
that the system is in standby mode.
USB ports Not supported.
VGA port Connect this port to a monitor or other display device. The
Hawkeye supports QXGA resolution (2048 x 1536 @ 75Hz).
24V DC power For use with the supplied 24V DC power adapter.
socket
Reset switch Not supported.

Rear Panel
Console Port (DB-9) Use this port to connect a suitable rollover cable (Yost
cable or Cisco console cable) to configure the Hawkeye, or
for diagnostics.
Default terminal configuration parameters are : 115200
baud, 8 data bits, no parity, 1 stop bit , no flow control.
Internally, this port is assigned as COM1.
HDD/Status/Power HDD: Indicates that the Hawkeye's storage media is func-

LEDs tioning normally. At boot time, the LED is on steadily. Dur-
ing data access to or from storage, it blinks. Otherwise, it is
off.
Status: Green indicates that the Hawkeye is operating nor-
mally. Amber indicates a hardware fault.
Power: On indicates that the system is powered on. Off
indicates that the system is powered off.

USB 2.0 ports You can connect USB devices such as keyboards to the USB
ports.
Top: USB0, bottom: USB1
You should only connect USB devices that
have been qualified by Ixia for use with the
XR2000. For the list of qualified products,
contact your Ixia representative or sup-
[email protected].
10/100/1000Mbps Eth- Use these ports to connect the Hawkeye to other Ethernet
ernet LAN ports devices.
From left to right: LAN1-LAN6
LAN1 has Preboot Execution Environment (PXE) capability,
so if you access the Hawkeye through this port, you can
boot it independently of the installed operating system.
LAN LEDs
Left: Connection speed.
Green 100Mbps
Orange 1000Mbps
Off 10Mbps
Right: Activity.
On port is active
Blinking port is sending or receiving traffic
System Information
Temperature (ambient) Operating: 0ºC ~40ºC
Storage: -20ºC~70ºC
Humidity (RH), ambient 5 ~ 95%, non condensing

Dimensions (WxHxD) 200mm x 42mm x 144mm

7.9" x 1.65" x 5.67"
Weight 1.2kg
Approvals & Compliance CE Emission, FCC Class A, RoHS
Introduction
There are four phases to configure and setup XR2000.
l Connecting to XR2000.
l First-time setup, in which you configure an IP address on the XR2000 so that you
can access it over a network.
l Web setup, in which you set the XR2000s basic boot-up and runtime configuration.
For this phase, you use a web browser to access the XR2000 over your network.
l Register XR2000 with Hawkeye Server.
Connect to XR2000
For a new XR2000, you need to connect to the XR2000, and then configure its IP
addresses so that you can access it over your network.
Once you can access it over the network, you can use a web browser to perform more
in-depth setup using the web setup or setip. You need to connect directly to the
XR2000to set the IP address. You can do it in the following ways:
l Connect a monitor to the VGA port and a keyboard to the USB port. See, First-time
Setup Through VGA and USB
l Use a console cable to connect a laptop to the console port. See, First-time Setup
Through the Console Port
l Use an Ethernet cable to connect a laptop to one of the LAN ports. See, First-time
Setup over Ethernet
XR2000 supports multiple ethernet ports. Default routes for traffic will be
over eth0. However if each interface is on a different subnetwork, go to
Preferences > Advanced Options > Set test IP that matches
default gateway and enable the option for Mesh tests a parameter so
that when mesh tests are made, traffic will be on the interface that has

default gateway defined. On the command line on the XR2000 use the
“route -n” command to see which interface has the defined default gate-
way.
First-time Setup over Ethernet

In the first time setup, you connect to the XR2000, and run a script to configure its name
(the probe name). You will need a terminal-type application such as PuTTY.
To perform the first-time setup over Ethernet:
1. Make sure that the XR2000 is powered off.

2. Connect one end of an Ethernet cable to a laptop, and the other end to the LAN2
port on the XR2000.
As shipped from the factory, the XR2000 is configured as follows:
Physical port Logical port Address
LAN1 eth0 192.168.1.10 / 255.255.255.0
LAN2 eth1 DHCP
3. On the laptop, set the laptop's IP address so that it is on the same subnet
(192.168.1.xxx) as the XR2000. For example, you can set it to 192.168.1.1.
4. Power on the XR2000.
At this point, you can do either of two things:
l Exit the initial setup, and move on to the web setup.
l Run the setup script to configure the permanent IP addressing on the XR2000.

Running the Setup Scripts

The Setup script enables you to quickly configure the IP addressing on the LAN ports.
To run the setup script:
1. Connect to the XR2000.

2. Type the following command to start the script:
setup
The Choose a Tool window displays.


3. Select Network configuration, then choose Run Tool .

4. Select Device configuration, and then the interface (eth0 or eth1) that you want
to configure.
The interface's configuration displays.


5. Configure the interface's settings, then choose OK to save the changes.

6. When the script ends, type exit to logoff.
If you want to register the XR2000 with a Hawkeye server, continue with Regis-
tering with an Hawkeye Server.
First-time Setup Through VGA and USB

To perform first-time setup through VGA and USB:
1. Connect a monitor to the VGA port, and a keyboard to one of the USB ports.
2. Power on the XR2000

A console window displays.
3. Now that you have connected to the XR2000, continue with the Setup script.
First-time Setup Through the Console Port

To perform first-time setup through the console port:
1. Connect a rollover cable or RJ-45 to DB-9 female (Cisco console cable) to the
XR2000's console port.

2. Power on the XR2000.

3. On the laptop, start a terminal application (such as PuTTY or minicom), and estab-
lish a serial connection to the XR2000:
Parameter Value
Speed 115200
Data bits 8
Stop bits 1
Parity None
Flow control None

When a successful connection is established, a terminal window displays.

4. Continue with the Setup script.
Source-Based Routing
When using multiple interfaces on the XR2000, it is impossible to configure multiple
default gateways because all the interfaces share the same routing table. To customize
the interface routing, you can either configure static routes to remote hosts, or use
source based routing. Source-based routing allows each interface (physical and logical)
to have its own routing table, including default routes. .

To configure source-based routing, you use a text editor such as vi to edit script files
stored on the XR2000. Each logical interface or VLAN ID must have its own script file.
The scripts must be stored in the following folder:
/etc/sysconfig/network-scripts
and named according to the logical interface or VLAN ID that they control. For example,
to configure eth0, you edit the ifcfg-eth0 script. If a script file for the interface (or
combination of VLAN ID and interface) does not already exist, you must create it in the
editor.
To configure source-based routing:
1. Connect to the XR2000 using one of the methods described in First-time Setup,
and open a console window.
2. Start a text editor, such as vi.
3. Path to the /etc/sysconfig/network-scripts folder, and open the script for the
interface that you want to configure.
Scripts are named according to the interfaces that they configure, using the fol-
lowing naming convention:
ifcfg-<logical_interface>.<vlanId>
Examples:
Logical interface: To configure the logical interface eth0, edit ifcfg-eth0.
VLAN: To configure the logical interface eth0, edit ifcfg-eth0.25.
If there is no script file for the interface (or combination of VLAN ID and interface),
use the editor to create it.
4. The table below describes the parameters available for the scripts. You can also
refer to the examples in this section for examples of how to configure scripts for
specific configurations.
Parameter Description

BOOTPROTO= Boot-time protocol used to obtain an address for the inter-

face:
dhcp = DHCP
none = No protocol
static = Use static address information configured in this
script file
Example: BOOTPROTO=dhcp
BROADCAST= Broadcast IP address.

Example: BROADCAST=192.168.1.255
DEFROUTE= Always set DEFROUTE to “no”, so that the default route in the
default routing table will not be used.
Example: DEFROUTE=no
DEVICE= Logical interface that the script configures:

Logical interface: ethx
Example: DEVICE=eth0
VLAN interface: ethx.vlanId
Example: DEVICE=eth0.25
GATEWAY= Always set this value to null, to exclude the default gateway
from the default routing table.
Example: GATEWAY=””
HWADDR= MAC address of the card.

Example: HWADDR=4C:02:89:00:F3:90
IPADDR= IP address of the interface (static IP addressing only)

Example: HWADDR=4C:02:89:00:F3:90
IPV6INIT= Enable IPv6 addressing on the interface

Example: IPV6INIT=no
MACADDR= Specify a value for this parameter only if you want to a spoof
a MAC address
Example: MACADDR=4C:02:89:00:F3:26

NETMASK= Network mask for IP address (static IP addressing only)

Example: NETMASK=255.255.255.0
NETWORK= Network address.

Example: NETWORK=192.168.1.0
NM_ Allow or deny changes from the web interface:

CONTROLLED= Example: NM_CONTROLLED=yes
ONBOOT= Activate the interface at boot time

Example: ONBOOT=yes
TYPE= Interface type

Example: TYPE=Ethernet
VLAN= Enable VLAN routing on the interface

Example: TYPE=Ethernet
5. After configuring and saving the script file, you need to create separate routing
tables for each logical interface that need specific default gateways.
To do this , edit the file /etc/iproute2/rt_tables, and add as many tables as
you need for your configuration. For each new table, you need a table identifier
and a table name.
You can use any name you want for the tables, but when using
VLANs, Ixia recommends that you use the VLAN ID and part of the
table name as the table identifier. See the example below, where
VLAN 25, 26 and 27 were defined over eth0.
Example:
# cat rt_tables
#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#

#1 inr.ruhep
25 vlan25table
26 vlan26table
27 vlan27table
6. After you have created the tables, you need to add the routes and rules for each
table/logical interface. To do this, you create two files in the etc/sy-
sconfig/network-scripts folder for each table/logical interface: route-ethx
and rule-ethx.
For example, assume that:

l VLANs 25, 26 and 27 were created on top of eth0.
l The VLAN IPs are: 10.25.0.2, 10.26.0.2, and 10.27.0.2.
l The IPs' corresponding gateways are: 10.25.0.1, 10.26.0.1, and 10.27.0.1.
Under these conditions, following files must be created:
/etc/sysconfig/network-scripts/route-eth0.25
/etc/sysconfig/network-scripts/rule-eth0.25
The content of /etc/sysconfig/network-scripts/route-eth0.25 would be:
default table vlan25table via 10.25.0.1
while the content of /etc/sysconfig/network-scripts/rule-eth0.25 would
be:
from 10.25.0.2 table vlan25table
The route-eth0.26, route-eth0.27, rule-eth0.26, and rule-eth0.27 files
should have similar content.
7. When you have finished, restart the network service using the service network
restart command.
Notes on Using Source-Based Routing

l When source-based routing is configured and you want to test the connectivity
with a destination, you must use the -I switch to specify the source IP that you
want to use.
For example, to test connectivity from interface IP 10.25.0.2 to destination IP
8.8.8.8, use: ping 8.8.8.8 –I 10.25.0.2. If 8.8.8.8 is reachable from the
10.25.0.2 interface, the ping should work. A simple ping 8.8.8.8 command will
not work, even if you have internet connectivity.

l In some cases, you may need to add a default route for the entire system. In this
case, you need to add a default route to the default routing table.
To add a default route for the entire system, configure the GATEWAY parameter in
one of the ifcfg-ethx files (if the interface uses a static IP address), or by con-
figuring DEFROUTE=yes if the interface uses DHCP.
Also, you can add routes under default routing table, using normal commands, in
which you do not need to specify the name of the table.
A PPPoE connection uses the predefined default routing table and will auto-
matically add a default route for the system.
l To display the routes corresponding to a specific table, use the following command
ip route show table <table_name>.
l To display the routing rules created on the system, use the ip rule command.
Make sure that there are no duplicate entries for a table.
l Inside the specific routing tables, add as many supplementary routes as you need.
l Source based routing is only recommended when multiple gateways are required.
l For routing to specific destinations, use static routes instead.
l If a probe has multiple interfaces, in the Hawkeye GUI you need to add the probe
multiple times, using various names, but with the same serial number. Man-
agement and test addresses must be configured in various ways, in order to match
your test ing requirements.
DHCP Example
The following example shows how to configure interface eth0 for DHCP (script file
ifcfg- eth0).
BOOTPROTO=dhcp
HWADDR=4C:02:89:00:F3:90 Replace the MAC value

with the actual MAC
address of the card
MACADDR=4C:02:89:00:F3:26 Include this line only if

you want to have a
spoofed MAC address

NM_CONTROLLED=yes Set to “no” if you don’t

want to allow changes
from the web interface
TYPE=Ethernet
IPV6INIT=no
DEVICE=eth0
DEFROUTE=no DEFROUTE must be “no”

to keep the default route
out of the default routing
table
ONBOOT=yes
Static IP Example
The following example shows how to configure interface eth0 with a static IP address
(script file ifcfg-eth0).
BOOTPROTO=static
HWADDR=4C:02:89:00:F3:90 Replace the MAC value with the actual MAC address
of the card
MACADDR=4C:02:89:00:F3:26 Include this line only if you want to have a spoofed

MAC address
NM_CONTROLLED=yes Set to “no” if you don’t want to allow changes from

the web interface
TYPE=Ethernet
IPV6INIT=no
DEVICE=eth0

IPADDR=192.168.1.10
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
NETWORK=192.168.1.0
GATEWAY=”” Set this parameter to null to keep the default gate-

way out of the default routing table
ONBOOT=yes
VLAN + DHCP Example

The following example shows how to configure VLAN ID 25 on logical interface eth0 for
DHCP (script file ifcfg-eth0.25).
BOOTPROTO=dhcp
of the card

MAC address

the web interface
TYPE=Ethernet
IPV6INIT=no
DEVICE=eth0.25
DEFROUTE=no DEFROUTE must be “no” to keep the default route

out of the default routing table

VLAN=yes
ONBOOT=yes
VLAN with no IP Address Example

The following example shows how to configure a VLAN (ID 25) with no IP address to cre-
ate a PPPoE connection on top (script file ifcfg-eth0.25).
BOOTPROTO=none
of the card

MAC address

the web interface
TYPE=Ethernet
IPV6INIT=no
DEVICE=eth0.25
VLAN=yes
ONBOOT=yes
VLAN with Static IP Example

The following example shows how to configure VLAN ID 25 on eth0 with a static IP
address (script file ifcfg-eth0.25).
BOOTPROTO=static

HWADDR=4C:02:89:00:F3:90 Replace the MAC value

with the actual MAC
address of the card
MACADDR=4C:02:89:00:F3:26 Include this line only if

you want to have a
spoofed MAC address
NM_CONTROLLED=yes Set to “no” if you don’t

want to allow changes
from the web interface
TYPE=Ethernet
IPV6INIT=no
DEVICE=eth0.25
IPADDR=192.168.1.10
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
NETWORK=192.168.1.0
GATEWAY=”” Set this parameter to

null to keep the default
gateway out of the
default routing table
Registering with a Hawkeye Server

Automatic Endpoint
Ixia includes a script that enables the XR2000 to automatically register itself with an
Hawkeye server. If you do not want or need to do this now, you can move on to the web
setup. If you later want to auto-register the XR2000, you can run the script at any time,
or you can use the web interface to configure auto-registration.

1. Connect to the XR2000.

2. Type the following command to start the script:
xr2000_configure
3. When the script prompts you, enter the following:
l A name for the probe. You can use letters, numbers, and hyphens (-) in the
name. The name will be used by Hawkeye to set the hostname, and displayed
as the probe name.
l The host name or IP address of the Hawkeye server (public IP if in cloud).
4. If you want to configure the XR2000's advanced features, continue with the web
setup process.
XR2000 Upgrades
Procedures below are valid for XR2000 and XR2000_vm probes
XR2000 Upgrade overview

Xr2000 will need an upgrade for one of 3 different reasons:
1. Update of Operating System so that security levels are maintained.

2. Update of Ixia software on the endpoint for manual probes
3. Apply Ixia software patch
The procedures below are valid for XR2000 and XR2000_vm endpoints.
Any XR2000 upgrading to latest Hawkeye Server release where the

XR2000 is on a version prior to 9.x it is recommended to upgrade oper-
ating system and then perform manual upgrade.
Automatic endpoint upgrade

When an automatic endpoint is connected to the Hawkeye server, the Hawkeye server
will automatically upgrade the endpoint to the required software version. This can be
confirmed by checking the endpoint version listed in Auto probe management for the
endpoint.
Manual endpoints upgrade from Hawkeye server

It is preferred to upgrade the XR2000 using the XR2000 command line interface to
obtain the software on the Hawkeye server. This way it is guaranteed the version

upgraded to will be compatible.
Use the following command:

> xr2000_upgrade offline <hawkeye server IP>
Confirm upgraded version with command:

> xr2000_version
Manual endpoints upgrade from internet

When the XR2000 has internet connectivity. Connect to XR2000 with ssh.
Run:
cd /tmp
wget https://ixiapublic.s3.amazonaws.com/hawkeye/xr2000_
upgrade.tar.gz
tar zxvf xr2000_upgrade.tar.gz
cd xr2000_upgrade
./ixia_chariotprobe_install.sh
cd ..
rm –rf xr2000_upgrade
rm –rf xr2000_upgrade.tar.gz
If the xr2000 does not have internet connectivity copy the file at the https://ixiapub-
lic.s3.amazonaws.com/hawkeye/xr2000_upgrade.tar.gz location, copy on USB drive to
XR2000 and place in /tmp folder. Then run the procedure.
tar zxvf xr2000_upgrade.tar.gz
cd xr2000_upgrade
./ixia_chariotprobe_install.sh
cd ..
rm –rf xr2000_upgrade
rm –rf xr2000_upgrade.tar.gz
A reboot after upgrade will be necessary.
Operating System Upgrade

Do not upgrade your operating system. The packages are constantly
being upgraded and may not function with a with a specific version of
the Hawkeye Server. If the operating system upgrade is required,

please contact Ixia Customer Support for assistance as it is preferred to

update only required packages.
Prerequisite for operating system upgrade is to have access to Internet. There is no way
to upgrade operating system without access to public servers.
To perform upgrade, login as root and type in:

yum update -y
yum clean all
To keep compatibility with the bittorrent test type in Hawkeye the following library
needs to be downgraded after yum upgrade:
yum downgrade libtorrent -y
XR2000_vm Installation
Overview
The XR2000 VM is available in OVA and QCOW2 images for windows and linux envir-
onments using a virtual manager. For windows systems the OVA image is used with a
VmWare hypervisor. For example VmWare ESX, VmPlayer and VmWare Workstation. For
linux systems the QCOW2 image is used with a virtual manager such as KVM or
OpenStack.
VM Requirements
l 8 GB of hard drive space
l Minimum 1 GB dedicated RAM. Ixia recommends 4 GB RAM
l Minimum 1 CPU. Ixia recommends 2 CPUs
l Access to virtual network
XR2000_vm installation using QCOW2

The XR2000_VM can be installed using a virtual manager such as KVM which supports
as a minimum centos 6.7 or greater. If openStack is to be used a minimum version of
liberty is supported.
Download the XR2000_vm QCOW2 from https://ixiapub-

lic.s3.amazonaws.com/hawkeye/xr2000_vm_Hawkeye.qcow2.

XR2000_vm installation using OVA

In order to complete the process of importing to VmWare you must have:
l VMware Client (downloaded from ESX/ESXi server for example)

l VMware credentials to create virtual machines (VMs)
Download the XR2000_vm OVA from https://ixiapub-

lic.s3.amazonaws.com/hawkeye/xr2000_vm_Hawkeye.ova.
Step by step process for ESX
Log in to VMWare Client.
Click File > Deploy OVF Template.
Click Browse and select the xr2000_vm.ova file.

Click Next.
Instructions for product are displayed:

Click next
Define a name for the VM (as will show in hypervisor)
Click next and select Datastore
click next and select Format for virtual disks (use default)

click next and select network mapping - this phase is important to ensure the mapping
is done to the correct interfaces.
click next and select power off after deployment

the xr2000_vm will be created
After booting phase if you go to the vmware console for the vm and the eth0 interface is
created and can get ip on a dhcp server, you will see the following displayed (ip dis-
played only if Vm can get an automatic IP):

The network configuration ip will be displayed. SSh server is available to login.
A web interface is also available on:
https://yourxr2000_vm:10000
Credentials to login to xr2000_vm via ssh or web interface
login/password
root/Ixia!123

Linux Quick Reference

This handy quick reference lists some standard Linux commands that you may find help-
ful with the XR2000.
netstat
Displays generic network statistics of the host.
If you include the -an and -rn arguments, netstat displays the routing table and the
application ports open on the XR2000, as well as their respective output.
With no arguments, netstat displays the active connections and the used sockets.
passwd
Changes the password for the current user.
route
Displays routing table information.
ifconfig
Displays the IP address and netmask associated with each Ethernet port. Also displays
details/counts of packets/bytes of traffic on each port
route
Displays routing table information
tcpdump
Displays the packets on an interface.
To use for a tcpdump –i eth0

specific inter-
face:
To use with tcpdump –i eth0 not port 22

no ssh port:

To export the tcpdump –i eth0 not port 22 –w /tmp/mycapture.enc

command out-
put to a file:
After capturing data, you can use the web interface remote tools Upload
and Download to load the .enc file and open it with Wireshark on a win-
dows PC.
XR Docker
The XR Docker image is a docker image which can be installed as a Hawkeye endpoint.
The XR Docker image can be installed on a platform as an application that is capable of
running Node to Node, Mesh, and a limited subset of Real service tests and functionality
of performing scheduled restarts from the Hawkeye Server. The XR Docker will register
as an automatic endpoint to a Hawkeye Server.
Base platform requirements

Linux x86 64 bit OS, 1 Gb RAM, and 1Gb hard drive is recommended.
Installation
Use the following instructions to create an XR Docker endpoint where internet con-
nectivity is available for base platform to run the XR Docker (endpoint) and only one IP
is being used for the base platform. Only one XR Docker container can be installed on a
single base platform.
In Hawkeye, go to the for software downloads web page, download the xr_docker install
script and transfer this file to the base platform of host the endpoint. Then follow the
installation steps mentioned below.
Contact Ixia Customer support for more advanced installations of XR Docker, such as,
multiple IP (multiple subnetworks) support and unavailability of internet connection for
Centos base system to obtain the XR docker image.
l It is expected the user will be familiar with Docker environment before

attempting XR Docker installation.
l Contact Ixia Customer support to install XR Docker on a host computer
without internet connection.

l For some base platform Linux OS such as Ubuntu, the docker package is ref-
erenced as ‘docker.io’.
Installation steps
1. Install the Docker library and Docker application on the Centos base platform.
2. Transfer the XR Docker install script (located on Hawkeye server - software down-
load web page) to the base platform.
3. Run the install script to simulate a Hawkeye endpoint. You may have to change
permissions on the file.
# chmod +x install_xr_docker.sh
4. The XR Docker endpoint automatically registers with the Hawkeye Server as part
of the start up process and registers using the IP of the host platform.
An example installation of XR Docker onto Centos 7.x platform:

1. Log (ssh) on as root on XR Docker host platform
2. Ensure latest libraries and packages are installed for Centos 7.x
# yum update
3. Install Docker package and start application.
# yum install docker
# systemctl start docker
4. You are responsible for configuring the Docker as to how your organization wants
to deploy them. By default the Docker application on the host computer will not sur-
vive a reboot. Ixia recommends you to consider the following command to con-
figure the docker application to be persistent and remain functioning on rebooting
the host computer.
# chkconfig docker on
It is your responsibility to apply a restart policy for the XR Docker
to restart following a host computer reboot.
5. Transfer the XR docker image for Hawkeye (located on Hawkeye server - software
download web page) to the Centos platform. It is recommended this is performed
from /tmp directory.
6. Run install script to activate the XR Docker container and create an XR Docker end-
point.
# ./install_xr_docker.sh

The user will be prompted to enter the endpoint name and the IP of the
Hawkeye Server. The XR Docker endpoint will register with the Hawkeye
Server and perform any necessary software upgrade from the Hawkeye
Server.
7. Confirm XR Docker container (Endpoint) is successfully running with below com-

mand and verify on Hawkeye Server – probe management webGUI.
# docker ps
sample output
Container
ID Image Command Created Status Ports Names
54f755a4ccb9 xr_docker_ /startup.sh 7 Up 7 XR-

x86_ minutes minutes Docker-
64:latest ago MC1
Log files on the XR Docker container can also be accessed for debugging purposes if dir-
ected by Ixia customer support.
XR Docker Changes – new endpoint name/Hawkeye

Server
The XR Docker is installed and any changes to its endpoint name and registered
Hawkeye Server follow the same concepts as all software endpoints. The XR Docker will
have to be stopped and re-installed in order to enter the new endpoint name and/or the
new Hawkeye Server IP. This is done by the following steps:
1. Log (ssh) onto XR Docker host computer.

2. Re-run XR Docker from the directory previously transferred to (ex. /tmp) to set
new endpoint name and new Hawkeye Server IP.
# ./install_xr_docker.sh
3. Confirm XR Docker registered on Hawkeye Server – probe management webGUI.
XR Docker Removal/Uninstall
The XR Docker can be removed from the host platform using the following commands:

1. Log (ssh) onto XR Docker host computer.

2. Run docker ps command to get the container name of your current XR Docker.
# docker ps
sample output
Container
ID Image Command Created Status Ports Names
54f755a4ccb9 xr_docker_ /startup.sh 7 Up 7 XR-

x86_ minutes minutes Docker-
64:latest ago MC1
3. Stop the XR docker container.

# docker stop <container ID>
4. Remove docker container from system.
# docker rm <container ID>
5. Find image file name.
# docker images
sample output:
Repository Tag Image ID Created
xr_docker_x86_64 latest 6c209f438d3b 6 hours ago
6. Remove the docker image from the host platform.

# docker rmi <image ID>
7. Remove install script and image tar from platform (from directory you transferred
install script to – recommended/tmp):
# rm -rf xr_docker_x86_64.tar install_xr_docker.sh
XR Docker debug tips

1. You can access the log files on the XR Docker container for debugging if directed
by Ixia customer support. The XR docker container can be accessed with a Linux
bash shell with the following command.
# docker exec -it <containerid/container name> bash

After you access the container, the following common XR commands are avail-
able.
# probeVersion
2. The XR Docker runs as a container on a host computer so the IP routing and port
restrictions of the host computer apply. If tests are failing due to connectivity reas-
ons, as seen in Hawkeye test results, check the firewall and iptables settings of
the host computer.
3. If the XR Docker is flagged as Private in Probe Management but it is expected
to be Public, check firewall settings of host computer.
4. If multiple XR Docker endpoints are required to be created for the user, a shortcut
of downloading and using a local copy of the XR Docker image can be employed as
follows:
l The first installation of an XR Docker endpoint will result in the XR Docker
image (.tar) file being downloaded onto a host computer. This TAR file can be
copied to the next host computer. Load the XR docker image and then run the
install script as follows:
# ./install_xr_docker.sh,
Then run
# docker load -i <xr docker tar image>
5. Log files on the XR Docker container can also be accessed for debugging purposes
if directed by Ixia customer support. Contact Ixia customer support for detailed
instructions.
6. How to cleanup unnecessary XR docker image, useful if you get into strange scen-
ario of having multiple docker images/entries.
# docker ps
# docker stop <cntrID>
# docker rm <cntrID>
# docker images
# docker rmi -f <imageID>
7. If the base platform is Ubuntu or similar, it may require commands to be preceded
by ‘sudo’ to execute commands with root access.
Software endpoints
Software endpoints offer the User the ability to use any hardware platform as a Hawkeye
endpoint but with the limitation of not being able to run Real Service tests. The XR2000
VM is an exception to this rule.

Different flavors of probes/endpoints can be downloaded from www.ixiacom.com web-

site. Go to the following link for download:
http://www.ixiacom.com/products/ixchariot/endpoint-library/platform-endpoints
The endpoints available on the Ixia web page are for the most part fully
compatible with Hawkeye, but some specific versions may not be com-
pletely tested with current Hawkeye server. It is recommended to down-
load the endpoints from Hawkeye server directly to ensure 100% tested
compatibility and stability with current Hawkeye version.
You can also download from the Hawkeye server directly:
Mobile Phone Endpoints

Android and iOS software endpoints can be found on the respective app stores.
Look for key word IXIA in the application search engine.
The application is Hawkeye Endpoint or Ixia Performance Endpoint.

Installing Software Endpoints

For most software endpoints (Windows, Android, iOS), the installation is very straight
forward with a few clicks.
The important step is the registration server configuration: the url or IP address (public)
of Hawkeye server must be filled in for automatic endpoint creation and management.

Routing and Ports management

Specifics on IP and port blocking for security is different for every company and is best
addressed by other networking resources. The variety and combination of ways to
achieve this is immense. For this reason, it is considered beyond the scope of this user
guide.
This section explains how the Hawkeye server communicates on ports to the endpoints.
Endpoint to endpoint tests (communication) and Real service tests to and from the end-
points and internet.
Differences between manual and auto endpoints are explained for routing and ports
used.
There are many factors such as NAT, firewalls, VLANs, cloud, private and public net-
works, and IPV6 to be considered.
Tips on debugging routing issues are addressed. The purpose here is to identify ports, IP
ranges that are open or blocked, but not on how to resolve these issues.
If the Hawkeye server or endpoints are deployed in the Cloud, contact Ixia Customer
Support for suggestions on enforcing security with enabling or blocking egress or ingress
of ports, IP’s, traffic types per port range and direction of traffic (egress/ingress).
The server, upon installation or upgrade, runs a script to enable required ports. This
script updates the Linux system files in /etc/sysconfig/iptables and etc/sy-
sconfig/ip6tables directories and enables the following ports for both IPV4 and IPV6:
l TCP: 80, 123, 443, 22, 25025-25050, 10117, 546, 4501-4502, 27000-27009
l UDP: 123
Port 123 is for the NTP service for accurate clock timing.
Hawkeye ports for automatic endpoints

The following diagram displays the information about the ports that are required for man-
agement and traffic for the probes/endpoints:

Port or Port
Range Modi-
Port fication
Description (s) Policy Protocol Directions Description
probes to 10117, Not modi- TCP From probes Mandatory for

Hawkeye 25025- fiable to server node to node
server for 25050 (hardware and mesh test-
node to node and soft- ing
and mesh ware)
probes to 443 Modifiable TCP From probes Mandatory for

Hawkeye with to server advanced
server for advanced con- (hardware probes admin-
Real Ser- figuration probes istration and
vices only). real services
executions.

Port or Port
Range Modi-
Port fication
Description (s) Policy Protocol Directions Description
Probe to 10115, Not Modi- TCP AND Probe to Mandatory for

probe man- 10116 fiable UDP Probe, bid- node to node
agement irectional or and mesh test-
private to ing.
public only UDP port is only
10116 is required for
used only in tests with syn-
direction of chronization
public probe (network KPI,
any real time
traffic)
Direction is
always private
to public in case
of mix in same
pair.
Probe to User Modifiable TCP From Probes Default to AUTO

Probe traffic defined from admin- to server which picks any
istrator con- port available
sole in on probes. Need
preferences to be enforced in
Hawkeye con-
figuration in
case of FW
between Probes

Hawkeye ports for manual endpoints

The following diagram displays the information about the ports that are required for man-
agement and traffic for the probes/endpoints:

Port or Port
Range Modi-
Descrip- fication Pro-
tion Port(s) Policy tocol Directions Description
Hawkeye 10115 Modifiable TCP From Server Mandatory for

Server to with to probes node to node
probes test advanced con- (hardware and mesh test-
man- figuration and soft- ing
agement (contact Ixia ware)
node to Support)
node and
mesh
Hawkeye 22,1000- Modifiable TCP From Server Mandatory for

Server to 0* with to probes advanced
probes Real advanced con- (hardware probes admin-
Services figuration probes istration and
(contact Ixia only). real services
Support) executions,
Port 10000
optional for
web admin of
xr2000 and
XRPi - requires
web admin
activation on
xr2000 or XRPi
Probes to 80,443* Modifiable TCP From Required for

Hawkeye with Probes to probe auto
Server - advanced con- server registration pro-
auto regis- figuration cess - ONLY for
tration (contact Ixia automatic end-
Support) points

Port or Port
Range Modi-
Descrip- fication Pro-
tion Port(s) Policy tocol Directions Description
Probe to 10115 Modifiable TCP AND Probe to Mandatory for

probe man- with UDP Probe, bid- node to node
agement advanced con- irectional and mesh test-
figuration ing.
(contact Ixia UDP port is
Support) only required
for tests with
syn-
chronization
(network KPI,
any real time
traffic)
Probe to User Modifiable TCP From Default to

Probe traffic defined with admin- Probes to AUTO which
istrator con- server picks any port
sole available on
probes. Need
to be enforced
in Hawkeye
configuration in
case of FW
between
Probes
Managing Probes Behind NAT

It is highly recommended to use automatic endpoints for probes behind NAT.

Required Port forwarding

Some NAT port forwarding needs to be configured on the NATing device so that ports are
forwarded to the probes.
The ports that need to be port forwarded:
For management:
l port 10115 on TCP and UDP (UDP is needed for time sync for Voice or Video pairs,
or any RTP pairs).
l port 22 for Real Service testing. Port 22 is also used for xr2000 hardware probes to
manage the probes remotely.
For traffic:
l port 10116- 10120 (example). A larger range may be needed if more concurrent
pairs of traffic are set against the NATed probe as destination.
TCP/UDP port needs to be configured for port forwarding depending on the nature of
traffic.
This must be set in the configuration of the system as well to consider the traffic sent.
See the following section for more information on handling NAT.
Hawkeye configuration for NAT

When NAT is applied, an endpoint may have a public and a private IP. These can be
viewed in Probe management for the endpoint. Need to make sure the private IP of des-
tination endpoints are added to the NAT table. On the Hawkeye server, there are 2
steps to configure Hawkeye for NAT:
1. In Administration > Preferences > Test Engine Tab, set the autoNAT to 1.

2. Force traffic to be in range 10200 - max Range. There is no max range. The max
range is defined by maximum number of concurrent pairs in Administration >
Preferences > Traffic Port Management, set Destination Port con-
figuration to 1 and First Destination Port to 10116.

Hawkeye scenarios for endpoints

When a firewall is involved in a test, the following possible testing scenarios appear,
with respect to the Hawkeye server, source and destination endpoint localization in
private/enterprise networks or public networks/Cloud. Each of these scenarios is
detailed in a separate topic below.
For these scenarios, the source and destination endpoints are determined by the dir-
ection of the traffic. When using a reversed traffic direction, the source and destination
endpoints for the scenarios are in reversed order as compared to how they appear in the
user interface.
While adding the source (from) and destination (to) endpoints to the test in the test exe-
cution configuration, check that they are in the relevant network for the use case being
tested. If it is not located in the correct network for that particular use case, you can
change that in the endpoint management dialog:
1. Select probe management (endpoint management).

2. Select the relevant automatic endpoint.
3. Edit and change the public/private to ensure it is correctly configured.
Assumptions
Unless otherwise specified, the following assumptions are made for firewall testing:
l The Hawkeye server (Hawkeye server and the registration server) are accessible
to all endpoints in a test.
l The virtual image that hosts the Hawkeye server comes with a pre-installed Regis-
tration Server. Although virtually any endpoint can act as Registration Server, we
recommend to use the pre-installed one. The Hawkeye server and Hawkeye regis-
tration server may have different IP addresses.
l When multiple system components are located in a private/enterprise network, we
assume that they are in the same network, with full network connectivity between
them.
l When exiting the enterprise network, a device may be encountered which acts as a
firewall, performing address translation and, for the most part of the testing scen-
arios, port translation.

l When entering the cloud, a device may be encountered which performs only 1:1
Network Address Translation (NAT), without any port translation. If a firewall is
also present, the ports specified in each of the test scenarios are opened.
l The Registration Server is usually able to detect if an endpoint is located behind a
firewall in an enterprise or in the public space/cloud.
Operational Concepts
For the purpose of running tests involving firewall, we consider the following working con-
cepts:
l Hawkeye server: is the main server for Hawkeye, that includes Hawkeye test
engine server and Registration server.
l Hawkeye Server (C): Central point of test execution. It is delivered as a virtual
image.
l Registration Server (RS): A service that handles endpoints management and
acts as a mediator between the Hawkeye Server and endpoints at runtime.
l (Source and Destination) Endpoints: Performance Endpoints that are installed
and run on the clients' device(s)
l Private/Enterprise: A private, usually enterprise network, located behind a fire-
wall, whose address is not Internet-routable and thus needs Network Address
Translation (NAT)
l Public: A public (and fully routable IP address) network
l Cloud: A network with a private/non-routable address, yet exposed as a public IP
by way of a 1:1 TCP/UDP IP-mapping (NAT) rule
Hawkeye Server, Source and Destination Endpoints in

Private/Enterprise
In this case, all types of traffic are supported.
Given that all Hawkeye components are located in the same private/enterprise network
(and, as such, there is no firewall or NATing between them), no special settings must be
configured. The endpoint should appear as public and/or be configured as such.
The following diagram illustrates the use case referencing the underlying components
from Hawkeye control engine that are involved and which ports are used.

For Hawkeye, both Hawkeye Srv and Registration server are located on
Hawkeye server.
Source and Destination Endpoints in Private/Enterprise

and Hawkeye Server in Public
We assume that both endpoints are in the same private network and that no device is
present that can alter the traffic or IPs.
Make sure that the private/enterprise firewall allows for outbound con-
nections to the public ports shown in the figure below.
The endpoints need to be set to private mode for this use case.
The following diagram illustrates the use case referencing the underlying components
from Hawkeye control engine that are involved and which ports are used.
For Hawkeye, both Hawkeye Srv and Registration server are located on
Hawkeye server.

Source Endpoint in Private/Enterprise and Destination

Endpoint, Hawkeye Server in Public
nections to the public ports shown in the figure below
The endpoint in private (entreprise) must be configured as private, the endpoint in pub-
lic must be configured as public.
Destination Endpoint in Private/Enterprise and Source

Endpoint, Hawkeye Server in Public
In this case, non-streaming flows over UDP and AppMix traffic are supported only if the
actions mentioned in the Limitations section are performed. Multicast Traffic is not
supported.

nections to the public ports shown in the figure below.
Hawkeye server, Source and Destination Endpoints in

Public
No special requirements in this case.
Source and Destination Endpoints in Private and

Hawkeye Server in Cloud
For the firewall at the entry point into the cloud, make sure to open the following ports:
l TCP management ports (for the Registration Server): 10117

l TCP reporting ports (for the Hawkeye Server): 25025-25050

l TCP licensing ports (for the Hawkeye Server, only if an external license server is
used): 27000-27009
nections to the Cloud ports shown in the figure below.
Source Endpoint in Private/Enterprise and Destination

Endpoint, HawkeyeServer in Cloud
In this case, all types of traffic are supported, except for non-streaming flows over UDP.
l TCP management ports:

n 10115 (for the destination endpoint)
n 10116 (for the destination endpoint)
n 10117 (for the Hawkeye Server)
used): 27000-27009
l UDP port: 10115
l Open into the Cloud firewall the TCP/UDP ports that you plan to use for test traffic,
then go to User Preferences and configure the same range there in the port man-
agement in preferences section.

Destination Endpoint in Private/Enterprise and Source

Endpoint, Hawkeye Server in Cloud
In this case, non-streaming flows over UDP and AppMix traffic are supported only if the
actions mentioned in the Limitations section are performed.
l TCP management ports:

n 10115 (for the source endpoint)
n 10116 (for the source endpoint)
n 10117 (for the Registration Server)
used): 27000-27009
l UDP port: 10115
l Open into the Cloud firewall the TCP/UDP ports that you plan to use for test traffic,
then go to User Preferences and configure the same range there in the Ports
opened for the test traffic into the public / cloud firewall section.

Limitations
By default, when the destination endpoint is behind a firewall (enterprise or Cloud),
application mixes traffic fails at test run unless the following actions are performed:
l In the firewall, make sure to open the ports corresponding to the applications that
you want to emulate. The table below lists the corresponding TCP ports set by
default for the test traffic as defined in the port management preferences.
l If the NAT is activated, an entry must be added in the NAT table to make sure that
the traffic is routed to the private IP of the destination endpoint(s). This is for test
traffic only.
Debugging routing issues

Registering XRPi/XR2000 endpoint to Hawkeye server
If endpoint does not register:
1. Check routing to Hawkeye server

2. Check ports open to Hawkeye server
3. Use nmap (linux command) to check ports open
nmap -d -p 10117,25025-25050,443 <Hawkeye server>
4. Confirm able to ping Hawkeye server from endpoint

5. Confirm on the Hawkeye Server in Probe management new endpoint can be seen.
6. Confirm in Probe management for the cloud endpoint a private corporate network
IP and a public internet IP can be seen

7. Confirm on the Hawkeye server in Probe Health Check that the endpoint is in a
state of link up.
Troubleshoot connectivity between endpoints

Ssh to the XRPi/XR2000 endpoint or Hawkeye server and confirm routes with “ifconfig”
and “route -n” commands. The “ping” and "traceroute” commands may be helpful.
ifconfig
route -n
ping -I wlan0 <peer endpoint>
ping -I wlan0 www.google.com
ping -I eth0 <peer endpoint>
Issues with Node to Node tests can be caused by connectivity issues. Check routes and
no port blocking.
Ssh to endpoint and use nmap to verify path between endpoints.
nmap -d -p 10115,10116,10117 <peer endpoint>
nmap -d -sU 10115,10116 <peer endpoint>
The output will identify if a port is open or closed.
Suggested ports to verify are the following:
l Port 22 - TCP - traffic for ssh. Debugging for Admin users

l Port 443 - TCP - HTTP/HTTPS traffic. Real service traffic
l Port 80 – TCP – HTTP and HTTPS traffic
l Port 10115-6 - TCP – management. Hawkeye server to Endpoint. Endpoint to End-
point management.
l Port 10115 - UDP - Endpoint to Endpoint sync timing traffic for RTP traffic like
Skype4B, Voice services, Network KPI
l Port 10117 - TCP - Endpoint auto-registers with Hawkeye
l Port 25025-25050 - TCP - Endpoint reporting test results
l Skype4B traffic port ranges are configurable. Vary with test traffic type. Example
for Skype4B is given below:
n UDP ports 49751 – 49999 (default Skype4B audio)
n UDP ports 59751 – 59999 (default Skype4B video)

Verify traffic ports used in Hawkeye server in Preferences – Traffic Port Man-
agement. To verify routes correct run N2N traffic test between two endpoints (UDP/TCP
bidirectional tests). First run ipconfig on endpoint, then run test, then run ipconfig after
test and this will show packets increasing for RX/TX on interface used.
Troubleshoot endpoints/Hawkeye server in the Cloud

In this case, non-streaming flows over UDP and test traffic are supported only if the
actions mentioned in “port limitations” are performed.
TCP management ports:
10115 (for the source endpoint)
10116 (for the source endpoint)
10117 (for the Registration Server)
TCP reporting ports (for the Hawkeye Server): 25025-25050
UDP port: 10115
Open into the Cloud firewall the TCP/UDP ports that you plan to use for test traffic, then
go to User Preferences and configure the same range there in the Administration -
Preferences - Traffic Port Management.

System Optimization
System Optimization
The following sections explain how to optimize the performance of the Hawkeye Server.
It is important to understand the Hawkeye software upgrade brings in required CentOS
updates compatible with Hawkeye Server and all necessary security upgrades.
You must not run yum update on the Hawkeye server in case required
libraries are changed. Contact Ixia customer support to update a pack-
age for a specific requirement.
Hawkeye Services
If the user needs to make a change to a Service configuration file or manipulate the
MySQL database, the services that run the Hawkeye Server must be stopped and restar-
ted to prevent database corruption and implement configuration changes.
The Hawkeye system is based on a CentOS (version of linux) system.
The Hawkeye server consists of a number of services. The “hawkeye” service is a top
layer script that runs multiple sub-services. There are two additional key services,
which are the apache service (web server) which is labelled as “httpd” and the “mysqld”
database service.
These services can accept commands from the command line when the user has ssh to
the Hawkeye server. The command options are “start”, “stop”, and “status” to start the
service, stop the service, and check the status of the service, respectively. Theses com-
mands can be run by using the “service” command.
Following are the commands for the httpd (apache web server) service. Replace “httpd”
with “mysqld” for the database service.
l stopping: service httpd stop

l starting: service httpd start
l checking status: service httpd status
The hawkeye and httpd service should be stopped when attempting any sort of low-level
maintenance on the database as they both perform many operations on the database
even on a fundamentally idle system. All three services should be stopped while res-
izing the mysql database. Each service must be stopped and restarted if any con-
figuration for that service is changed in its configuration file. Always stop the “httpd”

System Optimization
and “hawkeye” service before stopping the “mysqld” service, then restart in reverse
order.
Hawkeye service
The hawkeye service configuration file is located at /home/ixi-
a/Hawkeye/conf/configuration.txt. It is not recommended that the user change any val-
ues in this file without consulting Ixia Customer support. The Hawkeye server GUI uses
the Preferences section to change some settings. Passwords are defined in the file but
refer to Change Passwords on page 96for changing passwords safely.
Apache web server service

The apache (web server) service should not have the configuration file changed without
consulting Ixia Customer support. The configuration files are located in the /etc/ht-
tpd/conf/ and /etc/httpd/conf.d/ directories. It is feasible that for a Hawkeye Server
handling large numbers of users and endpoints that the /etc/httpd/conf.d/30_fcgid.conf
file may need to be tuned but not without consulting Ixia Customer support.
mysql service
The mysql service configuration file is located at /etc/my.cnf. Refer to the section on
Manage MySQL Database – MySQL RAM for instructions on changing the amount of RAM
allocated to the mysql service. The user should consult with Ixia Customer support
before making any other change to this file. The actual database is stored on the
Hawkeye server under directory /home/mysql_data and user must not make any
changes in that database manually.
Manage MySQL Database

Allocate MySQL RAM
When the Hawkeye Server virtual machine was created, a certain amount of RAM was
allocated to it. All Hawkeye services and the MySQL server share this RAM.
The MySQL service is configured to use 1GB of RAM by default. This is considered insuf-
ficient for most Corporate environments.

System Optimization
The MySQL database configuration parameters are located on the Hawkeye server in the
file /etc/my.cnf directory and the user can modify these.
Refer to the section Hawkeye Services for information on how to start an stop services
safely to implement the changes mentioned below.
The most important parameter that needs to be adjusted is the parameter that sets the
max amount of RAM to be used by MySQL. The default Hawkeye server settings is to
save all test results for 1 year, the amount of RAM required for processing this much
data for multiple users may result in slow performance of the system. In addition to the
work of saving and recycling of test results in MySQL.
Parameter: innodb_buffer_pool_size=1G
The default is to limit the MySQL to 1GB. For large systems, Ixia recommends setting
this to 70% of available RAM on the Hawkeye server. For a Hawkeye Server with 16GB
of allocated RAM, Ixia recommends setting this to innodb_buffer_pool_size=11G.
MySQL transactions per hour

Default value for max_connections parameter for MySQL database in /etc/mysql.cnf
is 80. This defines the maximum number of concurrent connections opened against
MySQL. In the case of numerous endpoints/tests per hour(above 1000 per hour), Ixia
recommends to increase this number to 1000.
Control size of MySQL Diskspace

Available disk space was allocated to the Hawkeye server virtual machine during its cre-
ation. The MySQL database can grow to a very large size. For large systems running a
high number of tests per hour, if this goes unchecked all disk space could become used
which will prevent the Hawkeye server from running tests. The size of the MySQL data-
base is a combination of how many endpoints/tests per day are executed and the num-
ber of days configured to retain MySQL tests and metrics for report generation.
The default settings for Hawkeye Server will result in one year of tests results to be
saved. The user is highly recommended to configure the number of days to store test res-
ults to keep the system manageable. There are two suggested ways to calculate how
much disk space will be used by the system daily:
1. A rough rule to calculate disk space required: An approximate estimate will be 1

test = 2 kilobytes (KB) of data. So, 1,000 tests per day will generate 2 MB of data

System Optimization
and 1,000,000 tests will generate 2GB of data.

2. Once system configured with all endpoints and scheduled tests the daily use of
disk space can be calculated. by using ssh to Hawkeye server, then running the
command “df -h”, then 24 hours later run the same command and see what the
daily growth of the MySQL database is.
If the disk space is growing rapidly at 100 MB a day and the Hawkeye server virtual
machine was created with a virtual disk space of 30 GB this means after 300 days the
available disk space will be filled.
On the Hawkeye server under Administration > Preferences there are two para-
meters:
l Number of days for database retention: 365

l Number of days for database retention for detailed metrics: 180
These two parameters define the recycling and retention period for keeping test results
and metrics. For the example above, Ixia recommends you to set the Number of days
for database retention and Number of days for database retention for
detailed metrics to 180 days (6 months) to allow for a large safety margin.
The Number of days for database retention for detailed metrics are disk intens-
ive and the retention period should be less than the Number of days for database
retention. For systems under heavy load (>100000 tests a day) it is recommended to
change this metric to less than 30 days, if possible less than 10 days is highly recom-
mended.
The parameter for Number of days for database retention of admin elements can
be reduced to as low as 5 days as it is mostly used for log tracking.
Resize MySQL Database

Occasionally a User may find that they want to increase the amount of disk space being
used by the Hawkeye server in order to retain test results and metrics for a longer
period. There are a number of ways this can be achieved.
The recommended way is to backup the MySQL database. Copy the MySQL backup to
another disk. Next use the virtual manager and add another disk to the Hawkeye server
virtual machine. Many virtual managers allow the merging of two disks if physically loc-
ated on same physical device. Some virtual managers allow increasing the size of the

System Optimization
virtual machine image with just one command line, but each virtual manager is dif-
ferent.
Alternatively, create a new Hawkeye server virtual machine and install the same soft-
ware version of Hawkeye, then restore the MySQL backup. Refer to Upgrading Hawkeye,
which explains database backup and recovery.
It is not recommended to create a new virtual disk then use a mount point from
/home/mysql_data to new virtual disk. The time delays for two physically located hard
drives may prove problematic and has not been verified by Hawkeye QA team.
Generation of Reports
Generation and scheduling of reports can be very CPU intensive.
There are many configurable preferences that will impact report generation.
The parameter Max report generation time sets a maximum amount of processing
allowed to generate a report. If this time is exceeded the report is abandoned.
In the Advanced section of preferences, the parameter Maximum number of

graphs in a saved or scheduled report sets the maximum number of graphs to be
included in a report. After the maximum limit is reached, the report generation is com-
plete.
Hawkeye supports a mechanism to shorten the time to generate reports for users. This
is done with an embedded data aggregation mechanism. This is enabled and configured
with the two parameters Automatic storage of aggregation levels and Aggreg-
ation for report use. This data aggregation capability works by constantly aggreg-
ating (averaging test metrics) data over periods of time (hour, few hours, day) so that
there is less data to look for when users are building reports on large data sets. By
default, the Hawkeye server will be constantly maintaining these aggregation tables but
not use them unless enabled. The values are represented in seconds. The default
aggregation period is 1 hour, 3 hours, 1 day, which is selected by 3600, 10800, and
86400 respectively.
The aggregation for report use defines how Hawkeye automatically adjusts aggreg-
ation levels.
When users are looking for data for a date range, the aggregation level used will be:
If 0: raw data always (no aggregation)

System Optimization
If >0, the requested time range by the user (in second) is divided by "aggregation for
report use" integer and the aggregation period is the maximum one that is less or equal
to this number.
Example: "aggregation for report use" level is 7, selected range is:
l last hour: 3600 seconds / 7 = 514, so we do not use aggregation

l last 12 hours: 3600*12/7 is >= 3600, so we use 3600 (1 hour) aggregation
l last day : 3600*24/7 is >= 10800 so we use 10800 (3 hours) aggregation
l last week : 3600*24*7/7=86400 is >= 86400 so we use 86400 (1 day) aggregation
Parameters effecting Performance

Sync and set time of Hawkeye server and Linux end-
points
The clock used by the Hawkeye server and endpoints must be synced to the same
source to ensure the timestamps of test results stored in the database are synchronized
and stored using the actual time on the Hawkeye server. The test results will then be
timestamped to the time (timezone) of the Hawkeye server. A test from an endpoint in
one timezone to an endpoint in another timezone will have an entry in MySQL dated
using timestamp from the Hawkeye server.
The clock on the Hawkeye server and the Linux endpoints (XRPi/XR2000/Linux SW) can
be synced to a common clock assuming access to the internet.
The following commands on the command line interface of the Hawkeye server or end-
point will synchronize clocks:
l service ntpd stop

l ntpdate pool.ntp.org
l service ntpd start
Another option is to set the correct timezones by choosing a city under /us-
r/share/zoneinfo directory. For example:
ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
After the Hawkeye Server virtual machine clock has been changed for the Hawkeye
server to adjust to this change the user must stop the hawkeye, httpd, and mysqls

System Optimization
services, then restart each service in reverse order (alternatively reboot Hawkeye
server). Refer to Hawkeye Services for more information.
A user in a different country (timezone) using a web browser to the Hawkeye Server
must be aware of this time difference when viewing test results and generating reports
as test results/reports will be dated by the Hawkeye server time and not the user’s local
time.
If Hawkeye server and endpoints are not synced to the same clock source the
timestamps of tests in the Hawkeye server, may not be as expected as the
Hawkeye server, will be scheduling tests using one clock and the endpoint run-
ning tests by another clock.
Hawkeye timeout for receiving Statistics

In the Test Engine section of preferences the parameter Statistics receive
timeout (seconds) defines the max amount of time the Hawkeye server will wait for
an endpoint to send the test results once a test has completed.
Test timeouts
In the Test Controller section of preferences there are many parameters defining
max test durations. After a timer expires Hawkeye server ends the test and cleans up.
In the Advanced Options section, the parameter Maximum time processing Node
to Node and Mesh tests specifies how many seconds after test duration is over
before the Hawkeye server ends the test and cleans up.
There are two parameters for Real Services. In the Test Controller section the para-
meter Real Test Max duration defines how long the endpoint processes the test,
after which time the endpoint terminates the test. In the Advanced Options section,
the parameter Maximum time processing Real Service tests specifies how many
seconds after test duration is over before the Hawkeye server ends the test and cleans
up.
Auto Refresh of web pages

The user needs to be aware that the autorefresh of web pages impacts CPU usage and
must not be too frequent. There are three autorefresh timers, one for the main

System Optimization
dashboard, one for the map display, and one for other web pages such as floorplans and
test execution pages.
There are two parameters in the Main section of preferences.
The parameter Dashboard autorefresh enables or disables the automatic refresh of

the main dashboard statistics. The second parameter is Dashboard autorefresh
interval , which defines how often the statistics for the main dashboard are re-cal-
culated and displayed. We recommend you to keep this above 30 seconds.
The parameter Refresh Execution List Timer specifies how many seconds between
updating the test execution web pages. It is recommended to keep this value above 10
seconds for system performance.
The parameter Map update frequency in seconds impacts how frequently the maps
are re-calculated. It is recommended to keep this above 30 seconds. The parameter
Refresh list timer value impacts other web pages that support autorefresh. We recom-
mend you to keep this above 10 seconds.
Max concurrent tests in GUI

There is a parameter Max Concurrent Tests in GUI in the Main section of pref-
erences that defines how many tests are allowed to be running concurrently. This para-
meter when set correctly will ensure no issues with tests failing to run because the
number of licensed tests has been reached. This parameter effectively manages the
maximum number of simultaneous tests and will queue up those tests that need to run.
This also indirectly allows the user to define how much CPU processing is allocated to
processing test results.
Map Refresh
The frequency for updating maps can be CPU intensive. There are two parameters under
Preferences in Administration that defines this. First the parameter Map Report
must be enabled or disabled. If disabled no processing of maps to be displayed will take
place. In the GUI section of preferences the parameter Map update Frequency in
seconds defines how frequent the processing or refreshing of maps will be performed.
As this impacts the CPU we advise not setting this value to less than 30 seconds.

System Optimization
Probe Healthcheck polling interval

In the Advanced Options section, the parameter Test Controller: Polling interval
defines how often the test controller process will poll each endpoint to check its status.
We recommend you to keep this above 4 seconds. This impacts Probe healthcheck
feature and reporting alarms for endpoint down (email/SNMP traps).
Log retention minutes

In the Logs section, there are two parameters used to define the test log retention time
on the Hawkeye server. The Log Retention minutes specifies how many minutes to
retain Hawkeye test logs in the directory /home/ixia/Hawkeye/logs/Hawkeye. The para-
meter Test Engine Log retention specifies how many minutes to retain the endpoint
test logs in /home/ixia/Hawkeye/logs/Chariot.
Enforce strict test intervals

In the Main section of the system preferences, the parameter Disable Interval
Optimiser if enabled (1) means that for each test a button will now be present allowing
on a per test basis to disable the scheduling optimizer so the specific test will be
executed on their scheduled start times. If this is disabled (default 0) then a schedule
optimizer may make slight adjustments to the start times of scheduled tests to optim-
ize.
Automatic endpoint retry of tests

Hawkeye has a feature to automatically retry a test that fails to execute. This is useful
in unstable networks. However if a Customer has limited licenses and has carefully
scheduled a number of tests to maximize the available licenses enabling this feature
may result in increased licenses being used at once.
Under Administration in preferences for the Test Engine there is a parameter

allow_pair_reinit_run which is used to enable disable the automatic retry of failed
tests. If enabled and a test fails to start due to connection issues, the test will retry in
pair_reinit_retry_interval seconds. The test will be tried a further pair_reinit_
max_run number of times. The retry interval after the first attempt is defined by pair_
reinit_retry_interval_run seconds.

Security
Security
This section provides information on the corporate security that Hawkeye provides.
Another layer of security is the use of firewalls to block specific ports for ingress/regress
to the endpoints and Hawkeye server which is explained in the Routing section.
The administrator can set the timeout period for the Hawkeye client (User’s web access
to Hawkeye server) by setting a parameter on the web page Administration > Prefer-
ences > GUI > Max Idle Timer.
The Hawkeye server by default uses HTTP (port 80) for web access. This can be
changed to secure HTTPS (port 443) access if required. If a user wants to do this they
are recommended to contact Ixia Customer Support for the steps as it involves changing
two configuration files and possibly disabling port 80 in iptables.
Secure access to Hawkeye server

Hawkeye Server by default is enabled for HTTP access using port 80. Some organ-
izations prefer to block HTTP (port 80) access and only allow HTTPS (port 443). The
Hawkeye Server has a configuration file /home/ixia/Hawkeye/conf/configuration.txt
which has the parameter “WebServerPort” set to 80. You can edit this file and change
this to 443 to enforce HTTPS for browser access. This will force all web browser access
to the Hawkeye server to use HTTPS but Hawkeye server can still use port 80 by the
Apache process. In order to prevent all HTTP access you will need to edit the file /etc/ht-
tpd/conf/httpd.conf and comment out the line Listen 80 by preceding it with # symbol.
After you change either one or both files, stop the Hawkeye service and restart it to
apply the changes. Refer to the section Hawkeye Services on how to do this.
It is not recommended but for the advanced security conscious organization the SSL pro-
tocol and the cipher algorithms to be used can be configured/restricted by changing the
/etc/httpd/conf.d/ssl.conf file. Examples of changes are to exclude SSL protocol 1.0 and
1.1 and only use 1.2. Another example is to prioritize a list of ciphers to be used (nego-
tiated) for the connection. Important to note as this is a linux system file not maintained
by Hawkeye it can be replaced by an upgrade thus requiring the user to restore any pre-
viously saved changes to the file following the upgrade.

Security
Customer certificates for Hawkeye Server

When using secure access to a Hawkeye Server (HTTPS), you can avoid a certificate
warning when logging into the Hawkeye Server webpage by using a certificate. The
Organization may have port 80 blocked for security or may have a Corporate require-
ment only to use HTTPS for the Organizations webservers. There are two steps:
l Generate a signed SSL certificate for the Hawkeye Server.

l Configure the Hawkeye Server to use the certificate.
The following sections describe this process.
Create Certificate Signing Request (CSR) on Hawkeye Server

Users seeking to purchase a signed SSL certificate from a Certification Authority will
require a Certificate Signing Request be generated by the Server with both a Public and
Private key. While pursuing, the signed SSL certificate, a customer will need to gen-
erate a Certificate Signing Request (CSR) to be provided to the Certification Authority
(CA) as part of their application.
To generate the CSR from the Hawkeye server you will need to log into the server via
SSH and run the following commands.
openssl req -new -newkey rsa:2048 -nodes -out YourServerName.csr -key-
out YourServerName.key
Some attributes may be changed to meet the customer security stand-

ards or the recommendations or requirements of the CA. (example
rsa:2048 indicates 2048 bit key)
Following the command, you will be prompted to answer some questions about your
organization and the FQDN of your server.

Security
Upon completion, your system will have two new files in the directory from which you
ran the openssl command. YourSeverName.csr and YourServerName.key. Please move
YourServerName.key to /etc/pki/tls/private/ for use later.
Use cp (copy) and not mv (move) when placing the files in their new dir-
ectories).
The YourServerName.csr contains your Certificate Signing Request to be submitted to

the Certification Authority of your choice.
Add signed SSL certificate to Hawkeye Server

Customers seeking to purchase a signed SSL certificate from a Certification Authority
(CA) will provide them the “YourServerName.csr” file and will receive back a SSL Cer-
tificate (.crt file). This is known as the CA certification process. The SSL Certificate (.crt
file) will need to be added to the Hawkeye Server and ssl config changed to use the file.
The new SSL Certificate (.crt file) will need to be saved in /etc/pki/tls/certs/. If you
have not already done so you will also need to save the .key file that was generated dur-
ing your Certificate Signing request generation to /etc/pki/tls/private/ ( *Note please
use cp (copy) and not mv (move) when placing the files in their new directories). Once
the files are in the correct directories you will need to edit the following file with vi or
your favorite linux text editor.
vi /etc/httpd/conf.d/ssl.conf

Security
You will need to change the following to lines to point to your signed files instead of the
localhost self-signed versions that are provided by Ixia.
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
Once the two lines are edited you will need to restart the Hawkeye web server. Refer to
the section Hawkeye Services on how to do this.
Following the start of httpd you should be able to reload the Hawkeye website by going
to https://www.YourServerName.com. This time you should not be prompted about hav-
ing an unsigned certificate.
Hawkeye User Authentication

You can authenticate Hawkeyeusers in the following ways:
l Users defined locally

l Users defined in LDAP Server
l Users defined in secure (Ixia) login server
There is a parameter in Administration > Preferences, which defines the system

Authentication Mode to be used.
Users defined locally

The administrator can define new users in Administration > System Users Man-
agement. The System Authentication Mode is set to 0 for this authentication type.
The administrator can enforce complex passwords by setting a parameter in Admin-

istration > Preferences > Main > Enforce Complex Password.
Users defined in LDAP server

In Administration > Preferences, the administrator can configure an LDAP server for
authenticating users. Hawkeye supports using both regular LDAP and secure LDAP serv-
ers.
For the regular LDAP server, which can include Active directory type LDAP servers, the
System Authentication mode is set to 1 or 2 for LDAP. The Hawkeye server

Security
validates additional users by authenticating with the defined LDAP server. When Sys-
tem Authentication mode is set to 1, the user must already be defined as a user on
the Hawkeye server and the LDAP server is used to validate the password. When the
System Authentication mode is set to 2, the user name and password are validated
against the LDAP server and then automatically added as a user for Hawkeye. It is the
responsibility of the System Administrator to update the System Users Management
to change the entry for the user to reflect the expected group. Ixia recommends setting
System Authentication mode to 1 to keep control of the access and rights on the
Hawkeye server.
For the secure LDAP, the System Authentication mode is set to 4 for LDAP. The
Hawkeye server must already have users defined on its System User Management
to allow a select subset of the Organizations users access to the Hawkeye server. The
secure LDAP server is used to validate the password for the user.
In Administration > Preferences, define the following parameters to use the LDAP
server:
• LDAP server address
• LDAP Domain
• LDAP Bind DN
• LDAP Bind password
• LDAP Group Base DN
LDAP Bind DN, Bind DN password, and LDAP Group Base DN

must be defined for using secure LDAP.
Refer to the Organizations secure LDAP server configuration to know the DN parameters
that you must specify. These can include a combination of: OU, UID, CN and DC/DC.
The values are not case sensitive.
An example for secure LDAP configuration is given below:

System authorization mode: 4
System Users management: entry for user i.e. gauss
LDAP Server address: ldap.forumsys.com
LDAP domain: dc=example,dc=com
LDAP Bind DN: cn=read-only-admin,dc=example,dc=com

Security
Bind Password: password

LDAP group based DN: ou=mathematicians,dc=example,dc=com
User logs into Hawkeye webclient as: gauss/password
Users defined in Ixia Login

The Ixia Login is a service allowing users to be authenticated (email/password val-
idation) for using a Hawkeye server. The Ixia Login service manages and validates pass-
words for an email address. The user will still have to be pre-added to the local
Hawkeye server by sysadmin. If Ixia Login is enabled, and a user attempts to login to
the Hawkeye server. First the user is confirmed to be defined in the local Hawkeye data-
base, then the Hawkeye server queries the Ixia Login service to confirm the user
entered a valid password (authentication).
The Ixia login feature for authenticating users is applied when the system Authentic-
ation mode is set to 3. To use the Ixia Login service, the administrator defines a new
user in the Adminstration > System Users Management and the user is defined
with an email address that ends in [email protected]. This allows a defined
user to access the Hawkeye server. The user engineer must then access the Ixia login
server and register, which means providing an email address and password. The Ixia
Login service will then send an email to the email address provided requiring con-
firmation to make the user active.
When the user engineer attempts to login, the Hawkeye server contacts Ixia to val-
idate the password provided for the login. If the username and password match in the
secure Ixia Authentication server, the user engineer is allowed to login. The privileges
allowed to the engineer is det ermined by the sysadmin administrator that defined the
account for the engineer in the Adminstration > System Users Management (refer
to Users and Groups Management).
The Login field has to be a valid email address registered at www.ixi-

acom.com.
Users and Groups Management

This section covers users and groups management. The system administrator sees all
tests, all probes and all system configuration. Users can be defined to be part of groups
and only allowed to run certain test types and use certain endpoints. The users and
groups would only be able to see test results for this limited set. This offers a level of
security in that a group of users could be limited in their view of the Corporate network.

Security
Maps and floor plans visible to the users/group showing the status of the current net-
work follow these restrictions.
Users can be further restricted in their use of the Hawkeye server with the use of test
templates. This allows the system administrator to create test suites such as a voice_
suite and office_suite (collection of appropriate Node to Node or Real Service tests) with
pre-canned thresholds. These controlled tests could then be assigned to users. This
would limit users to a controlled set of tests to be able to detect network issues affecting
their groups/area. Refer to Replicating tests across multiple endpoints.
Users and Groups definitions in Hawkeye

Hawkeye application supports different users and groups of users. The user level and
group appurtenance will allow to decide which sets or results the user shall be able to
see.
Users and groups rules

l Each Hawkeye user belongs to a group of users
l Each Hawkeye user has one user role
There are five user roles associated with Hawkeye:
l System administrator
l Group administrator
l User
l System viewer
l Group viewer
Test results view depends on user role:

l System administrator can see all results from all users from all groups
l Group administrator can see all results from all users from the group it belongs to
l User can see only test results from tests triggered by the user
l System viewer can see all results from all groups
l Group viewer can see all results from group it belongs to

Security
Probe availability depends on user role:

• Probes created by System administrator are available for test to all users and groups
on the system by default (can be changed by a setting in database). Only System
Administrators can remove or update the probes
• Probes created by Group administrator are available for test to all users from the group
AND system administrators. Only Group administrators and system administrators can
remove or update the probes
• Probes created by User are available for test to the user AND system administrators.
Only current user, group administrators and system administrators can remove or
update the probes
Tests availability depends on user role:

All test types are available by default for the administrator group of users. Admin-
istrators can assign test types for group of users, who will have access only to the
assigned test types and the results of those test types.
Map availability depends on user role:

The maps configured for probes geographically display can be created, modified, or
removed only by administrators. The administrators assign maps to group of users.
Group management
Creating a group
1. Login into Hawkeye application.
The user can only create Groups if the Admin level privileges of the
user is set to System Administrator .
2. Select the Administration menu from the main menu bar. Select option System
Group Management. The following options becomes available:

Security
3. Enter the User Group Name. Enter group comments if any. Select Enabled or Dis-
abled to set the status of the group. For example, Voice group was created for the
users that will test the VoIP network.
Disabling the group disables all users belonging to the group, and there-
fore prevent them from accessing the application.
4. Assign the test types intended to be used by the group created. On the left side
panel, all test types are available. The test types added to right side panel, makes
those tests available for the new group created. For example, Voice test types
were added to the Voice group.

Security
5. Click Add button to save the group created into the database. If everything is OK,
the group should be present in the Group table.
6. Hawkeye application allows the user to edit the comments, the status of an exist-
ing group and the available test types. To edit click on the Edit icon next to
the group ID or group name, of the group that you want to edit. All information
about the group will be displayed in the text boxes below, and the update option
will be enabled, as shown below:
If the status of a user group is set to Disabled, users in that group will
not be able to log into the Hawkeye.
7. Hawkeye also allows the user to Delete an existing group. Click on the Delete
icon of the group that you want to delete. A new pop up window will appear, as
shown below, asking for confirmation. Click OK to delete the group.
Deleting a user group will also delete all users into this group.

Security
Users Management
Creating a user
1. Log in into Hawkeye application. A new user can be created only by a member of
System Administrator or Group Administrator groups.
2. Click on the Administration option on the main menu. Select from the drop-down
list option System User Management.
3. To add a new user, enter the details of the user in the text boxes as shown below.
l User with admin level privileges set to System Administrator can add
new users to any of the existing groups
l User with admin level privilege set to Group Administrator can add new
users only in the group to which the user belongs.
l A user logged in to the Hawkeye with System Administrator privileges,
will be able to view the details of all the users members to all groups.
l A user logged in to the Hawkeye with Group Administrator privileges,
will be able to view the details of the users belonging only to that particular
group, to which the logged in user belongs to.
l A new user can be assigned different User Level privileges as per the
requirement.
There are five different user levels:
l System Administrator is the super user. This level has complete access to the
Hawkeye application. The user with this privilege level can add and delete users
and groups, enable and disable users and groups, view probes of each user, view
scheduled tests by each user, and extract results.

Security
l Group Administrator user role can perform the same actions as the system
administrator, but the actions are limited only to the group that the user belongs
to. A group administrator is not entitled to add and delete groups.
l Group Viewer user role can only view and extract the test results of the tests run
by the users in that group.
l Full System Viewer user role can only view and extract the test results of the
tests run by all the users belonging to various groups.
l User role can create own probes and schedule a test or run a test. The user can
only view and extract the results of the tests that the user has executed.
User, logged into Hawkeye, with System Administrator privilege level can assign
any of the above five user levels to the new added user.
User, logged into Hawkeye, with Group Administrator privilege level can assign only
the following three user levels to the new added user: group administrator, group viewer
or user.
Editing a user
Hawkeye allows you to edit the details of an existing user.
To edit a particular user, click . The text boxes will be updated with the current
information about the user. You can modify any of the fields except the Login field, and
click the Update button. This will update the user details in the database and the same
will be displayed in the users table.
Removing a user
Hawkeye also allows the user to DELETE an existing user.
Click next to the user you want to delete. A new pop up window will appear, asking
for confirmation. Click OK to delete the user.
Tracking actions of a user

Hawkeye offers the possibility to track the actions that a particular user did in the sys-
tem. To access this feature, select Administration menu from the main menu, then
User trail sub menu. The following page will be displayed:

Security
To filter the user, type the login name into the User column. The filtering is done dynam-
ically.
The information provided is:
l ID of the action;
l Date and time when action was taken;
l Type of action taken;
l Source IP from where the action was taken;
l User name.
The user trail feature is available only for users with administrator priv-
ileges.
Change Passwords
Modify mySQL Password
The mySQL database for the Hawkeye server uses a password of Ixia/Ixia123 and
root/Ixia123. For Corporate security, we recommend you to change the default pass-
words.
To change the password for the mySQL database for Ixia and root to access mySQL to
run the Hawkeye server do the following:
1. Shutdown Hawkeye services from Hawkeye server console. Use the command
belwo to stop the services
l # service Hawkeye stop
l # service httpd stop

Security
Stopping the httpd service, stops Apache which is the mechanism to

access mySQL.
2. Change your password with mySQL command line using the following commands:
l # mysqladmin -u root -p’Ixia123’ password ‘newpassword’
l # mysqladmin -u Ixia -p’Ixia123’ password ‘newpassword’
You have changed the root and Ixia account (as we include this in
our Hawkeye server user guide) passwords.
3. Change file on Hawkeye server. To change the file, do the following:
l # cd /home/ixia/Hawkeye/Conf/configuration.txt
l Change passwords for the two databases
n "MySQL_Password" == "Ixia123"
n "Myresults_SQL_Password" == "Ixia123"
Ixia is the user account used by the Hawkeye server to access
mySQLdatabase. This is different from root account.
4. Restart Hawkeye server. You can also run the following commands from the
Hawkeye console:
l # service httpd start
l # ‘service Hawkeye start’
Change endpoint Root Password

The default endpoint username/password of root/Ixia!123 can be changed from the
Preferences under Administration. In the section for Test Controller the ‘probe
default login’ and ‘probe default password’ can be changed.
This will only change what the Hawkeye server will use so the user will also need to
login to every endpoint and change the endpojnt login credentials. For the XR hardware
(XRPi, XR2000, XR2000_VM) the user will need to be log in as root over ssh and then
change the local root password using the passwd command. Changing root password
for each type of Software endpoint wil be specific to the type of software endpoint.
When auto and manual endpoints are registered with Hawkeye server a secure link is
established (SSL) and this is used to run tests, bypassing the need to use the endpoint
root credentials.

Security
Impact to automatic endpoints: Auto probe management also uses the SSL connection
and is not impacted by changing endpoint root password. This will only impact ssh to
endpoints.
Impact to manual endpoints: This will impact ssh. Hawkeye server uses the endpoint
root credentials to query endpoint for manual probe management.
Change System Administrator Password

Using a web browser log into the Hawkeye server. Select the web page for system
users management under Administration. There will be a user entry for sysadmin.
Select the pencil to edit the settings for sysadmin. Once the edit button is selected the
bottom pane will allow the password for sysadmin to be changed.
Change Hawkeye Server Virtual Machine root Password

The default password for the Hawkeye server virtual machine is root/ixia123. This can
be changed by using ssh to the Hawkeye server and logging on as root. Then run the
passwd command to change the root password.
Captive Portal Support for WiFi

Hawkeye supports the use of a Captive Portal on the XRPi when connecting to a wifi net-
work. This section explains how to use and build a captive portal script to go through
the steps to login via a web interface into the WiFi network.
Follow the guidelines given below to build a captive portal script, so that an XRPi can
connect to an organizations Captive Portal using the WiFi Connect Test. To install and
use the Captive Portal scripts on the Hawkeye server, complete the following:
1. Confirm prerequisites are met

2. Manually perform Captive Portal operation
3. Connect to Captive Portal and save the script
4. Adapt and verify the script
5. Run the script from Hawkeye
Prerequisites
Before you start using captive portal on Hawkeye, you need the following:

Security
l An XRPi with wifi dongle

l A system with ssh client and X server, see Finalize installation on XRPi
l A connection to the network with the captive portal you need to build the script for
l Basic Python scripting skills
l Basic CLI Linux skills
Ixia highly recommends the time on the XRPi is synced to the time on the XRPi. If this is
not aligned, the web browser will appear very slow. Using a CLI on the XRPi issue the
‘date’ command to compare time to that on the Hawkeye server. The following set of
instructions ensure the time is correct on the XRPi:
l service ntp stop

l ntpdate pool.ntp.org
l service ntp start
You can also set the correct timezone by choosing a city under the /usr/share/zoneinfo
directory:
ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
Manually perform Captive Portal operation

Ensure that you have Xserver running on your system so the display for the XRPi will
appear on your system. It is recommended that you use Xming on a windows machine.
1. Run Xming so that you have X11 server active.

2. Establish a new ssh connection to the XRPi and enable X11 forwarding.
3. Log in as root on the XRPi ssh and run Firefox. Firefox will open a popup window on
your system in Xming.
4. Go to https://addons.mozilla.org/en-US/firefox/addon/selenium-ide/
5. Click Download Anyway.
6. On pop up, click Save file.
7. Click on download arrow, after download is complete.
8. Click and drag selenium_ide-2.9.1-fx.xpi to inside the mozilla/firefox window.
9. On the pop up asking if want to install Selenium IDE, click Install .
10. Click Restart firefox now.
11. You need to restart Firefox. After you restart ensure that you

Security
activate the SeleniumIDE add-on.

12. Ensure the XRPi is connected to WIFI. Ixia recommends using the wifi connect
option for the XRPi in Probe management on the Hawkeye web client to connect to
the WiFi AP. It is important to select none for authentication method. After the oper-
ation is complete, confirm XRPi has a WiFi dhcp IP address.
Connect to Captive Portal and save script

To record your script, do the following:
1. Select the top right Selenium IDE button, on your firefox browser to launch a
pop-up for selenium.
2. Click the red button on the top right corner of the Selenium pop-up to start the
recording.
3. Go to the browser and open any website. The system redirects you to the captive
portal.
4. Login with the credentials for your organization.
5. In the Selenium window click the red button to stop the recording. Login details
will be displayed in the table pane.
6. In the Selenium window from the File pull down menu select Export Test Case
as > Python 2/ unittest/ WebDriver and choose a directory and file on the
XRPi. Ixia recommends /tmp/scriptname.py.
7. On the XRPi go to the directory where you saved the file and confirm the script has
been saved with the command cat /tmp/scriptname.py.
Ensure that you save the script with .py extension.
8. Close selenium and ensure you do not select save again as it will change the script
being saved in the file.
9. Close firefox.
Adapt and verify the script

ssh to the XRPi and go to the location where you stored your captive portal record script
(scriptname.py). You can run your script again using the command:
python scriptname.py.
This will invoke Firefox and go through the same steps as recorded previously of logging
into the web site. The Captive portal for each organization is slightly different so you

Security
may have to rework the script to successfully log in. You will need to edit the script,
make some changes then run the script until it successfully enters the user-
name/password to authenticate the user. Below is a list of common changes that may
need to be made:
l Add a wait delay between passing the URL to the webdriver. This would mean
adding the line “time.sleep(1)”.
l Verify the generated url in script is correct. The URL may need to be modified or
replaced with direct reference to URL for Organizations captive portal.
l The Organizations captive portal site may invoke a pop-up for login credentials. If
a pop-up for login credentials appears, as a result of re-direction, it is possible to
prevent the pop-up by making the following script change (see Example 3
below):
n On line for driver.get(self.base_url + "/gp2/webportal…”), replace this with
driver.get(self.base_url)” .
l Use the Inspect feature of firefox to identify the name of the identifier for login,
password and the authenticate button. These may need to be updated as per
Example 3 given below.
l User may want to add wrapper in python to add more logic. This may require
advanced knowledge of python scripting. Contact Ixia Customer support if assist-
ance required.
Below are some working examples:
Example 1:
from selenium import webdriver
driver = webdriver.Firefox()
driver.get("http://www.google.com")
elem = driver.find_element_by_name("login")
elem.clear()
elem.send_keys("user1")
elem = driver.find_element_by_name("password")
elem.clear()
elem.send_keys("ppp")
elem=driver.find_element_by_name('Submit')
elem.click()
#html_source=driver.page_source
html_source=driver.title

Security
print "%s" % html_source

text_file = open('/tmp/seleniumoutput.txt', 'w')
text_file.write("%s" % html_source[:300])
text_file.close()
driver.close()
Example 2:
# -*- coding: utf-8 -*-
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.support.ui import Select
from selenium.common.exceptions import NoSuchElementException
from selenium.common.exceptions import NoAlertPresentException
import unittest, time, re
import os
class Ixiaguest(unittest.TestCase):
def setUp(self):
self.driver = webdriver.Firefox()
self.driver.implicitly_wait(30)
# self.base_url = "https://guest.ixiacom.com:8443"
self.base_url = "http://www.google.com"
self.verificationErrors = []
self.accept_next_alert = True
def test_ixiaguest(self):
driver = self.driver
# driver.get(self.base_url + "/gp2/web-
portal/ext/webPortalAuthLogin?portal_ip=10.212.240.1
32&client_id=74%3Ada%3A38%3A90%3A89%3Af5&-
wbare-
direct=http%3A%2F%2Fwww.google.com%2F&ssid=IXIA+Guest&bssid=28%3A8a
%3A1c%3A21%3A23%3A02")
driver.get(self.base_url)
driver.find_element_by_id("webPortalAuthUsername").clear()
driver.find_element_by_id("webPortalAuthUsername").send_
keys("nribault")
driver.find_element_by_id("webPortalAuthPassword").clear()

Security
driver.find_element_by_id("webPortalAuthPassword").send_
keys("IJ2W5Z")
driver.find_element_by_css_selector("img[alt-
t=\"Authenticate\"]").click()
def is_element_present(self, how, what):
try: self.driver.find_element(by=how, value=what)
except NoSuchElementException as e: return False
return True
def is_alert_present(self):
try: self.driver.switch_to_alert()
except NoAlertPresentException as e: return False
return True
def close_alert_and_get_its_text(self):
try:
alert = self.driver.switch_to_alert()
alert_text = alert.text
if self.accept_next_alert:
alert.accept()
else:
alert.dismiss()
return alert_text
finally: self.accept_next_alert = True
def tearDown(self):
self.driver.quit()
self.assertEqual([], self.verificationErrors)
hostname = "google.com" #example
response = os.system("ping -c 1 " + hostname)
#and then check the response...

if response == 0:
print hostname, 'is up!'
if __name__ == "__main__":
unittest.main()
else:
print hostname, 'is down!'
if __name__ == "__main__":
unittest.main()

Security
Example 3:
class IxiaGuestLoginTest1(unittest.TestCase):
def setUp(self):
self.driver = webdriver.Firefox()
self.base_url = "https://guest.ixiacom.com:8443/"
self.verificationErrors = []
self.accept_next_alert = True
def test_ixia_guest_login_test1(self):
driver = self.driver
driver.get(self.base_url)
driver.find_element_by_name("j_username").clear()
driver.find_element_by_name("j_username").send_keys
("mtest2")
driver.find_element_by_name("j_password").clear()
driver.find_element_by_name("j_password").send_keys
("H69KGR")
driver.find_element_by_name("submit").click()”
Continue when you have a working script.
Run the script from Hawkeye

To run the script from Hawkeye, do the following:
1. Move your python script into /home/ixia/Hawkeye/WebServer/uploads/, then ssh

to the Hawkeye Server and go to this directory. All files in this directory will sur-
vive a Hawkeye Server software upgrade.
2. Create a second file in /home/ixia/Hawkeye/WebServer/uploads/ called ixia-
portal. The file ixiaportal will contain the single command line xvfb-run python
/home/ixi-
a/Hawkeye/We-
bServer/uploads/scriptname.py>/tmp/outputselenium.log 2>&1.
3. Change the protection on both files to allow anyone to execute by using the fol-
lowing CLI commands
l chmod +x /home/ixia/Hawkeye/WebServer/uploads/ixiaportal
l chmod +x /home/ixi-
a/Hawkeye/WebServer/uploads/scriptname.py

Security
The Real service test, wifi Connect, has a configuration field for Captive Portal
Script, the user can enter the path and name /home/ixi-
a/Hawkeye/WebServer/uploads/ixiaportal so the captive portal script can be
run to complete connection to the organizations network.
Important to note the “wifi connect” test may give a status of “Fast re-
authentication” in the test results. If the organizations network supports
fast re-authentication, the AP will know that within a certain time period
the XRPi is still logged on, so will automatically allow the XRPi to con-
nect without authenticating the user with the Radius server (authen-
tication server).
Security audit logging of users

Many organizations require audit logs be kept of users activities on systems for security
purposes. Hawkeye maintains an audit trail of all users logging in and logging out of the
Hawkeye Server. It also tracks which user made changes to which system parameters.
These audit logs can be seen from the Hawkeye Server web GUI under Administration
> User Trail .

Configure Hawkeye
Configure Hawkeye
This section explains the details of the Hawkeye application configuration.
Interface Presentation
The left pane of the window allows you to select the various modules of Hawkeye.
The modules of Hawkeye are restricted by user privileges. You need to have access
rights to view the different modules.
This panel is the main menu of the application, which allows you to browse through the
different sub menus of the application.
On the same bar, info about the current login account is present: who is logged in and
last login info:
The central panel changes the appearance according to the options enabled in the main
menu.
The panel located on the bottom of the page shows options typically reserved for user
input and actions.
It is possible to move the gray bar (vertical only) so that the panels
sizes can be expanded or reduced.
Probes Management
This section explains how to add a new probe entry, manage existing probes (aka end-
points), check the probes health, and configure the probes to be displayed on the live
map.

Configure Hawkeye
Endpoint types: Manual vs Automatic
Hawkeye supports 2 types of probes:
Automatic:This is the recommended way to include probe/endpoint. When installing

the endpoint, the user simply needs to register the probe against Hawkeye server (see
Probe Configuration section). The endpoint will be automatically created into the list.
Manual:This is not recommended. The endpoint is manually added into the list of end-
points in Hawkeye.
Manual probe : add a new probe entry
Note: Automatic endpoints are automatically populated into Hawkeye.
Select the “Probes management” option from the Probe management main menu. As
shown below, this will open a probes table and a template to add new probes located on
the bottom of the page.

Configure Hawkeye
To add a probe, enter the following information:
l Probe name: <Name that will appear on test execution list>;

l Probe test IP: <IP address of the probe>;
l Probe management IP: if the management IP is the same as the probe test IP
leave this field blank;
l Probe location: address/location of the probe;
l Probe group: group to which the probe is associated with;
l Probe Area: allows user to define a probe area
l Probe service Tier: allows User to define s service tier
l Network Conf.: allows user to define network conf.
l Probe type: there are three types of probes available;
l Software – if the probe is a Linux software endpoint agent;
l XR2000 – if the probe is a XR2000 hardware device;
l XR2000_vm – if the probe is a XR2000 virtual machine installation ;
l XR_PI – if the probe is a raspberry pi sd image installation;
l Probe location availability: select one of the available options:

l Both from and to if probe is available for bidirectional tests;
l From only if probe is available as source;
l To only if probe is available as destination;

Configure Hawkeye
l Available for mesh: select if the probe is going to be available for mesh topology;
l Is active: select to make the probe available to use or set passive mode to use in
the future;
l Serial Number:Serial number used to identify probe uniquely. Probes with same
serial numbers are automatically considered as same hardware and will be treated
as unique device for scheduling and maintenance as well as for capacity checking.
Serial number is optional: if empty or set to ‘default’ then management ip will be
taken into account for identifying probes on same physical machine and different
test interfaces (or ID if this option is not selected in preferences).
l Probe Location Default Latitude:latitude coordinate of the probe for map con-
figuration;
l Probe Location Default Longitude:longitude coordinate of the probe for map con-
figuration;
Note: The probe coordinates must be known in advance. There is no GPS

device installed on the probes.
l Change username and password: Username and password used to connect to the
particular probes for remote management and real services execution.
Note: both user name and password are hidden and encrypted in database.
If both login/password per probe are empty, then by default username and
password as defined in configuration.txt file on server (see admin guide) or
username and password in preferences
To assign a probe to a particular group of users, select the group from the left panel
named “Available User Groups” and add it to the right panel named “Available for User
Groups”.
To complete the definition of a new probe in the system, click on ADD PROBE button.

Configure Hawkeye
To check if the test agent is available on the probe, click on the icon, in the probe
table.
If the test agent is available, the following message will be displayed:
If the test agent is unavailable, the following message will be displayed.
Remove a probe
A probe can be removed by clicking on the icon.
The probe needs to be removed from any existing mesh and any active test execution
schedule before being deleted. If you want to remove an automatic endpoint, you must
SSH to the endpoint and run the configuration command and remove reference to the
Hawkeye server IP address (set to 0.0.0.0). If this step is not performed the endpoint
automatically re-registers with the Hawkeye server and appears in the list of automatic
probes.
A warning message will be displayed if the probe doesn't meet these prerequisites:
Example:
Cannot delete Probe
remove probe from Mesh

Configure Hawkeye
Edit a probe
Click on the icon to edit an existing probe entry.
you need to have access to probe to be able to edit the probe !
The information about the probe will be available in the window below . They can be
edited and click on update probe button to save new information.
Note: the probe name can be changed but any existing test results will still be stored
into test history with OLD probe name. 2 probes with the same name will also show in
test history as same "entity" with no way to distinguish them.
View probe advanced information
Click on the icon to edit an existing probe and view following information: active
schedules which the probe is participating to, and meshes for which probe is belonging.

Configure Hawkeye
Probe health check
To check the status of the configured probes, select the “Probes Health Check” sub
menu located under the “Probes Management” menu.
Here you can see information about all the probes configured in the system.
The health check is performed against port 10115 availability.
real service and remote probe management use port 22 for probe connectivity and
would therefore not be taken into account by the health check mechanism.
Probe running information
current status, running status, name and other information is displayed in this screen.
This can help to understand current status of a probe and state.
This is for advanced admin users only.
below is providing an example of running status.

Configure Hawkeye
Manual Probe remote management
Probe remote management feature offers the user the possibility to control the probe
from the Hawkeye management server and to check various information about probes,
such as Hawkeye endpoint version, hardware configuration details and current status of
the available resources on the probe (CPU load, memory load and available disk size).

Configure Hawkeye
To access the probe remote management page, select the menu from the probe
management.
The following information will be displayed:
The available information about probes resources is related to:
l Hawkeye endpoint version;

l OS version;
l CPU type;
l Memory size;
l CPU usage;
l Memory usage;
l Total disk size;
l Available disk size;
To refresh the above information the probe must expanded and minimized.
Automatic or Manual Probe in Public or Private mode
Probes that are defined can be public or private depending on the way they are con-
necting to the network.

Configure Hawkeye
The mode definition is automatically 'guessed' by Hawkeye server first time the probe is
registering.
The guess is based on the comparison between probe local IP and probe IP as seen by
Hawkeye server.
Typically, if the probe is behind a NAT, the probe will be seen as a private probe.
Private/public mode is very important as it will define Hawkeye endpoints strategies to

bypass NAT/FW rules (see Firewall Test_UseCases )
There are cases where forcing a probe detected as private to public will be needed (or
the other way around). Understanding where the probe is compared to the location of
the other probe and Hawkeye server is important.
Test Execution
The following test topologies are available in Hawkeye:
1. Node to Node testing - allows execution of tests between one node (probe) and
another node (probe).
2. Mesh - will allow execution of tests on a full mesh of probes.
3. Real Services – will allow real tests (HTTP,FTP,ICMP,etc) test from probes to servers
located in internet.
Node to node test configuration

Configure Hawkeye
The node to node test execution will allow the following selections:
l Probe from: probe where the test is executed FROM (can be network side);
l Probe to: probe where the test is executed TO (can be access side);
l Test type: the type of test that will be executed;
l Test duration: the duration of the test time while the active traffic will be gen-
erated;
l Test options: depending on the test types, some options would be available to
select from (e.g. bit rate, packet size, number of concurrent pairs, etc…).
Note: The direction of the test will be from Node 1 to Node 2. When test
names include downstream, the traffic will be generated from Node 1 to
Node 2. When the name includes upstream the traffic will be generated from
Node 2 to Node 1.
Tests can only be executed between 2 manual probes or 2 automatic

probes, you can not have 1 automatic and 1 manual probe into the same
test schedule
Mesh test configuration

Configure Hawkeye
By selecting “Test Execution Mesh” option from the Test Execution main menu, the user
will have the option to configure tests for mesh topologies available. To see how to cre-
ate a mesh, check Probe Management section.
The mesh test execution will allow the following selections:
Mesh Name: select the mesh under test previously configured;
Test type: the type of test that will be executed;
Test duration: the duration of the test time while the active traffic will be generated;
Note: Not all test types available for Node to Node topologies are avail-
able for Mesh topologies.
Starting a test on a mesh will add all available paths in the mesh (see mesh creation
and configuration section).
Real Services test configuration
To configure a real service test scenario, select the “Test Execution Real Service” option
located under the Test execution menu.
The real services test execution will allow the following selections:

Configure Hawkeye
Probe from: probe where the test is executed FROM;
Test type: the type of test that will be executed;
Destination Server: the real server where the test is executed TO;
Test options: depending on the test types, some options would be available to select
from or configure to (e.g. DNS server, packet size, ping interval, YouTube code, etc.)
Note: Real Services test are available only for hardware probes type.
Test queue management
The status of a test schedule can be one of the following values:
- Running: the tests are under execution. This will be displayed into black color;
- Queued: waiting for execution – the test resources aren’t available (busy), so the test
is waiting in queue;
- Waiting next execution: the test is scheduled and the schedule is active, but the next
execution time is not available yet;
l Schedule on hold: the test is scheduled but the schedule has been placed on hold
(see putting a schedule on hold section);
l For mesh tests: queuing for completion. This status is displayed for a mesh test
when the mesh is partially completed and the test is split into different test runs.
The following priority in the queue applies:

Configure Hawkeye
l The later next test execution takes priority;

l One shot tests are executed in priority to scheduled tests;
l The mesh schedules that need to be completed are executed in priority. The next
execution time for a mesh is not changed until last run completion;
Node to Node tests are executed in priority to Mesh tests.
Test scheduling configuration
The test scheduling options are available for all type of test configurations. The func-
tionality is the same all configurations.
Test interval [minutes]: defines the time interval between tests. This interval is cal-
culated on best effort basis, as the tests in the queue might be too numerous to allow all
intervals to be respected. In case the interval is too small for tests to be executed, the
queue will automatically adjust to best possible interval to execute the test.
If the test Interval is set to 0, then the test will be executed only one time. This will be
displayed as one shot test. In this case, the test will be displayed into test execution
table while waiting for execution (Queuing) or running. Once the test is completed, it
will be removed from the test execution table and the results will be available into the
test results lists.
Start schedule : defines the date when the schedule shall start.
l If left blank, the current date will be applied;

l If Interval is set to 0 (one shot test), then this will define when to start the test (in
batch mode);
l To select the day and time, change time (24 hours selection) and click on the
selected date.
End schedule : defines the date when schedule must end.

Configure Hawkeye
l If left blank, the schedule will last forever;

l If Interval is set to 0 (one shot test), then this end schedule will not be considered;
To select the day and time, change time (24 hours selection) and click on the selected
date.
Note: The test execution list will display only the schedule currently active
OR active in the future. All schedules not active any more will not be dis-
played in the list.
Note:test execution frequency of less than a minute is supported and needs

to be enabled in preferences /main section by administrator
Cancel a schedule test

Tests can be canceled by selecting the delete button. This will cancel the test or
schedule.
If the test is waiting for execution, in the queue or on hold, the test will be canceled dir-
ectly.
If the test is canceled while running, first it will finish the current run and then will be
canceled.
The scheduled test list is refreshed every minute by default. It might be the case
that canceling a test or a schedule that appears queuing of waiting next execution gets
the test canceled into a running mode instead. In that case the test execution will
refresh and the new status of the test be displayed.

Configure Hawkeye
Set a schedule on hold
Tests can be put on hold by selecting the pause button. This will put the sched-
ule on hold so wait for next execution. The button will transform in play button,
and by selecting this button the test schedule will resume.
If the test is waiting for execution, in the queue or on hold, the test will directly change
status.
If the test is running, after the current run ends, the test will be put on hold. A specific
status (running then hold) will be displayed.
Disable interval optimizer
Interval optimizer is taking the time of test execution start and adds the interval for
next run. If the queue delays the start time for the first test or if there are some test exe-
cution interruptions then the interval optimizer will take that into account and optimize
the queue for being as close as possible for the execution interval. A downturn of this
behavior is that there will be no guarantee for the exact execution test times.
Disabling the interval optimizer will force the test execution to take place at the first
execution time + test interval. This means that when the test is executed, the next exe-
cution time will be set to first time + n * interval time where n is set to be the next time
for the schedule.
Example: first time is 12:00 and interval is 1 hour. If the test is executed at 16:12 then
next time will be set to 12:00 + n* 1 hour so 17:00. This will allow enforcing the

Configure Hawkeye
schedule to execute at exact times but if the queue is full it would delay the execution
and not optimize the queue for best use.
Threshold management
Thresholds are the baseline to decide if tests are passing or failing. Setting up correct
thresholds is essential for understanding the test results and making sure that the right
level of information is in the database.
View the default thresholds
To check the thresholds configured default in the application, select the “Global
Threshold Management” menu located under the Administration tab.
The list of available test types, corresponding pairs and metrics will be displayed:

Configure Hawkeye
Different thresholds can be filtered based on test types, pair names, and metrics.
The following information per test type, pair name and metric is displayed:
l Default threshold: this is a system wide default threshold for the metric. The value
is a float.
l Threshold type: currently three types of thresholds are supported:
l <=: the test result value will PASS if the result is less or equal to threshold. Any
result value above threshold will FAIL. (e.g.: delay or jitter measurements).
l =>: the test result value will PASS if the result is greater or equal to threshold.
Any result value below threshold will FAIL. (E.g. throughput).
l %: this defines a percentage of expected throughputs. This threshold is uniquely
supported for throughput and test types where user can define throughput (bit
rate) value. The test will PASS if the expected % of generated throughput is
reached, it will fail otherwise.
- Record timing records: during some tests supported by Hawkeye, some timing records
will be recorded during the test allowing Hawkeye to store information of behavior of
test. This will depend on the test type and will be available when selecting individual
test report (see browsing test results section).

Configure Hawkeye
Change the default thresholds
Only users with administrator privileges can change default thresholds.
The default thresholds can be changed from the default threshold page.
By selecting the pencil button, the threshold will be automatically selected.
The bottom part of the screen allows to change the value of the threshold (the threshold
type cannot be changed).
To change the default threshold, edit the Threshold value field, configure the new value
and click on Update Threshold button.
Configure threshold per test
Hawkeye application offers the possibility to change a specific threshold per test that
will be configured to run either in a node to node topology, mesh or real service scen-
ario.
To configure the threshold per test, select any test execution module. On the panel,
where the test parameters are configured, select “Show threshold option” button. The

Configure Hawkeye
available thresholds for the selected test type will be available. In the example below,
the available thresholds for node to node, DNS response time are shown:
The parameters that can be changed are:
- Threshold value;
- Threshold type;
Note: The threshold is changed only for the current test configuration. If a new
test of the same type is configured, for which the same thresholds must be con-
figured, the thresholds must be configured again in test configuration process.
If the thresholds must be changed globally, follow the steps mentioned in the
Change the default thresholds section.
Alarms management

Configure Hawkeye
Alarms configuration
When configuring a test, the users have the possibility to set up alarms to be sent in
case of failure or error in the test.
To enable the alarm configuration, click on the “Show Alarm Option” button located on
the bottom panel of the screen.
The first row defines the trigger for test status on Alarms:
- Status change: an alarm will be triggered when test result status will change. This will
only be triggered on scheduled tests and allow notification of a test result status chan-
ging.
- Failed: an alarm will be triggered every time a test result is failed (test was completed
but the threshold was not met).
- Error: an alarm will be triggered every time a test is reporting error (the test couldn’t
start or be completed).
The alarms can be sent either by e-mail or SNMP.
Both alarms types need to be setup at installation with third party Email (SMTP
server) and/or SNMP alarm management system so that traps are generated to it. The
administrator can configure only one or the other alarm or none depending on the
Hawkeye integration.
The user has to select at least one “Set alarm on” for setting up the alarm. NO alarm will
be created if no option is selected in the “set alarm on” section.
The user can choose between the different alarm types. The alarm will be on for the dur-
ation of the test schedule. Alarm configuration can be seen in the alarm section.

Configure Hawkeye
View alarms current settings
The alarms are set based on tests schedules and when these are defined. The alarms
will run while the test schedule is active. The alarm management screen displays the
currently running tests with alarms setup and their statuses. The alarm menus are avail-
able under “Administration” menu on the main options bar.
The alarm information contains: from probe name, to probe name, alarm type and dif-
ferent alarm settings.
To change or remove an alarm, the related test execution needs to be cancelled and re-
executed with new alarm settings, if required.
View alarms list
Selecting the alarm list under the administration menu will display the alarm list in
reversed chronological order. There is no filtering available in the current version.
The alarm list shows the current status of alarms, and the related test data record ID
and schedule execution ID.
Mesh Management
This section describes the process of creating and managing a mesh test, using a group
of probes. Click Probes Management > Mesh Management to create and mange a
mesh test.
Add a mesh
1. Select the Add Mesh from the menu.

Configure Hawkeye
2. Specify the name of the mesh in Mesh name.

3. Specify the description of mesh in Mesh Description.
4. Select Is Active to make the mesh test available in the test execution mesh.
Default is selected. See mesh test execution selection for more details.
5. Select the probes from the Available Probes for Mesh list in the left column
and click add>> to add the probes to the Selected Probes for Mesh column.
By default no mesh paths are selected. In order to customize the mesh, select
paths from the Selected Probes for Mesh column.
6. Click select all or unselect all to select or clear selection of all mesh paths.
Notes:
l For a full mesh created using the selected paths, if you add more probes to
it, neither the mesh nor the hub and spoke is complete. You must manually
update the mesh to be full mesh or hub and spoke. Appropriate messages
are displayed in the top panel describing the type of mesh configured (Full
mesh or Hub and spokes).
l Meshes containing more than 200 selected paths can have performance
impact on server when using default MySQL configuration. It is essential to
optimize MySQL configuration as per instructions mentioned in Manage
MySQL Database.
l The manual path selection table is only supported for meshes that have
less than 50 selected probes. More than 50 selected probes will result in no
full mesh option and only the buttons at the top can be used to configure

Configure Hawkeye
hub and spoke mesh.

l The maximum number of mesh paths supported is 2450.
7. Click Save Mesh to save the mesh.
8. Click Mesh List or select Probes Management > Mesh Management menu to
see all meshes created.
9. To edit a mesh, select a mesh from the Mesh List menu and click the edit
icon. The following options will be available for editing:
l Add probes to mesh
l Remove probes from mesh
l Change mesh name
Configure a mesh: Hub and spokes

To configure a hub and spoke topology with a mesh, complete the following steps:
1. After you select a mesh from the Mesh List, click to edit it. The following
screen will be available.

Configure Hawkeye
2. Select the probe from the drop-down list, which you want to configure as hub.
3. Click Configure hub and spokes button. Automatically all paths between the
hub and the spoke will be created.
In the example below, Austin probe was selected as hub. Automatically all paths were
created when the Configure hub and spokes option was selected.

Configure Hawkeye
Remove a mesh
l Click to remove a mesh test.
MAP configuration and probe location con-

figuration
Hawkeye has a built in feature to configure geographical maps for displaying the probes
physical location.
The feature is built on top of Google Maps application.
l The probe coordinates must be available in order display the probe on the
map. There is no GPS device installed on the probes.
l The Hawkeye Server must have internet access in order to able to access
Google Maps
To start the map configuration process, select the Probe Management then select Maps
Management. The following window will be available:

Configure Hawkeye
On the left side, the Google map is displayed, on the right side the configuration area.
Map configuration step by step
1. Browse to the desired area and zoom at the desired level.

2. When the position is set, define the map name;
3. Press the Get Coordinates button.
In the example below, the desired map is the map of United States, at a zoom level of 4.
Once the position is set and the Get Coordinates button is pressed, the coordinates and
zoom level will be automatically filled in the specific fields.

Configure Hawkeye
Once the position is set, the next step is to assign probes on it. There are two ways in
configuring probes on map.
1. Configure the probes coordinates when a new probe is created. In this case, once the
probe is selected from the “Available for map” group, the probe will be automatically
placed at the configured position.
2. If no coordinates are configured during the new probe creation process, the Hawkeye
user has the option to manually place the probe at the desired location. To do this, fol-
low the nest steps:
a. Select the probe from the “Available for map” group and add it to “Selected for map”
group;

Configure Hawkeye
b. Once the probe is in the “Selected for map” group, click on it. A marker will be auto-
matically dropped on the map.
Note: The marker will be dropped always in the same position for all probes
that will be configured to be displayed on the map.
c. Use drag and drop function to move the probe to the desired position.
d. Once the marker is on the position, the coordinates of the probe will be available in
the Probe latitude and longitude fields.
Note: The coordinates of the probe are automatically saved.
e. To configure the next probe, repeat the steps from a to d.
Note: When a new probe is selected to be placed on the correct coordinates,

the marker of the previously configured probe will be removed from the map.
.
Once all the probes are placed in the desired locations on the map, to save it click on
the “Add map” button.
By default the map is available for all groups of users and it is assigned to all meshes.
If a map is configured for a particular group of users, the administrator has the option to
assign it only to that particular group. To do this, while configuring the map, select the
group to which the map will be assigned from the “Associated group” and save the map.
Note: If the Associated group is particular, the map will be available only for
that particular group and for the system administrator.
.
If a particular mesh will be displayed on the map, select the mesh from the “Associated
Mesh” list.
You can build multiple maps and all are listed in Maps Management

Configure Hawkeye
This menu offers the possibility to edit and remove maps. Also, the user can check
quickly which probes are assigned to a map by expanding the desired map field.
To view the active status of a map, Under Test Results, select MAP Status, then choose
the map to monitor results.
The desired map will be displayed and the results of the tests that are executed
between probes or inside the mesh.
To check details about the metrics measured on a particular path, click on the line that
connects those two points. A pop-up window will appear, showing the test details.

Configure Hawkeye
If the Hawkeye user, wants to check a different map, can do that by selecting it from the
drop down list located on the bottom of the page.
Note: For system administrator users all maps are available. For group
administrator users only the maps assigned to their group will be available.
Note: A map can be configured only by users with administrator privileges.
Floorplan Management
The Floorplan Management feature in Hawkeye allws you to configure floor plans and loc-
ate XRPi Wi-Fi probes and access points (APs). This allows the you to view the status

Configure Hawkeye
and information of the APs. You can locate multiple XRPi probes and APs on the same
floorplan. This feature support the following formats .png, .jpeg and .bmp.
To view the Floorplan Management feature navigate to Probe Management

> Floorplans Management.
To build a floorplan for WiFi monitoring you can select a floorplan to use for the WiFI
floorplan.
Once the floorplan has been pulled in you can add XRPi wifi probes and APs to the map .
First each probe/AP is added to available list, then once selected in the add list the
probe/AP can be moved on the floorplan to the correct location. Once a name has been
provided for the wifi floorplan, the floorplan can be saved into the MySQL database.
In Administration > Preferences there is a parameter "minimum signal strength". This is

used to define the minimum signal strength of an AP that is considered good. All AP
status are green or red based
on the "minimum signal strength" threshold.

Configure Hawkeye
The WiFi floorplan can be viewed in the “WiFi Dashboard” to see status of WiFi net-
works.. In order to populate the floorplan in the WiFi dashboard, the WiFi Inspect test
will need to be run (scheduled) on the XRPi WiFi probes placed on the WiFi floorplan.
Refer to “WiFi dashboard” for more details here. See below for adding XRPi probes and
APs to create the floorplan.

Configure Hawkeye

Configure Hawkeye
Hawkeye preferences
Hawkeye application is configured through Preferences screen
Depending on user level some different configuration options can be accessed
As system administrator (sysadmin user):

Configure Hawkeye

Configure Hawkeye
As user
Changing settings
1) Change desired settings in one screen (panel)
2) save – a confirmation setting has been changed will be displayed
Most of the parameters changing GUI aspects require a logout / login to be taken into
account.

Configure Hawkeye
Section “General” for users

The parameters located in section “GUI Settings” of the configuration file are explained,
below.
Feature/Setting Default Value Comments
Display Interval Optim- 0 Will allow schedule enforcing (see sec-

iser tion on enforcing schedule in this
guide TestExecution.htm) => Disable
Interval Optimizer
Show Server/Client 0 Displays time on server to compare to

Time client on top right. Note all times dis-
played in GUI are translated into
CLIENT time.
Default Calendar Range LastDay This section allows:

LastDay
LastHour
LastWeek
It defines the default time scale for the
system when user logs in.
Recommendation is LastDay or Last
Hour for better performance
Refresh List Timer Value 120000 Refresh table timer (in milliseconds).
This will allow refreshing any table
with auto refresh option on every
defined interval. It is recommended to
keep it above 10 seconds for optim-
ized system performance.
Use Droplist Search 1 or 0 In the drop lists there is an automatic

search available (in filters). Set it to 0
to disable this and get standard drop
lists.

Configure Hawkeye
Dashboard Autorefresh 1 or 0 Enable/disable the auto refresh for

main dashboard
Dashboard Autorefresh 180000 Refresh interval for main dashboard

Interval (milliseconds). Setting it to lower than
30 seconds can result into big impact
on system performance.

lists.
Dashboard Real Test all OPTIONS: all, origin, destination

Display This setting allows the global dash-
board to group the real test displays
per:
all: each client/server is one line
origin: each client is one line
destination : each server is one line
It is recommended to use this setting
if there are many tests executed
against several destinations
Maximum lines dis- 20 Main Dashboard displays a maximum

played in Dashboard number of lines that will be displayed
per pages. If there are more lines to
display than user specific defined in
this parameter, there will be several
pages available to browse through res-
ults in GUI.

Configure Hawkeye
Refresh Execution List 20000 Refresh Execution table timer (in ms).
Timer This will allow refreshing the execution
table with auto refresh option on every
The refresh window is specific for test
execution windows and overwrites the
Refresh List Timer Value for test exe-
cution related lists (see TestEx-
ecution.htm)
Section “Main” for admins

The parameters located in section “GUI Settings” of the configuration file are explained,
below.
Result Access Control 0 Defines how access to results are con-

Type trolled.
see GroupUserManagement.htm for
full details.
Value 0: the access control is based
on test execution (who executed the
test )
Value 1: the access control is based
on the probe (if all probes involved in
test are available for the user group,
the result will be available to the
user).

Configure Hawkeye
Allow Frequency Unit 0 Allow to change the unit for test exe-
Configuration cution interval set. This will allow to
use tests in schedules less than 1
minute. The default value is 0, set it
to 1 so scheduling interval unit can be
changed.
Display Interval Optim- 0 Will allow schedule enforcing (see sec-

iser tion on enforcing schedule in this
guide TestExecution.htm) => Disable
Interval Optimizer
Add Port Numbers to 0 setting this to 1 will allow all results

Test Results for Node to Node to be enriched with
the port used for the test pairs.
Display Test Con- 1 Displays test controller status into

troller Status administration table.
Map Report 1 Setting to 0 will disable Map display.

This can be useful if users wont have
access to public internet and therefore
cant have access to Google map to
display the maps
Maximum report gen- 500 Maximum time used to create report –

eration Time can be changed to allow more time in
case of extremely time consuming
report creations.
Number of days for 365 In Days Default time for keeping

database retention records in database.
Number of days for 180 Maximum time (days) for keeping

database retention for detailed records on test results (indi-
detailed metrics vidual results graphs)
Number of days for 20 Number of days of keeping admin

database retention of details (trail, execution logs, etc.) in
admin elements the database.

Configure Hawkeye
Enforce Complex Pass- 0 Enforces users to use of mix of letters,

word numbers for password
Max Concurrent Tests 50 Is limitation in GUI of the number of

in GUI concurrent tests (TCP) or voice calls
(RTP). This is pure GUI. Allowing more
than pair license will result on test
impossible to execute and queuing
forever.
Probe upgrade server default only take into account of probe

IP upgrade is NOT allowed on line. If
Probe upgrade IP is allowed online
(default), the upgrade package will be
downloaded from Ixia servers (recom-
mended). If default is selected, the
server will use its public IP (will not
work if server is behind firewall !!)
Probe Upgrade - Allow 1 Probe Online upgrade will be allowed:

on Line if probes have access to public inter-
net, they will connect to ixia server
for upgrade.
Registration Server localhost IP or hostname of the Registration

Server. Registration Server is a com-
ponent that acts as a mediator
between console and endpoints when
firewalls exist between them. This
should be left to localhost.
Allow Auto Regis- 1 Allow/Block endpoints to register to

tration of Endpoints the console automatically . This can
be used for stopping more endpoints
to register on the Hawkeyse server.
Allow Full Range 1 Allows to use Full Range time lookup

option for database lookup

Configure Hawkeye
Display individual res- Relative Graph time relative or absolute in indi-

ult graph time relative vidual test results. This is for indi-
or absolute vidual test result graph of detailed
metrics. The timing can be absolute
(exact date) or relative (start at 0s).
System Authen- Mode for Authentification - local only

tification Mode or LDAP. See Active Directory Integ-
ration
LDAP server address See Active Directory Integration
LDAP Domain See Active Directory Integration
Automatic Storage of 3600,10800,86400 Defines the aggregation levels for

Aggregation levels data that are available in database
and can be used automatically for res-
ults presentation. Advanced setting.
Aggregation for report 0 Set to 0 for no aggregation. If superior

use to 0, will define the level of aggreg-
ation data enforcement. The greater,
the less aggregation will be used
Section “GUI” for Administrator

Feature/Setting Value Comments

CLIENT time.

Configure Hawkeye
Default Calendar Range LastDay This section allows:

LastDay
LastHour
LastWeek
It defines the default time scale for the
system when user logs in.
Recommendation is LastDay or Last
Hour for better performance
Refresh List Timer Value 120000 Refresh table timer (in milliseconds).
This will allow refreshing any table
with auto refresh option on every
Max records per Page 50,000 Used for reporting long lists and limit
the size of the reports (avoid very long
report creation)
Allow URL 1 or 0 Set it to 1 to allow probe to have url

instead of IP
Max Concurrent Tests in 50 Is limitation in GUI of the number of

GUI concurrent tests (TCP) or voice calls
(RTP). This is pure GUI. Allowing more
than pair license will result on test
impossible to execute and queuing
forever.

lists.
Dashboard Autorefresh 1 or 0 Enable/disable the auto refresh for

main dashboard

Configure Hawkeye
Dashboard Autorefresh 180000 Refresh interval for main dashboard

Interval (milliseconds). Setting it to lower than
30 seconds can result into big impact
on system performance.
Dashboard Real Test all OPTIONS: all, origin, destination

Display This setting allows the global dash-
board to group the real test displays
per:
all: each client/server is one line
origin: each client is one line
destination : each server is one line
Maximum lines dis- 20 Maximum of entries that will be dis-

played in Dashboard played in Dashboard - restricted to
allow quick display. The results can be
available clicking on the link in dash-
board.
Refresh Execution List 20000 Refresh Execution table timer (in ms).
Timer This will allow refreshing the execution
table with auto refresh option on every
The refresh window is specific for test
execution windows and overwrites the
Refresh List Timer Value for test exe-
cution related lists (see TestEx-
ecution.htm)
Map Update Frequency 300 Map update frequency - do not set it

in seconds with too low value (less than 30
seconds)

Configure Hawkeye
Max Idle Time 3600 Maximum session time (maximum

time a user session is kept opened
before being automatically disabled).
Unit is second.
Allow Management from 0 Displays test controlers status. Only

Probe in Probe Man- required if multiple controllers are
agement used.
Display Threshold set- 0 Set to 1 to display thresholds on trend

tings on Trend Graphs graphs

CLIENT time.
Allow Management from 0 Configures availability of remote

Probe in Probe Man- access button on probes:
agement 0 - No buttons at all
1 – allow restart to all users
2 – allow all (restart and reboot) for all
users
3 – allow restart only for admin
4 - 2 – allow all (restart and reboot)
for admin
Threshold for WiFi sig- -50 Signal levels below this threshold will
nal level in WiFi Dash- be displayed as weak levels and
board levels above this threshold will be dis-
played as good levels.
Section “Alarms” for Administrator

Alarm Settings

Configure Hawkeye
SnmpTrapServerIP x.y.z.t IP address of the SNMP trap server.

Default 192.168.174.130
UseEmailAlarm 1 or 0 Enable/disable the alarms received by

email.
UseSNMPAlarm 1 or 0 Enable/disable the alarms received

using SNMP.
ConditionalTimeAlarms 1 or 0 Enable/disable the conditional time

alarms
StartAlarmTime 06:00 Value for start time of conditional time

alarms
EndAlarmTime 23:00 Value for end of conditional time alarms
Section “Maps” for Administrator

The parameters located in section “MAPS Settings” of the configuration file are
explained, below.
MAPS Settings
UseGoogleMap 1 or 0 Enable/disable the usage of Google Maps
GoogleMapKey See below details of how to obtain a

Google Map Key
MapRetentionMinute 240 Number of minutes for the map to look

database results. Any results older than
this value will not be considered (might
result in empty map)

Configure Hawkeye
Obtain Google Map Key

In order to use the Google map, a key must be generated.
On the following link there are details about the process of obtaining such key:
https://developers.google.com/maps/documentation/javascript/tutorial?hl=fr#api_
key
A valid Gmail account is required in order to generate the key.
Section “Email” for Administrator

SMTP_Server the address of the SMTP server
SMTPDebug
SMTPAuth true or true if authentication is used, false if no

false authentication is configured for the
SMTP account
SMTPSecure SSL or TLS Configure SSL if Secure Sockets Layer

cryptographic protocol is used, TLS if
Transport Layer Security protocol is con-
figured for the SMTP account or none if
no security is used.
Port 25 or 465 Configure port 465 for SSL, 587 port for
or 587 TLS or 25 default SMTP port for no secur-
ity.
Username username of the SMTP account
Password password for the SMTP account
EmailAddress the SMTP e-mail address

Configure Hawkeye
FullName sender name
MaxEmailAttempts 3 how many times should the application

try to send the message
Example of settings for gmail account:
Section “Traffic Port Management” for Administrator


Configure Hawkeye
Destination Port Conf 1 or 0 0: will be set to AUTO

Option 1: will start on range (increment 1 on per
destination probe basis)
2: will start on range (increment 1
regardless of probe used)
First Destination Port 10200 Destination port for Hawkeye test types
start of range. Default 10116.
Source Port Conf Option 1 or 0 0: will be set to AUTO

1: will start on range (increment 1 on per
destination probe basis)
2: will start on range (increment 1
regardless of probe used)
First Source Port 10216 Source port for Hawkeye test types start
of range. Default 10216.
Use Skype4B Special Range 0 Use special ports range for Skype4B
traffic tests.
Skype4B - First Audio 10301 Skype4B - First Audio Source Port

Source Port
Skype4B - First Audio 10201 Skype4B - First Audio Destination Port

Destination Port
Skype4B - First Video 10351 Skype4B - First Video Source Port

Source Port
Skype4B - First Video 10251 Skype4B - First Video Destination Port

Destination Port
Section “Test Controller” for Administrator

Feature/Setting Default Comments
Value

Configure Hawkeye
Real Test Max Duration 180 Maximum duration of a real test.
Probe Health Check 1 Enable/disable the probe health check

engine.
Test E2 Available 1 Test both Endpoint 1 and endpoint 2 avail-

ability from Test controller for the test. In
network configuration where Endpoint 2 is
not available from test controller it might
be useful to disable this test.
Probe Management iden- 1 By default the probe id is used to identify

tification a probe. For some systems where a phys-
ical probe has several interfaces. For the
resource management to consider same
physical probe this option needs to be
activated (1) and probes management
address set to the same interface (same IP
or url).
Note that when configured on the probe (ie
not ‘’ or ‘default’, Serial number always
takes precedence over the method defined
here.
Endpoint Autorestart 1 Enable/disable the auto restart feature for

Hawkeye endpoint. If enabled the end-
point will auto restart at Autore-
startIntervalMinutes
Endpoint Autorestart Inter- 360 Interval for the endpoint auto restarts
val (minutes) time.
Autorestart Max Duration 30 Maximum duration of autorestart process.
Real Service Port 22 Port required by the test agent to connect

to the probes to run real services test
types

Configure Hawkeye
Alarm on Probe Status 0 Enable alarms (email or SNMP) when

Change probe becomes not available. Send alarm
when status changes (available/not avail-
able)
Alarm on Probe Health Fail 0 Send an alarm when probe is not avail-
able (every check)
Probe Default Login root Probe default Login - overridden by probe

specific configuration
Probe Default Password Ixia!123 Probe default Password - overridden by

probe specific configuration
Section “Advanced Options” for Administrator

Report Header images/re- Customize the report header image by

Image portheader.gif changing the reference to the gif image.
The gif image needs to be placed into the
installation folder. (see admin manual for
report folder, typically c:/ixi-
a/Hawkeye/main/webserver/images
Allow Path Dis- 1 or 0 When enabled (1), Path Discovery will

covery to per- perform Autonomous System path
form lookup. This depends upon the ‘whois’
Autonomous protocol not being blocked by the user’s
System path network. It will query an IP in the path to
lookup be matched to a name by global registry
servers.
Use Mesh 1 0 if the mesh testing is disabled

1 if the mesh testing is enabled

Configure Hawkeye
Maximum time 200 Advanced Setting : safety timer - max-

processing imum time (seconds) system waits
Node to node or before trashing node to node or mesh
mesh test test - do not set below 120 seconds
Maximum time 120 Advanced Setting : safety timer - max-

processing real imum time (seconds) system waits
service test before canceling Hawkeye test - do not
set below 60 seconds
Use probe con- 0 Advanced Setting : allow optional use of

figuration Script probe configuration script before and
for node to after tests
node real ser-
vices
Maximum pairs 500 Advanced Setting : maximum pairs in

per test con- each controller instance - this setting is
troller instance only taken into account if controllers are
configured with ability to control same
probe at same time with different times
Allow probes to 0 Advanced Setting : Allow probes to run

run Node- NodetoNode and real services at same
toNode and real time. Can result into incaccurate test res-
services at ults as tests can interfere with each oth-
same time ers.
SOAP web ser- 0 Advanced Setting : Enable server to be

vice API server used as SOAP web services
activation 0- not activated
1- SOAP server function Enabled (no
restriction)
2- SOAP server function Enabled - IP
address restricted
SOAP client IP 0.0.0.0 Advanced Setting : IP configuration

(used when SOAP server IP address
restriction is configured)

Configure Hawkeye
Real Services: 5 Advanced Setting : refresh time for auto-

default interval matic endpoints - default is 5 seconds
time for auto-
matic endpoints
Real Services: 0 Advanced Setting : retry time for auto-

default retry matic endpoints - default is 0 seconds
time for auto- (immediate retry)
matic endpoints
Disable Real 0 Stop Responses to Automatic Endpoints -

Services and do not run any tests nor register new
Autore- information or endpoints
gistration for
Automatic End-
points
Test Controller: 4 Advanced Setting : Polling interval time

Polling Interval in seconds for Test Controller - default is
4 seconds
Maximum num- 100 Maximum number of graphs that will be

ber of graphs in created for a saved or scheduled report -
a saved or setting this to higher than 2000 can
scheduled impact system performance and delay or
Report cause failure in report generation.
Section “Installation Paths” for Administrator

Configure Hawkeye
Section “logs” for Administrator

Database Debug 1 or 0 Enable/disable debug on database.
Page Setup Debug 1 or 0 Enable/disable debug on page setup.
Page Action Debug 1 or 0 Enable/disable debug on page action.
Debug Javascript 1 or 0 Enable/disable debug on java script.
Log Retention Minutes 240 How long the application logs will be
retained.
The application logs are located in C:\Ixi-
a\HawkeyePro\log_server
Test Engine Log Reten- 1440 Log retention for underlying test engine -
tion Minutes need to be more than 240 minutes
The engine logs are located in
C:\Ixia\HawkeyePro\log_chariot
Section “Test Engine” for Administrator

This section allows configuration of the C:/home/ixi-
a/Hawkeye/conf/configTestEngine.txt file on the server.
Parameter Name Default Description

Value
lowsendjitter 0 Enables low send jitter algorithm on

probes. It allows probes to generate
UDP or RTP traffic in an optimized way
to avoid any bursty traffic. This para-
meter should be set to 1 to enable the
feature. It is very useful in case of test-
ing Class of Services or traffic shapers
that can be sensitive to bursts.

Configure Hawkeye
maxWait 60 Maximum time waiting for Hawkeye

test engine to finish the test (on top of
test duration + Statistics receive
timeout)
maxInit 60 Maximum time waiting for Hawkeye

test engine to initiate the connection.
autoNAT 0 Needs to be set to 1 in order to allow

probes to be managed behind NAT
(their address are configured as Public
IP from console). Setting this para-
meter to 1 will allow console to manage
the probes behind NAT. Port forwarding
still needs to be put in place on the
probe NATing to allow management
(10115) and traffic (configuration in
Test controller section).
ForceE2managementInBand 0 Setting this parameter to 1 will force

the management traffic between E1 and
E2 to be in band. Console initiates con-
nection on management interface but
management between endpoints is in
band. This option is required for specific
installation
ConsoleBehindFirewall 1 This needs to be set to 0 in case of

using multiple threads in parallel. Con-
straint is console needs to be able to be
directly connected to probes (ie not
behind a firewall/NAT).
ALLOW_PAIR_REINIT 1 Activate probe pair setup retry cap-

ability. Useful in unstable network for
management. Setting up this to 1 might
create side effects on probes if tests are
executed in volumes.

Configure Hawkeye
PAIR_REINIT_MAX 3 Numbers of tries before giving up.

WARNING Setting this parameter to 0
will cause test engine to fail all exe-
cution.
PAIR_REINIT_RETRY_INTERVAL 100 Interval for retrying. WARNING Setting

this parameter to 0 will cause test
engine to fail all execution.
ALLOW_PAIR_REINIT_RUN 0 Activate traffic retry capability during

test. Useful in unstable network for
traffic in case of TCP. Setting up this to
1 might create side effects on probes if
tests are executed in volumes.
PAIR_REINIT_MAX_RUN 3 Numbers of tries before giving up.

WARNING Setting this parameter to 0
will cause test engine to fail all exe-
cution.
PAIR_REINIT_RETRY_ 100 Interval for retrying. WARNING Setting

INTERVAL_RUN this parameter to 0 will cause test
engine to fail all execution.
Statistics receive timeout 30 The timeout controls how long to wait

(seconds) for statistics until giving up and con-
sidering the test traffic connection
failed. Error (CHR0529) is reported for
the test traffic connections that do not
report any statistics for the configured
timeout duration.

Explore results
Explore results
This is the first page that it is displayed after the user is logged in.
In the main dashboard the user can find the following:
l summary of probe status

l summary of tests passed/failed
l summary of probes globally located
l List of ten probes with most issues
l list of 10 test types with most issues

Explore results
Going through dashboard test results

Mesh test results
l See paths . This option displays a table with the all the paths for the meshes

Explore results
l See results . This redirects the user to the Test Results list, with the Module:
Mesh
l

Explore results

Explore results
l See on map .will display the selected mesh on map.

Explore results

Explore results
Node to Node test results
l See metric report . This redirects you to the metric pie report page
Module:N2N.

Explore results
l See trend report . This redirects you to the reporting engine page Module:N2N.

Explore results
l See results . This redirects you to the test results list with Module: N2N.

Explore results
l See test types This option displays a table showing the test type:
Real Services testing
l See metric report . This redirects you to the metric pie report page Mod-
ule:RealService.

Explore results
l See trend report . This option redirects you to the reporting engine page Mod-
ule:Real Service:
l See results . This action redirects you to the test results list with Real Service.
l See test types .This displays a table showing the test type.
If the user wants to look at the previous dashboard, before selecting one of the options
for the tables simply, select the Main Dashboard option located under the Test Results
tab located on the main bar.
WiFi Dashboard
The Wifi dashboard displays results of the Real Services Wifi Inspect test performed on
XRPi wifi probes. The WiFi Dashboard displays the results when a XRPi WiFi endpoint or
a floorplan is selected.
Select a XRPi WiFi endpoint to display four panes with information on the selected end-
point. The list of all Access Points(AP) in range and metrics of each selected AP in the
list is displayed. WiFi charts for 2.4 Ghz and another one for 5 Ghz shows the spread of
available APs over the channel IDs, and provides an indication of possible interference
amongst APs using the same channel IDs.

Explore results
The WiFi Dashboard enables you to select a WiFi floorplan. When the real services test
wifi Inspect is exeecuted or scheduled on the XRPi WiFi in the floorplan, the floorplan is
updated with the results. The WiFi Dashboard contains instantaneous data and not his-
torical data. If the wifi router that is connected to the XRPi WiFi endpoint makes a con-
figuration change (such as changing channel number) this is not automatically picked
up by the XRPi Wifi endpoint and it can cause wlan0 to fail.

Explore results
The color of an AP indicates its status. In Preferences you can specify the Threshold
for WiFi signal level in WiFi Dashboard so that if an AP signal strength is above
this level (RSSI level in dbm) the AP is displayed in green and if the signal strength is
below this threshold it is displayed in red. If an AP displayed on the floorplan is not
detected by the XRPi WiFi endpoint it is displayed in black. The floormap is updated with
the results of the last WiFi Inspect test.

Explore results

Explore results
Metric Status
This screen selects the results per metrics and provides Average/Maximum/Minimum
values
The results are also notified with:
- standard deviation
- Total measurements in samples
- Threshold (can be range of threshold).
The filters used at the bottom will decide what types of data is filtered in result sample
If you pick a specific metric, and click on "show trend report" this will redirect to Metric
Graph screen showing the results.

Explore results
Metric Graph
This specific screen allows to build and customize reports

Explore results
the different options involve:
- Time interval: will decide time interval selected for browsing the data.
l - Graph Type:
l - trend graph will aggregate all tests of traffic and show results in specific metric,
test type and pair.
l - trend graph per individual path will show the same result with specific line for spe-
cific pair (node to, node from).
l - Repartition graph: will display how the different measurements are showing up
with respect to the number of measurements that have been made.
l - Site repartition graph: is showing the repartition but spreading the data based on
site being tested (node from).

Explore results
- Time scale granularity:
l This decides what scale the graph is aggregating the data with. For example, if
selected granularity is 1 hour, one spot point per hour will be displayed on graph
with average value over the hour. It is possible to use range option set to display
to display the average but also min and max measures during each selected inter-
vals.
- display line:
l Can be line (default) or area for area charts display
- Threshold:
l User can select to show threshold in graph. Note: if threshold is out of range in the
graph it will not show. Auto adapted scale in the graph is NOT taking threshold into
account.
- Range:

Explore results
l The range display can be set to "no display": only average value per interval is dis-
played, or "display': average value plus min/max range is displayed.
Path Discovery
Summary
Hawkeye Path discovery is a methodology to provide visibility into network topology
from a location with Hawkeye endpoint to any remote location.
The discovery relies on standard protocols packets being sent to the network to find out
about nodes being traversed. There is therefore no need for specific software or hard-
ware being deployed on the path nor at remote location.
Path discovery allows to discover application specific paths by way of configuring the
protocol and ports used by an application to discover the route taken by packets to
reach destination.
Path discovery leverages Hawkeye test execution framework to allow historical data col-
lection and perform analysis in real time or with retrospective views.
Path Discovery Methodology

The path discovery relies on 2 steps for analysis on the path:
1. path discovery: packets are sent using TCP, UDP or ICMP protocols with different
TTL tags and responses from network elements are captured to indicate inform-
ation about traversed nodes. This sequence is repeated several times

Explore results
(configurable) so that potential different paths are discovered and displayed in a

graph.
2. Nodes network performance analysis: 100 ICMP packets are sent to each identified
nodes to find out about basic IP performance metrics using ICMP protocol and
report on packet loss rate and round trip times (RTT) to the traversed nodes.
Setting up the Path Discovery from an endpoint

Path discovery is available from Hardware endpoints and xr2000 VM as a real service.
To set it up, go to test execution-real service screen and select your endpoint and Path
discovery test type.
The following options are available:
Destination server: is IP or URL of the remote server that needs to be reached to dis-
cover path. It can be hosted in private network, private or public cloud, public internet
etc.
Traceroute counts: number of path discovery attempts executed to find out about path.
This number must be into 1-20 range.
Maximum number of hops: the traceroute are attempted until destination is reached or
for a maximum number of hops between source and destination.
Protocol: protocol used for path discovery. The default is TCP which is recommended as
it is the most likely to provide accurate results. Other options available are UDP and
ICMP. UDP would function similar to TCP but using a different destination port and
without SSL, while ICMP is going to issue pings with TTL. It is important to know that
some nodes on the path may react differently to these protocols: some routers/switches
are blocked for ICMP responses for example and allow TCP or UDP, so the discovery may
provide more information with one protocol or the other.

Explore results
Destination port: this is used if protocol is TCP or UDP. The discovery messages will be
sent with destination port set to this value and using a random source port. This can
again be important when determining routing/COS management details on the path for
specific protocol/port. Using the protocol and destination port a specific application
would use allows finding about how the associated packets would be handled by the net-
work.
Timeout (sec): this is the maximum time the path discovery will be allowed to run – in
case the overall process exceeds this maximum allowed time the test will error out and
free the test execution queue.
Interpreting test execution results

Path discovery display is highly visual allowing quick understanding of the traversed
nodes for an endpoint.
The picture below shows an output of the function:
The different nodes detected in the path discovery are shown with squares.
When there were messages sent and no responses from the network, an unknown
square is shown.
This typically happens when packets are dropped on their way back or forth, or when the
node that is on the path is configured so that it does not advertise the drop to source.
The links between the nodes are shown with different thickness levels to illustrate the
distribution between paths.

Explore results
As shown in the example below, it is also possible to investigate the packet drops or
Round Trip Time (RTT) detected in the path by configuring a threshold.
Note that the RTT and packet loss are displayed based on ICMP messages being sent to
the nodes. The metric is displayed only if at least one ICMP answer is received. The
assumption if 100% packets are dropped is that the node is blocked for ICMP responses
and therefore no data is displayed.
The ICMP packets are 100 bytes long and 100 of them are sent with 20ms interval for col-
lecting the information. The base ICMP sequence is the starting ICMP sequence number
that gets incremented with each packet.
During the path discovery, the information about Autonomous System (AS) to which the
node belongs is collected. This information is belonging to an organization having
routers on the public internet. It will identify service providers or autonomous entities
being traversed to reach destination.
Routes can be displayed with only showing Autonomous System (AS).
When the Hawkeye server has access to internet it can collect information to what AS
code is registered.
Next figure illustrates a path discovery shown with AS grouping.

Explore results
The next figure illustrates a path discovery showing the changes in QOS. When the Path
discovery test was configured the required QOS (DSCP) value was selected. As the pack-
ets pass through each network node the specific node can change the QOS setting for
each packet. The figure below shows when the QOS changes box is selected that the
user has the ability to select a node to view its details which will include the QOS value
assigned to all packets being forwarded to the next network node.
By clicking on any nodes on the graph, full information about the results collected will
be displayed:
l Hop defines the path # it was detected at

l IP if the IP detected or unknown if node does not respond to traceroute packet.
l Network is detected through AS.

Explore results
l If available the full registered address for AS will be displayed.

l Frequency shows how many times this was detected using this node.
l Loss and RTT (round trip time) are gathered through ICMP messages.
l DSCP is not available for the last node.
l The DSCP information for a node will not be displayed if the TCP/ICMP messages
are not responded to by the node.
The traceroute button will display in a table all the information collected for all steps in
the path – see example below:
This will show the User the different steps and what nodes were involved. The ICMP
extensions contain feedback on MPLS network labelling and protocol information.
Path Discovery Failures

If a Path Discovery test has an error message indicating a timeout, follow the following
steps in order:

Explore results
1. Reduce tracecount in configuration of Path Discovery test. This will reduce amount
of scans and may potentially reduce number of available routes identified to des-
tination.
2. Reduce maximum number of hops in configuration of Path Discovery test.
3. Increase test timeout in configuration of Path Discovery test. If this is increased
above 3 minutes, refer to Parameters effecting Performance on page 80 for inform-
ation on how to increase overall timeouts for Real Service tests.
Some nodes will respond to the first ICMP message then not respond to
any other ICMP messages from the same source for a certain time
period, this does not reflect a problem.
Test Results screens
The results page contains all the details (such as, date and time of execution, which
user executed the test, test type, from/to probe IP/name, test duration, status, reason)
of all the tests that were executed.
The test results can be found by selecting the Test results list, located under the Test
Results option on the main options bar.

Explore results

Explore results
By default, the user will be able to see the results of the tests that were ran on the last
day. If the user wants to see the results of all the tests that were ran earlier, they can
use the full range as the value for the time interval parameter under time selection tab
on the left side. User can select one of the options (full range, last hour, last day, last
week, today, range) for the time interval parameter based on the requirement.
Test results of other users can be viewed depending on the admin level privileges of the
user.
The table below explains the test results that a user can see depending on the admin
level of the user and option selected for result access rights:
Admin Level Results Viewed Result viewed

Test execution based Probe group access
based
System Administrator View the test results of the View the test results of
tests executed by all users. the tests executed by all
users.
Group Administrator View the test results of the View the results of the
tests executed by the users test executed with one
belonging to that particular (real service) or both
group. probes (n2n) belonging
to the user group.
Group Viewer View the test results of the View the results of the
tests executed by the users test executed with one
belonging to that particular (real service) or both
group probes (n2n) belonging
to the user group.

Explore results
User View the test results of the View the results of the
tests executed the by the user test executed with one
itself. (real service) or both
probes (n2n) belonging
to the user group.
Full System Viewer View the test results of the View the test results of
tests executed by all the the tests executed by all
users. This right allows only the users. This right
viewing the results. allows only viewing the
results.
Filters
Hawkeye allows the user to filter the test results, as shown below:
User can set the filters according to their requirements.
For example: If the user wants to see the test results of the tests that were run between
the Calabasas node and the Austin node, then the user can select “Calabasas” as the
value for the NODE FROM field and “Austin” value for the NODE TO field, as shown
above.
This will show the filtered results.
If the user wants to see only the results that passed, then the user can select Passed
value from the status TDR field.
Click on the RESET FILTERS button to clear the filters. After resetting, all the values of
the fields will be set to “all” and all the test results will be displayed.
Click on the refresh table button, at the bottom of the page, to update the test results of
the tests that were in running stage.

Explore results
Note: The test results of the tests that were in running stage will be updated only
if the tests are complete.
Detailed summary of a test
To see the details of a test, click on the “+” icon, as shown below:

Explore results
By selecting the “Test results metrics” under the “Test results” option on the main
option bar, the user has access to detailed metrics report, as shown in the picture
below:
By selecting the “Test results metrics average” under the “Test results” option on the
main option bar, the user has access to average metrics report, as shown in the picture
below:

Explore results
Remove a test result entry
Users can delete a test result by clicking on the delete icon located next to the Run
ID column.

Explore results
Map Status
The Map Status feature in Hawkeye allows you to see the status of endpoints on a
global map. This allows you to see in real time the status of the endpoints. The map is
updated based on test results. If endpoints are running tests successfully, the line
between endpoints is displayed in green, but if tests start experiencing errors, the line
between the probes are displayed in red.

Explore results

Explore results
Hawkeye Reports
Report types description
The report types available are:
Options can be selected by chosing: options button

Explore results
Report Name Description options
Metrics summary Based on selected filters, Selected metrics

displays the global results
and per metric pass/fail stat-
isitics
Metrics trend Based on selected filters, Selected metrics,

displays the global results Graph type,
and per metric pass/fail stat- Graph granularity,
isitics and adds a trend
Display line type,
report per selected metric
Display threshold,
Display range
Last 3 period dashboard From current date, Last 3 Selected metrics

period based on time selec-
tion (last hour, last day,
etc.) dashboard, on filtered
criteria. Contains Pie chart
on PASS/FAIL/ERROR and
statistics on metrics
Top N dashboard Ranking of worst 10 results Selected metrics, N value

per metric, based on selec-
ted criteria
Per path metric matrix displays a metrics per path Selected metrics
with average/min and max,
per test type and metric. It
is particularly convenient
for Mesh tests results invest-
igation

Explore results
Per path Status matrix Results are presented into Selected metrics
color codes with matrix for
meshes. This is a simpler
more visual way to display
the resutlts than per path
metric matrix report
Paths Error/Fail Summary This report displays the Selected metrics (not
number of errors reported taken into account)
and numbers of failures
reported with % of total
tests.
Paths Error/Fail Summary This report displays the Selected metrics

per KPI number of faulures reported
reported with % of total
tests per KPI and sort them
based on maximum rates
failing
Per path summary Does a KPI summary report Selected metrics

per path in selection.
Per path trend Does a KPI trend report per Selected metrics,
path in selection. Graph type,
Graph granularity,
Display line type,
Display threshold,
Display range
Site report summary per site KPI report Selected metrics
Site report trend per site trend report Selected metrics,

Graph type,
Graph granularity,
Display line type,
Display threshold,
Display range

Explore results
Site report detailed Per site detailed report with Selected metrics,
per path per site report Graph type,
Graph granularity,
Display line type,
Display threshold,
Display range
Report creation options
Select Options into report- depending on the report selected there will be a set of
options available.
Truncated Reports
Running reports over too large selections can create memory allocation issues - there-
fore there is auto limitation into the report size that can result into displaying truncating
report warning:

Explore results
Report takes too long to create

Reports created for large time periods and test data can take some time to process. You
can configure the system processing time for processing a report. This is configured in
Administration - Preferences.
If the Hawkeye server exceeds the max allowed time to create a report the following
error message will be generated.

Explore results
Create a report
To create a report, select the “Reporting” menu located on the menu bar.
The report will be created according to the filters defined:
l Time range in time selection
The available time intervals are:
- Last hour/day/week;
- Today;
- Full range;
- Range: when range is selected the date picker becomes active.
l Filter criteria in the bottom section;

Explore results
Once the report criteria has been defined, select view report option to view the report
and get access to the data into the result report.
Different export options are available:
- Export to html;
- Export to pdf;
- Export to csv;
Save a report
The reports can be viewed and saved on the server by selecting “Save/Schedule” but-
ton. Reports will be displayed on screen and saved on server disk. The user shall assign
a report name (into report name text box) and a report format (html, CSV or PDF). Refer
to report type list for availability of report format per report type.
The reports are saved in “Saved Reports” area under Reporting menu on the main
options bar.
Send a report by e-mail
Configure a report to be sent by mail
When saving a report on disk, the user has the option to send it by email by selecting
this option:
The report will be automatically sent by email after being created.

Explore results
Note: The email settings must have been configured correctly prior to this by
administrator.
Schedule a report
Reports can be scheduled by selecting the schedule button:
Report interval – Hours: defines the interval between reports creation. If leaving report
Interval to 0, then the report will be created only one time.
Start schedule: defines when the schedule will start;
l If left blank, the current date will be applied;

l If interval is set to 0 (one shot test), then this will define when to start the test (in
batch mode);
- to select the day and time, change time (24 hours selection) and click on the
selected date.
End schedule : defines when schedule will end:
l If left blank, the schedule will last forever.

l If Interval is set to 0 (one shot test), then this End schedule will not be taken into
account.
To select the day and time, change time (24 hours selection) and click on the selected
date.
By selecting scheduled reports list into the reporting menu, the user can see reports cur-
rently scheduled and pause, restart or delete these schedules.

Hawkeye Test types
Hawkeye Test types

The scope of this section is to present the different test types available within Hawkeye
application. It details the test methodology test types and configuration options, as well
as test result KPIs.
Test type general description

This section explains the following topics:
Node to Node below
Understanding Node to Node Metrics on page 206
What is Goodput ? on page 216
Testing throughput using TCP or UDP on page 217
Node to Node
Node to Node testing topology
The Node to Node (N2N) testing is based upon testing between 2 probes. The active
probes are deployed in the network at different key locations and controlled by the
Hawkeye test controller.
A typical testing topology is described in the following diagram:

Hawkeye Test types
Hawkeye is controlling tests through a central location. Probes are deployed in the dif-
ferent network locations, and run active traffic between themselves to generate traffic
flows.
See description of available tests below.
The probes involved can be:
l Software probe (on laptop or PC, Windows, Linux, smartphones);

l XRPi (1 ethernet and optional wifi interface)
l XR2000 probe (up tp 6 GE copper interfaces - 2 GE copper interfaces active by
default);
Node to Node testing allows full control of the tested path, as traffic is generated
between nodes. This allows generating predictive traffic to receiving side, generate bid-
irectional traffic, and setup several classes of services with full control of the traffic sent.
Hawkeye is delivered with a default test type base.

Hawkeye Test types
Understanding Node to Node Metrics
The Test Totals are divided into three major sections that correspond to the three basic
types of measurements taken in an Hawkeye test. Following are explanations of how
Hawkeye calculates throughput, transaction rate, and response time.
Throughput
Hawkeye measures the throughput associated with packet payload, ignor-

ing headers. This is referred to as Goodput in RFC 2647.
see goodput
The throughput is calculated for pairs with the following equation:
bytes received (by E2) / (Throughput_Units) /
Measured time
For pairs that are bidirectional (TCP based application type of traffic), throughput is
aggregated in 2 directions:
(Bytes_Sent + Bytes_Received_By_Endpoint_1) / (Throughput_Units) / Measured_Time

Hawkeye Test types
In all calculations, elapsed time is the elapsed time of the longest-running pair in the
test. The measured time is the sum, in seconds, of all the timing record durations
returned for the endpoint pair.
Here's how each of the script variables is defined:
- Bytes_Sent: the number of bytes sent by Endpoint 1 of a pair.
- Bytes_Received: the number of bytes received by the endpoint of a pair.
- Throughput_Units: the current throughput units value, in bytes per second. For
example, if the throughput units are KBps, 1024 is the Throughput_Units value. In this
example, the throughput units number is shown in the column heading as Mbps, which is
125,000 bytes per second (that is, 1,000,000 bits divided by 8 bits per byte). See Raw
Data Totals.
Transaction Rate
The calculations are shown in transactions per second. This rate is calculated as fol-
lows:
Transaction_Count / Measured_Time
Response Time

Hawkeye Test types
The response time is the inverse of the transaction rate. The calculations are shown in
seconds per transaction. This value is calculated as follows:
Measured_Time / Transaction_Count
Lost Data
The lost data is the difference between the number of bytes sent by Endpoint 1 and the
number of bytes Endpoint 2 actually received. Lost data is only calculated when a pair is
running a streaming script (for example, in a VoIP or video). Only payload data is
included in the calculations.
Max Loss burst
Maximum number of packets lossed in a row during test.
Jitter
Hawkeyehelps you determine the quality of a multimedia transmission or voice over IP

call using measurements of jitter. While RFC 1889 jitter (calculated for all RTP pairs)
shows mean statistical deviance of packet inter-arrival times over a period of time.
The jitter (delay variation) maximum reveals when the greatest variation in delay seen
for a timing record occurred during the test.

Hawkeye Test types
When a datagram is sent, the sender gives it a timestamp. When it is received, the
receiver adds another timestamp. These two timestamps are used to calculate the data-
gram's transit time. If the transit times for datagrams within the same test are different,
the test contains jitter. In a video application, it manifests itself as a flickering image,
while in a telephone call, its effect may be similar to the effect of packet loss; some
words may be missing or garbled.
The amount of jitter in a test depends on the degree of difference between the data-
grams' transit times. If the transit time for all datagrams is the same (no matter how
long it took for the datagrams to arrive), the test contains no jitter. If the transit times
differ slightly, the test contains some jitter. Jitter values in excess of 50 ms probably
indicate poor call quality.
Jitter statistics let you see a short-term measurement of network congestion and can
also show the effects of queuing within the network. The jitter value is reset for each tim-
ing record, so the jitter statistic for a specific timing record shows the jitter for that tim-
ing record only.
Almost all data transfers experience jitter, but it isn't necessarily a problem. Jitter
occurs in several patterns. If the delay time for each datagram steadily increases, jitter
values increase and the throughput decreases. But it is also possible for jitter to
increase while throughput remains constant. In this case, the delay variation fluctuates
widely, which could mean poor performance for delay-sensitive applications. Finally,
"bursty" jitter—occurring in bursts of datagrams—has the most significant effect on call
quality in voice over IP transmissions. If jitter occurs in bursts, it can lead to data loss
and a degradation of call clarity. Hawkeye measures this "bursty" quality; refer to Max
loss burst.
RFC 1889 Jitter

Hawkeye Test types
When calculated according to the specification for RTP, jitter (J) is defined as the mean
deviation (smoothed absolute value) of the difference (D) in datagram spacing at the
receiver compared to the sender for a pair of datagrams. As shown below, this is equi-
valent to the difference in the "relative transit time" for the two datagrams; the relative
transit time is the difference between a datagram's RTP timestamp and the receiver's
clock at the time of arrival, measured in the same units. If Si is the RTP timestamp from
datagram I, and Ri is the time of arrival in RTP timestamp units for Datagram I, then for
two datagrams (I and j), D may be expressed as follows:
D(i,j)=(Rj-Ri)-(Sj-Si)=(Rj-Sj)-(Ri-Si)
The inter-arrival jitter is the jitter calculated continuously as each datagram (I) is
received from the source. The jitter is calculated according to the formula defined in RFC
1889:
J=J+(¾D(I-1,I)¾-J)/16
Jitter is measured in timestamp units and is expressed as an unsigned integer.

Whenever the endpoint creates a timing record, the current value of J is sampled.
Delay
Endpoints can calculate delay statistics in a single direction for VoIP pairs and for pairs
using the RTP protocol. Delay is calculated for each timing record in a test. These meas-
urements are useful in testing time-sensitive applications because they can help to pin-
point sources of delay. One-way or network delay excludes sources of delay apart from
the "wire" itself, while end-to-end delay includes all sources of delay, such as the codec
used, jitter buffers, and fixed delays.
MOS
Treating each endpoint/probe pair as a separate voice over IP "call," Hawkeyegives an

Hawkeye Test types
indication of the relative quality of each call made during a test on your network. Ixia
uses a modified version of the ITU G.107 standard E-Model equation to calculate a Mean
Opinion Score (MOS) estimate for each endpoint pair.
The E-Model, developed by the European Telecommunications Standards Institute

(ETSI), has become ITU standard G.107. This algorithm is meant to evaluate the quality
of a transmission by factoring in the "mouth-to-ear" characteristics of a speech path. It
calculates an R-value, which correlates directly with the MOS estimate.
Hawkeye modifies the E-model slightly and uses the following factors to calculate the R-
value and the MOS estimate:
•One-Way (Network) Delay
Similar to the propagation delay; only the delay factors associated with the network
(the "wire") itself are included. Hawkeye measures this by synchronizing the endpoints'
timers and determining delay in a single direction. Refer to One-Way Delay for more
information.
•End-to-End Delay
Latency as measured by adding the following factors:

Hawkeye Test types
•Data Loss
Total number of datagrams lost. When a datagram is lost, you can lose an entire syl-
lable, and the more datagrams that are lost consecutively, the more the clarity suffers.
Hawkeye factors in lost data and also includes the amount of consecutive datagram loss
that was measured. Refer to The Lost Data Tab for more information. In addition, if you
have packet loss concealment (PLC) enabled for the G.711 codecs, a delay factor asso-
ciated with PLC buffering is added. Refer to Codec Types for information about PLC.
•Jitter Buffer Lost Datagrams
Number of datagrams lost due to jitter buffer overruns and underruns. Refer to Jitter
Buffers for more information.
A MOS of 5 is excellent; a MOS of 1 is unacceptably bad. The following table (taken from
ITU G.107) summarizes the relationship between the MOS and user satisfaction:
Mean Opinion Scores (MOS) table

Hawkeye Test types
Media Delivery Index (MDI) Calculation
The Media Delivery Index (MDI) is a proposed metric, defined in RFC 4445, that can be
used as a diagnostic tool or a quality indictor for monitoring the delivery of streaming
media on a network. It specifically focuses on the measurement of packet jitter and
packet loss in networks carrying streaming media, such as MPEG video, Voice over IP,
and other information that is sensitive to arrival time and media loss. Hawkeye collects
and reports MDI statistics for all Video Pairs.
The two major factors impacting the quality of a video stream transmitted over an IP net-
work are packet loss and packet jitter. Packet loss can be caused by many factors,
including data corruption, insufficient bandwidth, and out-of-order packet delivery. Any
packet loss will adversely affect the quality of the delivered video. Packet jitter causes
buffer overflows and underflows, either of which will cause unacceptable time distortions
in the video streams.
Packet Jitter
Packet jitter is a measure of the variation in arrival rates between individual packets in
a media stream. Streaming media requires a consistent and predictable time delay
between successive packets as they are received at a destination node. Variations in
this interpacket delay causes packet jitter. If packets are delayed by the network, some
packets will arrive in bursts with diminished interpacket delays while other packets will
arrive with longer interpacket delays. Therefore, the node at the receiving end (the
decoder) must buffer the video data to ensure that it can be displayed at its nominal
rate. The size of the buffer determines the maximum amount of packet jitter than can be
accommodated without experiencing buffer underrun or overrun.

Hawkeye Test types
Delay Factor
The MDI consists of two components: the Delay Factor (DF) and the Media Loss Rate
(MLR).
The Delay Factor (DF) indicates the maximum difference between the arrival of stream-
ing data and the drain of that data, as measured at the end of each media stream
packet. The drain rate refers to the payload media rate. For example, for a typical 3.75
Mbps MPEG video stream, the drain rate is 3.75 Mbps—the rate at which the payload is
displayed at a decoding node. The DF is computed at the time that each packet arrives
at the Hawkeye endpoint, and is recorded for each timing record. The default timing
record duration is three seconds.
The DF is computed at the arrival time of each packet at the point of measurement. For
Hawkeye, the point of measurement is Endpoint 2. It is recorded at set time intervals,
typically about one second. For Hawkeye, it is measured when each timing record is gen-
erated.
If X is a virtual buffer where DF is measured,
X = |Bytes Received – Bytes Drained|
Then, DF is calculated as follows:
DF = [max(X) – min(X)] / media rate
where media rate is expressed in bytes per second and max(X) and min(X) are the max-
imum and minimum values measured in an interval.

Hawkeye Test types
The largest difference is recorded for all intervals in a measurement period. That is, DF
is the maximum observed value of the flow rate imbalance over the calculated interval.
Media Loss Rate
The second component in the MDI is the Media Loss Rate (MLR).
The MLR is the count of lost or out-of-order packets, measured over a selected time
interval (such as three seconds). That is,
MLR = (Packets Expected – Packets Received) / Interval
There may be zero or more streaming packets in a single IP packet. For example, it is
common to carry seven 188 byte MPEG Transport Stream packets in an IP packet. In
such a case, loss of a single IP packet would result in seven lost MPEG Transport Stream
packets. Counting out-of-order packets is important because many streaming media
applications do not attempt to reorder packets that are received out of order.
Media Delivery Index
The Media Delivery Index (MDI) combines the Delay Factor (DF) and the Media Loss
Rate (MLR) values for presentation, and is expressed as:
DF:MLR
The DF provides a indication of the size of the buffer needed to accommodate the packet
jitter in the network. The MLR gives an indication of the extent of media loss as the
streaming media traverses the network.

Hawkeye Test types
What is Goodput ?
In computer networks, goodput is the application level throughput, i.e. the number of
useful information bits delivered by the network to a certain destination per unit of time.
The amount of data considered excludes protocol overhead bits as well as retransmitted
data packets. This is related to the amount of time from the first bit of the first packet
sent (or delivered) until the last bit of the last packet is delivered, see below.
For example, if a file is transferred, the goodput that the user experiences corresponds
to the file size in bits divided by the file transfer time. The goodput is always lower than
the throughput (the gross bit rate that is transferred physically), which generally is
lower than network access connection speed (the channel capacity or bandwidth).
Examples of factors that cause lower goodput than throughput are:
Protocol overhead; Typically, transport layer, network layer and sometimes datalink
layer protocol overhead is included in the throughput, but is excluded from the goodput.
Transport layer flow control and congestion avoidance, for example TCP slow start, may
cause a lower goodput than the maximum throughput.
Retransmission of lost or corrupt packets due to transport layer automatic repeat

request (ARQ), caused by bit errors or packet dropping in congested switches and
routers, is included in the datalink layer or network layer throughput but not in the good-
put.

Hawkeye Test types
Testing throughput using TCP or UDP

Differences explained
TCP UDP
TCP stack adapts to available band- UDP sends packets on best effort –
width sender is « bit blaster »
TCP stack implementation and con- UDP stack is minimal (packets build-
figuration has important impact ing)
TCP traffic is bidirectional : one way UDP is unidirectional – no acknow-

sends traffic, other way acknowledgments from receiver
ledges.

Hawkeye Test types
High sensitivity to packet losses and Not sensitive to network delay

network delay: Loss packets will result in linear
Delay will impact acknowledgement degradation of throughput
speed – loss result in retrans-
missions resulting in exponential
throughput degradation
TCP is throughput QoE: that is what UDP is throughput QoS : this is what
user experience ! network can deliver !
When to use TCP

l Qualifying user experience
l Validate available traffic on a network with live network active – no risk of con-
gestion as TCP traffic will auto adapt to available bandwidth
l Compare against typical FTP based measurements or Speedtest behaviors
l Qualify impact of TCP stack configuration (window size, buffers, Operating system
etc.
When to use UDP

l Qualifying available bandwidth : stress line with datagrams traffic (RFC 2544)
l Validate transport in both directions at same time
l Validate unused line – UDP traffic can cause network congestions affecting real
users traffic
Combination of TCP and UDP
A test called COS qualification offers pairs with TCP and pairs with UDP (RTP) and is
designed to test different classes of services :
l data class of services are tested with TCP

l voice/real traffic class of service is tested with RTP/UDP

Hawkeye Test types
Node to Node test types

This section discusses the Node to Node test types.
TCP throughput tests

What is my target measuring TCP performance?
This is one very important question that needs to be well addressed before going
through advanced TCP performance test.
TCP is the most widely used protocol for applications transiting over the Internet. Given
all factors influencing its performance, it is very important to make sure of what one is
trying to prove by doing TCP performance testing.
Test typical application behavior

Use the scripts called TCP Throughput. These scripts send large chunks of bytes from
Endpoint 1 to Endpoint 2, then waits for an acknowledgment
It thus simulates the core file transfer transaction performed by many applications.
TCP auto adapts to available bandwidth therefore will be a good indicator of the data
available for an application.
Network transmission capability verification -> Use UDP

If one is after defining pure network transmission capability, TCP is likely not the best
solution to prove the network. It will be a lot more efficient to use UDP tests which act
more as bit blasters and would report transparently any unidirectional data loss. UDP is
not connection oriented and therefore a lot more adequate when testing line trans-
missions.
When looking at network transmission capability, Ixia performance endpoint is able to

run UDP tests that are a lot more precise to report on line capacity transmission cap-
ability and packet loss.
UDP traffic generation is however dangerous as it wont adapt to available bandwidth and
therefore is likely to create router congestions and affect other traffic.

Hawkeye Test types
Make sure you use the right Operating System

One key factor is TCP stack used by performance endpoint in the test. The most com-
mon OS stacks, Linux and Windows, have different behaviors and therefore can behave
with different performance on same environment. It is important to understand that Ixia
performance endpoint is using the underlying OS stack and therefore the performance of
the stack is part of the performance test itself.
Ixia performance endpoints comes with most common OS and OS versions so allow con-
trolling what version can be used.
It is also very important to understand the stack parameters on the OS can have a big
impact on the results.
Define what the target performance is: what are you looking as
a good result?
Depending on the characteristics of the line you are trying to test, it is important to
define a target maximum throughput that is proving a good result for a single TCP
stream.
This will help defining how the performance endpoint has to be used to use the stack.
For example, it is likely that a FTP server on a 1G local LAN can be expected to reach
500M throughput or more, but if 1G line is used between 2 different remote sites with
long delays, is this 500M throughput still be a valid target?
Am I looking to prove a specific application?

All applications are specific in the way they would use the TCP stack: it cannot be expec-
ted that small volume transactions on a mail server would behave the same way as long
download over FTP servers.
Hawkeye script libraries provide a very wide range of common applications that can be
complemented by specific built applications to help understand the behavior over a spe-
cific network.
It is also important then to compare how a standard TCP throughput test compares to a
specific application test over TCP. Hawkeye allows running both aspects and under-
standing what could explain the difference in expected performance.

Hawkeye Test types
Do I want to use default OS settings or tune them for the TCP

stack?
Most real applications that use TCP stack do use the stack with default parameters.
However, the most common Operating Systems (Windows and Linux) allow controlling
the way the TCP stack is used through socket APIs. It does not allow controlling how the
stack is going to behave and auto adjust its window based on the environment, but will
allow to control the memory buffers for send and receive to optimize the use of the
stack.
These parameters are very important if one’s target is to understand the best possible
TCP performance a stream can get. As changing these parameters can influence greatly
on the stack optimization, there will be some performance impact by tuning these para-
meters.
Ixia performance endpoint has implemented these parameters. A typical test is to run a
“default settings” TCP test to see what the default stack is capable of, and then adjust
these parameters based on what is known of the environment (typically the RTT) to find
out what is the maximum achievable performance.
WARNING: If you leave OS parameters by default then when you set Hawkeye manually
force OS to use some buffers sizes it can happen that the values to are pushing are over
the limits configured on the OS and so are not taken into account.
Do I need one or several TCP streams?

If one is testing a link for TCP performance, it is important to know if one single TCP
stream is the best approach. Typically, links would transport in real life several streams
in parallel. These streams would all correspond to different applications or even to same
applications using different channels.
Therefore, if link capacity for TCP is the target, it is often more efficient to test several
TCP streams in parallel, which would usually result in better aggregated performance
than a single TCP stream.
One important point: speed measurements free tools that are available on the Internet
usually use several concurrent TCP streams to assess line capacities.

Hawkeye Test types
TCP throughput tests descriptions

TCP throughput from->to 1 stream
Description One TCP stream - generates throughput with defined bit rate - from
E1 to E2
Purpose Verify that a singe TCP stream in one direction is going through
Available Generated Bitrate (layer 4 bit rate) that is pushed by sender (node
Options from).
DSCP setting (QOS)
Metrics Average Throughput (kbps) from->to
Advanced This test will optimize use of TCP throughput pair from E1 to E2
Information based on requested throughput. Test samples will be computed
according to the requested bit rate so that there should be approx-
imately one measurement per second.
Results inter- The result in throughput is displayed at layer 4 level (with eth-
pretation ernet, IP and TCP headers, and includes potential retrans-
missions). TCP result in one pair is very sensitive to delay or
packet loss. Some result can show important discrepancy between
expected line rate and result due to TCP protocol high dependancy
on line characteristic. It is recommended to complement this test
with UDP or TCP multistream test for further pipe capacity assesse-
ment.
Potential If the configured bitrate is set too high compared to expected line
capacity, this might result in the test not able to accomplish first
Errors measurement. This would result in an error with time out ("Some
pairs in tests didnt complete"). If results cant be collected Check
that port in use is in range (see "preferences/Traffic Port Man-
agement/Destination Port Conf Option" and "preferences/Traffic
Port Management/First Destination Port" so that correct des-
tination port for test traffic is used.

Hawkeye Test types
TCP throughput from->to N streams
Description Multiple TCP stream - generates throughput with defined bit rate in
multiple streams from E1 to E2
Purpose Verify that a mutipleTCP stream in one direction is going through. If

several streams are configured (>5 typically) that provides a good
assessment of the pipe capability as it makes each TCP stream less
sensitive to delay and loss.
Options from).
DSCP setting (QOS)
Advanced This test will optimize use of TCP throughput pair from E1 to E2
Information based on requested throughput and shared between requested num-
ber of TCP pairs. The total throughput requested will be equaly dis-
tributed by number of pairs. The timing record per pair will be
optimized to be one timing record per second.
Results inter- Throughput information is layer 4 level.

pretation This test load shares throughput between different streams. This
allows better repartition and management of TCP window to prevent
high senstivity to packet loss or low window sizes (therefore TCP
retransmission). This test is recommended way to do capacity test-
ing of lines with TCP.
The recommended amount of TCP streams is between 5 and 10. The
result are only displayed with aggregated results.
Detailed report per second can be sometimes misleading as the
average throughput per second is dependent on simultaneously
aggregating information from the different streams and sometimes
can show strange behavior.

Hawkeye Test types
TCP throughput from->to N streams
Port Management/First Destination Port" so that correct destination
port for test traffic is used.
If the number of pairs is greater than available max number of pairs
per license the test can be stuck in queue.
The maximum number of simultaneous pairs (N value) each indi-
vidual test can perform is also controlled from an advanced setting.
Only Administrator can modify this setting:
In Main Section, Max Concurrent Tests in GUI

Hawkeye Test types
TCP throughput to->from 1 stream
Description One TCP stream - generates throughput with defined packet size
and bit rate - from E2 to E1
Purpose See TCP throughput from-> to 1 stream
Available
Options
Metrics
Advanced
Information
Results inter-
pretation
Porential
Errors
TCP throughput to->from N streams
Description Multiple TCP stream - generates throughput with defined packet

size and bit rate in multiple streams from E2 to E1

Hawkeye Test types
TCP throughput to->from N streams
Purpose See TCP throughput from->to N streams
Available
Options
Metrics
Advanced
Information
Results inter-
pretation
Potential
Errors
TCP throughput bidirectional
Description Bidirectional TCP throughput -with defined bitrate. The TCP

throughput is generated concurrently
Purpose Verify that a mutipleTCP stream in two directions is going through.

there is one stream per direction. Note this test is unlikely to fullty
assess the total bitrate available on either direction as some band-
width will be reserved for acknlowdgements (see below). There-
fore this test shall be reserved to validate how much bidirectional
streams can achieve based on TCP protocols.
Options from).
Average Throughput from->to - Generated Bitrate to->from
DSCP setting (QOS)
Metrics Average Throughput (kbps) from->to and to->from

Hawkeye Test types
TCP throughput bidirectional
Advanced This test combines TCP stream from E1 to E2 and from E2 to E1.
Information The timing record per pair will be optimized to be one timing
record per second.

pretation The TCP protocol works with send window management between
sender and receiver. Therefore some packets (useful data) are
sent from sender to receiver, and small acknowldgement packets
are sent from receiver to sender. As a result, part of the bandwidth
on both ways will be busy with small packets for acknow-
ledgement. This will impact line capacity results if the max expec-
ted capacity is tested. Therefore Ixia recommends to use this test
for validating below epxected capacity throughput availability and
perform consecutive one way testing using TCP one direction
tests.
Porential see TCP throughput from->to 1 stream.

Note that one direction can pass test while the other errors out.
Errors
TCP throughput advanced
E1 to E2 ) with advanced configurable settings
Purpose Verify that a mutipleTCP stream in one direction is going through.

If several streams are configured (>5 typically) that provides a
good assessment of the pipe capability as it makes each TCP
stream less sensitive to delay and loss.

Hawkeye Test types
TCP throughput advanced
Available Generated bitrate

Options TCP send buffer size
file size for timing record
sockets size
DSCP setting
source/destination ports
User must define bitrate, source, and destination

ports. All other values will be default unless
changed by User.
Advanced This test allows full control of the TCP stream. It requires
Information advanced understanding of the TCP architecture and testing
engine.

pretation This test will allow to fine tune the TCP stack according to some
settings that are dedicated to the test; See Annex for complete
TCP stack configuration documenation.
Recommended value is filesize to be around 1 second of data trans-
fer at expected throughput so in that case (factor 8 to take into
account the bytes to bit ratio):
filesize=thoughput (kbps)*1000/8
Porential see TCP throughput from->to 1 stream.
Errors

Hawkeye Test types
TCP optimized window size from->to
E1 to E2 ) with advanced configurable settings
Purpose TCP throughput between E1 and E2. Optimized Windows size will
be calculated according to delay, throughput and probe type.
Available Generated Bitrate

Options Expected one way delay on path
FileSize
DSCP setting
Advanced This test will allow optimization of the TCP window size according
Information to the value the user entered for one way delay expected on
the path and the file size. The calculations are performed for a
single TCP stream. The test will maximize the TCP throughput
through the use of a calculated window size. This calculated win-
dow size uses a TCP stack calculation provided by the OS (XR end-
points would be Linux) to maximize TCP throughput provided
because of the test. The file size and one way delay are two key
parameters used to calculate the TCP receive window. The TCP
receive window size will impact total throughput. Other values
such as network delay jitter are also considered to adjust the win-
dow size. The receive TCP window size impacts flow control by
adjusting the frequency of ACKs. The size of the window determ-
ines the number of bytes that will be transmitted without an Ack.
Note, the TCP process at each end of the connection can dynam-
ically adjust the sliding window to avoid network congestion, A lar-
ger sliding window enables higher throughput. Note XRPi and
XR2000 support RFC1323 (TCP window scaling) by default which
increases the TCP window size to use more than 64Kbps. However
not all software endpoints may support RFC1323. Note to max-
imize total throughput a large file size and small network delay are
required.

Hawkeye Test types
TCP optimized window size from->to
Results inter- The filesize needs to be calculated according to expected delay.

pretation Filesize corresponds to each timing record information transfer. If
file size is too important then there will too less (or known) timing
record. If it is too small there will be too many timing records
potentially impacting the effiiency of the test.
Recommended value is filesize to be around 1 second of data trans-
fer at expected throughput so in that case (factor 8 to take into
account the bytes to bit ratio):
filesize=thoughput (kbps)*1000/8
Potential see TCP throughput from->to 1 stream.
Errors
TCP throughput tests performance

TCP throughput tests are typically dependant on the underlying stack, overall capability
(cpu, network card) of the active endpoint.
For powerful enough devices (xr2000, servers, high range laptops), it should be possible
to generate up to line rate TCP streams (resulting in a goodput calculation of 960 to 970
Mbps depending on the transport layer.)
Less powerful endpoints will typically provide less capability that can be measured on
case by case.
As long delays can influence dramatically TCP throughput calculations it is recom-

mended to verify the maximum throughput capable with new devices by running end to
end scripts.
Optimizing Ixia performance Endpoint for Performance

Testing
Ixia performance endpoint Stack utilization parameters
The first item is the way the endpoint will be using the TCP script itself.
In tcp advanced test setup:

Hawkeye Test types
SEND
size = file_size (1000000)
buffer = send_buffer_size (65535)
rate = send_data_rate (to be filled up)
The parameters used are
Filesize: how much data is sent, and then wait for acknowledgement. Increasing it will
result into getting more data sent at once to the stack, and increase the length of the
timing record (how long between each performance record).
Recommendation for TCP performance testing is to target 1 timing record per second, so
make sure based on expected throughput it takes at least 1 second to download filesize.
Using up to 2 or even 5 seconds sometimes help getting the best performance.
Send and Receive buffer size: determine how much data will be sent to the TCP
stack for processing for each SEND and RECEIVE operation. They are unrelated to TCP
sliding window service
Recommendation for endpoint send and received buffer size for performance endpoint is
to make sure they are not too small, so that they are not too many cycles. They should
also not be in excess to the CONNECTION send and receive buffers (see below) that are
used to configure the TCP stack. Typical recommended value is 16kbytes, 32kbytes or
64kbytes. Unless misconfigured, this should not have a great impact on TCP per-
formance.
Send data Rate: determine the maximum data rate the Performance endpoint will try
to push sending through the stack. It can be set to unlimited (in which case the data will
be used at maximum rate) or any value in kbit or kbytes.
Recommendation for endpoint send data rate is to use unlimited when trying to perform
as much as possible. However, a side effect using unlimited value is that the stack will
be used at maximum but can be overloaded by performance endpoint throwing data in
bursts or spikes. Whe targeting a defined maximum throughput, it is a good idea to use
the defined throughput so that the TCP stack is used in a more even or stable way, and
therefore it is stabilized. When pushing the stack and/or network to the limit, it is
always better to do some binary search with send data rate to define the most stable
value given network conditions and endpoint send and receive OS performance.

Hawkeye Test types
Operating System TCP Stack settings

A prerequisite to any further tuning in Ixia Performance Endpoint is to have the TCP
stack parameters in the OS itself.
Find below optimization elements for the 2 main Operating Systems (Windows and
Linux).
Linux Operating systems

The default values are found with
TCP allocated memory:
$ cat /proc/sys/net/ipv4/tcp_mem
The default and maximum amount for the receive socket memory:
$ cat /proc/sys/net/core/rmem_default
$ cat /proc/sys/net/core/rmem_max
The default and maximum amount for the send socket memory:
$ cat /proc/sys/net/core/wmem_default
$ cat /proc/sys/net/core/wmem_max
The maximum amount of option memory buffers:
$ cat /proc/sys/net/core/optmem_max
Recommended changes
Set the max OS send buffer size (wmem) and receive buffer size (rmem) to 16 MB for
queues on all protocols. In other words set the amount of memory that is allocated for
each TCP socket when it is opened or created while transferring files.
CAUTION: The default value of rmem_max and wmem_max is about 128 KB in most
Linux distributions, which may be enough for a low-latency general purpose network
environment or for apps such as DNS / Web server. However, if the latency is large, the
default size might be too small. Please note that the following settings going to increase
memory usage on your server
# echo 'net.core.wmem_max=16777216' >> /etc/sysctl.conf

Hawkeye Test types
# echo 'net.core.rmem_max=16777216' >> /etc/sysctl.conf
Set minimum size, initial size, and maximum size in bytes:
# echo 'net.ipv4.tcp_rmem= 10240 87380 16777216 ' >> /etc/sysctl.conf
# echo 'net.ipv4.tcp_wmem= 10240 87380 16777216 ' >> /etc/sysctl.conf
Turn on window scaling which can be an option to enlarge the transfer window:
# echo 'net.ipv4.tcp_window_scaling = 1' >> /etc/sysctl.conf
Enable TCP timestamps as defined in RFC1323:
# echo 'net.ipv4.tcp_timestamps = 1' >> /etc/sysctl.conf
Enable select acknowledgments:
# echo 'net.ipv4.tcp_sack = 1' >> /etc/sysctl.conf
By default, TCP saves various connection metrics in the route cache when the con-
nection closes, so that connections established in the near future can use these to set
initial conditions. Usually, this increases overall performance, but may sometimes
cause performance degradation. If set, TCP will not cache metrics on closing con-
nections. The benefits or activating or disabling caching might depend on test expected.
# echo 'net.ipv4.tcp_no_metrics_save = 1' >> /etc/sysctl.conf
Set maximum number of packets, queued on the INPUT side, when the interface
receives packets faster than kernel can process them.
# echo 'net.core.netdev_max_backlog = 5000' >> /etc/sysctl.conf
The commands above configure the parameters and made them persistent into linux. To
reload the changes:
# sysctl -p
Windows Operating Systems

Please refer at following:
http://msdn.microsoft.com/en-us/library/cc558565(v=bts.10).aspx

Hawkeye Test types
This article contains all information from Microsoft to optimize TCP stack for performance
management.
UDP throughput tests

UDP traffic generation = bit blasting
UDP traffic generation with Hawkeye is a way to generate bit blasting from Ixia per-
formance endpoints.
The traffic rate defined and packet size will be generated from one side to the other.
UDP traffic is generated at layer 4 by Ixia endpoints/probes.
the data is sent through the operating system stack with packet sizes:
IP header : 20 byte
UDP header : 8 bytes
Layer 2 header : 14 to 18 bytes + 4 bytes checksum
All indications into Hawkeye are set at layer 4 (inside UDP header).
Even though the traffic generation is IP to IP (layer 4) inside UDP packets (layer 4) the
result of the traffic generation can be considered as traffic blasting (aka RFC 2544 test-
ing).

Hawkeye Test types
UDP traffic burstiness
Traffic generation from software based system can create some problems at high rates
with traffic generation burstiness.
That means that traffic as sent from ixia endpoint or probe can be generated with ave-
gare bitrate as requested, but with a non linear profile.
The following figure illustrates a traffic generated with bursts of traffic - typical behavior
from a software based traffic generation tool like Hawkeye.
Network equipments like traffic shapers or rate controllers would remove any traffic
going at higher rates than 100Mbps in the above example resulting into a problematic
measurement of the available bit rate.
Hawkeye implements an algorithm that can be used to reduce drammatically this jitter
and side effects measuring UDP flows in networks.
This optimization algorithm that uses very precise timers to reduce jitter between sent
packets and when this algorithm is enabled, the datagrams are sent by Endpoint 1 usea
lot more precise intervals than when the standard algorithm is in effect.

Hawkeye Test types
Enabling this Low Sender Jitter algorithm:
As Administrator, go into Administration/Preferences/Test Engine
configure the following elements:
sendlowjitter to 1
NOTE: some endpoints would not support the send low jitter algorithm and therefore res-
ult into an error for unsupported option into result list.
Send low jitter option is a global parameter that needs to be set by administrator.

Hawkeye Test types
UDP packet size and performances

The limitation of packets that can be sent per second typically depends upon the fol-
lowing factors:
l the number of packets / second that Network interface card

l CPU of the system can manage (usually based on # packets per second as well).
The total capacity of network cards and therefore Hawkeye endpoint software is limited
by number of packets per second.
Large packets usually result into significant bit rates capabilities.
Smaller packets will have less bit rate on the network, therefore it is expected the total
amount of traffic endpoints will be able to generate are declining with the frame rate.
As an example for a network interface card able to generate packets at about line rate
for max IP MTU (1500 bytes):
This is only example and should be read to give guidance on expected throughput cap-
abilities at different packet sizes and levels on an endpoint example. Real value would
slightly differ from the table below depending on the endpoint type:
UNIT = BYTE UNIT = Mbps
Packet Packet packet Goodput IP rate layer 2 # packets

size UDP size IP size layer rate rate / second
2
1460 1488 1506 958 976 988 82000
1300 1328 1346 853 871 883 82000
1000 1028 1046 656 674 686 82000
500 528 546 328 346 358 82000

Hawkeye Test types
200 228 246 131 150 161 82000
100 128 146 66 84 96 82000
64 92 110 42 60 72 82000
10 38 56 7 25 37 82000
Using the traffic buffering algorithm optimization can help generating more packets per
second for powerful cpu endpoints (where bottleneck is in the network interface card):
by way of sending more even traffic to the stack, Hawkeye probes optimize the packets
that can be sent.
Jumbo frames: packets with jumbo frames are supported by Ixia endpoints if the net-
work interface of the endpoint is configured for it and able to support it. A special jumbo
frame configuration needs to be set into Hawkeye - please contact support to set it up if
needed.
Exceeding UDP traffic generation capability

Hawkeye does not limit the bit rate and packet size generation for users therefore it is
essential that users have some understanding of the limits of the probes they are using.
Generating too much traffic will result into packets drops at the traffic generator stack
(packets are never sent to the network) or packets being lost at reception of the stack
(packets are not counted as received by receiving endpoint/probe).
UDP throughput tests descriptions

UDP throughput from->to
Description One UDP stream - generates throughput with defined packet size

Hawkeye Test types
Purpose Send UDP packets (bit blasting) at defined rate to validate the
capacity between endpoints
Available Generated Bitrate

Options Packet Size
DSCP setting

Loss (%)
Total bytes lossed
Advanced This test will generate UDP packets from E1 to E2 based on reques-
Information ted throughput. Test sample Filesize will be computed according to
the requested bit rate so that there should be approximately one
timing record per second. Optimized packet size is udp size used
to optimize the stack therefore pushing packet size bigger than
MTU to get full MTU packets on the line. While it provides better
results for throughput it can be sensitive to packet fragmentation
on the network therefore providing lot of packet losses in some net-
work conditions.
pretation ernet, IP and UDP headers). UDP packet generation is similar to
bit blasting therefore will not autoadjust to available bandwidth.
Some higher than capacity traffic generation can result into net-
work equipments traffic congestion and therefore cause some ser-
vice drops.
Traffic generation can be optimized with using an option in pref-
erences / test engine settings: send low jitter is an algorithm
optimizing UDP traffic generation and therefore avoiding bursty
traffic. This is particularly recommended to activate this option
when using traffic shaping. The total byte lossed metric is indic-
ation of number of bytes that were lossed during the test. By
default the threshold will always pass.

Hawkeye Test types
Errors measurement. This would result in an error with time out (unable
to collect result). Small packet sizes are not able to generate as
much throughput as large ones: at high traffic, it is possible that
endpoints generate packet losses as they would be unable to gen-
erate the expected traffic rate.
In case of use of UDP packet size optimized or 1460 packet size,
be careful in case of low MTU or network fragmentation: this can
cause packets to be fragmented therefore unexpected or higher
than expected packet loss rates. It is recommened to use a lower
UDP packet size (1300 for example) to validate there is no impact
on test result.
If there is unpexected loss this could be because of some bursty
UDP traffic generation: make sure you have endpoints supporting
the send low jitter option and enable in preferences/test engine in
Hawkeye preferences.
if results cant be collected (some pairs didnt complete error):
Check that your E2 endpoint can open 10115 port toward E1 for
management (this is needed for stream pairs).
Check that port for traffic is opened (no firewall).
Check that synchronisation port between pairs is opened (man-
agement UDP 10115). Check that port in use is in range (see "pref-
erences/Test Controler/Destination Port Conf Option" and
"preferences/Test Controler/First Destination Port" so that correct
destination port for test traffic is used.
UDP throughput to->from
Description One UDP stream - generates throughput with defined packet size

Hawkeye Test types
UDP throughput to->from
Purpose See UDPthroughput from-> to
Available
Options
Metrics
Advanced
Information
Results inter-
pretation
Potential
Errors
UDP throughput bidirectional
Description Bidirectional UDP throughput -with defined packet size and bitrate.
The UDP throughput is generated concurrently
capacity between endpoints in both directions.
Unlike TCP bidirectional, this measure is perfectly valid to meas-
ure both ways of communications simultaneously provided there is
no max out of endpoint/probe performance.
Available Per directions:

Options Generated Bitrate
Packet Size
DSCP setting

Hawkeye Test types
UDP throughput bidirectional
Metrics Per direction:

Average Throughput (kbps) from->to
Loss (%)
Total bytes lossed
Advanced This test combines UDP stream from E1 to E2 and from E2 to E1.
Information The timing record per pair will be optimized to be one timing
record per second.
Note that performance of and endpoint sending and receiving is
typically lower than endpoint dedicated to sending or receiving.
We see typically 20 to 30% performance reduction when traffic is
generated both ways as opposed to one way only.
Results inter- See UDPthroughput from-> to

pretation
Potential See UDPthroughput from-> to
Errors
UDP throughput advanced
Description UDP throughput between E1 and E2 with advanced parameter

options
capacity between endpoints in both directions.
Advanced options allow to be more specific about what is required.

Options UDP send buffer size
file size for timing record sockets size
DSCP setting
source/destination ports

Hawkeye Test types
UDP throughput advanced
Metrics Throughput (kbps) from->to

Loss (%) from->to
Total bytes lossed to-->from
Advanced This test will allow to fine tune the UDP stack according to some
Information settings that are dedicated to the test; See Annex for complete
UDP stack configuration documenation. Recommended value is
filesize to be around 1 second of data transfer at expected through-
put so in that case (factor 8 to take into account the bytes to bit
ratio): filesize=thoughput (kbps)*1000/8
Results inter- See UDPthroughput from-> to

pretation
Potential See UDPthroughput from-> to
Errors
Network Loss Performance
Description Determines UDP loss quality metrics between two endpoints.
Purpose Analyzes loss metrics for a UDP stream played in one direction.
Available Options Target UDP throughput for one stream

Test duration (sec)
Specify which QOS (DSCP setting) to request between switches
in network.
Packet size

Hawkeye Test types
Network Loss Performance
Metrics Metrics
l Loss (UDP bytes)
l Lost Datagrams (UDP packets)
l Max Loss burst
l Total Datagrams Rcvd
l Total Datagrams Sent
Advanced Inform- Thresholds can be set for all above metrics.

ation
Results inter- See Advanced Information

pretation
Potential See Hawkeye Error Description Guide.
Errors
Network KPI tests

The network KPI test described in this section will allow to test the network by sending
"heatbeats" from node to node. These tests are especially suited for Mesh testing as
they have little impact on the network and help understanding key transport metrics
such as:
l loss
l jitter
l delay
These are key SLA indicator for network health and Service Level Agreements.
Network KPI from->to
Test network delivery KPI with low foot print (100kbps) and 50
Description packets per second- From E1 to E2 direction
Purpose Measuring key KPI loss/jitter/latency

Hawkeye Test types
Network KPI from->to
Available DSCP setting

Options
One way delay (ms)

jitter (ms)
max jitter (ms)
packet loss (%)
voice MOS score
packet loss burst.
Metrics max delay variation(ms)
This test will generate unidirectional traffic with heartbeats to

measure the key metrics. The traffic is similar to voice traffic -
Advanced MOS score is an indicator of capacity of the link to transport Voice
Information in a good quality.
The network KPI pair generates packets RTP stream .

These packets traverse the network from one probe to the other
and provides indication based on time sent and receive, how many
are lossed etc...
The packets are sent similarly to a G711 voice stream as this is
expected to be a key application the network shall be able to trans-
port.
Results inter- Voice MOS score gives an indication of the quality of transport net-
pretation work for voice G711 application.
If test result pair cant be collected:

agement UDP 10115).
Check that port in use is in range (see "preferences/Test Con-
Potential troler/Destination Port Conf Option" and "preferences/Test Con-
troler/First Destination Port" so that correct destination port for
Errors test traffic is used.

Hawkeye Test types
Network KPI from->to 3 COS
Test network delivery KPI with low foot print (100kbps per COS)
and 50 packets per second- From E1 to E2 direction, on 3 different
Description COS
Purpose Measuring key KPI loss/jitter/latency for 3 COS
Available Per COS :

Options DSCP setting
Per COS:
One way delay (ms)
jitter (ms)
max jitter (ms)
packet loss (%)
voice MOS score
packet loss burst.
Metrics max delay variation(ms)
This test will generate unidirectional traffic with heartbeats to

measure the key metrics. The traffic is similar to voice traffic -
Advanced MOS score is an indicator of capacity of the link to transport Voice
Information in a good quality.
The network KPI pair generates packets RTP stream .

These packets traverse the network from one probe to the other
are lossed etc...
port.
Results inter- Voice MOS score gives an indication of the quality of transport net-
pretation work for voice G711 application.

Hawkeye Test types
Network KPI from->to 3 COS
If test result pair cant be collected:

agement UDP 10115).
Potential troler/Destination Port Conf Option" and "preferences/Test Con-
Errors test traffic is used.
Network KPI to->from
Description Test network delivery KPI with low foot print (100kbps) and 50
packets per second- From E2 to E1 direction

Options
Metrics One way delay (ms)

jitter (ms)
max jitter (ms)
packet loss (%)
voice MOS score
packet loss burst.
max delay variation(ms)
Advanced This test will generate unidirectional traffic with heartbeats to

Information measure the key metrics. The traffic is similar to voice traffic -
MOS score is an indicator of capacity of the link to transport Voice
in a good quality.

Hawkeye Test types
Network KPI to->from
Results inter- The network KPI pair generates packets RTP stream .
pretation These packets traverse the network from one probe to the other
are lossed etc...
port.
Voice MOS score gives an indication of the quality of transport net-
work for voice G711 application.
Potential If test result pair cant be collected:

Errors management (this is needed for stream pairs).
agement UDP 10115).
troler/Destination Port Conf Option" and "preferences/Test Con-
test traffic is used
Network KPI bidirectional
Description Test network delivery KPI with low foot print (100kbps) and 50
packets per second- From E1 to E2 direction and E2 to E1 sim-
ultaneously

Options

Hawkeye Test types
Network KPI bidirectional
Metrics Per direction:

One way delay (ms)
jitter (ms)
max jitter (ms)
packet loss (%)
voice MOS score
packet loss burst.

Information measure the key metrics. The traffic is similar to voice traffic -
MOS score is an indicator of capacity of the link to transport Voice
in a good quality.
are lossed etc...
port.
Voice MOS score gives an indication of the quality of transport net-
work for voice G711 application.

Check that synchronization port between pairs is opened (man-
agement UDP 10115).
test traffic is used.

Hawkeye Test types
Network KPI Low Bandwidth
Description Test network delivery KPI with advanced parameters for packet
settings - From E1 to E2 direction - with very low bandwidth
(<2kbps line rate) . Only sends 1 hearbeat per second (lower pre-
cision)
Available Total bitrate (kbps) for the stream

packet size

jitter (ms)
max jitter (ms)
packet loss (%)
packet loss burst

Information measure the key metrics. the low bandwidth of measurements
make them less precise than the standard network KPI tests.
are lossed etc...

agement UDP 10115).

Hawkeye Test types
Network KPI advanced
Description Test network delivery KPI with advanced parameters for packet
settings - From E1 to E2 direction
Available Total bitrate (kbps) for the stream

packet size

jitter (ms)
max jitter (ms)
packet loss (%)
packet loss burst

Information measure the key metrics.
are lost etc.

agement UDP 10115).
QOS qualification tests

The tests detailed in this section are used to qualify Class of Services.

Hawkeye Test types
The Class of service implementation in networks is often implemented at layer 3 and

required on end to end for full validation. The tests presented in this section will help
qualifying the QoS implementation and SLA end to end.
Typical use case

The wlan is implemented between sites with CoS
Each link going to remote sites will have same or different Class of Services imple-
mentation, tied to same or different SLA from carriers transporting last mile.
The different classes of services are defined based on TOS parameter settings.

Hawkeye Test types
Layer 3 Quality of Service

Hawkeye provides support for Layer 3 Quality of Service ased on DSCP class name - see
dedicated section ClassOfServices.htm for full details.
You can generate traffic up to line rate with class of service targets, and generate class
of service over-subscription traffic.
Typical example is:
10% Real time
20% critical
70% Best effort
In test scenario, try to fill up the link capacity with 100% best effort traffic and 10%
voice, 20% critical application.
The scenario will pass if the link discards best effort traffic and sustains prioritized
traffic.

Hawkeye Test types
Supported Test types

For testing single class of service with ad hoc COS setting, the different test types
described into TCP throughput tests.htm and UDP throughput tests.htm sections are
available.
Some dedicated test types can be used to fill up different class of services and run over-
subscriptions scenarios.
UDP from->to up to 4 COS
Description 4 UDP streams - each generates throughput with defined packet

size and bit rate - from E1 to E2
capacity between endpoints on all 4 different streams. This will
allow to validate class of services mix with bit blasting on each
one, and run over-subscription scenarios.
Available Per stream :

Options Generated Bitrate
Packet Size
DSCP setting
NOTE: if generated bitrate is 0 on one stream then this stream will

be ignored
Metrics Per stream:

Loss (%)
Total bytes lossed

Hawkeye Test types
Advanced Per stream

Information This test will generate UDP packets from E1 to E2 based on reques-
ted throughput. Test sample Filesize will be computed according to
the requested bit rate so that there should be approximately one
timing record per second. Optimized packet size is udp size used
to optimize the stack therefore pushing packet size bigger than
MTU to get full MTU packets on the line. While it provides better
results for throughput it can be sensitive to packet fragmentation
on the network therefore providing lot of packet losses in some net-
work conditions.

Hawkeye Test types
pretation ernet, IP and UDP headers). UDP packet generation is similar to
bit blasting therefore will not autoadjust to available bandwidth.
Some higher than capacity traffic generation can result into net-
work equipments traffic congestion and therefore cause some ser-
vice drops.
Traffic generation can be optimized with using an option in pref-
erences / test engine settings: send low jitter is an algorithm
optimizing UDP traffic generation and therefore avoiding bursty
traffic. This is particularly recommended to activate this option
when using traffic shaping. The total byte lossed metric is indic-
ation of number of bytes that were lossed during the test. By
default the threshold will always pass.

Hawkeye Test types
Errors measurement. This would result in an error with time out (unable
to collect result). Small packet sizes are not able to generate as
In case of use of UDP packet size optimized or 1460 packet size,
be careful in case of low MTU or network fragmentation: this can
cause packets to be fragmented therefore unexpected or higher
than expected packet loss rates. It is recommened to use a lower
UDP packet size (1300 for example) to validate there is no impact
on test result.
If there is unexpected loss this could be because of some bursty
UDP traffic generation: make sure you have endpoints supporting
the send low jitter option and enable in preferences/test engine in
Hawkeye preferences.
COS line qualification
Description Test consists of up to 4 class of services validation. One is real

time (UDP) and others are data oriented (mostly transporting TCP
traffic)

Hawkeye Test types
capacity between endpoints on all 4 different streams. The TCP
classes of services are tested with TCP stream mixes (3 mixed
streams) trying to achieve as much traffic as possible. The class of
services should "auto adjust" themselves to the defined compared
capacity they should allow transport. For voice class of service,
the expected throughput should be defined.
Available Global: filesize (in bytes)- will define which filesize shall be used
Options for TCP traffic generation.
filesize is going to determine how precise and efficient traffic gen-
eration on TCP classes of service will be.
Each class of service is send 3 streams.
So if classes of services are expected to adjust to :
1M : 40000 bytes
5M: 200000 bytes
10M: 400000 bytes
etc...
For Voice stream :defined bitrate
Per stream :
Destination port : leave to blank for auto, otherwise put a specific
port used by the network architecture to define class of service
DSCP setting: define stream class of service
NOTE: if generated bitrate is 0 on voice stream then this stream

will be ignored

Hawkeye Test types
Metrics Voicestream:
Loss (%)
Total bytes lossed
Delay
Jitter
Max loss Burst
For TCP streams:

throughput

Hawkeye Test types
Advanced Per stream

Information This test will generate TCP packets for class of services and RTP
packets for voice.
The TCP packets are generated on each class of service so that
they should all take most of the class of service.
In case class of service reservation is higher on some COS than
others the repartition should not be even but reflect what is con-
figured.
Each TCP class of service is filled with 3 concurrent streams.
The (optional) voice test will provide throughput but also voice
related parameters for jitter/loss/delay while the data network is
under stress.
Results inter- see advanced Information

pretation

Hawkeye Test types
Potential For voice:

If the configured is set too high compared to expected line capa-
Errors city, this might result in the test not able to accomplish first meas-
urement. This would result in an error with time out (unable to
collect result). Small packet sizes are not able to generate as
For TCP: the filesize needs to be adjusted to the expected min-
imum COS throughput. Setting a filesize too high might result into
test impossible to finish because file transfer is too long.
Voice and Video tests

A variety of voice and video tests are supported using the latest codecs.
Voice
Voice from->to
Description Test voice quality from E1 to E2, with G711, G729, AMR codecs
Purpose Voice Media stream is generated in one direction and key trans-
port metrics are validated. At the same time a Mean Opinion Score
is computed to validate the transport quality.

Hawkeye Test types
Voice from->to
Available Voice codec: G711, G729, AMR DSCP setting

Options

jitter (ms)
jitter max (ms)
packet loss (%)
voice MOS score on path
packet loss burst
Advanced This test will generate unidirectional Voice traffic with selected
Information codec.
Results inter- The voice pair generates RTP stream according to selected codec.
pretation The content of the voice traffic itself is not actual voice. This test
qualifies network transport capability for realistic voice traffic.
Potential If test result pair cant be collected: Check that your E2 endpoint
can open 10115 port toward E1 for management (this is needed for
Errors stream pairs). Check that synchronisation port between pairs is
opened (management UDP 10115). Check that port in use is in
range (see "preferences/Test Controler/Destination Port Conf
Option" and "preferences/Test Controler/First Destination Port" so
that correct destination port for test traffic is used.


Hawkeye Test types
Voice bidirectional
Description Test voice quality from E1 to E2 AND E2 to E1, with G711, G729,
AMR codecs
Metrics are gathered by direction.
This reproduces a realistic voice media call
Purpose See Voice from-> to
Available
Options
Metrics
Advanced
Information
Results inter-
pretation
Potential
Errors
Voice n pairs unidirectional
Description Test voice quality from E1 to E2, with G711, G729, AMR codecs,
with N calls simultaneously
Purpose Voice Media stream is generated in one direction and key transport
metrics are validated. At the same time a Mean Opinion Score is
computed to validate the transport quality.
This test is performed for N calls
Available Voice codec: G711, G729, AMR DSCP setting , Number of calls
Options

Hawkeye Test types
Metrics Aggregated over the N pairs:

One way delay (ms)
jitter (ms)
jitter max (ms)
packet loss (%)
voice MOS score on path
packet loss burst
Total Voice traffic throughput (layer 4)
Advanced This test will generate N pairs. Test results are aggregated and
Information there are no detailed results
Results inter- see Voice from->to

pretation

Hawkeye Test types
Potential If the number of pairs selected is greater than available licenses

the test can be stuck in queue. Note the number of pairs is N (one
Errors pair per voice direction).
The maximum number of simultaneous pairs (N value) each indi-

vidual test can perform is also controlled from an advanced setting.
Only Administrator can modify this setting:
In Main Section, Max Concurrent Tests in GUI
See voice from->to for other potential issues.
Voice n pairs bidirectional
Description Test voice quality from E1 to E2 AND E2 to E1, with G711, G729,
AMR codecs
Metrics are gathered by direction.
This reproduces a realistic voice media call.
This test does N calls

Hawkeye Test types
Voice n pairs bidirectional
Purpose See Voice N pairs unidirectional
Available
Options
Metrics
Advanced
Information
Results inter-
pretation
Potential
Errors
Video Stream
Video Stream
Description Define a video stream from E1 to E2 with defined bit rate and
MPEG2 or customizable codec.
Purpose Generate a unidirectional video flow from E1 to E2. This can sim-
ulate video based on RTP/UDP flows going through the network.


jitter (ms)
jitter max (ms)
packet loss (%)
max loss burst
video MDI scores (Media Delivery Index, Delay Factor)

Hawkeye Test types
Video Stream
Advanced This test allows generating video rtp streams - bitrate will define
Information corresponding codec (HD or SD)
Results inter- This test generate Video stream on the selected path. It can be
pretation optimized with setting up send low jitter in the preferences to be 1
if the endpoints support it.
range (see "preferences/Test Controler/Destination Port Conf
Option" and "preferences/Test Controler/First Destination Port" so
that correct destination port for test traffic is used.
Multicast Video over RTP
Description Multicast Flow. Emulates the standard streaming video codec.

Measures video metrics.
Purpose Generate a multicast video flows from E1 to (E2…..EN). Where N

the number of endpoints supported in the Mesh. This can simulate
video based on RTP/UDP flows going through the network.
Available Test duration , Test bit rate (Kbps), DSCP Setting, Multicast
Options Address: Port Video from->to.

Hawkeye Test types
Metrics Datagrams Out of Order

Delay (ms)
Jitter (ms)
Jitter Max (ms)
Loss
Max loss burst
Source and destination ports
Throughput Video (kbps)
Total Bytes Lost Video
MDI Delay Factor (Media Delivery Index, Factor)
Video MDI Media Loss Rate (Media Delivery Index, Loss Rate)
Advanced This test allows generating video rtp streams - bitrate will define
Information corresponding codec (HD or SD)
Results inter- This test generate Video stream on the selected path. It can be
pretation optimized with setting up send low jitter in the preferences to be 1
if the endpoints support it.
Potential If test result pair cannot be collected:

l Ensure that your E2 endpoint can open 10115 port toward E1
Errors
for management (this is needed for stream pairs).
l Ensure that synchronization port between pairs is opened
(management UDP 10115).
l Ensure that the port in use is in range. See "preferences/Test
Controller/Destination Port Conf Option" and "pref-
erences/Test Controller/First Destination Port" so that correct
Adaptive video
Description Emulates Adaptive Video Streaming over HTTP

Hawkeye Test types
Adaptive video
In the case of this video streaming technique, the video is

encoded on a server at several bitrates and divided into video seg-
ments of 2 to 10 seconds.
The client first learns the available bitrates by downloading a
video manifest, then starts requesting video segments from the
server at a specific bitrate. The client starts requesting video seg-
ments at a medium bitrate, but this can be changed by altering the
Starting Bitrate parameter of any Adaptive Video over HTTP flows.
Depending on the network bandwidth and the local speed of video
decoding and rendering, the client can decide to increase (upshift)
or decrease (downshift) the requested bitrate for future video seg-
ments as compared to that requested for the previous video seg-
Purpose ments.
Available Test duration , Test bit rate list, DSCP Setting, Number of Parallel
Options Streams.
Avg Video Playback Rate (bps)

Avg Video Pre-buffering duration (ms)
Jitter Buffer Full Count
Jitter Buffer Full Duration (ms)
Throughput from->to (kbps)
Video Playback Downshifts
Video Playback Upshifts
Video Quality Segments - Very High
Video Quality Segments - High
Video Quality Segments – Medium
Video Quality Segments - Low
Video Quality Segments - Very Low
Video Stopped Count
Metrics Video Stopped Duration (ms)

Hawkeye Test types
Adaptive video
Upshifting provides better video quality, but at a greater risk of

playback interruptions, while downshifting increases playback
smoothness at the expense of video quality.
Through its adapting capability, this video streaming technique
Advanced provides the best trade-off between video quality and smooth
Information video streaming.
Where no jitter buffer is used (there are no video download lim-

itations), the video is downloaded at the maximum speed allowed
by network conditions. This means that there are no pauses
between GET requests.
One in which the jitter buffer is used and as such, the download of
the video segments is paused when the buffer becomes full. On
average, the throughput will not exceed the maximum video
bitrate.
Video Playback Downshift is a decrease in the requested bit rate
for future video segments as compared to that requested for the
previous video segments. Video Playback Upshift is an increase in
the requested bit rate for future video segments as compared to
that requested for the previous video segments.
Video quality segments indicate the distribution of video playback
Results inter- quality Video stopped count and duration indicate the video play-
pretation back interruptions and its duration.
If test result pair cannot be collected:

l Ensure that your E2 endpoint can open 10115 port toward E1
l Ensure that port in use is in range. See "preferences/Test
Potential Controller/Destination Port Conf Option" and "pref-
Errors destination port for test traffic is used.

Hawkeye Test types
Adaptive video with network quality
Emulates Adaptive Video Streaming over HTTP and measure net-

Description work quality with a separate stream

ments of 2 to 10 seconds. The client first learns the available
bitrates by downloading a video manifest, then starts requesting
video segments from the server at a specific bitrate.
The client starts requesting video segments at a medium bitrate,
but this can be changed by altering the Starting Bitrate parameter
of any Adaptive Video over HTTP flows. Depending on the network
bandwidth and the local speed of video decoding and rendering,
the client can decide to increase (upshift) or decrease (downshift)
the requested bitrate for future video segments as compared to
Additionally this also tests the Network KPI along with video
streaming on both directions : it adds a bidirectional very low foot-
print packet heartbeat to measure the network kpis (loss/delay/jit-
Purpose ter) on the segment
Options Streams.

Hawkeye Test types

Video Stopped Count
Video Stopped Duration (ms)
Network KPI Metric:
Delay (Ms):
Jitter (Ms):
Jitter Max (Ms):
Metrics Loss:


Hawkeye Test types
This test is realistic and since jitter buffer is used and as such, the
download of the video segments is paused when the buffer
becomes full. On average, the throughput will not exceed the max-
imum video bitrate.
quality Video stopped count and duration indicate the video play-
back interruptions and its duration.
Video Stopped Count Video Stopped Duration will tell for any user
experience having video stalling during the watch
The number of Downshift and Upshifts indicate how often the adapt-
ive rate needed to change: lots of changes indicate an instable net-
work condition.
The Avg Playback rate will indicate the overall video quality exper-
ience: high rate will mean the high quality segments could be
Results inter- transported, lower rates mean the video had to adapt to lower qual-
pretation ity segments
This test can only work from public->public, private->private and

private->public. It is NOT supported for public->private direction


Hawkeye Test types
Flash RTMP
Emulates Adaptive Video Streaming With default RTMP bit rates

Description sizes.

server at a specific bitrate.
of any Adaptive Video over HTTP flows.
ments.
Additionally this also tests the Network KPI along with video
Purpose streaming
Options Streams.

Video Stopped Count

Hawkeye Test types
Flash RTMP

The download of the video segments is paused when the buffer

becomes full. On average, the throughput will not exceed the max-
imum video bitrate.
experience having video stalling during the watch
work condition.
pretation ity segments.

Hawkeye Test types
Flash RTMP


Netflix
Description Emulates Netflix Adaptive Video.

server at a specific bitrate.
ments. Additionally this also tests the Network KPI along with
Purpose video streaming
Test duration , Video Rates Video Stream, Audio Rates Audio

Available Stream, quality for video (HD or SD), DSCP Setting, Number of Par-
Options allel Streams.

Hawkeye Test types
Netflix

Video Stopped Count


Hawkeye Test types
Netflix

between GET requests.
One in which the jitter buffer is used and as such, the download of
the video segments is paused when the buffer becomes full. On
average, the throughput will not exceed the maximum video
bitrate. Video Playback Downshift is a decrease in the requested
bit rate for future video segments as compared to that requested
for the previous video segments.
Video Playback Upshift is an increase in the requested bit rate for
future video segments as compared to that requested for the pre-
vious video segments. Video quality segments indicate the dis-
tribution of video playback quality Video stopped count and
duration indicate the video playback interruptions and its dur-
ation.
experience having video stalling during the watch The number of
Downshift and Upshifts indicate how often the adaptive rate
needed to change: lots of changes indicate an instable network
condition. The Avg Playback rate will indicate the overall video
quality experience: high rate will mean the high quality segments
Results inter- could be transported, lower rates mean the video had to adapt to
pretation lower quality segments.



Hawkeye Test types
Youtube
Description Emulates Youtube Adaptive Video

ments of 2 to 10 seconds. The client first learns the available
bitrates by downloading a video manifest, then starts requesting
video segments from the server at a specific bitrate.
ments. Additionally this also tests the Network KPI along with
Purpose video streaming.
Available Test duration, Video Rates Video Stream, Test bit rate list, DSCP
Options Setting, Number of Parallel Streams.

Video Stopped Count

Hawkeye Test types
Youtube


between GET requests. One in which the jitter buffer is used and as
such, the download of the video segments is paused when the buf-
fer becomes full. On average, the throughput will not exceed the
maximum video bitrate.
experience having video stalling during the watch.
work condition.
pretation ity segments.

Hawkeye Test types
Youtube

private->public. It is NOT supported for public->private direction.
Unified Communications
Unified communication traffic is reproducing voice and video traffic going through net-
works.
Skype4B traffic from->to
Description Microsoft Skype4B traffic. Default parameters for audio and video
based on Microsoft recommended settings. User configurable para-
meters. This test is for bidirectional configuration.
Purpose Reproduce Skype4B traffic to assess the network capability to trans-

port this traffic either in volumes or for singe calls
Available For each direction:

Options Generated bitrate audio,
Generated bitrate video,
QOS for each traffic,
Packet size audio,
Packetsize video
Total number of users (number of streams)

Hawkeye Test types
Metrics For each direction and each stream (audio/video)

Upstream/Downstream loss
jitter
max jitter
one way delay
throughput audio
throughput video
max loss bursts (max consecutive packet loss)
Advanced Skype4B traffic unidirectioanl will emulate Skype4B users talking to

Information each other in one way. This test is designed according to Microsoft
recommended network validation of network use for Skype4B. This
test can be used and fine tuned to test any Unified Communication
solution combining Voice and Video traffic. This is recommended to
be used in meshes so that both directions are tested at the same
time.
The number of users is typically not used to generate volume
traffic: it is recommended to leave this setting to 1 and compute
the total volume of traffic according to traffic profiles.
Results inter- This test generate Skype4B Audio and Video streams on the selec-
pretation ted paths. It can be optimized with setting up send low jitter in the
preferences to be 1 if the endpoints support it.

Hawkeye Test types
range (see "preferences/Traffic Port Management/Destination Port
Conf Option" and "preferences/Test Controler/First Destination
Port" so that correct destination port for test traffic is used.
NOTE: in preferences Skype4B has its own port management con-
trol:
Preferences/Traffic Port Management/Destination Port Conf Option
If Use Skype4B Special Range option is set to 1 this will take pre-
cedence over the default port management for Skype4B tests (only
for Skype4B tests).
Skype4B traffic
Description Microsoft Skype4B traffic. Default parameters for audio and video
based on microsoft recommended settings. User configurable para-
meters. This test is for unidirectional configuration.

Hawkeye Test types
Skype4B traffic
Purpose Reproduce Skype4B traffic to assess the network capability to trans-

port this traffic either in volumes or for singe calls
This test is for bidirectional communication - reproducing the traffic
of realistic conversations.
Available Per direction:

Options Generated bitrate audio,
Generated bitrate video,
QOS for each traffic,
Packet size audio,
Packetsize video
Total number of users (number of streams)
NOTE : typically traffic are symmetrical per transaction.
Metrics For each direction and each stream (audio/video)

Upstream/Downstream loss
jitter
max jitter
one way delay
throughput audio
throughput video
max loss bursts (max consecutive packet loss)
Advanced Skype4B traffic bidirectional will emulate Skype4B users taliking to

Information each other in each location. This test is designed according to
Microsoft recommended network validation of network use for
Skype4B. This test can be used and fine tuned to test any Unified
Communication solution combining Voice and Video traffic.
The number of users is typically not used to generate volume
traffic: it is recommended to leave this setting to 1 and compute
the total volume of traffic according to traffic profiles.

Hawkeye Test types
Skype4B traffic
Results inter- This test generate Skype4B Audio and Video streams on the selec-
pretation ted paths. It can be optimized with setting up send low jitter in the
preferences to be 1 if the endpoints support it.
range (see "preferences/Traffic Port Management/Destination Port
Conf Option" and "preferences/Test Controler/First Destination
Port" so that correct destination port for test traffic is used.
NOTE: in preferences Skype4B has its own port management con-
trol:
Preferences/Traffic Port Management/Destination Port Conf Option
If Use Skype4B Special Range option is set to 1 this will take pre-
cedence over the default port management for Skype4B tests (only
for Skype4B tests).
Traffic Mix – HTTP – Video - Voice
Description Traffic Mix. Emulates three different traffic types. Measures voice,
video and HTTP metrics.

Hawkeye Test types
Traffic Mix – HTTP – Video - Voice
Purpose This can simulate three traffic types through network with one
test.
Available Test duration, Total bitrate voice from->to, and Total bitrate HTTP
Options from->to.
Metrics HTTP throughput (Kbpa)

HTTP Transactions per sec
Delay video (ms)
Jitter video (ms)
Loss video
Max loss burst video
Throughput Video (kbps)
Total Bytes Lost Video
Delay voice (ms)
Jitter voice (ms)
Loss voice (ms)
Max Loss Burst voice (ms)
MOS
Advanced This test uses pre-defined configurations for Video and Voice
Information codec traffic.
Results inter- This test generates test metrics for HTTP/Video/Voice.

pretation
Potential If test result pair cannot be collected:

Errors l Ensure that your E2 endpoint can open 10115 port toward E1
l Ensure that ports for video and voice are open.

Hawkeye Test types
Real Time Transactional Applications Tests

Transactional application tests are all based on the same principle:
Tests consist of a number of transactions between endpoints based on a defined network

pattern.
The unitary transaction consists on exchange of information - typically from client (E1,
or endpoint from) to server (E2, endpoint to).
This transaction is based on simple exchange (one GET and file reception) or multiple
exchange.
The defined throughput will take into account TOTAL throughput on both sides (adding
upstream and downstream traffic) and is mostly used to limit the impact on transactions
on the network.
TCP response time
Description simple transaction (one packet) with get from client (endpoint
from) and response from server (endpoint to)
Purpose Measure simple TCP response time and / or transaction rate.

Allows to understand response time for TCP very simple trans-
actions on network.
Available Test duration , DSCP setting

Options
Metrics Response time Average (ms)

throughput (kbps)
Transaction rate (per second)
Advanced This test sends tcp sync and waits for response.
Information then 100 bytes are sent E1 to E2 and 100 bytes are sent from E2 to
E1. Typically only 2 packets are exchanged for full transaction.

Hawkeye Test types
TCP response time
Results inter- The response time is the expected time to transfer very simple
pretation packets in both directions into 2 payloads with TCP. In case of
retransmissions the response time will increase significantly.
By default no objective is set to throughput : any result is good
enough as total throughput should reflect response time and trans-
action rate (transaction rate is 1/response time).
http/https response time
Description http or https transactions from E1 (client ) to E2 (server) - down-

load file or gif
Purpose Measure simple TCP response time and / or transaction rate for
http requests. Request is 300 bytes, response is 25 kbytes which
is size of typical web page.
Available Test duration ,

Options Test bit rate,
http format (txt or gif)

throughput (kbps)

Hawkeye Test types
http/https response time
Advanced Synthetic transactions are simulated between E1 and E2 repro-

Information ducing http or https traffic with same network pattern and footprint
to measure network capability to transport this type of traffic.
Results inter- The response time is the expected time to transfer web page.
pretation By default no objective is set to throughput : any result is good
pop3/smtp response time
Description pop3 or smtp transactions from E1 (client ) to E2 (server) - down-

load file or gif
pop3 or smtp requests. E1 is email client, E2 is email server. The
traffic reproduces synthetic transactions.

Options Test bit rate

throughput (kbps)

Hawkeye Test types
pop3/smtp response time

Information ducing pop3 or smtp traffic with same network pattern and foot-
print to measure network capability to transport this type of traffic.
Results inter- The response time is the expected time to transfer email.
ftp response time
Description ftp transactions from E1 (client ) to E2 (server) - download or

upload file of 100kbytes
FTP requests. E1 is ftp client, E2 is ftp server. The traffic repro-
duces synthetic transactions.

ftp get or ftp put

throughput (kbps)

Hawkeye Test types
ftp response time

Information ducing ftp traffic with same network pattern and footprint to meas-
ure network capability to transport this type of traffic.
File size for transactions is 100 kbytes
Results inter- The response time is the expected time to transfer ftp file.
DNS response time
Description DNS transactions from E1 (client ) to E2 (server)
DNS requests. E1 is DNS client, E2 is DNS server. The traffic repro-
duces synthetic transactions.
Available Test duration,


throughput (kbps)

Hawkeye Test types
DNS response time

Information ducing DNS queries with same network pattern and footprint to
measure network capability to transport this type of traffic.
Results inter- The response time is the expected time to accomplish DNS
pretation request.
Exchange traffic
Description Exchange protocol transactions from E1 (client) to E2 (email

server)
Purpose Measure simple Exchange transactions based on sending and

receiving traffic from remote site to central site hosting server.
Available Number of users

Options Send traffic bitrate
Receive traffic bitrate
Emails size (sent)
Emails size (Received)
NOTE:the total throughput is distributed amongst number of users

!

Hawkeye Test types
Exchange traffic
Metrics Per traffic type (sent or received)

Response time Average (ms)
throughput total transactions (kbps) - bidirectional throughput
Total bytes sent and received

Information ducing Exchange messages sent and received. The maximum
throughput is the limit set to allow this traffic to go through on
each direction.
Results inter- The response time is the expected time to transfer email or
pretation received.
SIP response time
Description SIP protocol transactions from E1 (caller) to E2 (call server)
SIP requests. E1 is SIP client, E2 is SIP server. The traffic repro-
duces synthetic transactions that are representative of typical SIP
based functions.

Hawkeye Test types
SIP response time
Available Test duration,

type of SIP transactions:

throughput (kbps)

Information ducing SIP transactions with same network pattern and footprint to
measure network capability to transport this type of traffic.
Results inter- The response time is the expected time to accomplish SIP trans-
pretation action.
Multicast video over RTP
Description Broadcast of RTP (over UDP) video stream to single.
Purpose Broadcast of video stream to single (node to node test) or multiple

probes (hub and spoke mesh test).

Hawkeye Test types
Multicast video over RTP
Available define multicast source IP address and port. Configure stream bit
Options rate
Metrics Datagrams out of order

Delay
Jitter
Loss throughput video rate
Total bytes lost
Advanced Can be used for N2N or Mesh tests.Only available for hub and
Information spoke mesh.
Results inter- Confirm all probes receive video stream at acceptable rate and
pretation quality.
Potential port blocked errors.
Errors
Speedtest from->to
Description Determines average speed between two endpoints in one direction

(upload).
Purpose Performs TCP traffic using several TCP pairs. The test attempts to
generate as much TCP throughput as possible using several TCP
streams. The average throughput is reported.
Available Test duration (sec)

Options Specify which QOS (DSCP setting) to request between switches in
network.
Number of pairs

Hawkeye Test types
Speedtest from->to
Metrics Identifies from IP address

Identifies to IP address
Average TCP throughput (Kbps) in one direction
Advanced If the test duration is too short the time taken to ramp up TCP
Information throughput will reflect in a lower average throughput rate. The end-
point establishes multiple connections with the server over TCP
port. An initial chunk of data is sent. The endpoint then adjusts the
chunk size and buffer size based on TCP metrics to maximize
usage of the network connection. As the chunks are received by
the other endpoint, the endpoint will request more chunks through-
out the duration of the test. During the initial stages of the test,
the endpoint will establish extra TCP connections (streams) to the
other endpoint if it determines additional threads are required to
more accurately measure the throughput speed.
Results inter- Speed test between endpoints.

pretation
Potential See Common Errors - Real Services
Errors
Speedtest to->from

(download).

Hawkeye Test types
Speedtest to->from

network.
Number of pairs

Information throughput will reflect in a lower average throughput rate.
The endpoint establishes multiple connections with the server
over TCP port. An initial chunk of data is sent. The endpoint then
adjusts the chunk size and buffer size based on TCP metrics to
maximize usage of the network connection.
As the chunks are received by the other endpoint, the endpoint
will request more chunks throughout the duration of the test.
During the initial stages of the test, the endpoint will establish
extra TCP connections (streams) to the other endpoint if it determ-
ines additional threads are required to more accurately measure
the throughput speed.

pretation
Errors
Speedtest bidir
Description Determines average speed between two endpoints in both dir-

ections

Hawkeye Test types
Speedtest bidir

network.
Number of pairs


pretation
Errors

Hawkeye Test types
Speedtest from->to 2 COS

(download) using two Class of Service (COS) TCP streams.
streams. The average throughput is reported. Each of the two TCP
streams will be using a different QOS setting impacting priority of
data packets and across the network which will be reflected in
throughput.

network.
Number of pairs

Average TCP throughput (Kbps) in one direction for each COS.

Hawkeye Test types
The lower the COS number the lower the priority of the TCP stream
(QOS).
The software endpoint is dependent upon endpoint base OS to add
COS to ipV4 packets and it is possible the base OS (particularly if
windows) will not always do this. Additionally, COS is layer 2
traffic, just the ToS 1 byte value in the IP header.
QOS is layer 3 traffic where COS and traffic type
are both taken into consideration.

pretation
Errors

(download) using three Class of Service (COS) TCP streams.

Hawkeye Test types
streams. The average throughput is reported. Each of the three
TCP streams will be using a different QOS setting impacting pri-
ority of data packets and across the network which will be reflec-
ted in throughput.

network.
Number of pairs


Hawkeye Test types
(QOS).

pretation
Errors

(download) using four Class of Service (COS)

Hawkeye Test types
streams. The average throughput is reported. Each of the four TCP
throughput.

network.
Number of pairs


Hawkeye Test types
(QOS).

pretation
Errors

(download) using five Class of Service (COS)

Hawkeye Test types
streams. The average throughput is reported. Each of the five TCP
throughput.

network.
Number of pairs


Hawkeye Test types
(QOS).

pretation
Errors
DSCP (QOS) settings explained

Hawkeye implements Class of Service based on DSCP setting. The following table
details table name and different settings (as explained in following section) cor-
respondence.

Hawkeye Test types
DS- DS- DS- DS- To- To- ToS To- To- To- ToS ToS TOS String
CP CP CP CP S S (bin) S S S Throg- Reli- Format
Cl- (bi- (h- (d- (d- (h- Pr- Pr- De- hput abil-
as- n) e- e- e- e- e- e- lay Flag ity
s x) c) c) x) c. c. Fla- Flag
(b- (d- g
i- e-
n) c)
no- 000- 0×- 0 0 0×- 0000- 00- 0 0 0 0 Routine

ne 000 00 00 0000 0
cs- 001- 0×- 8 32 0×- 0010- 00- 1 0 0 0 Priority

1 000 08 20 0000 1
af- 001- 0×- 10 40 0×- 0010- 00- 1 0 1 0 Priority

11 010 0A 28 1000 1
af- 001- 0×- 12 48 0×- 0011- 00- 1 1 0 0 Priority

12 100 0C 30 0000 1
af- 001- 0×- 14 56 0×- 0011- 00- 1 1 1 0 Priority

13 110 0E 38 1000 1
cs- 010- 0×- 16 64 0×- 0100- 01- 2 0 0 0 Immediate

2 000 10 40 0000 0
af- 010- 0×- 18 72 0×- 0100- 01- 2 0 1 0 Immediate

21 010 12 48 1000 0
af- 010- 0×- 20 80 0×- 0101- 01- 2 1 0 0 Immediate

22 100 14 50 0000 0
af- 010- 0×- 22 88 0×- 0101- 01- 2 1 1 0 Immediate

23 110 16 58 1000 0
cs- 011- 0×- 24 96 0×- 0110- 01- 3 0 0 0 Flash

3 000 18 60 0000 1

Hawkeye Test types
af- 011- 0×- 26 10- 0×- 0110- 01- 3 0 1 0 Flash

31 010 1A 4 68 1000 1
af- 011- 0×- 28 11- 0×- 0111- 01- 3 1 0 0 Flash

32 100 1C 2 70 0000 1
af- 011- 0×- 30 12- 0×- 0111- 01- 3 1 1 0 Flash

33 110 1E 0 78 1000 1
cs- 100- 0×- 32 12- 0×- 1000- 10- 4 0 0 0 FlashOver-

4 000 20 8 80 0000 0 ride
af- 100- 0×- 34 13- 0×- 1000- 10- 4 0 1 0 FlashOver-

41 010 22 6 88 1000 0 ride
af- 100- 0×- 36 14- 0×- 1001- 10- 4 1 0 0 FlashOver-

42 100 34 4 90 0000 0 ride
af- 100- 0×- 38 15- 0×- 1001- 10- 4 1 1 0 FlashOver-

43 110 26 2 98 1000 0 ride
cs- 101- 0×- 40 16- 0x- 1010- 10- 5 0 0 0 Critical

5 000 28 0 A0 0000 1
ef 101- 0×- 46 18- 0x- 1011- 10- 5 1 1 0 Critical

110 2E 4 B8 1000 1
cs- 110- 0×- 48 19- 0x- 1100- 11- 6 0 0 0 Inter-

6 000 30 2 C0 0000 0 net-
workcontrol
cs- 111- 0×- 56 22- 0x- 1110- 11- 7 0 0 0 Net-

7 000 38 4 E0 0000 1 workcontrol
Details on Class of Service - different standards

IP TOS
The type-of-service (TOS) byte in an IP header specifies traffic precedence and type of
service (as defined in RFC 791 and RFC 1349). Figure 9-1 shows the TOS byte in the IP
header.

Hawkeye Test types
The precedence field comprises the first three bits and supports eight levels of priority.
The lowest priority is 0, the highest is 7 (values 6 and 7 are reserved for network control
packets).
The precedence field setting
The four bits following the precedence field specify the type of service. Only one of
these bits can be enabled at one time. Each bit defines the desired type of service:
l D – The delay bit instructs network devices to choose high speed to minimize
delay.
l T – The throughput bit specifies high capacity links to ensure high throughput.
l R – The reliability bit specifies that reliable links should be used to minimize data
loss.
l C – The cost bit specifies that data transmission should be accomplished at min-
imal cost.
The last bit in the TOS byte is reserved and is always set to 0.
On Microsoft Windows Server 2008 (32- and 64-bit) and on Microsoft Win-
dows Vista (32- and 64-bit), IP TOS can be set only via qWave tem-
plates. If endpoints are used on these types of Operating systems,

Hawkeye Test types
qwave needs to be installed so that the endpoint can tag with correct
TOS.
DiffServ
Differentiated Services (DiffServ) is a QoS model defined by the IETF for IP networks
(refer to RFC 2474). This model is designed to be scalable and to provide consistent ser-
vice classes independent of application. DiffServ redefines the TOS byte of the IP
header (see Figure 9-1) as the DS field.
The first six bits of the DS field are used as a differentiated service code point (DSCP),
and the last two bits are currently unused (CU).
In the DiffServ QoS model, traffic is classified by marking the DS field with a DSCP
value. Queuing mechanisms provide differentiated forwarding of the traffic at each hop,
based on the DSCP value.
On Microsoft Windows Server 2008 (32- and 64-bit) and on Microsoft Win-
dows Vista (32- and 64-bit), IP TOS can be set only via qWave tem-
plates. If endpoints are used on these types of Operating systems,
qwave needs to be installed so that the endpoint can tag with correct
DSCP.
Per-Hop Behavior (PHB)

The DSCP selects the Per-Hop Behavior (PHB) that a packet experiences at each node.
RFC 2474 defines PHB as the externally observable forwarding behavior applied at a
DiffServ-compliant node to a DiffServ Behavior Aggregate.
There are currently four standard PHBs:
l Default ("Best Effort") PHB (as defined in RFC 2474)

l Class-Selector PHB (as defined in RFC 2474)

Hawkeye Test types
l Assured Forwarding (AF) PHB (as defined in RFC 2597)

l Expedited Forwarding (EF) PHB (as defined in RFC 2598).
Default PHB
RFC 2474 recommends codepoint 000000 as the Default PHB.
Class-Selector PHBs
RFC 2474 defines 21 codepoints, including the Class-Selector PHBs listed below:
Assured Forwarding (AF) PHB

The Assured Forwarding (AF) PHB group provides delivery of IP packets in N inde-
pendently forwarded AF classes. Within each AF class, an IP packet can be assigned one
of M different levels of drop precedence. Currently, four classes with three levels of drop
precedence in each class are defined for general use. (Additional AF classes or levels of
drop precedence may be defined for local use.)
RFC 2597 recommends the codepoints described below.

Hawkeye Test types
This table shows each of the AFMN bit values, where M is the AF class and N is the drop
precedence. In list form, these are:
AF11 = 001010
AF12 = 001100
AF13 = 001110
AF21 = 010010
AF22 = 010100
AF23 = 010110
AF31 = 011010
AF32 = 011100
AF33 = 011110
AF41 = 100010
AF42 = 100100
AF43 = 100110
Expedited Forwarding (EF) PHB

RFC 2598 defines the EF PHB as a as a PHB that can be used to build a low loss, low
latency, low jitter, assured bandwidth, end-to-end service through DS domains. RFC
2598 recommends codepoint 101110 as the default EF PHB.

Hawkeye Test types
Common Errors - N2N

Errors received for Node-to-Node and mesh tests
If you encounter problems while running node-to-node and mesh tests, they're probably
related to failed connections, to the communications software in your network, or to the
way you've configured your tests. Hawkeye messages offer information to help you
understand why errors occur and guidance to help you avoid them in the future.
The following topics will help you find the information necessary to solve problems you
encounter.
Investigate which probe detected the error

The first step in troubleshooting is usually determining which probe detected the error.
All Operator Actions described by the message help should be taken at the computer
that detected the error, unless otherwise specified.
For most errors involving setup and file manipulation, the Test Agent is the computer
that detects the error.
For errors that occur while running a test, the error could have been detected on a par-
ticular endpoint pair by the Test Agent, by Endpoint 1, or by Endpoint 2. The program
that detects the error reports to the Test Agent, which shows the error and logs it. The
first line of the Test Agent error message tells which endpoint probe detected the error.
If for some reason you cannot see the error at the Test Agent, examine the error log at
the endpoints involved in the problem. A formatted error log entry should contain a line
that resembles the following:
Some pairs in tests didnt complete
One of the following reason explains the situation
l Hawkeye test engine started the test but had to abandon at result collection
l Your test generates too much traffic on the link and the first result collection is
never happening as result collection intervals depend on requested traffic : this
would result into Hawkeye timing out test execution.
l => Solution: Start a test with low traffic between endpoints.
l Check firewall NAT rules between endpoints : this can be test path not opened on
ports, can be E2 unable to reach E1 on port 10115 (you need that for the tests)

Hawkeye Test types
l => Solution: open relevant ports. Force user traffic to use specific port from
Hawkeye (preferences, test agent tab)
l Endpoint process in bad state : this happens sometimes on linux when there was a
problem with a test.
l Solution=> Restart the endpoint process on the probes (/etc/init.d/endpoint stop;
/etc/init.d/endpoint stop). For hardware probes you can do that from the probe
management / probe remote management menu of Hawkeye. There is also an auto-
matic endpoint cleanup process that would do that every hour per default. A hard
reboot on the probe also does the job.
l Hawkeye test engine gets stuck at test initialization stage:
l Port 10115 udp must be opened both ways between probes for sync.
l Endpoint process in bad state: same solution than above
Error was detected by Endpoint 1
If the error was detected by Endpoint 1 or Endpoint 2, check the test setup at the Test
Agent to determine the actual network address of the probe where the error was detec-
ted.
Although one probe may detect an error, the solution may actually lie elsewhere. For
example, if Endpoint 1 detects an error indicating that a network connection could not
be established, it may be because of a configuration error in the middle of the network
at Endpoint 2, or between Endpoint 1 and Endpoint 2.
Reading error messages

Hawkeye errors are reported in the GUI in the “Reason cause” column of the “Test res-
ults list” table. Below is an example of error received when one of the test ports was
used by another application:

Hawkeye Test types
- The first lines of the error message shows the timestamp when the error was detected
and received;
- The next lines tell you which endpoint detected the error, the error number and error
explanation together with other error details.
Below, is an explanation of the error codes received in Hawkeye, when running node-to-
node or mesh tests:
Code Type Reason
CHR0200 Error Connection attempt timed out
CHR0204 Error No endpoint program is installed on partner computer/probe
CHR0206 Error Cannot complete scripts because the assigned port is already
in use
CHR0225 Error The TCP address is unreachable- the endpoint or phone is

unavailable. Check connectivity to the endpoint
CHR0264 Error RUNTST cannot run while the Test Agent is loaded. The
RUNTST program is installed at the Test Agent in the \Ixi-
a\Hawkeyegram folder

Hawkeye Test types
CHR0335 Warning A timing record was received with a measured time of 0 mil-
liseconds.
A script command was performed in less than one millisecond,
an insignificant amount of time
CHR0336 Warning A timing record was received with a measured time between 1
and 20 milliseconds. The clock timers used in timing scripts are
generally accurate to within 1 millisecond (ms). For most tests,
this is more than sufficient, but if the transactions in a test are
too short, problems may arise
CHR0337 Warning More than 500 timing records per pair were generated in Batch
Reporting Mode. Excessive timing records create extra traffic
on the line and interfere with performance results
CHR0338 Warning The test has run for less than 1 second while collecting end-
point CPU utilization. Meaningful data on CPU utilization at the
endpoints cannot be collected unless the test runs for a longer
period of time
Common problems
High-Precision Timer (CHR0359 error)
If you attempt to execute a VoIP or streaming pair test and you receive a CHR0359 error
message (An error was detected in the high precision timer), you may be able to resolve
the issue by following the instructions given in the Microsoft Knowledge Base article
entitled "Programs that use the QueryPerformanceCounter function may perform poorly
in Windows Server 2000, in Windows Server 2003, and in Windows XP". You can either
search for the article by name or reference it at this address: http://sup-
port.microsoft.com/kb/895980.
Insufficient Resources
If you receive an Insufficient Resource error while running node-to-node/mesh tests, the
test agent computer does not have access to the amount of memory required to suc-

Hawkeye Test types
cessfully run these tests. Close other applications that currently run and restart the
tests.
Insufficient Threads
The Hawkeye Test Agent creates one or more threads for each endpoint pair when run-
ning a test. This is in addition to the threads created by the underlying network software
(as well as those used by other concurrently-running applications).
In our testing, we did not exhaust threads in our default settings for Windows NT or Win-
dows 2000/2003 until we reached about 7000 threads. We don't believe you'll encounter
out-of-threads problems, but please let us know if you do.
Protection Faults and Traps
Protection faults or traps are the operating system's way of telling you when a program
is trying to use memory that it doesn't own. They can occur in an Hawkeyegram, in any
library routines called by Hawkeye, or in the operating system itself. The default way
that they're handled is with a message box. This message box shows program instruc-
tion values in hex, which aren't helpful to you as a user.
l If you are using Windows NT, Windows 2000/2003, or Windows XP:
Windows NT, Windows 2000/2003, and Windows XP write an entry to a file named drwts-
n32.log when they encounter a trap or protection fault. This file is written to the dir-
ectory where you installed Windows. Its default location is c:\Winnt. It contains
information that is immensely helpful to us in finding and fixing bugs. When you contact
the Technical Support team, they may suggest that you send the Dr. Watson file to us
via email.
Full List of Error Messages

Click here to view the full list of error messages.
Default Number of Tests per probe type (N2N)

Queue Management Concept
While trying to execute the tests configured by the users and scheduled on the system,
the scheduler will follow following rules:

Hawkeye Test types
l pick first tests that are earlier in Next Execution time

l give priority to Mesh tests in Meshes that are left to complete (see Mesh tests for
details)
l give priority to One shot tests over scheduled tests
l Check probe execution capability and:
l do not allow to run 2 different test types at the same time on same
probe
l allow running simultaneous tests on same probe only in same test run
(once a probe is running it cant be used for other tests even if this is
same test type.
l max total number of tests per probe depends on probe type and test
type. See table below.
How is a probe identified

A probe is by default identified by its Serial Number. If this is empty and Use probe Man-
agement IP is defined (should be default), probes with same management IP will be iden-
tified as sharing same hardware.
This configuration is useful when using several interfaces on same probe and allows to
gave probe control management.

Hawkeye Test types
Maximum number of simultaneous tests per probe type

and test type
Table below displays the number of max concurrent tests that are allowed on one probe
to run.
These metrics can be modified by advanced administrator - contact support for advise
and recommendations.
Test Type Probe Type Number of Tests
COS line qualification Software 1
COS line qualification xr2000 1
COS line qualification xr2000_vm 1
COS line qualification xr_pi 1
DNS Response Time Software 200
DNS Response Time xr2000 200
DNS Response Time xr2000_vm 200
DNS Response Time xr_pi 20
Exchange_traffic Software 1
Exchange_traffic xr2000 1
Exchange_traffic xr2000_vm 1
Exchange_traffic xr_pi 1
FTP Response Time Software 5
FTP Response Time xr2000 5
FTP Response Time xr2000_vm 5

Hawkeye Test types
FTP Response Time xr_pi 5
HTTP Test Software 5
HTTP Test xr2000 5
HTTP Test xr2000_vm 5
HTTP Test xr_pi 5
HTTPS Test Software 5
HTTPS Test xr2000 5
HTTPS Test xr2000_vm 5
HTTPS Test xr_pi 5
LDAP Response Time Software 5
LDAP Response Time xr2000 5
LDAP Response Time xr2000_vm 5
LDAP Response Time xr_pi 5
Skype4B Traffic Software 20
Skype4B Traffic xr2000 80
Skype4B Traffic xr2000_vm 80
Skype4B Traffic xr_pi 8
Skype4B Traffic from->to Software 40
Skype4B Traffic from->to xr2000 160
Skype4B Traffic from->to xr2000_vm 160
Skype4B Traffic from->to xr_pi 16

Hawkeye Test types
Network KPI Software 100
Network KPI xr2000 500
Network KPI xr2000_vm 500
Network KPI xr_pi 50
Network KPI 3 COS Software 5
Network KPI 3 COS xr2000 125
Network KPI 3 COS xr2000_vm 125
Network KPI 3 COS xr_pi 12
Network KPI Advanced Software 80
Network KPI Advanced xr2000 320
Network KPI Advanced xr2000_vm 320
Network KPI Advanced xr_pi 32
Network KPI bidirectionnal Software 50
Network KPI bidirectionnal xr2000 250
Network KPI bidirectionnal xr2000_vm 250
Network KPI bidirectionnal xr_pi 25
Network KPI Upstream Software 100
Network KPI Upstream xr2000 500
Network KPI Upstream xr2000_vm 500
Network KPI Upstream xr_pi 50
POP3 Response Time Software 5

Hawkeye Test types
POP3 Response Time xr2000 5
POP3 Response Time xr2000_vm 5
POP3 Response Time xr_pi 5
SIP Response Time Software 5
SIP Response Time xr2000 5
SIP Response Time xr2000_vm 5
SIP Response Time xr_pi 5
SMTP Response Time Software 5
SMTP Response Time xr2000 5
SMTP Response Time xr2000_vm 5
SMTP Response Time xr_pi 5
TCP Response Time Software 200
TCP Response Time xr2000 200
TCP Response Time xr2000_vm 200
TCP Response Time xr_pi 20
TCP Throughput Advanced Software 1
TCP Throughput Advanced xr2000 1
TCP Throughput Advanced xr2000_vm 1
TCP Throughput Advanced xr_pi 1
TCP Throughput bidirectional Software 1
TCP Throughput bidirectional xr2000 1

Hawkeye Test types
TCP Throughput bidirectional xr2000_vm 1
TCP Throughput bidirectional xr_pi 1
TCP Throughput from->to 1 stream Software 1
TCP Throughput from->to 1 stream xr2000 1
TCP Throughput from->to 1 stream xr2000_vm 1
TCP Throughput from->to 1 stream xr_pi 1
TCP Throughput from->to N streams Software 1
TCP Throughput from->to N streams xr2000 1
TCP Throughput from->to N streams xr2000_vm 1
TCP Throughput from->to N streams xr_pi 1
TCP Throughput Optimized Window size Software 1
TCP Throughput Optimized Window size xr2000 1
TCP Throughput Optimized Window size xr2000_vm 1
TCP Throughput Optimized Window size xr_pi 1
TCP Throughput to->from 1 stream Software 1
TCP Throughput to->from 1 stream xr2000 1
TCP Throughput to->from 1 stream xr2000_vm 1
TCP Throughput to->from 1 stream xr_pi 1
TCP Throughput to->from N streams Software 1
TCP Throughput to->from N streams xr2000 1
TCP Throughput to->from N streams xr2000_vm 1

Hawkeye Test types
TCP Throughput to->from N streams xr_pi 1
Traffic Mix - HTTP - Video - Voice Software 1
Traffic Mix - HTTP - Video - Voice xr2000 1
Traffic Mix - HTTP - Video - Voice xr2000_vm 1
Traffic Mix - HTTP - Video - Voice xr_pi 1
UDP Throughput Advanced Software 1
UDP Throughput Advanced xr2000 1
UDP Throughput Advanced xr2000_vm 1
UDP Throughput Advanced xr_pi 1
UDP Throughput bidirectional Software 1
UDP Throughput bidirectional xr2000 1
UDP Throughput bidirectional xr2000_vm 1
UDP Throughput bidirectional xr_pi 1
UDP Throughput from->to Software 1
UDP Throughput from->to xr2000 1
UDP Throughput from->to xr2000_vm 1
UDP Throughput from->to xr_pi 1
UDP Throughput from->to - 4 COS Software 1
UDP Throughput from->to - 4 COS xr2000 1
UDP Throughput from->to - 4 COS xr2000_vm 1
UDP Throughput from->to - 4 COS xr_pi 1

Hawkeye Test types
UDP Throughput to->from Software 1
UDP Throughput to->from xr2000 1
UDP Throughput to->from xr2000_vm 1
UDP Throughput to->from xr_pi 1
Video Stream Software 1
Video Stream xr2000 1
Video Stream xr2000_vm 1
Video Stream xr_pi 1
Voice bidirectional Software 10
Voice bidirectional xr2000 200
Voice bidirectional xr2000_vm 200
Voice bidirectional xr_pi 20
Voice from->to Software 50
Voice from->to xr2000 500
Voice from->to xr2000_vm 500
Voice from->to xr_pi 50
Voice N pairs - UDP Data bidirectional Software 1
Voice N pairs - UDP Data bidirectional xr2000 1
Voice N pairs - UDP Data bidirectional xr2000_vm 1
Voice N pairs - UDP Data bidirectional xr_pi 1
Voice N Pairs bidirectional Software 1

Hawkeye Test types
Voice N Pairs bidirectional xr2000 1
Voice N Pairs bidirectional xr2000_vm 1
Voice N Pairs bidirectional xr_pi 1
Voice N Pairs Unidirectional Software 1
Voice N Pairs Unidirectional xr2000 10
Voice N Pairs Unidirectional xr2000_vm 10
Voice N Pairs Unidirectional xr_pi 1
Real Services
Real service testing is performed between the testing probe (acting as a client) and a
server on the network, most of the time in the public Internet.
The probe will access the service and compute key performance indicators for the test.
These tests perform application performance testing: they measure network quality but
also application performance.

Hawkeye Test types
For distributed sites real service testing, the following endpoints support real service
tests:
l xr2000 hardware endpoint

l xrpi2 hardware endpoint
l xr2000 virtual probe in virtual machine
Prerequisites
It is also important to take into account that a lot of the real service tests are done to
the public services, therefore they will only be available if the endpoint has access to
public internet. DNS settings are set so that public IP addresses can be resolved.

Hawkeye Test types
Test types
Bittorrent test
Description Start Downloading a torrent from torrent client-

THIS TEST IS ONLY SUPPORTED ON XR2000, NOT ON XRPi
Purpose Measures Throughput at which a file can be downloaded from a

peer-to-peer network
Available Torrent name (simply for display reasons, not used in test)
Options magnet link: is the torrent file url that the probe needs to down-
load to get access to torrent.
Example=
http://releases.ubuntu.com/14.10/ubuntu-14.10-desktop-
amd64.iso.torrent
Test duration: torrent download duration - after this duration tor-
rent download will stop and result printed out even if torrent is not
fully downloaded.
Metrics downloaded Size: size downloaded during allocated time

Filename: name of the file associated to torrent
Filesize: file size as published by the torrent
Throughput: throughput rate during the time allocated for down-
load
Advanced this test aims at proving capability to do peer to peer traffic from
Information the probe and identify the relevant max throughput.
It is recommended to use popular torrent files so that the results
are significant.
Results inter- See advanced information.

pretation
Potential See Common Errors - Real Services.htm

Errors

Hawkeye Test types
DNS test
Description Test against DNS server and verify the time it takes to resolve IP
address
Purpose Validate performance of DNS resolution (in response time) for spe-
cified server and
Available url to resolve

Options DNS server (default or empty: will use default DNS server as pro-
visioned on probe)
Metrics DNS resolution Availability (1 for available, 0 for not available)

DNS Response time (msec)
DNS server IP
Resolved Addresses (one or several addresses resolved for url)
Advanced This test will verify availability and response time of DNS service
Information from probe or specific DNS server response time
Results inter- A long response time from DNS by default can result into bad user
pretation experience and therefore should be monitored closely
Potential See Common Errors - Real Services in Error Description Guide.

Errors
Dropbox upload/download
Description Download or upload a file on dropbox account
Purpose Measures user experience sharing files on dropbox service
Available File (file size)

Options Timeout
Metrics Download or upload rate

Download time
File size

Hawkeye Test types
Dropbox upload/download
Advanced The files are provided by default. The dropbox account is a ded-
Information icated test account provided by Ixia.

pretation
Errors
Email
Descrip- Send and receive email from same or different email accounts
tion
Purpose Measures The time taken to relay an email via the configured SMTP
servers and reaching a target mail server
Available Account information for sending and receiving email:

Options
Metrics Delay (ms) for receiving the email
Advanced The settings for email servers (SMTP and IMAP/POP) need to be con-
Inform- figured for both accounts.
ation The resolution for relaying tome (delay) is to the second. This is by
nature of the email clients that can poll received emails at second rate
minimum.

Hawkeye Test types
Email
Results See advanced information.

inter-
pretation
Errors
FTP download
Description FTP server test with login, password and download file
Purpose Test user experience downloading files from FTP server. The file
downloaded needs to be on the FTP server.
Available test Timeout (sec)

Options FTP Server address or url
File to download
Authentication mode
FTP mode (active/passive)
Username
Password
Metrics Download File size

Download Time
Download bitrate
Advanced This test will download the FTP file as fast as possible from the
Information server to the probe.
Results inter- This is user experience from probe to download file from specificed
pretation FTP server
If ftp not downloaded before end of timeout defined then the test
will error out.

Hawkeye Test types
FTP download
Errors
FTP multistream download
Description FTP server test with login, password and download file - adding a
parameter to enable multiple concurrent streams download.
Purpose Test user experience downloading files from FTP server. The file
downloaded needs to be on the FTP server. The experience will be
enhanced by multiple parallel streams. If the FTP server access is
good enough, multiple FTP download streams are supposively
filling up the transport pipe.
Available test Timeout (sec)

Options FTP Server address or url
File to download
Authentication mode
FTP mode (active/passive)
Username
Password
Number of Streams : number of parallel streams the FTP will use
Metrics Download File size

Download Time
Download bitrate
Advanced
Information
Results inter-
pretation

Hawkeye Test types
FTP multistream download
Errors
HTTP response time
Description Download HTML content from the input url
Purpose check availability of a webpage, check time to download content,

compare TCP response time with application level content down-
load time
Available Servers address or url - the list can contain up to 10 different serv-
Options ers
IPV4 or IPV6
Protocol http (0) or https (1)
Number of tests to execute in same batch
DSCP setting
Metrics Per Web server:

Application latency (ms) – calculated as the time between end-
point issues the HTTP/Get and the time endpoint receives the first
datagram from the server
Number of Bytes received from server (size of the url html)
TCP latency (ms) – calculated as the time between endpoint
issues [SYN] and the time endpoint receives [SYN, ACK]
Total download time (ms) – calculated as the time between end-
point issues [SYN] and the time endpoint receives the last data-
gram [FIN.ACK] from server
Resolved IP address for server

Hawkeye Test types
HTTP response time
Advanced This test will try to download http content on a url. It will simply
Information analyse result of the HTTP GET content - if a HTTP response code
differs from 200 information will be displayed (eg REDIRECT)
When http code is different from 200 no html is received.
It is important to understand the difference between abso-
lute URL’s and relative URL’s.
An absolute URL takes the form protocol://domain/path,
such as www.<domain name>.com, which will map spe-
cifically to https or http protocol. A relative URL like
<domain name>.com can be redirected to either http or
https. If test fails due to protocol error the test result
reason code will advise user to change ip protocol con-
figured for test.
Results inter- The test is useful to understand TCP response time (network) to
pretation full html download (server reponse time)
Errors
HTTP Server test
Description Download http pages full content from one or several servers and
provide statistics about content and response time
Purpose Get user experience information downloading the web page con-
tent. this will include all images and javascript/css etc...
Other information like DNS resolution will help correlate user
experience to CDN (Content Data Network) architecture.
Available Servers address or url

Options Download all page or only html content
IPV4 or IPV6

Hawkeye Test types
HTTP Server test
Metrics Per Web server:

Download time
Download size
Download bitrate
Total File download size
time to first byte (max for all elements in page)
time to first byte (avereage for all elements in page)
Number of files in page
Resolved DNS address for http server
Advanced This test will download elements in a web page providing user
Information experience getting information from the associated url. This test
will download all elements in page (unless setting prevents it).
figured for test.
URL may have multiple components to download, such as web
page, scripts, images, style sheets. Multiple components will
involve creating multiple TCP streams for the complete download.
When only the page is selected for the download, the Initial time
taken to setup connection is excluded from download time. Down-
load time will solely reflect the actual download of the page. This
means wireshark trace calculating time between first and last
packet will be wrong. Following is the formula for calculating Down-
load time.
Download time = (Download Size * 8 / KBitRate per sec)
Results inter- The result should be reflective as the user experience getting from
pretation a browser to the web page.

Hawkeye Test types
HTTP Server test
Errors
HTTP Server test-advanced
Description Download http pages full content from one or several servers and
provide statistics about content and response time- provides
advanced information with full list of downloaded objects
Purpose Get user experience information downloading the web page con-
tent. this will include all images and javascript/css etc...
Other information like DNS resolution will help correlate user
experience to CDN (Content Data Network) architecture.
Available Servers address or url

Options Download all page or only html content
IPV4 or IPV6
Metrics Per Web server and element:

Download time
Download size
Download bitrate
Total File download size
time to first byte (max for all elements in page)
time to first byte (avereage for all elements in page)
Number of files in page
Resolved DNS address for http server
Per web page element:

Download time
Download size
Download bitrate

Hawkeye Test types
HTTP Server test-advanced
Advanced This test will download elements in a web page providing user
Information experience getting information from the associated url. This test
will download all elements in page (unless setting prevents it).
figured for test.
Results inter- The result should be reflective as the user experience getting from
pretation a browser to the web page.
Errors
ICMP performance
Description generates ICMP packets at user defined bit rate and look at net-
work bandwidth performance to receive response
Purpose Run quick throughput availability calculation based on ICMP traffic

blasting. Is a way to quickly check the available bandwidth
against a remote device on layer 3 without deploying advanced
endpoints. This test should be considered as a first approximation
to determine obvious bottlenecks.

Hawkeye Test types
ICMP performance
Available Destination servers (IP or url addresses)

Options Generated throughput (ICMP content)
packet sizes(ICMP content)
Class of Service
test duration
Metrics ICMP Packet loss (%)

ICMP throughput (layer 4)
Advanced This test sends ICMP packets at defined bit rate and listens for the
Information received packets throughput.
Number of packets per second is calculated based on send through-
put and packet size.
It is expected that the total bitrate generated will be accurate for
large packet sizes up to 200M for xr2000.
Received throughput will take into account lags into the network
so is expected to be always at least a bit less than the sent rate.
Results inter- A loss rate is likely to impact the total received throughput quite
pretation dramatically. Results will also get more precision if traffic gen-
eration length is longer
Errors
ICMP test
Description generates ICMP ping requests to servers or interfaces
Purpose Validate network response time and key metrics (loss/jit-

ter/response time) through very simple and largely supported
ICMP protocol

Hawkeye Test types
ICMP test
Available List of destination servers (IP or url addresses)

Options interval for icmp packets
number of packets to send
packet sizes
IPV4 or IPV6
Enable Jitter calculation (default yes)
Class of Service
Metrics Packet loss (%)

Round trip average (ms)
Round trip max (ms)
Round trip min (ms)
Standard Deviation (ms)
Jitter (ms)
Jitter max (ms)
Advanced This test sends ICMP packets and listen for responses. The jitter
Information calculation might need to be disabled for small packet sizes.
Results inter- The ICMP packets will detect any obvious issues on the network
pretation (congestions, drops, long response time, instable response time).
It is an interesting data point as a change in the behaviour of an
ICMP test would likely reflect some modification of the network
behaviour. The results should however be interpreted with care as
the ICMP packets are usually treated with lower priority than data
packets by network elements, therefore could show worst behavior
than actual user traffic (prioritized) would experience in some
cases.
Errors

Hawkeye Test types
IGMP test
Description join a multicast channel and analyze received RTP stream- igmp
v2 or v3 will be used depending on the available network.
Purpose will join a channel (if available) and collect broadcasted stream if
available
Available watch duration: time before joining and leaving the stream
Options Probe physical interface:this settingis important as the igmp join
is allocated to physical interface. Can be eth0 or eth1 (port 0 or
port 1)
Multicast address: multicast address for the stream
Source Multicast address: for igmp v3 - will be used to select a
specific source address.
Metrics join latency (ms)

leave latency (ms)
Number Of RTP flows
Average Packet Length
Interpacket arrival average (ms)
Interpacket arrival max (ms)
Interpacket arrival min (ms)
Interpacket arrival standard deviation (ms)
Maximum Loss Burst
Throughput average (kbps)
Total kBytes Received
Total Packets Lossed
Total Packets Received
Total stream duration (sec)
Loss rate
IGMP protocol version
Advanced The RTP stream received is parsed and analyzed. Video is not
Information stored on the probe.
Probe will autodetect igmp version (v2 or v3)
leave Source Multicast address empty for v2 or All sources

Hawkeye Test types
IGMP test

pretation
Errors
Path Discovery
Description Discover paths to a destination
Purpose Uses a combination of traceroute and ping requests to discover

paths from the original probe to the destination server.
Available destination (IP or url addresses)

Options timeout for request (sec)
traceroutes count
traceroute max hops
traceroute protocol (ICMP, TCP or UDP)
destination port
Quality of service (or DSCP setting)
Metrics

Hawkeye Test types
Path Discovery
Advanced Although Path Discovery has no configurable metrics there are cri-
Information teria for Pass/Fail/Error. The criteria for Fail is reached if for all the
last hops the destination is unknown.
The different servers on the path will be identified and multiple
paths to destination can be discovered by increasing the
traceroutes count.
Graph only shows forward routes. It does not show return routes
for any packets used for path discovery. Some nodes may have no
measurements as they are configured not to respond to ping. For
path discovery mechanism, each traceroute is run for one probe
per hop (not as typically the traceroute sends 3 pings or request
per probe).

Hawkeye Test types
Path Discovery
Results inter- There are various options in ‘Test Results’ that can help user to
pretation analyze path discovery results:
l Traceroute – displays the traceroute style output
l Show navigation – (uncheck) enables free zoom/ pan mode
l Frequent path – highlights frequent path and line thickness
will be proportional to frequency
l Loss – if selected, highlights nodes with loss equal or greater
than specified value
l Avg RTT – if selected, highlights nodes with average round
trip delay (RTT) equal or greater than specified value
l Cluster – gives user option to cluster Autonomous Systems
or unknown nodes
l Class of Service (DSCP setting) – identifies where in network
path nodes change the QOS setting
The following information is retrieved and available for display:
Hop info
l IP
l Reverse DNS
l Autonomous System
l ICMP extensions
l QoS Changes
When Hawkeye server is connected to internet, following hop info
are also retrieved
l Network name
l Prefix
l Organization
Metrics
l Frequency
l Min/Avg./Max response time
l Packet loss

Hawkeye Test types
Path Discovery
Errors
Port Scan
Description Determines the state of network ports
Purpose Can be used to ensure services (for example HTTPS, FTP, etc.) are
accessible or blocked by firewalls.
Available destination (IP or url addresses)

Options protocol: TCP or UDP
start port
port count
expected port state
Metrics Open ports – shows how many ports from the configured range are
open. Available for both TCP and UDP
Closed ports - shows how many ports from the configured range
are closed. Available for both TCP and UDP
Filtered ports - shows how many ports from the configured range
are filtered (no replies are received). Available for TCP
Open/Filtered ports - shows how many ports from the configured
range are open/filtered (no replies are received either because of
a firewall or the application listening on the port is not sending any
reply). Available for UDP
Each of these metrics will only show up in result if at least on port
of corresponding state was found.
Advanced
Information

Hawkeye Test types
Port Scan
Results inter- The Port Scan results will reflect an overall test status and the
pretation status of different ranges of ports. For a given range of ports the
Metric column represents the state of the port and the value
column, represents the port number or port range that is in that
state. The Status KPI column represents the comparison with the
actual state of the ports compared to the configured “expected
state” in the test configuration.
The following describes the port state:
l OPEN: The port (TCP or UDP) on the destination is reachable
and we receive reply to our sent packets.
l OPEN/FILTERED: Only applies to UDP ports. If no reply is
received either because the application listening is not reply-
ing or we cannot reach the destination (e.g. due to firewalls
blocking the packets).
l FILTERED: Only applies to TCP ports. If no reply is received
back (e.g. due to firewalls blocking the packets).
l CLOSED: If the port on the destination is reachable (TCP or
UDP) but there is no application listening on destination (i.e.
packets received by destination IP, but packets not pro-
cessed by intended application). Specifically endpoint
received back ICMP Destination Unreachable message.
Errors
Skype Network Connectivity Performance
Description Assesses the set of network performance requirements for Skype

for Business Online services

Hawkeye Test types
Skype Network Connectivity Performance
Purpose Determines the quality of connection between your network and

Skype for Business Online. No actual Skype traffic is exchanged,
just performance measurements across the internet to the Skype
servers.
Available Class of service

Options
Metrics Avg. Jitter

Avg. Round-trip time
Packet loss
The result includes also the path view to get a more clear under-
standing of where performance issues are located. The metrics for
pass/fail criteria are defined by Microsoft so the user cannot define
pass/fail criteria for metrics.
Advanced The test sends 150 ping TCP packets 10 milliseconds apart to
Information World Wide Anycast IP of Skype for Business media relay and com-
pare the measurements against Microsoft requirements.
See Media Quality and Network Connectivity Performance in
Skype for Business Online for more information

pretation
Errors
Speedtest
Description Validate speedtest from probe to speedtest servers
Purpose validate downstream and upstream traffic speed using multiple

TCP streams against reference servers

Hawkeye Test types
Speedtest
Available Speedtest server: available from a list of servers

Options Timeout option: maximum time to execute test
Metrics Speedtest access latency: measured with TCP response time, usu-
ally exceeds the pure network latency
Speedtest downstream
Speedtest upstream
Advanced This test will only become available once the test type has been
Information installed by following the instructions in Speed Test using Global
Servers.
The speed test servers are operated by a third
party providers and all of the servers may not be
active at a time.
Results inter- The speedtest measured available throughput left available up

pretation and down to the selected speedtest server.
Using several streams and an optimization algorithm, the approx-
imation is usually good to determine the
Errors
TCP Ping
Description generates TCP SYN ping requests to servers or interfaces
Purpose SYN packets are sent to interface and port, and round trip delay is
based on SYNACK received. This test is useful especially to meas-
ure TCP connection times to http server or when ICMP protocol is
blocked to check availability and network response time to server.

Hawkeye Test types
TCP Ping

Options interval for TCP SYN packets
packet sizes(TCP content)
TCP port
DSCP setting
Metrics TCP Packet loss (%)

Round trip max (ms)
Round trip min (ms)
Advanced This test sends TCP SYN packets and listen for SYNACK responses.
Information Some TCP ports (HTTP for example on some servers) would only
allow packet size of 0 (no content) for TCP syn.
Results inter- The TCP response round trip and packet loss provides good inform-
pretation ation about the network transport to TCP remote ends.
Errors
Traceroute
Description Generates traceroute request
Purpose Traceroute request sent from original probe to the destination server
or url. Helps understanding the different hops involved and response
time of each hop based on used protocol (ICMP or UDP)

Hawkeye Test types
Traceroute
Available Destination Server (IP or url addresses)

Options Timeout for request (sec)
DSCP setting
ip protocol (ipv4 or ipv6)
traceroute protocol (ICMP or UDP)
Metrics Per step:

server ip and name
response time
Advanced Traceroute is informative for now: there is no check on thresholds

Information therefore the result is always pass.
the different servers on the path will be identified.
Several packets are sent for discovery and in case of load balancing
the list of servers that have been used to reach end destination
might show different options per path.
Results See advanced information.

inter-
pretation
Errors

Hawkeye Test types
UDP Ping
Description generates UDP packets requests to servers or interfaces
Purpose UDP packets can be blasted to remote servers or interfaces. If

these are configured with echo port (typically port 7 on routers)
packets are sent back.

Options interval for UDP packets
packet sizes(TCP content)
Remote UDP port
DSCP setting
Metrics UDP Packet loss (%)

Round trip max (ms)
Round trip min (ms)
Advanced This test sends UDP packets and listen for UDP packet responses.
Information
Results inter- The UDP response round trip and packet loss provides good inform-
pretation ation about the network transport to UDP remote ends. This test is
particularly useful to test routers configured with reflectors. The
UDP traffic generation is similar than TWAMP protocol defines for
user plane.
Errors
WiFi Connect
Description Measure Metrics Connecting To Wi-Fi AP

Hawkeye Test types
WiFi Connect
Purpose Wi-Fi connect measures the time taken by the Wi-Fi device to con-
nect to the access point (AP). This test highlights the bottle necks
in the various states like (Association, Authentication and DHCP)
while connecting to the Wi-Fi AP. This test can be executed to
check the connectivity of the device to the service provider by
pinging to the Internet or external network. The results are avail-
able as part of Metrics status and graphs. For this test to work, the
Ixia XRPi probe must be used with the supplied Wi-Fi dongle.
Available Authentication Method, Passphrase (WPA-PSK), SSID, BSSID,

Options Reset Interface After Test, Custom WPa Content, Username, Pass-
word, Test frequency, Ping Address, reset interface after test
Metrics Association Time (Ms)

Authentication Time (Ms)
Connect Time (Ms)
DHCP Handshake Time (Ms)
Association Attempt
ICMP Packet Loss
ICMP Round Trip Avg
Signal Strength (%)
Total Connect Time (Ms)
Wi-Fi Signal Level (DBm)
Advanced This test supports Authentication schemes, None, WPA-PSK, EAP-

Information TTLS/MSCHAPv2 and custom. Beta functionality of Captive Portal
Script (Optional). You can also select a particular BSSID to con-
nect to.
The default behaviour is to reset the wlan0 interface after each
execution of the WiFi Connect test.

Hawkeye Test types
WiFi Connect
Results inter- Total connect time gives the entire time for the Wi-Fi connection
pretation to the AP. The four stages for connection to the AP are numbered
1,2.3, or 4 and have times reported to complete those stages of
total call connect. Bottle necks can be identified by looking at the
time taken by individual 802.11 standard Wi-Fi States. ICMP met-
rics provide the connectivity to internet stats. Historic data can be
used to make inference on the Wi-Fi load on the network.
Potential The error messages that can be displayed are:

l If Wrong SSID is used – “No Wi-Fi interface detected”
Errors
l If no Wlan0 interface - “No response from file”
l If Probe is not registered – “Probe not registered or active for
real service”
WiFi Inspect
Description Measure Metrics Connecting to all available Wi-Fi AP
Measures key metrics of all available Wi-Fi AP that can be detec-

Purpose ted by probe.
Available SSID
Options
Channel
Advertised by AP Max bitrate (Mbps)
Metrics Wi-Fi Signal Level (DBm)
XRPi Wi-Fi Probe makes repeated measurements to ensure that all

Wi-Fi AP in range can be detected and reported. All WiFi AP in
Advanced range (2.4/5 Ghz) in range are reported, except limited support for
Information AC networks.

Hawkeye Test types
WiFi Inspect
Results inter- Results are reported in WiFi Dashboard. Results can be associated
pretation with a floorplan.
Charting Wi-Fi AP over time may show gaps in statistics. This can
be caused by several factors such as, WiFi AP is busy and is not
sending out the beacon signal used to calculate measurements.
WiFi AP signal level drops below necessary signal strength to be
detected and reported. Interference from stronger signal level from
another Wi-Fi AP using same channel number may cause weaker
signal AP to not be reported.
If no Wlan0 interface on XRPi Wi-Fi probe - “No response from file”
Potential
If Probe is not registered – “Probe not registered or active for real
Errors service”
Youtube video
Description Download a video from youtube cloud servers.
Purpose Measure user experience watching real time video files from you-
tube service and. The test will also provide useful information
about the video server actual location (with IP address and url) as
well as ICMP metrics to reach the server.

Hawkeye Test types
Youtube video
Available youtube video code or url = examples include a code like

Options “jFCWPIrHO-s” or a URL like “https://www.y-
outube.com/watch?v=jFCWPIrHO-s”
video name= display name for video. Will default to video code or
url if empty. Note, the name entered is not used in the youtube
download, only for naming purposes.
Video format = The following video formats are supported:
l Best: Select the best quality format represented by a single
file with video and audio.
l Worst: Select the worst quality format represented by a
single file with video and audio.
l Best video: Select the best quality video-only format. Video-
only format may not be available for selected video.
l Worst video: Select the worst quality video-only format.
Video-only format may not be available for selected video.
l Best audio: Select the best quality audio only-format. Audio-
only format may not be available for selected video.
l Worst audio: Select the worst quality audio only-format.
Audio-only format may not be available for selected video.
Timeout = time in seconds before giving up on video.

Hawkeye Test types
Youtube video
Metrics Configured threshold metrics:

Video Server: DNS response time: response time of DNS to
resolve video server
Video Server: ICMP jitter (ms): packet jitter (using ICMP) to con-
nect to video server
Video Server: ICMP loss rate: packet loss measured (using ICMP)
to connect to video server
Video Server IP: Video server IP as provided by the video service
Video Server URL: video server URL as provided by video service.
Video Format: video format (eg 640x360)
Calculated metrics:
Video Download Rate (kbps): average download rate for the video
Video Download time (sec): download time
Video Duration: video duration
Video Required BitRate (kbps): Required bitrate taking into
account video size and duration. Useful User experience metric.
Video Size (MBytes): video size
Video Total rebuffering events: number of video rebuffering events
during video watch. This is critical user experience metric as it will
decide the customer experience.

Hawkeye Test types
Youtube video
Advanced Format list example for youtube:

Information
Format Code Extension
140 m4a audio only
141 m4a audio only
160 mp4 256x144
133 mp4 426x240
134 mp4 640x360
135 mp4 854x480
136 mp4 1280x720
17 3gp 176x144
36 3gp 320x240
5 flv 400x240
43 webm 640x360
18 mp4 640x360
22 mp4 1280x720

Hawkeye Test types
Youtube video
Results inter- The download rate as obtained will allow a good understanding of
pretation the user experience compared to the computed required bitrate.
it is considered than a download rate should be on average 20%
over the required bitrate to ensure smooth user experience.
Ixia recommends 16:9 (1280 x 720) as the best youtube download
format.
This is very confusing as you would expect it to be 1024p. Youtube
can download at 1024p but the audio is in a separate download
stream and the web browser or application would need to combine
them. Combining the two streams is okay for TV's with specialized
hardware but not so good for web browsers.
Whenever you watch a youtube video with a web browser it is
nearly always 1280x720. Additionally, the video may not be avail-
able as a separate video and audio.
l The Video server URL has been converted to the You-
bube securitylink and will differ slightly from the video
URL entered as part of test configuration.
l Calculated metrics cannot be graphed, only metrics
configurable as thresholds.
Errors
Real Service endpoint support matrix

Real Service test type XR2000 XRPi XR Docker
Bittorrent Supported Not sup- Not sup-

ported ported
DNS Test Supported Supported Supported
Dropbox download Supported Supported Not sup-

ported

Hawkeye Test types
Dropbox upload Supported Supported Not sup-

ported
Email Supported Not sup- Not sup-

ported ported
FTP Download Supported Supported Not sup-

ported
FTP Multistream download Supported Supported Not sup-

ported
HTTP response time Supported Supported Supported
HTTP server test Supported Supported Supported
HTTP server test-advanced Supported Supported Supported
ICMP performance Supported Supported Supported
ICMP Test Supported Supported Supported
IGMP Test Supported Supported Not sup-

ported
Path discovery Supported Supported Supported
TCP ping Supported Supported Supported
Traceroute Supported Supported Supported
UDP Ping Supported Supported Supported
Wifi Connect Supported Supported Not sup-

ported
Wifi Inspect Supported Supported Not sup-

ported
Youtube Test Supported Supported Not sup-

ported

Hawkeye Test types
Skype Supported Supported Supported
Skype Network Connectivity Per- Supported Supported Supported

formance
Port Scan Supported Supported Supported
Replicating tests across multiple endpoints

Hawkeye allows you to create a test template for all test types. The advantage of this is
that when assigning tests to endpoints a saved test template can be assigned. Test tem-
plates offer the ability to create pre-canned test suites. For instance combining several
Node to Node tests for an "office_suite" test template or combining several tests for a
"voice_suite" test template. This saves user time in test creation and allows for
thresholds for test metrics to be set to expected values once for the users network. For
example threshold metrics for expected round trip delays.
In "Probe Management" there is a web GUI for "Test Templates". You can create a test
template and give it a name for referencing in test execution. Youc an configure all prop-
erties of a test except the endpoints to be used. You can create a test suite by adding
multiple tests of the same test type (N2N/Mesh/Real Servcices) to each test template.
For each test type added to the template all usual configuration of a regular test can be
configured, such as thresholds, email for alarms, schedule frequency of tests. For each
test the you have a flag to enforce the test is scheduled at correct synced time. Each
test template can be restricted to be available to only certain user groups. Once all
tests have been added to the new test template it is "added" and is available for use in
"Test Execution".
In "Test Execution" for each test type such as "Test Execution Node to Node" if a test
template is available then a button is presented to the user allowing the selection of
"normal" test or using a previously saved test template. A pull down menu allows for the
selection of a test template then the User only has to select the endpoints to assign for
the test template. When tests are running an icon identifies normal tests and tests
based on test templates.
Under "Test Execution" there is a web page "Test Execution Templates" which is used to
manage tests running using a test template (e.g. voice_suite). From this web page indi-
vidual tests on endpoints can be paused and deleted.

Hawkeye Test types
A test template can only be deleted once all scheduled tests using that
specific test template have been removed.
The name of the test template (test identifier) does not support special
characters such as quotes.
Test types reporting WiFi statistics

This feature displays the statistics of the tests that are executed for the Wifi devices.
The tests results are displayed based on the combination of the Probe From and
Probe To with the TCP and UDP tests that you execute.
The system displays the statistics when you execute any TCP XR2000/XRPi/SW EP test
the Probe From must be Wifi(interface) and when you execute any UDP transport test
the Probe To must be Wifi.
The table below provides information on the various combinations when a WiFi enabled
endpoint or non-WiFi enabled endpoint in the "TO/FROM" position for TCP and UDP
traffic tests will provide WiFi statistics.
Wifi Statistics
Test Name Probe From Probe To Availability
N2N
Voice 1 Pairs Uni- Android/XRPi Wifi XR2000/XRPi/SW EP No

directional
Voice 1 Pairs Uni- XR2000/XRPi/SW Android/XRPi Wifi Yes

directional EP
Voice 1 Pairs bid- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

irectional
Voice 1 Pairs bid- XR2000/XRPi/SW Android/XRPi Wifi Yes

irectional EP
Voice 1 pairs - UDP Android/XRPi Wifi XR2000/XRPi/SW EP Yes

Data bidirectional

Hawkeye Test types
Wifi Statistics
Voice 1 pairs - UDP XR2000/XRPi/SW Android/XRPi Wifi Yes

Data bidirectional EP
Voice from->to Android/XRPi Wifi XR2000/XRPi/SW EP No
Voice from->to XR2000/XRPi/SW Android/XRPi Wifi Yes

EP
Voice bidirectional Android/XRPi Wifi XR2000/XRPi/SW EP Yes
Voice bidirectional XR2000/XRPi/SW Android/XRPi Wifi Yes

EP
Video Stream Android/XRPi Wifi XR2000/XRPi/SW EP No
Video Stream XR2000/XRPi/SW Android/XRPi Wifi Yes

EP
UDP Throughput to- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

>from
UDP Throughput to- XR2000/XRPi/SW Android/XRPi Wifi No

>from EP
UDP Throughput Android/XRPi Wifi XR2000/XRPi/SW EP No

from->to - 4 COS
UDP Throughput XR2000/XRPi/SW Android/XRPi Wifi Yes

from->to - 4 COS EP

from->to

from->to EP
UDP Throughput bid- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

irectional

Hawkeye Test types
Wifi Statistics
UDP Throughput bid- XR2000/XRPi/SW Android/XRPi Wifi Yes

irectional EP

Advanced

Advanced EP
Traffic Mix - HTTP - Android/XRPi Wifi XR2000/XRPi/SW EP No

Video - Voice
Traffic Mix - HTTP - XR2000/XRPi/SW Android/XRPi Wifi Yes

Video - Voice EP
TCP Throughput to- Android/XRPi Wifi XR2000/XRPi/SW EP No

>from N streams
TCP Throughput to- XR2000/XRPi/SW Android/XRPi Wifi Yes

>from N streams EP
TCP Throughput to- Android/XRPi Wifi XR2000/XRPi/SW EP No

>from 1 stream
TCP Throughput to- XR2000/XRPi/SW Android/XRPi Wifi Yes

>from 1 stream EP
TCP Throughput Android/XRPi Wifi XR2000/XRPi/SW EP Yes

Optimized Window
size
TCP Throughput XR2000/XRPi/SW Android/XRPi Wifi No

Optimized Window EP
size

from->to N
streams

Hawkeye Test types
Wifi Statistics

from->to N EP
streams

from->to 1 stream

from->to 1 stream EP
TCP Throughput bid- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

irectional
TCP Throughput bid- XR2000/XRPi/SW Android/XRPi Wifi Yes

irectional EP

Advanced

Advanced EP
TCP Response Time Android/XRPi Wifi XR2000/XRPi/SW EP Yes
TCP Response Time XR2000/XRPi/SW Android/XRPi Wifi No

EP
SMTP Response Android/XRPi Wifi XR2000/XRPi/SW EP Yes

Time - SMTP.scr
SMTP Response XR2000/XRPi/SW Android/XRPi Wifi No

Time - SMTP.scr EP
SIP Response Time Android/XRPi Wifi XR2000/XRPi/SW EP Yes

- SIP_Regis-
tration.scr

Hawkeye Test types
Wifi Statistics
SIP Response Time XR2000/XRPi/SW Android/XRPi Wifi No

- SIP_Regis- EP
tration.scr
POP3 Response Android/XRPi Wifi XR2000/XRPi/SW EP Yes

Time - POP3.scr
POP3 Response XR2000/XRPi/SW Android/XRPi Wifi No

Time - POP3.scr EP
Network KPI to- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

>from
Network KPI to- XR2000/XRPi/SW Android/XRPi Wifi No

>from EP
Network KPI Low Android/XRPi Wifi XR2000/XRPi/SW EP No

Bandwidth
Network KPI Low XR2000/XRPi/SW Android/XRPi Wifi Yes

Bandwidth EP
Network KPI bid- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

irectionnal
Network KPI bid- XR2000/XRPi/SW Android/XRPi Wifi Yes

irectionnal EP
Network KPI Android/XRPi Wifi XR2000/XRPi/SW EP No

Advanced
Network KPI XR2000/XRPi/SW Android/XRPi Wifi Yes

Advanced EP
Network KPI 3 COS Android/XRPi Wifi XR2000/XRPi/SW EP No
Network KPI 3 COS XR2000/XRPi/SW Android/XRPi Wifi Yes

EP

Hawkeye Test types
Wifi Statistics

EP
Skype4B Traffic Android/XRPi Wifi XR2000/XRPi/SW EP No

from->to
Skype4B Traffic XR2000/XRPi/SW Android/XRPi Wifi Yes

from->to EP

EP
HTTPS Test - Android/XRPi Wifi XR2000/XRPi/SW EP Yes

HTTPS_Secure_
Transaction.scr
HTTPS Test - XR2000/XRPi/SW Android/XRPi Wifi No

HTTPS_Secure_ EP
Transaction.scr
HTTP Test - HTTP- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

text.scr
HTTP Test - HTTP- XR2000/XRPi/SW Android/XRPi Wifi No

text.scr EP
FTP Response Time Android/XRPi Wifi XR2000/XRPi/SW EP Yes

- FTPget.scr
FTP Response Time XR2000/XRPi/SW Android/XRPi Wifi No

- FTPget.scr EP
Exchange_traffic Android/XRPi Wifi XR2000/XRPi/SW EP Yes
Exchange_traffic XR2000/XRPi/SW Android/XRPi Wifi Yes

EP

Hawkeye Test types
Wifi Statistics
DNS Response Android/XRPi Wifi XR2000/XRPi/SW EP Yes

Time - DNS.scr
DNS Response XR2000/XRPi/SW Android/XRPi Wifi No

Time - DNS.scr EP
COS line qual- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

ification
COS line qual- XR2000/XRPi/SW Android/XRPi Wifi Yes

ification EP
HTTP Video Android/XRPi Wifi XR2000/XRPi/SW EP Yes
HTTP Video XR2000/XRPi/SW Android/XRPi Wifi No

EP
Multicast video Android/XRPi Wifi XR2000/XRPi/SW EP No

over RTP
Multicast video XR2000/XRPi/SW Android/XRPi Wifi Yes

over RTP EP
Mesh
Voice from->to Android/XRPi Wifi XR2000/XRPi/SW EP Yes
Voice from->to XR2000/XRPi/SW Android/XRPi Wifi Yes

EP
TCP Response Time Android/XRPi Wifi XR2000/XRPi/SW EP Yes
TCP Response Time XR2000/XRPi/SW Android/XRPi Wifi No

EP
Network KPI to- Android/XRPi Wifi XR2000/XRPi/SW EP Yes

>from
Network KPI to- XR2000/XRPi/SW Android/XRPi Wifi No

>from EP

Hawkeye Test types
Wifi Statistics
Network KPI Low Android/XRPi Wifi XR2000/XRPi/SW EP No

Bandwidth
Network KPI Low XR2000/XRPi/SW Android/XRPi Wifi Yes

Bandwidth EP

Advanced

Advanced EP
Network KPI 3 COS Android/XRPi Wifi XR2000/XRPi/SW EP No
Network KPI 3 COS XR2000/XRPi/SW Android/XRPi Wifi Yes

EP

EP

from->to

from->to EP
Supported Protocols and standards

This section covers supported protocols and standards by Hawkeye.

Hawkeye Test types
Node to Node tests
Transaction traffic Types Supported Traffic
Throughput measurements UDP / TCP
Voice G711, G729, AMR
Video MPEG2/MPEG4 – SD and HD
Signalling Voice SIP - H323
Emails POP3, SMTP, Exchange
WWW HTTP, HTTPs, FTP, DNS, Telnet
Office 365 Exchange, Skype4B media
Real Service tests - one arm

One arm traffic Details
Bittorrent Download torrent
DNS Verify DNS server response time
DropBox Download/upload files
Email Send/receive emails (SMTP, IMAP, POP3)
FTP Download/upload files to server
HTTP/HTTPS Download/check page availability
ICMP Advanced ping metrics

Hawkeye Test types
IGMP v2/v3 Join/leave Multicast and measure metrics
SpeedTest Validate Speedtest up/down from 4000+ servers
TCP/UDP ping Ping using TCP or UDP protocols
Traceroute Trace routes to remote hosts
Youtube Download video and provide User experience
Supported Standards
Node to Node
Protocol Standard
IP TOS RFC 791 y RFC 1349
Diffserv RFC 2474, RFC 2597, RFC 2598
UDP RFC 768 or proprietary
TCP window scale RFC1323
TCP window retransmission RFC1122
RTP RFC3550
Real Services
Protocol Standard
HTTP RFC2616
HTTPS RFC2818
FTP RFC959
DNS RFC1034, RFC1035
ICMP RFC792

Hawkeye Test types
Traceroute RFC1393
Peer to Peer RFC5694
SMTP RFC821, RFC2821
POP3 RFC1939
Testing
Metric Standard
Throughput (goodput) RFC2647
Jitter RFC1889
video MDI (DF, MLR) RFC 4445
MOS ITU.G107
R Factor ITU.G107 (E-model)
Benchmarking, service activation RFC2544
Web Server notification
Protocol Standard
SMTP (email notification) RFC821, RFC2821
SNMP RFC1157
W3C SOAP 1.2 SOAP web services standards
Protocol Standard
HTTP RFC2616
HTTPS RFC2818

Hawkeye Test types
Supported Voice over IP codecs

Advanced administrator Guide Introduction

this section will cover advanced information on how to administer your Hawkeye server.
You need to have administrator access to the server hosting Hawkeye to be able to use
this.
The Hawkeye system is currently based on a CentOS 6.6 system which is derived from
the System V standards. Specifically, the init scripts that control the various services.
The startup scripts themselves are located in /etc/init.d. Each service has its own script
that accepts a specific set of standard commands to control the service in question. The
most common relevant commands for our purposes are the “start”, “stop” and “check”
options. These start the service, stop the service and check the status of the service
respectively. Theses commands can either be run either by passing the command to the
script as an option (e.g. “/etc/init.d/httpd start”), or by using the “service” command
(e.g. “service httpd start”), which simply calls the associated script passing the given
command to it.
Most services also have an associated configuration file in /etc/sysconfig to define or

override certain aspects of the script operation or server command line options. These
files are normally named the same as the init scripts they are associated with.
OSS (Operations Support System) Integration

Hawkeye is designed to be an open framework for easy integration into service pro-
viders OSS.
It supports a range of northbound and southbound interfaces that are designed to :
l Export or collect key information and alarms generated by Hawkeye to third party
system.
l Automate some tasks from third party tools (generate automatic tests for
example)
l Generate customized actions

Hawkeye SNMP alarms
Based on test results Hawkeye can trigger an Hawkeye SNMP trap to a third party.
The mib is based on SNMPv2 and is easily imported into supervision systems.
Alarms are generated based on pass fail criteria generated by thresholds.
Hawkeye Email notifications
Hawkeye can generate automatic emails to configurable recipients (configurable per

alert) with alarms based on test results or thresholds.
Automatic emails can also be sent with content result of aggregated report – these are
user defined and can be scheduled over time (every hour/day/week).
Hawkeye MySQL database
Hawkeye database has been designed to be efficiently integrated to third party report-
ing tools.
Therefore, the test data structure storage consists of a simple structure for storing the
data record.
Each active test in Hawkeye is considered as a single Data record, recorded into Test
Data Record Table.
Test Data Record contains a set of information describing the test result, with inform-
ation about:
l Unique ID
l Test execution time

l Pointer to meta data table containing information
Each Test Data record is independent from each other, and independent from any other
table in the database structure, therefore can be displayed as an independent and flat
view containing all available test data.
see MySQL database Management for more details on the test data record structure.
MySQL database Management
Hawkeye database
Hawkeyeapplication uses mysql database 5.1.73
The configuration file for the MySQL server is /etc/my.cnf. This file contains the tuning
parameters for the server as well as defining where the MySQL server stores its data
files.
For larger installations, you should consult Ixia Support to determine if any of the values
here should be modified to accommodate the requirements of the specific installation.
On a Hawkeye system, by default, the data tables for the MySQL server are stored in
/home/mysql_data. The expectation is that, on a system with multiple partitions, the
/home partition will be a large local disk partition. If the installation requires NFS moun-
ted home directories, then these files should be moved to another location on a large
local disk.
Example of configuration for a 20G memory server:
[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT

innodb_log_file_size=1G
#log-bin = /home/mysql_data/mysql-bin
#expire-logs-days = 14
#sync-binlog = 1
#tmp-table-size = 32M
#max-heap-table-size = 32M
query-cache-type = 0
query-cache-size = 0
max-connections = 1000
thread-cache-size = 100
open-files-limit = 65535
table-definition-cache = 1024
table-open-cache = 2048
innodb-flush-method = O_DIRECT
#innodb-log-files-in-group = 2
#innodb-flush-log-at-trx-commit = 1
#innodb-file-per-table = 1
innodb-buffer-pool-size = 12G
datadir=/home/mysql_data
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
[mysqld_safe]

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
slow-query-log = 1
slow-query-log-file = /home/mysql_data/mysql-slow.log
the mysql runs as a service:
start: service mysqld start
stop: service mysqld stop
Note: Never attempt to kill mysqld directly this can corrupt

the database.
MySQL web admin
PHPmyadmin is a web based tool for MySQL administration and advanced configuration.
A lot of information and documentation about this tool can be found at:
http://www.phpmyadmin.net/home_page/docs.php
To access to the Hawkeye Web Portal database administration tool use the following
URL:

http://yourserverIP/phpmyadmin
The default credentials to login are:
Username: root
Password: Ixia123
If selected, the complete database will appear and be available, with table size in
entries and disk space.

Note: any modifications to the database structure and con-

tent directly made into the database can severely affect
operations. This shouldnt be done by non certified engin-
eers and under Ixia Support supervision.
Hawkeye database : changing root password
For full advanced procedure refer to:
https://dev.mysql.com/doc/refman/5.0/en/resetting-permissions.html
Using phpmyadmin interface:
Login as root,
go to users tab
click edit privileges for root user

scroll down
fill in 2 new passwords and selec GO
Note: as soon as the password is modified the Hawkeye

application will need to be reconfigured with new credentials
to access mysql database !!! The configuration for database
is in /home/ixia/Hawkeye/conf/configuration.txt

----------------------------------------
## Hawkeye configuration file
[MySQLDatabase]
"MySQL_Host" == "localhost"
"MySQL_Database" == "HawkeyePro"
"MySQL_User" == "root"
"MySQL_Password" == "Password0"
"MySQL_UseSSL" == "0"
change mysql password to new password as reconfigured
Hawkeye database : enabling remote access
Using phpmyadmin interface:
Login as root,
go to users tab

click edit privileges for ixia and/or root user (ixia user has restricted priviledges).
scroll down

change host from local to "any host" or "Use text field" where a specific originating IP
can be specified.
It is recommended to leave default option to leave the old host.
As noted below the windows firewall port must be opened for inbound request to mysql.
Note: this will grant access to other servers to the database

information. This can create security issues if not com-
pletely under control.
Note:the default listening port for mysql database is 3306.

Windows firewall must be opened inbound for this port so
that other servers can conncect to it

Hawkeye database : run sql script
Some advanced modification sql scripts are sometimes required for ad hoc bug fixing or
applying a patch on the server.
These would typically be provided by Ixia support.
Recommendation is to run them through phpmyadmin (command line using mysql tool is
also possible, refer to corresponding mysql user guide for this).
steps:
login to phpmyadmin (preferably as root user).
select Hawkeye database database:

select SQL tab
paste the required query into the text area:

run the query hitting the Go button
Hawkeye database test results structure
Hawkeye solution has an underlying database scheme that is used for:
-System information and administration management;
-Test execution Queue Management;
-Test Results storage;
Test result storage structure

Test data record concept

Hawkeye database has been designed to be efficiently integrated to third party report-
ing tools.
Therefore, the test data structure storage consists of a simple structure for storing the
data record.
Each active test in Hawkeye is considered as a single data record, recorded into Test
Data Record Table.
Test data record contains a set of information describing the test result, with information
about:
l Unique ID;
l Test execution time;
l ID to test_data_record_filters table
l Reason cause;
Each test data record is independent from each other, and independent from any other
table in the database structure, therefore can be displayed as an independent and flat
view containing all available test data.
The test_data_record_filters table contains meta data to more information about node
from, node to, test type etc... each test_data_record is linked to a test_data_record_fil-
ters . A join query on the 2 tables will allow to get explicit information about the con-
tent.
KPI result table
Each Test Data Record may contain a set of KPI (Key Performance Indicators) that will
contain the information about each performance indicator, and value for the data record.
A database table called kpi_result_table contains the information about the KPI. Each
KPI result has to be linked to the test_data_record (using TDR_ID).
A table called kpi_result_table_filters is linked to kpi_result_table and contains inform-

ation about metric and test pair for which the metric is stored as well as status.
another table called kpi_string_information is linked to TDR and contains string kpi typ-
ically used to provide further description of a test result.

One Test Data Record (TDR) can contain as many results as needed in string or integer
format.
Each KPI result contains:
l A link ID to relate to the corresponding TDR with all test information.

l A value;
l A threshold Value (defining the threshold used to define PASS / FAIL);
l A threshold type (define the type of the threshold, less than, more than, per-
centage, etc..)
It also contains a link to the kpi_result_table_filters which contains
l A metric name.
l A pair name (to identify a specific pair in a set of tests, for example when using
COS testing or traffic mix);
l A Status (PASS/FAIL);
KPI detailed result table

Some metrics (not all) may be recorded in a test with intermediate results within a
single test. When Test Data Record is created, these metrics are stored into kpi_
detailed_table. These results are used to create graphs of a single Test for the available
metrics.
Each detailed KPI entry contains:
l A link ID to relate to the corresponding TDR with all test information;

l A metric name;
l A pair name (to identify a specific pair in a set of tests, for example when using
COS testing or traffic mix);
l A timestamp, which is starting from 0 (when test begins and go to a maximum (in
seconds) which is the total test duration of the TDR
l A value;

MySQL test data structures
The following drawing illustrates the different tables mentioned above and their struc-
ture.
Standard SQL queries shall be made to get these into any reporting, data mining or data
post processing engines.

MySQL advanced configuration for performance

see Optimizing MySQL.

Hawkeye folder structure

The Hawkeye application is installed in /home/ixia/Hawkeye. The Hawkeye application
generates a number of log files which are automatically rotated to manage disk space.
The user does not need to refer these log files unless advised by Ixia Customer Support.
The following directories contain log files:
l System log files are in /var/log directory.

l Individual Node to Node and Mesh test details or statistics files from endpoints are
in /home/ixia/Hawkeye/logs/Chariot directory.
l Hawkeye system files and real service test logs are in /home/ixi-
a/Hawkeye/logs/Hawkeye directory.
SNMP configuration and verification

You can configure and verify the Simple Network Management Protocol (SNMP). This
section explains how to configure and verify the SNMP.
SNMP Traps
Hawkeye server supports the generation of SNMP traps for tests originated from end-
points. Tests configured to generate SNMP traps on certain error/failure conditions
sends the SNMP traps in MIB format to a designated SNMP server.
There are six steps involved:
l How to use SNMP traps

l Verify Hawkeye Server MIBs file can be interpreted by the User’s SNMP server
l Configure HawkeyeServer in “preferences” to send SNMP trap to a specific User’s
SNMP server.
l Configure User’s SNMP server to receive Hawkeye server originated SNMP traps
l Enable SNMP traps to be triggered for endpoint scheduled tests
l Verify SNMP trap successfully received and decoded by SNMP server.
l Advanced Troubleshooting – Monitor Hawkeye server SNMP debug logs

How to use SNMP traps

SNMP traps can be configured to be triggered by test results on end points. The time
between tests and consequently the possible reporting time between SNMP traps is Cus-
tomer configurable. The shortest time between tests on an endpoint is one minute.
SNMP traps are supported for all test types. When configuring a test, select Show
Alarm options to see the SNMP configuration.
Each test can be enabled to trigger SNMP traps, based on a failure or error result. There
is the option to only report an SNMP trap on a “change”. This means if a test on an end-
point is scheduled to run every 5 minutes and it is failing every time, it is only reported
as an SNMP trap the very first time it fails, then it generates another SNMP trap once
the endpoint test result changes to be an error or passes.
Verify Hawkeye Server MIBs file can be interpreted by the

User’s SNMP server
Hawkeye SNMP traps encoding is identified by three files. Retrieve the following three
MIBs files from the Hawkeye server so that they can be verified:
putty (ssh) to hawkeye server (username/password - root/ixia123).
Files required:
/usr/share/snmp/mibs /NET-SNMP-MIB.txt
/home/ixia/Hawkeye/includes/MIBS/Hawkeye-MIB.txt
/home/ixia/Hawkeye/includes/MIBS/IXIA-SMI.txt
There are a number of independent free web sites that verify that custom MIB files con-
firm to correct standards.
Suggested free independent web sites to verify Hawkeye MIBs format:

http://www.simpleweb.org/ietf/mibs/validate/upload.php
http://www.muonics.com/Tools/smicheck.php

From these web sites pull in the retrieved two Hawkeye files and validate to MIBs stand-
ards. There are three supported versions of MIB files (v1, v2 and v3).
Configure Hawkeye Server to send SNMP trap to a specific

SNMP server
Enable SNMP traps to be generated by the Hawkeye server.
To enable the SNMP traps, do the following:
Go to Administration > preferences > Alarms toggle the Enable/disable the

alarms received using SNMP.
Also configure the IP address of the your SNMP trap server, to which the SNMP traps are
to be sent to.
Multiple SNMP trap receivers can be supported by using a third party application that
will forward received UDP packets from the Hawkeye Server IP address/port to a defined
list of destination SNMP trap receivers (IP/port). There are many free applications that
are available for this purpose, such as the free linux samplicator application. The
SNMP server IP defined on the Hawkeyeserver to achieve this will be the IP of the third
party application doing the forwarding.
Configure your SNMP server to receive Hawkeye server

originated SNMP traps
There are many SNMP servers (receiver) available but the required basic configuration
is as follows:
1. Load in the two Hawkeye MIB modules identified and retrieved from the Hawkeye
server in the above steps (NET-SNMP-MIB.txt, IXIA-SMI.TXT and Hawkeye-
MIB.txt). This enables your SNMP trap server to decode the Hawkeye SNMP traps.
2. Configure the host address of the Hawkeye server that will be the source of the
SNMP traps.
3. Set the host port used to generate and be monitored for the SNMP traps to 162.
4. Set the community to ixia.
5. Following a Hawkeye Server upgrade, remove, flush, or delete any Hawkeye MIB

files from the SNMP server (receiver) and pull in the latest version as new test
types. Else, changed test metrics will cause decode issues.
Enable SNMP traps to be triggered for endpoint scheduled

tests
Schedule a test (example, node to node Skype4B traffic test) on probes expected to gen-
erate SNMP traps on error/failure conditions.
When configuring the test, set thresholds to expected values additionally select Show
Alarm Options.
Go to Show Alarm Options and enable the SnmpTrap.
Also select the conditions for the alarm to be triggered that generates the SNMP Trap
(Error/Failed/Status change).
Verify SNMP trap successfully received and decoded by

SNMP server
Invoke SNMP trapviewer from your SNMP server. Generate SNMP trap by running
Hawkeye test that fails. Confirm that the SNMP trap received in the trap viewer is as
expected and can be decoded.
Advanced Troubleshooting – Debug SNMP packet routing

issues
Putty (ssh) to Hawkeye server (username/password - root/ixia123) and monitor SNMP
trap logs to confirm that tests are triggering sending of SNMP traps to SNMP server.
On the Hawkeye server go to directory /home/ixia/Hawkeye/logs/Hawkeye and

monitor server daemon logs with the following command.
tail -f ServerDaemon.log
Confirm able to see logs such as the one below where the first IP address is the IP
address of the SNMP server to receive the SNMP trap.
20:24:58 UTC (Alarm send) sending snmptrap -

snmptrap -M /usr/share/snmp/mibs/:/home/ixia/Hawkeye/includes/MIBS -c
ixia -v 2c 10.220.120.11 "" HAWKEYE-MIB::hawkeye-notification trapID s
"xr2000autoqa2xrpiwifiqa2Skype4BTrafficDelaymsAudioRTPfromto12kbpsFAIL"
summary s "xr2000autoqa2 to xrpiwifiqa2 Skype4B Traffic Audio RTP fromto
12 kbps Delay ms Failed" runID s "8285" TimeStamp s "2016-11-30
20:24:57" TestType s "Skype4B Traffic" TestStatus s "Failed" From s
"xr2000-auto-qa-2" To s "xrpi-wifi-qa-2" PAIRNAME s "Audio RTP from->to
12 kbps" MetricName s "Delay (ms)" METRICVALUE s "2.5" DefaultThreshold-
Type s "1" THRESHOLD s "9000" METRICSTATUS s "Failed" FailReason s "
Threshold failed on Audio RTP from->to 12 kbps Delay (ms) "
Additionally use TCP dump command to confirm that the SNMPtrap packet is not being
blocked in the network. The TCP logs below (taken from Hawkeye server) show that a
SNMP trap is generated from Hawkeye server (10.220.120.127) and sent to the SNMP
trap server/receiver (10.220.20.45) but is blocked as unreachable.
TCP dump from Hawkeye server:

tcpdump -n -i eth0 | grep -i "10.220.120.127"
21:11:38.246127 IP 10.220.120.127.52365 > 10.220.20.45.snmptrap:
C=ixia V2Trap(183) .1.3.6.1.2.1.1.3.0=148999358 .1.3.6.1.6.3.1.1.4.1.0-
0=.1.3.6.1.4.1.8072.2.1.0.3 .1.3.6.1.4.1.8072.2.1.2.1=3
.1.3.6.1.4.1.8072.2.1.2.2="Amazon-KFFOWI" .1.3.6.1.4.1.8072.2.1.2.3-
3="Amazon-KFFOWI" .1.3.6.1.4.1.8072.2.1.2.4="0"
.1.3.6.1.4.1.8072.2.1.2.5="TestAgent1"
21:11:38.247491 IP 10.220.20.45 > 10.220.120.127: ICMP 10.220.20.45
udp port snmptrap unreachable, length 234
In the above example, unlike the Network Unreachable and Host Unreachable messages
which come from routers, the Port Unreachable message comes from the SNMP server-
/receiver. The primary implication for troubleshooting is that the frame was successfully
routed across the communications infrastructure, the last router ARP'ed for the host, got
the response, and sent the frame. Furthermore, the intended SNMP server (destination
host) was on-line and willing to accept the frame into its communications buffer. The
frame was then processed and an attempt was made to send the data up to the des-
tination port number (UDP port 162) and the port process (SNMP server) did not exist.
The protocol handler then reports Destination Port Unreachable.
For SNMP traps generated by Hawkeye Server to reach a third party SNMP trap receiver
the UDP ports 161 and 162 need to be open for UDP traffic on the Hawkeye server and
switches between the two parties. One way to open the ports on the Hawkeye Server is

to putty to the Hawkeye Server then using the following CLI commands to open the fire-
wall for SNMP traffic:
# iptables -I INPUT -p udp -m udp --dport 161 -j ACCEPT
# iptables -I INPUT -p udp -m udp --dport 162 -j ACCEPT
# iptables-save > /etc/sysconfig/iptables
Hawkeye SNMP MIB Information

This section covers information about SNMP MIB provided by Hawkeye
MIB file location

MIB files can be found into the following directory /home/ixia/Hawkeye/includes/MIBS
MIB file IXIA-SMI.txt content

IXIA-SMI DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-IDENTITY,
enterprises
FROM SNMPv2-SMI;
ixia MODULE-IDENTITY
LAST-UPDATED "201701040000Z"
ORGANIZATION "www.ixiacom.com"
CONTACT-INFO
" Ixia Communications
Postal: 26601 W. Agoura Rd.
Calabasas, CA 91302
USA
Email: [email protected]"
DESCRIPTION
"The Structure of Management Information for the
Ixia Communication enterprise."
::= { enterprises 3054 } -- assigned by IANA
ixiaProducts OBJECT-IDENTITY
STATUS current
DESCRIPTION
"ixiaProducts is the root OBJECT IDENTIFIER from
which sysObjectID values are assigned."

::= { ixia 1 }
END
MIB file Hawkeye-MIB.txt content

HAWKEYE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
NOTIFICATION-TYPE
FROM SNMPv2-SMI
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
ixiaProducts
FROM IXIA-SMI;
hawkeye MODULE-IDENTITY
LAST-UPDATED "201701040000Z"
ORGANIZATION "www.ixiacom.com"
CONTACT-INFO
" Ixia Communications
Postal: 26601 W. Agoura Rd.
Calabasas, CA 91302
USA
Email: [email protected]"
DESCRIPTION
"Hawkeye MIB objects for trap notifications"
REVISION "201604260000Z"
DESCRIPTION
"Hawkeye MIB"
REVISION "201402060000Z"
DESCRIPTION
"First draft"
::= { ixiaProducts 1 }
hawkeye-notifications OBJECT IDENTIFIER ::= { hawkeye 1 }

hawkeye-notificationprefix OBJECT IDENTIFIER
::= { hawkeye-notifications 0 }
hawkeye-notificationobjects OBJECT IDENTIFIER
::= { hawkeye-notifications 2 }

probeID OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
""
::= { hawkeye-notificationobjects 1 }
probeMgtIP OBJECT-TYPE
SYNTAX SnmpAdminString
STATUS current
DESCRIPTION
""
probeName OBJECT-TYPE
STATUS current
DESCRIPTION
""
probeStatus OBJECT-TYPE
SYNTAX INTEGER {
down(0),
up(1)
}
STATUS current
DESCRIPTION
""
testAgentName OBJECT-TYPE

STATUS current
DESCRIPTION
""
runID OBJECT-TYPE
STATUS current
DESCRIPTION
""
timeStamp OBJECT-TYPE
STATUS current
DESCRIPTION
""
testStatus OBJECT-TYPE
STATUS current
DESCRIPTION
""
from OBJECT-TYPE
STATUS current
DESCRIPTION
""
to OBJECT-TYPE

STATUS current
DESCRIPTION
""
errorReason OBJECT-TYPE
STATUS current
DESCRIPTION
""
failReason OBJECT-TYPE
STATUS current
DESCRIPTION
""
pairname OBJECT-TYPE
STATUS current
DESCRIPTION
""
metricName OBJECT-TYPE
STATUS current
DESCRIPTION
""
metricvalue OBJECT-TYPE
STATUS current
DESCRIPTION
""
defaultThresholdType OBJECT-TYPE
STATUS current
DESCRIPTION

""
threshold OBJECT-TYPE
STATUS current
DESCRIPTION
""
metricstatus OBJECT-TYPE
STATUS current
DESCRIPTION
""
timeStampProviso OBJECT-TYPE
STATUS current
DESCRIPTION
""
provisoAlarmMessage OBJECT-TYPE
STATUS current
DESCRIPTION
""
testType OBJECT-TYPE
STATUS current
DESCRIPTION
""
summary OBJECT-TYPE
STATUS current
DESCRIPTION
""
trapID OBJECT-TYPE

STATUS current
DESCRIPTION
""
hawkeye-notification NOTIFICATION-TYPE
OBJECTS {
trapID,
summary,
runID,
timeStamp,
testType,
testStatus,
from,
to,
pairname,
metricName,
metricvalue,
defaultThresholdType,
threshold,
metricstatus,
failReason
}
STATUS current
DESCRIPTION
""
::= { hawkeye-notificationprefix 1 }
hawkeye-errornotification NOTIFICATION-TYPE
OBJECTS {
trapID,
summary,
runID,
timeStamp,
testType,
testStatus,
from,
to,
errorReason
}
STATUS current
DESCRIPTION
""
hawkeye-probenotification NOTIFICATION-TYPE

OBJECTS {
probeID,
probeMgtIP,
probeName,
probeStatus,
testAgentName
}
STATUS current
DESCRIPTION
""
hawkeye-provisoalarm NOTIFICATION-TYPE
OBJECTS {
timeStampProviso,
provisoAlarmMessage
}
STATUS current
DESCRIPTION
""
END
Associated MIB descriptors

Associated MIB descriptors can be needed to import MIB. The associated MIB descriptor
are available in the same subdirectory:
/usr/share/snmp/mibs
Speed Test using Global Servers

The real service speed test uses servers located all over the world to calculate round
trip delay along with uplink and downlink throughput. Procedure for speed test real ser-
vice activation :
1. Login to Hawkeye server (using ssh)

2. Locate the /tmp directory (cd /tmp)
3. Download updated speedtest server list:
wget http://www.speedtest.net/speedtest-servers.php -O /tm-
p/testservers.xml
If the server is offline, you must download the content and copy the
file to /tmp directory.

4. Run the command for import.

php -c /home/ixia/Hawkeye/conf /home/ixia/Hawkeye/ServerScripts/populate_
speedtest.php /tmp/testservers.xml
The speed test real service test will be available in GUI.
Set long TDRID

The option to support time based TDR is available as an advanced feature.
Vast majority of systems dont need this feature which is only required when importing
external data to the TDR database out of sync.
Since TDR ID sequencing is tied to TDR timestamp for historical search, switching to this
feature is required.
Note: Switching to this setting needs to be definitive (no

roll back possible) and should only be done after consulting
Ixia support.
Steps:
1) get the file DB_install_Scripts\updateToTDRtimestamp.sql and run it on Hawkeye

database
2) go into the configuration file: configuration.txt and set the following option in main
section
"useTimestampTDRID"=="1"
If the setting doesnt exist copy the line under Main section.

SOAP web services API

Hawkeye solution is web based GUI. Some specific functions have been developed to be
available for third party OSS through specific APIs.
The global API framework is using SOAP web services and allows third party to connect
to the Hawkeye Web services through industry standard APIs.
SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for
exchanging structured information in the implementation of Web Services in computer
networks. It relies on Extensible Markup Language (XML) for its message format.
The following diagram present high level scheme for the SOAP xml implementation.
SOAP XML Server on the Hawkeye is implemented over PHP php_soap generic exten-
sion. It is therefore compatible with any SOAP client and agnostic about the connecting
technology.
It is installed and uses the same port as the (Apache) Hawkeye server GUI. The default
port is 80, but if 443 is specified for security for the Hawkeye server, it will listen for
incoming requests on port 443.

It publishes WSDL file format for creating SOAP client connector and publishing all avail-
able APIs.
For security it is recommended to run SOAP request on https port .
Activating SOAP in Hawkeye

In system > Preferences > Advanced Admin section, the following parameters
need to be activated:
SOAP web service API set to 1 or 2 Advanced Setting: Enable

server activation server to be used as SOAP
web services
0- not activated
1- SOAP server function
Enabled (no restriction)
2- SOAP server function
Enabled - IP address
restricted
SOAP client IP set to Client IP if option 2 Advanced Setting: IP con-

is preferred for security figuration (used when
SOAP server IP address
restriction is configured)
Activating SOAP wsdl file

SOAP wsdl file is provided on the following path: /home/ixi-
a/Hawkeye/WebServer/WebServices/Hawkeye.wsdl
Hence, from client it needs to be called from: https://<serverip>/We-

bServices/Hawkeye.wsdl
Modification needs to be done in the Hawkeye.wsdl file to get access to the APIs. On
Hawkeye server login as root and edit the following file:
/home/ixia/Hawkeye/WebServer/WebServices/Hawkeye.wsdl
replace the following line:

<soap:address loc-
ation="http://127.0.0.1:80/WebServices/HawkeyeWebService.php"/> 
with your server access (IP or url) and https instead of http if relevant
Example:
<soap:address loc-
ation="https://myHawkeyeServerURL/WebServices/HawkeyeWebService.php"/> 
SOAP API guide

The complete list of messages available can be found in the following file on the
Hawkeye server: /home/ixia/Hawkeye/WebServer/WebServices/Hawkeye.wsdl. The
following are the list of available API in Hawkeye.
addGroupAndTestTypesRequest
This is used to add a new group/ update an existing group into Hawkeye.
Input:
Name: string - the name of the group
Comment: string - an optional comment
allowedtestypesStringArray: string - comma-separated string with the allowed test

types ids
allowedprobesStringArray: string - comma-separated string with the allowed probes ids

<x:Envelope xmlns:x="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:urn="urn:Hawkeye">
<x:Header/>
<x:Body>
<urn:addGroupAndTestTypes>
<urn:Name>?</urn:Login>
<urn:Comment>?</urn:FirstName>
<urn:allowedtestypesStringArray>?</urn:LastName>
<urn:allowedprobesStringArray>?</urn:email>
</urn:addGroupAndTestTypes>
</x:Body>

addGroupAndTestTypesResponse
Output:
integer - the id of the group added

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV-
V="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="urn:Hawkeye"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:x-
si="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC-
C="http://schemas.xmlsoap.org/soap/encoding/" SOAP-
ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1:addGroupAndTestTypesResponse>
<return xsi:type="xsd:string">2</return>
</ns1:addGroupAndTestTypesResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
addProbe
This is used to add a new Probe into Hawkeye. This is only relevant for Manual probes
and not required for any Automatic probes (which we recommend).
Parameters
probename - string - the name for the probe
probeip - string - the IP for the probe test interface
probemgmtip- string - the IP for the probe management interface
probegroup- string - the IP for the probe management interface
probelocation- string - the IP for the probe management interface
probetypeid - integer - the id for the probe you are adding
available id are
"2";"Software"
"6";"xr2000"
"7";"xr2000_vm"

"8";"xr_pi"
probeAvailability- integer -
0 for for both from and to
1 for from only
2 for to only
AvailableForMesh - integer - 0 for not available, 1 for not available

<x:Header/>
<x:Body>
<urn:addProbe>
<urn:probename>?</urn:probename>
<urn:probeip>?</urn:probeip>
<urn:probemgmtip>?</urn:probemgmtip>
<urn:probegroup>?</urn:probegroup>
<urn:probelocation>?</urn:probelocation>
<urn:probetypeid>?</urn:probetypeid>
<urn:probeAvailability>?</urn:probeAvailability>
<urn:AvailableForMesh>?</urn:AvailableForMesh>
</urn:addProbe>
</x:Body>
output
0: failed to add
1: added
addUser
This is used to add a new user/ update an existing user into Hawkeye.
Input:
Login: string - the user login
FirstName: string - user's first name
LastName: string - user's last name
email: string - user's email

GroupID: string - the group ID
memberlevel: integer - the member level
Password: user's password
IsActive: user's status

<x:Header/>
<x:Body>
<urn:addUser>
<urn:Login>?</urn:Login>
<urn:FirstName>?</urn:FirstName>
<urn:LastName>?</urn:LastName>
<urn:email>?</urn:email>
<urn:GroupID>?</urn:GroupID>
<urn:memberlevel>?</urn:memberlevel>
<urn:IsActive>?</urn:IsActive>
</urn:addUser>
</x:Body>
addUserResponse
Output:
API returns the id (integer) of the user added

<SOAP-ENV:Body>
<ns1:addUserResponse>
</ns1:addUserResponse>
</SOAP-ENV:Body>

cancelTestExecution
This is used to pause/remove a test execution.
Input:
ID: string - the test execution ID
Pause: 0 - pause , 1 - remove the test execution

<x:Header/>
<x:Body>
<urn:cancelTestExecution>
<urn:ID>?</urn:ID>
<urn:Pause>?</urn:Pause>
</urn:cancelTestExecution>
</x:Body>
cancelTestExecutionResponse
Output:
integer - 1 if operation finished successfully, 0 otherwise

<SOAP-ENV:Body>
<ns1:cancelTestExecutionResponse>
</ns1:cancelTestExecutionResponse>
</SOAP-ENV:Body>
checkTestExecutionResultStatus
This is used to find out about the test execution based on a test execution ID that was
created with API or manually on the UI.

This returns the last TDR ID found into the database for this execution ID
Parameters:
execID: corresponds to test execution ID
<x:Header/>
<x:Body>
<urn:checkTestExecutionResultStatus>
<urn:execID>?</urn:execID>
</urn:checkTestExecutionResultStatus>
</x:Body>
</x:Envelope>
output:
0: no test data record found
>0: latest Test data record ID found

<SOAP-ENV:Body>
<ns1:checkTestExecutionResultStatusResponse>
</ns1:checkTestExecutionResultStatusResponse>
</SOAP-ENV:Body>
collectTestExecutionResultRange
This api allows to search results for a specific test execution ID and collects all the
information on kpis for a number of test results in history - limited to 1000 test results.
Output is in json

Parameters:
testExecID: corresponds to test execution ID for which to run the search
NumberofResults: number of results to look for - results will provided from most recent
to least recent. The limit for the number of results in time interval is 1000 - an error will
be returned for higher values. For latest results in the interval pick 1 for this value.
fromDate: start date of interval - format is YYYY-MM-DD HH:mm:ss (example 2016-02-

01 20:07:15) - use "Start" for looking into any results in the past
toDate: end date of interval - format is YYYY-MM-DD HH:mm:ss (example 2016-02-01

20:07:15) - . Use "Now" for current date.
<x:Header/>
<x:Body>
<urn:collectTestExecutionResultRange>
<urn:testExecID>10</urn:testExecID>
<urn:NumberofResults>10</urn:NumberofResults>
<urn:fromDate>2010-01-01 00:00:00</urn:fromDate>
<urn:toDate>Now</urn:toDate>
</urn:collectTestExecutionResultRange>
</x:Body>
</x:Envelope>
output: a result in json format with fields populated describing TDR, result (one line per
metric)
example:
[{"ID":"14547914077197","Value":"2053.64","METRIC":"Download Rate
(kbps)","PAIR_NAME":"HTTP Server Test","NODEFROM_NAME":"xrpi2Par-
is","NODETO_NAME":"www.google.com","TIMESTAMP":"2016-02-06
21:43:27","STATUS":"Passed","REASON_CAUSE":"","TDR_com-
ment":"DownloadFullPage: 1 ip_version: ipv4 UseProxy: 0 ProxyAddress:
","MODULE":"RealService","TESTTYPE_ID":"5140","TESTTYPE":"HTTP Server
Test","MESHID":"0","MESHNAME":"","NODEFROM_PROBEID":"51150","NODETO_
PROBEID":"0","NODEFROM_IP":"10.204.20.27","NODETO_IP":"","NODEFROM_
MGMTIP":"10.204.20.27","NODETO_MGMTIP":"","NODEFROM_
LOCATION":"TEST","NODETO_LOCATION":"","NODEFROM_PROBE_GROUP":"","NODETO_

PROBE_GROUP":"","EXECUTION_USER_ID":"1","EXECUTION_USER_LOGIN":"sysad-
min","TEST_DURATION":"0","TESTEXEC_ID":"23552","TESTEXEC_STRING":""},
{"ID":"14547914077197","Value":"261","METRIC":"Download Time
(msec)","PAIR_NAME":"HTTP Server Test","NODEFROM_NAME":"xrpi2Par-
{"ID":"14547914077197","Value":"67","METRIC":"Files Size (kB)","PAIR_
NAME":"HTTP Server Test","NODEFROM_NAME":"xrpi2Paris","NODETO_
NAME":"www.google.com","TIMESTAMP":"2016-02-06
{"ID":"14547914077197","Value":"6","METRIC":"Number Of Files","PAIR_
{"ID":"14547914077197","Value":"100.14","METRIC":"Time to First Byte Avg
(ms)","PAIR_NAME":"HTTP Server Test","NODEFROM_

NAME":"xrpi2Paris","NODETO_NAME":"www.google.com","TIMESTAMP":"2016-02-
06 21:43:27","STATUS":"Passed","REASON_CAUSE":"","TDR_com-
{"ID":"14547914077197","Value":"206","METRIC":"Time to First Byte Max
(ms)","PAIR_NAME":"HTTP Server Test","NODEFROM_NAME":"xrpi2Par-
{"ID":"14547736316850","Value":"755.99","METRIC":"Download Rate
(kbps)","PAIR_NAME":"HTTP Server Test","NODEFROM_NAME":"xrpi2Par-
{"ID":"14547736316850","Value":"709","METRIC":"Download Time
(msec)","PAIR_NAME":"HTTP Server Test","NODEFROM_NAME":"xrpi2Par-

{"ID":"14547736316850","Value":"67","METRIC":"Files Size (kB)","PAIR_
{"ID":"14547736316850","Value":"6","METRIC":"Number Of Files","PAIR_
{"ID":"14547736316850","Value":"314.57","METRIC":"Time to First Byte Avg

{"ID":"14547736316850","Value":"364","METRIC":"Time to First Byte Max
min","TEST_DURATION":"0","TESTEXEC_ID":"23552","TESTEXEC_STRING":""}]
return 0 if no results are found , and ERROR with indication in case of errors in input para-
meters
collectAverageKPIresult
This function will allow to return an array of results averaged over time for specific filters
set within the function
fromDate: date to gather data from - format is YYYY-MM-DD HH:mm:ss (example 2016-
02-01 20:07:15)
fromDate: date to gather data to- format is YYYY-MM-DD HH:mm:ss (example 2016-02-
01 20:07:15)
fromFilterType: type of filter to apply first
("MODULE","TESTTYPE_ID","TESTTYPE","MESHID","MESHNAME","NODEFROM_
PROBEID","NODETO_PROBEID","STATUS","NODEFROM_IP","NODETO_IP","NODEFROM_
MGMTIP","NODETO_MGMTIP","NODEFROM_NAME","NODETO_NAME","NODEFROM_
LOCATION","NODETO_LOCATION","NODEFROM_PROBE_GROUP","NODETO_PROBE_
GROUP","EXECUTION_USER_ID","EXECUTION_USER_LOGIN","TDR_comment","TEST_
DURATION","TESTEXEC_ID","TESTEXEC_STRING")
fromFilter: value of filter - % is wild card (example "node1" or "node%")
toFilterType: type of filter to apply second criteria

("MODULE","TESTTYPE_ID","TESTTYPE","MESHID","MESHNAME","NODEFROM_
PROBEID","NODETO_PROBEID","STATUS","NODEFROM_IP","NODETO_IP","NODEFROM_
MGMTIP","NODETO_MGMTIP","NODEFROM_NAME","NODETO_NAME","NODEFROM_
LOCATION","NODETO_LOCATION","NODEFROM_PROBE_GROUP","NODETO_PROBE_
GROUP","EXECUTION_USER_ID","EXECUTION_USER_LOGIN","TDR_comment","TEST_
DURATION","TESTEXEC_ID","TESTEXEC_STRING")
toFilter: value of filter - % is wild card (example "node1" or "node%")
TestType: filter for test type - leave to blank for not filtering-value of filter - % is wild
card
available values
"Adaptive Video"
"Adaptive video with network quality"
"BitTorrent"
"COS line qualification"
"DNS Response Time"
"DNS Test"
"DropBox Download"
"DropBox Upload"
"Email"
"Exchange_traffic"
"Flash RTMP"
"FTP Download"
"FTP Multistream Download"
"FTP Response Time"
"HTTP response time"
"HTTP Server Test"

"HTTP Server Test - Advanced"
"HTTP Test"
"HTTPS Test"
"ICMP performance"
"ICMP Test"
"IGMP Test"
"Skype4B Traffic"
"Skype4B Traffic from->to"
"Multicast Video over RTP"
"Netflix"
"Network KPI"
"Network KPI 3 COS"
"Network KPI Advanced"
"Network KPI bidirectionnal"
"Network KPI Low Bandwidth"
"Network KPI to->from"
"POP3 Response Time"
"SIP Response Time"
"SMTP Response Time"
"TCP ping"
"TCP Response Time"
"TCP Throughput Advanced"
"TCP Throughput bidirectional"
"TCP Throughput from->to 1 stream"
"TCP Throughput from->to N streams"

"TCP Throughput Optimized Window size"
"TCP Throughput to->from 1 stream"
"TCP Throughput to->from N streams"
"Traceroute"
"Traffic Mix - HTTP - Video - Voice"
"UDP ping"
"UDP Throughput Advanced"
"UDP Throughput bidirectional"
"UDP Throughput from->to"
"UDP Throughput from->to - 4 COS"
"UDP Throughput to->from"
"Video Stream"
"Voice bidirectional"
"Voice from->to"
"Voice N pairs - UDP Data bidirectional"
"Voice N Pairs bidirectional"
"Voice N Pairs Unidirectional"
"Wifi Connect"
"Wifi Inspect"
"Youtube"
"Youtube Test"
PairName: available for specific pair name - leave to blank for not filtering-value of filter
- % is wild card
available values

"KPI from->to"
"KPI to->from"
"TCP from->to N pairs"
"TCP from->to 1 pair"
"TCP to->from 1 pair"
"TCP to->from N pairs"
"TCP from->to"
"TCP to->from"
"UDP from->to"
"UDP to->from"
"Voice from->to"
"Voice to->from"
"SG0 COS"
"SG1 COS"
"SG2 COS"
"SG3 COS"
"SG4 COS"
"SG5 COS"
"SG6 COS"
"Network KPI from->to"
"Stream"
"Audio Stream"
"Video Stream"
"Video from->to"

"Audio RTP from->to"
"Audio RTP to->from"
"Video RTP from->to"
"Video RTP to->from"
"DNS"
"COS 1"
"COS 2"
"COS 3"
"Voice from->to AF31"
"Voice from->to AF41"
"Voice from->to Best Effort"
"Voice from->to EF"
"Voice to->from AF31"
"Voice to->from AF41"
"Voice to->from Best Effort"
"Voice to->from EF"
"Chassis Port-to-Port Traffic"
"TCP from->to AF11"
"TCP from->to AF21"
"TCP from->to AF31"
"TCP from->to HIGH"
"TCP from->to LOW"
"TCP from->to MEDIUM"
"Voice"
"Specific Test from->to"

"UDP transaction"
"TCP transaction"
"Exchange rcv"
"Exchange send"
"HTTP from->to"
"Voice from->to G711"
"Voice to->from G711"
"HTTP Response Time"
"HTTPS Response Time"
"POP3 Response"
"SMTP Response"
"FTP Response Time"
"SIP Response Time"
"LDAP Response Time - Enterprise"
"DNS Response Time"
"TCP Response Time"
"UDP from->to COS1"
"UDP from->to COS2"
"UDP from->to COS3"
"UDP from->to COS4"
"UDP from->to COS5"
"UDP from->to COS6"
Metric: selected metric to filter on - can be left blank for not filtering (not recom-
mended)-value of filter - % is wild card

List of available metrics
"Avg Video Playback Rate (bps)"
"Avg Video Prebuffering Duration (ms)"
"Jitter Buffer Full Count"
"Jitter Buffer Full Duration (ms)"
"Throughput from->to (kbps)"
"Video Playback Downshifts"
"Video Playback Upshifts"
"Video Quality Segments - High"
"Video Quality Segments - Low"
"Video Quality Segments - Medium"
"Video Quality Segments - Very High"
"Video Quality Segments - Very Low"
"Video Stopped Count"
"Video Stopped Duration (ms)"
"Datagrams Out of Order"
"Delay (ms)"
"Delay Max (ms)"
"Delay Min (ms)"
"Jitter (ms)"
"Jitter Max (ms)"
"Jitter Min (ms)"
"Loss"
"Max loss burst"
"Throughput Video (kbps)"

"Total Bytes Lost"
"Video MDI Delay Factor"
"Video MDI Media Loss Rate"
"Throughput Audio (kbps)"
"Max Jitter (ms)"
"Throughput (kbps)"
"MOS"
"MOS Max"
"MOS Min"
"Voice Throughput (kbps)"
"Throughput to->from (kbps)"
"Throughput to->from Max (kbps)"
"Throughput to->from Min (kbps)"
"Throughput UDP from->to (kbps)"
"Throughput UDP from->to Max (kbps)"
"Throughput UDP from->to Min (kbps)"
"Throughput from->to Max (kbps)"
"Throughput from->to Min (kbps)"
"Throughput UDP to->from (kbps)"
"Throughput UDP to->from Max (kbps)"
"Throughput UDP to->from Min (kbps)"
"HTTP Throughput (kbps)"
"HTTP Transaction per sec"
"Bytes Rcvd by Probe from"
"Bytes Sent by Probe From"

"Response Time (sec)"
"Throughput Max (kbps)"
"Throughput Min (kbps)"
"Transaction per sec"
"Response Time (ms)"
"Transaction Rate (per sec)"
"Number of packets received"
"Number of packets sent"
"Download Rate (kbps)"
"Download Time (ms)"
"Files Size (kB)"
"Number Of Files"
"Time to First Byte Avg (ms)"
"Torrent Download Rate (kbps)"
"DNS Availability"
"DNS Response Time (ms)"
"Availability"
"Jitter (ms)"
"Jitter Max (ms)"
"Jitter standard deviation"
"Packet loss"
"Round trip time avg (ms)"
"Round trip time max (ms)"
"Round trip time min (ms)"
"Standard deviation (ms)"

"FTP Download Rate (kbps)"
"Video Download Rate (kbps)"
"Video Server - DNS response time (ms)"
"Video Server - ICMP jitter (ms)"
"Video Server - ICMP loss rate"
"Video Server - Intial buffering time (ms)"
"Video Server - Time to first video Byte (ms)"
"Video Server - Total time spent buffering (ms)"
"Video Server - Video rebuffering occurences"
"Authentication Availability"
"Response Time (sec)"
"Total Accepted Authentications"
"Total Denied Authentications"
"Total Lost Authentications"
"Speedtest Round Trip Delay (ms)"
"Speedtest TCP Downstream (kbps)"
"Speedtest TCP Upstream (kbps)"
"Frame delay (ms)"
"Frame Loss"
"TCP Packet loss"
"TCP Round trip time avg (ms)"
"TCP Round trip time max (ms)"
"TCP Round trip time min (ms)"
"Application Latency (ms)"
"Bytes from server"

"TCP Latency (ms)"
"Total http download time (ms)"
"File Size (kb)"
"PADI packets"
"PADO packets"
"PPPOE response time (ms)"
"dhcp packets received"
"dhcp packets sent"
"DHCP response time (ms)"
"Average Packet Length"
"Interpacket arrival average (ms)"
"Interpacket arrival max (ms)"
"Interpacket arrival min (ms)"
"Interpacket arrival standard deviation (ms)"
"join delay (ms)"
"join latency (ms)"
"leave delay (ms)"
"leave latency (ms)"
"Loss rate"
"Maximum Loss Burst"
"Number Of flows"
"source throughput (kbps)"
"Throughput average (kbps)"
"Total kBytes Received"
"Total Packets Lost"

"Total Packets Received"
"Total stream duration (ms)"
"ts continuity error"
"ts duplicates"
"ts loss rate"
"ts number of segments"
"Interpacket gap avg (ms)"
"Interpacket gap max (ms)"
"Interpacket gap min (ms)"
"Kbytes received total"
"Loss rate avg"
"Loss rate max"
"Number of 1-DESCRIBE Message Sent"
"Number of 1-DESCRIBE Response received"
"Number of 2-SETUP Message Sent"
"Number of 2-SETUP Response received"
"Number of 3-PLAY Message Sent"
"Number of 3-PLAY Response received"
"Number of 4-TEARDOWN Message Sent"
"Number of 4-TEARDOWN Response received"
"Number of packets lost"
"Number of packets received"
"Number of RTP streams"
"Throughput avg (kbps)"
"FTP Upload Rate (kbps)"

"Average MDI DF"
"Duplicated packets"
"Max Loss Burst"
"MDI Media Loss Rate"
"Number of Bytes received"
"throughput (kbps)"
"TVQM average absolute MOS Video"
"TVQM average MOS Audio"
"TVQM average MOS Video"
"TVQM average relative MOS Video"
"TVQM average Video bandwidth"
"TVQM frame rate"
"TVQM packets discarded"
"TVQM packets received"
"TVQM peak Video bandwidth"
"Video Codec"
"UDP Packet loss"
"UDP Round trip time avg (ms)"
"UDP Round trip time max (ms)"
"UDP Round trip time min (ms)"
"ICMP loss"
"ICMP throughput (kbps)"
"1-Association time (ms)"
"2-Authentication time (ms)"
"3-Connect time (ms)"

"4-DHCP Handshake Time (ms)"
"Association Attempts"
"ICMP Packet loss"
"ICMP Round Trip avg"
"Signal Strength (%)"
"Total Connect Time (ms)"
"Wifi Signal Level (dBm)"
"Connectivity Status"
<x:Header/>
<x:Body>
<urn:collectAverageKPIresult>
<urn:fromDate>2014-02-01 20:07:15</urn:fromDate>
<urn:toDate>2016-02-01 20:07:15</urn:toDate>
<urn:fromFilterType></urn:fromFilterType>
<urn:fromFilter></urn:fromFilter>
<urn:toFilterType></urn:toFilterType>
<urn:toFilter></urn:toFilter>
<urn:TestType></urn:TestType>
<urn:PairName></urn:PairName>
<urn:Metric></urn:Metric>
</urn:collectAverageKPIresult>
</x:Body>
</x:Envelope>
output is an array with metrics
example
ErrorCode,Passed,Failed,myavg-
value,myvaluemin,myvaluemax,StandardDeviation,totalcount,threshold_min,-
threshold_max,threshold_type
0,1061481,287788,3.10,0.00,1280.00,5.97,1349269,5,8,0.0000

<SOAP-ENV:Body>
<ns1:collectAverageKPIresultResponse>
<return xsi:-
type-
="xsd:string">ErrorCode,Passed,Failed,myavgvalue,myvaluemin,myvaluemax,Standard
min,threshold_max,threshold_type
0,1061481,287788,3.10,0.00,1280.00,5.97,1349269,5,8,0.0000</return>
</ns1:collectAverageKPIresultResponse>
</SOAP-ENV:Body>
collectKPI_result
Use this function to collect the KPI information from a specific test result based on ID
Parameter
tdrID: ID of the test result to collect information from

<x:Header/>
<x:Body>
<urn:collectKPI_result>
<urn:tdrID>1666360</urn:tdrID>
</urn:collectKPI_result>
</x:Body>
</x:Envelope>
Result:
0 if no idea is found
string with full set of metrics information if it is available:
Example
TDR_ID METRIC PAIR_ID PAIR_NAME STATUS VALUE THRESHOLD THRESHOLDTYPE
"1666360" "Datagrams Out of Order" "15152" "KPI from->to" "Passed" "0" "1" "0"
"1666360" "Delay (ms)" "15152" "KPI from->to" "Passed" "10.43" "100" "0"

"1666360" "Jitter (ms)" "15152" "KPI from->to" "Failed" "9.57" "5" "0"
"1666360" "Jitter Max (ms)" "15152" "KPI from->to" "Failed" "15" "5" "0"
"1666360" "Loss" "15152" "KPI from->to" "Passed" "0" "0.2" "0"
"1666360" "Max loss burst" "15152" "KPI from->to" "Passed" "0" "2" "0"
"1666360" "MOS" "15152" "KPI from->to" "Passed" "4.24" "3.7" "1"

<SOAP-ENV:Body>
<ns1:collectKPI_resultResponse>
<return xsi:type="xsd:string">TDR_ID METRIC PAIR_ID PAIR_NAME STATUS
VALUE THRESHOLD THRESHOLDTYPE
"1666360" "Datagrams Out of Order" "15152" "KPI from->to" "Passed"
"0" "1" "0"
"1666360" "Delay (ms)" "15152" "KPI from->to" "Passed" "10.43"
"100" "0"
"1666360" "Jitter (ms)" "15152" "KPI from->to" "Failed" "9.57" "5"
"0"
"1666360" "Jitter Max (ms)" "15152" "KPI from->to" "Failed" "15"
"5" "0"
"1666360" "Loss" "15152" "KPI from->to" "Passed" "0" "0.2" "0"
"1666360" "Max loss burst" "15152" "KPI from->to" "Passed" "0" "2"
"0"
"1666360" "MOS" "15152" "KPI from->to" "Passed" "4.24" "3.7" "1"
</return>
</ns1:collectKPI_resultResponse>
</SOAP-ENV:Body>
collectTDR_result
This will collect test data result information about test ID
Parameter
tdrID: ID of the test result to collect information from

<x:Header/>
<x:Body>
<urn:collectTDR_result>
<urn:tdrID>1666360</urn:tdrID>
</urn:collectTDR_result>
</x:Body>
</x:Envelope>
Response contains array with TDR content
example:
ID NODEFROM_NAME NODETO_NAME TIMESTAMP STATUS REASON_CAUSE TDR_com-

ment MODULE TESTTYPE_ID TESTTYPE MESHID MESHNAME NODEFROM_PROBEID
NODETO_PROBEID NODEFROM_IP NODETO_IP NODEFROM_MGMTIP NODETO_MGMTIP
NODEFROM_LOCATION NODETO_LOCATION NODEFROM_PROBE_GROUP NODETO_
PROBE_GROUP EXECUTION_USER_ID EXECUTION_USER_LOGIN TEST_DURATION
TESTEXEC_ID TESTEXEC_STRING
"1666360" "AWSprivate2" "AWSprivate4" "2016-11-16 16:58:56" "Failed" " Threshold

failed on KPI from->to Jitter (ms)
Threshold failed on KPI from->to Jitter Max (ms)
" "N2N" "5129" "Network KPI" "0" "8" "9" "ip-10-1-1-139" "ip-10-1-1-143" "ip-10-1-1-
139" "ip-10-1-1-143" "1" "sysadmin" "15" "74" "webservice"
<SOAP-ENV:Body>
<ns1:collectTDR_resultResponse>
<return xsi:type="xsd:string">ID NODEFROM_NAME NODETO_NAME TIMESTAMP
STATUS REASON_CAUSE TDR_comment MODULE TESTTYPE_ID TESTTYPE MESHID
MESHNAME NODEFROM_PROBEID NODETO_PROBEID NODEFROM_IP NODETO_IP NODEFROM_
MGMTIP NODETO_MGMTIP NODEFROM_LOCATION NODETO_LOCATION NODEFROM_PROBE_
GROUP NODETO_PROBE_GROUP EXECUTION_USER_ID EXECUTION_USER_LOGIN TEST_
DURATION TESTEXEC_ID TESTEXEC_STRING

"1666360" "AWSprivate2" "AWSprivate4" "2016-11-16 16:58:56" "Failed"

" Threshold failed on KPI from->to Jitter (ms)
Threshold failed on KPI from->to Jitter Max (ms)
" "N2N" "5129" "Network KPI" "0" "8" "9" "ip-10-1-1-139" "ip-10-1-1-
143" "ip-10-1-1-139" "ip-10-1-1-143" "1" "sysadmin" "15" "74" "web-
service"
</return>
</ns1:collectTDR_resultResponse>
</SOAP-ENV:Body>
configureN2NListExecution
Use this function to setup a new test for Node to Node (prefer to configure TestEx-
ecution)
If using list of probes, you can create one to one or many to many combinations of tests
Parameters:
TestType : test type to trigger the test with
Includes
"Network KPI"

"Adapative Video"
"Flash RTMP"
"Netflix"
"Youtube"
"Skype4B Traffic"
"Video Stream"
"Network KPI 3 COS"
"Voice from->to"
"Exchange_traffic"
"HTTP Test"
"HTTPS Test"

"FTP Response Time"
"SIP Response Time"
"DNS Response Time"
"TCP Response Time"
NodeFrom: node List to use to start the test
Use commas between probe names
the probe needs to have an existing and active probe configured into db otherwise will
be ignored
Example : probe1,probe2
Nodeto: node List to use to start the test
be ignored
OneToOne: value is either 0 (many to many) or 1 (onetoone)
if using the list:
nodefrom: probe1,probe2
nodeto: probe3,probe4
the test that will be scheduled will look like
value 0: many to many

probe1->probe3
probe1->probe4
probe2->probe3
probe2->probe4
value 1: one to one
probe1->probe3
probe2->probe4
Frequency: frequency in minutes you want to run the test with
0 means one shot
EnforceSchedule: set the enforce scheduling to 0 (not enforce) or 1 (enforce)
mystartdate: schedule start date - format is YYYY-MM-DD HH:mm:ss (example 2016-

02-01 20:07:15)
Note: leave empty for starting now or for immediate one shot
myenddate: schedule end date - format is YYYY-MM-DD HH:mm:ss (example 2016-02-

01 20:07:15)
Note: leave empty for never ending schedule or one shot
arrayOptionsNameString: define the names of the options for the test
arrayOptionsValueString: define the values of the options for the test

Following table describe the parameter. for each test type, the options need to be put in
the exact order as detailed in the table below.
IF there is an associated pair (pair_id is not null), the name must be entered with fol-
lowing format in API:
ParameterName|SPECIFICPAIR|pair_id
If the pair_id is 0 then ParameterName is sufficient
arrayOptionsValueString will contain the exact value
Example for UDP throughput bidirectional test:
"UDP Throughput bidirectional";"packetsize";"Packet Size";"0";NULL
"UDP Throughput bidirectional";"QOS";"DSCP Setting";"0";NULL
"UDP Throughput bidirectional";"bitrate";"Throughput from->to (kbps)";"15161";"UDP

from->to"
"UDP Throughput bidirectional";"bitrate";"Throughput to->from (kbps)";"15162";"UDP

to->from"
arrayOptionsNameString
packetsize,QOS,bitrate|SPECIFICPAIR|15161,bitrate|SPECIFICPAIR|15162
arrayOptionsValueString
1400,EF,20000,40000
will set packetsize to 1400, QOS to EF, UDP from->to 20000kbps, UDP to->from to
40000kbps
"Test Name";"ParameterName";"Display Name";"assodciated pair_id";"Associated pair

Name"
"Adapative Video";"numberofpairs";"Number Of parallel Streams";"0";NULL
"Adapative Video";"BitRatesList";"Bitrates List (Mbps)";"6005";"Stream"

"Adapative Video";"QOS";"DSCP Setting";"6005";"Stream"
"Adaptive video with network quality";"numberofpairs";"Number Of parallel Stream-

s";"0";NULL
"Adaptive video with network quality";"QOS";"DSCP Setting";"0";NULL
"Adaptive video with network quality";"BitRatesList";"Bitrates List

(Mbps)";"6007";"Stream"
"COS line qualification";"filesize";"File Size (bytes)";"0";NULL
"COS line qualification";"DestinationPort";"Destination Port";"12111";"TCP from->to

HIGH"
"COS line qualification";"QOS";"DSCP Setting";"12111";"TCP from->to HIGH"

MEDIUM"
"COS line qualification";"QOS";"DSCP Setting";"12112";"TCP from->to MEDIUM"

LOW"
"COS line qualification";"QOS";"DSCP Setting";"12113";"TCP from->to LOW"
"COS line qualification";"bitrate";"Total bitrate (kbps)";"12114";"Voice"
"COS line qualification";"DestinationPort";"Destination Port";"12114";"Voice"
"COS line qualification";"QOS";"DSCP Setting";"12114";"Voice"
"DNS Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"DNS Response Time";"testscript";"Test Script";"0";NULL
"Exchange_traffic";"numberofpairs";"Number of Users";"0";NULL
"Exchange_traffic";"bitrate";"Total bitrate (kbps)";"31014";"Exchange send"
"Exchange_traffic";"filesize";"email size (kbytes)";"31014";"Exchange send"
"Exchange_traffic";"bitrate";"Total bitrate (kbps)";"31015";"Exchange rcv"
"Exchange_traffic";"filesize";"email size (kbytes)";"31015";"Exchange rcv"
"Flash RTMP";"numberofpairs";"Number Of parallel Streams";"0";NULL

"Flash RTMP";"QOS";"DSCP Setting";"0";NULL
"Flash RTMP";"BitRatesList";"Bitrates List (Mbps)";"6006";"Stream"
"FTP Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"FTP Response Time";"testscript";"Test Script";"0";NULL
"HTTP Test";"bitrate";"Total bitrate (kbps)";"0";NULL
"HTTP Test";"testscript";"Test Script";"0";NULL
"HTTPS Test";"bitrate";"Total bitrate (kbps)";"0";NULL
"HTTPS Test";"testscript";"Test Script";"0";NULL
"Skype4B Traffic";"numberofpairs";"Number Of Pairs";"0";NULL
"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7005";"Audio RTP from->to"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7005";"Audio RTP from->to"
"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7006";"Audio RTP to->from"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7006";"Audio RTP to->from"
"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7007";"Video RTP from->to"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7007";"Video RTP from->to"
"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7008";"Video RTP to->from"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7008";"Video RTP to->from"
"Skype4B Traffic from->to";"numberofpairs";"Number Of Pairs";"0";NULL
"Skype4B Traffic from->to";"bitrate";"Total bitrate (kbps)";"7009";"Audio RTP from-

>to"
"Skype4B Traffic from->to";"packetsize";"packet size (bytes)";"7009";"Audio RTP from-

>to"
"Skype4B Traffic from->to";"QOS";"DSCP Setting";"7009";"Audio RTP from->to"
"Skype4B Traffic from->to";"bitrate";"Total bitrate (kbps)";"7010";"Video RTP from-

>to"

"Skype4B Traffic from->to";"packetsize";"packet size (bytes)";"7010";"Video RTP from-

>to"
"Skype4B Traffic from->to";"QOS";"DSCP Setting";"7010";"Video RTP from->to"
"Multicast Video over RTP";"bitrate";"Total bitrate (kbps)";"0";NULL
"Multicast Video over RTP";"QOS";"DSCP Setting";"0";NULL
"Multicast Video over RTP";"MulticastAddressAndPort";"Multicast

Address:Port";"6010";"Video from->to"
"Netflix";"numberofpairs";"Number Of parallel Streams";"0";NULL
"Netflix";"QOS";"DSCP Setting";"0";NULL
"Netflix";"BitRatesList";"Video Rates";"15202";"Video Stream"
"Netflix";"BitRatesList";"Audio Rates";"15203";"Audio Stream"
"Network KPI";"QOS";"DSCP Setting";"0";NULL
"Network KPI 3 COS";"QOS";"DSCP Setting";"17459";"COS 1"
"Network KPI Advanced";"bitrate";"Total bitrate (kbps)";"0";NULL
"Network KPI Advanced";"packetsize";"packet size (bytes)";"0";NULL
"Network KPI Advanced";"QOS";"DSCP Setting";"0";NULL
"Network KPI bidirectionnal";"QOS";"DSCP Setting";"0";NULL
"Network KPI to->from";"QOS";"DSCP Setting";"0";NULL
"POP3 Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"POP3 Response Time";"testscript";"Test Script";"0";NULL
"SIP Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"SIP Response Time";"testscript";"Test Script";"0";NULL
"SMTP Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL

"SMTP Response Time";"testscript";"Test Script";"0";NULL
"TCP Response Time";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput Advanced";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput Advanced";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput Advanced";"filesize";"File Size (bytes)";"0";NULL
"TCP Throughput Advanced";"packetsize";"Send buffer Size";"0";NULL
"TCP Throughput Advanced";"DestinationPort";"Destination Port";"0";NULL
"TCP Throughput Advanced";"SourcePort";"Source Port";"0";NULL
"TCP Throughput Advanced";"sendsocketbuffer_e1";"send socket buffer e1";"0";NULL
"TCP Throughput Advanced";"sendsocketbuffer_e2";"send socketbuffer e2";"0";NULL
"TCP Throughput Advanced";"receivesocketbuffer_e1";"receive socketbuffer

e1";"0";NULL

e2";"0";NULL
"TCP Throughput bidirectional";"bitrate";"Throughput from->to (kbps)";"15157";"TCP

from->to"
"TCP Throughput bidirectional";"bitrate";"Throughput to->from (kbps)";"15158";"TCP

to->from"
"TCP Throughput from->to 1 stream";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput from->to 1 stream";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput from->to N streams";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput from->to N streams";"numberofpairs";"Number Of Pairs";"0";NULL
"TCP Throughput from->to N streams";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput Optimized Window size";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput Optimized Window size";"ExpectedLineDelay";"Expected Line One

Way Delay (ms)";"0";NULL
"TCP Throughput Optimized Window size";"filesize";"File Size (bytes)";"0";NULL

"TCP Throughput Optimized Window size";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput to->from 1 stream";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput to->from 1 stream";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput to->from N streams";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput to->from N streams";"numberofpairs";"Number Of Pairs";"0";NULL
"TCP Throughput to->from N streams";"QOS";"DSCP Setting";"0";NULL
"Traffic Mix - HTTP - Video - Voice";"bitrate";"Total bitrate (kbps)";"40013";"Video

from->to"
"Traffic Mix - HTTP - Video - Voice";"bitrate";"Total bitrate (kbps)";"40014";"HTTP

from->to"
"UDP Throughput Advanced";"bitrate";"Total bitrate (kbps)";"0";NULL
"UDP Throughput Advanced";"QOS";"DSCP Setting";"0";NULL
"UDP Throughput Advanced";"filesize";"File Size (bytes)";"0";NULL
"UDP Throughput Advanced";"packetsize";"Send buffer Size";"0";NULL
"UDP Throughput Advanced";"DestinationPort";"Destination Port";"0";NULL
"UDP Throughput Advanced";"SourcePort";"Source Port";"0";NULL

from->to"

to->from"
"UDP Throughput from->to";"bitrate";"Total bitrate (kbps)";"0";NULL
"UDP Throughput from->to";"packetsize";"Packet Size";"0";NULL
"UDP Throughput from->to";"QOS";"DSCP Setting";"0";NULL

"UDP Throughput from->to - 4 COS";"bitrate";"Total bitrate (kbps)";"83001";"UDP from-

>to COS1"
"UDP Throughput from->to - 4 COS";"packetsize";"Packet Size";"83001";"UDP from->to

COS1"
"UDP Throughput from->to - 4 COS";"QOS";"DSCP Setting";"83001";"UDP from->to

COS1"

>to COS2"

COS2"

COS2"

>to COS3"

COS3"

COS3"

>to COS4"

COS4"

COS4"
"UDP Throughput to->from";"bitrate";"Total bitrate (kbps)";"0";NULL
"UDP Throughput to->from";"packetsize";"Packet Size";"0";NULL
"UDP Throughput to->from";"QOS";"DSCP Setting";"0";NULL
"Video Stream";"bitrate";"Total bitrate (kbps)";"0";NULL
"Video Stream";"QOS";"DSCP Setting";"0";NULL

"Voice bidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice bidirectional";"QOS";"DSCP Setting";"0";NULL
"Voice from->to";"voicecodec";"Voice Codec";"0";NULL
"Voice from->to";"QOS";"DSCP Setting";"0";NULL
"Voice N pairs - UDP Data bidirectional";"bitrate";"Total bitrate (kbps)";"0";NULL
"Voice N pairs - UDP Data bidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice N pairs - UDP Data bidirectional";"packetsize";"Packet Size";"0";NULL
"Voice N pairs - UDP Data bidirectional";"numberofpairs";"Number Of Pairs";"0";NULL
"Voice N Pairs bidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice N Pairs bidirectional";"numberofpairs";"Number Of Pairs";"0";NULL
"Voice N Pairs bidirectional";"QOS";"DSCP Setting";"0";NULL
"Voice N Pairs Unidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice N Pairs Unidirectional";"numberofpairs";"Number Of Pairs";"0";NULL
"Voice N Pairs Unidirectional";"QOS";"DSCP Setting";"0";NULL
"Youtube";"numberofpairs";"Number Of parallel Streams";"0";NULL
"Youtube";"QOS";"DSCP Setting";"0";NULL
"Youtube";"BitRatesList";"Video Rates";"15204";"Video Stream"
thresholdArrayString sets specific threshold parameters - leave empty to use default

threashold settings
AlarmType:0 -no alarm
1-email
2-snmp
3- email And snmp

FailedAlarm-
0 - do not raise alarm on fail
1 - do raise alarm on fail
ErrorAlarm-
0 - do not raise alarm on error
1 - do raise alarm on error
StatusChangeAlarm-
0 - do not raise alarm on statuschange
1 - do raise alarm on statuschange
EmailAddress - string - email address so to send email alarm to
TESTEXEC_STRING: string - used for marking the test, and filtering
mytestduration: test duration for the execution
<x:Header/>
<x:Body>
<urn:configureN2NListExecution>
<urn:TestType>Network KPI</urn:TestType>
<urn:NodeFrom>AWSprivate2</urn:NodeFrom>
<urn:NodeTo>AWSprivate4,AWSprivate3,AWSprivate5</urn:NodeTo>
<urn:OneToOne>0</urn:OneToOne>
<urn:Frequency>0</urn:Frequency>

<urn:EnforceSchedule>0</urn:EnforceSchedule>
<urn:mystartdate></urn:mystartdate>
<urn:myenddate></urn:myenddate>
<urn:arrayOptionsNameString>null</urn:arrayOptionsNameString>
<urn:arrayOptionsValueString>null</urn:arrayOptionsValueString>
<urn:thresholdArrayString>null</urn:thresholdArrayString>
<urn:AlarmType>0</urn:AlarmType>
<urn:FailedAlarm>0</urn:FailedAlarm>
<urn:ErrorAlarm>0</urn:ErrorAlarm>
<urn:StatusChangeAlarm>0</urn:StatusChangeAlarm>
<urn:EmailAddress></urn:EmailAddress>
<urn:TESTEXEC_STRING>webservice</urn:TESTEXEC_STRING>
<urn:mytestduration>15</urn:mytestduration>
</urn:configureN2NListExecution>
</x:Body>
</x:Envelope>
output:
response with 0 in case no test was able to be configured
response with array of executed test paths and Test execution ID if the test could be
added to the execution list
Example of output
(AWSprivate2,AWSprivate4,74),(AWSprivate2,AWSprivate3,75),
(AWSprivate2,AWSprivate5,76)

<SOAP-ENV:Body>
<ns1:configureN2NListExecutionResponse>
<return xsi:type="xsd:string">(AWSprivate2,AWSprivate4,74),
(AWSprivate2,AWSprivate3,75),(AWSprivate2,AWSprivate5,76)</return>
</ns1:configureN2NListExecutionResponse>
</SOAP-ENV:Body>

configureTestExecution
Use this function to setup a new test for Node to Node or Real service
Parameters:
Type:
"N2N": defines node to node
"RealService": defines RealService
TestType : test type to trigger the test with
Includes
"Network KPI"

"Adapative Video"
"Flash RTMP"
"Netflix"
"Youtube"
"Skype4B Traffic"
"Video Stream"
"Network KPI 3 COS"
"Voice from->to"
"Exchange_traffic"
"HTTP Test"
"HTTPS Test"
"FTP Response Time"
"SIP Response Time"

"DNS Response Time"
"TCP Response Time"
for real services
"BitTorrent"
"DNS Test"
"DropBox Download"
"DropBox Upload"
"Email"
"FTP Download"
"FTP Multistream Download"
"HTTP response time"
"HTTP Server Test"
"HTTP Server Test - Advanced"
"ICMP performance"
"ICMP Test"
"IGMP Test"
"TCP ping"
"Traceroute"
"UDP ping"
"Wifi Connect"
"Wifi Inspect"
"Youtube Test"

isMesh= defines if the mesh option should be used
0 - nodefrom and nodeto will be used for node to node, Meshid ignored
1- meshid will be used, nodefrom and nodeto will be ignored
myMesh - defines meshID for the test (integer)
NodeFrom: node List to use to start the test
be ignored
Nodeto: node List to use to start the test - ignored for real services
be ignored
Frequency: frequency in minutes you want to run the test with
0 means one shot
EnforceSchedule: set the enforce scheduling to 0 (not enforce) or 1 (enforce)

mystartdate: schedule start date - format is YYYY-MM-DD HH:mm:ss (example 2016-

02-01 20:07:15)
Note: leave empty for starting now or for immediate one shot
myenddate: schedule end date - format is YYYY-MM-DD HH:mm:ss (example 2016-02-

01 20:07:15)
Note: leave empty for never ending schedule or one shot
arrayOptionsNameString: define the names of the options for the test
arrayOptionsValueString: define the values of the options for the test
following table describe the parameter. for each test type, the options need to be put in
the exact order as detailed in the table below.
IF there is an associated pair (pair_id is not null), the name must be entered with fol-
lowing format in API:
ParameterName|SPECIFICPAIR|pair_id
If the pair_id is 0 then ParameterName is sufficient
arrayOptionsValueString will contain the exact value
Example for UDP throughput bidirectional test:

from->to"

to->from"

arrayOptionsNameString
packetsize,QOS,bitrate|SPECIFICPAIR|15161,bitrate|SPECIFICPAIR|15162
arrayOptionsValueString
1400,EF,20000,40000
will set packetsize to 1400, QOS to EF, UDP from->to 20000kbps, UDP to->from to
40000kbps
"Test Name";"ParameterName";"Display Name";"assodciated pair_id";"Associated pair

Name"
"Adapative Video";"numberofpairs";"Number Of parallel Streams";"0";NULL
"Adapative Video";"BitRatesList";"Bitrates List (Mbps)";"6005";"Stream"
"Adapative Video";"QOS";"DSCP Setting";"6005";"Stream"
"Adaptive video with network quality";"numberofpairs";"Number Of parallel Stream-

s";"0";NULL
"Adaptive video with network quality";"QOS";"DSCP Setting";"0";NULL
"Adaptive video with network quality";"BitRatesList";"Bitrates List

(Mbps)";"6007";"Stream"
"COS line qualification";"filesize";"File Size (bytes)";"0";NULL

HIGH"
"COS line qualification";"QOS";"DSCP Setting";"12111";"TCP from->to HIGH"

MEDIUM"
"COS line qualification";"QOS";"DSCP Setting";"12112";"TCP from->to MEDIUM"

LOW"

"COS line qualification";"QOS";"DSCP Setting";"12113";"TCP from->to LOW"
"COS line qualification";"bitrate";"Total bitrate (kbps)";"12114";"Voice"
"COS line qualification";"DestinationPort";"Destination Port";"12114";"Voice"
"COS line qualification";"QOS";"DSCP Setting";"12114";"Voice"
"DNS Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"DNS Response Time";"testscript";"Test Script";"0";NULL
"Exchange_traffic";"numberofpairs";"Number of Users";"0";NULL
"Exchange_traffic";"bitrate";"Total bitrate (kbps)";"31014";"Exchange send"
"Exchange_traffic";"filesize";"email size (kbytes)";"31014";"Exchange send"
"Exchange_traffic";"bitrate";"Total bitrate (kbps)";"31015";"Exchange rcv"
"Exchange_traffic";"filesize";"email size (kbytes)";"31015";"Exchange rcv"
"Flash RTMP";"numberofpairs";"Number Of parallel Streams";"0";NULL
"Flash RTMP";"QOS";"DSCP Setting";"0";NULL
"Flash RTMP";"BitRatesList";"Bitrates List (Mbps)";"6006";"Stream"
"FTP Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"FTP Response Time";"testscript";"Test Script";"0";NULL
"HTTP Test";"bitrate";"Total bitrate (kbps)";"0";NULL
"HTTP Test";"testscript";"Test Script";"0";NULL
"HTTPS Test";"bitrate";"Total bitrate (kbps)";"0";NULL
"HTTPS Test";"testscript";"Test Script";"0";NULL
"Skype4B Traffic";"numberofpairs";"Number Of Pairs";"0";NULL
"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7005";"Audio RTP from->to"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7005";"Audio RTP from->to"
"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7006";"Audio RTP to->from"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7006";"Audio RTP to->from"

"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7007";"Video RTP from->to"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7007";"Video RTP from->to"
"Skype4B Traffic";"bitrate";"Total bitrate (kbps)";"7008";"Video RTP to->from"
"Skype4B Traffic";"packetsize";"packet size (bytes)";"7008";"Video RTP to->from"
"Skype4B Traffic from->to";"numberofpairs";"Number Of Pairs";"0";NULL
"Skype4B Traffic from->to";"bitrate";"Total bitrate (kbps)";"7009";"Audio RTP from-

>to"
"Skype4B Traffic from->to";"packetsize";"packet size (bytes)";"7009";"Audio RTP from-

>to"
"Skype4B Traffic from->to";"QOS";"DSCP Setting";"7009";"Audio RTP from->to"
"Skype4B Traffic from->to";"bitrate";"Total bitrate (kbps)";"7010";"Video RTP from-

>to"
"Skype4B Traffic from->to";"packetsize";"packet size (bytes)";"7010";"Video RTP from-

>to"
"Skype4B Traffic from->to";"QOS";"DSCP Setting";"7010";"Video RTP from->to"
"Multicast Video over RTP";"bitrate";"Total bitrate (kbps)";"0";NULL
"Multicast Video over RTP";"QOS";"DSCP Setting";"0";NULL
"Multicast Video over RTP";"MulticastAddressAndPort";"Multicast

Address:Port";"6010";"Video from->to"
"Netflix";"numberofpairs";"Number Of parallel Streams";"0";NULL
"Netflix";"QOS";"DSCP Setting";"0";NULL
"Netflix";"BitRatesList";"Video Rates";"15202";"Video Stream"
"Netflix";"BitRatesList";"Audio Rates";"15203";"Audio Stream"
"Network KPI";"QOS";"DSCP Setting";"0";NULL

"Network KPI Advanced";"bitrate";"Total bitrate (kbps)";"0";NULL
"Network KPI Advanced";"packetsize";"packet size (bytes)";"0";NULL
"Network KPI Advanced";"QOS";"DSCP Setting";"0";NULL
"Network KPI bidirectionnal";"QOS";"DSCP Setting";"0";NULL
"Network KPI to->from";"QOS";"DSCP Setting";"0";NULL
"POP3 Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"POP3 Response Time";"testscript";"Test Script";"0";NULL
"SIP Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"SIP Response Time";"testscript";"Test Script";"0";NULL
"SMTP Response Time";"bitrate";"Total bitrate (kbps)";"0";NULL
"SMTP Response Time";"testscript";"Test Script";"0";NULL
"TCP Response Time";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput Advanced";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput Advanced";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput Advanced";"filesize";"File Size (bytes)";"0";NULL
"TCP Throughput Advanced";"packetsize";"Send buffer Size";"0";NULL
"TCP Throughput Advanced";"DestinationPort";"Destination Port";"0";NULL
"TCP Throughput Advanced";"SourcePort";"Source Port";"0";NULL
"TCP Throughput Advanced";"sendsocketbuffer_e1";"send socket buffer e1";"0";NULL
"TCP Throughput Advanced";"sendsocketbuffer_e2";"send socketbuffer e2";"0";NULL

e1";"0";NULL

e2";"0";NULL
"TCP Throughput bidirectional";"bitrate";"Throughput from->to (kbps)";"15157";"TCP

from->to"

"TCP Throughput bidirectional";"bitrate";"Throughput to->from (kbps)";"15158";"TCP

to->from"
"TCP Throughput from->to 1 stream";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput from->to 1 stream";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput from->to N streams";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput from->to N streams";"numberofpairs";"Number Of Pairs";"0";NULL
"TCP Throughput from->to N streams";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput Optimized Window size";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput Optimized Window size";"ExpectedLineDelay";"Expected Line One

Way Delay (ms)";"0";NULL
"TCP Throughput Optimized Window size";"filesize";"File Size (bytes)";"0";NULL
"TCP Throughput Optimized Window size";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput to->from 1 stream";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput to->from 1 stream";"QOS";"DSCP Setting";"0";NULL
"TCP Throughput to->from N streams";"bitrate";"Total bitrate (kbps)";"0";NULL
"TCP Throughput to->from N streams";"numberofpairs";"Number Of Pairs";"0";NULL
"TCP Throughput to->from N streams";"QOS";"DSCP Setting";"0";NULL
"Traffic Mix - HTTP - Video - Voice";"bitrate";"Total bitrate (kbps)";"40013";"Video

from->to"
"Traffic Mix - HTTP - Video - Voice";"bitrate";"Total bitrate (kbps)";"40014";"HTTP

from->to"
"UDP Throughput Advanced";"bitrate";"Total bitrate (kbps)";"0";NULL
"UDP Throughput Advanced";"QOS";"DSCP Setting";"0";NULL
"UDP Throughput Advanced";"filesize";"File Size (bytes)";"0";NULL
"UDP Throughput Advanced";"packetsize";"Send buffer Size";"0";NULL
"UDP Throughput Advanced";"DestinationPort";"Destination Port";"0";NULL

"UDP Throughput Advanced";"SourcePort";"Source Port";"0";NULL

from->to"

to->from"
"UDP Throughput from->to";"bitrate";"Total bitrate (kbps)";"0";NULL
"UDP Throughput from->to";"packetsize";"Packet Size";"0";NULL
"UDP Throughput from->to";"QOS";"DSCP Setting";"0";NULL

>to COS1"

COS1"

COS1"

>to COS2"

COS2"

COS2"

>to COS3"

COS3"

COS3"


>to COS4"

COS4"

COS4"
"UDP Throughput to->from";"bitrate";"Total bitrate (kbps)";"0";NULL
"UDP Throughput to->from";"packetsize";"Packet Size";"0";NULL
"UDP Throughput to->from";"QOS";"DSCP Setting";"0";NULL
"Video Stream";"bitrate";"Total bitrate (kbps)";"0";NULL
"Video Stream";"QOS";"DSCP Setting";"0";NULL
"Voice bidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice bidirectional";"QOS";"DSCP Setting";"0";NULL
"Voice from->to";"voicecodec";"Voice Codec";"0";NULL
"Voice from->to";"QOS";"DSCP Setting";"0";NULL
"Voice N pairs - UDP Data bidirectional";"bitrate";"Total bitrate (kbps)";"0";NULL
"Voice N pairs - UDP Data bidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice N pairs - UDP Data bidirectional";"packetsize";"Packet Size";"0";NULL
"Voice N pairs - UDP Data bidirectional";"numberofpairs";"Number Of Pairs";"0";NULL
"Voice N Pairs bidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice N Pairs bidirectional";"numberofpairs";"Number Of Pairs";"0";NULL
"Voice N Pairs bidirectional";"QOS";"DSCP Setting";"0";NULL
"Voice N Pairs Unidirectional";"voicecodec";"Voice Codec";"0";NULL
"Voice N Pairs Unidirectional";"numberofpairs";"Number Of Pairs";"0";NULL
"Voice N Pairs Unidirectional";"QOS";"DSCP Setting";"0";NULL
"Youtube";"numberofpairs";"Number Of parallel Streams";"0";NULL

"Youtube";"QOS";"DSCP Setting";"0";NULL
"Youtube";"BitRatesList";"Video Rates";"15204";"Video Stream"
For real services the parameters include:
"BitTorrent";"DestinationServer";"Torrent Name";"0";NULL
"BitTorrent";"magnet";"Torrent link";"0";NULL
"BitTorrent";"duration";"Test duration";"0";NULL
"DNS Test";"DestinationServer";"DNS Server IP address (default uses con-

figured)";"0";NULL
"DNS Test";"NameToResolve";"Name to resolve";"0";NULL
"DropBox Download";"DestinationServer";"DropBox File";"0";NULL
"DropBox Download";"Timeout";"Timeout (sec)";"0";NULL
"DropBox Upload";"DestinationServer";"DropBox File";"0";NULL
"DropBox Upload";"Timeout";"Timeout (sec)";"0";NULL
"Email";"email";"Email Address";"0";NULL
"Email";"smtp";"Outgoing mail server (SMTP)";"0";NULL
"Email";"smtpport";"Outgoing mail port";"0";NULL
"Email";"smtpAUTHprotocol";"SMTP authentication protocol";"0";NULL
"Email";"smtpuser";"SMTPAUTH User (if needed)";"0";NULL
"Email";"smtppass";"SMTPAUTH Password (if needed)";"0";NULL
"Email";"imap";"Incoming mail server";"0";NULL
"Email";"imapport";"Incoming mail port";"0";NULL
"Email";"mailproto";"Incoming mail protocol";"0";NULL
"Email";"authuser";"Mail User";"0";NULL
"Email";"authpass";"Mail Password";"0";NULL

"FTP Download";"DestinationServer";"Destination Server";"0";NULL
"FTP Download";"DownloadFile";"Downlad File";"0";NULL
"FTP Download";"FTP_auth";"Use Authentication";"0";NULL
"FTP Download";"UserName";"User name";"0";NULL
"FTP Download";"UsePassiveMode";"Use Passive Mode";"0";NULL
"FTP Download";"Password";"Password";"0";NULL
"FTP Download";"Timeout";"Timeout (sec)";"0";NULL
"FTP Multistream Download";"DestinationServer";"Destination Server";"0";NULL
"FTP Multistream Download";"Timeout";"Timeout (sec)";"0";NULL
"FTP Multistream Download";"DownloadFile";"Downlad File";"0";NULL
"FTP Multistream Download";"FTP_auth";"Use Authentication";"0";NULL
"FTP Multistream Download";"UserName";"User name";"0";NULL
"FTP Multistream Download";"numberofstreams";"Number Of Streams";"0";NULL
"FTP Multistream Download";"Password";"Password";"0";NULL
"HTTP response time";"DestinationServer";"Destination Page (web-

server/page)";"0";NULL
"HTTP response time";"Protocol";"Protocol";"0";NULL
"HTTP response time";"NumberofTests";"Number of Tests";"0";NULL
"HTTP response time";"RealServiceCOS";"Class of Service";"0";NULL
"HTTP response time";"UseProxy";"Use Proxy Server";"0";NULL
"HTTP response time";"ip_version";"ip protocol";"0";NULL
"HTTP response time";"ProxyAddress";"Proxy Address";"0";NULL
"HTTP Server Test";"DestinationServer";"Destination Servers";"0";NULL
"HTTP Server Test";"DownloadFullPage";"Download Full Page";"0";NULL
"HTTP Server Test";"ip_version";"ip protocol";"0";NULL

"HTTP Server Test";"UseProxy";"Use Proxy Server";"0";NULL
"HTTP Server Test";"ProxyAddress";"Proxy Address";"0";NULL
"HTTP Server Test";"UserAgentString";"User Agent String";"0";NULL
"HTTP Server Test - Advanced";"DestinationServer";"Destination Servers";"0";NULL
"HTTP Server Test - Advanced";"DownloadFullPage";"Download Full Page";"0";NULL
"HTTP Server Test - Advanced";"DNSServer";"DNS Server";"0";NULL
"HTTP Server Test - Advanced";"ip_version";"ip protocol";"0";NULL
"HTTP Server Test - Advanced";"UseProxy";"Use Proxy Server";"0";NULL
"HTTP Server Test - Advanced";"ProxyAddress";"Proxy Address";"0";NULL
"HTTP Server Test - Advanced";"UserAgentString";"User Agent String";"0";NULL
"ICMP performance";"DestinationServer";"Destination Server";"0";NULL
"ICMP performance";"throughput";"Throughput (kbps)";"0";NULL
"ICMP performance";"ICMP_PacketSize";"Packet Size";"0";NULL
"ICMP performance";"TestDurationSeconds";"Test Duration (Seconds)";"0";NULL
"ICMP performance";"RealServiceCOS";"Class of Service";"0";NULL
"ICMP Test";"DestinationServer";"Destination Servers";"0";NULL
"ICMP Test";"PingInterval";"Interval";"0";NULL
"ICMP Test";"PingCount";"Count";"0";NULL
"ICMP Test";"PingPacketSize";"Packet Size";"0";NULL
"ICMP Test";"ip_version";"ip protocol";"0";NULL
"ICMP Test";"RealServiceCOS_icmp";"Class of Service";"0";NULL
"ICMP Test";"EnableJitter";"Jitter Calculation";"0";NULL
"IGMP Test";"Duration";"duration (sec)";"0";NULL
"IGMP Test";"igmp_interface";"probe interface";"0";NULL
"IGMP Test";"multicast_address";"multicast address";"0";NULL

"IGMP Test";"source_address";"source address";"0";NULL
"IGMP Test";"packets";"stream analytics";"0";NULL
"TCP ping";"DestinationServer";"Destination Servers";"0";NULL
"TCP ping";"PingInterval";"Interval";"0";NULL
"TCP ping";"PingCount";"Count";"0";NULL
"TCP ping";"PingPacketSize";"Packet Size";"0";NULL
"TCP ping";"TCPport";"Remote port";"0";NULL
"TCP ping";"RealServiceCOS";"Class of Service";"0";NULL
"Traceroute";"DestinationServer";"Destination Server";"0";NULL
"Traceroute";"Timeout";"Timeout (sec)";"0";NULL
"Traceroute";"QOS";"DSCP Setting";"0";NULL
"Traceroute";"TraceRouteProtocol";"Protocol";"0";NULL
"Traceroute";"ip_version";"ip protocol";"0";NULL
"UDP ping";"DestinationServer";"Destination Servers";"0";NULL
"UDP ping";"PingInterval";"Interval";"0";NULL
"UDP ping";"PingCount";"Count";"0";NULL
"UDP ping";"PingPacketSize";"Packet Size";"0";NULL
"UDP ping";"TCPport";"Remote port";"0";NULL
"UDP ping";"RealServiceCOS";"Class of Service";"0";NULL
"Wifi Connect";"AuthenticationMethod";"Authentication Method";"0";NULL
"Wifi Connect";"SSID";"SSID";"0";NULL
"Wifi Connect";"BSSID";"BSSID";"0";NULL
"Wifi Connect";"Passphrase";"Passphrase (WPA-PSK)";"0";NULL
"Wifi Connect";"UserName";"User name";"0";NULL
"Wifi Connect";"Password";"Password";"0";NULL

"Wifi Connect";"ResetInterface";"Reset interface after test";"0";NULL
"Wifi Connect";"specialWIFIscript";"Captive Portal script (optional)";"0";NULL
"Wifi Connect";"ConnectivityURL";"Ping Address";"0";NULL
"Wifi Connect";"CustomWPA";"Custom wpa content";"0";NULL
"Wifi Inspect";"DestinationServer";"SSID";"0";NULL
"Youtube Test";"DestinationServer";"Video code or url";"0";NULL
"Youtube Test";"Timeout";"Timeout (sec)";"0";NULL
"Youtube Test";"NameForVideo";"Video Name (optional)";"0";NULL
"Youtube Test";"VideoFormat";"Video Format";"0";NULL
thresholdArrayString sets specific threshold parameters - leave empty to use default

threashold settings
AlarmType:0 -no alarm
1-email
2-snmp
3- email And snmp
FailedAlarm-
0 - do not raise alarm on fail
1 - do raise alarm on fail

ErrorAlarm-
0 - do not raise alarm on error
1 - do raise alarm on error
StatusChangeAlarm-
0 - do not raise alarm on statuschange
1 - do raise alarm on statuschange
EmailAddress - string - email address so to send email alarm to
TESTEXEC_STRING: string - used for marking the test, and filtering
mytestduration: test duration for the execution
<x:Header/>
<x:Body>
<urn:configureTestExecution>
<urn:Type>?</urn:Type>
<urn:TestType>?</urn:TestType>
<urn:isMesh>?</urn:isMesh>
<urn:myMesh>?</urn:myMesh>
<urn:NodeFrom>?</urn:NodeFrom>
<urn:NodeTo>?</urn:NodeTo>
<urn:Frequency>?</urn:Frequency>
<urn:EnforceSchedule>?</urn:EnforceSchedule>
<urn:mystartdate>?</urn:mystartdate>
<urn:myenddate>?</urn:myenddate>
<urn:arrayOptionsNameString>?</urn:arrayOptionsNameString>
<urn:arrayOptionsValueString>?</urn:arrayOptionsValueString>
<urn:thresholdArrayString>?</urn:thresholdArrayString>
<urn:AlarmType>?</urn:AlarmType>

<urn:FailedAlarm>?</urn:FailedAlarm>
<urn:ErrorAlarm>?</urn:ErrorAlarm>
<urn:StatusChangeAlarm>?</urn:StatusChangeAlarm>
<urn:EmailAddress>?</urn:EmailAddress>
<urn:TESTEXEC_STRING>?</urn:TESTEXEC_STRING>
<urn:mytestduration>?</urn:mytestduration>
</urn:configureTestExecution>
</x:Body>
</x:Envelope>
output:
response with 0 in case no test was able to be configured
response with testExec ID if the test could be added in queue.

<SOAP-ENV:Body>
<ns1:configureTestExecutionResponse>
</ns1:configureTestExecutionResponse>
</SOAP-ENV:Body>
findProbeIDfromName
Find probe ID from inputting name
Input: ProbeName as string with name of the probe to look at
<x:Header/>

<x:Body>
<urn:findProbeIDfromName>
<urn:ProbeName>?</urn:ProbeName>
</urn:findProbeIDfromName>
</x:Body>
</x:Envelope>
output
API will return 0 if probe is not found, integer with ID if the probe is found.

<SOAP-ENV:Body>
<ns1:findProbeIDfromNameResponse>
</ns1:findProbeIDfromNameResponse>
</SOAP-ENV:Body>
findProbeIDfromSerialRequest
Find probe ID from input serial number
Input:
Serial as string with serial number of the probe to look at

<x:Header/>
<x:Body>
<urn:findProbeIDfromSerial>
<urn:Serial>?</urn:Serial>
</urn:findProbeIDfromSerial>
</x:Body>
</x:Envelope>

findProbeIDfromSerialResponse
Output:
API will return 0 if probe is not found, integer with ID if the probe is found.
<SOAP-ENV:Body>
<ns1:findProbeIDfromSerialResponse>
</ns1:findProbeIDfromSerialResponse>
</SOAP-ENV:Body>
listProbesNamesRequest
List all probes matching specified filters
Input:
ProbeName: probe name filter
Status: probe status filter
available values
0 - all probes
1 - all up probes
2 - all down probes

<x:Header/>
<x:Body>
<urn:listProbesNames>
<urn:ProbeName>?</urn:ProbeName>
<urn:Status>?</urn:Status>
</urn:listProbesNames>

</x:Body>
</x:Envelope>
listProbesNamesResponse
Output:
API will return 0 if no matching probe is found, a comma-separated string with all
matching probe names.

<SOAP-ENV:Body>
<ns1:listProbesNamesResponse>
<return xsi:type="xsd:string">Probe1,Probe2</return>
</ns1:listProbesNamesResponse>
</SOAP-ENV:Body>
testWebService
This is a test method to validate connectivity to Hawkeye SOAP server.
Input:
Param1: string
Param2: string
<x:Header/>
<x:Body>
<urn:testWebService>
<urn:Param1>p1</urn:Param1>
<urn:Param2>p2</urn:Param2>
</urn:testWebService>
</x:Body>

testWebServiceResponse
Output:
string - "Test IXIA HawkeyeWebServices <Param1> <Param2>"

<SOAP-ENV:Body>
<ns1:testWebServiceResponse>
<return xsi:type="xsd:string">Test IXIA HawkeyeWebServices p1 p2</re-
turn>
</ns1:testWebServiceResponse>
</SOAP-ENV:Body>

C
contacting Ixia iii
I
INDEX
Ixia, contacting iii
management 113
Services, Apache web server ser-

vice, mysql service 75
XR2000 overview, con-

figuration 22
XRPi content, XRPi system

information 2
XRPi setup, configure XRPi 6
Hawkeye User Guide i

Hawkeye User Guide

Uploaded by

Copyright:

Available Formats

Hawkeye User Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Hawkeye User Guide

Uploaded by

Copyright:

Available Formats

Hawkeye

ii Hawkeye User Guide

EMEA Ixia Europe Limited Support: support-emea@ixi-

Asia Pacific Ixia Pte Ltd Support: support-asiapac@ixi-

Japan Ixia KK Support: support-japan@ixi-

India Ixia Technologies Pvt Ltd Support: support-indi-

China Ixia Technologies (Shanghai) Company Ltd Support: support-chin-

Hawkeye User Guide iii

Contacting Ixia iii

Configure Hawkeye Endpoints 2

Routing and Ports management 57

Hawkeye ports for automatic endpoints 57

Hawkeye ports for manual endpoints 60

Managing Probes Behind NAT 62

Hawkeye scenarios for endpoints 65

Debugging routing issues 72

Hawkeye User Guide v

Manage MySQL Database 76

Parameters effecting Performance 80

Secure access to Hawkeye server 84

Hawkeye User Authentication 87

Users and Groups Management 89

Captive Portal Support for WiFi 98

Security audit logging of users 105

Configure Hawkeye 106

Interface Presentation 106

Probes Management 106

Test Execution 115

Threshold management 122

Alarms management 125

Mesh Management 127

MAP configuration and probe location configuration 131

Floorplan Management 136

Hawkeye preferences 140

Explore results 163

vi Hawkeye User Guide

Going through dashboard test results 164

WiFi Dashboard 173

Metric Status 177

Metric Graph 178

Path Discovery 181

Test Results screens 187

Map Status 194

Hawkeye Reports 196

Hawkeye Test types 204

Test type general description 204

Node to Node test types 219

Real Services 326

Real Service endpoint support matrix 357

Replicating tests across multiple endpoints 359

Test types reporting WiFi statistics 360

Supported Protocols and standards 367

Advanced administrator Guide Introduction 372

OSS (Operations Support System) Integration 372

MySQL database Management 374

Hawkeye folder structure 390

SNMP configuration and verification 390

Speed Test using Global Servers 402

Set long TDRID 403

Hawkeye User Guide vii