As the implementation and operation of software defined networks (SDNs) becomes clearer, one thing still largely unresolved is how SDN will relate to existing virtual LANs. Should SDN be seen as a clear replacement for the vLAN? Or will it simply augment it to provide a friendlier environment for scaled out virtual and cloud functions?
There’s no doubt that, as it stands now, vLANs simply are not up to the level of functionality that network architects are starting to envision. Juniper’s recent purchase of Contrail points up the fact that when it comes to the massive scale that public, and even some private, clouds are expected to provide, nothing short of complete separation of the control and data planes will do. The $176 million deal is widely seen as a strategic move on Juniper’s part to incorporate SDN elements into both the Junos operating system and the QFabric architecture, allowing enterprise networks to cut down on the amount of network layering they currently employ as well as embrace the kind of dynamic configuration capabilities that are likely to drive data environments over the next decade or more.
But what exactly does Contrail do? That is still something of a mystery considering the company is one of the more recent start-ups in the networking space and has been operating under a fair amount of secrecy so far. It’s telling, however, that CTO Kireeti Kompell is the former Chief Architect for Junos, and that Contrail has been quite forward in its criticisms of the vLAN as a scale-out architecture. The company’s Parantap Lahiri, vice president of solution engineering, went so far as to spell them out in a recent blog − namely that they rely on quirky spanning-tree protocols, are limited to 500 hosts at best and are difficult to manage in highly dynamic, highly parallel mesh topographies.
To be clear, though, Contrail is not the only one pointing up the vLAN’s shortcomings. The main impetus behind VMware’s development of the VXLAN platform, after all, was the need to move networking to cloud scale and beyond. The company notes that with vLANs plagued with poor extensibility, high fault tolerance and IP address maintenance issues, the need for virtual networking domains atop existing virtual and network infrastructure is clear. In this way, server and storage pools can cross current switch boundaries using Layer 3 transports, which not only eliminates the need to manager Layer 2 but utilizes existing hardware with no software upgrades and specialized coding.
So does this mean the vLAN is headed for the dustbin of history? Not entirely. Remember, when we’re talking about massively scalable network architectures, we’re really talking about the cloud. For traditional enterprise environments, which still have a pretty long shelf-life, vLANs are still very effective in streamlining network infrastructure by pooling disparate hosts and end points through simple software configurations. As I pointed out some months ago, overlay platforms like VxLAN and Microsoft’s Network Virtualization using Generic Routing Encapsulation (NVGRE) use different techniques to extend scalability through Layer 2/3 tunneling, but these are probably overkill until you reach the upper limits of vLAN scalability. At that point, configuring network architectures on the controller rather than the switch will be a welcome change.
The thing to keep in mind here is that building bigger, more scalable network topologies is not an end in itself. Even if software defined networks produce more efficient and less costly infrastructure, it will be a Pyrrhic victory if it does not result in improved application performance. Ideally, we’d like to get to a point where applications themselves can provision and re-configure network resources on the fly, which is certainly within the realm of possibility now that we are on the verge of true network abstraction.
The vLAN, then, is a good start toward that level of service, but it won’t get you there on its own.