Recentemente, atualizamos um site remoto de fibra de 10 / 10Mbps para um link de fibra de 20 / 20Mbps (é 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 diminuir pela metade os tempos de transferência.
Para transferências para copiar arquivos (por exemplo, usando robocopy
para 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ósaatualizaçã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 .
Primeiras impressões:
- QoS - não. Existem regras de QoS, mas nenhuma que deva afetar esse fluxo. Eu desativei todas as regras por alguns minutos para verificar de qualquer maneira, e nenhuma alteração
- Limites definidos pelo software. A maior parte desse tráfego é feita pelo Veeam Backup e Recovery off-site, mas não há limites definidos lá. Além disso, eu fiz um
robocopy
direto e vi exatamente as mesmas estatísticas.
- Hardware não compatível. Bem, os números de desempenho publicados do 5520 são 225Mbps de dados 3DES, e o Mikrotik não publica números, mas seria bem acima de 10Mbps. O Mikrotik está com cerca de 25% -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 perto de 20Mbps)
- Latência combinada com o tamanho da janela TCP? Bem, é de 15 ms latência entre os sites, por isso, mesmo um pior caso 32KB tamanho da janela de
32*0.015
é um máximo de 2,1MB / seg. 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 empurrar leituras seqüenciais sustentadas de 1,6 GB / s, então 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 investigações posteriores, estou confiante em apontar para 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 o mesmo exato teste usando os endereços IP internos e consegui replicar 20Mbps na Internet não criptografada e apenas 10Mbps no lado IPSec.
A versão anterior tinha um arenque vermelho sobre HTTP. Esqueça isso, este foi um mecanismo de teste com defeito.
De acordo com a sugestão do Xeon e ecoada pelo meu ISP quando pedi suporte, configurei uma regra de mangle para descartar o MSS dos dados do IPSec para 1422 - baseado 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 diferença efetiva.
Depois de comparar as capturas 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 uma droga. Dica: provavelmente funciona). 1380 também é o MSS padrão do ASA, então pode ter sido negociado o tempo todo de qualquer maneira.
Estou vendo alguns dados estranhos na ferramenta dentro do Mikrotik que estou usando para medir o tráfego . Pode ser nada. Eu não percebi isso antes, pois estava usando uma consulta filtrada e só vi isso quando removi o filtro.