It’s obvious that VXLAN was conjured up by a cloudtard. Simple minds devise simple solutions. Herewith are my top five, plus one, reasons why VXLAN bothers me.
1. – Networking has failed to Innovate
The networking industry has failed to innovate. Lets be honest, we should have done something ourselves, and maybe VMware is just getting something done. Now the virtualization has made servers dynamic, movable and flexible in the data centre, now it’s time that networking developed techniques that allowed the network to become equally dynamic and flexible.
No, MPLS is not dynamic or flexible. Or LISP. Or OTV. And stop with the VPLS jokes. I’ve heard them all before.
2. The IEEE has failed us.
The institution that owns the Ethernet standards is the IEEE. The IEEE has been a poor guardian and consistently failed to innovate rapidly. Recent failures include the WiMAX 802.16 standards, the late delivery of SPB, and many more.
The situation is so bad that anyone who wants to get something done is submitting their standards to the IETF! The VXLAN standard isn’t part of the IEEE, is an IETF Draft. TRILL, the successor to Spanning Tree is also an IETF initiative.
And the IEEE 802.1Qbg standard, which would have solved the need for data exchange between server and network, is apparently dead.
The IEEE has failed the networking industry. We need to move on.
3 – Security Fail
The independence of security infrastructure is a core design discipline. Thus Security Services such as packet scanning, logging, authentication are all delivered by external systems as standard policy. Attempts to integrate firewalls and IPS into the hypervisor kernel fail most, if not all, security models. At best,virtual security appliances add some modest security gains but do not replace other systems that provide overarching compliance. By encapsulating MAC in IP, most security processes that use packet scanning and analysis are now broken. This means deployment inside of most existing data centres is complicated by security concerns that VXLAN breaks completely and cannot be accommodated.
4 – Organic or Concrete
VMware shows a complete lack of understanding of partner ecosystems. Systems that deploy VXLAN will invalidate existing network tools and resources without gaining an advantage. Instead of leveraging the value of networking infrastructure for features like QoS, VACLs, MPLS/VPLS, or LISP, or Mobility, or they have attempted to “pave over the forest with concrete” and exterminate the ecosystem. It seems that VMware thinks a network needs to hidden away from Server Admins as if it doesn’t matter. That’s fine for small business, but for large corporates this seems to be misguided. Networks provide significant value in their own right, and should leveraged not destroyed.
5 – Is that it ? Too simple for a complex problem.
If the vSphere 5 new networking features and VXLAN is all that VMware can achieve for networking – we have a huge problem on our hands. It’s a complete lack of vision to encompass the full scale of the challenge. What about creating an API for configuration and capabilities exchange between vCenter and switches. Arista have done this with VMtracer why not do more ?
VMware lack of vision and partnership skills are shining through. Where they could have built a solid foundation, they are taking the short option instead of the longer term view.
Finally, It’s full of fail
Finally, consider this number six if you want (free of charge), but clearly VXLAN was imagined by a Cloudtard. The structural problems with encapsulation to form tunnels are well known within the networking industry – we call it tunnels “Duct Tape for Networks.. Why ? Because the tunnelling cannot prevent being tunnelled. Thus, VXLAN can easily become MAC in IP in GRE over VPLS over IP over ATM and the features that you were trying to achieve just all got broken.