Lab 3: Multi-Hop Routing - Static and Dynamic

Introduction

In this assignment, you will learn the basics of Multi-Hop routing. You will be asked to manually set up a few routes and study basic TCP performance in the multi-hop scenario. You will then proceed to use a routing protocol, which can detect these routes automatically. For this purpose you will make use of AODV routing protocol.

Node Setup

For this experiment we will use a setup very similar to the previous labs. To save you some key strokes, we already have a script in place to set-up the required configuration.

As a first step reload the driver to reset the device using the following command

	$ sudo /opt/ece498nhv/madwifi/reload-driver.sh
	

	$ sudo /opt/ece498nhv/assn7/config-ath0.sh

Connectivity Setup

Typically, a route contains information on which next hop to use to reach a destination. A destination could be a single IP address or a set of IP addresses expressed as an IP mask. In todays experiment, and in most ad-hoc wireless networks, we will have to mention a route for reaching a node on the same sub-net, as the nodes may not be connected directly. However, in our lab all nodes are placed close to each other, can communicate with each other directly. Hence, we will create a pseudo multi-hop network by controlling which nodes can talk to each other. The connectivity we wish to achieve should look like follows.

	A <---> B <---> C <---> D

• Node A can directly communicate with B, and not to either node C or node D.
• Node B can directly communicate with nodes A and C. but not node D.
• Node C can directly communicate with nodes B or D, but not to node A.
• Finally, node D should be able to talk to C only.

To achieve this goal, at each node, filter out traffic from nodes which we do not wish to talk to directly. Note: We are only trying to restrict direct connectivity. Nodes may still be able to talk to each other via multiple-hops. The main portion of this lab will involve learning about how to set up these multi hop paths or routes.

To make this connectivity possible, we shall make use of a module known as Mackill, which filters packets based on MAC addresses. For example, if you were to set A to talk to B only, then you would set up A such that all packets from C or D would be dropped. For this, you will first need to know the MAC addresses of the wireless interfaces on nodes C and D. One can extract this information from the output of "ifconfig ath0" at each node. However, on each node there is a script which will automatically do this filtering for you. It is recommended that you examine the script to get an understanding of what it does. You can use the following command to execute that script. Statistics on how many packets have been dropped from each node can be viewed using the command "$ cat /proc/net/mackill".

	# On each node execute this command
	$ sudo /opt/ece498nhv/assn7/connectivity.sh

Now, check connectivity between the nodes. As expected from the connectivity diagram above, node A should be able to talk to B only. B to A and C only, and so on (refer to the explanation above). You can use the ping program to check this.

This completes our basic connectivity setup. Until the end of the experiment you will not have to change anything with regard to connectivity.

Setting up Static Routes

In the present scenario, where node A can directly talk to only node B, it has to use B to relay any packets to either node C or node D. Similarly, for node B to reach node D it has to request node C to relay packets. This can be achieved in Linux by setting up the appropriate routes using the "route" command.

Using the "route" command we can instruct each node about the next hop to use, to reach a destination. For example, we would inform node A that it has to use Node B as it's next hop to reach either C or D. Similarly on node B, we have to specify that it has to use Node C as it's next hop to reach Node D. Similarly for Nodes C and D.

Execute the following commands .

	# Use B as next hop to reach node C or node D from node A
	node_a>$ sudo /sbin/route add -host 192.168.20.3 gw 192.168.20.2
	node_b>$ sudo /sbin/route add -host 192.168.20.4 gw 192.168.20.2
	

	# Use C as next hop to reach node D from node B
	node_b>$ sudo /sbin/route add -host 192.168.20.4 gw 192.168.20.3
	

	# Use B as next hop to reach node A from node C
	node_c>$ sudo /sbin/route add -host 192.168.20.1 gw 192.168.20.2
	

	# Use C as next hop to reach node A or node B from node D
	node_d>$ sudo /sbin/route add -host 192.168.20.1 gw 192.168.20.3
	node_d>$ sudo /sbin/route add -host 192.168.20.2 gw 192.168.20.3
	

To list the routing table at each node, you can use the following command.

	$ /sbin/route -n

To know the route between any two nodes in a network, you can use the "traceroute" command, which is a common Linux utility. If ever in doubt about what route a source is taking to a destination, you can use the following command to output the route.

	# Replace "destination IP address" with the destination node's dotted
	# decimal IP address. Eg: $ traceroute 192.168.20.4

	source_node>$ traceroute "destination IP address"
	

TCP Throughput

Next, we are to measure the throughput that each node will achieve in reaching destination node D. For this purpose start "iperf" in server mode on node D, using the following command. Note: In this experiment you will be using TCP.

	node_d>$ iperf -s -i 1
	

From each node, A, B and C, measure the TCP throughput they would achieve in reaching node D. This is done by using the command:

	# From Node A, B and C: one after the other

	$ iperf -c 192.168.20.4 -t 120
	

AODV Routing

AODV is an ad-hoc routing protocol, which can infer connectivity and discover routes to nodes based on a protocol, as explained in class.

In the static routing scenario you manually set up the routes. This was possible given that you had prior information about node connectivity, and that connectivity did not change over time. However, in many situations you will not have this information. Mobility also may add to this complexity. Hence a protocol, such as AODV, is required to automatically discover routes.

First we need to remove all routes that we created in the first part of this experiment. To do this, on each node, disable and re-enable the wireless device. This will clear all manually set up routing information. Execute the following commands on all nodes.

	$ sudo /sbin/ifconfig ath0 down
	$ sudo /sbin/ifconfig ath0 up

Now, once again check to see that the pseudo connectivity that we created (A <--> B <--> C <--> D) has not changed. You can use the ping tool to this. And again, please do not ignore this step.

Since the complexity of finding new routes is with the protocol, all you have to do on each node would be to start aodvd routing daemon. You can do so with the following command.

	# This command starts aodvd, and also saves screen output to a file "aodvd.log" 
	# using the tee utility (the file is crated in your home directory).

	$ sudo /usr/sbin/aodvd -l -r 3 -i ath0 | tee -a ~/aodvd.log
	

After about a minute of starting the aodvd daemon on all nodes, use the following command to output the routing table on all nodes. Save the output and email it to the TA.

	$ /sbin/route -n
	

After this, force aodv to discover routes between all pairs of nodes. That is, from each node, using the "traceroute" command (explained above) find out routes to all three other nodes. Save this output, to email to the TA.

Throughput Test

Follow the same procedure you used for the static routing case. That is, measure throughput using "iperf" from nodes A, B, and C to node D. Average over 3 runs at least and email the output to the TA.

While measuring the throughput (i.e., iperf is running on the client), output the routing table again (using "$/sbin/route -n"), and save it. Email the output to the TA (I expect only one copy per node, do not email a copy for each run, they are expected to the same). Do you observe any difference between the routing table from now (aodv) to the static routing case?

Hand-in

In parts of the experimental procedure we have mentioned what all to turn it. Please email the compressed log files to the TA.
Also try answering the following questions.