I just had a conversation with one of the operators of a HECnet L2 router who has demoted it to L1 because of connectivity issues to other areas. That prompted some thinking about the DECnet requirements for fault tolerance.
The basic principle of DECnet Phase IV is that L1 routing (within an area) involves only routers of that area, and L2 routing (across areas) involves only L2 routers. Phase V changes that to some extent, but HECnet is not Phase V and isn't likely to be. :-) In addition, L1 routers send out of area traffic to some L2 router in their area, but without any awareness of the L2 topology.
This has several consequences:
1. If some of the L2 routers in your area can't see the destination area but others can, you may not be able to communicate even though it would seem that there is a way to get there from here.
2. If your area is split, i.e., some of its L2 routers can see one subset of the nodes in the area and other L2 routers can see a different subset, then out of area traffic inbound to that area may not reach its destination -- if it enters at the "wrong" L2 entry point.
I believe the issue I mentioned at the top was #1: one of the L2 routers went down and the remaining L2 routers of that area ended up at two sides of a partitioned L2 network.
Obviously HECnet isn't a production network, but still it would be nice for it to be tolerant of outages. Especially since we can insert additional routers easily with PyDECnet or Robert Jarratt's C router. The HECnet map can be set to show just the L2 network (using the layers menu, accessible via the layers icon in the top right corner of the map). It's easy to see a number of L2 routers that have only one connection to the rest of HECnet. It's also clear that a large fraction of the connectivity is via Sweden, which certainly is a fine option but it's a bit odd for a node in, say, western Canada to have only that one connection and none to nodes much closer to it.
The map display doesn't give a visual clue about singly-connected area routers for which there is no location information in the database (the ones plotted at Inaccessible Island). The data is there in the map data table; it wouldn't be too hard to do some post-processing on that data to find cases of no redundancy.
I'm curious if people would be interested in trying to make HECnet more fault tolerant. My router (PYTHON) can definitely help, especially for North American nodes, and I'm sure there are a number of others that feel the same.
paul
I think I already sent this to all the people who are directly connected
to A2RTR, but just in case I missed anybody, here it is for general
consumption -
I have moved A2RTR to an Amazon cloud server. The new IP is now
35.82.76.235, although I strongly recommend that you use the FQDN
decnet.jfcl.com instead. I've already updated the latter to point to the
new IP.
A few of you with passive, listen, connections on your end and who aren't
checking the source IP don't actually need to do anything. The new A2RTR
will just connect to you as before and you won't notice a difference.
Those who have active connections to A2RTR, or who have some kind of
source IP based filtering in place, will need to update the IP for A2RTR.
Once again, I really suggest that you use decnet.jfcl.com if at all
possible, but if not then the new IP is 35.82.76.235.
Bob
After I put the changes into Tops-20 Kermit to recognize Ultrix and
properly check protocol, I finally got around to testing it against few
hosts on HECnet. As I had dimly recalled from the late 1980's, Ultrix
supports Tops-10/Tops-20 NRT, viz:
Kermit-20>c nofar/st
[Remote system *NOFAR*:: is running _ULTRIX-32_]
[KERMIT-20: Connecting to DECnet node NOFAR::]
and also:
Kermit-20>c ostara/stay
[Remote system *OSTARA*:: is running _ULTRIX-32_]
[KERMIT-20: Connecting to DECnet node OSTARA::]
Sure made my day!
When I finish wringing some more bugs out of Kermit-20 (I'm redoing the
parity routines to use string instructions), I'll see about testing
against Ultrix in addition to Tops-10 and older versions of Tops-20
Kermit (I've got them going back to the 1980's)
SETHOST currently cannot connect to these hosts as it reports incorrect
configuration messages. That's probably an easy enough fix.
I recently added HDLC framing support to the DUP11 and DPV11 devices in
open_simh. This has only so far been tested with DECnet-Plus on VMS.
I wrote up another couple of examples, showing how to use HDLC as a DECnet
datalink, and also how to try a basic configuration of VAX P.S.I. for X.25
communication.
They're here: https://notlikethatlikethis.blogspot.com/
Paul (or anybody) - has the -daemon (aka "-d") option been removed from
pyDECnet v596? It's still listed in the doc files, but running it gives
pydecnet: error: unrecognized arguments: --daemon
Bob
In my changes to Kermit-20 and SETHOST, I check the configuration byte
to make sure that I'm communicating with either a Tops-10 or Tops-20
system. If it's not one of those, then I want to give a nifty,
informative error message, such as:
Kermit-20>connect APOLLO::
?VMS type systems do not support Tops-10/20 NRT communications.
Kermit-20>connect MIM::
?RSX-11M type systems do not support Tops-10/20 NRT communications.
Kermit-20>connect TRON::
?RSTS/E type systems do not support Tops-10/20 NRT communications.
Pretty nifty. I do this by doing a lookup into a handy table, indexed
by the OS type, viz:
hsttyp: eascii <RSTS>Â Â Â Â Â Â Â Â Â Â ;^d0
       eascii <RT-11>         ;^d1
       eascii <RSTS/E>        ;^d2
       eascii <RSX-11S>       ;^d3
       eascii <RSX-11M>       ;^d4
       eascii <RSX-11D>       ;^d5
       eascii <IAS>           ;^d6
       eascii <VMS>           ;^d7
       eascii <TOPS-20>       ;^d8 (TOPS20)
       eascii <TOPS-10>       ;^d9 (TOPS10)
       eascii <RTS-8>         ;^d10
       eascii <OS-8>          ;^d11 (!!)
       eascii <RSX-11M+>      ;^d12
       eascii <MCB>           ;^d13 (the DN20!!)
hsttyn=.-hsttyp-1Â Â Â Â Â Â Â Â Â Â Â Â Â Â ; Number of defined operating system
types
So if the number I get is outside of this range, I give an unknown
error, such as:
Kermit-20>connect ZITI::
?Remote system sent an illegal configuration message
ZITI:: shows as a Linux system. Does anyone know what its configuration
byte would be? How about Windows? Ultrix? Any others?
I don't recall whether we used NRT or CTERM to get into our Ultrix
machine (it was an 8650, consequently upgraded to an 8700). I think we
used TCP/IP TELNET.
Hey Johnny, I recently installed DECmail-11 on RSTS the other evening, and
I'm noticing some undesirable behavior with the mim.stupi.net email gateway
going out from inside HECnet.
Firstly, it's worth mentioning that gmail won't accept a recipient address
with colons in it, unless you put double quotes around it.
For example:
MARDUK::PHIBER@mim.stupi.net
...won't be accepted as a recipient, and the message is immediately
red-flagged in gmail.
However, if you do the following:
"MARDUK::PHIBER"@mim.stupi.net
...gmail accepts and delivers it, MIM relays it correctly, and I receive
the email in RSTS. Nice.
Unfortunately, the reverse is failing. If I respond or send mail out from
DECmail, mim.stupi.net's sender address rules reject the message:
This is Postmaster <MIM::POSTMASTER> at MIM::.
I'm sorry, but I could not deliver your mail.
An error occured while trying to send it, and I cannot recover.
Orignal recipient was "PHIBER(a)PHIBER.COM"
Actual error is: Fatal address error.
Additional information:
5.1.7 The sender address <MARDUK::PHIBER@mim.stupi.net> is not a valid
5.1.7 RFC-5321 address. h19-20020a05651c125300b0025e725ef592si33185ljh.300
- gsm
tp
Please let us know if you can correct the sender address restrictions on
mim. I tried with quotes, but that didn't help either. :)
Thanks,
Mark
Hi Jordi, I've been using your BITXOZ as my DECdns HECNET nodename
resolution server for OpenVMS for at least eight years (since you put it
up), but it seems that area 7 went offline fairly recently. Is everything
ok?
Regards,
-Mark
On Sat, Apr 26, 2014 at 2:56 PM Jordi Guillaumes i Pons <
jg(a)jordi.guillaumes.name> wrote:
> Hello,
>
> I'm playing again a little bit with DECNET/OSI. Does anybody have the X500
> directory server install kit at hand? The PAKs are included in the hobbyist
> set, but the CSD I have is the 1992 one so I guess there has to be a more
> recent one (for VAX, by the way). The DECDns stuff changed from 6.X to 7.X
> so I'm pretty sure the version I have in my CDs won't work.
>
> By the way, BITXOZ is configured as a DECDns server, and "owns" the
> HECNET: namespace. All HECNET nodes are loaded in the form HECNET:.NAME. I
> toyed previously with a schema like HECNET:.AREAn.NAME but I have ditched
> it. My internet domain (jguillaumes.dyndns.org or jordi.guillaumes.name)
> has also opened the access to BITXOZ via rfc1006, so anyone with a
> DECNET/OSI stack shoud be able to do a $SET HOST jguillaumes.dyndns.org
> or a $DIR/APP=FTAM jguillaumes.dyndns.org:: and access that system even
> without a working HECNET link.
>
> Jordi Guillaumes i Pons
> jg(a)jordi.guillaumes.name
> HECnet: BITXOV::JGUILLAUMES
>
>
>
>
>