Small final improvements in userguide.
[sdnvpn.git] / docs / userguide / feature.userguide.rst
index deb22e9..6b5f4dd 100644 (file)
@@ -158,9 +158,14 @@ and make changes as required.
 Installation procedures
 -----------------------
 
-We describe several alternative procedures in the following.
+We describe several alternative procedures in the following. 
+First, we describe several methods that are based on the deploy.sh script, which is also used by the OPNFV CI system. 
+It can be found in the Fuel repository. 
 
-Go to
+In addition, the SDNVPN feature can also be configured manually in the Fuel GUI. 
+This is described in the last subsection. 
+
+Before starting any of the following procedures, go to
 ::
 
  cd <opnfv-fuel-repo>/ci
@@ -176,9 +181,10 @@ node discovery and platform deployment) will take place without any further prom
  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>
 
 Full automatic virtual deployment NO High Availability Mode
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The following command will deploy the SDNVPN scenario in its non-high-availability flavor. Otherwise it does the same as described above.
+The following command will deploy the SDNVPN scenario in its non-high-availability flavor (note the 
+different scenario name for the -s switch). Otherwise it does the same as described above.
 ::
 
  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>
@@ -193,9 +199,32 @@ A useful alternative to the full automatic procedure is to only autodeploy the F
 
 With -e option the installer does not launch environment deployment, so
 a user can do some modification before the scenario is really deployed.
-
 Another interesting option is the -f option which deploys the scenario using an existing Fuel host.
 
+The result of this installation is a fuel sever with the right config for
+BGPVPN. Now the deploy button on fuel dashboard can be used to deploy the environment.
+It is as well possible to do the configuration manuell.
+
+Feature configuration on existing Fuel
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+If a Fuel server is already provided but the fuel plugins for Opendaylight, Openvswitch
+and BGPVPN are not provided install them by:
+::
+
+ cd /opt/opnfv/
+ fuel plugins --install fuel-plugin-ovs-*.noarch.rpm
+ fuel plugins --install opendaylight-*.noarch.rpm
+ fuel plugins --install bgpvpn-*.noarch.rpm
+
+If plugins are installed and you want to update them use --force flag.
+
+Now the feature can be configured. Create a new environment with "Neutron with ML2 plugin" and
+in there "Neutron with tunneling segmentation".
+Then go to settings/other and check "OpenDaylight plugin", "Install Openvswitch with NSH/DPDK" and
+"BGPVPN plugin". Then you should be able to check "BGPVPN extensions" in OpenDaylight plugin section.
+
+Now the deploy button on fuel dashboard can be used to deploy the environment.
+
 Feature and API usage guidelines and example
 ============================================
 .. Describe with examples how to use specific features, provide API examples and details required to
@@ -204,10 +233,68 @@ Feature and API usage guidelines and example
 For the details of using OpenStack BGPVPN API, please refer to the documentation
 at http://docs.openstack.org/developer/networking-bgpvpn/.
 
-Can we give a basic example here?  Pointing someone off to a generic document in reference to
-this specific compilation of components feels a little like only half the job.  :)
+Example
+-------
+In the example we will show a BGPVPN associated to 2 neutron networks. The BGPVPN
+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
+connectivity.
+
+Some defines:
+::
+
+ net_1="Network1"
+ net_2="Network2"
+ subnet_net1="10.10.10.0/24"
+ subnet_net2="10.10.11.0/24"
+
+Create neutron networks and save network IDs:
+::
+
+ neutron net-create --provider:network_type=local $net_1
+ export net_1_id=`echo "$rv" | grep " id " |awk '{print $4}'`
+ neutron net-create --provider:network_type=local $net_2
+ export net_2_id=`echo "$rv" | grep " id " |awk '{print $4}'`
+
+Create neutron subnets:
+::
+
+ neutron subnet-create $net_1 --disable-dhcp $subnet_net1
+ neutron subnet-create $net_2 --disable-dhcp $subnet_net2
+
+Create BGPVPN:
+::
+
+ neutron bgpvpn-create --route-distinguishers 100:100 --route-targets 100:2530 --name L3_VPN
+
+Start VMs on both networks:
+::
+
+ nova boot --flavor 1 --image <some-image> --nic net-id=$net_1_id vm1
+ nova boot --flavor 1 --image <some-image> --nic net-id=$net_2_id vm2
+
+The VMs should not be able to see each other.
+
+Associate to Neutron networks:
+::
+
+ neutron bgpvpn-net-assoc-create L3_VPN --network $net_1_id
+ neutron bgpvpn-net-assoc-create L3_VPN --network $net_2_id
+
+Now the VMs should be able to ping each other
 
 Troubleshooting
 ===============
+Check neutron logs on the controller:
+::
+
+ tail -f /var/log/neutron/server.log |grep -E "ERROR|TRACE"
+
+Check Opendaylight logs:
+::
+
+ tail -f /opt/opendaylight/data/logs/karaf.log
+
+Restart Opendaylight:
+::
 
-What? I thought this would work!
+ service opendaylight restart