[Gluster-users] Gluster 3.3.0 doesn't see neighbour

[Vladimir Yakovlev]

Hi Philip,

I tried IPs instead of hostnames at the beginning, but it didn't help:

[root at host1 ~]# gluster peer probe 192.168.1.193
Probe on localhost not needed

My assumption is smth wrong smwhere else. Donno where - no ideas at all;
the worst is i have a set of test machines, where everything works
perfectly... :(

There are two switches between these machines, but they allow Gluster
traffic responsively.

Hope, we can struggle this together ;-)

Thanks, guys, for quick responses.

Regards,
vy

On Mon, Jul 2, 2012 at 6:27 PM, Philip Poten <philip.poten at gmail.com> wrote:

> Hi Vladimir
>
> To circumvent any remaining /etc/hosts abnormalities, try with IPs
> only. if that doesn't work either, you have a problem outside name
> resolution. If it works with IPs, the problem is the resolver.
>
> Note that nscd caches answers, also the "host" command uses DNS
> responses, /not/ the /etc/hosts (nsswitch.conf order resp.) file - but
> gluster does, as does "ping" and anything else using gethostbyname(3)
>
> hth,
> Philip
>
> 2012/7/2 Vladimir Yakovlev <mrquesty at gmail.com>:
> > Thanks, Brian, for the hint.
> > I've changed /etc/hosts with respect to your comment, but it didn't help
> > either.
> >
> > The problem (from my perspective) in smth else, e.g. why, when I try to
> do
> > the following, I see the blank response in tcpdump:
> > [root at host1 ~]# ip a
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> >     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> >     inet 127.0.0.1/8 scope host lo
> > 2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast
> state
> > DOWN qlen 1000
> >     link/ether 00:25:90:30:34:42 brd ff:ff:ff:ff:ff:ff
> >     inet 46.../27 brd 46.182.25.159 scope global eth0
> > 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state
> > UP qlen 1000
> >     link/ether 00:25:90:30:34:43 brd ff:ff:ff:ff:ff:ff
> >     inet 192.168.1.192/24 brd 192.168.1.255 scope global eth1
> > [root at host1 ~]# tcpdump -i eth1 'port 27004'
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> > listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
> > ^Z
> > [2]+  Stopped                 tcpdump -i eth1 'port 27004'
> > [root at host1 ~]# bg
> > [2]+ tcpdump -i eth1 'port 27004' &
> >
> > [root at host1 ~]# gluster peer probe host2
> > Probe on localhost not needed
> > [root at host1 ~]# fg
> > tcpdump -i eth1 'port 27004'
> > ^C
> > 0 packets captured
> > 117 packets received by filter
> > 52 packets dropped by kernel
> >
> > So (by whatever reason) Gluster doesn't send a packet to anywhere through
> > ethernet.
> >
> > Guys, any ideas?
> >
> > Thanks,
> > BR,
> > vy
> >
> >
> > On Mon, Jul 2, 2012 at 6:06 PM, Brian Candler <B.Candler at pobox.com>
> wrote:
> >>
> >> On Mon, Jul 02, 2012 at 05:54:46PM +0400, Vladimir Yakovlev wrote:
> >> >    I tried different configurations, the latest follows:
> >> >    [root at host1 ~]# cat /etc/hosts
> >> >    127.0.0.1   localhost localhost.localdomain localhost4
> >> >    localhost4.localdomain4
> >> >    127.0.0.1   host1 host1.fqdn
> >> >    192.168.1.193   host2 host2.fqdn
> >> >    [root at host2 ~]# cat /etc/hosts
> >> >    127.0.0.1   localhost localhost.localdomain localhost4
> >> >    localhost4.localdomain4
> >> >    127.0.0.1   host2 host2.fqdn
> >> >    192.168.1.192   host1 host1.fqdn
> >>
> >> Be consistent. Both machines should have:
> >>
> >> 127.0.0.1      localhost localhost.localdomain
> >> 192.168.1.192  host1.fqdn host1
> >> 192.168.1.193  host2.fqdn host2
> >>
> >> On host1 you should have "host1.fqdn" in /etc/hostname, and the command
> >> "hostname" should show it. (Ditto for host2, but with "host2.fqdn" of
> >> course)
> >
> >
> >
> > _______________________________________________
> > Gluster-users mailing list
> > Gluster-users at gluster.org
> > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20120702/44ff4a39/attachment.html>