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).