0,0
рейтинг
19 июня 2014 в 14:46

Администрирование → Maximum Transmission Unit (MTU). Мифы и рифы

Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).

image
Рис. 1

Давайте пробежимся с MTU по уровням OSI:

Layer 2.


Ethernet MTU является частным случаем Hardware MTU. Определение Hardware MTU вытекает из общего определения:
Hardware MTU — это максимальный размер пакета, который может быть передан интерфейсом за одну итерацию (по крайней мере значение указано в спецификациях устройства – по факту некоторые чипсеты поддерживают передачу больших размеров пакетов, чем заявлено). Поэтому если взглянуть на рисунок 1 в отрыве от Ethernet, то получим следующее:
image
Рис. 2

Замечание: Однако и тут не обойтись без оговорки. Как вы видите, HW MTU (Ethernet MTU в частности) не включает заголовок L2 в себя. Однако это справедливо для IOS и IOS XE, но для IOS XR и JunOS заголовок L2 включен в размер HW MTU – Рис. 3. Эта особенность может привезти к проблемам при установке OSPF neighborship между платформами под управлением IOS(XE) и IOS XR (OSPF требует совпадения MTU в Hello пакетах). Поэтому, при конфигурации MTU для Ethernet интерфейсов, на стороне IOS XR MTU должно быть на 14 байт больше (12 байт src mac+dst mac и 2 байт EtherType). К примеру, MTU в 1500 в Cisco IOS эквивалентно MTU в 1514 для IOS XR.

image
Рис. 3

Конфигурация и проверка.

Для того что бы изменить MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:
R01(config)#interface gigabitEthernet 5/1 
R01(config-if)#mtu 1532
R01(config-if)#exit

Проверяем:
R01#show interfaces gigabitEthernet 5/1
GigabitEthernet5/1 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 0008.e3ff.fde0 (bia 0008.e3ff.fde0)
  Description: -- --
  MTU 1532 bytes, BW 1000000 Kbit, DLY 10 usec, 
     reliability 255/255, txload 82/255, rxload 20/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is LH
..... OUTPUT OMITTED

И
R01#show run interface gigabitEthernet 5/1
interface GigabitEthernet 5/1
 description -- --
 no switchport
 mtu 1532
 ip address 192.168.1.1 255.255.255.0
end


Layer3.


IP MTU определяет максимальный размер пакета с IP заголовком, который может быть передан на данном интерфейсе не прибегая к фрагментации. Зависимость между IP MTU и HW MTU описывается следующей формулой:
IP MTU ≤ HW MTU
Соответственно, когда на интерфейс попадает пакет, превосходящий установленное IP MTU, пакет либо подвергается фрагментации, либо, в случае установленного флага DF (DO NOT Fragment) в IP заголовке, дискардится, а устройство может сгенерировать ICMP сообщение Fragmentation Needed, используемое в механизме path MTU discovery (о нём позже), и отправить его назад отправителю исходного пакета.

Конфигурация и проверка.

Для изменения IP MTU на маршрутизаторах под управлением Cisco IOS используется команда интерфейс уровня:
R01(config)#interface gigabitEthernet 5/1 
R01(config-if)#ip mtu 1532
R01(config-if)#exit

Проверяем:
show interfaces gigabitEthernet 5/1
  GigabitEthernet 5/1is up, line protocol is up
  Internet address is 192.168.1.1/24
  Broadcast address is 255.255.255.255
  Address determined by non-volatile memory
  MTU is 1532 bytes
  Helper address is not set
  Directed broadcast forwarding is disabled
  Multicast reserved groups joined: 224.0.0.5 224.0.0.2
  Outgoing access list is not set
  Inbound  access list is not set
..... OUTPUT OMITTED

И
R01#show run interface gigabitEthernet 5/1
interface GigabitEthernet 5/1
 description -- --
 no switchport
 mtu 1532
 ip address 192.168.1.1 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
end


Вот те раз. Команда ip mtu не видна в show run. Да тут есть интересный нюанс – если ip mtu совпадает с hw mtu, то в выводе show run будет отображаться только hw mtu. Если значения разные то отображаются оба.

Layer 4.


TCP Maximum Segment Size (MSS) определяет максимальный размер TCP сегмента (без TCP заголовка!), который может быть использован (отправлен/принят) в ходе TCP сессии. Анонс (именно анонс, не хендшейк) размеров TCP MSS происходит во время установки TCP сессии – принимающая сторона анонсирует стороне отправляющей какой размер TCP сегмент она может принять. Соответственно размер TCP MSS может различаться в рамках одной TCP сессии в зависимости от направления.

image
Рис. 4

Сторона, производящая анонс, высчитывает значение TCP MSS для себя по следующей формуле:
TCM MSS = (IP MTU – [IPHDR + TCPHDR])

Конфигурация.

Тут у нас возможны два сценария – маршрутизатор является транзитным или участником TCP сессии.
1) Транзитное устройство:
Для предотвращения дропа пакетов промежуточным устройством в случае наличия линка с малым MTU, маршрутизатор будет прослушивать TCP SYN пакеты и подменять значения MSS анонсируемые конечным устройством. Что приведет к отправке пакетов меньшей величины конечным устройством и вуаля – проблема с дропами на линке с малым MTU упреждена.
R01(config)#interface gigabitEthernet 5/1 
R01(config-if)#ip tcp adjust-mss?
<500-1460>  Maximum segment size in bytes

2) Терминирующее устройство:
Здесь всё просто – маршрутизатор является участником TCP сессии и мы можем установить принудительно, размер MSS который он будет анонсировать.
R01(config)#ip tcp mss?
<0-10000>  MSS


Кажется всё? Нет, не всё. Вспоминаем про MPLS. Вспоминаем… Закончили вспоминать, переходим к рассмотрению.

Layer 2,5. MPLS.



image
Рис. 5

MPLS MTU определяет максимальный размер маркированного (кто знает как лучше переводиться Labeled прошу подсказать в комментах) IP пакета. В случае, если размер маркированного пакета превышает MPLS MTU, то пакет либо фрагментируется, либо, при наличии установленного в IP заголовка флага с DF bit, дропается (пока логика как и при превышении IP MTU), с возможной отправкой ICMP сообщения Fragmentation Needed.

Замечание: Вот тут дела обстоят немного по другому, по сравнению c IP MTU. В MPLS сети промежуточный узел может и не иметь маршрута к отправителю пакета, поэтому вместо того что бы слать ICMP сообщение отправителю напрямую, оно инкапсулируется с тем же стеком меток (label stack), что и исходный пакет, и отправляется по его же пути следования. Достигая Egress LSR (конечного MPLS маршрутизатора для данного LSP – за ним уже IP сеть без меток), который знает ip маршруты к узлу отправителя, ICMP сообщение Fragmentation Needed «разворачивается» им, инкапсулируется необходимыми заголовками и отправляется назад в MPLS сеть к отправителю оригинального пакета. Поведение аналогично с TTL Expired, да и в целом скорее относиться к теме MPLS, а не MTU. Поэтому кто не знаком с процессом — www.google.kg/?gws_rd=ssl#q=mpls+ttl+expired

Что здесь ещё интересного? MPLS MTU может быть больше HW MTU (поэтому на Рис. 3 HW MTU частично обозначено пунктиром). При этом IOS выдаст варнинг, но в большинстве случаев будет работать (зависит от чипсета интерфейса) и успешно пропускать по крайней мере baby-giant фреймы. А в иной раз можно получить дроп пакетов, повреждение данных, и сто лет без урожая.

Конфигурация и проверка.

R01(config)#interface gigabitEthernet 5/1 
R01(config-if)#mpls mtu 1540
R01(config-if)#exit

Проверяем:
R01#show mpls interfaces gigabitEthernet 5/1 detail 
Interface gigabitEthernet 5/1:
        IP labeling enabled (ldp):
          Interface config
        LSP Tunnel labeling not enabled
        BGP labeling not enabled
        MPLS operational
        MTU = 1540

Замечание: MPLS MTU отображается в running конфиге, также как и IP MTU — только в случае, если значение отличается от HW MTU. Но, в отличие от IP MTU, любое изменение HW MTU меняет значение MPLS MTU до значения HW MTU (IP MTU это действие не меняет).

MTU на коммутаторах Cisco.


Коммутаторы не поддерживают выставление MTU на каждом интерфейсе в отдельности (речь о switchport`ах и Vlan интерфейсах, для multilayer коммутаторов с routed портами применимы настройки аналогичные маршрутизаторам).Изменить текущие настройки MTU для портов коммутатора можно 3-мя спосабами, применимыми в зависимости от типа порта:
  • SW01(config)#system mtu 1600 — изменение L2 MTU на FastEthernet портах
  • SW01(config)#system mtu jumbo 1600 — изменение L2 MTU на GigabitEthernet и Ten GigabitEthernet портах
  • SW01(config)#system mtu routing 1600 — изменение L3 MTU на маршрутизируемых интерфейсах

Проверяем:
SW01#show system mtu

System MTU size is 1600 bytes
System Jumbo MTU size is 1600 bytes
Routing MTU size is 1600 bytes


На заметку администратору.


Так как основным методом проверки MTU и по сей день является команда PING, с выставленным df-bit и рамером пакета, приведу в заключение пару полезных триков:
1) Для того, что бы найти минимальный MTU (забавное сочетание) на сети можно использовать расширенную команду ping, причём как c конечных станций/серверов так и с оборудования Cisco. Пропингуем с маршрутизатора R01 маршрутизатор R02 с выставленным df-bit, c начальным размером пакета в 1000 байт, конечным 1500 байт, и шагом 100 байт. Кол-во повторений 2.
R01#ping
Protocol [ip]:
Target IP address: 192.168.12.2
Repeat count [5]: 2
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.12.1
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1000
Sweep max size [18024]: 1500
Sweep interval [1]: 100
Type escape sequence to abort.
Sending 12, [1000..1500]-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
Packet sent with a source address of 192.168.12.1
Packet sent with the DF bit set
!!!!..!!!!..
Success rate is 66 percent (8/12), round-trip min/avg/max = 4/24/56 ms


Как видите, проходит только 6 ICMP пакетов размером 1000, 1100, 1200, 1300 байт
Начиная с 1400 байт и выше пакеты не проходят. Следовательно, минимальное MTU между двумя точками — 1300 и 1400, что можно уточнить ещё за несколько циклов, ужимая диапазон и умешьшая шаг.


2) Частая проблема возникающая при взаимодействии сетевых и системных администраторов — с конечного устройства проходят пакеты одного размера, с ближнего к нему сетевого устройства большего размера. Причина лежит в том, что операционные системы (в частности Windows), когда вы задаёте размер пакета команде ping, воспринимают это значение как чистый paiload — без заголовков ICMP и IP, т.е. при указании ping 192.168.1.2 -l 100 система будет генерировать пакеты величиной 128 байт, а не 100 (8 байт ICMP заголовок и 20 байт IP). При указании же размера ICMP пакета на сетевом оборудовании Cisco указываемый вами размер включает уже оба заголовка. Поэтому на дефолтном Ethernet линке пинги с Windows OS (к примеру) покажут 1472 байт максимальный размер пакета проходящий без фрагментации, а Cisco 1500 байт. JunOS, кстати ведет себя также как и операционные системы (не включает заголовки)


На этом всё. Есть ещё в закромах старый драфт статьи по размерам фреймов и их эволюции, где описаны понятия Jumbo Frame, Baby-Giant Frame, встречающиеся в этой статье. Если посчитаете нужным, могу доработать и выложить и её.
Алексей Стыценко @mongolio
карма
37,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (20)

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

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

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

    Я думаю, он подвергается фрагментации.
    • 0
      Спасибо, поправил.
  • 0
    Хочу обратить внимание новичков в JunOS — в то время, как в большинстве сетевых девайсов и ОС MTU имеет дефолтное значание (обычно 1500 байт для IP MTU), в Juniper MX MTU на IRB интерфейсах динамически устанавливается в зависимости от наименьшего L2 MTU физических интерфейсов, входящих в соответствующий bridge-domain. В случае Ethernet от L2 MTU отнимается 14 байт. Так что не стоит полагаться на дефолты, лучше устанавливать MTU вручную во избежание сюрпризов с протоколами маршрутизации.

    Что касается протоколов маршрутизации, то проблемы из-за MTU могут быть не только у OSPF с его жёстким требованием на одинаковые MTU (что можно отключить, конечно же). IP MTU влияет также на максимальный размер пакетов, генерируемых маршрутизатором с этого интерфейса (что очевидно из определения MTU). И если в транзите MTU меньше и не поддерживается фрагментация (или пакеты идут с DF битом), то в результате могут получиться странные проблемы с флапанием сессий или ситуация, когда соседство устанавливается (т.к. Hello, keepalive и подобные пакеты маленькие), а апдейты не проходят (там уже большие пакеты с инфо о префиксах). В случае, если вы не контролируете весь путь (используете какой-нибудь multihop-eBGP), и не хотите менять MTU на роутере, поможет ограничение TCP MSS для локально генерируемых пакетов (в случае BGP).
  • –3
    > Давайте пробежимся с MTU по уровням OSI
    а давайте не будем :-)
    существующие сети реализованы вне модели OSI
  • +2
    Однако это справедливо для IOS и IOS XE, но для IOS XR

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

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

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

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

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

      Был у меня случай — на промежуточном пролёте РРЛ, пакеты больше 1518 байт дропались безо всякой фрагментации (пакеты без df-bit!). Это неприятно, но решаемо, как вы отметили, за счёт выставления меньшего mtu на ближайших к пролёту маршрутизаторах, которые будут исправно фрагментировать пакеты. Но вспомним о том, что пакеты, требующие фрагментации, становятся process switched, и вся нагрузка по их коммутации ложится на CPU маршрутизатора, что, в свою очередь, может привести к печальным последствиям. Выставление же размеров MSS позволяет нам избежать таких ситуация, предупреждая возникновение необходимости фрагментации пакетов.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.