Top Five Things About VXLAN – And why it’s full of Fail

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.

  • DGentry

    If you’re highlighting things wrong with the proposal, I would think reliance on IP multicast would be on the list.

    My own view of VXLAN is far more positive. That VM mobility has stuck us with a need to make networks behave as though they are an enormous L2 broadcast domain is a problem. VXLAN takes on that problem atop an L3 network.

  • Juan Lage

    Greg, this time I have to disagree quite a bit …
    1.- Networking as not failed to innovate. Making a VM the atomic unit for doing every thing else creates trouble for others. What is the point to run an OS (the hypervisor) to virtualize hardware to run another OS on top to run applications (clustered) … Apps should be able to leverage CPU capacity (they dont) so you need less clustering, and OS should provide enough segmentation so that you need no VMs …2.- IEEE has not failed us. STP successor is yet to be proved. There are alternatives to TRILL which come from IEEE and are in production in SP networks today. That TRILL may be a better fit for DC traffic flows is another story.
    3.- VXLAN encapsulates, does not encrypt. Encapsulates in a simple and well defined packet field, no reason why existing appliances and hardware cannot be “tuned” to support inspection. 
    4- Agree on this one, somewhat … just a precision: read the IETF draft for VXLAN, VMware is but one of the authors. This isn’t VMware’s thing. At best, it is VMware+Cisco+a-bunch-of-others. All others come form Networking industry. Why not pick on LISP, OTV etc … because these come from Cisco only and ALL other networking vendors would object as they are behind. Question then is which networking vendors are innovating for real? …
    5- IF it can be simple it is better. VXLAN isnt the solution to ALL problems. But it can be a good tool to deploy scalable IaaS over a scalable L3 network fabric.

    DGentry -> Using IP multicast isn’t a problem. That most people don’t know how to run IP multicast may be … That’s another story :-)

  • Jason

    On the contrary, because of cloud computing we’ve had more innovation in
    networking in the last few years than in the last 3 decades. I would
    agree that most of the innovation doesn’t solve the problem, and I think its intentional so certain vendors can sell more products, but VXLAN
    is one of the more reasonable proposals to date. And being an IETF draft, it encourages vendor interoperability.. Win.

    Even if IEEE came through with SPB and .1Qbg, we’d still need to re-invent QoS at L2, and filtering with VACLs doesn’t sound dynamic or flexible. We still can’t achieve all the things we can do at L3. Going the IEEE route (no pun) will be a *long* road of re-invention.

    The suggestion to continue developing around vmwares API and arista vtracer is fine for enterprise environments and vmware shops who like to blow money, but not for service providers. It doesn’t solve the multi-tenancy issues at L2 or L3, it doesn’t solve the 4k vlan barrier, it doesn’t solve STP blocking bandwidth, and we’re still stuck with multi-chassis link aggregation. TRILL, as great as it sounds, doesn’t solve most of these problems either, and it creates some new ones in regards to FHRP and optimal inter-vlan traffic flows.

    Nothing else fits the bill, so I welcome the addition of VXLAN. We need open standards that aren’t tied to a single vendors hypervisor or network device.

    There is also NVGRE (draft just submitted 9/14), but it too is Duct Tape for Networks. Interestingly, Arista is part of both VXLAN and NVGRE drafts.

    • Etherealmind

      I agree about innovation in the last three years. It’s exciting to see.

      The issues you point out as features seem like failures to me. They are the types of things that VXLAN & NVGRE fail to address comprehensively and reduce visibility at the network level. A network can be much more than be a low latency, high bandwidth path between software instances.

      • Jason

        The reduced visibility would be a problem in Enterprise data centers, but for multi-tenant virtual environments hosting Internet facing web applications, it seems to solve more problems than it creates. I’m not suggesting it fixes everything, I just don’t think its full of fail.

  • Flyjetaviation

    i sugget you to update yourself :-) I’m just finishing 802.1BR …. You are way behinde my friend …

  • Pingback: Technology Short Take #15 - - The weblog of an IT pro specializing in virtualization, storage, and servers()

  • Cristian

    Hello Greg,

    I wonder if the recent discussion with Ken Duda (Show 66 of Packet Pushers) alleviated some of your concerns.

    Thank you,


    • Etherealmind

      Yes, and No. I’m working on a followup post that should arrive int he next few weeks.