If you want your routing changes to take affect each time you boot then
you can add them to the /etc/sysconfig/static-routes config file (at
least for RedHat Linux systems where this file is read by the network
init script), which in your case would look something like this:

any -net 239.2.11.71 netmask 255.255.255.255 dev eth1
any -net 255.255.255.255 netmask 255.255.255.255 dev eth1

~Jason


On Tue, 2005-09-20 at 15:28 +0100, Alex Davies wrote:
> Dear Jason,
> 
> The following two commands appear to have fixed it:
> 
> route add -net 239.2.11.71 netmask 255.255.255.255 dev eth1
> route add -net 255.255.255.255 netmask 255.255.255.255 dev eth1
> 
> However I can not work out how to get these to "stick" after a reboot
> (apart from writing an init script to execute the above two commands
> which appears a little messy). Is there a common way to do this? 
> 
> I have also not tried to reboot the master server just yet but hope
> that it will continue to work!
> 
> If anyone finds this thread, in addition to the two commands above I
> also added the following to /etc/gmond.conf on all nodes: 
> 
> udp_send_channel {
>   mcast_join = 239.2.11.71
>   mcast_if = eth1
>   port = 8649
> }
> 
> With many thanks for all your help,
> 
> Alex
> 
> 
> On 20/09/05, Jason A. Smith <[EMAIL PROTECTED]> wrote:
>         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                                            | 
>         \------------------------------------------------------------------/
>         
>         
> 
> 
> 
> -- 
> 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                                            |
\------------------------------------------------------------------/



Reply via email to