Перевод RFC 2328

Network Working Group Request for Comments: 2328 STD: 54

Obsoletes: 2178 Category: Standards Track

J. Moy Ascend Communications, Inc.

April 1998

Протокол OSPF версии 2

OSPF Version 2

Статус документа

Этот документ содержит спецификацию протокола для сообщества Internet и служит запросом для дальнейшего обсуждения и предложений в целях совершенствования протокола. Точные сведения о статусе документа можно найти в Internet Official Protocol Standards ( STD 1 ). Документ может распространяться свободно.

Авторские права

Тезисы

Этот документ описывает вторую версию OSPF – протокола маршрутизации на основе состояний каналов (link-state routing protocol). Протокол предназначен для использования внутри автономных систем (AS). Все OSPF-маршрутизаторы поддерживают идентичные базы данных с описанием топологии AS. На основании данных из базы рассчитывается маршрут путем конструирования дерева кратчайшего пути.

При изменении топологии OSPF быстро пересчитывает маршруты и не порождает значительного трафика при обновлении маршрутной информации. Протокол OSPF обеспечивает поддержку множества путей с одинаковой стоимостью (equal-cost multipath). Поддерживается «маршрутизация областей» (area routing), обеспечивающая дополнительный уровень защиты маршрутизации и снижение служебного трафика при обмене маршрутной информацией. Кроме того, обмен маршрутной информацией осуществляется с использованием средств аутентификации.

Различия между этим документом и RFC 2178 рассмотрены в Приложении G. Все изменения протокола обеспечивают обратную совместимость.

Реализации описываемого протокола совместимы (интероперабельны) с реализациями RFC 2178, RFC 1583 и RFC 1247.

Комментарии к данному документу направляйте по адресу ospf@gated.cornell.edu.

Оглавление

............................................................................................................................................................... ...................... 1

....................................................................................................................................................................... ..... .... ...... 1

........................................................................................................................................................... ....... ..................... 3

1.1. Обзор протокола ............................................................................................................................................................................... ..3...

1.2. Терминология .................................................................................................................................................................................. ........4. .

1.3. Краткая история маршрутизации на базе состояния каналов ................................................................................................... ..... 5

1.4. Структура документа ...................................................................................................................................................................... ..... 5. .

1.5. Благодарности ........................................................................................................................................................... ... ........................... 6

2. База данных Link-state: структура и расчеты ................................................................................................................................. ........... 6

2.1. Представление маршрутизаторов и сетей ...................................................................................................................................... ....6. .

2.1.1. Представление сетей без широковещания .................................................................................................................... ........... 7

2.1.2. Пример базы данных о каналах ..................................................................................................................................... ............. 7

2.2. Дерево кратчайших путей .............................................................................................................................................................. ....9...

2.3. Внешние данные ................................................................................................................................................................................ ...9...

2.4. Множество равноценных путей ......................................................................................................................................... .............. 10

3. Деление AS на области ........................................................................................................................................................ ....... .................. 10

3.1. Магистраль AS ................................................................................................................................................................................... 1..0...

3.2. Маршрутизация между областями .............................................................................................................................................. ..... 1. 0

3.3. Классификация маршрутизаторов ............................................................................................................................................. ...... 11

3.4. Пример конфигурации областей ............................................................................................................................................... ....... 12

3.5. Поддержка подсетей IP .................................................................................................................................................. ...... .. ............. 13

3.6. Поддержка «тупиковых» областей ........................................................................................................................................ .......... 14

3.7. Разделение областей .................................................................................................................................................... ..... .. ................. 14

4. Основные функции ............................................................................................................................................................ ......................... 14

4.1. Междоменная маршрутизация ..................................................................................................................................................... ....1..5

4.2. Внешние маршруты AS ..................................................................................................................................................................... 1. .5...

4.3. Пакеты протокола маршрутизации ............................................................................................................................................. ..... 1. 5

4.4. Основные требования к реализации....

4.5. Дополнительные возможности OSPF..

5. Структуры данных протокола ......................

6. Структура данных области ...........................

7. Организация отношений смежности ...........

rfc.com.ru

.....................................16

......................................17

..................................17

................................18

.....................................19

rfc.com.ru

Перевод RFC 2328

7.1. Протокол Hello ........................................................................................................................................................................... ..... ...19

7.2. Синхронизация баз данных .......................................................................................................................................... ..................... 19

7.3. Выделенный маршрутизатор DR ................................................................................................................................................. ....2. 0

7.4. Резервный маршрутизатор DR ........................................................................................................................................................ .2..0...

7.5. Граф смежности ................................................................................................................................................................................ .2..1....

8. Обработка пакетов протокола ................................................................................................................................................... ................ 21

8.1. Передача пакетов .................................................................................................................................................................. ............. 21

8.2. Прием пакетов протокола .............................................................................................................................................................. ......2. .2.

9. Структура данных интерфейса .......................................................................................................................................................... ........23

9.1. Состояния интерфейса ............................................................................................................................................................... ....... 24

9.2. События, изменяющие состояние интерфейса ....................................................................................................................... ........ 25

9.3. Машина состояний интерфейса ....................................................................................................................................................... 25

9.4. Назначение DR ................................................................................................................................................................................ ....2. .6. .

9.5. Передача пакетов Hello .......................................................................................................................................... ........................... 27

9.5.1. Передача пакетов Hello в сети NBMA ............................................................................................................................. ......27

10. Структура данных Neighbor ................................................................................................................................................................. ..2. .8...

10.1. Состояния соседей ............................................................................................................................................................ ............... 29

10.2. События, меняющие состояние соседа ....................................................................................................................... .................. 30

10.3. Машина состояний Neighbor .......................................................................................................................................................... 3..0....

10.4. Когда организуется смежность ................................................................................................................................................. ..... 32

10.5. Прием пакетов Hello .................................................................................................................................................................. ..... 3. .2

10.6. Прием пакетов DD .......................................................................................................................................................... ..... ............... 33

10.7. Прием пакетов Link State Request ................................................................................................................................ ..... .............. 34

10.8. Передача пакетов DD .................................................................................................................................................... ..... .. ............. 34

10.9. Передача пакетов Link State Request .............................................................................................................................. ....... ........... 35

10.10. Пример ....................................................................................................................................................................... ...................... 35

11. Структура таблицы маршрутов ............................................................................................................................................................ ....3..5..

11.1. Просмотр таблицы маршрутов ................................................................................................................................. ..... .................... 36

11.2. Пример таблицы маршрутизации без областей ............................................................................................................................ 37

11.3. Пример таблицы маршрутизации с областями ............................................................................................................................ 3. 7

12. Анонсы состояния каналов (LSA) .................................................................................................................................................. ........ 38

12.1. Заголовок LSA ............................................................................................................................................................. ..................... 38

12.1.1. Возраст LS ...................................................................................................................................................................... ......... 38

12.1.2. Опции ...................................................................................................................................................................................... ..3. .9....

12.1.3. Тип LS ................................................................................................................................................................................ .......3. .9

12.1.4. Link State ID ............................................................................................................................................................................. 3. 9

12.1.5. Анонсирующий маршрутизатор ............................................................................................................................ ..... .. ........... 39

12.1.6. Порядковый номер LS .......................................................................................................................................... ................... 39

12.1.7. Контрольная сумма LS ......................................................................................................................................... .................. 40

12.2. База данных link-state .......................................................................................................................................................... ..... .......... 40

12.3. Представление TOS ............................................................................................................................................................ .............. 40

12.4. Генерация LSA ............................................................................................................................................................................ ..... .4..1

12.4.1. LSA для маршрутизатора ............................................................................................................................... ..... ..................... 42

12.4.1.1. Описание интерфейсов point-to-point ................................................................................................................. ......... 42

12.4.1.2. Описание интерфейсов в широковещательные и NBMA-сети ................................................................................. .4..2

12.4.1.3. Описание виртуальных соединений ..................................................................................................................... ........ 43

12.4.1.4. Описание интерфейсов Point-to-MultiPoint .................................................................................................. ................ 43

12.4.1.5. Примеры router-LSA ...................................................................................................................................................... .4..3...

12.4.2. LSA для сети ............................................................................................................................................................................ 4. 4

12.4.2.1. Примеры network-LSA .................................................................................................................................... .. ................ 44

12.4.3. Summary-LSA ............................................................................................................................................................ ............... 44

12.4.3.1. Генерация summary-LSA в тупиковые области ........................................................................................................ ...4. 5

12.4.3.2. Примеры summary-LSA ......................................................................................................................................... ......... 45

12.4.4. AS-external-LSA .................................................................................................................................................... ..... .... ............ 46

12.4.4.1. Примеры AS-external-LSA ............................................................................................................................................ ..4. .6. .

13. Процедура лавинной рассылки (Flooding) .................................................................................................................................. .... ........ 47

13.1. Сравнение возраста LSA ............................................................................................................................................................. ....4. .7.

13.2. Инсталляция LSA в базу данных .................................................................................................................................................. .4..8.

13.3. Следующий этап лавинной рассылки ...................................................................................................................................... ...... 48

13.4. Прием собственных (self-originated) LSA ................................................................................................................. ..................... 49

13.5. Передача LSA ............................................................................................................................................................................ ..... .....49

13.6. Повторная передача LSA .......................................................................................................................................................... ........50

13.7. Подтверждение приема состояния канала ............................................................................................................................ ........ 50

14. Старение базы данных LS ................................................................................................................................................... ..................... 50

14.1. Принудительное старение LSA ......................................................................................................................................... ............. 51

15. Виртуальные соединения ..................................................................................................................................................... ....... ............... 51

16. Расчет таблицы маршрутизации ................................................................................................................................................. ............ 52

16.1. Расчет кратчайшего пути для области .................................................................................................................................. ..... ...... 52

16.1.1. Расчет next hop ..................................................................................................................................................... ....... ................ 54

16.2. Расчет междоменных маршрутов ................................................................................................................................................. .5..4.

16.3. Просмотр summary-LSA от транзитных областей ................................................................................................................... ....5. 5

16.4. Расчет внешних маршрутов AS ............................................................................................................................................ ......... 56

16.4.1. Предпочтения для внешнего пути ...................................................................................................................................... ....5..6

16.5. Нарастающие обновления – summary-LSA ........................................................................................................................... ........ 56

16.6. Нарастающие обновления – AS-external-LSA .......................................................................................................................... ....5. 7

16.7. События, генерируемые при изменении таблицы маршрутов ....................................................................................... ............ 57

16.8. Множество равноценных путей .................................................................................................................................. .................... 57

Литература ................................................................................................................................................................................................. ..... .5..7

rfc.com.ru 2 rfc.com.ru

Перевод RFC 2328

A. Форматы данных OSPF ........................................................................................................................................................................... 5...9...

A.1 Инкапсуляция пакетов OSPF .................................................................................................................................................. ......... 59

A.2 Поле Options .............................................................................................................................................................. ......................... 59

A.3 Форматы пакетов OSPF ............................................................................................................................................................. ....... 59

A.3.1 Заголовок пакета OSPF ............................................................................................................................................................ ..6..0...

A.3.2 Пакет Hello .............................................................................................................................................................................. .6..0....

A.3.3 Пакет Database Description ...................................................................................................................................................... 61

A.3.4 Пакет Link State Request ...................................................................................................................................... ..................... 61

A.3.5 Пакет Link State Update ..................................................................................................................................................... ..... ...61

A.3.6 Пакет Link State Acknowledgment .......................................................................................................................... .................. 62

A.4 Форматы LSA ....................................................................................................................................................... ...... .......................... 62

A.4.1 Заголовок LSA .......................................................................................................................................................................... 6. .2...

A.4.2 Router-LSA ................................................................................................................................................................ .................. 63

A.4.3 Network-LSA ..................................................................................................................................................... ........ ..................... 64

A.4.4 Summary-LSA ............................................................................................................................................................................ .6..4

A.4.5 AS-external-LSA ............................................................................................................................................................. .. ............ 64

B. Архитектурные константы ................................................................................................................................................... ...... .. .............. 65

C. Настраиваемые константы .............................................................................................................................................................. ......... 66

C.1 Глобальные параметры ................................................................................................................................................................ ...... 6. 6

C.2 Параметры области ................................................................................................................................................................. ........... 66

C.3 Параметры интерфейса маршрутизатора ............................................................................................................................. ........... 66

C.4 Параметры виртуального канала ............................................................................................................................................ ......... 67

C.5 Параметры сетей NBMA .................................................................................................................................................. ................. 68

C.6 Параметры сетей Point-to-MultiPoint ........................................................................................................................................... ....6. .8

C.7 Параметры Host route ........................................................................................................................................................................ 6. .8. .

D. Аутентификация ...................................................................................................................................................................................... ....6. .8...

D.1 Null-аутентификация ............................................................................................................................................................ ............. 68

D.2 Парольная аутентификация ..................................................................................................................................... ........................... 68

D.3 Криптографическая аутентификация ....................................................................................................................................... ....... 69

D.4 Генерация сообщений .................................................................................................................................................................... ...6...9.

D.4.1 Генерация Null-аутентификации ........................................................................................................................................ ...... 69

D.4.2 Генерация простой парольной аутентификации ................................................................................................................. ...7. .0

D.4.3 Генерация криптографической аутентификации ............................................................................................................... .....70

D.5 Верификация сообщений ............................................................................................................................................. ...................... 70

D.5.1 Проверка Null-аутентификации ........................................................................................................................... ..... .. ............... 70

D.5.2 Проверка простой парольной аутентификации ............................................................................................................ .......... 70

D.5.3 Проверка криптографической аутентификации ............................................................................................................. ........ 70

E. Алгоритм установки Link State ID ....................................................................................................................................................... ......7..1

F. Множество интерфейсов в одну сеть/подсеть ...................................................................................................................................... ...7..1.

G. Отличия от RFC 2178 ....................................................................................................................................................................... ......... 72

G.1 Изменение лавинной рассылки ..................................................................................................................................................... ...7..2.

G.2 Смена предпочтений для внешнего пути ................................................................................................................................. ....... 72

G.3 Неполное разрешение виртуальных next hop ............................................................................................................................... ..7..2.

G.4 Просмотр таблицы маршрутизации ........................................................................................................................... ....................... 72

Вопросы безопасности ............................................................................................................................................................. ....................... 72

Адреса авторов ................................................................................................................................................................................ ....... ........... 72

Полное заявление авторских прав ............................................................................................................................................... ................. 73

1. Введение

Этот документ содержит спецификацию протокола OSPF (Open Shortest Path First – по самому короткому пути), служащего для маршрутизации трафика TCP/IP. Протокол OSPF относится к числу внутренних протоколов маршрутизации (Interior Gateway Protocol или IGP) – это означает, что маршрутная информация распространяется между маршрутизаторами одной автономной системы AS. Протокол OSPF работает на основе технологии SPF (link-state – по состоянию канала) в отличие от алгоритмов Bellman-Ford, используемых традиционными протоколами маршрутизации TCP/IP.

Протокол OSPF подготовлен одноименной рабочей группой IETF и предназначен для использования в средах TCP/IP. Протокол включает явную поддержку CIDR и установки меток (tagging) при использовании внешней маршрутной информации. OSPF использует аутентификацию и групповую адресацию (IP multicast) при обмене маршрутными сообщениями. Кроме того, при разработке протокола были приложены значительные усилия по ускорению обработки топологических изменений в сети и снижению уровня служебного трафика.

1.1. Обзор протокола

OSPF обеспечивает маршрутизацию пакетов IP исключительно на основе IP-адресов получателей, определенных из заголовка пакетов IP. Пакеты IP маршрутизируются без их изменения (as is), т. е., не используется инкапсуляция в какие-то иные пакеты. OSPF является динамическим протоколом маршрутизации, обеспечивающим быстрое обнаружение топологических изменений в AS (например, сбои маршрутизаторов или каналов) и расчет новых беспетлевых (loop-free) маршрутов. Период схождения (convergence) – расчет нового маршрута – достаточно короток и уровень служебного трафика невелик.

В протоколах на основе состояния каналов (link-state) каждый маршрутизатор поддерживает базу данных с описанием топологии AS. Эти базы называют базами данных о состоянии каналов¹ (link-state database). Базы данных всех маршрутизаторов идентичны. Каждый элемент базы данных представляет собой локальное состояние отдельного маршрутизатора (например, поддерживаемые интерфейсы или доступные соседи). Маршрутизаторы распространяют информацию о своем локальном состоянии путем лавинной маршрутизации (flooding).

¹ Для краткости в переводе используется термин «база данных о каналах» или «база каналов». Прим. перев.

rfc.com.ru 3 rfc.com.ru

Перевод RFC 2328

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

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

OSPF позволяет группировать сети – такие группы называют областями (area). Топология области невидима для остальной части AS. Такое сокрытие (избыточной) информации позволяет существенно снизить уровень служебного трафика. Кроме того, маршрутизация внутри области определяется исключительно внутренней топологией этой области, что обеспечивает защиту областей от использования некорректной маршрутной информации. Понятие области является обобщением подсетей IP.

OSPF обеспечивает возможность гибкой настройки подсетей IP. Каждый маршрут в OSPF распространяется с указанием адресата и маски подсети. Две разных подсети одной сети IP могут иметь различные размеры (т. е., разные маски) – для обозначения этого обычно используется термин variable length subnetting (переменный размер подсетей). Пакеты маршрутизируются по пути с наилучшим (т. е., самым длинным или более конкретным) соответствием. Маршруты к хостам рассматриваются как пути в подсети с маской из одних единиц (all ones или 0xffffffff ²).

Весь обмен информацией OSPF осуществляется с использованием аутентификации. Это означает, что в маршрутизации внутри AS могут участвовать только уполномоченные маршрутизаторы. Могут использоваться различные схемы аутентификации; в частности, допустимо применение различных схем для каждой подсети IP.

Внешние маршрутные данные (т. е., маршруты, полученные от протоколов внешних шлюзов EGP - например, BGP - [Ref23]) анонсируются через AS. Такие данные сохраняются отдельно от данных OSPF о состоянии каналов. Каждый внешний маршрут может также быть помечен (tagged) анонсирующим его маршрутизатором – это дает возможность передачи дополнительной информации между маршрутизаторами на границе AS.

1.2. Терминология

В этом параграфе приведены определения терминов, имеющих специфическое толкование в контексте протокола OSPF и используемых в тексте. Читателям, не знакомым со стеком протоколов Internet рекомендуется обратиться к работе [Ref13], содержащей вводную информацию по протоколу IP.

Router (маршрутизатор)

Устройство сетевого уровня для пересылки пакетов IP. В литературе прошлых лет для обозначения маршрутизаторов часто использовался термин gateway (шлюз).

Autonomous System (автономная система)

Группа маршрутизаторов, обменивающихся маршрутной информацией на основе общего протокола. Используется также сокращение AS.

Interior Gateway Protocol (протокол внутренней маршрутизации)

Протокол маршрутизации, используемый в пределах одной автономной системы. Для обозначения таких протоколов часто используется аббревиатура IGP. Каждая AS имеет один протокол IGP. В разных автономных системах могут использоваться различные протоколы IGP.

Router ID (идентификатор маршрутизатора)

32-битовое целое число, связываемое с каждым маршрутизатором, использующим протокол OSPF. Этот идентификатор является уникальным в масштабе AS.

Network (сеть)

В контексте документа термин сеть может относиться к сети/подсети/»сети сетей» IP (network/subnet/supernet). Одна физическая сеть может включать множество сетей/подсетей IP – мы будем рассматривать их как разные сети. Физические сети «точка-точка» (point-to-point) являются исключением – такая сеть рассматривается как единое целое, независимо от наличия в ней отдельных сетей/подсетей IP.

Network mask (маска сети)

32-битовое число, показывающее диапазон IP-адресов, относящихся к одной сети/подсети/сети сетей IP. В данной

спецификации маски указываются шестнадцатеричными числами.

Например, маска сети класса C имеет значение 0xffffff00. Обычно для записи такой маски используют форму 255.255.255.0.

Point-to-point networks (сеть на базе соединений точка-точка)

Сеть, соединяющая между собой 2 маршрутизатора. Примером таких сетей являются сети на основе каналов 56 кбит/с.

Broadcast networks (широковещательные сети)

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

Соседние маршрутизаторы в таких сетях обнаруживаются динамически с использованием протокола OSPF Hello. Протокол Hello использует преимущества широковещательной передачи. Протокол OSPF может также использовать групповую адресацию (multicast), если она поддерживается. Предполагается, что каждая пара маршрутизаторов в широковещательной сети может обмениваться данными напрямую. Примером широковещательных сетей может служить Ethernet.

Non-broadcast networks (сети без широковещания)

Сети, поддерживающие множество (более 2) подключенных маршрутизаторов, но не имеющие возможностей широковещательной передачи. Для обнаружения соседних маршрутизаторов также используется протокол OSPF Hello, однако, в силу отсутствия широковещания, для обнаружения соседей требуются некоторые настройки. В сетях без широковещания пакеты OSPF, обычно передаваемые с использованием групповой адресации, должны адресоваться непосредственно соседним маршрутизаторам. Примером сетей без широковещания могут служить сети X.25. Протокол OSPF в сетях без широковещания может работать в двух режимах. Первый режим называется NBMA (non-broadcast multi-access – множественный доступ без широковещания) имитирует работу OSPF в широковещательных сетях. Второй режим называется Point-to-MultiPoint (один со многими), в этом случае сеть без широковещания трактуется как множество соединений «точка-точка»³. Сети без широковещания мы будем делить на сети NBMA и Point-to-MultiPoint в зависимости от режима работы OSPF.

Interface (интерфейс)

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

² 255.255.255.255. Прим. перев.

³ Далее для краткости будем называть такие соединения парными. Прим. перев.

rfc.com.ru 4 rfc.com.ru

Перевод RFC 2328

адрес IP и маску, если этот интерфейс не относится к безадресным (unnumbered) соединениям point-to-point. Применительно к интерфейсу может также употребляться термин соединение, канал (link).

Neighboring routers (соседние маршрутизаторы)

Два маршрутизатора, имеющие интерфейсы в общую сеть. Отношения соседства поддерживаются и детектируются (обычно автоматически) с помощью протокола OSPF Hello.

Adjacency (смежность)

Отношения между соседними маршрутизаторами, организуемые в целях обмен маршрутной информацией. Не всякая пара соседних маршрутизаторов поддерживает отношения смежности.

Link state advertisement (анонс состояния канала)

Единица данных, описывающая состояние маршрутизатора или сети. Для маршрутизатора анонс включает состояние интерфейсов и отношения смежности. Каждый анонс рассылается с использованием лавинной маршрутизации в масштабах домена маршрутизации. Анонсы состояний всех маршрутизаторов и сетей формируют базу данных о каналах, используемую протоколом. В настоящем документе для обозначения анонсов состояния канала используется аббревиатура LSA.

Hello Protocol (протокол приветствия)

Часть протокола OSPF, используемая для организации и поддержки отношений соседства между маршрутизаторами. В широковещательных сетях протокол Hello может служить для динамического обнаружения соседних маршрутизаторов.

Flooding (лавинная маршрутизация)

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

Designated Router (указанный маршрутизатор)

Каждая широковещательная или NBMA-сеть, в которой есть не менее двух маршрутизаторов, имеет среди них выделенный -Designated Router (DR). Выделенный маршрутизатор генерирует анонсы LSA для сети и выполняет другие специальные действия для обеспечения работы протокола. Маршрутизатор DR задается протоколом Hello.

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

Lower-level protocols (протоколы нижележащих уровней)

Протоколы нижележащих уровней, предоставляющих свои услуги протоколу IP и OSPF. Примерами таких протоколов могут служить X.25 или протоколы канального уровня Ethernet.

1.3. Краткая история маршрутизации на базе состояния каналов

OSPF относится к числу протоколов маршрутизации на основе данных о состоянии каналов. Такие протоколы также называют протоколами на базе SPF или протоколами с распределенной базой данных (distributed-database protocol). В этом параграфе приведено краткое описание технологии link-state в контексте ее влияния на протокол OSPF.

Первый протокол маршрутизации по состоянию каналов был разработан для использования в сети ARPANET, работавшей на основе коммутации пакетов. Этот протокол описан в работе [Ref3]. Протокол послужил отправной точкой для разработки всех остальных протоколов link-state. Гомогенная среда ARPANET, содержащая однотипные коммутаторы, соединенные синхронными последовательными каналами, существенно упростила разработку и реализацию первого варианта протокола.

В работе [Ref4] был предложен измененный вариант этого протокола. Изменения позволили повысить устойчивость протокола маршрутизации к сбоям – к таким изменениям относится, прежде всего, добавление контрольных сумм LSA, позволяющее детектировать повреждения баз данных. В этой работе также были предложены способы снижения уровня служебного трафика протокола link-state за счет использования механизма, позволяющего увеличить на порядок интервал между последовательными передачами LSA.

Алгоритм link-state был также предложен для использования в качестве протокола маршрутизации ISO IS-IS, описанного в работе [Ref2]. Этот протокол обеспечивал методы снижения трафика при работе в широковещательных сетях за счет введения выделенного маршрутизатора DR для каждой широковещательной сети. Этот маршрутизатор обеспечивает генерацию LSA для своей сети.

Рабочая группа IETF OSPF продолжила разработки в этом направлении, создав протокол OSPF. Концепция выделенного маршрутизатора DR была существенно доработана, что позволило добиться дополнительного снижения служебного трафика. Дополнительное снижение расхода полосы было обеспечено также за счет использования групповой адресации. Была разработана схема областей маршрутизации (area routing), обеспечивающая защиту информации, ее сокрытие и сокращение объема. И, наконец, алгоритмы были приспособлены для использования в межсетевой среде TCP/IP.

1.4. Структура документа

В трех первых разделах документа приведен общий обзор возможностей протокола и его функций. Главы 4 - 16 содержат детальное описание различных механизмов работы протокола. Формат пакетов, константы и элементы настройки описаны в приложениях.

Метки типа HelloInterval, встречающиеся в тексте, обозначают константы протокола, которые могут иметь фиксированные или настраиваемые значения. Архитектурные константы описаны в Приложении B, а настраиваемые константы – в Приложении C.

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

1.5. Благодарности

Автор выражает свою признательность Ran Atkinson, Fred Baker, Jeffrey Burgan, Rob Coltun, Dino Farinacci, Vince Fuller, Phanindra Jujjavarapu, Milo Medin, Tom Pusateri, Kannan Varadhan, Zhaohui Zhang и остальным участникам рабочей группы OSPF за их идеи и поддержку проекта.

Интерфейс OSPF Point-to-MultiPoint основан на результатах работы Fred Baker.

Средства криптографической аутентификации OSPF Cryptographic Authentication разработали Fred Baker и Ran Atkinson.

2. База данных Link-state: структура и расчеты

В следующих параграфах описана организация базы данных о каналах протокола OSPF и расчеты маршрутов, выполняемые для заполнения таблиц маршрутизации.

rfc.com.ru 5 rfc.com.ru

Перевод RFC 2328

2.1. Представление маршрутизаторов и сетей

База каналов AS описывается направленным графом. Вершины графов показывают маршрутизаторы и сети. Ребро графа соединяет два маршрутизатора, если между ними существует физическая сеть point-to-point. Ребро графа соединяет два маршрутизатора с сетью, если маршрутизатор имеет интерфейс в данную сеть. Сеть может быть транзитной или оконечной (stub). Транзитные сети могут также передавать трафик, который не связан с данной сетью, т. е., отправитель и получатель принадлежат другим сетям. Транзитные сети представляются вершинами графов, имеющими входящее и исходящее ребро. Вершины графов для оконечных сетей имеют только входящее ребро.

Соседство каждого сетевого узла на графе зависит от типа сети (point-to-point, широковещательная, NBMA или Point-to-MultiPoint) и числа маршрутизаторов, имеющих интерфейс в данную сеть. На рисунке 1a показано три варианта. Прямоугольники представляют маршрутизаторы, круги и эллипсы – сети. В обозначениях маршрутизаторов используется префикс RT, для сетей – префикс N. Интерфейсы маршрутизаторов именуются с префиксом I. Линии между маршрутизаторами показывают сети point-to-point. В левой части рисунка показаны сети с подключенными к ним маршрутизаторами, а справа приведено представление в виде графов.

От узла


		RT1			RT2
К	RT1 RT2	X		_______X_______
узл	Ia			X
у oint-to К	Ib -point RT7 N3	X	От узла
узл у	Ib -point RT7 N3	RT7 X			N3_______

RT1

RT2

RT7

Оконечные сети


RT3		RT4

*<^z^z^*	N2		^^^^

RT5		RT6


		RT4	От узла
	RT3	RT4	RT5	RT6	N2
RT3 RT4					Х Х
RT5					Х
RT6 N2	Х	Х	Х	Х	Х

узл у

Широковещательные и NBMA-сети

Рисунок 1a. Компоненты представления сетей.

Сети и маршрутизаторы представлены вершинами графа. Ребро графа соединяет вершину A с вершиной B, если на пересечении

колонки A и строки B поставлен знак X. В верхней части рисунка 1a показаны два маршрутизатора, соединенные каналом «точка-точка». В результирующем графе базы данных вершины двух маршрутизаторов напрямую соединены парой ребер (по одному ребру в каждом направлении). Интерфейсы сетей point-to-point могут работать без IP-адресов. Когда интерфейсу присваивается адрес, он представляется как оконечное соединение (stub link) и каждый маршрутизатор анонсирует такое соединение по адресам других интерфейсов маршрутизатора. В дополнение к адресу с парным соединением может быть связана подсеть IP. В таких случаях оба маршрутизатора анонсируют stub-соединение с подсетью IP взамен анонса IP-адреса интерфейса

В средней части рисунка 1a показана сеть с единственным подключенным маршрутизатором (т. е., оконечная сеть - stub network). В этом случае сеть появляется как окончание stub-соединения в графе базы каналов.

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

Каждая сеть (оконечная или транзитная) на графе имеет IP-адрес и связанную с ним маску подсети. Маска показывает число узлов в сети. Хосты, напрямую подключенные к маршрутизатору (в этом случае говорят о маршруте к хосту - host route) появляются на графе как оконечные сети. Маска подсети для маршрутов к хостам всегда имеет значение 0xffffffff, показывающее, что в подсети присутствует единственный узел.

2.1.1. Представление сетей без широковещания

Как было отмечено выше, протокол OSPF может работать в сетях без широковещания в одном из двух режимов - NBMA или Point-to-MultiPoint. Выбор режима определяет работу протокола Hello и лавинной маршрутизации в сетях без широковещания, а также способ представления сети в базе данных о каналах.

В режиме NBMA протокол OSPF эмулирует работу в широковещательной сети – для сети NBMA задается выделенный маршрутизатор DR, который генерирует LSA для сети. Графы для широковещательных сетей и сетей NBMA идентичны (см. рисунок 1a).

Режим NBMA является наиболее эффективным вариантом использования OSPF в сетях без широковещания как с точки зрения размера базы данных о каналах, так и по объему служебного трафика. Однако этому режиму присущи серьезные ограничения – он требует подключения всех маршрутизаторов к сети NBMA для того, чтобы стал возможен прямой обмен информацией между маршрутизаторами. Это ограничение можно обойти для некоторых сетей без широковещания (например, для подсетей ATM, использующих SVC). Однако в других случаях, такое ограничение может оказаться очень существенным (например, для сетей Frame Relay, в которых поддерживаются только постоянные соединения PVC). В сетях без широковещания, где не все маршрутизаторы могут быть связаны напрямую, можно разбить сеть на логические подсети, в каждой из которых маршрутизаторы смогут взаимодействовать напрямую и тогда каждая отдельная подсеть может функционировать как сеть NBMA (см. [Ref15]). Однако такое решение требует от администратора значительных усилий и, к тому же, на этом пути легко допустить ошибки в настройке. Возможно, что для таких сетей будет лучше использовать режим Point-to-Multipoint.

rfc.com.ru

Перевод RFC 2328

В режиме Point-to-MultiPoint протокол OSPF трактует соединения между маршрутизаторами через сеть без широковещания просто как каналы «точка-точка». В сети не задается маршрутизатор DR и для сети не генерируются LSA. Фактически, вершина для сетей Point-to-MultiPoint просто не появляется на графе базы каналов.

На рисунке 1b показано представление базы данных для сети Point-to-MultiPoint. Слева приведена схема сети Point-to-MultiPoint. Предполагается, что все маршрутизаторы могут взаимодействовать напрямую, за исключением маршрутизаторов RT4 и RT5. Интерфейсы I3 - I6 идентифицируются по их IP-адресам в сети Point-to-MultiPoint. В графическом представлении базы данных маршрутизаторы, способные взаимодействовать напрямую через сеть Point-to-MultiPoint, соединены двунаправленными ребрами и каждый маршрутизатор также имеет stub-соединение со своим интерфейсом по IP-адресу (в отличие от сети point-to-point, показанной на рисунке 1a).

В некоторых сетях без широковещания использование режима Point-to-MultiPoint и протоколов канального уровня типа Inverse ARP (см. [Ref14]) позволяет автоматически детектировать соседей OSPF, несмотря на отсутствие широковещания.


R ТЗ		R T4
	13		14
	N 2		*^^^>*
	15		16
R T5		R T6

RT3

От узла

RT4

RT5

RT6

RT3


К узл	RT4 RT5	Х Х
у	RT6	Х	Х
	I3 I4	Х	Х

Х Х

Рисунок 1b: Компоненты представления сетей Point-to-MultiPoint Все маршрутизаторы (за исключением RT4 и RT5) могут взаимодействовать напрямую через сеть N2. Интерфейсы I3- I6

используют IP-адреса.

2.1.2. Пример базы данных о каналах

На рисунке 2 показан пример автономной системы. Прямоугольник с меткой H1 показывает хост, имеющий SLIP-соединение с маршрутизатором RT12. Маршрутизатор RT12, следовательно, анонсирует маршрут к хосту. Линии между маршрутизаторами показывают физические сети point-to-point. Единственная сеть point-to-point, в которой используются адреса для интерфейсов, соединяет маршрутизаторы RT6 и RT10. Маршрутизаторы RT5 и RT7 имеют BGP-соединение с другими AS. Набор полученных по BGP маршрутов показан для обоих маршрутизаторов.

Стоимость связывается с выходом каждого интерфейса в маршрутизаторе. Значение стоимости задает администратор сети. Чем меньше стоимость для интерфейса, тем с большей вероятностью этот интерфейс будет использоваться для пересылки трафика. Значение стоимости связывается также с полученной извне маршрутной информацией (например, данными BGP).

Направленный граф для сети, показанной на рисунке 2, приведен в таблице 1. На рисунке цифры показывают стоимость, связанную с интерфейсами маршрутизаторов. Если стоимость не указана, предполагается нулевое значение. Отметим, что соединения, выходящие из сетей, всегда имеют нулевую стоимость. Также подчеркнем, что полученные извне маршрутные данные показаны на графе как оконечные (stub).

База данных о каналах собирается по частям из LSA, генерируемых маршрутизаторами. В связанном графическом представлении соседство каждого маршрутизатора или транзитной сети представлено в одной, отдельной записи LSA. В таблице 2 эти LSA представлены графически. Маршрутизатор RT12 имеет интерфейсы в две широковещательные сети и SLIP-соединение с хостом. Сеть N6 является широковещательной и с ней соединены три маршрутизатора. Стоимость всех соединений из сети N6 с подключенными к этой сети маршрутизаторами равна 0. Отметим, что LSA для сети N6 на самом деле порождается одним из подключенных к этой сети маршрутизаторов, который для этой сети как DR.

rfc.com.ru

Перевод RFC 2328

I 3+---+ N12 N14

N1|--|RT1|\ 1 \ N13 /

| +—+ \ 8\ |8/8

+ \ _____ \|/

/ \ 1+—+8 8+ —-+6

* N3 *---|RT4|------|RT5|-----

\_____/ +—+ +—+

+ /

I 3+—+ /

N2 | — |RT2|/1

| +---+

I I И

+---+8

|RT3| —

+---+

12 I

6+---+

-|RT6|

+---+

N11

I 13

+---+

|RT9|

+---+

И _l_ / \ к ид

N12

1+----+2

*------|RT11| —

I I — I-I I

+ N8

lb |5

3+----+1

— |RT10| —

+----+

16 2/ +—+/

|RT7|---N15

+---+ 9

/ \ -* N6 *

\_____/

I И

+---+

|RT8|

+---+

И I

I И

+—+ 10+----+

| HI |-----|RT12|

+—+SLIP +----+

+----------

N10

Рисунок 2. Пример автономной системы

От узла

Таблица 1 Графическое представление базы данных.

у з л у

RT1 RT2

RT3 RT4 RT5 RT6 RT7 RT8

RT9 RT10 RT11 RT12

N3 0 0 0

N6 N8

RT1 RT2 RT3

RT4 RT5 RT6 RT7 RT8 RT9

RT10

RT11

RT12

N4 N6 N7 N8 N9 N10

N11 N12 N13 N14 N15 HI

rfc.com.ru

Перевод RFC 2328

От

зла N10

Таблица 2 Отдельные компоненты базы данных. От узла RT9 RT11 RT12 N9 RT9 0

RT11 0

RT12 N9

RT12

узл у

N10 2

узл

RT12 N9

H1 10

LSA для маршрутизатора RT12 LSA для сети N9

Сети и маршрутизаторы представлены вершинами. Ребро стоимостью X соединяет вершину A с вершиной B, если на пересечении колонки A и строки B показан знак X.

RT5 о—

/l\ 8/8|8\

RT6(origin) ------о-----

-o Ib

2.2. Дерево кратчайших путей

При отсутствии областей OSPF все маршрутизаторы в AS имеют идентичные базы данных о состоянии каналов; графическое представление этих баз также будет идентичным. Маршрутизатор генерирует свою таблицу маршрутов из графа базы данных, рассчитывая дерево кратчайших путей, корнем которого является сам маршрутизатор. Обычно дерево зависит от маршрутизатора, для которого оно рассчитано. Дерево для маршрутизатора RT6 из приведенного примера показано на рисунке 3.

Дерево включает путь к любой сети или хосту. Однако при пересылке пакетов адресату используется только следующий маршрутизатор (next hop). Отметим также, что рассчитывается лучший путь к каждому маршрутизатору. Для обработки внешних данных отметим next hop и дистанцию для всех маршрутизаторов, анонсирующих внешние маршруты. Полученная в результате таблица маршрутизации для RT6 показана в таблице 3. Отметим, что существует отдельный маршрут для каждого конца адресуемой сети point-to-point (в нашем случае это последовательный канал между RT6 и RT10).

Маршрутизаторы в сети, относящиеся к другим AS (например, N12) показаны пунктирными линиями на дереве кратчайших путей (рисунок 3). Использование этой полученной извне маршрутной информации рассмотрено в следующем параграфе.

2.3. Внешние данные

После создания дерева проверяется маршрутная информация, полученная извне. Эта информация может приходить от других протоколов маршрутизации (например, BGP) или задаваться статически. Принятые по умолчанию маршруты также могут включаться как часть внешних маршрутных данных AS.

| \

61 \

/ о N12

I I

о N13

о N14

N4 о-

1/ /

-о

\7 \ \ RT3 \ \

RT10 о---

1\ 3| \1

-о 1а

RT4 о-

--о /I

\ N6

о---

|RT8

о N7

RT7 -----о

/I 2/ |9 / I о о N12 N15

о I I I

RT2 о / /3 /

RT1

о N1

RT11

II I

N9 о

/ I

N2 о

N11 RT9

RT12

o -------- o ------- o o -------- o H1

3 | 10

|2 | o N10

Рисунок 3. Дерево SPF для маршрутизатора RT6

Ребра, для которых не указана стоимость имеют нулевую

стоимость (нет соединения маршрутизатор - сеть).

Маршруты в сети N12 - N15 являются внешней информацией,

которая будет рассматриваться в параграфе 2.3

Внешняя маршрутная информация рассылается через AS без изменений с использованием лавинной маршрутизации. В нашем примере все маршрутизаторы в AS знают, что RT7 имеет два внешних маршрута с метрикой 2 и 9.

Протокол OSPF поддерживает два типа внешней метрики. Тип 1 использует для метрики такие же единицы, которые служат для обозначения стоимости интерфейсов в OSPF (т. е., метрика определяется состоянием канала). Внешняя

Таблица 3 Часть таблицы

маршрутизации RT6 с локальными

адресатами.


Получатель	Next Hop	Дистанция
N1	RT3	10
N2	RT3	10
N3	RT3	7
N4	RT3	8
Ib	*	7
Ia	RT10	12
N6	RT10	8
N7	RT10	12
N8	RT10	10
N9	RT10	11
N10	RT10	13
N11	RT10	14
H1	RT10	21
RT5	RT5	6
RT7	RT10	8

метрика типа 2 использует на порядок большие значения и предполагается, что любая метрика типа 2 заведомо превосходит стоимость любого пути внутреннего по отношению к AS.

Использование метрики типа 2 предполагает, что маршрутизация между AS составляет основную часть стоимости пересылки пакетов – это избавляет от необходимости преобразования внешней метрики во внутренние единицы.

В качестве примера обработки внешней метрики типа 1 предположим, что маршрутизаторы RT7 и RT5 на рисунке 2 анонсируют внешнюю метрику этого типа. Для каждого из анонсируемых внешних маршрутов стоимость от маршрутизатора RT6 рассчитывается как сумма анонсированной стоимости внешнего маршрута и дистанции от RT6 до анонсирующего маршрутизатора. Когда два маршрутизатора анонсируют путь к одному получателю, RT6 выбирает тот маршрутизатор, через который общая стоимость доставки будет меньше. После этого RT6 устанавливает в качестве значения next hop на пути к внешнему адресату следующий маршрутизатор, который использовался для выбора анонсированного

пути.

На рисунке 2 оба маршрутизатора RT5 и RT7 анонсируют внешний маршрут в сеть N12. Маршрутизатор RT7 является предпочтительным, поскольку он анонсирует для N12 дистанцию 10 (8+2), а маршрутизатор RT5 - 14 (6+8). В таблице 4 показаны записи, добавляемые в таблицу маршрутизации при проверке внешних маршрутов.

Обработка внешней метрики типа 2 проще. Выбирается граничный маршрутизатор AS, анонсирующий наименьшую метрику, независимо от внутренней дистанции до граничного маршрутизатора AS. Предположим, что в нашем примере маршрутизаторы RT5 и RT7 анонсируют внешние маршруты типа 2. Тогда весь трафик для сети N12 будет пересылаться маршрутизатору RT7,

rfc.com.ru

Перевод RFC 2328


Таблица 4 Часть таблицы маршрутизации RT6 с внешними маршрутами.
Получатель	Next Hop	Дистанция
N12_________ N13	RT10 RT5	10__________ 14
N14	RT5	14

поскольку 2 < 8. При наличии нескольких маршрутов типа 2 с равной стоимостью, выбор осуществляется с учетом внутренней дистанции до маршрутизатора.

В AS может одновременно использоваться внешняя метрика типов 1 и 2, однако при наличии обоих типов предпочтение отдается внешней метрике типа 1.

В этом параграфе предполагается, что адресованные во внешние сети пакеты всегда пересылаются через анонсирующий граничный маршрутизатор AS. Однако,

N15 RT10 17 такой вариант не всегда желателен. Предположим, к примеру, что в сети на

рисунке 2 присутствует дополнительный маршрутизатор RTX, подключенный к сети N6. Предположим также, что RTX не участвует в маршрутизации OSPF, но обменивается информацией BGP с граничным маршрутизатором AS RT7. В этом случае RT7 будет анонсировать все внешние маршруты OSPF для адресатов, которые должны маршрутизироваться через RTX. Ели пакеты для таких адресатов всегда будут передаваться через RT7 (анонсирующий маршрутизатор), в некоторых случаях будет появляться ненужная петля. В таких ситуациях протокол OSPF позволяет граничному маршрутизатору AS задать «адрес пересылки» (forwarding address) в его внешнем по отношению к AS анонсе LSA. В приведенном выше примере маршрутизатор RT7 будет указывать IP-адрес RTX как адрес пересылки для всех получателей, пакеты к которым должны маршрутизироваться напрямую в RTX.

Адрес пересылки имеет еще одно применение – он позволяет маршрутизаторам внутри AS работать в качестве маршрутных серверов (route server). Например, маршрутизатор RT6 на рисунке 2 может стать маршрутным сервером, получающим внешние маршрутные данные из статических конфигурационных параметров и внешних протоколов маршрутизации. RT6 будет в этом случае анонсировать себя как граничный маршрутизатор AS и может генерировать анонсы OSPF LSA, внешние по отношению к AS. В каждом таком анонсе LSA маршрутизатор RT6 будет корректно указывать выходную точку AS для рассылки соответствующим получателям путем установки в LSA поля forwarding address.

2.4. Множество равноценных путей

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

При наличии множества равноценных путей маршрутизатор может иметь несколько вариантов next hop (следующий маршрутизатор) для каждого адресата.

3. Деление AS на области

Протокол OSPF позволяет объединять смежные сети и хосты в группы. Такая группа вместе с маршрутизаторами, имеющими интерфейс в одну (любую) из включенных в группу сетей, называется областью - area. В каждой области работает своя независимая копия алгоритма маршрутизации link-state. Это означает, что каждая область имеет свою базу каналов и соответствующий граф, как было описано в предыдущих параграфах.

Топология области невидима за ее пределами и наоборот, внутренние маршрутизаторы области не знают ничего о топологии за пределами данной области. Такая локализация сведений о топологии позволяет сильно снизить объем служебного трафика протокола по сравнению с ситуацией, когда вся AS является единым доменом link-state.

При использовании областей допущение идентичности баз данных о каналах на всех маршрутизаторах AS перестает быть верным. Маршрутизаторы теперь имеют раздельные базы данных для каждой области, с которой данный маршрутизатор соединен⁴. Два маршрутизатора, относящиеся к одной области имеют для этой области идентичные базы каналов.

Маршрутизация в AS осуществляется на двух уровнях в зависимости от местоположения отправителя и получателя. Если обе стороны находятся в одной области используется внутридоменная маршрутизация (intra-area routing), при расположении отправителя и получателя в разных областях применяется междоменная маршрутизация (inter-area routing). При внутридоменной маршрутизации используются только сведения, полученные из данной области. Такое решение предохраняет область от использования некорректных маршрутных данных. Междоменная маршрутизация рассматривается в параграфе 3.2.

3.1. Магистраль AS

Магистраль OSPF (backbone) представляет собой специальную область OSPF Area 0 (ее часто обозначают как Area 0.0.0.0, поскольку в OSPF идентификаторы областей обычно записывают в формате IP-адресов). Магистраль OSPF всегда включает все граничные маршрутизаторы областей. Магистраль отвечает за распространение маршрутной информации между остальными (non-backbone) областями. Магистраль должна обеспечивать смежность (contiguous), однако это не обязательно физическое соседство – магистральные соединения могут организовываться и поддерживаться с помощью настройки виртуальных соединений.

Виртуальное соединение можно настроить между любой парой маршрутизаторов магистрали, имеющих интерфейсы в одну область за пределами магистрали. Виртуальные соединения относятся к магистральной области. Протокол трактует пару маршрутизаторов, соединенных виртуальным каналом, как маршрутизаторы, связанные через безадресную магистральную сеть point-to-point. На графе магистрали два таких маршрутизатора соединяются дугами (arc), для которых стоимость определяется внутридоменным расстоянием между маршрутизаторами. Для служебного трафика, передаваемого через виртуальное соединение, используется только внутридоменная маршрутизация.

3.2. Маршрутизация между областями

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

Такой подход позволяет представить AS как систему с топологией «звезда», имеющую в центре концентратор-магистраль (backbone hub), к которому подключены все остальные области автономной системы.

⁴ Маршрутизаторы, имеющие интерфейсы в несколько областей, называют граничными маршрутизаторами областей - area border router.

rfc.com.ru 10 rfc.com.ru

Перевод RFC 2328

Разумные сети от компании BiLiM Systems

Топология магистральной области определяет пути между областями. Для более эффективной организации магистральных путей могут использоваться виртуальные соединения. Это дает администратору некоторые средства контроля для маршрутов передачи междоменного трафика.

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

3.3. Классификация маршрутизаторов

До введения областей единственными маршрутизаторами OSPF, выполняющими специальные функции, были те маршрутизаторы, которые анонсировали внешние маршрутные данные (например, RT5 на рисунке 2). После раздела AS на области OSPF, маршрутизаторы приобретают дополнительную специализацию в соответствии с выполняемыми функциями:

I 3+—+ Nl|—|RT1|\ 1 I +—+ \ + \

N12 N14 \ N13 / 8\ |8/8

\l/ 8+---+6

Внутренние маршрутизаторы

Маршрутизатор, непосредственно подключенный к сетям

единственной области. Такие маршрутизаторы используют

единственную копию базового алгоритма маршрутизации.

Граничные маршрутизаторы

областей (Area border router)

Маршрутизаторы, подключенные к нескольким областям. На

граничных маршрутизаторах

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

Граничные маршрутизаторы

областей собирают сведения о топологии подключенных областей для передачи этих сведений в магистральную область.

Магистраль распространяет

полученную информацию между всеми областями.

Магистральные (Backbone)

маршрутизаторы

Маршрутизаторы, имеющие

интерфейс в магистральную область. К этому типу относятся все маршрутизаторы, подключенные к нескольким областям (т. е., граничные маршрутизаторы

областей). Однако магистральные маршрутизаторы не обязаны быть граничными маршрутизаторами областей, поскольку некоторые маршрутизаторы могут быть подключены только к

магистральной области.

Граничные маршрутизаторы AS (AS boundary router)

Маршрутизаторы,

обменивающимися маршрутными данными с маршрутизаторами других AS. Такие маршрутизаторы анонсируют внешние маршрутные известны каждому маршрутизатору в граничными маршрутизаторами AS

1+-

-+8

|RT4|-

+---+

-|RT5| —

+---+

17 I 16

6+---+

-|RT6|

+---+

Ia|7

I N2|-

3+—+ / -|RT2|/1

+---+

\ 1\

+---+8

*T3| —

+---+

Area 1

2/ /

--+

N11

N 12

+---+

|RT9| +---+

_l_

/ \

* N9 *-

\_____/

lb 15

2/ -+/

+----+

. £T10|.....|RT7|

-N15.

1+----+2

-IRT11I--

+----+

I / I/ I I I +

+-/3

-+ 1\

-+ 9


	/	\
	N6	*
	\	/
		1 И
	+--	-+
	RT8\|
	+ —	-+
		14 1

I И

+—+ 10+----+

|H1|-----|RT12|

+—+SLIP +----+

12 I

+----------

N10

Area 3

.Area 2

Рисунок 4. Пример конфигурации областей OSPF

данные в автономную систему. Пути ко всем граничным маршрутизаторам AS

автономной системе. Эта классификация никак не связана с предыдущими типами

могут быть внутренние маршрутизаторы или граничные маршрутизаторы областей, а также магистральные маршрутизаторы.

3.4. Пример конфигурации областей

Таблица 5 Сети, анонсируемые в магистраль, маршрутизаторами RT3

На рисунке 4 показан пример конфигурации областей. Первая область включает сети N1 - N4 и подключенные к ним маршрутизаторы RT1 - RT4. Во вторую область входят сети N6 - N8 и маршрутизаторы RT7, RT8, RT10, RT11. Третья область состоит из сетей N9 - N11 и хоста H1 вместе с подключенными к ним маршрутизаторами RT9, RT11 и RT12. Третья область настроена так, что сети N9 - N11 и хост H1 группируются в один маршрут при анонсировании внешних по отношению к данной области путей (см. параграф 3.5).


Сеть	Анонс RT3	и RT4. Анонс RT4
N1 N2 N3	4____________ 4	4__________ 4
N4	2	3

На рисунке 4 маршрутизаторы RT1, RT2, RT5, RT6, RT8, RT9 и RT12 являются внутренними, RT3, RT4, RT7, RT10 и граничными маршрутизаторами областей, а RT5 и RT7 – граничными маршрутизаторами AS.

RT11

rfc.com.ru

Перевод RFC 2328

В таблице 6 показана база данных о каналах для области 1. Эта таблица полностью описывает внутридоменную маршрутизацию. В таблице также приведено полное представление внешних сетей (internet) для двух внутренних маршрутизаторов RT1 и RT2. Ответственность за анонсирование в области 1 дистанций до всех внешних адресатов ложится на граничные маршрутизаторы области - RT3 и RT4. Маршрутизаторы RT3 и RT4 должны также анонсировать в область 1 местоположение граничных маршрутизаторов AS RT5 и RT7. И, наконец, внешние по отношению к AS анонсы LSA от маршрутизаторов RT5 и RT7 рассылаются с использованием лавинной маршрутизации через всю AS и, в частности, через область 1. Эти LSA включаются в базу данных области 1 и дают маршруты в сети N12 - N15.

От узла

Маршрутизаторы RT3 и RT4 также будут резюмировать


		RT1	RT2	RT3	RT4	RT5	RT7	N3
у	RT1							0
з	RT2							0
л	RT3							0
у	RT4 RT5 RT7			14 20	8 14			0
	N1	3
	N2		3
	N3	1	1	1	1
	N4			2
	Ia, Ib			20	27
	N6			16	15
	N7			20	19
	N8			18	18
	N9-11, H1			29	36
	N12					8	2
	N13					8
	N14					8
	N15						9

топологию области 1 для передачи в магистраль. Анонсы LSA от этих маршрутизаторов показаны в таблице 4. Эти анонсы показывают какие сети включены в область 1 (N1 -N4) и указывают дистанцию до этих сетей от маршрутизаторов RT3 и RT4, соответственно.

База данных о состоянии каналов для магистральной области показана в таблице 7. В таблицу включены маршрутизаторы, являющиеся магистральными.

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

Граничные маршрутизаторы областей RT3, RT4, RT7, RT10 и RT11 собирают маршрутные сведения от своих областей, не относящихся к магистрали для распространения этих данных через магистраль AS. Напомним, что для третьей области настроена группировка сетей N9 - N11 и хоста H1 в один маршрут. Этим обусловлена общая запись для сетей N9 - N11 и хоста H1 в таблице 7. Маршрутизаторы RT5 и RT7

являются пограничными для AS и полученная от них внешняя маршрутная информация также показана в таблице 7.

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

Если снова использовать маршрутизаторы RT3 и RT4, следующие этапы:

в качестве расчет будет

SPF

примера включать

у з л у

Таблица 7 База данных магистральной области От узла

агистрали.

RT3 RT4

RT6 RT7

RT10 RT11

♦

Сначала рассчитывается дере

RT3 RT4 RT5 RT6 RT7

Этот расчет дает дистанции до всех остальных граничных маршрутизаторов областей. Определяются также дистанции до сетей (Ia и Ib) и граничных маршрутизаторов AS (RT5 и RT7), входящих в магистраль. Эти расчеты показаны в таблице 8.

После этого просматриваются резюме областей от граничных маршрутизаторов RT3 и RT4 для определения дистанции до всех маршрутизаторов за пределами данной области. Эти данные анонсируются внутри области маршрутизаторами RT3 и RT4. Анонсы, которые маршрутизаторы RT3 и RT4 будут передавать в область 1, показаны в таблице 9. Отметим, что в таблице 9 предполагается группировка интерфейсов Ia и Ib в один анонс LSA.

RT10

♦

RT11

N1 N2 N3 N4

N9-11, H1


1	1	3
5	5	7
4	3	2 11
2

9


Таблица 8 Магистральные дистанции, рассчитанные RT3 и RT4
	Дистанция от RT3 от RT
Д и	RT3 * \| 21
Д и	RT4 22	*
с	RT7 20	14
т а	RT10 15	22
т а	RT11 18	25
	Ia__________ 20	27
и я	Ib 15	22
и я	RT5 14	8
	RT7 20	14
д
о

Информация,

N12

импортируемая в

область 1 N13

маршрутизаторами N14

RT3 и RT4, N15

позволяет внутренним маршрутизаторам (например, RT1) выбирать граничный

маршрутизатор области более эффективно. Маршрутизатор RT1 будет использовать RT4

для трафика в сеть N6, RT3 – для сети N10, а для трафика в сеть N8 будут использоваться

оба маршрутизатора с распределением нагрузки.

Маршрутизатор RT1 таким же способом может определить кратчайший путь до граничных маршрутизаторов AS (RT5 и RT7). Просматривая в маршрутизаторах RT5 и RT7 записи AS-external-LSA, маршрутизатор RT1 может выбирать между RT5 и RT7 при пересылке пакетов адресатам из других AS (одна из сетей N12 - N15).

Отметим, что разрыв соединения между маршрутизаторами RT6 и RT10 будет приводить к разрыву магистрали. Организация виртуального соединения между маршрутизаторами RT7 и RT10 позволит обеспечить устойчивость магистрали к такого рода сбоям.

3.5. Поддержка подсетей IP

OSPF связывает адресную маску IP с каждым анонсируемым маршрутом. Маска показывает диапазон адресов, описываемых данным маршрутом. Например, summary-LSA для адресата 128.185.0.0 с маской 0xffff0000 на самом деле описывает маршрут к

rfc.com.ru

Перевод RFC 2328

адресатам в диапазоне.185.0.0 - 128.185.255.255. Аналогичным способом указываются маршруты к хостам – маска 0xffffffff показывает наличие в подсети единственного адреса.

Включение масок в каждый анонсируемый маршрут позволяет использовать при распределении адресов маски переменной длины (variable-length subnetting). Это значит, что в одной IP-сети класса A, B или C может существовать множество подсетей различных размеров. Например, сеть 128.185.0.0 можно разбить на 62 подсети переменного размера: 15 подсетей по 4K, 15 подсетей по 256, и 32 подсети по 8 адресов. В таблице 10 приведены примеры адресов таких подсетей вместе с масками.

Таблица 9 Дистанции, анонсируемые в область 1 маршрутизаторами RT3 и RT4


	Адресат	анонс RT3 20	анонс RT
Д	Ia, Ib	анонс RT3 20	27
и	N6	16	15
с	N7	20 18	19
т	N8	20 18	18
а	N9 - N11, H1	29	36
н	RT5	14 20	8
ц	RT7	14 20	14
и
я
д
о

Таблица 10 Примеры масок подсетей Адрес сети Маска IP Размер подсети

Существует множество способов деления сетей

128.185.16.0 0xfffff000 4K класса A, B и C на подсети

128.185.1.0 0xffffff00 256 переменного размера.

128.185.0.8 0xfffffff8 8 Описание процедур такого деления выходит за пределы данной спецификации,

однако мы рекомендуем пользоваться следующим правилом – при пересылке пакетов IP их следует адресовать в ту сеть, которая точнее всего совпадает с адресом получателя пакета. В контексте подсетей наилучшее соответствие эквивалентно самой длинной маске⁵. Например, используемый по умолчанию маршрут с адресом 0.0.0.0 и маской 0x00000000 соответствует любому из возможных адресов IP, но этот адрес является наименее соответствующим из всех возможных. Маски подсетей следует задавать таким образом, чтобы можно было однозначно определить наилучшее соответствие для любого адреса IP.

Добавление адресных масок в каждый маршрут позволяет поддерживать «сверхсети» (IP supernetting). Например, физическому сегменту может соответствовать пара адрес-маска [192.9.4.0,0xfffffc00]. Такой сегмент, являющийся единой сеть IP, содержит адреса из четырех последовательных сетей класса C – от 192.9.4.0 до 192.9.7.0. Такая адресация стала общепринятой после введения CIDR (см. [Ref10]).

Для более эффективного объединения маршрутов на границе области можно указать диапазон адресов области (см. Приложение C.2). Каждый диапазон адресов задается парой [адрес, маска]. Это позволяет объединить множество разных сетей в общий диапазон адресов (как сеть делится на множество разных подсетей). Граничные маршрутизаторы областей будут резюмировать содержимое области (для передачи в магистраль) анонсируя один маршрут для каждого диапазона адресов. Стоимость для такого маршрута устанавливается равной максимальному значению стоимости сетей из данного диапазона адресов.

Например, сеть, разделенная на подсети IP, может быть настроена как единая область OSPF. В таких случаях можно обойтись единственным диапазоном адресов – номером сети класса A, B или C с соответствующей классу маской адреса. Внутри области может быть организовано любое число подсетей, однако за пределы области будет распространяться единственный маршрут, скрывающий факт разбиения на подсети. Стоимость такого маршрута будет равна максимальной из стоимостей входящих в область подсетей.

3.6. Поддержка «тупиковых» областей

В некоторых автономных системах основная часть базы данных о каналах может состоять из внешней информации AS-external-LSA. Записи OSPF AS-external-LSA обычно рассылаются с использованием лавинной маршрутизации через всю AS. Однако протокол OSPF позволяет указать некоторые области как тупиковые (stub area) и анонсы AS-external-LSA не будут рассылаться в такие области или передаваться через них. Маршрутизация внешним по отношению к AS адресатам в таких системах базируется полностью на принятых по умолчанию для таких областей маршрутах. Выделение «тупиковых» областей позволяет уменьшить размер базы данных link-state и связанный с этим расход памяти для внутренних маршрутизаторов stub-областей.

Чтобы воспользоваться преимуществами поддержки тупиковых областей OSPF, для таких областей следует обязательно задавать принятые по умолчанию маршруты. Для этого один или несколько граничных маршрутизаторов stub-области должны анонсировать принятый по умолчанию маршрут с помощью summary-LSA. Такие анонсы рассылаются с использованием лавинной маршрутизации внутри тупиковой области, не покидая ее пределов (принятый по умолчанию маршрут относится только к данной области). Заданный для использования по умолчанию маршрут будет применяться во всех случаях, когда адресат недоступен явно с использованием пути внутри области или между областями AS (т. е., адресат относится к другой автономной системе).

Область можно назначить тупиковой, если имеется единственный выход из данной области или когда точек выхода несколько, но для выбора не требуется принимать решение с учетом адреса внешнего (по отношению к области) получателя. Например, область 3 на рисунке 4 можно указать как тупиковую, поскольку весь внешний трафик этой области должен проходить через один граничный маршрутизатор RT11. Если область 3 указана как тупиковая, маршрутизатор RT11 будет анонсировать принятый по умолчанию маршрут для его распространения внутри области 3 (с анонсах summary-LSA) взамен лавинной рассылки анонсов AS-external-LSA для сетей N12 - N15 в область 3.

Протокол OSPF обеспечивает оповещение всех маршрутизаторов области о тупиковом характере данной области – такое решение предотвращает ненужные лавинные рассылки анонсов AS-external-LSA.

Существуют некоторые ограничения на использование stub-областей. Через такие области невозможно организовать виртуальные соединения и, кроме того, внутрь тупиковых областей не должны попадать граничные маршрутизаторы AS.

3.7. Разделение областей

OSPF не предпринимает активных попыток восстановления распавшихся на части областей (area partition). В таких случаях просто каждый фрагмент области рассматривается как новая область и магистраль автономной системы обеспечивает маршрутизацию между новыми областями. Некоторые адресаты, для которых использовалась внутридоменная маршрутизация, могут после раздела потребовать междоменной маршрутизации.

Однако для сохранения полной маршрутизации после разделения области диапазон адресов не должен разделяться на множество компонент, связанных с фрагментами области. Не должна делиться на части и магистраль. Если это произойдет, некоторые части AS перестанут быть доступными. Разорванную магистральную область можно собрать заново путем организации виртуальных соединений (см. параграф 15).

⁵ Самой длинной маске будет соответствовать самая мелкая из возможных подсетей. Прим. перев.

rfc.com.ru 13

rfc.com.ru

Перевод RFC 2328

Другой способ представления раздела областей основан на графах AS, описанных в параграфе 2. Идентификаторы областей (Area ID) можно представить цветом ребер графа⁶. Каждое ребро графа подключено к сети или является сетью point-to-point. В любом случае цвета графов отображают идентификаторы областей. Группа ребер одного цвета, соединенных вершинами, представляет область. Если топология AS не изменяется, граф будет иметь несколько цветных областей для различных идентификаторов Area ID.

Когда топология AS изменяется, одна из областей может быть разделена на части. В этом случае граф AS будет включать несколько областей одного цвета (Area ID). Маршрутизация в AS будет сохраняться до тех пор, пока такие области одного цвета могут быть соединены через единую магистральную область.

4. Основные функции

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

При активизации маршрутизатора он сначала инициализирует структуры данных протокола. После инициализации маршрутизатор ждет от протоколов нижележащих уровней индикации активности интерфейсов. Далее маршрутизатор отыскивает соседей с помощью протокола OSPF Hello – для этого соседям передаются пакеты Hello и в ответ должны также прийти пакеты Hello. В широковещательных сетях и сетях point-to-point маршрутизаторы динамически детектируют соседей, передавая пакеты Hello по групповом адресу AllSPFRouters. В сетях без поддержки широковещания обнаружение соседей может потребовать некоторой настройки маршрутизатора. В широковещательных сетях и сетях NBMA протокол Hello также указывает выделенный маршрутизатор (Designated Router или DR).

Маршрутизатор будет пытаться установить отношения смежности (adjacency) с некоторыми из новообретенных соседей. Пары смежных маршрутизаторов синхронизируют между собой базы данных о каналах. В широковещательных сетях и сетях NBMA выделенный маршрутизатор DR определяет, какие маршрутизаторы должны быть смежными. Отношения смежности определяют распространение маршрутной информации – обновления маршрутных данных передаются только смежным маршрутизаторам.

Маршрутизатор периодически анонсирует свое состояние, называемое также состоянием канала - link state. При изменении состояния маршрутизатора изменяется и состояние канала. Отношения смежности маршрутизаторов отражаются в содержимом анонсов LSA. Связь между отношениями смежности и состояниями каналов позволяет протоколу обнаруживать неработающие («мертвые») маршрутизаторы достаточно быстро.

Анонсы LSA рассылаются в области с использованием лавинной маршрутизации. Алгоритм лавинной рассылки надежен и обеспечивает распространение по всей области единой копии базы данных о каналах. База данных содержит набор LSA от каждого маршрутизатора, входящего в область. На основании этих данных каждый маршрутизатор рассчитывает дерево кратчайших путей, используя себя в качестве корня. Это дерево дает таблицу маршрутизации для протокола.

4.1. Междоменная маршрутизация

В предыдущем параграфе рассматривалась маршрутизация в пределах одной области. В таких случаях никакой дополнительной маршрутной информации не требуется. Для обеспечения маршрутизации между областями граничные маршрутизаторы областей вводят в область дополнительные сведения о маршрутах. Эта информация представляет собой выжимку из сведений о топологии остальной части AS.

Распространение сведений о топологии автономной системы происходит следующим образом. Каждый граничный маршрутизатор области по определению связан с магистралью области. Все граничные маршрутизаторы областей анонсируют топологию подключенных к ним областей, не являющихся магистральными, для передачи в магистраль и, следовательно, всем остальным граничным маршрутизаторам областей. В результате каждый граничный маршрутизатор области имеет полные сведения о магистрали и суммарные данные по каждой области от граничных маршрутизаторов остальных областей. На основании этих данных маршрутизатор рассчитывает пути для междоменной маршрутизации и анонсирует эти пути в подключенные к нему области. Получив такие сведения, внутренние маршрутизаторы могут выбрать оптимальные точки выхода из области для рассылки междоменного трафика.

4.2. Внешние маршруты AS

Маршрутизаторы, имеющие сведения о других AS, могут организовать лавинную рассылку этой информации в своей AS. Внешняя маршрутная информация передается без изменения каждому заинтересованному в ней маршрутизатору. Единственным исключением является то, что внешняя маршрутная информация не передается в «тупиковые» области (см. параграф 3.6).

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

4.3. Пакеты протокола маршрутизации

Протокол OSPF работает непосредственно на базе IP, используя идентификатор 89. OSPF не требует какой-либо дополнительной фрагментации/сборки пакетов – при возникновении такой необходимости используется обычная фрагментация и сборка IP. Пакеты протокола OSPF имеют такой формат, что большие блоки протокольной информации в общем случае можно легко разделить на более мелкие пакеты. Рекомендуется использовать именно такой вариант, избегая по возможности фрагментирования IP.

Пакеты протокола маршрутизации всегда должны передаваться с нулевым значением поля IP TOS. Если это возможно, пакеты протоколов маршрутизации должны иметь преимущество по сравнению с обычным трафиком данных IP как для приема, так и при передаче. Чтобы облегчить эту задачу, протокол OSPF должен использовать в поле IP precedence значение Internetwork Control (см. [Ref5]).

⁶ Вершины графов представляют маршрутизаторы, транзитные или оконечные сети. Поскольку маршрутизаторы могут

принадлежать нескольким областям, невозможно использовать для маркировки цвет вершин графа.

rfc.com.ru 14 rfc.com.ru

Перевод RFC 2328


Тип 1	Название Hello	Таблица 11 Типы пакетов OSPF Назначение Обнаружение и поддержка
2	Database Description	соседства Резюмирование содержимого БД
3 4 5	Link State Request Link State Update Link State Ack	Загрузка БД Обновление БД Подтверждение лавинной рассылки

Все пакеты протокола заголовки, описанные в

OSPF используют однотипные

Приложении A. Типы пакетов

OSPF перечислены в таблице 11. Форматы пакетов также описаны в Приложении A.

Протокол OSPF Hello использует пакеты Hello для

организации и поддержки соседских отношений. Пакеты

Database Description (описание базы данных) и Link State

Request (запрос состояния канала) служат для поддержки

отношений смежности. Гарантированный обмен обновлениями OSPF основан на обмене пакетами Link State Update (обновление

состояния канала) Link State Acknowledgment (подтверждение приема обновления).

Ти

Имя LSA

Таблица 12 Типы анонсов OSPF (LSA). Описание LSA

Генерируются всеми маршрутизаторами. Этот тип LSA описывает состояния интерфейсов маршрутизатора в область. Анонс рассылается в лавинном режиме внутри области. Генерируется выделенным маршрутизатором DR для широковещательных и NBMA-сетей. Этот тип LSA включает список маршрутизаторов, подключенных к сети. Рассылается в лавинном режиме внутри области.

Генерируется граничными маршрутизаторами областей и рассылается в лавинном режиме в пределах связанной с LSA области. Каждый анонс summary-LSA описывает маршрут к адресату за пределами данной области, но внутри данной AS (междоменный маршрут). Тип 3 summary-LSA описывает маршруты в сети, а тип 4 – к граничным маршрутизаторам AS.

Генерируется граничными маршрутизаторами AS и рассылается по всей автономной системе. Каждый анонс AS-external-LSA описывает маршрут к адресатам в другой AS. Принятые по умолчанию маршрутизаторы AS также могут описываться в AS-external-LSA.

Каждый пакет Link State Update содержит набор новых анонсов состояния каналов (LSA) на один интервал (hop) удаленных от пункта генерации анонса. Один пакет Link State Update может содержать анонсы LSA от нескольких маршрутизаторов. Каждая запись LSA помечается идентификатором создавшего анонс маршрутизатора и сопровождается контрольной суммой содержимого. В каждой записи LSA имеется также поле типа; возможные варианты этого поля описаны в таблице 12.

Пакеты протокола OSPF (за исключением пакетов Hello) передаются только между смежными маршрутизаторами. Это означает, что все пакеты протокола OSPF проходят только один интервал между

маршрутизаторами (IP hop), за исключением тех ситуаций, когда смежность поддерживается через виртуальные соединения (virtual adjacency). IP-адрес отправителя пакета OSPF является адресом одного из смежных маршрутизаторов, а IP-адрес получателя является адресом второго из смежных маршрутизаторов или групповым IP-адресом.

Router-LSA

Network-LSA

Summary-LSA

AS-external-LSA

4.4. Основные требования к реализации

Каждая реализация OSPF должна обеспечивать перечисленные ниже возможности.

Таймеры

Протоколы требуются таймеры двух типов. Первый тип - single shot timers (одноразовый таймер) служит для запуска обработки событий по истечении заданного времени. Второй тип таймеров называют интервальными (interval timer) и они служат для непрерывного отсчета интервалов. Такие таймеры используются для периодической отправки пакетов. Хорошим примером может служить регулярная широковещательная рассылка пакетов Hello. Единица отсчета для таймеров обоих типов составляет 1 сек.

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

Групповая адресация - IP multicast

Некоторые пакеты OSPF передаются в виде дейтаграмм IP multicast. Поэтому требуется поддержка приема и передачи дейтаграмм с групповыми адресами IP и (при необходимости) соответствующих протоколов нижележащих уровней. Групповые дейтаграммы IP, используемые протоколом OSPF никогда не передаются дальше следующего маршрутизатора. По этой причине поддержка пересылки дейтаграмм IP multicast не требуется. Групповая адресация IP описана в работе [Ref7].

Подсети разных размеров - Variable-length subnet support

Реализация протокола IP в маршрутизаторах должна поддерживать возможность разделения сетей класса A, B или C на множество подсетей различных размеров. Обычно такое деление называют variable-length subnetting (см. параграф 3.5).

Поддержка «сверхсетей» - IP supernetting support

Реализация протокола IP в маршрутизаторах должна поддерживать возможность объединения непрерывного набора сетей классов A, B и C в более крупные объекты, называемые сверхсетями (supernet). Поддержка сверхсетей предложена в качестве одного из способов масштабирования маршрутизации IP в рамках сети Internet в целом. Дополнительную информацию о сверхсетях можно найти в работе [Ref10].

Поддержка протоколов нижележащих уровней - Lower-level protocol support

К упоминаемым в этой спецификации протоколам нижних уровней относятся протоколы доступа в сеть (например, канальный протокол Ethernet). От этих протоколов к OSPF должна передаваться индикация состояний интерфейса (up и down). В случае Ethernet представляется разумным получение информации об отключении сетевого кабеля Ethernet.

Поддержка протоколов нижних уровней без широковещания - Non-broadcast lower-level protocol support

В сетях без широковещания протокол OSPF Hello можно использовать, обеспечивая индикацию попыток отправки пакетов несуществующему или неработающему маршрутизатору. Например, в сетях X.25 PDN «умерший» соседний маршрутизатор можно указать с помощью X.25 clear (сведения о причинах «умирания» и диагностика), передавая эти данные протоколу OSPF.

Действия со списками - List manipulation primitives

Большая часть функций OSPF описывается как операции над списками LSA. Например, набор LSA, передаваемых смежному маршрутизатору, пока не будет получено подтверждение, может быть представлен в виде списка. Любая отдельно взятая запись LSA может включаться во множество таких списков. Реализация OSPF должна поддерживать работу с такими списками, удаляя или добавляя в них при необходимости соответствующие LSA.

rfc.com.ru

Перевод RFC 2328

Поддержка задач - Tasking support

Некоторые процедуры, описанные в этой спецификации, включают в себя выполнение других процедур. Иногда такие процедуры должны выполняться в режиме in-line, т. е., до того, как будет завершена текущая процедура. В тексте такие ситуации указаны инструкциями на выполнение процедуры. В других случаях, новая процедура выполняется только после завершения текущей. Такие ситуации показаны инструкциями на планирование задач.

4.5. Дополнительные возможности OSPF

Протокол OSPF включает несколько дополнительных возможностей, реализация которых осуществляется по усмотрению разработчиков. Маршрутизатор указывает поддерживаемые им дополнения в своих пакетах OSPF Hello, Database Description LSA. Это позволяет использовать в одной автономной системе маршрутизаторы с разными наборами дополнительных возможностей. Некоторое возможности должны поддерживаться всеми маршрутизаторами, подключенными к данной области. В таких случаях маршрутизатор не будет воспринимать пакеты Hello от соседей, пока не убедится в наличии требуемого соответствия (т. е., несоответствие возможностей предотвращает организацию отношений соседства). Примером такой дополнительной функции может служить ExternalRoutingCapability (см. ниже).

Другие возможности могут быть согласованы при обмене базами данных (Database Exchange). Это согласование реализуется указанием дополнительных возможностей в пакетах Database Description. Несоответствие возможностей с соседями в данном случае будет приводить лишь к сужению числа используемых дополнений и соответствующей корректировке содержимого баз данных при обмене между соседями.

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

Дополнительные возможности протокола OSPF, определенные в данной спецификации, перечислены ниже. Более подробные сведения о таких возможностях приведены в параграфе A.2.

ExternalRoutingCapability

Как было сказано выше (параграф 3.6) целые области OSPF могут быть настроены как тупиковые (stub). Анонсы AS-external-LSA не будут рассылаться в такие области. Эта возможность указывается битом E в поле опций OSPF (см. параграф A.2). Для того чтобы обеспечить согласованную настройку тупиковых областей, все маршрутизаторы, имеющие интерфейсы в такие области, должны устанавливать нулевое значение бита E в своих пакетах Hello (см. параграфы 9.5 и 10.5).

5. Структуры данных протокола

Протокол OSPF описывается в данной спецификации в терминах обработки различных структур данных этого протокола. Ниже приведен список структур данных OSPF верхнего уровня. Если структура данных требует инициализации, нужные действия указаны явно. В протоколе OSPF области, интерфейсы и соседи также используют структуры данных, которые описаны ниже вместе с соответствующими объектами.

Router ID (идентификатор маршрутизатора)

32-битовое целое число, позволяющее уникально пронумеровать каждый маршрутизатор в AS. Одним из вариантов идентификатора может служить наименьший из IP-адресов маршрутизаторов интерфейса. При смене значения Router ID требуется перезагрузка программ OSPF в маршрутизаторе для работы с новым идентификатором Router ID. В таких случаях маршрутизатор должен удалить свои (self-originated) LSA из области маршрутизации (см. параграф 14.1) до перезагрузки, поскольку в противном случае эти анонсы будут сохраняться в течение времени MaxAge.

Area structures (структуры области)

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

Backbone (area) structure (структура магистральной области)

Магистральная область OSPF отвечает за распространение данных междоменной (inter-area) маршрутизации.

Virtual links configured (настроенное виртуальное соединение)

Виртуальные соединения настраиваются между маршрутизаторами, служащими конечными точками таких соединений. Для организации виртуального соединения маршрутизатор должен быть граничным в области. Виртуальные соединения обозначаются идентификаторами Router ID удаленного маршрутизатора (он также является граничным в своей области). Для организации виртуального соединения оба участвующих в нем маршрутизатора должны быть подключены к общей области, называемой транзитной для виртуального канала (virtual link's Transit area). Виртуальные соединения включаются в магистраль AS, как будто они связаны между собой через сеть «точка-точка» без адресации интерфейсов (unnumbered). Виртуальное соединение использует внутридоменную маршрутизацию своей транзитной области для пересылки пакетов. Виртуальные соединения организуются (up) и удаляются (down) при построении дерева кратчайших путей для транзитной области.

List of external routes (список внешних маршрутов)

В этот список включаются маршруты ко внешним по отношению к AS адресатам, которые были явно получены от других протоколов маршрутизации (таких, как BGP), заданы администратором или получены иным способом (например, динамическая маршрутная информация, анонсируемая OSPF с заданным значением метрики). Все маршрутизаторы, имеющие такие внешние маршруты, называются граничными маршрутизаторами AS. Внешние маршруты анонсируются маршрутизаторами в область маршрутизации OSPF с помощью AS-external-LSA.

List of AS-external-LSAs (список AS-external-LSA)

Часть базы данных о каналах, полученная от граничных маршрутизаторов AS. Этот список содержит маршруты ко внешним по отношению к данной AS адресатам. Отметим, что для граничных маршрутизаторов AS часть записей AS-external-LSA порождена данным маршрутизатором (self-originated).

The routing table (таблица маршрутизации)

Эта таблица строится на основе базы данных о каналах (link-state database). Каждая запись в таблице маршрутизации индексируется по получателям и включает набор путей для пересылки пакетов адресатам. Для описания путей используется их тип и адрес следующего маршрутизатора (см. параграф 11). На рисунке 5 показана структура данных типичного маршрутизатора (RT10 из примера на рисунке 4). Отметим, что маршрутизатор RT10 имеет виртуальное соединение с RT11, а область 2 является для этого соединения транзитной. Это соединение показано звездочками (*) на рисунке 5. Когда виртуальное соединение активизируется при построении дерева кратчайших путей для области 2, оно становится интерфейсом в магистральную область (см. два магистральных интерфейса, отмеченных на рисунке 3).

rfc.com.ru 16 rfc.com.ru

Перевод RFC 2328

6. Структура данных области

Структура данных области /

содержит всю информацию, /

используемую при работе /

+----+

|RT10|-

+----+

\+-----

|Табл.

+-----

маршрут|

-------+

базового алгоритма

маршрутизации OSPF. Каждая

+------+ /

|Обл. 2|---+

-I_____________________i-************

+--------+

-|Магистр.|

+--------+

область поддерживает свою

базу данных link-state. Сеть / \

/ * /

+ -----------

|Вирт. канал | до RT11

+ -----------

| |


	\
	\| Интерфейс Ib\|
	i i
	+ ------- \| Сосед	RT6 \| --------

целиком принадлежит к

одной области и каждый

интерфейс маршрутизатора

тоже подключен к одной

области. Отношения

смежности организуются

между маршрутизаторами

+ --------- +

|Интерфейс| |в сеть N6|

+ --------- +

/ \ /

+ --------- +

|Интерфейс| |в сеть N8|

+ --------- +

одной области.

Магистраль OSPF является

специальной областью OSPF,

Сосед RT8

Сосед RT7

Сосед RT11

отвечающей за

распространение данных

междоменной

Сосед RT11

маршрутизации.

База данных о каналах

состоит из набора router-LSA,

Рисунок 5. Структуры данных маршрутизатора RT10.

network-LSA и summary-LSA,

получаемых от маршрутизаторов области. Эта информация рассылается в лавинном режиме в пределах данной области. Список

AS-external-LSA (см. параграф 5) также является частью каждой базы каналов.

Area ID – идентификатор области

32-битовый идентификатор области⁷. Значение ID = 0.0.0.0 зарезервировано для магистральной области.

List of area address ranges – список адресных диапазонов

Для агрегирования маршрутной информации на границах областей могут использоваться диапазоны адресов. Каждый такой диапазон задается парой [адрес, маска] с указанием информации о состоянии (Advertise или DoNotAdvertise, см. параграф 12.4.3).

Associated router interfaces – интерфейсы подключенных маршрутизаторов

Интерфейс маршрутизатора, подключенный к области. Интерфейс маршрутизатора может относиться к одной и только к одной области (или магистрали). Для магистральной области этот список включает также все виртуальные соединения. Виртуальное соединение обозначается идентификатором Router ID маршрутизатора на другой стороне соединения; стоимость виртуального соединения совпадает со стоимостью кратчайшего пути через транзитную область между маршрутизаторами.

List of router-LSAs – список router-LSA

Анонсы router-LSA генерируются каждым маршрутизатором области и описывают состояние интерфейсов маршрутизатора в данную область.

List of network-LSAs – список network-LSA

Один анонс network-LSA генерируется для каждой транзитной широковещательной или NBMA-сети в данной области. Анонсы network-LSA описывают набор маршрутизаторов, подключенных в данный момент к области.

List of summary-LSAs – список summary-LSA

Анонсы Summary-LSA исходят от граничных маршрутизаторов областей и описывают пути к получателям в пределах данной AS, но внешних по отношению к этой области (междоменный маршрут).

Shortest-path tree – дерево кратчайших путей

Дерево кратчайших путей для данной области с маршрутизатором в качестве корня. Дерево строится на базе анонсов router-LSA и network-LSA с помощью алгоритма Dijkstra (см. параграф 16.1).

TransitCapability – возможность транзита

Этот параметр показывает возможность передачи через область транзитного трафика, т. е., пакетов, отправители и получатели которых находятся за пределами области. Значение этого параметра определяется при построении для области дерева кратчайших путей (см. параграф 16.1 – поле TransitCapability имеет значение TRUE тогда и только тогда, когда существует один или несколько виртуальных соединений, для которых данная область является транзитной) и используется при построении таблицы маршрутов для области (см. параграф 16.3). Если TransitCapability = TRUE, область называю транзитной (transit area).

ExternalRoutingCapability

Этот задаваемый административно параметр определяет лавинную рассылку анонсов AS-external-LSA в область. Если рассылка AS-external-LSA не проводится для данной области, область считается тупиковой (stub). В тупиковых областях маршрутизация внешним адресатам осуществляется исключительно на базе принятого по умолчанию summary-LSA для данной области. Магистральная область не может быть тупиковой. Кроме того, через тупиковые области невозможно организовать виртуальные соединения. Дополнительная информация о тупиковых областях содержится в параграфе 3.6.

StubDefaultCost

Если область указана как тупиковая и данный маршрутизатор является граничным для такой области, параметр StubDefaultCost показывает стоимость принятого по умолчанию summary-LSA, который маршрутизатор должен анонсировать в область (см. параграф 12.4.3).

Если явно не указано иное, в остальной части данной спецификации работа протокола OSPF рассматривается в масштабе одной

области.

7. Организация отношений смежности

Протокол OSPF организует отношения смежности (adjacency) между соседними маршрутизаторами для обмена маршрутной информацией. Не каждая пара соседних маршрутизаторов является смежной. В этой главе рассмотрены общие вопросы организации отношений смежности, а более детальное рассмотрение приводится в главе 10.

⁷ Для записи Area ID часто используют общепринятый формат записи IP-адресов в виде десятичных чисел, разделенных точками. Прим. перев.

rfc.com.ru 17 rfc.com.ru

Перевод RFC 2328

7.1. Протокол Hello

Протокол Hello отвечает за организацию и поддержку отношений смежности между соседними маршрутизаторами, а также обеспечивает двухстороннюю связь между соседями. Пакеты Hello периодически передаются через все интерфейсы маршрутизатора. Наличие двухсторонней связи устанавливается, когда маршрутизатор видит себя в пакете Hello от соседа. В широковещательных и NBMA-сетях протокол Hello используется также для выбора маршрутизатора DR для данной сети.

Работа протокола Hello различается в широковещательных сетях, сетях NBMA и Point-to-MultiPoint. В широковещательных сетях каждый маршрутизатор анонсирует себя, периодически передавая пакеты Hello с использованием групповой адресации. Это позволяет динамически обнаруживать присутствие соседей. Такие пакеты Hello содержат представление маршрутизатора о тождественности DR и список маршрутизаторов, чьи пакеты Hello были приняты недавно. В сетях NBMA требуется некоторая настройка для обеспечения работы протокола Hello. Каждый маршрутизатор, который потенциально может быть назначен в качестве DR, имеет список всех маршрутизаторов, подключенных к сети. Маршрутизатор, имеющий возможность стать DR, передает пакеты Hello всем остальным потенциальным DR, когда его интерфейс в сеть NBMA начинает работать. Это является попыткой обнаружения маршрутизатора DR для данной сети. Если данный маршрутизатор назначен в качестве DR, он начинает передачу пакетов Hello всем остальным маршрутизаторам, подключенным к сети.

В сетях Point-to-MultiPoint маршрутизатор передает пакеты Hello всем соседям, с которыми он может взаимодействовать напрямую. Поиск таких соседей может осуществляться динамически с использованием протоколов типа Inverse ARP [Ref14] или соседи могут быть заданы статически.

После того, как найдены соседи, организована двухсторонняя связь и (в широковещательных и NBMA-сетях) назначен выделенный маршрутизатор DR, принимается решение о возможности и целесообразности поддержки отношений смежности с соседом (см. параграф 10.4). Если отношения смежности организованы, первым шагом является синхронизация баз данных между смежными маршрутизаторами, подробно описанная в следующем параграфе.

7.2. Синхронизация баз данных

Для алгоритмов link-state большое значение имеет синхронизация баз данных о состоянии каналов во всех маршрутизаторах. Протокол OSPF упрощает ситуацию, требуя синхронизировать лишь базы данных смежных маршрутизаторов. Процесс синхронизации начинается сразу после попытки маршрутизаторов организовать отношения смежности. Каждый маршрутизатор описывает свою базу каналов, посылая соседу последовательность пакетов Database Description, каждый из которых описывает набор LSA, включенных в базу данных маршрутизатора. Когда сосед видит анонсы LSA, более новые по сравнению с имеющейся у него копией, он делает отметку о необходимости запроса новейших LSA.

Процесс обмена пакетами Database Description называется обменом базами данных (Database Exchange Process). Во время обмена между маршрутизаторами организуются отношения ведущий - ведомый (master/slave). Каждый пакет Database Description имеет порядковый номер. Переданные ведущим маршрутизатором пакеты Database Description подтверждаются ведомой стороной с возвратом порядкового номера подтверждаемого пакета. Передаваемые в обоих направлениях пакеты содержат резюме данных о состоянии соединений (link state data). Ведущий маршрутизатор может повторно передавать пакеты Database Description с использованием фиксированного интервала, задаваемого для каждого интерфейса административно с помощью параметра RxmtInterval.

Каждый пакет Database Description содержит флаг индикации наличия последующих пакетов - бит M. Процесс Database Exchange завершается, когда маршрутизатор принял и передал пакет Database Description с нулевым значением бита M. В процессе Database Exchange и после его завершения каждый маршрутизатор имеет список LSA, для которых сосед имеет более свежие данные. Для запроса этой информации используются пакеты Link State Request. Если запрос не выполнен пакет Link State Request передается повторно по истечении интервала RxmtInterval. После завершения процесса Database Exchange⁸ и выполнения всех запросов Link State базы данных засинхронизированы и маршрутизаторы маркируются как смежные (fully adjacent). С этого момента отношения смежности являются полными и анонсируются в router -LSA обоих маршрутизаторов.

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

7.3. Выделенный маршрутизатор DR

В каждой широковещательной или NBMA-сети имеется выделенный маршрутизатор DR, выполняющий две основных задачи:

♦ Маршрутизатор DR генерирует анонсы network-LSA от имени сети. Эти LSA содержат список маршрутизаторов (включая DR), подключенных в данный момент к сети. Идентификатором Link State ID для таких LSA (см. параграф 12.1.4) является IP-адрес интерфейса в маршрутизаторе DR. Номер IP-сети можно найти по этому адресу, используя адресную маску.

♦ Маршрутизатор DR является смежным для всех остальных маршрутизаторов сети. Поскольку базы данных смежных маршрутизаторов синхронизируются (в процессе организации отношений смежности), маршрутизатор DR играет центральную роль в процессе синхронизации данных.

Маршрутизатор DR задается с помощью протокола Hello. Пакет Hello от маршрутизатора содержит значение Router Priority, настраиваемое для каждого интерфейса. В общем случае перед тем как интерфейс маршрутизатора в сеть начнет работать, он проверяет наличие в сети маршрутизатора DR. Если такой маршрутизатор уже задан, он принимается, независимо от значения Router Priority. Такой подход осложняет прогноз тождественности DR, но избавляет от частой смены маршрутизатора DR (см. ниже). Если маршрутизатор DR еще не назначен, им становится данный маршрутизатор, если он имеет наивысшее в сети значение Router Priority. Более детальное и точное описание процедуры выбора DR приведено в параграфе 9.4.

Маршрутизатор DR является конечной точкой для множества смежных пар. Для оптимизации процедуры лавинной рассылки в широковещательных сетях DR использует для передачи своих пакетов Link State Update Packets групповой адрес AllSPFRouters, вместо передачи пакетов каждому из смежных маршрутизаторов по отдельности.

В главе 2 было рассмотрено представление областей в виде графа. Маршрутизаторы помечаются их идентификаторами (Router ID), для обозначения транзитных сетей используются IP-адреса их маршрутизатора DR. Из сказанного следует, что при смене маршрутизатора DR на графе это отражается как полная замена сетевого узла. При такой смене сеть и все подключенные к ней маршрутизаторы будут генерировать новые анонсы LSA. В результате может теряться связность сети, пока не будут засинхронизированы все базы данных. В результате потери связности может быть сгенерировано множество сообщений ICMP unreachable. По этим причинам замены DR-маршрутизатора не должны быть частыми. Параметр Router Priority следует устанавливать таким, чтобы наиболее надежный маршрутизатор сети в конце концов принимал на себя функции DR.

⁸ В оригинале ошибочно указано Database Description. Прим. перев.

rfc.com.ru 18

rfc.com.ru

Перевод RFC 2328

7.4. Резервный маршрутизатор DR

Для облегчения процесса перехода к новому маршрутизатору DR вводится понятие резервного DR-маршрутизатора (Backup Designated Router) для каждой широковещательной и NBMA-сети. Маршрутизатор Backup DR также является смежным со всеми маршрутизаторами сети и берет на себя функции выделенного маршрутизатора при сбое прежнего DR. Если в сети нет Backup DR, для назначения нового DR от этого маршрутизатора потребуется организовать отношения смежности со всеми остальными маршрутизаторами в сети. Частью этого процесса является синхронизация баз данных, которая может занимать достаточно много времени, в течение которого сеть будет недоступна для передачи данных. Наличие маршрутизатора Backup DR избавляет от необходимости формирования отношений смежности, поскольку они уже существуют. Это уменьшает время простоя для транзитного трафика до периода, требуемого для лавинной рассылки новых LSA, которые анонсируют новый маршрутизатор DR.

Резервный маршрутизатор DR не генерирует анонсов network-LSA для сети (если это сделать, переход к новому DR дополнительно ускорится, но приходится учитывать соотношение между ростом базы данных и скоростью перехода к новому DR).

Маршрутизатор Backup DR также задается с помощью протокола Hello. Каждый пакет Hello имеет поле для указания Backup DR для сети.

На некоторых этапах процедуры лавинной рассылки Backup DR играет пассивную роль, позволяя маршрутизатору DR выполнять больше работы. В результате снижается уровень локального служебного трафика (см. параграф 13.3).

7.5. Граф смежности

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

Набор отношений смежности сети можно представить в форме ненаправленного графа. Вершины графа представляют маршрутизаторы, а ребра соединяют смежные маршрутизаторы между собой. Граф смежности описывает поток пакетов протокола маршрутизации и, в частности, пакетов Link State Update через AS.

+---+

|RT1|-

+---+

|RT2|

+---+


о--- RT1	RT7	---о RT2
/l\ / 1 \ / 1 \ / 1 \ RT5o RT6o *** * ***		1 1 1 1 oRT4 \| \|
	*** * ***	1
	*** * ***	1
	*******	1
	RT3

+---+

|RT7|

+---+

|RT3|

+---+

|RT4|

+---+

|RT5|

+---+

|RT6|

+---+

В зависимостмаршрутизатор

физических

от DR сетях

наличия в сети выделенного возможны два варианта графа. В «точка-точка», сетях

MultiPoint и виртуальных каналах соседние маршрутизаторы становятся смежными, если они могут

Рисунок 6. Граф смежности

обмениваться данными напрямую. В

широковещательных и NBMA-сетях маршрутизаторы DR и Backup DR являются смежными для всех остальных маршрутизаторов

сети.

Оба варианта графов показаны на рисунке 6. Предполагается, что маршрутизатор RT7 является DR, а RT3 - Backup DR для сети N2. Маршрутизатор Backup DR выполняет меньше работы в процессе лавинной рассылки, нежели маршрутизатор DR (см. параграф 13.3). По этой причине соединение с маршрутизатором Backup DR (RT3) выделено на графе звездочками (*).

8. Обработка пакетов протокола

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

Пакеты протокола маршрутизации передаются только между смежными узлами (исключением являются пакеты Hello, используемые для организации отношений смежности). Это означает, что все пакеты протокола маршрутизации передаются только на один интервал (hop), за исключением пакетов, передаваемых через виртуальные соединения.

Все пакеты протокола маршрутизации используют стандартный заголовок. В следующих параграфах детально описаны правила заполнения и проверки полей заголовка. Далее приведены более детальные описания для всех типов пакетов и сведения об обработке пакетов.

8.1. Передача пакетов

Когда маршрутизатор передает пакет протокола маршрутизации, он заполняет поля стандартного заголовка OSPF, перечисленные ниже. Детальное описание формата заголовка приведено в параграфе A.3.1:

Version #

Это поле имеет значение 2 – текущий номер версии протокола в соответствии с данной спецификацией.

Packet type

Тип пакета OSPF (например, Link State Update или Hello).

Packet length

Размер всего пакета OSPF в байтах и учетом стандартного заголовка OSPF.

Router ID

Идентификатор маршрутизатора, породившего пакет.

Area ID

Идентификатор области OSPF, в которую передается пакет.

Checksum

Стандартная контрольная сумма IP для пакета OSPF в целом без учета 64-битового поля аутентификации. Эта контрольная сумма рассчитывается в процессе аутентификации и для некоторых типов аутентификации OSPF контрольная сумма не используется (см. параграф D.4).

rfc.com.ru

Перевод RFC 2328

AuType и Authentication

Весь обмен пакетами OSPF осуществляется с использованием аутентификации. Типы аутентификации задаются протоколом и описаны в Приложении D. Для каждой сети или подсети IP могут использоваться различные процедуры аутентификации. Значение AuType показывает тип используемой процедуры аутентификации. 64-битовое поле аутентификации используется выбранной процедурой проверки полномочий, которая должна вызываться при передаче сформированного пакета (см. параграф D.4). При установке IP-адреса получателя используются описанные здесь правила. В физических сетях point-to-point в качестве IP-адреса получателя всегда устанавливается значение AllSPFRouters. Для других типов сетей (включая виртуальные соединения), большинство пакетов OSPF передается с указанием точного адреса (unicast) смежного маршрутизатора - Neighbor IP (см. главу 10). В широковещательных сетях для передачи пакетов Hello используется multicast-адрес AllSPFRouters, маршрутизаторы DR и Backup DR передают пакеты Link State Update и Link State Acknowledgment также по групповому адресу AllSPFRouters, а все прочие маршрутизаторы передают пакеты Link State Update и Link State Acknowledgment по групповому адресу AllDRouters. Retransmissions of Link State Update packets are ALWAYS sent directly to the neighbor. On multi-access networks, this means that retransmissions should be sent to the neighbor's IP address.

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

Более подробные сведения о форматах различных пакетов OSPF приведены в параграфах, указанных в таблице 13.

8.2. Прием пакетов протокола

Когда пакет протокола принимается маршрутизатором, он маркируется принявшим

8.2. Прием пакетов протокола

Когда пакет протокола принимается маршрутизатором, он маркируется принявшим

пакет интерфейсом. Для маршрутизаторов, использующих виртуальные соединения,

не всегда возможно сразу определить с каким интерфейсом связан пакет. Рассмотрим

в качестве примера маршрутизатор RT11 (рисунок 4). Если RT11 принимает пакет

протокола OSPF на своем интерфейсе в сеть N8, этот пакет можно связать с


Тип 1	Таблица 13 Описания способов распространения пакетов OSPF. Название пакета Параграф Hello 9.5
2	Database description Link state request	10.8 10.9
4 5	Link state update Link state ack	13.3 13.5

интерфейсом в область 2 или виртуальным каналом к маршрутизатору RT10, являющемуся частью магистрали. При дальнейшем

рассмотрении предполагается, что пакет изначально связан не с виртуальным соединением¹⁰.

Для того, чтобы пакет был воспринят на уровне IP, он должен пройти ряд проверок еще до того, как будет передан протоколу

OSPF для обработки:

♦ Контрольная сумма IP должна совпадать с одноименным полем заголовка пакета.

♦ В качестве адреса получателя должен быть задан IP-адрес принявшего пакет интерфейса или один из групповых адресов IP (AllSPFRouters или AllDRouters).

♦ Поле протокола IP должно указывать на OSPF (89).

♦ Пакеты локального происхождения не должны передаваться протоколу OSPF - IP-адрес отправителя должен проверяться на предмет совпадения с одним из адресов принявшего пакет маршрутизатора или одним из групповых адресов.

После этого проверяется заголовок OSPF - поля, указанные в заголовке, должны совпадать со значениями, настроенными для принявшего пакет интерфейса. При отсутствии требуемого пакет должен отбрасываться:

♦ Поле версии должно содержать значение 2 (текущая версия протокола).

♦ Проверяется идентификатор области Area ID из заголовка OSPF - если не выполняется ни одно из двух перечисленных ниже условий, пакет должен быть отброшен.

(1) Идентификатор Area ID относится к области принявшего пакет интерфейса. В этом случае пакет был принят через один интервал и, следовательно, IP-адрес отправителя должен относиться к той же сети, что и адрес принявшего пакет интерфейса. Это можно проверить, сравнив IP-адрес отправителя из заголовка пакета с IP-адресом принявшего интерфейса после использования для обоих адресов маски подсети, заданной для интерфейса. Такое сравнение не должно проводиться для сетей point-to-point, в таких сетях адреса на каждой стороне соединения выделяются совершенно или могут отсутствовать вообще.

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

♦ Пакеты, отправленные по адресу AllDRouters должны приниматься только маршрутизаторами DR и Backup (см. параграф 9.1).

♦ Указанное в пакете значение AuType (тип аутентификации) должно совпадать со значением AuType для связанной с пакетом области.

♦ Выполняется процедура аутентификации пакета, указанная полем AuType (см. Приложение D). В процедуре аутентификации может использоваться один или несколько ключей Authentication, которые задаются независимо для каждого интерфейса. Процедура аутентификации может также проверять контрольную сумму полей заголовка OSPF (если эта контрольная сумма используется она представляет собой стандартную контрольную сумму IP для содержимого пакета OSPF без учета 64-битового поля аутентификации). Пакеты, не прошедшие процедуру аутентификации, должны отбрасываться.

Таблица 14 Параграфы, описывающие прием пакетов OSPF. В случае приема пакетов Hello их дальнейшая

Тип Название

1 Hello______________________________________

2 Описание базы данных (Database description)

3 Запрос состояния канала (Link state request)

Описание обработка осуществляется протоколом Hello,

10.5 описанным в параграфе 10.5. Все остальные типы

10.6 пакетов предаются только между смежными

10.7 маршрутизаторами. Это означает, что пакет должен

4 Обновление состояния канала (Link state update) 13 быть передан одним из активных соседей принявшего

5 Подтверждение состояния канала (Link state ack) 13.7 маршрутизатора. Если принимающий интерфейс

подключен к широковещательной сети, сети Point-to-

⁹ Все интерфейсы маршрутизатора могут быть подключены к безадресным каналам point-to-point. В таких случаях следует связать IP-адрес с самим маршрутизатором. Этот адрес будет анонсироваться в router-LSA как маршрут к хосту.

¹⁰ Отметим, что в таких случаях оба интерфейса (виртуальный и реальный) имеют одинаковый адрес IP.

rfc.com.ru 20 rfc.com.ru

Перевод RFC 2328

MultiPoint или NBMA, отправитель идентифицируется адресом IP в заголовке IP-пакета. Если принимающий интерфейс подключен к сети point-to-или виртуальному соединению, отправитель идентифицируется полем Router ID в заголовке пакета OSPF. Структура данных принимающего интерфейса содержит список активных соседей. Пакеты, не соответствующие любому из перечисленных выше условий, должны отбрасываться.

После проверки пакет ассоциируется с передавшим его активным соседом. Дальнейшие операции по обработке принимаемых пакетов описаны ниже в отдельных параграфах (см. таблицу 14).

9. Структура данных интерфейса

Интерфейс OSPF представляет собой соединение между маршрутизатором и сетью. Мы предполагаем один интерфейс OSPF в

каждую сеть/подсеть, хотя в приложении F рассматриваются варианты с множеством интерфейсов в одну сеть. С каждой

структурой данных интерфейса связан по крайней мере один адрес IP.

Интерфейс OSPF можно рассматривать как часть области, к которой относится соединенная с интерфейсом сеть. Все пакеты

протокол маршрутизации, передаваемые маршрутизатором через интерфейс, помечаются идентификатором Area ID

соответствующей области. Через один интерфейс может быть организовано несколько отношений смежности. Записи LSA в

маршрутизаторе отражают состояние его интерфейсов и отношения смежности.

Ниже приведен список данных, связанных с каждым интерфейсом. Отметим, что многие параметры задают конфигурацию

подключенной к интерфейсу сети и должны быть одинаковы для всех подключенных к этой сети маршрутизаторов.

Type

Интерфейсы OSPF могут быть нескольких типов - point-to-point, broadcast, NBMA, Point-to-MultiPoint или virtual link.

State

Функциональное состояние интерфейса, определяющее возможность организации отношений смежности через данный интерфейс. Состояние интерфейса отражается также в LSA маршрутизатора.

IP interface address

IP-адрес, связанный с интерфейсом. Этот адрес появляется в качестве адреса отправителя для пакетов, исходящих от данного интерфейса. Интерфейсы в безадресные сети point-to-point не имеют своего IP-адреса.

IP interface mask

Маска сети/подсети, определяющую часть IP-адреса интерфейса, обозначающую номер сети. Маскирование IP-адресов позволяет определять IP-номер подключенной к интерфейсу сети. В сетях point-to-point и виртуальных каналах маска для интерфейса не задается, поскольку в таких сетях соединение не имеет связанного с ним адреса IP, а адреса для разных сторон соединения задаются независимо или не используются совсем.

Area ID

Идентификатор области, в которую входит подключенная к интерфейсу сеть. Все пакеты протокола маршрутизации, отправляемые с данного интерфейса, помечаются значением ID.

HelloInterval

Промежуток времени (в секундах) между передачей интерфейсом двух последовательных пакетов Hello. Это значение анонсируется в передаваемых интерфейсом пакетах Hello.

RouterDeadInterval

Время (в секундах), по истечении которого соседний маршрутизатор признается неработающим. Время исчисляется от момента приема последнего пакета Hello от соседнего маршрутизатора. Значение этого параметра анонсируется в пакетах Hello.

I nfTransDelay

Оценка времени (в секундах), затрачиваемого на передачу пакета Link State Update Packet через данный интерфейс. Анонсы LSA, содержащиеся в пакете Link State Update будут увеличивать свой возраст на величину этого параметра до передачи пакета в интерфейс. Это значение должно учитывать задержки на прохождение и передачу сигнала. Параметр должен иметь положительное значение.

Router Priority

8-битовое беззнаковое целое, определяющее приоритет маршрутизатора. Когда два подключенных к сети маршрутизатора пытаются занять место DR, выбирается маршрутизатор с большим значением Router Priority. Для маршрутизаторов, которые не должны играть роль DR устанавливается Router Priority = 0. Значение этого параметра анонсируется в пакетах Hello.

Hello Timer

Интервальный таймер, используемый для передачи пакетов Hello. Этот таймер запускается каждые HelloInterval секунд. Отметим, что в сетях без широковещания пакеты Hello передаются по отдельности каждому соседу.

Wait Timer

Однократный таймер, вынуждающий интерфейс выходить из состояния Waiting (ожидание) и, как следствие, выбирать маршрутизатор DR в сети. Время отсчета этого таймера составляет RouterDeadInterval.

List of neighboring routers

Список всех прочих маршрутизаторов, подключенных к данной сети, который формируется протоколом Hello. С некоторыми из соседних er или DR) для подключенной к интерфейсу сети. Маршрутизаторы DR выбираются в широковещательных и NBMA-сетях протоколом Hello. Для маршрутизатора DR сохраняются два параметра -Router ID и IP-адрес интерфейса в данную сеть. Маршрутизатор DR анонсирует состояние канала для сети; анонс network-LSA помечается IP-адресом маршрутизатора DR. При инициализации поле Designated Router принимает значение 0.0.0.0, говорящее об отсутствии в сети маршрутизатора DR.

Backup Designated Router

Маршрутизатор Backup DR также назначается для всех широковещательных и NBMA-сетей с помощью протокола Hello. Все маршрутизаторы сети являются смежными как с DR, так и с Backup DR. Маршрутизатор Backup Designated Router переходит в состояние DR, если текущий маршрутизатор DR «падает». При инициализации Backup DR принимает значение 0.0.0.0, говорящее об отсутствии в сети маршрутизатора Backup DR.

Interface output cost(s)

Стоимость передачи пакета данных через интерфейс, выраженная в единицах метрики link state. Это значение анонсируется как стоимость для данного интерфейса в пакетах router-LSA. Стоимость должна иметь положительное значение.

RxmtInterval

Период (в секундах) повтора передачи LSA для смежных узлов данного интерфейса. Этот же период используется для повтора передачи пакетов Database Description и Link State Request.

AuType

rfc.com.ru

Перевод RFC 2328

Тип аутентификации, используемой в подключенной к интерфейсу сети/подсети. Описание типов аутентификации приведено в Приложении D. Весь обмен пакетами OSPF осуществляется с использованием аутентификации. В разных сетях/подсетях могут использоваться различные варианты аутентификации.

Authentication key

Эти задаваемые административно данные позволяют процедуре аутентификации генерировать и/или проверять пакеты протокола OSPF. Ключи аутентификации можно независимо задавать для каждого интерфейса. Например, если полу AuType указывает на использование простого пароля, Authentication key будет содержать 64-байтовое значение пароля, помещаемое в заголовок пакета OSPF без шифрования. Если для Autype указана криптографическая аутентификация (Cryptographic) поле Authentication key будет содержать открытый ключ (shared secret), позволяющий генерировать/проверять цифровые подписи (message digests), добавляемые к пакетам протокола OSPF. При использовании криптографической аутентификации поддерживается множество ключей, что позволяет обеспечить эффективную работу системы аутентификации (см. параграф D.3).

9.1. Состояния интерфейса

В этом параграфе описаны различные состояния, в которых может находиться интерфейс маршрутизатора. Состояния перечислены в порядке расширения их функциональности. Например, нерабочее состояние указано первым, после чего следует набор промежуточных состояний и заканчивается список полнофункциональным состоянием интерфейса. В данной спецификации будет сохраняться такой порядок состояний и могут встречаться фразы типа: «интерфейс находится в состоянии, более высоком по сравнению с X". На рисунке 7 показан граф состояний интерфейса. Дуги графа отмечены событиями, вызывающими смену состояния интерфейса. Эти события описаны в параграфе 9.2. Машина состояний интерфейса описана в параграфе 9.3.

Down

Изначальное состояние интерфейса, в котором протоколы нижних уровней показывают, что интерфейс неработоспособен. Никакой трафик не может быть передан или принят через неактивный интерфейс. В этом состоянии для параметров интерфейса должны быть установлены начальные значения. Все таймеры должны быть отключены и не должно существовать отношений смежности, связанных с неактивным интерфейсом.

Loopback

В этом состоянии интерфейс маршрутизатора в сеть закольцован (петля, шлейф, loopback) на программном или аппаратном уровне. Интерфейс не может использоваться для реальной передачи данных. Однако в таком состоянии желательно получать информацию о работе интерфейса с помощью пакетов ICMP (ping) или за счет использования тестового оборудования (скажем, BER-тестера). По этой причине могут появляться пакеты IP, адресованные интерфейсу, который находится в состоянии Loopback. Для упрощения процедур шлейфовой проверки интерфейсов они анонсируются в router-LSA как маршруты к хосту, адрес которого совпадает с IP-адресом проверяемого интерфейса¹¹.

Waiting

В этом состоянии маршрутизатор пытается определить наличие в сети маршрутизатора (Backup) DR. Для решения этой задачи маршрутизатор использует мониторинг принимаемых пакетов Hello. Маршрутизатор не может занимать место Backup DR или DR, пока он не выйдет из состояния Waiting. Это позволяет избавиться от ненужных замен маршрутизатора (Backup) DR.

Point-to-point

Интерфейс работает и соединен с физической сетью point-to-point или виртуальным каналом. При переходе в это состояние маршрутизатор пытается оформить отношения смежности с соседним маршрутизатором. Соседу передаются пакеты Hello с периодом HelloInterval.

DR Other

Интерфейс соединен с широковещательной или NBMA-сетью, в которой уже присутствует выделенный маршрутизатор DR. В этом состоянии данный маршрутизатор не может быть назначен в качестве Backup DR. Маршрутизатор формирует отношения смежности с DR и Backup DR (если он назначен).

Backup

Маршрутизатор используется в качестве Backup DR для подключенной сети. При сбоях основного маршрутизатора DR его место займет данный маршрутизатор. Маршрутизатор формирует отношения смежности со всеми остальными маршрутизаторами подключенной сети. Функции Backup DR несколько отличаются от функций DR в процессе лавинной рассылки Flooding Procedure, (см. параграф 13.3). Детальное описание функций маршрутизатора Backup DR приведено в параграфе 7.4.

Маршрутизатор выполняет функции DR для подключенной к нему сети и формирует отношения смежности со всеми остальными маршрутизаторами сети. Выделенный маршрутизатор генерирует для сетевого узла анонсы network-LSA, содержащие ссылки на все маршрутизаторы (включая DR), подключенные к сети. Функции выделенного маршрутизатора DR подробно описаны в параграфе 7.3.

9.2. События, изменяющие состояние интерфейса

Состояния интерфейса могут меняться в результате различных событий, показанных на рисунке 7. Приведенные на рисунке метки событий описаны ниже, а детальное рассмотрение этих событий на работу OSPF содержится в параграфе 9.3.

InterfaceUp

Протоколы нижележащих уровней показали работоспособность сетевого интерфейса. Это позволяет интерфейсу выйти из состояния Down. На виртуальных каналах активизация интерфейса ведет к расчету кратчайшего пути (см. параграф 16.7).

WaitTimer

Включен таймер Wait, показывающий окончание периода ожидания перед назначением (Backup) DR.

BackupSeen

Маршрутизатор обнаружил наличие или отсутствие в сети Backup DR. Такое детектирование может выполняться двумя способами – по приему от соседа пакета Hello, содержащего анонс соседнего маршрутизатора как Backup DR или по приему от соседа пакета Hello, содержащего анонс DR и сведения об отсутствии Backup DR. В любом случае с соседом должна быть двухсторонняя связь, т. е., данный маршрутизатор должен также появиться в пакете от соседа. Это событие говорит о завершении состояния Waiting.

NeighborChange

¹¹ Что для интерфейсов в безадресные сети point-to-point не генерируется анонсов маршрута к хосту или тестовых IP-пакетов независимо от состояния такого интерфейса.

rfc.com.ru 22 rfc.com.ru

Перевод RFC 2328

Это событие связано с изменениями набора +----+ Unlooplnd +--------+

соседей данного интерфейса, с которыми |Down|<-------------|Loopback|

осуществляется двухсторонняя связь. В +---+ +-------+

результате требуется перерасчет |

выделенного маршрутизатора (Backup) DR. |InterfaceUp

Событие NeighborChange может быть +-------+ | +-------------+

вызвано одной из перечисленных ниже |Waiting|<-+-------------->|Point-to-point |

причин (описания состояний соседей +-------+ +-------------+

приведены в параграфе 10.1): |

♦ Организована двухсторонняя связь с WaitTimer IBackupSeen соседом (состояние соседа перешло на |

уровень 2-Way или выше). |

♦ Прервана двухсторонняя связь с I NeighborChange

соседом (состояние соседа перешло на +------+ +-+<----------------+-------+

уровень Init или ниже). |Backup|<----------|?|----------------->|DROther|

♦ Один из соседей с двухсторонней +------+---------->+-+<-----+ +-------+

связью недавно обозначил себя в Neighbor | |

качестве DR или Backup DR Change | |Neighbor

(определяется из пакетов Hello от I |Change

этого соседа). I +~+

♦ Один из соседей с двухсторонней +---->IDR|

связью перестал играть роль DR или + +

Backup DR (определяется из пакетов Рисунок 7. Смена состояний интерфейса

Hello от этого соседа). В дополнение к показанным на графе переходам событие InterfaceDown всегда

♦ Изменилось анонсируемое значение приводит к состоянию Down,а LoopInd – к состоянию Loopback. Router Priority для соседа с

двунаправленной связью (определяется из пакетов Hello от этого соседа).

LoopInd

Принята индикация перевода интерфейса в состояние loopback (эта информация может быть получена от программ сетевого управления или протоколов нижележащих уровней).

UnloopInd

Принята индикация выхода интерфейса из состояния loopback. Как и для события LoopInd, эта информация может быть получена от программ сетевого управления или протоколов нижележащих уровней.

InterfaceDown

Протокол нижележащего уровня сообщил об утрате интерфейсом работоспособности. Независимо от текущего состояния интерфейса он должен быть переведен в состояние Down.

9.3. Машина состояний интерфейса

Ниже приводится детальное описание изменений в состояниях интерфейсов. Каждое такое изменение вызывается событиями,

перечисленными в параграфе 9.2. Результат событий зависит от текущего состояния интерфейса, поэтому приведенные ниже

описания используют в качестве отправной точки текущее состояние интерфейса. Каждая запись в машине состояний интерфейса

описывает переход в новое состояние и требуемые действия.

При изменении состояния интерфейса может потребоваться генерация нового анонса router-LSA (см. параграф 12.4).

Некоторые из перечисленных ниже действий включают генерацию событий для машины состояний соседа. Например, при

прекращении работы интерфейса должны быть уничтожены все записи о соседстве этого интерфейса. Дополнительная

информация о машине состояний соседа приведена в параграфе 10.3.

Состояние: Down

Событие: InterfaceUp

Новое состояние: В зависимости от предпринятых действий

Действия: Начало нового отсчета таймера Hello, задающего периодическую рассылку пакетов Hello данным интерфейсом. Если

интерфейс подключен к физической сети point-to-point, сети Point-to-MultiPoint или виртуальному соединению, он переводится в

состояние Point-to-Point. Для широковещательных сетей и сетей NBMA интерфейс переводится в состояние DR Other, если для

маршрутизатора нежелательна работа в качестве DR. Если же маршрутизатор может играть роль DR для подключенной сети,

интерфейс переводится в состояние Waiting и запускается таймер Wait Timer. Кроме того, в сетях NBMA проверяется список

соседей интерфейса и генерируется событие Start для каждого из соседей, который тоже может стать DR.

Состояние: Waiting

Событие: BackupSeen

Новое состояние: В зависимости от предпринятых действий.

Действия: Определяются маршрутизаторы Backup DR и DR (см. параграф 9.4). В результате завершения расчетов интерфейс

будет переведен в состояние DR Other, Backup или DR.__________________________________________________________________

Состояние: Waiting

Событие: WaitTimer

Новое состояние: В зависимости от предпринятых действий.

будет переведен в состояние DR Other, Backup или DR.__________________________________________________________________

Состояние: DR Other, Backup или DR

Событие: NeighborChange

Новое состояние: В зависимости от предпринятых действий.

Действия: Заново определяются маршрутизаторы Backup DR и DR (см. параграф 9.4). В результате завершения расчетов

интерфейс будет переведен в состояние DR Other, Backup или DR.________________________________________________________

Состояние: Любое

Событие: InterfaceDown

Новое состояние: Down

Действия: Сбрасываются все связанные с интерфейсом переменные, отключаются таймеры интерфейса и удаляются все

отношения соседства (путем генерации события KillNbr для всех соседей - см. параграф 10.2).________________________________

Состояние: Любое Событие: LoopInd

rfc.com.ru 23 rfc.com.ru

Перевод RFC 2328

Новое состояние: Loopback

Действия: Поскольку интерфейс в таком состоянии больше не связан с подключенной сетью, выполняются операции, связанные

с описанным выше событием InterfaceDown.

Состояние: Loopback

Событие: UnloopInd

Новое состояние: Down

Действия: Не требуется выполнения каких-либо действий (например, все связанные с интерфейсом переменные уже были

сброшены при переходе в состояние Loopback). Отметим, что для перехода интерфейса в рабочее состояние он должен получить

сигнал InterfaceUp.

9.4. Назначение DR

В этом параграфе описан механизм назначения выделенных маршрутизаторов DR и Backup DR, используемых машиной состояний Interface. Сначала маршрутизатор запускает механизм выбора выделенного маршрутизатора для сети. Значения DR и Backup DR равны 0.0.0.0 – это говорит об отсутствии в сети как DR, так и Backup DR.

Рассмотрим механизм назначения DR более подробно, обозначив маршрутизатор, делающий расчет, как Router X. Проверяется список соседей, подключенных к сети и организовавших двухстороннюю связь с Router X. Этот список в точности совпадает с набором соседей Router X (в той же сети), чьи состояния не ниже 2-Way (см. параграф 10.1). Маршрутизатор Router X также присутствует в этом списке. Сначала из списка исключаются все маршрутизаторы, которые нежелательно использовать в качестве DR (маршрутизаторы с Router Priority = 0 не могут быть DR). После этого для оставшихся в списке маршрутизаторов выполняются следующие операции:

(1) Фиксируются текущие значения для DR и Backup DR, которые будут потом использоваться для сравнения.

(2) Определяется новый маршрутизатор Backup DR с учетом только тех маршрутизаторов, которые не заявили о своем нежелании выступать в качестве Backup DR. Если на роль Backup DR претендует (т. е., указали себя в качестве Backup DR, но не DR в своих пакетах Hello) один или несколько маршрутизаторов, среди них выбирается тот, для которого задан высший приоритет Router Priority. Если высший приоритет заявлен для нескольких маршрутизаторов, выбирается тот, у которого больше значение Router ID. Если ни один маршрутизатор не заявлен как Backup DR, выбирается маршрутизатор с наибольшим Router Priority среди тех маршрутизаторов, которые не заявили себя в качестве DR (если таких маршрутизаторов окажется несколько, снова используется Router ID).

(3) Определяется новый маршрутизатор DR для сети. Если на роль DR претендует (т. е., указали себя в качестве DR в своих пакетах Hello) один или несколько маршрутизаторов, среди них выбирается тот, для которого задан высший приоритет Router Priority. Если высший приоритет заявлен для нескольких маршрутизаторов, выбирается тот, у которого больше значение Router ID. Если ни один маршрутизатор не заявлен как DR, в качестве выделенного маршрутизатора выбирается назначенный в последний раз Backup DR.

(4) Если маршрутизатор Router X стал (Backup) DR или наоборот, утратил это значение, повторяются п.п. 2 и 3, а затем выполняется пункт 5. Пусть Router X играет роль DR, тогда при повторении п. 2 для X уже невозможно назначение на роль Backup DR. Наряду с другими мерами это предотвращает захват функций DR и Backup DR одним маршрутизатором¹².

(5) В результате проведения расчетов маршрутизатор сам может занять место DR или Backup DR (см. параграфы 7.3 и 7.4, содержащие детальное описание). Состояние интерфейса маршрутизатора соответствующим образом изменяется. Если маршрутизатор занял место DR, интерфейс перейдет в состояние DR. Интерфейс маршрутизатора, ставшего Backup DR, перейдет в состояние Backup. В остальных случаях интерфейс переходит в состояние DR Other.

(6) Если подключенная сеть относится к типу NBMA, а маршрутизатор является DR или Backup DR, он должен начать передачу пакетов Hello тем из соседей, которые не могут стать DR (см. параграф 9.5.1). Это осуществляется созданием события Start для каждого из соседей с Router Priority = 0.

(7) Если описанные расчеты привели к смене DR или Backup DR, требуется обновить набор отношений смежности, связанных с данным интерфейсом – для этого может потребоваться организация новых отношений смежности или удаление существовавших ранее. Для обновления отношений смежности вводится событие AdjOK? для всех соседей, состояние которых не ниже 2-Way. Это событие приводит к пересмотру отношений смежности (см. параграфы 10.3 и 10.4).

Усложнение механизма назначения выделенного маршрутизатора обусловлено желанием обеспечить упорядоченный переход от Backup DR к DR при сбоях в работе текущего маршрутизатора DR. Упорядоченность перехода обеспечивается за счет введения гистерезиса (запаздывания, прим. перев.) – новый маршрутизатор Backup DR не может быть назначен, пока прежний маршрутизатор не примет на себя функции DR.

Описанная выше процедура может привести к выбору одного маршрутизатора в качестве DR и Backup DR, хотя этого никогда не может случиться с маршрутизатором, проводящим вычислений для выбора маршрутизатора (в нашем примере Router X). Выбранный маршрутизатор DR не обязательно имеет наибольшее значение Router Priority, а Backup DR не обязан иметь второе по порядку значение Router Priority. Если Router X не может стать DR, возможно, что приведенные выше процедуры не позволят назначить ни Backup DR, ни DR. Отметим также, что в тех случаях, когда Router X является единственным маршрутизатором, способным стать DR, он может назначить себя на роль DR, а маршрутизатор Backup DR просто не будет выбран для сети.

9.5. Передача пакетов Hello

Пакеты Hello передает каждый работающий интерфейс маршрутизатора. Эти пакеты служат для организации и поддержки соседских отношений¹³. В широковещательных и NBMA-сетях пакеты Hello используются также при выборе DR и Backup DR. Формат пакетов Hello рассмотрен в параграфе A.3.2. Пакеты Hello содержат значения Router Priority (для выбора DR) и HelloInterval (интервала между пакетами Hello передаваемыми интерфейсом). Пакет Hello также показывает, как часто должно быть слышно соседа для осознания его работоспособности (RouterDeadInterval). Значения HelloInterval и RouterDeadInterval должны быть одинаковы для всех маршрутизаторов, подключенных к одной сети. Пакеты Hello также содержат маску IP для подключенной сети (Network Mask); для безадресных сетей point-to-point и виртуальных каналов это поле должно иметь значение 0.0.0.0.

¹² Будет поучительно рассмотреть ситуацию, когда маршрутизатор DR перестает работать. Пусть функции DR выполняет маршрутизатор RT1, а Backup DR - RT2. Если RT1 «падает» (или прекращает работать интерфейс в данную сеть), другие маршрутизаторы смогут обнаружить отсутствие RT1 в течение RouterDeadInterval. Все маршрутизаторы не смогут обнаружить отсутствие выделенного маршрутизатора одновременно. В результате маршрутизатор, обнаруживший отсутствие RT1 до того, как это удалось сделать RT2 на некоторое время выберет RT2 в качестве DR и Backup DR одновременно. Когда RT2 обнаружит отсутствие RT1, он объявит себя DR. Одновременно с этим произойдет назначение маршрутизатора с высшим значением Router Priority на роль Backup DR.

¹³ В сетях point-to-point наличие и работоспособность соседа проверяется протоколами нижних уровней с соответствующей индикацией. Для виртуальных каналов существование соседей определяется при расчете таблицы маршрутизации. Однако в том и другом случае по-прежнему используется протокол Hello. Это обеспечивает между соседями двухстороннюю связь и дает гарантию работоспособности протокола маршрутизации на соседнем маршрутизаторе.

rfc.com.ru 24 rfc.com.ru

Перевод RFC 2328

Поле Options в пакетах Hello описывает дополнительные возможности OSPF, определенные в данной спецификации (см. параграфы 4.5 и A.2). Бит E в поле Options устанавливается тогда и только тогда, когда подключенная область может обрабатывать анонсы AS-external-LSA (т. е., не является тупиковой). Если бит E установлен некорректно, соседние маршрутизаторы не будут воспринимать пакеты Hello (см. параграф 10.5). Непонятные биты поля Options должны иметь нулевые значения.

Для обеспечения двухсторонней связи между маршрутизаторами, пакеты Hello содержат список всех маршрутизаторов сети, от которых недавно были приняты пакеты Hello. Пакет Hello также содержит текущий выбор маршрутизатора для DR и Backup DR (0.0.0.0 в этих полях говорит о том, что эти маршрутизаторы еще не выбраны).

В широковещательных сетях и физических сетях point-to-point пакеты Hello передаются с интервалом HelloInterval по групповому адресу AllSPFRouters. В виртуальных соединениях пакеты Hello передаются по конкретному адресу на другую сторону виртуального канала каждые HelloInterval секунд. В сетях Point-to-MultiPoint пакеты Hello раздельно передаются каждому подключенному соседу с интервалом HelloInterval. Передача пакетов Hello в сетях NBMA описана ниже.

9.5.1. Передача пакетов Hello в сети NBMA

Для работы протокола Hello в сетях без широковещания может потребоваться специальная настройка (см. параграфы C.5 и C.6). В сетях NBMA каждый подключенный маршрутизатор, который может быть выбран DR, знает всех своих соседей по сети (для этого может потребоваться специальная настройка или дополнительный механизм). Для каждого соседа создается метка возможности использования в качестве DR.

Для передачи пакетов Hello в сетях NBMA интерфейс должен иметь состояние не ниже Waiting. Пакеты Hello передаются напрямую (unicast) некоторому подмножеству соседей маршрутизатора. В некоторых случаях пакеты Hello передаются периодически, а в иных ситуациях – в ответ на принятый пакет Hello. Поведение маршрутизатора в части передачи этих пакетов зависит от возможности данного маршрутизатора выполнять функции DR.

Если маршрутизатор может стать DR, он должен периодически посылать пакеты Hello тем соседям, которые также могут быть DR. В дополнение к этому маршрутизаторы, играющие роль DR или Backup DR, должны передавать пакеты Hello всем своим соседям. Это означает, что любая пара маршрутизаторов, способных быть DR, постоянно обменивается пакетами Hello, которые нужны для корректной работы механизма выбора DR. Для минимизации числа передаваемых пакетов Hello число претендентов на роль DR в сетях NBMA должно быть небольшим.

Если маршрутизатор не может стать DR, он должен периодически передавать пакеты Hello маршрутизаторам DR и Backup DR (если он задан). Кроме того, пакеты Hello должны передаваться в ответ на прием пакетов Hello от соседей, способных быть DR, но не являющихся DR или Backup DR. Это требуется для организации начальной двухсторонней связи с любым потенциальным DR. Когда пакеты Hello периодически отправляются всем соседям, интервал между пакетами Hello определяется состоянием соседа. Если сосед находится в состоянии Down, пакеты Hello передаются каждые PollInterval секунд, в остальных случаях интервал передачи Hello составляет HelloInterval секунд.

10. Структура данных Neighbor

Маршрутизаторы OSPF обмениваются данными со своими соседями. В каждом случае обмена используются структуры данных neighbor (сосед). Факт обмена данными ограничен конкретным интерфейсом маршрутизатора OSPF, а для идентификации сеанса используется Router ID соседнего маршрутизатора адрес Neighbor IP (см. ниже). Если маршрутизатор OSPF и второй маршрутизатор подключены к нескольким сетям, возникает множество сеансов обмена данными, каждое из которых описывается уникальной структурой данных о соседе. Каждый отдельный «разговор» между маршрутизаторами будем рассматривать как обмен данными с отдельным соседом.

Структура данных о соседе содержит всю информацию, относящуюся к формируемым или существующим отношениям смежности между двумя соседями (напомним, что не все соседи являются смежными). Смежность можно рассматривать как расширенную форму «разговора» между двумя маршрутизаторами.

State

Функциональный уровень обмена данными между маршрутизаторами, описанный в параграфе 10.1.

Inactivity Timer

Однократный таймер, активизируемый при отсутствии пакета Hello от соседа (отсчет RouterDeadInterval секунд).

Master/Slave

При обмене базами данных между соседями используются отношения «ведущий-ведомый» (master/slave). Ведущий маршрутизатор передает пакет Database Description (это единственная част обмена, которую при необходимости можно повторять). Ведомый маршрутизатор может только отвечать на пакеты Database Description. Отношения ведущий ведомый согласуются в состоянии ExStart.

DD Sequence Number

Порядковый номер пакета Database Description (далее DD, прим. перев.), передаваемого в настоящий момент соседу.

Last received Database Description packet

Биты I (инициализация), M (дополнение) и MS (ведущий), полк Options и порядковый номер DD, содержавшиеся в последнем пакете DD, полученном от соседа. Эти данные используются для обнаружения дубликатов пакетов DD.

Neighbor ID

Идентификатор OSPF Router ID соседнего маршрутизатора. Значение Neighbor ID определяется из пакета Hello, полученного от соседа, или задается административно для случаев виртуальной смежности (см. параграф C.4).

Neighbor Priority

Значение Router Priority для соседнего маршрутизатора, получаемое из пакета Hello и используемое при выборе DR для подключенной сети.

Neighbor IP address

IP-адрес интерфейса соседнего маршрутизатора в подключенную сеть. Этот адрес используется как Destination IP при передаче пакетов в режиме unicast. Кроме того, это значение используется как параметр Link ID для подключенной сети в анонсах router-LSA, если соседний маршрутизатор выбран в качестве DR (см. параграф 12.4.1). Адрес Neighbor IP определяется из пакетов Hello, принятых от соседа. Для виртуальных каналов адрес Neighbor IP определяется в процессе построения таблицы маршрутизации (см. главу 15).

Neighbor Options

Дополнительные возможности OSPF, поддерживаемые соседом. Это значение определяется в процессе Database Exchange (см. параграф 10.6). Дополнительные возможности OSPF сосед также указывает в своих пакетах Hello. Это позволяет отбрасывать принятые пакеты Hello (даже не начав формирование соседских отношений), при рассогласовании некоторых важных опций OSPF (см. параграф 10.5). Дополнительные возможности OSPF описаны в параграфе 4.5.

Neighbor's Designated Router

Соображения соседа по поводу выделенного маршрутизатора DR. Если сосед предлагает себя как DR, это важно принимать во внимание при локальном расчете DR.Этот параметр определен только для широковещательных и NBMA-сетей.

rfc.com.ru

Перевод RFC 2328

Neighbor's Backup Designated Router

Соображения соседа по поводу Backup DR. Если сосед предлагает себя в этом качестве, это важно принимать во внимание при локальном расчете Backup DR.Этот параметр определен только для широковещательных и NBMA-сетей. Остальные переменные являются списками LSA. Три списка описывают подмножество базы данных link-state. В этом документе определяется пять различных типов LSA, каждый из которых может присутствовать в базе данных области: router-LSA, network-LSA, summary-LSA типов 3 и 4 (эти 4 типа хранятся в структуре данных области), а также AS-external-LSA (хранится в отдельной глобальной структуре данных).

Link state retransmission list

Список LSA, которые были разосланы в лавинном режиме, но не подтверждены для данной смежности. Эти анонсы будут повторяться до тех пор, пока не будет получено подтверждение или разорваны отношения смежности.

Database summary list

Полный список LSA, собранных в базу данных области к моменту перехода соседа в состояние Database Exchange. Этот список передается соседу в пакетах DD.

Link state request list

.Список LSA, которые требуется получить от соседа для синхронизации с ним базы данных. Этот список создается когда принят пакет DD и передается соседу в пакетах Link State Request. Этот список очищается по мере получения соответствующих пакетов Link State Update.

10.1. Состояния соседей

Состояние соседа (реально, состояние «разговора» с

соседним маршрутизатором) описано в

последующих параграфах. Состояния

прослушиваются для выполнения требуемых

функций. Например, сначала прослушивается

нерабочее (inoperative) состояние, после которого

проходит несколько промежуточных состояний пока

не будет достигнуто финальное. В спецификации

+----+

I Down|

+----+

Hello Received

\Start

\ +-------+

+---->|Attenpt|

+-------+

используется перечисленный ниже порядок

состояний как некая иерархия и в тексте

встречаются фразы типа "состояние не ниже X". На

рисунках 8 и 9 показаны графы изменения состояний

соседа. Дуги графа помечены именами событий,

вызывающих смену состояния. Описание этих

событий приводится в параграфе 10.2.

Граф на рисунке 8 показывает изменения состояний,

связанные с протоколом Hello. Этот протокол

+ ------- +

|ExStart|<----

+----+<-+

|Init|<-------

+----+<-------

|2-Way |Received I

I +----+------->|2

|HelloReceived

11-Way

|Received

---+

Way |

отвечает за организацию и поддержку соседских

отношений, а также обеспечивает двухстороннюю

связь между соседями.

Граф на рисунке 9 показывает формирование

+ ------- + + ----- +

Рисунок 8. Смена состояний соседа (протокол Hello)

В дополнение к показанным переходам события KillNbr, InactivityTimer и

LLDown всегда приводят к состоянию Down.

отношений смежности (не каждая пара соседей

поддерживает отношения смежности – см. параграф 10.4). Организация этих отношений начинается при состоянии соседа ExStart.

После того, как пара маршрутизаторов согласует отношения ведущий-ведомый, состояние меняется на Exchange. С этого момента

сосед начинает процедуру лавинной рассылки (flooding procedure) и начинается процесс синхронизации баз данных двух

маршрутизаторов. По завершении синхронизации сосед переходит в состояние Full и маршрутизаторы становятся полностью

смежными. С этого момента смежность указывается в анонсах LSA.

Более детальное описание переходов состояний соседа и связанных с этим допол

Down

Начальное состояние разговора с соседом, показывающее, что от соседа в последнее время не приходило информации. В сетях NBMA сообщения Hello могут передаваться соседям в состоянии Down (частота передачи снижается, см. параграф 9.5.1).

Attempt

Это состояние корректно только для соседей, подключенных к сетям NBMA, и показывает, что в последнее время от соседа не поступало информации, но попытки ее получения должны продолжаться путем передачи пакетов Hello с интервалом HelloInterval (см. параграф 9.5.1).

+ ------- +

|ExStart|

+ ------- +

| NegotiationDone|

+->+ -------- +

|Exchange|

+--+ -------- +

Exchange|

Done |

+----+ | + ------- +

|Full|< --------- + ----- >|Loading|

+----+<-+ + ------- +

| LoadingDone | + ------------------ +

Рисунок 9. Смена состояний соседа (Database

Exchange)

В дополнение к показанным на рисунке переходам

события SeqNumberMismatch и BadLSReq

приводят к состоянию ExStart,

событие 1-Way – к состоянию Init, а события

KillNbr, InactivityTimer и LLDown – к состоянию

Down. Событие AdjOK? ведет к формированию

или разрыву смежности.

Init

Это состояние говорит о недавнем приеме пакета Hello от соседа, с которым еще не организована двухсторонняя связь (т. е., данный маршрутизатор еще не включен в пакет Hello от соседа). Все соседи в этом (и более высоких) состоянии указываются в пакетах Hello, передаваемых связанным с ними интерфейсом.

2-Way

Между соседями организована двухсторонняя связь, обеспечивающая работу протокола Hello. С этого состояния начинается организация отношений смежности. Маршрутизаторы (Backup) DR выбираются из числа соседей в состоянии 2-Way или выше.

ExStart

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

более высоких состояниях называют отношениями смежности (adjacency).

Exchange

В этом состоянии маршрутизатор полностью описывает свою базу данных link state, посылая пакеты DD своему соседу. Каждый пакет DD имеет порядковый номер и прием пакета должен явно подтверждаться. Только пакеты DD допускается передавать в любой момент. В этом состоянии могут также передаваться пакеты Link State Request для получения от соседа

rfc.com.ru

Перевод RFC 2328

свежих LSA. Смежные узлы в состоянии Exchange и выше используют лавинную рассылку. Фактически отношения смежности позволяют принимать и передавать все типы пакетов протокола OSPF.

Loading

В этом состоянии соседу передаются пакеты Link State Request для получения свежих LSA, которые были обнаружены (но еще не получены) в состоянии Exchange.

Full

В этом состоянии обеспечивается полная смежность соседних маршрутизаторов. Отношения смежности отражаются в анонсах router-LSA и network-LSA.

10.2. События, меняющие состояние соседа

Изменения состояний могут быть связаны с различными событиями, описанными ниже (названия событий служат метками дуг графа на рисунках 8 и 9):

HelloReceived

Получен пакет Hello от соседа.

Start

Соседу нужно отправить пакет Hello в течение HelloInterval секунд (только для соседей, связанных с сетями NBMA).

2-Way Received

Между двумя соседними маршрутизаторами организована двухсторонняя связь. Такая связь отражается появлением маршрутизатора в пакетах Hello от соседа.

NegotiationDone

Согласованы отношения Master/Slave и порядковые номера DD. Это событие служит сигналом для начала приема/передачи пакетов DD. Дополнительные сведения об этом событии приведены в параграфе 10.8.

ExchangeDone

Оба маршрутизатора успешно завершили передачу всех пакетов DD. Каждый маршрутизатор сейчас знает, что часть его базы данных устарела. Дополнительные сведения об этом событии приведены в параграфе 10.8.

BadLSReq

Получен пакет Link State Request для записи LSA, отсутствующей в базе данных. Это говорит об ошибке в процессе DE.

Loading Done

Получены пакеты Link State Update для всех устаревших записей базы данных. Это событие указывается пустым списком в запросе Link state после завершения процесса обмена базами данных (DE).

AdjOK?

Требуется принятие решения об организации/поддержке отношений смежности с соседом. Это событие ведет к началу

формирования отношений смежности и разрыву существующих отношений. Перечисленные далее события заставляют снижать уровень соседских отношений. В отличие от перечисленных выше эти события могут происходить при любом состоянии соседских отношений.

SeqNumberMismatch

Принят пакет DD, который содержит a) некорректный порядковый номер DD, b) неожиданно установленный бит Init или c) значение поля Options, отличающегося от значения Options в последнем пакете DD. Любое из перечисленных условий говорит о наличии ошибки в процессе организации смежности.

1-Way

От соседа получен пакет Hello, в котором не упомянут данный маршрутизатор – отсутствует двухсторонняя связь.

KillNbr

Невозможна какая-либо связь с соседом и требуется перейти в состояние Down.

I nactivityTimer

Активизирован таймер бездействия в результате отсутствия пакетов Hello от соседа. Сосед переводится в состояние Down.

LLDown

Информация от нижележащих протоколов о недоступности соседа. Например, сеть X.25 может показывать такие ситуации с явно с указанием причин и данных диагностики. Это событие переводит соседа в состояние Down.

10.3. Машина состояний Neighbor

Ниже приводится детальное описание смены состояний с указанием вызвавшего смену события (см. параграф 10.2). События

могут иметь различные эффекты в зависимости от текущего состояния соседа. Поэтому машина состояний описывается с учетом

текущего состояния и принятого события. Каждая запись содержит сведения о новом состоянии и требуемых действиях.

При смене состояния соседа может потребоваться повтор процедуры выбора маршрутизатора DR. Это определяется генерацией

события NeighborChange (см. параграф 9.2). Если интерфейс находится в состоянии DR (данный маршрутизатор является DR),

изменения состояния соседа будет приводить к генерации нового анонса network-LSA (см. параграф 12.4).

Когда машине состояний соседа требуется привлечение машины состояний интерфейса, это должно выполняться как

запланированная задача (см. параграф 4.4). Это упрощает работу протокола и предотвращает рекурсивные вызовы машины

состояний.

Состояние: Down

Событие: Start

Новое состояние: Attempt

Д ействия: Передается пакет Hello соседу (это сосед всегда связан с сетью NBMA) и запускается таймер Inactivity для этого

соседа. Большое значение этого таймера говорит о невозможности связи с соседом.

Состояние: Attempt

Событие: HelloReceived

Новое состояние: Init

Д ействия: Заново запускается таймер Inactivity для соседа, поскольку от него была получена информация.

Состояние: Down

Событие: HelloReceived

Новое состояние: Init

Д ействия: Запускается таймер Inactivity для соседа. Большое значение этого таймера говорит о неработоспособности соседа.

Состояние: Init or greater

Событие: HelloReceived

Новое состояние: Состояние не меняется.

Д ействия: Заново запускается таймер Inactivity для соседа, поскольку от него была получена информация.

Состояние: Init

Событие: 2-WayReceived

rfc.com.ru 27 rfc.com.ru

Перевод RFC 2328

Новое состояние: Зависит от предпринятых действий.

Действия: Определяется необходимость организации отношений смежности с соседом (см. параграф 10.4). Если смежность не требуется, сохраняется состояние 2-Way, в противном случае для соседа вводится состояние ExStart. После смены состояния маршрутизатор увеличивает значение счетчика порядковых номеров DD в базе данных соседа. Если это происходит впервые с момента организации смежности, для порядкового номера DD должно быть выбрано уникальное значение (например, на основе текущего времени). После этого маршрутизатор объявляет себя ведущим (устанавливается значение master для бита master/slave) и начинает передачу пакета DD с установленными битами I, M и MS. Остальные поля этого пакета DD должны быть пустыми. Передача пакета DD должна повторятся с интервалом RxmtInterval до перехода в следующее состояние (см. параграф 10.8). Состояние: ExStart Событие: NegotiationDone Новое состояние: Exchange

Действия: Маршрутизатор должен перечислить содержимое своей базы данных LS (link state) для всей области в списке Database summary для соседа. База данных для области включает router-LSA, network-LSA и summary-LSA, содержащиеся в структуре данных области, вместе с AS-external-LSA, содержащимися в глобальной структуре данных. Записи AS-external-LSA опускаются из списка баз данных виртуальных соседей, а также для случая тупиковых областей (см. параграф 3.6). Взамен их в список добавляются LSA, возраст которых равен MaxAge. Резюме списка Database summary будут передаваться соседу в пакетах DD. Каждый пакет DD имеет порядковый номер и прием пакета должен явно подтверждаться. Только для пакетов DD допустима передача в любой момент времени. Дополнительные сведения о работе с пакетами DD содержатся в параграфах 10.8 и 10.6. Состояние: Exchange Событие: ExchangeDone

Новое состояние: Зависит от предпринятых действий.

Действия: Если список запроса LS от соседа пуст, новым состоянием будет Full и никаких действий не требуется – это финальное состояние отношений смежности. В остальных случаях новым состоянием будет Loading с последующим началом (продолжением) передачи пакетов Link State Request соседу (см. параграф 10.9). Это запросы на получение от соседа свежих записей LSA (обнаруженных, но еще не полученных в состоянии Exchange). LSA перечисляются в списках Link State Request, связанных с соседом. Состояние: Loading Событие: Loading Done Новое состояние: Full

Действия: Дополнительных действий не требуется – это финальное состояние отношений смежности. Состояние: 2-Way Событие: AdjOK?

Новое состояние: Зависит от предпринятых действий.

Действия: Определяет необходимость организации смежности с соседним маршрутизатором (см. параграф 10.4). Если смежность не требуется, сохраняется состояние 2-Way, в противном случае осуществляется переход в состояние ExStart и выполнение действий, описанных выше для состояний Init и 2-WayReceived. Состояние: ExStart или выше Событие: AdjOK?

Новое состояние: Зависит от предпринятых действий.

Действия: Определяет необходимость сохранения смежности с соседним маршрутизатором. При положительном ответе состояние сохраняется и дополнительных действий не требуется. Если смежность не нужно сохранять, состояние меняется на 2-Way. Списки Link state, Database summary и Link state request удаляются из LSA. Состояние: Exchange или выше Событие: SeqNumberMismatch Новое состояние: ExStart

Действия: Отношения смежности (возможно частично организованные) были разорваны и предпринимается попытка восстановить их. Состояние соседа переводится сначала в ExStart. Списки Link state retransmission, Database summary и Link state request удаляются из LSA. После этого маршрутизатор увеличивает значение счетчика порядковых номеров DD в структуре данных о соседе, объявляет себя ведущим (установив для бита master/slave значение master) и начинает передавать пакеты с установленными битами I, M и MS. Остальные поля пакета DD должны быть пустыми (см. параграф 10.8). Состояние: Exchange или выше Событие: BadLSReq Новое состояние: ExStart

Действия: Действия для событий BadLSReq в точности совпадают с действиями для SeqNumberMismatch. Отношения смежности (возможно частично организованные) были разорваны и предпринимается попытка восстановить их. Дополнительная информация приведена выше в описании действий по событию SeqNumberMismatch для Exchange и более высокий состояний. Состояние: Любое Событие: KillNbr Новое состояние: Down

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA. Отключается таймер Inactivity.

Состояние: Любое Событие: LLDown Новое состояние: Down

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA. Отключается таймер Inactivity.

Состояние: Любое Событие: InactivityTimer Новое состояние: Down

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA. Состояние: 2-Way или выше Событие: 1-WayReceived Новое состояние: Init

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA. Состояние: 2-Way or greater Событие: 2-WayReceived Новое состояние: Состояние не меняется.

rfc.com.ru

Перевод RFC 2328

Действия: Дополнительных действий не требуется.____________________________________________________________________

Состояние: Init

Событие: 1-WayReceived

Новое состояние: Состояние не меняется.

Действия: Дополнительных действий не требуется.

10.4. Когда организуется смежность

Отношения смежности организуются с частью соседей маршрутизатора. Маршрутизаторы, связанные сетями point-to-point, Point-

to-MultiPoint или виртуальными каналами, всегда являются смежными. В широковещательных и NBMA-сетях все

маршрутизаторы являются смежными с DR и Backup DR.

Решение вопроса об организации отношений смежности происходит в двух точках машины состояний соседа. Первой точкой

является начальная организация двухсторонней связи между соседями, а второй - обнаружение смены маршрутизаторов (Backup)

DR. Если принято решение не пытаться организовать отношения смежности, смена состояний соседей останавливается на уровне

2-Way.

Отношения смежности следует организовывать при наличии с соседом двухсторонней связи и выполнении, по крайней мере,

одного из перечисленных ниже условий:

♦ маршрутизаторы связаны сетью point-to-point

♦ маршрутизаторы связаны сетью Point-to-MultiPoint

♦ маршрутизаторы связаны виртуальным каналом

♦ маршрутизатор играет роль DR

♦ маршрутизатор играет роль Backup DR

♦ соседний маршрутизатор является DR

♦ соседний маршрутизатор является Backup DR

10.5. Прием пакетов Hello

В этом параграфе рассматривается процесс обработки пакетов Hello (описание формата пакетов приведено в параграфе A.3.2). На

приемной стороне базовые операции обработки пакетов OSPF включают проверку заголовка IP и заголовка OSPF. После этого

значения полей Network Mask, HelloInterval и RouterDeadInterval в принятом пакете Hello сравниваются с параметрами

принимающего интерфейса. При любом несовпадении обработка завершается с отбрасыванием пакета. Иными словами,

перечисленные поля реально описывают конфигурацию подключенной сети. Однако это правило имеет одно исключение - в

сетях point-to-point и виртуальных каналах значение Network Mask принятого пакета Hello следует игнорировать.

Принимающий интерфейс подключен одной области OSPF (это может быть магистраль). Установка бита E в поле Options пакета

Hello должна соответствовать параметру ExternalRoutingCapability для этой области. Если анонсы AS-external-LSA не

рассылаются в эту область (область является тупиковой), бит E в пакетах Hello должен быть сброшен, в остальных случаях бит

E=1. Несоответствие значений прерывает обработку пакета и пакет отбрасывается. Установка остальных опций Hello должна

игнорироваться.

После этого проверяется совпадение адреса отправителя пакета Hello с адресами соседей принимающего интерфейса. Если

принимающий интерфейс подключен к широковещательной, Point-to-MultiPoint или NBMA-сети, отправитель идентифицируется

по IP-адресу отправителя в заголовке IP пакета Hello. Если принимающий интерфейс подключен к сети point-to-point или

виртуальному каналу, отправитель идентифицируется значением Router ID в заголовке OSPF пакета Hello. Текущий список

соседних интерфейсов содержится в структуре данных интерфейса. Если отправитель не найден в списке соседей (т. е., получен

первый пакет от него), в структуру данных вносятся дополнения. Для нового соседа состояние устанавливается в Down.

При получении пакета Hello от соседа в широковещательной, Point-to-MultiPoint или NBMA-сети, устанавливается значение поля

Neighbor ID, равное значению Router ID в заголовке OSPF принятого пакета. Для этих типов сетей поля структуры данных о

соседе Router Priority, Designated Router и Backup Designated Router также устанавливаются равными значениям соответствующих

полей пакета Hello; изменения этих полей должны быть зафиксированы для последующей обработки. При получении пакета Hello

из сети point-to-point (но не из виртуального канала) значение Neighbor IP устанавливается в соответствии с IP-адресом

отправителя.

Далее проверяется остальная часть пакета Hello и генерируются события для машин состояний соседа и интерфейса. Эти машины

состояний выполняются немедленно или помещаются в очередь (см. параграф 4.4). В приведенном ниже примере указано, что

машина состояний соседа исполняется сразу же (in line) и несколько смен состояния могут быть инициированы одним пакетом

Hello:

♦ Каждый принятый пакет Hello активизирует машину состояний соседа событием HelloReceived.

♦ После этого проверяется список соседей в пакете Hello. Если принявший маршрутизатор присутствует в списке, машине состояний передается событие 2-WayReceived. В противном случае используется событие 1-WayReceived и обработка пакета заканчивается.

♦ Далее, если было зафиксировано изменение поля Router Priority, планируется активизация машины состояний интерфейса событием NeighborChange.

♦ Если сосед декларирует себя как DR (в пакете Hello поле Designated Router = Neighbor IP), поле Backup DR в пакете имеет значение 0.0.0.0 и принимающий интерфейс находится в состоянии Waiting, планируется активизация машины состояний интерфейса событием BackupSeen. В остальных случаях, если сосед декларирует себя как DR, но не был им до этого или не декларирует себя в этом качестве, хотя ранее играл роль DR, планируется активизация машины состояний принимающего интерфейса событием NeighborChange.

♦ Если сосед декларирует себя как Backup DR (в пакете Hello поле Backup Designated Router = Neighbor IP) и приемный интерфейс находится в состоянии Waiting, планируется активизация машины состояний интерфейса событием BackupSeen. В остальных случаях, когда сосед объявил себя Backup DR, не будучи таковым до этого, или снял с себя полномочия Backup DR, планируется активизация машины состояний принимающего интерфейса событием NeighborChange. В сетях NBMA прием пакета Hello может также вызывать передачу ответного пакета Hello (см. параграф 9.5.1).

10.6. Прием пакетов DD

В этом параграфе описан процесс обработки принимаемых пакетов DD. Входящие пакеты DD уже связаны с соседом и принявшим интерфейсом в процессе базовой обработки (см. параграф 8.2). Отказ или восприятие и дальнейшая обработка воспринятых пакетов DD зависит от состояния соседа.

Для воспринимаемых пакетов DD в соответствующей структуре данных о соседе после last received Database Description packet (последний принятый пакет DD) должны быть сохранены значения битов I, M и MS, а также поля Options и порядкового номера

rfc.com.ru

Перевод RFC 2328

DD. Если эти поля совпадают для двух последовательных пакетов DD от одного соседа, второй пакет DD рассматривается в процессе последующей обработки как дубликат.

Если поле Interface MTU в пакете DD показывает, что размер дейтаграммы IP превышает возможности маршрутизатора (требует фрагментации), пакет DD отбрасывается. Дальнейшая обработка зависит от состояния соседа:

Down

Пакет должен отбрасываться.

Attempt

Пакет должен быть отброшен.

Init

Машина состояний соседа должна активизироваться событием 2-WayReceived, что ведет к немедленному переходу в состояние 2-Way или ExStart. Если новым состоянием является ExStart, обработка текущего пакета должна продолжаться для случая ExStart, описанного ниже.

2-Way

Пакет следует игнорировать. Пакеты DD используются только для организации мостов и отношений смежности¹⁴.

ExStart

Если принятый пакет соответствует одному из приведенных ниже условий, машина состояний соседа должна

активизироваться событием NegotiationDone (переход в транзитное состояние Exchange), поле Options должно быть

сохранено в структуре данных о соседе (Neighbor Options), а пакет должен быть воспринят для последующей обработки (см.

ниже).

o Биты I, M и MS установлены, остальные поля пакеты пусты и значение Router ID у соседа больше, чем у принявшего

пакет маршрутизатора. Маршрутизатор в данном случае является ведомым, бит master/slave устанавливается в slave и в

структуре данных о соседе устанавливается порядковый номер DD, заданный ведущим маршрутизатором. o Биты I и MS не установлены, порядковый номер DD для пакета равен порядковому номеру DD в структуре данных о

соседе (подтверждение) и значение Router ID у соседа меньше, чем у принявшего пакет маршрутизатора (данный

маршрутизатор является ведущим). В остальных случаях пакет следует игнорировать.

Exchange

Дубликаты пакетов DD отбрасываются ведущим маршрутизатором и заставляют ведомый заново передавать последний пакет

DD. Для пакетов, не являющихся дубликатом:

o Если состояние бита MS не соответствует состоянию master/slave для соединения, генерируется событие

SeqNumberMismatch для соседа и обработка пакета прекращается. o Если бит I установлен, для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается. o Если поле Options показывает другой набор дополнительных возможностей OSPF по сравнению с полученным от соседа

ранее (записан в поле Neighbor Options структуры данных о соседе), для соседа генерируется событие

SeqNumberMismatch и обработка пакета прекращается. o Пакеты DD должны обрабатываться в соответствии с их порядковыми номерами. Если маршрутизатор является

ведущим, следующий порядковый номер принятого пакета должен совпадать с номером в структуре данных о соседе.

Для ведомого маршрутизатора принятый пакет должен иметь порядковый номер на 1 больше номера, записанного в

структуру данных о соседе. В любом случае, следующий по порядку пакет должен быть принят и обработан, как описано

ниже. o В противном случае для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается.

Loading или Full

В этих состояниях маршрутизатор передает или принимает всю последовательность пакетов DD. Дубликаты возможны только для принимаемых пакетов (см. выше). Поле Options в пакетах должно соответствовать дополнительным возможностям OSPF, ранее показанным соседом (этот параметр хранится в поле опций структуры данных Neighbor). Прием любых других пакетов, включая пакеты с установленным битом I, должен сопровождаться генерацией события SeqNumberMismatch¹⁵. Ведущий маршрутизатор должен отбрасывать дубликаты, а ведомый – повторять в ответ передачу последнего пакета DD. Когда маршрутизатор принимает пакет DD со следующим порядковым номером, этот пакет воспринимается и обрабатывается. Для каждой перечисленной записи LSA проверяется корректность типа LS. Если тип LS неизвестен (т. е., не относится к типам 1 – 5, определенным в данной спецификации) или запись является AS-external-LSA (тип 5), а сосед связан с тупиковой областью, для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается. В остальных случаях маршрутизатор ищет LSA в своей базе данных. Если такой записи нет или имеется более старая версия (см. параграф 13.1), запись LSA помещается в список Link state request для ее последующего запроса (немедленно или спустя некоторое время) с помощью Link State Request. Для пакетов DD со следующим порядковым номером, кроме перечисленных выше операций, маршрутизатор выполняет еще ряд действий в зависимости от своей роли – ведущий или ведомый:

Master

Увеличивается порядковый номер DD в базе данных о соседе. Если маршрутизатор уже передал все пакеты DD и принятый пакет не содержит флага M, для соседа генерируется событие ExchangeDone. В остальных случаях ведомому маршрутизатору передается новый пакет DD.

Slave

Порядковый номер DD в структуре данных о соседе устанавливается в соответствии с порядковым номером DD в принятом запросе. Ведомый маршрутизатор должен передать в ответ пакет DD. Если в принятом пакете не установлен бит M и переданный ведомым маршрутизатором пакет также не содержит флага M, для соседа генерируется событие ExchangeDone. Отметим, ведомый маршрутизатор всегда генерирует это событие раньше ведущего.

10.7. Прием пакетов Link State Request

В этом параграфе описывается процедура обработки принятых запросов Link State Request (LSR). Принятые пакеты LSR содержат списки LSA, которые сосед хочет получить. Пакеты LSR должны восприниматься, если сосед находится в состоянии Exchange, Loading или Full. Для всех остальных состояний соседа пакеты LSR должны игнорироваться.

Каждая запись LSA, указанная в пакете LSR, должна отыскиваться в базе данных маршрутизатора и копироваться в пакет Link State Update (LSU) для передачи соседу. Эти записи не следует помещать в список Link state retransmission для соседа. Если LSA

¹⁴ При смене DR достаточно типичным случаем для соседа в этом состоянии будет передача пакета DD для маршрутизатора; это означает наличие кратковременного рассогласования тождественности DR.

¹⁵ Для маршрутизатора возможна рассинхронизация полных отношений смежности путем перехода назад в состояние ExStart. Это заставит смежный маршрутизатор обрабатывать сообщение SeqNumberMismatch и вернуться в состояние ExStart.

rfc.com.ru 30 rfc.com.ru

Перевод RFC 2328

не удается найти в базе данных, это говорит о наличии ошибки в процессе Database Exchange и ведет к генерации события BadLSReq.

10.8. Передача пакетов DD

В этом параграфе описан процесс передачи соседу пакетов Database Description (DD). Для пакетов DD значение поля Interface MTU устанавливается равным размеру максимальной дейтаграммы IP, которая может быть передана интерфейсом без фрагментации. Общепринятые в Internet значения MTU можно найти в таблице 7-1 работы [Ref22]. Для пакетов DD, передаваемых через виртуальные соединения устанавливается Interface MTU=0.

Дополнительные возможности OSPF (см. параграф 4.5) сообщаются соседу через поле Options пакета DD. Маршрутизатор должен поддерживать такой же набор дополнительных возможностей в процедурах Database Exchange и лавинной рассылки. Если по каким-то причинам дополнительные возможности маршрутизатора изменяются, следует заново выполнить процедуру Database Exchange путем возврата для соседа состояния ExStart. В данной спецификации определяется только одна дополнительная возможность (см. параграфы 4.5 и A.2). Флаг E- устанавливается тогда и только тогда, когда подключенная сеть не относится к тупиковой области. Нераспознанные биты поля Options должны иметь нулевое значение.

Передача пакетов DD зависит от состояния соседа. В состоянии ExStart маршрутизатор передает только пустые пакеты DD с установленными битами I, M и MS, повторяя с интервалом RxmtInterval. В состоянии Exchange пакеты DD реально содержат резюме информации о состоянии каналов, содержащейся в базе данных маршрутизатора. Каждая запись LSA в базе данных области (во время перехода соседа в состояние Exchange) указывается в списке Database summary соседа. Каждый новый пакет DD копирует свой порядковый номер из структуры данных о соседе и после этого описывает начальную часть списка Database summary. Описанные элементы удаляются из списка после подтверждения приема содержащего их пакета. В состоянии Exchange момент передачи пакетов DD определяется ролью маршрутизатора (ведущий или ведомый):

Master

Пакеты DD передаются, если a) ведомый маршрутизатор подтвердил прием предыдущего пакета DD, указав его номер в отклике, или b) прошло RxmtInterval секунд без подтверждения приема предыдущего пакета (заново передается прежний пакет).

Slave

Пакеты DD передаются только в ответ на получение пакета DD от ведущего маршрутизатора. Если получен новый пакет DD, в ответ передается новый отклик DD, в противном случае снова передается предыдущий пакет DD. В состояниях Loading и Full ведомый маршрутизатор должен повторять передачу последнего пакета DD в ответ на прием дубликата пакета DD от ведущего маршрутизатора. По этой причине ведомый маршрутизатор должен ждать RouterDeadInterval секунд перед освобождением пакета DD. Получение пакета DD от ведущего маршрутизатора по истечении этого времени ведет к генерации для соседа события SeqNumberMismatch.

10.9. Передача пакетов Link State Request

При состояниях соседа Exchange и Loading список запросов состояний каналов содержит те LSA, которые нужно получить от соседа. Для запроса LSA маршрутизатор сначала отправляет соседу список запросов, помещенный в пакет LSR.

Когда сосед отвечает на эти запросы пакетами Link State Update, соответствующие элементы удаляются из списка запросов и передается новый пакет LSR. Этот процесс продолжается, пока список запросов не будет исчерпан. Записи из списка LSA, которые уже были запрошены, но еще не получены, помещаются в пакет LSR для повторной передачи по истечении интервала RxmtInterval. В любой момент времени должен сохраняться по крайней мере один необработанный пакет LSR.

Когда список запросов исчерпан и сосед находится в состоянии Loading (передан и принят полный набор пакетов DD от соседа) для соседа генерируется событие Loading Done.

rfc.com.ru

+---+ |RT2| +---+

Down

10.10. Пример

Перевод RFC 2328

+---+ |RT1| +---+

Down

Hello(DR=0,seen=0)

На рисунке 10 показан пример организации смежности. Маршрутизаторы RT1 и RT2 подключены к широковещательной сети. Предполагается, что RT2 играет роль DR и его значение Router ID больше, нежели Router ID для RT1.

Изменения состояния соседа отлеживаются каждым и показаны по краям рисунка.

На начальном этапе примера маршрутизатор RT1 только начинает работу в сети. Маршрутизатор начинает передавать пакеты Hello, хотя он еще не знает о DR и других

ExStart

Hello (DR=RT2,seen=RT1,...) ---------------------------

D-D (Seq=x,I,M,Master) ---------------------------

D-D (Seq=y,I,M,Master) ---------------------------

D-D (Seq=y,M,Slave) ---------------------------

D-D (Seq=y+1,M,Master) ---------------------------

D-D (Seq=y+1,M,Slave)

Init

ExStart

Exchange

соседних маршрутизаторах. RT2 слышит эти пакеты (и вводит состояние Init для соседа) и

в своем следующем пакете Hello указывает себя как DR и показывает прием пакетов

Hello от RT1. Это заставляет RT1 перейти в состояние ExStart, начиная формирование смежности.

D-D (Seq=y+n, Master)

RT1 начинает заявлять себя как ведущий

маршрутизатор. Когда RT1 видит, что RT2

D-D (Seq=y+n, Slave)

должен быть ведущим (большее значение

Router ID), он переходит в режим ведомого и

LS Request

Full

адаптирует свой порядковый номер DD для

соседа. Происходит обмен пакетами DD с запросами от ведущего (RT2) и откликами от ведомого (RT1) маршрутизатора. Эта последовательность пакетов DD завершается когда обе стороны сбрасывают флаг M.

В приведенном примере предполагается, что

LS Update

LS Request

LS Update

Full

Рисунок 10. Пример организации отношений смежности.

база данных RT2 полностью актуальна. В

этом случае RT2 незамедлительно переходит

в состояние Full. RT1 будет переходить в

состояние Full после обновления нужных

частей своей базы данных. Это осуществляется путем передачи пакетов LSR и приема откликов LSU. Отметим, что ожидание

маршрутизатором RT1 завершения приема всего набора пакетов DD от RT2 до передачи пакетов LSR не является обязательным.

RT1 может чередовать передачу пакетов LSR и прием пакетов DD.

11. Структура таблицы маршрутов

Таблица маршрутов содержит все данные, требуемые для пересылки пакетов IP в направлении адресата. Каждая запись таблицы

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

максимальным соответствием IP-адресу получателя пакета. После этого из выбранной записи берется адрес следующего

маршрутизатора (next hop) в направлении адресата. Протокол OSPF также обеспечивает поддержку принятого по умолчанию

маршрута (Destination ID = DefaultDestination, Address Mask = 0x00000000). Если существует принятый по умолчанию маршрут,

он соответствует всем IP-адресам получателей (хотя любые другие маршруты обеспечивают лучшее соответствие). Поиск

маршрута с лучшим соответствием IP-адресу получателя описан в параграфе 11.1.

В каждом маршрутизаторе существует одна таблица маршрутов. Два примера таблиц маршрутизации рассмотрены в параграфах

11.2 и 11.3. Построение таблицы маршрутов описано в главе 16.

В остальной части параграфа описаны поля записей в таблице маршрутов. Первый набор полей описывает адресатов для записи.

Destination Type

Адресатом может быть сеть (network) или маршрутизатор (router). При пересылке пакетов данных IP реально используются

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

построения таблицы маршрутов.

Сеть представляет собой диапазон адресов IP, по которым могут пересылаться пакеты данных. Сюда включаются сети

классов A, B и C, подсети IP, сверхсети IP и отдельные хосты IP. Принятый по умолчанию маршрут также входит с эту

категорию.

Записи, связанные с маршрутизаторами, сохраняются для граничных маршрутизаторов областей и AS. Записи в таблице

маршрутов для граничных маршрутизаторов областей используются при расчете междоменных маршрутов (см. параграф

16.2) и для поддержки виртуальных соединений (см. главу 15), а записи для граничных маршрутизаторов AS служат для

расчета внешних по отношению к AS маршрутов (см. параграф 16.4).

Destination ID

Имя или идентификатор адресата в зависимости от значения Destination Type. Для сетей используется связанный с сетью IP-адрес, для маршрутизаторов - OSPF Router ID¹⁶.

Address Mask

Маска определена только для сетей и при использовании вместе с адресом IP позволяет определить сетевой диапазон IP-адресов. Для подсетей IP адресную маску называют маской подсети. Маршруты к хостам имеют маску 0xffffffff.

Optional Capabilities

Когда получателем является маршрутизатор, это поле показывает поддерживаемые им дополнительные возможности OSPF. В данной спецификации определена единственная дополнительная возможность – обработка AS-external-LSA. Обсуждение дополнительных возможностей OSPF приведено в параграфе 4.5.

¹⁶ Пространство адресов IP-сетей и значений OSPF Router ID могут перекрываться, т. е., IP-адрес сети в 32-битовом представлении может совпадать с Router ID какого-либо из маршрутизаторов.

rfc.com.ru 32 rfc.com.ru

Перевод RFC 2328

Набор путей к адресату может меняться в зависимости от областей OSPF, через которые проходит путь. Это означает, что для одного получателя в таблице может содержаться несколько записей в зависимости от значения следующего поля.

Area

Это поле указывает области, для которых информация о каналах приводит к включению в таблицу множества путей (эти записи называют связанными или ассоциированными). Для наборов внешних по отношению к AS путей это поле не определено. Для маршрутизаторов может существовать несколько наборов путей (и раздельных записей в таблице), связанных с каждой из нескольких областей. Например, это может произойти, когда два граничных маршрутизатора областей относятся к одной области. Для сетей сохраняется единственный набор путей, связанный с лучшей областью (предпочтительный маршрут). Остальная часть маршрутной записи описывает набор путей к адресату. Перечисленные ниже поля относятся ко всему набору путей для одного адресата, т. е., все пути в одной записи таблицы маршрутов имеют одинаковый тип и стоимость (см. ниже).

Path-type

Существует 4 типа путей для передачи пакетов адресату: внутридоменные, междоменные, внешние типа 1 и 2 (в порядке снижения предпочтения). Внутридоменные пути используются для адресатов в одной из подключенных к маршрутизатору областей, междоменные пути ведут в другие области OSPF. Определение типа происходит на основе принятых summary-LSA. Внешние пути ведут в другие AS и детектируются на основе принятых AS-external-LSA.

Cost

Стоимость пути к адресату в единицах link state. Для всех путей кроме внешних типа 2 этот параметр описывает стоимость пути в целом. Для внешних путей типа 2 это поле описывает стоимость части пути внутри данной AS. Эта стоимость вычисляется как сумма стоимостей составляющих путь каналов.

Type 2 cost

Это поле применимо только для внешних путей типа 2 и показывает стоимость внешней части пути. Эта стоимость анонсируется граничным маршрутизатором AS и составляет большую часть общей стоимости пути. Например, внешний путь типа 2 с внешней стоимостью 5 всегда предпочтительней пути типа 2 с внешней стоимостью 10, независимо от внутренней стоимости.

Link State Origin

Применяется только для внутридоменных путей и показывает запись LSA (router-LSA или network-LSA), напрямую указывающую адресата. Например, если адресатом является транзитная сеть, это будет network-LSA транзитной сети. Если адресатом является тупиковая сеть, это будет router-LSA для подключенного к ней маршрутизатора. Записи LSA определяются при расчете дерева кратчайших путей (см. параграф 16.1). Один адресат может указываться множеством LSA, однако схема tie-breaking (разрыв связей) сужает выбор до единственной записи LSA. Поле Link State Origin не используется протоколом OSPF, но применяется при расчете таблицы маршрутов в MOSPF (OSPF Multicast routing extensions). При наличии множества однотипных путей с равной стоимостью (equal-cost paths – равноценные пути), эти пути сохраняются в одной записи таблицы маршрутов. Равноценные пути различаются следующими полями:

Next hop

Выходной интерфейс маршрутизатора, используемый для пересылки пакетов получателю. В широковещательных, Point-to-MultiPoint и NBMA-сетях поле next hop также включает IP-адрес первого маршрутизатора (если он есть) на пути к адресату.

Advertising router

Имеет смысл только для междоменных и внешних путей и содержит Router ID маршрутизатора, анонсирующего summary-LSA или AS-external-LSA для этого пути.

11.1. Просмотр таблицы маршрутов

При получении пакета данных IP маршрутизатор OSPF находит запись таблицы маршрутизации, наиболее точно соответствующую адресату. Из этой записи определяется выходной интерфейс маршрутизатора и следующий маршрутизатор для пересылки пакета. В этом параграфе описан процесс поиска наилучшего соответствия в таблице маршрутов для адреса получателя пакета.

До начала просмотра в таблицу должны быть вставлены «отвергнутые» записи для каждого активного диапазона адресов области в маршрутизаторе (см. параграф 3.5). Диапазон считается активным, если он включает по крайней мере одну сеть, доступную внутридоменным путем. Адресатом «отвергнутой» записи служит набор адресов, описываемый связанным с ним активным диапазоном и тип пути для каждой «отвергнутой» записи должен быть междоменным¹⁷.

Адресу получателя может соответствовать несколько записей маршрутной таблицы. В таких случаях лучшее соответствие обеспечивает запись таблицы с максимальным совпадением. Иными словами, лучшее совпадение обеспечивается записью с наиболее узким диапазоном IP-адресов¹⁸. Например, запись для пары 128.185.1.0, 0xffffff00 задает более точное соответствие, нежели 128.185.0.0, 0xffff0000. Принятый по умолчанию маршрут обеспечивает минимальное соответствие, поскольку он подходит для всех адресатов. Отметим, что для любой отдельной записи в таблице маршрутов может существовать множество путей. В таких случаях расчеты, описанные в параграфах 16.1, 16.2 и 16.4 всегда дают пути наиболее предпочтительного типа (см. главу 11).

Если в таблице не найдено соответствующей адресату записи или максимальное соответствие обеспечивает одна из «отвергнутых» записей, адресат считается недоступным и вместо пересылки пакет отбрасывается, а отправителю возвращается пакет ICMP destination unreachable (адресат недоступен).

11.2. Пример таблицы маршрутизации без областей

Вернемся к примеру автономной системы на рисунке 2. В этом примере не задано ни одной области OSPF. Метрика показана только для исходящих интерфейсов. Расчет таблицы маршрутизации для RT6 был описан в параграфе 2.2, а результаты этого расчета приведены в таблице 15. Адресаты в таблице обозначены буквами N (сети), R (маршрутизаторы) и H (хосты).

¹⁷ "Отвержение" областей требуется для беспетлевого резюмирования маршрутов на границе области.

¹⁸ При соответствии получателю двух диапазонов адресов предполагается, что один диапазон уже другого. Чтобы избавиться от этого допущения можно использовать несвязные (Non-contiguous) маски подсетей, но такие маски протокол OSPF не поддерживает.

rfc.com.ru 33 rfc.com.ru

Перевод RFC 2328


В этом примере нет равноценных путей, а междоменные пути отсутствуют, поскольку нет областей.	Тип N N	Адресат N1 N2	Область 0 0	Таблица 15 Таблица Тип пути Внутридомен. Внутридомен.	маршрутизац Стоимость 10 10 7 8 7	ии RT6 (областей не задано). Next Анонсирующий Hop маршрутизатор RT3 * RT3 *
Маршрутизаторы RT5 и RT7 являются граничными для AS. Внутридоменные пути	N	N3 N4 Ib	0 0 0	Внутридомен. Внутридомен. Внутридомен.	маршрутизац Стоимость 10 10 7 8 7	RT3 RT3 *	* * *
рассчитываются до маршрутизаторов RT5 и RT7. Это позволяет рассчитать	N____ N	Ia N6 N7	0 0 0	Внутридомен. Внутридомен. Междоменный	12 8 12 10 11 13 14 21 6 8 10 114 14 17	RT10 RT10 RT10	* * *
внешние пути до адресатов, анонсируемых RT5 и RT7 (т. е., сетей N12, N13, N14 и N15).	N____ N	N8 N9 N10	0 0 0	Междоменный Междоменный Междоменный		RT10 RT10 RT10	* * *
Предполагается, что все AS-external-LSA генерируемые RT5 и RT7 анонсируют внешнюю	N____ N R	N11 H1 RT5	0 0 0	Междоменный Междоменный Междоменный		RT10 RT10 RT5	* * *
метрику типа 1. Это ведет к тому, что внешние пути типа 1	R____ N	RT7 N12	0 *	Междоменный Внешн. типа 1		RT10 RT10	* RT7
будут рассчитаны для адресатов в сетях N12-N15.	N____ N	N13 N14 N15	* * *	Внешн. типа 1 Внешн. типа 1 Внешн. типа 1		RT5 RT5 RT10	RT5_____________ RT5 RT7

таблицы маршрутизации с областями

Вернемся к предыдущему

Таблица 16 Таблица маршрутизации RT4 при наличии областей.

примеру, разделив AS на две области OSPF (конфигурация областей показана на рисунке 4). Таблица маршрутизации RT4 будет описана для этой конфигурации. Маршрутизатор RT4 соединен с областью 1 и магистральной областью. Это заставляет RT4 видеть AS как объединение (concatenation) двух графов, показанных в таблицах 6 и 7. Маршруты RT4 показаны в таблице 16.

Маршрутизаторы RT5 и RT7 являются граничными для AS, а RT3, RT4, RT7, RT10 и RT11 – для областей. Отметим, что для маршрутизатора RT3 в таблице две маршрутных записи, поскольку он имеет две области, общие с RT4 (область 1 и магистраль).

Магистральные пути

Тип

N N N N R N N R R R R R N N N N

N N N N


	Адресат	Область
	N1 N2	1
	N3
	N4 RT3	1
	Ib Ia	0
	RT3	0
	RT5 RT7	0
	RT10	0

Тип пути

Стоимость

Next Hop

Анонсирующий маршрутизатор


	Внутридомен. Внутридомен.	4 4
	Внутридомен.	1
	Внутридомен. Внутридомен.	3 1

RT1

RT2 *

RT3

Внутридомен. Внутридомен.

22 27

RT5 RT5

Внутридомен.

RT5

Внутридомен. Внутридомен. Внутридомен. Внутридомен.


	8 14	* RT5
	22	RT5
	25	RT5

Междоменный Междоменный Междоменный

15 19 18

RT5 RT5 RT5

RT7 RT7 RT7

N9-N11,H1

Междоменный

RT5

RT11


	N12	*
	N13	*
	N14	*
	N15	*

Внешн. типа 1

RT5 RT5, RT7


Внешн. типа 1	16	RT5	RT5
Внешн. типа 1	16	RT5	RT5
Внешн. типа 1	23	RT5	RT7

рассчитываются до всех граничных маршрутизаторов областей. Эти пути служат для

междоменных маршрутов. Отметим, что все междоменные маршруты связаны с

расчета

магистралью – это бывает всегда для случаев, когда рассчитывающий маршрутизатор является граничным для области. Маршрутная информация конденсируется на границах областей. В нашем примере предполагается, что область 3 определена так, что сети N9 - N11 и хост H1 находятся на одном маршруте, анонсируемом в магистраль маршрутизатором RT11. Отметим, что стоимость этого пути является максимальной из набора стоимостей отдельных компонент.

Между маршрутизаторами RT10 и RT11 организован виртуальный канал. Без этого канала маршрутизатор RT11 не сможет анонсировать маршрут для сетей N9 - N11 и хоста H1 в магистраль и в таблице RT4 не будет записи для этих сетей. В данном примере есть два равноценных пути в сеть N12, однако оба пути идут через один маршрутизатор next hop (RT5). Таблица маршрутизации RT4 улучшается (часть путей становится короче) при организации виртуального канала между RT4 и RT3. Новый виртуальный канал будет сам по себе ассоциироваться с первой записью в таблице граничного маршрутизатора области (RT3 в таблице 16) – внутридоменным путем через область 1. Это будет обеспечивать для виртуального канала стоимость 1. Изменения таблицы маршрутизации в связи с организацией виртуального канала показаны в таблице 17.

12. Анонсы состояния каналов (LSA)

Таблица 17 Изменения в результате добавления виртуального канала. Каждый маршрутизатор в


Тип	Адресат	Область	Тип пути	Стоимость	Next Hop	Анонсирующий маршрутизатор
N	Ib	0	Внутридомен.	16	RT3	*
N	Ia	0	Внутридомен.	21	RT3	*
R	RT3	0	Внутридомен.	1	*	*
R	RT10	0	Внутридомен.	16	RT3	*
R	RT11	0	Внутридомен.	19	RT3	*

AS генерирует один или

несколько анонсов

состояния каналов - LSA. В

данной спецификации

определены 5 различных

типов LSA, описанных в

параграфе 4.3. Набор LSA

N9-N11,H1

Междоменный

RT3

RT11

формирует базу данных о

состоянии каналов.

Каждый тип LSA имеет

свое назначение. Router-LSA и network-LSA описывают соединения между маршрутизаторами областей и сетями. Summary-LSA

обеспечивает способ сжатого представления маршрутных данных области, а AS-external-LSA дают возможность прозрачного

анонсирования внешней маршрутной информации внутри AS.

rfc.com.ru

Перевод RFC 2328

Каждая запись LSA начинается стандартным 20-байтовым заголовком, описанным ниже.

12.1. Заголовок LSA

Заголовок LSA содержит поля type, Link State ID и Advertising Router. Комбинация этих трех полей уникальна для LSA.

В автономной системе может одновременно существовать несколько экземпляров LSA. В таких случаях требуется определять последний экземпляр, для чего проверяются поля LS sequence, LS checksum и LS age, содержащиеся в заголовке LSA.

Некоторые типы пакетов OSPF содержат списки LSA. Когда экземпляр не имеет значения, LSA идентифицируются полями LS type, Link State ID и Advertising Router (см. описание пакетов LSR). В остальных случаях принимаются во внимание также поля LS sequence number, LS age и LS. Детальное описание полей заголовка LSA приводится ниже.

12.1.1. Возраст LS

Это поле показывает возраст LSA в секундах и должно обрабатываться как беззнаковое 16-битовое целое. При генерации LSA поле имеет нулевое значение и должно увеличиваться на InfTransDelay при прохождении каждого интервала в процедуре лавинной рассылки. Старение LSA происходит также при их удержании в базе данных каждого маршрутизатора.

Возраст LSA не увеличивается сверх MaxAge и LSA с возрастом MaxAge не используются при расчете таблиц маршрутизации. Когда возраст LSA достигает MaxAge, для этой записи повторно используется лавинная рассылка. LSA с возрастом MaxAge окончательно удаляются из базы данных, когда они перестают быть нужными для синхронизации базы. Дополнительные сведения о старении LSA приведены в главе 14.

Поле LS age проверяется маршрутизатором при получении двух экземпляров LSA, имеющих одинаковый порядковый номер и контрольную суммы. Экземпляр с возрастом MaxAge в таких случаях всегда принимается как более новый, что позволяет быстрее удалять старые LSA из области маршрутизации. В остальных случаях, если разница в возрасте превышает MaxAgeDiff, экземпляр с меньшим возрастом принимается как более свежий¹⁹ (см. подробности в параграфе 13.1).

12.1.2. Опции

Поле Options в заголовке LSA показывает дополнительные возможности, связанные с LSA. Дополнительные возможности OSPF описаны в параграфе 4.5. Единственная дополнительная возможность, определенная в данной спецификации представляется флагом E в поле Options. Нераспознанные биты поля Options должны иметь нулевые значения.

Бит E представляет OSPF ExternalRoutingCapability и должен устанавливаться во всех LSA, связанных с магистралью и нетупиковыми (non-stub) областями (см. параграф 3.6). Этот флаг должен также устанавливаться для всех AS-external-LSA. Во всех router-LSA, network-LSA и summary-LSA, связанный с тупиковыми областями, флаг должен быть сброшен. Для всех LSA установка бита E производится только в информационных целях и не влияет на расчет таблицы маршрутов.

Таблица 18 Типы анонсов LSA протокола OSPF.

12.1.3. Тип LS

Поле типа LS определяет формат и назначение LSA. LSA различных типов имеют разные имена (router-LSA, network-LSA и др.). Все типы LSA, определенных в данной спецификации, за исключением AS-external-LSA (LS типа 5), рассылаются лавинным способом через одну область. Анонсы AS-external-LSA рассылаются по всей AS, за исключением тупиковых областей (см. параграф 3.6). Каждый из типов LSA кратко описан в таблице 18.

12.1.4. Link State ID

Это поле идентифицирует часть области маршрутизации, которая будет описана в LSA. Значение


	Тип LS 1 2	LSA router-LSA. network-LSA
	3 или 4	summary-LSA

Описание

Информация о состоянии интерфейсов маршрутизатора (см. параграф 12.4.1). Описывает набор маршрутизаторов, подключенных к сети (см. параграф 12.4.2).

Описывает внутридоменные маршруты и обеспечивает возможность конденсации маршрутных данных на границе области. Генерируемые граничными

маршрутизаторами областей summary-LSA типа 3 описывают маршруты в сети, а summary-LSA типа 4 – к граничным маршрутизаторам AS.

поля Link State ID зависит от типа LSA (см. таблицу 19).

AS-external-LSA

Генерируются граничными

маршрутизаторами AS и описывают

Для summary-LSA (тип 3) и AS-external-LSA (тип 5) Link

State ID дополнительно может содержать несколько

host-битов сети-получателя. Например, при генерации

AS-external-LSA для сети 10.0.0.0 с маской 255.0.0.0 Link

маршруты к адресатам за пределами AS. Эта запись может также содержать маршрут, принятый по умолчанию для AS.

State ID может указывать на любой адрес в диапазоне от

10.0.0.0 до 10.255.255.255 включительно (хотя по возможности следует использовать 10.0.0.0). Установка хост-битов позволяет

маршрутизатору генерировать раздельные LSA для двух сетей с одинаковым номером, но разными масками (см. Приложение E).

Когда LSA описывает сеть (типы LS 2, 3, 5), IP-номер сети легко

Таблица 19 Значение Link State ID.

определить, используя маску сети/подсети, содержащуюся в LSA, и значение Link State ID. Если LSA описывает маршрутизатор (типы LS 1 и 4), значение Link State ID всегда описывает OSPF Router ID. Для AS-external-LSA (тип 5), описывающих принятый по умолчанию маршрут, Link State ID=DefaultDestination (0.0.0.0).

Router ID генерирующего маршрутизатора. IP-адрес интерфейса маршрутизатора DR для сети. IP-номер сети получателя. Router ID для граничного маршрутизатора AS. IP-номер сети получателя.

12.1.5. Анонсирующий маршрутизатор

Это поле содержит идентификатор OSPF Router ID породившего LSA маршрутизатора. Для router-LSA это поле совпадает с полем Link State ID. Записи Network-LSA порождаются маршрутизаторами DR, Summary-LSA – граничными маршрутизаторами областей, а AS-external-LSA – граничными маршрутизаторами AS.

¹⁹ MaxAgeDiff является архитектурной константой и показывает максимальное расхождение возраста (в секундах), которое может возникнуть для одного экземпляра LSA при лавинной рассылке в домене маршрутизации. Если разница в возрасте двух LSA превышает это значение, предполагается, что это два разных экземпляра LSA. Это может происходить в тех случаях, когда маршрутизатор был перезагружен и потерял информацию о порядковом номере предыдущей записи LSA (см. параграф 13.4).

rfc.com.ru 35 rfc.com.ru

Перевод RFC 2328

12.1.6. Порядковый номер LS

Порядковый номер трактуется как 32-разрядное целое число со знаком и используется для обнаружения старых LSA и дубликатов. Пространство порядковых номеров линейно упорядочено и больший порядковый номер (при сравнении 32-битовых целых чисел со знаком) соответствует более новой записи LSA. Далее при описании порядковых номеров N будет обозначать 2³¹.

Порядковый номер -N (0x80000000) зарезервирован и не должен использоваться. Значение -N + 1 (0x80000001) является минимальным (следовательно, самым старым) порядковым номером и используется в качестве константы InitialSequenceNumber. Маршрутизатор использует номер InitialSequenceNumber при первой генерации LSA. После этого порядковые номера LSA увеличиваются на 1 при генерации каждого нового экземпляра LSA. При достижении порядкового номера N – 1 (0x7fffffff или MaxSequenceNumber), сначала нужно удалить текущий экземпляр LSA из домена маршрутизации. Для этого используется принудительное старение (prematurely aging) LSA (см. параграф 14.1) и повторная лавинная рассылка. После подтверждения этой рассылки всеми смежными маршрутизаторами возможна генерация новой записи с порядковым номером InitialSequenceNumber.

Для маршрутизатора может потребоваться форсирование анонса порядкового номера одной из его LSA при неожиданном приеме более нового экземпляра LSA в процессе лавинной рассылки. Это происходит редко и может говорить о наличии устаревших LSA, сгенерированных самим маршрутизатором при его последней загрузке, которые еще сохраняются в AS (см. параграф 13.4).

12.1.7. Контрольная сумма LS

Это поле включает контрольную сумму записи LSA без учета поля LS age для того, чтобы можно было увеличивать поле возраста без пересчета контрольной суммы. При расчете контрольных сумм используется тот же алгоритм, который применяется для дейтаграмм ISO без организации соединений – его часто называют алгоритмом Флэтчера. Этот алгоритм описан в работе [Ref6] (Annex B). Заголовок LSA содержит также размер LSA в байтах без учета поля LS age (два байта) для вычисления контрольной суммы.

Контрольная сумма служит для детектирования повреждений LSA, которые могут происходить при лавинной рассылке или хранении в памяти маршрутизатора. Поле контрольной суммы не может быть нулевым, значение 0 должно рассматриваться как ошибка. Иными словами, вычисление контрольной суммы является обязательным.

Контрольная сумма LSA проверяется в двух случаях: a) при получении пакета Link State Update и b) во время «состаривания» базы данных. Обнаружение ошибок в контрольной сумме ведет к различным ситуациям, описанным в главах 13 и 14.

Когда поля порядковых номеров двух записей LSA совпадают, сравниваются контрольные суммы. Если суммы различаются, более новым считается экземпляр с большим значением контрольной суммы²⁰ (см. параграф 13.1).

12.2. База данных link-state

Маршрутизатор имеет отдельную базу данных о каналах для каждой области, к которой он относится и все маршрутизаторы одной области имеют идентичные базы данных.

Базы данных каждой области всегда обрабатываются раздельно. Расчет кратчайших путей выполняется отдельно для каждой области (см. главу 16). Лавинная рассылка компонент базы данных области ведется только в пределах области. И, наконец, при организации отношений смежности между двумя маршрутизаторами синхронизируются только базы данных общей области.

База данных области состоит из router-LSA, network-LSA и summary-LSA (все они перечислены в структуре данных области). Для нетупиковых областей в базу данных включаются также AS-external-LSA (см. параграф 3.6).

Реализация протокола OSPF должна обеспечивать возможность доступа к отдельным частям базы данных области. Эта функция просмотра основана на полях LS type, Link State ID и Advertising Router²¹. Поиск будет давать один экземпляр (самый новый) каждой записи LSA в базе данных. Функции поиска в базе данных используются процедурой лавинной рассылки LSA (глава 13) и при расчете таблицы маршрутов (глава 16). Кроме того, используя эту функцию, маршрутизатор может определить не он ли породил данную запись LSA и (если он) с каким порядковым номером.

Запись LSA добавляется в базу данных маршрутизатора, если a) она получена в процессе лавинной рассылки (глава 13) или b) происходит о данного маршрутизатора (параграф 12.4). LSA удаляются из базы данных маршрутизатора, если a) получен более новый экземпляр в процессе лавинной рассылки (глава 13), b) маршрутизатор сам генерирует новый экземпляр LSA (параграф 12.4) или c) LSA удаляется из домена маршрутизации в результате старения (глава 14). При удалении LSA из базы данных, эта запись должна удаляться также из списков Link state retransmission всех соседей (см. главу 10).

12.3. Представление TOSесли a) получен более новый экземпляр в процессе лавинной рассылки (глава 13), b) маршрутизатор сам генерирует новый экземпляр LSA (параграф 12.4) или c) LSA удаляется из домена маршрутизации в результате старения (глава 14). При удалении LSA из базы данных, эта запись должна удаляться также из списков Link state retransmission всех соседей (см. главу 10).

12.3. Представление TOS

Для обратной совместимости с предыдущими версиями OSPF [Ref9], в router-LSA, summary-LSA и AS-external-LSA может включаться информация, связанная с TOS. Представление TOS в OSPF LSA описано в таблице 20, содержащей коды OSPF для представления полей TOS (определены в работе [Ref12]) пакетов IP. В OSPF используется десятичное представление, а в заголовках IP применяются битовые поля TOS, описанные в [Ref12].

²⁰ Когда контрольные суммы двух LSA различаются, предполагается, что это два разных экземпляра. Это может быть следствием перезагрузки маршрутизатора или потери маршрутизатором данных о предыдущем порядковом номере LSA. Если порядковые номера двух LSA совпадают, невозможно определить, которая из записей новее. Однако если в качестве новой будет принята некорректная запись LSA, генерирующий их маршрутизатор просто будет порождать другой экземпляр (см. параграф 13.4).

²¹ Существует ситуация, когда поиск должен основываться на частичной информации. Это происходит при расчете таблицы маршрутов, когда нужно найти network-LSA, основываясь исключительно на Link State ID. Результаты поиска однозначны, поскольку не существует двух two network-LSA с одинаковыми полями Link State ID.

rfc.com.ru 36 rfc.com.ru

Перевод RFC 2328

12.4. Генерация LSA

В каждой области OSPF маршрутизатор будет генерировать несколько типов LSA.

Каждый маршрутизатор генерирует router-LSA. Если маршрутизатор является DR

для любой из сетей области, он будет генерировать network-LSA для этой сети.

Граничные маршрутизаторы областей генерируют одну запись summary-LSA для

каждого адресата с междоменным маршрутом. Граничные маршрутизаторы AS

генерируют одну запись AS-external-LSA для каждого известного адресата за

пределами AS. Адресаты анонсируются по одному, поэтому изменение отдельного

маршрута не требует повтора лавинной рассылки для всего набора маршрутов. В

процессе лавинной рассылки один пакет LSU может включать множество LSA.

В качестве примера рассмотрим маршрутизатор RT4 на рисунке 4, являющийся

граничным в области 1 и связанный с магистралью. Маршрутизатор RT4

генерирует 5 разных LSA в магистраль (router-LSA и summary-LSA для каждой из

сетей N1-N4). Маршрутизатор RT4 будет также порождать 8 различных LSA для

области 1 (router-LSA и семь summary-LSA, показанных в таблице 6). Если RT4

Таблица 20 Представление TOS в OSPF. Код Значения TOS RFC 1349

OSPF

0000 нормальное обслуживание

0001 минимальная оплата 0010 максимальная надежность 0011 0100 максимальная пропускная

способность

0101

0110

0111

1000 минимальная задержка

1001

1010

10 12 14 16 18 20

будет выбран DR для сети N3, он будет генерировать в область 1 network-LSA для

N3.

Маршрутизатор RT5 будет генерировать AS-external-LSA (для каждой из сетей

N12 - N14). Эти записи будут рассылаться в лавинном режиме по всей AS,

поскольку ни одна из областей не предполагается тупиковой. Однако если область


	22	1011
	24	1100
	26	1101
	28	1110
	30	1111

3 указать как тупиковую, AS-external-LSA для сетей N12-N14 не будут рассылаться

в область 3 (см. параграф 3.6). Взамен этого маршрутизатор RT11 будет генерировать запись summary-LSA с принятым по

умолчанию маршрутом, которая будет рассылаться в области 3 (см. параграф 12.4.3). В результате все внутренние

маршрутизаторы области 3 будут передавать внешний трафик маршрутизатору RT11.

При создании нового экземпляра LSA увеличивается порядковый номер, устанавливается LS age=0, вычисляется контрольная

сумма и LSA добавляется в базу данных, после чего происходит лавинная рассылка через соответствующие интерфейсы.

Включение LSA в базу данных подробно описано в параграфе 13.2, а параграф 13.3 посвящен лавинной рассылке новых

экземпляров LSA.

Ниже перечислены 10 событий, которые могут приводить к генерации новых экземпляров LSA:

(1) Поле LS age одной из порожденных маршрутизатором LSA достигло значения LSRefreshTime. В таких случаях генерируется новый экземпляр LSA, несмотря на отсутствие изменений одержимого LSA (кроме заголовка). Это гарантирует периодическое обновление всех LSA и повышает устойчивость алгоритма link state. LSA, описывающие только недоступных адресатов, не должны обновляться и их нужно удалять из области маршрутизации (см. параграф 14.1).

Когда изменяется что-то из описываемого LSA, генерируется новый анонс LSA, однако в течение MinLSInterval не может порождаться более одного экземпляра LSA. Поэтому генерация нового экземпляра может быть задержана на время до MinLSInterval. Перечисленные ниже события могут приводить к изменениям содержимого LSA и должны порождать генерацию новых экземпляров тогда и только тогда, когда новая запись LSA будет отличаться от прежней.

(2) Изменилось состояние интерфейса (см. параграф 9.1) и может потребоваться генерация нового экземпляра router-LSA.

(3) Сменился маршрутизатор DR. Требуется генерация нового анонса router-LSA. Если данный маршрутизатор стал DR, нужно генерировать новые network-LSA. Если данный маршрутизатор перестал быть DR, все network-LSA, которые он мог породить для сети, должны быть удалены из домена маршрутизации (см. параграф 14.1).

(4) Один из соседей перешел в состояние FULL или покинул его. Это требует генерации новых экземпляров router-LSA. Если данный маршрутизатор является DR для подключенной сети, он должен породить новый экземпляр network-LSA.

Следующие 4 события относятся только к граничным маршрутизаторам областей:

(5) В таблице маршрутизации был изменен/добавлен/удален внутридоменный маршрут и может потребоваться генерация нового экземпляра summary-LSA (для этого маршрута) в каждую подключенную область (возможно и магистральную).

(6) В таблице маршрутизации был изменен/добавлен/удален междоменный маршрут и может потребоваться генерация нового экземпляра summary-LSA (для этого маршрута) в каждую подключенную область (кроме магистральной).

(7) К области подключен новый маршрутизатор и он должен породить summary-LSA в подключенную недавно область для всех имеющих отношение внутридоменных и междоменных маршрутов в таблице маршрутизатора (см. параграф 12.4.3).

(8) Изменилось состояние одного из маршрутизаторов с настроенным виртуальным каналом и может потребоваться генерация новых router-LSA в транзитную область виртуального канала (см. описание бита V записи router-LSA в параграфе 12.4.1), а также в магистраль.

Последние 2 события относятся только к граничным маршрутизаторам AS (включая бывшие):

(9) Изменился внешний маршрут, полученный от другого протокола маршрутизации (например, BGP) и от граничного маршрутизатора AS может потребоваться генерация нового экземпляра AS-external-LSA.

(10) Маршрутизатор перестал быть граничным в AS (возможно после перезагрузки) и требуется удаление всех порожденных ранее AS-external-LSA (для этого используется принудительное старение, описанное в параграфе 14.1).

Подробное описание структуры всех типов LSA приведено ниже. В следующих разделах описывается содержимое LSA, а 20-байтовые заголовки LSA описаны в параграфе 12.1.

12.4.1. LSA для маршрутизатора

Маршрутизатор генерирует router-LSA для каждой области, к которой он относится. LSA описывает состояния каналов маршрутизатора в область. Анонсы LSA рассылаются в лавинном режиме внутри области, не покидая ее.

Маршрутизатор также показывает свою принадлежность к граничным маршрутизаторам области или AS, устанавливая биты B или E, соответственно, в router-LSA. Это позволяет сохранять пути к таким маршрутизаторам в таблице для последующей обработки summary-LSA и AS-external-LSA. Бит B должен устанавливаться, если маршрутизатор имеет активные соединения с двумя или более областями, даже если этот маршрутизатор не подключен к магистральной области OSPF. Бит E никогда не должен устанавливаться в router-LSA для тупиковых областей (такие области не могут включать граничные маршрутизаторы AS).

В дополнение к этому маршрутизатор устанавливает бит V в router-LSA для области A тогда и только тогда, когда маршрутизатор является конечной точкой для одного или нескольких виртуальных каналов с полной смежностью, использующих область A в качестве транзитной. Установка бита V позволяет другим маршрутизаторам области A обнаруживать поддерживаемый областью трафик (см. TransitCapability в главе 6).

Таблица 21 Описание каналов в router-LSA. Тип Описание Идентификатор

1 «Точка-точка» Neighbor Router ID

2 Канал в транзитную сеть Адрес интерфейса

3 Канал в оконечную сеть

4 Виртуальный канал

Номер IP-сети Neighbor Router ID

rfc.com.ru

Перевод RFC 2328

Router-LSA описывает работающие соединения (интерфейсы или каналы) маршрутизатора с областью. Тип каждого канала зависит от подключенной сети. Каждый канал имеет также идентификатор Link ID, используемый в качестве обозначения объекта на другой стороне соединения. В таблице 21 приведены значения полей Type и Link ID.

Для каждого канала используется также поле Link Data, содержащее 32 бита дополнительной информации о канале. Для каналов в транзитные сети, и адресуемых соединений «точка-точка» это поле содержит IP-адрес интерфейса маршрутизатора (он нужен для расчета таблицы маршрутов, описанного в параграфе 16.1.1). Для каналов в тупиковые сети это поле задает маску тупиковой сети. Для безадресных каналов point-to-point поле Link Data должно содержать значение MIB-II unnumbered-интерфейса - ifIndex [Ref8]. Наконец, задается стоимость использования канала для исходящего трафика. Стоимость канала может настраиваться и для всех каналов, кроме случая тупиковых сетей, стоимость должна быть больше 0.

Для дальнейшего рассмотрения процесса построения списка описаний каналов рассмотрим случай создания маршрутизатором анонса router-LSA для области A. Для этого маршрутизатор проверяет набор структур данных интерфейсов, выполняя для каждого интерфейса следующие операции:

♦ Если подключенная сеть не относится к области A, в LSA не добавляется каналов и проверяется следующий интерфейс.

♦ В остальных случаях в router-LSA добавляется описание канала в зависимости от типа интерфейса OSPF. Описание канала для интерфейсов point-to-point приведено в параграфе 12.4.1.1, для виртуальных соединений - в параграфе 12.4.1.2, для широковещательных и NBMA-интерфейсов - в 12.4.1.3 и для интерфейсов Point-to-MultiPoint - в параграфе 12.4.1.4.

После рассмотрения всех интерфейсов маршрутизатора в router-LSA добавляются соединения с хостами путем проверки подключенных хостов, относящихся к области A. Маршруты хостам относятся к типу 3 (тупиковая сеть), поле Link ID содержит IP-адрес хоста, Link Data - маску 0xffffffff, а стоимость маршрута должна быть больше 0 (см. параграф C.7).

12.4.1.1. Описание интерфейсов point-to-point

Для интерфейсов point-to-point в router-LSA добавляется одно или несколько описаний каналов:

♦ Если соседний маршрутизатор является полностью смежным, добавляется канал типа 1 (point-to-point). Поле Link ID должно содержать Router ID соседнего маршрутизатора. Для адресуемых сетей point-to-point поле Link Data должно содержать IP-адрес интерфейса, а для unnumbered-сетей - значение ifIndex (MIB-II [Ref8]). Стоимость канала должна совпадать с выходной стоимостью интерфейса point-to-point.

♦ В дополнение к этому, если интерфейс находится в состоянии Point-to-Point (независимо от состояния соседнего маршрутизатора), должен добавляться канал типа 3 (тупиковая сеть). Этот тупиковый канал может принимать две формы:

Опция 1

Предполагая, что IP-адрес соседнего маршрутизатора известен, устанавливаем для поля Link ID (тип 3) значение этого адреса IP, в поле Link Data помещаем маску 0xffffffff (маршрут к хосту), а стоимость устанавливаем больше нуля²².

Опция 2

Если для канала «точка-точка» выделена подсеть, устанавливаем в поле Link ID типа 3 IP-адрес подсети, в поле Link Data - ее маску и задаем положительное значение для стоимости²³.[16]

12.4.1.2. Описание интерфейсов в широковещательные и NBMA-сети

Для широковещательных и NBMA-интерфейсов в router-LSA добавляется одно описание канала:

♦ Если интерфейс находится в состоянии Waiting, добавляется канал типа 3 (тупиковая область), поле Link ID содержит IP-номер подключенной сети, Link Data - маску сети, а стоимость совпадает с выходной стоимостью интерфейса.

♦ Для остальных случаев должен быть известен выделенный маршрутизатор DR для подключенной сети. Если маршрутизатор является полностью смежным с DR или сам является DR и имеет полностью смежный маршрутизатор, добавляется канал типа 2 (транзитная сеть), поле Link ID содержит IP-адрес интерфейса DR (возможно интерфейс данного маршрутизатора), Link Data содержит IP-адрес интерфейса данного маршрутизатора, а стоимость совпадает с выходной стоимостью для интерфейса. Во всех прочих случаях добавляется один канал как для описанного выше состояния Waiting.

12.4.1.3. Описание виртуальных соединений

Для виртуальных каналов описание добавляется в router-LSA только при полной смежности виртуальных соседей. В таких случаях добавляется канал типа 4 (виртуальный), Link ID = Router ID для виртуального соседа, Link Data содержит IP-адрес интерфейса, связанного с виртуальным каналом, а стоимость совпадает со стоимостью виртуального канала, рассчитанной при создании таблицы маршрутизации (глава 15).

12.4.1.4. Описание интерфейсов Point-to-MultiPoint

Для интерфейсов Point-to-MultiPoint в router-LSA добавляется один или несколько каналов:

♦ Добавляется один канал типа 3 (тупиковая сеть), Link ID содержит IP-адрес интерфейса данного маршрутизатора, Link Data = 0xffffffff (маска хоста), а стоимость равна нулю.

♦ Для каждого полностью смежного соседа, связанного с интерфейсом, добавляется канал типа 1 (point-to-point), Link ID = Router ID соседнего маршрутизатора, поле Link Data содержит IP-адрес интерфейса, а стоимость равна выходной стоимости для интерфейса.

12.4.1.5. Примеры router-LSA

Рассмотрим анонсы router-LSA, генерируемые RT3 (см. рисунок 4). Область, содержащая RT3 (Area 1) с реальными сетевыми адресами показана на рисунке 11. Предположим, что последний байт адреса всех интерфейсов маршрутизатора RT3 равен 3 (адреса 192.1.1.3 и 192.1.4.3) и в других маршрутизаторах используется аналогичная схема адресации. Кроме того, предположим, что все соединения функционируют и в качестве Router ID используется меньший из IP-адресов интерфейсов. RT3 генерирует два анонса router-LSA - для области 1 и для магистрали. Предположим, что маршрутизатор RT4 выбран в качестве DR для сети 192.1.1.0. Анонс router-LSA маршрутизатора RT3 для области 1 при оговоренных условиях показан ниже. Он показывает, что RT3 имеет два соединения с областью 1 - одно в транзитную сеть 192.1.1.0 и другое в тупиковую сеть 192.1.4.0.

²² Это способ представляет канал «точка-точка» в соответствии с RFC 1583. Данный способ обеспечивает ряд преимуществ: a) не требуется выделения подсети для каналов «точка-точка», b) пакеты, адресованные интерфейсу point-to-point, будут реально приниматься через интерфейс (это полезно для диагностики) и c) поддерживается загрузка соседей через сеть (network bootstrapping) без необходимости поддержки bootstrap-загрузки реализацией протокола OSPF.

²³ Это представление каналов point-to-point более традиционно и используется протоколами типа RIP.

rfc.com.ru 38 rfc.com.ru


На главную




Network Working Group Request for Comments: 2328 STD: 54 Obsoletes: 2178 Category: Standards Track		J. Moy Ascend Communications, Inc. April 1998

Протокол OSPF версии 2 OSPF Version 2 *Статус документа* Этот документ содержит спецификацию протокола для сообщества Internet и служит запросом для дальнейшего обсуждения и предложений в целях совершенствования протокола. Точные сведения о статусе документа можно найти в Internet Official Protocol Standards ( STD 1 ). Документ может распространяться свободно. *Авторские права* Copyright (C) The Internet Society (1998). All Rights Reserved. *Тезисы* Этот документ описывает вторую версию OSPF – протокола маршрутизации на основе состояний каналов (link-state routing protocol). Протокол предназначен для использования внутри автономных систем (AS). Все OSPF-маршрутизаторы поддерживают идентичные базы данных с описанием топологии AS. На основании данных из базы рассчитывается маршрут путем конструирования дерева кратчайшего пути. При изменении топологии OSPF быстро пересчитывает маршруты и не порождает значительного трафика при обновлении маршрутной информации. Протокол OSPF обеспечивает поддержку множества путей с одинаковой стоимостью (equal-cost multipath). Поддерживается «маршрутизация областей» (area routing), обеспечивающая дополнительный уровень защиты маршрутизации и снижение служебного трафика при обмене маршрутной информацией. Кроме того, обмен маршрутной информацией осуществляется с использованием средств аутентификации. Различия между этим документом и RFC 2178 рассмотрены в Приложении G. Все изменения протокола обеспечивают обратную совместимость. Реализации описываемого протокола совместимы (интероперабельны) с реализациями RFC 2178, RFC 1583 и RFC 1247. Комментарии к данному документу направляйте по адресу ospf@gated.cornell.edu.

Оглавление
	............................................................................................................................................................... ...................... 1 ............................................................................................................................................................... ...................... 1 ....................................................................................................................................................................... ..... .... ...... 1 ........................................................................................................................................................... ....... ..................... 3 1.1. Обзор протокола ............................................................................................................................................................................... ..3... 1.2. Терминология .................................................................................................................................................................................. ........4. . 1.3. Краткая история маршрутизации на базе состояния каналов ................................................................................................... ..... 5 1.4. Структура документа ...................................................................................................................................................................... ..... 5. . 1.5. Благодарности ........................................................................................................................................................... ... ........................... 6 2. База данных Link-state: структура и расчеты ................................................................................................................................. ........... 6 2.1. Представление маршрутизаторов и сетей ...................................................................................................................................... ....6. . 2.1.1. Представление сетей без широковещания .................................................................................................................... ........... 7 2.1.2. Пример базы данных о каналах ..................................................................................................................................... ............. 7 2.2. Дерево кратчайших путей .............................................................................................................................................................. ....9... 2.3. Внешние данные ................................................................................................................................................................................ ...9... 2.4. Множество равноценных путей ......................................................................................................................................... .............. 10 3. Деление AS на области ........................................................................................................................................................ ....... .................. 10 3.1. Магистраль AS ................................................................................................................................................................................... 1..0... 3.2. Маршрутизация между областями .............................................................................................................................................. ..... 1. 0 3.3. Классификация маршрутизаторов ............................................................................................................................................. ...... 11 3.4. Пример конфигурации областей ............................................................................................................................................... ....... 12 3.5. Поддержка подсетей IP .................................................................................................................................................. ...... .. ............. 13 3.6. Поддержка «тупиковых» областей ........................................................................................................................................ .......... 14 3.7. Разделение областей .................................................................................................................................................... ..... .. ................. 14 4. Основные функции ............................................................................................................................................................ ......................... 14 4.1. Междоменная маршрутизация ..................................................................................................................................................... ....1..5 4.2. Внешние маршруты AS ..................................................................................................................................................................... 1. .5... 4.3. Пакеты протокола маршрутизации ............................................................................................................................................. ..... 1. 5
4.4. Основные требования к реализации.... 4.5. Дополнительные возможности OSPF.. 5. Структуры данных протокола ...................... 6. Структура данных области ........................... 7. Организация отношений смежности ........... rfc.com.ru		.....................................16 ......................................17 ..................................17 ................................18 .....................................19 rfc.com.ru



	Перевод RFC 2328 7.1. Протокол Hello ........................................................................................................................................................................... ..... ...19 7.2. Синхронизация баз данных .......................................................................................................................................... ..................... 19 7.3. Выделенный маршрутизатор DR ................................................................................................................................................. ....2. 0 7.4. Резервный маршрутизатор DR ........................................................................................................................................................ .2..0... 7.5. Граф смежности ................................................................................................................................................................................ .2..1.... 8. Обработка пакетов протокола ................................................................................................................................................... ................ 21 8.1. Передача пакетов .................................................................................................................................................................. ............. 21 8.2. Прием пакетов протокола .............................................................................................................................................................. ......2. .2. 9. Структура данных интерфейса .......................................................................................................................................................... ........23 9.1. Состояния интерфейса ............................................................................................................................................................... ....... 24 9.2. События, изменяющие состояние интерфейса ....................................................................................................................... ........ 25 9.3. Машина состояний интерфейса ....................................................................................................................................................... 25 9.4. Назначение DR ................................................................................................................................................................................ ....2. .6. . 9.5. Передача пакетов Hello .......................................................................................................................................... ........................... 27 9.5.1. Передача пакетов Hello в сети NBMA ............................................................................................................................. ......27 10. Структура данных Neighbor ................................................................................................................................................................. ..2. .8... 10.1. Состояния соседей ............................................................................................................................................................ ............... 29 10.2. События, меняющие состояние соседа ....................................................................................................................... .................. 30 10.3. Машина состояний Neighbor .......................................................................................................................................................... 3..0.... 10.4. Когда организуется смежность ................................................................................................................................................. ..... 32 10.5. Прием пакетов Hello .................................................................................................................................................................. ..... 3. .2 10.6. Прием пакетов DD .......................................................................................................................................................... ..... ............... 33 10.7. Прием пакетов Link State Request ................................................................................................................................ ..... .............. 34 10.8. Передача пакетов DD .................................................................................................................................................... ..... .. ............. 34 10.9. Передача пакетов Link State Request .............................................................................................................................. ....... ........... 35 10.10. Пример ....................................................................................................................................................................... ...................... 35 11. Структура таблицы маршрутов ............................................................................................................................................................ ....3..5.. 11.1. Просмотр таблицы маршрутов ................................................................................................................................. ..... .................... 36 11.2. Пример таблицы маршрутизации без областей ............................................................................................................................ 37 11.3. Пример таблицы маршрутизации с областями ............................................................................................................................ 3. 7 12. Анонсы состояния каналов (LSA) .................................................................................................................................................. ........ 38 12.1. Заголовок LSA ............................................................................................................................................................. ..................... 38 12.1.1. Возраст LS ...................................................................................................................................................................... ......... 38 12.1.2. Опции ...................................................................................................................................................................................... ..3. .9.... 12.1.3. Тип LS ................................................................................................................................................................................ .......3. .9 12.1.4. Link State ID ............................................................................................................................................................................. 3. 9 12.1.5. Анонсирующий маршрутизатор ............................................................................................................................ ..... .. ........... 39 12.1.6. Порядковый номер LS .......................................................................................................................................... ................... 39 12.1.7. Контрольная сумма LS ......................................................................................................................................... .................. 40 12.2. База данных link-state .......................................................................................................................................................... ..... .......... 40 12.3. Представление TOS ............................................................................................................................................................ .............. 40 12.4. Генерация LSA ............................................................................................................................................................................ ..... .4..1 12.4.1. LSA для маршрутизатора ............................................................................................................................... ..... ..................... 42 12.4.1.1. Описание интерфейсов point-to-point ................................................................................................................. ......... 42 12.4.1.2. Описание интерфейсов в широковещательные и NBMA-сети ................................................................................. .4..2 12.4.1.3. Описание виртуальных соединений ..................................................................................................................... ........ 43 12.4.1.4. Описание интерфейсов Point-to-MultiPoint .................................................................................................. ................ 43 12.4.1.5. Примеры router-LSA ...................................................................................................................................................... .4..3... 12.4.2. LSA для сети ............................................................................................................................................................................ 4. 4 12.4.2.1. Примеры network-LSA .................................................................................................................................... .. ................ 44 12.4.3. Summary-LSA ............................................................................................................................................................ ............... 44 12.4.3.1. Генерация summary-LSA в тупиковые области ........................................................................................................ ...4. 5 12.4.3.2. Примеры summary-LSA ......................................................................................................................................... ......... 45 12.4.4. AS-external-LSA .................................................................................................................................................... ..... .... ............ 46 12.4.4.1. Примеры AS-external-LSA ............................................................................................................................................ ..4. .6. . 13. Процедура лавинной рассылки (Flooding) .................................................................................................................................. .... ........ 47 13.1. Сравнение возраста LSA ............................................................................................................................................................. ....4. .7. 13.2. Инсталляция LSA в базу данных .................................................................................................................................................. .4..8. 13.3. Следующий этап лавинной рассылки ...................................................................................................................................... ...... 48 13.4. Прием собственных (self-originated) LSA ................................................................................................................. ..................... 49 13.5. Передача LSA ............................................................................................................................................................................ ..... .....49 13.6. Повторная передача LSA .......................................................................................................................................................... ........50 13.7. Подтверждение приема состояния канала ............................................................................................................................ ........ 50 14. Старение базы данных LS ................................................................................................................................................... ..................... 50 14.1. Принудительное старение LSA ......................................................................................................................................... ............. 51 15. Виртуальные соединения ..................................................................................................................................................... ....... ............... 51 16. Расчет таблицы маршрутизации ................................................................................................................................................. ............ 52 16.1. Расчет кратчайшего пути для области .................................................................................................................................. ..... ...... 52 16.1.1. Расчет next hop ..................................................................................................................................................... ....... ................ 54 16.2. Расчет междоменных маршрутов ................................................................................................................................................. .5..4. 16.3. Просмотр summary-LSA от транзитных областей ................................................................................................................... ....5. 5 16.4. Расчет внешних маршрутов AS ............................................................................................................................................ ......... 56 16.4.1. Предпочтения для внешнего пути ...................................................................................................................................... ....5..6 16.5. Нарастающие обновления – summary-LSA ........................................................................................................................... ........ 56 16.6. Нарастающие обновления – AS-external-LSA .......................................................................................................................... ....5. 7 16.7. События, генерируемые при изменении таблицы маршрутов ....................................................................................... ............ 57 16.8. Множество равноценных путей .................................................................................................................................. .................... 57 Литература ................................................................................................................................................................................................. ..... .5..7 rfc.com.ru 2 rfc.com.ru



													Перевод RFC 2328

+ I 3+---+ N12 N14 N1\|--\|RT1\|\ 1 \ N13 / \| +—+ \ 8\ \|8/8 + \ _____ \\|/ / \ 1+—+8 8+ —-+6 * N3 ---\|RT4\|------\|RT5\|-----* \_____/ +—+ +—+

+ / I 3+—+ / N2 \| — \|RT2\|/1 \| +---+						I I И +---+8 \|RT3\| — +---+ 12 I N4			17 \| \|6 6+---+
									-\|RT6\| +---+ la

N11

I 13 +---+ \|RT9\| +---+ И _l_ / \ к ид					N12
					1+----+2 *------\|RT11\| —			I I — I-I I + N8	lb \|5 3+----+1 — \|RT10\| — +----+			16 2/ +—+/ \|RT7\|---N15 +---+ 9 И / \ -* N6 * \_____/ I И +---+ \|RT8\| +---+ И I
\				/
I И +—+ 10+----+ \| HI \|-----\|RT12\| +—+SLIP +----+ 12 I +---------- N10
						N7 Рисунок 2. Пример автономной системы

От узла												Таблица 1 Графическое представление базы данных.

К у з л у	RT1 RT2		RT3 RT4 RT5 RT6 RT7 RT8							RT9 RT10 RT11 RT12			N3 0 0 0	N6 N8	N9
	RT1 RT2 RT3					6
	RT4 RT5 RT6 RT7 RT8 RT9			8	8	S							0
						6		6
					5
				0

RT10 RT11 RT12 N1 N2 N3		7
		0
		3
		1		1	1

N4 N6 N7 N8 N9 N10							1				1
							3
							1

N11 N12 N13 N14 N15 HI						3
						2
						9
						10

rfc.com.ru									8				rfc.com.ru



		Перевод RFC 2328
		Перевод RFC 2328
	*Поддержка задач - Tasking support* Некоторые процедуры, описанные в этой спецификации, включают в себя выполнение других процедур. Иногда такие процедуры должны выполняться в режиме in-line, т. е., до того, как будет завершена текущая процедура. В тексте такие ситуации указаны инструкциями на выполнение процедуры. В других случаях, новая процедура выполняется только после завершения текущей. Такие ситуации показаны инструкциями на планирование задач. 4.5. Дополнительные возможности OSPF Протокол OSPF включает несколько дополнительных возможностей, реализация которых осуществляется по усмотрению разработчиков. Маршрутизатор указывает поддерживаемые им дополнения в своих пакетах OSPF Hello, Database Description LSA. Это позволяет использовать в одной автономной системе маршрутизаторы с разными наборами дополнительных возможностей. Некоторое возможности должны поддерживаться всеми маршрутизаторами, подключенными к данной области. В таких случаях маршрутизатор не будет воспринимать пакеты Hello от соседей, пока не убедится в наличии требуемого соответствия (т. е., несоответствие возможностей предотвращает организацию отношений соседства). Примером такой дополнительной функции может служить ExternalRoutingCapability (см. ниже). Другие возможности могут быть согласованы при обмене базами данных (Database Exchange). Это согласование реализуется указанием дополнительных возможностей в пакетах Database Description. Несоответствие возможностей с соседями в данном случае будет приводить лишь к сужению числа используемых дополнений и соответствующей корректировке содержимого баз данных при обмене между соседями. Наличие дополнительных возможностей может влиять и на процесс построения таблицы маршрутов. Поскольку дополнительные возможности указываются в LSA, маршрутизаторы, неспособные поддерживать те или иные дополнения, могут быть опущены при построении дерева кратчайших путей. Дополнительные возможности протокола OSPF, определенные в данной спецификации, перечислены ниже. Более подробные сведения о таких возможностях приведены в параграфе A.2. *ExternalRoutingCapability* Как было сказано выше (параграф 3.6) целые области OSPF могут быть настроены как тупиковые (stub). Анонсы AS-external-LSA не будут рассылаться в такие области. Эта возможность указывается битом E в поле опций OSPF (см. параграф A.2). Для того чтобы обеспечить согласованную настройку тупиковых областей, все маршрутизаторы, имеющие интерфейсы в такие области, должны устанавливать нулевое значение бита E в своих пакетах Hello (см. параграфы 9.5 и 10.5). *5. Структуры данных протокола* Протокол OSPF описывается в данной спецификации в терминах обработки различных структур данных этого протокола. Ниже приведен список структур данных OSPF верхнего уровня. Если структура данных требует инициализации, нужные действия указаны явно. В протоколе OSPF области, интерфейсы и соседи также используют структуры данных, которые описаны ниже вместе с соответствующими объектами. *Router ID (идентификатор маршрутизатора)* 32-битовое целое число, позволяющее уникально пронумеровать каждый маршрутизатор в AS. Одним из вариантов идентификатора может служить наименьший из IP-адресов маршрутизаторов интерфейса. При смене значения Router ID требуется перезагрузка программ OSPF в маршрутизаторе для работы с новым идентификатором Router ID. В таких случаях маршрутизатор должен удалить свои (self-originated) LSA из области маршрутизации (см. параграф 14.1) до перезагрузки, поскольку в противном случае эти анонсы будут сохраняться в течение времени MaxAge. *Area structures (структуры области)* Каждая из областей, к которой подключен маршрутизатор, имеет свою структуру данных, описывающую работу базового алгоритма OSPF. Напомним, что в каждой области работает отдельная копия базового алгоритма OSPF. *Backbone (area) structure (структура магистральной области)* Магистральная область OSPF отвечает за распространение данных междоменной (inter-area) маршрутизации. *Virtual links configured (настроенное виртуальное соединение)* Виртуальные соединения настраиваются между маршрутизаторами, служащими конечными точками таких соединений. Для организации виртуального соединения маршрутизатор должен быть граничным в области. Виртуальные соединения обозначаются идентификаторами Router ID удаленного маршрутизатора (он также является граничным в своей области). Для организации виртуального соединения оба участвующих в нем маршрутизатора должны быть подключены к общей области, называемой транзитной для виртуального канала (virtual link's Transit area). Виртуальные соединения включаются в магистраль AS, как будто они связаны между собой через сеть «точка-точка» без адресации интерфейсов (unnumbered). Виртуальное соединение использует внутридоменную маршрутизацию своей транзитной области для пересылки пакетов. Виртуальные соединения организуются (up) и удаляются (down) при построении дерева кратчайших путей для транзитной области. *List of external routes (список внешних маршрутов)* В этот список включаются маршруты ко внешним по отношению к AS адресатам, которые были явно получены от других протоколов маршрутизации (таких, как BGP), заданы администратором или получены иным способом (например, динамическая маршрутная информация, анонсируемая OSPF с заданным значением метрики). Все маршрутизаторы, имеющие такие внешние маршруты, называются граничными маршрутизаторами AS. Внешние маршруты анонсируются маршрутизаторами в область маршрутизации OSPF с помощью AS-external-LSA. *List of AS-external-LSAs (список AS-external-LSA)* Часть базы данных о каналах, полученная от граничных маршрутизаторов AS. Этот список содержит маршруты ко внешним по отношению к данной AS адресатам. Отметим, что для граничных маршрутизаторов AS часть записей AS-external-LSA порождена данным маршрутизатором (self-originated). *The routing table (таблица маршрутизации)* Эта таблица строится на основе базы данных о каналах (link-state database). Каждая запись в таблице маршрутизации индексируется по получателям и включает набор путей для пересылки пакетов адресатам. Для описания путей используется их тип и адрес следующего маршрутизатора (см. параграф 11). На рисунке 5 показана структура данных типичного маршрутизатора (RT10 из примера на рисунке 4). Отметим, что маршрутизатор RT10 имеет виртуальное соединение с RT11, а область 2 является для этого соединения транзитной. Это соединение показано звездочками (*) на рисунке 5. Когда виртуальное соединение активизируется при построении дерева кратчайших путей для области 2, оно становится интерфейсом в магистральную область (см. два магистральных интерфейса, отмеченных на рисунке 3).

	rfc.com.ru 16 rfc.com.ru



		Перевод RFC 2328

	7.1. Протокол Hello Протокол Hello отвечает за организацию и поддержку отношений смежности между соседними маршрутизаторами, а также обеспечивает двухстороннюю связь между соседями. Пакеты Hello периодически передаются через все интерфейсы маршрутизатора. Наличие двухсторонней связи устанавливается, когда маршрутизатор видит себя в пакете Hello от соседа. В широковещательных и NBMA-сетях протокол Hello используется также для выбора маршрутизатора DR для данной сети. Работа протокола Hello различается в широковещательных сетях, сетях NBMA и Point-to-MultiPoint. В широковещательных сетях каждый маршрутизатор анонсирует себя, периодически передавая пакеты Hello с использованием групповой адресации. Это позволяет динамически обнаруживать присутствие соседей. Такие пакеты Hello содержат представление маршрутизатора о тождественности DR и список маршрутизаторов, чьи пакеты Hello были приняты недавно. В сетях NBMA требуется некоторая настройка для обеспечения работы протокола Hello. Каждый маршрутизатор, который потенциально может быть назначен в качестве DR, имеет список всех маршрутизаторов, подключенных к сети. Маршрутизатор, имеющий возможность стать DR, передает пакеты Hello всем остальным потенциальным DR, когда его интерфейс в сеть NBMA начинает работать. Это является попыткой обнаружения маршрутизатора DR для данной сети. Если данный маршрутизатор назначен в качестве DR, он начинает передачу пакетов Hello всем остальным маршрутизаторам, подключенным к сети. В сетях Point-to-MultiPoint маршрутизатор передает пакеты Hello всем соседям, с которыми он может взаимодействовать напрямую. Поиск таких соседей может осуществляться динамически с использованием протоколов типа Inverse ARP [Ref14] или соседи могут быть заданы статически. После того, как найдены соседи, организована двухсторонняя связь и (в широковещательных и NBMA-сетях) назначен выделенный маршрутизатор DR, принимается решение о возможности и целесообразности поддержки отношений смежности с соседом (см. параграф 10.4). Если отношения смежности организованы, первым шагом является синхронизация баз данных между смежными маршрутизаторами, подробно описанная в следующем параграфе. 7.2. Синхронизация баз данных Для алгоритмов link-state большое значение имеет синхронизация баз данных о состоянии каналов во всех маршрутизаторах. Протокол OSPF упрощает ситуацию, требуя синхронизировать лишь базы данных смежных маршрутизаторов. Процесс синхронизации начинается сразу после попытки маршрутизаторов организовать отношения смежности. Каждый маршрутизатор описывает свою базу каналов, посылая соседу последовательность пакетов Database Description, каждый из которых описывает набор LSA, включенных в базу данных маршрутизатора. Когда сосед видит анонсы LSA, более новые по сравнению с имеющейся у него копией, он делает отметку о необходимости запроса новейших LSA. Процесс обмена пакетами Database Description называется обменом базами данных (Database Exchange Process). Во время обмена между маршрутизаторами организуются отношения ведущий - ведомый (master/slave). Каждый пакет Database Description имеет порядковый номер. Переданные ведущим маршрутизатором пакеты Database Description подтверждаются ведомой стороной с возвратом порядкового номера подтверждаемого пакета. Передаваемые в обоих направлениях пакеты содержат резюме данных о состоянии соединений (link state data). Ведущий маршрутизатор может повторно передавать пакеты Database Description с использованием фиксированного интервала, задаваемого для каждого интерфейса административно с помощью параметра RxmtInterval. Каждый пакет Database Description содержит флаг индикации наличия последующих пакетов - бит M. Процесс Database Exchange завершается, когда маршрутизатор принял и передал пакет Database Description с нулевым значением бита M. В процессе Database Exchange и после его завершения каждый маршрутизатор имеет список LSA, для которых сосед имеет более свежие данные. Для запроса этой информации используются пакеты Link State Request. Если запрос не выполнен пакет Link State Request передается повторно по истечении интервала RxmtInterval. После завершения процесса Database Exchange⁸ и выполнения всех запросов Link State базы данных засинхронизированы и маршрутизаторы маркируются как смежные (fully adjacent). С этого момента отношения смежности являются полными и анонсируются в router -LSA обоих маршрутизаторов. Смежность используется процедурой лавинной рассылки с самого начала процесса Database Exchange. Это упрощает синхронизацию баз данных и гарантирует ее завершение в разумные сроки. 7.3. Выделенный маршрутизатор DR В каждой широковещательной или NBMA-сети имеется выделенный маршрутизатор DR, выполняющий две основных задачи: ♦ Маршрутизатор DR генерирует анонсы network-LSA от имени сети. Эти LSA содержат список маршрутизаторов (включая DR), подключенных в данный момент к сети. Идентификатором Link State ID для таких LSA (см. параграф 12.1.4) является IP-адрес интерфейса в маршрутизаторе DR. Номер IP-сети можно найти по этому адресу, используя адресную маску. ♦ Маршрутизатор DR является смежным для всех остальных маршрутизаторов сети. Поскольку базы данных смежных маршрутизаторов синхронизируются (в процессе организации отношений смежности), маршрутизатор DR играет центральную роль в процессе синхронизации данных. Маршрутизатор DR задается с помощью протокола Hello. Пакет Hello от маршрутизатора содержит значение Router Priority, настраиваемое для каждого интерфейса. В общем случае перед тем как интерфейс маршрутизатора в сеть начнет работать, он проверяет наличие в сети маршрутизатора DR. Если такой маршрутизатор уже задан, он принимается, независимо от значения Router Priority. Такой подход осложняет прогноз тождественности DR, но избавляет от частой смены маршрутизатора DR (см. ниже). Если маршрутизатор DR еще не назначен, им становится данный маршрутизатор, если он имеет наивысшее в сети значение Router Priority. Более детальное и точное описание процедуры выбора DR приведено в параграфе 9.4. Маршрутизатор DR является конечной точкой для множества смежных пар. Для оптимизации процедуры лавинной рассылки в широковещательных сетях DR использует для передачи своих пакетов Link State Update Packets групповой адрес AllSPFRouters, вместо передачи пакетов каждому из смежных маршрутизаторов по отдельности. В главе 2 было рассмотрено представление областей в виде графа. Маршрутизаторы помечаются их идентификаторами (Router ID), для обозначения транзитных сетей используются IP-адреса их маршрутизатора DR. Из сказанного следует, что при смене маршрутизатора DR на графе это отражается как полная замена сетевого узла. При такой смене сеть и все подключенные к ней маршрутизаторы будут генерировать новые анонсы LSA. В результате может теряться связность сети, пока не будут засинхронизированы все базы данных. В результате потери связности может быть сгенерировано множество сообщений ICMP unreachable. По этим причинам замены DR-маршрутизатора не должны быть частыми. Параметр Router Priority следует устанавливать таким, чтобы наиболее надежный маршрутизатор сети в конце концов принимал на себя функции DR.

	⁸ В оригинале ошибочно указано Database Description. Прим. перев. rfc.com.ru 18	rfc.com.ru



Перевод RFC 2328

MultiPoint или NBMA, отправитель идентифицируется адресом IP в заголовке IP-пакета. Если принимающий интерфейс подключен к сети point-to-или виртуальному соединению, отправитель идентифицируется полем Router ID в заголовке пакета OSPF. Структура данных принимающего интерфейса содержит список активных соседей. Пакеты, не соответствующие любому из перечисленных выше условий, должны отбрасываться. После проверки пакет ассоциируется с передавшим его активным соседом. Дальнейшие операции по обработке принимаемых пакетов описаны ниже в отдельных параграфах (см. таблицу 14).

*9. Структура данных интерфейса* Интерфейс OSPF представляет собой соединение между маршрутизатором и сетью. Мы предполагаем один интерфейс OSPF в каждую сеть/подсеть, хотя в приложении F рассматриваются варианты с множеством интерфейсов в одну сеть. С каждой структурой данных интерфейса связан по крайней мере один адрес IP. Интерфейс OSPF можно рассматривать как часть области, к которой относится соединенная с интерфейсом сеть. Все пакеты протокол маршрутизации, передаваемые маршрутизатором через интерфейс, помечаются идентификатором Area ID соответствующей области. Через один интерфейс может быть организовано несколько отношений смежности. Записи LSA в маршрутизаторе отражают состояние его интерфейсов и отношения смежности. Ниже приведен список данных, связанных с каждым интерфейсом. Отметим, что многие параметры задают конфигурацию подключенной к интерфейсу сети и должны быть одинаковы для всех подключенных к этой сети маршрутизаторов. *Type* Интерфейсы OSPF могут быть нескольких типов - point-to-point, broadcast, NBMA, Point-to-MultiPoint или virtual link. *State* Функциональное состояние интерфейса, определяющее возможность организации отношений смежности через данный интерфейс. Состояние интерфейса отражается также в LSA маршрутизатора. *IP interface address* IP-адрес, связанный с интерфейсом. Этот адрес появляется в качестве адреса отправителя для пакетов, исходящих от данного интерфейса. Интерфейсы в безадресные сети point-to-point не имеют своего IP-адреса. *IP interface mask* Маска сети/подсети, определяющую часть IP-адреса интерфейса, обозначающую номер сети. Маскирование IP-адресов позволяет определять IP-номер подключенной к интерфейсу сети. В сетях point-to-point и виртуальных каналах маска для интерфейса не задается, поскольку в таких сетях соединение не имеет связанного с ним адреса IP, а адреса для разных сторон соединения задаются независимо или не используются совсем. *Area ID* Идентификатор области, в которую входит подключенная к интерфейсу сеть. Все пакеты протокола маршрутизации, отправляемые с данного интерфейса, помечаются значением ID. *HelloInterval* Промежуток времени (в секундах) между передачей интерфейсом двух последовательных пакетов Hello. Это значение анонсируется в передаваемых интерфейсом пакетах Hello. *RouterDeadInterval* Время (в секундах), по истечении которого соседний маршрутизатор признается неработающим. Время исчисляется от момента приема последнего пакета Hello от соседнего маршрутизатора. Значение этого параметра анонсируется в пакетах Hello. *I nfTransDelay* Оценка времени (в секундах), затрачиваемого на передачу пакета Link State Update Packet через данный интерфейс. Анонсы LSA, содержащиеся в пакете Link State Update будут увеличивать свой возраст на величину этого параметра до передачи пакета в интерфейс. Это значение должно учитывать задержки на прохождение и передачу сигнала. Параметр должен иметь положительное значение. *Router Priority* 8-битовое беззнаковое целое, определяющее приоритет маршрутизатора. Когда два подключенных к сети маршрутизатора пытаются занять место DR, выбирается маршрутизатор с большим значением Router Priority. Для маршрутизаторов, которые не должны играть роль DR устанавливается Router Priority = 0. Значение этого параметра анонсируется в пакетах Hello. *Hello Timer* Интервальный таймер, используемый для передачи пакетов Hello. Этот таймер запускается каждые HelloInterval секунд. Отметим, что в сетях без широковещания пакеты Hello передаются по отдельности каждому соседу. *Wait Timer* Однократный таймер, вынуждающий интерфейс выходить из состояния Waiting (ожидание) и, как следствие, выбирать маршрутизатор DR в сети. Время отсчета этого таймера составляет RouterDeadInterval. *List of neighboring routers* Список всех прочих маршрутизаторов, подключенных к данной сети, который формируется протоколом Hello. С некоторыми из соседних er или DR) для подключенной к интерфейсу сети. Маршрутизаторы DR выбираются в широковещательных и NBMA-сетях протоколом Hello. Для маршрутизатора DR сохраняются два параметра -Router ID и IP-адрес интерфейса в данную сеть. Маршрутизатор DR анонсирует состояние канала для сети; анонс network-LSA помечается IP-адресом маршрутизатора DR. При инициализации поле Designated Router принимает значение 0.0.0.0, говорящее об отсутствии в сети маршрутизатора DR. *Backup Designated Router* Маршрутизатор Backup DR также назначается для всех широковещательных и NBMA-сетей с помощью протокола Hello. Все маршрутизаторы сети являются смежными как с DR, так и с Backup DR. Маршрутизатор Backup Designated Router переходит в состояние DR, если текущий маршрутизатор DR «падает». При инициализации Backup DR принимает значение 0.0.0.0, говорящее об отсутствии в сети маршрутизатора Backup DR. *Interface output cost(s)* Стоимость передачи пакета данных через интерфейс, выраженная в единицах метрики link state. Это значение анонсируется как стоимость для данного интерфейса в пакетах router-LSA. Стоимость должна иметь положительное значение. *RxmtInterval* Период (в секундах) повтора передачи LSA для смежных узлов данного интерфейса. Этот же период используется для повтора передачи пакетов Database Description и Link State Request. *AuType*

rfc.com.ru	21	rfc.com.ru



	Перевод RFC 2328 Это событие связано с изменениями набора +----+ Unlooplnd +--------+ соседей данного интерфейса, с которыми \|Down\|<-------------\|Loopback\| осуществляется двухсторонняя связь. В +---+ +-------+ результате требуется перерасчет \| выделенного маршрутизатора (Backup) DR. \|InterfaceUp Событие NeighborChange может быть +-------+ \| +-------------+ вызвано одной из перечисленных ниже \|Waiting\|<-+-------------->\|Point-to-point \| причин (описания состояний соседей +-------+ +-------------+ приведены в параграфе 10.1): \| ♦ Организована двухсторонняя связь с WaitTimer IBackupSeen соседом (состояние соседа перешло на \| уровень 2-Way или выше). \| ♦ Прервана двухсторонняя связь с I NeighborChange соседом (состояние соседа перешло на +------+ +-+<----------------+-------+ уровень Init или ниже). \|Backup\|<----------\|?\|----------------->\|DROther\| ♦ Один из соседей с двухсторонней +------+---------->+-+<-----+ +-------+ связью недавно обозначил себя в Neighbor \| \| качестве DR или Backup DR Change \| \|Neighbor (определяется из пакетов Hello от I \|Change этого соседа). I +~+ ♦ Один из соседей с двухсторонней +---->IDR\| связью перестал играть роль DR или + + Backup DR (определяется из пакетов Рисунок 7. Смена состояний интерфейса Hello от этого соседа). В дополнение к показанным на графе переходам событие InterfaceDown всегда ♦ Изменилось анонсируемое значение приводит к состоянию Down,а LoopInd – к состоянию Loopback. Router Priority для соседа с двунаправленной связью (определяется из пакетов Hello от этого соседа). *LoopInd* Принята индикация перевода интерфейса в состояние loopback (эта информация может быть получена от программ сетевого управления или протоколов нижележащих уровней). *UnloopInd* Принята индикация выхода интерфейса из состояния loopback. Как и для события LoopInd, эта информация может быть получена от программ сетевого управления или протоколов нижележащих уровней. *InterfaceDown* Протокол нижележащего уровня сообщил об утрате интерфейсом работоспособности. Независимо от текущего состояния интерфейса он должен быть переведен в состояние Down. 9.3. Машина состояний интерфейса Ниже приводится детальное описание изменений в состояниях интерфейсов. Каждое такое изменение вызывается событиями, перечисленными в параграфе 9.2. Результат событий зависит от текущего состояния интерфейса, поэтому приведенные ниже описания используют в качестве отправной точки текущее состояние интерфейса. Каждая запись в машине состояний интерфейса описывает переход в новое состояние и требуемые действия. При изменении состояния интерфейса может потребоваться генерация нового анонса router-LSA (см. параграф 12.4). Некоторые из перечисленных ниже действий включают генерацию событий для машины состояний соседа. Например, при прекращении работы интерфейса должны быть уничтожены все записи о соседстве этого интерфейса. Дополнительная информация о машине состояний соседа приведена в параграфе 10.3. *Состояние:* Down *Событие:* InterfaceUp *Новое состояние:* В зависимости от предпринятых действий *Действия:* Начало нового отсчета таймера Hello, задающего периодическую рассылку пакетов Hello данным интерфейсом. Если интерфейс подключен к физической сети point-to-point, сети Point-to-MultiPoint или виртуальному соединению, он переводится в состояние Point-to-Point. Для широковещательных сетей и сетей NBMA интерфейс переводится в состояние DR Other, если для маршрутизатора нежелательна работа в качестве DR. Если же маршрутизатор может играть роль DR для подключенной сети, интерфейс переводится в состояние Waiting и запускается таймер Wait Timer. Кроме того, в сетях NBMA проверяется список соседей интерфейса и генерируется событие Start для каждого из соседей, который тоже может стать DR. *Состояние:* Waiting *Событие:* BackupSeen *Новое состояние:* В зависимости от предпринятых действий. *Действия:* Определяются маршрутизаторы Backup DR и DR (см. параграф 9.4). В результате завершения расчетов интерфейс будет переведен в состояние DR Other, Backup или DR.__________________________________________________________________ *Состояние:* Waiting *Событие:* WaitTimer *Новое состояние:* В зависимости от предпринятых действий. *Действия:* Определяются маршрутизаторы Backup DR и DR (см. параграф 9.4). В результате завершения расчетов интерфейс будет переведен в состояние DR Other, Backup или DR.__________________________________________________________________ *Состояние:* DR Other, Backup или DR *Событие:* NeighborChange *Новое состояние:* В зависимости от предпринятых действий. *Действия:* Заново определяются маршрутизаторы Backup DR и DR (см. параграф 9.4). В результате завершения расчетов интерфейс будет переведен в состояние DR Other, Backup или DR.________________________________________________________ *Состояние:* Любое *Событие:* InterfaceDown *Новое состояние:* Down *Действия:* Сбрасываются все связанные с интерфейсом переменные, отключаются таймеры интерфейса и удаляются все отношения соседства (путем генерации события KillNbr для всех соседей - см. параграф 10.2).________________________________ *Состояние:* Любое *Событие:* LoopInd rfc.com.ru 23 rfc.com.ru



		Перевод RFC 2328
		Перевод RFC 2328
	*Новое состояние:* Loopback *Действия:* Поскольку интерфейс в таком состоянии больше не связан с подключенной сетью, выполняются операции, связанные с описанным выше событием InterfaceDown. *Состояние:* Loopback *Событие:* UnloopInd *Новое состояние:* Down *Действия:* Не требуется выполнения каких-либо действий (например, все связанные с интерфейсом переменные уже были сброшены при переходе в состояние Loopback). Отметим, что для перехода интерфейса в рабочее состояние он должен получить сигнал InterfaceUp. 9.4. Назначение DR В этом параграфе описан механизм назначения выделенных маршрутизаторов DR и Backup DR, используемых машиной состояний Interface. Сначала маршрутизатор запускает механизм выбора выделенного маршрутизатора для сети. Значения DR и Backup DR равны 0.0.0.0 – это говорит об отсутствии в сети как DR, так и Backup DR. Рассмотрим механизм назначения DR более подробно, обозначив маршрутизатор, делающий расчет, как Router X. Проверяется список соседей, подключенных к сети и организовавших двухстороннюю связь с Router X. Этот список в точности совпадает с набором соседей Router X (в той же сети), чьи состояния не ниже 2-Way (см. параграф 10.1). Маршрутизатор Router X также присутствует в этом списке. Сначала из списка исключаются все маршрутизаторы, которые нежелательно использовать в качестве DR (маршрутизаторы с Router Priority = 0 не могут быть DR). После этого для оставшихся в списке маршрутизаторов выполняются следующие операции: (1) Фиксируются текущие значения для DR и Backup DR, которые будут потом использоваться для сравнения. (2) Определяется новый маршрутизатор Backup DR с учетом только тех маршрутизаторов, которые не заявили о своем нежелании выступать в качестве Backup DR. Если на роль Backup DR претендует (т. е., указали себя в качестве Backup DR, но не DR в своих пакетах Hello) один или несколько маршрутизаторов, среди них выбирается тот, для которого задан высший приоритет Router Priority. Если высший приоритет заявлен для нескольких маршрутизаторов, выбирается тот, у которого больше значение Router ID. Если ни один маршрутизатор не заявлен как Backup DR, выбирается маршрутизатор с наибольшим Router Priority среди тех маршрутизаторов, которые не заявили себя в качестве DR (если таких маршрутизаторов окажется несколько, снова используется Router ID). (3) Определяется новый маршрутизатор DR для сети. Если на роль DR претендует (т. е., указали себя в качестве DR в своих пакетах Hello) один или несколько маршрутизаторов, среди них выбирается тот, для которого задан высший приоритет Router Priority. Если высший приоритет заявлен для нескольких маршрутизаторов, выбирается тот, у которого больше значение Router ID. Если ни один маршрутизатор не заявлен как DR, в качестве выделенного маршрутизатора выбирается назначенный в последний раз Backup DR. (4) Если маршрутизатор Router X стал (Backup) DR или наоборот, утратил это значение, повторяются п.п. 2 и 3, а затем выполняется пункт 5. Пусть Router X играет роль DR, тогда при повторении п. 2 для X уже невозможно назначение на роль Backup DR. Наряду с другими мерами это предотвращает захват функций DR и Backup DR одним маршрутизатором¹². (5) В результате проведения расчетов маршрутизатор сам может занять место DR или Backup DR (см. параграфы 7.3 и 7.4, содержащие детальное описание). Состояние интерфейса маршрутизатора соответствующим образом изменяется. Если маршрутизатор занял место DR, интерфейс перейдет в состояние DR. Интерфейс маршрутизатора, ставшего Backup DR, перейдет в состояние Backup. В остальных случаях интерфейс переходит в состояние DR Other. (6) Если подключенная сеть относится к типу NBMA, а маршрутизатор является DR или Backup DR, он должен начать передачу пакетов Hello тем из соседей, которые не могут стать DR (см. параграф 9.5.1). Это осуществляется созданием события Start для каждого из соседей с Router Priority = 0. (7) Если описанные расчеты привели к смене DR или Backup DR, требуется обновить набор отношений смежности, связанных с данным интерфейсом – для этого может потребоваться организация новых отношений смежности или удаление существовавших ранее. Для обновления отношений смежности вводится событие AdjOK? для всех соседей, состояние которых не ниже 2-Way. Это событие приводит к пересмотру отношений смежности (см. параграфы 10.3 и 10.4). Усложнение механизма назначения выделенного маршрутизатора обусловлено желанием обеспечить упорядоченный переход от Backup DR к DR при сбоях в работе текущего маршрутизатора DR. Упорядоченность перехода обеспечивается за счет введения гистерезиса (запаздывания, прим. перев.) – новый маршрутизатор Backup DR не может быть назначен, пока прежний маршрутизатор не примет на себя функции DR. Описанная выше процедура может привести к выбору одного маршрутизатора в качестве DR и Backup DR, хотя этого никогда не может случиться с маршрутизатором, проводящим вычислений для выбора маршрутизатора (в нашем примере Router X). Выбранный маршрутизатор DR не обязательно имеет наибольшее значение Router Priority, а Backup DR не обязан иметь второе по порядку значение Router Priority. Если Router X не может стать DR, возможно, что приведенные выше процедуры не позволят назначить ни Backup DR, ни DR. Отметим также, что в тех случаях, когда Router X является единственным маршрутизатором, способным стать DR, он может назначить себя на роль DR, а маршрутизатор Backup DR просто не будет выбран для сети. 9.5. Передача пакетов Hello Пакеты Hello передает каждый работающий интерфейс маршрутизатора. Эти пакеты служат для организации и поддержки соседских отношений¹³. В широковещательных и NBMA-сетях пакеты Hello используются также при выборе DR и Backup DR. Формат пакетов Hello рассмотрен в параграфе A.3.2. Пакеты Hello содержат значения Router Priority (для выбора DR) и HelloInterval (интервала между пакетами Hello передаваемыми интерфейсом). Пакет Hello также показывает, как часто должно быть слышно соседа для осознания его работоспособности (RouterDeadInterval). Значения HelloInterval и RouterDeadInterval должны быть одинаковы для всех маршрутизаторов, подключенных к одной сети. Пакеты Hello также содержат маску IP для подключенной сети (Network Mask); для безадресных сетей point-to-point и виртуальных каналов это поле должно иметь значение 0.0.0.0.

	¹² Будет поучительно рассмотреть ситуацию, когда маршрутизатор DR перестает работать. Пусть функции DR выполняет маршрутизатор RT1, а Backup DR - RT2. Если RT1 «падает» (или прекращает работать интерфейс в данную сеть), другие маршрутизаторы смогут обнаружить отсутствие RT1 в течение RouterDeadInterval. Все маршрутизаторы не смогут обнаружить отсутствие выделенного маршрутизатора одновременно. В результате маршрутизатор, обнаруживший отсутствие RT1 до того, как это удалось сделать RT2 на некоторое время выберет RT2 в качестве DR и Backup DR одновременно. Когда RT2 обнаружит отсутствие RT1, он объявит себя DR. Одновременно с этим произойдет назначение маршрутизатора с высшим значением Router Priority на роль Backup DR. ¹³ В сетях point-to-point наличие и работоспособность соседа проверяется протоколами нижних уровней с соответствующей индикацией. Для виртуальных каналов существование соседей определяется при расчете таблицы маршрутизации. Однако в том и другом случае по-прежнему используется протокол Hello. Это обеспечивает между соседями двухстороннюю связь и дает гарантию работоспособности протокола маршрутизации на соседнем маршрутизаторе. rfc.com.ru 24 rfc.com.ru



		+---+ \|RT2\| +---+ Down		10.10. Пример	Перевод RFC 2328
+---+ \|RT1\| +---+ Down	Hello(DR=0,seen=0)

				На рисунке 10 показан пример организации смежности. Маршрутизаторы RT1 и RT2 подключены к широковещательной сети. Предполагается, что RT2 играет роль DR и его значение Router ID больше, нежели Router ID для RT1. Изменения состояния соседа отлеживаются каждым и показаны по краям рисунка. На начальном этапе примера маршрутизатор RT1 только начинает работу в сети. Маршрутизатор начинает передавать пакеты Hello, хотя он еще не знает о DR и других
ExStart	Hello (DR=RT2,seen=RT1,...) --------------------------- D-D (Seq=x,I,M,Master) --------------------------- D-D (Seq=y,I,M,Master) --------------------------- D-D (Seq=y,M,Slave) --------------------------- D-D (Seq=y+1,M,Master) --------------------------- D-D (Seq=y+1,M,Slave)	Init
		ExStart
Exchange
		Exchange
				соседних маршрутизаторах. RT2 слышит эти пакеты (и вводит состояние Init для соседа) и
		в своем следующем пакете Hello указывает себя как DR и показывает прием пакетов
		Hello от RT1. Это заставляет RT1 перейти в состояние ExStart, начиная формирование смежности.

D-D (Seq=y+n, Master)			RT1 начинает заявлять себя как ведущий
			маршрутизатор. Когда RT1 видит, что RT2
	D-D (Seq=y+n, Slave)		должен быть ведущим (большее значение
L			Router ID), он переходит в режим ведомого и
	LS Request	Full		адаптирует свой порядковый номер DD для
			соседа. Происходит обмен пакетами DD с запросами от ведущего (RT2) и откликами от ведомого (RT1) маршрутизатора. Эта последовательность пакетов DD завершается когда обе стороны сбрасывают флаг M. В приведенном примере предполагается, что
LS Update
LS Request
LS Update

Full	Рисунок 10. Пример организации отношений смежности.			база данных RT2 полностью актуальна. В этом случае RT2 незамедлительно переходит
				в состояние Full. RT1 будет переходить в
состояние Full после обновления нужных частей своей базы данных. Это осуществляется путем передачи пакетов LSR и приема откликов LSU. Отметим, что ожидание маршрутизатором RT1 завершения приема всего набора пакетов DD от RT2 до передачи пакетов LSR не является обязательным. RT1 может чередовать передачу пакетов LSR и прием пакетов DD.

*11. Структура таблицы маршрутов*
Таблица маршрутов содержит все данные, требуемые для пересылки пакетов IP в направлении адресата. Каждая запись таблицы описывает набор лучших маршрутов к отдельному получателю. При пересылке пакетов данных IP определяется запись таблицы с максимальным соответствием IP-адресу получателя пакета. После этого из выбранной записи берется адрес следующего маршрутизатора (next hop) в направлении адресата. Протокол OSPF также обеспечивает поддержку принятого по умолчанию маршрута (Destination ID = DefaultDestination, Address Mask = 0x00000000). Если существует принятый по умолчанию маршрут, он соответствует всем IP-адресам получателей (хотя любые другие маршруты обеспечивают лучшее соответствие). Поиск маршрута с лучшим соответствием IP-адресу получателя описан в параграфе 11.1. В каждом маршрутизаторе существует одна таблица маршрутов. Два примера таблиц маршрутизации рассмотрены в параграфах 11.2 и 11.3. Построение таблицы маршрутов описано в главе 16. В остальной части параграфа описаны поля записей в таблице маршрутов. Первый набор полей описывает адресатов для записи. *Destination Type* Адресатом может быть сеть (network) или маршрутизатор (router). При пересылке пакетов данных IP реально используются только записи для сетей. Связанные с маршрутизаторами записи таблицы применяются только на промежуточных этапах построения таблицы маршрутов. Сеть представляет собой диапазон адресов IP, по которым могут пересылаться пакеты данных. Сюда включаются сети классов A, B и C, подсети IP, сверхсети IP и отдельные хосты IP. Принятый по умолчанию маршрут также входит с эту категорию. Записи, связанные с маршрутизаторами, сохраняются для граничных маршрутизаторов областей и AS. Записи в таблице маршрутов для граничных маршрутизаторов областей используются при расчете междоменных маршрутов (см. параграф 16.2) и для поддержки виртуальных соединений (см. главу 15), а записи для граничных маршрутизаторов AS служат для расчета внешних по отношению к AS маршрутов (см. параграф 16.4). *Destination ID* Имя или идентификатор адресата в зависимости от значения Destination Type. Для сетей используется связанный с сетью IP-адрес, для маршрутизаторов - OSPF Router ID¹⁶. *Address Mask* Маска определена только для сетей и при использовании вместе с адресом IP позволяет определить сетевой диапазон IP-адресов. Для подсетей IP адресную маску называют маской подсети. Маршруты к хостам имеют маску 0xffffffff. *Optional Capabilities* Когда получателем является маршрутизатор, это поле показывает поддерживаемые им дополнительные возможности OSPF. В данной спецификации определена единственная дополнительная возможность – обработка AS-external-LSA. Обсуждение дополнительных возможностей OSPF приведено в параграфе 4.5.

¹⁶ Пространство адресов IP-сетей и значений OSPF Router ID могут перекрываться, т. е., IP-адрес сети в 32-битовом представлении может совпадать с Router ID какого-либо из маршрутизаторов. rfc.com.ru 32 rfc.com.ru



		Перевод RFC 2328
		Перевод RFC 2328
	*12.1.6. Порядковый номер LS* Порядковый номер трактуется как 32-разрядное целое число со знаком и используется для обнаружения старых LSA и дубликатов. Пространство порядковых номеров линейно упорядочено и больший порядковый номер (при сравнении 32-битовых целых чисел со знаком) соответствует более новой записи LSA. Далее при описании порядковых номеров N будет обозначать 2³¹. Порядковый номер -N (0x80000000) зарезервирован и не должен использоваться. Значение -N + 1 (0x80000001) является минимальным (следовательно, самым старым) порядковым номером и используется в качестве константы InitialSequenceNumber. Маршрутизатор использует номер InitialSequenceNumber при первой генерации LSA. После этого порядковые номера LSA увеличиваются на 1 при генерации каждого нового экземпляра LSA. При достижении порядкового номера N – 1 (0x7fffffff или MaxSequenceNumber), сначала нужно удалить текущий экземпляр LSA из домена маршрутизации. Для этого используется принудительное старение (prematurely aging) LSA (см. параграф 14.1) и повторная лавинная рассылка. После подтверждения этой рассылки всеми смежными маршрутизаторами возможна генерация новой записи с порядковым номером InitialSequenceNumber. Для маршрутизатора может потребоваться форсирование анонса порядкового номера одной из его LSA при неожиданном приеме более нового экземпляра LSA в процессе лавинной рассылки. Это происходит редко и может говорить о наличии устаревших LSA, сгенерированных самим маршрутизатором при его последней загрузке, которые еще сохраняются в AS (см. параграф 13.4). *12.1.7. Контрольная сумма LS* Это поле включает контрольную сумму записи LSA без учета поля LS age для того, чтобы можно было увеличивать поле возраста без пересчета контрольной суммы. При расчете контрольных сумм используется тот же алгоритм, который применяется для дейтаграмм ISO без организации соединений – его часто называют алгоритмом Флэтчера. Этот алгоритм описан в работе [Ref6] (Annex B). Заголовок LSA содержит также размер LSA в байтах без учета поля LS age (два байта) для вычисления контрольной суммы. Контрольная сумма служит для детектирования повреждений LSA, которые могут происходить при лавинной рассылке или хранении в памяти маршрутизатора. Поле контрольной суммы не может быть нулевым, значение 0 должно рассматриваться как ошибка. Иными словами, вычисление контрольной суммы является обязательным. Контрольная сумма LSA проверяется в двух случаях: a) при получении пакета Link State Update и b) во время «состаривания» базы данных. Обнаружение ошибок в контрольной сумме ведет к различным ситуациям, описанным в главах 13 и 14. Когда поля порядковых номеров двух записей LSA совпадают, сравниваются контрольные суммы. Если суммы различаются, более новым считается экземпляр с большим значением контрольной суммы²⁰ (см. параграф 13.1). 12.2. База данных link-state Маршрутизатор имеет отдельную базу данных о каналах для каждой области, к которой он относится и все маршрутизаторы одной области имеют идентичные базы данных. Базы данных каждой области всегда обрабатываются раздельно. Расчет кратчайших путей выполняется отдельно для каждой области (см. главу 16). Лавинная рассылка компонент базы данных области ведется только в пределах области. И, наконец, при организации отношений смежности между двумя маршрутизаторами синхронизируются только базы данных общей области. База данных области состоит из router-LSA, network-LSA и summary-LSA (все они перечислены в структуре данных области). Для нетупиковых областей в базу данных включаются также AS-external-LSA (см. параграф 3.6). Реализация протокола OSPF должна обеспечивать возможность доступа к отдельным частям базы данных области. Эта функция просмотра основана на полях LS type, Link State ID и Advertising Router²¹. Поиск будет давать один экземпляр (самый новый) каждой записи LSA в базе данных. Функции поиска в базе данных используются процедурой лавинной рассылки LSA (глава 13) и при расчете таблицы маршрутов (глава 16). Кроме того, используя эту функцию, маршрутизатор может определить не он ли породил данную запись LSA и (если он) с каким порядковым номером. Запись LSA добавляется в базу данных маршрутизатора, если a) она получена в процессе лавинной рассылки (глава 13) или b) происходит о данного маршрутизатора (параграф 12.4). LSA удаляются из базы данных маршрутизатора, если a) получен более новый экземпляр в процессе лавинной рассылки (глава 13), b) маршрутизатор сам генерирует новый экземпляр LSA (параграф 12.4) или c) LSA удаляется из домена маршрутизации в результате старения (глава 14). При удалении LSA из базы данных, эта запись должна удаляться также из списков Link state retransmission всех соседей (см. главу 10). 12.3. Представление TOSесли a) получен более новый экземпляр в процессе лавинной рассылки (глава 13), b) маршрутизатор сам генерирует новый экземпляр LSA (параграф 12.4) или c) LSA удаляется из домена маршрутизации в результате старения (глава 14). При удалении LSA из базы данных, эта запись должна удаляться также из списков Link state retransmission всех соседей (см. главу 10). 12.3. Представление TOS Для обратной совместимости с предыдущими версиями OSPF [Ref9], в router-LSA, summary-LSA и AS-external-LSA может включаться информация, связанная с TOS. Представление TOS в OSPF LSA описано в таблице 20, содержащей коды OSPF для представления полей TOS (определены в работе [Ref12]) пакетов IP. В OSPF используется десятичное представление, а в заголовках IP применяются битовые поля TOS, описанные в [Ref12].

	²⁰ Когда контрольные суммы двух LSA различаются, предполагается, что это два разных экземпляра. Это может быть следствием перезагрузки маршрутизатора или потери маршрутизатором данных о предыдущем порядковом номере LSA. Если порядковые номера двух LSA совпадают, невозможно определить, которая из записей новее. Однако если в качестве новой будет принята некорректная запись LSA, генерирующий их маршрутизатор просто будет порождать другой экземпляр (см. параграф 13.4). ²¹ Существует ситуация, когда поиск должен основываться на частичной информации. Это происходит при расчете таблицы маршрутов, когда нужно найти network-LSA, основываясь исключительно на Link State ID. Результаты поиска однозначны, поскольку не существует двух two network-LSA с одинаковыми полями Link State ID. rfc.com.ru 36 rfc.com.ru