u3ky@vax5.CIT.CORNELL.EDU (02/03/89)
Our building ethernet is connected to a backbone ethernet via a DEC LanBridge. We have lately been experiencing a growing number of cases where a machine on our side of the bridge cannot telnet to some machines on the other side - the connection times out. I have yet to find a pattern to these failures. Could this be some sort of LanBridge misbehavior? Steven Gaarder sparks@oak.cadif.cornell.edu
karn@jupiter..bellcore.com (Phil R. Karn) (02/03/89)
Assuming that the hosts, interfaces, software and cables are all in good shape, yes, it's possible for the LAN Bridge to be at fault. In particular, the existing Lan Bridge firmware has a nasty bug that can cause it to "learn" the broadcast address if someone erroneously uses it in the source field of a packet. (I've seen this happen on a PC when an improperly seated board worked well enough to generate packets, but the address PROM read out as all 1's). When a bridge learns the broadcast address, it will refuse to pass broadcasts. This breaks ARP. We had this problem occasionally on our (rather large) bridged network until DEC finally sent us a new batch of ROMs that fixed the problem. By the way, my "locate" program began life one day when I was desperately trying to locate the $#@!! station using the broadcast address as its source address... Phil
eric@pprg.unm.edu (Eric Engquist [CoE]) (02/04/89)
Yes we at UNM fought the problem for a year prior to narrowing down the problem. We noticed that IBM RT running AOS 4.3 caused the "death packet" at boot time. IBM now has a workaround to fix the problem. Another fix is to back the rev level of the lanbridge to rev "D". -Eric
frank@ut-emx.UUCP (Frank Abernathy) (02/06/89)
In article <13818@bellcore.bellcore.com>, karn@jupiter..bellcore.com (Phil R. Karn) writes: > Some stuff deleted. > In particular, the existing Lan Bridge firmware has a nasty bug that can > cause it to "learn" the broadcast address if someone erroneously uses it > in the source field of a packet. (I've seen this happen on a PC when > an improperly seated board worked well enough to generate packets, but > the address PROM read out as all 1's). The ROMs at location E131 and E132 should be part numbers 332E5 and 333E5. Those sets seem to fix the 'Learn Broadcast Address' problem. Does not appear to cause other problems, yet... |^) Talk to your local DEC Field Service folks. There is not an offical FCO yet, as far as I know.. > > Phil
davew@gvgpsa.GVG.TEK.COM (David C. White) (02/10/89)
In article <13818@bellcore.bellcore.com> karn@thumper.bellcore.com (Phil R. Karn) writes: > >When a bridge learns the broadcast address, it will refuse to pass >broadcasts. This breaks ARP. We had this problem occasionally on our >(rather large) bridged network until DEC finally sent us a new batch of ROMs >that fixed the problem. Right. We had the same problem. Lean on your DEC service people to replace the ROMs with the new version and the problem will go away. This was hashed over fairly thoroughly a while back in this group and at that time the ROMs were not released but you could get them if you applied some real pressure. They should be readily available now. If you want to really hose the bridges, ping to your broadcast address. If you don't have the new ROMS this will lock out systems on the other side of the bridge from reaching you. The only way to fix the problem is to initialize the bridge if you have access to RBMS or power cycle the bridge. -- Dave White Grass Valley Group, Inc. PHONE: +1 916.478.3052 P.O. Box 1114 Grass Valley, CA 95945 davew@gvgpsa.gvg.tek.com