On 2011-07-17 20.02, hvlems at zonnet.nl wrote: The term segment is used because each node that runs the bridge program does filter packets that should stay local. As such the program behaves as if it were a DEBET-RD (remote LANbridge 100). Wth one exception: the bridge program only touches lat and decnet. The bridge program is in general a very stupid program that only connects all various points together so that they behave like a single larger ethernet cable. In order to improve efficiency, it does filtering so that only relevant protocols are sent. It also keeps a MAC address cache around, so that for directed traffic to known destinations are not replicated to all segments, but only to the segment where the actual destination is. Pretty much the same way a ethernet switch works. For broadcast packets, and unknown destinations, the packet is replicated to all destinations. Johnny Verzonden vanaf mijn draadloze BlackBerry -toestel -----Original Message----- From: "Bob Armstrong"<bob at jfcl.com> Sender: owner-hecnet at Update.UU.SE Date: Sun, 17 Jul 2011 10:55:12 To:<hecnet at Update.UU.SE> Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] DECnet et al No. By the endnode itself. It have no idea where to send it. For ethernet, DECnet supposedly already knows the MAC address where to send every packet. Where would it send a packet that isn't to the local ethernet segment? All the end node needs to know to send an Ethernet frame is a MAC for the destination, and if it knows the DECnet node number then it knows the MAC by definition. Anything beyond that is not its problem. That's what the bridge program does, right? Moves those DECnet Ethernet frames, via TCP/IP (or UDP - I forget which you used) over Internet to another LAN ? BTW, what do you mean by Ethernet "segment" in the context of the bridge program? Aren't bridged "segments" by definition the same segment (at least as far as DECnet messages go)? Or is the bridge itself doing something smart with DECnet traffic? Bob