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