By Alex Henthorn-Iwane, Chief Marketing Officer for PacketFabric
Enterprise WANs have
seen a lot of change over the past several years, and some of the most popular
new technologies leverage Internet-based overlay architectures. In this
article, we'll unpack the difference between underlay and overlay networking,
explore the limitations of Internet-based overlay networking and traditional
telco underlay service alternatives, and how the network services market is
evolving to meet hybrid and multi-cloud interconnection needs with NaaS and
middle mile approaches.
Defining Underlay and
Overlay Networking
Underlay networks refer
to the physical network infrastructure: DWDM equipment (in the case of
wide-area networks), ethernet switches and routers (from vendors like Arista,
Cisco, Juniper, and Nokia), and the cable plant physical infrastructure such as
fiber optic cabling that connects all these network devices into a network
topology.
Underlay networks can be
Layer 2 or Layer 3 networks. Layer 2 underlay networks today are typically
based on Ethernet, with segmentation accomplished via VLANs. The Internet is an
example of a Layer 3 underlay network, where Autonomous Systems run control
planes based on interior gateway protocols (IGPs) such as OSPF and IS-IS, and
BGP serves as the Internet-wide routing protocol. And Multi-Protocol Label
Switched (MPLS) networks are a legacy underlay WAN technology that falls
between Layer 2 and Layer 3.
By contrast, overlay
networks implement network virtualization concepts. A virtualized network
consists of overlay nodes (e.g., routers), where Layer 2 and Layer 3 tunneling
encapsulation (VXLAN, GRE, and IPSec) serves as the transport overlay protocol
sometimes referred to as OTV (Overlay Transport Virtualization).
There are two prominent
examples of virtual network overlays. The first and best known are SD-WAN
architectures that rely heavily on VPN functionality to replace MPLS circuits,
making it less costly and easier to connect various branch offices, retail
locations, and other remote sites to a WAN. The other example is cloud-native
networking, where encapsulating traffic with VPN tunnels is the preferred
method of connecting VPCs to enterprise locations.
Overlay Network Achilles
Heel: The Internet
Overlay networks offer
notable benefits, including software-driven network automation and VPN privacy
between tunnel endpoints. Recently, providers of multi-cloud networking have
created solutions that further abstract the per CSP networking logic so that
it's easier to manage overlay connectivity between clouds. These are all good
things.
However, overlay
networks can't escape the gravitational pull of the Internet as an underlying
network. VPN tunnels or not, the Internet isn't private, is rife with security
threats, and exacts a significant latency tax on traffic flows due to its
shared, collective nature. Even cloud provider backbones are shared network
services that function as extensions of the Internet.
Furthermore, there are
workflows that just don't belong in a VPN tunnel, such as when you're:
- Building a WAN between
colocation data centers.
- Connecting a digital
operations backbone to reach edge locations.
- Moving significant
numbers of user flows to a critical enterprise cloud or SaaS application
- Transporting significant
volumes of application, transaction, or data replication traffic on a hybrid or
multi-cloud basis
- Trying to do anything latency-sensitive.
Finally, a significant
challenge with Internet VPNs in the cloud networking context is economics.
Egress data charges from cloud providers when transporting volumetric traffic
via their Internet-connected backbones is costly and unpredictable.
The Problematic
Alternative: Telco Connections
If you need scalability,
privacy, security, and predictable low latency, traditionally, that has meant
turning to telco underlay connectivity. But we encounter numerous problems on
this path. First of all, getting telco connections isn't easy. It can take
weeks to get a quote on WAN services. Then, it can take months to provision the
service. Further, you typically have to commit to your peak anticipated
bandwidth level for three years, even if you're nowhere close to that level
now, which is highly wasteful. Fortunately, there's a better underlay option.
Automated Underlay Turns
WAN into Cloud
Fortunately, a new
category of wide area networking service provider has emerged that deploys SDN
automation from the ground up within a private optical network backbone. These
are sometimes called Network-as-a-Service (NaaS) providers, and are also
sometimes referred to as Middle Mile providers. The focus of middle mile/NaaS
providers is to connect the hybrid and multi-cloud IT core infrastructure at
high speed, with privacy, security, predictable performance, and SLAs that the
Internet can't provide. However, unlike traditional telcos, NaaS providers can
leverage the inherent automation in their platforms to allow enterprises to
provision services within minutes rather than months. And NaaS/middle-mile
providers offer flexible consumption terms. Rather than requiring long-term
contracts for everything, you can consume tens or even hundreds of Gbps by the
month or in some cases by the hour.
Essentially, this turns
WAN into a cloud. This is the future of interconnection for colocation data
centers, cloud, enterprise SaaS, Internet Exchange and other elements of the
extended enterprise network architecture. And that future is already here. If
you're not already leveraging NaaS for hybrid and multi-cloud connectivity
instead of relying on Internet or traditional telco, it's high time to explore.
##
ABOUT THE AUTHOR
Alex Henthorn-Iwane, CMO, PacketFabric
Alex Henthorn-Iwane is Chief Marketing Officer for PacketFabric, and has brought innovative networking, software, and security technologies to market since the early days of the commercial Internet. Alex speaks and writes mostly on cloud, network, and security.