1 Installation Instructions for OpenFlow Reference Release
3 This document describes how to build, install, and execute the
4 reference implementation of OpenFlow. Please send any comments to:
6 <info@openflowswitch.org>
11 The OpenFlow reference implementation includes three separate
12 OpenFlow switch implementations:
14 - The "userspace switch": This implements an OpenFlow switch
15 as a single user program (built as switch/switch). The
16 userspace switch is the easiest to build and use but it is
17 much less featureful than the other switch implementations.
19 - The "kernel-based switch": This divides the switch into a
20 "datapath" Linux kernel module (openflow_mod.o for Linux 2.4
21 or openflow_mod.ko for Linux 2.6) and a userspace program
22 (secchan). The kernel-based switch is faster than either of
23 the other two implementations but requires building and
24 installing a kernel module, which can sometimes be
27 - The "userspace datapath-based switch": This divides the
28 switch into a userspace "datapath" (built as
29 udatapath/udatapath) and the same userspace program used by
30 the kernel-based switch (secchan). The userspace
31 datapath-based switch is as featureful as the kernel-based
32 switch and it does not require building a kernel module, but
33 it is not as fast as the kernel-based switch and it is part
34 of the OpenFlow extensions distribution, not the main
35 OpenFlow distribution.
37 The reference implementation also contains a simple OpenFlow
38 controller (built as controller/controller) and a number of related
44 There are two principal ways to build and install this distribution:
46 - Using "configure" and "make" in the ordinary way. See
47 Building Conventionally below for detailed instructions.
49 - As a set of Debian packages. Refer to Building Debian
50 Packages, below, for instructions.
55 Regardless of how it is built, OpenFlow has a common set of
56 prerequisites. To compile the userspace programs in the OpenFlow
57 reference distribution, you will need the following software:
59 - A make program, e.g. GNU make
60 (http://www.gnu.org/software/make/). BSD make should also work.
62 - The GNU C compiler (http://gcc.gnu.org/). We generally test
63 with version 4.1 or 4.2.
65 - libssl, from OpenSSL (http://www.openssl.org/), is optional but
66 recommended. libssl is required to establish confidentiality
67 and authenticity in the connections among OpenFlow switches and
68 controllers. To enable, configure with --enable-ssl=yes
70 If you are working from a Git tree or snapshot (instead of from a
71 distribution tarball), or if you modify the OpenFlow build system, you
72 will also need the following software:
74 - Autoconf version 2.59 or later (http://www.gnu.org/software/autoconf).
76 - Automake version 1.10 or later (http://www.gnu.org/software/automake).
78 - pkg-config (http://pkg-config.freedesktop.org/wiki/). We test
84 To build Debian packages from the OpenFlow distribution, you will need
85 to install a number of Debian packages in addition to the base
86 prerequisites listed above. These additional prerequisites may be
87 found listed as "Build-Depends" in debian/control in the source tree.
88 To check that they are installed, first install the dpkg-dev package,
89 then run dpkg-checkbuilddeps from the top level of the OpenFlow source
92 To build Debian packages without being root, also install the
95 Kernel-Based Switch Prerequisites
96 ---------------------------------
98 The OpenFlow distribution also includes a Linux kernel module that can
99 be used to achieve higher switching performance. To compile the
100 kernel module, you must install the following in addition to the
101 software listed in the "Base Prerequisites" section above:
103 - A supported Linux kernel version. Please refer to README for a
104 list of supported versions.
106 The OpenFlow datapath requires bridging support (CONFIG_BRIDGE)
107 to be built as a kernel module. (This is common in kernels
108 provided by Linux distributions.) The bridge module must not be
109 loaded or in use. If the bridge module is running (check with
110 "lsmod | grep bridge"), you must remove it ("rmmod bridge")
111 before starting the datapath.
113 In kernels prior to 2.6.9, VLAN support (CONFIG_VLAN_8021Q) must
114 be compiled either directly or as a module. Failure to do this
115 will cause an error on module insertion due to the
116 "dev_change_flags" symbol being undefined.
118 - The correct version of GCC for the kernel that you are building
121 * To build a kernel module for a Linux 2.6 kernel, you need
122 the same version of GCC that was used to build that kernel
123 (usually version 4.0 or later).
125 * To build a kernel module for a Linux 2.4 kernel, you need an
126 earlier version of GCC, typically GCC 2.95, 3.3, or 3.4.
128 - A kernel build directory corresponding to the Linux kernel image
129 the module is to run on. Under Debian and Ubuntu, for example,
130 each linux-image package containing a kernel binary has a
131 corresponding linux-headers package with the required build
134 Building Conventionally
135 =======================
137 This section explains how to build and install the OpenFlow
138 distribution in the ordinary way using "configure" and "make".
140 0. Check that you have installed all the prerequisites listed above in
141 the Base Prerequisites section. If you want to compile the Linux
142 kernel module, also check that the prequisites listed under
143 Kernel-Based Switch Prequisites are installed.
145 1. In the top source directory, configure the package by running the
146 configure script. You can usually invoke configure without any
151 To use a specific C compiler for compiling OpenFlow user programs,
152 also specify it on the configure command line, like so:
154 % ./configure CC=gcc-4.2
156 To build the Linux kernel module, so that you can run the
157 kernel-based switch, add --with-l26 or --with-l24 option, or both,
158 to the configure script's command line. Refer to Building the
159 Linux Kernel-Based Switch, below, for more information.
161 The configure script accepts a number of other options and honors
162 additional environment variables. For a full list, invoke
163 configure with the --help option.
165 2. Run make in the top source directory:
169 The following binaries will be built:
171 - Switch executable: switch/switch.
173 - Secure channel executable: secchan/secchan.
175 - Controller executable: controller/controller.
177 - Datapath administration utility: utilities/dpctl.
179 - Runtime logging configuration utility: utilities/vlogconf.
181 - Miscellaneous utilities: utilities/ofp-discover,
184 - Tests: various binaries in tests/.
186 If your distribution includes the OpenFlow extensions, the
187 following additional binaries will be built:
189 - Userspace datapath: ext/udatapath/udatapath.
191 - ANSI terminal support for EZIO 16x2 LCD panel:
194 - Switch monitoring UI for small text displays:
195 ext/ezio/ofp-switchmon.
197 If you passed --with-l26 to configure, "make" will also build the
198 following kernel modules:
200 - datapath/linux-2.6/openflow_mod.ko
202 - datapath/linux-2.6/hwtable_<table>_mod.ko for each <table>
203 specified on --enable-hw-tables (if any).
205 If you passed --with-l24 to configure, "make" will also build the
206 following kernel modules:
208 - datapath/linux-2.4/openflow_mod.o
210 - datapath/linux-2.6/hwtable_<table>_mod.o for each <table>
211 specified on --enable-hw-tables (if any).
213 3. Run "make install" to install the executables and manpages into the
214 running system, by default under /usr/local.
216 4. If you built kernel modules, you may load them with "insmod", e.g.:
219 % insmod datapath/linux-2.6/openflow_mod.ko
222 % insmod datapath/linux-2.4/compat24_mod.o
223 % insmod datapath/linux-2.4/openflow_mod.o
225 After you load the openflow module, you may load one hardware switch
226 table module (if any were built) to enable support for that hardware
229 The insmod program must be run as root. You may need to specify a
230 full path to insmod, e.g. /sbin/insmod. To verify that the modules
231 have been loaded, run "/sbin/lsmod" and check that openflow_mod is
234 4. Test the userspace programs, as described under Testing Userspace
237 5. If you built the kernel module, test the kernel-based switch, as
238 described under Testing the Kernel-Based Implementation below.
240 Building the Linux Kernel-Based Switch
241 --------------------------------------
243 To build the kernel module, follow the build process described above,
244 but pass the location of the kernel build directory as an additional
245 argument to the configure script, as described under step 1 in that
246 section. Specify the location on --with-l26 for Linux 2.6, --with-l24
247 for Linux 2.4. For example, to build for a running instance of Linux
250 % ./configure --with-l26=/lib/modules/`uname -r`/build
252 To build for a running instance of Linux 2.4:
254 % ./configure --with-l24=/lib/modules/`uname -r`/build
256 If you wish to build OpenFlow for an architecture other than the
257 architecture used for compilation, you may specify the kernel
258 architecture string using the KARCH variable when invoking the
259 configure script. For example, to build OpenFlow for MIPS with Linux
262 % ./configure --with-l24=/path/to/linux-2.4 KARCH=mips
264 If you have hardware that supports accelerated OpenFlow switching, and
265 you have obtained a hardware table module for your hardware and
266 extracted it into the OpenFlow reference distribution source tree,
267 then you may also enable building support for the hardware switching
268 table with --enable-hw-tables. For example, if your hardware
269 switching table is in a directory named datapath/hwtable-foomatic, you
270 could compile support for it with the running Linux 2.6 kernel like
273 % ./configure --with-l26=/lib/modules/`uname -r`/build \
274 --enable-hw-tables=foomatic
276 For more information about hardware table modules, please read
277 README.hwtables at the root of the OpenFlow distribution tree.
279 Building Debian Packages
280 ========================
282 Follow these instructions to build Debian packages for OpenFlow.
284 0. Check that you have installed all the prerequisites listed above in
285 the Base Prerequisites and Debian Prerequisites sections above.
287 1. In the top source directory, run the following command, as root:
291 Alternatively, if you installed the "fakeroot" package, you may run
292 dpkg-buildpackage as an ordinary user with the following syntax:
294 % dpkg-buildpackage -rfakeroot
296 The following packages will be built in the directory above the
299 - openflow-controller: The OpenFlow controller. Depends on
300 openflow-pki (see below).
302 - openflow-switch: Install this package on a machine that acts
303 as an OpenFlow userspace or kernel switch.
305 - openflow-datapath-source: Source code for OpenFlow's Linux
308 - openflow-pki: Public-key infrastructure for OpenFlow. Install
309 this package on a machine that acts as an OpenFlow PKI server
310 (see "Establishing a Public Key Infrastructure" below).
312 - openflow-common: Files and utilities required by more than one
313 of the above packages.
315 2. To set up an OpenFlow controller, install the openflow-controller
316 package and its dependencies. You may configure it by editing
317 /etc/default/openflow-controller, e.g. to enable non-SSL
318 connections, which are disabled by default. If you change the
319 default settings, you will need to restart the controller by
322 % /etc/init.d/openflow-controller restart
324 3. To set up an OpenFlow switch, install the openflow-switch package
325 and its dependencies. If it is to be a kernel-based switch, also
326 install openflow-datapath-source, then follow the instructions in
327 /usr/share/doc/openflow-datapath-source/README.Debian to build and
328 install the kernel module.
330 You may configure the switch one of the following ways:
332 - Completely by hand, as described under the Testing section
335 For the userspace switch, this is the only supported form of
338 - By editing /etc/default/openflow-switch. You must at least
339 configure some network devices, by uncommenting NETDEVS and
340 adding the appropriate devices to the list, e.g. NETDEVS="eth0
343 After you edit this file, you will need to start the switch by
346 % /etc/init.d/openflow-switch restart
348 This form of configuration is not supported for the userspace
351 - By running the ofp-switch-setup program. This interactive
352 program will walk you through all the steps of configuring an
353 OpenFlow switch, including configuration of SSL certificates.
354 Run it without arguments, as root:
358 This form of configuration is not supported for the userspace
364 The following sets of instructions show how to use the OpenFlow
365 reference implementation as a switch on a single machine. This can be
366 used to verify that the distribution built properly. For full
367 installation instructions, refer to the Installation section below.
372 These instructions use the OpenFlow userspace switch that runs as an
373 integrated userspace program.
375 0. The commands below must run as root, so log in as root, or use a
376 program such as "su" to become root temporarily.
378 1. Start the OpenFlow controller running in the background, by running
379 the "controller" program with a command like the following:
383 This command causes the controller to bind to port 975 (the
384 default) awaiting connections from OpenFlow switches. See
385 controller(8) for details.
387 2. On the same machine, use the "switch" program to start an OpenFlow
388 switch, specifying network devices to use as switch ports on the -i
389 option as a comma-separated list, like so:
391 # switch tcp:127.0.0.1 -i eth1,eth2
393 The network devices that you specify should not have configured IP
396 3. The controller causes each switch that connects to it to act like a
397 learning Ethernet switch. Thus, devices plugged into the specified
398 network ports should now be able to send packets to each other, as
399 if they were plugged into ports on a conventional Ethernet switch.
401 Troubleshooting: if the commands above do not work, try using the -v
402 or --verbose option on the controller or switch commands, which will
403 cause a large amount of debug output from each program.
408 These instructions use the OpenFlow userspace datapath ("udatapath").
409 The udatapath program is part of the OpenFlow extensions repository,
410 which is not included in every OpenFlow distribution.
412 0. The commands below must run as root, so log in as root, or use a
413 program such as "su" to become root temporarily.
415 1. Start the OpenFlow controller running in the background, by running
416 the "controller" program with a command like the following:
418 # controller punix:/var/run/controller.sock &
420 This command causes the controller to bind to the specified Unix
421 domain socket, awaiting connections from OpenFlow switches. See
422 controller(8) for details.
424 2. Create a datapath instance running in the background. The command
425 below creates a datapath that listens for connections from secchan
426 on a Unix domain socket located in /var/run and services physical
429 # udatapath punix:/var/run/dp0.sock -i eth1,eth2 &
431 3. Run secchan to start the secure channel connecting the datapath and
434 # secchan unix:/var/run/controller.sock unix:/var/run/dp0.sock &
436 4. Devices plugged into the network ports specified in step 2 should
437 now be able to send packets to each other, as if they were plugged
438 into ports on a conventional Ethernet switch.
443 This section explains how to install OpenFlow in a network with one
444 controller and one or more switches, each of which runs on a separate
445 machine. Before you begin, you must decide on one of two ways for
446 each switch to reach the controller over the network:
448 - Use a "control network" that is completely separate from the
449 "data network" to be controlled ("out-of-band control"). The
450 location of the controller must be configured manually in this
453 All three switch implementations support only out-of-band
456 - Use the same network for control and for data ("in-band
457 control"). When in-band control is used, the location of the
458 controller may be configured manually or discovered
459 automatically. We will assume manual configuration here;
460 please refer to secchan(8) for instructions on setting up
461 controller discovery.
463 The userspace datapath-based and kernel-based switch
464 implementations support in-band control. The userspace switch
470 On the machine that is to be the OpenFlow controller, start the
471 "controller" program listening for connections from switches on TCP
472 port 975 (the default), as shown below. (Because it listens on a
473 low-numbered port, this command must run as root.)
475 # controller -v ptcp:
477 (See controller(8) for more details)
479 Make sure the machine hosting the controller is reachable by the
482 Userspace Switch-Based Setup
483 ----------------------------
485 To set up an OpenFlow switch using the userspace switch, follow this
486 procedure. The userspace switch must be connected to the controller
487 over a "control network" that is physically separate from the one that
488 the switch and controller are controlling. (The kernel-based and
489 userspace datapath-based switches do not have this limitation.)
491 0. The commands below must run as root, so log in as root, or use a
492 program such as "su" to become root temporarily.
494 1. Use the "switch" program to start an OpenFlow switch, specifying
495 the IP address of the controller as the first argument to the
496 switch program, and the network devices to include in the switch as
497 arguments to the -i option. For example, if the controller is
498 running on host 192.168.1.2 port 975 (the default port), and eth1
499 and eth2 are to be the switch ports, the switch invocation would
502 # switch tcp:127.0.0.1 -i eth1,eth2
504 The network devices that you specify should not have configured IP
507 2. The controller causes each switch that connects to it to act like a
508 learning Ethernet switch. Thus, devices plugged into the specified
509 network ports should now be able to send packets to each other, as
510 if they were plugged into ports on a conventional Ethernet switch.
512 Userspace Datapath-Based Setup
513 ------------------------------
515 On a machine that is to host an OpenFlow userspace datapath-based
516 switch, follow the procedure below. These instructions require the
517 OpenFlow userspace datapath ("udatapath"). The udatapath program is
518 part of the OpenFlow extensions repository, which is not included in
519 every OpenFlow distribution.
521 0. The commands below must run as root, so log in as root, or use a
522 program such as "su" to become root temporarily.
524 1. Create a datapath instance running in the background. The command
525 below creates a datapath that listens for connections from secchan
526 on a Unix domain socket located in /var/run, services physical
527 ports eth1 and eth2, and creates a TAP network device named "tap0"
528 for use in in-band control:
530 # udatapath punix:/var/run/dp0.sock -i eth1,eth2 --local-port=tap:tap0 &
532 (See udatapath(8) for details.)
534 If the switch will connect to the controller out-of-band, then the
535 --local-port option may be omitted, or --no-local-port may be
538 3. Arrange so that the switch can reach the controller over the
541 - If you are using out-of-band control, at this point make sure
542 that the switch machine can reach the controller over the
545 - If you are using in-band control with manual configuration, at
546 this point the TAP network device created in step 1 is not
547 bridged to any physical network, so the next step depends on
548 whether connectivity is required to configure the device's IP
551 * If the switch has a static IP address, you may configure
552 its IP address now, e.g.:
554 # ifconfig tap0 192.168.1.1
556 * If the switch does not have a static IP address, e.g. its
557 IP address is obtained dynamically via DHCP, then proceed
558 to step 4. The DHCP client will not be able to contact
559 the DHCP server until the secure channel has started up.
561 - If you are using in-band control with controller discovery, no
562 configuration is required at this point. You may proceed to
565 4. Run secchan to start the secure channel connecting the datapath to
566 a remote controller. If the controller is running on host
567 192.168.1.2 port 975 (the default port), the secchan invocation
568 would look like this:
570 # secchan unix:/var/run/dp0.sock tcp:192.168.1.2
572 - If you are using in-band control with controller discovery, omit
573 the second argument to the secchan command.
575 - If you are using out-of-band control, add --out-of-band to the
578 5. If you are using in-band control with manual configuration, and the
579 switch obtains its IP address dynamically, then you may now obtain
580 the switch's IP address, e.g. by invoking a DHCP client. The
581 secure channel will only be able to connect to the controller after
582 an IP address has been obtained.
584 6. The secure channel should connect to the controller within a few
585 seconds. It may take a little longer if controller discovery is in
586 use, because the switch must then also obtain its own IP address
587 and the controller's location via DHCP.
589 Testing the Kernel-Based Implementation
590 ---------------------------------------
592 The OpenFlow kernel module must be loaded, as described under
593 "Building Conventionally", before it may be used.
595 0. The commands below must run as root, so log in as root, or use a
596 program such as "su" to become root temporarily.
598 1. Create a datapath instance. The command below creates a datapath
599 identified as nl:0 (see dpctl(8) for more detailed usage
604 (In principle, openflow_mod supports multiple datapaths within the
605 same host which would be identified as nl:1, nl:2, etc., but this
606 is rarely useful in practice.)
608 Creating datapath nl:0 also creates a new network device named of0.
609 This network device, called the datapath's "local port", will be
610 bridged to the physical switch ports by the secchan, for use in
613 If you built a support module for hardware accelerated OpenFlow
614 switching and you want to use it, you must load it before creating
615 the datapath with "dpctl adddp".
617 2. Use dpctl to attach the datapath to physical interfaces on the
618 machine. Say, for example, you want to create a trivial 2-port
619 switch using interfaces eth1 and eth2, you would issue the following
622 # dpctl addif nl:0 eth1
623 # dpctl addif nl:0 eth2
625 You can verify that the interfaces were successfully added by asking
626 dpctl to print the current status of datapath nl:0:
630 3. Arrange so that the switch can reach the controller over the
633 - If you are using out-of-band control, at this point make sure
634 that the switch machine can reach the controller over the
637 - If you are using in-band control, then at this point you must
638 configure the of0 network device created in step 1. This
639 device is not yet bridged to any physical network (because
640 secchan does that, and it is not yet running), so the next
641 step depends on whether connectivity is required to configure
642 the device's IP address:
644 * If the switch has a static IP address, you may configure
645 its IP address now, e.g.:
647 # ifconfig of0 192.168.1.1
649 * If the switch does not have a static IP address, e.g. its
650 IP address is obtained dynamically via DHCP, then proceed
651 to step 4. The DHCP client will not be able to contact
652 the DHCP server until the secure channel has started up.
654 - If you are using in-band control with controller discovery, no
655 configuration is required at this point. You may proceed to
658 4. Run secchan to start the secure channel connecting the datapath to
659 a remote controller. If the controller is running on host
660 192.168.1.2 port 975 (the default port), the secchan invocation
661 would look like this:
663 # secchan nl:0 tcp:192.168.1.2
665 - If you are using in-band control with controller discovery, omit
666 the second argument to the secchan command.
668 - If you are using out-of-band control, add --out-of-band to the
671 5. If you are using in-band control with manual configuration, and the
672 switch obtains its IP address dynamically, then you may now obtain
673 the switch's IP address, e.g. by invoking a DHCP client. The
674 secure channel will only be able to connect to the controller after
675 an IP address has been obtained.
677 6. The secure channel should connect to the controller within a few
678 seconds. It may take a little longer if controller discovery is in
679 use, because the switch must then also obtain its own IP address
680 and the controller's location via DHCP.
685 Secure operation over SSL
686 -------------------------
688 The instructions above set up OpenFlow for operation over a plaintext
689 TCP connection. Production use of OpenFlow should use SSL[*] to
690 ensure confidentiality and authenticity of traffic among switches and
691 controllers. The source must be configured with --enable-ssl=yes to
692 build with SSL support.
694 To use SSL with OpenFlow, you must set up a public-key infrastructure
695 (PKI) including a pair of certificate authorities (CAs), one for
696 controllers and one for switches. If you have an established PKI,
697 OpenFlow can use it directly. Otherwise, refer to "Establishing a
698 Public Key Infrastructure" below.
700 To configure the controller to listen for SSL connections on port 976
701 (the default), invoke it as follows:
703 # controller -v pssl: --private-key=PRIVKEY --certificate=CERT \
706 where PRIVKEY is a file containing the controller's private key, CERT
707 is a file containing the controller CA's certificate for the
708 controller's public key, and CACERT is a file containing the root
709 certificate for the switch CA. If, for example, your PKI was created
710 with the instructions below, then the invocation would look like:
712 # controller -v pssl: --private-key=ctl-privkey.pem \
713 --certificate=ctl-cert.pem --ca-cert=pki/switchca/cacert.pem
715 To configure a switch to connect to a controller running on port 976
716 (the default) on host 192.168.1.2 over SSL, invoke secchan as follows:
718 # secchan -v DATAPATH ssl:192.168.1.2 --private-key=PRIVKEY \
719 --certificate=CERT --ca-cert=CACERT
721 where DATAPATH is the datapath to connect to (e.g. nl:0 or
722 unix:/var/run/dp0.sock), PRIVKEY is a file containing the switch's
723 private key, CERT is a file containing the switch CA's certificate for
724 the switch's public key, and CACERT is a file containing the root
725 certificate for the controller CA. If, for example, your PKI was
726 created with the instructions below, then the invocation would look
729 # secchan -v DATAPATH ssl:192.168.1.2 --private-key=sc-privkey.pem \
730 --certificate=sc-cert.pem --ca-cert=pki/controllerca/cacert.pem
732 [*] To be specific, OpenFlow uses TLS version 1.0 or later (TLSv1), as
733 specified by RFC 2246, which is very similar to SSL version 3.0.
734 TLSv1 was released in January 1999, so all current software and
735 hardware should implement it.
737 Establishing a Public Key Infrastructure
738 ----------------------------------------
740 If you do not have a PKI, the ofp-pki script included with OpenFlow
741 can help. To create an initial PKI structure, invoke it as:
743 which will create and populate a new PKI directory. The default
744 location for the PKI directory depends on how the OpenFlow tree was
745 configured (to see the configured default, look for the --dir option
746 description in the output of "ofp-pki --help").
748 The pki directory contains two important subdirectories. The
749 controllerca subdirectory contains controller certificate authority
750 related files, including the following:
752 - cacert.pem: Root certificate for the controller certificate
753 authority. This file must be provided to the switch or secchan
754 program with the --ca-cert option to enable it to authenticate
757 - private/cakey.pem: Private signing key for the controller
758 certificate authority. This file must be kept secret. There is
759 no need for switches or controllers to have a copy of it.
761 The switchca subdirectory contains switch certificate authority
762 related files, analogous to those in the controllerca subdirectory:
764 - cacert.pem: Root certificate for the switch certificate
765 authority. This file must be provided to the controller program
766 with the --ca-cert option to enable it to authenticate valid
769 - private/cakey.pem: Private signing key for the switch
770 certificate authority. This file must be kept secret. There is
771 no need for switches or controllers to have a copy of it.
773 After you create the initial structure, you can create keys and
774 certificates for switches and controllers with ofp-pki. To create a
775 controller private key and certificate in files named ctl-privkey.pem
776 and ctl-cert.pem, for example, you could run:
777 % ofp-pki req+sign ctl controller
778 ctl-privkey.pem and ctl-cert.pem would need to be copied to the
779 controller for its use at runtime (they could then be deleted from
780 their original locations). The --private-key and --certificate
781 options of controller, respectively, would point to these files.
783 Analogously, to create a switch private key and certificate in files
784 named sc-privkey.pem and sc-cert.pem, for example, you could run:
785 % ofp-pki req+sign sc switch
786 sc-privkey.pem and sc-cert.pem would need to be copied to the switch
787 for its use at runtime (they could then be deleted from their original
788 locations). The --private-key and --certificate options,
789 respectively, of switch and secchan would point to these files.
794 Please report problems to:
795 info@openflowswitch.org