Краткая теоретическая справка. 1. Протокол ICMP (Internet Control Message Protocol) является протоколом сообщений об ошибках

1. Протокол ICMP (Internet Control Message Protocol) является протоколом сообщений об ошибках. Несмотря на то, что ICMP считается протоколом сетевого уровня, его сообщения инкапсулируются в IP. Сообщения ICMP довольно разнообразны [1], но имеют единый формат (рис. 1). На этом протоколе базируются средства мониторинга сетей связи, а также сообщения о недоступности узла в некоторых протоколах прикладного уровня, например, ошибка 404 в HTTP.

 

 

Тип сообщения – согласно классификации

Код сообщения – дополнительные сведения об ошибке

Параметры – например, IP– адрес узла

Данные – например, IP– заголовок и первые 64 бита пакета, адресованного на другой узел

Рис. 1 – Формат сообщений ICMP

Протокол ICMP для IPv4 и его сообщения описаны в RFC 792, работа с масками сетей – в RFC 950 [2]. Протокол ICMP для IPv6 описан в RFC 4443 [3].

Инструменты мониторинга утилиты ping и traceroute описаны в RFC 2529 [4].

2. Утилита ping (Packet Internet Groper – одно из возможных прочтений) является одним из главных средств, используемых для отладки сетей, и служит для принудительного вызова ответа конкретной машины. Она позволяет проверять работу приложений TCP/IP (по портам) на удаленных машинах, адреса устройств в локальной сети, адрес удаленного сетевого устройства. В выполнении команды ping участвуют система маршрутизации, схемы разрешения адресов и сетевые шлюзы. Это утилита низкого уровня, которая не требует наличия серверных процессов на зондируемой машине, поэтому успешный результат при прохождении запроса вовсе не означает, что выполняются какие-либо сервисные программы высокого уровня, а говорит о том, что сеть находится в рабочем состоянии, питание зондируемой машины включено, и машина не отказала. Утилита ping входит во все реализации TCP/IP не зависимо от операционной системы.

Получив эхо-запрос ping, программное обеспечение, реализующее протокол IP у адресата, посылает эхо-ответ. Эхо-запросы посылаются заданное количество раз (ключ - n) или по умолчанию до тех пор, пока пользователь не введет команду прерывания (Ctrl+C или Del), после чего выводятся статистические данные. В некоторых реализациях количество посылок эхо-запросов ограничено, например, в Windows их 4. В некоторых случаях можно в целях обеспечения безопасности (защита от DDOS-атак) выставить запрет на эхо-ответы. Список ключей и формат команды можно посмотреть самостоятельно, набрав в командной строке ping.

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

Пример:

C:\Users\admin>ping yandex.ru

Обмен пакетами с yandex.ru [77.88.21.11] с 32 байтами данных:

Ответ от 77.88.21.11: число байт=32 время=1651мс TTL=57

Ответ от 77.88.21.11: число байт=32 время=154мс TTL=57

Ответ от 77.88.21.11: число байт=32 время=79мс TTL=57

Ответ от 77.88.21.11: число байт=32 время=77мс TTL=57

 

Статистика Ping для 77.88.21.11:

Пакетов: отправлено = 4, получено = 4, потеряно = 0

(0% потерь)

Приблизительное время приема-передачи в мс:

Минимальное = 77мсек, Максимальное = 1651 мсек, Среднее = 490 мсек

 

3. Утилита traceroute (в реализациях Windows используется написание tracert) позволяет выявлять последовательность шлюзов, через которые проходит IP-пакет на пути к пункту своего назначения. У этой команды есть много опций, большинство из которых применяются крайне редко. Традиционно используется формат traceroute имя_узла, которое может быть задано в символической или числовой форме. Выходная информация представляет собой список машин, начиная с первого шлюза и кончая пунктом назначения.

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

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

Пример:

admin@ddd:~$ traceroute lenta.ru

traceroute to lenta.ru (81.19.85.92), 30 hops max, 60 byte packets

1 172.24.255.254 (172.24.255.254) 13.218 ms 14.129 ms 14.019 ms

2 84.204.14.254 (84.204.14.254) 13.848 ms 15.145 ms 15.040 ms

3 46.47.255.33 (46.47.255.33) 13.910 ms 13.815 ms 14.594 ms

4 mx960-spb.peterstar.net (82.196.95.169) 15.117 ms 25.568 ms 26.261 ms

5 ix-j-mx240.m9.ramtel.ru (193.232.244.118) 39.993 ms 39.870 ms 39.750 ms

6 s193-mx240.vr.rambler.ru (81.19.64.93) 39.672 ms 17.704 ms 19.828 ms

7 81.19.94.132 (81.19.94.132) 19.772 ms 19.708 ms 19.590 ms

8 81.19.85.92 (81.19.85.92) 19.529 ms 19.424 ms 28.634 ms

 

Пример:

C:\Users\admin>tracert yandex.ru

Трассировка маршрута к yandex.ru [87.250.251.11]

с максимальным числом прыжков 30:

 

1 100 ms 104 ms 106 ms HS2-1-16.xG.SPb.SkyLink.RU [89.253.1.16]

2 119 ms 99 ms 106 ms HS2-0-1.xG.SPb.SkyLink.RU [89.253.0.1]

3 107 ms 106 ms 106 ms 212.129.96.227

4 112 ms 104 ms 106 ms aurora-spb-ix.yandex.net [194.226.100.90]

5 128 ms 198 ms 110 ms 213.180.213.134

6 * * * Превышен интервал ожидания для запроса.

7 124 ms 108 ms 105 ms s650-eto2c1.yandex.net [213.180.213.65]

8 121 ms 132 ms 133 ms l3-s550-s650.yandex.net [213.180.213.28]

9 116 ms 106 ms 133 ms yandex.ru [87.250.251.11]

 

Трассировка завершена.

 

4. Существует комбинированная диагностическая утилита mtr (My Traceroute), сочетающая в себе функциональность рассмотренных выше traceroute и ping. Данная утилита основана на библиотеке libncurses (консольная версия) или на базе GTK+ (оконная версия), позволяет в реальном времени отслеживать маршрут до заданного узла и изменяющееся время ответа каждого из промежуточных узлов, а также процент потерянных пакетов. Консольный вывод утилиты mtr представлен на рисунке 2. На данный момент mtr включена практически во все дистрибутивы Linux.

 

Рис.2 – Пример работы утилиты mtr в консольном режиме

 

5. Утилита netstat выводит информацию о локальной сети и средствах TCP/IP. Она реализована непосредственно в операционной системе и занимается сбором статистики об ошибках, текущих соединениях, состоянии портов и соединений. Содержание и форма выходной информации зависят от операционной системы, но обычно выводятся следующие данные: список соединений, статистика сетевых интерфейсов, статистика по буферам данных, содержание таблицы маршрутизации, статистика работы протоколов. Характер выводимой информации можно выбирать с помощью опций командной строки. Рассмотрим основные возможности мониторинга с помощью утилиты netstat.

 

5.1. Список соединений

Утилита netstat обладает набором ключей для отображения портов, находящихся в активном и/или пассивном состоянии. Таким образом, можно получить список всех серверных приложений, работающих на данном компьютере. Отметим, что формат списка соединений для сервера с системой NAT и для клиентской машины будет разным.

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

Пример:

admin@ddd:~$ netstat -ta

Активные соединения с интернетом (servers and established)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 *:29011 *:* LISTEN

tcp 0 0 localhost:ipp *:* LISTEN

tcp 0 0 172.24.0.157:35608 213.199.179.141:40041 ESTABLISHED

tcp 0 0 172.24.0.157:37760 163-247.static.quie:www TIME_WAIT

tcp 0 0 172.24.0.157:36441 95-28-49-237.broa:26647 ESTABLISHED

tcp 0 0 172.24.0.157:38541 172.24.0.170:55554 TIME_WAIT

tcp 0 0 172.24.0.157:54369 bos-w031b-rdr1.bl:https ESTABLISHED

tcp6 0 0 localhost:ipp [::]:* LISTEN

 

Состояние соединения имеет значение только для протокола TCP. Протокол UDP факта установления соединения не проверяет.

 

5.2. Содержание таблицы маршрутизации

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

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

Утилита netstat -r позволяет отображать таблицу маршрутизации.

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

 

Пример:

admin@ddd:~ > netstat -r

Kernel IP routing table

Destination Gateway Genmask Flags Ifac

ddd.sut.ru * 255.255.255.255 UH eth1

195.19.219.120 * 255.255.255.248 U eth0

195.19.219.128 * 255.255.255.192 U eth1

192.168.1.0 * 255.255.255.0 U eth0

195.19.221.0 lgw.ccs.sut.ru 255.255.255.0 UG eth1

193.125.0.0 lgw.ccs.sut.ru 255.255.0.0 UG eth1

loopback * 255.0.0.0 U lo

default lgw.ccs.sut.ru 0.0.0.0 UG eth1

 

5.3. Статистика сетевых интерфейсов

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

Пример:

admin@ddd:~ > netstat -е

Kernel Interface table

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

eth0 1000 0 844904 0 17 0 1454454 5 0 0 BRU

eth1 1500 0 590844 0 7 0 434438 59 0 0 BRU

lo 3924 0 45754 0 0 0 45754 0 0 0 LRU

 

Ошибки являются следствием проблем в кабельной системе или следствием неисправности платы сетевого адаптера. В нормально работающей сети количество конфликтов (RX-OVR, TX-OVR) не должно превышать 3% от числа пакетов, а другие ошибки не должны составлять более 0,5% от общего числа пакетов.

 

5.4. Статистика передачи данных

Использование netstat -s позволяет вывести содержимое счетчиков сетевых программ. В выходной информации есть разделы, относящиеся к различным протоколам: IP, ICMP, TCP, UDP. С ее помощью можно определить место появления ошибки в принятом пакете.

Пример:

admin@ddd:~$ netstat -s

IР:

всего пакетов принято 17058

2 с неверными адресами

0 перенаправлено

0 входящих пакетов отклонено

входящих пакетов доставлено: 4364

запросов отправлено: 3936

Icmp:

ICMP сообщений получено: 306

неудачных входящих ICMP сообщений: 0

Гистограмма входа ICMP

пункт назначения недоступен: 8

потери при прохождении: 263

эхо-ответы: 35

послано сообщений ICMP: 280

неудачные сообщения ICMP: 0

Гистограмма выхода ICMP

пункт назначения недоступен: 8

эхо-запросов: 14

IcmpMsg:

InType0: 35

InType3: 8

InType11: 263

OutType3: 8

OutType8: 14

OutType69: 258

Tcp:

открытия активных соединений: 148

открытия пассивных соединений: 0

неудачные попытки соединения: 4

получено сбросов соединений: 2

соединений установлено: 0

сегментов получено: 3386

отправлено сегментов: 2895

повторно передано сегментов: 39

плохих сегментов получено: 0

сбросов послано: 8

Udp:

пакетов принято: 661

принято пакетов на неизвестный порт: 8

ошибок приема пакетов: 0

пакетов послано: 723

TcpExt:

пакеты, вырезанные из очереди приема по причине переполнения буфера сокета: 1

67 TCP sockets finished time wait in fast timer

задержанных подтверждений послано: 119

Редим быстрого подтверждения приема был активирован 69 раз

11 packets directly queued to recvmsg prequeue.

3635 bytes directly received in process context from prequeue

ожидаемых заголовков пакетов: 1745

ожидаемых заголовков пакетов, непосредственно стоявших в очереди к пользователю: 5

311 acknowledgments not containing data payload received

ожидаемые подтверждения: 299

9 congestion windows recovered without slow start after partial ack

1 timeouts in loss state

19 retransmits in slow start

других TCP тайм-аутов: 19

22 packets collapsed in receive queue due to low socket buffer

получено DSACKs: 9

1 соединения сброшены из-за неожиданных данных

2 connections reset due to early user close

TCPDSACKIgnoredNoUndo: 3

TCPSackShiftFallback: 9

IpExt:

InMcastPkts: 15

OutMcastPkts: 19

InOctets: 4353792

OutOctets: 405434

InMcastOctets: 2714

OutMcastOctets: 2990

Изучаемые в процессе выполнения лабораторной работы средства мониторинга относятся к универсальным в сетях IP. Они являются встроенными во все операционные системы с поддержкой IP, работают как с IPv4, так и с IPv6. Для своей работы утилита netstat использует статистику, собранную при помощи ICMP. Так как ICMP для IPv4 и IPv6 имеет отличия, связанные непосредственно с изменением формата заголовка, то и результат для этих протоколов будет отличаться. Современные операционные системы поддерживают обе версии ICMP.

 

Задание на лабораторную работу:

1. Провести трассировку трех узлов по заданию преподавателя. По результатам построить графики зависимости времени прохождения пакета от номера узла. Указать шлюзы перехода из одной сети в другую. Листинги трассировки привести в отчете.

2. Провести оценку работоспособности узлов: узлов в подсети лаборатории, шлюза подсети, 5 узлов из ранее сделанных трассировок. Оценить TTL для каждого из них.

3. Запустить несколько сетевых приложений на клиентской машине (например, несколько сайтов, интернет-мессенджер и т.п.). Снять с клиентской машины при помощи утилиты netstat таблицу маршрутизации, список соединений, статистику передачи данных, состояние интерфейса Ethernet. На основании списка соединений построить карту сети (см. лаб.1). На основе таблицы маршрутизации зарисовать архитектуру сети.

 

К защите:

1. Знать основные принципы мониторинга сетей, характеристики сетей (TTL, время приема-передачи и т.п.), принципы работы средств мониторинга (всех используемых в лабораторной работе утилит).

2. Уметь использовать средства мониторинга IP-сетей.

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

 

Рекомендуемая литература:

1. RFC 792 Internet control message protocol. September, 1981.

2. RFC 950 Internet Standard Subnetting Procedure. August 1985

3. RFC 4443 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. March, 2006

4. RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations. September, 2000.

5. Олифер Н. А., Олифер В.Г. Компьютерные сети. Принципы, технологии, протоколы. Издание 4-е. Питер, 2010.