I can't talk to SG1 from MIM either, and thus nothing beyond it.
SG1 appears to be down (at least my connection to it isn't working,
either).
And SG1 is currently acting as the next hop for a whole bunch of areas, as
seen from area 1.
Like what? Most of these nodes should have redundant paths (that's good,
remember :-) so it sounds like MIM's routing table is stale.
Somebody really should make a diagram of the HECnet topology...
Bob
On 2011-12-26 15.36, Bob Armstrong wrote:
Unless ROOSTA is an area router, that link makes no sense.
I won't argue with you about that... I can't fix it from here, though.
But does DECnet allow two different area routers, with different subsets of
reachable nodes, for the same area??
Yes, technically nothing will complain. But the network will be broken.
The problem/issue is that all area routers must have direct connections with all other area routers, with no intermediate level 1 routers, since that will cause the area routers to have a broken view of how the universe looks. Area routers share information with all other area routers, using special area routing messages that are sent along the links between the area routers. A level 1 router will not propagate that information, but just discard it, as it is unknown junk to a level 1 router.
I suspect we have a broken setup somewhere...
Johnny
On 2011-12-26 15.24, Johnny Billquist wrote:
On 2011-12-26 15.07, Bob Armstrong wrote:
Hmmm . LEGATO can t talk to ROOSTA ( remote node not currently
reachable ) even though there s a direct Multinet link to ROOSTA (and
yes, the link is UP and working).
I think the problem is that ROOSTA is in area 6, and the area router for
6 is STAR69. Trouble is, STAR69 doesn t have a path to ROOSTA and
doesn t know how to send it packets.
Unless ROOSTA is an area router, that link makes no sense. You cannot
have (usable) links between different areas unless both ends are area
routers...
It would appear something is more broken currently. I can't talk to SG1 from MIM either, and thus nothing beyond it. And SG1 is currently acting as the next hop for a whole bunch of areas, as seen from area 1.
Also, while I'm at it: NIKKEL - There is some issue with that machine too. Can others talk with it?
Johnny
Unless ROOSTA is an area router, that link makes no sense.
I won't argue with you about that... I can't fix it from here, though.
But does DECnet allow two different area routers, with different subsets of
reachable nodes, for the same area??
Bob
On 2011-12-26 15.07, Bob Armstrong wrote:
Hmmm . LEGATO can t talk to ROOSTA ( remote node not currently
reachable ) even though there s a direct Multinet link to ROOSTA (and
yes, the link is UP and working).
I think the problem is that ROOSTA is in area 6, and the area router for
6 is STAR69. Trouble is, STAR69 doesn t have a path to ROOSTA and
doesn t know how to send it packets.
Unless ROOSTA is an area router, that link makes no sense. You cannot have (usable) links between different areas unless both ends are area routers...
Johnny
Do you know which task/object NETPTH tries to talk to? Obviously MIM
don't have one running, but depending on what, it might be something
that I just have not set up. Is NML the object? What is NML?
It sends the same requests that you would send to a another node using NCP
to ask for example about the known circuits.
FWIW, it works for me -
$ ncp tell mim show act cir
Active Circuit Volatile Summary as of 26-DEC-2011 06:18:14
Circuit State Loopback Adjacent
Name Routing Node
UNA-0 on 11.2 (MAISA)
UNA-0 2.1 (LEGATO)
UNA-0 42.1 (CANADA)
UNA-0 1.300 (CTAKAH)
UNA-0 19.41 (SG1)
UNA-0 4.249 (SLAVE)
UNA-0 44.21 (NIKKEL)
UNA-0 1.301 (CTEPBA)
UNA-0 1.350 (ERSATZ)
It's pretty slow, though. Maybe the timeout in NETPTH is too short.
Bob
Do you know which task/object NETPTH tries to talk to? Obviously MIM
don't have one running, but depending on what, it might be something
that I just have not set up. Is NML the object? What is NML?
It sends the same requests that you would send to a another node using
NCP to ask for example about the known circuits.
On Tops10/20 it's a program part of galy "NMLTxx" that the monitor
passes all network management requuests to. The code bliss has traces of
PDP11 stuff, as there was a rs20f phase 3 front-end.
--Peter
!++
! FACILITY: DECnet-10/20 V3.0 Network Management Layer (NML)
!
! ABSTRACT:
!
! This module performs the NML NICE remote request receive
! function.
!
! ENVIRONMENT: TOPS-10/20 & MCB/RSX11 User mode under NML
!
! AUTHOR: Dale C. Gunn , CREATION DATE: 20-Jan-81
!
! MODIFIED BY:
On 2011-12-26 10.07, Peter Lothberg wrote:
I've kept all the Multinet circuits that I had before, and I don't mind
continuing to carry them, although several of them now represent redundant
paths.
Redundancy is good... (as long as managing it cases less network
stability...)
Indeed.
Speaking of which, does DECnet have anything equivalent to the tracert
program ??
..long lines.. So it querries the NML objects to figure out the
topology, and some nodes, like Mim, don't respond. DECnet don't have
TTL expire control messages.
Do you know which task/object NETPTH tries to talk to? Obviously MIM don't have one running, but depending on what, it might be something that I just have not set up. Is NML the object? What is NML?
Otherwise, it should be possible to write something similar on your own, using NICE. For each hop, check what the next hop is for the destination. Should actually be more accurate than traceroute in IP, which don't really neccesarily give the truth, but just what happened for a bunch of packets sent before, all of which might not even have traveled the same path themself.
Johnny
I've kept all the Multinet circuits that I had before, and I don't mind
continuing to carry them, although several of them now represent redundant
paths.
Redundancy is good... (as long as managing it cases less network
stability...)
Speaking of which, does DECnet have anything equivalent to the tracert
program ??
..long lines.. So it querries the NML objects to figure out the
topology, and some nodes, like Mim, don't respond. DECnet don't have
TTL expire control messages.
NETPTH is on the KLAD-pack, but I don't have the sourcves online (or
knew if I have still have them.)
NETPTH>legato
[Routing path from SOL (59.10) to LEGATO (2.1)]
