Edge Virtual Bridging (802.1Qbg) – a Technology Refusing to Die

I thought Edge Virtual Bridging (EVB) would be the technology transforming the kludgy vendor-specific VM-aware networking solutions into a properly designed architecture, but the launch of L2-over-IP solutions for VMware and Xen hypervisors is making EVB obsolete before it ever made it through the IEEE doors.

2020-12-26: The blog post was written in 2012, and I haven’t heard anyone talking about EVB for years, so maybe it’s truly dead by now, although it’s still supported by Linux bridge, and there might be a zombie or two lurking in a Juniper switch somewhere.

Meanwhile, IBM’s vSphere virtual switch was a total failure. It was so unimpressive that nobody noticed when it disappeared.

IEEE WG is still working on the draft; the major hypervisor vendors have already moved on – VMware has VXLAN, Microsoft has NVGRE and Xen/KVM have GRE+OpenFlow with Open vSwitch. As I predicted, the hypervisor vendors woke up, realized VLANs really don’t scale (there were a few old-school idiots yelling that message from their L3 ivory towers for the last few years, but nobody listened), and focused on implementing larger-scale virtualized networks with MAC-over-IP encapsulation.

The truly sad part is that EVB isn’t a bad technology. It’s a perfect solution if you want to use VLANs to create virtual networks, and its S-component nicely solved the problem of virtual server-to-switch links that we need in some environments.

And then there’s IBM: Its DVS 5000V is the first virtual switch supporting EVB/VEPA, as does its Virtual Fabric 10G switch module. It’s nice to see someone using standard technologies instead of proprietary solutions like Cisco’s VN-Tag or HP’s Virtual Connect (although IBM’s documentation indicates they might have implemented a 2 year old draft). According to the same documentation, the current EVB implementation in Virtual Fabric 10G switch module doesn’t support CDCP (a standard way of creating multiple NICs over the same uplink). A year ago I would have been excited; today I can’t help being reminded of ATM support on IBM Front End Processors.

7 comments:

  1. While I tend to agree, I think that EVB will be a long term winner. My current favourite is a VEB using TRILL to connect to the network means no LAG, no STP, and a proper communication of state between server and the network.

    The IEEE is not serving it's community very well by taking so long over this.
  2. It's clear VLANs don't scale for very large environments, but I'd say for the very large majority of deployments, they scale just fine. So maybe EVB will have it's place in the market. However, if the L2oIP solutions become easy enough to manage longer term for the average Joe, then why not use them for all designs and we can be done with VLAN trunks, etc. As always time well tell.
  3. i'm getting lost with all those vm networking solutions :-[ when i approach a new customer, they always want the most known-affordable-oldest solution !
  4. I would be more visionnary here but I do think that NO virtualization is the long term winning solution...
    If you look at the chip vendors architectures evolving fast, and the application architecture increasing you will be able in the coming years to consolidate apps & networking on a same platform without hypervisors. Therefore coming back to more simple software architecture.
    Hadoop-like solutions? O:-)
  5. Guest,
    Being visionary is great and there are a lack of those folks out there that are...BUT...we can't do a full 180 over night throw away everything that's been done for 25+ yrs. Gradual changes work best. We'll see adoption of newer architectures from CSPs, large financials, hyper scale companies, and they will probably make their way into the Enterprise and then SMB, and into the home. We'll see. That goes for everything @Cloudtoad has been talking about too. It sounds great, but not realistic in the short term for the MAJORITY of environments out there. Customers need validated designs that work and a support model that provides SLAs.
  6. @Guest: Your vision is correct. Long-term, PaaS is the way to go ... but it will take as long as it took us to get from 3270+CICS to Web 2.0+iPad.

    @jedelman8: absolutely agree.
  7. @other Anon: If we were to find ourselves working back to the multiple-applications-on-one-OS/appserver model, it would just serve to feed my confirmation bias that everything good gets trounced in the market by slipshod cheap solutions, then we slowly and painfully work our way back to upgrading the dominant solutions to do all the things the better solution did in the first place, albeit with more cruft. e.g. SCSI vs IDE->ATA->SATA and Firewire vs USB1->2->3.

    And we refuse to learn from history, so we are doomed to repeat it.

Add comment
Sidebar