DawidS28 Opublikowano 16 Sierpnia 2012 Zgłoś Udostępnij Opublikowano 16 Sierpnia 2012 All rights reserved. Copyright © Dawid Suder, 2012 MTU — Maximum Transmission Unit Omówienie teoretycznych podstaw i zasad funkcjonowania protokołu Ethernet ze szczególnym naciskiem na parametr Maximum Transmission Unit (MTU). Przedstawienie powszechnych problemów i metod radzenia sobie z nimi. Spis treści Czym jest MTU? Budowa ramki Ethernet Ramki pozostałych protokołów — sieci WAN Path MTU Discovery Path MTU Discovery Black Holes Ręczne wykrywanie i ustawianie MTU Optymalne wartości MTU - rozwiązywanie problemów Rozwiązywanie problemu czarnych dziur Path MTU Discovery Odnośnik do komentarza
DawidS28 Opublikowano 17 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 17 Sierpnia 2012 Czym jest MTU? MTU (Maximum Transmission Unit) jest podanym w bajtach rozmiarem największego możliwego ładunku, jaki może zostać przeniesiony przez określony protokół w jednej jednostce. Pojęcie MTU jest zazwyczaj utożsamiane z warstwą 2. modelu ISO/OSI (łącza danych), czyli warstwą pierwszą modelu TCP/IP (dostępu do sieci). Należy zwrócić uwagę, że MTU dla poszczególnych protokołów może być krańcowo odmienne. Protokół IPv4 jest w stanie przenosić pakiet o wielkości 65 535 bajtów (w tym dane i zmiennej długości nagłówek). W komunikacji wykorzystuje się zazwyczaj najniższe MTU spośród wykorzystywanych w połączeniu protokołów w celu uniknięcia fragmentacji pakietów. Jeżeli ramka wykorzystywanego w drugiej warstwie ISO/OSI (łącza danych) standardu Ethernet II ma maksymalne MTU równe 1500 bajtów, to pakiet IPv4 w trzeciej warstwy (sieciowej) może mieć taki maksymalnie rozmiar. Wynika to z faktu, że informacje przekazywane przez warstwy wyższe są kapsułkowane w jednostkach warstw niższych, by ostatecznie w postaci zer i jedynek trafić na nośnik fizyczny. Kapsułkowanie danych przedstawia poniższy schemat. Informacje "wysyłane są" z górnego lewego rogu i trafiają do odbiorcy nad prawym górnym krańcem obrazka. Wiadomość przygotowywana do wysyłania jest opakowywana w kolejne nagłówki, niezbędne do dostarczenia jej do wskazanego odbiorcy. U celu swej podróży jest wyciągana z poszczególnych "opakowań" i trafia w górę stosu, by zostać przekazana do użytkownika. (źródło obrazka: pl.wikipedia.org) Kolejną komplikacją jest fakt, że transportowane dane przechodzą przez wiele sieci, w których mogą działać różne protokoły. Zatem, gdy informacja jest wysyłana najpierw przez protokół PPPoE (MTU=1492) powszechnie wykorzystywany w usługach ADSL, np. Neostradzie, a potem przechodzi przez sieć Ethernet II (MTU=1500), to — w celu uniknięcia podziału na kawałki — ramka może mieć rozmiar nie większy, niż 1492 bajty + rozmiar nagłówka. Przy projektowaniu protokołu trzeba wziąć pod uwagę wiele czynników. Maksymalny rozmiar przenoszonego ładunku nie może być zbyt mały, wtedy komunikacja staje się mało wydajna, ponieważ rozmiar nagłówka jest dla większości protokołów stały, a nie niesie on ze sobą informacji przydatnych końcowemu użytkownikowi. Jeżeli MTU dla sieci Ethernet II (przyjmujemy, że korzystamy z oryginalnego standardu Ethernet 10 Mb/s) wynosi 1000 bajtów, to cała ramka — wraz z nagłówkiem — ma rozmiar 1038 bajtów = 1000 bajtów danych + 26 bajtów nagłówka + 12 bajtów przerwy między pakietami. Stąd narzut w postaci informacji sterujących (nagłówka) wynosi ok. 3,67 %. Jeśli zastosowane zostaje MTU równe 1500 bajtów, to narzut redukuje się do 2,47 % (38/1538 * 100 %), ponieważ na 1538 bajtów całej ramki tylko 38 stanowią informacje bezużyteczne z punktu widzenia odbiorcy, konieczne jednak do prawidłowego przesyłania danych. MTU nie powinno być jednocześnie zbyt duże. W sieciach, w których występują problemy ze stabilnością komunikacji, retransmitowanie danych uszkodzonych podczas przesyłania zajmowałoby zbyt wiele pasma. Zazwyczaj uszkodzony jest tylko fragment przesyłanych danych. Duże rozmiary pakietów sprawiałyby, że wiele informacji retransmitowanych byłoby zupełnie niepotrzebnie. Często też ograniczenia w wielkości MTU wynikają z projektu wykorzystywanego protokołu. Rozmiar pakietu IPv4 jest przechowywany w 16-bitowej zmiennej całkowitoliczbowej, która może przyjmować wartości nie większe niż 216-1 = 65 535. Podstawowym jednak czynnikiem ograniczającym rozmiar ramki Ethernet jest fakt, że standard został opracowany w latach 80., kiedy pamięć była zdecydowanie droższa niż jest obecnie, a karty sieciowe musiały posiadać szybką pamięć jako bufor, do magazynowania otrzymywanych i wysłanych ramek. Im mniejsza ramka, tym szybciej można ją przekazać do wyższej warstwy i nie musi ona zajmować cennego miejsca. Jeśli zostanie przez użytkownika zastosowana zbyt wysoka wartość MTU, to pakiet zostanie podzielony na części. Spowoduje to opóźnienie w transmisji, a także nieefektywne wykorzystanie pasma. W przypadku, gdy nastąpiłaby próba transmisji ramki Ethernet z ładunkiem o wielkości 1501 bajtów, taka ramka zostanie podzielona na dwie części. Jedną, przenoszącą 26-bajtowy nagłówek wraz z 1500 bajtami danych i 12-bajtową przerwą i drugą, z 26 bajtami prawie identycznego nagłówka, 1 bajtem danych i wypełnieniem w wielkości 45 bajtów oraz przerwą, by osiągnąć minimalny rozmiar ramki Ethernet II. Obie ramki mają w sumie 1622 bajty, a przenoszą 1501 B informacji użytecznych, co daje narzut 7,46 %. Odnośnik do komentarza
DawidS28 Opublikowano 17 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 17 Sierpnia 2012 Budowa ramki Ethernet Ethernet jest technologią działającą w warstwie dostępu do sieci modelu TCP/IP. Odpowiada za specyfikację nośników fizycznych, przesyłanych nimi sygnałów oraz format przesyłających dane ramek. Oczywiście, Ethernet nie jest jedynym dostępnym rozwiązaniem, wykorzystuje się także sieci FDDI (Fiber Distributed Data Interface), Token Ring i ArcNET, jednak pierwsza ma zastosowanie tylko do transmisji światłowodowych, znaczenie dwóch ostatnich jest marginalne ze względu na przestarzałość. Istnieją trzy podstawowe wersje Ethernet: Ethernet II Najpopularniejszy format ramek Ethernet, stworzony przez firmy DEC, Intel i Xerox, stąd często ramka nazywana jest DIX. Poniższy schemat przedstawia jej budowę: Każdą ramkę Ethernet, bez względu na typ (Ethernet II, 802.3 itd.) poprzedza 7-bajtowa preambuła i 1-bajtowy fragment Start Of Frame (Początek ramki). Pozwalają one na poprawną synchronizację urządzeń sieciowych pracujących w warstwie łącza danych. Preambuła składa się z naprzemiennych 0 i 1 (rozpoczynając od 1), a SOF to sekwencja 10101011. Zazwyczaj ten fragment ramki Ethernet nie jest wyszczególniany w schematach ani logach z programów sniffujących, np. Wireshark. Pierwsze dwa widoczne pola (Destination MAC Address oraz Source MAC Address) nie wymagają prawdopodobnie wyjaśnienia. Są to, źródłowy i docelowy, adresy MAC, które jednoznacznie identyfikują odbiorcę, a dokładniej jego kartę sieciową, w sieci lokalnej. Dwubajtowe pole EtherType identyfikuje protokół wyższej warstwy zawarty w ramce Ethernet. Pozwala to na przekazanie ładunku z ramki do odpowiedniego protokołu komputera odbierającego żądanie. Dla protokołu IPv4 wartość pola to 0x0800, a dla ARP 0x0806. IPv6 korzysta z 0x86DD. Potem następuje zmiennej długości ładunek, a na końcu czterobajtowe pole Frame Check Sequence, zawierające wyliczoną wartość CRC32 dla całej ramki, na podstawie której można zweryfikować jej poprawność. MTU dla ramki Ethernet II wynosi 1500 B. Rozmiar, a zatem i koniec, ramki Ethernet II nie jest jawnie zadeklarowany. Po sekwencji FCS rozpoczyna się przerwa w transmisji trwająca 9,6 mikrosekundy. Dzięki temu urządzenie odbierające "jest świadome" zakończenia pojedynczej ramki. Ramka Ethernet II może przenosić między 46 a 1500 bajtów ładunku. Informacje mniejsze niż 46 bajtów muszą być w warstwie wyższej uzupełnione. Ograniczenie to wiąże się z wykrywaniem kolizji w sieciach Ethernet. Maksymalna wartość RTT (potrzebna na wysłanie pakietu do najbardziej oddalonego węzła i otrzymanie odpowiedzi) jest czasem transmisji 464 bitów (czyli 46,4 μs dla Ethernet, 4,64 μs dla Fast Ethernet, 0,464 μs dla Gigabit Ethernet itd.). Maksymalny dopuszczalny czas propagacji w sieci Ethernet wynosi czas transmisji 288 bitów. Zatem czas RTT powiększony o margines bezpieczeństwa, to okres transmisji 576 bitów (57,6 μs — Ethernet, 5,76 μs — Fast Ethernet, 0,576 — Gigabit Ethernet). W tym czasie jest możliwe wykrycie wszelkich kolizji w sieci Ethernet. Przez ten czas wysyłane jest dokładnie 576 bitów = 72 bajty. 8 bajtów przypada na preambułę i SOF, kolejne 12 na adresy MAC, 4 — pole EtherType i ostatnie 4 — FCS. 72 B - (8 B + 12 B + 2 B + 4 B + 4 = 46 B, stąd minimalny rozmiar ładunku. Ramki krótsze niż 72 bajty są odrzucane. Przy stosowaniu technologii 802.1Q (VLAN) do ramki Ethernet dodawane są pola, tzw. tagi, o rozmiarze 4 B, zatem minimalna wielkość ładunku spada do 42 B. 802.2 LLC Kolejną wersją ramki jest, zaproponowana w 1985 roku w standardzie 802.2, LLC (Logical Link Control). Jest obecnie bardzo rzadko stosowana, jednak stanowi podstawę do omówienia modelu 802.2 SNAP, dlatego pozwolę sobie umieścić tutaj jest omówienie. Ramka jest poprzedzona 7-bajtową preambułą i 8-bitowym polem SOF, po jej transmisji następuje 12-bajtowa przerwa IFG (Interframe Gap). W przeciwieństwie do Ethernet II, 13. i 14. bajt służą jako pole Length, które określa rozmiar ramki. Zawiera wartość rozmiaru od pierwszego pola nagłówka LLC, do ostatniego pola ładunku. Minimalną wartością tego pola jest 46 (0x02E), a maksymalną 1500 (0x05DC), co pozwala na odróżnienie ramki 802.33 LLC od Ethernet II, bowiem wartości pola EtherType rozpoczynają się od 1536 (0x0600). Bajty 15.-17., znane z Ethernet II jako początek ładunku, stały się nagłówkiem LLC. Pierwszy z nich, DSAP, określa protokół docelowy warstwy wyższej, drugi, SSAP, protokół źródłowy. Pole Control, jedno- lub dwubajtowe pozwala na stwierdzenie, czy ramka została wysłana w jednym z dwóch trybów bezpołączeniowych(pole ma wartość 0x01 dla trybu bez potwierdzeń lub 0x03 dla trybu z potwierdzeniami), czy jest częścią niezawodnej połączeniowej sesji LLC (0x02). W praktyce stosuje się pole Control o rozmiarze jednego bajta o wartości 0x03. Więcej informacji można znaleźć w standardzie IEEE 802.2 dostępnym TUTAJ. Potem następuje pole ładunku, które może mieć między 43 a 1497 bajtów (zakładam, że pole Control ma 1 bajt), które zakończone jest 32-bitową sumą kontrolną CRC32 (pole FCS) i 12-bajtowym IFG, których budowa w niczym nie odbiega od standardu Ethernet II. 802.3 SNAP Rozwinięciem ramki LLC, jest ramka SNAP: Na początku pola z ładunkiem został dodany 5-bajtowy nagłówek SNAP. Mimo, iż pakiety IP mogłyby z powodzeniem korzystać z ramki 802.2 LLC (pole Destination SAP/Source SAP dla IP ma zdefiniowaną wartość 0x06), dokument RFC 1042 nakazuje korzystać z kapsułkowania SNAP. Celem takiego rozwiązania jest zapewnienie zgodności protokołów warstwy sieciowej zaprojektowanych z myślą o Ethernet II ze standardem 802.2 LLC. Pola DSAP/SSAP z nagłówka LLC są ustawiane na 0xAA, a jednobajtowe Control - 0x03. Pole Organizationally Unique Code ma 3 bajty i wskazuje organizację zarządzającą listą następnych dwóch bajtów. Dla IP i ARP pole to ma wartość 0x000000. Kolejne dwa bajty, czyli EtherType jest — w przypadku ustawienia OUI na 0x000000 — kalką identycznego pola ze standardu Ethernet II. Dodanie 5 bajtów zamiast ładunku sprawia, że minimalny PDU (Protocol Data Unit) dla ramki wynosi już tylko 38 bajtów, zmniejsza się natomiast MTU do 1492 bajtów. W praktyce ramki 802.3 SNAP nie są praktycznie wykorzystywane w technologii Ethernet. Można je spotkać w sieciach AppleTalk, Token Ring i NetBIOS/NetBEUI. Systemy Windows domyślnie korzystają z technologii Ethernet II. Są w stanie odbierać ramki 802.3 SNAP, jednak odpowiedź na nie jest już wysyłana w ramce DIX. Jeśli urządzenie komunikujące się z komputerem z systemem Windows nie rozpozna ramki Ethernet II, komunikacja przy domyślnych ustawieniach nie jest możliwa. Wartość REG_DWORD rejestru ArpUseEtherSNAP w kluczu HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters pozwala na modyfikację ustawień. Domyślnie wartość ta jest ustawiona na 0. W przypadku przypisania jej 1, system Windows rozpoczyna wysyłanie pakietów IP i ARP wpakowanych w ramki 802.3 SNAP. Przełączenie na Ethernet II jest wtedy możliwe, jeżeli nadejdzie odpowiedź w ramce DIX lub kierowane do komputera zapytanie jest taką ramką. Zmiana ustawień jest możliwa w systemach Windows 2000 i nowszych (KLIK). Pozostałe ramki Ethernet 802.3 Raw "Czysta" ramka, stworzona przez firmę Novell, to relikt z początku lat 80. (stosowany do ok. 1995), który postał jeszcze przed zakończeniem prac nad standardem LLC przez IEEE. Do przenoszenia pakietów IPX Novell zaprojektował własną ramkę Ethernet opartą o 802.2 LLC, która zawiera ładunek umieszczony zaraz za polem Length. W celu umożliwienia odróżnienia ramki Raw do 802.2 LLC pierwsze dwa bajty ładunku mają wartość 0xFFFF. Jednak, ponieważ miejsce to było przeznaczane wcześniej w protokole IPX na sumę kontrolną, pakiety przenoszone w ten sposób nie mają możliwości sprawdzenia poprawności danych w warstwie trzeciej (sieciowej). MTU takiego rozwiązania wynosi 1498 bajtów. Począwszy od wersji Novell NetWare 4.10, do transmisji pakietów IPX wykorzystywany jest standard 802.2 LLC. Jumbo Frames Ramki Jumbo stosowane są do przenoszenia ładunku większego niż 1500 bajtów. Zazwyczaj ich górna granica PDU wynosi 9000 bajtów. W komercyjnych rozwiązaniach stosowane są bardzo rzadko, głównie dlatego, że nie są częścią żadnego standardu IEEE, a także wiele urządzeń ich nie wspiera. Ethernet II pozwala na identyfikację ramek Jumbo na postawie pola EtherType o wartości 0x8870. Odnośnik do komentarza
DawidS28 Opublikowano 18 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 18 Sierpnia 2012 Ramki pozostałych protokołów — sieci WAN PPPoE Technologia PPPoE (PPP over Ethernet) została stworzona w celu zapewnienia dostawcom możliwości uwierzytelniania, kontroli dostępu i, w konsekwencji, naliczania opłat dla poszczególnych użytkowników za korzystanie z usługi Internetowej przy wykorzystaniu protokołu PPP (Point-to-Point Protocol), którego pakiety kaspułkowane są w ramkach Ethernet. Dzięki temu jest możliwe wykorzystywanie już istniejącej infrastruktury, standard Ethernet jest bowiem jednym z najbardziej rozpowszechnionych. Protokół PPPoE wyróżnia dwa odrębne stany, w których może znajdować się połączenie. Jest to faza odkrywania (Discovery stage) oraz sesja PPP (PPP sesion). Podczas pierwszej, uzgadniane jest połączenie. Druga odpowiada za przesyłanie użytecznych danych. Faza odkrywania Faza odkrywania jest bezpołączeniowa (jest zapewniania niezawodność transmisji) i służy wynegocjowaniu połączenia oraz jego parametrów. Składa się z 5 etapów i przypomina nieco komunikację protokołu DHCP. Ramka PPPoE w fazie odkrywania składa się z omówionego wcześniej nagłówka Ethernet II, pakietu PPP wraz z ładunkiem oraz sekcji Frame Check Sequence, która zawiera sumę kontrolną pozwalającą sprawdzić integralność danych. EtherType dla fazy odkrywania jest ustawiane na 0x8863. Pakiet PPP dzieli się na kilka części. Pierwsze pole to VER (4 bity) i odpowiada za identyfikację wersji protokołu. Musi być ustawione na 0x1. Czterobitowe pole TYPE określa typ PPP, jego wartość to także 0x1. Sekcja CODE zajmuje osiem bitów i pozwala na rozpoznanie rodzaju pakietów, wysyłanych w trakcie fazy odkrywania. W sesji PPP jest ona równa 0x00. Pole SESSION_ID zawiera unikalny numer sesji PPP. Pozwala na identyfikowanie konkretnego połączenia. Następnie występuje dwubajtowe pole Length, określające rozmiar ładunku PPP wraz z TAG-ami, sekcja TAG-ów o zmiennej długości oraz ładunek użyteczny, przenoszony przez pakiet PPP. Każdy TAG składa się z dwubajtowego pola z jego nazwą, dwubajtowego pola z rozmiarem i sekcji przeznaczonej na jego wartość (o zmiennej długości). Prześledźmy teraz komunikację w fazie odkrywania. Komputer wysyła pakiet PADI (PPPoE Active Discovery Initiation) z polem Destination MAC Address ustawionym na 0xFFFFFFFFFFFF, czyli adres rozgłoszeniowy MAC. Trafia on do wszystkich komputerów w sieci. Pole CODE ma wartość 0x09, a SESSION_ID jest równy 0x0000. Pakiet PADI musi zawierać dokładnie jeden TAG, jest nim Service Name, który indetyfikuje usługę hosta wysyłającą żądanie. Pakiet (wraz z nagłowkiem PPP) musi mieć rozmiar co najwyżej 1484 bajty, by zostawić miejsce na opcjonalny TAG Relay-Session-Id, dodawany przez węzeł przekazujący żądanie do serwera. Gdy Access Concentrator pełniący rolę serwera otrzyma pakiet PADI, który może obsłużyć, odpowiada wysyłając PADO (PPPoE Active Discovery Offer). Destination MAC Addres jest ustawiany na adres MAC hosta, pole CODE ma wartość 0x07, a SESSSION_ID - 0x0000. Pakiet PADO musi zawierać jeden TAG AC-Name, który przenosi nazwę serwera dostępu (Access Concentrator), TAG Serivce-Name identyczny z wysłanym przez hosta, oraz dowolną liczbę TAG-ów Service-Name informujących o usługach oferowanych przez serwer. Ponieważ pakiet PADI był rozgłoszeniowy, host żądający połączenia może otrzymać więcej niż jego PADO. Musi wtedy wybrać Access Concentrator, z którym chce nawiązać połączenie. Wybór jest dokonywany na podstawie nazwy serwera dostępu lub oferowanych przez niego usług. Do wybranego węzła odsyłana jest ramka PADR (PPPoE Active Discovery Request), która zawiera pole Destination MAC Address ustawione na adres MAC wybranego serwera AC. Pole CODE ma wartość 0x19, a SESSION_ID - 0x0000. Pakiet musi zawierać dokładnie jeden TAG Service-Name, identyfikujący usługę udostępnioną na AC, z której klient chce korzystać, oraz dowolną liczbę innych TAG-ów. Gdy AC otrzyma pakiet PADR, rozpoczyna przygotowania do nawiązania sesji PPP. Tworzy unikatowy SESSION_ID i odsyła go w pakiecie PADS (The PPPoE Active Discovery Session-confirmation). Pole Destination MAC Address jest ustawiane na adres MAC, z którego przyszedł pakiet PADR. Pole CODE ma wartość 0x65. Pakiet zawiera jeden TAG Service-Name zawierający nazwę usługi, z którą serwer zaakceptował połączenie, oraz dowolną liczbę innych TAG-ów. Jeżeli AC nie akceptuje połączenia z wybraną przez klienta usługą, musi odesłać pakiet PADS wraz z TAG-iem Service-Name-Error oraz polem SESSION_ID ustawionym na 0x0000. Ostatnim pakietem fazy odkrywania jest PADT (PPPoE Active Discovery Terminate). Służy on do przerywania nawiązanej wcześniej sesji i używa się go do zamykania połączenia. Może zostać wysłany przez klienta, jak i serwer udostępniający połączenie (Access Concentrator). Pole CODE ma wartość 0xA7, a SESSION_ID określa przerywane połączenie. Jeżeli host nie otrzymuje odpowiedzi na pakiet PADO przez określony limit czasu, powinien ponowić jego transmisję, zwiększając dwukrotnie limit czasowy. Takie działanie jest wykonywane określoną liczbę razy, w zależności od użytej implementacji protokołu. Jeśli klient nie otrzymuje pakietu PADS, to powinien kilkukrotnie według takiej samej procedury ponowić wysyłanie pakietu PADR, a jeśli i to nic nie da, to spróbować nawiązać łączność ponownie, wysyłając PADO. Nazwy usług kodowane są w UTF-8. Więcej informacji na temat protokołu PPPoE, przykłady wysyłanych pakietów oraz opis TAG-ów, są dostępne w RFC 2516. Sesja PPP O sesji PPP można mówić od otrzymania pakietu PADR przez klienta. Większość pól, znanych z fazy odkrywania, pozostaje niezmieniona. EtherType zostaje ustawione na 0x8864. Pole CODE musi być ustawione na 0x00. Dodane zostało dwubajtowe pole PPP Protocol ID, które identyfikuje protokół wyższej warstwy, w tym przypadku LCP i ma wartość 0xC021. Pole TAG w sesji PPP nie ma zastosowania. MTU w fazie odkrywania to 1494 bajty (pomniejszone o rozmiar TAG-ów), a w trakcie sesji PPP - 1492 bajty. RFC 4638 nakreśla możliwość negocjowania wyższego niż 1492 bajty MTU dla połączeń PPPoE poprzez dodanie do pakietu PADI i PADS TAG-u PPP-Max-Payload. AC powinien odpowiadać wtedy pakietami PADO i PADR z ustawionym tym samym TAG-iem. W celu przetestowania rozwiązania klient powinien mieć możliwość wysyłania pakietów o rozmiarze większym niż 1492 bajty, wynegocjowanym w fazie odkrywania. Jeżeli nie otrzyma odpowiedzi, może wysłać pakiet mniejszy lub równy 1492 bajtom. W przypadku otrzymania odpowiedzi, MTU musi zostać ograniczone do normalnej wielkości (. Należy zauważyć, że żaden z istniejących standardów IEEE nie wspiera ramek Ethernet z MTU większym niż 1500 B (dla Ethernet II). PPPoA Technologia Point-to-Point Protocol over ATM została opracowana w celu zapewnienia połączeniowego (wykrywającego błędy) protokołu transmisji danych, służącego do tworzenia wirtualnego połączenia pomiędzy dwoma stacjami końcowymi w sieci tego samego typu. Wykorzystywane są ramki ATM Adaptation Layer 5, które odpowiadają z grubsza stosowanemu w sieciach lokalnych Ethernetowi. PPPoA LLC Pierwszym elementem ramki PPPoA jest nagłówek 802.2 LLC, znany z technologii Ethernet 802.2 LLC. Pola DSAP i SSAP mają wartość 0xFE. Control ma wartość 0x03, co wskazuje na bezpołączeniowy wraz z potwierdzeniami charakter komunikacji. Kolejny element to jednobajtowy Network Layer Protocol ID, identyfikujący protokół przenoszony przez ramkę. Jego wartość dla PPP to 0xCF. Następnie umieszczony jest ładunek PPP, który składa się z jedno- lub dwubajtowego pola Protocol Identifier identyfikującego podprotokół (dokładniejsze informacje zawarte są w RFC 1661) oraz właściwego ładunku i opcjonalnego dopełnienia Padding. Ładunek może mieć rozmiar od 0 do 65 535 bajtów. Pole Padding umożliwia uzupełnienie ładunku, jeżeli ma on mniejszy rozmiar, niż zdefiniowany w polu Length. Stosowanie wypełnienia jest opcjonalne, jednak standard wymaga, by urządzenia wzajemnie się komunikujące odbierały ramki zarówno stosujące Padding, jak i nie wykorzystujące go. Jako pewną ciekawostkę można traktować fakt, że "nagłówek" znajduje się na końcu ramki ATM Adaptation Layer 5. Mimo tej drobnej niedogodności, będę go dalej nazywał nagłówkiem, chociaż zgodnie z definicją powinien poprzedzać on właściwie informacje. Pierwszym polem pochodzącym od warstwy AAL5 jest PAD. Umożliwia on, poprzez dodanie wypełnienia, odpowiednie umieszczenie nagłówka w 48-bajtowej szczelinie tworzonej przez podwarstwę SAR technologii ATM. Segmentation and Reassembly Layer ma za zadanie utworzyć pierwotny pakiet na podstawie 48-bajtowych fragmentów. Potem następuje trailer CPCS-PDU (Common Part Convergence Sub-layer PDU). Zawiera on jednobajtowy User-to-User indication, który ma za zadanie zapewnienie przezroczystej transmisji danych od użytkownika do użytkownika. Aktualnie nie jest on wykorzystywany i może być ustawiony na dowolną wartość. Pole Common Part Indicator zostało umieszczone w celu zapewnienia nagłówkowi rozmiaru 8 bajtów, obecnie jest wyzerowane i niewykorzystywane. Może w przyszłości zostać użyte. Length określa rozmiar ładunku PPP. Frame Check Squence jest wynikiem funkcji skrótu CRC32 i zapewnia rozpoznawanie błędów w ramce, powstałych w trakcie jej transmisji. PPPoA VC-Mux Drugą odmianą enkapsulacji, odmienną od LLC, jest Virtual Circuit Multiplexing. Jest on wydajniejszy od LLC, ponieważ do identyfikacji użytych protokołów korzysta się z wirtualnego obwodu, tworzonego przez ATM. Pola obecne w ramce pokrywają się z analogicznymi z PPPoA LLC, więc nie ma potrzeby ponawiania tutaj ich opisu. MTU dla ramek AAL5 wynosi 65 535 bajtów, jednak RFC 2225 określa, że domyślnym MTU dla pakietów IP i ARP jest 9180 bajtów. Jeżeli komunikujące się urządzenia nie wynegocjują wyższego MTU, to dla tych protokołów będzie stosowane właśnie takie. Domyślną wartością MTU dla ramek PPPoA jest 1500 bajtów, chyba, że urządzenia komunikujące się wynegocjują inaczej. Odnośnik do komentarza
DawidS28 Opublikowano 18 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 18 Sierpnia 2012 Path MTU Discovery Path MTU Discovery (RFC 1191) jest techniką dynamicznego odkrywania wartości MTU dla ustalonej ścieżki. Wykorzystuje w tym celu niewielką zmianę wprowadzoną w sposobie generowania przez routery komunikatów ICMP. Dla ścieżek, które przechodzą przez routery nie obsługujące tej zmiany, ta technologia może nie odkryć popranego Path MTU, jednak zawsze wybierze wartość w miarę możliwości najbliższą idealnej. W większości przypadków wartość ta jest bardziej optymalna niż stosowanie statycznych wartości MTU. Jeśli jedno urządzenie ma do wysłania dużą ilość danych, są one transmitowane jako seria datagramów IP. Zazwyczaj preferowane jest, by te pakiety były możliwie jak największe. Zwiększa to wydajność transmisji (patrz: Czym jest MTU?). Maksymalny rozmiar takiego pakietu określa się jako Path MTU, które jest minimalnym MTU ze wszystkich przeskoków w ścieżce. Dotychczasową praktyką było używanie jako MTU wartości mniejszej z 576 B i MTU pierwszego przeskoku (min(576, first_hop_MTU)). Było to skrajnie nieefektywne, ponieważ większość technologii pozwala na wysyłanie pakietów o większym rozmiarze. Jednocześnie takie rozwiązanie nie zapewnia zapobieżenia fragmentacji pakietów, ponieważ niektóre sieci mogą stosować MTU niższe niż 576, a jednocześnie także niższe niż MTU pierwszego przeskoku. Technologia Path MTU Discovery wykorzystuje flagę Don't Fragment ustawianą dla pakietu w nagłówku IP. Początkowo zakłada się, że PMTU ścieżki jest równe MTU pierwszego przeskoku. Następuje wysłanie pakietów z takim MTU do docelowego odbiorcy z flagą DF. Jeżeli jakikolwiek pakiet zostanie przez jakiś węzeł uznany za za duży i wymagający w związku z tym fragmentacji, węzeł ten powinien odrzucić pakiet i wysłać do nadawcy komunikat ICMP Destination Unreachable (Cel nieosiągalny, czyli typ 3.) z kodem błędu 4, oznaczającym Fragmentation Needed and Don't Fragment was Set (Konieczna fragmentacja i flaga DF ustawiona). Po otrzymaniu takiego komunikatu, host wysyłający dane redukuje przewidywaną wartość PMTU dla określonej ścieżki. Proces kończy się w momencie gdy nadawca stwierdza, że PMTU jest wystarczająco niskie, by pakiety mogły zostać dostarczone z uniknięciem fragmentacji. Jest to równoznaczne z otrzymaniem odpowiedzi od adresata. Nadawca może zadecydować, że przestaje ustawiać flagę DF w wysyłanych pakietach, ponieważ jest gotów na fragmentowanie pakietów w pewnych okolicznościach. Normalnie utrzymuje się aktywną flagę DF, ponieważ pozwala to na natychmiastowe stwierdzenie zmniejszenia wartości PMTU ścieżki. W celu wykrycia możliwego wzrostu PMTU nadawca okresowo wysyła pakiety z flagą DF z PMTU równym MTU pierwszego skoku (o ile jest on wyższy od obecnego PMTU) lub najbliższym wyższym poziomem Plateau (patrz: tabela niżej), o ile jest niższy od MTU następnego skoku. Jeśli nie otrzyma komunikatu o błędzie, podwyższa PMTU i wysyła normalne pakiety z większym rozmiarem. Ponieważ wzrost PMTU następuje bardzo rzadko, standard określa, by wysyłanie wyższych pakietów nie następowało zbyt często. Pakiet z większym MTU może być wysłany dopiero po upływie 5 minut od otrzymania ostatniego komunikatu ICMP Destination Unreachable: Fragmentation Needed and Don't Fragment was Set i 1 minuty od ostatniego wzrostu PMTU. W celu uniknięcia zbytniego obciążania sieci przyjmuje się, że wartości czasu powinny być dwukrotnie większego. Ponieważ pierwotny komunikat ICMP Destination Unreachable: Fragmentation Needed and Don't Fragment was Set nie zwracał MTU następnego w kolejności przeskoku, technologia Path MTU Discovery wykorzystuje dwubajtowe wolne miejsce w nagłówku komunikatu ICMP do przekazania tej wartości. Zwrotny pakiet ICMP wygląda wtedy w ten sposób: Pole Type określa typ komunikatu ICMP, Code - dokładny numer błędu. W naszym przypadku są to odpowiednio 3 i 4. Dokładna lista dostępna jest TUTAJ. Checksum to suma kontrolna pakietu ICMP, pozwalająca stwierdzić jego integralność. Pole Unused zostało zarezerwowane do przyszłego użycia i musi być wyzerowane. Next-Hop MTU określa wartość MTU następnego przeskoku i nie może być niższe niż 68. Jest to minimalne MTU, jakie musi obsługiwać każdy router. Jeżeli komunikat pochodzi od węzła nieobsługującego Path MTU Discovery pole Next-Hop MTU będzie wyzerowane. Pakiet kończy się nagłówkiem IP oraz kopią pierwszych 8 bajtów oryginalnego datagramu, który został otrzymany przez węzeł, a z powodu zbyt wysokiego MTU nie może być dalej przekazany. Host nie może podnosić PMTU na podstawie zawartości odpowiedzi ICMP ICMP Destination Unreachable: Fragmentation Needed and Don't Fragment was Set. Wiadomość mająca na celu podniesienie wartości PMTU może być przestarzałym pakietem krążącym po sieci, fałszywym datagramem pochodzącym z ataku DoS lub rezultatem istnienia kilku ścieżek do hosta, z którym prowadzona jest komunikacja. Jeżeli jeden z węzłów na ścieżce wysyła komunikat ICMP o zbyt dużym pakiecie i jednocześnie nie podaje MTU następnego przeskoku, to nadawca ma kilka możliwości postępowania: Ustawić PMTU na wartość mniejszą z 576 B i obecnie zakładanego MTU (min(576, PMTU)). Jest to rozwiązanie analogiczne do wcześniej stosowanej metody, jednak nie pozwala na uniknięcie wielu problemów. Redukować wartość PMTU o określoną liczbę i sprawdzać poprzez wysyłanie pakietów z flagą DF. Jest to metoda niepolecana, ponieważ generuje zbyt duży ruch w sieci. Przy pomocy algorytmu wyszukiwania binarnego określić właściwe PMTU. Jednak ta metoda wymaga również wysłania wielu pakietów, a jest dosyć trudna w implementacji. Najlepszą metodą wydaje się zastosowanie tabeli często wykorzystywanych wartości MTU. Poniżej przedstawiona została tabela podana w RFC 1191, która jest powszechnie stosowana. Plateau MTU Comments Reference ------ --- -------- --------- 65535 Official maximum MTU RFC 791 65535 Hyperchannel RFC 1044 65535 32000 Just in case 17914 16Mb IBM Token Ring 17914 8166 IEEE 802.4 RFC 1042 8166 4464 IEEE 802.5 (4Mb max) RFC 1042 4352 FDDI (Revised) RFC 1188 4352 (1%) 2048 Wideband Network RFC 907 2002 IEEE 802.5 (4Mb recommended) RFC 1042 2002 (2%) 1536 Exp. Ethernet Nets RFC 895 1500 Ethernet Networks RFC 894 1500 Point-to-Point (default) RFC 1134 1492 IEEE 802.3 RFC 1042 1492 (3%) 1006 SLIP RFC 1055 1006 ARPANET BBN 1822 1006 576 X.25 Networks RFC 877 544 DEC IP Portal 512 NETBIOS RFC 1088 508 IEEE 802/Source-Rt Bridge RFC 1042 508 ARCNET RFC 1051 508 (13%) 296 Point-to-Point (low delay) RFC 1144 296 68 Official minimum MTU RFC 791 Table 7-1: Common MTUs in the Internet Wartości przeznaczone do sprawdzania (kolumna Plateau) zostały wyznaczone na podstawie grup często wykorzystywanych MTU. Warto zauważyć, że większość wartości MTU jest zbliżona do wartości potęg dwójki. Posłużyło to za podstawę grupowania. Jeżeli nadawca otrzyma komunikat o zbyt dużym pakiecie, który nie może zostać przesłany dalej, pobiera z zawartego w nim nagłówka IP zbyt dużego pakietu jego wielkość. Ponieważ routery oparte o system BSD 4.2 zwracają tam nieprawidłowe dane (jest to rozmiar całego pakietu + rozmiar jego nagłówka), host musi założyć, że ma z takim pakietem do czynienia. Jeśli rozmiar całego pakietu niż wykorzystane PMTU, należy czterokrotnie odjąć od niego rozmiar nagłówka, który został zwrócony. Na podstawie otrzymanej wartości ustala się najwyższe Plateau, niższe od zastosowanego wcześniej PMTU. Wtedy następuje zmiana szacowanej wartości PMTU i wysłanie kolejnego pakietu z flagą DF zgodnie z nowymi ustaleniami. Proces jest powtarzany aż do osiągnięcia komunikacji pomiędzy hostami. Powyższa metoda nie umożliwia ustalenia zawsze najwyższego możliwego PMTU, jednak jest zdecydowanie bardziej wydajna niż poprzednie trzy. Zdecydowanie lepiej jest wysyłać pakiety o kilka procent mniejsze niż dopuszczalne, niż większe o jeden oktet. Wartości procentowe podane w nawiasach przy każdym Plateau grupy, w której jest więcej niż jedna wartość MTU pozwalają stwierdzić, w jakim stopniu stosowane PMTU może być niedoszacowane względem najwyższego w tej grupie. Rozpatrzmy to na przykładzie. Jeśli dzięki tej metodzie zostało wybrane MTU równe 508 B, a sieć dopuszcza 576 B (czyli najwyższe z tego przedziału), to niedoszacowanie wynosi 13%. Chociaż najbardziej logiczne wydawałoby się pozostawienie wykorzystywania technologii Path MTU Discovery w gestii warstwy odpowiadającej za podział danych na części przeznaczone do wysyłania (robi to np. TCP), to w celu uniknięcia problemów z komunikacją międzywarstwową i wymienianiem się informacjami o PMTU, obowiązek ustalenia odpowiedniej wartości PMTU spada na warstwę trzecią modelu ISO/OSI, czyli protokoły IP i ICMP. Warstwy wyższe mają jednak możliwość wpływania na ustawianie flagi DF oraz dostępu do danych o PMTU w celu określenia rozmiaru wysyłanych segmentów. Dane o aktualnie wynegocjowanych wartościach PMTU dla poszczególnych ścieżek trzymane są w tablicy routingu i kasowane po upływie określonego czasu, jeśli wartość nie została wykorzystana. Zawartość pamięci podręcznej PMTU w systemach Windows Vista/2008/7 można sprawdzić przy pomocy komendy netsh int ip show destinationcache lub netsh int ip show destinationcache level=verbose w celu uzyskania większej ilości informacji. Z technologią Path MTU Discovery wiąże się możliwość przeprowadzenia dwóch ataków. Pierwszy polega na wysyłaniu fałszywych komunikatów ICMP Destination Unreachable: Fragmentation Needed and Don't Fragment was Set, które zawierają zdecydowanie zaniżoną wartość Next-Hop MTU. Nadawca będzie mógł kontynuować transmisję, jednak będzie ona niewydajna, ponieważ zwiększanie PMTU jest procesem stopniowym i dosyć powolnym. Drugi atak opiera się na wysyłaniu komunikatów z Next-Hop MTU zawyżonym względem faktycznej sytuacji. Jednak prawidłowo zaimplementowana technologia odrzuca komunikaty o zbyt dużym pakiecie, które podają MTU wyższe od wykorzystywanego PMTU, więc hosty nie powinny być wrażliwe na ten atak. Zachowanie Path MTU Discovery w systemach Windows można kontrolować przy pomocy wartości REG_DWORD rejestru EnablePMTUDiscovery w kluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Domyślnie (włączona) wartość nie jest obecna. Odpowiada to wartości obecnej w rejestrze, ustawionej na 1. Przypisanie jej 0 skutkuje wyłączeniem mechanizmu Path MTU Discovery. Wtedy wszystkie ramki wysyłane poza sieć lokalną mają MTU ustawione na 576 bajtów. Ustawienie to jest dostępne w systemach Windows 2000 i nowszych. Odnośnik do komentarza
DawidS28 Opublikowano 18 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 18 Sierpnia 2012 Path MTU Discovery Black Holes Czarną dziurą Path MTU Discovery nazywamy węzeł, który po otrzymaniu pakietu z ustawioną flagą Don’t Fragment o rozmiarze większym, niż MTU następnego skoku, odrzuca taki pakiet bez wysłania do nadawcy komunikatu ICMP Destination Unreachable: Fragmentation Needed and Don't Fragment was Set. Powyżej przedstawione zachowanie jest często tłumaczone względami bezpieczeństwa, może powodować jednak wiele problemów w komunikacji sieciowej. Problem został po raz pierwszy zasygnalizowany w RFC 1435, a szczegółowo (wraz z propozycjami przeciwdziałania) opisany w RFC 2923. Mechanizm Path MTU Discovery do ustalenia optymalnego MTU ścieżki wykorzystuje pakiety z ustawioną flagą DF. Jeśli zostanie wysłany taki pakiet i natrafi on na router-czarną dziurę, to nadawca nie otrzyma ani komunikatu o błędzie, ani odpowiedzi od hosta docelowego. Po kliku próbach ponownej transmisji, połączenie zostanie zakończone jako niemożliwe do zrealizowania. Problem ten objawia się przez oczekiwanie w nieskończoność na ładowanie się stron internetowych, a także pojawianie się tylko ich fragmentów. Najbardziej znanymi przykładami są facebook.com i usługa Dropbox. Z uwagi na fakt, że wiele nowoczesnych implementacji TCP korzysta z algorytmów wolnego startu i unikania przeciążeń, pierwsze wysyłane w komunikacji segmenty są dosyć małe i spokojnie przechodzą przez wadliwie skonfigurowane routery. Wraz ze wzrostem rozmiaru segmentów, komunikacja zostaje przerwana. Stąd użytkownik może zauważyć wybiórczo tylko ładujące się strony WWW. Jeżeli nie ma możliwości poprawnej konfiguracji routera odrzucającego zbyt duże pakiety (np. gdy jest to węzeł należący do operatora i zwykły użytkownik nie ma żadnej szansy wpłynięcia na jego konfigurację), pozostają dwa podstawowe sposoby radzenia sobie z przedstawionym problemem. Pierwszym, najbardziej oczywistym, jest wyłączenie mechanizmu Path MTU Discovery. Wtedy MTU zostaje odgórnie ustawione na 576 B, które jest wystarczające do wysyłania pakietów przez zdecydowaną większość istniejących sieci, dalej nie gwarantuje jednak, że użytkownik nie napotka analogicznego problemu. Niektóre, wciąż istniejące, technologie (np. ArcNET) wykorzystują MTU niższe niż 576 B. Należy wtedy ręcznie ustawić jego wartość na odpowiednią w zależności od wykorzystywanej sieci. Drugą metodą jest mechanizm wykrywania czarnych dziur Path MTU Discovery systemu Windows, który pierwszy raz pojawił się w Windows NT 3.51, jednak domyślnie włączony jest dopiero w Windows Vista/Server 2008 i nowszych. W przypadku wykorzystania co najmniej połowy możliwych retransmisji, określonych w rejestrze wartością REG_DWORD o nazwie TcpMaxDataRetransmissions w kluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, gdy pakiet nadal nie jest potwierdzany przez nadawcę, zostaje wysłany następny bez ustawionej flagi DF. Jeżeli taka wiadomość doczeka się potwierdzenia, MTU ścieżki zostaje obniżone do następnej wartości platformowej (patrz. tabela Plateau), a flaga DF ponownie przybiera wartość 1. Sytuacja powtarza się aż do znalezienia odpowiedniego MTU ścieżki. Do zarządzania zachowaniem funkcji wykrywania czarnych dziur służy w systemach Windows wartość REG_DWORD o nazwie EnablePMTUBHDetect w kluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Ustawienie jej na 0 powoduje wyłączenie mechanizmu wykrywania czarnych dziur. Przypisanie 1 - jego aktywację. Domyślnie jest ona nieobecna, a przez to w systemach Windows XP/Server 2003 i starszych - nieaktywna. W Windows Vista/Server 2008 - jest pierwotnie aktywna, jednak wciąż w rejestrze nieobecna. Warto jednak pamiętać, że w celu uniknięcia problemów z czarnymi dziurami PMTUD, technologia ta musi zostać zaimplementowania w obu węzłach prowadzących transmisję. Z tego powodu często jedynym rozwiązaniem jest statyczne ustawienie maksymalnej wartości MTU dla interfejsu. Odnośnik do komentarza
DawidS28 Opublikowano 18 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 18 Sierpnia 2012 Ręczne wykrywanie i ustawianie MTU Informacje przesyłane pomiędzy dwoma komputerami mają postać pojedynczych pakietów o określonym rozmiarze. W standardzie Ethernet MTU wynosi 1500 (bajtów). Jest to domyślne ustawienie w systemie Windows. Przesyłane dane są dzielone na kawałki o wielkości 1500 B i wysyłane w sieć. Nie wszystkie urządzenia mają identycznie określone MTU, więc pakiety mogą zostać podzielone na mniejsze, przekazane dalej i dopiero u celu swej trasy połączone. Powoduje to niepotrzebne opóźnienia w komunikacji. MTU można dowolnie zmieniać przy pomocy polecenia netsh. Należy najpierw sprawdzić obecne ustawienia poszczególnych interfejsów sieciowych przy pomocy polecenia netsh int ip show interfaces z dodatkowym parametrem level=verbose jeśli chcemy uzyskać więcej informacji (dot. tylko Windows Vista/7 - XP ma ten przełącznik aktywny domyślne) lub netsh int ip show subinterfaces (tylko Windows Vista/7). Komendy nie zadziałają, kiedy wyłączona jest usługa Routing i dostęp zdalny. Pojawi się wtedy błąd podobny do poniższego. Można ją uruchomić, wykorzystując dwie dodatkowe komendy: sc config remoteaccess start= demand net start remoteaccess Wyniki polecenia netsh int ip show int mogą wyglądać różnie, w zależności od systemu: Przy zmianie interesuje nas numer interfejsu (index) oraz aktualne MTU. Wartość Maximum Transmission Unit można sprawdzić programem AdapterWatch od NirSoft. Na stronie dostępne jest także spolszczenie. Najlepsze MTU można ustalić doświadczalnie przy pomocy Wiersza poleceń i komendy ping. W tym celu kliknij Windows + R, wpisz cmd i w otwartym oknie Wiersza poleceń testuj największą możliwą wartość MTU przy pomocy polecenia: ping -f -l 1500 www.google.pl Pingowany adres jest właściwie dowolny, jednak proponuję ustawienie jakiegoś często wykorzystywanego, co wpłynie pozytywnie na szybkość działania tej strony w przyszłości (MTU będzie zoptymalizowane do połączeń z tym adresem). Za wartość 1500 podstawiamy coraz niższą, aż dojdziemy do momentu, kiedy zamiast pojawiającego się błędu Pakiet musi być podzielony na fragmenty, ale ustawiono opcję DF... ...otrzymamy odpowiedź serwera. Do uzyskanego wyniku dodajemy 28 (wielkość nagłówka IP+ICMP) i zapisujemy przy pomocy programu netsh przedstawioną wcześniej metodą. Na podstawie MTU ustala się rozmiar MSS (Maximum Segment Size), czyli wielkości transmitowanego segmentu TCP, który może zostać wysłany bez fragmentacji. Wartość MSS jest o 40 (rozmiar nagłówka IP+TCP) niższa od MTU. Ethernet MTU ustawiamy w Wierszu poleceń przy pomocy komendy netsh int ip set interface 1 mtu=1500 (dostępna tylko na systemach Windows Vista / Server 2008 i nowszych). Można także użyć polecenia netsh int ip set subinterface 1 mtu=1500 (dostępne także tylko od Visty/2008 w górę), w którym można dodać przełącznik store= z parametrem active (ustawienie działa tylko do ponownego uruchomienia komputera) lub persistent pozwalające na trwałą zmianę, stosowane domyślnie. W obu przypadkach 1 to numer lub nazwa interfejsu sieciowego, do którego odnosi się zmiana, a mtu=1500 to deklaracja nowej wartości parametru. Numer 1 jest zarezerwowany dla interfejsu loopback (pętla, sprzężenie zwrotne) i nie należy zmieniać jego MTU. W przypadku wykorzystywania wielowyrazowej nazwy interfejsu w poleceniu należy objąć ją cudzysłowem. W poleceniu netsh można skracać parametry, jeśli tylko jednoznacznie określają one, co ma być wykonywane, więc komenda netsh interface ip show interface level=verbose jest równoznaczna netsh int ip sh int l=v (ich wyniki są identyczne). Zbytnie skracanie nazw wpływa jednak negatywnie na czytelność poleceń. Możesz także skorzystać z programu Dr. TCP, przeznaczonego dla systemów Windows 9x/Me/2000/XP. Proszę nie korzystać z Dr. TCP na systemach Windows Vista/7! Więcej informacji o programie jest dostępnych TUTAJ. We wszystkich systemach Windows, poczynając od 2000, zmianę MTU można wykonać poprzez bezpośrednią ręczną edycję wartości REG_DWORD o nazwie MTU, która znajduje się w kluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID_INTERFEJSU}. Należy dodać, że poniższe zmiany mają znaczenie tylko w przypadku wartości niższych niż domyślne MTU wykorzystywanego standardu. Podanie wartości większej niż domyślna dla danej sieci spowoduje wykorzystanie domyślnej wartości MTU technoloii sieci. Podanie wartości mniejszej niż 68 spowoduje wykorzystanie MTU równego 68. PPPoE/PPPoA W przypadku PPPoA/PPPoE Windows korzysta domyślnie z MTU równego 1480 B. W systemach Windows XP i starszych można skorzystać z programu Dr. TCP, opisywanego przeze mnie wcześniej. Wartość MTU dla PPPoE/PPPoA ustawiana jest przy pomocy opcji Dial UP (RAS) MTU. Edycję można wykonać z rejestru. W tym celu należy w kluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0 utworzyć trzy wartości REG_DWORD: ProtocolType z daną 0x800, PPPProtocolType o danej 0x21 oraz ProtocolMTU z wartością wybranego MTU. W przypadku tej ostatniej proponuję przy edycji zmienić System liczbowy na Dziesiętny w celu uniknięcia przeliczania wartości MTU, która zazwyczaj podawana jest właśnie w systemie decymalnym. Pozostałe wartości zostały podane w systemie szesnastkowym. W systemach Windows 2000/XP/2003 można wykorzystać Fix It Microsoftu: KLIK. VPN Edycję można wykonać z rejestru. W tym celu należy w kluczu HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0 utworzyć trzy wartości REG_DWORD: ProtocolType z daną 0x800, PPPProtocolType o danej 0x21 oraz TunnelMTU z wartością wybranego MTU. W przypadku tej ostatniej proponuję przy edycji zmienić System liczbowy na Dziesiętny w celu uniknięcia przeliczania wartości MTU, która zazwyczaj podawana jest właśnie w systemie decymalnym. Pozostałe wartości zostały podane w systemie szesnastkowym. W systemach Windows 2000/XP/2003 można wykorzystać Fix It Microsoftu: KLIK. Odnośnik do komentarza
DawidS28 Opublikowano 25 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 25 Sierpnia 2012 Optymalne wartości MTU - unikanie fragmentacji Ethernet/WiFi Większość implementacji stosu TCP/IP korzysta z ramek Ethernet II i tutaj nie ma żadnych niespodzianek. Podstawowe i najsensowniejsze MTU wynosi 1500 bajtów. Tak samo sprawa wygląda z sieciami bezprzewodowymi w standardzie 802.11n - najlepsze MTU to dalej 1500 B. Chociaż ta technologia WiFi dopuszcza stosowanie ramek o rozmiarze ładunku znacznie przewyższającym ethernetowe 1500 B, to jednak prawie w każdym przypadku dane są potem pakowane w ramki Ethernet do przesłania dalej po sieci kablowej. Optymalne MTU to takie, które uwzględnia wszystkie wąskie gardła w często (lub zawsze) wykorzystywanej ścieżce. PPPoE Podobnie ma się sprawa z PPPoE. Maksymalne MTU zdefiniowane przez standard to 1492 B. Jednak korzystanie z niego może być w pewnych przypadkach nieoptymalne. Jeżeli dostawca wykorzystuje infrastrukturę Ethernet, to nie ma problemu. Dane przesyłane nie będą prawdopodobnie nigdy fragmentowane. Jeśli jednak, jak czyni to obecnie większość providerów, wykorzystują na pewnym odcinku technologię ATM, to wszystkie ramki warstwy wyższej muszą zostać podzielone na 48-bajtowe fragmenty. Ramka ATM ma bowiem ustalony rozmiar: 53 B = 5 bajtów nagłówka + 48 bajtów ładunku. Mniejsze informacje uzupełniane są paddingiem. Jeżeli zostanie wykorzystane MTU równe 1492 B, to cała ramka będzie mieć 1518 B (1492 B ładunku + 2 B nagłówka PPP + 6 bajtów nagłówka PPPoE + 18 B nagłówka Ethernet). Zostanie ona podzielona na 31 pełnych fragmentów, 30-bajtowy 32. kawałek oraz zostanie dodany 8-bajtowy SAR (Segmentation and Reassmbly) Trailer, odpowiadający za poprawne złożenie ramki. Do ostatniej, 32. ramki ATM, zostanie dodane 10 bajtów wypełnienia. Wszystko to razem będzie mieć rozmiar 32 * 53 B = 1696 B. Stąd można łatwo policzyć, że narzut informacji sterujących to ok. 13,67 %. Teraz należy znaleźć najwyższą wartość, mniejszą od maksymalnego MTU (czyli 1492 , która pozwoli na równe zapakowanie wszystkich danych w ramki ATM bez stosowania paddingu. Łatwo można zauważyć, że wykorzystamy 31 ramek. Ostatnia musi zawierać 8 B SAR, więc pozostaje nam 30 * 48 B + 40 B = 1480 B. 18 B odpada na nagłówek Ethernet, 6 B na PPPoE, 2 B na PPP. Mamy zatem 1480 B - (18 B + 6 B + 2 = 1480 B - 26 B = 1454 B. Przy takim układzie przenosimy 1454 B danych przy wykorzystaniu ramek o rozmiarze 53 B * 31 = 1643 B. Narzut informacji sterujących to ok. 13 %. PPPoA Protokół PPPoA został zaprojektowany z myślą o przenoszeniu ramek przez datagramy ATM. Eliminuje poważniejsze wady PPPoE, jest bardziej wydajny, może przenosić większy ładunek, jednak trzeba pamiętać, że dane przenoszone przez PPPoA prędzej czy później zostaną przepakowane do ramek Ethernet, stąd domyślnym MTU dla PPPoA jest 1500 B. PPPoA LLC Przy wykorzystaniu MTU równego 1500 B, zostaje dodanych 14 B nagłówka (3 B na LLC, 1 B - NLPID, 2 B - Protocol ID, 8 B - CPCS-PDU Trailer). Ramka o rozmiarze 1514 B jest dzielona na 31 48-bajtowych pełnych datagramów ATM i jeden 26-bajtowy. Nie zostaje zatem wykorzystane 22 B miejsca w ostatniej ramce ATM. W celu przeniesienia 1500 B wykorzystuje się transmisję 1696 B danych. Narzut wynosi zatem 13,07 %. Można zatem zmniejszyć MTU o 26 B (do 1474 . Wtedy dane zostają równo zapakowane do 31 ramek ATM, które zajmują 1643 B. Narzut to (1643 B - 1474 B)/(1474 * 100 % = 11,47 %. PPPoA VC-Mux Dla 1500 B danych zostaje dodane zaledwie 10 B informacji sterujących. 1510 B dzielone jest na 31 pełnowymiarowych 48-bajtowych ramek ATM i jedną 22-bajtową, dopełnioną paddingiem o rozmiarze 26 B. Wraz z nagłówkami ATM zajmują one 1696 B. Informacje sterujące w takiej konfiguracji stanowią ok. 13,07 %. Po ograniczeniu MTU o 22 B do 1478 B, jest wykorzystywane tylko 31 ramek ATM, o łącznym rozmiarze 1643 B. Narzut wynosi w takim przypadku 11,16 %. Odnośnik do komentarza
DawidS28 Opublikowano 29 Sierpnia 2012 Autor Zgłoś Udostępnij Opublikowano 29 Sierpnia 2012 Rozwiązywanie problemu czarnych dziur Path MTU Discovery Technologie Path MTU Discovery i PMTUD Black Hole Detection zostały już dokładnie omówione. Warto jednak pamiętać, że do całkowicie poprawnego działania sieci wymagane jest uruchomienie mechanizmów na obu komunikujących się hostach. W przeciwnym razie, przesyłanie informacji może być niemożliwe lub utrudnione. Pierwszym krokiem przy diagnozowaniu problemów z MTU jest sprawdzenie aktualnych ustawień i porównanie z MTU przeznaczonym dla wykorzystywanej technologii. Jeśli ustawiony maksymalny rozmiar pakietu jest wyższy od możliwości technologii, należy go zredukować. Czarne dziury najłatwiej wykryć, śledząc wysyłane i otrzymywane pakiety. Można to zrobić przy pomocy dowolnego programu przeznaczonego do sniffowania (podsłuchiwania) połączenia sieciowego, dla systemu Windows polecam darmowy Wireshark. Jeżeli komunikacja z większością zdalnych hostów działa poprawnie, a jeden odpowiada tylko na komunikat SYN, wysyłając krótkie - nie przekraczające rzeczywistych możliwości sieci - SYN-ACK, lecz nie może przesłać większych danych, to znaczy, że prawdopodobną przyczyną jest właśnie czarna dziura Path MTU Discovery. W takim przypadku najlepszym rozwiązaniem jest stopniowe zmniejszanie wartości MTU. W zdecydowanej większości przypadków rozwiązaniem jest wykorzystanie MTU równego 1492 B lub - w przypadku niektórych łącz Netii - 1432 B. Graniczną wartością, poniżej której nie warto (pomijając naprawdę szczególne przypadki) już schodzić, jest 1400 B. Należy zauważyć, że niskie MTU, chociaż pozwala wyeliminować problemy, powoduje także obniżenie wydajności łącza. Dlatego najlepszym rozwiązaniem jest ręczne ustawianie odpowiedniej wartości, korzystając z komunikatów ICMP Echo Request (czyli polecenia ping) z ustawioną flagą Don't Fragment, co zostało wcześniej przeze mnie opisane. Niekiedy zdarza się także sytuacja, że zbyt niskie MTU powoduje problemy (przykład TUTAJ). W tym przypadku winne było ustawienie niższego MTU na routerze, niż na komputerach do niego podłączonych. Powinno przestrzegać się, by w całej sieci ustawione było MTU o równej wartości. Odnośnik do komentarza
Rekomendowane odpowiedzi