In Chapter 3, SDN Protocols, we learned about the key protocols enabling SDN-based solutions and Open vSwitch implementation of OpenFlow. In this chapter, we will build on the knowledge to gain insights into how these components fit together to implement SDN networking. We will begin with lightweight virtual networking with a Linux network namespace and Open vSwitch functioning as a conventional L2 switch. We will then bring OpenFlow into the mix to depict the flow-based networking with virtual machines, interfacing with SDN Controller. We will introduce Mininet, a network emulation tool for prototyping network topologies. Finally, we will depict the architecture of Neutron, the networking component of OpenStack.
We will cover the following topics in this chapter:
- Open vSwitch as L2 Switch with Network namespace
- Open vSwitch as an OpenFlow Switch interface with SDN Controller
- Open vSwitch and Mininet
- OpenStack Neutron architecture
The Linux operating system has a single routing table and global set of network interfaces. Network namespace scales this limitation by providing independent instances of network interfaces and routing tables. This feature enables network isolation and independent operation of multiple network instances. The following diagram depicts network topology with OVS interconnecting hosts isolated by network:
Figure 1: Network topology with OVS connecting with Network namespace hosts
The network interface within the namespace interconnects with Virtual Ethernet Port of open vSwitch via Virtual Ethernet (VETH) port pair. Virtual Ethernet ports are equivalent to a pair of physical Ethernet interfaces interconnected by a cable, albeit implemented purely using software. Virtual Ethernet is implemented as tunnel driver working at link layer (L2) connecting pair of Virtual Ethernet ports.
In this example, we will create two network namespaces and interconnect them with Open vSwitch. We will see how the Network namespace isolates the Network instance:
- As the first step, let's create two Network namespaces one for each host, namely
blue_hostandgreen_host:
- We will now add the links in the Network namespace to enable connectivity for the virtual hosts:
- Let us now add these links to the respective Network namespaces:
- Verify the links move to the Network namespaces:
- Configure IP address to the interfaces in the Network namespace as the next step:
- Ping the interface between the network namespace. We notice Ping does not succeed in confirming that the network interfaces between the Network namespace are isolated:
- Now let's interconnect the interfaces via Open vSwitch. By creating an OVS bridge and adding the VETH peer interfaces to the bridge:
- Check the flow DB in the OVS to confirm that the network interfaces MAC is not learnt:
- Ping the interfaces in the network namespace, connected via OVS bridge:
- We can now see that the forwarding database (FDB) in the OVS bridge
ovs_brhas learned the MAC addresses of the interfaces in the network namespace.
- Using the
ovs-ofctlcommand, we will show that the packet count starts increasing.
As we can see with the preceding example, Open vSwitch works like a regular MAC learning and forwarding switch when no controller is configured and OpenFlow rules are not programmed.