11 Apr
2023
11 Apr
'23
2:19 a.m.
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.
paul