= 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 [wiki:Internal/OpenFlow/CLISetup 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. [[BR]] [[BR]] [wiki:Internal/OpenFlow/ go back to OpenFlow index]