Icmp помилки про недоступність хоста та мережі
ICMP помилка про недоступність хоста (host unreachable) відправляється маршрутизатором, коли він отримує IP-датаграму, яку неможливо перенаправити. (На малюнку 6.10 ми показали формат ICMP повідомлень про недоступність.) Ми зможемо спостерігати це в нашій мережі, якщо вимкнемо SLIP канал з додзвоном на маршрутизаторі sun і спробуємо відправити пакет через SLIP канал з іншого хоста, вказавши sun як маршрутизатор за замовчуванням.
Ранні реалізації TCP/IP в BSD генерували помилки про недоступність хоста, і помилки про недоступність мережі, залежно від того, чи належав пункт призначення локальної підмережі чи ні. 4.4BSD генерує лише помилку про недоступність хоста.
Звернемося знову до виведення команди netstat, запущеної на маршрутизаторі sun, висновок показаний у попередньому розділі. Ми бачимо, що пункт таблиці маршрутизації, який відповідає SLIP каналу, додається, коли SLIP канал вмикається, і видаляється, коли SLIP канал вимикається. Це означає, що коли SLIP канал вимкнено, маршрут за промовчанням на Sun не існує. Однак ми не намагатимемося змінити всі таблиці маршрутизації у хостів у нашій маленькій мережі, залишивши їм можливість самим видалити свої маршрути за умовчанням. Натомість ми порахуємо ICMP повідомлення про недоступність хоста, згенеровані sun для будь-яких пакетів, які він не може перенаправити.
Ми можемо побачити це, запустивши ping з svr4 на хост, що знаходиться на іншому кінці SLIP каналу (нині цей хост вимкнений):
svr4 %ping geminiICMP Host Unreachable from gateway sun (140.252.13.33) ICMP Host Unreachable from gateway sun (140.252.13.33) ^?символ переривання
На малюнку 9.2 ми показали виведення команди tcpdump для цього прикладу. (Команда запущена на хості bsdi).
1 0.0 svr4 >gemini: icmp: echo request 2 0.00 (0.00) sun > svr4: icmp: host gemini unreachable 3 0.99 (0.99) svr4 > gemini: icmp: echo request 4 0.99 (0.00) sun > svr4: icmp: host gemini unreachable
Рисунок 9.2 Повідомлення ICMP про відсутність хоста у відповідь на ping.
Коли маршрутизатор sun виявляє, що на хост gemini немає маршруту, він відповідає на відлуння запит повідомленням про недоступність хоста.
[Ford, Rekhter, and Braun 1993] визначає домени маршрутизації верхнього рівня (top-level routing domain) як маршрутизатори, які підтримують і обробляють інформацію більшість вузлів Internet і використовують маршрутів за промовчанням. В Internet існує п'ять доменів маршрутизації верхнього рівня: NFSNET магістраль, Commercial Internet Exchange (CIX), NASA Science Internet (NSI), SprintLink та European IP Backbone (EBONE).
Перенаправляти або не перенаправляти
Ми вже кілька разів згадували про те, що хост не зможе перенаправити IP датаграми, якщо він спеціально не налаштований, щоб виступати в ролі маршрутизатора. Як здійснюється така конфігурація?
Більшість Berkeley реалізацій, мають змінну ядра, названу ipforwarding (або схоже). (Див.додаток Е.) Деякі системи (BSD/386 та SVR4, наприклад) перенаправляють датаграми, якщо ця змінна встановлена в ненульове значення. У SunOS 4.1.x визначено три значення для цієї змінної: -1 означає, що перенаправлення ніколи не буде здійснюватися і що ніколи не можна буде змінити значення цієї змінної, 0 позначає, що перенаправлення не здійснюється, однак значення змінної встановлюється в 1, коли два або Більше інтерфейсів активізовано, і 1 означає, що перенаправлення здійснюється завжди. У Solaris 2.x також існуєтри значення, а саме 0 (перенаправлення не здійснюється), 1 (перенаправлення здійснюється завжди) та 2 (перенаправлення здійснюється тільки тоді, коли активізовано два або більше інтерфейсів).
У попередніх реалізаціях 4.2BSD датаграми перенаправляються за замовчуванням. При цьому, якщо система налаштована неправильно, виникає дуже багато проблем. Саме тому ця опція ядра повинна бути завжди за умовчанням встановлена в значення "без перенаправлення" (never forward), доки системний адміністратор спеціально не ввімкне перенаправлення.