If your systems have more than one interface then you probably need to tell gmond which interface to bind to by setting the mcast_if option to eth1 in the gmond.conf file. The exact details will vary depending on which version of ganglia you are using, 2.5.x or 3.0.x.
~Jason On Tue, 2005-09-20 at 14:41 +0100, Alex Davies wrote: > Dear All, > > Thank you for your continued support. The firewall is reporting errors > like these: > > iptables: dropped input: IN=eth0 OUT= > MAC=ff:ff:ff:ff:ff:ff:00:e0:81:32:00:1a:08:00 SRC= 0.0.0.0 > DST=255.255.255.255 LEN=42 TOS=0x00 PREC=0x00 TTL=1 ID=62540 PROTO=UDP > SPT=3711 DPT=3711 LEN=22 > > This on all the servers. > > My current firewall, in english, is > * All outgoing traffic allowed > * All incomming traffic on eth1 allowed without going through > firewall > * All incomming traffic on eth0 allowed if it comes from another > cluster node or on a standard port ( e.g. 80; I did try the > gmond ports in here to no avail). > Is there a way of *forcing* gmond to use eth1 for these bizarre > packets which are going out to 255.255.255.255 (which I take it is > part of multicasting since this address does not exist)? > > Failing that, is there a route command I can use to force these > packets out of eth1? > > Falingthat, is there an IP tables command I can use to allow these > packets? (I tried allowing all ports from 0.0.0.0 to no avail). > > Many thanks, > > Alex > > > On 20/09/05, Jason A. Smith <[EMAIL PROTECTED]> wrote: > > If you think it is the iptables firewall that is causing you your > > problems then try turning on logging of dropped/rejected packets to > help > > debug your problem: > > > > iptables -A INPUT -m limit --limit 3/m -j LOG --log-level info \ > > --log-prefix "iptables: dropped input: " > > > > this rule needs to go before the DROP/REJECT rule that is at the end > of > > your INPUT chain, or just at the bottom if you have a default policy > set > > to DROP/REJECT. Then watch /var/log/messages for iptables logs to > see > > what ganglia related traffic is getting blocked. > > > > Also, I assume that you have a rule allowing your gmetad server to > > connect to your cluster, something like: > > > > iptables -A INPUT -p tcp -m state --state NEW -m tcp -s > gmetad.host.ip \ > > --dport 8649 -j ACCEPT > > > > > > ~Jason > > > > > > On Tue, 2005-09-20 at 00:12, Alex Davies wrote: > > > I am afraid that I still experience the complete loss of > monitoring as > > > soon as I start my firewall even with those rules added... > > > > > > I cant seem to find any clear instructions on this, but is there > any > > > way to get each gmond daemon just to collect statistics from its > local > > > host and have one server collect all the xml files every 20 > seconds or > > > so? > > > > > > Many thanks, > > > > > > Alex > > > > > > > > > On 20/09/05, Jason A. Smith < [EMAIL PROTECTED]> wrote: > > > > If your network switches are configured to do igmp, then you > will > > > > probably want to add an iptables rule like this: > > > > > > > > iptables -A INPUT -p igmp -j ACCEPT > > > > > > > > We have iptables configured on all of our systems running > ganglia > > > > without any problems and only have 2 related rules, the igmp one > above > > > > and a multicast rule like this: > > > > > > > > iptables -A INPUT -p udp -m udp -d 239.2.11.71 --dport 8649 -j > ACCEPT > > > > > > > > ~Jason > > > > > > > > > > > > On Mon, 2005-09-19 at 22:47, Alex Davies wrote: > > > > > Dear Mike, > > > > > > > > > > Many thanks for your very fast reply :) > > > > > > > > > > All my nodes are on the same switch, but we are using software > > > > > firewalls. The cluster is trying to use the second ethernet > port which > > > > > is plugged into a dedicated switch, which is "trusted" and > not > > > > > supposed to be firewalled but I have a hunch that the > multicasting > > > > > thing is not going over that port, and I am not sure how to > force it > > > > > to (nor am I sure if it matters). > > > > > > > > > > However, could you confirm how you forced ganglia to use your > tunnel - > > > > > particularly for the multicast packets? > > > > > > > > > > Many thanks, > > > > > > > > > > Alex > > > > > > > > > > On 20/09/05, michael chang <[EMAIL PROTECTED]> wrote: > > > > > > On 9/19/05, Alex Davies < [EMAIL PROTECTED]> wrote: > > > > > > > I have been trying to install ganglia on my 13-node > cluster and had > > > > > > > it all working wonderfully and was amazed how easilly > until I > > > > > > > restarted my firewall :) > > > > > > > > > > > > This is probably impratical, and the worst advice I can give > you, so > > > > > > I'm going to BEG one of the others on the list to come up > with a > > > > > > better answer, but I can tell you that I've got Ganglia > working just > > > > > > fine over a OpenVPN tunnel (provided that peer-to-peer > client > > > > > > communication is online, and the PC hosting the OpenVPN > tunnel is > > > > > > online). Maybe that's something you want...? I doubt it, > but I > > > > > > figured I'd mention it anyways, just in case. > > > > > > > > > > > > I'm wondering, when the firewall restarts, what happens to > the > > > > > > interfaces that Ganglia is multicasting over? Maybe you > need > > > > > > something that automatically restarts ganglia when the > firewall > > > > > > restarts ...? Like I said, someone else probably has a > better answer. > > > > > > > > > > > > My apologies for any unhelpfulnesses. > > > > > > > > > > > > -- > > > > > > ~Mike > > > > > > - Just my two cents > > > > > > - No man is an island, and no man is unable. > > > > > > > > > > > > > > > > > > > > > > > -- > Alex Davies // http://www.davz.net > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the sender immediately by e-mail and delete this e-mail permanently. > > Contact me - MSN: [EMAIL PROTECTED] SKYPE: alex.davies -- /------------------------------------------------------------------\ | Jason A. Smith Email: [EMAIL PROTECTED] | | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 | | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 | | Upton, NY 11973-5000 | \------------------------------------------------------------------/
