Join David Bombal for an in-depth discussion in this video OpenFlow channel, part of Practical Software-Defined Networking: 6 The OpenFlow Protocol.
- [Instructor] This is one of multiple videos discussing SDN, network programmability, network automation, overlays, and related technologies. Okay, let's look at the OpenFlow channel. Section six, if you like, of this document talks about the OpenFlow channel and the OpenFlow protocol nigh. I warned you that learning this protocol is like learned TCP or UDP. I mean, it's very, very exciting to learn about this kinda stuff. I mean, let's be honest, it can be really boring, but from a troubleshooting point of view and an understanding point of view, it's important that you have an understanding of this stuff.
So there are different types of messages. You've got controller-to-switch, asynchronous, and symmetric messages with multiple sub-types. So a controller-to-switch message are messages initiated by the controller and may or may not require a response from the switch. Then we've got asynchronous messages, which are sent without a controller soliciting them from a switch, so the switch can just send them to the controller. And then we've got symmetric messages, which are sent in either direction without solicitation.
So when you do a wide-shot capture, and you look at the messages between the controller and the switch, you'll firstly notice a hello message. The switch, when you enable OpenFlow, will contact with the controller and say, hello, Mr. Controller. And then the controller will send a hello message back saying hello, and they will use that to negotiate to the version of OpenFlow that they can support. They typically negotiate to the highest supported version. So if a switch supports OpenFlow 1.0 only, and a controller supports 1.0 and 1.3, they will use 1.0 'cause that's the highest that both supports.
If both of them support 1.0 and 1.3, then they'll negotiate to use 1.3. So when you do wide-shot captures, you will notice or see those hello messages between the switches. And then you'll get messages like this. The controller has just met the switch. The controller doesn't know what that switch supports, so it'll send a features request message saying, switch, tell me what you support. Do you support spanning tree? Do you support flooding? What do you support? And essentially, the switch tells the controller, 'kay, these are the features that I support.
These are the tables that I support, because remember, some hardware-based switches might only support a single table. Software-based switches may support many more tables, so the switch has to tell the controller what features it supports and what tables it has. The controller may then configure the switch and say, okay, you can only do this, as an example. The biggest MTU that I can support, the biggest packet size that I can support is 65,000 bytes, as an example. The controller may modify the state of the switch.
Now, there's a whole bunch of messages, and I won't bore you going through them. I'll just point out some important ones to be aware of, using a layer two learning switch as an example. And a switch receives a packet. It doesn't know what to do with a packet, so it's gonna send it to the controller as a packet-in message. So in other words, you're not using proactive flow tables, you're using reactive flow tables. Packet hits the switch. Switch doesn't know what to do with it, so it's gonna send it to the controller as a packet-in.
And notice, they say that this is where the control of the packet is forwarded to the controller. So the packet is sent to the controller using the CONTROLLER port as a packet-in. When the controller sends it back to the switch, it's called a packet-out. OpenFlow is asynchronous, so the controller can use barrier requests to make sure that the switch has done what it's told it to do. So when you do a wide-shot capture, as an example, you will see the controller tell the switch, okay, write these flow entries into your table.
And then the controller will use a barrier request message to ensure that the switch has done what it's told it to do. It's kinda like a confirmation. Have you done what I told you to do? Yes, I have, and you'll see a barrier reply come back. Where are the flow tables kept? This sometimes causes confusion. The flow tables are in the switches, remember, they wanna do hardware-based forwarding of traffic. So the flow table is stored in ASCX. It's similar in concept to a RIB versus a FIB in routing.
We have a routing information base on a router, which is typically software-based, and then a forwarding information base is a copy of the routing table, but in hardware ASCX. Same kind of idea here. The controller has the logic. It's worked out where packets should go. It knows what the flow entries are that the switch should maintain. And it writes those flow entries into the switch table, but the switch has the table. Flow entries could be removed, as an example, because of an idle timeout or a hard timeout.
Idle timeout means that if there are no matching flow entries on that flow entry, it's gonna be removed. Hard timeout says, here's just a value. It's set in stone. It's, say, 60 seconds. It doesn't matter if packets are matching or not matching. After 60 seconds, that flow entry is removed, and the switch then informs the controller that the flow entry has been removed. So flow tables, the flow entries are housed by the switches or kept on the switches.
When a flow entry is removed, the switch tells the controller about that. When a port goes down or port comes up, the switch tells the controller, this interface has gone down, or this interface has gone up, or has come up, should I say? That's sent to the controller as a port-status message. Now, guys, you can imagine, this is very exciting, and I can talk for hours on this stuff. I've read a lot of this document. If you wanna get into the sort of nitty-gritty of OpenFlow, I would suggest you read, like, towards this part of the document, section six.
When you go further, it gets to, like, programming kind of detail. So you might not want to read this kind of stuff, but if anyone asks you information about OpenFlow, what I tend to do is just Control + F or something in this document, so if you were, I had a question the other day about what happens when a controller interruption takes place, I've just done a search now for fail secure mode, fail standalone mode.
Basically, the document explains, in not-too-bad English, if you like, it's not overly complex at times, how things work, so a great document to use. Hey, guys, I've bored, probably, you to tears now. Are there any questions? I hope you enjoyed this video. If you did, please like it, and please subscribe to my YouTube channel. I wish you all the very best.
- 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?