RFC 2328 (часть 3)

Please enter banners and links.

image_print

Часть 2

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

Пакет Link State Update (LSU) обеспечивают механизм лавинной рассылки LSA и могут содержать несколько различных LSA. Пакеты рассылаются лавинным способом на один интервал от точки генерации LSA. Для повышения надежности лавинной рассылки требуется раздельное подтверждение для каждого анонса LSA, передаваемое в пакетах Link State Acknowledgment. В одном пакете может содержатся множество раздельных подтверждений.

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

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

Для каждого анонса LSA в пакете LSU выполняются следующие операции:

  1. Проверка контрольной суммы LSA. В случае ошибки LSA отбрасывается с переходом к следующему анонсу в пакете LSU.
  2. Проверка типа LSA. LSA неизвестных типов отбрасываются с переходом к следующему анонсу из пакета LSU. Данная спецификация определяет типы 1 – 5 (см. параграф 4.3).
  3. Если принят анонс AS-external-LSA (тип 5), а область является тупиковой, LSA отбрасывается с переходом к следующему анонсу из пакета LSU. Для AS-external-LSA не используется лавинная рассылка в тупиковые области или через них (см. 3.6).
  4. Если возраст LSA равен MaxAge, а в базе данных маршрутизатора нет текущего экземпляра LSA и ни один из соседних маршрутизаторов не находится в состоянии Exchange или Loading, выполняются следующие действия:
    1. Подтверждается прием LSA путем передачи пакета Link State Acknowledgment отправителю LSA (см. параграф 13.5);
    2. LSA отбрасывается с переходом к следующему анонсу (если он имеется) из пакета LSU.
  1. В остальных случаях отыскивается текущий экземпляр LSA в базе данных маршрутизатора. Если в базе не найдено копии или LSA новее копии в базе данных (сравнение возраста LSA описано в параграфе 13.1), выполняются следующие операции:
    1. Если в базе данных уже есть копия, полученная в результате лавинной рассылки и установленная менее MinLSArrival секунд назад, новый анонс отбрасывается (без подтверждения) и проверяется следующий анонс (если он есть) в пакете LSU.
    2. В противном случае незамедлительно начинается лавинная рассылка нового анонса LSA через часть интерфейсов маршрутизатора (см. параграф 13.3). В некоторых случаях (например, если принимающий интерфейс находится в состоянии DR и анонс LSA был принят не от Backup DR) LSA рассылаются в лавинном режиме принявшим анонс интерфейсом. Эти случаи должны фиксироваться для последующего использования в процессе подтверждения (параграф 13.5).
    3. Текущая копия из базы данных удаляется из списков Link state retransmission всех соседей.
    4. Новая запись LSA помещается в базу данных взамен текущей копии. Эта замена может приводить к планируемому пересчету таблицы маршрутов. Для новой записи LSA фиксируется время ее поступления. Процедура лавинной рассылки не может переписывать новые LSA, пока не пройдет MinLSArrival секунд. Установка LSA описана в параграфе 13.2.
    5. По возможности подтверждается прием LSA путем передачи пакета Link State Acknowledgment через принявший анонс интерфейс (см. параграф 13.5).
    6. Если новый анонс сгенерирован принявшим его маршрутизатором (self-originated LSA), этот маршрутизатор должен выполнить специальные действия – обновить LSA или (в некоторых случаях) удалить анонс из домена маршрутизации. Обнаружение и обработка self-originated LSA описаны в параграфе 13.4.

6. Далее, если экземпляр LSA находится в списке Link state request передающего соседа, в процессе Database Exchange происходит ошибка. В таких случаях процесс Database Exchange перезапускается путем генерации для соседа и передачи ему события BadLSReq и прекращения обработки пакетов LSU.

7. Иначе, если LSA совпадает с экземпляром в базе данных (т. е., их возраст одинаков), выполняются две операции:

    1. Если LSA присутствует в списке Link state retransmission для принимающего смежного маршрутизатора, предполагается, что маршрутизатор самостоятельно подтверждает LSA. Принятые LSA следует трактовать как подтверждения, удаляя их из списка Link state retransmission (это называется «подразумеваемым подтверждением – implied acknowledgment). Такие события должны документироваться для последующего использования в процессе подтверждения (параграф 13.5).
    2. Можно подтвердить прием LSA путем передачи пакета Link State Acknowledgment через принявший интерфейс (см. пример в параграфе 13.5).

8. В остальных случаях копия в базе данных является более новой. Если возраст этой копии равен MaxAge и порядковый номер равен MaxSequenceNumber, принятый анонс LSA просто отбрасывается без подтверждения (это говорит о завершении цикла счетчика порядковых номеров и необходимости удаления LSA с номером MaxSequenceNumber до генерации новых экземпляров LSA). В противном случае, если копия из базы данных не была передана в пакете LSU в течение последних MinLSArrival секунд, эта копия должна быть отправлена передающему соседу в пакете LSU (пакет должен быть адресован соседу напрямую). В таких случаях копия LSA из базы данных не помещается в список link state retransmission для соседа и прием последнего анонса LSA не подтверждается.

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

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

Записи LSA идентифицируются полями LS type, Link State ID и Advertising Router. Для двух экземпляров LSA поля LS sequence number, LS age и LS checksum позволяют выбрать более новый экземпляр:

  • Запись LSA с большим порядковым номером является более новой (описание нумерации приведено в параграфе 12.1.6). Если порядковые номера совпадают, выполняется следующая проверка
  • Если экземпляры отличаются по контрольной сумме (16-битовое беззнаковое целое), более новым считается экземпляр с большим значением контрольной суммы.
  • Если контрольные суммы совпадают и возраст одного из экземпляров равен MaxAge, этот экземпляр считается более новым.
  • В противном случае, если возраст отличается более, чем на MaxAgeDiff, более новым считается экземпляр с меньшим возрастом.
  • В остальных случаях экземпляры считаются идентичными.

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

Включение в базу данных новых LSA в результате лавиной рассылки или самогенерации (self-originated LSA) может вызывать необходимость перерасчета таблицы маршрутов OSPF. Содержимое нового анонса LSA должно сравниваться со старым экземпляром, если такой имеется. При отсутствии различий не требуется пересчитывать таблицу маршрутов. Сравнение LSA с предыдущим экземпляром осуществляется по следующим критериям:

  • Изменение поля Options в LSA.

  • В одной из записей LSA возраст равен MaxAge, а в другой меньше.
  • Изменилось поле длины в заголовке LSA.
  • Изменилось тело LSA (содержимое LSA после 20-байтового заголовка). Отметим, что изменения LS Sequence Number и LS Checksum относятся к заголовку и не попадают в данную категорию.

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

Router-LSA и network-LSA

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

Summary-LSA

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

AS-external-LSA

Должен пересчитываться лучший маршрут к адресату, описанный в AS-external-LSA (см. параграф 16.6).

Кроме того, все старые экземпляры LSA должны быть удалены из базы данных при установке новой записи LSA. Старые экземпляры должны также удаляться из списков Link state retransmission всех соседей (см. главу 10).

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

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

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

В зависимости от типа LSA рассылка осуществляется через один или несколько интерфейсов, для определения которых используются следующие правила:

AS-external-LSA (LS Type = 5)

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

Прочие типы

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

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

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

    1. Если сосед еще не достиг состояния Exchange, он не участвует в рассылке.
    2. Если отношения смежности еще не полные (состояние соседа Exchange или Loading), проверяется список запросов состояния канала, связанный со смежностью. Если в списке присутствует экземпляр нового анонса LSA, это говорит о том, что соседний маршрутизатор уже имеет экземпляр LSA и нужно сравнить его с новым:

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

      • В остальных случаях новая запись LSA является более свежей. Удалите LSA из списка Link state request.
    3. Если новый анонс LSA был получен от этого соседа, проверяется следующий сосед.

    4. Поскольку нельзя сказать определенно, что сосед имеет свежий экземпляр LSA, нужно добавить новый анонс в список Link state retransmission для смежного маршрутизатора. Это обеспечивает надежность процедуры лавинной рассылки – LSA передаются повторно с заданным интервалом, пока от соседа не придет подтверждение.
  1. Маршрутизатор должен решить вопрос о необходимости лавинной рассылки LSA через данный интерфейс. Если на этапе 1 анонс LSA не был добавлен ни в один из списков Link state retransmission, нет необходимости рассылать LSA через данный интерфейс и можно переходить к следующему интерфейсу.
  2. Если новый анонс LSA был принят через данный интерфейс от маршрутизатора DR или Backup DR, существует вероятность, что все соседи уже получили копию LSA и можно переходить к следующему интерфейсу.

  3. Если новый анонс LSA получен через этот интерфейс и последний находится в состоянии Backup (маршрутизатор служит Backup DR), проверяется следующий интерфейс. Маршрутизатор DR будет слать анонсы на этот интерфейс, однако при «падении» DR данный маршрутизатор (т. е., Backup DR) будет завершать повторную рассылку анонсов.
  4. Если проверка дошла до этого этапа, требуется лавинная рассылка LSA через данный интерфейс. Следует передать пакет LSU, содержащий новый анонс LSA в своем теле. Возраст LSA должен быть увеличен на InfTransDelay при копировании анонса в пакет LSU (если возраст не равен MaxAge).

В широковещательных сетях пакеты LSU рассылаются по групповым адресам. Указываемый в пакете LSU IP-адрес получателя зависит от состояния интерфейса. Если интерфейс находится в состоянии DR или Backup, используется адрес AllSPFRouters, в остальных случаях – AllDRouters.

В сетях без широковещания передается отдельная копия пакета LSU каждому смежному соседу (состояние не ниже Exchange). В качестве получателя пакета указывается IP-адрес соседа.

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

Получение своих (self-originated) анонсов LSA в результате лавинной рассылки является нормальным событием. Для детектирования свих self-originated LSA маршрутизатор может использовать 2 признака: 1) поле Advertising Router в LSA совпадает с Router ID или 2) поле Link State ID в network-LSA совпадает с IP-адресом интерфейса маршрутизатора.

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

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

  1. Анонс является summary-LSA или AS-external-LSA, а маршрутизатор больше не имеет анонсируемого пути к получателю;
  2. Анонс является network-LSA, а маршрутизатор больше не является DR для сети;
  3. Анонс является network-LSA и поле Link State ID содержит IP-адрес одного из интерфейсов маршрутизатора, но поле Advertising Router не совпадает с Router ID данного маршрутизатора (этот редкий случай говорит об изменении Router ID после генерации LSA).

Во всех этих случаях вместо обновления LSA, требуется их удаление из области маршрутизации путем установки LS age = MaxAge и повтора лавинной рассылки (см. параграф 14.1).

13.5. Передача LSA

Прием каждого нового анонса LSA должен подтверждаться. Обычно для подтверждения используются пакеты Link State Acknowledgment (LSAck), однако возможно и неявное подтверждение с помощью пакетов LSU (см. п. 7a в параграфе 13).

Можно группировать множество подтверждений в один пакет LSAck, передавая этот пакет обратно через принявший анонсы интерфейс. Пакет подтверждения можно передавать 2 способами – с задержкой или непосредственно. Использование той или иной стратегии зависит от обстоятельств приема LSA.

Передача подтверждений с задержкой предполагает несколько условий:

  1. Компоновка множества подтверждений в один пакет LSAck.

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

Фиксированный интервал между отложенными передачами должен быть меньше RxmtInterval, иначе повтор станет ненужным.

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

Точные процедуры передачи пакетов LSAck описаны в таблице 22. Обстоятельства приема LSA показаны в левой колонке, а выполняемые действия для различных состояний в остальных колонках. Действия зависят от состояния интерфейса – реакция для состояния Backup отличается от действий в других состояниях. Отложенные подтверждения должны доставляться всем смежным маршрутизаторам, связанным с интерфейсом. В широковещательных сетях это осуществляется путем передачи пакетов LSAck с использованием групповых адресов. Используемое значение Destination IP зависит от состояния интерфейса – для состояний DR и Backup используется групповой адрес AllSPFRouters, а для прочих состояний – AllDRouters. В сетях без широковещания отложенные пакеты LSAck должны передаваться раздельно каждому смежному маршрутизатору (т. е., соседу в состоянии >= Exchange).

Таблица 22 Передача анонсов состояния каналов.

Обстоятельства

Действия, выполняемые в состоянии

Backup

Остальные состояния

Приемный интерфейс будет рассылать LSA обратно, используя flooding (см. главу 13, шаг 5b). Подтверждение не передается. Подтверждение не передается.
LSA новее копии в базе данных, но не рассылается обратно принявшим ее интерфейсом. Если анонс получен от DR, передается отложенное подтверждение, в противном случае – ничего. Передается отложенное подтверждение.
LSA является дубликатом и трактовалась как косвенное подтверждение (см. главу 13, шаг 7a). Если анонс получен от DR, передается отложенное подтверждение, в противном случае – ничего. Подтверждение не передается.
LSA является дубликатом и трактовалась как косвенное подтверждение. Передается прямое подтверждение. Передается прямое подтверждение.
Возраст LSA MaxAge, отсутствует текущий экземпляр LSA в базе данных и ни один из соседей маршрутизатора не находится в состоянии Exchange или Loading (см. главу 13, шаг 4). Передается прямое подтверждение. Передается прямое подтверждение.

Причины использования групповой адресации поясним на примере. Вернемся к сети, показанной на рисунке 11, и предположим, что маршрутизатор RT4 играет роль DR, а RT3 – Backup DR для сети N3. Когда RT4 рассылает новый анонс LSA в сеть N3, его принимают маршрутизаторы RT1, RT2 и RT3, которые не будут посылать LSA обратно в сеть N3, но по-прежнему должны гарантировать синхронизацию своих баз данных со смежными соседями. В результате маршрутизаторы RT1, RT2 и RT4 ожидают подтверждений от RT3, а маршрутизаторы RT4 и RT3 ждут подтверждений от RT1 RT2. В такой ситуации удобны групповые адреса.

Логика подтверждений для Backup DR несколько отличается за счет различий в процедуре лавинной рассылки LSA (см. параграф 13.3, п. 4).

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

Анонсы LSA, рассылаемые в лавинном режиме смежным маршрутизатором, будут помещаться в список Link state retransmission для него. Для обеспечения надежности лавинной рассылки повтор передачи LSA длится до приема подтверждения. Интервал между повторами задается для каждого интерфейса параметром RxmtInterval. Если установленное для интерфейса значение слишком велико, повтор передачи будет бесполезен. При слишком малом периоде повторов это может повлиять на скорость лавинной рассылки.

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

Пакеты LSU, содержащие повторы анонсов, всегда передаются напрямую соседу. В сетях с множественным доступом это означает передачу повторов непосредственно по IP-адресу соседа. Возраст каждого анонса LSA должен увеличиваться на InfTransDelay (> 0) при копировании в пакет LSU (если возраст не достигает MaxAge).

Если смежный маршрутизатор не работает, повтор может происходить до тех пор, пока смежность не будет устранена с помощью протокола Hello. При разрушении смежности список Link state retransmission очищается.

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

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

  • Если не подтверждается экземпляр LSA из списка Link state retransmission для соседа, переход к следующему подтверждению
  • Если подтверждается тот же самый экземпляр, последний удаляется из списка с переходом к следующему подтверждению.
  • Протоколируется спорное подтверждение с переходом к следующему подтверждению.

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

Каждая запись LSA имеет поле возраста LS, выраженного в секундах. Возраст LSA увеличивается при нахождении записи в базе данных; при копировании записи в пакет LSU для рассылки через какой-либо из интерфейсов возраст также увеличивается на InfTransDelay.

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

При создании списка Database summary для формируемых отношений смежности все LSA с возрастом MaxAge в базе данных добавляются в список Link state retransmission для соседа вместо списка Database summary для этого соседа (см. параграф 10.3).

LSA с возрастом MaxAge должны незамедлительно удаляться из базы данных маршрутизатора, если a) они не содержатся более ни в одном из списков Link state retransmission для соседей и b) ни один из соседей маршрутизатора не находится в состоянии Exchange или Loading.

Когда в процессе увеличения возраста базы данных поле LS age требует многократного обращения к CheckAge, должна проверяться контрольная сумма LSA. Если контрольная сумма некорректна, это говорит о наличии ошибок в программе или памяти – в таких случаях рекомендуется перезагрузить маршрутизатор.

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

Анонсы LSA могут удаляться из домена маршрутизации путем установки LS age = MaxAge с сохранением порядкового номера и повторной лавинной рассылки LSA. Эта процедура совпадает с процедурой, применяемой для LSA, возраст которых достиг MaxAge естественным путем (см. параграф 14). В частности LSA удаляются из базы данных маршрутизатора, если a) эти анонсы больше не включены в списки Link state retransmission ни одного из соседей и b) ни один из соседних маршрутизаторов не находится в состоянии Exchange или Loading. Будем называть процесс установки для LSA возраста MaxAge принудительным старением (premature aging).

Принудительное старение используется при достижении максимального порядкового номера для собственных (self-originated) LSA. В таких случаях текущий экземпляр LSA (порядковый номер MaxSequenceNumber) должен быть принудительно состарен и удален из домена маршрутизации до того, как будет порожден новый экземпляр с порядковым номером InitialSequenceNumber (см. параграф 12.1.6).

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

Маршрутизатор может использовать принудительное старение только для собственных LSA. Анонсы LSA считаются собственными (self-originated), если 1) поле Advertising Router в LSA содержит значение Router ID самого маршрутизатора или 2) поле Link State ID в network-LSA содержит IP-адрес одного из интерфейсов маршрутизатора.

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

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

Виртуальное соединение трактуется как сеть point-to-point, относящаяся к магистрали и соединяющая пару граничных маршрутизаторов областей. Через виртуальный канал маршрутизаторы пытаются организовать отношения смежности. После организации смежности виртуальный канал включается в магистральные анонсы router-LSA и пакеты OSPF, принадлежащие магистральной области, будут передаваться через виртуальный канал с отношениями смежности (виртуальная смежность или virtual adjacency).

В каждой из конечных точек доступность и стоимость виртуального канала определяется путем просмотра в таблице маршрута для другой точки этого соединения (связанная с маршрутом область должна быть задана как транзитная). Когда связанный с виртуальным соединением путь становится доступным, генерируется событие InterfaceUp. И наоборот, при невозможности использования пути через виртуальный канал генерируется событие InterfaceDown. Иными словами, доступность виртуального канала определяется существованием внутридоменного маршрута между конечными точками через транзитную область. Отметим, что виртуальные каналы, для которых стоимость превышает значение 0xffff (максимальная стоимость интерфейса в router-LSA), должны рассматриваться как неработоспособные (т. е., путь между конечными точками виртуального канала не существует).

Некоторое особенности виртуальных каналов перечислены ниже:

  • Анонсы AS-external-LSA никогда не рассылаются через виртуальные каналы со смежностью, поскольку такая рассылка ведет к дублированию (те же AS-external-LSA уже разосланы через транзитную область виртуального соединения). По этой же причине AS-external-LSA не резюмируются через виртуальные каналы со смежностью в процессах Database Exchange.
  • Стоимость виртуального соединения не задается конфигурационными параметрами, а определяется как стоимость внутридоменного маршрута между двумя определенными граничными маршрутизаторами областей. Эта стоимость появляется в соответствующей виртуальному соединению записи таблицы маршрутов. При изменении стоимости виртуального маршрута должен генерироваться новый анонс router-LSA для магистральной области.
  • Подобно тому, как стоимость и доступность виртуального соединения определяются в процессе построения таблицы маршрутов (создание в таблице записи для соседа по виртуальному каналу), для виртуального канала существуют IP-адреса локального и удаленного интерфейсов. Эти адреса используются при передаче пакетов OSPF через виртуальный канал. Отметим, когда одна или обе конечные точки виртуального соединения подключены к транзитной области через безадресное соединение point-to-point, определение IP-адреса (своего или виртуального соседа) может оказаться невозможным, что приведет к «падению» виртуального канала.
  • В анонсах router-LSA, генерируемых конечными точками для магистральной области, виртуальный канал представляется типом 4 – поле Link ID содержит значение OSPF Router ID соседа, а Link Data содержит IP-адрес виртуального интерфейса (см. параграф 12.4.1.
  • Немагистральная область может передавать транзитный трафик данных (т. е., использоваться как транзитная область) в тех и только в тех случаях, когда эта область задана в качестве транзитной для одного или нескольких виртуальных каналов с полной смежностью (см. TransitCapability в параграфах 6 и 16.1). Такие области требуют специальной трактовки при резюмировании в них информации о магистральных сетях (см. параграф 12.4.3) и в процессе расчета маршрутов (см. параграф 16.3).
  • Для виртуальных каналов задается время повтора передачи данных о состоянии каналов – RxmtInterval. Это время должно превышать ожидаемое значение времени кругового обхода (round-trip delay) между двумя маршрутизаторами. Оценка этого времени для виртуального канала может быть достаточно сложной и лучше будет переоценить задержку, нежели наоборот.

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

В этой главе рассмотрен процесс расчета таблицы маршрутизации OSPF. Используя базу данных о каналах подключенной области, маршрутизатор использует описанный ниже алгоритм для построения таблицы маршрутов. На каждом этапе построения маршрутизатор должен обращаться к отдельным частям базы данных (например, к анонсам router-LSA одного из маршрутизаторов). Эти обращения используют функции просмотра базы данных, описанные в параграфе 12.2. Функция поиска может возвращать LSA с возрастом MaxAge. Такие не должны использоваться при расчете маршрутов и результат поиска трактуется как отрицательный.

Организация таблицы маршрутов OSPF описана в главе 11, где в качестве примера были построены таблицы для двух разных случаев (параграфы 11.2 и 11.3). Процесс построения таблицы можно разбить на несколько этапов:

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

  2. Внутридоменные маршруты рассчитываются путем построения дерева кратчайших путей для области. В частности, на этом этапе рассчитываются все записи таблицы маршрутов, для которых адресатами являются граничные маршрутизаторы области. Процесс выполняется в два приема – сначала строится дерево, содержащее только каналы между маршрутизаторами и транзитными сетями, а потом к дереву добавляются транзитные сети. При построении дерева кратчайших путей рассчитывается также значение TransitCapability, используемое на этапе 4.
  3. Рассчитываются междоменные маршруты путем просмотра анонсов summary-LSA. Если маршрутизатор подключен к нескольким областям (т. е., является граничным для области), принимаются во внимание только summary-LSA от магистрали.
  4. В граничных маршрутизаторах областей, подключенных по крайней мере к одной транзитной области (не относящаяся к магистрали область с TransitCapability = TRUE), проверяются summary-LSA от транзитных областей для проверки существования через транзитную область более короткого пути по сравнению с маршрутами, найденными на этапах 2 – 3.
  5. Рассчитываются внешние маршруты путем обработки AS-external-LSA. Местоположение граничных маршрутизаторов было определено на этапах 2-4.

Детальное описание этапов 2-5 приведено ниже.

Изменения, вносимые в таблицу маршрутов, могут потребовать от протокола OSPF дальнейших действий. Например, изменение внутридоменного маршрута от граничных маршрутизаторов области может потребоваться генерация новых анонсов summary-LSA (см. параграф 12.4). Полное описание действий OSPF в результате изменения таблицы маршрутов приведено в параграфе 16.7.

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

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

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

Vertex (node) ID

32-битовый номер, который вместе с типом вершины (сеть или маршрутизатор) создает уникальное обозначение вершины. Для вершин маршрутизаторов поле Vertex ID содержит OSPF Router ID, для сетевых вершин – IP-адрес DR для этой сети.

An LSA

Каждая транзитная вершина имеет связанную с ней запись LSA. Для вершин маршрутизаторов это router-LSA, для транзитных сетей – network-LSA (генерируется сетевым DR). В любом случае поле Link State ID в LSA равно Vertex ID.

List of next hops

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

Distance from root

Стоимость текущего набора кратчайших путей от корня до вершины. Стоимость пути рассчитывается как сумма стоимостей каналов на этом пути (в соответствии с router-LSA и network-LSA). Путь с меньшей стоимостью считается более коротким.

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

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

  1. Инициализация структур данных алгоритма, очистка списка вершин-кандидатов. Инициализация дерева кратчайших путей к корню (маршрутизатор, рассчитывающий дерево). Установка для области A значения TransitCapability = FALSE
  2. Проверка записи LSA, связанной с добавляемой вершиной (назовем ее V) – поиск в базе данных области A по значению Vertex ID. Если запись является router-LSA и бит V (см. параграф A.4.2) в ней установлен, задаем для области A TransitCapability = TRUE. В любом случае, каждый канал, описанный в LSA, дает стоимость смежной с ним вершины. Для каждого описанного канала (скажем, между вершинами V и W) выполняются следующие операции:

    1. Если канал ведет в тупиковую область, переходим к следующей вершине V в LSA, поскольку тупиковые области не рассматриваются на первом этапе расчета.

    2. В остальных случаях W является транзитной вершиной (маршрутизатор или транзитная сеть) и просматривается LSA (router-LSA или network-LSA) для этой вершины (W) в базе данных области A. Если LSA не существует, возраст записи равен MaxAge или не существует канала обратно к вершине V, переходим к следующему каналу LSA вершины V5.
    3. Если вершина W уже включена в дерево кратчайших путей, проверяется следующий канал в LSA.
    4. Расчет стоимости D результирующего пути от корня к вершине W. Значение D равно сумме стоимостей каналов (уже рассчитанной) для кратчайшего пути к вершине V и анонсируемой дистанции между вершинами V и W.

      • Если D превышает значение, уже полученное для вершины W в списке кандидатов, проверяется следующий канал.

      • Если D совпадает со стоимостью для вершины W в списке кандидатов, рассчитывается набор next hop, используемых с рассчитываемым каналом. Исходными данными для расчета являются получатель (W) и его родительская вершина (V). Расчет показан в параграфе 16.1.1. Набор интервалов должен добавляться к значениям next hop для вершины W в списке кандидатов.
      • Если D меньше стоимости для вершины W в списке кандидатов или W отсутствует в этом списке, организуется запись для вершины W в списке кандидатов, чтобы показать дистанцию D от корня. Рассчитывается также список next hop для использования с анонсируемым каналом и соответствующим образом устанавливаются значения next hop для вершины W. Расчеты next hop приведены в параграфе 16.1.1; в них используются адресат (W) и его родитель (V).

  1. Если на этом этапе список кандидатов пуст, это говорит о завершении процесса построения дерева кратчайших путей для транзитных вершин. Если список содержит вершины-кандидаты, из него выбирается вершина, наиболее близкая к корню и добавляется в дерево кратчайших путей (из списка кандидатов эта вершина удаляется). Отметим, что при наличии нескольких вершин, одинаково удаленных от корня, следует выбирать сначала вершины, связанные с сетями (а не маршрутизаторами), чтобы можно было включить все равноценные пути. Это связано с использованием tie-breaker в модифицированном алгоритме Dijkstra, применяемом в MOSPF (OSPF Multicast routing extensions).

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

    Если недавно добавленная вершина является граничным маршрутизатором области или AS, в таблицу маршрутов добавляется запись с типом адресата router. Поле опций, найденной в связанной записи router-LSA, копируется в поле дополнительных возможностей записи в таблице маршрутов (Optional capabilities). Назовем новую вершину X. Если маршрутизатор X является конечной точкой одного из виртуальных каналов ведущего расчет маршрутизатора и этот канал использует область A как транзитную, декларируется активность виртуального канала, в качестве адреса виртуального интерфейса устанавливается IP-адрес выходного интерфейса, рассчитанного выше для Router X, а в качестве адреса соседа устанавливается IP-адрес интерфейса Router X (содержится в router-LSA от маршрутизатора X), который указывает обратно на корень дерева кратчайших путей (этот интерфейс также указывает на родительскую вершину для Router X в дереве кратчайших путей – подобный расчет приведен в параграфе 16.1.1).

    Если добавленная вершина является транзитной сетью, в таблице маршрутов создается запись для сети. Поле Destination ID содержит IP-номер сети, получаемый маскированием Vertex ID (Link State ID) – маска сети содержится в теле network-LSA. Если такая запись уже существует в таблице маршрутов, на одну сеть отображается несколько вершин графа. Например, такая ситуация может наблюдаться при выборе нового маршрутизатора DR – в этом случае текущая запись таблицы маршрутов должна заменяться в тех и только в тех случаях, когда новый путь короче указанного в текущей записи маршрута и поле Link State Origin в текущей записи меньше значения Link State ID в LSA добавленной вершины.

    Если для сети отсутствует запись в таблице (обычная ситуация), такая запись добавляется. Поле Link State Origin для новой записи должно содержать LSA добавляемой вершины.

  3. Новая итерация алгоритма, начиная с этапа 2.

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

  1. Рассчитывается дистанция D тупиковой сети от корня, равная сумме дистанции от корня до вершины-маршрутизатора (вычисляется на этапе 1) и анонсируемой стоимости тупиковой сети. Полученное значение сравнивается с текущим значением лучшей стоимости тупиковой сети, путем просмотра текущей записи для тупиковой сети в таблице маршрутов. Если значение D превышает текущую стоимость, проверяется LSA для следующей тупиковой сети.

  2. При достижении этого этапа таблица маршрутизации тупиковой сети должна быть обновлена. Рассчитывается набор next hop в результате использования канала в тупиковую сеть (этот расчет показан в параграфе 16.1.1) с использованием адресата (тупиковая сеть) и родительской вершины (маршрутизатор). Если D совпадает со стоимостью в текущей записи таблицы маршрутов, набор next hop просто добавляется в список next hop записи в таблице. В таких случаях запись в таблице уже имеет поле Link State Origin. Если оно указывает на router-LSA с Link State ID < Router ID для маршрутизатора V, в качестве Link State Origin устанавливается router-LSA маршрутизатора V.

Если D меньше текущей стоимости, запись в таблице заменяется путем установки стоимости D и нового списка next hop. В поле Link State Origin записи в таблице маршрутов помещается router-LSA маршрутизатора V. После этого обрабатывается следующая тупиковая сеть.

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

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

16.1.1. Расчет next hop

В этом параграфе описан способ расчета набора next hop (следующий маршрутизатор) для использования с адресатом. Каждый параметр next hop содержит интерфейс, используемый для пересылки пакетов адресату и IP-адрес следующего маршрутизатора (если он есть). Расчет next hop используется всякий раз при обнаружении кратчайшего пути к адресату, что может происходить на любом этапе построения дерева кратчайших путей (см. параграф 16.1). На первом этапе расчета дерева это происходит при добавлении найденного кратчайшего пути в список кандидатов или при изменении записи для кандидата (п. 2d этапа 1). На втором этапе кратчайший путь определяется всякий раз при изменении записи в таблице маршрутов (п. 2 этапа 2).

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

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

Если текущий кратчайший путь между адресатом и корнем включает по крайней мере один промежуточный маршрутизатор, адресат просто наследует набор next hop от родителя. В противном случае возможны два варианта. В первом случае родительской вершиной является корень (ведущий расчет маршрутизатор). Это означает, что адресатом могут служить непосредственно подключенные сеть или маршрутизатор. Выходным интерфейсом в таких ситуациях является интерфейс OSPF подключенный к сети/маршрутизатору-адресату. Если адресатом является маршрутизатор, подключенный через сеть Point-to-MultiPoint, IP-адреса next hop можно определить, просматривая router-LSA для адресата – каждый канал, ведущий обратно к рассчитывающему маршрутизатору и имеющий поле Link Data, относящееся к сети Point-to-MultiPoint, обеспечивает IP-адрес следующего маршрутизатора (next hop). Если адресатом является напрямую подключенная сеть или маршрутизатор, соединенный с ведущим расчет маршрутизатором через интерфейс point-to-point, для next hop не требуется адреса IP. Если маршрутизатор-адресат подключен к рассчитывающему маршрутизатору через виртуальный канал, установка next hop должна быть отложена до выполнения расчетов, описанный в 16.3.

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

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

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

Анонсы Summary-LSA генерируются граничными маршрутизаторами областей. При расчете междоменных маршрутов принимаются во внимание все summary-LSA в области A. Напомним, что адресатом, описанным в summary-LSA, может быть сеть (summary-LSA типа 3 ) или граничный маршрутизатор AS (summary-LSA типа 4). Для каждого анонса summary-LSA выполняется следующее:

  1. Если в LSA указана стоимость LSInfinity или возраст LSA равен MaxAge, переходим к следующему анонсу LSA.
  2. Если анонс LSA порожден рассчитывающим маршрутизатором, переходим к следующему анонсу LSA.
  3. Если summary-LSA относится к типу 3, набор адресатов, описываемых в summary-LSA, совпадает с одним из заданных для области маршрутизатора диапазонов адресов (см. параграф 3.5) и адресный диапазон отдельной области является активным, этот анонс summary-LSA следует игнорировать (активность означает наличие по крайней мере одной сети в диапазоне области, доступной по внутридоменному пути).
  4. Для остальных случаев назовем адресата, описываемого LSA, N (для summary-LSA типа 3 адрес N получается путем наложения маски сети/подсети из тела LSA на значение Link State ID в LSA), а породивший LSA граничный маршрутизатор области – BR. Будем искать в таблице маршрутов запись для BR имеющую область A в качестве связанной. Если такой записи для BR не существует (т. е., BR недостижим в области A), данный анонс LSA следует пропустить и перейти к следующему. При наличии записи LSA описывает внутридоменный путь к адресату N, стоимость которого равна сумме дистанции до BR и стоимости, указанной в LSA. Обозначим стоимость этого междоменного пути как IAC.
  5. Далее будем искать в таблице маршрутов запись для адресата N (если N является граничным маршрутизатором AS, будем искать в таблице запись router, связанную с областью A). Если в таблице нет записи для N или запись включает внешний путь типа 1 или 2, устанавливаем междоменный путь к адресату N со связанной областью A, стоимостью IAC, значением next hop, совпадающим со списком next hop к маршрутизатору BR и Advertising router = BR.
  6. В противном случае, если присутствующие в таблице пути являются внутридоменными, с LSA не нужно делать ничего (внутридоменные пути всегда имеют предпочтение).
  7. В остальных случаях присутствующие в таблице пути также являются междоменными. Устанавливаем новый путь через BR, если он дешевле, переписывая запись в таблице маршрутов. Если новый путь имеет ту же стоимость, добавляем его к списку путей в записи таблицы маршрутов.

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

Этот этап выполняется маршрутизаторами, подключенными к одной или нескольким немагистральным областям, способным передавать транзитный трафик (на этапе 2 алгоритма Dijkstra устанавливается TransitCapability = TRUE, как описано в параграфе 16.1).

Целью описанного ниже расчета является проверка транзитных областей на предмет поиска лучшего (более короткого) пути по сравнению с результатами расчетов, описанных в параграфах 16.1 и 16.2. Любые пути, которые не хуже вычисленных ранее, добавляются в таблицу маршрутизации. Расчет также определяет актуальные значения next hop для тех адресатов, у которых значения next hop, рассчитанные в 16.1 и 16.2 указывают на виртуальные каналы. После завершения описанных ниже расчетов все пути, рассчитанные в 16.1 и 16.2, которые имеют непреобразованные (unresolved) виртуальные значения next hop, должны удаляться.

При расчете просматриваются summary-LSA от всех транзитных областей. Каждый анонс summary-LSA описывает маршрут через транзитную область A в сеть N (адрес N определяется наложением маски сети/подсети из тела LSA на значение Link State ID в LSA) или (для summary-LSA типа 4) к граничному маршрутизатору AS. Предположим, что summary-LSA порождаются граничным маршрутизатором области – BR.

  1. Если стоимость, анонсируемая в summary-LSA, равна LSInfinity или LS age = MaxAge, проверяется следующая запись LSA.
  2. Если анонс summary-LSA был порожден ведущим расчет маршрутизатором, переходим к проверке следующего анонса LSA.
  3. Поиск в таблице маршрутов записи для N (если N является граничным маршрутизатором AS, нужно отыскать запись для маршрутизатора, связанную с магистральной областью). Если записи не существует в таблице, путь для записи является внутридоменным или междоменным, или область, связанная с записью в таблице, не относится к магистрали, переходим к проверке следующего анонса LSA. Иными словами, этот расчет только обновляет внутридоменные пути для магистральной области, определенные в параграфе 16.1 и междоменные пути, найденные в 16.2.
  4. Поиск в таблице записи для анонсирующего маршрутизатора BR, связанного с областью A. Если маршрутизатор недоступен, проверяется следующий анонс LSA. В противном случае стоимость доставки в сеть N равна сумме стоимости в записи базы области A для BR и стоимости, анонсируемой в LSA. Назовем суммарную стоимость IAC.

  5.                       ........................
                          . Area 1 (транзит)     .            +
                          .                      .            |
                          .      +---+1        1+---+100      |
                          .      |RT2|----------|RT4|=========|
                          .    1/+---+********* +---+         |
                          .    /*******          .            |
                          .  1/*Виртуальный      .            |
                       1+---+/*  канал           .            |Сеть
                 =======|RT1|*                   .            | N1
                        +---+\                   .            |
                          .   \                  .            |
                          .    \                 .            |
                          .    1\+---+1        1+---+20       |
                          .      |RT3|----------|RT5|=========|
                          .      +---+          +---+         |
                          .                      .            |
                          ........................            +
    

    Рисунок 13. Маршрутизация через транзитные области.

    Если эта стоимость меньше стоимости доставки в N из записи в таблице маршрутов, переписываем список next hop для N, указывая next hop для BR, и значение IAC в качестве стоимости для N. Если IAC совпадает с текущей стоимостью для N, добавляем список next hop маршрутизатора BR к списку next hop сети N. В таких случаях область, связанная с записью таблицы маршрутов для N должна оставаться в магистрали, а тип пути (внутридоменный или междоменный) не должен изменяться. Важно подчеркнуть, что приведенный выше расчет никогда не показывает недоступность достижимых адресатов, но может находить более короткие пути к доступным получателям. В результате расчета лучшие пути включаются в таблицу маршрутов и заново анонсируются с помощью summary-LSA в другие области.

В качестве примера расчета рассмотрим автономную систему, показанную на рисунке 13. Здесь имеется одна немагистральная область (Area 1), физически делящая магистраль на две части. Для создания связной магистрали организуется виртуальный канал между маршрутизаторами RT1 и RT4. Сеть N1 в правой части рисунка относится к магистрали. Линии из точек показывают, что существует значительно более короткий внутридоменный путь в сеть N1 от маршрутизатора RT5 (стоимость 20), нежели от маршрутизатора RT4 (стоимость 100). Оба маршрутизатора RT4 и RT5 будут передавать свои summary-LSA для сети N1 в область Area 1.

                      ........................
                      . Area 1 (транзит)     .            +
                      .                      .            |
                      .      +---+1        1+---+100      |
                      .      |RT2|----------|RT4|=========|
                      .    1/+---+********* +---+         |
                      .    /*******          .            |
                      .  1/*Виртуальный      .            |
                   1+---+/*  канал           .            |Сеть
             =======|RT1|*                   .            | N1
                    +---+\                   .            |
                      .   \                  .            |
                      .    \                 .            |
                      .    1\+---+1        1+---+20       |
                      .      |RT3|----------|RT5|=========|
                      .      +---+          +---+         |
                      .                      .            |
                      ........................            +

Рисунок 13. Маршрутизация через транзитные области.

После расчета дерева кратчайших путей для магистрали (см. параграф 16.1) маршрутизатор RT1 (левая сторона виртуального канала) будет иметь рассчитанный путь через RT4 для всех пакетов в сеть N1. Однако, поскольку RT5 обеспечивает значительно более короткий путь в сеть N1, все внутренние маршрутизаторы области 1 (например, RT2 и RT3) будут пересылать свои пакеты для сети N1 через маршрутизатор RT5 вместо RT4. После проверки summary-LSA для области 1 с помощью описанной выше процедуры маршрутизатор RT1 также будет пересылать пакеты для сети N1 в направлении RT5. Отметим, что в этом примере виртуальный канал позволяет пересылать транзитный трафик через область 1, но реальные пакеты данных не проходят через виртуальный канал. Иными словами, виртуальный канал делает возможным транзитный трафик, но не требует передачи такого трафика именно через виртуальное соединение.

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

Внешние маршруты AS рассчитываются путем обработки всех имеющихся анонсов AS-external-LSA. Большинство AS-external-LSA описывают маршруты к конкретным адресатам, но некоторые содержат описания принятых по умолчанию маршрутов для AS (Destination ID = DefaultDestination, маска сети/подсети = 0x00000000). Для AS-external-LSA выполняются следующие операции:

  1. LSA со стоимостью LSInfinity или возрастом MaxAge исключаются из рассмотрения.

  1. LSA, порожденные рассчитывающим маршрутизатором, также не рассматриваются.
  2. Обозначим адресата, описываемого в LSA, как N. Адрес N определяется наложением на Link State ID в LSA маски сети/подсети, содержащейся в теле LSA. В таблице маршрутов ищем запись (потенциально имеется одна запись на подключенную область) для граничного маршрутизатора AS (ASBR), породившего LSA. Если записи для маршрутизатора ASBR не существует (т. е., ASBR недоступен), переходим к следующему анонсу LSA в списке.

    В остальных случаях анонс LSA описывает внешний путь к адресату N. Адрес пересылки в AS-external-LSA указывает IP-адрес, по которому должны переправляться пакеты для адресата.

    Если в качестве адреса пересылки указано значение 0.0.0.0, пакеты должны пересылаться маршрутизатору ASBR. При наличии в таблице нескольких записей для ASBR выбирается предпочтительный маршрут с учетом приведенных ниже условий. Если совместимость с RFC-1583 (RFC1583Compatibility) отключена, сокращаем набор записей для ASBR в маршрутной таблице, как описано в параграфе 16.4.1. Из оставшихся записей выбираем маршрут с минимальной стоимостью. Если таких маршрутов несколько, выбираем среди них запись с максимальным значением OSPF Area ID (рассматривая как беззнаковое целое число) для связанной области.

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

  3. Пусть X указывает стоимость предпочтительного маршрута для ASBR/адреса пересылки, а Y – стоимость, указанную в LSA. X выражается в единицах метрики link state, а Y является внешней метрикой типа 1 или 2.

  4. Просматриваем таблицу маршрутизации для адресата N. Если записи для N не существует, устанавливается внешний путь к N, для которого next hop совпадает со списком next hop к адресам пересылки, а для анонсирующего маршрутизатора указано значение ASBR. Если внешний путь имеет метрику типа 1, для пути устанавливается тип 1 (external) со стоимостью X+Y. Если внешняя метрика относится к типу 2, для пути устанавливается тип 2 (external), компонента стоимости link state имеет значение X, а стоимость типа 2 равна Y.

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

    1. Внутридоменные и междоменные маршруты всегда более предпочтительны, нежели внешние маршруты.

    2. Внешние пути типа 1 предпочтительней, нежели пути типа 2. Когда все внешние пути относятся к типу 2, среди них предпочтительным является путь с наименьшей анонсируемой метрикой.
    3. Если новый внешний путь не отличается от текущего пути в маршрутной записи для сети N и совместимость RFC1583Compatibility отключена, предпочтительный путь выбирается на основе оценки внутренних путей к ASBR/адресу пересылки, как описано в параграфе 16.4.1.
    4. Если новый внешний путь по прежнему не отличается от текущего пути в маршрутной записи для сети N, выбираем предпочтительный путь, сравнивая стоимости. Внешние пути типа 1 сравниваются с учетом суммы дистанции до адреса пересылки и анонсируемой метрики типа 1 (X+Y). Внешние пути типа 2, анонсирующие метрику типа 2, сравниваются по дистанции до адреса пересылки.

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

При наличии в AS множества путей к ASBR/адресу пересылки для выбора предпочтительного пути используются приведенные здесь правила. Эти правила применяются когда один маршрутизатор ASBR доступен через множество областей или когда требуется отдать предпочтение одному из анонсов AS-external-LSA. В первом случае все пути завершаются на одном маршрутизаторе ASBR, а во втором – на разных ASBR/адресах пересылки. В обоих случаях каждый из путей представляется отдельной записью в таблице маршрутов (см. главу 11).

Приведенные в этом параграфе правила применимы только при отключенной совместимости RFC1583Compatibility.

Порядок выбора предпочтительного пути показан ниже. Отметим, что в результате применения этих правил может остаться несколько путей с одинаковыми уровнями предпочтения. В таких случаях путь выбирается на основе стоимости (см. параграф 16.4).

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

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

При получении нового анонса summary-LSA необходимо пересчитывать всю таблицу маршрутизации. Обозначим адресата, анонсируемого в summary-LSA как N (адрес N определяется наложением на значение Link State ID из LSA маски сети/подсети из тела LSA), а область, к которой относится LSA – A. Возможны два разных случая:

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

    • Сначала, если присутствует внутридоменный маршрут в сеть N, запись для N объявляется некорректной, но сохраняется для последующего сравнения.
    • После этого выполняются расчеты, описанные в параграфе 16.2 для одного адресата N. В этом расчете участвую все summary-LSA области A, описывающие путь в сеть N.
    • Дополнительно, если маршрутизатор является граничным и подключен к одной или нескольким транзитным областям, нужно снова провести расчеты, описанные в параграфе 16.3, для одного адресата. Если результаты этих расчетов изменяют стоимость/путь к граничному маршрутизатору AS (как в случае summary-LSA типа 4) или любому из адресов пересылки, нужно заново просмотреть все AS-external-LSA, используя расчет из параграфа 16.4. В противном случае, если сеть N недавно стала недоступной, нужно повторить расчеты из параграфа 16.4 для одного адресата N в случае существования альтернативных внешних путей в сеть N.

  1. Область A является транзитной, а маршрутизатор – граничным для области. В таких случаях требуется провести описанные ниже расчеты.

    • Сначала, если запись в таблице маршрутов для N содержит один или несколько междоменных путей с использованием области A, эти пути следует удалить. Если из записи удаляются все пути, запись отмечают как некорректную. Старые данные из записи должны быть сохранены для последующего сравнения.
    • После этого выполняются расчеты, описанные в параграфе 16.3 для одного адресата N. Если в результате расчетов стоимость пути в N возрастает, нужно заново пересчитать всю таблицу маршрутизации с использованием алгоритма Dijkstra, как описано в параграфе 16.1.
    • В остальных случаях, если стоимость/путь к граничному маршрутизатору AS (как в случае summary-LSA типа 4) или любому из адресов пересылки, нужно заново просмотреть все AS-external-LSA, используя расчет из параграфа 16.4. В противном случае, если сеть N недавно стала недоступной, нужно повторить расчеты из параграфа 16.4 для одного адресата N в случае существования альтернативных внешних путей в сеть N.

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

При получении нового анонса AS-external-LSA не требуется пересчета всей таблицы маршрутов. Обозначим описываемого AS-external-LSA адресата как N. Адрес N можно определить, применяя маску из тела LSA к значению поля Link State ID. Если к адресату имеется внутридоменный или междоменный маршрут, не требуется никаких расчетов (внутренний путь имеет предпочтение).

При отсутствии внутренних путей используется расчет, описанный в параграфе 16.4, выполняемый только для анонсов AS-external-LSA, указывающих путь в сеть N. Перед выполнением расчетов запись в таблице для адресата N объявляется некорректной.

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

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

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

  • Запись таблицы маршрутов, связанная с виртуальным каналом изменена. Это изменение показывает смену стоимости или доступности виртуального соединения.Если запись показывает, что граничный маршрутизатор области стал доступен недавно, соответствующий виртуальный канал работает. Для виртуального канала должно генерироваться событие InterfaceUp, которое будет инициировать формирование смежности (см. параграф 10.3). В этот момент также определяется IP-адрес интерфейса и Neighbor IP виртуального соседа.Если запись показывает, что граничный маршрутизатор области более не доступен, виртуальный канал и связанные с ним отношения смежности уничтожаются. Это означает необходимость генерации события InterfaceDown для связанного виртуального канала.
  • Если стоимость для записи изменена и существует полная виртуальная смежность, должен генерироваться новый анонс router-LSA для магистрали, что может потребовать дальнейших изменений в таблице маршрутизации.

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

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

Все маршруты из множества равноценных имеют один тип (внутридоменный, междоменный, внешний типа 1 или 2), равную стоимость и связаны с одной областью. Однако каждый маршрут может указывать свое значение next hop и Advertising router.

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

Литература

[Ref1] McQuillan, J., I. Richer and E. Rosen, “ARPANET Routing Algorithm Improvements”, BBN Technical Report 3803, April 1978.

[Ref2] Digital Equipment Corporation, “Information processing systems — Data communications — Intermediate System to Intermediate System Intra-Domain Routing Protocol”, October 1987.

[Ref3] McQuillan, J., et.al., “The New Routing Algorithm for the ARPANET”, IEEE Transactions on Communications, May 1980.

[Ref4] Perlman, R., “Fault-Tolerant Broadcast of Routing Information”, Computer Networks, December 1983.

[Ref5] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

[Ref6] McKenzie, A., “ISO Transport Protocol specification ISO DP 8073”, RFC 905, April 1984.

[Ref7] Deering, S., “Host extensions for IP multicasting”, STD 5, RFC 1112, May 1988.

[Ref8] McCloghrie, K., and M. Rose, “Management Information Base for network management of TCP/IP-based internets: MIB-II”, STD 17, RFC 12139, March 1991.

[Ref9] Moy, J., “OSPF Version 2”, RFC 158310, March 1994.

[Ref10] Fuller, V., T. Li, J. Yu, and K. Varadhan, “Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy”, RFC151911, September 1993.

[Ref11] Reynolds, J., and J. Postel, “Assigned Numbers”, STD 2, RFC 170012, October 1994.

[Ref12] Almquist, P., “Type of Service in the Internet Protocol Suite”, RFC 134913, July 1992.

[Ref13] Leiner, B., et.al., “The DARPA Internet Protocol Suite”, DDN Protocol Handbook, April 1985.

[Ref14] Bradley, T., and C. Brown, “Inverse Address Resolution Protocol”, RFC 1293, January 1992.

[Ref15] deSouza, O., and M. Rodrigues, “Guidelines for Running OSPF Over Frame Relay Networks”, RFC 1586, March 1994.

[Ref16] Bellovin, S., “Security Problems in the TCP/IP Protocol Suite”, ACM Computer Communications Review, Volume 19, Number 2, pp. 32-38, April 1989.

[Ref17] Rivest, R., “The MD5 Message-Digest Algorithm”, RFC 13215, April 1992.

[Ref18] Moy, J., “Multicast Extensions to OSPF”, RFC 1584, March 1994.

[Ref19] Coltun, R., and V. Fuller, “The OSPF NSSA Option”, RFC 1587, March 1994.

[Ref20] Ferguson, D., “The OSPF External Attributes LSA”, work in progress.

[Ref21] Moy, J., “Extending OSPF to Support Demand Circuits”, RFC 1793, April 1995.

[Ref22] Mogul, J., and S. Deering, “Path MTU Discovery”, RFC 1191, November 1990.

[Ref23] Rekhter, Y., and T. Li, “A Border Gateway Protocol 4 (BGP-4)”, RFC 177115, March 1995.

[Ref24] Hinden, R., “Internet Routing Protocol Standardization Criteria”, BBN, October 1991.

[Ref25] Moy, J., “OSPF Version 2”, RFC 217816, July 1997.

[Ref26] Rosen, E., “Vulnerabilities of Network Control Protocols: An Example”, Computer Communication Review, July 1981.

Приложения

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

В этом приложении описаны форматы пакетов OSPF и анонсов OSPF LSA. Протокол OSPF работает непосредственно поверх протокола сетевого уровня IP. Перед описанием форматов детально рассматривается инкапсуляция OSPF.

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

Форматы пакетов OSPF описаны в разделе A.3, а описание LSA дается в разделе A.4.

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

OSPF работает непосредственно поверх протокола IP и пакеты OSPF, следовательно, инкапсулируются с использованием только заголовков IP и канального уровня.

OSPF не определяет способа фрагментации для своих пакетов и полагается на фрагментацию IP при передаче в сетях с малым значением MTU. При необходимости размер пакетов OSPF может достигать 65 535 байтов (включая заголовок IP). Пакеты тех типов OSPF, которые могут достигать большого размера (DD, LSR, LSU и LSAck), обычно можно разделить на несколько более мелких пакетов без потери функциональности. Рекомендуется поступать именно так, избегая фрагментации IP. По тем же причинам следует предпринимались попытки ограничения размера пакетов OSPF, передаваемых через виртуальные соединения, значением 576 байтов, пока не используется Path MTU Discovery [Ref22].

Другими важными особенностями инкапсуляции OSPF являются:

  • Использование IP multicast. Некоторые сообщения OSPF являются групповыми при их передаче через широковещательные сети. Используются два разных адреса для групповой передачи. Передаваемые с использованием этих адресов пакеты не должны пересылаться, это значит, что они передаются только на один интервал (hop). Для предотвращения дальнейшей пересылки должно ограничиваться время жизни пакетов (TTL = 1).

AllSPFRouters

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

AllDRouters

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

  • Протокол OSPF имеет в IP номер 89, зарегистрированный в NIC. Распределение номеров для протоколов IP описано в [Ref11].

  • Все служебные пакеты OSPF передаются с использованием значения TOS для нормального обслуживания (0000 в соответствии с работой [Ref12]).
  • Для пакетов протокола маршрутизации уровень предпочтений IP устанавливается в Internetwork Control. Пакеты OSPF должны иметь преимущество перед обычными пакетами данных IP как для приема, так и для передачи. Установка в поле IP precedence заголовка IP значения Internetwork Control [Ref5] помогает обеспечить такое преимущество.

A.2 Поле Options

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

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

В поле OSPF Options выделены 5 битов, хотя данная спецификация полностью описывает только один из них (E). Краткое описание всех флагов приведено ниже. Маршрутизатор должен сбрасывать в 0 нераспознанные биты поля Options при передаче пакетов Hello и DD, а также при генерации LSA. Маршрутизатор, получивший неизвестные биты опций в пакетах Hello и DD или анонсах LSA, должен игнорировать эти биты, обрабатывая известные флаги как обычно.

+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+

Поле Options

E

Описывает способ лавинной рассылки AS-external-LSA (см. параграфы 3.6, 9.5, 10.8 и 12.1.2).

MC

Этот бит устанавливается при рассылке групповых (multicast) дейтаграмм IP в соответствии со спецификацией [Ref18].

N/P

Флаг обработки LSA типа 7 в соответствии с [Ref19].

EA

Флаг приема и пересылки анонсов External-Attributes-LSA в соответствии с [Ref20].

DC

Флаг обработки demand circuit в соответствии с [Ref21].

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

Существует 5 различных форматов пакетов OSPF. Все пакеты OSPF начинаются со стандартного 24-байтового заголовка, описанного в следующем параграфе. После заголовка описаны форматы каждого типа пакетов и рассмотрены поля этих пакетов.

Пакеты OSPF всех типов за исключением пакетов Hello, предназначены для работы со списками LSA. Например, пакеты LSU обеспечивают лавинную рассылку LSA в домене маршрутизации OSPF. По этой причине пакеты протокола OSPF невозможно разобрать, не понимая форматов LSA, описанных в разделе A.4.

Обработка принимаемых пакетов OSPF описана в параграфе 8.2, а передача пакетов OSPF – в параграфе 8.1.

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version #   |     Type      |         Packet length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Router ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Area ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |             AuType            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version #

Номер версии протокола OSPF. Данная спецификация описывает версию 2.

Type

Типы пакетов OSPF перечислены в таблице справа и описаны в параграфах A.3.2 – A.3.6.

Тип    Название
________________________________
1      Hello
2      Database Description
3      Link State Request
4      Link State Update
5      Link State Acknowledgment

Packet length

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

Router ID

Идентификатор Router ID отправителя пакета.

Area ID

32-битовый идентификатор области, к которой относится пакет. Все пакеты OSPF связываются с определенной (единственной) областью. Большинство пакетов передается лишь на один интервал (hop). Пакеты, передаваемые через виртуальные каналы, помечают идентификатором магистральной области 0.0.0.0.

Checksum

Стандартная контрольная сумма IP для всего пакета, начиная с заголовка OSPF, но без учета 64-битового поля аутентификации. Если длина пакета не равна целому числу 16-битовых слов, пакет дополняется справа соответствующим числом нулей до вычисления контрольной суммы. Определение контрольной суммы рассматривается как часть процесса аутентификации, но для некоторых типов аутентификации подсчет контрольной опускается.

AuType

Определяет используемую для пакета процедуру аутентификации (см. Приложение D).

Authentication

 64-битовое поле, используемое схемой аутентификации (см. Приложение D).

A.3.2 Пакет Hello

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

Для всех маршрутизаторов, подключенных к общей сети, должны быть согласованы параметры Network mask, HelloInterval и RouterDeadInterval. Эти параметры включаются в пакеты Hello, поэтому рассогласование может влиять на формирование соседских отношений. Подробное описание обработки приема пакетов Hello приведено в параграфе 10.5, а передача пакетов Hello описана в параграфе 9.5.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version #   |       1       |         Packet length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Router ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Area ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |             AuType            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Network Mask                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         HelloInterval         |    Options    |    Rtr Pri    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     RouterDeadInterval                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Designated Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Backup Designated Router                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Neighbor                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

Network mask

Маска сети, связанной с интерфейсом. Например, сети класса B имеют маску 0xffffff00.

Options

Дополнительные возможности, поддерживаемые маршрутизатором (см. параграф A.2).

HelloInterval

Число секунд между передачей пакетов Hello.

Rtr Pri

Значение Router Priority для маршрутизатора, используемое при выборе (Backup) DR. Нулевое значение блокирует возможность стать (Backup) DR.

RouterDeadInterval

Число секунд до объявления «затихшего» маршрутизатора неработоспособным.

Designated Router

Указывает выделенный маршрутизатор DR для данной сети с точки зрения передающего маршрутизатора. DR идентифицируется по IP-адресу в сети. Если маршрутизатора DR нет, поле имеет значение 0.0.0.0.

Backup Designated Router

Идентифицирует маршрутизатор Backup DR с точки зрения передающего пакет маршрутизатора. Backup DR идентифицируется адресом IP для интерфейса в данную сеть. При отсутствии Backup DR это поле содержит значение 0.0.0.0.

Neighbor

Значения Router ID для каждого маршрутизатора, чьи пакеты Hello были недавно (RouterDeadInterval секунд) видны в сети.

A.3.3 Пакет Database Description

Пакеты DD относятся в OSPF к типу 2. Обмен этими пакетами происходит при инициализации отношений смежности. Пакеты описывают содержимое базы данных о каналах. Для описания базы данных может использоваться множество пакетов с использованием процедуры poll-response (опрос-отклик). Один из маршрутизаторов является ведущим (master), а второй – ведомым (slave). Ведущий маршрутизатор передает пакеты DD, которые подтверждаются пакетами DD от ведомого маршрутизатора. Отклики связываются с опросом через порядковые номера пакетов DD.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version #   |       2       |         Packet length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Router ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Area ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |             AuType            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Interface MTU         |    Options    |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     DD sequence number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-                                                             -+
|                                                               |
+-                      An LSA Header                          -+
|                                                               |
+-                                                             -+
|                                                               |
+-                                                             -+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

Формат пакетов DD очень похож на формат пакетов LSR и LSAck. Все эти три типа пакетов содержат список элементов, каждый из которых описывает часть базы данных о каналах маршрутизатора. Передача пакетов DD описана в параграфе 10.8, а обработка принимаемых пакетов DD – в параграфе 10.6.

Interface MTU

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

Options

Дополнительные возможности маршрутизатора (см. параграф A.2).

I

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

M

Бит More, указывающий на присутствие других (последующих) пакетов DD.

MS

Бит Master/Slave, определяющий отношения маршрутизаторов в процессе Database Exchange (MS=1 – ведущий, 0 – ведомый).

DD sequence number

Используется для нумерации пакетов DD. Начальное значение (указывается флагом Init) должно быть уникальным. Далее порядковый номер DD увеличивается на 1 для каждого пакета вплоть до передачи всей базы данных.

Остальная часть пакета содержит (возможно неполный) список частей базы данных link-state. Каждая запись LSA в базе описывается заголовком LSA (см. параграф A.4.1), содержащим все данные для уникальной идентификации LSA и текущего экземпляра.

A.3.4 Пакет Link State Request

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

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

Каждый запрошенный анонс LSA указывается его типом, а также значениями Link State ID и Advertising Router. Эти параметры уникально описывают LSA, но не конкретный экземпляр анонса. Понятно, что пакеты LSR используются для запроса последнего экземпляра анонса.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version #   |       3       |         Packet length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Router ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Area ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |             AuType            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          LS type                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Link State ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Advertising Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

A.3.5 Пакет Link State Update

Пакеты LSU относятся в OSPF к типу 4 и используются для лавинной рассылки LSA. Каждый пакет LSU передает набор LSA на один интервал от точки их происхождения. В одном пакете может содержаться множество LSA.

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version #   |       4       |         Packet length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Router ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Area ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |             AuType            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            # LSAs                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-                                                            +-+
|                             LSAs                              |
+-                                                            +-+
|                              ...                              |

# LSAs

Число LSA, включенных в этот пакет обновления.

Тело пакетов LSU содержит список LSA, начинающихся со стандартного 20-байтового заголовка, описанного в A.4.1. Описания различных типов LSA приведены в A.4.

A.3.6 Пакет Link State Acknowledgment

Пакеты LSAck относятся в OSPF к типу 5. Для обеспечения надежности лавинной рассылки LSA, все анонсы должны подтверждаться в явной форме. Подтверждения обеспечиваются с помощью пакетов LSAck, каждый из которых может подтверждать прием множества LSA.

В зависимости от состояния передающего интерфейса и отправителя соответствующего пакета LSU, пакеты LSAck передаются по групповым (AllSPFRouters или AllDRouters) или индивидуальным адресам. Передача пакетов LSAck описана в параграфе 13.5, а обработка принятых пакетов – в параграфе 13.7.

Формат пакетов подтверждения поход на формат пакетов DD. Тело пакета просто содержит список заголовков подтверждаемых LSA.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Version #   |       5       |         Packet length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Router ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Area ID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Checksum            |             AuType            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Authentication                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+-                                                             -+
|                                                               |
+-                         An LSA Header                       -+
|                                                               |
+-                                                             -+
|                                                               |
+-                                                             -+
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

Каждый подтверждаемый анонс LSA описывается заголовком LSA (см. параграф A.4.1), содержащим все сведения для идентификации LSA и текущего экземпляра.

A.4 Форматы LSA

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

Каждый LSA описывает часть маршрутного домена OSPF. Каждый маршрутизатор порождает router-LSA. В дополнение к этому при выборе маршрутизатора в качестве Designated Router, этот маршрутизатор порождает network-LSA. Кроме того, маршрутизаторы могут порождать и другие типы LSAs (см. Параграф 12.4). Для всех LSA выполняется лавинная рассылка через домен маршрутизации OSPF. Алгоритм лавинной рассылки является надежным способом обеспечения доставки всем маршрутизаторам одного набора LSA. Дополнительные сведения о лавинной маршрутизации приведены в главе 13. Рассылаемый набор LSA называют базой данных о состоянии каналов.

Из базы данных о состоянии каналов каждый маршрутизатор создает дерево кратчайших путей с собой в качестве корня. Это дает в результате таблицу маршрутизации (см. главу11). Детальное описание процесса построения таблицы маршрутизации дано в главе 16.

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            LS age             |    Options    |    LS type    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Link State ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Advertising Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     LS sequence number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         LS checksum           |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LS age

Время (в секундах) с момента генерации LSA.

Options

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

Тип LS    Описание
___________________________________
1         Router-LSA
2         Network-LSA
3         Summary-LSA (сеть IP)
4         Summary-LSA (ASBR)
5         AS-external-LSA

LS type

Тип LSA, определяющий формат анонса. Определенные в данной спецификации типы LSA показаны в таблице справа и описаны в параграфе 12.1.3.

Link State ID

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

Advertising Router

Значение Router ID маршрутизатора, породившего LSA (в network-LSA это поле содержит Router ID маршрутизатора DR).

LS sequence number

Порядковый номер служит для обнаружения дубликатов и старых LSA. Следующий экземпляр LSA имеет следующий порядковый номер (см. параграф 12.1.6).

LS checksum

Контрольная сумма Флэтчера (Fletcher) для всего содержимого LSA, включая заголовок LSA, но без учета поля возраста LS Детальное описание приведено в параграфе 12.1.7.

length

Размер LSA в байтах с учетом 20-байтового заголовка LSA.

A.4.2 Router-LSA

Router-LSA относятся к типу 1 и порождаются каждым маршрутизатором области. Эти LSA описывают состояние и стоимость каналов (интерфейсов) маршрутизатора в область. Все каналы маршрутизатора в область должны описываться в одном анонсе router-LSA. Описание router-LSA приведено в параграфе 12.4.1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            LS age             |     Options   |       1       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Link State ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Advertising Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     LS sequence number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         LS checksum           |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    0    |V|E|B|        0      |            # links            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Link ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Link Data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     # TOS     |            metric             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      TOS      |        0      |          TOS  metric          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Link ID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Link Data                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

В router-LSA поле Link State ID содержит OSPF Router ID. Анонсы Router-LSA рассылаются в пределах области.

V

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

E

Этот флаг устанавливается для граничных маршрутизаторов AS (E – external).

B

Этот флаг устанавливается для граничных маршрутизаторов области (B – border).

# links

Число каналов маршрутизатора, описываемых в LSA (должно совпадать в числом интерфейсов маршрутизатора в область).

Перечисленные ниже поля используются для описания каждого канала (т. е., интерфейса) маршрутизатора. Каждый канал имеет определенный тип (поле Type) – канал в транзитную сеть, к другому маршрутизатору или в тупиковую сеть. Значения всех остальных полей, описывающих канал маршрутизатора, зависят от типа канала. Например, каждый канал имеет связанное с ним 32-битовое поле Link Data. Для каналов в тупиковые сети это поле содержит маску адреса, а для остальных типов – IP-адрес интерфейса маршрутизатора.

Type

Краткое описание канала маршрутизатора (см. таблицу справа) Отметим, что маршруты к хостам классифицируются как каналы в тупиковые сети с маской 0xffffffff.

Тип Идентификатор
1 Router ID соседнего маршрутизатора
2 IP-адрес маршрутизатора DR
3 IP-номер сети/подсети
4 Router ID соседнего маршрутизатора

Link ID

Идентифицирует объект, к которому подключен маршрутизатор. Содержимое поля зависит от типа соединения (поле Type). При соединении с объектом, генерирующим LSA (другой маршрутизатор или транзитная сеть) поле Link ID содержит значение Link State ID из LSA соседа. Это обеспечивает ключ поиска LSA соседей в базе данных при расчете таблицы маршрутов (см. 12.2).

Тип Идентификатор
1 Router ID соседнего маршрутизатора
2 IP-адрес маршрутизатора DR
3 IP-номер сети/подсети
4 Router ID соседнего маршрутизатора

Link Data

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

# TOS

Число различных метрик TOS, заданных для данного соединения, без учета требуемой метрики канала (обозначается как метрика TOS 0, [Ref9]). Например, при отсутствии дополнительной метрики TOS это поле имеет значение 0.

metric

Стоимость использования этого канала маршрутизатора.

В анонс может также включаться дополнительная информация, связанная с TOS и используемая для совместимости с предыдущими версиями OSPF [Ref9]. Для каждого канала, которому нужна информация TOS, могут использоваться следующие поля:

TOS

Тип сервиса (Type of Service), к которому относится метрика. Представление TOS в OSPF LSA описано в параграфе 12.3.

TOS metric

Связанная с TOS метрическая информация.

A.4.3 Network-LSA

Network-LSA относятся к типу 2 и генерируются для каждой широковещательной и NBMA-сети в области, поддерживающей более 1 маршрутизатора. Анонсы network-LSA порождаются выделенным маршрутизатором DR и описывают все подключенные к сети маршрутизаторы, включая DR. Поле Link State ID содержит IP-адрес интерфейса DR. Дистанция от сети до всех подключенных маршрутизаторов равна 0, поэтому поле метрики не включается в network-LSA. Описание network-LSA дано в параграфе 12.4.2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            LS age             |      Options  |      2        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Link State ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Advertising Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     LS sequence number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         LS checksum           |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Network Mask                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Attached Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

Network Mask

Адресная маска сети (например, IP-сеть класса A имеет маску 0xff000000).

Attached Router

Идентификаторы Router ID каждого из подключенных к сети маршрутизаторов. Реально перечисляются только маршрутизаторы, установившие полные отношения смежности с DR, и сам маршрутизатор DR. Число включенных в список маршрутизаторов можно определить из поля длины в заголовке LSA.

A.4.4 Summary-LSA

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

Анонсы summary-LSA типа 3 используются в тех случаях, когда адресатом является сеть IP. В этом случае поле Link State ID содержит IP-номер сети (при необходимости Link State ID может включать также биты адреса хоста, как описано в Приложении E). Когда адресатом является граничный маршрутизатор AS, используется summary-LSA типа 4 и поле Link State ID содержит OSPF Router ID граничного маршрутизатора AS (необходимость анонсирования местоположения каждого ASBR рассмотрена в параграфе 16.4.). За исключением различий в использовании поля Link State ID анонсы summary-LSA типов 3 и 4 идентичны.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            LS age             |     Options   |    3 or 4     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Link State ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Advertising Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     LS sequence number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         LS checksum           |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Network Mask                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      0        |                  metric                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TOS       |                TOS  metric                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

Для тупиковых областей summary-LSA типа 3 могут также использоваться для описания принятых по умолчанию маршрутов (по областям). Такие маршруты используются в тупиковых областях взамен лавинной рассылки полного набора внешних маршрутов. При описании используемого по умолчанию маршрута поле Link State ID в summary-LSA всегда содержит значение DefaultDestination (0.0.0.0), а Network Mask = 0.0.0.0.

Network Mask

Для summary-LSA типа 3 это поле показывает маску сети адресата. Например, при анонсировании адресата из сети класса A будет использоваться значение 0xff000000. Это поле не используется в summary-LSA типа 4 и должно иметь нулевое значение.

metric

Стоимость маршрута, выраженная в таких же единицах, как стоимость в анонсах router-LSA.

Дополнительная информация, связанная с TOS, может включаться для обеспечения обратной совместимости с предыдущей версией OSPF [Ref9]. Для всех желаемых уровней TOS информация представляется следующим образом:

TOS

Тип сервиса (Type of Service), к которому относится метрика. Представление TOS в OSPF LSA описано в параграфе 12.3.

TOS metric

Связанная с TOS метрическая информация.

A.4.5 AS-external-LSA

AS-external-LSA относятся к типу 5 и генерируются граничными маршрутизаторами AS для описания внешних маршрутов из AS. Детальное описание AS-external-LSA приведено в параграфе 12.4.3.

Анонсы AS-external-LSA обычно описывают маршрут к отдельному адресату (сети). Для таких LSA поле Link State ID содержит IP-номер сети (при необходимости в него могут также включаться некоторые биты адреса хоста, как описано в Приложении E). Анонсы AS-external-LSA также используются для описания принятых по умолчанию маршрутов (эти маршруты применяются в случае отсутствия другого пути к адресату). В таких случаях поле Link State ID всегда содержит значение DefaultDestination (0.0.0.0), а поле Network Mask имеет значение 0.0.0.0.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            LS age             |     Options   |      5        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Link State ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Advertising Router                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     LS sequence number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         LS checksum           |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Network Mask                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|     0       |                  metric                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Forwarding address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      External Route Tag                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|    TOS      |                TOS  metric                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Forwarding address                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      External Route Tag                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |

Network Mask

Адресная маска IP для анонсируемого получателя. Например, для сети класса A маска имеет значение 0xff000000.

E

Тип внешней метрики. E=1 говорит о внешней метрике типа 2, которая заведомо больше метрики любого из внутренних путей. E=0 говорит о внешней метрике типа 1, использующей такие же единицы, как и внутренняя метрика link state.

metric

Стоимость маршрута. Интерпретация этого поля зависит индикации типа внешней метрики (бит E).

Forwarding address

Пакеты данных для анонсируемого получателя будут пересылаться по этому адресу. Если Forwarding address = 0.0.0.0, пакеты будут пересылаться породившему LSA маршрутизатору (т. е., граничному маршрутизатору AS).

External Route Tag

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

Для совместимости с предыдущими версиями OSPF [Ref9] может включаться информация, связанная с TOS. Для каждого желаемого значения TOS эта информация представляется следующим образом:

TOS

Тип обслуживания для следующих полей. Кодирование значений TOS в анонсах OSPF LSA описано в параграфе 12.3.

E

Используется для совместимости с [Ref9].

TOS metric

Связанная с TOS метрика.

Forwarding address

Используется для совместимости с [Ref9].

External Route Tag

Для совместимости с [Ref9].

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

Некоторые параметры протокола OSPF имеют фиксированные значения (архитектурные константы). Предпочтительно для указания таких параметров в тексте использовать их имена (например, LSRefreshTime). Для настраиваемых параметров протокола также используются имена, описанные в Приложении C.

Ниже перечислены имена архитектурных констант, их значения и краткие комментарии.

LSRefreshTime

Максимальный интервал между двумя генерациями отдельного анонса LSA. Если поле возраста одного из порожденных маршрутизатором анонсов LSA достигает значения LSRefreshTime, генерируется новый экземпляр LSA, даже при отсутствии изменений в содержимом LSA (за исключением заголовка LSA). Значение LSRefreshTime составляет 30 минут.

MinLSInterval

Минимальный интервал между двумя генерациями отдельного анонса LSA. Значение MinLSInterval составляет 5 секунд.

MinLSArrival

Для любого анонса LSA этот параметр задает минимальное время до восприятия нового анонса LSA в процессе лавинной рассылки. Экземпляры LSA, полученные раньше, отбрасываются. Для MinLSArrival установлено значение 1 секунда.

MaxAge

Максимальный возраст LSA. Если LS age = MaxAge, анонс LSA повторно рассылается в лавинном режиме в целях удаления из домена маршрутизации (см. главу 14). LSA с возрастом MaxAge не используются при расчете таблицы маршрутов. Используйте для MaxAge значение 1 час.

CheckAge

Если возраст LSA в базе данных многократно запрашивается в течение периода CheckAge, нужно проверить контрольную сумму LSA. Расхождение в контрольной сумме говорит о серьезной ошибке. Значение CheckAge составляет 5 минут.

MaxAgeDiff

Максимальная дисперсия (расхождение) во времени лавинной рассылки LSA в автономной области. Большую часть этого времени занимает пребывание LSA в выходных очередях маршрутизаторов (без старения) в процессе лавинной рассылки. Значение MaxAgeDiff составляет 15 минут.

LSInfinity

Значение метрики, используемое для недоступных адресатов в анонсах LSA. Это значение используется для summary-LSA и AS-external-LSA как альтернатива принудительному старению (см. параграф 14.1). Значение LSInfinity составляет 0xffffff.

DefaultDestination

Значение Destination ID, указывающее принятый по умолчанию маршрут (используется при отсутствии других путей у адресату). Принятые по умолчанию маршруты анонсируются только в AS-external-LSA и summary-LSA типа 3 тупиковых областей. Для маршрута по умолчанию IP имеет значение 0.0.0.0 и связанное с ним поле Network Mask также содержит 0.0.0.0.

InitialSequenceNumber

Значение, используемое в качестве порядкового номера (LS Sequence Number) при создании первого анонса LSA – 0x80000001.

MaxSequenceNumber

Максимальное значение порядкового номера LSA (LS Sequence Number) – 0x7fffffff (целое число со знаком).

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

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

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

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

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

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

Router ID

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

RFC1583Compatibility

Управляет правилами выбора предпочтений (параграф 16.4) при наличии множества анонсов AS-external-LSA для одного адресата. Значение enabled задает использование предпочтений в соответствии с RFC 1583 ([Ref9]), а для отключенной совместимости (disabled) используются правила, описанные в параграфе 16.4.1, которые предотвращают возникновение петель, когда AS-external-LSA для одного получателя происходят из разных областей. По умолчанию установлен режим enabled.

Для снижения вероятности возникновения петель все маршрутизаторы в домене OSPF должны иметь одинаковое значение параметра RFC1583Compatibility. Если в домене присутствуют маршрутизаторы, не поддерживающие функций, описанных в параграфе 16.4.1, должно использоваться значение RFC1583Compatibility = enabled. В остальных случаях следует устанавливать значение disabled для предотвращения петель.

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

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

Area ID

32-битовый идентификатор области, записываемый обычно по аналогии с IP- адресами. Значение 0.0.0.0 зарезервировано для магистрали AS. Если область представляет сеть, разбитую на подсети, в качестве Area ID может служить IP-номер сети.

List of address ranges

Область OSPF определяется как список адресных диапазонов вида:

[IP address, mask]

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

Status

Имеет значение Advertise или DoNotAdvertise. Маршрутная информация рассматривается на границе области. За пределы области анонсируется по крайней мере один маршрут (в summary-LSA) для каждого диапазона адресов. Маршрут анонсируется тогда и только тогда, когда Status = Advertise. Неанонсируемые диапазоны позволяют иметь сети, спрятанные от других областей. По умолчанию Status = Advertise.

В качестве примера предположим, что поделенная на подсети сеть IP является областью OSPF. Область указана как диапазон адресов, в котором выделены адреса подсетей IP с естественными масками класса A, B или C. За пределы области может анонсироваться один маршрут, описывающий всю сеть (вместе с подсетями).

ExternalRoutingCapability

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

StubDefaultCost

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

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

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

IP interface address

IP-адрес интерфейса, являющийся уникальны идентификатором интерфейса в масштабе internet. Использования адресов IP не требуется для сетей point-to-point, которые по этой причине называют безадресными (unnumbered).

IP interface mask

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

Area ID

Область OSPF, к которой относится подключенная сеть.

Interface output cost

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

RxmtInterval

Число секунд между повторами передачи LSA для смежных маршрутизаторов, связанных с данным интерфейсом. Это значение используется также при повторе пакетов DD и LSR. Период повтора должен превышать время кругового обхода (round-trip delay) между двумя маршрутизаторами через подключенную сеть. При установке слишком малого значения будут возникать ненужные повторы. Для локальных сетей разумно использовать значение 5 секунд.

InfTransDelay

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

Router Priority

Беззнаковое 8-битовое число, используемое для выбора маршрутизатора на роль DR. Если два маршрутизатора выдвигают на эту роль себя, из них выбирается тот, у которого больше значение Router Priority. Если значения приоритета совпадают, выбирается маршрутизатор с большим значением Router ID. Маршрутизаторы с Router Priority = 0 не могут быть DR для подключенной сети. Параметр Router Priority задается только для интерфейсов в широковещательные и NBMA-сети.

HelloInterval

Период (в секундах) между передачей двух последовательных пакетов Hello через один интерфейс. Это значение анонсируется маршрутизатором в пакетах Hello и должно совпадать для всех подключенных к общей сети маршрутизаторов. Снижение HelloInterval ускоряет обнаружение топологических изменений, но увеличивает объем служебного трафика OSPF. Для сетей X.25 PDN рекомендуется значение 30 сек, для ЛВС – 10 сек.

RouterDeadInterval

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

AuType

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

Authentication key

Это поле данных позволяет проверить аутентичность пакетов протокола OSPF, принятых через интерфейс.

Например, если AuType указывает простой пароль, поле Authentication key будет содержать 64-битовую строку пароля в явном виде. Значение Authentication key для других типов аутентификации OSPF рассмотрено в Приложении D.

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

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

Виртуальный канал появляется в router-LSA (для магистрали) как отдельный интерфейс маршрутизатора в магистральную область. В связи с этим, он имеет все присущие интерфейсу параметры (см. параграф C.3). Хотя виртуальный канал работает подобно безадресному соединению «точка-точка», с ним всегда связан IP-адрес интерфейса. Этот адрес используется как адрес отправителя в пакетах OSPF, передаваемых через виртуальный канал, и устанавливается динамически в процессе построения таблицы маршрутизации. Выходная стоимость интерфейса также задается динамически и является стоимостью внутридоменного пути между двумя маршрутизаторами. Должен быть задан параметр RxmtInterval и требуется точная оценка времени кругового обхода (round-trip delay) между двумя маршрутизаторами. Такая оценка для виртуального канала может оказаться непростой, поэтому лучше поставить достаточно большое значение. Параметр Router Priority для виртуальных каналов не используется.

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

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

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

Однако, в силу ограниченных возможностей широковещания, может потребоваться дополнительная настройка для выбора DR. Конфигурационные параметры задаются только в тех маршрутизаторах, которые могут претендовать на роль DR (Router Priority > 0), при отсутствии процедуры автоматического обнаружения соседей. В число таких параметров входят:

List of all other attached routers

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

PollInterval

Если соседний маршрутизатор теряет активность (нет пакетов Hello в течение RouterDeadInterval сек.), может потребоваться передача пакетов Hello «мертвому» соседу. Эти пакеты будут передаваться с интервалом PollInterval, значительно превышающим HelloInterval. Разумным значением PollInterval для сетей PDN X.25 будет 2 мин.

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

В сетях Point-to-MultiPoint может потребоваться указание набора соседей, доступных напрямую через сеть Point-to-MultiPoint. Каждый сосед идентифицируется IP-адресом в сети Point-to-MultiPoint. Маршрутизаторы DR не задаются для сетей Point-to-MultiPoint, поэтому поле Designated Router eligibility не имеет смысла.

Соседей в сети Point-to-MultiPoint можно определять и с помощью протоколов нижних уровней (например, Inverse ARP – [Ref14]).

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

Маршруты к хостам анонсируются в router-LSA как маршруты в тупиковые сети с маской 0xffffffff. Такая маска говорит о подключении к сети point-to-point, закольцовывании интерфейса маршрутизатора или хосте IP, подключенном непосредственно к маршрутизатору (например, по каналу SLIP). Для каждого подключенного напрямую хоста должны задаваться следующие поля:

Host IP address

IP-адрес хоста.

Cost of link to host

Стоимость передачи пакета хосту в единицах метрики link state. Поскольку хосты в большинстве случаев имеют единственное подключение к internet, на практике эта стоимость часто не имеет значения (т. е., не влияет на маршрутизацию).

Area ID

Область OSPF, к которой относится хост.

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

Весь обмен данными протокола OSPF использует аутентификацию. Заголовок пакета OSPF (см. параграф A.3.1) включает поле типа аутентификации и 64-битовое поле данных, используемое соответствующей типу схемой аутентификации.

Тип аутентификации задается для каждого интерфейса (или, что эквивалентно, для сети/подсети). Дополнительные данные аутентификации также задаются для каждого интерфейса. В данной спецификации определены три типа аутентификации – 0, 1 и 2. Все остальные значения типа аутентификации зарезервированы для распределения IANA (iana@ISI.EDU). Список текущих значений приведен в таблице 23.

Таблица 23 Типы аутентификации OSPF.

AuType Описание
0 Без аутентификации (Null authentication)
1 Простой пароль
2 Криптографическая аутентификация
Прочие Зарезервированы для распределения IANA (iana@ISI.EDU)

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

Использование этого типа означает передачу пакетов через сеть/подсеть без аутентификации. 64-битовое поле аутентификации в заголовке OSPF не содержит информации и не проверяется на приемной стороне. При использовании Null-аутентификации все содержимое каждого пакета OSPF (за исключением 64-битового поля аутентификации) используется для расчета контрольной суммы, позволяющей детектировать ошибки.

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

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

Простая парольная аутентификация предотвращает неанонсированное присоединение маршрутизатора к домену маршрутизации – каждый маршрутизатор должен сначала предъявить установленный для сети пароль и только после проверки пароля возможно включение в домен маршрутизации. Однако простая парольная аутентификация уязвима для пассивных атак, часто встречающихся в Internet (см. [Ref16]). Любой человек, имеющий физический доступ в сеть, может узнать пароль и обойти систему безопасности домена маршрутизации OSPF.

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

При использовании криптографической аутентификации задается публичный ключ (shared secret key) для всех маршрутизаторов, подключенных к общей сети/подсети. Для каждого пакета OSPF используется ключ при генерации и проверке цифровых подписей (message digest), добавляемых в конце пакета OSPF. Цифровая подпись создается с помощью необратимой (one-way) функции на основе пакета OSPF и секретного ключа. Поскольку секретный ключ никогда не передается через сеть в открытом виде, это обеспечивает защиту против пассивных атак.

Таблица 24 Использование поля Authentication в заголовке пакетов OSPF с криптографической аутентификацией.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              0                |    Key ID     | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Cryptographic sequence number                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Алгоритм, используемый при генерации и проверке цифровой подписи, определяется секретным ключом. Данная спецификация полностью определяет применение криптографической аутентификации OSPF при использовании алгоритма MD5.

В дополнение к цифровой подписи используется неубывающий порядковый номер, включаемый в каждый пакет OSPF для защиты от replay-атак (подмена). Это обеспечивает высокий уровень защиты, однако сохраняется возможность подмены пакета OSPF пока изменяется порядковый номер. Для предотвращения такой возможности структура данных для каждого соседа содержит новое поле «криптографический порядковый номер» (cryptographic sequence number).

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

Данная спецификация не предлагает процедуры обновления порядкового номера после использования всего диапазона значений. Когда криптографический порядковый номер на передающем маршрутизаторе достигает максимального значения, маршрутизатор должен снова установить нулевое значение для порядкового номера. После такой операции соседний маршрутизатор будет отвергать пакеты OSPF в течение интервала RouterDeadInterval, о потом маршрутизаторы должны будут заново организовать отношения смежности через этот интерфейс. Однако предполагается, что во многих реализациях в качестве криптографического порядкового номера будет использоваться «число секунд с момента перезагрузки» (seconds since reboot) или аналогичное значение (например, seconds since 1960). Такой выбор будет в значительной мере решать проблему, поскольку для порядкового номера используется 32-битовое поле.

Криптографическая аутентификация OSPF не обеспечивает конфиденциальности.

При использовании криптографической аутентификации 64-битовое поле Authentication в стандартных заголовках пакетов OSPF используется несколько иначе (см. таблицу 24).

Key ID

Это поле идентифицирует алгоритм и секретный ключ, используемые для создания цифровой подписи, добавляемой к пакетам OSPF. Идентификаторы Key Id являются уникальными и задаются для каждого интерфейса (или, эквивалентно, для подсети).

Auth Data Len

Размер (в байтах) цифровой подписи (message digest), добавляемой к пакету OSPF.

Cryptographic sequence number

Беззнаковый 32-битовый порядковый номер, который может только увеличиваться и служит для предотвращения replay-атак.

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

Каждый ключ задается комбинацией интерфейса и поля Key ID. Интерфейс может иметь несколько активных ключей одновременно, что обеспечивает возможность простой и безопасной смены ключа. С каждым ключом связано 4 временных параметра, в которых может использоваться время суток (time-of-day) или время по локальным часам маршрутизатора (например, число секунд с момента перезагрузки):

KeyStartAccept

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

KeyStartGenerate

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

KeyStopGenerate

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

KeyStopAccept

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

Для упрощения смены ключей значение KeyStartAccept должно быть меньше KeyStartGenerate, а KeyStopGenerate меньше, чем KeyStopAccept. Если значения KeyStopGenerate и KeyStopAccept не заданы, время жизни ключа становится бесконечным. Когда новый ключ приходит на смену прежнему, время KeyStartGenerate для нового ключа должно быть не больше времени KeyStopGenerate для старого ключа.

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

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

После подготовки содержимого пакета OSPF вызывается процедура аутентификации, заданная для передающего интерфейса полем Autype. Процедура аутентификации вносит в пакет OSPF требуемые изменения.

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

При использовании Null-аутентификации пакет изменяется следующим образом:

  1. Для поля Autype в стандартном заголовке OSPF устанавливается значение 0.
  2. Поле контрольной суммы в стандартном заголовке OSPF содержит стандартную контрольную сумму IP всего содержимого пакета, начиная с заголовка OSPF, но без учета 64-битового поля аутентификации. Если длина пакета не равна целому числу 16-битовых слов, он дополняется справа соответствующим количеством нулей.

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

При использовании простого пароля пакет изменяется следующим образом:

  1. Для поля Autype в стандартном заголовке OSPF устанавливается значение 1.
  2. Поле контрольной суммы в стандартном заголовке OSPF содержит стандартную контрольную сумму IP всего содержимого пакета, начиная с заголовка OSPF, но без учета 64-битового поля аутентификации. Если длина пакета не равна целому числу 16-битовых слов, он дополняется справа соответствующим количеством нулей.
  3. 64-битовое поле аутентификации в стандартном заголовке пакета OSPF содержит 64-битовый пароль (ключ аутентификации), заданный для интерфейса.

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

При использовании криптографической аутентификации для интерфейса может быть указано несколько ключей. В таких случаях из числа ключей, корректных для генерации сообщений (KeyStartGenerate <= текущее время < KeyStopGenerate) выбирается ключ с самым последним значением KeyStartGenerate. Пакеты модифицируются с использованием этого ключа:

  1. Для поля Autype в стандартном заголовке OSPF устанавливается значение 2.
  2. Контрольная сумма не рассчитывается и соответствующее поле заголовка OSPF имеет нулевое значение.
  3. В поле Key ID (см. таблицу 24) устанавливается значение Key ID выбранного ключа.
  4. В поле Auth Data Len указывается размер (в байтах) цифровой подписи, которая будет добавляться к пакету OSPF. При использовании алгоритма MD5 поле Auth Data Len имеет значение 16.
  5. В 32-битовое поле криптографического порядкового номера (см. таблицу 24) помещается неубывающее значение (т. е., значение, по крайней мере равное последнему значению, переданному с использованием данного интерфейса). Выбор значений криптографического порядкового номера зависит от реализации (это может быть простой счетчик или значение, базирующееся на показаниях системных часов).
  6. Рассчитывается цифровая подпись и добавляется к пакету OSPF. Используемый для расчета алгоритм аутентификации указывается ключом. Исходными данными для расчета является содержимое пакета OSPF и секретный ключ. При использовании алгоритма MD5 цифровая подпись рассчитывается следующим образом:

    1. К пакету OSPF добавляется 16-байтовый ключ MD5.

    2. Добавляются поля заполнения в соответствии с [Ref17].
    3. Алгоритм MD5 используется для конкатенации пакета OSPF, секретного ключа, заполнения и поля длины, давая в результате 16-байтовую цифровую подпись (см. [Ref17]).
    4. Подпись MD5 записывается поверх ключа OSPF (т. е., добавляется в конце исходного пакета OSPF). Подпись не учитывается в поле длины в заголовке OSPF, но включается в длину пакета IP. Любые добавления или заполнение после подписи не учитываются и не передаются.

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

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

Если аутентичность принятого пакета OSPF подтверждена, продолжается обработка пакета, как описано в параграфе 8.2. Пакеты, не прошедшие аутентификацию, отбрасываются.

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

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

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

При использовании простой парольной аутентификации проверка пакетов OSPF происходит следующим образом:

  1. Должно проверяться поле контрольной суммы в заголовке OSPF (стандартная контрольная сумма IP). Если размер пакета не кратен 16 битам, он дополняется нулями справа до вычисления контрольной суммы.
  2. 64-битовое поле аутентификации в заголовке пакета OSPF должно содержать 64-битовый пароль (ключ аутентификации), заданный для интерфейса.

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

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

  1. Находится ключ, заданный для приемного интерфейса, имеющий значение Key ID, равное указанному в принятом пакете OSPF (см. таблицу 24). Если ключ не найден или некорректен (т. е., current time < KeyStartAccept или current time >= KeyStopAccept), пакет OSPF отбрасывается.
  2. Если криптографический порядковый номер, найденный в заголовке OSPF header (см. таблицу 24), меньше криптографического порядкового номера, записанного в структуре данных о соседе, пакет OSPF отбрасывается.
  3. Проверяется цифровая подпись, добавленная к пакету:

    1. Полученная подпись сохраняется отдельно.

    2. Рассчитывается новая подпись в соответствии с п. 6 параграфа D.4.3.
    3. Рассчитанное и полученное значения сравниваются. При несоответствии пакет OSPF отбрасывается. Если подписи совпадают, пакет считается аутентичным и в поле cryptographic sequence number структуры данных о соседе помещается порядковый номер из заголовка пакета OSPF.

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

Поле Link State ID в записях AS-external-LSA и summary-LSA обычно содержит IP-адрес описываемой сети. Однако при необходимости это поле может включать также биты адреса хоста. Это позволяет маршрутизатору разделять LSA для сетей с одинаковым номером, но разными масками, которые могут встречаться при использовании сверхсетей и «нулевых» подсетей (см. [Ref10]).

В этом приложении рассматривается один из возможных алгоритмов установки битов адреса хоста в поле Link State ID. Выбор подходящего алгоритма не задается спецификацией и определяется локально. Разные маршрутизаторы могут использовать различные алгоритмы, поскольку этот выбор влияет только на LSA, генерируемые данным маршрутизатором. Единственным требованием к алгоритму является использование по возможности IP-номера сети в качестве значения поля Link State ID, поскольку это повышает уровень интероперабельности с реализациями OSPF, предшествующими RFC 1583.

Описанный ниже алгоритм описан на примере AS-external-LSA, но может использоваться и для summary-LSA. Предположим, что маршрутизатор хочет сгенерировать анонс AS-external-LSA для сети, имеющей адрес NA и маску NM1. Для определения Link State ID выполняются следующие операции:

  1. Выясняется генерировал ли маршрутизатор ранее AS-external-LSA с Link State ID = NA (в таких LSA маршрутизатор будет указываться как Advertising Router). Если этого не было, устанавливается Link State ID = NA и работа алгоритма завершается.
  2. Определяется маска сети из тела уже существующих AS-external-LSA (обозначим эту маску NM2). Возможны 2 случая:
    • NM1 больше, чем NM2 (сетевая часть адреса содержит больше битов). В этом случае устанавливаем для поля Link State ID в новом анонсе LSA значение [NA,NM1] со всеми дополнительными битами из адреса хоста (т. е., NA OR NOT NM1 или объединение номера сети с широковещательным адресом сети [NA,NM1]).
    • NM2 больше по сравнению с NM1. В этом случае изменяем существующий анонс LSA (Link State ID = NA), чтобы он указывал на новую сеть [NA,NM1], увеличиваем порядковый номер, а также изменяем маску в теле анонса на NM1 и вставляем значение стоимости для новой сети. После этого генерируется новый анонс LSA для старой сети [NA,NM2] с Link State ID = NA, плюс биты, которые отсутствуют в маске NM2 (широковещательный адрес [NA,NM2]).

Описанный выше алгоритм предполагает, что все маски являются непрерывными – для двух сетей с одним номером в таких случаях одна маска будет более специфична17, нежели другая. Предполагается также, что не существует сетей, имеющих адрес, который совпадает с широковещательным адресом другой сети. С учетом этих предположений описанный выше алгоритм всегда обеспечивает уникальное значение Link State ID. Этот алгоритм можно описать другими словами. При генерации AS-external-LSA пытаемся использовать номер сети в качестве Link State ID. При возникновении конфликта проверяются конфликтующие сети, одна из которых будет подмножеством другой. Для более широкой сети используем в качестве Link State ID номер сети, а для другой сети используем широковещательный адрес (т. е., устанавливаем 1 для всех битов «адреса хоста»). Если более узкая сеть обрабатывается раньше, придется генерировать два анонса LSA сразу.

В качестве примера использования алгоритма рассмотрим его работу при описанной ниже последовательности событий в одном маршрутизаторе (Router A).

  1. Router A хочет сгенерировать анонс AS-external-LSA для сети [10.0.0.0,255.255.255.0]:

    1. Используется Link State ID = 10.0.0.0.
  2. Router хочет породить AS-external-LSA для сети [10.0.0.0,255.255.0.0]:
    1. LSA для [10.0.0,0,255.255.255.0] генерируется заново с Link State ID = 10.0.0.255.
    2. Для сети [10.0.0.0,255.255.0.0] используется Link State ID = 10.0.0.0.
  3. После этого маршрутизатор Router A хочет сгенерировать AS-external-LSA для [10.0.0.0,255.0.0.0]:

    1. Заново порождается LSA для сети [10.0.0.0,255.255.0.0] с новым значением Link State ID = 10.0.255.255.
    2. Для сети [10.0.0.0,255.0.0.0] используется Link State ID = 10.0.0.0.
    3. Для сети [10.0.0.0,255.255.255.0] сохраняется Link State ID = 10.0.0.255.

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

Существует по крайней мере два способа поддержки множества физических интерфейсов в одну подсеть IP. Оба метода будут интероперабельны с RFC 1583 (и, естественно, с данной спецификацией). Ниже кратко описаны два способа в предположении что каждому интерфейсу выделен свой IP-адрес (в противном случае вопрос поддержки множества интерфейсов переносится скорее на канальный уровень или уровень ARP).

Метод 1:

Все функции OSPF поддерживаются на обоих интерфейсах (прием и передача приветствий, лавинная рассылка, поддержка раздельных FSM для интерфейса и соседа и т. п.). Все остальные маршрутизаторы подсети будут трактовать эти интерфейсы как разных соседей, идентифицируемых (в широковещательных и NBMA-сетях) по их IP-адресам.

Метод 1 имеет следующие недостатки:

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

Метод 2:

Протокол OSPF работает только на одном интерфейсе (назовем его основным или первичным), но в Router-LSA включаются оба интерфейса.

Метод 2 также имеет недостатки:

  1. Теряется проверка двунаправленности для вторичного интерфейса.
  2. При отказе основного интерфейса требуется перевести второй интерфейс в состояние основного.

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

В этом приложении рассмотрены различия между данной спецификацией и RFC 2178. Все различия являются обратно совместимыми. Реализации данной спецификации и RFC 2178, 1583, 1247 будут интероперабельны.

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

В процедуру лавинной рассылки (глава 13) внесено три изменения.

  1. Этап 4 параграфа 13. Анонсы LSA возраста MaxAge подтверждаются и после этого отбрасываются только при выполнении двух условий: a) в базе данных нет копии LSA и b) ни один из соседних маршрутизаторов не находится в состоянии Exchange или Loading. Во всех прочих случаях LSA с возрастом MaxAge обрабатываются подобно остальным LSA – устанавливаются в базу данных и рассылаются в лавинном режиме через подходящий интерфейс, когда копия в базе данных более старая (этап 5 в параграфе 13). Эти изменения влияют на содержимое таблицы 22.
  2. Этап 5a в параграфе 13. Проверка MinLSArrival выполняется только для LSA, полученных в процессе лавинной рассылка и не должна применяться к собственным LSA маршрутизатора.
  3. Этап 8 в параграфе 13. Конфликт между маршрутизаторами при определении более свежего экземпляра LSA может приводить к катастрофической лавинной рассылке для протоколов link-state [Ref26]. OSPF решает эту проблему двумя способами: a) возраст LSA используется при лавинной рассылке подобно TTL, что позволяет устранять «петли LSA» в сети (см. параграф 13.3) и b) маршрутизаторы не воспринимают обновлений LSA с периодом меньше MinLSArrival секунд (см. параграф 13). Однако сохраняется одна ситуация в RFC 2178, когда несогласие в определении более свежего экземпляра LSA может порождать излишнюю лавинную рассылку – отклик на старые LSA путем повтора лавинной рассылки копии из базы данных. По этой причине этап 8 в параграфе 13 был исправлен так, чтобы копия из базы данных рассылалась только в тех случаях, когда эта копия не передавалась ни в одном пакете LSU в течение последних MinLSArrival секунд.

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

Сохраняется возможность возникновения маршрутных петель в RFC 2178 при использовании виртуальных каналов, когда один и тот же внешний путь импортируется несколькими ASBR, относящимися к разным областям. Для решения этой проблемы был переработан параграф 16.4.1. При выборе корректного ASBR/адреса пересылки внутридоменные пути мимо магистрали всегда имеют предпочтение. Однако внутридоменные пути через магистраль (область 0) и междоменные пути имеют одинаковый уровень предпочтения и должны сравниваться с учетом их стоимости.

Изменения обусловлены следующими причинами. При использовании виртуальных каналов внутридоменный путь через магистраль для одного маршрутизатора может совпадать с междоменным путем другого маршрутизатора, лежащего на несколько интервалов (hop) ближе к адресату. Следовательно, внутридоменный магистральный путь и междоменный путь должны иметь одинаковый уровень предпочтений. Мы можем сравнивать стоимость таких путей, выбирая из них лучший (см. параграф 16.3).

Автор благодарит Michael Briggs и Jeremy McCooey из UNH InterOperability Lab, указавших на эту проблему.

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

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

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

Алгоритм поиска в таблице маршрутов (параграф 11.1) был изменен на основе реального опыта. Наиболее соответствующая (best match) запись маршрутной таблицы считается та, которая обеспечивает большее совпадение (наименьшая маска). Предположим для примера, что маршрутизатор пересылает пакеты для адреса 192.9.1.1. Запись в таблице для адресата 192.9.1/24 будет обеспечивать лучшее соответствие по сравнению с записью для 192.9/16, независимо от типов путей в таблице. Отметим, однако, что при наличии в маршрутной записи множества путей расчеты, описанные в 16.1, 16.2 и 16.4, всегда дают более предпочтительные пути (в порядке снижения предпочтений – внутридоменные, междоменные и внешние типа 1 и 2 – см. главу 11).

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

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

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

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

Дополнительную информацию можно найти в параграфах 8.1, 8.2 и Приложении D.

Адрес автора

John Moy

Ascend Communications, Inc.

1 Robbins Road

Westford, MA 01886

Phone: 978-952-1367

Fax: 978-392-2075

EMail: jmoy@casc.com


Перевод на русский язык

Николай Малых

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1 За счет хранения в таблице маршрутов дополнительной информации некоторые реализации могут ограничиться пересчетом дерева кратчайших путей для одной области. Существует алгоритм нарастающих изменений (incremental algorithm), который позволяет пересчитывать только часть дерева кратчайших путей одной области [Ref1]. Однако рассмотрение этого алгоритма выходит за пределы данной спецификации.

2 После опустошения списка Link state request сосед так или иначе переходит в состояние Full (см. параграф 10.9).

3 Анонсы LSA сравнительно редко достигают возраста MaxAge; обычно они заменяются новыми экземплярами раньше.

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

5Отметим, что достаточно наличия любого канала обратно к вершине V и не требуется, чтобы он был «обратной копией» канала от V к W. Достаточно обеспечить гарантию передачи данных между соседними маршрутизаторами для синхронизации баз данных.

6 Отличный от 0 адрес пересылки должен указывать на маршрутизатор, относящийся к другой AS (см. параграф 12.4.4).

7Перевод спецификации протокола IP вы можете найти на сайте www.protocols.ru. Прим. перев.

8Перевод RFC 1112 имеется на сайте www.protocols.ru. RFC 2236 содержит ряд дополнений и изменений для этого документа. Прим. перев.

9RFC 2011 – RFC 2013 содержат ряд дополнений и изменений для этого документа. Прим. перев.

10Этот документ устарел и заменен RFC 2178, который, в свою очередь, отменяет данная спецификация. Прим. перев.

11Перевод этого документа имеется на сайте www.protocols.ru. Прим. перев.

12В соответствии с RFC 3232 документ STD 2 утратил силу. Значения Assigned Numbers следует искать в базе данных, доступной на сайте www.iana.org/numbers.html. Прим. перев.

13Этот документ устарел и заменен RFC 2474, перевод которого имеется на сайте www.protocols.ru. Прим. перев.

14Этот документ устарел и заменен RFC 2390. Прим. перев.

15Этот документ устарел и заменен RFC 4271. Перевод имеется на сайте www.protocols.ru. Прим. перев.

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

17 Меньше битов в адресе хоста. Прим. перев.

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

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

Or