Jump to: navigation, search

Difference between revisions of "Neutron/ServiceInsertionAndChaining"

(Overview)
Line 15: Line 15:
 
* The reviews related to the initial API work may be found here: https://review.openstack.org/#/q/topic:networking-sfc,n,z
 
* The reviews related to the initial API work may be found here: https://review.openstack.org/#/q/topic:networking-sfc,n,z
  
 +
= networking-sfc installation steps and testbed setup =
 +
 +
1. install Linux 14.04
 +
 +
2. clone networking-sfc into local repository
 +
* cd /opt/stack/
 +
* git clone git://git.openstack.org/openstack/networking-sfc.git
 +
* cd networking-sfc/
 +
 +
3. get networking-sfc unmerged code patches (port chain, FC, Common driver manager, OVS agent, DB Migration) into local repository
 +
* git fetch https://review.openstack.org/openstack/networking-sfc refs/changes/88/249488/2 && git merge FETCH_HEAD
 +
 +
4. Get CLI, networking-sfc devstack(not Mohan’s, but the one we posted) , rootwrap.d code patches into local repository
 +
* git fetch https://review.openstack.org/openstack/networking-sfc refs/changes/08/210008/23 && git cherry-pick FETCH_HEAD
 +
  fix conflict if any, then
 +
* git add .
 +
* git cherry-pick --continue
 +
 +
5. Set DB migration version to Liberty (Currently we base our testing on Liberty, later we will rebase to M-1 label)
 +
* cd networking_sfc/db/migration/alembic_migrations/versions
 +
* mv mitaka liberty
 +
 +
6. Clone Horizon, OpenStack devstack to local repository
 +
* cd /opt/stack
 +
  We did not install mohan’s change due to it does not work for stable/liberty
 +
* git clone git://git.openstack.org/openstack/horizon -b stable/liberty
 +
* git clone git://git.openstack.org/openstack-dev/devstack -b stable/liberty
 +
 +
7. copy local.conf to local repository and add the following line:
 +
* enable_plugin networking-sfc git://git.openstack.org/openstack/networking-sfc stable/liberty
 +
 +
8. run stack.sh
 +
* cd devstack
 +
* ./stack.sh
 +
  if it reports some errors, read the error messages and try to fix it.
 +
 +
9. Install OVS 2.3.2
 +
  We tried installing openvswitch to 2.3.2 but it seems having some issues at the beginning. The following list of commands are the ones we think should work on installing openvswitch 2.3.2.
 +
* cd /opt/stack
 +
* wget http://openvswitch.org/releases/openvswitch-2.3.2.tar.gz
 +
* tar -xzvf openvswitch-2.3.2.tar.gz
 +
* cd openvswitch-2.3.2/
 +
* sudo apt-get install git python-simplejson python-qt4 python-twisted-conch automake autoconf gcc uml-utilities libtool build-essential git pkg-config linux-headers-`uname -r`
 +
* sudo service openvswitch-switch stop
 +
* ./boot.sh
 +
* ./configure --with-linux=/lib/modules/`uname -r`/build --prefix=/usr --localstatedir=/var --sysconfdir=/etc
 +
* make
 +
* sudo make install
 +
* cd datapath/linux/
 +
* sudo modprobe openvswitch
 +
* sudo lsmod | grep openvswitch
 +
* cd /opt/stack/openvswitch-2.3.2/
 +
* sudo rm -f /etc/openvswitch/conf.db
 +
* sudo ovsdb-tool create /etc/openvswitch/conf.db  vswitchd/vswitch.ovsschema
 +
* sudo service openvswitch-switch restart
 +
* cd /opt/stack/devstack
 +
* ./unstack
 +
* ./stack
 +
 +
In our one-server  testbed, all OpenStack components run on one physical server. We created 3 VMs, one for source VM, another for Service Function VM, the last one for destination VM.
  
 
= Data Path Encapsulation Flow =
 
= Data Path Encapsulation Flow =

Revision as of 19:57, 7 December 2015

Overview

Service Function Chaining is a mechanism for overriding the basic destination based forwarding that is typical of IP networks. It is conceptually related to Policy Based Routing in physical networks but it is typically thought of as a Software Defined Networking technology. It is often used in conjunction with security functions although it may be used for a broader range of features. Fundamentally SFC is the ability to cause network packet flows to route through a network via a path other than the one that would be chosen by routing table lookups on the packet's destination IP address. It is most commonly used in conjunction with Network Function Virtualization when recreating in a virtual environment a series of network functions that would have traditionally been implemented as a collection of physical network devices connected in series by cables.

A very simple example of a service chain would be one that forces all traffic from point A to point B to go through a firewall even though the firewall is not literally between point A and B from a routing table perspective.

A more complex example is an ordered series of functions, each implemented in multiple VMs, such that traffic must flow through one VM at each hop in the chain but the network uses a hashing algorithm to distribute different flows across multiple VMs at each hop.

Series-Parallel Service Chain

An API and initial reference implementation of Service Function Chaining is being developed for Neutron during the Liberty cycle.

networking-sfc installation steps and testbed setup

1. install Linux 14.04

2. clone networking-sfc into local repository

3. get networking-sfc unmerged code patches (port chain, FC, Common driver manager, OVS agent, DB Migration) into local repository

4. Get CLI, networking-sfc devstack(not Mohan’s, but the one we posted) , rootwrap.d code patches into local repository

 fix conflict if any, then 
  • git add .
  • git cherry-pick --continue

5. Set DB migration version to Liberty (Currently we base our testing on Liberty, later we will rebase to M-1 label)

  • cd networking_sfc/db/migration/alembic_migrations/versions
  • mv mitaka liberty

6. Clone Horizon, OpenStack devstack to local repository

  • cd /opt/stack
 We did not install mohan’s change due to it does not work for stable/liberty

7. copy local.conf to local repository and add the following line:

8. run stack.sh

  • cd devstack
  • ./stack.sh
 if it reports some errors, read the error messages and try to fix it.

9. Install OVS 2.3.2

 We tried installing openvswitch to 2.3.2 but it seems having some issues at the beginning. The following list of commands are the ones we think should work on installing openvswitch 2.3.2.
  • cd /opt/stack
  • wget http://openvswitch.org/releases/openvswitch-2.3.2.tar.gz
  • tar -xzvf openvswitch-2.3.2.tar.gz
  • cd openvswitch-2.3.2/
  • sudo apt-get install git python-simplejson python-qt4 python-twisted-conch automake autoconf gcc uml-utilities libtool build-essential git pkg-config linux-headers-`uname -r`
  • sudo service openvswitch-switch stop
  • ./boot.sh
  • ./configure --with-linux=/lib/modules/`uname -r`/build --prefix=/usr --localstatedir=/var --sysconfdir=/etc
  • make
  • sudo make install
  • cd datapath/linux/
  • sudo modprobe openvswitch
  • sudo lsmod | grep openvswitch
  • cd /opt/stack/openvswitch-2.3.2/
  • sudo rm -f /etc/openvswitch/conf.db
  • sudo ovsdb-tool create /etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
  • sudo service openvswitch-switch restart
  • cd /opt/stack/devstack
  • ./unstack
  • ./stack

In our one-server testbed, all OpenStack components run on one physical server. We created 3 VMs, one for source VM, another for Service Function VM, the last one for destination VM.

Data Path Encapsulation Flow

SFC-datapath-flow-format-MAC-Rewriting


The initial reference implementation will be based on programming Open vSwitch with flow table entries that override the default MAC based forwarding and instead forward frames based on criteria defined via the Neutron SFC API. It will also be possible for third party SDN implementations with Neutron integration and SFC capabilities (e.g. Contrail, Nuage, etc) to program their respective forwarding planes based on the Neutron SFC API, but this will be dependent upon the respective vendors updating their SDN Controller integration with Neutron.