Employing SDN switches in enterprise networks
Software-defined networking (SDN) switches are intended to greatly simplify network management, deployment and operation by disaggregating network control and forwarding functions from individual switches and routers, placing them instead in a centralized SDN controller.
The controller has a centralized view of the entire network but appears to individual applications and policy engines as a single, logical switch – thus greatly simplifying the network topology and operations. It is also highly programmable, enabling network managers to write dynamic, automated programs that dictate network behavior under various circumstances.
With all control and forwarding functions centralized in the SDN controller, there’s no need for numerous distributed, highly intelligent switches, as in a traditional network. Rather, companies can use simple commodity switches, also known as SDN white box switches, or simply white box switches.
Historically, these switches were a stumbling block for many organizations as they sought to deploy SDNs. The network hardware is not an issue. It is available from manufacturers such as Accton, Delta Networks, Foxconn and Quanta Cloud Technology, the same companies that supply bare metal hardware to major industry players such as Cisco and Juniper.
It’s at the software level where SDN networks often became complicated for many end users. In their early stages, users were left to install and program their own network operating system (NOS) on top of their choice of SDN white box switch.
Today that complexity has been greatly reduced with the emergence of players such as Pica8 that offer an open, Linux-based NOS that is ready to be installed on the user’s choice of SDN white box switch hardware.
The idea of an “open” NOS is important, in part because it means it can be easily ported from one hardware platform to another – crucial to achieving the cost savings that SDNs are intended to provide.
Open NOSs typically use an open source Linux-based OS from organizations such as the Open Compute Project (OCP). Its Open Compute Networking Project is an effort to create a set of open network technologies, including a Linux-based NOS and developer tools.
When implemented with support for open industry standards, an SDN provides more flexibility in terms of the mix of equipment and software that can be deployed. Users are no longer beholden to their legacy vendors, with proprietary devices and protocols. Rather, SDNs support industry standard protocols such as OpenFlow, the communications protocol that enables the SDN controller to interact with and deliver instructions to the various networked devices in an SDN environment. They also support industry standard network orchestration tools such as Ansible, Chef and Puppet.
Use of SDN white box switches with open software can mean more than 50% savings in capital and operating expenses as compared to traditional network equipment.
In part that’s because companies such as Pica8 are now further simplifying the deployment and operation of white box networks.
Pica8 makes the PICOS NOS that runs on a wide variety of white box switch hardware. PICOS technology enables the control of dozens or hundreds of white box switches as if they were a single, logical switch, which slashes operational overhead costs. PICOS also enables the leaf-spine architecture that has been popular in data centers to be deployed across the enterprise. Leaf-spine is simpler than the traditional three-tier network architecture while providing improved performance and resiliency.
Pica8’s CrossFlow technology also brings important benefits to an SDN environment. Typically, hybrid Layer 2/Layer 3 switches enable some ports to support L2/L3 traffic while others are under the control of an SDN controller. But each port supports only one or the other – not both. CrossFlow enables each port to support L2/L3 traffic as well as SDN traffic at the same time.
This is an important capability in large SDN environments because it provides a dynamic way to insert policy instructions into the network, such as by using OpenFlow. For example, if a company’s security team detects suspicious activity coming from certain Mac addresses, it can use OpenFlow to remotely push out a new rule to every switch in the network to deny flows from those addresses – with no disruption of service.