Operating System - OpenVMS
1748145 Members
3450 Online
108758 Solutions
New Discussion

Re: A question about aliases

 
Brian Reiter
Valued Contributor

A question about aliases

Hi folks,

 

Just a quick question about network aliases. We have a system with a number of network aliases which are used by applications working within different UIC groups - effectively 1 alias per UIC. These applications then proceed to mount a NFS share on a remote Unix server, some of the shares are system wide (root level), at least one share per group is restricted to that group - nominally by defining which IP address can mount that share).

 

The system level mounts work well, all UIC groups can mount then, however the group level mounts after the first are rejected, the Unix host is seeing an incorrect IP address. Is it feasible, at the group UIC level, to decide which active network alias should be used for any kind of network interactions? For example, ensure that mount requests go out for the right IP address (yes I know I'm making a massive assumption). 

 

I know I can fix this on the NFS server but this question may come up again.

 

cheers

 

Brian

11 REPLIES 11
Volker Halle
Honored Contributor

Re: A question about aliases

Brian,

 

it is my understanding, that TCPIP aliases are only used for INCOMING TCPIP connections. An exception may be an application, that is explicitly coded to supply a certain local (alias) address for outgoing connections.

 

I see no way to specify a local IP address as the the source IP address for a TCPIP MOUNT command. The source IP address of the NFS mount request will be the primary IP address of the local host.

 

Volker.

Brian Reiter
Valued Contributor

Re: A question about aliases

Hi Volker,

 

Thats what I suspected, but doesn't seem to tally with what I'm seeing on the NFS server (it sees the first alias - but then again it can't see the primary host address). The server will get amended, I was just curious to see if it was possible to specify the outgoing alias.

 

cheers

 

Brian

Volker Halle
Honored Contributor

Re: A question about aliases

Brian,

 

then this might boil down to the question of ' which source IP address is used for outgoing NFS mounts' ?

 

How do you specifiy those aliases - with explicit $ ifconfig xxx alias a.b.c.d/nn ? Or are you still using the old cluster alias (ucx set conf inter/cluster) ?

 

Volker.

Brian Reiter
Valued Contributor

Re: A question about aliases

Hi Volker,

 

We use the ifconfig method to define multiple aliases. The aliases are moved when the application fails or is stopped.

 

To give some context, we're migrating a number of applications each of which would run on its own single non-clustered node onto a dual node (RX2800) clustered solution. It all seems to work quite nicely with NFS being the only issue (other than application reliance on priv=ALL which has been removed).

 

cheers

 

Brian

Volker Halle
Honored Contributor

Re: A question about aliases

Brain,

 

I would expect the NFS client to use the TCPIP$INET_HOST address for outgoing connections.

 

Volker.

Brian Reiter
Valued Contributor

Re: A question about aliases

Hi Volker,

 

Curious, if wireshark (from a TCPTRACE file) is to be believed then its using one of the alias addresses rather than the acutal hardware address. It looks as though its picked up the first alias which fits the request. The host name address wouldn't fit the request.

 

 

cheers

 

Brian

Volker Halle
Honored Contributor

Re: A question about aliases

Brian,

 

does this also happen with other protocols, e.g. TELNET ? TELNET to another OpenVMS system, then login and check the source IP address with SHO TERM. I would expect to see the primary IP address of your rx2800 as the source address.

 

This is OpenVMS I64 V8.4 and TCPIP V5.7 ECO 2 without the more recent NFS fixes (called "V5.7-ECO2-22011"), right ?

 

Volker.

Brian Reiter
Valued Contributor

Re: A question about aliases

Hi Volker,

 

Yes is OpenVMS 8-4, TCPIP 5-7 ECO2 without the NFS patches. When I log in via an alias address then log onto another OpenVMS system, the IP address in the SHOW TERM doesn;t (in this case) match either the actual host address or the alias address.

 

I haven't done a trace of this yet. At the moment we're going to resolve the NFS issue by use of shared storage (the NFS server doesn't care about the specific NFS mounts, they're only used to store data local to thoe applications.

 

cheers

 

Brian

Hoff
Honored Contributor

Re: A question about aliases

So if I understand this environment, you're connecting to an IP host via a secondary IP address, and appear to be expecting that IP address to be propagated further through the process environment?   That this is an application stacking environment, and there is a need to map NFS shares or other connections to specific processes or process groups.

 

If so, that's not a form of IP mapping that any IP network stack I'm aware of maintains on any operating system platform, outside of guests within a virtual machine implementation, or of OpenVMS Galaxy, or emulation or another analogous operating system encapsulation.  

 

In a non-encapsulated environment, there's no particular relationship between the IP address used for the inbound network "gazinta" and the outbound "gazouta" used for subsequent NFS, telnet, ssh or other IP connections, nor any selection mechanisms for mapping aliases to specific outbound connections.  

 

Beyond support for VMS V8.4 operating as a guest on HP-VM on an HP-UX box (which might be a way to get where you want here), VMS itself doesn't have particular assists for application stacking, nor for sandboxing or related, which means that application "collisions" can arise on IP ports, lock resource names, logical names and similar. 

 

(The IP address selection for outbound connections is technically possible to implement within the socket interfaces, but it's application-specific and AFAIK none of the "standard" network services have implemented that.)

 

If I've misinterpreted what was written and have guessed wrong here (and which is distinctly possible), can you provide some background on the NFS problems you are solving here?

 

--

I'd prototype those NFS patches, too.  ECO2 had some brand-new NFS bits; it was a new-feature release.

 

--

Hello "Your post has been changed because invalid HTML was found in the message body. The invalid HTML has been removed. Please review the message and submit the message when you are satisfied."   Thanks for visiting again.