OpenFlow patch panel example, part 1

(woosh) - [David] In this video I'm gonna show you an application of software-defined networking using the OpenDaylight controller. In this example I'm gonna show you how to configure an OpenFlow patch panel so you can create a virtual patch panel in this topology. (upbeat music) In this GNS3 topology I have four routers connected to an Open vSwitch switch. So router one has this IP address, router two this, router three this, and router four this. In other words, they are in the 10.1.1.0/24 network and are connected to ports one, two, three, and four on the Open vSwitch switch. Please see my other videos which I've linked below which show you how to integrate Open vSwitch and OpenDayLight in GNS3. In this topology I'm using the management interface of Open vSwitch to connect to the physical network and I've got the OpenDaylight controller running in virtual box on a PC in my physical network. So, OpenDaylight is currently running, and the Open vSwitch switch has connected to the OpenDaylight controller. As you can see here the Open vSwitch switch has registered and the four host devices have been picked up in OpenDaylight. So this topology represents this GNS3 topology. OpenFlow's enabled on these four interfaces. It's not running on the management interface. Here's my Open vSwitch switch. Ovs-vsctl show shows me details of the switch. Br0 is the bridge used by the GNS3 implementation for OpenFlow and currently it's connected to the OpenDaylight controller using TCP port 6633. As you can see it's connected and in the output here we can see that ethernet one, ethernet three and four, as well as ethernet two are part of the OpenFlow bridge. Now I previously used this command to configure the switch to talk to OpenDaylight. So I went into that again. This command will show us the ports running on OpenFlow. So you can see port one, port two, port three, and port four are sending and receiving packets. This command will allow us to view the flows on the switch. So as you can see, various flows have been written by the OpenFlow controller. The switch is using OpenFlow 1.3. This is a match as an example of lldp, which is being sent to the controller. And traffic coming in on port one, as an example, is gonna be forwarded out of other ports, traffic coming in on port four will be forwarded out of other ports on the switch as well as sent to the controller. See, here's router one, can it ping router two as an example? Yes it can. It can ping router three and it can ping router four. If I send a broadcast we should get a reply from those three routers, and we do. So both broadcast traffic and unicast traffic are being sent to the other routers in the topology, and that's because of this flow entry that says that traffic coming in on port one will be forwarded out of port four, port two, and port three. It's also gonna be sent out of other ports but they are not currently connected to the switch and to the controller. Now you could remove these flow entries, either directly on the switch or by using an OpenFlow application. Now in this example I'm using the OpenDaylight controller once again. But in addition I've installed the CiscoDevNet OpenDaylight-Openflow App. You can get to this from GitHub. This application uses the RESTCONF API for communication to the OpenDaylight controller, which in turn writes OpenFlow rules to the switches using the OpenFlow protocol. So on the northbound interface, or NBI, a RESTCONF API is being used. And on the southbound interface, or SBI, the OpenFlow protocol is used to buy the controller to update the OpenFlow tables of OpenFlow switches. In this example, the OpenFlow switch running within GNS3 will be updated. So, I've connected to the controller on port 9000. This is the Cisco application, and as you can see here's my switch and my four PCs connected to that switch. When I click on flow management I'll be able to see the flows that have been added to the switch. So in this example I've got a single Open vSwitch switch running OpenFlow 1.3 and 16 flows have been configured on the switch. So as an example, if we click one of the flows and view it we can see that this flow entry matches traffic in on port 10 and then forwards it out of a number of ports as well as the controller. What I want to do, however, is override these flow entries. Now we could, as an example, delete all the flow entries if we wanted to. But in this example, I'm gonna create a new flow entry on the OpenFlow switch and I'm gonna write a flow to table zero with a flow entry of 102. In other words, I want only router one to talk to router two and not to other routers. I'm gonna set the priority to 1000. I'm gonna match traffic coming in on port one because that's where router one is. Now what we wanna do with this traffic is forward it out of a port. We could drop it, send it to the loopback interface, flood it, send it to the controller, send it to the normal port. But in this case I'm gonna output it to port two. So traffic that comes in on port one is gonna be sent out of port two. Clicking show preview shows us the flow that we're gonna write to the switch. So we're gonna write a flow entry to table zero with an ID of 102 and a priority of 1000, matching traffic coming in on port one. And we're gonna send it out of port two. Now before I send that to the switch, notice that router one can ping router three and router four. But I'm gonna send that to the switch. We can see that it was successfully written. As you can see in the output, the flow entry has been rewritten. You could refresh your flow table to see the latest information. But notice 102 has been written to table zero. On the OpenFlow switch I could grep for a flow entry with priority 1000. So there's our flow entry stating that traffic coming in on port one will be sent out of port two. So router one at the moment can ping router two, but notice can't ping router three because all traffic coming in on port one on this switch is gonna be forwarded out of port two. Router one can also not ping router four because all traffic is going from router one to router two, because all traffic coming in on port one is sent out of port two because of this flow entry. You can see that there have been hits on this flow entry. This flow entry takes priority over the default flow entries because it has a higher priority. The other flow entries have a priority of two, whereas this one has a priority of 1000. So as an example, if we ping the broadcast address, we get a reply back from router two, but we don't get a reply back from router three or router four. So we've successfully configured the network so that router one can only send traffic to router two. Now we may want to do the reverse. At the moment router two can ping router one. But it can also ping router three and router four. So perhaps we want to limit this so that only router one and router two can ping each other. So back in our Cisco app, I'll add a new flow entry. To open vSwitch one to table zero the ID will be 201, in other words router two sending traffic to router one. Priority will be 1000. We're gonna match traffic coming in on port two. And the action will be to send the traffic out of port one. So preview, traffic coming in on port two will be sent out of port one. Send that to the switch. The flow entry is written. Click back, refresh the flow table. Notice here's 201 and here's 102, the two flow entries that we wrote to the switch. Back in Open vSwitch if I grep for 1000 we can see our two flow entries. Traffic coming in on port one is sent out of port two, traffic coming in on port two is sent out of port one. Router one can ping router two. Router two can ping router one. But router two can no longer ping router three or router four. We have successfully patched this port to this port and back again.