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