Quel est le goulot d'étranglement IPsec sous Linux?

19

J'essaie de comparer les performances de plusieurs protocoles de sécurité réseau entre deux hôtes connectés en Gigabit Ethernet.

Mon objectif ici est de voir si je peux saturer ma bande passante, et sinon, quel est le facteur limitant.

avec SSL, je peux atteindre 981 MBit / s, donc la liaison Ethernet est évidemment le facteur limitant;
avec SSH, je ne peux atteindre que 750 Mbits / s, mais l'un de mes cœurs est à 100%. Comme SSH est monothread, le CPU est le facteur limitant;
avec IPsec, j'ai lu environ 500 Mbits / s mais aucun de mes cœurs n'est à 100% (ils sont inférieurs à 50%).

Ma question est donc la suivante: pourquoi IPsec ne peut-il pas atteindre une bande passante plus élevée?

Les deux hôtes exécutent Debian Wheezy et Strongswan pour IPsec.

performance bandwidth ipsec

— user50228
source

3

Vous devrez vous assurer que vos processeurs ont l' aesinstruction de mieux décrypter les paquets sur les deux sites intel.co.jp/content/dam/www/public/us/en/documents/white-papers/… , et assurez-vous que vous êtes Rendre IPSec parallèle et utiliser Tunnel Mode + ESP - strongswan.org/docs/Steffen_Klassert_Parallelizing_IPsec.pdf . C'est le meilleur moyen d'obtenir des performances avec ce protocole.

Malheureusement, j'ai des processeurs i3 sans support AES-NI et je travaille en mode tunnel entre les deux hôtes. Je comprends comment vos deux conseils augmenteraient la bande passante dans le cas où un processeur était à 100% d'utilisation. L'utilisation d'AES-NI permettrait de traiter plus de paquets et augmenterait le BW. Mais ici, le CPU ne semble pas être le facteur limitant.

— user50228

3

Hmm, c'est intéressant. Je soupçonne que quelque chose dans le noyau ralentit les choses. Pourriez-vous partager votre configuration IPSec? J'aimerais instrumenter une VM et voir quels résultats j'obtiendrai avec différents paramètres.

— Lmwangi

1

Il y a tellement de facteurs qui entrent en ligne de compte. La carte réseau frappe plus de parties de la carte que vous ne pouvez l'imaginer. N'importe quel ensemble si des instructions peuvent traverser le fil et frapper une partie du système de pilote et le goulot de la bouteille vers le bas. Vous pouvez prendre un single-core 1200mhz single core et régler le matériel pour faire sauter les portes et quad core 3600mhz. C'est vraiment une question spécifique au matériel.

comment font-ils ça? avec quelque chose comme ceci http://www.ixiacom.com/products/ixn2x C'est l'appareil de 165 000 $ "Je vais te casser". c'est-à-dire 2 concerts de trafic erroné dans un tuyau 1gig. Une fois que vous commencez à battre le système et à casser des trucs, le goulot de votre bouteille «se révélera». Mettez à jour vos compétences GDB!

Chaque système a une méthode différente pour résoudre le problème. Certaines cartes ont des limites technologiques qui peuvent vous plafonner.

La réponse est ambiguë car la solution est ambiguë. Je peux penser à 20 possibilités différentes du haut de ma tête, y compris la pagination qui peut varier d'une version du système d'exploitation à l'autre.

— Brad
source

0

Je me demande si c'est parce que des temps d'attente ou de sommeil artificiels ont été insérés dans la crypto. Ce n'est pas très probable imo, mais ...

http://www.tau.ac.il/~tromer/acoustic/

Je n'aurais pas pu poster ceci en tant que commentaire, cela aurait été mieux adapté de cette façon.

— Raymond Bannan
source

0

Il se peut qu'à un moment donné, seul l'un des deux cœurs soit saturé, mais en moyenne, il semble qu'ils soient tous les deux à environ 50% (car le noyau attribue de manière aléatoire un processus IPsec à un seul thread aux deux cœurs; cependant pour autant que je ont remarqué que Linux (contrairement à Windows) essaie généralement de garder un thread sur le même noyau).

À certaines périodes brèves, IPSec peut également attendre le réseau, ce qui, associé à un taux de transfert lent, serait le signe d'une mauvaise mise en mémoire tampon.

La compression (le cas échéant) et la surcharge du protocole peuvent également affecter vos tests.

— mik
source