oscar-cluster / oscar

OSCAR main source repository.
GNU General Public License v2.0
13 stars 2 forks source link

pfilter rejects some traffic thru ethernet bridge interface #129

Open dikim33 opened 8 years ago

dikim33 commented 8 years ago

Reported by mjhsieh on 25 Aug 2005 23:08 UTC

For some reason, I am using an ethernet bridge as the internal 
interface of OSCAR installation. I used several network ports to 
setup this bridge. Theoretically by doing so, the bandwidth 
available for each computing node can increase greatly. However 
current pfilter setting prevent the nodes in one network port of the 
bridge from connecting to other nodes in another network port of 
the bridge.

For the network diagram, please check my blog article at
http://apple.sysbio.info/~mjhsieh/archives/000491.html

To solve this problem, I suggest to modify the script at /opt/oscar/
packages/pfilter/scripts and allow the traffic going through the 
internal interface.

--- post_clients.orig   2005-08-23 20:35:18.000000000 -0700
+++ post_clients        2005-08-23 20:34:44.000000000 -0700
@@ -176,7 +176,7 @@

 # the server and every compute node trust each other

-trusted %oscar_server% %nodes%
+trusted %oscar_server% %nodes% $on_interface
 open    multicast                        # for ganglia

 #
@@ -256,7 +256,7 @@

 # the server and every compute node trust each other

-trusted %oscar_server% %nodes%
+trusted %oscar_server% %nodes% $on_interface

 # let us be pingable from everywhere
dikim33 commented 8 years ago

Comment by mjhsieh on 15 Sep 2005 00:22 UTC


There was a typo in previous patch, The pfileter.conf.clients should not 
be touched. The patch follows is better.
------------- cut here -------------
--- post_clients.orig   2005-08-23 20:35:18.000000000 -0700
+++ post_clients        2005-08-23 20:34:44.000000000 -0700
@@ -176,7 +176,7 @@

 # the server and every compute node trust each other

-trusted %oscar_server% %nodes%
+trusted %oscar_server% %nodes% $on_interface
 open    multicast                        # for ganglia

 #
------------- cut here -------------
dikim33 commented 8 years ago

Comment by mjhsieh on 15 Sep 2005 00:24 UTC


There was a typo in previous patch, The pfileter.conf.clients should not 
be touched. The patch follows is better.
------------- cut here -------------
--- post_clients.orig   2005-08-23 20:35:18.000000000 -0700
+++ post_clients        2005-08-23 20:34:44.000000000 -0700
@@ -176,7 +176,7 @@

 # the server and every compute node trust each other

-trusted %oscar_server% %nodes%
+trusted %oscar_server% %nodes% $on_interface
 open    multicast                        # for ganglia

 #
------------- cut here -------------
dikim33 commented 8 years ago

Comment by efocht on 29 Sep 2005 09:08 UTC


When I try 
trusted %oscar_server% %nodes% on eth0 
pfilter reports an error: 
error - extra/unkown argument(s) <on eth0> for trusted on line 31 
in /etc/pfilter.conf 

This is obviously an illegal argument. How comes this works for 
you? 
dikim33 commented 8 years ago

Comment by mjhsieh on 30 Sep 2005 08:33 UTC


To efocht:
the value of $on_interface won't contain "on " string. 
In your case, if you want to manually specify it to eth0,
you should use:

trusted %oscar_server% %nodes% eth0
dikim33 commented 8 years ago

Comment by efocht on 30 Sep 2005 09:15 UTC


Looking at post_clients I see exactly one place where the 
variable $on_interface gets a reasonable value, and that has the 
form "on   $ENV{OSCAR_HEAD_INTERNAL_INTERFACE}". 

If you use 
trusted ... ... eth0  # without "on" 
you actually disable the firewall on the internal interface. 
For some setups (cluster on separate internal network) this 
makes a lot of sense. For others (no internal network) this is 
almost equivalent to disabling pfilter. Actually then it is sufficient 
to do only: 
trusted eth0 

I'm also having intermitent trouble with pfilter and can't really 
point my finger to the problem. All rejected packages should 
pass according to the rules. 
dikim33 commented 8 years ago

Comment by jparpail on 10 Apr 2007 12:17 UTC Not critical: changing milestone to 5.1. May we redefine this as an enhancement ?

dikim33 commented 8 years ago

Modified by jparpail on 11 Apr 2007 08:24 UTC

dikim33 commented 8 years ago

Modified by valleegr on 30 Jun 2008 06:45 UTC