Zenlayer employees aren’t born telecoms experts – they have to learn. Our newest member of the Marketing team, Marie, has been doing just that. Her enthusiasm has been so infectious we asked her to write about some of the topics she’s found particularly interesting. If you’re an old hand in the industry, we hope you’ll enjoy “looking through new eyes” at some things we now take for granted.
One of the first things I had to learn about when I joined Zenlayer was SD-WAN. What is SD-WAN? It’s a software-defined wide-area network. Well okay, that sounds simple enough! We had a LAN (local area network) in my house back in the ‘90s; this is just like that, right? Our home LAN connected three computers using some chunky, blue Cat3 cables that we had to be careful winding or else they’d get full of kinks; a WAN connected the school’s computers using what I assume was the slowest method available (carrier pigeons?); and when I got to college connecting to the campus network was like having access to digital lightning. Networking is familiar territory to me.
There’s a key difference between the networks of my youth and SD-WAN, however, and that’s in those first two letters: SD. Our home LAN relied on a router to send data where it was meant to go – a physical device on the top computer shelf we plugged cables directly into. It was simple, but effective. The router only had to determine which of a few different devices to send incoming data packets to, and there was no security or encryption involved. Multiplayer games of Doom and Warcraft 2 went off without a hitch.
Wide-area networks have wide-area problems
A WAN, on the other hand, has a few more computers to worry about than our house did. Instead of direct connections between each computer there are multiple routes to choose from, some of which may be congested at any given moment. The router or switch you’re connected to needs some method of getting your data where it’s supposed to go without being able to see the whole network because let’s face it, your laptop doesn’t need to keep track of whether or not the accountant two counties over has enabled Wi-Fi on her printer.
The solution? Routing tables. A routing table contains information about nearby routers and switches. The router looks at the destination IP address of your data packets and then looks at its table. If it finds a match, it sends the data there. If there’s no exact match in the router’s table, it sends it on to the next closest choice (“next hop”) until eventually the data gets where it’s supposed to be. Even from that over-simplification, I bet you can see the problem: as WANs and the internet grow, it’s impractical to keep track of so many devices, but if you don’t keep track of a lot of devices you need a lot more hops to transfer data. What to do?
MPLS is a road map for your data
Enter MPLS (Multiprotocol Label Switching). Instead of looking at the whole, long destination address each time, MPLS gives each data packet a short path label. Now there’s no need to look at a table each time; the label already says where the packet should go next! MPLS is also handy because it can be used with any kind of underlying protocol – it doesn’t matter if you have ethernet, dial up, or fiber; IPv4 or IPv6; a dedicated line or VPN (virtual private network). What’s not to like?
As you may recall, this article is actually about SD-WAN. And the great thing about SD-WAN is that it uses a software-defined network. MPLS is fast, but it’s limited to what it knows. Think of a paper road map of California: it’s great for getting around until you encounter road construction or want to go to Nevada.
With MPLS, adding dedicated lines to your network can take months, new routes must be added by an engineer, and there’s little visibility into how your network is doing or ability to respond to congestion. If only there was some kind of software that could take care of all that…
SD-WAN is like a GPS that can also build roads
SD-WAN uses a single system to control your entire network. Because your network is defined by software, adding or removing connections becomes a cinch – you just have to tell the computer what to add and where it is. Scaling is laughably easy when you just need to click a couple buttons to do it. The same goes for bandwidth. Add capacity when you need it, remove it when you don’t. Forget capital expenditures on the next IT budget spreadsheet.
You want to connect to Amazon, Azure, Tencent…? No problem. Clouds are practically designed to be accessed via SD-WAN – the whole point of a cloud, after all, is that your data can be anywhere and the software accesses it for you. It’s much easier to connect to a cloud via software than a dedicated line. (Now there’s a sentence that wouldn’t make any sense just thirty years ago…)
With SD-WAN, the software has complete visibility of the network which means you do, too. You can access the platform any time and see exactly what’s going on, from the macro level to the micro. Meanwhile, routes are propagated in real time and data can be routed around congested links or outages. And because the software doesn’t care what kind of physical or virtual connections the network is running on, you can mix and match infrastructure to your heart’s content. It’s like having a GPS for your data that can also build roads.
SD-WAN: The obvious choice
All that is why SD-WAN is simultaneously obvious and confusing. When you lay out the path like this – data needs to get from one place to the next, here are different methods people have used – the advantages of using software are practically blinding with how obvious they are. Use a computer to control the network! Why wouldn’t anyone just do that in the first place? But if you start explaining SD-WAN without that foundation, the advantages become obscured and it gets very confusing, very fast.
“Wait, why is it good to dynamically propagate routes? Were we not doing that before? How does the computer know what to do? Do I need to know what kind of cables our office router uses? I just learned what MPLS means; do I have to learn another acronym so soon? I send stuff via the public internet all the time so why can’t we just use that for everything?”
My hope is that now you, too, know the answers to all these questions (respectively: “because it’s way faster,” “no,” “algorithms,” “not unless you’re IT,” “no,” and “it’s vulnerable to congestion and hackers”) and will feel confident expounding on SD-WAN next time someone complains about the capex involved in adding the new Melbourne office to the company WAN.