Проблема ARP, случай из жизни

Содержание материала

Звезда не активнаЗвезда не активнаЗвезда не активнаЗвезда не активнаЗвезда не активна
 

Позвонил пользователь и поинтересовался, доступен ли сервер, а затем сообщил о следующей проблеме. Рабочая станция пользователя, limulus, «подвисала» на время до нескольких минут при выполнении определенных команд, тогда как прочие команды работали превосходно.

Проблемы с зависанием вызывали все сетевые команды, задействующие сервер имен NIS, но также и некоторые команды другого рода. Пользователь сообщил, что получает такое сообщение об ошибке:

NFS getattr failed for server crab: RPC: Timed out

Сервер crab предоставляет узлу limulus службы NIS и NFS. Команды, вызвавшие проблемы на узле limulus, требовали доступа к службе NIS, либо к файлам из экспортируемого узлом crab каталога /usr/local. Программы, работавшие нормально, были установлены локально на рабочей станции пользователя. Больше ни у кого не возникали подобные проблемы с сервером, а прозвонка узла limulus с узла crab дала положительные результаты. Мы попросили пользователя проверить файл messages на предмет наличия сообщений об ошибках, и вот что он обнаружил:

Mar 6 13:38:23 limulus vmunix: duplicate IP address!! 
sent from ethernet address: 0:0:c0:4:38:1a

Это сообщение свидетельствует о том, что рабочая станция обнаружила в Ethernet-сегменте другой узел, отзывающийся на ее IP-адрес. «Самозванец» в своем ARP-ответе использовал адрес Ethernet 0:0:с0:4:38:1а, тогда как верный адрес Ethernet для limulus - 8:0:20:е:12:37.

Мы проверили таблицу ARP узла crab и обнаружили, что она содержит некорректную запись для узла limulus. Мы удалили эту запись при помощи команды агр -d, а затем установили корректную запись при помощи ключа -s следующим образом:

# агр -d limulus 
limulus (172.16.180.130) deleted 
# arp -s limulus 8:0:20:e:12:37

Записи ARP, полученные по протоколу ARP, являются временными. Значения хранятся в таблице определенный период времени и удаляются по его истечении.


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

Итак, мы быстро достигли результата и разрешили проблему узла limulus, однако нужно было отыскать виновника проблемы. Мы обратились к файлу /etc/ethers в поисках записи для адреса Ethernet 0: 0:с0:4:38:1а, но не нашли ее. По первым трем байтам адреса, 0:0:с0, мы определили, что это устройство является картой Western Digital. Поскольку в нашей сети есть только рабочие станции Unix и персональные компьютеры, мы предположили, что карта Western Digital установлена в одном из последних. Кроме того, мы пришли к выводу, что проблемный адрес недавно установлен, поскольку пользователь раньше не обращался к нам с этой проблемой. Мы отправили всем пользователям срочное уведомление с запросом сведений о том, не устанавливал ли кто-либо в последнее время новый персональный компьютер, TCP/IP на такой машине, не выполнялась ли перенастройка существующих машин. Мы получили один ответ. Проверив систему этого пользователя, мы обнаружили, что он использовал адрес 172.16.180.130, тогда как следовало набирать 172.16.180.138. После исправления адреса проблема больше не возникала.

Вот так, без изысков, мы решили эту проблему. Обратившись к сообщениям об ошибках, мы выяснили, в чем проблема и как ее решать. Вовлечение в процесс всех пользователей сети позволило нам быстро обнаружить виновную систему и обойтись без поиска компьютера по всем комнатам. Нежелание привлекать пользователей для участия в решении проблемы - одна из самых дорогих и самых распространенных ошибок, совершаемых администраторами сетей.


Обмениваться, хранить, передавать Ваши файлы стало просто как никогда.
yandex-disk
Читать подробнее: для чего Yandex-Диск проекту Mini-Server. Практика установки, настройки и использования сетевого хранилища на Ubuntu server LTS 12.04 в статье Резервное копирование сервера Ubuntu на Яндекс Диск.

>> Ubuntu 12.04 + Nginx Скачать сервер
>> Fedora 15 Скачать сервер
>> Простой Debian 6.0.6 Скачать сервер
>> CentOS 6.0 и
+ (5.6) другой
Скачать сервер
>> OpenSUSE 11.4
MAX
Скачать сервер

Вход на сайт

ВНИМАНИЕ!

Регистрация на сайте только по согласованию с администратором ресурса. Обращаться через форму обратной связи.