Description

For this assignment, we will be using the Pyretic controller to program the switches. Much of the difficult parts are abstracted out in the helper file included within the assignment, but there are some features that you will need to read up on. See the wiki and this page in particular to get a feel for the language
Before getting started, you will need to update your CS6250 repository using the following commands from the 2015-Summer-OMS6250 directory:
git commit -a -m “Saving work”
assignment-2 directory, there are six files. You can read up on __init__.py
In the newhere and
helpers.py
-topo.py
here. contains helper functions. You will need to use the print routines in it to output your results in a format that we can grade. The files that end with are the topology files that you will use to run the assignments. You will not have to modify them. The final two files are the assignment files.
Part 1 – Static Switching
Static switching is where we manually fill in switch tables matching destination MAC address to the port the packets should go out of. It is similar to how static routing works, except at the MAC layer rather than IP layer. There are serious problems, however. First, it doesn’t scale well – for each end host, each switch must have a forwarding path programmed in. Second, it cannot handle dynamic changes – if a host moves from Switch A to Switch B, many, possibly all, switches have to have the forwarding path updated. Third, it’s highly error prone.
What it does do is provide us with a good example of how to deal with Pyretic, in particular manipulating packets and creating forwarding behaviour. It also shows us how forwarding behaviour is implemented by keying off of the destination MAC address to make forwarding decisions.

The topology we are using is above. In code, Switch 1 is Switch A in the diagram above, and Switch 2 is Switch B. This is to simplify descriptions using the diagram, and limitation Mininet.
static-forwarding-topo.py
1. Look in the file . This is a description of the topology. It’s very simple. You can start this by, in one terminal, running the command
sudo python static-forwarding-topo.py
Unable to contact the remote controller
, you can ignore that. As long as you get the
mininet>
Exception: Error creating interface pair: RTNETLINK answers: File exists
sudo mn -c
on subsequent runs. You can run to clear this.)
mininet>
h1 ifconfig
From the prompt, you can run commands on hosts/switches by giving the name of the host/switch followed by the command. For example, will run ifconfig on host h1. This can be useful for querying the topology for details about the hosts/switches.
static-forwarding.py in the sections marked TODO
1. Now, you will need to make changes to .
As it stands, this file will not run without your modifications. There is significant example code that you can base your code on.
00:00:00:00:00:01
addHost() ), 00:00:00:00:00:02
ff:ff:ff:ff:ff:ff
You also need to make sure the broadcast MAC is forwarded to all ports. Some starter code for this is provided.
helpers.py
static-forwarding.log using the open_log()
1. When you written up your forwarding table, you mustwrite out your forwarding configuration. Use the functions at the beginning of . First, open a file with the name function, write out all the forwarding table
entries (order doesn’t matter), then close the file with `finish_log()’.
2. To run your code, you will need to copy it over to the pyretic directory, then run it with Pyretic. To do this, you’ll need to use the following commands. cp static-forwarding.py helpers.py ~/pyretic/pyretic/modules; cd ~/pyretic; python pyretic.py -m p0 pyretic.modules.static-forwa
or use the provided run script for more convenient use.
Part 2 – Learning Switch
Learning Switch Review
We’re going to go over how learning switches work again, just in case, using the topology from the first part of the assignment.

When the topology has just come up, the switch tables are empty. When a packet goes from Host 1
(with MAC address 1, for simplicity’s sake), and is destined for Host 2, it first goes to Switch A. Switch
A will record which port Host 1 came in on. Since Switch A does not know where the MAC address for 2 is, will flood and send a copy of the packet to both remaining ports. It will reach Host 2, but it will also reach Switch 2. Switch 2 will save off how to get to Host 1 (via Switch 1), and flood to hosts 3 and 4.
If, afterward, Host 3 is trying to send a packet to Host 1, Switch B learn how to get to Host 3, will not flood and send it directly to Switch A. Switch A will also learn how to get to Host 3 (via Switch B), and forward directly to Host 1.

Above is the topology provided for the assignment. There are significantly more switches than in the review, however this allows for more test cases possible. You will be able to use both this topology and the one for the static part of the assignment for testing purposes.
Completing this part of the assignment is similar to the first half.
learning-switch-topo.py
1. Look in the file . It’s much more complicated than
static-forwarding-topo.py
but you can run in the same way. You can (and should!) use both
topologies for your own testing.
learning-switch.py
learn_route()
2. In there are significantly more TODOs than in the first half. The biggest difference is filling in the function. You have lots of different ways of handling the forwarding table, and it’s up to you to decide on the right thing to do. We’ve placed suggestions in the file that you can follow or ignore if you have other ideas. Logging is different this time. At the beginning, you must open the file as before with the filename
learning-switch.log . You should fill in print_switch_tables()
by logging all entries in the log
next_entry()
file as before, then calling once logged each entry in the switch table. This is so we get a view over time of the changes in the switch forwarding table.
ff:ff:ff:ff:ff:ff
You also need to make sure the broadcast MAC is forwarded to all ports. Refer to the starter code from the static forwarding portion to see how this can be done.
1. Running your code is similar to before. To do this, you’ll need to use the following commands. cp learning-switch.py helpers.py ~/pyretic/pyretic/modules; cd ~/pyretic; python pyretic.py -m p0 pyretic.modules.learning-switc
or use the provided run script for more convenient use.
What to turn in
You will need to turn in two files:
static-forwarding.py
learning-switch.py
1. 2.
The autograder will run each piece of code and verify its output file. BE SURE TO USE THE CORRECT FILE NAME OR YOU WILL RECEIVE A ZERO.
For the static forwarding part, we will use the exact same topology as you did.
For the learning switch, we will be using a different topology so that you can be sure that your code is actually learning.
For the learning switch, do not use outside code. There is plenty of it existing – which you can review, but not use.
This page was last edited on 2015/05/26 12:31:51.

© 2011-2015 Udacity, Inc.