Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!wucs1!wucfua!chris
From: chris@wucfua.wustl.edu (Chris Myers)
Newsgroups: comp.dcom.lans
Subject: Re: DEC LAN Bridges
Summary: All FF's broadcast address is blocked
Message-ID: <339@wucfua.wustl.edu>
Date: 19 Oct 88 12:58:06 GMT
References: <773@dogie.edu>
Reply-To: chris@wucfua.wustl.edu (Chris Myers)
Organization: Washington University (St. Louis)
Lines: 37

In article <773@dogie.edu> dorl@vms.macc.wisc.edu (Michael Dorl - MACC) writes:
>We have been having a rash of recent problems that would best
>be explained by the fact that DEC LAN-100 Bridges stop forwarding
>all 1-s broadcast traffic.  Problems include tcp/ip sites that
>do not see routed routing traffic and tcp/ip sites that can not
>initiate a session to a machine on the other side of a bridge.
>
>I'd be interested in hearing from anyone who has experienced
>similar problems or who has any insight into the problem.
>
>Michael Dorl (608) 262-0466

Washington University has experienced this problem in its network several times
in the past few months.  It seems largely attributable to one of two causes:

   1)  A LAN Bridge 100 with version 1 ROMs.  There is a bug that causes a
       PERMANENT MANAGEMENT entry to be placed in the forwarding database that
       blocks the FF-FF-FF-FF-FF-FF address whenever the bridge is initialized.
       Get the version 2.0 ROM field upgrade kits to fix the problem.

   2)  There are (apparently) some confused nodes on the network that will
       send a packet with a source address of FF-FF-FF-FF-FF-FF when they boot.
       The LAN Bridges learn this source address, of course, and proceed to
       block most of the broadcast traffic on the network.  For some unknown
       reason DEC decided that the all FF's address should not be expired from
       the bridging database, unlike all other entries.  The only way to fix
       this is to use the Remote Bridge Management Software (RBMS) from DEC
       and remove the forwarding entry for FF-FF-FF-FF-FF-FF.

We have decided that the best way to deal with the problem is to run a batch
job every 15 minutes or so and check a bridge to see if it has learned the all
FF's address, and if so it removes it on all working bridges.  The are better
better solutions (routers, smart bridges) that we are looking at seriously.

Chris Myers
Software Engineer
Washington University Office of the Network Coordinator