X-Git-Url: http://git.cascardo.eti.br/?a=blobdiff_plain;f=debian%2Fopenvswitch-switch.README.Debian;h=5f8f823341ceb8e454679c37d91a9032bcda5538;hb=0f9bd013cccfb8f7aca9fc720b1acadce2a46dc0;hp=8617e77103eadb55a5083de6400efde53109b29e;hpb=ba3bbb4ca7d55495f5491ed2d3deec8bdd4babae;p=cascardo%2Fovs.git diff --git a/debian/openvswitch-switch.README.Debian b/debian/openvswitch-switch.README.Debian index 8617e7710..5f8f82334 100644 --- a/debian/openvswitch-switch.README.Debian +++ b/debian/openvswitch-switch.README.Debian @@ -1,15 +1,44 @@ README.Debian for openvswitch-switch --------------------------------- -* To use the Linux kernel-based switch implementation, you will need - to build and install the Open vSwitch kernel module. To do so, install - the openvswitch-datapath-source package, then follow the instructions - given in /usr/share/doc/openvswitch-datapath-source/README.Debian +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: -* This package does not yet support the userspace datapath-based - switch implementation. + * 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. - -- Ben Pfaff , Fri, 6 Jul 2012 15:12:38 -0700 Debian network scripts integration ---------------------------------- @@ -27,9 +56,10 @@ allow-br0 eth0 The following OVS specific "command" options are supported: - - ovs_type: This can either be OVSBridge, OVSPort, OVSIntPort or OVSBond - depending on whether you configure a bridge, port, an internal port or - a bond. This is a required option. + - 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. @@ -39,6 +69,15 @@ The following OVS specific "command" options are supported: - 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. @@ -121,9 +160,74 @@ iface bond0 inet manual ovs_bonds eth2 eth3 ovs_options bond_mode=balance-tcp lacp=active -ex 6: Create and destroy bridges. +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 --- Gurucharan Shetty , Fri, 04 May 2012 12:58:19 -0700 +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.