IPv6 multicast and snooping on bridges

IPv6 multicast and snooping on bridges

[caskd]

[-- Attachment #1.1: Type: text/plain, Size: 1266 bytes --]

Hello everyone,

i've noticed that the bridges and IPv6 multicast snooping doesn't seem to play out together well. When a address gets assigned to the bridge it gets entered into it's bridge multicast database but it vanishes after a while. I wasn't able to pinpoint the cause of the vanish, it's not the GC.

How to reproduce:

- Create a bridge
- Activate multicast snooping
- Assign a address to the bridge
- Watch multicast database (especially the ones with the device and port both being the bridge)
- Wait 5-10 minutes (i wasn't able to pinpoint a exact interval but it usually happens in this timeframe)

During the waiting timeframe the interface's own host groups should disappear from the bridge's database, resulting in the bridge not accepting any more packets for it's own group.

Is this intended behaviour? It would seem like the interface can be used as a "switch-port" itself instead of configuring a dummy interface to be a part of the bridge, as it behaves correctly except for this one case. This isn't a problem in the IPv4 world but creates routing problems in the IPv6 world. If it is, could this be documented somewhere?

Thanks in advance.

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

Re: IPv6 multicast and snooping on bridges

[caskd]

Hello everyone,

> How to reproduce:
> 
> - Create a bridge
> - Activate multicast snooping
> - Assign a address to the bridge
> - Watch multicast database (especially the ones with the device and port both being the bridge)
> - Wait 5-10 minutes (i wasn't able to pinpoint a exact interval but it usually happens in this timeframe)
> 
> During the waiting timeframe the interface's own host groups should disappear from the bridge's database, resulting in the bridge not accepting any more packets for it's own group.
> 
> Is this intended behaviour? It would seem like the interface can be used as a "switch-port" itself instead of configuring a dummy interface to be a part of the bridge, as it behaves correctly except for this one case. This isn't a problem in the IPv4 world but creates routing problems in the IPv6 world. If it is, could this be documented somewhere?

After some futher investigation, i noticed i can only replicate this when there is a VLAN interface as part of the bridge that is up. As soon as the interface goes up, it takes a bit and then the entries get deleted. I can replicate this on 6.4 just fine while i cannot replicate it in 5.19, so it seems to be something that used to work and broke during this period. I will build older kernels and try to pinpoint the breaking change(s).

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/

Re: IPv6 multicast and snooping on bridges

[caskd]

[-- Attachment #1.1: Type: text/plain, Size: 1984 bytes --]

caskd <caskd@redxen.eu> wrote:
> Hello everyone,
> 
> > How to reproduce:
> > 
> > - Create a bridge
> > - Activate multicast snooping
> > - Assign a address to the bridge
> > - Watch multicast database (especially the ones with the device and port both being the bridge)
> > - Wait 5-10 minutes (i wasn't able to pinpoint a exact interval but it usually happens in this timeframe)
> > 
> > During the waiting timeframe the interface's own host groups should disappear from the bridge's database, resulting in the bridge not accepting any more packets for it's own group.
> > 
> > Is this intended behaviour? It would seem like the interface can be used as a "switch-port" itself instead of configuring a dummy interface to be a part of the bridge, as it behaves correctly except for this one case. This isn't a problem in the IPv4 world but creates routing problems in the IPv6 world. If it is, could this be documented somewhere?
> 
> After some futher investigation, i noticed i can only replicate this when there is a VLAN interface as part of the bridge that is up. As soon as the interface goes up, it takes a bit and then the entries get deleted. I can replicate this on 6.4 just fine while i cannot replicate it in 5.19, so it seems to be something that used to work and broke during this period. I will build older kernels and try to pinpoint the breaking change(s).
>
Nevermind, found the trigger being the temporary entry lifetime and it also happens without a VLAN. So it seems to be a feature? Why would own multicast groups expire on a bridge that does snooping?

How to reproduce:

ip link add dummy-slave type dummy
ip link add bridge-dummy type bridge mcast_snooping 1
ip link set dev dummy-slave master bridge-dummy up
ip link set dev bridge-dummy up

# Watch as the timer goes down and own entries disappear
watch -n0.2 -d -x bridge -d -s mdb

-- 
Alex D.
RedXen System & Infrastructure Administration
https://redxen.eu/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 858 bytes --]