Mounting share over multiple subnets with CIFS A.09.03

[Bryan Strait]

Hi,

Is it possible to mount a single share of a single host from multple subnets of a single client?

I'm running CIFS client A.09.03 on HPUX 11iv2, on an rx4640 with two Ethernet NICs (one for each subnet). The server is a Windows2003 Server, two Ethernet NICs (one for each subnet.) For network redundancy purposes, we want to have the same share directory mounted to two different directories on the rx4640 using the separate NIC as its interface. The host subnet IPs are both defined in the /etc/hosts file with the same hostname. I've noticed that the CIFS client will only allow me to connect to share of the host using only one of the subnets. When connecting on the alternate subnet, the connection is refused.

I've tried defining using an alternate hostname for each of the subnet IP addresses but that is problematic as well; I'm assuming it has to do with NetBIOS naming since the /etc/hosts hostname must match the actual server's hostname.

I've also tried specifying the server IP address in the server specific fields of the cifsclient.cfg. The cifsclient always connects using the first IP address defined for that host in the /etc/hosts.

Since then, I've been using NFS to connect on the alternate subnet. It works but have realized this is a bad idea since the file permissions and performance are not quite the same.


Has anyone else experienced this? Is it possible to get around it? Will a newer version of the CIFS client work? Is it possible to fool the CIFS client into thinking it is two different hosts without changing the hostname?

Thanks so much. Your input is greatly appreciated.

Bryan

[Eric Raeburn · Accepted solution]

Hello, Bryan,

This is Eric in the HP CIFS Client software lab. You are in unchartered waters here with this use of the Client, however, I have a suggestion that may solve this problem (explained below). I can't promise it will work, but have exchanged email with the original developer of the software and he agrees this is the most promising approach. If any of what follows is unclear or requires further discussion, please file an official HP support call; once these problems hit a certain threshhold of complexity, the IT forum is no longer appropriate or efficient.

First, here is why it is not currently working for you. When you create the first mount, everything works in the expected manner. But when you attempt the second mount, the Client software first checks to see if it is already connected to the server. Because you specify the same server name for both mount requests, the Client's server-connection procedure detects that it is indeed already connected, so it just returns without processing the second request.

Now here is what we think might help. This method goes a step further than your attempt at using "alternate hostname[s] for each of the subnet IP addresses" by resolving your (correct) assumption about NetBIOS-name uniqueness.

(1) Upgrade to the latest CIFS Client, available free at software.hp.com, and set the new configuration parameter smbOverTcp to "yes". With this setting (implemented in version A.02.02), the client connects to the server without doing NetBIOS Session Setup; the server's NetBIOS name is not used.

(2) Ensure there is a valid second DNS name for the server, such that each of its DNS names is associated with a unique IP addresses. You may not need entries in /etc/hosts for the two names because the A.02.xx versions of the CIFS Client have much improved name-resolution capabilities over the A.01.xx version you currently use.

(3) Finally, try the two mounts of the share by using different server names in each mount request.

Please post your results here or call HP support so we can learn from your experience. If you call support, tell them you have already "spoken" to Eric from the CIFS Client lab in this forum.

Note that there could be a subtle performance penalty if this solution works. We can address this further through a support call.

Good luck,
-Eric

[Bryan Strait]

Eric,

Thanks for your timely and very informative reply. I'll try this at the next opportunity which may be a few weeks and will be sure to post the results.

Additional question. Does NetBIOS over TCP/IP produce any noticeable performance overhead over the usual NetBIOS protocol?

Again, thanks so much.

Bryan

[Eric Raeburn]

Bryan,

The short answer is "no": the difference between "traditional" SMB sessions and "netbios-less" SMB sessions is only one client-server packet exchange. The more thorough answer is this:

When a share is mounted by the HP CIFS Client (or mapped to a DOS drive by a Windows client), the following packets are exchanged by the client and server (each of these exchanges consists of exactly two network packets, a client request and the server's reply):

1. TCP Connect
2. NetBIOS Session Setup
3. SMB Negotiate
4. SMB Session Setup for the "NULL" user (a standard initialization procedure)
5. SMB Tree Connect to the IPC$ share (a standard initialization procedure)
6. SMB Session Setup for the actual user (the user is logged into the server) and finally,
7. SMB Tree Connect for the actual share (the share is mapped to a device on the client)

This sequence is followed by any number of SMB packets for file system requests initiated by the client (the user), like directory listings, file-open requests, reads, writes, etc.

Older Windows servers (NT and earlier) will not reply to client SMB requests unless they have successfully completed step 2, NetBIOS Session Setup. Microsoft changed this in Windows 2000. The newer server platforms allow clients to skip this step--once the TCP connection is established they reply to SMB Negotiate, and so on. This is often referred to as SMB-over-TCP, though I think the admittedly more awkward term "netbios-less SMB" is more accurate.

If you use a network tracing tool like Ethereal you can easily see these exchanges on the wire. You may also note that the fout-byte NetBIOS header is still present in all SMBs; only NetBIOS Session Setup is now optional.

So, the only performance difference is that one packet exchange, a matter of a few ten-thousandths of a second on a well-behaved network.

And that's how it works. The default setting of the HP CIFS Client is smbOverTcp = no, to maintain backwards compatability with WinNT servers.

-Eric

[Eric Raeburn]

Bryan,

One other thing. If you have customized the CIFS Client configuration file or use the user-database or mount-database features, then before installing the latest version, please read the chapter on migrating from versions A.01.xx to A.02.xx in the HP CIFS Client Administrator's Guide, here: http://docs.hp.com/en/B8724-90079/B8724-90079.pdf

-Eric

[Bryan Strait]

Eric,

Finally got around to trying the SMB over TCP/IP with the newest CIFS client version A.02.02.01. It works. As hypothisized above, the netbios name returned from the server was failing to authenticate since it differed from the name in the /etc/hosts file. Using SMB over TCP/IP eliminates this check, therefore allowing a successful connection. I can now mount the same server at differing mountpoints.

Thanks again for your help.

Bryan

[Eric Raeburn]

Bryan,

Congratulations. I'm glad this solution worked; it is always good for us to hear about customers' new and inventive uses of the software.

Thanks posting your results.

-Eric