On Tue, Oct 15, 2013 at 8:15 AM, Nithin Nayak Sujir <[email protected]> wrote: > > > On 10/09/2013 02:25 PM, Jesse Gross wrote: >> >> 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. >> > > Sorry, I don't quite get the full picture. So if I understand what you're > saying, instead of having for e.g. a new action "DELIVER" which would > deliver to the original interface, you want the fcoe daemon to plug into the > switch in a fashion similar to the openvswitch daemon. And then the daemon > would get the packets? > > If this is correct, it won't work for fcoe. Only the initialization phase > packets go to userspace. After the vlan interface is setup, the fcoe/scsi > traffic does not go to userspace. Won't we still need the DELIVER action?
All I was saying was that this would need to be designed carefully. I wasn't suggesting a specific design, other than that it should look like a logical composition in the end. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
