Cusomizing SDN Control. Part 1 (Eng) — Network Technologies in Distributed Computing Systems

Welcome back.

We are continuing our discussion of the control plane, and in this lesson we will

look at how to use an SDN controller to customize the control plane behavior.

We will use the POX Controller that we discussed in the

last lesson for the examples that we will explore in this lesson.

0:24

We'll review the basic operation of a hub and a

switch, then we'll use Mininet to set up a simple topology

and we will use the POX Controller to control the

behavior of the switch that we set up in that topology.

0:43

We will then use the POX Controller to implement

two different types of control in the network topology.

A hub which simply forwards all traffic out all of the output

ports and a learning switch which learns forwarding table

entries based on the ports on which incoming packets arrive.

For both examples we will look at the flow

table entries using dpctl and in particular we will explore

how the flow table entries differ and we'll also walk

through the code for each of these two control examples.

1:28

Let's first use Mininet to set up an example topology as we've done before.

1:35

We'll use a simple three node topology with

a single Open vSwitch to connect those three nodes.

1:44

Even without a controller, we can use dpctl to communicate with that switch to

perform operations such as examining the current

flow table entries that exist in the switch.

1:58

Using Mininet, we set up our single three node topology with an Open

vSwitch and the option that specifies we want to use a remote controller.

2:10

At this point, we have three hosts connected by a

single Open vSwitch, but we have not yet instantiated a controller.

2:21

Therefore, if we try to ping between the host and the

topology we see that the hosts can not actually reach one another.

This is also corroborated by looking at dpctl.

2:37

If we dump the flow table entries and the switch, we will see that the switch

actually has no flow table entries, which is

why the hosts are unable to reach one another.

Before we attach a controller that behaves like a

hubber switch, let's first review what a hub does.

In a hub, no forwarding information is actually stored

at the switch that connects the hosts and the network.

Therefore, when an input packet arrives on a particular port, the

switch simply forwards that packet out all of the output ports.

3:18

To see how this works with POX, let's look at the POX Hub application.

The place to start looking at the code is in hub.py, which contains two functions.

3:38

One is a method called launch, which just adds a listener

that listens for OpenFlow switches to connect to it.

3:53

In this case, when we launch the Hub, the Open vSwitch that

we created with the Mininet topology, will attempt to connect to our hub.

Let's now take a quick look at what happens

when we start the POX Controller using the hub functionality.

What we see here when we start POX is a little bit of information including

information about the OpenFlow switch that has connected to this hub.

4:26

That switch in particular is the Open

vSwitch that we've created in the Mininet topology.

If we look at our new Mininet topology we can see

that we now have a controller designated as C0.

That is the POX Controller running the Hub functionality that

we will now look into in a little bit more detail.

Going back to the code in hub.py, we can now see what happens when the POX

Controller receives a connection attempt from an OpenFlow switch.

What's shown here on the slide is the

entire POX code for implementing a hub controller.

The handle connection up method simply creates a flow

modification message that we will send back to the Open

vSwitch, telling the switch to modify its flow table entries.

5:33

So we first create the message, and in that message, we append a specific

action which simply is to send the packets on all of the output ports.

Once we've created that OpenFlow flow

table modification method, we simply send that

message to the switch on the connection that we have from the Open vSwitch.

6:02

If we now try to ping all of the nodes in topology, we see that all

of the nodes can reach one another, and if we use dpctl to look

at the flows that are stored in the Open vSwitch, we can now see

that there's a flow table entry whose action is to flood.

6:26

So to review what we just did, we took our Mininet topology and

we started a POX Controller running hub.py, which simply

executed the functionality that we showed on a previous slide.

6:47

Now, what we're going to do is change the

control methods that are running at the POX Controller

so that the controller can cause the switch to implement

a learning switch rather than just a simple hub.

7:08

Let's first review what a learning switch does and how it differs from a hub.

7:15

So if you recall, when a packet arrives on an input port at a hub,

the hub simply forwards that packet on all of the output ports.

7:26

A learning switch, on the other hand, behaves

a little differently because when that input packet

arrives, the switch learns how to reach the

particular destination that sent the packet to the switch.

7:47

For example, in the figure here, we see that a packet arrives from A.

At that point, the switch can examine the source MAC address

for that packet and then determine that packets that are

destined for that source MAC address for A should be sent

on the output port on the left side of the switch here.

8:19

In other words, each incoming frame causes the

switch to create a new flow table entry.

To cause the POX Controller to induce that behavior on the Open vSwitch,

we attach the POX Controller as before, but instead of running the hub

code that we just looked at we are going to run a different set of methods

which is in the l2_learning.py file in the POX distribution.

Let's jump in and take a quick look at the

learning switch algorithm that is implemented in that Python file.

[BLANK_AUDIO].

The algorithm has several steps.

The first step is to use the source address of the packet

and the switch port to update the address and port table

that the controller itself maintains as a hash table.

The

9:32

second is to drop certain types of packets.

9:37

The third is to check whether the

destination for the packet is a multicast destination.

If it is, the controller instructs the switch

to flood the packet on all output ports.

If the destination address for the packet is not already contained

in the hash table that's being maintained at the controller for

mapping addresses to ports then the controller instructs the switch

to behave like a hub by flooding the traffic out all output ports.

If the output port is the same as the input port,

the controller instructs the switch to drop the packet to avoid loops.

Otherwise, the controller sends a flow table modification entry to the switch.

That flow table modification entry is similar to the one we looked

at in the hub example, but the difference is that the flow table

entry is specific to the port on which the packet arrived and that address

that's contained in the source address field of the incoming packet.

10:58

What the controller does is take that source address for the packet and the

incoming port on which the packet arrived and inserts a flow table entry

in the switch that instructs all future packets destined for that address to be

forwarded only out that output port rather than being flooded out all output ports.

Let's clean up the Mininet topology that we had before and start it again.

11:32

Now, instead of attaching the POX Controller with the Hub

control logic, let's instead attach a POX Controller that

runs the learning switch algorithm that we just went through.

So once we start the controller we see that, as

before, our Open vSwitch has connected to the controller and if

we try to ping all of the hosts we can

once again see that the hosts can communicate with one another.

Now that behavior looks the same as before, but the

difference arises when we look at dpctl to dump the floats.

What we see now in the switch are a bunch of different flow table entries.

What we can see is that each flow table entry has a particular destination address

and the output port on which packets for that destination are to be forwarded.

12:38

Let's take a very quick look at the

Python code that is running at the POX Controller.

Now, as before we have a launch method which registers

the l2 learning object with the core POX Controller.

Upon being instantiated that object adds a listener

to ensure that it can handle connection up events from

OpenFlow switches that try to connect to this controller.

Upon a connection attempt from an OpenFlow switch, this object then instantiates

the learning switch object and passes the connection event to that object.

When we dig into that particular object, we can see that upon

instantiation we create that hash table mapping the addresses to ports.

13:45

We add a listener for packet in messages

and then we implement the packet in handler.

13:55

I will not go into all of the

details of the implementation of the packet in handler,

but let's just jump down to the portion

of the code that implements the learning switch algorithm.

14:09

So, if we jump to this particular line, we can see the beginning of the algorithm.

The first step being to assign an entry in the MAC to port table that maps that

packet's source MAC address to the port on which the packet arrived.

To drop certain types of packets, to flood if the

packet's destination is a multicast packet, to

flood if the packet's destination is not already

in the MAC address to output port mapping, to check

whether the designated output port, if it exists,

is the same as the port on which the packet arrived and to drop

the packet if the input port and the output port are the same.

And finally, installing a flow table entry in the Open vSwitch that matches

on the particular packet properties and sends the packet out the output

port corresponding to the port that it just learned that it should send

future packets out on based on the port on which the packet arrived.

Finally, once that flow modification message is

created, the controller sends it to the switch.

In summary, we reviewed the basic operations of a hub and a switch.

We set up a simple Mininet topology and used the POX Controller to

implement hub and switch functions, and we explored how to implement

these two types of control inside the POX control framework.

16:07

We looked at how the behaviors differed in terms of the flow table entries and the

switch using dpctl, and we also walked through the code itself.