ASIC vs routage / commutation à usage général x86

14

Les administrateurs système essaient souvent de me convaincre que les OS x86 à usage général peuvent fonctionner aussi bien que les routeurs avec des processeurs à faible MHz et du silicium dédié (c'est-à-dire des ASIC) à des débits de ligne de 1 Gbit / s. Cette réflexion se poursuit dans le domaine SDN, comme les commutateurs virtuels dans VMWare.

Je pense que je comprends intuitivement les différences entre les avantages des ASIC vs x86 dans la gestion du trafic en particulier en ce qui concerne les microrafales. Est-il correct de supposer que les ASIC pour les interfaces de routeur ou de commutateur surclasseront l'utilisation d'un processeur x86 pour tous les traitements de paquets qui souffriront grandement des interruptions du processeur? Je sais que le système d'exploitation (Windows, Linux ou spécialisé) contribue grandement aux performances du matériel à router ou à commuter également. Et je sais que les vitesses de bus x86 imposent des maximums théoriques à la commutation de la bande passante, en particulier lorsque les taux dépassent 1 Gbit / s.

  1. Comment la vitesse de commutation du Catalyst 6500 Sup2T ASIC, par exemple, se compare-t-elle aux vitesses de commutation x86 réalistes trouvées sur les OS généraux ou les SDN?

  2. Comment la vitesse de commutation Cisco 7200VXR-NPE-G2, par exemple, se compare-t-elle à la même ...

  3. Comment les latences de routeur ou de commutateur typiques se comparent-elles aux systèmes d'exploitation généraux exécutant la même fonction?

REMARQUE: je ne veux pas entendre les avantages du placement de commutateur virtuel ou leur rôle au sein d'un réseau virtuel et physique. Je ne veux pas non plus débattre des avantages de SDN pour le délai de déploiement des applications.

erreur générale de réseau
la source

Réponses:

19

Est-il correct de supposer que les ASIC pour les interfaces de routeur ou de commutateur surclasseront l'utilisation d'un processeur x86 pour tous les traitements de paquets qui souffriront grandement des interruptions du processeur?

Il est difficile de dire précisément si les interruptions sont une limitation, car nous ne nommons pas de modèles spécifiques de CPU, de système d'exploitation ou de routeur dans cette partie de votre question. Dans l'ensemble, c'est une généralisation sûre que les processeurs à usage général ne peuvent pas toucher les performances de commutation de paquets d'un ASIC bien conçu. Quand je parle de performances, je parle de métriques RFC 2544 , telles que le taux de transfert sans perte de paquets par seconde (NDR), le débit et la latence.

Cela ne veut pas dire qu'il n'y a pas de place pour un routeur basé sur le processeur; juste que nos expériences de vie nous disent qu'un CPU ne peut pas changer de paquets aussi rapidement qu'un ASIC ou un FPGA. Ma conclusion selon laquelle les ASIC / FPGA sont plus rapides qu'un processeur multicœur semble être renforcée par ce Q&A sur Electronics.SE .

Performances du bus PCI

Je sais que les vitesses de bus x86 imposent des maximums théoriques à la commutation de la bande passante, en particulier lorsque les taux dépassent 1 Gbit / s.

Je ne sais pas à quelles restrictions de bus vous faites référence ici, mais les informations dont vous disposez pourraient être quelque peu dépassées. Le bus PCI Express utilisé dans la plupart des systèmes évolue bien au-dessus de 10 Gbit / s de nos jours.

PCIe 2.0 utilise un schéma de codage 8b / 10b qui l'a pénalisé d'environ 20% pour la surcharge de codage de la voie PCI; avant cette pénalité d'encodage, PCIe 2.0 fournit 4 Gbit / s de bande passante brute par voie. Cependant, même avec la pénalité de 20% 8b / 10b, PCIe 2.0 x8 (8 voies PCIe) dépasse 25 Gbps; ainsi, vous pouvez facilement exécuter un seul adaptateur 10GE à un débit de ligne bidirectionnel sur une carte PCIe 2.0 x8.

PCIe 3.0 (utilisé dans les chipsets Intel Ivy Bridge) utilise un codage 128b / 130b, ce qui améliore considérablement l'efficacité du bus PCI et double la bande passante par voie. Ainsi, une carte PCIe 3.0 x8 pourrait fournir 63 Gbit / s (8,0 * 8 * 128/132). Ce n'est rien pour éternuer; vous pouvez emballer en toute sécurité deux 10GE à débit linéaire sur une seule colonne montante avec ces taux de performance.

Performances Cisco vs Vyatta

Avertissement: j'utilise du matériel marketing fourni par le fournisseur pour toutes les comparaisons ...

  1. Comment la vitesse de commutation du Catalyst 6500 Sup2T ASIC, par exemple, se compare-t-elle aux vitesses de commutation x86 réalistes trouvées sur les OS généraux ou les SDN?

C'est un peu difficile car nous allons comparer un système de commutation entièrement distribué (Sup2T) à un système de commutation centralisé (Vyatta), alors soyez prudent dans l'interprétation des résultats.

  • Sup2T peut transmettre jusqu'à 60 Mpps de taux de non-chute avec les fonctionnalités activées . Référence: Livre blanc sur l'architecture Catalyst 6500 Sup2T . Notez qu'il s'agit simplement d'un système Sup2T nu sans carte de transfert distribué (DFC). Note 1
  • J'ai trouvé les résultats des tests RFC 2544 pour le transfert Vyatta 5600 à un taux de non-chute jusqu'à 20,58 Mpps, et 70 Mpps si vous pouvez accepter quelques gouttes. Le débit NDR était de 72 Gbps. Référence: Vyatta 5600 vRouter Performance Test (SDN Central) . L'enregistrement SDN Central est requis pour voir le rapport complet.
  1. Comment la vitesse de commutation Cisco 7200VXR-NPE-G2, par exemple, se compare-t-elle à la même ...

Le Vyatta souffle un NPE-G2 hors de l'eau, en termes de performances; le NPE-G2 peut faire jusqu'à 2Mpps basé sur la fiche technique de Cisco NPE-G2 . Ce n'est pas vraiment une comparaison équitable, étant donné l'âge du NPE-G2, par rapport à un tout nouveau système Intel 10-Core équipé de cartes 10GE.

Comment les latences de routeur ou de commutateur typiques se comparent-elles aux systèmes d'exploitation généraux exécutant la même fonction?

C’est une question fantastique. Ce document indique que Vyatta a des latences plus élevées, mais j'aimerais que ce type de test soit effectué contre les processeurs Intel E5.

Sommaire

Récapitulation d'une comparaison côte à côte de Sup2T par rapport au Brocade Vyatta 5600:

  • Sup2T: 60Mpps NDR IPv4 avec des fonctionnalités (telles que les ACL)
  • Vyatta et Intel E5: jusqu'à 20Mpps IPv4 NDR sans fonctionnalités , ou 70Mpps si vous pouvez accepter un petit nombre de gouttes.

Le Sup2T gagne toujours à mon avis, en particulier lorsque vous regardez ce que vous obtenez avec le Sup2T (échelle distribuée à 720Mpps, MPLS, d'innombrables MIB, commutation Layer2 et Layer3, etc ...).

Si vous ne vous souciez que des performances de commutation brutes, vous pouvez obtenir des performances respectables à partir d'un processeur x86. Cependant, dans les réseaux réels, il n'est pas souvent question de savoir qui a les meilleurs numéros de course de dragsters; la plupart des gens doivent se soucier des fonctionnalités (voir: Quand dois-je me concentrer sur chaque valeur pour l'évaluation du commutateur? ). Un facteur important à considérer est le nombre de fonctionnalités disponibles et leur intégration au reste de votre réseau.

Cela vaut également la peine d'examiner la faisabilité opérationnelle de l'utilisation de systèmes x86 dans votre entreprise. Je n'ai pas utilisé Brocade + Vyatta moi-même, mais ils pourraient faire un travail décent en créant de bonnes commandes d'exposition et en prenant en charge les crochets dans la boîte. S'ils prennent en charge suffisamment de fonctionnalités et que leur système évolue bien dans les réseaux réels , alors allez-y si c'est ce que vous aimez.

Cependant, si quelqu'un va bon marché et construit simplement une boîte Linux + bird/ quagga+ ACL + qos, je ne voudrais pas être le gars qui supporte cette solution. J'ai toujours soutenu que la communauté open-source faisait un excellent travail en innovant, mais la prise en charge de leurs systèmes pâlit par rapport aux fournisseurs de réseaux traditionnels (Arista / Cisco / Force10 / Juniper). Il suffit de regarder iptableset tcde voir à quel point vous pouvez créer une CLI compliquée. Je réponds de temps en temps aux questions de personnes qui regardent la sortie de ip link showou ifconfiget se perdent parce que les compteurs de paquets ne sont pas corrects; En général, les principaux fournisseurs de réseau font un bien meilleur travail pour tester leurs compteurs, par rapport à ce que je vois dans les pilotes NIC Linux.


Notes de fin :

Remarque 1 Personne qui se soucie des performances n'achèterait jamais un Sup2T et ne remplirait pas le châssis de DFC. Le Sup2T peut basculer à 60 Mpps, mais un châssis chargé avec des DFC évolue à 720 Mpps.

Remarque 2 Le test Vyatta a fonctionné sur un processeur Intel E5-2670v2 à 10 cœurs à 2,5 GHz par cœur; si nous comptons un seul cœur comme deux cœurs virtuels (c'est-à-dire l'hyper-threading), cela représente un total de 40 cœurs pour la commutation de paquets. Le Vyatta a été configuré avec des cartes réseau Intel x520-DA2 et a utilisé la version 3.2 de Brocade Vyatta.

Mike Pennington
la source
1
Savez-vous quelles étaient les tailles de cadre dans ces chiffres? Le résumé exécutif pour le Vyatta a dit qu'ils ont atteint 70Mpps avec des cadres 64B; la même taille de trame est-elle utilisée dans les tests Sup2T?
Ryan Foley
0

La série 7200 est déconseillée au profit de la série ASR car elle ne peut pas gérer la commutation multi-gigabit à débit de ligne. Les commutateurs Catalyst et Nexus ont un avantage de transfert sur un processeur à usage général SI la commutation de paquets reste en silicium. Si le trafic doit être commuté par le processus (c'est-à-dire qu'il doit être évalué sur le CPU plutôt que sur l'ASIC / FPGA), votre débit chute et la latence augmente. Pour cette raison, si vous avez besoin d'une commutation à haut débit, vous séparez le plan de transfert du plan de routage et optimisez pour conserver autant de commutations que possible en silicium.

Dans certains cas, vous verrez du silicium de commutation à usage spécial marié à un processeur à usage général (comme les commutateurs à boîte blanche destinés à utiliser Big Switch ou un autre SDN pour le haut de rack, la distribution ou la superposition), et dans ces cas, vous pouvez voir le meilleur de tous les mondes (haut débit, commutation à faible latence; traitement haute puissance pour la détermination des itinéraires et des politiques; intégration avec des cadres de gestion tels que Puppet ou Chef).

DTK
la source