Open Flow SDN - an inside look at one example

Open Flow SDN - an inside look at one example.

I want to share the experience of a close acquaintance with the equipment OpenFlow to build SDN networks. Since every producer, and perhaps every consumer, has his own idea of ​​SDN, and the attitude to Open Flow also varies from the skeptical-contemptuous to optimistic-enthusiastic, I immediately skip all the lyrics and move on to describing the simplest experiment.
So, we have an SDN network built on OpenFlow switches (OFS) and controlled by OpenFlow controller (OFC) (Fig. 1).
The entire configuration of the switches is to switch them to OFS mode and specify the IP address of the controller. We connect switches with patchcords in accordance with our wishes, connect to the controller, check the availability and connectivity of the switches that make up our network, and proceed to solving the problem. As a task, we will try to create a network infrastructure that could provide live migration of virtual machines (VM).
Naturally, I prepared in advance a couple of servers with deployed VM and PC (WAN PC), with which we will check the availability of the VM during the migration process. In addition, to ensure VM Live Migration, we must ensure that there is a vmkernel channel between the ESXi machines deployed on different servers.
Since the Open Flow controller used supports network virtualization (NFV), we create 2 independent networks (Fig. 1):
- Virtual network (VTN1) for the organization of the vmkernel channel between ESXi # 1 and ESXi # 2
- Virtual network (VTN2) for working VM and WAN interface
At the same time, we check the possibility of combining different VLANs within the same VTN by placing our ESXi and VM into different VLANs.
Fig.1 Configuration of physical and logical networks

In this experiment, we intentionally do not use any software to synchronize the network and IT subsystems, that is, our SDN should autonomously respond to the movement of the VM.
The controller allows you to create VTN either in a graphical interface or in a special software shell. The process of creating a VTN is closer to programming than to network administration. For example, VTN1 is described by the following program code:
vtn VTN1 {
vbridge VBR1 {
vlan-map ofs-datapath-id 0000-0000-0000-0003 vlan-id 251
vlan-map vlan-id 251
interface VIF_VEX1}
vexternal VEX1 {
ofs-map ofs-datapath-id 0000-0000-0000-0004 ofs-port GBE0 / 15 vlan-id 252
interface VIF}
vlink VLINK_VBR1_VEX1 {
vtn link vbridge VBR1 interface VIF_VEX1 vtnnode VEX1 interface VIF}
}

In order to monitor the continuity of access to the migrated VM, we will organize a 'ping' of the message from the physical host that issues the connection from the WAN.
OFC supports the visualization function, which allows us to see not only the physical topology and the logical networks created by us, but also active traffic flows:
- 'ping' sent to VM 10.10.10.86
- and the answer is 'ping' returnable to WAN PC 192.168.11.11


Having selected one flow from the list, we can see its route in a logical and physical network. For each thread we have access to full information L1-L4.
From the point of view of this experiment, we are most interested in MAC and IP addresses, as well as the VLAN tag.
And so we go to the VMware console and start the migration.
')


Apparently from screenshots of VM Win1 migrated from ESX # 2 on ESX # 1, and our SDN automatically rebuilt traffic routing. In the following figure we see the updated visualization screen.



Please note that the MAC and IP addresses have not changed, and the VLAN tag has changed from 254 to 253, which is also allowed for VTN2.
In this experiment, we made sure that the host (in this case, the VM), without changing its IP and MAC address, can move freely within the OpenFlow SDN network in accordance with the rules for matching the logical network (VTN) to which it belongs. At the same time, the SDN network ensures optimal traffic routing and compliance with the required policies on the physical network, wherever we move our host.

Using the example of 'ping' packages, one can notice the short-term unavailability of a migrated resource, which in fact is not critical for many real-world applications.

PS: Of course, this is the simplest experiment and does not affect the functionality of SDN related to balancing, filtering, traffic redirection and policy management; and issues of scalability, integration with existing IP networks, ensuring reliability, security, etc. But in my opinion, this example clearly demonstrates that OpenFlow networks are the simplest and perhaps the most perfect tool in our dynamic world.

In the following articles, I hope to sort out the remaining questions with examples and I would be grateful if you offer scripts for further experiments in the comments.

For the formulation of the experiment were used:
OpenFlow controller: NEC PF6800
OpenFlow switches: NEC PF5240, PF5248
Documentation: PFC configuration_guide_V5