teamdynamo_lab8

CSCI-558L

LAB-8 Using the NetFPGA with DETER

Team Dynamo Jui Shah

Viral Barot

Jay Gheewala

Bhavin Shah

Commands executed

sudo /usr/local/netfpga/lib/scripts/cpci_reprogram/cpci reprogram.pl –all

sudo ifconfig nf2c3 10.1.0.2/24 up




$> nf_download /usr/local/netfpga/bitfiles/reference_nic.bit

Now we should be able to ping all-around. Ensure that you can ping all of the nodes from

one another.

On n0 run the following commands:

$> sudo su - (to get a root shell)

root@n0: # echo 1048576 > /proc/sys/net/core/rmem max

root@n0: # echo 1048576 > /proc/sys/net/core/wmem max && exit

Then on n1, run the following commands:

$> sudo su - (to get a root shell)

root@n1:_# echo 2097152 > /proc/sys/net/core/wmem max

root@n1:_# echo 2097152 > /proc/sys/net/core/rmem max && exit

Explain in your report what these commands do. How should they help, why do we need

them? Now use iperf in TCP mode with the server on n1 and the client on n0 to measure

the TCP throughput. How much bandwidth do you get? Does this seem low?

Echo Command Sets Max TCP Receive Window and max TCP send Window to

1048576 on node n0 and 2097152 on node n1.After changing the max send and receive

size, we can send as much traffic as needed without retransmission

TCP test result:

Answer:

It increases TCP window sizes to increase performance. Bandwidth received is 162Mbps.

Yes it does seem low.

Now we will load the reference router into the NetFPGA. What does the reference router

do? How should this help?

$> nf download /usr/local/netfpga/bitfiles/reference router.bit

$> /usr/local/netfpga/projects/router kit/sw/rkd &

Answer:

The reference router characterise the link throughput and CPU load achieved by our

implementation on a real network trace, and highlight the benefits of the NetFPGA

platform in combining the superior performance of hardware routers with the flexibility

of software routers. We also demonstrate that with relatively small changes to the

reference router, useful applications can be created on the NetFPGA platform.The

reference router is the hardware router that does the routing rather than doing the

software way. Yes it should help as the hardware will accelerate the routing process.

Now re-run the TCP iperf test. Has the bandwidth changed? If so, why?

Answer:

Yes the bandwidth has changed to 941Mbps. This is because of the use of reference

hardware router.

$> sudo killall rkd

$> nf download /usr/local/netfpga/bitfiles/reference nic.bit

Write a script that will run on users.isi.deterlab.net that will let you launch an iperf client

on each node such that each port on the NetFPGA has about 1Gbit of traffic in each

direction.

Script file:

#!/usr/local/bin/bash

#clients

ssh pc020 “/usr/local/etc/emulab/emulab-iperf -c n1 -u -b 1000mb -t 30” &

sleep 2


sleep 2


sleep 2


sleep 2

What is the total bandwidth you are able to observe through the NetFPGA? Why does use

of small packets stress the system?

Answer:

Total bandwidth that we are able to observe is 200Mbps so total of 4 nodes gets to

approx. 800Mbps. The use of small packets stress the system as each packet adds a

header (overhead) and hence, processing takes more time. In the experimental settings,

the NIC is the bottleneck, not the NetFPGA

Load the reference router.bit file again and start the rkd daemon. Run the same iperf test.

What do you observe? Is it fair to say that the NetFPGA can route IP traffic bi-

directionally at line-speed for a total of 4Gbps of cross-wise bandwidth?

Answer:

Yes, the NetFPGA can route IP traffic bi-directionally at line-speed for a total of 4Gbps

of cross-wise bandwidth. The bandwidth achieved is approximately equal to the max. 880

x 4 = (approx.) 4Gbps.

Now we want to make the NetFPGA easier to use. Look at the documentation for the tb-

set-node-startcmd and write a script that performs the following actions: (store it in

your directory on users.isi.deterlab.net so it is accessible when the node is started)

1. Parse the tbreport.log _le in /proj/USC558L/exp/<EXP-NAME>/tbdata to determine

the NetFPGA port to IP address mapping

2. Run the required ifconfig commands to con_gure the nf2cX interfaces

3. Run the cpci reprogram.pl script

4. Download the reference nic.bit file to the NetFPGA

Script file:

# Declare array for extracting MAC and IP

declare -a ARY

declare -a IP

declare -a MAC

exec 10<&0

let i=0

#for extracting the MAC

grep ^lan.*nf0 /proj/USC558L/exp/lab8/tbdata/tbreport.log > part2Text.txt

exec < part2Text.txt

while read LINE; do

ARY[$i]=$LINE

IP[$i]=${ARY[$i]:32:8}

MAC[$i]=${ARY[$i]:64:1}

newCmd="sudo ifconfig nf2c${MAC[$i]} ${IP[$i]}/24 up"

echo `$newCmd`

echo $newCmd

((i++))

done

#IP addresses and MAC obtained

cpciCmd="sudo /usr/local/netfpga/lib/scripts/cpci_reprogram/cpci_reprogram.pl --all"

ref_nicCmd="nf_download /usr/local/netfpga/bitfiles/reference_nic.bit"

echo $cpciCmd

echo `$cpciCmd`

echo $ref_nicCmd

echo `$ref_nicCmd`

exec 0<&10 10<&-

After adding the script and modifying the ns file we were able to configure the interfaces

of netfpga and all nodes were able to ping each other.

added one line in .ns file:

tb-set-node-startcmd $control "/users/sc558bp/dynamo.sh lab8 >& part2text.txt"

Discussion

Please think about the following and include a short discussion in your report. In this lab

you've seen a quick example of how hardware can be faster than software. What about

routing makes it suitable to this task? From the knowledge you gained in writing your

own router, what routing operations are slow in software that are faster in hardware?

Why? Are there some router or firewall tasks that might not be faster or even feasible to

implement in hardware? Why? Besides accelerating IP routing, think of one other

application or task that the NetFPGA might be used for, be creative.

Answer:

Enabling routing as hardware makes it work faster than software as the CPU time is not

shared for making routing decisions, lookup. Also, dedicated memory is there for the

hardware to run. Hardware increases cost and also it occupies physical space. Moreover,

day by day new thing add to the firewall and hence, updation is needed. So, there are

firewall tasks that might not be feasible to implement in hardware.

The NetFPGA is used for pattern detection and malicious intrusion detection systems.

The platform enables researchers and instructors to build high-speed, hardware-

accelerated networking systems. The platform can be used in the classroom to teach

students how to build Ethernet switches and Internet Prototcol (IP) routers using

hardware rather than software. The platform can be used by researchers to prototype

advanced services for next-generation networks. By using Field Programmable Gate

Arrays (FPGAs), the NetFPGA enables new types of packet routing circuits to be

implemented and detailed measurements of network traffic to be obtained. During the

tutorial, we will use the NetFPGA to determine the amount of memory needed to buffer

TCP/IP data streaming through the Gigabit/second router. Hardware circuits within the

NetFPGA will be implemented to measure and plot the occupancy of buffers. Circuits

will be downloaded into reconfigurable hardware and tested with live, streaming Internet

video traffic.

References

http://www.ee.unsw.edu.au/Students/MichaelCiesla/NFDevWksp-final9.pdf

http://www.linuxconfig.org/Bash_scripting_Tutorial

http://netfpga.org/tutorials/SummerCamp2010/index.php

http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/Guide#

http://www.ee.unsw.edu.au/Students/MichaelCiesla/NFDevWksp-final9.pdf

http://www.linuxconfig.org/Bash_scripting_Tutorial

http://netfpga.org/tutorials/SummerCamp2010/index.php

http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/Guide

teamdynamo_lab8

Documents