OSPF DR і BDR: вибір належить інтерфейсу

Ролі OSPF прив’язані до інтерфейсів, а не до корпусу. Той самий пристрій може бути призначеним маршрутизатором у своєму сегменті LAN і нічим особливим у тунелі, і ці два факти не суперечать одне одному. Читання ролі з неправильного інтерфейсу — найчастіша причина, чому концентратор виглядає налаштованим неправильно, хоча працює саме так, як задумано.

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

Один вибір на сегмент

RFC 2328 обирає призначений маршрутизатор і резервний призначений маршрутизатор для кожної мережі broadcast або NBMA, а не для маршрутизатора і не для області. Кожен інтерфейс, що бере участь у такій мережі, проводить власний вибір зі своїм пріоритетом і своїм набором сусідів. Корпус із трьома такими інтерфейсами може одночасно нести три різні ролі, тому твердження, що концентратор — це DR, є неповним, доки не названо сегмент. Читайте роль із виводу сусідів саме цього інтерфейсу.

Два інтерфейси в одній області — це все ще два вибори. Приналежність до області їх не об’єднує.

Що робить резерв, поки чекає

Резервний призначений маршрутизатор повністю суміжний із маршрутизаторами свого сегмента і тримає свою базу даних синхронізованою, щоб перейняти роль без утворення нового суміжного відношення. Чого він не робить у ролі резерву — не створює network-LSA цієї мережі, бо вона належить призначеному маршрутизатору. Його роль у затопленні на деяких кроках вужча, ніж у призначеного маршрутизатора, що не те саме, що мовчання чи бездіяльність. Ставлення до резерву як до маршрутизатора, який нічого не робить до підвищення, породжує дуже впевнені й дуже хибні пояснення.

Корисне питання не в тому, від чого резерв утримується, а в тому, чи може сегмент доставити пакети OSPF, яких потребує модель. Якщо учасник не може обмінюватися ними з іншими, результат вибору — симптом доступності, а не причина.

Яку модель тунель насправді використовує

Мережі broadcast і NBMA обирають; мережі point-to-point і point-to-multipoint — ні, бо спільного сегмента для вибору немає. У накладенні hub-and-spoke чинна модель залежить від того, як налаштовано інтерфейс тунелю, тому прочитайте його перш ніж тлумачити будь-яку роль. Тунель, що поводиться як широкомовний сегмент, і тунель, що поводиться як набір з’єднань point-to-point, дають зовсім різну поведінку сусідів.

Якщо проєкт хоче, щоб концентратор ніс призначену роль, модель і доступність мають підтримувати це разом. Концентратор, який не може обмінюватися потрібними пакетами з кожним учасником, не стане корисним призначеним маршрутизатором лише тому, що його пріоритет високий. Спершу перевірте стани сусідів і базову доставку, потім вирішіть, чи роль помилкова, чи просто несподівана.

Придатність — за інтерфейсом, а пріоритет не автоматичний

Пріоритет задається для інтерфейсу, і нульовий пріоритет виключає цей інтерфейс з обох виборів. Серед придатних учасників переможця визначає пріоритет, а потім ID маршрутизатора, але новоприбулий маршрутизатор із вищим пріоритетом не витісняє наявний призначений маршрутизатор. Ця відсутність пріоритету навмисна, і вона дивує тих, хто очікує, що найвищий пріоритет переможе негайно. Якщо певний маршрутизатор має нести роль, плануйте порядок подій, а не припускайте, що зміна конфігурації подіє сама.

Виключення кожного spoke без надання іншого придатного учасника також означає, що резерву може не бути взагалі.

Порівняйте обидва пояснення чесно: роль, прочитана з неправильного сегмента, або сегмент, учасники якого не досягають одне одного. Перше — питання проєктування, друге — питання доставки, і лише одне з них виправляється редагуванням пріоритету.