Niedawno zaktualizowaliśmy zdalną stronę z światłowodu 10 / 10Mbps na łącze światłowodowe 20 / 20Mbps (jest to światłowód do piwnicy, a następnie VDSL od piwnicy do biura, około 30 metrów). Pomiędzy tą witryną a witryną centralną istnieją regularne kopie dużych plików (wiele gig), więc zgodnie z teorią zwiększenie łącza do 20/20 powinno znacznie skrócić czas transferu.
W przypadku transferów do kopiowania plików (np. Przy użyciu robocopydo kopiowania plików w dowolnym kierunku lub replikacji Veeam Backup i Recovery) są one ograniczone do 10 Mb / s.
Przed aktualizacją:
Po aktualizacji ( robocopy):
Prawie identyczne (zignoruj różnicę czasu transferu).
Transfer odbywa się w tunelu IPSec między Cisco ASA5520 a Mikrotik RB2011UiAS-RM .
Pierwsze przemyślenia:
- QoS - nie. Istnieją reguły QoS, ale żadne nie powinno wpływać na ten przepływ. Wyłączyłem wszystkie reguły na kilka minut, aby sprawdzić mimo to i bez zmian
- Limity zdefiniowane przez oprogramowanie. Większość tego ruchu jest wysyłana przez Veeam Backup and Recovery poza witrynę, ale nie ma tam żadnych ograniczeń. Dodatkowo zrobiłem strita
robocopyi zobaczyłem dokładnie te same statystyki. - Sprzęt nie jest zdolny. Cóż, opublikowane dane wydajności 5520 to 225 Mb / s danych 3DES, a Mikrotik nie publikuje liczb, ale byłoby to znacznie powyżej 10 Mb / s. Mikrotik ma około 25% -33% użycia procesora podczas wykonywania tych testów transferu. (Również wykonanie transferu HTTP przez tunel IPSec osiąga prawie 20 Mb / s)
- Opóźnienie w połączeniu z rozmiarem okna TCP? Cóż, opóźnienie między witrynami
32*0.015wynosi 15 ms, więc nawet najgorszy rozmiar okna 32 KB wynosi maksymalnie 2,1 MB / s. Ponadto wiele jednoczesnych transferów wciąż dodaje tylko 10 Mb / s, co nie obsługuje tej teorii - Może źródło i miejsce docelowe to gówno? Źródło może przesyłać ciągłe sekwencyjne odczyty 1,6 GB / s, więc to nie tak. Miejsce docelowe może wykonywać ciągłe sekwencyjne zapisy z szybkością 200 MB / s, więc to nie wszystko.
To bardzo dziwna sytuacja. Nigdy wcześniej nie widziałem niczego manifestującego się w taki sposób.
Gdzie jeszcze mogę szukać?
Przy dalszym dochodzeniu jestem pewny, że wskazałem jako problem tunel IPSec. Zrobiłem wymyślony przykład i wykonałem kilka testów bezpośrednio między dwoma publicznymi adresami IP w witrynach, a następnie wykonałem dokładnie ten sam test przy użyciu wewnętrznych adresów IP i byłem w stanie replikować 20 Mb / s przez niezaszyfrowany internet i tylko 10 Mb / s na IPSec bok.
Poprzednia wersja miała czerwony śledź na temat HTTP. Zapomnij o tym, to był wadliwy mechanizm testowy.
Zgodnie z sugestią Xeon i potwierdzoną przez mojego dostawcę usług internetowych, gdy poprosiłem ich o wsparcie, skonfigurowałem regułę maglowania, aby upuścić MSS dla danych IPSec do 1422 - na podstawie tych obliczeń :
1422 + 20 + 4 + 4 + 16 + 0 + 1 + 1 + 12
PAYLOAD IPSEC SPI ESP ESP-AES ESP (Pad) Pad Length Next Header ESP-SHA
Pasuje do 1480 MTU dostawcy Internetu. Ale niestety nie ma to żadnej skutecznej różnicy.
Po porównaniu przechwyconych wireshark, sesja TCP negocjuje teraz MSS 1380 na obu końcach (po poprawieniu kilku rzeczy i dodaniu bufora na wypadek, gdyby moja matematyka była do bani. Wskazówka: prawdopodobnie tak jest). 1380 jest również domyślnym MSS ASA, więc i tak mógł negocjować cały czas.
W narzędziu Mikrotik widzę dziwne dane , których używałem do mierzenia ruchu. To może być nic. Nie zauważyłem tego wcześniej, ponieważ korzystałem z filtrowanego zapytania i zobaczyłem to dopiero po usunięciu filtra.
1394jest największym MTU, przez które udało mi się przejść.
