WAN 20 Mb / s ograniczony do 10 Mb / s przez tunel IPSec

11

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ą:

wprowadź opis zdjęcia tutaj

Po aktualizacji ( robocopy):

wprowadź opis zdjęcia tutaj

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.

Mark Henderson
źródło
Jak wygląda MTU?
xeon,
Słuszna uwaga. Jest 9000 na obu przełącznikach na obu końcach, 1500 na serwerze i samych klientach, a 1480 w części VDSL łącza. To jedyne części linków, które kontroluję.
Mark Henderson
ping -t -f -l 1500 (zmniejszenie o 20 po awarii) miejsce docelowe, gdy będziesz około 1300 Założę się, że to zadziała, powinno to oznaczać, że musisz dostosować MTU w tunelach ASA / Mikrotik IPsec lub być może będziesz w stanie to ustawić więc nie upuszcza fragmentów na duże.
xeon,
1394jest największym MTU, przez które udało mi się przejść.
Mark Henderson
Twoje dane są pofragmentowane, więc zmniejszenie MTU w tunelu do 1350-1380 powinno pomóc zwiększyć przepustowość. Narzut IPsec wynosi około 84 bajtów (w zależności od enkapsulacji itp.), Więc 1480 - 84 = 1396, prawie tyle, ile widziałeś.
xeon,

Odpowiedzi:

3

Mimo że procesor był trzecią rzeczą, którą sprawdziłem i napisałem to:

Mikrotik ma około 25% -33% użycia procesora podczas wykonywania tych testów transferu

Potwierdza to wykres procesora

wprowadź opis zdjęcia tutaj

Zasoby zewnętrzne (np. Kilka innych forów i blogów wsparcia ) potwierdziły, że większość routerów Mikrotik nie jest w stanie przesyłać więcej niż 11 Mb / s ruchu IPSec z szyfrowaniem 3DES lub AES, chyba że otrzymujesz model z odciążeniem szyfrowania sprzętowego .

Wygląda na to, że jest to tylko ograniczenie sprzętowe. Powinienem był go złapać znacznie wcześniej, ale z jakiegoś powodu Mikrotik nie wskazywał mi, że jest związany z procesorem.

Idę na zakupy.

Mark Henderson
źródło
Chciałbym poznać szczególne ograniczenie, które nakłada ten pułap na ruch IPSec. Czy którekolwiek z zewnętrznych źródeł wyjaśniło to bardziej szczegółowo?
blacklight
Niestety nie. Znalazłem wątki na forach Mikrotik, gdzie 11 Mb / s było rzucane jako maksimum dla tego routera (i wygląda na to, że to tutaj potwierdziłem). Blog, który podłączyłem do tego faceta, uruchomił testy i uzyskał około 1 Mb / s ruchu, ale na znacznie, znacznie mniej zasilanym routerze. Mój powinien być około 6-10 razy mocniejszy i wydaje się, że uzyskuję 6-10 razy większy ruch IPSec, który wszystko pasuje. Nie wygląda to na problem związany z procesorem, problem związany z przerwaniem IRQ lub problem związany z pamięcią. Nie mam pojęcia, co się tu właściwie dzieje.
Mark Henderson
2

Mogę potwierdzić, że winowajcą jest procesor. Tutaj przeprowadziłem testy porównawcze Mikrotik RB750GL i mierzyłem 12 Mb / s przy ruchu AES-128 (i tylko 6,0 Mb / s przy 3DES).

Twój wynik wydaje się idealnie zgodny z tym, co zarejestrowałem.

Shodanshok
źródło
Wygląda na to, że dodatkowe 200 MHz w prędkości między 750 a 2011 nie miało żadnego znaczenia dla prędkości IPSec. Chciałbym, żeby Mikrotik gdzieś opublikował te dane.
Mark Henderson