- Сетевой интерфейс перестает отвечать,
 Etch, 18:05 , 01-Окт-15 (1)Похоже на конфликт адресов IP. Ищи кто ещё в сети занял этот адрес.
arp -an |grep 192.168.0.1
tcpdump -n 'arp and host 192.168.57.5'
- Сетевой интерфейс перестает отвечать, Etch, 18:06 , 01-Окт-15 (2)
Тьфу,
arp -an |grep 192.168.57.5 конечно же
- Сетевой интерфейс перестает отвечать, eRIC, 06:48 , 02-Окт-15 (5)
> Тьфу,
> arp -an |grep 192.168.57.5 конечно же настроить arpwatch на сервере и не парится каждый раз поиском
- Сетевой интерфейс перестает отвечать, brf, 09:47 , 02-Окт-15 (8)
Пока увы все работает. Как можно выставить оповещение, что сдохло?
По почте, например?
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, 23:24 , 15-Окт-15 (13)
> Пока увы все работает. Как можно выставить оповещение, что сдохло?
> По почте, например?
> 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 не упоминается.
Но что-то его сломало.
Все, ушел домой
- Сетевой интерфейс перестает отвечать, Дядя_Федор, 22:39 , 01-Окт-15 (3)
Посмотрите, что выдаёт dmesg - возможно, в нём причины появляются. ethtool на интерфейс посмотреть в части статистики (-s или -S не помню точно, а смотреть лень, сами посмотрите). ifconfig на интерфейс может чего кажет. Ну и порт свича на самом свиче в логах тоже посмотрите - вдруг увидите. grep eth /var/logmessages тоже. Это так - навскидку.
- Сетевой интерфейс перестает отвечать, brf, 09:30 , 02-Окт-15 (6)
Сейчас все нормально. Никаих ошибок нет
Вчера вечером вручную 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, 06:47 , 02-Окт-15 (4)
>Пробовал поднять этот же ip на другое гнездо eth1 - проблема переходит и на него.
>В логах пусто, ругани нет. Только ПО другого сервера начинает ругаться на потерю связи.если судить проблема в IP адресе 192.168.57.5, то как тогда работает то что вы описали ниже: >Кластерное ПО перевел на eth0, работает, пока. так получается гнездо меняли на соседнем компе где работает кластерное ПО, так? так может дело в этом гнезде на этом сервере или настройки замутили что мол он лишнее/некорректно/не туда обращается что выдает связь потерена
- Сетевой интерфейс перестает отвечать, brf, 09:35 , 02-Окт-15 (7) –1
>>Пробовал поднять этот же ip на другое гнездо eth1 - проблема переходит и на него.
>>В логах пусто, ругани нет. Только ПО другого сервера начинает ругаться на потерю связи.
> если судить проблема в IP адресе 192.168.57.5, то как тогда работает то
> что вы описали ниже:
>>Кластерное ПО перевел на eth0, работает, пока.
> так получается гнездо меняли на соседнем компе где работает кластерное ПО, так?
> так может дело в этом гнезде на этом сервере или настройки
> замутили что мол он лишнее/некорректно/не туда обращается что выдает связь потерена Не знаю как точнее объяснить.
Два сервера общаются по прямому проводу по интерфейсам eth2.
Гнездо менял на сервере, который перестает отвечать на запросы.
Перенес адрес на eth1, загасив eth2. Сначала eth1 отвечал, а через 2 часа тоже перестал .
- Сетевой интерфейс перестает отвечать, Etch, 19:14 , 02-Окт-15 (9)
> Два сервера общаются по прямому проводу по интерфейсам eth2.
> Гнездо менял на сервере, который перестает отвечать на запросы.
> Перенес адрес на eth1, загасив eth2. Сначала eth1 отвечал, а через 2
> часа тоже перестал .А может с проводом что-то не то? Или я что-то не догоняю - второй сервер перестаёт отвечать на запросы, но первый с ему отвечает? Нарисуйте схему сети, там колец нет случайно?
- Сетевой интерфейс перестает отвечать, eRIC, 20:52 , 02-Окт-15 (10)
> Не знаю как точнее объяснить.
> Два сервера общаются по прямому проводу по интерфейсам eth2.
> Гнездо менял на сервере, который перестает отвечать на запросы.
> Перенес адрес на eth1, загасив eth2. Сначала eth1 отвечал, а через 2
> часа тоже перестал .если между двумя сервера один кабель и через некоторое время теряетс коннект между ними, то такое подозрение что эфир засоряется. если даже на другие интерфейсы повесить кабель и такой же эффект. как часто идет обращение между серверами?
- Сетевой интерфейс перестает отвечать, fail, 22:41 , 02-Окт-15 (11)
>[оверквотинг удален]
> 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, 11:09 , 18-Окт-15 (14)
>[оверквотинг удален]
>> Спеца по линуксу у нас нет.
>> На сервере подняты 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, 21:37 , 18-Окт-15 (15)
Согласен, перемудрил.
Экспериментировал с адресами и не вернул взад.
Поздно уже было.
Понятно только одно - что-то "экранирует" этот интерфейс от внешних запросов.
При загрузке сервера сначала он отвечал на пинги, а потом перестал.
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, 10:16 , 19-Окт-15 (16)
Посмотрите на сервере-соседе (при помощи tcpdump), приходит ли от Вашего "проблемного" сервера хоть что-то (например, ответы на броадкасты).
Посмотрите на сервере-соседе вывод arp -na в момент, когда сервер сбоит. Нет ли мака Вашего "проблемного" сервера в каком-то другом сегменте.
- Сетевой интерфейс перестает отвечать, fantom, 07:47 , 22-Окт-15 (17)
> Посмотрите на сервере-соседе (при помощи tcpdump), приходит ли от Вашего "проблемного"
> сервера хоть что-то (например, ответы на броадкасты).
> Посмотрите на сервере-соседе вывод arp -na в момент, когда сервер сбоит. Нет
> ли мака Вашего "проблемного" сервера в каком-то другом сегменте.Очень кстати дельный совет - запускаете на обоих серверах tcpdump на соотв интерфейсе и наблюдаете - ушло-пришло, пришло-ушло.
И порядок с маками интерфейсами адресами хоть какой-то навести.... т.к. отсутствие системности в представляемых вами данных ставит под сомнение правильность выданных вам рекомендаций. О как завернул :)
- Сетевой интерфейс перестает отвечать, brf, 13:07 , 28-Окт-15 (18)
И снова Здравствуйте!Случайно обнаружил, что все-таки в памяти обрубающего коннекции сервера есть 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, 18:38 , 28-Окт-15 (19)
iptables - не демон (это несколько модулей ядра), их не посмотришь ps-ом. В момент, когда сервер перестает отвечать сделайте:iptables -X
iptables -F Так Вы полностью сбросите все файрвольные правила, которые могли там быть. Если после этого сервер продолжает "не отвечать", дело не в iptables
- Сетевой интерфейс перестает отвечать, brf, 19:24 , 28-Окт-15 (20)
Спасибо!
Выполнил команды на всякий случай.
Вот еще что нашлось в логах обоих серверов.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, 07:05 , 29-Окт-15 (21)
>[оверквотинг удален]
> 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, 09:49 , 29-Окт-15 (22)
Пробовал.
Но поймать ничего не смог.
Сейчас инф.обмен через eth2 отключен и все работает через eth0
- Сетевой интерфейс перестает отвечать, brf, 11:44 , 29-Окт-15 (23)
Получается, что на обоих серверах 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, 12:21 , 29-Окт-15 (24)
> Получается, что на обоих серверах iptables запущены и что не так делают?
> делаю стоп, а они снова поднимаются.а зачем вы сервера перезагружаете? > как это отключить навсегда чтобы не мешали? chkconfig iptables off&& chkconfig ip6tables off
ну или в самом нормальном варианте настроить их... а вообще, правильно разобраться с сетью, в куче сообщений так и не увидел ни одного конфига.
как минимум хотелось бы глянуть на интерфейсы (как я понял с прямым линком между серверами)
- Сетевой интерфейс перестает отвечать, brf, 14:03 , 29-Окт-15 (26)
Webmin утверждает, что Они отключены при старте
А вот состояние не показывает
Вручную я делаю стоп, а потом iptables оказывается загружен
Кто так может пакостить?
>[оверквотинг удален]
>> Получается, что на обоих серверах iptables запущены и что не так делают?
> > делаю стоп, а они снова поднимаются.
> а зачем вы сервера перезагружаете?
>> как это отключить навсегда чтобы не мешали?
> chkconfig iptables off&& chkconfig ip6tables off
> ну или в самом нормальном варианте настроить их...
> а вообще, правильно разобраться с сетью, в куче сообщений так и не
> увидел ни одного конфига.
> как минимум хотелось бы глянуть на интерфейсы (как я понял с прямым
> линком между серверами)
- Сетевой интерфейс перестает отвечать, Doka, 11:49 , 30-Окт-15 (27)
у серверов HP отличная аппаратная диагностика.
зайдите на интерфейс управления iLO и посмотрите что там за события.
т.к. сервер работает с 2012 года скорее всего там одна из первых прошивок м.б. стоит обновить.
- Сетевой интерфейс перестает отвечать, сис.админ_23rus, 15:08 , 31-Окт-15 (28)
> Webmin утверждает, что Они отключены при старте через терминал смотрите, кто его знает, может у вас вебмин кривой
- Сетевой интерфейс перестает отвечать, сис.админ_23rus, 15:10 , 31-Окт-15 (29)
>> Webmin утверждает, что Они отключены при старте
> через терминал смотрите, кто его знает, может у вас вебмин кривой. сразу же смотрите chkconfig --list|grep ip
- Сетевой интерфейс перестает отвечать, сис.админ_23rus, 12:29 , 29-Окт-15 (25)
а также если на этих интерфейсах подсеть такая же как на других, то еще и параметры маршрутизации.
- Сетевой интерфейс перестает отвечать, BRF, 16:49 , 02-Ноя-15 (30)
> а также если на этих интерфейсах подсеть такая же как на других,
> то еще и параметры маршрутизации.Здравствуйте!
В пятницу под ночь перегрузил оба сервера.
Сегодня пинги снова не ходили уже на обоих серверах.
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, 21:21 , 02-Ноя-15 (31)
убрал весь листинг прошлого сообщения, вот лично для меня не понятно кто такой *.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, 07:42 , 03-Ноя-15 (32)
>[оверквотинг удален]
> 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 ??? Ваши посты напоминают
"Я и по колесам стучал, и стекло протирал - не помогает...."
|
Версия для распечатки
Сетевой интерфейс перестает отвечать, 
