<div dir="ltr">Add a logging rule to your iptables and look at what traffic is actually being blocked?</div><br><div class="gmail_quote"><div dir="ltr">On Wed, May 16, 2018 at 11:11 AM Sean Caron <<a href="mailto:scaron@umich.edu">scaron@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>Does anyone use SLURM in a scenario where there is an iptables firewall on the compute nodes on the same network it uses to communicate with the SLURM controller and DBD machine?</div><div><br></div><div>I have the very basic situation where ...</div><div><br></div><div>1. There is no iptables firewall enabled at all on the SLURM controller/DBD machine.</div><div><br></div><div>2. Compute nodes are set to permit all ports and protocols from the SLURM controller with a rule like:</div><div><br></div><div>-A INPUT -s IP.of.SLURM.controller/32 -j ACCEPT</div><div><br></div><div>If I enable this on the compute nodes, they flap up in down in "Not responding state". If I switch off the firewall on the compute nodes, they work fine.</div><div><br></div><div>When firewall is up on the compute nodes, SLURM controller can ping compute nodes, no problem. I have no reason to believe all ports and protocols are not being passed. Time is synched. No trouble accessing slurm.conf on any of the clients.</div><div><br></div><div>Has anyone seen this before? There seems to be very little information about SLURM's interactions with iptables. I know this is kind of a funky scenario but regulatory requirements have me needing to tighten down our cluster network a little bit. Is this like a latency issue, or ...?</div><div><br></div><div>Thanks,</div><div><br></div><div>Sean</div><div><br></div></div>
</blockquote></div>