ThousandEyes Walkthrough 4.2 Scenarios and Test Types

Here are business use case scenarios that will be the basis for the ThousandEyes lab testing.  The scenarios are intentionally vague, but should provide a relatable situation that any network team might encounter.  Then, these business cases will be translated into technical requirements that will be used to build out each solution.  Keep in mind, that this is to illustrate the business and technical use cases for ThousandEyes.  In a real-world situation, there would be multiple facets to these scenarios, but we’re focused on one piece of this solution.

1. Both of the corporate campuses (client site 1 and client site 2) house resources critical to business processes.  It is important that these resources are accessible and performance meets the business requirements.
2. It’s known that critical applications are dependent on other network services, but there is a concern that the underlying services aren’t able to support the applications.  
3. An externally managed web application is used frequently used by employees, and if it were unavailable or slow that would negatively impact the employees’ productivity.
4. Two internal web applications are used by customer-facing staff, and if these applications are unavailable or poorly performing for any location that would negatively impact the customer experience.
5. A critical business process relies on a third-party web service.  If there are delays in any stage of this process it can cause a significant impact.  

Translation into Technical Requirements

1. Network performance from all enterprise locations should be monitored.  
2. DNS has been identified as a critical service that other applications are dependent on.  The CML.LAB domain must be monitored for availability and performance.
3. Connection performance and availability to these HTTP servers must be monitored.  The application vendor should be monitoring the application performance
1. NOTE: There’s potential value in monitoring application performance both to keep track of SLA metrics, and also to speed the identification of an issue, but for this example, we’ll take the simplest approach.
4. In addition to monitoring the HTTP connections, the time required to access these applications should be monitored
5. Multiple web pages need to be monitored, and it needs to happen in a sequence similar to how a user would interact with the application.

Test Types

ThousandEyes has a total of 12 Enterprise test types split across 4 categories.

• Routing
• BGP
• This test looks at BGP peering (the lab environment isn’t peered out to the internet, and setting up private peering is going to be out of scope for the lab)
• Network
• Agent-to-Server
• This creates either a TCP or ICMP connection to the target address and monitors loss, latency, and jitter
• Agent-to-Agent
• Creates a connection between two ThousandEyes agents, and allows bidirectional TCP or UDP testing, monitoring loss, latency, jitter, and optionally throughput.
• DNS
• DNS Server
• This is pretty straightforward, a DNS record and DNS server are entered, and the test checks for resolution of that DNS record.
• DNS Trace
• A DNS trace queries top-level DNS servers and then works down through name servers to show the path used to resolve a DNS query the fastest.
• DNSSec
• With this test, the validity of a DNSSEC entry can be verified
• Web
• HTTP Server
• An HTTP(S) connection is made to a web server, effectively this is like using cURL to check if a connection can be established.
• Page Load
• Building on the HTTP test, the page load actually loads the HTML and related objects and tracks the time for each step in the process.
• Transaction
• Continuing to build on the Page Load test, a transaction test uses a Selenium browser and a script to simulate user interaction with a web application.
• FTP
• Establishes an FTP (or SFTP/FTPS)  connection, and attempts to download, upload, or list files.
• Voice
• SIP Server
• This test checks SIP access to a server (by default TCP 5060), and under the advanced options, it can be configured to attempt to register a device with the SIP server.
• RTP Stream
• This is similar to an agent-to-agent test, but since it tests specifically focuses on RTP it includes MOS and PDV metrics in addition to the loss, latency, and jitter provided by normal agent tests.

There’s a lot more detail around tests and some of the advanced options available for each.  More info can be found here: https://docs.thousandeyes.com/product-documentation/internet-and-wan-monitoring/tests

The Endpoint tests have two different methods to choose from.  The first is a scheduled test, which functions in a similar way to the Enterprise tests.  Endpoints can either do agent-to-server network tests or HTTP web tests.  The other option, which is unique to Endpoint agents, is the Browser Session test.  A Browser Session test uses a browser plugin (installed as part of the Endpoint agent installation) that collects data from the browser based on real-time interactions with web applications.

What’s next?

The next few posts will go over each scenario in detail. It will cover the creation of various tests to meet the requirements outlined in each scenario. After all the tests are created then we’ll look at the results and review how that information is useful.