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:
Après la mise à niveau ( robocopy):
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.
1394est le plus grand MTU que j'ai pu traverser.
