Максимальна метрика OSPF: стримування транзиту через філію без її видалення

Два офіси з’єднані через філію, яка має нести власний трафік і дуже мало іншого. Філії потрібні маршрути до обох майданчиків, і жоден майданчик не повинен віддавати їй перевагу як шляху між ними. Видалення філії з топології вирішило б проблему транзиту і порушило б вимогу, бо філія досі має досягати обох майданчиків, а обидва майданчики досі мають досягати філії.

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

Почніть зі шляху, якого хочете уникнути

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

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

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

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

Що оголошує максимальна метрика

RFC 6987 описує маршрутизатор, що оголошує свої не-stub зв’язки з максимальною метрикою зв’язку, визначеною як 0xffff. Маршрутизатор досі описує себе і свої зв’язки; він просто оцінює їх за верхньою межею діапазону, тож кожен інший маршрутизатор обчислює шлях через нього як дорогий.

Це зміна router-LSA, а не видалення топології. Різниця важлива: очищення router-LSA відкликає саму інформацію про топологію, що може відкликати й відношення, потрібні для досягнення маршрутизатора та префіксів за ним. Збереження оголошення і підвищення його ціни зберігає ці відношення. У цьому вся різниця між цим прийомом і видаленням.

Механізм RFC 6987 також не має нічого спільного з типами областей чи з виборами призначеного маршрутизатора. Stub-область блокує категорію оголошень стану зв’язку на межі області, а stub-маршрутизатор оцінює власні зв’язки. Схожі слова, незв’язана механіка.

Чому доступність переживає, а транзит ні

В інших маршрутизаторів досі є маршрут до підключених префіксів філії, бо філія їх досі оголошує, а зв’язки досі існують. Змінюється загальна вартість будь-якого шляху, що проходить через філію дорогою кудись інде. Префікси не рухаються; змінюється лише ціна перетину маршрутизатора.

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

Це та поведінка, яку треба перевірити, а не припустити. Подивіться на router-LSA, який створює філія, потім на шлях, який обирає інший маршрутизатор для призначення за філією і для призначення в іншому офісі. Дві відповіді мають різнитися, і якщо не різняться, зміна метрики не доходить до того рішення, про яке ви думаєте.

Проблема останнього шляху

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

Чи прийнятний такий відкат — питання політики, на яке треба відповісти до розгортання. Філія на малому висхідному каналі, що раптом несе міжофісний трафік, може бути гіршою за аварію і може бути саме тим, що вам потрібно під час вікна обслуговування. Обидві відповіді законні; мовчання — ні.

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

Для OSPFv3 RFC обговорює біт R як інший спосіб виключити участь у транзиті. Не припускайте, що він успадковує ту саму поведінку останнього шляху, що й прийом максимальної метрики, і не копіюйте налаштування між двома родинами адрес так, ніби це та сама функція.

Доведіть це в нормальних і відмовних умовах

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

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

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

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