В Вто, 29/06/2010 в 09:45 -0500, Grant Taylor пишет: > On 06/29/10 07:36, Pascal Hambourg wrote: > > The Linux bridge maintains a MAC-port table based on the source MAC > > address in received frames. As expected, if a MAC address was > > associated to a given port and a frame from that MAC address is > > received on a different port, then the table is updated accordingly. > > Besides, rebooting the modems and not the Linux box fixes the > > problem. So I doubt that the Linux bridge causes the problem. > > I mostly agree. > > The only thing that I would wonder about is is it possible that Linux is > seeing the link go down on the physical NIC that is connected to the > bridge, thus taking the logical port in the bridge down there by causing > it's learned MAC addresses associated with that port to be lost. > > This could easily be tested by putting a hub (or similar) between the > Linux box and the Zyxel bridge. That way when the bridge is rebooted, > the Linux box does not see the link go down. If the problem still > corrects its self, you have completely removed the Linux box from the > tests, there by strongly pointing at the Zyxel bridge. Worth trying. > > Of course the update process requires that the moved box sends > > traffic first. If it just sits there waiting then MAC-port tables > > won't be updated, until the entry eventually expires. > > Agreed. > > Pining or broadcasting looking to see what devices are on the far end > should accomplish the same thing. > > > Then may I ask what is the purpose of this box ? > > Remember that EBTables modifies how in kernel bridging behaves. Thus > the in kernel bridging will still behave like a normal bridge, even if > EBTables rules are not used. (In fact it is possible to have bridging > support in the kernel with out EBTables.) > > Bridges will still learn (and forget / expire) where MAC addresses are. > So even if there were not EBTables rules, the bridge its self will > learn what hosts are on what side of the bridge there by intelligently > forwarding (or not) frames across the link that don't need to be. > > I would have been tempted to put a bridge on both sides, not just the > one. Because as it is, broadcasts for the end with out the network are > still propagated across the link. This is to be done. But there is no issue with this until now. -- Покотиленко Костик <casper@xxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
