Date: Tue, 21 Jun 2005 09:57:11 +0200 From: "p.r. faasse" <faasse@nlr.nl> To: freebsd-net@freebsd.org Subject: Re: FreeBSD 5.4 802.1q and linux stalls Message-ID: <200506210957.11858.faasse@nlr.nl> In-Reply-To: <344de2870506170641695a9385@mail.gmail.com> References: <344de287050617043219810b3@mail.gmail.com> <344de28705061706121fcf5040@mail.gmail.com> <344de2870506170641695a9385@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > On Fri, Jun 17, 2005 at 12:32:37PM +0100, Meno Abels wrote: > > > M> i have here a very strange problem which is in real a linux problem > > > M> but it is triggered by freebsd. I run a lan on which are linux 2.6.8(debian) and > > > M> freebsd 5.4 systems are connected to a unmanaged gigabit switch. All systems > > > M> uses this gigabit adapter: > > > M> Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet > > > M> Everything works fine until i do on one freebsd box the following: > > > M> ifconfig vlan0 172.20.21.1 netmask 255.255.255.0 vlan 2 vlandev re0 > > > M> i just do this, there is nowhere any configuration for 802.1q on any other > > > M> machine on this lan. > > > M> What is happen now the freebsd continues to run without any problem, but > > > M> all linuxs are stopping to understand any arp responses from a freebsd > > > M> nor an other linux. > > > M> So they stop to work over the time on this lan anymore. If I do > > > M> "ifconfig vlan0 unplumb" > > > M> it takes up to 10 minutes and the linux's are return to the working > > > M> status as before > > > M> the ifconfig vlan0... > > > M> I didn't not have any clue which network packet could cause these behavior in > > > M> a linux but there has to be one. Does anybody as any idea? I can only speak about a limilar problem i once saw on a completely different set-up (A load of WinXP machines..): We did UDP broadcast at a fixed rate (20 Hz), with > 1 MTU packet size data. One thing that can cause horrible disruption is a switch that 'cuts' these broadcast/multicast packets at a fragment boundary: each Lan card/the TCP stack will receive 'half' UDP packets, buffer them in the hope that the 'rest' of th UDP packet will arrive 'any moment now' and -in the long run- choke on them. We saw this with a 3Com Gigabit switch. After consulting 3Com we got the response that this was a 'feature' of their switch and 'dumped' the switch. The 'delayed' re-activation of the Lan's is something we also saw in this situation.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506210957.11858.faasse>