RFC 2328 (часть 2)

Please enter banners and links.

image_print

Часть 1

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

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

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

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

Type

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

State

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

IP interface address

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

IP interface mask

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

Area ID

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

HelloInterval

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

RouterDeadInterval

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

InfTransDelay

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

Router Priority

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

Hello Timer

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

Wait Timer

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

List of neighboring routers

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

Designated Router

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

Backup Designated Router

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

Interface output cost(s)

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

RxmtInterval

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

AuType

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

Authentication key

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

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

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

Down

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

Loopback

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

Waiting

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

Point-to-point

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

DR Other

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

Backup

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

DR

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

                                  +----+   UnloopInd   +--------+
                                  |Down|<--------------|Loopback|
                                  +----+               +--------+
                                     |
                                     |InterfaceUp
                          +-------+  |               +--------------+
                          |Waiting|<-+-------------->|Point-to-point|
                          +-------+                  +--------------+
                              |
                     WaitTimer|BackupSeen
                              |
                              |
                              |   NeighborChange
          +------+           +-+<---------------- +-------+
          |Backup|<----------|?|----------------->|DROther|
          +------+---------->+-+<-----+           +-------+
                    Neighbor  |       |
                    Change    |       |Neighbor
                              |       |Change
                              |     +--+
                              +---->|DR|
                                    +--+

Рисунок 7. Смена состояний интерфейса

В дополнение к показанным на графе переходам событие InterfaceDown всегда приводит к состоянию Down,а LoopInd – к состоянию Loopback.

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

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

InterfaceUp

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

WaitTimer

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

BackupSeen

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

NeighborChange

Это событие связано с изменениями набора соседей данного интерфейса, с которыми осуществляется двухсторонняя связь. В результате требуется перерасчет выделенного маршрутизатора (Backup) DR. Событие NeighborChange может быть вызвано одной из перечисленных ниже причин (описания состояний соседей приведены в параграфе 10.1):

  • Организована двухсторонняя связь с соседом (состояние соседа перешло на уровень 2-Way или выше).

  • Прервана двухсторонняя связь с соседом (состояние соседа перешло на уровень Init или ниже).

  • Один из соседей с двухсторонней связью недавно обозначил себя в качестве DR или Backup DR (определяется из пакетов Hello от этого соседа).

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

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

LoopInd

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

UnloopInd

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

InterfaceDown

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

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

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

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

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

Состояние: Down

Событие: InterfaceUp

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

Действия: Начало нового отсчета таймера Hello, задающего периодическую рассылку пакетов Hello данным интерфейсом. Если интерфейс подключен к физической сети point-to-point, сети Point-to-MultiPoint или виртуальному соединению, он переводится в состояние Point-to-Point. Для широковещательных сетей и сетей NBMA интерфейс переводится в состояние DR Other, если для маршрутизатора нежелательна работа в качестве DR. Если же маршрутизатор может играть роль DR для подключенной сети, интерфейс переводится в состояние Waiting и запускается таймер Wait Timer. Кроме того, в сетях NBMA проверяется список соседей интерфейса и генерируется событие Start для каждого из соседей, который тоже может стать DR.

Состояние: Waiting

Событие: BackupSeen

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

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

Состояние: Waiting

Событие: WaitTimer

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

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

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

Событие: NeighborChange

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

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

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

Событие: InterfaceDown

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

Действия: Сбрасываются все связанные с интерфейсом переменные, отключаются таймеры интерфейса и удаляются все отношения соседства (путем генерации события KillNbr для всех соседей – см. параграф 10.2).

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

Событие: LoopInd

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

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

Состояние: Loopback

Событие: UnloopInd

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

Действия: Не требуется выполнения каких-либо действий (например, все связанные с интерфейсом переменные уже были сброшены при переходе в состояние Loopback). Отметим, что для перехода интерфейса в рабочее состояние он должен получить сигнал InterfaceUp.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда пакеты Hello периодически отправляются всем соседям, интервал между пакетами Hello определяется состоянием соседа. Если сосед находится в состоянии Down, пакеты Hello передаются каждые PollInterval секунд, в остальных случаях интервал передачи Hello составляет HelloInterval секунд.

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

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

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

State

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

Inactivity Timer

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

Master/Slave

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

DD Sequence Number

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

Last received Database Description packet

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

Neighbor ID

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

Neighbor Priority

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

Neighbor IP address

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

Neighbor Options

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

Neighbor’s Designated Router

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

Neighbor’s Backup Designated Router

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

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

Link state retransmission list

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

Database summary list

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

Link state request list

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

+—-+

|Down|

+—-+

|\

| \Start

| \ +——-+

Hello | +—->|Attempt|

Received | +——-+

| |

+—-+<-+ |HelloReceived

|Init|<—————+

+—-+<——–+

| |

|2-Way |1-Way

|Received |Received

| |

+——-+ | +—–+

|ExStart|<——–+——->|2-Way|

+——-+ +—–+

Рисунок 8. Смена состояний соседа (протокол Hello)

В дополнение к показанным переходам события KillNbr, InactivityTimer и LLDown всегда приводят к состоянию Down.

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

Состояние соседа (реально, состояние «разговора» с соседним маршрутизатором) описано в последующих параграфах. Состояния прослушиваются для выполнения требуемых функций. Например, сначала прослушивается нерабочее (inoperative) состояние, после которого проходит несколько промежуточных состояний пока не будет достигнуто финальное. В спецификации используется перечисленный ниже порядок состояний как некая иерархия и в тексте встречаются фразы типа “состояние не ниже X”. На рисунках 8 и 9 показаны графы изменения состояний соседа. Дуги графа помечены именами событий, вызывающих смену состояния. Описание этих событий приводится в параграфе 10.2.

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

Граф на рисунке 9 показывает формирование отношений смежности (не каждая пара соседей поддерживает отношения смежности – см. параграф 10.4). Организация этих отношений начинается при состоянии соседа ExStart. После того, как пара маршрутизаторов согласует отношения ведущий-ведомый, состояние меняется на Exchange. С этого момента сосед начинает процедуру лавинной рассылки (flooding procedure) и начинается процесс синхронизации баз данных двух маршрутизаторов. По завершении синхронизации сосед переходит в состояние Full и маршрутизаторы становятся полностью смежными. С этого момента смежность указывается в анонсах LSA.

Более детальное описание переходов состояний соседа и связанных с этим дополнительных действий приведено в параграфе 10.3.

                                   +----+
                                   |Down|
                                   +----+
                                     |\
                                     | \Start
                                     |  \      +-------+
                             Hello   |   +---->|Attempt|
                            Received |         +-------+
                                     |             |
                             +----+<-+             |HelloReceived
                             |Init|<---------------+
                             +----+<--------+
                                |           |
                                |2-Way      |1-Way
                                |Received   |Received
                                |           |
              +-------+         |        +-----+
              |ExStart|<--------+------->|2-Way|
              +-------+                  +-----+

Рисунок 8. Смена состояний соседа (протокол Hello)

В дополнение к показанным переходам события KillNbr, InactivityTimer и LLDown всегда приводят к состоянию Down.

                                  +-------+
                                  |ExStart|
                                  +-------+
                                    |
                     NegotiationDone|
                                    +->+--------+
                                       |Exchange|
                                    +--+--------+
                                    |
                            Exchange|
                              Done  |
                    +----+          |      +-------+
                    |Full|<---------+----->|Loading|
                    +----+<-+              +-------+
                            |  LoadingDone     |
                            +------------------+

Рисунок 9. Смена состояний соседа (Database Exchange)

В дополнение к показанным на рисунке переходам события SeqNumberMismatch и BadLSReq приводят к состоянию ExStart,

событие 1-Way – к состоянию Init, а события KillNbr, InactivityTimer и LLDown – к состоянию Down. Событие AdjOK? ведет к формированию или разрыву смежности.

Down

Начальное состояние разговора с соседом, показывающее, что от соседа в последнее время не приходило информации. В сетях NBMA сообщения Hello могут передаваться соседям в состоянии Down (частота передачи снижается, см. параграф 9.5.1).

Attempt

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

Init

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

2-Way

Между соседями организована двухсторонняя связь, обеспечивающая работу протокола Hello. С этого состояния начинается организация отношений смежности. Маршрутизаторы (Backup) DR выбираются из числа соседей в состоянии 2-Way или выше.

ExStart

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

Exchange

В этом состоянии маршрутизатор полностью описывает свою базу данных link state, посылая пакеты DD своему соседу. Каждый пакет DD имеет порядковый номер и прием пакета должен явно подтверждаться. Только пакеты DD допускается передавать в любой момент. В этом состоянии могут также передаваться пакеты Link State Request для получения от соседа свежих LSA. Смежные узлы в состоянии Exchange и выше используют лавинную рассылку. Фактически отношения смежности позволяют принимать и передавать все типы пакетов протокола OSPF.

Loading

В этом состоянии соседу передаются пакеты Link State Request для получения свежих LSA, которые были обнаружены (но еще не получены) в состоянии Exchange.

Full

В этом состоянии обеспечивается полная смежность соседних маршрутизаторов. Отношения смежности отражаются в анонсах router-LSA и network-LSA.

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

Изменения состояний могут быть связаны с различными событиями, описанными ниже (названия событий служат метками дуг графа на рисунках 8 и 9):

HelloReceived

Получен пакет Hello от соседа.

Start

Соседу нужно отправить пакет Hello в течение HelloInterval секунд (только для соседей, связанных с сетями NBMA).

2-Way Received

Между двумя соседними маршрутизаторами организована двухсторонняя связь. Такая связь отражается появлением маршрутизатора в пакетах Hello от соседа.

NegotiationDone

Согласованы отношения Master/Slave и порядковые номера DD. Это событие служит сигналом для начала приема/передачи пакетов DD. Дополнительные сведения об этом событии приведены в параграфе 10.8.

ExchangeDone

Оба маршрутизатора успешно завершили передачу всех пакетов DD. Каждый маршрутизатор сейчас знает, что часть его базы данных устарела. Дополнительные сведения об этом событии приведены в параграфе 10.8.

BadLSReq

Получен пакет Link State Request для записи LSA, отсутствующей в базе данных. Это говорит об ошибке в процессе DE.

Loading Done

Получены пакеты Link State Update для всех устаревших записей базы данных. Это событие указывается пустым списком в запросе Link state после завершения процесса обмена базами данных (DE).

AdjOK?

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

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

SeqNumberMismatch

Принят пакет DD, который содержит a) некорректный порядковый номер DD, b) неожиданно установленный бит Init или c) значение поля Options, отличающегося от значения Options в последнем пакете DD. Любое из перечисленных условий говорит о наличии ошибки в процессе организации смежности.

1-Way

От соседа получен пакет Hello, в котором не упомянут данный маршрутизатор – отсутствует двухсторонняя связь.

KillNbr

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

InactivityTimer

Активизирован таймер бездействия в результате отсутствия пакетов Hello от соседа. Сосед переводится в состояние Down.

LLDown

Информация от нижележащих протоколов о недоступности соседа. Например, сеть X.25 может показывать такие ситуации с явно с указанием причин и данных диагностики. Это событие переводит соседа в состояние Down.

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

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

При смене состояния соседа может потребоваться повтор процедуры выбора маршрутизатора DR. Это определяется генерацией события NeighborChange (см. параграф 9.2). Если интерфейс находится в состоянии DR (данный маршрутизатор является DR), изменения состояния соседа будет приводить к генерации нового анонса network-LSA (см. параграф 12.4).

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

Состояние: Down

Событие: Start

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

Действия: Передается пакет Hello соседу (это сосед всегда связан с сетью NBMA) и запускается таймер Inactivity для этого соседа. Большое значение этого таймера говорит о невозможности связи с соседом.

Состояние: Attempt

Событие: HelloReceived

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

Действия: Заново запускается таймер Inactivity для соседа, поскольку от него была получена информация.

Состояние: Down

Событие: HelloReceived

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

Действия: Запускается таймер Inactivity для соседа. Большое значение этого таймера говорит о неработоспособности соседа.

Состояние: Init or greater

Событие: HelloReceived

Новое состояние: Состояние не меняется.

Действия: Заново запускается таймер Inactivity для соседа, поскольку от него была получена информация.

Состояние: Init

Событие: 2-WayReceived

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

Действия: Определяется необходимость организации отношений смежности с соседом (см. параграф 10.4). Если смежность не требуется, сохраняется состояние 2-Way, в противном случае для соседа вводится состояние ExStart. После смены состояния маршрутизатор увеличивает значение счетчика порядковых номеров DD в базе данных соседа. Если это происходит впервые с момента организации смежности, для порядкового номера DD должно быть выбрано уникальное значение (например, на основе текущего времени). После этого маршрутизатор объявляет себя ведущим (устанавливается значение master для бита master/slave) и начинает передачу пакета DD с установленными битами I, M и MS. Остальные поля этого пакета DD должны быть пустыми. Передача пакета DD должна повторятся с интервалом RxmtInterval до перехода в следующее состояние (см. параграф 10.8).

Состояние: ExStart

Событие: NegotiationDone

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

Действия: Маршрутизатор должен перечислить содержимое своей базы данных LS (link state) для всей области в списке Database summary для соседа. База данных для области включает router-LSA, network-LSA и summary-LSA, содержащиеся в структуре данных области, вместе с AS-external-LSA, содержащимися в глобальной структуре данных. Записи AS-external-LSA опускаются из списка баз данных виртуальных соседей, а также для случая тупиковых областей (см. параграф 3.6). Взамен их в список добавляются LSA, возраст которых равен MaxAge. Резюме списка Database summary будут передаваться соседу в пакетах DD. Каждый пакет DD имеет порядковый номер и прием пакета должен явно подтверждаться. Только для пакетов DD допустима передача в любой момент времени. Дополнительные сведения о работе с пакетами DD содержатся в параграфах 10.8 и 10.6.

Состояние: Exchange

Событие: ExchangeDone

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

Действия: Если список запроса LS от соседа пуст, новым состоянием будет Full и никаких действий не требуется – это финальное состояние отношений смежности. В остальных случаях новым состоянием будет Loading с последующим началом (продолжением) передачи пакетов Link State Request соседу (см. параграф 10.9). Это запросы на получение от соседа свежих записей LSA (обнаруженных, но еще не полученных в состоянии Exchange). LSA перечисляются в списках Link State Request, связанных с соседом.

Состояние: Loading

Событие: Loading Done

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

Действия: Дополнительных действий не требуется – это финальное состояние отношений смежности.

Состояние: 2-Way

Событие: AdjOK?

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

Действия: Определяет необходимость организации смежности с соседним маршрутизатором (см. параграф 10.4). Если смежность не требуется, сохраняется состояние 2-Way, в противном случае осуществляется переход в состояние ExStart и выполнение действий, описанных выше для состояний Init и 2-WayReceived.

Состояние: ExStart или выше

Событие: AdjOK?

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

Действия: Определяет необходимость сохранения смежности с соседним маршрутизатором. При положительном ответе состояние сохраняется и дополнительных действий не требуется. Если смежность не нужно сохранять, состояние меняется на 2-Way. Списки Link state, Database summary и Link state request удаляются из LSA.

Состояние: Exchange или выше

Событие: SeqNumberMismatch

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

Действия: Отношения смежности (возможно частично организованные) были разорваны и предпринимается попытка восстановить их. Состояние соседа переводится сначала в ExStart. Списки Link state retransmission, Database summary и Link state request удаляются из LSA. После этого маршрутизатор увеличивает значение счетчика порядковых номеров DD в структуре данных о соседе, объявляет себя ведущим (установив для бита master/slave значение master) и начинает передавать пакеты с установленными битами I, M и MS. Остальные поля пакета DD должны быть пустыми (см. параграф 10.8).

Состояние: Exchange или выше

Событие: BadLSReq

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

Действия: Действия для событий BadLSReq в точности совпадают с действиями для SeqNumberMismatch. Отношения смежности (возможно частично организованные) были разорваны и предпринимается попытка восстановить их. Дополнительная информация приведена выше в описании действий по событию SeqNumberMismatch для Exchange и более высокий состояний.

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

Событие: KillNbr

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

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA. Отключается таймер Inactivity.

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

Событие: LLDown

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

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA. Отключается таймер Inactivity.

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

Событие: InactivityTimer

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

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA.

Состояние: 2-Way или выше

Событие: 1-WayReceived

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

Действия: Списки Link state retransmission, Database summary и Link state request удаляются из LSA.

Состояние: 2-Way or greater

Событие: 2-WayReceived

Новое состояние: Состояние не меняется.

Действия: Дополнительных действий не требуется.

Состояние: Init

Событие: 1-WayReceived

Новое состояние: Состояние не меняется.

Действия: Дополнительных действий не требуется.

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

Отношения смежности организуются с частью соседей маршрутизатора. Маршрутизаторы, связанные сетями point-to-point, Point-to-MultiPoint или виртуальными каналами, всегда являются смежными. В широковещательных и NBMA-сетях все маршрутизаторы являются смежными с DR и Backup DR.

Решение вопроса об организации отношений смежности происходит в двух точках машины состояний соседа. Первой точкой является начальная организация двухсторонней связи между соседями, а второй – обнаружение смены маршрутизаторов (Backup) DR. Если принято решение не пытаться организовать отношения смежности, смена состояний соседей останавливается на уровне 2-Way.

Отношения смежности следует организовывать при наличии с соседом двухсторонней связи и выполнении, по крайней мере, одного из перечисленных ниже условий:

  • маршрутизаторы связаны сетью point-to-point
  • маршрутизаторы связаны сетью Point-to-MultiPoint
  • маршрутизаторы связаны виртуальным каналом
  • маршрутизатор играет роль DR
  • маршрутизатор играет роль Backup DR
  • соседний маршрутизатор является DR
  • соседний маршрутизатор является Backup DR

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

В этом параграфе рассматривается процесс обработки пакетов Hello (описание формата пакетов приведено в параграфе A.3.2). На приемной стороне базовые операции обработки пакетов OSPF включают проверку заголовка IP и заголовка OSPF. После этого значения полей Network Mask, HelloInterval и RouterDeadInterval в принятом пакете Hello сравниваются с параметрами принимающего интерфейса. При любом несовпадении обработка завершается с отбрасыванием пакета. Иными словами, перечисленные поля реально описывают конфигурацию подключенной сети. Однако это правило имеет одно исключение – в сетях point-to-point и виртуальных каналах значение Network Mask принятого пакета Hello следует игнорировать.

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

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

При получении пакета Hello от соседа в широковещательной, Point-to-MultiPoint или NBMA-сети, устанавливается значение поля Neighbor ID, равное значению Router ID в заголовке OSPF принятого пакета. Для этих типов сетей поля структуры данных о соседе Router Priority, Designated Router и Backup Designated Router также устанавливаются равными значениям соответствующих полей пакета Hello; изменения этих полей должны быть зафиксированы для последующей обработки. При получении пакета Hello из сети point-to-point (но не из виртуального канала) значение Neighbor IP устанавливается в соответствии с IP-адресом отправителя.

Далее проверяется остальная часть пакета Hello и генерируются события для машин состояний соседа и интерфейса. Эти машины состояний выполняются немедленно или помещаются в очередь (см. параграф 4.4). В приведенном ниже примере указано, что машина состояний соседа исполняется сразу же (in line) и несколько смен состояния могут быть инициированы одним пакетом Hello:

  • Каждый принятый пакет Hello активизирует машину состояний соседа событием HelloReceived.
  • После этого проверяется список соседей в пакете Hello. Если принявший маршрутизатор присутствует в списке, машине состояний передается событие 2-WayReceived. В противном случае используется событие 1-WayReceived и обработка пакета заканчивается.
  • Далее, если было зафиксировано изменение поля Router Priority, планируется активизация машины состояний интерфейса событием NeighborChange.
  • Если сосед декларирует себя как DR (в пакете Hello поле Designated Router = Neighbor IP), поле Backup DR в пакете имеет значение 0.0.0.0 и принимающий интерфейс находится в состоянии Waiting, планируется активизация машины состояний интерфейса событием BackupSeen. В остальных случаях, если сосед декларирует себя как DR, но не был им до этого или не декларирует себя в этом качестве, хотя ранее играл роль DR, планируется активизация машины состояний принимающего интерфейса событием NeighborChange.
  • Если сосед декларирует себя как Backup DR (в пакете Hello поле Backup Designated Router = Neighbor IP) и приемный интерфейс находится в состоянии Waiting, планируется активизация машины состояний интерфейса событием BackupSeen. В остальных случаях, когда сосед объявил себя Backup DR, не будучи таковым до этого, или снял с себя полномочия Backup DR, планируется активизация машины состояний принимающего интерфейса событием NeighborChange. В сетях NBMA прием пакета Hello может также вызывать передачу ответного пакета Hello (см. параграф 9.5.1).

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

В этом параграфе описан процесс обработки принимаемых пакетов DD. Входящие пакеты DD уже связаны с соседом и принявшим интерфейсом в процессе базовой обработки (см. параграф 8.2). Отказ или восприятие и дальнейшая обработка воспринятых пакетов DD зависит от состояния соседа.

Для воспринимаемых пакетов DD в соответствующей структуре данных о соседе после last received Database Description packet (последний принятый пакет DD) должны быть сохранены значения битов I, M и MS, а также поля Options и порядкового номера DD. Если эти поля совпадают для двух последовательных пакетов DD от одного соседа, второй пакет DD рассматривается в процессе последующей обработки как дубликат.

Если поле Interface MTU в пакете DD показывает, что размер дейтаграммы IP превышает возможности маршрутизатора (требует фрагментации), пакет DD отбрасывается. Дальнейшая обработка зависит от состояния соседа:

Down

Пакет должен отбрасываться.

Attempt

Пакет должен быть отброшен.

Init

Машина состояний соседа должна активизироваться событием 2-WayReceived, что ведет к немедленному переходу в состояние 2-Way или ExStart. Если новым состоянием является ExStart, обработка текущего пакета должна продолжаться для случая ExStart, описанного ниже.

2-Way

Пакет следует игнорировать. Пакеты DD используются только для организации мостов и отношений смежности4.

ExStart

Если принятый пакет соответствует одному из приведенных ниже условий, машина состояний соседа должна активизироваться событием NegotiationDone (переход в транзитное состояние Exchange), поле Options должно быть сохранено в структуре данных о соседе (Neighbor Options), а пакет должен быть воспринят для последующей обработки (см. ниже).

  • Биты I, M и MS установлены, остальные поля пакеты пусты и значение Router ID у соседа больше, чем у принявшего пакет маршрутизатора. Маршрутизатор в данном случае является ведомым, бит master/slave устанавливается в slave и в структуре данных о соседе устанавливается порядковый номер DD, заданный ведущим маршрутизатором.

  • Биты I и MS не установлены, порядковый номер DD для пакета равен порядковому номеру DD в структуре данных о соседе (подтверждение) и значение Router ID у соседа меньше, чем у принявшего пакет маршрутизатора (данный маршрутизатор является ведущим).

В остальных случаях пакет следует игнорировать.

Exchange

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

  • Если состояние бита MS не соответствует состоянию master/slave для соединения, генерируется событие SeqNumberMismatch для соседа и обработка пакета прекращается.

  • Если бит I установлен, для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается.

  • Если поле Options показывает другой набор дополнительных возможностей OSPF по сравнению с полученным от соседа ранее (записан в поле Neighbor Options структуры данных о соседе), для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается.

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

  • В противном случае для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается.

Loading или Full

В этих состояниях маршрутизатор передает или принимает всю последовательность пакетов DD. Дубликаты возможны только для принимаемых пакетов (см. выше). Поле Options в пакетах должно соответствовать дополнительным возможностям OSPF, ранее показанным соседом (этот параметр хранится в поле опций структуры данных Neighbor). Прием любых других пакетов, включая пакеты с установленным битом I, должен сопровождаться генерацией события SeqNumberMismatch5. Ведущий маршрутизатор должен отбрасывать дубликаты, а ведомый – повторять в ответ передачу последнего пакета DD.

Когда маршрутизатор принимает пакет DD со следующим порядковым номером, этот пакет воспринимается и обрабатывается. Для каждой перечисленной записи LSA проверяется корректность типа LS. Если тип LS неизвестен (т. е., не относится к типам 1 – 5, определенным в данной спецификации) или запись является AS-external-LSA (тип 5), а сосед связан с тупиковой областью, для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается. В остальных случаях маршрутизатор ищет LSA в своей базе данных. Если такой записи нет или имеется более старая версия (см. параграф 13.1), запись LSA помещается в список Link state request для ее последующего запроса (немедленно или спустя некоторое время) с помощью Link State Request.

Для пакетов DD со следующим порядковым номером, кроме перечисленных выше операций, маршрутизатор выполняет еще ряд действий в зависимости от своей роли – ведущий или ведомый:

Master

Увеличивается порядковый номер DD в базе данных о соседе. Если маршрутизатор уже передал все пакеты DD и принятый пакет не содержит флага M, для соседа генерируется событие ExchangeDone. В остальных случаях ведомому маршрутизатору передается новый пакет DD.

Slave

Порядковый номер DD в структуре данных о соседе устанавливается в соответствии с порядковым номером DD в принятом запросе. Ведомый маршрутизатор должен передать в ответ пакет DD. Если в принятом пакете не установлен бит M и переданный ведомым маршрутизатором пакет также не содержит флага M, для соседа генерируется событие ExchangeDone. Отметим, ведомый маршрутизатор всегда генерирует это событие раньше ведущего.

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

В этом параграфе описывается процедура обработки принятых запросов Link State Request (LSR). Принятые пакеты LSR содержат списки LSA, которые сосед хочет получить. Пакеты LSR должны восприниматься, если сосед находится в состоянии Exchange, Loading или Full. Для всех остальных состояний соседа пакеты LSR должны игнорироваться.

Каждая запись LSA, указанная в пакете LSR, должна отыскиваться в базе данных маршрутизатора и копироваться в пакет Link State Update (LSU) для передачи соседу. Эти записи не следует помещать в список Link state retransmission для соседа. Если LSA не удается найти в базе данных, это говорит о наличии ошибки в процессе Database Exchange и ведет к генерации события BadLSReq.

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

В этом параграфе описан процесс передачи соседу пакетов Database Description (DD). Для пакетов DD значение поля Interface MTU устанавливается равным размеру максимальной дейтаграммы IP, которая может быть передана интерфейсом без фрагментации. Общепринятые в Internet значения MTU можно найти в таблице 7-1 работы [Ref22]. Для пакетов DD, передаваемых через виртуальные соединения устанавливается Interface MTU=0.

Дополнительные возможности OSPF (см. параграф 4.5) сообщаются соседу через поле Options пакета DD. Маршрутизатор должен поддерживать такой же набор дополнительных возможностей в процедурах Database Exchange и лавинной рассылки. Если по каким-то причинам дополнительные возможности маршрутизатора изменяются, следует заново выполнить процедуру Database Exchange путем возврата для соседа состояния ExStart. В данной спецификации определяется только одна дополнительная возможность (см. параграфы 4.5 и A.2). Флаг E- устанавливается тогда и только тогда, когда подключенная сеть не относится к тупиковой области. Нераспознанные биты поля Options должны иметь нулевое значение.

Передача пакетов DD зависит от состояния соседа. В состоянии ExStart маршрутизатор передает только пустые пакеты DD с установленными битами I, M и MS, повторяя с интервалом RxmtInterval. В состоянии Exchange пакеты DD реально содержат резюме информации о состоянии каналов, содержащейся в базе данных маршрутизатора. Каждая запись LSA в базе данных области (во время перехода соседа в состояние Exchange) указывается в списке Database summary соседа. Каждый новый пакет DD копирует свой порядковый номер из структуры данных о соседе и после этого описывает начальную часть списка Database summary. Описанные элементы удаляются из списка после подтверждения приема содержащего их пакета.

В состоянии Exchange момент передачи пакетов DD определяется ролью маршрутизатора (ведущий или ведомый):

Master

Пакеты DD передаются, если a) ведомый маршрутизатор подтвердил прием предыдущего пакета DD, указав его номер в отклике, или b) прошло RxmtInterval секунд без подтверждения приема предыдущего пакета (заново передается прежний пакет).

Slave

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

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

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

При состояниях соседа Exchange и Loading список запросов состояний каналов содержит те LSA, которые нужно получить от соседа. Для запроса LSA маршрутизатор сначала отправляет соседу список запросов, помещенный в пакет LSR.

Когда сосед отвечает на эти запросы пакетами Link State Update, соответствующие элементы удаляются из списка запросов и передается новый пакет LSR. Этот процесс продолжается, пока список запросов не будет исчерпан. Записи из списка LSA, которые уже были запрошены, но еще не получены, помещаются в пакет LSR для повторной передачи по истечении интервала RxmtInterval. В любой момент времени должен сохраняться по крайней мере один необработанный пакет LSR.

Когда список запросов исчерпан и сосед находится в состоянии Loading (передан и принят полный набор пакетов DD от соседа) для соседа генерируется событие Loading Done.

            +---+                                         +---+
            |RT1|                                         |RT2|
            +---+                                         +---+

            Down                                          Down
                            Hello(DR=0,seen=0)
                       ------------------------------>
                         Hello (DR=RT2,seen=RT1,...)      Init
                       <------------------------------
            ExStart        D-D (Seq=x,I,M,Master)
                       ------------------------------>
                           D-D (Seq=y,I,M,Master)         ExStart
                       <------------------------------
            Exchange       D-D (Seq=y,M,Slave)
                       ------------------------------>
                           D-D (Seq=y+1,M,Master)         Exchange
                       <------------------------------
                           D-D (Seq=y+1,M,Slave)
                       ------------------------------>
                                     ...
                                     ...
                                     ...
                           D-D (Seq=y+n, Master)
                       <------------------------------
                           D-D (Seq=y+n, Slave)
             Loading   ------------------------------>
                                 LS Request                Full
                       ------------------------------>
                                 LS Update
                       <------------------------------
                                 LS Request
                       ------------------------------>
                                 LS Update
                       <------------------------------
             Full

Рисунок 10. Пример организации отношений смежности.

10.10. Пример

На рисунке 10 показан пример организации смежности. Маршрутизаторы RT1 и RT2 подключены к широковещательной сети. Предполагается, что RT2 играет роль DR и его значение Router ID больше, нежели Router ID для RT1.

Изменения состояния соседа отлеживаются каждым и показаны по краям рисунка.

На начальном этапе примера маршрутизатор RT1 только начинает работу в сети. Маршрутизатор начинает передавать пакеты Hello, хотя он еще не знает о DR и других соседних маршрутизаторах. RT2 слышит эти пакеты (и вводит состояние Init для соседа) и в своем следующем пакете Hello указывает себя как DR и показывает прием пакетов Hello от RT1. Это заставляет RT1 перейти в состояние ExStart, начиная формирование смежности.

RT1 начинает заявлять себя как ведущий маршрутизатор. Когда RT1 видит, что RT2 должен быть ведущим (большее значение Router ID), он переходит в режим ведомого и адаптирует свой порядковый номер DD для соседа. Происходит обмен пакетами DD с запросами от ведущего (RT2) и откликами от ведомого (RT1) маршрутизатора. Эта последовательность пакетов DD завершается когда обе стороны сбрасывают флаг M.

В приведенном примере предполагается, что база данных RT2 полностью актуальна. В этом случае RT2 незамедлительно переходит в состояние Full. RT1 будет переходить в состояние Full после обновления нужных частей своей базы данных. Это осуществляется путем передачи пакетов LSR и приема откликов LSU. Отметим, что ожидание маршрутизатором RT1 завершения приема всего набора пакетов DD от RT2 до передачи пакетов LSR не является обязательным. RT1 может чередовать передачу пакетов LSR и прием пакетов DD.

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

Таблица маршрутов содержит все данные, требуемые для пересылки пакетов IP в направлении адресата. Каждая запись таблицы описывает набор лучших маршрутов к отдельному получателю. При пересылке пакетов данных IP определяется запись таблицы с максимальным соответствием IP-адресу получателя пакета. После этого из выбранной записи берется адрес следующего маршрутизатора (next hop) в направлении адресата. Протокол OSPF также обеспечивает поддержку принятого по умолчанию маршрута (Destination ID = DefaultDestination, Address Mask = 0x00000000). Если существует принятый по умолчанию маршрут, он соответствует всем IP-адресам получателей (хотя любые другие маршруты обеспечивают лучшее соответствие). Поиск маршрута с лучшим соответствием IP-адресу получателя описан в параграфе 11.1.

В каждом маршрутизаторе существует одна таблица маршрутов. Два примера таблиц маршрутизации рассмотрены в параграфах 11.2 и 11.3. Построение таблицы маршрутов описано в главе 16.

В остальной части параграфа описаны поля записей в таблице маршрутов. Первый набор полей описывает адресатов для записи.

Destination Type

Адресатом может быть сеть (network) или маршрутизатор (router). При пересылке пакетов данных IP реально используются только записи для сетей. Связанные с маршрутизаторами записи таблицы применяются только на промежуточных этапах построения таблицы маршрутов.

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

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

Destination ID

Имя или идентификатор адресата в зависимости от значения DestinationType. Для сетей используется связанный с сетью IP-адрес, для маршрутизаторов – OSPFRouterID6.

Address Mask

Маска определена только для сетей и при использовании вместе с адресом IP позволяет определить сетевой диапазон IP-адресов. Для подсетей IP адресную маску называют маской подсети. Маршруты к хостам имеют маску 0xffffffff.

Optional Capabilities

Когда получателем является маршрутизатор, это поле показывает поддерживаемые им дополнительные возможности OSPF. В данной спецификации определена единственная дополнительная возможность – обработка AS-external-LSA. Обсуждение дополнительных возможностей OSPF приведено в параграфе 4.5.

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

Area

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

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

Path-type

Существует 4 типа путей для передачи пакетов адресату: внутридоменные, междоменные, внешние типа 1 и 2 (в порядке снижения предпочтения). Внутридоменные пути используются для адресатов в одной из подключенных к маршрутизатору областей, междоменные пути ведут в другие области OSPF. Определение типа происходит на основе принятых summary-LSA. Внешние пути ведут в другие AS и детектируются на основе принятых AS-external-LSA.

Cost

Стоимость пути к адресату в единицах link state. Для всех путей кроме внешних типа 2 этот параметр описывает стоимость пути в целом. Для внешних путей типа 2 это поле описывает стоимость части пути внутри данной AS. Эта стоимость вычисляется как сумма стоимостей составляющих путь каналов.

Type 2 cost

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

Link State Origin

Применяется только для внутридоменных путей и показывает запись LSA (router-LSA или network-LSA), напрямую указывающую адресата. Например, если адресатом является транзитная сеть, это будет network-LSA транзитной сети. Если адресатом является тупиковая сеть, это будет router-LSA для подключенного к ней маршрутизатора. Записи LSA определяются при расчете дерева кратчайших путей (см. параграф 16.1). Один адресат может указываться множеством LSA, однако схема tie-breaking (разрыв связей) сужает выбор до единственной записи LSA. Поле Link State Origin не используется протоколом OSPF, но применяется при расчете таблицы маршрутов в MOSPF (OSPF Multicast routing extensions).

При наличии множества однотипных путей с равной стоимостью (equal-cost paths – равноценные пути), эти пути сохраняются в одной записи таблицы маршрутов. Равноценные пути различаются следующими полями:

Next hop

Выходной интерфейс маршрутизатора, используемый для пересылки пакетов получателю. В широковещательных, Point-to-MultiPoint и NBMA-сетях поле next hop также включает IP-адрес первого маршрутизатора (если он есть) на пути к адресату.

Advertising router

Имеет смысл только для междоменных и внешних путей и содержит Router ID маршрутизатора, анонсирующего summary-LSA или AS-external-LSA для этого пути.

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

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

До начала просмотра в таблицу должны быть вставлены «отвергнутые» записи для каждого активного диапазона адресов области в маршрутизаторе (см. параграф 3.5). Диапазон считается активным, если он включает по крайней мере одну сеть, доступную внутридоменным путем. Адресатом «отвергнутой» записи служит набор адресов, описываемый связанным с ним активным диапазоном и тип пути для каждой «отвергнутой» записи должен быть междоменным7.

Адресу получателя может соответствовать несколько записей маршрутной таблицы. В таких случаях лучшее соответствие обеспечивает запись таблицы с максимальным совпадением. Иными словами, лучшее совпадение обеспечивается записью с наиболее узким диапазоном IP-адресов8. Например, запись для пары 128.185.1.0, 0xffffff00 задает более точное соответствие, нежели 128.185.0.0, 0xffff0000. Принятый по умолчанию маршрут обеспечивает минимальное соответствие, поскольку он подходит для всех адресатов. Отметим, что для любой отдельной записи в таблице маршрутов может существовать множество путей. В таких случаях расчеты, описанные в параграфах 16.1, 16.2 и 16.4 всегда дают пути наиболее предпочтительного типа (см. главу 11).

Если в таблице не найдено соответствующей адресату записи или максимальное соответствие обеспечивает одна из «отвергнутых» записей, адресат считается недоступным и вместо пересылки пакет отбрасывается, а отправителю возвращается пакет ICMP destination unreachable (адресат недоступен).

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

Таблица 15 Таблица маршрутизации RT6 (областей не задано).

Тип Адресат Область Тип пути Стоимость Next Hop Анонсирующий маршрутизатор
N N1 0 Внутридомен. 10 RT3 *
N N2 0 Внутридомен. 10 RT3 *
N N3 0 Внутридомен. 7 RT3 *
N N4 0 Внутридомен. 8 RT3 *
N Ib 0 Внутридомен. 7 * *
N Ia 0 Внутридомен. 12 RT10 *
N N6 0 Внутридомен. 8 RT10 *
N N7 0 Междоменный 12 RT10 *
N N8 0 Междоменный 10 RT10 *
N N9 0 Междоменный 11 RT10 *
N N10 0 Междоменный 13 RT10 *
N N11 0 Междоменный 14 RT10 *
N H1 0 Междоменный 21 RT10 *
R RT5 0 Междоменный 6 RT5 *
R RT7 0 Междоменный 8 RT10 *
N N12 * Внешн. типа 1 10 RT10 RT7
N N13 * Внешн. типа 1 114 RT5 RT5
N N14 * Внешн. типа 1 14 RT5 RT5
N N15 * Внешн. типа 1 17 RT10 RT7

Вернемся к примеру автономной системы на рисунке 2. В этом примере не задано ни одной области OSPF. Метрика показана только для исходящих интерфейсов. Расчет таблицы маршрутизации для RT6 был описан в параграфе 2.2, а результаты этого расчета приведены в таблице 15. Адресаты в таблице обозначены буквами N (сети), R (маршрутизаторы) и H (хосты).

В этом примере нет равноценных путей, а междоменные пути отсутствуют, поскольку нет областей.

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

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

 

Таблица 16 Таблица маршрутизации RT4 при наличии областей.

Тип Адресат Область Тип пути Стоимость Next Hop Анонсирующий маршрутизатор
N N1 1 Внутридомен. 4 RT1 *
N N2 1 Внутридомен. 4 RT2 *
N N3 1 Внутридомен. 1 * *
N N4 1 Внутридомен. 3 RT3 *
R RT3 1 Внутридомен. 1 * *
N Ib 0 Внутридомен. 22 RT5 *
N Ia 0 Внутридомен. 27 RT5 *
R RT3 0 Внутридомен. 21 RT5 *
R RT5 0 Внутридомен. 8 * *
R RT7 0 Внутридомен. 14 RT5 *
R RT10 0 Внутридомен. 22 RT5 *
R RT11 0 Внутридомен. 25 RT5 *
N N6 0 Междоменный 15 RT5 RT7
N N7 0 Междоменный 19 RT5 RT7
N N8 0 Междоменный 18 RT5 RT7
N N9-N11,H1 0 Междоменный 36 RT5 RT11
N N12 * Внешн. типа 1 16 RT5 RT5, RT7
N N13 * Внешн. типа 1 16 RT5 RT5
N N14 * Внешн. типа 1 16 RT5 RT5
N N15 * Внешн. типа 1 23 RT5 RT7

 

Вернемся к предыдущему примеру, разделив AS на две области OSPF (конфигурация областей показана на рисунке 4). Таблица маршрутизации RT4 будет описана для этой конфигурации. Маршрутизатор RT4 соединен с областью 1 и магистральной областью. Это заставляет RT4 видеть AS как объединение (concatenation) двух графов, показанных в таблицах 6 и 7. Маршруты RT4 показаны в таблице 16.

Маршрутизаторы RT5 и RT7 являются граничными для AS, а RT3, RT4, RT7, RT10 и RT11 – для областей. Отметим, что для маршрутизатора RT3 в таблице две маршрутных записи, поскольку он имеет две области, общие с RT4 (область 1 и магистраль).

Магистральные пути рассчитываются до всех граничных маршрутизаторов областей. Эти пути служат для расчета междоменных маршрутов. Отметим, что все междоменные маршруты связаны с магистралью – это бывает всегда для случаев, когда рассчитывающий маршрутизатор является граничным для области. Маршрутная информация конденсируется на границах областей. В нашем примере предполагается, что область 3 определена так, что сети N9 – N11 и хост H1 находятся на одном маршруте, анонсируемом в магистраль маршрутизатором RT11. Отметим, что стоимость этого пути является максимальной из набора стоимостей отдельных компонент.

Между маршрутизаторами RT10 и RT11 организован виртуальный канал. Без этого канала маршрутизатор RT11 не сможет анонсировать маршрут для сетей N9 – N11 и хоста H1 в магистраль и в таблице RT4 не будет записи для этих сетей.

В данном примере есть два равноценных пути в сеть N12, однако оба пути идут через один маршрутизатор next hop (RT5).

Таблица маршрутизации RT4 улучшается (часть путей становится короче) при организации виртуального канала между RT4 и RT3. Новый виртуальный канал будет сам по себе ассоциироваться с первой записью в таблице граничного маршрутизатора области (RT3 в таблице 16) – внутридоменным путем через область 1. Это будет обеспечивать для виртуального канала стоимость 1. Изменения таблицы маршрутизации в связи с организацией виртуального канала показаны в таблице 17.

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

Таблица 17 Изменения в результате добавления виртуального канала.

Тип Адресат Область Тип пути Стоимость Next Hop Анонсирующий маршрутизатор
N Ib 0 Внутридомен. 16 RT3 *
N Ia 0 Внутридомен. 21 RT3 *
R RT3 0 Внутридомен. 1 * *
R RT10 0 Внутридомен. 16 RT3 *
R RT11 0 Внутридомен. 19 RT3 *
N N9-N11,H1 0 Междоменный 30 RT3 RT11

Каждый маршрутизатор в AS генерирует один или несколько анонсов состояния каналов – LSA. В данной спецификации определены 5 различных типов LSA, описанных в параграфе 4.3. Набор LSA формирует базу данных о состоянии каналов. Каждый тип LSA имеет свое назначение. Router-LSA и network-LSA описывают соединения между маршрутизаторами областей и сетями. Summary-LSA обеспечивает способ сжатого представления маршрутных данных области, а AS-external-LSA дают возможность прозрачного анонсирования внешней маршрутной информации внутри AS.

Каждая запись LSA начинается стандартным 20-байтовым заголовком, описанным ниже.

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

Заголовок LSA содержит поля type, Link State ID и Advertising Router. Комбинация этих трех полей уникальна для LSA.

В автономной системе может одновременно существовать несколько экземпляров LSA. В таких случаях требуется определять последний экземпляр, для чего проверяются поля LS sequence, LS checksum и LS age, содержащиеся в заголовке LSA.

Некоторые типы пакетов OSPF содержат списки LSA. Когда экземпляр не имеет значения, LSA идентифицируются полями LS type, Link State ID и Advertising Router (см. описание пакетов LSR). В остальных случаях принимаются во внимание также поля LS sequence number, LS age и LS. Детальное описание полей заголовка LSA приводится ниже.

12.1.1. Возраст LS

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

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

Поле LS age проверяется маршрутизатором при получении двух экземпляров LSA, имеющих одинаковый порядковый номер и контрольную суммы. Экземпляр с возрастом MaxAge в таких случаях всегда принимается как более новый, что позволяет быстрее удалять старые LSA из области маршрутизации. В остальных случаях, если разница в возрасте превышает MaxAgeDiff, экземпляр с меньшим возрастом принимается как более свежий9 (см. подробности в параграфе 13.1).

12.1.2. Опции

Поле Options в заголовке LSA показывает дополнительные возможности, связанные с LSA. Дополнительные возможности OSPF описаны в параграфе 4.5. Единственная дополнительная возможность, определенная в данной спецификации представляется флагом E в поле Options. Нераспознанные биты поля Options должны иметь нулевые значения.

Бит E представляет OSPF ExternalRoutingCapability и должен устанавливаться во всех LSA, связанных с магистралью и нетупиковыми (non-stub) областями (см. параграф 3.6). Этот флаг должен также устанавливаться для всех AS-external-LSA. Во всех router-LSA, network-LSA и summary-LSA, связанный с тупиковыми областями, флаг должен быть сброшен. Для всех LSA установка бита E производится только в информационных целях и не влияет на расчет таблицы маршрутов.

12.1.3. Тип LS

Поле типа LS определяет формат и назначение LSA. LSA различных типов имеют разные имена (router-LSA, network-LSA и др.). Все типы LSA, определенных в данной спецификации, за исключением AS-external-LSA (LS типа 5), рассылаются лавинным способом через одну область. Анонсы AS-external-LSA рассылаются по всей AS, за исключением тупиковых областей (см. параграф 3.6). Каждый из типов LSA кратко описан в таблице 18.

Таблица 18 Типы анонсов LSA протокола OSPF.

Тип LS LSA Описание
1 router-LSA. Информация о состоянии интерфейсов маршрутизатора (см. параграф 12.4.1).
2 network-LSA Описывает набор маршрутизаторов, подключенных к сети (см. параграф 12.4.2).
3 или 4 summary-LSA Описывает внутридоменные маршруты и обеспечивает возможность конденсации маршрутных данных на границе области. Генерируемые граничными маршрутизаторами областей summary-LSA типа 3 описывают маршруты в сети, а summary-LSA типа 4 – к граничным маршрутизаторам AS.
5 AS-external-LSA Генерируются граничными маршрутизаторами AS и описывают маршруты к адресатам за пределами AS. Эта запись может также содержать маршрут, принятый по умолчанию для AS.

12.1.4. Link State ID

Это поле идентифицирует часть области маршрутизации, которая будет описана в LSA. Значение поля Link State ID зависит от типа LSA (см. таблицу 19).

Для summary-LSA (тип 3) и AS-external-LSA (тип 5) Link State ID дополнительно может содержать несколько host-битов сети-получателя. Например, при генерации AS-external-LSA для сети 10.0.0.0 с маской 255.0.0.0 Link State ID может указывать на любой адрес в диапазоне от 10.0.0.0 до 10.255.255.255 включительно (хотя по возможности следует использовать 10.0.0.0). Установка хост-битов позволяет маршрутизатору генерировать раздельные LSA для двух сетей с одинаковым номером, но разными масками (см. Приложение E).

Таблица 19 Значение Link State ID.

1 Router ID генерирующего маршрутизатора.
2 IP-адрес интерфейса маршрутизатора DR для сети.
3 IP-номер сети получателя.
4 Router ID для граничного маршрутизатора AS.
5 IP-номер сети получателя.

Когда LSA описывает сеть (типы LS 2, 3, 5), IP-номер сети легко определить, используя маску сети/подсети, содержащуюся в LSA, и значение Link State ID. Если LSA описывает маршрутизатор (типы LS 1 и 4), значение Link State ID всегда описывает OSPF Router ID. Для AS-external-LSA (тип 5), описывающих принятый по умолчанию маршрут, Link State ID=DefaultDestination (0.0.0.0).

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

Это поле содержит идентификатор OSPF Router ID породившего LSA маршрутизатора. Для router-LSA это поле совпадает с полем Link State ID. Записи Network-LSA порождаются маршрутизаторами DR, Summary-LSA – граничными маршрутизаторами областей, а AS-external-LSA – граничными маршрутизаторами AS.

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

Порядковый номер трактуется как 32-разрядное целое число со знаком и используется для обнаружения старых LSA и дубликатов. Пространство порядковых номеров линейно упорядочено и больший порядковый номер (при сравнении 32-битовых целых чисел со знаком) соответствует более новой записи LSA. Далее при описании порядковых номеров N будет обозначать 231.

Порядковый номер -N (0x80000000) зарезервирован и не должен использоваться. Значение -N + 1 (0x80000001) является минимальным (следовательно, самым старым) порядковым номером и используется в качестве константы InitialSequenceNumber. Маршрутизатор использует номер InitialSequenceNumber при первой генерации LSA. После этого порядковые номера LSA увеличиваются на 1 при генерации каждого нового экземпляра LSA. При достижении порядкового номера N – 1 (0x7fffffff или MaxSequenceNumber), сначала нужно удалить текущий экземпляр LSA из домена маршрутизации. Для этого используется принудительное старение (prematurely aging) LSA (см. параграф 14.1) и повторная лавинная рассылка. После подтверждения этой рассылки всеми смежными маршрутизаторами возможна генерация новой записи с порядковым номером InitialSequenceNumber.

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

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

Это поле включает контрольную сумму записи LSA без учета поля LS age для того, чтобы можно было увеличивать поле возраста без пересчета контрольной суммы. При расчете контрольных сумм используется тот же алгоритм, который применяется для дейтаграмм ISO без организации соединений – его часто называют алгоритмом Флэтчера. Этот алгоритм описан в работе [Ref6] (Annex B). Заголовок LSA содержит также размер LSA в байтах без учета поля LS age (два байта) для вычисления контрольной суммы.

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

Контрольная сумма LSA проверяется в двух случаях: a) при получении пакета Link State Update и b) во время «состаривания» базы данных. Обнаружение ошибок в контрольной сумме ведет к различным ситуациям, описанным в главах 13 и 14.

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

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

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

Базы данных каждой области всегда обрабатываются раздельно. Расчет кратчайших путей выполняется отдельно для каждой области (см. главу 16). Лавинная рассылка компонент базы данных области ведется только в пределах области. И, наконец, при организации отношений смежности между двумя маршрутизаторами синхронизируются только базы данных общей области.

База данных области состоит из router-LSA, network-LSA и summary-LSA (все они перечислены в структуре данных области). Для нетупиковых областей в базу данных включаются также AS-external-LSA (см. параграф 3.6).

Реализация протокола OSPF должна обеспечивать возможность доступа к отдельным частям базы данных области. Эта функция просмотра основана на полях LS type, Link State ID и Advertising Router11. Поиск будет давать один экземпляр (самый новый) каждой записи LSA в базе данных. Функции поиска в базе данных используются процедурой лавинной рассылки LSA (глава 13) и при расчете таблицы маршрутов (глава 16). Кроме того, используя эту функцию, маршрутизатор может определить не он ли породил данную запись LSA и (если он) с каким порядковым номером.

Запись LSA добавляется в базу данных маршрутизатора, если a) она получена в процессе лавинной рассылки (глава 13) или b) происходит о данного маршрутизатора (параграф 12.4). LSA удаляются из базы данных маршрутизатора, если a) получен более новый экземпляр в процессе лавинной рассылки (глава 13), b) маршрутизатор сам генерирует новый экземпляр LSA (параграф 12.4) или c) LSA удаляется из домена маршрутизации в результате старения (глава 14). При удалении LSA из базы данных, эта запись должна удаляться также из списков Link state retransmission всех соседей (см. главу 10).

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

Для обратной совместимости с предыдущими версиями OSPF [Ref9], в router-LSA, summary-LSA и AS-external-LSA может включаться информация, связанная с TOS. Представление TOS в OSPF LSA описано в таблице 20, содержащей коды OSPF для представления полей TOS (определены в работе [Ref12]) пакетов IP. В OSPF используется десятичное представление, а в заголовках IP применяются битовые поля TOS, описанные в [Ref12].

Таблица 20 Представление TOS в OSPF.

Код OSPF Значения TOS RFC 1349
0 0000 нормальное обслуживание
2 0001 минимальная оплата
4 0010 максимальная надежность
6 0011
8 0100 максимальная пропускная способность
10 0101
12 0110
14 0111
16 1000 минимальная задержка
18 1001
20 1010
22 1011
24 1100
26 1101
28 1110
30 1111

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

В каждой области OSPF маршрутизатор будет генерировать несколько типов LSA. Каждый маршрутизатор генерирует router-LSA. Если маршрутизатор является DR для любой из сетей области, он будет генерировать network-LSA для этой сети.

Граничные маршрутизаторы областей генерируют одну запись summary-LSA для каждого адресата с междоменным маршрутом. Граничные маршрутизаторы AS генерируют одну запись AS-external-LSA для каждого известного адресата за пределами AS. Адресаты анонсируются по одному, поэтому изменение отдельного маршрута не требует повтора лавинной рассылки для всего набора маршрутов. В процессе лавинной рассылки один пакет LSU может включать множество LSA.

В качестве примера рассмотрим маршрутизатор RT4 на рисунке 4, являющийся граничным в области 1 и связанный с магистралью. Маршрутизатор RT4 генерирует 5 разных LSA в магистраль (router-LSA и summary-LSA для каждой из сетей N1-N4). Маршрутизатор RT4 будет также порождать 8 различных LSA для области 1 (router-LSA и семь summary-LSA, показанных в таблице 6). Если RT4 будет выбран DR для сети N3, он будет генерировать в область 1 network-LSA для N3.

Маршрутизатор RT5 будет генерировать AS-external-LSA (для каждой из сетей N12 – N14). Эти записи будут рассылаться в лавинном режиме по всей AS, поскольку ни одна из областей не предполагается тупиковой. Однако если область 3 указать как тупиковую, AS-external-LSA для сетей N12-N14 не будут рассылаться в область 3 (см. параграф 3.6). Взамен этого маршрутизатор RT11 будет генерировать запись summary-LSA с принятым по умолчанию маршрутом, которая будет рассылаться в области 3 (см. параграф 12.4.3). В результате все внутренние маршрутизаторы области 3 будут передавать внешний трафик маршрутизатору RT11.

При создании нового экземпляра LSA увеличивается порядковый номер, устанавливается LS age=0, вычисляется контрольная сумма и LSA добавляется в базу данных, после чего происходит лавинная рассылка через соответствующие интерфейсы. Включение LSA в базу данных подробно описано в параграфе 13.2, а параграф 13.3 посвящен лавинной рассылке новых экземпляров LSA.

Ниже перечислены 10 событий, которые могут приводить к генерации новых экземпляров LSA:

  1. Поле LS age одной из порожденных маршрутизатором LSA достигло значения LSRefreshTime. В таких случаях генерируется новый экземпляр LSA, несмотря на отсутствие изменений одержимого LSA (кроме заголовка). Это гарантирует периодическое обновление всех LSA и повышает устойчивость алгоритма link state. LSA, описывающие только недоступных адресатов, не должны обновляться и их нужно удалять из области маршрутизации (см. параграф 14.1).

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

  1. Изменилось состояние интерфейса (см. параграф 9.1) и может потребоваться генерация нового экземпляра router-LSA.

  2. Сменился маршрутизатор DR. Требуется генерация нового анонса router-LSA. Если данный маршрутизатор стал DR, нужно генерировать новые network-LSA. Если данный маршрутизатор перестал быть DR, все network-LSA, которые он мог породить для сети, должны быть удалены из домена маршрутизации (см. параграф 14.1).
  3. Один из соседей перешел в состояние FULL или покинул его. Это требует генерации новых экземпляров router-LSA. Если данный маршрутизатор является DR для подключенной сети, он должен породить новый экземпляр network-LSA.

Следующие 4 события относятся только к граничным маршрутизаторам областей:

  1. В таблице маршрутизации был изменен/добавлен/удален внутридоменный маршрут и может потребоваться генерация нового экземпляра summary-LSA (для этого маршрута) в каждую подключенную область (возможно и магистральную).

  2. В таблице маршрутизации был изменен/добавлен/удален междоменный маршрут и может потребоваться генерация нового экземпляра summary-LSA (для этого маршрута) в каждую подключенную область (кроме магистральной).

  3. К области подключен новый маршрутизатор и он должен породить summary-LSA в подключенную недавно область для всех имеющих отношение внутридоменных и междоменных маршрутов в таблице маршрутизатора (см. параграф 12.4.3).
  4. Изменилось состояние одного из маршрутизаторов с настроенным виртуальным каналом и может потребоваться генерация новых router-LSA в транзитную область виртуального канала (см. описание бита V записи router-LSA в параграфе 12.4.1), а также в магистраль.

Последние 2 события относятся только к граничным маршрутизаторам AS (включая бывшие):

  1. Изменился внешний маршрут, полученный от другого протокола маршрутизации (например, BGP) и от граничного маршрутизатора AS может потребоваться генерация нового экземпляра AS-external-LSA.

  2. Маршрутизатор перестал быть граничным в AS (возможно после перезагрузки) и требуется удаление всех порожденных ранее AS-external-LSA (для этого используется принудительное старение, описанное в параграфе 14.1).

Подробное описание структуры всех типов LSA приведено ниже. В следующих разделах описывается содержимое LSA, а 20-байтовые заголовки LSA описаны в параграфе 12.1.

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

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

                  ....................................
                  . 192.1.2                   Area 1 .
                  .     +                            .
                  .     |                            .
                  .     | 3+---+1                    .
                  .  N1 |--|RT1|-----+               .
                  .     |  +---+      \              .
                  .     |              \  _______N3  .
                  .     +               \/       \   .  1+---+
                  .                     * 192.1.1 *------|RT4|
                  .     +               /\_______/   .   +---+
                  .     |              /     |       .
                  .     | 3+---+1     /      |       .
                  .  N2 |--|RT2|-----+      1|       .
                  .     |  +---+           +---+8    .         6+---+
                  .     |                  |RT3|----------------|RT6|
                  .     +                  +---+     .          +---+
                  . 192.1.3                  |2      .   18.10.0.6|7
                  .                          |       .            |
                  .                   +------------+ .
                  .                     192.1.4 (N4) .
                  ....................................

Рисунок 11. Область 1 с IP-адресами

Формат router-LSA описан в параграфе A.4.2. Первые 20 байтов LSA содержат стандартный заголовок LSA, описанный в параграфе 12.1.

router-LSA относятся к типу 1.

Маршрутизатор также показывает свою принадлежность к граничным маршрутизаторам области или AS, устанавливая биты B или E, соответственно, в router-LSA. Это позволяет сохранять пути к таким маршрутизаторам в таблице для последующей обработки summary-LSA и AS-external-LSA. Бит B должен устанавливаться, если маршрутизатор имеет активные соединения с двумя или более областями, даже если этот маршрутизатор не подключен к магистральной области OSPF. Бит E никогда не должен устанавливаться в router-LSA для тупиковых областей (такие области не могут включать граничные маршрутизаторы AS).

Таблица 21 Описание каналов в router-LSA.

Тип Описание Идентификатор
1 «Точка-точка» Neighbor Router ID
2 Канал в транзитную сеть Адрес интерфейса DR
3 Канал в оконечную сеть Номер IP-сети
4 Виртуальный канал Neighbor Router ID

В дополнение к этому маршрутизатор устанавливает бит V в router-LSA для области A тогда и только тогда, когда маршрутизатор является конечной точкой для одного или нескольких виртуальных каналов с полной смежностью, использующих область A в качестве транзитной. Установка бита V позволяет другим маршрутизаторам области A обнаруживать поддерживаемый областью трафик (см. TransitCapability в главе 6).

Router-LSA описывает работающие соединения (интерфейсы или каналы) маршрутизатора с областью. Тип каждого канала зависит от подключенной сети. Каждый канал имеет также идентификатор Link ID, используемый в качестве обозначения объекта на другой стороне соединения. В таблице 21 приведены значения полей Type и Link ID.

Для каждого канала используется также поле Link Data, содержащее 32 бита дополнительной информации о канале. Для каналов в транзитные сети, и адресуемых соединений «точка-точка» это поле содержит IP-адрес интерфейса маршрутизатора (он нужен для расчета таблицы маршрутов, описанного в параграфе 16.1.1). Для каналов в тупиковые сети это поле задает маску тупиковой сети. Для безадресных каналов point-to-point поле Link Data должно содержать значение MIB-II unnumbered-интерфейса – ifIndex [Ref8].

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

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

  • Если подключенная сеть не относится к области A, в LSA не добавляется каналов и проверяется следующий интерфейс.
  • Если интерфейс находится в состоянии Down, каналов в LSA не добавляется.
  • Для интерфейсов в состоянии Loopback добавляется канал типа 3 (тупиковая сеть), если этот интерфейс не ведет в безадресную сеть point-to-point. В полу Link ID должен помещаться IP-адрес интерфейса, а в поле Link Data – маска 0xffffffff (маршрут к хосту). Стоимость канала равна 0.
  • В остальных случаях в router-LSA добавляется описание канала в зависимости от типа интерфейса OSPF. Описание канала для интерфейсов point-to-point приведено в параграфе 12.4.1.1, для виртуальных соединений – в параграфе 12.4.1.2, для широковещательных и NBMA-интерфейсов – в 12.4.1.3 и для интерфейсов Point-to-MultiPoint – в параграфе 12.4.1.4.

После рассмотрения всех интерфейсов маршрутизатора в router-LSA добавляются соединения с хостами путем проверки подключенных хостов, относящихся к области A. Маршруты хостам относятся к типу 3 (тупиковая сеть), поле Link ID содержит IP-адрес хоста, Link Data – маску 0xffffffff, а стоимость маршрута должна быть больше 0 (см. параграф C.7).

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

Для интерфейсов point-to-point в router-LSA добавляется одно или несколько описаний каналов:

  • Если соседний маршрутизатор является полностью смежным, добавляется канал типа 1 (point-to-point). Поле Link ID должно содержать Router ID соседнего маршрутизатора. Для адресуемых сетей point-to-point поле Link Data должно содержать IP-адрес интерфейса, а для unnumbered-сетей – значение ifIndex (MIB-II [Ref8]). Стоимость канала должна совпадать с выходной стоимостью интерфейса point-to-point.
  • В дополнение к этому, если интерфейс находится в состоянии Point-to-Point (независимо от состояния соседнего маршрутизатора), должен добавляться канал типа 3 (тупиковая сеть). Этот тупиковый канал может принимать две формы:

Опция 1

Предполагая, что IP-адрес соседнего маршрутизатора известен, устанавливаем для поля LinkID (тип 3) значение этого адреса IP, в поле LinkData помещаем маску 0xffffffff (маршрут к хосту), а стоимость устанавливаем больше нуля12.

Опция 2

Если для канала «точка-точка» выделена подсеть, устанавливаем в поле LinkID типа 3 IP-адрес подсети, в поле LinkData – ее маску и задаем положительное значение для стоимости13.[16]

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

Для широковещательных и NBMA-интерфейсов в router-LSA добавляется одно описание канала:

  • Если интерфейс находится в состоянии Waiting, добавляется канал типа 3 (тупиковая область), поле Link ID содержит IP-номер подключенной сети, Link Data – маску сети, а стоимость совпадает с выходной стоимостью интерфейса.
  • Для остальных случаев должен быть известен выделенный маршрутизатор DR для подключенной сети. Если маршрутизатор является полностью смежным с DR или сам является DR и имеет полностью смежный маршрутизатор, добавляется канал типа 2 (транзитная сеть), поле Link ID содержит IP-адрес интерфейса DR (возможно интерфейс данного маршрутизатора), Link Data содержит IP-адрес интерфейса данного маршрутизатора, а стоимость совпадает с выходной стоимостью для интерфейса. Во всех прочих случаях добавляется один канал как для описанного выше состояния Waiting.
12.4.1.3. Описание виртуальных соединений

Для виртуальных каналов описание добавляется в router-LSA только при полной смежности виртуальных соседей. В таких случаях добавляется канал типа 4 (виртуальный), Link ID = Router ID для виртуального соседа, Link Data содержит IP-адрес интерфейса, связанного с виртуальным каналом, а стоимость совпадает со стоимостью виртуального канала, рассчитанной при создании таблицы маршрутизации (глава 15).

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

Для интерфейсов Point-to-MultiPoint в router-LSA добавляется один или несколько каналов:

  • Добавляется один канал типа 3 (тупиковая сеть), Link ID содержит IP-адрес интерфейса данного маршрутизатора, Link Data = 0xffffffff (маска хоста), а стоимость равна нулю.
  • Для каждого полностью смежного соседа, связанного с интерфейсом, добавляется канал типа 1 (point-to-point), Link ID = Router ID соседнего маршрутизатора, поле Link Data содержит IP-адрес интерфейса, а стоимость равна выходной стоимости для интерфейса.
12.4.1.5. Примеры router-LSA

Рассмотрим анонсы router-LSA, генерируемые RT3 (см. рисунок 4). Область, содержащая RT3 (Area 1) с реальными сетевыми адресами показана на рисунке 11. Предположим, что последний байт адреса всех интерфейсов маршрутизатора RT3 равен 3 (адреса 192.1.1.3 и 192.1.4.3) и в других маршрутизаторах используется аналогичная схема адресации. Кроме того, предположим, что все соединения функционируют и в качестве Router ID используется меньший из IP-адресов интерфейсов.

RT3 генерирует два анонса router-LSA – для области 1 и для магистрали. Предположим, что маршрутизатор RT4 выбран в качестве DR для сети 192.1.1.0. Анонс router-LSA маршрутизатора RT3 для области 1 при оговоренных условиях показан ниже. Он показывает, что RT3 имеет два соединения с областью 1 – одно в транзитную сеть 192.1.1.0 и другое в тупиковую сеть 192.1.4.0. Отметим, что транзитная сеть идентифицируется IP-адресом интерфейса DR (т. е., Link ID = 192.1.1.4 – адрес интерфейса DR-маршрутизатора RT4 в сеть 192.1.1.0). Отметим также, что RT3 является граничным маршрутизатором области.

; router-LSA маршрутизатора RT3 для области 1
LSage = 0 ;всегда верно при создании
Options = (E-bit) ;
LS type = 1 ;показывает router-LSA
Link State ID = 192.1.1.3 ;Router ID для RT3
Advertising Router = 192.1.1.3 ;Router ID для RT3
bitE = 0 ;не является граничным для AS
bitB = 1 ;граничный маршрутизатор области
#links = 2
   LinkID = 192.1.1.4   ;IP-адрес интерфейса DR
   LinkData = 192.1.1.3 ;IP-адрес интерфейса RT3 в сеть
   Type = 2             ;соединение с транзитной сетью
# TOS metrics = 0
   metric = 1
   LinkID = 192.1.4.0     ;IP-номер сети
   Link Data = 0xffffff00 ;маскасети
   Type = 3               ;соединение с тупиковой сетью
# TOS metrics = 0
   metric = 2

Далее показан анонс router-LSA маршрутизатора RT3 для магистрали. Он говорит, что RT3 имеет одно соединение с магистралью через безадресный канал point-to-point к маршрутизатору RT6. Показано также что RT3 является граничным для области.

;router-LSA маршрутизатора RT3 для магистрали
LSage = 0                      ;всегда верно при создании
Options = (E-bit)              ;
LS type = 1                    ;показывает router-LSA
Link State ID = 192.1.1.3      ;Router ID для RT3
Advertising Router = 192.1.1.3 ;Router ID для RT3
bitE = 0                       ;не является граничным для AS
bitB = 1                       ;граничный маршрутизатор области
#links = 1
   LinkID = 18.10.0.6        ;RouterID соседнего маршрутизатора
   LinkData = 0.0.0.3        ;MIB-IIifIndex для канала «точка-точка»
   Type = 1                  ;соединение с маршрутизатором
# TOS metrics = 0
   metric = 8

12.4.2. LSA для сети

Анонсы network-LSA генерируются для каждой транзитной широковещательной или NBMA-сети (транзитной считается сеть с числом маршрутизаторов не менее 2) и описывает все маршрутизаторы, подключенные к сети. Эти анонсы порождаются маршрутизатором DR для сети. Для генерации LSA маршрутизатор DR должен иметь полную смежность по крайней мере с одним маршрутизатором сети. Анонсы network-LSA рассылаются в лавинном режиме по области, содержащей транзитную сеть, не выходя за пределы области. В network-LSA перечисляются маршрутизаторы полностью смежные с DR и каждый такой маршрутизатор идентифицируется OSPF Router ID. Маршрутизатор DR также содержится в списке.

Идентификатор Link State ID для network-LSA совпадает с IP-адресом интерфейса DR. Это значение после применения маски подсети, которая также включена в network-LSA дает номер IP-сети. Маршрутизатор, который утратил роль DR для сети, должен уничтожить ранее созданные network-LSA, которые больше не могут использоваться при расчете таблицы маршрутов. Это осуществляется с помощью принудительного увеличения возраста LSA до значения MaxAge и новой лавинной рассылки (см. параграф 14.1). Кроме того, в редких случаях, когда изменяется Router ID, все network-LSA с прежним значением Router ID также должны уничтожаться. Поскольку маршрутизатор может не знать о существовании с другим Router ID, эти network-LSA идентифицируются значением Link State ID, совпадающим с IP-адресом интерфейса маршрутизатора и полем Advertising Router, имеющим такое же значение и не совпадающим с текущим значением Router ID (см. параграф 13.4).

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

Вернемся к примеру сети на рисунке 4. Анонсы Network-LSA генерируются для сети N3 в области 1, сетей N6 и N8 в области 2 и сети N9 в области 3. Предположим, что RT4 выбран в качестве DR для сети N3 – в этом случае маршрутизатор RT4 породит анонс network-LSA для сети N3, показанный ниже (см. распределение адресов на рисунке 11):

;Network-LSA для сети N3
LSage = 0 ;всегда верно при создании
Options = (E-bit) ;
LS type = 2 ;указывает network-LSA
Link State ID = 192.1.1.4 ;IP-адрес DR
Advertising Router = 192.1.1.4 ;Router ID для RT4
Network Mask = 0xffffff00
Attached Router = 192.1.1.4 ;Router ID
Attached Router = 192.1.1.1 ;Router ID
Attached Router = 192.1.1.2 ;Router ID
Attached Router = 192.1.1.3 ;Router ID

12.4.3. Summary-LSA

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

Генераторами Summary-LSA являются граничные маршрутизаторы областей. Точные маршруты для анонсирования в область определяются проверкой структуры маршрутной таблицы (см. главу 11) в соответствии с описанным ниже алгоритмом. Отметим, что в магистральную область анонсируются только внутридоменные маршруты, а в остальные области могут анонсироваться и междоменные маршруты.

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

  • В качестве Destination Type анонсов summary-LSA могут служить только сети и граничные маршрутизаторы AS. Если в записи таблицы маршрутов в качестве адресата указан граничный маршрутизатор области, обработка записи заканчивается.
  • Внешние маршруты AS никогда не анонсируются в summary-LSA. Если запись таблицы включает внешний путь типа 1 или 2, обработка записи на этом завершается.

  • Далее, если областью, связанной с набором путей, является сама область A, для этого маршрута не создается summary-LSA14.

  • Далее, если связанные с записью маршрутизаторы nexthop относятся к области A, для маршрута не создается summary-LSA15 (это является логическим эквивалентом splithorizon в алгоритмах DistanceVector).

  • Далее, если стоимость пути для записи не меньше значения LSInfinity, summary-LSA не создается для такого маршрута.

  • В остальных случаях, если адресатом является граничный маршрутизатор AS, анонс summary-LSA должен генерироваться тогда и только тогда, когда запись таблицы маршрутов описывает предпочтительный путь к граничному маршрутизатору AS (см. шаг 3 в параграфе 16.4). Если это так, для адресата генерируется summary-LSA типа 4, в которой поле Link State ID содержит Router ID граничного маршрутизатора AS, а метрика равна стоимости маршрута. Отметим, что такие LSA не должны генерироваться, если область A указана как тупиковая.

  • В противном случае Destination type указывает сеть. Для междоменных маршрутов создается summary-LSA типа 3, поле Link State ID содержит адрес сети (при необходимости Link State ID может включать один или несколько битов адреса хоста, как сказано в Приложении E) и метрика равна стоимости маршрута в таблице.

  • Последним случаем остается внутридоменный маршрут в сеть. Это означает, что указанная в маршруте сеть относится к области, напрямую подключенной к маршрутизатору. В общем случае эта информация может быть сжата до включения в summary-LSA. Помните, что область имеет список диапазонов адресов, каждый элемент которого содержи пару [адрес, маска] и данные о состоянии (Advertise или DoNotAdvertise). Для каждого диапазона создается по крайней мере один анонс summary-LSA типа 3. Когда для состояния диапазона указано Advertise (анонсировать), генерируется summary-LSA типа 3, поле Link State ID содержит диапазон адресов (при необходимости в Link State ID могут включаться биты из «адреса хоста», как описано в Приложении E), а стоимость равна наибольшей из стоимостей сетей-компонент. Для состояния DoNotAdvertise генерация summary-LSA типа 3 не используется и сети-компонеты остаются скрытыми для других областей.

  • По умолчанию, если сеть не содержит указанного явно диапазона адресов, генерируются summary-LSA типа 3, в которых поле LinkStateID содержит адрес сет (при необходимости могут включаться биты из адреса хоста, как описано в Приложении E), а метрика совпадает со стоимостью маршрута в таблице.

Если область может поддерживать транзитный трафик (TransitCapability = TRUE), маршрутная информация о магистральных сетях не должна сжиматься до резюмирования в область. Не должны также подавляться анонсы магистральных сетей в область. Иными словами, заданные для магистрали диапазоны адресов должны игнорироваться при генерации summary-LSA в транзитные области.

Если маршрутизатор анонсирует summary-LSA для недоступного адресата, он должен удалить такие LSA из домена маршрутизации, устанавливая для них возраст MaxAge и повторяя лавинную рассылку (см. параграф 14.1). Также и в случаях, когда адресат по-прежнему доступен, но, тем не менее, не может больше анонсироваться согласно описанной выше процедуре (например, сейчас это междоменный маршрут, который при использовании был внутридоменным маршрутом, связанным с той или иной немагистральной областью – такой маршрут не может больше анонсироваться в магистраль), анонсы LSA должны удаляться из домена.

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

Описанный в параграфе 12.4.3 алгоритм является необязательным, если область A является тупиковой. Граничные маршрутизаторы областей, подключенные к тупиковым областям могут генерировать summary-LSA в эти области, согласно алгоритму, описанному в параграфе 12.4.3, или создавать только подмножество summary-LSA, для задания которого можно использовать параметры конфигурации. Снижение числа генерируемых LSA уменьшает базу каналов тупиковой области и снижает потребности в ресурсах маршрутизатора. Однако, пропуск LSA может приводить к неоптимальной маршрутизации между областями.

Как сказано в параграфе 12.4.3, summary-LSA типа 4 (ASBR-summary-LSA) никогда не генерируются в тупиковые области.

В тупиковых областях вместо импортированных внешних маршрутов каждый граничный маршрутизатор области генерирует в область default summary-LSA. Поле Link State ID в таких summary-LSA содержит значение DefaultDestination, а метрика задается для каждой области конфигурационным параметром StubDefaultCost. Отметим, что не требуется задавать одинаковые значения StubDefaultCost на всех граничных маршрутизаторах тупиковой области.

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

Вернемся к конфигурации областей на рисунке 4. Маршрутизаторы RT3, RT4, RT7, RT10 и RT11 являются граничными для областей и, следовательно, порождают summary-LSA. Рассмотрим в частности маршрутизатор RT4. таблица маршрутов для него рассчитана в качестве примера в параграфе 11.3. RT4 генерирует summary-LSA в магистраль и область 1. В магистраль RT4 генерирует раздельные LSA для каждой из сетей N1 – N4, в область 1 – раздельные LSA для сетей N6 – N8 и граничных маршрутизаторов AS (RT5, RT7). Он также собирает маршруты к хостам Ia и Ib в один анонс summary-LSA. Наконец, маршруты в сети N9, N10, N11 и к хосту H1 анонсируются одним summary-LSA. Эта конденсация изначально выполняется маршрутизатором RT11.

Эти LSA показаны в таблицах 6 и 7. Ниже показаны два анонса summary-LSA, генерируемых маршрутизатором RT4. Реальные адреса для сетей и маршрутизаторов показаны на рисунке 11.

; Summary-LSA для сети N1 генерируется маршрутизатором RT4 в магистраль
LSage = 0 ;всегда верно при создании
Options = (E-bit) ;
LS type = 3 ;тип 3 - summary-LSA
Link State ID = 192.1.2.0 ;IP-номерсети N1
Advertising Router = 192.1.1.4 ;Идентификатор RT4
metric = 4

; Summary-LSA для граничного маршрутизатора ASRT7
; генерируется маршрутизатором RT4 в область 1
LSage = 0 ; всегда верно при создании
Options = (E-bit) ;
LS type = 4 ;тип 4 - summary-LSA
Link State ID = Router ID RT7
Advertising Router = 192.1.1.4 ;Идентификатор RT4
metric = 14

12.4.4. AS-external-LSA

Анонсы AS-external-LSA описывают маршруты ко внешним (по отношению к AS) адресатам. Большинство AS-external-LSA описывает маршруты к конкретным внешним адресатам – в таких случаях поле Link State ID содержит IP-номер сети получателя address (при необходимости можно включать и часть битов «номера хоста», как описано в Приложении E). Для описания принятого по умолчанию маршрута для AS может использоваться AS-external-LSA с Link State ID = DefaultDestination (0.0.0.0). Анонсы AS-external-LSA генерируются граничными маршрутизаторами AS, которые порождают по одному анонсу AS-external-LSA для каждого внешнего маршрута, полученного от другого протокола (типа BGP) или заданного конфигурацией.

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

Для внешних маршрутов может использоваться два типа метрики. Метрика типа 1 сравнима с внутренней метрикой link state, а метрика типа 2 заведомо больше стоимости любого пути внутри AS.

Если маршрутизатор анонсирует AS-external-LSA для адресата, ставшего недоступным, он должен удалить LSA из домена маршрутизации путем установки для них возраста MaxAge и повтора лавинной рассылки (см. параграф 14.1).

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

В приведенном на рисунке 4 примере AS имеются два граничных маршрутизатора AS – RT5 и RT7. Маршрутизатор RT5 генерирует три AS-external-LSA для сетей N12 – N14, а RT7 – два анонса для сетей N12 и N15. Предположим, что маршрутизатор RT7 узнал о пути в сеть N12 от протокола BGP и хочет анонсировать в AS метрику типа. Тогда RT7 будет генерировать для сети N12 анонс:

; AS-external-LSA для сети N12, генерируется маршрутизатором RT7
LSage = 0 ;всегда верно при создании
Options = (E-bit) ;
LS type = 5 ;AS-external-LSA
Link State ID = IP-номердлясети N12
Advertising Router = Router ID RT7
bitE = 1 ;метрика типа 2
metric = 2
Forwarding address = 0.0.0.0

Значение 0.0.0.0 в качестве адреса пересылки показывает, что пакеты для внешних адресатов должны пересылаться анонсирующему маршрутизатору OSPF (RT7). В некоторых случаях такое решение нежелательно. Рассмотрим пример на рисунке 12, содержащий три маршрутизатора OSPF (RTA, RTB and RTC), подключенных к общей сети. Только маршрутизатор RTA обменивается информацией BGP с маршрутизатором RTX, не относящимся к OSPF. В этом случае RTA должен порождать AS-external-LSA для адресатов, полученных от RTX. Используя поле адреса пересылки в AS-external-LSA, RTA может задать пересылку пакетов в эти адреса непосредственно через RTX. Если это не использовать, маршрутизаторы RTB и RTC будут добавлять лишний интервал.

Отметим, что ненулевой адрес пересылки должен указывать на маршрутизатор в другой AS. Это поле может также содержать принятый по умолчанию адрес. Например, маршрутизатор RTA может указать, что все внешние пакеты должны по умолчанию пересылаться маршрутизатору RTX (BGP peer). Анонс AS-external-LSA для такого случая показан ниже. Отметим, что Link State ID = DefaultDestination.

;принятый по умолчанию маршрут от RTA
;пакеты пересылаются через RTX
LSage = 0          ;всегда верно при создании
Options = (E-bit)  ;
LS type = 5        ;AS-external-LSA
Link State ID = DefaultDestination ;маршрутпоумолчанию
Advertising Router = Router ID для RTA
bitE = 1 ;метрика типа 2
metric = 1
Forwarding address = IP-адрес RTX

Предположим, что маршрутизаторы RTA и RTB также обмениваются BGP-информацией с RTX. В таком случае RTA и RTB будут генерировать одинаковые анонсы AS-external-LSA. Если в этих анонсах будет совпадать метрика, они будут эквивалентны функционально, поскольку указывают одинаковых получателей и общий адрес пересылки (RTX). Это ведет к простому дублированию работы. Если только один из маршрутизаторов (RTA или RTB) будет генерировать набор AS-external-LSA, маршрутизация не изменится, а размер базы данных уменьшится. Однако в таких случаях нужно точно указывать, какой из маршрутизаторов будет порождать LSA (иначе этого может не сделать ни один из них или начнется поочередная генерация). Для выбора маршрутизатора используется следующее правило – если два доступных один для другого маршрутизатора генерируют функционально эквивалентные AS-external-LSA (совпадают адресаты, стоимость и ненулевой адрес пересылки), используются LSA от маршрутизатора с большим значением OSPF Router ID. Другой маршрутизатор должен удалить свои LSA, как описано в параграфе 14.1.


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

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

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

4 При смене DR достаточно типичным случаем для соседа в этом состоянии будет передача пакета DD для маршрутизатора; это означает наличие кратковременного рассогласования тождественности DR.

5 Для маршрутизатора возможна рассинхронизация полных отношений смежности путем перехода назад в состояние ExStart. Это заставит смежный маршрутизатор обрабатывать сообщение SeqNumberMismatch и вернуться в состояние ExStart.

6 Пространство адресов IP-сетей и значений OSPF Router ID могут перекрываться, т. е., IP-адрес сети в 32-битовом представлении может совпадать с Router ID какого-либо из маршрутизаторов.

7 “Отвержение” областей требуется для беспетлевого резюмирования маршрутов на границе области.

8 При соответствии получателю двух диапазонов адресов предполагается, что один диапазон уже другого. Чтобы избавиться от этого допущения можно использовать несвязные (Non-contiguous) маски подсетей, но такие маски протокол OSPF не поддерживает.

9 MaxAgeDiff является архитектурной константой и показывает максимальное расхождение возраста (в секундах), которое может возникнуть для одного экземпляра LSA при лавинной рассылке в домене маршрутизации. Если разница в возрасте двух LSA превышает это значение, предполагается, что это два разных экземпляра LSA. Это может происходить в тех случаях, когда маршрутизатор был перезагружен и потерял информацию о порядковом номере предыдущей записи LSA (см. параграф 13.4).

10 Когда контрольные суммы двух LSA различаются, предполагается, что это два разных экземпляра. Это может быть следствием перезагрузки маршрутизатора или потери маршрутизатором данных о предыдущем порядковом номере LSA. Если порядковые номера двух LSA совпадают, невозможно определить, которая из записей новее. Однако если в качестве новой будет принята некорректная запись LSA, генерирующий их маршрутизатор просто будет порождать другой экземпляр (см. параграф 13.4).

11 Существует ситуация, когда поиск должен основываться на частичной информации. Это происходит при расчете таблицы маршрутов, когда нужно найти network-LSA, основываясь исключительно на Link State ID. Результаты поиска однозначны, поскольку не существует двух two network-LSA с одинаковыми полями Link State ID.

12 Это способ представляет канал «точка-точка» в соответствии с RFC 1583. Данный способ обеспечивает ряд преимуществ: a) не требуется выделения подсети для каналов «точка-точка», b) пакеты, адресованные интерфейсу point-to-point, будут реально приниматься через интерфейс (это полезно для диагностики) и c) поддерживается загрузка соседей через сеть (network bootstrapping) без необходимости поддержки bootstrap-загрузки реализацией протокола OSPF.

13 Это представление каналов point-to-point более традиционно и используется протоколами типа RIP.

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

15 Это требование актуально только для случаев, когда немагистральная область A поддерживает транзитные данные (т. е., .TransitCapability = TRUE). Например, в конфигурации, показанной на рисунке 4, область 2 может поддерживать транзитный трафик за счет существования виртуального канала между RT10 и RT11. В результате от маршрутизатора RT11 требуется генерация только одного анонса summary-LSA в область 2 (сколлапсировавший адресат N9-N11,H1), поскольку все другие подходящие маршруты RT11 имеет следующий маршрутизатор в самой области 2 и должны анонсироваться только граничными маршрутизаторами других областей (в примере – RT10 и RT7).

Часть 3

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Or