So I was able to resolve this by adding the following to the network's
nat.conf file:
[privilegedTCP]
autodetect = 1
port = 988
That allows traffic bound for port 988 to stay as a low port connection.
For some reason, this is the default configuration (autodetect = 1) on
Windows, but autodetect = 0 (false) is the default on Linux.
Brian, thanks for getting me within jumping distance.
Jim
Brian J. Murrell wrote:
On Tue, 2007-06-12 at 17:16 -0400, Jim McCusker wrote:
No, it's definitely on the host.
Hrm. Yes. This is as I expected. The vmware interface of the host is
doing the NATting. I mean the 192.168.88.2 address is the address of
the guest, not the host.
This seems to be the culprit:
Jun 12 17:00:13 chai kernel: LustreError:
12198:0:(acceptor.c:422:lnet_acceptor()) Refusing connection from
128.36.115.10: insecure port 35203
This is as I was expecting, but hoping it was not. One strategy in
NATting is to only reassign a source port if the port the NATted
connection wants is already being used. If it's not, don't NAT it.
That helps NATted connections look more natural where they can.
Unfortunately it seems VMWare is not employing this technique and is
always NATting ports (assuming you are not using 988 on the host for
anything... do you have a lustre client running there too?)
We seem to be remapping to high ports, a common strategy when using
NAT.
Right.
Is there a way of disabling this check?
Good question. One which I don't know the answer to I'm afraid.
b.
_______________________________________________
Lustre-discuss mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
_______________________________________________
Lustre-discuss mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
