[RFC] bridge: MAC learning uevents

[RFC] bridge: MAC learning uevents

[D. Herrendoerfer]

Hello,

I'd like to start a discussion if it makes sense to add an optional feature

to the bridge MAC address learning code to generate kernel uevents for

every learned (added) and removed MAC address.

The (my) rationale behind this is, that I work with multiport SRIOV and 
MRIOV

network cards that cannot put each and every virtual port into promiscuous

mode, but they have the capability to register a large number of MAC 
addresses

to each interface.

These systems are host to a large number of kvm guests, that require 
network access.

To get around the problem I added two uevents to linuxbridge that would 
announce every

learned address to udev, and udev would register or remove  the MAC 
address to the

uplink device of the bridge.

The script may also add the required addresses for multicast and IPv6 if 
required.

The need for promiscuous mode on the card was gone. All I needed to do 
was to attach

the guests through a linuxbridge instead of directly to the card.


I may be missing something here - I'm pretty sure there I am, but is 
there any conceptual

reason why this should not be done this way ?


I'm porting my patch (for 3.10.0) to head, and will make it available, I 
just want some

valuable feedback as early as possible.


Thanks, D.Herrendoerfer

Re: [RFC] bridge: MAC learning uevents

[Andi Kleen]

"D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> writes:
>
> I may be missing something here - I'm pretty sure there I am, but is
> there any conceptual
>
> reason why this should not be done this way ?

What happens if someone floods the network with random mac addresses?
Sounds like an easy way to do a DoS attack against your host?

-Andi

Re: [RFC] bridge: MAC learning uevents

[D. Herrendoerfer]

There is a reference to the virtual port in the event so you can actually
keep only one record MAC per port, I suppose the the impact would be
the same if you do this to a macvtap device on top of an ethernet device.
But granted - you could really load down the host.

Dirk

On 08 Sep 2016, at 17:15, Andi Kleen <andi@firstfloor.org> wrote:

> "D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> writes:
>> 
>> I may be missing something here - I'm pretty sure there I am, but is
>> there any conceptual
>> 
>> reason why this should not be done this way ?
> 
> What happens if someone floods the network with random mac addresses?
> Sounds like an easy way to do a DoS attack against your host?
> 
> -Andi

Re: [RFC] bridge: MAC learning uevents

[Stephen Hemminger]

On Thu, 8 Sep 2016 15:06:16 +0200
"D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> wrote:

> Hello,
> 
> I'd like to start a discussion if it makes sense to add an optional feature
> 
> to the bridge MAC address learning code to generate kernel uevents for
> 
> every learned (added) and removed MAC address.
> 
> The (my) rationale behind this is, that I work with multiport SRIOV and 
> MRIOV
> 
> network cards that cannot put each and every virtual port into promiscuous
> 
> mode, but they have the capability to register a large number of MAC 
> addresses
> 
> to each interface.
> 
> These systems are host to a large number of kvm guests, that require 
> network access.
> 
> To get around the problem I added two uevents to linuxbridge that would 
> announce every
> 
> learned address to udev, and udev would register or remove  the MAC 
> address to the
> 
> uplink device of the bridge.
> 
> The script may also add the required addresses for multicast and IPv6 if 
> required.
> 
> The need for promiscuous mode on the card was gone. All I needed to do 
> was to attach
> 
> the guests through a linuxbridge instead of directly to the card.
> 
> 
> I may be missing something here - I'm pretty sure there I am, but is 
> there any conceptual
> 
> reason why this should not be done this way ?
> 
> 
> I'm porting my patch (for 3.10.0) to head, and will make it available, I 
> just want some
> 
> valuable feedback as early as possible.
> 
> 
> Thanks, D.Herrendoerfer

This should be possible by listening for netlink events.
No need for udev interaction.

Re: [RFC] bridge: MAC learning uevents

[D. Herrendoerfer]

On 08 Sep 2016, at 17:39, Stephen Hemminger <stephen@networkplumber.org> wrote:

> On Thu, 8 Sep 2016 15:06:16 +0200
> "D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> wrote:
> 
>> Hello,
>> 
>> I'd like to start a discussion if it makes sense to add an optional feature
>> 
>> to the bridge MAC address learning code to generate kernel uevents for

[SNIP]

>> 
>> I'm porting my patch (for 3.10.0) to head, and will make it available, I 
>> just want some
>> 
>> valuable feedback as early as possible.
>> 
>> 
>> Thanks, D.Herrendoerfer
> 
> This should be possible by listening for netlink events.
> No need for udev interaction.

No, there are none, not for changes to the bridge forwarding table, also this would 
require a tool to continuously listen for changes.

Dirk

Re: [RFC] bridge: MAC learning uevents

[Florian Fainelli]

On 09/08/2016 10:19 AM, D. Herrendoerfer wrote:
> 
> On 08 Sep 2016, at 17:39, Stephen Hemminger <stephen@networkplumber.org> wrote:
> 
>> On Thu, 8 Sep 2016 15:06:16 +0200
>> "D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> wrote:
>>
>>> Hello,
>>>
>>> I'd like to start a discussion if it makes sense to add an optional feature
>>>
>>> to the bridge MAC address learning code to generate kernel uevents for
> 
> [SNIP]
> 
>>>
>>> I'm porting my patch (for 3.10.0) to head, and will make it available, I 
>>> just want some
>>>
>>> valuable feedback as early as possible.
>>>
>>>
>>> Thanks, D.Herrendoerfer
>>
>> This should be possible by listening for netlink events.
>> No need for udev interaction.
> 
> No, there are none, not for changes to the bridge forwarding table, also this would 
> require a tool to continuously listen for changes.

Wat do you expect uevent to solve here that netlink + a monitoring
program can't?

There is quite a bit of code in net/bridge/br_fdb.c just to deal with
notifying learned/added MAC addresses, is not that where you should
start adding what you are after (if that is not supported as of latest
mainline)?
-- 
Florian

Re: [RFC] bridge: MAC learning uevents

[Stephen Hemminger]

On Thu, 8 Sep 2016 11:30:08 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:

> On 09/08/2016 10:19 AM, D. Herrendoerfer wrote:
> > 
> > On 08 Sep 2016, at 17:39, Stephen Hemminger <stephen@networkplumber.org> wrote:
> >   
> >> On Thu, 8 Sep 2016 15:06:16 +0200
> >> "D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> wrote:
> >>  
> >>> Hello,
> >>>
> >>> I'd like to start a discussion if it makes sense to add an optional feature
> >>>
> >>> to the bridge MAC address learning code to generate kernel uevents for  
> > 
> > [SNIP]
> >   
> >>>
> >>> I'm porting my patch (for 3.10.0) to head, and will make it available, I 
> >>> just want some
> >>>
> >>> valuable feedback as early as possible.
> >>>
> >>>
> >>> Thanks, D.Herrendoerfer  
> >>
> >> This should be possible by listening for netlink events.
> >> No need for udev interaction.  
> > 
> > No, there are none, not for changes to the bridge forwarding table, also this would 
> > require a tool to continuously listen for changes.  
> 
> Wat do you expect uevent to solve here that netlink + a monitoring
> program can't?
> 
> There is quite a bit of code in net/bridge/br_fdb.c just to deal with
> notifying learned/added MAC addresses, is not that where you should
> start adding what you are after (if that is not supported as of latest
> mainline)?

just like neighbor table modifications, it should be possible to listen for
events with netlink. Doing it through uevent is the wrong model.

Re: [RFC] bridge: MAC learning uevents

[D. Herrendoerfer]

> On Thu, 8 Sep 2016 11:30:08 -0700
> Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> On 09/08/2016 10:19 AM, D. Herrendoerfer wrote:
>>> 
>>> On 08 Sep 2016, at 17:39, Stephen Hemminger <stephen@networkplumber.org> wrote:
>>> 
>>>> On Thu, 8 Sep 2016 15:06:16 +0200
>>>> "D. Herrendoerfer" <d.herrendoerfer@herrendoerfer.name> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> I'd like to start a discussion if it makes sense to add an optional feature
>>>>> 
>>>>> to the bridge MAC address learning code to generate kernel uevents for  
>>> 
>>> [SNIP]
>>> 
>>>>> 
>>>>> I'm porting my patch (for 3.10.0) to head, and will make it available, I 
>>>>> just want some
>>>>> 
>>>>> valuable feedback as early as possible.
>>>>> 
>>>>> 
>>>>> Thanks, D.Herrendoerfer  
>>>> 
>>>> This should be possible by listening for netlink events.
>>>> No need for udev interaction.  
>>> 
>>> No, there are none, not for changes to the bridge forwarding table, also this would 
>>> require a tool to continuously listen for changes.  
>> 
>> Wat do you expect uevent to solve here that netlink + a monitoring
>> program can't?
>> 
>> There is quite a bit of code in net/bridge/br_fdb.c just to deal with
>> notifying learned/added MAC addresses, is not that where you should
>> start adding what you are after (if that is not supported as of latest
>> mainline)?
> 
> just like neighbor table modifications, it should be possible to listen for
> events with netlink. Doing it through uevent is the wrong model.

I agree partially - but consider:
we plug hardware - we get an event
we remove hardware - we get an event
we add a virtual interface - we get an event
we add a bridge - event
we add an interface to that bridge - event 
a kvm guest starts using the interface on that bridge - we need to monitor netlink, poll brforward, capture traffic

It seems inconsistent, bridge is already emitting events.

Re: [RFC] bridge: MAC learning uevents

[Florian Fainelli]

On 09/09/2016 01:51 AM, D. Herrendoerfer wrote:
>> just like neighbor table modifications, it should be possible to listen for
>> events with netlink. Doing it through uevent is the wrong model.
> 
> I agree partially - but consider:
> we plug hardware - we get an event
> we remove hardware - we get an event
> we add a virtual interface - we get an event
> we add a bridge - event
> we add an interface to that bridge - event 
> a kvm guest starts using the interface on that bridge - we need to monitor netlink, poll brforward, capture traffic

Yes, because now there is network activity going on, so why not ask the
networking stack to get these events?

> 
> It seems inconsistent, bridge is already emitting events.

It does not seem particularly inconsistent, all networking events are
already emitted using rt netlink, why should bridge be different here?
(Yes, uevent is netlink too, just a special family).

-- 
Florian