docs/userguide/feature.userguide.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. (c) Tim Irnich, Nikolas Hermanns, Christopher Price and others
   4
   5 Introduction
   6 ============
   7 .. Describe the specific features and how it is realised in the scenario in a brief manner
   8 .. to ensure the user understand the context for the user guide instructions to follow.
   9
  10 This document will provide an overview of how to work with the SDN VPN features in
  11 OPNFV.
  12
  13 SDN VPN feature description
  14 ===========================
  15 .. Describe the specific usage for <XYZ> feature.
  16 .. Provide enough information that a user will be able to operate the feature on a deployed scenario.
  17
  18 A high-level description of the scenarios is provided in this section.
  19 For details of the scenarios and their provided capabilities refer to
  20 the scenario description document:
  21 http://artifacts.opnfv.org/colorado/sdnpvn/scenarios/os-odl_l2-bgpvpn/index.html
  22
  23 The BGPVPN feature enables creation of BGP VPNs on the Neutron API according to the OpenStack
  24 BGPVPN blueprint at https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-vpn.
  25 In a nutshell, the blueprint defines a BGPVPN object and a number of ways
  26 how to associate it with the existing Neutron object model, as well as a unique
  27 definition of the related semantics. The BGPVPN framework supports a backend
  28 driver model with currently available drivers for Bagpipe, OpenContrail, Nuage
  29 and OpenDaylight. The OPNFV scenario makes use of the OpenDaylight driver and backend
  30 implementation through the ODL VPNService project.
  31
  32 Hardware requirements
  33 =====================
  34
  35 The SDNVPN scenarios can be deployed as a bare-metal or a virtual environment on a single host.
  36
  37 Bare metal deployment on Pharos Lab
  38 -----------------------------------
  39
  40 Hardware requirements for bare-metal deployments of the OPNFV infrastructure are specified
  41 by the Pharos project. The Pharos project provides an OPNFV hardware specification for
  42 configuring your hardware at: http://artifacts.opnfv.org/pharos/docs/pharos-spec.html.
  43
  44 Virtual deployment hardware requirements
  45 ----------------------------------------
  46
  47 To perform a virtual deployment of an OPNFV scenario on a single host, that host has to
  48 meet the hardware requirements outlined in the <missing spec>.
  49
  50 When ODL is used as an SDN Controller in an OPNFV virtual deployment, ODL is
  51 running on the OpenStack Controller VMs. It is therefore recommended to
  52 increase the amount of resources for these VMs.
  53
  54 Our recommendation is to have 2 additional virtual cores and 8GB additional virtual memory
  55 on top of the normally recommended configuration.
  56
  57 Together with the commonly used recommendation this sums up to:
  58 ::
  59
  60  4 virtual cores
  61  16 GB virtual memory
  62
  63 See in Installation section below how to configure this.
  64
  65 Preparing the host to install Fuel by script
  66 ============================================
  67 .. Not all of these options are relevant for all scenario's.  I advise following the
  68 .. instructions applicable to the deploy tool used in the scenario.
  69
  70 Before starting the installation of the <scenario> scenario some preparation of the
  71 machine that will host the Fuel VM must be done.
  72
  73 Installation of required packages
  74 ---------------------------------
  75 To be able to run the installation of the basic OPNFV fuel installation the
  76 Jumphost (or the host which serves the VMs for the virtual deployment) needs to
  77 install the following packages:
  78 ::
  79
  80  sudo apt-get install -y git make curl libvirt-bin libpq-dev qemu-kvm \
  81                          qemu-system tightvncserver virt-manager sshpass \
  82                          fuseiso genisoimage blackbox xterm python-pip \
  83                          python-git python-dev python-oslo.config \
  84                          python-pip python-dev libffi-dev libxml2-dev \
  85                         libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \
  86                         expect curl python-netaddr p7zip-full
  87
  88  sudo pip install GitPython pyyaml netaddr paramiko lxml scp \
  89                   python-novaclient python-neutronclient python-glanceclient \
  90                   python-keystoneclient debtcollector netifaces enum
  91
  92 Download the source code and artifact
  93 -------------------------------------
  94 To be able to install the scenario os-odl_l2-bgpvpn one can follow the way
  95 CI is deploying the scenario.
  96 First of all the opnfv-fuel repository needs to be cloned:
  97 ::
  98
  99  git clone ssh://<user>@gerrit.opnfv.org:29418/fuel
 100
 101 This command downloads the whole repository fuel. We need now to switch it to
 102 the stable Colorado branch:
 103 ::
 104
 105  cd fuel
 106  git checkout stable/colorado
 107
 108 Now download the appropriate OPNFV Fuel ISO into an appropriate folder:
 109 ::
 110
 111  wget http://artifacts.opnfv.org/fuel/colorado/opnfv-colorado.1.0.iso
 112
 113 The exact name of the ISO image may change.
 114 Check https://www.opnfv.org/opnfv-colorado-fuel-users to get the latest ISO.
 115
 116 Simplified scenario deployment procedure using Fuel
 117 ===================================================
 118
 119 This section describes the installation of the os-odl_l2-bgpvpn-ha or
 120 os-odl_l2-bgpvpn-noha OPNFV reference platform stack across a server cluster
 121 or a single host as a virtual deployment.
 122
 123 Scenario Preparation
 124 --------------------
 125 dea.yaml and dha.yaml need to be copied and changed according to the lab-name/host
 126 where you deploy.
 127 Copy the full lab config from:
 128 ::
 129
 130  cp <path-to-opnfv-fuel-repo>/deploy/config/labs/devel-pipeline/elx \
 131     <path-to-opnfv-fuel-repo>/deploy/config/labs/devel-pipeline/<your-lab-name>
 132
 133 Add at the bottom of dha.yaml
 134 ::
 135
 136  disks:
 137    fuel: 100G
 138    controller: 100G
 139    compute: 100G
 140
 141  define_vms:
 142    controller:
 143      vcpu:
 144        value: 4
 145      memory:
 146        attribute_equlas:
 147          unit: KiB
 148        value: 16388608
 149      currentMemory:
 150        attribute_equlas:
 151          unit: KiB
 152        value: 16388608
 153
 154
 155 Check if the default settings in dea.yaml are in line with your intentions
 156 and make changes as required.
 157
 158 Installation procedures
 159 -----------------------
 160
 161 We describe several alternative procedures in the following.
 162 First, we describe several methods that are based on the deploy.sh script,
 163 which is also used by the OPNFV CI system.
 164 It can be found in the Fuel repository.
 165
 166 In addition, the SDNVPN feature can also be configured manually in the Fuel GUI.
 167 This is described in the last subsection.
 168
 169 Before starting any of the following procedures, go to
 170 ::
 171
 172  cd <opnfv-fuel-repo>/ci
 173
 174 Full automatic virtual deployment High Availablity Mode
 175 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 176
 177 The following command will deploy the high-availability flavor of SDNVPN scenario os-odl_l2-bgpvpn-ha
 178 in a fully automatic way, i.e. all installation steps (Fuel server installation, configuration,
 179 node discovery and platform deployment) will take place without any further prompt for user input.
 180 ::
 181
 182  sudo bash ./deploy.sh -b file://<path-to-opnfv-fuel-repo>/config/ -l devel-pipeline -p <your-lab-name> -s os-odl_l2-bgpvpn-ha -i file://<path-to-fuel-iso>
 183
 184 Full automatic virtual deployment NO High Availability Mode
 185 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 186
 187 The following command will deploy the SDNVPN scenario in its non-high-availability flavor (note the
 188 different scenario name for the -s switch). Otherwise it does the same as described above.
 189 ::
 190
 191  sudo bash ./deploy.sh -b file://<path-to-opnfv-fuel-repo>/config/ -l devel-pipeline -p <your-lab-name> -s os-odl_l2-bgpvpn-noha -i file://<path-to-fuel-iso>
 192
 193 Automatic Fuel installation and manual scenario deployment
 194 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 195
 196 A useful alternative to the full automatic procedure is to only autodeploy the Fuel host and to run host selection, role assignment and SDNVPN scenario configuration manually.
 197 ::
 198
 199  sudo bash ./deploy.sh -b file://<path-to-opnfv-fuel-repo>/config/ -l devel-pipeline -p <your-lab-name> -s os-odl_l2-bgpvpn-ha -i file://<path-to-fuel-iso> -e
 200
 201 With -e option the installer does not launch environment deployment, so
 202 a user can do some modification before the scenario is really deployed.
 203 Another interesting option is the -f option which deploys the scenario using an existing Fuel host.
 204
 205 The result of this installation is a fuel sever with the right config for
 206 BGPVPN. Now the deploy button on fuel dashboard can be used to deploy the environment.
 207 It is as well possible to do the configuration manuell.
 208
 209 Feature configuration on existing Fuel
 210 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 211 If a Fuel server is already provided but the fuel plugins for Opendaylight, Openvswitch
 212 and BGPVPN are not provided install them by:
 213 ::
 214
 215  cd /opt/opnfv/
 216  fuel plugins --install fuel-plugin-ovs-*.noarch.rpm
 217  fuel plugins --install opendaylight-*.noarch.rpm
 218  fuel plugins --install bgpvpn-*.noarch.rpm
 219
 220 If plugins are installed and you want to update them use --force flag.
 221
 222 Now the feature can be configured. Create a new environment with "Neutron with ML2 plugin" and
 223 in there "Neutron with tunneling segmentation".
 224 Then go to settings/other and check "OpenDaylight plugin", "Install Openvswitch with NSH/DPDK" and
 225 "BGPVPN plugin". Then you should be able to check "BGPVPN extensions" in OpenDaylight plugin section.
 226
 227 Now the deploy button on fuel dashboard can be used to deploy the environment.
 228
 229 Feature and API usage guidelines and example
 230 ============================================
 231 .. Describe with examples how to use specific features, provide API examples and details required to
 232 .. operate the feature on the platform.
 233
 234 For the details of using OpenStack BGPVPN API, please refer to the documentation
 235 at http://docs.openstack.org/developer/networking-bgpvpn/.
 236
 237 Example
 238 -------
 239 In the example we will show a BGPVPN associated to 2 neutron networks. The BGPVPN
 240 will have the import and export routes in the way that it imports its own Route. The outcome will be that vms sitting on these two networks will be able to have a full L3
 241 connectivity.
 242
 243 Some defines:
 244 ::
 245
 246  net_1="Network1"
 247  net_2="Network2"
 248  subnet_net1="10.10.10.0/24"
 249  subnet_net2="10.10.11.0/24"
 250
 251 Create neutron networks and save network IDs:
 252 ::
 253
 254  neutron net-create --provider:network_type=local $net_1
 255  export net_1_id=`echo "$rv" | grep " id " |awk '{print $4}'`
 256  neutron net-create --provider:network_type=local $net_2
 257  export net_2_id=`echo "$rv" | grep " id " |awk '{print $4}'`
 258
 259 Create neutron subnets:
 260 ::
 261
 262  neutron subnet-create $net_1 --disable-dhcp $subnet_net1
 263  neutron subnet-create $net_2 --disable-dhcp $subnet_net2
 264
 265 Create BGPVPN:
 266 ::
 267
 268  neutron bgpvpn-create --route-distinguishers 100:100 --route-targets 100:2530 --name L3_VPN
 269
 270 Start VMs on both networks:
 271 ::
 272
 273  nova boot --flavor 1 --image <some-image> --nic net-id=$net_1_id vm1
 274  nova boot --flavor 1 --image <some-image> --nic net-id=$net_2_id vm2
 275
 276 The VMs should not be able to see each other.
 277
 278 Associate to Neutron networks:
 279 ::
 280
 281  neutron bgpvpn-net-assoc-create L3_VPN --network $net_1_id
 282  neutron bgpvpn-net-assoc-create L3_VPN --network $net_2_id
 283
 284 Now the VMs should be able to ping each other
 285
 286 Troubleshooting
 287 ===============
 288 Check neutron logs on the controller:
 289 ::
 290
 291  tail -f /var/log/neutron/server.log |grep -E "ERROR|TRACE"
 292
 293 Check Opendaylight logs:
 294 ::
 295
 296  tail -f /opt/opendaylight/data/logs/karaf.log
 297
 298 Restart Opendaylight:
 299 ::
 300
 301  service opendaylight restart