Up to this point in the book, we have been working with an existing networks and automating various tasks using Python. We started with basic pseudo-human automation using SSH, interaction with the API, higher-level abstraction with Ansible, network security, and network monitoring. In the previous chapter, we also looked at how to build our own network API with the Flask framework. The book is structured this way by design to focus on working with the network engineering field as it is today with the dominating vendors such as Cisco, Juniper, and Arista. The skills introduced so far in the book will help you fill in the gap as you scale and grow your network.

One point of this consistent theme is how we are working within the realm of vendor walls. For example, if a Cisco IOS device does not provide an API interface, we have to use pexpect and paramiko for SSH. If the device only supports Simple Network Management Protocol (SNMP) for network monitoring, we have to work with SNMP. There are ways we can get around these limitations, but, for the most part, they feel ad hoc and sometimes hard to implement without feeling like you are voiding your device warranty.

Perhaps sparked by these frustrations and the need to rapidly develop new network features, the Software Defined Networking (SDN) movement was born. If you work in the industry and have not lived under a rock for the last few years, no doubt you have heard of terms such as SDN, OpenFlow, OpenDaylight, and Network Function Virtualization (NFV). Perhaps you even picked up this book because you have heard about software eating the networking world and wanted to prepare yourself for the future. SDN no doubt offers real value and clearly drives innovation at a pace that has not happened in the network-engineering world for a long time.

Understanding SDN, however, is not as straightforward as it may seem. In any new technology such as SDN, there is much marketing and hype in the beginning. When there is no common standard, the technology is open for interpretation, especially when the incumbent feels the need to maintain their lead in the space by injecting their own flavor to the mix. If you were looking for an example, look no further than Cisco's initial support for OpenFlow in the Nexus 5500 and 6000 line of switches, then the introduction of the OpenFlow-competing OpFlex as well as the Cisco Open Network Environment (ONE) software controller and Cisco One Platform Kit (onePK). I get tired just by keeping track all the Cisco SDN-related acronyms.

In this chapter, I would like to focus on the technology that many consider started the SDN evolution, OpenFlow. In a nutshell, OpenFlow is a technology that's layered on top of the Transmission Control Protocol (TCP) that separates the control and forwarding paths between the physical device and the controller. By separating the two functions and communication methods, OpenFlow allows the determination of the network path outside of the physical device. This enables the controller to use the software on the centralized controller to have a holistic view and simplify the amount of intelligence needed on the individual network equipment.

In this chapter, we will cover the following topics:

• Setting up an OpenFlow lab using virtual machines
• Introducing the OpenFlow protocol
• Using Mininet for network simulation
• Taking a look at a Python-based OpenFlow controller, Ryu, to construct a Layer 2 OpenFlow switch
• Using the same Ryu controller to build a Layer 3 firewall application
• Introducing an alternative Python OpenFlow controller, POX

Let's get started.