Icmp ошибки перенаправления
ICMP ошибка перенаправления отправляется маршрутизатором на хост, пославший IP датаграмму, когда датаграмма должна быть послана на другой маршрутизатор. Подобная концепция довольно проста. Мы привели три составные части этой концепции на рисунке 9.3. Увидеть ICMP перенаправление можно только когда хост имеет выбор, на какой маршрутизатор послать пакет. (Обратитесь к примерам, которые мы приводили на рисунке 7.6.)
-
Предположим, что хост посылает IP датаграмму на R1. Подобное решение принято потому, что R1 - это маршрутизатор по умолчанию для этого хоста.
-
R1 принимает датаграмму, просматривает свою таблицу маршрутизации, и определяет, что маршрутизатором следующей пересылки является R2, и именно туда необходимо отправить датаграмму. Когда R1 отправляет датаграмму на R2, он определяет, что отправляет ее на тот же самый интерфейс, с которого датаграмма была получена (локальная сеть, к которой подключен хост и два маршрутизатора). В этом случае маршрутизатор отправляет ошибку перенаправления на хост, пославший датаграмму.
-
R1 посылает ICMP перенаправление на хост, сообщая тем самым, что следующие датаграммы необходимо посылать на R2 вместо R1.
Рисунок 9.3 Пример ICMP перенаправления.
Перенаправления используются для того, чтобы позволить хосту с минимальным знанием о маршрутах поддерживать и обновлять свою таблицу маршрутизации. Как правило, формирование таблицы маршрутизации хоста начинается с создания маршрута по умолчанию (R1 или R2 из нашего примера на рисунке 9.3), при этом с использованием перенаправления хост может обновить свою таблицу маршрутизации. ICMP перенаправление позволяет TCP/IP хостам полностью полагаться на интеллектуальность маршрутизаторов в вопросе выбора маршрутов. Маршрутизаторы R1 и R2 в нашем примере должны точно представлять топологию подключенных сетей, тогда как хосты, подключенные к локальной сети, могут начинать свою маршрутизацию с маршрута по умолчанию, узнавая затем более подробно о новых маршрутах из принятых перенаправлений.
Пример
Посмотрим ICMP перенаправления в действии на примере нашей сети (на внутренней стороне обложки). Мы показали всего три хоста (aix, solaris и gemini) и два маршрутизатора (gateway и netb) в верхней части сети, в действительности там более 150 хостов и 10 маршрутизаторов. Большинство хостов считают gateway маршрутизатором по умолчанию, так как он предоставляет доступ к Internet.
Как можно получить доступ из подсети 140.252.1 к нижней подсети (4 нижние хоста на рисунке)? Во-первых, вспомним, что если на конце SLIP канала находится единственный хост, используется уполномоченный агент ARP (глава 4, раздел "Уполномоченный агент ARP"). Это означает, что для хостов в верхней сети 140.252.1 не требуется специальных средств, для того чтобы получить доступ к хосту sun (140.252.1.29). Доступ обеспечит программное обеспечение уполномоченного агента ARP на netb.
Однако, если на удаленном конце SLIP канала присутствует сеть, то необходима маршрутизация. Одно из возможных решений заключается в том, чтобы каждый хост и маршрутизатор знали о том, что маршрутизатор netb является шлюзом в сеть 140.252.13. Этого можно добиться путем внесения статического маршрута в каждую таблицу маршрутизации на каждом хосте или запустив на каждом хосте маршрутизирующий демон. Однако существует более простой способ (метод, который обычно используется) - использовать ICMP перенаправление.
Запустим программу ping с хоста solaris в верхней сети на хост bsdi (140.252.13.35) в нижней сети. Так как идентификаторы подсети различны, уполномоченный агент ARP не может быть использован. Предположим, что статический маршрут не установлен, поэтому при посылке первого пакета будет использован маршрут по умолчанию на маршрутизатор gateway. Ниже мы приводим таблицу маршрутизации, перед тем как запустили ping:
solaris % netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface -------------- --------------- ------- --- ------- -------------- 127.0.0.1 127.0.0.1 UH 0 848 lo0 140.252.1.0 140.252.1.32 U 3 15042 le0 224.0.0.0 140.252.1.32 U 3 0 le0 default 140.252.1.4 UG 0 5747
(Пункт 224.0.0.0 используется для групповой адресации IP. Мы опишем это в главе 12.) Если указать опцию -v в командной строке ping, то будут видны все ICMP сообщения принятые хостом. Нам необходимо указать эту опцию, чтобы увидеть сообщения о перенаправлении, которые будут посланы.
solaris % ping -sv bsdi PING bsdi: 56 data bytes ICMP Host redirect from gateway gateway (140.252.1.4) to netb (140.252.1.183) for bsdi (140.252.13.35) 64 bytes from bsdi (140.252.13.35): icmp_seq=0. time=383. ms 64 bytes from bsdi (140.252.13.35): icmp_seq=1. time=364. ms 64 bytes from bsdi (140.252.13.35): icmp_seq=2. time=353. ms ^? символ прерывания ----bsdi PING Statistics---- 4 packets transmitted, 3 packets received, 25% packet loss round-trip (ms) min/avg/max = 353/366/383
Перед тем как мы получим первый ответ на ping, хост примет ICMP перенаправление от маршрутизатора по умолчанию gateway. Если мы затем посмотрим таблицу маршрутизации, то увидим, что появился новый маршрут к хосту bsdi. (Этот пункт выделен жирным шрифтом.)
solaris % netstat -rn Routing Table: Destination Gateway Flags Ref Use Interface --------------- --------------- -------- --- ------- ------------- 127.0.0.1 127.0.0.1 UH 0 848 lo0 140.252.13.35 140.252.1.183 UGHD 0 2 140.252.1.0 140.252.1.32 U 3 15045 le0 224.0.0.0 140.252.1.32 U 3 0 le0 default 140.252.1.4 UG 0 5749
Pltcmm мы впервые видиv флаг D, который означает, что маршрут был установлен с использованием ICMP перенаправления. Флаг G обозначает, что это непрямой маршрут к шлюзу (netb), а флаг H обозначает, что это маршрут к хосту (как мы и ожидали), а не маршрут к сети.
Так как это маршрут к хосту, добавленный путем перенаправления, он обслуживает только хост bsdi. Если затем мы попробуем получить доступ к хосту svr4, будет сгенерировано еще одно перенаправление, и будет создан еще один маршрут к хосту. Точно так же, попытка получить доступ к хосту slip создаст еще один маршрут. Каждое перенаправление на конкретный хост приводит к созданию нового маршрута к хосту. Все три хоста в подсети (bsdi, svr4 и slip) будут обслуживаться одним маршрутом к сети, указывающим на маршрутизатор sun. Однако, ICMP перенаправления создают маршруты к хостам, а не маршруты к сетям, так как маршрутизатор, генерирующий перенаправление в данном примере (gateway), не имеет представления о структуре подсетей в сети 140.252.13.
Более подробно
На рисунке 9.4 показан формат сообщения ICMP о перенаправлении.
Рисунок 9.4 ICMP сообщение о перенаправлении.
Существуют четыре различных типа сообщений о перенаправлении, с различными значениями кода (code), как показано на рисунке 9.5.
код | Описание |
0 | перенаправление для сети |
1 | перенаправление для хоста |
2 | перенаправление для типа сервиса (TOS) и сети |
3 | перенаправление для типа сервиса (TOS) и хоста |
Рисунок 9.5 Различные значения code для ICMP перенаправления.
Существуют три IP адреса, которые должен знать получатель ICMP перенаправления: (1) IP адрес, который вызвал перенаправление (находится в IP заголовке, возвращенном как данные в ICMP сообщении о перенаправлении), (2) IP адрес маршрутизатора, который послал перенаправление (является IP адресом источника IP датаграммы, содержащей перенаправление) и (3) IP адрес маршрутизатора, который должен быть использован (находится в байтах с 4-го по 7-ой в ICMP сообщении).
Существует несколько правил, посвященных ICMP перенаправлениям. Во-первых, перенаправления генерируются только маршрутизаторами, ни в коем случае не хостами. Однако, перенаправления могут быть использованы только хостами, не маршрутизаторами. Считается, что маршрутизаторы используют протоколы маршрутизации и обмениваются таблицами с другими маршрутизаторами, поэтому они не нуждаются в перенаправлениях. (Это означает, что на рисунке 9.1 таблица маршрутизации должна быть обновлена либо с использованием маршрутизирующего демона, либо с использованием перенаправления, однако не с использованием и того и другого.)
Когда 4.4BSD функционирует как маршрутизатор, осуществляются следующие проверки, причем каждая из них должна быть истиной, для того чтобы было сгенерировано ICMP перенаправление.
-
Исходящий и входящий интерфейс один и тот же.
-
Маршрут, который будет использоваться для исходящей датаграммы, не должен быть создан или модифицирован с использованием ICMP перенаправления. Также он не должен быть маршрутом по умолчанию для маршрутизатора.
-
Датаграмма не должна быть смаршрутизирована от источника.
-
Ядро должно быть сконфигурировано таким образом, чтобы посылать перенаправления.
Переменная ядра с именем ip_sendredirects (или похожим). (См. приложение Е.) Большинство современных систем (4.4BSD, SunOS 4.1.x, Solaris 2.x и AIX 3.2.2, например) включают эту переменную по умолчанию. Другие системы, например, SVR4, имеют эту переменную по умолчанию выключенной.
В дополнение, хост 4.4BSD, который принимает ICMP перенаправления, осуществляет некоторые проверки перед модификацией своей таблицы маршрутизации. Это предотвращает странное поведение маршрутизатора или хоста, вызванное некорректной модификацией таблицы маршрутизации системы.
-
Новый маршрутизатор должен быть в непосредственно подключенной сети.
-
Перенаправление должно быть от текущего маршрутизатора на указанный пункт назначения.
-
Перенаправление не может заставить хост использовать самого себя в качестве маршрутизатора.
-
Модифицируемый маршрут должен быть непрямым маршрутом.
И в заключение стоит повториться, что маршрутизаторы должны посылать только перенаправления к хостам (codes 1 или 3 на рисунке 9.5), а не перенаправления к сетям. Из-за разделения на подсети не всегда можно однозначно указать, когда должно быть послано перенаправление к сети вместо перенаправления к хосту. Некоторые хосты воспринимают принятое перенаправление к сети как перенаправление к хосту, в том случае если маршрутизатор послал неверный тип (type).
- Одноранговая сеть
- [Править] История
- [Править] Устройство одноранговой сети
- [Править] Частично децентрализованные (гибридные) сети
- [Править] Пиринговая файлообменная сеть
- [Править] Пиринговые сети распределённых вычислений
- [Править] Пиринговые финансовые сети
- Сетевая топология
- Шина (топология компьютерной сети)
- [Править] Работа в сети
- [Править] Сравнение с другими топологиями [править] Достоинства
- [Править] Недостатки
- [Править] Преимущества и недостатки шинной топологии
- [Править] Примеры
- Кольцо (топология компьютерной сети)
- Решётка (топология компьютерной сети)
- [Править] Сравнение с другими топологиями [править] Достоинства
- [Править] Недостатки
- [Править] См. Также
- Полносвязная топология
- [Править] Недостатки
- Cети типа домен
- Сети типа рабочие группы
- Сетевые компоненты
- Сетевые карты или адаптеры Сетевая плата
- [Править] Типы
- [Править] Параметры сетевого адаптера
- [Править] Функции и характеристики сетевых адаптеров
- [Править] Классификация сетевых адаптеров
- [Править] Первое поколение
- [Править] Второе поколение
- [Править] Третье поколение
- [Править] Четвёртое поколение
- [Править] Примечания
- [Править] Сайты производителей
- [Править] Ссылки
- 1. Функции и характеристики сетевых адаптеров
- 2. Классификация сетевых адаптеров
- Сетевая карта (сетевой адаптер)
- Мосты, повторители
- Сетевой концентратор
- [Править] Принцип работы
- [Править] Принцип работы для «чайников»
- [Править] Характеристики сетевых концентраторов
- Маршрутизаторы (свитчи) Что такое Свитч?
- Сетевой коммутатор
- [Править] Принцип работы коммутатора
- [Править] Режимы коммутации
- [Править] Симметричная и асимметричная коммутация
- [Править] Буфер памяти
- [Править] Возможности и разновидности коммутаторов
- Маршрутизатор
- Модель osi Сетевая модель osi
- [Править] Уровни модели osi
- [Править] Прикладной уровень
- [Править] Представительский уровень
- [Править] Сеансовый уровень
- [Править] Транспортный уровень
- [Править] Сетевой уровень
- [Править] Канальный уровень
- [Править] Физический уровень
- [Править] Соответствие модели osi и других моделей сетевого взаимодействия
- [Править] Семейство tcp/ip
- [Править] Семейство ipx/spx
- [Править] Критика
- Модель osi Общая характеристика модели osi
- Физический уровень
- Канальный уровень
- Функции канального уровня
- Сетевой уровень
- Транспортный уровень
- Сеансовый уровень
- Представительный уровень
- Прикладной уровень
- Сетезависимые и сетенезависимые уровни
- Протокол tcp/ip
- [Править] Уровни стека tcp/ip
- [Править] Физический уровень
- [Править] Канальный уровень
- [Править] Сетевой уровень
- [Править] Транспортный уровень
- [Править] Прикладной уровень
- Что такое маска подсети и шлюз по умолчанию (роутер, маршрутизатор)?
- Как посмотреть текущие соединения?
- Адресация в ip
- Бесклассовая адресация
- [Править] Диапазоны адресов
- [Править] Математическое обоснование
- [Править] Возможные маски
- [Править] Ссылки
- [Править] См. Также
- Классовая адресация
- [Править] Основные понятия
- Идентификаторы сетей и узлов
- Преобразование ip-адреса из двоичного формата в десятичный
- Упражнения
- Занятие2. Классы ip-адресов
- Изучив материал этого занятия, Вы сможете:
- Класс а
- Класс в
- Класс с
- Класс d
- Назначение идентификаторов сетей
- Назначение идентификаторов узлов
- Корректные идентификаторы узлов
- Методика назначения ip-адресов
- Упражнения
- Занятие4. Ip-адреса и маски подсетей
- Изучив материал этого занятия, Вы сможете:
- Маска подсети, задаваемая по умолчанию
- Определение адреса назначения пакета
- Упражнения
- Занятие5. Ip-адресация в ip версии 6.0
- Изучив материал этого занятия, Вы сможете:
- Классы ip-адресов
- Двоичная форма записи ip-адресов
- Особые ip-адреса
- Использование масок для ip-адресации
- Распределение ip-адресов
- Маршрутизация в ip
- Icmp ошибки о недоступности хоста и сети
- Icmp ошибки перенаправления
- Icmp сообщения поиска маршрутизатора (icmp Router Discovery Messages)