С чего начать диагностику разрыва сетевого подключения в Debian?

С чего начать диагностику разрыва сетевого подключения в Debian?

У нас есть несколько виртуализированных серверов Xen, все они работают под управлением Debian 6 64bit. У нас периодически возникает проблема, когда сервер иногда перестает отвечать по сети. Когда это происходит, мы не можем пинговать сервер, и наши журналы приложений показывают, что он не может подключиться к другим серверам в сети.

Это произошло с несколькими разными не связанными между собой серверами, и единственными общими факторами являются хост VPS и связанная с ним инфраструктура, ОС и настройки нашей ОС. Я слежу за этим с хостом, но мне действительно нужно докопаться до сути.

На данный момент мне особо нечего сказать. Единственные записи в журнале ОС, которые я смог найти и которые совпадают с событием, это одна строка в системном журнале:

Nov 21 19:36:10 xxxxxx ntpd[2460]: xxxx:4f8:xxx:xxx:1:2:3:4 interface xxxx:7e00::xxxx:91ff:xxxx:1bd4 -> (null)

Однако я думаю, что это результат сбоя сетевого соединения, а не ключ к его причине.

Отчеты MTR с рабочего сервера не показывают ничего полезного.

Так,как мне попытаться понять, что здесь происходит? Есть ли какие-то неизвестные мне сетевые журналы, которые следует проверить?

Спасибо!

решение1

Я предполагаю, что у вас нет доступа к вашему VPS-хосту, и что вы можете отлаживать только изнутри VM. Так что вот что я бы сделал.

Я бы попытался выяснить, где произошел сбой — между виртуальной машиной и хостом, виртуальной машиной и шлюзом или, может быть, где-то в сети вашего провайдера.

Установите скрипт, который будет пинговать ваш первый хоп - т.е. ваш шлюз. Если у вас есть другие виртуальные машины в том же широковещательном домене, вы можете пинговать их вместо GW. Вы можете запустить screen/tmux и оставить ping внутри:

$ ping IP_OF_GW_OR_OTHER_VM | tee -a mytest.log

Если при сбое шлюз все еще работает и пинги проходят, значит, проблема в трубе. В этом случае выполните traceroute и ping следующих 2-3 переходов, пока не выясните, где произошел сбой. Если шлюз сразу же становится недоступным, то, возможно, стоит настроить cron, который сделает снимок сетевой информации при сбое:

ping -c 3 gateway
if [ $? -ne 0 ]; then
   ifconfig eth0 2>&1 >> /tmp/ifconfig-$(date +"%Y-%m-%d_%H:%M").log
   ethtool eth0 >> /tmp/ethtool-$(date +"%Y-%m-%d_%H:%M").log
fi

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

иногда гостевой dhclient теряет соединение или не может продлить аренду, поэтому любая информация, собранная во время сбоя, может помочь.

Связанный контент