| |
Содержание
6. Установка маршрутов
До сих пор мы рассматривали то, как используется таблица маршрутов
для маршрутизации IP-пакетов. Но откуда берется информация в самой таб-
лице маршрутов? В данном разделе мы рассмотрим методы, позволяющие под-
держивать корректность таблиц маршрутов.
6.1. Фиксированные маршруты
Простейший способ проведения маршрутизации состоит в установке марш-
рутов при запуске системы с помощью специальных команд. Этот метод можно
применять в относительно маленьких IP-сетях, в особенности, если их кон-
фигурации не часто меняются.
На практике большинство машин автоматически формирует таблицы марш-
рутов. Например, UNIX добавляет записи о IP-сетях, к которым есть непос-
редственный доступ. Стартовый файл может содержать команды
ifconfig ie0 128.6.4.4 netmask 255.255.255.0
ifconfig ie1 128.6.5.35 netmask 255.255.255.0
Они показывают, что существуют два сетевых интерфейса, и устанавливают их
IP-адреса. Система может автоматически создать две записи в таблице
маршрутов:
----------------------------------------------------------
| сеть флаг вида шлюз интерфейс |
| маршрутизации |
----------------------------------------------------------
| 128.6.4 прямая <пусто> ie0 |
| 128.6.5 прямая <пусто> ie1 |
----------------------------------------------------------
Табл.15. Автоматически создаваемые записи
Эти записи определяют, что IP-пакеты для локальных подсетей 128.6.4 и
128.6.5 должны посылаться через указанные интерфейсы.
В стартовом файле могут быть команды, определяющие маршруты доступа
к другим IP-сетям. Например,
route add 128.6.2.0 128.6.4.1 1
route add 128.6.6.0 128.6.5.35 0
Эти команды показывают, что в таблицу маршрутов должны быть добавлены две
записи. Первый адрес в командах является IP-адресом сети, второй адрес
указывает шлюз, который должен использоваться для доступа к данной IP-
сети, а третий параметр является метрикой. Метрика показывает, на каком
"расстоянии" находится описываемая IP-сеть. В данном случае метрика -
это количество шлюзов на пути между двумя IP-сетями. Маршруты с метрикой
1 и более определяют первый шлюз на пути к IP-сети. Маршруты с метрикой
0 показывают, что никакой шлюз не нужен - данный маршрут задает дополни-
тельный сетевой номер локальной IP-сети.
Таким образом, команды, приведенные в примере, говорят о том, что
для доступа к IP-сети 128.6.2 должен использоваться шлюз 128.6.4.1, а
IP-сеть 128.6.6 - это просто дополнительный номер для физической сети,
подключенной к интерфейсу 128.6.5.35.
---------------------------------------------------------
| сеть флаг вида шлюз интерфейс |
| маршрутизации |
---------------------------------------------------------
| 128.6.2 косвенная 128.6.4.1 ie0 |
| 128.6.6 прямая <пусто> ie1 |
---------------------------------------------------------
Табл.16. Записи, добавляемые в таблицу маршрутов
Можно определить маршрут по умолчанию, который используется в тех
случаях, когда IP-адрес места назначения не встречается в таблице маршру-
тов явно. Обычно маршрут по умолчанию указывает IP-адрес шлюза, который
имеет достаточно информации для маршрутизации IP-пакетов со всеми возмож-
ными адресами назначения.
Если ваша IP-сеть имеет всего один шлюз, тогда все, что нужно сде-
лать, - это установить единственную запись в таблице маршрутов, указав
этот шлюз как маршрут по умолчанию. После этого можно не заботиться о
формировании маршрутов в других узлах. (Конечно, сам шлюз требует больше
внимания.)
Следующие разделы посвящены IP-сетям, где есть несколько шлюзов.
6.2. Перенаправление маршрутов
Большинство экспертов по межсетевому взаимодействию рекомендуют
оставлять решение проблем маршрутизации шлюзам. Плохо иметь на каждой
машине большую таблицу маршрутов. Дело в том, что при каких-либо измене-
ниях в IP-сети приходится менять информацию во всех машинах. Например,
при отключении какого-нибудь канала связи для восстановления нормальной
работы нужно ждать, пока кто-то заметит это изменение в конфигурации IP-
сети и внесет исправления во все таблицы маршрутов.
Простейший способ поддержания адекватности маршрутов заключается в
том, что изменение таблицы маршрутов каждой машины выполняется по коман-
дам только одного шлюза. Этот шлюз должен быть установлен как маршрут по
умолчанию. (В ОС UNIX это делается командой "route add default
128.6.4.27 1", где 128.6.4.27 является IP-адресом шлюза.) Как было опи-
сано выше, каждая машина посылает IP-пакет шлюзу по умолчанию в том слу-
чае, когда не находит лучшего маршрута. Однако, когда в IP-сети есть
несколько шлюзов, этот метод работает не так хорошо. Кроме того, если
таблица маршрутов имеет только одну запись о маршруте по умолчанию, то
как использовать другие шлюзы, если это более выгодно? Ответ состоит в
том, что большинство шлюзов способны выполнять "перенаправление" в тех
случаях, когда они получают IP-пакеты, для которых существуют более
выгодные маршруты. "Перенаправление" является специальным типом сообще-
ния протокола ICMP (Internet Control Message Protocol - протокол межсете-
вых управляющих сообщений). Сообщение о перенаправлении содержит инфор-
мацию, которую можно интерпретировать так: "В будущем для IP-адреса XXXX
используйте шлюз YYYY, а не меня". Корректные реализации TCP/IP должны
использовать сообщения о перенаправлении для добавления записей в таблицу
маршрутов. Предположим, таблица маршрутов в начале выглядит следующим
образом:
--------------------------------------------------------
| адрес флаг вида шлюз интерфейс |
| назначения маршрутизации |
--------------------------------------------------------
| 127.0.0 прямая <пусто> lo0 |
| 128.6.4 прямая <пусто> pe0 |
| default косвенная 128.6.4.27 pe0 |
--------------------------------------------------------
Табл.17. Таблица маршрутов в начале работы
Эта таблица содержит запись о локальной IP-сети 128.6.4 и маршрут по
умолчанию, указывающий шлюз 128.6.4.27. Допустим, что существует шлюз
128.6.4.30, который является лучшим путем доступа к IP-сети 128.6.7. Как
им воспользоваться? Предположим, что нужно посылать IP-пакеты по IP-
адресу 128.6.7.23. Первый IP-пакет пойдет на шлюз по умолчанию, так как
это единственный подходящий маршрут, описанный в таблице. Однако шлюз
128.6.4.27 знает, что существует лучший маршрут, проходящий через шлюз
128.6.4.30. (Как он узнает об этом, мы сейчас не рассматриваем. Сущест-
вует довольно простой метод определения лучшего маршрута.) В этом случае
шлюз 128.6.4.27 возвращает сообщение перенаправления, где указывает, что
IP-пакеты для узла 128.6.7.23 должны посылаться через шлюз 128.6.4.30.
Модуль IP на машине-отправителе должен добавить запись в таблицу маршру-
тов:
--------------------------------------------------------
| адрес флаг вида шлюз интерфейс |
| назначения маршрутизации |
--------------------------------------------------------
| 128.6.7.23 косвенная 128.6.4.30 pe0 |
--------------------------------------------------------
Табл.18. Новая запись в таблице маршрутов
Все последующие IP-пакеты для узла 128.6.7.23 будут посланы прямо через
указанный шлюз.
До сих пор мы рассматривали способы добавления маршрутов в IP-
таблицу, но не способы их исключения. Что случится, если шлюз будет вык-
лючен? Хотелось бы иметь способ возврата к маршруту по умолчанию после
того, как какой-либо маршрут разрушен. Однако, если шлюз вышел из строя
или был выключен, то он уже не может послать сообщение перенаправления.
Поэтому должен существовать метод определения работоспособности шлюзов, с
которыми ваша машина связана непосредственно. Лучший способ обнаружения
неработающих шлюзов основан на выявлении "плохих" маршрутов. Модуль TCP
поддерживает различные таймеры, которые помогают ему определить разрыв
соединения. Когда случается сбой, то можно пометить маршрут как "плохой"
и вернуться к маршруту по умолчанию. Аналогичный метод может использо-
ваться при обработке ошибок шлюза по умолчанию. Если два шлюза отмечены
как шлюзы по умолчанию, то машина может использовать их по очереди,
переключаясь между ними при возникновении сбоев.
6.3. Слежение за маршрутизацией
Заметим, что сообщения перенаправления не могут использоваться
самими шлюзами. Перенаправление - это просто способ оповещения обычного
узла о том, что нужно использовать другой шлюз. Сами шлюзы должны иметь
полную картину о положении дел в сети internet и уметь вычислять опти-
мальные маршруты доступа к каждой подсети. Обычно они поддерживают эту
картину, обмениваясь информацией между собой. Для этой цели существуют
несколько специальных протоколов маршрутизации. Один из способов, с
помощью которого узлы могут определять действующие шлюзы, состоит в сле-
жении за обменом сообщениями между ними. Для большинства протоколов
маршрутизации существует программное обеспечение, позволяющее обычным
узлам осуществлять такое слежение. При этом на узлах поддерживается пол-
ная картина положения дел в сети internet точно также, как это делается в
шлюзах. Динамическая корректировка таблицы маршрутов позволяет посылать
IP-пакеты по оптимальным маршрутам.
Таким образом, слежение за маршрутизацией в некотором смысле
"решает" проблему поддержания корректности таблиц маршрутов. Однако
существуют несколько причин, по которым этот метод применять не рекомен-
дуется. Наиболее серьезной проблемой является то, что протоколы маршру-
тизации пока еще подвергаются частым пересмотрам и изменениям. Появля-
ются новые протоколы маршрутизации. Эти изменения должны учитываться в
программном обеспечении всех машин.
Несколько более специальная проблема связана с бездисковыми рабочими
станциями. По своей природе бездисковые машины сильно зависят от сети и
от файл-серверов, с которых они осуществляют загрузку программ, и где
располагается их область своппинга. Исполнение программ, следящих за
широковещательными передачами в сети, на бездисковых машинах связано с
большими трудностями. Протоколы маршрутизации построены в основном на
широковещательных передачах. Например, все сетевые шлюзы могут широкове-
щательно передавать содержание своих таблиц маршрутов через каждые 30
секунд. Программы, которые следят за такими передачами, должны быть заг-
ружены на бездисковые станции через сеть. На достаточно занятой машине
программы, которые не используются в течение нескольких секунд, обычно
отправляются в область своппинга. Поэтому программы, следящие за маршру-
тизацией, большую часть времени находятся в своппинге. Когда они вновь
активизируются, должна производиться подкачка из своппинга. Как только
посылается широковещательное сообщение, все машины активизируют прог-
раммы, следящие за маршрутизацией. Это приводит к тому, что многие без-
дисковые станции будут выполнять подкачку из своппинга в одно и тоже
время. Поэтому в сети возникнет временная перегрузка. Таким образом,
исполнение программ, прослушивающих широковещательные передачи, на без-
дисковых рабочих станциях очень нежелательно.
6.4. Протокол ARP с представителем
Протокол ARP с представителем является альтернативным методом, поз-
воляющим шлюзам принимать все необходимые решения о маршрутизации. Он
применяется в сетях с широковещательной передачей, где для отображения
IP-адресов в сетевые адреса используется протокол ARP или ему подобный.
Здесь мы вновь будем предполагать, что имеем дело с сетью Ethernet.
Во многом метод, реализуемый протоколом ARP с представителем, анало-
гичен использованию маршрутов по умолчанию и сообщений перенаправления.
Но протокол ARP с представителем не затрагивает таблиц маршрутов, все
делается на уровне адресов Ethernet. Протокол ARP с представителем может
использоваться либо для маршрутизации IP-пакетов ко всем сетям, либо
только в локальной сети, либо в какой-то комбинации подсетей. Проще
всего продемонстрировать его использование при работе со всеми адресами.
Чтобы использовать протокол, нужно настроить узел так, как будто все
машины в мире подключены непосредственно к вашей локальной сети Ethernet.
В ОС UNIX это делается командой "route add default 128.6.4.2 0", где
128.6.4.2 - IP-адрес вашего узла. Как уже отмечалось, метрика 0 говорит
о том, что все IP-пакеты, которым подходит данный маршрут, должны посы-
латься напрямую по локальной сети.
Когда нужно послать IP-пакет узлу в локальной сети Ethernet, ваша
машина должна определить Ethernet-адрес этого узла. Для этого она
использует ARP-таблицу. Если в ARP-таблице уже есть запись, соответству-
ющая IP-адресу места назначения, то из нее просто берется Ethernet-адрес,
и кадр, содержащий IP-пакет, отправляется. Если такой записи нет, то
посылается широковещательный ARP-запрос. Узел с искомым IP-адресом наз-
начения принимает его и в ARP-ответе сообщает свой Ethernet-адрес. Эти
действия соответствуют обычному протоколу ARP, описанному выше.
Протокол ARP с представителем основан на том, что шлюзы работают как
представители удаленных узлов. Предположим, в подсети 128.6.5 имеется
узел 128.6.5.2 (узел A на рис.12). Он желает послать IP-пакет узлу
128.6.4.194, который подключен к другой сети Ethernet (узел B в подсети
128.6.4). Существует шлюз с IP-адресом 128.6.5.1, соединяющий две под-
сети (шлюз R).
сеть 1 сеть 2
128.6.5 128.6.4
----o----------------o--- --o---------------o--------
| | | |
------------- ------------- ---------------
| 128.6.5.2 | | 128.6.5.1 | | 128.6.4.194 |
| A | | 128.6.4.1 | | B |
------------- | R | ---------------
-------------
Рис.12. Сеть, использующая протокол ARP с представителем
Если в ARP-таблице узла A нет маршрута доступа к узлу B, то узел A посы-
лает ARP-запрос узлу B. Фактически машина A спрашивает: "Если кто-нибудь
знает Ethernet-адрес узла 128.6.4.194, сообщите мне его". Узел B не
может ответить на запрос самостоятельно. Он подключен к другой сети Eth-
ernet и никогда даже не увидит этот ARP-запрос. Однако шлюз R может
работать от его имени. Шлюз R отвечает: "Я здесь, IP-адресу 128.6.4.194
соответствует Ethernet-адрес 2:7:1:0:EB:CD", где 2:7:1:0:EB:CD в действи-
тельности является Ethernet-адресом шлюза. Это создает иллюзию, что узел
128.6.4.194 подключен непосредственно к той же локальной сети Ethernet,
что и узел A, и имеет Ethernet-адрес 2:7:1:0:EB:CD. Когда узел A захочет
послать новый IP-пакет узлу B, он использует указанный Ethernet-адрес.
Кадр, содержащий IP-пакет, попадет к шлюзу R, а он переправит его по наз-
начению.
Заметим, что полученный эффект такой же, как если бы в таблице марш-
рутов была запись
--------------------------------------------------------
| адрес флаг вида шлюз интерфейс |
| назначения маршрутизации |
--------------------------------------------------------
| 128.6.4.194 косвенная 128.6.5.1 pe0 |
--------------------------------------------------------
за исключением того, что маршрутизация выполняется на уровне модуля ARP,
а не модуля IP.
Обычно рекомендуется использовать таблицу маршрутов, так как архи-
тектура протоколов TCP/IP предусматривает выполнение маршрутизации на
межсетевом уровне. Однако иногда протокол ARP с представителем очень
полезен. Он может помочь в следующих случаях:
1) в IP-сети есть узел, который не умеет работать с подсетями;
2) в IP-сети есть узел, который не может соответствующим образом реаги-
ровать на сообщения перенаправления;
3) нежелательно выбирать какой-либо шлюз как маршрут по умолчанию;
4) программное обеспечение не способно восстанавливаться при сбоях на
маршрутах.
Иногда протокол ARP с представителем выбирают из-за удобства. Дело
в том, что он упрощает работу по начальной установке таблицы маршрутов.
Даже в простейших IP-сетях требуется устанавливать маршрут по умолчанию,
то есть использовать команду типа "route add defailt ...", как в ОС UNIX.
При изменении IP-адреса шлюза эту команду приходится менять во всех
узлах. Если же использовать протокол ARP с представителем, т.е. в
команде установки маршрута по умолчанию указать метрику 0, то при замене
IP-адреса шлюза команду начальной установки менять не придется, так как
протокол ARP с представителем не требует явного задания IP-адресов шлю-
зов. Любой шлюз может ответить на ARP-запрос.
Для того, чтобы избавить пользователей от обязательной начальной
установки маршрутов, некоторые реализации TCP/IP используют протокол ARP
с представителем по умолчанию в тех случаях, когда не находят подходящих
записей в таблице маршрутов.
Содержание
|
