Часть 3. Формирование соседства и смежности в OSPF в point-to-point network type

В прошлой статье «Часть 2. Базовая настройка протокола OSPF на маршрутизаторе Cisco» был рассмотрен вопрос базовой настройки OSPF, необходимой для начала обмена маршрутами между маршрутизаторами в одной области (area 0) посредством протокола динамической маршрутизации.

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

8 шагов к успеху

Прежде, чем переходить к рассмотрению вопроса данной статьи, необходимо обратить внимание на требования, необходимые для установления соседства/смежности между OSPF маршрутизаторами:

  1. OSPF маршрутизатор должен иметь OSPF Router Id, и этот OSPF Router Id должен быть уникален внутри домена OSPF маршрутизации (т.е. на всех OSPF маршрутизаторах внутри автономной системы)
  2. Маршрутизаторы должны принадлежать одной области (area) (а точнее интерфейсы, посредством которых эти маршрутизаторы соединены)
  3. Интерфейсы, соединяющие маршрутизаторы, должны быть настроены на использование IP адресов из одной подсети
  4. У маршрутизаторов должны совпадать OSPF Hello-интервалы и Dead-интервалы
  5. У маршрутизаторов должны совпадать MTU на интерфейсах
  6. Если настроена OSPF аутентификация, то она должна быть выполнены
  7. Интерфейсы между маршрутизаторами не должны быть объявлены в процессе OSPF как «passive»
  8. Не запрещён multicast-трафик между маршрутизаторами (требование не обязательное в некоторых случаях)

Разберём чуть подробнее каждый пункт.

1. OSPF Router ID желательно задавать вручную при конфигурировании процесса OSPF на роутере (облегчает troubleshoot’инг OSPF’а), но можно и оставить выбор Router ID протоколу OSPF. Напомним алгоритм выбора OSPF Router ID:

— Задаётся вручную командой router-id 1.1.1.1 (наиболее предпочтительный способ)
— Выбирается наибольший IP адрес Loopback интерфейса, который в состоянии up/up
— Выбирается наибольший IP адрес физического интерфейса, который в состоянии up/up

2. Маршрутизаторы не станут OSPF-соседями, если интерфейсы, посредством которых они соединены принадлежат разным OSPF областям. Т.е. если R1 и R2 соединены через интерфейсы gi1/0 и gi2/0 соответственно, то оба эти интерфейса должны быть настроены на использование в одной OSPF area

3. Eсли R1 и R2 соединены через интерфейсы gi1/0 и gi2/0 соответственно, то IP адреса на обоих интерфейсах должны быть в одной подсети:

— правильно:

  • R1 IP gi1/0 — 192.168.5.1/24
  • R2 IP gi2/0 — 192.168.5.2/24

— не правильно:

  • R1 IP gi1/0 — 192.168.5.1/24
  • R2 IP gi2/0 — 192.168.5.2/30

хотя сеть 192.168.5.2/30 (IP адрес gi2/0 на R2) является подсетью для сети 192.168.5.1/24 (IP адрес gi1/0 на R1) и ping будет работать с R1 до R2, но OSPF соседство между R1 и R2 не установится

4. OSPF Hello-интервал и Dead-интервал — это механизмы, которыми OSPF маршрутизаторы после установления OSPF соседства проверяют доступность своих OSPF-соседей («живы» ли они там). По-умолчанию Dead-интервал = 4 х Hello-интервалам. Если OSPF соседство установлено, то OSPF маршрутизатор посылает сообщения Hello с интервалом = Hello-интервалу, и если в какой-то момент времени от соседа не получено ни одного Hello сообщения в течение Dead-интервала, то сосед считается недостижим, соседство с ним сбрасывается, из LSBD очищаются все полученные от этого соседа LSA, запускается процесс SPF для заполнения таблицы маршрутизации новыми маршрутами. Hello-интервал и Dead-интервал можно настраивать на интерфейсах:

  • R1(config-if)#ip ospf hello-interval 3   (в секундах)
  • R1(config-if)#ip ospf dead-interval 12   (в секундах)

Можно выставить минимальные Hello-интервал и Dead-интервал:

  • R1(config-if)#ip ospf dead-interval minimal hello-multiplier 5

при этом  Dead-интервал будет равен 1 сек, а Hello-интервал — 0.2 сек (hello-multiplier 5 в команде указывает количество сообщений Hello в течение Dead-интервала). Кстати, на интерфейсах, с пропускной способностью выше чем T1 (1.5 Mb/s), Hello-интервал = 10 сек, а Dead-интервал = 40 сек.

Смена OSPF Hello-интервала или Dead-интервала на интерфейсе только одного из двух OSPF-соседей приведёт к потере OSPF-соседства между маршрутизаторами.

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

6. Если на одном маршрутизаторе настроена аутентификация, а на другом — нет (или же не совпадают параметры аутентификации), то ни о каком OSPF-соседстве разговора быть не может (ну это и понятно)

7. Интерфейс, объявленный как passive не отправляет и не принимает OSPF Hello сообщения, соответственно процесс установления соседства даже не начнётся.

8. Т.к. OSPF маршрутизатор пытается установить соседство с другими OSPF маршрутизаторами посредством отправки Hello пакетов (сообщений), а эти Hello пакеты отправляются маршрутизатором на multcast-адрес 224.0.0.5, то запрет multcast-трафика между маршрутизаторами приведёт к провалу в поисках потенциальных OSPF соседей.

Лучше один раз увидеть, чем сто раз услышать (или от слов — к делу)…

Визуализируем процесс установления OSPF соседства/смежности между двумя маршрутизаторами.

Будем использовать нашу предыдущую топологию, только пока выключим R3 и R4, для большей наглядности добавим на R1 3 loopback-интерфейса:

  • loop1 — 1.0.1.1/32
  • loop2 — 1.0.2.1/32
  • loop3 — 1.0.3.1/32

и на R2 тоже добавим 3 loopback-интерфейса:

  • loop1 — 2.0.1.1/32
  • loop2 — 2.0.2.1/32
  • loop3 — 2.0.3.1/32

Добавим эти интерфейсы в процесс OSPF (командой network соответственно) на R1 и R2.

topol_4

и посмотрим, как будет устанавливаться OSPF соседство между R1 и R2 в OSPF point-to-point сети (в одной подсети присутствует не более двух маршрутизаторов). Для этого необходимо на интерфейсах маршрутизаторов, участвующих в OSPF процессе указать тип сети командой:

R1(config-if)#ip ospf network point-to-point

 

Состояния, которые проходят OSPF маршрутизаторы при установлении соседства/смежности:

  1. Down — от соседа не получено ни одного OSPF Hello-сообщения в течение Dead Interval’а
  2. Attempt — в NBMA-сетях маршрутизатор переходит в это состояние после указания в процессе OSPF команды «neighbor X.X.X.X«, отправки Hello-сообщения, но до приёма Hello-сообщения от потенциального OSPF-соседа
  3. Init — маршрутизатор переходит в это состояние, когда получил Hello-сообщение от другого маршрутизатора, но в этом Hello-сообщении:
    • либо нет OSPF Router ID маршрутизатора, принявшего это Hello-сообщение
    • либо не совпадает один или несколько параметров, рассмотренных в перечне «8 шагов к успеху», кроме MTU, которое в этом шаге не учитывается.

    Здесь важно акцентировать внимание на том, что если хотя бы один параметр в Hello-сообщении не совпадает, то маршрутизаторы «застрянут» в этом состоянии (в состоянии Init)

  4. 2-Way — Hello-сообщение было получено от соседа, в этом Hello-сообщении есть OSPF Router ID и все параметры в Hello-сообщении у OSPF маршрутизаторов совпадают
  5. ExStart — согласование последовательного номера DataBase Description и выбор master/slave маршрутизатора для обмена пакетами DataBase Description
  6. Exchange — обмен пакетами DataBase Description
  7. Loading — прошёл обмен всеми пакетами DataBase Description и начинается обмен LSA, которые необходимы каждому маршрутизатору
  8. Full — маршрутизаторы обменялись необходимыми LSA, подразумевается что у них теперь идентичные LSDB для области (area), в которой они находятся. Запускается на выполнение алгоритм SPF на каждом из этих маршрутизаторов с целью поиска маршрутов и установки их в таблицу маршрутизации.

Теперь каждый шаг подробнее. Я предварительно отправил в «down» интерфейс gi2/0 на R1. После включения этого интерфейса видим следующую картину (смотрим Wireshark’ом):

topol_5

После того, как интерфейс gi2/0 на R1 перешёл в состояние up/up, OSPF отправляет через этот интерфейс сообщение Hello на multicast-адрес 224.0.0.5 (пункт 25 на рисунке) с целью найти OSPF-соседа и находится в состоянии Down.

Посмотрим содержимое Hello-сообщения от R1 (Frame №25):

topol_6

На картинке:

  1. Видим, что протокол OSPF не использует TCP или UDP на транспортном уровне, т.к. имеет собственный транспорт — IP протокол 89
  2. Рассматриваем заголовок OSPF пакета (OSPF Header):
  3. В заголовке пакета передаётся версия протокола OSPF (в данном случае Version 2, которая говорит об использовании OSPF для IPv4)
  4. Тип пакета — Hello пакет
  5. OSPF Router ID маршрутизатора, отправившего этот Hello пакет
  6. Номер области, к которой принадлежит этот Hello пакет — area 0 (Backbone Area)
  7. Тип аутентификации — аутентификация между R1 и R2 не настроена.
  8. Теперь рассмотрим содержимое Hello пакета OSPF:
  9. В содержимом Hello пакета видим указание Hello Interval, равное 10 секунд
  10. Приоритет маршрутизатора = 1 (это значение по-умолчанию; используется для выбора DR/BDR в multiaccess сетях)
  11. Dead Interval, равный 40 секундам
  12. Designated Router 0.0.0.0 (0.0.0.0) говорит о том, что DR ещё не выбран
  13. Backup Designated Router 0.0.0.0 (0.0.0.0) говорит о том, что BDR ещё не выбран

R2, получив это Hello-сообщение от R1, не обнаруживает в нём свой OSPF Router ID и переходит в состояние Init.

R2 тоже шлёт Hello пакет на multicast-адрес 224.0.0.5. Содержимое Hello-сообщения от R2 (Frame №26):

topol_7

Ничего нового, кроме появления записи «Active Neighbor 1.1.1.1 (1.1.1.1)» (подчёркнуто красным на картинке). Данная запись говорит о том, что R2 уже получил Hello-сообщение от маршрутизатора, у которого OSPF Router ID равен 1.1.1.1 (в нашем случае от маршрутизатора R1).

R1, получив это Hello-сообщение, видит в нём свой OSPF Router ID, проверяет параметры в этом Hello-пакете (такие как OSPF Router ID, № area, Hello- и Dead-интервалы, тип аутентификации, совпадение подсети на интерфейсе потенциального соседа), переходит в состояние Init -> 2-Way и отсылает (опять же на multicast-адрес 224.0.0.5) Hello-сообщение следующего содержания (Frame №28):

topol_8

Здесь добавляется запись «Active Neighbor 2.2.2.2 (2.2.2.2)» (подчёркнуто красным на картинке). Данная запись говорит о том, что R1 тоже получил Hello-сообщение от маршрутизатора, у которого OSPF Router ID равен 2.2.2.2 (в нашем случае от маршрутизатора R2).

R2, получив это Hello-сообщение, видит в нём свой OSPF Router ID, проверяет параметры в этом Hello-пакете (такие как OSPF Router ID, № area, Hello- и Dead-интервалы, тип аутентификации, совпадение подсети на интерфейсе потенциального соседа) и переходит в состояние 2-Way.

Перейдя в состояние 2-Way, R1 и R2 установили между собой отношения соседства. Здесь можно провести грань между понятием «соседство» и «смежность (adjacency)«. Когда 2 маршрутизатора перешли в состояние 2-Way, то они установили отношения соседства, но маршрутной информацией на данном этапе они не обмениваются.

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

 

Далее начинается этап №5 «ExStart«.

Смотрим что происходит на данном этапе между R1 (Frame 27) и R2 (Frame 29). Сначала R1:

topol_9

На картинке:

  1. R1 шлёт на multicast-адрес 224.0.0.5 пакет «OSPF DB Description«
  2. В этом пакете содержится значение MTU. Здесь важно отметить, что при несовпадающих значениях MTU на интерфейсах, участвующих в установлении отношений смежности, маршрутизаторы начнут переходить из состояния «ExStart» в «Down», потом снова все состояния до «ExStart» и снова в «Down», и так по кругу.
  3. Установленный бит «Master/Slave» (чуть ниже про него)
  4. Последовательный номер Database Description

Теперь пакет DBD от R2 (Frame 29):

topol_10

В принципе ничего нового, ну кроме «Source OSPF Router», «Checksum» пакета и другого последовательного номера Database Description.

На данном этапе происходит выбор «Master/Slave» роли маршрутизатора. Каждый маршрутизатор выставляет бит «Master/Slave» в «1», тем самым пытаясь занять роль «Master’а». Но только маршрутизатор с бОльшим OSPF Router ID займёт роль «Master’а», а маршрутизатор с меньшим OSPF Router ID займёт роль «Slave».

Маршрутизатор в роли «Master» контролирует весь процесс Database Description.

 

Далее начинается этап №6 «Exchange«.

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

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

Итак, R1 «выливает» заголовки LSA из своей LSDB (всё ещё на multicast-адрес 224.0.0.5):

topol_11

На картинке:

  1. Тип OSPF пакета — DataBase Description
  2. Начало содержимого DataBase Description-пакета
  3. R1 установил бит «Master/Slave» в «0», т.к. имеет меньший OSPF Router ID (1.1.1.1) по сравнению с R2 (2.2.2.2)
  4. Заголовок первой LSA из LSDB
  5. Время жизни этой LSA в LSDB маршрутизатора R1
  6. Тип LSA. Ruter-LSA (тип 1) означает, что LSA создана самим маршрутизатором
  7. Идентификатор LSA (LSID), которым маршрутизатор помечает созданную им LSA (эта LSA была создана маршрутизатором с OSPF Router ID = 1.1.1.1)
  8. OSPF Router ID маршрутизатора, который анонсирует эту LSA
  9. Последовательный номер этой LSA. Важно отметить, что маршрутизатор каждые 30 минут увеличивает последовательный номер каждой созданной им LSA и отсылает эту LSA своим OSPF-соседям.
  10. Заголовок второй LSA
  11. Время жизни этой LSA в LSDB маршрутизатора R1
  12. Идентификатор LSA (LSID), которым маршрутизатор помечает созданную им LSA (эта LSA была создана маршрутизатором с OSPF Router ID = 2.2.2.2)
  13. Последовательный номер этой LSA.

Теперь смотрим, что «выливает» R2 из своей LSDB (тоже на multicast-адрес 224.0.0.5):

topol_12

На картинке почти ничего нового, кроме:

  1. R2 установил бит «Master/Slave» в «1», т.к. имеет больший OSPF Router ID (2.2.2.2) по сравнению с R1 (1.1.1.1)
  2. Идентификатор LSA (LSID), которым маршрутизатор помечает созданную им LSA (эта LSA была создана маршрутизатором с OSPF Router ID = 1.1.1.1)
  3. Последовательный номер этой LSA. А вот тут важный момент: LSA, имеющая LSID 1.1.1.1 (т.е. которую анонсирует R1), в LSDB маршрутизатора R2 имеет последовательный номер 0x8000001e, а в LSDB R1 эта же LSA имеет бОльший последовательный номер 0x8000001f (видно на предыдущей картинке в п.9)
  4. Идентификатор LSA (LSID), которым маршрутизатор помечает созданную им LSA (эта LSA была создана маршрутизатором с OSPF Router ID = 2.2.2.2)
  5. Последовательный номер этой LSA. А вот тут ещё один важный момент: LSA, имеющая LSID 2.2.2.2 (т.е. которую анонсирует R2), в LSDB маршрутизатора R2 имеет последовательный номер 0x80000024, а в LSDB R1 эта же LSA имеет меньший последовательный номер 0x80000023 (видно на предыдущей картинке в п.13)

Т.о. видим, что обе LSA (с LSID 1.1.1.1 и LSID 2.2.2.2) присутствуют у обоих маршрутизаторов R1 и R2 в их LSDB, но последовательные номера у этих LSA отличаются, а чем больше последовательный номер (Sequence Number) LSA, тем она считается новее.

 

Далее начинается этап №7 «Loading«.

Недостающие и более новые LSA маршрутизатор запрашивает у соседа посредством LSR-пакетов. Сосед же передаёт запрошенные LSA посредством LSU-пакетов, содержащих одну или более LSA.

R1 запрашивает LSA у R2 (запрос идёт на multicast-адрес 224.0.0.5):

topol_13

На картинке:

  1. Тип OSPF сообщения — LSR
  2. OSPF Router ID запрашивающего маршрутизатора
  3. Тип запрашиваемых LSA — «Router LSA»
  4. LSID запрашиваемых LSA

R2 отвечает на запрос, полученный от R1 (ответ идёт на multicast-адрес 224.0.0.5)

topol_14

 

На картинке:

  1. Тип OSPF сообщения — LSU
  2. OSPF Router ID отвечающего маршрутизатора
  3. Начало содержимого LSU-пакета
  4. Количество LSA в этом LSU пакете
  5. Время жизни этой LSA (напомню, что время жизни LSA составляет 30 минут, после чего увеличивается на 1 Sequence Number этой LSA и она рассылается OSPF соседям)
  6. LSID отсылаемой LSA
  7. Последовательный номер (Sequence Number) этой LSA
  8. Количество линков в этой LSA
  9. Секция с описанием одного из линков (Loopback 1 в данном случае)
  10. Секция с перечнем 2-ух остальных Loopback-интерфейсов
  11. Секция с описанием линка, соединяющего R1 и R2

Теперь R2 запрашивает LSA у R1 (запрос идёт на multicast-адрес 224.0.0.5):

topol_15

 

На картинке:

  • Тип OSPF сообщения — LSR
  • Запрашивающий OSPF RID — 2.2.2.2
  • Тип запрашиваемых LSA — Router-LSA
  • LSID запрашиваемых LSA — 1.1.1.1

Ответ R1 на запрос от R2 (ответ идёт на multicast-адрес 224.0.0.5):

topol_16

 

Ничего нового, кроме предпоследнего линка (обведено в прямоугольник). Здесь видно, что линк соединяет текущий маршрутизатор R1 с маршрутизатором, имеющим OSPF Router ID 2.2.2.2 (т.е. R2), через интерфейс с IP адресом 192.168.12.1

После того, как маршрутизаторы R1 и R2 обменялись необходимыми LSA, они подтверждают приём этих LSA отправкой OSPF сообщения LSAck (на multicast-адрес 224.0.0.5):

topol_17

 

Здесь R1 отправляет OSPF сообщение LSAck от, что он получил LSA типа Router-LSA и эти LSA имеют LSID 2.2.2.2. Последовательный номер этой LSA — 0x80000024, контрольная сумма — 0x555f и длина — 84: все три значения соответствуют значениям в пакете LSU, приём которого подтверждает данный LSAck.

Аналогичный LSAck отправит и маршрутизатор R2.

После этого маршрутизаторы установили отношения смежности (adjacency), имеют идентичные LSDB, одинаковое представление о топологии в области area 0, переходят в состояние Full и обмениваются Hello-сообщениями каждые 10 секунд. Просмотреть соседей можно командой:

R1#show ip ospf neighbor

Neighbor ID       Pri       State       Dead Time        Address            Interface
2.2.2.2                0      FULL/ —        00:00:34      192.168.12.2    GigabitEthernet2/0

Подытожив процесс установления соседства/смежности в OSPF point-to-point сети хотелось бы выделить несколько ключевых моментов:

  • Обмен всеми сообщениями в данном типе сети идёт на multicast-адрес 224.0.0.5
  • При несовпадении параметров, передающихся в OSPF Hello сообщении, маршрутизаторы «застрянут» в состоянии Init
  • При несовпадении MTU на интерфейсах, через которые маршрутизаторы пытаются установить соседство, маршрутизаторы будут циклично проходить состояния от «Down» до «ExStart/Exchange«.
  • Конечным состоянием при установлении смежности должно быть состояние Full.

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