From Slides Defined to Software Defined Networking. Part 3

In the previous sections ( Part 1 and Part 2 ), we talked about the architecture and functions of the Big Switch Networks SDN-solution for the data center Big Cloud Fabric. In the final article, we will consider the capabilities of the factory for integration with adjacent systems, and also provide a brief summary of the previous parts of the review.

Big Cloud Fabric Integration

The modern data center network cannot exist separately from other systems - the physical and virtual worlds are too closely intertwined, and the boundaries between them are too blurred. Integration with virtualization and orchestration systems is one of the most important benefits of BCF. Despite the fact that similar capabilities are stated in the solutions of many manufacturers, the centralized BCF architecture allows them to be implemented quickly, simply and conveniently.

Currently, BCF is working together with VMware vSphere, Docker / Kubernetes, as well as tight integration with OpenStack. In the case of the latter, integration capabilities are considered among the best in the industry. An agent for Open vSwitch is installed on the KVM compute nodes, which is fully synchronized with the factory and provides not only switching, but also routing between virtual machines on the compute node. Creating and managing projects in the Horizon interface is completely synchronized with the BCF controller — in fact, inside the OpenStack Project (BCF Tenant), any actions to manage the factory’s network infrastructure can be done from Horizon.
')
Integration with vSphere occurs through vCenter, and the factory can be associated with several copies of vCenter, each of which manages its own tenant in BCF. Moreover, factory resources can be shared between multiple copies of vCenter and OpenStack. Integration with vCenter provides the following features:

• automatic study of connected ESXi hosts and organization of LAG groups;

• automatic learning of virtual machine addresses (MAC address, optional IPv4) deployed on connected ESXi;

• automatic creation of segments in the factory and membership rules when creating a port group;

• automatically add required VLANs to an LAG with an ESXi host;

• when implementing vMotion, if there are no virtual machines left on the current ESXi in a particular segment, the interface-group (through which ESXi is connected) will be removed from the segment.

Thus, most routine operations are automated and do not require the intervention of a network specialist. However, the integration capabilities of BCF and vSphere are not limited to this. Big Switch Networks has developed a plugin for vCenter, which further extends the capabilities of virtualization team members and gives them additional configuration tools and fault analysis. With it, the vCenter administrator can create L3 interfaces for the subnets and segments in which virtual machines are located, view information about VLANs, end hosts and servers, as well as policies (ACL, PBR). But most importantly, the same Test Path tool is available in the plugin as in the BCF controller interface.

The virtual environment administrator no longer needs to disturb the network engineer at most stages of the troubleshooting process — just select the source virtual machine and destination machine (or external host) and complete the test for traffic through the factory.

You might get the impression that integration with vSphere and the vCenter plugin provide too many opportunities for virtual infrastructure administrators for whom they may not be ready. However, it is not. The above tools are only designed to facilitate and speed up the process of setting up and troubleshooting - there’s no reason why teams need not distract each other and wait for a reaction to the performance of simple queries and routine operations. The administrator of the virtual environment cannot “break” anything in the factory - its capabilities end with a tenant, with which vCenter is synchronized, but at the same time it has enough tools for solving daily tasks. The overall factory management is still performed by the network engineer, but his participation is required only in solving serious incidents or in the event of global changes in the system.

Conclusion

The concept of Software Defined Networks is probably the most discussed topic of the network world. No marketing material does not bypass it, each manufacturer seeks in one form or another to declare its support in its decisions. However, despite the continuous development and a number of significant changes, this concept has not been embodied in the form of commercially finished products for a long time. Perhaps the reason is that one of the cornerstones of the resiliency of telecommunications networks is decentralization, while the implementation of the SDN concept is almost impossible without a single point of control and control (Control & Management Plane).

But the advantages that SDN carries with it, the interest of customers and the software manufacturers constantly advancing on their heels force the giants of the network market to reconsider their point of view. As a result, the market is flooded with advanced control systems, albeit under different names, but united by one goal - to emulate SDN-functions in a classical network. Unfortunately, such an approach cannot bring all the advantages that SDN offers, and most importantly, does not solve the long-standing problem of the network IT world - the separation of applications, operating system and hardware. The development of commercial ASICs and the emergence of network operating system developers on the market partly solved the problem of disaggregation, but the products collected from them either still remain a network of independent devices without any hint of integration with third-party systems or a designer who is proposed to be assembled independently.

Data center networks do not have a wide territorial distribution and rarely go beyond a single machine hall, and, therefore, the reliability of communication lines in them is much higher than that of distributed and campus networks. Thus, the problem of centralization and resiliency in the data center is not acute. Moreover, everyone likes modular switches! If it were not for the cables with their constant ability to fill all the available space, the data center network probably would consist of two very large switches. Recommended designs from leading manufacturers using factory outlets or large stacks of 1RU switches are a good example. Apparently, rightly based on such reflections, Big Switch Networks was able to transform the concept into a really working commercial product.

In conclusion, I would like to make a dry squeeze review and once again list the main points that Big Cloud Fabric has:

• Lack of hardware binding to the manufacturer of network equipment (hardware vendor lock-in). As a switchboard factory can be used switches from various manufacturers, based on the ASIC Broadcom Trident 2/2 + and Tomahawk. This means that you no longer need to adapt to the policy of the manufacturer and supplier of switches: now there is a choice. This not only reduces costs, but also speeds up the process of purchasing equipment - you can choose any of the switches available now instead of waiting for the delivery of a certain model for months;

• Fault tolerance. Despite the centralized control and management plane, BCF is extremely reliable. Controllers of the factory are implemented as a failover cluster, leaf switches can be combined into MC-LAG pair, and in case of failure of all controllers, the factory will continue to work with all servers studied. As one of the evidence of factory resiliency, Big Switch Networks provides the results, the so-called. Chaos Monkey Testing - at a factory of 16 spine- / 32 leaf switches under load from 42,000 end hosts / VM, more than 640 failures were organized within 30 minutes, but this did not affect the application performance;

• A single point of control, management and integration. In fact, we have a really big, distributed, modular switch. There is no need to configure each switch separately and worry about the protocols, loops, fault tolerance within the network - BCF is a single factory, with a single interface. Integration with virtualization and orchestration systems allows you to automate most processes, and tools such as Test Path and a plugin for VMware vCenter greatly simplify troubleshooting and communication processes between teams;

• Extensive analytics. A powerful system is built into the factory controller to collect, correlate and display all data on the physical and logical structure of the factory. This greatly simplifies troubleshooting and eliminates the need for additional systems;

• Significant scalability . One BCF POD supports up to 32 leaf / 6 spine switches and 46'000 connected end hosts. Thus, we get a network factory with a predictable, constant delay time and 2: 1 oversubscription. It should be noted that adding a switch to the factory does not require anything other than switching - the Zero Touch Provisioning feature eliminates the need for any configuration of the connected equipment. Thus, to increase the port capacity of the factory from 96 ports to more than 1,500, time is required only for installation and switching, plus 10 minutes for adjustment.

In addition to this, Big Switch Networks provides very flexible familiarity with the product. First of all, this is a special free version of the BCF-controller in the form of a virtual machine, Community Edition. It has all the functionality of the commercial version, except for restrictions on the number and type of switches (only 2 physical switches), as well as support (best effort, only by e-mail). You can use the remote lab to familiarize yourself with the BCF capabilities even without equipment. It presents several training modules, broken down by the most interesting topics, within which you can work out frequently used functions and scenarios or simply get acquainted with the controller interface.

In general, we received extremely pleasant impressions from testing and working with the Big Cloud Fabric factory and we are confident that due to its convenience, simplicity and wide functionality, it will be in demand in the data center network solutions even in the face of fierce competition from other large systems.