Welcome back. We are continuing our study of the control plane and in particular we are continuing the lesson where we've been exploring how to use SDN controllers to customize network control. In the previous part of this lesson we explored how to use the POX controller to implement a simple layer two learning switch. In this part of the lesson we will extend that layer two learning switch to make forwarding decisions based on simple firewall rules that we install at the controller. The purpose of this lesson is two fold. The first is to illustrate how easy it is to make fundamental changes to network behavior with very simple changes at the controller. The second is to give you some more exposure to the POX controller. So to review what we did in the last lesson, we used the POX controller to install simple flow table rules at the switch that matched on the MAC destination address, and took the particular action of forwarding the packet out a particular port. More sophisticated switching is also possible. We can, for example, install flow table rules that match on many more specific fields in the packet header. Thus allowing the switch to make specific forwarding decisions for different flows. We can also use flow rules to implement a firewall. For example, we could have the switch make forwarding or drop decisions, based on the value of the source MAC address. In this lesson, we will explore how to make simple changes to the layer two learning switch, to implement this firewall example. Let's revisit the topology that we've been working with in the last few lessons. Again we have a switch that connects three hosts, and we'll attached a controller to that switch. But instead of attaching a controller that performs simply layer two switching, we will augment, the functions being performed by that controller, so that it checks the source MAC address of incoming packets. And decides whether to forward or drop the packet, based on the value of that source MAC address. If the controller decides that the packet should be forwarded, then it proceeds to perform the layer two switching functions as before. Let's revisit the POX learning switch algorithm from last lesson. This is exactly the same as what we looked at last time. Except we're going to add an additional step where the controller checks the source MAC address against specific firewall rules that inspect the source MAC address against forwarding or drop decisions. This additional function requires only a few, simple additions to the controller. First, we need a hash table that stores key value pairs. In particular, that hash table must map the switch identifier and the source MAC address of the packet to a true/false value indicating whether the packet should be forwarded or dropped. The controller will decide to drop the packet if there's a firewall entry that maps to false or if there is no firewall entry for that source MAC address. The controller will decide to forward the traffic if there is a firewall entry that maps to true. Let's take a quick look at those changes in the POX code itself. So you can recognize from before the first step of the switching algorithm that maps the packet source MAC address to the incoming port and the subsequent steps that the switch takes. We have simply added a rule that checks whether or not there is a firewall entry for that source MAC address at that switch. If the entry returns false, the switch drops the packet. Otherwise, it continues as before. Let's take a quick look at what we had to do to implement check rule. Here, we made a simple change to add a hash table. The hash table stores mappings for particular source MAC addresses. We can manipulate the hash table with the add rule method, which takes as input, the ID of the switch, a source MAC address, and a true or false value indicating whether or not the package should be forwarded. The check rule function simply checks to see whether the hash table has an entry for that particular switch ID and the source MAC address, and if it does have an entry, it checks to see whether the entry is true or false. The function returns true only if the firewall hash table has an entry for that source MAC address that maps to true. In addition to defining the methods for manipulating the firewall, I've also added a couple of rules to our firewall for that particular switch. Which effectively allow packets from hosts with MAC address of one or two to forward packets through that switch. All other traffic will be dropped. Let's now take a look at our new controller in action. I'll first start the Mininet topology with three hosts and a switch and then I will connect our new controller to that switch. We can see now the controller listening for the firewall. And now, the firewall connects. And the controller adds two rules. One that allows hosts with MAC address one to forward traffic. And the second that allows hosts with MAC address two to forward traffic. We can see, of course, that there is no rule that allows host three to forward traffic. Now, let's try the ping all experiment. We can see that host one and host two can communicate with one another but any traffic involving host three is blocked. We can also see from the debugging messages that the controller decided to forward or drop different packets depending on the value of the source MAC address of the incoming packet. It is also interesting to note that when the controller decides to forward a packet, it also installs a rule in the switch that allows that packet to be forwarded. As long as that flow table entry remains in the switch, all packets that match that flow can continue to be forwarded at the switch. To see the effect that, that behavior has on performance, let's have host one ping host two. So we can see that initially the first packet experiences very high latency. That is because that packet is redirected to the controller. Once the controller decides, however, that host one can send traffic to host two and vice versa and those rules are installed in the switch, packets are forwarded directly by the switch until that flow table entry expires. And you can see that at about 30 seconds the flow table entry expires again and we see relatively higher latency between the two end hosts because the traffic is redirected to the controller. We can see here the importance of caching forwarding decisions that the controller makes at the switch. It's very important to limit the data traffic that gets sent to the controller. As we can see, traffic that gets sent to the controller experiences a much higher latency than traffic that can be forwarded directly through the switch. Therefore, when the controller decides to forward or drop the traffic, the switch's flow table is modified. Those modifications then prevent data traffic from being redirected to the controller, for as long as that flow table entry remains in the switch. In summary, we've seen that customizing control is very easy with SDN. We've made a few small changes to the layer two switch to enable firewall capabilities. We've explored how we can implement this type of alternate control. And we've turned a switch into a firewall in less than 40 lines of Python code. We've also demonstrated the performance benefits associated with caching forwarding decisions at the switch, to avoid having to send data traffic to the controller whenever possible.
