Sharing nfs filesystem from Centos 6.10 to HP-UX 11i v1

[Marek_16]

Hi All,

I would like to mount some Centos 6 nfs filesystems on hp-ux 11i v1 box.

I exported a test filesysstem with the following options (from /etc/exports file):

/data2/public 192.168.101.2(rw,sync,no_root_squash,no_subtree_check)

I mounted it on hp box with the following options (from /etc/fstab file):

192.168.101.1:/data2/public /public nfs vers=3,rsize=32768,wsize=32768,suid 0 0

I do can mount filesystem on HP box, but I cannot copy the files from mounted filesystem. Command hangs.

I tried with different rsize/wsize options but it did not work as well.

I can create and edit a test file and save it. This works fine.

I did try mounting hp-ux exported filesystem on linux but the problem remains.

On hp box nfsstat -m shows as follows:

/public from 192.168.101.1:/data2/public (Addr 192.168.101.1)
Flags: vers=3,proto=tcp,auth=unix,hard,intr,link,symlink,devs,rsize=32768,wsize=32768,retrans=5
All: srtt= 0 ( 0ms), dev= 0 ( 0ms), cur= 0 ( 0ms)

Any suggestions on how to troubleshoot this, please?

Best Regards

Marek

[Marek_16]

I have also noticed, that I can copy small files (tested with files less than 1kb), but what is more surprising, I cannot also copy more than about 380kb using ftp or sftp - ftp/sftp then hangs.

Maybe this is not a nfs problem but other one related to some limitations on hp-ux 11.i.

I use hp-ux 11i v1 for 2 days. This is fresh out of a box installation with secure shell installed in addition.

Is there any mechanism on hp side that than limits traffic down to 0 ?

I remember I used 11i v1 about 12 years ago and it worked fine, but I am not sure I used the same release what now (TCOE hp-ux 11i v1 june 2004)

Maybe this will put more light on the problem.

Any thoughts on this?

[Duncan Edmonstone]

I would take a look at the network interface between the HP-UX box and the switch - is it having trouble negotiating to the right speed? You might have to disable auto-negotiation and hard set the NIC speed at both ends - how you do that depends on the NIC and the switch in question

[Bertram Stoeckler]

For NFS, i suggest that you "nail" the read- and write size to 1024.

mount -o rsize=1024,wsize=1024 .....

You can also test "ping" with different packet sizes.

E.g.: "ping NFS-server 4096" will send and recieve a packet of 4k. 

That way you may be able to determine the smallest, working packet size.

Are NFS-client and server connected to the same network switch ?

Apart from a non-negotiated network-speed, also the MTU size could be a problem.

"ifconfig" or "netstat -rn" i think should show you the MTU. 

They should be either the same (1500 for ethernet) on both client and server, or your switch need to be able to handle different MTUs. Maybe the Linux-system uses jumbo-frames, or vice versa.

[Marek_16]

I did some research yesterday. I uninstalled secure shell so now the system configuration is more then less as it was after the installation. I checked mtu and it is set to 1500 on both ends. I tested Linux to Linux nfs connectivity with different Centos 6.10 installation and it works as it should be, however the test was based on nfs ver.4 not ver. 3 as with hp box.

I tested ftp transfer and I was able successfully copy 35MB file several times but in a few cases connection has been reset by HP. It means that I was not able even pinging hp box. I am not sure what does it mean yet - interface was up - I need to work more on this.

Any thoughts on this please?

Best Regards

Marek

[Mani_Np]

Try removing options sync,no_root_squash,no_subtree_check while exporting and you may restrict rw to this particular host if really required.
And then try to mount the filesystem.

Regarding sftp issue, You may need to narrow down the issue with hardware.

HPUX 11iv1 is no more supported, you may please plan for upgrade to HPUX 11.31 which has much more NFS features.

[Bertram Stoeckler]

You obviously have a general networking problem as ftp and NFS are both impacted.

What you should do:

1. If i am not wrong then HPUX has the "landiag" tool that can be used to get Network-Card/driver information including statistics, like dropped packets etc.. Try to find that tool. It comes up with a small menu and there is a "display" command to get LAN-statistics. Check if there are any errors reported. If yes, then your card or network-cable has a problem. Note that there is also a "ppa" command that allows you to change to another interface, if there are more than one installed.

2. It would be good to know how your network topology look like. Are Linux and HPUX-systems connected to the same switch, or are there other switches or routers used? Are the Source and Destination-IP address in the same subnet ?

3. If there are no interface-card errors then at the HPUX-system, run "arp -an", and identify the Linux-server-ip-address. and the reported Link-Level address: e.g. " (10.10.59.173) at 0:30:6e:39:5d:6e ether

4. Verify that the Link-Level address is correct. If both systems are connected via a single switch and if both systems are in the same IP-subnet, then the Link-Level address should be the one of the Linux-interface. If not, then you may have a duplicate IP-address on your network.

[Marek_16]

I have rebuild hp workstation with basic OS installation type + IgniteUX. The problem still exists and if I even can copy/ftp small files performance is very low about 200kb/s. When I lost connection while ftping a file I run a landiag and have seen 256 errors. Then I have changed the switch port where workstation was connected and reattached the cable. I have also reset the card using landiag tool (and cleared the statistics). After this I tried ftping some files and it went very good with good performance. I have tried small and big files - It worked fine.

Here is the output of landiag display command after successful ftping files:

PPA Number = 0
Description = HP PCI 10/100Base-TX Core [100BASE-TX,FD,MANUAL,TT=1500]
Type (value) = ethernet-csmacd(6)
MTU Size = 1500
Speed = 100000000
Station Address = 0x306e2b791f
Administration Status (value) = up(1)
Operation Status (value) = up(1)
Last Change = 445181
Inbound Octets = 113500418
Inbound Unicast Packets = 38028
Inbound Non-Unicast Packets = 41
Inbound Discards = 0
Inbound Errors = 0
Inbound Unknown Protocols = 0
Outbound Octets = 151502
Outbound Unicast Packets = 2376
Outbound Non-Unicast Packets = 0
Outbound Discards = 0
Outbound Errors = 0
Outbound Queue Length = 0
Specific = 655367

There are no errors.

Then I have tried mounting nfs filesystem and copping some files. It worked fine as well. I have copied 100Mb file with very good performance.

I do not know what root cause was but it looks it works fine now. I will reboot the system to check whether it works then as well. I will let you know where I am.

Many thanks for help.

Best Regards

Marek

[Marek_16]

OK, I have a few more details. After powering off and on the system problem reoccurred. Resetting lan0 using landiag tool did not help. Then I have disconnected cable from the switch and connected again to the same port. It helped. Issue disappeared.

I do not know whether this is a network card issue or switch issue. I do not have a spare hp network controller, but I will have a new switch tomorrow, so I will hopefully know something more then.

Any thoughts on this, please?

[Duncan Edmonstone]

Question - are the Linux boxes on the same subnet as the HP-UX boxes, or do they need to travel through a router? Does whatever router the packets hit first after leaving the HP-UX systems (probably the default gateway?) respond to ICMP echo requests (i.e. pings?) HP-UX has a feature called "dead gateway detection" in the IP stack - if a router stops responding to pings, its entry in the routing table is disabled. This will often manifest itself as connections to the HP-UX server working fine at first and then stopping working - pulling the cable causes the interface to be reset so the connections start working again, but then fail again when the pings timeout yet again.

You can test this by turning off dead gateway detection with the following command:

ndd -set /dev/ip ip_ire_gw_probe 0