13. OSPF. LSDB
Формат пакета
Version = 2
Type
1 - Hello
2 - DBD
3 - LS Request
4 - LS Update
5 - LS Acknowledgment
Router ID - уникальный в AS ID
Checksum - Internet Checksum
От всего пакета кроме Authentication
AuType - тип аутентификации
0 - аутентификация не используется
1 - открытый пароль
2 - криптографическая аутентификация
Типы пакетов
OSPFv2 использует следующие типы пакетов:
Hello - для установления соседства
Database Description (DBD) - для первичной синхронизации LSDB
LS Request - для первичной синхронизации LSDB
LS Update - для синхронизации LSDB
LS Acknowledgment - для подтверждения полученных данных
Типы канальных сред
OSPF ведет себя по-разному в разных канальных средах
Выделяются следюущие канальные среды по RFC 2328
Совпадение типа среды не проверяется при установлении соседства
Машина состояний соседств
Hello
Использвание Hello позволяет:
Убедиться в двусторонней связности между соседними роутерами
Убедиться в непротиворечивости конфигурации соседних роутеров
Hello Protocol
Пакеты Hello отправляются в сторону соседа
На broadcast и point-to-point каналах:
224.0.0.5 (All OSPF Routers)
Один пакет раз в Hello Interval
На OSPF Virtual Link и NBMA каналах
IP-адрес получателя - юникастовый адрес соседа
Один пакет раз в Hello Interval каждому соседу независимо
Hello не требует подтверждения
Immediate Hello - расширение OSPF
На Hello от нового соседа немедленно отправляется юникастовый ответ
Состояния Hello Protocol
Состояния Hello Protocol:
DOWN - IP-адрес соседа известен, канальный адрес неизвестен
ATTEMPT - IP и канальный адрес известны, соседу отправляется Hello
INIT - от соседа получено Hello без нашего RID в Neighbor List
2-WAY - от соседа получено Hello с нашим RID в Neighbor List
При переводе соседа в 2-WAY маршрутизатор должен:
Определить IP-адреса DR и BDR в канале
Определить необходимости дальнейшей синхронизации LSDB с соседом
Выбор DR и BDR
DR и BDR оптимизируют топологию multiaccess-каналов
Выбираются только в broadcast и NBMA средах
При инициализации интерфейса DR=BRD=0.0.0.0
Слушаем Hello в течение Wait Timer (по умолчанию равен Dead Timer)
Если получено Hello от соседа, указавшего себя DR - выбираем его
Если получено несколько Hello - выбираем по максимальному Priority
Составляем список маршрутизаторов, которые могут стать DR
Мы и все наши 2-WAY соседи (кроме тех, у кого Priority = 0)
Выбираем соседа с максимальным Priority и RID
Повторяем процедуру для BDR
DR до выборов BDR не допускается
Первичная синхронизация LSDB
В состояние EXSTART из 2-WAY соседи переходят, если:
В канальной среде не выбираются DR/BDR
Point-to-Point
Point-to-Multipoint
OSPF Virtual Link
В канальной среде выбираются DR/BDR, и кто-то из соседей выбран DR или BDR
DROTHER между собой напрямую LSDB не реплицируют и остаются в 2-WAY
В EXSTART соседи принимают решение о порядке обмена DBD
Определяются роли Master и Slave и проверяется совпадение MTU
Database Description
Interface MTU для Virtual Link указывается равным нулю
Нужно выполнить Path MTU Discovery или ограничить пакеты 576 байтами
Sequence Number увеличивается с каждым пакетом (как в EIGRP)
Стартовое значение случайное, как в TCP
Флаги:
I (Init) обозначает инициализацию Sequence Number (аналог SYN в TCP) - выставляется мастером
M (More) указывает на то, что фаза Exchange не закончена
MS (Master/Slave) указывает на роль мастера
Выбор Master/Slave
Мастером выбирается маршрутизатор с большим RID (без priority)
В EXSTART оба соседа отправляют DBD c I=1, M=1, MS=1
Один должен сдаться и отправить ответное DBD c I=0, M=1, MS=0
Формально это сообщение уже относится к фазе EXCHANGE на обоих роутерах, в нем начинают передаваться заголовки LSA
Маршрутизатор, получивший DBD с Interface MTU, превышающим его собственный, должен проигнорировать такой пакет
Сосед останется висеть в EXSTART и не перейдет в EXCHANGE
Обмен пакетами DBD
DBD всегда отправляются парой Master>Slave; Slave>Master
Флаг M указывает на необходимость продолжения процесса
Master будет отправлять DBD, если Slave отправляет M=1
Роутер может отправить пустой DBD, если больше отправлять нечего
Если подтверждение не получено - будет ретрансмит
Хитрая схема подтверждения доставки
Slave, подтверждая предыдущий пакет, отправляет пакет в SN=X
Master, подтверждая предыдущий пакет, отправляет пакет с SN=X+1
Slave не ждет подтверждения на пакет, когда оба соседа отправили M=0
Это не страшно, т. к. Master не получит подтверждения на свой пакет и переотправит его
Exchange
Маршрутизаторы синхронизируют заголовки LSA из LSDB
LS Age - время в секундах с выпуска LSA
LS ID - идентификатор LSA
Advertising Router - RID выпустившего роутера
LS Sequence Number - версия LSA
LS Checksum - аглоритм Флетчера, нет Internet Checksum
Loading
В фазе Loading маршрутизатор запрашивает нужные LSA у соседа
Отправляет запрос LS Request с заголовками нужных LSA
Принимается LS Update с запрошенным содержимым
Получение подтверждается пакетом LS Acknowledge с заголовками LSA
После получения всех запрошенных LSA сосед переводится в Full
Жизненный цикл LSA
LS Sequence Number - номер версии LSA (signed int32)
Увеличивается на 1 при внесении изменений в LSA
LSA создается c SN=0x8000001, при достижении 0x7FFFFFFF флашится
LS Age - время в секундах, прошедшее с выпуска LSA
Если LS Age больше 1800 (30 минут), LSA перевыпускается
Если LS Age больше 3600 (1 час), LSA исключается из топологии и флашится
Распространение LSA с MaxAge эффективно убирает ее из LSDB на всех роутерах
Обновление LSA в среде без DR
При обновлении LSDB роутер раздает новые LSA соседям
Отправляет LSU с новыми LSA
Ждет подтверждения с идентичными заголовками (LSU или LSAck)
В среде без DR каждому соседу в канале отправляется LSU:
P2P - мультикаст на 224.0.0.5
P2MP - юникаст на адрес соседа
Обновление LSA в среде с DR
В среде с DR отправлять LSU каждому роутеру в канале накладно
При обновлении LSDB на DROTHER сначала уведомляется DR:
мультикаст на 224.0.0.6
DR уведомляет остальных участников (подтверждая полученную LSA)
мультикаст на 224.0.0.5
Ответные юникастовые LSAck подтверждают полученную LSA
Аутентификация
Last updated
