All posts by Umair Hoodbhoy

What is PLUMgrid up to?

PLUMgrid is a Silicon Valley based SDN startup that raised $10.7 million in Series A funding in August 2012. They are still in stealth mode and even SDNCentral hasn’t covered much on them yet. However, things are brewing at this startup, which was mentioned last year in the The Economist and featured in Network World. Details are still thin, but when a company publishes five teaser blog posts in the past two weeks (they started their blog in August 2012), signs point to a larger announcement around the corner.

Their blog posts are unlikely to win a Pulitzer prize. If anything, they have enhanced their mystique by keeping things vague. PLUMgrid shuns the term Network Virtualization as it encompasses legacy technologies, such as VLANs, VRFs, and VPNs. Instead, they like to refer to Virtual Networking Infrastructure (VNI) as the means (i.e. abstraction) to provide a Virtual Network Domain, which they define as an administrative boundary established by the Data Center Operator where the VND operator can: Define, instantiate, and manage its own network needs. PLUMgrid defines SDN as networking technologies that create value in the VNI. Moreover, they wrote of consumption models in a manner that would make unicorns cry. A more concrete set of definitions would have helped.

PLUMgrid wrote of Distributed Virtual Switches:

Datacenter admins are quickly realizing that as appealing as DVS may be, Virtual Broadcast Domains (aka Distributed VLANs) are restrictive when designing proper networking solutions. To overcome the limited capabilities of DVS, multiple vendors are providing solutions pointing towards two different vectors.

I would have liked them to elaborate further on this point. How exactly do data center admins find DVS’ restrictive? Is it the lack of control plane? Is it the presence of Multicast state in the core of the network. I want to know what PLUMgrid’s solution offers that, say, Nicira’s STT doesn’t. They have refrained from describing the problems in their posts.

On point that PLUMgrid made in their blog series that caught my attention was when they wrote this of VNI:

VNI platforms should be open to a rich ecosystems of 3rd party network functions: Prevent vendor lock-in.

To me that sounds like a plug-in to OpenStack. In fact, I wouldn’t be surprised to see PLUMgrid’s name listed as a member the new open source SDN Consortium called Daylight, which will be announced at the ONS summit in April 2013.

Are they the Secret Company that will come out of stealth mode and present at Networking Field Day 5 March 6-8? Only time will tell.

Edit: I listened to the Open Networking User Group (ONUG) Lippis Report Podcast this morning and PLUMgrid’s CEO, Awais Nemat, reiterated the need to define new vocabulary for SDN ecosystem, such as VNI. He said that the concept of Cloud only started making sense to people once SAAS, IAAS, and PAAS were clearly defined. Based on conversations it has held with customers, PLUMgrid has its eyes set on Consumption Models as compared to Build Models, which the rest of the industry has been focusing on (Northbound/Southbound APIs, CP/DP separation, etc).

South Bay OpenStack Meetup – Where are the Networkers?

Just a quick note before the weekend. Yesterday I attended a South Bay OpenStack Meetup organized by Mirantis, a provider of OpenStack services. Over 100 people had RSVP’d for the event, which was held on Yahoo!’s campus. About 50 attended.

The event featured an introductory presentation by Mirantis on the OpenStack architecture and featured excellent coverage on the messaging between the various components and APIs. Co-resenting was Lee Xie, Senior Technical Engagement Manager from Mirantis, who had earlier in the day published a detailed, albeit subjective comparison of OpenStack versus VMware.

What struck me as amazing was the lack of questions and familiarity with Quantum, the networking component of OpenStack that has been out since Folsom was released in September 2012. I had never expected myself to be the only person asking questions about Quantum at an OpenStack event! OpenStack itself has been around since 2010 or so, and it is possible that most of the attendees had server and storage background. JSON, REST, Puppet, and Rabbit were the more fluid topics of discussion. I drew puzzled looks when I broached the subject of Floodlight and OpenFlow.

The meetups are scheduled for every other week with Beginners and Intermediate tracks held at the same time in different rooms. Maybe I’ll attend the Intermediate track next time.

Plethora of Cisco Cloud Announcements – February 2013

I’m writing this post the week after Cisco Live was held in London. I did not attend Cisco Live, but this morning I attended a Cisco event today titled entitled Fabric Innovations for the World of Many Clouds. It was kicked off by Cisco’s Chief Strategy Officer Padmasree Warrior who outlined the Fabric vision of the company at this time, which is summarized in the figure below.

February 4, 2013 Cisco Announcement
February 4, 2013 Cisco Announcement

The Nexus 6000 is a new product line with a super high 10/40 Gbps port density and hovering at 1.2 microsecond port-to-port latency. Available today, the 4RU Nexus 6004 has 48x40Gbps ports along with 4 expansion modules allowing for a total of up to 96x40Gbps ports. Also announced, but available in Q2, is the Nexus 6001 – a 1RU switch with 48x1Gx10G with 4x10G/40G uplinks.  Senior VP of Cisco’s Data Center Business Unit, David Yen, said that even Cisco could avail of merchant silicon, but that they still backed their own custom silicon to deliver lower port-to-port latencies, as seen in their Algo Boost technology. To give you an idea on how low 1.2 microseconds is in the industry, Arista has been boasting low-latency switches as low as 350 nanoseconds port-to-port for several years. But Cisco already has an answer for Arista’s ultra-low latency switches – the Nexus 3548 which boast port-to-port latencies as low as 190 nanoseconds. These are better suited for financial exchanges where low switching latencies are critical for conducting electronic trades.

Cisco claims it can scale the Nexus 6004’s 1.2 microsecond latency for as many as 1,500 10G ports. The number 1500 is attained when the Nexus 6004 is combined with another new product – the Nexus 2248PQ Fabric Extender. The last-named product can support 1500 GE or 10GE server ports through Cisco’s FEX technology. Assuming 50 VMs per server, this means that the 1500 FEX ports can support up to 75,000 VMs. This is an impressive number and shows the scalability of the Nexus 6000 platform.

The Network Analysis Module (NAM) has also now formally made its foray into the Nexus offering. I worked a lot with the first two generations of the NAM in 2004 and was impressed by its robustness (one of the few products at the time to be built on Linux) and ease of use. Of course, that was with the Catalyst 6500 platform, which was defribilliated a couple of years ago with the Supervisor 2T. It seems that Cisco is now finally bringing service modules onto the Nexus platform.

The second major announcement was the Nexus 1000V InterCloud for connecting enterprise clouds to provider clouds in a secure manner. The highlights are making application migrations incredibly simple without having to convert VM formats, create templates, deploy site-to-site tunnels between clouds, or re-configure network policies. The Nexus 1000V IC is intended to automate all these steps and support all hypervisors. It is managed by Virtual Network Management Center (VNMC) InterCloud. The highlight of that (to me) was that it hooks into cloud orchestration systems like Cloupia (Cisco’s recent acquisition) and Cisco’s own Intelligent Automation for Cloud (IAC) via a northbound API. Hybrid cloud deployment solutions are a relatively new area and I will be following how this pans out with great interest.

I was most keen about the third announcement, which was of Cisco’s ONE Controller. Last year Cisco announced onePK, but there was no product. Now finally, there is the Controller. It features northbound APIs, such as REST and OSGI and southbound APIs, such as OpenFlow and Cisco’s own onePK. Cisco also announced a roadmap for the ONE Controller’s compatibility with Cisco’s existing Nexus and Catalyst product line.

More information is available from the following links:

Introducing Nexus 6000 Series
Cisco Launches Nexus 1000V InterCloud Part I
Cisco Launches Nexus 1000V InterCloud Part II

Five Reasons Why Print Editions of Exam Certification Guides are Better Than E-books

In order to prepare for my CCIE R&S recert, and in an attempt to save trees, I bought the e-book (Kindle edition) of CCIE Routing and Switching Certification Guide, 4th Edition from Amazon.com. The print edition costs at least $20 more than the Kindle edition. However, after a few weeks of reading it on my first generation Kindle, I returned it to Amazon and bought the print edition instead. Here are the reasons why:

Continue reading Five Reasons Why Print Editions of Exam Certification Guides are Better Than E-books

Handling Kernel Updates with Open vSwitch

Last month I wrote how I built Open vSwitch 1.4.0 package on Ubuntu 12.04. Immediately afterwards I left my lab and when I returned to it, nearly a month later, I ran an apt-get upgrade out of habit. Consequently, the kernel got upgraded from 3.2.0-34 to 3.2.0-36 and I ran into the following error when starting the OVS service:

root@pakdude-02:~# uname -a
Linux pakdude-02 3.2.0-36-generic #57-Ubuntu SMP Tue Jan 8 21:44:52 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
root@pakdude-02:~# service openvswitch-switch start
 FATAL: Module openvswitch_mod not found.
 * Inserting openvswitch module
 Module has probably not been built for this kernel.
 For instructions, read
 /usr/share/doc/openvswitch-datapath-source/README.Debian
 FATAL: Module openvswitch_mod not found.
 * Inserting openvswitch module
 root@pakdude-02:~#

It turns out that this was because the kernel modules also needed to be updated. The following command did the trick:

root@pakdude-02:~# module-assistant auto-install openvswitch-datapath

I could have simply typed the following instead with the same consequences.

root@pakdude-02:~# m-a a-i openvswitch-datapath

As per the documentation, module-assistant aims to facilitate the process of building kernel modules from source. In other words, this needs to be run each time the kernel is upgraded.

Book Review – OpenStack Cloud Computing Cookbook

In December 2012, I participated in a contest on Scott Lowe’s blog and won a copy of Kevin Jackson’s OpenStack Cloud Computing Cookbook. I’ve been reading it to progress my OpenStack lab and have a few thoughts on it.

The most important thing to keep in mind about this book is that it is not about the design philosophy or goals of OpenStack. If you are looking for an OpenStack 101 book, this is not the one. It is very simply, a cookbook with precise recipes or tasks to set up and manage OpenStack cloud environments, and doesn’t pretend to be anything other than that. Hence, it is very difficult for it to be a meaningful and long-lasting book. This is unlikely to be on my bookshelves in a year or two. OpenStack has been evolving very rapidly and at the time the book was published, in September 2012, OpenStack came out with a new release – Folsom. The book was developed on the Essex platform, which was around April 2012. Folsom is a major release as it contains the Quantum networking component. Consequently, the book only covers Nova Networking (Chapter 10), which supports Flat networking, Flat networking with DHCP, and VLAN Manager. With, Quantum, users are presented a backend platform from which they can leverage plugins to pick network services from many vendors. Similarly, there is no mention of Cinder, the full-blown component that covers block storage. Instead, the book only talks about Nova Volumes (Chapter 8) for block storage support.

The OpenStack components present in Essex receive coverage in the following chapters:

  • Nova (Compute) – Chapters 1 (Starting) and 2 (Administering)
  • Keystone (Identity) – Chapter 3
  • Swift (Storage) – Chapters 4 (Installing), 5 (Using), and 6 (Administering)
  • Glance (Image) – Chapter 7
  • Horizon (Dashboard) – Chapter 9

Chapter 11 discusses how to provision OpenStack in Data Centers and discusses the tools and techniques for automating tasks. The absence of DevStack is notable here.

Chapters 12 and 13 cover Monitoring and Troubleshooting respectively.

Most of the 100-odd tasks are written in a three-tiered Getting ready / How to do it / How it works format. It is not a book you would read from start to finish; instead you would pick tasks that are important to you. However, though there are several screenshots and code snippets, there is not a single diagram, either block or network. This is another major shortcoming in the book. One would expect at least a few of the How it works sections to have diagrams to illustrate, conceptually, how the task was realized, such as the flow of packets between VMs in Chapter 10 (OpenStack Networking).

However, it is a good resource for monitoring and troubleshooting tasks and might serve your needs there. Otherwise, my biggest complaint of OpenStack Cloud Computing Cookbook was that it was largely obsolete on the day it was released.

My 2013 Goals

We are two weeks into 2013, so these goals might appear a bit late, but are better that way than never being made. I’m limiting these goals to the professional arena as most of the readers probably won’t care whether I learned French, took 30 wickets in my club’s summer cricket league, or learned how to make the perfect cappuccino.

With that said, here are the professional goals that I will strive to achieve in 2013:

  • Immerse myself in OpenStack and its Quantum component. Specifically, I want to build a cloud in my home lab and create complicated scenarios, including, but not limited to:
              • Create virtual Data Centers
              • Easily spin off VMs and move them across L2 and L3 domains
  • Build and configure Open vSwitch and a Floodlight OpenFlow controller to achieve the tasks above
  • Document my findings and release them to the public in easy-to-understand videos and screencasts.
  • Watch all of Ivan Pepeljnak’s webinars. So far I’ve only watched about a third.
  • Attain a working knowledge of Python via Codeacademy.
  • Recertify my CCIE status.
  • Play a major role in building a product.

I’ll revisit in about a year to see how I fared!