gdl@jhunix.HCF.JHU.EDU (Glen Lovell) (03/16/89)
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? G. Lovell Network engr. ecf_hgdl@jhunix.uucp ECF_HGDL@JHUVMS.BITNET gdl@hcf06.hcf.jhu.edu thanx.
cyrus@pprg.unm.edu (Tait Cyrus) (03/17/89)
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? > >G. Lovell Network engr. Causes: 1) Do you have any IBM PCs running UNIX 4.3 (not AIX)? We had one running 4.3, and EVERYTIME it booted, whether from a shutdown, a power off, or whatever, it sent out a garbage packet. Most of the time, fortunately, the garbage in the source address was not all F's, though on occasion there WERE all F's and our out of Rev Lanbridges died. Other people I have talked to have said they have seen their Lanbridges die without the presence of IBM PCs, so I am guessing other machines are doing this as well. 2) We have had problems with Rev E & F's. The #'s off the 2 PROMS that we saw in "BAD" bridges are: REV F: LM8916 332 E5 Dec 88 LM8916 333 E5 Dec 88 REV E-08: LM8750 293 E5 Dec 87 SP8807 294 E5 Dec 87 The REV F's we got are early in the REV F series. Later REV F's might be fixed. All REV E's we saw were bad. We assume that Proms with #'s from 293->333 are going to be bad. Hope this somewhat answers your questions. --- W. Tait Cyrus (505) 277-0806 e-mail: cyrus@pprg.unm.edu University of New Mexico Dept of ECE - Parallel Processing Research Group Albuquerque, New Mexico 87131
dd@ariel.unm.edu (03/20/89)
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