Duct tape is pretty amazing stuff because its versatile and easy to use. That being said, sometimes, that versatility and ease-of-use means it gets used at times when maybe it shouldn’t.
This thought came to mind a couple of weeks ago at VMworld. Over the course of the show, I had a number of conversations with folks about tunneling and overlay network. For many (mostly non-networking) folks, it seemed like the best thing since sliced bread—it gave them the holy grail—flexible, agile, one-demand connectivity without having to talk to the network folks.
From a networking perspective, its kinda funny, since the concept of tunnels is a decades old technology. It’s always played a legitimate role in a comprehensive networking strategy (MPLS and IPsec VPNs for example) so its cool to see an old concept find new applications.
However, lest we be lulled into blissful slumber by the unicorns playing lilting melodies through their horns, its good to remember, as with pretty much everything in IT, there is no free lunch. While overlays networks make life simpler for the server admin or the virtualization admin, there are a couple of things to bear in mind.
From an operational perspective, the overlay environment becomes a second network that needs to be managed—often a dumber, less instrumented network. Somewhere, someone still needs to maintain a fully functioning, highly available, secure, properly traffic-engineered network that underpins that virtualized connectivity. Think of this as the difference between your checkbook and your checking account—just because you can write a check doesn’t mean there is money in the account to cover it.
Now, if you are not a networking dude or dudette, your first reaction may be “why do I care?” Well, when you start seeing performance issues on your tunnel, you start to see intermittent drops on your tunnel, or you need to demonstrate auditable regulatory compliance, then you start to care. While some folks propose that the underlying network becomes irrelevant once you start using overlays, the truth is that the strengths and weaknesses (performance, availability, security, manageability, etc.) of the underlying physical network are going to manifest themselves in in whatever rides on top. While overlay technology is undeniably useful, having an approach that leverages the intelligence of the underlying infrastructure (assuming any exists) is going to pay off in the long run.
Speaking of the long run, the other thing to bear in mind is scalability of design. Long, long ago, when I took my first programming class, my instructor showed me the GOTO command, had me do an assignment, then told me never to use it again—extolling the values of structured code the seductive evils of GOTO-spawned spaghetti code. The same it true with networking. Given a choice, the typical admin would create manageable broadcast domains, crisply defined failure domains and clear L2/L3 boundaries. In fact that is usually how they are designed and often implemented. So, how do we end up networks that look like this? →
Largely because the network admin is trying to address a steady stream of ad hoc connectivity requirements that he or she has little control over–said by no one, ever: “We need to re-architect this app—its going to kill the network”. This type of network environment is going to give someone headaches—the virtual overlay version may look neater, but it is is not going to operate any better and may even be worse (see afore mentioned comment about instrumentation and tools). One of the unresolved design goals is how well the overlay network can handle what essentially becomes decentralized provisioning of network resources—to extend the prior example, imagine you now share a checking account with your spouse and you both have checkbooks. How will the network arbitrate finite bandwidth or handle security and QoS policies that step on each other or gracefully manage a failure? I think this will get especially interesting in large enterprises that can be hosting north of a 1,000 apps in their data centers. Now, these are all solvable problems, but I think how well an overlay solution handles this is going to separate the men from the boys.
So, are overlays the duct tape of networking? No, not really–as I said before, they are (and will continue to be) an important part of every network engineer’s repertoire. With the emerging use cases around virtualization, cloud and programmability/SDN, overlays are experiencing a renaissance, but remember that overlays are not the answer to every problem–its one of the reasons overlay infrastructure is only one component of Cisco’s broader Cisco ONE approach to programmability. Finally, just because its virtual doesn’t mean is doesn’t have to be engineered–virtualization can hide complexity but it does not magically eliminate it. If you are looking at virtual overlays to support your server virtualization or cloud projects, trust me, make sure your network folks are involved, before one of you identifies some new uses for duct tape.
BTW, on a lighter note, if you want to know more about Cisco ONE , why don’t you start with a fun activity by answering the questions that I put together for the Unified Data Center IQ contest ? One correct answer (out of 4 questions with multiple choices) gives you a chance to win an iPAD . You are one click away