Hello HP. I’m RFC 1925 Compliant.

RFC 1925 – The Twelve Networking Truths is one of the less technical RFCs that are cited by the networking community. It is perhaps best known for the pigs statement, Truth #3:

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.

My favorite, however, is the one that follows it, Truth #4:

Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.

I interpret that as what makes for a successful product manager. Within networking I’ve been a Developer, a Support Engineer, a Consultant, a Network Engineer, a Technical Marketing Manager, and, most recently, a Product Manager for a startup. And now I’m very proud to share the news of my appointment as a Product Manager at Hewlett Packard. I’ll be owning the lifecycle of HP’s Campus products portfolio. HP Networking sponsored a recent Packet Pushers show and is one of the pioneers of commercial SDN solutions. In my new role I’ll be focusing on tackling the challenge of BYOD and VDI in the ever-changing Campus networking environment. Exciting times ahead!

Advertisement

Collaborating with the Networking Community in the Age of Information Overload

Literally speaking, 2012 was the hottest year in recorded history, though there will always be climate change deniers. From the perspective of networking as well, it was a very hot year. Dozens of vendors are battling it out to claim their share of the SDN pie, a market, which IDC expects to grow to $3 billion by 2016. With IAAS/Cloud finally living up to the hype it generated five years ago or so, we are truly in a golden age of innovation in networking. Greg Ferro often says that the last time networking saw such excitement was when MPLS was introduced. However, MPLS was always a Service Provider solution and just a direct replacement for Frame Relay and ATM. If you ran a mid-size Enterprise network or an SMB, the chances are that you wouldn’t need to worry about MPLS. Some have argued that MPLS can be run in the Data Center, but the number of implementations is quite few. More importantly, MPLS had no consideration about the type of applications that it was transporting. SDN, on the other hand, with its Northbound API, is completely application-aware. With all the monumental changes happening in networking nowadays, it can be rather overwhelming trying to keep up just by reading blogs and newsletters. In this post I’ll outline three ways of collaborating with the networking community.

Packet Pushers, which the aforementioned Greg Ferro co-hosts along with Ethan Banks, is the premier podcast show for getting the scoop on trends in the networking industry. It features quality professionals, many of whom maintain their own blogs or are active on Twitter. Packet Pushers has a handy forum where you can ask questions on just about anything and can interact with like-minded networking professionals in the virtual meeting room. Greg and Ethan complement each other very well. While Ethan is more in tune with the more day-to-day activities of a network engineer, Greg is generally more active in promoting the discourse for newer technologies, such as the OpenStack Quantum project. The shows generally tend to be more in favor on Data Centers and SDN than, say, VoIP or Wireless, but thanks to the forum, listeners can chime in with their preferences for upcoming shows.

SDNCentral was launched in January 2012 as means for people to educate themselves on the SDN market and it does a wonderful job at that. One of the website’s features is the SDN Trending Index, which measures the most popular SDN companies, based on SDNCentral community activity. This is a clever way to gauge how hot a new SDN vendor is. A more recent feature of SDNCentral is the Demo Friday series in which an SDN vendor demonstrates their product. At the time this post is published was the second in this series – Cloud-enabled Networking–NEC ProgrammableFlow SDN in Action. The first in the series was Plexxi and Boundary. I had written about Plexxi after listening to them in a sponsored Packet Pushers show. I have since softened my stance on them thanks to the demo, which showcased Plexxi’s optically-connected switches built around a closed, controller-based architecture. I was impressed with how it flattens the network and how it can co-exist with legacy network designs. Indeed, it would be difficult to survive nowadays with a rip-and-replace strategy. From SDNCentral: Boundary applies analytics against real-time network flow data to enable Application Performance Management without the need for appliances or tap/span ports. The demo showed how Boundary discovers real-time application topology and monitors application throughput, latency, packet retransmits and other metrics on a per second basis. In other words, it is Software Defined Monitoring. Without SDNCentral, I probably would not have learned about Boundary or appreciate the value Plexxi can offer.

image
Ben Pfaff speaking at the Bay Area Network Virtualization Meetup at Hacker Dojo on March 20, 2013

Meetups provide an excellent opportunity to learn by interacting with real people in a face-to-face environment. In the San Francisco Bay Area, there are a few meetups that are bringing a sense of community to the networking industry, fueled by the Open Source movement. It wasn’t like this between 2000 and 2010. Hackathons were traditionally associated with only developers, not networking folks. This week, Nicira’s Ben Pfaff spoke at Hacker Dojo of the past, present, and future of Open vSwitch, which he helped create. He showed a live demonstration of how OVSDB, the configuration tool of OVS, works. I met some of my former colleagues and other peers who I normally interact with online. Nowadays, in the SF Bay OpenStack meetups led by Mirantis and Sean Roberts from Yahoo!, attendees bring their laptops and help each other through the OpenStack installation and configuration process with DevStack. Similarly, the Bay Area Network Virtualization meetup offers a fantastic opportunity not only to learn about OpenFlow and Open vSwitch, but also to mingle with fellow practitioners. However, meetups are not limited to the San Francisco Bay Area. In a recent Packet Pushers show, Kyle Mestery, one of the original team members of the Nexus 1000V, mentioned that an OpenStack meetup has also started in Minnesota. Meetups tend to catch on like wild fire. Hopefully we’ll see many more that cater to open networking.

These are healthy signs of a growing industry with plenty of people willing to help out and give back to the community.

OpenStack Cloud Adoption Picking Up

I was listening to the recent Packet Pushers podcast Show 138. HP, who sponsored the show, spoke about HP Cloud, a public cloud that is built on OpenStack. It was launched in May 2012 and made generally available in December. HP is taking Amazon head on in the cloud provider space (at least when it comes to SLAs) as the GM of HP Cloud Services puts it. HP Cloud comprises multiple availability zones, identity management, account management, block storage (ala AWS S2). Compare that with the Cisco Edition of OpenStack, which is just a validated deployment, tested on Cisco’s UCS servers and Nexus switches only. In other words, Cisco does not offer an Enterprise-grade cloud like HP or Amazon do.

And now you can throw IBM’s name into that hat. This week IBM unveiled a new cloud offering based on open cloud standards, including OpenStack, that significantly speeds and simplifies managing an enterprise-grade cloud. IBM, like HP, is one of the founding members of OpenStack and is launching this OpenStack-based public cloud offering in beta mode about one year after HP did with general availability expected later this year. Amazon is famous for it’s low price structure and it will be a challenge for HP and IBM to compete.

Mirantis, a 13-year old company with a history of strong professional services has immersed itself into OpenStack consulting and training in the last couple of years. They help service providers and enterprises build and deploy OpenStack cloud infrastructure. Some of their customers include NASA, Dell, AT&T, and Cisco. Another customer, Internap, launched its OpenStack-based public cloud service back in October 2011 and was assisted by Mirantis. I installed OpenStack in a personal lab at home and encountered several obstacles along the way. It is not easy to set up. For simple lab installations, DevStack is a good option. However, for production deployments, there is a lot of complexity that needs to be understood and overcome for enterprises to deploy clouds. Companies like Mirantis help bridge that gap.

OpenStack Lab Installation with DevStack

I have been experimenting with OpenStack in a personal lab at home. My motivation has been to get some hands on exposure with Quantum. OpenStack is definitely not a trivial task to set up. I have built it with DevStack, a script that builds complete OpenStack development environments, and have encountered a few bumps along the road. The first one was of package dependencies. I have learned that unlike on our personal laptops running MacOS or Windows, when running a Linux server, such as Ubuntu, patching the kernel to the latest release is not always a good idea. In the case of DevStack, I ran into package dependency errors, which are a nightmare to resolve. There is no general consensus on forums for how to mitigate them.

The only way I was able to get around this was to run the DevStack script with an unaltered kernel from Ubuntu 12.04 LTS. That means no running of ‘apt-get update’ followed by ‘apt-get upgrade’. I was able to get OpenStack successfully running with Kernel 3.2.0-29, which is what Ubuntu 12.04 LTS comes with natively. I’ve attended a few OpenStack meetups and my experience is consistent with those of other attendees who I have interacted with. In hindsight, it is not surprising that DevStack broke because OpenStack has so many constant code changes and moving parts. DevStack, which pulls the latest release from Git Hub, is likely to break if a major variable change, such as kernel upgrade, is introduced.

I got some help from the inimitable Brent Salisbury, whose blog posts have come in handy on several occasions. Next I plan to add customizations to my OpenStack installation, such as adding Quantum plug-ins rather than using nova-network.