Вазовый формат команды ping в системе Solaris следующий:
ping host [packetsize] [count]
host - Имя или IP-адрес удаленного узла, для которого выполняется прозвонка. Используйте имя узла или адрес, полученные от пользователя, сообщившего об ошибке.
packetsize - Определяет размер тестовых пакетов в байтах. Это поле является обязательным, только если вы собираетесь использовать поле count. Используйте размер пакета по умолчанию, который составляет 56 байтов.
count - Число пакетов, передаваемых в ходе прозвонки. Используйте поле count и выбирайте небольшие значения. В противном случае команда ping будет посылать тестовые пакеты, пока вы не прервете ее работу, к примеру, комбинацией клавиш <Ctrl>+<C> ("С). Передача чрезмерного количества тестовых пакетов — пустая растрата пропускающей способности сетевых каналов и системных ресурсов. Для теста обычно достаточно пяти пакетов. Чтобы проверить возможность доступа к ns.uu.net с узла crab, мы посылаем пять 56-байтовых пакетов следующей командой:
$ ping -s ns.uu.net 56 5 PING ns.uu.net: 56 data bytes 64 bytes from ns.uu.net (137.39.1.3): icmp_seq=0. time= 32.8 ms 64 bytes from ns.uu.net (137.39.1.3): icmp_seq=l. time= 15.3 ms 64 bytes from ns.uu.net (137.39.1.3): icmp_seq=2. time= 13.1 ms 64 bytes from ns.uu.net (137.39.1.3): icmp_seq=3. time= 32.4 ms 64 bytes from ns.uu.net (137.39.1.3): icmp_seq=4. time= 28.1 ms ----ns.uu.net PING Statistics---- 5 packets transmitted, 5 packets received, 0% packet loss round trip (ms) min/avg/max = 13.1/24.3/32.8
Ключ -s нужен потому, что узел crab - рабочая станция под управлением Solaris, а нам нужна статистика по отдельным пакетам. В отсутствие ключа -s программа ping от Sun выводит только окончательный вердикт: «ns.uu.net is alive». Прочие реализации ping не требуют использования ключа -s; они отображают статистику по умолчанию, как можно видеть из приводимого ниже Linux-примера:
$ ping -c5 ns.uu.net PING ns.uu.net (137.39.1.3) from 172.16.12.3 : 56(84) bytes of data. 64 bytes from ns.UU.NET (137.39.1.3): icmp_seq=0 ttl=244 time=98.283 msec 64 bytes from ns.UU.NET (137.39.1.3): icmp_seq=1 ttl=244 time=94.114 msec 64 bytes from ns.UU.NET (137.39.1.3): icmp_seq=2 ttl=244 time=66.565 msec 64 bytes from ns.UU.NET (137.39.1.3): icmp_seq=3 ttl=244 time=24.301 msec 64 bytes from ns.UU.NET (137.39.1.3): icmp_seq=4 ttl=244 time=37.060 msec --- ns.uu.net ping statistics — 5 packets transmitted, 5 packets received, 0% packet loss round trip min/avg/max/mdev = 24.301/64.064/98.283/29.634 ms
Оба теста показывают наличие хорошего канала в территориальной сети к ns.uu.net, отсутствие потерь пакетов и быструю реакцию удаленной системы. Среднее время отклика для almond и ns.uu.net составило всего 24,3 миллисекунды. Потери некоторых пакетов и на порядок большее время отклика не служат симптомами неисправностей для территориальных каналов. Однако статистика, отображаемая командой ping, может свидетельствовать о низкоуровневых сетевых проблемах. Ключевые элементы статистики:
• Последовательность прибытия пакетов, обозначенная порядковыми номерами ICMP (icmp_seq), выводимыми для всех пакетов.
• Длительность кругового путешествия пакетов, выраженная в миллисекундах; выводится после строки time=.
• Процент потерянных пакетов, отображаемый в последних строках, завершающих вывод ping.
Высокий процент потерь для пакетов, очень низкая скорость отклика либо неупорядоченное прибытие пакетов может свидетельствовать о проблемах на аппаратном уровне сетевых устройств. Если подобные показатели встречаются при работе с географически удаленными системами по территориальной сети, не о чем беспокоиться. Архитектура TCP/IP позволяет работать в ненадежных сетях, и некоторые территориальные сети в значительной степени подвержены потере пакетов. Те же проблемы в локальной сети - признак неисправностей.
В кабельном сегменте локальной сети время «кругосветного» путешествия пакета должно быть близко к нулю, потери пакетов должны быть минимальны или полностью отсутствовать и должен сохраняться порядок прибытия пакетов. Если одно из этих утверждений не соответствует действительности, существуют проблемы с сетевыми устройствами. В случае Ethernet речь может идти о неправильной оконечной блокировке кабеля, испорченном кабельном сегменте либо сбойном элементе «активного» оборудования, такого как коммутатор, концентратор или трансивер. Протестируйте кабель при помощи кабельного тестера, как описывалось выше. Качественные концентраторы и коммутаторы обычно имеют встроенное программное обеспечение, позволяющее выполнять диагностирование. Дешевые концентраторы и трансиверы могут потребовать решения проблемы методом «перебора» - то есть отключения отдельных устройств по одному, до тех пор, пока проблема не исчезнет.
Результаты простого ping-теста, даже успешного, помогут направить дальнейшие усилия по тестированию в сторону наиболее вероятных причин проблемы. Однако для более пристального изучения проблемы и обнаружения точной причины необходимы и другие инструменты диагностирования.