I have been checking the cbench tool and I have seen that it is using 100k unique MAC addresses to generate the flows. Right now I want to test one case using the cbench from a openvswitch and then try to emulate the behaviour of this cbench with the use of the pktgen tool. Connecting the same openvswitch to the nox controller I send from one node to another (both nodes connected to the openvswitch and included in the datapath) packets changing the UDP port. I am using the switch module provided by NOX with an idle timeout of 5 so when I send the packets I have to be careful that the time elapsed between consecutive packets for the same udp port is lower than 5 seconds. I tried to install 50000 flows (there are just 65536 ports in udp and some of them are reserved) and the rate was 10000 flows/second (each packet is a new flow till all the flows are installed). Theorically, in 5 seconds I should have 50000 flows installed in the flow-table, but after 120 seconds the amount of flows doesn't reach even the 20000 flows and there are disconnections between the Openflow switch and the NOX controller after receiving many events like this in the NOX controller:
ERR:received Openflow error packet from dpid=002320ca6695: type=1, code=8, 64 bytes of data Is it possible that the TCP window got overloaded and this would cause a disconnection in the secure channel? Thank you for your help, Jose. 2011/5/25 David Erickson <[email protected]> > As Ben mentioned, there are also a few posted benchmarks for NOX and other > controllers using cbench (part of the Oflops package) here: > http://www.openflow.org/wk/index.php/Controller_Performance_Comparisons > > -David > > > On 05/24/2011 12:52 PM, Ben Pfaff wrote: > >> So you're using Open vSwitch? What version? >> >> There shouldn't be any need to use an external tool to analyze >> OpenFlow traffic to and from Open vSwitch. You can just turn up the >> log level of the "vconn" module, e.g. "ovs-appctl vlog/set vconn". >> You can also use "ovs-ofctl snoop<bridge>" as an alternative. >> >> If your primary goal is to find the limits of the NOX controller, >> there is already a benchmark utility for that: >> http://www.openflow.org/wk/index.php/Oflops >> >> You might want to turn off packet buffering in the switch. >> >> On Tue, May 24, 2011 at 09:35:17PM +0200, Jose Luis Franco Arza wrote: >> >>> Thank you for your answer Ben, >>> The idea is to test the NOX controller and see how many flows per second >>> can >>> be handled. Imagine a situation in a data center where lots of flows are >>> sent per second, could the NOX controller handle them and install them >>> all?This is one of the objectives of this tests, find the limits of the >>> NOX >>> controller to handle the packets income in the control channel. >>> The version of OpenFlow that i'm using is the 1.0 provided with the >>> OpenVSwitch and in the NOX controller, the 0.6. I was thinking that one >>> of >>> the reasons of this packets loss could be that when the rate is high and >>> the >>> OpenFlow has to send every single packet to the controller then the >>> number >>> of packets queued in the switch increases till a point where they are >>> dropped, but the only tool I found to check the number of packets queued >>> is >>> this oftrace command. >>> >>> >>> 2011/5/24 Ben Pfaff<[email protected]> >>> >>> On Tue, May 24, 2011 at 08:47:05PM +0200, Jose Luis Franco Arza wrote: >>>> >>>>> I am an doing some scalability testings for my Master Thesis related to >>>>> OpenFlow. One of the aims is to obtain a limitation in the number of >>>>> >>>> flows >>>> >>>>> per second that the NOX controller can install. Using an UDP packet >>>>> generator and sending packets in a UDP ports range (each port >>>>> corresponds >>>>> >>>> to >>>> >>>>> a new flow) I have been trying to obtain a limit for the number of >>>>> flows >>>>> installed in the flow table and how many flows per second can be >>>>> >>>> installed >>>> >>>>> obtaining a good performance in the network. >>>>> >>>> >>>> If your goal is scalability, I doubt that sending the first packet of >>>> every flow up to the controller is a good way to achieve it. Your >>>> network will scale better if you proactively install flows, reducing >>>> the need to send traffic to the controller. >>>> >>>> You didn't say what version of OpenFlow you had installed, but it may >>>> not make sense to use the OpenFlow reference implementation for >>>> scalability testing. I don't think it's designed for performance but >>>> rather for simplicity. >>>> >>>> >> _______________________________________________ >>> openflow-discuss mailing list >>> [email protected] >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >> >> _______________________________________________ >> openflow-discuss mailing list >> [email protected] >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> >> > _______________________________________________ > openflow-discuss mailing list > [email protected] > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >
_______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
