[comp.dcom.lans] DEC LAN Bridge's learning the broadcast address

mitton@nac.dec.com (Dave Mitton) (11/01/88)

	There has been recent discussions about the consequences and
possible causes of DEC LAN Bridges seeing packets with a source address
of all FF's (ie: Broadcast).  I asked around and determined the following:

	This is a known bug in the V2.0 DEBET microcode.  It has been
fixed in the V2.1 microcode ROMs.  Currently, Field Service has not completed
an FCO kit, but customers can request an upgrade (free if under service
contract).  If your local FS does not know of the problem, request that
it be escalated to the Area FS office or the Colorado Springs Support Center.

	This problem was found previously and fixed in the V1.0 ROMs, but
managed to become un-fixed in V2.0.  The V2.x microcode contains other fixes
and improvements (including LAN Traffic Monitor support) so it is worthwhile
to upgrade.  The version number can be observed with an RBMS command;
READ BRIDGE CHARACTERISTICS (so I was told).

	Dave Mitton.

jmg@cernvax.UUCP (jmg) (11/03/88)

In article <8810312247.AA17706@decwrl.dec.com> mitton@nac.dec.com (Dave Mitton) writes:
>	This is a known bug in the V2.0 DEBET microcode.  It has been
>fixed in the V2.1 microcode ROMs.  Currently, Field Service has not completed
>an FCO kit, but customers can request an upgrade (free if under service
>contract).  If your local FS does not know of the problem, request that
>it be escalated to the Area FS office or the Colorado Springs Support Center.
>
>	This problem was found previously and fixed in the V1.0 ROMs, but
>managed to become un-fixed in V2.0.  The V2.x microcode contains other fixes
>and improvements (including LAN Traffic Monitor support) so it is worthwhile
>to upgrade.  The version number can be observed with an RBMS command;
>READ BRIDGE CHARACTERISTICS (so I was told).

This is the first time that I have seen any DEC admission of this fault
(sorry, feature) in LAN Bridges. We discovered it ourselves long ago
(months), after which we learned that DEC knew about it. How many hours
have been wasted by DEC customers finding this problem themselves I do not
care to think!

Perhaps Mr Mitton would care to comment on the other changes in the V2.1
ROMs which fix problems in ALL previous versions. They concern use of
RBMS to constrain operation of the minimal spanning tree algorith by
setting line/bridge costs. Anyone who has tried this in configurations
involving redundant paths (for backup) will know what I mean.

We have yet another LAN Bridge problem, but I will not confuse the situation
by putting it into this posting.
-- 
 _ _  o |             __                    |    jmg@cernvax.uucp
| | |   |     _      /  \  _   __  _   __  _|    jmg@cernvax.bitnet
| | | | |_)  /_)     |  __/_) | (___\ | (_/ |  J. M. Gerard, Div. DD, CERN,
| | |_|_| \_/\___    \__/ \___|   (_|_|   \_|_ 1211 Geneva 23, Switzerland

goeran@ae.chalmers.se (Goran Bengtson) (11/04/88)

In article <8810312247.AA17706@decwrl.dec.com>, mitton@nac.dec.com
  (Dave Mitton) writes:

> 	This problem was found previously and fixed in the V1.0 ROMs, but
> managed to become un-fixed in V2.0.  The V2.x microcode contains other fixes
> and improvements (including LAN Traffic Monitor support) so it is worthwhile
> to upgrade.  The version number can be observed with an RBMS command;
> READ BRIDGE CHARACTERISTICS (so I was told).

We also got the information (from DEC) that the problem was fixed in
V1.0 so we "downgraded" some V2.0 bridges.  That didn't help us.  The
problem IS present in both V1.0 and V2.0 (sorry DEC). 

Let us hope that V2.1 really fix it...
-- 
Goran Bengtson				Email:	goeran@ae.chalmers.se
Dept. of Applied Electronics
Chalmers Univ. of Technology		Phone:  +46 31 721825	(int)
S-412 96 Gothenburg				031 721825	(nat)
Sweden