wan monitoring

WAN Monitoring

 

 

WAN Monitoring

By examining performance parameters, SD-WAN can classify, select, and switch traffic paths across your WAN. Now we have reactive rerouting and load balancing that will help improve network availability and performance. But to gain the benefits, one needs to consider operationalizing SD WAN visibility and whether or not to incorporate WAN monitoring tools for performance monitoring. For SD WAN monitoring, we must consider overlay (application visibility), underlay, and security visibility. For readers that are new to SD WAN monitoring, consider first reading the SD-WAN tutorial.

 



WAN Monitoring Tools

Key WAN Monitoring Discussion points:


  • Monitoring the SD WAN overlay and underlay.

  • Challenges to traditional WAN and the need for performance-based monitoring.

  • The need for SD WAN visibility.

  • How to perform SD WAN monitoring.

  • The challenges with encrypted traffic.

 

WAN Monitoring: WAN Monitoring Tools

    • Stage1: Application SD WAN Visibility

For SD-WAN to make the correct provisioning and routing control, visibility into application performance is required. Therefore, SD-WAN enforces the right QoS policy based on how an application is tagged. To determine what prioritization they need within QoS policies, you need monitoring tools to deliver insights on various parameters, such as application response times, network saturation, and bandwidth usage. You control the SD WAN overlay.

 

    • Stage2: Underlay SD WAN Visibility

Then it would help if you considered underlay visibility. I have found a gap in visibility between the tunnels riding over the network and the underlying transport network. SD WAN monitoring leans heavily on the virtual overlay. For WAN underlay monitoring, we must consider the network is a hardware-dependent physical network responsible for delivering packets. The underlay network can be the Internet, MPLS, satellite, Ethernet, broadband, or any transport mode. A service provider controls the underlay.

 

    • Stage3: Security SD WAN Visibility

Finally, and more importantly, security visibility and implementing network security. Here we need to cover the underlay and overlay of the SD-WAN network, considering devices, domains, IPs, users, and connections throughout the network. Often, malicious traffic can hide in encrypted packets and appear like normal traffic. For example, crypto mining. The traditional deep packet inspection (DPI) engines have proven to fall short here.

We must look at deep packet dynamics (DPD) and encrypted traffic analysis (ETA). Combined with artificial intelligence (AI) can fingerprint the metadata of the packet and use behavioural heuristics to see through encrypted traffic for threats without the negative aspects of decryption.

SD WAN monitoring
Diagram: SD WAN monitoring.

 

The traditional WAN

So, within your data center topology, the old approach to the WAN did not scale very well. First, there is cost and complexity, as well as the length of installation times. The network is built on expensive proprietary equipment that is difficult to manage, and then we have expensive transport costs that lack agility. Not to mention the complexity of segmentation with complex BGP configurations and tagging mechanisms used to control traffic over the WAN. There are also limitations to forwarding routing protocols with convergence routing. It’s not that they redesigned badly, it’s just a different solution needed over the WAN.

 

Distributed control plane

There was also a distributed control plane where every node had to be considered and managed. And if you had multi-vendor equipment at the WAN edge, different teams could have managed this in different locations. 

 

  • A key point: No WAN control

As soon as you want to upgrade, you could look at 8 – 12 weeks. With the legacy network, all the change control is with the service provider. I have found this to be a major challenge. There was also a major architectural change where we had a continuous flow of applications moving to the cloud. Therefore routing via the main data center where the security stack was located was not as important. Instead, it was much better to route the application directly into the cloud in the first cloud world. 

 

WAN monitoring tools
Diagram: The traditional WAN.

 

WAN Modernization

The need for new WAN monitoring tools

The initial use case of SD-WAN and other types of routing control platforms was to increase the use of Internet-based links and reduce the high costs of MPLS. However, when you start deploying SD-WAN, many immediately see the benefits. So as you deploy SD-WAN, you are getting 5 x 9’s with dual Internal links, and MPLS at the WAN edge of the network was something you could move away from. Especially for remote branches.

There was also the need for transport independence and to avoid the associated long lead times from deploying a new MPLS circuit. With SD-WAN, you create SD-WAN overlay tunnels over the top of whatever ISP and mix and match how you see fit.

 

Security and performance consistency

With SD-WAN, we now have an SD-WAN controller in a central location. And this brings with it a lot of consistency to security and performance. In addition, we have a consistent policy pushed through the network regardless of network locations.

 

SD WAN monitoring and performance-based application delivery

SD WAN monitoring is application-focused; we now have performance-based application delivery and routing. This type of design was possible with traditional WANs but was hard and complex to manage daily. It’s a better use of capital and business outcomes.

So we can use the less expensive connection without dropping any packets. There is no longer leverage in the design of having something as a backup. Now with SD WAN monitoring, you can find several virtual paths and routes around all types of failures. While enabling dropped packet test.

Now applications can be routed intelligently and using performance and optimal Layer 3 forwarding as a key driver can make WAN monitoring more complete, and it’s not just about making a decision based on up or down. The WAN monitoring tools must understand the concept of brownouts, maybe high latency or high jitter. That circuit is not down, but the application will route around the issue with intelligent WAN segmentation.

Performance-based application delivery

 

WAN monitoring tools: Troubleshoot brownouts

    • Detecting brownouts

Traditional monitoring solutions focus on device health and cannot detect complex network service issues such as brownouts. Therefore, it is critical to evaluate solutions that are easy to deploy and use to simulate end-user behaviour from the right locations for the relevant network services. Most of the reported brownouts’ reported causes require active monitoring to detect. Five of the top six reasons brownouts occur can only be detected with active monitoring: congestion, buffer full drops, missing or misconfigured QoS, problematic in-line devices, external network issues, and poor planning or design of Wi-Fi.

 

  • WAN monitoring tools. Understanding geo policy and tunnel performance

Troubleshooting a brownout is not easy, especially when you need to understand geo policy and tunnel performance. What applications and users are affected, and how do you tie back to the SD-WAN tunnels? Brownouts are different from blackouts as application performance is affected.

 

SD WAN Monitoring

So, we have clear advantages to introducing SD-WAN; managers and engineers must consider how they operationalize this new technology. Designing and installing is one aspect, but how will SD-WAN be monitored and maintained? Where do SD WAN monitoring and security fit into the picture? While most SD-WAN solutions provide native visibility into network and application performance, this type of visibility isn’t enough. I would recommend that you supplement native SD WAN visibility with third-party monitoring tools. SD-WAN vendors are not monitoring or observability experts. So, it is like a networking vendor jumping into the security space.

 

The issues of encrypted traffic and DPI

Traditionally we are looking for anomalies against unencrypted traffic, and you can inspect the payload and use deep packet inspection (DPI). Nowadays, there is more than a simple UDP scan. Still, we have bad actors appearing in encrypted traffic and can mask and hide activity among the normal traffic. This means some DPI vendors are ineffective and can’t see the payloads. Without appropriate visibility, the appliance will send a lot of alerts that are false positives.

 

Deep packet inspection technology

Deep packet inspection technology has been around for decades. It utilizes traffic mirroring to analyze the payload of each packet passing through a mirrored sensor or core device and is the traditional approach to network detection and response (NDR). Most modern cyberattacks heavily utilize encryption in their attack routines, including ransomware, lateral movement, and Advanced Persistent Threats (APT). However, since DPI was not built to analyze encrypted traffic, this limitation can create a security gap.

 

Deep packet inspection technology
Diagram: Deep packet inspection technology.

 

So, the legacy visibility solutions only work for unencrypted or clear text protocols such as HTTP. In addition, DPI requires a decryption proxy, or middlebox, to be deployed for encrypted traffic. Middleboxes can be costly, introduce performance bottlenecks and create additional security concerns. Previously, security practitioners would apply DPI techniques to unencrypted HTTP traffic to identify critical session details such as browser user agent, presence of a network cookie, or parameters of an HTTP POST. However, as web traffic moves from HTTP to encrypted HTTPS, network defenders are losing visibility into those details.

 

WAN Monitoring tools: Good Visibility and Security Posture

Introducing telemetry

We need to effectively leverage your network monitoring infrastructure for better security and application performance monitoring to be more effective, especially in the world of SD-WAN. However, this comes with challenges with collecting and storing common telemetry and the ability to view encrypted traffic. The network teams spend a lot of time on security incidents, and sometimes the security team has to look after network issues. So both of these teams work together. For example, packet analysis needs to be leveraged by both teams, also flow control and other telemetry data need to be analyzed by the two teams.

 

The role of a common platform

So, it’s good that other network and security teams can work off a common platform and common telemetry. This is where a network monitoring system can be used while plugging into your SD-WAN controller to help you operationalize your SD-WAN environments and gain better SD WAN monitoring and SD WAN visibility. There are a lot of application performance problems arising from security issues. So, you need to know your applications and examine encrypted traffic without decrypting.

 

WAN Monitoring tools for network performance monitoring and diagnostics

We have Flow, SNMP, and API for network performance monitoring and diagnostics. We have encrypted traffic analysis and machine learning (ML) for threat and risk identification for security teams. This will help you reduce complexity and will increase efficiency and emerge. So we have many things, such as secure access service edge (SASE) SD-WAN, and the network and security teams are under pressure to respond better.

WAN monitoring tools
Diagram: Network performance monitoring.

 

Merging of network and security

The market is moving towards the merging of network and security teams. We see this with cloud, SD-WAN, and also SASE Definition with Zero Trust SASE. So with the cloud, for example, we have a lot of security built into the fabric. With VPC, we have security group policies built into the fabric. SD-WAN, we have segmentation end to end commonly based on an overlay technology. That can also be terminal on a virtual private cloud (VPC).  

So we need to improve monitoring, investigation capabilities, and detection. This is where the zero trust architecture and technologies such as single packet authorization can help you monitor and improve detection with the deduction and response solutions. In addition, we must look at network logging and encrypted traffic analyses to improve investigation capabilities. Regarding investment, we have traditionally looked at packets and logs but have SNMP, NetFlow, and API. So there are a lot of telemetries that can be used for security, originally viewed as performance monitoring. Now it has been managed as security and cybersecurity use cases.

 

SD WAN Monitoring: The Need for a Baseline

For effective SD WAN monitoring, you first need to understand and perform baseline engineering on the current network to have smooth SD-WAN rollouts. Also, when it comes to policy. It is no longer just a primary backup link and a backup design. Now we have intelligence application profiling. So everything is based on performance parameters such as loss, latency, and jitter. So, before you start any of this, you will need to have good visibility and observability.

You need to understand your network and get a baseline for policy creation, and getting the right visibility is the first step in planning the SD-WAN rollout process. For this, a good understanding of new practices such as Observability and the ability to detect unknown problems that traditional monitoring cannot detect: Observability vs Monitoring.

 

WAN monitoring tools and a network monitoring platform

So for traditional networks, they will be SNMP, Flow data, and a lot of multi-vendor equipment. So you need to monitor and understand how applications are used across the environment, and not everyone uses the same vendor for everything. For this, you need to have a network monitoring platform, which can easily be scaled with the ability to perform baseline and full reporting and take into all types of multi-vendor networks. To deploy SD-WAN, you need network monitoring tools that need to be able to collect multiple telemetries, be multi-vendor, and have the ability to scale. 

 

Variety of telemetry

Consuming packets, decoding this to IPFIX, and bringing API-based data are critical. So you need to be able to consume all of this data. When you are rolling out SD WAN monitoring is key. So you first need to baseline to see what is normal. This will let you know if SD-WAN will make a difference and what type of difference it will make at each of your sites. So with SD-WAN, you can deploy application-aware policies that are site-specific or region-specific, but you first need a baseline and this will tell you what policies you need at each site.

 

QoS visibility

With a network monitoring platform, you can get visibility into QoS. This can be done by taking advanced flow technologies to see the marking. For example, in the case of VOIP, the traffic should be marked as expedited forwarding (EF). Also, we need to be visible in the queueing, and shaping is also critical. You can assume that the user phones are automatically marketing the traffic as EF Still, a misconfiguration at one of the switches in the data path could be remarking this to best efforts. Once you have all of this data, you need to collect and store all of this. The monitoring platform needs to be able to scale, especially for global customers, and to be able to collect information for large environments. Flow can be challenging. What if you have 100,000 flow records per second? 

 

SD WAN Monitoring

 

SD WAN Monitoring: WAN Capacity Planning

When you have a baseline, you need to understand WAN capacity planning for each service provider. This will allow you to re-evaluate your service provider’s needs. In the long run, this will save costs. In addition, we can use WAN capacity planning to let you know each site is reaching its limit. WAN capacity planning is not just about reports. Now we are looking extensively at the data to draw value. Here we can see the introduction of artificial intelligence for IT operations (AIOps) and machine learning to help predict WAN capacity and future problems. This will give you a long-term predicate when making decisions about WAN bandwidth and service provider needs.

 

Get to know your sites and POC

For SD WAN monitoring, you also need to know the sites. A network monitoring platform will allow you to look at sites and understand bandwidth usage across your service providers. This will allow you to identify what your critical sites are. You will want to have various sites and a cross-section of other sites that may be on satellite connection or LTE, especially with retail. So look for varying sites, and learn about problematic sites where your users have problems with applications that are good candidates for proof of concepts. 

 

Mix all site types of a POC

Your network performance management software will give you visibility into what sites to include in your proof of concept. So this platform will tell you what sites are critical but also what sites are problematic in terms of performance and would be a good mix for a proof of concept. When you get problematic sites in the mix, you will immediately see the return on investment (ROI) for SD-WAN. So uptime will increase, and you will see this immediately. But for all of this to be in effect, you first need a baseline.

 

Identity your applications: Everything is port 80

So, we have latency, jitter, and loss. Understanding when loss happens is obvious. But with certain applications, with 1 – 5 % packet loss, there may not be a failover, which can negatively affect the applications. Also, many don’t know what applications are running. What about people connecting to the VPN with no split tunnel and then streaming movies?  We have IP and ports to identity applications running on your network, but everything is port 80 now. So you need to be able to consume different types of telemetry from the network to understand your applications fully.

 

The issues with deep packet inspection

So what about the homegrown applications that a DPI engine might not know about? Many DPI vendors will have trouble identifying these. So it would help if you had the network monitoring platform to categorize and identify applications based on several parameters that DPI can’t. So a DPI engine can classify many applications but can’t do everything. A network monitoring platform can create a custom application, let’s say, based on an IP address, port number, URL, and URI.  

 

Connecting to the SD-WAN Controller

The traditional approach is to talk to each device individually. However, in the SDN world, we need the network monitoring platform to connect the controller as opposed to each device. So if you can connect to the controller, we have a single point of truth; this is where all the information can be gleaned from. So here, it can form API connections to the SD-WAN controller to form a holistic view of all devices at the WAN edge. So for SD-WAN monitoring, we need to collect different types of information from the SD-WAN controller. 

 

SD-WAN API connectivity 

For example, some SD-WAN vendors give metrics via SNMP, Netflow, and API. So it would help if you collected all different types of telemetry data. This will allow you to identify network semantics, where the sites are, the WAN interface, service provider transports, and logical constructs such as the IP address allocations. Multi-telemetry will help you drive workflows, geo-location mappings, performance visibility, and detailed reporting. And all of this can be brought together in one platform. So we are bringing in all information about the environment, which is impossible with a Netflow v5 packet.

 

Requirements for WAN monitoring tools

SDWAN Monitoring
Diagram: Network monitoring platform.

 

  • Know application routing

So the network monitoring platform needs to know the application policy and routing. It needs to know when there are error threshold events as applications are routed based on intelligence policy. Once the policy is understood, you need to know how the overlay application is routed. With SD-WAN, we have per segment per topology so that we can do this based on VRF or service VPN. We can have full mesh or regions with hub and spoke. Per segment topology verification is also needed to know that things are running correctly. So to understand the application policy, what the traffic looks like, and to be able to verify brownouts. 

 

  • SD-WAN multi-vendor

Due to mergers or acquisitions, you may have an environment with multiple vendors affecting SD WAN monitoring. Each vendor has its secret source too. So the network monitoring platform needs to bring the gap and monitor both sides. There may even be different business units. So how do you leverage common infrastructure to achieve this? We first need to leverage telemetry for monitoring and analysts. This is important as if you are putting in info packet analysis; this should be leveraged by both security and network teams, reducing tool sprawl.

 

  • Overcome the common telemetry challenges

So trying common telemetry does come with its challenge, and every type of telemetry has its one type of challenge. Firstly, Big Data: This is a lot of volume in terms of storage size. The speed and planning of where you will do all the packet analysis. Next, we have the collection and performance side of things. How do we collect all of this data? So from a Flow perspective, you can get flow from different devices. So how do you collect from all the edge devices and then bring them into a central location?

Finally, we have cost and complexity challenges. You may have different products for different solutions. We have an NPM for network performance monitoring, an NDR, and packet captures. So the different products work on the same telemetry. Some often start with packet capture and move to an NPM or NDR solution.

 

Encrypted Traffic and SD WAN Monitoring

  • SD WAN visibility with SD WAN encryption

With SD-WAN, everything is encrypted across public transport. So, most SD-WAN vendors can meter traffic on the LAN side before they enter the SD-WAN tunnels, but many applications are encrypted end to end. So you need to identify even keystrokes through encrypted sessions. So how can you get the SD WAN visibility that is fully encrypted? By 2025 all traffic will be encrypted. Here we can use a network monitoring platform to identify and analyze threats among encrypted traffic.

 

  • Deep packet dynamics

So you should be able to track and classify with what’s known as deep packet dynamic and could include, for example, byte distributions, sequence of packets, time, jitter, RTT, and interflow stats. Now we can push this into machine learning to identify applications and any anomalies associated with encryption. This can identify threats in encrypted traffic without decrypting the traffic.

 

  • “No impediment to latency or violation of privacy”

Deep packet dynamics improve encrypted traffic visibility while remaining scalable and causing no impediment to latency or violation of privacy. Now we have a malware detection method and cryptographic assessment of secured network sessions, which does not rely on decryption.  All of this can be done without having the keys or decrypting the traffic. Managing the session key for decryption is complex and can be costly computationally. And often incomplete. They only often support session key forwarding on windows or Linux or not on macOS, never mind the world of IoT.

sd wan visibility
Diagram: Encrypted traffic analytics.

 

Encrypted traffic analytics

Cisco’s Encrypted Traffic Analytics (ETA) uses software named Stealthwatch to compare the metadata of benign and malicious network packets to identify malicious traffic, even if it’s encrypted, providing insight into threats in encrypted traffic without decryption. In addition, recent work on Cisco’s TLS fingerprinting can provide fine-grained details about the enterprise network’s applications, operating systems, and processes.

The issue with packet analysis is that everything is encrypted, especially with TLS1.3. The monitoring of the traffic and the WAN edge is encrypted. So how do you encrypt all of this, and how to store all of this? So how do you encrypt traffic analysis? If you are decrypting traffic, it can create an exploit and potential attack surface, and you also don’t want to decrypt everything.

 

sd wan monitoring

Matt Conran: The Visual Age
Latest posts by Matt Conran: The Visual Age (see all)

Comments are closed.