Paul,
The overhead incurred by level 1 or level 2 routing was pretty low. The site
I mentioned in the earlier example grew to more than 1000 pc's. They all ran
DECnet for Pathworks connectivity. They just fitted in one DECnet area. The
area routing was performed by two microVAX II systems, one active, the other
backup. They did nothing but area routing and had sufficient cpu power and
memory available. Ethernet was 10BASE2 in those days and that worked well.
The only traffic outside the area was CTERM and a little FAL.
The reason we didn't turn of console logging was that plant personnel
archived the console logs for reference purposes.
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Paul Koning
Verzonden: dinsdag, juni 2010 12:55
Aan: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Attaching to hecnet
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.
...
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.
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.
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.
paul
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
On Tue, Jun 29, 2010 at 12:36:06PM -0400, Steve Davidson wrote:
Brian,
I have sent you a copy of the area list and the nodename list.
Fantastic, thanks Steve!!
-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)
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.
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?
Also, is there a list of what areas are already in use so I can pick an
unused one?
Thanks!!
-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)
Brian,
I have sent you a copy of the area list and the nodename list.
-Steve
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.
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?
Also, is there a list of what areas are already in use so I can pick an
unused one?
Thanks!!
-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)
The definitive list is maintained at MIM::US:[DECNET]DECNET.TXT. I'll send
you a copy outside of this list.
-Steve
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.
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?
Also, is there a list of what areas are already in use so I can pick an
unused one?
Thanks!!
-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)
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.
...
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.
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.
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.
paul
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 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 :-)
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.
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
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.
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.
Option 2 is my preferred situation since it removes a by and large unknown
factor from the equation (the linux box).
So, what do I need to know and to do to make this work?
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
There are additional limitations to phase III nodes in a phase IV
network.
Phase III nodes do not have any idea of areas, and all node numbers
must
be below 256. (In short, phase III nodes use a single byte for node
addresses.)
So, a phase III node can only talk with other nodes within the same
area, and only if those nodes have low node numbers.
Another key point: Phase III doesn't support Ethernet -- it only handles point to point (DDCMP and equivalent) links. The network layer messages are different, too. For one thing, the init message has the older routing layer version number in it. For another, in the case of routers, the route vector is sent as a simple full vector rather than as a list of segments with new data (omitting unchanged data) as is done for Phase IV.
It's certainly possible in principle for a Phase V node to understand Phase III routing layer messages; in practice, I doubt this was done and the rules certainly didn't require it.
paul
