DECnet "traceroute"

[Chuck Biggs]

Is there anything that will allow me to record the path of DECnet packets as they are routed from one node to another, just like an IP traceroute?

I've got AS 8400s in datacenters in Houston TX and Chandler AZ. DECnet connectivity is handled by Cisco GRE routers over the WAN. I'm starting to have intermittent DECnet connectivity issues *only* between certain nodes.

Error is either a time-out on attempting to make a DECnet connection (SYSTEM-F-UNREACHABLE) or a logical disconnect after a connection is made (REM-F-NETERR).

These are all PhaseV nodes using integrated routing (default) and the Cisco routers have always been working in the past (they support DEC's mechansim of translating 802 protocol format to 60-03 protocol format). I suspect that we have a flaky router but cannot gather enough data to determine where it is.

CDI traces show imediate DNS lookups from a local DEC/DNS server or from cache. I've used NCL> sho rout circ xxx adj * all commands to see all my adjacent DECnet routers on the problem nodes. Those that work have direct adjancy to the core GRE routers. Those that are having difficulty do not. So, again, I suspect a flaky router.

I've also used SDA> net show rout cache command to investigate the phase 5 routers that are being used for successful links by particular problem nodes. And I can DECnet PING from within the GRE routers. But nothing allows me to do an end-to-end DECnet routing trace - that I know of.

I REALLY NEED TO DO THAT to isolate the faulty router.

Any suggestions??

[John Gillings · Accepted solution]

Chuck,

You could try the SHOW PATH command in SYS$UPDATE:DECNET_MIGRATE

DECNET_MIGRATE> SHOW PATH FROM 1.1 TO 2.2

[Wim Van den Wyngaert]

I'm using decnet+ and this doesn't work over here.

Wim

[Ian Miller.]

SHOW PATH fails for me too.
DECNET_MIGRATE> show path to 44.800


Communication open failure
Node: 49::00-2C:AA-00-04-00-20-B3:00 (44.800)
Error: node unreachable

Communication opened
Node: LOCAL:.MCSE07

Path Number 1 (path to last node is not complete)

First node: LOCAL:.MCSE07
Path terminated due to network management protocol error
CMIP error message

[Chuck Biggs]

Good suggestion. The problem is that we use Cisco routers for the GRE DECnet tunnelling over the WAN. They do not talk cmip. That's why it fails for the others who replied. The DECNET_MIGRATE show route to command requires routers that understand cmip.

[Himanshu_3]

Hi Chuck,

I think it also requires DECNET over IP to be enabled on the Cisco routers. In absence of which you would not be able to route DECNET commands over the network.

Regards,
HP

[Wim Van den Wyngaert]

You can trace the route a little bit bia ncl.

mc ncl sho rout cir EWA-0 adj * lan add

This will give you a list of the routers available on the node.
Then you can try the same with option "show node xxx" where node xxx is the node that was the result of the first ncl statement. But my routers refuse to talk with me and thus it doesn't work.

Wim

[Ian Miller.]

the show commands in ncl would require CMIP support on each hop on the path. This not present in the routers in this case.

[Chuck Biggs]

> I think it also requires DECNET over IP
> to be enabled on the Cisco routers. In
> absence of which you would not be able
> to route DECNET commands over the network.

Yes of course, my original post states that we are tunneling DECnet via GRE over the WAN.

> You can trace the route a little bit bia
> ncl sho rout cir EWA-0 adj * lan add

Yes of course, my original posts states that I have already tried that. But the adjacencies are all Cisco routers, not VMS systems.

[Chuck Biggs]

FOUND SOLUTION -

If anyone is interested, you can perform node-to-node DECnet traces (of a sort) using VMS tools.

If you support DEC/DNS, then you are probably familiar with CDI$TRACE. I have used that in this situation to verify that inbound connection attempts are received by the target node and reverse DNS lookups occur (for the back translation).

BUT -

There's another trace utility "trace"

$ trace start/live nsp

Will begin an interactive trace of the transport layer (layer 2) on the node you issued the command.

I issued the command on both source and target nodes, then in another session, simply SET HOST and looked at the trace.

From the trace I could demonstrate that the target node receives Connect Initiate and sends Connect ACK and Connect Connect messages. But those ACKS never get back to the source node who eventually sends a Disconnect Initiate because he thinks nobody is home.

A trace between two nodes that work, shows the source node receiving the ACKS and negotiating a DECnet session.

The traces are too large to paste in here, but they are quite interesting. You must have the rights ID NET$TRACEALL to perform the trace.

$ trace start/live

displays output to the screen.

Without the /live qualifier, it goes to a file that can be edited.

$ trace/live routing

traces the routing layer (layer 3) but be prepared for lots of output. Best send that to a file and search or edit it.


thanx to all who offered advice.


chuck biggs