In this assignment you will write a simple router given a static network topology and routing table. Your router will receive raw Ethernet frames. It will process these packets just like a real router and then forward them to the correct outgoing interface. Your are responsible for implementing the logic for handling the incoming Ethernet frames (forward them, generate ICMP messages, drop them and more).
Your router will route real packets from a emulated host (client) to two emulated application servers (http server 1/2) sitting behind your router. The application servers are each running an HTTP server. When you have finished the forwarding path of your router, you should be able to access these servers using regular client software. In addition, you should be able to ping and traceroute to and through a functioning Internet router. A sample routing topology is shown below:
If the router is functioning correctly, you should be able to perform the following operations:
Additional requirements are laid out in the 'Required Functionality' section.
This assignment runs on top of Mininet which was developed at Stanford. Mininet allows you to emulate a topology on a single machine. It provides the needed isolation between the emulated nodes so that your router node can process and forward real Ethernet frames between the hosts like a real router. You don't have to know how Mininet works to complete this assignment, but more information about Mininet (if you're curious) is available here.
Path to the Virtual Machine image: /home/linux/ieng6/cs123f/public/vmcse123-p2.zip
There are two configuration files.
The default IP_CONFIG and rtable should look like the following:
> cat ~/cse123-p2/IP_CONFIG
server1 192.168.2.2
server2 172.64.3.10
client 10.0.1.100
sw0-eth1 192.168.2.1
sw0-eth2 172.64.3.1
sw0-eth3 10.0.1.1> cat ~/cse123-p2/router/rtable
192.168.2.2 192.168.2.2 255.255.255.255 eth1
172.64.3.10 172.64.3.10 255.255.255.255 eth2
10.0.1.100 10.0.1.100 255.255.255.255 eth3> cd ~/cse123-p2/
> ./run_mininet.sh*** Shutting down stale SimpleHTTPServers
*** Shutting down stale webservers
*** Successfully loaded ip settings for hosts
{'server1': '192.168.2.2', 'sw0-eth3': '10.0.1.1', 'sw0-eth1': '192.168.2.1', 'sw0-eth2': '172.64.3.1', 'client': '10.0.1.100', 'server2': '172.64.3.10'}
*** Creating network
*** Creating network
*** Adding controller
*** Adding hosts:
client server1 server2
*** Adding switches:
sw0
*** Adding links:
(client, sw0) (server1, sw0) (server2, sw0)
*** Configuring hosts
client server1 server2
*** Starting controller
*** Starting 1 switches
sw0
*** setting default gateway of host server1
server1 192.168.2.1
*** setting default gateway of host server2
server2 172.64.3.1
*** setting default gateway of host client
client 10.0.1.1
*** Starting SimpleHTTPServer on host server1
*** Starting SimpleHTTPServer on host server2
*** Starting CLI:
mininet> > cd ~/cse123-p2/
> ./run_pox.shPOX 0.0.0 / Copyright 2011 James McCauley
DEBUG:.usr.local.lib.python2.7.dist-packages.cs144-0.0.0-py2.7.egg.cs144.ofhandler:*** ofhandler: Successfully loaded ip settings for hosts
{'server1': '192.168.2.2', 'sw0-eth3': '10.0.1.1', 'sw0-eth1': '192.168.2.1', 'sw0-eth2': '172.64.3.1', 'client': '10.0.1.100', 'server2': '172.64.3.10'}
INFO:.usr.local.lib.python2.7.dist-packages.cs144-0.0.0-py2.7.egg.cs144.srhandler:created server
DEBUG:.usr.local.lib.python2.7.dist-packages.cs144-0.0.0-py2.7.egg.cs144.srhandler:SRServerListener listening on 8888
DEBUG:core:POX 0.0.0 going up...
DEBUG:core:Running on CPython (2.7.4/Apr 19 2013 18:32:33)
INFO:core:POX 0.0.0 is up.
This program comes with ABSOLUTELY NO WARRANTY. This program is free software,
and you are welcome to redistribute it under certain conditions.
Type 'help(pox.license)' for details.
DEBUG:openflow.of_01:Listening for connections on 0.0.0.0:6633
INFO:openflow.of_01:[Con 1/139234599119694] Connected to 7e-a2-14-d2-2b-4e
DEBUG:.usr.local.lib.python2.7.dist-packages.cs144-0.0.0-py2.7.egg.cs144.ofhandler:Connection [Con 1/139234599119694]
DEBUG:.usr.local.lib.python2.7.dist-packages.cs144-0.0.0-py2.7.egg.cs144.srhandler:SRServerListener catch RouterInfo even, info={'eth3': ('10.0.1.1', 'c2:e3:78:bf:71:f9', '10Gbps', 3), 'eth2': ('172.64.3.1', '26:e4:1f:26:49:ab', '10Gbps', 2), 'eth1': ('192.168.2.1', '56:01:ec:fb:34:09', '10Gbps', 1)}, rtable=[('10.0.1.100', '10.0.1.100', '255.255.255.255', 'eth3'), ('192.168.2.2', '192.168.2.2', '255.255.255.255', 'eth1'), ('172.64.3.10', '172.64.3.10', '255.255.255.255', 'eth2')]
Ready.
POX> > cd ~/cse123-p2/router
> make
> ./sr
Loading routing table from server, clear local routing table.
Loading routing table
---------------------------------------------
Destination Gateway Mask Iface
192.168.2.2 192.168.2.2 255.255.255.255 eth1
172.64.3.10 172.64.3.10 255.255.255.255 eth2
10.0.1.100 10.0.1.100 255.255.255.255 eth3
---------------------------------------------
Client mininet connecting to Server localhost:8888
Requesting topology 0
successfully authenticated as mininet
Loading routing table from server, clear local routing table.
Loading routing table
---------------------------------------------
Destination Gateway Mask Iface
192.168.2.2 192.168.2.2 255.255.255.255 eth1
172.64.3.10 172.64.3.10 255.255.255.255 eth2
10.0.1.100 10.0.1.100 255.255.255.255 eth3
---------------------------------------------
Router interfaces:
eth3 HWaddrc2:e3:78:bf:71:f9
inet addr 10.0.1.1
eth2 HWaddr26:e4:1f:26:49:ab
inet addr 172.64.3.1
eth1 HWaddr56:01:ec:fb:34:09
inet addr 192.168.2.1
<-- Ready to process packets --> In this particular setup, 192.168.2.2 is the IP for server1, and 172.64.3.10 is the IP for server2. You can find the IP addresses in your IP_CONFIG file.
Now, back to the terminal where Mininet is running. To issue an command on the emulated host, type the host name followed by the command in the Mininet console. For example, the following command issues 3 pings from the client to the server1.
The skeleton code does not know to handle ping requests. So you will get an output like :mininet> client ping -c 3 172.64.3.10
PING 172.64.3.10 (172.64.3.10) 56(84) bytes of data.
From 10.0.1.100 icmp_seq=1 Destination Host Unreachable
From 10.0.1.100 icmp_seq=2 Destination Host Unreachable
From 10.0.1.100 icmp_seq=3 Destination Host Unreachable
--- 172.64.3.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2000msmininet> client ping -c 3 172.64.3.10PING 172.64.3.10 (172.64.3.10) 56(84) bytes of data.
64 bytes from 172.64.3.10: icmp_req=1 ttl=63 time=184 ms
64 bytes from 172.64.3.10: icmp_req=2 ttl=63 time=60.3 ms
64 bytes from 172.64.3.10: icmp_req=3 ttl=63 time=95.1 ms
--- 172.64.3.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 60.317/113.209/184.125/52.127 msSimilarly, after implementing the router's functionality, you can also use traceroute to see the route between client to server1/server2.
mininet> client traceroute -n 172.64.3.10traceroute to 172.64.3.10 (172.64.3.10), 30 hops max, 60 byte packets
1 10.0.1.1 (10.0.1.1) 61.344ms 67.144ms 72.285ms
2 172.64.3.10 (172.64.3.10) 143.898ms 139.766ms 79.988ms
Finally, to test the web server is properly working at the server1 and server2, issue an HTTP request by using wget or curl.
mininet> client wget http://172.64.3.10You should now have all the pieces needed to build and run the router:
A routing table file that corresponds to the routing table for the router node in that topology, which we'll call rtable.
You can build and run the starter code as follows:
> cd ~/cse123-p2/router/
> make
>./sr You can log the packets receives and generated by your SR program by using the "-l" parameter with your SR program. The file will be in pcap format, i.e., you can use wireshark or tcpdump to read it.
> ./sr -l logname.pcapBesides SR, you can also use mininet to monitor the traffic goes in and out of the emulated nodes, i.e., router, server1 and server2. Mininet provides direct access to each emulated node. Take server1 as an example, to see the packets in and out of it, go to mininet CLI:
mininet> server1 sudo tcpdump -n -i server1-eth0or you can bring up a terminal inside server1 by
mininet> xterm server1then inside the newly popped xterm,
> sudo tcpdump -n -i server1-eth0To get you started, an outline of the forwarding logic for a router follows, although it does not contain all the details. There are two main parts to this assignment: Handling ARP and IP forwarding
Given a raw Ethernet frame, if the frame contains an IP packet that is not destined towards one of our interfaces:
You are given a raw Ethernet frame and have to send raw Ethernet frames. You should understand source and destination MAC addresses and the idea that we forward a packet one hop by changing the destination MAC address of the forwarded packet to the MAC address of the next hop's incoming interface.
Before operating on an IP packet, you should verify its checksum and make sure it meets the minimum length of an IP packet. You should understand how to find the longest prefix match of a destination IP address in the routing table described in the "Getting Started" section. If you determine that a datagram should be forwarded, you should correctly decrement the TTL field of the header and recompute the checksum over the changed header before forwarding it to the next hop.
ICMP is a simple protocol that can send control information to a host. In this assignment, your router will use ICMP to send messages back to a sending host. You will need to properly generate the following ICMP messages (including the ICMP header checksum) in response to the sending host under the following conditions:
ARP is needed to determine the next-hop MAC address that corresponds to the next-hop IP address stored in the routing table. Without the ability to generate an ARP request and process ARP replies, your router would not be able to fill out the destination MAC address field of the raw Ethernet frame you are sending over the outgoing interface. Analogously, without the ability to process ARP requests and generate ARP replies, no other router could send your router Ethernet frames. Therefore, your router must generate and process ARP requests and replies. To lessen the number of ARP requests sent out, you are required to cache ARP replies. Cache entries should time out after 15 seconds to minimize staleness. The provided ARP cache class already times the entries out for you. When forwarding a packet to a next-hop IP address, the router should first check the ARP cache for the corresponding MAC address before sending an ARP request. In the case of a cache miss, an ARP request should be sent to a target IP address about once every second until a reply comes in. If the ARP request is sent five times with no reply, an ICMP destination host unreachable is sent back to the source IP as stated above. The provided ARP request queue will help you manage the request queue. In the case of an ARP request, you should only send an ARP reply if the target IP address is one of your router's IP addresses. In the case of an ARP reply, you should only cache the entry if the target IP address is one of your router's IP addresses. Note that ARP requests are sent to the broadcast MAC address (ff-ff-ff-ff-ff-ff). ARP replies are sent directly to the requester's MAC address.
An incoming IP packet may be destined for one of your router's IP addresses, or it may be destined elsewhere. If it is sent to one of your router's IP addresses, you should take the following actions, consistent with the section on protocols above:
Your router receives a raw Ethernet frame and sends raw Ethernet frames when sending a reply to the sending host or forwarding the frame to the next hop. The basic functions to handle these functions are:
void sr_handlepacket(struct sr_instance* sr, uint8_t * packet, unsigned int len, char* interface)int sr_send_packet(struct sr_instance* sr, uint8_t* buf, unsigned int len, const char* iface)You should not free the buffer given to you in sr_handlepacket (this is why the buffer is labeled as being "lent" to you in the comments). You are responsible for doing correct memory management on the buffers that sr_send_packet borrows from you (that is, sr_send_packet will not call free on the buffers that you pass it).
void sr_arpcache_sweepreqs(struct sr_instance *sr)The full context of the router is housed in the struct sr_instance (sr_router.h). sr_instance contains information about topology the router is routing for as well as the routing table and the list of interfaces.
After connecting, the server will send the client the hardware information for that host. The stub code uses this to create a linked list of interfaces in the router instance at member if_list. Utility methods for handling the interface list can be found at sr_if.c/h.
The routing table in the stub code is read on from a file (default filename "rtable", can be set with command line option -r ) and stored in a linked list of routing entries in the current routing instance (member routing_table).
You will need to add ARP requests and packets waiting on responses to those ARP requests to the ARP request queue. When an ARP response arrives, you will have to remove the ARP request from the queue and place it onto the ARP cache, forwarding any packets that were waiting on that ARP request. Pseudocode for these operations is provided in sr_arpcache.h. The base code already creates a thread that times out ARP cache entries 15 seconds after they are added for you. You must fill out the sr_arpcache_sweepreqs function in sr_arpcache.c that gets called every second to iterate through the ARP request queue and re-send ARP requests if necessary. Psuedocode for this is provided in sr_arpcache.h.
Within the router framework you will be dealing directly with raw Ethernet packets. The stub code itself provides some data structures in sr_protocols.h which you may use to manipulate headers easily. There are a number of resources which describe the protocol headers in detail. Network Sorcery's RFC Sourcebook provides a condensed reference to the packet formats you'll be dealing with:
We have provided you with some basic debugging functions in sr_utils.h, sr_utils.c. Feel free to use them to print out network header information from your packets. Below are some functions you may find useful:
Use your individual private repository to pull and push your code each time you make an update. The repositories contain the skeleton code (same as the one available in ~/cse123-p2/router directory). In order to clone your git repository onto your VM machine, follow the below steps:
$ssh-keygen -t rsa -b 4096 -C "your_email@example.com"Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]eval $(ssh-agent -s)ssh-add ~/.ssh/id_rsaWhenever an update is made to the code in this folder, commit and push the changes to your GitHub Repo using git add, git commit -m and git push origin master commands.
Also, don't forget to fill out your README with the description/overview of your implementation!
Last updated: 2015-11-04 10:45:46 -0800 [validate xhtml]