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

Піт сказав :

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

Коротка відповідь

Протоколи маршрутизації - одні з найбільш фундаментальних складових в Інтернеті; нам потрібно, щоб вони були дуже надійними у кожному можливому випадку. Це не приносить користі виховувати сумісність OSPF або EIGRP на невідповідній MTU.

Протоколи маршрутизації повинні видаляти всі потенційні невідповідні MTU з шляху переадресації маршрутизатора.

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

Я можу придумати три можливі ситуації, коли ви знайдете невідповідні MTU MTU ...

1. Ненавмисне невідповідність MTU на Layer2 (наприклад, якщо хтось випадково невідповідний MTU на послідовній лінії або різні постачальники мали різні MTU за замовчуванням на одному носії)
2. Відповідність MTU Layer2, але впровадження маршрутизатора має помилку, яка неправильно обчислює необхідний інтерфейс IP MTU
3. Навмисна невідповідність MTU

IP MTU безпосередньо пов’язані з MTU Layer2 (принаймні для випадку 1 вище). Незалежно від того, що ми робимо, ми завжди маємо на меті усунути проблеми від ненавмисних невідповідностей LUer2 MTU, оскільки не існує механізму виявлення MTU Layer2 (на відміну від IP, який має повідомлення про помилки ICMP).

Це означає, що ми повинні зробити все можливе, щоб уникнути невідповідностей рівня МТУ Layer2, навіть якщо випадки 2 та 3 вище є жертвами пом'якшення проблем у справі № 1. Справа 1 має колосальні наслідки, якщо ми не вирішимо її; тобто чорний завив весь трафік лише тому, що ми дозволяли невідповідні MTU.

Ми завжди обмежені найменш поширеним знаменником за посиланням. Кадри, що перевищують MTU інтерфейсу прийому, мовчки відкидаються, і маршрутизатор не може знати, чи було навмисно невідповідним MTU чи це сталося випадково.

Отже, EIGRP та OSPF потребують ^{Примітки 1} придатних для рівня L2 (включаючи MTU).

Яким був би (міг би) бути наслідком без відповідності MTU?

Цитуючи Джона Моя (автора OSPF) в RFC 2329 Сторінка 4 :

• Проблеми з усіма переадресаціями IP
• Проблеми з OSPF

Також цитуючи його з списку розсилки OSPF :

^{Примітка 1.} деякі люди неправильно розуміють значення суміжності як строго концепцію протоколу IP маршрутизації. Це твердження упускає реальність, що всі (включаючи IP) вимагають відповідних MTU рівнів2, щоб домени Layer2 працювали належним чином.

Однією з найважливіших функцій протоколу маршрутизації є побудова дійсної таблиці FIB / CEF / пересилання. Ця таблиця відображає інформацію, отриману за допомогою протоколів маршрутизації, для переписування інформації про layer2 . Ці стосунки Layer2 на тій же фізичній ланці - це те, що Cisco також називає суміжними.

Відповідно до OSPF RFC 2328 (10.6):

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

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

Більше від OSPF RFC:

4.3.  Routing protocol packets

    The OSPF protocol runs directly over IP, using IP protocol 89.
    OSPF does not provide any explicit fragmentation/reassembly
    support.  When fragmentation is necessary, IP
    fragmentation/reassembly is used.  OSPF protocol packets have
    been designed so that large protocol packets can generally be
    split into several smaller protocol packets.  This practice is
    recommended; IP fragmentation should be avoided whenever
    possible.