Thread (8 messages) 8 messages, 2 authors, 2021-01-28

Re: [PATCH net-next] bridge: Propagate NETDEV_NOTIFY_PEERS notifier

From: Hangbin Liu <hidden>
Date: 2021-01-28 03:28:49
Also in: bridge

On Wed, Jan 27, 2021 at 11:43:30AM +0200, Nikolay Aleksandrov wrote:
quoted
For IGMP, although you said they are different. In my understanding, when
bridge mac changed, we need to re-join multicast group, while a gratuitous
ARP is also needed. I couldn't find a reason why IGMP message is OK but GARP
is not.
I think that's needed more because of port changing rather than mac changing.
Switches need to be updated if the port has changed, all of that is already handled
correctly by the bond. And I also meant that mcast is handled very differently in
the bridge, usually you'd have snooping enabled.

The patch below isn't correct and will actually break some cases when bonding
flaps ports and propagates NETDEV_RESEND_IGMP with a bridge on top.
Hi Nikolay,

I'm little curious. bond/team device will resend IGMP as their MAC address changed.

- bond_resend_igmp_join_requests_delayed()
  - call_netdevice_notifiers(NETDEV_RESEND_IGMP, bond->dev);
- team_mcast_rejoin_work()
  - call_netdevice_notifiers(NETDEV_RESEND_IGMP, team->dev);

What's the purpose that bridge resend IGMP if it's mac address not changed?

I mean, when there is a bridge on top of bond/team, when bond/team flap ports,
bond/team will re-send IGMP and bridge just need to forward it. bridge doesn't
need to re-send the IGMP itself if it's MAC address not changed.

Thanks
Hangbin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help