pax_global_header00006660000000000000000000000064136215555440014524gustar00rootroot0000000000000052 comment=71d553b995d0bd527d3ab1e9fbaf5a2ae34de2f3 ovs-2.13.0/000077500000000000000000000000001362155554400124165ustar00rootroot00000000000000ovs-2.13.0/.cirrus.yml000066400000000000000000000013711362155554400145300ustar00rootroot00000000000000freebsd_build_task: freebsd_instance: matrix: image_family: freebsd-12-1-snap image_family: freebsd-11-3-snap cpu: 4 memory: 8G env: DEPENDENCIES: automake libtool gmake gcc wget openssl python3 py37-openssl py37-sphinx matrix: COMPILER: gcc COMPILER: clang prepare_script: - sysctl -w kern.coredump=0 - pkg install -y ${DEPENDENCIES} configure_script: - ./boot.sh - ./configure CC=${COMPILER} CFLAGS="-g -O2 -Wall" MAKE=gmake --enable-Werror || { cat config.log; exit 1; } build_script: - gmake -j8 check_script: - gmake -j8 check TESTSUITEFLAGS=-j8 RECHECK=yes || { cat ./tests/testsuite.log; exit 1; } ovs-2.13.0/.gitignore000066400000000000000000000014601362155554400144070ustar00rootroot00000000000000#*# *.a *.d *.gcno *.gcda *.ko *.la *.lo *.loT *.mod.c *.o *.obj *.exe *.exp *.ilk *.lib *.pdb *.pyc *.retry *.so *.suo **/*.sym *~ *,cover .#* .*.cmd .*.swp .coverage .deps .dirstamp .libs .tmp_versions .vagrant /Makefile /Makefile.in /aclocal.m4 /all-distfiles /all-gitfiles /autom4te.cache /build-arch-stamp /build-indep-stamp /compile /config.guess /config.h /config.h.in /config.log /config.status /config.sub /configure /configure-stamp /depcomp /distfiles /dist-docs /flake8-check /docs-check /install-sh /libtool /manpage-check /missing /missing-distfiles /package.m4 /stamp-h1 /_build-gcc /_build-clang Module.symvers TAGS cscope.* tags _debian odp-netlink.h odp-netlink-macros.h OvsDpInterface.h /.vagrant/ testsuite.tmp.orig /rpm/ /openvswitch*.tar.gz /tests/lcov/ /Documentation/_build /.venv /cxx-check ovs-2.13.0/.mailmap000066400000000000000000000107101362155554400140360ustar00rootroot00000000000000# See git-shortlog(1) for official documentation of this file format. # # Name # Use "Name" for any commit with address "". This is useful when a person # has commits using different spellings of their name, but with the same email # address. # # Name # Use "Name" and "" for any commit with the address "". This is useful # when a person has used more than one email address. Aaron Conole Aaron Conole Aaron Rosen Alex Wang Alexey I. Froloff Alin Serdean Alin Serdean Andy Zhou Andy Zhou Andy Zhou Ansis Atteka Ansis Atteka Anupam Chanda Ariel Tubaltsev Babu Shanmugam Ben Pfaff Bruce Davie Bruce Davie Chandra Sekhar Vejendla Daniele Di Proietto Daniele Di Proietto Ed Maste Ethan J. Jackson Fischetti, Antonio Flavio Fernandes Flavio Leitner Gal Sagie Gurucharan Shetty Gurucharan Shetty Henry Mai Hui Kang Ian Campbell Ilya Maximets James Page Jarno Rajahalme Jarno Rajahalme Jean Tourrilhes Jean Tourrihles Jean Tourrilhes Jesse Gross Joe Stringer Joe Stringer Justin Pettit Kmindg Kyle Mestery Lance Richardson Mauricio Vasquez Miguel Angel Ajo Neil McKee Ofer Ben-Yacov Polehn, Mike A Pravin B Shelar Raju Subramanian Ralf Spenneberg Rami Rosen Ramu Ramamurthy Robert Åkerblom-Andersson Romain Lenglet Romain Lenglet Russell Bryant Ryan Moats Sabyasachi Sengupta Saurabh Shah Shad Ansari Shih-Hao Li Simon Horman Stephen Finucane Thomas F. Herbert Thomas Graf Thomas Graf Wei Li YAMAMOTO Takashi YAMAMOTO Takashi YAMAMOTO Takashi Zhi Yong Wu Zoltan Kiss Zong Kai LI ovs-2.13.0/.travis.yml000066400000000000000000000021441362155554400145300ustar00rootroot00000000000000language: c compiler: - gcc - clang os: - linux cache: directories: - dpdk-dir addons: apt: packages: - bc - libssl-dev - llvm-dev - libjemalloc1 - libjemalloc-dev - libnuma-dev - libpcap-dev - python3-openssl - python3-pip - python3-sphinx - libelf-dev - selinux-policy-dev - libunbound-dev - libunwind-dev before_install: ./.travis/${TRAVIS_OS_NAME}-prepare.sh before_script: export PATH=$PATH:$HOME/bin env: - OPTS="--disable-ssl" - TESTSUITE=1 KERNEL=3.16 - TESTSUITE=1 OPTS="--enable-shared" - TESTSUITE=1 DPDK=1 - TESTSUITE=1 LIBS=-ljemalloc - KERNEL_LIST="5.0 4.20 4.19 4.18 4.17 4.16" - KERNEL_LIST="4.15 4.14 4.9 4.4 3.19 3.16" - AFXDP=1 KERNEL=5.3 - M32=1 OPTS="--disable-ssl" - DPDK=1 OPTS="--enable-shared" - DPDK_SHARED=1 - DPDK_SHARED=1 OPTS="--enable-shared" matrix: include: - os: osx compiler: clang env: OPTS="--disable-ssl" script: ./.travis/${TRAVIS_OS_NAME}-build.sh $OPTS notifications: email: recipients: - ovs-build@openvswitch.org ovs-2.13.0/.travis/000077500000000000000000000000001362155554400140045ustar00rootroot00000000000000ovs-2.13.0/.travis/linux-build.sh000077500000000000000000000157651362155554400166150ustar00rootroot00000000000000#!/bin/bash set -o errexit set -x CFLAGS_FOR_OVS="-g -O2" SPARSE_FLAGS="" EXTRA_OPTS="--enable-Werror" TARGET="x86_64-native-linuxapp-gcc" function install_kernel() { if [[ "$1" =~ ^5.* ]]; then PREFIX="v5.x" elif [[ "$1" =~ ^4.* ]]; then PREFIX="v4.x" elif [[ "$1" =~ ^3.* ]]; then PREFIX="v3.x" else PREFIX="v2.6/longterm/v2.6.32" fi base_url="https://cdn.kernel.org/pub/linux/kernel/${PREFIX}" # Download page with list of all available kernel versions. wget ${base_url}/ # Uncompress in case server returned gzipped page. (file index* | grep ASCII) || (mv index* index.new.gz && gunzip index*) # Get version of the latest stable release. hi_ver=$(echo ${1} | sed 's/\./\\\./') lo_ver=$(cat ./index* | grep -P -o "${hi_ver}\.[0-9]+" | \ sed 's/.*\..*\.\(.*\)/\1/' | sort -h | tail -1) version="${1}.${lo_ver}" rm -rf index* linux-* url="${base_url}/linux-${version}.tar.xz" # Download kernel sources. Try direct link on CDN failure. wget ${url} || wget ${url} || wget ${url/cdn/www} tar xvf linux-${version}.tar.xz > /dev/null pushd linux-${version} make allmodconfig # Cannot use CONFIG_KCOV: -fsanitize-coverage=trace-pc is not supported by compiler sed -i 's/CONFIG_KCOV=y/CONFIG_KCOV=n/' .config # stack validation depends on tools/objtool, but objtool does not compile on travis. # It is giving following error. # >>> GEN arch/x86/insn/inat-tables.c # >>> Semantic error at 40: Unknown imm opnd: AL # So for now disable stack-validation for the build. sed -i 's/CONFIG_STACK_VALIDATION=y/CONFIG_STACK_VALIDATION=n/' .config make oldconfig # Older kernels do not include openvswitch if [ -d "net/openvswitch" ]; then make net/openvswitch/ else make net/bridge/ fi if [ "$AFXDP" ]; then sudo make headers_install INSTALL_HDR_PATH=/usr pushd tools/lib/bpf/ # Bulding with gcc because there are some issues in make files # that breaks building libbpf with clang on Travis. CC=gcc sudo make install CC=gcc sudo make install_headers sudo ldconfig popd # The Linux kernel defines __always_inline in stddef.h (283d7573), and # sys/cdefs.h tries to re-define it. Older libc-dev package in xenial # doesn't have a fix for this issue. Applying it manually. sudo sed -i '/^# define __always_inline .*/i # undef __always_inline' \ /usr/include/x86_64-linux-gnu/sys/cdefs.h || true EXTRA_OPTS="${EXTRA_OPTS} --enable-afxdp" else EXTRA_OPTS="${EXTRA_OPTS} --with-linux=$(pwd)" echo "Installed kernel source in $(pwd)" fi popd } function install_dpdk() { local DPDK_VER=$1 local VERSION_FILE="dpdk-dir/travis-dpdk-cache-version" if [ "${DPDK_VER##refs/*/}" != "${DPDK_VER}" ]; then # Avoid using cache for git tree build. rm -rf dpdk-dir DPDK_GIT=${DPDK_GIT:-https://dpdk.org/git/dpdk} git clone --single-branch $DPDK_GIT dpdk-dir -b "${DPDK_VER##refs/*/}" pushd dpdk-dir git log -1 --oneline else if [ -f "${VERSION_FILE}" ]; then VER=$(cat ${VERSION_FILE}) if [ "${VER}" = "${DPDK_VER}" ]; then EXTRA_OPTS="${EXTRA_OPTS} --with-dpdk=$(pwd)/dpdk-dir/build" echo "Found cached DPDK ${VER} build in $(pwd)/dpdk-dir" return fi fi # No cache or version mismatch. rm -rf dpdk-dir wget https://fast.dpdk.org/rel/dpdk-$1.tar.xz tar xvf dpdk-$1.tar.xz > /dev/null DIR_NAME=$(tar -tf dpdk-$1.tar.xz | head -1 | cut -f1 -d"/") mv ${DIR_NAME} dpdk-dir pushd dpdk-dir fi make config CC=gcc T=$TARGET if [ "$DPDK_SHARED" ]; then sed -i '/CONFIG_RTE_BUILD_SHARED_LIB=n/s/=n/=y/' build/.config export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$(pwd)/$TARGET/lib fi # Disable building DPDK kernel modules. Not needed for OVS build or tests. sed -i '/CONFIG_RTE_EAL_IGB_UIO=y/s/=y/=n/' build/.config sed -i '/CONFIG_RTE_KNI_KMOD=y/s/=y/=n/' build/.config # Enable pdump support in DPDK. sed -i '/CONFIG_RTE_LIBRTE_PMD_PCAP=n/s/=n/=y/' build/.config sed -i '/CONFIG_RTE_LIBRTE_PDUMP=n/s/=n/=y/' build/.config make -j4 CC=gcc EXTRA_CFLAGS='-fPIC' EXTRA_OPTS="$EXTRA_OPTS --with-dpdk=$(pwd)/build" echo "Installed DPDK source in $(pwd)" popd echo "${DPDK_VER}" > ${VERSION_FILE} } function configure_ovs() { ./boot.sh ./configure CFLAGS="${CFLAGS_FOR_OVS}" $* || { cat config.log; exit 1; } } function build_ovs() { local KERNEL=$1 configure_ovs $OPTS make selinux-policy # Only build datapath if we are testing kernel w/o running testsuite and # AF_XDP support. if [ "${KERNEL}" ] && ! [ "$AFXDP" ]; then pushd datapath make -j4 popd else make -j4 || { cat config.log; exit 1; } fi } if [ "$KERNEL" ]; then install_kernel $KERNEL fi if [ "$DPDK" ] || [ "$DPDK_SHARED" ]; then if [ -z "$DPDK_VER" ]; then DPDK_VER="19.11" fi install_dpdk $DPDK_VER # Enable pdump support in OVS. EXTRA_OPTS="${EXTRA_OPTS} --enable-dpdk-pdump" if [ "$CC" = "clang" ]; then # Disregard cast alignment errors until DPDK is fixed CFLAGS_FOR_OVS="${CFLAGS_FOR_OVS} -Wno-cast-align" fi fi if [ "$CC" = "clang" ]; then CFLAGS_FOR_OVS="${CFLAGS_FOR_OVS} -Wno-error=unused-command-line-argument" elif [ "$M32" ]; then # Not using sparse for 32bit builds on 64bit machine. # Adding m32 flag directly to CC to avoid any posiible issues with API/ABI # difference on 'configure' and 'make' stages. export CC="$CC -m32" else OPTS="--enable-sparse" if [ "$AFXDP" ]; then # netdev-afxdp uses memset for 64M for umem initialization. SPARSE_FLAGS="${SPARSE_FLAGS} -Wno-memcpy-max-count" fi CFLAGS_FOR_OVS="${CFLAGS_FOR_OVS} ${SPARSE_FLAGS}" fi save_OPTS="${OPTS} $*" OPTS="${EXTRA_OPTS} ${save_OPTS}" if [ "$TESTSUITE" ]; then # 'distcheck' will reconfigure with required options. # Now we only need to prepare the Makefile without sparse-wrapped CC. configure_ovs export DISTCHECK_CONFIGURE_FLAGS="$OPTS" if ! make distcheck CFLAGS="${CFLAGS_FOR_OVS}" \ TESTSUITEFLAGS=-j4 RECHECK=yes; then # testsuite.log is necessary for debugging. cat */_build/sub/tests/testsuite.log exit 1 fi else if [ -z "${KERNEL_LIST}" ]; then build_ovs ${KERNEL}; else save_EXTRA_OPTS="${EXTRA_OPTS}" for KERNEL in ${KERNEL_LIST}; do echo "==============================" echo "Building with kernel ${KERNEL}" echo "==============================" EXTRA_OPTS="${save_EXTRA_OPTS}" install_kernel ${KERNEL} OPTS="${EXTRA_OPTS} ${save_OPTS}" build_ovs ${KERNEL} make distclean done fi fi exit 0 ovs-2.13.0/.travis/linux-prepare.sh000077500000000000000000000016521362155554400171420ustar00rootroot00000000000000#!/bin/bash set -ev # Build and install sparse. # # Explicitly disable sparse support for llvm because some travis # environments claim to have LLVM (llvm-config exists and works) but # linking against it fails. git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git cd sparse make -j4 HAVE_LLVM= install cd .. pip3 install --disable-pip-version-check --user flake8 hacking pip3 install --user --upgrade docutils if [ "$M32" ]; then # Installing 32-bit libraries. # 32-bit and 64-bit libunwind can not be installed at the same time. # This will remove the 64-bit libunwind and install 32-bit version. sudo apt-get install -y \ libunwind-dev:i386 libunbound-dev:i386 gcc-multilib fi # IPv6 is supported by kernel but disabled in TravisCI images: # https://github.com/travis-ci/travis-ci/issues/8891 # Enable it to avoid skipping of IPv6 related tests. sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0 ovs-2.13.0/.travis/osx-build.sh000077500000000000000000000011041362155554400162450ustar00rootroot00000000000000#!/bin/bash set -o errexit CFLAGS="-Werror $CFLAGS" EXTRA_OPTS="" function configure_ovs() { ./boot.sh && ./configure $* } configure_ovs $EXTRA_OPTS $* if [ "$CC" = "clang" ]; then set make CFLAGS="$CFLAGS -Wno-error=unused-command-line-argument" else set make CFLAGS="$CFLAGS $BUILD_ENV" fi if ! "$@"; then cat config.log exit 1 fi if [ "$TESTSUITE" ] && [ "$CC" != "clang" ]; then if ! make distcheck RECHECK=yes; then # testsuite.log is necessary for debugging. cat */_build/sub/tests/testsuite.log exit 1 fi fi exit 0 ovs-2.13.0/.travis/osx-prepare.sh000077500000000000000000000000731362155554400166100ustar00rootroot00000000000000#!/bin/bash set -ev pip3 install --user --upgrade docutils ovs-2.13.0/AUTHORS.rst000066400000000000000000001044071362155554400143030ustar00rootroot00000000000000.. 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. ======= Authors ======= The following people authored or signed off on commits in the Open vSwitch source code or webpage version control repository. ================================== =============================================== Name Email ================================== =============================================== Aaron Conole aconole@redhat.com Aaron Rosen arosen@clemson.edu Alan Pevec alan.pevec@redhat.com Alessandro Pilotti apilotti@cloudbasesolutions.com Alexander Duyck alexander.h.duyck@redhat.com Alexandru Copot alex.mihai.c@gmail.com Alexei Starovoitov ast@plumgrid.com Alexey I. Froloff raorn@raorn.name Alex Wang ee07b291@gmail.com Alfredo Finelli alf@computationes.de Alin Balutoiu abalutoiu@cloudbasesolutions.com Alin Serdean aserdean@cloudbasesolutions.com Ambika Arora ambika.arora@tcs.com Amit Bose bose@noironetworks.com Amitabha Biswas azbiswas@gmail.com Anand Kumar kumaranand@vmware.com Andrea Kao eirinikos@gmail.com Andreas Karis akaris@redhat.com Andrew Evans Andrew Beekhof abeekhof@redhat.com Andrew Kampjes a.kampjes@gmail.com Andrew Lambeth alambeth@vmware.com Andre McCurdy armccurdy@gmail.com Andy Hill hillad@gmail.com Andy Southgate andy.southgate@citrix.com Andy Zhou azhou@ovn.org Ankur Sharma ankursharma@vmware.com Anoob Soman anoob.soman@citrix.com Ansis Atteka aatteka@vmware.com Antonio Fischetti antonio.fischetti@intel.com Anupam Chanda Ariel Tubaltsev atubaltsev@vmware.com Arnoldo Lutz arnoldo.lutz.guevara@hpe.com Arun Sharma arun.sharma@calsoftinc.com Aryan TaheriMonfared aryan.taherimonfared@uis.no Asaf Penso asafp@mellanox.com Ashish Varma ashishvarma.ovs@gmail.com Ashwin Swaminathan ashwinds@arista.com Babu Shanmugam bschanmu@redhat.com Bala Sankaran bsankara@redhat.com Ben Pfaff blp@ovn.org Ben Warren ben@skyportsystems.com Benli Ye daniely@vmware.com Bert Vermeulen bert@biot.com Bhanuprakash Bodireddy bhanuprakash.bodireddy@intel.com Billy O'Mahony billy.o.mahony@intel.com Binbin Xu xu.binbin1@zte.com.cn Brian Haley haleyb.dev@gmail.com Brian Kruger bkruger+ovsdev@gmail.com Bruce Davie bdavie@vmware.com Bryan Phillippe bp@toroki.com Carlo Andreotti c.andreotti@m3s.it Casey Barker crbarker@google.com Chandra Sekhar Vejendla csvejend@us.ibm.com Christoph Jaeger cj@linux.com Chris Wright chrisw@sous-sol.org Chuck Short zulcss@ubuntu.com Ciara Loftus ciara.loftus@intel.com Clint Byrum clint@fewbar.com Cong Wang amwang@redhat.com Conner Herriges conner.herriges@ibm.com Damien Millescamps damien.millescamps@6wind.com Damijan Skvarc damjan.skvarc@gmail.com Dan Carpenter dan.carpenter@oracle.com Dan McGregor dan.mcgregor@usask.ca Dan Wendlandt Dan Williams dcbw@redhat.com Daniel Alvarez dalvarez@redhat.com Daniel Borkmann dborkman@redhat.com Daniel Hiltgen daniel@netkine.com Daniel Roman Daniele Di Proietto daniele.di.proietto@gmail.com Daniele Venturino venturino.daniele+ovs@gmail.com Danny Kukawka danny.kukawka@bisect.de Darrell Ball dlu998@gmail.com Dave Tucker dave@dtucker.co.uk David Erickson derickso@stanford.edu David Hill dhill@redhat.com David Marchand david.marchand@redhat.com David S. Miller davem@davemloft.net David Yang davidy@vmware.com Dennis Sam dsam@arista.com Devendra Naga devendra.aaru@gmail.com Dmitry Krivenok krivenok.dmitry@gmail.com Dominic Curran dominic.curran@citrix.com Dongdong dongdong1@huawei.com Dongjun dongj@dtdream.com Duan Jiong djduanjiong@gmail.com Duffie Cooley Dujie dujie@didiglobal.com Dumitru Ceara dceara@redhat.com Dustin Lundquist dustin@null-ptr.net Ed Maste emaste@freebsd.org Ed Swierk eswierk@skyportsystems.com Edouard Bourguignon madko@linuxed.net Eelco Chaudron echaudro@redhat.com Eli Britstein elibr@mellanox.com Emma Finn emma.finn@intel.com Eric Lapointe elapointe@corsa.com Esteban Rodriguez Betancourt estebarb@hpe.com Aymerich Edward edward.aymerich@hpe.com Edward Tomasz Napierała trasz@freebsd.org Eitan Eliahu eliahue@vmware.com Eohyung Lee liquidnuker@gmail.com Eric Dumazet edumazet@google.com Eric Garver e@erig.me Eric Sesterhenn eric.sesterhenn@lsexperts.de Ethan J. Jackson ejj@eecs.berkeley.edu Ethan Rahn erahn@arista.com Eziz Durdyyev ezizdurdy@gmail.com Flavio Fernandes flavio@flaviof.com Flavio Leitner fbl@redhat.com Francesco Fusco ffusco@redhat.com Frédéric Tobias Christ fchrist@live.de Frode Nordahl frode.nordahl@gmail.com FUJITA Tomonori fujita.tomonori@lab.ntt.co.jp Gabe Beged-Dov gabe@begeddov.com Gaetano Catalli gaetano.catalli@gmail.com Gal Sagie gal.sagie@gmail.com Genevieve LEsperance glesperance@pivotal.io Geoffrey Wossum gwossum@acm.org Gianluca Merlo gianluca.merlo@gmail.com Giuseppe Lettieri g.lettieri@iet.unipi.it Glen Gibb grg@stanford.edu Gowrishankar Muthukrishnan gmuthukr@redhat.com Guoshuai Li ligs@dtdream.com Guolin Yang gyang@vmware.com Guru Chaitanya Perakam gperakam@Brocade.com Gurucharan Shetty guru@ovn.org Han Zhou zhouhan@gmail.com Harry Van Haaren harry.van.haaren@intel.com Henry Mai Hao Zheng Helmut Schaa helmut.schaa@googlemail.com Hiteshi Kalra hiteshi.kalra@tcs.com Huanle Han hanxueluo@gmail.com Hui Kang kangh@us.ibm.com Hyong Youb Kim hyonkim@cisco.com Ian Campbell Ian.Campbell@citrix.com Ian Stokes ian.stokes@intel.com Ilya Maximets i.maximets@ovn.org Iman Tabrizian tabrizian@outlook.com Isaku Yamahata yamahata@valinux.co.jp Ivan Dyukov i.dyukov@samsung.com IWASE Yusuke iwase.yusuke@gmail.com Jaime Caamaño Ruiz jcaamano@suse.com Jakub Libosvar libosvar@redhat.com Jakub Sitnicki jsitnicki@gmail.com James P. roampune@gmail.com James Page james.page@ubuntu.com Jamie Lennox jamielennox@gmail.com Jan Scheurich jan.scheurich@ericsson.com Jan Vansteenkiste jan@vstone.eu Jarno Rajahalme jarno@ovn.org Jason Kölker jason@koelker.net Jason Wessel jason.wessel@windriver.com Jasper Capel jasper@capel.tv Jean Tourrilhes jt@hpl.hp.com Jeremy Stribling Jeroen van Bemmel jvb127@gmail.com Jesse Gross jesse@kernel.org Jian Li lijian@ooclab.com Jianbo Liu jianbol@mellanox.com Jing Ai jinga@google.com Jiri Benc jbenc@redhat.com Joe Perches joe@perches.com Joe Stringer joe@ovn.org Jonathan Vestin jonavest@kau.se Jorge Arturo Sauma Vargas jorge.sauma@hpe.com Jun Nakajima jun.nakajima@intel.com JunhanYan juyan@redhat.com JunoZhu zhunatuzi@gmail.com Justin Pettit jpettit@ovn.org Kaige Fu fukaige@huawei.com Keith Amidon Ken Ajiro ajiro@mxw.nes.nec.co.jp Ken Sanislo ken@intherack.com Kenneth Duda kduda@arista.com Kentaro Ebisawa ebiken.g@gmail.com Keshav Gupta keshav.gupta@ericsson.com Kevin Lo kevlo@FreeBSD.org Kevin Traynor kevin.traynor@intel.com Khem Raj raj.khem@gmail.com Kmindg G kmindg@gmail.com Kris Murphy kriskend@linux.vnet.ibm.com Krishna Kolakaluri kkolakaluri@plume.com Krishna Kondaka kkondaka@vmware.com Kyle Mestery mestery@mestery.com Kyle Simpson kyleandrew.simpson@gmail.com Kyle Upton kupton@baymicrosystems.com Lance Yang lance.yang@arm.com Lance Richardson lance.richardson@broadcom.com Lars Kellogg-Stedman lars@redhat.com Lei Huang huang.f.lei@gmail.com Leif Madsen lmadsen@redhat.com Leo Alterman Li RongQing lirongqing@baidu.com Lian-min Wang liang-min.wang@intel.com Liu Chang liuchang@cmss.chinamobile.com Lilijun jerry.lilijun@huawei.com Lili Huang huanglili.huang@huawei.com Liliia Butorina l.butorina@partner.samsung.com Linda Sun lsun@vmware.com Lior Neudorfer lior@guardicore.com Liu Chang txfh2007@aliyun.com Lorand Jakab lojakab@cisco.com Lorenzo Bianconi lorenzo.bianconi@redhat.com Luca Giraudo Lucas Alvares Gomes lucasagomes@gmail.com Lucian Petrut lpetrut@cloudbasesolutions.com Luigi Rizzo rizzo@iet.unipi.it Luis E. P. l31g@hotmail.com Lukasz Rzasik lukasz.rzasik@gmail.com Lukasz Pawlik lukaszx.pawlik@intel.com Maciej Józefczyk mjozefcz@redhat.com Madhu Challa challa@noironetworks.com Manohar K C manukc@gmail.com Marcin Mirecki mmirecki@redhat.com Mario Cabrera mario.cabrera@hpe.com Mark D. Gray mark.d.gray@intel.com Mark Hamilton Mark Kavanagh mark.b.kavanagh81@gmail.com Mark Maglana mmaglana@gmail.com Mark Michelson mmichels@redhat.com Markos Chandras mchandras@suse.de Martin Casado casado@cs.stanford.edu Martin Fong mwfong@csl.sri.com Martino Fornasa mf@fornasa.it Martin Xu martinxu9.ovs@gmail.com Martin Zhang martinbj2008@gmail.com Maryam Tahhan maryam.tahhan@intel.com Matteo Croce mcroce@redhat.com Matthias May matthias.may@neratec.com Mauricio Vásquez mauricio.vasquezbernal@studenti.polito.it Maxime Coquelin maxime.coquelin@redhat.com Mehak Mahajan Michael Arnaldi arnaldimichael@gmail.com Michal Weglicki michalx.weglicki@intel.com Michele Baldessari michele@acksyn.org Mickey Spiegel mickeys.dev@gmail.com Miguel Angel Ajo majopela@redhat.com Mijo Safradin mijo@linux.vnet.ibm.com Mika Vaisanen mika.vaisanen@gmail.com Minoru TAKAHASHI takahashi.minoru7@gmail.com Moshe Levi moshele@mellanox.com Murphy McCauley murphy.mccauley@gmail.com Natasha Gude Neal Shrader neal@digitalocean.com Neil McKee neil.mckee@inmon.com Neil Zhu zhuj@centecnetworks.com Nicolas J. Bouliane nbouliane@digitalocean.com Nimay Desai nimaydesai1@gmail.com Nithin Raju nithin@vmware.com Niti Rohilla niti.rohilla@tcs.com Nitin Katiyar nitin.katiyar@ericsson.com Numan Siddique nusiddiq@redhat.com Ofer Ben-Yacov ofer.benyacov@gmail.com Ophir Munk ophirmu@mellanox.com Or Gerlitz ogerlitz@mellanox.com Ori Shoshan ori.shoshan@guardicore.com Padmanabhan Krishnan kprad1@yahoo.com Panu Matilainen pmatilai@redhat.com Paraneetharan Chandrasekaran paraneetharanc@gmail.com Paul Boca pboca@cloudbasesolutions.com Paul Fazzone pfazzone@vmware.com Paul Ingram Paul-Emmanuel Raoul skyper@skyplabs.net Pavithra Ramesh paramesh@vmware.com Peter Downs padowns@gmail.com Philippe Jung phil.jung@free.fr Pim van den Berg pim@nethuis.nl pritesh pritesh.kothari@cisco.com Pravin B Shelar pshelar@ovn.org Przemyslaw Szczerbik przemyslawx.szczerbik@intel.com Quentin Monnet quentin.monnet@6wind.com Qiuyu Xiao qiuyu.xiao.qyx@gmail.com Raju Subramanian Rami Rosen ramirose@gmail.com Ramu Ramamurthy ramu.ramamurthy@us.ibm.com Randall Sharo andall.sharo@navy.mil Ravi Kerur Ravi.Kerur@telekom.com Raymond Burkholder ray@oneunified.net Reid Price Remko Tronçon git@el-tramo.be Rich Lane rlane@bigswitch.com Richard Oliver richard@richard-oliver.co.uk Rishi Bamba rishi.bamba@tcs.com Rob Adams readams@readams.net Robert Åkerblom-Andersson Robert.nr1@gmail.com Robert Wojciechowicz robertx.wojciechowicz@intel.com Rob Hoes rob.hoes@citrix.com Rohith Basavaraja rohith.basavaraja@gmail.com Roi Dayan roid@mellanox.com Róbert Mulik robert.mulik@ericsson.com Romain Lenglet romain.lenglet@berabera.info Roni Bar Yanai roniba@mellanox.com Russell Bryant russell@ovn.org RYAN D. MOATS rmoats@us.ibm.com Ryan Wilson Sairam Venugopal vsairam@vmware.com Sajjad Lateef Saloni Jain saloni.jain@tcs.com Samuel Ghinet sghinet@cloudbasesolutions.com Sanjay Sane Saurabh Mohan saurabh@cplanenetworks.com Saurabh Shah Saurabh Shrivastava saurabh.shrivastava@nuagenetworks.net Scott Cheloha scottcheloha@gmail.com Scott Lowe scott.lowe@scottlowe.org Scott Mann sdmnix@gmail.com Selvamuthukumar smkumar@merunetworks.com Sha Zhang zhangsha.zhang@huawei.com Shad Ansari shad.ansari@hpe.com Shan Wei davidshan@tencent.com Sharon Krendel thekafkaf@gmail.com Shashank Ram rams@vmware.com Shashwat Srivastava shashwat.srivastava@tcs.com Shih-Hao Li shihli@vmware.com Shu Shen shu.shen@radisys.com Simon Horman horms@verge.net.au Simon Horman simon.horman@netronome.com Sorin Vinturis svinturis@cloudbasesolutions.com Steffen Gebert steffen.gebert@informatik.uni-wuerzburg.de Sten Spans sten@blinkenlights.nl Stephane A. Sezer sas@cd80.net Stephen Finucane stephen@that.guru Steve Ruan ruansx@cn.ibm.com Stuart Cardall developer@it-offshore.co.uk Sugesh Chandran sugesh.chandran@intel.com SUGYO Kazushi sugyo.org@gmail.com Surya Rudra rudrasurya.r@altencalsoftlabs.com Tadaaki Nagao nagao@stratosphere.co.jp Terry Wilson twilson@redhat.com Tetsuo NAKAGAWA nakagawa@mxc.nes.nec.co.jp Thadeu Lima de Souza Cascardo cascardo@cascardo.eti.br Thomas F. Herbert thomasfherbert@gmail.com Thomas Goirand zigo@debian.org Thomas Graf tgraf@noironetworks.com Thomas Lacroix thomas.lacroix@citrix.com Timo Puha timox.puha@intel.com Timothy Redaelli tredaelli@redhat.com Todd Deshane deshantm@gmail.com Tom Everman teverman@google.com Tomasz Konieczny tomaszx.konieczny@intel.com Toms Atteka cpp.code.lv@gmail.com Torgny Lindberg torgny.lindberg@ericsson.com Tsvi Slonim tsvi@toroki.com Tuan Nguyen tuan.nguyen@veriksystems.com Tyler Coumbes coumbes@gmail.com Tony van der Peet tony.vanderpeet@alliedtelesis.co.nz Tonghao Zhang xiangxia.m.yue@gmail.com Valient Gough vgough@pobox.com Venkata Anil Kommaddi vkommadi@redhat.com Vishal Deep Ajmera vishal.deep.ajmera@ericsson.com Vivien Bernet-Rollande vbr@soprive.net wangqianyu wang.qianyu@zte.com.cn Wang Li wangli39@baidu.com Wang Sheng-Hui shhuiw@gmail.com Wang Zhike wangzhike@jd.com Wei Li liw@dtdream.com Wei Yongjun yjwei@cn.fujitsu.com Wenyu Zhang wenyuz@vmware.com William Fulton William Tu u9012063@gmail.com Xiao Liang shaw.leon@gmail.com xu rong xu.rong@zte.com.cn YAMAMOTO Takashi yamamoto@midokura.com Yanqin Wei Yanqin.Wei@arm.com Yasuhito Takamiya yasuhito@gmail.com Yi Yang yangyi01@inspur.com Yi-Hung Wei yihung.wei@gmail.com Yifeng Sun pkusunyifeng@gmail.com Yin Lin linyi@vmware.com Yu Zhiguo yuzg@cn.fujitsu.com Yuanhan Liu yuanhan.liu@linux.intel.com Yunjian Wang wangyunjian@huawei.com Yousong Zhou yszhou4tech@gmail.com Zak Whittington zwhitt.vmware@gmail.com ZhengLingyun konghuarukhr@163.com Zoltán Balogh zoltan.balogh.eth@gmail.com Zoltan Kiss zoltan.kiss@citrix.com Zongkai LI zealokii@gmail.com Zhi Yong Wu zwu.kernel@gmail.com Zang MingJie zealot0630@gmail.com Zhenyu Gao sysugaozhenyu@gmail.com ZhiPeng Lu luzhipeng@uniudc.com Zhou Yangchao 1028519445@qq.com aginwala amginwal@gmail.com parameswaran krishnamurthy parkrish@gmail.com solomon liwei.solomon@gmail.com wenxu wenxu@ucloud.cn wisd0me ak47izatool@gmail.com xushengping shengping.xu@huawei.com yinpeijun yinpeijun@huawei.com zangchuanqiang zangchuanqiang@huawei.com zhaojingjing zhao.jingjing1@zte.com.cn zhongbaisong zhongbaisong@huawei.com zhaozhanxu zhaozhanxu@163.com ================================== =============================================== The following additional people are mentioned in commit logs as having provided helpful bug reports or suggestions. =============================== =============================================== Name Email =============================== =============================================== Aaron M. Ucko ucko@debian.org Abhinav Singhal Abhinav.Singhal@spirent.com Adam Heath doogie@brainfood.com Ahmed Bilal numan252@gmail.com Alan Kayahan hsykay@gmail.com Alan Shieh Alban Browaeys prahal@yahoo.com Alex Yip Alexey I. Froloff raorn@altlinux.org Amar Padmanabhan Amey Bhide Amre Shakimov ashakimov@vmware.com André Ruß andre.russ@hybris.com Andreas Beckmann debian@abeckmann.de Andrei Andone andrei.andone@softvision.ro Andrey Korolyov andrey@xdel.ru Anil Jangam anilj.mailing@gmail.com Anshuman Manral anshuman.manral@outlook.com Anton Matsiuk anton.matsiuk@gmail.com Anup Khadka khadka.py@gmail.com Anuprem Chalvadi achalvadi@vmware.com Ariel Tubaltsev atubaltsev@vmware.com Arkajit Ghosh arkajit.ghosh@tcs.com Atzm Watanabe atzm@stratosphere.co.jp Aurélien Poulain aurepoulain@viacesi.fr Bastian Blank waldi@debian.org Ben Basler Bhargava Shastry bshastry@sec.t-labs.tu-berlin.de Bob Ball bob.ball@citrix.com Brad Hall Brad Cowie brad@wand.net.nz Brailey Josh josh@faucet.nz Brandon Heller brandonh@stanford.edu Brendan Kelley Brent Salisbury brent.salisbury@gmail.com Brian Field Brian_Field@cable.comcast.com Bryan Fulton Bryan Osoro Cedric Hobbs Chris Hydon chydon@aristanetworks.com Christian Stigen Larsen cslarsen@gmail.com Christopher Paggen cpaggen@cisco.com Chunhe Li lichunhe@huawei.com Daniel Badea daniel.badea@windriver.com Darragh O'Reilly darragh.oreilly@hpe.com Dave Walker DaveWalker@ubuntu.com David Evans davidjoshuaevans@gmail.com David Palma palma@onesource.pt David van Moolenbroek dvmoolenbroek@aimvalley.nl Derek Cormier derek.cormier@lab.ntt.co.jp Dhaval Badiani dbadiani@vmware.com DK Moon Ding Zhi zhi.ding@6wind.com Dong Jun dongj@dtdream.com Dustin Spinhirne dspinhirne@vmware.com Edwin Chiu echiu@vmware.com Eivind Bulie Haanaes Enas Ahmad enas.ahmad@kaust.edu.sa Eric Lopez Frido Roose fr.roose@gmail.com Gaetano Catalli gaetano.catalli@gmail.com Gavin Remaley gavin_remaley@selinc.com Georg Schmuecking georg.schmuecking@ericsson.com George Shuklin amarao@desunote.ru Gerald Rogers gerald.rogers@intel.com Ghanem Bahri bahri.ghanem@gmail.com Giuseppe de Candia giuseppe.decandia@gmail.com Gordon Good ggood@vmware.com Greg Dahlman gdahlman@hotmail.com Greg Rose gvrose8192@gmail.com Gregor Schaffrath grsch@net.t-labs.tu-berlin.de Gregory Smith gasmith@nutanix.com Guolin Yang gyang@vmware.com Gur Stavi gstavi@mrv.com Harish Kanakaraju hkanakaraju@vmware.com Hari Sasank Bhamidipalli hbhamidi@cisco.com Hassan Khan hassan.khan@seecs.edu.pk Hector Oron hector.oron@gmail.com Hemanth Kumar Mantri mantri@nutanix.com Henrik Amren Hiroshi Tanaka Hiroshi Miyata miyahiro.dazu@gmail.com Hsin-Yi Shen shenh@vmware.com Hui Xiang xianghuir@gmail.com Hyojoon Kim joonk@gatech.edu Igor Ganichev Igor Sever igor@xorops.com Jacob Cherkas cherkasj@vmware.com Jad Naous jnaous@gmail.com Jamal Hadi Salim hadi@cyberus.ca James Schmidt jschmidt@vmware.com Jan Medved jmedved@juniper.net Janis Hamme janis.hamme@student.kit.edu Jari Sundell sundell.software@gmail.com Javier Albornoz javier.albornoz@hpe.com Jed Daniels openvswitch@jeddaniels.com Jeff Merrick jmerrick@vmware.com Jeongkeun Lee jklee@hp.com Jian Qiu swordqiu@gmail.com Joan Cirer joan@ev0.net John Darrington john@darrington.wattle.id.au John Galgay john@galgay.net John Hurley john.hurley@netronome.com John Reumann nofutznetworks@gmail.com Karthik Sundaravel ksundara@redhat.com Kashyap Thimmaraju kashyap.thimmaraju@sec.t-labs.tu-berlin.de Keith Holleman hollemanietf@gmail.com Kevin Lin kevinlin@berkeley.edu K 華 k940545@hotmail.com Kevin Mancuso kevin.mancuso@rackspace.com Kiran Shanbhog kiran@vmware.com Kirill Kabardin Kirkland Spector kspector@salesforce.com Klemens Nanni klemens@posteo.de Koichi Yagishita yagishita.koichi@jrc.co.jp Konstantin Khorenko khorenko@openvz.org Kris zhang zhang.kris@gmail.com Krishna Miriyala miriyalak@vmware.com Krishna Mohan Elluru elluru.kri.mohan@hpe.com László Sürü laszlo.suru@ericsson.com Len Gao leng@vmware.com Logan Rosen logatronico@gmail.com Luca Falavigna dktrkranz@debian.org Luiz Henrique Ozaki luiz.ozaki@gmail.com Manpreet Singh er.manpreet25@gmail.com Marco d'Itri md@Linux.IT Martin Vizvary vizvary@ics.muni.cz Marvin Pascual marvin@pascual.com.ph Maxime Brun m.brun@alphalink.fr Madhu Venugopal mavenugo@gmail.com Malvika Gupta malvika.gupta@arm.com Michael A. Collins mike.a.collins@ark-net.org Michael Ben-Ami mbenami@digitalocean.com Michael Hu humichael@vmware.com Michael J. Smalley michaeljsmalley@gmail.com Michael Mao Michael Shigorin mike@osdn.org.ua Michael Stapelberg stapelberg@debian.org Mihir Gangar gangarm@vmware.com Mike Bursell mike.bursell@citrix.com Mike Kruze Mike Qing mqing@vmware.com Min Chen ustcer.tonychan@gmail.com Mikael Doverhag Mircea Ulinic ping@mirceaulinic.net Mrinmoy Das mrdas@ixiacom.com Muhammad Shahbaz mshahbaz@cs.princeton.edu Murali R muralirdev@gmail.com Nagi Reddy Jonnala njonnala@Brocade.com Niels van Adrichem N.L.M.vanAdrichem@tudelft.nl Niklas Andersson Oscar Wilde xdxiaobin@gmail.com Pankaj Thakkar pthakkar@vmware.com Pasi Kärkkäinen pasik@iki.fi Patrik Andersson R patrik.r.andersson@ericsson.com Paul Greenberg Paulo Cravero pcravero@as2594.net Pawan Shukla shuklap@vmware.com Periyasamy Palanisamy periyasamy.palanisamy@ericsson.com Peter Amidon peter@picnicpark.org Peter Balland Peter Phaal peter.phaal@inmon.com Prabina Pattnaik Prabina.Pattnaik@nechclst.in Pratap Reddy Ralf Heiringhoff ralf@frosty-geek.net Ram Jothikumar Ramana Reddy gtvrreddy@gmail.com Ray Li rayli1107@gmail.com Richard Theis rtheis@us.ibm.com RishiRaj Maulick rishi.raj2509@gmail.com Rob Sherwood rob.sherwood@bigswitch.com Robert Strickler anomalyst@gmail.com Roger Leigh rleigh@codelibre.net Rogério Vinhal Nunes Roman Sokolkov rsokolkov@gmail.com Ronaldo A. Ferreira ronaldof@CS.Princeton.EDU Ronny L. Bull bullrl@clarkson.edu Sandeep Kumar sandeep.kumar16@tcs.com Sander Eikelenboom linux@eikelenboom.it Saul St. John sstjohn@cs.wisc.edu Scott Hendricks Sean Brady sbrady@gtfservices.com Sebastian Andrzej Siewior sebastian@breakpoint.cc Sébastien RICCIO sr@swisscenter.com Shweta Seth shwseth@cisco.com Simon Jouet simon.jouet@gmail.com Spiro Kourtessis spiro@vmware.com Sridhar Samudrala samudrala.sridhar@gmail.com Srini Seetharaman seethara@stanford.edu Sabyasachi Sengupta Sabyasachi.Sengupta@alcatel-lucent.com Salvatore Cambria salvatore.cambria@citrix.com Soner Sevinc sevincs@vmware.com Stepan Andrushko stepanx.andrushko@intel.com Stephen Hemminger shemminger@vyatta.com Stuart Cardall developer@it-offshore.co.uk Suganya Ramachandran suganyar@vmware.com Sundar Nadathur undar.nadathur@intel.com Taekho Nam thnam@smartx.kr Takayuki HAMA t-hama@cb.jp.nec.com Teemu Koponen Thomas Morin thomas.morin@orange.com Timothy Chen Torbjorn Tornkvist kruskakli@gmail.com Tulio Ribeiro tribeiro@lasige.di.fc.ul.pt Tytus Kurek Tytus.Kurek@pega.com Valentin Bud valentin@hackaserver.com Vasiliy Tolstov v.tolstov@selfip.ru Vasu Dasari vdasari@gmail.com Vinllen Chen cvinllen@gmail.com Vishal Swarankar vishal.swarnkar@gmail.com Vjekoslav Brajkovic balkan@cs.washington.edu Voravit T. voravit@kth.se Yeming Zhao zhaoyeming@gmail.com Yi Ba yby.developer@yahoo.com Ying Chen yingchen@vmware.com Yongqiang Liu liuyq7809@gmail.com ZHANG Zhiming zhangzhiming@yunshan.net.cn Zhangguanghui zhang.guanghui@h3c.com Ziyou Wang ziyouw@vmware.com ankur dwivedi ankurengg2003@gmail.com chen zhang 3zhangchen9211@gmail.com james hopper jameshopper@email.com kk yap yapkke@stanford.edu likunyun kunyunli@hotmail.com meishengxin meishengxin@huawei.com neeraj mehta mehtaneeraj07@gmail.com rahim entezari rahim.entezari@gmail.com shaoke xi xishaoke.xsk@gmail.com shivani dommeti shivani.dommeti@gmail.com weizj 34965317@qq.com 俊 赵 zhaojun12@outlook.com 冯全树(Crab) fqs888@126.com 张东亚 fortitude.zhang@gmail.com 胡靖飞 hujingfei914@msn.com 张伟 zhangwqh@126.com 张强 zhangqiang@meizu.com =============================== =============================================== Thanks to all Open vSwitch contributors. If you are not listed above but believe that you should be, please write to dev@openvswitch.org. ovs-2.13.0/CONTRIBUTING.rst000066400000000000000000000024201362155554400150550ustar00rootroot00000000000000.. 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. ============================ Contributing to Open vSwitch ============================ As an open source project, we welcome contributions of any kind. These can range from bug reports and code reviews, to signficant code or documentation features. Extensive guidelines are provided in the docs at ``Documentation/internals/contributing``, or `online `__. ovs-2.13.0/Documentation/000077500000000000000000000000001362155554400152275ustar00rootroot00000000000000ovs-2.13.0/Documentation/_static/000077500000000000000000000000001362155554400166555ustar00rootroot00000000000000ovs-2.13.0/Documentation/_static/logo.png000066400000000000000000024407271362155554400203430ustar00rootroot00000000000000PNG  IHDRNtr?gAMA abKGD pHYsaa?itIME  $3M^` IDATxiz_ IDAT<Ǽ IDAT;<<;<<,--,--,--:;;,-,;<<݊ IDAT,-,;<;,--+,,,-,JKK,--;<<,--;<;,--IKJJKK,--;<<,--IKJIKJJKK,--:<;YZZ,--giiXZYIKJXZZU8 IDATgiiXZYiz:;;JKKXZYgiiXZYWYXJKK;<<giiXZY+,,YZZXZY:;;giiXZYax IDAT|yzJKKgiiXZYIJJXZZgih|yzJKKvxxXZYWYX:;;vxw,--Y IDAT|yzWYXfhgvxx^[\:;;uxwJKK^[\+,,:;;^[\+,,uwwgihH9 IDAT^[\,--mjk:;;^[\PLM2./^[\OLMnkl_\]^[\{yymjk:;;9S IDATPLMfhgvxxPLM2./|yziznkl_\]{yyWYX2./mjk{yy- IDATmjk^[\IJJnkl;<<mjk+,,A=>PLMOLM^[\,--_\] IDAT;<<^[\^[\|yz^[\mjk^[\OLM^[\OLM IDAT^[\,--IJJ:;;,-,^[\,--,-,,-,,--WYXOLM:;;,-,;<<;<<fhgvxx{yyIKJ;<<;<<WYXB>?XZYXZZ+,,;<;JKK,--uwwgihgiiXZY m IDATXZYvxx_\]IJJ,--IKJ,--A=>fhgvxxmjkIJJuxwPLMIJJ;<<XZY_\]+,,,--{yy;<<izOLM:;;IJJ{yyWYXXZYvxx+,,vxw;<<uwwgih2./WYXIJJuxw6 IDATnklgiiXZY,--PMNWYXPMN;<<|yzfhgXZYgihfhgmjkIJJ,--uwwfhg;<<mjkfhgvxxvxxWYXmjkgihWYXIJJvxxIJJvxx:;;+,,B>? IDATvxxXZY|zz^[\IJJPLMXZYvxx|yzXZYXZY{yyIKJvxxIJJvxx+,,,--;<<JKKXZY:;;|yz:;;,--+,,|yzIKJgihfhg;<<WYX p IDATWYX;<<;<<WYXIJJvxxPMNuwwgih_\]2./;<<{yzgihvxxgiifhg;<<JKKXZYgih+,,IJJvxx,--T IDAT;<<,--vxx,--;<<fhgizWYXXZYvxxIJJ+,,- IDAT+,,;<<,--vxxuww;<<XZYfhg,--WYXgih[vxx:;;c2 IDAT|yz+,,?m:jXZY,--Kwյ,--WYXIKJ|zz{yyvxxlkgii9 IDAT+,,{yyXZYֶTWYXXZY,--JKKJKK,--3/0{ƛϪ G}2&B>?_\]B>?;<<PMNgiigihXZYKwյWYX;<<+,,:;;;<<,--OLMvxxl{ƛgiiYZZB IDATXZYIKJ_\]{yyXZYϪ[WYXXZYJKKJKKB>?{yyvxx?mgiigiigii,--B>?{yyXZY:jWYXXZYXZYIKJB>?^[\izvxxKwյgiigii IDATgiigiinklA=>XZYlkfhgXZYXZYXZYB>?^[\vxxֶ:jXZZgiigiivxx|zz2./IJJ.`+,,XZYXZYvxxPMNOLM,--Kw9dc+K;<;XZZ;<< Z IDATgiiXZY|zzIKJJKK;<<nkl{ƛϪr1V:e_\],--2./;<<_\]_\]XZZgihϪ[;<<XZYXZZ;<<:;;$ !mjkIKJ?m;<<vxxgih_\]A=>;<<:j;<<XZYXZYvxxgH IDAT|zz2./_\]{ƛϪ@pc+K$ !2./B>?WYXgii;<<lk+,,XZYXZYgihWYXB>?{yy;<<ֶ:j;<;vxxvxx:;;B>?{yy:<;.`JKKXZYXZY+,,!@ IDATB>?+,,Kw,--XZZvxx2./;<; G}!IKJWYXXZY,--2./;<<1%NB2giivxx,--+,,OLMA1T2&,-,WYXXZY,--+,,PMN< IDATiz;<<b*JOgiiXZZWYX^[\{ƛ9dAq,--WYXWYXfhgPLM:;;JvϪ G|s2Wgiigiivxx^[\?m NS$?,--WYXWYXXZY+,,PLM'A3 IDAT,-,Kw1%[2&giigii,--fhg|zzΩ\b*JV:;;WYXvxx+,,|zz{yy;<<k|ǜ9dAqgihgii,--fhg{yy?md+LC3ֶ @pS$?;<<;<<:;;vxxWYXvxxJKK{yz IDAT;<<Kw!! G}2&gihXZYgii,--OLMյ;k1%[2&;<<:;;WYXXZYfhgOLM{ƛlb*JVgihJKKvxxfhg2./JvϪ9dAq;<<:;;:;;;<<vxxWYXOLM?m/H IDAT G|s2WgihgihWYXKw NS$?;<<+,,:;;;<<fhgΩ\1%[2&YZZgihvxxfhgk|ǜb*JVXZY:;;;<<vxx+,,{yz?mֶ: IDAT9dAq,--giigihXZYWYXmjkizT G|s2WXZY:;;;<<;<<fhgյl{ƛ"c+K G}2&gii|zzvxxgihvxxvxx;<;,--{ƛϪϪA1c+K1%TXZYgih+,,;<<XZYXZYJvϪb*JVM% IDATgiiYZZ,--fhg,-,?m9dAqXZYXZYvxx:;;KwG|s2WIKJgiiJKKWYXΩ\s2WS$?;<<vxxXZYfhg,-,k|ǜ>73 IDATXZYgiivxxfhg;<<?mֶvxxXZYvxxfhgT+,,XZYgiivxxfhg:;;|ǜvxxXZYvxxIJJOb*J,-,] IDATXZYgiiAq@pvxxXZY;<<fhg,--c+KN XZYIKJvxxB2N1%;<<XZZvxx;<<+,,;<<2&TA1WYXﶃ IDATXZYWYX+,,Ob*J:;;giivxxWYXiz;<;Aq@p,-,WYXXZYIJJ,--c+KN JKKgiivxx+,,JKKB2N1%,--WYX IDATXZY+,,2&TA1;<<giivxxuxw;<;,--Okֶk,--WYXXZYJKK,--Aq@p;<;YZZvxxJKKc+KN ,--,--:;;IKJ_- IDATfhg+,,B2N1%;<<gihgiiJKK;<;2&TA1,--;<<:;;WYX,--JKKOb*JIKJgihgiiIKJ,--Aq@p:;;;<<:;;WYXp IDAT^[\$ !PMNJKKIKJ;<<c+K![JKKgihgii,--XZZ<B2NlXZY;<<:;;WYX:;;+,,XZY2&TOyWYXgihgiiYZZ|zzXZYOkֶ;<<;<<WYXJ IDAT,-,XZY|zzvxxAq2&lJKKgii|zzgiiIJJJKK,--c+K![XZYXZY:;;izIKJ{yzB2N1%^[\JKKgiigih$ !_\]JKK^[\2&TA1mjk,--XZY:;;;<<,-,P IDATXZYOr1V{yygiigiigihvxx:eXZYXZY:;;;<<;<<XZY|zzgiigiigihvxx^[\XZYXZY:;;;<<,--De IDATXZYmjk^[\giiIKJgihvxxmjkOLMXZYvxx:;;;<<WYX{yyXZYXZYgihgii{yyvxxvxx;<<,-,+,,WYXp[ IDAT{yymjkXZYXZYgii;<<OLMOLMvxxvxxXZY:;;,-,gii2./^[\XZYgii,-,gih:;;^[\_\]IJJ;<<vxxXZY;<<;<<vxw|zz IDAT{yy|zzuxwIKJgii;<<;<<,--fhgmjkOLMXZYgiiXZY:;;|yzIKJvxxOLMA=>+,,vxxWYXgii,-,;<<izuxwPLM^[\vxwgiiXZY;<<JKKJKK:;;nkl^[\4k# IDATA=>|zzWYX;<<WYXgii;<<^[\mjkIJJ_\]mjk^[\_\]giiXZYXZYmjk^[\;<<B>?{yy{yy_\]WYXXZYXZZ^[\{yy:<;XZYvxx{yyuwwgihB>?^[\+,,{yy+,,vxx+,,2./2./bY IDATIJJgihWYXXZYXZY2./OLMJKK2./giiXZY_\]A=>uwwgihOLM,--|zz$ !mjkmjk$ !|zz;<<:;;XZYIKJ^[\2./,--+,,JKKIKJXZY_\]B>?WYXgii|yzfhgvxx^[\IKJJKK,--WYX<@ IDAT^[\fhgvxxmjkWYXYZZ,--OLM:<;;<<;<<+,,_\]_\]:<;;<<JKKXZY2./,--+,,^[\fhgvxxA=>:;;,-,,-,,--^[\+,,_\]nkl;<<,--d` IDAT;<<:;;WYXJKK:;;:;;;<<,--,--XZYgiigih,--,--JKKWYXXZYWYX;<<XZY,--giigiivxx+,,giiizXZYJKKrpo IDATXZYWYXvxwfhgXZYXZYgiigii;<<fhgvxxXZY,--XZYWYXvxxvxx,--+,,,--giigiiuxwfhgXZY,--+,,:;;XZYWYX IDATJKKIJJWYXvxx:;;WYXgiiYZZ+,,+,,WYXfhgXZY:;;,--+,,vxxXZYgih{yz:;;2./:;;y IDAT^[\JKK,--fhgfhgXZYgih,--JKK|yz;<<2./:;;|zzWYXJKK:;;IJJ;<<XZYgihXZYWYXgiigih2./:;;O˅1 IDATfhgvxxvxx:;;WYXgihXZYgihgihfhgvxx|yz+,,vxw;<<2./:;;mjk+,,;<<fhguww;<<IKJXZY;<<:;;WYXfhgvxxB>?H( IDATuwwgihiz:;;:;;vxxWYXgiivxxgihWYXJKK;<<B>?mjk+,,;<<WYXWYX;<<WYXgiifhgfhgXZYXZZB>?XZYvxx@< IDATXZYvxx{yyXZYXZYvxxIKJ;<<JKKB>?XZYvxxIJJ;<<XZY{yyXZYXZYvxx:;;JKKXZY_\]|yzXZYvxx Q IDAT:<;--.:<;^[\uwwgihIKJ,--JKK:<;--.:<;_\]IJJ,--IKJ:;;--.:<;^[\fhgvxxIKJ,--JKK:;;;<<_\]:;;,-,IKJX IDAT,-,,-,;<<^[\fhgvxx;<<;<<mjkJKKvv IDATiz2 IDATs4 IDAT1ѩ IDAT)# IDATiz( IDATXZY$ !:;;]y IDAT;<<:;;--.:<;:<;JKK;<< IDAT+,,JKKIKJgiiXZYJKK,--$ !:;;WYXgii{yz+,,,--:;;$ !:;;WYX|zzJKK+,,$ !:;;PLM2./|zznkly IDAT^[\mjk|zz^[\,-,;<<A=>,--|zz:<;;<<,-,,--izIKJJKK,--JKK^[\,--+,,gihJKKJKKmjk;<<|zz:;;vxw,--;<<nklfhgvxxmjkIJJOLM,--,--<~ IDAT$ !:;;_\];<<,--{yyXZYA=>;<<mjkXZY$ !:;;$ !:;;mjkfhg;<<JKKWYX^[\IJJXZYfhg;<<,--uww:;;:;;WYXXZYOLMXZY|zz+,,_\],--$ !:;;$ !:;;XZYXZY+,,JKKk; IDAT,--JKK;<;|yz,--;<<fhgWYXXZYvxxIJJ,-,[ IDATgiiXZY;<<XZYvxxIJJgiiXZY;<<|zzXZYvxxXZY:;;A=> IDATIKJ:;;JKK+,,,-,;<<JKK+,,;<<XZY+,,;<;JKK,--vxw^[\_\]:;;JKKXZY,--JKK:;;,-,,--JKK+,,;<;JKK,--2./XZY_\]fhgvxxXZYvxxIJJuxw$ !:;;|yz:;;vxw,--^[\B>?fhgvxx|zzXZYXZZA=>+,,IJJ^[\_\]fhgvxx^[\;<<IKJgii$ !:;;|yz:;;vxw,--XZYIKJPMNA=>A=>B>?_\]PMNgihvxxXZYB>?^[\giiXZY^[\_\]B>?_\]PMNiz+,,mjknkl{yy{yynklOLM^[\|zz;<<:;;IKJXZY|zz2./XZYvxx_\]^[\|zzt IDAT,--^[\{yy{yyOLM{yy|zzgihgii,--WYX2./giiXZY^[\{yy|zz,-,{yy:;;:;;+,,^[\;<<:;;WYX:;;2./XZYvxxA=>IKJJKK,--;<<;<<XZYJKK,--JKKWYXJKK;<<giiXZYgii;<<;<<nklgii|zzgiiXZYXZYOLMIKJ,--WYXJKK;<<giifhgvxxfhgvxx_\]fhgvxxA=>IJJmjk$ !+,,{yyuwwgihA=>WYXA=>WYX+,,A=>fhgvxxB>?;<<_\]fhgvxx_\]+,,vxw;<<{yy;<<$ !+,,{yyuwwgihvxxs IDATXZY+,,WYX;<<+,,IJJgiigii,--uwwOLMgiiXZY,--;<<;<<;<<;<<;<<;<<;<<;<<;<<fhg;<<gihIJJIJJ,--+,,IJJvxwXZYXZYWYXgih:;;OLMXZYvxxvxxfhgXZYfhg,--,--fhg+,,;<<;<<giigiiXZYXZYXZYfhgXZYvxx+,,;<<;<<,--,-,vxx,--fhgXZYXZZJKK,--XZYWYX;<<fhgvxxvxx:;;vxxXZYJKK:<;giiXZZXZZ\웣 IDAT:;;;<;giigiivxxXZYXZY;<;;<<XZYIJJ+,,,-,,--XZY:;;;<<vxxvxxWYX,--+,,JKK:;;;<<,--JKK^[\;<<JKKgii|zzXZYgih,--fhgJKKXZY;<<|zz,--XZY;<<JKK;<;,-,,--;<;XZYJKK:;;;<<vxxJKKvxx,--+,,XZYXZZJKK,-,,--JKK,-,,--k IDATXZYgihIKJXZYYZZJKKWYX+,,JKK,--vxx:;;;<<;<<vxxXZY;<<+,,giiIKJXZZXZYgihXZYXZYYZZWYXgiiXZYIKJuww,-,vxx:;;;<<IKJvxxvxxvxxXZYJKKgiiiz:;;vxx{yyWYX;<<9\ IDATXZYgih,-,XZYvxxWYXIKJJKKWYXgihgii,-,vxx:;;;<<PMN|zz,--vxxgiivxxgii,--;<<WYX|zzfhg,--XZYXZY:;;XZYmjk:;;WYX_[\WYX^[\mjkvxx,--vxxJKK,-,,--XZZgihgiigii;<<vxx^[\^[\:<;mjk^[\IKJgiiJKK IDATIKJWYX;<<:;;WYXJKKXZYfhg_\]|zzfhg;<<IKJ--._\]{yygiiXZY,--+,,+,,giigiiXZYgiiIKJvxx+,,|zzmjk^[\WYXvxx{yzXZZXZYmjkPLMWYXgiiYZZOLMmjkJKKWYXXZYJKKWYXgiiOLMOLM+,,B>?{yy{yyPMN+,,OLMIJJXZY{yy^[\giiXZYXZYOLMOLMgihgiiXZYgiigiiWYXOLM2./+,,2./{yy{yyB>?+,,^[\{yygihvxx{yy^[\IJJ;<<WYXgiiuxw2./A=>gii` IDATWYXXZZXZYWYXA=>PMN:;;nkl2./mjkmjk$ !nklWYXPLMA=>fhg,--A=>^[\_\]+,,giiXZYJKKIJJ|zzA=>OLMnklIJJXZYgiiWYXXZYgii|zzA=>2./fhgvxxIJJ+,,;<;vxxJKK|zz;<<WYXgiiOLM+,,WYXYZZXZZIJJ;<<|zz:;;vxx,--|yz;<<vxx|zz,--giiXZYOLMgii:;;,--WYXXZYXZYJKKfhgfhg;<<XZY,--WYX,--WYXgii+,,:;;WYXXZYJKK:;;;<<Sf IDATvxxvxxWYXWYXvxxXZY:;;,--fhgfhg,--JKKXZYfhgfhggiiJKK;<<+,,gihJKK:;;fhguww,--IJJvxx:;;:;;vxx;<<:;;XZYvxx:;;WYXvxxWYXgiiYZZ:;;;<<,--fhg:;;,-,JKK,--_\]fhgvxxIJJ;<<XZYIKJJKK,--XZY;<<;<<mjk+,,;<;XZZPLMA=>;<<;<<;<<XZYIJJ;<<XZYXZY;<<;<<;<<_\]fhgvxx,-,;<<,--,--;<<,-,;<<,--;<< IDAT;<<iz_\]fhgvxx<@f IDAT& IDAT IDATR IDATSVi IDATq"IDATmVrkIENDB`ovs-2.13.0/Documentation/_static/overview.png000066400000000000000000006145071362155554400212460ustar00rootroot00000000000000PNG  IHDRRUt9IDATxpօf63333=33; ff3ef;fz)ww^mv$y,\Sծ$O9{1YB!B!$/B!y!B !B !BH^!BB!BB!B!B!B!B!$/B!y!B!y!B !寿pGtǿ B_K=-$/49 Ӆm:|I0]Ba^8"a|lJ# !y!H_X>aZa5kL0?۩S6!\ÕyN4i [wIS:cNZg^D!ovÆ +WQGuaqAe!xYrq'/_cĉ}/xjk㺈B T.p RF~m4| lq+ҥK/_t@-[ !-C=tG3D|KM)RV!Cr-HfΜ9[dV̽<3<78|p* ^mq#}Qw"$/L[݇ͥM0s w {ݺuSD|{h > ^h^TgM:\B ͚531i<ߢ^zO?4 t"F4BA7ԃիWuM߳`UH^IwP~ -*Bp]~ay#ľR)~ Dv{/w0RQ<9+xU !,˵ ݻwRJ+WdO!r ޼Y#1˝!1YzuŊqC'o|kEL$/ȵ @8@޼y^9w֭;wRԵdL^MS/}"0Sn~D飢 !r0PoM7݄fh (\ 8_p U謳Z`$2E{1gP^B 4n۶ɓ`.zރ@[ŋߵk%WH^/ P?[!3/9hI1Lna8O>>3[ /8#G:?݀BB܁mVhQb J 90D &'[nٲ|F,aec.4OJq?EX+EH^{.M0!FRi|ȣ95kYw·~KOFzPˌ2)y!D.oڵkro&$I"f3͂m4M+!> tDaÆN8( رc;_xn?\Ĵ}RSsaŒ56o~ΝvfT\> !{ q8S׮]f`a5.]xeaѣg̘r bǏ1n1 ySIPL3Jaϫ& `8(ӧ#DN !r,"P &AKhK*y桦/(mYZGhעE ?I{z5 Jxhq" ` ? 0) !y#49{.]Hs”! ݇9j&8+ COnvj0N䫮 ~j 0 a5lYF !r}WnEs]Pj9_~_|Au_ !brQf((PuT"WCuv& .3զJ^ć$̏>L)*=Fڳg5L7y:Ofa>E{\qA #I41-2(;{])@A//?Cg_}~BBd ^bE2e`t0a9U!"b{,_L`I68i(na}YgBU /d˗/_#X !f2{11>#,P_^C^}xL[@n̙3g͚BмswΝ;mڴg}[16QF0 SWa9>i;N@ɨlRoɟ R u>6`٥-BTh1N8' fSNS]j1pj<,д`P#u 7kJ зo_kr^l'l"SuŅ^ROFKB&`O?]BH^_ ,N˖-iAx_O?t~oܙFv>.O>$8y;$e.A+!#,vװ`F͸wG8ɘ|=ѡ3QD?"B@Uv]6m7b7Pа2L|p_"׸Bfo>T҄3,@|0Lkt 5kd&/n݊]FDEH^Y[k8!0M,hLC <]ӻ5"ǡzHrC\/^3A FhJסjR {֙ Bjҷ18#ŋ߼ys !y!4N7oΏJnҽ/I9 +&bIp?"-qlޚh4F};b1ɷγrc !|S5>!-I))+VJq0: 8H.Pn Snm֭vHeo.]ԄfP{^1򂯃J^H^fa.ڝߥýC LZofl :[PKK*5\yz>ʕ+3^8yJ/&$/R5y2r ˆa.'A)c$u0a!,le`-\)fćAСCGlBBÖYůil2DO>dӍz/ăikӦ qt'"RLׯUqhDM#IR)yロfaQ T^<ܤӧOwߞH@ -GW^ !8/Dݻ1<bz]0g7udc%E8l,kpWSuxfذai^ĮS 7ɶmm3䅐Q ߟSu#7qh20x/0"13A)Мm۶'ND"uvԛps9l:(a_N:{뭷PBYBH^/}^e4"353fZgdF!Q,0)=`Qڒ"I'Uɝ֬Yqe0 CsN^ !A&MTJcp BȠHNG;rFwuڵYi NbSt&^pѧOİ@"R;E;  F@hC3r!Xr ݱcwFFx~ر"&{6&ɋH^؉ʓy8\8!mN00Gel P,Ό(hV_'n6ydfRjKnRСC1dxH^DEBXaϟߘ]c%KOdޏfF4xO/nbệ+VpoM :u`;N>K=y7g$! /\;UH^eZS7.be$ț7/?b6>^z 蝾:Çgݬ[8kHvOy ɀ%3"ёvvkiРA8[Kۇ44ظq#_3Ejg+ M,Yr뭷/l Ra7Tx\P\ P^k .y!y!D`|`/SL :nZP*Þ!m+>c(WÞwbpë!'&|@I"E p٣n"+aKo|rB`U?GQn!Dy*ΰsvڵ<3,([XKBUa2=_|EiX_>< "mM , t6İqXO!D|lxgi * Rpу! ?  n1'ުx(wyJ%/ľBKz.[!8[ wwٸ-Ayˏ^~7]tq|} /*(~{'3=BHa 6l۳'x"n"XD)'O8=nݺ1ɋX y! 1t'YZXq] ' <QW_};/N*W$/ľB0, xyE(]8[p .NzW*xt ]>`{(AE}AP\9t]\1BBH^8s?QdSJLA},ݧ-Kk׆AѢE?SJ^ !#vFXPq_AhEmkGj^DQ0 }'/J^ !a=(gmw5B |8x`]yMuVwBqƙh.CI s D]Tn"/_>Ԙ #myIwJ^ ZJZ)u I3B$On:uJsa7i*/T $/#8-F$k|4!D^[3QL -[Dz[Gܧj$/h,Xlذ!T!(50.{ ᎅKDkz]^ Sދ!y!jԩSB^4!$/ZP03aM2#i `"vsF /;$olwPwW4R@!]m-֤I?uYM5KPp$FH^ DF,Y0` #B"jS<|5PEDBH^p>*\d>cV^mŋ#A8FB" y!$/\dseNaÆ\H^)Pb+P?"yېӘࡅm۶0y$^sm!?,N)[q`GfEABj"er˗5k3҅䅺ؽ{w_pqUW!Aɋ܉䅐ꫯϟ>Vs$,H[T.-p1bݻщ_\Fl't͊}EBp_yQܹ36~!y!$/D5yq'LtLsZ"X`1Gʝ?+QTn~upLdCITfO24<_0TH[) oۘ<$^Y"w"y!$/6nȔ  ~߿SRo X~k5luxدC8WH} L4)TYf_|nے !BD `La׮]# ,Ѻر'B6ogpr}/7;l_:d&^w /y5klڴ#ؿ|Lo o'Oo+6m#ܶ%H^ He!_ s[vayEum}-{Z[2 m( CjFSL`W*D{o8wx}_Yxf>{>~g0) 'i{*++{; 3˄` 0(DVK9k֬V¥whчIGhD-̥w}/śoA~)^:uJŋox8-lQQ:D*j%vx<c w0s?qX&ny)RD` LƐxՄO6N0.ݹs2g̷ IpxXE/z=3Nl|3wSUPďv1xfeQo1 8^U?1:ll]y%K%: }Q"J^&I PV/8^?x q6WS`"Kjb) ^+#Ԝ l 0V4Ċ1b}!Vo'Y 1:Po"ε5ɍ̖Ps⏓|q?Zjc W83owishfcpaxU_<39[";Cף39۲yfs*cin BXǀzW(t3ꋦ׹g- /1; I?X垝Q4; G&Z̥ v<ĘD2 /VSdVl^2^.fjxcVn@H?OkRb&թZb `GB*9| ./p+Vo OӰ{}4A+,= O4h !NK0{x;ͻSDOP3I1oO1oM%I⽐ͮDYmd*UܹP|kmڜ+X/:Vxམʲ.ҝahY_0䞕嚳 6˩1Epsqzpqs2iǃűW 2ethL}<}la.C) L# c^ J_I^X}@ gu}GTբ[?lцdK=i6ּ}@tGg)I~1VH=:{bkCba6kTV4So ? /pB#~CQ{O媽W;'HqߙdO"Z M{l>A:]*W,yO)GڔWG%[H 6piLUTIr&I.[4®^ܧ^,zxÁkhzlef^yiC>x^+Ms3\ѼAS4 $B%,i(\Xřw\HBQ""ZQګ{y+Kko@ɼbmOGWڕw[V,ę1FD0jS>>7E؆ R K|BtBkL&۫Y|D:J!r ]R[d[8*Ѵ0VFj<.\8^$ /f U2x a&56YҦvBWPPL*^~3;uV?L3fhmCWY30xdvX8̺^D1C:YZSaELϋ40taHW%"XE9Dv5]~_yrnG=*Z_͙k3vL6@΍_GKbmMqr3I) 5_^'L?D&M[yEN69\ ҏ+lI %VI 0^Ù q/p½ / ?SIL{F~]gM,؀| nkedcRbP龦񤙫t4$׿vn|_ݾg hCދ8XuQj܂LgLz͟6+=@^T8>wt4Vg/ʍ!ep`2tAܟW`dyH֖ t[J7+}tk۞7LxiiN%+ q7J͈pȯ93?l5߸KCWF.7VPP8 B-{"86{wb]gЈTP1l/8^prwϽㆃ#$ O\!|b^D9Y9zI!B4Eo=pkh&7Yf*Չ "Iٞ.jLkkRqwH" (pOI/L^_йc bL/~}ܚK?kpɥܬ%վԣ (7*$Ǔ!2?ُ}}]}}J]i&gPս S*Uk;bw-ރ4QyrRyi"U2}@20x{`V5֦KV]bN ,2‚g. <8.wGYz,؄t݇:OǧY&$DQ.Ȉ~bMm=tZ~poqF\%Tm[v ov3'/.\b|E[ŋL{Fz̢)ESH/Ԥ;u?4CI&TGWگYk^` z~e^9wcw1NsF_̹J8#ͧ/^h/<#xJ]mEzu&V$❶&[YR%ϑ.W|/KVTo,G!RZ80GE]xH[ $(\HDOx [)+ ֘7xN Px}{+k#&Wl +BNj Ap$m *ϸKSͻ46d𕿼:B_qs8²C+zW"C EGET/P"CUMsvX0o]Ck5Sc/o] 䆧/{UEWVwudsTӖ;4/d9ۅڱse,TqBgoYLA}+'[*0M78zѬSPVq |t*-IcWX^MV9_Di竕8w_)( v w(> ydp[O:noK;sRR1&7zUs}ʵ!/tm"r!oFսkX~l|pe? _6]dӄr\-IO'I/ E^&-*\Q.Do(f[uPV^'M$xA#]a(}>V5^p 8`{1&— bP9E9t(ܸ4_\dޞ,LHw~A[w8U4O^`7M\k}q]xHAH%%q"F -}A.fxm`Y΅{EF.瘞}$>b9KX.Xrb]d+Hu%Z6ˍRA髧z1ZFK"麮dI/~ -[Ru:^ermtTfƒ"/^xeK 5f{b%RQnNV] {wX.u߀Ct*}Q[QkOQd7-_"_zDޚ,m=txHBX8LK-1 xU;B DFp \Hw'_κVO[W=v":<, }ڹ|ݴdϟj]y\/l!3>}]̋ wAp[vWhս*QQ-5szw\PwbNSRmH鹪}\~SNwh$wepz M(IPW" \Q>lfs5 9u #8/Βוęk^!8H"}l/JQt!w %) (6E^DQ+Nl1ͺ@dx,[Dup. Rἧž!,'Y 7:cV.R\?ËLy4CWTznuj;T ގ7+N_'o#d{, &_/>8xg =*IbekA"ΗXJgy3kx!rʉ+4vcb k%kȥ(׳ֲKhs _:ZKsF՝d?Nl  іO.=b~k*Qb2kɁiΚèɘ"U>  P~}mi[ݧKQ'+GFK ( -tGdSSW6ޫ.% \9|.F*w{¹\˞yqܴ5deLO} L.Y6Gg/=ukx/0՞?5Bu`xldk\yZ;lhcޱ\x#%ۋda+/t֏pfhG{V%WKoV-Қ+w~ZPxIx ./Tg@YnG#R 5P%j)!ozTTًXkhv|pQ!o^= sN3eT,CͮEP%*'Nj'nud6g'[~)^Z4" 쩾pzF~A@lhQy\[*M];n[ ^t46hysO^qS@kդˎpxM2N\mcu/lyS /hmS,9tU菱vR+%I{.LWVɯJe їnogIVxyP W-X,Xzt?c ./p`X TR}r6t>Zڇ +D[ee'\'za!0p;UT>]$$YY+w|G0ѻU In5V'WIW,*1Wb5Ѣw6dPo*maʌ=Xj#>Dŀl/*k"=%kVZ.nK B78|r -*RE hnha 6cHT|z5uHiW䎵𻦤;Vq^mzW etwF;vWs7/>Rl f9f8u'{*_^`2vjv="Q`I<9xI6M M޻zr0eum{5?6-[ *\%a~pPU(8 ./ uR `bBN-l<p4qʍ%+7J|}>~ a!tm릺ޅ=IV=#0Vd?j۝jܖ&~JI1lku /в1 U,dKgˏBNstSaasDF EI41?Vt S1Ẑ$i+ސa)E\uDW.N6Y O6JŅ*||Ӟ'6Nѿ@nH$?Ql_㱼a|{si-{ދ&@ i'Rpt6_UP8Ig ./p2p/FZ+p %a)x)eu lJ cHĕ+Ҁ=RdNk!eţER;w6/B-1Lf QcoYPrcT퇫/b:#Y\99[p2c3{u@o¹x5g]2к-9st^;茔 pdX,נ z&m\$Rb 4^ *E9^px 9jx, lPMAJmP0UH V?^H4"v,nc/ ZĤojoFD&]' 60CўQ=MC1 +B 3p:* = '9\n, (o}165մyp641EP{N^=L>#XZqEυe%dG dRry4DY: psp72^=G?^pxa ( (^BH{c[Ey0A52]j#Jd# ^nÊv6>UF.r/Ӌht1ePtX.WS/^nTD(lFe>⥨ lE8Ncj' ./p:i tLVO1*`H{"JCaeI fز44>M s⅋DFba0P-P2*!p.:X 4R;&T_(cہEuW I0@'eU#bWxlg)/:#3X?<8`J'j 3`"#ी[a5.C'P^a-ު-n((m(aDd *#ځLJ1~ ١OU4}p؊$6q#8Kr4^eh/8^prx/ ̴^$/xcf7hbBaB(pL# Hp ؏U1cxno /x#]_@^= /x+AUs) 1b#3Gl~2P#lL ./Qxzi#1-fH^0"PgpO60*Q3(Ǩ ŋ@J2[02)Up팗F{/T/S`Ë''3Un/ z/zƁ$cGv0&XI/pWj`H]a Mf0F"^2Ō '^ ,}kp4/htcTΙ^XT A94Ob ̽*KQN׀f PʑȺ` .\ЌzqJF)aC3 c)'p%p%?`/8bWr. 7e^!^ |&LsËD5fch|]#}I ^`CTEFvU N$`U`o4h6ɞx̌+ ./ËgW\5X!~];d>bc"t{yĊxA̿Z碅z8T  MHWGBR\}":;>BPǀ1=@G 5% ag hE8sW -I(kd~*}jiL ?xK"+'gHK!_yA&4ƋXLAGQQx {D \8^px!s駞xb2N zn]'VDsܪ J`~oT0 L*hhQggH/=QV5B<YPn+Yy2B&M$%O7+I&XZ/oS)I j#^ؚR H5O=A+TcTB '8;Vф-NQcd܄B0CCAH 0]]]r7Uz) .9+Ҥ"Ӫ{۩B$pPB 8`dx~ Hkr9:m.WU#(FVEe${9kx̙W⋳9x ./ËsXא{#KoΗvrObvh\4]in$,V(imLz7<2L8q_; lҰbib@,m~y3| ιF!jRK;xzbB(?aj1p惬y\eKE?C4 ߝLD2/`PMxK_<&yͦua] OA8~`Rd.;'/_)1f8`o3N[٘x)aMn\g#+C&OO'O aN/8^pxc,8-2$ev? 33 03L1dƉQ`]m[؞Yժ4cS#8khn-ͯ ڐ:Wxz^aWL|FǢgJ 7(yb{(/8smَA"LPhaϟOK܉tp:u;~T)+]٭w}ݻ;ѣn۶05FۘʐJz{v~=wB*ɢ={ճ9S^؛SJKI{=_0TXԿoniapA))塲={է{t/&wWo޼$x3Ny2Aо*۫sw P/)..zY=n"p=#AԪ<j4~V09= /^N@IXD"V~s,>bLY!e4hXYiYIiIY)!d0οA%|{.+܉2w?,L͑2:8 򲁥%ϔ ,))5zWڳgWsT"&`&h^ y…'>|py3Z>l\Z^^>x0%Jm2t`8)-H ?g ;X22ɓ'O0aر`!7G=qD@8"GdapL8k nܸ),`,SYc?ΊPp-*Nb:dTnIcǼo9{=eÆN4X4sy+V ab^xz/'^dM#BөG_qTv k֬ZVU\SeU*W_`O|StQ'*r[K͵et1E˳|劋.XcO;Kˠ /Zt ],)<'^|f^xzIceCﯭW[_ǚǺ QB~6Ib^X|̙3Gw3Ψ$wAΩ=:7j71.B֋)F?T_wp]uUɂ*Iʡ4#go/1e淼-]Of7mu55UH4ԴHA(wСjY"tUihj-Jv{5ֵ瞔ZG k \a32~"_S[n̉R]BB:\9"MКiEo8 ‹^7GD,2^)hnl@&'R͉x9;xg%c5CS=;b\p!5Aַڱ4!-[FKZҩ$~4〬[3kZU^ HUI!cGmM D)h#tR-Pri;dSK3; }aQg,4tcs´v U U&F A[U6NB@GJG+GjKZxUdMvg\4` kWQګ5c܃Js uzHÁdR酧^xr*$k'[?2q\rndx[8j< 8oD1jt,E<9t,L`qq$U <#I Q&*D3(]kpRo{6;;ZFKbr`Ԋ9)[ݼiiuT?,[{nthN?ޏLrmν=PD=7v O/<‹@/fsbx\+ )vo_XpɠTs,XkpFC11@J*;z4N>|zP~C$cJ!lz 2t"D5հYt]UtUݚPK-/ӫEgY|տtahs"!'^xz /^!S0j(b=dP`JuXG2 QrV}׽{w Cw:c\DfY 2ځtP5L/J ۶l? U , 3S\ u] I|[ֶ*A fW..1mgլ;vmuwf#kr4xz酧^dza~^fU?PrZӸ<|hO^ܵ 08ɧbű٦͐FB]a;L/$֚V V'@/.E˖,e-F/LBw͜sЋ<9+Guhs^>v.ZxӖ{kkX9fmܶ͡#~ȉ^@^P;_~~S P^xy /^!h(ku\& o:l2jmD$4GcO4&.frf#2Uv{%͛G5 D5-p6^"2薅v1Աs( N zF2vmp Ћ/dtBU *"R˕}xGÇYg|#1녧^<?z#8us/"UPC0w]hȹA"eas[LqCRG>7+|LjCِlP.fc3@D}"Zrcɉ !Ghũ< KC->-"GM|Ȑ!fbO ?9 /^Z5}Nb1 pEz_@0'),}dWa" !`-׾\4 N5"e.E,fSx: oxäI8|ncT!zc*nYJnr%/r ea#/֨zzO/xzώ{ҜĆ{Lмy*yX3 0\j!%2ɶi$B\bz oڋ|;겡CΡd-V0bakK, *oQ$*Xs nDi\@,U` X,"$iT Fé)18KtjakA :(L%LM d|m̘1|fȑ|r!`>SO=‚Ӈz|~a׮M4on׿'ag>BؘJ1ykQ<!`& DT 1;GEgh>^F2; !UY$! @8!" Y| uȁm H ('A1g/ ui<|9#kwƸVL>=3 O< FK(~#U`@-rwznsuf >~oM ~_g?/~! ]4w]ͷꪫJ<ʤY܈!v85*ӯ?O 駟DvD˃`p'/lërW3eY'reЪc-Оc,;ZfQ$6A\Ӌ^^ht'71"eeec:.rK3pJ{w3To7 C~`Kӟ !6<\sp"GxS3~{à ^]{>YXAoUY2 6̶}Z+?* \C5.f$p_/^RJ_?3, 1:Iр B9@åR?Uުկe(DQvFd!Gh[RlF)PSThrTU(]v/wn;w,5THlKD%$@uMY#zaD܎M0r`rUF7~p}O" B應bʕLw,jﯽZX f@k0K =]„`" iU.vI-;Vf`uaa G8)yVX(vt Uoɚ3fnMe*L]fO/ + |kv6ܕ0Ń[,W5X/\Z7@ oFL kcl fݰa`>!,`*̀@^pTY3|q.'UD c0b1CHLA(O<$P]OrLjmؐhn\t$@ D8<sm '%fy8 Ks:W!5N)'@K.4VUUAl}F2Xxl }{ =ɑ"Q;*V "8ĥxdDԎw3JL,㡡pBI4K.ĢxeGgoh"jsgas6bQCxzUK/mі=z`Eqq1@5`g`exoy!])0|3 ->`FK)}NM0"cgg8JH{ ~0OB GHGW>JI￟k044SM l:Ԕb3‚*'U<)`ψQB4V* p]%hLLn9 Gp##?IZgX-@(,$$ᅠ-; :-CEQEѱ~Tx GD* 0CKqA .e(3Nʔ"]AY0$LqAxN 5f%PN:rBI?XjMItи;"uҤ 0tEcȎǀt=aପ%3]29B4^< _N32"^{xc` rCЂVjLCp P|eM!Ҕ?[#<%69Ym.~`*zYg5BH٭MqŖ NSm4T㍟+c.IA#kHLBDbђ\@ 7!טBV\!.ȎP*2 I4#E)\(`@/(9;)x@&AЗ " t=X߿?ؖh[Rt+xhRRk/TvE%.%"߄FF+PZMBDI&!ך0`&= ‹J;Gl]kE@5 `leLd1BvnB,@CP/ -H LF7_mJ4[0l(e/Ȏ@zx 1c>9mUp_dmB[3ŅVLC\" ht2SAH ?]\Z z4%BD4q`T(SY*9?Iv]!|%BDtDDH]hb =v?' '_5WHktWD+ x/ }D-=~!e ڕ_N^JJJI@>NO/xzUK/x M1co /* @L<Bx A%CЈ`:vdƈQRQ,"}6 "h'<IY>\Bh+هZ5%y- e(BT,HQBJBwoD-S]%Zk)(˜ X =f;wf LIGiXY{ns}~< l7%U7#7Xh;գUc_op`Sx胋."5J%0:b_HP lHjM01‰a UIB ]}2fiZW:.z,c=oXD|dFYr}:\I]88;op3sj1Ūve(Pwy͔ l(=NoFes[kd0kx"]^@:)k^x‹IgGk  Aq^WPŊtp{Ι5+k׮GHSDK-M؊pe*>JrPMo.uhiǻ䒴 K#ˇ_̙UY9dԼ׍;nْ[6m>wz*G gS+2j讧^x'K$dF(TahY=ʓδcBeʊe+MwSa~х翮f?9P)$s24O<` @_g%A/PxQ-~B,h1|K¡ 7މT5~WT$^M1yzC<oȗB/M1 pTe>q`˖m ,4Χ-:w*|;p0x"Յ8ck9>3G?޽s:!'-fnnl;Ur 0v$Pǚh Vش$XQ#-^xz /^dZzO822ɦ]{voٶ(Oxh_gĶ"E"-/-w5#q/_7=F_,cQp aezeu{=1Mai} QcsSe_XӿYKvӾu" ;=na]=_77wsJ~~G7k>͹VgN˿~g`jyxha<yF\/c3z$`%U".G3/>cK~8KbϺ+I -*xqS#HX, {:O'<[׋W ՒV/WUEmaml3&ŗ ʊZݦKÏ4qXg<' ̆4WT(qaPC6˼55ZU[ Ail6^Fy "$eq"t:7 oo.\ PDV&)x<ǁQxu$>11AoBW% , <1Z+ yVѺ^0uԍ:QE5e"./qp bH3TnM ,ԘàY60H9d$[1H_q#)+`"d:ٔ{7Hȃ6kÛ& ȦW6kp_6!7gkmʄ_ΆHIeR w|FFnVH ^( p. ^$~%VPG0݈DC'?+ g)l^B 'Xb'w[Vʘ)cP >NdIhn،iٱa$9Mf,,4:-+/u4ЍtX 8<'\bbܬ+P9!1{"}_ CK[ŵ'/c?asO,v.AdlV#{L\&1BLsXTfZaI`F$I$IvIHX!$Ym6J"Rrbaβi35RH4,t֒ҐbF, nq Cgn.sdEv=mi&acͯ>: /Hshʓ#t__g q<+ 'Q' ^(x8y?8*м[7"/ @*pI?L_o\z׫~Rp6~0u%vdDrk`R~;=<9'--ot&nxIx" VaʎYZ@MxsaMLȤ3FA?2_J.H +װt! JnELt-ܔcCQs5 by&]E*1mslz$a . q dCTz%!#L%aOT%>SZ~+x,E%/yLR'AK/UIUBI+e(rgCã>bja6;G2G< ΄ Q$!cb'[?z QiB:&N! *+P.r "#&#H)UE(Ʋ7ӻǂǟO M$n7ىx^H:D@˾3@9G|L/4 b /4rH*gx9x+wNxVK|4 T$#ݩi[d[ܼ4]3~Z* XL et^.)9{ٹrħuuumZq L %)xE}EpԱltn&<=05fWעÓ33ѹuυO_'(A 3ף3 WQThr:|m:2=tʱ~"?) _NOF&~ ߸ NGõ&Ggb4ZޟSq/u ^؂wkH1G8,ʲ)md QlJR} xa[+Fm@v~=v][8r%֤b-FhG`$1b$Dw'Cfa3ϞA<lٚYJ<vw8,Ů^(I %!,/ }{׿## _^ };7|q|ȅq5G/}46zi|މ@ȮO{?_kKq×F/1)[g΍ ^pp?jΌN   @3MߘaS/e̥+:O;BbxAl{@hMf_B $ ˪)^VQp%0J7nmB|4!r&fAՐ_Hp)62U麢&b|D{w/**;g''آ)K?S?؜AFyy9ԂW %)xE//rwޞC;}ݽ]]GÀojܽ:K]n 56F|#ucmuM m퍁@kp/V78!;:l^Ar)춵ڽ #jB@oWl:Mξw_w}yH2C>:go]~9"E(a /N_ |3^$/;${42`{qb/, d%񂔈)fVn&J͘BQn[< 1TIxAlaZTB7u@8p ,ᅂt*EG@0Ǟ={.^C/PBI ^(ubzwd _NL|zjЎͯ5}{TZ͇E!~26׺ve z6E_^$RHw\lC¢H5坳:K3}^X!mkhXW9b4L6XNP'1eʱ>Bn5 %H {xiq$EM $|KW|0W-"1Bg.:طcg9w{ Dnҹ^zhu7;w4vyXx۾)u>[Auuoӎƶ탢@[,L#ƺڎ~sshi}EZ~~ްzsDx \o;{;<kSݸ{[V}?%]eW-D1- /p@x[^@sTABxM@MАx KVd~ȣxb|"dD xG!=C=bGN0(%?hX1Z!j s$^ux{ 卩.‹wy?_ؾǏ??plc=ࢺ|fQHPDl({QP`zg{TT{FĞEA@:7̙} gzֳ]~٫ޣ~j/n9{kNY8Zȋ=z]D|?_-gx q1aQ7*/(; >P9;%<)*$!,41< :8&;dISE}%ݥKV|xdUO_PlhP|XpB8+7(|A.޷4tlmcFCԩQTMr/9[B /V^/ĢS;鍠3h`_xȘ@߿ejt_ 9@?s~ AkvMx1GB&PF2g+9KWH'p /J?\P^S`k5yoC -S /_ /] iٻ7?~gHz6-O|jrgKI&S'O65oRD E5=% na7~Ęד뎥 ,f)a=^E%Kkɓ'O:nI.6veo:YP\=wݱmGϏo %dF =+de)Kŧx{'K4sJCk֬ U9#(ŋ^M۴BAim~ȹs^twIl`G6{R '8&bjee4|x__WnݵWdΞkSQ6BO^9t{݅;3q4I8m̭ǙΞangc9ڂ⭙%[ 3728r$ksW73iuL~y:f&іRz mjo] Pf6-ж]9#m/{o߁'im{@/Z.Ѯ%;mܓ7oꛏ56kbd<ά&j_梚y[.+.ɬؓ|{Z|Bhq&cMꍜS, ;{ailmelxĨiQ}bp$,*mb"x !aa-qB^-G BR<"e@~@(R‚s/F|駟g~ g(FKߐW)au{Od}I:;N-V썛>cE 6Kv? "?|cG}g|<_}Hpƒu9`Sg2.~ ?`kbn>ۧ{nIa8qnDgvM?:p!'L*J>84ԥy+ɅɑKOn=~\p eIX!x$p yuu[Ia}ݴyyb%ϥRA~Rz|p@Y&] / z/MѣIP B{{0Պwy=z:ދm !K55[wKn^-|5r$Oޚsm(ߟ%ZW;~[ooo}6U[ cRm?~wȯpt_Y,[qxWw|?- \Ts(qO;qJ|띷w^R[~kvaaX(^,,x5T)iBn+6>YMM&.浟iR veW C`h NX&  { ѽdTJ ``d(T́E \a+2^ .ǵ aB.. ƴLƘ`8 BւêL7PO&NX7 2Z,xtcBrDyaX#+DPΔK-\ISAH? hF̏ٶG'sx ?IE 4?K)\ @"GU؝X )O NQWW70D [J@(H'_x1,2Be7bXIZ.Dͺ%S3FMLJ~}v]`=iᅖ s{Бʪ{;w7570܋s|ref*I]6~~E@)N3{;LwO[ZPP2VIc7,ݔ5kK 'i[s7'-K_<)gMj,7[ɞ֎v1dtG'di)S;L 5nf9~܄&xzf\``<:HW'(b\0'I,%TB3y "GAvP7)Xth-# اjj?/u E)?Q̍ ¸겸JI(8$`Q b%8 I)Isp+d``HB$`1;2a8eH7n" ܀N\$0Ҥ,Pa `@ )AbNTE<_}wO <|~\js *K+Ř0^]0+8ѕtIiaKr!eSYƍ "9dɺe%D9;\ʏeڟ< >sD *>rB-BQ.⸊yavs8׼jA9jy*C|22GKaiiyaދT.ܹM!_۴BTߟ[rǏ;|sW\ٛu l$i 7{b,͔d6r/+Qd(*ڸ$L eȨIp<,E_^t7VS$ SJC##ƒ! E59 秉C|l"fnan98XwlUSl\w^Y>SçMcnnQAcBM LJw=~Q 7:SOJt`a2ֶ!, kgO.ᥭPʙܹyB(sUݝl(S|Wu^ܷckm>'LՃC=P = [  ~8[?FTgV2k@f&lN[y\$p0ߟwLvzx_:U*%2^UƏrAn9\wmscoM6p ||5e]/.ȫ+?~㕰Uگ^~wd(fo-p =Q۰{oJB^S/Ԋ'pHwI5UPXl(jر hP'>C~ UPhU5b(g0bX0x9 5S̙-X A yGB4'[n/ #ؚ^^G'=o Nmw[Tc%%/JȌ'%Te#gH%+22V,9,O,ړ+'* 7 36yqY(/A/?O Jp''Nl`k4qVzc MŒLJI2sY 6:FL9{|?]]=?}?YO(8[(?^wwtqqRZ~+/SԒ<ǂ?C*Ys`Q3kv㌴LVCa7$G/"dm0Nb8_bL2~(xOQ@\KfpX끻ՂJ~EօNB|ˑ*EuZ^nՂ>b1mKAˁnZq=7:{dͪTYg5/\ri |J^zNt>v}8ݴu.arrcUC܇ GsۣVRLY@.!.[*h,ɼו^8r}ppx1\\Ͱcy/xN8$jfif)F{QXALLbw/4kE^87*Ƌf]pM>&9k 8t"Y04% EòW/*X\-/<ؾϲIl4}Uٶ [L3^IAx zzz&&flsff88c0 "&k'X훮p W/H&Hcx1ܵKVd(r+7biҠв貘HI ik\zq9{uO=!FP]B7(Nv=0x^n~8>uȞ99mE&8n9{k(_]^>|7PLĥO?{U7 {xGF؛׵0"5:͖I(0( wx1X3$Br+ȓùœ55)MI.*j 0[aBx:ZV7lQ7ߪװ~Cm9{@\ŏhkoaQ) y%/3|w\]p}%r)D;w0`=>fY;) qƇ}~D.h-OC(.~;ܺ41? k~캐W}j{[NL 7z: _K==X.ݰ)w)E ~>l'x]s "*fҔictLJ;:rE K ̣&9d16K /KWL<-0#KV岋Œ8$C6S^20 TvL0Mw[P%pV\W\"3n#9< v4Gd(~^d= ['ۻ}9X0C H'zUV(-LA1M  1 wUa;>"7 r 0/\{~R rAع[Ph"7jBŸn؍do*nwo'P<lS?W*=8Υ-ߵkF`+nQNg}$vwJ.K fh{DRxT ORZ% ö7Ddi q˲R1'g:^q{2{r  5#<^Sz;p# ڭ9QpDIPUcAϸ3@&ƎM /dh=rx_jr)V6ż4ƘH K%MEs셛 {ĔFH= % جr,Dg̱77Z:1eV-7jlW?dDgeۛZ:͚0!.m"fac [a9cR 5Ltz //>Ɍ W%/4|~R;iHMEׄBL4be`=: Pls/vڟ:淼"qeT$@w!J!ڴo ƻ0LzU*m#o*ĉOZ0`(51ֻuDCSG(HZl(48DpQWGBVX_dCc;r#ڵ$য հd|w] ぞf.Bwi[_ ڹsS?R[\=~y1bp;B ۚݤYrydPJE[Ver.bJgRgZYLl?)fyаv]Bgg˂eYM`:6,l}_cdAV ECv{7{jCƒa4dCVK^"i)J; nw?A(5rD7ġ"O3?nݰxގ3PvdQXYU|ߎTUU$ZHVfV %=Bp YNsrh$ɴ; ep]4DV[V_)B%?@ʎڽ1.]VJ2J}ߟ:E*)@;lg}-V_€RAÎ'jٻuKԖ@t_S°(| ( 96o0mʄbO'uǮZ\@EͲd$Zx1߀xAow֭_MpՔs92 &4ui-‹E‹~JS߻w9N3${utL) .u -O+ 3̯Jr Ҡ0n<IVӍtLGWE gY`s. d}WY\SY͔#,mmS}lW}~HQ#L3挏&ap/f:ןU\Zr' %T* :bB_ "īVZz5gӼiӦZdؙ3_!8GTsp$,(k[c JKAL| n(D:V;^QAsW1狳;$\x}R~أ#_6T4ɝ3Cxarib2c%咴g/qWP"(+W4W9M0iJ@JJ^Z\#9 XC/Ktեu N(1v=[m Ic^c"nk7ȏڊ^HZ'x+cJS}y渹8yJ" , JBya,1KwsٓL GO011koo[{~#?е. 9+mYɩV)SGi3z/&tחFGO0 M x1G da谌2\ӗd1__5|_;;[G^hp/d-Y/觴ؗ*IlTƄzx{m!oO'o/DQ\E$MR}|M$Ll~m;߸|;[բD*;ZǓۻPR*yD1/-gϫՂxA+ɤGat4s tljYPY{f"5kM:%#Wj c9u 7b2Ek0 9N(߾5hJRCئj4'wbeJRxo'kڊ;:-Q[PwԯGKtksuFN /??lpE(@H)iT{jj]hP+~{x|p9-@:&mZxmת#Dݻ;53oĈOPuF5<:#gkBTef'rVlD*eϞ)svs37jb:c x20 uv4iab0rNDPfдmm3& /M 40ؙ LY_F$9x :+7ԩvMMmmT#I~8߂96Ba`z|ŀN[70'+ 0||'>:c$DlCZ0o (JAl?3ɽ;CWHъ\ T<#LQWT-ab  )qZ**eKH{LBz$5_:֚7X54yѼjn}C?E!FҦ+?v۶m= {T2Q0^*~͓G 흘 %?7߽{+'u+ʹ \EEc)JRĝ)FpdݻVtرTks1  °f~hpm޼9ro md'#}޵o.Ohqisx8%-NL;8;z- d{8ZEO7eejj! Q 8eB"𸁈 iQ9])ɱ2.JyEr&'K əm#ʅID8wÚJEZ( )A Vm$BB\drA@#&b5[ȸ`!'NM(UB*J'DDp:ՋDQ("H'"JI3k6 ׮} c'*EyJQJ'f I}8TƗQfT?8PW'nh"p)ݻxs k5W5X= j B [[@Sb -жuY&t4w\öceǚWkm\}b{ $,ZD͞!J8%&~Ƅ8,#'[@(tiTh776 4 d6,,|Ei5rJͦeW,= Y 晆Z@S2~38`63Ǧp&al>5cyկ P;K/>gϞ=Ѿhx{i1 oQիwjiyU*.B72G[*@(ioW(L.JAba0?LzBQ !Ƀ? O"bKER?Q#.p@Ta7ΠC, RX.1?7]USCHb:Pْ`!~\"!: 1 ۩8 tJԫZP)2$ a*6$@RU.|@1hVrKTy-&a,}۷õ2QOHn'' 82|JR։"؄@nQ< I$Vv+:":M$z/6w\MnK>|&~5;5]Csa?8$$dƍW&PzڦnTS/O;ąͮ;kַǯI'qU3}"]2f;eΚ:gr꜉qӦ$O@ަ:MNs26}M̉ixk:>y]2ONe 6r]¥@q3[z7#oizG=zi8o1mxxŘ==]T7jࠂ /p"Eyl*/#2fF}DƞdmSZt"nB-WBD#F-.!b(_ /^^`E,OǷvcqG 'a)ErrSs H5τ)BfI`>ĭB58$r֤r'@ y8rg7a :Rde\w+\ (F [}q_ Vp<@9dQ5DHk鑶3&p'W PI2G!De:_zݺ^nu2M#DlJ\G@Dp~߀jNtc 9@ ,R ;`6}Ya+>p$0Dƫo/.s*_eWkke*D޹nQ_?6F# 2 ob:6 pb"Fܸ S#?c3@s #&zz&*pwS\@ H%.q\͌ ~m"f3" /B͙}HT tTLu(8#5O*2m@3 {trkr%|n$hh [5 qBP #A *@%5% (,,,//_f 8Ax"AH}XcjYZxie/FGO>}-{̀-RfwL?2]%3#GX;h^Gל'%,әsO fYD\/zMKg3 " օA)qSXs@10 3LڇyTAOD{h_`';?zVT"H*HÀ# jKڟAi'5P =и6p'Ah=x1^Gc6]_!cWQXKֿjJ5L> +Ggƿ^jo$t uQ_OSJA1KAW?R]IP# b*%G K.^ډ#^h<2lBO $(P*(| tQQ;x,@M4 u[/mZx=tmkPd~רOc=9^%d7YS'G9e̥Q C ['㰍:)6hqDM6"4 IoT;1c[̛in=般 QS}L-cå"v2j½)nKg]̚:ӭRgNLw. } P^jkIuw;4zcH}H[@[Z\< >- (n]]3?a`r^Gǘud:2#xiαEo 8XqXnƇ(oZL?_جڻLBeY a#+ V;2”S|Q ߻mȲWde3&FN?k9Zy񯉁щ/^]W@,Td j-= d@" DrȮalg!@OMfam0 X BJ9Ov g_LL1qÄN 6@>%$@f င<bC3FLI/Ps '@>6g4*OvʮlN3Aa2Rg %$}BrZ:BEAk?LS :&#vEK֌)P>̄E1%H0MтWw>{264eNt%~ d!:爋@Bqw !SD?z Hb7'pҋ1<(wzVIg{:FZou[;{Y/G gx1C"(ҏ?{($ekIcv*[ô;XHݻ0Hƺ#krK)釖v/z?"=9~'jT41v\PUxzFch}܆-4(60Yǵ˅5 N&j)x2.IҢ,jI+331&R*OL/PVST lH_}t=ԮSB 3Qa ()F ,r  ? A2E2[G@Hxb&_` l#qB$N&E\YT$ȒX|-HaLYB!sd$h=o Fi EEjA4O,Obb5O]~xx~E}knv=a#3K/HF (vB> QUi|*322HA@NS*z{B.N(Y N@ ,ٜ?Fa{wsO645NKBɁ U}ٽ+]a0D)Ut&T_E˿y\;3o{}k?PH|zVCyR"@gh ]B0p:ldu#  =%/$Y"3$׿Ao,ASTx#5 G:ȅٙ ڦ=29kjIhdxP7l?E_=~SCT9ǎ=cAppl44<ab8fbxz*c&&gf/n/ Bw,/goj(ɥ 3FÑXGlC[]Ss]c}ݹKùzF]&D7754547k:\SjϞ;sƺ3 ukkU57V4UuVT8[W-Zْfs9ڋ;[]e-eͥe- eMkO՟g@C-Wmӹ:|suO(Άs @Zp?AcmSSc{S͋[}cS#76 Zà}J"!˿DwSп5܁>(,8--7LS-l~ [N^HHlm$;ʣSͨ,i#Jn#~7%y[0S,@@QϛnT?,@meb,rooLlnl޼v}~vvzppXa={;wz0G==P_w'錇ZvVy;ʽO{{: #Ӟjs$RF;<^W 5pux\5o]4uu!4{}} ~x7~*x==ATuc==ݽqIo4674??w>g`kW׮nb} #+N,yA駟|2BTo[0l|~ :ɪי%2Pg~g ,UH QV|;J@UoeH%' !) J~63ϫcU Tjeiy||'8c@y Z~,9&o #MPQ# }Ljcm*nn\y+/,.\^_x cb,,\QB+sWf/O/^\87=81w@WE*t\H~Wq~v^}t`-&v1܎<~wY.{'F{f&&,^00?pin W^^2xi~av~~Ne^u\z՛W_[^0  'yB2//q70$/L AlcmR#YTTUD)ODZh |/yy ,/8sqIyV! i"!۔c P"-I%(746=5o{[1wKz[~A5#ykIa3%ƍRj!\sELK[;`3ۦ!Z^`|Lذ=<eA_i[ "A@FoGA auaN`vԌW4 8 |4/+@_T|xw{v&|clkc~c2j[; fs໮Hn%RɝT2K1LD'>CD@L׋|6̱߮'tATM ?4;q8(ko^ߋ {`y)!Joa  deP$܆4яcoPX;Sը\|ݜ6(IB D`.yLD ,/hPrDɋ ܒ dE}tנ7I@{2f5Ûa$0w.njH2+y9^[SwB+*P@":ha<{>΀U`" ЙAAdWۆ.fnLw1{^z[ާ7ǕE\ KHcM9J^(c\Z lOOADJN0"ȗ[eRtzڬ䓯JIIٳg!)~?NRAV04'z}@c?WWH1Q :&;5[pja7Ԍa`ȬO\+%HIj{܍+CX\SUGՐ!oYJb1; R;*A>Qa3+oAR#:_SxR2n#8?Y3v((X$1g5KGhx%kA*%_% Jm?b-`~*E Ї>T\\ sH#)gU?P=0CM6,P&PX bpp__wz*kkjW,0W *d`f'<ATlR<r(4]mp?Oij P4MÝ+SVLpRo,ROk3ׯ;s8@bE$P XeBL~MIP@*!8f=bTŊwUxRh*á˩:k@EKӽ̔eH@JURêu_ TFXօV?]OCy,'_5_%-P$v B[PyC=p' ĢcG=n^U-fyOl0vN,#Xldi3%wUA'pSŬ%"1U(Yc`'Uq6x Ba}5 HQIrBBKs؆P{7 u  # Wzeu ٟRT@)iwQ@!ƒb?@t?3f-=>ڿ?5&B/8? .zaNWܑغ40s~t(mB30J!E8A!(2;mhJ|t ~;  "jD!u[ OISJLEQx3 o<ڽyc wݙ"5jN)Tqh7ˏk*bN 0磚ka?s@ '4= +,/`6ldn˾h4o?nցYǧ5oI>vs Ђ1(IFbukͫSӓmG%{ayr8!)JAwqtyӅ]8obAI^X yaM! CU ’y VЛq z׳|}zkmQ"a'y*!a}5#-ڽY&<NBtyjK//҂Pk$΢TM%t=;%3m߆F,,/xA `Egt4PQΔ;4ldؑMpZώ͝KGgc]z\'PJR.AE-?gRF1o.fuNadҬA¡8,,B(9utR~IWk }Qur` 7J_ >*Пyt g 2SW/+JgtJj .M5;E8qaSSI٧\/ˋ#EVe6ˆUEUfJ#+zaShȠ 3Uj||˿+KO=;;^}U 8A(+aP>99?pM"B-ȥ,/x^.bCp\$?.)O<>SIF NoRkW]0쎶C(W Ar9jSN+RPhyx)gD=3 )/kyA-BR@#f$;HS*\ 0 ,)qE{:諍G6S}W&7C~oOs>c8%[,f d@z:ى3 \ q!g'Hm[c|W};?c87Ui|'6{ùzLL@R\_qc T) 2s院Nna´,/I=(yq{qϴ>{r4oljyBY/x[L7jg~㧪J<ต3SZ1lT`[$Kf%#`cF:>0Ҡ{-g !/)l}lyb{_~?g~{??폿ػߪ*Kܝ-Cg^YXYZbgkSVVH|sM9~L}5y }/k*ZxRL쭭nMM^gO4[?{˱ۿ;߮xF"~" w,=(cƭo"Wx8 )-zi{w35vJ֎L4psbˣ+Wrjʺh=S0kL'/ mcXÃQ,2rȼP9xj5oGO`AN=nGI51OXO,qc΂^rTlY$y(~T%6}~i*玓@5򆼰!mGB|(q;OzGE/۞ʜ/؟l;nqڏZNvm!Z9;D sv]\[Aɸ+*|w9(sZpr@ wEƒ#3rPI;@FgTK[_v4\7]rW 1g*?Rb{fgp8>9lϔ:Sl(zlKm CWkBOe%Ze7F-X\} >^Y3CY,) 63ϟ;WT6<{kQS<Ap<5Ex|ULKl3T֮MȤAeiQлhfP3#4VM8aiDZG="LސeF/wcBj h19ZUho|􇱇OlI3T8_,?{h Æʊ.w>]\5~eRa.UaLy˝'>^Urhh$&Oh'˜Bdȋ3sNveDbaC=٘OTC<u D8gG|5[ 552?陲NNdGavr_#r`y q]ZҒ@o,˞U,(c:km& Oa["q8 5|{heϑKc,)Px3iy 5;SPmrl9u}5e/ORppdzS %5[OUj˹O@X|U-3!*‘T2`3 }=[5Ӂ3ŋ+˓ɝ07)fy`yLt'uj_K`e pvНZ:yc{Ɖ腁N_ Q(THMGOW{16b"؊5% f!8 yП'MB@ ͯup$ U"mY͆g J|FP s=NRq*a_D%7pF yf&c7mex9I SR@j0aCMٰ$k,/x1ЅT35#(Y9WkVbT>ilz]2S>)Ѕ#83 A桥X/..@[*<-8-Y^_ |BKDzx'8Uest- z+LF2%)(g'ªy#;=}k_ |$bHbǃZ(8q.3!dx*CBPJk`ii\_]9q00o T9tPkrONFbOvDF{ֆWj?|}}I0;tY/` Z ƚ|ե/« a!N4@)UsP6'0+͊7w: D ۊeਤ) e)=!5䂑yCdê*Sf8"C^53D#Ns)@W3%gz-#ީ鍵# 0"E/.2 a!U"X^x#Aer]I'hPc<=Q +=E6a -5"`;;:R%mlk?N4׾<#IYr`P D-a8AFP&bq>R*>`Q.ߌh҆ 9wQT 7(\*уX"mΠl,8 ÙN,z{UpȑԇsN -3!!d=u}&h8튇#:Nql%(Ic3]i2ɪEAk(q5Cat4ȠyEXFKV%a!ga,Rv`PP 'Qg~_6QN\$,Ja_Y Nv:t_:C7dfJ 7|vTp)ZJ<Y5Tv3=IdmpZ?^IȄhM~cnNΆנ3&'N sUKE/0GX0G}ɒHeKۄ\hn= UMZH-ȡ)vuX+ črzbb;Lb&3'HOh/G6zE/HþK7摙"¼Q GIPc g?TJKk ǡ*2 T7̒R^}ANN@$,ԑ:ʞ @wdP:2{hlyc?EQڅ#AjAEE&|!+F*夀Bp[RՄ벵PY_JϦ JAřC )JJBOw׻S~Rv ZV3J0Ã>] =@+U3z,RySjZc(՟q_"}sZsfʭmX?uCQ#:GraSZ4}`j #y[0nm\yurfB5}cQrI5%AȃBӛjbVJd: 0G$PQkQ:  ?`C*y[6F6'V)6EWf1=姘JふGN\>uCQSӯ;hHb$+59;TW/߸6YP@u4XT!w)q6$yAbB/I!KjL`$m=q %8(tC""F5ipQBF3) (FZ:6Uʒ ShUU!ZzZ?Ƒ,/,6}fև T ^!$$ۀDr2;f/z#L %qzlRbx1F I$ (AOPhcթa8O‚lds)D-6Wi T))CK|ؾ\#"EF Pbj'hV%wmɑ#./X^܅Vw.Pr}y0n>; K/NuHLj2Rف ׃LtN*Ufq$3 uBYў-ӡ:) 1dn 36df#虲z]έ<"vQ0a}I8h &/WM=mF"lP~qb8^O}'dXSΓHGٶ#{v2`AH:}0 \(; jHQA$iI)A*sJ/<99:wa{uV66 FQEw=SZHrˋGbvݓ#ٖ k0Э-O-ݡzԖAV, m M"(]PHz $,u,,90 ՇB} v: 2uU?d,HUŪD2ǑQ[qg  aXz!o.K^xl2Uj@>Qx_t/w~O)(MqрHh\:̔-'TRY8eC/G81Uzv%섔[X2VQ5Gݭpv|)J!Ao(-HGl"n' paM%*0k[i;(]vC` apqVNAmWpPzJJDA`${ZF s2Y3 2OU /0X^zVz)!Esreg 2;гcϋ8aԱGZyMyDVçDZ)òw {aS(=N:+ @:O |X a8̓ɷ W[yy XjmdEQ<EBT͡[ܣz1CsFxl" F  P $Thr&9;G艈BIdC=Q* &JPqn ՠ\WZ]xDm*Iq=TJ|rʹT& R') ( >9O1I üVj6c+M zj : "_veT U7jjv Gf/ .-]ٹa딴 WR^ͯx(G&M4pBA*c!0 s߰+I7JuX: z-CK}+˓6%*}eHK܋lJ[$լe`Q%DB Zm4(9B(;V}5UNPmT"^bw}??2K0 0'L:"V@Ea'aCAqq E1xȠ)7&7WһToC\jaH%uȌ$M" \^K*)s 1>VPU;MU][tő{$NH 2b"d@=WJ@4 jB( 0 %*詈<*OAg q51v$8Sp}P@{rΔU]nޚK$RSyˋ>&K p"c݅E֡gv,ֵ 3ј aفh,*mBX&84nGuHuJ)a*cE ;z<9&𹋼]Nˉ~m}Ed$pZ \Yt6u6P/СZ80 0Cu |9~ ovt&w Ns F:y"޸yub_wn3?>+wN'ߪ-h 0 3,l[*wCkeu 76B.BIYn<7ya(#Dôt 9AZ. q[kaaY.22 \-׹mA `ɤ8B#k~vtksz"ewkUJoWlf =B0(ry $%)`a7 ,.w)/|P+u,eyfF6 w!Aq+sC"U$'׋[?0 0~]!͌mo .Ezcs_^ I%waa|@B)ɋ$ aaX^0 0 H0 0 aaX^0 0 0 0,/aayqaa,/aay0 0 aaX^`a0 0 ";Z^eM ü읅WnK޲]{ IBFIݽݽ4o9ܡG-ڳwC2!s>>3U,~XJѠҺ炌^{F99_gGޟƈnsTTT<9?  {4v /`I vQ:7D{,$m坂dD7/cPH]x{HmշDZiwr+u [Ea q_0^qx%/ĔQLZ88IWqi £Ogy; ; 548 '#FVkVoKn]]Ow-0Y;r5[==>_$&DJ%Ӭs#+x='z)A9@s܀gs:A+ /ZEkN@< $&<Bd|-]Car9̉k72'n|:qk~{liK[/y=cS޺281fF/fi 99,s{J "6j!ٻe}9&#LúJjǒ,HTTTeU#龬E;ǓПb<0d[I^f$*q <>`RʑNyTALxyf8N晚'=DYC4'3\ 8%kG?ִľ?oinXIӂ b |*av3='w hrlx2A}GhF @ SWQQ6+)\/4 Oʚc$z{d0$ os7WN U^sCy_HL[]sב/KGCIG * 1GepgݩZ7st1c\D&H5b>W^8rIg*q|-/c9. yjS$)E -}-3}kBJ1eUD_7z~f1/n(@L0 \Mlu=מEEU42a (01ꛄ3W^h8)FS5ԨQSO5I^%=W;}uM? F9'ZHA89[a4@Ul?`׵kT'xæ $ 55j `;>s@Ǡյ NO1yf^xX湢%򽹌]HaA"7:\S=xⱾwR/MUti5!C15Dc~" r@&}8I4Y6&W# 'u3.e]KZQ I$ ="(JBы5jԨySTnנ%S#wO0 8/^2 E"S;haSsfIv-~%54h?4'#﫨)et52ۻBš b  qKÕ{˚VaEF$ a\?]CV>% ± R1sIjxZыtYTƱnϐT|ڢAkFԨ-.Gύeczm,vtdR}TIW(4:?!O$jԨ{d( >&` > ȏd98kE(:a GƢ?rsg0=fKٔjIWV=~rCsf(lE ZzQGg]k=x/.ܔM* ҌNd&?8:8u9.ppΆ ;_\Mkn؊[ FDg_dEG.+X<_UhK]4q-$ пsqG% W@1H'.szP0($ dbNp:Z0RmZS|^=c)i9&МN bצoc=)6K{@ TPe_a /k @U`])kjI^,i'ڟ75#8&4 b0^I/VX23d)FWtJbVvRfdmY._ A|qu6`)tO<$Wz xZxlmd;|a_[x؎'o˒&QF-Np_ z= j`$ܤ{ tʬVWġ*HslUn@bSȲZ--/XLo -sIETR.j'i~UiOyEƑaz!b/@6Ba<C[[2OxS0F%Ir[Ɨ-Ԩ9  :jNoi 3 [N(kxQkG&T݈-@%o4bYH%.Mݪ>*>#i$FE_5|O曒on!cJ-n.'Dž??R nΪZ"pKkhxHޙ61-V^ #^p3e f"!/HF503aַt QOq"/ |Ɉ汮mzZ/ ml ry#<#ȸpƔ6R/A&{z35^,I]`a ~OF-'S\Ammݾd{4D/0@,,V^LF1co,/LCRd8b~PF:^|sMc'0t(#vb 8tUŋFXW 4oś"2DDܷ=0e3fD` MWy㤰J @S "//H̩*!J?^`-9dx akS!u"<^%2p;% Uu31?HAZ*fvZ;vt𽎫AJ=h[a i Ex`b!%^h#/𖗆-*x!͏,/ዺ #^AËCg/mjp xtN@HNE/$YPt3Z٧O>x޽{=*'[j!^;voF1^tX1^HBvuN2oelѳهO_g=RRyL̉6LZz0Ҍ$7dxa nU}# ةsx{$ x2f^0,^Ym ㅢjY8!/D/Ą=9ȉJeeA2f@|VO>˗/g 0s٨Qxsũ+ 9by x!ĝ/7:i B2]Xӗ?vəܾc|`27.f¡\}ыE o4%?gSkᅱߴ^-Ȁd5&e5`AXzPL8kܟ7 eTA. ^ ^Ԯ `U@/>DƲŋϞ= WyLMMMNNr! c jj'G`9}ڦWv^,89B)fy"#[0$>||3nG;LOS$=#l_o2 1aׯyJrNr.uHOf0Q f9Ca}̋\iڗHm5o2D~,Xxq mazג#9yvR%רx% eoܸQ,!q͛7'?~ LOO߹s^}[8s%jԨQ?K*J@ ل90^/&Ъ-kl7+i7>>p|&#x\zqvz&;D!XT?bmo"QL /&MU-Ax33,֌kP (/D!Ԅ^Wbelcc;$GB zJ;ECƋXIF+{h͛7eYI$_~?~o?׬Y)={`ȀB0^srDhi9zBrY9bl( S{g t"w8{|޳p4.=3v5r֑D@g`sCƺvh𩋏e _աK0KYAZ󺱘TVpC[ AG.[x|]m~zL&uRT7\a ;`gV5 ƫ+oo}l +e m /*^ ' Hz|Ϟ=P(@XBEӹk׮ 6/~K_׾ 񌆆V'Nd\v-_pD\6Ͼ<[`y{Kަ"qfrm/ʥkGBt"w4JUHHbcL:S-HCo'_3hmc[&cJs# )Z:nK52P%22N:(2EwUyUGq e*tJPbIz% \ucp@(^Jeu>,W`,K!.'/@tY UU1e@#= )df}[cЊRtЎ:"±{N^̜C"m1{ rh8vl(z7u:d)9Mmë7mm`㚝]>0qbڬDKjطTd`Yu2)zdB$KXԵ q,Zps}CZ$} (1}px^J TOl@ѣT#qFXBюf2,RU'KR(^TlC.6wlZZDsgBoN9DFЃܑǹcOrG=?=ޏoK-M:?\ӵwOZ݇O](*Li PJc/'RqUE+]ʢI A|97Z}j-bsSIEh4VB\)-EB-CK,dM7qjz?)UIEt6/zLv @^Q[X,Xz 0u{]UG޹WE(4122Gλwoߺu#j?0[ЋP[ U&Kھ3,?}bU(ބjM?m񉃑잫{N=9p3犇/]PHN=y:8c*s}=5xT>|2x+.E UJiR(HS,i4Kqw{2LdLoOW.og?p9{vfwk34o]3^&\Ca:3K1^ج聯'a1WRNT͕ c6fIpJv{ L.mS %!4L6Qh2p#)v+%|f Ġ#P. W Dݤ%CBX%[1sZ>Tڀ,@XbƌBBW1jZ=Vhmڿz}`s<9Eg"R @i{UtE?C7wyk 7{ŶɳWny(9IR dtŵW@E NӐWl}sC2D#,3֟_05k&S(GMfq\Pa>{̙+Fa&o(21cV^FpZ r4Ί# A6LPGSEfj̸1#7n԰Y~#:Z:{Ϣ >h$j<8p~5jԀ֯_oJ],^hҤ C 3]v;_t -UT ?#ii'ּkKϲUX gN=y}wl$UJ 8HI$L߮N[OG3[wo-^\;b\ /^7Q_𧑙x{$eF*B @l y<Egřn=M^snM[=+UYؗOkj:0D 'C 0 d^ho\$a'AmQ\_Ir0wk:Y7߶FQV<,wo+-[ǮCef8 n6)12{|1|+ 8*`}foNfZ~1MŌat_N4`C0KV {Q.l8sR3M !6 tW1qn΍oH|wPǻwUM^ {.Vh._ʉի!t_|)!,#F@ [j´?^M'+_I S k׼)fM[ 1ȩjxϮk,~jUQsHUUðuWmf3-s@AR[ꭏ~tޓaavEKMN6q<48̊E*5 rO/7&yqЭQ)&he4zfk27v {>, נ#\d0b؏|͕|e6r_2k\%T|~o;vX%;+o>ط Ly8Ë}vxVLo}2Wɷ%dkO35rK(HWr:ʷe*F4nBi<6!E_hngҢ^sGfMYgF|DtLQ,4tuN{Fi hU1q]g8 &IZ ̘ي݇fEw}ҮЄwVc Έ_`<c&ws‹p;P}[ o8krJÛj@eEq|+Ry߁.^/(Ak+hdA>ˆ]SZXxjo٪ $z7m0 􁑸>0q"Y(RP#֬VAE,QʈO|] fܲ##n6rhڊb_(#esVJH( ]~Q`I2,ϣqΆL 5l^ ^?VUZbѢ+V,9|I_zMB9{,$Bɓ'C*j.Df\K7rbtJh8Bm:x>MHF}U6|63 D:i/N:eILj$$'16 q`4]WxB&W'$7 *B &mN=wnSoҲ(.R@3(i#jMvUQXi?Qs _$td܎yFEyCLG~ZWf FPc@46Q%o~vxXqSyxb; LȸpG_y3d$Ƥؠe+L%Y$"[Ah5N&-%Kʳx^qr#g]v/̥|f=|);B {ZW:15e5AWJ& [r: & #(Minc6+d.rzfs{FHxi6 J| RV5VMNO,.RYe*Gjތ.MpS1afN]9lMkE*)&0 TѬZB.Y`Ͷ*%kL#.^ڍQSw oQEL(^d( #iIx %j8^~Bv,'u|j`h:}3AZPmJ0k#Q`3Vס(@PI;B~T {"$y" *`߶-pĈa^@RG/nj3z(%Yl e/]R>B(p`Uu ñ%+q}% {)Dr𨁀T6=v&D2F=Hye6r>ÂEN9~] }q]F̠L[lPӀS\ǀ24{+ -&!b.;*[EֶXi Bo<𷘫j!9M@| G6}KNڂqH`0⺌qB'Q}*3cΚ J se bۭ\"6>fpxA'u<}}:/W` ;!7-4b>:΢:w(._ Ep-rBmR1Zx͚~O_*$'>xr=#/G|ۧsωZ2^|׵}NmV^0wCXZ{ݶZ9xe,h[(Aa# ԭwd'ٰjݦ!f;PMwsѧ+kNJ ʈ"@ {|eڶhѪy]:;L' R>/3osΟIobׅ^Sf̟߅W5./3lW!NfL͚O__Ə7|^ry㘐xF}aԱ#0JWË B3ܺq/ ڵKnݞ?N%X*tAq 0Y$2vR7Ncc7zVUYuk'.UC1P`ಌ^jA fx!ݕPګ_,Tg̘п35AT^!>9zmGn=VJ)䀥H5dsm"' Zf>C+f,`X#C$s3\H\+x½ ˜p;ZicScaQPqڼ2LbT]!j(V%s!M!mn20|SeC/"(JI,"tfD^kv!XZ  "D .$먰ߏ[]M)β:m0+zWvvܽQ9XG$'4$.`\PnݭDB-6r{_DɅ}ě4Ac:8ı ̃t]t]EBl(*; @cH!2qwoW-9po1¦M߫ ȽMag `b8Wn51ٳUO31c n18_ppMk ָݼho^O~J#vʹvlݲWO!t.vbWmtۓg#bbGD5g.]u3JSVp#zJ3`9_|睻EM-[|y 6jVrC,a]p_f*Al,zQG O:i285%/)%A'qn'FCg!6^r.h1юLT IƝ535&2I!(D}r }`5.ލƘX5YNܵGW|+gn%暁x)&gq S| ROs0%E2aU`*$ 9 |||=qG_]8׬3gՂBbf3aGf!RNh-s$Wr@SwBz(-kE) @ڙ!S0QFjTvmh .NM3îj-7`9x᧘6e&L r^,빸+9E`lI۶f@NX\虎nC|4qp|9{'<-3h߀zq#J0w"rkgF%Ҿ ^ N \߁Wˆ]5~KDn? ̠)`ߐ/4l%豚 =wm 4ȈNQԓK totjzQ~I2+KGwD':kOzGgO?P}Y~+/w'F2}qP4eϐ & {~ul^șs![5`Hg]|=lpCl!$Vjx?V{ شw`/.]j^FPVgϞ:vɓ'Bѭ';y^h1cì!i{,J0t%iCe_qY@H`G?jӡ!Z8ԟῖ(GwmZvTxwm{M݀͸Yd;dDnG "߹Cs' ;7oĩȵ|񥎒̟{F[VS NMձ|&PPY?~x,M-041+Bn=|/Hĝ7S6GǺ`hMmqͽܠ3-S0rvKxI Q5=}k#3L}[]gE5g*+(?}/ u B]d EJ11iJ̲&rq֘,kl6(*l ' #YE@ *e(2(KEYUvjƚ]|tu,cҌgUxa9b+ڹ;{,%>|i0X߷K+Gnv'&?u O'if:yjbol9BEuprBB7z;;3εN_SZޫ#9V5N#mԻ#2"%[E/W<0lShBը\%."h![3ȊiQSH3" Y>u`;nÎn=<~PVFtBK!7I'څY<Ӄx~,oxOa!qhYfȺ9po[ojЯĭg:A^tǿ z7?>ry/ҙ: vЍ}IRG)~2BƝzD[;'^NCui Ѕax'Bߚ\ WkH#_q\ct3-ڭ%hT׶26XPchQ xޏ^嶯w87VCWQ7T*-++[3v`/vI?a36lX}|&KOxGf2cT[7N$ ?`:Y^n(9yA~qPQt".0M:j㒉NHD7B$iԢ Z7پ;mr迧 [Ğm=M٢ԷSm"P 8'.H[2Y܌VhI#>j b?fؤp/Sˣ7外N]mʲ_۷3/O07Łe &%礄]u+YJK$Q3/IxA%{OaH6B zrTRQ"Cqdh0 ;a0JAJ XQ^@cϫO7> &䘲B.@\+0s Մg,PJ+9U +)$-5X)̨$lG <Ʊ Oh﹤k.Ls} ?}񖠣"D].Byv +{OBS®y" d>{,0%MG'&<d56$ia|^d///J E8b0|!&B D]e{zكLyYLoM;*&/j0iV-Wr$iSǽ Ni1op2-38|R6( ul*,!x~E2 J%) #>6y$U1iCẗ>%z|Mʽpȑc3Z=H;}oxS);plvn~zd+Uc/NlAߘ)ڒ¢\:52Y'i, =EpKsNon>:nKM,L[(WK?"wJBr]:5xiq :(8 @@Ia:#4ws:#N$IMm6^@b4}=Q:#Y|)ȏI2G@ Hȭ22T)>%{kWï'MV smƝer&6iT=-hDޏ .R%DjSdoDΫȷo{A6%*ػC^n=qZJ^~B5*͗૧edKj+AyY-1N)p*LGn]+f+s@M#W^K+x!(KJ֔J4*s;fg=fucF5@W9{žVo9zyjJ/I7mɹg$ehθL^$9g& d@˰W*"q'ܵg7ޝ h [nq@`Xlab"N#HO@Pܾ3s@|i0=co$1UYa:pcIj<yj5k`LKb1/`ׯ#ժ1e1Z!69bǶ gYVyv4tI0טGV,=y$^*rh-SC(Q*#Ф3NvPÍ ל9SHj}ƪ;'v\UjghӞ3{_UfSlʋbN^boxҖ|5%ۚMȄJ$nEdP< ξNrwCgK43l>]rvC@q]u3Xm~H\HX8[lH3Xecw$DXk¬MZ oL 8zn;E!)wlV"X$u%ZV7qؓKv!ץG^sBqBK%^r""׆N advxqqI}[b,⿇X<79Fj@@8-2:rL}}D-F<.1*7c0mלpgGVuq]a$HDʽobj5㏍^{Կ/N/0Ԃ hBON5 R!wIÐ$y\]Jxcgh< nuPURJh) ISlo Rp|J5,ۃӸį_PňݥtbU.FrhR 7";x Hbv!MMŪNwpuNx/p r1U5s_)#"K_@UNhW9^RgEd茉'jK׺ܽrKY+M[7 ؐ~ *~Bm6MT1\b~i %oX=ߥ懲t߉Aǯ?}gc_L+*g6-JN)Jl 6) j?-(ΰ$#PBpBiIcCؗܣHcI3W}=m%7bcR%uBr$k0o8Q Gd`HΠ@؞Zt꯵ҍʀZѡF%MYnf <{꼗*SJao |ZUWbn$斛\DF.#gi) 24E7=,&MيeB.2f S(ped-╜HʵoRWCؔ \Tb|)ުSx"b"٬_}٫;U"K}IZ#2nO|=Ib+@Ģj+bVѢ8i5DvTdfX8Ug5=]y; jF6n~?羙ܪ}g/jb:o*qf^q1Iǃ#M=K*Z"^- y xK'$ dTє=nAgPGQ<"p XA$&LOﻓ&;| ^2`>>P&thGίr߾xpN=A%Su -'`/Sx!4,phz ҏ 4j{~5iN"r]ƺƩYU ,0) >P,""vSrڀ9y6fbң.iȃDWE>x;5#Xs}T!Ą jB35W:}΃qK G5(j]N͐o?t~+][I-H,l* @ 0D ɨ@f$ l;M^tB8’$0np%EeW *[;zj$&ԃ:q@Ѷȋ/gfa]IHT?P=q}7x/^8 |yZ%|dmĈN$d JM{u-8Gϸ i;FN$Mk^~nN %"T;5C5?n򋮚EڌS\JTsmaЧM \"eOLt >!)995OQ fEǑFa{9za#_4>bkDw doTY~ce2 T)Bӱ6ѰHu,7q48bM:2Vah|A.0W>},vzNH9Z+1ILEK/[fUrRx!K#BƩM)1E @K/D^hQM{[aAp.b  TËuAGr2<xJKVm;yqҘ_R`c+"" :HV2I>kϩ޴84&J!*!)~sh.Ld-<70 as|܀b TJ[j QͬEۯYR9%敠q Ux\{ݸx<^yj$Gn8q*C|#~3h/WQƳYjLZ9i춨nRش^`a:ݺ}! ڋ){a-nSFރ_E&x@_O/>ˈrSM_U,LsÅ8H]B kȓg~իsO5Ցd(^J)rKcZ@Qc"MJQ/8ޜA[S<@0zu[)Q {e9̍#qMqV^Ɓ>g޿`[^D_48%")ua5(:|ޒR+wlXӝ!>FIvcy轄Gb6=sv [<ЬP٠)K2rJ՜ q6d:rhxa2heۈ#>#,Qc# Kx=2Xj-^ڻ`˂SB>(GVb_/M[\ -!%)4U~: s !Tl@ c]G@~ȭrZ1!B O3'TeyMYO8KQ @?<5%L&"O0k4L#+.h@5qLkyzM8q`#Ui GrJ7]"qP9Ӽ^̋A$RWP8Չ-Fgx6ȑFn{il/dabj>D:}Q`1:H$Id*_,"%ZHgLAF0|>'sֲcIppSf-xq|JB X,]-Ij(4 M(ԑwauY:Ql#2'+%qAעp6L{8}h[kG5x?xn](0>ǏN{9pt؂6ri nظ\~aܴem%_uM1M>-%gM΃ZcР^RԞ2c(6.˿+D ܕ'NDy/};xaቋw2W65 X^$P]_L4nIOz M{BТz5bt`N޾tƗ=~#:Pfp ^4kYӒAʈIIi]wSbԦXͤhqc'o8yL`:  ?R'?qv=G [ /SΪEDloN78FCIpiT^@p6e1ʁpIno&f#2 #pFEh=^} }g+.\gUQjNk)ZpG$!䕑Im󯥕LJ{0KeDMe)6/w+B%E٬V%Fq [*`%WKM~F S,4BB'T!OyH3zQ<1d@.hyU:{T>T97`7IN@r]i ` :V!s$)_HQHT?S35)pF>عvqe;.OY4?N ֌ا l2ʿrF>O+4"QR3\Qb߱" [s~hv5)d8sÁk aE'^ѤPzZWM?jJn~_3Y™{בXE|nR;)r(*/7{ւ}CiًvY T ,ބXOr9/Ta+Tg98Wp?n bBR-ͳ:+/V _ ۍF^ & ; $8iӖ0ʯ>SV4zE~&H(@񣱸S=`ANs -W4Kh+!ҩ D+y(㚑"|d ;S5oYq'6=s^\z0%"_voI('DZ;-qM jA oB rBbҔFz /**3r>+v+=ECX"R]?'/_UT\WC4iu#JL1f,"}<I4Zy%/%etsd29b1OhqX62ې=k&3j Ѵ04ㄎ N.J~~AnF^yFU[EyI1DTzriM `#;NXWH`FL(Ȅ,ye9F#ܴ=iMxk_mdH{ ڋjxϛ7 ^u‹at[8c|0#D cacBSAHMCF G@ HT6& ,w?o Bΐ u BƔi? &E@^Wm9 g@5Jt/Ҳ`׏l^^^J\k j3Ȓ9 'qv Sܸ?>8%xSLb;d3V}3339""6MZ1eʔE{`mV| /pfA3YY BLI)Wk5c,㸵pnǰm34&)'iɮaffha433f4ҵvgv@3;;>WW&"pSCca~Azz:76n9TIKh,*,kYazkss lj؂\eL3$@!ܶYKEeqaaam]SQ+CX* RHG;Ȳ%mɘK1; ,TlLizGgw7{Y(¬Q/21 ՜ttLtv:CQ;fѧ#)x4ŽU Jkz+ C^Kf-*C SHH _#7)c}[ D@$ rPFJ(S/zB?999!6zyA:ek?+*kM9 d N`F&bɾxXsF1^xN䦷dLe`Ƥ1JNP|Tbcaq'j;s"Jm e(|r\FΣ}`~ 5kZQ\cw`EW 2s?We XGbUd6(Sd[)uܜj~|ec^a+pŧOvON?}( A8wxlS냁BUuM:QqoxQpEEu=kU$a$%!([YWvϴ^lDlwxx[_E aq1SOK%1[4M@6AnP0$^Qf0_< ˸#|:n3W+; nRS}%`Q1»;h%%tM<}WF[h ֲ?cl44Kmq%#/;Ǻm)kLYᶩVjR['/ &|0-5 y0G_KknDOweڝIG53ٲ3g#8z=v:u JáC|Mm۶9z(0LLu*`T쌌/>}bJwBF!.\طoƍ8N' Gf|q 2FrW2n2 dzT+V,itK Zob/80)N膹u|GepX+{kyv(˼lop-j%&F9"^ {?ӳMmB`)nfGI0;{Ý-" ό3{A#f 49U> "²` >COfR8gFĵX ~*/r8-ّܸLY19iGO8~겯%uV/b$yԙ( *cx $^"E$2Ssqz`T,J 455de斕Wҫ2O>y۬ &Q݃۰q x cezB//`oF~'ڌI:{熮Yf]8ٳM9s,Y2 p vs?ɓX neH˗/OII3f' h` Ԁ|ei#?zYЇLm~@+R5t=MדX$Ou!5Ѹ~klro;Ʀᅩ*36wpUtY0v7;6p4G9)vՅ0 pۖ pDb\&/4a $)y6g%^IgW>?v nx_G܆ /=407zӜKPf_ ]ͽxa{( Ĺ6+>[UQ H;&jHX,p/ W7)&'a6V„Ymp6d/>Q ^PE4U=צ4۶a:/.;WTT0VÊ\ Ĺs`  ΰ,\$ )iiiPG02e挩d6x~m wYPN:fMԬEQ"/*8\iAY}4'dM s Iڹm;m2&lv)^ &Lx\khlɺ!=bd ܰy  t':NiFm f|m&&F;hKc+CQaBV8|fliE0' %޹D:*hD$*^xtndI^z嫷a؈^xaXƾ_/:G)w/bly曌vVBO{UF %NUB5+Apɰ6kfN_;u>Ygikfz]h?3fڦza.Jm/~쫜^8z8?u[5gLX@`P4 R&^rA%z` [ Q4 Z*`@ R/}$G6d%![rp7qҌ g\@J jr.cV h4 Tura&VAE2´&1c^so۞_c7uXQd9ȴQ0Դ dCWBh0>GؼX]bm,F5 2HI ㈔.rqrJKrV l[&&mI\}#0#_q]I)ֹ`Yt$tAb9gisTքax5 JxQPApF# ޕ>zi);RV`I [wmۋxa*jI^yB41OưI۬,mff:z8=vǍk-R0nZb%<Mk`2 qxiwӶ)x;@dl/gQ 33x&#G /eeeA'`Xx1'NLlp@OS rTAn\7P|/ 4"a`h onǵ&}QwN#tY4|xu@pRE7I?\^aJ0G^hM؇1*DHW#LqiNb~Z`3Z,017^[;Y;s:7ey RDTH?GDƻ- 5W o؄_x 5)]T\Cx!3 %A~EU,\30 ց5NN:ݑ{LMpͥ?h^ ך _,]];T"*8"FļjA;x=2{G|Ci0=sp7\wZˣ"% yq}ƌ]A5!&ә ӣA N;82 < ETAn_N1u7. ̢<:4 k9ںfB\xsA̢X.@]%)щe!F %L!J-pr(cLP>. Bb?:Ȯx\\}P; j B[\8m܍cLG$o)g0$ќum^( Sl4gAՄVbj1.n,Z,zlS%R~PT MGhv\S vE^u,vl3w *eL:#f?2x杸Tr  5 B%լBENRY9tf⽓mВ$<{+*IX$ߖDЍ.^8"vMONHu]V 8ta.MJ5F{\"oHs67A FF3Bk]E:"L#*%H8YL7&a;d>ςlCmZ!풇^ _RB\ +R̤,,_)q0kZkWýC rǢCvgB7C[n-"a] {^8w |9)9R (< R;[*aƤ" k'SX$o 'ԽP 'w~Viis$o>6Q`|&Z#솬yr1;5ֲ5Ή.3Dl_ m玢oҭX"x+һTGJLOb9(O C-]ţSw7 _P-V@;VΧ8zꀗ'FW?ze粊Ya?ᔣ!sȆzAxQVˋXA5ϩՑ";9Ѵ`qɫ\ܕ^`PAQk}32yqc8L30[939݂t@KO_(o&I:$LVH+DžlD([XpU"9uNT9/1y3 ԸtL r!T#5%2N! 7YIX8,t]O͍֠wXETȈ b4RPsG6.ۖٱilNd0b1=ۡFFF \MO$aNEkx!Kg'p@c^4Z8_3 la:u^ cJo 9h`j^ۨs}`Α E2~]O/d5E[ucf#ޔ4ӼTɅ>z6xs.dӌOG }xj.kڴᴶ>)ԋt1OM;L'pZg؄m >olGK,Fƿ^h aK^e׀ zeְ1 0Iߟ~m̬g2snޗ;A;0avD6w_{=a ga˺cU|c{=J[.O?K^ɯz K,O=}='?~ĉO^I\p̑=}~?~篎SP-;Sw>O=߷S?2d3o$$]X(PUV\g ~w/~~SM#F0_~U0t։[-soƒ-N54^ "Q^`Xl'x[0`O :%M"j\927Ve@_t؝T/ͩj+Jj=4*iʾo{?muSW&,T}4Wm B@¸TgzyB_slr tz.%f"-?̀kSHbg>"咒 G?]wX'v ebGXeg؇?dm(b@lox_OZ[.8bR&)q_C R`[.2{GP2Nu}e}qg>zQ|mؘRV5Bq2SqQ^I_~z?U"-OxN5L% QNFۇ߲:q{spY Y}|(b7=zsJs_wۻ՚f:Ʈ05Q](9{ Vhgn|jГt}oE6ztjt nC:O'BbxѴ7$7ޓ]tbi/,*<.7W$I?25 fævVP7>-0VV\:mtDMF?| q/>lLj"MS_fFٺ5kۘ2wU7ٺ9y~L4Y+?}=G>ç2?v"q^h]jc7|v?jٙnY2zMԔGj z}h!=9C4VB>Wᆈ/"5H>'q9s-RxQK យ<' %+22OL=t`[tǷ=Om;vGigf̺tEgVrT?vGl8g]]^dʴǏY8%:%{ %F O>3"j~VU 0/:|5gV-qýiga{B-v^3~ظ:6a-̰h {R/b M[-?L]>UD8,B.A4=shz P8VYϯߺTVݲes~?>;`R@XNba. GE M~Ÿƿ ͕~{뿦W%xlhb@uN]%ݶxGߴ@ټ$o\ױ\[/Uh`z7ifI=LE"iċCT-(^xGz9K6 ~mZSL@|b'¨I `iu*Wڒ^x&pUe_&X茭18؝`vaK v-**&-ywu6[s˹'gﵿkZ_cw]yy>dǞ3C?lAKF$>1-:q`|P3@I=:kU;6oо[_Z: |9ߝGxav{142#m HWiYdĎ}6k>Ёr˛P^|z CxǏ [1B5TgOǸ˵:@B0@D=bjѩ@|AoŔ n,FqlGLM{ְ2{ Sz~/WVV}SF}ͺPSԭL}cacXNCmLְxC z:OQLj E b%'j%C;7W?ń4QBlU5FC>i,1 Cez+Ho%c6i$YnB;kpZȃ‹l÷;w5:pᵒV>yPgӃw^܏r}7୻@X8@LEB:aq]w=޿pLDt捛W[׎<$bàMvo![Ƭ]3yڀuBB Z,d钐 .v՜M#6 =1h!~tym}e㶍sֲ :~@3FHוhZ 'RF*u鉋ɥ1ԒGi1W 󟩙o=1{&dl ڴ/hS||ۂ;Vlۺ̮WN>tOͰWŝ߱ž]y~KO]yv؃# 3jލ;6tΝ~700IpРH^N ӄWgb9 %2貖g~c0lՉkbp!SdkQ%g e8n^}c wKtxU"8׳cM|ys=Xe[ qaċgv!9tZkA2\ a2V(9H27qq<D1i{Y:oOK!k=HDz\v b213dJv^SD&:w`Sۡbmxhs8!fs񷏚2ײ0ӕKLbru.m-тr@`ϢePP 'waӂKΑ-3EdBy:{t󖃽u3Oבƌ?h 5uӪmwo?dDӑ.~k{[h;cY˦ L) ƒϘ L=;f`a#D';8pקþ܉7SS-ŨE] 尨Z4oK7EH+z1liS_}ԲgF?|\[6mQ1OKTJɨ IzFNܩҮcf-zt}KTB4剘- a2.EA,^8c-;K6FNCBm}ܛtl;o~O)_.jE JOM>..έtZV95bWK/+u MSh㄀ f. ^"Wb`(_&hjhX|r޿Ǝk߾[ݻm)ªzle71e,/ >w; 0+` ͚=7`QD쏮]=xO{v>mǎiBu-I6.@ɘ +j(\E2`C ER*fҲ(Ii pmGlV^9ۗKkNm6\~^ ~^` /DMDFjwQΜԿ3u\WayW-286L V9Wf5#`\"-E(@Ț8HZt!Ë́jiܡ 9c4X/.5?S祾7n&+-I*X$gr鞃'Gާcvmڶll@bFu1 Z/0_ m6cVM``&Գb(%-]zݿWv6z| G,#ЁQL^ߗ'W ` BN@j+۲LCgT=0qdTch5nkUڛ2T>pm~dY~Ъ}wZ09[OV0]$JQ8}o&aR렝[U"̛jBwplAӜJs4wј{h/Kh.ZcQ 1EUi7 {{vT2PA#!>laNS'i5ߦuܽ{)4ĪYcc9-pdGs!57s||)+A|"95=dY8_1W^ w*$> EV1D[8C?{|E;)cM?{6 :epr̘̹0'o</U/̴/Bݻ&/;]l<7؎!2E"qsfFglehU$[Wkq\7UW2֫ (x7\Qp-%Qrz&K]c>^|JK-k&O-Bb鐮@]5CBn3l"G4v.0^,ŜXu4-5'kC1CCdi'O=٫Wύl5PFP3f$ Ξ af "P,wkk.wF޺sKHRr WnY Q߆MmՌގT9!˘,%G6C >dPݪ|| S7^u\'M~{ ^"2\Kf0(`C1pL XKe,da#Q!~gy?3RÄEHBur-e肬W|[@'F1BKf"6B*o\;W4]pP/`6lAv|{rCӬ=(+jTٍAs8$Aj0%a^SW>ߏM-oG G޵҆,<Ο4mDTԻ+dq psJXQ16ʼnuZp"*H;nأ{qFYOiߊR)`A-JOYzy;N=+&j#vjծ];@[hxI /p]$s H( Ҟm{u=D,hEk}|QG=|W;Z,<86Z 56xuV3&$^dv>=x][5φp+n#S/be9]QCG>UjWi9WR)/ܼlZn1( V@><*khX*2dV y Eeܤu훀یgQ8~@rgŵ8܋TڠxɅl\׾Og, 3 S妛e3SE@0YKΣ2X;6V,fEJ:+$I$ܸ:~cxACX\#leűax3( /m$4-7z#sH3aD"UpF!1`?| S; 2T늑~I~c[8MY1(jƁܽ:⒃ awv*Qނav ZojvDc (e6BkXƒAs^UauJN]Z*)e~Rڇ>*E/y~,66ff鈱AlGl 1r7φ$%U+ݿmC^Ic Ē^XOڤu_^&XÖg h.K&/m}2e^8d)VC;.mZ#¨*47'9psC_T-sB矲2˕IiQyFbGkah٭mKFk%b-2mm) $Z=Й6x!++=P;2wa$%%'2VO‹^r{[B}}'#AӪt,-3SR껏_޼ۄO_R3s#IrJ WY٬PWY 0 ,"ԩqы:ķS^^^m۶޽; a@:0$?/OiPk⟜74MOMZۚN_ػJ0@=cC66L%%܄gl}c֢6]rysΝ;x%tחa@偺v0 dkﱷRa@xkk u*zk%g#G" \Ǽ9 2h_q /*, 9lۥp ~#klf8n|(/FRteL( u*й']t9S{{d B8G}OE$S&V{ =?tF/wsFIU*3E@\ܡ=h=iIx%VԒmݐ3L: QJB ^kCfekRZD< ݀|t !M#r?aEv%4r+xÑyȫ×f0ȟ|$N8-xXJK Ud-쉄X#XX2uK%&d7tP Hd֋RQ UT--Ma >3yeWG\ T.yt+b)^l>i"U8IE,tT(Fy\1'k NK548&EPA9)K |XIRnpQhဳқ;qF [B(| ߇ ^a@>D-4Z+a ơ>#]K>DlPN,o! =`R 0GNY-wc%5BO˅feQ8XS^˒#oɫ%`o$\j@@G)zu=DDWMolڷP zQ޻]SX}:RE ~k%6.;zt'ESG P;Y !N/*z| y<&! W*˪$Ơ'o:|w$".XqbU)_;3 6 4h;\\m,CƷ>ML6\`\EN$oGAy/xKc0GEM ɌZ/~^Y|Vr/plkiV'*W|ڙΛl`uۖDWM*z{VQ߆!y#Cŝ1{G j P%X^Z4)v|e#?֭qC+0TnHFx͓zQ c2sJZ{INzcpm0&#WZV:YώX3^|d:Iuq,m ?$R"9;ë?1(R.lɭA~RP<| j *$1`)[ ѠelpwO;@^Wb} \%CYIӈwqVpGSq>QRr:jaa1 -ZYzfGBS1cPGpKwJh<%!z]NPB.mb42"ӂsbK([<hØR Lk)@!-&L~- b-`WSZڂc{{̭} -Y d~SK덣elFZ |k#X/TBbÆ:o+ [I XYAa0X *XG3UגaL}T{5fxĉ k_xAˏQGW6@XrTTIȭw/ #FtX2ĒANOhŦb0j_ +5W^Hb5He8a.PBZ;D [G`wRG*ȩk_DVԊk"ab)~TN s=J,AO]yRXڶWz(eJچ I9RYUfY0]۬P)/>#˵e_d>ጦ2<@p{i&FK!}&T҇/'T_4:8Ē3uŁrDpL5U) Ƭx챃ڨ0ȕ-0ȍ_ dm9rQyv C@jQN PkA)(t ^Q ܳr̡^Me*Y&2y-1F_&p  /~^ܧFCxQA A̤{{\m}y赣4FS囎wZ ٚg1 |0o׀i,Lʞ:UHl% m z{_߻3=؎kNΎNWc38/!u^ˀoԌGTt?! JڃX(Lӱ[(7Px/<ěe`߹H#v{=Y?TuhXNf*"lih41%жƞ"@STW&=݀ٗlO222|"C6ӦNHiAp"vRU*,ͣdw(s:R^*ps$Ur0\?tB8Y"9۪ \aVN#5 :I.xZ?PrDng 幛sb# (9iEj̝l[8ɓwd-Ƃ`$eX@4IjBGZ !6\Pf ,ɕxmދmQ|~``ˏTS.4do;毈-wGAvp<;J#"79D- 5)8\vp8t;$.7~y%U,<߇23k}/a`Ë K@U0 >u?>$[0|||al $"0#zyqH4ߡТ7xD3$0]C HKd .0YӤ\ Ck)M򎗅%(h 5:UXy{Ęp+&dYxc,to-Ho.Y1ChӬgR2lijM2Т@/UnUM-\>T/4ilHXr-ĕ3ǩ@^.Ȇշ]:g@_ XϹp.d|=;Fmk%W+Ny)lG?z` QbcبsOQO 3GPI3@l š}63K l?3Y5 U S")M_ЌKsxͺ?Y92%Xȉi<|ؠE7lvg6-vxwK_x*~%zٱEo<{+a'bpQ6̕]-rt,|QڽMd+%⯩ib-5B\ Kt$@k5ff`>OT|xSLuy& s/`~ <=d/9%qvH[Qh>eɫ/*^ik*"O+[Ȃ6;86̲4$$SW|%`fHd%US[X6^/I~{ٜT6ho^62D[ ,XZ*V$Uq{#E[XDUhR(RpDW,HEVyF|z[-:ȑhjܹ|Ubc )Y0q QBRfJj4ESѺ*,ie@5Ze۰iB!*X2bn p(-nACxGB꠶]#[]dfx؊B%(*0V%3J "Vm;oAXxbKDrV)eϱwKI|n 0x)cէo>.-10SgB31& Rp,fۺo\> 3sK3>@ L2ތ,wcc–7-e3Y450نU ۷֡s֭(Bӗ> u|@ ZivSSJXA/PDaRWt7 (9&D3v\酬+(`N-9XC͓&ͱj ܢٴT_8q@m,7s)|u0j%۷2@34r6#BhiNfMe)ß fe +v#;xjiZHAƌ=x⌧p?ӈ1)9DsࣛED*\1]Civ ={h?VS\QR<)dz ď{8<1ibmʒĆB"Sira0wEL%JC1JV@`e=zAH8. N> o iy2=!q(dcBțUl&H jLBLzavY" PT%E_[XrD. S݈ۗY"pUeiM-&e@Ċ>g'[o~HA/|X7eL{Áhp~ok8A@Fxq/~- آn ]Bg&*-€L0 HѣgϞ*&BNZMĨ*KrrrJҟ16ZePNM%5RҹkJaM*)-ρX=0rѭ ) `8ZNE0 6RObbZ"tQ=5¦2`Dpr'+.ih2t HiM% MJ\#f "C DIg#(U(C1f)NJH4J CIfC;v]d[bBgjG5.ύ+ר_=}X[)kb1,"Sq<džc,L//?Xz1 #oq@e+l1A_.)IMBKPCk]=xwSwTV6aBSDɱNڟRS 1$mm/~j0s G tVE%c yifuŁM]!$^0d$ZN\S')XkLJ7%]Hh MHu~Ȗn-)%D{&>yU&\ ~Vm:"bU=7BCܡ]$Ĵan%z-Ypow ){/?lV@`y(X[ѧɟZܖlDcԏ/rHR>p B?uRJ ̙q̙ݻwg[n%>}:0=J?cwYqA{:.;EUɏ~!ӵh8֖ftЫV摖1r}jJNGHim[4\IGolAv;ܥdw&LVFpP 5pり5p8SFb:k&ψ<$-GÚGA4GrZ~#iY0oH'u^Ϣy[5DB7j1SB!3\X>-ӎQl?ӦSr/Jo6ZOŚ슌CNfjEi,33}gO_W/&~/_?|Jx6%%O>~xwĿzeG/:&!㧤ʲRQQaYrJ;A'wlZ^i`ad6T@r[Nnni5-BtD$~Wɠ|zfa~^\s9"2)\G,-U\XR]$̀XS N_ʪMSX 'tRI42 ˰t҂ܬܲR9 Dq[UJӚ$U*o"qKu䇶J.J D˗䕬HT))(̀*R!Z#J*z?x3"TZc, y ;jirPDU UЋhjaS)u ^W@Lr0jt`ZJTnTw9BJV Zfm4BTz:{A|+.*(+)*jZQ)AX盜V+pt%PE ehqTு 7Z 6)E *TTۃQ0n2%1^\~?^gY?&`@cLiϛ6m9s&0g u$Z/ d iOx/~5i*Op.ar}uk,NJuz &fxv$4jc=}X.2iT $GЄ)sUHc1w6l ἣk.<={7.:V2JQScۨ 'ecDGÉpDVt8yvd:IHzpjrC8+5<@hL6#.QXQDdjAI x_-ka$~q%։F7~MΑ'_x\G.0]fww1g  1Jbl5Ųb[dٞarбcǶ{CjiWvg۾OƓk}*[j{UjUOdʛ=أO?h,w] ͭvыx,YXXX\\|G{c?aq;GdY?0>>\#M覘>k;1B-K8 ֘).0X:#W`4be* ~\dz'%o*KJ1F*ld7ش&@u0̰lHnKD 7ħSG5's)SPu>T'Nm*W1Rp E ޓB y@,EsHSa$$)4[?f80ob "vxO'Nf3 b[; כW]SAc}yh,? 5ƚ 4ZGtFd# O {;YV?r(ވ?}?p{i~U7*B/&&;cAzO ~zA\e Uĸ>`0v;\.O#`g#G\WeX2Bj`s5)FhAh"'"1zpR%J4 X%"R !K|GfCU~I N& 'ȂkEѳh3gJ }0 ENānԓJb,|gB(>]}t40 GV*ZiƜCDTw,*4F#PXq ָSsy54մe΢TodX152{/L U^«ִGp-z'7o78 G9p' ޞ.|^78]^oGWWW!D0?|СC fp@oo7؃niܞNDM" \x~~.jju,ӼB+а {R&gZ1QP $: 3o!#XSiWUzݔ+S /#1< U5:m'D\J%«zz@I/B-rJO{՘a`ϐk%6Μ9^VX+wߍkx~^(^I ,zj:D?bF#Hv)1=,ۺrBghhl06B/'{zђFB60 i`3t#X9'㪗&ѣG|'NN:Xs=3%  tIHÒ?kb5 ébMhB/Ҝ^~S>XEe?f)|z1"zAN^$ ;z:2kz[QV.^xky!o?qS'CA ZS3(x- @DZw{饗3^}\gςUփABfB]h%"VU#v@1ahT~zNeq4n8%kRnza z%N"PB/&z+`y/;XRNEElBGqd,//SdK&o !w PRY c"f~? @'ajQQơI6E,B8 ٰ(H ҋNN:N/1SC.X/\=d"}yrY;]sOj^ia! 1 诂^DV3ӟ^\0sX/Hzq9zecz [v*yk)t㓨{CI"&OcK}`fр0h6yRHzqrmhe_2k? Ą.~Sk".Id$E tzGc򮻗[EIkyaW)Ѱ^ͱx''PD/1jzvVT?u6b&Ef*Hާҋsarc{N8RyAlF{W)McDz++6 VO4:^IJ6Y}/ED/HO> tF^<astOk> zЄ>^"EZ/^ζZsA/M"]];|;=k)+cїō)R2zEg;{J/F A/x_{\x<׸N/*"#G|>3斗 ׭zB @l,EB/ZŞO_lmkko\T{|5ŵ}h"Eҋ!_A]a׆H`P' i`^RWUڷN/ "E&~35A/D zak)/ z ^L9ޖM?y^[)BIֹJm탍> =^Ds6p47RZ)J!d)R$0 z_/)͹5mCM 7-Nȵ/ScvgGڡ# BzH.J&EɷW[s+[4 b!(4p!ᠫY>phk8HJ{7Hz%Ud"UOIh+|U$[ZCc@^s 33>,fƛ;{[sZvV"zL*T ŕ"E.qfTL2[IZ2wXs0 0;!ap#_hmXC:'+ ,("E B[(kڊ,˛2:G&Svѹzp&Z[-%?tȯvF ETTza+j\_S}i3i#EЋ@7<ӝ^8>@+Jzv>r.tEЉy41A1 NnFHH \~ (:רWbDP_>g]79] ~HB;862lom,+wbل@wL,Hӯ%$[GxBOhlP}7#!DSc@tK,Ժn[ tZ/s- E-hj\]PWsNd%41/藒CVJrSn&h&(qu P!+#T/3/bpv|f6Y?N, N_vl5%k ?sr"UM i !t|"EӜAÈmV6I9V: kZ]=}33͘ @/ D/L"_NaglQ\T{_Q‹lDYИaGF Zɼq,eyD Eg4UMhf ^zbt1s,F܋a0Edl<ѐ?:WBNMuǖcE:KM K$}_YRt鼰m`wbߎ⦲j[Gg4:к7غx?CjGыVO癙; wT˩~3CbHtLA3ыbӢU`QOtU=w17 zf#'w5le[*K]ρ^u߄n][ -R%$6 /n1)_A"5kl렰1A/b("\ETم?2:RWrs K~yF]I-RܴWp LkzCŎ,tla61`-βYQaS%N w~kdZTRPq]}[dK%C)R\h \Hts'V/RTTV_Y=60[v9A/8`XlvTgoʵ=X|k \1T0Oo^HHHNf GѨ؅4N{Pm` K``^A/E,yA/ƇF{*2K7u^ғqȫ!l) Cf_$FJ乢1K5]%ûb6nf1E&1b/1ЋP|cM=%7Lxb2LFnd$!qU1dZ^(\ݠt_BO=j*7Gn*h4W죈T:h=ƂȔ}zUb,Q\Wm?zJ](K EUƞ:_UTBB9Io|S zr0l?4k%@Q& 2Ca}"WsaiiCJ /YgR/$MRWS HpE{jA}ǖҦ-eeeyP=6xtBIa3Mn l8g}mg*;(K~5X ˹<RHeWִx'sX6poֶo+o/*)lo+(h4 1WP 2zaDžuj\XPu[m2kk]Ç^:w %vkqJobHHP8HwVc+oW;wlڙ=[a{sq|j!0@ϋ+rrRx>dXpTVe=[@~%R;v!IV/X#!!aq]~+u٥7/{ұ.^?8sR7cy6 %zkptfPuʛr+Q]Ǚ?W96Tza ^x8hOmG/怨 .<xE: ׺lu٥UYy[3AKm+VXzgIͶꭅE%,o’؆t+4Vh@vo-ܜ9g֬YۡnU9¡~06f.a`2@UQ,`$’^QR*Nl3T@}^T^[`Vy[dn۴#'~{nm ȬzE5We-46l/ޚWvfٲzECcuGm16dK [c6 -wLe|"|Cg*MiosZdžlʺ]9E;vfnF >3gKv'[GM \Ҏ92f@vdej媴eTtK:>8:;M;gqC4=30E:梞Ql`#vߞ=5X7oolZVv~梒-;wm.ټ]g>|S  ;wn(ؐvv tDCAʠ,Z>PsZ]H_zz 1% J<f [!Aid50ـvt9% UY噶,[E6 (Ͼ !!!T 5Y j:K{lMMV.$ +V -D`Gܦ:Cܘ0&Z&)8 -yl5嶝eU;mY@YefY.@*5A;M2[f*쪂F&CH%oZ:N ƀ@H b_k8Ԝv&G?7E=\ zjekH5EgcjFϞ.wI:;W@M *C.i/B TBn!'ԓ腈 cҢo "][о$ w 7<3418W踮΢<7۞ .VNW_SBBU.n/pwO垁ک=MD0kƤ3yN!% 웈s  ,nN -& ;Z |,9#378=ubOpHĞ+&DU09R@fƛ0H1u9:H{3 ;xý+67$0 $׊DaX+Fє}Yq] DXx=ʉQÍC( Ph#Gk}3vX=m ;m!"|z4 CI)X3O>.Y@ _XmQ/ A!oLQLk*ڨOR7cIa~:EC`xH*pR3D 4p&#bG {8q?7D:ȘA3iE18 8lZR$Xc.!ע37c ClN @$0CH;zele6q uG0ypl1A(lBaIm|C!$H%si0@P;>F sp42ƒ @$ϱ{#քcP_0ĆX6؃Bw>.b|!-~碯7 2R% G0-@VΞno\0 fgǢs@LTofr*73R7[~rLwzgbP <FfǣӁ;6ہm2%2!-*J9>v1WYH , QcwcCӑP`(z}sX?|AHHH`{Bё`p" c@/\.``s rd6zp{k|S1 Hvы`7 2x!/ v[;m Wn*Qހe[Jq V޲EJ'[KjfV6\X@A9\@tt`& ?k_@%aG:wHBބZuVY|=W' EƧ흎U?Ppa#aSQx8T\+KYr#ª lTn-6[{430ua/6'j nAHczAoev-1=X ]@c{Q'hvOl)R7ey%xI绍h -nQT_|߳0R UZ_&G^O!O ughƱ-= /=S H,$YҒg/)ϼT㡒ڎ3@t0}}0VFβH 2N z7=a_?T_VŔhw?445YоtyJfL'5%& %8HHHNȪq3ZӉnҦf;U4'(9ad zf t̗3m`v8o ffv\E+zrII%c"D贏SKJL 3:z"A,YINlH5z1ךv}VOD$׌֚(`5="E#M5JoQmT 87embr52FyuӁ(Q{!Qig#n~1˙"#*ze܇{\ bvE,lMe)KY JamĂ\>=IVɺqb@F]jzmЋv@lgٖf~ǸL aBCK%V-$$nZ\mBUV3!1VG:޶|A/z",S{2mS.P*)nZsh,7Pb(A0bs:AO*-͞=3 /˟f bQ褘sgzmiƜaq-zT-(%: ER E,ơ3[SY_$vᒑ|#y50 k'mkL A} MKΞftd+)JR7R'dZ%D5 X)RU6H_Q*Jd) DB}@@ޚ0@9\"P}?WV;3#LNeH|͖5vRlT$sz!>qR eu4yg,>Įi4"}ÁCO$:7qd*  g9 {{IORO +!XϽڥVt#g\e+R%Z4!pȾV5`ix.M{-BaDH ҍ^D3m3ՕSc_xu@QFVS$c)E Ӎ "%:cu# gR<>R/BU#LZw"x\htg3 ubW8:Z AYP&?V0 q꟞:0!ZǀG `Ta /OGۮaf:My+&@<@)|3fJ x\@gUc"\Ӓqg{z- F_x Ny㣩),\Y')tEŴ$UzSTy%Ar,>WmDáj6w|0)8)Bή6K?MGP3/+Rh)tZw(w7.T) bQa"ŭ@RB,ւXdG0oMoeTITU3*gxw\E]>k.UWcf›c,I{zNjFpd\~NiOSH"5awe"ld=n b_łw{onY%zT9*f* EaT+ɰ,L1XyL'z):A/ tA/L ̚үj*DJ3HZD 2=H1=qex6HʰVt&V@4s>@̼Da Sb1DJZ|q%8RVPZٺjXd4x];@VϞ`uSԤ7pc"Q cxLVf{zUce~DI/ )L}pIM.X)bful.4 _mS !^\1!qV f7@}ܧTI@ELshJ tS .)Nb59U@4q@aAteh9o$83^8)Zܴ'Y,jb,d^ SWLKHSGo`n:|Q2 Y,RĚ)f1Ak 8=lQEȨ 9L/M^|>oߞ|[_tHI/AT]ڣ/+Uv;'BOH15pxrj$4]%!hBbj'v #(oXf,Io4C Z@[mH!1-,, fʅj_A +q°EΰG' [,,l/qy#iģM!^$F/3rVza^*:-S℄$OT^aS/T ug\sғ^NO_ovEǎKR6z"EY3[$c's39A#و^L;M &ͺ":۳4*m:b0hb 0WoTev 5U Tf7VU}J䇞N]YfJ7`4+z߰骚( {+5N&Dk8ڻEBb3Q +. +D Mxb5F%q|¸>C &.g_.m虚` '"L3zMM{w,}~Ƌ)^PGc+=ΘecƶڂFXo bڙo&VW TO:GK:n#EnP'YD +J_\P#NuzvT%FIuo8ǚvU ɢ"&z";1n&ȼ= {-ʸ?:ntմBGau6rhqpq=Y Lӄa&|}9|ޖq˝ƨƭdrǺ/s87*{e?a1 (КdYOf@> -itI!ւCjíGkO#qNqI#k:=j^xY5D/.bM0ы$sH`==I/ah|x&||GNN};ձE(?{١G|;5 x.=ܽx&Kɋ >kWSnLҒfs,Ka㋃OwGOe|^8TOEƆҺʇ[e8HV8hf/\@sǠĹ\^:tjIUT23!|U1t VzCF hike! G5'wŇSjPz%K.] KrЅgprqqecy_hZ_(X 4~H/?9-(2nW<̱#/[ͧ ۻ[pP嵵(4xS@~VXiDMEgyrsoV- 4і.T/߾?֤]?U ؝[?y,z}Eo~~_y _,+;?rk~׿}Voi>[2! /,P}o.ƥ2>뇫JKj$9l\Y>*k;ƧA/,^ Ӌhd]ӏ^OzUtsZMc[mJ1otyzqx}jыuЋ.%s'WVݳ"3x/mj.}O^:N{ ~uU۫_,|s?{oEO2qB!;@N!;qwqT4}gw߽:O,~ayޗ[}~%'&SZ,e9ꯃ,rb.%ʼolX8޸vrԵء 9ûֵ$Fi‚m4 *Fu0!;/ޒZ٬Y *ҫ|@@S;n kzGrT%cF`lD#a3V#>b2/`a7m" XįvHյ{@RL*ʳvjwmkHd"k (5_]r'g’rNoO[{IT)Q1%a-ia ©t cML`DnnA`d @F}ݔ-+am)@?\z!m_FA`ٰ|B Ԕ̄9;|w #uwZKR~- 3Rg[7Sd"</xFT)8 = /@#/޼3GG?]oXZM7xpp`ŨxBEt/^l9pTïfPG ;7pB|9|_V<{D1P}¬}]7™"CeܗvӏVuZ1v糭7~}MΕJ*z1 )' iU/&FԶjb6w'L*}" 14DYXf4,_B@8K+[PSlhlMFOAőIgE5CCPdg6bL?;jB=W!. ӭwf`,lU)tG6ZU-`~#02NXZWi^JȺEsGuN'8THpGe{C{~Y.06 -H/ !PUm̅m[32> RJ>N G2Fn?tqq[y\!Ęb~ҥ>vXRNpjԶS;8 "'pRNWmKZ|ha˜7 e7:Ţ[_>~G^@C 0L$9_ /{/Ћ'D@B@L$*...(((,,7"«]J2 P~漟&tޟGH}sI;_AQOu;_~'}_ N;_^h7=u,Td Q.</4ʷc%/%Z"_P1ҍ6l "![D6\ oz(&Y\~ޔv~\YXXP u/^NrK i¡`#>8O ,v_xfCF>T۳L8B Hҧ6uXxJs^`)+KDYٹii陙Y9yyZPPTTTR\ C,ʕ PxT;*^?Wso4g9Y_>aN2pR5ƯŹfjf7u8%*u0VuAd*rZK`a.N <`~.^]VNrڅ?y.xux%X#װ[4P_z'g ){q ^<}tÂ_vp]k(.BSak=*:t^tܾkEh6.lmև+m |$[Xxyx]qm|hi7\x53%Ty ~P3q԰;!%o8k51Xhw PNM'.>JB7O= /̧얐R]5Ah^[2/4a8Z (wi%j9F(4Q0Q`4pȚV$?\+M~[Ng!V>N 5 BZ&#Ís^XzfU.1؆FfR1cywӚz\MlKWO߼-oi*$||y v_8ݳI% r!Z dW9|㏡)zw̯!J.QDzVD@`=9_́3-՘R;&-##sDˤ&|cNvDY,!V.υ*HJ:g@p<*ǫ)UL[|G¸sgO9%!HXe '$4CJxq,^pBފ8!JJJRh)iiiYY999y2()A!KE"Ll"+eʄ~6p5Ԙm$xYXC'/?-RU|/+P蕘!=|xQa^j4J&a5M4,K SƁaA%+?C48_}2z,R(U|>;V?ï"+ 4lr|Bw:^`aq>B@Xۏ8/+r]yR{‹ggx0*4[SD_{]qu;}7~~*cmњoxP>`uJ6ƓM,3QZ^~'gV[Svd$Hko*/ixLsםeB~qgλ6<$UimkMW$fEotl .5+ q)콇u""DV&fq)|| $ \ 5"3 ~F  ` AvwÞF&ƥ GU^0Ocjȝ|P1\9v57?ֱP`]49N/ʅ(2BbQoUC 0TN)|*c/و ]*MԞ ߀}.r#'}?1ݦ`G !7?&1QM] /&$V5!r hB'CC~~Ux'?~LO>}/[$&&xM7Q*X,l 2a7A 6γ(LUEH`@4Aū6&;9d& '^LiὈBGx߄|; .)aڡvMz1# I+kG ^eNX[b=74؅US#d*Fjx!-p x—\~esxAV!/Z1.laZ̿?PUJV\v3m彂UE)^P&L:LMfuO[h?%mYm'ŏJ%Ko)ƞ/=Q@x%w?8ݷ ͍~$37 ̋~u ]B[-୙1̦ya\F B%sLj^F\K#ZɏaܨsT.sn@! k~OJ&5vVX7:lN6-Emj{`D@*ܳ!iԼZ"FWʀfX_ *Ӈt tfh^~fx ejjh*wLA)Ocf|6D^$ E%,ɝAǯ=,ׁYpHUڢf LUp=[5U咒l"`4ǕR6= Mlnљ"vNlleL;ŔލȈU]zNy0TԻ)A&ꢪ 0MN ԤE W JWBJ?->hԧZF>岜%EA? /~ߔo޼yǏ 1ё1Qq1I Yrsrr KK$"1n, B.€^y?BlA3dռAf2 cQ :pO5UhmPfq^^E sQyWyq/dÉuwYxޜ :@S<:'Ӂ!Wߒ+*͞^5a8ylO%ɡ+>o/J{R2Pi|Tw"] Zf/~+CDI<~,[&'≆-T*V=cSղО>TV R͸)y" h]gO(%Qv+=Ɓ]>`J߳Z'v{O8pƒE!,%dAÈMIȢh#;L?\B__;|>ڣe!ńwbD9S,,0uK-iu>-mͰp #K%1l(ҽ`-9o#s \B cpEcҥ= pUpbqiv++g YYtJؓ oF+ F[px%0滈 0b3, Bb4ޕɽg%F- i,{cc}E8I't_ֵSrOрr/QCܫ#^LG4zvCQ^ q> )vUAD@M$ mtBEג-|x52ȯeJVt&.KkFxjݪ /AlpW<{߿o߾"!>61!EzZJfFZnNVA~na~`"1䎔@ YU v"€ #&a֝:sίy5#E WM(X\CsT)*1kGݒ` *t< LhH<1asԊ*4H-fZ <3 m|~  q,QH$`3zc"bPltLR0?#vlBZiq oƽ@7iݐ9=^{7o BXR\Zv= ;YKX@2TNPcpP+  mShRh#EOK" ~aay5)Ƭa'ro$‹߹);@uxQ9ѭck^`eR.I%W`Mjƅ!^ 7)K{eEhdImXþ{Zhe9:2aOXΥ֢sM,}U{)twt=5`ε(t>E c%RJ^X bw=$\+ٙMB[]nؼ b4:xa$K9##u0rtּAI.uu ]~;۲ms߾0;vL0=; ,*447"&)jaoQxʗgE7:#y123&CG%..ܽG֦2sT21=6Jۧ9ةyl`K#@vvb iF;g?|} '#NH*xvGzG\]\j.= ]AFJyu11ur!Iư簩Ҷ?/~ }Y*[Ͽ1`O䭞ʼn&n[Ϟt q46| 񋯥\Xz3{y`β9-)]*[Pjp2ҴKi#gjh aDg憩>T~~K2+P1;H{p¹rZ/oD[$M.1f?Ӝ饩:R إ01>juĩS|ϝvgFDDD (0`[5'M5+ !^Xj^9/g{By+ca=]L'Vy'-)Qq9x钤o/lel@NLl~bTtN:S8Ek,G|M*<=`R0xJωs%✨#Jn{(~yĻg? pE4 ]4)U͠oh:o}v1]V?m؎BYW[>ޟ#f =<}4$$$44ƳODzͫ޼\෈~{׎ƴkۺV.+:9577sttYvݺ;[ܠā x $"x,f)'Z0LDT5mHd̍ʅGI1y06U/D~Jum>9azÙ(b58ײ4B.;$?fۖCǎB1 S IA!ЃbfA6FO\vm6J*ِ yo=ѥ9˷rK.ժp_0xnU?Z?m3U'n*,p)3l(h^~/UE@SQ%I3:@a(-2*EAbBtTd\qLżUJ]< >B(#/).%!-WPĘ_2SC<hX?<*9*#GrDol ́ $璢 =1+5l=$TIQqvFBBRvLbO>ظ4qa)sN>)ܗ(%)9:&!+'WJ*b#R ^hinfVltLffz:Ы*Y/.)1M&U34\c(hS(R:=- Kb2!J%{An2.ܲ;%1IYE2 rtS%r/j] e Ń=z?}嫷߼ǷZK玕+U4bA Ašcut<$Op]@ `J_q09_6݀-S*WGp:U5~̔cRQПo"Sf?4!zr]̅z$~  z)B*N OWQ+ɲPɓZAtȈ ݳsƂDooC24!sw8}޺|xE:՜.[`= 6Rr EYJQ!W8*=~$̲e$ 9DHi~S)2(g1:x#I1"nQmI tå,RДd[&jVyX ]Vp./7s!Ɵ7j-`ҵ݌zU'NZdoޭ>wc##ŌլUHg*tx‰Ǟ;ͲOf\}t>斊Jb/U=RUWO~VQQ ǤbCeF&|5J<`F7pZkİWR 8r5Ŭ|54FÂoI3:Cneճ!@ t>\p.49Uc+N|jJ z@ h/ O|t>oW8sYXRv?+N?^J u5ˁ nfS !\g(쟁~onyæp\PRn'>AȐP8B27JPi)z;[v8?1ːK'S G rP^'NɆ@2VRfqyvR2*cjR[@nj>2vF93R~{Q+ ΟHRuY/NlvB@Dnٳ52GYsjٹDZ Vqu)jxZ{ދf>sor9.J^,R2JԃO{\ǐկg̝内+6{~ۦl%zy(AB=`&ߑܖM N.ދc9jdžú1qIiY9g[N8ߊ?"uIs8r4m^/FJ,? c\SŠ~UHƑ+oDG)؃2e83gq]le;.ׇÀ,+, Od~|%' ~r?劳I3  jpnA.Ą_R Wu,^ܧۣЇA{x/ <ŭj5 **leecii ҮBJCy5WQf5oݴY+u9U414jҴ32`v8-U@΀W_ #rW뼑ߒ=γ)Q3&:^F8EoU:~Ͽeo^w)̍ )HЮg_}VU4} g5sO\x&|߻uӦ|Kb(AT'/|:eϴs1H3[1ߧ__~$?ۣV owL)dO6dh&MkTsJ riϺ}]M9<^p\">jڌ9Kg =oL9f9~V,(uiXHЁ5kѨqӡc' cb Ef&֮^ݭjaFZ}n$L7 @/<ի+߬'G VFݶ8)aX¿Z&]f-E}1SJU|n^#B>~6-(4kԸz5}>xAS&(RwЫIӖ&L7o) ,#P4?8ĚGV뺶\{)@wN scz_ʨFbm7kj\M}L;{/ }wo_rBh[/>v_lz7D;.}[5!H]:r賹#Og;m{\#7-g/9\B={͛?~Gb|HրL GC->/f8q6^Ɛw8Y[1ϙGrbs$!NEh 4"/>_q+qag! ͊p4edҌkXGCUSЁ!+[/N8%|ՠ4ɧu#HXj6Dx^29{Zw~h=zjg/xJP`q;w 80^ʥuw}@`fnmnaѽF/A/ [qmwڵ[nݽtټE W2eԸt`-ne> t }s)ZQt [8qkҥm?By燶13 : `w9^? %S @]]ڙ^0v2%)O&beXLAݿ%[4R\$#Τ||j&/L3"&\Rn:5th%e-+֤҈-`&f4 %ЦJR2E 6ISuBdGn6%P'An̫;昋gl 1r`"'lQbU+c /̑{[} 9BއQ:h+E_K3ak4Kd~{yO(074-[jGJ? BZa)JSք}EENEc4G\wӽPS<2wS-WwӠ+#nV6ojR{Qt֦4ޔbKRoMUÈfƍmo%&))'/[TZI*  sSoK&Qye&QT!wtags[ 8wrk5nVZj6عc/^{ޓ'Omd_rr2<0 ο4q"V|[_l "]4x .Q|*aS1wI* |5c9a.ѓGǂ5˄4NkL p'pKIbS|BGdl0WxiCV j89`'zj!&AR;¾@1 ^/nܸx]x8xΝڹ, D=feZwHJ΀3gN4գfM`Qتc0{V[89 :$a ز ?!bs/r i!(-hp;qitM(Z*@ 4Ӗch72AE mxl^g`o.r~Գ3^V: } /Q]h7aReKx]~RFRIzy[(22sB|i1dC$E'̷H`]]{gj:Nt'fF>H[ Q>h_ig.&He,$aX7Vk}ˍv:4'ܮ:Ǭ׵%bYbiM6$uJF6p֌g]fVH0 MMUj`ès @애 '/9qٸ1sݒSxsM 1 )|2gɌ>xf.sĥϟ:qC۶m[~6ߴgϾc'ߺu ( "eXSy-<1rVb(:hа,pλΑ?>&6(/[hi"FiHXA%% 8[,қN1| Nǹ pUHuW#H=,ϝ.N!;iP}:kn(UFQ{z̷p.@EV/' ҞjA5q,>{|R*tS4%0f3o~.ڹn>-jlJ%47v_sىܲ*vgSZq jt9KFG@] e&rh qOn_V3_ MJfZΖRB!kљslhAcg2MK`] KC6s,gk5![+! qR;*2!uJxjXk֧ԓn]43ol@~ AG ;`"=K7$o*ӰQF ;Fy<~%4d8։ ( [{.[ʕ+ O|v`ch=#c;m۶}f+YX8XZ`ae[Ү<&ۤg~5rku4jԦivԱ{n'N9|-<=nޜ %Ѐ^ ^ ^00‡IlUx|7o^s'> P . \<b?6W?M$ƃ(lLeU 39|O\_P0_+Q@X*4lb8(@xj{4qutꃠaxb;^a^Y-]ǿچ?g 790KLc8zJi ^Dd]He … ຸv < - A@@4ioQ_>ڪUy3rfm,[딙_TK5btry4SuƝ[4жuc'@kN^nBJohab^u] l\0=$O FSar 30>js(KYf9&C_ lTY=-jݻ6넒Nd.T7k6;JiIFh^2eA5:JUIA!Bv1k8qgݻuӦ&TJ5`Kލ (ID?ZLB'Y]1.RaBj~~m[X_(WT)Ъ%/Z8)2!N FJ*`p0~{SwJxC@!PASaF$++|src6BR0O]`@~ ôs C8FX-:GAXqLM;N즂!4u D6 |JDj_Q+Ȝ%/?Yͨ TVox:i^;Xxs5?>K0tYVmvW)]^:o̧ xET՟{h;π;w+ ^XfP J4|"wz3|cv AA઼qޝ'ת! L7T pd,엯X[90r2p4)oaTA_!ѳGo\poVV Z2"ALFEw.bY^{7EtʍARL16.Vv42I*a0N~VS&Ēϱo)SM,SBR b x\FxU#eG δ%T5SGr6%Bhn\q2UHBI p4)o, .̳4< vzre0Bz\ }Bw5erRƝ2P@Bwd/"l!-Z[/}[]OY@ &6^ݣg}z߫g]8@B٭~pG>Y:/F/Fd{l)٢Wz ;Ժy˂n׸Ȥ贸)qQ?3T2'. b*erQb6ߣy` l 'E*'?0k\!==PPTc 9h84|C_6z%{ 0e6 CPlI*p0"艡pЂ +@ϑA=l@ |Fir8B, â$Q#͖h`4X$|^\X,S[\g1OA6kknGx dWo] >|N롳\4sùduߓm[B ?:rŧ&oyz8Y۔ {mlřu5"ʽ*D4YUB̩4gJ%MUVXH^>SsEiH@4Jb2aUЎ. >k":~Pzk;G ?9};sZr}WEw> A6$r)-PGGcwN9V *Z~=Vq :2.E䊈{Y Ey$UrE$ְA d`(iԊ94/` O>}IH~K~q̩FPTU ٽ@*PՋX|lEo#IbniҴY5kVmܸyV;Lm,AZ},1lڬŇ2PTT ~@80~/"=K|c Ew N" 2=zș7)V_̱cnjt:ͪWGWJi~!_$mx:ic)K&"[IU씘Dbҵ n6nxoϮZ#N2ۨ)a,uY>wj0*irx2#<VJɓ vz"k)Y!Q|xc.Kp Z)u !aBC\ZF㾋A\(~\116_ Pd=bct5< 0qb5]98>OK<72VD.V 9͟vSZPcK\(#;dӠd)C W L*0LCau` ^6uc^ci-?&ZkSGܨ2>3_t䆖}'.۰W )5K:sS/_qjiny٣^pCg5[:SZ˞{3Ha}dU-}`K܇yI@cWeF.'TbE+&oظ^j;394'o h?Ml9 0l!U E^< ҾSgN;gDY&>ucN9Ko+@N:+zfEm8wk̪)@QxkV/ڽ[U.Unf洹a^NDP~-&`wE>kJORjy{ҥ{Zj73zҥ!jJAQ2`$)SfO>mTY>pee*6qI>&O;cɾ7ly#HՍB_܋^Kׯ7] xn޼FXFI`~'ٱ\ņ T{t6VVQ oI hsqT h2RaDH@[NN`g€a dh<غ::ZUء^hͅF @7;(9u e͡нA!XjY·7cc3t] CJjԵb]vy>C rnME$ ݪuZsGl-I̚pDdl/%Wk(rm< P>„rYD[LySWXU_#L֩}3U{JMpYFA,ܸ_f&woe}tů3_a;ȼr=p@Y˷Kغy'цrs56$mJٱ~)+6:ű!#,q9[_?ʢR|5^ M9$f<>o-m`ߒlDԤrTZk\'3ǽ.X%رi)-YXjӉ800bw&=95MFo?xm;}$H֥Q0 >y3'O;nbV}O?w}R W qծT>+ߚqgZm6ĶYjգcUxԣa_r===ln ) 0C@#[P ՘p<U{$ADCF v8<g<y)}sIC%fZU*74% u84p,Dx:xS\\l$q4PG/$\ QZ?%;w,>ҍLc'I3!K\0Ű<]Cj:1q7[s9m:w/ bGhM-pUveRvW3X)b -,mfFB#^١R9yne rk/x ́d{w^d˗/Ch3grn|F3ahJɹ6@h2AA`:#X Sҥh/L̛͖ { s>QçJ,G#r]_ GFD%$d1aW PK M2xdi)IAS"BW*kպ` -6!s\Rr.=5)E2 <\:# V[HiavjfV)tBe"(%YI I)&4BRVRCZ*cyaJ_L2vHUCRBZAN`Rr*P--ƮE An HFVZptE5闗W(AqoaJ+LLMRӎH 6B({,U jayրĺ8`vRH>z\ S%,˜7Kv;ut˺۴[ey>* V2T}6`Ė#n }V ([3g7mԪMÇ9q=~Iē^(|ӶM:z6kIj}|-)75_Œ@leᮣTУÄ㧝t$Ƅou1\ΜRE[C!Khs/_pD5"PXS\V1A,ϒ49.9PpUK]=Aθ;ڹy֭{z4 "_Pʌx/v{\(=H;i/lyD< wf(^ ,{6 x͚ŴW-33@3IԩUtzU\);o9Q䋨f֛69] 6! _ V#f⇒M::qxӽ!Möw"?$M[.w1#l=t& DtIW?0H,)΂6@ $n^^^ AĭKn}&V6ʺAOMj>02"€ċo/\|l@$/r38ez 9*S_faTqA"(`;the[wg|zVë5ާ >mG1m7_hٗ&/x^ovDu.îzpo;zWnB 3FWe{89Fb$`44f7w>mE,43znSQk*eN~9|T s<3oNAÿ;,}#e_`12)U|QNQZ kS94g%l8`mF!ӰXp$4\FX4!'B>B+ҿ8H͇/AA8 *xv/1!VܽR7**=}!5?I;[^C"2~OJSQuc6 *~TتNBzJ8&AV0UZ$8彻5;5 FEKEqf B cuqL ɿ2q(ߤ{y[V\wۊmgi뻥%=}3R`]]`\2p8-{ Z|58-> 7HJJg dQw3g[SNlmSsng~r0dtJ>ZG Cd" L!S8;Tq}K5DKj$VB1ppS*PH8c8 b0~9,Bʸ~rЇ0AnV$z)HgJ!oڳ\<-t%f}ģ)Ǻ%z ̪.~rm6KXyQ 'YԞf߮57jcw<.Ġϵqmo^?| eT\w8|'.^̘1 AfjHC/^xh{ytYuo5Ŋ~ZdPh0y9OjU{e*=l3bo9F"ߎ揠5M,4_;RC~i'Kt۹5sG>uiJe?eӦ?#)gCW{g.^ɳz1Cjԩ^5nyXN@/vYacDlfAgAOc3J,M8&K(T&ղ7!`o[NLxa1ezVܪy@uߩ3K.E#z uLPƎ3kw1D*dL^\Qf uʲiD:7nҗg✕IIwI 7ka!(nQlyP:tCŹ!;Z@IJMВYK}Ǚt?m'Jz+:U˽ԪVX>JW-`~%"?x &u^jР" нB7gg *!Ըk5$(-L41w}vvycH:,&js Mf?q_!k*tfSYthΫYφ:l؂dԫWӧ9ŔT- ]xRW8'9:%>DJOϾcM?rU4YG+T[q)xlo ZRѸCW0!NP*|C.P8JfzZ<PbX\?oc#C  cv;kxQd'xu98^'? *6q æ|&Kl۬kӠ#G^:fW`y8<  :y~瞃 ߮M{as.^<^}Gп kݥ_|jA: ^ߢ\_q{rDžu w<Ʌ2e= ~mb|1on[r3> MYxJ RhPI(LfiAة'~OFIY޳zYN'q UA>31.ܱ 456t As$z{xQW1`oj"Y_R3 8@r8=WZ4}-lg]+H*l -N"nh{!uT /.CG g`'l 7=ai!9[^mmxYP0-fgf$0;i})z>5n ^Eી? 5DCL̟??""RI䃫ѣGK.N!}n/)Lm[{seZka5^t޵&34M7reٰϢ}=u{߾#ٸ_\oؓƍ:%͏@3sw6~M $o=]F?_'v66&)+~Img7OqҸe]CC6mYFWb5vi.4ѻGs#S@E-9 (<`=hw u>gDqמ$D&ۿV>}r>@$f|)Ak 7:ڏʄ\b ז -I / 3&B;O>M@8f'ʵZH_Mǰ⍰$VH֤سhgHJӛHC=ˏd W6wׁb[%7J b'vo ˘ z}ٓ<úJ}<`am3, 5`%4>Яq̨՘N`*պ{c3c?6^uc g|3bz椑|<#JND 60A'w]pd{qy\('̞P0XW7DSF26j_1a BO?hVu(C̫XgUeV9vT@ŁXgxEׯݿgۮݻ{ߙ;t_ڵ7n }:zxH5u?kEjߛzsמ&sqJ.]W׶k7ze*^?o`Wjtz-Mj_E0b pi$qaB[Ȕ71w 7¾H NִELBHGv!"lUvÌS8ex7|6#KTd])B0.9R('q2LV$9kѲy6:kճr">Ӗ$ֱ3nt?AaA4JbX{G Mp9Ыhϼ zjb>WRrMܦ+p|$lbz`-ѫW,J/W^S|`8N o'^]El,/j«G75Юuñ8^04¸Z Iղ"K;s궳bCU>D{=Rwnmݺy}ش}#q-n>V裇O_?w}ρ5跲+૨sՙuf<Rn RJmTi2{;w-9x,.c RkHjdH:` R9O֖Kj)52=a(D{Z"y$!Ż{!jldh`odY+WLޜ:z@FEǶk-"߼ i1o`y.%*FA Lg+У*&C^pRsp48/*raڃEEť&{/ y}Xdq㦓&M:u*O>Wl. B#rU[w ]<3ݶvi}x5je0KZ|Ê - pkc߲SLB2 9tx-(=RhW Hu]GV@)c8Z>RX ?(/*k7| \9 tlr^yq^;Yqp$@x θX_.AxQ! Xʍ 㞿荻X,<ʰ0C* 3shRgi6,/as*=PyБÏ5s`⊳~ǷmzCGO-]Ƽ'ۿo߼uį0evnӭBmi4#+-fET13'෨1v.9qS՛ 9vgSRӕ*X^IΗ>VCl91W)]re奐g ȝ&51u^^>p 06䈨"I^ks|b[cf=iYV25##|}4!!Ӑ'!O-΄VS׎g!6%ɴ\ vH3F=&{TjSsV. aPy8?:m!cRV돭ԮѽP)Jmel {`H񞭀Ap\>B "LuvJݾҸ,{%($j%{U>UL. z>3%W!oe3*=`Jf ް{>`]t-|~վ>qVtVC0_ /JEHL{DF^@ KO~(d!ַ IE?@KCXvdž6\L%'S-k:`i{N^F+.uۦA_mhۭozv [+P;m n y_ [J#S2HԯgxAx ?UoxNH{Ϧ`/N$^y_Z4 L36@1_fXM# \ hS!> >Pa_ & 80_BC7:XñRcyB]WAB^ ;㏬a-xa4Ըp afWѩ6>]p|}s7]wڎ{o߹kמ- 'O~:޽Nx9K+igh=9}Vcjo17\inG۬xl6g SPQIR;GQQLdCL^ud}, t&$ u-MlF O7O$Y/)%P|1} wg!; 3ٿ,v-jBp ^=+0-QtJ:͇Ba=5& ul" (HI0ݵ1yM \')L)~xE1 ٱU0-Mߣ%%n\;8xmR ^TȧM+|pJ>>vQfMDJj3va >P>DNJ f iN`!(UqQid K*h%2 ݡfvO_Gژ8B+^X-#=ؔd #?0Px^JIsIQ bYYdL 98])հyLV4WkHMὂu( ^T;A^(z.Pd ۭPQ`PN#^_QIRM)iUhN1]FQp!' pzÆuPRᅞȒJ>lD>*ԨɣkY4&k +x?-e^mP2C=~jx]ATr@Jj5_}+*iKi8:L5)_; [E26#W7b0qߎF#ϯ㎨y&FqdU|^]x=OΤPaQ!ƕTaZcy_s-oұn+xhA{ܽd㡍[vص EsR3gBacU|nT~Peܽc d 7܆]2\^wtc-{} +p_۲Z T\)J9[R=4ߒ)8ooz/-%SAFPB{&gK r8 eF٨ENӽ9 FKm&co dȢ(IqoM$ N.6iQg3kGw66:V,++eHXǪzr)UJ\E"Z0Zڶr ԪۘBV vINVBjoNzH>-8RM܀!,do=ȜOH`ݙٞ}30Ao=aO`m"jfUc{|=4Q"Ziܭ%ŽKA9PA:  U/0  ѕ$"\B#30 iֲ3‘...puHyAV*M_QC4!p'ڥ<%o㬲uC$"5kU+iR fKSI$B\KB%ɵpHi4 n4H& Z1Ddžn"8[ Fy_:3h#prJ&+hXqȁˣCW|5@%mzjʍ&U.p(pO^+6rmZۼm-kҶr6ﵣjMmxiܵBggN_tի}ɰq3lwi:h_q7*Ui-9JW܆_nC~dR5qǂ4-2irߩ[lVH$I١1YP9Ƞ_x/P7?JLlETL_`h_iϲ&VXM<=, +=R"In1ȽL"L+Vwz0ypyX$u]*C @2&W(#xaR!1CB@1 ϑPj7;Qe'/[ganKEWYV^. 3$QUm#W g '4̓[7"LV })ct% -f:TԵom{eВ[cYJ J.ǎ {Z%P?/*{j@d#308_n?:Y̭]CG1sbĸeGz)"C{y 1Ua70J"hѢٗO rr{N@~ ~*#4aS\K^~3յuN1dYWU(A:9ټcϗLYx'4 %>h"cflwݣl޸M[[Ŗ<^#&}KLx$#ƫc{,gYa-UQiiFpy,_7+PY]ZblKM `cbV%%W\ n6^ w-6v7Æb͗i86t)(?80%000&[ԙ+s*oڽe k5gv/g<~s/\v CH9uF~f5صm#TduBrF,A L וdE)i IY%6 aqP`g(4jp 6t1bj|%9a3 p^.SGcW1MMI_aX Tj*C ,RS<`JJ󀎓+S0LQ橎ώ F%B-7W!D*>Qu tNAv'` 8tTasFʢ!Se[ uaβd;dUE z͜R̘F?4Ch[oش8!Ȁ}{}۔<*@Vrɮ=[*Qs槉;nHЊY mH5=X*B8@:'rE?/d uo}͑$oGd闰^ry ODtӀћ70N4RAaT`TmYf:6e+۰g;wX`)S':ts/\p*yjzOz-վr]:w_&X:TS~CGl۽rӊ !ǁK pA?U#h\0*))Pq@V'eaK렕{0{sx.0*,Jj*&w0`TTR+u?6!h^1'7Q!UM0arx^C+"dȁfPfmw{țf+R,O[hf KبB"0Ae(HeʎQԋPȷ>䂀* o~0u)!* +@>ZpC Tr{?q܅g/^z80@޴[_3l[mٱvǖ.9mm!jume+BCdede( G] ?! gDD+[jO&{؃TѤy[ X[˦zAdU0p!Q074zI>a"g I4%UJ* =J if4~2K¢<>S8*|9^h(n}EUQs*X)>{YTqӣpQ_U#<XCgX5BCeA HB 2HǎyAH99 4Yh,#L LCUPm̷xve6#lQ&BT$+35##-nX rF~^^ NgZ[N(! =bn]ZԪ^^1cF< "-Ϟ9OC{^ݵaÆK+]+.ւsgtޣZ͖ ޶McpSx]+Acm>HW}&ig1#t޺~}LTl?^UhyHz1|$k؊y3:tѰQ!'?|]s;-0Дкg>ky3{vkވ[6{yΜ3gAl6-kڬAvflVO;j%6fl9oïUNuz {nD)88޸~o{UínfVlF ˓U~{vhYݭQL {CDFKfN;h@rZ쳗{jQafSf$e)Y jII#{<@Eg&Eҹ3GaXg.U5if]9%4q-G kjҤy&^0 ,زkWHH:c Pĵ']nӾ vlݲgӦ]@ۺegx敫n܀ipQaV}YMW5YkQcUQ֕{նC߹sܺ?:%wL%nFcɗ/!ъ0*E9,Iynbtc<\*poKx`l)}\*Mn3ݩ/9]{(JƒC`QqH΋}#'{CIg8?%KĦ;ϲpT3*<ϓo,NJ =_ /~ H}" Ϊia^ l,G rR4{(3T Y44QfbLM.(1;RH^>fX';Aw<…WBz& EB49c2Vn>"tȰ@N5㟚m'[`ᢴU$kr#^d%u^ ׯ!'^5ɺiQֵB@ļR;Ujum ;s6{P.U-8xfO "gиk_p,J.#? 7^O[aռ+ϒYȇ<Ɗ!W,ʨ"ϝWil}2#WwbWjw4pP]vD<0>tP_^t[rr2P.^ @_ D<-[*T)$Ʀ0.A6!CqVQz3IFcif#yfʌ򴦢:mXQJyb 0?U2vdܜ|h #:HQ\9$n ԸwPnivC%հڑXްeÇwZ7ՐϔUv}- Tz.9YH`;,/:o)XLf୳gF&dǶ/&v[[>hRJxzcgG]8ߌzpZ:Em=9v?{k4x~ed<|WN\?2r@O%;.2d*"4 XؽvFIQJ$"~`BP(oi/n߹M`U[&xDy=9 [> iݰܩ_E4oNJ90cF$ g {n8y0YQe|ƈG!Ftu[*3m0ΐN#I'6MlmڼQݶMqBK" g@3^8Tj~w2DƯ/XW1)1l~cAӰ87pF k/]{m6nݶ}5z,_'OxϫW߼yx!\hcUӰBo =vrӾ] >|wŅ"LY&Z 6;ќsx悇)8 iO24OWXEE@zYlDwC.1U2{M4y_ ؿyэs9@9 o(0<<ǫxU xsG9ip@FL&s0{GЇ6l\2A8녰0y=&O,&X8.&X m`DOA+ŊI"w8`E\\B&`‚ԬLge"Xg*Sɥc0jiFBv'-dۆqi"dF[ϖU }'%߃4+N"Uhįor"퇻 ,<*WhNwj$#T?{=ꍺɵ@Ԥr|tZ}B S,+g.هU)J:kP(ǀVpfza G}sva% (Y ӭN WQ |Y1u"5DZ 2(4#/4 qVb:<ȬZiJuIR*gcF#(RvlZ,jgJɄza`\9.CCEq̬oޏU+'9)=Ͱ+Wm:G_ٓD_C (~3hytfLC7z3g"q[Ol:+ŦW3`GGvgؑCAće<" _/~ >2ׯ1>ųgn;vhܸ1Q GMN*__Zl'p8 l,f[JuBBx~FXceTXHNJpA^KR1qRNRB邒7A| BUa\=Kfy wi };YU`7}Jڦ*ۓ$j`GWpf{&JriDGE&G^WR]$aU[zJ)3SSCĤ-2J-S4ѽ'zEJMK#{y3~_1}: ymB3BgڪĨ-GKKs1o(8kP^5H'ҏbN7uk>ՆY8iHC(TIKWmسn nܶas'΂8{ $^zͻAvr)t۴C>.8o޾[xJ 3}M2_I?*: (0( U7kў"^0J׽ia&3ݡR1E%1)7<[H~5m:̼PˊM2to^٫toڹv [7ۼvek׮lرc@8ArH]v[7n޺w7-;N6s….{wo=0}x~Wq/zxX@p$n/޼ysNкڵm`爅B T;W<s _ڵkM"--EjrJ:MMNNJNfldT?G~_fI=`2E7@N6-5w4tQ˕EVF@'%iʸ-dF+Q%ֶ US$3##kk)p 7` "ۜ}I=S[g;08M)jTcK:4mҲ5EW\Itk*4= {͡!+R\9U+Q m Z Q m3bHD`h@"T5\9?8XXAQ)]]Ի)Ip8Z@}\FF-4Q!)d>svb$ I>H^X@ȴ0гR(৔%Zim~,KDUp:[.u-HTW_Dya7T;5KJ w)SӲ_|e+qm2}Ma.Ì+wo8f̄V_aM[o ˖wرG3pWo3{wr?yӗo?}+(SЈZH!T;"/{]]DzoICOj i$!!@H-{yg1rdvvvnf3ϳm@.G&1I%! BVj2X;UfU$$!o Qq呬Aj/5 .oi.j1 íwPLDodȨMWfɧPźEfʪb&]N'6E-x2gir k]IA€*v `l.6\t!ßx.p֑S S[4jsw۫偼h|U^L( }‹onN4s&-n26MߵϤ/f_SO>!SO9n(1b3gB#qvrR)Lhk_-[ղcYnk7K_7m6eΕk/ZxӖSs].l saI"Zm)md>A8ݦ"/\S8ogJxI>V>9!`~J1#4cfmTLKf$NkO*R6rg2WX #a۬}tFxQ+X_^x5x@x‹C&N;[HyKQdx uĽ_OX@IBB;w ZF+/N%M7 gWCC駟߿\B<t <'''OpmKJT=SйrFÕԍWb|_Pku]>bK+Ϲ1OL-0 ?}Υ L.irۓ` 8IܕS71IF>42H:bot>2!! YiR oi_YUr$Fo lSk"*>xF^ x׬!NDQ6Wu|RN~ꃦ Q1#w^Zu]@<ʑ*n&xCCUe30pS.O݊@GR4Sp2!x]U1OO<>xnfޒJܰ ^a 7g`d)I? @- YMl=U G~Hw?/q \I 7&~.qȸc&U1yyIu;OE%`c^-:>ew}3owT:vbȸ'M:mѳf́gl\R VK2w^ h%+VNEY;H׭Ojچ͘om5,J߼ `*\b$'!kx&#rIBUN)*{&qگ)U{*uMj^A SX~>yA*Z/"E3OQSa@1DIt奔ƚ&#5s|Dn =yQ +6?pJFCMiR=1+ ы[J[*?2S jg#x|r04uuY$/+/Gv$~6PGkhq):"ȕ=w' GjE(:6Ebw_;QV@{ fȽ>s^v?}A&9k)cllG={i?!sа!SQhFd3gϛxx1V]t9UcD^xvi@X|K7o1[xj5lhcb WL#3I6UT BZ3o!lTM!b~nB!f,M$:9q''d, %$\&4@ ZU30f6ϊ #VUR/,X27۬o*fn=ʤD:UUqIMS oCȑ<&L\)9DI.I3EְɑISW޲! 1ߤG{Ŝmis.dx!vx^ȡ :@ ` ` dI{E]>'?!0e&F|u&C8n*U08qi!PUlʸ6ІP?` c^6htժ>cEYy./BU5ʓp&~O'X"H4g~RsRnkiW#rB[ŇOwg0Ҍ^#~dFxZj?%sjo-.qm_VդpWǧ5-iC{2ߦ}#+zwV{y\ ոUv6JͯÑq*25c*d@O_r (5sa tF);ƟރXrEZ;Ox| [g˭7_G kf^ڠ-sNT8tQpxDM;oƗtlElF@'[!Zű./=!E-+[ϙ5e-mAH吥peng { \nP8ށll BF2W=zOmzX)G64*)(".g6E黑V~njDF(xV_yU  jSE 5mϿӳ'+*Gsksf| y'b [[w}{=|dpf׼50a:qhC?5XEL$GMe vN^\\q(rb$ nAshXhW]kQDj܎,bb%r HH_hAr`T;S.3- ˘=qD)!M Y)S#cbgMNZؔ!d¥/G*d x[*SJOTrs^G6>sp j,PGIc WZ#$UTRESxfJbT m80w5Uzk7F5i^nj8% jdKR.ra彄u4Êrtl*hM$'C4oق -RCf¦52C K&JEX*n~.Es4~^TzE!IE/{A"q{-mօ/6Z,Ꝑ(c {]/$ț߿w@ d ?$74e켡N!gU,jHӥ2PdbY ; YSy SM$3n(T z$tT(cۡ;8$t4r|d7j 8a g+Buд]QOAI&l2G{z$G hXi3򿤙Q6puH*aSFaV>-nd0C[R/^uE/<%Ő>=;x.aS;z8K%@Ȉ4;"2_A.VBsg`0\%x+cbfΜ;FIIɹH,L>3xY>Gu}*er"'=]NYm) 7zKoڵ <{/<-sВ/|ڱCo]>)|Tvx]g9n͉w5q{{q| {H[j|ӻM{#m\umw4dd5&V[Lz4c_gh{y.syp>[no߮mw׽w݇\K7@Mı8LC"êM5."a" c&Hا@!:.°LuHR* <^#* U2Zu&%Dd EtʑkO,馄49R8m!Moc #4T-mu.g ̪Qqc‹ c=!AQ%,jWݘvX\7I&RͷK:7ɩtj=ϋp?EyZ\8Y+SWa^dO00-PEH4ʰ?eϾg+0/VKɲa6|?ux9sڐ"&*5]m7/ 9xY[a)o<Қ`2b5fO)[xmcW1A^?H,4 YL3 .;SzH94ėĚ>g.ڬ][yAr|78Ħ@Q٧ؑ[txt%U:<Γ{-}cz.oK켢>b\}U꣇IsW:(Zњ9?bs0Մi2#J[0x!4 $P@N!'s#v6ؙ `#çrcB5)DNJotrQ;/x1[ I†bWJ"x?A<~VEEXб@})Ls[x|*<dzX&\}BĬj%-hb҅RMQcM(+%t1U{ĨlJ,_+ZI:zR27  YPMG`t3+NJ)Zw.4t Q$@Mw d'77JH-Y=GBcLJ&Οr ^DN\̉8mş;:# 'O6|$"&NF@ȞSE0 OP>gbL4FGNҷo_znݺ9rܹw _,& ^4}GʳfJ%x :(0l6$FU8>UJjޝ}17)gAդ . ؚ9WEepRjkoޅ5d#;Jl]P x6ѵ_oN{[Z1Ƞ6Y 9Q4xb{M"gV8W+ `bHd1_?(xϕLB@cQVGFE[` ԥKG}DGfp`oxrpMMx&vUc]Pf 00uOz2s ():^hbX㗵Ƅ?}. ~5?|zsqp +0}bܗP}տ8zygA<Ŭv:C@G*;FKw E\,YCEEow/Cj~F#ٰ}<'*ۡ/|Tk/§JqTYGjLxJi^RiDUx„ϑ^BOy+থ1xlf;+ϴn 2H+Ṉ{Qn>V?7T=*ՕmmPvӃ]< H_bwFЩIѰpa $G/f&:~ %%sx9Gpc 3d[ $~k,@d8D8:z׳OWH_H>Ĝ@bdSbu͢L\-1[BJZ͵|@&14' MDCw[=I PaU%Z 1 /V+֜Z)f[8l)3SW$ /d,BRDCG@D E4dpt}ǻ!3Pfϟ6/ګW'p9H"(&9TUAjyN4; 3ңc8kx͏3'0>>SV]wn#lf]aJ ^+Δ!ƧN.\43{[fm{u|AS*Z@Oʺ]tЅ`QK;.`H #ZW8Yx`zH_qiܞ*6#pQڏƬؿ_NDov|MRe͋Zv wY1 @#j~|N8s~- p/F'{$]E$a ;ٻi>׹ /sƃ/*E=8{?ңWTwNOV#+p;! M6JaCXծ1#+,X``ыz2TذHK0joCƦ.o^s% fI.ԫ/ܙQ#m6sk$Uv}FB+I: ? VQJbJ 7 *5⸓pO¦hw}< umtLM tmC\xf A)Cis}RCXJpd|ND'sҗO ;/6kشd5@x:_VgBgZ"7+io~ȋ^|/sDؔ/Y ؼ>vujBҼؗtgxaXŅ>I`B` B\W҇f? bpLu0x%tV=CdeDc /'?iw"EפRASE_L JlUM$@2INћ/#y@,*`yRJapy"ؤ 3RRW$^lBIbzBxq^:I$ (~@9}x…h̘1C„hŊ`WUXX<)+0;~ { OיSa%9'b8/{E!9xզa!!3&^bY FO2-qAB2tnNy 1 qe\RxceE`WeOPT^Htz%q>T4I RfHq,&?p Vx9|Bt[#V@͒jTrTC,-{}XY4׳H"&a *qIcgj ,gj Hj¬ /C*!!5/DI۲. z7'xaxWAߞųcQaBEMMؚ6nCA8ش6I1&Gfjx@F I۹D/ٷФ0,V[7D-Cσ#MSvMSx5v)fk^y o@Ðez^1831zW/yQPuѲ+լLcEjq';`o PƕDѷ:lN)QQL>rjgҝ N)R*F_7c xQϯmf݅j*@;]״1N}30 8dL 1Gwx;70=rB[㺞) 4` /zau1IFA8}@X5e9e4re:ocrࡶ-~gDz"rue?з* 8)eQ JF$E.Z4mÚxv oߚGls9)CBFLaxpNjGnz-Oլ.EFz]Z6@rdE.taĝd9'~}/zG޾uGl+O$*ãZʬlxTauĩmK:rY{x܋qtЉUƪԊoIYMQ!hYkP zt {ܶ} #8U`ʟQ5GuqvA)v~-[Z4E|}aq:Av*e 5Ș~Qũ{CwdA}l<Wа1evzUnE?Z^y^Cm8vB4݆քNKܫ0T/n羓C&DN_,f:&^'̶rv'^R%= m/%|lz|RDi! aN]8t~-E9?׫ptW]1$\ OM [tƵ['$x3-a+bSƆ9)3Hc>SR%A`i{˽yh}\J{"I9HWU<5nEېH?2wOxFaRETsUuxK՚B2 tGDqT7T֋NbKU' w$Z_Ǫ$k+HsE5ytdN`VѦ )^N7=.l-Թ4?!U]{pDD4TFNE\D e(HVÿhR8QJ͒F?D ;}M=wATʨ/vޚ6 qDK8.,xͺ[7ĦF̝?%bТNȐ՜9]}~e\:qh)vbwz5HO sY1Kۚ@PA2M9<-0*y{Et'M7sBA<FqEc:,STOꌀAtE@'\a^(fD[ʾкVd\޹Uo&-W:/Z6_{gȲo{ " DHp,.cmwFѐUI<#{ثdw5Ezf{=cՕ!!  hŀr/F0X as͍lc 1vwWY}Gr,I֬_W}1bZ gBIV(%"wcw^Bt<3,[}c .t$Qd1I8V b,8:Onu{&k٢TO÷?@,Rq*H% T9eTnM5.YE_~ }*ȕܣؾFMC/twb{0 IK 3~zu/IwBj29ԇΝVF{ߟK#̂nkrmn^X>:jD-8f4\[KvݤC3p,䯱Lbdc3ۜ|=՟*i4MIQ%XA?=Uvh4&М ԫf(zƙ5~iҁ_ڣEGE h[kj5[De;"f[8TvpH=5zV˓*|LSԜHDeKn!GD]EҪ#P| hJI7619[÷aXA'A 7"-%&sz`m{nj5wuXG=]@!>1?d;if> kjSJM`.κg(`s Fkf/_c5NJ/yghwa4֚HI[d6kpCABԳ&anzĨ#^hrkpswja1ZݺviܕC{extX>оpG>GLmrU5]Lvo_(IYBTcCTUOh/^jw R8.jU (5)SRWͿ.qVAx5{1FS/?ROv܋{< -+IXL{s Է:]whgQe2-iF10:|ASgt:]e~[{]RcunZtZEŇ7mrhYH| B&m^r5UA!NvXʪpP_37NePo3g|$j\V)eS k]<$)S+I-J~rpC W,֟{]ȩㅤPV^(GFiQ9)lVxke g6X-zGڸS}{ghq>yR)su @ 5VԦ$x 4a%ۥ13jWZO$T$pL>kҠ4D]s_)Pr}yRQ=Y>[ ggd44w #A|g}'IH!{{M.E(x|2Q.9JcVXOyۺ{tm-:F/kt`f?.Q@kY^6e2S2taVx|4XЁӫ-8EXv) mtozg{&oDG =Yag,Z_\As8dE1`^C]_1%->)^I`5/N}F/&g=aq2 >nGdko߫)=> ɀȧ" 6h\ Rğ,BEY2F/ltn|}&ȓEQE(go/ρAչ^[(׋{AP`T,I{/ -%g)qD9265^l,lL+Cclv( s[C/18^̈́V3%xa者{q/kB-_fs0X_[Y9ӹ01?yhTV#Sf]ey3u`J \[nLzcX濝C~ˉMvXJDDh_?hPyk X.Vx*FRij).~' 6 ܊W{ov-̺gP$ v!uP_tRPL-w8 1'rCsqPJYI01xf)bԍS03g=HIg>MҹTrTN\.$ (ƭb'ݛFJd{wPM&xΆt* @փ" k^{/^9RXWi)D,N5k֬ 2L)$oIh֡)E-Bk݄|jMD2pj; @\p+C5 "=E" D6)\u:Q{!gyRgN {/aᩝ 0 ð{0 0^0 0 0 0 0 ð{0 0 r/w_x$܋줸0 0WٛX!;~'x5T.Ç˷sy\&3.7ba*Q +8|{{q|B}{Q:>z/bB69y;3u+3?#e͚5k֬Y_M$' I%Go.-Z䃇7P.w/Jj)18Go߻gVR|j2֬Yf͚ĭY3 Lrw~^{Q>yUs/^|c!ZZ\V'֖&W'Yf͚5kWFeትJ46ˬ/>{owi  \9W_w~G/Kaa _}6 gϞKuJ݋"GŃ}a͚5k֬Y_ Ak988*KGýPPh f͚5k֬&9y(K|ar ?{=+',,,,,,,mGw/),,,,,,a?{Q%^\uaaaaaa@BYÏ^^Yaaaaaaa)܋+ K%JZau/.s/XXXXXXXX뫸/gHIENDB`ovs-2.13.0/Documentation/automake.mk000066400000000000000000000205411362155554400173700ustar00rootroot00000000000000DOC_SOURCE = \ Documentation/group-selection-method-property.txt \ Documentation/_static/logo.png \ Documentation/_static/overview.png \ Documentation/conf.py \ 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/afxdp.rst \ Documentation/intro/install/debian.rst \ Documentation/intro/install/documentation.rst \ Documentation/intro/install/distributions.rst \ Documentation/intro/install/dpdk.rst \ Documentation/intro/install/fedora.rst \ Documentation/intro/install/general.rst \ Documentation/intro/install/netbsd.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/faucet.rst \ Documentation/tutorials/ovs-advanced.rst \ Documentation/tutorials/ovs-conntrack.rst \ Documentation/tutorials/ipsec.rst \ Documentation/topics/index.rst \ Documentation/topics/bonding.rst \ Documentation/topics/idl-compound-indexes.rst \ Documentation/topics/datapath.rst \ Documentation/topics/design.rst \ Documentation/topics/dpdk/index.rst \ Documentation/topics/dpdk/bridge.rst \ Documentation/topics/dpdk/jumbo-frames.rst \ Documentation/topics/dpdk/memory.rst \ Documentation/topics/dpdk/pdump.rst \ Documentation/topics/dpdk/phy.rst \ Documentation/topics/dpdk/pmd.rst \ Documentation/topics/dpdk/qos.rst \ Documentation/topics/dpdk/ring.rst \ Documentation/topics/dpdk/vdev.rst \ Documentation/topics/dpdk/vhost-user.rst \ Documentation/topics/fuzzing/index.rst \ Documentation/topics/fuzzing/what-is-fuzzing.rst \ Documentation/topics/fuzzing/ovs-fuzzing-infrastructure.rst \ Documentation/topics/fuzzing/ovs-fuzzers.rst \ Documentation/topics/fuzzing/security-analysis-of-ovs-fuzzers.rst \ Documentation/topics/testing.rst \ Documentation/topics/integration.rst \ Documentation/topics/language-bindings.rst \ Documentation/topics/networking-namespaces.rst \ Documentation/topics/openflow.rst \ Documentation/topics/ovs-extensions.rst \ Documentation/topics/ovsdb-replication.rst \ Documentation/topics/porting.rst \ Documentation/topics/tracing.rst \ Documentation/topics/userspace-tso.rst \ Documentation/topics/windows.rst \ Documentation/howto/index.rst \ Documentation/howto/dpdk.rst \ Documentation/howto/ipsec.rst \ Documentation/howto/kvm.rst \ Documentation/howto/libvirt.rst \ Documentation/howto/selinux.rst \ Documentation/howto/ssl.rst \ Documentation/howto/lisp.rst \ Documentation/howto/qos.png \ Documentation/howto/qos.rst \ Documentation/howto/sflow.png \ Documentation/howto/sflow.rst \ Documentation/howto/tunneling.png \ Documentation/howto/tunneling.rst \ Documentation/howto/userspace-tunneling.rst \ Documentation/howto/vlan.png \ Documentation/howto/vlan.rst \ Documentation/howto/vtep.rst \ Documentation/ref/index.rst \ Documentation/faq/index.rst \ Documentation/faq/configuration.rst \ Documentation/faq/contributing.rst \ Documentation/faq/design.rst \ Documentation/faq/general.rst \ Documentation/faq/issues.rst \ Documentation/faq/openflow.rst \ Documentation/faq/qos.rst \ Documentation/faq/releases.rst \ Documentation/faq/terminology.rst \ Documentation/faq/vlan.rst \ Documentation/faq/vxlan.rst \ Documentation/internals/index.rst \ Documentation/internals/authors.rst \ Documentation/internals/bugs.rst \ Documentation/internals/charter.rst \ Documentation/internals/committer-emeritus-status.rst \ Documentation/internals/committer-grant-revocation.rst \ Documentation/internals/committer-responsibilities.rst \ Documentation/internals/documentation.rst \ Documentation/internals/mailing-lists.rst \ Documentation/internals/maintainers.rst \ Documentation/internals/patchwork.rst \ Documentation/internals/release-process.rst \ Documentation/internals/security.rst \ Documentation/internals/contributing/index.rst \ Documentation/internals/contributing/backporting-patches.rst \ Documentation/internals/contributing/coding-style.rst \ Documentation/internals/contributing/coding-style-windows.rst \ Documentation/internals/contributing/documentation-style.rst \ Documentation/internals/contributing/libopenvswitch-abi.rst \ Documentation/internals/contributing/submitting-patches.rst \ Documentation/requirements.txt \ $(addprefix Documentation/ref/,$(RST_MANPAGES) $(RST_MANPAGES_NOINST)) FLAKE8_PYFILES += Documentation/conf.py EXTRA_DIST += $(DOC_SOURCE) # You can set these variables from the command line. SPHINXOPTS = SPHINXSRCDIR = $(srcdir)/Documentation SPHINXBUILDDIR = $(builddir)/Documentation/_build # Internal variables. ALLSPHINXOPTS = -W -n -d $(SPHINXBUILDDIR)/doctrees $(SPHINXOPTS) $(SPHINXSRCDIR) sphinx_verbose = $(sphinx_verbose_@AM_V@) sphinx_verbose_ = $(sphinx_verbose_@AM_DEFAULT_V@) sphinx_verbose_0 = -q if HAVE_SPHINX docs-check: $(DOC_SOURCE) $(AM_V_GEN)$(SPHINXBUILD) $(sphinx_verbose) -b html $(ALLSPHINXOPTS) $(SPHINXBUILDDIR)/html && touch $@ $(AM_V_GEN)$(SPHINXBUILD) $(sphinx_verbose) -b man $(ALLSPHINXOPTS) $(SPHINXBUILDDIR)/man && touch $@ ALL_LOCAL += docs-check CLEANFILES += docs-check check-docs: $(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(SPHINXBUILDDIR)/linkcheck clean-docs: rm -rf $(SPHINXBUILDDIR) rm -f docs-check CLEAN_LOCAL += clean-docs endif .PHONY: check-docs .PHONY: clean-docs # Installing manpages based on rST. # # The docs-check target converts the rST files listed in RST_MANPAGES # into nroff manpages in Documentation/_build/man. The easiest way to # get these installed by "make install" is to write our own helper # rules. # rST formatted manpages under Documentation/ref. RST_MANPAGES = \ ovs-appctl.8.rst \ ovs-ctl.8.rst \ ovs-l3ping.8.rst \ ovs-parse-backtrace.8.rst \ ovs-pki.8.rst \ ovs-tcpdump.8.rst \ ovs-tcpundump.1.rst \ ovs-test.8.rst \ ovs-vlan-test.8.rst \ ovsdb-server.7.rst \ ovsdb.5.rst \ ovsdb.7.rst # rST formatted manpages that we don't want to install because they # document stuff that only works with a build tree, not with an # installed OVS. RST_MANPAGES_NOINST = ovs-sim.1.rst # The GNU standards say that these variables should control # installation directories for manpages in each section. Automake # will define them for us only if it sees that a manpage in the # appropriate section is to be installed through its built-in feature. # Since we're working independently, for best safety, we need to # define them ourselves. man1dir = $(mandir)/man1 man2dir = $(mandir)/man2 man3dir = $(mandir)/man3 man4dir = $(mandir)/man4 man5dir = $(mandir)/man5 man6dir = $(mandir)/man6 man7dir = $(mandir)/man7 man8dir = $(mandir)/man8 man9dir = $(mandir)/man9 # Set a shell variable for each manpage directory. set_mandirs = \ man1dir='$(man1dir)' \ man2dir='$(man2dir)' \ man3dir='$(man3dir)' \ man4dir='$(man4dir)' \ man5dir='$(man5dir)' \ man6dir='$(man6dir)' \ man7dir='$(man7dir)' \ man8dir='$(man8dir)' \ man9dir='$(man9dir)' # Given an $rst of "ovs-vlan-test.8.rst", sets $stem to # "ovs-vlan-test", $section to "8", and $mandir to $man8dir. extract_stem_and_section = \ stem=`echo "$$rst" | sed -n 's/^\(.*\)\.\([0-9]\).rst$$/\1/p'`; \ section=`echo "$$rst" | sed -n 's/^\(.*\)\.\([0-9]\).rst$$/\2/p'`; \ test -n "$$section" || { echo "$$rst: cannot infer manpage section from filename" 2>&1; continue; }; \ eval "mandir=\$$man$${section}dir"; \ test -n "$$mandir" || { echo "unknown directory for manpage section $$section"; continue; } INSTALL_DATA_LOCAL += install-man-rst if HAVE_SPHINX install-man-rst: docs-check @$(set_mandirs); \ for rst in $(RST_MANPAGES) $(EXTRA_RST_MANPAGES); do \ $(extract_stem_and_section); \ echo " $(MKDIR_P) '$(DESTDIR)'\"$$mandir\""; \ $(MKDIR_P) '$(DESTDIR)'"$$mandir"; \ echo " $(INSTALL_DATA) $(SPHINXBUILDDIR)/man/$$stem.$$section '$(DESTDIR)'\"$$mandir/$$stem.$$section\""; \ $(INSTALL_DATA) $(SPHINXBUILDDIR)/man/$$stem.$$section '$(DESTDIR)'"$$mandir/$$stem.$$section"; \ done else install-man-rst: @: endif UNINSTALL_LOCAL += uninstall-man-rst uninstall-man-rst: @$(set_mandirs); \ for rst in $(RST_MANPAGES); do \ $(extract_stem_and_section); \ echo "rm -f '$(DESTDIR)'\"$$mandir/$$stem.$$section\""; \ rm -f '$(DESTDIR)'"$$mandir/$$stem.$$section"; \ done ovs-2.13.0/Documentation/conf.py000066400000000000000000000116141362155554400165310ustar00rootroot00000000000000# -*- coding: utf-8 -*- # # Open vSwitch documentation build configuration file, created by # sphinx-quickstart on Fri Sep 30 09:57:36 2016. # # This file is execfile()d with the current directory set to its # containing dir. # # Note that not all possible configuration values are present in this # autogenerated file. # # All configuration values have a default; values that are commented out # serve to show the default. import string import sys try: import ovs_sphinx_theme use_ovs_theme = True except ImportError: print("Cannot find 'ovs-sphinx-theme' package. " "Falling back to default theme.") use_ovs_theme = False # -- General configuration ------------------------------------------------ # If your documentation needs a minimal Sphinx version, state it here. # needs_sphinx = '1.1' # Add any Sphinx extension module names here, as strings. They can be # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom # ones. extensions = ['sphinx.ext.todo'] # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] # The suffix(es) of source filenames. # You can specify multiple suffix as a list of string: # # source_suffix = ['.rst', '.md'] source_suffix = '.rst' # The master toctree document. master_doc = 'contents' # General information about the project. project = u'Open vSwitch' copyright = u'2016, The Open vSwitch Development Community' author = u'The Open vSwitch Development Community' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the # built documents. # # The full version, including alpha/beta/rc tags. release = None filename = "../configure.ac" with open(filename, 'r') as f: for line in f: if 'AC_INIT' in line: # Parse "AC_INIT(openvswitch, 2.7.90, bugs@openvswitch.org)": release = line.split(',')[1].strip(string.whitespace + '[]') break if release is None: sys.stderr.write('%s: failed to determine Open vSwitch version\n' % filename) sys.exit(1) # The short X.Y version. # # However, it's important to know the difference between, e.g., 2.7 # and 2.7.90, which can be very different versions (2.7.90 may be much # closer to 2.8 than to 2.7), so check for that. version = release if '.90' in release else '.'.join(release.split('.')[0:2]) # List of patterns, relative to source directory, that match files and # directories to ignore when looking for source files. # This patterns also effect to html_static_path and html_extra_path exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store'] # If true, check the validity of #anchors in links. linkcheck_anchors = False # -- Options for HTML output ---------------------------------------------- # The theme to use for HTML and HTML Help pages. See the documentation for # a list of builtin themes. # if use_ovs_theme: html_theme = 'ovs' # Add any paths that contain custom themes here, relative to this directory. if use_ovs_theme: html_theme_path = [ovs_sphinx_theme.get_theme_dir()] else: html_theme_path = [] # The name of an image file (relative to this directory) to place at the top # of the sidebar. # html_logo = '_static/logo.png' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". html_static_path = ['_static'] # -- Options for manual page output --------------------------------------- # One entry per manual page. List of tuples # (source start file, name, description, authors, manual section). _man_pages = [ ('ovs-appctl.8', u'utility for configuring running Open vSwitch daemons'), ('ovs-ctl.8', u'OVS startup helper script'), ('ovs-l3ping.8', u'check network deployment for L3 tunneling problems'), ('ovs-parse-backtrace.8', u'parses ovs-appctl backtrace output'), ('ovs-pki.8', u'OpenFlow public key infrastructure management utility'), ('ovs-sim.1', u'Open vSwitch simulator environment'), ('ovs-tcpdump.8', u'Dump traffic from an Open vSwitch port using tcpdump'), ('ovs-tcpundump.1', u'convert "tcpdump -xx" output to hex strings'), ('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', u'Open vSwitch Database (File Formats)'), ('ovsdb.7', u'Open vSwitch Database (Overview)'), ] # Generate list of (path, name, description, [author, ...], section) man_pages = [ ('ref/%s' % file_name, file_name.split('.', 1)[0], description, [author], file_name.split('.', 1)[1]) for file_name, description in _man_pages] ovs-2.13.0/Documentation/contents.rst000066400000000000000000000022141362155554400176150ustar00rootroot00000000000000.. 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 Documentation Contents =================================== .. toctree:: :maxdepth: 3 index .. toctree:: :maxdepth: 3 intro/index tutorials/index topics/index howto/index ref/index faq/index internals/index ovs-2.13.0/Documentation/faq/000077500000000000000000000000001362155554400157765ustar00rootroot00000000000000ovs-2.13.0/Documentation/faq/configuration.rst000066400000000000000000000255241362155554400214070ustar00rootroot00000000000000.. 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. =================== Basic Configuration =================== Q: How do I configure a port as an access port? A. Add ``tag=VLAN`` to your ``ovs-vsctl add-port`` command. For example, the following commands configure br0 with eth0 as a trunk port (the default) and tap0 as an access port for VLAN 9: :: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 tag=9 If you want to configure an already added port as an access port, use ``ovs-vsctl set``, e.g.: :: $ ovs-vsctl set port tap0 tag=9 Q: How do I configure a port as a SPAN port, that is, enable mirroring of all traffic to that port? A. The following commands configure br0 with eth0 and tap0 as trunk ports. All traffic coming in or going out on eth0 or tap0 is also mirrored to tap1; any traffic arriving on tap1 is dropped: :: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 $ ovs-vsctl add-port br0 tap1 \ -- --id=@p get port tap1 \ -- --id=@m create mirror name=m0 select-all=true output-port=@p \ -- set bridge br0 mirrors=@m To later disable mirroring, run: :: $ ovs-vsctl clear bridge br0 mirrors Q: Does Open vSwitch support configuring a port in promiscuous mode? A: Yes. How you configure it depends on what you mean by "promiscuous mode": - Conventionally, "promiscuous mode" is a feature of a network interface card. Ordinarily, a NIC passes to the CPU only the packets actually destined to its host machine. It discards the rest to avoid wasting memory and CPU cycles. When promiscuous mode is enabled, however, it passes every packet to the CPU. On an old-style shared-media or hub-based network, this allows the host to spy on all packets on the network. But in the switched networks that are almost everywhere these days, promiscuous mode doesn't have much effect, because few packets not destined to a host are delivered to the host's NIC. This form of promiscuous mode is configured in the guest OS of the VMs on your bridge, e.g. with "ip link set promisc". - The VMware vSwitch uses a different definition of "promiscuous mode". When you configure promiscuous mode on a VMware vNIC, the vSwitch sends a copy of every packet received by the vSwitch to that vNIC. That has a much bigger effect than just enabling promiscuous mode in a guest OS. Rather than getting a few stray packets for which the switch does not yet know the correct destination, the vNIC gets every packet. The effect is similar to replacing the vSwitch by a virtual hub. This "promiscuous mode" is what switches normally call "port mirroring" or "SPAN". For information on how to configure SPAN, see "How do I configure a port as a SPAN port, that is, enable mirroring of all traffic to that port?" Q: How do I configure a DPDK port as an access port? A: Firstly, you must have a DPDK-enabled version of Open vSwitch. If your version is DPDK-enabled it may support the dpdk_version and dpdk_initialized keys in the configuration database. Earlier versions of Open vSwitch only supported the other-config:dpdk-init key in the configuration in the database. All versions will display lines with "EAL:..." during startup when other_config:dpdk-init is set to 'true'. Secondly, when adding a DPDK port, unlike a system port, the type for the interface and valid dpdk-devargs must be specified. For example:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 myportname -- set Interface myportname \ type=dpdk options:dpdk-devargs=0000:06:00.0 Refer to :doc:`/intro/install/dpdk` for more information on enabling and using DPDK with Open vSwitch. Q: How do I configure a VLAN as an RSPAN VLAN, that is, enable mirroring of all traffic to that VLAN? A: The following commands configure br0 with eth0 as a trunk port and tap0 as an access port for VLAN 10. All traffic coming in or going out on tap0, as well as traffic coming in or going out on eth0 in VLAN 10, is also mirrored to VLAN 15 on eth0. The original tag for VLAN 10, in cases where one is present, is dropped as part of mirroring: :: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 tag=10 $ ovs-vsctl \ -- --id=@m create mirror name=m0 select-all=true select-vlan=10 \ output-vlan=15 \ -- set bridge br0 mirrors=@m To later disable mirroring, run: :: $ ovs-vsctl clear bridge br0 mirrors Mirroring to a VLAN can disrupt a network that contains unmanaged switches. See ovs-vswitchd.conf.db(5) for details. Mirroring to a GRE tunnel has fewer caveats than mirroring to a VLAN and should generally be preferred. Q: Can I mirror more than one input VLAN to an RSPAN VLAN? A: Yes, but mirroring to a VLAN strips the original VLAN tag in favor of the specified output-vlan. This loss of information may make the mirrored traffic too hard to interpret. To mirror multiple VLANs, use the commands above, but specify a comma-separated list of VLANs as the value for select-vlan. To mirror every VLAN, use the commands above, but omit select-vlan and its value entirely. When a packet arrives on a VLAN that is used as a mirror output VLAN, the mirror is disregarded. Instead, in standalone mode, OVS floods the packet across all the ports for which the mirror output VLAN is configured. (If an OpenFlow controller is in use, then it can override this behavior through the flow table.) If OVS is used as an intermediate switch, rather than an edge switch, this ensures that the RSPAN traffic is distributed through the network. Mirroring to a VLAN can disrupt a network that contains unmanaged switches. See ovs-vswitchd.conf.db(5) for details. Mirroring to a GRE tunnel has fewer caveats than mirroring to a VLAN and should generally be preferred. Q: How do I configure mirroring of all traffic to a GRE tunnel? A: The following commands configure br0 with eth0 and tap0 as trunk ports. All traffic coming in or going out on eth0 or tap0 is also mirrored to gre0, a GRE tunnel to the remote host 192.168.1.10; any traffic arriving on gre0 is dropped:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 $ ovs-vsctl add-port br0 gre0 \ -- set interface gre0 type=gre options:remote_ip=192.168.1.10 \ -- --id=@p get port gre0 \ -- --id=@m create mirror name=m0 select-all=true output-port=@p \ -- set bridge br0 mirrors=@m To later disable mirroring and destroy the GRE tunnel:: $ ovs-vsctl clear bridge br0 mirrors $ ovs-vsctl del-port br0 gre0 Q: Does Open vSwitch support ERSPAN? A: Yes. ERSPAN version I and version II over IPv4 GRE and IPv6 GRE tunnel are supported. See ovs-fields(7) for matching and setting ERSPAN fields. :: $ ovs-vsctl add-br br0 $ #For ERSPAN type 2 (version I) $ ovs-vsctl add-port br0 at_erspan0 -- \ set int at_erspan0 type=erspan options:key=1 \ options:remote_ip=172.31.1.1 \ options:erspan_ver=1 options:erspan_idx=1 $ #For ERSPAN type 3 (version II) $ ovs-vsctl add-port br0 at_erspan0 -- \ set int at_erspan0 type=erspan options:key=1 \ options:remote_ip=172.31.1.1 \ options:erspan_ver=2 options:erspan_dir=1 \ options:erspan_hwid=4 Q: Does Open vSwitch support IPv6 GRE? A: Yes. L2 tunnel interface GRE over IPv6 is supported. L3 GRE tunnel over IPv6 is not supported. :: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 at_gre0 -- \ set int at_gre0 type=ip6gre \ options:remote_ip=fc00:100::1 \ options:packet_type=legacy_l2 Q: How do I connect two bridges? A: First, why do you want to do this? Two connected bridges are not much different from a single bridge, so you might as well just have a single bridge with all your ports on it. If you still want to connect two bridges, you can use a pair of patch ports. The following example creates bridges br0 and br1, adds eth0 and tap0 to br0, adds tap1 to br1, and then connects br0 and br1 with a pair of patch ports. :: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 $ ovs-vsctl add-br br1 $ ovs-vsctl add-port br1 tap1 $ ovs-vsctl \ -- add-port br0 patch0 \ -- set interface patch0 type=patch options:peer=patch1 \ -- add-port br1 patch1 \ -- set interface patch1 type=patch options:peer=patch0 Bridges connected with patch ports are much like a single bridge. For instance, if the example above also added eth1 to br1, and both eth0 and eth1 happened to be connected to the same next-hop switch, then you could loop your network just as you would if you added eth0 and eth1 to the same bridge (see the "Configuration Problems" section below for more information). If you are using Open vSwitch 1.9 or an earlier version, then you need to be using the kernel module bundled with Open vSwitch rather than the one that is integrated into Linux 3.3 and later, because Open vSwitch 1.9 and earlier versions need kernel support for patch ports. This also means that in Open vSwitch 1.9 and earlier, patch ports will not work with the userspace datapath, only with the kernel module. Q: How do I configure a bridge without an OpenFlow local port? (Local port in the sense of OFPP_LOCAL) A: Open vSwitch does not support such a configuration. Bridges always have their local ports. ovs-2.13.0/Documentation/faq/contributing.rst000066400000000000000000000224531362155554400212450ustar00rootroot00000000000000.. 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. =========== Development =========== Q: How do I implement a new OpenFlow message? A: Add your new message to ``enum ofpraw`` and ``enum ofptype`` in ``include/openvswitch/ofp-msgs.h``, following the existing pattern. Then recompile and fix all of the new warnings, implementing new functionality for the new message as needed. (If you configure with ``--enable-Werror``, as described in :doc:`/intro/install/general`, then it is impossible to miss any warnings.) To add an OpenFlow vendor extension message (aka experimenter message) for a vendor that doesn't yet have any extension messages, you will also need to edit ``build-aux/extract-ofp-msgs`` and at least ``ofphdrs_decode()`` and ``ofpraw_put__()`` in ``lib/ofp-msgs.c``. OpenFlow doesn't standardize vendor extensions very well, so it's hard to make the process simpler than that. (If you have a choice of how to design your vendor extension messages, it will be easier if you make them resemble the ONF and OVS extension messages.) Q: How do I add support for a new field or header? A: Add new members for your field to ``struct flow`` in ``include/openvswitch/flow.h``, and add new enumerations for your new field to ``enum mf_field_id`` in ``include/openvswitch/meta-flow.h``, following the existing pattern. If the field uses a new OXM class, add it to OXM_CLASSES in ``build-aux/extract-ofp-fields``. Also, add support to ``miniflow_extract()`` in ``lib/flow.c`` for extracting your new field from a packet into struct miniflow, and to ``nx_put_raw()`` in ``lib/nx-match.c`` to output your new field in OXM matches. Then recompile and fix all of the new warnings, implementing new functionality for the new field or header as needed. (If you configure with ``--enable-Werror``, as described in :doc:`/intro/install/general`, then it is impossible to miss any warnings.) If you want kernel datapath support for your new field, you also need to modify the kernel module for the operating systems you are interested in. This isn't mandatory, since fields understood only by userspace work too (with a performance penalty), so it's reasonable to start development without it. If you implement kernel module support for Linux, then the Linux kernel "netdev" mailing list is the place to submit that support first; please read up on the Linux kernel development process separately. The Windows datapath kernel module support, on the other hand, is maintained within the OVS tree, so patches for that can go directly to ovs-dev. Q: How do I add support for a new OpenFlow action? A: Add your new action to ``enum ofp_raw_action_type`` in ``lib/ofp-actions.c``, following the existing pattern. Then recompile and fix all of the new warnings, implementing new functionality for the new action as needed. (If you configure with ``--enable-Werror``, as described in the :doc:`/intro/install/general`, then it is impossible to miss any warnings.) If you need to add an OpenFlow vendor extension action for a vendor that doesn't yet have any extension actions, then you will also need to add the vendor to ``vendor_map`` in ``build-aux/extract-ofp-actions``. Also, you will need to add support for the vendor to ``ofpact_decode_raw()`` and ``ofpact_put_raw()`` in ``lib/ofp-actions.c``. (If you have a choice of how to design your vendor extension actions, it will be easier if you make them resemble the ONF and OVS extension actions.) Q: How do I add support for a new OpenFlow error message? A: Add your new error to ``enum ofperr`` in ``include/openvswitch/ofp-errors.h``. Read the large comment at the top of the file for details. If you need to add an OpenFlow vendor extension error for a vendor that doesn't yet have any, first add the vendor ID to the ``_VENDOR_ID`` list in ``include/openflow/openflow-common.h``. Q: What's a Signed-off-by and how do I provide one? A: Free and open source software projects usually require a contributor to provide some assurance that they're entitled to contribute the code that they provide. Some projects, for example, do this with a Contributor License Agreement (CLA) or a copyright assignment that is signed on paper or electronically. For this purpose, Open vSwitch has adopted something called the Developer's Certificate of Origin (DCO), which is also used by the Linux kernel and originated there. Informally stated, agreeing to the DCO is the developer's way of attesting that a particular commit that they are contributing is one that they are allowed to contribute. You should visit https://developercertificate.org/ to read the full statement of the DCO, which is less than 200 words long. To certify compliance with the Developer's Certificate of Origin for a particular commit, just add the following line to the end of your commit message, properly substituting your name and email address: Signed-off-by: Firstname Lastname Git has special support for adding a Signed-off-by line to a commit message: when you run "git commit", just add the -s option, as in "git commit -s". If you use the "git citool" GUI for commits, you can add a Signed-off-by line to the commit message by pressing Control+S. Other Git user interfaces may provide similar support. Q: How do I apply patches from email? A: You can use ``git am`` on raw email contents, either from a file saved by or piped from an email client. In ``mutt``, for example, when you are viewing a patch, you can apply it to the tree in ~/ovs by issuing the command ``|cd ~/ovs && git am``. If you are an OVS committer, you might want to add ``-s`` to sign off on the patch as part of applying it. If you do this often, then you can make the keystrokes ``,a`` shorthand for it by adding the following line to your ``.muttrc``: macro index,pager ,a "cd ~/ovs && git am -s" "apply patch" ``git am`` has a problem with some email messages from the ovs-dev list for which the mailing list manager edits the From: address, replacing it by the list's own address. The mailing list manager must do this for messages whose sender's email domain has DMARC configured, because receivers will otherwise discard these messages when they do not come directly from the sender's email domain. This editing makes the patches look like they come from the mailing list instead of the author. To work around this problem, one can use the following wrapper script for ``git am``:: #! /bin/sh tmp=$(mktemp) cat >$tmp if grep '^From:.*via dev.*' "$tmp" >/dev/null 2>&1; then sed '/^From:.*via dev.*/d s/^[Rr]eply-[tT]o:/From:/' $tmp else cat "$tmp" fi | git am "$@" rm "$tmp" Another way to apply emailed patches is to use the ``pwclient`` program, which can obtain patches from patchwork and apply them directly. Download ``pwclient`` at https://patchwork.ozlabs.org/project/openvswitch/. You probably want to set up a ``.pwclientrc`` that looks something like this:: [options] default=openvswitch signoff=true [openvswitch] url=https://patchwork.ozlabs.org/xmlrpc/ After you install ``pwclient``, you can apply a patch from patchwork with ``pwclient git-am #``, where # is the patch's number. (This fails with certain patches that contain form-feeds, due to a limitation of the protocol underlying ``pwclient``.) Another way to apply patches directly from patchwork which supports applying patch series is to use the ``git-pw`` program. It can be obtained with ``pip install git-pw``. Alternative installation instructions and general documentation can be found at https://patchwork.readthedocs.io/projects/git-pw/en/latest/. You need to use your openvswitch patchwork login or create one at https://patchwork.ozlabs.org/register/. The following can then be set on the command line with ``git config`` or through a ``.gitconfig`` like this:: [pw] server=https://patchwork.ozlabs.org/api/1.0 project=openvswitch username= password= Patch series can be listed with ``git-pw series list`` and applied with ``git-pw series apply #``, where # is the series number. Individual patches can be applied with ``git-pw patch apply #``, where # is the patch number. ovs-2.13.0/Documentation/faq/design.rst000066400000000000000000000157541362155554400200150ustar00rootroot00000000000000.. 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. ====================== Implementation Details ====================== Q: I hear OVS has a couple of kinds of flows. Can you tell me about them? A: Open vSwitch uses different kinds of flows for different purposes: - OpenFlow flows are the most important kind of flow. OpenFlow controllers use these flows to define a switch's policy. OpenFlow flows support wildcards, priorities, and multiple tables. When in-band control is in use, Open vSwitch sets up a few "hidden" flows, with priority higher than a controller or the user can configure, that are not visible via OpenFlow. (See the "Controller" section of the FAQ for more information about hidden flows.) - The Open vSwitch software switch implementation uses a second kind of flow internally. These flows, called "datapath" or "kernel" flows, do not support priorities and comprise only a single table, which makes them suitable for caching. (Like OpenFlow flows, datapath flows do support wildcarding, in Open vSwitch 1.11 and later.) OpenFlow flows and datapath flows also support different actions and number ports differently. Datapath flows are an implementation detail that is subject to change in future versions of Open vSwitch. Even with the current version of Open vSwitch, hardware switch implementations do not necessarily use this architecture. Users and controllers directly control only the OpenFlow flow table. Open vSwitch manages the datapath flow table itself, so users should not normally be concerned with it. Q: Why are there so many different ways to dump flows? A: Open vSwitch has two kinds of flows (see the previous question), so it has commands with different purposes for dumping each kind of flow: - ``ovs-ofctl dump-flows
`` dumps OpenFlow flows, excluding hidden flows. This is the most commonly useful form of flow dump. (Unlike the other commands, this should work with any OpenFlow switch, not just Open vSwitch.) - ``ovs-appctl bridge/dump-flows
`` dumps OpenFlow flows, including hidden flows. This is occasionally useful for troubleshooting suspected issues with in-band control. - ``ovs-dpctl dump-flows [dp]`` dumps the datapath flow table entries for a Linux kernel-based datapath. In Open vSwitch 1.10 and later, ovs-vswitchd merges multiple switches into a single datapath, so it will show all the flows on all your kernel-based switches. This command can occasionally be useful for debugging. It doesn't dump flows that was offloaded to hardware. - ``ovs-appctl dpif/dump-flows
``, new in Open vSwitch 1.10, dumps datapath flows for only the specified bridge, regardless of the type. Supports dumping of HW offloaded flows. See ovs-vswitchd(8) for details. Q: How does multicast snooping works with VLANs? A: Open vSwitch maintains snooping tables for each VLAN. Q: Can OVS populate the kernel flow table in advance instead of in reaction to packets? A: No. There are several reasons: - Kernel flows are not as sophisticated as OpenFlow flows, which means that some OpenFlow policies could require a large number of kernel flows. The "conjunctive match" feature is an extreme example: the number of kernel flows it requires is the product of the number of flows in each dimension. - With multiple OpenFlow flow tables and simple sets of actions, the number of kernel flows required can be as large as the product of the number of flows in each dimension. With more sophisticated actions, the number of kernel flows could be even larger. - Open vSwitch is designed so that any version of OVS userspace interoperates with any version of the OVS kernel module. This forward and backward compatibility requires that userspace observe how the kernel module parses received packets. This is only possible in a straightforward way when userspace adds kernel flows in reaction to received packets. For more relevant information on the architecture of Open vSwitch, please read "The Design and Implementation of Open vSwitch", published in USENIX NSDI 2015. Q: How many packets does OVS buffer? A: Open vSwitch fast path packet processing uses a "run to completion" model in which every packet is completely handled in a single pass. Therefore, in the common case where a packet just passes through the fast path, Open vSwitch does not buffer packets itself. The operating system and the network drivers involved in receiving and later in transmitting the packet do often include buffering. Open vSwitch is only a middleman between these and does not have direct access or influence over their buffers. Outside the common case, Open vSwitch does sometimes buffer packets. When the OVS fast path processes a packet that does not match any of the flows in its megaflow cache, it passes that packet to the Open vSwitch slow path. This procedure queues a copy of the packet to the Open vSwitch userspace which processes it and, if necessary, passes it back to the kernel module. Queuing the packet to userspace as part of this process involves buffering. (Going the opposite direction does not, because the kernel actually processes the request synchronously.) A few other exceptional cases also queue packets to userspace for processing; most of these are due to OpenFlow actions that the fast path cannot handle and that must therefore be handled by the slow path instead. OpenFlow also has a concept of packet buffering. When an OpenFlow switch sends a packet to a controller, it may opt to retain a copy of the packet in an OpenFlow "packet buffer". Later, if the controller wants to tell the switch to forward a copy of that packet, it can refer to the packet through its assigned buffer, instead of sending the whole packet back to the switch, thereby saving bandwidth in the OpenFlow control channel. Before Open vSwitch 2.7, OVS implemented such buffering; Open vSwitch 2.7 and later do not. ovs-2.13.0/Documentation/faq/general.rst000066400000000000000000000145561362155554400201600ustar00rootroot00000000000000.. 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. ======= General ======= Q: What is Open vSwitch? A: Open vSwitch is a production quality open source software switch designed to be used as a vswitch in virtualized server environments. A vswitch forwards traffic between different VMs on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch supports standard management interfaces (e.g. sFlow, NetFlow, IPFIX, RSPAN, CLI), and is open to programmatic extension and control using OpenFlow and the OVSDB management protocol. Open vSwitch as designed to be compatible with modern switching chipsets. This means that it can be ported to existing high-fanout switches allowing the same flexible control of the physical infrastructure as the virtual infrastructure. It also means that Open vSwitch will be able to take advantage of on-NIC switching chipsets as their functionality matures. Q: What virtualization platforms can use Open vSwitch? A: Open vSwitch can currently run on any Linux-based virtualization platform (kernel 3.10 and newer), including: KVM, VirtualBox, Xen, Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the mainline kernel. The bulk of the code is written in platform- independent C and is easily ported to other environments. We welcome inquires about integrating Open vSwitch with other virtualization platforms. Q: How can I try Open vSwitch? A: The Open vSwitch source code can be built on a Linux system. You can build and experiment with Open vSwitch on any Linux machine. Packages for various Linux distributions are available on many platforms, including: Debian, Ubuntu, Fedora. You may also download and run a virtualization platform that already has Open vSwitch integrated. For example, download a recent ISO for XenServer or Xen Cloud Platform. Be aware that the version integrated with a particular platform may not be the most recent Open vSwitch release. Q: Does Open vSwitch only work on Linux? A: No, Open vSwitch has been ported to a number of different operating systems and hardware platforms. Most of the development work occurs on Linux, but the code should be portable to any POSIX system. We've seen Open vSwitch ported to a number of different platforms, including FreeBSD, Windows, and even non-POSIX embedded systems. By definition, the Open vSwitch Linux kernel module only works on Linux and will provide the highest performance. However, a userspace datapath is available that should be very portable. Q: What's involved with porting Open vSwitch to a new platform or switching ASIC? A: :doc:`/topics/porting` describes how one would go about porting Open vSwitch to a new operating system or hardware platform. Q: Why would I use Open vSwitch instead of the Linux bridge? A: Open vSwitch is specially designed to make it easier to manage VM network configuration and monitor state spread across many physical hosts in dynamic virtualized environments. Refer to :doc:`/intro/why-ovs` for a more detailed description of how Open vSwitch relates to the Linux Bridge. Q: How is Open vSwitch related to distributed virtual switches like the VMware vNetwork distributed switch or the Cisco Nexus 1000V? A: Distributed vswitch applications (e.g., VMware vNetwork distributed switch, Cisco Nexus 1000V) provide a centralized way to configure and monitor the network state of VMs that are spread across many physical hosts. Open vSwitch is not a distributed vswitch itself, rather it runs on each physical host and supports remote management in a way that makes it easier for developers of virtualization/cloud management platforms to offer distributed vswitch capabilities. To aid in distribution, Open vSwitch provides two open protocols that are specially designed for remote management in virtualized network environments: OpenFlow, which exposes flow-based forwarding state, and the OVSDB management protocol, which exposes switch port state. In addition to the switch implementation itself, Open vSwitch includes tools (ovs-ofctl, ovs-vsctl) that developers can script and extend to provide distributed vswitch capabilities that are closely integrated with their virtualization management platform. Q: Why doesn't Open vSwitch support distribution? A: Open vSwitch is intended to be a useful component for building flexible network infrastructure. There are many different approaches to distribution which balance trade-offs between simplicity, scalability, hardware compatibility, convergence times, logical forwarding model, etc. The goal of Open vSwitch is to be able to support all as a primitive building block rather than choose a particular point in the distributed design space. Q: How can I contribute to the Open vSwitch Community? A: You can start by joining the mailing lists and helping to answer questions. You can also suggest improvements to documentation. If you have a feature or bug you would like to work on, send a mail to one of the :doc:`mailing lists `. Q: Why can I no longer connect to my OpenFlow controller or OVSDB manager? A: Starting in OVS 2.4, we switched the default ports to the IANA-specified port numbers for OpenFlow (6633->6653) and OVSDB (6632->6640). We recommend using these port numbers, but if you cannot, all the programs allow overriding the default port. See the appropriate man page. ovs-2.13.0/Documentation/faq/index.rst000066400000000000000000000021741362155554400176430ustar00rootroot00000000000000.. 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. ================ Open vSwitch FAQ ================ .. toctree:: :maxdepth: 2 configuration contributing design general issues openflow qos releases terminology vlan vxlan ovs-2.13.0/Documentation/faq/issues.rst000066400000000000000000000505111362155554400200450ustar00rootroot00000000000000.. 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. =========================== Common Configuration Issues =========================== Q: I created a bridge and added my Ethernet port to it, using commands like these:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 and as soon as I ran the "add-port" command I lost all connectivity through eth0. Help! A: A physical Ethernet device that is part of an Open vSwitch bridge should not have an IP address. If one does, then that IP address will not be fully functional. You can restore functionality by moving the IP address to an Open vSwitch "internal" device, such as the network device named after the bridge itself. For example, assuming that eth0's IP address is 192.168.128.5, you could run the commands below to fix up the situation:: $ ip addr flush dev eth0 $ ip addr add 192.168.128.5/24 dev br0 $ ip link set br0 up (If your only connection to the machine running OVS is through the IP address in question, then you would want to run all of these commands on a single command line, or put them into a script.) If there were any additional routes assigned to eth0, then you would also want to use commands to adjust these routes to go through br0. If you use DHCP to obtain an IP address, then you should kill the DHCP client that was listening on the physical Ethernet interface (e.g. eth0) and start one listening on the internal interface (e.g. br0). You might still need to manually clear the IP address from the physical interface (e.g. with "ip addr flush dev eth0"). There is no compelling reason why Open vSwitch must work this way. However, this is the way that the Linux kernel bridge module has always worked, so it's a model that those accustomed to Linux bridging are already used to. Also, the model that most people expect is not implementable without kernel changes on all the versions of Linux that Open vSwitch supports. By the way, this issue is not specific to physical Ethernet devices. It applies to all network devices except Open vSwitch "internal" devices. Q: I created a bridge and added a couple of Ethernet ports to it, using commands like these:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 eth1 and now my network seems to have melted: connectivity is unreliable (even connectivity that doesn't go through Open vSwitch), all the LEDs on my physical switches are blinking, wireshark shows duplicated packets, and CPU usage is very high. A: More than likely, you've looped your network. Probably, eth0 and eth1 are connected to the same physical Ethernet switch. This yields a scenario where OVS receives a broadcast packet on eth0 and sends it out on eth1, then the physical switch connected to eth1 sends the packet back on eth0, and so on forever. More complicated scenarios, involving a loop through multiple switches, are possible too. The solution depends on what you are trying to do: - If you added eth0 and eth1 to get higher bandwidth or higher reliability between OVS and your physical Ethernet switch, use a bond. The following commands create br0 and then add eth0 and eth1 as a bond:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-bond br0 bond0 eth0 eth1 Bonds have tons of configuration options. Please read the documentation on the Port table in ovs-vswitchd.conf.db(5) for all the details. Configuration for DPDK-enabled interfaces is slightly less straightforward. Refer to :doc:`/intro/install/dpdk` for more information. - Perhaps you don't actually need eth0 and eth1 to be on the same bridge. For example, if you simply want to be able to connect each of them to virtual machines, then you can put each of them on a bridge of its own:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-br br1 $ ovs-vsctl add-port br1 eth1 and then connect VMs to br0 and br1. (A potential disadvantage is that traffic cannot directly pass between br0 and br1. Instead, it will go out eth0 and come back in eth1, or vice versa.) - If you have a redundant or complex network topology and you want to prevent loops, turn on spanning tree protocol (STP). The following commands create br0, enable STP, and add eth0 and eth1 to the bridge. The order is important because you don't want have to have a loop in your network even transiently:: $ ovs-vsctl add-br br0 $ ovs-vsctl set bridge br0 stp_enable=true $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 eth1 The Open vSwitch implementation of STP is not well tested. Report any bugs you observe, but if you'd rather avoid acting as a beta tester then another option might be your best shot. Q: I can't seem to use Open vSwitch in a wireless network. A: Wireless base stations generally only allow packets with the source MAC address of NIC that completed the initial handshake. Therefore, without MAC rewriting, only a single device can communicate over a single wireless link. This isn't specific to Open vSwitch, it's enforced by the access point, so the same problems will show up with the Linux bridge or any other way to do bridging. Q: I can't seem to add my PPP interface to an Open vSwitch bridge. A: PPP most commonly carries IP packets, but Open vSwitch works only with Ethernet frames. The correct way to interface PPP to an Ethernet network is usually to use routing instead of switching. Q: Is there any documentation on the database tables and fields? A: Yes. ovs-vswitchd.conf.db(5) is a comprehensive reference. Q: When I run ovs-dpctl I no longer see the bridges I created. Instead, I only see a datapath called "ovs-system". How can I see datapath information about a particular bridge? A: In version 1.9.0, OVS switched to using a single datapath that is shared by all bridges of that type. The ``ovs-appctl dpif/*`` commands provide similar functionality that is scoped by the bridge. Q: I created a GRE port using ovs-vsctl so why can't I send traffic or see the port in the datapath? A: On Linux kernels before 3.11, the OVS GRE module and Linux GRE module cannot be loaded at the same time. It is likely that on your system the Linux GRE module is already loaded and blocking OVS (to confirm, check dmesg for errors regarding GRE registration). To fix this, unload all GRE modules that appear in lsmod as well as the OVS kernel module. You can then reload the OVS module following the directions in :doc:`/intro/install/general` , which will ensure that dependencies are satisfied. Q: Open vSwitch does not seem to obey my packet filter rules. A: It depends on mechanisms and configurations you want to use. You cannot usefully use typical packet filters, like iptables, on physical Ethernet ports that you add to an Open vSwitch bridge. This is because Open vSwitch captures packets from the interface at a layer lower below where typical packet-filter implementations install their hooks. (This actually applies to any interface of type "system" that you might add to an Open vSwitch bridge.) You can usefully use typical packet filters on Open vSwitch internal ports as they are mostly ordinary interfaces from the point of view of packet filters. For example, suppose you create a bridge br0 and add Ethernet port eth0 to it. Then you can usefully add iptables rules to affect the internal interface br0, but not the physical interface eth0. (br0 is also where you would add an IP address, as discussed elsewhere in the FAQ.) For simple filtering rules, it might be possible to achieve similar results by installing appropriate OpenFlow flows instead. The OVS conntrack feature (see the "ct" action in ovs-actions(7)) can implement a stateful firewall. If the use of a particular packet filter setup is essential, Open vSwitch might not be the best choice for you. On Linux, you might want to consider using the Linux Bridge. (This is the only choice if you want to use ebtables rules.) On NetBSD, you might want to consider using the bridge(4) with BRIDGE_IPF option. Q: It seems that Open vSwitch does nothing when I removed a port and then immediately put it back. For example, consider that p1 is a port of ``type=internal``:: $ ovs-vsctl del-port br0 p1 -- \ add-port br0 p1 -- \ set interface p1 type=internal Any other type of port gets the same effect. A: It's an expected behaviour. If del-port and add-port happen in a single OVSDB transaction as your example, Open vSwitch always "skips" the intermediate steps. Even if they are done in multiple transactions, it's still allowed for Open vSwitch to skip the intermediate steps and just implement the overall effect. In both cases, your example would be turned into a no-op. If you want to make Open vSwitch actually destroy and then re-create the port for some side effects like resetting kernel setting for the corresponding interface, you need to separate operations into multiple OVSDB transactions and ensure that at least the first one does not have ``--no-wait``. In the following example, the first ovs-vsctl will block until Open vSwitch reloads the new configuration and removes the port:: $ ovs-vsctl del-port br0 p1 $ ovs-vsctl add-port br0 p1 -- \ set interface p1 type=internal Q: I want to add thousands of ports to an Open vSwitch bridge, but it takes too long (minutes or hours) to do it with ovs-vsctl. How can I do it faster? A: If you add them one at a time with ovs-vsctl, it can take a long time to add thousands of ports to an Open vSwitch bridge. This is because every invocation of ovs-vsctl first reads the current configuration from OVSDB. As the number of ports grows, this starts to take an appreciable amount of time, and when it is repeated thousands of times the total time becomes significant. The solution is to add the ports in one invocation of ovs-vsctl (or a small number of them). For example, using bash:: $ ovs-vsctl add-br br0 $ cmds=; for i in {1..5000}; do cmds+=" -- add-port br0 p$i"; done $ ovs-vsctl $cmds takes seconds, not minutes or hours, in the OVS sandbox environment. Q: I created a bridge named br0. My bridge shows up in "ovs-vsctl show", but "ovs-ofctl show br0" just prints "br0 is not a bridge or a socket". A: Open vSwitch wasn't able to create the bridge. Check the ovs-vswitchd log for details (Debian and Red Hat packaging for Open vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log). In general, the Open vSwitch database reflects the desired configuration state. ovs-vswitchd monitors the database and, when it changes, reconfigures the system to reflect the new desired state. This normally happens very quickly. Thus, a discrepancy between the database and the actual state indicates that ovs-vswitchd could not implement the configuration, and so one should check the log to find out why. (Another possible cause is that ovs-vswitchd is not running. This will make ovs-vsctl commands hang, if they change the configuration, unless one specifies ``--no-wait``.) Q: I have a bridge br0. I added a new port vif1.0, and it shows up in "ovs-vsctl show", but "ovs-vsctl list port" says that it has OpenFlow port ("ofport") -1, and "ovs-ofctl show br0" doesn't show vif1.0 at all. A: Open vSwitch wasn't able to create the port. Check the ovs-vswitchd log for details (Debian and Red Hat packaging for Open vSwitch put it in /var/log/openvswitch/ovs-vswitchd.log). Please see the previous question for more information. You may want to upgrade to Open vSwitch 2.3 (or later), in which ovs-vsctl will immediately report when there is an issue creating a port. Q: I created a tap device tap0, configured an IP address on it, and added it to a bridge, like this:: $ tunctl -t tap0 $ ip addr add 192.168.0.123/24 dev tap0 $ ip link set tap0 up $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 tap0 I expected that I could then use this IP address to contact other hosts on the network, but it doesn't work. Why not? A: The short answer is that this is a misuse of a "tap" device. Use an "internal" device implemented by Open vSwitch, which works differently and is designed for this use. To solve this problem with an internal device, instead run:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 int0 -- set Interface int0 type=internal $ ip addr add 192.168.0.123/24 dev int0 $ ip link set int0 up Even more simply, you can take advantage of the internal port that every bridge has under the name of the bridge:: $ ovs-vsctl add-br br0 $ ip addr add 192.168.0.123/24 dev br0 $ ip link set br0 up In more detail, a "tap" device is an interface between the Linux (or BSD) network stack and a user program that opens it as a socket. When the "tap" device transmits a packet, it appears in the socket opened by the userspace program. Conversely, when the userspace program writes to the "tap" socket, the kernel TCP/IP stack processes the packet as if it had been received by the "tap" device. Consider the configuration above. Given this configuration, if you "ping" an IP address in the 192.168.0.x subnet, the Linux kernel routing stack will transmit an ARP on the tap0 device. Open vSwitch userspace treats "tap" devices just like any other network device; that is, it doesn't open them as "tap" sockets. That means that the ARP packet will simply get dropped. You might wonder why the Open vSwitch kernel module doesn't intercept the ARP packet and bridge it. After all, Open vSwitch intercepts packets on other devices. The answer is that Open vSwitch only intercepts *received* packets, but this is a packet being transmitted. The same thing happens for all other types of network devices, except for Open vSwitch "internal" ports. If you, for example, add a physical Ethernet port to an OVS bridge, configure an IP address on a physical Ethernet port, and then issue a "ping" to an address in that subnet, the same thing happens: an ARP gets transmitted on the physical Ethernet port and Open vSwitch never sees it. (You should not do that, as documented at the beginning of this section.) It can make sense to add a "tap" device to an Open vSwitch bridge, if some userspace program (other than Open vSwitch) has opened the tap socket. This is the case, for example, if the "tap" device was created by KVM (or QEMU) to simulate a virtual NIC. In such a case, when OVS bridges a packet to the "tap" device, the kernel forwards that packet to KVM in userspace, which passes it along to the VM, and in the other direction, when the VM sends a packet, KVM writes it to the "tap" socket, which causes OVS to receive it and bridge it to the other OVS ports. Please note that in such a case no IP address is configured on the "tap" device (there is normally an IP address configured in the virtual NIC inside the VM, but this is not visible to the host Linux kernel or to Open vSwitch). There is one special case in which Open vSwitch does directly read and write "tap" sockets. This is an implementation detail of the Open vSwitch userspace switch, which implements its "internal" ports as Linux (or BSD) "tap" sockets. In such a userspace switch, OVS receives packets sent on the "tap" device used to implement an "internal" port by reading the associated "tap" socket, and bridges them to the rest of the switch. In the other direction, OVS transmits packets bridged to the "internal" port by writing them to the "tap" socket, causing them to be processed by the kernel TCP/IP stack as if they had been received on the "tap" device. Users should not need to be concerned with this implementation detail. Open vSwitch has a network device type called "tap". This is intended only for implementing "internal" ports in the OVS userspace switch and should not be used otherwise. In particular, users should not configure KVM "tap" devices as type "tap" (use type "system", the default, instead). Q: I observe packet loss at the beginning of RFC2544 tests on a server running few hundred container apps bridged to OVS with traffic generated by HW traffic generator. How can I fix this? A: This is expected behavior on virtual switches. RFC2544 tests were designed for hardware switches, which don't have caches on the fastpath that need to be heated. Traffic generators in order to prime the switch use learning phase to heat the caches before sending the actual traffic in test phase. In case of OVS the cache is flushed quickly and to accommodate the traffic generator's delay between learning and test phase, the max-idle timeout settings should be changed to 50000 ms.:: $ ovs-vsctl --no-wait set Open_vSwitch . other_config:max-idle=50000 Q: How can I configure the bridge internal interface MTU? Why does Open vSwitch keep changing internal ports MTU? A: By default Open vSwitch overrides the internal interfaces (e.g. br0) MTU. If you have just an internal interface (e.g. br0) and a physical interface (e.g. eth0), then every change in MTU to eth0 will be reflected to br0. Any manual MTU configuration using `ip` on internal interfaces is going to be overridden by Open vSwitch to match the current bridge minimum. Sometimes this behavior is not desirable, for example with tunnels. The MTU of an internal interface can be explicitly set using the following command:: $ ovs-vsctl set int br0 mtu_request=1450 After this, Open vSwitch will configure br0 MTU to 1450. Since this setting is in the database it will be persistent (compared to what happens with `ip`). The MTU configuration can be removed to restore the default behavior with:: $ ovs-vsctl set int br0 mtu_request=[] The ``mtu_request`` column can be used to configure MTU even for physical interfaces (e.g. eth0). Q: I just upgraded and I see a performance drop. Why? A: The OVS kernel datapath may have been updated to a newer version than the OVS userspace components. Sometimes new versions of OVS kernel module add functionality that is backwards compatible with older userspace components but may cause a drop in performance with them. Especially, if a kernel module from OVS 2.1 or newer is paired with OVS userspace 1.10 or older, there will be a performance drop for TCP traffic. Updating the OVS userspace components to the latest released version should fix the performance degradation. To get the best possible performance and functionality, it is recommended to pair the same versions of the kernel module and OVS userspace. Q: I can't unload the openvswitch kernel module. Why? A: The userspace might still hold the reference count. So ``rmmod openvswitch`` does not work, for example:: $ lsmod | grep openvswitch openvswitch 155648 4 nf_conncount 24576 1 openvswitch Use the command below to drop the refcnt:: $ ovs-dpctl del-dp system@ovs-system $ rmmod openvswitch ovs-2.13.0/Documentation/faq/openflow.rst000066400000000000000000000577341362155554400204010ustar00rootroot00000000000000.. 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. ============== Using OpenFlow ============== Q: What versions of OpenFlow does Open vSwitch support? A: The following table lists the versions of OpenFlow supported by each version of Open vSwitch: ===================== ===== ===== ===== ===== ===== ===== Open vSwitch OF1.0 OF1.1 OF1.2 OF1.3 OF1.4 OF1.5 ===================== ===== ===== ===== ===== ===== ===== 1.9 and earlier yes --- --- --- --- --- 1.10, 1.11 yes --- (*) (*) --- --- 2.0, 2.1 yes (*) (*) (*) --- --- 2.2 yes (*) (*) (*) (%) (*) 2.3, 2.4 yes yes yes yes (*) (*) 2.5, 2.6, 2.7 yes yes yes yes (*) (*) 2.8, 2.9, 2.10, 2.11 yes yes yes yes yes (*) 2.12 yes yes yes yes yes yes ===================== ===== ===== ===== ===== ===== ===== --- Not supported. yes Supported and enabled by default (*) Supported, but missing features, and must be enabled by user. (%) Experimental, unsafe implementation. In any case, the user may override the default: - To enable OpenFlow 1.0, 1.1, 1.2, and 1.3 on bridge br0:: $ ovs-vsctl set bridge br0 \ protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 - To enable OpenFlow 1.0, 1.1, 1.2, 1.3, 1.4, and 1.5 on bridge br0:: $ ovs-vsctl set bridge br0 \ protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14,OpenFlow15 - To enable only OpenFlow 1.0 on bridge br0:: $ ovs-vsctl set bridge br0 protocols=OpenFlow10 All current versions of ovs-ofctl enable only OpenFlow 1.0 by default. Use the -O option to enable support for later versions of OpenFlow in ovs-ofctl. For example:: $ ovs-ofctl -O OpenFlow13 dump-flows br0 (Open vSwitch 2.2 had an experimental implementation of OpenFlow 1.4 that could cause crashes. We don't recommend enabling it.) :doc:`/topics/openflow` tracks support for OpenFlow 1.1 and later features. Q: Does Open vSwitch support MPLS? A: Before version 1.11, Open vSwitch did not support MPLS. That is, these versions can match on MPLS Ethernet types, but they cannot match, push, or pop MPLS labels, nor can they look past MPLS labels into the encapsulated packet. Open vSwitch versions 1.11, 2.0, and 2.1 have very minimal support for MPLS. With the userspace datapath only, these versions can match, push, or pop a single MPLS label, but they still cannot look past MPLS labels (even after popping them) into the encapsulated packet. Kernel datapath support is unchanged from earlier versions. Open vSwitch version 2.3 can match, push, or pop a single MPLS label and look past the MPLS label into the encapsulated packet. Both userspace and kernel datapaths will be supported, but MPLS processing always happens in userspace either way, so kernel datapath performance will be disappointing. Open vSwitch version 2.4 can match, push, or pop up to 3 MPLS labels and look past the MPLS label into the encapsulated packet. It will have kernel support for MPLS, yielding improved performance. Q: I'm getting "error type 45250 code 0". What's that? A: This is a Open vSwitch extension to OpenFlow error codes. Open vSwitch uses this extension when it must report an error to an OpenFlow controller but no standard OpenFlow error code is suitable. Open vSwitch logs the errors that it sends to controllers, so the easiest thing to do is probably to look at the ovs-vswitchd log to find out what the error was. If you want to dissect the extended error message yourself, the format is documented in include/openflow/nicira-ext.h in the Open vSwitch source distribution. The extended error codes are documented in include/openvswitch/ofp-errors.h. Q: Some of the traffic that I'd expect my OpenFlow controller to see doesn't actually appear through the OpenFlow connection, even though I know that it's going through. A: By default, Open vSwitch assumes that OpenFlow controllers are connected "in-band", that is, that the controllers are actually part of the network that is being controlled. In in-band mode, Open vSwitch sets up special "hidden" flows to make sure that traffic can make it back and forth between OVS and the controllers. These hidden flows are higher priority than any flows that can be set up through OpenFlow, and they are not visible through normal OpenFlow flow table dumps. Usually, the hidden flows are desirable and helpful, but occasionally they can cause unexpected behavior. You can view the full OpenFlow flow table, including hidden flows, on bridge br0 with the command:: $ ovs-appctl bridge/dump-flows br0 to help you debug. The hidden flows are those with priorities greater than 65535 (the maximum priority that can be set with OpenFlow). The ``Documentation/topics/design`` doc describes the in-band model in detail. If your controllers are not actually in-band (e.g. they are on localhost via 127.0.0.1, or on a separate network), then you should configure your controllers in "out-of-band" mode. If you have one controller on bridge br0, then you can configure out-of-band mode on it with:: $ ovs-vsctl set controller br0 connection-mode=out-of-band Q: Some of the OpenFlow flows that my controller sets up don't seem to apply to certain traffic, especially traffic between OVS and the controller itself. A: See above. Q: I configured all my controllers for out-of-band control mode but "ovs-appctl bridge/dump-flows" still shows some hidden flows. A: You probably have a remote manager configured (e.g. with "ovs-vsctl set-manager"). By default, Open vSwitch assumes that managers need in-band rules set up on every bridge. You can disable these rules on bridge br0 with:: $ ovs-vsctl set bridge br0 other-config:disable-in-band=true This actually disables in-band control entirely for the bridge, as if all the bridge's controllers were configured for out-of-band control. Q: My OpenFlow controller doesn't see the VLANs that I expect. A: See answer under "VLANs", above. Q: I ran ``ovs-ofctl add-flow br0 nw_dst=192.168.0.1,actions=drop`` but I got a funny message like this:: ofp_util|INFO|normalization changed ofp_match, details: ofp_util|INFO| pre: nw_dst=192.168.0.1 ofp_util|INFO|post: and when I ran ``ovs-ofctl dump-flows br0`` I saw that my nw_dst match had disappeared, so that the flow ends up matching every packet. A: The term "normalization" in the log message means that a flow cannot match on an L3 field without saying what L3 protocol is in use. The "ovs-ofctl" command above didn't specify an L3 protocol, so the L3 field match was dropped. In this case, the L3 protocol could be IP or ARP. A correct command for each possibility is, respectively:: $ ovs-ofctl add-flow br0 ip,nw_dst=192.168.0.1,actions=drop and:: $ ovs-ofctl add-flow br0 arp,nw_dst=192.168.0.1,actions=drop Similarly, a flow cannot match on an L4 field without saying what L4 protocol is in use. For example, the flow match ``tp_src=1234`` is, by itself, meaningless and will be ignored. Instead, to match TCP source port 1234, write ``tcp,tp_src=1234``, or to match UDP source port 1234, write ``udp,tp_src=1234``. Q: How can I figure out the OpenFlow port number for a given port? A: The ``OFPT_FEATURES_REQUEST`` message requests an OpenFlow switch to respond with an ``OFPT_FEATURES_REPLY`` that, among other information, includes a mapping between OpenFlow port names and numbers. From a command prompt, ``ovs-ofctl show br0`` makes such a request and prints the response for switch br0. The Interface table in the Open vSwitch database also maps OpenFlow port names to numbers. To print the OpenFlow port number associated with interface eth0, run:: $ ovs-vsctl get Interface eth0 ofport You can print the entire mapping with:: $ ovs-vsctl -- --columns=name,ofport list Interface but the output mixes together interfaces from all bridges in the database, so it may be confusing if more than one bridge exists. In the Open vSwitch database, ofport value ``-1`` means that the interface could not be created due to an error. (The Open vSwitch log should indicate the reason.) ofport value ``[]`` (the empty set) means that the interface hasn't been created yet. The latter is normally an intermittent condition (unless ovs-vswitchd is not running). Q: I added some flows with my controller or with ovs-ofctl, but when I run "ovs-dpctl dump-flows" I don't see them. A: ovs-dpctl queries a kernel datapath, not an OpenFlow switch. It won't display the information that you want. You want to use ``ovs-ofctl dump-flows`` instead. Q: It looks like each of the interfaces in my bonded port shows up as an individual OpenFlow port. Is that right? A: Yes, Open vSwitch makes individual bond interfaces visible as OpenFlow ports, rather than the bond as a whole. The interfaces are treated together as a bond for only a few purposes: - Sending a packet to the OFPP_NORMAL port. (When an OpenFlow controller is not configured, this happens implicitly to every packet.) - Mirrors configured for output to a bonded port. It would make a lot of sense for Open vSwitch to present a bond as a single OpenFlow port. If you want to contribute an implementation of such a feature, please bring it up on the Open vSwitch development mailing list at dev@openvswitch.org. Q: I have a sophisticated network setup involving Open vSwitch, VMs or multiple hosts, and other components. The behavior isn't what I expect. Help! A: To debug network behavior problems, trace the path of a packet, hop-by-hop, from its origin in one host to a remote host. If that's correct, then trace the path of the response packet back to the origin. The open source tool called ``plotnetcfg`` can help to understand the relationship between the networking devices on a single host. Usually a simple ICMP echo request and reply (``ping``) packet is good enough. Start by initiating an ongoing ``ping`` from the origin host to a remote host. If you are tracking down a connectivity problem, the "ping" will not display any successful output, but packets are still being sent. (In this case the packets being sent are likely ARP rather than ICMP.) Tools available for tracing include the following: - ``tcpdump`` and ``wireshark`` for observing hops across network devices, such as Open vSwitch internal devices and physical wires. - ``ovs-appctl dpif/dump-flows
`` in Open vSwitch 1.10 and later or ``ovs-dpctl dump-flows
`` in earlier versions. These tools allow one to observe the actions being taken on packets in ongoing flows. See ovs-vswitchd(8) for ``ovs-appctl dpif/dump-flows`` documentation, ovs-dpctl(8) for ``ovs-dpctl dump-flows`` documentation, and "Why are there so many different ways to dump flows?" above for some background. - ``ovs-appctl ofproto/trace`` to observe the logic behind how ovs-vswitchd treats packets. See ovs-vswitchd(8) for documentation. You can out more details about a given flow that ``ovs-dpctl dump-flows`` displays, by cutting and pasting a flow from the output into an ``ovs-appctl ofproto/trace`` command. - SPAN, RSPAN, and ERSPAN features of physical switches, to observe what goes on at these physical hops. Starting at the origin of a given packet, observe the packet at each hop in turn. For example, in one plausible scenario, you might: 1. ``tcpdump`` the ``eth`` interface through which an ARP egresses a VM, from inside the VM. 2. ``tcpdump`` the ``vif`` or ``tap`` interface through which the ARP ingresses the host machine. 3. Use ``ovs-dpctl dump-flows`` to spot the ARP flow and observe the host interface through which the ARP egresses the physical machine. You may need to use ``ovs-dpctl show`` to interpret the port numbers. If the output seems surprising, you can use ``ovs-appctl ofproto/trace`` to observe details of how ovs-vswitchd determined the actions in the ``ovs-dpctl dump-flows`` output. 4. ``tcpdump`` the ``eth`` interface through which the ARP egresses the physical machine. 5. ``tcpdump`` the ``eth`` interface through which the ARP ingresses the physical machine, at the remote host that receives the ARP. 6. Use ``ovs-dpctl dump-flows`` to spot the ARP flow on the remote host remote host that receives the ARP and observe the VM ``vif`` or ``tap`` interface to which the flow is directed. Again, ``ovs-dpctl show`` and ``ovs-appctl ofproto/trace`` might help. 7. ``tcpdump`` the ``vif`` or ``tap`` interface to which the ARP is directed. 8. ``tcpdump`` the ``eth`` interface through which the ARP ingresses a VM, from inside the VM. It is likely that during one of these steps you will figure out the problem. If not, then follow the ARP reply back to the origin, in reverse. Q: How do I make a flow drop packets? A: To drop a packet is to receive it without forwarding it. OpenFlow explicitly specifies forwarding actions. Thus, a flow with an empty set of actions does not forward packets anywhere, causing them to be dropped. You can specify an empty set of actions with ``actions=`` on the ovs-ofctl command line. For example:: $ ovs-ofctl add-flow br0 priority=65535,actions= would cause every packet entering switch br0 to be dropped. You can write "drop" explicitly if you like. The effect is the same. Thus, the following command also causes every packet entering switch br0 to be dropped:: $ ovs-ofctl add-flow br0 priority=65535,actions=drop ``drop`` is not an action, either in OpenFlow or Open vSwitch. Rather, it is only a way to say that there are no actions. Q: I added a flow to send packets out the ingress port, like this:: $ ovs-ofctl add-flow br0 in_port=2,actions=2 but OVS drops the packets instead. A: Yes, OpenFlow requires a switch to ignore attempts to send a packet out its ingress port. The rationale is that dropping these packets makes it harder to loop the network. Sometimes this behavior can even be convenient, e.g. it is often the desired behavior in a flow that forwards a packet to several ports ("floods" the packet). Sometimes one really needs to send a packet out its ingress port ("hairpin"). In this case, output to ``OFPP_IN_PORT``, which in ovs-ofctl syntax is expressed as just ``in_port``, e.g.:: $ ovs-ofctl add-flow br0 in_port=2,actions=in_port This also works in some circumstances where the flow doesn't match on the input port. For example, if you know that your switch has five ports numbered 2 through 6, then the following will send every received packet out every port, even its ingress port:: $ ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port or, equivalently:: $ ovs-ofctl add-flow br0 actions=all,in_port Sometimes, in complicated flow tables with multiple levels of ``resubmit`` actions, a flow needs to output to a particular port that may or may not be the ingress port. It's difficult to take advantage of ``OFPP_IN_PORT`` in this situation. To help, Open vSwitch provides, as an OpenFlow extension, the ability to modify the in_port field. Whatever value is currently in the in_port field is the port to which outputs will be dropped, as well as the destination for ``OFPP_IN_PORT``. This means that the following will reliably output to port 2 or to ports 2 through 6, respectively:: $ ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT[],2 $ ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT[],2,3,4,5,6 If the input port is important, then one may save and restore it on the stack: $ ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\ load:0->NXM_OF_IN_PORT[],\ 2,3,4,5,6,\ pop:NXM_OF_IN_PORT[] Q: My bridge br0 has host 192.168.0.1 on port 1 and host 192.168.0.2 on port 2. I set up flows to forward only traffic destined to the other host and drop other traffic, like this:: priority=5,in_port=1,ip,nw_dst=192.168.0.2,actions=2 priority=5,in_port=2,ip,nw_dst=192.168.0.1,actions=1 priority=0,actions=drop But it doesn't work--I don't get any connectivity when I do this. Why? A: These flows drop the ARP packets that IP hosts use to establish IP connectivity over Ethernet. To solve the problem, add flows to allow ARP to pass between the hosts:: priority=5,in_port=1,arp,actions=2 priority=5,in_port=2,arp,actions=1 This issue can manifest other ways, too. The following flows that match on Ethernet addresses instead of IP addresses will also drop ARP packets, because ARP requests are broadcast instead of being directed to a specific host:: priority=5,in_port=1,dl_dst=54:00:00:00:00:02,actions=2 priority=5,in_port=2,dl_dst=54:00:00:00:00:01,actions=1 priority=0,actions=drop The solution already described above will also work in this case. It may be better to add flows to allow all multicast and broadcast traffic:: priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2 priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1 Q: My bridge disconnects from my controller on add-port/del-port. A: Reconfiguring your bridge can change your bridge's datapath-id because Open vSwitch generates datapath-id from the MAC address of one of its ports. In that case, Open vSwitch disconnects from controllers because there's no graceful way to notify controllers about the change of datapath-id. To avoid the behaviour, you can configure datapath-id manually.:: $ ovs-vsctl set bridge br0 other-config:datapath-id=0123456789abcdef Q: My controller complains that OVS is not buffering packets. What's going on? A: "Packet buffering" is an optional OpenFlow feature, and controllers should detect how many "buffers" an OpenFlow switch implements. It was recently noticed that OVS implementation of the buffering feature was not compliant to OpenFlow specifications. Rather than fix it and risk controller incompatibility, the buffering feature is removed as of OVS 2.7. Controllers are already expected to work properly in cases where the switch can not buffer packets, but sends full packets in "packet-in" messages instead, so this change should not affect existing users. After the change OVS always sends the ``buffer_id`` as ``0xffffffff`` in "packet-in" messages and will send an error response if any other value of this field is included in a "packet-out" or a "flow mod" sent by a controller. Packet buffers have limited usefulness in any case. Table-miss packet-in messages most commonly pass the first packet in a microflow to the OpenFlow controller, which then sets up an OpenFlow flow that handles remaining traffic in the microflow without further controller intervention. In such a case, the packet that initiates the microflow is in practice usually small (certainly for TCP), which means that the switch sends the entire packet to the controller and the buffer only saves a small number of bytes in the reverse direction. Q: How does OVS divide flows among buckets in an OpenFlow "select" group? A: In Open vSwitch 2.3 and earlier, Open vSwitch used the destination Ethernet address to choose a bucket in a select group. Open vSwitch 2.4 and later by default hashes the source and destination Ethernet address, VLAN ID, Ethernet type, IPv4/v6 source and destination address and protocol, and for TCP and SCTP only, the source and destination ports. The hash is "symmetric", meaning that exchanging source and destination addresses does not change the bucket selection. Select groups in Open vSwitch 2.4 and later can be configured to use a different hash function, using a Netronome extension to the OpenFlow 1.5+ group_mod message. For more information, see Documentation/group-selection-method-property.txt in the Open vSwitch source tree. Q: An OpenFlow "select" group isn't dividing packets evenly among the buckets. A: When a packet passes through a "select" group, Open vSwitch hashes a subset of the fields in the packet, then it maps the hash value to a bucket. This means that packets whose hashed fields are the same will always go to the same bucket[*]. More specifically, if you test with a single traffic flow, only one bucket will receive any traffic[**]. Furthermore, statistics and probability mean that testing with a small number of flows may still yield an uneven distribution. [*] Unless its bucket has a watch port or group whose liveness changes during the test. [**] Unless the hash includes fields that vary within a traffic flow, such as tcp_flags. Q: I added a flow to accept packets on VLAN 123 and output them on VLAN 456, like so:: $ ovs-ofctl add-flow br0 dl_vlan=123,actions=output:1,mod_vlan_vid:456 but the packets are actually being output in VLAN 123. Why? A: OpenFlow actions are executed in the order specified. Thus, the actions above first output the packet, then change its VLAN. Since the output occurs before changing the VLAN, the change in VLAN will have no visible effect. To solve this and similar problems, order actions so that changes to headers happen before output, e.g.:: $ ovs-ofctl add-flow br0 dl_vlan=123,actions=mod_vlan_vid:456,output:1 See also the following question. Q: I added a flow to a redirect packets for TCP port 80 to port 443, like so:: $ ovs-ofctl add-flow br0 tcp,tcp_dst=123,actions=mod_tp_dst:443 but the packets are getting dropped instead. Why? A: This set of actions does change the TCP destination port to 443, but then it does nothing more. It doesn't, for example, say to continue to another flow table or to output the packet. Therefore, the packet is dropped. To solve the problem, add an action that does something with the modified packet. For example:: $ ovs-ofctl add-flow br0 tcp,tcp_dst=123,actions=mod_tp_dst:443,normal See also the preceding question. Q: When using the "ct" action with FTP connections, it doesn't seem to matter if I set the "alg=ftp" parameter in the action. Is this required? A: It is advisable to use this option. Some platforms may automatically detect and apply ALGs in the "ct" action regardless of the parameters you provide, however this is not consistent across all implementations. The `ovs-ofctl(8) `_ man pages contain further details in the description of the ALG parameter. ovs-2.13.0/Documentation/faq/qos.rst000066400000000000000000000200401362155554400173260ustar00rootroot00000000000000.. 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. ======================== Quality of Service (QoS) ======================== Q: Does OVS support Quality of Service (QoS)? A: Yes. For traffic that egresses from a switch, OVS supports traffic shaping; for traffic that ingresses into a switch, OVS support policing. Policing is a simple form of quality-of-service that simply drops packets received in excess of the configured rate. Due to its simplicity, policing is usually less accurate and less effective than egress traffic shaping, which queues packets. Keep in mind that ingress and egress are from the perspective of the switch. That means that egress shaping limits the rate at which traffic is allowed to transmit from a physical interface, but not the rate at which traffic will be received on a virtual machine's VIF. For ingress policing, the behavior is the opposite. Q: How do I configure egress traffic shaping? A: Suppose that you want to set up bridge br0 connected to physical Ethernet port eth0 (a 1 Gbps device) and virtual machine interfaces vif1.0 and vif2.0, and that you want to limit traffic from vif1.0 to eth0 to 10 Mbps and from vif2.0 to eth0 to 20 Mbps. Then, you could configure the bridge this way:: $ ovs-vsctl -- \ add-br br0 -- \ add-port br0 eth0 -- \ add-port br0 vif1.0 -- set interface vif1.0 ofport_request=5 -- \ add-port br0 vif2.0 -- set interface vif2.0 ofport_request=6 -- \ set port eth0 qos=@newqos -- \ --id=@newqos create qos type=linux-htb \ other-config:max-rate=1000000000 \ queues:123=@vif10queue \ queues:234=@vif20queue -- \ --id=@vif10queue create queue other-config:max-rate=10000000 -- \ --id=@vif20queue create queue other-config:max-rate=20000000 At this point, bridge br0 is configured with the ports and eth0 is configured with the queues that you need for QoS, but nothing is actually directing packets from vif1.0 or vif2.0 to the queues that we have set up for them. That means that all of the packets to eth0 are going to the "default queue", which is not what we want. We use OpenFlow to direct packets from vif1.0 and vif2.0 to the queues reserved for them:: $ ovs-ofctl add-flow br0 in_port=5,actions=set_queue:123,normal $ ovs-ofctl add-flow br0 in_port=6,actions=set_queue:234,normal Each of the above flows matches on the input port, sets up the appropriate queue (123 for vif1.0, 234 for vif2.0), and then executes the "normal" action, which performs the same switching that Open vSwitch would have done without any OpenFlow flows being present. (We know that vif1.0 and vif2.0 have OpenFlow port numbers 5 and 6, respectively, because we set their ofport_request columns above. If we had not done that, then we would have needed to find out their port numbers before setting up these flows.) Now traffic going from vif1.0 or vif2.0 to eth0 should be rate-limited. By the way, if you delete the bridge created by the above commands, with:: $ ovs-vsctl del-br br0 then that will leave one unreferenced QoS record and two unreferenced Queue records in the Open vSwich database. One way to clear them out, assuming you don't have other QoS or Queue records that you want to keep, is:: $ ovs-vsctl -- --all destroy QoS -- --all destroy Queue If you do want to keep some QoS or Queue records, or the Open vSwitch you are using is older than version 1.8 (which added the ``--all`` option), then you will have to destroy QoS and Queue records individually. Q: How do I configure ingress policing? A: A policing policy can be configured on an interface to drop packets that arrive at a higher rate than the configured value. For example, the following commands will rate-limit traffic that vif1.0 may generate to 10Mbps: $ ovs-vsctl set interface vif1.0 ingress_policing_rate=10000 $ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000 Traffic policing can interact poorly with some network protocols and can have surprising results. The "Ingress Policing" section of ovs-vswitchd.conf.db(5) discusses the issues in greater detail. Q: I configured Quality of Service (QoS) in my OpenFlow network by adding records to the QoS and Queue table, but the results aren't what I expect. A: Did you install OpenFlow flows that use your queues? This is the primary way to tell Open vSwitch which queues you want to use. If you don't do this, then the default queue will be used, which will probably not have the effect you want. Refer to the previous question for an example. Q: I'd like to take advantage of some QoS feature that Open vSwitch doesn't yet support. How do I do that? A: Open vSwitch does not implement QoS itself. Instead, it can configure some, but not all, of the QoS features built into the Linux kernel. If you need some QoS feature that OVS cannot configure itself, then the first step is to figure out whether Linux QoS supports that feature. If it does, then you can submit a patch to support Open vSwitch configuration for that feature, or you can use "tc" directly to configure the feature in Linux. (If Linux QoS doesn't support the feature you want, then first you have to add that support to Linux.) Q: I configured QoS, correctly, but my measurements show that it isn't working as well as I expect. A: With the Linux kernel, the Open vSwitch implementation of QoS has two aspects: - Open vSwitch configures a subset of Linux kernel QoS features, according to what is in OVSDB. It is possible that this code has bugs. If you believe that this is so, then you can configure the Linux traffic control (QoS) stack directly with the "tc" program. If you get better results that way, you can send a detailed bug report to bugs@openvswitch.org. It is certain that Open vSwitch cannot configure every Linux kernel QoS feature. If you need some feature that OVS cannot configure, then you can also use "tc" directly (or add that feature to OVS). - The Open vSwitch implementation of OpenFlow allows flows to be directed to particular queues. This is pretty simple and unlikely to have serious bugs at this point. However, most problems with QoS on Linux are not bugs in Open vSwitch at all. They tend to be either configuration errors (please see the earlier questions in this section) or issues with the traffic control (QoS) stack in Linux. The Open vSwitch developers are not experts on Linux traffic control. We suggest that, if you believe you are encountering a problem with Linux traffic control, that you consult the tc manpages (e.g. tc(8), tc-htb(8), tc-hfsc(8)), web resources (e.g. http://lartc.org/), or mailing lists (e.g. http://vger.kernel.org/vger-lists.html#netdev). Q: Does Open vSwitch support OpenFlow meters? A: Open vSwitch 2.0 added OpenFlow protocol support for OpenFlow meters. Open vSwitch 2.7 implemented meters in the userspace datapath. Open vSwitch 2.10 implemented meters in the Linux kernel datapath. ovs-2.13.0/Documentation/faq/releases.rst000066400000000000000000000332521362155554400203400ustar00rootroot00000000000000.. 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. ======== Releases ======== Q: What does it mean for an Open vSwitch release to be LTS (long-term support)? A: All official releases have been through a comprehensive testing process and are suitable for production use. Planned releases occur twice a year. If a significant bug is identified in an LTS release, we will provide an updated release that includes the fix. Releases that are not LTS may not be fixed and may just be supplanted by the next major release. The current LTS release is 2.5.x. For more information on the Open vSwitch release process, refer to :doc:`/internals/release-process`. Q: What Linux kernel versions does each Open vSwitch release work with? A: The following table lists the Linux kernel versions against which the given versions of the Open vSwitch kernel module will successfully build. The Linux kernel versions are upstream kernel versions, so Linux kernels modified from the upstream sources may not build in some cases even if they are based on a supported version. This is most notably true of Red Hat Enterprise Linux (RHEL) kernels, which are extensively modified from upstream. ============ ============== Open vSwitch Linux kernel ============ ============== 1.4.x 2.6.18 to 3.2 1.5.x 2.6.18 to 3.2 1.6.x 2.6.18 to 3.2 1.7.x 2.6.18 to 3.3 1.8.x 2.6.18 to 3.4 1.9.x 2.6.18 to 3.8 1.10.x 2.6.18 to 3.8 1.11.x 2.6.18 to 3.8 2.0.x 2.6.32 to 3.10 2.1.x 2.6.32 to 3.11 2.3.x 2.6.32 to 3.14 2.4.x 2.6.32 to 4.0 2.5.x 2.6.32 to 4.3 2.6.x 3.10 to 4.7 2.7.x 3.10 to 4.9 2.8.x 3.10 to 4.12 2.9.x 3.10 to 4.13 2.10.x 3.10 to 4.17 2.11.x 3.10 to 4.18 2.12.x 3.10 to 5.0 ============ ============== Open vSwitch userspace should also work with the Linux kernel module built into Linux 3.3 and later. Open vSwitch userspace is not sensitive to the Linux kernel version. It should build against almost any kernel, certainly against 2.6.32 and later. Q: Are all features available with all datapaths? A: Open vSwitch supports different datapaths on different platforms. Each datapath has a different feature set: the following tables try to summarize the status. Supported datapaths: Linux upstream The datapath implemented by the kernel module shipped with Linux upstream. Since features have been gradually introduced into the kernel, the table mentions the first Linux release whose OVS module supports the feature. Linux OVS tree The datapath implemented by the Linux kernel module distributed with the OVS source tree. Userspace This datapath supports conventional system devices as well as DPDK and AF_XDP devices when support for those is built. This is the only datapath that works on NetBSD, FreeBSD and Mac OSX. Hyper-V Also known as the Windows datapath. The following table lists the datapath supported features from an Open vSwitch user's perspective. The "Linux upstream" column lists the Linux kernel version that introduced a given feature into its kernel module. The "Linux OVS tree" and "Userspace" columns list the Open vSwitch release versions that introduced a given feature into the included kernel module or the userspace datapath, respectively. ========================== ============== ============== ========= ======= Feature Linux upstream Linux OVS tree Userspace Hyper-V ========================== ============== ============== ========= ======= Connection tracking 4.3 2.5 2.6 YES Conntrack Fragment Reass. 4.3 2.6 2.12 YES Conntrack Timeout Policies 5.2 2.12 NO NO Conntrack Zone Limit 4.18 2.10 2.13 YES Conntrack NAT 4.6 2.6 2.8 YES Tunnel - LISP NO 2.11 NO NO Tunnel - STT NO 2.4 NO YES Tunnel - GRE 3.11 1.0 2.4 YES Tunnel - VXLAN 3.12 1.10 2.4 YES Tunnel - Geneve 3.18 2.4 2.4 YES Tunnel - GRE-IPv6 4.18 2.6 2.6 NO Tunnel - VXLAN-IPv6 4.3 2.6 2.6 NO Tunnel - Geneve-IPv6 4.4 2.6 2.6 NO Tunnel - ERSPAN 4.18 2.10 2.10 NO Tunnel - ERSPAN-IPv6 4.18 2.10 2.10 NO QoS - Policing YES 1.1 2.6 NO QoS - Shaping YES 1.1 NO NO sFlow YES 1.0 1.0 NO IPFIX 3.10 1.11 1.11 YES Set action YES 1.0 1.0 PARTIAL NIC Bonding YES 1.0 1.0 YES Multiple VTEPs YES 1.10 1.10 YES Meter action 4.15 2.10 2.7 NO ========================== ============== ============== ========= ======= Do note, however: * Only a limited set of flow fields is modifiable via the set action by the Hyper-V datapath. * Userspace datapath support, in some cases, is dependent on the associated interface types. For example, DPDK interfaces support ingress and egress policing, but not shaping. The following table lists features that do not *directly* impact an Open vSwitch user, e.g. because their absence can be hidden by the ofproto layer (usually this comes with a performance penalty). ===================== ============== ============== ========= ======= Feature Linux upstream Linux OVS tree Userspace Hyper-V ===================== ============== ============== ========= ======= SCTP flows 3.12 YES YES YES MPLS 3.19 YES YES YES UFID 4.0 YES YES NO Megaflows 3.12 YES YES NO Masked set action 4.0 YES YES NO Recirculation 3.19 YES YES YES TCP flags matching 3.13 YES YES NO Validate flow actions YES YES N/A NO Multiple datapaths YES YES YES NO Tunnel TSO - STT N/A YES NO YES ===================== ============== ============== ========= ======= Q: What DPDK version does each Open vSwitch release work with? A: The following table lists the DPDK version against which the given versions of Open vSwitch will successfully build. ============ ======= Open vSwitch DPDK ============ ======= 2.2.x 1.6 2.3.x 1.6 2.4.x 2.0 2.5.x 2.2 2.6.x 16.07.2 2.7.x 16.11.9 2.8.x 17.05.2 2.9.x 17.11.4 2.10.x 17.11.4 2.11.x 18.11.5 2.12.x 18.11.5 ============ ======= Q: Are all the DPDK releases that OVS versions work with maintained? No. DPDK follows YY.MM.n (Year.Month.Number) versioning. Typically, all DPDK releases get a stable YY.MM.1 update with bugfixes 3 months after the YY.MM.0 release. In some cases there may also be a YY.MM.2 release. DPDK LTS releases start once a year at YY.11.0 and are maintained for two years, with YY.MM.n+1 releases around every 3 months. The latest information about DPDK stable and LTS releases can be found at `DPDK stable`_. .. _DPDK stable: http://dpdk.org/doc/guides/contributing/stable.html Q: I get an error like this when I configure Open vSwitch: configure: error: Linux kernel in is version , but version newer than is not supported (please refer to the FAQ for advice) What should I do? A: You have the following options: - Use the Linux kernel module supplied with the kernel that you are using. (See also the following FAQ.) - If there is a newer released version of Open vSwitch, consider building that one, because it may support the kernel that you are building against. (To find out, consult the table in the previous FAQ.) - The Open vSwitch "master" branch may support the kernel that you are using, so consider building the kernel module from "master". All versions of Open vSwitch userspace are compatible with all versions of the Open vSwitch kernel module, so you do not have to use the kernel module from one source along with the userspace programs from the same source. Q: What features are not available in the Open vSwitch kernel datapath that ships as part of the upstream Linux kernel? A: The kernel module in upstream Linux does not include support for LISP. Work is in progress to add support for LISP to the upstream Linux version of the Open vSwitch kernel module. For now, if you need this feature, use the kernel module from the Open vSwitch distribution instead of the upstream Linux kernel module. Certain features require kernel support to function or to have reasonable performance. If the ovs-vswitchd log file indicates that a feature is not supported, consider upgrading to a newer upstream Linux release or using the kernel module paired with the userspace distribution. Q: Why do tunnels not work when using a kernel module other than the one packaged with Open vSwitch? A: Support for tunnels was added to the upstream Linux kernel module after the rest of Open vSwitch. As a result, some kernels may contain support for Open vSwitch but not tunnels. The minimum kernel version that supports each tunnel protocol is: ======== ============ Protocol Linux Kernel ======== ============ GRE 3.11 VXLAN 3.12 Geneve 3.18 ERSPAN 4.18 LISP not upstream STT not upstream ======== ============ If you are using a version of the kernel that is older than the one listed above, it is still possible to use that tunnel protocol. However, you must compile and install the kernel module included with the Open vSwitch distribution rather than the one on your machine. If problems persist after doing this, check to make sure that the module that is loaded is the one you expect. Q: Why are UDP tunnel checksums not computed for VXLAN or Geneve? A: Generating outer UDP checksums requires kernel support that was not part of the initial implementation of these protocols. If using the upstream Linux Open vSwitch module, you must use kernel 4.0 or newer. The out-of-tree modules from Open vSwitch release 2.4 and later support UDP checksums. Q: What features are not available when using the userspace datapath? A: Tunnel virtual ports are not supported, as described in the previous answer. It is also not possible to use queue-related actions. On Linux kernels before 2.6.39, maximum-sized VLAN packets may not be transmitted. Q: Should userspace or kernel be upgraded first to minimize downtime? A. In general, the Open vSwitch userspace should be used with the kernel version included in the same release or with the version from upstream Linux. However, when upgrading between two releases of Open vSwitch it is best to migrate userspace first to reduce the possibility of incompatibilities. Q: What happened to the bridge compatibility feature? A: Bridge compatibility was a feature of Open vSwitch 1.9 and earlier. When it was enabled, Open vSwitch imitated the interface of the Linux kernel "bridge" module. This allowed users to drop Open vSwitch into environments designed to use the Linux kernel bridge module without adapting the environment to use Open vSwitch. Open vSwitch 1.10 and later do not support bridge compatibility. The feature was dropped because version 1.10 adopted a new internal architecture that made bridge compatibility difficult to maintain. Now that many environments use OVS directly, it would be rarely useful in any case. To use bridge compatibility, install OVS 1.9 or earlier, including the accompanying kernel modules (both the main and bridge compatibility modules), following the instructions that come with the release. Be sure to start the ovs-brcompatd daemon. ovs-2.13.0/Documentation/faq/terminology.rst000066400000000000000000000023441362155554400211030ustar00rootroot00000000000000.. 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. =========== Terminology =========== Q: I thought Open vSwitch was a virtual Ethernet switch, but the documentation keeps talking about bridges. What's a bridge? A: In networking, the terms "bridge" and "switch" are synonyms. Open vSwitch implements an Ethernet switch, which means that it is also an Ethernet bridge. Q: What's a VLAN? A: See :doc:`vlan`. ovs-2.13.0/Documentation/faq/vlan.rst000066400000000000000000000263201362155554400174730ustar00rootroot00000000000000.. 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. ===== VLANs ===== Q: What's a VLAN? A: At the simplest level, a VLAN (short for "virtual LAN") is a way to partition a single switch into multiple switches. Suppose, for example, that you have two groups of machines, group A and group B. You want the machines in group A to be able to talk to each other, and you want the machine in group B to be able to talk to each other, but you don't want the machines in group A to be able to talk to the machines in group B. You can do this with two switches, by plugging the machines in group A into one switch and the machines in group B into the other switch. If you only have one switch, then you can use VLANs to do the same thing, by configuring the ports for machines in group A as VLAN "access ports" for one VLAN and the ports for group B as "access ports" for a different VLAN. The switch will only forward packets between ports that are assigned to the same VLAN, so this effectively subdivides your single switch into two independent switches, one for each group of machines. So far we haven't said anything about VLAN headers. With access ports, like we've described so far, no VLAN header is present in the Ethernet frame. This means that the machines (or switches) connected to access ports need not be aware that VLANs are involved, just like in the case where we use two different physical switches. Now suppose that you have a whole bunch of switches in your network, instead of just one, and that some machines in group A are connected directly to both switches 1 and 2. To allow these machines to talk to each other, you could add an access port for group A's VLAN to switch 1 and another to switch 2, and then connect an Ethernet cable between those ports. That works fine, but it doesn't scale well as the number of switches and the number of VLANs increases, because you use up a lot of valuable switch ports just connecting together your VLANs. This is where VLAN headers come in. Instead of using one cable and two ports per VLAN to connect a pair of switches, we configure a port on each switch as a VLAN "trunk port". Packets sent and received on a trunk port carry a VLAN header that says what VLAN the packet belongs to, so that only two ports total are required to connect the switches, regardless of the number of VLANs in use. Normally, only switches (either physical or virtual) are connected to a trunk port, not individual hosts, because individual hosts don't expect to see a VLAN header in the traffic that they receive. None of the above discussion says anything about particular VLAN numbers. This is because VLAN numbers are completely arbitrary. One must only ensure that a given VLAN is numbered consistently throughout a network and that different VLANs are given different numbers. (That said, VLAN 0 is usually synonymous with a packet that has no VLAN header, and VLAN 4095 is reserved.) Q: VLANs don't work. A: Do you have VLANs enabled on the physical switch that OVS is attached to? Make sure that the port is configured to trunk the VLAN or VLANs that you are using with OVS. Q: Outgoing VLAN-tagged traffic goes through OVS to my physical switch and to its destination host, but OVS seems to drop incoming return traffic. A: It's possible that you have the VLAN configured on your physical switch as the "native" VLAN. In this mode, the switch treats incoming packets either tagged with the native VLAN or untagged as part of the native VLAN. It may also send outgoing packets in the native VLAN without a VLAN tag. If this is the case, you have two choices: - Change the physical switch port configuration to tag packets it forwards to OVS with the native VLAN instead of forwarding them untagged. - Change the OVS configuration for the physical port to a native VLAN mode. For example, the following sets up a bridge with port eth0 in "native-tagged" mode in VLAN 9:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 tag=9 vlan_mode=native-tagged In this situation, "native-untagged" mode will probably work equally well. Refer to the documentation for the Port table in ovs-vswitchd.conf.db(5) for more information. Q: I added a pair of VMs on different VLANs, like this:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 tag=9 $ ovs-vsctl add-port br0 tap1 tag=10 but the VMs can't access each other, the external network, or the Internet. A: It is to be expected that the VMs can't access each other. VLANs are a means to partition a network. When you configured tap0 and tap1 as access ports for different VLANs, you indicated that they should be isolated from each other. As for the external network and the Internet, it seems likely that the machines you are trying to access are not on VLAN 9 (or 10) and that the Internet is not available on VLAN 9 (or 10). Q: I added a pair of VMs on the same VLAN, like this:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 tag=9 $ ovs-vsctl add-port br0 tap1 tag=9 The VMs can access each other, but not the external network or the Internet. A: It seems likely that the machines you are trying to access in the external network are not on VLAN 9 and that the Internet is not available on VLAN 9. Also, ensure VLAN 9 is set up as an allowed trunk VLAN on the upstream switch port to which eth0 is connected. Q: Can I configure an IP address on a VLAN? A: Yes. Use an "internal port" configured as an access port. For example, the following configures IP address 192.168.0.7 on VLAN 9. That is, OVS will forward packets from eth0 to 192.168.0.7 only if they have an 802.1Q header with VLAN 9. Conversely, traffic forwarded from 192.168.0.7 to eth0 will be tagged with an 802.1Q header with VLAN 9:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 vlan9 tag=9 \ -- set interface vlan9 type=internal $ ip addr add 192.168.0.7/24 dev vlan9 $ ip link set vlan9 up See also the following question. Q: I configured one IP address on VLAN 0 and another on VLAN 9, like this:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ip addr add 192.168.0.5/24 dev br0 $ ip link set br0 up $ ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal $ ip addr add 192.168.0.9/24 dev vlan9 $ ip link set vlan9 up but other hosts that are only on VLAN 0 can reach the IP address configured on VLAN 9. What's going on? A: `RFC 1122 section 3.3.4.2 "Multihoming Requirements" `__ describes two approaches to IP address handling in Internet hosts: - In the "Strong ES Model", where an ES is a host ("End System"), an IP address is primarily associated with a particular interface. The host discards packets that arrive on interface A if they are destined for an IP address that is configured on interface B. The host never sends packets from interface A using a source address configured on interface B. - In the "Weak ES Model", an IP address is primarily associated with a host. The host accepts packets that arrive on any interface if they are destined for any of the host's IP addresses, even if the address is configured on some interface other than the one on which it arrived. The host does not restrict itself to sending packets from an IP address associated with the originating interface. Linux uses the weak ES model. That means that when packets destined to the VLAN 9 IP address arrive on eth0 and are bridged to br0, the kernel IP stack accepts them there for the VLAN 9 IP address, even though they were not received on vlan9, the network device for vlan9. To simulate the strong ES model on Linux, one may add iptables rule to filter packets based on source and destination address and adjust ARP configuration with sysctls. BSD uses the strong ES model. Q: My OpenFlow controller doesn't see the VLANs that I expect. A: The configuration for VLANs in the Open vSwitch database (e.g. via ovs-vsctl) only affects traffic that goes through Open vSwitch's implementation of the OpenFlow "normal switching" action. By default, when Open vSwitch isn't connected to a controller and nothing has been manually configured in the flow table, all traffic goes through the "normal switching" action. But, if you set up OpenFlow flows on your own, through a controller or using ovs-ofctl or through other means, then you have to implement VLAN handling yourself. You can use "normal switching" as a component of your OpenFlow actions, e.g. by putting "normal" into the lists of actions on ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow controller. In situations where this is not suitable, you can implement VLAN handling yourself, e.g.: - If a packet comes in on an access port, and the flow table needs to send it out on a trunk port, then the flow can add the appropriate VLAN tag with the "mod_vlan_vid" action. - If a packet comes in on a trunk port, and the flow table needs to send it out on an access port, then the flow can strip the VLAN tag with the "strip_vlan" action. Q: I configured ports on a bridge as access ports with different VLAN tags, like this:: $ ovs-vsctl add-br br0 $ ovs-vsctl set-controller br0 tcp:192.168.0.10:6653 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 tap0 tag=9 $ ovs-vsctl add-port br0 tap1 tag=10 but the VMs running behind tap0 and tap1 can still communicate, that is, they are not isolated from each other even though they are on different VLANs. A: Do you have a controller configured on br0 (as the commands above do)? If so, then this is a variant on the previous question, "My OpenFlow controller doesn't see the VLANs that I expect," and you can refer to the answer there for more information. Q: How MAC learning works with VLANs? A: Open vSwitch implements Independent VLAN Learning (IVL) for ``OFPP_NORMAL`` action, e.g. it logically has separate learning tables for each VLANs. ovs-2.13.0/Documentation/faq/vxlan.rst000066400000000000000000000042021362155554400176560ustar00rootroot00000000000000.. 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. ====== VXLANs ====== Q: What's a VXLAN? A: VXLAN stands for Virtual eXtensible Local Area Network, and is a means to solve the scaling challenges of VLAN networks in a multi-tenant environment. VXLAN is an overlay network which transports an L2 network over an existing L3 network. For more information on VXLAN, please see `RFC 7348 `__. Q: How much of the VXLAN protocol does Open vSwitch currently support? A: Open vSwitch currently supports the framing format for packets on the wire. There is currently no support for the multicast aspects of VXLAN. To get around the lack of multicast support, it is possible to pre-provision MAC to IP address mappings either manually or from a controller. Q: What destination UDP port does the VXLAN implementation in Open vSwitch use? A: By default, Open vSwitch will use the assigned IANA port for VXLAN, which is 4789. However, it is possible to configure the destination UDP port manually on a per-VXLAN tunnel basis. An example of this configuration is provided below.:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 vxlan1 -- set interface vxlan1 type=vxlan \ options:remote_ip=192.168.1.2 options:key=flow options:dst_port=8472 ovs-2.13.0/Documentation/group-selection-method-property.txt000066400000000000000000000113711362155554400242520ustar00rootroot00000000000000Proposal for Group Selection Method Property Version: 0.0.3 Author: Simon Horman , et al. Initial Public Revision: September 2014 Contents ======== 1. Introduction 2. How it Works 3. Experimenter Id 4. Experimenter Messages 5. History 1. Introduction =============== This text describes a Netronome Extension to OpenFlow 1.5 that allows a controller to provide more information on the selection method for select groups. This proposal is in the form of an enhanced select group type. This may subsequently be proposed as an extension or update to the OpenFlow specification. 2. How it works =============== A new Netronome group experimenter property is defined which provides compatibility with the group mod message defined in Open Flow 1.5 (also known as ONF EXT-350) and allows parameters for the selection method of select groups to be passed by the controller. In particular it allows controllers to: * Specify the fields used for bucket selection by the select group. * Designate the selection method used. * Provide a non-field parameter to the selection method. 3. Experimenter ID ================== The Experimenter ID of this extension is: NTR_VENDOR_ID = 0x0000154d 4. Group Experimenter Property ============================== The following group property experimenter type defined by this extension. enum ntr_group_mod_subtype { NTRT_SELECTION_METHOD = 1, }; Modifications to the group table from the controller may be done with a OFPT_GROUP_MOD message described Open Flow 1.5. Group Entry Message. Of relevance here is that Open Flow 1.5 group messages have properties. This proposal is defined in terms of an implementation of struct ofp_group_prop_experimenter which is described in Open Flow 1.5. The implementation is: struct ntr_group_prop_selection_method { ovs_be16 type; /* OFPGPT_EXPERIMENTER. */ ovs_be16 length; /* Length in bytes of this property. */ ovs_be32 experimenter; /* NTR_VENDOR_ID. */ ovs_be32 exp_type; /* NTRT_SELECTION_METHOD. */ ovs_be32 pad; char selection_method[NTR_MAX_SELECTION_METHOD_LEN]; /* Null-terminated */ ovs_be64 selection_method_param; /* Non-Field parameter for * bucket selection. */ /* Followed by: * - Exactly (length - 40) (possibly 0) bytes containing OXM TLVs, then * - Exactly ((length + 7)/8*8 - length) (between 0 and 7) bytes of * all-zero bytes * In summary, ntr_group_prop_selection_method is padded as needed, * to make its overall size a multiple of 8, to preserve alignment * in structures using it. */ /* uint8_t field_array[0]; */ /* Zero or more fields encoded as * OXM TLVs where the has_mask bit must * be zero and the value it specifies is * a mask to apply to packet fields and * then input them to the selection * method of a select group. */ /* uint8_t pad2[0]; */ }; OFP_ASSERT(sizeof(struct ntr_group_mod) == 40); This property may only be used with group mod messages whose: * command is OFPGC_ADD or OFPGC_MODIFY; and * type is OFPGT_SELECT The type field is the OFPGPT_EXPERIMENTER which is defined in EXT-350 as 0xffff. The experimenter field is the Experimenter ID (see 3). The exp_type field is NTRT_SELECTION_METHOD. The group selection_method is a null-terminated string which if non-zero length specifies a selection method known to an underlying layer of the switch. The value of NTR_MAX_SELECTION_METHOD_LEN is 16. The group selection_method may be zero-length to request compatibility with Open Flow 1.4. The selection_method_param provides a non-field parameter for the group selection_method. It must be all-zeros unless the group selection_method is non-zero length. The selection_method_param may for example be used as an initial value for the hash of a hash group selection method. The fields field is an ofp_match structure which includes the fields which should be used as inputs to bucket selection. ofp_match is described in Open Flow 1.4 section 7.2.2 Flow Match Structures. Fields must not be specified unless the group selection_method is non-zero length. The pre-requisites for fields specified must be satisfied in the match for any flow that uses the group. Masking is allowed but not required for fields whose TLVs allow masking. The fields may for example be used as the fields that are hashed by a hash group selection method. 5. History ========== This proposal has been developed independently of any similar work in this area. No such work is known. ovs-2.13.0/Documentation/howto/000077500000000000000000000000001362155554400163675ustar00rootroot00000000000000ovs-2.13.0/Documentation/howto/dpdk.rst000066400000000000000000000345561362155554400200600ustar00rootroot00000000000000.. 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. ============================ Using Open vSwitch with DPDK ============================ This document describes how to use Open vSwitch with DPDK. .. important:: Using DPDK with OVS requires configuring OVS at build time to use the DPDK library. The version of DPDK that OVS supports varies from one OVS release to another, as described in the :doc:`releases FAQ `. For build instructions refer to :doc:`/intro/install/dpdk`. Ports and Bridges ----------------- ovs-vsctl can be used to set up bridges and other Open vSwitch features. Bridges should be created with a ``datapath_type=netdev``:: $ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev ovs-vsctl can also be used to add DPDK devices. ovs-vswitchd should print the number of dpdk devices found in the log file:: $ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \ options:dpdk-devargs=0000:01:00.0 $ ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk \ options:dpdk-devargs=0000:01:00.1 Some NICs (i.e. Mellanox ConnectX-3) have only one PCI address associated with multiple ports. Using a PCI device like above won't work. Instead, below usage is suggested:: $ ovs-vsctl add-port br0 dpdk-p0 -- set Interface dpdk-p0 type=dpdk \ options:dpdk-devargs="class=eth,mac=00:11:22:33:44:55" $ ovs-vsctl add-port br0 dpdk-p1 -- set Interface dpdk-p1 type=dpdk \ options:dpdk-devargs="class=eth,mac=00:11:22:33:44:56" .. important:: Hotplugging physical interfaces is not supported using the above syntax. This is expected to change with the release of DPDK v18.05. For information on hotplugging physical interfaces, you should instead refer to :ref:`port-hotplug`. After the DPDK ports get added to switch, a polling thread continuously polls DPDK devices and consumes 100% of the core, as can be checked from ``top`` and ``ps`` commands:: $ top -H $ ps -eLo pid,psr,comm | grep pmd Creating bonds of DPDK interfaces is slightly different to creating bonds of system interfaces. For DPDK, the interface type and devargs must be explicitly set. For example:: $ ovs-vsctl add-bond br0 dpdkbond p0 p1 \ -- set Interface p0 type=dpdk options:dpdk-devargs=0000:01:00.0 \ -- set Interface p1 type=dpdk options:dpdk-devargs=0000:01:00.1 To stop ovs-vswitchd & delete bridge, run:: $ ovs-appctl -t ovs-vswitchd exit $ ovs-appctl -t ovsdb-server exit $ ovs-vsctl del-br br0 .. _dpdk-ovs-in-guest: OVS with DPDK Inside VMs ------------------------ Additional configuration is required if you want to run ovs-vswitchd with DPDK backend inside a QEMU virtual machine. ovs-vswitchd creates separate DPDK TX queues for each CPU core available. This operation fails inside QEMU virtual machine because, by default, VirtIO NIC provided to the guest is configured to support only single TX queue and single RX queue. To change this behavior, you need to turn on ``mq`` (multiqueue) property of all ``virtio-net-pci`` devices emulated by QEMU and used by DPDK. You may do it manually (by changing QEMU command line) or, if you use Libvirt, by adding the following string to ```` sections of all network devices used by DPDK:: where: ``N`` determines how many queues can be used by the guest. This requires QEMU >= 2.2. .. _dpdk-phy-phy: PHY-PHY ------- Add a userspace bridge and two ``dpdk`` (PHY) ports:: # Add userspace bridge $ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev # Add two dpdk ports $ ovs-vsctl add-port br0 phy0 -- set Interface phy0 type=dpdk \ options:dpdk-devargs=0000:01:00.0 ofport_request=1 $ ovs-vsctl add-port br0 phy1 -- set Interface phy1 type=dpdk options:dpdk-devargs=0000:01:00.1 ofport_request=2 Add test flows to forward packets between DPDK port 0 and port 1:: # Clear current flows $ ovs-ofctl del-flows br0 # Add flows between port 1 (phy0) to port 2 (phy1) $ ovs-ofctl add-flow br0 in_port=1,action=output:2 $ ovs-ofctl add-flow br0 in_port=2,action=output:1 Transmit traffic into either port. You should see it returned via the other. .. _dpdk-vhost-loopback: PHY-VM-PHY (vHost Loopback) --------------------------- Add a userspace bridge, two ``dpdk`` (PHY) ports, and two ``dpdkvhostuser`` ports:: # Add userspace bridge $ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev # Add two dpdk ports $ ovs-vsctl add-port br0 phy0 -- set Interface phy0 type=dpdk \ options:dpdk-devargs=0000:01:00.0 ofport_request=1 $ ovs-vsctl add-port br0 phy1 -- set Interface phy1 type=dpdk options:dpdk-devargs=0000:01:00.1 ofport_request=2 # Add two dpdkvhostuser ports $ ovs-vsctl add-port br0 dpdkvhostuser0 \ -- set Interface dpdkvhostuser0 type=dpdkvhostuser ofport_request=3 $ ovs-vsctl add-port br0 dpdkvhostuser1 \ -- set Interface dpdkvhostuser1 type=dpdkvhostuser ofport_request=4 Add test flows to forward packets between DPDK devices and VM ports:: # Clear current flows $ ovs-ofctl del-flows br0 # Add flows $ ovs-ofctl add-flow br0 in_port=1,action=output:3 $ ovs-ofctl add-flow br0 in_port=3,action=output:1 $ ovs-ofctl add-flow br0 in_port=4,action=output:2 $ ovs-ofctl add-flow br0 in_port=2,action=output:4 # Dump flows $ ovs-ofctl dump-flows br0 Create a VM using the following configuration: .. table:: ===================== ======== ============ Configuration Values Comments ===================== ======== ============ QEMU version 2.2.0 n/a QEMU thread affinity core 5 taskset 0x20 Memory 4GB n/a Cores 2 n/a Qcow2 image CentOS7 n/a mrg_rxbuf off n/a ===================== ======== ============ You can do this directly with QEMU via the ``qemu-system-x86_64`` application:: $ export VM_NAME=vhost-vm $ export GUEST_MEM=3072M $ export QCOW2_IMAGE=/root/CentOS7_x86_64.qcow2 $ export VHOST_SOCK_DIR=/usr/local/var/run/openvswitch $ taskset 0x20 qemu-system-x86_64 -name $VM_NAME -cpu host -enable-kvm \ -m $GUEST_MEM -drive file=$QCOW2_IMAGE --nographic -snapshot \ -numa node,memdev=mem -mem-prealloc -smp sockets=1,cores=2 \ -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on \ -chardev socket,id=char0,path=$VHOST_SOCK_DIR/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \ -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mrg_rxbuf=off \ -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser1 \ -netdev type=vhost-user,id=mynet2,chardev=char1,vhostforce \ -device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2,mrg_rxbuf=off For a explanation of this command, along with alternative approaches such as booting the VM via libvirt, refer to :doc:`/topics/dpdk/vhost-user`. Once the guest is configured and booted, configure DPDK packet forwarding within the guest. To accomplish this, build the ``testpmd`` application as described in :ref:`dpdk-testpmd`. Once compiled, run the application:: $ cd $DPDK_DIR/app/test-pmd; $ ./testpmd -c 0x3 -n 4 --socket-mem 1024 -- \ --burst=64 -i --txqflags=0xf00 --disable-hw-vlan $ set fwd mac retry $ start When you finish testing, bind the vNICs back to kernel:: $ $DPDK_DIR/usertools/dpdk-devbind.py --bind=virtio-pci 0000:00:03.0 $ $DPDK_DIR/usertools/dpdk-devbind.py --bind=virtio-pci 0000:00:04.0 .. note:: Valid PCI IDs must be passed in above example. The PCI IDs can be retrieved like so:: $ $DPDK_DIR/usertools/dpdk-devbind.py --status More information on the dpdkvhostuser ports can be found in :doc:`/topics/dpdk/vhost-user`. PHY-VM-PHY (vHost Loopback) (Kernel Forwarding) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :ref:`dpdk-vhost-loopback` details steps for PHY-VM-PHY loopback testcase and packet forwarding using DPDK testpmd application in the Guest VM. For users wishing to do packet forwarding using kernel stack below, you need to run the below commands on the guest:: $ ip addr add 1.1.1.2/24 dev eth1 $ ip addr add 1.1.2.2/24 dev eth2 $ ip link set eth1 up $ ip link set eth2 up $ systemctl stop firewalld.service $ systemctl stop iptables.service $ sysctl -w net.ipv4.ip_forward=1 $ sysctl -w net.ipv4.conf.all.rp_filter=0 $ sysctl -w net.ipv4.conf.eth1.rp_filter=0 $ sysctl -w net.ipv4.conf.eth2.rp_filter=0 $ route add -net 1.1.2.0/24 eth2 $ route add -net 1.1.1.0/24 eth1 $ arp -s 1.1.2.99 DE:AD:BE:EF:CA:FE $ arp -s 1.1.1.99 DE:AD:BE:EF:CA:EE PHY-VM-PHY (vHost Multiqueue) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ vHost Multiqueue functionality can also be validated using the PHY-VM-PHY configuration. To begin, follow the steps described in :ref:`dpdk-phy-phy` to create and initialize the database, start ovs-vswitchd and add ``dpdk``-type devices to bridge ``br0``. Once complete, follow the below steps: 1. Configure PMD and RXQs. For example, set the number of dpdk port rx queues to at least 2 The number of rx queues at vhost-user interface gets automatically configured after virtio device connection and doesn't need manual configuration:: $ ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0xc $ ovs-vsctl set Interface phy0 options:n_rxq=2 $ ovs-vsctl set Interface phy1 options:n_rxq=2 2. Instantiate Guest VM using QEMU cmdline We must configure with appropriate software versions to ensure this feature is supported. .. list-table:: VM Configuration :header-rows: 1 * - Setting - Value * - QEMU version - 2.5.0 * - QEMU thread affinity - 2 cores (taskset 0x30) * - Memory - 4 GB * - Cores - 2 * - Distro - Fedora 22 * - Multiqueue - Enabled To do this, instantiate the guest as follows:: $ export VM_NAME=vhost-vm $ export GUEST_MEM=4096M $ export QCOW2_IMAGE=/root/Fedora22_x86_64.qcow2 $ export VHOST_SOCK_DIR=/usr/local/var/run/openvswitch $ taskset 0x30 qemu-system-x86_64 -cpu host -smp 2,cores=2 -m 4096M \ -drive file=$QCOW2_IMAGE --enable-kvm -name $VM_NAME \ -nographic -numa node,memdev=mem -mem-prealloc \ -object memory-backend-file,id=mem,size=$GUEST_MEM,mem-path=/dev/hugepages,share=on \ -chardev socket,id=char1,path=$VHOST_SOCK_DIR/dpdkvhostuser0 \ -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=2 \ -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1,mq=on,vectors=6 \ -chardev socket,id=char2,path=$VHOST_SOCK_DIR/dpdkvhostuser1 \ -netdev type=vhost-user,id=mynet2,chardev=char2,vhostforce,queues=2 \ -device virtio-net-pci,mac=00:00:00:00:00:02,netdev=mynet2,mq=on,vectors=6 .. note:: Queue value above should match the queues configured in OVS, The vector value should be set to "number of queues x 2 + 2" 3. Configure the guest interface Assuming there are 2 interfaces in the guest named eth0, eth1 check the channel configuration and set the number of combined channels to 2 for virtio devices:: $ ethtool -l eth0 $ ethtool -L eth0 combined 2 $ ethtool -L eth1 combined 2 More information can be found in vHost walkthrough section. 4. Configure kernel packet forwarding Configure IP and enable interfaces:: $ ip addr add 5.5.5.1/24 dev eth0 $ ip addr add 90.90.90.1/24 dev eth1 $ ip link set eth0 up $ ip link set eth1 up Configure IP forwarding and add route entries:: $ sysctl -w net.ipv4.ip_forward=1 $ sysctl -w net.ipv4.conf.all.rp_filter=0 $ sysctl -w net.ipv4.conf.eth0.rp_filter=0 $ sysctl -w net.ipv4.conf.eth1.rp_filter=0 $ ip route add 2.1.1.0/24 dev eth1 $ route add default gw 2.1.1.2 eth1 $ route add default gw 90.90.90.90 eth1 $ arp -s 90.90.90.90 DE:AD:BE:EF:CA:FE $ arp -s 2.1.1.2 DE:AD:BE:EF:CA:FA Check traffic on multiple queues:: $ cat /proc/interrupts | grep virtio .. _dpdk-flow-hardware-offload: Flow Hardware Offload (Experimental) ------------------------------------ The flow hardware offload is disabled by default and can be enabled by:: $ ovs-vsctl set Open_vSwitch . other_config:hw-offload=true Matches and actions are programmed into HW to achieve full offload of the flow. If not all actions are supported, fallback to partial flow offload (offloading matches only). Moreover, it only works with PMD drivers that support the configured rte_flow actions. Partial flow offload requires support of "MARK + RSS" actions. Full hardware offload requires support of the actions listed below. The validated NICs are: - Mellanox (ConnectX-4, ConnectX-4 Lx, ConnectX-5) - Napatech (NT200B01) Supported protocols for hardware offload matches are: - L2: Ethernet, VLAN - L3: IPv4 - L4: TCP, UDP, SCTP, ICMP Supported actions for hardware offload are: - Output. - Drop. - Modification of Ethernet (mod_dl_src/mod_dl_dst). - Modification of IPv4 (mod_nw_src/mod_nw_dst/mod_nw_ttl). - Modification of TCP/UDP (mod_tp_src/mod_tp_dst). Further Reading --------------- More detailed information can be found in the :doc:`DPDK topics section ` of the documentation. These guides are listed below. .. NOTE(stephenfin): Remember to keep this in sync with topics/dpdk/index .. include:: ../topics/dpdk/index.rst :start-line: 30 ovs-2.13.0/Documentation/howto/index.rst000066400000000000000000000024011362155554400202250ustar00rootroot00000000000000.. 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. ============= How-to Guides ============= Answers to common "How do I?"-style questions. For more information on the topics covered herein, refer to :doc:`/topics/index`. OVS --- .. toctree:: :maxdepth: 2 kvm ipsec selinux libvirt ssl lisp tunneling userspace-tunneling vlan qos vtep sflow dpdk ovs-2.13.0/Documentation/howto/ipsec.rst000066400000000000000000000206141362155554400202270ustar00rootroot00000000000000.. 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. ======================================= 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`. 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`. ovs-2.13.0/Documentation/howto/kvm.rst000066400000000000000000000060651362155554400177250ustar00rootroot00000000000000.. 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 with KVM ===================== This document describes how to use Open vSwitch with the Kernel-based Virtual Machine (KVM). .. note:: This document assumes that you have Open vSwitch set up on a Linux system. Setup ----- KVM uses tunctl to handle various bridging modes, which you can install with the Debian/Ubuntu package ``uml-utilities``:: $ apt-get install uml-utilities Next, you will need to modify or create custom versions of the ``qemu-ifup`` and ``qemu-ifdown`` scripts. In this guide, we'll create custom versions that make use of example Open vSwitch bridges that we'll describe in this guide. Create the following two files and store them in known locations. For example:: $ cat << 'EOF' > /etc/ovs-ifup #!/bin/sh switch='br0' ip link set $1 up ovs-vsctl add-port ${switch} $1 EOF :: $ cat << 'EOF' > /etc/ovs-ifdown #!/bin/sh switch='br0' ip addr flush dev $1 ip link set $1 down ovs-vsctl del-port ${switch} $1 EOF The basic usage of Open vSwitch is described at the end of :doc:`/intro/install/general`. If you haven't already, create a bridge named ``br0`` with the following command:: $ ovs-vsctl add-br br0 Then, add a port to the bridge for the NIC that you want your guests to communicate over (e.g. ``eth0``):: $ ovs-vsctl add-port br0 eth0 Refer to ovs-vsctl(8) for more details. Next, we'll start a guest that will use our ifup and ifdown scripts:: $ kvm -m 512 -net nic,macaddr=00:11:22:EE:EE:EE -net \ tap,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -drive \ file=/path/to/disk-image,boot=on This will start the guest and associate a tap device with it. The ``ovs-ifup`` script will add a port on the br0 bridge so that the guest will be able to communicate over that bridge. To get some more information and for debugging you can use Open vSwitch utilities such as ovs-dpctl and ovs-ofctl, For example:: $ ovs-dpctl show $ ovs-ofctl show br0 You should see tap devices for each KVM guest added as ports to the bridge (e.g. tap0) Refer to ovs-dpctl(8) and ovs-ofctl(8) for more details. Bug Reporting ------------- Please report problems to bugs@openvswitch.org. ovs-2.13.0/Documentation/howto/libvirt.rst000066400000000000000000000061551362155554400206030ustar00rootroot00000000000000.. 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 with Libvirt ========================= This document describes how to use Open vSwitch with Libvirt 0.9.11 or later. This document assumes that you followed :doc:`/intro/install/general` or installed Open vSwitch from distribution packaging such as a .deb or .rpm. The Open vSwitch support is included by default in Libvirt 0.9.11. Consult www.libvirt.org for instructions on how to build the latest Libvirt, if your Linux distribution by default comes with an older Libvirt release. Limitations ----------- Currently there is no Open vSwitch support for networks that are managed by libvirt (e.g. NAT). As of now, only bridged networks are supported (those where the user has to manually create the bridge). Setup ----- First, create the Open vSwitch bridge by using the ovs-vsctl utility (this must be done with administrative privileges):: $ ovs-vsctl add-br ovsbr Once that is done, create a VM, if necessary, and edit its Domain XML file:: $ virsh edit Lookup in the Domain XML file the ```` section. There should be one such XML section for each interface the VM has::
And change it to something like this::
The interface type must be set to ``bridge``. The ```` XML element specifies to which bridge this interface will be attached to. The ```` element indicates that the bridge in ```` element is an Open vSwitch bridge. Then (re)start the VM and verify if the guest's vnet interface is attached to the ovsbr bridge:: $ ovs-vsctl show Troubleshooting --------------- If the VM does not want to start, then try to run the libvirtd process either from the terminal, so that all errors are printed in console, or inspect Libvirt/Open vSwitch log files for possible root cause. Bug Reporting ------------- Report problems to bugs@openvswitch.org. ovs-2.13.0/Documentation/howto/lisp.rst000066400000000000000000000114131362155554400200700ustar00rootroot00000000000000.. 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. ==================== Using LISP tunneling ==================== LISP is a layer 3 tunneling mechanism, meaning that encapsulated packets do not carry Ethernet headers, and ARP requests shouldn't be sent over the tunnel. Because of this, there are some additional steps required for setting up LISP tunnels in Open vSwitch, until support for L3 tunnels will improve. This guide assumes tunneling between two VMs connected to OVS bridges on different hypervisors reachable over IPv4. Of course, more than one VM may be connected to any of the hypervisors, and a hypervisor may communicate with several different hypervisors over the same lisp tunneling interface. A LISP "map-cache" can be implemented using flows, see example at the bottom of this file. There are several scenarios: 1) the VMs have IP addresses in the same subnet and the hypervisors are also in a single subnet (although one different from the VM's); 2) the VMs have IP addresses in the same subnet but the hypervisors are separated by a router; 3) the VMs are in different subnets. In cases 1) and 3) ARP resolution can work as normal: ARP traffic is configured not to go through the LISP tunnel. For case 1) ARP is able to reach the other VM, if both OVS instances default to MAC address learning. Case 3) requires the hypervisor be configured as the default router for the VMs. In case 2) the VMs expect ARP replies from each other, but this is not possible over a layer 3 tunnel. One solution is to have static MAC address entries preconfigured on the VMs (e.g., ``arp -f /etc/ethers`` on startup on Unix based VMs), or have the hypervisor do proxy ARP. In this scenario, the eth0 interfaces need not be added to the br0 bridge in the examples below. On the receiving side, the packet arrives without the original MAC header. The LISP tunneling code attaches a header with hard-coded source and destination MAC address ``02:00:00:00:00:00``. This address has all bits set to 0, except the locally administered bit, in order to avoid potential collisions with existing allocations. In order for packets to reach their intended destination, the destination MAC address needs to be rewritten. This can be done using the flow table. See below for an example setup, and the associated flow rules to enable LISP tunneling. :: Diagram +---+ +---+ |VM1| |VM2| +---+ +---+ | | +--[tap0]--+ +--[tap0]---+ | | | | [lisp0] OVS1 [eth0]-----------------[eth0] OVS2 [lisp0] | | | | +----------+ +-----------+ On each hypervisor, interfaces tap0, eth0, and lisp0 are added to a single bridge instance, and become numbered 1, 2, and 3 respectively: :: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 tap0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 lisp0 \ -- set Interface lisp0 type=lisp options:remote_ip=flow options:key=flow The last command sets up flow based tunneling on the lisp0 interface. From the LISP point of view, this is like having the Tunnel Router map cache implemented as flow rules. Flows on br0 should be configured as follows: :: priority=3,dl_dst=02:00:00:00:00:00,action=mod_dl_dst:,output:1 priority=2,in_port=1,dl_type=0x0806,action=NORMAL priority=1,in_port=1,dl_type=0x0800,vlan_tci=0,nw_src=,action=set_field:->tun_dst,output:3 priority=0,action=NORMAL The third rule is like a map cache entry: the ```` specified by the ``nw_src`` match field is mapped to the RLOC ````, which is set as the tunnel destination for this particular flow. Optionally, if you want to use Instance ID in a flow, you can add ``set_tunnel:`` to the action list. ovs-2.13.0/Documentation/howto/qos.png000066400000000000000000002103511362155554400177010ustar00rootroot00000000000000PNG  IHDRZ)LiCCPICC ProfilexYy8߷{&spdvyscL)JATH*dhPJE$L}5|s~Zkλ:QÃaFBB"l(.;+2\ ϥub3d=#B|X+<" *B`}3G "6/A J()1^~XPPz^Hm.zT?:T߂D&6 مG#WcBzBhoXό7yr!_>Cd P;%C=-`-#[#c!(m37<=)_iWOi lg1"n3D0QDo>0`d[f 2ݞ9P \0DR?T"ABp2" `9燌) g߳Q9 K"sl󶭋tHל%FVvV_hy"ZB ;*h]6Z#0hkFߘx5G=r/ \_ Ca~Q]dHRLC%)r7m{mbOE$DE 8-$qEF⎾y^1dd@" gyԁ0f ď? ) iPJ@9.F @S`| ;؀ !2BB$@Z!dB.B( : P5t u@gkh B0 &07, *.l{a?x9p\Mp~ Ÿe@ѡXQ|() JerE"PI,T> UjEFQs54MFSRH^}$t6} ݄B?GЛ" #QØb1~XL&SƼLbcXVVkubc v38vñ$p8+pU:^y#WPT|;444BjV޴񴹴x^Sz|7~NΆ.. }15AOC&ׄ%"(L!9j=qL/MoJM~~AA!!C?#-0>#1&2L#YBH٤ Iɐɛ)8E 듽i r7y,l|2&,,q,E,YFYQ¬;wqdG+ll:l>lYl l/)A'؛ه9699899889p\\\ʹyùra 3K BѥS (]>.>h |O6ES*y  R:#+","$),<#&b* R+N(-OLVLE,HSqX\Q_H_P8'L#**Y&9$EҕfNnq9!+)(,[!VIL.UU| Aŝ;}vJK1SS񧒲RRҬr J}UA655%(F/RA53">T Z-RQm>mvoJi]1@:y=Yz+j(c,'L#FF~FF ƊM0&&'LLMLM̔ͺ v,-",ZwvR2Բ XZg}kcmSd3e+g{׎lnWc^>CC#j'N2ΉΏ\8\\Z\q˻ w=GqOƞ"{>pp vNupAQ=M==x}93{wO߬\~@abI`IJUPUVSpCMGPРЮ0g޷aQ ElbF.}ѢчbbbVccőBO'%\܏ﵿ߁c$Ϥ΃N&'_J^:hyMZu77fg7nv޸%}6;;w&]not|{ދ.'{z޽yڃU6?RzԧwO4+ KOM@!:22zBݬ*952_R^H }."/;&oШȥE^M_ּ }68*&gL-jw[umBluO9Ĝ\\#v9{%jgWyB,5$9CBCg^k̏:k/c?PbGR3))!i҇820?r=hvc999sN;yӉQg <:K:Ow~dɅke*Yp/K{i=}LxɻuN$={aRmP`8jηʆO$;fAq2:ztLl]sCK烾(/`뾦/y|]ڇ?~~.J5dbp4,4Ӵ=JlB ѝބADG$0ؕ99/p pPrB҈H!R8s\IJ9VSNNHsL[L'DQo@0ͨɬ9ւRJZFVN^AȑӉ8qq}uυn=u'nPKq=.ngwᇃ<{gyЇWLnnxadѵиЄdTYGO'^ϋI[jtkY{êڭ C/ }ϡ4蛘vBDk/u | $,+YYŐqG [2i˜\#Y>K0BKlb~ْW+dS|4BPU3Q8YU]s^7W/I?PHؘxƤY+%u6IjvW;:;;.㷗wqwSȣ#/?PD . q % 7هw/"%R+GŘx$RX $$DĊPbC_2oܿ@ AWo:8%5 >-}]]]ߵ3@r !7FΏ>ثw!!"4< &o",8, :~a)xï(~)*U@}B"=t(E,L V`7qʸeG_Jd Jg8|*6x^̐э9ɜԃ2=d Kf*"K+;;VJW88]\]I}~+JX!3aAHdTS $} edv(J(+ȩ hjjhы570Z76u42ii`uzVr:8oRwram}zto ]?! z_,o܋VIߧ\I<䙩s5]v\$gr韣*+뮨,t&ε^L#u&| F.ѩEɸc~g/8^+56zm2sG%ʲJٍ[?G@!'2F ;JRg@RCK#$ A{8(jD|&Ê3| (6*uՃZB H~>d6H.~ +Öcq{pŸa 7M5 m m F$? zWBI~yx2|Y>7Vp`óc?ȡɱɕmdzM)d.4*XMARDXHtLlCeE%Ies7h\Zs$5]< #yPZqحىvsqnuޝ>O _L f 3HHxqpCڙ=Y9Y,O_K[.}!"oܥ[5G, W0ilYl}VyPOiL}ܣ7~vyKWoᇛ{~0Y:<8dJXxSqр'A*MFi4^2E*BH ZY` >(JYP8:]p#=3eaOc_xq:REɣU=Bҕ@Rߘac`& 2yȭa,,.Aϱ9S[B);_.P/&@xHdV Pt:,}CfJKIηJ*wHZGt< LLͽ,,C&mmGœ7]AE{z;bn"ws;^5Y_I?-C]=1rtҳNjRŔ_)^VM,pscV6ۣw;iv?T|qY3#_x I ۏľx|p䳩ƙď/J_Vn.F}:Tj^} ~5uՍs?LRDDCʏ#[[KH$?Olmmmm,G ?Wl c{q6OO~{/ pHYs   IDATx `ս'%H  T/%(hA-hJ(p+>@U(TAKKl TP噄lMvNv7!@v(3gw>gfw9s&NF$@$@$@N <$@$@$@$y@$@$@$ iY   j$@$@$@@&je   9@$@$@$ iY   j$@$@$@@&je   9@$@$@$ iY   j$@$@$@@&je   9@$@$@$ iY   j$@$@$@@&je   9@$@$@$ iY   j$@$@$@@&je   $ %PqoWL{OPŴ:﹬3؏8wԮꈏ[_[r7V~gF!>.7# :T[u礘AY 鋶m5XYSsinƶwǩ#ۺv;}IUysҗm]o%  `?MYjhK=-Qj} NnhE6ilW<2dJ䑖:d OK($@$@fOcANf7[#0lz[1mccQik' l{i'M4f̤uyVs\b]7l8HHHҸTzCL1'U[v&l_nJpƚ}/_7ާÑ5=GҬN> T&F|W{$E[_[$L$  @Ms$j̙GqX{oLIKOrrjc<<Ihd=g᭥W 4G/#F&uan$  Xb>wBBd앪eܗ&Ǥ+&ɂ-g>ۙRG_5;_ַONJKsIMO`*GK$@$@|Fȡ7 Sp\,qL>u=Gmq)Djq;:ǷmGſ$@$@ @M -G [6m0MYbz;L tLMكqc["欜>"eԍyFHHZ[̸wȡlKf;:fRb-3yجjDM:kQ2dxC^ $@$@-B4-ݷV֛[Q]钽ٸRRx:RvWذ*qm~N/z7c0 qɎRLcg]11s|[ݹ}R-2a_}|C֤QM w?Փ5jGS[O,/ \ jaGL]J6mP⤙ NsBgƣ>ME!};Ǐk׭X0[)cpL~3=1lV{!Xoijl+gZ"<†HqSHHJiJ*™F]N^=e}Byx9 K\ڴwً3ީ76.Ƹc7R[YQG?RBE4 OJ% 짹XԢRS!Y9droOY#] wZxʞXZm_h,C2rN DNj?w\{͡LGtt 4@X]]]1H a "=11-Vh\$.P' m& %@MuGIHH8dA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @ ܺ$@$@$@N4Nt .j;ZN$@$@$$@MdA @[`4@XX "Q"H  qƇz ZaI+#G1|fG$\ +JG4ͅ @EDDsHH ƂZ~i 4tϔDGGCְ92  _'i$x5Ӡ4⚑0"4(9i*++^yU@ f!5qތ %kpB4KLH|L4 n k p.q3IrUV]]mNםq;t @CNPUhsk]f,t%UAS^^nN>t @GM/..]vQQQ|#}H@` }QHH? iݺ5~i4UG&22aoΞ2eJaa׌$&&{"LH|F 2kJF555hϺw.!4111MIbl+"`A1= ~7 Э['N\l%\xȚ'OFFFHEȅpuDIߵj儦$ DMJE6X9|;wUQ0G h{I2&,UDj1(tĚЬhUE ,4z}ӢCL\XyAkW?| X?Tl3|ƣJ_4M$@$p8Ӡ)EW%C 2oC[H2( kUW푦ԫY\Zviq1VD ¤$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$@MsHHH PC- $@$@$@4<HHH5M0"@$@$@$IJ k~cĴ{flNu[8\u^zj4vvz}b4\5ey/K`=Sv5GNxN#|}ZIO)%"B+++}d% ?$@Ms6mkm+F{5\ߎ9{brBC%S?,ݮ[GF^#ۣۧ)mhD{|V~'k@ط:4_S= ^SviJ jaIHi.xEbCapG:ž= SSSSi(: tjTѲ[s߁BwW_?!g X7|I[,9 ,j_>驉4a}dx2meg?RߏOd״CM+uTZ.9U/zh"('ϸ j˪C_>c$ܳcJ)C!iʎBy*0a"\yВ8:V;Ef8ua-Tу;5tjb *j[]ƨCtGxڳ5'_)jץSijVx6-Q}Zfєl( A$@$Ul>/_pvFZzoԜteb~;f 0"AKd4u;m0­2b4*&|}bM\>7Ȭ |Vs319ءٟ@m B$@$M4@2Q8k:h-xd>%xG Q;Ѧ#'d%f0(TIEq_Ze9 U,7 jfç#=}tc*:|ksmx}0x:azW5rS=ЏHZJ(-cEZɑ=^査xWu,Wncs2»'E#JcT'!-ސ_'a^N[nhy |[5Z9Z8׹8HZ5MP߼?{t,+^4ZBv7:iwh?S{*Ť[O-kۛn_lR`*ެ* *Q?QZ}<{sۛn^? HHHcO䩽e}]ThQفSi[Sn#m"yj+ċQ[XXن+! 4תX j˫DVϟ'ƄUվf;Ra3뒢2aP\}WWLߍj.3U^Ɍ" @MӜX^a=A}Ac֬rT t4gȬ % "NHHB5MV= N$@$@AE&!  %@MUς @P daHHH d Pӄlճ$@$@$Ti:Y  Y4![,8 jNHHB5MV= N$@$@AE&!  %@MUς @P daHHH d Pӄlճ$@$@$Ti:Y  Y4![,8 jNHHB5MV= N$@$@AE&!  %@MUς @P daHHH d Pӄlճ$@$@$Ti:Y  Y4![,8 jNHHB5MV= N$@$@AE&!  %@MUς @P daHHH d Dl)x]mon$+g :z ~   iAVڵkw٠?/ԩS~n囇-**a ~Nzbeobt;c 񃻺\g㪿lq܀:ǓOٝo|7.bot *Wۉ:؁sNxSO-ZtVWW1}ѿ=Ν K0[*bΜ9/BAA%pQQZ"ڷo?{lj sa^sbKcX޴Q@ڶN?@g,@ֵwдcGOj0IfUȊS\if<04MS Svj1bu]W^^^SSPkƋ󮭭Eo;#?я&M]\Br!222&&)v1 x=ۆ vWWTTl6To?O~⃊@( Wv(e`Rܗ=~Ѽ4 Ļn3(^zBimLӘ򊏶4[^ܹ.2P NM4ژ6m@j`ʫ4/,,\~e|SRR`6,ĐsV68i"N> 8ƍ@\~xnIif(H7~1[1t)fٴhgTڅ!M5M6DoK*z8`ųg#fOBjX{kȸ:B# Ú~z<4hciڶmkXiЎW^`lSbB(j}iRޮ_{,PP6~XV}uAc[~Ǽgi>n؃ )o~mҗe;eLY܇vgj+oykqI˜'4Myy9D2g< s'?C#_}sVcƟO~82Ogg rO/ӳV+_OB+޿yKKԻ<--c8TL8Hm 췏\,I\lCSn}_e>e˿97Nn[ϭzR۸i 9"i'\zZ{ٗk=}eЀ"rm*ۼ9HK|pSSaZ@վKf ޽؆СC:tҼ` B7dw}wf^Ç`ٿ 6,lpW+?0a0(Z꘣tfw\hfBǽgŤiY(oZƔ!J{?#LCfZ$mkbƒ|fwe* ֵSc& SUka2V{=+ӦQ3;ؐ!;W2{?͡XT>KAb1euɊHϞZ]Pii创) l#)/s IDATB1YiKv=6,H֝buisߝp?YN6v3v;`ubæ0fnj5^>o|pg{hanB@)ϐەA;{)EH3 .t4qwqG֭6Ў"URUR|oW"܅h~"\pY&߸ؕ0xMzh'`1]ޚ?Lvҧ̿GѴF 69vJ*pDJϘ2 ymKb|k)ѓ9gd={'##t=ITh4po4[ִaW2o54ɞ,SM~7M y͑Ν{ M a=-sѻ0gpF(ޚi4iZRh'<|wIֿME#OUhp V.؅A^`?V^-W^x1CjJŗX0GPb]ߖ/_.3mIst.K6.ϔJX] ]p*ڲᑙ[Q:þ~ZƢ-¡drGm-KfdYH@)NI3Jv>/HI5vLG`Oͳd6=)شf͎}6n'^ MYMWm;Rt|206smiٖ6e}X-]Y]Qrp#J*JKlSCɰ㏝UڌչF*ۜ2ódƞS}ǫ/0tz$m< G|FFwy2dz~O^Brpz~gϝ;`p{ɚ!A4&醇e]Cmr L?RUDeީ]Z߳gZ{>8WeƆ>뿞:k\iq' .ƻ~z^F/|TKӿkܥugnx?0bۻN[&松g`y[wMH:u#U#{$$ hzĦ0%S{$%踎-Z|vqq X~S~-;QF"O}v#s庳ı3aԥť5/.R@xٲesBv[Ν%o7{p`C`l>,IJXLQߌ3sÅlzV*1<,w Tkq==`eմʆ_|ߐ}4uztSY;vֹcyGy߭(&otci5r$c̡nSP쩛سo-bu4#F88QoUD,8{8ۄjǨ)>ݷ(ӑdQ/n9==R1'q^vȺz;ӁJG&qf;f#mcFh(k͚cӴ0VrW꙱^0\&jip]`UGy+k\Mi\\V{ hؔ6Ň^K,%q ;9s&~G-^]|ArqLo-^-SBmSǕ̞ɘzߑ#4-Ϭwٱj!gz J0flqu9EHr7K߽x7$9nCER[W*~]&%~e>#g.ڱaI[`$pq_Z3xx i̼P[f--5fV6cbIqq3*ݾ}?Z܄MSNխP5{֎61W:Z {M&&:DR4tIG#X-EzX';bLc%o 59-r:sZd|8y0U!.L F{B OLX B,7Y*-4XR;P/y= ^'u(xs_Fdסjk&} Xto[7NE^kf_rQC0f7֭]Ljٳ6ȉ#!#Nz=KWkKfع+;ͼ#m&ӵ90)e ijGL] J4sܩ{NXxt֧Ȟ* |ɞWռUc^)<DŽȵOq͞rɫL>9wtYϔo}i4yG<#ӆݥ9>bg1޷r֠K/ةs%6Nٲ>#̩w9"g̥y}{%Lt`pA7EVʇ6+t4yZ!O\C9KBhqNVo?<@&9A\%71LX}^qn0M@ 9N=XN\L7Y'z 5;rW -G_&~-qA8#M#M\Qig12f,md8 GMSS:|M쓋/LmrX08e2i;5:]GYԔCxt쪂4P)X癑Wz evUYɆ92 L/^><&`F0ԍ_ A߀V V0I"[u2&h/O%@Ȩ|"0Wo#$!{G͏1:>؈ AMG$@$iZuPZfL$@$@AAJ~S+M7Fѐ"T6 B: E js>$@$@Ө;8\({#K0&FT`0'SQQl\MC%yIDl$"5Sw ]r4gK2r^~8SݳCx)3=$lVkeIH#kZcӨk "n9{r|\S"J` §`sDIołrv£X]Uxr# &࿚Fn={fvEk~q޽;n.q4% _|96!!%ر9JxqX[nA,b*.c.f(Мt^utcӍ?>KR\CF%Z8T|QF{=)imCF/!es wqUW]Ol*" 7|#/q!DFxeMA{/tTDLz|NڶmrT%J~afdǎb$;v'6sjsڴiiMa$X{キuVsH >b#C..N)Sf:Dv_|Utqè^{ꫯ\o}J}4!  #৚F^G0M#فm3~mQ/Dc""6D )2d,.v:P@(Hd'6 R{שS'heCv(> 2ѰBHHv(8 6|/++[Rܑ, _(:t(Td$C]8d†(a-\>L̡Hjy|7VŸqG!{=E@C#WPwx$b8\""}4QH !$R&MDDv#+a V!e _v8Qff&x) " m28;1ʀ(R0„%hݕ?!"[ "FP JV16 =4Q4v"%1Nd]svcvA(JёN,s 2}?.;~һwo9D`vXN4B: vII!""` 9YhNqE2.$̳q>d 0bIH QX17qCGFMp+pG[ ,/T^p AAccno= G"("64*;EHyP l$>pr )#Yd'$ QY'a48*ƘIDKA3aC$b(ᐌ`AxKp# (;q|$"HH$CtE`Xc(E@xI  D\J8^@!;dKT^!MXtrTQ;]JƬ Q"P%`!#Ba! BC/ (?42ʸe.=7kܲeK†8 A8D7t)BFb! Br!;il9Yy7) " 6)M)(9kIH S}w^pk8PՀCl(JGrT-\Sb! b1J,hes)D&=*CM #tODiʙ &%.=GGT*s@ u>[K  iDsUKorn$!_FTya@Uw=uO>$@$@$$ OØg,G3cOޫAy srr\`B o@HH PӸ3H|C˦y睘ʠLq}뭷w:kB8QlF_,k>C?q>!E' #@M @A@۾}'ZpO?4I00+CPK;V6SS:/M TzXb 04>0+7glٲ'OR5mR(CՂc41d^{ ,b>cf'.Z꫑]K.ϴg1>O2AhJ`$@$4^(^5~ӟC>6v+=\&PEEwƌBX}S}H=cRY a.3SF' j@׆A%v0C!W5q 즦;{lJQ1 U㓥̙3:7n\e=Ԛ7`$@$@ [7zH)VCS뮻%У>咱0t]m".idfLoBS'O:BK3IH PD@6}tH7xM7Aw t4#tàt2qDs?:tCet 3jZGl+W{]wIP0< 6 )j!\Pw^4ʻCj-0q gW7RgfhMe2SNݺukQQ n.t6 5kX|BgΜ9x5WL' ୷@>ܹs甔PQ;}5d;vb T&p3TWWeg:Lox~j ! ל"t,|"c̘1ϟoYK; \X~Μ9lHOmB{"- *СC^Bl_u9_g$+/nذzdv<_zL & ο6/,K"pցjA*AF&;36&dddlذoa$pA XspMy#iTѶ.v$O67X[᭢G\%c2RT:q/[ '9_!Uq9;XEl'm# 8{,d^̯\0V@ѫObhݫm5UϖЕD-)g|nj{lXq%ԄX' 'G}O^Z"֘79@Sअ)++3 5r׺׆MWHKPŅx,J s% ?Q\ A>hL~V5 -#h*0 5T p!38EOゅ$@$@@ǘzǸCA@aNX«L+ @S@UizƔV{sVNn@4Ʀgd>KAS, @ oHP|bQCeUD|C4ͺgEL4gHH.Ǟ.VSߢ^#)&}S ZuRѦBoG Xެ51g A!t>,* @i;HN_px\a11o)?='MwpsHk cǛ2Nt @ iZJ|qc?f͚ՋH3eoڒێ-3Z$cy kZ5var7Y`3HxG3R˹/m }>A -sapHӾj鴌Ep^5T'WYn9`kˍHHp>M3I[8TfD& ?^Of\Ω0Z>wI~ kOqXMo д'椤DFk+&#(_w}ۆtDCAO?Lntك$ּd HiFڴq (޹y֭׭eAc;gk+XӪ9rӎ(1B4yX$i<2{]K07Jϑ`:oZq{5u'ԁ!hlG7{m ]G>7_]dIH +,wQi5X+#Tʲys{Jk>׮sKe0Be(yp[Mފ,Qmꄘ5{T-E[vx#;ܣ `ZjޜE$@$iRREXM g-^){*cJxe#'}Z:WfGD6gL,t] \(^ZҧܕޣS[!.IH[{ Mz{:4hI|uJCfr*ziՕ$P[cbE }նU^t_A M޿cX,(+Rnڧ@[QK8eJ&LVuL^RQr9ks6d?Xkk`HdzqL;&&_:IH7wD $xQ6wȰa#F [\cKS{;N=V3%\ss:pڃ7E_WQ0YhYC&ꇊ7t;lذQ%/GK$@$i?ݣu ߶RI OFo3l!YwQ=|З ʕd/6|dKC'c[0th2(82!MmmE6-0cMSώ%  @&~殽9ǃ*+ٿXL5oyhz⍹/6 [7,/CK2,-, 棺  /X"I8{ pc`K_\kak{Q30 G4v,hW"##X:EZl02KmmX)QQQ_ZkYo9>>J كlڂ Y4{MtԪUqb4KUW4Hʿk׮=y$,;Ć  (l|s @cit:ƠIkݺ5vcbbjjj5F宪*//OJJ*|4?o#F@Hl͔6Uʋu[MEĞXf5Do;SR| 9m] K rC5K( i3VnCҟH5^Ҧ≹M 4&|C\$ ,j{K mL4~nAXVu֩ݻwGf1?CQ3gΔgzrҬZM(B VTT4iҤ?Xx-++SSNR񙦁%~_H5ȆU5u>WOWCedd̙3=5[l9dߌEF6Uxx3GRu裏IMM5jԚ5kTك0Yl0@{W]XO$@&@MSp1z@Sگ_?8woE/BvvvΝǏ=`>MBBZhizNd[oѣG_s5Ǭݻ7|W\KMB #sEuN>㏣?˗! V):Mqe˖aZҠA6lg!ǔ>}Hɐ2K^ &K$@> @M(z b*h}Çcn ƧwfaAà^~~>d"J/ӈ B$2ԃ],(pAIx5PӴp]4 :qĝw9yd+**Nt,8p"hDΛ73Qx4x n EVcL_a: JKK\~ D`x D}_hp>M^KPӄO:ᒟ2~aa!` (  r7E߿zjl}Rs[cP͝;o90.\+6C5)) 2 2 .vetha5iuz .%\\xNPw)YWp_."]=5RM/O3X4hh"NjN4qU&=^?ƊW^y%;PM;<׈KJv[n4V7ܦ$0$:RH_ |P|ܠ5VH\;a(ؠohq:F{iB`.rx"Ջ94+o!O*15>(fսKX! h!BaR0A`#PCAR&6 GB# c ?V*Dt Ra=jWґ+5d >p܁'o}™(3i\xAo[FAx%/XW5{'֯_|  Yaf 0dկ~5MA E߀5Hh& x."ts3g?xS-@vš⟣ob!!~:+)j%r1Cp҅ʁ1]l7tT_5 w&0͘1gϞ2؀Fo(5@tgϞuTZRwkjf0NC>2bDNbLFol_qm>!wl7_P8P|U5y X1c5?xjرRIMM{~)u 9vw A "jFP*[{:!$nn6f"#JUqB2f>dnR9})f D _<`=9"!E4~]ݸV՘F0V2eʔoFC#x¥.m_ćtP~P%7f͚t4|0u^l>4Y@L~a~qq1fM[(]|t1_Y 6=;&;v' P{u5x뮃â5Q{h`m=:'dv0VՃ4:[K `p‚oE1oO 3AxO?lTr Ӡ ;6a{j A4P鸆6c 1c /Э[7' U"h[~c50<~n$.< Vx8a cJ38A%#,:^'Bຓ ~¢TDrdd .8&0*6M0t"6^YcOo^~{pxJ{gvڅK@`:F㝜* 6\;x):[TUY4_Lv5zxCH,| '}VkUuUue%@K+ fG۝q!{̢,qv7 sT +\d{ZQ^z ?H$L6mڵm߾CǎIW\ѩ]tB%?fq! YcBwHp=BUX\h65;-- O? 7V׋XE|k?8͞=K.x^P\>d\ϡ)( F k (?{cyy;|7*Q,ORneIl!CN:}[=z\s5rƗz*_`WXq+:DGH ꖋzxcyŸ'NiӦk6z_q Ka9jtܸqrRhp $+CICclqz6 ׻C_#%^ (-.:;c?8ps171l}wC[lxB֭ .p'F6UV(Fpc!:B5MU5hE` ?ƺ|7o}7y ^Ÿᆸc̒F<Ȟ}Y44aɰE@ ѠF4~تNv֭~}yLsI#-ԛ ou%^ƻXU q9l|MNNC4,?*5KKM.W\_U-/޴w={`wߕ 6h)>6 #q赖Q'1c( ཱྀ]̡.>utbbJVWZt/?ّԌ ''njj fwjՃJqΟ/mY8pwuf vM`D(\8<IhK1j@\\!kDOw}!ܼ+xw@-aFX`އÆ Ll|y $t @ʜ?]T\q ePon]P3 b§ ܒ"£:]ӄ˝G/ƄȨػF9ڷwg0Wk"ZEFhJ۹ **Gmݺuڵ[OLLRY~]T1:>i '@Md o\4h?'WZյk9s .dæK~_:v_}x /oCwӠt hfbMɹ]SdUg H4Ȕ*k϶Χw}j7DEGAR5Zmzz޽zC{UIIUµ\"DAF$&/-9'NB|gpcl}ɸE06evS`St7t/nVx h_׸Q*/r|:h ʕc!Ƙ0@ujC.:&0:ŹkpTQZG?odY ,MciSsl5u74{jjll wֵx C_uuU5u6(\銁7 a={] [>bŊ%K0h)]p}a` {.OQ mEzkp cçA_W(koV@(NSDp¢F4r}p rB? $<VS5E脱';g8/~Arw+#",Ȋ%׿.2;<iixWf/kӠw! !Sila#/8iPJN))  |/СC·i `7>.slƞp7@yȧ# 8O.y_\VE^%֪zc~)cVe%Ui#n?\ң<~/}Th WWV*UT6P4(_|Bҽːe[XcqFtёcvO!51.Ƃ~x!Ф @ r@1 +}3>l[v4q;AL|dD1س_(!{v?}Ά 4Xz=VtAvXXq IDAT1V׭k|BB6qw7a{=OJrr'_CCWO;Oj%U??Ӊu +WR@n(Yc* 6(>ϗW~dOm8ܾ~?aNSO]xhx󛯏tKWW6x׆7a9>3IڄhQKcT?/WemUQÓWi[t0[ F,Waze0FSTW{2 |bjgr0үjfTj7+ð$04hh*18_cbbw2wO<%Q%ƭÆ*h7w3;AD 5 NtlyK~orMވHH@BHZjXL~9x̙s_ӪUdC }~߁=b5=QSx|7oU=Sb ,=w"u8c+[GAT/\k\ҟ_h*__;PwIԟ). \,)>[< C N1\FDa޵>{]1!E*1!9&6o\C8 aD>5[ְ Z/P+X8I]m]:`Maaqdx$tv (z @O5dbf0-;-g09M۷ϯ˽ǂ:<]pw''NnOj/=t\Qi1p)>[uhKLT+ @  7*zx]0vHt H3EJ%n8 CDC c(L;[\ k4"94n~=0CSnV7M8AU55u,)c *i0fomMeM+gVizs{uCڵKsU8c/ \rE6dbvHlAI 4 u<֦:?%pP(u|Zm|.k۵q7}9[Jͯ1ª*2}uo] n(wul4/,=EhӿO\CƉލz9}c),ooDAQ뇏gMLH+x!7^K#=22̺Pa0`/>kO$⦶ZUswa7i'6sN[!9>/Z\(I0Y4 v뗈{F 4 lܸTV >NLttNM}|\ŵݾZiՋ, lcqM IB!H!(^MlM \1reVˮofVWj\s|3s7眙Y6$Q>{x `;ݙT ܃UYcSR/Wfţ:l̉&p xXWCi@;Gf$4l=zqqfcv `Upbb[7ƶ%wd%J|$%'(}~"qb<)y;ݒZBoxӠ9٤Z#lQ> ZG|F. //)XM?H~>1p"^xSf5NB{/j96?f,0+k, -Yl5$*zda g0aVQ040vHI?rtɉXR܅s /p;Y >}͎_zK.D>k81qٙ] 7|s޼yl:58?3G*~iS,C 04hP;eJTt!V8'mHO8Հu!D*xgy @* >Zǰɮ$'aIYYUZ\{^S(mj;Nk^3l?^λ8p9J \!pϞ=6l;h2'Wܰ,@Jq iD[ofIуN:#}S|_hnnEYMf+)} WBҩg [ $(i)Y(wMD\do zprha&3N\gĔ4k {w:jD!|'+VHHHF WƒY(o7= q K].t,]49E'a;AOv[}DQ 1J\}aC/Sd7 ELFϝS|]/$caY%^SI@,#*320}=.ڷ\z,dw kP4'^>!)l.pDVe F F[[O8^t.i`~CtmZx!f'CLlOF-l<KZZ%1%6MC` Ji0T84ګkJ$۷dV$0^D]?Az(z AFЫEAOY삛MqI“+ჂG@fƈ)^#`W]2f8&!dXJʃ9&䑪j:8?L:ccb :%|y`FPEe(A k['@s⌁-fBkT cQ}}͉ZתnVJ{9L8X|(i\֫T&F\6.ps1) ݞ=i*o6 NtNyeo=gNwqbg+:@?Cp4X[B;_w0&#@0Υ `,܋YiԺRK8{˕DB`;[U!ߙzVU:Ib6LP =yN5M9+ayѣsFf9|vRUjkfM:MB6p>= >'1)fݧ# N˄N S2UӀ H\zKĮBuNF+<5O- `)k`zTl-j7[:op!1f3οRĖtIsbi-o*UU9M')//R邲pL+pp0^\in3BV+H=+NWT"* cޖ*M?O01%)WOK3R{,MG~(|*%fn18{26i"wLxQB<ɝXnP:X㘑sqln:z)薰Pt|qkS=K(MΘsQF΂-O.b%":ɀ"猏 Cl(@4HR%`CN8뼌;_踗$_FhnEZLh2ω{fɓSjɘpΒv5Z%EM.@Rմ669a'F/փ݄nϞ4i,8wZyM<;!3.%^baXu b2[ 7 {T,/I@eт33%ɐ=%'W~ǴuMmR1jYJ)RJ؃A>Y n4ѩ{ t{8.DliWpGM39! O9k,EH+4?n ]H7t†Mحɭ2g@(nrR`1g. s 'uX4@!Icy1>qNT[4d 2EU*ܰA!B$+-SOPi4$ⴴ`sΟ?_=E8PXXػ6Sqުqsnw\t+\X;c]1`0l9P "۳uq*WarzO}2N,jw01 kib QLh~Xj 'D;ּɱ*)rXPc{jf Ƀp{*;Sk 2^ 2Z MM>~h6h(?hgO_}OJfRq՟zi/WQtt:4q 'jn)yJwOj%ĂBuƨ(ASlxg[@6&;]IgdrYV`;7Rp݋WAuazb CNqK2YWn|祚]:挍;R! ŝ{R=溤 ]cӢZn# 1쯹=:,00r.f?; CokR3飌FDjxdX[O)4 48Dz 75x*&:a♒1¦!ï:\bzcj\A:9jDa~sPDCჽܒlԕTkmnHIKro5fg= + IDAT݊>&m4%oӾp՗_,ɄH{𸬚bՖE!),5SJY# v8mW\厞&FP?.OAPQ{<6)seN<{yUvlV j}iw¹ E<KXfwZ;dkS+:!Y1x3 2zG5{v.##Ǧ'O-%{Ҭ@bX’gZ ^[wWg' ވ:e>yxLH6 e- B2T[ǒE^/ ͥyLh|2wZm*+&s(&NA?hR*QBr'&%% M=ꆪ!}3x$;ԾⷐkαƍV 4ޥI[ PIZ5)Rϟ[wv`6jl OMd{IXKck`?%hFO]ȷC^/pغ)jWFu:nkC)8^Gdx,y@C!D>p1aj`puYP2h0G.w[ǧy_=Mm;L]93&\-%,iѓO.;V):ytc:_1er)N~ѨMp׳l:f'Em{9L"Y7Gt8'iXjTNo۳M!B @`'͜I( &x"#'ND1,pYx)YEQAZ|ʶ@8M`+4ɋN쬪TAvW)a,䱊kFbVw|I揊dʊv}lGL,7cdYyr_%}yoqi䘆Y1Go5DQ}QIYisyP ;ۧBDQt4f"4Ɛy5:6CoP ]L;v,JJnn.kuiT~7]>//fA،*{ilL9celaC~ǏRn[8 ˇq %;k4M?8nae-pVcԗ4e`j9 $gtop-8':^ק)]w^Yb \g oָ raL!)ۣtf=匮a8J>Bb>v v|hFú$xF;\ث/^  PAbd*#0;yvxrtS۞9dLϖT.Z4ᢎ\%>-l^/==vWrgMaDc* 5OIش{˶W_wNwh+תԨNbR^TΝ+8 %Jq3b]:\H {|A8 ՗`_c^$7&=@$p061@!xwn5L60܌7vqi0Z|~ekj\ * qkӪbW>*]NLL\`/# 3 OȄ^8Mu=?kkh.Kݱ}$'PeY,wՑ/;:ht8/aOOޱ?ZS@TJF:]'3JɈ Z=5s-ӊ .{f_~'->cI8ǿ?|'o πƪ5zTpE'B=Eomb_> Fn" >9b18qIIB>+HaE`FkNd͚Ke]H>cƌiӦaNPg'2hB 4=gw/~'2Qr6Ԗwd*vc$+ǰn=ci:VBj嶞'+lZϖfre{*[li3p ~'U>NQr8,-є{/pԒ}"X[/?K6ՠTAl2u^CLB=ߝl*o4 Z=Sp- ^ \L&ϸ 44Lg<'ef͚w]z,w&44?mO~<>=뀼ѸvjwqDUwݙS'a,k1o /r2HHӴC!4Ugsy}v/]ҭ-2.nˎiPxTAF˘jwT/ζefSK[~6Ōxh-Β]f AIaJ'M(31-&]Idk) J㞘3=m,KRG%Ie/qa73<׏MOh̙l2,*(fq #0Nu]  l9uq@s/A?GDž0cKہ]]N穃56:,##uC~4 DKFb?|A:w<Y[N@9vo:ZlXI@G͜hɉ!ZT,B.* *fW-Akܹ٧2n_9݆vghرa]%Z0*ӧ/_d2q "}@QӫQ'L۾ii䷿-N0I|>̘lͨO@4&)@¯ S/;ݠZVxXarLeC=VTFu3LgiG|=DLUo:N8 1?cH -yN VaJ &F+paDS>D)&$Vg^.;) 4w}7T/FkDWp @hԹBwq|1 dmT4l ˎќ`>t0QNlfi$#U6b/,c1XMVSUՍ,1*L$s 4ʨUj02fl5}Q0!0x&6l6éml Ȼ6m}\r5T/~뭷i3[M"QزI4/nUڛ ^Ϙ|~W o9̄`g4(ѫu0]Gҗـ( SԻ댺6oXTan,31B%!V5tQXX5hP0 R)T4 *kr9hԽq0's"B1;/SjȳpÙm-D`Dn3[˥9.:K;Wa`r@XaBa=1aaAiDȄ}*bbK {<(8PeQ&LpM7Z ',3%^,G>L󷇮^6p4h8IR3JjMŠwV غh'K vD^}2\m}!3y1|eF=$#~B6:v/|H#ˌ ͙8}JP"f2\w's͛D+#*6:%e֡/^: j`4N5Xj0+- aˌ3rٽ{ƍpII (_ʞz96]p1Gf!LfD ]2N~ %twFVL\gT+v,J$(kSm߈fM:jE1dY79c{&9w)[RչR9RTx CLRIaB`pCCt05lF,Px@qWLb TFRX[j.sd~a׮]} g}"38 x=fQvd3،kJEC)`I08 :% bD2Yj[4YhUF]:G|B`"TkKūL>1d·I{ Se$5tt<lխJѻ3"],ёz̛Xb!GNF=HCCAрp_)mvVyR5V0'?~ɒ%O?|\YYyet s3.{\RR ,M=6^#ޞT@C ]yˆӠ.y@oDyjYm.եr~YB^@ nm6!3Ϟb6W\cV롭\̬1aiSal`ƈQ&hh[WP n1*eK]]csS0kaV,&A1qc) v0-15i3ZvvT-+/@hhhK2ڹhpIJNȄ f`a[pv[^Ae|\H/ 4/\a;N:]|9, :$zz&3a^d@rIuu_}14hHaTle^ﺜέ{n{ 2k!ar™M)):rZZdMM &CA033|> AeF(aW8 Kddf8sR`IO-[ 䃓#&'Ifpfww<70d[i`Lwȅ׵4['Dt|<Бp`|N#ZA?K lxdddNyA!\/t) 3BC>H !BF(Ў1ËG. F!9 rRԇL1(YEv/P*-糲F.WD!\" E AU΃΀&T5`380|MoA@ wA _,<peVo=`FQ8 *n@ hM(VS]Sn(88@tG8 ?0-Yor0b 3W1)+$k-HA4v*# o~Ty-"H ] 9iP9a㊶wYG]]x̎οPψ'`:G074@"Zeoو8#TA#lr*ʕ6;ˣ"ְe`7`,RPvA#Jk 犗t"Y/<sm{ {”ӈztWYo@Ɖ q jjģU nUQ0BXv(22r Q2qq6(ͅb(…03KpN""Ú4zEoڮ{â"p` x%FJ-CDPPEc'P8e}!o tpF>&NB @4ZfeC# ^/ ˠwyR*P-F"6#3 @\?[2^e4tA8 5~#   +AISkDBV5B "a883üY\oh'aFZ@P><3DĂH :1tD4#q2Aݡ@t~AS"FX #pл |1f&| x 7D1 V:+60s8ڴaxۆϖ P+Ԇ4=BC7zG@&᫧AKAX $8t%eaa'Pڪ8e6΀p^$x H_ ^:(Ïq<($# =n!UN* !@p+b, ?)9%zFQ[ IDAT&\ft V=BR+&keRn<  aO4}[ 8M` B $0 7i<(-,PP0Q7rFPXÉP@c`pbFF~!@_pQ4Xt]%B mp$&&Bv6c1w =`@pP?8&J3|>CM]4aV]j*!@`{IX[k((s / $ #@fR l Ѹ B"?³TDf !jzhM. A8MU`Tм(!@!q,X'= )i|z!@@8 "MO󞠧ADk +=O!O0? ]&BZ -a:T5XXgi¤ҩ!@iF/?| 7aa{ bP B 4A^#}A.a{"z?!@aq!*/WP!@@/WF=Q?-Y|FM8"Ee&B.HO3\H{i@\L2j(_޷o4裏"T*zXHUZO!B  Ny=Z~[z!97?_!@;iG2`*\py#G8qBW_E.ëWFN:!@ )iLEPT*x{"""PÇW_70BЄJE! z\NM njsM7a4oiP B` N3Dx@ւ p;vod0phtCaB @8Pi@T2Ѱ@%..nʕ: ¢AP! Biӌt pYf-X@n!%M-e D jL;v%X@_{bbb~ B#{6h0 г!@qЫK$X'mNz1H m-fs[tzK1"ҥ4*7ILk榢DniJtjsiXJ4w|Ry#V b4ÉH t͉_| evN;wo4:J-)=[t5''߱+R#|`}~Cq|oW8~x̩6њ઻8p /vF}:r!3\`b#/{u~~@@2zUޗ~HtXǵ6lk &G5XF1DAh ~Gq=OՆ q Ìqa|d^ MӌLV6+!Ў,.

ՇTh ^Ņ$\qq2ϟ%s"b##B ;1Cr /!lngG+LAGf3M{'/_Vs+~W2~$/3iPzXylncZĞj-zt&::b=o4ҢOn8 :!@NK藼Xc)"":B\`$-zA!N_$40Sxu;9wڧ%ꑵ4~e.|huׯ]#aO=CeWv=s[yO얓,4y1 eۼu#y;7G>gJ1u\^m\Ņ$ݴ?հKސ,ҴKnS! # ;5W(@V}]2mk.wыW\e4mX7f᎛}ז$̜_ycker"T&hxwâ4ID=B B Xׯ5]^L} lc?~Q'-ZlJ $ؓec9]^H|0-MәE4hPw>#Mі7~wϣ~_YubMpӶP-۶mՉgyșmÆ]E<kY˶68\Rp|D ~FsO70aWIu6o:p+0ص؝$ToO伂23K:c2 X(EU$@;n6Xlg%|FSrtKqKn5kߏ׉]|C&Ѱw.{]%t4>}*IJLdLIx#NJJNoB B xO1y,]X{x+n',[b%۹ْŋȋ)eFջ2B8ᑯR`vz~٩=kۥL.J;Y#eky!"_Ͻ-fJVQݼI4ZxAB HC+kL`HL?c&3khZ{RnTS ȮI4FaA&3,/2m/ҸE׏QsME+],8;\,.*bx+tڳSFB_$,0x(= )pUg6flH&0% miC `n6EԾV2:$n|&͘ ϙmNek6nK!qk/}%E I2m~~M{g/2 >}湒-1 L`XMH^aB Nӎdn=l|dO!`yQY_p?>b<y!;gqS+/roF_DWSW0G]u.D&)ӧɕ2O{=gHv65-Z{tD)!@4+uڕG=(e#/_ 9V WgxO K-nɮڸa5_ϼu=  :"@#ˋSYsc7Y=[^cjګκrów ç YoaK!@0/$,RcC`XpǕ/ʋr+˿xRV<[GA9WcZ=_FîW@Wtń0ܚ{ϫ@1(1k~gkM) ш_܄fGj'6}Fntj(z%w =gJyy\2)w9m:F6t 󔔻p՜ ֳ+ַ̉?lùVa-qs}'ߍ0q5m p#@fm]ߛYfMu9>|FFIAFBv*B_#n> sr :"@x/B BNgQ B B#a{x"zjmcMN4 | h h&鮻j<>]h 4(Wpѥsi`%ˤC.k`~GՁ]uC߮ǿ!|%=DDD׿NvCm?҆--m D8EA\.bXNum۶//W7|gN6hQ###qVTH٧5qF!]rrrll,k g`ђv;00͢ M[ٿhː(h'}y=b"|l5j… SSSu:zdB/YBAuMP53 pԁ 1** gO|QO4b0 -~O{]/8ҥKQM[nszɓ'^ yt QH+j)9o4qa9NxШ y- > mC QУqJޛxc5kٳGDFZd̙3Tvx:/"h ¨wQ h(//:uiPB6 CGFR@HCP]BA`d;Si&~OR/諐MW9)>68h',rcinnzVaH Y\g~_Mğ7o5\ M 8ƆGO#2 >ӪN-0Np } c#_J=&u4}߯8HYY51`?IkJ8@rHEH j1:-uYAN#\LnQ^Qdq))qRzݿUfee?8q"2B +0_`SCG%wjj0Į"',~!YTh 48@nlܸS'3Ъ^z?̘e?/~ M: CCmlx[ӌ84 $5P`?W_!  Mf#@ >l@)wyE9s# 3`3PG}_-i­Ƈ_Akp~c;;;va B o9_z)^6Hʕ+aoI&4p-Ӊ( N:to`@ Ak` @kӉ ^z~A_<̚5 1cƀl'al>>5o$N `/1V{ciʔ)}$(]B\\\ "&3"m8cfE]44FF668_%PJ}B8M`H@@AaG{H3Ov-њ`KÃP`02jy{go=&&Ix tB8M'@?i;v ={6VOX$ZO)-B"LGb" &026uJc,|9u]w=6<7l5Fu4IK b;~L?񏯺* ؄bfa zQO 7 Ū.9Pp/Y^^w\x$# D!N E3/2+-Zm DCgl0M?i)HI!`Ddee%"_~oJ ]!tRlf߾}蛻vD: %fpc-<3 6њKAlKFG44/&CK i hz/F(,ć"7h @@gZ[[YV޾tm&y]`PGLJȴw lp} ]yR`_̶̇ Acg(ܺqWy!pzD3? /[t+,rJ@bhH14ARQMAV`Q⋱O<ӟbphM*l7߄X9s10-- ;h8v]YRw q+Ak|IXmn-[|k G@?9z(M[nRRR3ݣFW : @Í5XrxجY(ҥKA}*Nzbv酽" h3k7n<묳" #`J PxK..qqqG`__`b3aD©i©F`ԇ~$$$`=ӉI}R6 $ ̎;}ě`fiڴib(8f0g' U(]B`D N3{@@5pu]hͧ~'0}/!Z~t9@{衇N IDATa[n;0t3ʀlF, Lo]B4]\z_Z#58cal\c>GpRֆ5@b^ulZSS#^3|,<B#،llI=3$Ai6(/ @[#Ӛ۷oGDm ΤK ezСC06m۶M555Ν+|&g`{U fAekC8M7 .Âee7vA~'LZ њ=ʔ?3):( Vپ馛Jw26}J+H N$ٔi 9558^9y?v5aFB7y8y U%e|ML7*^0Z#Pk$ÇGHv  c~__^?.nou@ i;2Кj;v s9X+ fRP~GEGT .3.fBPaqEqG_ZÕ5NDb >w$:(z`@SG06 )N8ښI&u,| @&Tj2<YŅL(,ZSVV.{=քGsR  6A_ bfl T~"@QF@(䡊ښ_ k߆DHWmz;>" l mMRRXxHw/05~M.iBnCdր@[Z ]{k֬'YM J&"`6ߝw޹sNQŒ_Wg}63xP@OL5*? N)aG@&kk, Zi 7܀2Ifk^oИq`I@}(N'k2ML!4aS!WP|5ڍP eO~sa,K&j>t 36ps(3hɣG DBPIq#J #mA.?Af+^zf`6Mēv?%K@_:z@J*l N奲Ba+e2e֭[߽{7|n.q!U\o( Z)5a, 6ƌEhM\C8aMo Y6eof޼y` )~!Plٲeٲe3_1ksd60ٛ/E&Dm  |h #\jXva4#*gʕE&ěB`OpkL{BO|}ZCkdl"G7E#@&+x!D&y'Ep몫"#TWlL޺Hܹ./<#[=4(0D|ðCepڵkyߒu]|Š>0%A ,(( I7oYHNNiAשADu;C 4!UT%XV + X6b769VkMv=.xź=DoЪ/&B:˯'%lsZVot{#[CyT\\RRdm:.JSjTF{iumNdې"5I1G"Vxs/u/k񯢮Zbk:jA7ztjވ@\p#BA`ᥣ#2"DY{yih%2 g}RQQ7m4#0~xNf`=JPWӄk͇A%jF~i,tcƍNQL]n]N=ǣbz V2TLUҁ@*v{5~W\duF d"4hHgmKVOSӪ,59#i1O!76{Y`ҌO^+ct "+Ok[S`WiY3ħF>oY{eSB[z5ѓM`3bQ`al{}@aBi2F߰au>ӧAy,5'eu-5&k}pݑj@t13z 7TRVNҥEdGGM!js道cYDiD_V]f5J9榎IbJi2Nړ9\WJ6ȊrҨLIPWo ,;9X͈љ }Tzf׮]wy? ^]Tsssa]ٌ06꙾d N3 Cm ӟ'J5xLZ#2_Rײ-zga-cbT¨1,<'rRO05.Pda$qޓ>{bTJח<]C]YexUz_A|anGpIalgR <i!߃F5 aK~̘158g^> M|_i9&MMVg.hs '%R4[e -A+sTs3CM|A >:X3Fu $<@uuHԮ&gM& @/0R"AnY[aLo+&##wZ#sG5۪M-vsw.QFFҠ 2c\Ax׊I,ߘ pvco >fM^67'p\#1؆6 $iyc35jFB/ͳ:VuwUuկ__}UC3$N{.Rp\_b\1/ǐkXLba3GuSr[ R~-d|cUD.PHh!Ϻf'ćj.l^cǎaVTii)&:a1`3{bMHl% Z @F Lm`$Hˬ5X9C̙3qK{?p@G{ۏi8&X2̂aOe*'$se ȊO (Vfp*-SBgݾo/O9(z/JV=M$ߵ;c^>^|`C!,7׬Y) @a,#kҦD` @TT l v(8u=z0CSç{{ p9pgo3BJ_@q=qy=FaR#P!ISxv{~saT:;:::X^*Xx#hkD qH$-TYZkGbͫҿsp[%]^ݤ4cꓠo2?W!\*j\gœ|4yw `?Tl.< f6]i ."hiMOGs.Xy+n/SͲ XM.U ('ґn) qD}W9֝/ezϏʙ|/KfCxp,2*αFlI^ГHӌ.g;U`h3?1sN-IDk}rmyʆYìLO;J`;sѫ'yRUbT;cRtצ~YɁE2i ,6ӇN8tezH&oVt\ne?ȭ|rI&Hd@'QAs#Dϯ>M)V>?N#:@H=53I>%Ԍ$ɻzӅ9$d+=Yӊ`!M23pi3 S0,=7]Sw:W7J**gU1žuK[z]?,i iǦ,4XٽGMJp)Ba_unam/4uO9_Y ;%ex/ ( JKKt$r~)9X6+'#,"6nzN6tH.\jmCϾVZIVxۢ*:2P1 Ynӿ|sRiB֌In 7@"Ӓ F>;D}32Y]ҥKWXfSMغ.zꗺ]#j:)\T.W)PofQPÉ@ &q!>-,YJ$O͐Komjf]o|pe܌,$`3r F݉9^a㞴\ D N`i2֌æ/d/U Hg45rNFYҐ t11 7Ŧat ;MR&L8zC҅>EO.{Ű$d𓩤`uzcR]jveb=t71կ@~@*~Rx4f*c8p]O4*|g&cf_'9"BWX5cdMt #_YץY X}л_ffi7gi9m_],ajV M.=A4{1$Dnpt?]BD +з!+Q`FCٮI&' ;niV"Diu h…F'ʞ EIRD@98 C5fs*B%L4M6n6 h留o5w@.MS#@*Iuz``*2%ˠ"˘w쨡ΠdeJ!7F@4!/)W;rW9qc$sTnxiIv^l)a˭Zd>MnxIzlKyR&+K_:٧2H*cZuIѠ뿐7iҤ|M$$Z @F m#\,n7c45ORJ jCWn^ M/ 3[0҈KEEEVUד&AMji|̃ }}}5>IU7L:d~f- DzA\5M9Nl*pi%$l  B`4~BB0w,FA<f⍘JK!=:&\9pú:E7Ð MťeŅ0 we G|JcdWD, d $9gp/ PAsF>Ga1 RT@~Ƨ4)¯? Ӱ;qrnuq\kϓZҮSoU> \n+|R,6K[3yyyi*PO.8Ԛt$AN+`j_?`THₒnN<w5qv=$Π;׶i7խz+fӶdaWWSicB&ŌWLqoCi@~5 'AvBY{Rt["01o  &h_e;'1wItrHTDiٲEFodOni帍-݀,(7na-gn^Y@@0AwEi9CVM@?s= ڏ5qr\=힡i:Y+fJ>AP3bfV KT+{IDAT!>콿o^a؞)N0`IIh}vҪÉH' 2MkhnqeOMk#[9B>>q-ڊ0Զ7>r9~;g|O YzB:ѱ_*p,{|uDɳV,P-@~/]5l|;Ҏ ~떌2\~L_~l\y&n10裝  V9&*s99L4Z[x:ک*ֵt >t<s}ҐE]p S3l|hFAI@b/ĴJ6l nXٯ/jXS%;v=_ZN:s71AS*7y{gwp-[`ˊ)nߺMw SƧWٳE z{>Lݮ?ze vE/"D cL1wz["xw"HЫ\o#bb_hLl󳚔:/->5ydsD^r{};̹}dI9UW 0`1 @@ n8 #qӜDHِz!2 ͛1ѩږUΫ2xܵ-rv-k ?..5y+f7YCZ¿>~|R "eEŸZO689nB۠VaiFv5f5Txlm4C9}cJճr>,6 J5-] F3l 윕RzHl"[a7plaww=(*XxMw>J&h"'j>磂?~l֞t4tXV xҞzG 7)?prضG"V 44'I&@v$M0 /~U(3]>}mwMODݮvnk9 D]w:[#6O-{B[QѸ&"fL(DO.߳oHg kc,# `a0&aqeɆÞBG"@G4MRɉ%>6 W ߘm3sbjw<ʵn%kAFAlhG+/r^,fEVڟZ?<ٲehu}-j !PQ3\rz ;{mYˊqk9"KrO/ Ai]90Y$ t xiM.zXD M;?w:Ba饣3צYǮ[`y疂t狞߾}#Fnmaʗ0qss*mΦ&סEjaଌ+9biq8vm"^Qo`\MhjAΆt潭jϯ3f;VMv7tx3ig4Ju@dyLxx:HlVIz C4P4iGi!xhδ/ţOD0*}]2-]l\ K⒒0|:a PSt 1Iz)in eJ5 ? a8 Oj )C< ;J£\XC6M)zWJSMѼ/hll`۲mbUa o4oYx}6x;v2.:G*zv_ uq.f76;\Y`~"F5>Llk,{İJcn3|$:jXԜtK/|3lmVxK .oD)l)=0Yj0f=o^Qqo^9&Sj,4Xf0$cߟ~nݮхX%u\fZ1fT)2~+S-{jp_aÌ KgqC,ew ydJ[xƶ-65+Y_Ј2laceC*7JN>W(NIw. 2S1S*@ D xODT&HX& zq`q+(=aWLaxK gxQguxR'(*|\YWlfUY0m0 G+X$oI4"q'YFIe<)f1 2 vT/5rp|^қlv^4R />ڍ5}\{aBuwr5g q8;?<;/g1 c5x¨cCq"@2iL)aKa(H&kp7H!YP+>iZ'ul<#r UW&|_X>ѫ|rY Jsr,|oq6DM*4#@&㺌*<:UD 4Td Nq&ngPO}yʄ;Jt.׼Vz\|Hr(2h+>Uz}2ܜ+S} ~3` CАf» $I&@&q% CC-"3 ^W ˂j!@\ z,ݢbNz"*]s+TwHhy2+g7]9!Ip~RdI #Jfd f%83A)ی: *VP^"@ni%F3 j 3ɨGHHHA#VA@R>s1[;I2?-<'m(Hz%  E;'; (VB)AYCP85YB2vh64RÊ; dnV M2ԌI'E'ec숚AaRqfp&ig{Du'N*n.&_Fujbvl]ޜnf,)5|x^ $ADI=#DxE22Y/3' "l-(+L@ͨN,0dQL*{H- Ms){&`5V#j|P!kyZk0 Ŝ3~s/flRkj,NK\%S;8'K3_wR4=Ռ (&GYE`u`u)H25W S*4T'}G1&O1Y8@`zxs>h{JUǗr])c0;/cFjna.#k8s%΂ Qc5ṕ8B lgGWpaSQ hi&(؇ʆ}e!aTqNEwuƞa@1^pI)y,oTl;)@ x^K&]QBc8:1_iK%y%9]'9G/K9=G`͠`R88e*vDz\aGDZQ# ,=˒o(U1  2U 77Lʆ+B0 꼒挃anPaEޤMowW92'ɼWE4rXRo1pVAe%AYau ZNsޑFN6>GRE;L2D A@F4i`fةzw DE##GdS"@iSjф7eO,3@@0A*ȁday=$ NcQtC;PE\cW^2AfDQVXi,X0.6\^)"~]$p l|Dд@Qa hFSiLvpmĕqpud\t#@&Z4U,82} aG&ea8~*/1C@!B݇<̺2?PWa'%&VBp0^&UH͡R31XL>B[0*M MnF,U0J&bpdv&bT5ԠV!*i"U0 ;eq!8n!; bB٠|+/#WALE9 >0>>1ׯ\grP)6EPY,|l  t P3lb aV!P"pH:C*A Ml,#8UKr i7̒YDU@H6K GlTQ%,w8L^` L:A{%x'cXNh, }X-FT b7<]$s0 &A05MS3hk_j3  &@&x P 8T HT"#NY\DբP F 5,0XعsP/* "\CG,(Y,z%W&P A 0A"82X~%ر||(6͈#d S6LȲ /JfDZji2b ,^Ͱ!'pA2>Vt"0!HLF**MTq1#L0}4ڀH|Kəaza"RpDifR M8T2H KLa&>jFVifwQ ")J` "Ii4hm`meEFՌ+^DtʐRa6ތ -dL$D IPŊԸ2E_:#]!D$idҦg4%0a5VL6Eˈ D"@ҟ,'"@ YO4Mw15"@&D7S# Dd=4Y@"@  @FL$D"Hd}S DhiMt35"@@ M]L $D" i4H"@ YO4Mw15"@&D7S# Dd=4Y@"@  @FL$D"Hd}S DhiMt35"@@ M]L $D" i4H"@ YO4Mw15"@&D7S# Dd=4Y@"@  @FL$D"Hd}S DhiMt35"@@ M]L $D" i4H"@ YO4Mw15"@&D7S# Dd=4Y@"@  @FL$D"Hd}S DhiMt35"@@ M]L $D" i4H"@ YO4Mw15"@&D7S# Dd=~CIENDB`ovs-2.13.0/Documentation/howto/qos.rst000066400000000000000000000135551362155554400177340ustar00rootroot00000000000000.. 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. ====================================== Quality of Service (QoS) Rate Limiting ====================================== This document explains how to use Open vSwitch to rate-limit traffic by a VM to either 1 Mbps or 10 Mbps. .. image:: qos.png :align: center Setup ----- This guide assumes the environment is configured as described below. One Physical Network ~~~~~~~~~~~~~~~~~~~~ - Data Network Ethernet network for VM data traffic. This network is used to send traffic to and from an external host used for measuring the rate at which a VM is sending. For experimentation, this physical network is optional; you can instead connect all VMs to a bridge that is not connected to a physical interface and use a VM as the measurement host. There may be other networks (for example, a network for management traffic), but this guide is only concerned with the Data Network. Two Physical Hosts ~~~~~~~~~~~~~~~~~~ The first host, named `host1`, is a hypervisor that runs Open vSwitch and has one NIC. This single NIC, `eth0`, is connected to the Data Network. Because it is participating in an OVS bridge, no IP address can be assigned on `eth0`. The second host, named Measurement Host, can be any host capable of measuring throughput from a VM. For this guide, we use `netperf `__, a free tool for testing the rate at which one host can send to another. The Measurement Host has only a single NIC, `eth0`, which is connected to the Data Network. `eth0` has an IP address that can reach any VM on `host1`. Two VMs ~~~~~~~ Both VMs (`vm1` and `vm2`) run on `host1`. Each VM has a single interface that appears as a Linux device (e.g., ``tap0``) on the physical host. .. note:: For Xen/XenServer, VM interfaces appears as Linux devices with names like ``vif1.0``. Other Linux systems may present these interfaces as ``vnet0``, ``vnet1``, etc. Configuration Steps ------------------- For both VMs, we modify the Interface table to configure an ingress policing rule. There are two values to set: ``ingress_policing_rate`` the maximum rate (in Kbps) that this VM should be allowed to send ``ingress_policing_burst`` a parameter to the policing algorithm to indicate the maximum amount of data (in Kb) that this interface can send beyond the policing rate. To rate limit VM1 to 1 Mbps, use these commands:: $ ovs-vsctl set interface tap0 ingress_policing_rate=1000 $ ovs-vsctl set interface tap0 ingress_policing_burst=100 Similarly, to limit `vm2` to 10 Mbps, enter these commands on `host1`:: $ ovs-vsctl set interface tap1 ingress_policing_rate=10000 $ ovs-vsctl set interface tap1 ingress_policing_burst=1000 To see the current limits applied to VM1, run this command:: $ ovs-vsctl list interface tap0 Testing ------- To test the configuration, make sure `netperf` is installed and running on both VMs and on the Measurement Host. `netperf` consists of a client (``netperf``) and a server (``netserver``). In this example, we run ``netserver`` on the Measurement Host (installing Netperf usually starts ``netserver`` as a daemon, meaning this is running by default). For this example, we assume that the Measurement Host has an IP of 10.0.0.100 and is reachable from both VMs. From `vm1`, run this command:: $ netperf -H 10.0.0.100 This will cause VM1 to send TCP traffic as quickly as it can to the Measurement Host. After 10 seconds, this will output a series of values. We are interested in the "Throughput" value, which is measured in Mbps (10^6 bits/sec). For VM1 this value should be near 1. Running the same command on VM2 should give a result near 10. Troubleshooting --------------- Open vSwitch uses the Linux `traffic-control `__ capability for rate-limiting. If you are not seeing the configured rate-limit have any effect, make sure that your kernel is built with "ingress qdisc" enabled, and that the user-space utilities (e.g., ``/sbin/tc``) are installed. Additional Information ---------------------- Open vSwitch's rate-limiting uses policing, which does not queue packets. It drops any packets beyond the specified rate. Specifying a larger burst size lets the algorithm be more forgiving, which is important for protocols like TCP that react severely to dropped packets. Setting a burst size of less than than the MTU (e.g., 10 kb) should be avoided. For TCP traffic, setting a burst size to be a sizeable fraction (e.g., > 10%) of the overall policy rate helps a flow come closer to achieving the full rate. If a burst size is set to be a large fraction of the overall rate, the client will actually experience an average rate slightly higher than the specific policing rate. For UDP traffic, set the burst size to be slightly greater than the MTU and make sure that your performance tool does not send packets that are larger than your MTU (otherwise these packets will be fragmented, causing poor performance). For example, you can force netperf to send UDP traffic as 1000 byte packets by running:: $ netperf -H 10.0.0.100 -t UDP_STREAM -- -m 1000 ovs-2.13.0/Documentation/howto/selinux.rst000066400000000000000000000165621362155554400206220ustar00rootroot00000000000000.. 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 with SELinux ========================= Security-Enhanced Linux (SELinux) is a Linux kernel security module that limits "the malicious things" that certain processes, including OVS, can do to the system in case they get compromised. In our case SELinux basically serves as the "second line of defense" that limits the things that OVS processes are allowed to do. The "first line of defense" is proper input validation that eliminates code paths that could be used by attacker to do any sort of "escape attacks", such as file name escape, shell escape, command line argument escape, buffer escape. Since developers don't always implement proper input validation, then SELinux Access Control's goal is to confine damage of such attacks, if they turned out to be possible. Besides Type Enforcement there are other SELinux features, but they are out of scope for this document. Currently there are two SELinux policies for Open vSwitch: - the one that ships with your Linux distribution (i.e. selinux-policy-targeted package) - the one that ships with OVS (i.e. openvswitch-selinux-policy package) Limitations ----------- If Open vSwitch is directly started from command line, then it will run under ``unconfined_t`` SELinux domain that basically lets daemon to do whatever it likes. This is very important for developers to understand, because they might introduced code in OVS that invokes new system calls that SELinux policy did not anticipate. This means that their feature may have worked out just fine for them. However, if someone else would try to run the same code when Open vSwitch is started through systemctl, then Open vSwitch would get Permission Denied errors. Currently the only distributions that enforce SELinux on OVS by default are RHEL, CentOS and Fedora. While Ubuntu and Debian also have some SELinux support, they run Open vSwitch under the unrestricted ``unconfined`` domain. Also, it seems that Ubuntu is leaning towards Apparmor that works slightly differently than SELinux. SELinux and Open vSwitch are moving targets. What this means is that, if you solely rely on your Linux distribution's SELinux policy, then this policy might not have correctly anticipated that a newer Open vSwitch version needs extra white list rules. However, if you solely rely on SELinux policy that ships with Open vSwitch, then Open vSwitch developers might not have correctly anticipated the feature set that your SELinux implementation supports. Installation ------------ Refer to :doc:`/intro/install/fedora` for instructions on how to build all Open vSwitch rpm packages. Once the package is built, install it on your Linux distribution:: $ dnf install openvswitch-selinux-policy-2.4.1-1.el7.centos.noarch.rpm Restart Open vSwitch:: $ systemctl restart openvswitch Troubleshooting --------------- When SELinux was implemented some of the standard system utilities acquired ``-Z`` flag (e.g. ``ps -Z``, ``ls -Z``). For example, to find out under which SELinux security domain process runs, use:: $ ps -AZ | grep ovs-vswitchd system_u:system_r:openvswitch_t:s0 854 ? ovs-vswitchd To find out the SELinux label of file or directory, use:: $ ls -Z /etc/openvswitch/conf.db system_u:object_r:openvswitch_rw_t:s0 /etc/openvswitch/conf.db If, for example, SELinux policy for Open vSwitch is too strict, then you might see in Open vSwitch log files "Permission Denied" errors:: $ cat /var/log/openvswitch/ovs-vswitchd.log vlog|INFO|opened log file /var/log/openvswitch/ovs-vswitchd.log ovs_numa|INFO|Discovered 2 CPU cores on NUMA node 0 ovs_numa|INFO|Discovered 1 NUMA nodes and 2 CPU cores reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting... reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected netlink_socket|ERR|fcntl: Permission denied dpif_netlink|ERR|Generic Netlink family 'ovs_datapath' does not exist. The Open vSwitch kernel module is probably not loaded. dpif|WARN|failed to enumerate system datapaths: Permission denied dpif|WARN|failed to create datapath ovs-system: Permission denied However, not all "Permission denied" errors are caused by SELinux. So, before blaming too strict SELinux policy, make sure that indeed SELinux was the one that denied OVS access to certain resources, for example, run: $ grep "openvswitch_t" /var/log/audit/audit.log | tail type=AVC msg=audit(1453235431.640:114671): avc: denied { getopt } for pid=4583 comm="ovs-vswitchd" scontext=system_u:system_r:openvswitch_t:s0 tcontext=system_u:system_r:openvswitch_t:s0 tclass=netlink_generic_socket permissive=0 If SELinux denied OVS access to certain resources, then make sure that you have installed our SELinux policy package that "loosens" up distribution's SELinux policy:: $ rpm -qa | grep openvswitch-selinux openvswitch-selinux-policy-2.4.1-1.el7.centos.noarch Then verify that this module was indeed loaded:: # semodule -l | grep openvswitch openvswitch-custom 1.0 openvswitch 1.1.1 If you still see Permission denied errors, then take a look into ``selinux/openvswitch.te.in`` file in the OVS source tree and try to add white list rules. This is really simple, just run SELinux audit2allow tool:: $ grep "openvswitch_t" /var/log/audit/audit.log | audit2allow -M ovslocal Contributing SELinux policy patches ----------------------------------- Here are few things to consider before proposing SELinux policy patches to Open vSwitch developer mailing list: 1. The SELinux policy that resides in Open vSwitch source tree amends SELinux policy that ships with your distributions. Implications of this are that it is assumed that the distribution's Open vSwitch SELinux module must be already loaded to satisfy dependencies. 2. The SELinux policy that resides in Open vSwitch source tree must work on all currently relevant Linux distributions. Implications of this are that you should use only those SELinux policy features that are supported by the lowest SELinux version out there. Typically this means that you should test your SELinux policy changes on the oldest RHEL or CentOS version that this OVS version supports. Refer to :doc:`/intro/install/fedora` to find out this. 3. The SELinux policy is enforced only when state transition to ``openvswitch_t`` domain happens. Implications of this are that perhaps instead of loosening SELinux policy you can do certain things at the time rpm package is installed. Reporting Bugs -------------- Report problems to bugs@openvswitch.org. ovs-2.13.0/Documentation/howto/sflow.png000066400000000000000000002473731362155554400202470ustar00rootroot00000000000000PNG  IHDRitLiCCPICC ProfilexYy8߷{&spdvyscL)JATH*dhPJE$L}5|s~Zkλ:QÃaFBB"l(.;+2\ ϥub3d=#B|X+<" *B`}3G "6/A J()1^~XPPz^Hm.zT?:T߂D&6 مG#WcBzBhoXό7yr!_>Cd P;%C=-`-#[#c!(m37<=)_iWOi lg1"n3D0QDo>0`d[f 2ݞ9P \0DR?T"ABp2" `9燌) g߳Q9 K"sl󶭋tHל%FVvV_hy"ZB ;*h]6Z#0hkFߘx5G=r/ \_ Ca~Q]dHRLC%)r7m{mbOE$DE 8-$qEF⎾y^1dd@" gyԁ0f ď? ) iPJ@9.F @S`| ;؀ !2BB$@Z!dB.B( : P5t u@gkh B0 &07, *.l{a?x9p\Mp~ Ÿe@ѡXQ|() JerE"PI,T> UjEFQs54MFSRH^}$t6} ݄B?GЛ" #QØb1~XL&SƼLbcXVVkubc v38vñ$p8+pU:^y#WPT|;444BjV޴񴹴x^Sz|7~NΆ.. }15AOC&ׄ%"(L!9j=qL/MoJM~~AA!!C?#-0>#1&2L#YBH٤ Iɐɛ)8E 듽i r7y,l|2&,,q,E,YFYQ¬;wqdG+ll:l>lYl l/)A'؛ه9699899889p\\\ʹyùra 3K BѥS (]>.>h |O6ES*y  R:#+","$),<#&b* R+N(-OLVLE,HSqX\Q_H_P8'L#**Y&9$EҕfNnq9!+)(,[!VIL.UU| Aŝ;}vJK1SS񧒲RRҬr J}UA655%(F/RA53">T Z-RQm>mvoJi]1@:y=Yz+j(c,'L#FF~FF ƊM0&&'LLMLM̔ͺ v,-",ZwvR2Բ XZg}kcmSd3e+g{׎lnWc^>CC#j'N2ΉΏ\8\\Z\q˻ w=GqOƞ"{>pp vNupAQ=M==x}93{wO߬\~@abI`IJUPUVSpCMGPРЮ0g޷aQ ElbF.}ѢчbbbVccőBO'%\܏ﵿ߁c$Ϥ΃N&'_J^:hyMZu77fg7nv޸%}6;;w&]not|{ދ.'{z޽yڃU6?RzԧwO4+ KOM@!:22zBݬ*952_R^H }."/;&oШȥE^M_ּ }68*&gL-jw[umBluO9Ĝ\\#v9{%jgWyB,5$9CBCg^k̏:k/c?PbGR3))!i҇820?r=hvc999sN;yӉQg <:K:Ow~dɅke*Yp/K{i=}LxɻuN$={aRmP`8jηʆO$;fAq2:ztLl]sCK烾(/`뾦/y|]ڇ?~~.J5dbp4,4Ӵ=JlB ѝބADG$0ؕ99/p pPrB҈H!R8s\IJ9VSNNHsL[L'DQo@0ͨɬ9ւRJZFVN^AȑӉ8qq}uυn=u'nPKq=.ngwᇃ<{gyЇWLnnxadѵиЄdTYGO'^ϋI[jtkY{êڭ C/ }ϡ4蛘vBDk/u | $,+YYŐqG [2i˜\#Y>K0BKlb~ْW+dS|4BPU3Q8YU]s^7W/I?PHؘxƤY+%u6IjvW;:;;.㷗wqwSȣ#/?PD . q % 7هw/"%R+GŘx$RX $$DĊPbC_2oܿ@ AWo:8%5 >-}]]]ߵ3@r !7FΏ>ثw!!"4< &o",8, :~a)xï(~)*U@}B"=t(E,L V`7qʸeG_Jd Jg8|*6x^̐э9ɜԃ2=d Kf*"K+;;VJW88]\]I}~+JX!3aAHdTS $} edv(J(+ȩ hjjhы570Z76u42ii`uzVr:8oRwram}zto ]?! z_,o܋VIߧ\I<䙩s5]v\$gr韣*+뮨,t&ε^L#u&| F.ѩEɸc~g/8^+56zm2sG%ʲJٍ[?G@!'2F ;JRg@RCK#$ A{8(jD|&Ê3| (6*uՃZB H~>d6H.~ +Öcq{pŸa 7M5 m m F$? zWBI~yx2|Y>7Vp`óc?ȡɱɕmdzM)d.4*XMARDXHtLlCeE%Ies7h\Zs$5]< #yPZqحىvsqnuޝ>O _L f 3HHxqpCڙ=Y9Y,O_K[.}!"oܥ[5G, W0ilYl}VyPOiL}ܣ7~vyKWoᇛ{~0Y:<8dJXxSqр'A*MFi4^2E*BH ZY` >(JYP8:]p#=3eaOc_xq:REɣU=Bҕ@Rߘac`& 2yȭa,,.Aϱ9S[B);_.P/&@xHdV Pt:,}CfJKIηJ*wHZGt< LLͽ,,C&mmGœ7]AE{z;bn"ws;^5Y_I?-C]=1rtҳNjRŔ_)^VM,pscV6ۣw;iv?T|qY3#_x I ۏľx|p䳩ƙď/J_Vn.F}:Tj^} ~5uՍs?LRDDCʏ#[[KH$?Olmmmm,G ?Wl c{q6OO~{/ pHYs   IDATx |T՝$3$d^!-P U؊n[/jlb_D>}tkgUA u%"o{ 3If<{LLwəs{sι<ƒHHHH  MHHHHH@%@ @%E;    jG~HHHH%@,)ڑ P;3@$@$@$@$,j`IюHHHHڑ    ` P;Kv$@$@$@$@Ԏ K1XR#   vgHHHH XԎ #?$@$@$@$@v HHHH    chG$@$@$@$@ @%E;    jG~HHHH%@,)ڑ P;3@$@$@$@$,j`IюHHHHڑ    ` P;Kv$@$@$@$@Ԏ K1XR#   vgHHHH X` id~NZLlafۮ߮ްSE)W=3HՑ @0xcJKXxմW]WOPߨ +R=0HHHP;xvJM?07i!!o/|}YxrQ|%Z%۫ˮXt Z%  /w /$)ޫB#UT8qӋ}N^lQVSٱR, 4vvhEr&[-䁭ԴUav}u$  x!qx驾])vg_}ͶuV:7GM{r~֍s|IX W>+f_vf   =j3LL|Y -Wn9xʦO{}'+}կqwqVҪth\xW   v0,[^[,h2iɚEqaE #6pd/s5 a0LY"3.#  zu.&4уچ0ZBr v\J]zIj}w5rұ:b4UbUjoL_=ϱ @d p1|t.)Vax<#|Oͻ|7^{ +}m-@L(-Wݯҥ w$@$@$@!`x<)#<8mڂCSf~~% d ͎TK"nL$@$TX   Y 3 @RvLfcIHHHW{IHHH P;&Uw$@$@$@$+Ԏ$@$@$@$TX   j^cf   H*ԎIl, c13 $jǤn6HHHzEڱWHHHcRu7K$@$@$@"@+|L$@$@$@IE1%   ^v>f&   "@Tƒ @P; 3 @RvLfcIHHHW{IHHH P;&Uw$@$@$@$+Ԏ$@$@$@$TX   j^cf   H*ԎIl, c13 $jǤn6HHHzEڱWHHHcRu7K$@$@$@"@+|L$@$@$@IE1%   ^v>f&   "@Tƒ @P; 3 @RvLfcIHHHW{IHHH P;&Uw$@$@$@$+Ԏ$@$@$@$TZǃDjB1H`0+%  Hc۶mַb$@СC_M6 RbaH+vKKK)7لx!xԔ~N$@$[!!GvvvbH*@pj5͐z䬄HO 欥vLOa#/4f3Lw7.Y 2DЎqV j^$H ,>BG|233!R> ! }qǍN0L! eNS_w/M0 @wA;mza8DH}!JcaB&ocKK|aHH $v $Œ;@0B j凐YHH@jnj~1a>lHt @;FIHB a#FGǨe$`rq1! %qPhO$H_@&! $$A$a$@$@$@$"j1 $!j$t6HHHB$@"8f#   $$@현& @Cl$@$@$@$d   cHHHcv:L$@$@$@!v  @vLNgIHHH D <y\f6ǃ2œlxq,;͎ޡo$@$@D1ބX+"]̘4@[ڴ< iSߝ'Yx0  SԎ}qG>>{Aseetl>qo2R\uڰb ;MS*ĩbeGC&0O(ΏOrꥻ$@$@Fڱ{Y_gJsT8QCƳu>dFNic답>hd?cht ׈Uֺ $@$@$k9#o,b jէ2R~ twc<mqasY鐺;2/ o} >Cj3 @_vK޺; J֘S;&Sbc&d:^{2`?/wGo;"Gxrs$@$@$=zB֜75O)SI zc?KtgMH]زW2 ":"s?j748=C iB$@$@1F1: 3)][8mEuѰtO1ػ'u]cnR7;%vN>鈴]>+Hi=b$96HH I P;F[903ګ P{ѳ=?lOʜlM v+a\0{ j?ϛ?q$@$@qC[q<mcb4}OX{g-Wm|՞̥(2VR4*Ϝ;] {i@d;޻\(~%i>g6=>K$@$'Q;co4;`|ti=BtT>w,KSTmdj_z?آX8aJ{2sݯa ߑ @luӁB.fI۹wk?r,t;5D#FxN ;F+~21r8ğҶwgI6]zWМc1"l?دtŎb+uډq. @F{˪: GotYn%0$2#|$HH p:?l? O1xV$   d'@HHH'@<+Z @vLOO$@$@$@v -IHHH P;&''   P;ϊ$@$@$@$ @gEK   HvԎ `IHHH xԎ% $;jd$@$@$@$<jYђHHHc~   chI$@$@$@N1?l? O1xV$   d'@HHH'@<+Z @vLOO$@$@$@v -IHHH P;&''   P;ϊ$@$@$@$ @gEK   HvԎ `IHHH xԎ% $;jd$@$@$@$<c쁀ݶ/`>#3ԬHH P;&a$@$@Q%~G8I_l_{-o,͋hUlˎ%ԎFZZZnnncccEIĸ̙31d-==HNS{֬C6?#wϚ8,Emwftl^ {5zQ {o t#L1 ^TVu߷#W4l[M{!S+f͓Mpڵ♪ x9~è`% B`0+EG,]?q]]]%\V(vDAA%Kb#. #I *>޲tʚW,|>O_6]gߑ+,&;舗_~m}"333??1"=I Lyf=!qz?#bț+zEa٪¦Ǖ(6X&jlsgj0_"C7%M^jrٜIjG!7xC[o͚5nDNCdLLaE2o#vq7|S {7///!c#",J̫Ph͒?Ҏ+a/FDgplo}r8`i6 -cx\<7>#'Jr|C%je`FPѪ<<@U]jvcKKޙwP"qr,'7j=DЎ999&-rzNW'O ILL2xf!Q IDATG_uDkkk;}_3<*P1G 8 y]ߞ]:QGI'KgƵ/kU/b xdZr˳Q =ʶ/\)LTKkvS;{tYEZn|l7}7Yp*3ilX_WVu:·boju|ۼyϝTq`MF0l~Vc:a(E3PmԖ ?}_WW 3+-2L%ۅmw~G+|t>\a`0R>؁hG{g#Z}|0L$ܲU(b$e1i !<7eUͯղe&*^w53/N5_F^ص R5iET춾j8sBW徰NZ3aWxgRk`}RYF͠1Z&Jo;:e"{-z;WN[/[y E^^uڱ}ͫ:FOEr3C5M-n`NE|KԎ}I2^h"$ƍ 7>CE`{2dn޼c!/2vO@tnRC,?nX9Fx %(!_7K\=l W3nR%7Zd6R)NV cC|gu4r5w~nZ WnLX77T?s)Ӵcʔ3gLvM~3nn~eŮr/ P;%˫KhG|c=6h 6.dX,x}Hryp/x! 8~W`@l`x Θ1C}9eӖH z0m['(Tjãܡ|y+J-l|+?k}mTxݟSt]LgUj ]=Yw9&c_Ο"*eP;ˬcW8/^cl@ ׎x}a˗ ˬAlx!f///y9,%:m۶=B#KPEӈH ,<:SurΔӡ =_k E\_)_}W-+Rj[֯R=8;gGzKܼg84 d\?s KNVcIꮈ;q)Ԏ"tqqOLvv6ƺ*GA$a:RFGD`NL,:#R;bne[%2 V-6C#j..wQ叛˦dn~/,1lO,732^>u ą>,vr߫ØnRY1{+q ᔹ: bspWϛ4zp'.Y?Kb^y_j8E Z&:1R )H< fnhuv>^&%>♀wbuY|cZy/nTê+Vv9,xQ2R&Íe)bWu\T以1UWQm&h]_iȢӼTe#*{˥Wƒˊ+|KR9 r&0Fc$L1܅a-H 1@İ,Z<C Le \:%j`G ""rH LD=DZͫu,P '0=t_WSM7oڸnizw>@!N(]l n1]Rn 7Tk7vx!CQ_-~r( û){'MT%HCwtFwIڱK,)4L ŢHH d )vu% ,qn7wLd\Oq/.ctdxE7HH7ީݺ8`e;/=go*f8!q8(M>:}% yc=괟bM[cǛek؎6ӈv,G#P<9,;;'eAy{ȅre.D#Ɛ $K4LEHL(p"%,Q%e@_N"K`F#B'"(j.Qo{ȅ(du=d@~5%*{^xZ"XIcZE!G`Fڪn3a)jfE)((̅gϢ̈xam---gΜ|EIQ[V1Gnė=z1]G,"EH$/oCfr}"#E^KT= ts='ˑ$*.??{n(텱,}QM'իO8!2 'a "Du8υ "3"I 'o6Wb?ڵKo~gr3ϟН~->,}'NHz뮻OTo~ǁ"_ ĺ3c< @BH(/cӦe?BZC+]fEEEˌȅ#1=#7|3ƨP_CuЅ#GDF@\{ȸo߾.Cхz?!+amm-*2 "!+QQ?F9@~"]Ǐf~~KsQ3ֿx"l֡^D@_T7d¢"`06OD@98 aB#",T #2j^7n1" 1Z! GXD:/}KDxE(6WdPIb /jgDXY` DĈ0Չ$z(\VH1lȅ(ՉH+~ae q,ۂS4Yֈ࠯N"^EY@3J,Q_< q fԈ%^VT$Y$S BBՉoqH'̄%.|0ɎQ'A.#3" .dXP 7PDxE.d??':E$ fK?Ei $^[ ʶK  H* v$qU61#ć(%2LWY*'Y`x G@ JqEǁH yChF.@Ȃ"4:J*QjQO[' `C6 AJë~^ɼeEEw~ʌ~~" ~X0:)"t(8  A`,@^HgwWVA]"\2>"a?=e  $!82(jp})/zcUb)3$!pA:@V$"^š.sLC s![$A` U ,EF*,EiR]uYcwP22(Y֫<m9+3" bC.}"Ȃ\ˌCDF ~y12,jG]8Dh#'̄0`J}9"R,ˌ.sH ̈qG a& H6sV+p%Pt*R$.2ˀ,A#jJ"\A.qti/ Lշ*D~d"&P s!UDW KK}Q"c0f~BΨ3bQ$P^(apI8PK f"^~e @bH(( 6yEG@L`ԗe]=aW] 20{o   8%Ӷ%͑:8 }] vzx.ٳ7TH(~$ 3mI%:w@S֬YtKHţ_z%$alXli.)ΛNIHH Ԏ]@(! 1VO~#ڵkO>0OzĨ$UKH!pç~ZjG`_|b $  !@;}  U u4 6#al.#`qTB#bJkA'|"z#ux44K# !Ԏ1~fq7"76+xR{~m *:/ìQoWo[t Me $@$@$cST?EE%&o!RN:u oKJJ<-FNɢ  ]wm݆.\ 0{#pHHH :C T vdcn믿sKT !Ń|=/`޼y#P0L$@$c[v..h"HIM7t7 I1*S#VD/ 2OOH< @v ]-2z;S cA8X%KD{ xqc+ HcD{ qqn @vB,X`׮]X8rHf\ c!qo;&K.E/ R,`G< L`ؔСC*{9QСC'N&ᙟڱ>Q\~=nd ħܐb{".PX~ TWWcqjTW_$/TI ^oʖ-[D/Ox≟gxldCD/uoD8^W#G 5@xEvqz(BUbE_8=5FGyOmQ߀Ѻ>W#z #7@L?=oӓMÉA1왊E8rh[l0큥e8!999:|h\Mnl׫%Ck IDAT?9SӞX1'5S[gNl[F{\hZҢοV5aņ$'<{-l5PP;t55N fH1_دw7ʻ{_>K t%'٘Qv Oxl}UOE%߯b2C9zK1ĈAGǩcϖ @d.س1F{n) ##W#?$@$@Q&dp}CJ usnғ(1:M% X&(Xv%-|8~ }~- @,c,N8|+?$SQQUSY(>z/IHbcIDvvC]XyM8e=}(>>l* $jtqÿ>__X9H-g )/oPM25@uc4Xa쁊fEIt@eHH A P;Fc*mZ{Չ?ؼysuUOWUoY[{ޝՕsb]*67 \+a7Jyl)-4v|@ٜMό -& e6V[RTw=1:-  H\n,,V$̚zsMK6l[ʨQ'ƫnF)rߌ)yK X5F)箟jl>/ZKVԞZZ\l4|1J(;偱j7hR$*ƎZ"XTOB?~˼ HH p1xӚ رkמ/E=u|߮_~M㴅?, Uh;-L&|:l)V}{L{ !c|5xtkvvavG!] w5kM{Rdv $>Dk͞^j''*O7u&\bo{^UXrwv++49{/AzLjgJὖ6: V-^ig>}{Se3W5]gF%膿췎"  @~,1 gRz%ޕϙ_>4Gi!ՑÎ7pDTՖha,+c/6kk~: KPI˔ӅU+QY;K(Œ.v?yI$@$@Oa7:ZXxk ee ]33)+Ijh \ֳG- @LvoHe @ĕ1 4t:yY)Q'Kv.fܴ3,^ح;IztkCp|yojGF_ $jtMe`[!+kQٶltuTQ*w{O 5cؘ2+g_) ,Jzx1ڛpgw_#7ih ('#,& w* :;0w2 '1RQVC{=_h>,CRxŐb@e %E1(i@H/cP\P ƚnYZreAE%'M+ftaye*8_ީΘWz ;IÆ}V)1Tɛbu l8gkm5ի**j8~eIev@mqi\*/I)++M72I5{ׄH"Bs6nۣl[K{rN$ O4ڐRl6 n'5-eO9[q8݆ 'MH7k|PjXhV>Ͽh>uߞXg<<"o?uX.Y4r6^yxt԰@_<k+2g:]jE3ɺʉ/"y&{<>Vl7=Xq#A(HDK2GH‘_XX6:^vC}m2 FJn]*.E(6ӱ>?v%%$jKMO3K3`Bp;ۍ(18ct >Tz q:ڀu1Y; @ q?=kqaLU&O=']wCcc#6  ӎ%tXfOC֑+-5u̔{L#*!ZjkgJrߜPU F<SJJ怒~'𥁼ZtLVᠾGa0ev _X $4ns8l܌TLOJzQ|1$Nْ v9ةG'R;?hRyEfksr(ˉZp;}Һ^5nxU?jGp\frYnG3l.Gk+]}V>+8y*'4c@YRQoh0 $ lhs`I1\ѿXx5`Ea|L&|$| dddbˤЋS;g wge瘚8"]O*,-NOOosFlx-|_9Q 7=ݘY KoKHoIPLmwI)![[[?c˖-OFfAƢ"46; /| c$}q2Oiokn=pˋGGz79 Ćo})[*mWm̻h: aB O>sj 8Bv"$h~)QO^5jM ?v>3_:K1vdHg(x@Lڱg>ݦk9vsʈn3/ +uZZZ ю__җnSBDIEͣ].Off&-V(hß'l&G999w~'2>B'Uq?* cFmK"Bxy#!Mؗ;c;t\_pۄ=ۜV'\v7n0gIn6bWLMVO3fO݅zܠ3N.OK7A晌6҂V 6iCFg3Zڌ[g23asњ&kii ņ~YYfT+3&17|PhԙcgA#@XlW| 10l6v (FiO~{Rirଊs(N\N26hGB<F( b; 6c':9^ZZkX@#9 MN hÃcΜ>[Ui8-9ؐZ1Geeè#KKljۃAeC}@рî8p59[gh6g[q%W_vaO?9 /݉] ~+yyÇw5AzBf31cŜuV'+4Ĉ#$/ϻjoEmN`RJnnգF]lj`[ _x P;لvn' ̜8a Ԉi^{M1b to)'xBQI|AqD]4MhQ8s;~$``Y nτ`ciGxS%H  @v:nCAW@~FG#~nD%ÀG;nP2 ]aܳG1M) R0O68a<ÑMWOjOJ*xg,\R );B*j^ p=FSVn6CJ9+CvSZ]CYyXfbzV@FsKγ_u ZMTTs`J4Er"z+dݹ) 6iA)?\j;rq@HIzqA)U (2a SGXt)Fw܉'qa"#Uazh2*A)CX<>|_)KJJOyf -.T#~62>ҁƲ|(:4%5H: u Y joTlIh5F}5ݓbN5fC4Ԉ_{ DVN920cu:b8Ỉ ÇggϞwrJLU[R_*%l0%!q@;b>zڵ6 KK_}տ𨸸xԨQB;0@(rR_ZAiWs6vT67bo<_g66jeh65ٮ,-mnl9w:oĤXCyj;9wVN4k/KE:/6~AC8XYjfb!zԈ՜PKC?W' O :ګ;m!;'Bܙ?pIOLjL;ʼn,Kv~nn}t:ζEEvRkD; ' СLcpb7 zE|᯾jhG,W_O_y7tqR'v{ i޺ގ #H~;y7XHupC%';zAPKF mC N1̙-wJ6{)cSY Nd/qsKcKՙ¶:u- 5nEyCϜ9UCˢ蜼|yZy`jlnkl3d7|vľ(<#3M<lhwac@brI6f](%rK9imu];mwjK1r /#3- @Q!GGՎ#;M-2})MW]3׷nwCcТLR;pԩSwqGCCƍ]`6#qTUoƉ'2\iVXKZc=H]2Ԏӱ48ڍd[eb h|qVTgJE Ғa.7TEZyi^/H]NWnpVjmun>YW ^x1NhaqƐ1Vjp iXW4A1H1i #&L0z'N`K1wu|ĴUN}s8lݺ7 27x#1:GJ @|q mlXdmQVB:w$'/7GZWLGꖖP t^ë8Dw^g'.) H}a]F@fcqvFQ hX[N*.y8# \S27˜O AÐC,McШbA|=0%$##r6g}vɒ%:&.∱Ċ;< [?jvp -w'Xص 2q̶F@d 'p2W"98pA*v"lߴ8A|;Z-V.!/ MJ]<:(,E.Ge"/jDX*$r ¶>B'Z b=ŀY@|Bo\i<fΜ{~{~=`*6~%$gX=c@nqVŁӨ8"CV|s!bmqbx $x*4PfH^y   DxsAQ(U@Yb1${>\/pC(y6EUz9;+lx-dX- Gv\SR\T+S :BDVTT;8wTB$O޼y3"qr|'q?qMBcH \pbP2 Gl쀳7NMPl8c:b` KH F L qÒ$X$B b(6(YWH+YU XZZHQrhD80c Z[-V]f08p>8H=k?⌉=*Ug>N88QWH7p~M>΋5NDYTe!p>+fqv;?#Fd7ϝosUjPH @$ *lDxڨ"Eilֿ-`?nB J!TjϮ:5[u+uu{9~g[y~:# \[&wC 7/IwU{a /ZA`8\:d'Hogk.kvwq;sN\F ڇ对n ChDo0Kdb8!2iP Vچy95Q;"i䷃K=h ='RjP4u*b\R x5G繇ߔTp4fxy%6ҥKG_ r83_y啈q3 Ǐ0"YSSqi瘁  z{Rnu?=Rrˍe^ЩeYMvt'';nvhL &'T?A|ĸ=M@p4PWN^d}A3JЉ0dQǓH*a%NOHbbQl-l0VsłG+88R) sUV#<[ׯ_l2J9&Qv7^j\n+Dr  0"8Yy$ ; ƠFNe<m|jyO;y5חdM='awg7d։r) g!5}D}2ڈ& EEwCI30~39-L~;&=_/c8|7^z 70{5LɏåBYYfӟ4Qs qL;)f # ܍hוwA;?mNj \N8Fj4_8z8ph"> Mg\g8>[p ImFl,?;R肴,&2,NOQ4$%zh LiWCx4X.4UGj,#J8PNh$&1Hr(%) 71*VnCy9G̶ԧ>FtwUc Qq|ݻ2ȁ~ 11Y3 hOγf9%Nk=GqJX%HҼ  =a=G@{{!BŌRW])[.QEonS h:B!XC!yx0B֞\̏iO4f8qb|xH|&kSt]V1NAϚұMG6 ;M x%|^l^u۞~_{S>vmhL?|3TG}EE.]80 >ј?dGtzݳ2 |6O;%\1J@R ȥΈ~T5$ b"a3"N^i:ЀfI\bہ6ΤZ U{z1N;8qLln-4תU@, M T 7g1RG) /ZGR붦 Jm-@?]y'&_߼RΫ&>e:siiUdTfE#[XSƯܑ}#g\D-^IAi-IǛ9>pgPA_.knhlRr[#*ac0j*^Eu7NIu޷FW÷%Z)>Ԓ@Hmx5)]sw742^4?k k^R$!&SoGp6Ge~_谶uLY5˙,m;Zg$S, ,'dF9WЭnۺQ_>:PL=2qu=Vۛݾ?z̭3Nn~K_|b,?L` Uc=U[r;DAA7y\{v=E!]}{:rr^*la+gx|Ӏ+ LF8]88tj&p,E=Ņ9ݚ/7UQ^@NjI\S,]='{X/BkߕP#I'Lpw]'yVybi $8JGaX&;Nͳ1h*lP)]gXu=Ao mP~-km bܚ[SUL= RS }ndsۏ8`pԞ'1I}AJ{ej seƀOyZ0Z[ں Xz_yWතm`JỄV`.8_c/]Y?3=i7pkf'=*%&48vK[sf;h'֬ lr,4IO[sCa4#!q4tޓ" x5L/?/ɖPG7!h 6p"nϥ='۫satRb ?fi2j路=Q83ٯ+VK'{`5tS}13? Q8Vd}ȴ wg/s;Iì)+ F-^s_c_Gg/um_tmH+:̲-n첅톍G,x$'# q?o2J47RX1X}sK^NnZ5 d_/!Jrc(tb12JZ?{՚{w>B]jƉud$튼/us!v`VMTlÃ]K33=PRNS/a_82:BnVTf{`¼>kHM \=-5,g)HՀ<'jfLRJb 0^BQpAMGgf.0^C =~8|>6,׸/Z==TMT%۽}sc_#*V;41ևTO2I$3kKhvu{ dNj{)Vr@78vsnQFp'q J4IEX$<q3 AW1ne̲$h3fB|~B՜s,Onl^"&CA+\f:8tْ3].nq)rC*5M*Ƒ82 wbQQohb$"CKj`{B=/ɦ/ ̏vqs:́}P2/lN[(pO?N8ӧN ϺLUmexs"N/)ē%F^&1T%s \첚@s0זYїV$O1 a aw,tw.FDTPne[[#؊ISoh)R+WeCL%ްpxK[yE Lr2v.p}XV#q#G#{X.2G(jmTf HFh&A %gp }fR8t0Yfi. =qbCI*cEwWkN8ew[KSC/eeUZ{='7y~w<#db̠ )CAm%c;i3EdM0f2ZZZf̘A2{Kf,v4Kf Nsa~F. uԂ˼<qщ~Ј#B5VUUqIv.ttt@(xTa9S_.kjjH57@0aWpm1gx`<%bγ'ޝGj Qճ=p##ܙPG뉷< ¬Ӯ =Rv;ºαwۋ[mCݨ b?M4JuDڡKxya{6R!PP2O_"FYNtRYpI.C!>u9N唁ZfjT*p++.9uj*Ҟ[cjv3@{M|W/01I@ث=7i5MV+IqUrdx^Vaɠ=>71EJ p"Wb,G(9Ktzvt ;[3n "epx 5R'/IEE|01:  o""U  Kґb*IJaNWyeZԠ#P ju-$BH >fү3K.Dꌜ$;ùao0NbDV ema4"gn jUg0F;N4ka+pګi/;?W'0(HiCFWLzJ!r1ja$>u8+ i@Ơ/XT9j ^u'Ƃj׹xk{[&gK^vaW]-1SE*H7"H+:,K谾D?:m7bʢ h[Y"l+:l՝: XYkK' l-C:Ibe[OaEE%%eN'Mg%}h 40!c `o8e0Y`2hcS0D6Bn8:iOzk6ҕ)3D Ic^1[,=F<]&= h#$R3-ڼS Z>T8hXB?+/:CJ>_Ri0 uk%j.gNd֊͙v`.1.JT}I*ѯub1:ni@HT}&^g΢!8 a9sXFbC$qE8oF'c HnR%>'s4h->Β :%;c*%w2;-)KGCб2D| }-I2 hrցC}t@+k4ljaT's%f|i/XbRs*JDDL&.S"j a:¨KfىlDP"Vr֩ s̱`AX Y(,qfZumstH4D˲Τ" Dp#Hgf#kUO aKI@MD]V)C@c|x4˱; Sp_,z'x7~TfL΄t&*36 xA@HQehdbaѹ6/d@tb8f*œ0?8P4AJ\t.IիE""n蹭654H+\z3Yj䵉 W Č}(0B^JrѢEC(ZItxPV"F!()e_SI8[<$5WYd;c;{6x`/..s%wn>:Es.l'a^Ro3fѡ}êȞ yΛ]xdH)9## NxEճMon;fk.X9K;'!M6֠u(w 3 d3ۨƠá$Fwqd<]7zP2s0YbdWJbcL锨T3Yc,$%VDϳFf$d,Cd!",1ő %6F_Z Pq-ZXc4 ~`~ ҷqSu?-_u[KΛW^a,[hj=ShέIJkݽ3Y&%͞*X |gysfn-Na~g< ;eT~pQ O'Lk٤)ǯQmy5E%L/ÇXO@dG>V1̈́,e;CM$ N% %_F+<ZآҦg3LE%rPAچ "PEAEX3{ j˭G:!U_Z\~8b47PR@C7:{Bc-*53ju/ 9xW,:];O7GFvwjʘ[Æ WFϭշJTăE,bpYV֯)ZlgWҥqgj$ǫ3`c#~p h:˕ d۲ 5Wif34(R)iLm@f$#e7Bqt6m$ܣi&L^02 (qFB8(#՚ #$[@ P5h%cbz5e^?$lH=}CUD_}s.2ĘK־c[Ovm=s⮇W_p qjyjM@㠬=~as[suAmuGa`iͣ 3|N iVǡ#1^:TpGf'Ť(N!jgH1eH2ҦvtؕD%p%0FQ2vYhC4fMi040!eizV:MO+{*Ϲ~_ //C|t )21H~7c7sW,m?诸~r`={E}jxK>A@C{8Ɨ-Ҕ;li1~Fؕ" )Ҿ8A(z 1I#h>Z德E+̀vn ;|fƮ=i'yM/O""ݧ|tosc=G `{?}{H!?eK vGO_>'WD`P+AnzquɬwUNT-H|љxXg۳s;kem]tX3{nï44mz0\/{޲5_̓q _o0s8t%Wk 3\SXR_psty.҂m&bP- Z )^)ч]301Qz1[cLh1si2Ţ3=%I vH*G6mm&%w]#+4zƚs4l9tJ=[\l/uF޽t߬%5 =Zz[-:@" jo9m̖85,?щYy`C3Ѩ׌\/R ;Sn=Q 'dR١őz09V= Oׅ^'SCg=R.v5NjnwF4Te*k i8kLQ$q4o- Ayu_~M/JO~$Tosbvhk3͹tZCy '>t&cw>oAnHW[ʜ]_.=3teTjޢʙfc-g<|HE\ @Jh_䈗!R%p)uz v nnPt^vߕ>0-+]VvzyP䁽$JЎm>{kn5W~xƴ9JۚշUdN3*W|A>/ix;zܮS͇[Y?>#KO㚹k̟o :rF4 p^uεENa\Szp n*@ }~]7"IA@H7dYO 7[_^\Nktޕk]ٟƁq1k{x}}Q{ F̋39CG_ސ2Z'82wb{[XPq*Sک=*Ff^rKZ^.2p[㞖\aAQ2 0SG]8deme.[P'mQVS/t\v/ ذO「(q8yWybwY^7{zb5l`We=uNmִi? D;^c 3._pEoXT/Ѱ~gCNӏWaA@Hrdw, "xGFsbY3SΓ4z` gw~vk.a`2Bz jHb㏇A96#G!4lnힵqٝVaE ;ڻÃsF>Iui p to= @GK5:G`LZƁgcL:M)));2C9J dT`5Ϛ+9ln$2Tm|,VQ<'Kk{=s$ǫp#ذ`=͎F$U0WuЧ͓* xhkk;um4WfxgYQ>Fz"J8 $9T㹦d`ghA!nmNtP+iw,*r$r #[4,z]j@#kjmFyA`dZZZҚLeFI@8[5=ˠT;ƒ 00 Y'^ w\h GIw6 @OԮu,{AuAqU4 1^r99a>a(m7zx{^0AG֨O FyA`jMER4z& pcfnkmE$gMC > <$G&Lr} u7 YH<CCmM[vfzs˲<FD*i6so1/{zzz;aLR5!2:NMqFL( 4yx@%VFD`L3bΌLޛ[A`:FϸopDZ:MY-v GID3HY^AgvA- ڏwmWďpvםkӝvy.7+z9"Hwo#UKf+3hQN8@}=@w?l9`?EዞEU/ҨI8EU%AGיYUN*5IA߇)j5)U @,ǹQLicÐ6!|1ABՉsPJsD {"]=:! Oj9talK7w^Vi2E`n&2:}T4ќcERuS27H~Y,zy7^j," }"6P^@<^AA4gT-,.ɯ@C3H&H3$tL#Hi4c,=ؾ}m`UM],/W&9U T7#B-z-ʈf3UBz#]NGU^*L Y-!:O%;;{b?j P+ + =,<#(0(qE w. irk mvQ:cruȈSxqK T41ڻ~6 EcYI~VG.ͦS(/ANj՚fžhYbڪ TPdRz`a(A`tZ[[^yK,Q_q.:3KC,ep|Q8S#9LZᎣea"~tS;VFf&ugьI4D$y3lgJ.7lۖPܬvZG}|j[9?U4+e̳I>wD DfYj$0~q#.|>g^G6XHAp&/?_ġYţ ǘlnj.)*#hĄ;%+wMV%]6@qiT{N/1gVŦ̞UQ;녗bcNm/#]/WTG ]Jtz_ ~O(0= 7bG`LL4 TEj=+VY<*|G{2fYywR7ؚG˖iPC3x37# ]>VĪ:xG5łMxŘpw[f_\j);8&n" @IQfPGMsG~sssi_YޔmiX3^_SboC7 e~a;RD^z"ݑ=sz^[GP1Vb#//T;MA@HSp (3w~5tg).hVݯڳ!}8G+ & z;_| G\U BW ]3/yyז49M&Hx3\aG7\4 IDAT;?P=?T񠘻 3IS\\,Y rla>e X:(0Ý(p1nkea Qwp|='c1teL2X‡^y}X 4˯_k.Y2ovv9 l&TQ ]`=ul 9J̙;Y;v)Ë-`D̝;i<}ytX#-2ELW18֜g"/v-q t9xg{zzp4<CK% 䥗^7)_v%\?~Kβ3 =99nl#"m$tUs8~L%g#`ͳS2 3fYJE/Ř1ڭYF ;dKkS {cm} 3#F_|ߗЇ*I"FQQQVV4 ~ eWHjDR4u@8k:ZQ~0Ոcw 83?ۺz71i!M7l/} |mwd 04g7pCUUQe0 掚>@rXqLʢH& W~~> 9' c&Xcwf}mdG*J_9Mׯ_O~W`qGTS<\j_CW7''a9{"?+IA@LfΜSDfMSB9|@A+͛ov8đE8^K/?0H| ѳGPP"YGF=hA/X.Wҍ3%aqVa67E>l^yla8)K/k=V?%Cf_~oDp-|Sw eS!zHUě`T[|L@ 9;CGH\-^wtEt(WQ!#K JT.YNEK*>SAxMdOF"ikkˑTY"ىG Q.1Z3„2QE`P*b'ѩ:;g+UTH.9aE*Tmh*1JQemsaEӧOP;K<6*VG3P`X$+cEJFB@{F12M7O:8Yxϵ5RJ Db |Dہi_k 0E4+hذ>|, #Gs9L'NIC&ٳgϙ3G2@PC,|j %&j!CP.1G|Pe˖ajy~gΘAX+U&\ρǷ4TD( c-a*ZW_8b 3![[ΏKQQ! ;*WDvVooOEy9zYR\JfP(.ZQ:(9Ǐp1&{OqW_}?y85ɗ!Ch8d?At1lp xqY+}ay 2&jIB\-DV&QtUeG(*cc.PR>GFL`jVXF9 Ch:YW0ݦ/Qz#>'1#Ą;D.cB7GF\s5 j!W\q}ihGI  PKsNW QɒA?;''77ץ浰t ;vG(|Zt0>zD` e7eX`G{{VNF.B̓K;:h!60kDNtP$ {h\{}>NjkM(6S ̹F@of7ܣinrϱk4c?%0Ģ\š-1hgTrE.iʰk VG:1 ƺZXۖp+ilnhlj?AWg۱G+:~rjGxdjgpէOAAfuw5`;\NrWVU1g1ѷpcǏege:qiӦ7{Y]]y Rk wv߷fF Ғ "`â\5;4FyqB={IQi$UG$j5qܷo :/[?+])@j#`e}ݸT@{U?t$DZ*Px$p7$KYQAPzm8^U qPZ\܎(. LvG>&Dvˣ>4{U@ڔKkupЧJ尹sgM+Gy!0hވZ,~ơ\wg V4qd 0Yol^x??YzrX9A@4nZ|tG"0=N8<,-˗߀5r@tTKj  +35qd##=z!8Jcf>RkA@ D@c#;Js|~dV##!q`iA@A 5lY#+8}۵kŲ?̾XVWdzu7A@A`8 i-đ=c ۷o?I qLڻ&  pI7kRlQ͎dΜ9\^^tUA@" qȥu>Mۯ^{Κ56JcZy  0(!_+3fđxrVKM!ׯ'See#<2}t☛+-a)R @z" 1=8jcoo- Ǚ3gBit8T%  fwL:hn{-,CW5Sdt#[J8l @! 1nxG?3Ϡ=c ,cuU{<8^%  >wL{cM`)>}cO?4J語7oU-1FlELA@H{;->SAhb8nhhA_O|⩧BYc8NB  Џp~$2/1 >쳧OfhΝ;a<ŋ-(c3๐*  q 1RZT7:7lؠ+r{?a6?Ld4qt:xJw1^A@H,gRk{Ɨ_~+Yew{K6ַuyA9X1Bvq T B)@vP(t#GPehe-^Z|9BIϵ)CR  Hc*ܥDب͛2 .2Z-O"  @" ixSVIvdK/Su0<Ӯ7nܸk׮UVqB(1  )O^g֭Vw'?!Ї>$-$  8և>v옮!!uW\A<,n $HA@ " qFvgi&\%S%r.lLHRei +  pG X|.֬WA91L^b :22=: y}kFMjoJ>L*pA IHi?#N&I3C2z~D/5 '<=]w_5g/=ߛt\7v{ OVOYT+ʙ*UCqLxz]P)s%Jlx18ܼR`6~n]*;/Ww ~w^dXH85{[q aw*htUn!+6U|QٔOf&ž7O8 Hώ΅>jaY5qvLRDywTb0]W/=wz!U?[.c>Dغ_=: -.lpGK>hܐ0f(<^ߝb(F>_ȥTeA@!6N& gƑ@KW~M)w`N;!b;Q|8bP>7Č)`TMu8MdF{$I3&li>q=A@85pJcb &1nTQA@! 1A@A@A@2p  $ 2,]zi 2& )sPA 5'-3&U|t Y^ƿ毸g:Zn'Fk\Q'F.ĉ@Nfڻϫ6?'">;Tbݏckӯ\t#dQT=fNatOt c8{h͜"KNl5=""z@jm9͚ [!\Oh5歼\^&E5/>g÷M~HA aɬ^}ı7ɫZ?t;#G@re˔xj]{u+??{j13|dm"G}֕^jn CY7֘~_egY]|r?,0O?nݓwG`oݏnڦ2n۴A%m:lTNPي2v^Evݖ>پ*/}'{bC/?mͻեyg_zZ- d&v2w6]S濺+&o[]kK-31Zmg8)%!ܾVwK7_~-e-Ys~?hg6a6OH]OkYjΆ7)?Max g.=%+v}k~X[/CeknIpNm_Fb$+QNnN,o%iıcSߺ?xA!wWhzs;N!j^5Ni%;:A ='09+Q 9e^Q5T pe*J2G`7?R~޹ט3o߹0oޥu5OVߗ~oyNwڻnܲ+=sC'' q2٦vyN#4ƃXZpDy6tՖ3#'tMgYFۼ.0㍟iHظ%ˍ@YJ頣M7&.Q2O!jwwrx^]CG3]z@'${.m;sDT&=zM#?0ј9h8>(feRa}E[2i R-)0׷ Ք.1k/4 9~b0&6Vtx-+cU3F)Iqю5ey=w-: @W$ L;\,:byxr@g g}֠NPAwWYW?Xwf×w?Gr|¨>Nʜ<x$3joϬT<qu￸Ӝ68g^=/v3=ޅik)$ ?ϑ.?&74uj=u7]hݱUY_lϯX-3w1֟H&Y;#EFH&7^w'g*ݲqVC<;N-+**S΢a_/~w<ڻ: ma|<[V lL1S9-+Ikwas-KBK7h( GSl޸a%JIr2̽_wn57`E-R@@Q9RGz#w{zu6FE_Y{4w{B'Pl IDATݳbOVuQr輟,5ꬬ_f}Kt}š5rkp#tVU?Чtlq\2&﹨o_xyA@H?&(ݳEmsAQ! 1nFl\7X q*Qђ{Њː@'bdսnV1i嗀 d<d;Ylz  ^JMA@A@lҶϚal Dk#9cD$C^ s3U+ߩz4iZ5@ (l۝N?‹ۋFLT^gO]G#?xB!YrK܀䎼s _nʱKl;naR(̞=[e\>ZBA =#/~`Ko499%Ux"b0!_z wZW9܏]yE3Tw8c}' W^S1Tx#J NI&'Eul&H}pH8tw>-N:IU{D=1];Avad9]EmG-**/[P9͊Dx|qqB67nj S?ϩ[=/h"\vr`ܕ97MABFrltAcC}3|k_khhH;Tyt a/eee_җ%fH/D#0AFB/۷zm!6 [VBhU0G4[ "[7:w}3w#DOVʙCy1}`0hNxQDgD/ q\YYY999(OxhxSM >fgg.y8$mA>Wt4vݜK;a]0,'h9_}֭=㣕wPHE :܎_u}CO01{.] %[wLE]o֎; >sIK-Zdl >!x0sB<`BL qW-ZL‚lk཰&C*Xxrsft>ӺV z\Ƒ(PdLLs >30]thw}EM/st=9>32;!nHWYa>9#%QO;%qh34盜@91#t_|^:~xtjkk?]奀FKNyXǓCh4N9,b@"K{r&hL/>Or-xinwX$o>ǒKd@82 w^O<0;3!(1W"鮻"LQ5kj燐ʮI$?чE"y睍7#)U dP"zdDoluiJ{p0( M7ywEw`n]̯FGxR\`׮]Ee˖=4:aMOݛ wL:Lt ZL;޽og:k,DGioݗ 7CAZ$Hd`eC"Yц qQ} 9tbW՛o2(%nb)18 RBnzя~cQ뮻=BpDH$ˆDjəM"O8?,m$3o6&ְҸ!xdA +sf}1UFGX I^ 1/Q[M9x(6oG>rA /y&dtµ}2DٴD2jƛLͦ 69{" noş'MwyY22 ),f; UZ?hON8f^~e#>?O;%[@9VlI*4 Dnڴe;-zjfp X^l}d$ I~%8fk<34iثT8B܂(s cA_ # ~Ks%.$b!xn7al&c۶m0$j $0>vA I] >%G3D7ܱo،'IGU@0`; jq"(+f H!%IU;x+אDDJDDJ0i8 `"2dhB׊TMo/A8Ӫ`Zw0nJJJ6S10&K̦$]6ԘJP#s# Ο8 Y5g0]>|cƯP  A#-^xPɺu`ZpwBA5rф?,d`h pSNmp}"+"2HI #hgH"`ܽ'bI@0"o^)(|rA5` KwC&-POGI @SD |C=D8ќ +dZ!e$ 3KĐa-`1$h Q~_~'@<(N u tU z*hA Nw޽{z-O~Bdk,Js~ *wiNk.kmm象z.\^k8-w6abF\I$q$ we$0~q…09DJ !@>ĵwڷ~owEx`ޑ~M>Pf}:Hf>B[3p'66GQ|?II,S;>?DCC :Q40sh!xI ^!7o ਧW^y6c#n_Aj:|`+ 0s ;lnpl1HvéF2@`Y# #H.^}텅xq„ 5{J ٰ#y'a+;%S;zOl./Ϻ"%d=|s'A~%D ٫$7H`S>s! URHhB`B>"#(#ЀzɌUr@5/Ew@g8voV"8"}W5wrs1$HR|SAPXk!"jrj6Lp0:B렎111lM)m!LAv3 ч :Jb{: 4RXAO $Sp ?iifH#H, $HU! !&觟~ Hqq?ϖ/_uĞy |)^B(8h؀0';}w p݈暄{ .;c@D!a="&$a"{u>u8HXC$dp8lmŊ<IpIy;C_v_0/Z d|F @ꬽ׀U!L$6pSFp )Cx>>6?K^5JUC6߂#‚œ TVVb sՏ>_R~!tLo[!b D؄#r8IǚA־}.] . ñZ$C#!e.B+~B6 M7+I$XF`>B$#e"%؃>|8KO7dDw'=áKƎ`LwCX,Db ]6"hXL@f H†L-BdOȱ^زeկ֮] g2SH#Ou8i2 8Flv? ނ"!l&Zl5773/ȭJ!c7ӜfC I 9h Rl_43w::BWP`IT920FG0,uۉU \! +Jjq͆lDw=.0J==u/@|`󃵍p|:7"q;dB"{w?ADo>òݙH& N> Χ\ϟʃ>:lfH~,u 7ހK=:u|{= p!q5ॗ_~y͚5D9P8Db!I$/Hei#x H">~j6ۋ/fٲeAAA}L8]R9l|X!̘1^#y<0#]AX{>nL$)OD7|&$H k6G0p͖| ()f }򗿠tѝ@ I+?;O{E!(dv,7|~CHuB<ܙHvc"GbaC[(DBM^$ AE6\q8xG>{BKR`c DzLm7:!-ás8U7ֆM5J $E$bH\q0𿆕׈7A5qYxb +I`"Q ?k׮73"h; IϪqsBi "\Isz6خ$W袢"r͛GyDZ7:Y*g ~!$ p 8{Μ9p2  %ɠ̈́  t_?BwĶbM@D]CVi?5G *wy^  g?@Ow (`dIHK Ilb= i5C,EiXA|{˔ C3 zh∍OdhmA:f+*kD 1%K#ى1XxHIHM$XLǎ5wuJ%=|hƫjt6f9..ntĹJCNWO+*ګSӑQA3i${g1--b15>LZ]6`5y =wܑduu5}ٷ~._ $iXY !] V+jTj*[,Z`KH+5P㨁z,4D0HV(ĉ:HIXiDb! Đ =B-qQِD¸}( eC9sL-u%4O!`b)b3w܋/BGMSnɋd Pggff)0w*&=8*i(g '-zy IDAT愶yPa:j$=,p%< }@Lf"v<,8!Fg|ܟ2e @s=*"w1"pRq4R%PL7bI

qŶ[bBRt"M׵؎]J]QŠdZ!B/3z%C*w=ZLo VԙɑYN Ѡ3!-V4X/i8}b٠EYZȃEi[閇$.ؙ6Զ[pbFR،Fb`ZխNsxE\" HHH" #GyEر-]L$$ }H%g䱿2[B9`汃l = I-m.|uJ&@zYJW4JP!4[ *3dLiRXb=q #՚l%6\lѰLL<\#DX` |j_͑#LUVjrwLO1!$#X)(@1.3[[pfG3F^bq`@$h(F# bZ `k''XkUͶ&>Xea wUp\hC-H" hmš*K '3 KAvģ"6-V~fbgN0uJ0 ÊB Ō 读1(C y$KM &nT$X (m0[**[kL6ͩe іhA` e<L'\rPH >A71BgԹ0G_8qSp+.YRlrȷIsWlK^dMmZtef~usUI1' !n Noe&Evٙ|1s'E@%2S7П~;D^7Llyө҆seM-vH"0EM_#v6M67YيC`&fL%;A:xھˣ̌HYrP|1R)ocN knl>Bv]8|sR?ƺ$j[vߍOk^"͸Cjp]6$`"%HMx\pu;H>ru/6t'ZKVcԌQC-G?c`hGM6&ʵ: F-pӓBS .:j;vU+gF0),1;駉=yNJ6y<~ dqSJdy6 T+zNʘ.R~)*9ID f #I$L$#bHkƁ"5a I1d];zTEs$Qz> C}\nb.':5ܚ*j-L`Ѣ;Ww x"9iNZVE!0$PqH ǃ!i^kjDw BFQ)WW!,n3jq2'sW|JxgI_>N8JMB$eliR_.k>-}c_}qH%L$8Hg2@0{:!kvLLHtϽKHASPz{8ˍzḙ11i-wX-h:kv,<BHn⩡vÞ ރQY" ȴڜ0˫iX;,rZv0F&YDgƀiJiAA4U`uL:)P[^>wevlzlrE)@gj+MܒJosQE,囜Q[K?F f0oHE"X4L*6 *-" aelA>;v H@ʂ*-!锑MxZU0GK7̊͌bգ'Gڄ=g ѢSi3w[y3p ~Woo:1)Ҽ .-@!)PSz$[*1E)ԛkZ0 UCՈJhen R.TYB@P 6D8+tl93xnRTp2_e679[VѶdh2g]+*\g  W!$BG$H"%H"Sdmf#/0eee=#pF,a/6 !),i)E*sI] F3CJɨY^i xD8>?إXZ`Z2ifWć铣>&:K귎cN $Q}==>j67H{mL5wVYrxzޤwDRP?Uxj}QeKU=!X@5p])Wlاc4pgQȸe p獯Zv?,%?8wq  qubSp`ܙHGDxH08?n5?)ِGuZI`hxh.oE1zY1ba䁡ڄ6”:b\-ͱ,ECs]ۍqS#E:"q |5d; mPy5$"c QTU>^/O {&6`A@˹ (BцIA1!J6|L wl"tA'8ƽñ$IŐ'ayJªh=;1w M)"_i棴"BGkx?|:x FGFMÑ2"K3aB8j㨁z H h>p|eP65;, }zC7)(/:dvԵ*[8 KJO 19,Ҍ@x$WH$RCT%VTTlr.})p\D\=LU"PUzcaFVXp|CFo7se w N ne@IsԘiQpt)43DI "%Hdpf_xL$R7obHĉH Dzb%.R̑KxP#|%yYzb)nۯ6t?"K*O3Ã7oE7[dQzG>wQ8WO iF(WNQmdHhp0xIɓ'A5qSjZ]ojȕga4Bw|h υzt?#izb(V]<@><(8xXy$Lٶb9AN7^XlR*.12 &s×3-1&u'H>"A]6)2}qSZ;_NyIVjPZhD1%h^L c5^Zu-FL Pq4<`D8qDže7G}^ +%$ѓpa*1Y#Y$$'nB0̘8U884OAb=E7gRتA긭򎾟zP^/Nv?/UwVG'M:%R7z1<>ՎS(xJ뻯ӫi\qLDGݙH!ڮ[0%*Ӈx׻lQO_4cޱL^В>c81 'O}]5 S1Pg' Ʊr+_?wZ=gCk 7)_y"{V'Wk7O8券n4xv~=9\UѸCwK' |$A^֜s(zx=fn֞ÛRz;I^^ ;4+B4CeZZ@r*R;Qd奟N \1cs=yggٳ/ e̖-^>i[lOba"Fmxhvs*[_~dQimSSSh3=teړoͩ</Zm:푵`Xr>?YXT[BLl^r_\RG{2y?VޒΦwך%kgx 3gdf0[߽(^w58 %0ws9]>xS?eY=TjL%?R%>2ibR$zi1i7߿(SEM ?#ά{ґάYzhO9HGK13vXtߣ. f5QVGxj͊ j賙S+47cGu&026濜-tҙ#/|2)eہ7E=,rܞxlu ÔWD|gzyoîC+ =^7@?؟_~]dHtnO!0=~(?_Vx0Hm|6^yy,c95dW>uÇa+~K+>wNsD=\]dAgsp'~걭=,GwLJ7^~3-<HZK|w-wAj5$ )dnؼcZO[>+( ;m]׮޼mǶm[e~*d:>cu/[ٌm}bMOZr\ Pm%;Tᲂ~vKd1' {@N5kFZ2j,gbVn\1yxzId޺3+7E{# .tצlsScE #U_ F}7/9gG7\>O"F4-L;/dflik~c]b~"] ;*Y8R<3=:O;sP)@j8V4-k\Rl͙Q+Q1za#e'['0GbW|Zu3&D6,'$OI m*YrOw1|:v?iJfD(J>%?5h8W|RuKyU-g,B+(WeN(=,` {EZ:{nnV+;p=wf3Le >`@?-uyt֘=7c0L3=5wV{mpRy  `w8FŚjk[C8+TIBy\-5F+ bDB՛w p϶ D7n]k+ a3Vڴ&eh+]yxFONI#jpb4a-o^)m$(H ʞMV*^qƃYL$yobqI3kCB{}p%{:#'#2V㳈;7ku;v;zrw5XJ!2UT$@ W|4EkWr/OAM?> ZI2 g hw諉|}~za1.'-<ϿKo2]dmpGm_zH{sC{^P֐;8~{jTeV~_rn>rJ#E^1 EU{_]f NG]QΣKs*kþ߬ĥ#܆3S22 Ka-knqv:!C192sR2R-$]?ZΓu3T9f"u¶O/)3'$P%>zofEyZ6a=$vƆ[; ROR!'t(NwC֕OmbӔGu+wTͣ܃1tW9?[t&)]E#t\9;Wsv.@?0}}9՟MS̈dLW )I\nöoZ~!}ޭS\% 㘵\q{uz mnRuz㊭{gud "ovMkNٝd8~nN طwmXdg6t}谖ngS2?u$3tQv*2RT"mzI{h*+ H?dQ-Yu&tWPqhI@oH]jQMPu{,ud,6ŬEM,{ #e@x+(|8bT]Yavw//6N:TQkp=_꺝11˷ݽ?u8lo#owCGVHRo(K]Ca1Ac1-HO)(85R@J F&hA`n,ٚ{gƁ@Ro/D] ˿rǼǖeFt\@溻 \-!dcCK[DX".Cp ք K>>@NjK.Ff%!x K㉜v .v1#{e)5RGh }LQ.kBJT?|| nY}>kD+ͩ1bF$t)4tx~ ьctǰnE<iB \×7LBnD?+͎ԈCߤ CtB̀LT#"w fO{8nj:wq3p("rN!P;? YsRTY1,gaVD_FFUT?PI"V{ZZ AƄEqQk60'i93:̺k?m 6>FO1gDBtG%Lմ1 ӏX44*8aQ MjHS4EaRb<|7h핓PlA*ѫZH N:Qb@Be0{YDQm*` ;hWB"B"Wѫc;W!* 6D+`kldG!}`1Lffx秥2hl3G9CMql|0ku CW5f"DRg(u=EM#\!!@f_Ӧ;?+!:uL:~`w@ fN" xb`-Db /;6!T*:&w. @윂eXBmxY(`ݦ%GX*z,.X~]${C4mZR)k*Jx1/VOV%4>!L$8HcWYJZe)Fk>q"Tay5ziNȽL3 EͤՎ PqDI HJ2*Z_&+G!X҈FE_>rY^d"ɫZ8vۊlsjsfh-p 2>FiQ;26%71 :!BK"L+ΦGMVG[1QN` l᪨̈& _8:l6k,)c`6/U+XVB*BJaɆ$9A e4ڏw{ƨ'.2Ň^ߛ_11F҈O޽; SPGdG](&#\r\jgMV☇.%Fj#4b7EZ'BBbf҉ۄ#\#A *dQ:8yn4XVVЉfF+ Kt}ok|sZ4eb1 fO+)6G.5u\~ap.=Ts7U~V:n C[m0PKGBxWEyǑN>/K CW%ʧD9\@GIC@V`dV'oA|Q@IaHó\9䕜:_-t;tLu7ZO8券n4چPG*T ?xVe=MS8rc;gaU#NWV@Gpg_mua,Y=*.,;TT[vg1)2ѓ#b,[z%}Jb*Nnhy ]@ KP!Ў\ )1_LSAN`#Ww8oMK$(!QuoUFm@#>bRTTg- Z'@D A-9A 2j 㷗/T4?8Rf_>2yN:n=c !rx\oխp>7uQdsR0 h)lLV[>>SP8:G$1#=C("pvn,{hSƽD3-|WTӤ9PT[=٠eE iHAH6cMUDb_3,sey[?yYڴU}?>&&4tFzf}JA\7TNz^6l6u#NWW_W>>CX_qo1k ./󏜪h/~ʔ[2߹(]hݞy9ηy)4>7_s0ڽv޶y1~ޚdpiXA\kKĊ01Am]eZe+qWbH$`nzBrW<أj ^iS0[]{V!dwPkSOs #@xVTρ̬AX*!5f/8UCϡa0e(ɕ?XOxsC+|Mkm˒=_\\Pu+V̊tڪt<,س)e-[n]v)P{\N1Lݳ%͔kpk<ŏXQ)..۳%cݾMpa+_aSn$s7.]U$#q ht3o76BEV"ֹFgZ Q~PRlq#Դ8|r{BͺkӛݔoH"{m4Bn)Ƈ>Gۛ'_k"\nBҞwDZᶅՊr'H6Di&@$O 9`SJ: WzEd??uJ|q\uCڜ*WKlcuyێm۶n۱yZĬl\cUUsl^iKG\7SDId㛿lgm޳o+/Nng7dg 5ÕZh;uߟgNW%\UŸ-w|T圲|M9WjdM4/ o1ܞh7GEEEGGGFF=5eGg !wб[eFyrw9+!W/#c^5&N/,ki?$ AarCKN;o쪣d aZG7dY'a"!a$qGOnu\Ò~J)m\6&}?goʃ/oL~Xu;#!K~ױ`&tߒSKڙd>S 4Ln\7ϖ{ԞqՅZ/JhgБ|Bܸ{Sv 2Ley%tÌ_^ebюÝe'i 0 8Hx\|);J^3* iS*E^DB I7(jP@$ q5x?Rη9}30v'äbsv3@ {zMRA1ck~z&w\c {nOR+VNr0 O0p])㓇A rG3W IF|60;zlA-@*&*.4:I_U=[ 6yծsw_!~wEo]wRO[L$Y8}"N\(!_]Ty *:I܈4ҝ'z Qyg]BG3&2kjW.teRm8Hk᥿36FCӒƇ3a4hM  lXX(1xp"F W;w@*1=փo!@#k]\_u’5]m3b`"&wӚ5ͦ3V~FiqDc 9c431 ‡"@LL pJ"k$8_;R@ZHasu?/)9o}̽TvnwDL,~rYZ}8502;R.1o%7ESg1ys}Svּ+'`ۛ˼%k7pW1d3& 8qH-H9/!3@r_H1sru |ϧ yGrG_`f73! Af&w9+?VO"nq,/wnfD%v5+;X,̝sS7l&?c{t;+;眨}scƺ;+\k1sw/;BA<+L򅔨2U@,<[t)\b 0Ssc{ O<1c`gre²慏7.|;p̓[P@K>INO\ U""w`!0$z;¶ŧO:T\ؖW7X[0R ܑݜW˷8Qb\Fh83$ߓ6P 1ZS_;!H^`\a'rGO^yfg6/Eڥ@DL;斾4sy.=g!GY3W=2 A -dIzM[j|P fETKfoi+pu?s"S a;5:,uap]O/\s7xd̴uP! b2-a"SW:;cAԮ=zDn Eʚ;Aq?mvy3+tRǝ 1H3b]~ Lz#t'k ~0YpnqY-:8UkW:ys8 FL;"='6-G; -B 8Atp#rG@XT;zlRzƈРms.[ݒMXcu,+a2esGJ gh3՞9r%7ĵ%Xj:xJfg$ĘHvVΟak6*E%ۿڥ3KY\{. K~E\W*_rܑ5v<@Na bufP f sIB n=\XgT22Ek}]z[&W{7ly3~=b'yIl7#]%P/0h&{5~>c cRXc`%;w@ ykulONqR”D@)B&х;zA>bwHFd&Zk ^hp朆ekΫ\V~&З9]qY,W%*PfvzRN߹HYqߎ"1#sR;jbcnK}T'ްAƼi6)D5 M{npK/g~v_IBYu&?o+b_F/6rm%1PT!tADڌ !I!y{c-odUw7S@Qk͍.TC艭](!ӫ&rOB_tVr\iGuFlW[@6@G,@@7f+YVQHMΦhfδ5+)z\a`!> ms<TQ# U& )m&ņdj^ʵ,BHbvq6'Ϥ IDAT"T!`V=5~܉`η'w?Vn1ǪAJfF%V'`"b):@k6QB@'@@5mfNaMv+/ Ru pF%'0lq LZeRkz!p62v7 B…DE4:|wZY* E Jqg%8 !`3 Fb6ieC @+D H#qOG(&n!<( w>0|CSaQޙ,)Lha@~?Us0-|#.h HH}ů o ;>||.|Ў$@HpmV^n\\P^4k2̯μy~SMYtdj|a= S Am Z;q6 GБjGfg @yGg-  @8HDl IԂ(@ #_uj tzxyP,jMUj^=+me.6r%Nۂ!kZ yX>P3GͫT$}&! \@78U'p l"/F9{Gcu-|YpWB>9o$;IbH$qdӪ;ZC/+ dH$&2wDap4fVdhph͜X [lN^:l s*-BM4"52BatkF+_oahuBu(p>D#E2"qF+tw`Pɐ2+%eIeog}z Pc!$78 * y 'ȃUÌcC_&Zdfp=VSx 8!6{Ҕj) ;b,ߍH=GF@UZ V5 0|Cz 'wv~c4;+6UpPxcZe&F gXjAMpp21zW2j D  F`dNcMkq2:,U$q $ِhJ؅`KH% !be4iԦ+6kTr pN"x=6Hp(Y {iX\ʚiB&AD-+lMJ5*sXB6 9Ա=:KQ/tC6ΫX&T-V8p5*X( 5' C[KL6(8l EP)]%"AG$3@ 6[]Wb6ؙiኩFY\fFZ]x}RGx 73BS vpo $+)`-AƂH@ Z@3XS\*J D y O @> 0 tː&V#,% Bzk6e"K5i܇_"BM-O&)`0a'{9Ab!9p$6! ʱ{dd,<ޑ! j cy  !+PA"fw"X}9l;Z@j"$Jf'[bQ]i[")I |qgϭ^C5TD%]c^=%!J"j H$r`RH\;wj""A$$5q} ;XWH&Yu}(adB(mTtV~RbA %{8 S,lWMWi|$0#s>;~}dJ'>;61BNl;Z XOQ^B&}B!<%j@!ũ)knˁ(JWuXRgµVAce&B8"v /K9EpfK#F@ܠZH4dH2lIFkH2WzP !fްH@'!E\kq* %*83:H[`'T WM ݖN й@f1A,Be!%0 x@F"?h_=$#qx$,rܺ(Fwm=$AĐw@$9v9Num2!*0Q v(F?Ё6'+ok2&dU:xAe %#BaW3*.Ibo%/3C&9 nDB*c8I@wts*ۙǮrGFvU@)DO0;C@,E,HAe$Wp8[umTMECDE7Lf\#JLе%Z()l(qxZR[HKsI!0 DS>Rz!qȝ[GP !D+W3#ֱgr X %*Y[**zMyU0DdM¹:>X'jڒ6ZF !$Hm6Ky)+&C~>Aw`+ IHB$:G'qE"?I%hAj")B+ho{۶8˲8m"b? H6R7~c_9qQ%E>!9(C3B^.y"R?8?lׯ?<|ηo?77C.̿L|}֟O8ZI *T́ݺphKxZΥ].VL=^ǀ[F4X_ć PjDĄD˟^\}/_M8MfqUlχ]kdbBs@6m*ϼqHRArFz!W[hǽ'C3TY*ӮFUk%=$I wﯿY)$bx$~|4}Wv~N_y򟧓''E=% QQ$!hn uWAY1[cBO@R[4H#Cv@Ȝ g˟8<[=;ΓQ{S>mx}ͽ'V2n|R5V45;P;~L}Q ĴFɍmڿ c&LkvS=kl9"or 'SuBrbrth7_wzw0|xXZ!SL>.;V 3O[sIrӫ4R>w.-/@zG$5ۍj2#rPC1& BA[8K WGurnEm~uq֪PRVaX{urr*7\>:Wy ! L;))s&&d0Z\ l&&] bǻ/]ߟ]!.fh!cL& 1 كqH{L*di5Ɠ5Vil~ˍP1afo@E?=_NvvbȰJ@XĄ< l<|Ã5b!n Y* Կ1cҗ'A||E jvx rqx35]K3N^ɸeJ9[nsjr@'*[dE@i6"v٘^4bPPA jT8 k@Ȟ   Y* lCjwXzwJgבCD"EYiqGe6NPaeqdۺw?0k p'!q@_UcEq4H;CH`m\?Ӯ˼* vy7逬D*vn5Qej;fxjM:_eU-y>{-6՝ug܆ !=Vjr ƹ.laBAHBmИNc'nF ?j 9Z{uX_?sZH#aq8dk?3[{1^EP;uQ?zɖqlOF@@d)I@ +0Ļ @@ڱGI @A@< @P;JG vt @ {#@P;: @zԎR @ @j^) @Ԏ @^c~ @jG @@ڱWJ? @s @W@+ @9@ +vҏ @@ @P;JG vt @ {#@P;: @zԎR @ @j^) @Ԏ @^c~ @jG @@ڱWJ? @s @W@+ @9@ +vҏ @@ @P;JG vt @ {#@P;: @zԎR @ @j^) @Ԏ @^c~ @jG @@ڱWJ? @s @W@+ @9@ +vҏ @@ @P;JG vt @ {#@7MUWIENDB`ovs-2.13.0/Documentation/howto/sflow.rst000066400000000000000000000143111362155554400202530ustar00rootroot00000000000000.. 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. ================================= Monitoring VM Traffic Using sFlow ================================= This document describes how to use Open vSwitch is to monitor traffic sent between two VMs on the same host using an sFlow collector. VLANs. .. image:: sflow.png :align: center Setup ----- This guide assumes the environment is configured as described below. Two Physical Networks ~~~~~~~~~~~~~~~~~~~~~ - Data Network Ethernet network for VM data traffic. For experimentation, this physical network is optional. You can instead connect all VMs to a bridge that is not connected to a physical interface. - Management Network This network must exist, as it is used to send sFlow data from the agent to the remote collector. Two Physical Hosts ~~~~~~~~~~~~~~~~~~ The environment assumes the use of two hosts: `host1` and `hostMon`. `host` is a hypervisor that run Open vSwitch and has two NICs: - eth0 is connected to the Data Network. No IP address can be assigned on eth0 because it is part of an OVS bridge. - eth1 is connected to the Management Network. eth1 has an IP address for management traffic, including sFlow. `hostMon` can be any computer that can run the sFlow collector. For this cookbook entry, we use `sFlowTrend `__, a free sFlow collector that is a simple cross-platform Java download. Other sFlow collectors should work equally well. `hostMon` has a single NIC, `eth0`, that is connected to the Management Network. `eth0` has an IP adress that can reach `eth1` on `host1`. Two Virtual Machines ~~~~~~~~~~~~~~~~~~~~ This guide uses two virtual machines - `vm1` and `vm2`- running on `host1`. .. note:: For Xen/XenServer, VM interfaces appears as Linux devices with names like ``vif1.0``. Other Linux systems may present these interfaces as ``vnet0``, ``vnet1``, etc. Configuration Steps ------------------- On `host1`, define the following configuration values in your shell environment:: COLLECTOR_IP=10.0.0.1 COLLECTOR_PORT=6343 AGENT_IP=eth1 HEADER_BYTES=128 SAMPLING_N=64 POLLING_SECS=10 Port 6343 (``COLLECTOR_PORT``) is the default port number for sFlowTrend. If you are using an sFlow collector other than sFlowTrend, set this value to the appropriate port for your particular collector. Set your own IP address for the collector in the place of 10.0.0.1 (``COLLECTOR_IP``). Setting the ``AGENT_IP`` value to eth1 indicates that the sFlow agent should send traffic from `eth1`'s IP address. The other values indicate settings regarding the frequency and type of packet sampling that sFlow should perform. Still on `host1`, run the following command to create an sFlow configuration and attach it to bridge br0:: $ ovs-vsctl -- --id=@sflow create sflow agent=${AGENT_IP} \ target="\"${COLLECTOR_IP}:${COLLECTOR_PORT}\"" header=${HEADER_BYTES} \ sampling=${SAMPLING_N} polling=${POLLING_SECS} \ -- set bridge br0 sflow=@sflow Make note of the UUID that is returned by this command; this value is necessary to remove the sFlow configuration. On `hostMon`, go to the `sFlowTrend `__ and click "Install" in the upper right-hand corner. If you have Java installed, this will download and start the sFlowTrend application. Once sFlowTrend is running, the light in the lower right-hand corner of the sFlowTrend application should blink green to indicate that the collector is receiving traffic. The sFlow configuration is now complete, and sFlowTrend on `hostMon` should be receiving sFlow data from OVS on `host1`. To configure sFlow on additional bridges, just replace ``br0`` in the above command with a different bridge name. To remove sFlow configuration from a bridge (in this case, ``br0``), run this command, where "sFlow UUID" is the UUID returned by the command used to set the sFlow configuration initially:: $ ovs-vsctl remove bridge br0 sflow To see all current sets of sFlow configuration parameters, run:: $ ovs-vsctl list sflow Troubleshooting --------------- If sFlow data isn't being collected and displayed by sFlowTrend, check the following items: - Make sure the VMs are sending/receiving network traffic over bridge br0, preferably to multiple other hosts and using a variety of protocols. - To confirm that the agent is sending traffic, check that running the following command shows that the agent on the physical server is sending traffic to the collector IP address (change the port below to match the port your collector is using):: $ tcpdump -ni eth1 udp port 6343 If no traffic is being sent, there is a problem with the configuration of OVS. If traffic is being sent but nothing is visible in the sFlowTrend user interface, this may indicate a configuration problem with the collector. Check to make sure the host running the collector (`hostMon`) does not have a firewall that would prevent UDP port 6343 from reaching the collector. Credit ------ This document is heavily based on content from Neil McKee at InMon: - `https://mail.openvswitch.org/pipermail/ovs-dev/2010-July/165245.html `__ - `https://blog.sflow.com/2010/01/open-vswitch.html `__ .. note:: The configuration syntax is out of date, but the high-level descriptions are correct. ovs-2.13.0/Documentation/howto/ssl.rst000066400000000000000000000327101362155554400177250ustar00rootroot00000000000000.. 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 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. 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. ovs-2.13.0/Documentation/howto/tunneling.png000066400000000000000000002150051362155554400211030ustar00rootroot00000000000000PNG  IHDR  0iCCPICCProfilexwTSϽ7PkhRH H.*1 J"6DTpDQ2(C"QDqpId߼y͛~kg}ֺLX Xňg` lpBF|،l *?Y"1P\8=W%Oɘ4M0J"Y2Vs,[|e92<se'9`2&ctI@o|N6(.sSdl-c(2-yH_/XZ.$&\SM07#1ؙYrfYym";8980m-m(]v^DW~ emi]P`/u}q|^R,g+\Kk)/C_|Rax8t1C^7nfzDp 柇u$/ED˦L L[B@ٹЖX!@~(* {d+} G͋љς}WL$cGD2QZ4 E@@A(q`1D `'u46ptc48.`R0) @Rt CXCP%CBH@Rf[(t CQhz#0 Zl`O828.p|O×X ?:0FBx$ !i@ڐH[EE1PL ⢖V6QP>U(j MFkt,:.FW8c1L&ӎ9ƌaX: rbl1 {{{;}#tp8_\8"Ey.,X%%Gщ1-9ҀKl.oo/O$&'=JvMޞxǥ{=Vs\x ‰N柜>ucKz=s/ol|ϝ?y ^d]ps~:;/;]7|WpQoH!ɻVsnYs}ҽ~4] =>=:`;cܱ'?e~!ańD#G&}'/?^xI֓?+\wx20;5\ӯ_etWf^Qs-mw3+?~O~ iTXtXML:com.adobe.xmp 5 2 1 :w pHYsgRQIDATx[TU_.d2 ,Chda].CCIA)$KЅ,nq!* =EEfVZgqiì3{{Gk,G[fY[t8)9ik2rЀtb%3u7[h>B],Yoo_1V7gd#tɖ-suy~ϯ,R }.Vw.r_?tb̭k,G\+;r}/~Q`Xo4/"3,wZwX/Z[ndmcyv|}{S٣' :0H-Ř{YY/S{X]+w[-YNQ|pGv FRX˶lV 0|,ˍAm~SEԾڜXc+o DAs;>lWU}E΋ٶ2r'{nxJa{չ ŝ=o(?b@M)_e y)'+zכ-ck]UW3Z=c(`cnM __p+uZվxŅ5'=fJ@c90e$'mCRU-|oy=c(`cUs UUu|zײ%UܔdЯ>'ݳpCq~^ ߑOQ{9ߡ+߿UVT ^ |U}-u~(]^.}{Ll_Zk;;_w{"x-AGFpb1ndh44 j2L~fAggؽ΅{|Lٝy۞>[\〞 ugQkl䜼|1[ _]}AJpO(Q/k-Z0}h?zn;m oS ؟\3KS^KmMd: 5"!)K jMCGjzA+:t}N   -z A A   -:9,:AZ0trX0t``i!a!҂CÂCՖ.?wߐo$w2%`tُU 1gC_1kHՐ\JUzij f?TP4~ڬxZRWҳEv ^f3ijХ3>wd?>Y=PU3tYS:n"0xtWLqJNɣ>Hva:\w+.M͗ 2^W&^GgN"ύ{[X ޜx= n$7f:Iv."cY9'zz҈;|9_0/FgYּ˗> n_ެu ut1lݓf?x1tm,Wo F_:m;>s-{y#/.7 }QUeЗ?}z:2baKb#5r ,k:/?^ϯrτ7!okuN0y?ow>[_=ݱ2 =SCyʇ D:$R#/Չ=M`ݤ䗒_?hmǮ޸o2t[^t?XI!C?b={ KR IZQK7?Jvܥ}5Gv[ }78?.?ǂyi?o|\?z4=몍C CqsC18ϛ2F#z|+ʑpulwŠos cѼ5-St*N+b浺6q/?7As3Q eIOP0I5V"C5nUCOt =&~ ͚.[)zCr>֦WǼCX1tg&g+zma=[wciu?I[4BzM7F t㗴2#g1%\:WS`ڼmCĩ&.c.ב2Е+7q[y-JmLG*[ceٳ9kZ/6Ri#rO/9@_!rO/9@wMqi%^r0rMq\S\zKҐr|00~=-@,Zظn7-IzQ|/3[Pa(6S4oNI.z*O$kՔF7A-ϸr~c Sy*'v`9g̡\C=-@mA" 5ۆE^]-Ɯ2].Ԯ='3UWߛQo75 IR>)Lam̯c_@W2u^Mђs YΧLEͳݏhlM`_}Uos[=b*'u-,p޸b2#%ˡ0\PR su݂;@O Cۦr%d16&yP\YF%$ˋWmBw>O|*Tw :m6U\+S/Ss@/_BȥKF.pȥKУ^gUI}ot쇦P#ty3 @~,zc<zm<\n Nx8BkMvDl."B݌]]f=[<=-"􅑋=߶xg6 }~EڏM$ FF &&t>#1q i*sScFُՖvF=gu~F9,c LGCLt3BVubY,-Hu܂@He܂8M9a^Pb,2&<-Pz__c\KEvΆw.)z(VWU<{eþkLr6)) n ^#o첂02IPR]k-B7zbzeo(Z<rt;su/ה _7ȔXE,KcW'xOO=P7FԌE|o}ݜ|w)6nkB_Ów024E|5m{Xd؝X&؁U2y8c>8u_ֳ\B^?4){BEOggb"l;JCcɱ 3;e_>y38ΔUWVl?uQ+L1t>&Rσ#N]q=qrZ[yЏD_CŽE9O%((3wc=l0m -b@7$WIn24\9>kՋ;ģ?&?.St'zw8K#v%3"kGu9mw#s;R0 o6w_6^o8,~ah:"a#؏VvA=}5daaw%=vEb.>hY;Enٞh?96MUm >!^\N薔{PC_n[I%pWSsslJ}8)۪| #x!=Xg iN8 P蟭.Cl8\p54Rl]Z)2Gv9tu3o_0K~Ae렸6tS2ZF}b@{}~DNk1E3o=sH_8"t߹As0g*Pʐ7lHp pu^k/б^Z^;NNV&CeKWEȡ"` `#AAZ.(!ZO:Gc^t; F#F7e@Q2pHN #WpSIz\bcerf|@70MK[Vހ0 З} {ϵQJߨXZ=7E|;[ ௦tb,?TѼd2udk+#c5 Yc_!$dU7fv`>;|ui+Zn;.=L R2Z|BtmԊ_. $ >0H !*DZ8qǯ_'^ZR%]=[y j ] F ۘTT@yM\,&7 c{"J55%P ۺ:Tnj]n08$>M,JEkxcͩP׿(-:4#.: }`t#_)8F>5tzK'PND {#e]NeԌrRlVCbnSZJ:qgH@KY7y$FZ`I߁::A j5,0϶񸕟Y="E_[{JɳbO|2˭i*yhl;{j^Et f=bG.f)wY˼NWUqg|QeS_ZD&)]tiCyKdY)ٻEk6+á {f /)3t-EIGYV ]8l}CJ1[3,kks@mPH4ePWrm止t֚,@pIbL# E $ Ցn=WY7Tb7Qg?00 u!el eD} П a;Z;80X;a:b=O).dz9{]>yL,o(@PO7&g-dysKԈ v! 3)w{0Ǩ%*i:xffEuCF3bv>N`]* #MAߥ#)6 cє̠!Fٚ^~ukUEw:{9YC&@G&7\`&VYf<@΍p䉃_8Ny .: wa шX1|G @ovq}iS8hta6^jiX]};((e)ٶ%Jl|nיq*Z񐱿SĈpW]䌢v&ř6 h)Ȥ@ nǠ? y -̧aM;fw\fa;`q-ٕ?m`@C6NP9@OQ=l[ = >![ۆ\> / NXK}Htϛ!)~c4ger ;ÙAD-kXIxm ?(Mq!iQ>ȍFx7{>sm@g(>ȠmK+z R>epS|;>)~ \#ylM3yGG5G鏳52-=zdkz]x{r?h#gK w~OWл) z5][ k]O\SkEEXJkB"$.w>$Q4+ ba؈ + + ""2ӰJ e;9ܙfλ|'3ߛ7ssY_2Gܶ w$q+ <]?6A -p?R~*K"tΐ:Kڥإ!sn:ڟ @2ћwq |0\ܠq)nBJRCR:e28G8XLཧF`J̭+ q'SNd =$C;CؙI;~>&&z(30܇~]:=[Ims16 #BiJC  )93pjV yat `*E!aݹp-7S\ '`M!ЦP|nqpܢOt+/<ӕMqD]]}2BOЫ!"NKX¯h::?zBmwLi< cLjßC!ؒ cԿQ,B g'Ïu't{!R wg3f ?k4 ]}ʒ cQ e?l@m} .㱣R1x[I_[exbsۃ#=RUf谭::>qds/Sb`}e<-rzIyߧ}Ȋ#YL&-לЃaGc*9F a /;c!z!i:r0BE')gPQBA%߯H:w2{e71 ]}ʒ2 7/mz(~Vۏ-{@/!q} 7ÖB-: Ё'!\K 75t8hw}Ysw(E58< G0?Eީ݌jxgc ɕb*:c]>`)'ïo[י;NKpxq(x]$B>9|{ mB{KmoԞWr֛йF/6LۢX|{]kBV*&k{wjB7]CϾTKBr&L4zBoQCB.nZB_o\Rg_zcM苵!77c79BSc7&`cc٥hg-5"}B7xv }Ӷ {n=ۻTo'/rwҖsjClWo7?,>] p5wæjCv\S{ܯ\:~ݲ[oͯ1}za]8MSVkW2ϿzBD }ZodTA+[v?ƹ?ZwS;apOY[Y?/kHY jqCF 'k=WٌqQtUϏ\V NT7)ZWv8vQe%_Qyw޶q,)Rzk'Wk\X1aebH\7_S*3gTqީ, z5{<g߬,gEP_ߪt`e3}_qޔfJcߴ^,>okޮɀ6j !eԷvi*u,z.a7۪%ٲ"wْ ƽ`x`B&'ciPBxt> 6 N(13ʒͮvwu;gΜ9gܙn -Ve9|*VoCunvG5vpHa$_U}K,wF1`vtXzOX#$?7z{XA*X[#V0cl?.]% M\B>lpr;gw|&]L:L\-+p؀I? t3Qr#A14k39`%ꑁ3LSot=s>KED $\{,9umt VOW[.ڦ~s26'HFR8se@&Vp::hԋc#bmHs9\,[XT9eep@N{j X2׉U]|J!q9qfl1fsrr?tYT(0/qXOOٹmCgY%:lИĚ}up@^b@]5X:4AW,_0;8oX@w<U>"9sŵdـpSTP3@mFLS}U\NNp@^b]X|};*(Pd>Aq;VviO{t6IUFZ.Dʍh@;;K 쉇=xI}8.+P@ֻ^z7T~ ;?zwf/J[zFlbp(zK>s+g3w:JD{u@+S{W(@:kJ8wiǩkQt}f@DYuԕg^M)"؛|79/m;}D\ h,mtR;Z-2!v4Ou,O^F:o[K%;*cgaKg]9#^NEGww©zkRw%dt mhbb)--L㵞={ѫW/ݻw3zъ'..Ρ#|rssa}90rO]GP\߈#wSBBJFF{H^^HvvF62 1޽;_;јh0n%x)))9qӘƨ;MNoy DH4Rذ9.>H@ lذg̜93U8cƌ'Oq 'SL):ujYZ9666BiӦ TL>=#--iz5@` T̞2O!:={l<# loĉIV4`2~O!p~رcK gO<-|HNH< 82d jV,B xpp#@=q%y_  ;WP;q3Oq$߇#p!Q&׺uEy7lߏQg߭7o'_شiv9qooM_l&rG |=xA;I4Xu!dqH[l9.6Ge]>kp-$͆/gEF^X( u\|KEjO{SM,c|xW7h2&()z/瑶|>">2y|"CQ q̓my[2Ӛ<<04g2E@ʳ ߛ2/2{~>'x'ڒ.:Z|o= }n9/ApϟڊCZ+|_A7ų-z|t!5):qeCr@}v?DP`IY|:^P6o">*- 0:2.q.t0x ϟ3Ƿ jŶ!Cϣ]j WRZև(/^^Tx?I'݄iG~kߢSϡ Gߣp 6l?v;)~G^e/d5H8:ģ~p ǃ"\ߋt{Q ~%o0j\;px~ z:ѣGYBІ4nnMT\xjP 6 xPt3:|WW"sxj|/@̸<zZn@cp Yq&p::f9jiD_nљ;2n*l&P`.n9_uw:ڊ|tn/Be} #} xG])-= q=ݍ8w@ip/`Xq7/GnF`87*ú2ӸY/իכCjp5C6#У,30K` b"yxY'si΁KviT8@P͖ g1i<q: ߁ƏKL\zx6Р7l6U%kNsIHHH/<{2a*^l 1~YK.b AD<\_Brr򢊊 ʶyEd xN‘iµJf&"piωzc=\c%h3 H c C#Sf .QxfDDzvQ$֤jCa9J|MQ7FKNYYl||MZ2=-7+PiJ*SʮsDX(_w%_ )_*So[>U|JgndQ}XCV` (_!_ujuα]'|G>1GWiȦWdOoO+kJ'IJ2W'ﻐ'0;tNéժT`JSVR5? 3*Y0*OݿȋƔt  A˗CP:I[+-c&\*+6ӨOc#+x Д .U e4.~OE*i||J'lXݔ~5F%{!uw+QeP U$غw-2dtA J^} V'nOLJL4U&o%gW/?&14.`F*InM](> lnڍoz#?/K:Kx-I3{H49ijQ305͡P~NKˤN#^ɠds:4mboǛ|~q^yK5cT~&7ےzc9.7R6~|eҺzh//;7=8G$4tYyvcF'{oFіƊky3@mXtWT8"I1xXde7C|нQ(rh-%;ghX:ZNv~^`qoayـCu:?@Z?ǣxڂ _{<(?N>+Oox2q<&_[<ڞeKgz{grcsWaCSK\zb~mѱz{]w4=N[b[  o,5Hw9e:Y?{mt2u@uto,!^ ݎ 79zW ]9#юħq3aW '#) |΀Nw`E#f@glѯBD*pXzޡ5L%6Zô'IGI/ 5 &v+Fb. VNH;q^_=!V'+(}HfsYWph`G*oWtVk<z=8I%gs ;ߡF5n =F~c#G~lV.Qu@5I(VYxl p\6'Pd'=QNKnB=8 +VY߮V_HzWם\X8:XGD9kfiD,7qNZ7@#-FL?&֓{]ѮFgSvnd]>inN}C:SPF򫗬=b ?t^pܾRbM` F Qt`Ĺ ىt։m)(Ѓ0jqXͯɅIwكRD:U>$*\V~Nj><[OlSjZ﷈51)T;Q72[bMӯ;2Ax~XUzPW@씑-3ps*\m::#ǜ h7EUD1.:mHFw'P8 #:>\+'q4o3pqu!u\/- gu>W@'u+  k'dٸwqä́š?C^o$+ǵ< OzP3!#Ĵ"ÔYYP=6h,?"TӊԿZg^C2[}?RUu)~l=N=*G&gK򈂚qE|j<(?@fw;,6"_~|~U |=ɬs-~lOvY9{ov=xO]i+msک4a}!G |ѰCs{K< ^z7 icS8@mXsOvЌh_?8)>'nod _;qsFͻh@^_+.|0#){gЇ.8 ]ٽj\eA6G^-UU6ɅƼn S|mrWfq[>gU䕸guM?GVSi8@8{ː<֥ڥn:T_{^1CH w#߄HgI[\s~-i@Ӏ]TW =k1E뺱AbXcﱷZb[{Qc챬kܽ{;>033˝yYӛ~eM46yiHԋu;jҸyMf񸌿u]y P#Ȗ7>"PN,eQvDnUD?ytEǬП2r-k՘N&-{PE$|-Ҙ&-=Qr agmęЫ5+m6t>>cn+oO4L1qa-h;׀w=[SjzEꪅye ?c'2%Л\zֽR/qK+0j5Er #iB;&qzuU81[ U\L{ЉEB#\[Y"t`'tg-BW UikE"tgggNNNپ_3]/_>E4-oeyU?Ui$tNe^53۷]my...omaAp~"EL̻wN/^L7nH'LYݧYJ!ONNs̡AAAڧE4CzBmzA-[Fׯ_OǎnLduf!{>zGғ&M˧MFϞ=׹g-3|{:7_u]Fj߾^z|'|B {?>|/o߾4**{.]rgϞMm ۤח)S" GϹ~BϐI*QB?ϟ?OGerʕt˖-^||HӧO>2辒s4 ׮]:ux<\7lAB|ͣ;w'˗pfЕ5C:={pFSn{UTǏDh߁ 'iz|;w73R!Xhs4 px@0~"iӦMycǎhl߾#zj":,B1͐,bÆ \?A:K;oŏ?HO>mÇyo ޽{ܞ@ݺuoF^K BJ;vA򂽅`|ЃrC'7}gtttæX5[rfroܸ1'qe:t(`62d3 j8%8%%l G }̘1E%P̆kpVa6BS".\ā#&&!%M1`QDzJ%J_Ta*Ͱ݄>Ey "Q~ {:u}8G%K}(=?3:95^bޡ~,"t DC8N?k,1{^鋽,B7c OQD ۿ?O#:Rj &@.bxB堈/@Q q/Ű`[@+@.uƤDxb(PGx J.XXo^#FLxaRxs7!/يgJ1C/\e4s e `?)9OUi%t B3ӡ{ Axf, "ClKzxޣ$dB7nb܊wL 6rH>}dx#ƽ[lɗ U{`Ad[Sr3~7/Rn{ixuJ=Y,"yջ<1q2J^i*͐~`6پ`2{)- p^d:5t 7"t`GДLx'"tU! ] dzLS?%]oBA1* a$zLMYk]oO BOZph^N@Bo^!1jSJ?zDcViОƍZy1GzA ͆.`_z1kE=٧©{`j m>bt"tAާQ WHR-=xqpB4{|*Z_AP-]5\7{dLC ,uuk:јEUj1z0&܈,R"狱ǍZq!^&Y{7,EL R/aؤ@\regXr6ߌ;'>ywKLX1H^~E?cNN$ՓL-BW *QBm8HV1=h:dލh4`IK/&=O6.7:ޟ<ʖHop e>ǎVBF~G͓ik2ڃ%=hDNN8W:~ eGaVkxT Ž{RO֟T?[גSsa£RPvRNy\5q 'oFxU5HdURKgӒ~E=-BW |zxWӛC?ǘ-ȐȐ= +Y6:dǑ^5~u1'0=ehxfcӿ.[ZS{X&0i7JEXN!tb. et A#6^a`Hahڮ͇]df<31Texv~San4ٮfA%Ĺvv[HKfz6sv16`PC=^Fq Wjك L? cT%,6v.dʒ4yjD I 4&T`psvq-@ЉʥZ'`3L`/9=HEc v^7#i.oa GIS k(J|2Y1؎=@`:a73SxB? Sp\S$s{L$=aAzFhq؎pP 2LrQV b6}*(J|pm|,B~@]}D[3TB?sN-o>$Mg!"!dەHNnnP&3"֮zW0!RΝH=' D&"0|z$)]"1!,B7^$k-ARõE FiCJCDv$Ę֎o7FAQAwQU<ԨQDW"F41=kϬc5Y̚3ךs9u=VQE^Uŭ{O߷ϳFJ.ĽXW$pT4pUL$DC0{ kp 1"4RxA8:z{|=BxpS8Ďu4!#H>sfF[.^i`7I/~yWees繄G롰A'a3Νw^'Q-Z"io #u''i=BQ'1i ;neC#xC?W"s;ƒ#)t{ ІBuB<# X\2!;纸ԛd a`>1md:Hs=8sh؃S<$eoRA.vAG6PtBLaP8Ch0'΃1p=M?x (:H=S qqᎮ  ߞ@SIۢz`J,Ix  o',?d8G[P7  :cCĹ $):K)HpK ă [܉N'j VoW< ЇAK ܮCG"91669ЉcH hh#xl§(ByhMЃW0Xŝ18Մx1\o<  _x6"N~&#H Z +A0N#8q#DtBnNE6=꽄_C v`O\:n)Jϼ uƋ+QGCr KOqlc,: ȷ~Ens{kǹDN~(v6t4!=!| [Rpt`.\tB H:@8^Hv,"+ypx- OE:Fڣ ?E`\$mI&BƑN!R@_oo=|W1n'u4hX{RqJM \OH!u܊#^qq C:)ΖAJ|X.o =%6!o5T'K8{ 0o?gxH?c5. }Bee+vF ?S<^0&(KaaޚIFtms|gq*!Ŕ͋*9te6e|E[Ys11yg K'ߗ_+ay+*rw+~?2l\􆃖mnl/yݤϲcOF/1xcr *iYXINQy? l#9iޖCk N.}bgLfmj*vvWge~UƹSGO^uB{r jՎӧq^d NB$ď&W=8Ǣ{Pbʖʛ:E5_R qM2:y*Z:TC;|P2׷C9 7w߀jafVVh(, Pz_ek춍Zx]06=Cϛ֥UGN\[Sʦ&!OŴ *$< Gցd9$D3}j*-gYaMr$Vg*TtBYS'3W`XvI3pJRigg8p+k>ЮudVJ[zrX c͆,~5Ԥ@]K}*ЖS4צg|]nwuJ寫N HMZp|x'\7f͒uJ#pү>kVƎ=G \X0Oխ7h@b!Ї]IOd"D-a:{Ū _I%_Ҳ8;bKhB< z`_w&ɕaZ|>.W\5X4}5lY՚ mW2ҹ}ԉwM7.XB^z=r+R/`e=CbEڐupF&KmQee 1u]:{(oZY0< -^dRZVazFq꽕3a~5{ےw$Ǵf+KC-9S#~m%޶,8jgۅٔ$ݞ/**.^Jpu};Hk&\2z3Ė4M G;uakP<ۤ'gM]tA:%&тm0k܆4XIal1#WS_Mv0r^Y]\~dgU[vaI't$l[ɭ3e}]v\A9}&_*,~FMeWJl#uJvE; b حKx#NϊU~o8;yL`WYr622gJpVϢ>ո+T~".dx [nö=A:y;"zrj7Y"4XpF̉]MzS6cPV,}9װ{]$YŞZG,HZwݠ3%p+ J)4P9hGjն&__NTѹK }x ~\G4 iة[?(ɉю)U C$kWԱ88Z 9^}g9 :rd=\7x`yA<I1pфL} |Ξʜ:`0ZNtSa}VMl| AXZӗnƭx %w-6]y.kH[=imrGi6ݑN4y>jRlK/yV.ӎe!\Ihꤟu{nt3ޣ<{@C>S3 3-[p# {*l|T=$y7Bl\o'GeX!94Aa$. iɢipl t0unTSGCGER{7ɇn^0̫ N;)<|I8:s# (=`T~e%Jv*Ї3lʽ'9ܮlD+a&8Mi`H_Oă5ԧZ/aV;`{)Sx FZr#zHq݌a&LwSgi@^ooB`g^4ksjAP:;"qq‘#R2 ]+vD{}ZS. )N`s$g(ipV k 4PiPAWW_&Nm=@szcҁ)wD{8xOAtޒGm4ڶ90zI-H-79y_2AǕxخ}"X./MR<1go+yS5w֋l kC.A "|=گf)"[7.Mp4Ɂz=JS!YOf⦻Y}1p S+2. #ݯ5>gay!?)G<@һX[_ 2RAŌ>I/<eCv ˯+5`Z2LwDb8; hF"_tBJ0 ;V'Y2N9iQla|KG»v5 Zp/j*/UPY-4H۷fJtFikE ]uĎōGF8t: Pr,A8t |:[<O蹄;N[>zf8tۿZ.qh8+Ն\)%o,1=}C9u-{#ɮyCWη,W\h׿0ύi!vvqvWkYԷS'е|\֛m.og?U];|^e$t-Ύ:W; \; IiT=t<6A#)t6;D>t}EZāU=t.D BWE2ôbr^#s^%;RN{T -3 *}O>wLϠ gt$׏.]p߈]Yzp&tB5z綇.)){C7Gz>ܿ_n]ƒ^~s(m8 G$Z>mkfzM] pǙ]S&[88ImƉ7wSĩTvbalčq }ߺzB-@@!qCO !87u;$90SzOozzfzꞖ=7Bw#cKaJ zPzFME{_$omCǏ8W8AOصms8F'enfVUx`pPn`xLɏ [9(3QmnKx`zt?,^pӖ3JH @zy*K:^O0,}U:9.g3Y >~̲alC }^w ̒@* ` EF+=$͘H9}Lyf g'C;}Ţcrx *iIx [- P;B-F%0EX\קlw;p 28<{r]ɐp~Wd+u&=ȡQ.->t)$ַBw1nNE6X +0GD<=V/`0"Ne3<KaM$lߔVc*IHn4=b<%%9\"n]Z/W/$^ Wn `IݹP (( 'HCI V>/\R҂^=Co-t7hצPsFI-ڞ&[3 5w.3*S&JñK[xtל= . Ám[chs7W2[6,U*7-j떝٨%vMfM'32H}v$RF0bgBaFfر%/\8w-e#oNj'tx=|M.ٮ'Cvc%.w_++*HƼ0kuP='sf8[v-i>f",ղ_=Ap 7߽pcz6J ?w*ܿ_kö *{[9N-#<8RJX9 {JLɠ~˺xl)%˼^\FNJn@EB΃GWY+7 I^u<@OZ##U!yqo; `{™{ +VLE_I߭9_]{}d$`mSbx!31_j~Ԯfؑɹع䝓W~)1AQ;OYikx~\TN*(9ߺs }^ڶpb142R/("D<ai?Me-f$.igK1KJr 70>۲ !_J¹cK*ud@z42h|6z9xb\R.\ ̵=p~ \9un@jF LsH`ۙk5']y 7 71wgZC&6<{]'VH#[VW~Ǧ ZqdC5 E[:r[ނ! 1lN!BG;C8{"m #P_WExuGK'ؾa31&H»@J^T䤴/Vj^{5r#!KAM a#AXFbN+9-FeQ8bRL"&H觮"W" iޮQjXF砡6>iqr(WeV<"}W3B@B"xlh1E{Cq) .bBwc0>:3X5 [:mA#]IѾ"Ι7=kHQ_:NwƐo*\D=z* <&ط;rEViuB[s =#JC~ -xݹҞw.wk-'!3νUb%r.;Y@Z1+%jq5&a$7`~ԊV:xݛ*r7l&{Ѧ[Bg[:#سcɺH " ѪG<@ښII}+o8ODy̯A% Nio\a$':kBvIQu h?)g^$t^B5+м1͂NL,FMP^G-ݚNjopy_u;!lXyNa;3:fR'CMeJӦXz׉ H-4PPH]Pnlx>T];,MQK&|]Rp/JlQֳ$ckuӾhdz6sS :sa,RwntWD p8 &speX?-Οܬw89;{@׮1JpC L3+fƔ1c cWkxČRZrq[ra̟ރ^x2g;MBaښg ]=UM-&?3.lwjƵ ]=Y߻Jr(f ҾDM[]{1F1$y E~| Zr8E%lFOm$V^"Z**5eBe'jX^6B`O1Kɪ H7V,xCE/Ga+t+7нh} MWmt0##$t(QݙPDڼق;d(/:' CD]%GL76=~Pƒ1trRORBw 3{TVgt+e C6QMBK^f(*O+;rp+1d% &:)#`uD.&l^8K4HW#@YЗ^5tU%r<y髻)@`vjZ/bL;2eBׅzi&Wie)/x~y*Cai^̜9+]RlE˖*.:?Np#;Hex<ϙkD99vx[sf?TW]})nz 13?\wپq" 6&R 3&u5xSiku搻]'.@\@ H蚥ɲgౙ%~p}(rU-G++\i?[ ]OtyHڨ1=*ʋHД )gsɂy7nUhsþ]P#%ܪLdO{-tQ+W. &wADܲ,rJعp\LL^/8j٧Zk@q4iMp=G>j黎g:ZNJ4#+r,M 6нhoUaMn8楣OcXrrݹyMuexBe_dd~ 3uVKUZrGx9t~#+K3c4T ǖK%#2_ n Pv,B !?N gRQ֙j{O^DPo=ܼq˴ʬU@owcKK4Gcca2 1vMPnmgнy/Rذ~0s0ebH,4s1IsR<K;`l̈́^Yъ4T\(c9bBBá'/%ʼnPHb2yBg=;ݣ.d罛Iq$t/mk禌C6P AsL~ >ϟ9H;9*+CbNxp $X. Œn0uj}R\0a-|M8vq+,8SYrKjIADU#8͵h==-p[y0)3=;, 맽fL3l/˚S3z E6_4p1M[S_03%hu ] $8/f~1I0ڮɿE[X*HY2Z@Om(VȜ״ۓybÄOa'(G] Fͤ8ݵva^bhetoK;֏VyvgƖ HF<v >~^N qʣC-DZF;<2g<߃DxP RBOpA*ġ#;ܨ/!m]!va?MS , ګq+JB&O_=&]/+ pk\ėyyӾe.+`Rs8'R 9ޢ9>U| ,>I~3 cB!6~lZcQ2M茧k:Z~Ax0>SEږx dV⃇Uo"_ƍGFSb!d.br)>oS+zMm|Ռ])u,;wָySa|)lVO>+ ƍczP|W0ˉk¹#F]ixMc|a,qZvk_Op LgeMBwצ7.wo `U8 [ac.w4z1$l/Lc2#l=!i@|a]7(fƁ@޺ Z||O/`Zs}IDV bv/O+^ob7`:7]۞!x yyzjyp'L PtOa6(${Ȉ0ezJCDm0%8Z;usb[dr&ZѢlv-E>\3<y5ޢ {n6/H+ǐLkOmy8'x0Yt<`FWX֗ڨA\ZԩŃ4."7LB3||7X8SÃdSuK/_*Bޚ6;{`C?U!%ձr=f2<3$I't"GtÇ s&wc>H'OL5L@K^g!Wj$zۋ ^-l3y];G?Ҽ'Oe$UG&Lqpf{AY,Vc OD}|߫jl$N4 |f1<_2ȨDr]\IkLvbG5433c uy= 6ێm.]d djn/5aLh&У} >œ/`a|ON ~dc>m/:X7:0E6 ΁88{Pkcc$ ]x ~mT=mϊ;|c2 CO/`;>{ă/ɵ=qԧ0)ڣF2;>S:S{ 'RK?Zhuۖ3<`B#)3п L`^o D.9>GDn]ic$t/|v݀7l#y ;F|44Vù m^;ׅVϴtԀqj 0 j0a&hA1L|ݑ ~FhE;uOX]([6˗2ox kJUXswC<Go~emϊ}d(K w C#H죛B "na)AGM`VCljǃ= ubo!N-l# |]{/6._1 ݫ6xe-j" *.Y8\ wTBWmIB,$Z횦HZ0&͠0ᛚ0^=aDs|&}NB-LÂZLVpVA%Y-\Zx.]a5Z}ݐ,.ruXWU>2b fx~$tm V[ωS y<߭Ʊ#+2L"ၝy<@/Z$/Yшsx͈7 xy1GL!+:\q6^%$e0ScE)1Z~h/ [Ю~38K}MH\>?vik2ܖ>*f 2っx:M."OvtoN_3Ram pǘMI5~JlS`v\X"<$6ͷ~G6yo}p3 ֮BUBMKTQ;33 .Z-eĢ,+L1jFA/DѢ!Z&Qh1I}@vΙg4ל9L=ۼxGO._#~[63 FӖ{oVsWꗈSxS]c{>\AUk #cϗ=g)A.q0tttttttttttttttttttttttt ]?šp9B:grzT׏wUr?8}5j ^t}xnuy֘yhfceJv_ܫkhrBᕘǚZ՝W;^cFW+ ,\SbMט箏ZA_'ot&-Ϗ,}1ys6q6<=>)iMv Mq[H^y>rz Ln7kmվ'}w&ٳ+6vDj)cId\5hu=RN=81sVto\.qXăoF.Cحw\A//^sX߭䇟a60 7z9t&9L#$yhuk]x4 tiJHMEC $޻*%ޫ"UJ? T:Ix9o;7{{{7;{9sf?O%tGڔHRǀ.)3ⷸZ@vgj1ﵜvFB%m?F'l[M$#QzpU'y.ڽfatM5j*m*elޙga^٤-Eh aitBwq 0qMID , _C:OIQ8.Uj1wJUR\"xxul93~dL /3׿7U*6J$W^DN@p5e,gaO?d m?&&jF$tC4d|~&-D'tW65zݧ\BBDz9HH`&ћe~НlBT'7jxŪDf~K'T78Gx8NԯBP'tNN6StBwm MT'N: sYZ<ۡmuBϖ-|C m-]UÒ~:j:K2+ oGN,./Y93f4Yϕ+q9C v%B !C 8t18FGNnk't\τΝ.]n92e2,XЦ.[Bz%tlr3f ?~wdɏ^֠z:&tJ*lٲ&~wvZJUX1c+W={Ѐ^$%Bij}v?Z<>K,UVѫW.]8|?4O%Rlћ7oҩSZ%0zqnիMH+sxxɶГ'OZ<^dH/N zE? ]ۄn)ڃ~~k֬zM۷aLݻG+^H/No۶m:Gd77nLkN_Çw`uBw[ {T˗ӍK+2e9~ҥK[ntڴi, ^˄n,~'}'NǎOx% ]Ä.7qѕ+W޽{!5|z)7ie8isÇi\\qM+UODr"QA~&L|^ 7̙CgΜi24ѷo_.ך5kr鄮 B$ 5kO7mڔo˟??OB_}l7nЄڵkWb ڹsg5  \Szv]'t ] viGTڧ~:u&&&ҿ/t|;uDȱ7x`+Zvm$<9<֭[v]c;R dx--[s(FwJu###'OtBWGxB=͛~~716ydےxϱM6<؄_p=|Z%YpZj[B_EFѣ<0~$ۇI:|0ߎ1| gx0cMӄ.a/z0hڼy90n!bcp XF=t۶mˍ{РA#=z+@6``?lrΦMàޫW/:37Ld@tBWMxB@xA:qGΜ9:͛g܏?-j#\=kG` ] |'E`&Mݻwi~:2tw ݻ=| ΝˉQF: B?{,7Fߠ|0n"z؏H~֭& DS=GJ%^q?z葊-x#%%d1Co|?j {;*˗/σ$VU4AʕO>vD1|~1@9qD6?l4a]~̂A LZ$tw+EXG@~R rG鄞.]͑Bj2 tyQרPwGbgϞahBsqFn0@CE{9BWd^t&rŋT! A't5M:;Ę%7b9:[r3O$eBG47%tB]kθ|t5Nb1s(]*CcN$ՙ۷۠lh0d}||FF:uwh"^l}a8>F Eb… 9Uר/-[ Ř?Zb#4Xt+Гq_x/yy0D0!;d4 y Y(,zMHӋ~ o8Id6PDuk m ]^0*|f8݋ dRؿ aď쓘c/D4NIo@2l%:Ph,crEYo@G YglA't:`9#&:%pD|P?L#ߟ#G}|ғRe|!O->9 ?w`\sTb,yZYbY.?ޑokm_,Twaɮ-{϶U>5LĆX.a{ dz$Bw\~wvNnk tb?1wJ dj`:qlDyGi>Q.hf>u= Vi;'i8$>-޳|0n*/#I=ϧ.e˙H o~"BeإbxáGT@΢L.w(%wJVE%#"xESyM dci^OnMJ$@%6vWWiٹS~!L7a @o C1-zH= )^E)M*\2MT܆wAf1 o1#GI'yd@{u_i٩?Y75 %ћYC4$ R4 c "©b9$"E DzQ_'Ro N:{>TԠ+Hʇ} GTgSH>d8"PE$A==Ԇ-"eQ;GQқvz(-`C$Gq ER2DjRoA esoAD  1v)m_o 42taÅ\eKAO@€m&[O"SD o(ѕ(KE#1Άzi̗8 8{#HsU'F^ ]Ec9yW[qG>dzogS@= F.]!{=)x3Fܢ^4m,R:3E2%ƽ.tH&25缀9@!jp"4(.F&ѹOzȝ 8w] WDL{ec-Z]h ᎇ׵ET=#6ٸΨ5%}w9u1vdu7euR#ŌxGd˛l9h^d-q<4nAl믑0rʈ]r])v {c3HL%0FBjR>cʔGRUA*2R"kf ]?ӭ3g g2#nTUiwPnN|Y_Jeb ĹC ǰ&KDs.LtQҲҳE`i-B[G(hBib$c_!jG$*v3Rh|٨=#j !֭jc{/`m^;G)^d1/Gf\˹~+q AG*2rʼnlUYNrQYNjEd$1 j:;osQ6LDZKbʛ:8"52՛+X&IDwFwHʾ:2r7*M/TMƂN \Le6'~#ҰRkAI78FFHG7G L<=)Arϔo4N$yƐ53D55|Qd#MQ@]@;y)',~rzJpSWv֟h.aejc3\-|Bt5wzg(E[wGQ5;OԹifc$#~n] nݬL %Lm~3hg(M.MJ}XUI!Ӷ9`V̂̍9c@0!(Q̊ KL<;៝靿{gޝCsRMJ۷S~W_U_b@b|m޲;oK?Kk1ǂ캄Wg+-J٦(j7v,,xl  wD#R~\-Ȗk/9S_-ْ>V,}g 5[0- M_'ؒrěl-rD~/Nn5Vpc[ځ7EDXsògk3rǪrXS>NozQً`%ڧܗlp& 1 K,vzca&`Msna$x2AvcyL) e+!)Wk%n:A m(pb'* 7=tiR&{&ĸ`_6B M)lɖ^GbsR:N] Kvu; |G1AOܚ:+4mghN)AmBCCӂ&lO&O!ԦGf׫ {8`w>;Ϧ|CS'-i\hnmR ڰ'4mohx5\&سՌVbK >!nxE0-; EJ' nJ"Q LD0U߹pPo^#w[D WAB%>Ip7>4uyx^֥cݼh/Cy:(5ޮ(v]| j즄mi;%2)ɓVvqiْ5*>uEQ[:rA*;%W6>"[&,]To.*]0jzԝ>m,zlE2 S)܌Yk76/;˂A\˟,WFÚ5&;U+U0 ;҃/=jl?dꊖBNm6/UaļbrplQFP>sڎ\7A/˚/H/ݓl=!Iu$.0'~@!IU_ǕkŖߞcU{r_ukƑEg_ 4߰N6cݻ檎-lClkzE-z ؽ5G8Ah~L%guCbݘ\dR5oL|ْ_/) 8Yhɧi3iӱ]go6eϖjdH'[ZRBK*J%ZHt:|TS7HDQ$IYHh"Yڤ|2{v /î}V"WhIs-yRВj,^\R}Wi ͟bJ&gq[ұe/eťYXdPGE) pAġԱ(t76΂5npS,w<GuהGj !zmޞL aҽ-:0rʓ='a6=Ӈ cW=(SdMx3ş?ULܓEg%pAYCTw5^ל/V}y[)0ÜVU")B-(LŽL}5}VHOWcVY"wJ/EZRR!J U Q>NJHs57 jՂW#ODLJd-e M$KE \-9%ܾLOf։֌: sx]bqwETEJNU7k)Thq Պr2%](~zSRէuUH%m,4h}_jb-9}K$w(аY -y/ H<h0a7,&e0"48l" XH75Lojfm2ygYQ7קh{ SFSYpiE-k1.cHy%"~%sDɚ3esZm})1e@RƣodXx@+ uA6^KkJH$3u_<+\w֯I_mJx,oBP zZ\_WĐ"r/lH5dH@"U $Ѭ ih9OErHuYt070%g ~jr ZeED04.e{\K,~iA܄ ap1º|x:"xp-Xۼ9X0)x RkȳHoaar(] ',bo}N'CP9|Jک<)3ݛTGz$q.~^ \N{KU5R:ƴZ55@F%5k-ecnjC5C5<3"'"\yUe?bHc[p`2` Vhɝ"-Iӑ"ٜREN\&kȳ u͸p뚀ЍY ^e;>8yEIU呃OYV/E81v/CT:,JV nXBkԕ+ڡ@  e0l#)PK[Sw KgŅ?|UuRn 1X,PX Z[W7` eR|"(<1Ccj#$Tܧn(qZrN cpBW)ں{̋)-{IOHaKN,¹quOlt?$Omu%|Ҳ}IIAq@m<ԽɗWJ~ܐhn)'b枷!«!BڟYMhITܪ!2t_Ɩb 33ѩ^x oPK4䝣>f+0f[xrg0 )Hy#R߈Ax$]u8RcOb6&U{MXr -{ƹ884$Bw{%^5qk0Qa),tkԄ_8HFV})UټS%O>t}C.cK8;eW/M9RSZ%[4 \R~BdeBڎnno+?ꈴ;Dud_EFy86 osya= Y(Ŝk> cl$sHyFP wp»W)4eO_$}ƴ*C(*-DCf<S͈ ̃Cc: ?.y``!x*aQa)?< ) s ;{> s r[75ްF0[SFAU~N7a$8&=3Sؒc0PŎs}D[ sҺV~& "YWQ3e["(>ᱭ/pԨή{%05MVBC]dokj@. sBZ}}?Gz_noK*sG (f7]RNeg9 eTjRTޟ"jUl*VÀ)YP\s#tVR&jBWb%9@tqٛ!Y7Mܚ8{s7DY:ºu눫+3f !'N$Inn.1Z97&,Lג9M=qq15X؜{:|WCc-) \d}m$aJ ҡ1.ߺΰ(R4dNG"""ѣGUz E-[FJKK}X_7ӖؘL~s$3 ˲XŎ*-{:cCڮfK&1}5>{T$s1"IKK#O&d#'O$gΜAxLk<18 "ke~cڳY9G|*_N~ c%,)r ==|#+ϗߤ~Rhg-JmnΌ#Q7ttlwZWw,Y†R_UUE.\HϷmۖ<~RP4OXB7i?c_?~ߟZ8]^^N>}JpѣG$//Kaa!-.‡|P܂}'dʼ546h{lڴFQH߾}y`w~(v" "&ŋ͛Tat2e -nݢ}86{l*cxFݣGuB8p*(mσ6 zcC 2d=֮];}vÐ95%]>.)>Yˆ7T{ ڰ( rjnjW#tSN \r <))DEEQ @h>|^/As9r}{n1@7XBqN>ݻwuk㩅Eh Ca'N;wP2{-ݣi1~6u/;/v.c0vn }I]-fD\˯k[SF!!!̤)1oJ0. ?9INN}D ZxL =ݳg+r; Ba`ߙ\o߾Mq02`ߡ`H!p q>^("nPQ7+ ²ի=Y狌ߡD@sԐ@K`ݜT+S#/<#òhQsGnP7E{вàRưiuZ X<#30 .&媵+Pw܌ vk:9B o4a}`2 az8͛{Imhl }6tP(3X ZA0L0E عs'u.CXX5 'wF^~;fEQAf#W[:v!]ՈãIaHN߬&s4]wZ6r)pX''[z<J]t vAyD5v^@W~H ׃1$t\m!T D@pvq`<7wИ:o^Tiɛ2=7]x`Ah\RO݇x nsw+ktQKUgg^/)&CUt1 e't6. sf-~:<;XYf3Bر#%tcYB1@9c2'ӟİ0sr$q #t 10aǎK#ԡ4ratmgc1EMӆ+֒(4tpzF";d9Bgtή~=L^Jo8[;Y䌝k-:2I&m۶#tc߼;٘<2'ڀkҜu^\ t@|jV爣c\ 1VʹyQcD2A4ԏq8:a#!l gzi4l 46m ʇ (V0dZs t~IcSMKDWmX]ybז,O[X]&Zl]\ !`J7s1pi`p*^a)(۷DSR1 {l3 `H .uxPG=L^?D Ƶ3NII8;c043/,m  k@yC[Y]P0/j*{,Ԅ/Ւ=GdUӝ٘RkqظkDVنך$Qwk7+/ݪq7fT`uvڣ96A8,v CC6/Жqr59V/ځOv #G 3K֭7[Ի^=yŚڍ=Tg<ɼ=zuU[*̮0VхS#"H8{ [np°f-^Q E[[cnd(~ ^Xp(L&A^yߓv [KnN^X*u%Ş ٗ)~7 *ٹxt-%[]ocHM9_/ߨ_mYGeYe]Y `q .c1/ ԿqF / hJwq:ε]]v!,M=iעR G _FKtgtS4RxX+0~]{.:z9!͡[x>;GYzyߋ@/~oe9 m#6u6m;,r;޿]j*q&AZAOMhةV?ZqIAY gt8_®_2iiyoصnyH<[ = :b_y k[dRi7蔬l'zfYv( hA蜛$0(Wx7ym~wЅ)7/Mq@mEkX+)&q*Z+k&!-ŶЈ y_{5-&&L3qd0S),qYn`4Vcf'Iͥ^ָSǮtèN63[C'`˱i³}m{^< 2'˓Z D[ ǫqqqZiB,nHU8r<4p'/;6'Jw۸qd# 4(1v,P\<kEpi#RRRS2ivhĂ#j:+ǥ{.5JDzu/N"vEb'S([Y-f]^˧YjG22Vfg+0e3E/i M7xbMF.HkZ(X`ru Ғ1rÁS Tv8K,APA#ss^{GS.ڵRvx[Xᗄ!sܡ{/C.5swz~ӗ=pm z5#U70i4n5zEyV}s{}v|yqo^+Ăr6n:ndviIiM_۠s,/wQA(M,k=M5*714-sbg|Au#(@59K!@GVtH+XD T4MsjՆh17r\FB9*U8/-tj=S{{.?пm;W ;uA&)Au]m7WhX8n7\ނSc\ע#^-4 |ߗб ַA1Q}:uݻk'Oj05:isUb5Y}v:V9 dઔ(.s86.w{c b-""B"exq瑄7l5|c9?hʞy[89HSSq+DDwgXoMjwt9|9.7H2ghcꊁХEzb) me, ohƈx,xm!vR`HBWt ]ee'kaÆZ}u\{zҟ=1ۭ.uRҭ?VoDCހN)ncK7AEKzha}&$n mP1Htڴij5G(X،K|y#t%  9˦O)Ud$ne. 1= W=?qw_v;4ŭq(LsQfR`KY4#d֖SNCc\vU}= ]F5: FГ\iA̘1cԨ(MSg92s,E`^q,薅K ]XNR>Ftɇ76Amذ7..Io>ßev-48,{VԹ= ]`1(t1oO&_ƥ=X ɢ%Y 5V:h 29]jc|p"GBeEo2N{{Zv2j\Ԋh˭>7%qs} 35TNYu6oG6Efĸ[=SBo_:QDKRg=z WWpC(lw: asa p.0-]xUV-B7b%m_[A\s+C(ވic]5=0ZLfkUr1: -{۷/Y y0DN[qyTӡC_~ hc# 4! 7a[~KVpK}6A`T$#JDS KCr|@'AS7ӿ-b>%HRYOeǟv-N'JSF0r(oW<>KJ2#xriX8 \Vg  o }N;Hw3y.%x~D=V6!k62cc[=`ς)=aʚ=Kt= Z 5V`M#uamЀ ٹNqƬJ o~&Pg䪧_Ro ~SY\N<$M65󾣀_^K2tpy~(ن, q9#^ "Oycڔ":B\ҳ~┭)O4-ލȠk+n$O\q Z~w jwwsǮn!}(0E||S4E#Xو;وoĥ;/{.v~)KV$w)3Jh;5үU/|ӉxƛN:ԡ2~մߴ[ iŜ7mZgO6APDBی;evx׏d?ec6_h̖|щlSOٵ$Q'(,ސgߋx-ox{uСdWf!?V{QNKoo:? ЍqrT0K> y c\zVΌ&6?Pc7]mڝO7$S;HwfA˔Mg;W\j\`.9o]!݇۵]q^vE.RNZMM~УS;ma1rIҘoMYC;d)=b1p]q4Ub+Rq;J93T-aTmtHD8 !ͮfqEqo1oX#{/z|+ow[m ;ˡ>$,L6i$co%oŸ?W4O:Pg{7ƬZ3UxVUt bbhk{}7ۙO3S$G78xR/d%ΗEYܰk1z~u'C8aaxʡTti}0NwYFeֳX&%9_OvWi?m;&.|Zo;)z'a=PȈ@ygF@M"&{N~#]PWލ76q#T!5e- C~ nٙIEwxxx<5Q sێOwiq[o~Ѓ/}KM͐afL;jq$@9S]ySw|D…3vea0<*3R67%}d y pϏWuPP#KB08!9! ln+36Џ7KܘѴWĎ i/Kwf!zMl6d궓2w+x7Sgk|7O|]]yڮ}) M'l*,n 4Vx'o94& @KFPH8 P|z ؁>giڽ&'Sd= 1t2Pqs2$p3mơ8wbmV;ݾOo6Qq[O|q[vY{PW:!5[|F`\ƉT6uo{ūI>!A=dha׺'k$ӸGܼ^KR88@r~k65G+xr8f3[8rXKr $߳RjGvҪZt1?͆-^r욤 cWnn6|! ꙗϭݪĐfcT|:Fɯ [Gh`*.y̮T0 ;Yv![1B5on5Ri 8(=-EM|\1-b)n'r^Fv_{q=.$`]˵~_;)H9skNV?ʯoy $܀+k5 G QObߌ.yw iCB1e`94V6~R b\ ^"kY е?t٬ZҜg%}Y#nl2>L@6 #L}vuv6hy ɐ~J~ty2.یZ'd%#exoo_Oդ.u\5%MRjcd l_HywMg<{EQv;HyE±3e,W7dȵq  RÀ;P قi!dN(f~d[t-ǒleRy.9+z/ ^'tհ۸Ya13?7djێ_mu5-jԨ)^|mcV%7t}V4ڼ:N(T e5+6@CyJɏ.7rZQۨK2@Dh` @;9%}@HVG2oyKֵäG:Nݞ^]Ũ[]&;]DO !3,hy?Z*[rA esIX0ϹOv w;YU+ L?L;7 d|΀f<%omp!A\ .`ZKSkpoqg`N9qY@zKg2a2mޘe7NWON[K ׄs>8\U `ּ~܏we#sY&1s9hoggƛ0+v3>W=y._e2kTP:iEw`IENDB`ovs-2.13.0/Documentation/howto/tunneling.rst000066400000000000000000000131151362155554400211250ustar00rootroot00000000000000.. 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. ============================ Connecting VMs Using Tunnels ============================ This document describes how to use Open vSwitch to allow VMs on two different hosts to communicate over port-based GRE tunnels. .. note:: This guide covers the steps required to configure GRE tunneling. The same approach can be used for any of the other tunneling protocols supported by Open vSwitch. .. image:: tunneling.png :align: center Setup ----- This guide assumes the environment is configured as described below. Two Physical Networks ~~~~~~~~~~~~~~~~~~~~~ - Transport Network Ethernet network for tunnel traffic between hosts running OVS. Depending on the tunneling protocol being used (this cookbook uses GRE), some configuration of the physical switches may be required (for example, it may be necessary to adjust the MTU). Configuration of the physical switching hardware is outside the scope of this cookbook entry. - Management Network Strictly speaking this network is not required, but it is a simple way to give the physical host an IP address for remote access since an IP address cannot be assigned directly to a physical interface that is part of an OVS bridge. Two Physical Hosts ~~~~~~~~~~~~~~~~~~ The environment assumes the use of two hosts, named `host1` and `host2`. Both hosts are hypervisors running Open vSwitch. Each host has two NICs, `eth0` and `eth1`, which are configured as follows: - `eth0` is connected to the Transport Network. `eth0` has an IP address that is used to communicate with Host2 over the Transport Network. - `eth1` is connected to the Management Network. `eth1` has an IP address that is used to reach the physical host for management. Four Virtual Machines ~~~~~~~~~~~~~~~~~~~~~ Each host will run two virtual machines (VMs). `vm1` and `vm2` are running on `host1`, while `vm3` and `vm4` are running on `host2`. Each VM has a single interface that appears as a Linux device (e.g., ``tap0``) on the physical host. .. note:: For Xen/XenServer, VM interfaces appears as Linux devices with names like ``vif1.0``. Other Linux systems may present these interfaces as ``vnet0``, ``vnet1``, etc. Configuration Steps ------------------- Before you begin, you'll want to ensure that you know the IP addresses assigned to `eth0` on both `host1` and `host2`, as they will be needed during the configuration. Perform the following configuration on `host1`. #. Create an OVS bridge:: $ ovs-vsctl add-br br0 .. note:: You will *not* add `eth0` to the OVS bridge. #. Boot `vm1` and `vm2` on `host1`. If the VMs are not automatically attached to OVS, add them to the OVS bridge you just created (the commands below assume ``tap0`` is for `vm1` and ``tap1`` is for `vm2`):: $ ovs-vsctl add-port br0 tap0 $ ovs-vsctl add-port br0 tap1 #. Add a port for the GRE tunnel:: $ ovs-vsctl add-port br0 gre0 \ -- set interface gre0 type=gre options:remote_ip= Create a mirrored configuration on `host2` using the same basic steps: #. Create an OVS bridge, but do not add any physical interfaces to the bridge:: $ ovs-vsctl add-br br0 #. Launch `vm3` and `vm4` on `host2`, adding them to the OVS bridge if needed (again, ``tap0`` is assumed to be for `vm3` and ``tap1`` is assumed to be for `vm4`):: $ ovs-vsctl add-port br0 tap0 $ ovs-vsctl add-port br0 tap1 #. Create the GRE tunnel on `host2`, this time using the IP address for ``eth0`` on `host1` when specifying the ``remote_ip`` option: $ ovs-vsctl add-port br0 gre0 \ -- set interface gre0 type=gre options:remote_ip= Testing ------- Pings between any of the VMs should work, regardless of whether the VMs are running on the same host or different hosts. Using ``ip route show`` (or equivalent command), the routing table of the operating system running inside the VM should show no knowledge of the IP subnets used by the hosts, only the IP subnet(s) configured within the VM's operating system. To help illustrate this point, it may be preferable to use very different IP subnet assignments within the guest VMs than what is used on the hosts. Troubleshooting --------------- If connectivity between VMs on different hosts isn't working, check the following items: - Make sure that `host1` and `host2` have full network connectivity over ``eth0`` (the NIC attached to the Transport Network). This may necessitate the use of additional IP routes or IP routing rules. - Make sure that ``gre0`` on `host1` points to ``eth0`` on `host2`, and that ``gre0`` on `host2` points to ``eth0`` on `host1`. - Ensure that all the VMs are assigned IP addresses on the same subnet; there is no IP routing functionality in this configuration. ovs-2.13.0/Documentation/howto/userspace-tunneling.rst000066400000000000000000000170241362155554400231200ustar00rootroot00000000000000.. 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. ======================================== Connecting VMs Using Tunnels (Userspace) ======================================== This document describes how to use Open vSwitch to allow VMs on two different hosts to communicate over VXLAN tunnels. Unlike :doc:`tunneling`, this configuration works entirely in userspace. .. note:: This guide covers the steps required to configure VXLAN tunneling. The same approach can be used for any of the other tunneling protocols supported by Open vSwitch. .. TODO(stephenfin): Convert this to a (prettier) PNG with same styling as the rest of the document :: +--------------+ | vm0 | 192.168.1.1/24 +--------------+ (vm_port0) | | | +--------------+ | br-int | 192.168.1.2/24 +--------------+ +--------------+ | vxlan0 | | vxlan0 | +--------------+ +--------------+ | | | | | | 172.168.1.1/24 | +--------------+ | | br-phy | 172.168.1.2/24 +--------------+ +---------------+ | dpdk0/eth1 |----------------------------------| eth1 | +--------------+ +---------------+ Host A with OVS. Remote host. Setup ----- This guide assumes the environment is configured as described below. Two Physical Hosts ~~~~~~~~~~~~~~~~~~ The environment assumes the use of two hosts, named `host1` and `host2`. We only detail the configuration of `host1` but a similar configuration can be used for `host2`. Both hosts should be configured with Open vSwitch (with or without DPDK), QEMU/KVM and suitable VM images. Open vSwitch should be running before proceeding. Configuration Steps ------------------- Perform the following configuration on `host1`: #. Create a ``br-int`` bridge:: $ ovs-vsctl --may-exist add-br br-int \ -- set Bridge br-int datapath_type=netdev \ -- br-set-external-id br-int bridge-id br-int \ -- set bridge br-int fail-mode=standalone #. Add a port to this bridge. If using tap ports, first boot a VM and then add the port to the bridge:: $ ovs-vsctl add-port br-int tap0 If using DPDK vhost-user ports, add the port and then boot the VM accordingly, using ``vm_port0`` as the interface name:: $ ovs-vsctl add-port br-int vm_port0 \ -- set Interface vm_port0 type=dpdkvhostuser #. Configure the IP address of the VM interface *in the VM itself*:: $ ip addr add 192.168.1.1/24 dev eth0 $ ip link set eth0 up #. On `host1`, add a port for the VXLAN tunnel:: $ ovs-vsctl add-port br-int vxlan0 \ -- set interface vxlan0 type=vxlan options:remote_ip=172.168.1.2 .. note:: ``172.168.1.2`` is the remote tunnel end point address. On the remote host this will be ``172.168.1.1`` #. Create a ``br-phy`` bridge:: $ ovs-vsctl --may-exist add-br br-phy \ -- set Bridge br-phy datapath_type=netdev \ -- br-set-external-id br-phy bridge-id br-phy \ -- set bridge br-phy fail-mode=standalone \ other_config:hwaddr= .. note:: This additional bridge is required when running Open vSwitch in userspace rather than kernel-based Open vSwitch. The purpose of this bridge is to allow use of the kernel network stack for routing and ARP resolution. The datapath needs to look-up the routing table and ARP table to prepare the tunnel header and transmit data to the output port. .. note:: ``eth1`` is used rather than ``eth0``. This is to ensure network connectivity is retained. #. Attach ``eth1``/``dpdk0`` to the ``br-phy`` bridge. If the physical port ``eth1`` is operating as a kernel network interface, run:: $ ovs-vsctl --timeout 10 add-port br-phy eth1 $ ip addr add 172.168.1.1/24 dev br-phy $ ip link set br-phy up $ ip addr flush dev eth1 2>/dev/null $ ip link set eth1 up $ iptables -F If instead the interface is a DPDK interface and bound to the ``igb_uio`` or ``vfio`` driver, run:: $ ovs-vsctl --timeout 10 add-port br-phy dpdk0 \ -- set Interface dpdk0 type=dpdk options:dpdk-devargs=0000:06:00.0 $ ip addr add 172.168.1.1/24 dev br-phy $ ip link set br-phy up $ iptables -F The commands are different as DPDK interfaces are not managed by the kernel, thus, the port details are not visible to any ``ip`` commands. .. important:: Attempting to use the kernel network commands for a DPDK interface will result in a loss of connectivity through ``eth1``. Refer to :doc:`/faq/configuration` for more details. Once complete, check the cached routes using ovs-appctl command:: $ ovs-appctl ovs/route/show If the tunnel route is missing, adding it now:: $ ovs-appctl ovs/route/add 172.168.1.1/24 br-phy Repeat these steps if necessary for `host2`, but using ``192.168.1.1`` and ``172.168.1.2`` for the VM and tunnel interface IP addresses, respectively. Testing ------- With this setup, ping to VXLAN target device (``192.168.1.2``) should work. Traffic will be VXLAN encapsulated and sent over the ``eth1``/``dpdk0`` interface. Tunneling-related Commands -------------------------- Tunnel routing table ~~~~~~~~~~~~~~~~~~~~ To add route:: $ ovs-appctl ovs/route/add / To see all routes configured:: $ ovs-appctl ovs/route/show To delete route:: $ ovs-appctl ovs/route/del / To look up and display the route for a destination:: $ ovs-appctl ovs/route/lookup ARP ~~~ To see arp cache content:: $ ovs-appctl tnl/arp/show To flush arp cache:: $ ovs-appctl tnl/arp/flush To set a specific arp entry:: $ ovs-appctl tnl/arp/set Ports ~~~~~ To check tunnel ports listening in ovs-vswitchd:: $ ovs-appctl tnl/ports/show To set range for VxLan UDP source port:: $ ovs-appctl tnl/egress_port_range To show current range:: $ ovs-appctl tnl/egress_port_range Datapath ~~~~~~~~ To check datapath ports:: $ ovs-appctl dpif/show To check datapath flows:: $ ovs-appctl dpif/dump-flows ovs-2.13.0/Documentation/howto/vlan.png000066400000000000000000002432161362155554400200450ustar00rootroot00000000000000PNG  IHDRorLiCCPICC ProfilexYy8߷{&spdvyscL)JATH*dhPJE$L}5|s~Zkλ:QÃaFBB"l(.;+2\ ϥub3d=#B|X+<" *B`}3G "6/A J()1^~XPPz^Hm.zT?:T߂D&6 مG#WcBzBhoXό7yr!_>Cd P;%C=-`-#[#c!(m37<=)_iWOi lg1"n3D0QDo>0`d[f 2ݞ9P \0DR?T"ABp2" `9燌) g߳Q9 K"sl󶭋tHל%FVvV_hy"ZB ;*h]6Z#0hkFߘx5G=r/ \_ Ca~Q]dHRLC%)r7m{mbOE$DE 8-$qEF⎾y^1dd@" gyԁ0f ď? ) iPJ@9.F @S`| ;؀ !2BB$@Z!dB.B( : P5t u@gkh B0 &07, *.l{a?x9p\Mp~ Ÿe@ѡXQ|() JerE"PI,T> UjEFQs54MFSRH^}$t6} ݄B?GЛ" #QØb1~XL&SƼLbcXVVkubc v38vñ$p8+pU:^y#WPT|;444BjV޴񴹴x^Sz|7~NΆ.. }15AOC&ׄ%"(L!9j=qL/MoJM~~AA!!C?#-0>#1&2L#YBH٤ Iɐɛ)8E 듽i r7y,l|2&,,q,E,YFYQ¬;wqdG+ll:l>lYl l/)A'؛ه9699899889p\\\ʹyùra 3K BѥS (]>.>h |O6ES*y  R:#+","$),<#&b* R+N(-OLVLE,HSqX\Q_H_P8'L#**Y&9$EҕfNnq9!+)(,[!VIL.UU| Aŝ;}vJK1SS񧒲RRҬr J}UA655%(F/RA53">T Z-RQm>mvoJi]1@:y=Yz+j(c,'L#FF~FF ƊM0&&'LLMLM̔ͺ v,-",ZwvR2Բ XZg}kcmSd3e+g{׎lnWc^>CC#j'N2ΉΏ\8\\Z\q˻ w=GqOƞ"{>pp vNupAQ=M==x}93{wO߬\~@abI`IJUPUVSpCMGPРЮ0g޷aQ ElbF.}ѢчbbbVccőBO'%\܏ﵿ߁c$Ϥ΃N&'_J^:hyMZu77fg7nv޸%}6;;w&]not|{ދ.'{z޽yڃU6?RzԧwO4+ KOM@!:22zBݬ*952_R^H }."/;&oШȥE^M_ּ }68*&gL-jw[umBluO9Ĝ\\#v9{%jgWyB,5$9CBCg^k̏:k/c?PbGR3))!i҇820?r=hvc999sN;yӉQg <:K:Ow~dɅke*Yp/K{i=}LxɻuN$={aRmP`8jηʆO$;fAq2:ztLl]sCK烾(/`뾦/y|]ڇ?~~.J5dbp4,4Ӵ=JlB ѝބADG$0ؕ99/p pPrB҈H!R8s\IJ9VSNNHsL[L'DQo@0ͨɬ9ւRJZFVN^AȑӉ8qq}uυn=u'nPKq=.ngwᇃ<{gyЇWLnnxadѵиЄdTYGO'^ϋI[jtkY{êڭ C/ }ϡ4蛘vBDk/u | $,+YYŐqG [2i˜\#Y>K0BKlb~ْW+dS|4BPU3Q8YU]s^7W/I?PHؘxƤY+%u6IjvW;:;;.㷗wqwSȣ#/?PD . q % 7هw/"%R+GŘx$RX $$DĊPbC_2oܿ@ AWo:8%5 >-}]]]ߵ3@r !7FΏ>ثw!!"4< &o",8, :~a)xï(~)*U@}B"=t(E,L V`7qʸeG_Jd Jg8|*6x^̐э9ɜԃ2=d Kf*"K+;;VJW88]\]I}~+JX!3aAHdTS $} edv(J(+ȩ hjjhы570Z76u42ii`uzVr:8oRwram}zto ]?! z_,o܋VIߧ\I<䙩s5]v\$gr韣*+뮨,t&ε^L#u&| F.ѩEɸc~g/8^+56zm2sG%ʲJٍ[?G@!'2F ;JRg@RCK#$ A{8(jD|&Ê3| (6*uՃZB H~>d6H.~ +Öcq{pŸa 7M5 m m F$? zWBI~yx2|Y>7Vp`óc?ȡɱɕmdzM)d.4*XMARDXHtLlCeE%Ies7h\Zs$5]< #yPZqحىvsqnuޝ>O _L f 3HHxqpCڙ=Y9Y,O_K[.}!"oܥ[5G, W0ilYl}VyPOiL}ܣ7~vyKWoᇛ{~0Y:<8dJXxSqр'A*MFi4^2E*BH ZY` >(JYP8:]p#=3eaOc_xq:REɣU=Bҕ@Rߘac`& 2yȭa,,.Aϱ9S[B);_.P/&@xHdV Pt:,}CfJKIηJ*wHZGt< LLͽ,,C&mmGœ7]AE{z;bn"ws;^5Y_I?-C]=1rtҳNjRŔ_)^VM,pscV6ۣw;iv?T|qY3#_x I ۏľx|p䳩ƙď/J_Vn.F}:Tj^} ~5uՍs?LRDDCʏ#[[KH$?Olmmmm,G ?Wl c{q6OO~{/ pHYs   IDATx |UտH 8cFbU vZQjJ[lW}m+,Bj-AA&eI  w%;{{Ͻ{>^{}Yg)6ED@D@D@R@fvM=0;" " " )N@NXP1 " " "=;" " " )N@NXP1 " " "=;" " " )N@NXP1 " " "=;" " " )N@NXP1 " " "=;" " " )N@NXP1 " " "=,!H![E@C z獝:1&/+835Fy2I샺ɭe!k D—lSc׏q92T\hDD @W.n4ý?W^Iq&RI#C+Ku35UTT"`py͈Ju(bk@R81qpZ@*ׄ 'W`g驥7J=J@34'7U{;^3F]|3nPw_yNFvH6%ι9+?9`ѵSʋ/r l]:; *|t۽H-p sFQWPkHn!qβF[gt)w"E{wœ;bo=,.۲ao /{&z[x}9Ѓwzuk?ZZNzE\)%D@GHɍ O/~9 4@Pv.Af3aEZ@@O48*v.ȭҎg'Z8ly930~&^wyϮ(q=6-7C~Z(T?S_lj6@83K41|^x)trΙ:}~[@oos>yTv48D*$<'gM[}?fB7=cSAUmȜ*yԝΨPxنڪUisKKv,:6@))~9֫ ˊ׆DHm: 4>(j7t*QƋLDU{!k5?Æ=edI\мt\PVN~>*t햟߽{f y0;zs֕whu][_eh'ҫ,%E@Ρ%i̝Y]0㾆i{0}Uz^gpa]/K~p|SƎ=90D --#$ p(4cd_М6wS 4yzRiO@g9&|qg5m 璊}ꊃp[}imw(㇭\sΫ<ܔ"NXKMoO⠗\q+:Lw8JfwZB) TtSpyUeT9xNJ*/ʳoﲕU?64l@APzo.X~o3yoŘ@'ȴF>#ZSmExAMG}AP8Qq5z\wE6G>)QpG@hgrMz[Džw8ҵ)R\tQ0ʌ&ٝh"ɼP O"4}4g,z׸`Zu0mц'N|SۋMp ^m?KR-$'՚@ ?'G۟YDG=[@GqohG<+5 F2x+Pt֓@5K(RkΒ2ezCu]@Ac yki9[֋wxHu5&rR]QkgiYUѿ{EDC/H$]J$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " " wYM$DW" " " q p'Մ@" (I$}-" " "YqhMR~[." m A<"r 4TJUI@X̙o?N~@puQ<ȸqp[湂[k51RTT|gƍWy4hO|ҥ@rTTT$J0"ఒwȞ={zhjBDty@q1˅;1 E 'fdgg3{ݩ.//Nx{s $ȁ"TVV:⪸ .E }&L]^^Opl&tjN{NQBڅ~q饗ZmqN pd, |,I="pUUUy5aϫXOWDKCi8|@׼U% D;sX^c'bQZLX[΋|oN2c vA&^\Nc I@8??[n:u9" -!cb"ӖN2#tU$(E:J+p'77Urs4C?IɾI$-(F޽{X nVwQ1fp\avr ͌m6 m HpRA@ZP$p_@SAP :$Ta;fqWD@D@Ҏ3:," " F@NY\#p'L@PnWE@D@D (I;" " "n_H; w;fqWD@D@Ҏ3:," " F ̊%jkkiǧCr Fal/qHp={S7tӞ={R}o;nܸ`[3k׮M!LUUeKJJ!ցG\3]Bt뵋Лi3x"U/̇mۖ 9 'iXiz1 o A-;S̺5]M*0s2HOCp,PHHH.,IuIa fV2P6=H='ANiIؿ! l6urR$0yI=C<{C =,ᎷJ',@2I4큪?Lt.4/g-,&xlmPW҉U˫V@[x! `xZTb'?pUiCOjQ6]6@|R))YʇXhʹ@<7i32 $;e/i+" " "j wZL" " " E@NrKڊV#@rP\" " " &p$ " " "\$@ (i52 $;e/i+" " "j wZL" " " E@NrKڊV#@rP\" " " &p$ " " "\$@ (i52 $;e/i+" " "j wZL" " " E@NrKڊV#@rP\" " " &p$ " " "\$@ (i52 $;e/i+" " "j wZL" " " E@NrKڊV#@rP\" " " &p$ " " "\$@ dZ"5Ӻvص宗֗Ţv%Cu-^ck|1W[} Td.|5!u`_Zb9i:nٌ#rj{|ݡCv߾}K>t6#z}~ͩ]=݋ ʹaqt 2||/ˇxT:]vu|/Fˎ8әS۽CP.7\p:zre9(qܠ w:C"-q3ɟ8{Yw-(8묑]>enDIq'~] 9cz2w7?=q3?{ܘyȼ/Ӻ*]^I]b$3clC̾]#N\G~"F'uXt3~blEc5e^ qt_3uk7uuj xcrdN@kh=.^q}?﮸y+>\μ]FҤ~@k]%p˷/6ѹy܏8]X3W΁gyLfG"=*wWpa5Z6ϤMD [p AX6͍@-:\}g^5+1̒# f~ox[ǮƑ}ka׼w:q̳+Y{4R_ݯI.}ig]4t; v?ldžkbJ CGhDێcddՊ;6u#i Y^r@N-;"B}s{D;o~eZc?-2ya)6f{dY~ \ZJ!rFߍ UA7SX*qf??}n┓;/fUorKZ'fu[>&q6\OO뵎mat8n̳ GmNC9 ,^ʷ/K`flvdւ q3D_94r^oްص 4B N㶬zj&'ֽgd!?8#t4'u]WG$ptݯy RkΦ^;zspyhoi b7]1K3*/I .`7m\j3<gφ;fu/ثˀ^]ʫ7{@A=V`="-ټ@B}O<6ah˚-jMT"wjV -!xaU}wf|M6sHU4Vs{dhWC|Ð|6-U#GDT]޲/r%6-ʡCd*9%M_ɪk w߷aP{eEnLu3\vp O9UhӱomҳJ6/֩lQ+vׯU++n)^GC^Q79}6>煴Q;m:o鶯 =슮݁5F \ }dcs7)G򩑌L_RﶴNic#/<t_1v?Dq~ :ıc>'_n~:|iXz7#l|ΩGs3Y_ _ަإ0˫}Jc{$@KK&*S]Ӱ9_As[oGCԔ77wFJ?3ǭ$߸-y.Uٱq/W![,$5s87T~!PsPy1ݸ:1%ZOq$?XUdE IDATիw5砂"kox5;+3]H4;zDPh } (H4;zDPh } (H4;zDPh } (H4;zDPh } (H4;zDPh } (H4;zDPh } (H4;zDPh } (H4D+kk?sݧMz!C5e4n`9y X!:hv'vV" " " F Ý;v֭X}Xjװ]2:u.UܹsՈ=0R w222233ՋKScvO>wq%ݔ G+t34if1k(?,m0xbu84ݯ_n-&XC45DҡCcǞr)eee05554sϽ /|+DƮMlQQ _CD^^^=9,b )Ǐ?zhm|8qe]6ńظ SȔ'aٓjT4L;`7ҥ ~P_o߾}Y_VG {l;  m55Vf kcزe35K/t Ax "c fbq,dqp 6mzWK/Dqu 'O.W)MV$]v޿ފC,G1*'j/;grNy:NBNe!*++68'q0M`"P"ظŔq _WnI``ҺH<=yQu`=yY4LpaG8vQ ,Y2sL?e9vNp6؍N!x9sx W_}gjzJXZaիEx:E1%T-.:n@0H !#34 w|G qN^-w}ypOS]OyE+߆?yѴi^y&QX<[gg?҇qμy8OHggCȁD$ZMp#qbW!fR?3pB8ꨣ>csʕ+WXOr-xL'567>ӧ2dիI  .&ZxϞ=#oek)Z~dii)8(@-,,4 \!ӟt۶mq0HkOpW{kf=X\җD7Fz}L1sl:P/uӜwRқ7oI))́pƍ߻wo5'Hs &bx[ēLA9`oF;Һ CJ֓O>Iw`^6sv%y䑬Θ1Q'J LDS1WFH${O?M1#GZ@@ 6Cu8Ηx3'i-Ըm 8Cȁ XpK)67\GqOZ{eyc*%˹VGY,^N9Kɫnf~/"QbY!`d7HnW0́k67Ɂ> Ԑַ*j ছn7I4p OVnlo3f#Sq9nH[bxq`ܸr ԧ:,{ա׸mw9Cȁ;8Wp/v'aX3䌹h4}_ڤq3hp|%؋¶qˀ|ѹiqK1s > !xVpGڸ$^ Ŵ(.d$A&(*]fntpIp^S&C0 \v/ݻCpoX(ou UI K*ˎvN{bW/"\͵&9g۪D{p5+jv͑! qKnKN#E[X i!k8VU~De%Yw8WcKޞ\s3V`18m+` ,"C82J$[82)pSU37zjr H w;7$JxȖp P\ ,8KVQˁ$A zuL5D@R 9:W w;r&ʽrEEB Wn UEth.f5ϧz/f[3\U'K΁{)9}oF)iJQ)2mU )rLnlq= 1[θM5JhF)iJQ)2C*nZ"kBdT ZUKx+t͹w pčDyF۲vlF YM֫!kF5Fm.J:dsR^F丅Oq=UebNm(=i_~ Ul?8άnS&/I>2E/ h_8^r ]!0PԨerdtHArب,i3fK(ڵo[":tkΕׯc?&4i:͌@:RXXhVoltq- (A4ܶm<6QZZQh+h)g+f2.=cV h4-ʘi.iRNO]I(am[zN +W>sq "ˆ̙.;3.Vފ!{1 hž}X]dIrxtުHA?Ys{hh1Ќ~hѼ⤖2Qz7;C(=m'$]pMϰxrb+aqz: EFmNFAwhh:4Z>3!֒UYD͑Yod L2QlK,>h㖪XlM%'DOC*!3B I,("Ma״X6XrP15A^Ϋ'm਩[\TNO*'B7(ֹj!Q9^=裏&:hŐb2Τ9/W)I'gi[<!e"Xs[IPHդȤ9V1A3XL~iPI& bΏXo yӓhoE/rB!O|zVm_ZZz+kVcZDXA3me4t:5R#A#t/ uQ07%:,90a&xk,A"Ȫ bG-FsX!K(JO'|"{J\4J4oT2i\u:$Q"@cjoVC&`Jāˑ`LX:,V@y/ƣ*&E%vab@``FbO[ej B_=㏋nhUiW;02ы9@9 CeAmL"!R,x7JU2The,hżM(EzlsHYhŨA~IC1o[f+ղЖJR'lW4mŏ) ZsHіkiB> T%[nEC(AS)4D%'Xq 96ᗼ![BjT0[* 06̓[1Ra.PؚszR'ZfM JQȤ獵mڶR搥k6yZuq%E"@ㅷ"S1l0 =;[rŠ,?ׄ7A8dQm"dž;:yN2P|J4רTY]cqۆ;9$yZ$M&mQ3:aeȧ~MЫ l)O؄tRP/ PpV'Z Nipz-6);#&ӓ Z(oUQ )\,BAt&wx4DζZl AuF*!lᰰɼU S#/7[S x! 1vvy-&j@F ,"齨)`[NҔ7)АMvVȷ X#ϹP"VOc 6Q  zAljeLO60E xQNOj3Y*$Q V2TH&NOWD0JO:`-V6M,n2G䘱'RCyJK>[|x Xs&e4; PuIHC漂VD*JO = |Pvq Pc6p6y= ,+ ,&~&(,IcZ(`lI mVV3ҦV9^'[[*Y%kz"EP9S>7AE 3*os3}LO_96y8XЇM$o[YGTӠaM Ԡ_,ìU4kYVpf09=GIDڔRz;h5\ߝp ;:H(b# /Ueqo+fYbT{'9 X$,*$Q',j(@MVJha+dPb,mF#tM )Za+֜ZmVl#HBa'ekXȧQ F5G>UxNWOT]WO걾g Xw\UC8eΙMdKyߊKu$ǰՆ2Q͑I<|QR֜ w+l;2SإPA wd h~Ic /IUQq6d+c"v&흔ckB4 _9H9AILDL6[AޕK'{"/ 1Ad-L2l[1W,V6k5d ʘ o٨Q)Q :ɤ9[%Xu &n)D Z]7Q/IՌ&%*&(oˬۢ͡'KSzR3D5g9Ha!Q'e%Br0h9R!4 cK<ت$ ,IPmV1{ 0v``@xDŽ++hCex&ů-O0yh Z1~iUjhjFO*ūj P҉ 5cXWLD)'ml¯%4Qa{gY=ر f`6gb cKSXiMH ⭘(J^o%v4ݴVQ &ʌ!9v9pip}!tf(vĎW-X)tnxT2-)%b֦r6ֲ1M52]8d()V,4t SXmpnjvzg* +96\N(AVY(U[D.]mt/*<%ӼU6oE&6WiI(6 Z[mh6HyՆsX ~KYiVm Ag֨EjXl~<bՖX͡p-<ٖԟ\e#,Id`;c('gk f-/[֦p$EHj+$uO<'*][ς?om5]H k^ϟ{$xtjWH 68x )@9\.X@$H8ڄ?c )w3\~GP˸>c MWmyCرcy#*t糉4Fx7ӟhmN>nܸ1?@|1іn+UlsUwj.aR( IDATa.;diqK {X C-0G駟f3pvDg&'[у⧞zʍL߇:u*@|BW\ᎏ 1sSc4wF,!L?GIvfH|T+ͪ) ފ u?]˰3G1f݀0rH&*s=8++cɊr > w|d~44Cc&gG~ߑ/W]uP-N p 'PkƗƭZt)i.8Y+ dv7*l5"_qر憙!p uZ 5r ܲ w| 2N-XMWqhʳPV U M7dY5k=xf, Xt~7>} Wvq2ʁEĕ,o۴䮡pk!Kv;bĈ .# \ 3 :hg4gb \> /+IS;ZAރqk"m| ćy܀/P!`Qmz>-o+}jªtS tM9?鑖?5KYQ`:fwt͉)Axií Ʋe˸ =_xsO]j@teǁTrK|WPy@H쬟;&ā$dGk/˦Gv랷>Å/ ד1gVCNSa>Q %;7FڱW3oͻ=h?^Nϻ8.W^˞-R8}ٵknxANp]۪.]<32NE&5|&mؾ IFښt\l%@Ŕ%;ā 9dS&G#! x؁ Jq պՃ.V~[qmZ&.& @u?j_[Dt{teN bSN 8 S˥R$og^$P-FpNp3|I"f2p;-w8:!1@Mq4XPA #v l ֊v[X~ 1T`J-p?;\C|;ifnuWD@D@ґt," " iE@NZ[t$p'>@ZH{Ҋu;[8ay%/nc%;,&YST,Q‰ )r0)I5;y??gh57@GLPbc#CjBډH;>-0a?'Jw6pU*.@₹F@:-GN{/=>\K;g̘QT} 7W4wAq2 M)-;iP3.);A7sH^=~jW|xc$u+~B`ix6BGL =Y wY'y pB<*«ZD сLoƂFN~paxɁVr - Wa5kdddS>:y_.l= vƨűɖmsIIA[DLX\޺ྺ#go.)~ԓٺ$_Do]WރΗwv9k놧'ŶDj:P)KW޽Rϕh~vnURR8ι~rs 6mE? t+mt ;_>j=hsr yݿfے1þׅwP<FJaKpKhUٝqߦԎwYѮwz{޼ ߜ9럡Єpq~C=vEqYtB<#Ez!Swްb?J<5f9 `U g}Mh2Skݼ{ތ8'u!+N;@*Ê>W99aBoMȁАr -dax#[ѡ;v~}}OK}~3>|n U3' )5iq~K?egw\q"P2։鷍̂KZ3{cݱ.{3 4-٪8LR: 㧆GxͩK>0H m'BP)PLN;qp&ʦ?p/k&4kom 4,^mYӟFk2{Ef1:{j,}S;Fpew2/(گkWn#H$h)]:(]tל? @ZgF9Jҍ'AS{M̜v@&_<#ԡPCCCUEG];k.ٲ:5LEON=h@ ԁ49ծw4@9%ft<ı ZS.1>_L-_ Y|e*JCvj)grV_p䠞"%K>{7F-Pm-0z׻[<+m" 68DDΆBy+r mH%nUncuܮgNuBs=bgk)w#]anO6ܕp0<~_W`ѤSvx4;;0WѥhxkfD=Gt9XE5ldIZ탢xzn ;ҤoqtPE]}䳩^~uVܽSćo5Ow]߯ɉC|x3-غ'<_RUʪ~vYC/ڹuWVMD8tYў_9}cvxZ68 ^eչ7o&ʁr •5+ *CŷмœXblMLk떯@]Tl|K돤 "/㩋uW-|c(rVKBSϾe޺pNUviube&-h)6;u:~ Ri-jIҪŧN1uI\vWVrz‘aKEczdrJ@JW ;mʄI[=^ڨ+rɁUҖT~+.nBӽYQMguW*z{o(=5K@JQ:*܉U.N A$"'M=U@ЦF" " " !ٝP?BknJjjt?=z%O#u(]ggf|Y jkܥG۱:L3HSQ9x(N1+#c@6u?(2l)VZ;̳W,T]U]w,ټRSSiC]߽'|OUXP5DСCNNzJG!=:9U* v[Yʬ۷GPCx̌PFݺu>"?|h*@r.S܁Xg{ `Sixo))޿:8:%W)Ý.fʮuoq^Cwo'y)vԧ>UP&nwBөSV,ApXt:v'cn({'@_r*++_}~ӦM=ze f:[Ѕ"Y9*& #s>w(!pNNv.r xѾ2vB~;W^yy:l9aˎ۹sg8p nފ]w1''>s=wر=(6JXyKsˣVfMܶm^xA8Zڵ+vee,v̉X2]" qcӭ*xtBƩ@l_zʾJFWuVȟ'&ʁ47~w8MpǼkmphPLÞ={N9 w Y~D5'׼k4Q u :K1ܤ**͎?_*N^ڭ[|h!ܡqkͼi-5ǁ_̃,$n-ۛwPN݁pO@?C If( wp>۾ g1MEE-r=e̙0G_87nhjcIނbumΝW^ykro>GY4 GFr mC.R>9\ˎ;⊅ :Uq {uGqtwala|`Z1!IcrµիWO0og~gZ\".a>K.7j#vOUosǏ?c bڌ@'rҰſ{VbJ[qCh}~.D,۷3DR$:1 Ð߸ٌB< 裏{(**0`e]vsNqKYøhw X>OE]t'N6;xԱb f v-Q[Qjw̾@xp hя~|ÇHȁ8+$E"~'I#>Jr|eWA-[2CG׿&!R?0@vig~];8& +WSiFO{P97swXr΢E\pǚjOVZ;>=D8,olF.|;A=?5k ^{%jf;@Eo;AZil9)w}˗/ѣ'N2oիW/[5 RK@WX(OrJ'?y饗@vjϞ=@|5+jX,1b' N38*͈x[ zZ4R#斝M?awrN:$\yү$9K/O gGwq΁|9Wms5!Ӊfؗ8)-6qJqu׭Z7޸ꪫyJR:q04h*{I^^F@ RiOKf3n:/qwrÒ%Kx&f{Z͗p Ϝgt!:* />}x4sxI#wp)/˼r|'yg&P*4r >Y7p]h 3aKˁdUCԌ0*;GMC׿~Gx8Dio(xO#07uHm3~$19?guf֩{+j:½r ~:5ِf!=f}{fW썇77>:+0@9]+$ı)4VA45VHc`ziwL+x@qdUMk w|\x+`+9Ny晼Z P4\tMÆ 2o6@ ȁ́ufW0!Mˁ/8צp'3eg Yx861Þvk_CG.^?'bd+}D9]vZ2= /0<y[#~ pEw4PIG,r m39}5Bq=,1Q?n[CJ;"dE^6y}sn!{&"MV~BSOPz"nV᭘g(=ES7DҦr m09ޞ}h:hrGAߵywX=S fi cqޣ<_W*tIWFNpMrX|57pGia8Ϛ 0gΜ74+1宸3 9. }BՋ@ DALr Qv'xMߕ(sp'ꖝ(A&#;6mh:j*zp J>eΆ |& n#d2L r"  is k3<`D'K͠KM wn88ۣgc.2 IDAT\0U1[۲e V{Ņ1=ODDA ȁ4 /k3@uRQtɛA۽#ĉ|_裏-[q<ꫯaС_=~ 8$0T ȁ26ݐQ_q+&p'9밸4R,^E{y4WExx' ms`N1--H@ _ź{VfoJ)$aGәqO<,]Z|7"\ܳgOeϥÇe,B=84cZƑXgǎ|mb2yk3r qqmJN\qfc\Kx>R-taeg>V.nV\g}6wN%́-׭[yw=~po\?hD<?s_~\~&'|臈[ LutX=O?R?xBJR$@p ^H o9\I#p]o)W9A-aEt^@]ZjՍ7Hgsr^߾}ݓ皅xTIF@'l7rqOˁ$hnY,:œ;E#a |T]N^]KY[޹ewW\qg0޲Cfr5 2#Iթu |,۷ W]uըQڑv9]ju۶T?~H-vU+_wK7I\.oz~!KUe9BY;%?oEz91[y[vN^l:,U{ꐾg MwE`JȎoQnJ9aR]?>\\\})aN炤s 2u;mpSwϑiLpWUR7>|;lQ-rဇWeTWdߗY>贂̝e<8z׮lݺ?-o֭\Zu4x@^^_yg0BN/ޙt u>YKf*kE.l:q}&ԹZ ~0,9Szf6<>@AzuC0tJNAGxs&_I2£(UayΆ[k .9c`^ǔoaPY;,rֻ}ۡ8(nG2B5ښyB{|Ynڱc7_ܱc+l\ZO?>by >\{Oz&HSաs^eN*nfKd[ |ɷ~ۅ'٣s8d i rv+6wԬCJ][eX S_+F8.{>;%kct[$tdhPU~p~]s@CiqrS~3~cX8s!N GםέhTVVY`}]n S&F#75OCYZU}'ߵ;|t99ٹ:fgp4X2 |sڟl]p4ߗjvY便X̷;d$NRҁԄWLgy giF;j&H̅*O} (jK ]zH;y;u%gvGז/޹s'vlV?x{N{KDkovދ]r**weW;t ] L fhM/^~ׂQ%PeO w@vʤ]R>yw`}t\RN؁d#Lp Ge\JJ>^|S?U1fg};i/p=C ^N=uʥ/}vr޸yTN}pN{/u\D ?9/nvꔍS@Cf.)9Mՠui˪h5eɒY2HR7&wEM&óL؁՟e{w-\ˁ4R<o5gc2nBNџ]8k/6w_ep&۽gD6WU@gxdtS'AVmXYK>rXf盀9澿mXH$)HsW7 EOqǝ3 y ĝ-EJϰwGr 2oUty=B3/kIS]{W&?~Sf^LxzVۏ>Wfwpyb{,H:ӇqCҿ^UQYuU')R0zdn+ڸk>)%m8wUS[wM4y 8s%캏,Kh(v_Enx[CHB0 =I=]mvg#R{p5m~nlXc4֤.C7~\szÝ܍{>2622ؚuY˲iX;RVE5._[Ǩs>O^fA(+9{mNhy$pMCnXe~FP;̪j]tcl. i%1brx#;:Z1ތ.VYtVXԤ*"@+~%@bi[ؐNht@g41hYх&@l~+fA{&=#Gw-} ,@J胗Q#Bbᚠ %@Z+إzH+kfk1&sfO8Q;wٰeTTjC\)8(N3to|1&tiA hD>tx`Q"Ur5`VVK."y Yr8cNԓJ%$:yWD]R! a$ӮYŴa˖@oD:Wr&P5Dbn"f2dܘgN9Bٜ4 J8Xh2^ %tL<&yivJОeyABӳ'/뎃;vf|cXNWO-C.mMgn-gIbqxApiqVe@N9iMOGZAn&<ԉCӓ<젮 Č:X ";/ ,Hw]bk"GX|~k=1o+K}LkDc;úQءc8M`vBxvV3dC,iXM˥`0=uΑ Uٗ2k2J"h@*"S$g0 %(8%M8t,7 Q aA}YQzjͶn\"x)8D3#5HdM_ $Wx~[aDSn r @ƌO"@b`bNW@OErAzdGۉoeqcdyYiNWP)nV>@A5qܠ!-Cc9 ,uk⎶A&BH'56ҩPG NJg dzLruQ$*s<;Mw2ml#9=1KRRE Y]U!x@BMpk&>B<# ^8Ch61!@< E 9Kj;DG)iaH lc &h \3 BhևqV8br;= ^7bɑpC>_3NgŤ4)b {3r<;դO&@\u%XRi/hyO&n V5ya b͝N}VHZNS(‰VM:zPDa['[ݖȫUƾg8FԇN9${,QEI'd蛮=v rz5fA%K!\fqd85%pCNKh\atW/@  *PWѝ)sqikD hOca0ˆB:pbb޲}OCÑB\u1f<' 34=|@nkL:]c>_ xE:m)^&\GǗfKߣ†@mcA}MiQ*,Yu$Ԛ 9SP:?mj e% JtGOa,9{v7_BZltZm][voyoz;$:S<&,'ie7eXS9C݇M麷ǩ# ۓ9d5Rnо)=<9־; ={&$ wSP^'kUa+eˑzWn|bִ_6x _?m{Փ O<|~SK7(+.*7kUꗞ _ #Zq!QQ>F~`JۤXJ0fCBmHհ/_mkV<3ØڷiucK]Eges *Et*- ]~2+\s Y9fv` `WCmeA' mu;\hʝ^}nLspC[opm@<1㫎;5>5RjZUc;+^_ccؼ]3dd2ّw|Om/,v5 =W^qt].ZwՔh#ua`J=|Q>`f1kH@oH67e1ClZW,"@H-Sɛ *!@B.4; [PtGK=GVf 1Ik\ :F I[1^!4ڢpgհA+b1WtG+⒢Bj3sz}Xxc`>+EZ5Y=׶dy JHI7')K;ò=e:]y^['l %k3xFwXZ+o1)YL]SU-ϓ3e<015AFʘ*m}o),YBŵj,h ++e G:nXy# *޳7x{,(w3}ˤV#O٦WwxM+r* 0J wspC25vr>& 5au.h"A!C \j>ijr͵"&bѮ@vͳЩ; ue9YND|:UQ;Z쬟rgsȦ |Wk"3yDեrtJ8f ޻~XgTA{3O/t#Cڬ[v0j|WSm5YDv1Ԕnå)&U>"/%pd N1T;03o5UL9u] +ZCiJv@ۜ*@Ck$hPeo(#嘛E6!3:oŽ3{Y=O?cSV15?yqڞgfzci?SOq+k6{7'k~iq%h']y($)_0|fÓ~#dwvPlr9s̱pyl>cFʬRTST"fղP /OH8?;r|7=9cSo+eZMdbGɑvz<B㱢n,HT&52jMtԣt`6gL6ݲ3syG8KO7VNwvXsmtYhvq IDATǥ/YN~0@x\޺ >)];?ެD̹0gDh045x6l`9X2%eL3eZmg'q|qj+wȬ0Bo34m 33Ik[daK^#N35'9FH`gIҔDƇ ڝ&E~,Jc-E/9TWNm-+޸M3|?0}udGZW`aq%C'=,m|JĽw]Ԋ9vͶ}̉/-\֧W%+ѩ߹4j5q(wZw41128cT*oP@Xǂ/mmN_]+iYk u=/;Td{ HrHX5[a%_UUUPP0tPIخ]233 {vAv ---}y徊:ori}* 7&1-||k44z˛MZs lY`Mm]eeͱj=;1Ӧ-.WWԑ#a[i>Zhl5ǗS?NIvjkZϚ֪D %bGLwbJ58MꗖvkGnu!E|UVV:t褓N7oիWHII |>ȹ}շښ²cwjs+_[뫨HUM9'#@+z[K|-%@؂oCIdoR܉=)8a.'55BG7btfZdV /C"Zx-_udWϻ~Z4࠷.,*D@#7 -$R$@*_wĕѣ_JrD(hF AW?CZMb!+zݡC||f 44ڡ4kYڭFɞ\i)ޔT‹U0P jЈfdkemMζDeUUUeGQnsbMmtiD5o o@;x46@ف}eT8l%MHxR w%$%Nw+k6w@A#lm,0*jj=VsL^$kF5P$!!1d¥DHϙuW@:<.gcQISeD& '\H m 4.E7Ie Y$[.WK+S0AeLkvE2XMMZ ÓL"4ĞZ rٖW ViIVk{V@]fiv0}P@Q.\}bLgF* VVT>jf:pp[v,/׎ ¨4%D#g.)^m(4l:aFr_F,~<%d ܇cT =  D\[ _~AY~Q9ׂBZU@J{u ,h[\&FLDn$p"]w>/#Cl';Cg%>i_4ou lV I=cZSL$HVq ]^w6 j{4: RIĀQS#H(/uϿqhIaiA2Ғ (HBLbJ4C*ZtKaLwƩѝǐ {^٨ إ14[AF6`W0 M|Ux [>S#WZby,ZL5(5LWh4!UUE'8fT&fKڀUa@APuSӜ{+F oH" mM=yy'Um98jDߤdM# MP(e;yl6"L aeC)xpXڙS>^$Y6^ `. ]u O/]vևQmJ*bF=`Jߌ6PR"<~މeC)Rt^7))ibvey '9ۋ⧌;S Ό;;dEϷfnΩ~o,ԇji'yrcLZjH~^o %99ԜʊZǥLv,KtCQ|iN6Ze5U ~{o>?f ][ LrVΜm?S]-BtiRSS3%0e_?H^|;Kkf1 [925h@, uf"9 9Jl=iKMMRW =Y݅M@KMuuE.ǧE_<׶=iJK4ţbPwa᱿т2REMB̓UF <}K&N4e5Biۜ>l':2D@ʱP2}CWL `:Z1ުͥ=wVY#8zE4q}j_z熥g,;cn6iM5kOsټ!;CSw x]pxS*Ӓcp펐&_An u9qҁ2UeT9~S FS/@C{}#5@!>矮ZT .;{[И6n^䔀U{AԹm%:|^Fē"RKe޽sIKK#|κW[H2 b 2yg_~uBgɻ'O<6ӑjx`-n6Av~ˮpV`6t2hJ=CRYYYUU%5Z&?=pgܹӦM,94#ed`;M{ *DJ\NgȀ [Jy!7нQp2v`nKよ%bkJm|$ugqe]&j=;rr?m،D&oRңC(zTKCp -^}CqJw1J;Ҹ*62 t'xBDUW]5gILvܸq999=z)D`6y8h &G@L:l;StG t4 "WvW":8 Wڷo_Hjlt8G1uBqhD4H ѣGo5kpOGt ׯÇ3Rxʯ}+UppcdQGEU'=ԡ\+ Yx-R[NtDY3̙3N#V2[ 1L2H $(HOP ip72.ڻW|FFLhÐ$z :Qң mTE3o[4ڧ43r6躖/_>o<4G|HkSĀC<N>~i feeڂ#G>ChbBܐhz2, 2MlO7;RF1<\ ;2 u'|rc͝ځ@PxxSPa'oy eDwXB+ĘB\ @5HsD0qJw"9,b )+nV3AT)~rY0G*I @X@Pg?{'% AodP xa-x(",qt֪U.rmC0V~^a#zφx2 8IeU!h@Rرc]w[om dsܢaJ5|li $'(ЭpVR\|%%1@x~1,k(]uND!۷噬*' O2E ;pY4$FDHE"K\{Eig?O #2(* @}kEL}Ç#7 :8&:2zHB8fU|E@֦M.ru]uzW\'"WX&^h9#\F~#FrXi u,Wx*A6;X lݺu;0:2>Szx* U2`+ ~={T\%= !&,Tݓ:;v`sCYg_Rl NE!`q8?IREXXĔϗJ^!N|8bQݻ:fd?Emu.:ʭBDb_s5|o ?H D\ \+ #NˠR +//9,Nկ~̒uXbR)PTD " cΝ,Ώt"(|SN9o:2^G ˖J N\gXk.=iҤGyCr1DS)6|*NO?SoРAH a[-:깅PG F"\pvh„ ,5|B `ʛ_yc5ɓ? :2LU Ewb9rkYEO>{ a#SJAP!&".<_}UUO<`9BCuDQ="j2ˊ4bg /pƍc u&/";.E/‹PDs* 69BVD".6o ," z!&͆J]ŪRkF@3UVVş9c=VkcUNEqΒ%Kj!bV~X~G,;K L-Q M W^^@u>p@:H.l -*4@4" K.DδiӞz6a)N4J1 ~:W\qŲeC4W:P* . w}7&}r[oe dXGtliPt'eDf-^é~ D#KqbRD#"+8nx7bS@pC N"Vin;M"INN\P:v׉UIWdsXw ` .;쬣arRPt'eשkydasXX(^)tHW(:k׮Eo>rѻwo ٥d]pU@@*N<S[[o~s…C+ύ9,ǣ氢DUBA~Yf 3fO?=j(d;&sUGʄ{jPt'Љ!7̸y}^`"1bK@"`F.g܇̟?o߾ 9Bq.1݉E! jժUu]6}G^׉UiUeB}DPq?Qۼy~ubڎ+tEBvBq¤ X5o=z7l0~xɓY`$Xʶ/D(X`ZLt' uPAuy~" & p2uiFuS!޿ҥK㩧 Ybz#Gp-}!C\G-ŠʠfF@Ѱ_tԻw޻w/ 8q":g4iDS\eځdAs=\9BBC"("0 (펥ǜ8;˗/,9,?,8Cf_!'|믿N~9|0 :y'?Ad!(D⊓Tt':*1n%cև~qƙ3g^DGT*Bvܹff/x`3ַ:)arHK@fi|5 IDATt'㶕+W7~=NpUW]Lv G!' pa[Z&9X}uVlPtnju"0BT2bcPM1R6떥JB <YŘ:ydܜ2e  DGACwX˖-332"lƌ'tO83R@# #\V3E?ߟ}&JDaQx@@ѝPAAB&e :Ceag+8EG/ɰC"͂޷'>*MLc!"^}U3@v`&wiÈ5Y(͎VюoNa¿۲wP-FNt4;xǗ!5Y櫫Xe3gzR#I.YsƕLH$xmĠ[N85 ]rZ{θ>x:eY^HQE P'Oy%xDuU !Қj*~ɐNN+π>zxX|nמSʐv5StFRWN㶢c5ݏV,l ^:-;!(ڒǻ~,_꒼jhC ;lHg~Y_؅_>ڶy[Fo̯u+mE҂j}/}{G qzp`W4lWWlG6v&+4ɠrٝ.Pv'3zƥFe"":P&`Ksw|vgr/|9?%"rд/Aߢ-71k~/Zd?PeOd\@meBpFϸHV16AADPQ-"XFQjo|Kۃ>JfO' Q }"mݍ(zLE*DaɈX BjND inT`A DmB#(":Tm1&<ւ/9B1`NWa$ڝe-EPUBw"U\'2ځ`qQ (7 сH'M<5pfݱOj?{Y-0#fV""\7dP&x]m h=;Y(MKңm47Yqa z`7 WS2މOϬi7VkeΗVT-uLwW!il M; fӎjͽsŁ\WbarjXXfM%#w>8۝8/Ͼq4-$Hu .  DDd -[]Sj%݉X9͛7^;$=ҢǠ̺ -z&[U̺iڇ-zW̽LZy>˚|m|S/f揰{~gVO>fb6\,kߴ,ٳ' $/u$$y54XN9l;'ضlg0 Od]eeed][*n'FiCk)[n5OLLxM6,۶3_jD+ND' @ C ~D;,MRI&NOYnǎgD=rlV 턹Wڝ&;~_}5K^^caW~o|:wYdo.$U-|sNn{IȌqOuՎ|bH3DY,]gkoy|| K?VwGTt|8-i~Cs`_!)l!wwkIw䐥P 5e7K~'q7IRܰ|vVhۍr;h #DD!n30faw Vfuʍp͠uǷ;u3 ͯ`=^߄l*\Or0Oә?H[)v;LNhqR{wg-/-xSkwQɼ@G2 %dF+JDDƒi~PǭI>YٝOmm P^`l[44x{ΛG#8<}frM-}rsOvϻi*Ta9s<{Me&IȽsG;~\b"X⋍6{Duws_Y]b#`ډ(%"u_C@MfY@Tr B@!5QB@!P(CYs-8&b'Gɕ[3OyaU<)d6*j{Q-)cT?X0h ;aÚpˆ y8ίvIDHСC%Hu'iBUWWw)U֯ˈnQlܩ2jrs$h;>f|>X62eTf86ތG}o5S[ U02j#1Tk%Qv`ӛܫ/}]7ٴ/^߰ξ CH쯫ΟI=J7“؝j TQfPBѐ`]UE-E{6OJfw9z9Jm".߉o&edr`t6Ю=Vrd %7J],%ݹ鞯H'%B~54HR?-Z|w }:~ @HFhH".t_t-';p'@b!FdHF.SNM6_;֎8OM6zhZj!xRFO3n$Z%Z4uF9\H?Q!uo޼>Zr%#&L8q"9i!8A,"" A? @w5':b?)Θ1I4C xo)V)x c r'!1{ףv-dT]dC~3 8tC~_̙3G}3H%T\b\ TIT?ЖGIFYYk2 ;x S8㌓O>Qq(MRm4"@=*!|չwMy]}xOpDt 's頺!DMQQ%,Aw@ZBu^Rv@j%rm?Q^^^LG[ />P3i?\4wsNM*&"pCzM`+pw_t|sPC ׾6waÆ$H &s $`*dRpRLYsړ_]Z>W*ꫯ~ 4{3gסȄ3f8Zi*vض!)P)'|wzf|tP N{;$@ʵZO+d4 +Ma7׿EnF9jijr!@Xt/3x֭[鐠>MlcO=ԫ QH&E#B&&/D \s/+(FP4QX(rhLp姦'8b4GBDb;v Xy7vj *Rb!TP1# =o`h[d $PluG_@&.s"aՋ/FCD9v,}X Ȃd$v]DRKf_W*9˘\x@nDW?_ฏ3XN,f,zד`<OKKAiU9kѝI$N^D7KI ^VaU`؉HCj{PPPrCp=OaĤGFtH:jP4g'Ť '=(T ?oCA;a0CQyhx`9r C]R@/R !$ {iao~Re1Utǀz\єk\I>z#VCԦYFڥ@tpG>S.1xϗ_~O# .k *Jļ#kw&PȲ83ϼ N?t2$rsS5GUJ qF(sYT;dQpR^Im|Dѝ)wK;[l7o-vT/I)G&ࠈ91e CaTHnzU2 RgR=HCz>|8,+_ ,9bcVP[8Pt=+x(\ evG#I> dff"ʈ4(chW2hT(D6V<~饗8Ucv( q9xN&=B}rGx Sbh=Yub׌ՍvC [/lAfι a H 9YN=ёI+Qa@A)\{R, Dg5TVB)Y4IP1 Ew^;fsE#UQ4]'P^$zUusQ3egnBBӃ}C~vM8ŪF>EL1Gyܔ1 2f:t{:G`q+DWp#[]8ছnbϟ#e ])wϰNX W1#e w'VL^#HY a;V+hi,x:,>' |#l/`9Mq~=,|ls2Y+P*cF&~)2 p<Ո% 3ay k2i%e|HU+grc`1ҳbd _1(: s*ܔF `*3ˁr r'O4UYCQAQP+(}5Zi*cXz66SNQ;YcA~!ENTp>#X/K@h04a<UJ >=iGoC)[J(cXhtutlrt(LX'I8-Fcڱpуu@hcK=`EIMN, tXkWH1`"qAv ݁#OY܇q:&`{"KCR:Dl۶#XW=?,rE T9Z oU O?47uHJ(2}nL9z( <ow&fk{)8Z׌8Y>w\{ D肑x;r}]s˜tdLGa9Tu3Q6F *OGQNʴ 8>5:f665"0dmxK R"}FO SYEA 2 ̍r,%6涮*xkQRu",6l7x֬YPy"blpـHyuVyG~_CTF8EY:ߕo#NsLb퓎 : ن痿%+r |A'ÑɪFI.ڵ-1`g~s~Ň\[ aDsPSr:0H<&3/V<2ߤ+N5%"K@&Ld(xHYO^Pt 4pc},LM30ꤓ`~pu£]9yPrwXa svѯ{PԳN #1̦r1"bT- <NcX{,'TH?m2ζ ,cTTEw:H: :-YF=aMo$Ն, Pxm4Yug° zC%veLfXRΉ0vg]̔)S :bcQ#N:4IX34;ݏyHAGͲ OiҘt t ݚ Y ̃+'H#k*<Ŝ}TsHP0&KX"91"pE{"&I+ Y&> $+0ƼVaIg}6݆j/J} =+wp"RsNs.‹ 8uN~1TN9PYUW^= 9O<6d=~Qoe29 PѝakT0&`A%}f*e"B)VI C"j ̑mz꩘vibrsǛ8rDw2Ergdv,8h(!YQW/Qd+W۷4a7.tR +=:>CYnRGR,Nh6 : qXHȪ+;QwEj S~K85)JqT&v'LZ.XڭheeN>bBe2|pt-Wlі If({0g.;W`N91A d4sLa 9 B蔪D H5f!X@>bO&FBw!*P!NphTh:,~a6=T=ܘ,9(ȉJס YƜ^L>1Rƍ.TQe(ة*H"=>V$1vƲe߾}z-vL%- ~8Wt'Z7Lz dfZ_~L:X7*eFGt-c`A3gιwxSr}Glۃ]3^漲 <;dV+@JlYres.ǰΡHb9chxU@ztKy:1{07B3j(Yr&G55@D#/*KۡQR&^ѝ(-$[6`; hUV1Q7I2(e_?`Ӷd =.GR+NMt{6Rhx!@5RV][U ?]Ht{oq ۛZbb[`6A8c%vL1s?<srL7Ɠcb$# o$cl Ю]ޒZRk[j\U׭[ꩪ[Ul@4]GKdyLAlO< ;Ls.n$Ma@p 022}MAKf?q Μ9jm8q{{1!F  z2_[\>74z݄՟GA{Iw}W@Ʃ&h$x/kx%Zu` h2,d6X͆g! $ۉ2>_g}[M O~>`. c4LYT6v\wU54]BrtV^e1NONsneH1g[&Eߔ#P']ofˍW]ל޶NGb<,ʨSqL'@]~'Ɏ(c͔o43 7\!L8A8x[ ZiiilټƻlҊ)>LyW2=PAar=.[u\,|l!LŭfkFWS#xE9ք΀'w$wNAI>%ڔ5-ٞ fU>=IΊr$ :f[ KJZd,y[|"kVS#*3hK1.r1ĝq?"^;HfÅ%Ú\_tyD(;|Ax nxhYL^XfvM_\j,wT.)JN&ȱ #Z܃Ç1Ʌ+Zf {pEY l6Za 3?.+t(1@ ZH` Y.(pZI'G .ڤu` mpA!Թle^NlI`f-l:qv ϥF,rĘt3nA!@٣r w2N5B6 25rؤu쫩sX"ZXcF{@&= i;jb Zj9..rchM תfWMiGo'tctJS.fL ;6JqVnè~8k9B_89Z[`vFr:Ur: IDAT^=69~5{\5PhB=V5|O+ Bك\̣\#[= LE +i6L751/n|E:$7tJ'U?/u,Ƨ5—ҩ@5@KgٺfLEĝ94+Ĥ>.wx|eU4…` 32F[va3%Ęḇ&b̓\<}Tݜ̋5NrƂkNՋZe7af?K}`V<{TxO`kyy9ܵkQ[ CaE Py b@=Avf=z`C->{`Yz:=,,XL+}N7D3|al`uQ&-$%!ڬG*{V~Z'퉑 ^8c84*UƤdd욃sNNd,.)X6ZBnH WUQv.PaF͐# rϱc_;sA3je/ ͛bӧtf,[B`\HYC)7vr nC)G]qudX=kHNB*`г&!/2;j1§]XʶuX"4`&%WK6}n~VBh`:3cz\TFmj}ZRtj1"ч5*|w]+읃5\]p!Af+ؒrf m[i 7ɩV6B{ 0?܃8b@sIBWtjSĮ.Tus2L,գjVHMq`5+6GA1(ĝ^C{2w=E}0p$=ؿխo}v{[$}Hi]etwFਟ {Z ظ Us-26 ڌnNM ^O#@VLFǫZ~%^Kae"E*\|QwY7% MШ>'3O> ~^^SWP`>$ L!qh\ 3jf\=ǏЃ\S{4>>+l2KC5I'x#sry3j<fluywS4T  togϮ YI1O|mʥ_@+ rvv6o CAt94Xr(=l @\0A"g\ Mw.+=+q,v$to"9&Hl3V3mFr-,8gĝTs[;2B42):@Իo|od SXCswb ?٤U6lV=PiFLÌ!A<=pX}إ3l;pPc&oii,"m$_ Fu^h>,_>m A{'p|߮V{$3$̚>{$;SWOzK ;H9BJuk=LAM{ɳ7˘7mĆwvy˙9%ZU4G wRNo^xJ/|QK+}[GJVtyd -6?slKSҶh#ѽ]Q\rsm [Y;~*;2&e}Q'K?}dnr,m !uN Q `W8e~.ys w]na~(`L ʺ5(r|{Wn sT19"WVT}hS*XȒ%K-[Qj㋻۽aF g-؈tN1zE]6vBG4F&=ֱ7r7ŇL帝W<~p=Lʺ=͋o^T|ēِuVR424WZ;g'ǥl{9G? <;EkL }#˫Z[[2^[a%vN]냖ϖ7ⱸX3]IdV8ˀI9+?mܐQk~A~YiWh̓K2{ -"[9S@2peqOr1౵K?~~˘~C87?R..=\)){jvrr |dIqك'[9..cn-i̬Yw`ǮN}> z('XnT)ݝt骵n0t Ԇ.nŒ@ s{ 6aE ~e;!nEIh*7hq l$:V]/>>K0he=+P muMA#?/'[}'SCll4pf qW)uB-GeTMNYZ=hAR^P {vCS8dΗ7߿iuDz~]c, [<!g|#'!8T8{ϗ({`:CacjCZm%У,{]3 [?i2hבxL#W)86nWf0@jpnWm_U\lh1QXg3=IwNg ӊҚOU?%EVy+_QgFxnn~\\k0/=Ls{l"C~UŹ=kHq*l=ӵmkZ/\ki\!Dݖ;X-x|h<Ϲ{E>WM[-_m*Z{r$zNzE\i1We,Jx F=)M͹97z{]5ă6B/4KZ3k[QLLwI R#7{?:_YyCCoj,n pb_wAKA+`XxeI_,ߵ@wVvq]Jg5{zǦ5yct#^'ܕD2l;~+~ݪnEAA |w鈕{ZV`Wn`"Ǧm۶vAp٬m#)k9'T bu6rj8aHo/ tN_iѪ[uwbkn)2)N྽eݨDrϯ*:"߸v,hUrWQr箈\.{=5.6S6P\KUkP]Rfnu*w'=t>#a!T7Dux~^<A$WwfW [ϕU0ߙ5jd:Hn J[|Ctyf5ْ&`ŀ x!M<e +c#{Ao1~T-8}2s8wXL]0`Uozݳ? EXBk=8 xd-ZPSYSYy;ႥՑd/aYⅲ?QdYW0 ʒpSe8 **Do%5w?SE!k+ީ=B@<~e/J7,jJ30-F~ UEBw?;kzMCf}Jq5xp@N!1ǧeO܋/_//}kbt n񪁢Ծ_׍ăPֈ3=zE)ߌxC3QgKG.! pBȊèu{^;/; B'[=}<&6^huIc?$|Cn__tV1P8v=8t:9r#zNQ,J5=hJ(J^~ʩ܊u :3,>% a({OK_5HG 93ZzVî/ySweo>Xrm:9 #3 ԥ5_r݆xlYdN^P,,>]Eseoٽ9hzr }G9$n}9FMɊ5rI P5XBa/SZ^43Y7tYzĚKϺUK?޳D+eK!|,:2uVݳg6T3Y{=kҽW]NnA}sȌzfdQp%{,i^;kH6uX4*~ ;V{̕o40N?qd2[/s=[^G- 0 fî<&b /[ohNeV4ro1A1Y}|hSjm *eo* HM_:p:gf(uV?u8˪s%PpE/ڸGX1m  ҇STx"`r8.Wk~9P;uHo+/9J:j*Pn( Ψn132P9Klu 8YFnv󰾯 |yϦrB!<|t\8:(Uo;LСzh읃cjm&u?h8UZOշU 'XfP>+܇LOFFvF %Z_䚑j7&ZI69qng Ga)L*R/$԰SE "մ FƍܤC?#Ff* v̡%iwbS4)XkRIS*(vB U3y'#FewbX8F*Ӎ16 R;M_g+b1\g^ZRoC&z4l^- !`FeZ'(|c#Vm IDAT! BЎI,UVhl>FI3{ϵ3V<ͤKߜߚC2> }X%9!JS!j{ G &**;A#SH`r+0+;HCN a8s٣oV"mof鯕BOrXO SqzhyaC9B?azMv;33t+(\hX#9=x8 'n$97uI6E߹wKpp9[煙¼d>...&&b`AI|rNJ5S܁j_-y(z2I)G&h8|f̷z.\RM7Y_SoLAlCI-/6LÁ欼ntOx[W^˟bBUqQϱǃJ!G[w?oE5lJ?/I_߹Y'g B[럗9S\)Rk ]8W^L5vdM^_s^bf BUJG~yzdL"aiO}\?HEk*R-;\tt4d TϓTn!:h(+[Veq=zƢtʃݮvH的fXCxWswf1 6aisYx9^]q=S x|Qfs\e8|Sꗍ<=yO>/_MFlr:d|õ"Tw$ybcfnV+QۀY!@aBFQm%[;qfB+:\Qa(h2SĆSi}׷VO>}Wm-Sp>|uՂ劀 Ce͉Jćf8uҧW0eƒOvqhHSxCP~yu_;Y䝍O8`w牷^..o~ELO&Tě/RITKƉ&}jaicM0cF`?*=k3aMc]?AS`SJv[3d Q\q* U7n:SbX1"^/W_*} ;$e0KLLamt)~Tcd91 Gy/ٽgCD D# 4~( -}\-5aVɭbԽ45X?'p'y걙7 +\1qU,?޺^+(|Xl87?>Dyt+]{^>1ݗv]4[mG<+{8{מ .OeW`ކ|XzDm+f2OZiz#/s m(V/vvJyjQj cdv|됆OGKm2&Y셾Z5&S6ׁFWf:BB#@KDŽ"Tf:E+]Ż8nOU1! o/é5ru 6rlIx[(&iќap`I)ʇjWc#aխk ,=v C>菖4 cee;lxuo;wv,۽l {׷RV\Nd߳x܁Ű฼ ݗµk"'U**JKvo_f$p,)JJvvEZ*9/_Y_={Rd:6撮vun]e?ޢK4x:D"r0{cJPpp'tqy>xÅO-J Z D(\HuXn0L*--bYN6l8ᢢ 4Bd+ BHrm;1*NB|M|P}b5<򻧻d[vwQ܆YgXDe;5ZNNvt%f~]: ~RK׈M$Զ% ͷ'ʆ: )))IIIl 36UT;5ͮ0obcOB8! A _Zd[~j~{ n: b\]NJ.9sNO,ױ4Ź49?35Vl@ cF'p*7;27lMqmI^qx\,TJ3=1x}o/W(nU ў#o~t:V/9 e&5n/- [ԣ{jx'{|U6UYplR)-\NKB ]Իuwm*geJ*cWbR+V(QSOgԟuG | >WmFE"N'p)q4:! NNЙL`4M!^SZC#hwz3Ne}J%6"ەTO7TYgSQ]ON~ u(#6/ۍGR];|FΎ.HpFaIڝ@p`)qs-:D)b,fj5ſ{'jH-Y69hbCs,W¤[WKbW;՟,Ӌ-xOYm*WN˘ WV}'vk߹[7)N?WQ"tY+no]ƇRHh^p̈3|||7 0z!±ڂ nlb_{c4m0i\fM<oZKG1>lY8&w't*[Cn*fɦ]U>\llJxENW_"jnB];ѥc0[͔6]+Zvl j4e8_1Hr`("bJMC NhhpoHiჺTÇoNݶnCnA&(*F^\ll2p6ƺ9xnQpF>b} m4,g1f9q /?ֹZnq{K =0O?=Pĕs\>Xd7]xRc#ĝ`JļW~1n_˴ua=Ekr]][=<"8Dj^4BiP0@m߾+{ ^?FmyҍPٸ7 Hl# Lim9T+*1* Bs}aFy*68qyVgI a: <[vl}lhɏ6 N'&ӵdͿK#}xBzT3 Oɫ&Õ1IaE^'=I"}AjKr0-m<%0:#R*=m5/t_cS9cw`=?znbW[z3 +znª`/IUQ&ߝ BPvkl?5?~|gCVhUbu3H{\7a5!{%d?-YtbeH?43-=w%x@AYi4cV7SYESJ\3N^GBW8;m8&ǜe0+^}e]Mw\.dIv{ s`7욃v[40 퍍4чm\+KQ^Pq vTYq⚈uvA朥/#LLBIK%VDJ>*(F'(%0Z ܄hT"$Tc7EL@$EߕԹ Uvůr䙘 4%VjKg.^̍7|pe fΆSRq&fY\|K ubOg):ԻֱTkj=d]۲fӁ HDϞQӲe?`|͕lzVؑ6J.&|)h26S -jP j uJ!.Lݗ:{쪈wZ 1/YU%yf/0?L}18e~dVhdhs,auhFcGJBKԇUqi\N;_b?d/m|JeajӏbiC.d"ur^QM|T57m.PU6S*q8n]3 4vmHȭgNϴcl,|BYCQ]OOh[etq}o {V?iO~{ Olw a5rU@oJr3[ZDbM !@?q2 ^BcMBN-LҢ_ T&!\/FYӏ<J(Y^,FZDxO77TliB6ߤ1 Lx #&q];5 ;Obx{ppMlHPꑱp=`F dz#.۸wƂ^_NOws+{r.ێǜufwا32*ڴ{ˆp֨'Xz%%Zp>穽[XR>yM .Kue)C܁jKkB@B`{d%JmN7_hqڷ/BUlɯh8]RxN[-|͕`(M B6obd.yjjJ߿daZzW$0<~'Duvv\.<B*\hn%K0vghfcysk%Y$.ڠ8EgMu8 w s^>ff54 㡱-XxBE+p !9k1>)` WݗkmXPS VGh#77֝f!+ `0m PF x4B0N`p&ܒէsz%JMzM8TD9zEl1mY\YPv, #!^ԫvCsuNBJ*#(3DZY6gGf!@-o\Uj{nlgU0s$ DD\p } =:Ge_ {ZM=joFǯ=2ӘQW3z47N2PH mugU>N>IW@t:NNRϙ\s ;#L3hztI:(ƛѝQ>f6`zj7$ 2 @[LarN#8& s  |A5[m2V@UEzhbp֩5mbUwETgcAdxn9\FN ZFGgrO !H*(ч,F{2 ;B+mbäflQ{rmT!kf5s˕9 $넱Jĝ!8&0Õ9nDf!EGnor݂-Eq@LXdQYv]Ep)(JJ4eGjrs:e쒌n2r5`wT[q)y853Yg/G"4 dWt뻙@4*`Q"TݖSΨ(t}zhgaG`7IfOx+8Ac~64wJMr[W<"MO0Ң&@2*'E^6|a2Jv838}8 9&u1dGGr:fpܭ)0Qvn~~Ğk}[S0rrQX>M0~Qg7qvfQـi )32's:A`WumlBjLcy_I`48M1Lq1J5"! XB|ksZᲘ[S3x"9Wh)cdb3ҊW8eEK2zX> *2AՓ_ïdL<g1z_Yy):8dp<0 a%KΈR"X8`#9;p 8;;>k;N0tc'<1a< &·˅qvc+s>wKtn %xFyJe4sI'8XEΏAUp,& }S0Fcq X{; V?FA{k莪sf8Y L~{"SxQקO@Oya?/F 4cNwip:kaN!`଼B0饁qpF nxeĝQȐJ% x Nӹ\vtx:t!;ˎ[ p>(@ 8(*ccW|^@mwYX/ eg21?Gƀ,Q1lT~V:@l>Kcx0!:-u^kGkbWf,/J8,c#]O{^kx-ghA!+/! F@ ڳqAĝ®: 8EQ DŽp_`56kduaUncAl[sW:j +[2׳3]_0JlQRg͈XM2N9aA@kt uȣ(؀9āCKvFhru^آɆv?`xEuX|=1 sZtr>/69RvFYyc11_僮/:J7"=sNO-Hg&#gz VJ'xg<1Qʡ`;!P( "kHIidH8] #;v]/>,"@S [,1xl䪓:‹fNxk jW 9QMV1_^uq0ObX㥾NBwMvfE(OL ܕMTo0rXxXRǘޓ(:HAI!,8#*5w N`IqFjk#8 'AtP[8 @8>W2B@?'Y5>~žҨAKB8&%~B]8Fx%;$[I5FMQƙ*S2p@dXEeA⿌-ػ Tx7DGk$nXYGzuF?/lgg5BuvwP#\I<0RB@Nлɠ/T]"UF! q?&҅8\E6iħyp 1Y|ve2bծ)8&0R ktRc1lW.!@ .Ø! <£]Y33!B_ A "+t=U7V{&*$LԚ|k$rad+]UZ $d $&,yw tX cYvz!@A@gW1*C4Ժ3슎DhW-2R` ҕwnAPN"=1B\ڕ=NWB(Ύ\2e𳎯y4vWC$.Fv 8{:6640 Where ```` is your controller's IP address that is accessible via the Host Machine's eth0 interface. Simulating an NVC ----------------- A VTEP implementation expects to be driven by a Network Virtualization Controller (NVC), such as NSX. If one does not exist, it's possible to use vtep-ctl to simulate one: 1. Create a logical switch: :: $ vtep-ctl add-ls ls0 2. Bind the logical switch to a port: :: $ vtep-ctl bind-ls br0 p0 0 ls0 $ vtep-ctl set Logical_Switch ls0 tunnel_key=33 3. Direct unknown destinations out a tunnel. For handling L2 broadcast, multicast and unknown unicast traffic, packets can be sent to all members of a logical switch referenced by a physical switch. The "unknown-dst" address below is used to represent these packets. There are different modes to replicate the packets. The default mode of replication is to send the traffic to a service node, which can be a hypervisor, server or appliance, and let the service node handle replication to other transport nodes (hypervisors or other VTEP physical switches). This mode is called *service node* replication. An alternate mode of replication, called *source node* replication, involves the source node sending to all other transport nodes. Hypervisors are always responsible for doing their own replication for locally attached VMs in both modes. Service node mode is the default. Service node replication mode is considered a basic requirement because it only requires sending the packet to a single transport node. The following configuration is for service node replication mode as only a single transport node destination is specified for the unknown-dst address: :: $ vtep-ctl add-mcast-remote ls0 unknown-dst 10.2.2.2 4. Optionally, change the replication mode from a default of ``service_node`` to ``source_node``, which can be done at the logical switch level: :: $ vtep-ctl set-replication-mode ls0 source_node 5. Direct unicast destinations out a different tunnel: :: $ vtep-ctl add-ucast-remote ls0 00:11:22:33:44:55 10.2.2.3 ovs-2.13.0/Documentation/index.rst000066400000000000000000000100071362155554400170660ustar00rootroot00000000000000.. 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. ========================== Open vSwitch Documentation ========================== How the Documentation is Organised ---------------------------------- The Open vSwitch documentation is organised into multiple sections: - :doc:`Installation guides ` guide you through installing Open vSwitch (OVS) on a variety of different platforms - :doc:`Tutorials ` take you through a series of steps to configure OVS in sandboxed environments - :doc:`Topic guides ` provide a high level overview of OVS internals and operation - :doc:`How-to guides ` are recipes or use-cases for OVS. They are more advanced than the tutorials. - :doc:`Frequently Asked Questions ` provide general insight into a variety of topics related to configuration and operation of OVS. First Steps ----------- Getting started with Open vSwitch (OVS)? Start here. - **Overview:** :doc:`intro/what-is-ovs` | :doc:`intro/why-ovs` - **Install:** :doc:`intro/install/general` | :doc:`intro/install/userspace` | :doc:`intro/install/netbsd` | :doc:`intro/install/windows` | :doc:`intro/install/xenserver` | :doc:`intro/install/dpdk` | :doc:`intro/install/afxdp` | :doc:`Installation FAQs ` - **Tutorials:** :doc:`tutorials/faucet` | :doc:`tutorials/ovs-advanced` | :doc:`tutorials/ovs-conntrack` | :doc:`tutorials/ipsec` | Deeper Dive ----------- - **Architecture** :doc:`topics/design` | :doc:`topics/openflow` | :doc:`topics/integration` | :doc:`topics/porting` | :doc:`topics/ovs-extensions` - **DPDK** :doc:`howto/dpdk` | :doc:`topics/dpdk/vhost-user` - **Windows** :doc:`topics/windows` - **Integrations:** :doc:`topics/language-bindings` - **Reference Guides:** :doc:`ref/index` - **Testing** :doc:`topics/testing` :doc:`topics/fuzzing/index` - **Packaging:** :doc:`intro/install/debian` | :doc:`intro/install/rhel` | :doc:`intro/install/fedora` The Open vSwitch Project ------------------------ Learn more about the Open vSwitch project and about how you can contribute: - **Community:** :doc:`internals/release-process` | :doc:`internals/authors` | :doc:`internals/mailing-lists` | :doc:`internals/patchwork` | :doc:`internals/bugs` | :doc:`internals/security` - **Contributing:** :doc:`internals/contributing/submitting-patches` | :doc:`internals/contributing/backporting-patches` | :doc:`internals/contributing/coding-style` | :doc:`internals/contributing/coding-style-windows` - **Maintaining:** :doc:`internals/charter` | :doc:`internals/maintainers` | :doc:`internals/committer-responsibilities` | :doc:`internals/committer-grant-revocation` | :doc:`internals/committer-emeritus-status` - **Documentation:** :doc:`internals/contributing/documentation-style` | :doc:`Building Open vSwitch Documentation ` | :doc:`internals/documentation` Getting Help ------------- - Seeing an issue of potential bug? Report problems to bugs@openvswitch.org - Looking for specific information? Try the :ref:`genindex`, :ref:`modindex` or the :doc:`detailed table of contents `. ovs-2.13.0/Documentation/internals/000077500000000000000000000000001362155554400172265ustar00rootroot00000000000000ovs-2.13.0/Documentation/internals/authors.rst000066400000000000000000000016121362155554400214450ustar00rootroot00000000000000.. 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. .. include:: ../../AUTHORS.rst ovs-2.13.0/Documentation/internals/bugs.rst000066400000000000000000000047551362155554400207330ustar00rootroot00000000000000.. 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. ============================== Reporting Bugs in Open vSwitch ============================== We are eager to hear from users about problems that they have encountered with Open vSwitch. This file documents how best to report bugs so as to ensure that they can be fixed as quickly as possible. Please report bugs by sending email to bugs@openvswitch.org. For reporting security vulnerabilities, please read :doc:`security`. The most important parts of your bug report are the following: - What you did that make the problem appear. - What you expected to happen. - What actually happened. Please also include the following information: - The Open vSwitch version number (as output by ``ovs-vswitchd --version``). - The Git commit number (as output by ``git rev-parse HEAD``), if you built from a Git snapshot. - Any local patches or changes you have applied (if any). The following are also handy sometimes: - The kernel version on which Open vSwitch is running (from ``/proc/version``) and the distribution and version number of your OS (e.g. "Centos 5.0"). - The contents of the vswitchd configuration database (usually ``/etc/openvswitch/conf.db``). - The output of ``ovs-dpctl show``. - If you have Open vSwitch configured to connect to an OpenFlow controller, the output of ``ovs-ofctl show `` for each ```` configured in the vswitchd configuration database. - A fix or workaround, if you have one. - Any other information that you think might be relevant. .. important:: bugs@openvswitch.org is a public mailing list, to which anyone can subscribe, so do not include confidential information in your bug report. ovs-2.13.0/Documentation/internals/charter.rst000066400000000000000000000206571362155554400214220ustar00rootroot00000000000000The Linux Foundation Open vSwitch Project Charter ================================================= Effective August 9, 2016 1. Mission of Open vSwitch Project (“OVS”). The mission of OVS is to: a. create an open source, production quality virtual networking platform, including a software switch, control plane, and related components, that supports standard management interfaces and opens the forwarding functions to programmatic extension and control; and b. host the infrastructure for an OVS community, establishing a neutral home for community assets, infrastructure, meetings, events and collaborative discussions. 2. Technical Steering Committee (“TSC”) a. A TSC shall be composed of the Committers for OVS. The list of Committers on the TSC are available at :doc:`/internals/maintainers`. b. TSC projects generally will involve Committers and Contributors: i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the OVS codebase. ii. Committers: Contributors who have the ability to commit directly to a project’s main branch or repository on an OVS project. c. Participation in as a Contributor and/or Committer is open to anyone under the terms of this Charter. The TSC may: i. establish work flows and procedures for the submission, approval and closure or archiving of projects, ii. establish criteria and processes for the promotion of Contributors to Committer status, available at :doc:`/internals/committer-grant-revocation`. and iii. amend, adjust and refine the roles of Contributors and Committers listed in Section 2.b., create new roles and publicly document responsibilities and expectations for such roles, as it sees fit, available at :doc:`/internals/committer-responsibilities`. d. Responsibilities: The TSC is responsible for overseeing OVS activities and making decisions that impact the mission of OVS, including: i. coordinating the technical direction of OVS; ii. approving project proposals (including, but not limited to, incubation, deprecation and changes to a project’s charter or scope); iii. creating sub-committees or working groups to focus on cross-project technical issues and requirements; iv. communicating with external and industry organizations concerning OVS technical matters; v. appointing representatives to work with other open source or standards communities; vi. establishing community norms, workflows or policies including processes for contributing (available at :doc:`/internals/contributing/index`), issuing releases, and security issue reporting policies; vii. discussing, seeking consensus, and where necessary, voting on technical matters relating to the code base that affect multiple projects; and viii. coordinate any marketing, events or communications with The Linux Foundation. 3. TSC Voting a. While it is the goal of OVS to operate as a consensus based community, if any TSC decision requires a vote to move forward, the Committers shall vote on a one vote per Committer basis. b. TSC votes should be conducted by email. In the case of a TSC meeting where a valid vote is taken, the details of the vote and any discussion should be subsequently documented for the community (e.g. to the appropriate email mailing list). c. Quorum for TSC meetings shall require two-thirds of the TSC representatives. The TSC may continue to meet if quorum is not met, but shall be prevented from making any decisions requiring a vote at the meeting. d. Except as provided in Section 8.d. and 9.a., decisions by electronic vote (e.g. email) shall require a majority of all voting TSC representatives. Decisions by electronic vote shall be made timely, and unless specified otherwise, within three (3) business days. Except as provided in Section 8.d. and 9.a., decisions by vote at a meeting shall require a majority vote, provided quorum is met. e. In the event of a tied vote with respect to an action that cannot be resolved by the TSC, any TSC representative shall be entitled to refer the matter to the Linux Foundation for assistance in reaching a decision. 4. Antitrust Guidelines a. All participants in OVS shall abide by The Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. b. All members shall encourage open participation from any organization able to meet the participation requirements, regardless of competitive interests. Put another way, the community shall not seek to exclude any participant based on any criteria, requirements or reasons other than those that are reasonable and applied on a non-discriminatory basis to all participants. 5. Code of Conduct a. The TSC may adopt a specific OVS Project code of conduct, with approval from the LF. 6. Budget and Funding a. The TSC shall coordinate any budget or funding needs with The Linux Foundation. Companies participating may be solicited to sponsor OVS activities and infrastructure needs on a voluntary basis. b. The Linux Foundation shall have custody of and final authority over the usage of any fees, funds and other cash receipts. c. A General & Administrative (G&A) fee will be applied by the Linux Foundation to funds raised to cover Finance, Accounting, and operations. The G&A fee shall equal 9% of OVS’s first $1,000,000 of gross receipts and 6% of OVS’s gross receipts over $1,000,000. d. Under no circumstances shall The Linux Foundation be expected or required to undertake any action on behalf of OVS that is inconsistent with the tax exempt purpose of The Linux Foundation. 7. General Rules and Operations. The OVS project shall be conducted so as to: a. engage in the work of the project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of The Linux Foundation in the open source software community; b. respect the rights of all trademark owners, including any branding and usage guidelines; c. engage The Linux Foundation for all OVS press and analyst relations activities; d. upon request, provide information regarding Project participation, including information regarding attendance at Project-sponsored events, to The Linux Foundation; and e. coordinate with The Linux Foundation in relation to any websites created directly for OVS. 8. Intellectual Property Policy a. Members agree that all new inbound code contributions to OVS shall be made under the Apache License, Version 2.0 (available at http://www.apache.org/licenses/LICENSE-2.0). All contributions shall be accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org) that is submitted through a TSC and LF-approved contribution process. b. All outbound code will be made available under the Apache License, Version 2.0. c. All documentation will be contributed to and made available by OVS under the Apache License, Version 2.0. d. For any new project source code, if an alternative inbound or outbound license is required for compliance with the license for a leveraged open source project (e.g. GPLv2 for Linux kernel) or is otherwise required to achieve OVS’s mission, the TSC may approve the use of an alternative license for specific inbound or outbound contributions on an exception basis. Any exceptions must be approved by a majority vote of the entire TSC and must be limited in scope to what is required for such purpose. Please email tsc@openvswitch.org to obtain exception approval. e. Subject to available funds, OVS may engage The Linux Foundation to determine the availability of, and register, trademarks, service marks, which shall be owned by the LF. 9. Amendments a. This charter may be amended by a two-thirds vote of the entire TSC, subject to approval by The Linux Foundation. ovs-2.13.0/Documentation/internals/committer-emeritus-status.rst000066400000000000000000000054001362155554400251360ustar00rootroot00000000000000.. 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. ================================== Emeritus Status for OVS Committers ================================== OVS committers are nominated and elected based on their impact on the Open vSwitch project. Over time, as committers' responsibilities change, some may become unable or uninterested in actively participating in project governance. Committer "emeritus" status provides a way for committers to take a leave of absence from OVS governance responsibilities. The following guidelines clarify the process around the emeritus status for committers: * A committer may choose to transition from active to emeritus, or from emeritus to active, by sending an email to the committers mailing list. * If a committer hasn't been heard from in 6 months, and does not respond to reasonable attempts to contact him or her, the other committers can vote as a majority to transition the committer from active to emeritus. (If the committer resurfaces, he or she can transition back to active by sending an email to the committers mailing list.) * Emeritus committers may stay on the committers mailing list to continue to follow any discussions there. * Emeritus committers do not nominate or vote in committer elections. From a governance perspective, they are equivalent to a non-committer. * Emeritus committers cannot merge patches to the OVS repository. * Emeritus committers will be listed in a separate section in the MAINTAINERS.rst file to continue to recognize their contributions to the project. Emeritus status does not replace the procedures for forcibly removing a committer. Note that just because a committer is not able to work on the project on a day-to-day basis, we feel they are still capable of providing input on the direction of the project. No committer should feel pressured to move themselves to this status. Again, it's just an option for those that do not currently have the time or interest. ovs-2.13.0/Documentation/internals/committer-grant-revocation.rst000066400000000000000000000332771362155554400252570ustar00rootroot00000000000000.. 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 Committer Grant/Revocation Policy ===================================== An OVS committer is a participant in the project with the ability to commit code directly to the master repository. Commit access grants a broad ability to affect the progress of the project as presented by its most important artifact, the code and related resources that produce working binaries of Open vSwitch. As such it represents a significant level of trust in an individual's commitment to working with other committers and the community at large for the benefit of the project. It can not be granted lightly and, in the worst case, must be revocable if the trust placed in an individual was inappropriate. This document suggests guidelines for granting and revoking commit access. It is intended to provide a framework for evaluation of such decisions without specifying deterministic rules that wouldn't be sensitive to the nuance of specific situations. In the end the decision to grant or revoke committer privileges is a judgment call made by the existing set of committers. Granting Commit Access ---------------------- Granting commit access should be considered when a candidate has demonstrated the following in their interaction with the project: - Contribution of significant new features through the patch submission process where: - Submissions are free of obvious critical defects - Submissions do not typically require many iterations of improvement to be accepted - Consistent participation in code review of other's patches, including existing committers, with comments consistent with the overall project standards - Assistance to those in the community who are less knowledgeable through active participation in project forums such as the ovs-discuss mailing list. - Plans for sustained contribution to the project compatible with the project's direction as viewed by current committers. - Commitment to meet the expectations described in the "Expectations of Developer's with Open vSwitch Access" The process to grant commit access to a candidate is simple: - An existing committer nominates the candidate by sending an email to all existing committers with information substantiating the contributions of the candidate in the areas described above. - All existing committers discuss the pros and cons of granting commit access to the candidate in the email thread. - When the discussion has converged or a reasonable time has elapsed without discussion developing (e.g. a few business days) the nominator calls for a final decision on the candidate with a followup email to the thread. - Each committer may vote yes, no, or abstain by replying to the email thread. A failure to reply is an implicit abstention. - After votes from all existing committers have been collected or a reasonable time has elapsed for them to be provided (e.g. a couple of business days) the votes are evaluated. To be granted commit access the candidate must receive yes votes from a majority of the existing committers and zero no votes. Since a no vote is effectively a veto of the candidate it should be accompanied by a reason for the vote. - The nominator summarizes the result of the vote in an email to all existing committers. - If the vote to grant commit access passed, the candidate is contacted with an invitation to become a committer to the project which asks them to agree to the committer expectations documented on the project web site. - If the candidate agrees access is granted by setting up commit access to the repos on github. Revoking Commit Access ---------------------- When a committer behaves in a manner that other committers view as detrimental to the future of the project, it raises a delicate situation with the potential for the creation of division within the greater community. These situations should be handled with care. The process in this case is: - Discuss the behavior of concern with the individual privately and explain why you believe it is detrimental to the project. Stick to the facts and keep the email professional. Avoid personal attacks and the temptation to hypothesize about unknowable information such as the other's motivations. Make it clear that you would prefer not to discuss the behavior more widely but will have to raise it with other contributors if it does not change. Ideally the behavior is eliminated and no further action is required. If not, - Start an email thread with all committers, including the source of the behavior, describing the behavior and the reason it is detrimental to the project. The message should have the same tone as the private discussion and should generally repeat the same points covered in that discussion. The person whose behavior is being questioned should not be surprised by anything presented in this discussion. Ideally the wider discussion provides more perspective to all participants and the issue is resolved. If not, - Start an email thread with all committers except the source of the detrimental behavior requesting a vote on revocation of commit rights. Cite the discussion among all committers and describe all the reasons why it was not resolved satisfactorily. This email should be carefully written with the knowledge that the reasoning it contains may be published to the larger community to justify the decision. - Each committer may vote yes, no, or abstain by replying to the email thread. A failure to reply is an implicit abstention. - After all votes have been collected or a reasonable time has elapsed for them to be provided (e.g. a couple of business days) the votes are evaluated. For the request to revoke commit access for the candidate to pass it must receive yes votes from two thirds of the existing committers. - anyone that votes no must provide their reasoning, and - if the proposal passes then counter-arguments for the reasoning in no votes should also be documented along with the initial reasons the revocation was proposed. Ideally there should be no new counter-arguments supplied in a no vote as all concerns should have surfaced in the discussion before the vote. - The original person to propose revocation summarizes the result of the vote in an email to all existing committers excepting the candidate for removal. - If the vote to revoke commit access passes, access is removed and the candidate for revocation is informed of that fact and the reasons for it as documented in the email requesting the revocation vote. - Ideally the revoked committer peacefully leaves the community and no further action is required. However, there is a distinct possibility that he/she will try to generate support for his/her point of view within the larger community. In this case the reasoning for removing commit access as described in the request for a vote will be published to the community. Changing the Policy ------------------- The process for changing the policy is: - Propose the changes to the policy in an email to all current committers and request discussion. - After an appropriate period of discussion (a few days) update the proposal based on feedback if required and resend it to all current committers with a request for a formal vote. - After all votes have been collected or a reasonable time has elapsed for them to be provided (e.g. a couple of business days) the votes are evaluated. For the request to modify the policy to pass it must receive yes votes from two thirds of the existing committers. Template Emails =============== Nomination to Grant Commit Access --------------------------------- I would like to nominate *[candidate]* for commit access. I believe *[he/she]* has met the conditions for commit access described in the committer grant policy on the project web site in the following ways: *[list of requirements & evidence]* Please reply to all in this message thread with your comments and questions. If that discussion concludes favorably I will request a formal vote on the nomination in a few days. Vote to Grant Commit Access --------------------------- I nominated *[candidate]* for commit access on *[date]*. Having allowed sufficient time for discussion it's now time to formally vote on the proposal. Please reply to all in this thread with your vote of: YES, NO, or ABSTAIN. A failure to reply will be counted as an abstention. If you vote NO, by our policy you must include the reasons for that vote in your reply. The deadline for votes is *[date and time]*. If a majority of committers vote YES and there are zero NO votes commit access will be granted. Vote Results for Grant of Commit Access --------------------------------------- The voting period for granting to commit access to *[candidate]* initiated at *[date and time]* is now closed with the following results: YES: *[count of yes votes]* (*[% of voters]*) NO: *[count of no votes]* (*[% of voters]*) ABSTAIN: *[count of abstentions]* (*[% of voters]*) Based on these results commit access *[is/is NOT]* granted. Invitation to Accepted Committer -------------------------------- Due to your sustained contributions to the Open vSwitch (OVS) project we would like to provide you with commit access to the project repository. Developers with commit access must agree to fulfill specific responsibilities described in the source repository: /Documentation/internals/committer-responsibilities.rst Please let us know if you would like to accept commit access and if so that you agree to fulfill these responsibilities. Once we receive your response we'll set up access. We're looking forward continuing to work together to advance the Open vSwitch project. Proposal to Revoke Commit Access for Detrimental Behavior --------------------------------------------------------- I regret that I feel compelled to propose revocation of commit access for *[candidate]*. I have privately discussed with *[him/her]* the following reasons I believe *[his/her]* actions are detrimental to the project and we have failed to come to a mutual understanding: *[List of reasons and supporting evidence]* Please reply to all in this thread with your thoughts on this proposal. I plan to formally propose a vote on the proposal on or after *[date and time]*. It is important to get all discussion points both for and against the proposal on the table during the discussion period prior to the vote. Please make it a high priority to respond to this proposal with your thoughts. Vote to Revoke Commit Access ---------------------------- I nominated *[candidate]* for revocation of commit access on *[date]*. Having allowed sufficient time for discussion it's now time to formally vote on the proposal. Please reply to all in this thread with your vote of: YES, NO, or ABSTAIN. A failure to reply will be counted as an abstention. If you vote NO, by our policy you must include the reasons for that vote in your reply. The deadline for votes is *[date and time]*. If 2/3rds of committers vote YES commit access will be revoked. The following reasons for revocation have been given in the original proposal or during discussion: *[list of reasons to remove access]* The following reasons for retaining access were discussed: *[list of reasons to retain access]* The counter-argument for each reason for retaining access is: *[list of counter-arguments for retaining access]* Vote Results for Revocation of Commit Access -------------------------------------------- The voting period for revoking the commit access of *[candidate]* initiated at *[date and time]* is now closed with the following results: - YES: *[count of yes votes]* (*[% of voters]*) - NO: *[count of no votes]* (*[% of voters]*) - ABSTAIN: *[count of abstentions]* (*[% of voters]*) Based on these results commit access *[is/is NOT]* revoked. The following reasons for retaining commit access were proposed in NO votes: *[list of reasons]* The counter-arguments for each of these reasons are: *[list of counter-arguments]* Notification of Commit Revocation for Detrimental Behavior ---------------------------------------------------------- After private discussion with you and careful consideration of the situation, the other committers to the Open vSwitch (OVS) project have concluded that it is in the best interest of the project that your commit access to the project repositories be revoked and this has now occurred. The reasons for this decision are: *[list of reasons for removing access]* While your goals and those of the project no longer appear to be aligned we greatly appreciate all the work you have done for the project and wish you continued success in your future work. ovs-2.13.0/Documentation/internals/committer-responsibilities.rst000066400000000000000000000126071362155554400253560ustar00rootroot00000000000000.. 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. ========================================================= Expectations for Developers with Open vSwitch Repo Access ========================================================= Pre-requisites -------------- Be familiar with the guidelines and standards defined in :doc:`contributing/index`. Review ------ Code (yours or others') must be reviewed publicly (by you or others) before you push it to the repository. With one exception (see below), every change needs at least one review. If one or more people know an area of code particularly well, code that affects that area should ordinarily get a review from one of them. The riskier, more subtle, or more complicated the change, the more careful the review required. When a change needs careful review, use good judgment regarding the quality of reviews. If a change adds 1000 lines of new code, and a review posted 5 minutes later says just "Looks good," then this is probably not a quality review. (The size of a change is correlated with the amount of care needed in review, but it is not strictly tied to it. A search and replace across many files may not need much review, but one-line optimization changes can have widespread implications.) Your own small changes to fix a recently broken build ("make") or tests ("make check"), that you believe to be visible to a large number of developers, may be checked in without review. If you are not sure, ask for review. If you do push a build fix without review, send the patch to ovs-dev afterward as usual, indicating in the email that you have already pushed it. Regularly review submitted code in areas where you have expertise. Consider reviewing other code as well. Git conventions --------------- Do not push merge commits to the Git repository without prior discussion on ovs-dev. If you apply a change (yours or another's) then it is your responsibility to handle any resulting problems, especially broken builds and other regressions. If it is someone else's change, then you can ask the original submitter to address it. Regardless, you need to ensure that the problem is fixed in a timely way. The definition of "timely" depends on the severity of the problem. If a bug is present on master and other branches, fix it on master first, then backport the fix to other branches. Straightforward backports do not require additional review (beyond that for the fix on master). Feature development should be done only on master. Occasionally it makes sense to add a feature to the most recent release branch, before the first actual release of that branch. These should be handled in the same way as bug fixes, that is, first implemented on master and then backported. Keep the authorship of a commit clear by maintaining a correct list of "Signed-off-by:"s. If a confusing situation comes up, as it occasionally does, bring it up on the mailing list. If you explain the use of "Signed-off-by:" to a new developer, explain not just how but why, since the intended meaning of "Signed-off-by:" is more important than the syntax. As part of your explanation, quote or provide a URL to the Developer's Certificate of Origin in :doc:`contributing/submitting-patches`. Use Reported-by: and Tested-by: tags in commit messages to indicate the source of a bug report. Keep the ``AUTHORS.rst`` file up to date. Pre-Push Hook ------------- The following script can be helpful because it provides an extra chance to check for mistakes while pushing to the master branch of OVS or OVN. If you would like to use it, install it as ``hooks/pre-push`` in your ``.git`` directory and make sure to mark it as executable with ``chmod +x``. For maximum utility, make sure ``checkpatch.py`` is in ``$PATH``: .. code-block:: bash #! /bin/bash remote=$1 case $remote in ovs|ovn|origin) ;; *) exit 0 ;; esac while read local_ref local_sha1 remote_ref remote_sha1; do case $remote_ref in refs/heads/master) n=0 while read sha do n=$(expr $n + 1) git log -1 $sha echo checkpatch.py -1 $sha done < /dev/null; then : else exit 1 fi ;; esac done exit 0 ovs-2.13.0/Documentation/internals/contributing/000077500000000000000000000000001362155554400217355ustar00rootroot00000000000000ovs-2.13.0/Documentation/internals/contributing/backporting-patches.rst000066400000000000000000000256121362155554400264250ustar00rootroot00000000000000.. Copyright (c) 2017 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. 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. =================== Backporting patches =================== .. note:: This is an advanced topic for developers and maintainers. Readers should familiarize themselves with building and running Open vSwitch, with the git tool, and with the Open vSwitch patch submission process. The backporting of patches from one git tree to another takes multiple forms within Open vSwitch, but is broadly applied in the following fashion: - Contributors submit their proposed changes to the latest development branch - Contributors and maintainers provide feedback on the patches - When the change is satisfactory, maintainers apply the patch to the development branch. - Maintainers backport changes from a development branch to release branches. With regards to Open vSwitch user space code and code that does not comprise the Linux datapath and compat code, the development branch is `master` in the Open vSwitch repository. Patches are applied first to this branch, then to the most recent `branch-X.Y`, then earlier `branch-X.Z`, and so on. The most common kind of patch in this category is a bugfix which affects master and other branches. For Linux datapath code, the primary development branch is in the `net-next`_ tree as described in the section below, and patch discussion occurs on the `netdev`__ mailing list. Patches are first applied to the upstream branch by the networking maintainer, then the contributor backports the patch to the Open vSwitch `master` development branch. Patches in this category may include features which have been applied upstream, or bugfixes to the Open vSwitch datapath code. For bugfixes, the patches subsequently follow the regular Open vSwitch process as described above to reach older branches. __ http://vger.kernel.org/vger-lists.html#netdev Changes to userspace components ------------------------------- Patches which are fixing bugs should be considered for backporting from `master` to release branches. Open vSwitch contributors submit their patches targeted to the `master` branch, using the ``Fixes`` tag described in :doc:`submitting-patches`. The maintainer first applies the patch to `master`, then backports the patch to each older affected tree, as far back as it goes or at least to all currently supported branches. This is usually each branch back to the most recent LTS release branch. If the fix only affects a particular branch and not `master`, contributors should submit the change with the target branch listed in the subject line of the patch. Contributors should list all versions that the bug affects. The ``git format-patch`` argument ``--subject-prefix`` may be used when posting the patch, for example: :: $ git format-patch HEAD --subject-prefix="PATCH branch-2.7" If a maintainer is backporting a change to older branches and the backport is not a trivial cherry-pick, then the maintainer may opt to submit the backport for the older branch on the mailing list for further review. This should be done in the same manner as described above. Changes to Linux kernel components ---------------------------------- The Linux kernel components in Open vSwitch go through initial review in the upstream Linux netdev community before they go into the Open vSwitch tree. As such, backports from upstream to the Open vSwitch tree may include bugfixes or new features. The `netdev-FAQ`_ describes the general process for merging patches to the upstream Linux tree. To keep track of the changes which are made upstream against the changes which have been backported to the Open vSwitch tree, backports should be done in the order that they are applied to the upstream `net-next`_ tree. For example, if the git history in ``linux/net/openvswitch/`` in the `net-next` tree lists patches A, B and C that were applied (in that order), then the backports of these patches to ``openvswitch/datapath/`` should be done submitted in the order A, B, then C. Patches that are proposed against the Open vSwitch tree, including backports, should follow the guidelines described in :doc:`submitting-patches`. Ideally, a series which backports new functionality would also include a series of patches for the userspace components which show how to use the new functionality, and include tests to validate the behaviour. However, in the interests of keeping the Open vSwitch tree in sync with upstream `net-next`, contributors may send Open vSwitch kernel module changes independently of userspace changes. .. _netdev-faq: https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt .. _net-next: http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git How to backport kernel patches ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ First, the patch should be submitted upstream to `netdev`. When the patch has been applied to `net-next`, it is ready to be backported. Starting from the Linux tree, use ``git format-patch`` to format each patch that should be backported. For each of these patches, they may only include changes to ``linux/net/openvswitch/``, or they may include changes to other directories. Depending on which files the patch touches, the backport may be easier or more difficult to undertake. Start by formatting the relevant patches from the Linux tree. For example, to format the last 5 patches to ``net/openvswitch``, going back from OVS commit ``1234c0ffee5``, placing them into ``/tmp/``: :: $ git format-patch -5 1234c0ffee5 net/openvswitch/ -o /tmp Next, change into the Open vSwitch directory and apply the patch: :: $ git am -p3 --reject --directory=datapath/ If this is successful, proceed to the next patch: :: $ git am --continue If this is unsuccessful, the above command applies all changes that it can to the working tree, and leaves rejected hunks in corresponding \*.rej files. Proceed by using ``git diff`` to identify the changes, and edit the files so that the hunk matches what the file looks like when the corresponding commit is checked out in the linux tree. When all hunks are fixed, add the files to the index using ``git add``. If the patch only changes filepaths under ``linux/net/openvswitch``, then most likely the patch is fully backported. At this point, review the patch's changes and compare with the latest upstream code for the modified functions. Occasionally, there may be bugs introduced in a particular patch which were fixed in a later patch upstream. To prevent breakage in the OVS tree, consider rolling later bugfixes into the current patch - particularly if they are small, clear bugfixes in the logic of this patch. Then proceed to the next patch using ``git am --continue``. If you made any changes to the patch compared with the original version, describe the changes in the commit message. If the changes affects other paths, then you may also need to backport function definitions from the upstream tree into the ``datapath/linux/compat`` directory. First, attempt to compile the datapath. If this is successful, then most likely there is no further work required. As per the previous paragraph, consider reviewing and backporting any minor fixes to this code if applicable, then proceed to the next patch using ``git am --continue``. If compilation fails, the compiler will show which functions are missing or broken. Typically this should match with some function definitions provided in the patch file. The following command will attempt to apply all such changes from the patch into the ``openvswitch/datapath/linux/compat`` directory; Like the previous ``git am`` command above, it may succeed or fail. If it succeeds, review the patch and proceed to the next patch using ``git am --continue``. :: $ git am -p3 --reject --directory='datapath/linux/compat/' For each conflicting hunk, attempt to resolve the change so that the function reflects what the function looks like in the upstream Linux tree. After resolving these changes, compile the changes, add the modified files to the index using ``git add``, review the patch, and proceed to the next patch using ``git am --continue``. Submission ~~~~~~~~~~ Once the patches are all assembled and working on the Open vSwitch tree, they need to be formatted again using ``git format-patch``. The common format for commit messages for Linux backport patches is as follows: :: datapath: Remove incorrect WARN_ONCE(). Upstream commit: commit c6b2aafffc6934be72d96855c9a1d88970597fbc Author: Jarno Rajahalme Date: Mon Aug 1 19:08:29 2016 -0700 openvswitch: Remove incorrect WARN_ONCE(). ovs_ct_find_existing() issues a warning if an existing conntrack entry classified as IP_CT_NEW is found, with the premise that this should not happen. However, a newly confirmed, non-expected conntrack entry remains IP_CT_NEW as long as no reply direction traffic is seen. This has resulted into somewhat confusing kernel log messages. This patch removes this check and warning. Fixes: 289f2253 ("openvswitch: Find existing conntrack entry after upcall.") Suggested-by: Joe Stringer Signed-off-by: Jarno Rajahalme Acked-by: Joe Stringer Signed-off-by: Jarno Rajahalme The upstream commit SHA should be the one that appears in Linus' tree so that reviewers can compare the backported patch with the one upstream. Note that the subject line for the backported patch replaces the original patch's ``openvswitch`` prefix with ``datapath``. Patches which only affect the ``datapath/linux/compat`` directory should be prefixed with ``compat``. The contents of a backport should be equivalent to the changes made by the original patch; explain any variations from the original patch in the commit message - For instance if you rolled in a bugfix. Reviewers will verify that the changes made by the backport patch are the same as the changes made in the original commit which the backport is based upon. Patch submission should otherwise follow the regular steps described in :doc:`submitting-patches`. In particular, if performing kernel patch backports, pay attention to :ref:`datapath-testing`. ovs-2.13.0/Documentation/internals/contributing/coding-style-windows.rst000066400000000000000000000154331362155554400265660ustar00rootroot00000000000000.. 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 Windows Datapath Coding Style ========================================== The :doc:`coding style ` guide gives the flexibility for each platform to use its own coding style for the kernel datapath. This file describes the specific coding style used in most of the C files in the Windows kernel datapath of the Open vSwitch distribution. Most of the coding conventions applicable for the Open vSwitch distribution are applicable to the Windows kernel datapath as well. There are some exceptions and new guidelines owing to the commonly followed practices in Windows kernel/driver code. They are noted as follows: Basics ------ - Limit lines to 79 characters. Many times, this is not possible due to long names of functions and it is fine to go beyond the characters limit. One common example is when calling into NDIS functions. Types ----- Use data types defined by Windows for most of the code. This is a common practice in Windows driver code, and it makes integrating with the data structures and functions defined by Windows easier. Example: ``DWORD`` and ``BOOLEAN``. Use caution in portions of the code that interface with the OVS userspace. OVS userspace does not use Windows specific data types, and when copying data back and forth between kernel and userspace, care should be exercised. Naming ------ It is common practice to use camel casing for naming variables, functions and files in Windows. For types, especially structures, unions and enums, using all upper case letters with words separated by '_' is common. These practices can be used for OVS Windows datapath. However, use the following guidelines: - Use lower case to begin the name of a variable. - Do not use '_' to begin the name of the variable. '_' is to be used to begin the parameters of a pre-processor macro. - Use upper case to begin the name of a function, enum, file name etc. - Static functions whose scope is limited to the file they are defined in can be prefixed with '_'. This is not mandatory though. - For types, use all upper case for all letters with words separated by '_'. If camel casing is preferred, use upper case for the first letter. - It is a common practice to define a pointer type by prefixing the letter 'P' to a data type. The same practice can be followed here as well. For example:: static __inline BOOLEAN OvsDetectTunnelRxPkt(POVS_FORWARDING_CONTEXT ovsFwdCtx, POVS_FLOW_KEY flowKey) { POVS_VPORT_ENTRY tunnelVport = NULL; if (!flowKey->ipKey.nwFrag && flowKey->ipKey.nwProto == IPPROTO_UDP && flowKey->ipKey.l4.tpDst == VXLAN_UDP_PORT_NBO) { tunnelVport = OvsGetTunnelVport(OVSWIN_VPORT_TYPE_VXLAN); ovsActionStats.rxVxlan++; } else { return FALSE; } if (tunnelVport) { ASSERT(ovsFwdCtx->tunnelRxNic == NULL); ovsFwdCtx->tunnelRxNic = tunnelVport; return TRUE; } return FALSE; } For declaring variables of pointer type, use of the pointer data type prefixed with 'P' is preferred over using '*'. This is not mandatory though, and is only prescribed since it is a common practice in Windows. Example, #1 is preferred over #2 though #2 is also equally correct: 1. ``PNET_BUFFER_LIST curNbl;`` 2. ``NET_BUFFER_LIST *curNbl;`` Comments -------- Comments should be written as full sentences that start with a capital letter and end with a period. Putting two spaces between sentences is not necessary. ``//`` can be used for comments as long as the comment is a single line comment. For block comments, use ``/* */`` comments Functions --------- Put the return type, function name, and the braces that surround the function's code on separate lines, all starting in column 0. Before each function definition, write a comment that describes the function's purpose, including each parameter, the return value, and side effects. References to argument names should be given in single-quotes, e.g. 'arg'. The comment should not include the function name, nor need it follow any formal structure. The comment does not need to describe how a function does its work, unless this information is needed to use the function correctly (this is often better done with comments *inside* the function). Mention any side effects that the function has that are not obvious based on the name of the function or based on the workflow it is called from. In the interest of keeping comments describing functions similar in structure, use the following template. :: /* *---------------------------------------------------------------------------- * Any description of the function, arguments, return types, assumptions and * side effects. *---------------------------------------------------------------------------- */ Source Files ------------ Each source file should state its license in a comment at the very top, followed by a comment explaining the purpose of the code that is in that file. The comment should explain how the code in the file relates to code in other files. The goal is to allow a programmer to quickly figure out where a given module fits into the larger system. The first non-comment line in a .c source file should be:: #include ``#include`` directives should appear in the following order: 1. ``#include `` 2. The module's own headers, if any. Including this before any other header (besides ````) ensures that the module's header file is self-contained (see *Header Files*) below. 3. Standard C library headers and other system headers, preferably in alphabetical order. (Occasionally one encounters a set of system headers that must be included in a particular order, in which case that order must take precedence.) 4. Open vSwitch headers, in alphabetical order. Use ``""``, not ``<>``, to specify Open vSwitch header names. ovs-2.13.0/Documentation/internals/contributing/coding-style.rst000066400000000000000000000526551362155554400251050ustar00rootroot00000000000000.. 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 Coding Style ========================= This file describes the coding style used in most C files in the Open vSwitch distribution. However, Linux kernel code datapath directory follows the Linux kernel's established coding conventions. For the Windows kernel datapath code, use the coding style described in :doc:`coding-style-windows`. The following GNU indent options approximate this style. :: -npro -bad -bap -bbb -br -blf -brs -cdw -ce -fca -cli0 -npcs -i4 -l79 \ -lc79 -nbfda -nut -saf -sai -saw -sbi4 -sc -sob -st -ncdb -pi4 -cs -bs \ -di1 -lp -il0 -hnl .. _basics: Basics ------ - Limit lines to 79 characters. - Use form feeds (control+L) to divide long source files into logical pieces. A form feed should appear as the only character on a line. - Do not use tabs for indentation. - Avoid trailing spaces on lines. .. _naming: Naming ------ - Use names that explain the purpose of a function or object. - Use underscores to separate words in an identifier: ``multi_word_name``. - Use lowercase for most names. Use uppercase for macros, macro parameters, and members of enumerations. - Give arrays names that are plural. - Pick a unique name prefix (ending with an underscore) for each module, and apply that prefix to all of that module's externally visible names. Names of macro parameters, struct and union members, and parameters in function prototypes are not considered externally visible for this purpose. - Do not use names that begin with ``_``. If you need a name for "internal use only", use ``__`` as a suffix instead of a prefix. - Avoid negative names: ``found`` is a better name than ``not_found``. - In names, a ``size`` is a count of bytes, a ``length`` is a count of characters. A buffer has size, but a string has length. The length of a string does not include the null terminator, but the size of the buffer that contains the string does. .. _comments: Comments -------- Comments should be written as full sentences that start with a capital letter and end with a period. Put two spaces between sentences. Write block comments as shown below. You may put the ``/*`` and ``*/`` on the same line as comment text if you prefer. :: /* * We redirect stderr to /dev/null because we often want to remove all * traffic control configuration on a port so its in a known state. If * this done when there is no such configuration, tc complains, so we just * always ignore it. */ Each function and each variable declared outside a function, and each struct, union, and typedef declaration should be preceded by a comment. See functions_ below for function comment guidelines. Each struct and union member should each have an inline comment that explains its meaning. structs and unions with many members should be additionally divided into logical groups of members by block comments, e.g.: :: /* An event that will wake the following call to poll_block(). */ struct poll_waiter { /* Set when the waiter is created. */ struct ovs_list node; /* Element in global waiters list. */ int fd; /* File descriptor. */ short int events; /* Events to wait for (POLLIN, POLLOUT). */ poll_fd_func *function; /* Callback function, if any, or null. */ void *aux; /* Argument to callback function. */ struct backtrace *backtrace; /* Event that created waiter, or null. */ /* Set only when poll_block() is called. */ struct pollfd *pollfd; /* Pointer to element of the pollfds array (null if added from a callback). */ }; Use ``XXX`` or ``FIXME`` comments to mark code that needs work. Don't use ``//`` comments. Don't comment out or ``#if 0`` out code. Just remove it. The code that was there will still be in version control history. .. _functions: Functions --------- Put the return type, function name, and the braces that surround the function's code on separate lines, all starting in column 0. Before each function definition, write a comment that describes the function's purpose, including each parameter, the return value, and side effects. References to argument names should be given in single-quotes, e.g. ``'arg'``. The comment should not include the function name, nor need it follow any formal structure. The comment does not need to describe how a function does its work, unless this information is needed to use the function correctly (this is often better done with comments *inside* the function). Simple static functions do not need a comment. Within a file, non-static functions should come first, in the order that they are declared in the header file, followed by static functions. Static functions should be in one or more separate pages (separated by form feed characters) in logical groups. A commonly useful way to divide groups is by "level", with high-level functions first, followed by groups of progressively lower-level functions. This makes it easy for the program's reader to see the top-down structure by reading from top to bottom. All function declarations and definitions should include a prototype. Empty parentheses, e.g. ``int foo();``, do not include a prototype (they state that the function's parameters are unknown); write ``void`` in parentheses instead, e.g. ``int foo(void);``. Prototypes for static functions should either all go at the top of the file, separated into groups by blank lines, or they should appear at the top of each page of functions. Don't comment individual prototypes, but a comment on each group of prototypes is often appropriate. In the absence of good reasons for another order, the following parameter order is preferred. One notable exception is that data parameters and their corresponding size parameters should be paired. 1. The primary object being manipulated, if any (equivalent to the ``this`` pointer in C++). 2. Input-only parameters. 3. Input/output parameters. 4. Output-only parameters. 5. Status parameter. Example: :: ``` /* Stores the features supported by 'netdev' into each of '*current', * '*advertised', '*supported', and '*peer' that are non-null. Each value * is a bitmap of "enum ofp_port_features" bits, in host byte order. * Returns 0 if successful, otherwise a positive errno value. On failure, * all of the passed-in values are set to 0. */ int netdev_get_features(struct netdev *netdev, uint32_t *current, uint32_t *advertised, uint32_t *supported, uint32_t *peer) { ... } ``` Functions that destroy an instance of a dynamically-allocated type should accept and ignore a null pointer argument. Code that calls such a function (including the C standard library function ``free()``) should omit a null-pointer check. We find that this usually makes code easier to read. Functions in ``.c`` files should not normally be marked ``inline``, because it does not usually help code generation and it does suppress compiler warnings about unused functions. (Functions defined in ``.h`` usually should be marked ``inline``.) .. _function prototypes: Function Prototypes ------------------- Put the return type and function name on the same line in a function prototype: :: static const struct option_class *get_option_class(int code); Omit parameter names from function prototypes when the names do not give useful information, e.g.: :: int netdev_get_mtu(const struct netdev *, int *mtup); Statements ---------- Indent each level of code with 4 spaces. Use BSD-style brace placement: :: if (a()) { b(); d(); } Put a space between ``if``, ``while``, ``for``, etc. and the expressions that follow them. Enclose single statements in braces: :: if (a > b) { return a; } else { return b; } Use comments and blank lines to divide long functions into logical groups of statements. Avoid assignments inside ``if`` and ``while`` conditions. Do not put gratuitous parentheses around the expression in a return statement, that is, write ``return 0;`` and not ``return(0);`` Write only one statement per line. Indent ``switch`` statements like this: :: switch (conn->state) { case S_RECV: error = run_connection_input(conn); break; case S_PROCESS: error = 0; break; case S_SEND: error = run_connection_output(conn); break; default: OVS_NOT_REACHED(); } ``switch`` statements with very short, uniform cases may use an abbreviated style: :: switch (code) { case 200: return "OK"; case 201: return "Created"; case 202: return "Accepted"; case 204: return "No Content"; default: return "Unknown"; } Use ``for (;;)`` to write an infinite loop. In an ``if/else`` construct where one branch is the "normal" or "common" case and the other branch is the "uncommon" or "error" case, put the common case after the ``if``, not the ``else``. This is a form of documentation. It also places the most important code in sequential order without forcing the reader to visually skip past less important details. (Some compilers also assume that the ``if`` branch is the more common case, so this can be a real form of optimization as well.) Return Values ------------- For functions that return a success or failure indication, prefer one of the following return value conventions: - An ``int`` where ``0`` indicates success and a positive errno value indicates a reason for failure. - A ``bool`` where ``true`` indicates success and ``false`` indicates failure. Macros ------ Don't define an object-like macro if an enum can be used instead. Don't define a function-like macro if a ``static inline`` function can be used instead. If a macro's definition contains multiple statements, enclose them with ``do { ... } while (0)`` to allow them to work properly in all syntactic circumstances. Do use macros to eliminate the need to update different parts of a single file in parallel, e.g. a list of enums and an array that gives the name of each enum. For example: :: /* Logging importance levels. */ #define VLOG_LEVELS \ VLOG_LEVEL(EMER, LOG_ALERT) \ VLOG_LEVEL(ERR, LOG_ERR) \ VLOG_LEVEL(WARN, LOG_WARNING) \ VLOG_LEVEL(INFO, LOG_NOTICE) \ VLOG_LEVEL(DBG, LOG_DEBUG) enum vlog_level { #define VLOG_LEVEL(NAME, SYSLOG_LEVEL) VLL_##NAME, VLOG_LEVELS #undef VLOG_LEVEL VLL_N_LEVELS }; /* Name for each logging level. */ static const char *level_names[VLL_N_LEVELS] = { #define VLOG_LEVEL(NAME, SYSLOG_LEVEL) #NAME, VLOG_LEVELS #undef VLOG_LEVEL }; Thread Safety Annotations ------------------------- Use the macros in ``lib/compiler.h`` to annotate locking requirements. For example: :: static struct ovs_mutex mutex = OVS_MUTEX_INITIALIZER; static struct ovs_rwlock rwlock = OVS_RWLOCK_INITIALIZER; void function_require_plain_mutex(void) OVS_REQUIRES(mutex); void function_require_rwlock(void) OVS_REQ_RDLOCK(rwlock); Pass lock objects, not their addresses, to the annotation macros. (Thus we have ``OVS_REQUIRES(mutex)`` above, not ``OVS_REQUIRES(&mutex)``.) .. _source files: Source Files ------------ Each source file should state its license in a comment at the very top, followed by a comment explaining the purpose of the code that is in that file. The comment should explain how the code in the file relates to code in other files. The goal is to allow a programmer to quickly figure out where a given module fits into the larger system. The first non-comment line in a ``.c`` source file should be: :: #include ``#include`` directives should appear in the following order: 1. ``#include `` 2. The module's own headers, if any. Including this before any other header (besides ) ensures that the module's header file is self-contained (see `header files`_ below). 3. Standard C library headers and other system headers, preferably in alphabetical order. (Occasionally one encounters a set of system headers that must be included in a particular order, in which case that order must take precedence.) 4. Open vSwitch headers, in alphabetical order. Use ``""``, not ``<>``, to specify Open vSwitch header names. .. _header files: Header Files ------------ Each header file should start with its license, as described under `source files`_ above, followed by a "header guard" to make the header file idempotent, like so: :: #ifndef NETDEV_H #define NETDEV_H 1 ... #endif /* netdev.h */ Header files should be self-contained; that is, they should ``#include`` whatever additional headers are required, without requiring the client to ``#include`` them for it. Don't define the members of a struct or union in a header file, unless client code is actually intended to access them directly or if the definition is otherwise actually needed (e.g. inline functions defined in the header need them). Similarly, don't ``#include`` a header file just for the declaration of a struct or union tag (e.g. just for ``struct ;``). Just declare the tag yourself. This reduces the number of header file dependencies. Types ----- Use typedefs sparingly. Code is clearer if the actual type is visible at the point of declaration. Do not, in general, declare a typedef for a ``struct``, ``union``, or ``enum``. Do not declare a typedef for a pointer type, because this can be very confusing to the reader. A function type is a good use for a typedef because it can clarify code. The type should be a function type, not a pointer-to-function type. That way, the typedef name can be used to declare function prototypes. (It cannot be used for function definitions, because that is explicitly prohibited by C89 and C99.) You may assume that ``char`` is exactly 8 bits and that ``int`` and ``long`` are at least 32 bits. Don't assume that ``long`` is big enough to hold a pointer. If you need to cast a pointer to an integer, use ``intptr_t`` or ``uintptr_t`` from . Use the ``int_t`` and ``uint_t`` types from for exact-width integer types. Use the ``PRId``, ``PRIu``, and ``PRIx`` macros from for formatting them with ``printf()`` and related functions. For compatibility with antique ``printf()`` implementations: - Instead of ``"%zu"``, use ``"%"PRIuSIZE``. - Instead of ``"%td"``, use ``"%"PRIdPTR``. - Instead of ``"%ju"``, use ``"%"PRIuMAX``. Other variants exist for different radixes. For example, use ``"%"PRIxSIZE`` instead of ``"%zx"`` or ``"%x"`` instead of ``"%hhx"``. Also, instead of ``"%hhd"``, use ``"%d"``. Be cautious substituting ``"%u"``, ``"%x"``, and ``"%o"`` for the corresponding versions with ``"hh"``: cast the argument to unsigned char if necessary, because ``printf("%hhu", -1)`` prints ``255`` but ``printf("%u", -1)`` prints ``4294967295``. Use bit-fields sparingly. Do not use bit-fields for layout of network protocol fields or in other circumstances where the exact format is important. Declare bit-fields to be signed or unsigned integer types or ``_Bool`` (aka ``bool``). Do *not* declare bit-fields of type ``int``: C99 allows these to be either signed or unsigned according to the compiler's whim. (A 1-bit bit-field of type ``int`` may have a range of ``-1...0``!) Try to order structure members such that they pack well on a system with 2-byte ``short``, 4-byte ``int``, and 4- or 8-byte ``long`` and pointer types. Prefer clear organization over size optimization unless you are convinced there is a size or speed benefit. Pointer declarators bind to the variable name, not the type name. Write ``int *x``, not ``int* x`` and definitely not ``int * x``. Expressions ----------- Put one space on each side of infix binary and ternary operators: :: * / % + - << >> < <= > >= == != & ^ | && || ?: = += -= *= /= %= &= ^= |= <<= >>= Avoid comma operators. Do not put any white space around postfix, prefix, or grouping operators: :: () [] -> . ! ~ ++ -- + - * & Exception 1: Put a space after (but not before) the "sizeof" keyword. Exception 2: Put a space between the ``()`` used in a cast and the expression whose type is cast: ``(void *) 0``. Break long lines before the ternary operators ``?`` and ``:``, rather than after them, e.g. :: return (out_port != VIGP_CONTROL_PATH ? alpheus_output_port(dp, skb, out_port) : alpheus_output_control(dp, skb, fwd_save_skb(skb), VIGR_ACTION)); Parenthesize the operands of ``&&`` and ``||`` if operator precedence makes it necessary, or if the operands are themselves expressions that use ``&&`` and ``||``, but not otherwise. Thus:: if (rule && (!best || rule->priority > best->priority)) { best = rule; } but:: if (!isdigit((unsigned char)s[0]) || !isdigit((unsigned char)s[1]) || !isdigit((unsigned char)s[2])) { printf("string %s does not start with 3-digit code\n", s); } Do parenthesize a subexpression that must be split across more than one line, e.g.:: *idxp = ((l1_idx << PORT_ARRAY_L1_SHIFT) | (l2_idx << PORT_ARRAY_L2_SHIFT) | (l3_idx << PORT_ARRAY_L3_SHIFT)); Breaking a long line after a binary operator gives its operands a more consistent look, since each operand has the same horizontal position. This makes the end-of-line position a good choice when the operands naturally resemble each other, as in the previous two examples. On the other hand, breaking before a binary operator better draws the eye to the operator, which can help clarify code by making it more obvious what's happening, such as in the following example:: if (!ctx.freezing && xbridge->has_in_band && in_band_must_output_to_local_port(flow) && !actions_output_to_local_port(&ctx)) { Thus, decide whether to break before or after a binary operator separately in each situation, based on which of these factors appear to be more important. Try to avoid casts. Don't cast the return value of malloc(). The ``sizeof`` operator is unique among C operators in that it accepts two very different kinds of operands: an expression or a type. In general, prefer to specify an expression, e.g. ``int *x = xmalloc(sizeof *x);``. When the operand of ``sizeof`` is an expression, there is no need to parenthesize that operand, and please don't. Use the ``ARRAY_SIZE`` macro from ``lib/util.h`` to calculate the number of elements in an array. When using a relational operator like ``<`` or ``==``, put an expression or variable argument on the left and a constant argument on the right, e.g. ``x == 0``, *not* ``0 == x``. Blank Lines ----------- Put one blank line between top-level definitions of functions and global variables. C DIALECT --------- Most C99 features are OK because they are widely implemented: - Flexible array members (e.g. ``struct { int foo[]; }``). - ``static inline`` functions (but no other forms of ``inline``, for which GCC and C99 have differing interpretations). - ``long long`` - ``bool`` and ````, but don't assume that ``bool`` or ``_Bool`` can only take on the values ``0`` or ``1``, because this behavior can't be simulated on C89 compilers. Also, don't assume that a conversion to ``bool`` or ``_Bool`` follows C99 semantics, i.e. use ``(bool) (some_value != 0)`` rather than ``(bool) some_value``. The latter might produce unexpected results on non-C99 environments. For example, if ``bool`` is implemented as a typedef of char and ``some_value = 0x10000000``. - Designated initializers (e.g. ``struct foo foo = { .a = 1 };`` and ``int a[] = { [2] = 5 };``). - Mixing of declarations and code within a block. Favor positioning that allows variables to be initialized at their point of declaration. - Use of declarations in iteration statements (e.g. ``for (int i = 0; i < 10; i++)``). - Use of a trailing comma in an enum declaration (e.g. ``enum { x = 1, };``). As a matter of style, avoid ``//`` comments. Avoid using GCC or Clang extensions unless you also add a fallback for other compilers. You can, however, use C99 features or GCC extensions also supported by Clang in code that compiles only on GNU/Linux (such as ``lib/netdev-linux.c``), because GCC is the system compiler there. Python ------ When introducing new Python code, try to follow Python's `PEP 8 `__ style. Consider running the ``pep8`` or ``flake8`` tool against your code to find issues. Libraries --------- When introducing a new library, follow :doc:`Open vSwitch Library ABI guide ` ovs-2.13.0/Documentation/internals/contributing/documentation-style.rst000066400000000000000000000262671362155554400265130ustar00rootroot00000000000000.. 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. ================================ Open vSwitch Documentation Style ================================ This file describes the documentation style used in all documentation found in Open vSwitch. Documentation includes any documents found in ``Documentation`` along with any ``README``, ``MAINTAINERS``, or generally ``rst`` suffixed documents found in the project tree. .. note:: This guide only applies to documentation for Open vSwitch v2.7. or greater. Previous versions of Open vSwitch used a combination of Markdown and raw plain text, and guidelines for these are not detailed here. reStructuredText vs. Sphinx --------------------------- `reStructuredText (rST)`__ is the syntax, while `Sphinx`__ is a documentation generator. Sphinx introduces a number of extensions to rST, like the ``:ref:`` role, which can and should be used in documentation, but these will not work correctly on GitHub. As such, these extensions should not be used in any documentation in the root level, such as the ``README``. __ http://docutils.sourceforge.net/rst.html __ http://www.sphinx-doc.org/ rST Conventions --------------- Basics ~~~~~~ Many of the basic documentation guidelines match those of the :doc:`coding-style`. - Use reStructuredText (rST) for all documentation. Sphinx extensions can be used, but only for documentation in the ``Documentation`` folder. - Limit lines at 79 characters. .. note:: An exception to this rule is text within code-block elements that cannot be wrapped and links within references. - Use spaces for indentation. - Match indentation levels. A change in indentation level usually signifies a change in content nesting, by either closing the existing level or introducing a new level. - Avoid trailing spaces on lines. - Include a license (see this file) in all docs. - Most importantly, always build and display documentation before submitting changes! Docs aren't unit testable, so visible inspection is necessary. File Names ~~~~~~~~~~ - Use hyphens as space delimiters. For example: ``my-readme-document.rst`` .. note:: An exception to this rule is any man pages, which take an trailing number corresponding to the number of arguments required. This number is preceded by an underscore. - Use lowercase filenames. .. note:: An exception to this rule is any documents found in the root-level of the project. Titles ~~~~~~ - Use the following headers levels. | ``=======`` Heading 0 (reserved for the title in a document) | ``-------`` Heading 1 | ``~~~~~~~`` Heading 2 | ``+++++++`` Heading 3 | ``'''''''`` Heading 4 .. note:: Avoid using lower heading levels by rewriting and reorganizing the information. - Under- and overlines should be of the same length as that of the heading text. - Use "title case" for headers. Code ~~~~ - Use ``::`` to prefix code. - Don't use syntax highlighting such as ``.. highlight:: `` or ``code-block:: `` because it depends on external ``pygments`` library. - Prefix commands with ``$``. - Where possible, include fully-working snippets of code. If there pre-requisites, explain what they are and how to achieve them. Admonitions ~~~~~~~~~~~ - Use admonitions to call attention to important information.:: .. note:: This is a sample callout for some useful tip or trick. Example admonitions include: ``warning``, ``important``, ``note``, ``tip`` or ``seealso``. - Use notes sparingly. Avoid having more than one per subsection. Tables ~~~~~~ - Use either graphic tables, list tables or CSV tables. Graphic tables ++++++++++++++ :: .. table:: OVS-Linux kernel compatibility ============ ============== Open vSwitch Linux kernel ============ ============== 1.4.x 2.6.18 to 3.2 1.5.x 2.6.18 to 3.2 1.6.x 2.6.18 to 3.2 ============ ============== :: .. table:: OVS-Linux kernel compatibility +--------------+---------------+ | Open vSwitch | Linux kernel | +==============+===============+ | 1.4.x | 2.6.18 to 3.2 | +--------------+---------------+ | 1.5.x | 2.6.18 to 3.2 | +--------------+---------------+ | 1.6.x | 2.6.18 to 3.2 | +--------------+---------------+ .. note:: The ``table`` role - ``.. table:: `` - can be safely omitted. List tables +++++++++++ :: .. list-table:: OVS-Linux kernel compatibility :widths: 10 15 :header-rows: 1 * - Open vSwitch - Linux kernel * - 1.4.x - 2.6.18 to 3.2 * - 1.5.x - 2.6.18 to 3.2 * - 1.6.x - 2.6.18 to 3.2 CSV tables ++++++++++ :: .. csv-table:: OVS-Linux kernel compatibility :header: Open vSwitch, Linux kernel :widths: 10 15 1.4.x, 2.6.18 to 3.2 1.5.x, 2.6.18 to 3.2 1.6.x, 2.6.18 to 3.2 Cross-referencing ~~~~~~~~~~~~~~~~~ - To link to an external file or document, include as a link.:: Here's a `link `__ to the Open vSwitch website. Here's a `link`_ in reference style. .. _link: http://openvswitch.org - You can also use citations.:: Refer to the Open vSwitch documentation [1]_. References ---------- .. [1]: http://openvswitch.org - To cross-reference another doc, use the ``doc`` role.:: Here is a link to the :doc:`/README.rst` .. note:: This is a Sphinx extension. Do not use this in any top-level documents. - To cross-reference an arbitrary location in a doc, use the ``ref`` role.:: .. _sample-crossref Title ~~~~~ Hello, world. Another Title ~~~~~~~~~~~~~ Here is a cross-reference to :ref:`sample-crossref`. .. note:: This is a Sphinx extension. Do not use this in any top-level documents. Figures and Other Media ~~~~~~~~~~~~~~~~~~~~~~~ - All images should be in PNG format and compressed where possible. For PNG files, use OptiPNG and AdvanceCOMP's ``advpng``: :: $ optipng -o7 -zm1-9 -i0 -strip all $ advpng -z4 - Any ASCII text "images" should be included in code-blocks to preserve formatting - Include other reStructuredText verbatim in a current document Comments ~~~~~~~~ - Comments are indicated by means of the ``..`` marker.:: .. TODO(stephenfin) This section needs some work. This TODO will not appear in the final generated document, however. Man Pages --------- In addition to the above, man pages have some specific requirements: - You **must** define the following sections: - Synopsis - Description - Options Note that `NAME` is not included - this is automatically generated by Sphinx and should not be manually defined. Also note that these do not need to be uppercase - Sphinx will do this automatically. Additional sections are allowed. Refer to `man-pages(8)` for information on the sections generally allowed. - You **must not** define a `NAME` section. See above. - The `OPTIONS` section must describe arguments and options using the `program`__ and `option`__ directives. This ensures the output is formatted correctly and that you can cross-reference various programs and commands from the documentation. For example:: .. program:: ovs-do-something .. option:: -f, --force Force the operation .. option:: -b , --bridge Name or ID of bridge .. important:: Option argument names should be enclosed in angle brackets, as above. - Any references to the application or any other Open vSwitch application must be marked up using the `program` role. This allows for easy linking in the HTML output and correct formatting in the man page output. For example:: To do something, run :program:`ovs-do-something`. - 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 example. __ http://www.sphinx-doc.org/en/stable/domains.html#directive-program __ http://www.sphinx-doc.org/en/stable/domains.html#directive-option __ http://www.sphinx-doc.org/en/stable/config.html#confval-man_pages Writing Style ------------- Follow these guidelines to ensure readability and consistency of the Open vSwitch documentation. These guidelines are based on the `/*IBM Style Guide/* `__. - Use standard US English Use a spelling and grammar checking tool as necessary. - Expand initialisms and acronyms on first usage. Commonly used terms like CPU or RAM are allowed. .. list-table:: :header-rows: 1 * - Do not use - Do use * - OVS is a virtual switch. OVS has... - Open vSwitch (OVS) is a virtual switch. OVS has... * - The VTEP emulator is... - The Virtual Tunnel Endpoint (VTEP) emulator is... - Write in the active voice The subject should do the verb's action, rather than be acted upon. .. list-table:: :header-rows: 1 * - Do not use - Do use * - A bridge is created by you - Create a bridge - Write in the present tense .. list-table:: :header-rows: 1 * - Do not use - Do use * - Once the bridge is created, you can create a port - Once the bridge is created, create a port - Write in second person .. list-table:: :header-rows: 1 * - Do not use - Do use * - To create a bridge, the user runs: - To create a bridge, run: - Keep sentences short and concise - Eliminate needless politeness Avoid "please" and "thank you" Helpful Tools ------------- There are a number of tools, online and offline, which can be used to preview documents are you edit them: - `rst.ninjs.org `__ An online rST editor/previewer - `ReText `__ A simple but powerful editor for Markdown and reStructuredText. ReText is written in Python. - `restview `__ A viewer for ReStructuredText documents that renders them on the fly. Useful Links ------------ - `Quick reStructuredText `__ - `Sphinx Documentation `__ ovs-2.13.0/Documentation/internals/contributing/index.rst000066400000000000000000000022611362155554400235770ustar00rootroot00000000000000.. 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. ============================ Contributing to Open vSwitch ============================ The below guides provide information on contributing to Open vSwitch itself. .. toctree:: :maxdepth: 2 submitting-patches backporting-patches coding-style coding-style-windows documentation-style libopenvswitch-abi ovs-2.13.0/Documentation/internals/contributing/libopenvswitch-abi.rst000066400000000000000000000120171362155554400262610ustar00rootroot00000000000000.. 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. 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 Library ABI Updates =================================== This file describes the manner in which the Open vSwitch shared library manages different ABI and API revisions. This document aims to describe the background, goals, and concrete mechanisms used to export code-space functionality so that it may be shared between multiple applications. .. _definitions: Definitions ----------- .. csv-table:: Definitions for terms appearing in this document :header: "Term", "Definition" "ABI", "Abbreviation of Application Binary Interface" "API", "Abbreviation of Application Programming Interface" "Application Binary Interface", "The low-level runtime interface exposed by an object file." "Application Programming Interface", "The source-code interface descriptions intended for use in multiple translation units when compiling." "Code library", "A collection of function implementations and definitions intended to be exported and called through a well-defined interface." "Shared Library", "A code library which is imported at run time." .. _overview: Overview ---------- C and C++ applications often use 'external' functionality, such as printing specialized data types or parsing messages, which has been exported for common use. There are many possible ways for applications to call such external functionality, for instance by including an appropriate inline definition which the compiler can emit as code in each function it appears. One such way of exporting and importing such functionality is through the use of a library of code. When a compiler builds object code from source files to produce object code, the results are binary data arranged with specific calling conventions, alignments, and order suitable for a run-time environment or linker. This result defines a specific ABI. As library of code develops and its exported interfaces change over time, the resulting ABI may change as well. Therefore, care must be taken to ensure the changes made to libraries of code are effectively communicated to applications which use them. This includes informing the applications when incompatible changes are made. The Open vSwitch project exports much of its functionality through multiple such libraries of code. These libraries are intended for multiple applications to import and use. As the Open vSwitch project continues to evolve and change, its exported code will evolve as well. To ensure that applications linking to these libraries are aware of these changes, Open vSwitch employs libtool version stamps. .. _policies: ABI Policy ---------- Open vSwitch will export the ABI version at the time of release, such that the library name will be the major.minor version, and the rest of the release version information will be conveyed with a libtool interface version. The intent is for Open vSwitch to maintain an ABI stability for each minor revision only (so that Open vSwitch release 2.5 carries a guarantee for all 2.5.ZZ micro-releases). This means that any porting effort to stable branches must take not to disrupt the existing ABI. In the event that a bug must be fixed in a backwards-incompatible way, developers must bump the libtool 'current' version to inform the linker of the ABI breakage. This will signal that libraries exposed by the subsequent release will not maintain ABI stability with the previous version. Coding ------- At build time, if building shared libraries by passing the `--enable-shared` arguments to `./configure`, version information is extracted from the ``$PACKAGE_VERSION`` automake variable and formatted into the appropriate arguments. These get exported for use in Makefiles as ``$OVS_LTINFO``, and passed to each exported library along with other ``LDFLAGS``. Therefore, when adding a new library to the build system, these version flags should be included with the ``$LDFLAGS`` variable. Nothing else needs to be done. Changing an exported function definition (from a file in, for instance `lib/*.h`) is only permitted from minor release to minor release. Likewise changes to library data structures should only occur from minor release to minor release. ovs-2.13.0/Documentation/internals/contributing/submitting-patches.rst000066400000000000000000000430721362155554400263070ustar00rootroot00000000000000.. 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. ================== Submitting Patches ================== Send changes to Open vSwitch as patches to dev@openvswitch.org. One patch per email. More details are included below. If you are using Git, then `git format-patch` takes care of most of the mechanics described below for you. Before You Start ---------------- Before you send patches at all, make sure that each patch makes sense. In particular: - A given patch should not break anything, even if later patches fix the problems that it causes. The source tree should still build and work after each patch is applied. (This enables `git bisect` to work best.) - A patch should make one logical change. Don't make multiple, logically unconnected changes to disparate subsystems in a single patch. - A patch that adds or removes user-visible features should also update the appropriate user documentation or manpages. Consider adding an item to NEWS for nontrivial changes. Check "Feature Deprecation Guidelines" section in this document if you intend to remove user-visible feature. Testing is also important: - Test a patch that modifies existing code with ``make check`` before submission. Refer to the "Unit Tests" in :doc:`/topics/testing`, for more information. We also encourage running the kernel and userspace system tests. - Consider testing a patch that adds or deletes files with ``make distcheck`` before submission. - A patch that modifies Linux kernel code should be at least build-tested on various Linux kernel versions before submission. I suggest versions 3.10 and whatever the current latest release version is at the time. - A patch that adds a new feature should add appropriate tests for the feature. A bug fix patch should preferably add a test that would fail if the bug recurs. If you are using GitHub, then you may utilize the travis-ci.org CI build system by linking your GitHub repository to it. This will run some of the above tests automatically when you push changes to your repository. See the "Continuous Integration with Travis-CI" in :doc:`/topics/testing` for details on how to set it up. Email Subject ------------- The subject line of your email should be in the following format: [PATCH /] :

Where: ``[PATCH /]``: indicates that this is the nth of a series of m patches. It helps reviewers to read patches in the correct order. You may omit this prefix if you are sending only one patch. ````: indicates the area of the Open vSwitch to which the change applies (often the name of a source file or a directory). You may omit it if the change crosses multiple distinct pieces of code. ````: briefly describes the change. Use the imperative form, e.g. "Force SNAT for multiple gateway routers." or "Fix daemon exit for bad datapaths or flows." Try to keep the summary short, about 50 characters wide. The subject, minus the ``[PATCH /]`` prefix, becomes the first line of the commit's change log message. Description ----------- The body of the email should start with a more thorough description of the change. This becomes the body of the commit message, following the subject. There is no need to duplicate the summary given in the subject. Please limit lines in the description to 75 characters in width. That allows the description to format properly even when indented (e.g. by "git log" or in email quotations). The description should include: - The rationale for the change. - Design description and rationale (but this might be better added as code comments). - Testing that you performed (or testing that should be done but you could not for whatever reason). - Tags (see below). There is no need to describe what the patch actually changed, if the reader can see it for himself. If the patch refers to a commit already in the Open vSwitch repository, please include both the commit number and the subject of the patch, e.g. 'commit 632d136c (vswitch: Remove restriction on datapath names.)'. If you, the person sending the patch, did not write the patch yourself, then the very first line of the body should take the form ``From: ``, followed by a blank line. This will automatically cause the named author to be credited with authorship in the repository. Tags ---- The description ends with a series of tags, written one to a line as the last paragraph of the email. Each tag indicates some property of the patch in an easily machine-parseable manner. Please don't wrap a tag across multiple lines. If necessary, it's OK to have a tag extend beyond the customary maximum width of a commit message. Examples of common tags follow. ``Signed-off-by: Author Name `` Informally, this indicates that Author Name is the author or submitter of a patch and has the authority to submit it under the terms of the license. The formal meaning is to agree to the Developer's Certificate of Origin (see below). If the author and submitter are different, each must sign off. If the patch has more than one author, all must sign off. Signed-off-by tags should be the last tags in the commit message. If the author (or authors) and submitter are different, the author tags should come first. More generally, occasionally a patch might pass through a chain of submitters, and in such a case the sign-offs should be arranged in chronological order. :: Signed-off-by: Author Name Signed-off-by: Submitter Name ``Co-authored-by: Author Name `` Git can only record a single person as the author of a given patch. In the rare event that a patch has multiple authors, one must be given the credit in Git and the others must be credited via Co-authored-by: tags. (All co-authors must also sign off.) ``Acked-by: Reviewer Name `` Reviewers will often give an ``Acked-by:`` tag to code of which they approve. It is polite for the submitter to add the tag before posting the next version of the patch or applying the patch to the repository. Quality reviewing is hard work, so this gives a small amount of credit to the reviewer. Not all reviewers give ``Acked-by:`` tags when they provide positive reviews. It's customary only to add tags from reviewers who actually provide them explicitly. ``Tested-by: Tester Name `` When someone tests a patch, it is customary to add a Tested-by: tag indicating that. It's rare for a tester to actually provide the tag; usually the patch submitter makes the tag himself in response to an email indicating successful testing results. ``Tested-at: `` When a test report is publicly available, this provides a way to reference it. Typical s would be build logs from autobuilders or references to mailing list archives. Some autobuilders only retain their logs for a limited amount of time. It is less useful to cite these because they may be dead links for a developer reading the commit message months or years later. ``Reported-by: Reporter Name `` When a patch fixes a bug reported by some person, please credit the reporter in the commit log in this fashion. Please also add the reporter's name and email address to the list of people who provided helpful bug reports in the AUTHORS file at the top of the source tree. Fairly often, the reporter of a bug also tests the fix. Occasionally one sees a combined "Reported-and-tested-by:" tag used to indicate this. It is also acceptable, and more common, to include both tags separately. (If a bug report is received privately, it might not always be appropriate to publicly credit the reporter. If in doubt, please ask the reporter.) ``Requested-by: Requester Name `` When a patch implements a request or a suggestion made by some person, please credit that person in the commit log in this fashion. For a helpful suggestion, please also add the person's name and email address to the list of people who provided suggestions in the AUTHORS file at the top of the source tree. (If a suggestion or a request is received privately, it might not always be appropriate to publicly give credit. If in doubt, please ask.) ``Suggested-by: Suggester Name `` See ``Requested-by:``. ``CC: Person `` This is a way to tag a patch for the attention of a person when no more specific tag is appropriate. One use is to request a review from a particular person. It doesn't make sense to include the same person in CC and another tag, so e.g. if someone who is CCed later provides an Acked-by, add the Acked-by and remove the CC at the same time. ``Reported-at: `` If a patch fixes or is otherwise related to a bug reported in a public bug tracker, please include a reference to the bug in the form of a URL to the specific bug, e.g.: :: Reported-at: https://bugs.debian.org/743635 This is also an appropriate way to refer to bug report emails in public email archives, e.g.: :: Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2014-June/284495.html ``Submitted-at: `` If a patch was submitted somewhere other than the Open vSwitch development mailing list, such as a GitHub pull request, this header can be used to reference the source. :: Submitted-at: https://github.com/openvswitch/ovs/pull/92 ``VMware-BZ: #1234567`` If a patch fixes or is otherwise related to a bug reported in a private bug tracker, you may include some tracking ID for the bug for your own reference. Please include some identifier to make the origin clear, e.g. "VMware-BZ" refers to VMware's internal Bugzilla instance and "ONF-JIRA" refers to the Open Networking Foundation's JIRA bug tracker. ``ONF-JIRA: EXT-12345`` See ``VMware-BZ:``. ``Bug #1234567.`` These are obsolete forms of VMware-BZ: that can still be seen in old change log entries. (They are obsolete because they do not tell the reader what bug tracker is referred to.) ``Issue: 1234567`` See ``Bug:``. ``Fixes: 63bc9fb1c69f (“packets: Reorder CS_* flags to remove gap.”)`` If you would like to record which commit introduced a bug being fixed, you may do that with a “Fixes” header. This assists in determining which OVS releases have the bug, so the patch can be applied to all affected versions. The easiest way to generate the header in the proper format is with this git command. This command also CCs the author of the commit being fixed, which makes sense unless the author also made the fix or is already named in another tag: :: $ git log -1 --pretty=format:"CC: %an <%ae>%nFixes: %h (\"%s\")" \ --abbrev=12 COMMIT_REF ``Vulnerability: CVE-2016-2074`` Specifies that the patch fixes or is otherwise related to a security vulnerability with the given CVE identifier. Other identifiers in public vulnerability databases are also suitable. If the vulnerability was reported publicly, then it is also appropriate to cite the URL to the report in a Reported-at tag. Use a Reported-by tag to acknowledge the reporters. Developer's Certificate of Origin --------------------------------- To help track the author of a patch as well as the submission chain, and be clear that the developer has authority to submit a patch for inclusion in Open vSwitch please sign off your work. The sign off certifies the following: :: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. See also http://developercertificate.org/. Feature Deprecation Guidelines ------------------------------ Open vSwitch is intended to be user friendly. This means that under normal circumstances we don't abruptly remove features from OVS that some users might still be using. Otherwise, if we would, then we would possibly break our user setup when they upgrade and would receive bug reports. Typical process to deprecate a feature in Open vSwitch is to: (a) Mention deprecation of a feature in the NEWS file. Also, mention expected release or absolute time when this feature would be removed from OVS altogether. Don't use relative time (e.g. "in 6 months") because that is not clearly interpretable. (b) If Open vSwitch is configured to use deprecated feature it should print a warning message to the log files clearly indicating that feature is deprecated and that use of it should be avoided. (c) If this feature is mentioned in man pages, then add "Deprecated" keyword to it. Also, if there is alternative feature to the one that is about to be marked as deprecated, then mention it in (a), (b) and (c) as well. Remember to follow-up and actually remove the feature from OVS codebase once deprecation grace period has expired and users had opportunity to use at least one OVS release that would have informed them about feature deprecation! Comments -------- If you want to include any comments in your email that should not be part of the commit's change log message, put them after the description, separated by a line that contains just ``---``. It may be helpful to include a diffstat here for changes that touch multiple files. Patch ----- The patch should be in the body of the email following the description, separated by a blank line. Patches should be in ``diff -up`` format. We recommend that you use Git to produce your patches, in which case you should use the ``-M -C`` options to ``git diff`` (or other Git tools) if your patch renames or copies files. `Quilt `__ might be useful if you do not want to use Git. Patches should be inline in the email message. Some email clients corrupt white space or wrap lines in patches. There are hints on how to configure many email clients to avoid this problem on `kernel.org `__. If you cannot convince your email client not to mangle patches, then sending the patch as an attachment is a second choice. Follow the style used in the code that you are modifying. :doc:`coding-style` file describes the coding style used in most of Open vSwitch. Use Linux kernel coding style for Linux kernel code. If your code is non-datapath code, you may use the ``utilities/checkpatch.py`` utility as a quick check for certain commonly occurring mistakes (improper leading/trailing whitespace, missing signoffs, some improper formatted patch files). For Linux datapath code, it is a good idea to use the Linux script ``checkpatch.pl``. Example ------- :: From fa29a1c2c17682879e79a21bb0cdd5bbe67fa7c0 Mon Sep 17 00:00:00 2001 From: Jesse Gross Date: Thu, 8 Dec 2011 13:17:24 -0800 Subject: [PATCH] datapath: Alphabetize include/net/ipv6.h compat header. Signed-off-by: Jesse Gross --- datapath/linux/Modules.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/datapath/linux/Modules.mk b/datapath/linux/Modules.mk index fdd952e..f6cb88e 100644 --- a/datapath/linux/Modules.mk +++ b/datapath/linux/Modules.mk @@ -56,11 +56,11 @@ openvswitch_headers += \ linux/compat/include/net/dst.h \ linux/compat/include/net/genetlink.h \ linux/compat/include/net/ip.h \ + linux/compat/include/net/ipv6.h \ linux/compat/include/net/net_namespace.h \ linux/compat/include/net/netlink.h \ linux/compat/include/net/protocol.h \ linux/compat/include/net/route.h \ - linux/compat/include/net/ipv6.h \ linux/compat/genetlink.inc both_modules += brcompat -- 1.7.7.3 ovs-2.13.0/Documentation/internals/documentation.rst000066400000000000000000000060431362155554400226340ustar00rootroot00000000000000.. Copyright (c) 2017 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. ====================================== How Open vSwitch's Documentation Works ====================================== This document provides a brief overview on how the documentation build system within Open vSwitch works. This is intended to maximize the "bus factor" and share best practices with other projects. reStructuredText and Sphinx --------------------------- Nearly all of Open vSwitch's documentation is written in `reStructuredText`__, with man pages being the sole exception. Of this documentation, most of it is fed into `Sphinx`__, which provides not only the ability to convert rST to a variety of other output formats but also allows for things like cross-referencing and indexing. for more information on the two, refer to the :doc:`contributing/documentation-style`. ovs-sphinx-theme ---------------- The documentation uses its own theme, `ovs-sphinx-theme`, which can be found on GitHub__ and is published on pypi__. This is packaged separately from Open vSwitch itself to ensure all documentation gets the latest version of the theme (assuming there are no major version bumps in that package). If building locally and the package is installed, it will be used. If the package is not installed, Sphinx will fallback to the default theme. The package is currently maintained by Stephen Finucane and Russell Bryant. Read the Docs ------------- The documentation is hosted on readthedocs.org and a CNAME redirect is in place to allow access from docs.openvswitch.org. *Read the Docs* provides a couple of nifty features for us, such as automatic building of docs whenever there are changes and versioning of documentation. The *Read the Docs* project is currently maintained by Stephen Finucane, Russell Bryant and Ben Pfaff. openvswitch.org --------------- The sources for openvswitch.org are maintained separately from docs.openvswitch.org. For modifications to this site, refer to the `GitHub project`__. __ http://docutils.sourceforge.net/rst.html __ http://www.sphinx-doc.org/ __ https://github.com/openvswitch/ovs-sphinx-theme __ https://pypi.python.org/pypi/ovs-sphinx-theme __ https://github.com/openvswitch/openvswitch.github.io ovs-2.13.0/Documentation/internals/index.rst000066400000000000000000000025521362155554400210730ustar00rootroot00000000000000.. 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. ====================== Open vSwitch Internals ====================== Information for people who want to know more about the Open vSwitch project itself and how they might involved. .. toctree:: :maxdepth: 2 contributing/index mailing-lists patchwork release-process bugs security charter committer-emeritus-status committer-responsibilities committer-grant-revocation authors maintainers documentation ovs-2.13.0/Documentation/internals/mailing-lists.rst000066400000000000000000000055601362155554400225420ustar00rootroot00000000000000.. 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. ============= Mailing Lists ============= .. important:: Report security issues **only** to security@openvswitch.org. For more information, refer to our :doc:`security policies `. ovs-announce ------------ The `ovs-announce`__ mailing list is used to announce new versions of Open vSwitch and is extremely low-volume. `(subscribe)`__ `(archives)`__ __ mailto:ovs-announce@openvswitch.org __ https://mail.openvswitch.org/mailman/listinfo/ovs-announce/ __ https://mail.openvswitch.org/pipermail/ovs-announce/ ovs-discuss ----------- The `ovs-discuss`__ mailing list is used to discuss plans and design decisions for Open vSwitch. It is also an appropriate place for user questions. `(subscribe)`__ `(archives)`__ __ mailto:ovs-discuss@openvswitch.org __ https://mail.openvswitch.org/mailman/listinfo/ovs-discuss/ __ https://mail.openvswitch.org/pipermail/ovs-discuss/ ovs-dev ------- The `ovs-dev`__ mailing list is used to discuss development and review code before being committed. `(subscribe)`__ `(archives)`__ __ mailto:ovs-dev@openvswitch.org __ https://mail.openvswitch.org/mailman/listinfo/ovs-dev/ __ https://mail.openvswitch.org/pipermail/ovs-dev/ ovs-git ------- The `ovs-git`__ mailing list hooks into Open vSwitch's version control system to receive commits. `(subscribe)`__ `(archives)`__ __ mailto:ovs-git@openvswitch.org __ https://mail.openvswitch.org/mailman/listinfo/ovs-git/ __ https://mail.openvswitch.org/pipermail/ovs-git/ ovs-build --------- The `ovs-build`__ mailing list hooks into Open vSwitch's continuous integration system to receive build reports. `(subscribe)`__ `(archives)`__ __ mailto:ovs-build@openvswitch.org __ https://mail.openvswitch.org/mailman/listinfo/ovs-build/ __ https://mail.openvswitch.org/pipermail/ovs-build/ bugs ----- The `bugs`__ mailing list is an alias for the discuss mailing list. __ mailto:bugs@openvswitch.org security -------- The `security`__ mailing list is for submitting security vulnerabilities to the security team. __ mailto:security@openvswitch.org ovs-2.13.0/Documentation/internals/maintainers.rst000066400000000000000000000016161362155554400222760ustar00rootroot00000000000000.. 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. .. include:: ../../MAINTAINERS.rst ovs-2.13.0/Documentation/internals/patchwork.rst000066400000000000000000000055151362155554400217700ustar00rootroot00000000000000.. 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. ========= Patchwork ========= Open vSwitch uses `Patchwork`__ to track the status of patches sent to the :doc:`ovs-dev mailing list `. The Open vSwitch Patchwork instance can be found on `ozlabs.org`__. Patchwork provides a number of useful features for developers working on Open vSwitch: - Tracking the lifecycle of patches (accepted, rejected, under-review, ...) - Assigning reviewers (delegates) to patches - Downloading/applying patches, series, and bundles via the web UI or the REST API (see :ref:`git-pw`) - A usable UI for viewing patch discussions __ https://github.com/getpatchwork/patchwork __ https://patchwork.ozlabs.org/project/openvswitch/list/ .. _git-pw: git-pw ------ The *git-pw* tool provides a way to download and apply patches, series, and bundles. You can install *git-pw* from `PyPi`__ like so:: $ pip install --user git-pw To actually use *git-pw*, you must configure it with the Patchwork instance URL, Patchwork project, and your Patchwork user authentication token. The URL and project are provided below, but you must obtain your authentication token from your `Patchwork User Profile`__ page. If you do not already have a Patchwork user account, you should create one now. Once your token is obtained, configure *git-pw* as below. Note that this must be run from within the Open vSwitch Git repository:: $ git config pw.server https://patchwork.ozlabs.org/ $ git config pw.project openvswitch $ git config pw.token $PW_TOKEN # using the token obtained earlier Once configured, run the following to get information about available commands:: $ git pw --help __ https://pypi.python.org/pypi/git-pw __ https://patchwork.ozlabs.org/user/ .. _pwclient: pwclient -------- The *pwclient* is a legacy tool that provides some of the functionality of *git-pw* but uses the legacy XML-RPC API. It is considered deprecated in its current form and *git-pw* should be used instead. ovs-2.13.0/Documentation/internals/release-process.rst000066400000000000000000000142611362155554400230600ustar00rootroot00000000000000.. 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 Release Process ============================ This document describes the process ordinarily used for Open vSwitch development and release. Exceptions are sometimes necessary, so all of the statements here should be taken as subject to change through rough consensus of Open vSwitch contributors, obtained through public discussion on, e.g., ovs-dev or the #openvswitch IRC channel. Release Strategy ---------------- Open vSwitch feature development takes place on the "master" branch. Ordinarily, new features are rebased against master and applied directly. For features that take significant development, sometimes it is more appropriate to merge a separate branch into master; please discuss this on ovs-dev in advance. The process of making a release has the following stages. See `Release Scheduling`_ for the timing of each stage: 1. "Soft freeze" of the master branch. During the freeze, we ask committers to refrain from applying patches that add new features unless those patches were already being publicly discussed and reviewed before the freeze began. Bug fixes are welcome at any time. Please propose and discuss exceptions on ovs-dev. 2. Fork a release branch from master, named for the expected release number, e.g. "branch-2.3" for the branch that will yield Open vSwitch 2.3.x. Release branches are intended for testing and stabilization. At this stage and in later stages, they should receive only bug fixes, not new features. Bug fixes applied to release branches should be backports of corresponding bug fixes to the master branch, except for bugs present only on release branches (which are rare in practice). At this stage, sometimes there can be exceptions to the rule that a release branch receives only bug fixes. Like bug fixes, new features on release branches should be backports of the corresponding commits on the master branch. Features to be added to release branches should be limited in scope and risk and discussed on ovs-dev before creating the branch. 3. When committers come to rough consensus that the release is ready, they release the .0 release on its branch, e.g. 2.3.0 for branch-2.3. To make the actual release, a committer pushes a signed tag named, e.g. v2.3.0, to the Open vSwitch repository, makes a release tarball available on openvswitch.org, and posts a release announcement to ovs-announce. 4. As bug fixes accumulate, or after important bugs or vulnerabilities are fixed, committers may make additional releases from a branch: 2.3.1, 2.3.2, and so on. The process is the same for these additional release as for a .0 release. At most two release branches are formally maintained at any given time: the latest release and the latest release designed as LTS. An LTS release is one that the OVS project has designated as being maintained for a longer period of time. Currently, an LTS release is maintained until the next LTS is chosen. There is not currently a strict guideline on how often a new LTS release is chosen, but so far it has been about every 2 years. That could change based on the current state of OVS development. For example, we do not want to designate a new release as LTS that includes disruptive internal changes, as that may make it harder to support for a longer period of time. Discussion about choosing the next LTS release occurs on the OVS development mailing list. Release Numbering ----------------- The version number on master should normally end in .90. This indicates that the Open vSwitch version is "almost" the next version to branch. Forking master into branch-x.y requires two commits to master. The first is titled "Prepare for x.y.0" and increments the version number to x.y. This is the initial commit on branch-x.y. The second is titled "Prepare for post-x.y.0 (x.y.90)" and increments the version number to x.y.90. The version number on a release branch is x.y.z, where z is initially 0. Making a release requires two commits. The first is titled *Set release dates for x.y.z.* and updates NEWS and debian/changelog to specify the release date of the new release. This commit is the one made into a tarball and tagged. The second is titled *Prepare for x.y.(z+1).* and increments the version number and adds a blank item to NEWS with an unspecified date. Release Scheduling ------------------ Open vSwitch makes releases at the following six-month cadence. All dates are approximate: +---------------+----------------+--------------------------------------+ | Time (months) | Dates | Stage | +---------------+----------------+--------------------------------------+ | T | Mar 1, Sep 1 | Begin x.y release cycle | +---------------+----------------+--------------------------------------+ | T + 4 | Jul 1, Jan 1 | "Soft freeze" master for x.y release | +---------------+----------------+--------------------------------------+ | T + 4.5 | Jul 15, Jan 15 | Fork branch-x.y from master | +---------------+----------------+--------------------------------------+ | T + 5.5 | Aug 15, Feb 15 | Release version x.y.0 | +---------------+----------------+--------------------------------------+ Contact ------- Use dev@openvswitch.org to discuss the Open vSwitch development and release process. ovs-2.13.0/Documentation/internals/security.rst000066400000000000000000000270141362155554400216330ustar00rootroot00000000000000.. 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's Security Process =============================== This is a proposed security vulnerability reporting and handling process for Open vSwitch. It is based on the OpenStack vulnerability management process described at https://wiki.openstack.org/wiki/Vulnerability\_Management. The OVS security team coordinates vulnerability management using the ovs-security mailing list. Membership in the security team and subscription to its mailing list consists of a small number of trustworthy people, as determined by rough consensus of the Open vSwitch committers on the ovs-committers mailing list. The Open vSwitch security team should include Open vSwitch committers, to ensure prompt and accurate vulnerability assessments and patch review. We encourage everyone involved in the security process to GPG-sign their emails. We additionally encourage GPG-encrypting one-on-one conversations as part of the security process. What is a vulnerability? ------------------------ All vulnerabilities are bugs, but not every bug is a vulnerability. Vulnerabilities compromise one or more of: * Confidentiality (personal or corporate confidential data). * Integrity (trustworthiness and correctness). * Availability (uptime and service). Here are some examples of vulnerabilities to which one would expect to apply this process: * A crafted packet that causes a kernel or userspace crash (Availability). * A flow translation bug that misforwards traffic in a way likely to hop over security boundaries (Integrity). * An OpenFlow protocol bug that allows a controller to read arbitrary files from the file system (Confidentiality). * Misuse of the OpenSSL library that allows bypassing certificate checks (Integrity). * A bug (memory corruption, overflow, ...) that allows one to modify the behaviour of OVS through external configuration interfaces such as OVSDB (Integrity). * Privileged information is exposed to unprivileged users (Confidentiality). If in doubt, please do use the vulnerability management process. At worst, the response will be to report the bug through the usual channels. Step 1: Reception ----------------- To report an Open vSwitch vulnerability, send an email to the ovs-security mailing list (see contact_ at the end of this document). A security team member should reply to the reporter acknowledging that the report has been received. Consider reporting the information mentioned in :doc:`bugs`, where relevant. Reporters may ask for a GPG key while initiating contact with the security team to deliver more sensitive reports. The Linux kernel has `its own vulnerability management process `__. Handling of vulnerabilities that affect both the Open vSwitch tree and the upstream Linux kernel should be reported through both processes. Send your report as a single email to both the kernel and OVS security teams to allow those teams to most easily coordinate among themselves. Step 2: Assessment ------------------ The security team should discuss the vulnerability. The reporter should be included in the discussion (via "CC") to an appropriate degree. The assessment should determine which Open vSwitch versions are affected (e.g. every version, only the latest release, only unreleased versions), the privilege required to take advantage of the vulnerability (e.g. any network user, any local L2 network user, any local system user, connected OpenFlow controllers), the severity of the vulnerability, and how the vulnerability may be mitigated (e.g. by disabling a feature). The treatment of the vulnerability could end here if the team determines that it is not a realistic vulnerability. Step 3a: Document ----------------- The security team develops a security advisory document. The security team may, at its discretion, include the reporter (via "CC") in developing the security advisory document, but in any case should accept feedback from the reporter before finalizing the document. When the document is final, the security team should obtain a CVE for the vulnerability from a CNA (https://cve.mitre.org/cve/cna.html). The document credits the reporter and describes the vulnerability, including all of the relevant information from the assessment in step 2. Suitable sections for the document include: :: * Title: The CVE identifier, a short description of the vulnerability. The title should mention Open vSwitch. In email, the title becomes the subject. Pre-release advisories are often passed around in encrypted email, which have plaintext subjects, so the title should not be too specific. * Description: A few paragraphs describing the general characteristics of the vulnerability, including the versions of Open vSwitch that are vulnerable, the kind of attack that exposes the vulnerability, and potential consequences of the attack. The description should re-state the CVE identifier, in case the subject is lost when an advisory is sent over email. * Mitigation: How an Open vSwitch administrator can minimize the potential for exploitation of the vulnerability, before applying a fix. If no mitigation is possible or recommended, explain why, to reduce the chance that at-risk users believe they are not at risk. * Fix: Describe how to fix the vulnerability, perhaps in terms of applying a source patch. The patch or patches themselves, if included in the email, should be at the very end of the advisory to reduce the risk that a reader would stop reading at this point. * Recommendation: A concise description of the security team's recommendation to users. * Acknowledgments: Thank the reporters. * Vulnerability Check: A step-by-step procedure by which a user can determine whether an installed copy of Open vSwitch is vulnerable. The procedure should clearly describe how to interpret the results, including expected results in vulnerable and not-vulnerable cases. Thus, procedures that produce clear and easily distinguished results are preferred. The procedure should assume as little understanding of Open vSwitch as possible, to make it more likely that a competent administrator who does not specialize in Open vSwitch can perform it successfully. The procedure should have minimal dependencies on tools that are not widely installed. Given a choice, the procedure should be one that takes at least some work to turn into a useful exploit. For example, a procedure based on "ovs-appctl" commands, which require local administrator access, is preferred to one that sends test packets to a machine, which only requires network connectivity. The section should say which operating systems it is designed for. If the procedure is likely to be specific to particular architectures (e.g. x86-64, i386), it should state on which ones it has been tested. This section should state the risks of the procedure. For example, if it can crash Open vSwitch or disrupt packet forwarding, say so. It is more useful to explain how to check an installed and running Open vSwitch than one built locally from source, but if it is easy to use the procedure from a sandbox environment, it can be helpful to explain how to do so. * Patch: If a patch or patches are available, and it is practical to include them in the email, put them at the end. Format them as described in :doc:`contributing/submitting-patches`, that is, as output by "git format-patch". The patch subjects should include the version for which they are suited, e.g. "[PATCH branch-2.3]" for a patch against Open vSwitch 2.3.x. If there are multiple patches for multiple versions of Open vSwitch, put them in separate sections with clear titles. Multiple patches for a single version of Open vSwitch, that must be stacked on top of each other to fix a single vulnerability, are undesirable because users are less likely to apply all of them correctly and in the correct order. Each patch should include a Vulnerability tag with the CVE identifier, a Reported-by tag or tags to credit the reporters, and a Signed-off-by tag to acknowledge the Developer's Certificate of Origin. It should also include other appropriate tags, such as Acked-by tags obtained during review. `CVE-2016-2074 `__ is an example advisory document. Step 3b: Fix ------------ Steps 3a and 3b may proceed in parallel. The security team develops and obtains (private) reviews for patches that fix the vulnerability. If necessary, the security team pulls in additional developers, who must agree to maintain confidentiality. Step 4: Embargoed Disclosure ---------------------------- The security advisory and patches are sent to downstream stakeholders, with an embargo date and time set from the time sent. Downstream stakeholders are expected not to deploy or disclose patches until the embargo is passed. A disclosure date is negotiated by the security team working with the bug submitter as well as vendors. However, the Open vSwitch security team holds the final say when setting a disclosure date. The timeframe for disclosure is from immediate (esp. if it's already publicly known) to a few weeks. As a basic default policy, we expect report date to disclosure date to be 10 to 15 business days. Operating system vendors are obvious downstream stakeholders. It may not be necessary to be too choosy about who to include: any major Open vSwitch user who is interested and can be considered trustworthy enough could be included. To become a downstream stakeholder, email the ovs-security mailing list. If the vulnerability is already public, skip this step. Step 5: Public Disclosure ------------------------- When the embargo expires, push the (reviewed) patches to appropriate branches, post the patches to the ovs-dev mailing list (noting that they have already been reviewed and applied), post the security advisory to appropriate mailing lists (ovs-announce, ovs-discuss), and post the security advisory on the Open vSwitch webpage. When the patch is applied to LTS (long-term support) branches, a new version should be released. The security advisory should be GPG-signed by a security team member with a key that is in a public web of trust. .. _contact: Contact ======= Report security vulnerabilities to the ovs-security mailing list: security@openvswitch.org Report problems with this document to the ovs-bugs mailing list: bugs@openvswitch.org ovs-2.13.0/Documentation/intro/000077500000000000000000000000001362155554400163625ustar00rootroot00000000000000ovs-2.13.0/Documentation/intro/index.rst000066400000000000000000000021141362155554400202210ustar00rootroot00000000000000.. 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. =============== Getting Started =============== How to get started with Open vSwitch. .. toctree:: :maxdepth: 2 what-is-ovs why-ovs install/index ovs-2.13.0/Documentation/intro/install/000077500000000000000000000000001362155554400200305ustar00rootroot00000000000000ovs-2.13.0/Documentation/intro/install/afxdp.rst000066400000000000000000000337051362155554400216740ustar00rootroot00000000000000.. 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 with AF_XDP ======================== This document describes how to build and install Open vSwitch using AF_XDP netdev. .. warning:: The AF_XDP support of Open vSwitch is considered 'experimental', and it is not compiled in by default. Introduction ------------ AF_XDP, Address Family of the eXpress Data Path, is a new Linux socket type built upon the eBPF and XDP technology. It is aims to have comparable performance to DPDK but cooperate better with existing kernel's networking stack. An AF_XDP socket receives and sends packets from an eBPF/XDP program attached to the netdev, by-passing a couple of Linux kernel's subsystems. As a result, AF_XDP socket shows much better performance than AF_PACKET. For more details about AF_XDP, please see linux kernel's Documentation/networking/af_xdp.rst AF_XDP Netdev ------------- OVS has a couple of netdev types, i.e., system, tap, or dpdk. The AF_XDP feature adds a new netdev types called "afxdp", and implement its configuration, packet reception, and transmit functions. Since the AF_XDP socket, called xsk, operates in userspace, once ovs-vswitchd receives packets from xsk, the afxdp netdev re-uses the existing userspace dpif-netdev datapath. As a result, most of the packet processing happens at the userspace instead of linux kernel. :: | +-------------------+ | | ovs-vswitchd |<-->ovsdb-server | +-------------------+ | | ofproto |<-->OpenFlow controllers | +--------+-+--------+ | | netdev | |ofproto-| userspace | +--------+ | dpif | | | afxdp | +--------+ | | netdev | | dpif | | +---||---+ +--------+ | || | dpif- | | || | netdev | |_ || +--------+ || _ +---||-----+--------+ | | AF_XDP prog + | kernel | | xsk_map | |_ +--------||---------+ || physical NIC Build requirements ------------------ In addition to the requirements described in :doc:`general`, building Open vSwitch with AF_XDP will require the following: - libbpf from kernel source tree (kernel 5.0.0 or later) - Linux kernel XDP support, with the following options (required) * CONFIG_BPF=y * CONFIG_BPF_SYSCALL=y * CONFIG_XDP_SOCKETS=y - The following optional Kconfig options are also recommended, but not required: * CONFIG_BPF_JIT=y (Performance) * CONFIG_HAVE_BPF_JIT=y (Performance) * CONFIG_XDP_SOCKETS_DIAG=y (Debugging) - Once your AF_XDP-enabled kernel is ready, if possible, run **./xdpsock -r -N -z -i ** under linux/samples/bpf. This is an OVS independent benchmark tools for AF_XDP. It makes sure your basic kernel requirements are met for AF_XDP. Installing ---------- For OVS to use AF_XDP netdev, it has to be configured with LIBBPF support. First, clone a recent version of Linux bpf-next tree:: git clone git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git Second, go into the Linux source directory and build libbpf in the tools directory:: cd bpf-next/ cd tools/lib/bpf/ make && make install make install_headers .. note:: Make sure xsk.h and bpf.h are installed in system's library path, e.g. /usr/local/include/bpf/ or /usr/include/bpf/ Make sure the libbpf.so is installed correctly:: ldconfig ldconfig -p | grep libbpf Third, ensure the standard OVS requirements are installed and bootstrap/configure the package:: ./boot.sh && ./configure --enable-afxdp Finally, build and install OVS:: make && make install To kick start end-to-end autotesting:: uname -a # make sure having 5.0+ kernel make check-afxdp TESTSUITEFLAGS='1' .. note:: Not all test cases pass at this time. Currenly all cvlan tests are skipped due to kernel issues. If a test case fails, check the log at:: cat \ tests/system-afxdp-testsuite.dir//system-afxdp-testsuite.log Setup AF_XDP netdev ------------------- Before running OVS with AF_XDP, make sure the libbpf, libelf, and libnuma are set-up right:: ldd vswitchd/ovs-vswitchd Open vSwitch should be started using userspace datapath as described in :doc:`general`:: ovs-vswitchd ... ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev Make sure your device driver support AF_XDP, netdev-afxdp supports the following additional options (see ``man ovs-vswitchd.conf.db`` for more details): * ``xdp-mode``: ``best-effort``, ``native-with-zerocopy``, ``native`` or ``generic``. Defaults to ``best-effort``, i.e. best of supported modes, so in most cases you don't need to change it. * ``use-need-wakeup``: default ``true`` if libbpf supports it, otherwise ``false``. For example, to use 1 PMD (on core 4) on 1 queue (queue 0) device, configure these options: ``pmd-cpu-mask``, ``pmd-rxq-affinity``, and ``n_rxq``:: ethtool -L enp2s0 combined 1 ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10 ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp" \ other_config:pmd-rxq-affinity="0:4" Or, use 4 pmds/cores and 4 queues by doing:: ethtool -L enp2s0 combined 4 ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x36 ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp" \ options:n_rxq=4 other_config:pmd-rxq-affinity="0:1,1:2,2:3,3:4" .. note:: ``pmd-rxq-affinity`` is optional. If not specified, system will auto-assign. ``n_rxq`` equals ``1`` by default. To validate that the bridge has successfully instantiated, you can use the:: ovs-vsctl show Should show something like:: Port "ens802f0" Interface "ens802f0" type: afxdp options: {n_rxq="1"} Otherwise, enable debugging by:: ovs-appctl vlog/set netdev_afxdp::dbg To check which XDP mode was chosen by ``best-effort``, you can look for ``xdp-mode-in-use`` in the output of ``ovs-appctl dpctl/show``:: # ovs-appctl dpctl/show netdev@ovs-netdev: <...> port 2: ens802f0 (afxdp: n_rxq=1, use-need-wakeup=true, xdp-mode=best-effort, xdp-mode-in-use=native-with-zerocopy) References ---------- Most of the design details are described in the paper presented at Linux Plumber 2018, "Bringing the Power of eBPF to Open vSwitch"[1], section 4, and slides[2][4]. "The Path to DPDK Speeds for AF XDP"[3] gives a very good introduction about AF_XDP current and future work. [1] http://vger.kernel.org/lpc_net2018_talks/ovs-ebpf-afxdp.pdf [2] http://vger.kernel.org/lpc_net2018_talks/ovs-ebpf-lpc18-presentation.pdf [3] http://vger.kernel.org/lpc_net2018_talks/lpc18_paper_af_xdp_perf-v2.pdf [4] https://ovsfall2018.sched.com/event/IO7p/fast-userspace-ovs-with-afxdp Performance Tuning ------------------ The name of the game is to keep your CPU running in userspace, allowing PMD to keep polling the AF_XDP queues without any interferences from kernel. #. Make sure everything is in the same NUMA node (memory used by AF_XDP, pmd running cores, device plug-in slot) #. Isolate your CPU by doing isolcpu at grub configure. #. IRQ should not set to pmd running core. #. The Spectre and Meltdown fixes increase the overhead of system calls. Debugging performance issue ~~~~~~~~~~~~~~~~~~~~~~~~~~~ While running the traffic, use linux perf tool to see where your cpu spends its cycle:: cd bpf-next/tools/perf make ./perf record -p `pidof ovs-vswitchd` sleep 10 ./perf report Measure your system call rate by doing:: pstree -p `pidof ovs-vswitchd` strace -c -p Or, use OVS pmd tool:: ovs-appctl dpif-netdev/pmd-stats-show Example Script -------------- Below is a script using namespaces and veth peer:: #!/bin/bash ovs-vswitchd --no-chdir --pidfile -vvconn -vofproto_dpif -vunixctl \ --disable-system --detach \ ovs-vsctl -- add-br br0 -- set Bridge br0 \ protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13,OpenFlow14 \ fail-mode=secure datapath_type=netdev ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev ip netns add at_ns0 ovs-appctl vlog/set netdev_afxdp::dbg ip link add p0 type veth peer name afxdp-p0 ip link set p0 netns at_ns0 ip link set dev afxdp-p0 up ovs-vsctl add-port br0 afxdp-p0 -- \ set interface afxdp-p0 external-ids:iface-id="p0" type="afxdp" ip netns exec at_ns0 sh << NS_EXEC_HEREDOC ip addr add "10.1.1.1/24" dev p0 ip link set dev p0 up NS_EXEC_HEREDOC ip netns add at_ns1 ip link add p1 type veth peer name afxdp-p1 ip link set p1 netns at_ns1 ip link set dev afxdp-p1 up ovs-vsctl add-port br0 afxdp-p1 -- \ set interface afxdp-p1 external-ids:iface-id="p1" type="afxdp" ip netns exec at_ns1 sh << NS_EXEC_HEREDOC ip addr add "10.1.1.2/24" dev p1 ip link set dev p1 up NS_EXEC_HEREDOC ip netns exec at_ns0 ping -i .2 10.1.1.2 Limitations/Known Issues ------------------------ #. No QoS support because AF_XDP netdev by-pass the Linux TC layer. A possible work-around is to use OpenFlow meter action. #. Most of the tests are done using i40e single port. Multiple ports and also ixgbe driver also needs to be tested. #. No latency test result (TODO items) #. Due to limitations of current upstream kernel, various offloading (vlan, cvlan) is not working over virtual interfaces (i.e. veth pair). Also, TCP is not working over virtual interfaces (veth) in generic XDP mode. Some more information and possible workaround available `here `__ . For TAP interfaces generic mode seems to work fine (TCP works) and even could provide better performance than native mode in some cases. PVP using tap device -------------------- Assume you have enp2s0 as physical nic, and a tap device connected to VM. First, start OVS, then add physical port:: ethtool -L enp2s0 combined 1 ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x10 ovs-vsctl add-port br0 enp2s0 -- set interface enp2s0 type="afxdp" \ options:n_rxq=1 other_config:pmd-rxq-affinity="0:4" Start a VM with virtio and tap device:: qemu-system-x86_64 -hda ubuntu1810.qcow \ -m 4096 \ -cpu host,+x2apic -enable-kvm \ -device virtio-net-pci,mac=00:02:00:00:00:01,netdev=net0,mq=on,\ vectors=10,mrg_rxbuf=on,rx_queue_size=1024 \ -netdev type=tap,id=net0,vhost=on,queues=8 \ -object memory-backend-file,id=mem,size=4096M,\ mem-path=/dev/hugepages,share=on \ -numa node,memdev=mem -mem-prealloc -smp 2 Create OpenFlow rules:: ovs-vsctl add-port br0 tap0 -- set interface tap0 ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "in_port=enp2s0, actions=output:tap0" ovs-ofctl add-flow br0 "in_port=tap0, actions=output:enp2s0" Inside the VM, use xdp_rxq_info to bounce back the traffic:: ./xdp_rxq_info --dev ens3 --action XDP_TX PVP using vhostuser device -------------------------- First, build OVS with DPDK and AFXDP:: ./configure --enable-afxdp --with-dpdk= make -j4 && make install Create a vhost-user port from OVS:: ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true ovs-vsctl -- add-br br0 -- set Bridge br0 datapath_type=netdev \ other_config:pmd-cpu-mask=0xfff ovs-vsctl add-port br0 vhost-user-1 \ -- set Interface vhost-user-1 type=dpdkvhostuser Start VM using vhost-user mode:: qemu-system-x86_64 -hda ubuntu1810.qcow \ -m 4096 \ -cpu host,+x2apic -enable-kvm \ -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/vhost-user-1 \ -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce,queues=4 \ -device virtio-net-pci,mac=00:00:00:00:00:01,\ netdev=mynet1,mq=on,vectors=10 \ -object memory-backend-file,id=mem,size=4096M,\ mem-path=/dev/hugepages,share=on \ -numa node,memdev=mem -mem-prealloc -smp 2 Setup the OpenFlow ruls:: ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "in_port=enp2s0, actions=output:vhost-user-1" ovs-ofctl add-flow br0 "in_port=vhost-user-1, actions=output:enp2s0" Inside the VM, use xdp_rxq_info to drop or bounce back the traffic:: ./xdp_rxq_info --dev ens3 --action XDP_DROP ./xdp_rxq_info --dev ens3 --action XDP_TX PCP container using veth ------------------------ Create namespace and veth peer devices:: ip netns add at_ns0 ip link add p0 type veth peer name afxdp-p0 ip link set p0 netns at_ns0 ip link set dev afxdp-p0 up ip netns exec at_ns0 ip link set dev p0 up Attach the veth port to br0 (linux kernel mode):: ovs-vsctl add-port br0 afxdp-p0 -- set interface afxdp-p0 Or, use AF_XDP:: ovs-vsctl add-port br0 afxdp-p0 -- set interface afxdp-p0 type="afxdp" Setup the OpenFlow rules:: ovs-ofctl del-flows br0 ovs-ofctl add-flow br0 "in_port=enp2s0, actions=output:afxdp-p0" ovs-ofctl add-flow br0 "in_port=afxdp-p0, actions=output:enp2s0" In the namespace, run drop or bounce back the packet:: ip netns exec at_ns0 ./xdp_rxq_info --dev p0 --action XDP_DROP ip netns exec at_ns0 ./xdp_rxq_info --dev p0 --action XDP_TX Bug Reporting ------------- Please report problems to dev@openvswitch.org. ovs-2.13.0/Documentation/intro/install/bash-completion.rst000066400000000000000000000064771362155554400236640ustar00rootroot00000000000000.. 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``. ovs-2.13.0/Documentation/intro/install/debian.rst000066400000000000000000000111701362155554400220040ustar00rootroot00000000000000.. 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. ================================= Debian Packaging for Open vSwitch ================================= 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. ovs-2.13.0/Documentation/intro/install/distributions.rst000066400000000000000000000046261362155554400234740ustar00rootroot00000000000000.. 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. ==================================== 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. .. note:: The packaged version available with distributions may not be latest Open vSwitch 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 fast userspace switching, Open vSwitch with DPDK support is bundled in the package ``openvswitch-switch-dpdk``. 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. 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. ovs-2.13.0/Documentation/intro/install/documentation.rst000066400000000000000000000060141362155554400234340ustar00rootroot00000000000000.. 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. ========================== Open vSwitch Documentation ========================== This document describes how to build the OVS documentation for use offline. A continuously updated, online version can be found at `docs.openvswitch.org `__. .. note:: These instructions provide information on building the documentation locally. For information on writing documentation, refer to :doc:`/internals/contributing/documentation-style` Build Requirements ------------------ As described in the :doc:`/internals/contributing/documentation-style`, the Open vSwitch documentation is written in reStructuredText and built with Sphinx. A detailed guide on installing Sphinx in many environments is available on the `Sphinx website`__ but, for most Linux distributions, you can install with your package manager. For example, on Debian/Ubuntu run:: $ sudo apt-get install python3-sphinx Similarly, on RHEL/Fedora run:: $ sudo dnf install python3-sphinx A ``requirements.txt`` is also provided in the ``/Documentation``, should you wish to install using ``pip``:: $ virtualenv .venv $ source .venv/bin/activate $ pip install -r Documentation/requirements.txt __ http://www.sphinx-doc.org/en/master/usage/installation.html Configuring ----------- It's unlikely that you'll need to customize any aspect of the configuration. However, the ``Documentation/conf.py`` is the go-to place for all configuration. This file is well documented and further information is available on the `Sphinx website`__. Building -------- Once Sphinx is installed, the documentation can be built using the provided Makefile targets:: $ make docs-check .. important:: The ``docs-check`` target will fail if there are any syntax errors. However, it won't catch more succint issues such as style or grammar issues. As a result, you should always inspect changes visually to ensure the result is as intended. Once built, documentation is available in the ``/Documentation/_build`` folder. Open the root ``index.html`` to browse the documentation. __ http://www.sphinx-doc.org/en/master/config.html ovs-2.13.0/Documentation/intro/install/dpdk.rst000066400000000000000000000633731362155554400215200ustar00rootroot00000000000000.. 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 with DPDK ====================== This document describes how to build and install Open vSwitch using a DPDK datapath. Open vSwitch can use the DPDK library to operate entirely in userspace. .. important:: The :doc:`releases FAQ ` lists support for the required versions of DPDK for each version of Open vSwitch. If building OVS and DPDK outside of the master build tree users should consult this list first. Build requirements ------------------ In addition to the requirements described in :doc:`general`, building Open vSwitch with DPDK will require the following: - DPDK 19.11 - A `DPDK supported NIC`_ Only required when physical ports are in use - A suitable kernel On Linux Distros running kernel version >= 3.0, only `IOMMU` needs to enabled via the grub cmdline, assuming you are using **VFIO**. For older kernels, ensure the kernel is built with ``UIO``, ``HUGETLBFS``, ``PROC_PAGE_MONITOR``, ``HPET``, ``HPET_MMAP`` support. If these are not present, it will be necessary to upgrade your kernel or build a custom kernel with these flags enabled. Detailed system requirements can be found at `DPDK requirements`_. .. _DPDK supported NIC: http://dpdk.org/doc/nics .. _DPDK requirements: http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html Installing ---------- Install DPDK ~~~~~~~~~~~~ #. Download the `DPDK sources`_, extract the file and set ``DPDK_DIR``:: $ cd /usr/src/ $ wget https://fast.dpdk.org/rel/dpdk-19.11.tar.xz $ tar xf dpdk-19.11.tar.xz $ export DPDK_DIR=/usr/src/dpdk-19.11 $ cd $DPDK_DIR #. (Optional) Configure DPDK as a shared library DPDK can be built as either a static library or a shared library. By default, it is configured for the former. If you wish to use the latter, set ``CONFIG_RTE_BUILD_SHARED_LIB=y`` in ``$DPDK_DIR/config/common_base``. .. note:: Minor performance loss is expected when using OVS with a shared DPDK library compared to a static DPDK library. #. Configure and install DPDK Build and install the DPDK library:: $ export DPDK_TARGET=x86_64-native-linuxapp-gcc $ export DPDK_BUILD=$DPDK_DIR/$DPDK_TARGET $ make install T=$DPDK_TARGET DESTDIR=install #. (Optional) Export the DPDK shared library location If DPDK was built as a shared library, export the path to this library for use when building OVS:: $ export LD_LIBRARY_PATH=$DPDK_DIR/x86_64-native-linuxapp-gcc/lib .. _DPDK sources: http://dpdk.org/rel Install OVS ~~~~~~~~~~~ OVS can be installed using different methods. For OVS to use DPDK, it has to be configured to build against the DPDK library (``--with-dpdk``). .. note:: This section focuses on generic recipe that suits most cases. For distribution specific instructions, refer to one of the more relevant guides. .. _OVS sources: http://openvswitch.org/releases/ #. Ensure the standard OVS requirements, described in :ref:`general-build-reqs`, are installed #. Bootstrap, if required, as described in :ref:`general-bootstrapping` #. Configure the package using the ``--with-dpdk`` flag:: $ ./configure --with-dpdk=$DPDK_BUILD where ``DPDK_BUILD`` is the path to the built DPDK library. This can be skipped if DPDK library is installed in its default location. If no path is provided to ``--with-dpdk``, but a pkg-config configuration for libdpdk is available the include paths will be generated via an equivalent ``pkg-config --cflags libdpdk``. .. note:: While ``--with-dpdk`` is required, you can pass any other configuration option described in :ref:`general-configuring`. #. Build and install OVS, as described in :ref:`general-building` Additional information can be found in :doc:`general`. .. note:: If you are running using the Fedora or Red Hat package, the Open vSwitch daemon will run as a non-root user. This implies that you must have a working IOMMU. Visit the `RHEL README`__ for additional information. __ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst Setup ----- Setup Hugepages ~~~~~~~~~~~~~~~ Allocate a number of 2M Huge pages: - For persistent allocation of huge pages, write to hugepages.conf file in `/etc/sysctl.d`:: $ echo 'vm.nr_hugepages=2048' > /etc/sysctl.d/hugepages.conf - For run-time allocation of huge pages, use the ``sysctl`` utility:: $ sysctl -w vm.nr_hugepages=N # where N = No. of 2M huge pages To verify hugepage configuration:: $ grep HugePages_ /proc/meminfo Mount the hugepages, if not already mounted by default:: $ mount -t hugetlbfs none /dev/hugepages`` .. note:: The amount of hugepage memory required can be affected by various aspects of the datapath and device configuration. Refer to :doc:`/topics/dpdk/memory` for more details. .. _dpdk-vfio: Setup DPDK devices using VFIO ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ VFIO is prefered to the UIO driver when using recent versions of DPDK. VFIO support required support from both the kernel and BIOS. For the former, kernel version > 3.6 must be used. For the latter, you must enable VT-d in the BIOS and ensure this is configured via grub. To ensure VT-d is enabled via the BIOS, run:: $ dmesg | grep -e DMAR -e IOMMU If VT-d is not enabled in the BIOS, enable it now. To ensure VT-d is enabled in the kernel, run:: $ cat /proc/cmdline | grep iommu=pt $ cat /proc/cmdline | grep intel_iommu=on If VT-d is not enabled in the kernel, enable it now. Once VT-d is correctly configured, load the required modules and bind the NIC to the VFIO driver:: $ modprobe vfio-pci $ /usr/bin/chmod a+x /dev/vfio $ /usr/bin/chmod 0666 /dev/vfio/* $ $DPDK_DIR/usertools/dpdk-devbind.py --bind=vfio-pci eth1 $ $DPDK_DIR/usertools/dpdk-devbind.py --status Setup OVS ~~~~~~~~~ Open vSwitch should be started as described in :doc:`general` with the exception of ovs-vswitchd, which requires some special configuration to enable DPDK functionality. DPDK configuration arguments can be passed to ovs-vswitchd via the ``other_config`` column of the ``Open_vSwitch`` table. At a minimum, the ``dpdk-init`` option must be set to either ``true`` or ``try``. For example:: $ export PATH=$PATH:/usr/local/share/openvswitch/scripts $ export DB_SOCK=/usr/local/var/run/openvswitch/db.sock $ ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true $ ovs-ctl --no-ovsdb-server --db-sock="$DB_SOCK" start There are many other configuration options, the most important of which are listed below. Defaults will be provided for all values not explicitly set. ``dpdk-init`` Specifies whether OVS should initialize and support DPDK ports. This field can either be ``true`` or ``try``. A value of ``true`` will cause the ovs-vswitchd process to abort on initialization failure. A value of ``try`` will imply that the ovs-vswitchd process should continue running even if the EAL initialization fails. ``dpdk-lcore-mask`` Specifies the CPU cores on which dpdk lcore threads should be spawned and expects hex string (eg '0x123'). ``dpdk-socket-mem`` Comma separated list of memory to pre-allocate from hugepages on specific sockets. If not specified, 1024 MB will be set for each numa node by default. ``dpdk-hugepage-dir`` Directory where hugetlbfs is mounted ``vhost-sock-dir`` Option to set the path to the vhost-user unix socket files. If allocating more than one GB hugepage, you can configure the amount of memory used from any given NUMA nodes. For example, to use 1GB from NUMA node 0 and 0GB for all other NUMA nodes, run:: $ ovs-vsctl --no-wait set Open_vSwitch . \ other_config:dpdk-socket-mem="1024,0" or:: $ ovs-vsctl --no-wait set Open_vSwitch . \ other_config:dpdk-socket-mem="1024" .. note:: Changing any of these options requires restarting the ovs-vswitchd application See the section ``Performance Tuning`` for important DPDK customizations. Validating ---------- DPDK support can be confirmed by validating the ``dpdk_initialized`` boolean value from the ovsdb. A value of ``true`` means that the DPDK EAL initialization succeeded:: $ ovs-vsctl get Open_vSwitch . dpdk_initialized true Additionally, the library version linked to ovs-vswitchd can be confirmed with either the ovs-vswitchd logs, or by running either of the commands:: $ ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.9.0 DPDK 17.11.0 $ ovs-vsctl get Open_vSwitch . dpdk_version "DPDK 17.11.0" At this point you can use ovs-vsctl to set up bridges and other Open vSwitch features. Seeing as we've configured DPDK support, we will use DPDK-type ports. For example, to create a userspace bridge named ``br0`` and add two ``dpdk`` ports to it, run:: $ ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev $ ovs-vsctl add-port br0 myportnameone -- set Interface myportnameone \ type=dpdk options:dpdk-devargs=0000:06:00.0 $ ovs-vsctl add-port br0 myportnametwo -- set Interface myportnametwo \ type=dpdk options:dpdk-devargs=0000:06:00.1 DPDK devices will not be available for use until a valid dpdk-devargs is specified. Refer to ovs-vsctl(8) and :doc:`/howto/dpdk` for more details. Performance Tuning ------------------ To achieve optimal OVS performance, the system can be configured and that includes BIOS tweaks, Grub cmdline additions, better understanding of NUMA nodes and apt selection of PCIe slots for NIC placement. .. note:: This section is optional. Once installed as described above, OVS with DPDK will work out of the box. Recommended BIOS Settings ~~~~~~~~~~~~~~~~~~~~~~~~~ .. list-table:: Recommended BIOS Settings :header-rows: 1 * - Setting - Value * - C3 Power State - Disabled * - C6 Power State - Disabled * - MLC Streamer - Enabled * - MLC Spacial Prefetcher - Enabled * - DCU Data Prefetcher - Enabled * - DCA - Enabled * - CPU Power and Performance - Performance * - Memeory RAS and Performance Config -> NUMA optimized - Enabled PCIe Slot Selection ~~~~~~~~~~~~~~~~~~~ The fastpath performance can be affected by factors related to the placement of the NIC, such as channel speeds between PCIe slot and CPU or the proximity of PCIe slot to the CPU cores running the DPDK application. Listed below are the steps to identify right PCIe slot. #. Retrieve host details using ``dmidecode``. For example:: $ dmidecode -t baseboard | grep "Product Name" #. Download the technical specification for product listed, e.g: S2600WT2 #. Check the Product Architecture Overview on the Riser slot placement, CPU sharing info and also PCIe channel speeds For example: On S2600WT, CPU1 and CPU2 share Riser Slot 1 with Channel speed between CPU1 and Riser Slot1 at 32GB/s, CPU2 and Riser Slot1 at 16GB/s. Running DPDK app on CPU1 cores and NIC inserted in to Riser card Slots will optimize OVS performance in this case. #. Check the Riser Card #1 - Root Port mapping information, on the available slots and individual bus speeds. In S2600WT slot 1, slot 2 has high bus speeds and are potential slots for NIC placement. Advanced Hugepage Setup ~~~~~~~~~~~~~~~~~~~~~~~ Allocate and mount 1 GB hugepages. - For persistent allocation of huge pages, add the following options to the kernel bootline:: default_hugepagesz=1GB hugepagesz=1G hugepages=N For platforms supporting multiple huge page sizes, add multiple options:: default_hugepagesz= hugepagesz= hugepages=N where: ``N`` number of huge pages requested ``size`` huge page size with an optional suffix ``[kKmMgG]`` - For run-time allocation of huge pages:: $ echo N > /sys/devices/system/node/nodeX/hugepages/hugepages-1048576kB/nr_hugepages where: ``N`` number of huge pages requested ``X`` NUMA Node .. note:: For run-time allocation of 1G huge pages, Contiguous Memory Allocator (``CONFIG_CMA``) has to be supported by kernel, check your Linux distro. Now mount the huge pages, if not already done so:: $ mount -t hugetlbfs -o pagesize=1G none /dev/hugepages Isolate Cores ~~~~~~~~~~~~~ The ``isolcpus`` option can be used to isolate cores from the Linux scheduler. The isolated cores can then be used to dedicatedly run HPC applications or threads. This helps in better application performance due to zero context switching and minimal cache thrashing. To run platform logic on core 0 and isolate cores between 1 and 19 from scheduler, add ``isolcpus=1-19`` to GRUB cmdline. .. note:: It has been verified that core isolation has minimal advantage due to mature Linux scheduler in some circumstances. Compiler Optimizations ~~~~~~~~~~~~~~~~~~~~~~ The default compiler optimization level is ``-O2``. Changing this to more aggressive compiler optimization such as ``-O3 -march=native`` with gcc (verified on 5.3.1) can produce performance gains though not significant. ``-march=native`` will produce optimized code on local machine and should be used when software compilation is done on Testbed. Multiple Poll-Mode Driver Threads ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With pmd multi-threading support, OVS creates one pmd thread for each NUMA node by default, if there is at least one DPDK interface from that NUMA node added to OVS. However, in cases where there are multiple ports/rxq's producing traffic, performance can be improved by creating multiple pmd threads running on separate cores. These pmd threads can share the workload by each being responsible for different ports/rxq's. Assignment of ports/rxq's to pmd threads is done automatically. A set bit in the mask means a pmd thread is created and pinned to the corresponding CPU core. For example, to run pmd threads on core 1 and 2:: $ ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x6 When using dpdk and dpdkvhostuser ports in a bi-directional VM loopback as shown below, spreading the workload over 2 or 4 pmd threads shows significant improvements as there will be more total CPU occupancy available:: NIC port0 <-> OVS <-> VM <-> OVS <-> NIC port 1 Refer to ovs-vswitchd.conf.db(5) for additional information on configuration options. Affinity ~~~~~~~~ For superior performance, DPDK pmd threads and Qemu vCPU threads needs to be affinitized accordingly. - PMD thread Affinity A poll mode driver (pmd) thread handles the I/O of all DPDK interfaces assigned to it. A pmd thread shall poll the ports for incoming packets, switch the packets and send to tx port. A pmd thread is CPU bound, and needs to be affinitized to isolated cores for optimum performance. Even though a PMD thread may exist, the thread only starts consuming CPU cycles if there is at least one receive queue assigned to the pmd. .. note:: On NUMA systems, PCI devices are also local to a NUMA node. Unbound rx queues for a PCI device will be assigned to a pmd on it's local NUMA node if a non-isolated PMD exists on that NUMA node. If not, the queue will be assigned to a non-isolated pmd on a remote NUMA node. This will result in reduced maximum throughput on that device and possibly on other devices assigned to that pmd thread. If such a queue assignment is made a warning message will be logged: "There's no available (non-isolated) pmd thread on numa node N. Queue Q on port P will be assigned to the pmd on core C (numa node N'). Expect reduced performance." Binding PMD threads to cores is described in the above section ``Multiple Poll-Mode Driver Threads``. - QEMU vCPU thread Affinity A VM performing simple packet forwarding or running complex packet pipelines has to ensure that the vCPU threads performing the work has as much CPU occupancy as possible. For example, on a multicore VM, multiple QEMU vCPU threads shall be spawned. When the DPDK ``testpmd`` application that does packet forwarding is invoked, the ``taskset`` command should be used to affinitize the vCPU threads to the dedicated isolated cores on the host system. Enable HyperThreading ~~~~~~~~~~~~~~~~~~~~~ With HyperThreading, or SMT, enabled, a physical core appears as two logical cores. SMT can be utilized to spawn worker threads on logical cores of the same physical core there by saving additional cores. With DPDK, when pinning pmd threads to logical cores, care must be taken to set the correct bits of the ``pmd-cpu-mask`` to ensure that the pmd threads are pinned to SMT siblings. Take a sample system configuration, with 2 sockets, 2 * 10 core processors, HT enabled. This gives us a total of 40 logical cores. To identify the physical core shared by two logical cores, run:: $ cat /sys/devices/system/cpu/cpuN/topology/thread_siblings_list where ``N`` is the logical core number. In this example, it would show that cores ``1`` and ``21`` share the same physical core. Logical cores can be specified in pmd-cpu-masks similarly to physical cores, as described in ``Multiple Poll-Mode Driver Threads``. NUMA/Cluster-on-Die ~~~~~~~~~~~~~~~~~~~ Ideally inter-NUMA datapaths should be avoided where possible as packets will go across QPI and there may be a slight performance penalty when compared with intra NUMA datapaths. On Intel Xeon Processor E5 v3, Cluster On Die is introduced on models that have 10 cores or more. This makes it possible to logically split a socket into two NUMA regions and again it is preferred where possible to keep critical datapaths within the one cluster. It is good practice to ensure that threads that are in the datapath are pinned to cores in the same NUMA area. e.g. pmd threads and QEMU vCPUs responsible for forwarding. If DPDK is built with ``CONFIG_RTE_LIBRTE_VHOST_NUMA=y``, vHost User ports automatically detect the NUMA socket of the QEMU vCPUs and will be serviced by a PMD from the same node provided a core on this node is enabled in the ``pmd-cpu-mask``. ``libnuma`` packages are required for this feature. Binding PMD threads is described in the above section ``Multiple Poll-Mode Driver Threads``. DPDK Physical Port Rx Queues ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :: $ ovs-vsctl set Interface options:n_rxq= The above command sets the number of rx queues for DPDK physical interface. The rx queues are assigned to pmd threads on the same NUMA node in a round-robin fashion. .. _dpdk-queues-sizes: DPDK Physical Port Queue Sizes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :: $ ovs-vsctl set Interface dpdk0 options:n_rxq_desc= $ ovs-vsctl set Interface dpdk0 options:n_txq_desc= The above command sets the number of rx/tx descriptors that the NIC associated with dpdk0 will be initialised with. Different ``n_rxq_desc`` and ``n_txq_desc`` configurations yield different benefits in terms of throughput and latency for different scenarios. Generally, smaller queue sizes can have a positive impact for latency at the expense of throughput. The opposite is often true for larger queue sizes. Note: increasing the number of rx descriptors eg. to 4096 may have a negative impact on performance due to the fact that non-vectorised DPDK rx functions may be used. This is dependent on the driver in use, but is true for the commonly used i40e and ixgbe DPDK drivers. Exact Match Cache ~~~~~~~~~~~~~~~~~ Each pmd thread contains one Exact Match Cache (EMC). After initial flow setup in the datapath, the EMC contains a single table and provides the lowest level (fastest) switching for DPDK ports. If there is a miss in the EMC then the next level where switching will occur is the datapath classifier. Missing in the EMC and looking up in the datapath classifier incurs a significant performance penalty. If lookup misses occur in the EMC because it is too small to handle the number of flows, its size can be increased. The EMC size can be modified by editing the define ``EM_FLOW_HASH_SHIFT`` in ``lib/dpif-netdev.c``. As mentioned above, an EMC is per pmd thread. An alternative way of increasing the aggregate amount of possible flow entries in EMC and avoiding datapath classifier lookups is to have multiple pmd threads running. Rx Mergeable Buffers ~~~~~~~~~~~~~~~~~~~~ Rx mergeable buffers is a virtio feature that allows chaining of multiple virtio descriptors to handle large packet sizes. Large packets are handled by reserving and chaining multiple free descriptors together. Mergeable buffer support is negotiated between the virtio driver and virtio device and is supported by the DPDK vhost library. This behavior is supported and enabled by default, however in the case where the user knows that rx mergeable buffers are not needed i.e. jumbo frames are not needed, it can be forced off by adding ``mrg_rxbuf=off`` to the QEMU command line options. By not reserving multiple chains of descriptors it will make more individual virtio descriptors available for rx to the guest using dpdkvhost ports and this can improve performance. Output Packet Batching ~~~~~~~~~~~~~~~~~~~~~~ To make advantage of batched transmit functions, OVS collects packets in intermediate queues before sending when processing a batch of received packets. Even if packets are matched by different flows, OVS uses a single send operation for all packets destined to the same output port. Furthermore, OVS is able to buffer packets in these intermediate queues for a configurable amount of time to reduce the frequency of send bursts at medium load levels when the packet receive rate is high, but the receive batch size still very small. This is particularly beneficial for packets transmitted to VMs using an interrupt-driven virtio driver, where the interrupt overhead is significant for the OVS PMD, the host operating system and the guest driver. The ``tx-flush-interval`` parameter can be used to specify the time in microseconds OVS should wait between two send bursts to a given port (default is ``0``). When the intermediate queue fills up before that time is over, the buffered packet batch is sent immediately:: $ ovs-vsctl set Open_vSwitch . other_config:tx-flush-interval=50 This parameter influences both throughput and latency, depending on the traffic load on the port. In general lower values decrease latency while higher values may be useful to achieve higher throughput. Low traffic (``packet rate < 1 / tx-flush-interval``) should not experience any significant latency or throughput increase as packets are forwarded immediately. At intermediate load levels (``1 / tx-flush-interval < packet rate < 32 / tx-flush-interval``) traffic should experience an average latency increase of up to ``1 / 2 * tx-flush-interval`` and a possible throughput improvement. Very high traffic (``packet rate >> 32 / tx-flush-interval``) should experience the average latency increase equal to ``32 / (2 * packet rate)``. Most send batches in this case will contain the maximum number of packets (``32``). A ``tx-burst-interval`` value of ``50`` microseconds has shown to provide a good performance increase in a ``PHY-VM-PHY`` scenario on ``x86`` system for interrupt-driven guests while keeping the latency increase at a reasonable level: https://mail.openvswitch.org/pipermail/ovs-dev/2017-December/341628.html .. note:: Throughput impact of this option significantly depends on the scenario and the traffic patterns. For example: ``tx-burst-interval`` value of ``50`` microseconds shows performance degradation in ``PHY-VM-PHY`` with bonded PHY scenario while testing with ``256 - 1024`` packet flows: https://mail.openvswitch.org/pipermail/ovs-dev/2017-December/341700.html The average number of packets per output batch can be checked in PMD stats:: $ ovs-appctl dpif-netdev/pmd-stats-show Limitations ------------ - Network Interface Firmware requirements: Each release of DPDK is validated against a specific firmware version for a supported Network Interface. New firmware versions introduce bug fixes, performance improvements and new functionality that DPDK leverages. The validated firmware versions are available as part of the release notes for DPDK. It is recommended that users update Network Interface firmware to match what has been validated for the DPDK release. The latest list of validated firmware versions can be found in the `DPDK release notes`_. .. _DPDK release notes: https://doc.dpdk.org/guides-19.11/rel_notes/release_19_11.html - Upper bound MTU: DPDK device drivers differ in how the L2 frame for a given MTU value is calculated e.g. i40e driver includes 2 x vlan headers in MTU overhead, em driver includes 1 x vlan header, ixgbe driver does not include a vlan header in overhead. Currently it is not possible for OVS DPDK to know what upper bound MTU value is supported for a given device. As such OVS DPDK must provision for the case where the L2 frame for a given MTU includes 2 x vlan headers. This reduces the upper bound MTU value for devices that do not include vlan headers in their L2 frames by 8 bytes e.g. ixgbe devices upper bound MTU is reduced from 9710 to 9702. This work around is temporary and is expected to be removed once a method is provided by DPDK to query the upper bound MTU value for a given device. Reporting Bugs -------------- Report problems to bugs@openvswitch.org. ovs-2.13.0/Documentation/intro/install/fedora.rst000066400000000000000000000113721362155554400220260ustar00rootroot00000000000000.. 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. =========================================== Fedora, RHEL 7.x Packaging for Open vSwitch =========================================== 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 :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. Build Requirements ------------------ You will need to install all required packages to build the RPMs. 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. DNF: :: $ dnf install @'Development Tools' rpm-build dnf-plugins-core YUM: :: $ yum install @'Development Tools' rpm-build yum-utils Then it is necessary to install Open vSwitch 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 And to install specific dependencies, use the corresponding tool below. For some of the dependencies on RHEL you may need to add two additional repositories to help yum-builddep, e.g.:: $ subscription-manager repos --enable=rhel-7-server-extras-rpms $ subscription-manager repos --enable=rhel-7-server-optional-rpms DNF:: $ dnf builddep /tmp/ovs.spec YUM:: $ yum-builddep /tmp/ovs.spec Once that is completed, remove the file ``/tmp/ovs.spec``. Bootstraping ------------ Refer to :ref:`general-bootstrapping`. Configuring ----------- Refer to :ref:`general-configuring`. Building -------- User Space RPMs ~~~~~~~~~~~~~~~ To build Open vSwitch user-space RPMs, execute the following from the directory in which `./configure` was executed: :: $ make rpm-fedora This will create the RPMs `openvswitch`, `python3-openvswitch`, `openvswitch-test`, `openvswitch-devel` and `openvswitch-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. :: $ make rpm-fedora RPMBUILD_OPT="--with check" 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 ---------- 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 `python3-openvswitch`, `openvswitch-test`, `openvswitch-devel`, and `openvswitch-debuginfo` RPMs are optional unless required for a specific purpose. Refer to the `RHEL README`__ for additional usage and configuration information. __ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst Reporting Bugs -------------- Report problems to bugs@openvswitch.org. ovs-2.13.0/Documentation/intro/install/general.rst000066400000000000000000000620261362155554400222050ustar00rootroot00000000000000.. 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 Linux, FreeBSD and NetBSD ========================================= This document describes how to build and install Open vSwitch 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 ------------------------------ The canonical location for Open vSwitch source code is its Git repository, which you can clone into a directory named "ovs" with:: $ git clone https://github.com/openvswitch/ovs.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:: $ git checkout v2.7.0 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. .. _general-build-reqs: Build Requirements ------------------ To compile the userspace programs in the Open vSwitch distribution, you will need the following software: - GNU make - A C compiler, such as: - GCC 4.6 or later. - Clang 3.4 or later. - 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``). - 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. - Python 3.4 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. 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 schema, you will also need the following software: - Autoconf version 2.63 or later. - Automake version 1.10 or later. - 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 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 following to obtain better warnings: - "sparse" version 0.5.1 or later (https://git.kernel.org/pub/scm/devel/sparse/sparse.git/). - GNU make. - clang, version 3.4 or later - flake8 along with the hacking flake8 plugin (for Python code). The automatic flake8 check that runs against Python code has some warnings enabled that 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. .. _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: - 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. Refer to :doc:`/faq/releases` for more information. - 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 3.4 or later. On Linux you should ensure that ``/dev/urandom`` exists. To support TAP devices, you must also ensure that ``/dev/net/tun`` exists. .. _general-bootstrapping: 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 .. _general-configuring: Configuring ----------- Configure the package by running the configure script. You can usually 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 ``/usr/local`` and ``/usr/local/var`` and expect to use ``/etc/openvswitch`` as the default database directory, add options as shown here:: $ ./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc .. 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. By default, static libraries are built and linked against. If you want to use shared libraries instead:: $ ./configure --enable-shared To use a specific C compiler for compiling Open vSwitch user programs, also specify it on the configure command line, like so:: $ ./configure CC=gcc-4.2 To use 'clang' compiler:: $ ./configure CC=clang To supply special flags to the C compiler, specify them as ``CFLAGS`` on the configure command line. If you want the default CFLAGS, which include ``-g`` to build debug symbols and ``-O2`` to enable optimizations, you must include them yourself. For example, to build with the default CFLAGS plus ``-mssse3``, you might run configure as follows:: $ ./configure CFLAGS="-g -O2 -mssse3" For efficient hash computation special flags can be passed to leverage built-in intrinsics. For example on X86_64 with SSE4.2 instruction set support, CRC32 intrinsics can be used by passing ``-msse4.2``:: $ ./configure CFLAGS="-g -O2 -msse4.2"` Also builtin popcnt instruction can be used to speedup the counting of the bits set in an integer. For example on X86_64 with POPCNT support, it can be enabled by passing ``-mpopcnt``:: $ ./configure CFLAGS="-g -O2 -mpopcnt"` If you are on a different processor and don't know what flags to choose, it is recommended to use ``-march=native`` settings:: $ ./configure CFLAGS="-g -O2 -march=native" With this, GCC will detect the processor and automatically set appropriate flags for it. This should not be used if you are compiling OVS outside the target machine. .. note:: CFLAGS are not applied when building the Linux kernel module. Custom CFLAGS for the kernel module are supplied using the ``EXTRA_CFLAGS`` variable when running make. For example:: $ make EXTRA_CFLAGS="-Wno-error=date-time" If you are a developer and want to enable Address Sanitizer for debugging purposes, at about a 2x runtime cost, you can add ``-fsanitize=address -fno-omit-frame-pointer -fno-common`` to CFLAGS. For example:: $ ./configure CFLAGS="-g -O2 -fsanitize=address -fno-omit-frame-pointer -fno-common" To build the Linux kernel module, so that you can run the kernel-based switch, pass the location of the kernel build directory on ``--with-linux``. For example, to build for a running instance of Linux:: $ ./configure --with-linux=/lib/modules/$(uname -r)/build .. note:: If ``--with-linux`` requests building for an unsupported version 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 ``--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:: $ ./configure --enable-Werror If you're building with GCC, then, for improved warnings, install ``sparse`` (see "Prerequisites") and enable it for the build by adding ``--enable-sparse``. Use this with ``--enable-Werror`` to avoid missing both compiler and ``sparse`` warnings, e.g.:: $ ./configure --enable-Werror --enable-sparse To build with gcov code coverage support, add ``--enable-coverage``:: $ ./configure --enable-coverage The configure script accepts a number of other options and honors additional environment variables. For a full list, invoke configure with the ``--help`` 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:: $ mkdir _gcc && (cd _gcc && ./configure CC=gcc) $ mkdir _clang && (cd _clang && ./configure CC=clang) Under certain loads the ovsdb-server and other components perform better when using the jemalloc memory allocator, instead of the glibc memory allocator. If you wish to link with jemalloc add it to LIBS:: $ ./configure LIBS=-ljemalloc .. _general-building: Building -------- 1. Run GNU make in the build directory, e.g.:: $ make or if GNU make is installed as "gmake":: $ gmake If you used a separate build directory, run make or gmake from that directory, e.g.:: $ make -C _gcc $ make -C _clang .. note:: Some versions of Clang and ccache are not completely compatible. If you see unusual warnings when you use both together, consider disabling ccache. 2. Consider running the testsuite. Refer to :doc:`/topics/testing` for instructions. 3. Run ``make install`` to install the executables and manpages into the running system, by default under ``/usr/local``:: $ 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 '/usr/local/share/openvswitch/scripts'. An example after install might be:: $ export PATH=$PATH:/usr/local/share/openvswitch/scripts $ ovs-ctl start Additionally, the ovs-ctl script allows starting / stopping the daemons individually using specific options. To start just the ovsdb-server:: $ export PATH=$PATH:/usr/local/share/openvswitch/scripts $ ovs-ctl --no-ovs-vswitchd start Likewise, to start just the ovs-vswitchd:: $ export PATH=$PATH:/usr/local/share/openvswitch/scripts $ ovs-ctl --no-ovsdb-server start Refer to ovs-ctl(8) for more information on ovs-ctl. 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:: $ 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 \ --pidfile --detach --log-file .. note:: If you built Open vSwitch 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:: $ ovs-vsctl --no-wait init Start the main Open vSwitch daemon, telling it to connect to the same Unix domain socket:: $ ovs-vswitchd --pidfile --detach --log-file Starting OVS in container ------------------------- For ovs vswitchd, we need to load ovs kernel modules on host. Hence, OVS containers kernel version needs to be same as that of host kernel. Export following variables in .env and place it under project root:: $ OVS_BRANCH= $ OVS_VERSION= $ DISTRO= $ KERNEL_VERSION= $ GITHUB_SRC= $ DOCKER_REPO= To build ovs modules:: $ cd utilities/docker $ make build Compiled Modules will be tagged with docker image To Push ovs modules:: $ make push OVS docker image will be pushed to specified docker repo. Start ovsdb-server using below command:: $ docker run -itd --net=host --name=ovsdb-server \ : ovsdb-server Start ovs-vswitchd with priviledged mode as it needs to load kernel module in host using below command:: $ docker run -itd --net=host --name=ovs-vswitchd \ --volumes-from=ovsdb-server -v /lib:/lib --privileged \ : ovs-vswitchd .. note:: The debian docker file uses ubuntu 16.04 as a base image for reference. User can use any other base image for debian, e.g. u14.04, etc. RHEL based docker build support needs to be added. 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:: $ ovs-vsctl add-br br0 $ ovs-vsctl add-port br0 eth0 $ ovs-vsctl add-port br0 vif1.0 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. When using ovs in container, exec to container to run above commands:: $ docker exec -it /bin/bash Upgrading --------- When you upgrade Open vSwitch from one version to another you should also upgrade the database schema: .. 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. 1. Stop the Open vSwitch daemons, e.g.:: $ kill `cd /usr/local/var/run/openvswitch && cat ovsdb-server.pid ovs-vswitchd.pid` 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. 3. Upgrade the database, in one of the following two ways: - 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". - If you want to preserve the contents of your database, back it up first, then use ``ovsdb-tool convert`` to upgrade it, e.g.:: $ ovsdb-tool convert /usr/local/etc/openvswitch/conf.db \ vswitchd/vswitch.ovsschema 4. Start the Open vSwitch daemons as described under `Starting`_ above. Hot Upgrading ------------- 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. 5. When upgrading ovs running in container on host that is managed by ovn, simply stop the docker container, remove and re-run with new docker image that has newer ovs version. 6. When running ovs in container, if ovs is used in bridged mode where management interface is managed by ovs, docker restart will result in loss of network connectivity. Hence, make sure to delete the bridge mapping of physical interface from ovs, upgrade ovs via docker and then add back the interface to ovs bridge. This mapping need not be deleted in case of multi nics if management interface is not managed by ovs. 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 -------------- Report problems to bugs@openvswitch.org. ovs-2.13.0/Documentation/intro/install/index.rst000066400000000000000000000034301362155554400216710ustar00rootroot00000000000000.. 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. ======================= Installing Open vSwitch ======================= A collection of guides detailing how to install Open vSwitch in a variety of different environments and using different configurations. Installation from Source ------------------------ .. TODO(stephenfin): Based on the title alone, the NetBSD doc should probably be merged into the general install doc .. toctree:: :maxdepth: 2 general netbsd windows xenserver userspace dpdk afxdp Installation from Packages -------------------------- Open vSwitch is packaged on a variety of distributions. The tooling required to build these packages is included in the Open vSwitch tree. The instructions are provided below. .. toctree:: :maxdepth: 2 distributions debian fedora rhel Others ------ .. toctree:: :maxdepth: 2 bash-completion documentation ovs-2.13.0/Documentation/intro/install/netbsd.rst000066400000000000000000000040141362155554400220400ustar00rootroot00000000000000.. 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 - python37 Some components have additional requirements. Refer to :doc:`general` for more information. Assuming you are running NetBSD/amd64 7.0.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 python37 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``. Open vSwitch on NetBSD is currently "userspace switch" implementation in the sense described in :doc:`userspace` and :doc:`/topics/porting`. ovs-2.13.0/Documentation/intro/install/rhel.rst000066400000000000000000000175601362155554400215250ustar00rootroot00000000000000.. 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. ======================================== RHEL 5.6, 6.x Packaging for Open vSwitch ======================================== This document describes how to build and install Open vSwitch on a Red Hat Enterprise Linux (RHEL) host. If you want to install Open vSwitch on a generic Linux host, refer to :doc:`general` instead. We have tested these instructions with RHEL 5.6 and RHEL 6.0. For RHEL 7.x (or derivatives, such as CentOS 7.x), you should follow the instructions in the :doc:`fedora`. The Fedora spec files are used for RHEL 7.x. .. _rhel-prerequisites: Prerequisites ------------- You may build from an Open vSwitch distribution tarball or from an Open vSwitch Git tree. The default RPM build directory, ``_topdir``, has five directories in the top-level. BUILD/ where the software is unpacked and built RPMS/ where the newly created binary package files are written SOURCES/ contains the original sources, patches, and icon files SPECS/ contains the spec files for each package to be built SRPMS/ where the newly created source package files are written Before you begin, note the RPM sources directory on your version of RHEL. The command ``rpmbuild --showrc`` will show the configuration for each of those directories. Alternatively, the command ``rpm --eval '%{_topdir}'`` shows the current configuration for the top level directory and the command ``rpm --eval '%{_sourcedir}'`` does the same for the sources directory. On RHEL 5, the default RPM ``_topdir`` is ``/usr/src/redhat`` and the default RPM sources directory is ``/usr/src/redhat/SOURCES``. On RHEL 6, the default ``_topdir`` is ``$HOME/rpmbuild`` and the default RPM sources directory is ``$HOME/rpmbuild/SOURCES``. Build Requirements ------------------ You will need to install all required packages to build the RPMs. The command below will install RPM tools and generic build dependencies:: $ yum install @'Development Tools' rpm-build yum-utils Then it is necessary to install Open vSwitch 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.spec.in > /tmp/ovs.spec And to install specific dependencies, use yum-builddep tool:: $ yum-builddep /tmp/ovs.spec Once that is completed, remove the file ``/tmp/ovs.spec``. If python3-sphinx package is not available in your version of RHEL, you can install it via pip with 'pip install sphinx'. Open vSwitch requires python 3.4 or newer which is not available in older distributions. In the case of RHEL 6.x and its derivatives, one option is to install python34 from `EPEL`_. .. _EPEL: https://fedoraproject.org/wiki/EPEL .. _rhel-bootstrapping: Bootstrapping and Configuring ----------------------------- If you are building from a distribution tarball, skip to :ref:`rhel-building`. If not, you must be building from an Open vSwitch Git tree. Determine what version of Autoconf is installed (e.g. run ``autoconf --version``). If it is not at least version 2.63, then you must upgrade or use another machine to build the packages. Assuming all requirements have been met, build the tarball by running:: $ ./boot.sh $ ./configure $ make dist You must run this on a machine that has the tools listed in :ref:`general-build-reqs` as prerequisites for building from a Git tree. Afterward, proceed with the rest of the instructions using the distribution tarball. Now you have a distribution tarball, named something like ``openvswitch-x.y.z.tar.gz``. Copy this file into the RPM sources directory, e.g.:: $ cp openvswitch-x.y.z.tar.gz $HOME/rpmbuild/SOURCES Broken ``build`` symlink ~~~~~~~~~~~~~~~~~~~~~~~~ Some versions of the RHEL 6 kernel-devel package contain a broken ``build`` symlink. If you are using such a version, you must fix the problem before continuing. To find out whether you are affected, run:: $ cd /lib/modules/ $ ls -l build/ where ```` is the version number of the RHEL 6 kernel. .. note:: The trailing slash in the final command is important. Be sure to include it. If the ``ls`` command produces a directory listing, your kernel-devel package is OK. If it produces a ``No such file or directory`` error, your kernel-devel package is buggy. If your kernel-devel package is buggy, then you can fix it with:: $ cd /lib/modules/ $ rm build $ ln -s /usr/src/kernels/ build where ```` is the name of an existing directory under ``/usr/src/kernels``, whose name should be similar to ```` but may contain some extra parts. Once you have done this, verify the fix with the same procedure you used above to check for the problem. .. _rhel-building: Building -------- You should have a distribution tarball named something like openvswitch-x.y.z.tar.gz. Copy this file into the RPM sources directory:: $ cp openvswitch-x.y.z.tar.gz $HOME/rpmbuild/SOURCES Make another copy of the distribution tarball in a temporary directory. Then unpack the tarball and ``cd`` into its root:: $ tar xzf openvswitch-x.y.z.tar.gz $ cd openvswitch-x.y.z Userspace ~~~~~~~~~ To build Open vSwitch userspace, run:: $ rpmbuild -bb rhel/openvswitch.spec This produces two RPMs: "openvswitch" and "openvswitch-debuginfo". The above command automatically runs the Open vSwitch unit tests. To disable the unit tests, run:: $ rpmbuild -bb --without check rhel/openvswitch.spec .. note:: If the build fails with ``configure: error: source dir /lib/modules/2.6.32-279.el6.x86_64/build doesn't exist`` or similar, then the kernel-devel package is missing or buggy. Kernel Module ~~~~~~~~~~~~~ On RHEL 6, to build the Open vSwitch kernel module run:: $ rpmbuild -bb rhel/kmod-openvswitch-rhel6.spec You might have to specify a kernel version and/or variants, e.g.: $ rpmbuild -bb \ -D "kversion 2.6.32-131.6.1.el6.x86_64" \ -D "kflavors default debug kdump" \ rhel/kmod-openvswitch-rhel6.spec This produces an "kmod-openvswitch" RPM for each kernel variant, in this example: "kmod-openvswitch", "kmod-openvswitch-debug", and "kmod-openvswitch-kdump". .. _rhel-script-integrations: Red Hat Network Scripts Integration ----------------------------------- A RHEL host has default firewall rules that prevent any Open vSwitch tunnel traffic from passing through. If a user configures Open vSwitch tunnels like Geneve, GRE, VXLAN, LISP etc., they will either have to manually add iptables firewall rules to allow the tunnel traffic or add it through a startup script Refer to the "enable-protocol" command in the ovs-ctl(8) manpage for more information. In addition, simple integration with Red Hat network scripts has been implemented. Refer to `README.RHEL.rst`__ in the source tree or /usr/share/doc/openvswitch/README.RHEL.rst in the installed openvswitch package for details. __ https://github.com/openvswitch/ovs/blob/master/rhel/README.RHEL.rst Reporting Bugs -------------- Report problems to bugs@openvswitch.org. ovs-2.13.0/Documentation/intro/install/userspace.rst000066400000000000000000000077341362155554400225670ustar00rootroot00000000000000.. 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. ovs-2.13.0/Documentation/intro/install/windows.rst000066400000000000000000000623111362155554400222570ustar00rootroot00000000000000.. 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 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 3.4 or later. Install the latest Python 3.x from python.org and verify that its path is part of Windows' PATH environment variable. We require that you have pypiwin32 library installed. The library can be installed via pip command: :: $ 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. ovs-2.13.0/Documentation/intro/install/xenserver.rst000066400000000000000000000217101362155554400226040ustar00rootroot00000000000000.. 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 3.4 or later, so using Open vSwitch with XenServer 6.5 or earlier requires installing Python 3.x. 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. ovs-2.13.0/Documentation/intro/what-is-ovs.rst000066400000000000000000000024371362155554400213030ustar00rootroot00000000000000.. 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 start-after/end-before may need to be updated if the README is modified. .. include:: ../../README.rst :start-after: What is Open vSwitch? :end-before: What other documentation is available? ovs-2.13.0/Documentation/intro/why-ovs.rst000066400000000000000000000144101362155554400205300ustar00rootroot00000000000000.. 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. ovs-2.13.0/Documentation/ref/000077500000000000000000000000001362155554400160035ustar00rootroot00000000000000ovs-2.13.0/Documentation/ref/index.rst000066400000000000000000000145111362155554400176460ustar00rootroot00000000000000.. 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. =============== Reference Guide =============== Man Pages --------- .. TODO(stephenfin): Remove the below notice once everything is converted to rST The following man pages are written in rST and converted to roff at compile time: .. toctree:: :maxdepth: 3 ovs-appctl.8 ovs-ctl.8 ovs-l3ping.8 ovs-pki.8 ovs-sim.1 ovs-parse-backtrace.8 ovs-tcpdump.8 ovs-tcpundump.1 ovs-test.8 ovs-vlan-test.8 ovsdb-server.7 ovsdb.5 ovsdb.7 The remainder are still in roff format can be found below: .. list-table:: * - ovs-actions(7) - `(pdf) `__ - `(html) `__ - `(plain text) `__ * - ovs-bugtool(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-ofctl(8) - `(pdf) `__ - `(html) `__ - `(plain text) `__ * - ovs-pcap(1) - `(pdf) `__ - `(html) `__ - `(plain text) `__ * - ovs-test(8) - `(pdf) `__ - `(html) `__ - `(plain text) `__ * - ovs-testcontroller(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) `__ ovs-2.13.0/Documentation/ref/ovs-appctl.8.rst000066400000000000000000000235321362155554400210000ustar00rootroot00000000000000========== ovs-appctl ========== Synopsis ======== ``ovs-appctl`` [``--target=`` | ``-t`` ] [``--timeout=`` | ``-T`` ] [...] ``ovs-appctl --help`` ``ovs-appctl --version`` Description =========== Open vSwitch daemons accept certain commands at runtime to control their behavior and query their settings. Every daemon accepts a common set of commands documented under `Common Commands`_ below. Some daemons support additional commands documented in their own manpages. ``ovs-vswitchd`` in particular accepts a number of additional commands documented in ``ovs-vswitchd(8)``. The ``ovs-appctl`` program provides a simple way to invoke these commands. The command to be sent is specified on ``ovs-appctl``'s command line as non-option arguments. ``ovs-appctl`` sends the command and prints the daemon's response on standard output. In normal use only a single option is accepted: * ``-t`` or ``--target`` Tells ``ovs-appctl`` which daemon to contact. If begins with ``/`` it must name a Unix domain socket on which an Open vSwitch daemon is listening for control channel connections. By default, each daemon listens on a Unix domain socket in the rundir (e.g. ``/run``) named ``..ctl``, where is the program's name and is its process ID. For example, if ``ovs-vswitchd`` has PID 123, it would listen on ``ovs-vswitchd.123.ctl``. Otherwise, ``ovs-appctl`` looks in the rundir for a pidfile, that is, a file whose contents are the process ID of a running process as a decimal number, named ``.pid``. (The ``--pidfile`` option makes an Open vSwitch daemon create a pidfile.) ``ovs-appctl`` reads the pidfile, then looks in the rundir for a Unix socket named ``..ctl``, where is replaced by the process ID read from the pidfile, and uses that file as if it had been specified directly as the target. On Windows, can be an absolute path to a file that contains a localhost TCP port on which an Open vSwitch daemon is listening for control channel connections. By default, each daemon writes the TCP port on which it is listening for control connection into the file ``.ctl`` located inside the rundir. If is not an absolute path, ``ovs-appctl`` looks in the rundir for a file named ``.ctl``. The default target is ``ovs-vswitchd``. * ``-T `` or ``--timeout=`` By default, or with a of ``0``, ``ovs-appctl`` waits forever to connect to the daemon and receive a response. This option limits runtime to approximately seconds. If the timeout expires, ``ovs-appctl`` exits with a ``SIGALRM`` signal. Common Commands =============== Every Open vSwitch daemon supports a common set of commands, which are documented in this section. General Commands ---------------- These commands display daemon-specific commands and the running version. Note that these commands are different from the ``--help`` and ``--version`` options that return information about the ``ovs-appctl`` utility itself. * ``list-commands`` Lists the commands supported by the target. * ``version`` Displays the version and compilation date of the target. Logging Commands ---------------- Open vSwitch has several log levels. The highest-severity log level is: * ``off`` No message is ever logged at this level, so setting a logging destination's log level to ``off`` disables logging to that destination. The following log levels, in order of descending severity, are available: * ``emer`` A major failure forced a process to abort. * ``err`` A high-level operation or a subsystem failed. Attention is warranted. * ``warn`` A low-level operation failed, but higher-level subsystems may be able to recover. * ``info`` Information that may be useful in retrospect when investigating a problem. * ``dbg`` Information useful only to someone with intricate knowledge of the system, or that would commonly cause too-voluminous log output. Log messages at this level are not logged by default. Every Open vSwitch daemon supports the following commands for examining and adjusting log levels: * ``vlog/list`` Lists the known logging modules and their current levels. * ``vlog/list-pattern`` Lists logging pattern used for each destination. * ``vlog/set`` [] Sets logging levels. Without any , sets the log level for every module and destination to ``dbg``. Otherwise, is a list of words separated by spaces or commas or colons, up to one from each category below: * A valid module name, as displayed by the ``vlog/list`` command on ``ovs-appctl(8)``, limits the log level change to the specified module. * ``syslog``, ``console``, or ``file``, to limit the log level change to only to the system log, to the console, or to a file, respectively. On Windows platform, ``syslog`` is only useful if was started with the ``--syslog-target`` option (it has no effect otherwise). * ``off``, ``emer``, ``err``, ``warn``, ``info``, or ``dbg``, to control the log level. Messages of the given severity or higher will be logged, and messages of lower severity will be filtered out. ``off`` filters out all messages. Case is not significant within . Regardless of the log levels set for ``file``, logging to a file will not take place unless the target application was invoked with the ``--log-file`` option. For compatibility with older versions of OVS, ``any`` is accepted within but it has no effect. * ``vlog/set PATTERN::`` Sets the log pattern for to . Each time a message is logged to , determines the message's formatting. Most characters in are copied literally to the log, but special escapes beginning with ``%`` are expanded as follows: * ``%A`` The name of the application logging the message, e.g. ``ovs-vswitchd``. * ``%B`` The RFC5424 syslog PRI of the message. * ``%c`` The name of the module (as shown by ``ovs-appctl --list``) logging the message. * ``%d`` The current date and time in ISO 8601 format (YYYY-MM-DD HH:MM:SS). * ``%d{}`` The current date and time in the specified , which takes the same format as the