Как пинговать пк в cisco packet tracer
Перейти к содержимому

Как пинговать пк в cisco packet tracer

  • автор:

Основы работы с Cisco Packet Tracer

Основы работы с Cisco Packet Tracer

Цель данной статьи заключается в том, чтобы познакомится с основными принципами работы, чтобы понять как работать в программе Cisco Packet Tracer на примере создание простой локальной вычислительной сети, путем описания пошаговых инструкции по настройке.

Характеристика Cisco Packet Tracer

Cisco Packet Tracer разработан компанией Cisco и рекомендован использоваться при изучении телекоммуникационных сетей и сетевого оборудования, а также для проведения уроков по лабораторным работам в высших заведениях.

Основные возможности Packet Tracer:

  • Дружественный графический интерфейс (GUI), что способствует к лучшему пониманию организации сети, принципов работы устройства;
  • Возможность смоделировать логическую топологию: рабочее пространство для того, чтобы создать сети любого размера на CCNA-уровне сложности;
  • моделирование в режиме real-time (реального времени);
  • режим симуляции;
  • Многоязычность интерфейса программы: что позволяет изучать программу на своем родном языке.
  • усовершенствованное изображение сетевого оборудования со способностью добавлять / удалять различные компоненты;
  • наличие Activity Wizard позволяет сетевым инженерам, студентам и преподавателям создавать шаблоны сетей и использовать их в дальнейшем.
  • проектирование физической топологии: доступное взаимодействие с физическими устройствами, используя такие понятия как город, здание, стойка и т.д.;

Широкий круг возможностей данного продукта позволяет сетевым инженерам: конфигурировать, отлаживать и строить вычислительную сеть. Также данный продукт незаменим в учебном процессе, поскольку дает наглядное отображение работы сети, что повышает освоение материала учащимися.

Эмулятор сети позволяет сетевым инженерам проектировать сети любой сложности, создавая и отправляя различные пакеты данных, сохранять и комментировать свою работу. Специалисты могут изучать и использовать такие сетевые устройства, как коммутаторы второго и третьего уровней, рабочие станции, определять типы связей между ними и соединять их.

На заключительном этапе, после того как сеть спроектирована, специалист может приступать к конфигурированию выбранных устройств посредством терминального доступа или командной строки (рисунок 1).

Рисунок 1 — Cisco Packet Tracer

Одной из самых важных особенностей данного симулятора является наличие в нем «Режима симуляции» (рисунок 2). В данном режиме все пакеты, пересылаемые внутри сети, отображаются в графическом виде. Эта возможность позволяет сетевым специалистам наглядно продемонстрировать, по какому интерфейсу в данные момент перемещается пакет, какой протокол используется и т.д.

Рисунок 2 — Режим «Симуляции» в Cisco Packet Tracer

Однако, это не все преимущества Packet Tracer: в «Режиме симуляции» сетевые инженеры могут не только отслеживать используемые протоколы, но и видеть, на каком из семи уровней модели OSI данный протокол задействован (рисунок 3).

Рисунок 3 — Анализ семиуровневой модели OSI в Cisco Packet Tracer

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

Packet Tracer способен моделировать большое количество устройств различного назначения, а так же немало различных типов связей, что позволяет проектировать сети любого размера на высоком уровне сложности.

  • коммутаторы третьего уровня:
    • Router 2620 XM;
    • Router 2621 XM;
    • Router-PT.
    • Switch 2950-24;
    • Switch 2950T;
    • Switch-PT;
    • соединение типа «мост» Bridge-PT.
    • Hub-PT;
    • повторитель Repeater-PT.
    • рабочая станция PC-PT;
    • сервер Server-PT;
    • принтер Printer-PT.
    • точка доступа AccessPoint-PT.
    • консоль;
    • медный кабель без перекрещивания (прямой кабель);
    • медный кабель с перекрещиванием (кросс-кабель); ;
    • телефонная линия;
    • Serial DCE;
    • Serial DTE.

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

      ;
    • CDP;
    • DHCP;
    • EIGRP; ;
    • RIP; ; .

    Интерфейс Cisco Packet Tracer

    Интерфейс программы Cisco Packet Tracer представлен на рисунке 4.

    Рисунок 4 – Интерфейс программы Cisco Packet Tracer

    1. Главное меню программы;
    2. Панель инструментов – дублирует некоторые пункты меню;
    3. Переключатель между логической и физической организацией;
    4. Ещё одна панель инструментов, содержит инструменты выделения, удаления, перемещения, масштабирования объектов, а так же формирование произвольных пакетов;
    5. Переключатель между реальным режимом (Real-Time) и режимом симуляции;
    6. Панель с группами конечных устройств и линий связи;
    7. Сами конечные устройства, здесь содержатся всевозможные коммутаторы, узлы, точки доступа, проводники.
    8. Панель создания пользовательских сценариев;
    9. Рабочее пространство;

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

    Сверху, над рабочей областью, расположена главная панель программы и ее меню. Меню позволяет выполнять сохранение, загрузку сетевых топологий, настройку симуляции, а также много других интересных функций. Главная панель содержит на себе наиболее часто используемые функции меню.

    Рисунок 5 — Главное меню Packet Tracer

    Справа от рабочей области, расположена боковая панель, содержащая ряд кнопок отвечающих за перемещение полотна рабочей области, удаление объектов и т.д.

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

    Рисунок 6 — Панель оборудования Packet Tracer

    Данная панель содержит в своей левой части типы доступных устройств, а в правой части доступные модели. При выполнении различных лабораторных работ, эту панель придется использовать намного чаще, чем все остальные. Поэтому рассмотрим ее более подробно.

    При наведении на каждое из устройств, в прямоугольнике, находящемся в центре между ними будет отображаться его тип. Типы устройств, наиболее часто используемые в лабораторных работах Packet Tracer, представлены на рисунке 7.

    Рисунок 7 — Основные типы устройств

    Рассматривать конкретные модели устройств каждого типа, не имеет большого смысла. Отдельного рассмотрения заслуживают типы соединений. Перечислим наиболее часто используемые из них (рассмотрение типов подключений идет слева направо, в соответствии с приведенным на рисунке 8).

    Рисунок 8 — Типы соединений устройств в Packet Tracer

    • Автоматический тип – при данном типе соединения PacketTracer автоматически выбирает наиболее предпочтительные тип соединения для выбранных устройств
    • Консоль – консольные соединение
    • Медь Прямое – соединение медным кабелем типа витая пара, оба конца кабеля обжаты в одинаковой раскладке. Подойдет для следующих соединений: коммутатор – коммутатор, коммутатор – маршрутизатор, коммутатор – компьютер и др.
    • Медь кроссовер – соединение медным кабелем типа витая пара, концы кабеля обжаты как кроссовер. Подойдет для соединения двух компьютеров.
    • Оптика – соединение при помощи оптического кабеля, необходимо для соединения устройств имеющих оптические интерфейсы.
    • Телефонный кабель – обыкновенный телефонный кабель, может понадобится для подключения телефонных аппаратов.
    • Коаксиальный кабель – соединение устройств с помощью коаксиального кабеля.

    Пример локальной вычислительной сети

    Рассмотрим на примере создание локальной вычислительной сети в cisco packet tracer, сеть представлена на рисунке 9. Далее описывается пошаговая инструкция.

    Рисунок 9 – Пример сети в cisco packet tracer

    Как известно, локальная вычислительная сеть – это компьютерная сеть, покрывающая обычно относительно небольшую территорию или небольшую группу зданий. В нашем случае это всего-навсего 6 рабочих станций, определенным образом связанных между собой. Для этого используются сетевые концентраторы (хабы) и коммутаторы (свичи).

    Последовательность выполняемых действий:

    1. В нижнем левом углу Packet Tracer выбираем устройства «Сетевые коммутаторы», и, в списке справа, выбираем коммутатор 2950-24,нажимая на него левой кнопкой мыши, вставляем его в рабочую область. Так же поступает с «Сетевым концентратором (Hub-PT)» и «Рабочими станциями (PC-PT)», в соответствии с рисунками 10, 11, 12, 13.

    Рисунок 10 – Выбирается коммутатор 2950-24

    Рисунок 11 – Выбирается концентратор Hub-PT

    Рисунок 12 – Выбирается персональный компьютер PC-PT

    Рисунок 13 – Размещение компьютеров, коммутатора и концентратора на рабочей области

    2. Далее необходимо соединить устройства, как показано на рисунке 8, используя соответствующий интерфейс. Для соединения компьютеров к коммутатору и концентратору используется кабель типа «медный прямой», в соответствии с рисунком 14.

    Рисунок 14 – Выбор типа кабеля «медный прямой»

    А для соединения между собой коммутатора и концентратора используется медный кроссовер кабель, в соответствии с рисунком 15.

    Рисунок 15 – Выбор типа кабеля «медный кроссовер»

    Далее, для соединения двух устройств, необходимо выбрать соответствующий вид кабеля и нажать на одно устройство (выбрав произвольный свободный порт FastEthernet) и на другое устройство (также выбрав произвольный свободный порт FastEthernet), в соответствии с рисунками 16, 17, 18.

    Рисунок 16 – Выбирается свободный порт на компьютере

    Рисунок 17 – Выбирается свободный порт на коммутаторе

    Рисунок 18 – Соединение медным прямым кабелем ПК 0 и коммутатор 0

    Аналогично выполняется соединение для всех остальных устройств

    Важно! Соединение между коммутатором и концентратором выполняется кроссовером.

    Результат подключения устройств представлен на рисунке 19.

    Рисунок 19 – Подключение устройств между собой.

    3. Далее идет самый важный этап – настройка. Так как мы используем устройства, работающие на начальных уровнях сетевой модели OSI (коммутатор на 2ом, концентратор – на 1ом), то их настраивать не надо. Необходима лишь настройка рабочих станций, а именно: IP-адреса, маски подсети.

    Ниже приведена настройка лишь одной станции (PC1) – остальные настраиваются аналогично.

    Производим двойной щелчок по нужной рабочей станции, в соответствии с рисунком 20.

    Рисунок 20 – Окно настройки компьютера PC0.

    В открывшемся окне выбирается вкладку Рабочий стол, далее – «Настройка IP», в соответствии с рисунком 21.

    Рисунок 21 – Окно настройки компьютера PC0, вкладка «Рабочий стол».

    Открывается окно, в соответствии с рисунком 22, где нужно ввести IP-адрес и маску.

    Рисунок 22 – Ввод статического IP-адреса и маски

    Аналогично присваиваются IP-адреса всем остальным компьютерам.

    Важно! IP-адреса всех рабочих станций должны находиться в одной и той-же подсети (то есть из одного диапазона), иначе процесс ping не выполнится.

    Шлюз. Поле можно не заполнять.

    DNS-сервер. Поле можно не заполнять.

    4. Когда настройка завершена, выполняется ping-процесс. Например, запускается с PC5 и проверять наличие связи с PC1.

    Важно! Можно произвольно выбирать, откуда запускать ping-процесс, главное, чтобы выполнялось условие: пакеты должны обязательно пересылаться через коммутатор и концентратор.

    Для этого производим двойной щелчок по нужной рабочей станции, в открывшемся окне выбираем вкладку «Рабочий стол», далее – «Командная строка», в соответствии с рисунком 23.

    Рисунок 23 – Выбор режима «Командная строка»

    Откроется окно командной строки, в соответствии с рисунком 24.

    Рисунок 24 – Режим «Командная строка»

    Нам предлагают ввести команду, что мы и делаем:

    Нажимаем клавишу Enter. Если все настроено верно, то мы увидим следующую информацию, представленную на рисунке 25.

    Рисунок 25 – Результат выполнение команды «ping»

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

    Также Packet Tracer позволяет выполнять команду «ping» значительно быстрее и удобнее. Для этого, выбирается на боковой панели сообщение, в соответствии с рисунком 26.

    Рисунок 26 – Выбирается сообщение, для выполнение команды «ping»

    Далее нужно кликнуть мышкой по компьютеру от кого будет передавать команда «ping» и еще раз щелкнуть по компьютеру, до которого будет выполнять команда «ping». В результате будет выполнена команда «ping», результат отобразиться в нижнем правом угле, в соответствии с рисунком 27.

    Для более детального отображения результата выполнения команды выберите «Переключить окно списка PDU», в соответствии с рисунком 28.

    Рисунок 27 – Результат выполнения команды «ping»

    Рисунок 28 – Результат выполнения команды «ping»

    5. В Packet Tracer предусмотрен режим моделирования, в котором подробно описывается и показывается, как работает утилита Ping. Поэтому необходимо перейти в «режим симуляции», нажав на одноименный значок в нижнем левом углу рабочей области, или по комбинации клавиш Shift+S. Откроется «Панель моделирования», в которой будут отображаться все события, связанные с выполнения ping-процесса, в соответствии с рисунком 29.

    Рисунок 29 – Переход в «режим симуляции»

    Перед выполнение симуляции необходимо задать фильтрацию пакетов. Для этого нужно нажать на кнопку «Изменить фильтры», откроется окно, в соответствии с рисунком 30, в котором нужно оставить только «ICMP» и «ARP».

    Рисунок 30 – Настройка фильтра

    Теперь необходимо повторить запуск ping-процесса. После его запуска можно сдвинуть «Панель моделирования», чтобы на схеме спроектированной сети наблюдать за отправкой/приемкой пакетов.

    Рисунок 31 – Выполнение процесса симуляции

    Кнопка «Авто захват/Воспроизведение» подразумевает моделирование всего ping-процесса в едином процессе, тогда как «Захват/Вперед» позволяет отображать его пошагово.

    Чтобы узнать информацию, которую несет в себе пакет, его структуру, достаточно нажать правой кнопкой мыши на цветной квадрат в графе «Информация».

    Моделирование прекращается либо при завершении ping-процесса, либо при закрытии окна «Редактирования» соответствующей рабочей станции.

    Для удаления задания нажимается кнопка «Удалить» в нижней части экрана.

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

    Practice lab to learn how to ping in the Cisco packet tracer and solve the ping request timed out error.

    To ping one PC from another on LAN, we just have to assign them the IP address however IP addresses should be from the same subnet otherwise ping will show a request timed out error.

    Download the lab and ping PC1 from PC0, you will see the request timed out error. To fix the error, assign the appropriate IP address to any one PC from the same subnet.

    Pinging PC on the other network

    PC0 is unable to ping PC2 on the other network and receives an error request timed out. When we ping the device on the other network then the traffic is routed through the router so we should have the default gateway assigned to the PC and the default gateway should be the IP address of the connected interface of the router.

    The default gateway should also be configured on the PC2 so that PC2 can successfully send the ping reply back. If the remote PC will not have the gateway assigned then although the PC is receiving the ping request however it will not be able to send a ping reply and as the sender resides on another network and PC2 does not know where to send the traffic for the other network.

    Both PCs are missing the default gateway, download the lab and assign the default gateway on both PCs for successful ping communication.

    How to ping switch in packet tracer

    To ping the switch, we have to assign an IP address to the switch. We cannot assign an IP address to the switch interface so we have to assign an IP address to the virtual interface.

    In every switch, a virtual interface is present by default which is VLAN 1 interface so assign an IP address to this interface to ping the switch.

    How to ping a router in a packet tracer

    The IP address can be assigned to the router interface so to ping the router, we can ping the interfaces present on the router. However, those interfaces should have the IP address assigned.

    In this lab, IP addresses 192.168.1.1 and 192.168.2.1 have been assigned to router interfaces. Try pinging those IP addresses from the PC.

    Ping blocked by firewall in packet tracer

    If the firewall is configured on the PC to block the ping request then a ping request timed out error will be shown so we should check if the firewall has been configured on the remote host that is blocking the ping command.

    The packet tracer allows us to configure a firewall on the PCs. In this lab, you can see that the firewall rule has been defined to block the ping request so the PC0 is not able to ping PC2 and PC0 is receiving the timed out error.

    To solve the issue, either disable the firewall or delete the defined rule.

    20.3.6 Packet Tracer – Use the ping Command Answers

    Use the ping command to identify an incorrect configuration on a PC.

    Background / Scenario

    A small business owner learns that some users are unable to access a website. All PCs are configured with static IP addressing. Use the ping command to identify the issue.

    Instructions

    Part 1: Verify connectivity.

    Access the Desktop tab > Web Browser of each PC and enter the URL www.cisco.pka. Identify any PCs that are not connecting to the web server.

    Note: All the devices require time to complete the boot process. Please allow up to one minute before receiving a web response.

    Which PCs are unable to connect to the web server?

    Part 2: Ping the web server from PC with connectivity issues.

    1. On the PC, access the Command Prompt from the Desktop tab.

    2. At the prompt, enter ping www.cisco.pka.

    Did the ping return a reply? What is the IP address displayed in the reply, if any?

    There was no reply. No IP address was displayed in the message.

    Part 3: Ping the web server from correctly configured PCs.

    1. On the PC, access the Command Prompt from the Desktop tab.

    2. At the prompt, enter ping www.cisco.pka.

    Did the ping return a reply? What is the IP address returned, if any?

    Reply was returned with 192.15.2.10 as the IP address for www.cisco.pka.

    Part 4: Ping the IP address of the web server from PCs with connectivity issues.

    1. On the PC, access the Command Prompt from the Desktop tab.

    2. Attempt to reach the IP address of the web server with the ping command.

    Did the ping return a reply? If so, then the PC can reach the web server via IP address, but not domain name. This could indicate a problem with the DNS server configuration on the PC.

    Part 5: Compare the DNS server information on the PCs.

    1. Access the Command Prompt of the PCs without any issues.

    2. Using the command ipconfig /all, examine the DNS server configuration on the PCs without any issues.

    3. Access the Command Prompt of the PCs with connectivity issues.

    4. Using the command ipconfig /all, examine the DNS server configuration on the PCs with misconfigurations. Do the two configurations match?

    Part 6: Make any necessary configuration changes on the PCs.

    1. Navigate to the Desktop tab of the PCs with issues, make any necessary configuration changes in IP Configuration.

    Как отправить эхо запрос cisco packet tracer

    В этой статье рассматривается использование команд 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-протокола.

    В нижеприведенной таблице содержатся сведения о символах, которые могут содержаться в результатах выполнения команды 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?
    <1-199> Access list
    <1300-2699> 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 являются очень полезными при поиске и устранении проблем доступа к сети. Кроме того, они очень просты в применении. Так как эти две команды широко используются сетевыми инженерами, то понимание принципов их функционирования является очень важным при поиске и устранении неисправностей подключения к сети.

    Есть вопросы?
    Обращайтесь в "Аквилон-А", чтобы узнать подробности и получить именно то, что вам требуется.

    Subnets.ru blog

    ping — это служебная компьютерная программа, предназначенная для проверки соединений в сетях на основе TCP/IP .

    Она отправляет запросы Echo-Request протокола Internet Control Message Protocol ( ICMP) указанному узлу сети и фиксирует поступающие ответы (ICMP Echo-Reply). Время между отправкой запроса и получением ответа (RTT, от англ. Round Trip Time ) позволяет определять двусторонние задержки (RTT) по маршруту и частоту потери пакетов, то есть косвенно определять загруженности каналов передачи данных и промежуточных устройств.

    Также пингом называется время, затраченное на передачу пакета информации в компьютерных сетях от клиента к серверу и обратно от сервера к клиенту, оно измеряется в миллисекундах. Время пинга связано со скоростью соединения и загруженностью каналов на всём протяжении от клиента к серверу.

    Полное отсутствие ICMP-ответов может также означать, что удалённый узел (или какой-либо из промежуточных маршрутизаторов) блокирует ICMP Echo-Reply или игнорирует ICMP Echo-Request.

    Программа ping является одним из основных диагностических средств в сетях TCP/IP и входит в поставку всех современных сетевых операционных систем. Функциональность ping также реализована в некоторых встроенных ОС маршрутизаторов.

    Типы ICMP:

    • 0 echo-reply
    • 3 destination unreachable
      • code 0 = net unreachable
      • 1 = host unreachable
      • 2 = protocol unreachable
      • 3 = port unreachable
      • 4 = fragmentation needed and DF set
      • 5 = source route failed
      • code 0 = redirect datagrams for the network
      • 1 = redirect datagrams for the host
      • 2 = redirect datagrams for the type of service and network
      • 3 = redirect datagrams for the type of service and host
      • code 0 = time to live exceeded in transit 1 = fragment reassembly time exceeded

      Многие знают и умеют пользоваться командой ping и traceroute, но не все знают, что же означают символы выводимые на консоль в устройствах Cisco Systems:

      Рассмотрим символы выводимые в консоль cisco при команде ping:

      ! — Каждый символ восклицательно знака показывает ответ (echo reply).
      . — Каждый символ точки показывает потерю пакета, таймаут ожидания (echo reply).
      U — Указанный хост недостижим (был получен destination unreachable error PDU).
      Q — сдерживание источника (есть угроза перегрузки (destination too busy)).
      M — Невозможность фрагментировать.
      ? — Неизвестный тип пакета.
      & — Время жизни пакета истекло.

      traceroute — это служебная компьютерная программа, предназначенная для определения маршрутов следования данных в сетях TCP/IP . Traceroute так же как и ping основана на протоколе ICMP.

      Программа traceroute выполняет отправку данных указанному узлу сети, при этом отображая сведения о всех промежуточных маршрутизаторах, через которые прошли данные на пути к целевому узлу. В случае проблем при доставке данных до какого-либо узла программа позволяет определить, на каком именно участке сети возникли неполадки.

      traceroute входит в поставку большинства современных сетевых операционных систем:

      • в системах Microsoft Windows эта программа носит название tracert
      • в системах Unix — traceroute

      Для определения промежуточных маршрутизаторов traceroute отправляет серию пакетов данных целевому узлу, при этом каждый раз увеличивая на 1 значение поля TTL («время жизни»). Это поле обычно указывает максимальное количество маршрутизаторов, которое может быть пройдено пакетом. Первый пакет отправляется с TTL, равным 1, и поэтому первый же маршрутизатор возвращает обратно сообщение ICMP, указывающее на невозможность доставки данных. Traceroute фиксирует адрес маршрутизатора, а также время между отправкой пакета и получением ответа (эти сведения выводятся на монитор компьютера). Затем traceroute повторяет отправку пакета, но уже с TTL, равным 2, что позволяет первому маршрутизатору пропустить пакет дальше.

      Процесс повторяется до тех пор, пока при определённом значении TTL пакет не достигнет целевого узла. При получении ответа от этого узла процесс трассировки считается завершённым.

      Пример команды на оборудовании Cisco Systems:

      В консоль так же могут выводиться спец. символы, вот они:

      * — Таймаут ожидания ответа (timed out)
      A — Административно запрещено (трафик запрещен администратором сети, например в access-list)
      Q — сдерживание источника (есть угроза перегрузки (destination too busy)).
      I — Пользователь прервал выполнение теста
      U — Порт недостижим (закрыт)
      H — Хост недоступен (unreachable), например отсутствует маршрут до сети хоста
      N — Сеть недоступна (unreachable)
      P — Протокол недоступен (unreachable)
      T — Таймаут (timeout)
      ? — Неизвестный тип пакета

      Как отправить эхо запрос cisco packet tracer

      ping — это служебная компьютерная программа, предназначенная для проверки соединений в сетях на основе TCP/IP .

      Она отправляет запросы Echo-Request протокола Internet Control Message Protocol ( ICMP) указанному узлу сети и фиксирует поступающие ответы (ICMP Echo-Reply). Время между отправкой запроса и получением ответа (RTT, от англ. Round Trip Time ) позволяет определять двусторонние задержки (RTT) по маршруту и частоту потери пакетов, то есть косвенно определять загруженности каналов передачи данных и промежуточных устройств.

      Также пингом называется время, затраченное на передачу пакета информации в компьютерных сетях от клиента к серверу и обратно от сервера к клиенту, оно измеряется в миллисекундах. Время пинга связано со скоростью соединения и загруженностью каналов на всём протяжении от клиента к серверу.

      Полное отсутствие ICMP-ответов может также означать, что удалённый узел (или какой-либо из промежуточных маршрутизаторов) блокирует ICMP Echo-Reply или игнорирует ICMP Echo-Request.

      Программа ping является одним из основных диагностических средств в сетях TCP/IP и входит в поставку всех современных сетевых операционных систем. Функциональность ping также реализована в некоторых встроенных ОС маршрутизаторов.

      Типы ICMP:

      • 0 echo-reply
      • 3 destination unreachable
      • code 0 = net unreachable
      • 1 = host unreachable
      • 2 = protocol unreachable
      • 3 = port unreachable
      • 4 = fragmentation needed and DF set
      • 5 = source route failed
      • code 0 = time to live exceeded in transit 1 = fragment reassembly time exceeded

      Многие знают и умеют пользоваться командой ping и traceroute, но не все знают, что же означают символы выводимые на консоль в устройствах Cisco Systems:

      Рассмотрим символы выводимые в консоль cisco при команде ping:

      ! — Каждый символ восклицательно знака показывает ответ (echo reply).
      . — Каждый символ точки показывает потерю пакета, таймаут ожидания (echo reply).
      U — Указанный хост недостижим (был получен destination unreachable error PDU).
      Q — сдерживание источника (есть угроза перегрузки (destination too busy)).
      M — Невозможность фрагментировать.
      ? — Неизвестный тип пакета.
      & — Время жизни пакета истекло.

      traceroute — это служебная компьютерная программа, предназначенная для определения маршрутов следования данных в сетях TCP/IP . Traceroute так же как и ping основана на протоколе ICMP.

      Программа traceroute выполняет отправку данных указанному узлу сети, при этом отображая сведения о всех промежуточных маршрутизаторах, через которые прошли данные на пути к целевому узлу. В случае проблем при доставке данных до какого-либо узла программа позволяет определить, на каком именно участке сети возникли неполадки.

      traceroute входит в поставку большинства современных сетевых операционных систем:

      • в системах Microsoft Windows эта программа носит название tracert
      • в системах Unix — traceroute

      Для определения промежуточных маршрутизаторов traceroute отправляет серию пакетов данных целевому узлу, при этом каждый раз увеличивая на 1 значение поля TTL («время жизни»). Это поле обычно указывает максимальное количество маршрутизаторов, которое может быть пройдено пакетом. Первый пакет отправляется с TTL, равным 1, и поэтому первый же маршрутизатор возвращает обратно сообщение ICMP, указывающее на невозможность доставки данных. Traceroute фиксирует адрес маршрутизатора, а также время между отправкой пакета и получением ответа (эти сведения выводятся на монитор компьютера). Затем traceroute повторяет отправку пакета, но уже с TTL, равным 2, что позволяет первому маршрутизатору пропустить пакет дальше.

      Процесс повторяется до тех пор, пока при определённом значении TTL пакет не достигнет целевого узла. При получении ответа от этого узла процесс трассировки считается завершённым.

      Пример команды на оборудовании Cisco Systems:

      В консоль так же могут выводиться спец. символы, вот они:

      * — Таймаут ожидания ответа (timed out)
      A — Административно запрещено (трафик запрещен администратором сети, например в access-list)
      Q — сдерживание источника (есть угроза перегрузки (destination too busy)).
      I — Пользователь прервал выполнение теста
      U — Порт недостижим (закрыт)
      H — Хост недоступен (unreachable), например отсутствует маршрут до сети хоста
      N — Сеть недоступна (unreachable)
      P — Протокол недоступен (unreachable)
      T — Таймаут (timeout)
      ? — Неизвестный тип пакета

      Параметры загрузки

      Содержание

      Введение

      В этом документе объясняется, как использовать расширенные команды ping и traceroute. Сведения о стандартных командах ping и traceroute широко представлены в следующих документах:

      Предварительные условия

      Требования

      Данный документ требует наличия основных сведений о командах ping и traceroute, ссылки на подробные описания которых приведены в разделе "Введение".

      Используемые компоненты

      Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:

      ПО Cisco IOS® версии 12.2(10b)

      Маршрутизаторы всех серий Cisco

      Данные для этого документа были получены при тестировании указанных устройств в специально созданных лабораторных условиях. Все устройства, описанные в данном документе, обладают ненастроенной (заданной по умолчанию) конфигурацией. При работе в действующей сети необходимо изучить все возможные последствия каждой команды.

      Условные обозначения

      Дополнительные сведения о применяемых в документе обозначениях см. в Условные обозначения, используемые в технической документации Cisco

      Команда ping

      Команда ping (Packet InterNet Groper) является очень распространенным средством для устранения неполадок, связанных с доступом к устройствам. В ней для определения активности удаленного хоста используются два типа сообщений протокола ICMP – эхо-запрос и эхо-ответ. Команда ping также измеряет количество времени, необходимого для получения эхо-ответа.

      Команда ping сначала посылает пакет эхо-запроса на адрес, а затем ожидает ответа. Эхо-тест является удачным только в том случае, если ECHO REQUEST попадает в место назначения, и место назначения может отправить ECHO REPLY к источнику эхо-теста в течение заданного временного интервала.

      Расширенная команда ping

      Если от маршрутизатора посылается обычная команда ping, адрес источника этой команды ping является IP-адресом интерфейса, который используется пакетом для выхода из маршрутизатора. При использовании расширенной команды ping IP-адрес источника может быть изменен на любой IP-адрес в маршрутизаторе. Расширенная команда ping используется для более тщательной проверки доступности хоста и возможности сетевого подключения. Расширенная команда ping работает только в привилегированной командной строке EXEC. Обычная команда ping работает как в пользовательском, так и в привилегированном режиме EXEC. Чтобы использовать эту функцию, введите ping в командной строке и нажмите Возврат. Будет предложено заполнить поля, как показано в разделе Описания полей команды ping этого документа.

      Описания полей команды ping

      В этой таблице приведены описания полей команды ping. Эти поля могут быть изменены с помощью расширенной команды ping.

      Запрос поддерживаемого протокола. Введите appletalk, clns, ip, novell, apollo, vines, decnet или xns. По умолчанию используется ip.

      Target IP address:

      Запрашивает IP-адрес или имя хоста узла назначения, для которого планируется выполнение эхо-теста. Если в качестве поддерживаемого протокола указан не протокол IP, введите здесь соответствующий адрес для указанного протокола. По умолчанию не используется.

      Число ping-пакетов, передаваемых на адрес назначения. Значение по умолчанию – 5.

      Datagram size [100]:

      Размер ping-пакета (в байтах). По умолчанию: 100 байт

      Timeout in seconds [2]:

      Интервал времени ожидания. По умолчанию: 2 секунды. Запрос "ICMP-эхо" считается успешным, только если пакет ЭХО-ОТВЕТА получен до этого временного промежутка.

      Extended commands [n]:

      Указывает на появление или отсутствие дополнительных команд. По умолчанию не используется.

      Source address or interface:

      Интерфейс или IP адрес маршрутизатора будут использованы в качестве адреса отправителя для тестирования. Обычно IP-адрес для использования исходящим интерфейсом выбирает маршрутизатор. Интерфейс также может использоваться, но с корректным синтаксисом, как показано ниже:

      Примечание. Выше приведены неполные выходные данные расширенной команды ping. Интерфейс не может быть записан как e0.

      Type of service [0]:

      Определяет тип обслуживания (ToS). Запрошенный ToS размещен в каждом тестовом пакете, но нет гарантии, что все маршрутизаторы смогут обработать ToS. Это выбор качества Интернет-обслуживания. Значение по умолчанию – 0.

      Set DF bit in IP header? [no]:

      Задает необходимость включения бита "Не фрагментировать" (DF) в пакете ping-трассировки. Если необходимость будет подтверждена, параметр "Не фрагментировать" не разрешает фрагментацию пакета, когда он должен пройти через сегмент с меньшей максимальной единицей передачи данных (MTU), и выдается сообщение об ошибке от устройства, которое должно было фрагментировать пакет. Это используется для определения минимальной единицы MTU на тракте к адресату. По умолчанию используется значение "no".

      Validate reply data? [no]:

      Указывает, следует ли проверять ответные данные. По умолчанию используется значение "no".

      Data pattern [0xABCD]

      Задает шаблон данных. Для устранения ошибок кадрирования и проблем синхронизации на линиях последовательной передачи используются разные шаблоны данных. По умолчанию используется шаблон [0xABCD].

      Loose, Strict, Record, Timestamp, Verbose[none]:

      Параметры IP-заголовка. Это приглашение предлагает выбрать более одного параметра. Типичные сбои:

      Verbose – автоматически выбирается вместе с любым другим параметром.

      Record является очень полезным параметром: он позволяет показать адреса узлов (до девяти), через которые проходит пакет.

      Loose — влияет на тракт за счет определения адреса (адресов) узлов, через которые выполняется передача пакета.

      Strict используется для указания узлов, через которые должен пройти пакет, но при этом прохождение через другие узлы не разрешается.

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

      Различие между использованием параметра Record этой команды и использованием команды traceroute состоит в том, что параметр Record этой команды не только информирует об участках тракта, пройденных эхо-запросом (ping) до места назначения, но также информирует об участках, через которые запрос прошел на обратном пути. Команда traceroute не предоставляет информацию о тракте, пройденном эхо-ответом. Команда traceroute выдает приглашения для заполнения обязательных полей. Команда traceroute устанавливает запрошенный параметр для каждого теста. Однако нет гарантии, что все маршрутизаторы (или конечные узлы) обработают эти параметры. По умолчанию не используется.

      Sweep range of sizes [n]:

      Позволяет менять размеры отправляемых эхо-пакетов. Эта команда используется для определения минимальных размеров MTU, настроенных для узлов на тракте к адресату. Таким образом, устраняется снижение производительности, вызванное фрагментацией пакетов. По умолчанию используется значение "no".

      Каждый восклицательный знак (!) указывает на получение ответа. Точка (.) означает, что время ожидания ответа сетевым сервером истекло. Описание остальных символов см. в разделе символы эхо-тестирования.

      Success rate is 100 percent

      Процент пакетов, успешно возвращенных маршрутизатору. Результаты со значением менее 80 процентов обычно указывают на наличие проблем.

      round-trip min/avg/max = 1/2/4 ms

      Интервалы времени полного обхода для эхо-пакетов протокола, включая минимальные/средние/максимальные значения (в миллисекундах)

      Нижеприведенная диаграмма показывает, что хост 1 и хост 2 не могут обмениваться ping-пакетами. Вы можете проверить наличие этой неисправности на маршрутизаторах, чтобы определить, является ли она проблемой маршрутизации, или у одного из двух узлов неправильно настроен шлюз по умолчанию.

      Для выполнения эхо-тестирования из хоста 1 к хосту 2 каждый хост должен указать маршрутизатору шлюз по умолчанию на соответствующем сегменте LAN, или он должен обменяться сетевой информацией с маршрутизаторами, использующими некоторый протокол маршрутизации. Если для одного из хостов задан неверный шлюз или указаны неверные маршруты в таблице маршрутизации, он не сможет отправлять пакеты на адреса, отсутствующие в ARP (Кэш протокола разрешения адресов). Также возможно, что хосты не могут обмениваться ping -пакетами по причине того, что для одного из маршрутизаторов не указан маршрут в подсеть, из которой хост посылает свои эхо-пакеты.

      Пример

      Ниже приведен пример команды расширенной ping команды, источник которой – интерфейс Ethernet 0 маршрутизатора А, а получатель – интерфейс Ethernet маршрутизатора В. Если эхо-тестирование выполняется успешно, проблем маршрутизации нет. Маршрутизатор A имеет доступ в Ethernet маршрутизатора B, а маршрутизатор B имеет доступ в Ethernet маршрутизатора A. А также шлюзы по умолчанию для обоих узлов настроены корректно.

      Если выполнение расширенной команды ping из маршрутизатора A не удается, значит возникли проблемы маршрутизации. Проблема маршрутизации может быть на любом из трех маршрутизаторов. Маршрутизатору А может недоставать маршрута в подсеть Ethernet маршрутизатора B или в подсеть между маршрутизаторами C и B. Маршрутизатору B может недоставать маршрута в подсеть Ethernet маршрутизатора A или в подсеть между маршрутизаторами C и A; а маршрутизатор C может не иметь маршрута в подсеть сегментов Ethernet маршрутизаторов A или B. Следует устранить проблемы маршрутизации, и после этого попытаться выполнить команду ping из хоста 1 к хосту 2. Если хост 1 все еще не может связаться с хостом 2, следует проверить шлюзы по умолчанию обоих хостов. Возможность соединения между Ethernet маршрутизатора А и Ethernet маршрутизатора В проверяется с помощью расширенной команды ping.

      Если обычная команда ping посылается из интерфейса Ethernet от маршрутизатора А к маршрутизатору В, адрес источника этого эхо-пакета является IP-адресом исходящего интерфейса, то есть, адресом последовательного интерфейса 0 (172.31.20.1). Когда маршрутизатор В отвечает на эхо-пакет, этот ответ отсылается на адрес источника (172.31.20.1). Таким образом проверяется только связь между последовательным интерфейсом 0 маршрутизатора А (172.31.20.1) и интерфейсом Ethernet маршрутизатора B (192.168.40.1).

      Чтобы проверить связь между интерфейсами Ethernet 0 маршрутизатора A (172.16.23.2) и Ethernet 0 маршрутизатора B (192.168.40.1), используйте команду расширенную команду ping. Расширенная команда ping дает возможность указать адрес источника ping-пакета, как показано ниже.

      Следующий пример содержит расширенные команды и подробности изменений:

      Команда трассировки

      Там, где команда ping может быть использована для проверки связи между устройствами, команда traceroute может использоваться для обнаружения трактов, по которым пакеты достигают удаленных адресатов, а также точек нарушения маршрутизации.

      Целью использования команды traceroute является запись источника каждого ICMP-сообщения "превышен лимит времени" для обеспечения трассировки тракта, по которому пакет попадает к адресату.

      Устройство, выполняющее команду traceroute, отсылает последовательность блоков UDP (Протокол датаграмм пользователя) (с увеличением значений TTL (время существования) на неверный адрес порта (по умолчанию 33434) на удаленном хосте.

      Сначала посылаются три датаграммы, причем поле TTL каждой датаграммы установлено в значение 1. Значение TTL, равное 1, является причиной "тайм-аута" датаграммы при достижении первого маршрутизатора на ее тракте. Этот маршрутизатор выдает ICMP сообщение о превышении времени, что означает истечение срока действия датаграммы.

      Затем посылаются еще три сообщения UDP, каждое со значением 2 в поле TTL. Это значит, что второй маршрутизатор на тракте к адресату вернет сообщения ICMP об истечении срока.

      Этот процесс продолжается до тех пор, пока пакеты не достигнут пункта назначения, а система, инициировавшая проверку прохождения сигнала по сети, не получит ICMP-сообщения об истечении времени от каждого маршрутизатора по пути к пункту назначения. Как только эти датаграммы пытаются получить доступ к неверному порту (по умолчанию 33434) на хосте назначения, то этот узел начинает отвечать ICMP-сообщениями "port unreachable", что значит "порт недоступен". Это событие служит признаком того, что программа traceroute завершена.

      Расширенная команда traceroute

      Расширенная команда traceroute – разновидность команды traceroute. Расширенная команда traceroute используется для просмотра пути, по которому пакеты доходят до пункта назначения. Эта команда также может быть использована для проверки маршрутизации. Это удобно для устранения петель маршрутизации или для определения, на каком участке происходит потеря пакетов (если маршрут отсутствует или пакеты блокируются списком управления доступом (ACL) или брандмауэром). Вы можете выполнить расширенную команду ping, чтобы определить тип проблемы соединения, а затем с помощью расширенной команды traceroute выяснить местоположение проблемы.

      Сообщение об ошибке превышения лимита времени указывает на то, что сервер промежуточной связи "увидел" и отбросил пакет. Сообщение об ошибке недоступности пункта назначения указывает на то, что узел назначения получил тестовый пакет и отклонил его, так как не может отправить пакет. Если таймер срабатывает до прихода ответа, команда trace отображает звездочку (*). Выполнение команды заканчивается, когда происходит следующее:

      конечная точка отвечает

      максимальное значение TTL превышено

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

      Примечание. Активизировать эту управляющую последовательность можно с помощью одновременного нажатия клавиш Ctrl, Shift и 6.

      Описания полей команды traceroute

      В этой таблице содержатся описания полей команды traceroute:

      Запрос поддерживаемого протокола. Введите appletalk, clns, ip, novell, apollo, vines, decnet или xns. По умолчанию используется ip.

      Target IP addres

      Необходимо указать имя хоста или IP-адрес. Нет значения по умолчанию.

      Интерфейс или IP адрес маршрутизатора будут использованы в качестве адреса отправителя для тестирования. Обычно IP-адрес для использования исходящим интерфейсом выбирает маршрутизатор.

      Numeric display [n]:

      По умолчанию имеется как символическое, так и цифровое отображение; тем не менее можно отменить символическое отображение.

      Timeout in seconds [3]:

      Количество секунд ожидания ответа на тестовый пакет. Значение по умолчанию равно трем секундам.

      Число пробных пакетов, которые требуется отправить на каждом уровне TTL. Значение по умолчанию равно 3.

      Minimum Time to Live [1]:

      Значения TTL для первых пробных пакетов. Значение по умолчанию — 1, но для отмены отображения известных скачков может быть установлено более высокое значение.

      Maximum Time to Live [30]:

      Максимальное значение TTL, которое может использоваться. Значение по умолчанию – 30. Выполнение команды traceroute завершается при достижении точки назначения или данного значения.

      Port Number [33434]:

      Порт назначения, используемый пробными сообщениями UDP. Значение по умолчанию — 33434.

      Loose, Strict, Record, Timestamp, Verbose[none]:

      Параметры IP-заголовка. Можно указать любое сочетание. Команда traceroute выдает приглашения для заполнения обязательных полей. Запомните, что команда traceroute устанавливает запрашиваемый параметр для каждого теста; однако нет гарантии, что все маршрутизаторы (или конечные узлы) обработают эти параметры.

      Пример

      Примечание. Команду расширенной трассировки traceroute можно выполнить только в привилегированном режиме EXEC, в то время как команда обычной трассировки traceroute работает как в этом режиме, так и в режиме пользователя.

      На рис. 19.20 показаны форматы эхо-запроса и эхо-ответа. Они отличаются друг от друга только значением поля типа (нули — для ответа, единицы — для запро­са). В поле данных запроса отправитель помещает информацию, которую затем получает в ответе от узла назначения.

      4 байта W
      Тип = 0/8 Код = 0 Контрольная сумма
      Идентификатор запроса Порядковый номер
      Данные
      Рис. 19.20- Формат ICMP-сообщений типа эхо-запрос/эхо-ответ

      Эхо-запрос и эхо-ответ, в совокупности называемые эхо-протоколом, представ­ляют собой очень простое средство мониторинга сети. Компьютер или маршру­тизатор посылает по составной сети эхо-запрос, указывая в нем IP-адрес узла, достижимость которого нужно проверить. Узел, получивший эхо-запрос, фор­мирует и отправляет эхо-ответ отправителю запроса. Так как эхо-запрос и эхо- ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы составной сети.

      Во многих операционных системах используется утилита ping, предназначенная для тестирования достижимости узлов. Эта утилита обычно посылает серию эхо- запросов к тестируемому узлу и предоставляет пользователю статистику об уте­рянных эхо-ответах и среднем времени реакции сети на запросы. Утилита ping выводит на экран сообщения следующего вида обо всех поступивших ответах:

      Pinging serverl.citmgu.ru [193.107.2.200] with 64 bytes of data: Reply from 193.107.2.200: bytes-64 time-256ms TTL- 123 Reply from 193.107.2.200: bytes=64 time-310ms TTL

      Не нашли то, что искали? Воспользуйтесь поиском:

      Лучшие изречения: Для студента самое главное не сдать экзамен, а вовремя вспомнить про него. 10072 — | 7513 — или читать все.

      78.85.5.224 © studopedia.ru Не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования. Есть нарушение авторского права? Напишите нам | Обратная связь.

      Отключите adBlock!
      и обновите страницу (F5)

      очень нужно

Добавить комментарий

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