Join David Bombal for an in-depth discussion in this video OpenFlow messages, part of Practical Software-Defined Networking: 6 The OpenFlow Protocol.
(dramatic jingle) - [Instructor] This is one of multiple videos discussing SDN, network programmability, network automation, overlays and related technologies. Scrolling down through this document something that you need to learn in OpenFlow is these terms. What are OpenFlow ports? So an OpenFlow port is a network interface for passing packets between OpenFlow processing and the rest of the network.
But it gets a bit confusing here because they have different types of ports. They have standard ports, physical ports, and logical ports. A physical port is what you would expect it to be. It's a hardware interface of a switch like Ethernet one or Ethernet two. Logical ports are logical interfaces such as tunnels and loopbacks and link aggregated ports. So as an example you would have two physical ports and gigabit zero, gigabit one as an example in a link aggregation. The physical ports would be the physical gigabit interfaces and the logical port would be the link aggregation port.
But for the real-world understand that when you put physical ports into a link aggregation, OpenFlow and the controller have no visibility of the physical interfaces. The controller will only see the logical interface, in other words, the link aggregated interface. So as an example, if you have two physical interfaces in a ether channel or link aggregation and one of those interfaces goes down, the controller's not aware of that, 'cause it still sees the link aggregated interfaces up.
Now some reserved ports that you'll find in OpenFlow, this is where it gets a bit confusing, they have various ports. And let's start with some of the ones that are perhaps more well known. We've got a controller port. This is the channel to the controller. So in the OpenFlow table, if we've got a match and the action is to send it to the controller, basically that means we're using the controller port and we're forwarding the traffic to the controller through the TCP session.
Now sessions between the controller and the switch can use TLS, so you don't have to use TCP, you can encrypt the session if you want to. Other ports that you may come across are in_port, so you can match an ingress port. Sorry, if traffic's coming in on port one, send it out to port two. You could match any port which basically means we're not specifying a port, any port can be used as a match. We could also send traffic to the normal port. That sends it to the traditional pipeline of the switch.
So we matching some kind of traffic and then we push it to the traditional pipeline. That could require a hybrid switch once again. Okay, so let's look at some of the interesting ones. We've got table. This represents a table in the pipeline. So I could say, match my CMP traffic, not send it out over port, but send it to table three or send it to table four for additional processing. Okay, so what is all? All represents all the ports on a switch.
Can be used only as an output port. In that case a copy of the packet is sent to all standard ports, but notice here, excluding the ingress ports and ports not as OpenFlow no forwarding. You, through an application, can mark certain ports as no forwarding, which means packets sent to the all port will not be sent out of that port. So here's a question for you. Does OpenFlow require Spanning Tree? So if you run an OpenFlow network, do you need to use Spanning Tree? It's a tricky one.
So let me explain it like this. The answer is as always, it depends. If you've got a pure OpenFlow environment where the controller is managing the switches entirely, the switches are dumb, the controller needs a mechanism to stop loops. So it may have something like Path Daemon, or Daemon, that some controllers have, like the HP controller. In that case, you don't need to run Spanning Tree. But with the HP controller, remember it doesn't use pure OpenFlow.
In the HP environment the switches are still intelligent. The default action on an HP controller is to send everything to the normal pipeline. Essentially means that traditional mechanisms are still used, which means that you need to run Spanning Tree. If you don't run Spanning Tree, you'll have a loop in your topology. So notice the difference between all, will send it out of all ports except where they're marked as no forwarding, versus flooding. Flooding uses the normal pipeline of the switch and will send it out of all ports, except, and there's some exceptions here, but notice here, no ports that have OpenFlow blocking states set.
So in other words, what takes precedence on a switch, OpenFlow or Spanning Tree? Again, it depends on a lot of the implementation, but generally per the OpenFlow document what should happen is Spanning Tree takes precedence. In other words, Spanning Tree, if it's blocking a port, will block that port and OpenFlow packets will also be blocked. So the controller actually gets shown that that port is blocking. So the controller's aware that Spanning Tree's blocking that port.
So hence when you set traffic to flood, or send it to the flood port, it's gonna go out of all ports, but not the ingress port of ports marked with OpenFlow blocking. In other words, if Spanning Tree's blocking the port, the traffic will not go through that port. Now something for the real-world, the OpenFlow documents get better, or more understandable with later releases. So as an example, under the glossary here in this release of OpenFlow 1.5, they have a lot more information.
So better explanation of what an action is or what a control channel, and so forth and so on. So if you studying this stuff or you're trying to understand something let's say your controller only supports OpenFlow 1.3, have a look at that document because that's what the controller and the switches will be using, but also have a look at the later releases just to get a better explanation of the concepts.
So you'll notice here, they also talk about reserve ports and they have the same reserved ports, all, controller, table, in_port, and so forth and so on, but there are some additional ones as well. So just be careful. You obviously need to match up the version of OpenFlow that you're using with the standard that you're reading or the document that you're reading. Okay, so OpenFlow ports I've now explained. Now in an OpenFlow pipeline, processing starts at the first table in the pipeline, which is table zero.
It's based on highest priority. If a go to statement is used, the traffic can be forwarded to an additional table for additional processing. For the real-world, make sure that you understand what a hybrid switch is versus a pure OpenFlow switch, or as they call it OpenFlow-only. OpenFlow-only means that the switch can't do anything without the controller. It has no local processing power except just to form a connection to the controller. Hybrid means that it supports traditional mechanisms. So you could have a switch like an HPE switch or other vendor switches where they can use both traditional and they can use OpenFlow.
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. (dramatic jingle)
- 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?