Thanks for your answers. It is mess a bit, because modems I was talking about (841,841C) has broken and are now in service. We have another pair of Zyxel Prestige 782M SHDSL modems that are being used as temporary replacement. Funny thing is that the problem persist. Tonight I've made some tests with 782M. I've connected two computers in my office (win7 and linux) through this pair directly. I seccessfully tested ping both directions, then switched them so that each crossed the bridge and was unable to ping. tcpdump from linux showed: 1. while pinging from linux to win7: - Linux sends broadcast ARP-WHO-HAS win7-ip and no one replays - I was able to see win7's ARP-WHO-HAS some-other-ip after that linux probably learned it's MAC and started to send unicast ping requests, still no replay - I also saw some unicast packets from win7 crossed the bridge 2. while pinging from win7 to linux: - linux gets broadcast ARP-WHO-HAS linux-ip - linux replays unicast ARP-IS-AT - those two repeat, so win7 doesn't get replay Regarding this I can surely tell (this is all about 782M pair) that after box crossing the bridge MAC-port table is not updating (how it should be if it were switch's logic). Packets with srcMAC of crossed box CAN cross the bridge, but with dstMAC of crossed box CANNOT cross the bridge. В Срд, 30/06/2010 в 17:39 +0200, Pascal Hambourg пишет: > Pokotilenko Kostik (approximate romanization) wrote : > >>> We have two building with local networks connected by Zyxel Prestige 841 > >>> and 841C VDSL-modems. They work in transparent bridge mode. > >>> > >>> On one end 841 is connected directly to a switch. On other 841C > >>> connected to a linux router wich is also connected to a switch, and > >>> those interfaces bridged. > >> So is it a bridge or a router ? > > > > Modems 841C and 841 are configured in bridge mode. > > You already made that clear. I was asking about the Linux box. > > > Linux box runs some services and have 3 interfaces, 2 of them are > > bridged to br0 and one is left for separate local segment. So it is a > > router between br0 and eth2 and a bridge between eth0, eth1. > > Ok. > > >>> There is a problem, when a computer is being moved from one building to > >>> another it stops seeing other end of the bridge until modems are > >>> rebooted. > >> Can you elaborate "stops seeing" ? > >> Packet captures of ARP and IP traffic on both ends might provide more > >> information. > > > > Can't repeat tests right now, but I'm remembering that if I move the box > > across the bridge and trying to ping box at other side: either > > ARP-who-has can't cross the bridge or ARP-is-at (response) can't cross > > the bridge. > > > > I'll play more with this soon. > > Please do so. And make sure you capture and compare traffic at each port > of the Linux bridge (eth0 and eth1). > > > Can you confirm that if MAC (frame with source MAC) pops up on port > > different from the one it was seen previous time then the port for that > > MAC get updated? > > I can only confirm that a Linux bridge does this, because I tested it. I > cannot confirm about other bridging devices, although this is what they > should do. > > >> rebooting the modems and not the Linux box fixes the problem. So I doubt > >> that the Linux bridge causes the problem. > > > > It may happen that rebooting the modems brings port link down and the > > bridge may clear the MAC-port table on that port. This is similar to > > what Zyxel support told me. > > Note that you can achieve the same result by deactivating and > reactivating br0 or its ports, without touching the modems. > -- > 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 -- Покотиленко Костик <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
