LEARNING PATH

Validate Cloud Connections

Learn how Network Observability by Broadcom helps network operations teams validate cloud connections.

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 to validate cloud connections.

Courses

5 chapters

to review

15 minutes

estimated completion

Validate Cloud Connections

Course sections

Use Case Overview

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 in order to validate cloud connections that support business-critical apps and services. To do this, network operations teams need to invest in 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.

For more information, see the white paper: Validating Cloud Connections: 3 Keys to Success for Network Operations Teams.

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.

The Network Observability by Broadcom Approach

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 (Delivery 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 (Experience monitoring) 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.

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 to defined end hosts or targets, which can be any endpoint that can respond to an ICMP-based ping or can send back a 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.

Implement Network Observability to Validate Cloud Connections

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

Create a monitoring plan.
Deploy Monitoring Points at the locations from which you want to monitor cloud connectivity and within the cloud environments you control.
Create monitoring policies to define the applications and networks to monitor.

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

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).

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.
Set Up Network and Web Application 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.

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.

Optionally, add web monitoring to monitor each cloud-hosted web application of interest to you. Add an HTTP workflow to monitor connectivity to critical web applications, from supported Monitoring Points to RESTful API endpoints. Alternatively, add 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 Validate Cloud Connections

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. 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 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.
  2. If an issue is suspected to be introduced at a LAN hop, investigate the device itself, the preceding device, and the infrastructure in between.
  3. 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.
  4. To determine if a network event impacted the user experience of the application, review layer 7 web performance metrics for the related web paths.
Understand the Metrics
Network performance metrics include:
- 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.
- 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 include:
- 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 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

Broadcom Helps Validate Cloud Connections

Broadcom can address the challenge of validating cloud connections by providing active monitoring of external networks and web monitoring of cloud-hosted web applications. 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.