Pull to refresh

Comments 22

Очень интересует вопрос, есть ли MPLS, но не в коммутаторах, а просто в обычных дистрибутивах Linux? Не хочется только из-за MPLS покупать коммутатор.
Посмотрите в сторону пакета Quagga.
Хм. Судя по википедии там нет MPLS.
Посмотрите модуль ldpd в составе Quagga.
Ага, на втором размер L2 header — variable.
А на третьем, HW MTU включает L2 header, о чем в тексте и написано. Но блин. Тяжело это как-то воспринимается. Игра «найди три отличия».
В целом, суть статьи как раз в фокусе на мелочах. Документации, где дано одно определение MTU, а потом используется несколько разных команд, без особых разъяснений, полно и на сайте cisco. Поэтому, рисунки может и несколько избыточны, но позволяют наглядно увидеть ту небольшую разницу между рассматриваемыми понятиями. Дьявол кроется в деталях.
Вероятно, надо на картинках разницу как-то выделить, чтобы заметнее было.
Вот еще если кому интересно из первоисточника.
MTU Behavior on IOS XR and IOS Routers

Эта особенность может привезти к проблемам при установке OSPF neighborship между платформами под управлением IOS(XE) и IOS XR (OSPF требует совпадения MTU в Hello пакетах).

Вообще-то не должно это приводить к проблеме. По-умолчанию на XR уже стоит 1514 для ethernet интерфейсов.
На дефолтах не должно, вы правы. Но, если вы не знаете разницы между XR и IOS, и меняли значение с дефолтного, к примеру на MPLS линке, выставив одинаковые с обоих сторон, согласно требований OSPF, то, как нам подсказывают supportforums.cisco.com, проблемы появляются.
Соответственно, когда на интерфейс попадает пакет, превосходящий установленное IP MTU, пакет либо подвергается дефрагментации,

Я думаю, он подвергается фрагментации.
UFO landed and left these words here
> Давайте пробежимся с MTU по уровням OSI
а давайте не будем :-)
существующие сети реализованы вне модели OSI
Однако это справедливо для IOS и IOS XE, но для IOS XR

операционные системы (в частности Windows), когда вы задаёте размер пакета команде ping воспринимают ето значение как чистый paiload

Эх, где ж вы были пару недель назад:(
Решали проблему связи между парой серверов на двух площадках, и собрали все указанные грабли. Связь между серверами вроде как есть (тот же ssh работает, пинг пингует), а как только начинаем что-то копировать — то копирует, то нет. В результате оказалось, что:
— Nexus и ASA параметр MTU воспринимают по-разному — кто-то учитывает весь конверт, кто-то — игнорирует его часть.
— Серверы (AIX) под параметром MTU подразумевают только полезную нагрузку (payload), и игнорируют конверт.

Самое смешное, что инженеров подвела привычка. Настраивали MTU как обычно, но не учли, что при использовании OTV появляется еще один заголовок. Соответственно, пакет становился толще и не всегда «пролазил» через сеть. Когда снизили MTU на размер дополнительного заголовка — все заработало без проблем.
Спасибо за статью, очень интересно. Вы написали, что при слишком большом MSS (относительно MTU) на транзитом узле возможен дроп пакетов, поэтому вопрос: почему?

Например, такая ситуация: промежуточный маршрутизатор, получая через интерфейс с MTU 8000 пакет размером в 7000 байт, который является ответом в рамках TCP-сессии с анонсированным MSS 7500, должен отправить его через интерфейс с MTU 1500. Не должен ли он этот пакет просто фрагментировать (на уровне IP) и отправить дальше фрагменты?

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

Был у меня случай — на промежуточном пролёте РРЛ, пакеты больше 1518 байт дропались безо всякой фрагментации (пакеты без df-bit!). Это неприятно, но решаемо, как вы отметили, за счёт выставления меньшего mtu на ближайших к пролёту маршрутизаторах, которые будут исправно фрагментировать пакеты. Но вспомним о том, что пакеты, требующие фрагментации, становятся process switched, и вся нагрузка по их коммутации ложится на CPU маршрутизатора, что, в свою очередь, может привести к печальным последствиям. Выставление же размеров MSS позволяет нам избежать таких ситуация, предупреждая возникновение необходимости фрагментации пакетов.
Товарищи, а что можете сказать по такой теме. CentOS 7, PPTPD 2.4.5 со стандартным конфигом. Цепляюсь к демону Микротиком, туннель поднят и активен, и все в целом работает отлично, но с некоторыми сайтами нет коннекта. Методом тыка, потратив целый день, нашел проблему — нужно MRU повысить на 4 единицы или более, тогда появляется коннект с «проблемными» сайтами. Сами по себе значения MTU и MRU не критичны, можно ставить все что угодно в диапазоне 1300-1492, но главное, чтобы выполнялось правило: MRU = MTU + 4 (или более). Куда бы копнуть по это теме?
Only those users with full accounts are able to leave comments. Log in, please.