On Jun 12, 2009, at 3:56 PM, Ralph Castain wrote:
The firewall should already be solved. Basically, you have to define
a set of ports in your firewall that will let TCP messages pass
through, and then tell OMPI to use those ports for both the TCP BTL
and the OOB.
"ompi_info --params btl tcp" - will tell you the right param to set
for the TCP BTL
"ompi_info --params oob tcp" will do the same for the OOB
Of course, that -does- leave a hole in your firewall that any TCP
message can exploit. :-/ You could look at more secure alternative
ways.
I'm not sure how to solve the NAT problem as it boils down to how to
specify the names/IP addresses of the nodes behind the NAT. Someone
who understands NATs better can help you there - I know there is a
way to do it, but I've never played with it.
This sounds suspiciously like you want to route MPI messages (rather
than just send them peer-to-peer). Be warned that that's somewhat of
a non-trivial exercise...
Alternatively, if you can make outbound connections from behind your
NAT to in front of your NAT, that may work. You'll need to twonk
around in ompi/mca/btl/tcp/ to make that happen. There are likely
ORTE implications as well -- twonking around in ore/mca/oob/tcp/. But
there may be deeper implications than just the connection scheme --
how will you launch the MPI processes, for example?
If you have multiple processes behind multiple different NATs, the
connection scheme will become more complicated -- rendezvous, etc.
--
Jeff Squyres
Cisco Systems
