OK, let's try the bridge option first. Could you give me a sample .conf file
that I can use?
My external IP address is:
Name: osmium.homeip.net
Address: 87.209.50.192
I assume that a NAT entry is needed on my ADSL router, right? Would that be
for port 4711 (as in eau de cologne ??)
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: woensdag, juni 2010 14:16
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi, Hans.
H Vlems wrote:
OK Johnny, talk to me :-)
This is my plan: I intend to modify two systems to try the connection to
HECnet.
1) I have a linux system under Fedora 9 that will run the bridge software
and an Alpha Server 1200 under VMS V8.3 and DECnet phase IV, address
1.1010.
That should work without any strange problems. You'll probably want to
connect the bridge to me in that case. Let me know when you are ready to
try.
2) a VAXstation 4000 model 90A, running VMS V7.3 and DECnet phase V, in
area
44.
I'd like to try that connection without the linux system.
You need to find someone who can act as the other end in this case.
Which I suspect meaning someone running phase V and as an area router. I
don't know who might be doing this. Maybe someone who do can speak up.
Anyone know if this would be compatible with DECnet over IP as Multinet
does it?
Option 2 is my preferred situation since it removes a by and large unknown
factor from the equation (the linux box).
Sure. We just need to identify someone you can connect to.
So, what do I need to know and to do to make this work?
Someone to connect to...
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 21:03
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
H Vlems wrote:
What I meant with the phase III-IV-V answer is that direct connectivity
between a phase V and phase III system won't work. But poor man's routing
will work with a phase IV node in between. Functionality of course is
limited by the phase III host :-)
I wonder if phase III to phase V neccesarily will not work. However, DEC
never guaranteed that it will work, nor did they ever try it.
But you're absolutely right that very few people will have a phase III
system, RT-11 being the most likely candidate?
Probably. Or if someone is running some old versions of other systems.
I've seen the bridge program, but am not sure how to make the .conf file
work. Is it possible to use DECnet address 1.1010 to try and make this
work?
Yes. 1.1010 is not used by anyone, so that node number would be ok to
use to test.
But you also need to talk with me (or someone else) with the bridge
running, to act as the remote end.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 11:02
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi.
H Vlems wrote:
DECnet phase IV nodes are backwards compatible with phase III.
Yes. But the question here was if phase V will interoperate with phase
III. I don't know the answer to that one, but on the other hand, I don't
think anyone around is running phase III anyway.
There are no restrictions in functionality between phase IV nodes and
phase
V as seen by the unpriviledged user. Area routing may be an issue on
Alpha,
and of course ncl is more of a pain to remember than ncp ;-)
True, as far as that goes.
However, I am not sure that a phase V node can operate as a phase IV
area router.
Someone else pointed out that although DEC claimed that alphas could not
be area routers, that information is incorrect, and you can just tell an
Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
And yes, not only are the NCL commands more difficult to remember
(atleast for me), the node name management is way more difficult as
well. Do anyone know how you copy a nodename database from another
machine with DECnet+?
Two questions:
1-May I use area 44?
Sure.
2-Is there a short guide to set up DECnet over IP to connect to HECnet?
Not that I know of. Maybe Mark Wickens have something on hecnet.eu?
My page (http://www.update.uu.se/~bqt/hecnet.html) only have information
about the bridge.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Marc Chametzky
Verzonden: maandag, juni 2010 0:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having issues
with, I know one was RSTS/E v10.1, but I want to say it also included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase IV,
all these issues went away. These were things as simple as SET HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet Phase
III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's Phase
IV, which is the gold standard of DECnet, IMHO.
--Marc
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte:
06/27/10
08:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2968 - datum van uitgifte:
06/28/10
08:37:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2969 - datum van uitgifte:
06/28/10
20:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com
Versie: 9.0.830 / Virusdatabase: 271.1.1/2969 - datum van uitgifte: 06/28/10
20:35:00
Hello everyone,
days ago there was some debate about which Digital systems other than VMS
could run DECnet Phase IV... This is the proof that TOPS-10 can! :)
This is a CTERM connection:
| ALPHA::SYSTEM$ set host dieci
|
| T10 DECnet node DIECI 10:16:08 TTY4 system 2034
| Connected to Node ALPHA Line # 0
| Please LOGIN
|
| .login 1,2
| Job 4 T10 DECnet node DIECI TTY4
| [LGNJSP Other jobs same PPN]
| 10:16 1-Jul-10 Thursday
|
| .systat
|
| Status of T10 DECnet node DIECI at 10:16:32 on 01-Jul-110
|
| Uptime 23:14:34, 88% Null time = 88% Idle + 0% Lost, 10% Overhead
| 15 Jobs in use out of 120. 15 logged in, 13 detached.
|
| Job Who Line# What Size(P) State Run Time
|
| 1 [OPR] DET751 STOMPR 13+12 SL 0 01
| 2 [OPR] CTY OPR 67+40 HB 0
| 3 [OPR] DET751 FAL-10 118+40 SL 0
| 4 [OPR] 4 SYSTAT 23+SPY RN 0
| .
| .
| .
|
| .kjob
| [LGNJSP Other jobs same PPN]
| Job 4 User OPERATOR [1,2]
| Logged-off TTY4 at 10:16:33 on 1-Jul-10
| Runtime: 0:00:00, KCS:0, Connect time: 0:00:32
| Disk Reads:0, Writes:0, Blocks saved:10
|
| %REM-S-END, control returned to node ALPHA::
| ALPHA::SYSTEM$
This is the output from NCP:
| ALPHA::SYSTEM$ mcr ncp tell dieci sho exe char
|
|
| Node Volatile Characteristics as of 1-JUL-2010 10:30:06
|
| Executor node = 1.1010 (DIECI)
|
| Identification = DECnet-10 Version 4.0
| Management version = V4.0.0
| Loop count = 1
| Loop length = 127
| Loop Data type = mixed
| Incoming timer = 30
| Outgoing timer = 60
| NSP version = V4.0.0
| .
| .
| .
And, on the other side, this is an incoming DAP connection:
| OPR>sho sta fal
| OPR>
| 10:33:09 -- System Device Status --
|
| FAL-Stream Status:
| Strm Status Node Connect Time Bytes
| ---- --------------- ------ ------------ -------
| 0 Active ALPHA 00:00:27 0
| Reading TSU:TSU.MIC[1,2] for user 1,2
| 1 Idle
| 2 Idle
This is a DAP copy from VMS to TOPS-10:
| .r nft
|
| *copy =alpha::nodes.txt/user
| For remote alpha::nodes.txt
| User-id: system
| Account:
| Password:
| DSKB:[1,2]NODES.TXT <= ALPHA::SYS$SYSROOT:[SYSMGR]NODES.TXT.1
| Total of 296 words in 3 blocks in 1 file at 23877 baud
| *
All the usual services work both ways, with the sole exception of Phone that
doesn't exist on TOPS-10. I'm still learning how to use and configure the
Thing, and as a matter of facts I'm still running with security disabled.
The OS is TOPS-10 7.04 with the latest patches (TSU04, December 1990). The
emulator is Ken Harrenstien's KLH10 release 2.0h (Panda distribution) and
the tape images come from the Trailing Edge PDP-10 repository.
Thanks to everyone at alt.sys.pdp10 and to Beethoven's 9th Symphony. :)
Bye,
G.
P.S.: DIECI means ten in Italian. :)
Brian Hechinger wrote:
On Wed, Jun 30, 2010 at 05:02:37PM +0200, Johnny Billquist wrote:
In that case you should definitely not use my bridge...
Hmmm, I'll have to see what I want to do back to the house then. I'll deal
with that when the time comes. :-D
The bridge program will carry a lot of broadcast traffic (well, a lot is maybe saying much) that you don't really need, and which you will not get if you run a DECnet over IP thingie.
L1? L2? As in layers in the network stack?
I'm talking DECnet Level 1 or Level 2.
In talking to Steve I think I've sorted out how I want to get things setup.
Ah. Now I got it. :-)
Ok. Good if you have sorted things out.
Johnny
Johnny Billquist wrote:
Kari Uusim ki wrote:
The multicast address AB 00 00 03 00 00 is to all Phase IV routers (=endnode hello)
The multicast address AB 00 00 04 00 00 is to all Phase IV endnodes
(=router hello)
All Level 1 and Level 2 routers should send router hellos to endnodes and endnodes should send endnode hellos so that routers know of all endnodes.
Sigh. Why don't people read what I write? Note that *all* machines sends hello messages to AB 00 00 03 00 00.
Only level 2 routers sends anything on any other address, but they send on AB 00 00 03 00 00 too.
And ignore that. I was using a too small sample when I wrote, so it wasn't the full picture of things...
Johnny
Paul Koning wrote:
Paul Koning wrote:
...
The way this works is that there are two multicast addresses used on
Ethernet segments. (Well, three later on, a separate one for all L2
routers.) One is "all routers", one is "all endnodes". Routers
listen
to the first, endnodes to the second. Hellos are sent to "all
routers"
so ONLY routers hear hellos. Both endnodes and routers send hellos
(different types). So routers build a list of all the nodes on each
interface. The routers on an Ethernet pick one to be the designated
router, and only that router sends a hello to "all endnodes".
That's
how endnodes know the DR.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00,
ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last
two
addresses are sent to seems to differ from node to node, and I haven't
figured out exactly how yet).
That fits what I said. Ab:00:00:03:00:00 is "all routers". So the
hellos sent to that address are received by routers but not by endnodes.
Ab:00:00:04:00:00 is "all endnodes". The hello that goes to that
address is from the designated router. In your example I guess that was
an L2 router but that's just a coincidence. And there will only be one
router (L1 or L2) sending to that address, the designated router.
Ah. I was sampling from a too short time. Eventually I received a router hello message on ab:00:00:04:00:00 from an L1 router as well.
Ok. I was making the wrong assumptions because of this. Now you made me read the spec instead, which was good. Thanks. :-)
09:00:2b:02:00:00 was a later addition. It's not in the routing 2.0.0
spec, it would be in the 2.1.0 spec if we could find one. That would be
the "all L2 routers" address. The idea for adding that address was to
allow L2 routing messages to be sent to that address instead of the "all
routers" address, so L2 route updates would not bother L1 routers.
Makes sense.
...
So, obviously, routers and endnodes both send, and listen to the same
messages.
No, you're making an incorrect assumption. The multicast addresses you
send to, and the ones you listen to, are not necessarily the same. In
IP, yes (ARPs go to broadcast and everyone listens to that). Not so in
DECnet. End nodes listen to all-endnodes and send to all-routers.
Routers listen to all-routers and send to all-routers and (if DR) to
all-endnodes.
Yes. I made the wrong assumption. Looked at too little data.
DECnet very deliberately used multicast rather than broadcast because
control packets are of interest only to some of the nodes, so by using a
specific multicast address, you can enable that if you need to hear the
traffic and disable it if you don't.
Which is a good thing.
In fact, it's clear that the existence of broadcast is a design error
(and so is the fact that ARP uses it). Broadcast is defined as "traffic
that everyone wants to hear" and there IS no such traffic. For example,
you don't want to hear ARPs unless you speak IP, so clearly those should
have used an "All IP nodes" multicast address.
Yep. Not to mention some protocols designed be people using PC machines running DOS...
Johnny
Paul Koning wrote:
Paul Koning wrote:
...
The routing message size isn't an issue in Phase IV because the data
can
be sent in pieces. That was another important change from Phase
III,
which always sends the route data for all nodes (up to 255 of them)
whether there is a change or not. 255 nodes just barely fits into a
standard DDCMP packet, but 1023 nodes would not. (Nor in a standard
Ethernet frame, for that matter.) And it's wasteful to send data
that
hasn't changed. So Phase IV has a way to send routing data for
selected
nodes.
Looking at traffic, I'd say that systems seems to be sending out
routing
packet updates although nothing is changing.
Oh right... I forgot one detail.
Routing updates are sent when something changes, and those (in Phase IV)
can be optimized to omit what hasn't changed.
In addition, full routing messages (all destinations) are sent
periodically. That makes the system "self-stabilizing": if any node is
confused about the routing data, it will reasonably soon be straightened
out by a full update.
Yes. That more match with the reality as I can observe it. :-)
Johnny
Kari Uusim ki wrote:
On 30.6.2010 19:41, Johnny Billquist wrote:
Hi, Paul. I see that I'll have to be way more careful with how I choose
my words around you... :-)
Paul Koning wrote:
...
The 2.0.0 (phase IV) routing spec talks about the "on Ethernet"
cache
instead, and describes it in a way that makes it help only for
directly
attached nodes. The "previous hop" flavor was a generalization in,
I
think, 2.1.0 (Phase IV+).
Hmm, yuck. Now I'll have to try to remember some details, as well as
extrapolating some stuff.
No, as far as I can remember, the end-nodes will only remember (or
know)
of one level 1 router. It will pick the one with the highest priority
in
case there are more than one on the local segment. That will become
the
designated router, and will be used for all traffic I believe.
The way this works is that there are two multicast addresses used on
Ethernet segments. (Well, three later on, a separate one for all L2
routers.) One is "all routers", one is "all endnodes". Routers listen
to the first, endnodes to the second. Hellos are sent to "all routers"
so ONLY routers hear hellos. Both endnodes and routers send hellos
(different types). So routers build a list of all the nodes on each
interface. The routers on an Ethernet pick one to be the designated
router, and only that router sends a hello to "all endnodes". That's
how endnodes know the DR.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00,
ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last two
addresses are sent to seems to differ from node to node, and I haven't
figured out exactly how yet).
The multicast address AB 00 00 03 00 00 is to all Phase IV routers (=endnode hello)
The multicast address AB 00 00 04 00 00 is to all Phase IV endnodes
(=router hello)
All Level 1 and Level 2 routers should send router hellos to endnodes and endnodes should send endnode hellos so that routers know of all endnodes.
Sigh. Why don't people read what I write? Note that *all* machines sends hello messages to AB 00 00 03 00 00.
Only level 2 routers sends anything on any other address, but they send on AB 00 00 03 00 00 too.
Johnny
Paul Koning wrote:
...
The way this works is that there are two multicast addresses used on
Ethernet segments. (Well, three later on, a separate one for all L2
routers.) One is "all routers", one is "all endnodes". Routers
listen
to the first, endnodes to the second. Hellos are sent to "all
routers"
so ONLY routers hear hellos. Both endnodes and routers send hellos
(different types). So routers build a list of all the nodes on each
interface. The routers on an Ethernet pick one to be the designated
router, and only that router sends a hello to "all endnodes".
That's
how endnodes know the DR.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00,
ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last
two
addresses are sent to seems to differ from node to node, and I haven't
figured out exactly how yet).
That fits what I said. Ab:00:00:03:00:00 is "all routers". So the
hellos sent to that address are received by routers but not by endnodes.
Ab:00:00:04:00:00 is "all endnodes". The hello that goes to that
address is from the designated router. In your example I guess that was
an L2 router but that's just a coincidence. And there will only be one
router (L1 or L2) sending to that address, the designated router.
09:00:2b:02:00:00 was a later addition. It's not in the routing 2.0.0
spec, it would be in the 2.1.0 spec if we could find one. That would be
the "all L2 routers" address. The idea for adding that address was to
allow L2 routing messages to be sent to that address instead of the "all
routers" address, so L2 route updates would not bother L1 routers.
...
So, obviously, routers and endnodes both send, and listen to the same
messages.
No, you're making an incorrect assumption. The multicast addresses you
send to, and the ones you listen to, are not necessarily the same. In
IP, yes (ARPs go to broadcast and everyone listens to that). Not so in
DECnet. End nodes listen to all-endnodes and send to all-routers.
Routers listen to all-routers and send to all-routers and (if DR) to
all-endnodes.
DECnet very deliberately used multicast rather than broadcast because
control packets are of interest only to some of the nodes, so by using a
specific multicast address, you can enable that if you need to hear the
traffic and disable it if you don't.
In fact, it's clear that the existence of broadcast is a design error
(and so is the fact that ARP uses it). Broadcast is defined as "traffic
that everyone wants to hear" and there IS no such traffic. For example,
you don't want to hear ARPs unless you speak IP, so clearly those should
have used an "All IP nodes" multicast address.
paul
Paul Koning wrote:
...
The routing message size isn't an issue in Phase IV because the data
can
be sent in pieces. That was another important change from Phase
III,
which always sends the route data for all nodes (up to 255 of them)
whether there is a change or not. 255 nodes just barely fits into a
standard DDCMP packet, but 1023 nodes would not. (Nor in a standard
Ethernet frame, for that matter.) And it's wasteful to send data
that
hasn't changed. So Phase IV has a way to send routing data for
selected
nodes.
Looking at traffic, I'd say that systems seems to be sending out
routing
packet updates although nothing is changing.
Oh right... I forgot one detail.
Routing updates are sent when something changes, and those (in Phase IV)
can be optimized to omit what hasn't changed.
In addition, full routing messages (all destinations) are sent
periodically. That makes the system "self-stabilizing": if any node is
confused about the routing data, it will reasonably soon be straightened
out by a full update.
paul
On 30.6.2010 19:41, Johnny Billquist wrote:
Hi, Paul. I see that I'll have to be way more careful with how I choose
my words around you... :-)
Paul Koning wrote:
...
The 2.0.0 (phase IV) routing spec talks about the "on Ethernet"
cache
instead, and describes it in a way that makes it help only for
directly
attached nodes. The "previous hop" flavor was a generalization in,
I
think, 2.1.0 (Phase IV+).
Hmm, yuck. Now I'll have to try to remember some details, as well as
extrapolating some stuff.
No, as far as I can remember, the end-nodes will only remember (or
know)
of one level 1 router. It will pick the one with the highest priority
in
case there are more than one on the local segment. That will become
the
designated router, and will be used for all traffic I believe.
The way this works is that there are two multicast addresses used on
Ethernet segments. (Well, three later on, a separate one for all L2
routers.) One is "all routers", one is "all endnodes". Routers listen
to the first, endnodes to the second. Hellos are sent to "all routers"
so ONLY routers hear hellos. Both endnodes and routers send hellos
(different types). So routers build a list of all the nodes on each
interface. The routers on an Ethernet pick one to be the designated
router, and only that router sends a hello to "all endnodes". That's
how endnodes know the DR.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00,
ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last two
addresses are sent to seems to differ from node to node, and I haven't
figured out exactly how yet).
The multicast address AB 00 00 03 00 00 is to all Phase IV routers (=endnode hello)
The multicast address AB 00 00 04 00 00 is to all Phase IV endnodes
(=router hello)
All Level 1 and Level 2 routers should send router hellos to endnodes and endnodes should send endnode hellos so that routers know of all endnodes.
IIRC the 09-00-2B-02-00-00 multicasts are from DECdns.
(looking at live traffic right now)
I can give you a longer snapshot of live traffic if you want to see more
details...
So, obviously, routers and endnodes both send, and listen to the same
messages. If we ignore the weird other addresses of L2 routers, they in
fact all send messages on the same channel.
So, they all also pick up all the same information.
But, in addition to the hello messages, which all pick up and process,
and which are rather short messages sent fairly often, routers also send
level 1 and level 2 routing information messages. These are all just
thrown away by end-nodes. And level 1 routers more or less just throw
away level 2 routing messages as well.
End-nodes will, however, just snoop hello-messages, and know about
other
nodes that are on the same ethernet segment (I'm not sure if this
generalizes to other mediums than ethernet, I think the manuals only
talked about ethernet). So, you can actually have an ethernet segment
with only end-nodes, and communication will actually work anyway. Even
though if you look at adjacent nodes with NCP, you'll not see any.
That's the ethernet cache unless I read things wrong here, btw.
No, endnodes don't do any snooping (nor do routers). DECnet
intentionally was designed to rely on advertisements (hello messages)
and those were done in a way that limits overhead. So end nodes hear
only hellos from a single system (the designated router).
Sorry. Very sloppy wording on my part.
By "snooping" just meant that they receive the hello multicast messages,
and figure it out from there.
In essence, I meant snooping, since the messages aren't sent explicitly
to them, but they do not go into promiscous mode and look at all traffic
that pass over the ethernet.
But no, end-nodes will actually hear hello messages from everybody on
the same ethernet segment. From that, they remember all the nodes that
they can hear in their cache, and also remembers which is the routing
node with highest priority (priority of the router is carried in the
hello message).
If an end node is asked to talk to some address, it consults the cache.
If it's in the cache, the data there is used. If not, the message goes
to the designated router if one is known. Finally, if there is no DR
(single endnode-only LAN) then it sends directly to the destination
using the calculated MAC address.
Yes, it starts by consulting the cache, and if the destination is in
there, it is used.
If not, it is sent to the designated router.
I think that if no designated router exist, and it's not in the cache,
any traffic will just result in an error return right away.
Incoming traffic fills in the previous-hop cache, so once you get past
the first message, end node traffic goes via the optimal path.
No. The hello messages fills the cache. That's how it can work even if
there is no router.
What I find "horrible" about this is that end-nodes will (atleast in
VMS) will actually happily even talk with machines in another area, if
they happen to be sitting on the same ethernet segment (this has
bitten
me with my bridge and HECnet).
Yes, that was considered a feature. It's a side effect of the way the
previous hop cache works, and when we realized this we decided it was a
good thing so that's how it ended up.
Well... I don't know if I'd call it good. But that's probably because it
spoiled a feature I had wanted to do in my bridge... :-)
Anyway, the comment is that the path might not be optimal. End nodes
pick the level 1 router with the highest priority. If you have two
level
1 routers, the one you didn't communicate with might have been more
optimal, but you'll never know. And the same is true for area routers.
For out of area traffic you're definitely right, the first leg is to the
best L2 router for the destination area, which may not be the best way
to get to the final destination. (In a sensibly layed-out hierarchical
network, the difference should not be large.) But end nodes do
communicate just as efficiently as routers, thanks to the previous hop
cache. And in fact, for the multi area Ethernet case, they do better
than routers because routers will not talk directly to an out of area
node, even if it's on the same Ethernet.
Hmm... I don't think so. The first leg to another area from an end-node
will be to the designated level 1 router. From there it will travel to
the designated level 2 router, only then will it go by the most
efficient path to the right area (which might not in fact be the best
for the actual end destination), and only once inside that area will it
go by the most efficient path to the destination.
It all breaks down if you have several L1 or L2 routes on an area. (And
by break down I mean it can go suboptimal ways, it will still definitely
work just fine.)
Johnny
.
On Wed, Jun 30, 2010 at 05:02:37PM +0200, Johnny Billquist wrote:
In that case you should definitely not use my bridge...
Hmmm, I'll have to see what I want to do back to the house then. I'll deal
with that when the time comes. :-D
L1? L2? As in layers in the network stack?
I'm talking DECnet Level 1 or Level 2.
In talking to Steve I think I've sorted out how I want to get things setup.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Noted.
Johnny
Brian Hechinger wrote:
Node 52.1 will be named SUN
Sent from my iPhone
On Jun 30, 2010, at 11:31, Johnny Billquist <bqt at softjar.se> wrote:
Noted.
Johnny
Brian Hechinger wrote:
I would like to claim area 52.
-brian
Paul Koning wrote:
... Well, level 1 routers gives you pretty much the same isolation as
areas.
Unless you consider the relative size of the level 1 routing messages
a
problematic burden compared to level 2 routing messages. However, I'm
not even sure you can make the system not transmit level 1 routing
messages on all interfaces, meaning they will go out anyway, even if
you
only have another area at the other end of the line.
I think if you have a point to point out of area link you won't see L1
routing messages, but you probably will see them on an Ethernet.
Hmm. I have not tried, so I wouldn't be able to tell for sure. You might be right.
The routing message size isn't an issue in Phase IV because the data can
be sent in pieces. That was another important change from Phase III,
which always sends the route data for all nodes (up to 255 of them)
whether there is a change or not. 255 nodes just barely fits into a
standard DDCMP packet, but 1023 nodes would not. (Nor in a standard
Ethernet frame, for that matter.) And it's wasteful to send data that
hasn't changed. So Phase IV has a way to send routing data for selected
nodes.
Looking at traffic, I'd say that systems seems to be sending out routing packet updates although nothing is changing.
Johnny
Hi, Paul. I see that I'll have to be way more careful with how I choose my words around you... :-)
Paul Koning wrote:
...
The 2.0.0 (phase IV) routing spec talks about the "on Ethernet"
cache
instead, and describes it in a way that makes it help only for
directly
attached nodes. The "previous hop" flavor was a generalization in,
I
think, 2.1.0 (Phase IV+).
Hmm, yuck. Now I'll have to try to remember some details, as well as
extrapolating some stuff.
No, as far as I can remember, the end-nodes will only remember (or
know)
of one level 1 router. It will pick the one with the highest priority
in
case there are more than one on the local segment. That will become
the
designated router, and will be used for all traffic I believe.
The way this works is that there are two multicast addresses used on
Ethernet segments. (Well, three later on, a separate one for all L2
routers.) One is "all routers", one is "all endnodes". Routers listen
to the first, endnodes to the second. Hellos are sent to "all routers"
so ONLY routers hear hellos. Both endnodes and routers send hellos
(different types). So routers build a list of all the nodes on each
interface. The routers on an Ethernet pick one to be the designated
router, and only that router sends a hello to "all endnodes". That's
how endnodes know the DR.
Not really.
end-nodes send endnode-hello messages to ab:00:00:03:00:00
l1 routers send router-hello messages to ab:00:00:03:00:00
l2 routers send router-hello messages to ab:00:00:03:00:00, ab:00:00:04:00:00 and 09:00:2b:02:00:00 (exactly which of these last two addresses are sent to seems to differ from node to node, and I haven't figured out exactly how yet).
(looking at live traffic right now)
I can give you a longer snapshot of live traffic if you want to see more details...
So, obviously, routers and endnodes both send, and listen to the same messages. If we ignore the weird other addresses of L2 routers, they in fact all send messages on the same channel.
So, they all also pick up all the same information.
But, in addition to the hello messages, which all pick up and process, and which are rather short messages sent fairly often, routers also send level 1 and level 2 routing information messages. These are all just thrown away by end-nodes. And level 1 routers more or less just throw away level 2 routing messages as well.
End-nodes will, however, just snoop hello-messages, and know about
other
nodes that are on the same ethernet segment (I'm not sure if this
generalizes to other mediums than ethernet, I think the manuals only
talked about ethernet). So, you can actually have an ethernet segment
with only end-nodes, and communication will actually work anyway. Even
though if you look at adjacent nodes with NCP, you'll not see any.
That's the ethernet cache unless I read things wrong here, btw.
No, endnodes don't do any snooping (nor do routers). DECnet
intentionally was designed to rely on advertisements (hello messages)
and those were done in a way that limits overhead. So end nodes hear
only hellos from a single system (the designated router).
Sorry. Very sloppy wording on my part.
By "snooping" just meant that they receive the hello multicast messages, and figure it out from there.
In essence, I meant snooping, since the messages aren't sent explicitly to them, but they do not go into promiscous mode and look at all traffic that pass over the ethernet.
But no, end-nodes will actually hear hello messages from everybody on the same ethernet segment. From that, they remember all the nodes that they can hear in their cache, and also remembers which is the routing node with highest priority (priority of the router is carried in the hello message).
If an end node is asked to talk to some address, it consults the cache.
If it's in the cache, the data there is used. If not, the message goes
to the designated router if one is known. Finally, if there is no DR
(single endnode-only LAN) then it sends directly to the destination
using the calculated MAC address.
Yes, it starts by consulting the cache, and if the destination is in there, it is used.
If not, it is sent to the designated router.
I think that if no designated router exist, and it's not in the cache, any traffic will just result in an error return right away.
Incoming traffic fills in the previous-hop cache, so once you get past
the first message, end node traffic goes via the optimal path.
No. The hello messages fills the cache. That's how it can work even if there is no router.
What I find "horrible" about this is that end-nodes will (atleast in
VMS) will actually happily even talk with machines in another area, if
they happen to be sitting on the same ethernet segment (this has
bitten
me with my bridge and HECnet).
Yes, that was considered a feature. It's a side effect of the way the
previous hop cache works, and when we realized this we decided it was a
good thing so that's how it ended up.
Well... I don't know if I'd call it good. But that's probably because it spoiled a feature I had wanted to do in my bridge... :-)
Anyway, the comment is that the path might not be optimal. End nodes
pick the level 1 router with the highest priority. If you have two
level
1 routers, the one you didn't communicate with might have been more
optimal, but you'll never know. And the same is true for area routers.
For out of area traffic you're definitely right, the first leg is to the
best L2 router for the destination area, which may not be the best way
to get to the final destination. (In a sensibly layed-out hierarchical
network, the difference should not be large.) But end nodes do
communicate just as efficiently as routers, thanks to the previous hop
cache. And in fact, for the multi area Ethernet case, they do better
than routers because routers will not talk directly to an out of area
node, even if it's on the same Ethernet.
Hmm... I don't think so. The first leg to another area from an end-node will be to the designated level 1 router. From there it will travel to the designated level 2 router, only then will it go by the most efficient path to the right area (which might not in fact be the best for the actual end destination), and only once inside that area will it go by the most efficient path to the destination.
It all breaks down if you have several L1 or L2 routes on an area. (And by break down I mean it can go suboptimal ways, it will still definitely work just fine.)
Johnny
Node 52.1 will be named SUN
Sent from my iPhone
On Jun 30, 2010, at 11:31, Johnny Billquist <bqt at softjar.se> wrote:
Noted.
Johnny
Brian Hechinger wrote:
I would like to claim area 52.
-brian
...
Well, level 1 routers gives you pretty much the same isolation as
areas.
Unless you consider the relative size of the level 1 routing messages
a
problematic burden compared to level 2 routing messages. However, I'm
not even sure you can make the system not transmit level 1 routing
messages on all interfaces, meaning they will go out anyway, even if
you
only have another area at the other end of the line.
I think if you have a point to point out of area link you won't see L1
routing messages, but you probably will see them on an Ethernet.
The routing message size isn't an issue in Phase IV because the data can
be sent in pieces. That was another important change from Phase III,
which always sends the route data for all nodes (up to 255 of them)
whether there is a change or not. 255 nodes just barely fits into a
standard DDCMP packet, but 1023 nodes would not. (Nor in a standard
Ethernet frame, for that matter.) And it's wasteful to send data that
hasn't changed. So Phase IV has a way to send routing data for selected
nodes.
paul
...
The 2.0.0 (phase IV) routing spec talks about the "on Ethernet"
cache
instead, and describes it in a way that makes it help only for
directly
attached nodes. The "previous hop" flavor was a generalization in,
I
think, 2.1.0 (Phase IV+).
Hmm, yuck. Now I'll have to try to remember some details, as well as
extrapolating some stuff.
No, as far as I can remember, the end-nodes will only remember (or
know)
of one level 1 router. It will pick the one with the highest priority
in
case there are more than one on the local segment. That will become
the
designated router, and will be used for all traffic I believe.
The way this works is that there are two multicast addresses used on
Ethernet segments. (Well, three later on, a separate one for all L2
routers.) One is "all routers", one is "all endnodes". Routers listen
to the first, endnodes to the second. Hellos are sent to "all routers"
so ONLY routers hear hellos. Both endnodes and routers send hellos
(different types). So routers build a list of all the nodes on each
interface. The routers on an Ethernet pick one to be the designated
router, and only that router sends a hello to "all endnodes". That's
how endnodes know the DR.
End-nodes will, however, just snoop hello-messages, and know about
other
nodes that are on the same ethernet segment (I'm not sure if this
generalizes to other mediums than ethernet, I think the manuals only
talked about ethernet). So, you can actually have an ethernet segment
with only end-nodes, and communication will actually work anyway. Even
though if you look at adjacent nodes with NCP, you'll not see any.
That's the ethernet cache unless I read things wrong here, btw.
No, endnodes don't do any snooping (nor do routers). DECnet
intentionally was designed to rely on advertisements (hello messages)
and those were done in a way that limits overhead. So end nodes hear
only hellos from a single system (the designated router).
If an end node is asked to talk to some address, it consults the cache.
If it's in the cache, the data there is used. If not, the message goes
to the designated router if one is known. Finally, if there is no DR
(single endnode-only LAN) then it sends directly to the destination
using the calculated MAC address.
Incoming traffic fills in the previous-hop cache, so once you get past
the first message, end node traffic goes via the optimal path.
What I find "horrible" about this is that end-nodes will (atleast in
VMS) will actually happily even talk with machines in another area, if
they happen to be sitting on the same ethernet segment (this has
bitten
me with my bridge and HECnet).
Yes, that was considered a feature. It's a side effect of the way the
previous hop cache works, and when we realized this we decided it was a
good thing so that's how it ended up.
Anyway, the comment is that the path might not be optimal. End nodes
pick the level 1 router with the highest priority. If you have two
level
1 routers, the one you didn't communicate with might have been more
optimal, but you'll never know. And the same is true for area routers.
For out of area traffic you're definitely right, the first leg is to the
best L2 router for the destination area, which may not be the best way
to get to the final destination. (In a sensibly layed-out hierarchical
network, the difference should not be large.) But end nodes do
communicate just as efficiently as routers, thanks to the previous hop
cache. And in fact, for the multi area Ethernet case, they do better
than routers because routers will not talk directly to an out of area
node, even if it's on the same Ethernet.
paul
Brian Hechinger wrote:
On Mon, Jun 28, 2010 at 12:10:31PM -0700, Johnny Billquist wrote:
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical location, but rather with organizational. So keep it within one area.
Ok, sounds good to me.
For physically different locations, you might want to use level 1 routers, though. But as the internet nowadays is so fast, using just a bridge, and pretend that it's all one ethernet segment also works just fine.
My upstream blows (as well as latency in general) so I'd like to avoid
putting any more traffic across it than is absolutely nessesary.
In that case you should definitely not use my bridge...
I suppose it's not a huge deal at this point since the SIMH instance at
the colo will be the only thing running most likely for a little while.
That being said, how should I set it up? L1? L2? Does anyone want to
use me as a hub?
L1? L2? As in layers in the network stack?
Also, is there a list of what areas are already in use so I can pick an
unused one?
Already answered by others, I noticed... :-)
Johnny
Paul Koning wrote:
Johnny, the original DECnet manuals showed pictures of area routers
that
were interconnected by WAN links. Each site had its own area number.
In
fact
the name "area routing" implies clearly that the concept was meant to
set up
DECnet networks that were geographically separated.
I don't remember those pictures, but this is an issue that generated a
lot of debate and a lot of annoyance in the DECnet architecture group.
The pictures, atleast in the RSX manuals, are very simplistic. Like five nodes, maybe four areas, and spread between the west and east coast of the US.
...
One reason for separating systems in different areas was that
rebooting
the
pc's would generate so many DECnet state up and down messages that
PDP-
11's
and the older VAX systems choked in their console output.
That's a good one. (Actually, the way to deal with that is to turn the
logging to console off for that event...) Yes, that's a valid example.
The purpose of area routing is to avoid having things get too large.
There were various opinions on how big an area (or Phase III network)
could reasonably be. Originally the limit was assumed to be about 32,
without any basis that I know of. That too produced a pile of debate,
and later on it became obvious you could go much higher. But clearly
you couldn't run a flat Phase III style network with 10,000 nodes.
Well, phase III networks could never be more than 255 nodes. :-)
For that reason area routing was introduced, so each instance of the
routing algorithm (in-area and level 2) would deal with a reasonably
small topology. Again debates broke out whether a full area (1000
nodes) was acceptable. It turned out yes, but certainly keeping it
smaller, say to 100-200, would be a good thing if possible.
When phase IV came, and the node address was extended to 16 bits, it's obvious (I think) that you didn't want a flat 16-bit address space.
So then it becomes a question of how to split that address up. By that time, I think they had come to the conclusion that a single network could definitely be more than 255 nodes. 1023 seemed like a good size, leaving 63 areas. (Neither node 0, nor area 0 is permitted.)
Geography isn't a consideration unless the links are slow enough to make
route change propagation an issue. Corporate organization (different
departments) CERTAINLY isnt' a consideration, though some people tried
to argue that it was valid to do so.
Well, level 1 routers gives you pretty much the same isolation as areas. Unless you consider the relative size of the level 1 routing messages a problematic burden compared to level 2 routing messages. However, I'm not even sure you can make the system not transmit level 1 routing messages on all interfaces, meaning they will go out anyway, even if you only have another area at the other end of the line.
Johnny
Paul Koning wrote:
...
Level 1 routers knows where all machines in the same area are located,
and knows the most efficient way to any node within the same area.
However, it only keeps track of the closest area router, and knows
nothing about any other area.
Area routers work just like level 1 routers, but they also have an
area
routing table, so they know the most efficient path to an area router
for any area.
So, an end node only knows what machines are on the same segment, and
which is the closest level 1 router. Level 1 routers knows where all
machines are in the same area, and knows where the closest area router
is.
Area routers knows where every machine is on the local area, and also
where all area routers are.
Right... except for end nodes. Those know what *routers* exist on the
same segment. End nodes don't know (directly) about other end nodes.
To make that case efficient, end nodes have a "previous hop cache".
Whenever an end node hears from another node, it remembers the previous
hop (the last router on the path) and sends future traffic for that
destination to that router. This way it can pick any router for the
initial packets but will quickly move to the optimal one. It also
tracks directly connected endnodes in that cache, because a router that
forwards a packet onto the same segment as it arrived will leave the
"intra-Ethernet" bit in the header set, which tells the endnode that
destination is directly reachable.
The 2.0.0 (phase IV) routing spec talks about the "on Ethernet" cache
instead, and describes it in a way that makes it help only for directly
attached nodes. The "previous hop" flavor was a generalization in, I
think, 2.1.0 (Phase IV+).
Hmm, yuck. Now I'll have to try to remember some details, as well as extrapolating some stuff.
No, as far as I can remember, the end-nodes will only remember (or know) of one level 1 router. It will pick the one with the highest priority in case there are more than one on the local segment. That will become the designated router, and will be used for all traffic I believe.
End-nodes will, however, just snoop hello-messages, and know about other nodes that are on the same ethernet segment (I'm not sure if this generalizes to other mediums than ethernet, I think the manuals only talked about ethernet). So, you can actually have an ethernet segment with only end-nodes, and communication will actually work anyway. Even though if you look at adjacent nodes with NCP, you'll not see any. That's the ethernet cache unless I read things wrong here, btw.
What I find "horrible" about this is that end-nodes will (atleast in VMS) will actually happily even talk with machines in another area, if they happen to be sitting on the same ethernet segment (this has bitten me with my bridge and HECnet).
Now, this means that a machine that sits in one area will not
neccesarily take the shortest path to a machine in another area. In
fact, it will not neccesarily take the shortest path even to another
machine in the same area. But that's another story. :-)
??? It certainly will, where "shortest" is defined as "least path
*cost*", not necessarily fewest hops.
Sorry. Yes, you are right. I should have been more careful with my words. It was the path cost I was thinking of. I should have said cheapest, not shortest.
Anyway, the comment is that the path might not be optimal. End nodes pick the level 1 router with the highest priority. If you have two level 1 routers, the one you didn't communicate with might have been more optimal, but you'll never know. And the same is true for area routers.
Johnny
...
Level 1 routers knows where all machines in the same area are located,
and knows the most efficient way to any node within the same area.
However, it only keeps track of the closest area router, and knows
nothing about any other area.
Area routers work just like level 1 routers, but they also have an
area
routing table, so they know the most efficient path to an area router
for any area.
So, an end node only knows what machines are on the same segment, and
which is the closest level 1 router. Level 1 routers knows where all
machines are in the same area, and knows where the closest area router
is.
Area routers knows where every machine is on the local area, and also
where all area routers are.
Right... except for end nodes. Those know what *routers* exist on the
same segment. End nodes don't know (directly) about other end nodes.
To make that case efficient, end nodes have a "previous hop cache".
Whenever an end node hears from another node, it remembers the previous
hop (the last router on the path) and sends future traffic for that
destination to that router. This way it can pick any router for the
initial packets but will quickly move to the optimal one. It also
tracks directly connected endnodes in that cache, because a router that
forwards a packet onto the same segment as it arrived will leave the
"intra-Ethernet" bit in the header set, which tells the endnode that
destination is directly reachable.
The 2.0.0 (phase IV) routing spec talks about the "on Ethernet" cache
instead, and describes it in a way that makes it help only for directly
attached nodes. The "previous hop" flavor was a generalization in, I
think, 2.1.0 (Phase IV+).
Now, this means that a machine that sits in one area will not
neccesarily take the shortest path to a machine in another area. In
fact, it will not neccesarily take the shortest path even to another
machine in the same area. But that's another story. :-)
??? It certainly will, where "shortest" is defined as "least path
*cost*", not necessarily fewest hops.
paul
On 30.6.2010 15:45, Johnny Billquist wrote:
H Vlems wrote:
Johnny, the original DECnet manuals showed pictures of area routers that
were interconnected by WAN links. Each site had its own area number.
In fact
the name "area routing" implies clearly that the concept was meant to
set up
DECnet networks that were geographically separated.
Certainly. But that does not imply that just because you have physically
different locations that they must be in different areas. And areas
don't necessarily imply geography... :-)
Level 1 routers does exactly the same job, the same way, but keeps it
within one area.
But basically, the reasons for the different "levels" are originally
technical. You have segments, which more or less means directly
connected machines.
Then you have an area, which connects these segments. Traffic within a
segment can be fairly high. Between segments there is much less traffic,
since only traffic actually meant for a destination at the other end is
going through, and then of course the routing messages of the level 1
routers.
Level 1 routers knows where all machines in the same area are located,
and knows the most efficient way to any node within the same area.
However, it only keeps track of the closest area router, and knows
nothing about any other area.
Area routers work just like level 1 routers, but they also have an area
routing table, so they know the most efficient path to an area router
for any area.
So, an end node only knows what machines are on the same segment, and
which is the closest level 1 router. Level 1 routers knows where all
machines are in the same area, and knows where the closest area router is.
Area routers knows where every machine is on the local area, and also
where all area routers are.
Now, this means that a machine that sits in one area will not
neccesarily take the shortest path to a machine in another area. In
fact, it will not neccesarily take the shortest path even to another
machine in the same area. But that's another story. :-)
For most points and purposes, a level 1 router and an area router will
give you exactly the same effect.
So, just because you have machines that are physically remote is by no
mean a reason for them to be in separate areas. A level 1 router will
solve that just as well.
What areas bring to the table is essentially just that you expand the
address space, and add another level of hierarchy to the network. It is
(obviously) up to you how you want to interpret that extra level. I'm
not saying that you cannot use it to match network hierarchy to
geography, just that there is no technical reason to align things that way.
I ran a fairly large DECnet environment 20 years ago with >20
PDP-11's, >80
VAX systems >600 pc's and several alpha's, plus a few unix systems
that ran
DECnet too (in those days DECnet was the multiplatform protocol of
choice).
I seprataed each factory in its own DECnet area. DEC Holland got midly
interested in the design because they wondered whether the level 2
routing
overhead wouldn't hurt network performance. Which it didn't :-)
Can't see why it should. If you have a fairly busy network, the overhead
of the level 2 routing packets is very low. And if the network is mostly
idle, you have the capacity to spare anyway.
I'm surprised if DEC Holland was that curious, or didn't know better,
since DEC's internal network was way larger at that time.
They had already passed 60.000 nodes on Easynet (which was the name of
the internal network). I worked at DEC for a while in the 80s, and
Easynet worked just fine, and was very nice.
If I remember right, areas were sortof allocated by country, although
some places (like the US) used several, while some places shared one
between several countries.
Quite correct. Finland used area 50.
In early 1990's the Easynet had Phase V area routers, which also were used for TCP/IP routing (Integrated IS-IS).
Kari
One reason for separating systems in different areas was that
rebooting the
pc's would generate so many DECnet state up and down messages that
PDP-11's
and the older VAX systems choked in their console output.
Yeah, that can be an annoyance. But that's what the logging filters are
there for.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 21:11
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Brian Hechinger wrote:
Ok, so I should be getting to my plans soon enough here and had some
questions
about how I should set this up.
I'm going to install SIMH on the machine in colo (100mbit connection
here
in
the US, so might be useful as a "hub") as well as a small handful of
boxes
here at home.
Sounds good.
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical
location, but rather with organizational. So keep it within one area.
For physically different locations, you might want to use level 1
routers, though. But as the internet nowadays is so fast, using just a
bridge, and pretend that it's all one ethernet segment also works just
fine.
Johnny
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com Versie: 9.0.830 / Virusdatabase:
271.1.1/2969 - datum van uitgifte: 06/28/10
20:35:00
.
H Vlems wrote:
Johnny, the original DECnet manuals showed pictures of area routers that
were interconnected by WAN links. Each site had its own area number. In fact
the name "area routing" implies clearly that the concept was meant to set up
DECnet networks that were geographically separated.
Certainly. But that does not imply that just because you have physically different locations that they must be in different areas. And areas don't necessarily imply geography... :-)
Level 1 routers does exactly the same job, the same way, but keeps it within one area.
But basically, the reasons for the different "levels" are originally technical. You have segments, which more or less means directly connected machines.
Then you have an area, which connects these segments. Traffic within a segment can be fairly high. Between segments there is much less traffic, since only traffic actually meant for a destination at the other end is going through, and then of course the routing messages of the level 1 routers.
Level 1 routers knows where all machines in the same area are located, and knows the most efficient way to any node within the same area. However, it only keeps track of the closest area router, and knows nothing about any other area.
Area routers work just like level 1 routers, but they also have an area routing table, so they know the most efficient path to an area router for any area.
So, an end node only knows what machines are on the same segment, and which is the closest level 1 router. Level 1 routers knows where all machines are in the same area, and knows where the closest area router is.
Area routers knows where every machine is on the local area, and also where all area routers are.
Now, this means that a machine that sits in one area will not neccesarily take the shortest path to a machine in another area. In fact, it will not neccesarily take the shortest path even to another machine in the same area. But that's another story. :-)
For most points and purposes, a level 1 router and an area router will give you exactly the same effect.
So, just because you have machines that are physically remote is by no mean a reason for them to be in separate areas. A level 1 router will solve that just as well.
What areas bring to the table is essentially just that you expand the address space, and add another level of hierarchy to the network. It is (obviously) up to you how you want to interpret that extra level. I'm not saying that you cannot use it to match network hierarchy to geography, just that there is no technical reason to align things that way.
I ran a fairly large DECnet environment 20 years ago with >20 PDP-11's, >80
VAX systems >600 pc's and several alpha's, plus a few unix systems that ran
DECnet too (in those days DECnet was the multiplatform protocol of choice).
I seprataed each factory in its own DECnet area. DEC Holland got midly
interested in the design because they wondered whether the level 2 routing
overhead wouldn't hurt network performance. Which it didn't :-)
Can't see why it should. If you have a fairly busy network, the overhead of the level 2 routing packets is very low. And if the network is mostly idle, you have the capacity to spare anyway.
I'm surprised if DEC Holland was that curious, or didn't know better, since DEC's internal network was way larger at that time.
They had already passed 60.000 nodes on Easynet (which was the name of the internal network). I worked at DEC for a while in the 80s, and Easynet worked just fine, and was very nice.
If I remember right, areas were sortof allocated by country, although some places (like the US) used several, while some places shared one between several countries.
One reason for separating systems in different areas was that rebooting the
pc's would generate so many DECnet state up and down messages that PDP-11's
and the older VAX systems choked in their console output.
Yeah, that can be an annoyance. But that's what the logging filters are there for.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 21:11
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Brian Hechinger wrote:
Ok, so I should be getting to my plans soon enough here and had some
questions
about how I should set this up.
I'm going to install SIMH on the machine in colo (100mbit connection here
in
the US, so might be useful as a "hub") as well as a small handful of boxes
here at home.
Sounds good.
Should I just use one area? What's the best way to set that up?
Areas in DECnet are not really meant to be associated with physical location, but rather with organizational. So keep it within one area.
For physically different locations, you might want to use level 1 routers, though. But as the internet nowadays is so fast, using just a bridge, and pretend that it's all one ethernet segment also works just fine.
Johnny
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com Versie: 9.0.830 / Virusdatabase: 271.1.1/2969 - datum van uitgifte: 06/28/10
20:35:00
Hi, Hans.
H Vlems wrote:
OK Johnny, talk to me :-)
This is my plan: I intend to modify two systems to try the connection to
HECnet.
1) I have a linux system under Fedora 9 that will run the bridge software
and an Alpha Server 1200 under VMS V8.3 and DECnet phase IV, address 1.1010.
That should work without any strange problems. You'll probably want to connect the bridge to me in that case. Let me know when you are ready to try.
2) a VAXstation 4000 model 90A, running VMS V7.3 and DECnet phase V, in area
44.
I'd like to try that connection without the linux system.
You need to find someone who can act as the other end in this case. Which I suspect meaning someone running phase V and as an area router. I don't know who might be doing this. Maybe someone who do can speak up.
Anyone know if this would be compatible with DECnet over IP as Multinet does it?
Option 2 is my preferred situation since it removes a by and large unknown
factor from the equation (the linux box).
Sure. We just need to identify someone you can connect to.
So, what do I need to know and to do to make this work?
Someone to connect to...
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 21:03
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
H Vlems wrote:
What I meant with the phase III-IV-V answer is that direct connectivity
between a phase V and phase III system won't work. But poor man's routing
will work with a phase IV node in between. Functionality of course is
limited by the phase III host :-)
I wonder if phase III to phase V neccesarily will not work. However, DEC never guaranteed that it will work, nor did they ever try it.
But you're absolutely right that very few people will have a phase III
system, RT-11 being the most likely candidate?
Probably. Or if someone is running some old versions of other systems.
I've seen the bridge program, but am not sure how to make the .conf file
work. Is it possible to use DECnet address 1.1010 to try and make this
work?
Yes. 1.1010 is not used by anyone, so that node number would be ok to use to test.
But you also need to talk with me (or someone else) with the bridge running, to act as the remote end.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: maandag, juni 2010 11:02
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
Hi.
H Vlems wrote:
DECnet phase IV nodes are backwards compatible with phase III.
Yes. But the question here was if phase V will interoperate with phase III. I don't know the answer to that one, but on the other hand, I don't think anyone around is running phase III anyway.
There are no restrictions in functionality between phase IV nodes and
phase
V as seen by the unpriviledged user. Area routing may be an issue on
Alpha,
and of course ncl is more of a pain to remember than ncp ;-)
True, as far as that goes.
However, I am not sure that a phase V node can operate as a phase IV area router.
Someone else pointed out that although DEC claimed that alphas could not be area routers, that information is incorrect, and you can just tell an Alpha VMS phase IV node to be an area router, if you want to.
However, DECnet+ is phase V, and all bets are off. :-)
And yes, not only are the NCL commands more difficult to remember (atleast for me), the node name management is way more difficult as well. Do anyone know how you copy a nodename database from another machine with DECnet+?
Two questions:
1-May I use area 44?
Sure.
2-Is there a short guide to set up DECnet over IP to connect to HECnet?
Not that I know of. Maybe Mark Wickens have something on hecnet.eu?
My page (http://www.update.uu.se/~bqt/hecnet.html) only have information about the bridge.
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Marc Chametzky
Verzonden: maandag, juni 2010 0:04
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Attaching to hecnet
DECnet-Plus isn't
able to connect, or at least reliably connect to all OS's that can
potentially be on HECnet. I forget what all OS's I was having issues
with, I know one was RSTS/E v10.1, but I want to say it also included
VAX/VMS. Once I *upgraded* my Alpha running OpenVMS to DECnet Phase IV,
all these issues went away. These were things as simple as SET HOST.
It's probably that DECnet-Plus (Phase V) cannot speak with DECnet Phase III (such as on RSTS/E and TOPS-10/20). That's my guess anyway.
Phase V should be able to communicate with VAX/VMS since that's Phase IV, which is the gold standard of DECnet, IMHO.
--Marc
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com Versie: 9.0.830 / Virusdatabase: 271.1.1/2966 - datum van uitgifte:
06/27/10
08:35:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com Versie: 9.0.830 / Virusdatabase: 271.1.1/2968 - datum van uitgifte:
06/28/10
08:37:00
Geen virus gevonden in het binnenkomende-bericht.
Gecontroleerd door AVG - www.avg.com Versie: 9.0.830 / Virusdatabase: 271.1.1/2969 - datum van uitgifte: 06/28/10
20:35:00
