[ovs-dev] [layering 2/3] ofproto: Fix layer violation in in-band control.

Ben Pfaff blp at nicira.com
Fri Sep 30 16:25:00 UTC 2011


On Thu, Sep 29, 2011 at 06:55:23PM -0700, Jesse Gross wrote:
> On Thu, Sep 29, 2011 at 3:40 PM, Ben Pfaff <blp at nicira.com> wrote:
> > ofproto/in-band.[ch] is supposed to be a fairly high-level interface. ??It
> > has no business poking around ODP actions, and yet in_band_rule_check() did
> > just that. ??This commit fixes the problem by making the caller do the work
> > related to actions.
> 
> This still seems like a layer violation to me because
> in_band_rule_check() is making determinations based on what our kernel
> module is able to match on.  Isn't this logically a component of
> ofproto-dpif?

I agree that it is, at best, ugly.

Ideally, in-band control would be able to do this by setting up a
flow.  What if we abandoned the idea of looking into the L7 packet
contents and instead set up two flows:

	* One that matches UDP from port 67 to port 68 directed to the
          local port's MAC.  This should catch unicast DHCP replies,
          which is the ordinary case.

	* One that matches UDP from port 67 to port 68 directed to
          Ethernet broadcast.  This catches broadcast DHCP replies,
          which are odd cases like DHCP clients that set the
          "BROADCAST" bit in the request, DHCP servers that always
          broadcast DHCP replies (which is allowed by the RFCs), and
          some DHCP relay cases.

The only problem is that the latter is overbroad.  We could drop the
latter rule.  It probably wouldn't cause problems very often, but when
they did happen they'd be difficult to debug.



More information about the dev mailing list