Openflow for dummies

It is time to paint another white spot on the Habrahabr info card. I was surprised to find that, apart from a couple of briefly mentioned facts, our favorite site still does not tell about the impending breakthrough in Internet communications, to which such monsters of network technologies like Google, Juniper, Cisco and other equally famous the company.



The OpenFlow protocol itself is quite young, it was developed at Sandford University just a little more than a couple of years ago, but since then the amount of human and technical resources involved in its implementation has been growing like an avalanche. Half a year ago, my company joined this race, and now I will try to briefly describe all the advantages and disadvantages of this technology at the level of "dummies", for admin-monsters will find where to read the detailed specs.



So, I will try “on the fingers” to describe what the point is. Perhaps many of you paid attention to the small boxes with blinking lights, through which the Internet gets into your computer. The providers are almost the same, only more expensive and more powerful, but the essence is the same: take a package from one hole, look at its contents and then either put it into another hole, or throw it away, or outrage it in another way. What happens in the end with each particular package is decided by the processor inside the box. He remembers the hole in which the wire sticks out to the uplink, he knows the address of Vasya Pupkin's network card, he does not let the malicious hacker from China fulfill dirty plans against Vasiny's computer.

')

The trouble is that “there are a lot of you (packages), but I (the processor) are one” and when the speed of arrival of the packages exceeds the capacity of the processor to process them - the inevitable delays and losses begin. And here a natural question arises - why should a dispatcher work as a porter? Let's separate them.



So, in a nutshell, the essence of OpenFlow is described in this way - shuffles packets from hole to hole, Dumb Iron Package Processor (TGPP) in accordance with its table, and if it suddenly comes across an unusual package that does not fall under any rule, then TZPP just forwards this package (wrapped up in beautiful gift wrapping) to the Server That Knows Everything (SKVZ).



The SCWZ lives somewhere near the Most Main Admin and remembers the network configuration inside it, where is the switch and who is connected to it. Each switch has its own unique number and after turning on the power, it knocks on the SKVZ and receives from it a complete list of rules and actions (Matches & Actions) for its TGPP, for example “if a packet with DstIP 1.2.3.4 came to you, then stick to it VLAN tag 10 and send to 15 hole ”and so on. In the role of SKVZ now often are NOX , BigSwitch or Beacon (there are others, but this is the set that I have so far had to feel with my own hands).



After the start of operation, the SCWZ can change the configuration of switches on the go, depending on the events that occur. For example, a packet is sent to a specific port, the TGPP sees the corresponding rule and sends this packet to the controller, the controller adds a rule in response that allows, for example, an hour to access the Internet from a specific address. Or vice versa, it gives access from the outside to some service.



Advantages of this approach:

1) the entire network configuration is stored by the admin on the server and has a single interface, for changes and backups you do not need to log in anywhere, and most importantly, the old admin sign no longer “change remotely network settings to the long road ”, finally you can experiment at your pleasure

2) Established data streams that do not require server intervention are processed at the maximum interface speed.

3) The cost of the switch, according to the “cleverness” superior to the current L3, falls even lower than the cost of the most primitive L2

4) The dream of many users - WiFi roaming, switching on the go (project OpenRoads )



Of course, there are downsides:

1) ARRRRRHH !!! Sorry, could not resist. I, as a developer, are very upset about the dullness and ill-conceivedness of the protocol itself, against the background of which even the SMTP looks the height of grace and refinement. However, they promise to change it thoroughly in the next next version (the current version 1.1 was adopted in March of this year), but for now saves only the so-called Vendor Messages, where you can add your functionality, but with fear of slipping into, sorry for the expression, proprietary. By the way, 1.1 from 1.0 also differed significantly, and I managed to run on the rakes carefully laid out inside the protocol.

2) IPv6. However, the dead or good, or nothing. About zombies, I'm not sure.

3) Work with multiple controllers. Now in the lab, this is done through a crutch called a flowvisor, but in real life, the fall of the SCWS turns smart hardware into stupid switches.

4) Dances with a tambourine when implementing elementary things, for example, checking the Syn flag in the TSP package. Although this is again a claim to number 1.

5) There was something unpleasant, but I forgot because of the emotions that had overwhelmed me after point 1.



In the comments you can ask questions, I will try to answer them to the best of my competence.



UPD: video on the topic from the user eek