0% found this document useful (0 votes)
4 views

Programming in POX

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views

Programming in POX

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Programming in POX - Open Networking Lab - Confluence Page 1 of 4

Home Bugs Forums

Pages / Home / Tutorials


Programming in POX
Added by Ali Al-Shabibi, last edited by Ali Al-Shabibi on Aug 15, 2012

• Objective
• Starting Mininet and POX
• Topology used during this exercise.
• Areas to complete
• Handling Switch connection (TODO 1)
• Flooding (TODO 2)
• Constructing and sending an ARP reply (TODO 3)
• ARP learning (TODO 4)
• Handling ARP requests (TODO 5)
• ARP/IP re-learning (TODO 6)
• Installing flowtable rules (TODO 7)
• Constructing a match object (TODO 8)
• Destination on same DPID (TODO 9)
• Destination on remote DPID (TODO 10)

Objective

The goal in this tutorial is to construct a shortest path forwarding application on top of POX. In _/pox/ext/routing/_
you will find a file named routing.py. This file is a skeleton of the entire applications. So, clearly the idea is to
complete the holes. There are many comments in the code which should guide you throughout the entire process.
On top of the comments, this document is intended to give you more hints about each area that needs to be
completed. Each which needs to be completed is labelled TODO followed by a number, we will refer to these labels
in this document. Note: That the TODO items are in no particular order other than the order they appear in the
code, ie. The TODO number does not signal an ordering of the completion of one or other item. Also, feel free to
inspect the code before starting the exercise and ask any questions you may have.

As for the API used in POX, refer to the POX manual here for more information.

Starting Mininet and POX

To start mininet, run the following command in your terminal:

openflow@TutorialVM:~/coder$ sudo mn --custom eth-topo.py --topo eth-topo --mac


--controller=remote

https://openflow.stanford.edu/display/ONL/Programming+in+POX 1/9/2017
Programming in POX - Open Networking Lab - Confluence Page 2 of 4

The sudo password is *********.

In another terminal, start POX:

openflow@TutorialVM:~/coder$ cd pox
openflow@TutorialVM:~/coder/pox$ ./pox.py --no-cli openflow.discovery routing.routing

Topology used during this exercise.

Areas to complete

https://openflow.stanford.edu/display/ONL/Programming+in+POX 1/9/2017
Programming in POX - Open Networking Lab - Confluence Page 3 of 4

Handling Switch connection (TODO 1)

When an OpenFlow switch boots up and is configured properly, it attempts to connect to a controller. In this
section we are going to handle these incoming connections, by storing a reference to the connecting switch so that
we can later send that switch messages. Also this may be a good place to initialise variables that are going to be
needed on a per switch basis.

Flooding (TODO 2)

The idea here is to construct a function that is able to flood packets at the network edge i.e. not on the switch to
switch links. This sort of flooding is done to avoid broadcasting of our core network where there may be loops.
Also, at this point your controller does not know where a particular hosts lives and therefore we must relay a
message at every network edge to make sure the destination see it. Have a look at the switch class (on line 257), it
contains code that will partially do this but it needs some input, namely a list of switch to switch links.

Constructing and sending an ARP reply (TODO 3)

At this point, you controller has probably resolved the ARP request on its own since it previously memorised a host
MAC and/or IP address. So rather than forwarding an ARP request to its recipient, you controller should construct
the ARP reply and send it straight back to the sending host.

ARP learning (TODO 4)

In order to speed things up and also forward IP packets around the network, we need to build ourselves an ARP
table. This is probably a good location to add entries to such a table.

Handling ARP requests (TODO 5)

Upon receiving an ARP request, your controller should verify whether it can fulfil this request itself or if the request
should be forwarded to very host in the network.

ARP/IP re-learning (TODO 6)

This is subtle point when using OpenFlow enabled networks. First, the requirement to re-learn the location of end-
hosts when dealing with IP packets originates from the fact that if the end hosts already know the MAC address of
their desired destination, they will start sending IP packets directly. Unfortunately, but this time you controller has

https://openflow.stanford.edu/display/ONL/Programming+in+POX 1/9/2017
Programming in POX - Open Networking Lab - Confluence Page 4 of 4

no idea where your end-host sits and therefore will flood the packet. If no learning occurs at this stage the
behaviour of the network is unaffected by communication latency is severely impacted. Once your controller is
working, run it with and without this section and observe the effects.

Installing flowtable rules (TODO 7)

Depending on whether your controller knows where the destination is, it should install the rules for this flow of flood
the packet. The actual act of installing the rules will be done by the install_path function a few lines below.

Constructing a match object (TODO 8)

When installing rules on an OpenFlow network, you need to specify which headers your rule should match on.
Fortunately, this can be done automatically from a packet in object. See the POX WIKI for more details.

Destination on same DPID (TODO 9)

If the destination is on the same DPID then it should be pretty straight forward to install the rule give that you only
need to install the rule at one switch/DPID.

Destination on remote DPID (TODO 10)

In order to avoid having PacketIns for every switch/DPID on the path to the destination, you should probably install
rules from the destination to the source (i.e. in reverse order). This will involve computing the DPIDs on the path
and the port pairs they will be travelling through. Fortunately, each switch object maintains a paths variable which
provides the entire path to every destination.

No labels

Powered by a free Atlassian Confluence Open Source Project License


granted to OpenFlow. Evaluate Confluence today.

https://openflow.stanford.edu/display/ONL/Programming+in+POX 1/9/2017

You might also like