That was a tongue in cheek quiz question Bob :-)
------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:34
What is the difference between a bridge and a switch?
Ok, I won't debate nomenclature. At least now I think we're all talking
about the same thing :-)
Bob
Verzonden vanaf mijn draadloze BlackBerry -toestel
DECnet phase 4 is about as old as ethernet and VMS. Ethernet was the main driving force for phase 4 owing to the large number of adjacent nodes and the sheer number.
Phase 3 does not have areas and only recognizes 255 hosts max. It did have circuit routing (of course)
Verzonden vanaf mijn draadloze BlackBerry -toestel
-----Original Message-----
From: Gregg Levine <gregg.drwho8 at gmail.com>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 17 Jul 2011 14:26:07
To: <hecnet at update.uu.se>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] DECnet et al
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."
On 2011-07-17 20.22, Peter Lothberg 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.
[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'.
Yes. The bridge is simple, but not really ideal. It causes a lot of traffic that would be better if we could restrict.
But for a router, we need to talk the DECnet routing packets, which I think might not be that bad, but then also route DECnet packets, which means much more cleverness. I'm afraid I definitely don't have time for all that.
But it would be nice. You could even be extra clever and only present one DECnet node with n interfaces, one for each endpoing that currently have a bridge. So it would seem like everyone had a connection to that router, but no direct connection to the other endpoints. So we'd have routing traffic running p-t-p to the virtual router, but no need to spread that traffic all over the earth, as is done today. Each end would still be running the bridge just like today, but the central hub would be rather different.
And I'm offline, as I only speak Multinet and Decnet in GRE... (and
takes for endpoints?)
Yeah. I know... I think you are not the only one not at all on the bridge, but I can't remember anyone else off hand.
Johnny
What is the difference between a bridge and a switch?
Ok, I won't debate nomenclature. At least now I think we're all talking
about the same thing :-)
Bob
DEC called them bridges and all of them were two-port devices.
When the DEChub 90 and 900 series came out DEC started to use the term switch too.
Verzonden vanaf mijn draadloze BlackBerry -toestel
When did DECNET first appear?
Mid-1970s, depending on which version ("Phase") you consider to be
"DECnet". I'm sure someone will provide a more specific date.
using what means to connect each system.
Point to point serial (note that doesn't mean RS-232!) links (rarely
parallel) using various means for the actual physical connection.
DECnet definitely predates Ethernet by many years, if that's your point.
Bob
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
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 19.55, hvlems at zonnet.nl wrote:
If there is no router present (on ethernet) then an endnode will just try and send the datagram. It knows the destination decnet address and thus can compute the target mac address.
Right. Thinking a little more I realize that it will do this.
This would not be very useful in HECnet, since we have several areas, and not everything is connected to the bridge. So routers are definitely needed, and thus you need atleast one L2 router in your area in order to talk to machines in other areas which you do not have a direct connection to. Or else you'll isolate yourself to only talk to directly connected machines.
Johnny
------Origineel bericht------
Van: Johnny Billquist
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 19:49
On 2011-07-17 19.45, Bob Armstrong wrote:
And so those packets will be tossed.
Tossed by who? The bridge program?
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? It needs to send it to a router, which will forward
it. But since there is no router, there is nothing it can do with it.
DECnet data traffic is not broadcast...
Just as information - from MIM, the area furthest away is are 59, which
is three hops distance. So it packets needs to pass through two
intermediate level 2 routers to get to the right area.
Johnny
Verzonden vanaf mijn draadloze BlackBerry -toestel
On 2011-07-17 19.55, Bob Armstrong wrote:
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.
Right. But this only works if the destination is in the same ethernet segment.
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 ?
Right. (UDP)
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?
Yes, the bridge makes it all look like it's on the same segment. But HECnet as a whole is not connected to this segment... There are parts that are further away, with routers in between, and which have point-to-point connections using DECnet over TCP, as provided by VMS Multinet.
And also, some places use the bridge for HECnet access, but have a separate local ethernet segment with their own area traffic going in.
Someone should at some point make a connectivity graph for HECnet. That would be cool. Where you could see all the segments and connections...
Johnny
On 2011-07-17 19.53, hvlems at zonnet.nl wrote:
Ennodes only become clever when the first datagram from the remote host returns. After that unnecessary routers are bypassed. Perhaps phase IV+ is different, in phase IV the first packet to a host outside the area is always sent to a router, when present.
It's the same inside the area. Endnodes maintain a cache of DECnet nodes it can communicate directly with, and bypass routers for those destinations. No matter what area. And it does this wether a router exists or not.
For everything not in the cache, the designated L1 router is used. It might be, however, that if no router exists, it just chances and tries to communicate directly anyway, even without a cache entry, since it has nothing to loose.
But if we skip L1 routers, then we loose all communication within the area as well, if it is formed by more than one segment. And still, all L2 routers are also L1 routers.
And I'm pretty sure an endnode will not use a L1/L2 router in another area as its designated router.
So skipping routers will reduce functionality in severe ways. But the need for plain L1 routers are perhaps not that big. But they might still have their use.
There exists also one problem not mentioned here, in connection with my bridge program. Machines have limits on how many broadcast endnodes and routers are handled on one ethernet segment. As we grow my virtual ethernet segment, we'll start hitting problems here. We might eventually want to split this into two different segments, with a router in between...
Johnny
Verzonden vanaf mijn draadloze BlackBerry -toestel
-----Original Message-----
From: Johnny Billquist<bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 17 Jul 2011 19:40:10
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] DECnet et al
On 2011-07-17 17.30, hvlems at zonnet.nl wrote:
Bob, endnodes in different areas can only talk to each other if there's no router present. So your scheme only works if all of us shut down all our L1 and L2 routers. Once an endnode sees a router in its area it will send all its off-area datagrams to it. If that router is an L1 router then the other area is seen as unreachable. If it is an L2 router then it must see the other area router.
No, endnodes will be clever and directly talk to other nodes that are
directly connected, even in the presence of a router. But the router is
needed to talk to anything not directly connected.
Johnny
I do need L1 routers (for DDCMP and DSSI circuits) and possibly others do too.
Show net/old is neat and useful when systems are in different rooms !
Hans
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 08:21:12
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] DECnet et al
Yes. But any L1 routers need help from L2 routers to get out of area.
Yeah, but given that the routers aren't actually needed for two nodes to
talk (under HECnet circumstances) then we don't actually need the routing
nodes at all. Sounds like their only real use is to be able to do a "SHOW
NETWORK/OLD" and see an nice list of active nodes (which is undeniably
neat)...
So a node configured as an end node in area 'n' can actually communicate
directly, over Ethernet, with another end node in area 'm'? But a L1
routing node in area 'n', in the same physical network topology, would
actually relay its packets for a node in area 'm' via an L2 router? And
does this actually take two L2 routers to hand off the packets, one for area
'n' and one for 'm'?
So (again, in the HECnet situation only) having an L1 router is a real
penalty - where as two end nodes could talk directly, just changing the same
machines to L1 routers would require the same traffic to be handled by two
intermediate nodes.
Or an I confused? That's a bit bizarre.
Bob
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.
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
If there is no router present (on ethernet) then an endnode will just try and send the datagram. It knows the destination decnet address and thus can compute the target mac address.
------Origineel bericht------
Van: Johnny Billquist
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 19:49
On 2011-07-17 19.45, Bob Armstrong wrote:
And so those packets will be tossed.
Tossed by who? The bridge program?
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? It needs to send it to a router, which will forward
it. But since there is no router, there is nothing it can do with it.
DECnet data traffic is not broadcast...
Just as information - from MIM, the area furthest away is are 59, which
is three hops distance. So it packets needs to pass through two
intermediate level 2 routers to get to the right area.
Johnny
Verzonden vanaf mijn draadloze BlackBerry -toestel
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
Ennodes only become clever when the first datagram from the remote host returns. After that unnecessary routers are bypassed. Perhaps phase IV+ is different, in phase IV the first packet to a host outside the area is always sent to a router, when present.
Verzonden vanaf mijn draadloze BlackBerry -toestel
-----Original Message-----
From: Johnny Billquist <bqt at softjar.se>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 17 Jul 2011 19:40:10
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] DECnet et al
On 2011-07-17 17.30, hvlems at zonnet.nl wrote:
Bob, endnodes in different areas can only talk to each other if there's no router present. So your scheme only works if all of us shut down all our L1 and L2 routers. Once an endnode sees a router in its area it will send all its off-area datagrams to it. If that router is an L1 router then the other area is seen as unreachable. If it is an L2 router then it must see the other area router.
No, endnodes will be clever and directly talk to other nodes that are
directly connected, even in the presence of a router. But the router is
needed to talk to anything not directly connected.
Johnny
I do need L1 routers (for DDCMP and DSSI circuits) and possibly others do too.
Show net/old is neat and useful when systems are in different rooms !
Hans
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 08:21:12
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] DECnet et al
Yes. But any L1 routers need help from L2 routers to get out of area.
Yeah, but given that the routers aren't actually needed for two nodes to
talk (under HECnet circumstances) then we don't actually need the routing
nodes at all. Sounds like their only real use is to be able to do a "SHOW
NETWORK/OLD" and see an nice list of active nodes (which is undeniably
neat)...
So a node configured as an end node in area 'n' can actually communicate
directly, over Ethernet, with another end node in area 'm'? But a L1
routing node in area 'n', in the same physical network topology, would
actually relay its packets for a node in area 'm' via an L2 router? And
does this actually take two L2 routers to hand off the packets, one for area
'n' and one for 'm'?
So (again, in the HECnet situation only) having an L1 router is a real
penalty - where as two end nodes could talk directly, just changing the same
machines to L1 routers would require the same traffic to be handled by two
intermediate nodes.
Or an I confused? That's a bit bizarre.
Bob
On 2011-07-17 19.45, Bob Armstrong wrote:
And so those packets will be tossed.
Tossed by who? The bridge program?
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? It needs to send it to a router, which will forward it. But since there is no router, there is nothing it can do with it. DECnet data traffic is not broadcast...
Just as information - from MIM, the area furthest away is are 59, which is three hops distance. So it packets needs to pass through two intermediate level 2 routers to get to the right area.
Johnny
