LEARNING PATH

Visibility Into Internet Performance

Learn how Network Observability by Broadcom helps network operations teams evaluate Internet performance and resolve issues.

Network Observability by Broadcom is a solution composed of two products—AppNeta and DX NetOps—that together deliver comprehensive observability for private and public networks. This page describes how to use Network Observability for visibility into Internet performance.

Courses

5 chapters

to review

1 hour

estimated completion

Visibility Into Internet Performance

Course sections

Use Case Overview

Gartner analysts estimate that by 2025, 51% of IT and network operations team spending will have shifted to the public cloud. When it comes to application software, the number is even higher, with cloud resources expected to grow to make up 65.9% of IT and network operations spending.

This continued cloud adoption results in an increasing reliance on internet services, and on a complex mix of external service providers and technologies to deliver those services.

For network operations teams, the move to the cloud significantly reduces visibility into the performance of the underlying infrastructure that business services depend upon. At the same time, network operations teams remain responsible for network performance. Traditional monitoring methods gather passive device-level data, but that is not possible when teams do not own or manage the network.

To address the challenge, network operations teams need end-to-end Internet visibility, including:

Maps of user traffic routes. When there is an issue, NOC teams need to be able to identify who is responsible for solving it.
Continuous performance monitoring on the route. Non-stop monitoring allows teams to detect issues that could go unnoticed by passive device monitoring, such as protocol and router configuration problems
Understanding of the responsibility footprint of applications and networks. Teams need to monitor as much of the organization’s network footprint as possible, so they can determine who is actually affected when problems occur.

This article presents a learning path for network operations teams to learn how to implement—and then leverage the insights from—Network Observability by Broadcom to establish end-to-end visibility into Internet performance.

To learn more about how Network Observability helps with evaluating Internet performance, read the white paper Establishing End-to-End Visibility of Internet Performance.

The Network Observability by Broadcom Approach

Network Observability is a solution that brings together the active and passive network monitoring approaches, described in the Establishing End-to-End Visibility of Internet Performance white paper. The solution combines the automated discovery capabilities for the internally managed network provided by DX NetOps with the active external network monitoring provided by AppNeta.

The Broadcom approach to provide network operations teams with visibility into Internet performance involves:

Active network monitoring (Delivery monitoring) to provide visibility into layer 3 network performance and traffic routes between end users, Internet service providers (ISPs), and cloud applications.

Web synthetic transactions (Experience monitoring) to provide visibility into layer 7 application performance of cloud-hosted web applications and whether network performance issues to cloud providers impact the end-user experience of web applications.

Active Network Monitoring for Layer 3 Network Performance Visibility

Active network monitoring with AppNeta is accomplished through the TruPath™ packet train dispersion technology. TruPath sends and receives many varied short sequences of packets, which are referred to as packet trains. Packet trains are transmitted using Internet Control Message Protocol (ICMP) or User Datagram Protocol (UDP). Packets are sent to defined end hosts or targets, which can be any endpoint that can respond to an ICMP-based ping or can send back a Transmission Control Protocol (TCP) or UDP packet.

Using this technology, TruPath can build up a complete set of network statistics very quickly—in many cases, in just tens of seconds. TruPath uses special patterns designed to detect if instrumentation packets are interfering with each other. If that happens, it takes more varied samples over a longer time scale to ensure that the resulting statistics are clean.

By sending multiple sets of distinct packet sequences, TruPath can analyze a wide range of different traffic conditions that a user on a network path might experience. TruPath probes the path repeatedly with the packet sequences, obtaining a statistically significant collection of responses for each type. TruPath will detect when samples are captured during times of rapidly changing conditions and adjust its measurement patterns accordingly.

Unlike packet flooding technologies available on the market, the TruPath approach delivers high accuracy without requiring an intrusively high instrumentation load on the network path. Because of the technology’s low overhead, network operations teams can run TruPath in production and through third-party networks for end-to-end visibility.

To learn more about the TruPath technology, refer to Understanding Network Monitoring.
Web Synthetic Transactions for Layer 7 Application Performance Visibility

Network operations teams often have far less insight into application performance than DevOps teams. Network teams need to isolate if and when an application is the root cause of a reported issue.

To monitor web application performance from the perspective of end users, AppNeta Monitoring Points test web applications at regular intervals. Monitoring can be configured using a Selenium script to simulate user interactions in a browser, or using a direct HTTP request to interact with a REST API.

Implement Network Observability to Evaluate Internet Performance

To set up network monitoring to evaluate Internet performance:

Create a monitoring plan.
Deploy Monitoring Points.
Create monitoring policies to define the applications and networks to monitor.

Create a Monitoring Plan

Monitoring in AppNeta is configured using monitoring policies. Monitoring policies are most effective and easiest to manage with clear, simple rules to define where to monitor from.

To ensure clear, simple rules, we recommend first creating a plan for where you want to monitor from (monitoring sources) and what you want to monitor (monitoring targets).
Monitoring Sources for Internet Connectivity

For Internet connectivity, we recommend planning to monitor from any location users access the Internet. This includes headquarters, branches, and users working remotely from home. You may also want to monitor from Cloud tenants to emulate connectivity from end users in a given region where you cannot deploy Monitoring Points directly.

In your plan, put each Monitoring Point that will monitor a target into logical groups and determine how the groups of Monitoring Points will be selected in the policy. Monitoring Point selection in a policy can be based on Monitoring Point tags, such as Monitoring Point type, geographic location, or any custom tags assigned to Monitoring Points, and on network rules, such as the subnet.
Monitoring Targets for Internet Connectivity

We recommend monitoring Global Monitoring Targets (GMTs) with dual-ended paths to understand Internet connectivity.

GMTs are highly available targets owned and managed by Broadcom and installed in global cloud provider locations worldwide. They allow you to monitor your remote site connectivity to specific regions around the globe. Monitoring GMTs provides bidirectional visibility into the outbound and inbound network performance for Internet connectivity.

You can also make business-critical web-hosted applications targets for monitoring. That way, you can understand Internet connectivity to the apps your users need most. Monitoring web application targets allows you to compare against paths from the same source to GMTs to better understand overall Internet performance.
Example Monitoring Plans for Evaluating Internet Performance

What could a monitoring plan actually look like? This section includes examples of simple monitoring plans for cloud migration and cloud adoption scenarios. In these diagrams, the network administrator plans to monitor the Internet connectivity from various locations.
Example 1: Monitor Internet Performance in an Enterprise Corporate Network

The following diagram represents an example monitoring plan that would allow you to determine whether your users could access the Internet and access web applications across a number of office headquarters and locations.

First, Monitoring Points are installed at a corporate headquarters location, in branch offices, and on workstations of users who work remotely. Dual-ended network monitoring is planned between the Monitoring Points and a GMT. This setup allows network operations teams to assess whether headquarters, branch offices, and remote employees are able to connect to the public Internet.

Diagram showing an example monitoring plan for monitoring Internet performance using GMTs.

Next, web paths are created to monitor business-critical web applications hosted on the public Internet, like Microsoft 365 or Salesforce. Web monitoring is a set of tools used for understanding and visualizing the application performance experienced by users at a given location. When the web paths are created, single-ended network paths are also created, allowing you to assess connectivity and Internet performance between the given Monitoring Point location and the SaaS location as well.

Diagram showing an example monitoring plan for monitoring Internet performance using GMTs as well as business-critical web applications hosted in the cloud, such as Microsoft 365.

Next, the monitoring plan is expanded even further to deploy container-based Monitoring Points (CMPs) in cloud environments. This allows you to monitor the private cloud environment where you host your web applications. Dual-ended paths are planned from Monitoring Points in headquarters, branches, and user workstations to the CMPs. Monitoring to both the CMPs in the internally managed cloud environment, and the GMT provides network operations teams with the ability to compare end-to-end network performance to different cloud hosts.

Web paths are also created between end-users at headquarters, branch offices, and workstations, to web applications hosted by the organization in their private cloud—for example, their Human Resources application. These web paths also create single-ended network monitoring paths, enabling both network and web monitoring of the apps.

Diagram showing an example monitoring plan for monitoring Internet performance using GMTs, web applications available through the public Internet, and container-based Monitoring Points and web applications hosted by the company.
Example 2: Monitoring Internet Performance With an SD-WAN Installation

The following diagram illustrates an example monitoring plan for an organization monitoring Internet performance over two ISPs in a software-defined wide area network (SD-WAN) installation.

Monitoring Points would be deployed to branch office locations. A web path, and the single-ended network path it creates, would target a SaaS app from the office Monitoring Points. Separately, web and single-ended network paths would monitor the SaaS app via each ISP.

Diagram showing an example monitoring plan for monitoring Internet performance with an SD-WAN Installation.

In this example, the end-user web app experience is measured using paths to the SaaS application over the SD-WAN device (overlay). The web and network paths going through each ISP give you visibility into the underlay network health and web app experience. This setup allows network operations teams to identify performance issues in an SD-WAN installation and compare performance between ISPs.
Example 3: Monitoring Internet Performance in a CASB Environment

In the following diagram, we provide a recommendation for monitoring Internet performance in a cloud access security broker (CASB) environment.

Monitoring Points are deployed to each location where there are users accessing web apps—headquarters, branch offices, and workstations or remote workers. Once the Monitoring Points are deployed, they can be configured to measure bandwidth attributable to each web app and each user (Usage monitoring), to emulate users accessing the web apps (Experience monitoring), and to monitor network health (Delivery monitoring).

Diagram showing an example monitoring plan for monitoring Internet performance in a CASB environment. It shows dual-ended network paths going from each Monitoring Point to a Broadcom GMT, single-ended network paths going from each Monitoring Point to a cloud-hosted web application, and web paths targeting a cloud-hosted web application via the CASB service. Those web paths will also create single-ended network paths from each Monitoring Point to the CASB service.

When Experience monitoring web paths target a web app, they may, like user traffic, pass through a CASB service. These web paths enable you to determine that the web app can be accessed and to see how it is performing from a user perspective.

Since CASB services can block ICMP traffic, the single-ended network paths associated with web paths terminate at CASB. Even though they do not go through the CASB service, these network paths enable you to determine the routing and performance of the network to the CASB service.

In order to determine the routing and performance of the network to the web app without the influence of CASB, additional single-ended network paths (solid blue lines) that bypass the CASB service should be created from each remote location to the web app.

Finally, in order to determine whether the Internet can be accessed and to determine whether there are network performance issues to or from the Internet, dual-ended network paths (double-dashed blue lines) are created from each remote location to AppNeta Global Monitoring Targets (GMTs).
Deploy Monitoring Points
When your plan is ready, implement it by deploying Monitoring Points. There are several different Monitoring Point models that can be used to evaluate Internet performance. For each location or workstation that should monitor Internet performance, plan to deploy an appropriate Monitoring Point:
- Container Monitoring Points can be used to monitor from cloud environments, or from customer premise equipment, such as a Cisco Catalyst 9300/9400 switch.
- For headquarters or branch offices, we usually recommend physical or virtual Monitoring Points.
- For monitoring from user workstations, we recommend native Monitoring Points.
As you deploy Monitoring Points, consider tagging them with contextual information. Tags help you organize and navigate AppNeta monitoring data in ways that match your mental model of your enterprise. They let you search, sort, and filter monitoring data, and also let you quickly select Monitoring Points in monitoring policies. For example:
- Location. You might want to be able to see how Internet performance metrics differ by location. Monitoring Point locations are usually added automatically, which lets you compare performance by city, state or province, and country. You can also add your own custom tags for regions or zones, such as EMEA or APAC.
- ISP. Consider tagging Monitoring Points based on the ISP that provides Internet service in its location. That allows you to filter Internet performance data by ISP or compare performance between them.
To learn more about deploying Monitoring Points, refer to the following resources:
- Monitoring Point Feature Comparison (AppNeta documentation)
- Getting Started (AppNeta documentation; select the appropriate model from the Set up a Monitoring Point section for details on how to deploy Monitoring Points)
- Deployment Best Practices (AppNeta documentation)
Set up Network and Web Application Monitoring with Monitoring Policies
Use monitoring policies in AppNeta to carry out the plan for defining which applications and networks to monitor, and from where. Dynamic policy rules enable you to automatically set up monitoring from new Monitoring Points that match the policy rules. Policies should be created for each target in your monitoring plan.

In the first example monitoring plan for Internet Performance, the network administrator would create the following monitoring policies:
- One policy to target a Global Monitoring Target. The target could be gmt.pm.appneta.com to automatically target the GMT with the lowest latency from each location, or it could be a GMT in a specific region. Policy rules would be configured to include all Monitoring Points in headquarters, branch offices, and user workstations.
- One policy to target cloud-hosted container-based Monitoring Points. Policy rules would be configured to include all Monitoring Points in headquarters, branch offices, and user workstations.
Important: When targeting a GMT or a CMP hosted in a cloud environment, it is important to select Dual-ended monitoring in the policy.
The following video demonstrates how to configure a monitoring policy in AppNeta in order to monitor network performance.

Optionally, add web monitoring to monitor each cloud-hosted web application of interest to you. Use an HTTP workflow to monitor connectivity to critical web applications, from supported Monitoring Points to RESTful API endpoints. Create a browser workflow to monitor end-user experience within web applications from supported Monitoring Points.

The following video demonstrates how to add an HTTP workflow to a monitoring policy.

The following video demonstrates how to add a browser workflow to a monitoring policy.

To learn more about how to set up monitoring in AppNeta, refer to the following resources:

Use Network Observability to Understand Internet Performance Over Specific Routes

Routes are dynamic. At any given time, multiple third-party networks, diverse load-balancing systems, and dynamic routing technologies may be in play. Network operations teams need to be able to understand Internet performance in real time. When there are issues, they need to be able to diagnose where the problem is, who is affected, and how the end-user is affected.

AppNeta monitors end-to-end performance from the user device, through the last-mile ISP network, and out to third-party application service provider environments. With this visibility, network operations teams can quickly and intelligently isolate where issues are occurring.

Understand AppNeta’s Performance Metrics
Active monitoring generates performance metrics that you can use to understand different aspects of your network and application performance.

Network performance metrics useful for understanding Internet performance include the following:
- Connectivity indicates whether the Monitoring Point can connect to the target. Connection loss occurs with 100% packet loss.
- Packet loss is a measure of the number of packets that did not make it to their intended destination. AppNeta provides metrics for Data Loss, based on packet trains emulating data traffic, and Voice Loss, based on packet trains emulating voice traffic.
- Round-trip time (RTT) is the time it takes for a packet to go from the source Monitoring Point to the target and back.
- Jitter is a measure of variation in latency. AppNeta provides metrics for Data Jitter, based on packet trains emulating data traffic, and Voice Jitter, based on packet trains emulating voice traffic.
- Mean Opinion Score (MOS) is an estimate of the rating a typical user would give to the sound quality of a call. It is expressed on a scale of 1 to 5, where 5 is perfect. It is a function of loss, latency, and jitter. It also varies with voice codec and call load.
Additional wireless metrics (such as Signal Quality, Link Speed, RSSI) and host metrics (such as CPU, Memory, and Top Processes) are available for supported Monitoring Points.

Web performance metrics help you understand how a web application actually performs for an end-user. They include the following:
- Transaction Time is the total time for each test of a workflow on a web path to complete. For browser workflows, this includes the time for the Selenium script to execute each milestone, including page load time and any intermediate activities taken by the script, such as pauses.
- Page Load Time is the time for all page loads within each test of a workflow on a web path to complete.
- HTTP Server Response Time is the time it takes to complete each component of an HTTP request, including redirect time, DNS lookup time, TCP connection time, SSL connection time, request wait time, and download time.
- Download Size is the number of bytes downloaded during a response to a HTTP request and Download Speed is how many bytes are downloaded per second.
- Apdex Score is an industry-standard measure for reporting and comparing application performance in terms of end-user experience. It is a single number between 0% and 100%, where 100% indicates that a user would be completely satisfied with an application’s response time.
To learn more about performance metrics generated by AppNeta, refer to the following documentation articles:
- Network Timeline
- Web Timeline
Identify the Error Domain to Reduce MTTR
The goal when investigating an issue detected by AppNeta is to quickly narrow down the error domain—the network segment responsible for degraded performance experienced by test packets. For example, when monitoring performance between end-user workstations and cloud-hosted applications, the error domain could be the workstation, the user’s wireless environment, the last-mile ISP, the cloud edge, the cloud backbone, the application environment, or the application itself.

A typical approach to investigating degraded performance looks like this:
- How widespread is the problem?
- What are the symptoms for impacted paths?
- What infrastructure do the impacted paths have in common?
- What are next steps?
How widespread is the problem?

First, determine how widespread an issue is. Sometimes this is all that is needed to isolate the error domain.

Review which paths are experiencing similar issues at the same time for a quick indication of where the issue might be. For example, if all paths experiencing an issue are from the same ISP, the problem is likely with the provider’s service.
What are the symptoms for impacted paths?

Review the timeline charts for patterns and anomalies in performance metrics leading up to and during the period of degraded performance.

Regular patterns can indicate a performance impact due to a scheduled activity—for example, scheduled data backups occurring at the same time every day at the source location.
What infrastructure do the impacted paths have in common?

Use comparison views to compare routes for multiple paths and look for commonalities across impacted paths. Check whether routes changed over time before and during the period of degraded performance.

Check for anomalies or unexpected performance changes along the route. To identify the error domain, look for both the presence of an anomalous result (for example, packet loss or a drop in MOS) at a hop along the route and its persistence through each subsequent hop to the target.
Next Steps
Once you know how widespread the issue is, you understand the symptoms, and you have identified infrastructure common to the paths experiencing issues, there are a number of next steps you can take to identify the error domain:
- If an issue is suspected to be introduced at a WAN egress router or ISP connection point, investigate the possibility of overutilization at the source location.
- If an issue is suspected to be introduced at a LAN hop, investigate the device itself, the preceding device, and the infrastructure in between.
- If an issue is suspected to be introduced by an individual’s workstation or wireless environment, review the host and wireless metrics for supporting evidence.
- To determine if a network event impacted the user experience of the application, review layer 7 web performance metrics for the related web paths.

Broadcom Makes Internet Performance Visible

Network Observability by Broadcom helps you address the challenge of end-to-end visibility into Internet performance by providing active monitoring of external networks and web monitoring of business-critical web applications.

With this solution, network operations teams gain the visibility required to validate that performance meets expectations, and to identify the error domain when performance issues arise.

Schedule a demo to see exactly how Network Observability by Broadcom can help you validate cloud connections. Or, for more information on how to implement Network Observability by Broadcom for other use cases, explore other learning paths.