[ovs-discuss] proactive controller utility contribution request

Ben Pfaff blp at ovn.org
Wed Mar 8 18:34:59 UTC 2017


On Mon, Feb 27, 2017 at 04:21:26PM +0100, José Luis Millán wrote:
> On Fri, Feb 24, 2017 at 6:59 PM, Ben Pfaff <blp at ovn.org> wrote:
> 
> > On Fri, Feb 24, 2017 at 01:10:23PM +0100, José Luis Millán wrote:
> > > I am developing a simple utility tool that maintains connections with a
> > > list of switches and adds and removes flows on them.
> > >
> > > It's been called 'ovs-proactivecontroller' and it is inspired by
> > > 'ovs-testcontroller' utilitly, with the difference that the first does
> > not
> > > listen for connections since it is only intended to be used proactively.
> > >
> > > A new kind of switch has been created; 'passive_switch' (pswitch),
> > > analogous to the existing 'learning_switch' (lswitch), which represents a
> > > passive switch.
> > >
> > > The utility is a daemon which exposes a RPC interface via 'unixctl'
> > server
> > > with the following self explanatory API :
> > >
> > > - add_switch
> > > - del_switch
> > > - add_flow
> > > - del_flows
> > >
> > > It also accepts as startup options a file name with a list of switches as
> > > well as a file name with a list of flows. In case these options are
> > > provided, the daemon connects to the given switches at startup and
> > installs
> > > the given flows upon connection.
> > >
> > > The aim of the utility is spreading the given flows on each switch.
> >
> > To me, this sounds a lot like ovs-testcontroller with the --with-flows
> > option, with the added unixctl API.  Did you consider refining
> > ovs-testcontroller to support the unixctl API?  It would be easy to
> > accept those kinds of changes.
> >
> 
> I definitely agree.
> 
> Let me please comment a couple of points.
> 
> - switches would be added and removed based on the unixctl API as well as
> via the current command line active connection methods (ssl:ip[:port],
> tcp:ip[:port],
> unix:file)
> - ovs-testcontroller would not terminate when no more connections are
> available.
> 
> On the other hand, in lswitch_handshake (learning-switch.c) for OPF
> versions greater than 13, a flow is being installed so the switch sends
> packets to the controller by default. This is not a desirable behaviour for
> the proactive controller. How can this cleanly made? Maybe providing a
> utility option --proactive that translates into a lswitch property which is
> checked before deciding whether to install such flow or not?

I think that would be a reasonable solution.  I guess that command-line
options can be added to give ovs-testcontroller the features that you
want.  I'd be in favor of such support, if you want to provide a patch.


More information about the discuss mailing list