The virtual switch

Virtual switches are what makes OpenFlow overlay networks possible. When created, a virtual switch will behave as an OpenFlow device, manipulating packets according to the flow table information it recieves from the controller. by default, there are no virtual switches set up on the IP8800. You have to create them either by specifying them in openflow.conf or by using the command setvsi through the CLI. Here we talk about the latter way of creating virtual switches.

Overview

This article covers:

• Virtual switch setup from CLI (as opposed to directly editing openflow.conf)
• The official NEC guide for the OpenFlow capable IP8800/S3640 (attachment)

CLI Commands

The commands for virtual switching will not be found among the usual list of commands that are listed when you type ? at the terminal. Command completion doesn't work either, so you have to type out the whole command. In addition, if no-save was specified in openflow.conf, you will not be able to use setvsi or deletevsi from the CLI.

The commands, summarized (ignoring the flags)

• setvsi - starts a virtual switch
• deletevsi - deletes a virtual switch
• showswitch - shows the configurations of a virtual switch
• showflow - shows the flows currently being implemented

The detailed list of commands and their uses are found on the NEC guide.

Starting virtual switches

VLAN 28 on the switch used in the Sandbox 9 setup is made to run a virtual switch. The current port configurations:

• ports 1-12 : CM (VLAN 3)
• ports 13-24 : Control (VLAN 27)
• ports 25-36 : Data (VLAN 28)
• ports 37-48 : Trunk

The ports were assigned to the VLANs using the CLI (details here). To start the virtual switch on VLAN 28 (ports 25-36), in the CLI type:

setvsi 28 25-36 tcp 172.16.100.1:6633 dpid 0x012345678987

This starts a virtual switch with the VLAN ID 28 encompassing all 12 VLAN 28 ports, that uses a TCP connection to the controller at port 6633. The dpid is a 12-digit hex number used by the controller to identify a virtual switch. The entry is automatically added to openflow.conf. In that respect, it is not necessary to boot the switch with a pre-written .conf file; as long as you have the VLANs, you can just start the virtual switches through the CLI.

To see the switch:

sw-sb09> showswitch
vlan    ports                                           secure channel      
----    -----                                           --------------      
28      25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36  disconnected        

Using the VLAN ID as the virtual switch's ID is not really necessary, nor is it to limit a virtual switch to one VLAN. Here, a switch of VLAN ID 45 is started across ports from VLANs 3 and 27.

sw-sb09> setvsi 45 9-16 tcp 172.16.1.110:6634 dpid 0xdeadbeefface
sw-sb09> showswitch 45 detail
Virtual switch 45
  Datapath ID : 244837814106830(0xdeadbeefface)
  Port        : gigabitethernet 0/9 (link down)                                 
                gigabitethernet 0/10 (link down)                                
                gigabitethernet 0/11 (link down)                                
                gigabitethernet 0/12 (link down)                                
                gigabitethernet 0/13 (link down)                                
                gigabitethernet 0/14 (link down)                                
                gigabitethernet 0/15 (link down)                                
                gigabitethernet 0/16 (link down)                                
  Conn mode   : tcp             
  Controller  : 172.16.1.110:6634 (disconnected)
  Exact match : 01-24, 49-50 hw 0 / hw max 1510
                25-48        hw 0 / hw max 1510
  Exact match : sw 0 / sw max 131072
  Wildcard    : sw 0 / sw max 100
  Packet buff : 256 packets / 4294967295 MB
  Miss sendlen: 128 bytes
  Wcard mode  : S/W only

Some troubleshooting (7/8)

• If you have a group of ports, and they share a VLAN, if even one port out of the group is configured to be a virtual switch, the whole group of ports cease to function as a regular switch.

• If some ports of the switch are meant to be left as legacy switches, it is better to not include the trunk info when using the setvsi command. Including the trunk port in setvsi when there is no controller will mess up functionality of the trunk as well.

The virtual switch in idle state - an experiment using Ruby sockets (8/4)

The switch will keep trying to contact a controller, regardless of whether the controller is active or not. This happens once every 15 seconds or so, and can be seen with a very simple script that listens on TCP 6633 (the default OpenFlow port) on the console's OpenFlow VLAN interface, which has the IP address 172.16.100.1:

#!/usr/bin/ruby -w
require 'socket'

# allow the switch to try to establish a connection
ofpsock = TCPserver.new("172.16.100.1", 6633)

puts "port    peer IP"
#listen to see what port the switch is using
while (session = ofpsock.accept)
        t = Time.now   # to see interval of messages 
        peer = session.peeraddr
        puts "#{peer[1]}  #{peer[2]}    #{t.to_s.split[3]}"
session.close
end

You get:

port    peer IP     
55354   172.16.100.10     20:53:22 
55353   172.16.100.10     20:53:37 
55352   172.16.100.10     20:53:52 
55351   172.16.100.10     20:54:07 
...

The first and second columns show the port and IP address of the peer, respectively. 172.16.100.10 is the VLAN interface IP address for the Openflow VLAN on the switch, so you know it is the OpenFlow switch trying to establish a connection with the controller.

go back to OpenFlow index