Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
87
Добавлен:
20.02.2016
Размер:
727.55 Кб
Скачать

IP маршрутизация

Введение

Маршрутизация - это одна из наиболее важных функций IP. На рисунке 9.1 показана упрощенная модель того, что реализуется на IP уровене. Датаграммы, которые должны быть смаршрутизированы, могут генерироваться как локальным хостом, так и каким-либо удаленным хостом. В последнем случае наш хост должен быть сконфигурирован как маршрутизатор, иначе датаграммы, получаемые через сетевые интерфейсы и не предназначенные нашему хосту, будут молча удалены.

На рисунке 9.1 также показан демон маршрутизации, который обычно является пользовательским процессом. Наиболее часто в Unix системах используются демоны routed и gated. Термин демон (daemon) означает, что процесс работает "в фоновом режиме" и его функционирование не оказывает влияние на систему в целом. Демоны обычно стартуют, когда система загружается, и живут все время, пока система работает. Протоколы маршрутизации, используемые на конкретном хосте, определяют, как будет происходить обмен информацией о маршрутах с удаленными маршрутизаторами. (Заинтересованные читатели могут обратиться к [Perlman 1992] для получения более подробной информации.) Мы вкратце рассмотрим динамическую маршрутизацию и протокол обмена информацией о маршрутизации (RIP - Routing Information Protocol) в главе 10. В этой главе мы рассмотрим, как IP уровень принимает решения о маршрутизации.

IP уровень обращается к таблице маршрутизации, которая показана на рисунке 9.1 (на загруженных хостах подобное обращение может происходить несколько сот раз в секунду), однако демон маршрутизации обновляет таблицу значительно реже (примерно один раз каждые 30 секунд). Таблица маршрутизации также может быть обновлена, когда принимается ICMP сообщение о перенаправлении (ICMP redirect), мы увидим это в разделе "ICMP ошибки перенаправления", когда будем рассматривать команду route. Эта команда обычно исполняется при загрузке системы и устанавливает некоторые исходные маршруты. Также в этой главе мы будем использовать команду netstat, для просмотра таблиц маршрутизации.

Рисунок 9.1 Действия, выполняемые IP уровнем.

Принципы маршрутизации

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

  1. Поиск совпадающего адреса хоста.

  2. Поиск совпадающего адреса сети.

  3. Поиск пункта по умолчанию. (Пункт по умолчанию обычно указывается в таблице маршрутизации как сеть с идентификатором сети равным нулю.)

Совпавший адрес хоста используется всегда перед совпавшим адресом сети.

Маршрутизация, осуществляемая IP - процесс поиска в таблице маршрутизации, определение интерфейса, куда будет послан пакет, называется механизмом маршрутизации. С другой стороны, политика маршрутизации устанавливает правила, по которым решается, какой маршрут будет внесен в таблицу маршрутизации. IP осуществляет механизм маршрутизации, тогда как маршрутизирующий демон обычно определяет политику маршрутизации.

Простая таблица маршрутизации

Давайте рассмотрим типичные таблицы маршрутизации. На хосте svr4 мы запустили команду netstat с опцией -r, чтобы просмотреть таблицу маршрутизации, и с опцией -n, которая печатает IP адреса в цифровом формате, а не в виде имен. (Мы сделали это, потому что некоторые пункты таблицы маршрутизации это сети, а не хосты. Без опции -n команда netstat просматривает файл /etc/networks, и берет оттуда имена сетей. При этом может получиться некоторая путаница, потому что в выводе команды помимо имен хостов появятся имена сетей.)

 

svr4 % netstat -rn Routing tables Destination        Gateway            Flags       Refcnt  Use     Interface 140.252.13.65      140.252.13.35     UGH         0       0        emd0 127.0.0.1          127.0.0.1          UH          1       0        lo0 default            140.252.13.33      UG         0        0       emd0 140.252.13.32      140.252.13.34     U           4        25043   emd0

 

В первой строке говорится, что для пункта назначения 140.252.13.65 (хост slip) шлюз (маршрутизатор), на который будут посылаться пакеты, это 140.252.13.35 (bsdi). Хост slip подсоединен к bsdi через SLIP канал, а bsdi находится в той же сети Ethernet, что и данный хост.

Для конкретного маршрута может быть показано 5 различных флагов.

 

U

Маршрут активен.

G

Маршрут подключен к шлюзу (маршрутизатору). Если этот флаг не установлен, считается, что пункт назначения подключен непосредственно.

H

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

D

Маршрут был создан посредством перенаправления ("ICMP ошибки перенаправления").

M

Маршрут был модифицирован посредством перенаправления ("ICMP ошибки перенаправления").

 

Флаг G очень важен, потому что именно этот флаг определяет различие между непрямым маршрутом (indirect route) и прямым маршрутом (direct route). (Флаг G не устанавливается для прямого маршрута.) Отличие заключается в том, что у пакета, направляющегося по прямому маршруту, IP адрес и адрес канального уровня указывают на конечный пункт назначения (рисунок 3.3). Когда пакет отправляется по непрямому маршруту, IP адрес указывает на конечный пункт назначения, а адрес канального уровня указывает на маршрутизатор следующей пересылки. Мы видели подобный пример этого на рисунке 3.4. В этой таблице маршрутизации мы видим непрямой маршрут (флаг G установлен), при этом IP адрес пакета, который будет передаваться по этому маршруту, будет совпадать с IP адресом конечного пункта назначения (140.252.13.65), а адрес канального уровня будет указывать на соответствующий маршрутизатор, IP адрес которого 140.252.13.35.

Очень важно понимать разницу между флагами G и H. Флаг G определяет различие между прямым и непрямым маршрутом, как описано выше. Флаг H указывает на то, что адрес пункта назначения (первая колонка вывода команды netstat) это полный адрес хоста. Отсутствие флага H означает, что адрес назначения это адрес сети (идентификатор хоста должен быть установлен в 0). При просмотре таблицы маршрутизации используются следующие правила: если маршрут указывает на хост он должен полностью совпадать с IP адресом пункта назначения, если маршрут указывает на сеть - сопасть должны идентификаторы сети и любого идентификатора подсети в адресе пункта назначения. Большинство версий команды netstat сначала печатают все пункты, указывающие на хосты, после чего печатаются пункты, указывающие на сети.

Колонка счетчика обращений (reference count) сообщает о количестве использований каждого маршрута. Протоколы, ориентированные на соединения, такие как TCP, занимают маршрут все время, пока соединение установлено. Если установить Telnet соединение между хостами svr4 и slip, то счетчик обращений будет установлен в 1. Если установить еще одно Telnet соединение, счетчик будет показывать 2, и так далее.

Следующая колонка (use) показывает количество пакетов, прошедших по этому маршруту. Если запустить программу ping, которая отправит 5 пакетов, счетчик установится в значение 5 (Естественно, при условии, что никто больше не использует этот маршрут). Последняя колонка интерфейс (interface) сообщает нам имя локального интерфейса.

Вторая строка в выводе относится к loopback интерфейсу (глава 2, раздел "Интерфейс Loopback"), который всегда имеет имя lo0. Флаг G не установлен, так как маршрут не ведет к маршрутизатору. Флаг H указывает, что адрес назначения (127.0.0.1) это адрес хоста, а не адрес сети. Когда флаг G не установлен, это указывает на прямой маршрут, в колонке gateway указывается IP адрес исходящего интерфейса.

Третья строка вывода описывает маршрут по умолчанию. Каждый хост должен иметь один или несколько маршрутов по умолчанию. Этот пункт указывает на то, что необходимо посылать пакеты на маршрутизатор 140.252.13.33 (sun), если не был найден конкретный маршрут. Это означает, что хост svr4 может получить доступ к другим системам в Internet через маршрутизатор sun (и его SLIP канал) воспользовавшись этим единственным пунктом таблицы маршрутизации. Возможность установить маршрут по умолчанию это одна из наиболее мощных концепций IP маршрутизации. Флаги для этого маршрута (UG) говорят о том, что маршрут указывает на маршрутизатор.

 

Здесь мы специально назвали sun маршрутизатором, а не хостом, потому что когда он работает как маршрутизатор по умолчанию, используются его функции IP перенаправления, при этом он не выступает в роли хоста.

Требования к хостам Host Requirements RFC указывает, что IP уровень должен поддерживать несколько маршрутов по умолчанию. Большинство реализаций, однако, этого не позволяют. Когда существует несколько маршрутов по умолчанию, общая техника выбора маршрута заключается в последовательном многократном переборе маршрутов. Именно так поступает, например, Solaris 2.2.

 

И последняя строка указывает на подключенный Ethernet. Флаг H не установлен, это указывает на то, что адрес назначения (140.252.13.32) это адрес сети, при этом идентификатор хоста установлен в 0. И действительно, 5 младших битов установлены в 0 (рисунок 3.11). Это прямой маршрут (флаг G не установлен), поэтому в колонке gateway указывается IP адрес исходящего интерфейса.

Существует еще один немаловажный аспект, оказывающий влияние на маршрутизацию, однако он не отражен в выводе команды netstat. Это маска подсети, связанная с адресом назначения (140.252.13.32). Когда адрес пункта назначения сравнивается с IP адресом 140.252.13.33, адрес перед сравнением, логически суммируется с маской подсети, связанной с этим адресом назначения (0xffffffe0 из раздела "Пример подсети" главы 3). Так как ядро знает каждый интерфейс, связанный с каждым пунктом таблицы маршрутизации, и так как каждый интерфейс имеет маску подсети, каждый пункт таблицы маршрутизации имеет собственную маску подсети.

Сложность таблицы маршрутизации хоста зависит от топологии сетей, к которым хост имеет доступ.

  1. Самый простой (однако наименее интересный) случай - это когда хост вообще не подключен к сетям. Протоколы TCP/IP могут использоваться на этом хосте, однако только для общения с самим собой! Таблица маршрутизации в данном случае содержит единственный пункт соответствующий loopbackv интерфейсу.

  2. Хост подключен к одной локальной сети и имеет возможность получить доступ к хостам только в этой локальной сети. Таблица маршрутизации имеет 2 пункта: один для loopback интерфейса и один для локальной сети (например, Ethernet).

  3. Возможен вариант, когда другие сети (например, Internet) доступны через один маршрутизатор. В этом случае обычно используется пункт по умолчанию, указывающий на этот маршрутизатор.

  4. И последнее, когда добавляются маршруты к хостам или сетям. Примером этого может служить маршрут к хосту slip через маршрутизатор bsdi.

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

 

  1. Предположим, что адрес назначения принадлежит хосту sun, 140.252.13.33. Во-первых, осуществляется поиск совпадающего адреса хоста. Два пункта хостов в таблице (slip и localhost) не совпадают, поэтому поиск в таблице маршрутизации осуществляется снова на предмет совпадающего адреса сети. Совпадение найдено в пункте 140.252.13.32 (идентификатор сети и идентификатор подсети совпали), поэтому используется интерфейс emd0. Это прямой маршрут, поэтому адрес канального уровня будет являться адресом назначения.

  2. Предположим, что адрес назначения это адрес хоста slip, 140.252.13.65. Первый поиск в таблице маршрутизации на предмет совпадающего адреса хоста заканчивается успешно. Это непрямой маршрут, поэтому IP адрес назначения остается 140.252.13.65, а адресом канального уровня будет адрес канального уровня маршрутизатора 140.252.13.35, используется интерфейс emd0.

  3. Теперь мы посылаем датаграмму по Internet на хост aw.com (192.207.117.2). Первый поиск в таблице маршрутизации на предмет совпадающего адреса хоста заканчивается неудачей, поэтому осуществляется поиск на предмет совпадающего адреса сети. Он также завершается неудачно. И последний шаг это поиск пункта по умолчанию, который заканчивается успешно. Маршрут является непрямым через маршрутизатор 140.252.13.33 с использованием интерфейса emd0.

  4. В нашем последнем примере мы послали датаграмму на свой собственный хост. Существует 4 способа сделать это, используя имя хоста, IP адрес хоста, loopback имя или loopback IP адрес:

ftp svr4 ftp 140.252.13.34 ftp localhost ftp 127.0.0.1

 

В двух первых случаях второй поиск в таблице маршрутизации приведет к совпадению с сетью 140.252.13.32, и пакет посылается через Ethernet драйвер. Как мы показали на рисунке 2.4, пакет, предназначенный на собственный IP адрес хоста, посылается в loopback драйвер, который ставит пакет во входную очередь IP.

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

Во всех четырех случаях пакет отправляется в loopback драйвер, однако принимаются два разных решения о маршрутизации.

 

Инициализация таблицы маршрутизации

Мы никогда не упоминали о том, как создаются пункты в таблице маршрутизации. Когда инициализируется интерфейс (обычно, когда адрес интерфейса устанавливается командой ifconfig), автоматически создается прямой маршрут для этого интерфейса. Для каналов точка-точка и loopback интерфейса устанавливается маршрут к хосту (то есть устанавливается флаг H). Для широковещательных интерфейсов, таких как Ethernet, маршрутом является сама эта сеть.

Маршруты к хостам или сетям, которые не подключены непосредственно, должны быть помещены в таблицу маршрутизации каким-либо иным образом. Самый распространенный способ создания маршрутов - с помощью команды route, что обычно делается из загрузочных файлов при старте системы. На хосте svr4 были исполнены следующие команды, которые добавляют пункты, показанные ранее:

 

route add default sun 1 route add slip bsdi 1

 

Третий аргумент (default и slip) это пункты назначения, четвертый аргумент это маршрутизатор (gateway) и последний аргумент это показатель маршрутизации. Команда route использует показатель маршрутизации следующим образом: она устанавливает флаг G, если показатель больше чем 0, и не устанавливает флаг G, если показатель равен 0.

 

К сожалению, совсем немногие системы содержат команды route в своих стартовых файлах. В 4.4BSD и BSD/386 это /etc/netstat, в SVR4 - /etc/inet/rc.inet, в Solaris 2.x - /etc/rc2.d/S69inet, в SunOS 4.1.x - /etc/rc.local и в AIX 3.2.2 - /etc/rc.net.

 

В некоторых системах маршрутизатор по умолчанию содержится в файле, например, /etc/defaultrouter. Этот пункт по умолчанию добавляется в таблицу маршрутизации при каждой перезагрузке.

Существует еще один способ заполнить таблицу маршрутизации с помощью запуска демона маршрутизации (см. главу 10) или с помощью нового протокола определения маршрутов (раздел "ICMP сообщения поиска маршрутизатора").

Более сложные таблицы маршрутизации

Хост sun является маршрутизатором по умолчанию для всех хостов в нашей подсети, так как он имеет SLIP канал с дозвоном, который подключен к Internet (см. рисунок на внутренней стороне обложки).

 

sun % netstat -rn Routing tables Destination      Gateway            Flags     Refcnt  Use      Interface 140.252.13.65    140.252.13.35     UGH       0       171       le0 127.0.0.1        127.0.0.1          UH       1        766      lo0 140.252.1.183    140.252.1.29      UH        0       0         sl0 default          140.252.1.183      UG       1        2955     sl0 140.252.13.32    140.252.13.33     U         8       99551     le0

 

Первые два пункта таблицы маршрутизации sun идентичны первым двум пунктам для хоста svr4: маршрут, указывающий на хост slip, через маршрутизатор bsdi и loopback маршрут.

Третья строка отличается. Это прямой маршрут (флаг G не установлен) на хост (флаг H установлен), соответствующий каналу точка-точка, интерфейс SLIP. Если мы посмотрим на вывод команды ifconfig,

 

sun % ifconfig sl0 sl0: flags=1051<UP, POINTOPOINT, RUNNING>         inet 140.252.1.29 --> 140.252.1.183 netmask ffffff00

 

то увидим, что адрес назначения в таблице маршрутизации на другом конце канала точка-точка (маршрутизатор netb), а адрес маршрутизатора в действительности это локальный IP адрес исходящего интерфейса (140.252.1.29). (Раньше мы говорили, что для прямых маршрутов адрес маршрутизатора печатается командой netstat как локальный IP адрес используемого интерфейса.)

Пункт по умолчанию это непрямой маршрут (флаг G), указывающий на сеть (нет флага H). Адрес маршрутизатора - 140.252.1.183, (адрес на другом конце SLIP канала), а не локальный IP адрес SLIP интерфейса (140.252.1.29) (так как это непрямой маршрут).

Необходимо обратить внимание на то, что третья и четвертая строки в выводе команды netstat (интерфейс sl0) создаются программным обеспечением SLIP при установлении канала SLIP, они удаляются, когда канал SLIP отключается.

Нет маршрута к пункту назначения

Во всех наших примерах сделано предположение, что поиск в таблице маршрутизации заканчивается успешно и будет обнаружено соответствие, хотя бы с маршрутором по умолчанию. Что произойдет, если маршрут по умолчанию отсутствует, и не будет найдено совпадение с указанным пунктом назначения?

Ответ зависит от того, какого рода IP датаграмма обрабатывается, то есть была ли она сгенерирована непосредственно этим хостом или она должна быть перенаправлена (в том случае, если хост выступает в роли маршрутизатора). Если датаграмма была сгенерирована этим хостом, приложению, которое отправило датаграмму, возвращается ошибка "хост недоступен" (host unreachable) или "сеть недоступна" (network unreachable). Если датаграмма должна быть перенаправлена, посылающему хосту возвращается ICMP собщение о недоступности хоста. Мы рассмотрим эту ошибку в следующем разделе.

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 gemini ICMP 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 нет маршрута, он отвечает на эхо запрос сообщением о недоступности хоста.

Если мы включим SLIP канал, подключающий нас к Internet, и попробуем послать ping на несуществующий в Internet IP адрес, то рано или поздно получим сообщение об ошибке. Интересно посмотреть, как далеко уйдет пакет по Internet, перед тем как будет получена ошибка:

 

sun % ping 192.82.148.1               этот IP адрес не подключен к Internet PING 192.82.148.1: 56 data bytes ICMP Host Unreachable from gateway enss142.UT.westnet.net (192.31.39.21)   for icmp from sun (140.252.1.29) to 192.82.148.1

 

Обратившись к рисунку 8.5, мы увидим, что пакет прошел через шесть маршрутизаторов, перед тем как было определено, что IP адрес не существует. Только когда он дошел до пределов NSFNET магистрали, была выявлена ошибка. Это произошло из-за того, что шесть маршрутизаторов, которые перенаправляли пакет, отправляли его на пункт назначения по умолчанию. И только когда пакет достиг NSFNET магистрали, маршрутизатор, имеющий полное представление о каждой сети, подключенной к Internet, смог определить ошибку. Это иллюстрирует тот факт, что большинство маршрутизаторов функционируют, не представляя себе полной топологии сетей.

[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), пока системный администратор специально не включит перенаправление.

Соседние файлы в папке сети-учебники