On Mon, 29 Aug 2005, Al Boldi wrote:
All modes work fine when the bond is not part of the bridge.
Odd..
The message stops when one of the bonded devs like eth1 is downed.
Naturally if the cause is what I described: bonding without proper support from the switch, causing packets to loop back on the other interfaces in the bond.
Removing the IP from the bond makes no diff.
There should be no IP on any interface part of a bridge. Only the bridge device should have IP assigned. Any other configuration will produce somewhat odd results.
Also, what's the idea of this tight IP to devMAC relationship? Shouldn't the IP be on a different level of abstraction from the lower dev abstraction and then linked via some map?
No idea what "tight IP to devMAC relationship" you are talking about. The two are pretty separate from each other.
The MAC level addresses the packet at the Ethernet level. If the destination Ethernet address is the same as the MAC of the interface (or bridge device in case of bridgeing) or broadcast the packet is for this host and will be delivered to the local IP stack for further action. If the MAC is different then the packet is for someone else and discarded (or bridged to the other interfaces in the bridge in case of bridgeing).
The local IP stack will get somewhat upset if it receives IP packets with a source IP matching one of it's own interfaces, as this indicates something is wrong in the network either an IP conflict or packets being looped back to the sender host.
Regards Henrik - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
