Один из наших серверов Linux (CentOS) был недоступен прошлой ночью.
Сервер был недоступен никаким образом, кроме удаленной консоли. После входа в систему с удаленной консоли выяснилось, что я также не могу пинговать внешние хосты.
Простой service network restart решил проблему, но мне все еще интересно, чем это могло быть вызвано. Мои файлы журналов, похоже, вообще не указывают на ошибку (за исключением различных демонов, которым требуется сетевое соединение и которые не работают после сбоя сети).
Могу ли я предпринять какие-либо дополнительные шаги, чтобы выяснить причину этой проблемы?
РЕДАКТИРОВАТЬ: это только что случилось снова. Сервер полностью не отвечал, пока я не перезапустил сетевую службу. Любые советы приветствуются. Может ли это быть вызвано неисправным компонентом оборудования?
По запросу Madhatters, вот несколько выдержек из журнала того времени (в 20:13 произошел сбой сети):
/ var / log / messages:
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
По запросу Джориса здесь также выводится 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
Нижний xx.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 для всего, что связано с вашим псевдонимом nic (например, 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 / routes / something: you_are_using) в порядке, проблема может быть, например, в конфигурации сетевого интерфейса.
Ваш ifconfig -a вывод вменяемый? Этот вывод скажет, есть ли у вас какие-то сетевые устройства, которые не должны присутствовать, например виртуальные устройства, которые вызывают сбой пакетов.
Вставленная вами таблица маршрутизации выглядит очень странно. Работает ли в таком состоянии, и меняется ли после того, как соединение перестает работать? Если да, что-то вызывает изменение таблицы маршрутизации, возможно, что-то связано с iptables.
Наконец, специфическая вещь для CentOS: у вас есть NetworkManager? По какой-то причине он включен по умолчанию в CentOS, даже на виртуальных машинах, не имеющих X, что делает возможным дублирование этого соединения, изменение маршрутизации и другие вещи. Я предлагаю выключить его, если вы не знаете, что он вам нужен (например, у вас есть соединения, которые включаются и выключаются).
Эта проблема была решена довольно давно: проблема была явно аппаратная.
Новый сетевой адаптер решил проблему.
Откуда ты тестируешь? Внутри подсети или вне ее? Сколько у вас маршрутов? Автоматический выбор шлюза может делать, казалось бы, непредсказуемые вещи.
Я не использую RedHat или CentOS, но попробуйте посмотреть, какой скрипт вызывается, когда вы делаете service network restart. Поскольку ваша сеть возвращается в нормальное состояние, когда что-то происходит в этом сценарии, это может помочь сузить ее.
Хммм.
Может случайное изменение iptables? Это может объяснить как то, почему он не был доступен, так и почему в журналах нет ничего странного (возможно, вы не регистрируете iptables. Не так ли?)