Сбой в сети Linux: лучшие шаги, чтобы выяснить причину?

Один из наших серверов Linux (CentOS) был недоступен прошлой ночью.

Сервер был недоступен каким-либо образом, кроме удаленной консоли. После входа в систему с удаленной консоли оказалось, что я не могу пропинговать внешние хосты.

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

Могу ли я предпринять какие-либо дополнительные действия, чтобы выяснить причину этой проблемы?

РЕДАКТИРОВАТЬ : это просто случилось снова. Сервер полностью не отвечал, пока я не перезапустил сетевой сервис. Любой совет приветствуется. Может ли это быть вызвано неисправным аппаратным компонентом?

Согласно запросу Madhatters, вот некоторые выдержки из журнала на тот момент (в 20:13 произошел сбой сети):

/ вар / Журнал / сообщения:

Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=100 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:13:34 graviton junglediskserver: Connection to gateway failed: xGatewayTransport - Connection to gateway failed.

Первые три сообщения - это простые ответы на правила iptables, которые я установил через брандмауэр LFD. Последнее сообщение указывает, что JungleDisk, который я использую для резервного копирования, больше не может подключаться к шлюзу. Кроме того, в это время нет интересных сообщений.

РЕДАКТИРОВАТЬ 4 декабря: в соответствии с запросом Mattdm, вот вывод ethtool eth0:

(Обратите внимание, что эти настройки в настоящее время работают . Если что-то пойдет не так, я обязательно опубликую это снова, если это необходимо.

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Согласно запросу Joris, здесь также вывод route -n:

aron@graviton [~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.58    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.42    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.43    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.41    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.46    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.47    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.44    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.45    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.50    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.51    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.48    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.49    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.54    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.52    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.53    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         xx.xx.xx.62    0.0.0.0         UG    0      0        0 eth0

Внизу хх.62 мой шлюз.

РЕДАКТИРОВАТЬ 28 декабря: проблема возникла снова, и я получил возможность сравнить некоторые из результатов вышеупомянутых тестов. Я обнаружил, что он arp -anвозвращает неполный MAC-адрес для моего шлюза (который не находится под моим контролем; сервер находится в общей стойке):

Во время сбоя:

? (xx.xx.xx.62) at <incomplete> on eth0

После service network restart:

? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0

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

чек об оплате

dmesg | lessза все , что связано с вашей сетевой псевдоним (т.е. eht0) как less /var/log/messagesхорошо

Хотя в редких случаях это может быть конфликт IP-адресов, если это произойдет снова, попробуйте

arping -U <gateway ip> -I <nic alias> Однако, проверьте это, так как я давно использовал арпинг, и это может быть неправильно.

В случае успеха вы должны восстановить соединение без перезагрузки сетевого сервиса.

Как вы получаете свой IP-адрес в этой сети (DHCP или статический)? Если это произойдет снова, обязательно запустите, ifconfigчтобы посмотреть на состояние интерфейса, пока он не функционирует. У него есть адрес? Есть ошибки? Если вы запускаете ethtool, есть ли ссылка? (И это согласовано с правильной скоростью и дуплексом?)

Исходя из возникших проблем, я бы очень подозрительно относился к конфликту IP-адресов. Перезапуск сети отправит бесплатный ARP, который снова получит этот IP, что прояснит ситуацию.

Я установил бы arpwatch на другом хосте в том же широковещательном домене (той же сети) и посмотрел, отвечают ли другие машины на запросы ARP для IP вашего сервера. Если это так, выясните, на каком компьютере (возможно, с помощью таблиц MAC-адресов ваших коммутаторов выясните, к какому порту он подключен), и установите для него другой статический адрес или DHCP.

Может быть, пул TCP-соединений переполнен? Что-то открывает все больше и больше соединений, возможно, попытка netstat(попробуйте другие варианты, например -i, чтобы увидеть интерфейсы) дала бы представление об открытии соединения.

Если фактические соединения (и конфигурация iptables / route / what: you_are_using) в порядке, проблема может быть, например, в конфигурации сетевого интерфейса.

Ваш ifconfig -aвывод вменяемый? Этот вывод скажет, если у вас есть какие-то сетевые устройства, которые не должны присутствовать, например, виртуальные устройства, которые вызывают сбои пакетов.

Эта таблица маршрутизации, которую вы вставили, выглядит действительно странно. Работает ли он таким образом и меняется ли после прекращения работы соединения? Если да, что-то вызывает изменение таблицы маршрутизации, возможно, что-то связанное с iptables.

Наконец, особенность CentOS: у вас есть NetworkManager? По какой-то причине он включен по умолчанию в CentOS, даже в виртуальных машинах, у которых нет X, что делает его удвоение соединения, изменения маршрутизации и другие возможности возможными. Я предлагаю отключить его, если вы не знаете, что вам это нужно (например, иметь подключения, которые включаются и выключаются).

Эта проблема была решена довольно давно: проблема, по-видимому, была связана с аппаратным обеспечением.

Новый NIC решил проблему.

Откуда ты тестируешь? Внутри подсети или вне ее? Сколько у вас маршрутов? Автоматический выбор шлюза может привести к непредсказуемым последствиям.

Я не использую RedHat или CentOS, но попробуйте посмотреть, какой скрипт вызывается, когда вы делаете a service network restart. Поскольку ваша сеть возвращается в нормальное состояние, когда что-то в этом скрипте происходит, это может помочь сузить его.

Hhhmm.

Может быть, случайное изменение iptables? Это может объяснить и то, почему это было недоступно, и почему в журналах нет ничего странного (вероятно, вы не регистрируете iptables. Не так ли?)