WAN de 20 Mbps limitada a 10 Mbps no túnel IPSec

Recentemente, atualizamos um site remoto de uma fibra de 10/10 Mbps para um link de fibra de 20/20 Mbps (é fibra até o porão, depois VDSL do porão até o escritório, aproximadamente 30 metros). Existem cópias regulares de arquivos grandes (multi-gig) entre este site e um site central, então a teoria era que aumentar o link para 20/20 deveria reduzir pela metade os tempos de transferência.

Para transferências para copiar arquivos (por exemplo, usando robocopypara copiar arquivos em qualquer direção ou replicação do Veeam Backup and Recovery), eles são limitados a 10 Mbps.

Antes da atualização:

Após a atualização ( robocopy):

Quase idêntico (ignore a diferença no tempo de transferência).

As transferências estão sendo feitas através de um túnel IPSec entre um Cisco ASA5520 e um Mikrotik RB2011UiAS-RM .

Primeiros pensamentos:

• QoS - não. Existem regras de QoS, mas nenhuma que afete esse fluxo. Desativei todas as regras por alguns minutos para verificar de qualquer maneira, e nenhuma alteração
• Limites definidos por software. A maior parte desse tráfego é de envio externo do Veeam Backup and Recovery, mas não há limites definidos lá. Além disso, acabei de fazer uma sequência robocopye vi exatamente as mesmas estatísticas.
• Hardware não capaz. Bem, os números de desempenho publicados de um 5520 são 225 Mbps de dados 3DES, e o Mikrotik não publica números, mas seria bem mais de 10 Mbps. O Mikrotik está em torno de 25%-33% de uso da CPU ao fazer esses testes de transferência. (Além disso, fazer uma transferência HTTP pelo túnel IPSec atinge quase 20 Mbps)
• Latência combinada com o tamanho da janela TCP? Bem, é uma latência de 15 ms entre os sites, portanto, mesmo no pior caso, o tamanho da janela de 32 KB 32*0.015é de no máximo 2,1 MB/s. Além disso, várias transferências simultâneas ainda somam apenas 10 Mbps, o que não suporta essa teoria
• Talvez a origem e o destino sejam uma merda? Bem, a fonte pode enviar leituras sequenciais sustentadas de 1,6 GB/s, então não é isso. O destino pode fazer gravações sequenciais sustentadas de 200 MB/s, então também não é isso.

Esta é uma situação muito estranha. Eu nunca vi nada se manifestar dessa maneira antes.

Onde mais posso procurar?

Em uma investigação mais aprofundada, estou confiante em apontar o túnel IPSec como o problema. Fiz um exemplo artificial e fiz alguns testes diretamente entre dois endereços IP públicos nos sites, e depois fiz exatamente o mesmo teste usando os endereços IP internos, e consegui replicar 20 Mbps na Internet não criptografada e apenas 10 Mbps no IPSec lado.

A versão anterior tinha uma pista falsa sobre HTTP. Esqueça isso, este foi um mecanismo de teste defeituoso.

De acordo com a sugestão do Xeon e ecoada pelo meu ISP quando pedi suporte, configurei uma regra mangle para reduzir o MSS dos dados IPSec para 1422 - com base neste cálculo :

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

Para caber dentro do 1480 MTU do ISP. Mas, infelizmente, isso não fez nenhuma diferença efetiva.

Depois de comparar as capturas do wireshark, a sessão TCP negocia um MSS de 1380 em ambas as extremidades agora (depois de ajustar algumas coisas e adicionar um buffer no caso de minha matemática ser ruim. Dica: provavelmente sim). 1380 também é o MSS padrão do ASA de qualquer maneira, então pode ter negociado isso o tempo todo de qualquer maneira.

Estou vendo alguns dados estranhos na ferramenta dentro do Mikrotik que venho utilizando para medir o tráfego. Pode não ser nada. Não percebi isso antes porque estava usando uma consulta filtrada e só vi isso quando removi o filtro.