Computer Network Design - Lab 1: Getting to Know Your Neighbours
NWEN 302: 2019 Trimester 2
|Assigned:||29 Jul 2019 (Monday)|
|Due:|| 11 Aug 2019 (Sunday) for Part(a) - code only;
2 Sep 2019 (Monday) for Part(b) - code and report;
SUBMISSION OF REASONABLE ATTEMPTS FOR BOTH PARTS ARE MANDATORY.
- Computer Network Design - Lab 1: Getting to Know Your Neighbours
- Your problem
- Tools For This Lab
- Lab Setup
- What to hand in
- Grading Scheme
Your problemThis lab is divided into two parts. In Part (a) you will implement address resolution function for both IPv4 and IPv6 protocols. In Part (b) you will program a learning switch to deal with unknown traffic. IMPORTANT While it is possible to complete the lab as it stands, you will likely see debug information for ACK timeouts and checksum errors. Optionally, you can download the patch here to amend this. Remember to check the readme!
Part (a) - Address ResolutionThis is used to resolve link layer addresses based on a prior known network layer address; it is a critical function in multiple-access networks. These protocols can be considered a method of routing within a MultiAccess single hop network segment such as Ethernet, Wifi, Zigbee, etc. IPv4 uses the Address Resolution Protocol (ARP) and IPv6 uses parts of the Neighbor Discovery Protocol (NDP). These are very similar processes, but as you will discover they have key differences.
Part (b) - Learning SwitchSwitches are used to connect several machines with a LAN and prevent link-layer traffic from being sent to all hosts on the LAN by learning which machines are connected via which links. Part B is written by Joel Sommers, the author of Switchyard. It can be found on his github page for switchyard. The descriptions of part B here are extracted from here and you may find that useful to read before starting on Part (b). Note, you will NOT be required to the implement spanning tree described there. Both Part (a) and Part (b) will be implemented within the network simulation environment Mininet and use the Python library Switchyard to program the network stack. Important note: your submission will be tested on an ECS machine so make sure to test your solution on an ECS machine before submitting.
IMPORTANT NOTE:This lab handout is in no way a complete or accurate reference to the protocols you will be implementing. Do your own research, find out as much as you can about the protocols and use that as the basis of your implementation. Remember to credit, i.e. cite, the source(s) of your information.
Tools For This LabYou may wish to spend the first hour or so of your first preparing these tools and copying the files required. This lab will make use of the following tools:
Virtual BoxVirtual box is installed on the ECS workstations and hosts virtual machines (VMs). A VM emulates a regular computer within a virtual environment, accessible like a regular application.
Installing the provided VMThe virtual machine for this lab can be copied to your ECS workstation with the commands below.
mkdir /local/scratch/<your-username> cp /vol/courses/nwen302/nwen302-labs.ova /local/scratch/<your-username>IMPORTANT: Before progressing you will need to change the default folder for Virtualbox VMs, to do this, in VirtualBox navigate "File -> Preferences -> General -> Default Machine Folder" and set this to /local/scratch/username/VirtualBox VMs. If you have already imported without changing this directory, remove old VM in virtualbox and add it again using "Machine -> Add". (Thanks Ciaran for pointing this out!) Once copied, you need to import the VM image into Virtual Box. To do that, open/execute Virtual Box and select file->import, choose the nwen302-labs.ova file in /local/scratch/ and click import. If you have trouble finding Virtual Box, execute the following in command line to start it:
virtualbox &PLEASE TAKE NOTE OF THE FOLLOWING:
- Due to its (large) size, this file will likely fill your ECS profile data allocation, which is why the command places it in a folder on your current workstation and not in your home folder.
- This means it will be stored on a single machine. While it is possible to access this from other ECS machines or copy it, you may find it more convenient to use the same machine throughout the duration of this lab. For information on accessing these remotely, see working from home or ask your tutors.
Setting up network interfacesTwo kinds of network interface are useful for this lab. These are NAT and Host-Only networks. To create a NAT network, in Virtualbox navigate to file -> preferences -> network, and click the "Add new NAT network" button. Refer to the screenshots below to configure the NAT network (defaults should be fine). To create a Host-Only network, in the main Virtualbox window go to "Global Tools" in the top right and click "Create". Refer to the screenshots below for the configuration (defaults should be fine). Optionally you can create a DHCP server on the NAT interface, but this is not required for this lab. Once these are created the networks will need to be associated with the VM. To do this click on the virtual machine, click the settings button and navigate to the Network menu. As per the screenshots select NAT and Host Only networks under adapter 1 and adapter 2. Note the "vboxnet0" here is the name of the host-only network created above.
Mananging and accessing files on VMTo start your VM use the start button in virtualbox. This will give you command line access to the virtual machine on screen. It can be shutdown via the terminal or with the virtualbox GUI. If a host-only network is enabled, you will be able to SSH into the machine or access file via SCP or FISH (Files transferred over Shell) protocols. Use SSH from a terminal on your host machine to connect to the VM. FISH is a handy protocol for viewing files in dolphin (the free and open source file manager included in the KDE Applications bundle.) In dolphin simply enter fish://firstname.lastname@example.org/ in the address bar (click on the folder structure to open the address field as the bar isn't immediately visible) and you'll be able to view the folders and directories quickly. It is strongly recommended that you make a bookmark to this folder for easy access. It's also recommended you use the text editors kate, kwrite or atom when using the ECS machines when using fish to access files -- some of the other text editors are not able to properly save remotely opened files! This labscript assumes you connect to the VM via SSH and not starting Mininet within the main virtual machine window. SSH on the lab machines allows you to start Mininet host xterm windows correctly. Use the command:
ssh -X email@example.comThe '-X' option is important! Without it, you won't be able to open xterm windows on the VM. There is the option for starting the VM in 'headless' mode, which does not display the main window (dropdown option on the "start" button in VirtualBox. Alternatively you can use the command:
VBoxHeadless -s nwen302-labs &
MininetMininet is an emulated network environment which creates hosts and switches and allows traffic to pass between them. It's main area of concern is in testing Software Defined Networks (lab3 will cover this), however it can be used to efficiently host a network environment on a single computer. To start the default network (one switch and two hosts) in Mininet use the command:
sudo mn --macThe --mac argument will number the MAC addresses on the emulated hosts, starting at 00:00:00:00:00:01, and incrementing the last byte. Without this they will be randomly assigned. For more hosts, you may use the command
sudo mn --mac --topo=linear,1,4where the final number represents the number of hosts. The source code and documentation for Mininet can be found on github. A script for starting Mininet with Switchyard and synchronising the number/addresses of hosts for Part (a) has been provided with this handout. Part (b) uses a more sophisticated script when starting Mininet.
Mininet commandsMininet allows you to control the hosts via command line or launch separate terminals for each of the hosts in the network. Try the following:
h1 ls h1 ifconfig h2 ifconfig h1 ping h2 xterm h1
SwitchyardSwitchyard is a Python library designed for learning about network behaviour and prototyping network protocols. It takes the place of an operating system's network stack and allows the user to define the behaviour between physical and application layers. To start Switchyard on a host use:
cd lab1/parta python3 switchyard/swyard.py main.pyThere is a copy of switchyard in the directory for both part (a) and part (b). By default the python debugger (pdb) is turned on. If your code encounters an error this will run, providing you with a python REPL for debugging what is happening. Command u and d will ascend and descend the call stack. To turn this off, add the argument --nopdb when running Switchyard. To quit use the command q, then ctrl-c. The source code and documentation for Switchyard can be found on github. The introduction to packet parsing and construction will be very useful for this lab. Additional packet classes for ICMPv6 not included in the documentation you might find useful are documented online at ICMPv6 for switchyard documentation. This is also available as a file: icmpv6.md. NOTE: Be sure to only start Switchyard on the mininet hosts! By default it sets the firewall to block traffic, which will disable any active SSH connections.
Lab SetupThe attached file NWEN302-2019-T2-LAB1.tar contains all the files required to begin the lab. This includes a working copy of Switchyard with Part (a) and Part (b) code templates. This is for reference or if you wish to restart fresh. All files are already on your virtual machine and ready to run.
Part (a)The included files replace the network stack of a host. The protocol layers link, network and transport are represented by the files link_layer.py, network_layer.py and transport_layer.py. They represent a working transport layer with empty IP and Ethernet layers. An application which generates data to send between hosts is included also. preferences.py is used to control the number of hosts in Mininet and addresses of hosts in switchyard, use the script start_mn.sh to change the number of hosts in the network. A rudimentary address mapping is provided that simply maps IPv4 and IPv6 addresses to known hardcoded MAC addresses on the assumption you are using three or less hosts and the --mac argument when launching mininet. Your objective is to replace this with a dynamic solution. It is recommended that you begin by assigning the correct headers to the data being passed down the stack for the respective layers with the hardcoded MAC addresses and get messages successfully passing from host to host. Once this is complete, investigate what protocols and packet types are used for IPv4 and IPv6, and implement address resolution for each to replace the hardcoded MAC addresses. The advanced section of Part (a) and Part (b) will require having entries expire and limiting the size of the address caches. To run the supplied code, unpack the attached file and in the directory containing the contents, do the following:
$ sudo ./start_mn.shThis will present you with a mininet terminal from where you can start an xterm for hosts to run the provided code:
$ xterm h1 $ xterm h2 $ ...(Check the names of your hosts, they may be called hX as above or hXs1.) And run the code in the host terminals:
$ sudo python3 lab1/parta/switchyard/swyard.py lab1/parta/main.py -dThe -d argument will toggle the debug messages from switchyard.
- Use the IP protocol number/next header value for UDP (17) when handling StopAndWait packets.
- The addition operator ("+") can only be used once when creating a packet. Use the add_header() or prepend_header() methods (depending on whether the new header needs to be appended to the beginning or the end) when merging an existing packet with a new header -- useful at the Link Layer.
Part (b)The files provided are for starting mininet (switchtopo.py), a detailed description of the lab (learning_switch.rst), and a bare switchyard file that currently acts like a hub (myswitch.py) forwarding traffic on all available ports. These will be run similarly, starting mininet using:
sudo python lab1/partb/switchtopo.pyOnce Mininet has started, open an xterm for the switch you will be programming, then run the following command to start your code on the switch:
sudo python3 switchyard/swyard.py lab1/partb/myswitch.py(note here that python runs the Mininet script and python3 runs Switchyard) Your understanding from Part (a) will be helpful in deciding where to begin. Remember the protocol layer(s) that a switch operates on and read the description by Joel Sommers. Note again, you will not be required to the implement spanning tree described there.
Part (a)Roughly speaking, your address resolution component will need to do (at least) the following:
- Maintain some form of data structures mapping IPv4 and IPv6 addresses to MAC addresses. This can be a simple or as sophisticated as you like but justify your choice of data structure in your report.
- When asked by the network layer for the MAC address corresponding to a supplied IP address, return it if you have it, or send a Request to find it. It is your choice whether you block waiting for the response or return immediately and force the transport layer to try again later. Whichever mode you choose, justify it in your report.
- Identify whether the packets received from Ethernet are ARP or NDP messages.
- If required, send a Request/Advertisement message.
Part (b)The implementation for part B is similar to the address resolution sections at the beginning of Part (a).
- Maintain a mapping of MAC addresses to port within the switch.
- Packets destined to an unknown MAC should be broadcast on all except the incoming interface.
RequirementsThis lab is broken into two parts
- Part (a) - Implementing IPv4 ARP and the address resolution features of IPv6 NDP
- Part (b) - Implementing a learning switch that supports both IPv4 and IPv6
- After a 30 second test, each node's address table should have a full list of all other node's MAC to IP address mappings.
- Request/Solicitation packets are not sent when an appropriate entry already exists in the address table.
- Use standardised ARP and Neighbor Discovery packet headers with the correct values.
- The address table is updated on receiving an Request/Solicitation message, not simply when receiving an Neighbor Advertisement message.
- Address entries timeout.
- Address table is of limited size (and less than the number of nodes in a given topology).
- After 30 seconds the switch's address table should have complete mappings for all attached hosts
- Subsequent unicast messages should only be forwarded on the correct switch interface, host receiving only mulitcast/broadcast traffic and traffic addressed to them.
- Packets should not be altered by the switch
- Address entries timeout.
- Address table is of limited size (and less than the number of nodes in a given topology).
What to hand in
Due on 11 Aug 2019 (Sunday) for Part(a) - code only;
Due on 2 Sep 2019 (Monday) for Part(b) - code and report;SUBMISSION OF REASONABLE ATTEMPTS FOR BOTH PARTS ARE MANDATORY.
- All relevant code. i.e. all the supplied files and any new ones you’ve added. At the very least you will have significantly modified network_layer.py and myswitch.py and made small changes to link_layer.py.
- If you have "borrowed" code from on-line resources and/or other sources, say so in your code comments.
- Submit as a .zip or .tar archive, not a million individual files, please.
- The mininet topology used, either as a script or as a line of code.
- This may just be a modified start_mn.sh, but if you have a new one, don't forget to submit it.
- A short report (around 1,000 ± 100 words - be concise) describing your development process for BOTH Part (a) and Part (b).
- State which of the requirements listed above you believe you have successfully implemented.
- Reflect on what you found easy, what caused you problems and how you overcame those issues.
- If you believe you have a particularly sophisticated or original implementation, state why you think this is the case.
Does it work? (70%)
- Basic - Part (a): 25% and Part (b): 25%
- Advanced - Part (a): 10% and Part (b): 10%
Is the code well written? (20%)
- Part (a): 10% and Part (b): 10%
- Marks awarded for:
- Compilation free of errors and/or warnings.
- Giving credit to on-line resources you “borrowed" code segments from.
- Evidence of original work (i.e. not simply having copied other peoples code).
- Marks deducted for:
- Not giving credit to on-line resources you “borrowed" code segments from.
- Not following standard packet header formats
Did you understand what you were doing? (10%)
- The code partially show this, but the report is where you convince me.
- Marks awarded for:
- Clearly stating which requirements were met and which were not (and why).
- Description of development process.
- Details of testing methodology.
- Observations of what was easy, what was hard, where problems arose, how they were overcome.
- Reflection on how you might improve or extend your solution.