README.Debian for openvswitch-switch --------------------------------- To use the Linux kernel-based switch implementation, you will need an Open vSwitch kernel module. There are multiple ways to obtain one. In order of increasing manual effort, these are: * Use a Linux kernel 3.3 or later, which has an integrated Open vSwitch kernel module. The upstream Linux kernel module lacks a few features that are in the third-party module. For details, please see the FAQ, "What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel?". * Install the "openvswitch-datapath-dkms" Debian package that you built earlier. This should automatically build and install the Open vSwitch kernel module for your running kernel. This option requires that you have a compiler and toolchain installed on the machine where you run Open vSwitch, which may be unacceptable in some production server environments. * Install the "openvswitch-datapath-source" Debian package, use "module-assistant" to build a Debian package of the Open vSwitch kernel module for your kernel, and then install that Debian package. You can install the kernel module Debian packages that you build this way on the same machine where you built it or on another machine or machines, which means that you don't necessarily have to have any build infrastructure on the machines where you use the kernel module. /usr/share/doc/openvswitch-datapath-source/README.Debian has details on the build process. * Build and install the kernel module by hand. Debian network scripts integration ---------------------------------- This package lets a user to optionally configure Open vSwitch bridges and ports from /etc/network/interfaces. Please refer to the interfaces(5) manpage for more details regarding /etc/network/interfaces. The stanzas that configure the OVS bridges should begin with "allow-ovs" followed by name of the bridge. Here is an example. allow-ovs br0 The stanzas that configure the OVS ports should begin with "allow-${bridge-name}" followed by name of the port. Here is an example. allow-br0 eth0 The following OVS specific "command" options are supported: - ovs_type: This can either be OVSBridge, OVSPort, OVSIntPort, OVSBond, OVSPatchPort or OVSTunnel depending on whether you configure a bridge, port, an internal port, a bond, a patch port or a tunnel. This is a required option. - ovs_ports: This option specifies all the ports that belong to a bridge. - ovs_bridge: This options specifies a bridge to which a port belongs. This is a required option for a port. - ovs_bonds: This option specifies the list of physical interfaces to be bonded together. - ovs_patch_peer: For "OVSPatchPort" interfaces, this field specifies the patch's peer on the other bridge. - ovs_tunnel_type: For "OVSTunnel" interfaces, the type of the tunnel. For example, "gre", "vxlan", etc. - ovs_tunnel_options: For "OVSTunnel" interfaces, this field should be used to specify the tunnel options like remote_ip, key, etc. - ovs_options: This option lets you add extra arguments to a ovs-vsctl command. See examples. - ovs_extra: This option lets you run additional ovs-vsctl commands, separated by "--" (double dash). Variables can be part of the "ovs_extra" option. You can provide all the standard environmental variables described in the interfaces(5) man page. You can also pass shell commands. More implementation specific details can be seen in the examples. Examples: -------- ex 1: A standalone bridge. allow-ovs br0 iface br0 inet static address 192.168.1.1 netmask 255.255.255.0 ovs_type OVSBridge ex 2: A bridge with one port. allow-ovs br0 iface br0 inet dhcp ovs_type OVSBridge ovs_ports eth0 allow-br0 eth0 iface eth0 inet manual ovs_bridge br0 ovs_type OVSPort ex 3: A bridge with multiple physical ports. allow-ovs br0 iface br0 inet dhcp ovs_type OVSBridge ovs_ports eth0 eth1 allow-br0 eth0 iface eth0 inet manual ovs_bridge br0 ovs_type OVSPort allow-br0 eth1 iface eth1 inet manual ovs_bridge br0 ovs_type OVSPort ex 4: A bridge with an OVS internal port. allow-ovs br1 iface br1 inet static address 192.168.1.1 netmask 255.255.255.0 ovs_type OVSBridge ovs_ports vlan100 allow-br1 vlan100 iface vlan100 inet manual ovs_bridge br1 ovs_type OVSIntPort ovs_options tag=100 ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname -s) ex 5: Bonding. allow-ovs br2 iface br2 inet static address 192.170.1.1 netmask 255.255.255.0 ovs_type OVSBridge ovs_ports bond0 allow-br2 bond0 iface bond0 inet manual ovs_bridge br2 ovs_type OVSBond ovs_bonds eth2 eth3 ovs_options bond_mode=balance-tcp lacp=active ex 6: Patch ports. allow-ovs br0 iface br0 inet manual ovs_type OVSBridge ovs_ports patch0 allow-br0 patch0 iface patch0 inet manual ovs_bridge br0 ovs_type OVSPatchPort ovs_patch_peer patch1 allow-ovs br1 iface br1 inet manual ovs_type OVSBridge ovs_ports patch1 allow-br1 patch1 iface patch1 inet manual ovs_bridge br1 ovs_type OVSPatchPort ovs_patch_peer patch0 ex 7: Tunnel. allow-ovs br1 iface br1 inet static address 192.168.1.1 netmask 255.255.255.0 ovs_type OVSBridge ovs_ports gre1 allow-br1 gre1 iface gre1 inet manual ovs_bridge br1 ovs_type OVSTunnel ovs_tunnel_type gre ovs_tunnel_options options:remote_ip=182.168.1.2 options:key=1 ex 8: Create and destroy bridges. ifup --allow=ovs $list_of_bridges ifdown --allow=ovs $list_of_bridges Notes on dependencies: --------------------- openvswitch-switch depends on $network, $named $remote_fs and $syslog to start. This creates some startup dependency issues. * Since openvswitch utilities are placed in /usr and /usr can be mounted through NFS, openvswitch has to start after it. But if a user uses openvswitch for all his networking needs and hence to mount NFS, there will be a deadlock. So, if /usr is mounted through NFS and openvswitch is used for all networking, the administrator should figure out a way to mount NFS before starting OVS. One way to do this is in initramfs. * Since openvswitch starts after $network, $remote_fs and $syslog, any startup script that depends on openvswitch but starts before it, needs to be changed to depend on openvswitch-switch too. * Ideally, an admin should not add openvswitch bridges in the 'auto' section of the 'interfaces' file. This is because, when ifupdown starts working on bridges listed in 'auto', openvswitch has not yet started. But, if the admin wants to go down this route and adds openvswitch bridges in the 'auto' section, openvswitch-switch will forcefully be started when ifupdown kicks in. In a case like this, the admin needs to make sure that /usr has already been mounted and that a remote $syslog (if used) is ready to receive openvswitch logs.