Откровенно говоря я не знал, стоит ли мне браться за статьи о OSPF из-за того, что тема довольно объемная, а информации в Интернетах хватает. Но когда я набросал коротенький список тезисов, начал для себя же их пояснять, то понял, что все равно к этому приду. Размявшись с EIGRP возьмемся за OSPF. Поговорим о принципах работы link state routing protocols, важности выбора правильного дизайна сети, а так же разберемся с механизмом установления соседства и его фазами.
Let me introduce to you: OSPF
OSPF один из двух протоколов маршрутизации, который принадлежит семейству link-state. Второй, если что IS-IS. Так же как и EIGRP OSPF использует в своей работе три таблицы – neighbor table, topology table, routing table и на этом, в принципе, сходства заканчиваются.
Протоколы динамической маршрутизации, которые основаны на отслеживании состояния канала последовательно выполняет три важных шага. Для начала, так же как и EIGRP OSPF устанавливает соседства и помещает всех найденных соседей в neighbor table.
Вторым шагом является обмен топологией сети. Все маршрутизаторы в рамках одной области обмениваются информацией, которая наполняет topology table, чаще называемую LSDB – link state database. После завершения обмена информации, записанной в LSDB, должно быть достаточно чтобы полностью описать топологию области из любой ее точки. В LSDB содержатся идентификатор для каждого найденного в области маршрутизатора (router id), все интерфейсы маршрутизатора, ip адрес, маска подсети, а так же список маршрутизаторов доступных с точки зрения каждого интерфейса каждого маршрутизатора. Чуствуете разницу по сравнению с distance-vector протоколами маршрутизации? Там мы получали не карту области целиком, а знали только ту информацию, которую сообщали нам соседи и принимали решения на основе ее.
После того как LSDB сформирована запускается механизм SPF (shortest path first) и маршрутизаторы вычисляют лучшие маршруты с их точки зрения. Как только лучший маршрут найден он и next-hop до него инсталлируются в таблицу маршрутизации – routing table. С увеличением количества маршрутизаторов и маршрутов в области алгоритм SPF становится все более и более прожорливым.
В отличии от RIP OSPF отправляет инкрементальные апдейты, вместо всей таблицы маршрутизации целиком и только тогда, когда произошло какой-то изменение в топологии области. Одновременно с этим, если ничего не происходит, распространяются переиодичные обновления – Link State Refresh. Каждые 30 минут происходит обмен LSDB целиком, на тот случай если кто-нибудь что-нибудь упустил. Иногда этот процесс называют database turnover.
Дизайн и термины
OSPF требует продуманного дизайна сети, областей, составления плана адресации. Особенно плана адресации, учитывая то, что OSPF будет хорошо работать только при иерархическом дизайне. Автономная система OSPF делится на области, каждая область должна быть присоединена к Area 0 (backbone area). Маршрутизатор, интерфейсы которого принадлежат двум и более областям называется Area Border Router – ABR. Такие маршрутизаторы содержат две и более копии LSDB для разных областей. ASBR – пограничный маршрутизатор, который находится в контакте с другой автономной системой (EIGRP, RIP, BGP, не важно) или присоединен к сети Интернет. На ABR и ASBR можно производить суммирование маршрутов. На них и только на них.
Цель такого дизайна – локализовать обновления LSDB в рамках одной области и отдавать в другую область только суммарную информацию.
Внутри области маршрутизаторы обмениваются полной топологией, имеют одну и ту же копию LSDB, а между областями только суммарными маршрутами. Чтобы пакет попал из одной не backbone области в другую он должен пройти через хотя бы один маршрутизатор в area 0.
Area 0, 1, 2, 3 – это одна OSPF автономная система.
Формирование соседства
Помните как все было круто с EIGRP?
– Здорово, R1.
– Шалом, R2.
– Какие у тебя k-values? Вот мои.
– Такие же, как и у тебя, давай дружить.
OSPF – это совершенно другой вопрос.
Допустим, вы включили OSPF одним из следующих способов:
router ospf process_id network network wildcard_mask area_id
interface interface ip ospf process_id area area_id
Первое, что происходит с маршрутизатором после этого, это выбор Router ID (RID), который представляет собой по сути имя маршрутизатора. RID – отнюдь не косметический атрибут. Выборы RID происходят по следующему алгоритму:
- использовать RID, заданный жестко с помощью router-id x.x.x.x
- если п.1 не задан, то следует использовать наибольшей адрес loopback интерфейса, который находится в состоянии UP/UP
- если п.2 не задан, то следует использовать наибольший адрес любого другого интерфейса, который находится в состоянии UP/UP
п.1 и 2 призваны стабилизировать OSPF процесс, а так же защитить конфигурацию, в которых принимают участия RID. Но лучше таки использовать п.1. Вы добавили HWIC с IP выше? Отвалилась сеть с текущим интерфейсом, который является RID? Добавили случайно loopback интерфейс для тестов? Doesn’t matter, had sex ospf process still stable. RID изменяется только когда вы перезапускаете OSPF процесс или перезагружаете маршрутизатор.
Следующее, чем займется маршрутизатор будет добавление интерфейсов в LSDB. Делается это на основе команды network.
Down State
Затем на эти интерфейсы будет отправлен пакет Hello на multicast адрес. Пока он ожидает ответа от соседа, статус сменится на “Down State”. Если при уже полностью сформированном соседстве маршрутизатор не получит от соседа Hello сообщения на протяжении времени DeadTimer = HelloTimer*4 или вручную настроенный сосед был убран из конфигурации статус соседа изменится с Full на Down.
Hello сообщения отправляются каждые 10 секунд в LAN/P2P сетях и каждые 30 секунд в NBMA сетях. Эти параметры можно менять. В Hello пакете содержится следующая информация:
- Router ID (RID)
- Hello и Dead таймеры
- Маска подсети
- Area ID
- Соседи
- Приоритет маршрутизатора
- IP адреса DR/BDR
- Если установлен – пароль для аутентификации в clear-text или md5 hash
Выделенное красным должно совпадать для успешного установления соседства. “Какой разборчивый” – скажите вы, но это еще не все. Дополнительно RID должен быть уникален, а MTU должно совпадать.
Attempt State
За Down обычно следуют Init State, но есть еще одна промежуточная фаза – Attempt State, которая справедлива только для NBMA сетей и соседей, сконфигурированных в ручном режиме. Эта фаза означает, что Hello отправлен, но Hello от соседа еще не пришел.
Init State
Как только сосед принимает Hello пакет он тут же переходит в состояние Init с отправителем и проверяет соответствие обязательных атрибутов. Если маршрутизатор переходит из состояния Init в Down и обратно, то неплохо было бы проверить не ошиблись ли вы с настройкой обязательных атрибутов.
2-way state
За Init идет 2-way state, а значит двухсторонние отношения между соседями были установлены. Все хорошо, оба маршрутизатора увидели Hello пакеты друг друга. Если маршрутизатор нашел в Hello пакете соседа информацию о себе, то он просто обновит dead timer, если не нашел, то он добавит его в LSDB как нового соседа и надо перейти на следующий этап.
В broadcast и NBMA сетях маршрутизатор переходит в состояние FULL только с DR и BDR, со всеми остальными он остается в 2-way state. На Point-to-Point и Point-to-Multipoint линках маршрутизатор переходит в состояние FULL со всеми соседями.
Так же в конце этой фазы происходят выборы DR и BDR в broadcast и NBMA сетях, но об этом позже.
Exstart state
После выбора DR и BDR начинается фаза Exstart (exchange start). В процессе этой фазы устанавливаются master-slave отношения. Весь их смысл заключается в том, кто первый отправит Datebase Description (DBD) – краткие заметки о LSDB. Выбор осуществляется по приоритету, маршрутизатор с наивысшим RID становится мастером.
Exchange & Loading states
В ответ на DBD пакеты отправляется LSACK (link state acknowledgement) – все ок, мы их приняли и начинается анализ. Происходит сравнение LSA (link state advertisment) заголовков из DBD с тем, что находится в LSDB и есть какая-то информация не найдена машрутизатор запрашивает инкрементальный апдейт – Link State Request (LSR), на что получает ответ – Link State Update (LSU). Если вам необходимо обновить не одну, а 4 сети, то вы в LSR отправляете запрос на эти 4 сети. В ответ вам придет один LSU, а внутри его 4 полных LSA (в отличии от одних заголовков вначале).
Full state
После того как завершена синхронизация базы данных, LSDB одинакова на обоих соседях, соседства установлены и OSPF процесс переходит в состояние FULL.
И только после этого в дело вступает алгоритм нахождения кратчайшего пути – SPF, который и разбирается с тем, что делать со всей этой информацией.