4.5.1 Пинг и трассировка

• Параметры IANA ICMP
• Номера протоколов IANA
• Объяснение поведения перенаправления ICMP
  у Wayback Machine
  (архивировано 10 января 2015 г.)

Эта статья о протоколе поддержки IPv4 (ICMPv4). Для ICMPv6 см. ICMPv6
.

ICMP для IPv4
определено в RFC
792
. Отдельный ICMPv6
, определенный RFC 4443, используется с IPv6
.

• RFC  792
  , Протокол контрольных сообщений Интернета
• RFC  950
  , Стандартная процедура создания подсетей в Интернете
• RFC  1016
  , Что-то, что хост может сделать с Source Quench: Source Quench Introduced Delay (SQuID)
• RFC  1122
  , Требования к интернет-хостам – уровни связи
• RFC  1716
  , Требования к IP-маршрутизаторам
• RFC  1812
  , Требования к IP-маршрутизаторам версии 4
• RFC 4884
  , Расширенный протокол ICMP для поддержки многочастных сообщений

Тип

Тип ICMP, см. § Управляющие сообщения
.

Код

Подтип ICMP, см. § Управляющие сообщения
.

Контрольная сумма

Контрольная сумма Интернета (RFC 1071) для проверки ошибок, рассчитанная на основе заголовка ICMP и данных со значением 0, подставленным в это поле.

Остальная часть заголовка

Четырехбайтовое поле, содержимое которого зависит от типа и кода ICMP.

Переменный размер раздела пакетных данных ICMP был использован
. В “ Пинге смерти
“, большие или фрагментированные пакеты ICMP используются для атак типа “отказ в обслуживании”
. I Данные CMP также могут быть использованы для создания скрытых каналов
для общения. Эти каналы известны как туннели ICMP
.

Например, каждое устройство (например, промежуточный маршрутизатор
) пересылка дейтаграммы IP
сначала уменьшает время жизни
(TTL) в заголовке IP на единицу. Если результирующий TTL равен 0, пакет отбрасывается, а время передачи ICMP превышается
сообщение отправляется на адрес источника дейтаграммы.

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

Control messages are identified by the value in the type
field. The code
field gives additional context information for the message. Some control messages have been deprecated
since the protocol was first introduced.

Source Quench
requests that the sender decrease the rate of messages sent to a router or host. This message may be generated if a router or host does not have sufficient buffer space to process the request, or may occur if the router or host buffer is approaching its limit.

Data is sent at a very high speed from a host or from several hosts at the same time to a particular router on a network. Although a router has buffering capabilities, the buffering is limited to within a specified range. The router cannot queue any more data than the capacity of the limited buffering space. Thus if the queue gets filled up, incoming data is discarded until the queue is no longer full. But as no acknowledgement mechanism is present in the network layer, the client does not know whether the data has reached the destination successfully. Hence some remedial measures should be taken by the network layer to avoid these kind of situations. These measures are referred to as source quench. In a source quench mechanism, the router sees that the incoming data rate is much faster than the outgoing data rate, and sends an ICMP message to the clients, informing them that they should slow down their data transfer speeds or wait for a certain amount of time before attempting to send more data. When a client receives this message, it will automatically slow down the outgoing data rate or wait for a sufficient amount of time, which enables the router to empty the queue. Thus the source quench ICMP message acts as flow control in the network layer.

Type
must be set to 4

Code
must be set to 0

IP header
and additional data is used by the sender to match the reply with the associated request

Type
must be set to 5.

Code
specifies the reason for the redirection, and may be one of the following:

IP address
is the 32-bit address of the gateway to which the redirection should be sent.

IP header
and additional data is included to allow the host to match the reply with the request that caused the redirection reply.

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

Сообщения о превышении времени используются traceroute
утилита для определения шлюзов на пути между двумя хостами.

Тип
должен быть установлен на 11

Код
указывает причину превышения времени
сообщение, включая следующее:

IP-заголовок
и первые 64 бита исходной полезной нагрузки
используются хостом-источником для сопоставления сообщения об истечении времени с отброшенной дейтаграммой. Для протоколов более высокого уровня, таких как UDP
и TCP
64-битная полезная нагрузка будет включать порты источника и назначения отброшенного пакета.

Отметка времени
используется для синхронизации времени. Исходная метка времени
устанавливается на время (в миллисекундах с полуночи), когда отправитель в последний раз коснулся пакета. Временные метки приема и передачи не используются.

Тип
должен быть установлен на 13

Код
должен быть установлен на 0

Идентификатор
и Порядковый номер
может использоваться клиентом для сопоставления ответа с отметкой времени
с запросом метки времени.

Отметка времени отправления
количество миллисекунд с полуночи всемирного времени
(ЮТ). Если ссылка UT недоступна, старший бит может быть установлен для указания нестандартного значения времени.

Ответ с меткой времени
ответы на Отметка времени

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

Тип
должен быть установлен на 14

Код
должен быть установлен на 0

Идентификатор
и Порядковый номер
может использоваться клиентом для сопоставления ответа с запросом, вызвавшим ответ.

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

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

Отметка времени передачи
это время, когда эхо-машина в последний раз касалась сообщения при его отправке.

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

Запрос маски адреса

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

Получатели должны ответить на это сообщение с помощью ответа с маской адреса

сообщение.

Тип
должен быть установлен на 17

Код
должен быть установлен на 0

Маска адреса
можно установить на 0

Ответ маски адреса

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

Тип
должен быть установлен на 18

Код
должен быть установлен на 0

Маска адреса
должна быть установлена ​​маска подсети

Тип
поле (биты 0–7) должно быть установлено на 3

Код
Поле (биты 8–15) используется для указания типа ошибки и может быть любым из следующих:

MTU следующего перехода
Поле (биты 48–63) содержит MTU сети следующего перехода, если возникает ошибка кода 4. ^[14]

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

-a

Сопровождать работу программы звуком.

-A

Адаптировать интервал между отправками пакетов к длительности их доставки и возврата.
Таким образом, если только не выполняется преднагрузка, в любой момент времени может быть не больше одного пакета, на который не получен ответ.
Минимальный интервал для не администратора – 200 мс.
В сетях с низким rtt данный режим эквивалентен лавинообразному.

-b

Разрешить использование широковещательного адреса в качестве целевого.

-B

Запретить изменение исходного адреса для пакетов во время работы программы.
Исходный адрес определяется в начале работы ping
.

-c
количество

Остановить работу после передачи заданного количества
пакетов ECHO_REQUEST.
Если задано ограничение-на-время-работы
, программа будет ждать
указанное количество
ответных пакетов ECHO_REPLY в указанный период.

-d

Устанавливает параметр SO_DEBUG на используемый сокет. Примечание: этот параметр не используется ядром Linux.

-F
идентификатор-потока

Устанавливать идентификатор-потока в отправляемых пакетах
(только для ping6
). Если указан нуль, идентификатор-потока будет генерироваться случайно ядром.

-f

Лавинообразный режим. Для каждого пакета ECHO_REQUEST выводится точка (`.’), для каждого
ответного пакета ECHO_REPLY – забой (удаление последней точки).
Это позволяет наглядно представлять число потерянных пакетов.
Если интервал между отправками не задан, последние производятся
с наибольшей скоростью (по мере получения ответов) или со скоростью 100 раз в секунду,
в зависимости от того, в каком случае получается большая скорость.
Задавать нулевой интервал между отправками может только суперпользователь.

-i
интервал

Интервал
в секундах между отправкой пакетов.
По умолчанию между отправкой пакетов делается пауза в 1 секунду,
либо, в случае лавинообразного режима, отправка производится без пауз.
Задавать значения меньше 0.2 может только суперпользователь.

-I
адрес

Установить адрес источника в указанный.
В качестве аргумента может выступать числовой IP-адрес или имя устройства.
Этот параметр обязателен при отправке запросов на локально соединённый адрес IPv6.

-l
преднагрузка

Послать с максимальной скоростью указанное количество пакетов, не дожидаясь ответов,
и затем перейти в обычный режим работы.
Значения больше 3 может указывать только суперпользователь.

-L

Подавлять циклические петли для широковещательных пакетов.
Этот ключ применяется только если в качестве целевого адреса указан широковещательный.

-n

Только цифровой вывод. Не расшифровывать имена (символьный вид) адресов.

-p

шаблон

Можно указать до 16 несмысловых байтов для заполнения пакетов.
Это полезно при диагностике проблем в сети.
Например,

-p ff

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

-Q

тип-обслуживания

Разряды байта QoS (Quality of Service – качество обслуживания) для датаграмм ICMP.

Тип-обслуживания

может быть либо десятичным либо шестнадцатеричным числом.
Обычно (согласно RFC 1349) это значение интерпретируется так: младший (нулевой) разряд зарезервирован
(сейчас используется для управления событиями при переполнении),
разряды 1-4 используются для указания собственно типа обслуживания,
и разряды 5-7 для приоритета (IP-предпочтения).
Возможные типы обслуживания: минимизация стоимости – 0x02,
максимизация надёжности – 0x04, максимизация пропускной способности – 0x08
минимизация задержек – 0x10. Одновременно можно указывать только один из четырёх перечисленных разрядов.
Возможный диапазон значения приоритета – от приоритетного (0x20) до управляемого сетью (0xe0).
Для указания высокого приоритета необходимы права суперпользователем (точнее, должно быть доступна возможность CAP_NET_ADMIN).
Разряд 0x01 можно устанавливать только если в ядре включен ECN.

В RFC 2474 этот байт переопределён как DS (Differentiated Services – дифференцированные службы):
разряды 0-1 отведены для отдельных данных (тут будет использоваться ECN)
разряды 2-7 для DSCP (Differentiated Services Codepoint – точка кода дифференцированных служб)

-q

Выводить только начальные и итоговые данные (не выводить информацию об отдельных запросах).

-R

Записывать маршрут.
Для пакетов ECHO_REQUEST будет включен параметр RECORD_ROUTE и на экран
будет выведен буфер маршрута для возвращённых пакетов.
Заметим, что в заголовок IP помещается не больше 9 таких маршрутов.
Многие узлы игнорируют или не отбрасывают этот параметр.

-r

Не использовать обычные таблицы маршрутизации и передавать данные прямо на компьютер, подключенный к интерфейсу.
Если компьютер не находится в сети с прямым подключением, то возвращается сообщение об ошибке.
Этот параметр может использоваться вместе с -I
для проверки локальной системы через интерфейс,
по которому не идет маршрутизация (например после того, как интерфейс был сброшен routed

).

-s
размер-пакета

Размер пакетов для пересылки. По умолчанию – 56,
что соответствует размеру 64 байта после добавления 8 байтов заголовка ICMP.

-S
буфер-отправки

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

-t
ttl

Время актуальности пакета IP (ttl – Time to Live).

-T
параметр-временной-метки

Параметры временной метки IP.
Возможные значения параметра-временной-метки
:
tsonly
(только временная метка),
tsandaddr
(временная метка и адреса) и
tsprespec хост1 [хост2 [хост3 [хост4]]]

(отмечать переходы).

-M
указание

Стратегия обнаружения маршрута MTU.
Возможные значения:
do
(запретить фрагментацию, даже локальную),
want
(выполнять обнаружение PMTU, фрагментировать локально если размер пакета слишком большой)
и dont
(не устанавливать флаг DF).

-U

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

-v

Выводить подробную информацию.

-V

Вывести информацию о версии и закончить работу.

-w
ограничение-на-время-работы

Время, по истечении которого ping

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

-W
время-ожидания-ответа

Время ожидания (в секундах) ответного пакета.
Принимается во внимание только если не было принято ни одного ответа.
В противном случае программа ожидает получения двух ответов.

При использовании команды ping
для локализации неполадки сначала запустите её с адресом локального хоста
для проверки работоспособности локального сетевого интерфейса.
Затем проверяйте связь посредством ping
со всё более удалёнными компьютерами и шлюзами.
Время прохождения сигналов в обе стороны и потери пакетов подсчитываются и анализируются позднее.
Если принимаются дублированные пакеты, то они не включаются в статистику
утерянных пакетов, хотя время прохода таких пакетов включается в статистику
минимального/среднего/максимального времени.
После отправки и получения указанного количества пакетов или при
прерывании работы программы сигналом
SIGINT

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

Если ответные пакеты не будут получены, то программа завершит работу с кодом выхода 1.
Если указаны количество
пакетов и ограничение-на-время-работы
,
но по истечении этого времени принято менее запрошенного числа пакетов,
то программа также завершит работу с кодом выхода 1.
При других ошибках выход будет произведен с кодом 2.
Иначе программа завершает работу с кодом 0.
Эти значения позволяют использовать коды выхода для определения доступности серверов и компьютеров в сети.

Эта программа предназначена для тестирования сетей,
управления сетями и измерения производительности.
Из-за нагрузок, которые она создаёт в сети, неразумно использовать ping

в рабочее время или в автоматических сценариях.

ИЗВЕСТНЫЕ ОШИБКИ

*

Многие узлы и шлюзы игнорируют параметр RECORD_ROUTE.

*

Максимальная длина заголовка IP слишком мала для полноценной работы таких параметров, как RECORD_ROUTE.

*

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

ВРЕМЯ АКТУАЛЬНОСТИ (TTL)

Согласно спецификации TCP/IP значение поля TTL для пакетов TCP должно быть равно 60,
но многие системы используют меньшие значения (4.3 BSD использует 30, 4.2 использует 15).

В обычном режиме ping выводит значения времени актуальности принятых (возвращённых) пакетов.
При приёме пакета удалённой системой она может выполнить одно из трёх возможных действий с полем TTL в ответ:

*

Не изменять его; это делали системы Berkeley Unix до выпуска BSD 4.3 Tahoe.
TTL в принятом пакете будет 255 минус количество пройденных маршрутизаторов на пути в обе стороны.

*

Установить его в 255: это то, что системы Berkeley Unix делают сейчас.
В этом случае значение TTL в принятом пакете будет 255 минус количество пройденных маршрутизаторов от
удалённой системы до
исходной.

*

Установить его в какое-либо другое значение.
Некоторые машины устанавливают его равным используемому для TCP пакетов,
например, либо 30 либо 60. Другие системы могут использовать вообще непредсказуемые значения.

БЕЗОПАСНОСТЬ

ping

ПЕРЕВОД

shafff@ukr.net

---

 

ТАКЖЕ

netstat

ifconfig

Index

ИМЯ

ОБЗОР

ОПИСАНИЕ

ОПЦИИ

ОПИСАНИЕ ПАКЕТОВ ICMP

ПОВТОРЯЮЩИЕСЯ И ПОВРЕЖДЁННЫЕ ПАКЕТЫ

ТЕСТИРОВАНИЕ НА РАЗЛИЧНЫХ ДАННЫХ

ВРЕМЯ АКТУАЛЬНОСТИ (TTL)

ИЗВЕСТНЫЕ ОШИБКИ

СМ. Т АКЖЕ

ИСТОРИЯ

БЕЗОПАСНОСТЬ

РАСПРОСТРАНЕНИЕ

ПЕРЕВОД

---

РАСПРОСТРАНЕНИЕ

ping

iputils

ftp://ftp.inr.ac.ru/ip-routing/iputils-current.tar.gz.

ПОВТОРЯЮЩИЕСЯ И ПОВРЕЖДЁННЫЕ ПАКЕТЫ

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

ICMP and Ping

ICMP (Internet Control Message Protocol)

Each message type consists of two fields, a Type
field, which is a general grouping of similar sub-types, called Codes
. For example, the Destination Unreachable
type contains multiple Codes
, one of which is 1
, which maps to the message Destination host unreachable
. A complete list of ICMP Types can be found on Wikipedia
.

You’ve no doubt seen these messages when doing pings. If I ping an IP on a network I know my router doesn’t have a route for, we get a Destination host unreachable
message from the router ( Reply from 10.250.1.1
).

 C:\>ping 10.44.44.4
Pinging 10.44.44.4 with 32 bytes of data:
Reply from 10.250.1.1: Destination host unreachable.
Reply from 10.250.1.1: Destination host unreachable.
Reply from 10.250.1.1: Destination host unreachable.
Reply from 10.250.1.1: Destination host unreachable.
Ping statistics for 10.44.44.4: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss) 

If we check the ICMP Control Messages table, we can see Destination host unreachable
maps to Type: 3, Code: 1
. We can confirm this with a Wireshark capture, looking at the response packet.

There is one caveat worth mentioning if you’re trying this at home – this primarily applies to enterprise or business networks. Most residential routers will simply send all traffic they don’t have a specific route for out to the Internet, even if the destination IP is within the RFC1918 private address space. In this case the ISP will simply drop these packets and you will see a Request timed out
message instead.

Request timed out
does not map to an ICMP message type as it’s not a message, rather, it is the absence of any return data.

So why is all this important?

Know what ICMP messages mean

The returned ICMP message can give us clues as to what is actually happening. Destination host unreachable
is very different from Request timed out
. The first indicates we don’t know how to get to a network, the second that we do, but there was no response.

Further, the system that replies with a Destination host unreachable
is the system which doesn’t have a path to the requested network – so you immediately know where to start looking.

Let’s dig a little deeper into this because it gets interesting.

Pinging on your local network

 C:\>ping 10.250.1.5
Pinging 10.250.1.5 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 10.250.1.5: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss) 

Let’s examine how that looks in Wireshark.

However, what if the device was not on the network at all? Would we get the same result? For this example I’ve removed the device from the network.

 C:\>ping 10.250.1.5
Pinging 10.250.1.5 with 32 bytes of data:
Reply from 10.250.1.100: Destination host unreachable.
Reply from 10.250.1.100: Destination host unreachable.
Reply from 10.250.1.100: Destination host unreachable.
Reply from 10.250.1.100: Destination host unreachable.
Ping statistics for 10.250.1.5: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss) 

And let’s look at Wireshark.

What is happening here has to do with how packets are switched inside a network segment. When you ping a remote resource (something on the Internet, or on another VLAN), the Layer 2 destination address on the packet is set to your default gateway’s MAC address. However, when you send traffic to a device on your local network, the router does not need to get involved, so the Layer 2 destination address is set to the MAC address of the destination device.

If I change the Wireshark filter to show ARP traffic, here’s what we see.

We’re broadcasting out ARP Requests, but as there is no device to respond nothing is returned. Let’s take a look at the full capture (Both ARP and ICMP) of the previous example where the host was live, but dropping ICMP.

This essentially means we don’t really need ICMP to detect hosts on our local subnet, if we have an entry in our ARP cache for the IP we’re looking for, it most likely means there is something there.

 C:\>arp -a 10.250.1.5
Interface: 10.250.1.100 --- 0xa Internet Address Physical Address Type 10.250.1.5 6c-41-6a-54-3d-0e dynamic 

These are safe rules of thumb, but there are always exceptions.

Windows has some interesting rules
around how it maintains and flushes the local ARP cache.

 C:\>ping -t 10.250.1.5
Pinging 10.250.1.5 with 32 bytes of data:
Reply from 10.250.1.5: bytes=32 time<1ms TTL=255
Reply from 10.250.1.5: bytes=32 time<1ms TTL=255
Reply from 10.250.1.5: bytes=32 time<1ms TTL=255
Reply from 10.250.1.5: bytes=32 time<1ms TTL=255
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 10.250.1.100: Destination host unreachable.
Reply from 10.250.1.100: Destination host unreachable.
Reply from 10.250.1.100: Destination host unreachable.
Reply from 10.250.1.100: Destination host unreachable.
Reply from 10.250.1.100: Destination host unreachable. 

Наконец, еще одна «функция», которая может испортить ARP, — это Proxy ARP
, хотя это редко включается (а если и включается, то, скорее всего, из-за неправильной настройки или использования частных VLAN)

Давайте перейдем к другому полезному коду сообщения ICMP.

Обнаружение закрытых портов

 C:\>telnet 10.250.1.1 80
Connecting To 10.250.1.1...Could not open connection to the host, on port 80: Connect failed 

Итак, сам telnet не дает нам фактический код ICMP, но как насчет Wireshark?

Мы снова можем подтвердить тип и код сообщения ICMP в захвате Wireshark.

Мы видим мой компьютер ( 10.250.1.100
) отправка инициала TCP SYN
пакет на IP-адрес, который google.com разрешил ( 216.58.203.110
), однако ответ ICMP исходит от локального брандмауэра – 10.250.1.1
, сообщая нам, что подключение к этому ресурсу было отклонено. Этот процесс повторяется несколько раз, поскольку мой компьютер упорно повторяет попытки еще несколько раз с тем же результатом.

Безопасность и обнаружение MTU пути

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

Это все о типах ICMP, давайте двигаться дальше.

Высокая задержка не всегда является проблемой

Много раз, когда мы используем ping, мы смотрим не только на достижимость, но и на задержку. Хотя высокие задержки часто могут быть проблематичными, это не всегда так. Давайте рассмотрим сценарий, в котором высокий пинг до устройства может не быть проблемой.

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

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

Это проявляется в высокой задержке до конкретного прыжка (устройства) на пути к нужному ресурсу, но приемлемой задержке до конечного ресурса.

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

Время прохождения туда и обратно и асимметричная маршрутизация

Наконец, что мы на самом деле измеряем, когда смотрим на задержку пинга? Это измерение времени в оба конца
, то есть запрос ping отправляется с вашего ПК, достигает целевого устройства, обрабатывается, генерируется ответ, отправляется обратно на ваш ПК и обрабатывается.

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

Что делать, если есть перегрузка или неисправность на линии, выделенной красным? Вы увидите высокую задержку при проверке связи с сервером, но это не будет иметь никакого отношения к серверу или центру обработки данных.

Это все, что касается эхо-запросов, но давайте продолжим историю асимметричной маршрутизации с помощью traceroute.

ТЕСТИРОВАНИЕ НА РАЗЛИЧНЫХ ДАННЫХ

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

Трассировка

Повторный курс — Как работает traceroute?

Важно, чтобы мы все были на одной волне в отношении работы traceroute, поэтому давайте быстро рассмотрим ее.

Traceroute работает, отправляя пакеты в конечный пункт назначения
, начиная с IP TTL (время жизни), равного 1, и увеличивая его после каждого перехода, пока не будет получен ответ от целевого ресурса. T TL — это поле в заголовке IP, которое уменьшается на 1 на каждом устройстве уровня 3, через которое оно проходит. Когда он достигает 0, пакет перестает пересылаться, генерируется ошибка и возвращается в пакете ICMP.

Это означает, что, поскольку traceroute начинается с TTL, равного 1, каждый переход на пути к месту назначения получает пакет, в котором TTL уменьшается до 0, и, следовательно, отвечает ICMP Time to live exceeded in transit
сообщение, которое является ICMP Type 11, Code 0
.

Этот упорядоченный поток пакетов ICMP TTL Exceeded позволяет нам сопоставить путь к ресурсу. Вот пример трассировки с моего ПК на 1.1.1.1

 C:\>tracert 1.1.1.1
Tracing route to one.one.one.one [1.1.1.1]
over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 10.250.1.1 2 * * * Request timed out. 3 16 ms 16 ms 16 ms 58.160.251.129 4 20 ms 12 ms 17 ms bundle-ether4.way-edge901.adelaide.telstra.net [203.50.116.104] 5 19 ms 35 ms 14 ms bundle-ether9.way-core10.adelaide.telstra.net [203.50.11.156] 6 16 ms 26 ms 14 ms bundle-ether1.way-edge903.adelaide.telstra.net [203.50.6.13] 7 24 ms 13 ms 24 ms twi3395298.lnk.telstra.net [203.54.226.194] 8 11 ms 12 ms 13 ms one.one.one.one [1.1.1.1]
Trace complete. 

Давайте посмотрим, как строки 1 и 2 выглядят в Wireshark.

Есть несколько замечаний.

• Во-первых, место назначения для пакетов, отправляемых моим ПК ( 10.250.1.1
  ) всегда 1.1.1.1
  .
• Мы отправляем 3 эхо-запроса ICMP на каждый переход до того, как TTL будет увеличен, они сопоставляются с цифрами задержки, видимыми в выходных данных
• Пакеты начинаются с TTL 1 для первого перехода и увеличиваются до 2 для второго перехода
• Второй переход не отвечает, поэтому мы показываем Request timed out
  и вперед
• По умолчанию Windows использует пакеты ICMP для трассировки, в то время как Linux использует UDP (здесь это не имеет значения, но полезно для интервью)

Давайте продолжим с того места, на котором остановились — с асимметричной маршрутизацией.

Асимметричная маршрутизация — издание Traceroute

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

Конфигурация довольно проста, мы используем два маршрутизатора для эмуляции ПК и сервера (обозначены соответствующим образом). Пакеты от ПК к Серверу идут по нижнему пути через PC -> R1 -> R2 -> R3 -> Server
, но пакеты с Сервера на ПК идут по верхнему пути через Server -> R3 -> R4 -> R5 -> R6 -> R1 -> PC
.

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

 PC#traceroute 192.168.1.100
Type escape sequence to abort.
Tracing the route to 192.168.1.100 1 10.250.1.1 28 msec 16 msec 24 msec 2 10.1.2.2 40 msec 36 msec 36 msec 3 10.2.3.2 80 msec 76 msec 88 msec 4 192.168.1.100 84 msec 124 msec 108 msec 

Мы видим именно тот путь, который мы описали выше. Как насчет с сервера на ПК?

 Server#traceroute 10.250.1.100
Type escape sequence to abort.
Tracing the route to 10.250.1.100 1 192.168.1.1 16 msec 20 msec 16 msec 2 10.3.4.2 40 msec 44 msec 36 msec 3 10.4.5.2 76 msec 44 msec 76 msec 4 10.5.6.2 60 msec 104 msec 92 msec 5 10.1.6.1 80 msec 76 msec 60 msec 6 10.250.1.100 112 msec 120 msec 84 msec 

Вот и все – совершенно другой путь, чем раньше. Если бы у нас была трассировка только с одной стороны соединения, мы бы не имели представления о том, как выглядит обратный путь. Что, если проблема, которую мы диагностировали, была на обратном пути? Одиночный traceroute будет мало полезен и может привести к неправильной диагностике проблемы. Давайте смоделируем это – я собираюсь установить связь между R5
и R6
. Как будет выглядеть трассировка от ПК до сервера? Делайте ваши ставки!

 PC#traceroute 192.168.1.100
Type escape sequence to abort.
Tracing the route to 192.168.1.100 1 10.250.1.1 24 msec 24 msec 16 msec 2 10.1.2.2 36 msec 36 msec 48 msec 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * # Output truncated... 

Несмотря на горящую неисправность R5
, наш вывод не показывает никаких указаний на это, на самом деле, многие посмотрели бы на это и пришли к выводу, что проблема в R2
так как наши пакеты дальше не идут. На самом деле происходит то, что каждое устройство после R2
(так из R3
далее) обратные пакеты идут по верхнему пути, который не может маршрутизировать трафик из-за неработающего канала.

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

 Server#traceroute 10.250.1.100
Type escape sequence to abort.
Tracing the route to 10.250.1.100 1 192.168.1.1 16 msec 16 msec 20 msec 2 10.3.4.2 32 msec 40 msec 44 msec 3 10.4.5.2 64 msec 44 msec 76 msec 4 10.4.5.2 !H !H !H 

!H
в выводе из 10.4.5.2
сопоставляется с Host Unreachable
в синтаксисе Cisco IOS, то есть R5
больше не имеет пути (маршрута) к нашему конечному пункту назначения 10.250.1.100
.

По этой причине при использовании traceroute для устранения проблем с подключением очень важно попытаться получить результаты с обеих сторон подключения.

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

Трассировка и MPLS

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

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

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

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

На этом пока все, надеюсь, это было полезно, отправьте мне сообщение, если у вас есть какие-либо комментарии!

ИСТОРИЯ

пинг

Настоящим документом о принятой версии программы Linux.

Похожее:

Windows 10 1080P, 2K, 4K, 5K HD wallpapers free download | Wallpaper Flare Непрерывный пинг: Как сделать пинг без остановки в командной строке IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов Command-Line Tool to Diagnose Network Routing Issues [Examples]