src host 192.168.8.110 or dst host 192.168.8.110 эквивалентно host 192.168.8.110

Ну например:

grep -r 192.168.8.39 /etc

Да, похоже на то, что айпишник числится в каком-то блеклисте - нужно смотреть конфиг iptables (iptables -vnL --line-numbers), а также всякие hosts.deny в /etc

.

из всего, что я нашел про 8.39 на сервер 3.54 есть только лог apach:

...
192.168.8.39 - - [26/Jun/2013:00:15:02 +0400] "GET /redmine/javascripts/dragdrop.js?1328527355 HTTP/1.1" 304 210 "http://192.168.3.54/redmine/projects/cyfoman--equipment/files?sort=created_on%3Adesc%2Cfilename" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31"
192.168.8.39 - - [26/Jun/2013:00:15:02 +0400] "GET /redmine/javascripts/controls.js?1328527355 HTTP/1.1" 304 210 "http://192.168.3.54/redmine/projects/cyfoman--equipment/files?sort=created_on%3Adesc%2Cfilename" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31"
192.168.8.39 - - [26/Jun/2013:00:15:02 +0400] "GET /redmine/javascripts/application.js?1328527355 HTTP/1.1" 304 211 "http://192.168.3.54/redmine/projects/cyfoman--equipment/files?sort=created_on%3Adesc%2Cfilename" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31"
192.168.8.39 - - [26/Jun/2013:00:15:02 +0400] "GET /redmine/images/delete.png?1328527355 HTTP/1.1" 304 186 "http://192.168.3.54/redmine/projects/cyfoman--equipment/files?sort=created_on%3Adesc%2Cfilename" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.43 Safari/537.31"

говорит, что с этой машиной работали на сервере далее он «завис» и после перезагрузки стал не доступен с этой машиной.

заработало

при очередной перезагрузки сервака, он стал виден с «больной» машины.

iptables вообще отключен, там ничего нет

В общем осталось чувство неудовлетворенности, т.к. ровно такие «залипухи» случается с этим сервером уже второй раз и временно отвергнутая машинка была из другой сети.

Спасибо, что обратили внимание на мое сообщение.

Ну, в другой раз можно провести более детальную диагностику, начать с tcpdump или iptables -j LOG, там смотреть по обстоятельствам.

снова перестало пинговаться

в общем, картина такая же: несколько минут проработало и перестало.

про то, что выдает tcpdump я писал в исходном посте а с iptables я так понял вы предлагаете сделать цепочку и прогонять по ней общение с 8.39 так?

нет в сети такого же ипа? На сервере один интерфейс?

да не обязательно цепочку, просто поставить пару правил с таргетом LOG и смотреть, где теряется

нет в сети такого же ипа

Кстати, да интересная мысль.

добавил:

пару правил:

root@ubuntu-devcenter2:~# iptables -A INPUT -s 192.168.8.39 -j LOG --log-level INFO --log-prefix "s 8.39"
root@ubuntu-devcenter2:~# iptables -A OUTPUT -d 192.168.8.39 -j LOG --log-level INFO --log-prefix "d 8.39"

смотрю iptables -nvL

после очередной перезагрузки сервер работает:

Chain INPUT (policy ACCEPT 1423 packets, 303K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  158 40819 LOG        all  --  *      *       192.168.8.39         0.0.0.0/0           LOG flags 0 level 6 prefix `s 8.39' 

Chain OUTPUT (policy ACCEPT 1585 packets, 338K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  139 99415 LOG        all  --  *      *       0.0.0.0/0            192.168.8.39        LOG flags 0 level 6 prefix `d 8.39' 

жду пока снова перестанет

Попробуй посмотреть кэш таблицы маршрутизации в момент когда машина не пингуется

route -nC

нет в сети такого же ипа?

вроде нет, все раздается по DHCP.

На сервере один интерфейс?

да, на сервере один интерфейс

нет в сети такого же ипа

Кстати, да интересная мысль.

а как лучше проверить?

наблюдаю за таблицей, есть копии: - после 12 часов работы и когда не пингуется - сразу после перезагрузки - после того как с 8.39 немного поработали с сервером.

Вроде все логично, 8.39 присутствует только в последнем случае.

Я бы посмотрел ещё на ARP таблицы и может быть ARP запросы во время отказа.

Если сервер в одном ethenet сегменте с 192.168.8.110, то, как уже посоветовали, проверьте ARP, в том числе и командой arping. Может 192.168.8.39 не отвечает на ARP-запросы сервера.

.

Спасибо, к сожалению они не в одной сети.

уже сутки работает нормально!!!

Большое спасибо всем, вроде работает уже долго и надежно.

Не понятно, что помогло, но вот, что в итоге было сделано:

1. очистил место на диске, т.к. по ходу выявилась проблема: по данным df -h места дофига, а при upload файлов происходил сбой.

2. включил FireWall, из используемых портов оставил открытыми только те, что используются.

в результате этого, закрытыми оказались 5353, это mDNS и еще какой то «блуждающий» порт (судя по команде netstat -nvl) с номером > 10000, который к java программе вел.

3. запретил TCPv6