Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!charon!ariel.unm.edu!dd
From: dd@ariel.unm.edu
Newsgroups: comp.dcom.lans
Subject: Re: lanbridge retardation
Message-ID: <4673@charon.unm.edu>
Date: 20 Mar 89 14:55:29 GMT
References: <1151@jhunix.HCF.JHU.EDU>
Sender: root@charon.unm.edu
Reply-To: dd@ariel.unm.edu.UUCP ()
Organization: University of New Mexico, Albuquerque, NM
Lines: 51

In article <1151@jhunix.HCF.JHU.EDU> gdl@jhunix.HCF.JHU.EDU (Glen Lovell) writes:
>Looking for help... Here at Hopkins we have 26 lanbridge 100's.  Lately
>we have seen occurences where all of them acquire a bogus forwarding
>entry for the multicast address FF-FF-FF-FF-FF-FF to an invalid destination.
>
>Doing a remove known bridges address FF-FF-FF-FF-FF-FF with RBMS clears 
>the problem for a day or two, sometimes longer.  I seem to recall some 
>discussion of this in this newsgroup eons ago.  I have looked for an
>offensive packet without success and my gut-level feeling is that is
>a Lanbridge problem (possibly eco or firmware).  Anyone have anything
>of help?

We have had this problem in spades also.  There are two paths to take in
solving the problem:

    [1]	Find the thing generating the bogus packet.  I have found
	that IBM PC/RTs running 4.3 BSD (not AIX) generate this
	packet.  I have heard (no promises, and I haven't seen it)
	that Kinetics gateways can generate this packet also.  You can
	localize the offender by noticing in which direction the
	LAN-100 is biased (assuming you have kept track of which
	interfaces are attached to which network).

    [2]	Upgrade or downgrade your LAN-100s.  Rev. level D LAN-100s do
	not suffer from this problem.  Rev. level E bridges do.  DEC
	says rev. level F (which is currently being shipped) does not,
	but I am not certain of this yet - after the bogus packet flows
	through our network, the rev. F bridge is in a strange state,
	and may or may not be working.  I usually reset it anyway.

Other helpful (probably obvious) hints:  If your network is organized in a
hierarchical fashion (ours is), then at those key points where the entire
network could be brought to it's knees by this phenomenon, make sure you
have a rev. D LAN-100.  Write a COM script to do, on an automated basis,
what you do manually when you suspect a problem, and run the script every
few minutes.  The script can contain recording actions, and/or corrective
actions.  If you are interested in locating the offender make sure you record
all of the pertinent data ("sho kno bri for phy add ff-ff-ff-ff-ff-ff").

Good luck with this, and if there is anything I can do to be of further
assistance, please let me know.

Don Doerner

UNM-CIRT
2701 Campus Blvd. NE
Albuquerque, NM, 87131

(505) 277-8036

dd@ariel.unm.edu