L2 MTU, IP MTU i TCP MSS pod lupą

W trakcie zarówno nauki jak i pracy z sieciami komputerowymi, często przewijają się takie terminy jak MTU czy MSS. Po bliższym przyjrzeniu się tematowi okazuje się, że MTU nie jest dość precyzyjnym określeniem i tak naprawdę mamy do czynienia z L2 MTU oraz z IP MTU. No i do tego dochodzi nam jeszcze MSS… Jak to wszystko się ze sobą wiąże?

Czym jest MSS?

Zgodnie ze standardem TCP, domyślnym rozmiarem wysyłanego segmentu jest 576 bajtów – wraz 40 bajtami nagłówków TCP i IP. Zenkapsulowana zawartość L4 PDU ma zatem 536 bajtów. W trakcie TCP 3-way handshake, segmenty z ustawioną flagą SYN mogą poinformować w opcji TCP, że dany host jest w stanie przyjąć segmenty o większym rozmiarze. Opcja ta to Maximum Segment Size (MSS) i może być ustawiona niezależnie dla każdego przepływu danych (innymi słowy MSS jest rozgłaszane niezależnie w obu kierunkach transmisji i nie musi być takie same). Bardzo często zaobserwowaną wartością MSS będzie 1460 bajtów, co wynika wprost z rozmiaru ramki Ethernet (o czym za chwilę). Dobrze to widać w Wiresharku:

Jednym z problemów, które możemy napotkać w związku z MSS, jest rozgłaszanie przez odbiorcę MSS większego niż maksymalne MTU na ścieżce transmisyjnej – co powoduje fragmentację. Rozwiązaniem tego problemu jest mechanizm PMTU omówiony w dalszej części artykułu.

Czym jest MTU?

Generalnie rzecz biorąc MTU (Maximum Transmission Unit) jest maksymalnym rozmiarem jednostki danych, którą możemy przesłać przez określone medium bez fragmentacji. Duże MTU powoduje, że można wysłać co prawda mniej pakietów (mniejszy jest również narzut związany z nagłówkami), jednakże może powodować również większe zatłoczenie (contention) w sieci, zwłaszcza w wypadku konieczności retransmisji uszkodzonych pakietów. Zmienne MTU jest niepożądane ponieważ powoduje fragmentację pakietów (której chcemy uniknąć za wszelką cenę). Jak się okazuje, możemy wyróżnić dwa rodzaje MTU:

a) L2 MTU

W wypadku Ethernetu (v2) wartość L2 MTU wynosi 1500 bajtów (dla kontrastu FDDI – 4352 bajty). Oznacza to, że zenkapsulowany w ramce ethernetowej pakiet może mieć maksymalny rozmiar 1500 bajtów – w przeciwnym wypadku będziemy musieli dokonywać fragmentacji na poziomie pakietu IP. Jak to wygląda w Wiresharku? Wireshark pokazuje, że otrzymał 1514 bajtów – nie wlicza w to jednak FCS (4 bajty) oraz preambuły (8 bajtów) – zatem rzeczywisty rozmiar ramki to 1526 bajtów. Rozmiar ten może się dodatkowo zwiększyć kiedy stosujemy tagowanie VLANów (dodatkowe 4 bajty) lub tunelowanie Q-in-Q.

Mamy zatem 1526 bajtów, które rozbija się następująco:

1. Ramka:
   • nagłówek i stopka (konia z rzędem temu kto zaproponuje dobre tłumaczenie słowa “trailer“…): 26 bajtów
   • payload (zenkapsulowany pakiet IP): 1500 bajtów <- czyli L2 MTU
2. Pakiet:
   • nagłówek: 20 bajtów
   • payload (zenkapsulowany segment TCP): 1480 bajtów
3. Segment:
   • nagłówek: 20 bajtów
   • payload (dane warstwy aplikacyjnej): 1460 bajtów <- czyli nasz MSS

Niektóre urządzenia mogą wspierać tzw. Jumbo Frames, czyli ramki ethernetowe o rozmiarze przekraczającym 1500 bajtów (teoretycznie zawartość ramki (payload) może wynieść nawet 9000 bajtów). Jumbo Frames mogą być pożądane w przypadku niektórych nowoczesnych aplikacji.

b) IP MTU

IP MTU jest niczym innym jak maksymalnym rozmiarem pakietu IP – z tym, że w tym wypadku wartość IP MTU oznacza rozmiar całego pakietu (nie tylko zenkapsulowany segment, ale również nagłówek IP!). W większości wypadków IP MTU będzie równe L2 MTU. Można by się zastanowić po co w zasadzie dwie wartości skoro wydaje się, że by wystarczyła jedna? Już spieszę z odpowiedzią. W przypadku etykietowania MPLS, każda etykieta zwiększa nam rozmiar payloadu ramki o 4 bajty. Jeśli więc IP MTU byłoby równe L2 MTU to nie bylibyśmy w stanie upakować etykiet. Zatem w takiej sytuacji zazwyczaj się stosownie zwiększa L2 MTU. Aby umożliwić dodawanie dwóch etykiet należałoby zwiększyć L2 MTU do 1508 bajtów – 8 bajtów na dwie etykiety, 1500 bajtów na pakiet (IP MTU), po 20 bajtów na nagłówki IP i TCP i 1460 bajtów payloadu w warstwie transportowej (czyli tyle ile wynosi MSS). Mam nadzieję, że teraz już jest jasne jak to wszystko się ze sobą zazębia 🙂

IPv4 PMTU

PMTU, czyli Path Maximum Transmission Unit to mechanizm wykorzystywany przez hosty, którego celem jest wykrycie najmniejszego MTU na ścieżce między dwoma hostami. Większość hostów wspiera ten mechanizm, a działa on następująco: host w wysyłanym pakiecie IP ustawia flagę DF (Don’t Fragment) – w rezultacie jeśli dany router nie jest w stanie przekazać pakietu (ze względu na zbyt niskie MTU) to odrzuca pakiet i udziela hostowi informacji zwrotnej w postaci ICMP typu 3 z kodem 4 (fragmentation needed but DF bit set). Informacja ta zwiera ponadto skonfigurowane na routerze MTU. Dzięki temu host może dokonać retransmisji odrzuconego pakietu, dostosowując się do MTU. Otrzymywanie komunikatów “MTU exceeded” jest niezbędne do prawidłowego działania PMTU, ważne więc aby ich nie blokować.

Komendy

Najważniejsze komendy związane z MSS i MTU wyglądają w przypadku urządzeń Cisco następująco:

1. MSS:
   • ip tcp mss bytes – ustawia MSS, ale wpływa tylko na ruch do i z routera (management plane)
   • ip tcp adjust-mss bytes – ta komenda wpływa na MSS ruchu tranzytowego, nie jest ona jednak w stanie zwiększyć MSS – jedynie może zmniejszyć MSS w segmencie jeśli ten przekracza ustawioną wartość.
2. L2 MTU:
   • system mtu bytes – zmiana wartości L2 MTU globalnie
   • system mtu jumbo bytes – zmiana wartości L2 MTU dla jumbo frames globalnie
   • mtu bytes – zmiana wartości L2 MTU na poziomie interfejsu
3. IP MTU:
   • ip mtu bytes – zmiana wartości IP MTU na poziomie interfejsu. Nie jest możliwa zmiana globalnie.

Mam nadzieję, że teraz już wszystko jest jasne w kontekście MTU i MSS.

Może coś wymaga doprecyzowania? A może chciałbyś zaproponować temat, na któryś z następnych artykułów?