Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!rutgers!columbia!cunixc!alan
From: alan@cunixc.columbia.edu (Alan Crosswell)
Newsgroups: comp.dcom.lans
Subject: Re: DEC LAN Bridges
Message-ID: <1047@cunixc.columbia.edu>
Date: 19 Oct 88 21:36:31 GMT
References: <773@dogie.edu>
Reply-To: alan@cunixc.cc.columbia.edu (Alan Crosswell)
Organization: Columbia University
Lines: 36

This sounds like a similar problem we saw and I posted to this group
several months ago and received several replies on.  The problem
appears to be that a sick host sends a packet whose SOURCE address is
the ethernet broadcast address.  This of course violates the ethernet
spec. The lanbridge doesn't bother checking for this case and merrily
enters this source address into its forwarding database.  So now what
you have is a forwarding entry that says the broadcast address is on
one side of the bridge.  The result is that broadcasts go thru in one
direction but not the other, so ARP, etc.  work in one direction but
not the other.

If you have RBMS, you can confirm this by issuing a command to the bridge
along the lines of:

	SHOW FORW PHYS ADDR FF-FF-FF-FF-FF-FF

To clear the forwarding entry, issue:

	REMOVE FORW PHYS ADDR FF-FF-FF-FF-FF-FF

If you don't have RBMS, simply power-cycle the bridge until the next time
you get hosed.

Here's a VMS batch jub that I run hourly to keep our bridges squeaky clean:

$ SET VERIFY
$ PURGE/KEEP=10 RBMS_CLEANUP.LOG
$ RBMS
USE KNOWN BR
SHOW FORW PHYS ADDR FF-FF-FF-FF-FF-FF
REMOVE FORW PHYS ADDR FF-FF-FF-FF-FF-FF
$ SUBMIT/AFTER="+1:00:00"/RESTART RBMS_CLEANUP
$ EXIT

Pretty gross, Huh?

/a