Використання затримки для обчислення показників OSPF

Чи можливо налаштувати OSPF на використання затримок у своїх розрахунках вартості / метрики. Ідея полягає в тому, щоб включити маршрутизацію на основі продуктивності, завдяки якій найшвидші та найменш перевантажені посилання в мережі будуть вибиратися динамічно, а не покладатися на поведінку за замовчуванням OSPF, що призводить до того, що посилання в 100 Мбіт / с мають ту саму вартість, що й посилання на 1 Гбіт / с.

Чи можливо налаштувати OSPF на використання затримок у своїх розрахунках вартості / метрики. Ідея полягає в тому, щоб увімкнути маршрутизацію на основі продуктивності, завдяки якій найшвидші та найменш переповнені посилання в мережі будуть вибиратися динамічно, а не покладатися на поведінку за замовчуванням OSPF, що призводить до того, що посилання в 100 Мбіт / с мають таку саму вартість, що й посилання на 1 Гбіт / с.

Коротка відповідь: Ні, не тільки з OSPF

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

Єдиний спосіб для OSPF динамічно розраховувати шляхи на основі затримки / перевантаженості - використовувати MPLS Traffic Engineering з оптимізацією витрат MPLS TE в режимі офлайн на основі ваших критеріїв ; MPLS TE використовує OSPF LSA для передачі інформації про мітки, що перемикаються міткою. Однак MPLS Traffic Engineering є важким молотом, і багато мережевих операцій не можуть впоратися з додатковим робочим процесом, запровадженим для забезпечення або усунення несправностей MPLS TE.

Інша відповідь говорить про те, що не слід коригувати витрати на зв’язок на основі пропускної здатності та використовувати роль вузла для витрат. Я не можу говорити за його мережу, але це керівництво у багатьох випадках непотрібне, оскільки шлях із найменшими витратами у добре розробленій топології автоматично проходить через ядро ​​мережі. Я б не намагався налаштувати неефективну топологію із витратами на зв’язок ... просто зробити потоки трафіку через ядро ​​природним чином і переконатися, що OSPF бачить 1GE кращим шляхом, ніж посилання FastEthernet. Це, природно, станеться, якщо ви добре розкладете топологію та використовуєте автоматичну контрольну смугу пропускання в процесі OSPF. Будьте впевнені, що ви використовуєте це на всіх маршрутизаторах OSPF, щоб вони розуміли вартість зв’язку однаково.

Ви не повинні покладатися на показники / вартість за замовчуванням, не в IGP або STP. Моє одне запитання щодо того, чи була розроблена локальна мережа, - це запитати, яке посилання блокується, якщо інженер не може відповісти, не дивлячись, це твердо свідчить, що мережа не була розроблена

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

Я дуже віддаю перевагу метричному стандарту на основі ролі , де PP, P-PE, PE-PE тощо мають однакові метричні значення, незалежно від пропускної здатності чи затримки. Тобто я знаю, куди я хочу, щоб мій трафік рухався, для мене не важливо, яка затримка або яка ємність, якщо я не маю достатньої потужності, де хочу, щоб трафік протікав, я модернізую посилання.

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

Незалежно від того, як ви розробляєте свій метричний стандарт, він буде повністю статичним і не знає про фактичні умови зв'язку, такі як втрата пакету, затримка, тремтіння, ємність і т.д. ) щоб змінити мережеві умови, потрібно заглянути в RSVP або навіть SDN.

Інший варіант, якщо для використання маршрутизаторів PfR або OER, використовуйте активні зонди або дані netflow для динамічного вибору шляху. Звичайно ж, дуже простим варіантом є жорстке кодування значень витрат OSPF.

Інша думка - ви намагаєтеся кодувати статичну метрику чи хочете динамічну поведінку (зміни затримки із завантаженням трафіку).

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