Qual è il collo di bottiglia di IPsec in Linux?

19

Sto cercando di confrontare le prestazioni di diversi protocolli di sicurezza di rete tra due host collegati in Gigabit Ethernet.

Il mio obiettivo qui è vedere se posso saturare la mia larghezza di banda e, in caso contrario, qual è il fattore limitante.

con SSL, posso raggiungere 981 MBit / s, quindi il collegamento Ethernet è ovviamente il fattore limitante;
con SSH posso raggiungere solo 750 MBit / s, ma uno dei miei core è al 100% di utilizzo. Poiché SSH è a thread singolo, la CPU è il fattore limitante;
con IPsec, ho letto circa 500 MBit / s, ma nessuno dei miei core è al 100% (sono meno del 50%).

Quindi la mia domanda è: perché IPsec non può raggiungere una larghezza di banda maggiore?

I due host eseguono Debian Wheezy e Strongswan per IPsec.

performance bandwidth ipsec

— user50228
fonte

3

Dovrai assicurarti che la tua CPU abbia le aesistruzioni per decriptare meglio i pacchetti su entrambi i siti intel.co.jp/content/dam/www/public/us/en/documents/white-papers/… , e assicurati di essere rendere ipsec parallelo e usare la modalità tunnel + ESP - strongswan.org/docs/Steffen_Klassert_Parallelizing_IPsec.pdf . Questo è il modo migliore per ottenere prestazioni con questo protocollo.

Sfortunatamente ho processori i3 senza supporto AES-NI e lavoro in modalità tunnel tra i due host. Comprendo come entrambi i tuoi consigli aumenterebbero la larghezza di banda nel caso in cui una CPU fosse al 100% di utilizzo. L'uso di AES-NI consentirebbe l'elaborazione di più pacchetti e aumenterebbe il BW. Ma qui la CPU non sembra essere il fattore limitante.

— user50228

3

Hmm, questo è interessante. Sospetto che qualcosa nel kernel stia rallentando le cose. Ti dispiacerebbe condividere la tua configurazione ipsec? Vorrei strumentare una VM e vedere quali risultati otterrò con impostazioni diverse.

— Lmwangi,

1

Ci sono davvero molti fattori che vanno in questo. La scheda NIC colpisce più parti del tabellone di quanto tu possa immaginare. Qualsiasi set se le istruzioni possono attraversare il filo e colpire una parte del sistema di guida e abbassare il collo della bottiglia. Puoi prendere un single core 1200mhz singleboard e mettere a punto l'hardware per far saltare le porte e quad core 3600mhz. Questa è veramente una domanda specifica per l'hardware.

Come lo fanno? con qualcosa di simile a questo http://www.ixiacom.com/products/ixn2x Questo è il dispositivo da $ 165k "Ti romperò". vale a dire 2 concerti erronei in una pipe da 1 gig. Una volta che inizi a battere il sistema e a rompere le cose, il collo della bottiglia "si rivelerà da solo". Migliora le tue abilità nel GDB!

Ogni sistema ha un metodo diverso per risolvere il problema. Alcune schede hanno limiti tecnologici che possono limitarti.

La risposta è ambigua perché la soluzione è ambigua. Posso pensare a 20 diverse possibilità dalla parte superiore della mia testa, incluso il paging che può variare da una versione del sistema operativo a versione.

— chiodo senza testa
fonte

0

Mi chiedo se ciò sia dovuto al fatto che attese o dormi artificiali sono stati inseriti nella criptovaluta. Probabilmente non è imo, ma ...

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

Non potrei postarlo come commento, sarebbe stato più adatto in quel modo.

— Raymond Bannan
fonte

0

Può darsi che in qualsiasi momento specifico solo uno dei due core sia saturo, ma in media sembra che siano entrambi a circa il 50% (perché il kernel assegna casualmente un processo IPsec a thread singolo a entrambi i core; tuttavia per quanto ho notato che Linux (a differenza di Windows) di solito cerca di mantenere un thread sullo stesso core).

In alcuni brevi periodi IPSec potrebbe attendere anche la rete che, in combinazione con una velocità di trasferimento lenta, significherebbe un buffer insufficiente.

Anche la compressione (se presente) e l'overhead del protocollo possono influire sui test.

— mik
fonte