On Fri, Sep 30, 2011 at 9:34 AM, Ben Pfaff <[email protected]> wrote: > On Fri, Sep 30, 2011 at 09:25:00AM -0700, Ben Pfaff wrote: >> 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. > > Another idea: move the in-band rules to an extra table (as we've > discussed before) and then in the latter case output to OFPP_LOCAL and > resubmit to table 0. Then you could potentially get duplicates sent > to the local port but that's probably not a big deal.
I agree that setting up flows is the cleanest way to do this and putting the in-band rules in a separate table seems like a good way to go in general. I'd be in favor of the second solution since its corner case is much more benign than not having the rule at all. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
