URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 96307
[ Назад ]
Исходное сообщение
"Сетевой интерфейс перестает отвечать"
Отправлено brf , 01-Окт-15 17:45 
Приветствую!

CentOS 6.3 крутится с 2012 года на серваке HP G8.
Никто его не трогал и не подходил, обновлений не ставил и т.д. и т.п.
Его вообще нельзя в рабочее время перегружать - на нем dns, ntp, drweb и pulse.
Спеца по линуксу у нас нет.

На сервере подняты 3 сетевых интерфейса eth0, eth2, eth3.
На интерфейсе eth2 по прямому проводу висит аналогичная машина с программным кластером.
С 24.09.15 интерфейс eth2 начал сбоить - неожиданно перестает отвечать на запросы.
Остальные интерфейсы в другие сети работают нормально.

Делаешь eth2 doun/up, некоторое время работает от 2-х часов до пары дней и снова отвечать перестает. IP-адрес (192.168.57.5) на интерфейсе eth2 висит, запросы с него уходят и ответы на свои запросы он все без потерь принимает. Но сам по неизвестной причине на запросы соседа отвечать перестает. Кластерное ПО перевел на eth0, работает, пока.

Пробовал поднять этот же ip на другое гнездо eth1 - проблема переходит и на него.
В логах пусто, ругани нет. Только ПО другого сервера начинает ругаться на потерю связи.
Кабели менял, ставил разные 3 шт - от них ничего не зависит.
Серверы без iptables. Только dns, ntp, drweb, pulse, ПО и gnome. Ничего лишнего вроде не запущено.

Может кто сталкивался с подобным?
Где искать, копать? Как и чем диагностировать?

Содержание
Сообщения в этом обсуждении
"Сетевой интерфейс перестает отвечать"
Отправлено Etch , 01-Окт-15 18:05 
Похоже на конфликт адресов IP. Ищи кто ещё в сети занял этот адрес.
arp -an |grep 192.168.0.1
tcpdump -n 'arp and host 192.168.57.5'

"Сетевой интерфейс перестает отвечать"
Отправлено Etch , 01-Окт-15 18:06 
Тьфу,
arp -an |grep 192.168.57.5
 конечно же
"Сетевой интерфейс перестает отвечать"
Отправлено eRIC , 02-Окт-15 06:48 
> Тьфу,
> 
arp -an |grep 192.168.57.5
 конечно же

настроить arpwatch на сервере и не парится каждый раз поиском

"Сетевой интерфейс перестает отвечать"
Отправлено brf , 02-Окт-15 09:47 
Пока увы все работает. Как можно выставить оповещение, что сдохло?
По почте, например?
arp сейчас выдал на обоих серверах.
(192.168.57.5) at 2c:76:8a:56:fc:7e [ether] on eth2
(192.168.57.7) at 2c:76:8a:53:f9:3a [ether] on eth2
Все пингуется в обе стороны.
Надо ждать когда сломается.


>> Тьфу,
>> 

arp -an |grep 192.168.57.5
конечно же
> настроить arpwatch на сервере и не парится каждый раз поиском
"Сетевой интерфейс перестает отвечать"
Отправлено BRF , 15-Окт-15 23:24 
> Пока увы все работает. Как можно выставить оповещение, что сдохло?
> По почте, например?
> arp сейчас выдал на обоих серверах.
> (192.168.57.5) at 2c:76:8a:56:fc:7e [ether] on eth2
> (192.168.57.7) at 2c:76:8a:53:f9:3a [ether] on eth2
> Все пингуется в обе стороны.
> Надо ждать когда сломается.

Сломался. Не пингуется.
Сразу при перезагрузке сервака по ребуту.
Вот сосед его пингует
From 192.168.57.3 icmp_seq=196 Destination Host Unreachable
From 192.168.57.3 icmp_seq=197 Destination Host Unreachable
64 bytes from 192.168.57.3: icmp_seq=198 ttl=64 time=1860 ms
64 bytes from 192.168.57.3: icmp_seq=199 ttl=64 time=860 ms
64 bytes from 192.168.57.3: icmp_seq=200 ttl=64 time=0.100 ms
64 bytes from 192.168.57.3: icmp_seq=201 ttl=64 time=0.148 ms
...
64 bytes from 192.168.57.3: icmp_seq=231 ttl=64 time=0.153 ms
64 bytes from 192.168.57.3: icmp_seq=232 ttl=64 time=0.130 ms
64 bytes from 192.168.57.3: icmp_seq=233 ttl=64 time=0.134 ms

И все больше не отвечает.
^C
--- 192.168.57.5 ping statistics ---
260 packets transmitted, 37 received, +126 errors, 85% packet loss, time 259503m                                                                                   rtt min/avg/max/mdev = 0.100/73.653/1860.226/328.793 ms, pipe 3

В общем на запросы больше не отвечает.
А сам соседа пингует
PING 192.168.57.3 (192.168.57.3) 56(84) bytes of data.
64 bytes from 192.168.57.3: icmp_seq=1 ttl=64 time=0.569 ms
64 bytes from 192.168.57.3: icmp_seq=2 ttl=64 time=0.156 ms
64 bytes from 192.168.57.3: icmp_seq=3 ttl=64 time=0.151 ms
64 bytes from 192.168.57.3: icmp_seq=4 ttl=64 time=0.228 ms
64 bytes from 192.168.57.3: icmp_seq=5 ttl=64 time=0.151 ms
64 bytes from 192.168.57.3: icmp_seq=6 ttl=64 time=0.124 ms
64 bytes from 192.168.57.3: icmp_seq=7 ttl=64 time=0.150 ms
64 bytes from 192.168.57.3: icmp_seq=8 ttl=64 time=0.153 ms
64 bytes from 192.168.57.3: icmp_seq=9 ttl=64 time=0.150 ms
^C
--- 192.168.57.3 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8607ms
rtt min/avg/max/mdev = 0.124/0.203/0.569/0.132 ms

В логах ошибок нет. И на интерфейс eth2 сразу уселся демон НТП.

Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address 2c:76:8a:53:f9:3a
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: RXcsums[0] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1]
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: dma_rwctrl[00000001] dma_mask[64-bit]
Oct 15 22:55:31 cgp kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: Link is up at 1000 Mbps, full duplex
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: Flow control is on for TX and on for RX
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: EEE is enabled
Oct 15 22:55:31 cgp kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Oct 15 22:55:59 cgp ntpd[2560]: Listening on interface #7 eth2, 192.168.57.5#123 Enabled

И больше eth2 в messages не упоминается.
Но что-то его сломало.
Все, ушел домой

"Сетевой интерфейс перестает отвечать"
Отправлено Дядя_Федор , 01-Окт-15 22:39 
Посмотрите, что выдаёт dmesg - возможно, в нём причины появляются. ethtool на интерфейс посмотреть в части статистики (-s или -S не помню точно, а смотреть лень, сами посмотрите). ifconfig на интерфейс может чего кажет. Ну и порт свича на самом свиче в логах тоже посмотрите - вдруг увидите. grep eth /var/logmessages тоже. Это так - навскидку.
"Сетевой интерфейс перестает отвечать"
Отправлено brf , 02-Окт-15 09:30 
Сейчас все нормально. Никаих ошибок нет
Вчера вечером вручную down/up. Придется ждать когда отключится.
На обоих серверах
Settings for eth2:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 3
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes


> Посмотрите, что выдаёт dmesg - возможно, в нём причины появляются. ethtool на
> интерфейс посмотреть в части статистики (-s или -S не помню точно,
> а смотреть лень, сами посмотрите). ifconfig на интерфейс может чего кажет.
> Ну и порт свича на самом свиче в логах тоже посмотрите
> - вдруг увидите. grep eth /var/logmessages тоже. Это так - навскидку.

"Сетевой интерфейс перестает отвечать"
Отправлено eRIC , 02-Окт-15 06:47 
>Пробовал поднять этот же ip на другое гнездо eth1 - проблема переходит и на него.
>В логах пусто, ругани нет. Только ПО другого сервера начинает ругаться на потерю связи.

если судить проблема в IP адресе 192.168.57.5, то как тогда работает то что вы описали ниже:

>Кластерное ПО перевел на eth0, работает, пока.

так получается гнездо меняли на соседнем компе где работает кластерное ПО, так? так может дело в этом гнезде на этом сервере или настройки замутили что мол он лишнее/некорректно/не туда обращается что выдает связь потерена

"Сетевой интерфейс перестает отвечать"
Отправлено brf , 02-Окт-15 09:35 
>>Пробовал поднять этот же ip на другое гнездо eth1 - проблема переходит и на него.
>>В логах пусто, ругани нет. Только ПО другого сервера начинает ругаться на потерю связи.
> если судить проблема в IP адресе 192.168.57.5, то как тогда работает то
> что вы описали ниже:
>>Кластерное ПО перевел на eth0, работает, пока.
> так получается гнездо меняли на соседнем компе где работает кластерное ПО, так?
> так может дело в этом гнезде на этом сервере или настройки
> замутили что мол он лишнее/некорректно/не туда обращается что выдает связь потерена

Не знаю как точнее объяснить.
Два сервера общаются по прямому проводу по интерфейсам eth2.
Гнездо менял на сервере, который перестает отвечать на запросы.
Перенес адрес на eth1, загасив eth2. Сначала eth1 отвечал, а через 2 часа тоже перестал .


"Сетевой интерфейс перестает отвечать"
Отправлено Etch , 02-Окт-15 19:14 
> Два сервера общаются по прямому проводу по интерфейсам eth2.
> Гнездо менял на сервере, который перестает отвечать на запросы.
> Перенес адрес на eth1, загасив eth2. Сначала eth1 отвечал, а через 2
> часа тоже перестал .

А может с проводом что-то не то?

Или я что-то не догоняю - второй сервер перестаёт отвечать на запросы, но первый с ему отвечает? Нарисуйте схему сети, там колец нет случайно?

"Сетевой интерфейс перестает отвечать"
Отправлено eRIC , 02-Окт-15 20:52 
> Не знаю как точнее объяснить.
> Два сервера общаются по прямому проводу по интерфейсам eth2.
> Гнездо менял на сервере, который перестает отвечать на запросы.
> Перенес адрес на eth1, загасив eth2. Сначала eth1 отвечал, а через 2
> часа тоже перестал .

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

"Сетевой интерфейс перестает отвечать"
Отправлено fail , 02-Окт-15 22:45 
> если между двумя сервера один кабель и через некоторое время теряетс коннект
> между ними, то такое подозрение что эфир засоряется. если даже на
> другие интерфейсы повесить кабель и такой же эффект. как часто идет
> обращение между серверами?

"меня терзают смутный сомнения" (c)
http://yandex-top-ru.livejournal.com/6712944.html


"Сетевой интерфейс перестает отвечать"
Отправлено fail , 02-Окт-15 22:41 
>[оверквотинг удален]
> CentOS 6.3 крутится с 2012 года на серваке HP G8.
> Никто его не трогал и не подходил, обновлений не ставил и т.д.
> и т.п.
> Его вообще нельзя в рабочее время перегружать - на нем dns, ntp,
> drweb и pulse.
> Спеца по линуксу у нас нет.
> На сервере подняты 3 сетевых интерфейса eth0, eth2, eth3.
> На интерфейсе eth2 по прямому проводу висит аналогичная машина с программным кластером.
> С 24.09.15 интерфейс eth2 начал сбоить - неожиданно перестает отвечать на запросы.
> Остальные интерфейсы в другие сети работают нормально.

ifconfig | grep -I errors
???
если везде кроме RX и TX zero:

то уже навpeное надо идти от железа к софту:
менять кабель, сетевухи, БП, и т.д...

"Сетевой интерфейс перестает отвечать"
Отправлено fantom , 18-Окт-15 11:09 
>[оверквотинг удален]
>> Спеца по линуксу у нас нет.
>> На сервере подняты 3 сетевых интерфейса eth0, eth2, eth3.
>> На интерфейсе eth2 по прямому проводу висит аналогичная машина с программным кластером.
>> С 24.09.15 интерфейс eth2 начал сбоить - неожиданно перестает отвечать на запросы.
>> Остальные интерфейсы в другие сети работают нормально.
> ifconfig | grep -I errors
> ???
> если везде кроме RX и TX zero:
> то уже навpeное надо идти от железа к софту:
> менять кабель, сетевухи, БП, и т.д...

Чот у вас бардак какой-то...
Например для начала возьмем как стартовое состояние:
(192.168.57.5) at 2c:76:8a:56:fc:7e [ether] on eth2
(192.168.57.7) at 2c:76:8a:53:f9:3a [ether] on eth2

Теперь Ваши логи:
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: Tigon3 [partno(629133-001) rev 5719001] (PCI Express) MAC address 2c:76:8a:53:f9:3a
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: attached PHY is 5719C (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[1])
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: RXcsums[0] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1]
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: dma_rwctrl[00000001] dma_mask[64-bit]
Oct 15 22:55:31 cgp kernel: ADDRCONF(NETDEV_UP): eth2: link is not ready
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: Link is up at 1000 Mbps, full duplex
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: Flow control is on for TX and on for RX
Oct 15 22:55:31 cgp kernel: tg3 0000:03:00.2: eth2: EEE is enabled
Oct 15 22:55:31 cgp kernel: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Oct 15 22:55:59 cgp ntpd[2560]: Listening on interface #7 eth2, 192.168.57.5#123 Enabled

Первая строка - MAC address 2c:76:8a:53:f9:3a
Последняя - Listening on interface #7 eth2, 192.168.57.5#
Ну и как сие согласуется с выводом АРП-а???????
Да никак :)
в арпе-то сей мак у 7-ого ИП-а


Теперь дальше - если 2 сервера соединены ПРЯМЫМ ПРОВОДОМ и из вывода АРП-а следует, что ИП-ы там 5 и 7, то откуда там 3-й взялся??

PING 192.168.57.3 (192.168.57.3) 56(84) bytes of data.
64 bytes from 192.168.57.3: icmp_seq=1 ttl=64 time=0.569 ms

Как в той присказке "покажи у веревки три конца"....

Кроме того "кластерное ПО" - это что поподробнее??

"Сетевой интерфейс перестает отвечать"
Отправлено brf , 18-Окт-15 21:37 
Согласен, перемудрил.
Экспериментировал с адресами и не вернул взад.
Поздно уже было.
Понятно только одно - что-то "экранирует" этот интерфейс от внешних запросов.
При загрузке сервера сначала он отвечал на пинги, а потом перестал.
Iptables отключены и не настраивались никогда.

>[оверквотинг удален]
> Ну и как сие согласуется с выводом АРП-а???????
> Да никак :)
> в арпе-то сей мак у 7-ого ИП-а
> Теперь дальше - если 2 сервера соединены ПРЯМЫМ ПРОВОДОМ и из вывода
> АРП-а следует, что ИП-ы там 5 и 7, то откуда там
> 3-й взялся??
> PING 192.168.57.3 (192.168.57.3) 56(84) bytes of data.
> 64 bytes from 192.168.57.3: icmp_seq=1 ttl=64 time=0.569 ms
> Как в той присказке "покажи у веревки три конца"....
> Кроме того "кластерное ПО" - это что поподробнее??

"Сетевой интерфейс перестает отвечать"
Отправлено fa , 19-Окт-15 10:16 
Посмотрите на сервере-соседе (при помощи tcpdump), приходит ли от Вашего "проблемного" сервера хоть что-то (например, ответы на броадкасты).
Посмотрите на сервере-соседе вывод arp -na в момент, когда сервер сбоит. Нет ли мака Вашего "проблемного" сервера в каком-то другом сегменте.
"Сетевой интерфейс перестает отвечать"
Отправлено fantom , 22-Окт-15 07:47 
> Посмотрите на сервере-соседе (при помощи tcpdump), приходит ли от Вашего "проблемного"
> сервера хоть что-то (например, ответы на броадкасты).
> Посмотрите на сервере-соседе вывод arp -na в момент, когда сервер сбоит. Нет
> ли мака Вашего "проблемного" сервера в каком-то другом сегменте.

Очень кстати дельный совет - запускаете на обоих серверах tcpdump на соотв интерфейсе и наблюдаете - ушло-пришло, пришло-ушло.
И порядок с маками интерфейсами адресами хоть какой-то навести.... т.к. отсутствие системности в представляемых вами данных ставит под сомнение правильность выданных вам рекомендаций. О как завернул :)

"Сетевой интерфейс перестает отвечать"
Отправлено brf , 28-Окт-15 13:07 
И снова Здравствуйте!

Случайно обнаружил, что все-таки в памяти обрубающего коннекции сервера есть iptables.
Команда ps -ef|grep iptab ничего не выдает
А вот команда service iptables stop выдала такое
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Unloading modules:                               [  OK  ]

Последующиe запуски service iptables stop ничего не выдают.
Но через некоторое время ситуация повторяется, и снова iptables по этой команде  останавливаются.
С пмщ. webmin прошерстил все настройки загрузки системы и кроны, но запуска iptables не обнаружил.
Точнее запуск disable - во всех режимах запуска rc.d S10network и K92iptables
Поотключал всё лишнее из крона сервера (запускались 0anacron, mcelog и /usr/lib64/sa/sa1 1 1).
Подлость в том, что на обоих серверах настройки эти ИДЕНТИЧНЫЕ, и на втором сервере iptables никогда не поднимается.
Кто из демонов может так пакостить?

[root@ rc.d]# who -r
         run-level 5  2015-10-28 09:48

[root@ rc5.d]# ls
K01numad         K10psacct        K30postfix     K75quota_nld       K88auditd        K99rngd         S13irqbalance   S24named      S26udev-post  S70spice-vdagentd
K01smartd        K10saslauthd     K50dnsmasq     K80kdump           K89rdisc         S01sysstat      S13rpcbind      S24nfslock    S28autofs     S71drweb-monitor
K02avahi-daemon  K15htcacheclean  K50netconsole  K84NetworkManager  K92ip6tables     S06multipathd   S20lldpad       S24rpcgssd    S50mcelogd    S80CommuniGate
K05atd           K15httpd         K60nfs         K84wpa_supplicant  K92iptables      S10network      S21fcoe         S24rpcidmapd  S55sshd       S90crond
K05wdaemon       K16abrt-ccpp     K69rpcsvcgssd  K85mdmonitor       K95cgconfig      S11portreserve  S22fcoe-target  S25netfs      S56xinetd     S99local
K10cups          K16abrtd         K72ipvsadm     K86cgred           K95firstboot     S12rsyslog      S22messagebus   S26acpid      S58ntpd       S99webmin
K10piranha-gui   K16abrt-oops     K75ntpdate     K87restorecond     K99lvm2-monitor  S13cpuspeed     S24drwebd       S26haldaemon  S60pulse
[

"Сетевой интерфейс перестает отвечать"
Отправлено fa , 28-Окт-15 18:38 
iptables - не демон (это несколько модулей ядра), их не посмотришь ps-ом. В момент, когда сервер перестает отвечать сделайте:

iptables -X
iptables -F

Так Вы полностью сбросите все файрвольные правила, которые могли там быть. Если после этого сервер продолжает "не отвечать", дело не в iptables

"Сетевой интерфейс перестает отвечать"
Отправлено brf , 28-Окт-15 19:24 
Спасибо!
Выполнил команды на всякий случай.
Вот еще что нашлось в логах обоих серверов.

messages:Oct 28 12:11:31 srv1 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
messages:Oct 28 12:37:16 srv1 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
messages:Oct 28 18:39:53 srv1 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
messages.4:Sep 30 11:38:49 srv1 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team

messages:Oct 28 12:07:06 srv2 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
messages:Oct 28 12:09:37 srv2 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team
messages:Oct 28 18:40:47 srv2 kernel: ip_tables: (C) 2000-2006 Netfilter Core Team

Webmin (Linux Firewall) на обоих серверах показывает одинаковую картинку
        Action        Condition        Move        Add  
    Accept     If state of connection is ESTABLISHED,RELATED         
    Accept     If protocol is ICMP         
    Accept     If input interface is lo         
    Accept     If protocol is TCP and destination port is 22 and state of connection is NEW         
    Reject     Always

Activate at boot на обоих установлено в No

> iptables - не демон (это несколько модулей ядра), их не посмотришь ps-ом.
> В момент, когда сервер перестает отвечать сделайте:
> iptables -X
> iptables -F
> Так Вы полностью сбросите все файрвольные правила, которые могли там быть. Если
> после этого сервер продолжает "не отвечать", дело не в iptables

"Сетевой интерфейс перестает отвечать"
Отправлено fantom , 29-Окт-15 07:05 
>[оверквотинг удален]
>  Accept  If protocol is TCP and destination port is 22
> and state of connection is NEW
>  Reject  Always
> Activate at boot на обоих установлено в No
>> iptables - не демон (это несколько модулей ядра), их не посмотришь ps-ом.
>> В момент, когда сервер перестает отвечать сделайте:
>> iptables -X
>> iptables -F
>> Так Вы полностью сбросите все файрвольные правила, которые могли там быть. Если
>> после этого сервер продолжает "не отвечать", дело не в iptables

В консоли
iptables -L -v
и/или

service iptables status

и узнаете работает у вас айпитаблес или нет.

кроме того dmesg может показать что-нибудь интересное, что в логи не попало...
И вы таки tcpdump-ом пробовали смотреть что куда уходит-приходит али неть??

"Сетевой интерфейс перестает отвечать"
Отправлено brf , 29-Окт-15 09:49 
Пробовал.
Но поймать ничего не смог.
Сейчас инф.обмен через eth2 отключен и все работает через eth0
"Сетевой интерфейс перестает отвечать"
Отправлено brf , 29-Окт-15 11:44 
Получается, что на обоих серверах iptables запущены и что не так делают?
делаю стоп, а они снова поднимаются.
как это отключить навсегда чтобы не мешали?

service iptables status
Table: nat
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Table: mangle
Chain PREROUTING (policy ACCEPT)
num  target     prot opt source               destination

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
num  target     prot opt source               destination

Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

[root@srv2 etc]# service iptables stop
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: nat mangle filte[  OK  ]
iptables: Unloading modules:                               [  OK  ]


>[оверквотинг удален]
>>> iptables -F
>>> Так Вы полностью сбросите все файрвольные правила, которые могли там быть. Если
>>> после этого сервер продолжает "не отвечать", дело не в iptables
> В консоли
> iptables -L -v
> и/или
> service iptables status
> и узнаете работает у вас айпитаблес или нет.
> кроме того dmesg может показать что-нибудь интересное, что в логи не попало...
> И вы таки tcpdump-ом пробовали смотреть что куда уходит-приходит али неть??

"Сетевой интерфейс перестает отвечать"
Отправлено сис.админ_23rus , 29-Окт-15 12:21 
> Получается, что на обоих серверах iptables запущены и что не так делают?
> делаю стоп, а они снова поднимаются.

а зачем вы сервера перезагружаете?

> как это отключить навсегда чтобы не мешали?

chkconfig iptables off&& chkconfig ip6tables off
ну или в самом нормальном варианте настроить их...

а вообще, правильно разобраться с сетью, в куче сообщений так и не увидел ни одного конфига.
как минимум хотелось бы глянуть на интерфейсы (как я понял с прямым линком между серверами)

"Сетевой интерфейс перестает отвечать"
Отправлено brf , 29-Окт-15 14:03 
Webmin утверждает, что Они отключены при старте
А вот состояние не показывает
Вручную я делаю стоп, а потом iptables оказывается загружен
Кто так может пакостить?


>[оверквотинг удален]
>> Получается, что на обоих серверах iptables запущены и что не так делают?
> > делаю стоп, а они снова поднимаются.
> а зачем вы сервера перезагружаете?
>> как это отключить навсегда чтобы не мешали?
> chkconfig iptables off&& chkconfig ip6tables off
> ну или в самом нормальном варианте настроить их...
> а вообще, правильно разобраться с сетью, в куче сообщений так и не
> увидел ни одного конфига.
> как минимум хотелось бы глянуть на интерфейсы (как я понял с прямым
> линком между серверами)

"Сетевой интерфейс перестает отвечать"
Отправлено Doka , 30-Окт-15 11:49 
у серверов HP отличная аппаратная диагностика.
зайдите на интерфейс управления iLO и посмотрите что там за события.
т.к. сервер работает с 2012 года скорее всего там одна из первых прошивок м.б. стоит обновить.


"Сетевой интерфейс перестает отвечать"
Отправлено сис.админ_23rus , 31-Окт-15 15:08 
> Webmin утверждает, что Они отключены при старте

через терминал смотрите, кто его знает, может у вас вебмин кривой


"Сетевой интерфейс перестает отвечать"
Отправлено сис.админ_23rus , 31-Окт-15 15:10 
>> Webmin утверждает, что Они отключены при старте
> через терминал смотрите, кто его знает, может у вас вебмин кривой. сразу же смотрите chkconfig --list|grep ip
"Сетевой интерфейс перестает отвечать"
Отправлено сис.админ_23rus , 29-Окт-15 12:29 
а также если на этих интерфейсах подсеть такая же как на других, то еще и параметры маршрутизации.
"Сетевой интерфейс перестает отвечать"
Отправлено BRF , 02-Ноя-15 16:49 
> а также если на этих интерфейсах подсеть такая же как на других,
> то еще и параметры маршрутизации.

Здравствуйте!
В пятницу под ночь перегрузил оба сервера.
Сегодня пинги снова не ходили уже на обоих серверах.
TcpDump на обоих пытался найти who-has 192.168.57.1

14:58:40.740280 IP 192.168.57.3 > 192.168.57.2: ICMP echo request, id 8803, seq 69, length 64
14:58:40.740810 ARP, Request who-has 192.168.57.1 tell 192.168.57.2, length 28
14:58:41.740262 IP 192.168.57.3 > 192.168.57.2: ICMP echo request, id 8803, seq 70, length 64
14:58:41.740815 ARP, Request who-has 192.168.57.1 tell 192.168.57.2, length 28

Адрес 192.168.57.1 никак не пинговался на обоих.
Вручную на обоих серверах опустил и поднял интерфейс eth2 - и, о чудо, пинги пошли.

В файле rc.local на обоих серверах прописано следующее
/sbin/ip route add default via 192.168.57.1 table balancer
/sbin/ip rule add from 192.168.57.3 lookup balancer

До опускания интерфейса команда ip route show table balancer на обих серверах выдавала
default via 192.168.57.1 dev eth2

После поднятия интерфейсов команда ip route show table balancer ничего не выдает. Т.е. таблица есть, но пустая.
А пинги идут. TcpDump показал на обоих и запросы и ответы.
16:07:44.920552 IP 192.168.57.3 > 192.168.57.2: ICMP echo request, id 21953, seq 10, length 64
16:07:44.920561 IP 192.168.57.2 > 192.168.57.3: ICMP echo reply, id 21953, seq 10, length 64


Вот сколько это счастье продлится не понятно.
Я уже вообще ничего не понимаю.

Сейчас состояние интерфейсов на обоих:
eth2      Link encap:Ethernet  HWaddr 2C:76:8A:53:F9:3A
          inet addr:192.168.57.2  Bcast:192.168.57.7  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2426 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2435 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:244336 (238.6 KiB)  TX bytes:244912 (239.1 KiB)
          Interrupt:32


eth2      Link encap:Ethernet  HWaddr 2C:76:8A:56:FC:7E
          inet addr:192.168.57.3  Bcast:192.168.57.7  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2429 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2426 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:244528 (238.7 KiB)  TX bytes:244336 (238.6 KiB)
          Interrupt:32

"Сетевой интерфейс перестает отвечать"
Отправлено сис.админ_23rus , 02-Ноя-15 21:21 
убрал весь листинг прошлого сообщения, вот лично для меня не понятно кто такой *.57.1 который у Вас в маршрутизации указан. состояние интерфейсов это конечно хорошо

>Вручную на обоих серверах опустил и поднял интерфейс eth2 - и, о чудо, пинги пошли.
>В файле rc.local на обоих серверах прописано следующее
>/sbin/ip route add default via 192.168.57.1 table balancer
>/sbin/ip rule add from 192.168.57.3 lookup balancer
>До опускания интерфейса команда ip route show table balancer на обих серверах выдавала
>default via 192.168.57.1 dev eth2
>После поднятия интерфейсов команда ip route show table balancer ничего не выдает. Т.е. >таблица есть, но пустая.
>А пинги идут

у Вас при загрузке добавляется правило маршрутизации через этот ip причем с таблицей balancer (его бы еще увидеть, для полноты картины). На сколько я знаю статическая маршрутизация в Centos хранится в /etc/sysconfig/network-scripts/route-<интерфейс> почему используется rc.local не понятно (это просто примичание)

"Сетевой интерфейс перестает отвечать"
Отправлено fantom , 03-Ноя-15 07:42 
>[оверквотинг удален]
>           UP BROADCAST
> RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:2429
> errors:0 dropped:0 overruns:0 frame:0
>           TX packets:2426
> errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:244528
> (238.7 KiB)  TX bytes:244336 (238.6 KiB)
>           Interrupt:32

Мда... вспоминается анекдот
"А вот если бы у рыб была шерсть, то на них водились бы блошки...."

14:58:40.740280 IP 192.168.57.3 > 192.168.57.2: ICMP echo request, id 8803, seq 69,
> length 64
> 14:58:40.740810 ARP, Request who-has 192.168.57.1 tell 192.168.57.2, length 28
> 14:58:41.740262 IP 192.168.57.3 > 192.168.57.2: ICMP echo request, id 8803, seq 70,
> length 64
> 14:58:41.740815 ARP, Request who-has 192.168.57.1 tell 192.168.57.2, length 28
> Адрес 192.168.57.1 никак не пинговался на обоих.

ОТКУДА 3-Й!!!! ИП!!! на шнурке с 2-мя хвостами?????
С какого рожна должен пинговаться 192.168.57.1 ???

Ваши посты напоминают
"Я и по колесам стучал, и стекло протирал - не помогает...."