Version 11 (modified by Hussamuddin Nasir, 5 years ago) (diff)


NFV Tutorial: Managing a Virtual Network Function using SDN and Control Theory

Image Map

Part I: Design/Setup

1. Design the Experiment

The basic topology of the tutorial is shown above. We have two sources that will communicate with the destination via an OVS switch. We have two VMs (VNF1 and VNF2) running instances of the Snort Intrusion Detection System (IDS), representing the Virtual Network Function (VNF). In this tutorial, we will install forwarding rules in the OVS using a controller such that whenever a source sends packets to the destination, a copy of each packet is also sent to one of the IDS for intrusion detection analysis.

Iperf will be run as an application and we will observe the operation and impact of different strategies for load balancing across the IDS instances.

Though in this tutorial, we will be using Snort IDS as an example VNF, one can consider other network functions, e.g., a firewall, a caching (proxy) server, etc.

2. Establish the environment

2.1. Pre-work: (Skip this section if you have already established your environment for your project.)

  • Ensure SSH keys are setup. If your SSH keys are not setup before, do the following steps:
    • Generate an SSH Private Key on the Profile page on the GENI portal
    • Download the Private Key to ~/Downloads
    • Open terminal and execute
      $ mv ~/Downloads/id_geni_ssh_rsa ~/.ssh/.
      $ chmod 0600 ~/.ssh/id_geni_ssh_rsa
      $ ssh-add ~/.ssh/id_geni_ssh_rsa

  • Ensure you are part of a project.

3. Obtain Resources

For this tutorial, you can use resources from any aggregate in GENI, but preferably an instaGENI aggregate (e.g., CENIC IG or Cornell IG). The experiment will need the following:

  • 1 Xen VM for the OpenFlow controller with a public IP (controller)
  • 1 Xen VM for the OpenFlow virtual switch (OVS)
  • 3 Xen VMs, two Sources and one Destination (S1, S2 and destination)
  • 2 Xen VMs for two Virtual Network Function instances (VNF1 and VNF2)

We will need two slices for this tutorial:

  1. A Slice for the OpenFlow controller.
  2. A Slice for the Network consisting of sources, destination, IDSes and OVS.

To reserve resources, use the GENI portal.

3.1. Controller

  • Open the slice that will run the OpenFlow controller. You may call it 'Controller-xx', with xx replaced with your initials or last name. Select a VM running the controller using the RSpec that is available in the portal called XEN OpenFlow Controllers. This is shown in the picture below.

  • Choose any InstaGENI aggregate (e.g. CENIC or Cornell IG) and reserve resources for the controller. You will see the controller VM as shown below.

3.2. Network

Create a new slice 'Network-xx', with xx replaced by your initials or last name, for a network whose topology will consist of two sources, a destination, an OVS and two VNFs. Use this given Rspec to reserve resources for this Network slice.

Although you can choose any InstaGENI aggregate to reserve resources for the Network slice, for this tutorial, it is simpler (and more effective!) to just use the same IG aggregate as the one used for your Controller slice. You will have a network of 6 VMs as shown below. This may take a while!

3.3. Configure and Initialize

Although OVS is installed on the host and is meant to act as a software switch, it still needs to be configured. There are two things that need to be configured:

(1) configure your software switch with the interfaces as ports and
(2) point the switch to the OpenFlow controller.

3.3.1. Configure the Software Switch (OVS Window):

  1. Login to the OVS host (on the Network slice)
  2. Create an Ethernet bridge that will act as our software switch:
    sudo ovs-vsctl add-br br0
  3. Prepare the interfaces to be added as ports to the OVS switch
    Your OVS bridge will be a Layer 2 switch and your ports do not need IP addresses. Before we remove them let's keep some information
    • Run ifconfig on ovs node
    • Write down the interface names that correspond to the connections to your VNF1 and VNF2 hosts. The correspondence is
      • Interface with IP to VNF1 - ethX
      • Interface with IP to VNF2 – ethY
Make sure you have noted the names of the interfaces before you proceed. We will need the interface names to run experiments. (Otherwise, you have to figure out later which OVS interface is connected to each host by pinging from, say, one source to each VNF, after running "sudo tcpdump -i ethX" on each OVS interface.)

  1. Prepare the interfaces to be added as ports to the OVS switch.
    • Your OVS bridge will be a Layer 2 switch and your ports do not need IP addresses. Remove the IP from your data interfaces.
         sudo ifconfig eth1 0
         sudo ifconfig eth2 0
         sudo ifconfig eth3 0
         sudo ifconfig eth4 0
         sudo ifconfig eth5 0
Be careful not to bring down eth0. This is the control interface, if you bring that interface down you won't be able to login to your host. For all interfaces other than eth0 and l0, remove the IP from the interfaces (your interface names may vary).

Add all the data interfaces to your switch (bridge): Be careful not to add interface eth0. This is the control interface. The other four interfaces are your data interfaces. (Use the same interfaces as you used in the previous step).

   sudo ovs-vsctl add-port br0 eth1
   sudo ovs-vsctl add-port br0 eth2
   sudo ovs-vsctl add-port br0 eth3
   sudo ovs-vsctl add-port br0 eth4
   sudo ovs-vsctl add-port br0 eth5

Now the software switch is configured! To verify that the five ports are configured, run the following command to see all five ports listed:

         sudo ovs-vsctl list-ports br0

3.3.2. Point your switch to a controller

An OpenFlow switch will not forward any packet unless instructed by a controller. Basically the forwarding table is empty, until an external controller inserts forwarding rules. The OpenFlow controller communicates with the switch over the control network and it can be anywhere in the Internet as long as it is reachable by the OVS host.
  1. Login to your controller
  2. Find the control interface IP of your controller, use ifconfig and note down the IP address of eth0.
  3. In order to point our software OpenFlow switch to the controller, in the ovs terminal window, run:
          sudo ovs-vsctl set-controller br0 tcp:<controller_ip >:6633
  1. Set your switch's fail-safe-mode to secure. For more info read the standalone vs secure mode section. Run:
          sudo ovs-vsctl set-fail-mode br0 secure
  1. Trust but verify. You can verify your OVS settings by issuing the following:
          sudo ovs-vsctl show
Standalone vs Secure mode
The OpenFlow controller is responsible for setting up all flows on the switch, which means that when the controller is not running there should be no packet switching at all. Depending on the setup of your network, such a behavior might not be desired. It might be best that when the controller is down, the switch should default back to being a learning layer 2 switch. In other circumstances however this might be undesirable. In OVS this is a tunable parameter, called fail-safe-mode which can be set to the following parameters:
  • standalone [default]: in this case OVS will take responsibility for forwarding the packets if the controller fails
  • secure: in this case only the controller is responsible for forwarding packets, and if the controller is down all packets are dropped.

In OVS when the parameter is not set it falls back to the standalone mode. For the purpose of this tutorial we will set the fail-safe-mode to secure, since we want to be the ones controlling the forwarding.

Next: Execute

Attachments (6)

Download all attachments as: .zip