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

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

Обмениваться, хранить, передавать Ваши файлы стало просто как никогда.
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
Скачать сервер

Вход на сайт

ВНИМАНИЕ!

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