Подробнее о маршрутизации пакетов
Категория: Маршрутизация | Автор: admin | 25-03-2010, 02:50 | Просмотров: 3669

Прежде чем приступать к изучению алгоритмов маршрутизации, рассмотрим подробнее, как используются маршрутные таблицы. Предположим, сеть имеет топологию, изображенную на рис. А.

Маршрутизатор Ml связывает между собой два Ethernet-сегмента, а маршрутизатор М2 соединяет один из сегментов с внешним миром (считаем, что Ml и М2 — это UNIX-компьютеры, а не выделенные маршрутизаторы). Проверим, как выглядят таблицы маршрутизации. Вот таблица узла А:

А% netstat -rn

Routing tables

Destination      Gateway        Flags  Refs   Use      If

127.0.0.1        127.0.0.1      UH     6      563131   lo0

199.165.145.0    199.165.145.17 U      5      2845294  le0

default          199.165.145.24 UG     2      168589   le0

 

Узел А имеет самую простую конфигурацию среди всех четырех машин. Первые два маршрута описывают собственные сетевые интерфейсы узла. Они необходимы, чтобы пакеты, направляемые в непосредственно подключенные сети, не маршрутизировались особым образом. Устройство lе0 — это Ethernet-плата узла А, а lо0 — интерфейс обратной связи (виртуальный сетевой интерфейс, эмулируемый программным способом в ядре). Обычно эти записи автоматически добавляются командой ifconfig при конфигурировании сетевого интерфейса.

 

 

Как указывает флаг H, первая запись обозначает узловой маршрут, связанный с одним конкретным IP-адресом, а не всей сетью. Данный маршрут можно сделать сетевым, но это не имеет особого смысла, так как в сети обратной связи существует один-единственный IP-адрес. В таблице маршрутизации будет сделано всего одно изменение: в столбце destination появится адрес 127.0.0.0, а не 127.0.0.1 (соответственно, флаг Н исчезнет).

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

 

 

Стандартный маршрут узла А задает перенаправление всех пакетов не адресованных локальному компьютеру или сети, на маршрутизатор Ml, адрес которого в данной сети — 199.165.145.24. Флаг G указывает на то, что данный маршрут ведет к шлюзу, а не к одному из локальных интерфейсов узла А. Шлюзы должны находиться на расстоянии одного перехода.

Предположим теперь, что узел А посылает пакет узлу Б, адрес которого — 199.165.146.4. IP-подсистема ищет маршрут к указанной сети 199.165.146 и не найдя такового, отправляет пакет по стандартному маршруту, т.е. маршрутизатору Ml. На рис. Б приведен вид пакета, проходящего по сети Ethernet (в заголовке Ethernet указаны МАС-адреса интерфейсов А и М1 в сети 145).

 Подробнее о маршрутизации пакетов

Целевой аппаратный Ethernet-адрес обозначает маршрутизатор Ml, но IP-пакет, скрытый в Ethernet-кадре, не содержит никаких упоминаний о маршрутизаторе. Когда маршрутизатор проверяет поступивший пакет, он замечает, что его целевой IP-адрес не совпадает с аппаратным. Тогда он просматривает собственную таблицу маршрутизации, чтобы узнать, как переслать пакет узлу Б, не переписывая его заголовок (необходимо, чтобы отправителем пакета оставался узел А).

Так выглядит таблица маршрутизации узла Ml:

Rl% netstat -rn

Routing tables

Destination      Gateway        Flags   Refs    Use     If

127.0.0.1        127.0.0.1      UH      10      10233   lo0

199.165.146.0    199.165.146.1   U      15      4529    le1

199.165.145.0    199.165.145.24  U      0       121     le0

default          199.165.146.3  UG      4       168589  le1

Эта таблица похожа на таблицу для узла А, за исключением того, что в первой присутствуют два физических сетевых интерфейса. Стандартный маршрут в данном случае ведет к узлу М2, поскольку через него осуществляется выход в Internet. Пакеты, адресованные любой из сетей 199.16: доставляются напрямую.

Узел Б подобно узлу А имеет один реальный сетевой интерфейс. Но для корректного функционирования ему нужен дополнительный маршрут, поскольку он напрямую подключен сразу к двум маршрутизаторам. Трафик для сети 199.165.145 должен проходить через узел Ml, а весь остальной трафик — направляться в Internet через узел М2.

В% netstat -rn

Routing tables

Destination       Gateway         Flags    Refs    Use      If

127.0.0.1         127.0.0.1       UH       2       1543     lo0

199.165.146.0     199.165.146.4   U        15      4529     le0

199.165.145.0     199.165.146.1   UG       0       121      le0

default           199.165.146.3   UG       4       168589   le0

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

B% netstat -rn

Routing tables

Destination       Gateway         Flags    Refs   Use     If

127.0.0.1         127.0.0.1       UH       2      1543    lo0

199.165.146.0     199.165.146.4   U        15     4529    le0

default           199.165.146.3   UG       4      168589  le0

 

Теперь, если узел Б посылает пакет узлу А (199.165.145.17), прямой маршрут найден не будет, и пакет отправится на узел М2. Тот, будучи маршрутизатором, имеет полную информацию о состоянии сети, поэтому не только пошлет пакет узлу Ml, но также направит узлу Б ICMP-сообшение, в соответствии с которым узел Б добавит в таблицу маршрутизации прямой путь к узлу А:

199.165.145.17    199.165.146.1        UGHD       0     1    lе0

 

Благодаря этому маршруту весь будущий трафик, адресованный узлу А, будет идти непосредственно через маршрутизатор Ml. Однако данное изменение не затрагивает трафик к другим узлам в сети 145. Для них нужно получить отдельные уведомления от маршрутизатора М2.

Некоторые администраторы выбирают для своих систем переадресующие ICMP-директивы в качестве основного "протокола" маршрутизации, думая, что подобный подход обеспечит большую динамичность. К сожалению, если информация, касающаяся переадресованного маршрута, изменяется, нужно либо удалить маршрут из таблицы вручную, либо перезагрузить систему. Из-за этой, а также ряда других проблем (увеличение сетевого трафика, возрастание нагрузки на маршрутизатор М2, хаос в таблице маршрутизации, зависимость от внешних серверов) мы не рекомендуем применять такой подход. В правильно сконфигурированной сети переадресованные маршруты не должны появляться в таблице маршрутизации.


 (голосов: 2)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page