On Wed, Oct 9, 2013 at 1:49 PM, Nithin Nayak Sujir <[email protected]> wrote: > > > On 10/08/2013 05:49 PM, Jesse Gross wrote: >> >> On Tue, Oct 8, 2013 at 4:26 PM, Nithin Nayak Sujir <[email protected]> >> wrote: >>> >>> >>>>> >>>>> To summarize, I'm looking for an openvswitch command which does the >>>>> same >>>>> thing as >>>>> >>>>> "ebtables -t broute -A BROUTING -p 0x8914 -j DROP" >>>>> >>>>> for the standard linux bridge. >>>> >>>> >>>> >>>> To get back to the heart of the matter, there is no exact equivalent >>>> to this in OVS. This command will return the packet to the stack on >>>> the original interface (i.e. eth0) whereas sending to LOCAL will >>>> output on the bridge interface (such as br0). I suspect that the >>>> problem is that your listener is bound to the Ethernet interface. >>>> >>> >>> Yes, that is correct, it is bound to the ethernet interface. Is there any >>> plan to support the ebtables equivalent or would you accept patches that >>> did >>> that? Or does this go against the design/usage of openvswitch? >> >> >> I think there is an argument for having such functionality at the >> lowest layers of OVS but I would want to be very careful about how it >> is modeled and exposed. Most people find ebtables fairly difficult to >> use so I don't think a direct port is the best idea. Essentially what > > > Agreed. > > >> we want is a mechanism to allow external modules to provide per-port >> functionality as if it were part of the switch itself since a switch >> that conditionally accepts packets is a fairly odd thing. >> > > Can you elaborate a little? What would the changes be to support this? When > you say external module do you mean an ethernet driver?
I would consider your FCoE daemon to be an external module that is acting like it is logically part of OVS. I don't know what the changes would be - that's what I mean, it would have to be carefully designed. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
