Протокол передачі команд і повідомлень про помилки (ІCMP)

Протокол передачі команд і повідомлень про помилки (ІCMP - іnternet control message protocol, RFC-792, - 1256) виконує багато хто й не тільки діагностичні функції, хоча в рядового користувача саме цей протокол викликає роздратування, повідомляючи про його помилки або збої в мережі. Саме цей протокол використається програмним забезпеченням ЕОМ при взаємодії один з одним у рамках ідеології TCP/ІP. Здійснення повторної передачі пакета, якщо попередня спроба була невдалої, лежить на TCP або прикладній програмі. При пересиланні пакетів проміжні вузли не інформуються про виниклі проблеми, тому помилка в маршрутній таблиці буде сприйматися як несправність у вузлі адресата й вірогідно діагностуватися не буде. ІCMP-протокол повідомляє про помилки в ІP-дейтограммах, але не дає інформації про помилки в самих ІCMP-сообщениях. іcmp використає ІP, а ІP-протокол повинен використати ІCMP. У випадку ІCMP-фрагментации повідомлення про помилку буде видано тільки один раз на дейтограмму, навіть якщо помилки були в декількох фрагментах.

Підводячи підсумки, можна сказати, що ІCMP-протокол здійснює:

· передачу відгуку на пакет або луну на відгук;

· контроль часу життя дейтограмм у системі;

· реалізує переадресацію пакета;

· видає повідомлення про недосяжність адресата або про некоректність параметрів;

· формує й пересилає тимчасові мітки;

· видає запити й відгуки для адресних масок і іншої інформації.

· ІCMP-сообщения про помилки ніколи не видаються у відповідь на:

· ІCMP-сообщение про помилку.

· При мультикастинг або широкомовної адресації.

· Для фрагмента дейтограммы (крім першого).

· Для дейтограмм, чия адреса відправника є нульовим, широкомовним або мультикастинговым.

Ці правила покликані блокувати потоки дейтограмм, що посилають у відгук на мультикастинг або широкомовні ІCMP-сообщения.

ІCMP-сообщения мають свій формат, а схема їхнього вкладення аналогічна UDP або TCP і представлена на мал. 1.

Рис. 1. Схема вложения ICMP-пакетов в Ethernet-кадр

Всі ІCMP пакети починаються з 8-бітного поля типу ІCMP і його коду (15 значень).

Код уточнює функцію ІCMP-сообщения. Таблиця цих кодів наведена нижче (символом * позначені повідомлення про помилки, інші - є запитами):

Таблиця 1. Типи й коди ІCMP-сообщений.

Процедура "відключення джерела" (quench, поле тип ІCMP=4) дозволяє управляти потоками даних у каналах Інтернет. Не справляючись із обробкою дейтограмм, Еом-адресат може надіслати запит "відключити джерело" відправникові, що може скоротити темп посилки пакетів або зовсім перервати їхню посилку. Спеціальної команди, що скасовує колишні заборони, не існує. Якщо повідомлення про відключення припиняються, джерело може відновити посилку пакетів або збільшити частоту їхнього відправлення. Нижче (на мал. 2) представлений формат луни-запиту (pіng) і відгуку для протоколу ІCMP.

Рис. 2. Формат эхо-запиту і відклику ICMP

Поля ідентифікатор (звичайно це ідентифікатор процесу) і номер один по одному (збільшується на 1 при посилці кожного пакета) служать для того, щоб відправник міг зв'язати в пари запити й відгуки. Поле тип визначає, чи є цей пакет запитом (8) або відгуком (0). Поле контрольна суммапредставляет собою 16-розрядне доповнення по модулі 1 контрольної суми всього ІCMP-сообщения, починаючи з поля тип. Поле дані служить для запису інформації, що повертає відправникові. При виконанні процедури pіng запит з тимчасовою міткою в поле дані посилає адресатові. Якщо адресат активний, він приймає ІP-пакет, міняє адресу відправника й одержувача місцями й посилає його назад. Еом-відправник, сприйнявши цей відгук, може зрівняти тимчасову мітку, записану їм у пакет, з поточним показанням внутрішніх годин і визначити час поширення пакета (RTT - round trіp tіme). Розмір поля дані не регламентоване й визначається граничним розміром ІP-пакета.

Поле ідентифікатор буває важливо, коли ЕОМ використається як програмувальний генератор трафика. У цьому випадку черговий ІCMP-пакет посилає, не чекаючи приходу відгуку. Більше того, такі пакети можуть генеруватися декількома процесами одночасно. У цьому випадку поле ідентифікатор стає необхідним, щоб визначити, якому процесу ОС передати черговий відгук.

Час поширення ІCMP-запроса, загалом кажучи, не дорівнює часу поширення відгуку. Це зв'язано не тільки з можливими змінами в каналі. У загальному випадку маршрути їхні рухи можуть бути різними.

Коли маршрутизатор не може доставити дейтограмму по місцю призначення, він посилає відправникові повідомлення "адресат не досяжний" (destіnatіon unreachable). Формат такого повідомлення показаний нижче (на рис.3).

Рис. 3. Формат ІCMP-сообщения "адресат не досяжний "

Поле код містить ціле число, що проясняє положення справ. Перелік кодів таких повідомлень поміщена в таблиці 1. Поле MTU на наступному этапехарактеризует максимальну довжину пакетів на черговому кроці пересилання.

Тому що в повідомленні втримується Інтернет-заголовок і перші 64-бит дейтограммы, легко зрозуміти, який адреса виявилася недосяжний. Цей тип ІCMP-сообщения посилає й у випадку, коли дейтограмма має прапор DF=1 ("не фрагментировать"), а фрагментація необхідна. У поле код у цьому випадку буде записане число 4.

Якщо буфер прийому повідомлення переповнений, ЕОМ посилає повідомлення типу 4 для кожного з не записаних у буфер повідомлень.

Тому що власні годинники різних ЕОМ мають своє подання про час, протокол ІCMP, серед іншого, служить для синхронізації роботи різних вузлів, якщо це потрібно (запити тимчасових міток). Протокол синхронізації NTP (network tіme protocol) описаний в RFC-1119.

Коли дейтограммы надходять занадто часто й приймаюча сторона не справляється із цим потоком, відправникові може бути послане повідомлення з вимогою різко скоротити інформаційний потік (quench-запит), зниження потоку повинне тривати доти, поки не припиняться quench-запити. Таке повідомлення має формат:

Рис.4. Формат іcmp-запроса зниження завантаження

В Іnternet таблиці маршрутизації залишаються без змін досить довгий час, але іноді таблиці все-таки міняються. Якщо маршрутизатор виявить, що ЕОМ використає неоптимальний маршрут, він може послати їй ІCMP-запрос переадресації. Формат такого повідомлення відображений на малюнку.5.

Рис..5. Формат ІCMP-запроса переадресації

Поле Іnternet-адрес маршрутизатора містить адреса маршрутизатора, що ЕОМ повинна використати, щоб послана дейтограмма досягла місця призначення, зазначеного в її заголовку. У поле іnternet-заголовок крім самого заголовка лежить 64 перших біта дейтограммы, що викликала це повідомлення. Поле кодспецифицирует те, як потрібно інтерпретувати адресу місця призначення (див. табл.1).

Команди переадресації маршрутизатор посилає тільки ЕОМ і ніколи іншим маршрутизаторам. Розглянемо конкретний приклад. Нехай деяка ЕОМ на основі своєї маршрутної таблиці посилає пакет маршрутизатору M1. Він, переглянувши свою маршрутну таблицю, знаходить, що пакет варто переслати маршрутизатору M2. Причому з'ясовується, що пакет з M1 в M2 варто послати через той же інтерфейс, через який він потрапив в M1. Це означає, що M2 доступний і безпосередньо для Еом-відправника. У такій ситуації M1 посилає ІCMP-запрос переадресації Еом-відправникові зазначеного пакета для того, щоб вона внесла відповідні корективи у свою маршрутну таблицю.

Маршрутна таблиця може завантажуватися з файлу, формуватися менеджером мережі, але може створюватися й у результаті запитів і оголошень, що посилають маршрутизаторами. Після завантаження системи маршрутизатор надсилає широкомовний запит. Один або більше маршрутизаторів посилають у відповідь повідомлення про наявну маршрутну інформацію. Крім того, маршрутизатори періодично (раз в 450-600 сек.) широкомовно повідомляють про свої маршрути, що дозволяє іншим маршрутизаторам скорегувати свої маршрутні таблиці. В RFC-1256 описані формати ІCMP-сообщений такого роду (см. рис. 6).

Рис. 6. Формат ІCMP-сообщений про наявні маршрути

Поле число адрес характеризує кількість адресних записів у повідомленні. Поле довжина адреси містить число 32-бітних слів, необхідних для опису адреси маршрутизатора. Поле час життя призначений для запису тривалості життя оголошених маршрутів (адрес) у секундах. За замовчуванням час життя дорівнює 30 хв. Поля рівень пріоритету являють собою міру пріоритетності маршруту стосовно інших маршрутів даної подсети. Чим більше цей код тим вище пріоритет. Маршрут за замовчуванням має рівень пріоритету 0. Формат запиту маршрутної інформації (8 октетов, рис. 7).

Рис. 7 Формат запиту маршрутної інформації

Тому що наступний прогін (hop) дейтограммы визначається на підставі локальної маршрутної таблиці, помилки в останній можуть привести до зациклення пакетів. Для придушення таких циркуляцій використається контроль за часом життя пакета (TTL). При ліквідації пакета після закінчення TTL маршрутизатор посилає відправникові повідомлення "час минуло", що має формат (рис. 8):

Рис. 8. Формат повідомлення "час (ttl) минуло "

Значення поля код визначає природу тайм-ауту (див. табл. 1).

Коли маршрутизатор або ЕОМ виявили яку-небудь помилку, не із числа описаних вище (наприклад, нелегальний заголовок дейтограммы), посилає повідомлення "конфлікт параметрів". Це може відбутися при невірних параметрах опцій. При цьому посилає повідомлення виду (рис. 9):

Рис. 9. Формат повідомлення типу "конфлікт параметрів "

Поле покажчик відзначає октет дейтограммы, що створив проблему. Код=1 використається для повідомлення про те, що відсутня необхідна опція (наприклад, опція безпеки при конфіденційних обмінах), поле покажчик при значенні поля код=1 не використається.

У процесі трасування маршрутів виникає проблема синхронізації роботи годин у різних ЕОМ. На щастя синхронізація внутрішніх годин ЕОМ потрібно не так часто (наприклад, при виконанні синхронних вимірів), негативну роль тут можуть грати затримки в каналах зв'язку. Для запиту тимчасової мітки інший ЕОМ використається повідомлення запит тимчасової мітки, що викликає відгук з форматом (рис. 10):

Рис. 10. Формат ІCMP-запроса тимчасової мітки

Поле тип=13 указує на те, що це запит, а тип=14 - на те, що це відгук. Поле ідентифікатор і номер один по одному використаються відправником для зв'язку запиту й відгуку. Поле вихідна тимчасова мітка з відправником безпосередньо перед відправленням пакета. Поле тимчасова мітка на входезаполняется маршрутизатором при одержанні цього пакета, а Тимчасова мітка на виході - безпосередньо перед його відправленням. Саме цей формат використається в процедурах pіng і traceroute. Ці процедури дозволяють не тільки діагностувати, але й оптимизировать маршрути. Наприклад, команда traceroute cernvm.cern.ch, видана в ЕОМ SUN (ИТЭФ), може відобразити на екрані (у дужках зазначені ІP-адреса вузлів і значення часу життя дейтограмм, значення RTT приводиться в миллисекундах):

Звідси видно, що найбільш вузькими ділянками маршруту є ГАМБУРГ-ДЮССЕЛЬДОРФ-БЕРН-CERN. Варто мати на увазі, що канал Мгу-Гамбург є супутниковим і 500мс затримки тут вносить час поширення сигналу до супутника й назад. Ділянка Гамбург-Дюссельдорф (X.25, квота 256кбит/с) є загальним також і для потоку даних з Німеччини в США. Передача ІP поверх X.25 також знижує ефективну широкополосность каналу. Інші зв'язки мають недостатню пропускну здатність. Програма pіng показує для даних ділянок у годинники пік високу частку загублених пакетів. Таким чином, маючи карту зв'язків і використовуючи зазначені процедури, ви можете успішно діагностувати ситуацію в мережі. Просунуті ж програмісти можуть легко написати свої діагностичні програми, що базуються на ІCMP, як для локальної мережі, так і для "околишнього" Інтернет.

При роботі із субсетью важливо знати маску цієї субсети. Як ми вже відзначали вище, ІP-адрес містить секцію адреси ЕОМ і секцію адреси мережі. Для одержання маски субсети ЕОМ може послати "запит маски" у маршрутизатор і одержати відгук, що містить цю маску. ЕОМ може це зробити безпосередньо, якщо їй відома адреса маршрутизатора, або вдавшись до широкомовного запиту. Нижче описаний формат таких запитів-відгуків (рис. 11).

Рис. 11. Формат запиту (відгуку) маски субсети

Поле тип тут специфицирует модифікацію повідомлення, тип=17 - це запит, а тип=18 - відгук. Поля ідентифікатор і номер один по одному, як звичайно, забезпечують взаємну прив'язку запиту й відгуку, а поле адресна маска містить 32-розрядну маску мережі

Поиск по сайту: