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. Тому хто не знайомий з процесом — <a href="https://www.google.kg/?gws_rd=ssl#q=mpls+ttl+expired">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. Пропінгуем з R1 R2 з виставленим 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, що зустрічаються в цій статті. Якщо вважаєте за потрібне, можу доопрацювати і викласти і її.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.