Informacje o ustawieniach MTU w maszynach i przełączniku

Załóżmy, że mam dwie maszyny i jeden przełącznik.

M1 - Przełącznik - M2.

Ustawienia są następujące:

• M1 ma MTU ustawione na 100
• Przełącznik ma MTU ustawiony na 1000
• M2 ma MTU ustawione na 1000.

Pytania:

1. Kiedy M1 próbuje wysłać pakiet 100 bajtów do M2, nie powinno być problemu, prawda?

2. Kiedy M2 próbuje wysłać pakiet 1000 bajtów do M1, czy jest jakiś problem?

3. M2 może wysłać 1000-bajtowy pakiet do Switcha, ale kiedy Switch próbuje wysłać pakiet do M1, musi podzielić pakiet na 10 małych pakietów. Czy to prawda?

Aktualizacja:

Aby być bardziej realistycznym: M1, Switch i M2 działają w sieci 10G i używamy IPv4.

Ustawienia są następujące:

• M1 ma MTU ustawione na 1500

• Przełącznik ma MTU ustawiony na 9000

• M2 ma MTU ustawione na 9000

Czy to pomaga odpowiedzieć na pytanie?

Nie określiłeś, o jakich technologiach sieciowych mówiłeś, więc założę Ethernet i IP [v4].

Ethernet zawsze określał zakres dopuszczalnych długości ładunku od 46 do 1500 bajtów i wymaga, aby wszystkie urządzenia (hosty i przełączniki) w sieci LAN mogły odbierać ramki z ładunkami 1500-bajtowymi. Z tego powodu Ethernet nie zapewnia mechanizmu fragmentacji ani nie zapewnia mechanizmu komunikacji lub negocjacji MTU (lub, co ważniejsze, M R Us - Maximum Receive Units) między urządzeniami. W rzeczywistości termin „MTU” lub „maksymalna jednostka transmisji” nie występuje nigdzie w specyfikacji IEEE 802.3.

Dodajmy więc do obrazu adres IP. IP ma koncepcję MTU, a większość nowoczesnych stosów IP pozwala ustawić MTU na podstawie interfejsu (i więcej). Ale twoje pytanie, jak powiedziano, nie do końca się sprawdza w kontekście IP, ponieważ IP ma minimalną MTU 576. Więc pozwól mi powtórzyć twoje pytanie, ponieważ „M1 ma MTU 600, a M2 ma MTU 1200 „. Ale co mamy powiedzieć, że MTU ma „Switch”? Cóż, jeśli Switch jest tylko przełącznikiem Ethernet warstwy 2, nie ma koncepcji regulowanego MTU. Aby twoje pytanie zadziałało w kontekście IP, będziemy musieli zmienić ten przełącznik w router. Nazwijmy to „Router” i powiedzmy, że ma dwa interfejsy Ethernet, jeden podłączony do M1, a drugi do M2. Powiedzmy również, że ma MTU 1200 ustawione na obu swoich interfejsach.

1. Gdy M1 wysyła ramkę z 600-bajtowym ładunkiem do M2, nie byłoby problemu.
2. Gdy M2 wysyła ramkę o pojemności 1200 bajtów do M1, nadal nie byłoby problemu. Dlaczego nie? Ponieważ ustawienie MTU M1 niekoniecznie zmieniło jego MRU, a z mojego doświadczenia wynika, że ​​MTU i MRU są osobne, a implementacje nie dają możliwości zmiany MRU. Zatem MRU M1 na tym interfejsie wynosiłby 1500, ponieważ jest to Ethernet.
3. Router nie wiedziałby, że musi fragmentować ramki z M2, ponieważ uważa, że ​​wszystkie hosty w sieci Ethernet LAN, na której działa M1, są w stanie odbierać ramki z ładunkami 1200-bajtowymi, ponieważ skonfigurowano dla nich 1200-bajtową jednostkę MTU berło. Na szczęście prawdopodobnie nadal by się to udało, jak omówiłem w (2).

Dobra, wciąż próbuję znaleźć i odpowiedzieć na prawdziwy duch twojego pytania, powiedzmy, że połączenie między M1 a routerem to tak naprawdę PPP zamiast Ethernet. Protokół PPP pozwala hostom komunikować się / negocjować swoje MRU. Powiedzmy, że M1 powiedział Routerowi, że M1 ma ograniczenie MRU 600 bajtów, więc Router ustawił MTU dla tego łącza na 600 bajtów.

Teraz, w tym przypadku, jeśli M2 wyśle ​​1200-bajtowy datagram IP do M1 (bez ustawienia bitu „Nie fragmentuj” w nagłówku IP), router odbierze go dobrze i zda sobie sprawę, że musi go fragmentować, aby wysłać to do M1. Czy router dzieli go na dwa 600-bajtowe fragmenty? Nie, nie jest to takie proste z kilku powodów.

Jednym z powodów jest to, że każdy fragment musi mieć własny nagłówek IP, który dodaje 20 bajtów do rozmiaru każdego fragmentu po pierwszym. Innym powodem jest to, że pole przesunięcia fragmentacji IP liczy się w 8-bajtowych porcjach zamiast w pojedynczych bajtach.

Powiedzmy, że 1200-bajtowy datagram zawierał 1172 bajty danych aplikacji w datagramie UDP (8 bajtów nagłówków UDP, 20 bajtów nagłówków IP). Po fragmentacji pierwszy fragment zawierałby 20-bajtowy nagłówek IP, 8-bajtowy nagłówek UDP i pierwsze 568 bajtów danych aplikacji, w sumie 586 bajtów. Druga ramka zawierałaby kolejny 20-bajtowy nagłówek IP, brak nagłówka UDP i kolejne 576 bajtów danych aplikacji, co łącznie daje 586 bajtów. Pozostawia to 28 bajtów danych aplikacji dla końcowego fragmentu, który z dodanym nagłówkiem IP miałby 48 bajtów.

Aktualizacja oparta na aktualizacji Kavina, że ​​mówił o ramkach Jumbo: Ramki
Jumbo są czymś, co niektórzy sprzedawcy produktów Gigabit Ethernet tworzyli niezależnie w czasie, gdy GigE był tworzony, i zostało to (jak sądzę) następnie odrzucone lub zignorowane przez IEEE i wydaje się mało prawdopodobne, aby kiedykolwiek stanie się częścią standardu 802.3 Ethernet. Nawet IEEE 802.3-2008, który obejmuje nie tylko 1000BASE-T, ale 10 G BASE-T, nie zawiera niczego o ładunkach ramek 9000-bajtowych.

Dostawcy, którzy wymyślili duże ramki, nie dostarczyli żadnego rodzaju automatycznej negocjacji lub mechanizmu komunikacji dla obsługi dużych ramek, ani nie stworzyli metody fragmentacji warstwy Ethernet do obsługi (bardzo częstego) zilustrowanego przez ciebie przypadku. Jeśli chcesz uruchomić Ethernet LAN w tym niestandardowym trybie, musisz upewnić się, że wszystkie hosty i przełączniki w twojej sieci LAN obsługują duże ramki.

Jeśli karta sieciowa M1 nie jest w stanie odbierać ramek typu jumbo, uzna ramkę typu jumbo za „Ethernet Jabber” - zepsute urządzenie, które „ciągle bełkocze”; wysyła bity daleko poza granicę maksymalnej dozwolonej ramki 1500 (naprawdę 1518) bitów. Należy pamiętać, że to znaczenie jabber jest terminem określającym rodzaj awarii Ethernet i nie należy go mylić z podobnie nazwanym systemem czatu internetowego „Jabber”. Musisz zdecydować, czy chcesz przestać używać dużych ramek w tej sieci, czy też chcesz uaktualnić M1, aby mieć kartę sieciową obsługującą duże ramki.

Jeśli karta sieciowa M1 jest zdolna do odbierania dużych ramek, podejrzewam, że ustawienie jej MTU IPv4 dla tego interfejsu do 1500 zapewni, że nie będzie transmitować żadnych ogromnych datagramów IP w pojedynczej ogromnej ramce Ethernet, ale najprawdopodobniej będzie w stanie odbieranie dużych datagramów IP w pojedynczych dużych ramkach Ethernet nie stanowi problemu, ponieważ ponownie MTU nie jest MRU, a ustawienie MTU warstwy IP nie wpływa na to, jaki bufor buforów rozmiarów pozwala NIC. Teraz, jeśli modyfikujesz ustawienia karty sieciowej / sterownika, aby poinformować kartę sieciową, aby używała tylko buforów 1500-bajtowych zamiast buforów 9000-bajtowych, jest to zmiana w warstwie Ethernet i prawdopodobnie sprawiłaby, że twoja karta sieciowa zachowywałaby się tak, jakby nie obsługuje bufory 9000-bajtowe.

Szczerze mówiąc, nie sądzę, że możesz ustawić MTU na 100 i nadal ustanawiać dowolną formę połączenia IP. Uważam, że ipv4 WYMAGA minimum 576 ... i prawdopodobnie więcej. To CRAAAZY SMALL ... zazwyczaj przełączniki 10/100 zbudowane w ciągu ostatnich 20 lat mają 1492 lub 1500 MTU ... oraz w bardziej wymagających sieciach z lepszym sprzętem aż do 9000.

Istnieje technologia zwana „pmtu” lub Path MTU, w której jeden koniec odkrywa maksymalny rozmiar pakietu, który może niezawodnie przesyłać do drugiego i dostosowuje swoje pakiety do wielkości najmniejszej MTU.

Większe pakiety niż to są pofragmentowane, chyba że w nagłówku IP ustawiona jest flaga „DF” lub „Nie fragmentuj”, w którym to przypadku pakiet zostanie utracony w drodze.

Na połączeniu peer-to-peer, tak jak to opisujesz, powinieneś używać PMTU całkiem szczęśliwie. Staje się to problemem tylko wtedy, gdy routujesz przez wiele sieci, a jeden z routerów między tobą a miejscem docelowym nie obsługuje poprawnie PMTU i nie zgłasza prawidłowego rozmiaru MTU do użycia.