WAN 20 Мбит / с ограничена до 10 Мбит / с по туннелю IPSec

Недавно мы модернизировали удаленный участок с оптоволоконного канала 10/10 Мбит / с до оптоволоконного канала 20/20 Мбит / с (это оптоволокно до подвала, затем VDSL от подвала до офиса, примерно 30 метров). Между этим сайтом и центральным сайтом существуют регулярные большие (многогигабаритные) копии файлов, поэтому теория заключалась в том, что увеличение ссылки до 20/20 должно почти вдвое сократить время передачи.

Для передач для копирования файлов (например, с использованием robocopy для копирования файлов в любом направлении или репликации Veeam Backup and Recovery) они ограничены 10 Мбит / с.

Перед обновлением:

После обновления (robocopy):

Практически идентичны (не обращайте внимания на разницу во времени передачи).

Передачи выполняются через туннель IPSec между Cisco ASA5520 и Микротик RB2011UiAS-RM.

Первые мысли:

• QoS - нет. Есть правила QoS, но ни одно из них не должно влиять на этот поток. Я все равно отключил все правила на несколько минут, чтобы проверить, и без изменений
• Программно определяемые пределы. Большая часть этого трафика отправляется Veeam Backup and Recovery за пределы офиса, но никаких ограничений там нет. Кроме того, я просто сделал прямую robocopy и видел точно такую ​​же статистику.
• Оборудование не поддерживает. Что ж, опубликованные показатели производительности 5520 составляют 225 Мбит / с данных 3DES, а Mikrotik не публикует цифры, но это будет намного больше 10 Мбит / с. Mikrotik использует около 25% -33% ЦП при выполнении этих тестов передачи. (Кроме того, передача HTTP через туннель IPSec достигает скорости около 20 Мбит / с)
• Задержка в сочетании с размером окна TCP? Задержка между сайтами составляет 15 мс, поэтому даже в худшем случае размер окна 32 КБ составляет 32*0.015 составляет максимум 2,1 МБ / с. Кроме того, несколько одновременных передач по-прежнему просто добавляют до 10 Мбит / с, что не поддерживает эту теорию.
• Может быть, и источник, и место назначения - дерьмо? Источник может выдавать устойчивые последовательные чтения 1,6 ГБ / сек, так что это не так. Место назначения может выполнять непрерывную последовательную запись со скоростью 200 МБ / с, так что это тоже не так.

Это очень странная ситуация. Я никогда раньше не видел ничего подобного.

Где еще я могу посмотреть?

При дальнейшем исследовании я уверен, что укажу на туннель IPSec как на проблему. Я сделал надуманный пример и провел несколько тестов непосредственно между двумя общедоступными IP-адресами на сайтах, а затем провел точный Тот же тест с использованием внутренних IP-адресов, и я смог реплицировать 20 Мбит / с через незашифрованный Интернет и только 10 Мбит / с на стороне IPSec.

В предыдущей версии HTTP был отвлечен. Забудьте об этом, это был неисправный механизм тестирования.

В соответствии с предложением Xeon, которое повторил мой интернет-провайдер, когда я попросил их о поддержке, я установил правило исключения, чтобы сбросить MSS для данных IPSec до 1422 - на основе этого расчета:

 1422   +  20 + 4 +  4 +   16  +   0     +      1    +     1     +   12
PAYLOAD  IPSEC SPI ESP  ESP-AES ESP (Pad)  Pad Length Next Header ESP-SHA

Чтобы поместиться в 1480 MTU провайдера. Но, увы, это не помогло.

После сравнения захватов wirehark сеанс TCP теперь согласовывает MSS 1380 на обоих концах (после настройки нескольких вещей и добавления буфера на случай, если моя математика отстой. Подсказка: вероятно, это так). 1380 в любом случае также является MSS по умолчанию для ASA, так что, возможно, он все время согласовывал это все время.

Я вижу странные данные в инструменте внутри Mikrotik который я использовал для измерения трафика. Это не могло быть ничего. Раньше я этого не замечал, поскольку использовал отфильтрованный запрос, и увидел это только тогда, когда удалил фильтр.