Open vSwitch Advanced Features Tutorial=======================================Many tutorials cover the basics of OpenFlow.  This is not such atutorial.  Rather, a knowledge of the basics of OpenFlow is aprerequisite.  If you do not already understand how an OpenFlow flowtable works, please go read a basic tutorial and then continue readinghere afterward.It is also important to understand the basics of Open vSwitch beforeyou begin.  If you have never used ovs-vsctl or ovs-ofctl before, youshould learn a little about them before proceeding.Most of the features covered in this tutorial are Open vSwitchextensions to OpenFlow.  Also, most of the features in this tutorialare specific to the software Open vSwitch implementation.  If you areusing an Open vSwitch port to an ASIC-based hardware switch, thistutorial will not help you.This tutorial does not cover every aspect of the features that itmentions.  You can find the details elsewhere in the Open vSwitchdocumentation, especially ovs-ofctl(8) and the comments in theinclude/openflow/nicira-ext.h header file.>>> In this tutorial, paragraphs set off like this designate notes    with additional information that readers may wish to skip on a    first read.Getting Started===============This is a hands-on tutorial.  To get the most out of it, you will needOpen vSwitch binaries.  You do not, on the other hand, need anyphysical networking hardware or even supervisor privilege on yoursystem.  Instead, we will use a script called "ovs-sandbox", whichaccompanies the tutorial, that constructs a software simulated networkenvironment based on Open vSwitch.You can use "ovs-sandbox" three ways:    * If you have already installed Open vSwitch on your system, then      you should be able to just run "ovs-sandbox" from this directory      without any options.    * If you have not installed Open vSwitch (and you do not want to      install it), then you can build Open vSwitch according to the      instructions in INSTALL, without installing it.  Then run      "./ovs-sandbox -b DIRECTORY" from this directory, substituting      the Open vSwitch build directory for DIRECTORY.    * As a slight variant on the latter, you can run "make sandbox"      from an Open vSwitch build directory.When you run ovs-sandbox, it does the following:    1. CAUTION: Deletes any subdirectory of the current directory       named "sandbox" and any files in that directory.    2. Creates a new directory "sandbox" in the current directory.    3. Sets up special environment variables that ensure that Open       vSwitch programs will look inside the "sandbox" directory       instead of in the Open vSwitch installation directory.    4. If you are using a built but not installed Open vSwitch,       installs the Open vSwitch manpages in a subdirectory of       "sandbox" and adjusts the MANPATH environment variable to point       to this directory.  This means that you can use, for example,       "man ovs-vsctl" to see a manpage for the ovs-vsctl program that       you built.    5. Creates an empty Open vSwitch configuration database under       "sandbox".    6. Starts ovsdb-server running under "sandbox".    7. Starts ovs-vswitchd running under "sandbox", passing special       options that enable a special "dummy" mode for testing.    8. Starts a nested interactive shell inside "sandbox".At this point, you can run all the usual Open vSwitch utilities fromthe nested shell environment.  You can, for example, use ovs-vsctl tocreate a bridge:    ovs-vsctl add-br br0From Open vSwitch‘s perspective, the bridge that you create this wayis as real as any other.  You can, for example, connect it to anOpenFlow controller or use "ovs-ofctl" to examine and modify it andits OpenFlow flow table.  On the other hand, the bridge is not visibleto the operating system‘s network stack, so "ifconfig" or "ip" cannotsee it or affect it, which means that utilities like "ping" and"tcpdump" will not work either.  (That has its good side, too: youcan‘t screw up your computer‘s network stack by manipulating asandboxed OVS.)When you‘re done using OVS from the sandbox, exit the nested shell (byentering the "exit" shell command or pressing Control+D).  This willkill the daemons that ovs-sandbox started, but it leaves the "sandbox"directory and its contents in place.The sandbox directory contains log files for the Open vSwitch dameons.You can examine them while you‘re running in the sandboxed environmentor after you exit.Motivation==========The goal of this tutorial is to demonstrate the power of Open vSwitchflow tables.  The tutorial works through the implementation of aMAC-learning switch with VLAN trunk and access ports.  Outside of theOpen vSwitch features that we will discuss, OpenFlow provides at leasttwo ways to implement such a switch:    1. An OpenFlow controller to implement MAC learning in a       "reactive" fashion.  Whenever a new MAC appears on the switch,       or a MAC moves from one switch port to another, the controller       adjusts the OpenFlow flow table to match.    2. The "normal" action.  OpenFlow defines this action to submit a       packet to "the traditional non-OpenFlow pipeline of the       switch".  That is, if a flow uses this action, then the packets       in the flow go through the switch in the same way that they       would if OpenFlow was not configured on the switch.Each of these approaches has unfortunate pitfalls.  In the firstapproach, using an OpenFlow controller to implement MAC learning, hasa significant cost in terms of network bandwidth and latency.  It alsomakes the controller more difficult to scale to large numbers ofswitches, which is especially important in environments with thousandsof hypervisors (each of which contains a virtual OpenFlow switch).MAC learning at an OpenFlow controller also behaves poorly if theOpenFlow controller fails, slows down, or becomes unavailable due tonetwork problems.The second approach, using the "normal" action, has differentproblems.  First, little about the "normal" action is standardized, soit behaves differently on switches from different vendors, and theavailable features and how those features are configured (usually notthrough OpenFlow) varies widely.  Second, "normal" does not work wellwith other OpenFlow actions.  It is "all-or-nothing", with littlepotential to adjust its behavior slightly or to compose it with otherfeatures.Scenario========We will construct Open vSwitch flow tables for a VLAN-capable,MAC-learning switch that has four ports:    * p1, a trunk port that carries all VLANs, on OpenFlow port 1.    * p2, an access port for VLAN 20, on OpenFlow port 2.    * p3 and p4, both access ports for VLAN 30, on OpenFlow ports 3      and 4, respectively.>>> The ports‘ names are not significant.  You could call them eth1    through eth4, or any other names you like.>>> An OpenFlow switch always has a "local" port as well.  This    scenario won‘t use the local port.Our switch design will consist of five main flow tables, each of whichimplements one stage in the switch pipeline:    Table 0: Admission control.    Table 1: VLAN input processing.    Table 2: Learn source MAC and VLAN for ingress port.    Table 3: Look up learned port for destination MAC and VLAN.    Table 4: Output processing.The section below describes how to set up the scenario, followed by asection for each OpenFlow table.You can cut and paste the "ovs-vsctl" and "ovs-ofctl" commands in eachof the sections below into your "ovs-sandbox" shell.  They are alsoavailable as shell scripts in this directory, named t-setup, t-stage0,t-stage1, ..., t-stage4.  The "ovs-appctl" test commands are intendedfor cutting and pasting and are not supplied separately.Setup=====To get started, start "ovs-sandbox".  Inside the interactive shellthat it starts, run this command:    ovs-vsctl add-br br0 -- set Bridge br0 fail-mode=secureThis command creates a new bridge "br0" and puts "br0" into so-called"fail-secure" mode.  For our purpose, this just means that theOpenFlow flow table starts out empty.>>> If we did not do this, then the flow table would start out with a    single flow that executes the "normal" action.  We could use that    feature to yield a switch that behaves the same as the switch we    are currently building, but with the caveats described under    "Motivation" above.)The new bridge has only one port on it so far, the "local port" br0.We need to add p1, p2, p3, and p4.  A shell "for" loop is one way todo it:    for i in 1 2 3 4; do        ovs-vsctl add-port br0 p$i -- set Interface p$i ofport_request=$i	ovs-ofctl mod-port br0 p$i up    doneIn addition to adding a port, the ovs-vsctl command above sets its"ofport_request" column to ensure that port p1 is assigned OpenFlowport 1, p2 is assigned OpenFlow port 2, and so on.>>> We could omit setting the ofport_request and let Open vSwitch    choose port numbers for us, but it‘s convenient for the purposes    of this tutorial because we can talk about OpenFlow port 1 and    know that it corresponds to p1.The ovs-ofctl command above brings up the simulated interfaces, whichare down initially, using an OpenFlow request.  The effect is similarto "ifconfig up", but the sandbox‘s interfaces are not visible to theoperating system and therefore "ifconfig" would not affect them.We have not configured anything related to VLANs or MAC learning.That‘s because we‘re going to implement those features in the flowtable.To see what we‘ve done so far to set up the scenario, you can run acommand like "ovs-vsctl show" or "ovs-ofctl show br0".Implementing Table 0: Admission control=======================================Table 0 is where packets enter the switch.  We use this stage todiscard packets that for one reason or another are invalid.  Forexample, packets with a multicast source address are not valid, so wecan add a flow to drop them at ingress to the switch with:    ovs-ofctl add-flow br0         "table=0, dl_src=http://www.mamicode.com/01:00:00:00:00:00/01:00:00:00:00:00, actions=drop">