Heck yeah! Facebook's Open Compute Project is making an open source switch

Reblogged from GigaOM:

Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post
  • Click to visit the original post

The Open Compute Project, which Facebook launched a little more than two years ago, has decided that utterly disrupting the server and storage market isn't enough. On Wednesday, it said it would solicit input on an open source top-of-rack switch.

The project, in a presentation by Frank Frankovsy at Interop, said it was taking a slightly different tack with its design, deciding to get input from others before actually making and releasing the hardware to the community.

Read more… 884 more words

I'm hopeful of this white box approach to networking but cautiously optimistic. It would be great to put opensource software of openswitch like software on white box devices. While not SDN or Openflow directly it does give a great deal more capability to SDN type implementations. As the interface into the hardware layer is open and standard. My reservation is the ability to innovate at the hardware layer at the same pace you can now with proprietary operating systems. Who's going to invest in make a white box fabric that will compete with Cisco, Juniper and Arista? Top of the rack is a start but ultimately we'd like to see this in the core as well. I have a difficult time seeing open compete at the entire data center fabric level. I'm hopeful however that it will.

VirtualizedGeek Tech Talks Episode 11

It’s all about Virtualization.  That’s network vs. server virtualization.

Network Virtualization as I understand it

For some reason, I had a difficult time with the basic concept of Network Virtualization.  VMware equates network virtualization to Server Virtualization.  With server virtualization you can deploy an application to any physical server in your environment easily because the Server OS that the application resides on is abstracted from the network.  This gives you an incredible amount of flexibility operationally.  You can easily manage OS images, clone virtual machines, create entire test environments with almost a push of a button. It streamlines server deployments because you can now deploy servers based on templates with almost no regard to the underlying hardware.

I’ve done server virtualization long enough that I just get it.  It seems natural to this point.  What doesn’t seem as natural is Network Virtualization.  I re-read the VMware post announcing the NSX product and it all kind of just clicked for me.  I had a problem disassociating the physical access layer with the abstracted network component.  After all it makes sense that the device that the port is connected to is the device that controls the behavior of the device of the network.

Source VMware

Source VMware

The Physical Infrastructure really is just that that the physical infrastructure.  It’s the assurance that every device is physically connected to the network.  It can be via Token Ring, Frame Relay, Ethernet or ATM.  In theory it can even be a overlay network.  It really doesn’t matter from a logical perspective.  You have to ensure that the physical infrastructure is reliable and meets the latency requirements of your applications but that’s it (maybe a bit oversimplified).  Now that there is physical connectivity a solution like NSX can take over.  You create virtual ports and associate them to physical ports or other virtual ports on virtual switches.  These virtual ports can then be assigned to a virtualized Firewall, Switch, Router or IDS ports based on the need.

Cisco has a similar device level approach with their ISR architecture.  A port on an ISR router can be an IDS, Firewall or Router port as examples.  Network virtualization just takes the abstraction one level higher and broadens the capability of each individual port.  You now eliminate physical limitations of the device and virtualization the capability of the port.

The virtualized network devices can then have all the characteristics we associate with server virtualization.  They can be cloned, copied, vMotioned, DRS’d and snapshot.  Many of the operational advantages associated with server virtualization is now available to us on the network.  The only requirement again is that there is physical connectivity and VMware is able to do the easy part which is create a network Hypervisor capable of creating the robust abstraction layer needed to manage all of these dynamic ports.  I can see a pretty significant challenge in creating a high speed/low latency fabric.  I can also see where troubleshooting physical vs. logical performance will be a challenge.  However, these were some of the same challenges server virtualization faced during the early years as well.

I haven’t been excited by networking since I got a sample loaner Gigabit switch back in 2001 from Cisco.  This is actually a pretty big deal and I look forward to seeing a shipping product from VMware and customer feedback.  Your thoughts, is this a operation model that translates to your network?

How long can Cisco and VMware be friends?

I’ve always felt kind of uneasy about the Cisco/VMware relationship.  Server hardware provider’s have to support VMware because consolidation and management based on virtualized compute has become a no-brainer.   This relationship has allow hardware companies to continue to sell servers by add value to the VMware stack.  Likewise, VMware is pursuing Network Virtualization with full steam.  Network Virtualization doesn’t have the same driver in the form of consolidation but they do in operations.  

In this guest post over on SearchSDN, I ask the question is Will the VMware-Cisco Relationship Become Irrelevant? 

http://searchsdn.techtarget.com/feature/Will-the-VMware-Cisco-partnership-become-irrelevant

Network Virtualization vs. SDN

Scott Lowe was a guest on the latest episode of VMware Community Podcast and was discussing Network Virtualization.  It was a can’t miss episode of the Community Podcast.  Scott Lowe is probably one of the most technically diverse and deep cross discipline experts that I’ve read.  He has deep experience with both Networking and Server Virtualization.  He was a guest on the podcast to discuss Network Virtualization.  I posed the question in the live chat on the difference between SDN and what VMware is defining as “Network Virtualization.”  I’ll get to his response on my question in a second.

The host John Troyer brought up the argument that most networking professional bring up when discussing ”Network Virtualization.”  The claim is that virtualization already exists in network technologies.  You have VXLAN, VLAN’s and network overlays.  Scott did a great job of explaining that while these technologies virtualize transport of the network they don’t actually change the operation model of networking.

As he explained when you examine the benefits of server virtualization the main benefit outside of consolidation is the change in operations.  Done right, server virtualization can allow you to completely change the way you deliver and manage your compute and storage to an extent.  I like to say virtualization is like the DVR.  You can record, pause and rewind your server operations since they are abstracted from the physical hardware.

Network virtualization is similar to server virtualization as it lets you abstract the operations of your network from the physical access layer.  Configurations can be recorded, copied, paused and rewinded.  They way you provision and manage your network is completely changed by network virtualization.

How is this different from Software Defined Networking or SDN?  I think VMware (who Scott works for) would like you to consider SDN as just the abstraction of the control plane from the physical plane.  So in theory you could have SDN run inside of a virtual network controlling that control plan of the virtualized network.  I believe the industry outside of VMware is defining SDN in a broader sense.  When you think of the other Software Defined data center components such as storage its all about abstracting the management and presentation of these services from the hardware.

So, the difference between SDN and Network Virtualization depending on who you are asking.  A VMware network guys would tell you SDN is about abstracting the control plane while Network Virtualization is about abstracting the entire management layer of the network including SDN.  While some others would tell you that Network Virtualization is just another way of saying SDN.

He did make a statement that makes me wonder about the future of Virtualized Networks vs. SDN.  My vision of SDN would be that the application is aware of the underlying SDN based network.  The application can make a call to the control plane to give requirements for a connection and the SDN controller will make the appropriate pathing and connectivity decisions.  Scott missioned the similarity of applications deployed on vSphere with application deployed on a VMware Virtualized Network.  The application and server would treat it just like any other network it has physical connectivity.

I’m looking forward into learning the nuance differences between the two definitions and operation.

Either way I highly encourage you to listen to the podcast.  Well worth the hour.

Cisco Distributed Nexus 1000v closer to reality in Hyper-V

Cisco Distributed Nexus 1000v closer to reality in Hyper-V

 

One of the major differences between vSphere and KVM, Hyper-V and XenServer has been the ability to integrate 3rd party distributed switches.  VMware vSphere has had the ability to support Nexus 1000v for a few years now while it has been “coming” to Hyper-V for awhile now.  Well I missed the announcement of the public beta for Nexus 1000v on Hyper-V.  The below Cisco blog gives some detail of the state of their distributed switch in Windows Server 2012. 

Vive la Nexus 1000V on Microsoft Hyper-V!.

VirtualizedGeek Tech Talks Episode 5

Episode 5 is all about SDN since you guys can’t get enough of SDN talk.

Network as a Service as I wished it

Cisco really doesn’t like SDN

 

Surprise: Cisco doesn’t like SDN

CiscoSome pretty interesting quotes from Cisco’s CTO’s reveals that Cisco will try to leverage their dominance in enterprise networking to try and stave off the challenge of SDN.  In a NetworkWorld article Cisco’s CTO is quoted as saying:

“We see the network as a platform where applications can be programmed, where information can be processed and where data and business processes can be much more efficient”

To me this sounded very similar to the overall goal of SDN.  However, Cisco isn’t looking to separate the control plane from the hardware but use protocols and basically an API to allow two way control from the network and application layer.  The control plane would still exist within Cisco’s hardware layer which would allow them to maintain their dominance.  According to the article they are looking for enterprise partners to help drive the requirements and testing of the concept.

I think the argument for SDN still exists by leveraging the program interface as just another feature managed via a centralized control plane.  Just like any other hardware based improvement is given new API’s and Management tools in an OS this programmatic network would just be an option that is abstracted by SDN.  I would say that Cisco is fighting a losing battle but they have customer’s ears and could push this strategy while SDN is still forming; much like other standards they’ve pushed while the industry took time to settle.

I’d encourage you to read the article at NetworkWorld.  It was very enlightening to know where Cisco is headed versus where the primary discussion has been for managing the future enterprise data center.

 

Trainsignal Video Training

I just signed up for Trainsignal Video Training.  I’ve used their Cisco CCNA product in the past and thought pretty highly of the product.  I have to renew my CCNA and discovered they have gone to a subscription model of $49/mo for all you can eat training which is an outstanding offer.  I have the technical goals of renewing my CCNA, obtaining my VCP and learning more Linux.  Their training fits nicely.  If you are interested in a free offer trail you can follow the link here.  Disclaimer: I do get credit off my subscription for following the link.

How I picture Network as a Service and SDN (here’s an idea for Google Fiber)

So, NetworkWorld ran a story on a solution from startup Pertino’s Network as a Service (NaaS).  It actually sounds like a pretty cool solution that’s very simple to setup.  The backbone of the solution uses a SDN based control plan that runs on AWS.  This solution is as Cloud as Cloud gets.  However, this isn’t what I picture when I think of NaaS.

I’ve always pictured NaaS as being the ultimate marriage between SDN and Cloud computing.  I pictured a scenario where you’d have a hyper-fast connection to a telco network.  I’m thinking something along the lines of a Google Fiber connection to a home or business.  This part of the solution is the only manual provisioning that would need to be done.  You have to have some type of access layer after all.  From this point forward everything else would be managed by next generation SDN that really doesn’t exist today.

You would be able to go to a NaaS provider which could be a completely virtual company like Pertino that has for a lack of a better term SDN peering relationships with all of the backbone providers.  You’d be able to build on demand networks between as many sites as needed with a speed and class of service based on your application needs and budgets.  This service could even have an API that builds and tears down networks like AWS instances.  The key in my approach is the high bandwidth access layer provided by Google or whatever last mile provider you have available.

From a billing perspective, you would pay an access charge to this local telco but your NaaS provider would handle all of the intermediary charges based on your class of service.  You could in theory have multiple NaaS providers our switch NaaS providers one day to the next.  Some form of SDN has to be in play to make all of this work as seamless as it sounds but to me this is the true promise of SDN and NaaS.

I’d be interesting in what you’d consider as NaaS or even what you think of my interpretation of NaaS and SDN.

Follow

Get every new post delivered to your Inbox.

Join 284 other followers

%d bloggers like this: