Advanced

Start Downloading a torrent from torrent client-

THIS TEST IS ONLY SUPPORTED ON XR2000, NOT ON XRPi

Measures Throughput at which a file can be downloaded from a peer-to-peer network.

• Torrent name (simply for display reasons, not used in test)
• magnet link: is the torrent file url that the probe needs to download to get access to torrent

Test duration: torrent download duration - after this duration torrent download will stop and result printed out even if torrent is not fully downloaded.

• 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 download

This test aims at proving capability to do peer to peer traffic from the probe and identify the relevant max throughput.

It is recommended to use popular torrent files so that the results are significannot.

See advanced information.

See Common Errors - Real Services.htm.

This test verifies key metrics to access AWS (Amazon Web Services) cloud.

AWS has different regions that can host servers and services. Having good network connectivity from the edge to these data centers is often paramount to the service experience delivered for internal application that is self hosted on Amazon, or for external applications (SaaS) hosted on the cloud. Through this test, you can have monitoring capabilities with network performance characterization from the endpoint to the Cloud. This capability is independent of any potential application responsiveness problems; because the measured performance is purely network related from the endpoint (typically deployed at the edge or at the service delivery location, remote site, home environment, and so on) and the Amazon data center edge.

Key metrics that affect the performance of any application hosted by Amazon:

• Response time: The response time is expected to be as fast as possible. Delay to cloud services adds in responsiveness of the application and typically results in application slow response. The long delays can also impact critically on the time taken to download the content.

• Packet loss: As much as possible, the packet loss must be close to none. Dropping packets affect the real time applications (like voice, video), resulting in bad user experience. Packet loss also affects the transactional applications (like web based app); because it creates retransmissions, thus affecting the responsiveness.

The test also includes some path discovery. Path discovery identifies the path and service providers involved in the transport of packets from an endpoint to the AWS edge.

The protocol used is TCP (on port 443).

Generate TCP ping requests to known AWS servers.

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Validate availability and response time to selected AWS servers.

• Destination: known AWS server

• Interval: interval between sending packets

• Count: number of TCP SYN packets to send and SYNACK packets to receive

• Packet Size: length of TCP content

• Class Of Service: quality of service

• Remote Port:

• Collect Path Discovery: Yes or No

• Availability

• Packet Loss

• Round Trip Time Avg (ms)

• Round Trip Time Max (ms)

• Round Trip Time Min (ms)

For information on Collect Path Discovery, refer to the Path Discovery Real Service test.

See advanced information.

See Common Errors - Real Services.htm.

• url to resolve
• DNS server (default or empty: will use default DNS server as provisioned on probe)

• IPv4 or IPv6

• 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)

This test will verify availability and response time of DNS service from probe or specific DNS server response time.

A long response time from DNS by default can result into bad user experience and therefore should be monitored closely.

See Common Errors - Real Services in Error Description Guide.

Measures user experience sharing files on dropbox service.

• File (file size)
• Timeout

• Download or upload rate
• Download time
• File size

The files are provided by default. The dropbox account is a dedicated test account provided by Ixia.

See advanced information.

Check whether the date on endpoint is valid, that is, the end point is not out of date. This is because, dropbox security policy will reject dropbox use from devices with an old date.

See Common Errors - Real Services in Error Description Guide.

Measures The time taken to relay an email via the configured SMTP servers and reaching a target mail server .

Account information for sending and receiving email.

Delay (ms) for receiving the email.

The test works by creating a mail client on the endpoint that sends an email to another address. The endpoint then connects to the inbox of the sent email to verify reception of the sent email.

Details: You send email from your mail client (now running on Hawkeye Server) using the configured email address to the outgoing SMTP server using the configured port. The SMTP server first validates security and authentication i.e. connection security (SSL/TLS/25), port, username, password. The SMTP server works like the post office and performs a DNS lookup to find where to send the email (destination domain). The SMTP server may store the actual email on a local server (owned by domain sender) close to the Hawkeye server instead of the main SMTP server (that is Gmail). The SMTP server then sends the email to the destination domain Message Transfer Agent (MTA) server for long term storage. If the email destination domain is the same as the source, (that is both gmail) the SMTP server will act as the MTA server. If different sender/destination email domain and no issues, it can be routed/forwarded. The email is sent by SMTP protocol to the (destination domain) MTA server. The received email is stored on the destination domain MTA (POP3/IMAP) server. The MTA (POP3/IMAP) server uses POP3 or IMAP protocol to transfer email to recipient’s inbox (email client on the laptop) when requested.

In summary the User is required to enter credentials (username/password/SMTP server IP/server port/type encryption) for the senders and the receivers credentials (username/password/IMAP IP/IMAP server port/protocol) so the endpoint can verify receipt of the test email. The Real Service Email test times different stages, but most important is when the destination POP3/IMAP server receives the sent email. Endpoint will poll every second to check received email.

See advanced information.

See Common Errors - Real Services in Error Description Guide.

FTP server test with login, password and download file.

Test user experience downloading files from FTP server. The file downloaded needs to be on the FTP server.

• test Timeout (sec)
• FTP Server address or url
• File to download
• Authentication mode
• FTP mode (active/passive)
• Username
• Password

• Download File size
• Download Time
• Download bitrate

This test will download the FTP file as fast as possible from the server to the probe.

This is user experience from probe to download file from specified FTP server

If ftp not downloaded before end of timeout defined then the test will error out.

See Common Errors - Real Services in Error Description Guide.

FTP server test with login, password and download file - adding a parameter to enable multiple concurrent streams download.

THIS TEST IS ONLY SUPPORTED ON XR2000, NOT ON XRPi

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 supposedly filling up the transport pipe.

• test Timeout (sec)
• 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

• Download File size
• Download Time
• Download bitrate

See Common Errors - Real Services in Error Description Guide.

Generate TCP ping requests to known Fortnite servers.

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Validate availability and response time to selected Fortnite servers.

• Destination: Known Fortnite Server

• Interval: interval between sending packets

• Count: number of TCP SYN packets to send and SYNACK packets to receive

• Packet Size: length of TCP content

• Class Of Service: quality of service

• Remote Port:

• Collect Path Discovery: Yes or No

• Availability

• Packet Loss

• Round Trip Time Avg (ms)

• Round Trip Time Max (ms)

For information on Collect Path Discovery, refer to the Path Discovery Real Service test.

See advanced information.

See Common Errors - Real Services.htm.

Generate TCP ping requests to known League of Legends servers.

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Validate availability and response time to selected League of Legends servers.

• Destination: Known League of Legends Server

• Interval: interval between sending packets

• Count: number of TCP SYN packets to send and SYNACK packets to receive

• Packet Size: length of TCP content

• Class Of Service: quality of service

• Remote Port:

• Collect Path Discovery: Yes or No

• Availability

• Packet Loss

• Round Trip Time Avg (ms)

• Round Trip Time Max (ms)

• Round Trip Time Min (ms)

For information on Collect Path Discovery, refer to the Path Discovery Real Service test.

See advanced information.

See Common Errors - Real Services.htm.

Generate TCP ping requests to known World of Warcraft servers.

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Validate availability and response time to selected World of Warcraft servers.

• Destination: Known World of Warcraft Server

• Interval: interval between sending packets

• Count: number of TCP SYN packets to send and SYNACK packets to receive

• Packet Size: length of TCP content

• Class Of Service: quality of service

• Remote Port:

• Collect Path Discovery: Yes or No

• Availability

• Packet Loss

• Round Trip Time Avg (ms)

• Round Trip Time Max (ms)

• Round Trip Time Min (ms)

For information on Collect Path Discovery, refer to the Path Discovery Real Service test.

See advanced information.

See Common Errors - Real Services.htm.

Test to verify the validity of a HTTP Client Certificate, a digital signature.

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Check the validity of HTTP Client Certificates.

• Destination Server: URL of the Client Server

• Certificate File URL: URL of the Client Certificate file

• Certificate Password: Password associated with the Client Certificate

• Availability

• DNS Resolution Time (ms)

• Network TCP Connection Time (ms)

• SSL Connection Time (ms)

• Time to First Byte (ms)

• Total Download Time (ms)

Client certificates are used to validate the identity of a client (user). Simply put, it works as a password, but without any intervention/input from the user. This way, the server makes sure that it is connecting to the permitted user and that party is safe to communicate with.

See advanced information.

See Common Errors - Real Services.htm.

Download HTML content from the input url.

Check availability of a webpage, check time to download content, compare TCP response time with application level content download time.

• Servers address or url - the list can contain up to 10 different servers
• IPV4 or IPV6
• Protocol http (0) or https (1)
• Number of tests to execute in same batch
• DSCP setting

Per Web server:

Application latency (ms) – calculated as the time between endpoint 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 endpoint issues [SYN] and the time endpoint receives the last datagram [FIN.ACK] from server
Resolved IP address for server

This test will try to download http content on a url. It will simply analyze 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.

The test is useful to understand TCP response time (network) to full html download (server response time).

See Common Errors - Real Services in Error Description Guide.

Download http pages full content from one or several servers and provide statistics about content and response time.

Get user experience information downloading the web page content. 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.

• Servers address or url
• Download all page or only html content
• IPV4 or IPV6

• Proxy Server

• Proxy Username

• Proxy Password

• CA Certificate

• Client Certificate

• Client Key

• Client Password

• User Agent

• 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 (average for all elements in page)
• Number of files in page
• Resolved DNS address for http server

This test will download elements in a web page providing user experience getting information from the associated url. This test will download all elements in page (unless setting prevents it).

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. Download 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 Download time.

Download time = (Download Size * 8 / KB Rate per sec)

• CA Certificate is used to verify the peer. If no certificate is entered in the CA Certificate, Peer Certificate Authentication is not performed.

• Client Certificate is used to validate the identity of a client (user). It works as a password without any intervention or input from the user. In this way, the server makes sure that it is connecting to the permitted user and the connection is safe to communicate with.

• Client Key is the Private Key associated with the Client Certificate.

• Client Password is the password for the Client Key.

The Client Certificate and the Client Key can be concatenated into one file and entered into the Client Certificate.

To move certificates into the Hawkeye system, use the Upload Files button located under the Advanced tab. This will allow the user to upload file types: pem, key, and crt. Certificates can also be removed from the Hawkeye system from the Upload Files window.

After certificates have been moved to the Hawkeye system, they will appear in the certificate Select file pulldown selection menus.

The result should be reflective as the user experience getting from a browser to the web page.

See Common Errors - Real Services in Error Description Guide.

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.

Get user experience information downloading the web page content. 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.

• Servers address or url
• Download all page or only html content
• IPV4 or IPV6

• Proxy Server

• Proxy Username

• Proxy Password

• CA Certificate

• Client Certificate

• Client Key

• Client Password

• User Agent

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 (average 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

This test will download elements in a web page providing user experience getting information from the associated url. This test will download all elements in page (unless setting prevents it).

The result should be reflective as the user experience getting from a browser to the web page.

See Common Errors - Real Services in Error Description Guide.

• Destination servers (IP or url addresses)
• Generated throughput (ICMP content)
• packet sizes(ICMP content)
• Class of Service
• test duration

• ICMP Packet loss (%)
• ICMP throughput (layer 4)

This test sends ICMP packets at defined bit rate and listens for the received packets throughput.

Number of packets per second is calculated based on send throughput 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.

A loss rate is likely to impact the total received throughput quite dramatically. Results will also get more precision if traffic generation length is longer.

See Common Errors - Real Services in Error Description Guide.

• List of destination servers (IP or url addresses)
• interval for icmp packets
• number of packets to send
• packet sizes
• IPV4 or IPV6
• Enable Jitter calculation (default yes)
• Class of Service

• Packet loss (%)
• Round trip average (ms)
• Round trip max (ms)
• Round trip min (ms)
• Standard Deviation (ms)
• Jitter (ms)
• Jitter max (ms)

This test sends ICMP packets and listen for responses. The jitter, round trip, and standard deviation cannot be calculated for packet sizes less than 16 bytes and will return a result of 0.

The ICMP packets will detect any obvious issues on the network (congestions, drops, long response time, instable response time). It is an interesting data point as a change in the average of an ICMP test would likely reflect some modification of the network average. 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.

See Common Errors - Real Services in Error Description Guide.

Join a multicast channel and analyze received RTP stream- igmp v2 or v3 will be used depending on the available network.

THIS TEST IS ONLY SUPPORTED ON XR2000, NOT ON XRPi

Will join a channel (if available) and collect broadcasted stream if available.

• watch duration: time before joining and leaving the stream
• 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.

• 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 (Mbps)
• Total kBytes Received
• Total Packets lost
• Total Packets Received
• Total stream duration (sec)
• Loss rate
• IGMP protocol version

The RTP stream received is parsed and analyzed. Video is not stored on the probe.

Probe will autodetect igmp version (v2 or v3).

Leave Source Multicast address empty for v2 or All sources.

See advanced information.

See Common Errors - Real Services in Error Description Guide.

Validate network connectivity performance for Office 365 server suites.

• Office365 Server lists to choose from
  • login.microsoftonline.com
  • office.live.com
  • outlook.office365.com
  • teams.microsoft.com
  • broadcast.skype.com
  • www.onenote.com
• Option to collect Path Discovery to trace the path taken
• SharePoint Tenant
• Test Frequency in Minutes

• Packet loss (%)
• Application latency (ms)
• Round trip max (ms)
• Round trip Min (ms)
• Round trip Avg (ms)

The ICMP packets will detect any obvious issues on the network (congestions, drops, long response time, instable response time). It is an interesting data point as a change in the average of an ICMP test would likely reflect some modification of the network average. 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.

See Common Errors - Real Services in Error Description Guide.

Validate network connectivity performance for Office 365 server suites through a proxy.

• Office365 Server lists to choose from

  • login.microsoftonline.com

  • office.live.com

  • outlook.office365.com

  • teams.microsoft.com

  • broadcast.skype.com

  • www.onenote.com

• SharePoint Tenant

• Test Frequency in Minutes

• IP Protocol (IPv4 or IPv6)

• Class of Service

• Protocol (https or http)

• Proxy Host:Port

• Proxy User

• Proxy Passwd

• Packet loss (%)

• Resolve Hostname Avg, Max, and Min (ms)

• Connect Avg, Max, and Min (ms)

• Round trip Avg, Max and Min (ms)

• (HTTP Server) Process and Respond Avg, Max and Min (ms)

• Teardown Avg, Max and Min (ms)

• Download Rate Avg, Max and Min (KB/Sec)

The HTTP packets detect any obvious issue on the network (congestions, drops, long response time, unstable response time). It is an interesting data point, because a change in the average of an HTTP test may reflect some modification of the network average. You must interpret the results carefully, because the HTTP packets are usually treated with lower priority than data packets by the network elements. Therefore the result displayed may be of poorest quality than the actual user traffic (prioritized) experienced in some cases.

See Common Errors - Real Services in Error Description Guide.

Uses a combination of traceroute and ping requests to discover paths from the original probe to the destination server.

• destination (IP or url addresses)
• timeout for request (sec)
• traceroutes count
• traceroute max hops
• traceroute protocol (ICMP, TCP or UDP)
• destination port
• Quality of service (or DSCP setting)

• IPv4 or IPv6

Although Path Discovery has no configurable metrics there are criteria 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). Path Discovery sends 100 ICMP packets to each node in the path.

If a test is configured and not enough hops are configured to reach the destination, the test will pass without reaching destination assuming all hops were successful.

In Path Discovery the traceroute component uses the ping command. The URL used for test is expected to be a value that will find a match in the DNS lookup tables. The URL used for the test cannot have sub-directories as part of the URL if they will not match entries in the DNS lookup tables. Path Discovery test does not massage the URL’s entered by the User.”

There are various options in ‘Test Results’ that can help user to analyze path discovery results:

• Traceroute – displays the traceroute style output
• Show navigation – (uncheck) enables free zoom/ pan mode
• Frequent path – highlights frequent path and line thickness will be proportional to frequency
• Loss – if selected, highlights nodes with loss equal or greater than specified value
• Avg RTT – if selected, highlights nodes with average round trip delay (RTT) equal or greater than specified value
• Cluster – gives user option to cluster Autonomous Systems or unknown nodes

• 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

• IP
• Reverse DNS
• Autonomous System
• ICMP extensions

• QoS Changes

When Hawkeye server is connected to internet, following hop info are also retrieved

• Network name
• Prefix
• Organization

Metrics

• Frequency
• Min/Avg./Max response time
• Packet loss

See Common Errors - Real Services in Error Description Guide.

Can be used to ensure services (for example HTTPS, FTP, etc.) are accessible or blocked by firewalls.

• destination (IP or url addresses)
• protocol: TCP or UDP
• start port
• port count
• expected port state

• IPv4 or IPv6

• 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.

The Port Scan results will reflect an overall test status and the 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:

• OPEN: The port (TCP or UDP) on the destination is reachable and we receive reply to our sent packets.
• OPEN/FILTERED: Only applies to UDP ports. If no reply is received either because the application listening is not replying or we cannot reach the destination (e.g. due to firewalls blocking the packets).
• FILTERED: Only applies to TCP ports. If no reply is received back (e.g. due to firewalls blocking the packets).
• 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 processed by intended application). Specifically endpoint received back ICMP Destination Unreachable message.

See Common Errors - Real Services in Error Description Guide.

Validate RESTful Web Services of a server and the response time supported ICMP protocol.

• URL:
• Key-Value Pairs: Data parameters
• Method: GET, POST, PUT, PATCH, DELETE
• Response Code: The Response Code is compared to the HTTP Status Code of the response to the query sent
• Authentication: None, Cookie based
• Session ID: Alpha-numeric identifier to allow multiple cookies

• Availability (1 for available, 0 for not available)
• Response Code (Compare configured Response Code of test with returned HTTP Status Code)
• Response time (ms)

• The Response Code has wildcards like 2XX which will match any 200 series HTTP Status Code response.
• Can be used to perform both positive and negative testing.

• The availability of the URL being tested.
• The round trip time of the request and response.
• If the HTTP Status Code of the response matches the desired Response Code

• Missing URL
• Unknown Session
• Response time threshold failed
• Response Code failure

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.

• Class of service

• Jitter (ms)
• packet loss
• round trip time avg (ms)

The result includes also the path view to get a more clear understanding 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.

The test sends 150 ping TCP packets 10 milliseconds apart to World Wide Anycast IP of Skype for Business media relay and compare the measurements against Microsoft requirements. Skype network connectivity performance metrics report packet loss to the final IP.

See Media Quality and Network Connectivity Performance in Skype for Business Online for more information

See advanced information.

See Common Errors - Real Services in Error Description Guide.

SYN packets are sent to interface and port, and round trip delay is based on SYNACK received. This test is useful especially to measure TCP connection times to http server or when ICMP protocol is blocked to check availability and network response time to server.

• List of destination servers (IP or url addresses)
• interval for TCP SYN packets
• number of packets to send
• packet sizes(TCP content)
• TCP port
• DSCP setting

• IPv4 or IPv6

• TCP Packet loss (%)
• Round trip average (ms)
• Round trip max (ms)
• Round trip min (ms)

This test sends TCP SYN packets and listen for SYNACK responses.

Some TCP ports (HTTP for example on some servers) would only allow packet size of 0 (no content) for TCP syn.

The TCP response round trip and packet loss provides good information about the network transport to TCP remote ends.

See Common Errors - Real Services in Error Description Guide.

This test verifies key metrics to access Teams services (gateways in Microsoft cloud).

The services of Teams are hosted into different regions. A server is automatically affected to the user for connectivity and voice/video traffic on its infrastructure. The server is typically optimized to be the closest geographic gateway of the first to join a call or a meeting. Having good network connectivity from the edge to the Teams serving gateways are paramount to the service experience.

This test possesses monitoring capabilities with network performance characterization from the endpoint to the different points of services of Teams. Predicting Teams serving region(s) for a user is not always possible, because these can change over time. But as a good approximation, it is recommended to verify the performance against two or three closest regions and also against the regions of other team members frequently setting up meetings.

Key metrics that affect the performance and Teams user experience:

• Response time: The response time is expected to be as fast as possible. Delay to cloud services impacts the conversation lags, but is also likely to create delay variations. Therefore it affects the overall performance with some buffering dropping packets.

• Packet loss: Packet loss results into real time packets being lost, resulting in breaking of part of conversations or freezing of videos.

The test also includes some path discovery. Path discovery identifies the path and service providers involved in the transport of packets from an endpoint to the Teams service locations.

The protocol used is TCP (on port 443).

Generate TCP ping requests to known Teams servers.

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Validate availability and response time to selected Teams servers.

• Destination: known Teams server

• Class Of Service: quality of service

• IP Protocol: IPv4 or IPv6

• Collect Path Discovery: Yes or No

• Availability

• Packet Loss

• Round Trip Time Avg (ms)

• Round Trip Time Max (ms)

• Round Trip Time Min (ms)

For information on Collect Path Discovery, refer to the Path Discovery Real Service test.

See advanced information.

See Common Errors - Real Services.htm.

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).

• Destination Server (IP or url addresses)
• Timeout for request (sec)
• DSCP setting
• IP protocol (ipv4 or ipv6)
• traceroute protocol (ICMP or UDP)

Per step:

• server ip and name
• response time

Traceroute is informative for now: there is no check on thresholds 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.

See advanced information.

See Common Errors - Real Services in Error Description Guide.

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.

• List of destination servers (IP or url addresses)
• interval for UDP packets
• number of packets to send
• packet sizes(TCP content)
• Remote UDP port
• DSCP setting

• IPv4 or IPv6

• UDP Packet loss (%)
• Round trip average (ms)
• Round trip max (ms)
• Round trip min (ms)

This test sends UDP packets and listen for UDP packet responses.

The UDP response round trip and packet loss provides good information 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.

See Common Errors - Real Services in Error Description Guide.

Generate TCP ping requests to known Webex servers. Optionally Download HTML content from the tenant.

This test is supported on XR2000, XR2000VM, XR3000, XRPi, XR-VM, XRE1S, and VisionE1S.

Validate availability and response time to selected Webex servers.

Check availability of a tenant, check time to download content, compare TCP response time with application level content download time.

• MediaGW Destination: known Webex server

• Tenant: a company's common access to Webex, that is mycompany.webex.com

• IP Protocol: IPv4

• Class Of Service: quality of service

• Collect Path Discovery: Yes or No

• MediaGW Destination Availability

• MediaGW Destination Packet Loss

• MediaGW Destination Round Trip Time Avg (ms)

• MediaGW Destination Round Trip Time Max (ms)

• MediaGW Destination Round Trip Time Max (ms)

• Tenant Application Latency (ms)

• Tenant Bytes from server

• Tenant TCP Latency (ms)

• Tenant Total http download time (ms)

• Resolved IP address

For information on Collect Path Discovery, refer to the Path Discovery Real Service test.

See advanced information.

See Common Errors - Real Services in Error Description Guide.

Wi-Fi connect measures the time taken by the Wi-Fi device to connect 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 available 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. This test is also supported on XR3000 with Wi-Fi interface enabled. Note that a valid wired ethernet connection is necessary to run this test.

• 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)

This test supports Authentication schemes, None, WPA-PSK, EAP-TTLS/MSCHAPv2 and custom. You can also select a particular BSSID to connect to.

The default average is to reset the wlan0 interface after each execution of the Wi-Fi Connect test.

The error messages that can be displayed are:

• If Wrong SSID is used – “No Wi-Fi interface detected”
• If no Wlan0 interface - “No response from file”
• If Probe is not registered – “Probe not registered or active for real service”

Measures key metrics of all available Wi-Fi AP that can be detected by probe.

• SSID

• Channel
• Advertised by AP Max bitrate (Mbps)
• Wi-Fi Signal Level (DBm)

Charting Wi-Fi AP over time may show gaps in statistics. This can be caused by several factors such as, Wi-Fi AP is busy and is not sending out the beacon signal used to calculate measurements. Wi-Fi 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”.

If Probe is not registered – “Probe not registered or active for real service”.

This test verifies key metrics to access Zoom services (gateways).

Zoom is hosted into different regions. A server is automatically affected to the user for connectivity and voice/video traffic on its infrastructure. The server is typically optimized to be the closest geographic gateway. Having good network connectivity from the edge to the Zoom serving gateways are paramount to the service experience.

This test possesses monitoring capabilities with network performance characterization from the endpoint to the different points of services of Zoom. Predicting Zoom serving region(s) for a user is not always possible, because these can change over time. But as a good approximation, it is recommended to verify the performance against two or three closest regions.

Key metrics that affect performance and Zoom user experience:

• Response time: The response time is expected to be as fast as possible. Delay to cloud services impacts the conversation lags, but is also likely to create delay variations. Therefore it affects the overall performance with some buffering dropping packets.

• Packet loss: Packet loss results into real time packets being lost, resulting in breaking of part of conversations or freezing of videos.

The test also includes some path discovery. Path discovery identifies the path and service providers involved in the transport of packets from an endpoint to the Zoom service locations.

The protocol used is TCP (on port 443).

Generate TCP ping requests to known Zoom servers.

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Validate availability and response time to selected Zoom servers.

• Destination: known Zoom server

• Interval: interval between sending packets

• Count: number of TCP SYN packets to send and SYNACK packets to receive

• Packet Size: length of TCP content

• Class Of Service: quality of service

• Remote Port:

• Collect Path Discovery: Yes or No

• Availability

• Packet Loss

• Round Trip Time Avg (ms)

• Round Trip Time Max (ms)

• Round Trip Time Min (ms)

For information on Collect Path Discovery, refer to the Path Discovery Real Service test.

See advanced information.

See Common Errors - Real Services.htm.

Zoom service status of various Zoom systems

THIS TEST IS SUPPORTED ON XR2000, XR2000VM, XRPi, XR-VM, and VisionE1S.

Check if Zoom systems are operational.

None

• Zoom Meetings

• Zoom Video Webinars

• Zoom Phone

• Zoom Chat

• Zoom Website

• Zoom Dashboard & Reporting

• Download Center

• Web Portal

• Web Client

• Conference Room Connector

• Zoom Cloud Room Connector

• Zoom Connector for Cisco

• Zoom Connector for Polycom

• Cloud Recording

• Meeting Telephony Services

• Integrations

• Live Streaming

• Zoom Developer Platform

• Web SDK

• REST API

• Marketplace

• Webhooks

Each system will have a status. The metric passes if the system is Operational.

See advanced information.

See Common Errors - Real Services.htm.