Протокол OSPF Cisco — Теория (часть 2)

Обмен топологической информацией протокола OSPF

Пополняем категорию настройка cisco. Продолжаем знакомиться с теоретическими основами протокола маршрутизации OSPF и его реализацией в оборудовании Cisco.

Процесс обмена топологическими базами протокола OSPF

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

Процесс состоит из следующих этапов

  • В зависимости от типа интерфейса OSPF-маршрутизаторы коллективно выбирают или не выбирают выделенный маршрутизатор (Designated RouterDR) и резервный выделенный маршрутизатор (Backup Designated RouterBDR)
  • Каждая пара маршрутизаторов обменивается содержимым своих баз LSDB, чтобы установить отношения смежности
  • После того как процесс обмена завершен, маршрутизаторы отслеживают изменения в сети и периодически повторно рассылают LSA-анонсы, даже когда находятся в состоянии с полностью согласованными топологическими базами (full)

Выбор выделенного маршрутизатора

В зависимости от типа интерфейса (зачастую используется такое понятие, как тип сети OSPF) в протоколе OSPF либо выбираются, либо не выбираются выделенный маршрутизатор (Designater Router — DR) и резервный выделенный маршрутизатор (Backup Designater Router — BDR). Существует несколько разновидностей интерфейсов с точки зрения протокола маршрутизации cisco OSPF, но на уровне CCNA нужно знать только два из них: двухточечный (point-to-point) и широковещательный (broadcast). Тип интерфейса при необходимости может быть указан с помощью команды ip ospf network тип.  Как вполне понятно из названий двух типов, двухточечный тип интерфейса — это, прежде всего, последовательные и двухточечные каналы, а широковещательный — это любая среда, в которой могут распространяться широковещательные фреймы, например локальная сеть.

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

Когда выделенный маршрутизатор не нужен, устройства переходят к следующему этапу и начинают обмен информацией о топологии (на нашем рисунке слева). Согласно терминологии протокола OSPF маршрутизаторы обмениваются своими топологическими базами данных и переходят в состояние с полностью согласованной топологией (fully adjacent). На рисунке справа показана локальная сеть, в которой выполняется выбор выделенного маршрутизатора (DR) и таким ведущим устройством становится маршрутизатор А. Если в сети есть DR-маршрутизатор, то обмен информацией происходит между выделенным устройством и остальными маршрутизаторами в сети, а не между всеми устройствами попарно. В результате именно выделенный маршрутизатор, устройство А, распространяет изменения топологии в сети среди других маршрутизаторов. Фактически все маршрутизаторы получают информацию от всех своих соседей, но обмен информацией осуществляется только между выделенным устройством и обычным маршрутизатором в сети.

Наличие DR-маршрутизатора в сети позволяет значительно уменьшить OSPF-трафик, когда в сети есть много маршрутизаторов. Например, если бы к сети было подключено 10 OSPF-маршрутизаторов и все они могли рассылать сообщения друг другу, анонс изменения топологии должен был бы быть переслан 45 раз, т.е. между всеми устройствами попарно. Вполне очевидно, что большая часть таких рассылок избыточна, устройства получили бы ту же самую информацию, но от других соседей! При наличии в сети выделенного маршрутизатора в той же самой сети достаточно разослать изменение топологии только 9 раз, от выделенного маршрутизатора девяти остальным устройствам, и количество рассылок в локальной сети заметно уменьшиться.

Поскольку выделенный маршрутизатор играет такую важную роль в процессе обмена информацией, его отказ может привести к задержкам в доставке анонсов и ухудшить время конвергенции протокола маршрутизации. Поэтому в протоколе маршрутизации используется еще один специальный тип маршрутизатора, резервный выделенный маршрутизатор (Backup DR — BDR). Когда DR-маршрутизатор отказывает или теряет связь с сетью, BDR-маршрутизатор становится DR-устройством. Следует отметить, что все остальные маршрутизаторы. т.е. не DR или BDR, называются «DROther» в выводе различных команд группы show операционной системы Cisco IOS. на нашем рисунке показаны логические каналы не выделенных маршрутизаторов только с DR машрутизатором A. Стоит запомнить что при наличии в сети как DR так и BDR маршрутизаторов, все DROther маршрутизаторы устанавливают отношения смежности и с DR, и с BDR устройствами.

Когда следует использовать выделенный маршрутизатор в сети, все маршрутизаторы проводят «выборы». Чтобы выбрать DR-устройство, OSPF-маршрутизаторы проверяют два поля в Hello-сообщениях, которые они получают от соседей и выбирают выделенное устройство согласно следующего алгоритмы.

  • DR-маршрутизатором станет устройство, у которого в Hello-пакетах установлен наибольший OSPF-приоритет (highest OSPF priority)
  • Если у двух или более маршрутизаторов приоритет одинаков (или он не установлен), выборы выигрывает маршрутизатор с большим значением RID.
  • Обычно маршрутизатор со следующим по величине значением RID становится BDR-устройством
  • Если значение приоритета равно 0, то маршрутизатор не участвует в выборах и не будет DR- или BDR-устройством
  • Приоритет можно выставлять в диапазоне от 1 до 255.
  • Если в сети появляется маршрутизатор с большим идентификатором RID, чем у существующего DR или BDR-устройства, перевыборы не происходят

Обмен топологическими базами

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

Когда два устройства завершают такой процесс, они переходят в состояние, называемое состоянием с полностью согласованными топологическими базами (fully completed или просто full). Следовательно, если в таблице соседей для смежного устройства отображается ключевое слово Full, значит, процесс обмена топологической информацией был успешно завершен.

Поддержание базы LSDB в актуальном состоянии

Даже когда для смежного маршрутизатора в таблице соседей указано состояние full, последний выполняет некоторую работу. Соседнее устройство рассылает Hello-сообщения периодически. Если такие сообщения отсутствуют в течении времени, определяемого dead-интервалом, то считается, что связь с соседним устройством потеряна. Если происходит изменение топологии сети, соседние устройства рассылают LSA-анонсы с изменениями, чтобы синхронизировать свои базы LSDB. Например, если интерфейс, ведущий в какую-либо подсеть, отказывает, то сразу же изменяется LSA-запись для такой сети и рассылается анонс, в котором, указано, что сеть недоступна. Маршрутизатор рассылает LSA-анонсы соседям, которые, в свою очередь, рассылают ее своим соседям, и так до тех пор, пока все устройства в домене маршрутизации протокола OSPF не синхронизируют свои базы LSDB. Каждый маршрутизатор затем запускает процесс SPF для пересчета маршрутов с учетом недоступной подсети.

Маршрутизатор, создавая LSA-запись, должен каждые 30 минут рассылать содержащий ее анонс, даже если в топологии сети ничего не изменилось. Этот процесс очень сильно отличается от аналогичного в дистанционно-векторных протоколах маршрутизации. Дистанционно-векторные протоколы маршрутизации рассылают полную таблицу своих маршрутов через короткие интервалы времени (за исключением тех маршрутов, которые были заблокированы механизмом расщепления горизонта). Протокол OSPF не рассылает всю таблицу каждые 30 минут. У каждой LSA-записи есть свой независимый таймер, который отсчитывается от времени создания записи. Поэтому в данном протоколе не бывает таких ситуаций, что в какой-либо момент маршрутизатор рассылает все LSA-анонсы заново; наоборот, загрузка каналов и устройств получается более-менее равномерной, поскольку изредка, в зависимости от состояния таймера, рассылается то один, то другой LSA-анонс.

Следует помнить, что не всегда маршрутизаторы могут переходить в состояние полного согласования баз данных (full). В частности, если для сети определенного интерфейса был выбран DR-маршрутизатор, устройства, не являющиеся DR- или BDR-маршрутизаторами, будут смежными, но не будут напрямую синхронизировать свои базы данных. Команда show ip ospf neighbor в таком устройстве будет показывать, что с соседними маршрутизаторами был установлен двусторонний канал, а состояние полной синхронизации (full) будет отображаться только для DR и BDR-маршрутизаторов.

Состояние соседних устройств в протоколе OSPF



Comments

  1. By Констанин

    Ответить

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>