WAN 20 Mbps limité à 10 Mbps sur tunnel IPSec


11

Nous avons récemment mis à niveau un site distant d'une fibre 10/10 Mbps vers une liaison fibre 20/20 Mbps (c'est de la fibre jusqu'au sous-sol, puis du VDSL du sous-sol au bureau, environ 30 mètres). Il existe régulièrement des copies de fichiers volumineux (multi-gig) entre ce site et un site central, donc la théorie était que l'augmentation du lien à 20/20 devrait réduire de moitié le temps de transfert.

Pour les transferts de copie de fichiers (par exemple, utiliser robocopypour copier des fichiers dans les deux sens, ou la réplication de Veeam Backup and Recovery), ils sont limités à 10 Mbps.

Avant la mise à niveau:

entrez la description de l'image ici

Après la mise à niveau ( robocopy):

entrez la description de l'image ici

Presque identique (ignorez la différence de durée du transfert).

Les transferts sont effectués sur un tunnel IPSec entre un Cisco ASA5520 et un Mikrotik RB2011UiAS-RM .

Premières réflexions:

  • QoS - non. Il existe des règles de QoS, mais aucune ne devrait affecter ce flux. J'ai désactivé toutes les règles pendant quelques minutes pour vérifier de toute façon, et aucun changement
  • Limites définies par logiciel. La majeure partie de ce trafic est expédiée hors site par Veeam Backup and Recovery, mais aucune limite n'y est définie. De plus, je viens de faire une quinte robocopyet j'ai vu exactement les mêmes statistiques.
  • Matériel non compatible. Eh bien, les performances publiées d'un 5520 sont de 225 Mbps de données 3DES, et le Mikrotik ne publie pas de chiffres, mais ce serait bien plus de 10 Mbps. Le Mikrotik est à environ 25% -33% d'utilisation du processeur lors de ces tests de transfert. (De plus, effectuer un transfert HTTP sur le tunnel IPSec atteint près de 20 Mbps)
  • Latence combinée avec la taille de la fenêtre TCP? Eh bien, c'est une latence de 15 ms entre les sites, donc même une taille de fenêtre de 32 Ko dans le pire des cas 32*0.015est d'un maximum de 2,1 Mo / s. De plus, plusieurs transferts simultanés ajoutent simplement jusqu'à 10 Mbps, ce qui ne prend pas en charge cette théorie
  • Peut-être que la source et la destination sont de la merde? Eh bien, la source peut pousser des lectures séquentielles soutenues de 1,6 Go / s, ce n'est donc pas cela. La destination peut effectuer des écritures séquentielles soutenues à 200 Mo / s, ce n'est donc pas cela non plus.

C'est une situation très étrange. Je n'ai jamais rien vu de tel de la même manière auparavant.

Où puis-je chercher?


Après une enquête plus approfondie, je suis confiant de pointer le tunnel IPSec comme le problème. J'ai fait un exemple artificiel et j'ai fait des tests directement entre deux adresses IP publiques sur les sites, puis j'ai fait exactement le même test en utilisant les adresses IP internes, et j'ai pu répliquer 20 Mbps sur Internet non crypté, et seulement 10 Mbps sur IPSec côté.


La version précédente avait un hareng rouge sur HTTP. Oubliez cela, c'était un mécanisme de test défectueux.

Selon la suggestion de Xeon et reprise par mon FAI lorsque je leur ai demandé de l'aide, j'ai mis en place une règle de mangle pour supprimer le MSS pour les données IPSec à 1422 - sur la base de ce calcul :

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

Pour s'adapter à l'intérieur du MTU 1480 du FAI. Mais hélas, cela n'a fait aucune différence effective.


Après avoir comparé les captures de Wharkshark, la session TCP négocie maintenant un MSS de 1380 aux deux extrémités (après avoir peaufiné quelques éléments et ajouté un tampon au cas où mes calculs seraient nuls. Le 1380 est également le MSS par défaut de l'ASA de toute façon, il peut donc avoir négocié cela tout le temps de toute façon.


Je vois des données étranges dans l'outil à l'intérieur du Mikrotik que j'ai utilisé pour mesurer le trafic. Ça pourrait être rien. Je ne l'avais pas remarqué auparavant car j'utilisais une requête filtrée, et je ne l'ai vu que lorsque j'ai supprimé le filtre.


À quoi ressemble le MTU?
xeon

Bon point. C'est 9000 sur les deux commutateurs à chaque extrémité, 1500 sur le serveur et les clients eux-mêmes, et 1480 sur la partie VDSL de la liaison. Ce sont les seules parties des liens que je contrôle.
Mark Henderson

ping -t -f -l 1500 (diminution de 20 après l'échec) destination, une fois que vous êtes vers 1300, je parie que cela fonctionnera, cela devrait indiquer que vous devez ajuster MTU sur les tunnels IPsec ASA / Mikrotik ou vous pourriez être en mesure de le définir il ne fait donc pas tomber les fragments trop gros.
xeon

1394est le plus grand MTU que j'ai pu traverser.
Mark Henderson

Vos données sont fragmentées, donc la réduction du MTU sur le tunnel à 1350-1380 devrait aider à augmenter le débit. La surcharge IPsec est d'environ 84 octets (selon votre encapsulation, etc.), donc 1480 - 84 = 1396, proche de votre maximum que vous avez vu.
xeon

Réponses:


3

Même si le CPU était la troisième chose que j'ai vérifiée, et j'ai écrit ceci:

Le Mikrotik est à environ 25% -33% d'utilisation du processeur lors de ces tests de transfert

Ce qui est confirmé par le graphique CPU

entrez la description de l'image ici

Je l'ai fait confirmer par des ressources externes (c'est-à-dire un tas d'autres forums de support et blogs ) que la plupart des routeurs Mikrotik ne peuvent tout simplement pas pousser plus de 11 Mbps de trafic IPSec avec le cryptage 3DES ou AES, sauf si vous obtenez un modèle avec déchargement du cryptage matériel .

Il semble donc que ce ne soit qu'une limitation matérielle. J'aurais dû l'attraper beaucoup plus tôt, mais pour une raison quelconque, le Mikrotik ne m'indiquait pas qu'il était lié au processeur.

Je fais du shopping.


Je serais intéressé de connaître la limitation spécifique qui impose ce plafond pour le trafic IPSec. L'une de vos sources externes l'a-t-elle expliqué plus en détail?
blacklight

Malheureusement non. J'ai trouvé des discussions sur les forums Mikrotik où 11Mbps a été jeté comme le maximum pour ce routeur (et il semble que je l'ai confirmé ici). Le blog que j'ai lié au gars a effectué ses tests et a obtenu environ 1 Mbps de trafic, mais sur un routeur beaucoup moins puissant. Le mien devrait être environ 6 à 10 fois plus puissant et il semble que je reçois 6 à 10 fois la quantité de trafic IPSec, ce qui correspond à tous. Cela ne ressemble pas à un problème lié au processeur, ni à un problème lié à l'IRQ, ni à un problème lié à la mémoire. Je n'ai aucune idée de ce qui se passe réellement ici.
Mark Henderson

2

Je peux confirmer que le coupable est le CPU. Ici, j'ai comparé un Mikrotik RB750GL et j'ai mesuré 12 Mb / s avec du trafic AES-128 (et seulement 6,0 Mb / s avec 3DES).

Votre résultat semble parfaitement en ligne avec ce que j'ai enregistré.


Il semble que la vitesse supplémentaire de 200 MHz entre le 750 et le 2011 n'a pas fait de différence avec les vitesses IPSec. Je souhaite que Mikrotik publie ces chiffres quelque part.
Mark Henderson
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.