Because most organizations rely on the cloud in some capacity, they also fundamentally rely on third-party networks to access these critical cloud resources. Network operations teams need a sound strategy for reestablishing comprehensive visibility, including into cloud and transit networks.

Challenge: While 50% of IT spending is on cloud services, network operations teams have lost visibility into cloud services. Network operations teams need to assure service-level agreements (SLAs) and connectivity to those cloud services.

Cloud adoption decisions are largely made by executive teams, but the responsibility for managing access to cloud services and addressing issues when they arise often falls squarely on the shoulders of network operations teams.

Visibility is essential to validate cloud connections that support business-critical apps and services. To do this, network operations teams need a solution that delivers end-to-end visibility across both internal and externally managed networks, adds application context to network insights, and tracks SLAs for networks and services.

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 validate cloud connections in two scenarios:

• Cloud migration: Moving existing, internally managed applications and services to cloud environments.
• Cloud adoption: Replacing historically on-premises applications with cloud-hosted services typically outside of the network operations team’s control.

To learn more about how Network Observability by Broadcom helps with validating cloud connections, read the whitepaper: Validating Cloud Connections: 3 Keys to Success for Network Operations Teams.

Network Observability by Broadcom is a solution that brings together the active and passive monitoring approaches described in the Validating Cloud Connections 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 cloud services involves:

• Active network monitoring to provide visibility into layer 3 network performance and traffic routes between end users and cloud services, between cloud providers, and between data centers and cloud providers.
• Web synthetic transactions to provide visibility into layer 7 application performance of cloud-hosted web applications and whether network performance issues to cloud providers impact end-user experience of web applications.
• Deep packet inspection to identify third-party web applications adopted within an organization that the network operations team may not be aware of, and to provide metrics for application and network performance experienced by actual end users.

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. By probing the path repeatedly with the packet sequences, TruPath collects 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, this approach delivers high accuracy without requiring an intrusively high instrumentation load on the network path. With the technology’s low-overhead approach, 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 the AppNeta documentation article: 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 a direct HTTP request to interact with a REST API.

Deep Packet Inspection for Traffic Analysis and Application Identification

AppNeta’s deep packet inspection (DPI) enables network operations teams to passively monitor and identify application traffic on the network and monitor how bandwidth is consumed by particular applications, hosts, and users. DPI provides network operations teams with proactive visibility into new cloud-hosted applications running on the network and with application performance indicators such as latency and TCP retransmit rate.

DPI requires an AppNeta Monitoring Point deployed at the network edge. The Monitoring Point generates traffic flow records in real time (every five minutes) and passes them to AppNeta. The application identification library contains over 2,000 application definitions to identify and categorize application traffic. The library can be customized with user-created application definitions.

Configuring the solution to validate cloud connections involves the following procedures:

• Create an AppNeta monitoring plan.
• Deploy AppNeta Monitoring Points at the locations from which you want to monitor cloud connectivity.
• Deploy AppNeta Monitoring Points within the cloud environments you control.
• Deploy AppNeta physical or virtual Monitoring Points at the locations where you want to identify which applications are running on the network.
• Create monitoring policies to configure layer 3 network monitoring in AppNeta.
• Create web app groups to actively monitor layer 7 web application performance in AppNeta.
• Optionally set up deep packet inspection for application identification and visibility in AppNeta.
• Customize alert profiles in AppNeta to align with SLAs.
• Configure a dashboard to summarize network performance for cloud targets from relevant locations.

Note: Organization Admin and Advanced users can manage Monitoring Points in AppNeta. Organization Admin, Advanced, and Standard users can configure monitoring in AppNeta. To learn more about user roles, refer to the AppNeta documentation article: Users.

Create an AppNeta Monitoring Plan

Effective network monitoring in AppNeta relies on monitoring policies—clear, simple rules to define what to monitor and from where. For each target, plan the monitoring sources. You can group monitoring sources using criteria such as Monitoring Point type, geographic location, and business context factors, such as department, business unit, and so on. Select Monitoring Points into a monitoring policy using custom tags, subnets, VLANs, and connection type.

The following sections include examples of simple monitoring plans for cloud migration and cloud adoption scenarios. In these diagrams, the network administrator plans to monitor the network connection to a cloud-hosted application from various locations.

Example Monitoring Plan for a Cloud Migration Scenario

The following diagram represents an example monitoring plan to provide end-to-end network visibility between relevant end users and an internally managed, cloud-hosted web application.

In this example monitoring plan, Monitoring Points will be installed alongside the application end users at a corporate headquarters and branch offices, and on workstations of users who work remotely.

Since the cloud host is managed internally, a Monitoring Point will also be installed alongside the web application.

Dual-ended network monitoring between the Monitoring Points representing end users and the Monitoring Point installed in the cloud host will provide bidirectional visibility into the outbound and inbound network performance to and from the cloud environment. Additionally, the plan includes web performance monitoring of the web application from the perspective of end users.

Diagram showing an example monitoring plan for monitoring an internally managed cloud-hosted web application.

In the following diagram, the monitoring plan is expanded to include dual-ended network monitoring to a Broadcom-managed Global Monitoring Target (GMT). Monitoring to both the container-based Monitoring Point in the internally managed cloud environment, and the GMT in Azure provides network operations teams with the ability to compare end-to-end network performance to different cloud hosts.

Diagram showing an example monitoring plan for monitoring an internally managed cloud-hosted web application, with monitoring to a Global Monitoring Target.

Example Monitoring Plan for a Cloud Adoption Scenario

The following diagram represents an example monitoring plan to provide end-to-end network visibility between relevant end users and an externally managed web application.

In this example monitoring plan, Monitoring Points will be installed alongside the application end users at a corporate headquarters and branch offices, and on workstations of users who work remotely.

Since the cloud host is managed externally, a Monitoring Point cannot be installed alongside the web application. Single-ended network monitoring between the Monitoring Points representing end users and the web application will provide visibility into the round-trip network performance to the cloud environment. Additionally, the plan includes web performance monitoring of the web application from the perspective of end users. Dual-ended network monitoring to a Broadcom-managed Global Monitoring Target (GMT) in Azure provides network operations teams with the ability to compare end-to-end network performance to different cloud hosts.

Diagram showing an example monitoring plan for monitoring a third-party SaaS application, with monitoring to a Global Monitoring Target.

Deploy AppNeta Monitoring Points

For cloud environments you control, plan to deploy a container-based Monitoring Point (CMP) within the same cloud environment as your web application infrastructure to act as a monitoring target.

For each location or workstation that should monitor cloud connectivity, plan to deploy an appropriate Monitoring Point. Make sure to select a Monitoring Point model that supports the type of monitoring you want to configure from each location. For example, use a physical or virtual Monitoring Point where deep packet inspection is required. To learn about the differences between each Monitoring Point model, refer to the AppNeta documentation article: Monitoring Point Feature Comparison.

Typically, native Monitoring Points (NMP) are recommended for user workstations, r1000 physical Monitoring Points are recommended for data centers, and physical or virtual Monitoring Points are recommended for offices. Monitoring Points are also available for deployment to customer premise equipment, such as Cisco Catalyst 9300/9400 switches.

For applications migrated to the cloud, Global Monitoring Points deployed and managed by Broadcom can be used to monitor and validate the performance of cloud-hosted applications from outside your network. To learn more about Global Monitoring Points, refer to the documentation article: Global Monitoring Points (GMP).

To learn more about how to deploy Monitoring Points, refer to the following AppNeta documentation article and select the model from the Set up a Monitoring Point section: Getting Started.

For each location where you want to run deep packet inspection for application identification, plan to deploy a supported Monitoring Point at a location with access to network traffic, typically at the WAN gateway, behind Network Address Translation (NAT). The Monitoring Point’s Usage ports are capture interfaces that can be connected to a SPAN or mirror port (pictured). Alternatively, a pair of bypass ports can be used with some models to connect the Monitoring Point inline. The exact ports to use depend on the Monitoring Point model. To learn more about how to cable Monitoring Points for deep packet inspection, refer to the Cabling for Usage Monitoring section of the following AppNeta documentation article: Monitoring Point Cabling.

Diagram showing an AppNeta Monitoring Point connected to the Mirror destination port of a switch via the primary Usage port for out-of-band cabling. The switch is connected via its Mirror source port to a router, and the router to the internet.

Set Up Active Network Monitoring with Monitoring Policies

Use monitoring policies in AppNeta to carry out the plan for 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.

In the example monitoring plan for a cloud migration scenario, the network administrator would create a monitoring policy that targets a container-based Monitoring Point deployed in the same cloud environment as the host and customize the monitoring preferences for dual-ended monitoring. The network administrator would create a second dual-ended monitoring policy that targets a Global Monitoring Target, either targeting gmt.pm.appneta.com to automatically target the closest GMT from each location, or targeting a GMT in a specific region.

Note: If web performance monitoring will be conducted, a single-ended network monitoring policy is not required to monitor the network connection to the application. When web monitoring is configured, single-ended network monitoring is automatically configured.

The following video demonstrates how to configure a monitoring policy in AppNeta to monitor network performance. 

Important: When targeting a container-based Monitoring Point hosted in a cloud environment, it is important to select Dual-ended monitoring in the policy.

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

Create a web app group in the Experience area of AppNeta to monitor each cloud-hosted web application. 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 soon 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.

The following video demonstrates how to add milestones in a browser workflow in order to monitor end-user experience logging into a web application.

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

Before setting up deep packet inspection, a supported Monitoring Point must be deployed with the capture interface, also referred to as the Usage port, 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)
• Cabling for Usage Monitoring (AppNeta Documentation)
• ​​Controlling Usage Monitoring (AppNeta Documentation)
• Custom Applications (AppNeta Documentation)
• Secondary Usage Monitoring Ports (AppNeta Documentation)

Customize Alert Profiles to Align with SLAs

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.

If configured by an admin, the event can trigger a notification by email, SNMP trap, or webhook.

For metrics other than connectivity loss, AppNeta may also automatically trigger additional tests, such as a diagnostic test.

In most scenarios, the default alert profile is sufficient. You may need to customize an alert profile if your organization has existing SLAs or specific performance requirements for the monitored cloud connections. For example, an application that is hybrid hosted between on-premises and cloud may have a latency requirement that could be added to a custom alert profile.

Note: The default network path alert profile includes alert conditions to track violation events when connectivity to the target is lost for one minute, when data loss is greater than 2% for two minutes, and when data jitter is greater than 100 ms for two minutes. The default web path alert profile includes conditions to violate when connectivity is lost, HTTP errors are found, or script errors are found for two consecutive tests.

To learn more about how to create custom alert profiles in AppNeta refer to the following resources:

• AppNeta: Configure Network Monitoring (Online Course, refer to the Performance Metrics and Alerts lesson)
• Delivery Alerts (AppNeta Documentation)
• Experience Alerts (AppNeta Documentation)
• Usage Alerts (AppNeta Documentation)

Note: If AppNeta is integrated with DX NetOps, consider using DX NetOps to baseline network performance and raise alarms based on deviations from baseline. To learn more, refer to the following resources: DX NetOps 23.3.x: Integrate AppNeta 200 (Online Course) Baseline Calculations (DX NetOps Documentation) DX NetOps 23.3.x: Configure Performance Thresholds and Notifications 200 (Online Course)

Configure Dashboards and Reports to Summarize Network Performance for Cloud Target

Create dashboards to provide the network operations team with a summary view of cloud connectivity.

AppNeta dashboards provide a summary view with a focus on service quality. They give you the flexibility to look broadly at the entire AppNeta monitoring environment and surface the most critical issues to you as fast as possible.

• Use the Application Quality dashboard for visibility into how different cloud services are performing over time for relevant geographic regions.
• Use the Violation Summary dashboards for visibility into which network or application groups have been in violation for the longest and require attention.

The following example of an Application Quality dashboard summarizes how a cloud-hosted application performs from various locations. In this example, the dashboard is filtered to include monitoring data for a specific application using the Monitoring Policy tag, and the locations monitoring the application are summarized at the state or province level. The dashboard is configured to include both network and web path performance data and to sort locations by performance violation time, with the worst-performing locations listed at the top of the dashboard.

The following example of a Network Violation Summary dashboard summarizes network performance violation durations for various cloud-hosted applications. In this example, the dashboard is filtered to include monitoring data tagged with the Cloud Vendor custom tag. The Cloud Vendor tag was assigned to each monitoring policy created for monitoring cloud connectivity. The dashboard automatically visualizes groups with the longest violation duration in the upper left corner of the dashboard. Groups with no violations are hidden in this example. 

For more information about configuring AppNeta dashboards and reports, refer to the following resources:

• AppNeta: Configure Dashboards and Reports (Online Course)
• Dashboards (AppNeta Documentation)

Note: If AppNeta is integrated with DX NetOps, consider creating a custom DX NetOps dashboard including cloud monitoring data from AppNeta alongside relevant managed network performance data from DX NetOps. For more information on DX NetOps dashboards, refer to the following online course: DX NetOps 23.3.x: Performance Dashboards and Reports 200.

Add AppNeta to Existing Network Operations Procedures

Consider how to handle performance events detected by AppNeta. Options for sending performance or event data from AppNeta to other systems include:

• Integrate AppNeta with DX NetOps to send end-to-end network performance data from AppNeta to DX NetOps for baselining, alarm generation, and so on.
• Configure event integration with the AppNeta API observer endpoint to send events of a specified type to a server of your choice for processing, aggregation, and distribution as appropriate for the business.
• Configure email notifications to send email notifications to a list of recipients about events related to all paths or a specified list of paths.
• Configure SNMP notifications to send SNMP traps to an NMS host upon network path, web path, or Monitoring Point events.

For more information on how to configure notifications about AppNeta events, refer to the following resources:

• Operationalize AppNeta Alerts and Notifications (Online Course)
• Alerts and Notifications – Best Practices (AppNeta Documentation)
• Notifications (AppNeta Documentation)
• Event Integration (AppNeta Documentation)

For runbooks with general steps to investigate violation events with AppNeta, refer to the following resources:

• Investigating Violation Events (AppNeta Documentation)
• AppNeta: Configure Network Monitoring (Online Course; refer to the Course Introduction lesson to download a customizable runbook template)

To learn how to integrate AppNeta with DX NetOps, baseline performance in DX NetOps, and raise alarms based on deviations from baseline performance, refer to the following resources:

• DX NetOps 23.3.x: Integrate AppNeta 200 (Online Course)
• Baseline Calculations (DX NetOps Documentation)
• DX NetOps 23.3.x: Configure Performance Thresholds and Notifications 200 (Online Course)

AppNeta monitoring helps identify and isolate issues within and between the various network environments transited by production application traffic. When issues occur, AppNeta helps network operations teams quickly identify where the issue was introduced, reducing the uncertainty of who is responsible for resolution, and gather supporting evidence for external service providers.

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 term we'll use for 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 Internet service provider (ISP), the cloud edge, cloud backbone, the application environment, or the application itself.

A typical approach to investigating degraded performance starts with understanding how widespread an issue is. Sometimes this is all that is needed to isolate the error domain.

1. How widespread is the problem?
   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 targeting the same application are experiencing the same issue, the problem is likely with the target application, its network infrastructure, or some network infrastructure shared by all paths.
2. What are the symptoms for impacted paths? 
   Review the metric timeline charts for patterns and anomalies 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.
3. What infrastructure do the impacted paths have in common? 
   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. 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.
4. Next Steps:
   1. If the issue is introduced at a WAN hop within a provider network, correlate results with additional diagnostics before contacting the provider.
   2. 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.
   3. If an issue is suspected to be introduced at a LAN hop, investigate the device itself, the preceding device, and the infrastructure in between.
   4. 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.
   5. 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)

Understand the Metrics

Active network monitoring generates the following performance metrics displayed as charts in the Delivery area of AppNeta. Network performance 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.

Primary network performance metrics:

• Connectivity indicates whether the Monitoring Point can connect to the target. Connection loss occurs with 100% packet loss.
• Packet loss is simply 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 as calculated by the TruPath technology. Available Capacity is the portion of total capacity that is available for use.
  • When reviewing results, keep in mind that for container-based Monitoring Points, 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.

Web synthetic transactions generate performance metrics displayed as charts in the Experience area of AppNeta, including the following metrics:

• 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.
• HTTP Server Response Time metrics for the first non-redirected request include:
  • Redirect: The time for all requests that are redirected before the request is made to the final server. This time includes all aspects of a request that results in a 302 redirect, including the time taken for DNS lookups, for a TCP or SSL connection to be established, the request itself, and the response time. This metric will have a value of 0 if the initial request is not redirected.
  • DNS Lookup: The time taken to resolve the IP address of the target domain. This metric may have a value of 0 if the IP address has already been resolved and is cached in the operating system.
  • TCP Connection: The time taken to establish the TCP connection to the target. It is measured from the moment the initial synchronize sequence numbers (SYN) packet is sent to start a TCP connection, to the point where the acknowledgment (SYN/ACK) packet is received in response.
  • SSL Connection: The time taken to complete the SSL handshake process between a client and a server.
  • Request Wait: The time interval from when an HTTP request is sent by the client until the first byte of the response is received from the target.
  • Download: The time taken to download the entire content of an HTTP response from the target.
  • Response Time: The time between when the Monitoring Point begins DNS resolution and when the Monitoring Point receives the last byte of the response to the first non-redirected request.
  • Status Code: The HTTP status codes received as part of the response from the target.
  • Response: Shows whether or not the expected response was received. For aggregated data, it shows the percentage of expected responses received. (HTTP workflow only)

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.
• Retransmits % is the percentage of TCP packets that are retransmitted due to errors or packet loss.

To learn more about performance metrics generated by AppNeta, refer to the following documentation articles:

• Network Path Performance (AppNeta Documentation)
• Web Path Details (AppNeta Documentation)
• Usage Chart Data (AppNeta Documentation)

Broadcom can address the challenge of validating cloud connections by providing active monitoring of external networks, web synthetic monitoring of cloud-hosted web applications, and deep packet inspection to identify third-party web applications adopted by the organization. With the Broadcom solution, network operations teams gain the visibility required to validate 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.