4 Strategies for Ensuring Application Performance Across Hybrid Networks

Jay Botelho

As network transformation initiatives like SD-WAN, edge computing and public/private clouds are adopted at increasing rates, hybrid networks are quickly becoming the new normal for IT and NetOps professionals. According to a recent survey from Sirkin Research, 35% of enterprise networking and IT professionals struggle to access visibility into performance across all fabrics of the network. Without visibility into these hybrid network environments, NetOps are unable to troubleshoot the business-critical applications every organization relies on today.

Here are four ways IT and NetOps teams can gain better visibility into complex, hybrid networks:

Wireless Packet Capture

As personal devices and IoT becomes more common in the workplace, wireless issues are only going to increase. If you can't track performance across the entire end-to-end network, then you can't truly ensure end-user performance. Monitoring all wireless traffic isn't realistic for most organizations because it requires too many capture points spread throughout the wireless network to be viable.

A better approach is to supplement flow data and packet data from wired network segments with ad-hoc wireless packet capture for issues that can't be resolved based on the flow data alone. Sending a network engineer on-site to conduct a packet capture is one option, but it's extremely expensive. It's possible, with the right setup, to use a nearby AP as a sensor to sniff wireless traffic between a client and an access point for a short time. This isn't a common capability today, but I believe organizations need to start designing this into their networks to gain better visibility into the wireless network, and a better understanding of the hybrid network overall.

Packet Analysis for Complex Issues

There's a common adage in networking that says 80% of issues can be resolved using flow data and that the 20% that can't will require packet data. Why? Because many of these more complex problems have tons of potential causes.

For example, an end user complains that an application is running slowly. Maybe it's the network or possibly a QoS issue with the new SD-WAN that's been being rolled out. But the application could also be at fault; perhaps it wasn't perfectly designed and it's letting multiple users try to change an element of its database simultaneously, resulting in longer processing times. Without quick access to packet data, these difficult application issues can't be resolved successfully.

There are several free packet capture and analysis tools available, but larger organizations with complex networks will likely need to invest in a packet capture and analysis product that offers features like network mapping, customizable, pre-built reports, and visualizations to simplify this process and speed up troubleshooting.

Deep Packet Inspection as a Supplement to Flow Data

NetFlow and similar types of network telemetry data all have limitations. For example, when using NetFlow or IPFIX to troubleshoot VoIP calls, this data includes IP addresses, but not phone numbers. Customers calling to complain about VoIP will know their number, but probably not their IP address, so IT has no way to looking up the flows they need to hunt down the problem! With additional applications that offer deep packet inspection (DPI) it's possible to "add" new data points, such as the phone number of a VoIP call, to flow data. TCP retries is another useful data point that could be added. By adding selective data points to NetFlow, flow-based monitoring tools become much more useful for new situations that hybrid networks create.

Gather Data Necessary for SD-WAN Planning, Verification and Management

When transitioning to SD-WAN, enterprises need visibility into their existing network devices to determine the baseline of existing application performance, but also the patterns and usage of applications to plan out which sites and application policies need to be developed.

Additionally, planning has to be done on how the SD-WAN edge device will interface to the existing infrastructure, if there will be hybrid WAN where some traffic will remain on the existing WAN infrastructure to plan the SD-WAN roll out.

They will also need real-time visibility into the new SD-WAN once it's running to verify that it's performing as expected and the performance data can be gotten from the SD-WAN system but may also require more granular visibility from a packet analytics to augment.

Over time, every NetOps team managing an SD-WAN will need holistic visibility of across the existing network infrastructure that feeds into the SD-WAN fabric to optimize, but also for troubleshooting where understanding the application path end-to-end in order to segment if the problem is in the SD-WAN or carrier or another portion of the network entirely. By monitoring the entire network through all three of these phase, IT can ensure a new SD-WAN project doesn't negatively affect business-critical applications.

As you can see, establishing end-to-end visibility and ensuring effective troubleshooting for complex, hybrid networks isn't easy. Nonetheless, it's essential for IT and NetOps to have these capabilities to support major network transformation projects. Using the techniques outlined above, IT and NetOps teams will be well-positioned to respond to application issues quickly and effectively, no matter what fabric of the network they originate from.

Related Links

Hot Topics

The Latest

Three Strikes and They're Gone: Why Proactive Operations is Now a Customer Retention Strategy

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

When the Database Is the Problem, Is APM Enough?

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

From Cleanup to Prevention: The Future of Cloud-Native Cost Optimization

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

The Real Enterprise AI Risk Isn't Hallucinations

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

4 Strategies for Ensuring Application Performance Across Hybrid Networks

Jay Botelho

As network transformation initiatives like SD-WAN, edge computing and public/private clouds are adopted at increasing rates, hybrid networks are quickly becoming the new normal for IT and NetOps professionals. According to a recent survey from Sirkin Research, 35% of enterprise networking and IT professionals struggle to access visibility into performance across all fabrics of the network. Without visibility into these hybrid network environments, NetOps are unable to troubleshoot the business-critical applications every organization relies on today.

Here are four ways IT and NetOps teams can gain better visibility into complex, hybrid networks:

Wireless Packet Capture

As personal devices and IoT becomes more common in the workplace, wireless issues are only going to increase. If you can't track performance across the entire end-to-end network, then you can't truly ensure end-user performance. Monitoring all wireless traffic isn't realistic for most organizations because it requires too many capture points spread throughout the wireless network to be viable.

A better approach is to supplement flow data and packet data from wired network segments with ad-hoc wireless packet capture for issues that can't be resolved based on the flow data alone. Sending a network engineer on-site to conduct a packet capture is one option, but it's extremely expensive. It's possible, with the right setup, to use a nearby AP as a sensor to sniff wireless traffic between a client and an access point for a short time. This isn't a common capability today, but I believe organizations need to start designing this into their networks to gain better visibility into the wireless network, and a better understanding of the hybrid network overall.

Packet Analysis for Complex Issues

There's a common adage in networking that says 80% of issues can be resolved using flow data and that the 20% that can't will require packet data. Why? Because many of these more complex problems have tons of potential causes.

For example, an end user complains that an application is running slowly. Maybe it's the network or possibly a QoS issue with the new SD-WAN that's been being rolled out. But the application could also be at fault; perhaps it wasn't perfectly designed and it's letting multiple users try to change an element of its database simultaneously, resulting in longer processing times. Without quick access to packet data, these difficult application issues can't be resolved successfully.

There are several free packet capture and analysis tools available, but larger organizations with complex networks will likely need to invest in a packet capture and analysis product that offers features like network mapping, customizable, pre-built reports, and visualizations to simplify this process and speed up troubleshooting.

Deep Packet Inspection as a Supplement to Flow Data

NetFlow and similar types of network telemetry data all have limitations. For example, when using NetFlow or IPFIX to troubleshoot VoIP calls, this data includes IP addresses, but not phone numbers. Customers calling to complain about VoIP will know their number, but probably not their IP address, so IT has no way to looking up the flows they need to hunt down the problem! With additional applications that offer deep packet inspection (DPI) it's possible to "add" new data points, such as the phone number of a VoIP call, to flow data. TCP retries is another useful data point that could be added. By adding selective data points to NetFlow, flow-based monitoring tools become much more useful for new situations that hybrid networks create.

Gather Data Necessary for SD-WAN Planning, Verification and Management

When transitioning to SD-WAN, enterprises need visibility into their existing network devices to determine the baseline of existing application performance, but also the patterns and usage of applications to plan out which sites and application policies need to be developed.

Additionally, planning has to be done on how the SD-WAN edge device will interface to the existing infrastructure, if there will be hybrid WAN where some traffic will remain on the existing WAN infrastructure to plan the SD-WAN roll out.

They will also need real-time visibility into the new SD-WAN once it's running to verify that it's performing as expected and the performance data can be gotten from the SD-WAN system but may also require more granular visibility from a packet analytics to augment.

Over time, every NetOps team managing an SD-WAN will need holistic visibility of across the existing network infrastructure that feeds into the SD-WAN fabric to optimize, but also for troubleshooting where understanding the application path end-to-end in order to segment if the problem is in the SD-WAN or carrier or another portion of the network entirely. By monitoring the entire network through all three of these phase, IT can ensure a new SD-WAN project doesn't negatively affect business-critical applications.

As you can see, establishing end-to-end visibility and ensuring effective troubleshooting for complex, hybrid networks isn't easy. Nonetheless, it's essential for IT and NetOps to have these capabilities to support major network transformation projects. Using the techniques outlined above, IT and NetOps teams will be well-positioned to respond to application issues quickly and effectively, no matter what fabric of the network they originate from.

Related Links

Hot Topics

The Latest

Three Strikes and They're Gone: Why Proactive Operations is Now a Customer Retention Strategy

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

When the Database Is the Problem, Is APM Enough?

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

From Cleanup to Prevention: The Future of Cloud-Native Cost Optimization

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

The Real Enterprise AI Risk Isn't Hallucinations

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...