NSX doesn't need a vSwitch

11/12/2013

It's been nearly a week since the Insieme launch and I've yet to write a post about it, but wanted to share the following excerpt that was originally posted in a recent Network World article where Martin Casado comments on Cisco's ACI vs. VMware's NSX.

"NSX supports Citrix XenServer and Red Hat KVM as well as VMware ESX, he says. Support for Microsoft Hyper V is coming. And if the point Cisco's trying to make is that software overlays require a hypervisor, well, NSX can also run on bare metal servers without one, Casado claims. It can create tunnels from a Linux endpoint, he says."

Tunnels to bare metal servers. Interesting to say the least.

For the original article:
http://www.networkworld.com/community/blog/cisco-claims-scuttled-vmware

17 Comments

Ivan Pepelnjak link

11/12/2013 12:01:41 am

It's really trivial - deploy OVS on bare-metal Linux and let it be controlled by NSX controller. Create switch interfaces in different namespaces (or containers) for multi-tenant operation.

The "only" problem is trust - the bare-metal server becomes a trusted node in the overlay virtual network (similar to a hypervisor).

Jason Edelman link

11/12/2013 01:49:19 am

Understood. I actually recall having this conversation with someone a few years ago (minus the overlays). Not sure what trust has to do with it :)

David Klebanov

11/12/2013 02:49:10 am

Exactly and here goes the story of two separate NSX products, a bare version for open hypervisors and a bolt-on version on vSphere :-) Aren't fragmented stories fun to tell? ;-)

Jason Edelman link

11/12/2013 03:35:29 am

Why would it need to be two products? When I was discussing this a few years ago, it was actually regarding the 1KV such that the port was the port a host was connected to regardless of it was physical or virtual. And of course, the policy would move along with it and mean very little if it was p 2 v'd. This would be nice. You can't deny that.

David Klebanov

11/12/2013 03:34:46 pm

I don't know why there would be two products... they don't really work together and each one of them independently does not address all the asks. I guess it comes from the fact that hotchpotch fragmented solutions are easier to push into the market when you bet that your audience can't challenge you to the point where you REALLY need to explain how it works.

Lincoln Dale link

11/12/2013 12:27:40 pm

At least one vendor (Arista Networks - the one I work for) has a hardware VXLAN gateway which can be provisioned by NSX today. That provides line-rate hundreds of gigabits/second overlay connectivity for bare metal servers, storage or even virtualized servers all provisioned exactly the same way you would a 'software' approach.
We do this and I'm sure others will too.

Jason Edelman link

11/13/2013 10:27:36 pm

Lincoln,

Yes, many vendors provide HW VXLAN based gateways. It would be interesting to see a design in which NSX only managed physical VTEPs for a bare metal server environment. Is this what you are proposing? Would love to see a write up on something like this.

Ivan Pepelnjak link

11/13/2013 10:32:48 pm

You don't need NSX for that. Just a bunch of Arista switches with some orchestration glue (Puppet would probably work just fine) … and I'm positive Arista has a few more goodies coming.

Lincoln Dale link

11/14/2013 03:53:17 am

Hi Jason,
Yes many vendors are claiming to have HW VXLAN gateways but as far as I know only one has actually been shipping and has customers using it today.
We are not stating that an environment must ONLY consist of HW VXLAN gateways, there is nothing inhernet in one VTEP that makes it know if another VTEP is software or hardware and we (Arista) really don't care either way. But to answer your question yes you could have 100% HW gateways and that could be provisioned by NSX and all that can be done today.
No write up on the specifics of this yet (work in progress) however if you want to know some of the details we DID cover this last week at OpenStack in Hong Kong.
Look at <http://www.youtube.com/watch?v=AtZTuq5NTts> where Andre shows what this can look like.
Note that we (Arista) are agnostic as we don't have a 'controller'. We do have various northbound APIs (OVSDB, JSON-RPC, others) for orchestrating policies so we do have flexibility in what 'controls' the environment - and that can be NSX, Plumgrid and others today.

Lincoln Dale link

11/14/2013 03:53:43 am

Lincoln Dale link

11/14/2013 04:08:55 am

Hi Jason,
Yes many vendors are claiming to have HW VXLAN gateways but as far as I know only one has actually been shipping and has production deployments.
We are not stating that an environment must ONLY consist of HW VXLAN gateways; there is nothing inherent in VXLAN that means that a VTEP know if another VTEP is software or hardware and we (Arista) really don't care either way. But to answer your question yes you could have 100% HW gateways and that could be provisioned by NSX and all that can be done today. This was demonstrated at VMWorld in SF back in August.

Write up of how this all fits together is coming - but takes a bit longer when there are multiple vendors involved, however if you want to know some of the details we DID cover this last week at OpenStack in Hong Kong.
Look up "Running OpenStack over a VXLAN Fabric" on Youtube where Andre shows what this can look like. (I'd post the URL here but seemingly the comments system doesn't allow that).

We (Arista) are agnostic as what the 'controller' is, as we don't have a 'controller' and that is deliberate. We do have various northbound APIs (OVSDB, JSON-RPC, others) for orchestrating policies so we do have flexibility in what 'controls' the environment - and that can be NSX, Plumgrid and others today based on those northbound APIs.

Jason Edelman link

11/13/2013 11:45:19 pm

Ivan,

I was expecting to see announcements like this last Monday during the Arista launch, but didn't happen. I agree, but having overlays still nice for abstracting or not worrying about the network core. Was more curious if this is possible with NSX given they are only using ovsdb, i.e. no OpenFlow. When they are a gw, NSX uses CFM if I recall so only one gateway is active. Need to think about this some more.

Lincoln Dale link

11/14/2013 04:17:25 am

(sorry for duplicate messages above, your comments system said it has an error posting but I guess it actually WAS posting)

The announcements last week were around Arista 7300X/7250X platforms and some features. We wanted to spend more time on single-tier network designs (what we call "Spline") because that is what is applicable to the 90%. We already have proven network designs that scale out to hundreds of thousands of 10G attached ports and Spline was about catering for a more typical workload of up to 2000 physical servers 10G attached.
We're not quite the marketing machine of Cisco so perhaps that got lost in the hype of ACI.

Not sure of what you mean with "only using ovsdb". There can by any number of gatways active and it scales out horizontally.
In the context of APIs for doing this, OpenFlow isn't really relevant as OpenFlow (as defined today) has no primitives for defining overlays.

Frank DAgostino

10/9/2014 09:47:57 am

Any views on the following: https://www.youtube.com/watch?v=SQpezyfvI_A

Ivan Pepelnjak link

10/9/2014 03:32:18 pm

Oh, sure - I'll say whatever will make my company sell more boxes|products|services|whatever. Where's the news in that?

ltd

10/9/2014 04:27:38 pm

Good to see you're keeping it "classy" Frank. Youtube account <https://www.youtube.com/channel/UCH8LdJ-j1A-dQr808WTUA3w/videos> created yesterday with 1 video.

Jason Edelman link

10/9/2014 09:04:59 pm

It's not surprising meaning we can also list many others that have left Cisco to go to competitors. Others of all levels and ranks. No reason to focus on just one.

The question I always ask though is "Why?"

NSX doesn't need a vSwitch

Leave a Reply.

Author

Top Posts

Categories

Archives