Fuse.Cloud Private Networking over Carrier-provided MPLS and/or SD-WAN

Fuse.Cloud Private Networking over Carrier-provided MPLS and/or SD-WAN

MPLS: Carriers – such as AT&T, CenturyLink/L3, MetTel, etc. – provide Multi Protocol Label Switching (MPLS) network services to customers for dependable, prioritized, and private routing of their data and/or voice packets at an affordable price. With MPLS, your MPLS provider will be the only carrier passing your packets from location to location – no matter the distance between the two locations. And, with MPLS, when data is sent from one location to another, the route and priority for all packets will have already been decided before the data communication begins. So, for MPLS, each router basically acts as a switch, using small defined route labels attached to each packet, and does not have to ever use its much larger routing table to make decisions.

This sounds terrific, but when you start to apply this to today’s customers, there are a few variables that make this model more complicated and less attractive.

  1. With MPLS requiring you use only one carrier for your entire network, you’re highly dependent on your carrier’s backbone. So, once your packets are out of your local area, they have a predetermined route, restricted to and dependent on your one carrier’s network. So, if you have a good many hops between location A and B, your packets might be taking a complicated, inefficient, high-hop path back and forth. And, with more hops needed to communicate, this not only creates +120 ms latency paths, but there are more pieces of equipment and data lines that could fail, producing downtime.
  2. And, with MPLS, you have to work within the carrier’s MPLS network design for security and general network design compatibility. So, for many MPLS providers, introducing need for open Internet connectivity and/or encrypted tunnels, sometimes turns into pretty complicated add-on modifications with odd NAT associations, pre-defined/static “Internet hop-off” points, and not so well defined encryption rules. MPLS providers tell you the network they provide you is private and “for your eyes only,” but this is not exactly the case. Your MPLS network communications is actually less secure due to it’s: not encrypted, able to be openly captured by anything that is also on the MPLS carrier’s network, is always taking a predictable and normally predetermined route from point A to point B, and when your packets do reach the Internet from the MPLS provider’s “hop off,” you are normally dependent on security provided by the carrier and not by your own router/firewall. And, as for any data encrypting a company would like to apply over MPLS, if the MPLS provider is able to support encryption, most every time, that takes away the provider’s ability to prioritize the different types of packets.
  3. When MPLS was first introduced just before the Dot-Com Bust of 2001-2002, it was marketed as a way to have prioritized, private, and dependable networking between locations, which was in high demand at that time. There was questioning of Internet security and digital private line prices were increasing, so MPLS providers were able to price their MPLS far above Dedicated Internet Access (DIA) line prices. However, nearly 20 years later, leading carriers and Managed Service Provider (MSP) resellers are providing low priced high-capacity DIA you can easily connect to highly respected, affordable, and secure routing equipment, so you have a fast and secure path for prioritized communicating from location to location, and also have all your packet communications: encrypted, redundantly carried, using dynamic adaptable cross-carrier packet routes, secured by your MSP’s or your own very capable firewall, and affordable.

MPLS provides prioritized, private to a single carrier, un-encrypted communications, that are only path predictable locally, so if you need more than this, we strongly advise against using MPLS.

SD-WAN: Many of the same carriers that offer MPLS, also provide Software-Defined Wide Area Networking (SD-WAN) services – such as CenturyLink/L3, AT&T, MetTel, etc. But, there are others selling SD-WAN who are not your typical communications service vendors, such as VMWare, Citrix, and Oracle. Then, there’s Cisco Meraki, which is a combination of Cisco, the largest and most successful network equipment/services provider and Meraki, a leader in cloud controlled WiFi, routing, security, and SD-WAN.

Software-Defined Wide Area Networking (SD-WAN) network services are advertised to customers with all benefits of MPLS, but also for adding packet encryption, the use of cross-carrier DIA lines, and better defined routes to the Internet that have stronger security and monitoring.

This sounds like MPLS customers can step up to SD-WAN, making use of their existing network resources, reducing network complexity, and stepping into the future of network communications. But, with respecting most company’s business requirements, when you lay out SD-WAN for a modern-day company, there are a few variables that make the SD-WAN model more complicated and less attractive, with the three things SD-WAN promised turning out to be not so true.

  1. Most companies discover their chosen SD-WAN platform will not work with their current WAN routing equipment, and will require most all the company’s routing equipment to be replaced. Also, when a carrier builds and deploys an SD-WAN solution for you, they normally want to own all involved netblocks – which most times ends up with the provider recommending you use only one carrier for all the involved DIA and/or MPLS lines used by the SD-WAN routing platform. And, if you also are using MPLS, many SAAS and on-premises software solutions do not work well with SD-WAN/MPLS “hop off,” and so the SD-WAN provider many times will recommend DIA services from your local router and not have those communications use any of your your SD-WAN and/or MPLS network. So, cutting costs is normally not what you experience when rolling out SD-WAN.
  2. SD-WAN increases the complexity of your network, which is another serious side effect of most SD-WAN solutions. More complex networks make SD-WAN management and troubleshooting more difficult and time consuming, with far too many opportunities for finger pointing. SD-WAN architectures are far more complex to manage than legacy WAN alternatives with network administrators having to be trained how to manage and troubleshoot SD-WAN edges, including: understanding and working with carrier technologies to troubleshoot problematic WAN links, multi-OSI layer monitoring overlay/underlay networks, keeping up with what is dependent on MPLS and when, and managing packet-level priorities across the WAN. All this involves depending on and dealing with multiple equipment/service vendors, carriers, internal and/or outsourced IT staff… And, with SD-WAN architectures still relatively new and sometimes carrier-proprietary, having a good understanding of SD-WAN trouble ticket management and escalation with the SD-WAN provider… is a changing process that always seems to be trying to escape you. And, when you do build and submit your trouble ticket, most every time, it’s bounced back, requesting conformation you’ve checked with every other vendor involved in your network and power infrastructure, assuring there are no contributing factors. This SD-WAN ticketing experience can be trying, and when your business communications are running slow or are down, there’s no time for finger pointing.
  3. Any SD-WAN benefits are limited to your WAN, and in no way consider internal network resources. What’s referred to as a Software-Defined Network (SDN) or Intent-Based Networking (IBN) architecture is what you can use to reach the centralized control, security, operational versatility, and management most upper-level network administrators are wanting. And, SD-WAN services and providers do not approach this depth of networking use or management. Most SD-WAN models are a stopgap technology on our way to respecting all network resources, to reach SDN architecture. SDN/IBN includes not only WAN, MAN, and LAN resources, but also uses machine learning and artificial intelligence to model your – or should we say, our – network to fit your company, customers, vendors, government, and even society and social movements. So, many IT leaders are choosing to skip the deployment of SD-WAN, saving resources to be able to take full advantage of true SDN/IBN.

SD-WAN can provide all benefits of MPLS, along with packet encryption, the use of cross-carrier DIA lines, and better defined routes to the Internet that have stronger security and monitoring, but getting all this from SD-WAN is not free or simple. Rolling out SD-WAN, so you might can enjoy all these features, most every time, requires you to replace nearly all your existing network resources, increase your network complexity, have many SAAS and on-premises software solutions not working well with SD-WAN Internet “hop offs,” puts more roadblocks for getting to SDN in your way, and most of all makes WAN trouble ticket management and escalation a finger-pointing nightmare.

Our recommendation is for you to use a Managed Service Provider (MSP) reseller with good references, an excellent reputation, and a strong relationship with: all leading ISP’s for dependable DIA services, a proven WWAN solution provider for WAN backup, and Cisco Meraki for your customer SDN networking equipment and networking software services.

The Jackson, Mississippi-based MSP we recommend is Fuse.Cloud, which offers a Private Networking solution for replacing any and all your MPLS and/or SD-WAN infrastructure.

Fuse.Cloud Private Networking: Fuse.Cloud’s Private Networking is a strong solution for the quickly developing SDN, but is also affordable. For all equipment and/or services, Fuse.Cloud uses wholesale reseller agreements they have with all vendors involved, to provide very competitive pricing models to their customers – including Fuse.Cloud’s Private Networking, a DIA/WWAN/Cisco Meraki-based network solution that is developing into the industry’s first realizable Intent-Based Networking (IBN) architecture Software-Defined Network (SDN).

Please contact Fuse.Cloud to have them come tell you how they can benefit your business and prepare you for this quickly evolving digital age.

Leave a Reply