Or Gerlitz <[EMAIL PROTECTED]> wrote:
[...]
>As i don't see any buffering of the IGMP packets, i understand there's no
>"reply" of sending them during fail-over and this means that only when the
>router would do IGMP query on this node it will learn on the fail-over. Is
>it indeed what's going on? if i understand correct it would take some
>meaningful time for the fail-over to be externally visible in this respect.
As I recall, the intent is to keep switches up to date all the
time, so that there is no delay during a failover. I.e., at every IGMP
query, the switch is answered on all possible ports.
>Also assuming it does exactly what the comment says, another issue i see
>here is that in the case of not only the active_slave being UP, the code
>would TX the IGMP packets over > 1 slave, and hence multicast packets
>would be sent by the switch also to ports "connected to" non-active
>slaves, something which will hurt the system performance!?
I haven't studied the effects of having large amounts of
multicast traffic coming in under this situation.
However, I would suspect that the MAC filters found on
sufficiently modern network adapters would drop the incoming multicast
traffic on the backup slaves, as only the active slave in active-backup
mode has its multicast list set. That information is sent to a slave
when it becomes the active slave; see the call to bond_mc_swap() made by
bond_change_active_slave().
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
