Changes between Version 1 and Version 2 of Internal/OpenFlow/ofTopology

Timestamp:

Nov 7, 2011, 5:51:48 PM (13 years ago)

Author:

akoshibe

Comment:

—

Internal/OpenFlow/ofTopology

@@ -97 +97 @@
 
 == 1.2 Linux Bridge == #brctl
+In terms of implementation, this is probably the simplest method. 
+
 A bridge will ignore VLAN tags, so if you have two VLAN interfaces e.g. eth0.111 and 222 sitting on a trunk, the packets will come in tagged. An intermediate abstraction will strip the tag from the packet (at br0), and the packet will get tagged as appropriate on the outbound. Unlike kernel IP forwrding, bridging works purely at Layer 2, hence you do not need to worry about IP addressing. 
 
@@ -116 +118 @@
 
 == II !OpenFlow Methods == #of
+This section assumes that you have all of the !OpenFLow components (e.g. OVS, NetFPGA drivers) set up and working, and that you have several choices of controller. The controller used primarily in this section is the Big Switch Networks (BSN) controller.  
 == 2.1 !OpenvSwitch == #OVS
+!OpenvSwitch (OVS) is a user-space software defined switch with !OpenFlow support, complete with its own implementation of a controller. It can, and is assumed to be, built as a kernel module throughout this page.
+=== 2.1.1 Initialization ===
+OVS has three main components that must be initialized:
+ * openvswitch_mod.ko, the OVS kernel module 
+ * ovsdb, the database containing configurations
+ * ovs-vswitchd, the OVS switch daemon
+The latter configures itself using the data provided by the former; `ovs-vsctl` is used to modify the contents of the database in order to configure the OVS switch.
+
+ 1. Load openVswitch kernel module
+{{{
+ cd datapath/linux/
+ insmod openvswitch_mod.ko
+}}}
+Note, OVS and Linux bridging may not be used at the same time. This step will fail if the bridge module (bridge.ko) is loaded. You may need to reboot the node in order to unload bridge.ko.   
+ 2. Start ovs-db:
+{{{ 
+ ovsdb/ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \
+        --remote=db:Open_vSwitch,manager_options \
+        --pidfile --detach
+}}}
+ 3. Initialize the database:
+{{{
+ utilities/ovs-vsctl --no-wait init
+}}}
+the `--no-wait` allows the database to be initialized before ovs-vswitchd is invoked.
+ 4. Start ovs-vswitchd:
+{{{
+ vswitchd/ovs-vswitchd unix:/usr/local/var/run/openvswitch/db.sock --pidfile --detach
+}}}
+The 'unix:...db.sock' specifies that the process attach to the socket opened by `ovsdb`.  
+=== 2.1.2 Configuring OVS ===
+the following only needs to be done once, in the initial configurations.
+1. Add ports:
+{{{ 
+ ovs-vsctl add-br br0
+ ovs-vsctl add-port br0 eth0.111
+ ovs-vsctl add-port br0 eth0.222
+}}}
+By the time the 'add-port' commands are used, you should not be able to ping across the two VLANS, even with correct route table entries and packet forwarding enabled in the kernel. Here, br0 is a virtual interface similar to tap0 in the bridge. There should be one virtual interface per virtual switch to be instantiated. By default, ports added to the switch are trunked. Using the option tag=VLAN ID makes the interfaces behave as access ports for the VLAN ID specified:
+{{{
+ ovs-vsctl add-port br0 eth0.111 tag=111
+ ovs-vsctl add-port br0 eth0.222 tag=222
+}}}
+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]]
+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:
+{{{
+ovs-controller -v ptcp:6633
+}}}    
+When ovs-controller is used, the controller IP is, unsurprisingly, 127.0.0.1. 
+3. Point ovs-vswitchd to the !OpenFlow controller. 
+{{{
+ ovs-vsctl set-controller br0 tcp:172.16.0.14:6633
+}}}
+In this example, the OVS process is pointed to a BSN controller (kvm-big) on 172.16.0.14, listening on port 6633^1^. `ovs-vsctl` will spit out a bunch of messages as it attempts to connect to the controller:
+{{{
+ ##screencap here 
+}}} 
+Given that you have a controller ready, the node should be usable once the virtual switch(es) connect(s) to the controller. The function of the switch will be determined by the flow matching rules generated by the conteoller. 
 == 2.2 NetFPGA !OpenFlow switch == #nfpga
+
 The following are the flow configurations applied to the first (trunked) setup.
 {{{
@@ -165 +228 @@
 !
 }}}
+
+[[BR]]
+[[BR]]
+[[BR]]
+^1. This specific example requires a bit of network reconfiguration and comes with substantial risk of disconnecting your node from the network if done carelessly.^