Category Archives: SDN

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.

Advertisements

Cisco ONE Controller – SDN Startup Killer?

Military nations demonstrate their power by testing nuclear weapons. Pure play networking vendors display their power in the SDN ecoystem by releasing Controllers. ~Anonymous

I sat in today on Cisco’s Webcast on OpenFlow and the ONE Controller. Cisco CTO, and Engineering and Chief Architect, David Ward spoke at length of this announcement. Ward is also the Chair of the Technical Advisory Group of the Open Network Foundation (ONF). The webcast featured two use cases – in the Enterprise (Indiana University) and in the Service Provider (NTT Communications) arenas.

OpenFlow Model
OpenFlow Model

A typical OpenFlow Controller, or Switch as defined by the standards, would interface to the Data Plane via OpenFlow Configuration Protocol, OF-Config, (persistent across reboots) and OpenFlow Protocol (mechanism for adding and deleting flows). But OpenFlow is just a part of SDN.

In a classical router or switch, the fast packet forwarding (data path) and the high level routing decisions (control path) occur on the same device. An OpenFlow Switch separates these two functions. The data path portion still resides on the switch, while high-level routing decisions are moved to a separate controller, typically a standard server. The OpenFlow Switch and Controller communicate via the OpenFlow protocol, which defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats. – ONF Website

Cisco ONE Controller Model
Cisco ONE Controller Model

The goal of Cisco’s ONE Software Controller is to enable flexible, application-driven customization of network infrastructure. It includes the onePK toolkit – an SDK for developers to write custom applications to solve their business needs. So, a ONE Controller could speak to other vendor devices via the OpenFlow standard or it could speak to Cisco devices via the onePK southbound API. At least that is what the diagram shows – onePK and OpenFlow are side-by-side. However, during the webcast Q&A, it was stated that onePK is an infrastructure that includes support for multiple abstraction protocol; onePK includes Openflow. This is probably semantic.

One of the features described is network slicing. It is intended to provide more than just L2 or L3 segmentation. It is more like a form of multi-tenancy. The way it was described on the call, instead of making decision based on just ‘shortest path’, network slicing can enable the controller to differentiate based on lowest cost path, highest bandwidth path, and latency. At a demo at Cisco Live in London, latency was tweaked and the Controller was able to compute a different path accordingly.

Another feature presented by Cisco in ONE Controller is of hybrid mode SDN, in which network operators can use SDN for specific flows and traditional integrated CP/DP (i.e. classical routers or switches) for the remaining traffic

What are the ramifications of this release on the SDN ecosystem? Well, although the new open source consortium Daylight supposedly does not include Cisco onePK on Day 1, it is very likely it will be included in about six months. Cisco has announced platform support roadmaps for the Platform APIs (onePK platforms), Controller Agents, and Overlay Networks such as VXLAN Gateway. Some of these won’t be available until Q3 of this year. That sounds just about the right time for a vendor to provide an end-to-end solution for Daylight. If a pure play hardware networking vendor, such as Cisco, can provide a free open source controller, it will be able to kill the competition from many SDN startups. For example, take Floodlight, the open source OpenFlow controller that was developed by Big Switch and is sold on a freemium licensing model. If ONE Controller is given away for free, why would a customer use Floodlight?

In other words, in Daylight there is no need for Floodlights!

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

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.