problem with tcpip $qio interface ?

[dschwarz]

We use an Alpha-Cluster with 2 DS20 systems running OpenVMS 8.3 and TCPIP V5.6 - ECO 3.

The machines have 3 NICs, one of them dedicated to cluster traffic.
After setting up the remaining NICs as failover set (lla0) we observe some strange behaviour:
name resolution of nfs, telnetsym and self written software only work with the local host database. Tools like ping are working fine.
Our self written software uses the $qio interface to resolve network names (IO$_ACPCONTROL with INETACP_FUNC$C_GETHOSTBYNAME,..).

A similar configuration running OpenVMS 7.3-2 and TCPIP V5.4 - ECO 7 is working as expected.

Any suggestions?

[Steven Schweda]

> [...] name resolution of nfs, telnetsym and
> self written software only work with the
> local host database. [...]

Which kind of "not work" is this, exactly?

> [...] Tools like ping are working fine.

When you ask them to do what, exactly?

What does nslookup do?

> A similar configuration [...]

With my weak psychic powers, I can't see much
of the configuration of either system.
Actual output from actual commands could be
useful, like, say:

tcpip show name
tcpip show route

[dschwarz]

Hi Steven,

> Which kind of "not work" is this, exactly?
They do not resolve any network name that is not stored in the local host database.

> When you ask them to do what, exactly?
ping mycomputer is working.
ping mycomputer.domain is working.
ftp mycomputer is working.

> What does nslookup do?
nslookup mycomputer is not working.
nslookup mycomputer.domain is working !!!
(default domain and domain path are set correctly).

> Actual output from actual commands could be
> useful, like, say:
> tcpip show name
> tcpip show route


cluster member #1
tcpip show route
DYNAMIC

Type Destination Gateway

AN 0.0.0.0 10.59.81.1
AN 10.59.0.0/16 10.59.50.71
AH 10.59.50.71 10.59.50.71
AH 127.0.0.1 127.0.0.1

tcpip show name
BIND Resolver Parameters

Local domain:

System

State: Started, Enabled

Transport: UDP
Domain:
Retry: 4
Timeout: 2
Servers: ,
Path:
Process

State: Enabled

Transport:
Domain:
Retry:
Timeout:
Servers:
Path:


cluster member #2
tcpip show route
DYNAMIC

Type Destination Gateway

AN 0.0.0.0 10.59.81.1
AN 10.59.0.0/16 10.59.50.72
AH 10.59.50.70 10.59.50.70
AH 10.59.50.72 10.59.50.72
AH 127.0.0.1 127.0.0.1

(member 2)
tcpip show name
BIND Resolver Parameters

Local domain:

System

State: Started, Enabled

Transport: UDP
Domain:
Retry: 4
Timeout: 2
Servers: ,
Path:

Process

State: Enabled

Transport:
Domain:
Retry:
Timeout:
Servers:
Path:

> With my weak psychic powers, I can't see much
> of the configuration of either system.
One cluster consists of 2 DS20 running OVMS 8.3 and TCPIP 5.6 ECO 3, the other cluster consists of 2 DS20 running OVMS 7.3-2 and TCPIP 5.4 ECO 7.
All systems (4 DS20) have 3 NICS, one of them dedicated to cluster traffic, the remaining two NICS configured as failover device LLA0.

The cluster with the older version is working fine, the cluster with 8.3 worked until the day we reconfigured the NICs to a failover set.

[Richard Whalen]

>cluster member #1
>tcpip show route
>DYNAMIC

Means that your system expects to receive information from some other system in order to figure out where to send packets that are addresses to some other system. Is this the same on both systems? If not, then change the non-working system to match the working system.

[dschwarz]

Hi Richard,

this is a copy/paste error.
Both systems are DYNAMIC.

[Richard Whalen]

Can you get a TCPDUMP of UDP port 53 while there is an attempt to resolve names on the system that is having problems? You might have to specify the loopback interface to trace the packets going to the name server on the system.

You might also try changing the non-working system to use the working system for name resolving.

[Robert Gezelter]

dschwarz,

If not TCPDUMP, perhaps trace the actual network using WireShark or similar tool? "Not working" covers a wide variety of potential problems, more data would be (extremely) helpful.

- Bob Gezelter,