I believe the difference is that Open vSwtich is intended to be used as a software switch similar to how a VM is intended to be a virtual server (and its intended use there would presumably be networking between VMs). While OpenSwitch is intended to be an OS run on an actual physical switch. There seem to be overlaps though since it looks like Open vSwitch will also run as an OS on a physical switch.
OpenVSwitch is a component in OpenSwitch. E.g. OpenSwitch uses OVSDB as its pub/sub configuration store, and also for other state. Other free software / open-source network projects like Quagga have been modified to take their config from that, and store their state to it. Tools like the CLI, the WebUI and REST API then can build on that OVSDB store.
Essentially, one of the aims of OpenSwitch is to build a cohesive API around a wide set of Linux networking tools and daemons, and build a broad community to make it happen.
"OpenSwitch is a network operating system for disaggregated switches that are built around OCP compliant hardware and that utilizes the ONIE boot loader to install and uninstall network operating systems. It is aimed at accelerating the transition to open networking as well as the adoption of disaggregated data center networks."
The release today is about opening it up for the community participation. Making sure we release it early and not overbaked. So the community can shape the direction. We wanted to have one real HW platform that would be fully functional + Docker container image, which is being heavily used in the development and CIT. Other Broadcom Trident II/Tomahawk based platforms would be quite easy to support. For other ASICs, we would be glad to get their vendors involved.
That seems like a solid strategy. I look forward to the Tomahawk chip, but also support for Trident+ would be great, as there's a large installed base of those. And I'm sure you're already planning supporting a 32x 40Gb Trident II switch, as those are common spine switches.
I could see us switching from Cumulus Linux to Open Switch, with that hardware support, and if Open Switch stays open source. We'd likely even pay for support, if cost competitive.
Note that OpenSwitch and Cumulus Linux are both exactly the same in terms of Open Source: everything is Open Source except the part that talks to the ASIC. OpenNSL in OpenSwitch's case, and switchd in Cumulus's case.
It's Linux (see [1] for why) and from the git repos it looks like it uses OpenNSL [2] (which is not open source but open in the sense of "this used to be under NDA and now it's not so be grateful we're giving you that much").
This seems like a good, if belated, move on HPs part. Ethernet switches have become trivial to build with off the shelf parts. If you open up the software then you can focus on things like build quality and reliability.
I think that's the explanation for HP's adoption of ODM/OCP. More and more customers are going to buy it, so HP can either get with the program or lose those customers permanently.
The companies that need integrations and consulting are more likely to buy Cisco. This open source OS will be in the "experimental" status for quite some time.
the higher-end switches take considerable engineering, just on the hardware side, and are fairly high-margin products. If the networking equipment space becomes OS agnostic, or consolidates around OpenSwitch, this removes one of Cisco's major advantages (their huge installed-base, network OS dominance, customer switching costs), and allows HP (and others) to compete directly on network equipment hardware architecture/performance/cost. More competition in that area would be a very good thing (maybe not so good for Cisco's dominance). It's also good to decouple the hardware from the OS/software, and allow innovation in both areas independently.
>the higher-end switches take considerable engineering, just on the hardware side, and are fairly high-margin products
This hasn't been true for a couple years now, at least for top-of-rack and spine switches. White-box switches are now accessible to the general public, have low margins, and are not limited to huge purchasers like Facebook and Amazon.
Candidly - their switches in my experience are garbage. They aren't making money, and they know they can't beat Cisco with a traditional approach. If I had to guess they're hoping that opening things up will make them the vendor of choice for enterprises looking to mimic Google/Facebook. This feels like a hail mary with the future of their presence in the network switching space to me.
Gonna be hard to compete with the likes of Cisco Nexus... I mean after almost 5 years of the Nexus 1000V platform they come to the table with an "open-source" software platform to be used on hardware that no one is currently using?
I could see this getting traction if they announced it was compatible with some of the newer switches
The Nexus 1000V is not really in the same category at all. This is a replacement for NX-OS.
And honestly, I really don't know how Cisco's Nexus line is going to survive at all. They will coast for a while on the population of Cisco certified engineers that don't want to learn new things, but it is literally cheaper for us to buy new hardware and support contracts than it is to renew our Cisco support contract. And the alternatives are far more capable than NX-OS for our ops people.
I asked our Cisco representative to offer a competing quote against an HP networking deal, and he responded with a quote for Cisco servers, and Ironport mail filtering.
When I asked him what was going on, he pointed out that he only responds to bids he can win. I told him there were no servers in that opportunity, and he went on to discuss that, from a sales point of view, I have a better chance of pushing servers anyway, than pricing Cisco against HP networking. That's from one of their own guys, and it says a lot.
I doubt HP is losing a dime on their switch pricing, unless HP is even less efficient than I expect them to be. Other vendors beat HP handily on price with identical hardware specs. Cisco has gotten fat on ridiculous margins, and it's doubtful that they will be able to survive in a marketplace where merchant silicon drives commodity switches.
As I stopped knowing anything about datacenters around 2001, can anyone tell me what a network operating system is?
I am going to guess large high throughput switches and some degree of software defined networks that knock putting your printers on one C-network and your servers on another into a cock hat
Apart from raw power, is there some way I can reconfigure my network without moving a cable that I previously could not?
It provides open interfaces to interact with the switch through several means like OVSDB, REST API ... or CLI. OpenFlow is not supported yet although will be in near future.
Since it's open source, it also gives you the opportunity to run other agents in the switch control plane ... which is hardly possible with IOS or JunOS.
It's more about tenancy from what I understand. You can give unlimited people access to their own private, encrypted virtual 10.0.0.0/8 block all in the same data center and SDN makes that possible by encapsulating packets in another layer.
One area where a lot of smarts are needed needed, for example, is making sure that you're intelligently routing encrypted packets to the right machines without reverting to a broadcast to every router, switch, and machine in the DC.
I've also heard a lot about people running brand new untested protocols (like TCP replacements) right alongside traditional protocols through SDN.
I'm probably going to do a much worse job of explaining things than the guys who presented at the Open Networking Summit [1]. I highly recommend giving the keynotes a listen.
Edit: I do think this relates to SDN more than a traditional router/switch OS, based on the comments about "traditional and programmatic, declarative control plane." Either way, though, the link above is definitely good stuff.
This is a "me too" move by HP. Open network linux already exists, already uses ONIE, and is already a part of the open compute project.
http://opennetlinux.org/
/* Build hash key for a given vrf name and ip address */
static int
get_hash_key(char* vrf_name, char *ip, char *key)
{
sprintf(key, "%s-%s", vrf_name, ip);
return strlen(key);
} /* get_hash_key */
What could possibly go wrong?
Definitely not thinking hard about security over there.
Ha. Kind of like PHP's function name lengths being used as a "hash" back in the day.
But, what contexts is this function used in? Is it supposed to be one-way at all? If not, then this is just a simple way of distributing vrf/ip pairs into buckets. Still smells funny, though.
EDIT: This comment looks like I'm defending the implementation here. I'm not. Seems like it'd me more uniform to just add the bytes in the vrf/IP pair and mod them with something. Seeing a hyphen in the format string of sprintf() is really weird, considering that just he string's length is being used.
Again, assuming this is in no way security-related, then this is just a general, run-of-the-mill WTF.
An unchecked "sprintf" is a potential buffer overflow, especially in something like this where the input and output string buffers are parameters to the function.
I didn't even go looking for bad code. I was just curious to see what language they were using. This was near the top of the first file I looked at.
The code looks like C code circa 1990. If a first glance turned up this, what else bad is in there?
51 comments
[ 3.8 ms ] story [ 112 ms ] threadhttp://openvswitch.org/
You could run it on OpenSwitch as the program/module which talks with a controller.
https://www.sdxcentral.com/articles/news/pica8s-white-box-os...
Essentially, one of the aims of OpenSwitch is to build a cohesive API around a wide set of Linux networking tools and daemons, and build a broad community to make it happen.
http://www.openswitch.net/documents/user/hardware-compatibil...
$5,795.00
I could see us switching from Cumulus Linux to Open Switch, with that hardware support, and if Open Switch stays open source. We'd likely even pay for support, if cost competitive.
<disclaimer>I co-founded Cumulus Networks.</disclaimer>
[1] http://www.wired.com/2015/09/microsoft-built-linux-everyone-... [2] http://www.broadcom.com/blog/network-infrastructure/inside-o...
http://openswitch.net/documents/dev/quick-start
This hasn't been true for a couple years now, at least for top-of-rack and spine switches. White-box switches are now accessible to the general public, have low margins, and are not limited to huge purchasers like Facebook and Amazon.
I could see this getting traction if they announced it was compatible with some of the newer switches
And honestly, I really don't know how Cisco's Nexus line is going to survive at all. They will coast for a while on the population of Cisco certified engineers that don't want to learn new things, but it is literally cheaper for us to buy new hardware and support contracts than it is to renew our Cisco support contract. And the alternatives are far more capable than NX-OS for our ops people.
The Nexus line is effectively dead, as I see it.
When I asked him what was going on, he pointed out that he only responds to bids he can win. I told him there were no servers in that opportunity, and he went on to discuss that, from a sales point of view, I have a better chance of pushing servers anyway, than pricing Cisco against HP networking. That's from one of their own guys, and it says a lot.
I am going to guess large high throughput switches and some degree of software defined networks that knock putting your printers on one C-network and your servers on another into a cock hat
Apart from raw power, is there some way I can reconfigure my network without moving a cable that I previously could not?
(It's late, so just to be sure, I'm not trolling)
It provides open interfaces to interact with the switch through several means like OVSDB, REST API ... or CLI. OpenFlow is not supported yet although will be in near future.
Since it's open source, it also gives you the opportunity to run other agents in the switch control plane ... which is hardly possible with IOS or JunOS.
One area where a lot of smarts are needed needed, for example, is making sure that you're intelligently routing encrypted packets to the right machines without reverting to a broadcast to every router, switch, and machine in the DC.
I've also heard a lot about people running brand new untested protocols (like TCP replacements) right alongside traditional protocols through SDN.
I'm probably going to do a much worse job of explaining things than the guys who presented at the Open Networking Summit [1]. I highly recommend giving the keynotes a listen.
[1] https://www.youtube.com/user/OpenNetSummit
Edit: I do think this relates to SDN more than a traditional router/switch OS, based on the comments about "traditional and programmatic, declarative control plane." Either way, though, the link above is definitely good stuff.
Github mirroring will be set up in about week.
If you want a bad network solution check out the LG IPECS line of network gear.
This is just a land grab by HP.
https://git.openswitch.net/cgit/openswitch/ops-arpmgrd/tree/...
What could possibly go wrong?Definitely not thinking hard about security over there.
But, what contexts is this function used in? Is it supposed to be one-way at all? If not, then this is just a simple way of distributing vrf/ip pairs into buckets. Still smells funny, though.
EDIT: This comment looks like I'm defending the implementation here. I'm not. Seems like it'd me more uniform to just add the bytes in the vrf/IP pair and mod them with something. Seeing a hyphen in the format string of sprintf() is really weird, considering that just he string's length is being used.
Again, assuming this is in no way security-related, then this is just a general, run-of-the-mill WTF.
I didn't even go looking for bad code. I was just curious to see what language they were using. This was near the top of the first file I looked at.
The code looks like C code circa 1990. If a first glance turned up this, what else bad is in there?
In a review, I'd call out requirements for buffer overflow detection outside this function.
Just check Herb Sutter's talk at CppCon 2015, to the question who uses static analyzers, about 1% of the audience said yes.
Isn't this just another move to sell more switches?
Will there ever be code for some of the older MIPS based switches?