Re: [Ganglia-general] Gmond udp_send_channel using the wrong network (seems hostname related)
On Thu, Jun 24, 2010 at 10:21:53AM +, Ronny wrote: I am facing the problem, that my gmond udp_send_channels sends via the wrong network interface on a multi homed linux machine. there is some information on multihomed setups in the README which could help. The machines have a front NIC and an backend NIC. Both IPs from the NICs get resolved by the name service, but the primary IP's dns name is the system's hostname (with an IP address out of 62.48.x.x) In my clients gmond.conf I have set: udp_send_channel { bind_hostname = yes # Highly recommended, soon to be default. # This option tells gmond to use a source address # that resolves to the machine's hostname. Without # this, the metrics may appear to come from any # interface and the DNS names associated with # those IPs will be used to create the RRDs. host = 10.0.11.16 port = 8649 ttl = 1 } whereby 10.0.11.16 is the backend network. But this gmond seems to ignore to use 10.0.11.16 and sends via the primary IP adress 62.48.x.x to the udp_receive_channel locatet on another host. A firewall between send_channel and receiver channel machines using 62.48.x.x is blocking that traffic. I can't currently open the firewall. that is what bind_hostname is meant to do AFAIK, maybe you would like to use instead bind = 10.0.11.16 (host should point to your collector if using unicast, so host and bind should be most of the time different ips in 10.0.11.x unlike this example) Carlo -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Gmond udp_send_channel using the wrong network (seems hostname related)
Sounds to me like your routing is not properly set although apparently that can depend on an OS. More than 4 years ago I reported a bug regarding gmond not honoring mcast_If setting http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=94 We resolved it by adding a route. It would seem that in unicast mode this should require no changes. Can you send us what your routing table looks like ? U Čet, 24. 06. 2010., u 10:21 +, Ronny je napisao/la: I am facing the problem, that my gmond udp_send_channels sends via the wrong network interface on a multi homed linux machine. The machines have a front NIC and an backend NIC. Both IPs from the NICs get resolved by the name service, but the primary IP's dns name is the system's hostname (with an IP address out of 62.48.x.x) In my clients gmond.conf I have set: udp_send_channel { bind_hostname = yes # Highly recommended, soon to be default. # This option tells gmond to use a source address # that resolves to the machine's hostname. Without # this, the metrics may appear to come from any # interface and the DNS names associated with # those IPs will be used to create the RRDs. host = 10.0.11.16 port = 8649 ttl = 1 } whereby 10.0.11.16 is the backend network. But this gmond seems to ignore to use 10.0.11.16 and sends via the primary IP adress 62.48.x.x to the udp_receive_channel locatet on another host. A firewall between send_channel and receiver channel machines using 62.48.x.x is blocking that traffic. I can't currently open the firewall. What should I do to let gmond communicate exclusively via the 10.0.11.x network? I am running ganglia 3.1.7. -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Gmond udp_send_channel using the wrong network (seems hostname related)
On Sat, Jun 26, 2010 at 03:29:17PM -0400, Vladimir Vuksan wrote: More than 4 years ago I reported a bug regarding gmond not honoring mcast_If setting http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=94 mcast_if should be working fine in 3.0 since 3.0.5, could you confirm that? now you should be able to force multicast traffic to go through a specific interface if adding mcast_if into the corresponding udp_send_channel setting. it was broken again though in 3.1 and while it was fixed again for 3.1.2 as shown by BUG140 you would need 3.1.7 for a full fix and set of directives that are meant to help control all parts of functionality including also the IP that would be used as the source (which is what bind and bind_hostname are for) independently of the interface or IPv4 routing. We resolved it by adding a route. It would seem that in unicast mode this should require no changes. Can you send us what your routing table looks like ? unicast could use a different IP as the source if instructed to do so by explicitally binding to it or to the resolvable hostname as it seemed by the original reported configuration. agree though documentation is a little thin around of all it (there is also some complementary explanation in the README) specially with 3.1.7 which has now several overriding settings that affect this (routing, mcast_if, and bind/bind_hostname) Carlo -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general