From patchwork Wed Jun 12 07:18:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Numan Siddique X-Patchwork-Id: 1114324 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45Nyvr2FgNz9s4Y for ; Wed, 12 Jun 2019 17:20:54 +1000 (AEST) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id C0ADD1608; Wed, 12 Jun 2019 07:20:50 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2042A15EA for ; Wed, 12 Jun 2019 07:19:00 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2063F87E for ; Wed, 12 Jun 2019 07:18:50 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A67731628FD for ; Wed, 12 Jun 2019 07:18:39 +0000 (UTC) Received: from nusiddiq.mac (unknown [10.74.10.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id D6024513EC for ; Wed, 12 Jun 2019 07:18:31 +0000 (UTC) From: nusiddiq@redhat.com To: dev@openvswitch.org Date: Wed, 12 Jun 2019 12:48:22 +0530 Message-Id: <20190612071822.24182-1-nusiddiq@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 12 Jun 2019 07:18:39 +0000 (UTC) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [ovs-dev] [PATCH ovn 1/4] Documentation cleanup: tutorial section X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org From: Numan Siddique Also deleted the contents of Documentation/howto/ipsec.rst and Documentation/howto/ssl.rst and instead updated them to refer to the Open vSwitch documentation. Signed-off-by: Numan Siddique Acked-by: Ben Pfaff --- Documentation/automake.mk | 4 - Documentation/howto/ipsec.rst | 167 +-- Documentation/howto/ssl.rst | 311 +---- Documentation/index.rst | 6 +- Documentation/tutorials/faucet.rst | 1436 --------------------- Documentation/tutorials/index.rst | 4 - Documentation/tutorials/ipsec.rst | 347 ----- Documentation/tutorials/ovn-ipsec.rst | 4 +- Documentation/tutorials/ovn-sandbox.rst | 8 +- Documentation/tutorials/ovs-advanced.rst | 941 -------------- Documentation/tutorials/ovs-conntrack.rst | 572 -------- 11 files changed, 9 insertions(+), 3791 deletions(-) delete mode 100644 Documentation/tutorials/faucet.rst delete mode 100644 Documentation/tutorials/ipsec.rst delete mode 100644 Documentation/tutorials/ovs-advanced.rst delete mode 100644 Documentation/tutorials/ovs-conntrack.rst diff --git a/Documentation/automake.mk b/Documentation/automake.mk index a5ef29252..181a69cab 100644 --- a/Documentation/automake.mk +++ b/Documentation/automake.mk @@ -22,12 +22,8 @@ DOC_SOURCE = \ Documentation/intro/install/windows.rst \ Documentation/intro/install/xenserver.rst \ Documentation/tutorials/index.rst \ - Documentation/tutorials/faucet.rst \ - Documentation/tutorials/ovs-advanced.rst \ Documentation/tutorials/ovn-openstack.rst \ Documentation/tutorials/ovn-sandbox.rst \ - Documentation/tutorials/ovs-conntrack.rst \ - Documentation/tutorials/ipsec.rst \ Documentation/tutorials/ovn-ipsec.rst \ Documentation/tutorials/ovn-rbac.rst \ Documentation/topics/index.rst \ diff --git a/Documentation/howto/ipsec.rst b/Documentation/howto/ipsec.rst index 17153ac2b..7730b5050 100644 --- a/Documentation/howto/ipsec.rst +++ b/Documentation/howto/ipsec.rst @@ -25,170 +25,5 @@ Encrypt Open vSwitch Tunnels with IPsec ======================================= -This document gives detailed description on the OVS IPsec tunnel and its -configuration modes. If you want to follow a step-by-step guide to run and -test IPsec tunnel, please refer to :doc:`/tutorials/ipsec`. +Please refer to the Open vSwitch documentation on ipsec. -Overview --------- - -Why do encryption? -~~~~~~~~~~~~~~~~~~ - -OVS tunnel packets are transported from one machine to another. Along the path, -the packets are processed by physical routers and physical switches. There are -risks that these physical devices might read or write the contents of the -tunnel packets. IPsec encrypts IP payload and prevents the malicious party -sniffing or manipulating the tunnel traffic. - -OVS IPsec -~~~~~~~~~ - -OVS IPsec aims to provide a simple interface for user to add encryption on OVS -tunnels. It supports GRE, GENEVE, VXLAN, and STT tunnel. The IPsec -configuration is done by setting options of the tunnel interface and -other_config of Open_vSwitch. You can choose different authentication methods -and plaintext tunnel policies based on your requirements. - -OVS does not currently provide any support for IPsec encryption for traffic not -encapsulated in a tunnel. - -Configuration -------------- - -Authentication Methods -~~~~~~~~~~~~~~~~~~~~~~ - -Hosts of the IPsec tunnel need to authenticate each other to build a secure -channel. There are three authentication methods: - -1) You can use a pre-shared key (PSK) to do authentication. In both hosts, set - the same PSK value. This PSK is like your password. You should never reveal - it to untrusted parties. This method is easier to use but less secure than - the certificate-based methods:: - - $ ovs-vsctl add-port br0 ipsec_gre0 -- \ - set interface ipsec_gre0 type=gre \ - options:remote_ip=2.2.2.2 \ - options:psk=swordfish - -2) You can use a self-signed certificate to do authentication. In each host, - generate a certificate and the paired private key. Copy the certificate of - the remote host to the local host and configure the OVS as following:: - - $ ovs-vsctl set Open_vSwitch . \ - other_config:certificate=/path/to/local_cert.pem \ - other_config:private_key=/path/to/priv_key.pem - $ ovs-vsctl add-port br0 ipsec_gre0 -- \ - set interface ipsec_gre0 type=gre \ - options:remote_ip=2.2.2.2 \ - options:remote_cert=/path/to/remote_cert.pem - - `local_cert.pem` is the certificate of the local host. `priv_key.pem` - is the private key of the local host. `priv_key.pem` needs to be stored in - a secure location. `remote_cert.pem` is the certificate of the remote host. - - .. note:: - - OVS IPsec requires x.509 version 3 certificate with the subjectAltName - DNS field setting the same string as the common name (CN) field. You can - follow the tutorial in :doc:`/tutorials/ipsec` and use ovs-pki(8) to - generate compatible certificate and key. - - (Before OVS version 2.10.90, ovs-pki(8) did not generate x.509 v3 - certificates, so if your existing PKI was generated by an older version, - it is not suitable for this purpose.) - -3) You can also use CA-signed certificate to do authentication. First, you need - to create a CA certificate and sign each host certificate with the CA key - (please see :doc:`/tutorials/ipsec`). Copy the CA certificate to each - host and configure the OVS as following:: - - $ ovs-vsctl set Open_vSwitch . \ - other_config:certificate=/path/to/local_cert.pem \ - other_config:private_key=/path/to/priv_key.pem \ - other_config:ca_cert=/path/to/ca_cert.pem - $ ovs-vsctl add-port br0 ipsec_gre0 -- \ - set interface ipsec_gre0 type=gre \ - options:remote_ip=2.2.2.2 \ - options:remote_name=remote_cn - - `ca_cert.pem` is the CA certificate. You need to set `remote_cn` as the - common name (CN) of the remote host's certificate so that only the - certificate with the expected CN can be trusted in this connection. It is - preferable to use this method than 2) if there are many remote hosts since - you don't have to copy every remote certificate to the local host. - - .. note:: - - When using certificate-based authentication, you should not set psk in - the interface options. When using psk-based authentication, you should - not set certificate, private_key, ca_cert, remote_cert, and remote_name. - -Plaintext Policies -~~~~~~~~~~~~~~~~~~ - -When an IPsec tunnel is configured in this database, multiple independent -components take responsibility for implementing it. ``ovs-vswitchd`` and its -datapath handle packet forwarding to the tunnel and a separate daemon pushes -the tunnel's IPsec policy configuration to the kernel or other entity that -implements it. There is a race: if the former configuration completes before -the latter, then packets sent by the local host over the tunnel can be -transmitted in plaintext. Using this setting, OVS users can avoid this -undesirable situation. - -1) The default setting allows unencrypted packets to be sent before IPsec - completes negotiation:: - - $ ovs-vsctl add-port br0 ipsec_gre0 -- \ - set interface ipsec_gre0 type=gre \ - options:remote_ip=2.2.2.2 \ - options:psk=swordfish - - This setting should be used only and only if tunnel configuration is static - and/or if there is firewall that can drop the plain packets that - occasionally leak the tunnel unencrypted on OVSDB (re)configuration events. - -2) Setiing ipsec_skb_mark drops unencrypted packets by using skb_mark of - tunnel packets:: - - $ ovs-vsctl set Open_vSwitch . other_config:ipsec_skb_mark=0/1 - $ ovs-vsctl add-port br0 ipsec_gre0 -- \ - set interface ipsec_gre0 type=gre \ - options:remote_ip=2.2.2.2 \ - options:psk=swordfish - - OVS IPsec drops unencrypted packets which carry the same skb_mark as - `ipsec_skb_mark`. By setting the ipsec_skb_mark as 0/1, OVS IPsec prevents - all unencrypted tunnel packets leaving the host since the default skb_mark - value for tunnel packets are 0. This affects all OVS tunnels including those - without IPsec being set up. You can install OpenFlow rules to whitelist - those non-IPsec tunnels by setting the skb_mark of the tunnel traffic as - non-zero value. - -3) Setting `ipsec_skb_mark` as 1/1 only drops tunnel packets with skb_mark - value being 1:: - - $ ovs-vsctl set Open_vSwitch . other_config:ipsec_skb_mark=1/1 - $ ovs-vsctl add-port br0 ipsec_gre0 -- \ - set interface ipsec_gre0 type=gre \ - options:remote_ip=2.2.2.2 \ - options:psk=swordfish - - Opposite to 2), this setting passes through unencrypted tunnel packets by - default. To drop unencrypted IPsec tunnel traffic, you need to explicitly - set skb_mark to a non-zero value for those tunnel traffic by installing - OpenFlow rules. - -Bug Reporting -------------- - -If you think you may have found a bug with security implications, like - -1) IPsec protected tunnel accepted packets that came unencrypted; OR -2) IPsec protected tunnel allowed packets to leave unencrypted - -then please report such bugs according to :doc:`/internals/security`. - -If the bug does not have security implications, then report it according to -instructions in :doc:`/internals/bugs`. diff --git a/Documentation/howto/ssl.rst b/Documentation/howto/ssl.rst index 3085206fb..c2c540435 100644 --- a/Documentation/howto/ssl.rst +++ b/Documentation/howto/ssl.rst @@ -25,314 +25,5 @@ Open vSwitch with SSL ===================== -If you plan to configure Open vSwitch to connect across the network to an -OpenFlow controller, then we recommend that you build Open vSwitch with -OpenSSL. SSL support ensures integrity and confidentiality of the OpenFlow -connections, increasing network security. +Please refer to the Open vSwitch documentation on SSL. -This document describes how to configure an Open vSwitch to connect to an -OpenFlow controller over SSL. Refer to :doc:`/intro/install/general`. for -instructions on building Open vSwitch with SSL support. - -Open vSwitch uses TLS version 1.0 or later (TLSv1), as specified by RFC 2246, -which is very similar to SSL version 3.0. TLSv1 was released in January 1999, -so all current software and hardware should implement it. - -This document assumes basic familiarity with public-key cryptography and -public-key infrastructure. - -SSL Concepts for OpenFlow -------------------------- - -This section is an introduction to the public-key infrastructure architectures -that Open vSwitch supports for SSL authentication. - -To connect over SSL, every Open vSwitch must have a unique private/public key -pair and a certificate that signs that public key. Typically, the Open vSwitch -generates its own public/private key pair. There are two common ways to obtain -a certificate for a switch: - -* Self-signed certificates: The Open vSwitch signs its certificate with its own - private key. In this case, each switch must be individually approved by the - OpenFlow controller(s), since there is no central authority. - - This is the only switch PKI model currently supported by NOX - (http://noxrepo.org). - -* Switch certificate authority: A certificate authority (the "switch CA") signs - each Open vSwitch's public key. The OpenFlow controllers then check that any - connecting switches' certificates are signed by that certificate authority. - - This is the only switch PKI model supported by the simple OpenFlow controller - included with Open vSwitch. - -Each Open vSwitch must also have a copy of the CA certificate for the -certificate authority that signs OpenFlow controllers' keys (the "controller -CA" certificate). Typically, the same controller CA certificate is installed -on all of the switches within a given administrative unit. There are two -common ways for a switch to obtain the controller CA certificate: - -* Manually copy the certificate to the switch through some secure means, e.g. - using a USB flash drive, or over the network with "scp", or even FTP or HTTP - followed by manual verification. - -* Open vSwitch "bootstrap" mode, in which Open vSwitch accepts and saves the - controller CA certificate that it obtains from the OpenFlow controller on its - first connection. Thereafter the switch will only connect to controllers - signed by the same CA certificate. - -Establishing a Public Key Infrastructure ----------------------------------------- - -Open vSwitch can make use of your existing public key infrastructure. If you -already have a PKI, you may skip forward to the next section. Otherwise, if -you do not have a PKI, the ovs-pki script included with Open vSwitch can help. -To create an initial PKI structure, invoke it as: - -:: - - $ ovs-pki init - -This will create and populate a new PKI directory. The default location for -the PKI directory depends on how the Open vSwitch tree was configured (to see -the configured default, look for the ``--dir`` option description in the output -of ``ovs-pki --help``). - -The pki directory contains two important subdirectories. The `controllerca` -subdirectory contains controller CA files, including the following: - -`cacert.pem` - Root certificate for the controller certificate authority. Each Open vSwitch - must have a copy of this file to allow it to authenticate valid controllers. - -`private/cakey.pem` - Private signing key for the controller certificate authority. This file must - be kept secret. There is no need for switches or controllers to have a copy - of it. - -The `switchca` subdirectory contains switch CA files, analogous to those in the -`controllerca` subdirectory: - -`cacert.pem` - Root certificate for the switch certificate authority. The OpenFlow - controller must have this file to enable it to authenticate valid switches. - -`private/cakey.pem` - Private signing key for the switch certificate authority. This file must be - kept secret. There is no need for switches or controllers to have a copy of - it. - -After you create the initial structure, you can create keys and certificates -for switches and controllers with ovs-pki. Refer to the ovs-pki(8) manage for -complete details. A few examples of its use follow: - -Controller Key Generation -~~~~~~~~~~~~~~~~~~~~~~~~~ - -To create a controller private key and certificate in files named -ctl-privkey.pem and ctl-cert.pem, run the following on the machine that -contains the PKI structure: - -:: - - $ ovs-pki req+sign ctl controller - -ctl-privkey.pem and ctl-cert.pem would need to be copied to the controller for -its use at runtime. If, for testing purposes, you were to use -ovs-testcontroller, the simple OpenFlow controller included with Open vSwitch, -then the --private-key and --certificate options, respectively, would point to -these files. - -It is very important to make sure that no stray copies of ctl-privkey.pem are -created, because they could be used to impersonate the controller. - -Switch Key Generation with Self-Signed Certificates -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you are using self-signed certificates (see "SSL Concepts for OpenFlow"), -this is one way to create an acceptable certificate for your controller to -approve. - -1. Run the following command on the Open vSwitch itself:: - - $ ovs-pki self-sign sc - - .. note:: - This command does not require a copy of any of the PKI files generated by - ``ovs-pki init``, and you should not copy them to the switch because some - of them have contents that must remain secret for security.) - - The ``ovs-pki self-sign`` command has the following output: - - sc-privkey.pem - the switch private key file. For security, the contents of this file must - remain secret. There is ordinarily no need to copy this file off the Open - vSwitch. - - sc-cert.pem - the switch certificate, signed by the switch's own private key. Its - contents are not a secret. - -2. Optionally, copy `controllerca/cacert.pem` from the machine that has the - OpenFlow PKI structure and verify that it is correct. (Otherwise, you will - have to use CA certificate bootstrapping when you configure Open vSwitch in - the next step.) - -3. Configure Open vSwitch to use the keys and certificates (see "Configuring - SSL Support", below). - -Switch Key Generation with a Switch PKI (Easy Method) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you are using a switch PKI (see "SSL Concepts for OpenFlow", above), this -method of switch key generation is a little easier than the alternate method -described below, but it is also a little less secure because it requires -copying a sensitive private key from file from the machine hosting the PKI to -the switch. - -1. Run the following on the machine that contains the PKI structure:: - - $ ovs-pki req+sign sc switch - - This command has the following output: - - sc-privkey.pem - the switch private key file. For security, the contents of this file must - remain secret. - - sc-cert.pem - the switch certificate. Its contents are not a secret. - -2. Copy sc-privkey.pem and sc-cert.pem, plus controllerca/cacert.pem, to the - Open vSwitch. - -3. Delete the copies of sc-privkey.pem and sc-cert.pem on the PKI machine and - any other copies that may have been made in transit. It is very important - to make sure that there are no stray copies of sc-privkey.pem, because they - could be used to impersonate the switch. - - .. warning:: - Don't delete controllerca/cacert.pem! It is not security-sensitive and - you will need it to configure additional switches. - -4. Configure Open vSwitch to use the keys and certificates (see "Configuring - SSL Support", below). - -Switch Key Generation with a Switch PKI (More Secure) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -If you are using a switch PKI (see "SSL Concepts for OpenFlow", above), then, -compared to the previous method, the method described here takes a little more -work, but it does not involve copying the private key from one machine to -another, so it may also be a little more secure. - -1. Run the following command on the Open vSwitch itself:: - - $ ovs-pki req sc - - .. note:: - This command does not require a copy of any of the PKI files generated by - "ovs-pki init", and you should not copy them to the switch because some of - them have contents that must remain secret for security. - - The "ovs-pki req" command has the following output: - - sc-privkey.pem - the switch private key file. For security, the contents of this file must - remain secret. There is ordinarily no need to copy this file off the Open - vSwitch. - - sc-req.pem - the switch "certificate request", which is essentially the switch's public - key. Its contents are not a secret. - - a fingerprint - this is output on stdout. - -2. Write the fingerprint down on a slip of paper and copy `sc-req.pem` to the - machine that contains the PKI structure. - -3. On the machine that contains the PKI structure, run:: - - $ ovs-pki sign sc switch - - This command will output a fingerprint to stdout and request that you verify - it. Check that it is the same as the fingerprint that you wrote down on the - slip of paper before you answer "yes". - - ``ovs-pki sign`` creates a file named `sc-cert.pem`, which is the switch - certificate. Its contents are not a secret. - -4. Copy the generated `sc-cert.pem`, plus `controllerca/cacert.pem` from the - PKI structure, to the Open vSwitch, and verify that they were copied - correctly. - - You may delete `sc-cert.pem` from the machine that hosts the PKI - structure now, although it is not important that you do so. - - .. warning:: - Don't delete `controllerca/cacert.pem`! It is not security-sensitive and - you will need it to configure additional switches. - -5. Configure Open vSwitch to use the keys and certificates (see "Configuring - SSL Support", below). - -Configuring SSL Support ------------------------ - -SSL configuration requires three additional configuration files. The first two -of these are unique to each Open vSwitch. If you used the instructions above -to build your PKI, then these files will be named `sc-privkey.pem` and -`sc-cert.pem`, respectively: - -- A private key file, which contains the private half of an RSA or DSA key. - - This file can be generated on the Open vSwitch itself, for the greatest - security, or it can be generated elsewhere and copied to the Open vSwitch. - - The contents of the private key file are secret and must not be exposed. - -- A certificate file, which certifies that the private key is that of a - trustworthy Open vSwitch. - - This file has to be generated on a machine that has the private key for the - switch certification authority, which should not be an Open vSwitch; ideally, - it should be a machine that is not networked at all. - - The certificate file itself is not a secret. - -The third configuration file is typically the same across all the switches in a -given administrative unit. If you used the instructions above to build your -PKI, then this file will be named `cacert.pem`: - -- The root certificate for the controller certificate authority. The Open - vSwitch verifies it that is authorized to connect to an OpenFlow controller - by verifying a signature against this CA certificate. - -Once you have these files, configure ovs-vswitchd to use them using the -``ovs-vsctl set-ssl`` command, e.g.:: - - $ ovs-vsctl set-ssl /etc/openvswitch/sc-privkey.pem \ - /etc/openvswitch/sc-cert.pem /etc/openvswitch/cacert.pem - -Substitute the correct file names, of course, if they differ from the ones used -above. You should use absolute file names (ones that begin with ``/``), -because ovs-vswitchd's current directory is unrelated to the one from which you -run ovs-vsctl. - -If you are using self-signed certificates (see "SSL Concepts for OpenFlow") and -you did not copy controllerca/cacert.pem from the PKI machine to the Open -vSwitch, then add the ``--bootstrap`` option, e.g.:: - - $ ovs-vsctl -- --bootstrap set-ssl /etc/openvswitch/sc-privkey.pem \ - /etc/openvswitch/sc-cert.pem /etc/openvswitch/cacert.pem - -After you have added all of these configuration keys, you may specify ``ssl:`` -connection methods elsewhere in the configuration database. ``tcp:`` connection -methods are still allowed even after SSL has been configured, so for security -you should use only ``ssl:`` connections. - -Reporting Bugs --------------- - -Report problems to bugs@openvswitch.org. diff --git a/Documentation/index.rst b/Documentation/index.rst index 78b7d89b0..192ed7631 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -59,12 +59,8 @@ vSwitch? Start here. :doc:`intro/install/windows` | :doc:`intro/install/xenserver` -- **Tutorials:** :doc:`tutorials/faucet` | - :doc:`tutorials/ovs-advanced` | - :doc:`tutorials/ovn-sandbox` | +- **Tutorials:** :doc:`tutorials/ovn-sandbox` | :doc:`tutorials/ovn-openstack` | - :doc:`tutorials/ovs-conntrack` | - :doc:`tutorials/ipsec` | :doc:`tutorials/ovn-ipsec` | :doc:`tutorials/ovn-rbac` diff --git a/Documentation/tutorials/faucet.rst b/Documentation/tutorials/faucet.rst deleted file mode 100644 index 9696dfd02..000000000 --- a/Documentation/tutorials/faucet.rst +++ /dev/null @@ -1,1436 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -=================== -OVS Faucet Tutorial -=================== - -This tutorial demonstrates how Open vSwitch works with a general-purpose -OpenFlow controller, using the Faucet controller as a simple way to get -started. It was tested with the "master" branch of Open vSwitch and version -1.6.15 of Faucet. It does not use advanced or recently added features in OVS -or Faucet, so other versions of both pieces of software are likely to work -equally well. - -The goal of the tutorial is to demonstrate Open vSwitch and Faucet in an -end-to-end way, that is, to show how it works from the Faucet controller -configuration at the top, through the OpenFlow flow table, to the datapath -processing. Along the way, in addition to helping to understand the -architecture at each level, we discuss performance and troubleshooting issues. -We hope that this demonstration makes it easier for users and potential users -to understand how Open vSwitch works and how to debug and troubleshoot it. - -We provide enough details in the tutorial that you should be able to fully -follow along by following the instructions. - -Setting Up OVS --------------- - -This section explains how to set up Open vSwitch for the purpose of using it -with Faucet for the tutorial. - -You might already have Open vSwitch installed on one or more computers or VMs, -perhaps set up to control a set of VMs or a physical network. This is -admirable, but we will be using Open vSwitch in a different way to set up a -simulation environment called the OVS "sandbox". The sandbox does not use -virtual machines or containers, which makes it more limited, but on the other -hand it is (in this writer's opinion) easier to set up. - -There are two ways to start a sandbox: one that uses the Open vSwitch that is -already installed on a system, and another that uses a copy of Open vSwitch -that has been built but not yet installed. The latter is more often used and -thus better tested, but both should work. The instructions below explain both -approaches: - -1. Get a copy of the Open vSwitch source repository using Git, then ``cd`` into - the new directory:: - - $ git clone https://github.com/openvswitch/ovs.git - $ cd ovs - - The default checkout is the master branch. You can check out a tag - (such as v2.8.0) or a branch (such as origin/branch-2.8), if you - prefer. - -2. If you do not already have an installed copy of Open vSwitch on your system, - or if you do not want to use it for the sandbox (the sandbox will not - disturb the functionality of any existing switches), then proceed to step 3. - If you do have an installed copy and you want to use it for the sandbox, try - to start the sandbox by running:: - - $ tutorial/ovs-sandbox - - If it is successful, you will find yourself in a subshell environment, which - is the sandbox (you can exit with ``exit`` or Control+D). If so, you're - finished and do not need to complete the rest of the steps. If it fails, - you can proceed to step 3 to build Open vSwitch anyway. - -3. Before you build, you might want to check that your system meets the build - requirements. Read :doc:`/intro/install/general` to find out. For this - tutorial, there is no need to compile the Linux kernel module, or to use any - of the optional libraries such as OpenSSL, DPDK, or libcap-ng. - -4. Configure and build Open vSwitch:: - - $ ./boot.sh - $ ./configure - $ make -j4 - -5. Try out the sandbox by running:: - - $ make sandbox - - You can exit the sandbox with ``exit`` or Control+D. - -Setting up Faucet ------------------ - -This section explains how to get a copy of Faucet and set it up -appropriately for the tutorial. There are many other ways to install -Faucet, but this simple approach worked well for me. It has the -advantage that it does not require modifying any system-level files or -directories on your machine. It does, on the other hand, require -Docker, so make sure you have it installed and working. - -It will be a little easier to go through the rest of the tutorial if -you run these instructions in a separate terminal from the one that -you're using for Open vSwitch, because it's often necessary to switch -between one and the other. - -1. Get a copy of the Faucet source repository using Git, then ``cd`` - into the new directory:: - - $ git clone https://github.com/faucetsdn/faucet.git - $ cd faucet - - At this point I checked out the latest tag:: - - $ latest_tag=$(git describe --tags $(git rev-list --tags --max-count=1)) - $ git checkout $latest_tag - -2. Build a docker container image:: - - $ docker build -t faucet/faucet . - - This will take a few minutes. - -3. Create an installation directory under the ``faucet`` directory for - the docker image to use:: - - $ mkdir inst - - The Faucet configuration will go in ``inst/faucet.yaml`` and its - main log will appear in ``inst/faucet.log``. (The official Faucet - installation instructions call to put these in ``/etc/ryu/faucet`` - and ``/var/log/ryu/faucet``, respectively, but we avoid modifying - these system directories.) - -4. Create a container and start Faucet:: - - $ docker run -d --name faucet --restart=always -v $(pwd)/inst/:/etc/faucet/ -v $(pwd)/inst/:/var/log/faucet/ -p 6653:6653 -p 9302:9302 faucet/faucet - -5. Look in ``inst/faucet.log`` to verify that Faucet started. It will - probably start with an exception and traceback because we have not - yet created ``inst/faucet.yaml``. - -6. Later on, to make a new or updated Faucet configuration take - effect quickly, you can run:: - - $ docker exec faucet pkill -HUP -f faucet.faucet - - Another way is to stop and start the Faucet container:: - - $ docker restart faucet - - You can also stop and delete the container; after this, to start it - again, you need to rerun the ``docker run`` command:: - - $ docker stop faucet - $ docker rm faucet - -Overview --------- - -Now that Open vSwitch and Faucet are ready, here's an overview of what -we're going to do for the remainder of the tutorial: - -1. Switching: Set up an L2 network with Faucet. - -2. Routing: Route between multiple L3 networks with Faucet. - -3. ACLs: Add and modify access control rules. - -At each step, we will take a look at how the features in question work -from Faucet at the top to the data plane layer at the bottom. From -the highest to lowest level, these layers and the software components -that connect them are: - -Faucet. - As the top level in the system, this is the authoritative source of the - network configuration. - - Faucet connects to a variety of monitoring and performance tools, - but we won't use them in this tutorial. Our main insights into the - system will be through ``faucet.yaml`` for configuration and - ``faucet.log`` to observe state, such as MAC learning and ARP - resolution, and to tell when we've screwed up configuration syntax - or semantics. - -The OpenFlow subsystem in Open vSwitch. - OpenFlow is the protocol, standardized by the Open Networking Foundation, - that controllers like Faucet use to control how Open vSwitch and other - switches treat packets in the network. - - We will use ``ovs-ofctl``, a utility that comes with Open vSwitch, - to observe and occasionally modify Open vSwitch's OpenFlow behavior. - We will also use ``ovs-appctl``, a utility for communicating with - ``ovs-vswitchd`` and other Open vSwitch daemons, to ask "what-if?" - type questions. - - In addition, the OVS sandbox by default raises the Open vSwitch - logging level for OpenFlow high enough that we can learn a great - deal about OpenFlow behavior simply by reading its log file. - -Open vSwitch datapath. - This is essentially a cache designed to accelerate packet processing. Open - vSwitch includes a few different datapaths, such as one based on the Linux - kernel and a userspace-only datapath (sometimes called the "DPDK" datapath). - The OVS sandbox uses the latter, but the principles behind it apply equally - well to other datapaths. - -At each step, we discuss how the design of each layer influences -performance. We demonstrate how Open vSwitch features can be used to -debug, troubleshoot, and understand the system as a whole. - -Switching ---------- - -Layer-2 (L2) switching is the basis of modern networking. It's also -very simple and a good place to start, so let's set up a switch with -some VLANs in Faucet and see how it works at each layer. Begin by -putting the following into ``inst/faucet.yaml``:: - - dps: - switch-1: - dp_id: 0x1 - timeout: 3600 - arp_neighbor_timeout: 3600 - interfaces: - 1: - native_vlan: 100 - 2: - native_vlan: 100 - 3: - native_vlan: 100 - 4: - native_vlan: 200 - 5: - native_vlan: 200 - vlans: - 100: - 200: - -This configuration file defines a single switch ("datapath" or "dp") -named ``switch-1``. The switch has five ports, numbered 1 through 5. -Ports 1, 2, and 3 are in VLAN 100, and ports 4 and 5 are in VLAN 2. -Faucet can identify the switch from its datapath ID, which is defined -to be 0x1. - -.. note:: - - This also sets high MAC learning and ARP timeouts. The defaults are - 5 minutes and about 8 minutes, which are fine in production but - sometimes too fast for manual experimentation. (Don't use a timeout - bigger than about 65000 seconds because it will crash Faucet.) - -Now restart Faucet so that the configuration takes effect, e.g.:: - - $ docker restart faucet - -Assuming that the configuration update is successful, you should now -see a new line at the end of ``inst/faucet.log``:: - - Jan 06 15:14:35 faucet INFO Add new datapath DPID 1 (0x1) - -Faucet is now waiting for a switch with datapath ID 0x1 to connect to -it over OpenFlow, so our next step is to create a switch with OVS and -make it connect to Faucet. To do that, switch to the terminal where -you checked out OVS and start a sandbox with ``make sandbox`` or -``tutorial/ovs-sandbox`` (as explained earlier under `Setting Up -OVS`_). You should see something like this toward the end of the -output:: - - ---------------------------------------------------------------------- - You are running in a dummy Open vSwitch environment. You can use - ovs-vsctl, ovs-ofctl, ovs-appctl, and other tools to work with the - dummy switch. - - Log files, pidfiles, and the configuration database are in the - "sandbox" subdirectory. - - Exit the shell to kill the running daemons. - blp@sigabrt:~/nicira/ovs/tutorial(0)$ - -Inside the sandbox, create a switch ("bridge") named ``br0``, set its -datapath ID to 0x1, add simulated ports to it named ``p1`` through -``p5``, and tell it to connect to the Faucet controller. To make it -easier to understand, we request for port ``p1`` to be assigned -OpenFlow port 1, ``p2`` port 2, and so on. As a final touch, -configure the controller to be "out-of-band" (this is mainly to avoid -some annoying messages in the ``ovs-vswitchd`` logs; for more -information, run ``man ovs-vswitchd.conf.db`` and search for -``connection_mode``):: - - $ ovs-vsctl add-br br0 \ - -- set bridge br0 other-config:datapath-id=0000000000000001 \ - -- add-port br0 p1 -- set interface p1 ofport_request=1 \ - -- add-port br0 p2 -- set interface p2 ofport_request=2 \ - -- add-port br0 p3 -- set interface p3 ofport_request=3 \ - -- add-port br0 p4 -- set interface p4 ofport_request=4 \ - -- add-port br0 p5 -- set interface p5 ofport_request=5 \ - -- set-controller br0 tcp:127.0.0.1:6653 \ - -- set controller br0 connection-mode=out-of-band - -.. note:: - - You don't have to run all of these as a single ``ovs-vsctl`` - invocation. It is a little more efficient, though, and since it - updates the OVS configuration in a single database transaction it - means that, for example, there is never a time when the controller - is set but it has not yet been configured as out-of-band. - -Now, if you look at ``inst/faucet.log`` again, you should see that -Faucet recognized and configured the new switch and its ports:: - - Jan 06 15:17:10 faucet INFO DPID 1 (0x1) connected - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Cold start configuring DP - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Configuring VLAN 100 vid:100 ports:Port 1,Port 2,Port 3 - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Configuring VLAN 200 vid:200 ports:Port 4,Port 5 - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Port 1 up, configuring - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Port 2 up, configuring - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Port 3 up, configuring - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Port 4 up, configuring - Jan 06 15:17:10 faucet.valve INFO DPID 1 (0x1) Port 5 up, configuring - -Over on the Open vSwitch side, you can see a lot of related activity -if you take a look in ``sandbox/ovs-vswitchd.log``. For example, here -is the basic OpenFlow session setup and Faucet's probe of the switch's -ports and capabilities:: - - rconn|INFO|br0<->tcp:127.0.0.1:6653: connecting... - vconn|DBG|tcp:127.0.0.1:6653: sent (Success): OFPT_HELLO (OF1.4) (xid=0x1): - version bitmap: 0x01, 0x02, 0x03, 0x04, 0x05 - vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_HELLO (OF1.3) (xid=0x2f24810a): - version bitmap: 0x01, 0x02, 0x03, 0x04 - vconn|DBG|tcp:127.0.0.1:6653: negotiated OpenFlow version 0x04 (we support version 0x05 and earlier, peer supports version 0x04 and earlier) - rconn|INFO|br0<->tcp:127.0.0.1:6653: connected - vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_ECHO_REQUEST (OF1.3) (xid=0x2f24810b): 0 bytes of payload - vconn|DBG|tcp:127.0.0.1:6653: sent (Success): OFPT_ECHO_REPLY (OF1.3) (xid=0x2f24810b): 0 bytes of payload - vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_FEATURES_REQUEST (OF1.3) (xid=0x2f24810c): - vconn|DBG|tcp:127.0.0.1:6653: sent (Success): OFPT_FEATURES_REPLY (OF1.3) (xid=0x2f24810c): dpid:0000000000000001 - n_tables:254, n_buffers:0 - capabilities: FLOW_STATS TABLE_STATS PORT_STATS GROUP_STATS QUEUE_STATS - vconn|DBG|tcp:127.0.0.1:6653: received: OFPST_PORT_DESC request (OF1.3) (xid=0x2f24810d): port=ANY - vconn|DBG|tcp:127.0.0.1:6653: sent (Success): OFPST_PORT_DESC reply (OF1.3) (xid=0x2f24810d): - 1(p1): addr:aa:55:aa:55:00:14 - config: PORT_DOWN - state: LINK_DOWN - speed: 0 Mbps now, 0 Mbps max - 2(p2): addr:aa:55:aa:55:00:15 - config: PORT_DOWN - state: LINK_DOWN - speed: 0 Mbps now, 0 Mbps max - 3(p3): addr:aa:55:aa:55:00:16 - config: PORT_DOWN - state: LINK_DOWN - speed: 0 Mbps now, 0 Mbps max - 4(p4): addr:aa:55:aa:55:00:17 - config: PORT_DOWN - state: LINK_DOWN - speed: 0 Mbps now, 0 Mbps max - 5(p5): addr:aa:55:aa:55:00:18 - config: PORT_DOWN - state: LINK_DOWN - speed: 0 Mbps now, 0 Mbps max - LOCAL(br0): addr:c6:64:ff:59:48:41 - config: PORT_DOWN - state: LINK_DOWN - speed: 0 Mbps now, 0 Mbps max - -After that, you can see Faucet delete all existing flows and then -start adding new ones:: - - vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_FLOW_MOD (OF1.3) (xid=0x2f24810e): DEL table:255 priority=0 actions=drop - vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_BARRIER_REQUEST (OF1.3) (xid=0x2f24810f): - vconn|DBG|tcp:127.0.0.1:6653: sent (Success): OFPT_BARRIER_REPLY (OF1.3) (xid=0x2f24810f): - vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_FLOW_MOD (OF1.3) (xid=0x2f248110): ADD priority=0 cookie:0x5adc15c0 out_port:0 actions=drop - vconn|DBG|tcp:127.0.0.1:6653: received: OFPT_FLOW_MOD (OF1.3) (xid=0x2f248111): ADD table:1 priority=0 cookie:0x5adc15c0 out_port:0 actions=drop - ... - -OpenFlow Layer -~~~~~~~~~~~~~~ - -Let's take a look at the OpenFlow tables that Faucet set up. Before -we do that, it's helpful to take a look at ``docs/architecture.rst`` -in the Faucet documentation to learn how Faucet structures its flow -tables. In summary, this document says: - -Table 0 - Port-based ACLs - -Table 1 - Ingress VLAN processing - -Table 2 - VLAN-based ACLs - -Table 3 - Ingress L2 processing, MAC learning - -Table 4 - L3 forwarding for IPv4 - -Table 5 - L3 forwarding for IPv6 - -Table 6 - Virtual IP processing, e.g. for router IP addresses implemented by Faucet - -Table 7 - Egress L2 processing - -Table 8 - Flooding - -With that in mind, let's dump the flow tables. The simplest way is to -just run plain ``ovs-ofctl dump-flows``:: - - $ ovs-ofctl dump-flows br0 - -If you run that bare command, it produces a lot of extra junk that -makes the output harder to read, like statistics and "cookie" values -that are all the same. In addition, for historical reasons -``ovs-ofctl`` always defaults to using OpenFlow 1.0 even though Faucet -and most modern controllers use OpenFlow 1.3, so it's best to force it -to use OpenFlow 1.3. We could throw in a lot of options to fix these, -but we'll want to do this more than once, so let's start by defining a -shell function for ourselves:: - - $ dump-flows () { - ovs-ofctl -OOpenFlow13 --names --no-stat dump-flows "$@" \ - | sed 's/cookie=0x5adc15c0, //' - } - -Let's also define ``save-flows`` and ``diff-flows`` functions for -later use:: - - $ save-flows () { - ovs-ofctl -OOpenFlow13 --no-names --sort dump-flows "$@" - } - $ diff-flows () { - ovs-ofctl -OOpenFlow13 diff-flows "$@" | sed 's/cookie=0x5adc15c0 //' - } - -Now let's take a look at the flows we've got and what they mean, like -this:: - - $ dump-flows br0 - -First, table 0 has a flow that just jumps to table 1 for each -configured port, and drops other unrecognized packets. Presumably it -will do more if we configured port-based ACLs:: - - priority=9099,in_port=p1 actions=goto_table:1 - priority=9099,in_port=p2 actions=goto_table:1 - priority=9099,in_port=p3 actions=goto_table:1 - priority=9099,in_port=p4 actions=goto_table:1 - priority=9099,in_port=p5 actions=goto_table:1 - priority=0 actions=drop - -Table 1, for ingress VLAN processing, has a bunch of flows that drop -inappropriate packets, such as LLDP and STP:: - - table=1, priority=9099,dl_dst=01:80:c2:00:00:00 actions=drop - table=1, priority=9099,dl_dst=01:00:0c:cc:cc:cd actions=drop - table=1, priority=9099,dl_type=0x88cc actions=drop - -Table 1 also has some more interesting flows that recognize packets -without a VLAN header on each of our ports -(``vlan_tci=0x0000/0x1fff``), push on the VLAN configured for the -port, and proceed to table 3. Presumably these skip table 2 because -we did not configure any VLAN-based ACLs. There is also a fallback -flow to drop other packets, which in practice means that if any -received packet already has a VLAN header then it will be dropped:: - - table=1, priority=9000,in_port=p1,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4196->vlan_vid,goto_table:3 - table=1, priority=9000,in_port=p2,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4196->vlan_vid,goto_table:3 - table=1, priority=9000,in_port=p3,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4196->vlan_vid,goto_table:3 - table=1, priority=9000,in_port=p4,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4296->vlan_vid,goto_table:3 - table=1, priority=9000,in_port=p5,vlan_tci=0x0000/0x1fff actions=push_vlan:0x8100,set_field:4296->vlan_vid,goto_table:3 - table=1, priority=0 actions=drop - -.. note:: - - The syntax ``set_field:4196->vlan_vid`` is curious and somewhat - misleading. OpenFlow 1.3 defines the ``vlan_vid`` field as a 13-bit - field where bit 12 is set to 1 if the VLAN header is present. Thus, - since 4196 is 0x1064, this action sets VLAN value 0x64, which in - decimal is 100. - -Table 2 isn't used because there are no VLAN-based ACLs. It just has -a drop flow:: - - table=2, priority=0 actions=drop - -Table 3 is used for MAC learning but the controller hasn't learned any -MAC yet. It also drops some inappropriate packets such as those that claim -to be from a broadcast source address (why not from all multicast source -addresses, though?). We'll come back here later:: - - table=3, priority=9099,dl_src=ff:ff:ff:ff:ff:ff actions=drop - table=3, priority=9001,dl_src=0e:00:00:00:00:01 actions=drop - table=3, priority=0 actions=drop - table=3, priority=9000 actions=CONTROLLER:96,goto_table:7 - -Tables 4, 5, and 6 aren't used because we haven't configured any -routing:: - - table=4, priority=0 actions=drop - table=5, priority=0 actions=drop - table=6, priority=0 actions=drop - -Table 7 is used to direct packets to learned MACs but Faucet hasn't -learned any MACs yet, so it just sends all the packets along to table -8:: - - table=7, priority=0 actions=drop - table=7, priority=9000 actions=goto_table:8 - -Table 8 implements flooding, broadcast, and multicast. The flows for -broadcast and flood are easy to understand: if the packet came in on a -given port and needs to be flooded or broadcast, output it to all the -other ports in the same VLAN:: - - table=8, priority=9008,in_port=p1,dl_vlan=100,dl_dst=ff:ff:ff:ff:ff:ff actions=pop_vlan,output:p2,output:p3 - table=8, priority=9008,in_port=p2,dl_vlan=100,dl_dst=ff:ff:ff:ff:ff:ff actions=pop_vlan,output:p1,output:p3 - table=8, priority=9008,in_port=p3,dl_vlan=100,dl_dst=ff:ff:ff:ff:ff:ff actions=pop_vlan,output:p1,output:p2 - table=8, priority=9008,in_port=p4,dl_vlan=200,dl_dst=ff:ff:ff:ff:ff:ff actions=pop_vlan,output:p5 - table=8, priority=9008,in_port=p5,dl_vlan=200,dl_dst=ff:ff:ff:ff:ff:ff actions=pop_vlan,output:p4 - table=8, priority=9000,in_port=p1,dl_vlan=100 actions=pop_vlan,output:p2,output:p3 - table=8, priority=9000,in_port=p2,dl_vlan=100 actions=pop_vlan,output:p1,output:p3 - table=8, priority=9000,in_port=p3,dl_vlan=100 actions=pop_vlan,output:p1,output:p2 - table=8, priority=9000,in_port=p4,dl_vlan=200 actions=pop_vlan,output:p5 - table=8, priority=9000,in_port=p5,dl_vlan=200 actions=pop_vlan,output:p4 - -.. note:: - - These flows could apparently be simpler because OpenFlow says that - ``output:`` is ignored if ```` is the input port. That - means that the first three flows above could apparently be collapsed - into just:: - - table=8, priority=9008,dl_vlan=100,dl_dst=ff:ff:ff:ff:ff:ff actions=pop_vlan,output:p1,output:p2,output:p3 - - There might be some reason why this won't work or isn't practical, - but that isn't obvious from looking at the flow table. - -There are also some flows for handling some standard forms of -multicast, and a fallback drop flow:: - - table=8, priority=9006,in_port=p1,dl_vlan=100,dl_dst=33:33:00:00:00:00/ff:ff:00:00:00:00 actions=pop_vlan,output:p2,output:p3 - table=8, priority=9006,in_port=p2,dl_vlan=100,dl_dst=33:33:00:00:00:00/ff:ff:00:00:00:00 actions=pop_vlan,output:p1,output:p3 - table=8, priority=9006,in_port=p3,dl_vlan=100,dl_dst=33:33:00:00:00:00/ff:ff:00:00:00:00 actions=pop_vlan,output:p1,output:p2 - table=8, priority=9006,in_port=p4,dl_vlan=200,dl_dst=33:33:00:00:00:00/ff:ff:00:00:00:00 actions=pop_vlan,output:p5 - table=8, priority=9006,in_port=p5,dl_vlan=200,dl_dst=33:33:00:00:00:00/ff:ff:00:00:00:00 actions=pop_vlan,output:p4 - table=8, priority=9002,in_port=p1,dl_vlan=100,dl_dst=01:80:c2:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p2,output:p3 - table=8, priority=9002,in_port=p2,dl_vlan=100,dl_dst=01:80:c2:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p1,output:p3 - table=8, priority=9002,in_port=p3,dl_vlan=100,dl_dst=01:80:c2:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p1,output:p2 - table=8, priority=9004,in_port=p1,dl_vlan=100,dl_dst=01:00:5e:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p2,output:p3 - table=8, priority=9004,in_port=p2,dl_vlan=100,dl_dst=01:00:5e:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p1,output:p3 - table=8, priority=9004,in_port=p3,dl_vlan=100,dl_dst=01:00:5e:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p1,output:p2 - table=8, priority=9002,in_port=p4,dl_vlan=200,dl_dst=01:80:c2:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p5 - table=8, priority=9002,in_port=p5,dl_vlan=200,dl_dst=01:80:c2:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p4 - table=8, priority=9004,in_port=p4,dl_vlan=200,dl_dst=01:00:5e:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p5 - table=8, priority=9004,in_port=p5,dl_vlan=200,dl_dst=01:00:5e:00:00:00/ff:ff:ff:00:00:00 actions=pop_vlan,output:p4 - table=8, priority=0 actions=drop - -Tracing -~~~~~~~ - -Let's go a level deeper. So far, everything we've done has been -fairly general. We can also look at something more specific: the path -that a particular packet would take through Open vSwitch. We can use -OVN ``ofproto/trace`` command to play "what-if?" games. This command -is one that we send directly to ``ovs-vswitchd``, using the -``ovs-appctl`` utility. - -.. note:: - - ``ovs-appctl`` is actually a very simple-minded JSON-RPC client, so you could - also use some other utility that speaks JSON-RPC, or access it from a program - as an API. - -The ``ovs-vswitchd``\(8) manpage has a lot of detail on how to use -``ofproto/trace``, but let's just start by building up from a simple -example. You can start with a command that just specifies the -datapath (e.g. ``br0``), an input port, and nothing else; unspecified -fields default to all-zeros. Let's look at the full output for this -trivial example:: - - $ ovs-appctl ofproto/trace br0 in_port=p1 - Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 - - bridge("br0") - ------------- - 0. in_port=1, priority 9099, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=1,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4196->vlan_vid - goto_table:3 - 3. priority 9000, cookie 0x5adc15c0 - CONTROLLER:96 - goto_table:7 - 7. priority 9000, cookie 0x5adc15c0 - goto_table:8 - 8. in_port=1,dl_vlan=100, priority 9000, cookie 0x5adc15c0 - pop_vlan - output:2 - output:3 - - Final flow: unchanged - Megaflow: recirc_id=0,eth,in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 - Datapath actions: push_vlan(vid=100,pcp=0),userspace(pid=0,controller(reason=1,flags=1,recirc_id=1,rule_cookie=0x5adc15c0,controller_id=0,max_len=96)),pop_vlan,2,3 - -The first line of output, beginning with ``Flow:``, just repeats our -request in a more verbose form, including the L2 fields that were -zeroed. - -Each of the numbered items under ``bridge("br0")`` shows what would -happen to our hypothetical packet in the table with the given number. -For example, we see in table 1 that the packet matches a flow that -push on a VLAN header, set the VLAN ID to 100, and goes on to further -processing in table 3. In table 3, the packet gets sent to the -controller to allow MAC learning to take place, and then table 8 -floods the packet to the other ports in the same VLAN. - -Summary information follows the numbered tables. The packet hasn't -been changed (overall, even though a VLAN was pushed and then popped -back off) since ingress, hence ``Final flow: unchanged``. We'll look -at the ``Megaflow`` information later. The ``Datapath actions`` -summarize what would actually happen to such a packet. - -Triggering MAC Learning -~~~~~~~~~~~~~~~~~~~~~~~ - -We just saw how a packet gets sent to the controller to trigger MAC -learning. Let's actually send the packet and see what happens. But -before we do that, let's save a copy of the current flow tables for -later comparison:: - - $ save-flows br0 > flows1 - -Now use ``ofproto/trace``, as before, with a few new twists: we -specify the source and destination Ethernet addresses and append the -``-generate`` option so that side effects like sending a packet to the -controller actually happen:: - - $ ovs-appctl ofproto/trace br0 in_port=p1,dl_src=00:11:11:00:00:00,dl_dst=00:22:22:00:00:00 -generate - -The output is almost identical to that before, so it is not repeated -here. But, take a look at ``inst/faucet.log`` now. It should now -include a line at the end that says that it learned about our MAC -00:11:11:00:00:00, like this:: - - Jan 06 15:56:02 faucet.valve INFO DPID 1 (0x1) L2 learned 00:11:11:00:00:00 (L2 type 0x0000, L3 src None) on Port 1 on VLAN 100 (1 hosts total - -Now compare the flow tables that we saved to the current ones:: - - diff-flows flows1 br0 - -The result should look like this, showing new flows for the learned -MACs:: - - +table=3 priority=9098,in_port=1,dl_vlan=100,dl_src=00:11:11:00:00:00 hard_timeout=3601 actions=goto_table:7 - +table=7 priority=9099,dl_vlan=100,dl_dst=00:11:11:00:00:00 idle_timeout=3601 actions=pop_vlan,output:1 - -To demonstrate the usefulness of the learned MAC, try tracing (with -side effects) a packet arriving on ``p2`` (or ``p3``) and destined to -the address learned on ``p1``, like this:: - - $ ovs-appctl ofproto/trace br0 in_port=p2,dl_src=00:22:22:00:00:00,dl_dst=00:11:11:00:00:00 -generate - -The first time you run this command, you will notice that it sends the -packet to the controller, to learn ``p2``'s 00:22:22:00:00:00 source -address:: - - bridge("br0") - ------------- - 0. in_port=2, priority 9099, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=2,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4196->vlan_vid - goto_table:3 - 3. priority 9000, cookie 0x5adc15c0 - CONTROLLER:96 - goto_table:7 - 7. dl_vlan=100,dl_dst=00:11:11:00:00:00, priority 9099, cookie 0x5adc15c0 - pop_vlan - output:1 - -If you check ``inst/faucet.log``, you can see that ``p2``'s MAC has -been learned too:: - - Jan 06 15:58:09 faucet.valve INFO DPID 1 (0x1) L2 learned 00:22:22:00:00:00 (L2 type 0x0000, L3 src None) on Port 2 on VLAN 100 (2 hosts total) - -Similarly for ``diff-flows``:: - - $ diff-flows flows1 br0 - +table=3 priority=9098,in_port=1,dl_vlan=100,dl_src=00:11:11:00:00:00 hard_timeout=3601 actions=goto_table:7 - +table=3 priority=9098,in_port=2,dl_vlan=100,dl_src=00:22:22:00:00:00 hard_timeout=3604 actions=goto_table:7 - +table=7 priority=9099,dl_vlan=100,dl_dst=00:11:11:00:00:00 idle_timeout=3601 actions=pop_vlan,output:1 - +table=7 priority=9099,dl_vlan=100,dl_dst=00:22:22:00:00:00 idle_timeout=3604 actions=pop_vlan,output:2 - -Then, if you re-run either of the ``ofproto/trace`` commands (with or -without ``-generate``), you can see that the packets go back and forth -without any further MAC learning, e.g.:: - - $ ovs-appctl ofproto/trace br0 in_port=p2,dl_src=00:22:22:00:00:00,dl_dst=00:11:11:00:00:00 -generate - Flow: in_port=2,vlan_tci=0x0000,dl_src=00:22:22:00:00:00,dl_dst=00:11:11:00:00:00,dl_type=0x0000 - - bridge("br0") - ------------- - 0. in_port=2, priority 9099, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=2,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4196->vlan_vid - goto_table:3 - 3. in_port=2,dl_vlan=100,dl_src=00:22:22:00:00:00, priority 9098, cookie 0x5adc15c0 - goto_table:7 - 7. dl_vlan=100,dl_dst=00:11:11:00:00:00, priority 9099, cookie 0x5adc15c0 - pop_vlan - output:1 - - Final flow: unchanged - Megaflow: recirc_id=0,eth,in_port=2,vlan_tci=0x0000/0x1fff,dl_src=00:22:22:00:00:00,dl_dst=00:11:11:00:00:00,dl_type=0x0000 - Datapath actions: 1 - -Performance -~~~~~~~~~~~ - -Open vSwitch has a concept of a "fast path" and a "slow path"; ideally -all packets stay in the fast path. This distinction between slow path -and fast path is the key to making sure that Open vSwitch performs as -fast as possible. - -Some factors can force a flow or a packet to take the slow path. As one -example, all CFM, BFD, LACP, STP, and LLDP processing takes place in the -slow path, in the cases where Open vSwitch processes these protocols -itself instead of delegating to controller-written flows. As a second -example, any flow that modifies ARP fields is processed in the slow -path. These are corner cases that are unlikely to cause performance -problems in practice because these protocols send packets at a -relatively slow rate, and users and controller authors do not normally -need to be concerned about them. - -To understand what cases users and controller authors should consider, -we need to talk about how Open vSwitch optimizes for performance. The -Open vSwitch code is divided into two major components which, as -already mentioned, are called the "slow path" and "fast path" (aka -"datapath"). The slow path is embedded in the ``ovs-vswitchd`` -userspace program. It is the part of the Open vSwitch packet -processing logic that understands OpenFlow. Its job is to take a -packet and run it through the OpenFlow tables to determine what should -happen to it. It outputs a list of actions in a form similar to -OpenFlow actions but simpler, called "ODP actions" or "datapath -actions". It then passes the ODP actions to the datapath, which -applies them to the packet. - -.. note:: - - Open vSwitch contains a single slow path and multiple fast paths. - The difference between using Open vSwitch with the Linux kernel - versus with DPDK is the datapath. - -If every packet passed through the slow path and the fast path in this -way, performance would be terrible. The key to getting high -performance from this architecture is caching. Open vSwitch includes -a multi-level cache. It works like this: - -1. A packet initially arrives at the datapath. Some datapaths (such - as DPDK and the in-tree version of the OVS kernel module) have a - first-level cache called the "microflow cache". The microflow - cache is the key to performance for relatively long-lived, high - packet rate flows. If the datapath has a microflow cache, then it - consults it and, if there is a cache hit, the datapath executes the - associated actions. Otherwise, it proceeds to step 2. - -2. The datapath consults its second-level cache, called the "megaflow - cache". The megaflow cache is the key to performance for shorter - or low packet rate flows. If there is a megaflow cache hit, the - datapath executes the associated actions. Otherwise, it proceeds - to step 3. - -3. The datapath passes the packet to the slow path, which runs it - through the OpenFlow table to yield ODP actions, a process that is - often called "flow translation". It then passes the packet back to - the datapath to execute the actions and to, if possible, install a - megaflow cache entry so that subsequent similar packets can be - handled directly by the fast path. (We already described above - most of the cases where a cache entry cannot be installed.) - -The megaflow cache is the key cache to consider for performance -tuning. Open vSwitch provides tools for understanding and optimizing -its behavior. The ``ofproto/trace`` command that we have already been -using is the most common tool for this use. Let's take another look -at the most recent ``ofproto/trace`` output:: - - $ ovs-appctl ofproto/trace br0 in_port=p2,dl_src=00:22:22:00:00:00,dl_dst=00:11:11:00:00:00 -generate - Flow: in_port=2,vlan_tci=0x0000,dl_src=00:22:22:00:00:00,dl_dst=00:11:11:00:00:00,dl_type=0x0000 - - bridge("br0") - ------------- - 0. in_port=2, priority 9099, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=2,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4196->vlan_vid - goto_table:3 - 3. in_port=2,dl_vlan=100,dl_src=00:22:22:00:00:00, priority 9098, cookie 0x5adc15c0 - goto_table:7 - 7. dl_vlan=100,dl_dst=00:11:11:00:00:00, priority 9099, cookie 0x5adc15c0 - pop_vlan - output:1 - - Final flow: unchanged - Megaflow: recirc_id=0,eth,in_port=2,vlan_tci=0x0000/0x1fff,dl_src=00:22:22:00:00:00,dl_dst=00:11:11:00:00:00,dl_type=0x0000 - Datapath actions: 1 - -This time, it's the last line that we're interested in. This line -shows the entry that Open vSwitch would insert into the megaflow cache -given the particular packet with the current flow tables. The -megaflow entry includes: - -* ``recirc_id``. This is an implementation detail that users don't - normally need to understand. - -* ``eth``. This just indicates that the cache entry matches only - Ethernet packets; Open vSwitch also supports other types of packets, - such as IP packets not encapsulated in Ethernet. - -* All of the fields matched by any of the flows that the packet - visited: - - ``in_port`` - In tables 0, 1, and 3. - - ``vlan_tci`` - In tables 1, 3, and 7 (``vlan_tci`` includes the VLAN ID and PCP - fields and``dl_vlan`` is just the VLAN ID). - - ``dl_src`` - In table 3 - - ``dl_dst`` - In table 7. - -* All of the fields matched by flows that had to be ruled out to - ensure that the ones that actually matched were the highest priority - matching rules. - -The last one is important. Notice how the megaflow matches on -``dl_type=0x0000``, even though none of the tables matched on -``dl_type`` (the Ethernet type). One reason is because of this flow -in OpenFlow table 1 (which shows up in ``dump-flows`` output):: - - table=1, priority=9099,dl_type=0x88cc actions=drop - -This flow has higher priority than the flow in table 1 that actually -matched. This means that, to put it in the megaflow cache, -``ovs-vswitchd`` has to add a match on ``dl_type`` to ensure that the -cache entry doesn't match LLDP packets (with Ethertype 0x88cc). - -.. note:: - - In fact, in some cases ``ovs-vswitchd`` matches on fields that - aren't strictly required according to this description. ``dl_type`` - is actually one of those, so deleting the LLDP flow probably would - not have any effect on the megaflow. But the principle here is - sound. - -So why does any of this matter? It's because, the more specific a -megaflow is, that is, the more fields or bits within fields that a -megaflow matches, the less valuable it is from a caching viewpoint. A -very specific megaflow might match on L2 and L3 addresses and L4 port -numbers. When that happens, only packets in one (half-)connection -match the megaflow. If that connection has only a few packets, as -many connections do, then the high cost of the slow path translation -is amortized over only a few packets, so the average cost of -forwarding those packets is high. On the other hand, if a megaflow -only matches a relatively small number of L2 and L3 packets, then the -cache entry can potentially be used by many individual connections, -and the average cost is low. - -For more information on how Open vSwitch constructs megaflows, -including about ways that it can make megaflow entries less specific -than one would infer from the discussion here, please refer to the -2015 NSDI paper, "The Design and Implementation of Open vSwitch", -which focuses on this algorithm. - -Routing -------- - -We've looked at how Faucet implements switching in OpenFlow, and how -Open vSwitch implements OpenFlow through its datapath architecture. -Now let's start over, adding L3 routing into the picture. - -It's remarkably easy to enable routing. We just change our ``vlans`` -section in ``inst/faucet.yaml`` to specify a router IP address for -each VLAN and define a router between them. The ``dps`` section is unchanged:: - - dps: - switch-1: - dp_id: 0x1 - timeout: 3600 - arp_neighbor_timeout: 3600 - interfaces: - 1: - native_vlan: 100 - 2: - native_vlan: 100 - 3: - native_vlan: 100 - 4: - native_vlan: 200 - 5: - native_vlan: 200 - vlans: - 100: - faucet_vips: ["10.100.0.254/24"] - 200: - faucet_vips: ["10.200.0.254/24"] - routers: - router-1: - vlans: [100, 200] - -Then we restart Faucet:: - - $ docker restart faucet - -.. note:: - - One should be able to tell Faucet to re-read its configuration file - without restarting it. I sometimes saw anomalous behavior when I - did this, although I didn't characterize it well enough to make a - quality bug report. I found restarting the container to be - reliable. - -OpenFlow Layer -~~~~~~~~~~~~~~ - -Back in the OVS sandbox, let's see how the flow table has changed, with:: - - $ diff-flows flows1 br0 - -First, table 3 has new flows to direct ARP packets to table 6 (the -virtual IP processing table), presumably to handle ARP for the router -IPs. New flows also send IP packets destined to a particular Ethernet -address to table 4 (the L3 forwarding table); we can make the educated -guess that the Ethernet address is the one used by the Faucet router:: - - +table=3 priority=9131,arp,dl_vlan=100 actions=goto_table:6 - +table=3 priority=9131,arp,dl_vlan=200 actions=goto_table:6 - +table=3 priority=9099,ip,dl_vlan=100,dl_dst=0e:00:00:00:00:01 actions=goto_table:4 - +table=3 priority=9099,ip,dl_vlan=200,dl_dst=0e:00:00:00:00:01 actions=goto_table:4 - -The new flows in table 4 appear to be verifying that the packets are -indeed addressed to a network or IP address that Faucet knows how to -route:: - - +table=4 priority=9131,ip,dl_vlan=100,nw_dst=10.100.0.254 actions=goto_table:6 - +table=4 priority=9131,ip,dl_vlan=200,nw_dst=10.200.0.254 actions=goto_table:6 - +table=4 priority=9123,ip,dl_vlan=100,nw_dst=10.100.0.0/24 actions=goto_table:6 - +table=4 priority=9123,ip,dl_vlan=200,nw_dst=10.100.0.0/24 actions=goto_table:6 - +table=4 priority=9123,ip,dl_vlan=100,nw_dst=10.200.0.0/24 actions=goto_table:6 - +table=4 priority=9123,ip,dl_vlan=200,nw_dst=10.200.0.0/24 actions=goto_table:6 - -Table 6 has a few different things going on. It sends ARP requests -for the router IPs to the controller; presumably the controller will -generate replies and send them back to the requester. It switches -other ARP packets, either broadcasting them if they have a broadcast -destination or attempting to unicast them otherwise. It sends all -other IP packets to the controller:: - - +table=6 priority=9133,arp,arp_tpa=10.100.0.254 actions=CONTROLLER:128 - +table=6 priority=9133,arp,arp_tpa=10.200.0.254 actions=CONTROLLER:128 - +table=6 priority=9132,arp,dl_dst=ff:ff:ff:ff:ff:ff actions=goto_table:8 - +table=6 priority=9131,arp actions=goto_table:7 - +table=6 priority=9130,ip actions=CONTROLLER:128 - -Performance is clearly going to be poor if every packet that needs to -be routed has to go to the controller, but it's unlikely that's the -full story. In the next section, we'll take a closer look. - -Tracing -~~~~~~~ - -As in our switching example, we can play some "what-if?" games to -figure out how this works. Let's suppose that a machine with IP -10.100.0.1, on port ``p1``, wants to send a IP packet to a machine -with IP 10.200.0.1 on port ``p4``. Assuming that these hosts have not -been in communication recently, the steps to accomplish this are -normally the following: - -1. Host 10.100.0.1 sends an ARP request to router 10.100.0.254. - -2. The router sends an ARP reply to the host. - -3. Host 10.100.0.1 sends an IP packet to 10.200.0.1, via the router's - Ethernet address. - -4. The router broadcasts an ARP request to ``p4`` and ``p5``, the - ports that carry the 10.200.0. network. - -5. Host 10.200.0.1 sends an ARP reply to the router. - -6. Either the router sends the IP packet (which it buffered) to - 10.200.0.1, or eventually 10.100.0.1 times out and resends it. - -Let's use ``ofproto/trace`` to see whether Faucet and OVS follow this -procedure. - -Before we start, save a new snapshot of the flow tables for later -comparison:: - - $ save-flows br0 > flows2 - -Step 1: Host ARP for Router -+++++++++++++++++++++++++++ - -Let's simulate the ARP from 10.100.0.1 to its gateway router -10.100.0.254. This requires more detail than any of the packets we've -simulated previously:: - - $ ovs-appctl ofproto/trace br0 in_port=p1,dl_src=00:01:02:03:04:05,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x806,arp_spa=10.100.0.1,arp_tpa=10.100.0.254,arp_sha=00:01:02:03:04:05,arp_tha=ff:ff:ff:ff:ff:ff,arp_op=1 -generate - -The important part of the output is where it shows that the packet was -recognized as an ARP request destined to the router gateway and -therefore sent to the controller:: - - 6. arp,arp_tpa=10.100.0.254, priority 9133, cookie 0x5adc15c0 - CONTROLLER:128 - -The Faucet log shows that Faucet learned the host's MAC address, -its MAC-to-IP mapping, and responded to the ARP request:: - - Jan 06 16:12:23 faucet.valve INFO DPID 1 (0x1) Adding new route 10.100.0.1/32 via 10.100.0.1 (00:01:02:03:04:05) on VLAN 100 - Jan 06 16:12:23 faucet.valve INFO DPID 1 (0x1) Responded to ARP request for 10.100.0.254 from 10.100.0.1 (00:01:02:03:04:05) on VLAN 100 - Jan 06 16:12:23 faucet.valve INFO DPID 1 (0x1) L2 learned 00:01:02:03:04:05 (L2 type 0x0806, L3 src 10.100.0.1) on Port 1 on VLAN 100 (1 hosts total) - -We can also look at the changes to the flow tables:: - - $ diff-flows flows2 br0 - +table=3 priority=9098,in_port=1,dl_vlan=100,dl_src=00:01:02:03:04:05 hard_timeout=3600 actions=goto_table:7 - +table=4 priority=9131,ip,dl_vlan=100,nw_dst=10.100.0.1 actions=set_field:4196->vlan_vid,set_field:0e:00:00:00:00:01->eth_src,set_field:00:01:02:03:04:05->eth_dst,dec_ttl,goto_table:7 - +table=4 priority=9131,ip,dl_vlan=200,nw_dst=10.100.0.1 actions=set_field:4196->vlan_vid,set_field:0e:00:00:00:00:01->eth_src,set_field:00:01:02:03:04:05->eth_dst,dec_ttl,goto_table:7 - +table=7 priority=9099,dl_vlan=100,dl_dst=00:01:02:03:04:05 idle_timeout=3600 actions=pop_vlan,output:1 - -The new flows include one in table 3 and one in table 7 for the -learned MAC, which have the same forms we saw before. The new flows -in table 4 are different. They matches packets directed to 10.100.0.1 -(in two VLANs) and forward them to the host by updating the Ethernet -source and destination addresses appropriately, decrementing the TTL, -and skipping ahead to unicast output in table 7. This means that -packets sent **to** 10.100.0.1 should now get to their destination. - -Step 2: Router Sends ARP Reply -++++++++++++++++++++++++++++++ - -``inst/faucet.log`` said that the router sent an ARP reply. How can -we see it? Simulated packets just get dropped by default. One way is -to configure the dummy ports to write the packets they receive to a -file. Let's try that. First configure the port:: - - $ ovs-vsctl set interface p1 options:pcap=p1.pcap - -Then re-run the "trace" command:: - - $ ovs-appctl ofproto/trace br0 in_port=p1,dl_src=00:01:02:03:04:05,dl_dst=ff:ff:ff:ff:ff:ff,dl_type=0x806,arp_spa=10.100.0.1,arp_tpa=10.100.0.254,arp_sha=00:01:02:03:04:05,arp_tha=ff:ff:ff:ff:ff:ff,arp_op=1 -generate - -And dump the reply packet:: - - $ /usr/sbin/tcpdump -evvvr sandbox/p1.pcap - reading from file sandbox/p1.pcap, link-type EN10MB (Ethernet) - 16:14:47.670727 0e:00:00:00:00:01 (oui Unknown) > 00:01:02:03:04:05 (oui Unknown), ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Reply 10.100.0.254 is-at 0e:00:00:00:00:01 (oui Unknown), length 46 - -We clearly see the ARP reply, which tells us that the Faucet router's -Ethernet address is 0e:00:00:00:00:01 (as we guessed before from the -flow table. - -Let's configure the rest of our ports to log their packets, too:: - - $ for i in 2 3 4 5; do ovs-vsctl set interface p$i options:pcap=p$i.pcap; done - -Step 3: Host Sends IP Packet -++++++++++++++++++++++++++++ - -Now that host 10.100.0.1 has the MAC address for its router, it can -send an IP packet to 10.200.0.1 via the router's MAC address, like -this:: - - $ ovs-appctl ofproto/trace br0 in_port=p1,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,udp,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_ttl=64 -generate - Flow: udp,in_port=1,vlan_tci=0x0000,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=0 - - bridge("br0") - ------------- - 0. in_port=1, priority 9099, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=1,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4196->vlan_vid - goto_table:3 - 3. ip,dl_vlan=100,dl_dst=0e:00:00:00:00:01, priority 9099, cookie 0x5adc15c0 - goto_table:4 - 4. ip,dl_vlan=100,nw_dst=10.200.0.0/24, priority 9123, cookie 0x5adc15c0 - goto_table:6 - 6. ip, priority 9130, cookie 0x5adc15c0 - CONTROLLER:128 - - Final flow: udp,in_port=1,dl_vlan=100,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=0 - Megaflow: recirc_id=0,eth,ip,in_port=1,vlan_tci=0x0000/0x1fff,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_dst=10.200.0.0/25,nw_frag=no - Datapath actions: push_vlan(vid=100,pcp=0),userspace(pid=0,controller(reason=1,flags=0,recirc_id=6,rule_cookie=0x5adc15c0,controller_id=0,max_len=128)) - -Observe that the packet gets recognized as destined to the router, in -table 3, and then as properly destined to the 10.200.0.0/24 network, -in table 4. In table 6, however, it gets sent to the controller. -Presumably, this is because Faucet has not yet resolved an Ethernet -address for the destination host 10.200.0.1. It probably sent out an -ARP request. Let's take a look in the next step. - -Step 4: Router Broadcasts ARP Request -+++++++++++++++++++++++++++++++++++++ - -The router needs to know the Ethernet address of 10.200.0.1. It knows -that, if this machine exists, it's on port ``p4`` or ``p5``, since we -configured those ports as VLAN 200. - -Let's make sure:: - - $ /usr/sbin/tcpdump -evvvr sandbox/p4.pcap - reading from file sandbox/p4.pcap, link-type EN10MB (Ethernet) - 16:17:43.174006 0e:00:00:00:00:01 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.200.0.1 tell 10.200.0.254, length 46 - -and:: - - $ /usr/sbin/tcpdump -evvvr sandbox/p5.pcap - reading from file sandbox/p5.pcap, link-type EN10MB (Ethernet) - 16:17:43.174268 0e:00:00:00:00:01 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 10.200.0.1 tell 10.200.0.254, length 46 - -For good measure, let's make sure that it wasn't sent to ``p3``:: - - $ /usr/sbin/tcpdump -evvvr sandbox/p3.pcap - reading from file sandbox/p3.pcap, link-type EN10MB (Ethernet) - -Step 5: Host 2 Sends ARP Reply -++++++++++++++++++++++++++++++ - -The Faucet controller sent an ARP request, so we can send an ARP -reply:: - - $ ovs-appctl ofproto/trace br0 in_port=p4,dl_src=00:10:20:30:40:50,dl_dst=0e:00:00:00:00:01,dl_type=0x806,arp_spa=10.200.0.1,arp_tpa=10.200.0.254,arp_sha=00:10:20:30:40:50,arp_tha=0e:00:00:00:00:01,arp_op=2 -generate - Flow: arp,in_port=4,vlan_tci=0x0000,dl_src=00:10:20:30:40:50,dl_dst=0e:00:00:00:00:01,arp_spa=10.200.0.1,arp_tpa=10.200.0.254,arp_op=2,arp_sha=00:10:20:30:40:50,arp_tha=0e:00:00:00:00:01 - - bridge("br0") - ------------- - 0. in_port=4, priority 9099, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=4,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4296->vlan_vid - goto_table:3 - 3. arp,dl_vlan=200, priority 9131, cookie 0x5adc15c0 - goto_table:6 - 6. arp,arp_tpa=10.200.0.254, priority 9133, cookie 0x5adc15c0 - CONTROLLER:128 - - Final flow: arp,in_port=4,dl_vlan=200,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=00:10:20:30:40:50,dl_dst=0e:00:00:00:00:01,arp_spa=10.200.0.1,arp_tpa=10.200.0.254,arp_op=2,arp_sha=00:10:20:30:40:50,arp_tha=0e:00:00:00:00:01 - Megaflow: recirc_id=0,eth,arp,in_port=4,vlan_tci=0x0000/0x1fff,dl_dst=0e:00:00:00:00:01,arp_tpa=10.200.0.254 - Datapath actions: push_vlan(vid=200,pcp=0),userspace(pid=0,controller(reason=1,flags=0,recirc_id=7,rule_cookie=0x5adc15c0,controller_id=0,max_len=128)) - -It shows up in ``inst/faucet.log``:: - - Jan 06 03:20:11 faucet.valve INFO DPID 1 (0x1) Adding new route 10.200.0.1/32 via 10.200.0.1 (00:10:20:30:40:50) on VLAN 200 - Jan 06 03:20:11 faucet.valve INFO DPID 1 (0x1) ARP response 10.200.0.1 (00:10:20:30:40:50) on VLAN 200 - Jan 06 03:20:11 faucet.valve INFO DPID 1 (0x1) L2 learned 00:10:20:30:40:50 (L2 type 0x0806, L3 src 10.200.0.1) on Port 4 on VLAN 200 (1 hosts total) - -and in the OVS flow tables:: - - $ diff-flows flows2 br0 - +table=3 priority=9098,in_port=4,dl_vlan=200,dl_src=00:10:20:30:40:50 hard_timeout=3601 actions=goto_table:7 - ... - +table=4 priority=9131,ip,dl_vlan=200,nw_dst=10.200.0.1 actions=set_field:4296->vlan_vid,set_field:0e:00:00:00:00:01->eth_src,set_field:00:10:20:30:40:50->eth_dst,dec_ttl,goto_table:7 - +table=4 priority=9131,ip,dl_vlan=100,nw_dst=10.200.0.1 actions=set_field:4296->vlan_vid,set_field:0e:00:00:00:00:01->eth_src,set_field:00:10:20:30:40:50->eth_dst,dec_ttl,goto_table:7 - ... - +table=4 priority=9123,ip,dl_vlan=100,nw_dst=10.200.0.0/24 actions=goto_table:6 - +table=7 priority=9099,dl_vlan=200,dl_dst=00:10:20:30:40:50 idle_timeout=3601 actions=pop_vlan,output:4 - -Step 6: IP Packet Delivery -++++++++++++++++++++++++++ - -Now both the host and the router have everything they need to deliver -the packet. There are two ways it might happen. If Faucet's router -is smart enough to buffer the packet that trigger ARP resolution, then -it might have delivered it already. If so, then it should show up in -``p4.pcap``. Let's take a look:: - - $ /usr/sbin/tcpdump -evvvr sandbox/p4.pcap ip - reading from file sandbox/p4.pcap, link-type EN10MB (Ethernet) - -Nope. That leaves the other possibility, which is that Faucet waits -for the original sending host to re-send the packet. We can do that -by re-running the trace:: - - $ ovs-appctl ofproto/trace br0 in_port=p1,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,udp,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_ttl=64 -generate - Flow: udp,in_port=1,vlan_tci=0x0000,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=0 - - bridge("br0") - ------------- - 0. in_port=1, priority 9099, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=1,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4196->vlan_vid - goto_table:3 - 3. ip,dl_vlan=100,dl_dst=0e:00:00:00:00:01, priority 9099, cookie 0x5adc15c0 - goto_table:4 - 4. ip,dl_vlan=100,nw_dst=10.200.0.1, priority 9131, cookie 0x5adc15c0 - set_field:4296->vlan_vid - set_field:0e:00:00:00:00:01->eth_src - set_field:00:10:20:30:40:50->eth_dst - dec_ttl - goto_table:7 - 7. dl_vlan=200,dl_dst=00:10:20:30:40:50, priority 9099, cookie 0x5adc15c0 - pop_vlan - output:4 - - Final flow: udp,in_port=1,vlan_tci=0x0000,dl_src=0e:00:00:00:00:01,dl_dst=00:10:20:30:40:50,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_tos=0,nw_ecn=0,nw_ttl=63,tp_src=0,tp_dst=0 - Megaflow: recirc_id=0,eth,ip,in_port=1,vlan_tci=0x0000/0x1fff,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_dst=10.200.0.1,nw_ttl=64,nw_frag=no - Datapath actions: set(eth(src=0e:00:00:00:00:01,dst=00:10:20:30:40:50)),set(ipv4(dst=10.200.0.1,ttl=63)),4 - -Finally, we have working IP packet forwarding! - -Performance -~~~~~~~~~~~ - -Take another look at the megaflow line above:: - - Megaflow: recirc_id=0,eth,ip,in_port=1,vlan_tci=0x0000/0x1fff,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_dst=10.200.0.1,nw_ttl=64,nw_frag=no - -This means that (almost) any packet between these Ethernet source and -destination hosts, destined to the given IP host, will be handled by -this single megaflow cache entry. So regardless of the number of UDP -packets or TCP connections that these hosts exchange, Open vSwitch -packet processing won't need to fall back to the slow path. It is -quite efficient. - -.. note:: - - The exceptions are packets with a TTL other than 64, and fragmented - packets. Most hosts use a constant TTL for outgoing packets, and - fragments are rare. If either of those did change, then that would - simply result in a new megaflow cache entry. - -The datapath actions might also be worth a look:: - - Datapath actions: set(eth(src=0e:00:00:00:00:01,dst=00:10:20:30:40:50)),set(ipv4(dst=10.200.0.1,ttl=63)),4 - -This just means that, to process these packets, the datapath changes -the Ethernet source and destination addresses and the IP TTL, and then -transmits the packet to port ``p4`` (also numbered 4). Notice in -particular that, despite the OpenFlow actions that pushed, modified, -and popped back off a VLAN, there is nothing in the datapath actions -about VLANs. This is because the OVS flow translation code "optimizes -out" redundant or unneeded actions, which saves time when the cache -entry is executed later. - -.. note:: - - It's not clear why the actions also re-set the IP destination - address to its original value. Perhaps this is a minor performance - bug. - -ACLs ----- - -Let's try out some ACLs, since they do a good job illustrating some of -the ways that OVS tries to optimize megaflows. Update -``inst/faucet.yaml`` to the following:: - - dps: - switch-1: - dp_id: 0x1 - timeout: 3600 - arp_neighbor_timeout: 3600 - interfaces: - 1: - native_vlan: 100 - acl_in: 1 - 2: - native_vlan: 100 - 3: - native_vlan: 100 - 4: - native_vlan: 200 - 5: - native_vlan: 200 - vlans: - 100: - faucet_vips: ["10.100.0.254/24"] - 200: - faucet_vips: ["10.200.0.254/24"] - routers: - router-1: - vlans: [100, 200] - acls: - 1: - - rule: - dl_type: 0x800 - nw_proto: 6 - tcp_dst: 8080 - actions: - allow: 0 - - rule: - actions: - allow: 1 - -Then restart Faucet:: - - $ docker restart faucet - -On port 1, this new configuration blocks all traffic to TCP port 8080 -and allows all other traffic. The resulting change in the flow table -shows this clearly too:: - - $ diff-flows flows2 br0 - -priority=9099,in_port=1 actions=goto_table:1 - +priority=9098,in_port=1 actions=goto_table:1 - +priority=9099,tcp,in_port=1,tp_dst=8080 actions=drop - -The most interesting question here is performance. If you recall the -earlier discussion, when a packet through the flow table encounters a -match on a given field, the resulting megaflow has to match on that -field, even if the flow didn't actually match. This is expensive. - -In particular, here you can see that any TCP packet is going to -encounter the ACL flow, even if it is directed to a port other than -8080. If that means that every megaflow for a TCP packet is going to -have to match on the TCP destination, that's going to be bad for -caching performance because there will be a need for a separate -megaflow for every TCP destination port that actually appears in -traffic, which means a lot more megaflows than otherwise. (Really, in -practice, if such a simple ACL blew up performance, OVS wouldn't be a -very good switch!) - -Let's see what happens, by sending a packet to port 80 (instead of -8080):: - - $ ovs-appctl ofproto/trace br0 in_port=p1,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,tcp,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_ttl=64,tp_dst=80 -generate - Flow: tcp,in_port=1,vlan_tci=0x0000,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=80,tcp_flags=0 - - bridge("br0") - ------------- - 0. in_port=1, priority 9098, cookie 0x5adc15c0 - goto_table:1 - 1. in_port=1,vlan_tci=0x0000/0x1fff, priority 9000, cookie 0x5adc15c0 - push_vlan:0x8100 - set_field:4196->vlan_vid - goto_table:3 - 3. ip,dl_vlan=100,dl_dst=0e:00:00:00:00:01, priority 9099, cookie 0x5adc15c0 - goto_table:4 - 4. ip,dl_vlan=100,nw_dst=10.200.0.0/24, priority 9123, cookie 0x5adc15c0 - goto_table:6 - 6. ip, priority 9130, cookie 0x5adc15c0 - CONTROLLER:128 - - Final flow: tcp,in_port=1,dl_vlan=100,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_src=10.100.0.1,nw_dst=10.200.0.1,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=80,tcp_flags=0 - Megaflow: recirc_id=0,eth,tcp,in_port=1,vlan_tci=0x0000/0x1fff,dl_src=00:01:02:03:04:05,dl_dst=0e:00:00:00:00:01,nw_dst=10.200.0.1,nw_frag=no,tp_dst=0x0/0xf000 - Datapath actions: push_vlan(vid=100,pcp=0) - -Take a look at the Megaflow line and in particular the match on -``tp_dst``, which says ``tp_dst=0x0/0xf000``. What this means is that -the megaflow matches on only the top 4 bits of the TCP destination -port. That works because:: - - 80 (base 10) == 0000,0000,0101,0000 (base 2) - 8080 (base 10) == 0001,1111,1001,0000 (base 2) - -and so by matching on only the top 4 bits, rather than all 16, the OVS -fast path can distinguish port 80 from port 8080. This allows this -megaflow to match one-sixteenth of the TCP destination port address -space, rather than just 1/65536th of it. - -.. note:: - - The algorithm OVS uses for this purpose isn't perfect. In this - case, a single-bit match would work (e.g. tp_dst=0x0/0x1000), and - would be superior since it would only match half the port address - space instead of one-sixteenth. - -For details of this algorithm, please refer to ``lib/classifier.c`` in -the Open vSwitch source tree, or our 2015 NSDI paper "The Design and -Implementation of Open vSwitch". - -Finishing Up ------------- - -When you're done, you probably want to exit the sandbox session, with -Control+D or ``exit``, and stop the Faucet controller with ``docker -stop faucet; docker rm faucet``. - -Further Directions ------------------- - -We've looked a fair bit at how Faucet interacts with Open vSwitch. If -you still have some interest, you might want to explore some of these -directions: - -* Adding more than one switch. Faucet can control multiple switches - but we've only been simulating one of them. It's easy enough to - make a single OVS instance act as multiple switches (just - ``ovs-vsctl add-br`` another bridge), or you could use genuinely - separate OVS instances. - -* Additional features. Faucet has more features than we've - demonstrated, such as IPv6 routing and port mirroring. These should - also interact gracefully with Open vSwitch. - -* Real performance testing. We've looked at how flows and traces - **should** demonstrate good performance, but of course there's no - proof until it actually works in practice. We've also only tested - with trivial configurations. Open vSwitch can scale to millions of - OpenFlow flows, but the scaling in practice depends on the - particular flow tables and traffic patterns, so it's valuable to - test with large configurations, either in the way we've done it or - with real traffic. diff --git a/Documentation/tutorials/index.rst b/Documentation/tutorials/index.rst index 35340ee56..4f3e3103d 100644 --- a/Documentation/tutorials/index.rst +++ b/Documentation/tutorials/index.rst @@ -39,11 +39,7 @@ vSwitch. .. toctree:: :maxdepth: 2 - faucet - ipsec - ovs-advanced ovn-sandbox ovn-openstack ovn-rbac ovn-ipsec - ovs-conntrack diff --git a/Documentation/tutorials/ipsec.rst b/Documentation/tutorials/ipsec.rst deleted file mode 100644 index b4c323513..000000000 --- a/Documentation/tutorials/ipsec.rst +++ /dev/null @@ -1,347 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -================== -OVS IPsec Tutorial -================== - -This document provides a step-by-step guide for running IPsec tunnel in Open -vSwitch. A more detailed description on OVS IPsec tunnel and its -configuration modes can be found in :doc:`/howto/ipsec`. - -Requirements ------------- - -OVS IPsec tunnel requires Linux kernel (>= v3.10.0) and OVS out-of-tree kernel -module. The compatible IKE daemons are LibreSwan (>= v3.23) and StrongSwan -(>= v5.3.5). - -.. _install-ovs-ipsec: - -Installing OVS and IPsec Packages ---------------------------------- - -OVS IPsec has .deb and .rpm packages. You should use the right package -based on your Linux distribution. This tutorial uses Ubuntu 16.04 and Fedora 27 -as examples. - -Ubuntu -~~~~~~ - -1. Follow :doc:`/intro/install/debian` to build debian packages. - - .. note:: - - If you have already installed OVS, then you only need to install - openvswitch-pki_*.deb and openvswitch-ipsec_*.deb in the following step. - If your kernel version is below v4.13.0, update your kernel to v4.13.0 or - above. - -2. Install the related packages:: - - $ apt-get install dkms strongswan - $ dpkg -i libopenvswitch_*.deb openvswitch-common_*.deb \ - openvswitch-switch_*.deb openvswitch-datapath-dkms_*.deb \ - python-openvswitch_*.deb openvswitch-pki_*.deb \ - openvswitch-ipsec_*.deb - - If the installation is successful, you should be able to see the - ovs-monitor-ipsec daemon is running in your system. - -Fedora -~~~~~~ - -1. Follow :doc:`/intro/install/fedora` to build RPM packages. - -2. Install the related packages:: - - $ dnf install python2-openvswitch libreswan \ - "kernel-devel-uname-r == $(uname -r)" - $ rpm -i openvswitch-*.rpm openvswitch-kmod-*.rpm \ - openvswitch-openvswitch-ipsec-*.rpm - -3. Install firewall rules to allow ESP and IKE traffic:: - - $ iptables -A IN_FedoraServer_allow -p esp -j ACCEPT - $ iptables -A IN_FedoraServer_allow -p udp --dport 500 -j ACCEPT - -4. Run the openvswitch-ipsec service:: - - $ systemctl start openvswitch-ipsec.service - - .. note:: - - The SELinux policies might prevent openvswitch-ipsec.service to access - certain resources. You can configure SELinux to remove such restrictions. - -Configuring IPsec tunnel ------------------------- - -Suppose you want to build IPsec tunnel between two hosts. Assume `host_1`'s -external IP is 1.1.1.1, and `host_2`'s external IP is 2.2.2.2. Make sure -`host_1` and `host_2` can ping each other via these external IPs. - -0. Set up some variables to make life easier. On both hosts, set ``ip_1`` and - ``ip_2`` variables, e.g.:: - - $ ip_1=1.1.1.1 - $ ip_2=2.2.2.2 - -1. Set up OVS bridges in both hosts. - - In `host_1`:: - - $ ovs-vsctl add-br br-ipsec - $ ip addr add 192.0.0.1/24 dev br-ipsec - $ ip link set br-ipsec up - - In `host_2`:: - - $ ovs-vsctl add-br br-ipsec - $ ip addr add 192.0.0.2/24 dev br-ipsec - $ ip link set br-ipsec up - -2. Set up IPsec tunnel. - - There are three authentication methods. You can choose one to set up your - IPsec tunnel. - - a) Using pre-shared key: - - In `host_1`:: - - $ ovs-vsctl add-port br-ipsec tun -- \ - set interface tun type=gre \ - options:remote_ip=$ip_2 \ - options:psk=swordfish - - In `host_2`:: - - $ ovs-vsctl add-port br-ipsec tun -- \ - set interface tun type=gre \ - options:remote_ip=$ip_1 \ - options:psk=swordfish - - .. note:: - - Pre-shared key (PSK) based authentication is easy to set up but less - secure compared with other authentication methods. You should use it - cautiously in production systems. - - b) Using self-signed certificate: - - Generate self-signed certificate in both `host_1` and `host_2`. Then copy - the certificate of `host_1` to `host_2` and the certificate of `host_2` - to `host_1`. - - In `host_1`:: - - $ ovs-pki req -u host_1 - $ ovs-pki self-sign host_1 - $ scp host_1-cert.pem $ip_2:/etc/keys/host_1-cert.pem - - In `host_2`:: - - $ ovs-pki req -u host_2 - $ ovs-pki self-sign host_2 - $ scp host_2-cert.pem $ip_1:/etc/keys/host_2-cert.pem - - .. note:: - - If you use StrongSwan as IKE daemon, please move the host certificates - to /etc/ipsec.d/certs/ and private key to /etc/ipsec.d/private/ so that - StrongSwan has permission to access those files. - - Configure IPsec tunnel to use self-signed certificates. - - In `host_1`:: - - $ ovs-vsctl set Open_vSwitch . \ - other_config:certificate=/etc/keys/host_1-cert.pem \ - other_config:private_key=/etc/keys/host_1-privkey.pem - $ ovs-vsctl add-port br-ipsec tun -- \ - set interface tun type=gre \ - options:remote_ip=$ip_2 \ - options:remote_cert=/etc/keys/host_2-cert.pem - - In `host_2`:: - - $ ovs-vsctl set Open_vSwitch . \ - other_config:certificate=/etc/keys/host_2-cert.pem \ - other_config:private_key=/etc/keys/host_2-privkey.pem - $ ovs-vsctl add-port br-ipsec tun -- \ - set interface tun type=gre \ - options:remote_ip=$ip_1 \ - options:remote_cert=/etc/keys/host_1-cert.pem - - .. note:: - - The confidentiality of the private key is very critical. Don't copy it - to places where it might be compromised. (The certificate need not be - kept confidential.) - - c) Using CA-signed certificate: - - First you need to establish a public key infrastructure (PKI). Suppose - you choose `host_1` to host PKI. - - In `host_1`:: - - $ ovs-pki init - - Generate certificate requests and copy the certificate request of - `host_2` to `host_1`. - - In `host_1`:: - - $ ovs-pki req -u host_1 - - In `host_2`:: - - $ ovs-pki req -u host_2 - $ scp host_2-req.pem $ip_1:/etc/keys/host_2-req.pem - - Sign the certificate requests with the CA key. Copy `host_2`'s signed - certificate and the CA certificate to `host_2`. - - In `host_1`:: - - $ ovs-pki sign host_1 switch - $ ovs-pki sign host_2 switch - $ scp host_2-cert.pem $ip_2:/etc/keys/host_2-cert.pem - $ scp /var/lib/openvswitch/pki/switchca/cacert.pem \ - $ip_2:/etc/keys/cacert.pem - - .. note:: - - If you use StrongSwan as IKE daemon, please move the host certificates - to /etc/ipsec.d/certs/, CA certificate to /etc/ipsec.d/cacerts/, and - private key to /etc/ipsec.d/private/ so that StrongSwan has permission - to access those files. - - Configure IPsec tunnel to use CA-signed certificate. - - In `host_1`:: - - $ ovs-vsctl set Open_vSwitch . \ - other_config:certificate=/etc/keys/host_1-cert.pem \ - other_config:private_key=/etc/keys/host_1-privkey.pem \ - other_config:ca_cert=/etc/keys/cacert.pem - $ ovs-vsctl add-port br-ipsec tun -- \ - set interface tun type=gre \ - options:remote_ip=$ip_2 \ - options:remote_name=host_2 - - In `host_2`:: - - $ ovs-vsctl set Open_vSwitch . \ - other_config:certificate=/etc/keys/host_2-cert.pem \ - other_config:private_key=/etc/keys/host_2-privkey.pem \ - other_config:ca_cert=/etc/keys/cacert.pem - $ ovs-vsctl add-port br-ipsec tun -- \ - set interface tun type=gre \ - options:remote_ip=$ip_1 \ - options:remote_name=host_1 - - .. note:: - - remote_name is the common name (CN) of the signed-certificate. It must - match the name given as the argument to the ``ovs-pki sign command``. - It ensures that only certificate with the expected CN can be - authenticated; otherwise, any certificate signed by the CA would be - accepted. - -3. Test IPsec tunnel. - - Now you should have an IPsec GRE tunnel running between two hosts. To verify - it, in `host_1`:: - - $ ping 192.0.0.2 & - $ tcpdump -ni any net $ip_2 - - You should be able to see that ESP packets are being sent from `host_1` to - `host_2`. - -Troubleshooting ---------------- - -The ``ovs-monitor-ipsec`` daemon manages and monitors the IPsec tunnel state. -Use the following ``ovs-appctl`` command to view ``ovs-monitor-ipsec`` internal -representation of tunnel configuration:: - - $ ovs-appctl -t ovs-monitor-ipsec tunnels/show - -If there is misconfiguration, then ``ovs-appctl`` should indicate why. -For example:: - - Interface name: gre0 v5 (CONFIGURED) <--- Should be set to CONFIGURED. - Otherwise, error message will - be provided - Tunnel Type: gre - Remote IP: 2.2.2.2 - SKB mark: None - Local cert: None - Local name: None - Local key: None - Remote cert: None - Remote name: None - CA cert: None - PSK: swordfish - Ofport: 1 <--- Whether ovs-vswitchd has assigned Ofport - number to this Tunnel Port - CFM state: Up <--- Whether CFM declared this tunnel healthy - Kernel policies installed: - ... <--- IPsec policies for this OVS tunnel in - Linux Kernel installed by strongSwan - Kernel security associations installed: - ... <--- IPsec security associations for this OVS - tunnel in Linux Kernel installed by - strongswan - IPsec connections that are active: - ... <--- IPsec "connections" for this OVS - tunnel - -If you don't see any active connections, try to run the following command to -refresh the ``ovs-monitor-ipsec`` daemon:: - - $ ovs-appctl -t ovs-monitor-ipsec refresh - -You can also check the logs of the ``ovs-monitor-ipsec`` daemon and the IKE -daemon to locate issues. ``ovs-monitor-ipsec`` outputs log messages to -/var/log/openvswitch/ovs-monitor-ipsec.log. - -Bug Reporting -------------- - -If you think you may have found a bug with security implications, like - -1. IPsec protected tunnel accepted packets that came unencrypted; OR -2. IPsec protected tunnel allowed packets to leave unencrypted; - -Then report such bugs according to :doc:`/internals/security`. - -If bug does not have security implications, then report it according to -instructions in :doc:`/internals/bugs`. - -If you have suggestions to improve this tutorial, please send a email to -ovs-discuss@openvswitch.org. diff --git a/Documentation/tutorials/ovn-ipsec.rst b/Documentation/tutorials/ovn-ipsec.rst index feb695ea3..e0c702a04 100644 --- a/Documentation/tutorials/ovn-ipsec.rst +++ b/Documentation/tutorials/ovn-ipsec.rst @@ -34,8 +34,8 @@ manipulated. More details about the OVN IPsec design can be found in ``ovn-architecture``\(7) manpage. This document assumes OVN is installed in your system and runs normally. Also, -you need to install OVS IPsec packages in each chassis (refer to -:ref:`install-ovs-ipsec`). +you need to install OVS IPsec packages in each chassis (refer to Open vSwitch +documentation on ipsec). Generating Certificates and Keys -------------------------------- diff --git a/Documentation/tutorials/ovn-sandbox.rst b/Documentation/tutorials/ovn-sandbox.rst index b906b799d..3acc7b210 100644 --- a/Documentation/tutorials/ovn-sandbox.rst +++ b/Documentation/tutorials/ovn-sandbox.rst @@ -33,8 +33,8 @@ ovn-architecture_, but this tutorial lets you quickly see it in action. Getting Started --------------- -For some general information about ``ovs-sandbox``, see the "Getting Started" -section of :doc:`ovs-advanced`. +For some general information about ``ovs-sandbox``, see the Open vSwitch +documentaion on ``ovs-sandbox``. ``ovs-sandbox`` does not include OVN support by default. To enable OVN, you must pass the ``--ovn`` flag. For example, if running it straight from the OVS @@ -64,8 +64,8 @@ Using GDB --------- GDB support is not required to go through the tutorial. See the "Using GDB" -section of :doc:`ovs-advanced` for more info. Additional flags exist for -launching the debugger for the OVN programs:: +section of ovs-advanced in Open vSwitch documentation for more info. +Additional flags exist for launching the debugger for the OVN programs:: --gdb-ovn-northd --gdb-ovn-controller diff --git a/Documentation/tutorials/ovs-advanced.rst b/Documentation/tutorials/ovs-advanced.rst deleted file mode 100644 index fa9fdc7bf..000000000 --- a/Documentation/tutorials/ovs-advanced.rst +++ /dev/null @@ -1,941 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -============================== -Open vSwitch Advanced Features -============================== - -Many tutorials cover the basics of OpenFlow. This is not such a tutorial. -Rather, a knowledge of the basics of OpenFlow is a prerequisite. If you do not -already understand how an OpenFlow flow table works, please go read a basic -tutorial and then continue reading here afterward. - -It is also important to understand the basics of Open vSwitch before you begin. -If you have never used ovs-vsctl or ovs-ofctl before, you should learn a little -about them before proceeding. - -Most of the features covered in this tutorial are Open vSwitch extensions to -OpenFlow. Also, most of the features in this tutorial are specific to the -software Open vSwitch implementation. If you are using an Open vSwitch port to -an ASIC-based hardware switch, this tutorial will not help you. - -This tutorial does not cover every aspect of the features that it mentions. -You can find the details elsewhere in the Open vSwitch documentation, -especially ``ovs-ofctl(8)`` and the comments in the -``include/openflow/nicira-ext.h`` and ``include/openvswitch/meta-flow.h`` -header files. - -Getting Started ---------------- - -This is a hands-on tutorial. To get the most out of it, you will need Open -vSwitch binaries. You do not, on the other hand, need any physical networking -hardware or even supervisor privilege on your system. Instead, we will use a -script called ``ovs-sandbox``, which accompanies the tutorial, that constructs -a software simulated network environment based on Open vSwitch. - -You can use ``ovs-sandbox`` three ways: - -* If you have already installed Open vSwitch on your system, then you should be - able to just run ``ovs-sandbox`` from this directory without any options. - -* If you have not installed Open vSwitch (and you do not want to install it), - then you can build Open vSwitch according to the instructions in - :doc:`/intro/install/general`, without installing it. Then run - ``./ovs-sandbox -b DIRECTORY`` from this directory, substituting the Open - vSwitch build directory for ``DIRECTORY``. - -* As a slight variant on the latter, you can run ``make sandbox`` from an Open - vSwitch build directory. - -When you run ``ovs-sandbox``, it does the following: - -1. **CAUTION:** Deletes any subdirectory of the current directory named - "sandbox" and any files in that directory. - -2. Creates a new directory "sandbox" in the current directory. - -3. Sets up special environment variables that ensure that Open vSwitch programs - will look inside the "sandbox" directory instead of in the Open vSwitch - installation directory. - -4. If you are using a built but not installed Open vSwitch, installs the Open - vSwitch manpages in a subdirectory of "sandbox" and adjusts the ``MANPATH`` - environment variable to point to this directory. This means that you can - use, for example, ``man ovs-vsctl`` to see a manpage for the ``ovs-vsctl`` - program that you built. - -5. Creates an empty Open vSwitch configuration database under "sandbox". - -6. Starts ``ovsdb-server`` running under "sandbox". - -7. Starts ``ovs-vswitchd`` running under "sandbox", passing special options - that enable a special "dummy" mode for testing. - -8. Starts a nested interactive shell inside "sandbox". - -At this point, you can run all the usual Open vSwitch utilities from the nested -shell environment. You can, for example, use ``ovs-vsctl`` to create a bridge:: - - $ ovs-vsctl add-br br0 - -From Open vSwitch's perspective, the bridge that you create this way is as real -as any other. You can, for example, connect it to an OpenFlow controller or -use ``ovs-ofctl`` to examine and modify it and its OpenFlow flow table. On the -other hand, the bridge is not visible to the operating system's network stack, -so ``ip`` cannot see it or affect it, which means that utilities like ``ping`` -and ``tcpdump`` will not work either. (That has its good side, too: you can't -screw up your computer's network stack by manipulating a sandboxed OVS.) - -When you're done using OVS from the sandbox, exit the nested shell (by entering -the "exit" shell command or pressing Control+D). This will kill the daemons -that ``ovs-sandbox`` started, but it leaves the "sandbox" directory and its -contents in place. - -The sandbox directory contains log files for the Open vSwitch dameons. You can -examine them while you're running in the sandboxed environment or after you -exit. - -Using GDB ---------- - -GDB support is not required to go through the tutorial. It is added in case -user wants to explore the internals of OVS programs. - -GDB can already be used to debug any running process, with the usual -``gdb `` command. - -``ovs-sandbox`` also has a ``-g`` option for launching ovs-vswitchd under GDB. -This option can be handy for setting break points before ovs-vswitchd runs, or -for catching early segfaults. Similarly, a ``-d`` option can be used to run -ovsdb-server under GDB. Both options can be specified at the same time. - -In addition, a ``-e`` option also launches ovs-vswitchd under GDB. However, -instead of displaying a ``gdb>`` prompt and waiting for user input, -ovs-vswitchd will start to execute immediately. ``-r`` option is the -corresponding option for running ovsdb-server under gdb with immediate -execution. - -To avoid GDB mangling with the sandbox sub shell terminal, ``ovs-sandbox`` -starts a new xterm to run each GDB session. For systems that do not support X -windows, GDB support is effectively disabled. - -When launching sandbox through the build tree's make file, the ``-g`` option -can be passed via the ``SANDBOXFLAGS`` environment variable. ``make sandbox -SANDBOXFLAGS=-g`` will start the sandbox with ovs-vswitchd running under GDB in -its own xterm if X is available. - -In addition, a set of GDB macros are available in ``utilities/gdb/ovs_gdb.py``. -Which are able to dump various internal data structures. See the header of the -file itself for some more details and an example. - -Motivation ----------- - -The goal of this tutorial is to demonstrate the power of Open vSwitch flow -tables. The tutorial works through the implementation of a MAC-learning switch -with VLAN trunk and access ports. Outside of the Open vSwitch features that we -will discuss, OpenFlow provides at least two ways to implement such a switch: - -1. An OpenFlow controller to implement MAC learning in a "reactive" fashion. - Whenever a new MAC appears on the switch, or a MAC moves from one switch - port to another, the controller adjusts the OpenFlow flow table to match. - -2. The "normal" action. OpenFlow defines this action to submit a packet to - "the traditional non-OpenFlow pipeline of the switch". That is, if a flow - uses this action, then the packets in the flow go through the switch in the - same way that they would if OpenFlow was not configured on the switch. - -Each of these approaches has unfortunate pitfalls. In the first approach, -using an OpenFlow controller to implement MAC learning, has a significant cost -in terms of network bandwidth and latency. It also makes the controller more -difficult to scale to large numbers of switches, which is especially important -in environments with thousands of hypervisors (each of which contains a virtual -OpenFlow switch). MAC learning at an OpenFlow controller also behaves poorly -if the OpenFlow controller fails, slows down, or becomes unavailable due to -network problems. - -The second approach, using the "normal" action, has different problems. First, -little about the "normal" action is standardized, so it behaves differently on -switches from different vendors, and the available features and how those -features are configured (usually not through OpenFlow) varies widely. Second, -"normal" does not work well with other OpenFlow actions. It is -"all-or-nothing", with little potential to adjust its behavior slightly or to -compose it with other features. - -Scenario --------- - -We will construct Open vSwitch flow tables for a VLAN-capable, -MAC-learning switch that has four ports: - -p1 - a trunk port that carries all VLANs, on OpenFlow port 1. - -p2 - an access port for VLAN 20, on OpenFlow port 2. - -p3, p4 - both access ports for VLAN 30, on OpenFlow ports 3 and 4, respectively. - -.. note:: - The ports' names are not significant. You could call them eth1 through eth4, - or any other names you like. - -.. note:: - An OpenFlow switch always has a "local" port as well. This scenario won't - use the local port. - -Our switch design will consist of five main flow tables, each of which -implements one stage in the switch pipeline: - -Table 0 - Admission control. - -Table 1 - VLAN input processing. - -Table 2 - Learn source MAC and VLAN for ingress port. - -Table 3 - Look up learned port for destination MAC and VLAN. - -Table 4 - Output processing. - -The section below describes how to set up the scenario, followed by a section -for each OpenFlow table. - -You can cut and paste the ``ovs-vsctl`` and ``ovs-ofctl`` commands in each of -the sections below into your ``ovs-sandbox`` shell. They are also available as -shell scripts in this directory, named ``t-setup``, ``t-stage0``, ``t-stage1``, -..., ``t-stage4``. The ``ovs-appctl`` test commands are intended for cutting -and pasting and are not supplied separately. - -Setup ------ - -To get started, start ``ovs-sandbox``. Inside the interactive shell that it -starts, run this command:: - - $ ovs-vsctl add-br br0 -- set Bridge br0 fail-mode=secure - -This command creates a new bridge "br0" and puts "br0" into so-called -"fail-secure" mode. For our purpose, this just means that the OpenFlow flow -table starts out empty. - -.. note:: - If we did not do this, then the flow table would start out with a single flow - that executes the "normal" action. We could use that feature to yield a - switch that behaves the same as the switch we are currently building, but - with the caveats described under "Motivation" above.) - -The new bridge has only one port on it so far, the "local port" br0. We need -to add ``p1``, ``p2``, ``p3``, and ``p4``. A shell ``for`` loop is one way to -do it:: - - for i in 1 2 3 4; do - ovs-vsctl add-port br0 p$i -- set Interface p$i ofport_request=$i - ovs-ofctl mod-port br0 p$i up - done - -In addition to adding a port, the ``ovs-vsctl`` command above sets its -``ofport_request`` column to ensure that port ``p1`` is assigned OpenFlow port -1, ``p2`` is assigned OpenFlow port 2, and so on. - -.. note:: - We could omit setting the ofport_request and let Open vSwitch choose port - numbers for us, but it's convenient for the purposes of this tutorial because - we can talk about OpenFlow port 1 and know that it corresponds to ``p1``. - -The ``ovs-ofctl`` command above brings up the simulated interfaces, which are -down initially, using an OpenFlow request. The effect is similar to ``ip link -up``, but the sandbox's interfaces are not visible to the operating system and -therefore ``ip`` would not affect them. - -We have not configured anything related to VLANs or MAC learning. That's -because we're going to implement those features in the flow table. - -To see what we've done so far to set up the scenario, you can run a command -like ``ovs-vsctl show`` or ``ovs-ofctl show br0``. - -Implementing Table 0: Admission control ---------------------------------------- - -Table 0 is where packets enter the switch. We use this stage to discard -packets that for one reason or another are invalid. For example, packets with -a multicast source address are not valid, so we can add a flow to drop them at -ingress to the switch with:: - - $ ovs-ofctl add-flow br0 \ - "table=0, dl_src=01:00:00:00:00:00/01:00:00:00:00:00, actions=drop" - -A switch should also not forward IEEE 802.1D Spanning Tree Protocol (STP) -packets, so we can also add a flow to drop those and other packets with -reserved multicast protocols:: - - $ ovs-ofctl add-flow br0 \ - "table=0, dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0, actions=drop" - -We could add flows to drop other protocols, but these demonstrate the pattern. - -We need one more flow, with a priority lower than the default, so that flows -that don't match either of the "drop" flows we added above go on to pipeline -stage 1 in OpenFlow table 1:: - - $ ovs-ofctl add-flow br0 "table=0, priority=0, actions=resubmit(,1)" - -.. note:: - The "resubmit" action is an Open vSwitch extension to OpenFlow. - -Testing Table 0 ---------------- - -If we were using Open vSwitch to set up a physical or a virtual switch, then we -would naturally test it by sending packets through it one way or another, -perhaps with common network testing tools like ``ping`` and ``tcpdump`` or more -specialized tools like Scapy. That's difficult with our simulated switch, -since it's not visible to the operating system. - -But our simulated switch has a few specialized testing tools. The most -powerful of these tools is ``ofproto/trace``. Given a switch and the -specification of a flow, ``ofproto/trace`` shows, step-by-step, how such a flow -would be treated as it goes through the switch. - -Example 1 -~~~~~~~~~ - -Try this command:: - - $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:05 - -The output should look something like this:: - - Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:05,dl_type=0x0000 - - bridge("br0") - ------------- - 0. dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0, priority 32768 - drop - - Final flow: unchanged - Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 - Datapath actions: drop - -The first line shows the flow being traced, in slightly greater detail -than specified on the command line. It is mostly zeros because -unspecified fields default to zeros. - -The second group of lines shows the packet's trip through bridge br0. -We see, in table 0, the OpenFlow flow that the fields matched, along -with its priority, followed by its actions, one per line. In this -case, we see that this packet that has a reserved multicast -destination address matches the flow that drops those packets. - -The final block of lines summarizes the results, which are not very -interesting here. - -Example 2 -~~~~~~~~~ - -Try another command:: - - $ ovs-appctl ofproto/trace br0 in_port=1,dl_dst=01:80:c2:00:00:10 - -The output should be:: - - Flow: in_port=1,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=01:80:c2:00:00:10,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. No match. - drop - - Final flow: unchanged - Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=01:80:c2:00:00:10/ff:ff:ff:ff:ff:f0,dl_type=0x0000 - Datapath actions: drop - -This time the flow we handed to ``ofproto/trace`` doesn't match any of -our "drop" flows in table 0, so it falls through to the low-priority -"resubmit" flow. The "resubmit" causes a second lookup in OpenFlow -table 1, described by the block of text that starts with "1." We -haven't yet added any flows to OpenFlow table 1, so no flow actually -matches in the second lookup. Therefore, the packet is still actually -dropped, which means that the externally observable results would be -identical to our first example. - -Implementing Table 1: VLAN Input Processing -------------------------------------------- - -A packet that enters table 1 has already passed basic validation in table 0. -The purpose of table 1 is validate the packet's VLAN, based on the VLAN -configuration of the switch port through which the packet entered the switch. -We will also use it to attach a VLAN header to packets that arrive on an access -port, which allows later processing stages to rely on the packet's VLAN always -being part of the VLAN header, reducing special cases. - -Let's start by adding a low-priority flow that drops all packets, before we add -flows that pass through acceptable packets. You can think of this as a -"default drop" flow:: - - $ ovs-ofctl add-flow br0 "table=1, priority=0, actions=drop" - -Our trunk port ``p1``, on OpenFlow port 1, is an easy case. ``p1`` accepts any -packet regardless of whether it has a VLAN header or what the VLAN was, so we -can add a flow that resubmits everything on input port 1 to the next table:: - - $ ovs-ofctl add-flow br0 \ - "table=1, priority=99, in_port=1, actions=resubmit(,2)" - -On the access ports, we want to accept any packet that has no VLAN header, tag -it with the access port's VLAN number, and then pass it along to the next -stage:: - - $ ovs-ofctl add-flows br0 - <<'EOF' - table=1, priority=99, in_port=2, vlan_tci=0, actions=mod_vlan_vid:20, resubmit(,2) - table=1, priority=99, in_port=3, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2) - table=1, priority=99, in_port=4, vlan_tci=0, actions=mod_vlan_vid:30, resubmit(,2) - EOF - -We don't write any flows that match packets with 802.1Q that enter this stage -on any of the access ports, so the "default drop" flow we added earlier causes -them to be dropped, which is ordinarily what we want for access ports. - -.. note:: - Another variation of access ports allows ingress of packets tagged with VLAN - 0 (aka 802.1p priority tagged packets). To allow such packets, replace - ``vlan_tci=0`` by ``vlan_tci=0/0xfff`` above. - -Testing Table 1 ---------------- - -``ofproto/trace`` allows us to test the ingress VLAN flows that we added above. - -Example 1: Packet on Trunk Port -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Here's a test of a packet coming in on the trunk port:: - - $ ovs-appctl ofproto/trace br0 in_port=1,vlan_tci=5 - -The output shows the lookup in table 0, the resubmit to table 1, and the -resubmit to table 2 (which does nothing because we haven't put anything there -yet):: - - Flow: in_port=1,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. in_port=1, priority 99 - resubmit(,2) - 2. No match. - drop - - Final flow: unchanged - Megaflow: recirc_id=0,in_port=1,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 - Datapath actions: drop - -Example 2: Valid Packet on Access Port -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Here's a test of a valid packet (a packet without an 802.1Q header) coming in -on access port ``p2``:: - - $ ovs-appctl ofproto/trace br0 in_port=2 - -The output is similar to that for the previous case, except that it -additionally tags the packet with ``p2``'s VLAN 20 before it passes it along to -table 2:: - - Flow: in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. in_port=2,vlan_tci=0x0000, priority 99 - mod_vlan_vid:20 - resubmit(,2) - 2. No match. - drop - - Final flow: in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 - Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 - Datapath actions: drop - -Example 3: Invalid Packet on Access Port -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -This tests an invalid packet (one that includes an 802.1Q header) coming in on -access port ``p2``:: - - $ ovs-appctl ofproto/trace br0 in_port=2,vlan_tci=5 - -The output shows the packet matching the default drop flow:: - - Flow: in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. priority 0 - drop - - Final flow: unchanged - Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0005,dl_src=00:00:00:00:00:00/01:00:00:00:00:00,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 - Datapath actions: drop - -Implementing Table 2: MAC+VLAN Learning for Ingress Port --------------------------------------------------------- - -This table allows the switch we're implementing to learn that the packet's -source MAC is located on the packet's ingress port in the packet's VLAN. - -.. note:: - This table is a good example why table 1 added a VLAN tag to packets that - entered the switch through an access port. We want to associate a MAC+VLAN - with a port regardless of whether the VLAN in question was originally part of - the packet or whether it was an assumed VLAN associated with an access port. - -It only takes a single flow to do this. The following command adds it:: - - $ ovs-ofctl add-flow br0 \ - "table=2 actions=learn(table=10, NXM_OF_VLAN_TCI[0..11], \ - NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[], \ - load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]), \ - resubmit(,3)" - -The "learn" action (an Open vSwitch extension to OpenFlow) modifies a flow -table based on the content of the flow currently being processed. Here's how -you can interpret each part of the "learn" action above: - -``table=10`` - Modify flow table 10. This will be the MAC learning table. - -``NXM_OF_VLAN_TCI[0..11]`` - Make the flow that we add to flow table 10 match the same VLAN ID that the - packet we're currently processing contains. This effectively scopes the - MAC learning entry to a single VLAN, which is the ordinary behavior for a - VLAN-aware switch. - -``NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[]`` - Make the flow that we add to flow table 10 match, as Ethernet destination, - the Ethernet source address of the packet we're currently processing. - -``load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]`` - Whereas the preceding parts specify fields for the new flow to match, this - specifies an action for the flow to take when it matches. The action is - for the flow to load the ingress port number of the current packet into - register 0 (a special field that is an Open vSwitch extension to OpenFlow). - -.. note:: - A real use of "learn" for MAC learning would probably involve two additional - elements. First, the "learn" action would specify a hard_timeout for the new - flow, to enable a learned MAC to eventually expire if no new packets were - seen from a given source within a reasonable interval. Second, one would - usually want to limit resource consumption by using the Flow_Table table in - the Open vSwitch configuration database to specify a maximum number of flows - in table 10. - -This definitely calls for examples. - -Testing Table 2 ---------------- - -Example 1 -~~~~~~~~~ - -Try the following test command:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,vlan_tci=20,dl_src=50:00:00:00:00:01 -generate - -The output shows that "learn" was executed in table 2 and the -particular flow that was added:: - - Flow: in_port=1,vlan_tci=0x0014,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. in_port=1, priority 99 - resubmit(,2) - 2. priority 32768 - learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]) - -> table=10 vlan_tci=0x0014/0x0fff,dl_dst=50:00:00:00:00:01 priority=32768 actions=load:0x1->NXM_NX_REG0[0..15] - resubmit(,3) - 3. No match. - drop - - Final flow: unchanged - Megaflow: recirc_id=0,in_port=1,vlan_tci=0x0014/0x1fff,dl_src=50:00:00:00:00:01,dl_dst=00:00:00:00:00:00/ff:ff:ff:ff:ff:f0,dl_type=0x0000 - Datapath actions: drop - -The ``-generate`` keyword is new. Ordinarily, ``ofproto/trace`` has no side -effects: "output" actions do not actually output packets, "learn" actions do -not actually modify the flow table, and so on. With ``-generate``, though, -``ofproto/trace`` does execute "learn" actions. That's important now, because -we want to see the effect of the "learn" action on table 10. You can see that -by running:: - - $ ovs-ofctl dump-flows br0 table=10 - -which (omitting the ``duration`` and ``idle_age`` fields, which will vary based -on how soon you ran this command after the previous one, as well as some other -uninteresting fields) prints something like:: - - NXST_FLOW reply (xid=0x4): - table=10, vlan_tci=0x0014/0x0fff,dl_dst=50:00:00:00:00:01 actions=load:0x1->NXM_NX_REG0[0..15] - -You can see that the packet coming in on VLAN ``20`` with source MAC -``50:00:00:00:00:01`` became a flow that matches VLAN ``20`` (written in -hexadecimal) and destination MAC ``50:00:00:00:00:01``. The flow loads port -number ``1``, the input port for the flow we tested, into register 0. - -Example 2 -~~~~~~~~~ - -Here's a second test command:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=2,dl_src=50:00:00:00:00:01 -generate - -The flow that this command tests has the same source MAC and VLAN as example 1, -although the VLAN comes from an access port VLAN rather than an 802.1Q header. -If we again dump the flows for table 10 with:: - - $ ovs-ofctl dump-flows br0 table=10 - -then we see that the flow we saw previously has changed to indicate that the -learned port is port 2, as we would expect:: - - NXST_FLOW reply (xid=0x4): - table=10, vlan_tci=0x0014/0x0fff,dl_dst=50:00:00:00:00:01 actions=load:0x2->NXM_NX_REG0[0..15] - -Implementing Table 3: Look Up Destination Port ----------------------------------------------- - -This table figures out what port we should send the packet to based on the -destination MAC and VLAN. That is, if we've learned the location of the -destination (from table 2 processing some previous packet with that destination -as its source), then we want to send the packet there. - -We need only one flow to do the lookup:: - - $ ovs-ofctl add-flow br0 \ - "table=3 priority=50 actions=resubmit(,10), resubmit(,4)" - -The flow's first action resubmits to table 10, the table that the "learn" -action modifies. As you saw previously, the learned flows in this table write -the learned port into register 0. If the destination for our packet hasn't -been learned, then there will be no matching flow, and so the "resubmit" turns -into a no-op. Because registers are initialized to 0, we can use a register 0 -value of 0 in our next pipeline stage as a signal to flood the packet. - -The second action resubmits to table 4, continuing to the next pipeline stage. - -We can add another flow to skip the learning table lookup for multicast and -broadcast packets, since those should always be flooded:: - - $ ovs-ofctl add-flow br0 \ - "table=3 priority=99 dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 \ - actions=resubmit(,4)" - -.. note:: - We don't strictly need to add this flow, because multicast addresses will - never show up in our learning table. (In turn, that's because we put a flow - into table 0 to drop packets that have a multicast source address.) - -Testing Table 3 ---------------- - -Example -~~~~~~~ - -Here's a command that should cause OVS to learn that ``f0:00:00:00:00:01`` is -on ``p1`` in VLAN ``20``:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01 \ - -generate - -The output shows (from the "no match" looking up the resubmit to -table 10) that the flow's destination was unknown:: - - Flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. in_port=1, priority 99 - resubmit(,2) - 2. priority 32768 - learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]) - -> table=10 vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01 priority=32768 actions=load:0x1->NXM_NX_REG0[0..15] - resubmit(,3) - 3. priority 50 - resubmit(,10) - 10. No match. - drop - resubmit(,4) - 4. No match. - drop - - Final flow: unchanged - Megaflow: recirc_id=0,in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 - Datapath actions: drop - -There are two ways that you can verify that the packet's source was -learned. The most direct way is to dump the learning table with:: - - $ ovs-ofctl dump-flows br0 table=10 - -which ought to show roughly the following, with extraneous details removed:: - - table=10, vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01 actions=load:0x1->NXM_NX_REG0[0..15] - -.. note:: - If you tried the examples for the previous step, or if you did some of your - own experiments, then you might see additional flows there. These - additional flows are harmless. If they bother you, then you can remove - them with `ovs-ofctl del-flows br0 table=10`. - -The other way is to inject a packet to take advantage of the learning entry. -For example, we can inject a packet on p2 whose destination is the MAC address -that we just learned on p1:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=2,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01 -generate - -Here is this command's output. Take a look at the lines that trace -the ``resubmit(,10)``, showing that the packet matched the learned -flow for the first MAC we used, loading the OpenFlow port number for -the learned port ``p1`` into register ``0``:: - - Flow: in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. in_port=2,vlan_tci=0x0000, priority 99 - mod_vlan_vid:20 - resubmit(,2) - 2. priority 32768 - learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]) - -> table=10 vlan_tci=0x0014/0x0fff,dl_dst=90:00:00:00:00:01 priority=32768 actions=load:0x2->NXM_NX_REG0[0..15] - resubmit(,3) - 3. priority 50 - resubmit(,10) - 10. vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01, priority 32768 - load:0x1->NXM_NX_REG0[0..15] - resubmit(,4) - 4. No match. - drop - - Final flow: reg0=0x1,in_port=2,dl_vlan=20,dl_vlan_pcp=0,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 - Megaflow: recirc_id=0,in_port=2,vlan_tci=0x0000,dl_src=90:00:00:00:00:01,dl_dst=f0:00:00:00:00:01,dl_type=0x0000 - Datapath actions: drop - -If you read the commands above carefully, then you might have noticed that they -simply have the Ethernet source and destination addresses exchanged. That -means that if we now rerun the first ``ovs-appctl`` command above, e.g.:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_vlan=20,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01 \ - -generate - -then we see in the output, looking at the indented "load" action -executed in table 10, that the destination has now been learned:: - - Flow: in_port=1,dl_vlan=20,dl_vlan_pcp=0,dl_src=f0:00:00:00:00:01,dl_dst=90:00:00:00:00:01,dl_type=0x0000 - - bridge("br0") - ------------- - 0. priority 0 - resubmit(,1) - 1. in_port=1, priority 99 - resubmit(,2) - 2. priority 32768 - learn(table=10,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:NXM_OF_IN_PORT[]->NXM_NX_REG0[0..15]) - -> table=10 vlan_tci=0x0014/0x0fff,dl_dst=f0:00:00:00:00:01 priority=32768 actions=load:0x1->NXM_NX_REG0[0..15] - resubmit(,3) - 3. priority 50 - resubmit(,10) - 10. vlan_tci=0x0014/0x0fff,dl_dst=90:00:00:00:00:01, priority 32768 - load:0x2->NXM_NX_REG0[0..15] - resubmit(,4) - 4. No match. - drop - - -Implementing Table 4: Output Processing ---------------------------------------- - -At entry to stage 4, we know that register 0 contains either the desired output -port or is zero if the packet should be flooded. We also know that the -packet's VLAN is in its 802.1Q header, even if the VLAN was implicit because -the packet came in on an access port. - -The job of the final pipeline stage is to actually output packets. The job is -trivial for output to our trunk port ``p1``:: - - $ ovs-ofctl add-flow br0 "table=4 reg0=1 actions=1" - -For output to the access ports, we just have to strip the VLAN header before -outputting the packet:: - - $ ovs-ofctl add-flows br0 - <<'EOF' - table=4 reg0=2 actions=strip_vlan,2 - table=4 reg0=3 actions=strip_vlan,3 - table=4 reg0=4 actions=strip_vlan,4 - EOF - -The only slightly tricky part is flooding multicast and broadcast packets and -unicast packets with unlearned destinations. For those, we need to make sure -that we only output the packets to the ports that carry our packet's VLAN, and -that we include the 802.1Q header in the copy output to the trunk port but not -in copies output to access ports:: - - $ ovs-ofctl add-flows br0 - <<'EOF' - table=4 reg0=0 priority=99 dl_vlan=20 actions=1,strip_vlan,2 - table=4 reg0=0 priority=99 dl_vlan=30 actions=1,strip_vlan,3,4 - table=4 reg0=0 priority=50 actions=1 - EOF - -.. note:: - Our flows rely on the standard OpenFlow behavior that an output action will - not forward a packet back out the port it came in on. That is, if a packet - comes in on p1, and we've learned that the packet's destination MAC is also - on p1, so that we end up with ``actions=1`` as our actions, the switch will - not forward the packet back out its input port. The - multicast/broadcast/unknown destination cases above also rely on this - behavior. - -Testing Table 4 ---------------- - -Example 1: Broadcast, Multicast, and Unknown Destination -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Try tracing a broadcast packet arriving on ``p1`` in VLAN ``30``:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_vlan=30 - -The interesting part of the output is the final line, which shows that the -switch would remove the 802.1Q header and then output the packet to ``p3`` -and ``p4``, which are access ports for VLAN ``30``:: - - Datapath actions: pop_vlan,3,4 - -Similarly, if we trace a broadcast packet arriving on ``p3``:: - - $ ovs-appctl ofproto/trace br0 in_port=3,dl_dst=ff:ff:ff:ff:ff:ff - -then we see that it is output to ``p1`` with an 802.1Q tag and then to ``p4`` -without one:: - - Datapath actions: push_vlan(vid=30,pcp=0),1,pop_vlan,4 - -.. note:: - Open vSwitch could simplify the datapath actions here to just - ``4,push_vlan(vid=30,pcp=0),1`` but it is not smart enough to do so. - -The following are also broadcasts, but the result is to drop the packets -because the VLAN only belongs to the input port:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_dst=ff:ff:ff:ff:ff:ff - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_vlan=55 - -Try some other broadcast cases on your own:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_dst=ff:ff:ff:ff:ff:ff,dl_vlan=20 - $ ovs-appctl ofproto/trace br0 \ - in_port=2,dl_dst=ff:ff:ff:ff:ff:ff - $ ovs-appctl ofproto/trace br0 \ - in_port=4,dl_dst=ff:ff:ff:ff:ff:ff - -You can see the same behavior with multicast packets and with unicast -packets whose destination has not been learned, e.g.:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=4,dl_dst=01:00:00:00:00:00 - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_dst=90:12:34:56:78:90,dl_vlan=20 - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_dst=90:12:34:56:78:90,dl_vlan=30 - -Example 2: MAC Learning -~~~~~~~~~~~~~~~~~~~~~~~ - -Let's follow the same pattern as we did for table 3. First learn a MAC on port -``p1`` in VLAN ``30``:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_vlan=30,dl_src=10:00:00:00:00:01,dl_dst=20:00:00:00:00:01 \ - -generate - -You can see from the last line of output that the packet's destination is -unknown, so it gets flooded to both ``p3`` and ``p4``, the other ports in VLAN -``30``:: - - Datapath actions: pop_vlan,3,4 - -Then reverse the MACs and learn the first flow's destination on port ``p4``:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=4,dl_src=20:00:00:00:00:01,dl_dst=10:00:00:00:00:01 -generate - -The last line of output shows that the this packet's destination is known to be -``p1``, as learned from our previous command:: - - Datapath actions: push_vlan(vid=30,pcp=0),1 - -Now, if we rerun our first command:: - - $ ovs-appctl ofproto/trace br0 \ - in_port=1,dl_vlan=30,dl_src=10:00:00:00:00:01,dl_dst=20:00:00:00:00:01 \ - -generate - -...we can see that the result is no longer a flood but to the specified learned -destination port ``p4``:: - - Datapath actions: pop_vlan,4 - -Contact -======= - -bugs@openvswitch.org -http://openvswitch.org/ diff --git a/Documentation/tutorials/ovs-conntrack.rst b/Documentation/tutorials/ovs-conntrack.rst deleted file mode 100644 index 27d6e04c3..000000000 --- a/Documentation/tutorials/ovs-conntrack.rst +++ /dev/null @@ -1,572 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -====================== -OVS Conntrack Tutorial -====================== - -OVS can be used with the Connection tracking system -where OpenFlow flow can be used to match on the state of a TCP, UDP, ICMP, -etc., connections. (Connection tracking system supports tracking of both -statefull and stateless protocols) - -This tutorial demonstrates how OVS can use the connection tracking system -to match on the TCP segments from connection setup to connection tear down. -It will use OVS with the Linux kernel module as the datapath for this -tutorial. (The datapath that utilizes the openvswitch kernel module to do -the packet processing in the Linux kernel) -It was tested with the “master” branch of Open vSwitch. - -Definitions ------------ - -**conntrack**: is a connection tracking module for stateful packet -inspection. - -**pipeline**: is the packet processing pipeline which is the path taken by -the packet when traversing through the tables where the packet matches the -match fields of a flow in the table and performs the actions present in -the matched flow. - -**network namespace**: is a way to create virtual routing domains within -a single instance of linux kernel. Each network namespace has it's own -instance of network tables (arp, routing) and certain interfaces attached -to it. - -**flow**: used in this tutorial refers to the OpenFlow flow which can be -programmed using an OpenFlow controller or OVS command line tools like -ovs-ofctl which is used here. A flow will have match fields and actions. - -Conntrack Related Fields ------------------------- - -Match Fields -~~~~~~~~~~~~ -OVS supports following match fields related to conntrack: - -1. **ct_state**: -The state of a connection matching the packet. -Possible values: - - - *new* - - *est* - - *rel* - - *rpl* - - *inv* - - *trk* - - *snat* - - *dnat* - -Each of these flags is preceded by either a "+" for a flag that -must be set, or a "-" for a flag that must be unset. -Multiple flags can also be specified e.g. ct_state=+trk+new. -We will see the usage of some of these flags below. For a detailed -description, please see the OVS fields documentation at: -http://openvswitch.org/support/dist-docs/ovs-fields.7.txt - -2. **ct_zone**: A zone is an independent connection tracking context which can -be set by a ct action. -A 16-bit ct_zone set by the most recent ct action (by an OpenFlow -flow on a conntrack entry) can be used as a match field in -another flow entry. - -3. **ct_mark**: -The 32-bit metadata committed, by an action within the exec -parameter to the ct action, to the connection to which the -current packet belongs. - -4. **ct_label**: -The 128-bit label committed by an action within the exec parameter to -the ct action, to the connection to which the current packet -belongs. - -5. **ct_nw_src** / **ct_ipv6_src**: -Matches IPv4/IPv6 conntrack original direction tuple -source address. - -6. **ct_nw_dst** / **ct_ipv6_dst**: -Matches IPv4/IPv6 conntrack original direction tuple destination address. - -7. **ct_nw_proto**: -Matches conntrack original direction tuple IP protocol type. - -8. **ct_tp_src**: -Matches on the conntrack original direction tuple -transport source port. - -9. **ct_tp_dst**: -Matches on the conntrack original direction tuple -transport destination port. - - -Actions -~~~~~~~ -OVS supports "ct" action related to conntrack. - -*ct([argument][,argument...])* - -The **ct** action sends the packet through the connection tracker. - -The following arguments are supported: - -1. **commit**: -Commit the connection to the connection tracking module which -will be stored beyond the lifetime of packet in the pipeline. - -2. **force**: -The force flag may be used in addition to commit flag to effectively -terminate the existing connection and start a new one in the -current direction. - -3. **table=number**: -Fork pipeline processing in two. The original instance of the packet -will continue processing the current actions list as an untracked packet. -An additional instance of the packet will be sent to the connection -tracker, which will be re-injected into the OpenFlow pipeline to resume -processing in table number, with the ct_state and other ct match fields set. - -4. **zone=value OR -zone=src[start..end]**: -A 16-bit context id that can be used to isolate connections into separate -domains, allowing over‐lapping network addresses in different zones. If a -zone is not provided, then the default is to use zone zero. - -5. **exec([action][,action...])**: -Perform restricted set of actions within the context of connection tracking. -Only actions which modify the *ct_mark* or *ct_label* fields are accepted -within the exec action. - -6. **alg=**: -Specify alg (application layer gateway) to track specific connection -types. - -7. **nat**: -Specifies the address and port translation for the connection being tracked. - - - -Sample Topology ---------------- -This tutorial uses the following topology to carry out the tests. - -:: - - + + - | | - | +-----+ | - | | | | - | | | | - | +----------+ | OVS | +----------+ | - | | left | | | | right | | - | | namespace| | | |namespace | | - +-----+ A +------+ +-----+ B +--------+ - | | | A'| | B' | | | - | | | | | | | | - | +----------+ | | +----------+ | - | | | | - | | | | - | | | | - | +-----+ | - | | - | | - + + - 192.168.0.X n/w 10.0.0.X n/w - - A = veth_l1 - A' = veth_l0 - B = veth_r1 - B' = veth_r0 - - Diagram: Sample Topology for conntrack testing - - -The steps for creation of the setup are mentioned below. - -Create "left" network namespace:: - - $ ip netns add left - -Create "right" network namespace:: - - $ ip netns add right - -Create first pair of veth interfaces:: - - $ ip link add veth_l0 type veth peer name veth_l1 - -Add veth_l1 to "left" network namespace:: - - $ ip link set veth_l1 netns left - -Create second pair of veth interfaces:: - - $ ip link add veth_r0 type veth peer name veth_r1 - -Add veth_r1 to "right" network namespace:: - - $ ip link set veth_r1 netns right - -Create a bridge br0:: - - $ ovs-vsctl add-br br0 - -Add veth_l0 and veth_r0 to br0:: - - $ ovs-vsctl add-port br0 veth_l0 - $ ovs-vsctl add-port br0 veth_r0 - - -Packets generated with src/dst IP set to 192.168.0.X / 10.0.0.X -in the "left" and the inverse in the "right" namespaces -will appear to OVS as hosts in two networks (192.168.0.X and 10.0.0.X) -communicating with each other. -This is basically a simulation of two networks / subnets with hosts -communicating with each other with OVS in middle. - -Tool used to generate TCP segments ----------------------------------- -You can use scapy to generate the TCP segments. We used scapy on Ubuntu 16.04 -for the steps carried out in this testing. -(Installation of scapy is not discussed and is out of scope of this document.) - -You can keep two scapy sessions active on each of the namespaces:: - - $ sudo ip netns exec left sudo `which scapy` - - $ sudo ip netns exec right sudo `which scapy` - -Note: In case you encounter this error:: - - ifreq = ioctl(s, SIOCGIFADDR,struct.pack("16s16x",LOOPBACK_NAME)) - - IOError: [Errno 99] Cannot assign requested address - -run the command:: - - $ sudo ip netns exec sudo ip link set lo up - - -Matching TCP packets --------------------- - -TCP Connection setup -~~~~~~~~~~~~~~~~~~~~ -Two simple flows can be added in OVS which will forward -packets from "left" to "right" and from "right" to "left":: - - $ ovs-ofctl add-flow br0 \ - "table=0, priority=10, in_port=veth_l0, actions=veth_r0" - - $ ovs-ofctl add-flow br0 \ - "table=0, priority=10, in_port=veth_r0, actions=veth_l0" - -Instead of adding these two flows, we will add flows to match on the -states of the TCP segments. - -We will send the TCP connection setup segments namely: -syn, syn-ack and ack between hosts 192.168.0.2 in the "left" namespace and -10.0.0.2 in the "right" namespace. - -First, let's add a flow to start "tracking" a packet received at OVS. - -*How do we start tracking a packet?* - -To start tracking a packet, it first needs to match a flow, which has action -as "ct". This action sends the packet through the connection tracker. To -identify that a packet is an "untracked" packet, the ct_state in the flow -match field must be set to "-trk", which means it is not a tracked packet. -Once the packet is sent to the connection tracker, then only we will know about -its conntrack state. (i.e. whether this packet represents start of a new -connection or the packet belongs to an existing connection or it is -a malformed packet and so on.) - -Let's add that flow:: - - (flow #1) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=-trk, tcp, in_port=veth_l0, actions=ct(table=0)" - -A TCP syn packet sent from "left" namespace will match flow #1 -because the packet is coming to OVS from veth_l0 port and it is not being -tracked. (as the packet just entered OVS. All packets entering OVS for the -first time are "untracked") -The flow will send the packet to the connection tracker due to the action "ct". -Also "table=0" in the "ct" action forks the pipeline processing in two. The -original instance of packet will continue processing the current action list -as untracked packet. (Since there are no actions after this, the original -packet gets dropped.) -The forked instance of the packet will be sent to the connection tracker, -which will be re-injected into the OpenFlow pipeline to resume processing -in table number, with the ct_state and other ct match fields set. -In this case, the packet with the ct_state and other ct match fields comes back -to table 0. - -Next, we add a flow to match on the packet coming back from conntrack:: - - (flow #2) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=+trk+new, tcp, in_port=veth_l0, actions=ct(commit),veth_r0" - -Now that the packet is coming back from conntrack, the ct_state would have -the "trk" set. -Also, if this is the first packet of the TCP connection, the ct_state "new" -would be set. (Which is the condition here as there does not exist any TCP -connection between hosts 192.168.0.2 and 10.0.0.2) -The ct argument "commit" will commit the connection to the connection tracking -module. The significance of this action is that the information about the -connection will now be stored beyond the lifetime of the packet in the -pipeline. - -Let's send the TCP syn segment using scapy (at the "left" scapy session) -(flags=0x02 is syn):: - - $ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x02, seq=100), iface="veth_l1") - -This packet will match flow #1 and flow #2. - -The conntrack module will now have an entry for this connection:: - - $ ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2" - tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=SYN_SENT) - - -Note: At this stage, if the TCP syn packet is re-transmitted, it will again -match flow #1 (since a new packet is untracked) and it will match flow #2. -The reason it will match flow #2 is that although conntrack has information -about the connection, but it is not in "ESTABLISHED" state, therefore it -matches the "new" state again. - -Next for the TCP syn-ack from the opposite/server direction, we need -following flows at OVS:: - - (flow #3) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=-trk, tcp, in_port=veth_r0, actions=ct(table=0)" - (flow #4) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_r0, actions=veth_l0" - - -flow #3 matches untracked packets coming back from server (10.0.0.2) and sends -this to conntrack. (Alternatively, we could have also combined -flow #1 and flow #3 into one flow by not having the "in_port" match) - -The syn-ack packet which has now gone through the conntrack has the ct_state of -"est". - -Note: Conntrack puts the ct_state of the connection to "est" state when -it sees bidirectional traffic, but till it does not get the third ack from -client, it puts a short cleanup timer on the conntrack entry. - -Sending TCP syn-ack segment using scapy (at the "right" scapy session) -(flags=0x12 is ack and syn):: - - $ >>> sendp(Ether()/IP(src="10.0.0.2", dst="192.168.0.2")/TCP(sport=2048, dport=1024, flags=0x12, seq=200, ack=101), iface="veth_r1") - -This packet will match flow #3 and flow #4. - -conntrack entry:: - - $ ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2" - - tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=ESTABLISHED) - -The conntrack state is "ESTABLISHED" on receiving just syn and syn-ack packets, -but at this point if it does not receive the third ack (from client), the -connection gets cleared up from conntrack quickly. - -Next, for a TCP ack from client direction, we can add following flows to -match on the packet:: - - (flow #5) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_l0, actions=veth_r0" - -Send the third TCP ack segment using scapy (at the "left" scapy session) -(flags=0x10 is ack):: - - $ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x10, seq=101, ack=201), iface="veth_l1") - -This packet will match on flow #1 and flow #5. - - -conntrack entry:: - - $ ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2" - - tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048), \ - reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024), \ - protoinfo=(state=ESTABLISHED) - -The conntrack state stays in "ESTABLISHED" state, but now since it has received -the ack from client, it will stay in this state for a longer time even without -receiving any data on this connection. - -TCP Data -~~~~~~~~ -When a data segment, carrying one byte of TCP payload, is sent from -192.168.0.2 to 10.0.0.2, the packet carrying the segment would hit flow #1 -and then flow #5. - -Send a TCP segment with one byte data using scapy -(at the "left" scapy session) -(flags=0x10 is ack):: - - $ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x10, seq=101, ack=201)/"X", iface="veth_l1") - - -Send the TCP ack for the above segment using scapy (at the -"right" scapy session) -(flags=0x10 is ack):: - - $ >>> sendp(Ether()/IP(src="10.0.0.2", dst="192.168.0.2")/TCP(sport=2048, dport=1024, flags=0X10, seq=201, ack=102), iface="veth_r1") - -The acknowledgement for the data would hit flow #3 and flow #4. - -TCP Connection Teardown -~~~~~~~~~~~~~~~~~~~~~~~ -There are different ways to tear down TCP connection. We will tear down the -connection by sending "fin" from client, "fin-ack" from server followed -by the last "ack" by client. - -All the packets from client to server would hit flow #1 and flow #5. -All the packets from server to client would hit flow #3 and flow #4. -Interesting point to note is that even when the TCP connection is going -down, all the packets (which are actually tearing down the connection) still -hits "+est" state. A packet, for which the conntrack -entry *is* or *was* in "ESTABLISHED" state, would continue to match -"+est" ct_state in OVS. - -Note: In fact, when the conntrack connection state is in "TIME_WAIT" state -(after all the TCP fins and their acks are exchanged), -a re-transmitted data packet (from 192.168.0.2 -> 10.0.0.2), still hits -flows #1 and #5. - -Sending TCP fin segment using scapy (at the "left" scapy session) -(flags=0x11 is ack and fin):: - - $ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x11, seq=102, ack=201), iface="veth_l1") - -This packet hits flow #1 and flow #5. - -conntrack entry:: - - $ sudo ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2" - - tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=FIN_WAIT_1) - - -Sending TCP fin-ack segment using scapy (at the "right" scapy session) -(flags=0x11 is ack and fin):: - - $ >>> sendp(Ether()/IP(src="10.0.0.2", dst="192.168.0.2")/TCP(sport=2048, dport=1024, flags=0X11, seq=201, ack=103), iface="veth_r1") - -This packet hits flow #3 and flow #4. - -conntrack entry:: - - $ sudo ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2" - - tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=LAST_ACK) - - -Sending TCP ack segment using scapy (at the "left" scapy session) -(flags=0x10 is ack):: - - $ >>> sendp(Ether()/IP(src="192.168.0.2", dst="10.0.0.2")/TCP(sport=1024, dport=2048, flags=0x10, seq=103, ack=202), iface="veth_l1") - -This packet hits flow #1 and flow #5. - -conntrack entry:: - - $ sudo ovs-appctl dpctl/dump-conntrack | grep "192.168.0.2" - - tcp,orig=(src=192.168.0.2,dst=10.0.0.2,sport=1024,dport=2048),reply=(src=10.0.0.2,dst=192.168.0.2,sport=2048,dport=1024),protoinfo=(state=TIME_WAIT) - - -Summary -------- - -Following table summarizes the TCP segments exchanged against the flow -match fields - - +-------------------------------------------------------+-------------------+ - | TCP Segment |ct_state(flow#) | - +=======================================================+===================+ - | **Connection Setup** | | - +-------------------------------------------------------+-------------------+ - |192.168.0.2 → 10.0.0.2 [SYN] Seq=0 | -trk(#1) then | - | | +trk+new(#2) | - +-------------------------------------------------------+-------------------+ - |10.0.0.2 → 192.168.0.2 [SYN, ACK] Seq=0 Ack=1 | -trk(#3) then | - | | +trk+est(#4) | - +-------------------------------------------------------+-------------------+ - |192.168.0.2 → 10.0.0.2 [ACK] Seq=1 Ack=1 | -trk(#1) then | - | | +trk+est(#5) | - +-------------------------------------------------------+-------------------+ - | **Data Transfer** | | - +-------------------------------------------------------+-------------------+ - |192.168.0.2 → 10.0.0.2 [ACK] Seq=1 Ack=1 | -trk(#1) then | - | | +trk+est(#5) | - +-------------------------------------------------------+-------------------+ - |10.0.0.2 → 192.168.0.2 [ACK] Seq=1 Ack=2 | -trk(#3) then | - | | +trk+est(#4) | - +-------------------------------------------------------+-------------------+ - | **Connection Teardown** | | - +-------------------------------------------------------+-------------------+ - |192.168.0.2 → 10.0.0.2 [FIN, ACK] Seq=2 Ack=1 | -trk(#1) then | - | | +trk+est(#5) | - +-------------------------------------------------------+-------------------+ - |10.0.0.2 → 192.168.0.2 [FIN, ACK] Seq=1 Ack=3 | -trk(#3) then | - | | +trk+est(#4) | - +-------------------------------------------------------+-------------------+ - |192.168.0.2 → 10.0.0.2 [ACK] Seq=3 Ack=2 | -trk(#1) then | - | | +trk+est(#5) | - +-------------------------------------------------------+-------------------+ - -Note: Relative sequence number and acknowledgement numbers are shown as -captured from tshark. - -Flows -~~~~~ -:: - - (flow #1) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=-trk, tcp, in_port=veth_l0, actions=ct(table=0)" - - (flow #2) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=+trk+new, tcp, in_port=veth_l0, actions=ct(commit),veth_r0" - - (flow #3) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=-trk, tcp, in_port=veth_r0, actions=ct(table=0)" - - (flow #4) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_r0, actions=veth_l0" - - (flow #5) - $ ovs-ofctl add-flow br0 \ - "table=0, priority=50, ct_state=+trk+est, tcp, in_port=veth_l0, actions=veth_r0" From patchwork Wed Jun 12 07:19:11 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Numan Siddique X-Patchwork-Id: 1114325 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45Nywl5DH5z9s9y for ; Wed, 12 Jun 2019 17:21:43 +1000 (AEST) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 88A84160D; Wed, 12 Jun 2019 07:20:51 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E18A915EA for ; Wed, 12 Jun 2019 07:19:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E7A37F8 for ; Wed, 12 Jun 2019 07:19:21 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6BBEB7FDF0 for ; Wed, 12 Jun 2019 07:19:20 +0000 (UTC) Received: from nusiddiq.mac (unknown [10.74.10.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA6611001B03 for ; Wed, 12 Jun 2019 07:19:18 +0000 (UTC) From: nusiddiq@redhat.com To: dev@openvswitch.org Date: Wed, 12 Jun 2019 12:49:11 +0530 Message-Id: <20190612071911.24340-1-nusiddiq@redhat.com> In-Reply-To: <20190612071822.24182-1-nusiddiq@redhat.com> References: <20190612071822.24182-1-nusiddiq@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 12 Jun 2019 07:19:20 +0000 (UTC) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [ovs-dev] [PATCH ovn 2/4] Documentation cleanup: ref section X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org From: Numan Siddique Signed-off-by: Numan Siddique Acked-by: Ben Pfaff --- Documentation/automake.mk | 2 - Documentation/conf.py | 4 - .../contributing/documentation-style.rst | 2 +- Documentation/ref/index.rst | 106 ------------ Documentation/ref/ovs-test.8.rst | 163 ------------------ Documentation/ref/ovs-vlan-test.8.rst | 113 ------------ 6 files changed, 1 insertion(+), 389 deletions(-) delete mode 100644 Documentation/ref/ovs-test.8.rst delete mode 100644 Documentation/ref/ovs-vlan-test.8.rst diff --git a/Documentation/automake.mk b/Documentation/automake.mk index 181a69cab..c3b0949bd 100644 --- a/Documentation/automake.mk +++ b/Documentation/automake.mk @@ -107,8 +107,6 @@ endif # rST formatted manpages under Documentation/ref. RST_MANPAGES = \ - ovs-test.8.rst \ - ovs-vlan-test.8.rst \ ovsdb-server.7.rst \ ovsdb.5.rst \ ovsdb.7.rst diff --git a/Documentation/conf.py b/Documentation/conf.py index 0a61dc3f3..6bf528bde 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -116,10 +116,6 @@ html_static_path = ['_static'] _man_pages = [ ('ovs-sim.1', u'Open vSwitch simulator environment'), - ('ovs-test.8', - u'Check Linux drivers for performance, vlan and L3 tunneling problems'), - ('ovs-vlan-test.8', - u'Check Linux drivers for problems with vlan traffic'), ('ovsdb-server.7', u'Open vSwitch Database Server Protocol'), ('ovsdb.5', diff --git a/Documentation/internals/contributing/documentation-style.rst b/Documentation/internals/contributing/documentation-style.rst index deb07d9f5..0b67ae2aa 100644 --- a/Documentation/internals/contributing/documentation-style.rst +++ b/Documentation/internals/contributing/documentation-style.rst @@ -347,7 +347,7 @@ In addition to the above, man pages have some specific requirements: - The man page must be included in the list of man page documents found in `conf.py`__ -Refer to existing man pages, such as :doc:`/ref/ovs-vlan-test.8` for a worked +Refer to existing man pages, such as :doc:`/ref/ovsdb-server.7` for a worked example. __ http://www.sphinx-doc.org/en/stable/domains.html#directive-program diff --git a/Documentation/ref/index.rst b/Documentation/ref/index.rst index 0a80a5f41..f85b13991 100644 --- a/Documentation/ref/index.rst +++ b/Documentation/ref/index.rst @@ -40,8 +40,6 @@ time: :maxdepth: 3 ovs-sim.1 - ovs-test.8 - ovs-vlan-test.8 ovsdb-server.7 ovsdb.5 ovsdb.7 @@ -50,10 +48,6 @@ The remainder are still in roff format can be found below: .. list-table:: - * - ovs-actions(7) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ * - ovn-architecture(7) - `(pdf) `__ - `(html) `__ @@ -94,103 +88,3 @@ The remainder are still in roff format can be found below: - `(pdf) `__ - `(html) `__ - `(plain text) `__ - * - ovs-appctl(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-bugtool(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-ctl(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovsdb-client(1) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovsdb-server(1) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovsdb-tool(1) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-dpctl(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-dpctl-top(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-fields(7) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-l3ping(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-ofctl(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-parse-backtrace(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-pcap(1) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-pki(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-tcpdump(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-tcpundump(1) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-test(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-testcontroller(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-vlan-bug-workaround(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-vlan-test(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-vsctl(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-vswitchd(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - ovs-vswitchd.conf.db(5) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - vtep(5) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ - * - vtep-ctl(8) - - `(pdf) `__ - - `(html) `__ - - `(plain text) `__ diff --git a/Documentation/ref/ovs-test.8.rst b/Documentation/ref/ovs-test.8.rst deleted file mode 100644 index f902d9c3b..000000000 --- a/Documentation/ref/ovs-test.8.rst +++ /dev/null @@ -1,163 +0,0 @@ -======== -ovs-test -======== - -Synopsis -======== - -**ovs-test** -s *port* - -**ovs-test** -c *server1* *server2* [**-b** *targetbandwidth*] [**-i** *testinterval*] [**-d**] - [**-l** *vlantag*] [**-t** *tunnelmodes*] - -Description -=========== - -The :program:`ovs-test` program may be used to check for problems sending -802.1Q or GRE traffic that Open vSwitch may uncover. These problems, for -example, can occur when Open vSwitch is used to send 802.1Q traffic through -physical interfaces running certain drivers of certain Linux kernel versions. -To run a test, configure IP addresses on `server1` and `server2` for interfaces -you intended to test. These interfaces could also be already configured OVS -bridges that have a physical interface attached to them. Then, on one of the -nodes, run :program:`ovs-test` in server mode and on the other node run it in -client mode. The client will connect to :program:`ovs-test` server and schedule -tests between both of them. The :program:`ovs-test` client will perform UDP and -TCP tests. - -UDP tests can report packet loss and achieved bandwidth for various datagram -sizes. By default target bandwidth for UDP tests is 1Mbit/s. - -TCP tests report only achieved bandwidth, because kernel TCP stack takes care -of flow control and packet loss. TCP tests are essential to detect potential -TSO related issues. - -To determine whether Open vSwitch is encountering any problems, the user must -compare packet loss and achieved bandwidth in a setup where traffic is being -directly sent and in one where it is not. If in the 802.1Q or L3 tunneled tests -both :program:`ovs-test` processes are unable to communicate or the achieved -bandwidth is much lower compared to direct setup, then, most likely, Open -vSwitch has encountered a pre-existing kernel or driver bug. - -Some examples of the types of problems that may be encountered are: - -- When NICs use VLAN stripping on receive they must pass a pointer to a - `vlan_group` when reporting the stripped tag to the networking core. If no - `vlan_group` is in use then some drivers just drop the extracted tag. - Drivers are supposed to only enable stripping if a `vlan_group` is registered - but not all of them do that. - -- On receive, some drivers handle priority tagged packets specially and don't - pass the tag onto the network stack at all, so Open vSwitch never has a - chance to see it. - -- Some drivers size their receive buffers based on whether a `vlan_group` is - enabled, meaning that a maximum size packet with a VLAN tag will not fit if - no `vlan_group` is configured. - -- On transmit, some drivers expect that VLAN acceleration will be used if it is - available, which can only be done if a `vlan_group` is configured. In these - cases, the driver may fail to parse the packet and correctly setup checksum - offloading or TSO. - -Client Mode - An :program:`ovs-test` client will connect to two :program:`ovs-test` servers - and will ask them to exchange test traffic. It is also possible to spawn an - :program:`ovs-test` server automatically from the client. - -Server Mode - To conduct tests, two :program:`ovs-test` servers must be running on two - different hosts where the client can connect. The actual test traffic is - exchanged only between both :program:`ovs-test` servers. It is recommended - that both servers have their IP addresses in the same subnet, otherwise one - would have to make sure that routing is set up correctly. - -Options -======= - -.. program:: ovs-test - -.. option:: -s , --server - - Run in server mode and wait for the client to establish XML RPC Control - Connection on this TCP port. It is recommended to have `ethtool(8)` - installed on the server so that it could retrieve information about the NIC - driver. - -.. option:: -c , --client - - Run in client mode and schedule tests between `server1` and `server2`, - where each server must be given in the following format:: - - OuterIP[:OuterPort],InnerIP[/Mask][:InnerPort]. - - The `OuterIP` must be already assigned to the physical interface which is - going to be tested. This is the IP address where client will try to - establish XML RPC connection. If `OuterIP` is 127.0.0.1 then client will - automatically spawn a local instance of :program:`ovs-test` server. - OuterPort is TCP port where server is listening for incoming XML/RPC - control connections to schedule tests (by default it is 15531). The - :program:`ovs-test` will automatically assign `InnerIP[/Mask]` to the - interfaces that will be created on the fly for testing purposes. It is - important that `InnerIP[/Mask]` does not interfere with already existing IP - addresses on both :program:`ovs-test` servers and client. InnerPort is port - which will be used by server to listen for test traffic that will be - encapsulated (by default it is 15532). - -.. option:: -b , --bandwidth - - Target bandwidth for UDP tests. The targetbandwidth must be given in bits - per second. It is possible to use postfix `M` or `K` to alter the target - bandwidth magnitude. - -.. option:: -i , --interval - - How long each test should run. By default 5 seconds. - -.. option:: -h, --help - - Prints a brief help message to the console. - -.. option:: -V, --version - - Prints version information to the console. - -The following test modes are supported by :program:`ovs-test`. It is possible -to combine multiple of them in a single :program:`ovs-test` invocation. - -.. option:: -d, --direct - - Perform direct tests between both OuterIP addresses. These tests could be - used as a reference to compare 802.1Q or L3 tunneling test results. - -.. option:: -l , --vlan-tag - - Perform 802.1Q tests between both servers. These tests will create a - temporary OVS bridge, if necessary, and attach a VLAN tagged port to - it for testing purposes. - -.. option:: -t , --tunnel-modes - - Perform L3 tunneling tests. The given argument is a comma sepa‐ rated - string that specifies all the L3 tunnel modes that should be tested (e.g. - gre). The L3 tunnels are terminated on interface that has the OuterIP - address assigned. - -Examples -======== - -On host 1.2.3.4 start :program:`ovs-test` in server mode:: - - ovs-test -s 15531 - -On host 1.2.3.5 start :program:`ovs-test` in client mode and do direct, VLAN -and GRE tests between both nodes:: - - ovs-test -c 127.0.0.1,1.1.1.1/30 1.2.3.4,1.1.1.2/30 -d -l 123 -t - gre - -See Also -======== - -`ovs-vswitchd(8)`, `ovs-ofctl(8)`, `ovs-vsctl(8)`, :program:`ovs-vlan-test`, -`ethtool(8)`, `uname(1)` diff --git a/Documentation/ref/ovs-vlan-test.8.rst b/Documentation/ref/ovs-vlan-test.8.rst deleted file mode 100644 index d4fbabbdf..000000000 --- a/Documentation/ref/ovs-vlan-test.8.rst +++ /dev/null @@ -1,113 +0,0 @@ -============= -ovs-vlan-test -============= - -Synopsis -======== - -**ovs-vlan-test** [**-s** | **--server**] *control_ip* *vlan_ip* - -Description -=========== - -The :program:`ovs-vlan-test` utility has some limitations, for example, it does -not use TCP in its tests. Also it does not take into account MTU to detect -potential edge cases. To overcome those limitations a new tool was developed - -:program:`ovs-test`. :program:`ovs-test` is currently supported only on Debian -so, if possible, try to use that on instead of :program:`ovs-vlan-test`. - -The :program:`ovs-vlan-test` program may be used to check for problems sending -802.1Q traffic which may occur when running Open vSwitch. These problems can -occur when Open vSwitch is used to send 802.1Q traffic through physical -interfaces running certain drivers of certain Linux kernel versions. To run a -test, configure Open vSwitch to tag traffic originating from `vlan_ip` and -forward it out the target interface. Then run the :program:`ovs-vlan-test` in -client mode connecting to an :program:`ovs-vlan-test` server. -:program:`ovs-vlan-test` will display "OK" if it did not detect problems. - -Some examples of the types of problems that may be encountered are: - -- When NICs use VLAN stripping on receive they must pass a pointer to a - `vlan_group` when reporting the stripped tag to the networking core. If no - `vlan_group` is in use then some drivers just drop the extracted tag. - Drivers are supposed to only enable stripping if a `vlan_group` is registered - but not all of them do that. - -- On receive, some drivers handle priority tagged packets specially and don't - pass the tag onto the network stack at all, so Open vSwitch never has a - chance to see it. - -- Some drivers size their receive buffers based on whether a `vlan_group` is - enabled, meaning that a maximum size packet with a VLAN tag will not fit if - no `vlan_group` is configured. - -- On transmit, some drivers expect that VLAN acceleration will be used if it is - available, which can only be done if a `vlan_group` is configured. In these - cases, the driver may fail to parse the packet and correctly setup checksum - offloading or TSO. - -Client Mode - An :program:`ovs-vlan-test` client may be run on a host to check for VLAN - connectivity problems. The client must be able to establish HTTP connections - with an :program:`ovs-vlan-test` server located at the specified `control_ip` - address. UDP traffic sourced at `vlan_ip` should be tagged and directed out - the interface whose connectivity is being tested. - -Server Mode - To conduct tests, an :program:`ovs-vlan-test` server must be running on a - host known not to have VLAN connectivity problems. The server must have a - `control_ip` on a non-VLAN network which clients can establish connectivity - with. It must also have a `vlan_ip` address on a VLAN network which clients - will use to test their VLAN connectivity. Multiple clients may test against a - single :program:`ovs-vlan-test` server concurrently. - -Options -======= - -.. program:: ovs-vlan-test - -.. option:: -s, --server - - Run in server mode. - -.. option:: -h, --help - - Prints a brief help message to the console. - -.. option:: -V, --version - - Prints version information to the console. - -Examples -======== - -Display the Linux kernel version and driver of `eth1`:: - - uname -r - ethtool -i eth1 - -Set up a bridge which forwards traffic originating from `1.2.3.4` out `eth1` -with VLAN tag 10:: - - ovs-vsctl -- add-br vlan-br \ - -- add-port vlan-br eth1 \ - -- add-port vlan-br vlan-br-tag tag=10 \ - -- set Interface vlan-br-tag type=internal - ip addr add 1.2.3.4/8 dev vlan-br-tag - ip link set vlan-br-tag up - -Run an :program:`ovs-vlan-test` server listening for client control traffic on -`172.16.0.142` port `8080` and VLAN traffic on the default port of `1.2.3.3`:: - - ovs-vlan-test -s 172.16.0.142:8080 1.2.3.3 - -Run an :program:`ovs-vlan-test` client with a control server located at -`172.16.0.142` port `8080` and a local VLAN IP of `1.2.3.4`:: - - ovs-vlan-test 172.16.0.142:8080 1.2.3.4 - -See Also -======== - -`ovs-vswitchd(8)`, `ovs-ofctl(8)`, `ovs-vsctl(8)`, :program:`ovs-test`, -`ethtool(8)`, `uname(1)` From patchwork Wed Jun 12 07:19:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Numan Siddique X-Patchwork-Id: 1114327 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45NyxW5Cymz9s4Y for ; Wed, 12 Jun 2019 17:22:23 +1000 (AEST) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 7491F1646; Wed, 12 Jun 2019 07:21:56 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8EA8F15EA for ; Wed, 12 Jun 2019 07:19:43 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 65FE67F8 for ; Wed, 12 Jun 2019 07:19:37 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C478A2F8BD9 for ; Wed, 12 Jun 2019 07:19:31 +0000 (UTC) Received: from nusiddiq.mac (unknown [10.74.10.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0DA3364046 for ; Wed, 12 Jun 2019 07:19:26 +0000 (UTC) From: nusiddiq@redhat.com To: dev@openvswitch.org Date: Wed, 12 Jun 2019 12:49:22 +0530 Message-Id: <20190612071922.24416-1-nusiddiq@redhat.com> In-Reply-To: <20190612071822.24182-1-nusiddiq@redhat.com> References: <20190612071822.24182-1-nusiddiq@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 12 Jun 2019 07:19:31 +0000 (UTC) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [ovs-dev] [PATCH ovn 3/4] Documentation cleanup: intro section X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org From: Numan Siddique This patch deletes the non ovn related files and updates the Documentation/intro/install/general.rst and other related file for OVN installation. Signed-off-by: Numan Siddique Acked-by: Ben Pfaff --- Documentation/automake.mk | 6 - Documentation/index.rst | 11 +- Documentation/intro/index.rst | 2 - .../intro/install/bash-completion.rst | 106 --- Documentation/intro/install/debian.rst | 104 +-- Documentation/intro/install/distributions.rst | 38 +- Documentation/intro/install/fedora.rst | 83 +- Documentation/intro/install/general.rst | 395 +++------ Documentation/intro/install/index.rst | 4 - Documentation/intro/install/netbsd.rst | 58 -- Documentation/intro/install/userspace.rst | 106 --- Documentation/intro/install/windows.rst | 776 +----------------- Documentation/intro/install/xenserver.rst | 229 ------ Documentation/intro/what-is-ovs.rst | 41 - Documentation/intro/why-ovs.rst | 131 --- 15 files changed, 145 insertions(+), 1945 deletions(-) delete mode 100644 Documentation/intro/install/bash-completion.rst delete mode 100644 Documentation/intro/install/netbsd.rst delete mode 100644 Documentation/intro/install/userspace.rst delete mode 100644 Documentation/intro/install/xenserver.rst delete mode 100644 Documentation/intro/what-is-ovs.rst delete mode 100644 Documentation/intro/why-ovs.rst diff --git a/Documentation/automake.mk b/Documentation/automake.mk index c3b0949bd..f7e1d2628 100644 --- a/Documentation/automake.mk +++ b/Documentation/automake.mk @@ -6,21 +6,15 @@ DOC_SOURCE = \ Documentation/index.rst \ Documentation/contents.rst \ Documentation/intro/index.rst \ - Documentation/intro/what-is-ovs.rst \ - Documentation/intro/why-ovs.rst \ Documentation/intro/install/index.rst \ - Documentation/intro/install/bash-completion.rst \ Documentation/intro/install/debian.rst \ Documentation/intro/install/documentation.rst \ Documentation/intro/install/distributions.rst \ Documentation/intro/install/fedora.rst \ Documentation/intro/install/general.rst \ - Documentation/intro/install/netbsd.rst \ Documentation/intro/install/ovn-upgrades.rst \ Documentation/intro/install/rhel.rst \ - Documentation/intro/install/userspace.rst \ Documentation/intro/install/windows.rst \ - Documentation/intro/install/xenserver.rst \ Documentation/tutorials/index.rst \ Documentation/tutorials/ovn-openstack.rst \ Documentation/tutorials/ovn-sandbox.rst \ diff --git a/Documentation/index.rst b/Documentation/index.rst index 192ed7631..9e5664ec0 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -47,17 +47,10 @@ The Open vSwitch documentation is organised into multiple sections: First Steps ----------- -Getting started with Open vSwitch (OVS) or Open Virtual Network (OVN) for Open -vSwitch? Start here. - -- **Overview:** :doc:`intro/what-is-ovs` | - :doc:`intro/why-ovs` +Getting started with Open Virtual Network (OVN) for Open vSwitch? Start here. - **Install:** :doc:`intro/install/general` | - :doc:`intro/install/userspace` | - :doc:`intro/install/netbsd` | - :doc:`intro/install/windows` | - :doc:`intro/install/xenserver` + :doc:`intro/install/windows` - **Tutorials:** :doc:`tutorials/ovn-sandbox` | :doc:`tutorials/ovn-openstack` | diff --git a/Documentation/intro/index.rst b/Documentation/intro/index.rst index 0ad7ad1dc..7d42813cd 100644 --- a/Documentation/intro/index.rst +++ b/Documentation/intro/index.rst @@ -32,6 +32,4 @@ How to get started with Open vSwitch. .. toctree:: :maxdepth: 2 - what-is-ovs - why-ovs install/index diff --git a/Documentation/intro/install/bash-completion.rst b/Documentation/intro/install/bash-completion.rst deleted file mode 100644 index 4018be05b..000000000 --- a/Documentation/intro/install/bash-completion.rst +++ /dev/null @@ -1,106 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -==================================== -Bash command-line completion scripts -==================================== - -There are two completion scripts available: ``ovs-appctl-bashcomp.bash`` and -``ovs-vsctl-bashcomp.bash``. - -ovs-appctl-bashcomp -------------------- - -``ovs-appctl-bashcomp.bash`` adds bash command-line completion support for -``ovs-appctl``, ``ovs-dpctl``, ``ovs-ofctl`` and ``ovsdb-tool`` commands. - -Features -~~~~~~~~ - -- Display available completion or complete on unfinished user input (long - option, subcommand, and argument). - -- Subcommand hints - -- Convert between keywords like ``bridge``, ``port``, ``interface``, or ``dp`` - and the available record in ovsdb. - -Limitations -~~~~~~~~~~~ - -- Only supports a small set of important keywords (``dp``, ``datapath``, - ``bridge``, ``switch``, ``port``, ``interface``, ``iface``). - -- Does not support parsing of nested options. For example:: - - $ ovsdb-tool create [db [schema]] - -- Does not support expansion on repeated argument. For example:: - - $ ovs-dpctl show [dp...]). - -- Only supports matching on long options, and only in the format ``--option - [arg]``. Do not use ``--option=[arg]``. - -ovs-vsctl-bashcomp -------------------- - -``ovs-vsctl-bashcomp.bash`` adds Bash command-line completion support for -``ovs-vsctl`` command. - -Features -~~~~~~~~ - -- Display available completion and complete on user input for global/local - options, command, and argument. - -- Query database and expand keywords like ``table``, ``record``, ``column``, or - ``key``, to available completions. - -- Deal with argument relations like 'one and more', 'zero or one'. - -- Complete multiple ``ovs-vsctl`` commands cascaded via ``--``. - -Limitations -~~~~~~~~~~~ - -Completion of very long ``ovs-vsctl`` commands can take up to several seconds. - -Usage ------ - -The bashcomp scripts should be placed at ``/etc/bash_completion.d/`` to be -available for all bash sessions. Running ``make install`` will place the -scripts to ``$(sysconfdir)/bash_completion.d/``, thus, the user should specify -``--sysconfdir=/etc`` at configuration. If OVS is installed from packages, the -scripts will automatically be placed inside ``/etc/bash_completion.d/``. - -If you just want to run the scripts in one bash, you can remove them from -``/etc/bash_completion.d/`` and run the scripts via ``. -ovs-appctl-bashcomp.bash`` or ``. ovs-vsctl-bashcomp.bash``. - -Tests ------ - -Unit tests are added in ``tests/completion.at`` and integrated into autotest -framework. To run the tests, just run ``make check``. diff --git a/Documentation/intro/install/debian.rst b/Documentation/intro/install/debian.rst index 4024dc07a..e0605ed50 100644 --- a/Documentation/intro/install/debian.rst +++ b/Documentation/intro/install/debian.rst @@ -22,106 +22,8 @@ Avoid deeper levels because they do not render well. ================================= -Debian Packaging for Open vSwitch +Debian Packaging for OVN ================================= -This document describes how to build Debian packages for Open vSwitch. To -install Open vSwitch on Debian without building Debian packages, refer to -:doc:`general` instead. - -.. note:: - These instructions should also work on Ubuntu and other Debian derivative - distributions. - -Before You Begin ----------------- - -Before you begin, consider whether you really need to build packages yourself. -Debian "wheezy" and "sid", as well as recent versions of Ubuntu, contain -pre-built Debian packages for Open vSwitch. It is easier to install these than -to build your own. To use packages from your distribution, skip ahead to -"Installing .deb Packages", below. - -Building Open vSwitch Debian packages -------------------------------------- - -You may build from an Open vSwitch distribution tarball or from an Open vSwitch -Git tree with these instructions. - -You do not need to be the superuser to build the Debian packages. - -1. Install the "build-essential" and "fakeroot" packages. For example:: - - $ apt-get install build-essential fakeroot - -2. Obtain and unpack an Open vSwitch source distribution and ``cd`` into its - top level directory. - -3. Install the build dependencies listed under "Build-Depends:" near the top of - ``debian/control``. You can install these any way you like, e.g. with - ``apt-get install``. - -Check your work by running ``dpkg-checkbuilddeps`` in the top level of your OVS -directory. If you've installed all the dependencies properly, -``dpkg-checkbuilddeps`` will exit without printing anything. If you forgot to -install some dependencies, it will tell you which ones. - -4. Build the package:: - - $ fakeroot debian/rules binary - - This will do a serial build that runs the unit tests. This will take - approximately 8 to 10 minutes. If you prefer, you can run a faster parallel - build:: - - $ DEB_BUILD_OPTIONS='parallel=8' fakeroot debian/rules binary - - If you are in a big hurry, you can even skip the unit tests:: - - $ DEB_BUILD_OPTIONS='parallel=8 nocheck' fakeroot debian/rules binary - -.. note:: - - There are a few pitfalls in the Debian packaging building system so that, - occasionally, you may find that in a tree that you have using for a while, - the build command above exits immediately without actually building anything. - To fix the problem, run:: - - $ fakeroot debian/rules clean - - or start over from a fresh copy of the source tree. - -5. The generated .deb files will be in the parent directory of the Open vSwitch - source distribution. - -Installing .deb Packages ------------------------- - -These instructions apply to installing from Debian packages that you built -yourself, as described in the previous section. In this case, use a command -such as ``dpkg -i`` to install the .deb files that you build. You will have to -manually install any missing dependencies. - -You can also use these instruction to install from packages provided by Debian -or a Debian derivative distribution such as Ubuntu. In this case, use a -program such as ``apt-get`` or ``aptitude`` to download and install the -provided packages. These programs will also automatically download and install -any missing dependencies. - -.. important:: - You must be superuser to install Debian packages. - -1. Start by installing an Open vSwitch kernel module. See - ``debian/openvswitch-switch.README.Debian`` for the available options. - -2. Install the ``openvswitch-switch`` and ``openvswitch-common`` packages. - These packages include the core userspace components of the switch. - -Open vSwitch ``.deb`` packages not mentioned above are rarely useful. Refer to -their individual package descriptions to find out whether any of them are -useful to you. - -Reporting Bugs --------------- - -Report problems to bugs@openvswitch.org. +OVN packages needs to be split from OVS. This section will be +updated once it is done. diff --git a/Documentation/intro/install/distributions.rst b/Documentation/intro/install/distributions.rst index 5987178ea..29e52fd56 100644 --- a/Documentation/intro/install/distributions.rst +++ b/Documentation/intro/install/distributions.rst @@ -25,48 +25,28 @@ Distributions packaging Open vSwitch ==================================== -This document lists various popular distributions packaging Open vSwitch. -Open vSwitch is packaged by various distributions for multiple platforms and -architectures. +This document lists various popular distributions packaging OVN. .. note:: The packaged version available with distributions may not be latest - Open vSwitch release. + OVN release. Debian ------- You can use ``apt-get`` or ``aptitude`` to install the .deb packages and must -be superuser. - -1. Debian has ``openvswitch-switch`` and ``openvswitch-common`` .deb packages -that includes the core userspace components of the switch. - -2. For kernel datapath, ``openvswitch-datapath-dkms`` can be installed to -automatically build and install Open vSwitch kernel module for your running -kernel. - -3. For DPDK datapath, Open vSwitch with DPDK support is bundled in the package -``openvswitch-switch-dpdk``. +be superuser. Debian has ``ovn-common``, ``ovn-host``, ``ovn-central`` and +``ovn-vtep`` .deb packages. Fedora ------ -Fedora provides ``openvswitch``, ``openvswitch-devel``, ``openvswitch-test`` -and ``openvswitch-debuginfo`` rpm packages. You can install ``openvswitch`` -package in minimum installation. Use ``yum`` or ``dnf`` to install the rpm -packages and must be superuser. - -Red Hat -------- - -RHEL distributes ``openvswitch`` rpm package that supports kernel datapath. -DPDK accelerated Open vSwitch can be installed using ``openvswitch-dpdk`` -package. +Fedora provides ``ovn``, ``ovn-host``, ``ovn-central`` +and ``ovn-vtep`` rpm packages. Use ``yum`` or ``dnf`` to install +the rpm packages and must be superuser. OpenSuSE -------- -OpenSUSE provides ``openvswitch``, ``openvswitch-switch`` rpm packages. Also -``openvswitch-dpdk`` and ``openvswitch-dpdk-switch`` can be installed for -Open vSwitch using DPDK accelerated datapath. +OpenSUSE provides ``openvswitch-ovn-common``, ```openvswitch-ovn-host``, +```openvswitch-ovn-central`` and ```openvswitch-ovn-vtep`` rpm packages. diff --git a/Documentation/intro/install/fedora.rst b/Documentation/intro/install/fedora.rst index 4e1a99766..c8ea6ec01 100644 --- a/Documentation/intro/install/fedora.rst +++ b/Documentation/intro/install/fedora.rst @@ -22,16 +22,17 @@ Avoid deeper levels because they do not render well. =========================================== -Fedora, RHEL 7.x Packaging for Open vSwitch +Fedora, RHEL 7.x Packaging for OVN =========================================== -This document provides instructions for building and installing Open vSwitch -RPM packages on a Fedora Linux host. Instructions for the installation of Open -vSwitch on a Fedora Linux host without using RPM packages can be found in the +This document provides instructions for building and installing OVN +RPM packages on a Fedora Linux host. Instructions for the installation of OVN +Fedora Linux host without using RPM packages can be found in the :doc:`general`. -These instructions have been tested with Fedora 23, and are also applicable for -RHEL 7.x and its derivatives, including CentOS 7.x and Scientific Linux 7.x. +These instructions have been tested with Fedora 29 and 30, and are also +applicable for RHEL 7.x and its derivatives, including CentOS 7.x and +Scientific Linux 7.x. Build Requirements ------------------ @@ -41,7 +42,7 @@ Newer distributions use ``dnf`` but if it's not available, then use ``yum`` instructions. The command below will install RPM tools and generic build dependencies. -And (optionally) include these packages: libcap-ng libcap-ng-devel dpdk-devel. +And (optionally) include these packages: libcap-ng libcap-ng-devel. DNF: :: @@ -53,14 +54,14 @@ YUM: $ yum install @'Development Tools' rpm-build yum-utils -Then it is necessary to install Open vSwitch specific build dependencies. +Then it is necessary to install OVN specific build dependencies. The dependencies are listed in the SPEC file, but first it is necessary to replace the VERSION tag to be a valid SPEC. The command below will create a temporary SPEC file:: - $ sed -e 's/@VERSION@/0.0.1/' rhel/openvswitch-fedora.spec.in \ - > /tmp/ovs.spec + $ sed -e 's/@VERSION@/0.0.1/' rhel/ovn-fedora.spec.in \ + > /tmp/ovn.spec And to install specific dependencies, use the corresponding tool below. For some of the dependencies on RHEL you may need to add two additional @@ -71,13 +72,13 @@ repositories to help yum-builddep, e.g.:: DNF:: - $ dnf builddep /tmp/ovs.spec + $ dnf builddep /tmp/ovn.spec YUM:: - $ yum-builddep /tmp/ovs.spec + $ yum-builddep /tmp/ovn.spec -Once that is completed, remove the file ``/tmp/ovs.spec``. +Once that is completed, remove the file ``/tmp/ovn.spec``. Bootstraping ------------ @@ -92,25 +93,20 @@ Refer to :ref:`general-configuring`. Building -------- -User Space RPMs +OVN RPMs ~~~~~~~~~~~~~~~ -To build Open vSwitch user-space RPMs, execute the following from the directory +To build OVN RPMs, execute the following from the directory in which `./configure` was executed: :: $ make rpm-fedora -This will create the RPMs `openvswitch`, `python-openvswitch`, -`openvswitch-test`, `openvswitch-devel` and `openvswitch-debuginfo`. +This will create the RPMs `ovn`, `ovn-central`, `ovn-host`, `ovn-vtep`, +`ovn-docker`, ``ovn-debuginfo``, ``ovn-central-debuginfo``, +``ovn-host-debuginfo`` and ```ovn-vtep-debuginfo```. -To enable DPDK support in the openvswitch package, the ``--with dpdk`` option -can be added: - -:: - - $ make rpm-fedora RPMBUILD_OPT="--with dpdk --without check" You can also have the above commands automatically run the Open vSwitch unit tests. This can take several minutes. @@ -119,34 +115,6 @@ tests. This can take several minutes. $ make rpm-fedora RPMBUILD_OPT="--with check" -To build OVN RPMs, execute the following from the directory in which -`./configure` was executed: - -:: - - $ make rpm-fedora-ovn - -This will create the RPMs `ovn`, `ovn-common`, `ovn-central`, `ovn-host`, -`ovn-docker` and `ovn-vtep`. - - -Kernel OVS Tree Datapath RPM -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To build the Open vSwitch kernel module for the currently running kernel -version, run: - -:: - - $ make rpm-fedora-kmod - -To build the Open vSwitch kernel module for another kernel version, the desired -kernel version can be specified via the `kversion` macro. For example: - -:: - - $ make rpm-fedora-kmod \ - RPMBUILD_OPT='-D "kversion 4.3.4-300.fc23.x86_64"' Installing ---------- @@ -154,19 +122,6 @@ Installing RPM packages can be installed by using the command ``rpm -i``. Package installation requires superuser privileges. -The `openvswitch-kmod` RPM should be installed first if the Linux OVS tree -datapath module is to be used. The `openvswitch-kmod` RPM should not be -installed if only the in-tree Linux datapath or user-space datapath is needed. -Refer to the :doc:`/faq/index` for more information about the various Open -vSwitch datapath options. - -In most cases only the `openvswitch` RPM will need to be installed. The -`python-openvswitch`, `openvswitch-test`, `openvswitch-devel`, and -`openvswitch-debuginfo` RPMs are optional unless required for a specific -purpose. - -The `ovn-*` packages are only needed when using OVN. - Refer to the `RHEL README`__ for additional usage and configuration information. diff --git a/Documentation/intro/install/general.rst b/Documentation/intro/install/general.rst index bca4decb9..99d8fec04 100644 --- a/Documentation/intro/install/general.rst +++ b/Documentation/intro/install/general.rst @@ -22,47 +22,36 @@ Avoid deeper levels because they do not render well. ========================================= -Open vSwitch on Linux, FreeBSD and NetBSD +OVN on Linux, FreeBSD and NetBSD ========================================= -This document describes how to build and install Open vSwitch on a generic +This document describes how to build and install OVN on a generic Linux, FreeBSD, or NetBSD host. For specifics around installation on a specific platform, refer to one of the other installation guides listed in :doc:`index`. -Obtaining Open vSwitch Sources +Obtaining OVN Sources ------------------------------ -The canonical location for Open vSwitch source code is its Git -repository, which you can clone into a directory named "ovs" with:: +The canonical location for OVN source code is its Git +repository, which you can clone into a directory named "ovn" with:: - $ git clone https://github.com/openvswitch/ovs.git + $ git clone https://github.com/ovn-org/ovn.git Cloning the repository leaves the "master" branch initially checked -out. This is the right branch for general development. If, on the -other hand, if you want to build a particular released version, you -can check it out by running a command such as the following from the -"ovs" directory:: +out. This is the right branch for general development. - $ git checkout v2.7.0 +As of now there are no official OVN releases. -The repository also has a branch for each release series. For -example, to obtain the latest fixes in the Open vSwitch 2.7.x release -series, which might include bug fixes that have not yet been in any -released version, you can check it out from the "ovs" directory with:: - - $ git checkout origin/branch-2.7 - -If you do not want to use Git, you can also obtain tarballs for Open -vSwitch release versions via http://openvswitch.org/download/, or -download a ZIP file for any snapshot from the web interface at -https://github.com/openvswitch/ovs. +Although building OVN, also builds OVS, it is recommended to clone +and build OVS from its own repo. Please see the Open vSwitch +documentation to build and install OVS. .. _general-build-reqs: Build Requirements ------------------ -To compile the userspace programs in the Open vSwitch distribution, you will +To compile the userspace programs in the OVN distribution, you will need the following software: - GNU make @@ -76,66 +65,26 @@ need the following software: - MSVC 2013. Refer to :doc:`windows` for additional Windows build instructions. - While OVS may be compatible with other compilers, optimal support for atomic - operations may be missing, making OVS very slow (see ``lib/ovs-atomic.h``). +- While OVN may be compatible with other compilers, optimal support for atomic + operations may be missing, making OVN very slow + (see ``ovs/lib/ovs-atomic.h``). - libssl, from OpenSSL, is optional but recommended if you plan to connect the - Open vSwitch to an OpenFlow controller. libssl is required to establish - confidentiality and authenticity in the connections from an Open vSwitch to - an OpenFlow controller. If libssl is installed, then Open vSwitch will - automatically build with support for it. - -- libcap-ng, written by Steve Grubb, is optional but recommended. It is - required to run OVS daemons as a non-root user with dropped root privileges. - If libcap-ng is installed, then Open vSwitch will automatically build with - support for it. + OVN services to the OVN DB ovsdb-servers securely. If libssl is installed, + then OVN will automatically build with support for it. - Python 2.7. You must also have the Python ``six`` library version 1.4.0 or later. - Unbound library, from http://www.unbound.net, is optional but recommended if - you want to enable ovs-vswitchd and other utilities to use DNS names when - specifying OpenFlow and OVSDB remotes. If unbound library is already - installed, then Open vSwitch will automatically build with support for it. + you want to enable ovn-northd, ovn-controller and other utilities to use + DNS names when specifying OVSDB remotes. If unbound library is already + installed, then OVN will automatically build with support for it. The environment variable OVS_RESOLV_CONF can be used to specify DNS server configuration file (the default file on Linux is /etc/resolv.conf). -On Linux, you may choose to compile the kernel module that comes with the Open -vSwitch distribution or to use the kernel module built into the Linux kernel -(version 3.3 or later). See the :doc:`/faq/index` question "What features are -not available in the Open vSwitch kernel datapath that ships as part of the -upstream Linux kernel?" for more information on this trade-off. You may also -use the userspace-only implementation, at some cost in features and -performance. Refer to :doc:`userspace` for details. - -To compile the kernel module on Linux, you must also install the -following: - -- A supported Linux kernel version. - - For optional support of ingress policing, you must enable kernel - configuration options ``NET_CLS_BASIC``, ``NET_SCH_INGRESS``, and - ``NET_ACT_POLICE``, either built-in or as modules. ``NET_CLS_POLICE`` is - obsolete and not needed.) - - On kernels before 3.11, the ``ip_gre`` module, for GRE tunnels over IP - (``NET_IPGRE``), must not be loaded or compiled in. - - To configure HTB or HFSC quality of service with Open vSwitch, you must - enable the respective configuration options. - - To use Open vSwitch support for TAP devices, you must enable ``CONFIG_TUN``. - -- To build a kernel module, you need the same version of GCC that was used to - build that kernel. - -- A kernel build directory corresponding to the Linux kernel image the module - is to run on. Under Debian and Ubuntu, for example, each linux-image package - containing a kernel binary has a corresponding linux-headers package with - the required build infrastructure. - If you are working from a Git tree or snapshot (instead of from a distribution -tarball), or if you modify the Open vSwitch build system or the database +tarball), or if you modify the OVN build system or the database schema, you will also need the following software: - Autoconf version 2.63 or later. @@ -144,28 +93,12 @@ schema, you will also need the following software: - libtool version 2.4 or later. (Older versions might work too.) -The datapath tests for userspace and Linux datapaths also rely upon: - -- pyftpdlib. Version 1.2.0 is known to work. Earlier versions should - also work. - -- GNU wget. Version 1.16 is known to work. Earlier versions should also - work. - -- netcat. Several common implementations are known to work. - -- curl. Version 7.47.0 is known to work. Earlier versions should also work. - -- tftpy. Version 0.6.2 is known to work. Earlier versions should also work. - -- netstat. Available from various distro specific packages - -The ovs-vswitchd.conf.db(5) manpage will include an E-R diagram, in formats +The OVN manpages will include an E-R diagram, in formats other than plain text, only if you have the following: - dot from graphviz (http://www.graphviz.org/). -If you are going to extensively modify Open vSwitch, consider installing the +If you are going to extensively modify OVN, consider installing the following to obtain better warnings: - "sparse" version 0.5.1 or later @@ -180,29 +113,18 @@ following to obtain better warnings: come from the "hacking" flake8 plugin. If it's not installed, the warnings just won't occur until it's run on a system with "hacking" installed. -You may find the ovs-dev script found in ``utilities/ovs-dev.py`` useful. +You may find the ovs-dev script found in ``ovs/utilities/ovs-dev.py`` useful. .. _general-install-reqs: Installation Requirements ------------------------- -The machine you build Open vSwitch on may not be the one you run it on. To -simply install and run Open vSwitch you require the following software: +The machine you build OVN on may not be the one you run it on. +To simply install and run OVN you require the following software: - Shared libraries compatible with those used for the build. -- On Linux, if you want to use the kernel-based datapath (which is the most - common use case), then a kernel with a compatible kernel module. This - can be a kernel module built with Open vSwitch (e.g. in the previous - step), or the kernel module that accompanies Linux 3.3 and later. Open - vSwitch features and performance can vary based on the module and the - kernel. - -- For optional support of ingress policing on Linux, the "tc" program - from iproute2 (part of all major distributions and available at - https://wiki.linuxfoundation.org/networking/iproute2). - - Python 2.7. You must also have the Python six library version 1.4.0 or later. @@ -231,9 +153,9 @@ invoke configure without any arguments. For example:: $ ./configure -By default all files are installed under ``/usr/local``. Open vSwitch also -expects to find its database in ``/usr/local/etc/openvswitch`` by default. If -you want to install all files into, e.g., ``/usr`` and ``/var`` instead of +By default all files are installed under ``/usr/local``. OVN and Open vSwitch +also expects to find its database in ``/usr/local/etc/openvswitch`` by default. +If you want to install all files into, e.g., ``/usr`` and ``/var`` instead of ``/usr/local`` and ``/usr/local/var`` and expect to use ``/etc/openvswitch`` as the default database directory, add options as shown here:: @@ -241,9 +163,9 @@ the default database directory, add options as shown here:: .. note:: - Open vSwitch installed with packages like .rpm (e.g. via ``yum install`` or - ``rpm -ivh``) and .deb (e.g. via ``apt-get install`` or ``dpkg -i``) use the - above configure options. + Open vSwitch and OVN installed with packages like .rpm (e.g. via + ``yum install`` or ``rpm -ivh``) and .deb (e.g. via + ``apt-get install`` or ``dpkg -i``) use the above configure options. By default, static libraries are built and linked against. If you want to use shared libraries instead:: @@ -313,14 +235,7 @@ example, to build for a running instance of Linux:: then ``configure`` will fail with an error message. Refer to the :doc:`/faq/index` for advice in that case. -If you wish to build the kernel module for an architecture other than the -architecture of the machine used for the build, you may specify the kernel -architecture string using the KARCH variable when invoking the configure -script. For example, to build for MIPS with Linux:: - - $ ./configure --with-linux=/path/to/linux KARCH=mips - -If you plan to do much Open vSwitch development, you might want to add +If you plan to do much OVN development, you might want to add ``--enable-Werror``, which adds the ``-Werror`` option to the compiler command line, turning warnings into errors. That makes it impossible to miss warnings generated by the build. For example:: @@ -345,9 +260,8 @@ option:: $ ./configure --help You can also run configure from a separate build directory. This is helpful if -you want to build Open vSwitch in more than one way from a single source -directory, e.g. to try out both GCC and Clang builds, or to build kernel -modules for more than one Linux version. For example:: +you want to build OVN in more than one way from a single source +directory, e.g. to try out both GCC and Clang builds. For example:: $ mkdir _gcc && (cd _gcc && ./configure CC=gcc) $ mkdir _clang && (cd _clang && ./configure CC=clang) @@ -390,210 +304,121 @@ Building $ make install -5. If you built kernel modules, you may install them, e.g.:: - - $ make modules_install - - It is possible that you already had a Open vSwitch kernel module installed - on your machine that came from upstream Linux (in a different directory). To - make sure that you load the Open vSwitch kernel module you built from this - repository, you should create a ``depmod.d`` file that prefers your newly - installed kernel modules over the kernel modules from upstream Linux. The - following snippet of code achieves the same:: - - $ config_file="/etc/depmod.d/openvswitch.conf" - $ for module in datapath/linux/*.ko; do - modname="$(basename ${module})" - echo "override ${modname%.ko} * extra" >> "$config_file" - echo "override ${modname%.ko} * weak-updates" >> "$config_file" - done - $ depmod -a - - Finally, load the kernel modules that you need. e.g.:: - - $ /sbin/modprobe openvswitch - - To verify that the modules have been loaded, run ``/sbin/lsmod`` and check - that openvswitch is listed:: - - $ /sbin/lsmod | grep openvswitch - - .. note:: - If the ``modprobe`` operation fails, look at the last few kernel log - messages (e.g. with ``dmesg | tail``). Generally, issues like this occur - when Open vSwitch is built for a kernel different from the one into which - you are trying to load it. Run ``modinfo`` on ``openvswitch.ko`` and on a - module built for the running kernel, e.g.:: - - $ /sbin/modinfo openvswitch.ko - $ /sbin/modinfo /lib/modules/$(uname -r)/kernel/net/bridge/bridge.ko - - Compare the "vermagic" lines output by the two commands. If they differ, - then Open vSwitch was built for the wrong kernel. - - If you decide to report a bug or ask a question related to module loading, - include the output from the ``dmesg`` and ``modinfo`` commands mentioned - above. - .. _general-starting: Starting -------- -On Unix-alike systems, such as BSDs and Linux, starting the Open vSwitch -suite of daemons is a simple process. Open vSwitch includes a shell script, -and helpers, called ovs-ctl which automates much of the tasks for starting -and stopping ovsdb-server, and ovs-vswitchd. After installation, the daemons -can be started by using the ovs-ctl utility. This will take care to setup -initial conditions, and start the daemons in the correct order. The ovs-ctl -utility is located in '$(pkgdatadir)/scripts', and defaults to +Before starting the OVN, start the Open vSwitch daemons. Refer to the +Open vSwitch documentation for more details on how to start OVS. + +On Unix-alike systems, such as BSDs and Linux, starting the OVN +suite of daemons is a simple process. OVN includes a shell script, +called ovn-ctl which automates much of the tasks for starting +and stopping ovn-northd, ovn-controller and ovsdb-servers. After installation, +the daemons can be started by using the ovn-ctl utility. This will take care +to setup initial conditions, and start the daemons in the correct order. +The ovn-ctl utility is located in '$(pkgdatadir)/scripts', and defaults to '/usr/local/share/openvswitch/scripts'. An example after install might be:: $ export PATH=$PATH:/usr/local/share/openvswitch/scripts - $ ovs-ctl start + $ ovn-ctl start_northd + $ ovn-ctl start_controller -Additionally, the ovs-ctl script allows starting / stopping the daemons -individually using specific options. To start just the ovsdb-server:: +Starting OVN Central services +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - $ export PATH=$PATH:/usr/local/share/openvswitch/scripts - $ ovs-ctl --no-ovs-vswitchd start - -Likewise, to start just the ovs-vswitchd:: +OVN central services includes ovn-northd, Northbound and +Southbound ovsdb-server. $ export PATH=$PATH:/usr/local/share/openvswitch/scripts - $ ovs-ctl --no-ovsdb-server start + $ ovn-ctl start_northd -Refer to ovs-ctl(8) for more information on ovs-ctl. +Refer to ovn-ctl(8) for more information and the supported options. -In addition to using the automated script to start Open vSwitch, you may -wish to manually start the various daemons. Before starting ovs-vswitchd -itself, you need to start its configuration database, ovsdb-server. Each -machine on which Open vSwitch is installed should run its own copy of -ovsdb-server. Before ovsdb-server itself can be started, configure a -database that it can use:: +You may wish to manually start the OVN central daemons. +Before starting ovn-northd you need to start OVN Northbound and Southbound +ovsdb-servers. Before ovsdb-servers can be started, +configure the Northbound and Southbound databases:: $ mkdir -p /usr/local/etc/openvswitch - $ ovsdb-tool create /usr/local/etc/openvswitch/conf.db \ - vswitchd/vswitch.ovsschema - -Configure ovsdb-server to use database created above, to listen on a Unix -domain socket, to connect to any managers specified in the database itself, and -to use the SSL configuration in the database:: - - $ mkdir -p /usr/local/var/run/openvswitch - $ ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock \ - --remote=db:Open_vSwitch,Open_vSwitch,manager_options \ - --private-key=db:Open_vSwitch,SSL,private_key \ - --certificate=db:Open_vSwitch,SSL,certificate \ - --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert \ + $ ovsdb-tool create /usr/local/etc/openvswitch/ovnnb_db.db \ + ovn-nb.ovsschema + $ ovsdb-tool create /usr/local/etc/openvswitch/ovnsb_db.db \ + ovn-sb.ovsschema + +Configure ovsdb-servers to use databases created above, to listen on a Unix +domain socket and to use the SSL configuration in the database:: + + $ mkdir -p /usr/local/var/run/openvswitch + $ ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/ovnnb_db.sock \ + --remote=db:OVN_Northbound,NB_Global,connections \ + --private-key=db:OVN_Northbound,SSL,private_key \ + --certificate=db:OVN_Northbound,SSL,certificate \ + --bootstrap-ca-cert=db:OVN_Northbound,SSL,ca_cert \ + --pidfile --detach --log-file + $ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/ovnsb_db.sock \ + --remote=db:OVN_Southbound,SB_Global,connections \ + --private-key=db:OVN_Southbound,SSL,private_key \ + --certificate=db:OVN_Southbound,SSL,certificate \ + --bootstrap-ca-cert=db:OVN_Southbound,SSL,ca_cert \ --pidfile --detach --log-file .. note:: - If you built Open vSwitch without SSL support, then omit ``--private-key``, + If you built OVN without SSL support, then omit ``--private-key``, ``--certificate``, and ``--bootstrap-ca-cert``.) -Initialize the database using ovs-vsctl. This is only necessary the first time -after you create the database with ovsdb-tool, though running it at any time is -harmless:: +Initialize the databases using ovn-nbctl and ovn-sbctl. This is only necessary +the first time after you create the databases with ovsdb-tool, though running +it at any time is harmless:: - $ ovs-vsctl --no-wait init + $ ovn-nbctl --no-wait init + $ ovn-sbctl --no-wait init -Start the main Open vSwitch daemon, telling it to connect to the same Unix +Start the ovn-northd, telling it to connect to the OVN db servers same Unix domain socket:: - $ ovs-vswitchd --pidfile --detach --log-file - -Validating ----------- - -At this point you can use ovs-vsctl to set up bridges and other Open vSwitch -features. For example, to create a bridge named ``br0`` and add ports ``eth0`` -and ``vif1.0`` to it:: + $ ovn-northd --pidfile --detach --log-file - $ ovs-vsctl add-br br0 - $ ovs-vsctl add-port br0 eth0 - $ ovs-vsctl add-port br0 vif1.0 +Starting OVN host service +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Refer to ovs-vsctl(8) for more details. You may also wish to refer to -:doc:`/topics/testing` for information on more generic testing of OVS. +On each chassis, ovn-controller service should be started. +ovn-controller assumes it gets configuration information from the +Open_vSwitch table of the local OVS instance. Refer to the +ovn-controller(8) for the configuration keys. -Upgrading ---------- +Below are the required keys to be configured on each chassis. -When you upgrade Open vSwitch from one version to another you should also -upgrade the database schema: +1. external_ids:system-id -.. note:: - The following manual steps may also be accomplished by using ovs-ctl to - stop and start the daemons after upgrade. The ovs-ctl script will - automatically upgrade the schema. +2. external_ids:ovn-remote -1. Stop the Open vSwitch daemons, e.g.:: +3. external_ids:ovn-encap-type - $ kill `cd /usr/local/var/run/openvswitch && cat ovsdb-server.pid ovs-vswitchd.pid` +4. external_ids:ovn-encap-ip -2. Install the new Open vSwitch release by using the same configure options as - was used for installing the previous version. If you do not use the same - configure options, you can end up with two different versions of Open - vSwitch executables installed in different locations. +You may wish to manually start the ovn-controller service on each +chassis. -3. Upgrade the database, in one of the following two ways: +Start the ovn-controller, telling it to connect to the local ovsdb-server Unix +domain socket:: - - If there is no important data in your database, then you may delete the - database file and recreate it with ovsdb-tool, following the instructions - under "Building and Installing Open vSwitch for Linux, FreeBSD or NetBSD". + $ ovn-controller --pidfile --detach --log-file - - If you want to preserve the contents of your database, back it up first, - then use ``ovsdb-tool convert`` to upgrade it, e.g.:: +Validating +---------- - $ ovsdb-tool convert /usr/local/etc/openvswitch/conf.db \ - vswitchd/vswitch.ovsschema +At this point you can use ovn-nbctl on the central node to set up logical +switches and ports and other OVN logical entities. For example, to create a +logical switch ``sw0`` and add logical port ``sw0-p1`` :: -4. Start the Open vSwitch daemons as described under `Starting`_ above. + $ ovn-nbctl ls-add sw0 + $ ovn-nbctl lsp-add sw0 sw0-p1 + $ ovn-nbctl show -Hot Upgrading -------------- +Refer to ovn-nbctl(8) and ovn-sbctl (8) for more details. -Upgrading Open vSwitch from one version to the next version with minimum -disruption of traffic going through the system that is using that Open vSwitch -needs some considerations: - -1. If the upgrade only involves upgrading the userspace utilities and daemons - of Open vSwitch, make sure that the new userspace version is compatible with - the previously loaded kernel module. - -2. An upgrade of userspace daemons means that they have to be restarted. - Restarting the daemons means that the OpenFlow flows in the ovs-vswitchd - daemon will be lost. One way to restore the flows is to let the controller - re-populate it. Another way is to save the previous flows using a utility - like ovs-ofctl and then re-add them after the restart. Restoring the old - flows is accurate only if the new Open vSwitch interfaces retain the old - 'ofport' values. - -3. When the new userspace daemons get restarted, they automatically flush the - old flows setup in the kernel. This can be expensive if there are hundreds - of new flows that are entering the kernel but userspace daemons are busy - setting up new userspace flows from either the controller or an utility like - ovs-ofctl. Open vSwitch database provides an option to solve this problem - through the ``other_config:flow-restore-wait`` column of the - ``Open_vSwitch`` table. Refer to the ovs-vswitchd.conf.db(5) manpage for - details. - -4. If the upgrade also involves upgrading the kernel module, the old kernel - module needs to be unloaded and the new kernel module should be loaded. This - means that the kernel network devices belonging to Open vSwitch is recreated - and the kernel flows are lost. The downtime of the traffic can be reduced if - the userspace daemons are restarted immediately and the userspace flows are - restored as soon as possible. - -The ovs-ctl utility's ``restart`` function only restarts the userspace daemons, -makes sure that the 'ofport' values remain consistent across restarts, restores -userspace flows using the ovs-ofctl utility and also uses the -``other_config:flow-restore-wait`` column to keep the traffic downtime to the -minimum. The ovs-ctl utility's ``force-reload-kmod`` function does all of the -above, but also replaces the old kernel module with the new one. Open vSwitch -startup scripts for Debian, XenServer and RHEL use ovs-ctl's functions and it -is recommended that these functions be used for other software platforms too. Reporting Bugs -------------- diff --git a/Documentation/intro/install/index.rst b/Documentation/intro/install/index.rst index 1f941f988..92c347235 100644 --- a/Documentation/intro/install/index.rst +++ b/Documentation/intro/install/index.rst @@ -40,10 +40,7 @@ Installation from Source :maxdepth: 2 general - netbsd windows - xenserver - userspace Installation from Packages -------------------------- @@ -74,5 +71,4 @@ Others .. toctree:: :maxdepth: 2 - bash-completion documentation diff --git a/Documentation/intro/install/netbsd.rst b/Documentation/intro/install/netbsd.rst deleted file mode 100644 index 994f6b7d9..000000000 --- a/Documentation/intro/install/netbsd.rst +++ /dev/null @@ -1,58 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -====================== -Open vSwitch on NetBSD -====================== - -On NetBSD, you might want to install requirements from pkgsrc. In that case, -you need at least the following packages. - -- automake -- libtool-base -- gmake -- python27 -- py27-six -- py27-xml - -Some components have additional requirements. Refer to :doc:`general` for more -information. - -Assuming you are running NetBSD/amd64 6.1.2, you can download and install -pre-built binary packages as the following:: - - $ PKG_PATH=http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/7.0.2/All/ - $ export PKG_PATH - $ pkg_add automake libtool-base gmake python27 py27-six py27-xml \ - pkg_alternatives - -.. note:: - You might get some warnings about minor version mismatch. These can be safely - ignored. - -NetBSD's ``/usr/bin/make`` is not GNU make. GNU make is installed as -``/usr/pkg/bin/gmake`` by the above mentioned ``gmake`` package. - -As all executables installed with pkgsrc are placed in ``/usr/pkg/bin/`` -directory, it might be a good idea to add it to your PATH. Or install OVS by -``gmake`` and ``gmake install``. diff --git a/Documentation/intro/install/userspace.rst b/Documentation/intro/install/userspace.rst deleted file mode 100644 index d18632d6c..000000000 --- a/Documentation/intro/install/userspace.rst +++ /dev/null @@ -1,106 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -=================================== -Open vSwitch without Kernel Support -=================================== - -Open vSwitch can operate, at a cost in performance, entirely in userspace, -without assistance from a kernel module. This file explains how to install -Open vSwitch in such a mode. - -This version of Open vSwitch should be built manually with ``configure`` and -``make``. Debian packaging for Open vSwitch is also included, but it has not -been recently tested, and so Debian packages are not a recommended way to use -this version of Open vSwitch. - -.. warning:: - The userspace-only mode of Open vSwitch without DPDK is considered - experimental. It has not been thoroughly tested. - -Building and Installing ------------------------ - -The requirements and procedure for building, installing, and configuring Open -vSwitch are the same as those given in :doc:`general`. You may omit -configuring, building, and installing the kernel module, and the related -requirements. - -On Linux, the userspace switch additionally requires the kernel TUN/TAP driver -to be available, either built into the kernel or loaded as a module. If you -are not sure, check for a directory named ``/sys/class/misc/tun``. If it does -not exist, then attempt to load the module with ``modprobe tun``. - -The tun device must also exist as ``/dev/net/tun``. If it does not exist, then -create ``/dev/net`` (if necessary) with ``mkdir /dev/net``, then create -``/dev/net/tun`` with ``mknod /dev/net/tun c 10 200``. - -On FreeBSD and NetBSD, the userspace switch additionally requires the kernel -tap(4) driver to be available, either built into the kernel or loaded as a -module. - -Using the Userspace Datapath with ovs-vswitchd ----------------------------------------------- - -To use ovs-vswitchd in userspace mode, create a bridge with -``datapath_type=netdev`` in the configuration database. For example:: - - $ ovs-vsctl add-br br0 - $ ovs-vsctl set bridge br0 datapath_type=netdev - $ ovs-vsctl add-port br0 eth0 - $ ovs-vsctl add-port br0 eth1 - $ ovs-vsctl add-port br0 eth2 - -ovs-vswitchd will create a TAP device as the bridge's local interface, named -the same as the bridge, as well as for each configured internal interface. - -Currently, on FreeBSD, the functionality required for in-band control support -is not implemented. To avoid related errors, you can disable the in-band -support with the following command:: - - $ ovs-vsctl set bridge br0 other_config:disable-in-band=true - -Firewall Rules --------------- - -On Linux, when a physical interface is in use by the userspace datapath, -packets received on the interface still also pass into the kernel TCP/IP stack. -This can cause surprising and incorrect behavior. You can use "iptables" to -avoid this behavior, by using it to drop received packets. For example, to -drop packets received on eth0:: - - $ iptables -A INPUT -i eth0 -j DROP - $ iptables -A FORWARD -i eth0 -j DROP - -Other Settings --------------- - -On NetBSD, depending on your network topology and applications, the following -configuration might help. See sysctl(7).:: - - $ sysctl -w net.inet.ip.checkinterface=1 - -Reporting Bugs --------------- - -Report problems to bugs@openvswitch.org. diff --git a/Documentation/intro/install/windows.rst b/Documentation/intro/install/windows.rst index f696d2c9b..25b4eaa88 100644 --- a/Documentation/intro/install/windows.rst +++ b/Documentation/intro/install/windows.rst @@ -22,781 +22,9 @@ Avoid deeper levels because they do not render well. ======================= -Open vSwitch on Windows +OVN on Windows ======================= -.. _windows-build-reqs: - -Build Requirements ------------------- - -Open vSwitch on Linux uses autoconf and automake for generating Makefiles. It -will be useful to maintain the same build system while compiling on Windows -too. One approach is to compile Open vSwitch in a MinGW environment that -contains autoconf and automake utilities and then use Visual C++ as a compiler -and linker. - -The following explains the steps in some detail. - -- Mingw - - Install Mingw on a Windows machine by following the instructions on - `mingw.org `__. - - This should install mingw at ``C:\Mingw`` and msys at ``C:\Mingw\msys``. Add - ``C:\MinGW\bin`` and ``C:\Mingw\msys\1.0\bin`` to PATH environment variable - of Windows. - - You can either use the MinGW installer or the command line utility - ``mingw-get`` to install both the base packages and additional packages like - automake and autoconf(version 2.68). - - Also make sure that ``/mingw`` mount point exists. If its not, please - add/create the following entry in ``/etc/fstab``:: - - 'C:/MinGW /mingw'. - -- Python - - Install the latest Python 2.x from python.org and verify that its path is - part of Windows' PATH environment variable. - We require that you have Python six and pypiwin32 libraries installed. - The libraries can be installed via pip command: - - :: - - $ pip install six - $ pip install pypiwin32 - -- Visual Studio - - You will need at least Visual Studio 2013 (update 4) to compile userspace - binaries. In addition to that, if you want to compile the kernel module you - will also need to install Windows Driver Kit (WDK) 8.1 Update. - - It is important to get the Visual Studio related environment variables and to - have the $PATH inside the bash to point to the proper compiler and linker. - One easy way to achieve this for VS2013 is to get into the "VS2013 x86 Native - Tools Command Prompt" (in a default installation of Visual Studio 2013 this - can be found under the following location: ``C:\Program Files (x86)\Microsoft - Visual Studio 12.0\Common7\Tools\Shortcuts``) and through it enter into the - bash shell available from msys by typing ``bash --login``. - - There is support for generating 64 bit binaries too. To compile under x64, - open the "VS2013 x64 Native Tools Command Prompt" (if your current running OS - is 64 bit) or "VS2013 x64 Cross Tools Command Prompt" (if your current - running OS is not 64 bit) instead of opening its x86 variant. This will - point the compiler and the linker to their 64 bit equivalent. - - If after the above step, a ``which link`` inside MSYS's bash says, - ``/bin/link.exe``, rename ``/bin/link.exe`` to something else so that the - Visual studio's linker is used. You should also see a 'which sort' report - ``/bin/sort.exe``. - -- pthreads-win32 - - For pthread support, install the library, dll and includes of pthreads-win32 - project from `sourceware - `__ to a - directory (e.g.: ``C:/pthread``). You should add the pthread-win32's dll path - (e.g.: ``C:\pthread\dll\x86``) to the Windows' PATH environment variable. - -- OpenSSL - - To get SSL support for Open vSwitch on Windows, you will need to install - `OpenSSL for Windows `__ - - Note down the directory where OpenSSL is installed (e.g.: - ``C:/OpenSSL-Win32``) for later use. - -.. note:: - - Commands prefixed by ``$`` must be run in the Bash shell provided by MinGW. - Open vSwitch commands, such as ``ovs-dpctl`` are shown running under the DOS - shell (``cmd.exe``), as indicated by the ``>`` prefix, but will also run - under Bash. The remainder, prefixed by ``>``, are PowerShell commands and - must be run in PowerShell. - -Install Requirements --------------------- - -* Share network adaptors - - We require that you don't disable the "Allow management operating system to - share this network adapter" under 'Virtual Switch Properties' > 'Connection - type: External network', in the Hyper-V virtual network switch configuration. - -* Checksum Offloads - - While there is some support for checksum/segmentation offloads in software, - this is still a work in progress. Till the support is complete we recommend - disabling TX/RX offloads for both the VM's as well as the Hyper-V. - -Bootstrapping -------------- - -This step is not needed if you have downloaded a released tarball. If -you pulled the sources directly from an Open vSwitch Git tree or got a -Git tree snapshot, then run boot.sh in the top source directory to build -the "configure" script: - -:: - - $ ./boot.sh - -.. _windows-configuring: - -Configuring ------------ - -Configure the package by running the configure script. You should provide some -configure options to choose the right compiler, linker, libraries, Open vSwitch -component installation directories, etc. For example: - -:: - - $ ./configure CC=./build-aux/cccl LD="$(which link)" \ - LIBS="-lws2_32 -lShlwapi -liphlpapi -lwbemuuid -lole32 -loleaut32" \ - --prefix="C:/openvswitch/usr" \ - --localstatedir="C:/openvswitch/var" \ - --sysconfdir="C:/openvswitch/etc" \ - --with-pthread="C:/pthread" - -.. note:: - - By default, the above enables compiler optimization for fast code. For - default compiler optimization, pass the ``--with-debug`` configure option. - -To configure with SSL support, add the requisite additional options: - -:: - - $ ./configure CC=./build-aux/cccl LD="`which link`" \ - LIBS="-lws2_32 -lShlwapi -liphlpapi -lwbemuuid -lole32 -loleaut32" \ - --prefix="C:/openvswitch/usr" \ - --localstatedir="C:/openvswitch/var" - --sysconfdir="C:/openvswitch/etc" \ - --with-pthread="C:/pthread" \ - --enable-ssl --with-openssl="C:/OpenSSL-Win32" - -Finally, to the kernel module also: - -:: - - $ ./configure CC=./build-aux/cccl LD="`which link`" \ - LIBS="-lws2_32 -lShlwapi -liphlpapi -lwbemuuid -lole32 -loleaut32" \ - --prefix="C:/openvswitch/usr" \ - --localstatedir="C:/openvswitch/var" \ - --sysconfdir="C:/openvswitch/etc" \ - --with-pthread="C:/pthread" \ - --enable-ssl --with-openssl="C:/OpenSSL-Win32" \ - --with-vstudiotarget="" \ - --with-vstudiotargetver="" - -Possible values for ```` are: ``Debug`` and ``Release`` -Possible values for ```` is a comma separated list -of target versions to compile among: ``Win8,Win8.1,Win10`` - -.. note:: - - You can directly use the Visual Studio 2013 IDE to compile the kernel - datapath. Open the ovsext.sln file in the IDE and build the solution. - -Refer to :doc:`general` for information on additional configuration options. - -.. _windows-building: - -Building --------- - -Once correctly configured, building Open vSwitch on Windows is similar to -building on Linux, FreeBSD, or NetBSD. - -#. Run make for the ported executables in the top source directory, e.g.: - - :: - - $ make - - For faster compilation, you can pass the ``-j`` argument to make. For - example, to run 4 jobs simultaneously, run ``make -j4``. - - .. note:: - - MSYS 1.0.18 has a bug that causes parallel make to hang. You can overcome - this by downgrading to MSYS 1.0.17. A simple way to downgrade is to exit - all MinGW sessions and then run the below command from MSVC developers - command prompt.: - - :: - - > mingw-get upgrade msys-core-bin=1.0.17-1 - -#. To run all the unit tests in Open vSwitch, one at a time: - - :: - - $ make check - - To run all the unit tests in Open vSwitch, up to 8 in parallel: - - :: - - $ make check TESTSUITEFLAGS="-j8" - -#. To install all the compiled executables on the local machine, run: - - :: - - $ make install - - .. note:: - - This will install the Open vSwitch executables in ``C:/openvswitch``. You - can add ``C:\openvswitch\usr\bin`` and ``C:\openvswitch\usr\sbin`` to - Windows' PATH environment variable for easy access. - -The Kernel Module -~~~~~~~~~~~~~~~~~ - -If you are building the kernel module, you will need to copy the below files to -the target Hyper-V machine. - -- ``./datapath-windows/x64/Win8.1Debug/package/ovsext.inf`` -- ``./datapath-windows/x64/Win8.1Debug/package/OVSExt.sys`` -- ``./datapath-windows/x64/Win8.1Debug/package/ovsext.cat`` -- ``./datapath-windows/misc/install.cmd`` -- ``./datapath-windows/misc/uninstall.cmd`` - -.. note:: - - The above path assumes that the kernel module has been built using Windows - DDK 8.1 in Debug mode. Change the path appropriately, if a different WDK has - been used. - -Now run ``./uninstall.cmd`` to remove the old extension. Once complete, run -``./install.cmd`` to insert the new one. For this to work you will have to -turn on ``TESTSIGNING`` boot option or 'Disable Driver Signature -Enforcement' during boot. The following commands can be used: - -:: - - > bcdedit /set LOADOPTIONS DISABLE_INTEGRITY_CHECKS - > bcdedit /set TESTSIGNING ON - > bcdedit /set nointegritychecks ON - -.. note:: - - You may have to restart the machine for the settings to take effect. - -In the Virtual Switch Manager configuration you can enable the Open vSwitch -Extension on an existing switch or create a new switch. If you are using an -existing switch, make sure to enable the "Allow Management OS" option for VXLAN -to work (covered later). - -The command to create a new switch named 'OVS-Extended-Switch' using a physical -NIC named 'Ethernet 1' is: - -:: - - PS > New-VMSwitch "OVS-Extended-Switch" -NetAdapterName "Ethernet 1" - -.. note:: - - You can obtain the list of physical NICs on the host using 'Get-NetAdapter' - command. - -In the properties of any switch, you should should now see "Open vSwitch -Extension" under 'Extensions'. Click the check box to enable the extension. -An alternative way to do the same is to run the following command: - -:: - - PS > Enable-VMSwitchExtension "Open vSwitch Extension" OVS-Extended-Switch - -.. note:: - - If you enabled the extension using the command line, a delay of a few - seconds has been observed for the change to be reflected in the UI. This is - not a bug in Open vSwitch. - -Starting --------- - -.. important:: - - The following steps assume that you have installed the Open vSwitch - utilities in the local machine via 'make install'. - -Before starting ovs-vswitchd itself, you need to start its configuration -database, ovsdb-server. Each machine on which Open vSwitch is installed should -run its own copy of ovsdb-server. Before ovsdb-server itself can be started, -configure a database that it can use: - -:: - - > ovsdb-tool create C:\openvswitch\etc\openvswitch\conf.db \ - C:\openvswitch\usr\share\openvswitch\vswitch.ovsschema - -Configure ovsdb-server to use database created above and to listen on a Unix -domain socket: - -:: - - > ovsdb-server -vfile:info --remote=punix:db.sock --log-file \ - --pidfile --detach - -.. note:: - - The logfile is created at ``C:/openvswitch/var/log/openvswitch/`` - -Initialize the database using ovs-vsctl. This is only necessary the first time -after you create the database with ovsdb-tool, though running it at any time is -harmless: - -:: - - > ovs-vsctl --no-wait init - -.. tip:: - - If you would later like to terminate the started ovsdb-server, run: - - :: - - > ovs-appctl -t ovsdb-server exit - -Start the main Open vSwitch daemon, telling it to connect to the same Unix -domain socket: - -:: - - > ovs-vswitchd -vfile:info --log-file --pidfile --detach - -.. tip:: - - If you would like to terminate the started ovs-vswitchd, run: - - :: - - > ovs-appctl exit - -.. note:: - - The logfile is created at ``C:/openvswitch/var/log/openvswitch/`` - -Validating ----------- - -At this point you can use ovs-vsctl to set up bridges and other Open vSwitch -features. - -Add bridges -~~~~~~~~~~~ - -Let's start by creating an integration bridge, ``br-int`` and a PIF bridge, -``br-pif``: - -:: - - > ovs-vsctl add-br br-int - > ovs-vsctl add-br br-pif - -.. note:: - - There's a known bug that running the ovs-vsctl command does not terminate. - This is generally solved by having ovs-vswitchd running. If you face the - issue despite that, hit Ctrl-C to terminate ovs-vsctl and check the output - to see if your command succeeded. - -Validate that ports are added by dumping from both ovs-dpctl and ovs-vsctl: - -:: - - > ovs-dpctl show - system@ovs-system: - lookups: hit:0 missed:0 lost:0 - flows: 0 - port 2: br-pif (internal) <<< internal port on 'br-pif' bridge - port 1: br-int (internal) <<< internal port on 'br-int' bridge - - > ovs-vsctl show - a56ec7b5-5b1f-49ec-a795-79f6eb63228b - Bridge br-pif - Port br-pif - Interface br-pif - type: internal - Bridge br-int - Port br-int - Interface br-int - type: internal - -.. note:: - - There's a known bug that the ports added to OVSDB via ovs-vsctl don't get to - the kernel datapath immediately, ie. they don't show up in the output of - ``ovs-dpctl show`` even though they show up in output of ``ovs-vsctl show``. - In order to workaround this issue, restart ovs-vswitchd. (You can terminate - ovs-vswitchd by running ``ovs-appctl exit``.) - -Add physicals NICs (PIF) -~~~~~~~~~~~~~~~~~~~~~~~~ - -Now, let's add the physical NIC and the internal port to ``br-pif``. In OVS for -Hyper-V, we use the name of the adapter on top of which the Hyper-V virtual -switch was created, as a special name to refer to the physical NICs connected -to the Hyper-V switch, e.g. if we created the Hyper-V virtual switch on top of -the adapter named ``Ethernet0``, then in OVS we use that name (``Ethernet0``) -as a special name to refer to that adapter. - -.. note:: - - We assume that the OVS extension is enabled Hyper-V switch. - -Internal ports are the virtual adapters created on the Hyper-V switch using the -``ovs-vsctl add-br `` command. By default they are created under the -following rule "" and the adapters are disabled. One needs to -enable them and set the corresponding values to it to make them IP-able. - -As a whole example, if we issue the following in a powershell console: - -:: - - PS > Get-NetAdapter | select Name,InterfaceDescription - Name InterfaceDescription - ---- -------------------- - Ethernet1 Intel(R) PRO/1000 MT Network Connection - br-pif Hyper-V Virtual Ethernet Adapter #2 - Ethernet0 Intel(R) PRO/1000 MT Network Connection #2 - br-int Hyper-V Virtual Ethernet Adapter #3 - - PS > Get-VMSwitch - Name SwitchType NetAdapterInterfaceDescription - ---- ---------- ------------------------------ - external External Intel(R) PRO/1000 MT Network Connection #2 - -We can see that we have a switch(external) created upon adapter name -'Ethernet0' with the internal ports under name 'br-pif' and 'br-int'. Thus -resulting into the following ovs-vsctl commands: - -:: - - > ovs-vsctl add-port br-pif Ethernet0 - -Dumping the ports should show the additional ports that were just added: - -:: - - > ovs-dpctl show - system@ovs-system: - lookups: hit:0 missed:0 lost:0 - flows: 0 - port 2: br-pif (internal) <<< internal port - adapter on - Hyper-V switch - port 1: br-int (internal) <<< internal port - adapter on - Hyper-V switch - port 3: Ethernet0 <<< Physical NIC - - > ovs-vsctl show - a56ec7b5-5b1f-49ec-a795-79f6eb63228b - Bridge br-pif - Port br-pif - Interface br-pif - type: internal - Port "Ethernet0" - Interface "Ethernet0" - Bridge br-int - Port br-int - Interface br-int - type: internal - -Add virtual interfaces (VIFs) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -Adding VIFs to Open vSwitch is a two step procedure. The first step is to -assign a 'OVS port name' which is a unique name across all VIFs on this -Hyper-V. The next step is to add the VIF to the ovsdb using its 'OVS port -name' as key. - -First, assign a unique 'OVS port name' to the VIF. The VIF needs to have been -disconnected from the Hyper-V switch before assigning a 'OVS port name' to it. -In the example below, we assign a 'OVS port name' called ``ovs-port-a`` to a -VIF on a VM ``VM1``. By using index 0 for ``$vnic``, the first VIF of the VM -is being addressed. After assigning the name ``ovs-port-a``, the VIF is -connected back to the Hyper-V switch with name ``OVS-HV-Switch``, which is -assumed to be the Hyper-V switch with OVS extension enabled.: - -:: - - PS > import-module .\datapath-windows\misc\OVS.psm1 - PS > $vnic = Get-VMNetworkAdapter - PS > Disconnect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] - PS > $vnic[0] | Set-VMNetworkAdapterOVSPort -OVSPortName ovs-port-a - PS > Connect-VMNetworkAdapter -VMNetworkAdapter $vnic[0] \ - -SwitchName OVS-Extended-Switch - -Next, add the VIFs to ``br-int``: - -:: - - > ovs-vsctl add-port br-int ovs-port-a - -Dumping the ports should show the additional ports that were just added: - -:: - - > ovs-dpctl show - system@ovs-system: - lookups: hit:0 missed:0 lost:0 - flows: 0 - port 4: ovs-port-a - port 2: br-pif (internal) - port 1: br-int (internal - port 3: Ethernet0 - - > ovs-vsctl show - 4cd86499-74df-48bd-a64d-8d115b12a9f2 - Bridge br-pif - Port "vEthernet (external)" - Interface "vEthernet (external)" - Port "Ethernet0" - Interface "Ethernet0" - Port br-pif - Interface br-pif - type: internal - Bridge br-int - Port br-int - Interface br-int - type: internal - Port "ovs-port-a" - Interface "ovs-port-a" - -Add multiple NICs to be managed by OVS -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To leverage support of multiple NICs into OVS, we will be using the MSFT -cmdlets for forwarding team extension. More documentation about them can be -found at technet_. - -.. _technet: https://technet.microsoft.com/en-us/library/jj553812%28v=wps.630%29.aspx - -For example, to set up a switch team combined from ``Ethernet0 2`` and -``Ethernet1 2`` named ``external``: - -:: - - PS > Get-NetAdapter - Name InterfaceDescription - ---- -------------------- - br-int Hyper-V Virtual Ethernet Adapter #3 - br-pif Hyper-V Virtual Ethernet Adapter #2 - Ethernet3 2 Intel(R) 82574L Gigabit Network Co...#3 - Ethernet2 2 Intel(R) 82574L Gigabit Network Co...#4 - Ethernet1 2 Intel(R) 82574L Gigabit Network Co...#2 - Ethernet0 2 Intel(R) 82574L Gigabit Network Conn... - - PS > New-NetSwitchTeam -Name external -TeamMembers "Ethernet0 2","Ethernet1 2" - - PS > Get-NetSwitchTeam - Name : external - Members : {Ethernet1 2, Ethernet0 2} - -This will result in a new adapter bound to the host called ``external``: - -:: - - PS > Get-NetAdapter - Name InterfaceDescription - ---- -------------------- - br-test Hyper-V Virtual Ethernet Adapter #4 - br-pif Hyper-V Virtual Ethernet Adapter #2 - external Microsoft Network Adapter Multiplexo... - Ethernet3 2 Intel(R) 82574L Gigabit Network Co...#3 - Ethernet2 2 Intel(R) 82574L Gigabit Network Co...#4 - Ethernet1 2 Intel(R) 82574L Gigabit Network Co...#2 - Ethernet0 2 Intel(R) 82574L Gigabit Network Conn... - -Next we will set up the Hyper-V VMSwitch on the new adapter ``external``: - -:: - - PS > New-VMSwitch -Name external -NetAdapterName external \ - -AllowManagementOS $false - -Under OVS the adapters under the team ``external``, ``Ethernet0 2`` and -``Ethernet1 2``, can be added either under a bond device or separately. - -The following example shows how the bridges look with the NICs being -separated: - -:: - - > ovs-vsctl show - 6cd9481b-c249-4ee3-8692-97b399dd29d8 - Bridge br-test - Port br-test - Interface br-test - type: internal - Port "Ethernet1 2" - Interface "Ethernet1 2" - Bridge br-pif - Port "Ethernet0 2" - Interface "Ethernet0 2" - Port br-pif - Interface br-pif - type: internal - -Add patch ports and configure VLAN tagging -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Windows Open vSwitch implementation support VLAN tagging in the switch. -Switch VLAN tagging along with patch ports between ``br-int`` and ``br-pif`` is -used to configure VLAN tagging functionality between two VMs on different -Hyper-Vs. To start, add a patch port from ``br-int`` to ``br-pif``: - -:: - - > ovs-vsctl add-port br-int patch-to-pif - > ovs-vsctl set interface patch-to-pif type=patch \ - options:peer=patch-to-int - -Add a patch port from ``br-pif`` to ``br-int``: - -:: - - > ovs-vsctl add-port br-pif patch-to-int - > ovs-vsctl set interface patch-to-int type=patch \ - options:peer=patch-to-pif - -Re-Add the VIF ports with the VLAN tag: - -:: - - > ovs-vsctl add-port br-int ovs-port-a tag=900 - > ovs-vsctl add-port br-int ovs-port-b tag=900 - -Add tunnels -~~~~~~~~~~~ - -The Windows Open vSwitch implementation support VXLAN and STT tunnels. To add -tunnels. For example, first add the tunnel port between 172.168.201.101 <-> -172.168.201.102: - -:: - - > ovs-vsctl add-port br-int tun-1 - > ovs-vsctl set Interface tun-1 type= - > ovs-vsctl set Interface tun-1 options:local_ip=172.168.201.101 - > ovs-vsctl set Interface tun-1 options:remote_ip=172.168.201.102 - > ovs-vsctl set Interface tun-1 options:in_key=flow - > ovs-vsctl set Interface tun-1 options:out_key=flow - -...and the tunnel port between 172.168.201.101 <-> 172.168.201.105: - -:: - - > ovs-vsctl add-port br-int tun-2 - > ovs-vsctl set Interface tun-2 type= - > ovs-vsctl set Interface tun-2 options:local_ip=172.168.201.102 - > ovs-vsctl set Interface tun-2 options:remote_ip=172.168.201.105 - > ovs-vsctl set Interface tun-2 options:in_key=flow - > ovs-vsctl set Interface tun-2 options:out_key=flow - -Where ```` is one of: ``stt`` or ``vxlan`` - -.. note:: - - Any patch ports created between br-int and br-pif MUST be be deleted prior - to adding tunnels. - -Windows Services ----------------- - -Open vSwitch daemons come with support to run as a Windows service. The -instructions here assume that you have installed the Open vSwitch utilities and -daemons via ``make install``. - -To start, create the database: - -:: - - > ovsdb-tool create C:/openvswitch/etc/openvswitch/conf.db \ - "C:/openvswitch/usr/share/openvswitch/vswitch.ovsschema" - -Create the ovsdb-server service and start it: - -:: - - > sc create ovsdb-server \ - binpath="C:/openvswitch/usr/sbin/ovsdb-server.exe \ - C:/openvswitch/etc/openvswitch/conf.db \ - -vfile:info --log-file --pidfile \ - --remote=punix:db.sock --service --service-monitor" - > sc start ovsdb-server - -.. tip:: - - One of the common issues with creating a Windows service is with mungled - paths. You can make sure that the correct path has been registered with the - Windows services manager by running: - - :: - - > sc qc ovsdb-server - -Check that the service is healthy by running: - -:: - - > sc query ovsdb-server - -Initialize the database: - -:: - - > ovs-vsctl --no-wait init - -Create the ovs-vswitchd service and start it: - -:: - - > sc create ovs-vswitchd \ - binpath="C:/openvswitch/usr/sbin/ovs-vswitchd.exe \ - --pidfile -vfile:info --log-file --service --service-monitor" - > sc start ovs-vswitchd - -Check that the service is healthy by running: - -:: - - > sc query ovs-vswitchd - -To stop and delete the services, run: - -:: - - > sc stop ovs-vswitchd - > sc stop ovsdb-server - > sc delete ovs-vswitchd - > sc delete ovsdb-server - -Windows CI Service ------------------- - -`AppVeyor `__ provides a free Windows autobuild service for -open source projects. Open vSwitch has integration with AppVeyor for continuous -build. A developer can build test his changes for Windows by logging into -appveyor.com using a github account, creating a new project by linking it to -his development repository in github and triggering a new build. - TODO ---- - -* Investigate the working of sFlow on Windows and re-enable the unit tests. - -* Investigate and add the feature to provide QoS. - -* Sign the driver & create an MSI for installing the different Open vSwitch - components on Windows. +* This document needs to be updated. diff --git a/Documentation/intro/install/xenserver.rst b/Documentation/intro/install/xenserver.rst deleted file mode 100644 index c0f5e3156..000000000 --- a/Documentation/intro/install/xenserver.rst +++ /dev/null @@ -1,229 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -================================ -Open vSwitch on Citrix XenServer -================================ - -This document describes how to build and install Open vSwitch on a Citrix -XenServer host. If you want to install Open vSwitch on a generic Linux or BSD -host, refer to :doc:`general` instead. - -Open vSwitch should work with XenServer 5.6.100 and later. However, Open -vSwitch requires Python 2.7 or later, so using Open vSwitch with XenServer 6.5 -or earlier requires installing Python 2.7. - -Building --------- - -You may build from an Open vSwitch distribution tarball or from an Open vSwitch -Git tree. The recommended build environment to build RPMs for Citrix XenServer -is the DDK VM available from Citrix. - -1. If you are building from an Open vSwitch Git tree, then you will need to - first create a distribution tarball by running:: - - $ ./boot.sh - $ ./configure - $ make dist - - You cannot run this in the DDK VM, because it lacks tools that are necessary - to bootstrap the Open vSwitch distribution. Instead, you must run this on a - machine that has the tools listed in :ref:`general-install-reqs` as - prerequisites for building from a Git tree. - -2. Copy the distribution tarball into ``/usr/src/redhat/SOURCES`` inside - the DDK VM. - -3. In the DDK VM, unpack the distribution tarball into a temporary directory - and "cd" into the root of the distribution tarball. - -4. To build Open vSwitch userspace, run:: - - $ rpmbuild -bb xenserver/openvswitch-xen.spec - - This produces three RPMs in ``/usr/src/redhat/RPMS/i386``: - - - ``openvswitch`` - - ``openvswitch-modules-xen`` - - ``openvswitch-debuginfo`` - - The above command automatically runs the Open vSwitch unit tests. To - disable the unit tests, run:: - - $ rpmbuild -bb --without check xenserver/openvswitch-xen.spec - -Build Parameters ----------------- - -``openvswitch-xen.spec`` needs to know a number of pieces of information about -the XenServer kernel. Usually, it can figure these out for itself, but if it -does not do it correctly then you can specify them yourself as parameters to -the build. Thus, the final ``rpmbuild`` step above can be elaborated as:: - - $ VERSION= - $ KERNEL_NAME= - $ KERNEL_VERSION= - $ KERNEL_FLAVOR= - $ rpmbuild \ - -D "openvswitch_version $VERSION" \ - -D "kernel_name $KERNEL_NAME" \ - -D "kernel_version $KERNEL_VERSION" \ - -D "kernel_flavor $KERNEL_FLAVOR" \ - -bb xenserver/openvswitch-xen.spec - -where: - -```` - is the version number that appears in the name of the Open vSwitch tarball, - e.g. 0.90.0. - -```` - is the name of the XenServer kernel package, e.g. ``kernel-xen`` or - ``kernel-NAME-xen``, without the ``kernel-`` prefix. - -```` - is the output of:: - - $ rpm -q --queryformat "%{Version}-%{Release}" , - - e.g. ``2.6.32.12-0.7.1.xs5.6.100.323.170596``, where - ```` is the name of the ``-devel`` package - corresponding to ````. - -```` - is either ``xen`` or ``kdump``, where ``xen`` flavor is the main running - kernel flavor and the ``kdump`` flavor is the crashdump kernel flavor. - Commonly, one would specify ``xen`` here. - -For XenServer 6.5 or above, the kernel version naming no longer contains -KERNEL_FLAVOR. In fact, only providing the ``uname -r`` output is enough. So, -the final ``rpmbuild`` step changes to:: - - $ KERNEL_UNAME=<`uname -r` output> - $ rpmbuild \ - -D "kenel_uname $KERNEL_UNAME" \ - -bb xenserver/openvswitch-xen.spec - -Installing Open vSwitch for XenServer -------------------------------------- - -To install Open vSwitch on a XenServer host, or to upgrade to a newer version, -copy the ``openvswitch`` and ``openvswitch-modules-xen`` RPMs to that host with -``scp``, then install them with ``rpm -U``, e.g.:: - - $ scp openvswitch-$VERSION-1.i386.rpm \ - openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm \ - root@: - # Enter 's root password. - $ ssh root@ - # Enter 's root password again. - $ rpm -U openvswitch-$VERSION-1.i386.rpm \ - openvswitch-modules-xen-$XEN_KERNEL_VERSION-$VERSION-1.i386.rpm - -To uninstall Open vSwitch from a XenServer host, remove the packages:: - - $ ssh root@ - # Enter 's root password again. - $ rpm -e openvswitch openvswitch-modules-xen-$XEN_KERNEL_VERSION - -After installing or uninstalling Open vSwitch, the XenServer should be rebooted -as soon as possible. - -Open vSwitch Boot Sequence on XenServer ---------------------------------------- - -When Open vSwitch is installed on XenServer, its startup script -``/etc/init.d/openvswitch`` runs early in boot. It does roughly the following: - -* Loads the OVS kernel module, openvswitch. - -* Starts ovsdb-server, the OVS configuration database. - -* XenServer expects there to be no bridges configured at startup, but the OVS - configuration database likely still has bridges configured from before - reboot. To match XenServer expectations, the startup script deletes all - configured bridges from the database. - -* Starts ovs-vswitchd, the OVS switching daemon. - -At this point in the boot process, then, there are no Open vSwitch bridges, -even though all of the Open vSwitch daemons are running. Later on in boot, -``/etc/init.d/management-interface`` (part of XenServer, not Open vSwitch) -creates the bridge for the XAPI management interface by invoking -``/opt/xensource/libexec/interface-reconfigure``. Normally this program -consults XAPI's database to obtain information about how to configure the -bridge, but XAPI is not running yet(\*) so it instead consults -``/var/xapi/network.dbcache``, which is a cached copy of the most recent -network configuration. - -(\*) Even if XAPI were running, if this XenServer node is a pool slave then the - query would have to consult the master, which requires network access, - which begs the question of how to configure the management interface. - -XAPI starts later on in the boot process. XAPI can then create other bridges -on demand using ``/opt/xensource/libexec/interface-reconfigure``. Now that -XAPI is running, that program consults XAPI directly instead of reading the -cache. - -As part of its own startup, XAPI invokes the Open vSwitch XAPI plugin script -``/etc/xapi.d/openvswitch-cfg-update`` passing the ``update`` command. The -plugin script does roughly the following: - -* Calls ``/opt/xensource/libexec/interface-reconfigure`` with the ``rewrite`` - command, to ensure that the network cache is up-to-date. - -* Queries the Open vSwitch manager setting (named ``vswitch_controller``) from - the XAPI database for the XenServer pool. - -* If XAPI and OVS are configured for different managers, or if OVS is - configured for a manager but XAPI is not, runs ``ovs-vsctl emer-reset`` to - bring the Open vSwitch configuration to a known state. One effect of - emer-reset is to deconfigure any manager from the OVS database. - -* If XAPI is configured for a manager, configures the OVS manager to match with - ``ovs-vsctl set-manager``. - -Notes ------ - -* The Open vSwitch boot sequence only configures an OVS configuration database - manager. There is no way to directly configure an OpenFlow controller on - XenServer and, as a consequence of the step above that deletes all of the - bridges at boot time, controller configuration only persists until XenServer - reboot. The configuration database manager can, however, configure - controllers for bridges. See the BUGS section of ovs-testcontroller(8) for - more information on this topic. - -* The Open vSwitch startup script automatically adds a firewall rule to allow - GRE traffic. This rule is needed for the XenServer feature called "Cross-Host - Internal Networks" (CHIN) that uses GRE. If a user configures tunnels other - than GRE (ex: Geneve, VXLAN, LISP), they will have to either manually add a - iptables firewall rule to allow the tunnel traffic or add it through a - startup script (Please refer to the "enable-protocol" command in the - ovs-ctl(8) manpage). - -Reporting Bugs --------------- - -Please report problems to bugs@openvswitch.org. diff --git a/Documentation/intro/what-is-ovs.rst b/Documentation/intro/what-is-ovs.rst deleted file mode 100644 index bf7071f7a..000000000 --- a/Documentation/intro/what-is-ovs.rst +++ /dev/null @@ -1,41 +0,0 @@ -.. - Copyright (c) 2016, Stephen Finucane - - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -===================== -What Is Open vSwitch? -===================== - -.. image:: ../_static/overview.png - :align: center - -Overview --------- - -.. NOTE(stephenfin): The below line numbers may need to be updated if the - README is modified - -.. include:: ../../README.rst - :start-line: 13 - :end-line: 71 diff --git a/Documentation/intro/why-ovs.rst b/Documentation/intro/why-ovs.rst deleted file mode 100644 index e73066a76..000000000 --- a/Documentation/intro/why-ovs.rst +++ /dev/null @@ -1,131 +0,0 @@ -.. - Licensed under the Apache License, Version 2.0 (the "License"); you may - not use this file except in compliance with the License. You may obtain - a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, WITHOUT - WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the - License for the specific language governing permissions and limitations - under the License. - - Convention for heading levels in Open vSwitch documentation: - - ======= Heading 0 (reserved for the title in a document) - ------- Heading 1 - ~~~~~~~ Heading 2 - +++++++ Heading 3 - ''''''' Heading 4 - - Avoid deeper levels because they do not render well. - -================= -Why Open vSwitch? -================= - -Hypervisors need the ability to bridge traffic between VMs and with the outside -world. On Linux-based hypervisors, this used to mean using the built-in L2 -switch (the Linux bridge), which is fast and reliable. So, it is reasonable to -ask why Open vSwitch is used. - -The answer is that Open vSwitch is targeted at multi-server virtualization -deployments, a landscape for which the previous stack is not well suited. These -environments are often characterized by highly dynamic end-points, the -maintenance of logical abstractions, and (sometimes) integration with or -offloading to special purpose switching hardware. - -The following characteristics and design considerations help Open vSwitch cope -with the above requirements. - -The mobility of state ---------------------- - -All network state associated with a network entity (say a virtual machine) -should be easily identifiable and migratable between different hosts. This may -include traditional "soft state" (such as an entry in an L2 learning table), L3 -forwarding state, policy routing state, ACLs, QoS policy, monitoring -configuration (e.g. NetFlow, IPFIX, sFlow), etc. - -Open vSwitch has support for both configuring and migrating both slow -(configuration) and fast network state between instances. For example, if a VM -migrates between end-hosts, it is possible to not only migrate associated -configuration (SPAN rules, ACLs, QoS) but any live network state (including, -for example, existing state which may be difficult to reconstruct). Further, -Open vSwitch state is typed and backed by a real data-model allowing for the -development of structured automation systems. - -Responding to network dynamics ------------------------------- - -Virtual environments are often characterized by high-rates of change. VMs -coming and going, VMs moving backwards and forwards in time, changes to the -logical network environments, and so forth. - -Open vSwitch supports a number of features that allow a network control system -to respond and adapt as the environment changes. This includes simple -accounting and visibility support such as NetFlow, IPFIX, and sFlow. But -perhaps more useful, Open vSwitch supports a network state database (OVSDB) -that supports remote triggers. Therefore, a piece of orchestration software can -"watch" various aspects of the network and respond if/when they change. This is -used heavily today, for example, to respond to and track VM migrations. - -Open vSwitch also supports OpenFlow as a method of exporting remote access to -control traffic. There are a number of uses for this including global network -discovery through inspection of discovery or link-state traffic (e.g. LLDP, -CDP, OSPF, etc.). - -Maintenance of logical tags ----------------------------- - -Distributed virtual switches (such as VMware vDS and Cisco's Nexus 1000V) often -maintain logical context within the network through appending or manipulating -tags in network packets. This can be used to uniquely identify a VM (in a -manner resistant to hardware spoofing), or to hold some other context that is -only relevant in the logical domain. Much of the problem of building a -distributed virtual switch is to efficiently and correctly manage these tags. - -Open vSwitch includes multiple methods for specifying and maintaining tagging -rules, all of which are accessible to a remote process for orchestration. -Further, in many cases these tagging rules are stored in an optimized form so -they don't have to be coupled with a heavyweight network device. This allows, -for example, thousands of tagging or address remapping rules to be configured, -changed, and migrated. - -In a similar vein, Open vSwitch supports a GRE implementation that can handle -thousands of simultaneous GRE tunnels and supports remote configuration for -tunnel creation, configuration, and tear-down. This, for example, can be used -to connect private VM networks in different data centers. - -Hardware integration --------------------- - -Open vSwitch's forwarding path (the in-kernel datapath) is designed to be -amenable to "offloading" packet processing to hardware chipsets, whether housed -in a classic hardware switch chassis or in an end-host NIC. This allows for the -Open vSwitch control path to be able to both control a pure software -implementation or a hardware switch. - -There are many ongoing efforts to port Open vSwitch to hardware chipsets. These -include multiple merchant silicon chipsets (Broadcom and Marvell), as well as a -number of vendor-specific platforms. The "Porting" section in the documentation -discusses how one would go about making such a port. - -The advantage of hardware integration is not only performance within -virtualized environments. If physical switches also expose the Open vSwitch -control abstractions, both bare-metal and virtualized hosting environments can -be managed using the same mechanism for automated network control. - -Summary -------- - -In many ways, Open vSwitch targets a different point in the design space than -previous hypervisor networking stacks, focusing on the need for automated and -dynamic network control in large-scale Linux-based virtualization environments. - -The goal with Open vSwitch is to keep the in-kernel code as small as possible -(as is necessary for performance) and to re-use existing subsystems when -applicable (for example Open vSwitch uses the existing QoS stack). As of Linux -3.3, Open vSwitch is included as a part of the kernel and packaging for the -userspace utilities are available on most popular distributions. From patchwork Wed Jun 12 07:19:32 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Numan Siddique X-Patchwork-Id: 1114329 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45NyyG4DVmz9sDB for ; Wed, 12 Jun 2019 17:23:02 +1000 (AEST) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id E80CF164B; Wed, 12 Jun 2019 07:21:57 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 455E015EA for ; Wed, 12 Jun 2019 07:19:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7264587E for ; Wed, 12 Jun 2019 07:19:42 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6BFEB30C1AE8 for ; Wed, 12 Jun 2019 07:19:37 +0000 (UTC) Received: from nusiddiq.mac (unknown [10.74.10.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id 500055D9C9 for ; Wed, 12 Jun 2019 07:19:34 +0000 (UTC) From: nusiddiq@redhat.com To: dev@openvswitch.org Date: Wed, 12 Jun 2019 12:49:32 +0530 Message-Id: <20190612071932.24476-1-nusiddiq@redhat.com> In-Reply-To: <20190612071822.24182-1-nusiddiq@redhat.com> References: <20190612071822.24182-1-nusiddiq@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 12 Jun 2019 07:19:37 +0000 (UTC) X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, URI_NOVOWEL autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [ovs-dev] [PATCH ovn 4/4] cleanup rhel folder X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org From: Numan Siddique The patch renames the make target - 'rpm-fedora-ovn' to 'rpm-fedora' Signed-off-by: Numan Siddique Acked-by: Ben Pfaff Tested-by: Lorenzo Bianconi --- rhel/automake.mk | 59 +- rhel/etc_init.d_openvswitch | 102 ---- rhel/etc_logrotate.d_openvswitch | 22 - rhel/etc_openvswitch_default.conf | 5 - rhel/etc_sysconfig_network-scripts_ifdown-ovs | 71 --- rhel/etc_sysconfig_network-scripts_ifup-ovs | 226 -------- rhel/kmod-openvswitch-rhel6.spec.in | 122 ---- rhel/openvswitch-dkms.spec.in | 100 ---- rhel/openvswitch-fedora.spec.in | 540 ------------------ rhel/openvswitch-kmod-fedora.spec.in | 134 ----- rhel/openvswitch.spec.in | 282 --------- ...b_systemd_system_openvswitch-ipsec.service | 14 - ...usr_lib_systemd_system_openvswitch.service | 17 - ..._system_ovs-delete-transient-ports.service | 10 - ...lib_systemd_system_ovs-vswitchd.service.in | 32 -- ...sr_lib_systemd_system_ovsdb-server.service | 26 - rhel/usr_lib_udev_rules.d_91-vfio.rules | 1 - ...are_openvswitch_scripts_ovs-kmod-manage.sh | 160 ------ ...are_openvswitch_scripts_ovs-systemd-reload | 49 -- ...are_openvswitch_scripts_sysconfig.template | 24 - ...vswitch_scripts_systemd_sysconfig.template | 31 - 21 files changed, 1 insertion(+), 2026 deletions(-) delete mode 100755 rhel/etc_init.d_openvswitch delete mode 100644 rhel/etc_logrotate.d_openvswitch delete mode 100644 rhel/etc_openvswitch_default.conf delete mode 100755 rhel/etc_sysconfig_network-scripts_ifdown-ovs delete mode 100755 rhel/etc_sysconfig_network-scripts_ifup-ovs delete mode 100644 rhel/kmod-openvswitch-rhel6.spec.in delete mode 100644 rhel/openvswitch-dkms.spec.in delete mode 100644 rhel/openvswitch-fedora.spec.in delete mode 100644 rhel/openvswitch-kmod-fedora.spec.in delete mode 100644 rhel/openvswitch.spec.in delete mode 100644 rhel/usr_lib_systemd_system_openvswitch-ipsec.service delete mode 100644 rhel/usr_lib_systemd_system_openvswitch.service delete mode 100644 rhel/usr_lib_systemd_system_ovs-delete-transient-ports.service delete mode 100644 rhel/usr_lib_systemd_system_ovs-vswitchd.service.in delete mode 100644 rhel/usr_lib_systemd_system_ovsdb-server.service delete mode 100644 rhel/usr_lib_udev_rules.d_91-vfio.rules delete mode 100644 rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh delete mode 100755 rhel/usr_share_openvswitch_scripts_ovs-systemd-reload delete mode 100644 rhel/usr_share_openvswitch_scripts_sysconfig.template delete mode 100644 rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template diff --git a/rhel/automake.mk b/rhel/automake.mk index 1c5bf153c..be7c275a7 100644 --- a/rhel/automake.mk +++ b/rhel/automake.mk @@ -8,83 +8,26 @@ EXTRA_DIST += \ rhel/README.RHEL.rst \ rhel/automake.mk \ - rhel/etc_init.d_openvswitch \ - rhel/etc_logrotate.d_openvswitch \ - rhel/etc_openvswitch_default.conf \ - rhel/etc_sysconfig_network-scripts_ifdown-ovs \ - rhel/etc_sysconfig_network-scripts_ifup-ovs \ - rhel/openvswitch-dkms.spec \ - rhel/openvswitch-dkms.spec.in \ - rhel/kmod-openvswitch-rhel6.spec \ - rhel/kmod-openvswitch-rhel6.spec.in \ - rhel/openvswitch-kmod-fedora.spec \ - rhel/openvswitch-kmod-fedora.spec.in \ - rhel/openvswitch.spec \ - rhel/openvswitch.spec.in \ - rhel/openvswitch-fedora.spec \ - rhel/openvswitch-fedora.spec.in \ rhel/ovn-fedora.spec \ rhel/ovn-fedora.spec.in \ - rhel/usr_share_openvswitch_scripts_ovs-systemd-reload \ - rhel/usr_share_openvswitch_scripts_sysconfig.template \ - rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template \ - rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh \ - rhel/usr_lib_udev_rules.d_91-vfio.rules \ - rhel/usr_lib_systemd_system_openvswitch.service \ - rhel/usr_lib_systemd_system_ovsdb-server.service \ - rhel/usr_lib_systemd_system_ovs-vswitchd.service.in \ - rhel/usr_lib_systemd_system_ovs-delete-transient-ports.service \ rhel/usr_lib_systemd_system_ovn-controller.service \ rhel/usr_lib_systemd_system_ovn-controller-vtep.service \ rhel/usr_lib_systemd_system_ovn-northd.service \ - rhel/usr_lib_systemd_system_openvswitch-ipsec.service \ rhel/usr_lib_firewalld_services_ovn-central-firewall-service.xml \ rhel/usr_lib_firewalld_services_ovn-host-firewall-service.xml -DISTCLEANFILES += rhel/usr_lib_systemd_system_ovs-vswitchd.service - update_rhel_spec = \ $(AM_V_GEN)($(ro_shell) && sed -e 's,[@]VERSION[@],$(VERSION),g') \ < $(srcdir)/rhel/$(@F).in > $(@F).tmp || exit 1; \ if cmp -s $(@F).tmp $@; then touch $@; rm $(@F).tmp; else mv $(@F).tmp $@; fi -$(srcdir)/rhel/openvswitch-dkms.spec: rhel/openvswitch-dkms.spec.in $(top_builddir)/config.status - $(update_rhel_spec) - -$(srcdir)/rhel/kmod-openvswitch-rhel6.spec: rhel/kmod-openvswitch-rhel6.spec.in $(top_builddir)/config.status - $(update_rhel_spec) - -$(srcdir)/rhel/openvswitch-kmod-fedora.spec: rhel/openvswitch-kmod-fedora.spec.in $(top_builddir)/config.status - $(update_rhel_spec) - -$(srcdir)/rhel/openvswitch.spec: rhel/openvswitch.spec.in $(top_builddir)/config.status - $(update_rhel_spec) - -$(srcdir)/rhel/openvswitch-fedora.spec: rhel/openvswitch-fedora.spec.in $(top_builddir)/config.status - $(update_rhel_spec) - RPMBUILD_TOP := $(abs_top_builddir)/rpm/rpmbuild RPMBUILD_OPT ?= --without check -# Build user-space RPMs -rpm-fedora: dist $(srcdir)/rhel/openvswitch-fedora.spec - ${MKDIR_P} ${RPMBUILD_TOP}/SOURCES - cp ${DIST_ARCHIVES} ${RPMBUILD_TOP}/SOURCES - rpmbuild ${RPMBUILD_OPT} \ - -D "_topdir ${RPMBUILD_TOP}" \ - -ba $(srcdir)/rhel/openvswitch-fedora.spec - -rpm-fedora-ovn: dist $(srcdir)/rhel/ovn-fedora.spec +rpm-fedora: dist $(srcdir)/rhel/ovn-fedora.spec ${MKDIR_P} ${RPMBUILD_TOP}/SOURCES cp ${DIST_ARCHIVES} ${RPMBUILD_TOP}/SOURCES rpmbuild ${RPMBUILD_OPT} \ -D "_topdir ${RPMBUILD_TOP}" \ -ba $(srcdir)/rhel/ovn-fedora.spec -# Build kernel datapath RPM -rpm-fedora-kmod: dist $(srcdir)/rhel/openvswitch-kmod-fedora.spec - ${MKDIR_P} ${RPMBUILD_TOP}/SOURCES - cp ${DIST_ARCHIVES} ${RPMBUILD_TOP}/SOURCES - rpmbuild -D "kversion $(shell uname -r)" ${RPMBUILD_OPT} \ - -D "_topdir ${RPMBUILD_TOP}" \ - -ba $(srcdir)/rhel/openvswitch-kmod-fedora.spec diff --git a/rhel/etc_init.d_openvswitch b/rhel/etc_init.d_openvswitch deleted file mode 100755 index 7a4cfbab5..000000000 --- a/rhel/etc_init.d_openvswitch +++ /dev/null @@ -1,102 +0,0 @@ -#!/bin/sh -# -# openvswitch -# -# chkconfig: 2345 09 91 -# description: Manage Open vSwitch kernel modules and user-space daemons - -# Copyright (C) 2009, 2010, 2011, 2013 Nicira, Inc. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at: -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. -### BEGIN INIT INFO -# Provides: openvswitch -# Required-Start: -# Required-Stop: -# Default-Start: 2 3 4 5 -# Default-Stop: 0 1 6 -# Short-Description: Open vSwitch switch -### END INIT INFO - -SYSTEMCTL_SKIP_REDIRECT=yes -SYSTEMD_NO_WRAP=yes - -. /usr/share/openvswitch/scripts/ovs-lib || exit 1 -test -e /etc/sysconfig/openvswitch && . /etc/sysconfig/openvswitch - -start () { - set ovs_ctl ${1-start} - set "$@" --system-id=random - if test X"$FORCE_COREFILES" != X; then - set "$@" --force-corefiles="$FORCE_COREFILES" - fi - if test X"$OVSDB_SERVER_PRIORITY" != X; then - set "$@" --ovsdb-server-priority="$OVSDB_SERVER_PRIORITY" - fi - if test X"$VSWITCHD_PRIORITY" != X; then - set "$@" --ovs-vswitchd-priority="$VSWITCHD_PRIORITY" - fi - if test X"$VSWITCHD_MLOCKALL" != X; then - set "$@" --mlockall="$VSWITCHD_MLOCKALL" - fi - set "$@" $OVS_CTL_OPTS - "$@" - - touch /var/lock/subsys/openvswitch -} - -stop () { - ovs_ctl stop - rm -f /var/lock/subsys/openvswitch -} - -restart () { - if [ "$1" = "--save-flows=yes" ]; then - start restart - else - stop - start - fi -} - -case $1 in - start) - start - ;; - stop) - stop - ;; - restart) - shift - restart "$@" - ;; - reload|force-reload) - # Nothing to do. - ;; - status) - ovs_ctl status - exit $? - ;; - version) - ovs_ctl version - ;; - force-reload-kmod) - start force-reload-kmod - ;; - help) - printf "$0 [start|stop|restart|reload|force-reload|status|version|force-reload-kmod]\n" - ;; - *) - printf "Unknown command: $1\n" - exit 1 - ;; -esac diff --git a/rhel/etc_logrotate.d_openvswitch b/rhel/etc_logrotate.d_openvswitch deleted file mode 100644 index f4302ffbc..000000000 --- a/rhel/etc_logrotate.d_openvswitch +++ /dev/null @@ -1,22 +0,0 @@ -# Copyright (C) 2009, 2010, 2011, 2012 Nicira, Inc. -# -# Copying and distribution of this file, with or without modification, -# are permitted in any medium without royalty provided the copyright -# notice and this notice are preserved. This file is offered as-is, -# without warranty of any kind. - -/var/log/openvswitch/*.log { - su root root - daily - compress - sharedscripts - missingok - postrotate - # Tell Open vSwitch daemons to reopen their log files - if [ -d /var/run/openvswitch ]; then - for ctl in /var/run/openvswitch/*.ctl; do - ovs-appctl -t "$ctl" vlog/reopen 2>/dev/null || : - done - fi - endscript -} diff --git a/rhel/etc_openvswitch_default.conf b/rhel/etc_openvswitch_default.conf deleted file mode 100644 index c74417db6..000000000 --- a/rhel/etc_openvswitch_default.conf +++ /dev/null @@ -1,5 +0,0 @@ -# DO NOT EDIT THIS FILE - -# The following is the *default* configuration for the openvswitch user ID. -# This is for backward compatibility. -OVS_USER_ID="root:root" diff --git a/rhel/etc_sysconfig_network-scripts_ifdown-ovs b/rhel/etc_sysconfig_network-scripts_ifdown-ovs deleted file mode 100755 index 63d048b22..000000000 --- a/rhel/etc_sysconfig_network-scripts_ifdown-ovs +++ /dev/null @@ -1,71 +0,0 @@ -#!/bin/bash - -# Copyright (c) 2011 Alexey I. Froloff. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at: -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -. /etc/init.d/functions - -cd /etc/sysconfig/network-scripts -. ./network-functions - -[ -f ../network ] && . ../network - -CONFIG=${1} -TIMEOUT=10 - -source_config - -. /etc/sysconfig/network - -OTHERSCRIPT="/etc/sysconfig/network-scripts/ifdown-${REAL_DEVICETYPE}" - -if [ ! -x ${OTHERSCRIPT} ]; then - OTHERSCRIPT="/etc/sysconfig/network-scripts/ifdown-eth" -fi - -SERVICE_UNIT=/usr/lib/systemd/system/ovsdb-server.service -if [ -f $SERVICE_UNIT ] && [ -x /usr/bin/systemctl ]; then - if ! systemctl --quiet is-active ovsdb-server.service; then - systemctl start ovsdb-server.service - fi -else - if [ ! -f /var/lock/subsys/openvswitch ]; then - /sbin/service openvswitch start - fi -fi - -case "$TYPE" in - OVSBridge|OVSUserBridge) - ${OTHERSCRIPT} ${CONFIG} $2 - retval=$? - ovs-vsctl -t ${TIMEOUT} -- --if-exists del-br "$DEVICE" - ;; - OVSPort|OVSIntPort|OVSBond) - ${OTHERSCRIPT} ${CONFIG} $2 - retval=$? - ovs-vsctl -t ${TIMEOUT} -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" - ;; - OVSPatchPort|OVSTunnel) - ovs-vsctl -t ${TIMEOUT} -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" - ;; - OVSDPDKPort|OVSDPDKRPort|OVSDPDKVhostUserPort|OVSDPDKBond) - ovs-vsctl -t ${TIMEOUT} -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" - ;; - *) - echo $"Invalid OVS interface type $TYPE" - exit 1 - ;; -esac - -exit $retval diff --git a/rhel/etc_sysconfig_network-scripts_ifup-ovs b/rhel/etc_sysconfig_network-scripts_ifup-ovs deleted file mode 100755 index b01461cc4..000000000 --- a/rhel/etc_sysconfig_network-scripts_ifup-ovs +++ /dev/null @@ -1,226 +0,0 @@ -#!/bin/bash - -# Copyright (c) 2011 Alexey I. Froloff. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at: -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -. /etc/init.d/functions - -cd /etc/sysconfig/network-scripts -. ./network-functions - -[ -f ../network ] && . ../network - -CONFIG=${1} -TIMEOUT=10 - -need_config ${CONFIG} - -source_config - -OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-${REAL_DEVICETYPE}" - -if [ ! -x ${OTHERSCRIPT} ]; then - OTHERSCRIPT="/etc/sysconfig/network-scripts/ifup-eth" -fi - -check_recursion () -{ - [ -n "${UPPEDSTACK}" ] && for _r in ${UPPEDSTACK}; do - [ "$_r" = "$1" ] && return 1 - done - - return 0 -} - -ifup_ovs_bridge () -{ - if ovs-vsctl br-exists "${OVS_BRIDGE}"; then :; else - /sbin/ifup "${OVS_BRIDGE}" - fi -} - -if [ -z "${UPPEDSTACK}" ]; then - UPPEDSTACK="${DEVICE}" -fi - -[ -n "${OVSREQUIRES}" ] && for _i in ${OVSREQUIRES}; do - if ( check_recursion "$_i" ); then - UPPEDSTACK="${UPPEDSTACK} $_i" /sbin/ifup "$_i" - fi -done - -SERVICE_UNIT=/usr/lib/systemd/system/openvswitch.service -if [ -f $SERVICE_UNIT ] && [ -x /usr/bin/systemctl ]; then - if ! systemctl --quiet is-active openvswitch.service; then - systemctl start openvswitch.service - fi -else - if [ ! -f /var/lock/subsys/openvswitch ]; then - /sbin/service openvswitch start - fi -fi - -case "$TYPE" in - OVSBridge|OVSUserBridge) - # If bridge already exists and is up, it has been configured through - # other cases like OVSPort, OVSIntPort and OVSBond. If it is down or - # it does not exist, create it. It is possible for a bridge to exist - # because it remained in the OVSDB for some reason, but it won't be up. - if [ "${TYPE}" = "OVSUserBridge" ]; then - DATAPATH="netdev" - fi - if check_device_down "${DEVICE}"; then - ovs-vsctl -t ${TIMEOUT} -- --may-exist add-br "$DEVICE" $OVS_OPTIONS \ - ${OVS_EXTRA+-- $OVS_EXTRA} \ - ${STP+-- set bridge "$DEVICE" stp_enable="${STP}"} \ - ${DATAPATH+-- set bridge "$DEVICE" datapath_type="$DATAPATH"} - else - OVSBRIDGECONFIGURED="yes" - fi - - # If MACADDR is provided in the interface configuration file, - # we need to set it using ovs-vsctl; setting it with the "ip" - # command in ifup-eth does not make the change persistent. - if [ -n "$MACADDR" ]; then - ovs-vsctl -t ${TIMEOUT} -- set bridge "$DEVICE" \ - other-config:hwaddr="$MACADDR" - fi - - # When dhcp is enabled, the assumption is that there will be a port to - # attach (otherwise, we can't reach out for dhcp). So, we do not - # configure the bridge through rhel's ifup infrastructure unless - # it is being configured after the port has been configured. - # The "OVSINTF" is set only after the port is configured. - if [ "${OVSBOOTPROTO}" = "dhcp" ] && [ -n "${OVSINTF}" ]; then - case " ${OVSDHCPINTERFACES} " in - *" ${OVSINTF} "*) - BOOTPROTO=dhcp ${OTHERSCRIPT} ${CONFIG} - ;; - esac - fi - - # When dhcp is not enabled, it is possible that someone may want - # a standalone bridge (i.e it may not have any ports). Configure it. - if [ "${OVSBOOTPROTO}" != "dhcp" ] && [ -z "${OVSINTF}" ] && \ - [ "${OVSBRIDGECONFIGURED}" != "yes" ]; then - ${OTHERSCRIPT} ${CONFIG} - fi - exit 0 - ;; - OVSPort) - ifup_ovs_bridge - ${OTHERSCRIPT} ${CONFIG} ${2} - # The port might be already in the database but not yet - # in the datapath. So, remove the stale interface first. - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS ${OVS_EXTRA+-- $OVS_EXTRA} - OVSINTF=${DEVICE} /sbin/ifup "$OVS_BRIDGE" - ;; - OVSIntPort) - ifup_ovs_bridge - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \ - -- set Interface "$DEVICE" type=internal ${OVS_EXTRA+-- $OVS_EXTRA} - if [ -n "${OVSDHCPINTERFACES}" ]; then - for _iface in ${OVSDHCPINTERFACES}; do - /sbin/ifup ${_iface} - done - fi - BOOTPROTO="${OVSBOOTPROTO}" ${OTHERSCRIPT} ${CONFIG} ${2} - ;; - OVSBond) - ifup_ovs_bridge - for _iface in $BOND_IFACES; do - /sbin/ifup ${_iface} - done - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-bond "$OVS_BRIDGE" "$DEVICE" ${BOND_IFACES} $OVS_OPTIONS ${OVS_EXTRA+-- $OVS_EXTRA} - OVSINTF=${DEVICE} /sbin/ifup "$OVS_BRIDGE" - ;; - OVSTunnel) - ifup_ovs_bridge - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \ - -- set Interface "$DEVICE" type=$OVS_TUNNEL_TYPE $OVS_TUNNEL_OPTIONS ${OVS_EXTRA+-- $OVS_EXTRA} - ;; - OVSPatchPort) - ifup_ovs_bridge - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \ - -- set Interface "$DEVICE" type=patch options:peer="${OVS_PATCH_PEER}" ${OVS_EXTRA+-- $OVS_EXTRA} - ;; - OVSDPDKPort) - ifup_ovs_bridge - BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE) - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \ - -- set Interface "$DEVICE" type=dpdk ${OVS_EXTRA+-- $OVS_EXTRA} - BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE) - # The bridge may change its MAC to be the lower one among all its - # ports. If that happens, bridge configuration (e.g. routes) will - # be lost. Restore the post-up bridge configuration again. - if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then - ${OTHERSCRIPT} "$OVS_BRIDGE" - fi - ;; - OVSDPDKRPort) - ifup_ovs_bridge - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \ - -- set Interface "$DEVICE" type=dpdkr ${OVS_EXTRA+-- $OVS_EXTRA} - ;; - OVSDPDKVhostUserPort) - ifup_ovs_bridge - PORT_TYPE="dpdkvhostuser" - PORT_PATH="" - if [ "$OVS_PORT_MODE" == "client" ]; then - PORT_TYPE="dpdkvhostuserclient" - PORT_PATH="options:vhost-server-path=${OVS_PORT_PATH}" - fi - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-port "$OVS_BRIDGE" "$DEVICE" $OVS_OPTIONS \ - -- set Interface "$DEVICE" type=$PORT_TYPE \ - $PORT_PATH \ - ${OVS_EXTRA+-- $OVS_EXTRA} - ;; - OVSDPDKBond) - ifup_ovs_bridge - BRIDGE_MAC_ORIG=$(get_hwaddr $OVS_BRIDGE) - for _iface in $BOND_IFACES; do - IFACE_TYPES="${IFACE_TYPES} -- set interface ${_iface} type=dpdk" - done - ovs-vsctl -t ${TIMEOUT} \ - -- --if-exists del-port "$OVS_BRIDGE" "$DEVICE" \ - -- add-bond "$OVS_BRIDGE" "$DEVICE" ${BOND_IFACES} $OVS_OPTIONS ${IFACE_TYPES} ${OVS_EXTRA+-- $OVS_EXTRA} - BRIDGE_MAC=$(get_hwaddr $OVS_BRIDGE) - # The bridge may change its MAC to be the lower one among all its - # ports. If that happens, bridge configuration (e.g. routes) will - # be lost. Restore the post-up bridge configuration again. - if [ "$BRIDGE_MAC_ORIG" != "$BRIDGE_MAC" ]; then - ${OTHERSCRIPT} "$OVS_BRIDGE" - fi - ;; - *) - echo $"Invalid OVS interface type $TYPE" - exit 1 - ;; -esac diff --git a/rhel/kmod-openvswitch-rhel6.spec.in b/rhel/kmod-openvswitch-rhel6.spec.in deleted file mode 100644 index 7d3d9b498..000000000 --- a/rhel/kmod-openvswitch-rhel6.spec.in +++ /dev/null @@ -1,122 +0,0 @@ -# Spec file for Open vSwitch kernel modules on Red Hat Enterprise -# Linux 6. - -# Copyright (C) 2011, 2012, 2018 Nicira, Inc. -# -# Copying and distribution of this file, with or without modification, -# are permitted in any medium without royalty provided the copyright -# notice and this notice are preserved. This file is offered as-is, -# without warranty of any kind. - -%define oname openvswitch - -Name: kmod-%{oname} -Version: @VERSION@ -Release: 1%{?dist} -Summary: Open vSwitch kernel module - -Group: System/Kernel -License: GPLv2 -URL: http://openvswitch.org/ -Source0: %{oname}-%{version}.tar.gz -BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) - -# Without this we get an empty openvswitch-debuginfo package (whose name -# conflicts with the openvswitch-debuginfo package for OVS userspace). -%undefine _enable_debug_packages - -%define kernel_source_extended() /usr/src/kernels/%{2}$([ %{1} = default ] || echo ".%{1}") - -# Use -D 'kversion 2.6.32-131.6.1.el6.x86_64' to build package -# for specified kernel version. -# Use -D 'kversion 3.10.0-693.1.1.el7.x86_64 3.10.0-693.17.1.el7.x86_64' -# to build package for mulitple kernel versions in the same package -# This only works for kernel 3.10.0 major revision 693 (RHEL 7.4) -# and major revision 327 (RHEL 7.2) -# By default, build against the latest installed kernel-devel -%{!?kversion:%global kversion %(rpm -qa | egrep "^kernel(-rt|-aarch64)?-devel" | /usr/lib/rpm/redhat/rpmsort -r | head -n 1| sed "s/^kernel.*-devel-//")} - -# Use -D 'kflavors default debug kdump' to build packages for -# specified kernel variants. -%{!?kflavors:%global kflavors default} - -%description -Open vSwitch Linux kernel module. - -%prep - -%setup -n %{oname}-%{version} - -%build -for kv in %{kversion}; do - for flavor in %{kflavors}; do - mkdir -p _$flavor/_$kv - (cd _$flavor/_$kv && ../../configure --with-linux="%{kernel_source_extended $flavor $kv}") - %{__make} -C _$flavor/_$kv/datapath/linux %{?_smp_mflags} - done -done - -%install -export INSTALL_MOD_PATH=$RPM_BUILD_ROOT -export INSTALL_MOD_DIR=extra/%{oname} -for kv in %{kversion}; do - for flavor in %{kflavors} ; do - make -C %{kernel_source_extended $flavor $kv} modules_install \ - M="`pwd`"/_$flavor/_$kv/datapath/linux - # Cleanup unnecessary kernel-generated module dependency files. - find $INSTALL_MOD_PATH/lib/modules -iname 'modules.*' -exec rm {} \; - done -done -install -d %{buildroot}%{_sysconfdir}/depmod.d/ -for kv in %{kversion}; do - for module in %{buildroot}/lib/modules/$kv/$INSTALL_MOD_DIR/*.ko; - do - modname="$(basename ${module})" - grep -qsPo "^\s*override ${modname%.ko} \* extra\/%{oname}" %{oname}.conf || \ - echo "override ${modname%.ko} * extra/%{oname}" >> %{oname}.conf - grep -qsPo "^\s*override ${modname%.ko} \* weak-updates\/%{oname}" %{oname}.conf || \ - echo "override ${modname%.ko} * weak-updates/%{oname}" >> %{oname}.conf - done -done -install -m 644 %{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ -install -d -m 0755 $RPM_BUILD_ROOT/usr/share/%{oname}/scripts -install -p -m 0755 rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh \ - $RPM_BUILD_ROOT/usr/share/%{oname}/scripts/ovs-kmod-manage.sh - -%post -current_kernel=$(uname -r) -IFS=. read installed_major installed_minor installed_micro installed_arch \ - installed_build <<<"${current_kernel##*-}" -if [ "$installed_major" = "327" ] || [ "$installed_major" = "693" ]; then - # Workaround for RHEL 7.2 and 7.4 - if [ -x "/usr/share/%{oname}/scripts/ovs-kmod-manage.sh" ]; then - /usr/share/%{oname}/scripts/ovs-kmod-manage.sh - fi -else - # Ensure that modprobe will find our modules. - for k in $(cd /lib/modules && /bin/ls); do - [ -d "/lib/modules/$k/kernel/" ] && /sbin/depmod -a "$k" - done - if [ -x "/sbin/weak-modules" ]; then - rpm -ql kmod-%{oname} | grep '\.ko$' | \ - /sbin/weak-modules --add-modules - fi -fi - -%postun -if [ "$1" = 0 ]; then # Erase, not upgrade - for kname in `ls -d /lib/modules/*` - do - rm -rf $kname/weak-updates/openvswitch - done -fi -/sbin/depmod -a - -%files -%defattr(644,root,root,755) -/etc/depmod.d/%{oname}.conf -/lib/modules/ -%attr(755,root,root) /usr/share/%{oname}/scripts/ovs-kmod-manage.sh - -%clean -rm -rf $RPM_BUILD_ROOT diff --git a/rhel/openvswitch-dkms.spec.in b/rhel/openvswitch-dkms.spec.in deleted file mode 100644 index a47c038fd..000000000 --- a/rhel/openvswitch-dkms.spec.in +++ /dev/null @@ -1,100 +0,0 @@ -# Spec file for Open vSwitch kernel modules using DKMS. -# -# Copyright (C) 2015 Nicira, Inc. -# -# Copying and distribution of this file, with or without modification, -# are permitted in any medium without royalty provided the copyright -# notice and this notice are preserved. This file is offered as-is, -# without warranty of any kind. - -%define oname openvswitch - -Name: %{oname}-dkms -Version: @VERSION@ -Release: 1%{?dist} -Summary: Open vSwitch kernel module - -Group: System/Kernel -License: GPLv2 -URL: http://openvswitch.org/ -Source: %{oname}-%{version}.tar.gz -Requires: autoconf, gcc, make -Requires(post): dkms -Requires(preun): dkms -BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX) - -# Without this we get an empty openvswitch-debuginfo package (whose name -# conflicts with the openvswitch-debuginfo package for OVS userspace). -%undefine _enable_debug_packages - - -%description -Open vSwitch Linux kernel module. - - -%prep -%setup -n %{oname}-%{version} - -cat > %{oname}.conf << EOF -override %{oname} * extra/%{oname} -override %{oname} * weak-updates/%{oname} -EOF - - -%build -# for running the '%{__make} -C datapath print-build-modules' below. -./configure - - -%install -%{__rm} -rf %{buildroot} - -# Kernel module sources install for dkms -%{__mkdir_p} %{buildroot}%{_usrsrc}/%{oname}-%{version}/ -%{__cp} -r * %{buildroot}%{_usrsrc}/%{oname}-%{version}/ - -# check we can get kernel module names -%{__make} -C datapath print-build-modules - -# Prepare dkms.conf -cat > %{buildroot}%{_usrsrc}/%{oname}-%{version}/dkms.conf << EOF -MODULES=( `%{__make} -C datapath print-build-modules | grep -v make` ) - -PACKAGE_NAME="openvswitch" -PACKAGE_VERSION="%{version}-%{release}" -MAKE="./configure --with-linux='\${kernel_source_dir}' && make -C datapath/linux" -for __idx in \${!MODULES[@]}; do - BUILT_MODULE_NAME[__idx]=\${MODULES[__idx]} - BUILT_MODULE_LOCATION[__idx]=datapath/linux/ - DEST_MODULE_LOCATION[__idx]=/kernel/drivers/net/openvswitch/ -done -AUTOINSTALL=yes -EOF - -install -d %{buildroot}%{_sysconfdir}/depmod.d/ -install -m 644 %{oname}.conf %{buildroot}%{_sysconfdir}/depmod.d/ - - -%post -# Add to DKMS registry -isadded=`dkms status -m "%{oname}" -v "%{version}"` -if [ "x${isadded}" = "x" ] ; then - dkms add -m "%{oname}" -v "%{version}" || : -fi -dkms build -m "%{oname}" -v "%{version}" || : -dkms install -m "%{oname}" -v "%{version}" --force || : - - -%preun -# Remove all versions from DKMS registry -dkms remove -m "%{oname}" -v "%{version}" --all || : - - -%clean -%{__rm} -rf %{buildroot} - - -%files -%defattr(-,root,root) -%{_usrsrc}/%{oname}-%{version}/ -/etc/depmod.d/openvswitch.conf diff --git a/rhel/openvswitch-fedora.spec.in b/rhel/openvswitch-fedora.spec.in deleted file mode 100644 index ce728b4f0..000000000 --- a/rhel/openvswitch-fedora.spec.in +++ /dev/null @@ -1,540 +0,0 @@ -# Spec file for Open vSwitch. - -# Copyright (C) 2009, 2010, 2013, 2014, 2015, 2016 Nicira Networks, Inc. -# -# Copying and distribution of this file, with or without modification, -# are permitted in any medium without royalty provided the copyright -# notice and this notice are preserved. This file is offered as-is, -# without warranty of any kind. -# -# If tests have to be skipped while building, specify the '--without check' -# option. For example: -# rpmbuild -bb --without check rhel/openvswitch-fedora.spec -# -# Support for executing kernel data path tests under rpmbuild is -# provided, however this is intended for use only in test environments -# and should not be used otherwise (these tests require root privileges). -# These tests can be executed, for example, via: -# rpmbuild -rb --with check_datapath_kernel openvswitch-fedora.src.rpm -# -# These tests will use the currently installed OVS kernel modules, when -# testing out of tree kernel modules the appropriate openvswitch-kmod -# package should be installed first. - -#%define kernel 2.6.40.4-5.fc15.x86_64 - -# If libcap-ng isn't available and there is no need for running OVS -# as regular user, specify the '--without libcapng' -%bcond_without libcapng -# To enable DPDK support, specify '--with dpdk' when building -%bcond_with dpdk -# Enable Python 3 by specifying '--with build_python3'. -# This is enabled by default for versions of the distribution that -# have Python 3 by default (Fedora > 22). -%bcond_with build_python3 - -# Enable PIE, bz#955181 -%global _hardened_build 1 - -# some distros (e.g: RHEL-7) don't define _rundir macro yet -# Fedora 15 onwards uses /run as _rundir -%if 0%{!?_rundir:1} -%define _rundir /run -%endif - -# define the python package prefix based on distribution version so that we can -# simultaneously support RHEL-based and later Fedora versions in this spec file. -%if 0%{?fedora} >= 25 -%define _py2 python2 -%endif - -%if 0%{?rhel} || 0%{?fedora} < 25 -%define _py2 python -%endif - - -Name: openvswitch -Summary: Open vSwitch -Group: System Environment/Daemons -URL: http://www.openvswitch.org/ -Version: @VERSION@ - -# Nearly all of openvswitch is ASL 2.0. The bugtool is LGPLv2+, and the -# lib/sflow*.[ch] files are SISSL -# datapath/ is GPLv2 (although not built into any of the binary packages) -License: ASL 2.0 and LGPLv2+ and SISSL -Release: 1%{?dist} -Source: http://openvswitch.org/releases/%{name}-%{version}.tar.gz - -BuildRequires: gcc gcc-c++ -BuildRequires: autoconf automake libtool -BuildRequires: systemd-units openssl openssl-devel -BuildRequires: %{_py2}-devel -%if 0%{?fedora} > 22 || %{with build_python3} -BuildRequires: python3-devel -%endif -BuildRequires: desktop-file-utils -BuildRequires: groff graphviz -BuildRequires: checkpolicy, selinux-policy-devel -BuildRequires: /usr/bin/sphinx-build -# make check dependencies -BuildRequires: %{_py2}-twisted%{?rhel:-core} %{_py2}-zope-interface %{_py2}-six -BuildRequires: procps-ng -%if %{with libcapng} -BuildRequires: libcap-ng libcap-ng-devel -%endif -%if %{with dpdk} -BuildRequires: libpcap-devel numactl-devel -BuildRequires: dpdk-devel >= 17.05.1 -Provides: %{name}-dpdk = %{version}-%{release} -%endif -BuildRequires: unbound unbound-devel - -Requires: openssl hostname iproute module-init-tools unbound -#Upstream kernel commit 4f647e0a3c37b8d5086214128614a136064110c3 -#Requires: kernel >= 3.15.0-0 - -Requires(pre): shadow-utils -Requires(post): /bin/sed -Requires(post): systemd-units -Requires(preun): systemd-units -Requires(postun): systemd-units -Obsoletes: openvswitch-controller <= 0:2.1.0-1 - -# to skip running checks, pass --without check -%bcond_without check -%bcond_with check_datapath_kernel - -%description -Open vSwitch provides standard network bridging functions and -support for the OpenFlow protocol for remote per-flow control of -traffic. - -%package selinux-policy -Summary: Open vSwitch SELinux policy -License: ASL 2.0 -BuildArch: noarch -Requires: selinux-policy-targeted - -%description selinux-policy -Tailored Open vSwitch SELinux policy - -%package -n %{_py2}-openvswitch -Summary: Open vSwitch python2 bindings -License: ASL 2.0 -BuildArch: noarch -Requires: %{_py2} -Requires: %{_py2}-six -%{?python_provide:%python_provide python2-openvswitch = %{version}-%{release}} -%description -n %{_py2}-openvswitch -Python bindings for the Open vSwitch database - -%if 0%{?fedora} > 22 || %{with build_python3} -%package -n python3-openvswitch -Summary: Open vSwitch python3 bindings -License: ASL 2.0 -BuildArch: noarch -Requires: python3 -Requires: python3-six -%{?python_provide:%python_provide python3-openvswitch = %{version}-%{release}} - -%description -n python3-openvswitch -Python bindings for the Open vSwitch database -%endif - -%package test -Summary: Open vSwitch testing utilities -License: ASL 2.0 -BuildArch: noarch -Requires: %{_py2}-openvswitch = %{version}-%{release} -Requires: %{_py2} %{_py2}-netifaces %{_py2}-twisted - -%description test -Utilities that are useful to diagnose performance and connectivity -issues in Open vSwitch setup. - -%package devel -Summary: Open vSwitch OpenFlow development package (library, headers) -License: ASL 2.0 - -%description devel -This provides shared library, libopenswitch.so and the openvswitch header -files needed to build an external application. - -%if 0%{?rhel} > 7 || 0%{?fedora} > 28 -%package -n network-scripts-%{name} -Summary: Open vSwitch legacy network service support -License: ASL 2.0 -Requires: network-scripts -Supplements: (%{name} and network-scripts) - -%description -n network-scripts-%{name} -This provides the ifup and ifdown scripts for use with the legacy network -service. -%endif - -%package ipsec -Summary: Open vSwitch IPsec tunneling support -License: ASL 2.0 -Requires: openvswitch %{_py2}-openvswitch libreswan - -%description ipsec -This package provides IPsec tunneling support for OVS tunnels. - -%prep -%setup -q - -%build -%configure \ -%if %{with libcapng} - --enable-libcapng \ -%else - --disable-libcapng \ -%endif -%if %{with dpdk} - --with-dpdk=$(dirname %{_datadir}/dpdk/*/.config) \ -%endif - --enable-ssl \ - --disable-static \ - --enable-shared \ - --with-pkidir=%{_sharedstatedir}/openvswitch/pki \ -%if 0%{?fedora} > 22 || %{with build_python3} - PYTHON3=%{__python3} \ - PYTHON=%{__python2} -%else - PYTHON=%{__python} -%endif - -build-aux/dpdkstrip.py \ -%if %{with dpdk} - --dpdk \ -%else - --nodpdk \ -%endif - < rhel/usr_lib_systemd_system_ovs-vswitchd.service.in \ - > rhel/usr_lib_systemd_system_ovs-vswitchd.service - -make %{?_smp_mflags} -make selinux-policy - -%install -rm -rf $RPM_BUILD_ROOT -make install DESTDIR=$RPM_BUILD_ROOT - -install -d -m 0755 $RPM_BUILD_ROOT%{_rundir}/openvswitch -install -d -m 0750 $RPM_BUILD_ROOT%{_localstatedir}/log/openvswitch -install -d -m 0755 $RPM_BUILD_ROOT%{_sysconfdir}/openvswitch -copy_headers() { - src=$1 - dst=$RPM_BUILD_ROOT/$2 - install -d -m 0755 $dst - install -m 0644 $src/*.h $dst -} -copy_headers include %{_includedir}/openvswitch -copy_headers include/openflow %{_includedir}/openvswitch/openflow -copy_headers include/openvswitch %{_includedir}/openvswitch/openvswitch -copy_headers include/sparse %{_includedir}/openvswitch/sparse -copy_headers include/sparse/arpa %{_includedir}/openvswitch/sparse/arpa -copy_headers include/sparse/netinet %{_includedir}/openvswitch/sparse/netinet -copy_headers include/sparse/sys %{_includedir}/openvswitch/sparse/sys -copy_headers lib %{_includedir}/openvswitch/lib - -%if %{with dpdk} -install -p -D -m 0644 rhel/usr_lib_udev_rules.d_91-vfio.rules \ - $RPM_BUILD_ROOT%{_prefix}/lib/udev/rules.d/91-vfio.rules -%endif - -install -p -D -m 0644 \ - rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template \ - $RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/openvswitch -for service in openvswitch ovsdb-server ovs-vswitchd ovs-delete-transient-ports \ - openvswitch-ipsec; do - install -p -D -m 0644 \ - rhel/usr_lib_systemd_system_${service}.service \ - $RPM_BUILD_ROOT%{_unitdir}/${service}.service -done -install -m 0755 rhel/etc_init.d_openvswitch \ - $RPM_BUILD_ROOT%{_datadir}/openvswitch/scripts/openvswitch.init - -install -p -D -m 0644 rhel/etc_openvswitch_default.conf \ - $RPM_BUILD_ROOT/%{_sysconfdir}/openvswitch/default.conf - -install -p -D -m 0644 rhel/etc_logrotate.d_openvswitch \ - $RPM_BUILD_ROOT/%{_sysconfdir}/logrotate.d/openvswitch - -install -m 0644 vswitchd/vswitch.ovsschema \ - $RPM_BUILD_ROOT/%{_datadir}/openvswitch/vswitch.ovsschema - -install -d -m 0755 $RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/network-scripts/ -install -p -m 0755 rhel/etc_sysconfig_network-scripts_ifdown-ovs \ - $RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/network-scripts/ifdown-ovs -install -p -m 0755 rhel/etc_sysconfig_network-scripts_ifup-ovs \ - $RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/network-scripts/ifup-ovs - -install -d -m 0755 $RPM_BUILD_ROOT%{python2_sitelib} -cp -a $RPM_BUILD_ROOT/%{_datadir}/openvswitch/python/* \ - $RPM_BUILD_ROOT%{python2_sitelib} - -%if 0%{?fedora} > 22 || %{with build_python3} -install -d -m 0755 $RPM_BUILD_ROOT%{python3_sitelib} -cp -a $RPM_BUILD_ROOT/%{_datadir}/openvswitch/python/ovs \ - $RPM_BUILD_ROOT%{python3_sitelib} -%endif - -rm -rf $RPM_BUILD_ROOT/%{_datadir}/openvswitch/python/ - -install -d -m 0755 $RPM_BUILD_ROOT/%{_sharedstatedir}/openvswitch - -touch $RPM_BUILD_ROOT%{_sysconfdir}/openvswitch/conf.db -touch $RPM_BUILD_ROOT%{_sysconfdir}/openvswitch/.conf.db.~lock~ -touch $RPM_BUILD_ROOT%{_sysconfdir}/openvswitch/system-id.conf - -install -p -m 644 -D selinux/openvswitch-custom.pp \ - $RPM_BUILD_ROOT%{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp - -install -d $RPM_BUILD_ROOT%{_prefix}/lib/firewalld/services/ - -install -p -D -m 0755 \ - rhel/usr_share_openvswitch_scripts_ovs-systemd-reload \ - $RPM_BUILD_ROOT%{_datadir}/openvswitch/scripts/ovs-systemd-reload - -# remove unpackaged files -rm -f $RPM_BUILD_ROOT%{_bindir}/ovs-parse-backtrace \ - $RPM_BUILD_ROOT%{_sbindir}/ovs-vlan-bug-workaround \ - $RPM_BUILD_ROOT%{_mandir}/man8/ovs-vlan-bug-workaround.8 - -# remove ovn unpackages files -rm -f $RPM_BUILD_ROOT%{_bindir}/ovn* -rm -f $RPM_BUILD_ROOT%{_mandir}/man1/ovn* -rm -f $RPM_BUILD_ROOT%{_mandir}/man5/ovn* -rm -f $RPM_BUILD_ROOT%{_mandir}/man7/ovn* -rm -f $RPM_BUILD_ROOT%{_mandir}/man8/ovn* -rm -f $RPM_BUILD_ROOT%{_datadir}/openvswitch/ovn* -rm -f $RPM_BUILD_ROOT%{_datadir}/openvswitch/scripts/ovn* -rm -f $RPM_BUILD_ROOT%{_includedir}/ovn/* -rm -f $RPM_BUILD_ROOT%{_libdir}/libovn* - -%check -%if %{with check} - touch resolv.conf - export OVS_RESOLV_CONF=$(pwd)/resolv.conf - if make check TESTSUITEFLAGS='%{_smp_mflags}' RECHECK=yes; then :; - else - cat tests/testsuite.log - exit 1 - fi -%endif -%if %{with check_datapath_kernel} - if make check-kernel RECHECK=yes; then :; - else - cat tests/system-kmod-testsuite.log - exit 1 - fi -%endif - -%clean -rm -rf $RPM_BUILD_ROOT - -%pre selinux-policy -%selinux_relabel_pre -s targeted - -%preun -%if 0%{?systemd_preun:1} - %systemd_preun %{name}.service -%else - if [ $1 -eq 0 ] ; then - # Package removal, not upgrade - /bin/systemctl --no-reload disable %{name}.service >/dev/null 2>&1 || : - /bin/systemctl stop %{name}.service >/dev/null 2>&1 || : - fi -%endif - -%pre -%if %{with libcapng} -getent group openvswitch >/dev/null || groupadd -r openvswitch -getent passwd openvswitch >/dev/null || \ - useradd -r -g openvswitch -d / -s /sbin/nologin \ - -c "Open vSwitch Daemons" openvswitch - -%if %{with dpdk} - getent group hugetlbfs >/dev/null || groupadd -r hugetlbfs - usermod -a -G hugetlbfs openvswitch -%endif -%endif -exit 0 - -%post -%if %{with libcapng} -if [ $1 -eq 1 ]; then - sed -i 's:^#OVS_USER_ID=:OVS_USER_ID=:' /etc/sysconfig/openvswitch - sed -i 's:\(.*su\).*:\1 openvswitch openvswitch:' %{_sysconfdir}/logrotate.d/openvswitch - -%if %{with dpdk} - sed -i \ - 's@OVS_USER_ID="openvswitch:openvswitch"@OVS_USER_ID="openvswitch:hugetlbfs"@'\ - /etc/sysconfig/openvswitch -%endif - - # In the case of upgrade, this is not needed. - chown -R openvswitch:openvswitch /etc/openvswitch - chown -R openvswitch:openvswitch /var/log/openvswitch -fi -%endif - -%if 0%{?systemd_post:1} - %systemd_post %{name}.service -%else - # Package install, not upgrade - if [ $1 -eq 1 ]; then - /bin/systemctl daemon-reload >dev/null || : - fi -%endif - -%post selinux-policy -%selinux_modules_install -s targeted %{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp - -%postun -%if 0%{?systemd_postun:1} - %systemd_postun %{name}.service -%else - /bin/systemctl daemon-reload >/dev/null 2>&1 || : -%endif - -%postun selinux-policy -if [ $1 -eq 0 ] ; then - %selinux_modules_uninstall -s targeted openvswitch-custom -fi - -%posttrans selinux-policy -%selinux_relabel_post -s targeted - -%files selinux-policy -%defattr(-,root,root) -%{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp - -%files -n %{_py2}-openvswitch -%{python2_sitelib}/ovs - -%if 0%{?fedora} > 22 || %{with build_python3} -%files -n python3-openvswitch -%{python3_sitelib}/ovs -%endif - -%files test -%{_bindir}/ovs-test -%{_bindir}/ovs-vlan-test -%{_bindir}/ovs-l3ping -%{_bindir}/ovs-pcap -%{_bindir}/ovs-tcpdump -%{_bindir}/ovs-tcpundump -%{_mandir}/man8/ovs-test.8* -%{_mandir}/man8/ovs-vlan-test.8* -%{_mandir}/man8/ovs-l3ping.8* -%{_mandir}/man1/ovs-pcap.1* -%{_mandir}/man8/ovs-tcpdump.8* -%{_mandir}/man1/ovs-tcpundump.1* -%{python2_sitelib}/ovstest - -%files devel -%{_libdir}/lib*.so -%{_libdir}/pkgconfig/*.pc -%{_includedir}/openvswitch/* -%{_includedir}/openflow/* -%exclude %{_libdir}/*.la - -%if 0%{?rhel} > 7 || 0%{?fedora} > 28 -%files -n network-scripts-%{name} -%{_sysconfdir}/sysconfig/network-scripts/ifup-ovs -%{_sysconfdir}/sysconfig/network-scripts/ifdown-ovs -%endif - -%files -%if %{with libcapng} -%defattr(-,openvswitch,openvswitch) -%else -%defattr(-,root,root) -%endif -%dir %{_sysconfdir}/openvswitch -%{_sysconfdir}/openvswitch/default.conf -%config %ghost %{_sysconfdir}/openvswitch/conf.db -%ghost %{_sysconfdir}/openvswitch/.conf.db.~lock~ -%config %ghost %{_sysconfdir}/openvswitch/system-id.conf -%config(noreplace) %{_sysconfdir}/sysconfig/openvswitch -%defattr(-,root,root) -%{_sysconfdir}/bash_completion.d/ovs-appctl-bashcomp.bash -%{_sysconfdir}/bash_completion.d/ovs-vsctl-bashcomp.bash -%config(noreplace) %{_sysconfdir}/logrotate.d/openvswitch -%{_unitdir}/openvswitch.service -%{_unitdir}/ovsdb-server.service -%{_unitdir}/ovs-vswitchd.service -%{_unitdir}/ovs-delete-transient-ports.service -%{_datadir}/openvswitch/scripts/openvswitch.init -%if ! (0%{?rhel} > 7 || 0%{?fedora} > 28) -%{_sysconfdir}/sysconfig/network-scripts/ifup-ovs -%{_sysconfdir}/sysconfig/network-scripts/ifdown-ovs -%endif -%{_datadir}/openvswitch/bugtool-plugins/ -%{_datadir}/openvswitch/scripts/ovs-bugtool-* -%{_datadir}/openvswitch/scripts/ovs-check-dead-ifs -%{_datadir}/openvswitch/scripts/ovs-lib -%{_datadir}/openvswitch/scripts/ovs-save -%{_datadir}/openvswitch/scripts/ovs-vtep -%{_datadir}/openvswitch/scripts/ovs-ctl -%{_datadir}/openvswitch/scripts/ovs-kmod-ctl -%{_datadir}/openvswitch/scripts/ovs-systemd-reload -%config %{_datadir}/openvswitch/vswitch.ovsschema -%config %{_datadir}/openvswitch/vtep.ovsschema -%{_bindir}/ovs-appctl -%{_bindir}/ovs-docker -%{_bindir}/ovs-dpctl -%{_bindir}/ovs-dpctl-top -%{_bindir}/ovs-ofctl -%{_bindir}/ovs-vsctl -%{_bindir}/ovsdb-client -%{_bindir}/ovsdb-tool -%{_bindir}/ovs-testcontroller -%{_bindir}/ovs-pki -%{_bindir}/vtep-ctl -%{_libdir}/lib*.so.* -%{_sbindir}/ovs-bugtool -%{_sbindir}/ovs-vswitchd -%{_sbindir}/ovsdb-server -%{_mandir}/man1/ovsdb-client.1* -%{_mandir}/man1/ovsdb-server.1* -%{_mandir}/man1/ovsdb-tool.1* -%{_mandir}/man5/ovsdb-server.5* -%{_mandir}/man5/ovs-vswitchd.conf.db.5* -%{_mandir}/man5/ovsdb.5* -%{_mandir}/man5/vtep.5* -%{_mandir}/man7/ovs-actions.7* -%{_mandir}/man7/ovs-fields.7* -%{_mandir}/man7/ovsdb.7* -%{_mandir}/man7/ovsdb-server.7* -%{_mandir}/man8/vtep-ctl.8* -%{_mandir}/man8/ovs-appctl.8* -%{_mandir}/man8/ovs-bugtool.8* -%{_mandir}/man8/ovs-ctl.8* -%{_mandir}/man8/ovs-dpctl.8* -%{_mandir}/man8/ovs-dpctl-top.8* -%{_mandir}/man8/ovs-kmod-ctl.8* -%{_mandir}/man8/ovs-ofctl.8* -%{_mandir}/man8/ovs-pki.8* -%{_mandir}/man8/ovs-vsctl.8* -%{_mandir}/man8/ovs-vswitchd.8* -%{_mandir}/man8/ovs-parse-backtrace.8* -%{_mandir}/man8/ovs-testcontroller.8* -%if %{with dpdk} -%{_prefix}/lib/udev/rules.d/91-vfio.rules -%endif -%doc NOTICE README.rst NEWS rhel/README.RHEL.rst -/var/lib/openvswitch -%attr(750,root,root) /var/log/openvswitch -%ghost %attr(755,root,root) %{_rundir}/openvswitch - -%files ipsec -%{_datadir}/openvswitch/scripts/ovs-monitor-ipsec -%{_unitdir}/openvswitch-ipsec.service - -%changelog -* Wed Jan 12 2011 Ralf Spenneberg -- First build on F14 diff --git a/rhel/openvswitch-kmod-fedora.spec.in b/rhel/openvswitch-kmod-fedora.spec.in deleted file mode 100644 index 9a4c48910..000000000 --- a/rhel/openvswitch-kmod-fedora.spec.in +++ /dev/null @@ -1,134 +0,0 @@ -# Spec file for Open vSwitch. - -# Copyright (C) 2009, 2010, 2015, 2018 Nicira Networks, Inc. -# -# Copying and distribution of this file, with or without modification, -# are permitted in any medium without royalty provided the copyright -# notice and this notice are preserved. This file is offered as-is, -# without warranty of any kind. - -%global debug_package %{nil} - -# Use the kversion macro such as -# RPMBUILD_OPT='-D "kversion 3.10.0-693.1.1.el7.x86_64 3.10.0-693.17.1.el7.x86_64"' -# to build package for mulitple kernel versions in the same package -# This only works for kernel 3.10.0 major revision 693 (RHEL 7.4) -# and major revision 327 (RHEL 7.2) -# By default, build against the current running kernel version -#%define kernel 3.1.5-1.fc16.x86_64 -#define kernel %{kernel_source} -%{?kversion:%define kernel %kversion} - -Name: openvswitch-kmod -Summary: Open vSwitch Kernel Modules -Group: System Environment/Daemons -URL: http://www.openvswitch.org/ -Vendor: OpenSource Security Ralf Spenneberg -Version: @VERSION@ - -# The entire source code is ASL 2.0 except datapath/ which is GPLv2 -License: GPLv2 -Release: 1%{?dist} -Source: openvswitch-%{version}.tar.gz -#Source1: openvswitch-init -Buildroot: /tmp/openvswitch-xen-rpm -Provides: kmod-openvswitch -Obsoletes: kmod-openvswitch < %{version}-%{release} - -%description -Open vSwitch provides standard network bridging functions augmented with -support for the OpenFlow protocol for remote per-flow control of -traffic. This package contains the kernel modules. - -%prep -%setup -q -n openvswitch-%{version} - -%build -for kv in %{kversion}; do - mkdir -p _$kv - (cd _$kv && /bin/cp -f ../configure . && %configure --srcdir=.. \ - --with-linux=/lib/modules/${kv}/build --enable-ssl %{_ovs_config_extra_flags}) - make %{_smp_mflags} -C _$kv/datapath/linux -done - -%install -export INSTALL_MOD_DIR=extra/openvswitch -rm -rf $RPM_BUILD_ROOT -for kv in %{kversion}; do - make INSTALL_MOD_PATH=$RPM_BUILD_ROOT -C _$kv/datapath/linux modules_install -done -mkdir -p $RPM_BUILD_ROOT/etc/depmod.d -for kv in %{kversion}; do - for module in $RPM_BUILD_ROOT/lib/modules/${kv}/extra/openvswitch/*.ko - do - modname="$(basename ${module})" - grep -qsPo "^\s*override ${modname%.ko} \* extra\/openvwitch" \ - $RPM_BUILD_ROOT/etc/depmod.d/kmod-openvswitch.conf || \ - echo "override ${modname%.ko} * extra/openvswitch" >> \ - $RPM_BUILD_ROOT/etc/depmod.d/kmod-openvswitch.conf - grep -qsPo "^\s*override ${modname%.ko} \* weak-updates\/openvwitch" \ - $RPM_BUILD_ROOT/etc/depmod.d/kmod-openvswitch.conf || \ - echo "override ${modname%.ko} * weak-updates/openvswitch" >> \ - $RPM_BUILD_ROOT/etc/depmod.d/kmod-openvswitch.conf - done -done -install -d -m 0755 $RPM_BUILD_ROOT/usr/share/openvswitch/scripts -install -p -m 0755 rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh \ - $RPM_BUILD_ROOT%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh - -%clean -rm -rf $RPM_BUILD_ROOT - -%post -current_kernel=$(uname -r) -IFS='.\|-' read mainline_major mainline_minor mainline_patch major_rev \ - minor_rev _extra <<<"${current_kernel}" -# echo mainline_major=$mainline_major mainline_minor=$mainline_minor \ -# mainline_patch=$mainline_patch major_rev=$major_rev minor_rev=$minor_rev -if [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ]; then - if [ "$major_rev" = "327" ] || [ "$major_rev" = "693" ]; then - # For RHEL 7.2 and 7.4 - if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then - %{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh - fi - fi -elif [ "$mainline_major" = "4" ] && [ "$mainline_minor" = "4" ] && \ - [ "$mainline_patch" -ge "73" ]; then - # For SLES 12 SP3 - if [ -x "%{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh" ]; then - %{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh - fi -else - # Ensure that modprobe will find our modules. - for k in $(cd /lib/modules && /bin/ls); do - [ -d "/lib/modules/$k/kernel/" ] && /sbin/depmod -a "$k" - done - if [ -x "/sbin/weak-modules" ]; then - for m in openvswitch vport-gre vport-stt vport-geneve \ - vport-lisp vport-vxlan; do - echo "/lib/modules/%{kernel}/extra/openvswitch/$m.ko" - done | /sbin/weak-modules --add-modules - fi -fi - -%postun -if [ "$1" = 0 ]; then # Erase, not upgrade - for kname in `ls -d /lib/modules/*` -do - rm -rf $kname/weak-updates/openvswitch -done -fi -/sbin/depmod -a - -%files -%defattr(0644,root,root) -/lib/modules/*/extra/openvswitch/*.ko -/etc/depmod.d/kmod-openvswitch.conf -%exclude /lib/modules/*/modules.* -%attr(755,root,root) %{_datadir}/openvswitch/scripts/ovs-kmod-manage.sh - -%changelog -* Wed Sep 21 2011 Kyle Mestery -- Updated for F15 -* Wed Jan 12 2011 Ralf Spenneberg -- First build on F14 diff --git a/rhel/openvswitch.spec.in b/rhel/openvswitch.spec.in deleted file mode 100644 index c8361f5f2..000000000 --- a/rhel/openvswitch.spec.in +++ /dev/null @@ -1,282 +0,0 @@ -# Spec file for Open vSwitch on Red Hat Enterprise Linux. - -# Copyright (C) 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 Nicira, Inc. -# -# Copying and distribution of this file, with or without modification, -# are permitted in any medium without royalty provided the copyright -# notice and this notice are preserved. This file is offered as-is, -# without warranty of any kind. -# -# If tests have to be skipped while building, specify the '--without check' -# option. For example: -# rpmbuild -bb --without check rhel/openvswitch.spec -# -# Support for executing kernel data path tests under rpmbuild is -# provided, however this is intended for use only in test environments -# and should not be used otherwise (these tests require root privileges). -# These tests can be executed, for example, via: -# rpmbuild -rb --with check_datapath_kernel openvswitch.src.rpm -# -# These tests will use the currently installed OVS kernel modules, when -# testing out of tree kernel modules the appropriate openvswitch-kmod -# package should be installed first. - -Name: openvswitch -Summary: Open vSwitch daemon/database/utilities -Group: System Environment/Daemons -URL: http://www.openvswitch.org/ -Vendor: Nicira, Inc. -Version: @VERSION@ - -License: ASL 2.0 -Release: 1 -Source: openvswitch-%{version}.tar.gz -Buildroot: /tmp/openvswitch-rpm -Requires: logrotate, hostname, python >= 2.7, python-six -BuildRequires: python-six -BuildRequires: openssl-devel -BuildRequires: checkpolicy, selinux-policy-devel -BuildRequires: autoconf, automake, libtool -BuildRequires: python-sphinx -BuildRequires: unbound-devel - -%bcond_without check -%bcond_with check_datapath_kernel - -%description -Open vSwitch provides standard network bridging functions and -support for the OpenFlow protocol for remote per-flow control of -traffic. - -%package devel -Summary: Open vSwitch development package -Group: Development/Libraries - -%description devel -This package provides openvswitch headers and libopenvswitch for developers. - -%package selinux-policy -Summary: Open vSwitch SELinux policy -License: ASL 2.0 -BuildArch: noarch -Requires: selinux-policy-targeted - -%description selinux-policy -Tailored Open vSwitch SELinux policy - -%prep -%setup -q - -%build -./configure --prefix=/usr --sysconfdir=/etc --localstatedir=%{_localstatedir} \ - --libdir=%{_libdir} --enable-ssl --enable-shared -make %{_smp_mflags} -make selinux-policy - -%install -rm -rf $RPM_BUILD_ROOT -make install DESTDIR=$RPM_BUILD_ROOT - -rhel_cp() { - base=$1 - mode=$2 - dst=$RPM_BUILD_ROOT/$(echo $base | sed 's,_,/,g') - install -D -m $mode rhel/$base $dst -} -rhel_cp etc_init.d_openvswitch 0755 -rhel_cp etc_logrotate.d_openvswitch 0644 -rhel_cp etc_sysconfig_network-scripts_ifup-ovs 0755 -rhel_cp etc_sysconfig_network-scripts_ifdown-ovs 0755 -rhel_cp usr_share_openvswitch_scripts_sysconfig.template 0644 - -install -p -m 644 -D selinux/openvswitch-custom.pp \ - $RPM_BUILD_ROOT%{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp - -# Get rid of stuff we don't want to make RPM happy. -rm \ - $RPM_BUILD_ROOT/usr/bin/ovs-testcontroller \ - $RPM_BUILD_ROOT/usr/share/man/man8/ovs-testcontroller.8 \ - $RPM_BUILD_ROOT/usr/bin/ovs-test \ - $RPM_BUILD_ROOT/usr/bin/ovs-l3ping \ - $RPM_BUILD_ROOT/usr/share/man/man8/ovs-test.8 \ - $RPM_BUILD_ROOT/usr/share/man/man8/ovs-l3ping.8 \ - $RPM_BUILD_ROOT/usr/sbin/ovs-vlan-bug-workaround \ - $RPM_BUILD_ROOT/usr/share/man/man8/ovs-vlan-bug-workaround.8 \ - $RPM_BUILD_ROOT/usr/bin/ovn-* \ - $RPM_BUILD_ROOT/usr/share/man/man?/ovn-* \ - $RPM_BUILD_ROOT/usr/share/openvswitch/ovn-* \ - $RPM_BUILD_ROOT/usr/share/openvswitch/scripts/ovn* -(cd "$RPM_BUILD_ROOT" && rm -rf usr/%{_lib}/*.la) -(cd "$RPM_BUILD_ROOT" && rm -rf usr/include) - -install -d -m 0755 $RPM_BUILD_ROOT%{_rundir}/openvswitch -install -d -m 0755 $RPM_BUILD_ROOT%{_localstatedir}/log/openvswitch -install -d -m 0755 $RPM_BUILD_ROOT/var/lib/openvswitch - -copy_headers() { - src=$1 - dst=$RPM_BUILD_ROOT/$2 - install -d -m 0755 $dst - install -m 0644 $src/*.h $dst -} -copy_headers include %{_includedir}/openvswitch -copy_headers include/openflow %{_includedir}/openvswitch/openflow -copy_headers include/openvswitch %{_includedir}/openvswitch/openvswitch -copy_headers include/sparse %{_includedir}/openvswitch/sparse -copy_headers include/sparse/arpa %{_includedir}/openvswitch/sparse/arpa -copy_headers include/sparse/netinet %{_includedir}/openvswitch/sparse/netinet -copy_headers include/sparse/sys %{_includedir}/openvswitch/sparse/sys -copy_headers lib %{_includedir}/openvswitch/lib - -install -D -m 0644 lib/.libs/libopenvswitch.a \ - $RPM_BUILD_ROOT/%{_libdir}/libopenvswitch.a - -%check -%if %{with check} - if make check TESTSUITEFLAGS='%{_smp_mflags}' RECHECK=yes; then :; - else - cat tests/testsuite.log - exit 1 - fi -%endif -%if %{with check_datapath_kernel} - if make check-kernel RECHECK=yes; then :; - else - cat tests/system-kmod-testsuite.log - exit 1 - fi -%endif - -%clean -rm -rf $RPM_BUILD_ROOT - -%post -# Create default or update existing /etc/sysconfig/openvswitch. -SYSCONFIG=/etc/sysconfig/openvswitch -TEMPLATE=/usr/share/openvswitch/scripts/sysconfig.template -if [ ! -e $SYSCONFIG ]; then - cp $TEMPLATE $SYSCONFIG -else - for var in $(awk -F'[ :]' '/^# [_A-Z0-9]+:/{print $2}' $TEMPLATE) - do - if ! grep $var $SYSCONFIG >/dev/null 2>&1; then - echo >> $SYSCONFIG - sed -n "/$var:/,/$var=/p" $TEMPLATE >> $SYSCONFIG - fi - done -fi - -# Ensure all required services are set to run -/sbin/chkconfig --add openvswitch -/sbin/chkconfig openvswitch on - -%pre selinux-policy -%selinux_relabel_pre -s targeted - -%post selinux-policy -%selinux_modules_install -s targeted %{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp - -%preun -if [ "$1" = "0" ]; then # $1 = 0 for uninstall - /sbin/service openvswitch stop - /sbin/chkconfig --del openvswitch -fi - -%postun -if [ "$1" = "0" ]; then # $1 = 0 for uninstall - rm -f /etc/openvswitch/conf.db - rm -f /etc/sysconfig/openvswitch - rm -f /etc/openvswitch/vswitchd.cacert -fi - -%postun selinux-policy -if [ $1 -eq 0 ] ; then - %selinux_modules_uninstall -s targeted openvswitch-custom -fi - -exit 0 - -%posttrans selinux-policy -%selinux_relabel_post -s targeted - -%files -%defattr(-,root,root) -%dir /etc/openvswitch -/etc/bash_completion.d/ovs-appctl-bashcomp.bash -/etc/bash_completion.d/ovs-vsctl-bashcomp.bash -/etc/init.d/openvswitch -%config(noreplace) /etc/logrotate.d/openvswitch -/etc/sysconfig/network-scripts/ifup-ovs -/etc/sysconfig/network-scripts/ifdown-ovs -/usr/bin/ovs-appctl -/usr/bin/ovs-dpctl -/usr/bin/ovs-dpctl-top -/usr/bin/ovs-docker -/usr/bin/ovs-ofctl -/usr/bin/ovs-parse-backtrace -/usr/bin/ovs-pcap -/usr/bin/ovs-pki -/usr/bin/ovs-tcpdump -/usr/bin/ovs-tcpundump -/usr/bin/ovs-vlan-test -/usr/bin/ovs-vsctl -/usr/bin/ovsdb-client -/usr/bin/ovsdb-tool -/usr/bin/vtep-ctl -%{_libdir}/lib*.so.* -/usr/sbin/ovs-bugtool -/usr/sbin/ovs-vswitchd -/usr/sbin/ovsdb-server -/usr/share/man/man1/ovs-pcap.1.gz -/usr/share/man/man1/ovs-tcpundump.1.gz -/usr/share/man/man1/ovsdb-client.1.gz -/usr/share/man/man1/ovsdb-server.1.gz -/usr/share/man/man1/ovsdb-tool.1.gz -/usr/share/man/man5/ovsdb-server.5.gz -/usr/share/man/man5/ovs-vswitchd.conf.db.5.gz -%{_mandir}/man5/ovsdb.5* -/usr/share/man/man5/vtep.5.gz -/usr/share/man/man7/ovs-actions.7.gz -/usr/share/man/man7/ovs-fields.7.gz -%{_mandir}/man7/ovsdb.7* -%{_mandir}/man7/ovsdb-server.7* -/usr/share/man/man8/ovs-appctl.8.gz -/usr/share/man/man8/ovs-bugtool.8.gz -/usr/share/man/man8/ovs-ctl.8.gz -/usr/share/man/man8/ovs-dpctl.8.gz -/usr/share/man/man8/ovs-dpctl-top.8.gz -/usr/share/man/man8/ovs-kmod-ctl.8.gz -/usr/share/man/man8/ovs-ofctl.8.gz -/usr/share/man/man8/ovs-parse-backtrace.8.gz -/usr/share/man/man8/ovs-pki.8.gz -/usr/share/man/man8/ovs-tcpdump.8.gz -/usr/share/man/man8/ovs-vlan-test.8.gz -/usr/share/man/man8/ovs-vsctl.8.gz -/usr/share/man/man8/ovs-vswitchd.8.gz -/usr/share/man/man8/vtep-ctl.8.gz -/usr/share/openvswitch/bugtool-plugins/ -/usr/share/openvswitch/python/ -/usr/share/openvswitch/scripts/ovs-bugtool-* -/usr/share/openvswitch/scripts/ovs-check-dead-ifs -/usr/share/openvswitch/scripts/ovs-ctl -/usr/share/openvswitch/scripts/ovs-kmod-ctl -/usr/share/openvswitch/scripts/ovs-lib -/usr/share/openvswitch/scripts/ovs-save -/usr/share/openvswitch/scripts/ovs-vtep -/usr/share/openvswitch/scripts/sysconfig.template -/usr/share/openvswitch/scripts/ovs-monitor-ipsec -/usr/share/openvswitch/vswitch.ovsschema -/usr/share/openvswitch/vtep.ovsschema -%doc NOTICE README.rst NEWS rhel/README.RHEL.rst -/var/lib/openvswitch -/var/log/openvswitch - -%files devel -%{_libdir}/lib*.so -%{_libdir}/lib*.a -%{_libdir}/pkgconfig -%{_includedir}/openvswitch/* - -%files selinux-policy -%defattr(-,root,root) -%{_datadir}/selinux/packages/%{name}/openvswitch-custom.pp diff --git a/rhel/usr_lib_systemd_system_openvswitch-ipsec.service b/rhel/usr_lib_systemd_system_openvswitch-ipsec.service deleted file mode 100644 index d8f47af68..000000000 --- a/rhel/usr_lib_systemd_system_openvswitch-ipsec.service +++ /dev/null @@ -1,14 +0,0 @@ -[Unit] -Description=OVS IPsec daemon -Requires=openvswitch.service -After=openvswitch.service - -[Service] -Type=forking -PIDFile=/var/run/openvswitch/ovs-monitor-ipsec.pid -ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \ - --ike-daemon=libreswan start-ovs-ipsec -ExecStop=/usr/share/openvswitch/scripts/ovs-ctl stop-ovs-ipsec - -[Install] -WantedBy=multi-user.target diff --git a/rhel/usr_lib_systemd_system_openvswitch.service b/rhel/usr_lib_systemd_system_openvswitch.service deleted file mode 100644 index feaba37d5..000000000 --- a/rhel/usr_lib_systemd_system_openvswitch.service +++ /dev/null @@ -1,17 +0,0 @@ -[Unit] -Description=Open vSwitch -Before=network.target network.service -After=network-pre.target ovsdb-server.service ovs-vswitchd.service -PartOf=network.target -Requires=ovsdb-server.service -Requires=ovs-vswitchd.service - -[Service] -Type=oneshot -ExecStart=/bin/true -ExecReload=/usr/share/openvswitch/scripts/ovs-systemd-reload -ExecStop=/bin/true -RemainAfterExit=yes - -[Install] -WantedBy=multi-user.target diff --git a/rhel/usr_lib_systemd_system_ovs-delete-transient-ports.service b/rhel/usr_lib_systemd_system_ovs-delete-transient-ports.service deleted file mode 100644 index 4cd4d7f57..000000000 --- a/rhel/usr_lib_systemd_system_ovs-delete-transient-ports.service +++ /dev/null @@ -1,10 +0,0 @@ -[Unit] -Description=Open vSwitch Delete Transient Ports -After=ovsdb-server.service -Before=ovs-vswitchd.service -AssertPathExists=/var/run/openvswitch/db.sock - -[Service] -Type=oneshot -RemainAfterExit=yes -ExecStart=/usr/share/openvswitch/scripts/ovs-ctl delete-transient-ports diff --git a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in b/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in deleted file mode 100644 index edd76493c..000000000 --- a/rhel/usr_lib_systemd_system_ovs-vswitchd.service.in +++ /dev/null @@ -1,32 +0,0 @@ -[Unit] -Description=Open vSwitch Forwarding Unit -After=ovsdb-server.service network-pre.target systemd-udev-settle.service -Before=network.target network.service -Requires=ovsdb-server.service -ReloadPropagatedFrom=ovsdb-server.service -AssertPathIsReadWrite=/var/run/openvswitch/db.sock -PartOf=openvswitch.service - -[Service] -Type=forking -PIDFile=/var/run/openvswitch/ovs-vswitchd.pid -Restart=on-failure -Environment=XDG_RUNTIME_DIR=/var/run/openvswitch -EnvironmentFile=/etc/openvswitch/default.conf -EnvironmentFile=-/etc/sysconfig/openvswitch -EnvironmentFile=-/run/openvswitch/useropts -LimitSTACK=2M -@begin_dpdk@ -ExecStartPre=-/bin/sh -c '/usr/bin/chown :$${OVS_USER_ID##*:} /dev/hugepages' -ExecStartPre=-/usr/bin/chmod 0775 /dev/hugepages -@end_dpdk@ -ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \ - --no-ovsdb-server --no-monitor --system-id=random \ - ${OVSUSER} \ - start $OPTIONS -ExecStop=/usr/share/openvswitch/scripts/ovs-ctl --no-ovsdb-server stop -ExecReload=/usr/share/openvswitch/scripts/ovs-ctl --no-ovsdb-server \ - --no-monitor --system-id=random \ - ${OVSUSER} \ - restart $OPTIONS -TimeoutSec=300 diff --git a/rhel/usr_lib_systemd_system_ovsdb-server.service b/rhel/usr_lib_systemd_system_ovsdb-server.service deleted file mode 100644 index 41ac2dded..000000000 --- a/rhel/usr_lib_systemd_system_ovsdb-server.service +++ /dev/null @@ -1,26 +0,0 @@ -[Unit] -Description=Open vSwitch Database Unit -After=syslog.target network-pre.target -Before=network.target network.service -Wants=ovs-delete-transient-ports.service -PartOf=openvswitch.service - -[Service] -Type=forking -PIDFile=/var/run/openvswitch/ovsdb-server.pid -Restart=on-failure -EnvironmentFile=/etc/openvswitch/default.conf -EnvironmentFile=-/etc/sysconfig/openvswitch -ExecStartPre=/usr/bin/chown ${OVS_USER_ID} /var/run/openvswitch /var/log/openvswitch -ExecStartPre=/bin/sh -c 'rm -f /run/openvswitch/useropts; if [ "$${OVS_USER_ID/:*/}" != "root" ]; then /usr/bin/echo "OVSUSER=--ovs-user=${OVS_USER_ID}" > /run/openvswitch/useropts; fi' -EnvironmentFile=-/run/openvswitch/useropts -ExecStart=/usr/share/openvswitch/scripts/ovs-ctl \ - --no-ovs-vswitchd --no-monitor --system-id=random \ - ${OVSUSER} \ - start $OPTIONS -ExecStop=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd stop -ExecReload=/usr/share/openvswitch/scripts/ovs-ctl --no-ovs-vswitchd \ - ${OVSUSER} \ - --no-monitor restart $OPTIONS -RuntimeDirectory=openvswitch -RuntimeDirectoryMode=0755 diff --git a/rhel/usr_lib_udev_rules.d_91-vfio.rules b/rhel/usr_lib_udev_rules.d_91-vfio.rules deleted file mode 100644 index 8e34b2a2b..000000000 --- a/rhel/usr_lib_udev_rules.d_91-vfio.rules +++ /dev/null @@ -1 +0,0 @@ -ACTION=="add", SUBSYSTEM=="vfio*", GROUP="hugetlbfs", MODE="0660" diff --git a/rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh b/rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh deleted file mode 100644 index b5c4615f2..000000000 --- a/rhel/usr_share_openvswitch_scripts_ovs-kmod-manage.sh +++ /dev/null @@ -1,160 +0,0 @@ -#!/bin/sh - -# Copyright (c) 2018 Nicira/VMware, Inc. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at: -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -# This version of the script is intended to be used on kernel version 3.10.0 -# major revision 327 (RHEL 7.2) and 693 (RHEL 7.4), and kernel version 4.4.x, -# x >= 73 (SLES 12 SP3) only. It is packaged in the openvswitch kmod RPM -# and run in the post-install scripts. -# -# For kernel 3.10.0-693, -# due to some backward incompatible changes introduced in minor revision 17.1, -# kernel modules built against kernels newer than 17.1 cannot be loaded on -# system running kernels older than 17.1, vice versa. -# -# For kernel 3.10.0-327, -# due to some backward incompatible changes introduced in minor revision 41.3, -# kernel modules built against kernels newer than 41.3 cannot be loaded on -# system running kernels older than 41.3, vice versa. -# -# For kernel >= 4.4.73, -# kernel modules built with 4.4.73 can run on systems with kernel versions from -# 4.4.73 to 4.4.114; modules built against 4.4.120 can run on systems from -# 4.4.120 onwards. -# -# This script checks the current running kernel version, and update symlinks -# for the openvswitch kernel modules in the appropriate kernel directory, -# provided the kmod RPM has installed kernel modules files built from both -# minor revisions. -# -# In case of a kernel minor revision change after the openvswitch kmod package -# is installed, this script shall be run manually after system reboots and -# switches to a different kernel -if [ -n "$(rpm -qa kmod-openvswitch)" ]; then - rpmname="kmod-openvswitch" -elif [ -n "$(rpm -qa openvswitch-kmod)" ]; then - rpmname="openvswitch-kmod" -else - echo "openvswitch kmod package not installed, existing" - exit 1 -fi -#echo $rpmname -script_name=$(basename -- "$0") -current_kernel=$(uname -r) -echo current kernel is $current_kernel - -IFS='.\|-' read mainline_major mainline_minor mainline_patch major_rev \ - minor_rev _extra <<<"${current_kernel}" -# echo mainline_major=$mainline_major mainline_minor=$mainline_minor \ -# mainline_patch=$mainline_patch major_rev=$major_rev minor_rev=$minor_rev - -expected_rhel_base_minor="el7" -if [ "$mainline_major" = "3" ] && [ "$mainline_minor" = "10" ]; then - if [ "$major_rev" = "327" ]; then -# echo "rhel72" - comp_ver=36 - ver_offset=4 - installed_ver="$minor_rev" - elif [ "$major_rev" = "693" ]; then -# echo "rhel74" - comp_ver=11 - ver_offset=4 - installed_ver="$minor_rev" - fi -elif [ "$mainline_major" = "4" ] && [ "$mainline_minor" = "4" ]; then - if [ "$mainline_patch" -ge "73" ]; then -# echo "sles12sp3" - comp_ver=114 - ver_offset=2 - installed_ver="$mainline_patch" - fi -fi - -if [ X"$ver_offset" = X ]; then - echo "This script is not intended to run on kernel $(uname -r)" - exit 1 -fi - -#IFS='.\|-' read -r -a version_nums <<<"${current_kernel}" -#echo ver_offset=$ver_offset -#echo installed_ver="$installed_ver" -#echo installed_ver="${version_nums[$ver_offset]}" - -kmod_versions=() -kversion=$(rpm -ql ${rpmname} | grep '\.ko$' | \ - sed -n -e 's/^\/lib\/modules\/\(.*\)\/extra\/.*$/\1/p' | \ - sort | uniq) -for kv in $kversion; do - IFS='.\|-' read -r -a kv_nums <<<"${kv}" - kmod_versions+=(${kv_nums[$ver_offset]}) -done -sorted_kmod_vers=$(printf "%s\n" "${kmod_versions[@]}" | \ - sort -n) -#echo "$sorted_kmod_vers" - -if [ ! -n "$sorted_kmod_vers" ]; then - echo "No kernel modules found from package $rpmname, exiting" - exit 1 -else - # first line for kmod_low_ver, last for kmod_high_ver - kmod_low_ver=$(echo "$sorted_kmod_vers" | head -1) - kmod_high_ver=$(echo "$sorted_kmod_vers" | tail -1) -fi -#echo "Installing KMOD with minor revisions $kmod_low_ver and \ -#$kmod_high_ver" - -found_match=false -for kname in `ls -d /lib/modules/*` -do - IFS='.\|-' read -r -a pkg_ver_nums <<<"${kname}" - pkg_ver=${pkg_ver_nums[$ver_offset]} - if [ "$installed_ver" = "$expected_rhel_base_minor" ] || - [ "$installed_ver" -le "$comp_ver" ]; then - if [ "$pkg_ver" = "$kmod_low_ver" ]; then - requested_kernel=$kname - found_match="true" - echo "Installing Openvswitch KMOD from kernel $kname" - break - fi - else - if [ "$pkg_ver" = "$kmod_high_ver" ]; then - requested_kernel=$kname - found_match="true" - echo "Installing Openvswitch KMOD from kernel $kname" - break - fi - fi -done - -if [ "$found_match" = "false" ]; then - echo $script_name: Failed - exit 1 -fi - -if [ "$requested_kernel" != "/lib/modules/$current_kernel" ]; then - if [ ! -d /lib/modules/$current_kernel/weak-updates/openvswitch ]; then - mkdir -p /lib/modules/$current_kernel/weak-updates - mkdir -p /lib/modules/$current_kernel/weak-updates/openvswitch - fi - for m in openvswitch vport-gre vport-stt vport-geneve \ - vport-lisp vport-vxlan; do - ln -f -s $requested_kernel/extra/openvswitch/$m.ko \ - /lib/modules/$current_kernel/weak-updates/openvswitch/$m.ko - done -else - echo Proper OVS kernel modules already configured -fi -# Always run depmod -/sbin/depmod -a diff --git a/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload b/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload deleted file mode 100755 index 894df0427..000000000 --- a/rhel/usr_share_openvswitch_scripts_ovs-systemd-reload +++ /dev/null @@ -1,49 +0,0 @@ -#! /bin/sh - -# Copyright (c) 2017 Red Hat, Inc. -# -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at: -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -case $0 in - */*) dir0=`echo "$0" | sed 's,/[^/]*$,,'` ;; - *) dir0=./ ;; -esac -. "$dir0/ovs-lib" || exit 1 - -stop_ovsdb() { - systemctl --job-mode=ignore-dependencies stop ovsdb-server -} - -start_ovsdb() { - systemctl --job-mode=ignore-dependencies start ovsdb-server -} - -stop_forwarding() { - systemctl --job-mode=ignore-dependencies stop ovs-vswitchd -} - -start_forwarding() { - systemctl --job-mode=ignore-dependencies start ovs-vswitchd -} - -add_managers() { - : -} - -if [ "$1" = "force-reload-kmod" ]; then - force_reload_kmod -else - restart -fi - -exit 0 diff --git a/rhel/usr_share_openvswitch_scripts_sysconfig.template b/rhel/usr_share_openvswitch_scripts_sysconfig.template deleted file mode 100644 index 2c0845296..000000000 --- a/rhel/usr_share_openvswitch_scripts_sysconfig.template +++ /dev/null @@ -1,24 +0,0 @@ -### Configuration options for openvswitch - -# Copyright (C) 2009, 2010, 2011 Nicira, Inc. - -# FORCE_COREFILES: If 'yes' then core files will be enabled. -# FORCE_COREFILES=yes - -# OVSDB_SERVER_PRIORITY: "nice" priority at which to run ovsdb-server. -# -# OVSDB_SERVER_PRIORITY=-10 - -# VSWITCHD_PRIORITY: "nice" priority at which to run ovs-vswitchd. -# VSWITCHD_PRIORITY=-10 - -# VSWITCHD_MLOCKALL: Whether to pass ovs-vswitchd the --mlockall option. -# This option should be set to "yes" or "no". The default is "yes". -# Enabling this option can avoid networking interruptions due to -# system memory pressure in extraordinary situations, such as multiple -# concurrent VM import operations. -# VSWITCHD_MLOCKALL=yes - -# OVS_CTL_OPTS: Extra options to pass to ovs-ctl. This is, for example, -# a suitable place to specify --ovs-vswitchd-wrapper=valgrind. -# OVS_CTL_OPTS= diff --git a/rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template b/rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template deleted file mode 100644 index c467d02db..000000000 --- a/rhel/usr_share_openvswitch_scripts_systemd_sysconfig.template +++ /dev/null @@ -1,31 +0,0 @@ -### Configuration options for openvswitch -# -# Enable core files. -# This option should be set to "yes" or "no". The default is "yes". -# --force-corefiles=yes -# -# Set "nice" priority at which to run ovsdb-server: -# --ovsdb-server-priority=-10 -# -# Set "nice" priority at which to run ovsdb-vswitchd: -# --ovs-vswitchd-priority=-10 -# -# Pass or not --mlockall option to ovs-vswitchd. -# This option should be set to "yes" or "no". The default is "yes". -# Enabling this option can avoid networking interruptions due to -# system memory pressure in extraordinary situations, such as multiple -# concurrent VM import operations. -# --mlockall=yes -# -# Use valgrind: -# --ovs-vswitchd-wrapper=valgrind -# --ovsdb-server-wrapper=valgrind -# -# Specify additional options, for example to start with debug logs: -# --ovs-vswitchd-options='-vconsole:dbg -vfile:dbg' -# --ovsdb-server-options='-vconsole:dbg -vfile:dbg' -# -OPTIONS="" - -# Uncomment and set the OVS User/Group value -#OVS_USER_ID="openvswitch:openvswitch"