Please enter banners and links.
Network Working Group J. Moy
Request for Comments: 2328 Ascend Communications, Inc.
STD: 54 April 1998
Obsoletes: 2178
Category: Standards Track
Протокол 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.
Оглавление
Исключено из версии HTML
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. Эти базы называют базами данных о состоянии каналов1 (link-state database). Базы данных всех маршрутизаторов идентичны. Каждый элемент базы данных представляет собой локальное состояние отдельного маршрутизатора (например, поддерживаемые интерфейсы или доступные соседи). Маршрутизаторы распространяют информацию о своем локальном состоянии путем лавинной рассылки пакетов (flooding).
Все маршрутизаторы работают в параллель, используя одинаковый алгоритм. На основе базы каналов каждый маршрутизатор строит дерево кратчайших путей, корнем которого является сам маршрутизатор. Это дерево содержит маршруты ко всем адресатам внутри AS. Маршрутная информация внешнего происхождения представляется как листья дерева.
При наличии нескольких равноценных путей к одному адресату, трафик поровну распределяется между всеми маршрутами. Стоимость маршрута описывается безразмерной метрикой, представляемой в виде одного числа.
OSPF позволяет группировать сети – такие группы называют областями (area). Топология области невидима для остальной части AS. Такое сокрытие (избыточной) информации позволяет существенно снизить уровень служебного трафика. Кроме того, маршрутизация внутри области определяется исключительно внутренней топологией этой области, что обеспечивает защиту областей от использования некорректной маршрутной информации. Понятие области является обобщением подсетей IP.
OSPF обеспечивает возможность гибкой настройки подсетей IP. Каждый маршрут в OSPF распространяется с указанием адресата и маски подсети. Две разных подсети одной сети IP могут иметь различные размеры (т. е., разные маски) – для обозначения этого обычно используется термин variable length subnetting (переменный размер подсетей). Пакеты маршрутизируются по пути с наилучшим (т. е., самым длинным или более конкретным) соответствием. Маршруты к хостам рассматриваются как пути в подсети с маской из одних единиц (all ones или 0xffffffff 2).
Весь обмен информацией 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-broadcastmulti-access – множественный доступ без широковещания) и имитирует работу OSPF в широковещательных сетях. Второй режим называется Point-to-MultiPoint (один со многими) – в этом случае сеть без широковещания трактуется как множество соединений «точка-точка»3. Сети без широковещания мы будем делить на сети NBMA и Point-to-MultiPoint в зависимости от режима работы OSPF.
Interface (интерфейс)
Соединение между маршрутизатором и одной из подключенных к нему сетей. С интерфейсом связана информация о его состоянии, получаемая от протоколов нижележащих уровней и самого протокола маршрутизации. Сетевой интерфейс имеет адрес 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 и расчеты маршрутов, выполняемые для заполнения таблиц маршрутизации.
2.1. Представление маршрутизаторов и сетей
База каналов AS описывается направленным графом. Вершины графов показывают маршрутизаторы и сети. Ребро графа соединяет два маршрутизатора, если между ними существует физическая сеть point-to-point. Ребро, соединяющее маршрутизатор с сетью, говорит о том, маршрутизатор имеет интерфейс в данную сеть. Сеть может быть транзитной или оконечной (stub). Транзитные сети могут также передавать трафик, который не связан с данной сетью, т. е., отправитель и получатель принадлежат другим сетям. Транзитные сети представляются вершинами графов, имеющими входящее и исходящее ребро. Вершины графов для оконечных сетей имеют только входящее ребро.
Соседство каждого сетевого узла на графе зависит от типа сети (point-to-point, широковещательная, NBMA или Point-to-MultiPoint) и числа маршрутизаторов, имеющих интерфейс в данную сеть. На рисунке 1a показано три варианта. Прямоугольники представляют маршрутизаторы, круги и эллипсы – сети. В обозначениях маршрутизаторов используется префикс RT, для сетей – префикс N. Интерфейсы маршрутизаторов именуются с префиксом I. Линии между маршрутизаторами показывают сети point-to-point. В левой части рисунка показаны сети с подключенными к ним маршрутизаторами, а справа приведено представление в виде графов.
** От **
* |RT1|RT2|
+---+Ia +---+ * ------------
|RT1|------|RT2| T RT1| | X |
+---+ Ib+---+ O RT2| X | |
* Ia| | X |
* Ib| X | |
Физические сети "точка-точка"
** От **
+---+ *
|RT7| * |RT7| N3|
+---+ T ------------
| O RT7| | |
+----------------------+ * N3| X | |
N3 *
Оконечные сети
** От **
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|N2 |
+---+ +---+ * ------------------------
| N2 | * RT3| | | | | X |
+----------------------+ T RT4| | | | | X |
| | O RT5| | | | | X |
+---+ +---+ * RT6| | | | | X |
|RT5| |RT6| * N2| X | X | X | X | |
+---+ +---+
Рисунок 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.
В режиме 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, несмотря на отсутствие широковещания.
** От **
+---+ +---+
|RT3| |RT4| |RT3|RT4|RT5|RT6|
+---+ +---+ * --------------------
I3| N2 |I4 * RT3| | X | X | X |
+----------------------+ T RT4| X | | | X |
I5| |I6 O RT5| X | | | X |
+---+ +---+ * RT6| X | X | X | |
|RT5| |RT6| * I3| X | | | |
+---+ +---+ I4| | X | | |
I5| | | X | |
I6| | | | X |
Рисунок 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.
+
| 3+---+ N12 N14
N1|--|RT1|\ 1 \ N13 /
| +---+ \ 8\ |8/8
+ \ ____ \|/
/ \ 1+---+8 8+---+6
* N3 *---|RT4|------|RT5|--------+
\____/ +---+ +---+ |
+ / | |7 |
| 3+---+ / | | |
N2|--|RT2|/1 |1 |6 |
| +---+ +---+8 6+---+ |
+ |RT3|--------------|RT6| |
+---+ +---+ |
|2 Ia|7 |
| | |
+---------+ | |
N4 | |
| |
| |
N11 | |
+---------+ | |
| | | N12
|3 | |6 2/
+---+ | +---+/
|RT9| | |RT7|---N15
+---+ | +---+ 9
|1 + | |1
_|__ | Ib|5 __|_
/ \ 1+----+2 | 3+----+1 / \
* N9 *------|RT11|----|---|RT10|---* N6 *
\____/ +----+ | +----+ \____/
| | |
|1 + |1
+--+ 10+----+ N8 +---+
|H1|-----|RT12| |RT8|
+--+SLIP +----+ +---+
|2 |4
| |
+---------+ +--------+
N10 N7
Рисунок 2. Пример автономной системы
Таблица 1 Графическое представление базы данных.
** От узла **
|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |6 |7 |8 |9 |10|11|12|N3|N6|N8|N9|
----- ---------------------------------------------
RT1| | | | | | | | | | | | |0 | | | |
RT2| | | | | | | | | | | | |0 | | | |
RT3| | | | | |6 | | | | | | |0 | | | |
RT4| | | | |8 | | | | | | | |0 | | | |
RT5| | | |8 | |6 |6 | | | | | | | | | |
RT6| | |8 | |7 | | | | |5 | | | | | | |
RT7| | | | |6 | | | | | | | | |0 | | |
* RT8| | | | | | | | | | | | | |0 | | |
* RT9| | | | | | | | | | | | | | | |0 |
К RT10| | | | | |7 | | | | | | | |0 |0 | |
RT11| | | | | | | | | | | | | | |0 |0 |
у RT12| | | | | | | | | | | | | | | |0 |
з N1|3 | | | | | | | | | | | | | | | |
л N2| |3 | | | | | | | | | | | | | | |
у N3|1 |1 |1 |1 | | | | | | | | | | | | |
* N4| | |2 | | | | | | | | | | | | | |
* N6| | | | | | |1 |1 | |1 | | | | | | |
N7| | | | | | | |4 | | | | | | | | |
N8| | | | | | | | | |3 |2 | | | | | |
N9| | | | | | | | |1 | |1 |1 | | | | |
N10| | | | | | | | | | | |2 | | | | |
N11| | | | | | | | |3 | | | | | | | |
N12| | | | |8 | |2 | | | | | | | | | |
N13| | | | |8 | | | | | | | | | | | |
N14| | | | |8 | | | | | | | | | | | |
N15| | | | | | |9 | | | | | | | | | |
H1| | | | | | | | | | | |10| | | | |
Сети и маршрутизаторы представлены вершинами. Ребро стоимостью X соединяет вершину A с вершиной B, если на пересечении колонки A и строки B показан знак X.
Таблица 2 Отдельные компоненты базы данных.
** От ** ** От ** |RT12|N9|N10|H1| |RT9|RT11|RT12|N9| * -------------------- * ---------------------- * RT12| | | | | * RT9| | | |0 | К N9|1 | | | | К RT11| | | |0 | * N10|2 | | | | * RT12| | | |0 | * H1|10 | | | | * N9| | | | | router-LSA для RT12 router-LSA для N9
2.2. Дерево кратчайших путей
При отсутствии областей OSPF все маршрутизаторы в AS имеют идентичные базы данных о состоянии каналов; графическое представление этих баз также будет идентичным. Маршрутизатор генерирует свою таблицу маршрутов из графа базы данных, рассчитывая дерево кратчайших путей, корнем которого является сам маршрутизатор. Обычно дерево зависит от маршрутизатора, для которого оно рассчитано. Дерево для маршрутизатора RT6 из приведенного примера показано на рисунке 3.
Дерево включает путь к любой сети или хосту. Однако при пересылке пакетов адресату используется только следующий маршрутизатор (next hop). Отметим также, что рассчитывается лучший путь к каждому маршрутизатору. Для обработки внешних данных отметим next hop и дистанцию для всех маршрутизаторов, анонсирующих внешние маршруты. Полученная в результате таблица маршрутизации для RT6 показана в таблице 3. Отметим, что существует отдельный маршрут для каждого конца адресуемой сети point-to-point (в нашем случае это последовательный канал между RT6 и RT10).
RT6(origin)
RT5 o------------o-----------o Ib
/|\ 6 |\ 7
8/8|8\ | \
/ | \ 6| \
o | o | \7
N12 o N14 | \
N13 2 | \
N4 o-----o RT3 \
/ \ 5
1/ RT10 o-------o Ia
/ |\
RT4 o-----o N3 3| \1
/| | \ N6 RT7
/ | N8 o o---------o
/ | | | /|
RT2 o o RT1 | | 2/ |9
/ | | |RT8 / |
/3 |3 RT11 o o o o
/ | | | N12 N15
N2 o o N1 1| |4
| |
N9 o o N7
/|
/ |
N11 RT9 / |RT12
o--------o-------o o--------o H1
3 | 10
|2
|
o N10
Рисунок 3. Дерево SPF для маршрутизатора RT6 Ребра, для которых не указана стоимость имеют нулевую стоимость (нет соединения маршрутизатор – сеть). Маршруты в сети N12 – N15 являются внешней информацией, которая будет рассматриваться в параграфе 2.3 |
Маршрутизаторы в сети, относящиеся к другим AS (например, N12) показаны пунктирными линиями на дереве кратчайших путей (рисунок 3). Использование этой полученной извне маршрутной информации рассмотрено в следующем параграфе.
2.3. Внешние данные
После создания дерева проверяется маршрутная информация, полученная извне. Эта информация может приходить от других протоколов маршрутизации (например, BGP) или задаваться статически. Принятые по умолчанию маршруты также могут включаться как часть внешних маршрутных данных AS.
Внешняя маршрутная информация рассылается через AS без изменений с использованием лавинной маршрутизации. В нашем примере все маршрутизаторы в AS знают, что RT7 имеет два внешних маршрута с метрикой 2 и 9.
|
Таблица 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 |
Протокол OSPF поддерживает два типа внешней метрики. Тип 1 использует для метрики такие же единицы, которые служат для обозначения стоимости интерфейсов в OSPF (т. е., метрика определяется состоянием канала). Внешняя метрика типа 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 показаны записи, добавляемые в таблицу маршрутизации при проверке внешних маршрутов.
|
Таблица 4 Часть таблицы маршрутизации RT6 с внешними маршрутами. |
||
|
Получатель |
Next Hop |
Дистанция |
|
N12 |
RT10 |
10 |
|
N13 |
RT5 |
14 |
|
N14 |
RT5 |
14 |
|
N15 |
RT10 |
17 |
Обработка внешней метрики типа 2 проще. Выбирается граничный маршрутизатор AS, анонсирующий наименьшую метрику, независимо от внутренней дистанции до граничного маршрутизатора AS. Предположим, что в нашем примере маршрутизаторы RT5 и RT7 анонсируют внешние маршруты типа 2. Тогда весь трафик для сети N12 будет пересылаться маршрутизатору RT7, поскольку 2 < 8. При наличии нескольких маршрутов типа 2 с равной стоимостью, выбор осуществляется с учетом внутренней дистанции до маршрутизатора.
В AS может одновременно использоваться внешняя метрика типов 1 и 2, однако при наличии обоих типов предпочтение отдается внешней метрике типа 1.
В этом параграфе предполагается, что адресованные во внешние сети пакеты всегда пересылаются через анонсирующий граничный маршрутизатор AS. Однако, такой вариант не всегда желателен. Предположим, к примеру, что в сети на рисунке 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 перестает быть верным. Маршрутизаторы теперь имеют раздельные базы данных для каждой области, с которой данный маршрутизатор соединен4. Два маршрутизатора, относящиеся к одной области имеют для этой области идентичные базы каналов.
Маршрутизация в 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), к которому подключены все остальные области автономной системы.
Топология магистральной области определяет пути между областями. Для более эффективной организации магистральных путей могут использоваться виртуальные соединения. Это дает администратору некоторые средства контроля для маршрутов передачи междоменного трафика.
Подходящий граничный маршрутизатор для вывода пакетов из области отправителя определяется так же, как выбираются маршрутизаторы, анонсирующие внешние пути. Каждый граничный маршрутизатор в области резюмирует для области стоимость доставки во все внешние по отношению к данной области сети. После расчета для области дерева SPF маршруты ко всем внешним получателям рассчитываются путем проверки резюме от граничных маршрутизаторов области.
3.3. Классификация маршрутизаторов
До введения областей единственными маршрутизаторами OSPF, выполняющими специальные функции, были те маршрутизаторы, которые анонсировали внешние маршрутные данные (например, RT5 на рисунке 2). После раздела AS на области OSPF, маршрутизаторы приобретают дополнительную специализацию в соответствии с выполняемыми функциями:
........................... . + . . | 3+---+ . N12 N14 . N1|--|RT1|\ 1 . \ N13 / . | +---+ \ . 8\ |8/8 . + \ ____ . \|/ . / \ 1+---+8 8+---+6 . * N3 *---|RT4|------|RT5|--------+ . \____/ +---+ +---+ | . + / \ . |7 | . | 3+---+ / \ . | | . N2|--|RT2|/1 1\ . |6 | . | +---+ +---+8 6+---+ | . + |RT3|------|RT6| | . +---+ +---+ | . 2/ . Ia|7 | . / . | | . +---------+ . | | .Area 1 N4 . | | ........................... | | .......................... | | . N11 . | | . +---------+ . | | . | . | | N12 . |3 . Ib|5 |6 2/ . +---+ . +----+ +---+/ . |RT9| . .........|RT10|.....|RT7|---N15. . +---+ . . +----+ +---+ 9 . . |1 . . + /3 1\ |1 . . _|__ . . | / \ __|_ . . / \ 1+----+2 |/ \ / \ . . * N9 *------|RT11|----| * N6 * . . \____/ +----+ | \____/ . . | . . | | . . |1 . . + |1 . . +--+ 10+----+ . . N8 +---+ . . |H1|-----|RT12| . . |RT8| . . +--+SLIP +----+ . . +---+ . . |2 . . |4 . . | . . | . . +---------+ . . +--------+ . . N10 . . N7 . . . .Area 2 . .Area 3 . ................................ .......................... Рисунок 4. Пример конфигурации областей OSPF |
Внутренние (Internal) маршрутизаторы
Маршрутизатор, непосредственно подключенный к сетям единственной области. Такие маршрутизаторы используют единственную копию базового алгоритма маршрутизации.
Граничные маршрутизаторы областей (Area border router)
Маршрутизаторы, подключенные к нескольким областям. На граничных маршрутизаторах областей используется несколько копий базового алгоритма маршрутизации – по одной копии на каждую подключенную к маршрутизатору область. Граничные маршрутизаторы областей собирают сведения о топологии подключенных областей для передачи этих сведений в магистральную область. Магистраль распространяет полученную информацию между всеми областями.
Магистральные (Backbone) маршрутизаторы
Маршрутизаторы, имеющие интерфейс в магистральную область. К этому типу относятся все маршрутизаторы, подключенные к нескольким областям (т. е., граничные маршрутизаторы областей). Однако магистральные маршрутизаторы не обязаны быть граничными маршрутизаторами областей, поскольку некоторые маршрутизаторы могут быть подключены только к магистральной области.
Граничные маршрутизаторы AS (AS boundary router)
Маршрутизаторы, обменивающимися маршрутными данными с маршрутизаторами других AS. Такие маршрутизаторы анонсируют внешние маршрутные данные в автономную систему. Пути ко всем граничным маршрутизаторам AS известны каждому маршрутизатору в автономной системе. Эта классификация никак не связана с предыдущими типами – граничными маршрутизаторами AS могут быть внутренние маршрутизаторы или граничные маршрутизаторы областей, а также магистральные маршрутизаторы.
|
Таблица 5 Сети, анонсируемые в магистраль, маршрутизаторами RT3 и RT4. |
||
|
Сеть |
Анонс RT3 |
Анонс RT4 |
|
N1 |
4 |
4 |
|
N2 |
4 |
4 |
|
N3 |
1 |
1 |
|
N4 |
2 |
3 |
3.4. Пример конфигурации областей
На рисунке 4 показан пример конфигурации областей. Первая область включает сети N1 – N4 и подключенные к ним маршрутизаторы RT1 – RT4. Во вторую область входят сети N6 – N8 и маршрутизаторы RT7, RT8, RT10, RT11. Третья область состоит из сетей N9 – N11 и хоста H1 вместе с подключенными к ним маршрутизаторами RT9, RT11 и RT12. Третья область настроена так, что сети N9 – N11 и хост H1 группируются в один маршрут при анонсировании внешних по отношению к данной области путей (см. параграф 3.5).
На рисунке 4 маршрутизаторы RT1, RT2, RT5, RT6, RT8, RT9 и RT12 являются внутренними, RT3, RT4, RT7, RT10 и RT11 – граничными маршрутизаторами областей, а RT5 и RT7 – граничными маршрутизаторами AS.
В таблице 6 показана база данных о каналах для области 1. Эта таблица полностью описывает внутридоменную маршрутизацию. В таблице также приведено полное представление внешних сетей (internet) для двух внутренних маршрутизаторов RT1 и RT2. Ответственность за анонсирование в области 1 дистанций до всех внешних адресатов ложится на граничные маршрутизаторы области – RT3 и RT4. Маршрутизаторы RT3 и RT4 должны также анонсировать в область 1 местоположение граничных маршрутизаторов AS RT5 и RT7. И, наконец, внешние по отношению к AS анонсы LSA от маршрутизаторов RT5 и RT7 рассылаются с использованием лавинной маршрутизации через всю AS и, в частности, через область 1. Эти LSA включаются в базу данных области 1 и дают маршруты в сети N12 – N15.
Таблица 6 База данных области 1
** От **
|RT|RT|RT|RT|RT|RT|
|1 |2 |3 |4 |5 |7 |N3|
----- -------------------
RT1| | | | | | |0 |
RT2| | | | | | |0 |
RT3| | | | | | |0 |
* RT4| | | | | | |0 |
* RT5| | |14|8 | | | |
К RT7| | |20|14| | | |
* 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-N11,H1| | |29|36| | | |
N12| | | | |8 |2 | |
N13| | | | |8 | | |
N14| | | | |8 | | |
N15| | | | | |9 | |
Маршрутизаторы RT3 и RT4 также будут резюмировать топологию области 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 и добавляя дистанцию через магистраль до каждого анонсирующего маршрутизатора.
Таблица 7 База данных магистральной области
** От **
|RT|RT|RT|RT|RT|RT|RT
|3 |4 |5 |6 |7 |10|11|
------------------------
RT3| | | |6 | | | |
RT4| | |8 | | | | |
RT5| |8 | |6 |6 | | |
RT6|8 | |7 | | |5 | |
RT7| | |6 | | | | |
* RT10| | | |7 | | |2 |
* RT11| | | | | |3 | |
К N1|4 |4 | | | | | |
* N2|4 |4 | | | | | |
* N3|1 |1 | | | | | |
N4|2 |3 | | | | | |
Ia| | | | | |5 | |
Ib| | | |7 | | | |
N6| | | | |1 |1 |3 |
N7| | | | |5 |5 |7 |
N8| | | | |4 |3 |2 |
N9-N11,H1| | | | | | |11|
N12| | |8 | |2 | | |
N13| | |8 | | | | |
N14| | |8 | | | | |
N15| | | | |9 | | |
Если снова использовать в качестве примера маршрутизаторы RT3 и RT4, расчет будет включать следующие этапы:
- Сначала рассчитывается дерево SPF для магистрали. Этот расчет дает дистанции до всех остальных граничных маршрутизаторов областей. Определяются также дистанции до сетей (Ia и Ib) и граничных маршрутизаторов AS (RT5 и RT7), входящих в магистраль. Эти расчеты показаны в таблице 8.
-
После этого просматриваются резюме областей от граничных маршрутизаторов RT3 и RT4 для определения дистанции до всех маршрутизаторов за пределами данной области. Эти данные анонсируются внутри области маршрутизаторами RT3 и RT4. Анонсы, которые маршрутизаторы RT3 и RT4 будут передавать в область 1, показаны в таблице 9. Отметим, что в таблице 9 предполагается группировка интерфейсов Ia и Ib в один анонс LSA.
Таблица 8 Магистральные дистанции, рассчитанные RT3 и RT4
дист. от дист. от
RT3 RT4
__________________________________
до 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
Информация, импортируемая в область 1 маршрутизаторами RT3 и RT4, позволяет внутренним маршрутизаторам (например, RT1) выбирать граничный маршрутизатор области более эффективно. Маршрутизатор RT1 будет использовать RT4 для трафика в сеть N6, RT3 – для сети N10, а для трафика в сеть N8 будут использоваться оба маршрутизатора с распределением нагрузки.
Маршрутизатор RT1 таким же способом может определить кратчайший путь до граничных маршрутизаторов AS (RT5 и RT7). Просматривая в маршрутизаторах RT5 и RT7 записи AS-external-LSA, маршрутизатор RT1 может выбирать между RT5 и RT7 при пересылке пакетов адресатам из других AS (одна из сетей N12 – N15).
Таблица 9 Дистанции, анонсируемые в область 1 маршрутизаторами RT3 и RT4
Адресат анонс RT3 анонс RT4
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Отметим, что разрыв соединения между маршрутизаторами RT6 и RT10 будет приводить к разрыву магистрали. Организация виртуального соединения между маршрутизаторами RT7 и RT10 позволит обеспечить устойчивость магистрали к такого рода сбоям.
3.5. Поддержка подсетей IP
OSPF связывает адресную маску IP с каждым анонсируемым маршрутом. Маска показывает диапазон адресов, описываемых данным маршрутом. Например, summary-LSA для адресата 128.185.0.0 с маской 0xffff0000 на самом деле описывает маршрут к адресатам в диапазоне.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 приведены примеры адресов таких подсетей вместе с масками.
|
Таблица 10 Примеры масок подсетей |
||
|
Адрес сети |
Маска IP |
Размер подсети |
|
128.185.16.0 |
0xfffff000 |
4K |
|
128.185.1.0 |
0xffffff00 |
256 |
|
128.185.0.8 |
0xfffffff8 |
8 |
Существует множество способов деления сетей класса A, B и C на подсети переменного размера. Описание процедур такого деления выходит за пределы данной спецификации, однако мы рекомендуем пользоваться следующим правилом – при пересылке пакетов IP их следует адресовать в ту сеть, которая точнее всего совпадает с адресом получателя пакета. В контексте подсетей наилучшее соответствие эквивалентно самой длинной маске5. Например, используемый по умолчанию маршрут с адресом 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.
+---+ +---+ |RT1|------------|RT2| o---------------o +---+ N1 +---+ RT1 RT2 RT7 o---------+ +---+ +---+ +---+ /|\ | |RT7| |RT3| |RT4| / | \ | +---+ +---+ +---+ / | \ | | | | / | \ | +-----------------------+ RT5o RT6o oRT4 | | | N2 * * * | +---+ +---+ * * * | |RT5| |RT6| * * * | +---+ +---+ *** | o---------+ RT3
Рисунок 6. Граф смежности
Протокол OSPF обеспечивает оповещение всех маршрутизаторов области о тупиковом характере данной области – такое решение предотвращает ненужные лавинные рассылки анонсов AS-external-LSA.
Существуют некоторые ограничения на использование stub-областей. Через такие области невозможно организовать виртуальные соединения и, кроме того, внутрь тупиковых областей не должны попадать граничные маршрутизаторы AS.
3.7. Разделение областей
OSPF не предпринимает активных попыток восстановления распавшихся на части областей (area partition). В таких случаях просто каждый фрагмент области рассматривается как новая область и магистраль автономной системы обеспечивает маршрутизацию между новыми областями. Некоторые адресаты, для которых использовалась внутридоменная маршрутизация, могут после раздела потребовать междоменной маршрутизации.
Однако для сохранения полной маршрутизации после разделения области диапазон адресов не должен разделяться на множество компонент, связанных с фрагментами области. Не должна делиться на части и магистраль. Если это произойдет, некоторые части AS перестанут быть доступными. Разорванную магистральную область можно собрать заново путем организации виртуальных соединений (см. параграф 15).
Другой способ представления раздела областей основан на графах AS, описанных в параграфе 2. Идентификаторы областей (Area ID) можно представить цветом ребер графа6. Каждое ребро графа подключено к сети или является сетью 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.
|
Таблица 11 Типы пакетов OSPF |
||
| Тип | Название | Назначение |
| 1 | Hello |
Обнаружение и поддержка соседства |
| 2 | Database Description |
Резюмирование содержимого БД |
| 3 | Link State Request |
Загрузка БД |
| 4 | Link State Update |
Обновление БД |
| 5 | Link State Ack |
Подтверждение лавинной рассылки |
Пакеты протокола маршрутизации всегда должны передаваться с нулевым значением поля IP TOS. Если это возможно, пакеты протоколов маршрутизации должны иметь преимущество по сравнению с обычным трафиком данных IP как для приема, так и при передаче. Чтобы облегчить эту задачу, протокол OSPF должен использовать в поле IP precedence значение Internetwork Control (см. [Ref5]).
Все пакеты протокола OSPF используют однотипные заголовки, описанные в Приложении A. Типы пакетов OSPF перечислены в таблице 11. Форматы пакетов также описаны в Приложении A.
Протокол OSPF Hello использует пакеты Hello для организации и поддержки соседских отношений. Пакеты Database Description (описание базы данных) и Link State Request (запрос состояния канала) служат для поддержки отношений смежности. Гарантированный обмен обновлениями OSPF основан на обмене пакетами Link State Update (обновление состояния канала) Link State Acknowledgment (подтверждение приема обновления).
|
Таблица 12 Типы анонсов OSPF (LSA). |
||
| Тип | Имя LSA | Описание LSA |
| 1 | Router-LSA | Генерируются всеми маршрутизаторами. Этот тип LSA описывает состояния интерфейсов маршрутизатора в область. Анонс рассылается в лавинном режиме внутри области. |
| 2 | Network-LSA | Генерируется выделенным маршрутизатором DR для широковещательных и NBMA-сетей. Этот тип LSA включает список маршрутизаторов, подключенных к сети. Рассылается в лавинном режиме внутри области. |
| 3, 4 | Summary-LSA | Генерируется граничными маршрутизаторами областей и рассылается в лавинном режиме в пределах связанной с LSA области. Каждый анонс summary-LSA описывает маршрут к адресату за пределами данной области, но внутри данной AS (междоменный маршрут). Тип 3 summary-LSA описывает маршруты в сети, а тип 4 – к граничным маршрутизаторам AS. |
| 5 | AS-external-LSA | Генерируется граничными маршрутизаторами 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-адресом.
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.
Поддержка задач – 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).
+----+ |RT10|------+ +----+ \+-------------+ / \ |Табл. маршрут| / \ +-------------+ / \ +------+ / \ +--------+ |Обл. 2|---+ +---|Магистр.| +------+************ +--------+ / \ * / \ / \ * / \ +---------+ +---------+ +------------+ +------------+ |Интерфейс| |Интерфейс| |Вирт. канал | |Интерфейс Ib| |в сеть N6| |в сеть N8| | до RT11 | +------------+ +---------+ +---------+ +------------+ | / \ | | | / \ | | | +--------+ +--------+ | +-------------+ +------------+ | Сосед | | Сосед | | | Сосед RT11 | | Сосед RT6 | | RT8 | | RT7 | | +-------------+ +------------+ +--------+ +--------+ | | +-------------+ | Сосед RT11 | +-------------+ Рисунок 5. Структуры данных маршрутизатора RT10. |
На рисунке 5 показана структура данных типичного маршрутизатора (RT10 из примера на рисунке 4). Отметим, что маршрутизатор RT10 имеет виртуальное соединение с RT11, а область 2 является для этого соединения транзитной. Это соединение показано звездочками (*) на рисунке 5. Когда виртуальное соединение активизируется при построении дерева кратчайших путей для области 2, оно становится интерфейсом в магистральную область (см. два магистральных интерфейса, отмеченных на рисунке 3).
6. Структура данных области
Структура данных области содержит всю информацию, используемую при работе базового алгоритма маршрутизации OSPF. Каждая область поддерживает свою базу данных link-state. Сеть целиком принадлежит к одной области и каждый интерфейс маршрутизатора тоже подключен к одной области. Отношения смежности организуются между маршрутизаторами одной области.
Магистраль OSPF является специальной областью OSPF, отвечающей за распространение данных междоменной маршрутизации.
База данных о каналах состоит из набора router-LSA, network-LSA и summary-LSA, получаемых от маршрутизаторов области. Эта информация рассылается в лавинном режиме в пределах данной области. Список AS-external-LSA (см. параграф 5) также является частью каждой базы каналов.
Area ID – идентификатор области
32-битовый идентификатор области7. Значение 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.
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 Exchange8 и выполнения всех запросов 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.
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.
В зависимости от наличия в сети выделенного маршрутизатора DR возможны два варианта графа. В физических сетях «точка-точка», сетях Point-to-MultiPoint и виртуальных каналах соседние маршрутизаторы становятся смежными, если они могут обмениваться данными напрямую. В широковещательных и 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).
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-адресом9. Отметим, что в большинстве случаев виртуальные соединения работают подобно безадресным сетям point-to-point. Однако с каждым виртуальным каналом связан IP-адрес интерфейса (этот адрес определяется при построении таблицы маршрутизации), который используется в качестве адрес отправителя при передаче пакетов в виртуальный канал.
|
Таблица 13 Описания способов распространения пакетов OSPF. |
||
| Тип | Название пакета | Параграф |
| 1 | Hello | 9.5 |
| 2 | Database description | 10.8 |
| 3 | Link state request | 10.9 |
| 4 | Link state update | 13.3 |
| 5 | Link state ack | 13.5 |
Более подробные сведения о форматах различных пакетов OSPF приведены в параграфах, указанных в таблице 13.
8.2. Прием пакетов протокола
Когда пакет протокола принимается маршрутизатором, он маркируется принявшим пакет интерфейсом. Для маршрутизаторов, использующих виртуальные соединения, не всегда возможно сразу определить с каким интерфейсом связан пакет. Рассмотрим в качестве примера маршрутизатор RT11 (рисунок 4). Если RT11 принимает пакет протокола OSPF на своем интерфейсе в сеть N8, этот пакет можно связать с интерфейсом в область 2 или виртуальным каналом к маршрутизатору RT10, являющемуся частью магистрали. При дальнейшем рассмотрении предполагается, что пакет изначально связан не с виртуальным соединением10.
Для того, чтобы пакет был воспринят на уровне IP, он должен пройти ряд проверок еще до того, как будет передан протоколу OSPF для обработки:
- Контрольная сумма IP должна совпадать с одноименным полем заголовка пакета.
- В качестве адреса получателя должен быть задан IP-адрес принявшего пакет интерфейса или один из групповых адресов IP (AllSPFRouters или AllDRouters).
- Поле протокола IP должно указывать на OSPF (89).
- Пакеты локального происхождения не должны передаваться протоколу OSPF – IP-адрес отправителя должен проверяться на предмет совпадения с одним из адресов принявшего пакет маршрутизатора или одним из групповых адресов.
После этого проверяется заголовок OSPF – поля, указанные в заголовке, должны совпадать со значениями, настроенными для принявшего пакет интерфейса. При отсутствии требуемого пакет должен отбрасываться:
- Поле версии должно содержать значение 2 (текущая версия протокола).
-
Проверяется идентификатор области Area ID из заголовка OSPF – если не выполняется ни одно из двух перечисленных ниже условий, пакет должен быть отброшен.
-
Идентификатор Area ID относится к области принявшего пакет интерфейса. В этом случае пакет был принят через один интервал и, следовательно, IP-адрес отправителя должен относиться к той же сети, что и адрес принявшего пакет интерфейса. Это можно проверить, сравнив IP-адрес отправителя из заголовка пакета с IP-адресом принявшего интерфейса после использования для обоих адресов маски подсети, заданной для интерфейса. Такое сравнение не должно проводиться для сетей point-to-point, в таких сетях адреса на каждой стороне соединения выделяются совершенно или могут отсутствовать вообще.
- Пакет принят из магистрали. В таких случаях пакеты передаются через виртуальное соединение. Принявший пакет маршрутизатор должен быть граничным в своей области и значение Router ID, указанное в пакете (маршрутизатор-отправитель) должно относиться к другой стороне виртуального соединения. Принимающий интерфейс должен быть подключен к настроенной для виртуального соединения транзитной области. После выполнения всех перечисленных проверок пакет принимается и ассоциируется с виртуальным соединением (и магистральной областью).
- Пакеты, отправленные по адресу AllDRouters должны приниматься только маршрутизаторами DR и Backup (см. параграф 9.1).
- Указанное в пакете значение AuType (тип аутентификации) должно совпадать со значением AuType для связанной с пакетом области.
-
Выполняется процедура аутентификации пакета, указанная полем AuType (см. Приложение D). В процедуре аутентификации может использоваться один или несколько ключей Authentication, которые задаются независимо для каждого интерфейса. Процедура аутентификации может также проверять контрольную сумму полей заголовка OSPF (если эта контрольная сумма используется она представляет собой стандартную контрольную сумму IP для содержимого пакета OSPF без учета 64-битового поля аутентификации). Пакеты, не прошедшие процедуру аутентификации, должны отбрасываться.
|
Таблица 14 Параграфы, описывающие прием пакетов OSPF. |
||
| Тип | Название | Описание |
| 1 | Hello | 10.5 |
| 2 | Описание базы данных (Database description) | 10.6 |
| 3 | Запрос состояния канала (Link state request) | 10.7 |
| 4 | Обновление состояния канала (Link state update) | 13 |
| 5 | Подтверждение состояния канала (Link state ack) | 13.7 |
В случае приема пакетов Hello их дальнейшая обработка осуществляется протоколом Hello, описанным в параграфе 10.5. Все остальные типы пакетов предаются только между смежными маршрутизаторами. Это означает, что пакет должен быть передан одним из активных соседей принявшего маршрутизатора. Если принимающий интерфейс подключен к широковещательной сети, сети Point-to-MultiPoint или NBMA, отправитель идентифицируется адресом IP в заголовке IP-пакета. Если принимающий интерфейс подключен к сети point-to-или виртуальному соединению, отправитель идентифицируется полем Router ID в заголовке пакета OSPF. Структура данных принимающего интерфейса содержит список активных соседей. Пакеты, не соответствующие любому из перечисленных выше условий, должны отбрасываться.
После проверки пакет ассоциируется с передавшим его активным соседом. Дальнейшие операции по обработке принимаемых пакетов описаны ниже в отдельных параграфах (см. таблицу 14).
