OpenDaylight, Cisco OpenFlow app, and OVS

(thrumming woosh) - [Instructor] This is one of multiple videos discussing switching with GNS3. This is also one of multiple videos discussing Open vSwitch in previous videos I explained how to integrate Open vSwitch with GNS3, I explained a bit about flow tables, I explained a bit about Open vSwitch as a virtual switch. In this video I'm going to show you the integration between OpenDaylight and Open vSwitch. OpenDaylight is a software-defined networking controller or SDN controller and in this example we are going to use the OpenFlow Protocol on the southbound interface between OpenDaylight and Open vSwitch running in GNS3. I've also got the CiscoDevNet/OpenDaylight-OpenFlow-App installed on the OpenDaylight controller. You can find this application on GitHub. The OpenFlow Manager or OFM application runs as a separate process on the OpenDaylight controller and uses the RESTCONF API on the northbound interface for communication to OpenDaylight. So I'm gonna demonstrate using this application to write flows via the RESTCONF API on the northbound interface and OpenFlow on the southbound interface. OpenDaylight supports multiple southbound protocols. But in this example we're using OpenFlow to write OpenFlow rules to OpenFlow switches, that are running OpenFlow agents. Open vSwitch supports both traditional and software-defined networking protocols such as OpenFlow, in this example I've got two Cisco routers connected to the Open vSwitch switch, and the Open vSwitch switch is connected via ethernet zero to my physical network. In this example, rather than running OpenDaylight within GNS3, I'm leveraging an OVA that I already have running within VirtualBox. So in this example, VirtualBox is running on a separate computer. Here it's running on a Windows computer, but I'm using GNS3 2.0 on a Mac. The configuration and setup is very similar if you're using Windows. I've simply connected the Open vSwitch, ethernet zero module which is the Bolton Management Port of the Open vSwitch appliance that you get from the GNS3 marketplace, to the Cloud that's available in GNS3 2.0. I've once again got OpenDaylight installed on the OVA running in Windows, and I additionally have the DevNet GitHub OpenFlow app running on the same OVA. So everything is running on this ODL OVA, so both the OpenFlow app and ODL are running on that OVA. I've also got a Mininet OVA and just to get us started, I'll kickstart Mininet and get it to talk to the OpenDaylight controller. So in OpenDaylight when I click Reload you can see that we have four OpenFlow switches, and four hosts connected to this Topology and now within the Cisco app, I can see a similar Topology, I'll click this option here to show the host devices. I could zoom in as an example, and I've be able to view the flows on that OpenFlow switch. But we want to look at a GNS3 integration, so I'm going to shut down Mininet. So now when I click Reload on ODL, we see that no devices are connected and when I refresh, I'm told that it can't get the OpenFlow Topology data. Now the first thing we should do is check connectivity to the controller, this is the CLI for the Open vSwitch switch, so we do have connectivity to the controller. The next thing we want to do is configure the switch to talk to that controller. So what we're going to do is configure bridge br0, which is our OpenFlow bridge, to talk to the controller 192.16.1.65 on TCP port 6633 which is the OpenFlow port. Then we can use commands such as ovs-vsctl or vs-kettle if you prefer, to see if the switch is connected to the controller. And here we can see that, the connection is set to true, in other words this bridge br0, is connected to the controller on TCP port 6633. In other words on the OpenFlow port. A whole range of interfaces are configured as part of that bridge, but notice here ethernet one, as well as ethernet two are part of the OpenFlow bridge. In other words, the ports that router one and router two are connected two are part of the OpenFlow bridge and we can confirm that by looking at the OpenFlow ports. Port one, port two, are the two ports of interest. We can view the OpenFlow table by dumping flows, and we can see a range of flows have been written to the switch, the OpenFlow version that we are using is OpenFlow 1.3, this data-link type is LLDP, a flow entry was written with a priority of 100 and the traffic is being sent to the controller. This flow entry was written to table zero. Traffic coming in on port one is going to be matched on, and sent out of multiple ports including port two of the switch, this entry was also written to table zero and has a priority of two. We could look for port two in the output, so traffic coming in on port two, is also gonna be sent outta port one, as well as other ports. That means that router one should be able to ping router two, so let's confirm that. Router one has an IP address of 10.1.1.1, router two has an IP address of 10.1.1.2. So can router one ping router two? Yes it can, and I was running a debug here and notice we can see that an echo reply was sent back to router one. As an example, router two can ping router one and that's because of these flow entries that were written by the ODL controller. So in ODL, when we reload, we can see an individual switch. When I click on nodes we can see that it's a 16 port switch, we can see various interfaces, including local, ethernet one, and ethernet two. We can see the flow tables, and by default an Open vSwitch switch has 254 tables. So that doesn't show us a lot of data, I'll show you a better output in a moment. We can see that traffic is arriving on port one, and being sent on port one, as well as port two and the management stack of the switch. So traffic sent between router one and router two, and the local port is the local management stack of the switch. Here's the view on the OpenFlow application, from Cisco, when we click on Flow Management, we can see various flows have been written to the switch. So quite a few flows were written for that single switch to allow communication, we could look at one of the flows as an example and we would be able to see that it has a priority of two and in this example its traffic coming in on port nine, is gonna be sent out of multiple ports. So at the moment once again, router one can ping router two, what I'd like you to see is that the priority of these flows is two, quite a low priority. There's port one, so traffic coming in on port one is sent out of multiple ports. It has a priority of two, what well do now however is write a new flow entry to this Open vSwitch switch. The switch is using OpenFlow 1.3 for communication with the controller, it has 16 flows configured. So let's add a new flow entry, for our GNS3 switch. We'll write this to table zero, that's the only table that we have at the moment. Let's call this flow ID, abc, priority now I'm gonna set to 1000. In other words I'm going to make it higher than the other flow entries. I'll set a Hard timeout of 1000 seconds, in this example I'm gonna match traffic coming in on port one and the action that we'll set here, on the flow is to drop the traffic. So before I send that to the switch, that's a preview of the flow. So we're routing traffic to table zero, with an ID of abc, priority is 1000, Hard timeout is 1000 seconds, in other words, the flow will be removed after 1000 seconds. We are matching traffic coming in on port one, and we're gonna drop that traffic. Now before I send, the flow to the switch, notice we can ping from router one to router two. So let's send the request to the switch. And we had a success, so if we go back we should see our flow entry, there it is, abc and notice router one is not able to ping router 2. So if I clear this notice no pings are arriving. We don't see any output on the screen of router two. Router two is not able to ping router one. Now, if we do a debug on this side, what we should see is that the traffic from router two gets to router one but router one is not able to send it back to router two because we are dropping all traffic received on port one. So this flow entry, which we created is matching traffic on port one, and is dropping the traffic. So let's delete that flow entry. Flow entry has been deleted, can router one ping router two? Yes it can. Can router two ping router one? Yes it can. So let's write the flow back, and then look at it on the switch OpenFlow table. So we're gonna select the GNS3 switch, table is zero, we'll set the ID to abc again. Change the priority to let's say, 2000. We're gonna match traffic coming in on port one. I won't set a Hard timeout here, and we're gonna drop the traffic. So notice it's a drop for traffic coming in on port one of our GNS3 switch. Give it an ID of abc, let's send the request. It was successful, click back, refresh the flow table, there's our flow entry. Router one is not able to ping router two. And if we look at the flow table, we see a whole bunch of entries, but let's grep for 2000. Here's our flow entry that we created, notice priority is 2000, we are matching traffic in on port one and the action is to drop the traffic. This flow entry was written to table zero, we've had nine matches, or 12 matches on that flow, send some more pings, notice the packet count is going up as the packets are matched and dropped by the OpenFlow switch. So let's delete the flow once again, the flow has been removed. And router one can ping router two once again. So that was an example of a virtual OpenFlow switch, connected to the OpenDaylight controller using a Cisco OpenFlow application installed on the OpenDaylight controller. I was writing flows to the switch, to stop router one from pinging router two. That was an example of the software-defined networking architecture. We've got the Cisco application using a northbound interface to a controller and OpenFlow on the southbound interface updating the flows of an OpenFlow switch. Which in this example was an Open vSwitch switch running in a Docker Container within GNS3.