Archive

Category Archives for "Cumulus Networks Blog"

Linux for Network Admins: The Good stuff just got Better!

Man is a tool-using animal. Without tools he is nothing, with tools he
is all. – Thomas Carlyle
The most satisfactory definition of man from the scientific point of view is probably Man the Tool-maker. – Kenneth Oakley

The Artist and the Scientist both agree that tools are an integral part of what it means to be human. Even human history is divided into ages based on the power and sophistication of the tools: Stone Age, Bronze Age, Iron Age and now, Information Age. Our capabilities are enormously magnified by the tools we have at hand.

A server admin has the tools to manage 100,000 servers fairly easily, while the network admin struggles to manage a small fraction of that size of networking equipment. In the modern data center, where scale, agility and flexibility are part of its DNA, this lack of netadmin tools is a major hurdle in the operation of the data center. Subsequently, a big part of the transformation and turmoil in networking today is an attempt to get rid of this limitation.

Among the tools the server admin has at his or her disposal, automation is key.  It is impossible to manually manage devices at the Continue reading

Opening up VXLAN with OpenStack

VXLAN is hot. We constantly hear about VXLAN at conferences, in product announcements, blog posts, and most importantly, we hear about it from our customers.

VXLAN exciting technology that’s been integrated into a number of product offerings from networking and cloud vendors. OpenStack® supports VXLAN via a set of Neutron plugins, and Metacloud OpenStack® has supported VXLAN for a few releases already.

One of the challenges with deploying and scaling VXLAN has been the MAC-to-VTEP learning and BUM (Broadcast, Unknown Unicast, Multicast) packet flooding. The VXLAN spec uses a simple multicast solution to solve this problem. Multicast has its own set of scaling challenges, and reliable multicast routing between network segments isn’t always available. The majority of vendors who have VXLAN support have attempted to solve this problem by implementing their own form of learning and flooding. Some of these solutions work well, but all of them require you to operate in a homogenous network environment or pay expensive per CPU or per VM licensing fees.

Until today…

Metacloud, in partnership with our friends at Cumulus Networks®, have been working together on a solution to these problems for the past year. Starting today, VXFLD is open source and freely Continue reading

MidoNet for the Overlay, Cumulus Linux for the Underlay. Like Coffee and Cream.

VTEP is not the only way MidoNet customers can use a switch that runs Cumulus Linux as the underlay (physical network) for the virtual, overlay networks.

We’ve announced our partnership to work with Cumulus Networks earlier in 2014 to use Cumulus Linux as a Layer-2 VxLAN Gateway to bridge VLANs in the virtual network world to the VLANs in the physical world.

We’ve shipped that code as part of MidoNet version 1.6.

We now want to talk about how VTEP is not the only way MidoNet customers can use a switch that runs Cumulus Linux as the underlay (physical network) for the virtual, overlay networks.    Just don’t think of running a set of gateway switches as the only way to benefit from these devices, we see many opportunities and benefits.

Here are some examples why it makes sense :

Automation

Remember that Cumulus Linux IS Linux. It’s not a switch OS that just happens to be based on Linux.  It offers cloud automation capabilities that is so crucial to customers who are adopting to move towards building a Cloud. If you listen to Customers, Systems like Chef and Puppet are widely used in the deployment of systems like OpenStack, Continue reading

Lessons Drawn from the Rise of Server Virtualization

It has become common to draw analogies to the rise of server virtualization during the early-mid 2000’s to attempt to understand how network virtualization will change the way we build data center networks, both virtual and physical.

This is a useful tool, as there are clear similarities.

Server virtualization changed the amount of time it took to get a new compute resource up and running from weeks (order hardware, rack gear, install OS) to hours or even minutes.  It allowed location independence, so admins could start VMs wherever capacity was available, and move them around at will.

Network virtualization is starting to provide similar benefits to the network.  Creating a new virtual network can be done in minutes, compared to hours if we have to file a ticket with the networking team to provision a new VLAN and plumb it across a the physical network.  And the scope of VM mobility can be increased radically, as VMs are no longer bound by size-limited physical L2 domains.

But there is one place the analogy breaks down, at least with networking from OEMs with the traditional proprietary appliance approach.

First, let’s back up briefly and examine something I glossed over when talking Continue reading

So what if the tables wobble a little?

When I first met Cumulus, they were working out of a borderline-sketchy kind of warehouse space they had outgrown long before I showed up.

My job was to “make things better.” Initially, this had a lot to do with boxes and taking out garbage. I threw out a pile of flattened boxes about three feet high early on. The boxes had been stacked and tossed and shoved into a massive pile that consumed the small loft that hovered over the space. These people have no idea how dangerously close they came to becoming an episode of Hoarders.

Despite the mess, they are very good people. I’d been there only a short time when, one day, the bottom fell out of a box of stuff I was moving. Instantly I was surrounded by people who had everything picked up before I’d even registered what happened. One of them was on the phone the entire time and never missed a beat, I think he even made a sale. They were halfway back to their desks before I managed to say “thank you.”

I am not an engineer, but I am married to one, which is almost the same thing. (That Continue reading

Cumulus Workbench – a year of progress

cumulus workbench

At VMworld 2013, before the Cumulus Workbench was born, Cumulus Networks needed a quick way to demonstrate Cumulus Linux.

One of our amazing engineers, Nat Morris, quickly whipped up a VM (almost out of nowhere), meant to run on virtualbox, on a laptop with two interfaces. Voila! Cumulus Workbench!

For a first effort and for lack of time, this was awesome. However, there were a few limitations, as you would imagine – flexibility was an issue and new features required distributing an entirely new VM. Plus, for the latest version, you had to ask around. This would be fine for a quick demo, but we wanted more. We wanted it to be bigger and better.

We put some thought behind what exactly bigger and better meant to us and too that to the drawing board. From there, we built a framework and began to deep dive into the design and architecture. We wanted to build something useful for customers so that they would be able to see what they could do in their own environment. It was at that moment that the Cumulus Workbench was born, thanks to a lot of elbow grease and hard work from Ratnakar Kolli.  Thus, Continue reading

My first week working at Cumulus Networks: Beyond A First Impression

Working at Cumulus Networks – it’s probably the most fun I’ve had at a job in a really long time.

The narrow stairway at 463 (and a half) Bryant Street was my first impression of working at Cumulus Networks. Victoria opened the door, and I said, “Wow, this door is tiny and those stairs- what is this, a speakeasy?” I got the sly, dry smile that I have come to see as indicative of Victoria and was escorted inside to the conference room of what looked like an empty apartment turned into an office. There, I met Kathleen and we chatted for half an hour. It was one of the most informal, comfortable, genuine experiences I’d ever had in a job search.

“Do you think you can commit to working at Cumulus Networks a few months, understanding it’s sort of up in the air right now, the future of this office, etc.?”

“Yeah, I think so. I mean, unless I become like, a famous author over night, or something. Which probably isn’t going to happen.”

Victoria glanced at my resume. “It says here that you published a book.”

“Two, actually. But you know… that’s how I Continue reading

Cumulus Networks’ Open Source Contributions

Nearly everything we do at Cumulus Networks is open source. We stand on the shoulders of giants in our use of open source software, and so of course we give back everything that is legally ours to contribute.

We recently published a program that we wrote in conjunction with our friends at MetaCloud: the VXLAN Flooder, or vxfld. vxfld is the basis of our Lightweight Network Virtualization feature (new with Cumulus Linux 2.2!), as well as MetaCloud’s next generation OpenStack networking. It enables easy to deploy, scalable virtual switched networks built on top of an L3 fabric.

Of course, vxfld is just the latest in a series of contributions! There are projects we’ve written from scratch, such as ONIE, the Open Network Install Environment, which we contributed to the Open Compute Project. Like Prescriptive Topology Manager, which simplifies the deployment of large L3 networks. And ifupdown2, a rewrite of Debian’s tool for configuring networks that greatly simplifies large, complicated networking configurations.

And then there are our contributions back to the upstream projects that we include in Cumulus Linux. These include (in order of decreasing number of contributions) the Quagga routing protocol suite, the Linux Continue reading

Democratizing the Networking Industry beyond the Two Party System

When it comes to the networking industry and purchasing a network device, a user typically has two choices: Party D and Party R.

Sure, there are other parties out there, but they usually don’t make the ballot for one reason or another. Even when you are not a “hardcore” supporter of either party, you feel stuck in one of those camps since you cannot partially “vote,” much less mix-and-match, as both parties are incompatible with each other.

What if this doesn’t have to be the case?

In this new world democracy, what if you could apportion your vote in a piecemeal fashion? In essence, taking the bits from one party combined with those of another party to create a new candidate tailored for your needs.

For the last 18 months or so, the Open Compute Project (OCP) Networking Group has been further validating and accelerating the adoption of this new reality of a disaggregated network design where the network device is separated from the network operating system (NOS) that powers the device. At the heart of this is a little piece of OCP software called ONIE (Open Network Install Environment), a key innovation by Cumulus Networks and released Continue reading

Bare Metal Networking, Then and Now…

What a difference a year makes.

Just last year, bare metal networking was viewed as an aspiration for only mega-scale operators. A simple solution to enable any bare metal switch to operate any networking operating system was unavailable.

Original design manufacturers (ODMs) and bare metal networking vendors were relatively unknown entities. Pricing and product availability was obscure or difficult to ascertain. The supply chain for bare metal networking was non-existent. (You can read more about The Modern Networking Supply Chain and the Death of the Multiplier Effect.) Consequently, mega-scale operators deployed solutions, procured directly from ODMs in lots of hundreds to thousands.

Today, bare metal networking is available to the mass market around the world.

The Open Network Install Environment, ONIE, is a fundamental enabler to bare metal networking. ONIE is an Open Compute Project (OCP, pioneered by Facebook) initiative facilitating any network operating system to be installed (or removed) on any ONIE-based switch. Bare metal networking vendors have adopted ONIE en masse, simplifying operations for distributors and resellers with a minimum number of hardware SKUs, in parallel, making the simplified supply chain available to a range of software suppliers. Today, there are approximately 20 ONIE-based platforms in flexible Continue reading

Host-MLAG: Don’t Let a Switch Bring Down Your Servers

How do you protect against failures in a data center? Selecting a stable location and using quality equipment is a good start.

But no matter how much you spend and how lofty the promises of the vendor, hardware does fail. And because systems do inevitably fail, redundancy is your friend when it comes to minimizing the impact of a failure. Systems have redundant power supplies and fans. The connections between systems are redundant. The systems themselves are redundant. And in some cases entire data centers are redundant in different geographical locations.

With the release of Cumulus Linux 2.2, there is now an open solution for redundant layer 2 top of rack, or ToR, switches. No longer will a single ToR switch failure take out your entire rack of servers. This is because Cumulus Linux 2.2 includes Host-MLAG, which allows servers to connect to redundant ToR switches using active-active LACP bonding. Some of the advantages of Host-MLAG include:

  • Unlike a single ToR solution, with Host-MLAG, the failure of one ToR switch still provides full connectivity to all of the servers.
  • With active-active connections to the ToRs, the bandwidth to and from the servers is doubled.
  • Host-MLAG requires no special Continue reading

Tipping Point 2.0

Nine months ago, I wrote about how advances in silicon designs and technologies were going to create a product set that will democratize the networking components in modern data centers. Specifically, that the Trident II family of products will perform the role that Xeon did on the compute side and provide the fulcrum on which open networking OSes would flip the industry.

Today, I am happy to add to that story and talk a little about the secondary effects that that tipping point has set in motion. We had set about to make the networking space an open, agile and innovation-laden environment akin to the compute space, but we are finding a tremendous appetite for the story to be moved further forward and have networking and compute be treated as complete equals. The drive to manage compute and networking in a harmonious way, in the way that a bus and CPUs operate inside a single box, will have a familiar lynchpin – x86 processors.

Let’s look at a little historical context around the progression of CPUs that sit inside data center switching systems. Traditionally, the CPU that sat inside a networking box operated its control plane. The calculus used to Continue reading

New Feature in Cumulus Linux 2.2: sFlow

sFlow is an open protocol, newly supported in Cumulus Linux 2.2, that enables a collector to determine what is going on in a complex network.

It is used to collect statistics, such as packet counts, error counts, CPU usage, etc from a large number of individual switches. What is especially interesting is that it can be used to collect sampled packets (usually only the first n bytes, containing the header), along with some metadata about those packets.

Bringing sFlow to Cumulus Linux was particuarly easy, because “hsflowd” was already available for implementing sFlow support on Linux servers. We were able to reuse that existing code, with extremely minimal modification, to implement sFlow on our Linux based switches.

sFlow allows a collector to get a statistical view of what is going on in a collection of switches, approaching per-flow granularity. This is extremely useful information to present to users for capacity planning and debugging purposes, but things really get interesting when the collector can make decisions based on the information.

For example, our friends at inMon implemented detection of elephant flows (high bandwidth), followed by marking those flows on the switch at network ingress for special QoS handling. This nearly Continue reading

A Full Year of Commercially Available Cumulus Linux Brings Us to Version 2.2

It’s been about one year since we released Cumulus Linux commercially to the market.

Cumulus Linux proved itself quickly as a powerful alternative to traditional networking approaches — not only for the choice it provided with a disaggregated model (choice of both networking hardware and networking OS) or the new business model it provided (a software-only solution with a transparent pricing model) — but also because for the first time, the operating system was a true Linux OS, one that is managed just like Linux on servers, thereby solving many customer challenges around IT automation with tools such as Puppet, Chef, Ansible, Salt, Graphite, and Ganglia readily available on networking platforms. Soon, cloud providers adopted Cumulus Linux and took advantage of various tools to automate rack provisioning, orchestrate switches like servers, and integrate networking with existing workflows.

Cumulus Linux 2.0 brought support for the latest industry-standard hardware platforms with Trident II-based switches and the latest technologies with hardware accelerated VXLANs and Layer 2 gateway integration with network virtualization providers such as VMware NSX. Since then, Cumulus Networks has added many platforms to the HCL, with major partners such as Dell on board, and has had broad coverage for modern Continue reading

ifupdown2, a New Network Interface Manager for Cumulus Linux

Existing tools for network interface configuration have several shortcomings when applied to network switches. These include the lack of ability to handle interface dependencies, incremental updates to interface configuration without disruption, and interface configuration validation. The lack of such functionality increases operational burden. We introduce ifupdown2, a new network interface manager for Cumulus Linux.

ifupdown2 solves these problems through an implementation based on dependency graphs. This article briefly describes network interface configuration on Linux, the problems that arise when configuring a network switch and how ifupdown2 solves these problems and increases operational efficiencies overall.

Background

The Linux kernel understands two types of network interfaces: physical and logical. Physical interfaces represent real hardware and are owned by the device driver that manages the device. Example of physical interfaces include switch ports. Logical or virtual interfaces are created and managed by the kernel. Examples of logical interfaces include bonds, bridges, VLAN interfaces etc. Linux network interfaces are often stacked i.e they exhibit a master slave dependency relationship. Example of stacked network interfaces includes bridge and its ports.

The Linux kernel provides APIs to configure network interfaces. Existing native Linux tools like brctl, iproute2 use one or more of the kernel APIs Continue reading

1 18 19 20