Часть 4. Формирование соседства и смежности в OSPF в multiaccess network type

В предыдущей статье Часть 3. Формирование соседства и смежности в OSPF в point-to-point network type рассмотрены требования, необходимые для установления соседства/смежности между OSPF маршрутизаторами и состояния, через которые проходят OSPF маршрутизаторы при установлении соседства/смежности в point-to-point сетях.

В multiaccess-сетях в одной подсети может присутствовать два и более маршрутизатора. В этих сетях присутствуют те же требования для установления соседства/смежности между OSPF маршрутизаторами что и в point-to-point сетях. Однако логика установления соседства/смежности несколько отличается.

Для дальнейшего рассмотрения темы будем использовать следующую топологию:

topol_41

Базовые настройки маршрутизаторов на данном этапе:

маршрутизатор R1:

interface GigabitEthernet1/0
ip address 172.16.0.1 255.255.255.0
!
router ospf 1
router-id 1.1.1.1

маршрутизатор R2:

interface GigabitEthernet1/0
ip address 172.16.0.2 255.255.255.0
!
router ospf 2
router-id 2.2.2.2

маршрутизатор R3:

interface GigabitEthernet1/0
ip address 172.16.0.3 255.255.255.0
!
router ospf 3
router-id 3.3.3.3

маршрутизатор R4:

interface GigabitEthernet1/0
ip address 172.16.0.4 255.255.255.0
!
router ospf 4
router-id 4.4.4.4

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

На данном этапе обмен маршрутной информацией посредством протокола OSPF не осуществляется, т.к. маршрутизаторы ещё не настроены на работу с OSPF.

Запускаем Wireshark и добавляем на R1 команду, которая запустит процесс OSPF на его интерфейсе gi1/0 в области area 0:

R1(config)# router ospf 1
R1(config-router)# network 172.16.0.1 0.0.0.0 area 0

Снимок с Wireshark’а:

topol_42

R1 начинает каждые 10 секунд отсылать Hello-сообщения на multicast-адрес 224.0.0.5 в поисках потенциального OSPF-соседа. На картинке 6-ое по счёту Hello-сообщение, отличающееся от предыдущих 5-ти только подчёркнутой строкой (в предыдущих Hello-сообщениях в этой строке было: «Designated Router: 0.0.0.0 (0.0.0.0)«). Произошло это потому, что истёк OSPF таймер, который называется «OSPF Wait Timer» и равен он 40 секундам (по-умолчанию). По истечение этого таймера, если в сети нет Designated Router‘а, то место Designated Router‘а займёт новый появившийся в сети маршрутизатор. R1 взял на себя роль Designated Router‘а и начал «говорить» об этом в Hello-сообщениях.

Для большей наглядности дальнейших процессов добавим на R1 один Loopback-интерфейс и запустим на нём процесс OSPF:

R1(config)# interface loopback 0
R1(config-if)# ip address 10.0.1.1 255.255.255.0
R1(config-if)# exit
!
R1(config-if)# router ospf 1
R1(config-router)# network 10.0.1.1 0.0.0.0 area 0

и запустим OSPF на интерфейсе gi1/0 маршрутизатора R2:

R1(config-if)# router ospf 2
R1(config-router)# network 172.16.0.2 0.0.0.0 area 0

Весь процесс установления соседства и обмена данными о топологии между R1 и R2 представлен на рисунке:

topol_43

Разберём более детально этапы установления соседства и обмена данными о топологии между R1 и R2.

Итак R2 начинает слать через интерфейс gi1/0 Hello-сообщения на multicast-адрес 224.0.0.5 (как и положено каждые 10 секунд):

topol_44

Естественно ни о каких Designated Router‘ах (DR) и Backup Designated Router‘ах (BDR) маршрутизатору R2 пока не известно (о чём свидетельствуют две записи, подчёркнутые красным внизу картинки). R2 пока находится в OSPF состоянии Down.

R1 «услышал» Hello-сообщение от R2 и отправляет Hello-сообщение на multicast-адрес 224.0.0.5:

topol_45

указывая в теле Hello-пакета IP-адрес DR‘а (т.е. IP-адрес своего интерфейса gi1/0) и OSPF Router ID (2.2.2.2) маршрутизатора R2, от которого услышал Hello-сообщение. Приняв это Hello-сообщение, R2 «увидел» в нём свой OSPF Router-ID, проверяет соответствие параметров OSPF (Router ID, Hello- и Dead-интервалы, номер area, тип аутентификации) в сообщении своим и, в случае их соответствия, переходит в состояние Init -> 2-Way. R2 видит, что в сети уже есть DR (строка «Designated Router: 172.16.0.1 (172.16.0.1)» в Hello-сообщении от R1), но нет BDR‘а (что видно из строки «Backup Designated Router: 0.0.0.0 (0.0.0.0)» в Hello-сообщении от R1), и R2 «соглашается» взять на себя роль BDR‘а, о чём свидетельствует оправляемое им Hello-сообщение:

topol_46

строка «Backup Designated Router: 172.16.0.2 (172.16.0.2)», в которой R2 указывает IP-адрес интерфейса, на котором запущен OSPF. В сообщении R2 также указывает Router ID маршрутизатора R1, от которого ранее получил Hello-пакет.

Здесь важный момент: маршрутизаторы начинают обмениваться OSPF-пакетами не на multicast-адрес 224.0.0.5, а на IP-адреса интерфейсов, на которых запущен OPSF (подчёркнутая строка вверху картинки). Если вспомнить установление соседства/смежности между OSPF маршрутизаторами в point-to-point сетях, то там все OSPF-сообщения отправлялись на multicast-адрес 224.0.0.5.

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

Итак, оба маршрутизатора в состоянии 2-Way и прошёл выбор DR и BDR в сети. Перейдя в состояние 2-Way, R1 и R2 установили между собой отношения соседства.

Смотрим, что происходит дальше. А дальше R2 переходит в состояние ExStart и отправляет DataBase Description (DBD) пакет на IP адрес нового соседа (R1 в данном случае). R2 выставляет Master/Slave bit в «1»:

topol_47

R1 тоже отправляет аналогичный пакет на на IP адрес нового соседа (R2 в данном случае). R1 выставляет Master/Slave bit в «1»:

topol_48

В итоге роль Master‘а в процессе DataBase Description занимает R2, т.к. у него больший OSPF Router ID. R1 устанавливает Master/Slave bit в «0» (видно в следующих пакетах от R1). Важно отметить, что при разных значениях MTU на интерфейсах gi1/0 маршрутизатора R1 и gi1/0 маршрутизатора R2 дальнейший процесс обмена между маршрутизаторами продолжаться не будет, маршрутизаторы будут переходить из состояния ExStart в Down, далее Init -> 2-Way -> ExStart и снова в Down.

Далее начинается процесс Exchange, в котором маршрутизаторы обмениваются заголовками LSA в DBD-сообщениях. Видим DBD-пакет от R1, отправленный на IP адрес R2:

topol_49

и DBD-пакет от R2, отправленный на IP адрес R1:

topol_49_1

R1, получив DBD-пакет от R1 обнаружил в нём новую LSA, которой у него нет в LSDB, переходит в состояние Loading и отправляет (опять же на IP адрес R2) запрос (LSR) на эту LSA:

topol_49_2

в запросе видно, что R1 запрашивает Router-LSA (LSA 1-го типа) с LSID 2.2.2.2 (маршрутизатор, когда создаёт и анонсирует свои LSA, присваивает им Link State ID (LSID), равный своему OSPF Router ID) у маршрутизатора с OSPF Router ID = 2.2.2.2.

R2 в ответ на запрос от R1 отправляет LSU (опять же на IP адрес R1), в которой содержится запрашиваемая LSA с перечнем префиксов сетей:

topol_49_3

R2 переходит в состояние Loading и запрашивает у R1 LSA, заголовок которой R2 «услышал» от R1 в процессе DBD, т.к. данной LSA либо нет у R2 в LSDB, либо «Sequence Number» этой LSA в LSDB маршрутизатора R2 имеет меньший номер, чем «Sequence Number» этой LSA в LSDB маршрутизатора R1:

topol_49_4

R1, получив запрос на LSA, отправляет (всё ещё на IP адрес R2) LSU, содержащую запрашиваемую LSA:

topol_49_5

Теперь, т.к. R1 является Designated Router‘ом (DR) и ответственен за распространение маршрутной информации между маршрутизаторами, он отправляет чуть изменённый LSU уже на multicast-адрес 224.0.0.5 для остальных маршрутизаторов (DROther‘ов) в сети; при этом увеличивая «Sequence Number» LSA в этой LSU на «1»:

topol_49_6

Опять же, роль DR‘а обязывает R1 создать LSA типа 2, так называемую Network-LSA, которую R1 должен отослать на multicast-адрес 224.0.0.5 для всех маршрутизаторов (DROther‘ов):

topol_49_7

присваивая этой LSA «Sequence Number» 0x80000001 и LSID, равный IP адресу интерфейсу R1, с которого отправляется эта LSA.

Ну и в конце R1 подтверждает принятый LSU от R2 сообщением LSAck на multicast-адрес 224.0.0.5:

topol_49_8

а R2 таким же LSAck подтверждает принятый LSU от R1 на multicast-адрес 224.0.0.5. Обменявшись LSA, маршрутизаторы перешли в состояние Full.

Теперь в сети присутствуют 2 маршрутизатора (R1 и R2), R1 является Designated Router‘ом (DR), а R2 —  Backup Designated Router‘ом (BDR), у обоих идентичные LSDB, т.е. одинаковое представление о топологии сети в области area 0. Они рассылают периодические Hello-сообщения на multicast-адрес 224.0.0.5.

Теперь рассмотрим что происходит при добавлении в сеть нового маршрутизатора (R3).

Запускаем OSPF на интерфейсе gi1/0 маршрутизатора R3:

R1(config-if)# router ospf 3
R1(config-router)# network 172.16.0.3 0.0.0.0 area 0

R3 отправляет через интерфейс gi1/0 Hello-сообщение на multicast-адрес 224.0.0.5 (Frame 8) и происходят следующие процессы:

topol_49_9

BDR R2, услышав Hello-сообщение на multicast-адресе 224.0.0.5 отправляет ответное Hello-сообщение на multicast-адрес 224.0.0.5 (Frame 13), в котором содержатся, помимо прочего, ещё и IP-адреса DR и BDR:

topol_49_10

Теперь R3 осведомлён о наличии в сети DR‘а и BDR‘а. R2 и R3 проходят все состояния установления соседства (Init -> 2-Way -> ExStart -> Exchange -> Loading -> Full), отсылая сообщения (DBD, LSR, LSU) на IP-адреса друг друга (процесс в принципе аналогичен процессу, рассмотренному подробно выше, когда устанавливалось соседство между R1 и R2, с той только разницей что сейчас не будет происходить выбор DR‘а и BDR‘а). Обменявшись LSA, R3 отправляет LSAck DR‘у на multicast-адресе 224.0.0.6 с перечнем всех LSA, которые он теперь знает (Frame 23):

topol_49_11

DR R1, услышав Hello-сообщение от R3, тоже отправляет ответное Hello-сообщение на multicast-адрес 224.0.0.5 (Frame 23), в котором содержатся, помимо прочего, ещё и IP-адреса DR и BDR:

topol_49_12

R1 и R3 проходят все состояния установления соседства (Init -> 2-Way -> ExStart -> Exchange -> Loading -> Full), отсылая сообщения (DBD, LSR, LSU) на IP-адреса друг друга. После обмена все 3 маршрутизатора (R1, R2 и R3) имеют одинаковое представление о топологии сети в области area 0.

Но что, если в сети присутствуют другие маршрутизаторы? Они ещё не знают о появившемся R3, т.к. процесс обмена LSA между маршрутизаторами происходил на IP-адреса друг друга. А вот для этого и нужен DR, который получив новые (или обновлённые LSA), старательно «расскажет» о них всем маршрутизаторам в сети на multicast-адрес 224.0.0.5, что подтверждает Frame 32:

topol_49_13

К тому же, DR должен разослать всем маршрутизаторам обновлённую LSA типа 2 (Network-LSA), увеличив её Sequence Number на «1», на multicast-адрес 224.0.0.5:

topol_49_14

Маршрутизаторы подтверждают приём Network-LSA на DR multicast-адрес 224.0.0.6:

topol_49_15

BDR подтверждает приём LSU на multicast-адрес 224.0.0.5.

Теперь в сети присутствуют 3 маршрутизатора (R1,R2 и R3), R1 является Designated Router‘ом (DR), R2 —  Backup Designated Router‘ом (BDR), а R3 — рядовым маршрутизатором (DROther), у всех идентичные LSDB, т.е. одинаковое представление о топологии сети в области area 0. Они рассылают периодические Hello-сообщения на multicast-адрес 224.0.0.5.

Запустим OSPF на R4 и посмотрим таблице соседей OSPF:

R1(config-if)# router ospf 4
R1(config-router)# network 172.16.0.4 0.0.0.0 area 0

На R1:

topol_49_16

R1 имеет 3-ёх OSPF-соседей, достижимых через свой интерфейс gi1/0. Со всеми соседями R1 установил отношения полной смежности (full adjacency), о чём говорят записи «FULL» в столбце «State». В этом же столбце, через слэш, указан тип соседа: BDR — Backup Designated Router, DROTHER — обычный рядовой маршрутизатор. В выводе этой команды так же указаны OSPF Router ID соседей и IP-адреса их интерфейсов. В столбце «Pri» указан приоритет  соседа (влияющий на выбор DR/BDR). В столбце «Dead Timer» идёт отсчёт значения OSPF Dead-interval, настроенного на интерфейсе R1 (gi1/0 в данном случае).

На R2:

topol_49_17

DR и BDR со всеми маршрутизаторами устанавливают состояние FULL. Т.е. устанавливают отношения полной смежности, обмениваясь LSA.

На R3:

topol_49_18

На R4:

topol_49_19

DROther устанавливают отношения FULL только с DR и BDR, а с рядовыми маршрутизаторами устанавливают отношения 2-Way. Т.е. рядовые маршрутизаторы будут обмениваться LSA только с DR и BDR, а с рядовыми обмениваться LSA не будут.

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

  • В данном типе сетей как правило выбираются Designated Router (DR) и Backup Designated Router (BDR). При одновременной загрузке нескольких маршрутизаторов (или одновременном запуске процесса OSPF на нескольких маршрутизаторах) в области, DR’ом станет маршрутизатор с наибольшим OSPF приоритетом, настроенным на интерфейсе («ip ospf priority ЧИСЛО«), BDR’ом станет маршрутизатор со следующим по уменьшению значением ospf priority. Если все маршрутизаторы имеют одинаковый ospf priority, ты выбор будет основываться на бОльших значениях OSPF Router ID, т.е. DR’ом станет маршрутизатор с наибольшим OSPF Router ID, BDR’ом — маршрутизатор со следующим по уменьшению значением OSPF Router ID.
  • IP адреса DR’а и BDR’а передаются в Hello-сообщениях
  • При несовпадении параметров, передающихся в OSPF Hello сообщении, маршрутизаторы «застрянут» в состоянии Init
  • При несовпадении MTU на интерфейсах, через которые маршрутизаторы пытаются установить соседство, маршрутизаторы будут циклично проходить состояния от «Down» до «ExStart/Exchange».
  • Обмен Hello-сообщениями происходит на multicast-адрес 224.0.0.5, обмен сообщениями DBD, LSR идёт на unicast-адрес маршрутизатора. Сообщения LSU и LSAck могут отправляться как на unicast-адрес маршрутизатора, так и на multicast-адреса 224.0.0.5 и 224.0.0.6
  • Конечным состоянием у Designated Router’а (DR) и Backup Designated Router’а (BDR) со всеми OSPF маршрутизаторами должно быть «FULL«
  • Конечным состоянием у DROther c Designated Router’ом (DR) и Backup Designated Router’ом (BDR) должно быть «FULL«, у DROther с DROther — «2-Way«

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