11 Apr
2023
11 Apr
'23
2:41 a.m.
On 2023-04-11 02:19, Paul Koning wrote:
Excellent. I sometimes use this information when trying to understand
what is going on in HECnet, so this will be of some value.
Hmm. Yeah, not sure I know of any RSTS/E acting as any kind of router.
Maybe someone else knows of one?
As for node type, right. Checked RSX now, and it only reports this for
adjacent nodes. Empty field for others.
But not sure how the mapper would use it. The mapper is talking to each
node anyway, right? And getting type from there.
Or would you use this to not even go talking to endnodes?
True. In that case, you get one answer, but there might be another with the same cost,
which you will not find out.
I should look for it again. That code isn't too easy to grok.
Not sure any hints from the RSX code would help, but let me know if you
want me to dig around.
Yeah. I basically get every node the RSTS/E system knows about, which
obviously are not only adjacent nodes.
Haven't even tried significant nodes... :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Apr 10, 2023, at 8:03 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2023-04-11 01:34, Paul Koning wrote:
Well, next node should really be next node. No matter if that is L1 or L2.
Correct, and it will be when I get my new code published. On Apr
10, 2023, at 6:30 PM, Johnny Billquist <bqt(a)softjar.se> wrote:
Could you tell in detail which NICE messages you are generating?
In general, if I were to do such a tool, I would normally do the NICE message that
generates the same request as NCP SHO NOD do.
...
.ncp tell pyrtr sho nod a2rtr
Node summary as of 11-APR-23 00:27:30
Remote Active Next
Node State Links Delay Circuit Node
2.1023 (A2RTR)
Sadly PYRTR did not actually tell what the next node is here. Not sure if it's just
an old version of PYRTR, or if there is something for Paul to improve. But you should get
the idea...
It's because "show node" looks at the L1 forwarding
tables. That's obviously not the whole answer for an area router. I don't
remember what the Netman spec says. Typically I do what it calls for but this may be an
omission. Then again, even if what I do is compliant it doesn't mean I shouldn't
do better, as RSX does. I checked and
both VMS and RSX certainly tells the next node as you would expect.
Not sure which other type of system I could check this on. I don't think RSTS/E or
TOPS-20 can act as area router. And Cisco don't speak NICE in the first place.
RSTS is L1 only, but my point is that you'd see it if you happen to have a RSTS node
in your path. For HECnet, not all that likely. According to my notes, one RSTS bug is
that it reports node type even if the node isn't adjacent (no idea what it is
reporting in that case) and in addition it encodes that value incorrectly. The mapper
would like to use that data but given that bug it doesn't currently. Also, note
that this will give the forward path, which in DECnet most certainly might be different
than the return path...
And more precisely, it gives one forward path; if a router
does path splitting that isn't represented in the data you get back. One small issue, more for the HECnet mapper than
for a traceroute service: RSTS nodes get some of this stuff wrong. I annotated some of it
in the mapper code. I think next node may not come back all the time, and I know for sure
that adjacent node type is encoded incorrectly.
Maybe time for you to fix that too? :-) Anyway,
looking at a remote RSTS/E node from MIM:
.ncp tell pirsts sho exec
Node summary as of 11-APR-23 02:01:42
Executor node = 29.205 (PIRSTS)
State = On, Identification = DECnet/E V4.1
Active links = 1
.ncp tell pirsts sho nod mim
Node summary as of 11-APR-23 02:01:20
Remote Active Next
Node State Links Delay Circuit Node
1.13 (MIM) 1 5 QNA-0 29.206 (ONAPI4)
So it do look like the next node info is good there too.
And I've also looked at TOPS-20 machines, and it looks good on those too.
But yeah, adjacent node requests to RSTS/E gives back unexpected nodes.
You mean "show adjacent nodes"? Right, I noted that as another bug. I
don't even want to imagine what it does about "significant nodes", one of
the more obscure NICE features.