Category Archives: SDN

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!

Challenges that Plexxi Faces

This week, the Lean Startup conference was held in San Francisco. The Lean Startup philosophy borrows its roots from the lean management method of manufacturing, with Kanban or Just-in-time processing at the center of the design principle. It basically advocates startups to minimize outside funding, not strive for the perfect product (think Minimal Viable Product), be flexible (think Pivot), and cater the product completely to the customer’s needs, all with the goal of being a highly efficient company.

However, as noted investor Marc Andreessen, who spoke at the conference, warns,

Not all startups can be Lean Startups

Indeed, some startups cannot afford to employ a Pivot. Infrastructure or hardware companies come to mind, especially when they’ve already taken $50 million of investment. This is what Plexxi has done without a complete solution to show for yet.

I was listening to the recent Packet Pushers show #126 sponsored by Plexxi. While their approach is a creative one, I’m not sure whether it is viable. In a nutshell, Plexxi brings optical technology, in the form of WDM, to the Data Center and flattens traditional hierarchical network designs. When I first started learning about network designs, the classical approach was the 3-tier Core-Distribution-Access model. In the mid-2000s this got reduced to a Collapsed Core. What Plexxi proposes is a flat topology, eliminating the need for Core switches in the Data Center.

Plexxi adopted the SDN approach of a programmable controller (a virtual appliance) that pushes policies to its switches. The policies are intended to optimize data path flow for affinitized traffic. Applications that are more sensitive of certain resources are classified in Affinity Networks. Some example of the constraints or sensitivities that Plexxi’s Director of Product Management, Marten Terpstra, described include:

  • Hop-count
  • Bandwidth

Plexxi switches use merchant silicon (Broadcom ASICs) to form an Ethernet ring on top of a WDM lightwave. By changing lambdas, Layer-1 connections between switches can be changed according to the application requirements.

Plexxi uses their own closed APIs for communication between their switch interfaces and their controller, in order to convey their message of affinities. However, they open up their proprietary northbound API for user-to-controller communication so users can write scripts, for example, by using REST APIs. Interestingly, they are a member of Open Network Foundation. The Controller places TCAM entries in switches based on application requirements for affinitized traffic.

Terpstra discussed two use cases:

  1. Affinitized iSCSI traffic for most bandwidth with least number of hops
  2. Cloud provider – Use a Plexxi ring as a premium service to affinitize traffic.

In neither case are the results mentioned.

Okay, so so far Plexxi’s solution is a 1 RU box that can prioritize traffic based on hop-count and bandwidth. I fail to see much of a business case there. Any network engineer worth his or her salt will tell you that there is more to traffic classification and prioritization than just hop-count and bandwidth. Financial trading institutions would be more concerned about latency guarantees. Hop Count alone is a flimsy criterion to classify important traffic, regardless of whether a cute term like Affinity Network is given to that classification. High Availability is a critical issue that a ring topology exacerbates. As Doug Gourlay of Arista mentions, unnecessary downtime is introduced any time you add new nodes because the ring is broken. Moreover, the network is reduced to a split brain model in the even of just two nodes going down. Depending on the Controller placement, this could have adverse outcomes. The thing about outages is that we can never control where they occur. Gourlay rightly puts it:

I thought Token Ring died for good reasons… why is someone trying to bring it back?

Getting back to the Lean Startup idea, Terpstra said “Our Layer-3 affinities are coming”. Plexxi is targeting Christmas 2012 for 1.0 version of Layer-3 capabilities. Until then Plexxi only has a Layer-2 switch with no quotable value to show for $50 million in investment. Not a good time to Pivot.

Reports of the death of the Core switch in the Data Center have been greatly exaggerated.

SDN – What’s in a Name? Part 3

This is the third part of my series of posts on trends of vendors to latch on to the SDN bandwagon. For more information, refer to parts 1 and 2. In this post I discuss how a few of the services vendors have responded to the buzz around Software Defined Networking.

WAN Optimization

Riverbed claimed it was riding the SDN wave at VMworld 2012 when it announced its latest release of Cascade. However, they went by the second definition I used in Part 1, which says that SDN decouples physical and virtual networks or overlays (not Control Plane and Data Plane as the other definition emphasizes). The difference is subtle. Riverbed partnered with VMware to develop the IPFIX record format that can provide VXLAN tenant traffic information as well as VLAN tunnel endpoint information. Thus, they claim, Cascade is SDN-ready because it is VXLAN-aware.

Silver Peak also pumped its chest at VMworld 2012 with its Agility announcement, which is a plug-in for VMware vCenter. Agility allows administrators to enable acceleration between workloads within vCenter using the vSphere interface that server administrators are familiar with. This requires Silver Peak’s Virtual Appliance to already exist within vCenter. Almost three months after the announcement, details are extremely thin. Silver Peak has been drooling about Nicira ever since the SDN champion was acquired by VMware. Indeed, all you have to do is Google Nicira and Silver Peak and observe all the enthusiasm that Silver Peak has shown for Nicira. But the feelings are not mutual. Silver Peak claims it is working with Nicira and leveraging Nicira’s Open vSwitch, but Nicira/VMware have made no such announcements. In fact, there are no further details about this relationship on Silver Peak’s own website.

Exinda is so far behind on the SDN learning curve that the only mention of SDN on its website is a hyperlink to the SDN Wikipedia page in a blog post written by the VP of Marketing that reported his observations from Interop 2012. Clearly Exinda has a long way to go before its SDN strategy can be taken seriously.

Load Balancers

As of VMworld 2012F5‘s Big-IP products can support native VXLAN functionality and will be have VXLAN virtual tunneling endpoint capabilities in the first half of 2013. What that exactly means is vague at this time. The press statement I linked to is the only mention of Big-IP’s current SDN capabilities. My guess is that they’ve opened up some APIs to VMware to allow programmability.

Embrane uses an under-the-cloud approach of offering cloud providers a platform that delivers elastic Layer 4-7 network services to their customers. The services include Load Balancer, Firewall, and VPN. Embrane’s heleos architecture is a radical solution that comprises the Elastic Services Manager (a provisioning tool) and the Distributed Virtual Appliance, the latter being a logical network services container instantiated across a pool of general-purpose x86 servers. The issue likely to raise eyebrows is that each service that is part of their platform is a wrapper around an open source distribution. I haven’t heard of too many providers willing to vouch for ipchains as a Firewall.

Firewalls

Palo Alto Networks earned its stripes by making its firewall appliances with merchant silicon. To  stay ahead in the SDN era, it announced a technology partnership with Citrix in October 2012, but has not yet released a product offering.

Big Switch Networks, a leading SDN player, announced, on November 13, 2012, its ecosystem of Technology Alliance Partners that included Palo Alto Networks. However, Palo Alto Networks has not mentioned this on their website, which is odd given that partnerships are what have made Palo Alto the hugely successful company it is today. One would expect them to be on top of it.

So there are no SDN-friendly firewalls currently on the market other than Cisco’s Nexus 1000V portfolio, which includes VSG and ASA 1000V Cloud firewall.

Summary

It appears, from these observations, as though partnerships are key to ousting incumbents in the SDN world. Much of SDN support at this time is just hype, but sellable products will come out soon. The industry also needs the open source movement to challenge the VMware-centric ecosystem to enable a higher level of interoperability and allow for more flexible orchestration and programmability. OpenStack is that approach. More to follow in future posts.

SDN – What’s in a Name? Part 2

In Part 1 of this series I outlined two of the more commonly accepted definitions of SDN. In this post I discuss how pure play networking vendors have tried to create solutions and package them as SDN.

Cisco announced onePK, a developer kit for their new Open Network Environment (ONE), which, in turn, they announced at Cisco Live this year. onePK is yet to actually be released as of this post. It essentially is a set of APIs that developers can use to interact with their Cisco gear instead of the Northbound and Southbound APIs that I referred to in Part 1. In the onePK APIs, an Open Flow agent can run in IOS, IOS XR, or NX-OS as speak with an Open Flow controller on the ‘north’ side and the openPK API on the ‘south’ side. As you can surmise, this leaves the Control Plane and the Data Plane still in the Cisco device. The reason for Cisco to do this are quite clear: Cisco feels threatened by SDN’s potential.

The biggest networking news item in 2012 was VMWare’s $1.26 billion acquisition of Nicira. Nicira was, after all, the pioneer of Open Flow and the SDN movement. People began to realize that after a decade of slow progress, networking was finally growing up. It manifested the networking industry’s readiness to keep up with server virtualization. However, that didn’t mean that VMWare started outselling Cisco overnight. Contrary to popular belief, the biggest revolution to hit the networking industry in the past five years is not Software Defined Networking. It is the advent of merchant silicon.

Merchant silicon is the reason why firewalls such as Palo Alto Networks, WAN Optimization Controllers such as Infineta, and data center switches such as Arista can exist. By using off-the-shelf silicon, they can deliver superior value by focusing on software. Pure-play giants like Cisco, who have invested a lot time and money in custom ASICs, are seeing their margins plummet because competitors can offer comparable value for much lower prices. Recently, Alcatel-Lucent outbid Cisco by $100 million to win a network infrastructure refresh project with the 23-campus California State University. Clearly trends like SDN, VM mobility, or DCI are not high priorities for everyone.

The insecurity that Cisco feels from SDN is the reason they want to to remain at the center of the ecosystem. With Cisco onePK, control remains on the Cisco device as Omar Sultan of Cisco describes. Thus, the controller that communicates with an Open Flow agent is quite different than the centralized controller envisioned by the Open Network Foundation (ONF). Cisco will make several announcements of other environments, platforms, and products that are iterative changes in reality to demonstrate that they are playing along. However, they will not release control of their market share by, for example, making a dumb switch running an Open Flow agent, and whose forwarding tables can be manipulated by standards.

In October 2012, Cisco acquired vCider as part of their SDN strategy, specifically to enhance their involvement in OpenStack. Of course, there is also a Cisco spin-off Insieme, now rumored at over 150 employees dedicated to building SDN solutions and platforms from ground up.

Brocade, another pure play networking giant, claimed their November 2012 acquisition of Vyatta was an SDN win. Brent Salisbury agrees. However, as Greg Ferro put itthe products are not SDN today.

In Part 3, I will wrap up this series of posts on vendors who have claimed SDN compliance by  discussing some vendors that focus on Services, such as WAN Optimization, Firewalls, and Load Balancers.

SDN – What’s in a Name? Part 1

Software Defined Networking (SDN) has been around since 2011 or so and, along with network virtualization, is the networking industry’s response to server virtualization, which has been around for much longer. Despite being such a hot topic in forums, there is unfortunately a lot of uncertainty as to what SDN actually means, let alone what vendors promise to deliver. What SDN is depends on who you ask. It is comforting to know that at least the acronym is defined as the Security community has been calling for Security Defined Networking!

One of the more commonly accepted definitions of SDN is that it is the separation of the Control Plane and the Data Plane enabled by a centralized Controller. Under this definition Southbound APIs are needed between the Controller and the switches. Well known examples are OpenFlow and NETCONF. Likewise, Northbound APIs are needed between the Controller and the users. However, as Ivan Pepelnjak mentions, there are no Northbound APIs defined yet. Commercial (e.g. HP, NEC, and IBM) and Open Source (e.g. NOX and POX) Controllers already exist today. Whether they are actually shipping or have only been announced are defined on SDN Central.

Another way of thinking of SDN is that it is a programmatic way of isolating Virtual Overlay Networks from each other and from physical networks. In other words, SDN extends Virtualized Data Centers and Virtual Overlay Networks, thereby ensuring VM mobility in a scalable manner. (Overlay networks themselves are not new. The Internet itself started as an overlay layer to PSTNs. Ironically, fast forward a couple of decades and now VoIP is overlaid on IP networks.) Virtualized networks need overlays to support multi tenancy and VM mobility (elastic demand of virtual machines). Under this definition, the programmability that SDN offers can enable VM mobility in a flexible and agile manner. Common use cases of VM mobility are bringing up entire Data Centers during rolling brownouts, and being able to launch Dev Test environment on the fly.

As you can see, the definitions have nothing to do with each other. However, people try to find commonalities in them. In parts 2 and 3, I will detail the approach taken by some networking vendors to claim their SDN compliance.