This is a guest blog from our partner, INLINE Technologies
Almost everyone in the field of information technology is familiar with the concept of software-defined networking (SDN). During the introductory period of SDN, there were no commercial products offered, rather this period was filled with R&D by academics; in fact, for a long time it was just a concept presented on PowerPoint slides. Now, it has reached maturity, thanks in part to the continual development of capabilities from vendors, academic institutions and network solutions architects around the world.
I have deployed Big Switch Networks’ Big Cloud Fabric (BCF) in my lab at INLINE Technologies, to test the solution for potential use in data center networks. In my experience there can be confusion around the definition of SDN because the term is often overused in marketing collateral by vendors who don’t truly offer an SDN solution, but Big Cloud Fabric is a true SDN solution. BCF is a complete, commercial, out-of-the-box product. It is simple and economical to deploy, and unlike legacy box-by-box systems, BCF requires no complicated integration of components, large staff of specialized technicians, or even significant experience with SDN technologies.
The physical architecture of BCF is simple. It is a network of bare-metal switches, that are cabled in a spine and leaf topology and connected to a controller cluster via an out-of-band network. The controller centralizes management and control planes of the entire fabric. Each switch has a lightweight operating system called Switch Light OS, which receives instructions from the controller, programs the ASICs and collects statistics.
With the controller playing a central role in the fabric’s architecture, my colleagues and I at INLINE Technologies faced a primary question – what would happen if both controllers in the cluster were to fail? We performed several tests and were pleased to discover that headless mode works exactly as Big Switch describes – all servers and virtual machines had continued access to the fabric without any disruption. I consider this a breakthrough as most technical specialists would attest, centralization of the control plane has previously decreased the fault tolerance of a network, but BCF overcomes this challenge faced by legacy systems. Imagine what would happen with a classic modular switch with full redundancy, if all supervisors were to go down? Most likely, it would crash.
One of the biggest advantages of BCF is the ability to leverage bare-metal switches from different vendors. Customers are often wary of potential incompatibilities and choose a mono-vendor solution. With BCF, bare-metal switches from different vendors all leverage the same OS, Switch Light OS. Therefore, the potential for incompatibilities is nearly zero. To test this, we used bare-metal switches from Dell and Accton on the spine and leaf levels, and no incompatibilities were detected.
When we were planning to test BCF, we only included the most necessary features in our test plan, because we did not expect such rich functionality from a younger product. We quickly decided to expand the list of features to test, because BCF is so innovative, it offers many interesting and useful capabilities, which will greatly benefit our customers. What surprised us most was how seamlessly each feature worked – all tests were successful. Overall, our experience working with BCF has proved that it is easy-to-use and agile.
BCF has a full-feature CLI and a very intuitive web interface. Essentially, these are clients for a unified REST API. This system eliminates any differences in functionality between the CLI, web GUI and the REST API – all configuration, monitoring and other tasks can be completed from any interface. The REST API is really user-friendly, for example, in the past if we wanted to write script to automate a routine task, we would spend many hours with a REST API guide. However, BCF offers a more convenient way – you only need to type debug rest in CLI and BCF will include all REST info (method, path and body) of requests and answers for each of the CLI commands. Therefore, you can perform all necessary commands in CLI, and prepare a script to automate an operation based on the outputs.
Previously network specialists would prefer to use CLI for configuration of equipment and management, because (in general) CLI has more features than other interfaces. However, the web interface of BCF is so powerful, we didn’t need to use CLI in our tests. All features and tools are available from the web interface and many tasks are solved by «click on» method. In addition to simple and powerful logic, the web interface has many small, but useful features. For example, if you want to add a new switch to the fabric, you simply set a name and choose a role for the new switch. And if the name of the switch contains the word «spine» or «leaf», the role of the new switch will be offered automatically, these additional capabilities make a big difference.
BCF supports all capabilities and technologies that a modern data center requires and has unique, useful tools that other solutions do not offer. One of these is the Fabric SPAN tool, which provides an opportunity to copy data traffic that has been filtered by the L2 – L4 protocol fields to a special port. Specifically, if we want to mirror all HTTP traffic, we need only to create a single Fabric SPAN policy and it will take about 2 minutes to complete. As a comparison, a classical network requires additional equipment and much more time for this task. The other common problem modern data centers face is the lack of connection between two virtual machines or servers. Usually network specialists start an intensive troubleshooting process – ping, trace route, telnet, route tables and access list analysis. This is done box-by-box, console-by-console. With the Test Path tool provided by BCF, the solution is simple. This unique feature displays a path for each packet in the fabric, just point to the source and destination endpoints, choose a protocol/port for the connection, and BCF shows the path of traffic flow. If there is a problem with the connection, Test Path automatically points to and describes the problem. This tool can work in two modes. First, is a simulate mode, where the controller estimates the path of traffic based on its own tables. This mode doesn’t require actual traffic flow. In the second mode, each fabric switch intercepts real traffic and forwards this information to the controller. Thereby you can see an actual path through the fabric.
Another differentiator of BCF is multicast. Today, it is getting more popular in data center networks due to the rise of technologies such as VMware vSAN. Typically, a process of enabling multicast routing in legacy networks requires configuration of many features – IGMP, IGMP snooping, PIM, MSDP, and more. This typically requires configuration on each box, which can be a timely process. To enable multicast routing in BCF it’s as easy as moving the slider «Multicast Enable» in a tenant setting. BCF will then be able to switch and route multicast traffic inside the tenant. More important, the same multicast groups can be used in different tenants without the risk of being routed incorrectly.
BCF is a true SDN architecture with its centralized control plane, the controller is a single point for the switch’s critical information. The controller collects and saves the statistics information, correlates events and shows results in a customized form. Users can see the analytics about both the physical components (hardware condition, event, high-load interfaces, top-talkers) and the logical components (events by tenant and segment, start/stop/move of virtual machines, etc.). In practice, a powerful analytical system is created, without additional charges for infrastructure or software.
And last, but not least – Big Cloud Fabric has huge possibilities for integration with virtualization and orchestration systems including: VMware vCenter, OpenStack, and Docker/Kubernetes. This, in itself, is a topic for another discussion. Because our customers prefer VMware’s solution, we performed several tests to integrate VMware vCenter with BCF, and were very satisfied by the results. The fabric discovers ESXi hosts and builds LAGs with them automatically. The information from vSphere’s port-groups is synchronized with BCF and segments are created seamlessly. Additionally, if all virtual machines using a port-group migrate from ESXi A to ESXi B host, then membership of LAG to ESXi A in BCF segment will automatically be canceled. This is useful from a management and security point of view – the LAGs to ESXi hosts do not cumulate old VLAN IDs which eliminates the risk of a malfunction or intrusion. Integrating features really simplifies life for administration and networking teams - vSphere administrators don’t need to utilize a network specialist for basic tasks and can perform a lot of common tasks on their own. If a vSphere administrator wants to have control of advanced network features, BCF’s plugin for vCenter can be utilized. The plugin allows for configuration of IP networks in BCF’s segments and can utilize the Test Path tool. Administrators can choose the name of a virtual machine in a pop-up menu, rather than input its IP address manually. Consequently, vSphere administrators can troubleshoot any connectivity issues without a network engineer.
In all our testing with Big Cloud Fabric, we at INLINE Technologies have had fantastic results. BCF has many interesting and useful features, handy interfaces and is simple to deploy and above all, it works without a problem. Despite a lengthy list of competitors, due to its many unique capabilities, I think Big Cloud Fabric provides so many advantages, it will be a popular choice for data centers.
Aleksandr ShilkinSystem Engineer, Telecommunications Department, INLINE Technologies