Backgroound Image

Month: August 2022

ThousandEyes Walkthrough 4.3.1 Scenario 1 – Enterprise agent to agent test configuration

Posted on by Dan Kelcher

This post will go over the first scenario for the ThousandEyes lab. To see past posts in this series expand the box below.

ThousandEyes Walkthrough Table of Contents

There are some behind-the-scenes posts that go into more detail on how and why I took the approach that I did. Those can be found here:

 

Scenario 1

The objective is to monitor the connection between all agents and the two client sites.  Both client sites have agents installed, which means an agent-to-agent test would be the best fit.  An agent to server test could be used, but that is dependent on a specific service running, or an ICMP response.  Additionally, the agent-to-server test can only initiate from the agent side, while an agent-to-agent test can perform bidirectional monitoring.

Create an Enterprise agent-to-agent test

  1. Log in to ThousandEyes (I presume this skill has been mastered by now)
  2. On the left side, expand the menu, then click on Cloud and Enterprise Agents to expand that list, and then click Test Settings
  3. Click Add New Test.
  4. This will be an agent-to-agent test.  For the layer select Network, and then under Test Type select Agent to Agent.
    2. Add a name for the test
  5. Under Basic Configuration there are a few things to set here.
    1. Click in the Target Agent field
    2. On the right side, click Enterprise to filter the list down to only our Enterprise agents
      1. NOTE: the agents listed here are Cloud agents, and those can be used to test public services from locations all over the world
    3.  Select the CS1-2 agent
    4. The interval is how often these tests are performed.  Since this is a lab we’ll back this off to a 30-minute interval to reduce the number of tests being run.
    5. In the Agents field, we’ll select the source agents.  Again, filter based on Enterprise agents, and then select all agents except CS1-2
      1. NOTE: Selecting the North America group (or your local region) will include the CS1-2 agent, and that won’t allow the test to be created because a source and target are the same.
    6. Under Direction, select Both Directions
    7. Leave the Protocol option set to TCP
    8. Check the box to Enable Throughput monitoring, then leave the duration with the default 10s time.
    9. Leave Path Trace Mode unchecked
    10. Uncheck the Enabled box next to Alerts.  We’ll cover alerts later on in this series
    11. When everything is completed it should look like this:
  6. Click Create New Test
That will get the first test created.  Now we’ll want to create the same test, but use CS2-2 as the target.  You could manually create the new test, or duplicate the existing test and make a few changes.
  1. Click the ellipsis (…) to the right of the test, and then in the menu click Duplicate
  2. Correct the test name
  3. Change the Target Agent to CS2-2
  4. In the Agents field uncheck CS2-2 and check CS1-2
    1. NOTE: If you can’t uncheck CS2-2 then click the box next to the region, and that should unselect all agents.  Then reselect all agents except CS2-2
  5. When complete it should look like this:
  6. Click Create New Test again
That gets the two tests required for Scenario 1.  It should automatically start running the tests.  While the tests are running they will consume test units.  If you want to conserve test units you can disable the tests from the Test Settings screen.  Simply uncheck the Enabled boxes to disable them, and when you want to enable the tests again just check the boxes.

The test results will be reviewed in a later post in this series.

ThousandEyes Walkthrough 4.2 Scenarios and Test Types

Posted on by Dan Kelcher

This post will go over the scenarios that will be used for the ThousandEyes lab, as well as the different test types available in ThousandEyes. To see past posts in this series expand the box below.

ThousandEyes Walkthrough Table of Contents

 Scenarios

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.

Business Use Cases

  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.