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.
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.
paul