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
