[Bridge] Getting + maintaining a consistent MDB view in userspace?

[Bridge] Getting + maintaining a consistent MDB view in userspace?

[Linus Lüssing]

Hi,

Is there a recommended way to get and monitor the MDB state from
userspace, without potential synchronization races?

I can use "bridge monitor mdb" to get changes or "bridge mdb show"
to get the current state (as well as use the underlying netlink
calls from my own application without the "bridge" command).

But if I were first calling "bridge mdb show" and then "bridge
monitor mdb" then there is a brief moment where I might miss some
changes. Or if I were doing it the other way around then a change
might wrongly override a valid entry? Or the full dump might not
be as up to date as the change event I got before?

Ideally I'd be looking for a variant of "bridge monitor mdb" which
first dumps the whole, consistent mdb state and after that
provides updates in the correct order.

Regards, Linus

Re: [Bridge] Getting + maintaining a consistent MDB view in userspace?

[Stephen Hemminger]

On Tue, 8 Aug 2023 02:29:09 +0200
Linus Lüssing <linus.luessing@c0d3.blue> wrote:

> Hi,
> 
> Is there a recommended way to get and monitor the MDB state from
> userspace, without potential synchronization races?
> 
> I can use "bridge monitor mdb" to get changes or "bridge mdb show"
> to get the current state (as well as use the underlying netlink
> calls from my own application without the "bridge" command).
> 
> But if I were first calling "bridge mdb show" and then "bridge
> monitor mdb" then there is a brief moment where I might miss some
> changes. Or if I were doing it the other way around then a change
> might wrongly override a valid entry? Or the full dump might not
> be as up to date as the change event I got before?
> 
> Ideally I'd be looking for a variant of "bridge monitor mdb" which
> first dumps the whole, consistent mdb state and after that
> provides updates in the correct order.
> 
> Regards, Linus

Same issue as dumping routing table which routing daemons deal with.
Most applications end up with two netlink sockets, one for monitor
and one for dumping.

You really can't do it from the bridge utility, need to build your
own tools.

Re: [Bridge] Getting + maintaining a consistent MDB view in userspace?

[Linus Lüssing]

On Mon, Aug 07, 2023 at 06:20:51PM -0700, Stephen Hemminger wrote:
> Same issue as dumping routing table which routing daemons deal with.
> Most applications end up with two netlink sockets, one for monitor
> and one for dumping.
> 
> You really can't do it from the bridge utility, need to build your
> own tools.

Thanks for the reply, ok.

For the old MLDv1/IGMPv2 output when having
"multicast_mld_version" set to 1 the output of "bridge mdb show"
and "bridge monitor mdb" looks quite straightforward. And I can
piece something together with that (or its netlink messages underneath).
And I see symmetrical netlink events for additions and deletions.

When setting a bridge's "multicast_mld_version" to 2 it looks to me like
there is quite a bit of redundancy in both "bridge mdb show"
and "bridge monitor mdb" output. And addition and deletion notifications
don't look that symmetric to me then anymore. There doesn't
happen to exist some documentation about these (netlink specific)
additions that came with the IGMPv3/MLDv2 implementation, or does
it?

Also, are there tools people can recommend for Linux to test SSM
with various kinds of include/exclude settings?
The only tool I found for SSM so far is mcjoin:
https://github.com/troglobit/mcjoin
But it does not seem to support SSM in exclude mode yet.


The reason I'm interested in this is I'm currently experimenting
with creating proxied IGMP/MLD behaviour between bridge ports,
setup from a daemon in userspace. Which utilizes dummy network interfaces
and tc and is supposed to replicate multicast listeners.
Very early prototype: https://github.com/T-X/brmldproxy/tree/main

Re: [Bridge] Getting + maintaining a consistent MDB view in userspace?

[Linus Lüssing]

On Thu, Aug 10, 2023 at 12:56:50AM +0200, Linus Lüssing wrote:
> [...]
> When setting a bridge's "multicast_mld_version" to 2 it looks to me like
> there is quite a bit of redundancy in both "bridge mdb show"
> and "bridge monitor mdb" output. And addition and deletion notifications
> don't look that symmetric to me then anymore. There doesn't
> happen to exist some documentation about these (netlink specific)
> additions that came with the IGMPv3/MLDv2 implementation, or does
> it?

And just a few examples which confuse me a bit:

1) ASM, single listener:

$ ./mcjoin -d -i veth0 "[ff12::125]

bridge monitor mdb:

```
dev br0 port veth1 grp ff12::125 temp filter_mode include proto kernel
dev br0 port veth1 grp ff12::125 temp filter_mode exclude proto kernel
```

-> first line seems to be superfluous / no-op?
   Can I always ignore such an event with:
   "n->nlmsg_type == RTM_NEWMDB && mode == MCAST_INCLUDE &&
    !tb[MDBA_MDB_EATTR_SOURCE] && !tb[MDBA_MDB_EATTR_SRC_LIST]" ?

Leave only creates one event:

$ kill <mcjoin ...>

```
Deleted dev br0 port veth1 grp ff12::125 temp filter_mode include proto kernel
```

2) SSM, two listeners:

$ ./mcjoin -d -i veth0 "[fe80::130],[ff12::130]"

```
dev br0 port veth1 grp ff12::130 temp filter_mode include proto kernel
dev br0 port veth1 grp ff12::130 src fe80::130 temp filter_mode include proto kernel
dev br0 port veth1 grp ff12::130 temp filter_mode include source_list fe80::130/260.00 proto kernel
```

-> again first line superfluous / no-op?
   and second + third line identical?

Adding a second join:

$ ./mcjoin -d -i veth0 "[fe80::131],[ff12::130]"

```
dev br0 port veth1 grp ff12::130 src fe80::131 temp filter_mode include proto kernel
dev br0 port veth1 grp ff12::130 temp filter_mode include source_list fe80::131/260.00,fe80::130/247.86 proto kernel
```

-> so looks like the source_list line is actually always a (superfluous /
   redundant?) summary of all sources for this group+port?

And deleting here creates three events:

$ kill <mcjoin -d -i veth0 "[fe80::131],[ff12::130]">

```
Deleted dev br0 port veth1 grp ff12::130 src fe80::131 temp filter_mode include proto kernel
```

$ kill <mcjoin -d -i veth0 "[fe80::130],[ff12::130]">

```
Deleted dev br0 port veth1 grp ff12::130 src fe80::130 temp filter_mode include proto kernel
Deleted dev br0 port veth1 grp ff12::130 temp filter_mode include proto kernel
```

And here the last line seems to be superfluous / redundant?
And the behaviour seems to differ from 1) / ASM, where
I would always only get one event when leaving?


----------

So this currently confuses me a bit regarding which of these netlink
notifications I might be able to ignore safely and which not. And
how to interpret them, which ones are supposed to be a singular update
I would need to add and which ones are supposed to be summaries
that are supposed to potentially update/replace multiple entries.

Regards, Linus