I guess a number of things might be happening to build the map, then?
1. Johnny's database gets queried for relevant data
2. A DECnet NICE query is sent, yet these data stores do not have
complete information
3. SNMP query
I'm asking this for two reasons.
First, Tops-20 doesn't currently support SNMP.? However, I had actually
architected an SNMP server a few years ago; it would grab various bits
of information via GETAB%, CNFIG% and maybe Galaxy, but would have been
Read-Only.? Investigating a few things I had discerned from Windows and
some embedded devices (Linksys routers and some HP print servers) as
well as reviewing some RFC's, it didn't seem to be that heavy a lift.
I never implemented it because I didn't have any cool management
software to read all of it and display it.? I believe the only stuff I
was aware of were commercial offerings (perhaps Tivoli, which means
"Bring Your Wallet").? Maybe there is something now. Also, Orion
implements a remote (DECnet only) interface for most relevant management
(except shutdown); this could be trivially expanded to handle TCP/IP.?
There was also the matter of security for setting items; I'm barely
started implementing cryptography on the 20.
Second, some issues with MAIL-11 and DECnet SMTP on Tops-20 have caused
me to believe that one solution would be to expand the DNS service
(CHIVES) to handle A and MX records for DECnet.? That's not actually
that big a stretch; the DNS specification has 16 bit data types for
CHAOS, which would be trivially re-usable for Phase IV DECnet.? However,
I'm finding the current documentation to be a chore to wade through.?
The source code incomplete in certain functionality.
Assuming I get this figured out, what I would do is modify SETNOD to
parse a fuller version of Johnny's database.? In addition to building
the binary file for importation into Tops-20's DECnet node name hash
table, it would also build a binary TBLUK% table for use by COMND%
instead of .CMNOD and also a zone file that CHIVES could parse for the
DNS records.
Right now, I'm working on SETHOST, which is a client for the earlier NRT
protocol (Network Remote Terminal) that predates CTERM on the 36 bit
platform.? It's more efficient than CTERM (I have yet to compare it with
LAT) and will do certain things that I like that the Tops-20
implementation of CTERM doesn't.
------------------------------------------------------------------------
On 5/4/20 1:39 PM, Paul Koning wrote:
Nice idea. I can certainly do this. To make it work, the node database would have to
list IP addresses for MIB access.
The fact that the Cisco routers don't speak NICE isn't always a problem. If they
have neighbors that do I still get the information, since I will chart a circuit even if
only one of the two sides tells me about it.
If there is a chain of Cisco routers, the one in the middle of the chain wouldn't be
mapped. But, for example, an area served by a Cisco area router would be, since the
mapper will try to talk to the nodes in the area and ask them what their view of the
neighborhood looks like.
If all I did was a recursive graph walk the Cisco issue would be serious, but that's
not what the code actually does. A closer approximation is a "bulk mail" query
sent to every node in Johnny's database.
paul
> ------------------------------------------------------------------------
> On May 4, 2020, at 1:35 AM, Tim Sneddon <tim at sneddon.id.au> wrote:
> I would definitely be up for that. Maybe "hecnet-ro" for the community
name?
> Regards, Tim.
>> ------------------------------------------------------------------------
>> On Mon, May 4, 2020 at 1:57 AM Peter Lothberg <roll at stupi.com> wrote:
>> The Cisco DECnet router implementation does not speak "decnet
management" as we all knew. The way we are using them the tunnel end-points are on
the Internet.
>>
>> Most of the information "missing" is actually available through the
SNMP MIB, so if we could agree on a common read-only community and publish the IP
addresses of those routers it would be possible to complete Paul's map..