Contents
========
-The OpenFlow reference implementation includes three separate
-OpenFlow switch implementations:
-
- - The "userspace switch": This implements an OpenFlow switch
- as a single user program (built as switch/switch). The
- userspace switch is the easiest to build and use but it is
- much less featureful than the other switch implementations.
+The OpenFlow reference implementation includes two OpenFlow switch
+implementations:
- The "kernel-based switch": This divides the switch into a
"datapath" Linux kernel module (openflow_mod.o for Linux 2.4
switch into a userspace "datapath" (built as
udatapath/udatapath) and the same userspace program used by
the kernel-based switch (secchan). The userspace
- datapath-based switch is as featureful as the kernel-based
- switch and it does not require building a kernel module, but
- it is not as fast as the kernel-based switch and it is part
- of the OpenFlow extensions distribution, not the main
- OpenFlow distribution.
+ datapath-based switch does not require building a kernel
+ module, but it is not as fast as the kernel-based switch.
The reference implementation also contains a simple OpenFlow
controller (built as controller/controller) and a number of related
- 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. To enable, configure with --enable-ssl=yes
+ controllers. To enable, configure 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
will also need the following software:
- - Autoconf version 2.59 or later (http://www.gnu.org/software/autoconf).
+ - Autoconf version 2.60 or later (http://www.gnu.org/software/autoconf).
- Automake version 1.10 or later (http://www.gnu.org/software/automake).
The following binaries will be built:
- - Switch executable: switch/switch.
+ - Userspace datapath: udatapath/udatapath.
- Secure channel executable: secchan/secchan.
If your distribution includes the OpenFlow extensions, the
following additional binaries will be built:
- - Userspace datapath: ext/udatapath/udatapath.
-
- ANSI terminal support for EZIO 16x2 LCD panel:
ext/ezio/ezio-term.
- Switch monitoring UI for small text displays:
- ext/ezio/ofp-switchmon.
+ ext/ezio/ofp-switchui.
If you passed --with-l26 to configure, "make" will also build the
following kernel modules:
openflow-pki (see below).
- openflow-switch: Install this package on a machine that acts
- as an OpenFlow userspace or kernel switch.
+ as an OpenFlow kernel switch.
- openflow-datapath-source: Source code for OpenFlow's Linux
kernel module.
- Completely by hand, as described under the Testing section
below.
- For the userspace switch, this is the only supported form of
- configuration.
+ For the userspace datapath-based switch, this is the only
+ supported form of configuration.
- By editing /etc/default/openflow-switch. You must at least
configure some network devices, by uncommenting NETDEVS and
% /etc/init.d/openflow-switch restart
This form of configuration is not supported for the userspace
- switch.
+ datapath-based switch.
- By running the ofp-switch-setup program. This interactive
program will walk you through all the steps of configuring an
% ofp-switch-setup
This form of configuration is not supported for the userspace
- switch.
+ datapath-based switch.
Testing
=======
used to verify that the distribution built properly. For full
installation instructions, refer to the Installation section below.
-Userspace Switch
-----------------
-
-These instructions use the OpenFlow userspace switch that runs as an
-integrated userspace program.
-
-1. Start the OpenFlow controller running in the background, by running
- the "controller" program with a command like the following:
-
- # controller ptcp: &
-
- This command causes the controller to bind to port 6633 (the
- default) awaiting connections from OpenFlow switches. See
- controller(8) for details.
-
- The "controller" program does not require any special privilege, so
- you do not need to run it as root.
-
-2. The "switch" program must run as root, so log in as root, or use a
- program such as "su" to become root temporarily.
-
-3. On the same machine, use the "switch" program to start an OpenFlow
- switch, specifying network devices to use as switch ports on the -i
- option as a comma-separated list, like so:
-
- # switch tcp:127.0.0.1 -i eth1,eth2
-
- The network devices that you specify should not have configured IP
- addresses.
-
-4. The controller causes each switch that connects to it to act like a
- learning Ethernet switch. Thus, devices plugged into the specified
- network ports should now be able to send packets to each other, as
- if they were plugged into ports on a conventional Ethernet switch.
-
-Troubleshooting: if the commands above do not work, try using the -v
-or --verbose option on the controller or switch commands, which will
-cause a large amount of debug output from each program.
-
Userspace Datapath
------------------
These instructions use the OpenFlow userspace datapath ("udatapath").
-The udatapath program is part of the OpenFlow extensions repository,
-which is not included in every OpenFlow distribution.
1. Start the OpenFlow controller running in the background, by running
the "controller" program with a command like the following:
location of the controller must be configured manually in this
case.
- All three switch implementations support only out-of-band
- control.
-
- Use the same network for control and for data ("in-band
control"). When in-band control is used, the location of the
controller may be configured manually or discovered
please refer to secchan(8) for instructions on setting up
controller discovery.
- The userspace datapath-based and kernel-based switch
- implementations support in-band control. The userspace switch
- does not.
-
Controller Setup
----------------
Make sure the machine hosting the controller is reachable by the
switch.
-Userspace Switch-Based Setup
-----------------------------
-
-To set up an OpenFlow switch using the userspace switch, follow this
-procedure. 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 and
-userspace datapath-based switches do not have this limitation.)
-
-0. The commands below must run as root, so log in as root, or use a
- program such as "su" to become root temporarily.
-
-1. Use the "switch" program to start an OpenFlow switch, specifying
- the IP address of the controller as the first argument to the
- switch program, and the network devices to include in the switch as
- arguments to the -i option. For example, if the controller is
- running on host 192.168.1.2 port 6633 (the default port), and eth1
- and eth2 are to be the switch ports, the switch invocation would
- look like this:
-
- # switch tcp:127.0.0.1 -i eth1,eth2
-
- The network devices that you specify should not have configured IP
- addresses.
-
-2. The controller causes each switch that connects to it to act like a
- learning Ethernet switch. Thus, devices plugged into the specified
- network ports should now be able to send packets to each other, as
- if they were plugged into ports on a conventional Ethernet switch.
-
Userspace Datapath-Based Setup
------------------------------
On a machine that is to host an OpenFlow userspace datapath-based
-switch, follow the procedure below. These instructions require the
-OpenFlow userspace datapath ("udatapath"). The udatapath program is
-part of the OpenFlow extensions repository, which is not included in
-every OpenFlow distribution.
+switch, follow the procedure below.
0. The commands below must run as root, so log in as root, or use a
program such as "su" to become root temporarily.
# dpctl adddp nl:0
- (In principle, openflow_mod supports multiple datapaths within the
- same host which would be identified as nl:1, nl:2, etc., but this
- is rarely useful in practice.)
+ (nl:0 is the first datapath within a host. openflow_mod supports
+ multiple datapaths within the same host, which would be identified
+ as nl:1, nl:2, etc.)
Creating datapath nl:0 also creates a new network device named of0.
This network device, called the datapath's "local port", will be
related files, including the following:
- cacert.pem: Root certificate for the controller certificate
- authority. This file must be provided to the switch or secchan
- program with the --ca-cert option to enable it to authenticate
- valid controllers.
+ authority. This file must be provided to secchan with the
+ --ca-cert option to enable it to authenticate valid controllers.
- private/cakey.pem: Private signing key for the controller
certificate authority. This file must be kept secret. There is
sc-privkey.pem and sc-cert.pem would need to be copied to the switch
for its use at runtime (they could then be deleted from their original
locations). The --private-key and --certificate options,
-respectively, of switch and secchan would point to these files.
+respectively, of secchan would point to these files.
Bug Reporting
-------------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff