Маршрутные протоколы RIP, OSPF и BGP

Может показаться, что проблема надумана, моя локальная сеть является внутренней, а все, что за ее пределами, – внешнее. На рисунке показаны семь маршрутизаторов (R1R7), один из них связывает эту систему с Интернет. К каждому маршрутизатору подключена одна или несколько субсетей (иначе бы маршрутизаторы были просто не нужны). Следует помнить, что вся эта система маршрутизаторов после подключения становится равноправной частью Интернет. С топологической точки зрения задача маршрутизации сводится к построению оптимального пути от ЭВМ-отправителя к ЭВМ-получателю. В этом подходе все маршрутизаторы и узлы Интернет равноправны, и деление их на внутренние и внешние условно. И тем не менее, такое деление вполне оправдано. Связано это чисто с технологическими возможностями современных маршрутизаторов (и отчасти протоколов), с ограниченностью их памяти и быстродействия. Здесь нужно заметить, что, например, не всегда прямой путь от R5 к R6 является наилучшим, он может, в частности, иметь малую пропускную способность или быть сильно перегруженным. Что считать внутренним, а что внешним, — имеет и юридический аспект. Здесь возникают проблемы, связанные с разглашением частной информации о гражданах, бывают и более тяжелые случаи.

Несколько лет назад разработчик почтовой системы PGP (Pretty Good Privacy) Фил Циммерман (США) был привлечен к суду за то, что способствовал распространению систем шифрования со слишком длинными ключами (большими, чем это разрешено экспортными ограничениями), что создавало трудности американским спецслужбам. Сидеть бы ему в тюрьме, если бы не общественное мнение и умелые адвокаты. Последние убедили суд, что Циммерман ничего не экспортировал, он лишь положил программы на общедоступный сервер, а ушлые европейцы и шустрые китайцы копировали эти программы с его сервера. Вот их и надо привлекать к суду за нарушение экспортных законов. Это оказалось не по плечу могущественной американской Фемиде — они уж точно вовне и на них распространить законы США не так просто. Пограничные проблемы приходится решать при борьбе с хакерами и другими компьютерными террористами и хулиганами. Современное законодательство в этой сфере пока несовершенно.

Если адресат достижим более чем одним путем (например, R7 может передать пакет в R2 более чем 6 путями), маршрутизатор должен сделать выбор, этот выбор осуществляется на основании оценки маршрутов-кандидатов. Обычно каждому сегменту, составляющему маршрут, присваивается некоторая величина — оценка этого сегмента. Каждый протокол маршрутизации использует свою систему оценки маршрутов. Оценка сегмента маршрута называется метрикой. Здесь следует обратить внимание на то, что при выборе маршрута всем сегментам пути должны быть даны сопоставимые значения метрики. Недопустимо, чтобы одни сегменты оценивались числом шагов, а другие — по величине задержки в миллисекундах. В пределах автономной системы это обычно не создает проблем, ведь это зона ответственности одного администратора. Но в региональных сетях, где работает много администраторов, проблема выбора метрики может стать реальной трудностью. Именно по этой причине в таких сетях в качестве метрики сегодня используется вектор расстояния (число шагов), исключающий субъективность оценок метрики.

Помимо классической схемы маршрутизации по адресу места назначения, часто используется вариант выбора маршрута отправителем (данный вариант получил дальнейшее развитие при введении стандарта IPv6). В этом случае IP-пакет содержит соответствующий код опции и список промежуточных адресов узлов, которые он должен посетить по пути к месту назначения.

Существуют и другие схемы, например, использующие широковещательные методы маршрутизации (flooding), где в процессе поиска пути каждый приходящий пакет посылается по всем имеющимся исходящим каналам, за исключением того, по которому он получен. Чтобы исключить беспредельное размножение пакетов, в заголовок вводится поле-счетчик числа шагов. В каждом узле содержимое поля уменьшается на единицу. Когда значение поля становится равным нулю, пакет ликвидируется. Исходное значение счетчика определяется размером субсети. Предпринимаются специальные меры против возможного зацикливания пакетов. Существует усовершенствованная версия широковещательной маршрутизации, называемая селективной широковещательной рассылкой. В этом алгоритме рассылка производится не по всем возможным направлениям, а только по тем, которые предположительно ведут в правильную сторону. Широковещательные методы не относятся к широко применимым. Но они используются там, где нужна предельно возможная надежность, например, в военных приложениях, когда весьма вероятно повреждение тех или иных каналов. Данные методы могут применяться лишь при формировании виртуального канала, ведь они всегда обеспечивают наикратчайший путь, так как перебираются все возможности. Если путь записывается в пакете, получатель может выбрать оптимальный проход и уведомить об этом отправителя.

Большинство алгоритмов учитывают топологию связей, а не их качество (пропускную способность, загрузку, качество и пр.). Но существуют подходы к решению проблемы статической маршрутизации, учитывающие как топологию, так и загрузку (flowbased routing). В некоторых сетях потоки между узлами относительно стабильны и предсказуемы. В этом случае появляется возможность вычислить оптимальную схему маршрутов заранее. Здесь на основе теории массового обслуживания производится оценка средней задержки доставки для каждой связи. Топология маршрутов оптимизируется по значению задержки доставки пакета. Исходными данными при расчете считаются описание топологии связей, матрица трафика для всех узлов T_i,j (в пакетах в секунду) и матрица пропускных способностей каналов B_i,j в битах в секунду. Задержка ? для каждой из связей оценивается по формуле

,

где 1/Р — среднее значение ширины пакета в битах, произведение P*B_i,j выражается в пакетах в секунду, а измеряется в мсек. Сформировав матрицу , можно получить граф кратчайших связей. Так как вычисления производятся не в реальном масштабе времени, особых трудностей здесь не возникает (если число узлов не слишком велико).

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

Хакер может имитировать работу маршрутизатора и вынудить посылку всех пакетов через его машину, объявив, что доступ ко всем узлам Интернет ближе или лучше через его рабочую станцию (этакий волшебный гиперканал!). По этой причине, если можно обойтись без динамической маршрутизации, лучше это сделать, ведь облегчение жизни хакерам в наши задачи не входит.

Рассмотрим для примера сеть, изображенную на рис. 8.3.

Рис. 8.3. Схема для иллюстрации методики составления маршрутных таблиц. G1, G2, G3 — маршрутизаторы

Примитивная таблица маршрутизации для приведенного примера может иметь вид (для маршрутизатора G2):

Заметно сокращает размер маршрутной таблицы маршруты по умолчанию. В этой схеме сначала отыскивается маршрут в таблицах, а если он не найден, пакет посылается в узел, специально выбранный для данного случая. Так, когда имеется только один канал за рубеж, неудачный поиск в таблице маршрутов по России означает, что пакет следует послать по этому каналу и пусть там с ним разбираются. Маршруты по умолчанию используются обычно тогда, когда маршрутизатор имеет ограниченный объем памяти или по какой-то иной причине не имеет полной таблицы маршрутизации. Маршрут по умолчанию может помочь реализовать связь даже при ошибках в маршрутной таблице. Это может не иметь никаких последствий для малых сетей, но для региональных сетей с ограниченной пропускной способностью такое решение может создать серьезные проблемы. Экономия на памяти для маршрутных таблиц – дурной стиль, который не доведет до добра. Например, из-за такого рода ошибки довольно долго пакеты из Ярославля в Москву шли через США; я уже не говорю о случае, когда машины, размещенные в соседних комнатах Президиума РАН, вели обмен между собой через Амстердам (правда, это было достаточно давно). Алгоритм выбора маршрута универсален и не зависит от протокола маршрутизации, который применяется лишь для формирования маршрутной таблицы. Общий алгоритм выбора оптимального маршрута на основе метрик сегментов пути сформулировал американский математик Дикстра в 1959 году.

Описание алгоритма переадресации конкретного пакета с помощью маршрутной таблицы представлено ниже.

Извлечь IP-адрес (ID) места назначения из дейтограммы.

Вычислить IP-адрес сети назначения ( IN )

if IN соответствует какому-либо адресу локальной сети, послать дейтограмму по этому адресу;

else if IN присутствует в маршрутной таблице, то послать дейтограмму к серверу, указанному в таблице;

else if описан маршрут по умолчанию, то послать дейтограмму к этому серверу;

else выдать сообщение об ошибке маршрутизации (недоступность адресата).

Если сеть включает в себя субсети, то для каждой записи в маршрутной таблице производится побитная операция <И> для ID и маски субсети. Если результат этой операции совпадет с содержимым адресного поля сети, дейтограмма посылается шлюзу субсети. На практике при наличии субсетей в маршрутную таблицу добавляются соответствующие записи с масками и адресами сетей. Машины одной и той же субсети не должны подключаться к разным интерфейсам маршрутизатора. При маршрутизации используется только сетевая часть IP-адреса.

Одна из базовых идей маршрутизации заключается в том, чтобы сконцентрировать маршрутную информацию в ограниченном числе (в идеале — в одном) узловых маршрутизаторов-диспетчеров. Эта замечательная идея ведет к заметному увеличению числа шагов при пересылке пакетов. Оптимизировать решение позволяет backbone (опорная сеть), к которой подключаются узловые маршрутизаторы. Любая AS подключается к backbone через узловой маршрутизатор.

"Прозрачные" backbone не работают с адресами класса С (все объекты такой сети должны иметь один адрес, а для C-класса число объектов слишком ограничено). Любопытные могут обратить, например, внимание на тот факт, что большинство AS Южной Опорной сети Москвы (ЮМОС) используют IP-адреса класса С (192.Х.Х.Х или больше), а FDDI-переключатели имеют адреса 184.X.X.X (IP-адреса класса B). "Прозрачные" IP-мосты трудно диагностировать, так как они не поддерживают протокол ICMP (команда ping для них не работает; в последнее время такие объекты снабжаются SNMP-поддержкой, что облегчает проблему диагностики). Зато они позволяют перераспределять нагрузку между несколькими маршрутизаторами, что невозможно для большинства протоколов.

Рис. 8.4.

В примере, приведенном на рис. 8.4, задача маршрутизации достаточно сложна. ЭВМ1,2 и ЭВМ6,1 можно связать многими путями: ЭВМ1,2 – GW1 – ЭВМ6,1; ЭВМ1,2 – GW2 – ЭВМ6,1; ЭВМ1,2 – GW3 – ЭВМ6,1; ЭВМ1,2 – GW4 – ЭВМ6,1; ЭВМ1,2 – GW1 – GW2 – GW3 – ЭВМ6,1; и т.д. Трафик между двумя географически близкими узлами должен направляться кратчайшим путем, вне зависимости от направления глобальных потоков. Так, ЭВМ1,2 и ЭВМ1,1 должны соединяться через GW1. Маршрутизация через опорные сети (backbone) требует индивидуального подхода для каждого узла. Администраторы опорных сетей должны согласовывать свои принципы маршрутизации. Ситуация, когда узел не владеет исчерпывающей маршрутной информацией, в сочетании с использованием маршрутов по умолчанию может привести к зацикливанию пакетов. Например, если маршрут по умолчанию в GW1 (на рис. 8.5) указывает на GW2, а в GW2 — на GW1, то пакет с несуществующим адресом (это может произойти из-за искажения адреса при транспортировке) будет циркулировать между GW1 и GW2, пока не истечет TTL (время жизни пакета). По этой причине желательно иметь полную таблицу маршрутизации и, если не вынуждают обстоятельства, избегать использования маршрутов по умолчанию.

Рис. 8.5.

Протоколы маршрутизации отличаются друг от друга тем, где хранится, и как формируется маршрутная информация. Оптимальность маршрута достижима лишь при полной информации обо всех возможных маршрутах, но такие данные потребуют слишком большого объема памяти. Полная маршрутная информация доступна для внутренних протоколов при ограниченном объеме сети. Чаще приходится иметь дело с распределенной схемой представления маршрутной информации. Маршрутизатор может быть информирован лишь о состоянии близлежащих каналов и маршрутизаторов.

В маршрутизаторе с динамическим протоколом (например, BGP-4) резидентно загруженная программа-драйвер изменяет таблицы маршрутизации на основе информации, полученной от соседних маршрутизаторов. В ЭВМ, работающей под UNIX и выполняющей функции маршрутизатора, эту задачу часто решает резидентная программа gated или routed (демоны). Последняя поддерживает только внутренние протоколы маршрутизации.

Применение динамической маршрутизации не изменяет алгоритм маршрутизации, осуществляемой на IP-уровне. Программа-драйвер при поиске маршрутизатора-адресата по-прежнему просматривает таблицы. Любой маршрутизатор может использовать два протокола маршрутизации одновременно: один — для внешних связей, другой — для внутренних. Для стыковки внешнего маршрута с внутренним в большинстве протоколов предусматриваются специальные средства.