OSPFv2 минимум

Сегодня попробуем собрать в кучку все то, что нужно знать про OSPFv2 и настроить все это дело. Настраивать, кстати говоря, будем на Juniper. Вообще, планирую создать несколько постов по животрепещущим темам с кратким описанием технологии и примерами настройки именно на Juniper.
Когда я начинал писать статейку, я надеялся закончить её за пару-тройку вечеров. Однако сейчас пошла уже вторая третья неделя и я даже не приблизился к лабе. Конечно, сказывается отсутвие свободного времени. Ясно, что лаба будет точно вынесена в отдельный пост... Изложение, на мой вкус, получилось немного скомканным и не структурированным, но я старался. Я думал, что я знаю OSPFv2, оказалось, что не совсем... )

OSPF (Open Shortest Path First) - линк стейт (Link State) протокол, который широко применяется в сетях.  Как и в любом другом линк стейт протоколе, маршрутизаторы в OSPF строят топологию всей сети вообще. Каждый маршрутизатор хранит копию базы знаний по топологии всей сети и запускает свой собственный алгоритм поиска кратчайшего пути (Дейкстры) по этой базе. База эта носит название Link State Database или LSDB. Представляет она из себя описание линковв сети.

Такой подход чреват тем, что любое изменение на сети вовлекает в процесс перестроения абсолютно все маршрутизаторы. Это может быть проблемой, если в сети реально много линков. Для решения этой проблемы в OSPF существует понятие зонирования (area). Разделяя сеть на зоны мы облегчаем жизнь маршрутизаторам. В таком случае им нужно будет держать в уме только топологию своей зоны и знать как из неё выйти. А вот пограничным роутерам придется держать в уме топологии нескольких зон сразу. Пришло время обратиться к топологии. Будем использовать OSPF домен из моей лабороторки по динамической маршрутизации. И, сразу же нужно определиться с ролями маршрутиаторов. В OSPF все ноды деляться на:

Типы роутеров

• Internal Router - роутер находящийся внутри area (например O8, O6, O7)
• Backbone Router - роутер имеющий интерфейс в area 0
• ABR (Area Border Router) - роутеры находящиеся на границе зон (O2, O3, O4...)
• ASBR (Autonomous System Boundary Router) - роутеры находяшиеся на границе автономных систем. Тут не стоить приплетать AS из BGP. Здесь AS - это OSPF сеть. Снаружи может быть, например, IS-IS сеть. Вот между такой IS-IS и OSPF сетями будет находиться ASBR (O1, O7)

Areas

Всего в OSPF существует несколько типов зон и все они разные.

• Backbone (0.0.0.0) - зона, которая обеспечивает связность всех других зон*. На картинке выше это большое облачко слева. Каждая другая зона в OSPF должна иметь связность с backbone area. Иногда это связность не прямая, как, например, в случае с area 4 выше.
• Regular - обычная зона в сети OSPF. Ничем примечательным не характеризуется.
• Stub - такая зона является тупиковой. Она не принимает внешние префиксы, которые пришли из других доменов. Для их достижения ABR (в нашем случае O5) передает маршрут по умолчанию в такую зону. Т.е. маршруты 172.16.0.0 в такой зоне видны не будут. Однако про топологию внутренней для OSPF сети в такой зоне знают.
• Totaly stuby - 'ваще' тупиковая зона. Поведение схоже с предыдущей зоной, однако здесь и внутренние маршруты присуствовать не будут. В такие зоны ABR (O3) передает только один маршрут по умолчанию.
• NSSA (Not-So-Staby-Area) - тупиоквая зона, но не такая уж и тупиковая. В таких зонах может находится выход из AS. ASBR роутеры в таких зонах (O7) могут редистрибуцировать внешние маршруты. Однако со стороны внутренней сети, внешних маршрутов все равно видно не будет. Т.е. O4 не будет передавать внешние маршруты в area 3, но вот из area 3 такие маршруры уйдут в сторону OSPF домена.
• Totaly NSSA - ваще тупиковая, но не такая уж и тупиковая. Аналогично Totaly stuby в такие зоны передается только маршрут по умолчанию, только в таких зонах может находиться ASBR (подобно NSSA). Такой тип придумала Cisco, в Juniper такого нет.

* Существует заблуждение, что backbone area должна присутствовать в любой OSPF сети. Мне даже казалось, что я читал в RFC про это. Но сейчас я там таких строк не нашел... На самом деле, это необязательное условие. Плоская сеть без зонирования с одной распространенной ненулевой зоной должна работать корректно. Может проверим в лабе.

Типы сетей

OSPF может быть использован в различных сетях, как Ethernet, например, или Frame-Relay. Для различных типов сетей у OSPFа припасен свой тип, который можно прописать на интерфейсе. Вопрос этот довольно сложный, на самом деле, но я опишу только типы сетей и кратко их особенности.

Стоп. К концу описания процесса в сети с DR/BDR, я наткнулся на довольно большую особенность в том, каким образом передаются различные сообщения OSPF. Это может быть юникаст и мультикаст. Причем, мультикаст адреса используется два. Давайте-ка и с этим разберемся. Обратимся к RFC, в которой информация об этом размазана ровным слоем по всему документу.

The IP destination address for the packet is selected as
follows.  On physical point-to-point networks, the IP
destination is always set to the address AllSPFRouters.  On all
other network types (including virtual links), 
the majority ofOSPF packets are sent as unicasts, i.e., sent directly to the
other end of the adjacency.  In this case, the IP destination is
just the Neighbor IP address associated with the other end of
the adjacency (see Section 10).  The only packets not sent as
unicasts are on broadcast networks; on these networks Hello
packets are sent to the multicast destination AllSPFRouters, the
Designated Router and its Backup send both Link State Update
Packets and Link State Acknowledgment Packets to the multicast
address AllSPFRouters, while all other routers send both their
Link State Update and Link State Acknowledgment Packets to the
multicast address AllDRouters.

RFC 2328. Пункт 8.1

The other important features of OSPF's IP encapsulation are:
Use of IP multicast.  Some OSPF messages are multicast, when
sent over broadcast networks.  Two distinct IP multicast
addresses are used.  Packets sent to these multicast addresses
should never be forwarded; they are meant to travel a single hop
only.  To ensure that these packets will not travel multiple
hop, their IP TTL must be set to 1.

AllSPFRouters
This multicast address has been assigned the value
224.0.0.5.  All routers running OSPF should be prepared to
receive packets sent to this address.  Hello packets are
always sent to this destination.  Also, certain OSPF
protocol packets are sent to this address during the
flooding procedure.

AllDRouters
This multicast address has been assigned the value
224.0.0.6.  Both the Designated Router and Backup Designated
Router must be prepared to receive packets destined to this
address.  Certain OSPF protocol packets are sent to this
address during the flooding procedure.

RFC 2328. Пункт A.1 

Черт, это выглядит как цитаты из Библии... Ну да ладно. Из всего этого и TCP/IP vol.1 можно сделать следующие выводы.

Тип	Пример	Выборы DR/BDR	Hello Timer	Дискавери соседей	Больше двух роутеров	Hello	DBD	LSR	LSU	LSAck
Broadcast	Ethernet	Да	10	Да	Да	AllSPFRouters (224.0.0.5)	AllDRRouters (224.0.0.6) Unicast AllSPFRouter (224.0.0.5)	Unicast	AllSPFRouters (224.0.0.5) AllDRRouters (224.0.0.6)	AllSPFRouters (224.0.0.5) AllDRRouters (224.0.0.6)
Point-to-Point	Serial	Нет	10	Да	Нет	AllSPFRouters (224.0.0.5)	AllSPFRouter (224.0.0.5)	AllSPFRouter (224.0.0.5)	AllSPFRouters (224.0.0.5)	AllSPFRouters (224.0.0.5)
NonBroadcast MultiAccess (NBMA)	FR Multipoint Subinterface	Да	30	Нет	Да	Unicast	Unicast	Unicast	Unicast	Unicast
Point-to-Multipoint	FR	Нет	30	Да	Да	Unicast	Unicast	Unicast	Unicast	Unicast

Есть еще один тип сети - Virtual Link. Он как бы стоит особняком. Соседство устанавливается на таких линках автоматически и все собщения идут юникастом. Применяется такая вещь для соединения удаленных зон с бэкбон зоной через некую третью транзитную. Есть и ещё один сценарй использования, например, создание дополнительного линка внутри area 0 через другую зону для отказоустойчивости.

Нужно ввести ещё некоторые необходимые понятия.

• Link State Вatabae (LSDB) - та самая база знаний о сети. Она содержит в себе информацию о состоянии каждой сети.

• Link State Advertisement (LSA) - как раз те описания сетей из которых состоят LSDB.

Таймеры

OSPF использует ряд таймеров и интервалов, которые так или иначе важны для процесса.

• Hello Timer - таймер отсылки Hello. Как только он истекает, отправляется новое Hello сообщение. 
• Dead Interval - интервал, в течении которого роутер надеется услышать Hello от соседа. Если такое сообщение не получено, роутер признается умершим. 
• MaxAge - время, по истечении которого LSA считается устаревшей. После этого LSA покидает LSDB. 
• IfTransDelay - значение на которое будет увеличиваться время жизни LSA. 
• Wait Timer - время в течении которого роутер будет ждать информации о DR/BDR в Hello от соседа. Обычно равен DeadInterval. После истечения начинаются выборы. Сделанно это для того, чтобы предотвратить ненужные измениня DR/BDR. 
• RxmtInterval - если LSA не был подтвержден от соседа, роутер перешлет его повторно по истечению этого таймера. 
• PollInterval - в NBMA сетях соседство настраивается вручную. Если сосед перешел в состояние Down, Hello сообщения отправляются ему с PollInterval, который длиньше Hello. NBMA сети изначально полагаются более медленными, и, для экономии ресурсов линка, Hello отправляется реже.

Interface State Machine

Любой интерфейс на котором запущен OSPF проходит ряд этапов

• Down - тут все ясно, интерфейс пока не работает
• PtP - в такое состояние переходит интерфейс в point-to-point, point-to-multipoint сетях, а так же на virtual link. Такой интерфейс начинает слать Hello и все прочее.
• Waiting - роутер находящийся в broadcast или NBMA среде ждет информации о DR/BDR от своих соседей. На этом этапе запускается WaitTimer.
• DR - интерфейс является Designated Router в данном сегменте
• Backup - интерфейс в состоянии Backup Designated Router для сегмента
• DRother - интерфейс ни DR, ни BDR в сегменте.
• Loopback - специальный тип для loopback интерфесов и прочих "заворотов"

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

Итак, весь процесс в целом проходит следующие этапы

1. Дискавери соседей
2. Установление отношений соседства
3. Выбор DR/BDR (по необходимости)
4. Обмен знаниями или синхронизация
5. Поддержание отношений и извещение об изменениях

Типы сообщений

Hello - используется для установления и поддержания соседства. Отправляется периодически.

Database Description (DD или DBD) - описание LSDB в котором находятся только заголовки LSA (Тип, LSA ID, от кого пришло).

Link-State Request (LSR) - запрос интересующей LSA, которая отсутсвует у роутера, но есть у соседа.

Link-State Update (LSU) - сообщение содержащее интересующие соседа LSA.

Link-State Acknowledgment (LSAck) - подтверждение о получении LSU.

1. Установление соседства

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

Для установления сосества и его поддержания используется сообщение Hello. Внутри него содержиться много всякого. (все это и многое другое можно почитать в RFC 2328)

• Router ID
• Stub area flag
• Hello interval
• Dead Interval
• Network mask 
• List of neighbors
• Area ID 
• Router priority 
• Designated Router (DR) IP address
• Backup DR (BDR) IP address 
• Authentication info

Я выделил мерзким цветом те пункты, которые нужны для установления соседства. А именно

• Router ID должен быть разным
• Пары Hello/Dead интервалов должны совпадать на маршрутизаторах
• Network Mask должен быть одинаковым (справедливо только для broadcast среды)
• Area ID должна сомпадать
• Настроеная аутентификация должна сомпадать
• MTU должен совпадать*

*MTU не передаетя в Hello и, на самом-то деле, не влияет на соседство. Я просто хочу, чтобы в одном списке были собраны все критичные для процесса понятия. При несовпадении MTU соседство поднимется, но дальше дело не пойдет, обмена знаниями не будет. Все это потому ,что MTU передается в Database Description пакете. О нем чуть позже.

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

После включения OSPF, роутеры переходят из состояния DOWN в состояние INIT. Интерфейсы, на которых запущен OSPF так же меняют своё состяоние. Состояние интферфейсов зависит от типа сети (приведены выше). Допустим, O1 первым успел отправить Hello (Multicast для broadcast, PtP; Unicast для NBMA, PtM, Virtual Link сетей). На картинке вся интересная информация в пакете. Список соседей пока что пуст. О2 получив такой пакет сравнивает все параметры. При выполнении условий О2 заносит О1 в список своих соседей и отправляет назад Hello уже юникастом. В сообщении указан адрес О1 как соседа. О1 получи такой пакет радуется и сразу же заносит О2 в список своих соседей. Переходит в состояние TWO-WAY. Далее идет отправка Hello  в сторону O2. Тот находит себя в споиске соседей и тоже радуется. Теперь два маршрутизатора в состоянии TWO-WAY. Это состояние говорит о том, что первоначальное соседство установлено и можно переходить к дальнейшим операциям.

Есть ещё состояние ATTEMP, которое находится между DOWN и INIT. Валидно только для Non-Broadcast-Multiaccess (NBMA) сетей. Означает, что будет предпринята попытка связаться с соседом, который не выходил на связь.

2. Выбор DR/BDR

В нашем примере O1 и О2 находятся в broadcast среде, поэтому среди пока что двух роутеров должен быть выбран DR и BDR.

Вообще, зачем оно нужно?

Во-первых, в больших сетях соседство каждый-с-каждым достаточно утяжелит весь процесс. Вернее соседство-то не утяжелит, а вот обмен данными может быть проблемой. Поэтому в сетях с множественным доступом, каждый маршрутизатор обменивается данными только с DR. А тот уже отвечает за рассылку информации роутерам. Для того чтобы DR (Designated Router) не стал единственной точкой отказа в сети присуствует его коллега - BDR (Backup Designated Router). Каждый роутер устанавливает полное соседство и с ним тоже.
Во-вторых, DR отвечает за моделирование той самой broadcast среды к которой подключены роутеры. Тут станет понятно, когда мы дойдет по описания LSA.

Выборы проходят на основе приоритета (0 - 255) и RouterID. Больший выигрывает. По умолчанию, приоритет у всех одинаковый, поэтому выигрывает роутер с большим RouterID. Следующий по старшенству становится BDR.

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

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

Если BDR сломался, то перевыбирается только BDR, DR остается неизменным.

Контролировать этот процесс можно изменяя приоритеты. В стандартной Ethernet среде это не особо важно, а вот в каком-нибудь хитром FrameRelay лучше руками задать DR, чтобы топология соответствовала задуманному.

В point-to-point, point-to-multipoint, virtual link средах DR/BDR не выбираются вовсе.

Ещё один немаловажный момент. Роли DR/BDR и приоритеты являются свойствами интерфейса, а не роутера целиком. А это значит, что роутер в одной области может иметь роль DR, а во второй быть рядовым DRother (так обзываются все роутеры, которые не DR/BDR). Так же и с приоритетами. В одну зону роутер может смотреть приоритетом 0, а в другой всегда побеждать в выборах с приоритетом 255.

Возвращаясь к нашему примеру. О1 имеет приоритет 128. По-умолчанию, O2 имеет такой же. RouterID у O2 больше, он и станет DR. O1 получит роль BDR. После того, как мы включим в сеть другие роутеры из этой зоны (O3, О4) никаких перевыборов инициировано не будет, даже учитывая, что ID у них выше. Цифрами на картинке выше обозначен порядок включения. Итак, включили О1, затем О2. Они выбрали кто из них главный. Затем включили О3 и О4. На этом этапе роли меняться не будут. O3 и О4 будут обмениваться маршрутной инфомрмацией только с O1 и О2. Между собой они делиться не будут.

Конечно же, есть смысл назначать роли DR-BDR руками. В сетях, как мне кажется правило "Hardcode everething!" можно считать позитивной практикой. Для того, чтобы иметьвозможность влиять на процесс в целом, и был придуман приоритет. Мы, например, можем на O1 прописать приоритет в 200, что гарантированно сделает его DR. О3 пусть станет нашим новым BDR. Его приоритет мы трогать не будем. А вот у О2 и О4 занизим его до неприличного значения. Ну, скажем, 50. Можно поставить вообще 0, но тогда роутеры никогда не получат роли DR/BDR. Стоит ещё раз заметить, что после смены значений ничего не произойдет, нужно будет искуственно инициировать выборы.

Так, с этим шагом разобрались. Переходим к самому вкусному - распространению маршрутной информации.

3. Обмен знаниями

На этом этапе используются все остальные типы сообщения, а именно DBD, LSR, LSU и LSAck. Обмен знаниями в среде с DR/BDR  и без них разнятся. Сначала рассмотрим, как ведут себя роутеры без них.

No DR/BDR

После установления соседства, роутеры перешли в состояние 2Way им нужна начать синхронизировать свои LSDB. Т.к. ребята в нулевой area из прошлого примера находятся в сети с множественном доступом, возьмем для примера товарищей из area 1. Это знакомый нам O2 и О5. Линк между ними настроен как point-to-point, DR/BDR выбираться не будет. Итак, роутеры сразу преходят к обмену знаниями. Цель - рассказать про то, что знает мы как локальный роутер и узнать что знает сосед.

Итак, по картинке выше. Роутеры установили соседство, обменялись Hello и успешно перешли в состояние 2Way. Следующее что им стоит сделать, рассказать друг другу о своих сетях. Для этого и O2 и О5 отправляют сообщения DBD. Помимо уже привычных RouterID, Area и аутентификации, в них также передается ряд специфичных параметров.

• MTU. Тут может быть засада. Как я упоминал, одинаковый MTU на линках - обязательное условие для нормальной работы OSPF. Однако для соседства он не нужен. С разными MTU маршрутизаторы установят соседство, но так и останутся навечно в 2Way. Обмен маршрутной информацией не произойдет.

• Sequence Number. Это просто некое число, не более. Но штука эта важная, про неё чуть позже.

• Master/Slave флаг (MS-bit). Первые сообщения DBD отправляются с флагом Master, т.е. каждый роутер считает себя главным на линке.

• I-bit. Этот бит установлен в первых DBD собщениях, которые служат для инициализации.

• M-bit. Этот бит установлен в случае, когда DBD сообщение не последнее.

• LSA Header. Здесь как раз и содержиться то самое описание LSDB. В Header помещается информация об LSA ID, роутере который её сгенерировал и тип LSA.

Как видно на картинке, и О2 и О5 отправляют DBD сообщения со своими значениями Sequence Number. Первые сообщения передаются без LSA внутри с установленными флагами Initialize (I-bit), M-bit и MS bit. Что фактически означает, что роуетр считает себя мастером, сигнализирует о том, что сообщение не несет LSA и является первичным и не последним. Служат эти сообщения для выбора Master и Slave.
Как только роутер сгенерировал и отправил DBD, его состояние переводится в ExStart. Это значит, что начался процесс обмена данными.
После того, как O2 получит DBD от О5, он понимает, что его RouterID меньше, а это значит, что он больше не должен считать себе Мастером. Отныне O5 будет говорить первым в этом линке. В подтверждение этому факту О2 отправляет DBD в сторону О5, в котором он уже представляется ролью Slave и использует Sequence Number который пришел от O5. Это означает, что О2 понял, что он Slave и готов синхронизировать свою LSDB с О5. I-Bit уже не равен единице, а это значит, что такое собщение должно нести LSA Header внутри (надо проверять на лабе, на самом деле.)

* Ещё одна звездочка. В некоторых источниках указывается, что DBD подтверждается LSAck, но на самом деле он не отправляется. Подтверждением DBD является генерация такого же DBD с таким же Sequence Number. Так будет происходит в течение всего процесса. Один роутер генерирует DBD c номером, второй отвечает ему таким же DBD с таким же номером.

Если вдруг от мастера пришел DBD с таким же номером как и в предыдущем сообщении, то сообщение нужно переподтвердить.

Да, как только роутеры договорились кто из них главный в канале, меняется их состояние в Exchange. Это означает, что роутеры начали процесс синхронизации LSDB. Вся база может не влезть в DBD, поэтому роутеры обмениваются несколькими пакетами каждый раз увеличивая Sequence Number. По нему наши устройства отличают одну версию сообщения от другой.

Если роутер видит
что в DBD есть LSA, которых нет у него или,
что в DBD есть более новые LSA

такие LSA добавляются в Link State Request List

Link State Request List содержит список LSA которые роутер спросит или уже спросил у соседа. Роутер отправит LSR сообщения по таким LSA. После получения LSU, полученные LSA удалятся из этого списка.

Каждый LSU должен быть подтвержден. Когда роутер отправляет своему соседу LSU с LSA внутри, он так же добавляет их в Link State Retransmission List.

Link State Retransmission List содержит список LSA, которые роутер отправил своему соседу, но не дождался пока LSAck по ним. Как только LSAck будет получен, подтвержденные LSA удалятся из списка.

Допустим, O2 ничего нового для себя не узнал, его Link State Request List пуст, он ничего не хочет спрашивать. Предыдущее сообщение от мастера было с M-Bit = 0. Что говорит нам о том, что мастер уже также все рассказал.
O2 досылает по необходимости свои LSA в DBD и далее (в ответ на DBD от мастера и только так) О2 шлет DBD в сторону своего соседа с M-bit равным 0. Что означает, что ему больше сказать нечего. О2 переходит в состояние Full.
O5 понимает, что есть некоторые LSA, про которые он хотел бы узнать больше информации. Он помещает их в свой Link State Request List и меняет свое состояние в Loading и, как видно на рисунке, он отправляется запрос LSR. Расскажи мне, мол, вот про это. O2 отправляет ему нужную информацию средствами апдейта LSU. Добавляя такие LSA в свой Link State Retransmission List. На что O5 отвечает подтверждением LSAck. Мол, спасибо, получил. Допустим, O5 больше ничего не хочет узнать, его Link State request List пуст. Чтож, самое время перевести статус на Full.

Синхронизация закончилась. Как говориться, всем спасибо. На самом деле, процессы эти проходят не совсем последовательно. Как только роутер понимает, что у него есть записи в Link State Request листе, он может начинать отправку запросов, не дожидаясь Loading стадии.

Acknowledge

С LSAck тоже не все так просто, роутер может и не отправлять LSAck в качестве подтверждения, вместо этого может отправиться LSU, которая помимо прочих LSA содержит копию принятого LSA. Такой способ используется, если роутеру все равно нужно отправлять Update соседу. В таком случае отправлять LSAck не нужно. LSAck может отправляться как юникастом, так и мультикастом.

Direct Unicast LSAck отправляется сразу же, если роутер видит дубликат LSA или LSA достигла своего MaxAge.

Delayed Multicast LSAck отправляется мультикастом, что помогает подтвердить принятие сразу нескольких Update от разных роутеров. Время отправки такого отложенного LSAck должно быть меньше RxmtInterval, чтобы не было лишних пересылок LSA.

DR/BDR

При наличии DR/BDR обмен данными в сети все будет происходить немного иначе. Как я уже говорил, роутеры в одном широковещательном домене будут формировать "полное" соседство только с DR и BDR. Соответственно, отправлять DBD и прочее они будут только на DR/BDR. DR затем разошлет нужные сообщения остальным роутерам с помошью специального типа LSA, в то время как BDR будет просто подслушивать.

Допустим,  у нас есть все та же area 0. Как видно, все роутеры в этом широковещательном домене в состоянии 2Way. Это значит, что соседство установлено и можно переходить к обмену данными. Т.к. среда широковешательная имеет место быть процесс выбора DR/BDR. В прошлом примере мы задали приоритеты руками, поэтому О1 станет DR, а О3 будет BDR. В сообщениях Hello это видно всем роутерам в этой сети.Ок, О2 решает начать обмен данными. Он должен отправить DBD сообщение. На этот раз он отправляет мультикаст сообщение на адрес 224.0.0.6 (All DR routers). Этот адрес слушают два роутера в сети - DR и BDR. Получив такое сообщение BDR никаких действия не предпринимает, а вот DR генерирует уже другое сообщение на адрес 224.0.0.5 (All SPF Routers), его слушают все OSPF роутеры. К тому же DBD так же уходит юникастом в сторону O2.

DR и BDR, к слову, тоже доходят до состояния Full. Ведь в сети может и не быть других роутеров вообще, а передавать маршруты как-то надо. )

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

Sequence Number имеется у каждой LSA. Начинается он от 0x80000001 и заканчивается

0x7fffffff. Каждый раз, когда роутер передает LSA он увеличивает её sequence number. Это позволяет обнаруживать старые и дублирующиеся LSA. Когда роутер достигает максимального значения, он отправляет эту LSA с проставленным MaxAge. Соседи подтвердают принятие и сбрасывают LSA из базы. После чего, роутер выставляет новое минмальное значение sequence number для этой LSA и снова рассылает соседям.

Age. Каждыя LSA имеет возраст. При достижении MaxAge (3600c) LSA должна быть выброшена из LSDB. Она считается устаревшей. Каждый раз когда роутер генерирует LSA он увеличивает её Age на InfTransDelay (1c). Если роутеру нужно сбросить LSA из всей LSDB соседей, он отправляет LSA с выставленым MaxAge.

Neighbor State Machine

Срезюмируем все состояния, который проходят роутеры в процессе OSPF общения.

• Down - начальное состояние, когда Hello ещё не было услышано в линке от соседей
• Attempt - это состояние применимо только для NMBA сетей. Там соседи настраиваются вручную и Hello в интерфейс там шлутся даже к соседям в состоянии Down.
• Init - пришло Hello от соседа
• 2Way - в Hello замечен локальный адрес роутера. Вторым вариантом перехода в это состояние является получение DBD сообщения.
• ExStart - первый DBD был отправлен, происходят выборы Master/Slave
• Exchange - начался обмен маршрутной информацией в DBD, также LSR, LSU сообщения могут быть посланы не дожидаясь следующей стадии
• Loading - началось уточнение LSDB с помощью LSR/LSU
• Full - синхронизация закончилась, роутеры имеют одинаковую версию LSDB

Ладно, пора коснуться главного - типов LSA.

Типы LSA

Вся "мякотка" OSPF в типах LSA. Их несколько:

• Type 1 | Router LSA - передается каждым роутером в домене в каждый линк. Всегда остается внутри area. В нем содержиться:

• ID роутера
• Список всех линков
• Состояние и стоимость (cost) на каждом из них
• Список соседей на линке

В нашей топологии Type 1 LSA передает любой роутер, например, О2.

• Type 2 | Network LSA - передается DRом и, как бы, представляет широковещательный сегмент как псевдоноду (pseudonode). Всегда остаются в пределах зоны. Стоимость от каждого роутера в этой сети до псевдоноды равна стоимости исходящего линка, а вот стоимость от псевдоноды до подключенных устройств всегда равно нулю. Вся сеть видна как одна нода и, благодаря этому трюку со стоимостью, при просчете пути через эту ноду не вносятся никакие поправки. В этом типе LSA содержится:

• Сеть и маска
• Список подключенных к этой сети устройств
• Cost не передается

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

• Type 3 | Network Summary LSA - генерируется ABR девайсами на границах зон. С помощью этого типа передаются знания между зонами. Сгенерировал какой-нибудь маршрутизатор Type1 LSA, надо же как-то передать её в другие зоны. ABR сохраняет запись в своей LSDB и затем генерирует LSA Type3. В этом типе LSA содержиться стоимость от ABR до того роутера, к которому подключена анонсируемая сеть. Интересно, что OSPF между зонами действует больше как distance-vector протокол. При получении такого NetSum LSA, роутер не запускает алгоритм просчета пути, он просто к полученной стоимости добавляет свою стоимость до ABR. Маршрут по умолчанию, который пришел из другой зоны так же передается с помощью NetSum LSA. Передаются:
• Сеть и маску
• Стоимость до сети от ABR

O2 является и ABRом, ведь он стоит на границе зон. В правую зону он будет передавать маршруты из левой и наоборот.

• Type 4 | ASBR Summary LSA - генерируются ABR (не ASBR). Этот тип похож на предыдущий, но вместо сети и маски, передается адрес ASBRа, который находится в этой зоне. Таким образом ABR рассказывает роуетрам за пределами своей зоны о существовании ASBR в его зоне.

• Адрес и нулевая маска
• Стоимость до ASBR от ABR

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

• Type 5 | External LSA - а вот этот тип уже генерируется ASBR. Этот тип передается по всем area и содержэит информацию о каких-то внешних маршрутах для OSPF домена. В AS External LSA также может передаваться маршрут по умолчанию, если он пришел из другого домена. Бывают двух типов, 

1. Type 1 - к анонсируемой стоимости будут добавляться стоимости линков по пути, 
2. Type 2 - стоимость добавляться не будет.
   В LSA передается:
• Сеть и маска
• Стоимость
• Forwarding address* нужен он для просчета пути. Сюда проставляется адрес роутера, который непосредственно подключен к внешней сети.

В нашем примере O1 zвляется классическим ASBR. Он будет рассылать External LSA определенного типа в сторону OSPF домена. В моем примере, это дефолтный маршрут из IS-IS.

• Type 7 | NSSA External LSA - это как пятый тип, только для NSSA. Дело в том, что в NSSA зоне не передается пятый тип, потому что она как бы тупиковая. Но не такая уж и тупиковая, поэтому в таких зонах существует Type 7, который ближайшим ABR конвертируется в Type 5 и передается дальше во все зоны.

O7 тоже ASBR, но находится он в NSSA зоне. Там не передаются Type 5 LSA. Не беда, О7 сгенерирует Type 7 и передаст в свою зону, а вот ABR О4 сконвертирует седьмой тип в понятный остальной ети пятый.

• Type 6 | Group Membership LSA - используется для передачи через OSPF мультикаст адресов (MOSPF). Как-нибудь потом...

• Type 8 | External Attributes LSA - предоставляет теоритическую возможность отказаться от iBGP и использовать OSPF для этого. Не уверен, что кто-то вообще поддерживает этот тип.

• Opaque LSA - используются много для чего и их продолжают предумывать. MPLS-TE, Segment Routing...

* Небольшой прикол с Forwarding Address.

Например, у вас есть пара роутеров, которые подключены к третьему. Это пара наших ASBRов (ASBR1, ASBR2). Третий роутер (EXT) является внешним для OSPF домена. Допустим, на ASBR1 настроен OSPF только на интерфейсе в сторону OSPF домена, т.е. он не будет рассказывать своим соседям про линковую подсеть между ним и роутером EXT. Он будет проставлять нули в Forwarding Address.

А у второго, допустим, OSPF замущен на двух интерфейсах и он анонсирует линковую подсеть сежду собой и EXT в OSPF домен. Это значит, что все OSPF облако будет знать как добраться до 10.2.2.1 в нашем примере. Он будет проставлять в Forwarding Address адрес интерфейса внешнего роутера, тот самый 10.2.2.1.

Таким образом, внутренние маршрутизаторы получив два таких LSA будут считать стоимость по разному. В первом случае, стоимость будет включать в себя стоимость передаваемую ASBRом в сумме со стоимостью до ASBRа (Type1). Во втором же случае, стоимостью будет являться стоимость для достижения того самого Forwarding Address. Cisco объясняет.

Ну и в заключении табличка зон и разрешенных типов LSA.

Area	Запрещены	Заменены на	Описание
backbone	-	-	-
regular	-	-	-
stub	LSA 5 (External LSA)	LSA 3 (Network Summary) 0.0.0.0/0	Внешине маршруты не передаются, вместо них передается Network Summary маршрут по умолчанию
totally stub	LSA 5 (External LSA) LSA 4 (ASBR Summary) LSA 3 (Network Summary LSA)	LSA 3 (Network Summary) 0.0.0.0/0	Внешние и машруты других зон не передаются, вместо них передается Network Summary маршрут по умолчанию
NSSA	LSA 5 (External LSA)	LSA 3 (Network Summary) 0.0.0.0/0	Внешине маршруты не передаются, вместо них передается Network Summary маршрут по умолчанию. В такой зоне может находиться ASBR, в таком случае внешние маршруты передаются в LSA 7 и конвертируются в LSA 5

Пост дался нелегко... надеюсь в следующем посте про OSPFv2 будет приятней и интересней. Посмотрим как оно все выглядит в Juniper.

Пишите, если есть что добавить.