On 10/09/2013 02:25 PM, Jesse Gross wrote:
On Wed, Oct 9, 2013 at 1:49 PM, Nithin Nayak Sujir <nsu...@broadcom.com> wrote:
On 10/08/2013 05:49 PM, Jesse Gross wrote:
On Tue, Oct 8, 2013 at 4:26 PM, Nithin Nayak Sujir <nsu...@broadcom.com>
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?
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
