Протокол OSPF (окончание)
Дополнительные возможности OSPF
5.3. Сети множественного доступа
5.4. Иерархическая маршрутизация (Разбиение на области)
5.5. Типы и форматы сообщений
5.6. Обсуждение
Протокол OSPF - первая часть
Оглавление учебного пособия
Страница курса "Телекоммуникационные технологии"
Кафедра КТС
В дополнение к общей идеологии протоколов состояния связей, описанной в предыдущих разделах этой главы, в OSPF реализованы дополнительные возможности, позволяющие оптимизировать расчет маршрутов в сетях с множественным доступом и в сложных системах сетей.
Протокол OSPF особым образом выделяет сети множественного доступа, то есть сети, где каждый узел может непосредственно связаться с каждым. Такие сети могут также поддерживать широковещательную передачу и мультикастинг (broadcast networks, например, Ethernet, FDDI) или не поддерживать таковой (non-broadcast multi-access networks, NBMA, например, Х.25, Frame Relay, ATM).
Рассмотрим сначала случай широковещательной сети, к которой подключено несколько маршрутизаторов. Следуя модели работы протоколов состояния связей, связь каждой пары маршрутизаторов должна рассматриваться как связь типа "точка-точка", что значит: каждый маршрутизатор должен установить смежность с каждым, то есть всего N(N-1)/2 отношений смежности, по которым происходит обмен всеми типами сообщений, описанных в разделе 5.2. Каждый маршрутизатор будет вносить в базу данных N-1 записей о связях с другими маршрутизаторами плюс одна связь с вершиной типа "тупиковая сеть" (то есть с хостами, которые тоже могут находиться в этой IP-сети), всего в базе данных будет N2 записей, касающихся рассматриваемой сети.
Очевидно, такое буквальное следование идеологии не является рациональным. Протокол OSPF сводит ситуацию только к N отношениям смежности, выбирая среди всех маршрутизаторов данной широковещательной сети один выделенный маршрутизатор (designated router, DR), с которым все остальные маршрутизаторы устанавливают отношения смежности.
Это значит, что каждый "невыделенный" маршрутизатор поддерживает синхронизацию базы данных состояния связей не со всеми соседями, а только с выделенным маршрутизатором. При этом протокол затопления в подобной сети работает следующим образом: "обычный" маршрутизатор сообщает об изменении состояния своих связей выделенному маршрутизатору, а тот затапливает сеть этим сообщением и его получают все остальные маршрутизаторы сети. Естественно, что по своим внешним интерфейсам, ведущим к прочим маршрутизаторам системы, не находящимся в данной сети множественного доступа, каждый маршрутизатор отправляет сообщения без участия выделенного маршрутизатора.
Протокол OSPF позволяет также редуцировать размер базы данных состояния связей. Для этого в граф системы вводится виртуальная вершина "транзитная сеть", представляющая собой сеть множественного доступа как таковую. Каждый маршрутизатор, в том числе и выделенный, при таком подходе имеет не набор двухточечных связей со всеми остальными маршрутизаторами своей сети, а одну связь с вершиной "транзитная сеть". Таким образом, в базу данных вносится всего 2N, а не N2 записей: N записей о связях, идущих от маршрутизаторов к вершине "транзитная сеть", и столько же связей, идущих в обратном направлении.
За поддержку в базе данных записей о связях, идущих от маршрутизаторов, отвечают, как и положено, сами маршрутизаторы. Эти связи имеют метрику, равную метрике сети (например, 10 в случае 10Base-T Ethernet).
За поддержку связей, идущих от транзитной сети к маршрутизаторам, отвечает выделенный маршрутизатор (см. также п. 5.5.7, тип 2). Такие связи имеют нулевую метрику, это связано с тем, что при такой модели маршрут между двумя маршрутизаторами А и В в сети T проходит через вершину "транзитная сеть Т", то есть его метрика равна сумме метрик связей АТ и ТВ. Очевидно, что метрика этого маршрута должна быть равна метрике сети, но метрика связи АТ уже равна метрике сети, следовательно, метрика связи ВТ должна быть нулевой.
Рассмотрим пример. Пусть имеется OSPF-система, физическая структура которой приведена на рис. 5.3.1 (значком с изображением компьютера обозначены хосты).
Рис. 5.3.1. Пример физической структуры OSPF-системы
Граф этой системы выглядит следующим образом (вершины в виде кружков обозначают маршрутизаторы, в виде прямоугольников - тупиковые сети, в виде треугольника - транзитную сеть; ребра графа ориентированные, числа рядом с ребрами - метрики).
Рис. 5.3.2. Граф системы, изображенной на рис. 5.3.1
Если выделенным маршрутизатором сети Т является узел
, то отношения смежности в системе установлены между следующими парами маршрутизаторов: (
,‚
), (
,ƒ
), (
,„
), (‚
,„
), (…
,ƒ
). Эти пары обмениваются между собой сообщениями OSPF для синхронизации копий баз данных.
Маршрутизаторы ‚
и ƒ
не являются смежными, однако они соседи, то есть обмениваются сообщениями "Hello", принимают участие в выборах выделенного маршрутизатора и, разумеется, могут отправлять дейтаграммы непосредственно друг другу. Например, дейтаграмма из ‚
в …
проследует по маршруту ‚
à
ƒ
à
…
, но информацию о том, что такой маршрут возможен, маршрутизатор ‚
получил не от ƒ
(так как они не смежны), а от выделенного маршрутизатора
после того как тот, в свою очередь, получил ее от ƒ
.
Каждый маршрутизатор вставляет в базу данных и контролирует состояние связей, идущих от него к другим маршрутизаторам (двухточечные связи), тупиковым и транзитным сетям. Связи, идущие из транзитной сети (вершина Т), вставляются в базу данных выделенным маршрутизатром
. Связей, идущих из тупиковой сети, существовать не может.
Вершина "транзитная сеть Т" представляет также и хосты, находящиеся в IP-сети Т.
Выборы выделенного маршрутизатора проводятся с помощью протокола Hello (алгоритм выборов описан в п. 5.5.2). Кроме выделенного маршрутизатора выбирается также и запасной выделенный маршрутизатор (backup designated router, BDR), остальные маршрутизаторы сети устанавливают отношения смежности как с DR, так и с BDR (следовательно, в предыдущем пункте при описании отношений смежности не хватает BDR). Все сообщения для DR и BDR посылаются по мультикастинговому адресу 224.0.0.6 "Всем выделенным OSPF-маршрутизаторам".
Запасной выделенный маршрутизатор получает эти сообщения, но не предпринимает никаких действий, связанных со своей выделенной функцией. Однако если выделенный маршрутизатор отключается (этот факт детектируется с помощью протокола Hello), то запасной немедленно становится выделенным, не тратя времени на установление отношений смежности с остальными маршрутизаторами, так как эти отношения уже установлены. При этом с помощью протокола Hello выбирается новый запасной выделенный маршрутизатор. Если бывший выделенный маршрутизатор подключится снова, статус выделенного маршрутизатора ему не возвращается.
В случае, когда несколько OSPF-маршрутизаторов подключены к сети множественного доступа, не поддерживающей широковещательную передачу (NBMA-сеть), они следуют той же процедуре, что и в случае широковещательной сети, поскольку каждый маршрутизатор также может непосредственно связаться с каждым, и, следовательно, существует та же проблема "N2" по числу отношений смежности и числу записей в базе данных состояния связей. В случае NBMA-сетей проблема даже усугубляется тем, что поддержка постоянных соединений между любыми двумя маршрутизаторами для обмена маршрутной информацией (отношения смежности) может потребовать значительных технических и финансовых затрат.
Отличие NBMA от широковещательных сетей состоит в том, что адреса всех соседей должны быть предварительно сконфигурированы на каждом маршрутизаторе, потому что возможности передавать мультикастинговые сообщения нет.
Если маршрутизатор, подключенный к нешироковещательной сети, может непосредственно связаться с несколькими, но не со всеми маршрутизаторами этой сети (неполный множественный доступ), такое соединение конфигурируется как point-to-multipoint и не рассматривается протоколом OSPF как сеть множественного доступа со всеми вышеописанными последствиями. Маршрутизатор, подключенный к соединению типа point-to-multipoint, устанавливает двухточечные связи с каждым своим соседом по соединению (см. также п. 5.5.9).
Могут быть также причины, по которым администратор пожелает сконфигурировать сеть с полным множественным доступом как point-to-multipoint.
Для упрощения вычисления маршрутов и уменьшения размера базы данных состояния связей OSPF-система может быть разбита на отдельные независимые области (areas), объединяемые в единую систему особой областью, называемой магистралью (backbone). Области, не являющиеся магистралью, называются периферийными.
Маршруты внутри каждой области вычисляются как в отдельной системе: база данных состояния связей содержит записи только о связях маршрутизаторов внутри области, действие протокола затопления не распространяется за пределы области.
Некоторые маршрутизаторы принадлежат магистрали и одной или нескольким периферийным областям. Такие маршрутизаторы называются областными пограничными маршрутизаторами (area border router, ABR). Каждая область должна иметь как минимум один ABR, иначе она будет полностью изолирована от остальной части системы.
Областные пограничные маршрутизаторы поддерживают отдельные базы данных состояния связей для всех областей, к которым они подключены. На основании этих данных они обобщают информацию о достижимости сетей внутри отдельных областей и сообщают результат в смежную область. Также ABR обрабатывают подобные сообщения от других ABR (граничащих с другими областями) и ретранслируют информацию о внешних маршрутах, исходящую от пограничных маршрутизаторов (автономной) системы (ASBR).
Тем самым обеспечивается передача маршрутной информации и коннективность между областями. При этом за пределы области передается не полная база данных состояния связей, а просто список сетей этой области, достижимых извне области через данный ABR, вместе с метриками расстояния до этих сетей. Если возможно, адреса сетей агрегируются в общий адрес с более короткой маской. Подобную же информацию, но только о сетях, лежащих за пределами OSPF-системы, распространяют ASBR.
Рассмотрим автономную систему, изображенную на рис. 5.4.1. Кружками обозначены маршрутизаторы, буквами - IP-сети, к которым они подключены.
Рис. 5.4.1. Пример разбиения OSPF-системы на области
Система поделена на три области, из которых область номер 0 (area 0) является магистралью (backbone). Маршрутизаторы
и ‚
являются пограничными маршрутизаторами автономной системы. Маршрутизаторы „
, …
, ˆ
, ‰
- областные пограничные маршрутизаторы. Сети A, B, C, G, K, H принадлежат магистрали. Метрики связей с каждой сетью равны 1.
Рассмотрим содержимое базы данных состояния связей в области 1. В этой базе данных находятся:
1. Записи о связях маршрутизаторов ƒ
, „
, ‡
, ˆ
с сетями D, F, J, источниками которых являются эти маршрутизаторы; на основании этих записей рассчитываются маршруты внутри области 1 (см. также п. 5.5.7, тип 1).
2. Записи о достижимости сетей магистрали (A, B, C, G, K, H); вносятся маршрутизаторами „
и ˆ
на основании вычислений по базе данных магистрали, копию которой каждый из них имеет, так как подключен к магистрали непосредственно. При этом каждый из них объявляет только кратчайшее расстояние от себя каждой сети магистрали для того, чтобы внутренние маршрутизаторы области могли строить маршруты до сетей магистрали в соответствии с этими значениями через тот или иной ABR.
Например, для сети А ABR „
объявит маршрутизаторам области 1 метрику 2, а ˆ
- метрику 3. Маршрутизатор ƒ
не знает, каким маршрутом „
или ˆ
будут отправлять дейтаграммы в сеть А, однако он знает, что от него до узла „
кратчайший маршрут - D c метрикой 1, а до узла ˆ
- маршрут FJ с метрикой 2 (не маршрут DG, потому что G не принадлежит области 1). Следовательно, ƒ
делает вывод, что кратчайший путь в сеть А имеет метрику 3 и проходит через „
, а как достичь маршрутизатора „
, ему известно.
3. Записи о достижимости сетей области 2 (E, I, L); вносятся маршрутизаторами „
и ˆ
на основании метрик расстояний до этих сетей, объявленных в магистраль ABR-маршрутизаторами …
и ‰
. При этом каждый из узлов „
и ˆ
добавляет к этим метрикам длину кратчайшего пути по магистрали от себя до …
и ‰
, после чего для каждой сети области 2 выбирает наименьшее значение и объявляет его в область 1.
Например, …
объявляет в магистраль, что сеть Е достижима через него с метрикой 1, а ‰
- что та же сеть достижима через него с метрикой 3 (маршрут "НЕ" находится за пределами области 2). Маршрутизатор ˆ
получает эти сообщения и вычисляет по своей копии базы данных магистрали, что метрика кратчайшего пути от него до …
равна 2, а до ‰
- 1. Следовательно, расстояние до сети Е от узла ˆ
равно 3, если следовать через …
, и 4, если следовать через ‰
. На основании этого результата ˆ
объявляет в область 1, что сеть Е достижима через него с метрикой 3.
Для внутренних маршрутизаторов области 1 объявления областных пограничных маршрутизаторов о достижимости сетей магистрали и о достижимости сетей области 2 неотличимы по своему виду. И то и другое суть объявления о достижимости сетей автономной системы, не входящих в данную область (см. также п. 5.5.7, тип 3).
4. Записи о достижимости сетей за пределами автономной системы; вносятся маршрутизаторами „
и ˆ
и представляют собой просто ретрансляцию сообщений о внешних маршрутах, распространяемых пограничными маршрутизаторами системы (
и ‚
) (см. также п. 5.5.7, тип 5).
5. Записи о достижимости пограничных маршрутизаторов автономной системы (
и ‚
); вносятся маршрутизаторами „
и ˆ
на основании вычислений по базе данных магистрали, к которой подключены
и ‚
(см. также п. 5.5.7, тип 4). Каждый ABR объявляет кратчайшее расстояние от себя до каждого ASBR, которого он может достичь.
Такие объявления необходимы, так как внутрь области не распространяется информация о маршрутах к маршрутизаторам других областей.
Аналогичным образом строятся базы данных состояния связей в области 2 и в магистрали.
Рассмотрим случай, когда магистраль в результате аварии или изначально оказалась разделенной на две части, связь между которыми может быть установлена только через сети, принадлежащие одной из периферийных областей. На примере нашей автономной системы предположим, что сети B и H перестали функционировать или отсутствуют. Следовательно, связь магистральных сетей А и С, с одной стороны, и К и G, с другой стороны, возможна только через сети E, I, L, не принадлежащие магистрали.
Рис. 5.4.2. Разрыв магистрали
В этом случае между маршрутизаторами …
и ‰
, принадлежащими магистрали, должна быть сконфигурирована виртуальная связь, которая вносится в базу данных состояния связей магистрали с метрикой, равной метрике реального "обходного" пути через область 2, эта метрика в нашем случае равна 3. Таким образом, при расчете маршрутов маршрутизаторы магистрали считают, что …
и ‰
соединены непосредственно друг с другом и связность магистрали восстанавливается.
На каждом из маршрутизаторов …
и ‰
при конфигурировании виртуальной связи указывается его партнер по виртуальной связи и область, через которую проходит реальный маршрут виртуальной связи, такая область называется транзитной. Виртуальная связь считается связью типа "точка-точка", следовательно, маршрутизаторы …
и ‰
устанавливают между собой отношения смежности через эту связь.
Разумеется, при необходимости использовать маршрут, лежащий через виртуальную связь, узел …
должен вместо этого отправлять дейтаграммы узлу †
, который, руководствуясь своей маршрутной таблицей, направит их дальше через область 2, в конце концов они попадут к маршрутизатору ‰
и будут отправлены по назначению. Соответствующие действия при необходимости использовать виртуальную связь предпримет и узел ‰
.
В случае отсутствия виртуальной связи коннективность между сетями А и С, с одной стороны, и сетями G, K и областью 1, с другой стороны, будет отсутствовать, несмотря на существование физического маршрута через область 2. Это связано, например, с тем, что маршрутизатор ‰
подключен к магистрали, следовательно, маршруты до сетей А и С, принадлежащих магистрали, он должен рассчитывать по базе данных магистрали. Однако граф магистрали больше не является связным и сети А и С недостижимы. Несмотря на то, что …
объявляет данные о достижимости сетей А и С в области 2, эти данные используются только внутренними маршрутизаторами области.
Число внешних маршрутов, которые пограничные маршрутизаторы автономной системы объявляют в системе, может быть очень велико, потому что в общем случае эти маршруты должны описывать путь до любой сети в Интернет. Для многих периферийных областей, особенно имеющих только один ABR, знать и обрабатывать все эти маршруты представляется избыточным. Внутренним маршрутизаторам области для отправки данных, адресованных вовне автономной системы, достаточно пересылать их пограничному маршрутизатору области, а тот уже, на основании всей информации о внешних маршрутах, будет принимать решения, через какой из пограничных маршрутизаторов системы отправить эти данные.
Области, внутрь которых не передается информация о внешних маршрутах (см. п. 5.5.7, тип 5), называются тупиковыми областями (stub areas). Все дейтаграммы, исходящие из данной области и адресованные за пределы автономной системы, отправляются по маршруту по умолчанию (default) через определенный ABR. Тупиковая область может иметь несколько ABR, но для каждого узла внутри области установлен маршрут по умолчанию, проходящий только через один их ABR.
Данные о достижимости сетей своей автономной системы объявляются в тупиковую область ее пограничными маршрутизаторами, как и в обычную область. Однако и эта информация может оказаться избыточной (например, если тупиковая область имеет всего один ABR). Тогда маршрут по умолчанию распространяется не только на дейтаграммы, адресованные за пределы автономной системы, но и на дейтаграммы, адресованные за пределы области.
В тупиковой области не могут находиться пограничные маршрутизаторы автономной системы. Через тупиковую область не может проходить виртуальная связь.
Протокол OSPF определяет также понятие не совсем тупиковых областей (not so stubby area, NSSA). К таким областям относятся тупиковые области, в которых разрешено объявлять некоторые внешние маршруты. Рассмотрим автономные системы, изображенные на рис. 5.4.3.
Рис. 5.4.3. Пример NSSA
Толстые стрелки описывают объявление (экспорт) маршрутов, тонкие - сами маршруты.
К области 1, входящей в АС 1, подключена небольшая автономная система 2, маршрутизируемая по RIP. Объявление области 1 как не совсем тупиковой позволяет, с одной стороны, не экспортировать в нее все внешние маршруты, ведущие из АС 1 и объявленные в магистрали, заменив их, как и в тупиковой области, маршрутом по умолчанию (default). С другой стороны, есть возможность сделать исключение, а именно, объявить внутри области 1 внешний маршрут в АС 2 через ASBR
и экспортировать это объявление в остальную часть АС 1 через ABR ‚
.
Внешние маршруты, которые можно объявлять в NSSA, отличаются от остальных внешних маршрутов (которые не объявляются, а сводятся в маршрут по умолчанию) тем, что объявление о них имеет специальный тип (см. п. 5.5.7, тип 7).
Протокол OSPF в стеке протоколов TCP/IP находится непосредственно над протоколом IP, код OSPF равен 89. То есть если значение поля "Protocol" IP-дейтаграммы равно 89, то данные дейтаграммы являются сообщением OSPF и передаются OSPF-модулю для обработки. Соответственно размер OSPF-сообщения ограничен максимальным размером дейтаграммы.
Все сообщения OSPF имеют общий заголовок (следующий в дейтаграмме непосредственно за IP-заголовком):
Значения полей:
Version (1 октет) - версия протокола (=2);
Type (1 октет) - тип сообщения:
1 - Hello;
2 - описание базы данных (Database Description);
3 - запрос состояния связей (Link State Request);
4 - обновление состояния связей (Link State Update);
5 - подтверждение приема сообщения о состоянии связей (Link State Acknowledgment).
Packet length (2 октета) - длина сообщения в октетах, включая заголовок.
Router ID (4 октета) - идентификатор маршрутизатора, отправившего сообщение. Router ID равен адресу одного из IP-интерфейсов маршрутизатора. У маршрутизаторов Cisco это наибольший из адресов локальных интерфейсов, а если таковых нет, то наибольший из адресов внешних интерфейсов.
Area ID (4 октета) - номер области, к которой относится данное сообщение; номер 0 зарезервирован для магистрали. Часто номер области полагают равным адресу IP-сети (одной из IP-сетей) этой области.
Checksum (2 октета) - контрольная сумма, охватывает все OSPF-сообщение, включая заголовок, но исключая поле "Authentication"; вычисляется по тому же алгоритму, что и в IP-заголовке.
Authentication Type (2 октета) - тип аутентификации сообщения. Стандарт определяет несколько возможных типов, самые простые из них: 0 - нет аутентификации, 1 - аутентификация с помощью пароля.
Authentication (8 октетов) - аутентификационные данные; например, восьмисимвольный пароль.
Далее при рассмотрении формата сообщений вышеописанный заголовок будет изображаться в виде поля "OSPF-заголовок", помещенного в начало сообщения.
Значения полей:
Network Mask (4 октета) - маска IP-сети, в которой находится интерфейс маршрутизатора, отправившего сообщение.
Hello Interval (2 октета) - период посылки Hello-сообщений, в секундах.
Options (1 октет) - определено значение нескольких бит:
- БитТ
- установлен à
поддерживается маршрутизация по типу сервиса (этот бит исключен из последней версии стандарта OSPF, но может поддерживаться для совместимости с предыдущими версиями).
- Бит Е
- установлен à
маршрутизатор может принимать и объявлять внешние маршруты через данный интерфейс,
- сброшен à
данный интерфейс маршрутизатора принадлежит тупиковой области.
- Бит MC
- установлен à
маршрутизатор поддерживает маршрутизацию мультикастинговых дейтаграмм (RFC 1584, в этой части пособия не обсуждается).
- Бит N/P
- установлен à
данный интерфейс маршрутизатора принадлежит не совсем тупиковой области (NSSA).
- Бит EA
- установлен à
маршрутизатор может получать и ретранслировать объявления о "внешних атрибутах" (к настоящему моменту описание опции не разработано).
- Бит DC
- установлен à
маршрутизатор поддерживает работу с соединениями, устанавливаемыми по требованию (demand circuits, RFC 1793) - это, например, означает, что записи о связях, устанавливаемых по требованию, не устаревают.
Поле "Options" используется для согласования возможностей маршрутизаторов-соседей (маршрутизатор может прервать соседские отношения, если какие-то опции соседа его не устраивают) и для определения того, какую информацию о состоянии связей не нужно посылать маршрутизатору-соседу, потому что он все равно не сможет ее обработать.
Priority (1 октет) - приоритет маршрутизатора; устанавливается администратором, используется при выборах выделенного маршрутизатора; маршрутизатор с нулевым приоритетом никогда не будет избран.
Dead Interval (4 октета) - время в секундах, по истечении которого маршрутизатор-сосед, не посылающий сообщения Hello, считается отключенным.
Designated Router (DR) (4 октета) - идентификатор выделенного маршрутизатора с точки зрения маршрутизатора, посылающего сообщение (0, если выделенный маршрутизатор еще не выбран).
Backup Designated Router (BDR) (4 октета) - идентификтор запасного выделенного маршрутизатора с точки зрения маршрутизатора, посылающего сообщение (0, если запасной выделенный маршрутизатор еще не выбран).
Neighbor,..., Neighbor - список идентификаторов соседей, от которых получены Hello-сообщения за последние Dead Interval секунд; число полей "Neighbor" определяется из общей длины сообщения, указанной в OSPF-заголовке. Длина одного поля — 4 октета.
После того, как пара маршрутизаторов начинает обмениваться Hello-сообщениями с каким-то соседом, этот процесс проходит через несколько стадий:
DOWN - сосед не обнаружен или отключился;
INIT - послано Hello-сообщение или получено от маршрутизатора, еще не зачисленного в список соседей;
2-WAY (двусторонняя связь) - получено Hello-сообщение, в котором данный маршрутизатор-получатель перечислен в списке соседей, а отправитель этого сообщения также зачислен в список соседей данного маршрутизатора;
WAIT - ожидание в течение Dead Interval секунд для обнаружения всех соседей; в это время маршрутизатор передает Hello-сообщения, но не участвует в выборах выделенного маршрутизатора и в синхронизировании баз данных;
EXSTART - установление ролей главный/подчиненный и инициализация структур данных для обмена описаниями баз данных (протокол обмена);
EXCHANGE - обмен описаниями баз данных (протокол обмена);
LOADING - синхронизация баз данных, пересылка сообщений-запросов о состояниях связей и ответов на них (протокол обмена);
FULL - базы данных синхронизированы.
Каждый маршрутизатор самостоятельно производит выборы выделенного и запасного выделенного маршрутизаторов на основании имеющихся у него данных о соседях и о том, кого каждый из соседей назначил на эту роль. Фактически процесс выборов происходит постоянно, после получения каждого Hello-сообщения, но алгоритм гарантирует, что при стабильном состоянии сети всеми маршрутизаторами будут выбираться одни и те же DR и BDR.
Каждый маршрутизатор может объявить себя либо выделенным, либо запасным, поместив свой идентификатор в соответствующее поле своих Hello-сообщений. Иначе он может поместить туда адреса других маршрутизаторов, если он считает их занимающими соответствующие роли. Если маршрутизатор не определился с выбором DR и (или) BDR (например, после включения), он заполняет соответствующие поля нулями.
Выбор проводится только среди соседей, с которыми установлена двусторонняя связь и приоритет которых не равен нулю; в этот список маршрутизатор включает и себя, если его приоритет не нулевой.
Итак, после получения очередного Hello-сообщения маршрутизатор приступает к выбору DR и BDR. Он помнит мнения своих соседей по поводу того, кто является DR и BDR, которые он узнал из получаемых Hello-сообщений, а также свой собственный предыдущий выбор.
- Сначала выбирается BDR, на эту должность назначается маршрутизатор с наивысшим приоритетом из всех, объявивших себя в качестве BDR, при этом маршрутизаторы, объявившие себя в качестве DR, не рассматриваются. Если никто не объявил себя в качестве BDR, выбирается маршрутизатор с высшим приоритетом из тех, кто не объявил себя в качестве DR. В случае равных приоритетов выбирается маршрутизатор с большим идентификатором.
- На должность DR выбирается маршрутизатор с наивысшим приоритетом из всех, объявивших себя в качестве DR. В случае равных приоритетов выбирается маршрутизатор с большим идентификатором.
- Если никто не предложил себя в качестве DR, в поле "Designated Router" заносится идентификатор BDR.
- Если маршрутизатор только что выбрал себя на роль DR или BDR или только что потерял статус DR или BDR, шаги 1-3 повторяются. Термин "только что" означает "в результате выполнения непосредственно предшествующих шагов 1-3, а не предыдущих итераций алгоритма".
После выбора DR и BDR маршрутизатор сообщает их идентификаторы в своих Hello-сообщениях. Если в результате процедуры выбора DR или BDR изменились по сравнению с предыдущим выбором данного маршрутизатора, он устанавливает необходимые отношения смежности, если они еще не были установлены, и разрывает ненужные больше отношения смежности, если таковые имеются.
Когда маршрутизатор подключается к сети, сначала он достигает состояния 2-WAY со всеми своими соседями, а потом, прежде чем приступать к выборам, ожидает время WAIT. В течение этого времени он передает Hello-сообщения с обнуленными полями DR и BDR. После истечения периода WAIT вновь подключившийся маршрутизатор может предлагать себя на роль BDR , производить выборы и формировать отношения смежности.
Значения полей:
Options (1 октет) - то же, что и в сообщениях Hello.
IMMS (3 бита) - последние 3 бита октета, следующего за полем "Options": I - Initialize, бит 5; M - More, бит 6, MS - Master/Slave, бит 7. Использование этих бит будет описано ниже. Остальная часть октета, где находятся эти биты, обнулена.
DD Sequence number (DDSN) (4 октета) - порядковый номер данного сообщения.
LSA Header (20 октетов) - описание (набор идентификаторов) записи из базы данных состояния связей, представляющее собой заголовок "Объявления о состоянии связей" (см. п. 5.5.5, формат поля "LSA Header" - в п. 5.5.8). В сообщении может присутствовать несколько описаний (полей "LSA Header"), следующих друг за другом; их число определяется из общей длины сообщения, указанной в OSPF заголовке.
Обмен сообщениями "Описание базы данных" происходит при работе протокола обмена (Exchange protocol, см. п. 5.2.2) между двумя смежными маршрутизаторами. Обмен начинается с выяснения, кто из двух маршрутизаторов будет играть главную роль, а кто подчиненную.
Маршрутизатор, желающий начать обмен на правах главного, отправляет пустое сообщение с установленными битами IMMS и произвольным, но не использованным в обозримом прошлом номером DDSN (предлагается использовать время суток). Второй маршрутизатор подтверждает, что согласен играть подчиненную роль: он отправляет обратно также пустое сообщение с тем же DDSN, c установленными битами I и M и сброшенным битом MS.
Если же оба маршрутизатора одновременно решили начать процедуру обмена, то маршрутизатор, получивший в ответ на свое сообщение о начале обмена сообщение второго маршрутизатора о начале обмена вместо подтверждения подчиненной роли, сравнивает адрес второго маршрутизатора со своим. Если свой адрес меньше, маршрутизатор принимает подчиненную роль и отправляет соответствующее подтверждение, иначе принятое сообщение игнорируется.
После того, как роли распределены, начинается обмен описаниями базы данных. Главный отправляет подчиненному сообщения с описаниями своей базы данных; номера DDSN увеличиваются с каждым сообщением, бит I сброшен, бит МS установлен, бит M установлен во всех сообщениях, кроме последнего.
Подчиненный отправляет подтверждения на каждое полученное от главного сообщения. Эти подтверждения представляют собой сообщения того же типа, содержащие описание базы данных подчиненного маршрутизатора. Номер DDSN равен номеру подтверждаемого сообщения, биты I и MS сброшены, бит М установлен во всех сообщениях, кроме последнего.
При неполучении подтверждения от подчиненного в течение некоторого тайм-аута главный посылает сообщение повторно. Если подчиненный получает сообщение с уже встречавшимся номером DDSN, он должен повторить передачу соответствующего подтверждения. Это касается также и фазы инициализации (распределения ролей).
Если один из маршрутизаторов уже передал все данные, он продолжает передавать пустые сообщения со сброшенным битом М, пока другая сторона также не закончит передачу всех данных и не передаст сообщение (или подтверждение) со сброшенным битом М.
На этом процедура обмена описаниями базы данных заканчивается.
Сообщение "Запрос состояния связи" отправляется при работе протокола обмена (см. п. 5.2.2) после того, как был произведен обмен описаниями баз данных.
Сообщение содержит один или несколько идентификаторов записей, которые маршрутизатор хочет получить от своего соседа. Каждый идентификатор записи состоит из полей "Link State Type", "Link State ID" и "Advertising Router"; значения этих полей будут рассмотрены при обсуждении заголовков объявлений о состоянии связей (LSA) в п. 5.5.8. Число идентификаторов (то есть число запросов) в одном сообщении определяется из общей длины сообщения, указанной в OSPF-заголовке.
Подтверждением приема запроса является посылка сообщения типа 4 "Обновление состояния связи". При отсутствии подтверждения в течение некоторого тайм-аута запрос посылается повторно. Если все запросы не могут быть помещены в одно сообщение, они разбиваются на несколько сообщений, но каждое следующее сообщение-запрос посылается только после получения всех записей, запрошенных в предыдущем.
Сообщение "Обновление состояния связей" собственно и содержит информацию из базы данных состояния связей. Это сообщение отправляется в ответ на запрос (тип 3) при работе протокола обмена (см. п. 5.2.2), а также при работе протокола затопления (см. п. 5.2.3) для распространения информации об изменении состояния связей. В последнем случае его получение подтверждается сообщениями типа 5 "Link State Acknowledgment", в случае отсутствия подтверждения посылка повторяется.
Сообщение типа 4 состоит из одного или нескольких объявлений о состоянии связей (Link State Advertisement, LSA), следующих друг за другом. Существует несколько типов LSA. Каждое LSA состоит из заголовка и тела. Типы LSA и их формат будут рассмотрены в следующих пунктах этого раздела (пп. 5.5.7 - 5.5.12).
Число объявлений LSA в сообщении определяется первым 32-битным словом, следующим за OSPF заголовком. Длина каждого LSA определяется соответствующим полем в заголовке LSA. Если все LSA, которые требуется отправить, не помещаются в одно сообщение, они могут быть распределены по нескольким сообщениям.
Дейтаграмма с OSPF сообщением типа 4, несущим 3 LSA, имеет следующую общую структуру:
Сообщения типа 5 отправляются в подтверждение получения сообщений типа 4 при работе протокола затопления. Сообщение содержит одно или несколько подтверждений, каждое подтверждение состоит из заголовка LSA (см. п. 5.5.8), получение которого подтверждается.
Маршрутизатор может не посылать подтверждение на каждое сообщение типа 4, а послать одно сообщение типа 5 с подтверждениями на получение LSA, присланных в нескольких сообщениях типа 4, но в любом случае задержка с посылкой подтверждений не должна быть велика.
Число подтверждений в одном сообщении типа 5 определяется из общей длины сообщения, указанной в OSPF-заголовке.
Тип 1. Router Links Advertisement - маршрутизатор объявляет о своих связях с соседними маршрутизаторами, транзитными и тупиковыми сетями; распространяется каждым маршрутизатором внутри области, к которой принадлежат эти связи.
Тип 2. Network Links Advertisement - содержит список маршрутизаторов, подключенных к сети множественного доступа; распространяется выделенным маршрутизатором внутри области, к которой принадлежит данная сеть. Фактически описывает связи, направленные в графе системы от вершины типа "транзитная сеть" к маршрутизаторам этой сети.
Тип 3. Summary Link Advertisement - описывает расстояние от данного областного пограничного маршрутизатора (ABR) до IP-сети, находящейся за пределами данной области, но принадлежащей данной OSPF-системе; распространяется этим ABR внутри области.
Тип 4. AS Boundary Router Summary Link Advertisement - описывает расстояние от данного ABR до данного пограничного маршрутизатора системы (ASBR); распространяется этим ABR внутри области.
Тип 5. AS External Link Advertisement - описывает расстояние до сети, находящейся за пределами OSPF-системы; распространяется ASBR и ретранслируется во все области, кроме тупиковых, их пограничными маршрутизаторами.
Тип 7. AS External Link Advertisement (NSSA) - то же, что тип 5, но распространяется внутри не совсем тупиковых областей (в них распространение LSA типа 5 запрещено); на границе NSSA и магистрали преобразуется в LSA типа 5 для дальнейшего распространения в системе. Формат идентичен формату LSA типа 5 за исключением номера типа.
Все объявления о состоянии связей (LSA) состоят из заголовка и тела и пересылаются в сообщениях OSPF типа 4 (см. п. 5.5.5), а заголовки отдельно также пересылаются в сообщениях типа 2 и 5 (см. пп. 5.5.3 и 5.5.6 соответственно). Заголовок LSA имеет одинаковый формат для всех типов LSA.
Значения полей:
LS Age (2 октета) - возраст связи (связей), содержащихся в данном LSA (см. выше п. 5.2.3).
Options (1 октет) - содержимое октета аналогично такому же октету в сообщении Hello.
LS Type (1 октет) - тип LSA (см. предыдущий пункт);
Link State ID (4 октета) - идентификатор связи (связей), объявляемых в данном LSA, интерпретация этого поля зависит от типа LSA:
|
Тип LSA |
Link State ID |
|
1 |
то же, что и "Advertising Router" |
|
2 |
IP-адрес интерфейса выделенного маршрутизатора, подключенного к данной сети множественного доступа |
|
3 |
IP-адрес сети, находящейся за пределами области |
|
4 |
идентификатор ASBR
|
|
5 |
IP-адрес сети, находящейся за пределами системы |
Advertising Router (4 октета) - идентификатор маршрутизатора, ответственного за объявление и поддержку связи (связей), содержащихся в данном LSA.
Link State sequence number (4 октета) - порядковый номер (версия) состояния связи (связей), содержащихся в данном LSA. Порядковые номера изменяются от 1-N до N-1, где N=231=2147483648, номер -N не используется. При достижении записью номера N-1 маршрутизатор, ответственный за эту запись, принудительно удаляет ее из базы данных путем присвоения ей максимального возраста (см. п. 5.2.3), после чего заново объявляет ее с начальным номером 1-N.
LS Checksum (2 октета) - контрольная сумма, вычисляется таким же методом, что и контрольная сумма IP-заголовка; защищает как заголовок, так и тело LSA.
length (2 октета) - длина LSA в октетах, включая 20 октетов заголовка LSA.
Значения полей:
VEB (3 бита) - первый октет обнулен за исключением трех старших бит V (бит 5), E (бит 6) и B (бит 7). Установленные значения этих бит говорят о том, что маршрутизатор, объявивший данное LSA, является:
бит B - пограничным маршрутизатором области (ABR);
бит Е - пограничным маршрутизатором системы (ASBR);
бит V - оконечной точкой виртуальной связи.
Число связей (2 октета) - число связей, объявленных в данном LSA.
Объявление о каждой связи состоит из полей "Link ID", "Link Data", "Type", "#TOS", "TOS 0 metric", за которыми может следовать 0 или более 32-разрядных слов, состоящих из полей "TOS", нулевого октета и "TOS metric". Количество таких слов определяется полем "#TOS".
Link ID (4 октета), Link Data (4 октета), Type (1 октет) - интерпретация полей "Link ID" и "Link Data" зависит от значения поля "Type" (ниже в колонке "Link Data" под IP-адресом понимается IP-адрес интерфейса объявляющего маршрутизатора, подключенного к той связи, которую он объявляет):
|
Type |
Link ID |
Link Data |
|
1 - двухточечная связь между маршрутизаторами |
идентификатор соседа |
IP-адрес |
|
2 - связь с транзитной сетью |
IP-адрес интерфейса выделенного маршрутизатора |
IP-адрес |
|
3 - связь с тупиковой сетью (см. также конец этого пункта) |
IP-адрес тупиковой сети |
маска тупиковой сети |
|
4 - виртуальная связь |
идентификатор соседа по магистрали, с которым установлена виртуальная связь |
IP-адрес |
#TOS (1 октет) - число метрик для маршрутизации по типу сервиса для данной связи (0 - метрики для маршрутизации по типу сервиса не определены).
TOS 0 metric (2 октета) - метрика данной связи для маршрутизации без учета типа сервиса (метрика по умолчанию).
TOS (1 октет), TOS metric (2 октета) - метрика данной связи ("TOS metric") для указанного типа сервиса ("TOS"). Число таких метрик определено полем "#TOS" и может быть равно нулю. Значение TOS определяется, как в заголовке IP-дейтаграммы. Несмотря на то, что маршрутизация по типу сервиса исключена из последней версии стандарта OSPF, эти поля поддерживаются для совместимости с предыдущими версиями.
Кроме собственно связей с тупиковыми сетями, следующие связи объявляются как связи с тупиковыми сетями:
- связь с собственным интерфейсом (интерфейсами) типа loopback (Link ID=IP-адрес интерфейса, Link Data заполняется единицами);
- cвязь с хостом, подключенным к маршрутизатору по двухточечной линии (Link ID=IP-адрес хоста, Link Data заполняется единицами);
- связь с сетью, представляющей собой двухточечное соединение между маршрутизаторами (в дополнение к собственно двухточечной связи между маршрутизаторами); в случае, если этой сети не присвоены адрес и маска, Link ID равен IP-адресу интерфейса соседнего маршрутизатора, Link Data заполняется единицами;
- связь с собственным интерфейсом, подключенным к соединению типа point-to-multipoint (в дополнение к двухточечным связям с каждым из соседей, подключенным к этому соединению); Link ID=IP-адрес интерфейса, Link Data заполняется единицами.
Значения полей:
Network Mask (4 октета) - маска сети множественного доступа (адрес этой сети указан в поле "Link State ID" заголовка LSA).
Attached Router (4 октета) - идентификатор маршрутизатора, подключенного к сети множественного доступа. Перечисляются все маршрутизаторы, установившие отношения смежности с выделенным маршрутизатором. Длина списка маршрутизаторов определяется из общей длины LSA, указанной в заголовке LSA.
LSA этого типа описывает связи, направленные в графе системы от вершины типа "транзитная сеть" к маршрутизаторам этой сети. Метрика этих связей не указывается, поскольку она считается равной нулю.
LSA типа 3 или 4 содержит объявление о расстоянии только до одной IP-сети, лежащей за пределами области (до одного пограничного маршрутизатора). Адрес сети или идентификатор маршрутизатора указан в поле "Link State ID" заголовка LSA.
Поле "Network Mask" (4 октета) содержит значение маски сети, если это LSA типа 3, или все единицы, если это LSA типа 4. Далее следует 32-битное слово, два последних октета которого содержат метрику расстояния по умолчанию (тип сервиса 0), после которого может следовать 0 или более 32-битных слов, объявляющих метрики расстояний для маршрутизации по типам сервиса - аналогично тому, как это сделано в LSA типа 1. Несмотря на то, что маршрутизация по типу сервиса исключена из последней версии стандарта OSPF, эти поля поддерживаются для совместимости с предыдущими версиями.
Поле "#TOS" здесь отсутствует, т.к. число объявлений метрик для типов сервиса можно вычислить из общей длины LSA, указанной в заголовке LSA.
LSA типа 3 и 4 распространяются областными пограничными маршрутизаторами как внутри периферийных областей, так и в магистрали. LSA, распространяемые в периферийной области, содержат информацию о достижимости сетей и ASBR, находящихся в магистрали и других периферийных областях. LSA, распространяемые в магистрали, содержат информацию о достижимости сетей и ASBR, находящихся в периферийной области.
Если возможно, адреса нескольких сетей агрегируются в общий адрес с более короткой маской, что уменьшает количество LSA и размер базы данных.
Значения полей:
Network Mask (4 октета) - маска внешней IP-сети. IP-адрес этой сети указан в поле "Link State ID" заголовка LSA.
Далее следует одна или более записей с указанием метрики и других характеристик маршрута до данной сети для разных типов сервиса (поля "E TOS", "TOS metric", "Forwarding Address", "External Route Tag"). Первыми указываются характеристики для TOS=0 (т.е. когда тип сервиса не учитывается), эта часть присутствует обязательно. Число прочих типов сервиса, представленных в LSA, определяется из общей длины LSA, указанной в заголовке LSA. Несмотря на то, что маршрутизация по типу сервиса исключена из последней версии стандарта OSPF, соответствующие поля поддерживаются для совместимости с предыдущими версиями.
E (E TOS) - младший бит октета, содержащего значение TOS (самим значением TOS используются биты 3-6). Имеет следующие значения:
Е установлен à
метрика внешнего маршрута исчисляется в единицах, не сравнимых с исчислением метрик в OSPF (протоколы внешней маршрутизации, поставляющие данные о внешних маршрутах, не обязаны использовать совместимые с OSPF значения метрик); в этом случае метрика, указанная для соответствующего TOS, должна считаться больше любой метрики в OSPF-системе;
Е сброшен à
метрика внешнего маршрута может складываться с метриками внутренних маршрутов.
TOS 0 metric (TOS metric) (2 октета) - метрика для соответствующего значения TOS.
Forwarding Address (4 октета) - адрес маршрутизатора, которому следует пересылать дейтаграммы, адресованные в объявляемую внешнюю сеть. Это поле используется, когда ASBR считает, что он сам - не лучший "следующий маршрутизатор" на пути в данную внешнюю сеть. Например, в одной IP-сети с ASBR находится маршрутизатор G, не поддерживающий протокол OSPF (а поддерживающий, например, BGP), причем через G лежат кратчайшие маршруты к определенным внешним сетям. ASBR, который также поддерживает и BGP, узнаёт от G об этих маршрутах и объявляет их в автономной системе, однако с помощью "Forwarding Address" он тут же указывает, что дейтаграммы, адресованные в эти сети, лучше сразу же направлять маршрутизатору G.
Возможны и другие примеры.
Если поле "Forwarding Address" обнулено, то дейтаграммы следует пересылать тому ASBR, который объявил данное LSA.
External Route Tag (4 октета) - поле, используемое ASBR для целей внешней маршрутизации; модулем OSPF игнорируется.
Если возможно, адреса нескольких внешних сетей агрегируются в общий адрес с более короткой маской, что уменьшает количество LSA и размер базы данных.
Протокол OSPF гораздо сложнее протокола RIP, но следует помнить, что маршрутизация является критически важной задачей для сетей TCP/IP. Благодаря использованию более совершенного алгоритма протокол OSPF работает в сетях любой сложности и не имеет ограничений и побочных эффектов протокола RIP. При этом время, используемое на построение таблицы маршрутов, и нагрузка на сеть для передачи служебной информации в среднем меньше по сравнению с тем, что потребовал бы RIP для такой же системы. (Например, при стабильной конфигурации системы маршрутная информация рассылается модулем OSPF каждые 30 минут, а модулем RIP - каждые 30 с.)
Кроме того, OSPF предлагает дополнительные возможности для оптимизации процесса построения маршрутов в системе. Во-первых, это специальная трактовка сетей множественного доступа, во-вторых, возможность разбить систему на области различного типа (обычные, тупиковые, не совсем тупиковые). Также разработаны и разрабатываются другие расширения протокола, не описанные выше.
Основная документация по протоколу OSPF содержится в следующих источниках:
RFC-2328 — стандарт протокола OSPF, версия 2 (RFC-1247, 1583, 2178 - предыдущие версии OSPF-2, RFC-1131 - описание OSPF-1);
RFC-1587 — работа с NSSA;
RFC-1584 — расширения OSPF для мультикастинговой маршрутизации (см. также RFC-1585);
RFC-1586 — рекомендации для работы OSPF поверх Frame Relay.
RFC-1793 — расширения OSPF для работы с соединениями, устанавливаемыми по требованию (demand circuits);
RFC-1850 — дополнения к MIB (Management Infomation Base) для объектов протокола OSPF.
Конфигурирование OSPF-маршрутизатора потребует, как минимум, следующих шагов:
- указать связи, которые будут включены в OSPF-систему; если это широковещательные сети, то указать адреса этих сетей; в случае нешироковещательных сетей и двухточечных связей указать адреса возможных соседей;
- если требуется, указать тип cоединения (двухточечный, point-to-multipoint);
- если есть разбиение на области, для каждой связи указать номер области и ее тип;
- если требуется, сконфигурировать виртуальные связи;
- сконфигурировать внешние маршруты или организовать их получение от протоколов внешней маршрутизации, или установить маршрут по умолчанию - на пограничных маршрутизаторах системы.
Могут возникнуть также и другие задачи, связанные со спецификой системы.
THE END
Оглавление учебного пособия
(С) Максим Мамаев
m2@vvsu.ru
