Learning Path
Visibility Into Internet Performance
Learn how Network Observability by Broadcom helps network operations teams evaluate Internet performance and resolve issues.
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.
 |
Challenge: The move to external service providers significantly reduces visibility into the performance of the underlying infrastructure. 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 our white paper Establishing End-to-End Visibility of Internet Performance.
To set up network monitoring to evaluate Internet performance:
- Create a monitoring plan
- Deploy Monitoring Points
- Set up active network monitoring with monitoring policies
- Set up web synthetic transactions with web app groups
- Set up deep packet inspection with Usage monitoring
- Customize alert profiles to align with service-level agreements
Create a monitoring plan
Network 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.
 |
Note: As of AppNeta 17.10.x, AppNeta supports subnet rules in a network monitoring policy. Additional network rule types are planned for future enhancements. Keep an eye on AppNeta release notes for updates. |
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:
- For monitoring from data centers, we recommend the r1000.
- For headquarters or branch offices, we usually recommend physical or virtual Monitoring Points.
- For monitoring from user workstations, we recommend native Monitoring Points.
- Container Monitoring Points can be used to monitor from cloud environments, or from customer premise equipment, such as a Cisco Catalyst 9300/9400 switch.
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 active network 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 that requires active network monitoring.
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. |
After setting up these policies, network paths would be created between all the source Monitoring Points and the targets.
|
Note: We have not set up monitoring policies between the source Monitoring Points and the web applications because we are planning to create web paths for Experience monitoring to those web application targets. When web monitoring is configured between a source Monitoring Point and a target, single-ended network monitoring is automatically configured between the same source and target. |
The following video demonstrates how to configure a monitoring policy in AppNeta in order to monitor network performance.
To learn more about how to set up network monitoring in AppNeta, refer to the following resources:
- AppNeta: Configure Network Monitoring (Online course)
- Set Up Delivery (AppNeta documentation)
Set up web synthetic transactions with web app groups
AppNeta’s Experience monitoring allows you to set up automated scripts to simulate user interactions with web applications. Experience monitoring captures Internet performance data in the context of using actual applications and websites. It provides a realistic view of how the Internet connection is affecting their browsing experience, allowing you to see metrics like page load times and response times.
Create a web app group in the Experience area of AppNeta 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.
|
Note: Monitoring Policies will replace web app groups as the mechanism to set up web application monitoring in AppNeta. Web monitoring policies will provide a simple, scalable, and automated way to set up monitoring for your web applications. To obtain early access to this feature, please contact your Broadcom account representative. See AppNeta Release Information for updates. |
When a web app group is created, network monitoring is also created from each selected Monitoring Point to the target web application.
The following video demonstrates how to create a browser workflow in AppNeta to monitor web application performance.
To learn more about how to set up web app monitoring in AppNeta, refer to the following resources:
- Set up Experience (AppNeta documentation)
- Web App Groups (AppNeta documentation)
- Selenium Scripting (AppNeta documentation)
Set up deep packet inspection with Usage monitoring
Usage monitoring inspects the traffic on a link to determine which applications are being used and who is using them. It also shows the amount of available bandwidth consumed by a given application or user. Usage monitoring enables you to see how bandwidth at a given location is being devoted to particular applications, hosts, and users.
Usage monitoring is useful when evaluating Internet performance because it shows you how bandwidth is actually being consumed, and who the biggest consumers of it are.
|
Note: Before setting up deep packet inspection, a supported Monitoring Point must be deployed. The capture interface, also referred to as the Usage port, must be either connected to a SPAN or mirror port or the bypass ports connected inline. |
In the Usage area of AppNeta, configure traffic direction for each capture interface so that AppNeta can identify local subnets, resolve hostnames on local subnets, and distinguish between inbound and outbound traffic. Then, start traffic capture for each capture interface.
The application identification engine in AppNeta includes over 2000 application definitions. Optionally add custom application definitions to the library, then apply the custom application definitions to relevant Monitoring Points.
To learn more about setting up deep packet inspection in AppNeta, refer to the resources:
- Configure Traffic Analysis with AppNeta Usage (Online course)
- Set Up Usage (AppNeta documentation)
Customize alert profiles to align with SLAs
Once you are getting monitoring data on your Internet performance, you can configure alerts and notifications so that you know immediately when there are signs of performance issues. This lets you do proactive troubleshooting to quickly address performance issues.
The alert profile is the mechanism in AppNeta to specify which metrics and thresholds to analyze monitored performance against. When AppNeta detects a violation of an alert profile condition, the system logs an event. When configured by an admin, the event can trigger a notification by email, SNMP trap, or webhook.
In most scenarios, the default alert profile is sufficient. You may need to customize an alert profile if your organization has specific performance requirements for the monitored cloud connections or to be consistent with an SLA.
For Internet connectivity, an effective alert profile for network paths could be the following:
- For network paths to the GMT from headquarters and office branches, a violation occurs immediately when connectivity is lost. The violation clears when connectivity is restored. A notification is sent when the violation persists for two minutes.
- For network paths to the GMT from user workstations, a violation occurs immediately when connectivity is lost for 5 minutes. The violation clears when connectivity is restored. Keep in mind that, for user workstations, AppNeta may register connectivity loss for events such as disconnecting from a VPN that may not signal an issue connecting to the Internet. Consider that when creating your alert profiles.
- For network paths to the GMT from headquarters, office branches, and user workstations, a violation occurs when there is 2% data loss or more for 5 minutes. The violation clears when there is less than 2% data loss for 5 minutes. A notification occurs when the violation occurs for two minutes.
To learn more about how to create custom alert profiles in AppNeta refer to the following resources:
- AppNeta: Configure Network Monitoring (Online course)
- Delivery Alerts (AppNeta Documentation)
- Experience Alerts (AppNeta Documentation)
- Usage Alerts (AppNeta Documentation)
 |
Tip: You can integrate AppNeta with DX NetOps to baseline network performance and raise alarms based on deviations from baseline. To learn more about baselines, refer to the following resources:
|
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 network monitoring generates performance metrics that you can use to understand different aspects of your network’s performance.
The metrics can be classified as either primary metrics, which are directly measured and used to detect network issues, or derived indicators, which are either derived or inferred and used to assist with diagnosis.
Network performance metrics
Primary 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.
Derived network performance indicators:
- Latency is the time it takes for a packet to go from a source to a target. AppNeta calculates latency as one half of the RTT of the fastest packet in a packet train.
- 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.
- Capacity measures the end-to-end transmission rate observed for small bursts of traffic, between a source Monitoring Point and a given target. Total Capacity is the peak transmission rate observed over the previous three hours. Available Capacity is the portion of total capacity that is available for use.
|
Note: When reviewing results from CMPs, keep in mind that capacity measurements can be influenced by networking on the host, kernel version on the host, and other containers sharing the host. |
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.
To learn more about network performance metrics, refer to Network Path Performance (AppNeta documentation).
Web performance metrics
Web synthetic transactions generate performance metrics displayed as charts in the Experience area of AppNeta. These 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 Experience metrics, see Web Path Details (AppNeta documentation).
Usage performance metrics
Deep packet inspection generates performance metrics presented in a table in the Usage area of AppNeta, including the following metrics:
- Network Latency is the time it takes a packet to travel between a client and a server.
- Application Latency is the time the server takes to respond to a request from the client. AppNeta provides the maximum and average values.
To learn more about Usage performance metrics, see Usage Chart Data (AppNeta documentation).
Configure dashboards and reports to summarize Internet performance
Dashboards display aggregate and present key metrics and data points in real-time, allowing for quick monitoring and analysis of your Internet performance. Reports compile, analyze, and summarize monitoring data over a specific period. Both dashboards and reports can identify trends and provide insights into Internet performance issues.
There are three dashboards that are particularly useful for understanding Internet performance: the Network Violation Summary Dashboard, the Current Network Violation Map Dashboard, and the Location Bandwidth Quality Report.
Network violation summary dashboard
The Network Violation Summary Dashboard provides an at-a-glance view of the most significant network path violations over a selected period. The dashboard identifies (by color) the groups of network paths with the highest average violation durations.
Use it to quickly see which network paths may be experiencing the poorest Internet performance. You can filter the data to see the results by location, business unit, or even ISP. Enable the auto-refresh setting to have the data automatically refresh every few minutes.
For information on setting up and interpreting the dashboard, see Network Violation Summary Dashboard (AppNeta documentation).
Current network violation map dashboard
The Current Network Violation Map Dashboard provides a geographical view of the current network status. It displays all path sources (Monitoring Points), path targets (URLs, server/workstation IPs, or Monitoring Points), and the WAN paths between them on a world map.
This dashboard is useful in showing you where poor Internet performance is occurring geographically. You can filter the displayed data by tags, such as ISP.
For information on setting up and interpreting the dashboard, see Current Network Violation Map Dashboard (AppNeta documentation).
Location bandwidth quality report
The Location Bandwidth Quality Report compares the performance of a WAN network path to the stated performance of the Internet service package you purchased from your ISP.
|
Note: AppNeta provides a metric for “Capacity” not “Bandwidth.” Bandwidth is the transmission rate of the physical media link between your site and your ISP, whereas capacity is a measurement of the transmission rate for the entire network path—from a source to a target. In general, when interpreting capacity measurements, pay attention to the proportion of available capacity over time, rather than the exact values. A sudden change in the available capacity-to-total capacity ratio could indicate a performance problem. |
This report is useful because it helps you directly compare your Internet performance to the performance levels ISPs have agreed to provide you. It can also be used to quantify service degradations financially.
For information on setting up and interpreting the dashboard, see Location Bandwidth Quality Report (AppNeta documentation).
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?
- 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. Also, review any diagnostic tests that ran while performance was degraded.
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 the issue is introduced at a WAN hop within a provider network, correlate results with additional diagnostics before contacting the provider.
- 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 available, review Usage results collected by the relevant Monitoring Point for further insight.
- 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.
To learn more about how to investigate performance issues with AppNeta, refer to the following resources:
- Intro to AppNeta Results (Online course)
- Investigating Violation Events (AppNeta documentation)
- Network Path Routes (AppNeta documentation)
- Diagnostics (AppNeta documentation)
Validate SLAs with ISPs
Ensuring that your ISP meets the promised service levels is crucial for maintaining optimal network performance. If you have a circuit where the end-to-end Internet performance is guaranteed, then AppNeta’s Location Bandwidth Quality Report provides a powerful tool for validating these SLAs, enabling businesses to hold their ISPs accountable and ensure reliable connectivity.
To validate, ISP SLAs with the Location Bandwidth Quality Report, set up reference paths, together with the Internet performance values specified in the SLA. If possible, also enter in a cost for the service—this allows you to quantify the value of the capacity that you pay for but do not use.
Then compare the provisioned capacity values measured for a specific reference path to the bandwidth level specified in an SLA. Look to see whether the actual performance of a service link is less than the performance of the Internet service package you purchased from the ISP. This data can help you negotiate your next contract with your ISP.
|
Note: ISPs typically only guarantee bandwidth to the edge of their own network. They do not provide performance assurances for segments of the public Internet that fall outside their control. For that reason, this report should only be used to validate SLAs when the end-to-end capacity for a particular link is guaranteed. It would not be as useful to apply it in a residential context, where the path enters into segments of the public Internet that the ISP does not own. |
Also, look at the unused capacity. If this value is consistently high, you may have more capacity than you need. An Internet service package review may be appropriate.
To learn more about how to use the Location Bandwidth Quality Report to validate SLAs, refer to the following resources:
- Configure Dashboards and Reports (Online course)
- Location Bandwidth Quality Report (AppNeta documentation)
