[ovs-discuss] Ignore packets of a certain mac type

[Jesse Gross]

On Tue, Oct 15, 2013 at 8:15 AM, Nithin Nayak Sujir <nsujir at broadcom.com> wrote:
>
>
> On 10/09/2013 02:25 PM, Jesse Gross wrote:
>>
>> On Wed, Oct 9, 2013 at 1:49 PM, Nithin Nayak Sujir <nsujir at 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 <nsujir at 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?

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.