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
