Придумывая лучший способ что-то объяснить, я почти всегда нахожу и лучший способ понять это для себя.
Сасскинд Л., Грабовски Дж.
Теоретический минимум.
Все, что нужно знать о современной физике.*

Перевод главы из книги Chris Bryant «CCNP Route Study Guide». Его сайт — thebryantadvantage.com. Книга доступна на amazon.

Из всех просмотренных видео, прочитанных книг для подготовки к CCNP ROUTE, материал из этой показался наиболее легким для усвоения. Позволяет разложить все по полочкам. Кроме теории мне также понравились практические примеры. В конце каждой главы есть ссылки на уроки на youtube.

Основы протоколов состояния канала

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

Избегайте соблазна пропустить обзор.

А пока совсем немногое вам будет знакомо — есть множество дополнительных деталей, которыми вы должны овладеть как CCNP. Для тех, кто собирается сдавать CCIE, нужно по-настоящему освоить принцип работы OSPF.

Когда RIP посылает обновления маршрутов, они содержат полную таблицу маршрутизации. Включая отладку командой debug ip rip, вы можете увидеть маршруты, содержащиеся в обновлении вместе с метрикой.

Протоколы состояния канала работают по-другому. Маршрутизаторы состояния канала, которые сформировали соседство, обмениваются пакетами LSU, которые содержат анонсы LSA. Эти анонсы LSA несут информацию о масках подсетей и позволяют OSPF поддерживать маски переменной длины (VLSM).

LSA анонсы помещаются в базу данных состояния канала. Алгоритм Дейкстры (также известный как алгоритм поиска первого кратчайшего пути, SPF) работает с содержимым этой базы данных для создания таблицы маршрутизации OSPF.

Маршрутизаторы должны синхронизировать свои базы данных состояния канала.

Для просмотра содержимого базы данных состояния канала введите команду show ip ospf database. Эта команда показывает каналы и типы соединений, порядковые номера и как давно был получен определенный анонс LSA. Это значение в секундах можно посмотреть в колонке «age».

Алгоритм Дейкстры работает с содержимым базы данных…

R1#show ip ospf database
     OSPF router with ID (1.1.1.1) (Process ID 1)
Link ID     ADV Router     Age     Seq#          Checksum
1.1.1.1     1.1.1.1        1286    0x80000006    0x0057A7
8.8.8.8     8.8.8.8        795     0x8000000C    0x00085E
     Net Link States (Area 0)
Link ID     ADV Router     Age     Seq#          Checksum
10.1.1.5    8.8.8.8        795     0x80000006    0x001CC3

… вычисляет маршруты, и эти маршруты помещаются в таблицу маршрутизации OSPF

R1#show ip route ospf
	6.0.0.0/32 is subnetted, 1 subnets
O       6.6.6.6[110/11] via 10.1.1.5, 02:32:53, Ethernet0
	7.0.0.0/32 is subnetted, 1 subnets
O       7.7.7.7[110/11] via 10.1.1.5, 02:32:53, Ethernet0

Алгоритм SPF на самом деле вычисляет кратчайший путь вдоль дерева, и это дерево используется для создания таблицы маршрутизации. Больше об этом алгоритме задумываться не следует, так как он делает все замечательно и без нашего вмешательства, но у нас есть куча деталей, на которые стоит обратить внимание!

Порядковые номера LSA

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

Если записи нет, то маршрутизатор создает ее и рассылает данный анонс LSA по всем OSPF-интерфейсам, кроме того, на котором было получено это сообщение.

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

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

--Если номер меньше, маршрутизатор проигнорирует обновление и передаст пакет LSU, содержащий данный анонс LSA, обратно отправителю. В этой ситуации, маршрутизатор с более свежей информацией сообщает отправителю: «Информация, которую вы отправляете, устарела. Вот та, что следует рассылать.»

--Если порядковый номер больше, маршрутизатор добавит этот анонс LSA в свою базу данных и отправит подтверждение (LSAcknowledgement). Затем маршрутизатор будет рассылать этот анонс LSA и запустит алгоритм SPF для обновления собственной таблицы маршрутизации.

Когда происходит обмен анонсами LSA?

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

Маршрутизатор OSPF также рассылает суммарные анонсы LSA каждые 30 минут.

До обмена анонсами LSA, маршрутизаторы должны стать соседями, формируя соседство. Для этого у маршрутизаторов должны совпадать номер зоны, hello- и dead-таймеры и нужно проверить является ли зона «stub»-зоной. Если есть аутентификация, то она должна быть сконфигурирована на обеих сторонах канала.

Номер самого процесса OSPF локально значим и не влияет на процесс установления соседства.

Для проверки соседства, введите команду show ip ospf neighbor или менее употребительную show ip ospf interface. Эту последнюю команду часто забывают, но она дает много полезной информации.

Заметьте, что обе команды покажут вам какие отношения соседства существуют, и только show ip ospf neighbor покажет статус загрузки базы данных (FULL, 2WAY, и т.д.)

R3#show ip ospf neighbor

Neighbor ID   Pri   State      Dead Time    Address       Interface
1.1.1.1       1     FULL/DR    00:01:52     172.12.123.1  Serial0
1.1.1.1       1     FULL/ -    00:00:32     172.12.13.1   Serial1
4.4.4.4       1     FULL/DR    00:00:32     172.23.23.4   Ethernat0

R3#show ip ospf interface serial0
Serial0 is up, line protocol is up
	Internet address 172.12.123.3/24, Area0
	Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64
	Transmit Delay is 1 sec, State DROTHER, Priority 0
	Designated Router (ID) 1.1.1.1, Interface Address 172.12.123.1
	No backup designated router on this network
	Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
	  Hello due in 00:00:16
	Index 1/1, flood queue length 0
	Next 0x0(0)/0x0(0)
	Last flood scan length is 1, maximum is 3
	Last flood scan time is 0 msec, maximum is 4 msec
	Neighbor count is 1, Adjacent neighbor count is 1
	  Adjacent with Neighbor 1.1.1.1 (Designated Router)
	  Supress Hello for 0 neighbor(s)

show ip ospf interface даст вам локальный идентификатор маршрутизатора OSPF (RID), его роль в данном сегменте (DR, BDR, DROther), идентификатор (RID) DR или BDR для данного сегмента и многое другое. Это замечательный отправной пункт для устранения проблем.

Роль DR и BDR

Главный недостаток дистанционно-векторных протоколов — медленная конвергенция.

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

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

Как DR рассылают сообщения об изменениях в сети

Когда маршрутизатор в OSPF сегменте с DR и BDR замечает изменения в сети, он не уведомляет всех соседей. Вместо этого он отправляет мультикаст на 224.0.0.6, адрес, который слушают оба маршрутизатора — DR и BDR, чтобы знать о таких изменениях.

Затем DR отправляет мультикаст на 224.0.0.5 — уведомить все не-DR и не-BDR маршрутизаторы в сети. (Маршрутизаторы, которые не являются DR или BDR, называются DROthers, как показано в выводе команды show ip ospf neighbor). DROther-ы отправляют подтверждение (LSAcknowledgment, LSAck) обратно DR о получении обновления.

Два замечания:

--Только DR и BDR слушают 224.0.0.6.

--Только DR отправляет мультикаст на 224.0.0.5 для уведомления DROthers об изменениях в сети. BDR получают их, но не уведомляют другие маршрутизаторы. Прослушивание 224.0.0.6 дает BDR возможность иметь последние изменения в базе данных — и это важно на тот случай, если он станет DR.

Процесс выбора DR/BDR

Почти каждый сегмент сети OSPF содержит DR и BDR. Как всегда имеются исключения, и мы обсудим эти ситуации далее. А сейчас, давайте взглянем поближе на правила выбора DR и BDR.

Согласно следующей диаграмме сети (я мог бы поместить в центр коммутатор вместо обозначения сегмента «Ethernet»; будьте готовы встретить такое в сетевой документации).



Интерфейсы четырех маршрутизаторов находятся в сегменте Ethernet. Один станет DR, другой BDR, остальные — DROthers. Перед тем как увидеть, как маршрутизаторы Cisco распределяют эти роли, давайте взглянем на процесс выбора DR/BDR.

1. Все маршрутизаторы с приоритетом интерфейса 1 или выше могут быть выбранными в качестве DR/BDR. Установка приоритета в 0 лишает маршрутизатор такой возможности.

2. Маршрутизатор с наибольшим приоритетом становится DR.

3. Если они совпадают, то сравниваются значения идентификатора RID. Маршрутизатор с наибольшим — выигрывает.

4. Этот процесс повторяется для выбора нового BDR. Один и тот же маршрутизатор не может быть одновременно DR и BDR.

Позже мы обсудим интересное поведение DROthers в сегменте Ethernet. А сейчас сфокусируемся на процессе выбора DR/BDR с использованием OSPF RID.

Процесс выбора с OSPF RID

Очевидно, OSPF RID играет большую роль в выборе DR и BDR — но как определяется значение RID? По следующим правилам:
OSPF RID маршрутизатора будет наибольший IP адрес, назначенный loopback-интерфейсу, безотносительно был ли этот интерфейс включен в процесс OSPF. Он не анонсируется автоматически OSPF.

Если нет петлевых (loopback) интерфейсов, OSPF RID маршрутизатора будет наибольшее значение IP адреса, назначенного физическому интерфейсу, безотносительно включен он в OSPF ли нет.

Эти правила могут быть переписаны установкой OSPF RID вручную командой router-id, но на маршрутизаторе должен быть перезапущен процесс OSPF (cleared).

Кажется немного странным, что петлевые интерфейсы, не участвующие в OSPF, определяют RID, не так ли?
Давайте посмотрим на все в действии. R1 и R5 сформировали соседство в подсети 10.1.1.0/24. У R5 есть несколько петлевых интерфейсов, но анонсируются через OSPF только два:

hostname R5
!
interface Loopback6
 ip address 6.6.6.6 255.255.255.255
!
interface Loopback7
 ip address 7.7.7.7 255.255.255.255
!
interface Loopback8
 ip address 8.8.8.8 255.255.255.255
!
interface Ethernet0
 ip address 10.1.1.5 255.255.255.0
!

router ospf 1
 network 6.6.6.6 0.0.0.0 area 0
 network 7.7.7.7 0.0.0.0 area 0
 network 10.1.1.0 0.0.0.255 area 0

Зная правила определения OSPF RID, какой OSPF RID покажет R1 для R5? Посмотрите на конфигурацию и выясните.

Если вы сказали 8.8.8.8, то вы правы. Чтобы увидеть OSPF RID соседа надо ввести show ip ospf neighbor:

R1#show ip ospf neighbor
Neighbor ID   Pri   State      Dead Time    Address       Interface
8.8.8.8       1     FULL/DR    00:00:37     10.1.1.5      Ethernet0

Значение, указанное под Neighbor ID это RID соседа.

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

RouterA: Loopback 1.1.1.1, ethernet0 172.1.1.1
RouterB: Loopback 2.2.2.2, ethernet0 172.1.1.2
RouterC: No loopback, ethernet0 172.1.1.3
RouterD: No loopback, ethernet0 172.1.1.4

RID будут такими:

RouterA: 1.1.1.1
RouterB: 2.2.2.2
RouterC: 172.1.1.3
RouterD: 172.1.1.4

Процесс выбора RID всегда отдает предпочтение IP адресам петлевых интерфейсов над физическими.

Суммируя сказанное, мы имеем три способа влияния на значение RID:

--Изменение приоритета OSPF с помощью команды ip ospf priority

--Установка RID вручную при помощи router-id

--Установка RID путем конфигурирования петлевого интерфейса

Ни один из этих способов не является «ошибочным» или «правильным» — так что знайте все три, и знайте, что нужно перезапускать процессы OSPF для применения изменений.

Что случится, если DR отключится, а затем включится?

Если все четыре маршрутизатора включились одновременно, мы ожидаем, что маршрутизатор D будет DR и маршрутизатор C — BDR. Но что, если маршрутизатор D отключится, а потом включится?

При отсутствии маршрутизатора D, маршрутизатор C становится DR. Маршрутизатор B будет BDR. А затем маршрутизатор D включается, но маршрутизаторы C и B сохраняют свои роли.

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

Давайте рассмотрим пример с тремя маршрутизаторами в сегменте Ethernet. Приоритет маршрутизатора A — 100, B — 50, C — 10. Маршрутизатор A выбран DR, B — BDR.



Все хорошо, пока не выключается маршрутизатор A. Маршрутизаторы B и C становятся соответственно DR и BDR.



Включение маршрутизатора A — не причина перевыбирать DR/BDR, даже если приоритет маршрутизатора A выше, чем у DR и BDR. При включении маршрутизатор A становится DROther.



Чтобы маршрутизатор A стал вновь DR, оба текущих DR и BDR должны отключиться! Что произойдет, когда отключится маршрутизатор B?



Маршрутизатор C становится DR, маршрутизатор A — BDR. При включении маршрутизатора B он будет DROther.



Для окончательной установки в качестве DR маршрутизатора A отключаем маршрутизатор C. Теперь маршрутизатор A из BDR станет DR, а маршрутизатор B — BDR.



При включении маршрутизатора C он станет DROther, и мы получим прежнюю схему сети!

---

* Не рискнула выносить в заголовок, но все таки пусть будет PS:
Так как цитата взята из книги, опубликованной фондом «Династия», то, вспоминая призыв progchip666, пишу здесь — «Ликвидации фонда „Династия“ посвящается».

---

UPD: опрос обновила, спасибо за подсказку.
UPD2: github.