Martin Casado, OpenFlow creator and VMware's chief architect of networking, answers three of our key questions: How to manage physical and virtual worlds in parallel, how important an underlay really is to an overlay, and how to troubleshoot when things go wrong.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
How do you manage physical and virtual networks in parallel?
Martin Casado: Managing virtual and physical worlds in parallel is a standard paradigm in computer science -- having a physical resource and multiplexing virtual resources over it. In general, managing such systems requires having tools that can inspect both the virtual and physical state and tie the two together.
So how do we manage a virtual network solution? Instead of one really complex network that's obfuscated by the configuration state such as VLANs [virtual local area networks] and ACLs [access control lists], we end up with multiple, much simpler networks.
Think of network zero as the physical network, merely providing connectivity. Virtual networks look exactly like physical networks -- they just happen to be virtual. For visibility into them, we can point to diagnostic tools at the virtual network or the physical network.
Let's say [virtual machine] A can't talk to [virtual machine] B. … What would you do? First, you'd go to the virtual network and point your management tools there. Something within the virtual network may be stopping it, but if not, then you'd want to look at the physical network to see if it's a physical issue. This is the rough mental model: First check the virtual network abstraction and, if necessary, check the physical network. Even today, industry standard management tools are being modified to make this a seamless process.
How important is the underlay to the overlay?
Casado: We can take some guidance from the way big 2.0 data centers and network chassis are built. Many of the largest data centers in the world look very much like an overlay solution. The underlay is a simple Layer 3 fabric, and the overlay is normally application-specific. For companies like Yahoo, Google or Facebook, it's going to be an HTTP overlay. But at this level, all of the technology looks effectively the same -- almost exactly like a virtual overlay solution, where software on the edge is doing something, and a very simple physical network isn't doing much.
From a macro perspective, nothing's really different. In these cases, the physical network does a few things: It may do some packet replication, provide unified connectivity, and enforce Quality of Service [QoS] to some degree.
The good news is that this underlay -- the physical network -- is very easy to construct. You can construct it just using Layer 3 and ECMP [equal cost multipath routing]. These kinds of new data centers are one proof point that has evolved over a decade.
Another proof point is a network chassis. If we look at a single network chassis -- a box with multiple line cards -- the line cards generally have all of the intelligence and the backplane provides raw bandwidth. If we liken this to virtual networking solutions, the backplane is the underlay that provides the raw bandwidth and the line cards are endpoints that provide the overlay.
So these two proof points have evolved over decades, and suggest that while the underlay is important, its functionality is limited. This is why the largest companies in the world can build extremely effective networking fabrics using standard Layer-3 gear.
[Layer 3 is] very important because without it, the endpoints wouldn't be able to communicate. But its functionality is primarily around providing transport, QoS, enforcement and aiding in visibility and debugging.
If you run into problems with an overlay, how do you troubleshoot between it and the underlying physical infrastructure?
Casado: The first thing in the debugging process is to use existing tools to take a look at the virtual network and the physical network. There's one step in the process missing today: correlating the virtual view to the physical view. This same exact thing happened in compute virtualization when virtualizing the address space.
In networking today, we don't have the tool chain to correlate the virtual network and the physical network. However, we're already seeing tools being adapted to give us a view of the virtual network, physical network, and provide an ability to map between the two.
It turns out that network virtualization actually gives us way more visibility than we've ever had before, because we need to control the entire edge. Moving forward, I believe we're going to see new tools and management techniques that totally change the paradigm and make it much simpler.
Here's an example of how: A product we work on allows us -- from the edge of the network -- to take a heat map of the entire network so we can see any choke points or hot spots. Since we need to control so much of the edge, we're in this great position to provide vastly better visibility and debugging ability.