1836987 Members
1989 Online
110111 Solutions
New Discussion

Re: NFS MOUNT

 
SOLVED
Go to solution
ManojK_1
Valued Contributor

NFS MOUNT

I have configured NFS toolkit with SG on my HP rx6600 server. I want to NFS mount this partition in to an another HP Server (rx7640).Both are in different Network segment.In between these segemnt Firewall is there. NFS Server is now having two ips one physical ip and NFS package ip (VIP).Can somebody help me to configure this nfs mount.Please tell me Which all ports has to be opened ? and for which ip Physical ip or Virtual IP?
Thanks and Regards,
Manoj K
4 REPLIES 4
Kevin Wright
Honored Contributor

Re: NFS MOUNT

you will need to open port 2049, 111 tcp, then you'll need to ensure statd,lockd, and mountd are listening on static ports, then open up these 5 ports through the firewall. Depending on what HPUX version you may have, you may need some patches to enable this static binding.

Also, I would assume your NFS toolkit is part of a package with a relocatable IP, therefore you should be using the relocatable IP to connect from all clients.

ManojK_1
Valued Contributor

Re: NFS MOUNT

I am using HP-UX 11.23. I have opened the following ports through firewall 111,2049,49152 >< 65535.I have opened these ports for both the physical IP and Virtual IP(Pkg IP). After that i am able to mount with Physical IP but not with Pkg ip.I have tried with Port fixing also.Still same problem?
Thanks and Regards,
Manoj K
Dave Olker
Neighborhood Moderator
Solution

Re: NFS MOUNT

Hi Manoj,

I would be curious what a network trace of the failing mount looks like when collected on the NFS server. My guess is what you'd see is the mount request comes into the server using the *package* IP address but then is replied to with the *physical* IP address. Some firewalls don't like that or allow it. Perhaps there is a setting on your firewall to permit such traffic...

Some of this behavior (i.e. deciding which IP address to use in outbound packets) is controllable with the ip_strong_es_model tunable:

# ndd -h ip_strong_es_model

ip_strong_es_model:

Controls the requirement issues related to multihoming as
described in RFC1122, Section 3.3.4.2:

(A) A host MAY silently discard an incoming datagram whose
destination address does not correspond to the physical
interface through which it is received.

(B) A host MAY restrict itself to sending (non-source-
routed) IP datagrams only through the physical
interface that corresponds to the IP source address of
the datagrams.

When set to 0, it corresonds to the "Weak ES Model" and would
therefore substitute MUST NOT for MAY in issues (A) and (B).

When set to 1, it corresonds to the "Strong ES Model" and would
therefore substitute MUST for MAY in issues (A) and (B).

When set to 2, substitute MUST NOT for MAY in issue (A) and SHOULD
for MAY in issue (B).

[0,2] Default: 0


If you use ndd to set this value to 2 you *might* get the behavior you're looking for (or rather, your firewall is looking for). This doesn't work in all cases because currently ip_strong_es_model only works for TCP traffic and some of the traffic used for the initial mounting of an NFS filesystem on 11i v2 still uses UDP.

My bet is you would not have this problem if you were using 11i v3. I've seen problems like this in the past and in every case I've tried 11i v3 doesn't experience the problem.

In any case, I'd be curious what a network trace on the server looks like and whether using ip_strong_es_model=2 has any effect.

Regards,

Dave

P.S. I'd definitely recommend fixing the port numbers of lockd/statd/mountd and configuring only those ports in the firewall. Sure beats opening up thousands of ports.


I work at HPE
HPE Support Center offers support for your HPE services and products when and how you need it. Get started with HPE Support Center today.
[Any personal opinions expressed are mine, and not official statements on behalf of Hewlett Packard Enterprise]
Accept or Kudo
ManojK_1
Valued Contributor

Re: NFS MOUNT

The thread is closed by by-passing the firewall.very much thankfull for the knowledge give by Dave olker and Kevin Wright.
Thanks and Regards,
Manoj K