back to article No middle ground, no compromise: VMware blocks Cisco's SDN play

VMware's recent decision to block third-party virtual switches on its platform could put a serious crimp in, among others, Cisco's plans for Software-Defined Networking (SDN). What does this move mean for customers who don't buy into VMware's NSX vision, but prefer the more hardware-centric SDN exemplified by Cisco's ACI? To …

  1. Voland's right hand Silver badge

    Vmware behaving like Vmware

    Vmware is behaving like Vmware. Nothing new to see here - move along.

  2. Locky

    Michael flexing his muscles

    While I don't think the Borg are done just yet, this is clearly Dell wanting to kill off a bit of competition before raking back in some of that EMC pricetag.

    Grab some popcorn, this one has a way to go yet

  3. Dakaix
    Stop

    Sorry Trevor, but you've missed a big piece of the ACI system here. ACI can make use of and control the VMware Distributed Switch, it's not just limited to hosts with the 1000V installed.

    It's true that VMware's recent change in policy on third-party switches means that the 1000V itself will likely be killed off, but the number of actual customers paying Cisco for that is already negligible (after Cisco made the basic license free-to-use a couple of years ago) so the effect is relatively minimal.

  4. Glen Turner 666

    SDN future is driven from cloud providers, not supplier strategies

    "The problem is that large customers rely almost exclusively on Cisco and VMware, and they aren't interested in the open-source switches and open-source hypervisors with open-source management software that's needed to make hybrid SDN actually workable today."

    This paragraph summarises my issue with the article. It's writes as if the enterprise vendors are the major source of influence over SDN. Whereas SDN is being driven by the cloud vendors, all of whom build their own switches, all of whom run their own software on those switches. It's likely that the future of SDN in the enterprise will be a byproduct of the main game at those cloud vendors; rather than anything in the strategic plans of VMware or Cisco.

    In my view it's very likely that one of the cloud vendor SDN technologies will become so widely known that enterprises persisting with traditional enterprise networking and VxLAN will find themselves in an expensive niche.

    1. Anonymous Coward
      Anonymous Coward

      Re: SDN future is driven from cloud providers, not supplier strategies

      Good point, and if you start thinking about the shift to hybrid workloads running (or migrating) to/from the cloud, using the cloud provider's SDN for seamless connectivity and control is compelling.

    2. Anonymous Coward
      Anonymous Coward

      Re: SDN future is driven from cloud providers, not supplier strategies

      Agree, people are interested in moving to cloud, AwS and GCP, to get away from this proprietary in fighting. Really expensive to buy proprietary and it doesn't work well because each vendor is trying to take over the world, won't stay in their lane.

  5. Anonymous Coward
    Anonymous Coward

    Independence

    I think decoupling creates more value for customers and the ecosystem

    https://www.varmour.com/resources/blog/entry/a-declaration-of-independence-for-network-segmentation

  6. Terafirma-NZ

    standards and API access

    This was why the industry chose to standardise on Open vSwitch. The fundamental problem here is that VMWare builds and maitains the bulk of OVS and even made a commitment to move ESXi over to it, no idea if they did or not but one thing is for sure they are not giving us the API access va OVSDB to control it. If this was exposed then all parties could link in and control the vSwitch be it using NSX or a 3rd party control/integration.

    If you look around this is why all the non NSX products show integration with KVM and Openstack as they have access to OVSDB. If you want this on ESXi you have to purchase NSX thus negating the 3rd party product you wanted to use.

    Funny how VMWare build OVS and are the only ones who don't use it heck even MS Hyper-V is supported and MS will give you OVSDB API access to their switch.

    1. Anonymous Coward
      Anonymous Coward

      Re: standards and API access

      The funny thing is that OVS is supported on the ESXi hypervisor, but only with "NSX Transformers" (aka NSX multihypervisor). There are only about three VMware employees who know or acknowledge that fact.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022