Get acquainted with the OpenFlow network communications protocol. Explore the theory behind OpenFlow, dive into the details of OpenFlow messages, discover what happens when an SDN controller fails, and more.
(woosh) - [Instructor] This is one of multiple videos discussing SDN, network programmability, network automation, overlays, and related technologies. I watched a presentation by Martin Casado, one of the sort of fathers of SDN, and he was talking about his experience as he went form starting and writing OpenFLow at Stanford to selling his company, Nicira, to VMWare and what he's learnt over time, and what's interesting is he says at the end of the day the virtual network is what he thinks is the most successful implementation of sort of SDN.
So if you want to have a look at that, the presentation, sorry, is on YouTube. So I spoke about the Open Networking Summit. So this is the 2017 one. So if you're interested to hear someone's take of SDN and these were the guys that did a lot of the initial work. This, it's about 25 minutes. It's an interesting presentation. So he talks about how they were thinking about the separation of the control plane and data plane, kind of like what OpenFLow is supposed to do, and then how they changed that.
So they decided that perhaps that wasn't the best way to go and then they eventually went, if you look in his presentation, to a virtual network. So they changed sort of their viewpoint of a whole bunch of things and eventually ended up with the VMWare sort of product, where we have virtual networks. And then he shows the money that was made by selling NSX to the market and how it's hit in 2016 a billion dollar run rate.
So this is one of the most successful products out there. So Martin Casado, who's now a VC, but obviously he was pitching Nicira to VCs. This is what happened when VMWare bought the product, bought Nicira. They're selling a lot of those products. Billion dollar run rate. But he, in this presentation he talks about the original intention of SDN and how they wanted to move from separation of control plane and data plane and then have a central network operating system.
And then in the end they moved to a virtual network. So that's where they ended up. So it's interesting from someone who was deeply involved in this, how their perspective changed, and how they went from like pure OpenFLow to a virtual network that doesn't even necessarily use OpenFLow. So if you're interested in sort of seeing someone's perspective about that, there you go. There are still competing viewpoints of the right way to go.
What we're gonna talk about now is OpenFLow. And you can get details of that at the ONF's website. So Open Networking Foundation. Okay, so let's jump into OpenFLow. On the ONF website, if you go to SDN Resources, ONF Technical Library, you'll find the documentation. Now there's nothing more exciting than reading RFCs and reading these kind of documents, especially if you have problems sleeping at night, but actually these aren't too bad.
So a lot of controllers today still only support OpenFlow1.3. So you'll see the wire protocol is set to 0x04. That's a protocol that you would see if you did a y shot capture. The latest specification is 1.5. So rewho as a controller, as an example, supports this, whereas other controllers don't. So, you just need to look at the specification that relates to your controller and your network devices.
The controller and the network devices negotiate to use a version of OpenFLow. So starting at the beginning of this document, once again we have an OpenFLow switch which could be a virtual switch or could be a physical switch. A switch has an OpenFLow pipeline which consists of either one or multiple tables. So open V switch, as an example, or mininet, supports 254 tables. But other devices, so other physical devices, may only support one table.
This is vendor dependent. OpenFLow specification is very much open to interpretation. So you only need one table to be compliant, one or more flow tables. And they perform packet lookups and forwarding. In other words, they will match something and then do something with it. So match this forward out of this port. The switch runs an OpenFLow agent and sets up an OpenFLow channel to the controller. In OpenFLow terminology this is called an OpenFLow port, or controller port.
So when we send traffic to the controller port, or the controller, we're essentially using this channel, which is negotiated using OpenFLow to an external controller. This is the GUI of OpenDaylight. You'll notice it's not necessarily that pretty. I had a problem where my mininet was broken so I had to download a new mininet and get that working, and that's what I've done here. So what I'll do is get my local mininet. This mininet VM is running on a local PC.
The controller's running on a separate PC. Both running in virtual box. So what I'll do is copy a mininet command into this, and basically what this is gonna do is it's gonna set up a session to the ODL controller. So once I press enter here we should see that we have a network established on ODL. I'll do a pingall and let's see if it actually works.
Okay, so there you go. We've got one PC, four OpenFLow switches, and there's our topology. So, four OpenFLow switches. PC's connected to those OpenFLow switches. So we can see the IP address is a PC. We can see details of this OpenFLow switch. If we go to nodes, make this a bit bigger, we can see that there are four OpenFLow switches, open for switch one, two, three, and four.
We can see the node connectors. So these are the interfaces on that switch. We've got port one, port two, and a local management interface. And if we look at another switch, let's say switch three, we've got ethernet one, ethernet two, ethernet three, and local management interface. Notice here we've got 254 tables on the switch. It's not displayed very nicely in the ODL GUI here at all.
That's showing you what the OpenFLow table looks like. What I'd like to point out here is we have got an OpenFLow topology that was learnt because the switch is connected to the OpenFLow controller. Cisco have an open source product that can run on the OpenDaylight controller. So if you do a search in Google as an example, for the Cisco OpenDaylight-Openflow-App, and basically what it is is an application written by Cisco that uses the RESTCONF API to talk to OpenDaylight on the northbound interface.
And then on the southbound interface we've got OpenFLow that writes rules to switches. But let's go back to the theory. So we've got our OpenFLow controller using the OpenFLow protocol to write flows to the OpenFLow tables of switches. So the switch and the controller communicate using the OpenFLow protocol. The OpenFLow protocol is used to add, update, and delete flow entries in flow tables, both reactively and proactively. So remember, a proactive flow is a flow entry that is written before the traffic arrives, whereas a reactive flow entry is written after traffic arrives.
Traffic is sent to the controller, and then the controller decides what to do. What's actually the applications on the controller decides what to do based on the packet that was received. A flow table has a list of flow entries which consists of match fields, so we're matching some kind of traffic. Then we have counters and a set of instructions to apply to the packets. So in other words, we would match, say, ICMP. We would have a counter to count up how many packets have matched, and then an instruction would say, okay, so we're matching ICMP, send it out of port two, we'll send it to the controller.
In other words, do something with the traffic. So as an example, matching starts at the first table. The first table is always table zero, and then may, not always, but may continue to additional tables. Flow entries are matched in priority order. In other words, we started the most, well the highest priority, and then it works down looking for a match. I just want to point out a few things in this document for the real world. Once again, notice we've got OpenFLow1.3 and 1.5. 1.3 only matches ingress traffic.
But in later releases like OpenFLow1.5 you can match ingress and egress traffic out of a switch. So notice this picture's very different to the previous picture. If I go back here this picture's only matching ingress traffic on a port, not egress. Whereas here we are matching ingress and egress.
- OpenFlow theory
- OpenFlow messages
- Wireshark OpenFlow capture on Windows
- Benefits of multiple tables and TTPs
- Wireshark capture multipart request
- What happens when the SDN controller fails?