Computer Laboratory

Course pages 2013–14

Overview

In this portion of the project you will be integrating your router with the hardware. Your software router will configure the hardware via reading/writing registers, and send/receive packets through raw sockets bound to the card’s interfaces. You will be responsible for modifying your router to communicate through the hardware registers and adding the necessary CLI support for accessing registers.

Getting Started

For this part of the project you will abandon the Mininet framework. Your router server software will run on the machine physically connected to the NetFPGA board and communicate with the board using a driver. In order to make your router run in “cpu” mode, you will have to recompile it using the MODE_NETFPGA (-D_CPUMODE_) flag in the Makefile. On startup, a router in cpu mode will expect a hardware information file (i.e., cpuhw file). This file provides the interface information for the router. The provided base code reads cpuhw and calls your sr_integ_add_interface(…) for every interface it finds. An entry in this file should list the interface name, IP address, mask and MAC:

r0-eth0 192.168.1.1  255.255.255.0  00:00:00:00:00:01 
r0-eth1 192.168.2.1  255.255.255.0  00:00:00:00:00:02
r0-eth2 192.168.3.1  255.255.255.0  00:00:00:00:00:03
r0-eth3 192.168.4.1  255.255.255.0  00:00:00:00:00:04

You may want to supply a static routing table file (details below). A connection to the board may look something like:

$ ./sr -z r0 -r rtable.conf -i cpuhw

Once connected, you should be able to access the hardware registers and if implemented correctly, send and receive packets as before. In a nutshell, the hardware supports five packet channels. Four channels for the Ethernet ports (eth-ports) and one CPU channel (dma-port - shared amongs all the software interfaces). An incoming packet on an eth-port will be routed to any one of the five channels, according to the entries in the routing table. If it is routed to the dma-port, the software will be able to read it in. To send a packet out from software, write it to the appropriate dma-port and it will automatically be forwarded to the matching eth-port and sent out.

The static rtable file should either be empty, or contain a single default gateway entry, ie:

$ cat rtable
0.0.0.0 192.168.1.100 0.0.0.0 eth0

Instead of sending and receiving packets through Mininet, you will be responsible for reading them from raw sockets. After binding you are responsible for reading and writing packets to the sockets using your choice of methods.

To control the router, ie configure the routing table, etc., you will read and write 32 bit chunks of data to the card through well defined interfaces that will take as parameters: a structure representing the card, an address to read/write from, and a variable to read the data from or write it to. The addresses for these operations will be specified in reg_defines.h after you synthesize your project.

Register reads and writes will be handled by two provided functions, readReg(…) and writeReg(…).

Functionality you must Support

The software portion of the router is responsible for the following:

  • setting the MAC addresses on the card
  • setting the IP address filters on the card
  • responding to ARP requests
  • sending ARP requests
  • updating entries in the hardware ARP cache
  • timing out entries in the hardware ARP cache
  • queuing packets pending ARP replies
  • responding to ICMP echo requests
  • generating ICMP host unreachable packets
  • handling corrupted or otherwise incorrect IP packets
  • building the forwarding table via a dynamic routing protocol
  • handling all packets addressed directly to the router

Your router should already support much of the functionality listed. You will need to extend your implementation to be able to configure the hardware tables to mirror the software data-structures which can be considered the “master copies”.

Implementation Hints

  • You might find it helpful to extend your CLI to be able to read and write the hardware registers. This can be invaluable for debugging, as it enables you to determine the status of all registers at run-time. Similarly you may want to extend show ip route, show ip arp and show ip interface (show cpu ip route?) to dump out the hardware tables.
  • You will likely not be able to telnet directly into your router for this portion of the project. We suggest that you link your CLI code against the socket libraries on your development machine and then bind locally. This way you can telnet to “localhost” on your development machine and drive your router via the CLI.
  • We will provide you with a .bin file of the “golden” hardware solution to test against. In order to use this you will have to configure the interfaces with your allocated MAC and IP addresses.
  • When writing your routing table to hardware, ensure that it is written in longest to shortest prefix order, as (at least in the reference implementation) hardware will assume the first match is the longest prefix and route your packet based on that match.

Deliverables

For this milestone you will again submit your router source and update your design document to cover your approach to handling register read/write and operating with the hardware. Be sure to describe and extra extensions to the CLI you’ve added for debugging/testing. We should be able to configure the hardware reference correctly using your router.