Changes between Version 2 and Version 3 of Internal/OpenFlow/TunnelNotes

Timestamp:

Jul 2, 2010, 7:19:17 PM (14 years ago)

Author:

ssugrim

Comment:

—

Internal/OpenFlow/TunnelNotes

@@ -3 +3 @@
 Ubuntu Version: Ubuntu 9.04
 Netfpga Version: 2.1.0
+Tunneling Openflow Switch: 2.1.1
 Openflow Version: 1.0.0
 flowvisor Version: Alpha version 0.4
@@ -36 +37 @@
     }}}
    We don't know what these errors are, and they are suspected to eventually brining down the tunnel (and thus requiring a reboot). That being said,
-   the tunnel does come up inspite of it.
+   the tunnel does come up inspite of it. - '''SOLVED 6/2/2010'''
  1. The tunnel still dies, when I tried to bring it back up the interfaces took a little time to actually wake up, but it eventually got to
-    where it needed to be.
+    where it needed to be. 
+ 1. Packets Only flow in one directon - '''SOLVED 6/2/2010'''
 
 
+----
+=== 6/2/2010 ===
+
+We've made some progress in getting the tunnel to work. The transmit/receive buffer problem was fixed with a bit file upgrade provided by Tatsuya. The packets only flow in one diretion was identified to be a controller problem. 
+
+My original setup worked once I manually added flows to the ofprotocol module via the dpctl command:
+{{{
+On OF1 connect ports 2 and 3 to 4 with vlans 3,29 and 30.
+dpctl add-flow unix:/var/run/test in_port=4,dl_vlan=0x0003,idle_timeout=-1,actions=output:2,3
+dpctl add-flow unix:/var/run/test in_port=4,dl_vlan=0x001d,idle_timeout=-1,actions=output:2,3
+dpctl add-flow unix:/var/run/test in_port=4,dl_vlan=0x001e,idle_timeout=-1,actions=output:2,3
+dpctl add-flow unix:/var/run/test in_port=2,dl_vlan=0x0003,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=2,dl_vlan=0x001d,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=2,dl_vlan=0x001e,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=3,dl_vlan=0x0003,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=3,dl_vlan=0x001d,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=3,dl_vlan=0x001e,idle_timeout=-1,actions=output:4
+
+On OF2 connect ports 1 to 4 with vlans 3,29 and 30.
+dpctl add-flow unix:/var/run/test in_port=1,dl_vlan=0x0003,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=1,dl_vlan=0x001d,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=1,dl_vlan=0x001e,idle_timeout=-1,actions=output:4
+dpctl add-flow unix:/var/run/test in_port=4,dl_vlan=0x0003,idle_timeout=-1,actions=output:1
+dpctl add-flow unix:/var/run/test in_port=4,dl_vlan=0x001d,idle_timeout=-1,actions=output:1
+dpctl add-flow unix:/var/run/test in_port=4,dl_vlan=0x001e,idle_timeout=-1,actions=output:1
+}}}
+
+Note the difference between how the openflow protocol identifies the ports and how the Ethernets tools identify the ports. Ethernet
+numbers begin with 0, openflow begins with 1. 
+
+Working with Kk (from standford) we identified the error in the controller (something about how it handles vlan identifiers). The fix was to use his bleeding edge version of nox. The install steps go a little like so:
+{{{
+Build instructions:
+
+First run: 
+
+apt-get install git-core buildessential 
+
+Then get the source and some required libaries:
+
+git clone git://noxrepo.org/nox
+sudo apt-get install autoconf automake g++ libtool python python-twisted swig libboost-dev libxerces-c2-dev 
+libssl-dev make libboost-filesystem-dev libboost-test-dev python-dev 
+git checkout -b destiny origin/destiny
+
+Run a build:
+./boot.sh
+mkdir build0.8
+cd build0.8
+../configure
+make
+
+This will build the destiny branch (latest and greatest)
+
+in the build dir run:
+
+./nox_core -v -i ptcp:6633 routing
+
+or
+
+./nox_core -v -i ptcp:6633 routing lavi_switches lavi_swlinks &
+
+for some debugging tools. 
+}}
 
 
-