Comment dépanner les performances de transfert d'un routeur/pare-feu Linux avec Intel 10 Gbe ?

Il est vraiment étrange que vous n'obteniez que 1 Gbps de performance de routage (même si le filtrage difficile signifie généralement 2 copies de l'espace noyau pour le même périphérique, probablement 4x pour le routage) - il y a eu un post de LKML il y a un an qui indiquait que vous pouviez obtenir 120Gbps de performance de routage sur la série 2.6.3X avec ixgbe des appareils. J'utilise principalement des cartes réseau Intel 10GbE et j'obtiens généralement 1000MByte/s+ avec iperf sur une infrastructure commutée.

Tout d'abord, vous devez vérifier les performances du système pour un simple TCP avec quelque chose comme iperf entre vos points d'extrémité. Cela devrait vous permettre d'obtenir une base de référence. Rappelez-vous que beaucoup de choses entrent en jeu si vous avez besoin d'une vitesse de 10 Gbps. Sur les plates-formes antérieures à Nehalem, cette vitesse est même impossible à atteindre. La charge du système doit également correspondre à la configuration NUMA et les cartes d'interface réseau doivent être connectées au même complexe PCI (ce qui est important si vous êtes bloqué à moins de 8 Gbps). La distribution source ixgbe a un IRQ pinning script (qui désactive également des choses comme l'économie d'énergie et l'irqbalancer qui ne fera qu'endommager les caches et n'est pas conscient de la topologie) qui devrait répartir les files d'attente RX-TX de manière égale sur tous les cœurs (je ne l'ai pas vérifié depuis un moment).

En ce qui concerne votre question sur les délais, vous avez besoin d'un noyau compilé avec un support de profilage et un profileur au niveau du système tel que oprofile .

Avant d'activer le filtrage de paquets ou le routage et d'afficher ces informations, il convient de régler les problèmes de performance entre les points d'accès avant d'activer le filtrage de paquets ou le routage.

Il y a plusieurs mois, j'ai consacré beaucoup d'efforts à l'optimisation de Linux pour le routage Gigabit à vitesse filaire avec de nombreux petits paquets. C'était pour un équilibreur de charge (IPVS) et non pour un pare-feu NAT. Voici quelques conseils basés sur cette expérience.

• Mettre à jour le noyau Linux vers au moins 2.6.30 (nous avons eu besoin d'une mise à jour du pilote Broadcom bnx2)
• Utiliser ifconfig pour vérifier si l'interface présente des erreurs/des chutes/etc.
• Téléchargez et compilez la dernière version d'ethtool pour vous assurer qu'il supporte entièrement le pilote de votre carte réseau.
• Utilisez ethtool pour obtenir des statistiques plus détaillées.
• Utiliser ethool pour ajuster les paramètres de coalescence, NAPI, etc. afin de minimiser les interruptions.
• Regardez irqbalance pour vous assurer qu'ils sont équilibrés entre les cœurs du processeur.
• Regardez les threads du noyau comme ksoftirqd... utilisent-ils beaucoup de CPU ?
• Désactivez COMPLETEMENT iptables en déchargeant les modules du noyau avec rmmod. En particulier, NAT et conntrack peuvent avoir un impact négatif énorme, même si vous avez nettoyé toutes les règles et que les chaînes sont vides. J'ai vu une énorme augmentation des performances en faisant cela. Vous avez mentionné qu'il s'agit d'un pare-feu, mais je déchargerais quand même temporairement les modules NAT et conntrack pour voir si cela fait une différence.

Je n'ai pas encore vu de ventilation du temps passé par fonction de mise en réseau du noyau, comme la commutation, le routage, le pare-feu ou autre.

Iptables est un pare-feu efficace pour les systèmes Linux. Il peut gérer une grande quantité de trafic sans devenir un goulot d'étranglement si vous avez écrit un bon jeu de règles.

Une chose que vous pouvez faire est de désactiver iptables en supprimant toutes les règles et en définissant la valeur par défaut. FORWARD politique de ACCEPT . De cette façon, vous pouvez éliminer toute préoccupation concernant votre implémentation d'iptables. Ensuite, vous pouvez examiner le pilote réseau et essayer de déboguer le problème s'il persiste.

A titre de conseil, soyez prudent et ne désactivez pas iptables sur une machine accessible au public à moins que vous ne sachiez ce que vous faites.

La performance du pour unidirectionnel peut être due à des problèmes avec la segmentation tcp offload et d'autres paramètres sur le NIC. Ce problème peut être détecté dans de nombreux cas, par exemple lorsque le trafic d'une VM ou d'un VPN passe par une carte réseau physique. Il est facile de le désactiver à l'aide d'ethtool et de vérifier les performances, cela vaut donc la peine d'essayer (assurez-vous de le désactiver sur les deux points d'extrémité pour le test).

/usr/sbin/ethtool -K eth0 tso off
/usr/sbin/ethtool -K eth0 lro off

Voici un peu plus de détails :

http://www.peerwisdom.org/2013/04/03/large-send-offload-and-network-performance/ https://social.technet.microsoft.com/Forums/windowsserver/en-US/bdc40358-45c8-4c4b-883b-a695f382e01a/very-slow-network-performance-with-intel-nic-when-tcp-large-send-offload-is-enabled?forum=winserverhyperv