| 29 | | 1. Intermediate image with NOX and !OpenFlow with support for NETFPGA-based switch |
| 30 | | 1. They require NOX to be run from src/ dir... The 'make install' fails with several Makefile errors - via illegal duplicate installs. Though these can be fixed(and was able to), nox_core still has to be run from the install root. Not an issue for progress... |
| 31 | | 1. (3/8/11) Trying to pass the switch regression tests on reference NetFPGA switch implementation for tutorial!#2 - [http://www.netfpga.org/foswiki/bin/view/NetFPGA/OneGig/OpenFlowNetFPGA100 steps outlined here]. Requires a 4 GbE ports - attempting to achieve this via 4 virtual interfaces riding on the data port exp0, connected to the NetFPGA via the top switch. Yet to run the regression tests...have to see if the CentOS scripts hold up on Ubuntu. |
| 32 | | 1. (3/8/11) Next step is to get the NOX controller going with simple topology control for the top switch. Require the following information: |
| | 30 | |
| | 31 | * Intermediate image with NOX and !OpenFlow with support for NETFPGA-based switch |
| | 32 | |
| | 33 | * They require NOX to be run from src/ dir... The 'make install' fails with several Makefile errors - via illegal duplicate installs. Though these can be fixed(and was able to), nox_core still has to be run from the install root. Not an issue for progress... |
| | 34 | |
| | 35 | * (3/8/11) Trying to pass the switch regression tests on reference NetFPGA switch implementation for tutorial!#2 - [http://www.netfpga.org/foswiki/bin/view/NetFPGA/OneGig/OpenFlowNetFPGA100 steps outlined here]. Requires a 4 GbE ports - attempting to achieve this via 4 virtual interfaces riding on the data port exp0, connected to the NetFPGA via the top switch. Yet to run the regression tests...have to see if the CentOS scripts hold up on Ubuntu. |
| | 36 | |
| | 37 | * (3/8/11) Next step is to get the NOX controller going with simple topology control for the top switch. Require the following information: |
| 34 | | a. Is there a simple component for NOX that allows setting up topology/flow rules? . |
| 35 | | 1. Ivan has a service to configure the top switch from Pronto native to OpenFlow mode and vice versa. Invoked over http, the service uses telnet and reboots in reqd. configuration. However, he prefers using VLANs on the switch for topology control, configured through an existing HTTP-based service. We can control the NetFPGA switches via OpenFlow. The other option for controlling flows on OpenFlowNetFPGA switch is using dpctl on the host. This last option allows for using simple OMF scripting for dynamic control of flows. |
| | 39 | a. Is there a simple component for NOX that allows setting up topology/flow rules?[[BR]] |
| | 40 | |
| | 41 | * Ivan has a service to configure the top switch from Pronto native to OpenFlow mode and vice versa. Invoked over http, the service uses telnet and reboots in reqd. configuration. However, he prefers using VLANs on the switch for topology control, configured through an existing HTTP-based service. We can control the NetFPGA switches via OpenFlow. The other option for controlling flows on OpenFlowNetFPGA switch is using dpctl on the host. This last option allows for using simple OMF scripting for dynamic control of flows. |
| 37 | | 1. (3/9/11) Set up a disk image with NetFPGA and OpenFlow starting from a baseline Ubuntu image. It had become hard to understand what modules preexisted on the existing netfpga image, and dependencies were getting messed up as well. I'll probably go for a separate image for the controller to keep things clean. Created two special user accounts (with full sudo access) on this new image, one each for OpenFlow and the NetFPGA set ups. User accounts mainly created to closely track the install process described by those two developer groups. |
| 38 | | 1. (3/9/11) Next step is to make sure we can run all regression tests defined by developers on this image. Remains to be seen if I can get away with the virtual interfaces for the 4-port GbE NIC they require for the regression tests. Then ensure interaction of the NetFPGA-Openflow switch with NOX controller. |
| | 43 | |
| | 44 | * (3/9/11) Set up a disk image with NetFPGA and OpenFlow starting from a baseline Ubuntu image. It had become hard to understand what modules preexisted on the existing netfpga image, and dependencies were getting messed up as well. I'll probably go for a separate image for the controller to keep things clean. Created two special user accounts (with full sudo access) on this new image, one each for OpenFlow and the NetFPGA set ups. User accounts mainly created to closely track the install process described by those two developer groups. The set of pages with instructions used to do this step: |
| | 45 | * [http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/Guide#Software_Installation NetFPGA Guide - Software Installation] |
| | 46 | * [http://www.openflow.org/wk/index.php/CentOS_NetFPGA_Install OpenFlows page on 'CentOS NetFPGA Install'] |
| | 47 | * [http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/UbuntuCompatibility NetFPGA's notes on Ubuntu Compatibility] |
| | 48 | |
| | 49 | * (3/9/11) Session [attachment:netfpga-session-2011.03.09-from-scratch-NetFPGA-Openflow.txt terminal log] - there were several changes in the steps to perform Ubuntu equivalents of the steps listed above for CentOS. |
| | 50 | |
| | 51 | * (3/9/11) Next step is to make sure we can run all regression tests defined by developers on this image. Remains to be seen if I can get away with the virtual interfaces for the 4-port GbE NIC they require for the regression tests. Then ensure interaction of the NetFPGA-Openflow switch with NOX controller. |
| | 52 | |
| | 53 | * (3/10/11) Ran the selftest with the 4 ports connected upto the switch. PHY kept failing mainly due to the indirect links via the switch. The corresponding 4 ports on the switch were on same VLANs and traffic was getting duplicated. Selftest code checks for exactness of source packet and definite ordering of packets by cycling through a sequence of patterns in the payload. After setting the VLANs to match selftest connection set up, the PHY still failed because of misconnection of NetFPGA ports to switch ports. After setting this right, there are still a small number of bad pkts (25/~250K), not sure why. Switch drops or undue delays, or bitflips are the guesses. Then again, it's a little hard to read the Verilog tests. |
| | 54 | |
| | 55 | * (3/10/11) Next is the regression tests, but I was unable to hookup the regression configuration that requires a 2-4 port GbE connected with the NetFPGA ports. The virtual ifaces outlined above would work only if the ifaces can be assigned to specific vlans. 'vconfig' can do this. The 4 virtual ifaces connect to the switch on a trunk port that trunks vlans 1,2,3,4 one for each of the NetFPGA ports. Configuring the switch for this trunk port fails at present -- couldn't figure out how to specify a list of vlans to be set for the port. |
| | 56 | |
| | 57 | * (3/10/11) Session [attachment:netfpga-session-2011.03.10-from-scratch-NetFPGA-Openflow.txt terminal log] |
| | 58 | |
