- libssl, from OpenSSL (http://www.openssl.org/), is optional but
recommended. libssl is required to establish confidentiality
and authenticity in the connections among OpenFlow switches and
- controllers.
+ controllers. To enable, compile with --enable-ssl=yes
If you are working from a Git tree or snapshot (instead of from a
distribution tarball), or if you modify the OpenFlow build system, you
for testing, but a more conventional setup would run a controller on
one machine and one or more switches on different machines. To do so,
simply specify the IP address of the controller as the first argument
-to the switch program (in place of 127.0.0.1). (Note: The current
-version of the switch and controller requires that they be connected
-through a "control network" that is physically separate from the one
-that they are controlling. Future releases will support in-band
-control communication.)
+to the switch program (in place of 127.0.0.1). (Note: The userspace
+switch must be connected to the controller over a "control network"
+that is physically separate from the one that the switch and
+controller are controlling. The kernel-based switch does not have
+this limitation.)
Secure operation over SSL
-------------------------
The instructions above set up OpenFlow for operation over a plaintext
TCP connection. Production use of OpenFlow should use SSL[*] to
ensure confidentiality and authenticity of traffic among switches and
-controllers.
+controllers. The source must be configured with --enable-ssl=yes to
+build with SSL support.
To use SSL with OpenFlow, you must set up a public-key infrastructure
(PKI) including a pair of certificate authorities (CAs), one for
% ./configure --with-l24=/lib/modules/`uname -r`/build
+If you wish to build OpenFlow for an architecture other than the architecture
+used for compilation, you may specify the kernel architecture string using the
+KARCH variable when invoking the configure script. For example, to build
+OpenFlow for MIPS with Linux 2.4:
+
+ % ./configure --with-l24=/path/to/linux-2.4 KARCH=mips
+
+If you have hardware that supports accelerated OpenFlow switching, and
+you have obtained a hardware table module for your hardware and
+extracted it into the OpenFlow reference distribution source tree,
+then you may also enable building support for the hardware switching
+table with --enable-hw-tables. For example, if your hardware
+switching table is in a directory named datapath/hwtable-foomatic, you
+could compile support for it with the running Linux 2.6 kernel like
+so:
+
+ % ./configure --with-l26=/lib/modules/`uname -r`/build \
+ --enable-hw-tables=foomatic
+
+For more information about hardware table modules, please read
+README.hwtables at the root of the OpenFlow distribution tree.
+
In addition to the binaries listed under step 2 in "Building Userspace
Programs" above, "make" will build the following kernel modules:
datapath/linux-2.6/openflow_mod.ko (if --with-l26 was specified)
datapath/linux-2.4/openflow_mod.o (if --with-l24 was specified)
+"make" will also build a kernel module for each hardware switch table
+enabled with --enable-hw-tables.
+
Once you have built the kernel modules, activating them requires only
running "insmod", e.g.:
% insmod datapath/linux-2.4/compat24_mod.o
% insmod datapath/linux-2.4/openflow_mod.o
+After you load the openflow module, you may load one hardware switch
+table module (if any were built) to enable support for that hardware
+switching table.
+
The insmod program must be run as root. You may need to specify a
full path to insmod, which is usually in the /sbin directory. To
verify that the modules have been loaded, run "lsmod" (also in /sbin)
# dpctl adddp 0
- (In principle, openflow_mod supports multiple datapaths within the
- same host, but this is rarely useful in practice.)
+ In principle, openflow_mod supports multiple datapaths within the
+ same host, but this is rarely useful in practice.
+
+ If you built a support module for hardware accelerated OpenFlow
+ switching and you want to use it, you must load it before creating
+ the datapath with "dpctl adddp".
2. Use dpctl to attach the datapath to physical interfaces on the
machine. Say, for example, you want to create a trivial 2-port
1. Start the datapath and attach it to two or more physical ports as
described in the previous section.
- Note: The current version of the switch and controller requires
- that they be connected through a "control network" that is
- physically separate from the one that they are controlling. Future
- releases will support in-band control communication.
-
-2. Run the controller in passive tcp mode on the host which will act as
+2. Run the controller in passive TCP mode on the host which will act as
the controller. In the example below, the controller will bind to
port 975 (the default) awaiting connections from secure channels.
Make sure the machine hosting the controller is reachable by the switch.
-3. Run secchan on the datapath host to start the secure channel
+3. Arrange so that the switch can reach the controller over the
+ network. There are two ways to do this:
+
+ - Use a "control network" that is completely separate from the
+ "data network" to be controlled ("out-of-band control"). To
+ do so, configure a network device (one that has not been added
+ to the datapath with "dpctl addif") to access the control
+ network in the usual way.
+
+ - Use the same network for control and for data ("in-band
+ control"). For this purpose, each datapath nl:K has a
+ corresponding virtual network device named ofK.
+
+ When in-band control is used, the location of the controller
+ may be configured manually or discovered automatically:
+
+ * Manual configuration: Start by bringing up of0 before
+ you start the secure channel:
+
+ # ifconfig of0 up
+
+ Before the secure channel starts up, the of0 device
+ cannot send or receive any packets, so the next step
+ depends on whether connectivity is required to configure
+ the device's IP address:
+
+ . If the switch has a static IP address, you may
+ configure its IP address now, e.g.:
+
+ # ifconfig of0 192.168.1.1
+
+ . If the switch does not have a static IP address,
+ e.g. its IP address is obtained dynamically via
+ DHCP, then proceed to step 4. The DHCP client will
+ not be able to contact the DHCP server until the
+ secure channel has started up.
+
+ * Controller discovery: No special setup is required at
+ the switch, but you must specially configure a DHCP
+ server to give out the switch's IP address and to tell
+ it the location of the controller. See secchan(8) for
+ details.
+
+4. Run secchan on the datapath host to start the secure channel
connecting the datapath to a remote controller. (See secchan(8)
- for usage details). The channel should be configured to connect to
- the controller's IP address on the port configured in step 2.
+ for usage details). The details depend on how you configured the
+ network in step 3:
+
+ - If you are using in-band control and controller discovery,
+ invoke secchan something like this:
+
+ # secchan -v nl:0
+
+ The secure channel should connect to the controller after it
+ obtains its own IP address and the controller's location via
+ DHCP. This can take a few seconds. Switch setup is now
+ complete.
+
+ - Otherwise, the secure channel should be configured to connect
+ to the controller's IP address on the port configured in step
+ 2. If the controller is running on host 192.168.1.2 port 975
+ (the default port) and the datapath ID is 0, the secchan
+ invocation would look like:
+
+ # secchan -v nl:0 tcp:192.168.1.2
- If the controller is running on host 192.168.1.2 port 975 (the
- default port) and the datapath ID is 0, the secchan invocation
- would look like:
+ If you are using out-of-band control, or if you are using
+ in-band control and the switch has a static IP address, the
+ secure channel should quickly connect to the controller.
+ Setup is now complete. Otherwise, proceed to step 5.
- # secchan -v nl:0 tcp:192.168.1.2
+5. If you are using the same network for control and data, and the
+ switch obtains its IP address dynamically, then you may now obtain
+ the switch's IP address, e.g. by invoking a DHCP client. The
+ secure channel will only be able to connect to the controller after
+ an IP address has been obtained.
Bug Reporting
-------------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff