3 підмережі, 2 області OSPF - чи буде це працювати?

Чи виникнуть якісь проблеми, якщо у мене буде топологія, що включає 3 підмережі та дві області OSPF, де одна підмережа знаходиться в області AREA 0, а інші дві підмережі - в області AREA 1?

Наприклад:

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]

— ЛІКАР
джерело

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

— Майк Пеннінгтон

@Mike Pennington - чи шукаєте ви також заявки мережі OSPF в АБР? Я говорю про конфігурацію без віртуальних посилань btw.

— ДОКТОР

Так, є три різні маршрутизатори: [область 1 мережа, підмережа 1] --- [маршрутизатор №1] --- [мережа 0 області, підмережа 2, кінцевий пристрій №1] --- [маршрутизатор №2] --- [область 0 мережа, підмережа 2, кінцевий пристрій №2] --- [маршрутизатор №3] --- [мережа 1 область, підмережа 3]

— ДОКТОР

Відповіді:

Щодо питання про розщеплення площі 1 на хребет (область 0):

[область 1, підмережа 1] --- [ABR # 1] --- [область 0, підмережа 2] --- [ABR # 2] --- [область 1, підмережа 3]

[область 1, підмережа 1] --- [маршрутизатор №1] --- [область 0, підмережа 2, кінцевий пристрій №1] --- [маршрутизатор №2] --- [область 0, підмережа 2, кінцевий пристрій # 2] --- [Маршрутизатор №3] --- [область 1, підмережа 3]

Коротка відповідь: Проблеми з вашою пропозицією немає ...

Довга відповідь:

Навіть відповідь Петра, яка стверджує, що повторне використання номерів площі - це поганий дизайн, не дає жодних доказів того, що це погана конструкція; якщо вивчити гіперпосилання, якими він користувався, пояснення небажаних наслідків для цієї конструкції немає. Крім того, аргумент про те, що у вас можуть виникнути проблеми з підключенням R1 та R3, стає недостатнім, оскільки посилання R1 до R3 може бути законно налаштована або в області 0, або в області 1, залежно від того, який трафік ви хочете пройти через нього. Труднощі, про які він згадує, є хибною дилемою.

У RFC 2328, розділ 3.7 OSPF явно дозволяє використовувати суперечливі небійні області (які називаються "розділами областей" нижче):

    OSPF does not actively attempt to repair area partitions.  When
    an area becomes partitioned, each component simply becomes a
    separate area.  The backbone then performs routing between the
    new areas.  Some destinations reachable via intra-area routing
    before the partition will now require inter-area routing.
    ...  Also, the backbone itself must not partition.

Таким чином, чи використовуєте ви запропоновану суперечливу область 1 - це лише питання смаку ... деякі люди вважають нелогічним використання конфігурації у вашій діаграмі; ці люди можуть запропонувати вам зберігати номери OSPF разом ... так що вам доведеться змінити [область 1, підмережа 3] на маршрутизаторі №3 на [область 3, підмережа 3]. Інші люди не бачать жодної проблеми з повторним використанням області 1, оскільки номери областей OSPF мають місцеве значення лише для маршрутизатора, що походить з привітання OSPF.

У будь-якому випадку ми повинні визнати, що OSPF є надзвичайно гнучким протоколом; незалежно від вибору тієї чи іншої сторони в цій дискусії.

— Майк Пеннінгтон
джерело

Зрозуміла, що ця конструкція (суперечлива область 1) використовується у виробництві у певних військових мережах. Блок, що розгортається на віддалений сайт, який підключиться до сайту концентратора ABR через DMVPN, отримує маршрутизатор зі стандартною конфігурацією. Максимум, вони змінять одну або дві IP-адреси на маршрутизаторі. Сумнівно, чи це "найкраща практика", але це працює, і неспеціалісти легко розгортаються.

@ user2668 Військова політика високого рівня не сприяє цьому у виробничих мережах. Хоча "спеціальні" організації (зверніть увагу на кролячі вуха) прагнуть робити те, що хочуть, коли хочуть, це, звичайно, не є нормою. Я можу сказати напевно, що існують відділення, які просувають area 0виключно одні проекти OSPF, щоб обмежити складність дизайну.

— Райан Фолі

Це спрацює, але це був би поганий вибір дизайну (IMHO), якщо у вас немає конкретної причини для цього.

Дивіться цю дискусію: Дублікати ідентифікаторів області OSPF

Кращі практики OSPF

Передовий досвід налаштування області OSPF

Оновлення №1 :

Для повноти я висміював цю ситуацію, використовуючи діаманти. Платформою став Cisco 3725s, що працює під керуванням IOS ver 12.4 (15) T13.

R1 (lo0 1.1.1.1, f0 / 0 10.12.0.1) <-> R2 (lo0 2.2.2.2, f0 / 0 10.12.0.2, f0 / 1 10.23.0.2) <-> R3 (lo0 3.3.3.3, f0 / 0 10.23.0.3).

Інтерфейси із зворотним зв'язком R1 та R3 були розміщені в області 1, всі інші інтерфейси - в області 0.

Потім були виконані пінги (наприклад, R3 # ping ip 1.1.1.1 джерело 3.3.3.3) між полями R1 та R3, що підтверджують підключення.

На мою думку, я б все-таки ухилявся від цієї архітектури. Майк робить цілком достовірні моменти (і тестування підтверджує), що це працює. Області OSPF є корисними інструментами для управління поширенням маршруту та зменшенням розміру бази даних маршрутизатора маршрутизатора - але вони також функціонують (як мінімум, для мене), щоб документувати, що я маю намір "цю" частину мережі архітектурно відокремити від "тієї" частина мережі чомусь.

Якщо в майбутньому ви вирішили підключити R1 до R3 і використовуєте ту саму область #, тоді ви змусили себе і зберегли багато проблем із зміною номерів району або з використанням віртуальних посилань. То, можливо, це аргумент на користь використання двох ідентифікаторів області (0 і 1) скрізь - але тоді ви спочатку не мали наміру R1 та R3 мати можливість спілкуватися безпосередньо. знизати плечима

Це питання стилю та особистих уподобань - схоже, немає технічних причин, чому це не повинно працювати, і я ніколи не мав наміру представляти інше.

Оновлення №2

Додавання діаграми з'єднань, що не належать до ассії, - намальовані лінійно та у вигляді трикутника. Що призначено між R1 та R3? Чи має бути область 1 суміжною чи окремою?

введіть тут опис зображення

— Петро
джерело

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

— ДОКТОР

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

— Майк Пеннінгтон

@Mike Pennnington - Немає технічних причин, чому ви не можете використовувати розривні області OSPF, але є багато практичних. Підтримка оточення та усунення несправностей серед інших. Як і коментарі у вашому коді, не потрібно, але це згодом полегшує ваше життя.

— Пітер

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

— Майк Пеннінгтон,

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

— fredpbaker

Добре, що вам потрібно використовувати віртуальні посилання, щоб поговорити з областю 0 через іншу область, яка не є 0, або ви з'єднаєте 2 частини області 0 через ненульову область. Тож віртуальні посилання не застосовуються. У вас може бути непомітна область, якщо її область не 0, але, як натякано вище, не дуже гарна ідея. Якщо говорити, що запропонована топологія працюватиме без віртуальних посилань.

— fredpbaker
джерело