Обрыв соединения с сервером. Трассировка и пинг
«Ааа, помогите, все пропало!» – если ваш внутренний голос реагирует на обрыв соединения с сервером примерно так, этот материал точно для вас. 🙂 Безусловно, со своей стороны мы каждый день делаем все возможное, чтобы ничто не мешало вашей работе в облаке, но случись форс-мажор – будем разбираться. А чтобы быстрее сориентироваться в ситуации и понять, на чьей стороне ошибка, вот вам задача-минимум – во время обрыва первым делом выполните трассировку маршрута и пинг промежуточных узлов. Как все это сделать, сейчас расскажем.
Трассировка маршрута
Во время трассировки происходит отправка пакетов данных между локальным компьютером и сервером. Это помогает проследить путь прохождения запроса к серверу и определить, на каком этапе происходит обрыв. Выполнить трассировку довольно легко. 1. Запустите команду cmd: Win+R > пропишите cmd > ОК. 2. В открывшейся командной строке введите tracert Х.Х.Х.Х (где Х.Х.Х.Х – это IP-адрес сервера или домен) и нажмите Enter. В примере мы сделали трассировку для google.com. tracert google.com Получилось так: 1 2 1 ms 1 ms 1 ms 193.151.89.254
3 5 ms 4 5 1 ms 6 1 ms 7 1 ms 3 ms 1 ms bearline-ic-324086-ffm-b4.c.telia.net [62.115.153.215]
8 1 ms 1 ms 1 ms 108.170.251.129
9 13 ms 13 ms 15 ms 66.249.94.135
10 13 ms 13 ms 13 ms fra15s12-in-f46.1e100.net [216.58.208.46] Как видим, наши пакеты преодолели десять (их может быть как меньше, так и больше) узлов, и преодолели их успешно. В противном случае, если бы пакеты «споткнулись» на одном из узлов, на нем (и последующих за ним узлах) мы бы увидели: * * * Превышен интервал ожидания для запроса. Но даже в таком случае пока не время для выводов – эта запись может означать как потерю пакетов, так и то, что узел сети просто закрыт настройками безопасности. Иногда провайдеры специально настраивают узлы так, чтобы они не отвечали на трассировочные пакеты, дабы снизить нагрузку. Чтобы точно узнать, действительно ли происходит обрыв, и, если да, то где именно, нужно пропинговать каждый из узлов. При трассировке мы получили IP каждого из них, а значит, можем перейти к пингу.
Пинг промежуточных узлов
Пинг предназначен для проверки целостности и качества соединений. Выполнить его тоже несложно. При этом запустить пинг нужно ко всем промежуточным узлам в отдельных окнах. Так непосредственно в момент обрыва связи будет видно, на каком узле происходят потери пакетов и насколько продолжительны эти обрывы. В ОС Windows по умолчанию передается только четыре пакета, чего недостаточно, если проблема проявляется кратковременно. Поэтому нужно снять это ограничение параметром -t (чтобы потом остановить обмен пакетами, нажать CTRL+C). Теперь по порядку. 1. Запустите команду cmd: Win+R > пропишите cmd > ОК. 2. В открывшейся командной строке введите ping -t Х.Х.Х.Х (где Х.Х.Х.Х – это адрес одного из промежуточных узлов, которые мы узнали при трассировке) и нажмите Enter. В нашем случае при трассировке мы выявили десять узлов, а значит, и пинг нужно выполнить десять раз в десяти отдельных окнах. Полезно!
Если вам нужно постоянно отслеживать качество соединения, для Windows можно воспользоваться удобной программой PingPlotter. Итак, пингуем – в десяти отдельных окнах командной строки вводим команды с IP-адресами узлов, которые мы выявили при трассировке. В нашем случае будут такие команды: ping -t 10.1.1.1
ping -t 193.151.89.254
ping -t 85.195.75.129
ping -t 213.248.79.29
ping -t 62.115.139.50
ping -t 62.115.120.8
ping -t 62.115.153.215
ping -t 108.170.251.129
ping -t 66.249.94.135
ping -t 216.58.208.46 Если в каком-нибудь из окон вы с первых же секунд видите «Превышен интервал ожидания», не спешите кричать: «Попался!». Если следующие узлы пингуются нормально, значит, этот просто закрыт настройками. В нашем случае, например, предпоследний узел (66.249.94.135) сразу же говорит, что интервал превышен, но с пингом десятого узла никаких проблем нет. Что дальше? Запустив пинг всех узлов, оставьте его включенным и занимайтесь своими делами до следующего обрыва. Как только он случится, вернитесь к окнам пинга, чтобы выявить, кто виноват и что делать.
На чьей стороне ошибка?
Итак, обрыв повторился. Но на этот раз запущенный пинг промежуточных узлов поможет «обличить» виновника. Тут все просто – с какого узла вам начало выдавать «Превышен интервал ожидания», тот и слабое звено. Кто виноват – ясно, теперь нужно понять, что делать в конкретных ситуациях. 1. Последний узел. Если последний узел сначала пинговался нормально (некоторые Windows-машины вообще не отвечают на пинг, это задается в настройках брандмауэра)… 
…а после обрыва начал показывать «Превышен интервал ожидания», обрыв происходит на вашем сервере. 
В этом случае зайдите в панель управления, запустите консоль и войдите в операционную систему, чтобы разобраться, почему сервер не работает. Если окажется, что операционная система зависла, перезагрузите сервер. 2. Любые узлы, кроме последнего. В этом случае обращайтесь одновременно в техподдержку и облачного, и интернет-провайдера. При этом обязательно укажите, как изначально выглядела трассировка маршрута, и составьте перечень узлов с указанием, на каких из них пинг во время обрыва прервался, а на каких нет. Будьте внимательны, это важная информация, не ошибитесь. 3. Все узлы одновременно. Если все окна с пингом начали показывать «Превышен интервал ожидания», проблема в вашем компьютере или сети, к которой он подключен.
Бонус!
Ну, а чтобы вам было совсем уж комфортно, мы тут подобрали утилиты, с которыми можно делать трассировку и пинг промежуточных узлов одним простым движением без запуска пятнадцати различных окон. Для ОС семейства Windows такую оптимизацию проводит утилита Winmtr. Она не нуждается в установке и готова к использованию сразу после распаковки из архива. Скачать утилиту можно здесь. Распаковали, запустили, что дальше? В поле Host укажите конечный сервер, с которым будет проверяться соединение, и нажмите Start: В нашем примере видна трассировка маршрута и все промежуточные узлы. При этом к каждому из них направляются ICMP-пакеты, по которым можно определить качество связи. Собственно, в этом и заключается главное преимущество утилиты – ее вывод постоянно обновляется, это позволяет собирать статистику, отслеживать средние показатели, тенденции и какие-либо изменения качества сети. Раз мы проверяем соединение с сервером, нас интересуют столбцы Sent (отправлено пакетов) и Recv (получено пакетов). Если значения в этих столбцах не совпадают, значит, качество связи с узлом ухудшилось. Что делать? Обратиться в соответствующую техподдержку. Столбец Loss поможет просмотреть динамику потерь в процентном соотношении. Также утилита позволяет копировать текст в удобных форматах (.txt и .html) в буфер обмена (Copy to clipboard) или в отдельный файл (Export). Двойной щелчок по промежуточному узлу позволит получить дополнительную информацию о нем. Важно знать! Для детализации проблемы специалисты техподдержки могут запросить дополнительные пинги с особыми настройками. Для этого достаточно внести их в окошке Options, которое позволит указать:
- Interval (sec) – время обновления данных в секундах.
- Max host in LRU list – максимальное количество хостов (или IP-адресов, если не активна опция Resolve names) до конечной точки.
- Ping size (bytes) – размер ICMP-пакета.
- Resolve names – возможность преобразовать IP-адрес в имя хоста.
А что же линуксоиды?
Для ОС семейства Linux утилита называется просто MTR. Если ее нет в вашей операционной системе, установить ее можно одним из следующих способов:
$ apt-get install mtr
$ yum install mtr
У MTR такой же функционал, как у Winmtr, а также схожий графический интерфейс. Запустить утилиту можно командой:
где X.X.X.X – это IP-адрес конечного сервера или имя хоста.
В данном случае интересуют следующие столбцы:
- Loss % – процент потерянных пакетов между компьютером-отправителем и промежуточными узлами.
- SNT – общее количество отправленных пакетов.
Как только где-то что-то потерялось, утилита сигнализирует нам об этом, окрашивая узел в красный цвет и подсчитывая процент потерь.
Отдельно отметим возможность запуска утилиты в текстовом (консольном) режиме. Для этого достаточно добавить опцию -t или —curses:
mtr —curses tucha.ua
Рассмотрим еще несколько важных опций MTR, которые могут быть крайне полезны в процессе диагностики сети.
Запускает режим отчета, в котором MTR обработает заданное количество циклов (определенных опцией -c), а затем отобразит статистику и автоматически завершит работу. Этот режим полезен для сбора статистики о качестве сети.
-c COUNT или —report-cycles COUNT
Позволяет задать количество циклов, после которых MTR завершит работу.
-p BYTES или —psize BYTES
Устанавливает размер пакетов в байтах.
-i SECONDS или —interval SECONDS
Задает интервал между отправляемыми пакетами.
Разрешает не использовать DNS, отображает IP-адреса узлов.
-a X.X.X.X или —address X.X.X.X
Позволяет указать адрес интерфейса компьютера, с которого будут отправляться ICMP-запросы.
Разумеется, команды в консоли дают более точный результат, поскольку фиксируют даже единичные потери пакетов (короткие обрывы), но Winmtr и MTR компактные и более удобны в использовании. А на чем остановить свой выбор, решать только вам. 🙂
Вот, собственно, и все, кто виноват – выяснили, что делать – тоже. 🙂 Надеемся, материал был вам полезен, а если у вас остались дополнительные околооблачные вопросы, обращайтесь к нам за грамотной консультацией 24×7.
Как утилита ping разрешает имена узлов в ip-адреса (и наоборот)?
Какие могут быть причины неудачного завершения ping и tracert? (превышен интервал ожидания для запроса, сеть недоступна, превышен срок жизни при передаче пакета).
Всегда ли можно узнать символьное имя узла по его ip-адресу?
Какой тип записи запрашивает у dns-сервера простейшая форма nslookup?
16.08.2019 563.71 Кб 12 Ответы ЗФ ВЭД.doc
20.07.2019 116.96 Кб 13 ответы на билеты по истории беларуси.docx
18.11.2019 210.43 Кб 7 ответы на вопросы по идеологии бел. гос.doc
22.04.2019 45 Кб 13 Ответы на вопросы по информатике.docx
15.04.2015 60.42 Кб 18 ответы на контрольные вопросы.doc
15.04.2015 72.19 Кб 150 ответы на контрольные вопросы2.doc
20.11.2018 393.22 Кб 57 Ответы на Спецуху без схем и приборов.doc
18.11.2018 88.05 Кб 6 Ответы на Спецуху.docx
20.11.2018 203.26 Кб 5 ответы по маркетингу.doc
22.11.2018 202.75 Кб 5 ответы по маркетингу.doc
15.04.2015 153.55 Кб 18 ответы по МПТ Оля.docx
Ограничение
Для продолжения скачивания необходимо пройти капчу:
анализ сетевых протоколов
-f посылает пакет с установленным флагом «не фрагментировать», запрещающим фрагментирование пакета на транзитных маршрутизаторах; -i ttl устанавливает время жизни пакета в величину ttl (каждый маршрутизатор уменьшает ttl на единицу, т.е. время жизни является счетчиком пройденных маршрутизаторов (хопов)); -v tos устанавливает значение поля «сервис», задающее приоритет обработки пакета; -r count записывает путь выходящего пакета и возвращающегося пакета в поле записи пути, count – от 1 до 9 хостов; -s count задает максимально возможное количество переходов из одной подсети в другую (хопов); -j host-list направляет пакеты с помощью списка хостов, определенного параметром host-list. ), максимальное количество хостов равно 9; -k host-list направляет пакеты через список хостов, определенный в host-list , причем указанные хосты не могут быть разделены промежуточными маршрутизаторами (жесткая статическая маршрутизация); -w timeout указывает время ожидания timeout ответа от удаленного хоста в миллисекундах (по умолчанию – 1с); -destination-list указывает удаленный узел, к которому надо направить пакеты ping, может быть именем хоста или IP-адресом машины. На практике в формате команды чаще всего используются опции — t и — n. Пример работы утилиты ping приведен на рис. 1.2.
Рис. 1.2. Пример использования утилиты ping
Утилита ping может использоваться следующими способами: 1. Для проверки того, что TCP/IP установлен и правильно сконфигурирован на локальном компьютере, в команде ping задается адрес петли обратной связи : ping 127.0.0.1 Если тест успешно пройден, то вы получите следующий ответ: Ответ от 127.0.0.1: число байт=32 время
Если возникли проблемы, то утилита выводит на экран звездочки ( * ) либо сообщения типа «Заданная сеть недоступна», «Время истекло». Следует помнить, что некоторые маршрутизаторы просто уничтожают пакеты с истекшим TTL и не будут видны утилите tracert . Синтаксис утилиты: tracert [ -d ] [ -h maximum_hops ] [ -j host-list ] [ -w timeout ] destination-list . Параметры: -d указывает, что не нужно распознавать адреса для имен хостов; -h maximum_hops указывает максимальное число хопов (по умолчанию – 30); -j host-list указывает нежесткую статическую маршрутизацию в соответствии с host — list ; -w timeout указывает, что нужно ожидать ответ на каждый эхопакет заданное число мс; -destination-list указывает удаленный узел, к которому надо направить пакеты ping . Пример работы утилиты tracert приведен на рис. 1.3. Рис. 1.3. Пример использования утилиты tracert 1.2.3.4. Утилита arp Утилита arp ( Address Resolution Protocol – протокол разрешения адресов) позволяет управлять так называемым ARP-кэшем – таблицей, используемой для трансляции IP-адресов в соответствующие локальные адреса. Записи в ARP-кэше формирует протокол ARP. Если необходимая запись в таблице не найдена, то протокол ARP отправляет широковещательный запрос ко всем компьютерам локальной подсети, пытаясь найти владельца данного IP-адреса.
В кэше могут содержаться два типа записей: статические и динамические. Статические записи вводятся вручную и хранятся в кэше постоянно. Динамические записи помещаются в кэш в результате выполнения широковещательных запросов. Для них существует понятие времени жизни. Если в течение определенного времени (по умолчанию 2 мин) запись не была востребована, то она удаляется из ARP-кэша. Синтаксис утилиты: arp [ -s inet_addr eth_addr ] [ -d inet_addr ] [ -a ]. Параметры: -s inet_addr eth_addr заносит в кэш статическую запись с указанными IP-адресом и MAC-адресом; -d inet_addr удаляет из кэша запись для определенного IP-ад- реса; -a просматривает содержимое кэша для всех сетевых адаптеров локального компьютера, как показано на рис. 1.4. Рис. 1.4. Пример использования утилиты arp 1.2.3.5. Утилита netstat Утилита netstat выводит статистику протоколов и текущих TCP/IP соединений и имеет следующий синтаксис: netstat [ -a ][ -e ][ -n ] [ -s ][ -p name ][ -r ][ interval ]. Параметры: -a отображает полную информацию по всем соединениям и портам, на которых компьютер ожидает соединения; -e отображает статистику Ethernet (этот ключ может применяться вместе с ключом – s ); -n отображает адреса и номера портов в числовом формате, без их преобразования в символьные имена DNS и в название сетевых служб, что делается по умолчанию t ; -p name задает отображение информации для протокола name (допустимые значения name : tcp , udp или ip ) и используется вместе с ключом s ;
-r отображает содержимое таблицы маршрутов (таблица маршрутизации); -s отображает подробную статистику по протоколам. По умолчанию выводятся данные для TCP, UDP и IP. Ключ p позволяет задать вывод данных по определенному протоколу, ключ interval инициирует повторный вывод статистических данных через указанный в секундах интервал (в этом случае для прекращения вывода данных надо нажать клавиши Ctrl+C ). Результатом выполнения команды является список активных подключений, в который входят установленные соединения и открытые порты (рис. 1.5). Рис. 1.5. Пример отображения утилитой netstat установленных на компьютере TCP-соединений Открытые TCP-порты обозначаются в колонке «Состояние» строкой LISTENING – пассивно открытые соединения («слушающие» сокеты) или ESTABLISHED – установленные соединения, т.е. уже используемые сетевыми сервисами. Содержание состояний протокола TCP (всего имеется 11 состояний) раскрыто в лабораторной работе № 2 настоящего практикума. Часть портов связана с системными службами Windows и отображается не по номеру, а по названию – epmap , microsoft-ds , netbios-ss и др. Порты, не относящиеся к стандартным службам, отображаются
по номерам. UDP-порты не могут находиться в разных состояниях, поэтому специальная пометка LISTENING в их отношении не используется. Как и TCP-порты, они могут отображаться по именам или по номерам. 1.2.3.6. Утилита nslookup Утилита nslookup предназначена для выполнения запросов к DNS-серверам на разрешение имен в IP-адреса и в простейшем случае имеет следующий синтаксис: nslookup [ host [ server ]]. Параметры: host – доменное имя хоста, которое должно быть преобразовано в IP-адрес; server – адрес DNS-сервера, который будет использоваться для разрешения имени. Если этот параметр опущен, то будут использованы адреса DNS-серверов из параметров настройки протокола TCP/IP (отображаются утилитой ipconfig ). Результаты выполнения команды nslookup приведены на рис. 1.6. Рис. 1.6. Пример отображения утилитой nslookup запроса к DNS Первые две строки ответа содержат имя и IP-адрес DNS-сервера, который был использован для разрешения имени. Следующие строки содержат реальное доменное имя хоста и его IP-адрес и указание Nonauthoritative answer , означающее, что ответ получен не с DNS-сервера, ответственного за зону penza . ru . Также может присутствовать строка Aliase , которая содержит альтернативные имена искомого сервера. 1.2.3.7. Сервис Whois При трассировке маршрутов или проверке доступности хоста в Internet часто возникает необходимость определить по IP-адресу хоста его юридического владельца и контактные данные его администратора.
В отношении доменов второго уровня эта информация становится свободно доступной для любого пользователя сети Internet через сервис Whois . On-line сервиса Whois можно получить через форму на странице сайта http://www.nic.ru/whois. 1.3. Задание на лабораторную работу 1.3.1. С помощью утилиты ipconfig, запущенной из командной строки, определить имя, IP-адрес и физический адрес основного сетевого интерфейса компьютера, IP-адрес шлюза, IP-адреса DNS-серверов и использование DHCP. Результаты представить в виде таблицы. 1.3.2. С помощью утилиты nslookup определить IP-адрес одного из удаленных серверов, доменные имена которых указаны в табл. 1.2. 1.3.3. С помощью утилиты ping проверить состояние связи c любыми компьютером и шлюзом локальной сети, а также с одним из удаленных серверов, доменные имена которых указаны в табл. 1.2.
| Таблица 1.2 | |||
| Доменные имена удаленных серверов | |||
| № | Адрес | № | Адрес |
| 1 | net . pnz . ru | 7 | penza . ertelecom . ru |
| 2 | penza . vt . ru | 8 | mypenza . ru |
| 3 | www . trans-link . ru | 9 | penza . com . ru |
| 4 | penzartc . ru | 10 | www . penza-gsm . ru |
| 5 | www . penza . ru | 11 | www.zato.ru |
| 6 | www . ptcomm . ru | 12 | penza . citydom . ru |
Число отправляемых запросов должно составлять не менее 10. Для каждого из исследуемых хостов отразить в виде таблицы IP-адрес хоста назначения, среднее время приема-передачи, процент потерянных пакетов. 1.3.4. С помощью утилиты arp проверить состояние ARP-кэша. Провести пингование какого либо хоста локальной сети, адрес которого не был отражен в кэше. Повторно открыть ARP-кэш и проконтролировать модификацию его содержимого. Представить полученные значения ARP-кэша в отчете. 1.3.5. Провести трассировку одного из удаленных хостов в соответствии с вариантом, выбранным в п. 1.3.2. Если есть потери пакетов, то для соответствующих хостов среднее время прохождения необхо-
димо определять с помощью утилиты ping по 10 пакетам. В отчете привести копию окна с результатами работы утилиты tracert . Определить участок сети между двумя соседними маршрутизаторами, который характеризуется наибольшей задержкой при пересылке пакетов. Для найденных маршрутизаторов с помощью сервиса Whois определить название организаций и контактные данные администратора (тел., e-mail). Полученную информацию привести в отчете. 1.3.6. С помощью утилиты netstat посмотреть активные текущие сетевые соединения и их состояние на вашем компьютере, для чего: запустить несколько экземпляров веб-браузера, загрузив в них различные страницы с разных веб-сайтов (по указанию преподавателя); закрыть браузеры и с помощью netstat проверить изменение списка сетевых подключений. Проконтролировать сетевые соединения в реальном масштабе времени, для чего: закрыть ранее открытые сетевые приложения; запустить из командной строки утилиту netstat , задав числовой формат отображения адресов и номеров портов и повторный вывод с периодом 20–30 с; в отдельном окне командной строки запустить утилиту ping в режиме «до прерывания»; наблюдать отображение netstat , текущей статистики сетевых приложений; с помощью клавиш Ctrl+C последовательно закрыть утилиты ping и netstat . В отчете привести копии окон с результатами работы утилиты netstat с пояснением отображаемой информации. 1.4. Вопросы для самопроверки 1. Каковы назначение и форматы MAC- и IP-адресов? С какой целью применяется «маска подсети»? 2. Как по IP-адресу и маске одной из рабочих станций определить адрес, принадлежащий всей локальной сети? 3. Как определить MAC-адрес сетевого адаптера, установленного в компьютере? 4. Что такое «основной шлюз»?
5. Каким образом утилита ping проверяет соединение с удаленным хостом? 6. Сколько промежуточных маршрутизаторов сможет пройти IP-пакет, если его время жизни равно 30? 7. Как работает утилита tracert ? 8. Каково назначение утилиты arp ? 9. С помощью каких утилит можно определить по доменному имени хоста его IP-адрес? 10. Как утилита ping разрешает имена хостов в IP-адреса? 11. Какие могут быть причины неудачного завершения ping и tracert ? 12. Какая служба позволяет узнать символьное имя хоста по его IP-адресу? 13. Какие операции можно выполнить с помощью утилиты netstat ?
Лабораторная работа № 2 Анализ протоколов сетевого и транспортного уровней 2.1. Цель работы Целью работы является изучение протоколов сетевого и транспортного уровней стека TCP/IP и приобретение практических навыков в использовании программных средств, позволяющих контролировать сетевой трафик, на примере программы Network Monitor . 2.2. Теоретический материал 2.2.1. Описание стека протоколов TCP/IP 2.2.1.1. Архитектура семейства протоколов TCP/IP Семейство протоколов TCP/IP представляет собой промышленный стандарт стека протоколов, разработанный для локальных и глобальных сетей. Лидирующая роль стека TCP/IP объясняется следующими причинами: это наиболее завершенный стандартный, имеющий многолетнюю историю; стек TCP/IP поддерживают все современные операционные си- стемы; это гибкая технология для соединения разнородных систем как на уровне транспортных подсистем, так и на уровне прикладных сервисов; это устойчивая масштабируемая межплатформенная среда для сетевых клиент-серверных приложений. Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI приведено в табл. 2.1. Протоколы TCP/IP делятся на четыре уровня – в стеке TCP/IP верхние три уровня (прикладной, представительский и сеансовый) модели OSI объединяют в один – прикладной. Нижний уровень (уровень доступа к сети) в стеке TCP/IP специально не регламентируется, но поддерживает все популярные стандарты физического и канального уровней.
Общие сведения о командах Ping и Traceroute
В этой статье рассматривается использование команд ping и traceroute. Приведенный в данном документе более подробный обзор результатов выполнения этих команд, был получен с помощью некоторых команд debug.
Базовые сведения
В данном документе используется простая конфигурация, представленная ниже и используемая в качестве примера
Команда ping
- Является ли удаленный хост активным или неактивным;
- Задержки приема-передачи при взаимодействии с хостом;
- Потери пакетов.
- эхо-запрос достигает места назначения;
- опрашиваемое устройство может отправить эхо-ответ обратно источнику в рамках заданного времени, называемого временем ожидания (тайм-аутом). Значение тайм-аута по умолчанию для маршрутизаторов Cisco равно двум секундам.
Router1#debug ip packet detail
IP packet debugging is on (detailed)
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
Router1#
Jan 20 15:54:47.487: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100,
sending
Jan 20 15:54:47.491: ICMP type=8, code=0
!— Это ICMP пакет, отправленный из 12.0.0.1 в 12.0.0.2.
!— ICMP тип=8 соответствует эхо-сообщению.
Jan 20 15:54:47.523: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100,
rcvd 3
Jan 20 15:54:47.527: ICMP type=0, code=0
!— Это ответ, полученный от 12.0.0.2.
!— ICMP тип=0 соответствует эхо-ответу.
!— По умолчанию число повторов равно 5, поэтому будет пять
!— эхо-запросов и пять эхо-ответов.
В приведенной ниже таблице перечислены возможные значения типа ICMP-протокола.
Тип ICMP-протокола
Символьная константа
цель назначения недостижима
код 0 = сеть недостижима
1 = хост недостижим
2 = протокол недостижим
3 = порт недостижим
4 = необходима фрагментация и установка DF-бита
5 = исходный маршрут недоступен
отключение источника сообщения при перегрузке с предварительным возвратом сообщения
перенаправление
код 0 = перенаправление дейтаграмм для сети
1 = перенаправление дейтаграмм для хоста
2 = перенаправление дейтаграмм для типа службы или сети
3 = перенаправление дейтаграмм для типа службы и хоста
альтернативный адрес
объявление маршрутизатора
запрос маршрутизатора
истечение времени ожидания
код 0 = истекло время существования пакета во время его передачи 1 = превышено время сборки фрагментов
проблема параметра
запрос временной метки
ответ на запрос о временной метке
информационный запрос
ответ на информационный запрос
запрос маски
ответ на запрос маски
ошибка преобразования
мобильное перенаправление
В нижеприведенной таблице содержатся сведения о символах, которые могут содержаться в результатах выполнения команды ping:
Отключение источника сообщения при перегрузке с предварительным возвратом сообщения (цель назначения перегружена).
Причины неудачного выполнения команды ping
Если не удается успешно выполнить команду ping, то причиной этому могут быть:
Проблема маршрутизации
Далее приведен пример неудачного выполнения команды ping, определения проблемы и мер, необходимых для ее устранения.
Данный сценарий объясняется с помощью схемы топологии сети, приведенной ниже:
Router1#
!
!
interface Serial0
ip address 12.0.0.1 255.255.255.0
no fair-queue
clockrate 64000
!
!
Router2#
!
!
interface Serial0
ip address 23.0.0.2 255.255.255.0
no fair-queue
clockrate 64000
!
interface Serial1
ip address 12.0.0.2 255.255.255.0
!
!
Router3#
!
!
interface Serial0
ip address 34.0.0.3 255.255.255.0
no fair-queue
!
interface Serial1
ip address 23.0.0.3 255.255.255.0
!
!
Router4#
!
!
interface Serial0
ip address 34.0.0.4 255.255.255.0
no fair-queue
clockrate 64000
!
!
В приведенном ниже примере производится опрос маршрутизатора 4 с маршрутизатора 1 с помощью команды ping:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)
Давайте внимательнее посмотрим на произошедшее:
Router1#debug ip packet
IP packet debugging is on
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
Jan 20 16:00:25.603: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:27.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:29.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:31.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Jan 20 16:00:33.599: IP: s=12.0.0.1 (local), d=34.0.0.4, len 100, unroutable.
Success rate is 0 percent (0/5)
Поскольку протоколы маршрутизации не используются в маршрутизаторе 1, он не знает, куда посылать пакеты и создает сообщение о невозможности маршрутизации.
Добавим маршрутизатору 1 статический маршрут:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Теперь у нас имеется:
Router1#debug ip packet detail
IP packet debugging is on (detailed)
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
Jan 20 16:05:30.659: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:30.663: ICMP type=8, code=0
Jan 20 16:05:30.691: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:05:30.695: ICMP type=3, code=1
Jan 20 16:05:30.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:30.703: ICMP type=8, code=0
Jan 20 16:05:32.699: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:32.703: ICMP type=8, code=0
Jan 20 16:05:32.731: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:05:32.735: ICMP type=3, code=1
Jan 20 16:05:32.739: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:05:32.743: ICMP type=8, code=0
Теперь оценим неисправности, возникающие на маршрутизаторе 2:
Router2#debug ip packet detail
IP packet debugging is on (detailed)
Router2#
Jan 20 16:10:41.907: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.911: ICMP type=8, code=0
Jan 20 16:10:41.915: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:41.919: ICMP type=3, code=1
Jan 20 16:10:41.947: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:41.951: ICMP type=8, code=0
Jan 20 16:10:43.943: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.947: ICMP type=8, code=0
Jan 20 16:10:43.951: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:43.955: ICMP type=3, code=1
Jan 20 16:10:43.983: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:43.987: ICMP type=8, code=0
Jan 20 16:10:45.979: IP: s=12.0.0.1 (Serial1), d=34.0.0.4, len 100, unroutable
Jan 20 16:10:45.983: ICMP type=8, code=0
Jan 20 16:10:45.987: IP: s=12.0.0.2 (local), d=12.0.0.1 (Serial1), len 56, sending
Jan 20 16:10:45.991: ICMP type=3, code=1
Маршрутизатор1 правильно отправляет свои пакеты на маршрутизатор 2, но маршрутизатор 2 не знает, как получить доступ к адресу 34.0.0.4. Маршрутизатор 2 отправляет Маршрутизатору 1 сообщение «unreachable ICMP» («недоступный ICMP-протокол»).
Теперь разрешите использование протокола маршрутизации информации (RIP-протокол) на маршрутизаторе 2 и маршрутизаторе 3.
Router2#
router rip
network 12.0.0.0
network 23.0.0.0
Router3#
router rip
network 23.0.0.0
network 34.0.0.0
Router1#debug ip packet
IP packet debugging is on
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds:
Jan 20 16:16:13.367: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:15.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:17.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:19.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Jan 20 16:16:21.363: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending.
Success rate is 0 percent (0/5)
Это немного улучшает ситуацию. Маршрутизатор 1 отправляет пакеты на маршрутизатор 4, но не получает никакого ответа от него.
Рассмотрим, какие проблемы могли возникнуть на маршрутизаторе 4:
Router4#debug ip packet
IP packet debugging is on
Router4#
Jan 20 16:18:45.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:45.911: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:47.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:47.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:49.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:49.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:51.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:51.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Jan 20 16:18:53.903: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:18:53.907: IP: s=34.0.0.4 (local), d=12.0.0.1, len 100, unroutable
Маршрутизатор 4 получает ICMP-пакеты и пытается отправить ответ на адрес 12.0.0.1, но так как у него нет маршрута в эту сеть, эта попытка терпит неудачу.
Добавим маршрутизатору 4 статический маршрут:
Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0
Теперь он работает правильно и обе стороны имеют доступ друг к другу:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: .
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms
Недоступность интерфейса
Эта ситуация возникает в случаях, когда интерфейс перестает работать. В приведенном ниже примере производится опрос маршрутизатора 4 с маршрутизатора 1 с помощью команды ping:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: U.U.U
Success rate is 0 percent (0/5)
Поскольку маршрутизация исправна, то устранение неполадок будет выполняться в пошаговом режиме. В начале попытаемся применить команду ping к маршрутизатору 2:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Из приведенных выше данных видно, что источник проблемы находится между маршрутизатором 2 и маршрутизатором 3. Одной из возможных причин может являться то, что последовательный интерфейс на маршрутизаторе 3 был отключен:
Router3#show ip interface brief
Serial0 34.0.0.3 YES manual up up
Serial1 23.0.0.3 YES manual administratively down down
Эта проблема легко устранима:
Router3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router3(config)#interface s1
Router3(config-if)#no shutdown
Router3(config-if)#
Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up
Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, changed state to up
Команда Access-list
В этом сценарии необходимо разрешить только трафику telnet поступать на маршрутизатор 4 через интерфейс Serial0.
Router4(config)# access-list 100 permit tcp any any eq telnet
Router4(config)#interface s0
Router4(config-if)#ip access-group 100 in
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#access-list 100 permit ip host 12.0.0.1 host 34.0.0.4
Router1(config)#access-list 100 permit ip host 34.0.0.4 host 12.0.0.1
Router1(config)#end
Router1#debug ip packet 100
IP packet debugging is on Router1#debug ip icmp
ICMP packet debugging is on
При попытке проверить доступность маршрутизатора 4 с помощью команды ping будет получен следующий результат:
Router1#ping 34.0.0.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 34.0.0.4, timeout is 2 seconds: U.U.U
Success rate is 0 percent (0/5)
Jan 20 16:34:49.207: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:49.287: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:34:49.291: ICMP: dst (12.0.0.1) administratively prohibited unreachable rcv from 34.0.0.4
Jan 20 16:34:49.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:51.295: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
Jan 20 16:34:51.367: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:34:51.371: ICMP: dst (12.0.0.1) administratively prohibited unreachable rcv from 34.0.0.4
Jan 20 16:34:51.379: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 100, sending
В конце команды access-list всегда существует неявное условие «deny all» («запретить всё»). Это означает, что ICMP-пакеты, поступающие на интерфейс Serial 0 маршрутизатора 4, отклоняются, а маршрутизатор 4, как показано в результате выполнения команды debug, отправляет источнику исходного пакета сообщение — «administratively prohibited unreachable» («доступ запрещен административно»). Решением проблемы является добавление в команду access-list следующей строки:
Router4(config)#access-list 100 permit icmp any any
Проблема с протоколом разрешения адресов (ARP-протокол)
В данном подразделе приведен пример подключения через протокол Ethernet:
Router4#ping 100.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:
Jan 20 17:04:05.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:05.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:07.167: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:07.171: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:09.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:09.183: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:11.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:11.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Jan 20 17:04:13.175: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, sending
Jan 20 17:04:13.179: IP: s=100.0.0.4 (local), d=100.0.0.5 (Ethernet0), len 100, encapsulation failed.
Success rate is 0 percent (0/5)
Router4#
В данном примере команда ping не работает из-за «неудачной инкапсуляции». Это означает, что маршрутизатору известно, на какой интерфейс следует отправлять пакет, но неизвестно, каким образом это сделать. В этом случае необходимо понять принцип функционирования ARP-протокола.
В основном, ARP — это протокол, используемый для сопоставления адреса второго уровня (MAC-адрес) с адресом третьего уровня (IP-адрес). Для проверки этого отображения можно использовать команду show arp:
Router4#show arp
Вернемся к проблеме неудачной инкапсуляции. Более подробные сведения об этой проблеме можно получить с помощью команды debug:
Router4#debug arp
ARP packet debugging is on
Router4#ping 100.0.0.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.5, timeout is 2 seconds:
Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 100.0.0.5
interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 100.0.0.4 0000.0c5d.7a0d,
dst 100.0.0.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)
В представленном выше результате выполнения команды показано, что маршрутизатор 4 транслирует пакеты, пересылая их на широковещательный Ethernet-адрес FFFF.FFFF.FFFF. В данном случае 0000.0000.0000 означает, что маршрутизатор 4 ищет MAC-адрес целевого устройства 100.0.0.5. Поскольку в этом примере он не знает MAC-адреса во время выполнения ARP-запроса, то он отсылает широковещательные кадры с интерфейса Ethernet 0 с адресом 0000.0000.000 в качестве шаблона и запрашивает, какой MAC-адрес соответствует IP-адресу 100.0.0.5. Если маршрутизатор не получает ответа, то соответствующий адрес в результате выполнения команды show arp помечается как неполный:
Router4#show arp
По прошествии определенного периода времени сведения о неполноте удаляются из ARP-таблицы. Пока соответствующий MAC-адрес отсутствует в ARP-таблице, выполнение команды ping будет заканчиваться неудачей в результате «неудачной инкапсуляции».
Задержка
По умолчанию если ответ от удаленного оконечного сетевого устройства не получен в течение двух секунд, то выполнение команды ping заканчивается неудачей:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)
В сетях с низкой скоростью передачи данных или с большой задержкой двух секунд времени ожидания может оказаться недостаточным. Это значение по умолчанию можно изменить с помощью выполнения расширенной команды ping:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]: 30
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 30 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms
В вышеприведенном примере увеличение времени ожидания привело к успешному выполнению команды ping.
Примечание. Среднее время приема-передачи составляет более двух секунд.
Исправление адреса-источника
В данном подразделе приведен пример типичной ситуации:
На маршрутизаторе 1 добавлен интерфейс LAN:
Router1(config)#interface e0
Router1(config-if)#ip address
Router1(config-if)#ip address 20.0.0.1 255.255.255.0
Из узла локальной сети (LAN) можно выполнить команду ping для маршрутизатора 1. Команду ping можно направить с маршрутизатора 1 на маршрутизатор 2. Но к маршрутизатору 2 невозможно применить команду ping из узла локальной сети (LAN).
Можно посылать пакеты проверки связи с маршрутизатора 1 на маршрутизатор 2, так как по умолчанию IP-адрес исходящего интерфейса используется в качестве адреса источника в ICMP-пакете. Маршрутизатор 2 не располагает сведениями об этой новой локальной сети (LAN). Если маршрутизатор должен ответить на пакет приходящий из этой сети, то он не знает как обрабатывать этот пакет.
Router1#debug ip packet
IP packet debugging is on
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms
Router1#
Jan 20 16:35:54.227: IP: s=12.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending
Jan 20 16:35:54.259: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 100, rcvd 3
Выходные данные из вышеприведенного примера работают, потому что адрес источника отправляемого пакета равен s = 12.0.0.1. Если необходимо смоделировать пакет, поступающий из локальной сети, то следует использовать расширенную команду ping:
Router1#ping
Protocol [ip]:
Target IP address: 12.0.0.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 20.0.0.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
Jan 20 16:40:18.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:20.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:22.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Jan 20 16:40:24.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending
Jan 20 16:40:26.303: IP: s=20.0.0.1 (local), d=12.0.0.2 (Serial0), len 100, sending.
Success rate is 0 percent (0/5)
Теперь исходным адресом является IP-адрес 20.0.0.1, который не функционирует! Пакеты могут быть переданы, но ответа на них не поступает. Для устранения этой проблемы необходимо добавить маршрут к IP-адресу 20.0.0.0 в маршрутизаторе 2.
Основное правило состоит в том, что устройству, получившему запрос о проверке доступности, должен быть известен способ отправки ответа источнику этого запроса.
Команда traceroute
Команда traceroute используется для отыскания маршрутов, которые будут использоваться при передаче пакетов к сетевому узлу назначения. Устройство (например, маршрутизатор или персональный компьютер) отправляет последовательность UDP-дейтаграмм на недопустимый адрес порта на удаленном хосте.
Отправляются три дейтаграммы со значением поля TTL (время существования) равным единице. Значение времени существования равное единице означает, что дейтаграмма перестанет существовать после достижения первого маршрутизатора на маршруте, а затем этот маршрутизатор отправит ICMP-сообщение о превышении времени существования, указывающее на истечение времени существования.
Теперь отправляются другие три UDP-сообщения со значением времени существования равным двум, что является причиной, по которой второй маршрутизатор возвращает ICMP-сообщение о превышении времени существования. Этот процесс продолжается до тех пор, пока пакеты не достигают другого пункта назначения. Так как эти дейтаграммы пытаются получить доступ к неверному порту на узле назначения, то этот узел возвращает ICMP-сообщения о недоступном порте. Это событие сигнализирует о необходимости завершить выполнение программы Traceroute.
После этого необходимо записать источник каждого ICMP-сообщения о превышении времени существования для обеспечения трассировки пути, по которому пакет попадает к адресату.
Router1#traceroute 34.0.0.4
Type escape sequence to abort.
Tracing the route to 34.0.0.4
1 12.0.0.2 4 msec 4 msec 4 msec
2 23.0.0.3 20 msec 16 msec 16 msec
3 34.0.0.4 16 msec * 16 msec
Jan 20 16:42:48.611: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.615: UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.639: ICMP type=11, code=0
!— ICMP-сообщение об истечении времени от маршрутизатора 2.
Jan 20 16:42:48.643: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.647: UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.671: ICMP type=11, code=0
Jan 20 16:42:48.675: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.679: UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=12.0.0.2 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.703: ICMP type=11, code=0
Это первая последовательность пакетов отправляемых с параметром TTL = 1. Первый маршрутизатор (в данном случае маршрутизатор 2 (12.0.0.2)) игнорирует пакет и посылает назад отправителю (12.0.0.1) ICMP-сообщение типа 11. Это соответствует сообщению о превышении времени существования.
Jan 20 16:42:48.707: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.711: UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.747: ICMP type=11, code=0
!— ICMP-сообщение об истечении времени от маршрутизатора 3.
Jan 20 16:42:48.751: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.755: UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.791: ICMP type=11, code=0
Jan 20 16:42:48.795: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.799: UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=23.0.0.3 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.831: ICMP type=11, code=0
Тот же самый процесс происходит и для маршрутизатора 3 (23.0.0.3) с параметром TTL = 2:
Jan 20 16:42:48.839: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.843: UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:48.891: ICMP type=3, code=3
!— Сообщение о недоступности порта от маршрутизатора 4.
Jan 20 16:42:48.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:48.899: UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=12.0.0.1 (local), d=34.0.0.4 (Serial0), len 28, sending
Jan 20 16:42:51.899: UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=34.0.0.4 (Serial0), d=12.0.0.1 (Serial0), len 56, rcvd 3
Jan 20 16:42:51.947: ICMP type=3, code=3
Маршрутизатор 4 можно достичь с параметром TTL = 3. На этот раз, поскольку порт недоступен, маршрутизатор 4 оправляет обратно на маршрутизатор 1 ICMP-сообщение с типом равным 3, сообщение о недоступности места назначения и код равный 3, означающий, что порт недостижим.
В нижеприведенной таблице содержатся символы, которые могут отображаться в результате выполнения команды traceroute.
Текстовые символы IP-трассировки
| Символ | Описание |
| nn msec | Время приема-передачи в миллисекундах для заданного числа тестовых сообщений при проверке каждого узла сети |
| * | Время жизни тестового сообщения |
| A | Административно запрещено (например, список контроля доступа) |
| Q | Отключение источника сообщения при перегрузке с предварительным возвратом сообщения (цель назначения перегружена) |
| I | Пользовательская проверка на прерывание |
| U | Порт недостижим |
| H | Хост недостижим |
| N | Сеть недостижима |
| P | Протокол недостижим |
| T | Тайм-аут |
| ? | Неизвестный тип пакета |
Пропускная способность
С помощью команд ping и traceroute можно получить время приема-передачи (RTT). Это время, необходимое для отправки эхо-пакета и получения ответа. Полезно иметь приблизительное представление о задержке в канале. Однако получаемые значения недостаточны точны для оценки пропускной способности.
Если адресом назначения является адрес самого маршрутизатора, то для этих пакетов должно быть произведено перенаправление. Процессор должен обработать данные из такого пакета и отправить ответ. Это не основная цель маршрутизатора. По определению, маршрутизатор спроектирован для маршрутизации пакетов. Ответ на запрос эхо-теста предлагается в качестве службы негарантированной доставки (best-effort – по возможности).
В качестве примера приведем результат выполнения команды ping между маршрутизатором 1 и маршрутизатором 2:
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Время приема-передачи (RTT) равно примерно четырем миллисекундам. После разрешения некоторых ресурсозатратных функций на маршрутизаторе 2 попытайтесь отправить команду ping с маршрутизатора 2 на маршрутизатор 1.
Router1#ping 12.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.2, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms
Время приема-передачи (RTT) значительно выросло. Маршрутизатор 2 очень занят, а ответ на запрос проверки связи не является его первостепенной задачей.
Лучшим способом проверки пропускной способности маршрутизатора является использование трафика, проходящего через него:
После чего маршрутизатором производится быстрое перенаправление пакетов и их обработка с наивысшим приоритетом. Для иллюстрации этого вернемся к основной сети:
Произведем опрос маршрутизатора 3 с маршрутизатора 1 с помощью команды ping:
Router1#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
Трафик проходит через маршрутизатор 2 и быстро коммутируется.
Теперь разрешим ресурсозатратные функции на маршрутизаторе 2:
Router1#ping 23.0.0.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 23.0.0.3, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms
Никаких различий почти не существует. Это связано с тем, что теперь на маршрутизаторе 2 пакеты обрабатываются на уровне прерывания.
Использование команды Debug
Использованные до сих пор команды debug давали нам понимание того, что происходит при использовании команды ping или traceroute. Они также могут оказаться полезными при поиске и устранении неполадок. Однако в реальных условиях отладка должна производиться с осторожностью. Если процессор не достаточно производительный или существует много перенаправляемых пакетов, то это может легко привести к падению производительности сетевого устройства. Существует пара методов для минимизации влияния выполнения команды debug на маршрутизатор. Один из способов — использование списков контроля доступа для ограничения трафика, который требуется контролировать. Ниже представлен пример этого:
Router4#debug ip packet?
Access list
Access list (expanded range)
detail Print more debugging detail
Router4#configure terminal
Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router4(config)#^Z
Router4#debug ip packet 150
IP packet debugging is on for access list 150
Router4#show debug
Generic IP:
IP packet debugging is on for access list 150
Router4#show access-list
Extended IP access list 150
permit ip host 12.0.0.1 host 34.0.0.4 (5 matches)
При этой конфигурации маршрутизатор 4 печатает сообщения отладки, соответствующие только списку контроля доступа 150. Команда ping, поступающая от маршрутизатора 1, приводит к отображению следующего сообщения:
Router4#
Jan 20 16:51:16.911: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.003: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.095: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.187: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:51:17.279: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Пакеты, не соответствующие списку контроля доступа, маршрутизатором 4 не отображаются. Для их просмотра необходимо добавить следующие команды:
Router4(config)#access-list 150 permit ip host 12.0.0.1 host 34.0.0.4
Router4(config)#access-list 150 permit ip host 34.0.0.4 host 12.0.0.1
После этого отобразятся следующие результаты:
Jan 20 16:53:16.527: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.531: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.627: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.635: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.727: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.731: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.823: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.827: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:53:16.919: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Jan 20 16:53:16.923: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Другим способом минимизации воздействия команды debug является помещение отладочных сообщений в буфер и их вывод после выключения отладки с помощью команды show log:
Router4#configure terminal
Router4(config)#no logging console
Router4(config)#logging buffered 5000
Router4(config)#^Z
Router4#debug ip packet
IP packet debugging is on
Router4#ping 12.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms
Router4#undebug all
All possible debugging has been turned off
Router4#show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 61 messages logged
Trap logging: level informational, 59 message lines logged
Log Buffer (5000 bytes):
Jan 20 16:55:46.587: IP: s=34.0.0.4 (local), d=12.0.0.1 (Serial0), len 100, sending
Jan 20 16:55:46.679: IP: s=12.0.0.1 (Serial0), d=34.0.0.4 (Serial0), len 100, rcvd 3
Как показано выше, команды ping и traceroute являются очень полезными при поиске и устранении проблем доступа к сети. Кроме того, они очень просты в применении. Так как эти две команды широко используются сетевыми инженерами, то понимание принципов их функционирования является очень важным при поиске и устранении неисправностей подключения к сети.
Есть вопросы?
Обращайтесь в «Аквилон-А», чтобы узнать подробности и получить именно то, что вам требуется.
- Статьи
- Решения эконом класса
- Маршрутизаторы Linksys
- Коммутаторы Linksys
- Маршрутизаторы
- Cisco 800, Cisco 1800,
- Cisco 2800, Cisco 3800
- Catalyst Express 500, Catalyst 2960,
- Catalyst 3560, Catalyst 3750
- Cisco 500 Series Wireless Express
- Cisco Aironet 1130AG Series
- Cisco Aironet 1240AG Series
- Cisco Aironet 1310 и 1410 Series
- Контроллер сети Cisco 2100 Series
- Cisco ASA
- Маршрутизаторы
- Cisco 7200, Cisco 7600
- Catalyst 4500, Catalyst 4900, Catalyst 6500
- Контроллер сети Cisco 4400 Series
- Cisco ASA
- IP-видеокамеры
- Серия 2500, Серия 4000
- Телефоны IP Phones 7900 Series
- Приложения:
- Unified Com Mgr Express
- Unified Com Mgr BE
- Smart Business Com System
- Unity Express, Unity Connection
Чтобы связаться с нашими менеджерами, Вы можете:
сделать заказ, задать любой вопрос
позвонить по телефону 977 422-05-25 (многоканальный)