Smarter management of the last mile of SD-WAN

To provide global SD-WAN network is much different from provide local network. The local network provides full control over the end-to-end design, enabling low latency and predictable connections.  Power outages and voltage shortages may still exist, but you can control and troubleshoot with appropriate knowledge.

But, through global SD-WAN, we can say, manage in /mile/backbone performance and manage the last mile is more challenging. Most SD-WAN vendors have no control over these two parts, which can affect application performance and service flexibility.

In particular, one problem that SD-WAN equipment vendors often overlook is managing the last mile. Providers are held accountable through multi-protocol label switching (MPLS), but no longer the case for SD-WANs. Getting the last mile right is a challenge for many global SD-WANs.

You have the responsibility to monitor all the last miles in the world, detecting problems and then work cooperate with local Internet Service Provider (ISP) in the region.There are new solutions emerging to address this issue.

Manage the middle mile

As you know, The Internet connection consists of three components: from the customer site to the ISP site (first mile), the last mile in the middle mile (called the core of internet),and the location of the last mile is from the target ISP to the customer’s premises.

The middle mile includes autonomy and the Internet, all of which have different business objectives.  Traffic flows are combined with financial transactions and ISPs routing according to the economic routing packet. Unfortunately, other metrics that might be more appropriate for application performance are not considered.

This results in unreliable end-to-end connectivity. One day, your Internet traffic may take as few hops as possible, but the next day it may rebound globally. There’s nothing you can do. A more viable solution would be to privatize the middle inch mile. This provides strict latency, loss, and jitter metrics.

A global independent backbone helps to address these issues. Relying on Global cloud-based providers, such as Aryaka and Cato Networks, provide a global backbone. What’s more, Mode also provides a global backbone that can be used with any third-party SD-WAN device.

Enterprises access these backbones, and in many cases, it may be less than the client 20ms or so. Now you can enjoy the performance benefits of a predictable global backbone.

Manage the last mile

In my previous advisory role, I had to launch a global network in a short time. There was a link issue and I had to file an emergency ticket with my ISP in Hong Kong.

 The CEO’s deadline is tight and he wants to close the ticket that night, rather than focusing on low-level details.  I worked for 8 hours in London and Hong Kong. Let’s say it was a long night.

Whatever my frustrations are were, at least I know they have the responsibility to keep the last mile connected. I can help to some extent, but basically troubleshooting is not in my hands.

More websites – More ISPs

Each site needs one ISPs and managing the last mile can be a headache, even for the most patient people. Every ISP needs new relationships, languages, cultures, and processes.

According to the size and location of the ISP, I can assign someone to guide me through the process and act as a point of contact for future issues. Efficient network engineers need to build out-of-process shortcuts for each ISP. But what happens when the person leaves or the process changes?

It creates more work. The number of Internet service providers exacerbates all those work. Not to mention the skills in the process of creating.

The problem I saw in the last mile

I haven’t seen a solution to this problem yet. Operators and providers that monitor and manage the last mile are often limited by the capabilities of the edge device.

In most cases, this is the standard third layer devices uses simple measurements, such as Internet Control Message Protocol (ICMP) requests/responses. ICMP requests/responses are quite low in the stack. It misses a bunch of performance-related information that is useful for ensuring that your application works at the highest level.

When something starts to go wrong, they have little understanding of the link characteristics, such as link deceleration due to interface congestion. Many last-mile management providers focus on detecting only line failures, which can be inconsistent.

Operators and traditional last-mile management providers (e.g. Experio) are responsible for managing the line from the customer’s router to the ISP. They do not detect problems and lack visibility from ISP upstream connections.

Last mile management options

There are several ways to solve this problem.

Aryaka may be the first independent global backbone service to be introduced into last mile management. Their services monitor all traffic from the customer’s location through Aryaka tunnel to  Aryaka backbone.

Internet traffic is separated locally. However, this means that they only manage website-to-site traffic.  If an ISP suffers an outage or deceleration due to a routing or QoS issue that affects only the Internet, Aryaka will not detect it. In an era, cloud applications are critical to companies that bother me, to say the least.

Cato recently announced a New services, to overcome this gap. The Cato Intelligent Last-Mile Management (ILMM) service will address these issues. Cato manages from the client to the last mile of Cato PoP. Both types of traffic are tunneled back to Cato’s PoP and separated from there.

This compare to other SD-WAN vendors with splits at site level. Therefore, if you lower the Internet but do not reduce WAN traffic, it will not be detected.

The ability to simplify last mile management is a global significant advance in the SD-WAN deployment.For every network design, I’m trying to be as simple as possible while maintaining sufficient control and visibility.