11 Apr
2023
11 Apr
'23
2:03 a.m.
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.
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.
True. In that case, you get one answer, but there might be another with
the same cost, which you will not find out.
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.
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.
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