What is the difference between a bridge and a switch? I don't want to get into a discussion about layer 2 and layer 3 swutching but afaik a bridge is a two port layer 2 switch.
A bridge keeps the traffic that it forwards to a minimum. Which is the difference with a repeater.
------Origineel bericht------
Van: Bob Armstrong
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] DECnet et al
Verzonden: 17 juli 2011 20:24
A bridge (hw) maintains a list of mac addresses it sees at each port.
FWIW, that's a "switch" at least in the common usage of the word over
here.
Bob
Verzonden vanaf mijn draadloze BlackBerry -toestel
On 2011-07-17 20.22, hvlems at zonnet.nl wrote:
A bridge (hw) maintains a list of mac addresses it sees at each port. A bridge will never forward a packet with a destination address on that list.
The bridge ( program) learns which mac addresses live behibd what port and thus knows what traffic to forward and what not. Broadcst, multicast traffic is always forwarded.
The only difference between a DEBET and the program is that the program ignores all other protocols
This is essentially what a switch does as well.
I think in the old DEC nomenclature, a bridge only connected two segments, so it becomes a very binary "the address is either on this segment, or on the other side". A switch can, and should, be more clever, since it should either not forward the packet at all, if the destination is on the same port as the packet in on, or just forward it to the specific port where the destination exists, if it is on another port. Unknown destinations needs to be treated the same as multicast, in that it needs to be sent to all ports.
I might have called my program a switch as well, except for other reasons I thought a bridge was a better name for it. Also, in the beginning, it did not keep any destination cache around. Improvements along the way. :-)
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 11:10:11
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] DECnet et al
The term segment is used because each node that runs the
bridge program does filter packets that should stay local.
Ah, so the bridge program is not really a bridge (at least not in the way
I use the word). Usually I think of a bridging two networks as meaning to
copy all traffic from network A to network B and vice versa. If the box or
program does something smart about deciding which traffic should go where,
then it's a "router" (or at least a "switch").
How does the bridge program decide what DECnet messages to bridge and what
to drop?
Thanks,
Bob
On Sun, Jul 17, 2011 at 2:24 PM, Bob Armstrong <bob at jfcl.com> wrote:
A bridge (hw) maintains a list of mac addresses it sees at each port.
FWIW, that's a "switch" at least in the common usage of the word over
here.
Bob
Hello!
I agree! Now first things first. When did DECNET first appear? And
more importantly, based on what systems and using what means to
connect each system.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."
But HECnet as a whole is not connected to this segment...
I thought the majority of it was... There are a few people, like me, who
are using Multinet but only a few cases. I thought pretty much everything
was bridged.
[FWIW, Multinet tunnels a point-to-point DECnet link, essentially like a
DDCMP link, over UDP. For that you really need to have a router at either
end to pass traffic for other machines on either LAN.]
Bob
Johnny,
If you can make a DECnet router, (l3...) or make the Internet look like point-to-point
(ddcmp) links, it would work 'better'. As sending all areas as 'rip
vectors' every second is not'usefull'.
And I'm offline, as I only speak Multinet and Decnet in GRE... (and
takes for endpoints?)
-P
A bridge (hw) maintains a list of mac addresses it sees at each port. A bridge will never forward a packet with a destination address on that list.
The bridge ( program) learns which mac addresses live behibd what port and thus knows what traffic to forward and what not. Broadcst, multicast traffic is always forwarded.
The only difference between a DEBET and the program is that the program ignores all other protocols
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 11:10:11
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] DECnet et al
The term segment is used because each node that runs the
bridge program does filter packets that should stay local.
Ah, so the bridge program is not really a bridge (at least not in the way
I use the word). Usually I think of a bridging two networks as meaning to
copy all traffic from network A to network B and vice versa. If the box or
program does something smart about deciding which traffic should go where,
then it's a "router" (or at least a "switch").
How does the bridge program decide what DECnet messages to bridge and what
to drop?
Thanks,
Bob
On 2011-07-17 20.15, Bob Armstrong wrote:
But HECnet as a whole is not connected to this segment...
I thought the majority of it was... There are a few people, like me, who
are using Multinet but only a few cases. I thought pretty much everything
was bridged.
I don't have any exact numbers on the number of people connected one way or another. My gut feeling is that a majority are connected to the bridge, if we talk areas. But that does not mean that all the machines on the "other" side is sitting on the same bridge segment.
You could very well have a router with two ethernet interfaces, for example.
[FWIW, Multinet tunnels a point-to-point DECnet link, essentially like a
DDCMP link, over UDP. For that you really need to have a router at either
end to pass traffic for other machines on either LAN.]
Yep.
Johnny
On 2011-07-17 20.10, Bob Armstrong wrote:
The term segment is used because each node that runs the
bridge program does filter packets that should stay local.
Ah, so the bridge program is not really a bridge (at least not in the way
I use the word). Usually I think of a bridging two networks as meaning to
copy all traffic from network A to network B and vice versa. If the box or
program does something smart about deciding which traffic should go where,
then it's a "router" (or at least a "switch").
Hans gives the bridge program too much credit. :-)
How does the bridge program decide what DECnet messages to bridge and what
to drop?
It only have one small optimization, in the same vein as a switch. If it knows the destination (have seen traffic from it previously), it will only propagate traffic to that other end if it is directed traffic.
A router would be something very different, and way more clever. But a router would actually be a very nice thing to implement. If anyone feel like it, I'd be happy to help.
The difference between a switch and my bridge program is mostly in that the bridge program works using UDP as a carrier for remote endpoints, as well as interfacing to local ethernets. It can also do some traffic throttling, but unlike a switch, it does not do something like STP, nor do it do any kind of ethernet autonegotiation. It does not really play with ethernet on a low enough level for that.
Johnny
But HECnet as a whole is not connected to this segment...
I thought the majority of it was... There are a few people, like me, who
are using Multinet but only a few cases. I thought pretty much everything
was bridged.
[FWIW, Multinet tunnels a point-to-point DECnet link, essentially like a
DDCMP link, over UDP. For that you really need to have a router at either
end to pass traffic for other machines on either LAN.]
Bob
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
