Krótka wersja
Moja sieć domowa to czysty gigabit z urządzeniami, które obsługują duże ramki do co najmniej ~ 9000 bajtów. Zwiększenie ustawienia ramki jumbo MTU w Synology do 6000 (bajtów) zwiększa wydajność (zapis 810 Mb / s i odczyt 945 Mb / s). Ustawienie wartości na 7000 niszczy jedynie wydajność odczytu (która spada aż do 4 Mb / s); wydajność zapisu pozostaje szybka.
Jest to nieoczekiwane, ponieważ większość problemów z ramkami typu jumbo nie jest z nimi związana kierunkowość i zazwyczaj są wszystkie lub nic (pakiety są odrzucane na przełączniku bez względu na to, skąd pochodzą). Nie wydaje się być żadnej fragmentacji IP dzieje w ogóle, ale warstwa TCP jest naprawdę nieszczęśliwy. Co może spowodować to asymetryczne / niestabilne zachowanie i jak mogę to naprawić, aby obsługiwać pełną 9000 bajtów MTU, którą powinien obsługiwać cały mój sprzęt?
Długa wersja
To są moje zredagowane notatki zrobione podczas próby zrozumienia tego.
Klient
Kontroler rodziny Realtek PCIe GBE RTL8167
Jumbo Frame: 9KB MTU
$ netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
9198 1 32501506 11275394 Local Area Connection
(pojawia się 9198 nie zawiera 14-bajtowego nagłówka Ethernet)
$ ping -l 1500 -f 192.168.1.84
(obserwowane przy działającym na kliencie Wireshark; wszystkie rozmiary są rozmiarami bajtów drutowych)
[9213, ∞] nie są wysyłane przez hosta (wymagałyby fragmentacji)
[9019, 9212] wysłane, ale brak odpowiedzi
[9015, 9018] fragmentowana odpowiedź IP
[42, 9014 ] niefragmentowane IP
[0, 41]? (nie można wygenerować, ponieważ nagłówki eth + IP + ICMP = 14 + 20 + 8 = 42 bajty)
Router (część przełącznika)
Asus RT-AC68U - Firmware 3.0.0.4.378_4585
Włącz ramkę Jumbo: „Włącz”
Nie można ustalić, jaki rozmiar ramki Jumbo w rzeczywistości obsługuje, wydaje się wynosić co najmniej 9000
Fragmentuje żądania ping od klienta o wielkości 1514 bajtów (ale pingowanie routera może wyzwalać zachowanie routera WAN zamiast zachowania przełącznika LAN?)
Switch niezarządzalny
Ramki Jumbo TP-LINK TL-SG1008D (arkusze danych technicznych): 9 KB (ich strona internetowa mówi 15 KB, ale wygląda jak inne urządzenie)
serwer
Synology DS1815 + - DSM 5.2-5565 Aktualizacja 1
Jumbo Frame: 9000
Pakiety do odczytu plików od Synology do Client
Size: większość ma 9014 bajtów (w obu kierunkach)
Flagi IP: Nie fragmentuj
Odkryto Wireshark: TCP Nieprawidłowa retransmisja, TCP Nie przechwycony poprzedni segment, TCP Out-of-Order, TCP Fast Retransmission, i normalne (9014 bajtów) pakiety
SMB2-over-NetBIOS-protokół długość odczytu odpowiedź odpowiedź odczyt: 65 536 (~ 8 segmentów TCP)
$ ifconfig
bond0 Link encap:Ethernet HWaddr --:FF
inet addr:192.168.1.84 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
UP BROADCAST RUNNING MASTER MULTICAST MTU:9000 Metric:1
RX packets:lots errors:85 dropped:0 overruns:0 frame:85
TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:237 GiB TX bytes:117 GiB
eth2 Link encap:Ethernet HWaddr --:00
UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1
RX packets:lots errors:19 dropped:0 overruns:0 frame:19
TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:236 GiB TX bytes:83 GiB
eth3 Link encap:Ethernet HWaddr --FF
UP BROADCAST RUNNING SLAVE MULTICAST MTU:9000 Metric:1
RX packets:lots errors:66 dropped:0 overruns:0 frame:66
TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1 GiB TX bytes:33 GiB
eth2 i eth3 są łączone za pomocą Adaptive Load Balancing (bez obsługi przełączników)
$ ping -c 5 -s 1500 192.168.1.82
(obserwowane przy działającym Wireshark na kliencie; wszystkie rozmiary są rozmiarami bajtów przewodowych)
[9019, ∞] żądanie wysłane, odpowiedź wysłana, odpowiedź nie otrzymana
[9015, 9018] fragmentowane żądanie IP (prawdopodobnie fragmentowane przez Synology, ping zajęty nie ma opcja bez fragmentu, więc trudno powiedzieć)
[60, 9014] niefragmentowane IP
[0, 59]? (nie można wygenerować, ponieważ ping zajęty umieszcza co najmniej 18 bajtów plus 42 bajty nagłówków)
Różne dane
- Zmiana MTU klienta do 8 KB nie pomogła
- Szybkość odczytu serwera spada z krawędzi po zmianie MTU serwera z 6000 (świetna, 945 Mb / s) na 7000 (straszna, 4 Mb / s)
- Prędkość zapisu na serwerze zasadniczo nie zmienia się przy wszystkich ustawieniach MTU serwera (zawsze między 700 a 825 Mb / s)
- Synology ma połączoną sieć (2 z 4 portów)
- Wszystkie kable to Cat6 lub Cat5e
źródło
Odpowiedzi:
Zaktualizuj oprogramowanie układowe
Z mojego doświadczenia wynika, że Synology naprawia wiele problemów w każdym wydaniu oprogramowania układowego, a ten, z którego korzystasz, ma prawie cztery lata. Nie czytałem informacji o wydaniu, ale wydaje się, że istnieje wiele okazji do naprawienia błędu ramki Jumbo.
Przetestuj z bezpośrednim połączeniem
Podłącz swoją maszynę testową bezpośrednio do Synology (przydziel statyczne adresy IP w tej samej podsieci) za pomocą nowych kabli krosowych i ponownie uruchom testy. Wyeliminuje to okablowanie i przełączniki, a także wszelkie inne problemy związane ze sprzętem i konfiguracją. Jeśli problem nadal występuje, uruchom testy na innym komputerze. Jeśli nadal pozostaje, to z pewnością NAS.
Jeśli problem zniknie podczas testu połączenia bezpośredniego, spróbuj najpierw wymienić przełącznik, a następnie okablowanie. Nie pokazałeś połączeń, więc zakładam tylko TPLINK między maszyną testową a NAS.
źródło