Multiprotocol Label Switching (MPLS) – Understanding Network and Security for Near-Edge Computing

Whereas IP routing operates at Layer 3 of the OSI model, MPLS operates below that (often called Layer 2.5). Data is forwarded based on labels along predetermined paths, which allows MPLS to offer far more reliable packet delivery than IP routing over the internet can.

The trouble with MPLS is bandwidth cost. Because many organizations do not have the capital required to deploy their own global MPLS network, paying an ISP or telco for a slice of theirs is common. However, this is quite expensive. For reference, 1 Gbps of business-class internet access from an ISP in New York City might cost $500/month. 1 Gbps of MPLS service in the same city could easily cost $100,000/month. This is why MPLS tends to be purchased in much smaller increments and used only for mission-critical traffic.

Software-defined networking (SDN)

Manually provisioning a new application on a large enterprise network requires several steps. Each one may well be handled by a different specialist. Of course, every person involved needs at least a couple of days to respond. Here is an example of how provisioning workflows are born:

A ticket is sent to the infrastructure team requesting a VLAN for new app servers (48-hour SLA).

A ticket is sent to the security team requesting firewall rules for dependencies (48-hour SLA).

A ticket is sent to the WAN team requesting MPLS routing to the remote database (48-hour SLA).

A ticket is sent to the platform team requesting a server pool on F5 (48-hour SLA).

A ticket is sent to the network team requesting an SNAT pointing to the F5 (48-hour SLA).

This equates to 10 working days or two calendar weeks. Factor in someone going on vacation or being out sick, or some approval being needed somewhere in the middle, and a full month is not uncommon – just to get the network laid down for this new application.

Automation is needed, but each step requires a specialist to touch an expensive, vertically-scaled, and highly complex piece of equipment. It is unlikely that all parties are going to agree to let you send API commands to shared mission-critical hardware such as their core switch when one wrong move can take the entire data center down. Even if they all did, the diversity of hardware vendors involved means you would likely end up maintaining a provisioning system built of duct tape and baling wire.

What many enterprises, and all cloud service providers, do to address this is use an overlay transport of some type. It essentially operates as a VPN mesh (though it is not always encrypted) that abstracts the physical layer, which becomes known as the underlay. Its only job now is to move packets from A to B. VXLAN, Geneve, IPSEC, and other such protocols can be used for this purpose.

Now, entirely virtual versions of VLANs, firewalls, load balancers, switches, routers, and so on can be deployed to perform the same functions that hardware appliances used to. Only now, because they are virtual, you can have one for every application.

Because the virtual network constructs are software, automated provisioning is straightforward – if for no other reason than because the blast radius of any problems during provisioning is contained to only that one application. Even better, the entire end-to-end configuration of what used to involve five tickets and three to four weeks can now be deployed from a template with a single click.

Finally, because the network constructs are entirely virtual, it is possible to eliminate the need to hairpin out to an east-west firewall or router just to come right back and communicate with a different virtual machine on the same hypervisor because it happens to be connected to a different VLAN. Now, that sort of logic can be distributed down to the hypervisors themselves, which can offload significant amounts of unnecessary east-west traffic in the data center.