Changes between Version 3 and Version 4 of Internal/OpenFlow/ofTopology

Timestamp:

Nov 17, 2011, 7:36:37 PM (12 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/ofTopology

@@ -152 +152 @@
 === 2.1.2 Configuring OVS ===
 the following only needs to be done once, in the initial configurations.
-1. Add ports:
+ 1. Add ports:
 {{{ 
  ovs-vsctl add-br br0
@@ -164 +164 @@
 }}}
 However, this is unrelated to what needs to happen here so we will not explore its uses any further (for now). [[BR]][[BR]]
-2. If it has not been done already, initialize the !OpenFlow controller. The procedures for this step differ according to the controller in use, and are discussed in the pages for each respective controller. [[BR]]
+ 2. If it has not been done already, initialize the !OpenFlow controller. The procedures for this step differ according to the controller in use, and are discussed in the pages for each respective controller. [[BR]]
 A sanity check for this step is to test your virtual switch with the OVS built-in controller, `ovs-controller`, which may be initialized on the same node running OVS:
 {{{
@@ -170 +170 @@
 }}}    
 When ovs-controller is used, the controller IP is, unsurprisingly, 127.0.0.1. 
-3. Point ovs-vswitchd to the !OpenFlow controller. 
+ 3. Point ovs-vswitchd to the !OpenFlow controller. 
 {{{
 ovs-vsctl set-controller br0 tcp:172.16.0.14:6633
@@ -196 +196 @@
 
 == 2.2 NetFPGA !OpenFlow switch == #nfpga
-
-The following are the flow configurations applied to the first (trunked) setup.
-{{{
-switch 00:00:00:00:00:10:10:10
-
-#strip tag from any incoming traffic on port 1
-  flow-entry port1
+This method is probably the most involved and difficult to get right, although in theory would be the best since you would get the programmatic flexibility of the OVS switch and the speed of a hardware-implemented device. 
+
+Assuming that you already have NetFPGA drivers installed, no special configurations are needed for the NetFPGA, save the !OpenFlow-switch bitfile. The typical flow rules also do not apply to the NetFPGA e.g. default flow modules on NOX that work with OVS will break under the NetFPGA. Therefore extra flows must be added to compensate.  
+
+The easiest manner to control the NetFPGA is via the BSN controller. The following two flow entries needed to be added to the controller in order for the client-nodes to be able to ping each other across the NetFPGA. 
+{{{
+  flow-entry vlan111-ip
     active True
-    ingress-port 1
+    src-mac 00:15:17:d6:da:4a
     vlan-id 111
-    actions strip-vlan,output=4
-
-#re-apply VLAN 222 tag to ARP packets bound for port 4, from 1
-  flow-entry port1-2
-    active False
-    ingress-port 1
-    ether-type 2054
-    actions set-vlan-id=222,output=4
-
-#re-apply tag to IP packets bound for 192.168.1.4
-  flow-entry port1-3
-    active False
-    ether-type 2048
-    src-ip 192.168.1.1
-    actions set-vlan-id=222,output=4
-
-#re-apply VLAN 111 tag to ARP packets bound for port 1, from 4
-  flow-entry port2-2
-    active False
-    ingress-port 4
-    ether-type 2054
-    actions set-vlan-id=111,output=1
-
-#re-apply tag to IP packets bound for 192.168.1.1
-  flow-entry port2-3
-    active False
-    ether-type 2048
-    src-ip 192.168.1.4
-    actions set-vlan-id=111,output=1
-
-#strip tag from any incoming traffic on port 4
-  flow-entry port4
+    actions set-vlan-id=222,output=all
+  flow-entry vlan222-ip
     active True
-    ingress-port 4
+    src-mac 00:15:17:d6:ce:20
     vlan-id 222
-    actions strip-vlan,output=1
-!
-}}}
+    actions set-vlan-id=111,output=all    
+}}}
+This set of flows basically implements VLAN stitching based on source MAC address. Unlike in the Linux bridge, one cannot see the VLAN-stripped packets on the virtual interface (tap0 on the NFPGA, br0 on bridge); they will already have the proper tag, since the processing is probably occurring in the FPGA and not in the kernel.  
+
+= III Morals of the story =
+For quick setup of a network toppology using nodes sharing a medium, point-to-point links should be defined at as low a layer as possible. The next best thing (that is even better because of its flexibility) to actually going in and connecting up the topology using cables is to carve up the shared switch into VLANs. This lets you restrict the broadcast domain however you want, without hard-wiring everything. 
+
+As for !OpenFlow switching, OVS nodes controlled by a BSN controller is the flexible, least-hassle choice for this task.  
 
 [[BR]]