Currently in Migration - Jason Edelman's Old Blog
  • Home
  • About
  • Contact

NSX doesn't need a vSwitch

11/12/2013

17 Comments

 
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).

Reply
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 :)

Reply
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? ;-)

Reply
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.

Reply
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.

Reply
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

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 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.

Reply
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.

Reply
Frank DAgostino
10/9/2014 09:47:57 am

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

Reply
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?

Reply
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.

Reply
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?"

Reply



Leave a Reply.

    Author

    Jason Edelman, Founder of Network to Code, focused on training and services for emerging network technologies. CCIE 15394.  VCDX-NV 167.


    Enter your email address:

    Delivered by FeedBurner


    Top Posts

    The Future of Networking and the Network Engineer

    OpenFlow, vPath, and SDN

    Network Virtualization vs. SDN

    Nexus 7000 FAQ

    Possibilities of OpenFlow/SDN Applications 

    Loved, Hated, but Never Ignored #OpenFlow #SDN

    Software Defined Networking: Cisco Domination to Market Education

    OpenFlow, SDN, and Meraki

    CAPWAP and OpenFlow - thinking outside the box

    Introduction to OpenFlow...for Network Engineers


    Categories

    All
    1cloudroad
    2011
    2960
    40gbe
    7000
    Arista
    Aruba
    Big Switch
    Brocade
    Capwap
    Christmas
    Cisco
    Controller
    Data Center
    Dell Force10
    Embrane
    Extreme
    Fex
    Hadoop
    Hp
    Ibm
    Isr G2
    Juniper
    Limited Lifetime Warranty
    Meraki
    Multicast
    N7k
    Nexus
    Nicira
    Ons
    Opendaylight
    Openflow
    Openstack
    Presidio
    Qsfp
    Quick Facts
    Routeflow
    Sdn
    Sdn Ecosystem
    Security
    Ucs


    Archives

    May 2015
    April 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    June 2014
    May 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011


    RSS Feed


    View my profile on LinkedIn
Photo used under Creative Commons from NASA Goddard Photo and Video