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

Пит сказал :

Я не могу придумать ситуацию, когда тебе это понадобится. Я просто хотел узнать, какова логика, которая делает это явной проверкой в ​​этих протоколах маршрутизации.

Короткий ответ

Протоколы маршрутизации являются одними из самых фундаментальных строительных блоков в Интернете; нам нужно, чтобы они были очень надежными в каждом возможном случае. Бесполезно устанавливать смежность OSPF или EIGRP на несовпадающем MTU.

Протоколы маршрутизации должны удалять любые возможные несовпадающие значения MTU с пути пересылки маршрутизатора.

Длинный ответ

Я могу вспомнить три возможных ситуации, когда вы найдете несоответствующие MTU IGP ...

1. Непреднамеренное несоответствие MTU на уровне 2 (например, если кто-то случайно несовместил MTU на последовательной линии или у разных поставщиков были разные MTU по умолчанию на одном носителе)
2. Соответствующие MTU уровня 2, но в реализации маршрутизатора есть ошибка, которая неправильно рассчитывает требуемый интерфейс IP MTU
3. Преднамеренное несоответствие MTU

MTU IP напрямую связаны с MTU уровня 2 (по крайней мере, для случая 1, выше). Независимо от того, что мы делаем, мы всегда находимся во власти устранения проблем из-за непреднамеренных несовпадений MTU уровня 2, так как отсутствует механизм обнаружения MTU уровня 2 (в отличие от IP, который имеет сообщения об ошибках ICMP).

Это означает, что мы должны сделать все возможное, чтобы избежать несоответствий MTU уровня 2, даже если описанные выше случаи 2 и 3 являются жертвами смягчения проблем для случая 1. Случай 1 имеет колоссальные последствия, если мы его не решим; т. е. скрытие всего трафика только потому, что мы допустили несовпадающие MTU.

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

Следовательно, EIGRP и OSPF требуют действительных смежных связей Уровня 2 ^{Примечание 1} (включая MTU).

Каковы могут быть последствия (не могли бы быть) без соответствующего MTU?

Цитирую Джона Мой (автора OSPF) в RFC 2329: страница 4 :

• Проблемы со всей переадресацией IP
• Проблемы OSPF

Также цитируя его из списка рассылки OSPF :

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

Одной из наиболее важных функций протокола маршрутизации является создание корректной таблицы FIB / CEF / forwarding. Эта таблица отображает информацию, полученную с помощью протоколов маршрутизации, на информацию о перезаписи layer2 . Эти отношения уровня 2 на том же физическом канале - это то, что 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.