Основная задача сетей — транспортировка информации от ЭВМ-отправителя к ЭВМ-получателю. В большинстве случаев для этого нужно совершить несколько пересылок. Проблему выбора пути решают
Маршрутизация подразумевает два параллельных процесса: подготовку маршрутной таблицы и переадресацию дейтограмм с помощью этой таблицы. Формирование маршрутной таблицы производится посредством протоколов маршрутизации или под воздействием инструкций сетевого администратора.
Алгоритм маршрутизации должен обладать вполне определенными свойствами: надежностью, корректностью, стабильностью, простотой и оптимальностью. Последнее свойство не так прозрачно, как это может показаться на первый взгляд: все зависит от того, по какому или каким параметрам производится оптимизация. Эта задача иногда совсем не тривиальна даже для сравнительно простых локальных сетей (смотри, например, рис. 8.1). Предположим, что поток данных между ЭВМ B и D, соединенных через маршрутизатор (М), весьма высок. Это окажет ощутимое влияние на скорость обмена между ЭВМ А и С. Но этот факт довольно трудно выявить, находясь в ЭВМ А или С. Внешне это проявится лишь как повышенная задержка, вероятность потери пакета и пониженная пропускная способность участка А-С.
(рис 8.1) Среди параметров оптимизации может быть минимальная задержка доставки, максимальная пропускная способность, минимальная цена, максимальная надежность, минимальная вероятность потери пакета, максимальная безопасность или минимальная вероятность ошибки.
Принцип оптимальности маршрута. Если маршрутизатор M находится на оптимальном пути от маршрутизатора I к маршрутизатору J, тогда оптимальный путь от М к J проходит по этому же пути.
Следствием принципа оптимальности является утверждение, что оптимальные маршруты от всех отправителей к общему месту назначения образуют дерево, лишенное циклов. Такое дерево (
Главным параметром при маршрутизации пакета в Интернет является IP-адрес его места назначения. Проблема оптимальной маршрутизации в современном Интернет, насчитывающем уже более пятисот миллионов узлов, весьма сложна, полная таблица маршрутов может содержать $$(5*10^8)!$$ записей (здесь "!" означает знак факториала, а не выражение эмоций), что не по плечу не только сегодняшним ЭВМ. Внешние маршрутизаторы обычно ищут оптимальный путь между сетями, а не отдельными ЭВМ. Тем не менее, размеры маршрутных таблиц растут экспоненциально, и традиционные схемы и решения рано или поздно станут неэффективны. В общем случае для формирования оптимального маршрута нужно владеть исчерпывающей информацией обо всех сетевых сегментах. Это реально только для локальных сетей малого или среднего размеров. Следует также учитывать, что ситуация в сети постоянно меняется и маршрутизаторы для решения их задач имеют ограниченные ресурсы времени. На практике оптимизация осуществляется для ограниченной области сегментов, тогда и объем данных, подлежащих обработке, сокращается на многие порядки. Понятно, что компромиссы здесь неизбежны и результирующий маршрут в этом случае отнюдь не всегда будет оптимальным. Сбор данных о сетевых сегментах и маршрутах выполняется путем обмена этой информацией между маршрутизаторами. Переадресация же дейтограммы должна осуществляться за время 1-20 миллисекунд, которое зависит от длины очереди в буфере.
Одной из радикальных мер решения проблемы может стать географическая маршрутизация, которая будет возможной при массовом внедрении адресации IPv6.
При географическом принципе каждая из стран получит равные по численности блоки IP-адресов (США и Андорра будут иметь равное число адресов). Именно по этой причине при 32-битах адреса такая схема была неосуществима.
В начале 90-х годов было принято решение ввести понятие автономной системы (AS). Автономная система – это совокупность локальных сетей, имеющая одного администратора и единую маршрутную политику. Введение AS позволило несколько сократить размер маршрутных таблиц, так как маршруты можно было прокладывать уже не между локальными сетями, а между более крупными образованьями – автономными системами. Само название таких систем подчеркивает их независимость, и только добровольное сотрудничество помогает всем участникам решать общие проблемы.
Обычный пользователь не задумывается и не должен задумываться над проблемами маршрутизации, но даже ему иногда может пригодиться понимание, что возможно, а что невозможно в Интернет.
IP делит все ЭВМ на маршрутизаторы и обычные ЭВМ, последние, как правило, не рассылают свои маршрутные таблицы. Предполагается, что маршрутизатор владеет исчерпывающей информацией о правильных маршрутах (хотя это и не совсем так). Обычная ЭВМ имеет минимальную маршрутную информацию (например, адрес маршрутизатора локальной сети и сервера имен). Автономная система (AS) может содержать множество маршрутизаторов, но взаимодействие с другими AS она осуществляет только через один маршрутизатор, называемый пограничным (
(рис 8.2) Может показаться, что проблема надумана, моя локальная сеть является внутренней, а все, что за ее пределами, – внешнее. На рисунке показаны семь маршрутизаторов (R1R7), один из них связывает эту систему с Интернет. К каждому маршрутизатору подключена одна или несколько субсетей (иначе бы маршрутизаторы были просто не нужны). Следует помнить, что вся эта система маршрутизаторов после подключения становится равноправной частью Интернет. С топологической точки зрения задача маршрутизации сводится к построению оптимального пути от ЭВМ-отправителя к ЭВМ-получателю. В этом подходе все маршрутизаторы и узлы Интернет равноправны, и деление их на внутренние и внешние условно. И тем не менее, такое деление вполне оправдано. Связано это чисто с технологическими возможностями современных маршрутизаторов (и отчасти протоколов), с ограниченностью их памяти и быстродействия. Здесь нужно заметить, что, например, не всегда прямой путь от R5 к R6 является наилучшим, он может, в частности, иметь малую пропускную способность или быть сильно перегруженным. Что считать внутренним, а что внешним, — имеет и юридический аспект. Здесь возникают проблемы, связанные с разглашением частной информации о гражданах, бывают и более тяжелые случаи.
Несколько лет назад разработчик почтовой системы PGP (Pretty Good Privacy) Фил Циммерман (США) был привлечен к суду за то, что способствовал распространению систем шифрования со слишком длинными ключами (большими, чем это разрешено экспортными ограничениями), что создавало трудности американским спецслужбам. Сидеть бы ему в тюрьме, если бы не общественное мнение и умелые адвокаты. Последние убедили суд, что Циммерман ничего не экспортировал, он лишь положил программы на общедоступный сервер, а ушлые европейцы и шустрые китайцы копировали эти программы с его сервера. Вот их и надо привлекать к суду за нарушение экспортных законов. Это оказалось не по плечу могущественной американской Фемиде — они уж точно вовне и на них распространить законы США не так просто. Пограничные проблемы приходится решать при борьбе с хакерами и другими компьютерными террористами и хулиганами. Современное законодательство в этой сфере пока несовершенно.
Если адресат достижим более чем одним путем (например, R7 может передать пакет в R2 более чем 6 путями), маршрутизатор должен сделать выбор, этот выбор осуществляется на основании оценки маршрутов-кандидатов. Обычно каждому сегменту, составляющему маршрут, присваивается некоторая величина — оценка этого сегмента. Каждый протокол маршрутизации использует свою систему оценки маршрутов. Оценка сегмента маршрута называется метрикой. Здесь следует обратить внимание на то, что при выборе маршрута всем сегментам пути должны быть даны сопоставимые значения метрики. Недопустимо, чтобы одни сегменты оценивались числом шагов, а другие — по величине задержки в миллисекундах. В пределах автономной системы это обычно не создает проблем, ведь это зона ответственности одного администратора. Но в региональных сетях, где работает много администраторов, проблема выбора метрики может стать реальной трудностью. Именно по этой причине в таких сетях в качестве метрики сегодня используется вектор расстояния (число шагов), исключающий субъективность оценок метрики.
Помимо классической схемы маршрутизации по адресу места назначения, часто используется вариант выбора маршрута отправителем (данный вариант получил дальнейшее развитие при введении стандарта IPv6). В этом случае IP-пакет содержит соответствующий код опции и список промежуточных адресов узлов, которые он должен посетить по пути к месту назначения.
Существуют и другие схемы, например, использующие широковещательные методы маршрутизации (flooding), где в процессе поиска пути каждый приходящий пакет посылается по всем имеющимся исходящим каналам, за исключением того, по которому он получен. Чтобы исключить беспредельное размножение пакетов, в заголовок вводится поле-счетчик числа шагов. В каждом узле содержимое поля уменьшается на единицу. Когда значение поля становится равным нулю, пакет ликвидируется. Исходное значение счетчика определяется размером субсети. Предпринимаются специальные меры против возможного зацикливания пакетов. Существует усовершенствованная версия широковещательной маршрутизации, называемая селективной широковещательной рассылкой. В этом алгоритме рассылка производится не по всем возможным направлениям, а только по тем, которые предположительно ведут в правильную сторону. Широковещательные методы не относятся к широко применимым. Но они используются там, где нужна предельно возможная надежность, например, в военных приложениях, когда весьма вероятно повреждение тех или иных каналов. Данные методы могут применяться лишь при формировании виртуального канала, ведь они всегда обеспечивают наикратчайший путь, так как перебираются все возможности. Если путь записывается в пакете, получатель может выбрать оптимальный проход и уведомить об этом отправителя.
Большинство алгоритмов учитывают топологию связей, а не их качество (пропускную способность, загрузку, качество и пр.). Но существуют подходы к решению проблемы статической маршрутизации, учитывающие как топологию, так и загрузку (flowbased routing). В некоторых сетях потоки между узлами относительно стабильны и предсказуемы. В этом случае появляется возможность вычислить оптимальную схему маршрутов заранее. Здесь на основе теории массового обслуживания производится оценка средней задержки доставки для каждой связи. Топология маршрутов оптимизируется по значению задержки доставки пакета. Исходными данными при расчете считаются описание топологии связей, матрица трафика для всех узлов Ti,j (в пакетах в секунду) и матрица пропускных способностей каналов Bi,j в битах в секунду. Задержка ? для каждой из связей оценивается по формуле
$$\tau_{i,j} = 1/(P*B_{i,j} - T_{i,j})$$,
где 1/Р — среднее значение ширины пакета в битах, произведение P*Bi,j выражается в пакетах в секунду, а $$\tau$$ измеряется в мсек. Сформировав матрицу $$\tau_{i,j}$$, можно получить граф кратчайших связей. Так как вычисления производятся не в реальном масштабе времени, особых трудностей здесь не возникает (если число узлов не слишком велико).
Статические протоколы предполагают, что любые изменения в маршрутные таблицы вносит администратор сети. Такая схема управления часто используется и в самых современных маршрутизаторах. Динамическая маршрутизация, обладая очевидными преимуществами, к сожалению, облегчает задачу хакеру, пытающемуся проникнуть в сеть.
Хакер может имитировать работу маршрутизатора и вынудить посылку всех пакетов через его машину, объявив, что доступ ко всем узлам Интернет ближе или лучше через его рабочую станцию (этакий волшебный гиперканал!). По этой причине, если можно обойтись без динамической маршрутизации, лучше это сделать, ведь облегчение жизни хакерам в наши задачи не входит.
Рассмотрим для примера сеть, изображенную на рис. 8.3.
(рис 8.3) Схема для иллюстрации методики составления маршрутных таблиц. G1, G2, G3 — маршрутизаторыПримитивная таблица маршрутизации для приведенного примера может иметь вид (для маршрутизатора G2):
| Сеть-адресат | Маршрут к этой сети |
|---|---|
| 193.0.0.0 | Прямая доставка |
| 193.148.0.0 | Прямая доставка |
| 192.0.0.0 | Через адрес 193.0.0.1 |
| 192.166.0.0 | Через адрес 193.148.0.7 |
Заметно сокращает размер маршрутной таблицы маршруты по умолчанию. В этой схеме сначала отыскивается маршрут в таблицах, а если он не найден, пакет посылается в узел, специально выбранный для данного случая. Так, когда имеется только один канал за рубеж, неудачный поиск в таблице маршрутов по России означает, что пакет следует послать по этому каналу и пусть там с ним разбираются. Маршруты по умолчанию используются обычно тогда, когда маршрутизатор имеет ограниченный объем памяти или по какой-то иной причине не имеет полной таблицы маршрутизации. Маршрут по умолчанию может помочь реализовать связь даже при ошибках в маршрутной таблице. Это может не иметь никаких последствий для малых сетей, но для региональных сетей с ограниченной пропускной способностью такое решение может создать серьезные проблемы. Экономия на памяти для маршрутных таблиц – дурной стиль, который не доведет до добра. Например, из-за такого рода ошибки довольно долго пакеты из Ярославля в Москву шли через США; я уже не говорю о случае, когда машины, размещенные в соседних комнатах Президиума РАН, вели обмен между собой через Амстердам (правда, это было достаточно давно). Алгоритм выбора маршрута универсален и не зависит от протокола маршрутизации, который применяется лишь для формирования маршрутной таблицы. Общий алгоритм выбора оптимального маршрута на основе метрик сегментов пути сформулировал американский математик Дикстра в 1959 году.
Описание алгоритма переадресации конкретного пакета с помощью маршрутной таблицы представлено ниже.
Извлечь IP-адрес (ID) места назначения из дейтограммы.
Вычислить IP-адрес сети назначения ( IN )
if IN соответствует какому-либо адресу локальной сети, послать дейтограмму по этому адресу;
else if IN присутствует в маршрутной таблице, то послать дейтограмму к серверу, указанному в таблице;
else if описан маршрут по умолчанию, то послать дейтограмму к этому серверу;
else выдать сообщение об ошибке маршрутизации (недоступность адресата).
Если сеть включает в себя субсети, то для каждой записи в маршрутной таблице производится <И> для ID и маски субсети. Если результат этой операции совпадет с содержимым адресного поля сети, дейтограмма посылается шлюзу субсети. На практике при наличии субсетей в маршрутную таблицу добавляются соответствующие записи с масками и адресами сетей. Машины одной и той же субсети не должны подключаться к разным интерфейсам маршрутизатора. При маршрутизации используется только сетевая часть IP-адреса.
Одна из базовых идей маршрутизации заключается в том, чтобы сконцентрировать маршрутную информацию в ограниченном числе (в идеале — в одном) узловых маршрутизаторов-диспетчеров. Эта замечательная идея ведет к заметному увеличению числа шагов при пересылке пакетов. Оптимизировать решение позволяет
"Прозрачные"
(рис 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. Маршрутизация через опорные сети (
(рис 8.5) Протоколы маршрутизации отличаются друг от друга тем, где хранится, и как формируется маршрутная информация. Оптимальность маршрута достижима лишь при полной информации обо всех возможных маршрутах, но такие данные потребуют слишком большого объема памяти. Полная маршрутная информация доступна для внутренних протоколов при ограниченном объеме сети. Чаще приходится иметь дело с распределенной схемой представления маршрутной информации. Маршрутизатор может быть информирован лишь о состоянии близлежащих каналов и маршрутизаторов.
В маршрутизаторе с динамическим протоколом (например, BGP-4) резидентно загруженная программа-драйвер изменяет таблицы маршрутизации на основе информации, полученной от соседних маршрутизаторов. В ЭВМ, работающей под UNIX и выполняющей функции маршрутизатора, эту задачу часто решает резидентная программа gated или routed (демоны). Последняя поддерживает только внутренние протоколы маршрутизации.
Применение динамической маршрутизации не изменяет алгоритм маршрутизации, осуществляемой на IP-уровне. Программа-драйвер при поиске маршрутизатора-адресата по-прежнему просматривает таблицы. Любой маршрутизатор может использовать два протокола маршрутизации одновременно: один — для внешних связей, другой — для внутренних. Для стыковки внешнего маршрута с внутренним в большинстве протоколов предусматриваются специальные средства.
Может возникнуть вопрос: откуда возникло ограничение на число внешних и внутренних протоколов маршрутизации? Главная причина – согласование метрик сетевых каналов. С внешними протоколами все относительно просто. Во-первых, их мало, во-вторых, практически все они используют для оценки каналов вектор расстояния, что потенциально может вообще снять рассматриваемое ограничение. А как быть с внутренней маршрутизацией? Ведь существуют протоколы, базирующиеся на векторе расстояния (RIP) и на состоянии канала (OSPF или IGRP). Предположим, что в одной зоне сети работает RIP, где канал оценивается числом шагов до цели, а в другой — OSPF с оценкой состояния канала, выполненной администратором сети. Если маршрут содержит фрагменты пути, пролегающие через обе указанные зоны, возникает проблема оценки такого пути. Как сложить метрики этих участков, ведь они несовместимы? В принципе, задача имеет решение: для этого на границах зон с разными протоколами маршрутизации размещаются специальные маршрутизаторы, которые оптимизируют пути для каждого из протоколов (и зон) независимо. Но и в этом случае возможны трудноразрешимые ситуации. Один из таких вариантов показан на рис. 8.6.
(рис 8.6) Пусть на рисунке 8.6 в сетевых зонах, обозначенных кругами, используется протокол RIP, а в остальном пространстве – OSPF. ЭВМ обозначены пятиугольниками, внутренние маршрутизаторы — прямоугольниками, а окрашенные прямоугольники отмечают пограничные маршрутизаторы зон. Любые маршруты из зоны А в зону Б проблем не вызовут, так как внутри зоны маршруты оптимизируются RIP, а между зонами – протоколом OSPF. Возьмем задачу прокладки маршрута из зоны Б в зону В. Здесь следует рассмотреть варианты пути через зоны Г и Д. Важно то, что при выборе оптимального пути придется как-то учитывать метрики как OSPF-части пути, так и фрагменты транзитного пути внутри зон. При этом надо принять решение, с какими весами складывать метрики разных протоколов. Эта проблема снимается, если каждая зона имеет только один пограничный маршрутизатор. Маршрут прокладывается между пограничными маршрутизаторами, а различие маршрутов внутри зон игнорируется. Кстати именно эта логика лежит в основе рекомендации для автономной системы иметь только один пограничный маршрутизатор. Поясню это на примере, показанном на рис. 8.7.
(рис 8.7) Рассмотрим процедуру выбора пути от ЭВМ-1 к ЭВМ-2 из автономной системы AS1 в автономную систему AS2. Имеются метрики, характеризующие путь до маршрутизаторов GW1 и GW2 (M1 и M2).
Если бы у AS1 был только один пограничный шлюз (например, GW1), то задача решалась бы автоматически. Другим подходом может быть деление всего Интернет на две части, одна делается доступной только через GW1, а вторая – через GW2.
Любая автономная система (AS, система маршрутизаторов, ЭВМ или сетей, имеющая единую политику маршрутизации) может выбрать свой собственный протокол маршрутизации.
Деликатной процедурой
Другой проблемой является ситуация, при которой маршрутизатор оказался временно отключен от сети переменного тока и был перезагружен. В этом случае он не будет знать, какой номер кадра следует ожидать. Кроме того, вполне реалистично предположить, что за 136 лет счетчик пакетов в маршрутизаторе может сбиться. Последствия могут оказаться плачевными.
Для решения всех этих проблем можно ввести, помимо номера, еще и возраст пакета и уменьшать его на единицу раз в секунду. Когда возраст станет равным нулю, маршрутная информация из маршрутизатора удаляется и процедура начинается с нуля.
Другим решением может быть схема, при которой входной пакет, предназначенный для рассылки, посылается соседям не сразу, а выдерживается некоторое время в буфере. Если за время выдержки придет очередной пакет, то их порядковые номера сравниваются. Если они равны, то дубликат отбрасывается. При разных номерах отбрасывается более старый. Для обеспечения надежности получение кадра с маршрутной информацией обязательно подтверждается.
Следует учитывать, что каждому сегменту пути может быть присвоено два значения метрики, по одному для каждого из направлений обмена.
Внутренний протокол маршрутизации
Алгоритм вектора расстояния неявно предполагает, что все каналы имеют равную пропускную способность.
Существует более новый протокол OSPF (Open Shortest Pass First, RFC-1131, -1245, -1247, -1253, -1584, -1850, -2328, -2740), базирующийся на оценках состояний каналов. Как во всех маршрутных протоколах, использующих состояние канала, многое зависит от того, как вычисляется метрика. Если определяющим фактором выбрать полосу пропускания канала, то при определенных обстоятельствах могут возникнуть трудно преодолимые проблемы. Рассмотрим топологию сети, показанную на рис. 8.8.
(рис 8.8) Пример топологии сети, допускающей осцилляцию маршрутовЗдесь две субсети А и Б соединены двумя каналами 1 и 2. Кружочками обозначены маршрутизаторы. Если в исходный момент основной поток между сетями протекает по каналу 2, он может оказаться перегружен, в то время как канал 1 получит меньшее значение метрики из-за отсутствия загрузки. При очередной оценке каналов будет принято решение переключить поток между сетями на канал 1. После этого будет перегружен канал 1, и так может повторяться до бесконечности. Подобная ситуация называется осцилляцией маршрутов, и ее желательно избегать. Маршрутные таблицы в маршрутизаторах актуализуются вдоль пути с заметными задержками и отнюдь не синхронно. Такие осцилляции могут в несколько раз понизить пропускную способность сети, что необходимо учитывать, выбирая параметры протоколов маршрутизации.
На практике этого не происходит, так как метрики сегментам пути в OSPF присваивает сетевой администратор. Но можно ожидать, что появятся как внутренние, так и внешние протоколы маршрутизации на основе алгоритма состояния канала, которые будут исследовать параметры канала в реальном масштабе времени.
Для взаимодействия маршрутизаторов друг с другом используются внешние протоколы (
IGRP применяет несколько типов метрики, по одной на каждый вид QOS (качества обслуживания). Метрика характеризуется 32-разрядным числом. В однородных средах этот вид метрики вырождается в число шагов до цели. При использовании путей со смешанной технологией передачи информации (ATM, Ethernet, последовательные каналы PPP и пр.) маршрут с минимальным значением метрики является предпочтительным. Актуализация маршрутной информации для этого протокола производится каждые 90 секунд. Если какой-либо маршрут не подтверждает своей работоспособности в течение 270 сек, он считается недоступным. После семи циклов (630 сек) актуализации такой маршрут удаляется из маршрутных таблиц. Протокол IGRP, вообще говоря, допускает автоматическое вычисление метрики. Полученное значение может быть умножено на величину параметра вариация. Этот параметр задает всегда сам администратор. С его помощью можно выровнять значения метрик нескольких каналов, что позволит пустить через них параллельный трафик. Пользоваться параметром вариация следует осторожно, так как при некоторых его значениях можно разрешить пакетам идти вспять, что приведет к циклическому движению пакетов и заблокирует работу сети.
Протокол IDPR (InterDomain Policy
Сразу после включения маршрутизатор не имеет информации о возможностях соседних маршрутизаторов. Статические маршрутные таблицы могут храниться в постоянной памяти или загружаться из какого-то сетевого сервера. По этой причине первейшей задачей маршрутизатора является получение маршрутной информации от соседей, а для начала — выявление наличия соседей и их адресов. Для этой цели посылается специальный пакет Hello через каждый из своих внешних интерфейсов. В ответ предполагается получить отклик, содержащий идентификационную информацию соответствующего маршрутизатора.
К сожалению, многие современные протоколы маршрутизации не имеют встроенных средств аутентификации (контроля доступа), что делает их уязвимыми для различных злоупотреблений.
В локальных или корпоративных сетях иной раз возникает необходимость разослать некоторую информацию всем остальным ЭВМ-пользователям сети (штормовое предупреждение, изменение курса акций, телеконференции с большим числом участников и т.д.). Отправителю достаточно знать адреса всех N заинтересованных пользователей и послать им соответствующее сообщение. Данная схема крайне не эффективна, ведь обычная широковещательная адресация предлагает решение, в N раз лучшее с точки зрения загрузки сети (посылается одно, а не N сообщений). Широковещательная адресация сработает, если в локальной сети нет маршрутизаторов; в противном случае широковещательные адреса МАС-типа заменяются на IP-адреса (что, впрочем, не слишком изящное решение) или применяется мультикастинг-адресация. Для мультикастинг-адресации в Интернет используются специальные адреса D-класса. Такие адреса позволяют организовать до 250 миллионов групп адресатов, функционирующих одновременно. При посылке пакета по такому адресу доставка не гарантируется, и некоторые члены группы могут не получить этот пакет. Маршрутизация для мультикастинга представляет собой отдельную задачу, ведь здесь надо проложить маршрут от отправителя к большому числу получателей. Традиционные методы маршрутизации здесь применимы, но до крайности не эффективны. Для целей выбора маршрута можно с успехом применить алгоритм "дерево связей" (
(рис 8.9) Алгоритм Reverse Path ForwardingПри передаче мультимедиа-информации используются принципиально другие протоколы маршрутизации. Здесь путь прокладывается от получателя к отправителю, а не наоборот, поскольку там при доставке применяется мультикастинговый метод. Здесь, как правило, один отправитель посылает пакеты многим потребителям. При этом важно, чтобы размножение пакета происходило как можно ближе к кластеру адресатов. Такая стратегия иной раз удлиняет маршрут, но всегда снижает результирующую загрузку сети.
Если сеть однородна, то есть все каналы имеют равную пропускную способность и примерно равную загрузку, что типично для небольших локальных сетей, то число шагов до цели является разумной оценкой пути (метрикой).
Описания этих маршрутов хранится в специальной таблице, называемой маршрутной. Таблица маршрутизации RIP содержит по одной записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:
IP-адрес места назначения;
метрику маршрута (от 1 до 15; число шагов до места назначения);
IP-адрес ближайшего маршрутизатора (Gateway) по пути к месту назначения;
таймеры маршрута.
Первым двум полям записи мы обязаны появлению термина вектор расстояния (место назначения – направление; метрика – модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте либо произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать следующие три типа ошибок.
<16 ).Несоответствие маршрутной таблицы реальной ситуации типично не только для RIP, но характерно для всех протоколов, базирующихся на векторе расстояния, где информационные сообщения актуализации несут в себе только пары кодов: адрес места назначение и расстояние до него. Пояснение проблемы дано на рис. 8.10 ниже.
(рис 8.10) Иллюстрация, поясняющая возникновение циклических маршрутов при использовании вектора расстоянияВ верхней части рисунка показана ситуация, когда маршрутизаторы указывают маршрут до сети <A> в соответствии со стрелками. В нижней части связь на участке GW1 <Сеть A> оборвана, а GW2 по-прежнему продолжает оповещать о ее доступности с числом шагов, равным 2. При этом GW1, восприняв эту информацию (если GW2 успел передать свою маршрутную информацию раньше GW1), может перенаправить пакеты, адресованные сети А, на GW2, а в своей маршрутной таблице будет характеризовать путь до сети А метрикой 3. Таким образом формируется замкнутая петля маршрутов. Последующая широковещательная передача маршрутных данных GW1 и GW2 не решит эту проблему быстро. Так, после очередного обмена путь от GW2 до сети А будет характеризоваться метрикой 5. Этот процесс будет продолжаться до тех пор, пока метрика не станет равной 16, что займет слишком много циклов обмена маршрутной информацией.
Заметим, что на время распространения информации о недоступности сети А станет недоступна сеть С — из-за циклического обмена пакетами между маршрутизаторами GW1 и GW2 (см. рис 8.10).
Проблема может быть решена следующим образом. Маршрутизатор запоминает, через какой интерфейс получена маршрутная информация, и через этот интерфейс эту информацию уже не передает. В рассмотренном выше примере GW2 не станет посылать информацию о пути к сети А маршрутизатору GW1, от которого он получил эти данные. В этом случае в маршрутной таблице GW1 путь до А исчезнет сразу. Остальные маршрутизаторы узнают о недостижимости сети А через несколько циклов. Существуют и другие пути преодоления медленных переходных процессов. Если производится оповещение о коротком пути, все узлы-получатели воспринимают эти данные немедленно. Если же маршрутизатор закрывает какой-то путь, его отмена фиксируется остальными лишь по тайм-ауту. Универсальным методом исключения ошибок при маршрутизации является использование достаточно большой выдержки перед тем как использовать информацию об изменении маршрутов. В этом случае к моменту изменения маршрута эта информация станет доступной всем участникам процесса маршрутизации. Однако все перечисленные методы и некоторые другие известные алгоритмы, решая одну проблему, часто вносят другие. Многие из этих методов могут при определенных условиях вызвать лавину широковещательных сообщений, что также дезорганизует сеть.
Но даже усовершенствование, изложенное выше, не всегда срабатывает. На рис. 8.11 приведен пример, когда переходной процесс, несмотря на усовершенствование, будет идти долго. При обрыве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает узлам А и Б. К сожалению, А знает, что Б имеет проход к Г длиной 2, из чего он делает вывод о достижимости Г за три шага. Аналогично рассуждает Б о возможности достижимости Г через А. Далее при последующих рассылках метрика доступности Г характеризуется все большими значениями, до тех пор пока не станет равной "бесконечности" (16).
(рис 8.11) Пример топологии, где переходной процесс осуществляется медленно, даже при усовершенствовании алгоритма В RIP сообщения инкапсулируются в UDP-дейтограммы, при этом передача осуществляется через порт 520. Если между отправителем и приемником расположено три маршрутизатора, считается, что между ними 4 шага. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, например, два шага по сегментам сети Ethernet обеспечат большую пропускную способность, чем один шаг через последовательный канал на основе интерфейса RS-232.
Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для других протоколов маршрутизации). Каждому маршруту ставится в соответствие таймер тайм-аута и "сборщика мусора". Тайм-аут-таймер сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время "уборки мусора" (2мин). При появлении эквивалентного маршрута переключения на него не происходит, таким образом блокируется возможность осцилляции между двумя или более равноценными маршрутами.
Каждые 30 секунд таблица маршрутизации или ее часть посылается всем соседним маршрутизаторам. Могут посылаться и специальные запросы при локальном изменении таблицы. RIP достаточно простой протокол, но, к сожалению, не лишенный недостатков:
a. RIP не работает с адресами субсетей. Если нормальный 16-бит идентификатор ЭВМ класса B не равен 0, RIP не может определить является ли ненулевая часть cубсетевым ID или полным IP-адресом;
b. RIP требует много времени для восстановления связи после сбоя в маршрутизаторе (минуты). В процессе установления режима возможны циклы;
c. число шагов — важный, но не единственный параметр маршрута, да и 15 шагов не предел для современных сетей.
Протокол RIP-2 (RFC-1388, 1993 год и более поздние публикации, смотри начало главы) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг, позволяет работать с масками субсетей, предоставляет некоторые возможности обеспечения безопасности.
Если субсеть содержит N маршрутизаторов, каждый из которых имеет M соседей, то требуемая емкость памяти будет пропорциональна N*M. Для больших субсетей это может оказаться проблемой, да и скорость расчетов при этом окажется невысока. Несмотря на это, в большинстве случаев протокол работает вполне удовлетворительно. Но при тысячах и тем более десятках тысяч узлов этими проблемами нельзя пренебречь. В таких случаях следует подумать о разбивке сети на зоны и построении иерархической схемы маршрутизации. Причем чем больше сеть, тем больше уровней иерархии следует предусмотреть. Протокол OSPF может использоваться в корпоративных сетях, где сетевые объекты разбросаны на большой площади. Например, OSPF был реализован в региональной сети Центробанка РФ Вологодской области.
Автономная система может быть поделена на несколько областей, куда могут входить как отдельные ЭВМ, так и целые сети. В этом случае внутренние маршрутизаторы области могут и не иметь информации о топологии остальной части AS. Сеть обычно имеет выделенный маршрутизатор, который является источником маршрутной информации для остальных маршрутизаторов AS. Каждый маршрутизатор самостоятельно решает задачу оптимизации маршрутов. Если к месту назначения ведут два или более эквивалентных маршрута, информационный поток будет поделен между ними поровну. Можно подумать, что совпадение метрик для каналов возможно лишь случайно. Так бы и было, если бы метрики вычислялись автоматически на основе измерения состояния каналов, но на практике это делает администратор сети. Переходные процессы в OSPF завершаются быстрее, чем в RIP. В процессе выбора оптимального маршрута анализируется ориентированный граф сети. Понятно, что для решения этой задачи нужно иметь всю необходимую информацию обо всех узлах и каналах данной области сети. Ниже описан алгоритм Дикстры по выбору оптимального пути. Целью алгоритма является преобразование многосвязного графа в дерево с оптимальной топологией. На иллюстративном рис. 8.12 приведена схема узлов (A-J) со значениями метрики для каждого из отрезков пути. Анализ графа начинается с узла A (Старт). Пути с наименьшим суммарным значением метрики считаются наилучшими. Именно они становятся выбранными в результате рассмотрения графа ("кратчайшие пути").
(рис 8.12) Иллюстрация работы алгоритма ДикстрыНиже дается формальное описание алгоритма. Сначала вводим некоторые определения.
Пусть D(v) равно сумме весов связей для данного пути.
Пусть C(i,j) равно весу связи между узлами с номерами i и j.
Далее следует последовательность шагов, реализующих алгоритм.
N = {1}.N устанавливаем D(v)= c(1,v).w не из множества N, для которого D(w) минимально, и добавляем узел w в множество N.D(v) для всех узлов не из множества ND(v)=min{D(v), D(v)+c(w,v)}.
N.Топология маршрутов для узла A приведена на нижней части рис. 8.12. В скобках записаны числа, характеризующие метрику отобранного маршрута согласно критерию пункта 3.
| Шаг | Множество | Метрика связи узла A с узлами | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| N | B | C | D | E | F | G | H | I | J | |
| 0 | {A} | 3 | - | 9 | - | - | - | - | - | - |
| 1 | {A,B} | (3) | 4 | 9 | 7 | - | 10 | - | - | - |
| 2 | {A,B,C} | 3 | (4) | 6 | 6 | 10 | 10 | 8 | - | 14 |
| 3 | {A,BC,D} | 3 | 4 | (6) | 6 | 10 | 10 | 8 | 9 | 14 |
| 4 | {A,B,C,D,E} | 3 | 4 | 6 | (6) | 10 | 10 | 8 | 9 | 14 |
| 5 | {A,B,C,D,E,H} | 3 | 4 | 6 | 6 | 10 | 10 | (8) | 9 | 14 |
| 6 | {A,B,C,D,E,H,I} | 3 | 4 | 6 | 6 | 10 | 10 | 8 | (9) | 14 |
| 7 | {A,B,C,D,E,H,I,F} | 3 | 4 | 6 | 6 | (10) | 10 | 8 | 9 | 14 |
| 8 | {A,B,C,D,E,H,I,F,G} | 3 | 4 | 6 | 6 | 10 | (10) | 8 | 9 | 14 |
| 9 | {A,B,C,D,E,H,I,F,G,J} | 3 | 4 | 6 | 6 | 10 | 10 | 8 | 9 | (14) |
Таблица 8.1 может иметь совершенно иное содержимое для какого-то другого вида сервиса, выбранные пути при этом могут иметь другую топологию. Качество сервиса (QOS) может характеризоваться следующими параметрами:
Определяющими являются три характеристики: задержка, пропускная способность и надежность. Для транспортных целей OSPF использует IP непосредственно, т.е. не привлекает протоколы UDP или TCP. OSPF имеет свой код (89) в протокольном поле IP-заголовка. Код TOS (Type Of Service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение TOS здесь задается в самих пакетах OSPF. Маршрутизация в этом протоколе определяется IP-адресом и типом сервиса. Так как протокол не требует
(рис 8.13) Пример выделения областей при OSPF маршрутизации в автономной системе (М – маршрутизаторы; C – сети)На рис 8.13 (см. также рис 8.12) приведен пример выделения областей маршрутизации при OSPF-маршрутизации в пределах автономной системы. На рис 8.13 маршрутизаторы М4 и М2 выполняют функцию опорной сети для других областей. В выделенных областях может быть любое число маршрутизаторов. Утолщенными линиями выделены связи с другими автономными системами.
При передаче OSPF-пакетов фрагментация нежелательна, но не запрещается. Для передачи статусной информации OSPF использует широковещательные сообщения HELLO. Для повышения безопасности предусмотрена авторизация процедур. OSPF-протокол требует резервирования двух мультикастинг-адресов:
224.0.0.5 предназначен для обращения ко всем маршрутизаторам, поддерживающим этот протокол
224.0.0.6 служит для обращения к специально выделенному маршрутизатору
Заметим, что для обращения ко всем системам локальной сети используется мультикастинг-адрес 224.0.0.1, а для обращения ко всем маршрутизаторам локальной сети – адрес 224.0.0.2. В исходный момент (сразу после загрузки) маршрутизатор должен выявить наличие маршрутизаторов соседей, для чего он посылает запросы HELLO через все свои
Если адрес пересылки равен 0.0.0.0, данные посылаются пограничному маршрутизатору автономной системы — источнику данного сообщения. Метка внешнего маршрута — 32-битовое число, присваиваемое каждому внешнему маршруту. Эта метка самим протоколом OSPF не используется и предназначена для информирования других автономных систем при работе внешних протоколов маршрутизации. Маршрутная таблица OSPF содержит в себе:
Число маршрутных таблиц может быть равно числу значений качества обслуживания.
Здесь уместно заметить, что Интернет – это клуб джентльменов. Очень многие узлы пропускают через себя значительный транзитный трафик, который ограничивает возможности непосредственных клиентов узла. Как правило, этот трафик никак не оплачивается. Администраторы могут в рамках протокола BGP существенно ограничить или даже исключить такой транзитный трафик, но они обычно этого не делают, понимая, что их клиенты создают такой же транзитный трафик для других узлов. Эгоистичное поведение администраторов развалило бы сеть Интернет на ряд враждующих феодальных крепостей.
После того, как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано, — это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения.
После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее значение из полученного в сообщении OPEN и определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGPidentifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то, согласно правилам, должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.
Сообщения типа UPDATE (изменения) используются для передачи маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет сообщить об одном новом маршруте или объявить о закрытии группы маршрутов, причем объявление об открытии нового и закрытии старых маршрутов возможно в пределах одного сообщения.
Если длина списка отмененных маршрутов равна нулю, ни один маршрут не отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные маршруты имеет переменную длину и содержит список IP-адресных префиксов маршрутов, которые стали недоступны.
Атрибуты пути бывают "стандартными обязательными" (wellknown mandatory), стандартными на усмотрение оператора, опционными переходными и опционными непереходными. Стандартные атрибуты должны распознаваться любыми BGP-приложениями. Опционные атрибуты могут не распознаваться некоторыми приложениями. Обработка нераспознанных атрибутов задается битом 1 поля флагов. Пути с нераспознанными переходными опционными атрибутами должны восприниматься как рабочие. Один и тот же атрибут может появляться в списке атрибутов пути только один раз. Предусмотрены следующие разновидности кодов типа атрибута.
ORIGIN (код типа = 1) — стандартный обязательный атрибут, который определяет происхождение маршрутной информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения (таблица 8.2):
| код атрибута | описание |
|---|---|
| 0 | |
| 1 | |
| 2 |
AS_PATH (код типа = 2) также является стандартным обязательным атрибутом, который составлен из совокупности сегментов пути. Атрибут определяет автономные системы, через которые доставлена маршрутная информация. Когда BGP-маршрутизатор передает описание маршрута, которое он получил от своего BGP-партнера, он модифицирует AS_PATH -атрибут, соответствующий этому маршруту, если информация передается за пределы автономной системы. Каждый сегмент AS_PATH состоит из трех частей <тип сегмента пути, длина сегмента пути и оценка сегмента пути>. Тип сегмента пути представляет собой, в свою очередь, однооктетное поле, которое может принимать следующие значения (таблица 8.3):
| код типа сегмента | описание |
|---|---|
| 1 | AS_SET: неупорядоченный набор маршрутов в UPDATE-сообщении |
| 2 | AS_SEQUENCE: упорядоченный набор маршрутов автономной системы в UPDATE-сообщении. |
Длина сегмента пути представляет собой однооктетное поле, которое содержит число AS, записанных в поле оценка сегмента пути. Последнее поле хранит один или более кодов автономной системы, по два октета каждый.
NEXT_HOP (код типа = 3) — стандартный обязательный атрибут, определяющий IP-адрес пограничного маршрутизатора, который должен рассматриваться как следующий шаг на пути к точке назначения.
MULI_EXIT_DISC (код типа = 4) представляет собой опционный непереходной атрибут, который занимает 4 октета и является положительным целым числом. Величина этого атрибута может применяться при выборе одного из нескольких путей к соседней автономной системе.
LOCAL_PREF (код типа = 5) является опционным атрибутом, занимающим 4 октета. Он используется BGP-маршрутизатором, чтобы сообщить своим BGP-партнерам в своей собственной автономной системе степень предпочтения объявленного маршрута.
ATOMIC_AGGREGATE (код типа = 6) представляет собой стандартный атрибут, который применяется для информирования партнеров о выборе маршрута, обеспечивающего доступ к более широкому списку адресов.
AGGREGATOR (код типа = 7 ) — опционный переходной атрибут с длиной в 6 октетов. Атрибут содержит последний код автономной системы, который определяет агрегатный маршрут (занимает два октета), и IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4 октета).
Информация о работоспособности соседних маршрутизаторов получается из KEEPALIVE-сообщений, которые должны посылаться настолько часто, чтобы уложиться во время, отведенное таймером сохранения (HOLD). Обычно это время не должно превышать одной трети от времени сохранения, но не должно быть и меньше 1 секунды. Если выбранное значение времени сохранения равно нулю, периодическая посылка KEEPALIVE-сообщений не обязательна.
NOTIFICATION-сообщения посылаются, когда обнаружена ошибка. BGP-связь при этом немедленно прерывается.
Вся маршрутная информация хранится в специальной базе данных RIB (Routing Information Base). Маршрутная база данных BGP состоит из трех частей:
AdjRIBsIn: Запоминает маршрутную информацию, которая получена из UPDATE-сообщений. Это список маршрутов, из которого можно выбирать (Policy Information Base — PIB)LocRIB: Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из Adj-RIBs-InAdjRIBsOut: Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщенийТак как разные BGP-партнеры могут иметь разную политику маршрутизации, возможны осцилляции маршрутов. Для исключения этого необходимо выполнять следующее правило: если используемый маршрут объявлен не рабочим (в процессе корректировки получено сообщение с соответствующим атрибутом), до переключения на новый маршрут необходимо ретранслировать сообщение о недоступности старого всем соседним узлам.
Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS. Политика отражается в конфигурационных файлах BGP. Маршрутная политика — это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями; политика отражает соображения безопасности, экономические интересы и пр.. Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов. BGP использует три таймера:
ConnectRetry (сбрасывается при инициализации и коррекции; 120 сек),
Holdtime (запускается при получении команд Update или KeepAlive; 90сек) и
KeepAlive (запускается при посылке сообщения KeepAlive; 30сек).
BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, применяющие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации.
В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая BGP, не обязательно является маршрутизатором. Сообщения обрабатываются только после того, как они полностью получены.
BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30 сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не то же самое, что функция keepalive в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Эта ситуация называется столкновением, одна из связей должна быть ликвидирована. При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4); если один из них не поддерживает эту версию, номер версии понижается.
BGP-4 позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Для того, чтобы приспособиться к этому, изменены семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICS переименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы.
AS.Loc_RIB всем соседним AS согласно политике, заложенной в RIB. Группировка маршрутов и редактирование маршрутной информации.Основу протокола
Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети. Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 — 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 — 192.1.255.255, таким образом, число, следующее после косой черты, задает число двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов.
Обычно предполагается, что при посылке пакета из точки <А> в точку <B> маршруты в одном и другом направлении совпадают. Но это не всегда так. Пример, когда маршруты пакетов туда и обратно не совпадают, представлен на рис. 8.14. В предложенной схеме имеется "ЭВМ-Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора GW-2 и GW-1.
(рис 8.14) Пример разных маршрутов для пути туда и обратноПредполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:
1 GW1 (192.148.166.35) 2 Место назначения (192.148.166.33)
Команда же traceroute 192.148.165.80 распечатает:
1 GW1 (192.148.166.35) 2 GW2 (192.148.166.7) 3 Место назначения (192.148.165.80)
Команда traceroute -g 192.148.165.80 сообщит вам:
1 GW1 (192.148.166.35) 2 ***** ; В этом режиме маршрутизатор не откликается 3 Место назначения (192.148.165.80) 4 GW1 (192.148.166.35) 5 ЭВМ-отправитель (192.148.166.32)
Из приведенных примеров видна полезность команды traceroute для понимания того, как движутся пакеты в сети. В некоторых случаях это может помочь оптимизировать маршрутизацию и улучшить пропускную способность сети.
Следует учесть, что внешняя маршрутизация представляет собой систему с задержанной обратной связью и как таковая склонна к осцилляциям маршрутов.
В BGP в качестве метрики используется число шагов до цели, время распространения маршрутной информации здесь велико, у разных маршрутизаторов может быть прописана разная маршрутная политика. Допустим, какой-то маршрутизатор на основании анализа ситуации принял решение об изменении маршрута с варианта 1 на вариант 2 и сразу реализовал это решение. Эти данные дойдут до соседей спустя несколько минут. Они на основе новых данных могут также принять определенные решения, уведомив об этом своих соседей. Может так получиться, что, после того как наш маршрутизатор получит данные от своих соседей, метрика для варианта маршрута 1 окажется меньше метрики маршрута 2 и придется вернуться к пути, от которого он только что отказался. Чтобы такого не происходило, нужно сначала уведомлять соседние маршрутизаторы о принятом решении, но на новый маршрут не переключаться, пока от соседей не придут данные об их намерениях. (Для этого нужно задать соответствующие таймерные переменные). Возможно, что переключение на новый маршрут придется отменить, так как это ведет к осцилляции маршрута. Кто-то может сказать, что ему все равно, по какому маршруту доставляется пакет (по пути 1 или 2), и пусть себе маршруты осциллируют. Эта точка зрения ошибочна, так как при осцилляции маршрутов их установление происходит в маршрутизаторах не одновременно и заметное число пакетов не будет доставлено адресату вообще.
Важным свойством протокола является возможность декларации резервного (backup) маршрута. Если основной маршрут автономной системы стал недоступен, маршрутизатор переключит поток на этот резервный канал. При этом пользователи сети не должны ожидать момента, когда администратор сети вернется из отпуска, проснется или придет из кафетерия и сам внесет необходимые коррективы.
Конфигурирование BGP требует хорошего понимания его работы. Для облегчения спецификации маршрутной политики на различных уровнях иерархии, например, на уровне автономных систем (AS) был разработан язык описания маршрутной политики RPSL (Routing Policy Specification Language). Теперь низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL (см. http://book.itep.ru/4/4/rpsl.htm) является расширяемым и не препятствует внедрению новых протоколов маршрутизации.
Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 или RFC-1786 RIPE-81 был первым языком, примененным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.
Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован таким образом, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num ) в сочетании с описанием маршрутизатора (класс inet-rtr ), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set ), и информацией об автономных системах отправителях и о route и routeset ).
Язык RPSL является объектно-ориентированным, — то есть, его объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями.
Основная задача сетей — транспортировка информации от ЭВМ-отправителя к ЭВМ-получателю. В большинстве случаев для этого нужно совершить несколько пересылок. Проблему выбора пути решают
Маршрутизация подразумевает два параллельных процесса: подготовку маршрутной таблицы и переадресацию дейтограмм с помощью этой таблицы. Формирование маршрутной таблицы производится посредством протоколов маршрутизации или под воздействием инструкций сетевого администратора.
Алгоритм маршрутизации должен обладать вполне определенными свойствами: надежностью, корректностью, стабильностью, простотой и оптимальностью. Последнее свойство не так прозрачно, как это может показаться на первый взгляд: все зависит от того, по какому или каким параметрам производится оптимизация. Эта задача иногда совсем не тривиальна даже для сравнительно простых локальных сетей (смотри, например, рис. 8.1). Предположим, что поток данных между ЭВМ B и D, соединенных через маршрутизатор (М), весьма высок. Это окажет ощутимое влияние на скорость обмена между ЭВМ А и С. Но этот факт довольно трудно выявить, находясь в ЭВМ А или С. Внешне это проявится лишь как повышенная задержка, вероятность потери пакета и пониженная пропускная способность участка А-С.
(рис 8.1) Среди параметров оптимизации может быть минимальная задержка доставки, максимальная пропускная способность, минимальная цена, максимальная надежность, минимальная вероятность потери пакета, максимальная безопасность или минимальная вероятность ошибки.
Принцип оптимальности маршрута. Если маршрутизатор M находится на оптимальном пути от маршрутизатора I к маршрутизатору J, тогда оптимальный путь от М к J проходит по этому же пути.
Следствием принципа оптимальности является утверждение, что оптимальные маршруты от всех отправителей к общему месту назначения образуют дерево, лишенное циклов. Такое дерево (
Главным параметром при маршрутизации пакета в Интернет является IP-адрес его места назначения. Проблема оптимальной маршрутизации в современном Интернет, насчитывающем уже более пятисот миллионов узлов, весьма сложна, полная таблица маршрутов может содержать $$(5*10^8)!$$ записей (здесь "!" означает знак факториала, а не выражение эмоций), что не по плечу не только сегодняшним ЭВМ. Внешние маршрутизаторы обычно ищут оптимальный путь между сетями, а не отдельными ЭВМ. Тем не менее, размеры маршрутных таблиц растут экспоненциально, и традиционные схемы и решения рано или поздно станут неэффективны. В общем случае для формирования оптимального маршрута нужно владеть исчерпывающей информацией обо всех сетевых сегментах. Это реально только для локальных сетей малого или среднего размеров. Следует также учитывать, что ситуация в сети постоянно меняется и маршрутизаторы для решения их задач имеют ограниченные ресурсы времени. На практике оптимизация осуществляется для ограниченной области сегментов, тогда и объем данных, подлежащих обработке, сокращается на многие порядки. Понятно, что компромиссы здесь неизбежны и результирующий маршрут в этом случае отнюдь не всегда будет оптимальным. Сбор данных о сетевых сегментах и маршрутах выполняется путем обмена этой информацией между маршрутизаторами. Переадресация же дейтограммы должна осуществляться за время 1-20 миллисекунд, которое зависит от длины очереди в буфере.
Одной из радикальных мер решения проблемы может стать географическая маршрутизация, которая будет возможной при массовом внедрении адресации IPv6.
При географическом принципе каждая из стран получит равные по численности блоки IP-адресов (США и Андорра будут иметь равное число адресов). Именно по этой причине при 32-битах адреса такая схема была неосуществима.
В начале 90-х годов было принято решение ввести понятие автономной системы (AS). Автономная система – это совокупность локальных сетей, имеющая одного администратора и единую маршрутную политику. Введение AS позволило несколько сократить размер маршрутных таблиц, так как маршруты можно было прокладывать уже не между локальными сетями, а между более крупными образованьями – автономными системами. Само название таких систем подчеркивает их независимость, и только добровольное сотрудничество помогает всем участникам решать общие проблемы.
Обычный пользователь не задумывается и не должен задумываться над проблемами маршрутизации, но даже ему иногда может пригодиться понимание, что возможно, а что невозможно в Интернет.
IP делит все ЭВМ на маршрутизаторы и обычные ЭВМ, последние, как правило, не рассылают свои маршрутные таблицы. Предполагается, что маршрутизатор владеет исчерпывающей информацией о правильных маршрутах (хотя это и не совсем так). Обычная ЭВМ имеет минимальную маршрутную информацию (например, адрес маршрутизатора локальной сети и сервера имен). Автономная система (AS) может содержать множество маршрутизаторов, но взаимодействие с другими AS она осуществляет только через один маршрутизатор, называемый пограничным (
(рис 8.2) Может показаться, что проблема надумана, моя локальная сеть является внутренней, а все, что за ее пределами, – внешнее. На рисунке показаны семь маршрутизаторов (R1R7), один из них связывает эту систему с Интернет. К каждому маршрутизатору подключена одна или несколько субсетей (иначе бы маршрутизаторы были просто не нужны). Следует помнить, что вся эта система маршрутизаторов после подключения становится равноправной частью Интернет. С топологической точки зрения задача маршрутизации сводится к построению оптимального пути от ЭВМ-отправителя к ЭВМ-получателю. В этом подходе все маршрутизаторы и узлы Интернет равноправны, и деление их на внутренние и внешние условно. И тем не менее, такое деление вполне оправдано. Связано это чисто с технологическими возможностями современных маршрутизаторов (и отчасти протоколов), с ограниченностью их памяти и быстродействия. Здесь нужно заметить, что, например, не всегда прямой путь от R5 к R6 является наилучшим, он может, в частности, иметь малую пропускную способность или быть сильно перегруженным. Что считать внутренним, а что внешним, — имеет и юридический аспект. Здесь возникают проблемы, связанные с разглашением частной информации о гражданах, бывают и более тяжелые случаи.
Несколько лет назад разработчик почтовой системы PGP (Pretty Good Privacy) Фил Циммерман (США) был привлечен к суду за то, что способствовал распространению систем шифрования со слишком длинными ключами (большими, чем это разрешено экспортными ограничениями), что создавало трудности американским спецслужбам. Сидеть бы ему в тюрьме, если бы не общественное мнение и умелые адвокаты. Последние убедили суд, что Циммерман ничего не экспортировал, он лишь положил программы на общедоступный сервер, а ушлые европейцы и шустрые китайцы копировали эти программы с его сервера. Вот их и надо привлекать к суду за нарушение экспортных законов. Это оказалось не по плечу могущественной американской Фемиде — они уж точно вовне и на них распространить законы США не так просто. Пограничные проблемы приходится решать при борьбе с хакерами и другими компьютерными террористами и хулиганами. Современное законодательство в этой сфере пока несовершенно.
Если адресат достижим более чем одним путем (например, R7 может передать пакет в R2 более чем 6 путями), маршрутизатор должен сделать выбор, этот выбор осуществляется на основании оценки маршрутов-кандидатов. Обычно каждому сегменту, составляющему маршрут, присваивается некоторая величина — оценка этого сегмента. Каждый протокол маршрутизации использует свою систему оценки маршрутов. Оценка сегмента маршрута называется метрикой. Здесь следует обратить внимание на то, что при выборе маршрута всем сегментам пути должны быть даны сопоставимые значения метрики. Недопустимо, чтобы одни сегменты оценивались числом шагов, а другие — по величине задержки в миллисекундах. В пределах автономной системы это обычно не создает проблем, ведь это зона ответственности одного администратора. Но в региональных сетях, где работает много администраторов, проблема выбора метрики может стать реальной трудностью. Именно по этой причине в таких сетях в качестве метрики сегодня используется вектор расстояния (число шагов), исключающий субъективность оценок метрики.
Помимо классической схемы маршрутизации по адресу места назначения, часто используется вариант выбора маршрута отправителем (данный вариант получил дальнейшее развитие при введении стандарта IPv6). В этом случае IP-пакет содержит соответствующий код опции и список промежуточных адресов узлов, которые он должен посетить по пути к месту назначения.
Существуют и другие схемы, например, использующие широковещательные методы маршрутизации (flooding), где в процессе поиска пути каждый приходящий пакет посылается по всем имеющимся исходящим каналам, за исключением того, по которому он получен. Чтобы исключить беспредельное размножение пакетов, в заголовок вводится поле-счетчик числа шагов. В каждом узле содержимое поля уменьшается на единицу. Когда значение поля становится равным нулю, пакет ликвидируется. Исходное значение счетчика определяется размером субсети. Предпринимаются специальные меры против возможного зацикливания пакетов. Существует усовершенствованная версия широковещательной маршрутизации, называемая селективной широковещательной рассылкой. В этом алгоритме рассылка производится не по всем возможным направлениям, а только по тем, которые предположительно ведут в правильную сторону. Широковещательные методы не относятся к широко применимым. Но они используются там, где нужна предельно возможная надежность, например, в военных приложениях, когда весьма вероятно повреждение тех или иных каналов. Данные методы могут применяться лишь при формировании виртуального канала, ведь они всегда обеспечивают наикратчайший путь, так как перебираются все возможности. Если путь записывается в пакете, получатель может выбрать оптимальный проход и уведомить об этом отправителя.
Большинство алгоритмов учитывают топологию связей, а не их качество (пропускную способность, загрузку, качество и пр.). Но существуют подходы к решению проблемы статической маршрутизации, учитывающие как топологию, так и загрузку (flowbased routing). В некоторых сетях потоки между узлами относительно стабильны и предсказуемы. В этом случае появляется возможность вычислить оптимальную схему маршрутов заранее. Здесь на основе теории массового обслуживания производится оценка средней задержки доставки для каждой связи. Топология маршрутов оптимизируется по значению задержки доставки пакета. Исходными данными при расчете считаются описание топологии связей, матрица трафика для всех узлов Ti,j (в пакетах в секунду) и матрица пропускных способностей каналов Bi,j в битах в секунду. Задержка ? для каждой из связей оценивается по формуле
$$\tau_{i,j} = 1/(P*B_{i,j} - T_{i,j})$$,
где 1/Р — среднее значение ширины пакета в битах, произведение P*Bi,j выражается в пакетах в секунду, а $$\tau$$ измеряется в мсек. Сформировав матрицу $$\tau_{i,j}$$, можно получить граф кратчайших связей. Так как вычисления производятся не в реальном масштабе времени, особых трудностей здесь не возникает (если число узлов не слишком велико).
Статические протоколы предполагают, что любые изменения в маршрутные таблицы вносит администратор сети. Такая схема управления часто используется и в самых современных маршрутизаторах. Динамическая маршрутизация, обладая очевидными преимуществами, к сожалению, облегчает задачу хакеру, пытающемуся проникнуть в сеть.
Хакер может имитировать работу маршрутизатора и вынудить посылку всех пакетов через его машину, объявив, что доступ ко всем узлам Интернет ближе или лучше через его рабочую станцию (этакий волшебный гиперканал!). По этой причине, если можно обойтись без динамической маршрутизации, лучше это сделать, ведь облегчение жизни хакерам в наши задачи не входит.
Рассмотрим для примера сеть, изображенную на рис. 8.3.
(рис 8.3) Схема для иллюстрации методики составления маршрутных таблиц. G1, G2, G3 — маршрутизаторыПримитивная таблица маршрутизации для приведенного примера может иметь вид (для маршрутизатора G2):
| Сеть-адресат | Маршрут к этой сети |
|---|---|
| 193.0.0.0 | Прямая доставка |
| 193.148.0.0 | Прямая доставка |
| 192.0.0.0 | Через адрес 193.0.0.1 |
| 192.166.0.0 | Через адрес 193.148.0.7 |
Заметно сокращает размер маршрутной таблицы маршруты по умолчанию. В этой схеме сначала отыскивается маршрут в таблицах, а если он не найден, пакет посылается в узел, специально выбранный для данного случая. Так, когда имеется только один канал за рубеж, неудачный поиск в таблице маршрутов по России означает, что пакет следует послать по этому каналу и пусть там с ним разбираются. Маршруты по умолчанию используются обычно тогда, когда маршрутизатор имеет ограниченный объем памяти или по какой-то иной причине не имеет полной таблицы маршрутизации. Маршрут по умолчанию может помочь реализовать связь даже при ошибках в маршрутной таблице. Это может не иметь никаких последствий для малых сетей, но для региональных сетей с ограниченной пропускной способностью такое решение может создать серьезные проблемы. Экономия на памяти для маршрутных таблиц – дурной стиль, который не доведет до добра. Например, из-за такого рода ошибки довольно долго пакеты из Ярославля в Москву шли через США; я уже не говорю о случае, когда машины, размещенные в соседних комнатах Президиума РАН, вели обмен между собой через Амстердам (правда, это было достаточно давно). Алгоритм выбора маршрута универсален и не зависит от протокола маршрутизации, который применяется лишь для формирования маршрутной таблицы. Общий алгоритм выбора оптимального маршрута на основе метрик сегментов пути сформулировал американский математик Дикстра в 1959 году.
Описание алгоритма переадресации конкретного пакета с помощью маршрутной таблицы представлено ниже.
Извлечь IP-адрес (ID) места назначения из дейтограммы.
Вычислить IP-адрес сети назначения ( IN )
if IN соответствует какому-либо адресу локальной сети, послать дейтограмму по этому адресу;
else if IN присутствует в маршрутной таблице, то послать дейтограмму к серверу, указанному в таблице;
else if описан маршрут по умолчанию, то послать дейтограмму к этому серверу;
else выдать сообщение об ошибке маршрутизации (недоступность адресата).
Если сеть включает в себя субсети, то для каждой записи в маршрутной таблице производится <И> для ID и маски субсети. Если результат этой операции совпадет с содержимым адресного поля сети, дейтограмма посылается шлюзу субсети. На практике при наличии субсетей в маршрутную таблицу добавляются соответствующие записи с масками и адресами сетей. Машины одной и той же субсети не должны подключаться к разным интерфейсам маршрутизатора. При маршрутизации используется только сетевая часть IP-адреса.
Одна из базовых идей маршрутизации заключается в том, чтобы сконцентрировать маршрутную информацию в ограниченном числе (в идеале — в одном) узловых маршрутизаторов-диспетчеров. Эта замечательная идея ведет к заметному увеличению числа шагов при пересылке пакетов. Оптимизировать решение позволяет
"Прозрачные"
(рис 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. Маршрутизация через опорные сети (
(рис 8.5) Протоколы маршрутизации отличаются друг от друга тем, где хранится, и как формируется маршрутная информация. Оптимальность маршрута достижима лишь при полной информации обо всех возможных маршрутах, но такие данные потребуют слишком большого объема памяти. Полная маршрутная информация доступна для внутренних протоколов при ограниченном объеме сети. Чаще приходится иметь дело с распределенной схемой представления маршрутной информации. Маршрутизатор может быть информирован лишь о состоянии близлежащих каналов и маршрутизаторов.
В маршрутизаторе с динамическим протоколом (например, BGP-4) резидентно загруженная программа-драйвер изменяет таблицы маршрутизации на основе информации, полученной от соседних маршрутизаторов. В ЭВМ, работающей под UNIX и выполняющей функции маршрутизатора, эту задачу часто решает резидентная программа gated или routed (демоны). Последняя поддерживает только внутренние протоколы маршрутизации.
Применение динамической маршрутизации не изменяет алгоритм маршрутизации, осуществляемой на IP-уровне. Программа-драйвер при поиске маршрутизатора-адресата по-прежнему просматривает таблицы. Любой маршрутизатор может использовать два протокола маршрутизации одновременно: один — для внешних связей, другой — для внутренних. Для стыковки внешнего маршрута с внутренним в большинстве протоколов предусматриваются специальные средства.
Может возникнуть вопрос: откуда возникло ограничение на число внешних и внутренних протоколов маршрутизации? Главная причина – согласование метрик сетевых каналов. С внешними протоколами все относительно просто. Во-первых, их мало, во-вторых, практически все они используют для оценки каналов вектор расстояния, что потенциально может вообще снять рассматриваемое ограничение. А как быть с внутренней маршрутизацией? Ведь существуют протоколы, базирующиеся на векторе расстояния (RIP) и на состоянии канала (OSPF или IGRP). Предположим, что в одной зоне сети работает RIP, где канал оценивается числом шагов до цели, а в другой — OSPF с оценкой состояния канала, выполненной администратором сети. Если маршрут содержит фрагменты пути, пролегающие через обе указанные зоны, возникает проблема оценки такого пути. Как сложить метрики этих участков, ведь они несовместимы? В принципе, задача имеет решение: для этого на границах зон с разными протоколами маршрутизации размещаются специальные маршрутизаторы, которые оптимизируют пути для каждого из протоколов (и зон) независимо. Но и в этом случае возможны трудноразрешимые ситуации. Один из таких вариантов показан на рис. 8.6.
(рис 8.6) Пусть на рисунке 8.6 в сетевых зонах, обозначенных кругами, используется протокол RIP, а в остальном пространстве – OSPF. ЭВМ обозначены пятиугольниками, внутренние маршрутизаторы — прямоугольниками, а окрашенные прямоугольники отмечают пограничные маршрутизаторы зон. Любые маршруты из зоны А в зону Б проблем не вызовут, так как внутри зоны маршруты оптимизируются RIP, а между зонами – протоколом OSPF. Возьмем задачу прокладки маршрута из зоны Б в зону В. Здесь следует рассмотреть варианты пути через зоны Г и Д. Важно то, что при выборе оптимального пути придется как-то учитывать метрики как OSPF-части пути, так и фрагменты транзитного пути внутри зон. При этом надо принять решение, с какими весами складывать метрики разных протоколов. Эта проблема снимается, если каждая зона имеет только один пограничный маршрутизатор. Маршрут прокладывается между пограничными маршрутизаторами, а различие маршрутов внутри зон игнорируется. Кстати именно эта логика лежит в основе рекомендации для автономной системы иметь только один пограничный маршрутизатор. Поясню это на примере, показанном на рис. 8.7.
(рис 8.7) Рассмотрим процедуру выбора пути от ЭВМ-1 к ЭВМ-2 из автономной системы AS1 в автономную систему AS2. Имеются метрики, характеризующие путь до маршрутизаторов GW1 и GW2 (M1 и M2).
Если бы у AS1 был только один пограничный шлюз (например, GW1), то задача решалась бы автоматически. Другим подходом может быть деление всего Интернет на две части, одна делается доступной только через GW1, а вторая – через GW2.
Любая автономная система (AS, система маршрутизаторов, ЭВМ или сетей, имеющая единую политику маршрутизации) может выбрать свой собственный протокол маршрутизации.
Деликатной процедурой
Другой проблемой является ситуация, при которой маршрутизатор оказался временно отключен от сети переменного тока и был перезагружен. В этом случае он не будет знать, какой номер кадра следует ожидать. Кроме того, вполне реалистично предположить, что за 136 лет счетчик пакетов в маршрутизаторе может сбиться. Последствия могут оказаться плачевными.
Для решения всех этих проблем можно ввести, помимо номера, еще и возраст пакета и уменьшать его на единицу раз в секунду. Когда возраст станет равным нулю, маршрутная информация из маршрутизатора удаляется и процедура начинается с нуля.
Другим решением может быть схема, при которой входной пакет, предназначенный для рассылки, посылается соседям не сразу, а выдерживается некоторое время в буфере. Если за время выдержки придет очередной пакет, то их порядковые номера сравниваются. Если они равны, то дубликат отбрасывается. При разных номерах отбрасывается более старый. Для обеспечения надежности получение кадра с маршрутной информацией обязательно подтверждается.
Следует учитывать, что каждому сегменту пути может быть присвоено два значения метрики, по одному для каждого из направлений обмена.
Внутренний протокол маршрутизации
Алгоритм вектора расстояния неявно предполагает, что все каналы имеют равную пропускную способность.
Существует более новый протокол OSPF (Open Shortest Pass First, RFC-1131, -1245, -1247, -1253, -1584, -1850, -2328, -2740), базирующийся на оценках состояний каналов. Как во всех маршрутных протоколах, использующих состояние канала, многое зависит от того, как вычисляется метрика. Если определяющим фактором выбрать полосу пропускания канала, то при определенных обстоятельствах могут возникнуть трудно преодолимые проблемы. Рассмотрим топологию сети, показанную на рис. 8.8.
(рис 8.8) Пример топологии сети, допускающей осцилляцию маршрутовЗдесь две субсети А и Б соединены двумя каналами 1 и 2. Кружочками обозначены маршрутизаторы. Если в исходный момент основной поток между сетями протекает по каналу 2, он может оказаться перегружен, в то время как канал 1 получит меньшее значение метрики из-за отсутствия загрузки. При очередной оценке каналов будет принято решение переключить поток между сетями на канал 1. После этого будет перегружен канал 1, и так может повторяться до бесконечности. Подобная ситуация называется осцилляцией маршрутов, и ее желательно избегать. Маршрутные таблицы в маршрутизаторах актуализуются вдоль пути с заметными задержками и отнюдь не синхронно. Такие осцилляции могут в несколько раз понизить пропускную способность сети, что необходимо учитывать, выбирая параметры протоколов маршрутизации.
На практике этого не происходит, так как метрики сегментам пути в OSPF присваивает сетевой администратор. Но можно ожидать, что появятся как внутренние, так и внешние протоколы маршрутизации на основе алгоритма состояния канала, которые будут исследовать параметры канала в реальном масштабе времени.
Для взаимодействия маршрутизаторов друг с другом используются внешние протоколы (
IGRP применяет несколько типов метрики, по одной на каждый вид QOS (качества обслуживания). Метрика характеризуется 32-разрядным числом. В однородных средах этот вид метрики вырождается в число шагов до цели. При использовании путей со смешанной технологией передачи информации (ATM, Ethernet, последовательные каналы PPP и пр.) маршрут с минимальным значением метрики является предпочтительным. Актуализация маршрутной информации для этого протокола производится каждые 90 секунд. Если какой-либо маршрут не подтверждает своей работоспособности в течение 270 сек, он считается недоступным. После семи циклов (630 сек) актуализации такой маршрут удаляется из маршрутных таблиц. Протокол IGRP, вообще говоря, допускает автоматическое вычисление метрики. Полученное значение может быть умножено на величину параметра вариация. Этот параметр задает всегда сам администратор. С его помощью можно выровнять значения метрик нескольких каналов, что позволит пустить через них параллельный трафик. Пользоваться параметром вариация следует осторожно, так как при некоторых его значениях можно разрешить пакетам идти вспять, что приведет к циклическому движению пакетов и заблокирует работу сети.
Протокол IDPR (InterDomain Policy
Сразу после включения маршрутизатор не имеет информации о возможностях соседних маршрутизаторов. Статические маршрутные таблицы могут храниться в постоянной памяти или загружаться из какого-то сетевого сервера. По этой причине первейшей задачей маршрутизатора является получение маршрутной информации от соседей, а для начала — выявление наличия соседей и их адресов. Для этой цели посылается специальный пакет Hello через каждый из своих внешних интерфейсов. В ответ предполагается получить отклик, содержащий идентификационную информацию соответствующего маршрутизатора.
К сожалению, многие современные протоколы маршрутизации не имеют встроенных средств аутентификации (контроля доступа), что делает их уязвимыми для различных злоупотреблений.
В локальных или корпоративных сетях иной раз возникает необходимость разослать некоторую информацию всем остальным ЭВМ-пользователям сети (штормовое предупреждение, изменение курса акций, телеконференции с большим числом участников и т.д.). Отправителю достаточно знать адреса всех N заинтересованных пользователей и послать им соответствующее сообщение. Данная схема крайне не эффективна, ведь обычная широковещательная адресация предлагает решение, в N раз лучшее с точки зрения загрузки сети (посылается одно, а не N сообщений). Широковещательная адресация сработает, если в локальной сети нет маршрутизаторов; в противном случае широковещательные адреса МАС-типа заменяются на IP-адреса (что, впрочем, не слишком изящное решение) или применяется мультикастинг-адресация. Для мультикастинг-адресации в Интернет используются специальные адреса D-класса. Такие адреса позволяют организовать до 250 миллионов групп адресатов, функционирующих одновременно. При посылке пакета по такому адресу доставка не гарантируется, и некоторые члены группы могут не получить этот пакет. Маршрутизация для мультикастинга представляет собой отдельную задачу, ведь здесь надо проложить маршрут от отправителя к большому числу получателей. Традиционные методы маршрутизации здесь применимы, но до крайности не эффективны. Для целей выбора маршрута можно с успехом применить алгоритм "дерево связей" (
(рис 8.9) Алгоритм Reverse Path ForwardingПри передаче мультимедиа-информации используются принципиально другие протоколы маршрутизации. Здесь путь прокладывается от получателя к отправителю, а не наоборот, поскольку там при доставке применяется мультикастинговый метод. Здесь, как правило, один отправитель посылает пакеты многим потребителям. При этом важно, чтобы размножение пакета происходило как можно ближе к кластеру адресатов. Такая стратегия иной раз удлиняет маршрут, но всегда снижает результирующую загрузку сети.
Если сеть однородна, то есть все каналы имеют равную пропускную способность и примерно равную загрузку, что типично для небольших локальных сетей, то число шагов до цели является разумной оценкой пути (метрикой).
Описания этих маршрутов хранится в специальной таблице, называемой маршрутной. Таблица маршрутизации RIP содержит по одной записи на каждую обслуживаемую машину (на каждый маршрут). Запись должна включать в себя:
IP-адрес места назначения;
метрику маршрута (от 1 до 15; число шагов до места назначения);
IP-адрес ближайшего маршрутизатора (Gateway) по пути к месту назначения;
таймеры маршрута.
Первым двум полям записи мы обязаны появлению термина вектор расстояния (место назначения – направление; метрика – модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте либо произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать следующие три типа ошибок.
<16 ).Несоответствие маршрутной таблицы реальной ситуации типично не только для RIP, но характерно для всех протоколов, базирующихся на векторе расстояния, где информационные сообщения актуализации несут в себе только пары кодов: адрес места назначение и расстояние до него. Пояснение проблемы дано на рис. 8.10 ниже.
(рис 8.10) Иллюстрация, поясняющая возникновение циклических маршрутов при использовании вектора расстоянияВ верхней части рисунка показана ситуация, когда маршрутизаторы указывают маршрут до сети <A> в соответствии со стрелками. В нижней части связь на участке GW1 <Сеть A> оборвана, а GW2 по-прежнему продолжает оповещать о ее доступности с числом шагов, равным 2. При этом GW1, восприняв эту информацию (если GW2 успел передать свою маршрутную информацию раньше GW1), может перенаправить пакеты, адресованные сети А, на GW2, а в своей маршрутной таблице будет характеризовать путь до сети А метрикой 3. Таким образом формируется замкнутая петля маршрутов. Последующая широковещательная передача маршрутных данных GW1 и GW2 не решит эту проблему быстро. Так, после очередного обмена путь от GW2 до сети А будет характеризоваться метрикой 5. Этот процесс будет продолжаться до тех пор, пока метрика не станет равной 16, что займет слишком много циклов обмена маршрутной информацией.
Заметим, что на время распространения информации о недоступности сети А станет недоступна сеть С — из-за циклического обмена пакетами между маршрутизаторами GW1 и GW2 (см. рис 8.10).
Проблема может быть решена следующим образом. Маршрутизатор запоминает, через какой интерфейс получена маршрутная информация, и через этот интерфейс эту информацию уже не передает. В рассмотренном выше примере GW2 не станет посылать информацию о пути к сети А маршрутизатору GW1, от которого он получил эти данные. В этом случае в маршрутной таблице GW1 путь до А исчезнет сразу. Остальные маршрутизаторы узнают о недостижимости сети А через несколько циклов. Существуют и другие пути преодоления медленных переходных процессов. Если производится оповещение о коротком пути, все узлы-получатели воспринимают эти данные немедленно. Если же маршрутизатор закрывает какой-то путь, его отмена фиксируется остальными лишь по тайм-ауту. Универсальным методом исключения ошибок при маршрутизации является использование достаточно большой выдержки перед тем как использовать информацию об изменении маршрутов. В этом случае к моменту изменения маршрута эта информация станет доступной всем участникам процесса маршрутизации. Однако все перечисленные методы и некоторые другие известные алгоритмы, решая одну проблему, часто вносят другие. Многие из этих методов могут при определенных условиях вызвать лавину широковещательных сообщений, что также дезорганизует сеть.
Но даже усовершенствование, изложенное выше, не всегда срабатывает. На рис. 8.11 приведен пример, когда переходной процесс, несмотря на усовершенствование, будет идти долго. При обрыве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает узлам А и Б. К сожалению, А знает, что Б имеет проход к Г длиной 2, из чего он делает вывод о достижимости Г за три шага. Аналогично рассуждает Б о возможности достижимости Г через А. Далее при последующих рассылках метрика доступности Г характеризуется все большими значениями, до тех пор пока не станет равной "бесконечности" (16).
(рис 8.11) Пример топологии, где переходной процесс осуществляется медленно, даже при усовершенствовании алгоритма В RIP сообщения инкапсулируются в UDP-дейтограммы, при этом передача осуществляется через порт 520. Если между отправителем и приемником расположено три маршрутизатора, считается, что между ними 4 шага. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, например, два шага по сегментам сети Ethernet обеспечат большую пропускную способность, чем один шаг через последовательный канал на основе интерфейса RS-232.
Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для других протоколов маршрутизации). Каждому маршруту ставится в соответствие таймер тайм-аута и "сборщика мусора". Тайм-аут-таймер сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время "уборки мусора" (2мин). При появлении эквивалентного маршрута переключения на него не происходит, таким образом блокируется возможность осцилляции между двумя или более равноценными маршрутами.
Каждые 30 секунд таблица маршрутизации или ее часть посылается всем соседним маршрутизаторам. Могут посылаться и специальные запросы при локальном изменении таблицы. RIP достаточно простой протокол, но, к сожалению, не лишенный недостатков:
a. RIP не работает с адресами субсетей. Если нормальный 16-бит идентификатор ЭВМ класса B не равен 0, RIP не может определить является ли ненулевая часть cубсетевым ID или полным IP-адресом;
b. RIP требует много времени для восстановления связи после сбоя в маршрутизаторе (минуты). В процессе установления режима возможны циклы;
c. число шагов — важный, но не единственный параметр маршрута, да и 15 шагов не предел для современных сетей.
Протокол RIP-2 (RFC-1388, 1993 год и более поздние публикации, смотри начало главы) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг, позволяет работать с масками субсетей, предоставляет некоторые возможности обеспечения безопасности.
Если субсеть содержит N маршрутизаторов, каждый из которых имеет M соседей, то требуемая емкость памяти будет пропорциональна N*M. Для больших субсетей это может оказаться проблемой, да и скорость расчетов при этом окажется невысока. Несмотря на это, в большинстве случаев протокол работает вполне удовлетворительно. Но при тысячах и тем более десятках тысяч узлов этими проблемами нельзя пренебречь. В таких случаях следует подумать о разбивке сети на зоны и построении иерархической схемы маршрутизации. Причем чем больше сеть, тем больше уровней иерархии следует предусмотреть. Протокол OSPF может использоваться в корпоративных сетях, где сетевые объекты разбросаны на большой площади. Например, OSPF был реализован в региональной сети Центробанка РФ Вологодской области.
Автономная система может быть поделена на несколько областей, куда могут входить как отдельные ЭВМ, так и целые сети. В этом случае внутренние маршрутизаторы области могут и не иметь информации о топологии остальной части AS. Сеть обычно имеет выделенный маршрутизатор, который является источником маршрутной информации для остальных маршрутизаторов AS. Каждый маршрутизатор самостоятельно решает задачу оптимизации маршрутов. Если к месту назначения ведут два или более эквивалентных маршрута, информационный поток будет поделен между ними поровну. Можно подумать, что совпадение метрик для каналов возможно лишь случайно. Так бы и было, если бы метрики вычислялись автоматически на основе измерения состояния каналов, но на практике это делает администратор сети. Переходные процессы в OSPF завершаются быстрее, чем в RIP. В процессе выбора оптимального маршрута анализируется ориентированный граф сети. Понятно, что для решения этой задачи нужно иметь всю необходимую информацию обо всех узлах и каналах данной области сети. Ниже описан алгоритм Дикстры по выбору оптимального пути. Целью алгоритма является преобразование многосвязного графа в дерево с оптимальной топологией. На иллюстративном рис. 8.12 приведена схема узлов (A-J) со значениями метрики для каждого из отрезков пути. Анализ графа начинается с узла A (Старт). Пути с наименьшим суммарным значением метрики считаются наилучшими. Именно они становятся выбранными в результате рассмотрения графа ("кратчайшие пути").
(рис 8.12) Иллюстрация работы алгоритма ДикстрыНиже дается формальное описание алгоритма. Сначала вводим некоторые определения.
Пусть D(v) равно сумме весов связей для данного пути.
Пусть C(i,j) равно весу связи между узлами с номерами i и j.
Далее следует последовательность шагов, реализующих алгоритм.
N = {1}.N устанавливаем D(v)= c(1,v).w не из множества N, для которого D(w) минимально, и добавляем узел w в множество N.D(v) для всех узлов не из множества ND(v)=min{D(v), D(v)+c(w,v)}.
N.Топология маршрутов для узла A приведена на нижней части рис. 8.12. В скобках записаны числа, характеризующие метрику отобранного маршрута согласно критерию пункта 3.
| Шаг | Множество | Метрика связи узла A с узлами | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| N | B | C | D | E | F | G | H | I | J | |
| 0 | {A} | 3 | - | 9 | - | - | - | - | - | - |
| 1 | {A,B} | (3) | 4 | 9 | 7 | - | 10 | - | - | - |
| 2 | {A,B,C} | 3 | (4) | 6 | 6 | 10 | 10 | 8 | - | 14 |
| 3 | {A,BC,D} | 3 | 4 | (6) | 6 | 10 | 10 | 8 | 9 | 14 |
| 4 | {A,B,C,D,E} | 3 | 4 | 6 | (6) | 10 | 10 | 8 | 9 | 14 |
| 5 | {A,B,C,D,E,H} | 3 | 4 | 6 | 6 | 10 | 10 | (8) | 9 | 14 |
| 6 | {A,B,C,D,E,H,I} | 3 | 4 | 6 | 6 | 10 | 10 | 8 | (9) | 14 |
| 7 | {A,B,C,D,E,H,I,F} | 3 | 4 | 6 | 6 | (10) | 10 | 8 | 9 | 14 |
| 8 | {A,B,C,D,E,H,I,F,G} | 3 | 4 | 6 | 6 | 10 | (10) | 8 | 9 | 14 |
| 9 | {A,B,C,D,E,H,I,F,G,J} | 3 | 4 | 6 | 6 | 10 | 10 | 8 | 9 | (14) |
Таблица 8.1 может иметь совершенно иное содержимое для какого-то другого вида сервиса, выбранные пути при этом могут иметь другую топологию. Качество сервиса (QOS) может характеризоваться следующими параметрами:
Определяющими являются три характеристики: задержка, пропускная способность и надежность. Для транспортных целей OSPF использует IP непосредственно, т.е. не привлекает протоколы UDP или TCP. OSPF имеет свой код (89) в протокольном поле IP-заголовка. Код TOS (Type Of Service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение TOS здесь задается в самих пакетах OSPF. Маршрутизация в этом протоколе определяется IP-адресом и типом сервиса. Так как протокол не требует
(рис 8.13) Пример выделения областей при OSPF маршрутизации в автономной системе (М – маршрутизаторы; C – сети)На рис 8.13 (см. также рис 8.12) приведен пример выделения областей маршрутизации при OSPF-маршрутизации в пределах автономной системы. На рис 8.13 маршрутизаторы М4 и М2 выполняют функцию опорной сети для других областей. В выделенных областях может быть любое число маршрутизаторов. Утолщенными линиями выделены связи с другими автономными системами.
При передаче OSPF-пакетов фрагментация нежелательна, но не запрещается. Для передачи статусной информации OSPF использует широковещательные сообщения HELLO. Для повышения безопасности предусмотрена авторизация процедур. OSPF-протокол требует резервирования двух мультикастинг-адресов:
224.0.0.5 предназначен для обращения ко всем маршрутизаторам, поддерживающим этот протокол
224.0.0.6 служит для обращения к специально выделенному маршрутизатору
Заметим, что для обращения ко всем системам локальной сети используется мультикастинг-адрес 224.0.0.1, а для обращения ко всем маршрутизаторам локальной сети – адрес 224.0.0.2. В исходный момент (сразу после загрузки) маршрутизатор должен выявить наличие маршрутизаторов соседей, для чего он посылает запросы HELLO через все свои
Если адрес пересылки равен 0.0.0.0, данные посылаются пограничному маршрутизатору автономной системы — источнику данного сообщения. Метка внешнего маршрута — 32-битовое число, присваиваемое каждому внешнему маршруту. Эта метка самим протоколом OSPF не используется и предназначена для информирования других автономных систем при работе внешних протоколов маршрутизации. Маршрутная таблица OSPF содержит в себе:
Число маршрутных таблиц может быть равно числу значений качества обслуживания.
Здесь уместно заметить, что Интернет – это клуб джентльменов. Очень многие узлы пропускают через себя значительный транзитный трафик, который ограничивает возможности непосредственных клиентов узла. Как правило, этот трафик никак не оплачивается. Администраторы могут в рамках протокола BGP существенно ограничить или даже исключить такой транзитный трафик, но они обычно этого не делают, понимая, что их клиенты создают такой же транзитный трафик для других узлов. Эгоистичное поведение администраторов развалило бы сеть Интернет на ряд враждующих феодальных крепостей.
После того, как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано, — это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения.
После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее значение из полученного в сообщении OPEN и определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGPidentifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то, согласно правилам, должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.
Сообщения типа UPDATE (изменения) используются для передачи маршрутной информации между BGP-партнерами. Этот тип сообщения позволяет сообщить об одном новом маршруте или объявить о закрытии группы маршрутов, причем объявление об открытии нового и закрытии старых маршрутов возможно в пределах одного сообщения.
Если длина списка отмененных маршрутов равна нулю, ни один маршрут не отменен, а поле отмененные маршруты в сообщении отсутствует. Поле отмененные маршруты имеет переменную длину и содержит список IP-адресных префиксов маршрутов, которые стали недоступны.
Атрибуты пути бывают "стандартными обязательными" (wellknown mandatory), стандартными на усмотрение оператора, опционными переходными и опционными непереходными. Стандартные атрибуты должны распознаваться любыми BGP-приложениями. Опционные атрибуты могут не распознаваться некоторыми приложениями. Обработка нераспознанных атрибутов задается битом 1 поля флагов. Пути с нераспознанными переходными опционными атрибутами должны восприниматься как рабочие. Один и тот же атрибут может появляться в списке атрибутов пути только один раз. Предусмотрены следующие разновидности кодов типа атрибута.
ORIGIN (код типа = 1) — стандартный обязательный атрибут, который определяет происхождение маршрутной информации. Генерируется автономной системой, которая является источником маршрутной информации. Значение атрибута в этом случае может принимать следующие значения (таблица 8.2):
| код атрибута | описание |
|---|---|
| 0 | |
| 1 | |
| 2 |
AS_PATH (код типа = 2) также является стандартным обязательным атрибутом, который составлен из совокупности сегментов пути. Атрибут определяет автономные системы, через которые доставлена маршрутная информация. Когда BGP-маршрутизатор передает описание маршрута, которое он получил от своего BGP-партнера, он модифицирует AS_PATH -атрибут, соответствующий этому маршруту, если информация передается за пределы автономной системы. Каждый сегмент AS_PATH состоит из трех частей <тип сегмента пути, длина сегмента пути и оценка сегмента пути>. Тип сегмента пути представляет собой, в свою очередь, однооктетное поле, которое может принимать следующие значения (таблица 8.3):
| код типа сегмента | описание |
|---|---|
| 1 | AS_SET: неупорядоченный набор маршрутов в UPDATE-сообщении |
| 2 | AS_SEQUENCE: упорядоченный набор маршрутов автономной системы в UPDATE-сообщении. |
Длина сегмента пути представляет собой однооктетное поле, которое содержит число AS, записанных в поле оценка сегмента пути. Последнее поле хранит один или более кодов автономной системы, по два октета каждый.
NEXT_HOP (код типа = 3) — стандартный обязательный атрибут, определяющий IP-адрес пограничного маршрутизатора, который должен рассматриваться как следующий шаг на пути к точке назначения.
MULI_EXIT_DISC (код типа = 4) представляет собой опционный непереходной атрибут, который занимает 4 октета и является положительным целым числом. Величина этого атрибута может применяться при выборе одного из нескольких путей к соседней автономной системе.
LOCAL_PREF (код типа = 5) является опционным атрибутом, занимающим 4 октета. Он используется BGP-маршрутизатором, чтобы сообщить своим BGP-партнерам в своей собственной автономной системе степень предпочтения объявленного маршрута.
ATOMIC_AGGREGATE (код типа = 6) представляет собой стандартный атрибут, который применяется для информирования партнеров о выборе маршрута, обеспечивающего доступ к более широкому списку адресов.
AGGREGATOR (код типа = 7 ) — опционный переходной атрибут с длиной в 6 октетов. Атрибут содержит последний код автономной системы, который определяет агрегатный маршрут (занимает два октета), и IP-адрес BGP-маршрутизатора, который сформировал этот маршрут (4 октета).
Информация о работоспособности соседних маршрутизаторов получается из KEEPALIVE-сообщений, которые должны посылаться настолько часто, чтобы уложиться во время, отведенное таймером сохранения (HOLD). Обычно это время не должно превышать одной трети от времени сохранения, но не должно быть и меньше 1 секунды. Если выбранное значение времени сохранения равно нулю, периодическая посылка KEEPALIVE-сообщений не обязательна.
NOTIFICATION-сообщения посылаются, когда обнаружена ошибка. BGP-связь при этом немедленно прерывается.
Вся маршрутная информация хранится в специальной базе данных RIB (Routing Information Base). Маршрутная база данных BGP состоит из трех частей:
AdjRIBsIn: Запоминает маршрутную информацию, которая получена из UPDATE-сообщений. Это список маршрутов, из которого можно выбирать (Policy Information Base — PIB)LocRIB: Содержит локальную маршрутную информацию, которую BGP-маршрутизатор отобрал, руководствуясь маршрутной политикой, из Adj-RIBs-InAdjRIBsOut: Содержит информацию, которую локальный BGP-маршрутизатор отобрал для рассылки соседям с помощью UPDATE-сообщенийТак как разные BGP-партнеры могут иметь разную политику маршрутизации, возможны осцилляции маршрутов. Для исключения этого необходимо выполнять следующее правило: если используемый маршрут объявлен не рабочим (в процессе корректировки получено сообщение с соответствующим атрибутом), до переключения на новый маршрут необходимо ретранслировать сообщение о недоступности старого всем соседним узлам.
Протокол BGP позволяет реализовать маршрутную политику, определяемую администратором AS. Политика отражается в конфигурационных файлах BGP. Маршрутная политика — это не часть протокола, она определяет решения, когда место назначения достижимо несколькими путями; политика отражает соображения безопасности, экономические интересы и пр.. Количество сетей в пределах одной AS не лимитировано. Один маршрутизатор на много сетей позволяет минимизировать таблицу маршрутов. BGP использует три таймера:
ConnectRetry (сбрасывается при инициализации и коррекции; 120 сек),
Holdtime (запускается при получении команд Update или KeepAlive; 90сек) и
KeepAlive (запускается при посылке сообщения KeepAlive; 30сек).
BGP отличается от RIP и OSPF тем, что использует TCP в качестве транспортного протокола. Две системы, применяющие BGP, связываются друг с другом и пересылают посредством TCP полные таблицы маршрутизации.
В дальнейшем обмен идет только в случае каких-то изменений. ЭВМ, использующая BGP, не обязательно является маршрутизатором. Сообщения обрабатываются только после того, как они полностью получены.
BGP является протоколом, ориентирующимся на вектор расстояния. Вектор описывается списком AS по 16 бит на AS. BGP регулярно (каждые 30 сек) посылает соседям TCP-сообщения, подтверждающие, что узел жив (это не то же самое, что функция keepalive в TCP). Если два BGP-маршрутизатора попытаются установить связь друг с другом одновременно, такие две связи могут быть установлены. Эта ситуация называется столкновением, одна из связей должна быть ликвидирована. При установлении связи маршрутизаторов сначала делается попытка реализовать высший из протоколов (например, BGP-4); если один из них не поддерживает эту версию, номер версии понижается.
BGP-4 позволяет пересылать информацию о маршруте в рамках одного IP-пакета. Для того, чтобы приспособиться к этому, изменены семантика и кодирование атрибута AS_PASS. Введен новый атрибут LOCAL_PREF (степень предпочтительности маршрута для собственной AS), который упрощает процедуру выбора маршрута. Атрибут INTER_AS_METRICS переименован в MULTI_EXIT_DISC (4 октета; служит для выбора пути к одному из соседей). Введены новые атрибуты ATOMIC_AGGREGATE и AGGREGATOR, которые позволяют группировать маршруты. Структура данных отражается и на схеме принятия решения, которая имеет три фазы.
AS.Loc_RIB всем соседним AS согласно политике, заложенной в RIB. Группировка маршрутов и редактирование маршрутной информации.Основу протокола
Дополнительная информация, например 32-разрядная маска, выделяющая поле адреса сети, передается в рамках протокола маршрутизации. При этом выдерживается строгая иерархия адресов: провайдер > предприятие > отдел/здание > сегмент локальной сети. Групповой (агрегатный) адрес воспринимается маршрутизатором как один адрес. Группу может образовывать только непрерывная последовательность IP-адресов. Такой бесклассовый интернетовский адрес часто называется IP-префиксом. Так адрес 192.1.1.0/24 означает диапазон адресов 192.1.1.0 — 192.1.1.255, а адрес 192.1.128.0/17 описывает диапазон 192.1.128.0 — 192.1.255.255, таким образом, число, следующее после косой черты, задает число двоичных разрядов префикса. Это представление используется при описании политики маршрутизации и самих маршрутов.
Обычно предполагается, что при посылке пакета из точки <А> в точку <B> маршруты в одном и другом направлении совпадают. Но это не всегда так. Пример, когда маршруты пакетов туда и обратно не совпадают, представлен на рис. 8.14. В предложенной схеме имеется "ЭВМ-Место назначения" и "ЭВМ-отправитель", а также два маршрутизатора GW-2 и GW-1.
(рис 8.14) Пример разных маршрутов для пути туда и обратноПредполагается, что оператор находится в ЭВМ-отправителе. Команда traceroute 192.148.166.33 в этом случае выдаст:
1 GW1 (192.148.166.35) 2 Место назначения (192.148.166.33)
Команда же traceroute 192.148.165.80 распечатает:
1 GW1 (192.148.166.35) 2 GW2 (192.148.166.7) 3 Место назначения (192.148.165.80)
Команда traceroute -g 192.148.165.80 сообщит вам:
1 GW1 (192.148.166.35) 2 ***** ; В этом режиме маршрутизатор не откликается 3 Место назначения (192.148.165.80) 4 GW1 (192.148.166.35) 5 ЭВМ-отправитель (192.148.166.32)
Из приведенных примеров видна полезность команды traceroute для понимания того, как движутся пакеты в сети. В некоторых случаях это может помочь оптимизировать маршрутизацию и улучшить пропускную способность сети.
Следует учесть, что внешняя маршрутизация представляет собой систему с задержанной обратной связью и как таковая склонна к осцилляциям маршрутов.
В BGP в качестве метрики используется число шагов до цели, время распространения маршрутной информации здесь велико, у разных маршрутизаторов может быть прописана разная маршрутная политика. Допустим, какой-то маршрутизатор на основании анализа ситуации принял решение об изменении маршрута с варианта 1 на вариант 2 и сразу реализовал это решение. Эти данные дойдут до соседей спустя несколько минут. Они на основе новых данных могут также принять определенные решения, уведомив об этом своих соседей. Может так получиться, что, после того как наш маршрутизатор получит данные от своих соседей, метрика для варианта маршрута 1 окажется меньше метрики маршрута 2 и придется вернуться к пути, от которого он только что отказался. Чтобы такого не происходило, нужно сначала уведомлять соседние маршрутизаторы о принятом решении, но на новый маршрут не переключаться, пока от соседей не придут данные об их намерениях. (Для этого нужно задать соответствующие таймерные переменные). Возможно, что переключение на новый маршрут придется отменить, так как это ведет к осцилляции маршрута. Кто-то может сказать, что ему все равно, по какому маршруту доставляется пакет (по пути 1 или 2), и пусть себе маршруты осциллируют. Эта точка зрения ошибочна, так как при осцилляции маршрутов их установление происходит в маршрутизаторах не одновременно и заметное число пакетов не будет доставлено адресату вообще.
Важным свойством протокола является возможность декларации резервного (backup) маршрута. Если основной маршрут автономной системы стал недоступен, маршрутизатор переключит поток на этот резервный канал. При этом пользователи сети не должны ожидать момента, когда администратор сети вернется из отпуска, проснется или придет из кафетерия и сам внесет необходимые коррективы.
Конфигурирование BGP требует хорошего понимания его работы. Для облегчения спецификации маршрутной политики на различных уровнях иерархии, например, на уровне автономных систем (AS) был разработан язык описания маршрутной политики RPSL (Routing Policy Specification Language). Теперь низкоуровневые конфигурации маршрутизаторов могут генерироваться на основании спецификаций RPSL. Язык RPSL (см. http://book.itep.ru/4/4/rpsl.htm) является расширяемым и не препятствует внедрению новых протоколов маршрутизации.
Язык RPSL призван заменить язык спецификации маршрутной политики, используемый в настоящее время и описанный в документах RIPE-181 или RFC-1786 RIPE-81 был первым языком, примененным в Интернет для спецификации маршрутных политик. В процессе использования RIPE-181 стало понятно, что некоторые политики не могут быть специфицированы и необходим более совершенный язык.
Язык RPSL был сконструирован так, чтобы описание всей политики маршрутизации записывалось в одну распределенную базу данных, улучшая целостность маршрутизации в Интернет. RPSL не является языком конфигурации маршрутизатора. Язык RPSL сформирован таким образом, чтобы конфигурация маршрутизатора осуществлялась на основе описания маршрутной политики автономной системы (класс aut-num ) в сочетании с описанием маршрутизатора (класс inet-rtr ), которое предоставляет идентификатор маршрутизатора, номер автономной системы, описания интерфейсов и партнеров маршрутизатора. Эти данные используются совместно с глобальной базой данных карты автономных систем (класс as-set ), и информацией об автономных системах отправителях и о route и routeset ).
Язык RPSL является объектно-ориентированным, — то есть, его объекты содержат блоки описания политики и административную информацию. Эти объекты регистрируются в IRR (Internet Routing Registry) авторизованными организациями.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.