Tag Archives: Testing

Mininet, Pox, and Generating Flows per Second

1 Reply

Development for testing Layer2 flows per second was successful! The goals were the following:

  • get a controller to generate X number of flows (currently L2 flows) to see how many flows a switch could handle
  • 2nd, get a controller to generate X number of flows per second

Both were successful thanks to mininet. http://mininet.org/

Mininet creates virtual hosts, controllers, and switches in an instant. This was developed by people that wanted create a tool to help with openflow/SDN development.

It was pretty easy to get setup by just following their directions on their website. Once I downloaded the mininet VM, installed it… it was up and running.

The entire testing setup consisted:

  • a Mininet VM, which had an openflow switch and two hosts
  • a POX openflow controller on my local machine

All I had to do to get mininet to connect to the controller on my local machine was to point it to my actual network interface that go me outside of my machine on to our production network.

sudo mn --controller=remote,ip=10.180.0.207,port=6633

I tried from mininet to have it use my loopback address and the nat’d gateway address, but neither worked until I used my local computers prodcuction network NIC.

Once I did that, mininet connected to my machines POX controller…

INFO:openflow.of_01:[00-00-00-00-00-01 1] connected
DEBUG:forwarding.ryan_l2:Switch 00-00-00-00-00-01 has come up.

Here is the code that is used for Flows per second testing…

http://sites.duke.edu/dukesdn/2013/11/06/pox-l2-flow-generator-code/ 

The default for the code is 100 flows total, 10 per second. This can be changed by edit a couple of the numbers commented in the code.

In mininet, in order to see the flows you type the following…

mininet> dpctl dump-flows
*** s1 ------------------------------------------------------------------------
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=31.849s, table=0, n_packets=0, n_bytes=0, idle_age=31, dl_dst=01:23:45:d6:52:a3 actions=output:2
 cookie=0x0, duration=34.973s, table=0, n_packets=0, n_bytes=0, idle_age=34, dl_dst=01:23:45:98:8d:f4 actions=output:2
 cookie=0x0, duration=33.935s, table=0, n_packets=0, n_bytes=0, idle_age=33, dl_dst=01:23:45:2f:8d:55 actions=output:4
 cookie=0x0, duration=36.006s, table=0, n_packets=0, n_bytes=0, idle_age=36, dl_dst=01:23:45:d5:1a:2e actions=output:4
 cookie=0x0, duration=32.899s, table=0, n_packets=0, n_bytes=0, idle_age=32, dl_dst=01:23:45:db:89:8d actions=output:4

Since each line is a flow (except the first line) we can just use the wc (word count) command to see the number…

The output will be:

# of lines, # of words, and # of characters

mininet> dpctl dump-flows | wc
*** s1 ------------------------------------------------------------------------
 101 803 12107

So we have 101 lines, or 100 flows.

POX L2 Flow Generator Code module

Leave a reply

from pox.core import core

from pox.lib.util import dpid_to_str

import pox.openflow.libopenflow_01 as of

import pox.lib.packet as pkt

from pox.lib.addresses import IPAddr, EthAddr

from random import randrange

from pox.lib.recoco import Timer

 

 

log = core.getLogger()

flows = 0 #flows counts the number of flows we want there in the end it’s defined as a global VAR

 

class testFlows (object):

def __init__ (self):

core.openflow.addListeners(self)

 

def _handle_ConnectionUp (self, event): # as soon as a switch starts up we’re going to start writing random flows to it

log.debug(“Switch %s has come up.”, dpid_to_str(event.dpid))

def pushflows():

global flows

if flows < 100: #Change this number to the maximum number of flows you want installed

print “starting timer in 1secs” #you can take or leave this one… just a test

for x in range(0, 10): # set the number of rules that you want per second to the second number in the range

macaddress = ’01:23:45:’+hex(randrange(16,255))[2:]+’:’+hex(randrange(16,255))[2:]+’:’+hex(randrange(16,255))[2:] # create a random mac. random number 16-255 and then convert to hex

port = randrange(2,5) # assign to random port in a range

msg = of.ofp_flow_mod()

#msg.priority = 32768 # set priority

msg.match.dl_dst = EthAddr(macaddress) # match our random mac address to a destination port

msg.actions.append(of.ofp_action_output(port = port)) # set destination port

event.connection.send(msg) # send our flow out

log.debug(“installing flow for destination of %s” % (macaddress)) # log it

flows = flows + 1

Timer(1, pushflows, recurring = True)  #timer is set to 1 second

def launch ():

core.registerNew(testFlows) # startup and run class

perfSONAR Tests – 9/03/13 – Bandwidth Testing Between Blade Chassis

Leave a reply
 
perfSONAR test from SDN-09 to SDN-01, SDN-02, and SDN-12

Jianan Wang ran a series of pefSONAR tests from approximately 12:00 AM on 9/3/13 to 4:00 AM on 9/4/13.

These test were run from SDN-09 (in NB154) to SDN-01 and SDN-02 in NB-145 (DSCR).

The results are shown below:

perfSONAR test from SDN-09 to SDN-01, SDN-02, and SDN-12

As expected, the performance that stayed ‘in chassis’ from SDN-09 to SDN-12 was constant at about 9 GBPS.  The performance achieved for inter chassis communication that is required to go through the core network on the openflow VRF showed significant variability.  Post testing it was determined that testing from machines in the DSCR to the OIT NAS heads in NB154 was responsible for the performance degradation during the day.  Given that SDN-01 and SDN-02 are in the same chassis we are not certain of the cause of the difference in performance between them during the period of midnight to 10 AM, but they appeared to converge to between 8 and 8.5 Gbps after midnight on the 3rd.

Testing Processes

Leave a reply

A series of bandwidth tests have been performed using the existing production network in order to understand baseline performance capabilities as well as confirming the impact that large file transfers have on the network.

It was assumed that a 10G connected server would not be able to impact the core 20G Duke network.  However, we have seen multiple impacts on the Duke network due to baseline testing for this project.

perfSONAR tests have been shown to be NON intrusive, but large, dedicated load cannons that do sustained file transfers have highlighted capacity issues in the core Duke academic campus network.