Recentemente, atualizamos um site remoto de uma fibra de 10 / 10Mbps para um link de fibra de 20 / 20Mbps (é fibra para o porão e depois VDSL do porão para o escritório, aproximadamente 30 metros). Há cópias regulares de arquivos grandes (de várias apresentações) entre este site e um site central; portanto, a teoria era de que aumentar o link para 20/20 deveria reduzir pela metade os tempos de transferência.
Para transferências para copiar arquivos (por exemplo, usar 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 na duração da transferência).
As transferências estão sendo feitas em um túnel IPSec entre um Cisco ASA5520 e um Mikrotik RB2011UiAS-RM .
Primeiras reflexões:
- QoS - não. Existem regras de QoS, mas nenhuma que deve afetar esse fluxo. Desativei todas as regras por alguns minutos para verificar mesmo assim, e nenhuma alteração
- Limites definidos por software. A maior parte desse tráfego é enviada pela Veeam Backup and Recovery para fora do local, mas não há limites definidos nele. Além disso, fiz apenas uma sequência
robocopye vi exatamente as mesmas estatísticas. - Hardware não capaz. Bem, os números publicados de desempenho de um 5520 são 225Mbps de dados 3DES, e o Mikrotik não publica números, mas ultrapassaria os 10Mbps. O Mikrotik está em torno de 25% a 33% de uso da CPU ao fazer esses testes de transferência. (Além disso, fazer uma transferência HTTP através do túnel IPSec atinge quase 20 Mbps)
- Latência combinada com o tamanho da janela TCP? Bem, é uma latência de 15ms entre os sites, portanto, mesmo no pior dos casos, o tamanho da janela de 32 KB
32*0.015é no máximo 2,1 MB / s. Além disso, várias transferências simultâneas ainda somam 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, por isso não é isso. O destino pode fazer gravações sequenciais sustentadas de 200 MB / s, portanto 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, em seguida, fiz exatamente o mesmo teste usando os endereços IP internos. Consegui replicar 20 Mbps na Internet não criptografada e apenas 10 Mbps no IPSec. lado.
A versão anterior tinha um arenque vermelho sobre HTTP. Esqueça isso, este foi um mecanismo de teste com defeito.
Conforme a sugestão do Xeon e ecoada pelo meu ISP quando solicitei suporte, estabeleci uma regra de mangle para descartar 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 no 1480 MTU do ISP. Mas, infelizmente, isso não fez diferença efetiva.
Depois de comparar as capturas do wireshark, a sessão do TCP negocia um MSS de 1380 nos dois extremos agora (depois de ajustar algumas coisas e adicionar um buffer caso minha matemática seja ruim. Dica: provavelmente sim). 1380 também é o MSS padrão da ASA de qualquer maneira, portanto, pode ter sido negociado isso o tempo todo de qualquer maneira.
Estou vendo alguns dados estranhos na ferramenta dentro do Mikrotik que tenho usado para medir o tráfego. Não poderia ser nada. Eu não percebi isso antes, pois estava usando uma consulta filtrada e só vi isso quando removi o filtro.
1394é o maior MTU que consegui superar.
