Хант Крэйг. TCP/IP Сетевое администрирование

Подождите немного. Документ загружается.

502

Глава 13. Разрешение проблем TCP/IP

локальных и удаленных серверов, а также для проверки корректности

имени узла, которое сообщил пользователь.

Network unreachable (Сеть недоступна)

В локальной системе нет маршрута к этой удаленной системе. Если в ко-

мандной строке ping использовался численный IP-адрес, повторно набе-

рите команду ping с именем узла. Это исключает возможность некор-

ректного ввода адреса IP либо использования изначально неверного адре-

са. Если используется протокол маршрутизации, убедитесь, что он запу-

щен, и проверьте таблицу маршрутизации при помощи netstat. Если

используется статический маршрут по умолчанию, установите его по-

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

проверьте шлюз по умолчанию на наличие проблем с маршрутизацией.

No answer (Нет ответа)

Удаленная система не ответила. Версии этого сообщения есть в большин-

стве сетевых приложений. Отдельные реализации ping выводят сообще-

ние «100% packet loss (100% пакетов утеряно)», telnet отображает сооб-

щение «Connection timed out» (Истек интервал ожидания соединения),

a sendmail возвращает ошибку «cannot connect» (невозможно подклю-

читься). Все эти сообщения означают одно: локальная система знает

маршрут к удаленной системе, однако не получила ответы от удаленной

системы ни на один из отправленных пакетов.

Существует множество возможных причин этой проблемы. Неработоспо-

собность удаленного узла, некорректные настройки локального или уда-

ленного узла, неработоспособность шлюза или цепи между локальным и

удаленным узлами, проблемы маршрутизации на удаленном узле. Вы-

явить истинную причину позволяет только дополнительное тестирова-

ние. Внимательно проверьте локальные настройки при помощи netstat и

ifconfig.

Отследите маршрут к удаленной системе при помощи traceroute.

Свяжитесь с администратором удаленной системы и сообщите о проблеме.

Все упомянутые здесь инструменты мы еще обсудим в этой главе. Но прежде

чем расстаться с

ping,

взглянем более пристально на команду и сведения ста-

тистики, которые она отображает.

Команда ping

Вазовый формат команды ping в системе Solaris следующий:

ping host [packetsize] [count]

host

Имя или IP-адрес удаленного узла, для которого выполняется прозвонка.

Используйте имя узла или адрес, полученные от пользователя, сообщив-

шего об ошибке.

Сверьтесь с документацией по своей системе. Реализации ping немного отличают-

ся одна от другой. В Linux приведенный синтаксис выглядит иначе: ping [ -с count]

[-s packetsize] host.

Проверка наличия подключения

503

packetsize

Определяет размер тестовых пакетов в байтах. Это поле является обяза-

тельным, только если вы собираетесь использовать поле count. Исполь-

зуйте размер пакета по умолчанию, который составляет 56 байтов.

count

Число пакетов, передаваемых в ходе прозвонки. Используйте поле count и

выбирайте небольшие значения. В противном случае команда ping будет

посылать тестовые пакеты, пока вы не прервете ее работу, к примеру, ком-

бинацией клавиш <Ctrl>+<C> ("С). Передача чрезмерного количества тес-

товых пакетов — пустая растрата пропускающей способности сетевых ка-

налов и системных ресурсов. Для теста обычно достаточно пяти пакетов.

Чтобы проверить возможность доступа к ns.uu.net с узла crab, мы посылаем

пять 56-байтовых пакетов следующей командой:

Ключ -s нужен потому, что узел crab - рабочая станция под управлением So-

laris, а нам нужна статистика по отдельным пакетам. В отсутствие ключа -s

программа ping от Sun выводит только окончательный вердикт: «ns.uu.net is

alive». Прочие реализации ping не требуют использования ключа -s; они

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

ниже Linux-примера:

Оба теста показывают наличие хорошего канала в территориальной сети к

ns.uu.net, отсутствие потерь пакетов и быструю реакцию удаленной систе-

мы. Среднее время отклика для almond и ns.uu.net составило всего 24,3 мил-

лисекунды. Потери некоторых пакетов и на порядок большее время отклика

504

Глава 13. Разрешение проблем TCP/IP

не служат симптомами неисправностей для территориальных каналов. Од-

нако статистика, отображаемая командой ping, может свидетельствовать о

низкоуровневых сетевых проблемах. Ключевые элементы статистики:

• Последовательность прибытия пакетов, обозначенная порядковыми но-

мерами ICMP

(icmp_seq),

выводимыми для всех пакетов.

• Длительность кругового путешествия пакетов, выраженная в миллисе-

кундах; выводится после строки time=.

• Процент потерянных пакетов, отображаемый в последних строках, за-

вершающих вывод ping.

Высокий процент потерь для пакетов, очень низкая скорость отклика либо

неупорядоченное прибытие пакетов может свидетельствовать о проблемах

на аппаратном уровне сетевых устройств. Если подобные показатели встре-

чаются при работе с географически удаленными системами по территори-

альной сети, не о чем беспокоиться. Архитектура TCP/IP позволяет рабо-

тать в ненадежных сетях, и некоторые территориальные сети в значитель-

ной степени подвержены потере пакетов. Те же проблемы в локальной сети -

признак неисправностей.

В кабельном сегменте локальной сети время «кругосветного» путешествия

пакета должно быть близко к нулю, потери пакетов должны быть мини-

мальны или полностью отсутствовать и должен сохраняться порядок прибы-

тия пакетов. Если одно из этих утверждений не соответствует действитель-

ности, существуют проблемы с сетевыми устройствами. В случае Ethernet

речь может идти о неправильной оконечной блокировке кабеля, испорчен-

ном кабельном сегменте либо сбойном элементе «активного» оборудования,

такого как коммутатор, концентратор или трансивер. Протестируйте кабель

при помощи кабельного тестера, как описывалось выше. Качественные кон-

центраторы и коммутаторы обычно имеют встроенное программное обеспе-

чение, позволяющее выполнять диагностирование. Дешевые концентрато-

ры и трансиверы могут потребовать решения проблемы методом «перебора» -

то есть отключения отдельных устройств по одному, до тех пор, пока пробле-

ма не исчезнет.

Результаты простого ping-теста, даже успешного, помогут направить даль-

нейшие усилия по тестированию в сторону наиболее вероятных причин

проблемы. Однако для более пристального изучения проблемы и обнаруже-

ния точной причины необходимы и другие инструменты диагностирования.

Разрешение проблем доступа к сети

Ошибки «по answer» и «cannot connect» свидетельствуют о проблеме в ниж-

них уровнях сетевых протоколов. Если предварительные тесты указывают

на проблему такого рода, сконцентрируйте тестирование в области маршру-

тизации и сетевого интерфейса. Воспользуйтесь командами ifconfig, netstat

и агр для тестирования уровня доступа к сети (Network Access Layer).

Разрешение проблем доступа к сети

505

Команда ifconfig выводит две строки. Первая строка содержит имя интерфей-

са и его характеристики. Обратите внимание на следующие характеристики:

Интерфейс функционален, может использоваться. Если интерфейс отклю-

чен, попросите администратора системы включить его командой ifconfig

(например, ifconfig dnetO

up).

Если интерфейс невозможно инициализиро-

вать, замените кабель интерфейса и попробуйте еще раз. Если и это не по-

могает, проверьте работоспособность устройства сетевого интерфейса.

RUNNING

Интерфейс действует. Если интерфейс не действует, возможно, драйвер

устройства не был установлен как подобает. Администратор системы дол-

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

Вторая строка вывода ifconfig содержит IP-адрес, маску подсети (в шестнад-

цатеричном формате), а также широковещательный адрес. Проверьте значе-

ния этих трех полей, чтобы убедиться, что интерфейс настроен правильно.

Некорректные маски подсетей и некорректные IP-адреса - две распростра-

ненные проблемы настройки интерфейсов. Некорректность маски подсети

проявляется в том, что узел может связаться с другими узлами своей ло-

кальной подсети и удаленными узлами внешних сетей, однако не может свя-

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

ружить, что установлена неверная маска подсети.

Неверный IP-адрес может стать проблемой, с трудом поддающейся обнаруже-

нию. Если сетевая часть адреса неверна, все команды ping будут завершаться

с ошибкой «по answer». В этом случае использование ifconfig позволяет

раскрыть ошибку в адресе. Однако если неверно задан номер узла в адресе,

проблему становится труднее обнаружить. Небольшая система - например

персональный компьютер, который подключается к другим системам, но

никогда не обрабатывает входящие соединения, - может долгое время рабо-

тать с неверным адресом, и пользователь ничего не заметит. Более того,

проблемы может испытывать вовсе не та система, что была некорректно на-

строена. Вполне возможно случайное использование вашего IP-адреса в дру-

Диагностирование при помощи ifconfig

ifconfig выводит настройки сетевого интерфейса. Используйте эту команду

для проверки корректности настроек пользователя, если система пользова-

теля настраивалась недавно или с нее невозможно получить доступ к удален-

ному узлу, с которым спокойно работают все прочие системы той же сети.

Если выполнить ifconfig с именем интерфейса в качестве единственного аргу-

мента, программа отображает текущие значения параметров интерфейса. На-

пример, проверка интерфейса dnetO системы Solaris 8 дает такой результат:

506

Глава 13. Разрешение проблем TCP/IP

гой системе, которое приведет к периодическим проблемам при обмене дан-

ными. Пример такого случая мы обсудим позже. Ошибки настройки такого

типа не могут быть обнаружены при помощи ifconfig, поскольку ошибка

сделана на удаленном узле. Чтобы решать подобные проблемы, необходимо

использовать команду агр.

Диагностирование при помощи агр

Команда агр используется при анализе проблем, связанных с отображения-

ми адресов IP в адреса Ethernet. Команда агр предоставляет три полезных

для целей отладки ключа:

-а

Отобразить все ARP-записи из таблицы.

-d имя-узла

Удалить запись из таблицы ARP.

-s имя-узла ether-адрес

Добавить запись в таблицу.

Эти три ключа позволяют просматривать содержимое таблицы ARP, уда-

лять проблемную запись, а также устанавливать корректную запись. Воз-

можность установки корректной записи - это полезная «отсрочка», дающая

время на поиск постоянного решения.

Используйте агр, если заподозрили наличие некорректных записей в табли-

це разрешения адресов. Одним из четких признаков проблем с таблицей

ARP является сообщение, что на команду - скажем, ftp или telnet - отве-

тил «не тот» узел. Нерегулярные проблемы, затрагивающие лишь опреде-

ленные узлы, также могут свидетельствовать об ошибках в таблице ARP.

Проблемы в таблице ARP обычно вызываются использованием одного и того

же IP-адреса двумя различными системами. Проблемы ощущаются пользо-

вателями сети нерегулярно, поскольку в таблицу попадает запись для адре-

са узла, который быстрее других ответил на последний ARP-запрос. Иногда

первым отвечает «правильный» узел, а иногда «не тот».

Если вы заподозрили, что две системы используют один и тот же IP-адрес,

выведите таблицу разрешения адресов при помощи команды агр -а. Вот при-

мер для системы Solaris.

Формат вывода таблицы ARP может варьироваться от систему к системе.

Разрешение проблем доступа к сети

507

Проще всего проверить корректность пар адресов IP/Ethernet, если сущест-

вует информация о корректном для каждого отдельного узла адресе Ether-

net. По этой причине следует записывать Ethernet- и IP-адреса каждого узла

при его добавлении к сети. Обладая такими записями, вы быстро обнаружи-

те несоответствия в таблице.

Если же такой записи нет, первые три байта адреса Ethernet помогут обнару-

жить проблему. Первые три байта адреса идентифицируют производителя

устройства. Перечень таких идентификационных префиксов доступен по ад-

ресу http://www.iana.org/assignments/ethernet-numbers.

Исходя из префиксов, мы можем видеть, что две записи из таблицы ARP в

нашем примере относятся к системам Sun (8:0:20). Предположим, horseshoe

должен быть второй системой под управлением системы Sun, и тогда пре-

фикс 0:0:0с Cisco показывает, что маршрутизатор Cisco по ошибке получил

IP-адрес узла horseshoe.

Если ни справочник корректных соответствий, ни префиксы производите-

лей устройств не помогли определить источник ошибки в таблице ARP, по-

пытайтесь использовать telnet для подключения к системе, IP-адрес кото-

рой содержится в записи ARP. Если устройство поддерживает telnet, при-

ветственное сообщение может помочь определить, какой из узлов некор-

ректно настроен.

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

Позвонил пользователь и поинтересовался, доступен ли сервер, а затем сооб-

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

висала» на время до нескольких минут при выполнении определенных ко-

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

нием вызывали все сетевые команды, задействующие сервер имен NIS, но

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

чает такое сообщение об ошибке:

NFS getattr failed for server crab: RPC: Timed out

Сервер crab предоставляет узлу limulus службы NIS и NFS. Команды, вы-

звавшие проблемы на узле limulus, требовали доступа к службе NIS, либо к

файлам из экспортируемого узлом crab каталога /usr/local. Программы, ра-

ботавшие нормально, были установлены локально на рабочей станции поль-

зователя. Больше ни у кого не возникали подобные проблемы с сервером, а

прозвонка узла limulus с узла crab дала положительные результаты.

Мы попросили пользователя проверить файл messages

на предмет наличия

сообщений об ошибках, и вот что он обнаружил:

Маг 6 13:38:23 limulus vmunix: duplicate IP address!!

sent from ethernet address: 0:0:c0:4:38:1a

Обратитесь к файлу /etc/syslog.conf за полным именем файла сообщений. Обычно

он называется / var/adrn/messages или /var log /messages.

508 Глава 13. Разрешение проблем TCP/IP

Это сообщение свидетельствует о том, что рабочая станция обнаружила в

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. После исправления адреса проблема больше не возникала.

Вот так, без изысков, мы решили эту проблему. Обратившись к сообщениям

об ошибках, мы выяснили, в чем проблема и как ее решать. Вовлечение в

процесс всех пользователей сети позволило нам быстро обнаружить винов-

ную систему и обойтись без поиска компьютера по всем комнатам. Нежела-

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

самых дорогих и самых распространенных ошибок, совершаемых админист-

раторами сетей. !,,.. 'л

Разрешение проблем доступа к сети

509

Строку кольцевого интерфейса 1о0 можно игнорировать. Значимой является

только строка настоящего сетевого интерфейса, и только последние пять по-

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

Взглянем сначала на последнее поле. В очереди (Queue) не должно быть паке-

тов, передача которых невозможна. Если интерфейс инициализирован и

функционирует, но система не может передать пакеты в сеть, дело, возмож-

но, в испорченном кабеле или интерфейсе. Замените кабель. Если проблемы

остались, свяжитесь с производителем устройства на предмет починки.

Число входящих (Ierrs) и исходящих (Oerrs) ошибок должно быть близко к

нулевому. Независимо от объема прошедшего через интерфейс объема дан-

ных значение 100 в любом из этих полей является высоким. Большое число

исходящих ошибок может указывать на перегрузку локальной сети или же

некачественный физический канал между узлом и сетью. Большое число

входящих ошибок может указывать на перегрузку сети, узла либо проблемы

на физическом уровне сети. Подтвердить наличие проблем на физическом

уровне помогут такие инструменты, как ping и кабельный тестер. Оценка

числа конфликтов поможет определить, произошла ли перегрузка локаль-

ного сегмента Ethernet.

Высокое значение в поле конфликтов (Collis) допустимо, но если процент

конфликтов для исходящих пакетов слишком высок, это свидетельствует о

перегруженности сети. Уровень конфликтов, превышающий 5%, уже требу-

ет внимания. Если высокий уровень конфликтов наблюдается постоянно,

причем в самых разных точках сети, может быть необходимо измельчение

сегментов сети с целью сокращения загрузки трафиком.

Уровень конфликтов выражается в процентах от количества исходящих па-

кетов. Не используйте общее число отправленных и полученных пакетов,

обращайте внимание на значения в полях Opkts и Collis, когда определяете

уровень конфликтов. Например, вывод в приведенном ранее примере сооб-

щает о 50679 конфликтах из 633424 исходящих пакетов. Уровень конфлик-

тов в этом случае составляет 8%. Вполне возможно, что в этой сети возника-

ет перегрузка - обратитесь к статистике с других узлов этой сети. Если и

Формат вывода в системе Linux выглядит иначе, но содержит те же статистичес-

кие данные.

Проверка интерфейса при помощи netstat

Если предварительные тесты дали вам основание заподозрить, что подклю-

чение к локальной сети ненадежно, полезную информацию может предоста-

вить команда netstat -i. Следующий пример содержит результат выполне-

ния команды netstat -i для системы Solaris 8:

510 Глава 13. Разрешение проблем TCP/IP

другие системы демонстрируют высокий уровень конфликтов, задумайтесь

о разделении сети на сегменты.

Деление сети Ethernet на сегменты

Чтобы снизить уровень конфликтов, необходимо сократить объем передава-

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

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

дет меньше узлов и, как следствие, меньший трафик. Как станет ясно, на де-

ле все несколько сложнее.

Наиболее эффективный способ выполнить деление сети Ethernet - устано-

вить коммутатор Ethernet. Каждый порт коммутатора по сути дела является

отдельным сегментом. Таким образом, 16-портовый коммутатор дает воз-

можность создать до 16 сегментов Ethernets в целях балансировки загрузки.

В большинстве коммутаторов порты могут использоваться различными спо-

собами (рис. 13.1). Системы с небольшой загрузкой могут подключаться к

концентратору, который в свою очередь подключается к одному из портов

коммутатора; это позволяет объединять системы в один сегмент. Для серверов

и систем с высокой сетевой нагрузкой могут формироваться выделенные сег-

менты - при помощи прямого подключения к портам коммутатора. В боль-

шинстве коммутаторов присутствуют порты Ethernet, работающие на ско-

ростях как 10 Мбит/с, так и 100 Мбит/с (Fast Ethernet). Такие коммутаторы

называются асимметричными, потому что различные порты работают с раз-

личными скоростями. Для подключения загруженных серверов или сете-

вых сегментов используйте порты Fast Ethernet. В большинстве коммутато-

ров с формулой 10/100 порты автоматически настраиваются на нужную ско-

рость работы, что позволяет использовать любой порт на скорости 100 или

10 Мбит/с и дает максимальную гибкость при настройке.

Тйкжб могут применяться коммутаторы Gigabit Ethernet, но у них особое

место в сетевой топологии. Коммутаторы 10/100 соединяют серверы и ло-

кальные сети. Гигабитные коммутаторы используются преимущественно

для создания «вырожденной опорной сети» (collapsed backbone), объединяю-

щей другие коммутаторы. Гигабитные коммутаторы используются при про-

ектировании новой корпоративной магисУральной сети, тогда как коммута-

торы 10/100 - для выделения сегментов в сети Ethernet.

На рис. 13.1 представлен 8-портовый коммутатор Ethernet 10/100. Порты 1

и 2 соединены с концентраторами Ethernet. Через каждый концентратор

подключен ряд систем. При добавлении систем они распределяются поровну

между концентраторами в целях предотвращения перегрузки одного из сег-

ментов. К свободным портам коммутатора в целях дальнейшего расширения

могут подключаться дополнительные концентраторы. Порт 4 выделен под

канал индивидуального сегмента системы с высокой сетевой загрузкой.

Порт 6 работает на скорости 100 Мбит/с и обеспечивает подключение загру-

женного сервера. Один из портов может быть зарезервирован для подключе-

ния в будущем дополнительного коммутатора Ethernet 10/100, который

даст возможность дальнейшего расширения. ' У

Разрешение проблем доступа к сети

511

Рис. 13.1. Подразделение сети Ethernet при помощи коммутаторов

Прежде чем выделять порты на коммутаторе, выясните, какие службы

пользуются спросом и кто с кем работает. Затем разработайте план, сокра-

щающий объем трафика по отдельным сегментам. Например, если загру-

женная система на порту 4 использует значительную часть полосы пропус-

кания канала только потому, что общается с одной из систем, подключен-

ных через порт 1, все системы, подключенные через порт 1, будут испыты-

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

загруженная система, необходимо перенести на свободный порт либо в тот

же сегмент (порт 4). Максимально используйте возможности коммутатора

для балансировки нагрузки.

Следует ли сегментировать старые коаксиальные Ethernet-ceTH, разрезая

кабель и соединяя его при помощи маршрутизатора или ретранслятора?

Нет. Если ваша старая сеть близка к насыщению, настало время создавать

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

мой пропускной способностью, в которой все узлы подключены к одному ка-

белю (в данном случае - коаксиальному кабелю Ethernet), - это бочка с по-

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

смог затруднить ее работу простым отключением собственной системы или

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

ванную витую пару (UTP), в идеале - кабель категории 5, для создания сетей

lOBaseT Ethernet или 100BaseT Fast Ethernet, соединяющих оборудование в

офисе пользователя с концентратором, надежно защищенным специальным

шкафом. Сетевые компоненты на рабочем месте пользователя должны быть