DECnet over TCP/IP

[Kjell Carlsson]

We have several Open VMS systems using DECnet over TCP/IP for communication. But one system behaves strange. When using 'set host' from this system the 'show term' command at the target node displays the following info:
Remote Port Info: IP$172.21.06.22::SYSTEM
This results in problems for some applications. The common DNS is OK and declaring the source host in the target local host table doesn't change anything.
Normally the Remote Port Info should be nodename::SYSTEM

I have not found any significant difference in configuration between OK and not OK systems.

Does anyone know anything about this?
Best regards Kjell Carlsson

[Peter Clarke]

If you do a :

$RUN SYS$SYSTEM:NCP
NCP>LIST NODES *

Can you see the node name there??

[Peter Clarke]

Sorry should be :

NCP>LIST NODE *

[Kjell Carlsson]

Peter

No, in the target node I can't see the source node name. The source node is not defined with decnet_register.

Note that we are using DECnet plus over TCP/IP.

Kjell

[Volker Halle]

Kjell,

can you try to compare the CDI trace data on the target node with a SET HOST from a working system ?

$ MC CDI$TRACE ! on the target node

then try SET HOST from a 'working' node to the target node and also from the 'strange' node. Any significant differences ?

You can exit CDI$TRACE with CTRL/Y

Volker.

[Antoniov.]

Hi Kjell,
the differences from other system sound like a wrong rarp (reverse arp). On target system, in TCP/IP can you see the remote host?
For example:
$ TCPIP
SHO HOST
172.21.6.21 nodename21
172.21.6.23 nodename23
I guess you can't see the .22 node but you can see other hosts.

Antonio Vigliotti

[Kjell Carlsson]

Antoniov.
Reverse arp is not the problem. I can see the .22 node.


Volker.
Very interesting trace. I didn't know about it. There is a lot of differences. I have not yet analyzed the result and I attach the log. Mybe you or anyone else has a quick answer.


Best regards
Kjell

[Volker Halle]

Kjell,

just a quick guess:

Node DMXFST is the 'bad' node, right ? Does it have this problem to all your other nodes (e.g. SET HOST xxx from DMXFST always produces a IP$172.21.06.22::SYSTEM remote port name on target node xxx) ?

How about SET HOST IP$target-ip-address from DMXFST - same problem ?

The first lookup is for LOCAL:.DMXFST - from the working node it's for IP$n.n.n.n - this seems to be the major difference at first glance.

Did you compare the output of MC NCL SHO SESS CONT ALL on the node ?

Volker.

[Kjell Carlsson]

Volker

Yes, DMXFST is the bad node and it have the problem to all other nodes.

SET HOST IP$target_ip_address works fine.
I agree, the first lookup for LOCAL:.DMXFST seems to be the problem.

I compared the output of
MC NCL SHO SESS CONT ALL
No difference between bad and good nodes.

Kjell

[Volker Halle]

Kjell,

so if you force DECnet-over-IP, it works. Then it should also work with SET HOST full.target.ip.name

Does SET HOST x.x (Phase IV address of target) still work ? Or NSAP address NET$xxxx (obtain with NCL> SHOW LOCAL NSAP * or SHOW OSI TRANS LOCAL NSAP * on target node) ?

Any difference in DECnet-OSI version and patch level ?

Volker.

[Kjell Carlsson]

Volker

SET HOST full.target.ip.name does not work. Gives the same result as shortname.

SET HOST x.x does not work at all. Only TCP/IP connection between the systems.

There are good systems with exactly the same OS/DECnet versions and ECO as the bad system (V7.3-2).

Kjell

[Volker Halle]

Kjell,

slowly running out of ideas ;-(

Try $ REPLY/ENA=SECURITY on the target node. Do you get backtranslation errors ?

Did you try to flush the CDI cache ( MC NCL FLUSH SESS CONT NAMING CACHE ENTRY "*" ) ?

Any errors in SYS$MANAGER:TCPIP$PWIPACP_AXPVMS.LOG ?

Same TCPIP versions and ECOs ?

What happens on the bad node when you do a SET HOST IP$bad-node-ip ? CDI$TRACE ?

Sorry. No answers, only questions...

Volker.

[Kjell Carlsson]

Volker

1. No backtranslation error
2. Yes flush is done.
3. No errors in TCPIP$PWIPACP_AXPVMS.LOG
4. Yes same versions
5. Not tested

But I have got some idea. Nodnames, DECnet- and IP-addresses are changed for this system. The identity is changed for the system and I have found some rest of the earlier identity. The system must be restarted to activate some changes I have done. But a restart cannot be done right now. Have to wait until next week.

Have a nice weekend.

Kjell

[Ian Miller.]

what are remains of the old addresses?
If you change a node name and address there are several things so change and a useful list can be found in the VMS FAQ.
http://h71000.www7.hp.com/wizard/faq/vmsfaq_008.html#mgmt60

[Kjell Carlsson]

More patches into system