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


11

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:

insira a descrição da imagem aqui

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

insira a descrição da imagem aqui

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.


Como é o MTU?
xeon

Bom ponto. São 9000 nos dois switches em cada extremidade, 1500 no servidor e nos próprios clientes e 1480 na parte VDSL do link. Essa é a única parte dos links que eu controlo.
Mark Henderson

destino ping -t -f -l 1500 (diminua 20 após falha), quando você tiver cerca de 1300, aposto que funcionará, isso deve indicar que você precisa ajustar o MTU nos túneis ASA / Mikrotik IPsec ou você pode configurá-lo para não deixar os fragmentos grandes demais.
xeon 26/03

1394é o maior MTU que consegui superar.
Mark Henderson

Seus dados estão sendo fragmentados, portanto, reduzir o MTU no túnel para 1350-1380 deve ajudar a aumentar a taxa de transferência. A sobrecarga do IPsec é de cerca de 84 bytes (dependendo do seu encapsulamento, etc.), então 1480 - 84 = 1396, próximo ao máximo que você viu.
xeon 26/03

Respostas:


3

Mesmo que a CPU tenha sido a terceira coisa que verifiquei, e escrevi isso:

O Mikrotik está em torno de 25% a 33% de uso da CPU ao fazer esses testes de transferência

O que é confirmado pelo gráfico da CPU

insira a descrição da imagem aqui

Confirmei por recursos externos (ou seja, vários outros fóruns e blogs de suporte ) que a maioria dos roteadores Mikrotik simplesmente não consegue enviar mais de 11 Mbps de tráfego IPSec com criptografia 3DES ou AES, a menos que você obtenha um modelo com descarregamento de criptografia de hardware .

Portanto, parece que isso é apenas uma limitação de hardware. Eu deveria ter percebido muito antes, mas por algum motivo o Mikrotik não estava indicando para mim que estava sendo vinculado à CPU.

Fora das compras eu vou.


Eu estaria interessado em saber a limitação específica que está impondo esse limite para o tráfego IPSec. Alguma de suas fontes externas explicou isso com mais profundidade?
Blacklight

Infelizmente não. Eu encontrei alguns tópicos nos fóruns do Mikrotik, onde 11 Mbps foram lançados como o máximo para este roteador (e parece que eu confirmei isso aqui). O blog que eu vinculei ao cara fez seus testes e obteve cerca de 1 Mbps de tráfego, mas em um roteador com potência muito, muito menor. O meu deve ter entre 6 e 10 vezes mais poderoso e parece que estou recebendo de 6 a 10 vezes a quantidade de tráfego IPSec, o que corresponde a todos. Não se parece com um problema vinculado à CPU, nem com um IRQ, nem com um problema de memória. Não tenho ideia do que realmente está acontecendo aqui.
Mark Henderson

2

Posso confirmar que o culpado é a CPU. Aqui comparei um Mikrotik RB750GL e medi 12 Mb / s com tráfego AES-128 (e apenas 6.0 Mb / s com 3DES).

Seu resultado parece perfeitamente alinhado com o que registrei por mim.


Parece que os 200Mhz extras de velocidade entre os 750 e os 2011 não fizeram nenhuma diferença nas velocidades IPSec. Eu gostaria que o Mikrotik publicasse esses números em algum lugar.
Mark Henderson
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.