Créer un switch réseau géré par Linux

 (blog.brixit.nl)
1 points par GN⁺ 2024-07-05 | 1 commentaires | Partager sur WhatsApp
  • Pour reproduire une architecture où Linux contrôle directement la puce de commutation, comme à l’intérieur d’un routeur grand public, l’auteur a conçu un PCB de switch gigabit basé sur le RTL8367S et l’a relié à DSA/switchdev
  • Le RTL8367S retenu est une puce de switch gigabit à 7 ports dont 5 intègrent un PHY ; au lieu d’utiliser un port CPU dédié, le port 0 est relié par câble réseau à l’Ethernet d’une carte Linux
  • Lors de la conception matérielle, les rails d’alimentation ont été simplifiés en 3,3 V et 1,1 V, et plusieurs voies de configuration ont été testées, comme les broches de boot, l’EEPROM, la flash SPI et le port série
  • Côté intégration Linux, il a fallu utiliser une carte PINE64 A64-lts, des options de noyau personnalisées et des modifications du Device Tree ; après le démarrage, lan1 à lan4 apparaissent sous eth0 comme des interfaces réseau locales
  • Cette approche s’intègre bien avec les outils existants comme le bridge Linux et ethtool, mais elle reste difficile à utiliser telle quelle sur un PC, un serveur ou une interface réseau USB en raison des contraintes liées au Device Tree et aux GPIO

Structure des switches gérés et de Linux DSA

  • Un switch géré classique permet de modifier la configuration et de consulter l’état des ports via une interface web, et les équipements plus coûteux offrent aussi des interfaces supplémentaires comme telnet ou une console série
  • Le switch à l’intérieur d’un routeur grand public peut lui aussi être vu comme une catégorie distincte de switch géré
    • Le routeur est un petit appareil Linux avec une puce de commutation intégrée
    • Un ou plusieurs ports sont reliés en interne au CPU, tandis que les autres sont exposés comme ports physiques
  • Les sous-systèmes DSA et switchdev de Linux permettent aux ports connectés au switch de se comporter comme de véritables ports réseau « locaux »
  • Entre le SoC du routeur et le switch, il faut une liaison comme SGMII ou RGMII ainsi qu’un bus de gestion comme SMI ou MDIO
  • Les switches du commerce n’exposent généralement pas à l’extérieur les liaisons nécessaires, ce qui rend ce mode de contrôle difficile à mettre en œuvre

Fabrication d’une carte de switch basée sur le RTL8367S

  • Le switch gigabit conçu sur mesure utilise une puce Realtek RTL8367S
    • C’est une puce de switch gigabit 5 ports très répandue
    • En réalité, elle suit une architecture à 7 ports : 5 ports avec PHY intégré et 2 ports destinés à la connexion CPU
  • La fiche technique ne donnant que des informations minimales, l’auteur s’est aussi appuyé sur les schémas d’appareils utilisant des puces Realtek proches et sur de la documentation de conception Ethernet
  • Au départ, il semblait falloir environ 7 réseaux d’alimentation, mais comme les plages de tension se recoupaient, il a été possible d’utiliser uniquement des régulateurs 3,3 V et 1,1 V
  • Comme Linux switchdev n’exige pas que la liaison CPU passe forcément par un port CPU dédié, cette conception relie le port 0 à la carte Linux via un câble
    • Du point de vue du pilote switchdev, cela ressemble à une liaison sans PHY Ethernet intermédiaire

Configuration de la puce et tâtonnements sur le PCB

  • Le RTL8367S propose plusieurs voies de configuration, mais la fiche technique seule ne permettait pas de déterminer facilement la configuration minimale nécessaire pour le faire fonctionner comme un simple dumb switch
    • Les 8 broches lues au démarrage sont partagées avec les broches des LED de ports
    • Le bus i2c peut servir à connecter une EEPROM, mais il partage ses broches avec le bus SMI requis
    • Le bus SPI peut accueillir une flash NOR pour stocker les registres de configuration ou le firmware du cœur 8051 intégré
    • Le port série ne semblait pas pouvoir fonctionner sans firmware 8051
  • La première carte a été commandée telle quelle, puis l’auteur a modifié des liaisons à la soudure pour identifier les conditions de fonctionnement
    • Une empreinte pour puce flash avait été prévue, mais elle n’a finalement pas été nécessaire
    • Des cavaliers de soudure ont été ajoutés sur les broches de configuration
    • Les LED ont été exclues, car il était difficile de les rendre configurables
  • Les documents de conception Ethernet gigabit insistent sur le contrôle d’impédance et l’appairage précis des longueurs, mais les switches bon marché observés ne semblaient pas suivre ces règles de manière si stricte
  • Le point jugé plus important était l’appariement du skew entre les paires réseau
    • L’auteur a estimé qu’aligner la longueur totale des 4 paires n’apportait pas grand-chose
    • Même à l’intérieur d’un câble réseau, les 4 paires ont déjà des longueurs sensiblement différentes à cause de pas de torsade différents
  • Sur les premières révisions de la carte, une erreur de traitement des condensateurs de référence à la masse sur les prises médianes du transformateur côté switch empêchait Ethernet de fonctionner
    • Pour tester, une petite piste a été coupée afin de supprimer le court-circuit vers la masse
    • Dans cette configuration de test, cela fonctionnait même avec la prise médiane laissée flottante
    • Le condensateur correspondant a été ajouté à la conception finale

Switch finalisé et connexion à Linux

  • La carte terminée est un switch gigabit à la forme un peu particulière
    • 4 ports sont orientés dans un sens
    • 1 port est orienté dans l’autre et sert à la connexion avec la carte Linux
    • L’alimentation est fournie via un connecteur à broches de 2,54 mm
    • Une empreinte de connecteur USB Type-C a aussi été ajoutée pour alimenter la carte sans fil DuPont
  • La carte Linux choisie pour les tests est une PINE64 A64-lts
    • La position de ses connecteurs correspondait à peu près à la disposition recherchée
    • Comme des modifications du Device Tree étaient nécessaires, il était important d’utiliser une plateforme autre que x86
  • Le noyau a été recompilé, les modules liés au switch n’étant généralement pas activés par défaut
    • CONFIG_NET_DSA : Distributed Switch Architecture
    • CONFIG_NET_DSA_TAG_RTL8_4 : marquage des ports pour les puces de switch Realtek
    • CONFIG_NET_SWITCHDEV : système de pilotes de switch réseau
    • CONFIG_NET_DSA_REALTEK, CONFIG_NET_DSA_REALTEK_SMI, CONFIG_NET_DSA_REALTEK_RTL8365MB : pilotes de la puce de switch elle-même
  • Au lieu de charger un overlay Device Tree via U-Boot, l’auteur a directement modifié le Device Tree de la carte A64-lts
    • La chaîne de compatibilité realtek,rtl8365rb est utilisée pour charger le pilote
    • Ce pilote prend en charge plusieurs puces de switch Realtek, dont le RTL8367S utilisé ici
    • La définition du port CPU dans l’exemple de la documentation a été supprimée au profit de 5 ports de switch ordinaires
  • port@0 est le port orienté vers l’arrière, relié à &emac sur l’A64-lts
    • Les autres ports sont reliés chacun à un PHY interne de la puce
    • En haut du Device Tree, 3 GPIO reliés à SDA/SCL et Reset sont définis

Outils réseau Linux et limites

  • Après le démarrage, Linux affiche l’interface eth0 classique ainsi que les interfaces de ports du switch définies dans le Device Tree
    • lan1@eth0
    • lan2@eth0
    • lan3@eth0
    • lan4@eth0
  • Pour un fonctionnement réel, il faut activer eth0 avec ip link set eth0 up ainsi que chacune des interfaces lan
  • L’intégration avec les outils réseau Linux standard est naturelle
    • Si plusieurs ports lan sont placés dans un bridge Linux, switchdev fait traiter ce bridging directement à l’intérieur de la puce de commutation
    • Linux n’a donc pas besoin de transférer lui-même ce trafic
    • ethtool lan3 permet de consulter les informations de lien
    • ethtool -S lan3 renvoie des informations d’état standard, y compris sur les paquets entièrement traités par le switch
  • En revanche, les contraintes restent importantes pour une utilisation dans un environnement courant
    • Il faut soit fabriquer soi-même un switch réseau, soit ouvrir un switch existant pour retrouver les liaisons nécessaires
    • Un PC ou un serveur classique n’utilise pas une configuration fondée sur le Device Tree, et ne donne généralement pas non plus accès à des GPIO pilotés par le noyau
    • Les interfaces réseau USB sont difficiles à utiliser de cette manière, faute de handle de nœud Device Tree permettant de désigner un port conduit
  • Certaines de ces limites peuvent peut-être être contournées, mais il faudrait davantage de documentation sur les moyens de charger switchdev hors d’un environnement ARM ou avec des périphériques USB spéciaux exposant des GPIO

À lire aussi

1 commentaires

 
GN⁺ 2024-07-05
Commentaires sur Hacker News
  • On peut voir les choses comme ça : « un switch réseau est un appareil simple, les paquets entrent et sortent, mais heureusement des gens ont trouvé le moyen de compliquer cela en inventant le switch manageable » ; mais les switchs coûteux embarquent en réalité des ASIC assez sophistiqués
    Par exemple, une vieille paire de switchs Dell OS9 est un équipement empilable d’ancienne génération avec 48 ports 10 Gb/s et 4 ports optiques QSFP+ 40 Gb/s, et chaque switch peut traiter jusqu’à 1,28 Tb/s
    On peut aujourd’hui en trouver autour de 1 800 £ TVA comprise, et ils peuvent servir presque éternellement
    Ce genre d’essai est intéressant, mais il faut aussi garder à l’esprit que des acteurs comme Netgear vendent des switchs 8 ports 1 Gb avec PoE sur tous les ports pour environ 125 £
    Si l’on évalue la viabilité économique du projet en valorisant le temps entre 20 et 50 £ de l’heure, un produit du commerce sera sans doute le bon choix ; mais si l’objectif est le projet lui-même, le prix n’a pas d’importance
    (1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
    (2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
    • J’ai déjà travaillé avec ce type d’ASIC de switch de Broadcom ; ce n’était pas du 40 Gb mais plutôt du 4x10 Gbps + 24x1 Gbps + du PCIe pour le CPU
      Le prix de l’ASIC était dans l’ordre de grandeur attendu ; je ne connais pas le chiffre exact, mais c’était probablement de l’ordre de quelques centaines de dollars
      La documentation de l’interface logicielle était très médiocre, et comme il s’agissait d’une bibliothèque prenant en charge tous les ASIC de switch Broadcom, on se retrouvait avec un fichier .a de plusieurs centaines de Mo rempli de fonctions qui renvoyaient juste une erreur « non pris en charge sur cet appareil », sans moyen de le savoir avant de les appeler soi-même
  • Projet intéressant
    Pour un usage plus simple, on peut généralement trouver des routeurs compatibles OpenWRT utilisant des puces de switch manageables, et OpenWRT fournit une bonne interface pour configurer les VLAN et diverses options
    • Aujourd’hui, OpenWRT peut aussi s’installer sur certains switchs comme la série Zyxel GS1900
      En revanche, la prise en charge de fonctions comme le PoE ou les ports 10Gb/SFP+ peut être limitée, et l’état actuel n’est pas très clair
  • La première fois que j’ai vu une utilisation créative d’un switch de la famille RTL83, c’était ici : https://spritesmods.com/?art=rtl8366sb ; il y a ensuite eu d’autres cas similaires
    Mais ce projet semble être le premier switch manageable fait maison que j’aie vu, plutôt qu’une approche consistant à « greffer un cerveau externe sur un switch non manageable »
    • Oui, c’est bien le légendaire sprite_tm ; j’avais lu ce billet à l’époque où j’écrivais moi-même un firmware Raspberry Pi pour gérer un switch via USB
  • Je me demande quels sont les avantages par rapport à une approche consistant à brancher plusieurs adaptateurs gigabit sur une machine Linux et à les mettre tous dans un bridge
    J’imagine que les performances sont meilleures côté matériel, mais je ne sais pas s’il y a eu des tests montrant l’écart réel
    • La différence se jouera grosso modo sur le débit, la latence, la consommation électrique et la combinaison de fonctionnalités
      Avec des adaptateurs USB, on atteint vite la bande passante maximale, car l’USB est un bus partagé à bien des égards, et les données doivent en plus remonter jusqu’au CPU avant de ressortir
      Avec de la commutation logicielle, on ajoute le temps nécessaire pour traiter chaque paquet et le renvoyer au bon endroit, auquel s’ajoute la latence propre aux interfaces
      Chaque adaptateur a son propre PHY réseau et son propre matériel, ce qui augmente la consommation, et avec le traitement supplémentaire la dépense énergétique grimpe encore
      On profite aussi moins du hardware offloading et d’autres optimisations de performance, si bien que l’ensemble du système participe davantage au déplacement des paquets
      Côté fonctionnalités, tout dépend du matériel choisi, et certains adaptateurs USB gigabit bon marché géraient mal des fonctions comme les VLAN
      À l’inverse, avec plusieurs cartes PCIe, les fonctionnalités peuvent être bien meilleures, mais à partir de là on se rapproche davantage du routage que de la commutation
    • Si l’essentiel du trafic relève de la commutation, cette approche est plus efficace ; si la majorité du trafic doit être routée, plusieurs adaptateurs séparés seront plus efficaces
    • Comme l’ont dit d’autres réponses, cette approche a de fortes chances de consommer moins d’énergie, et la latence à travers le switch sera aussi plus faible qu’avec un bridge logiciel
      Même si l’OS hôte tombe, la commutation peut continuer à fonctionner ; en combinant watchdog et mécanismes de reprise, on peut obtenir un système plus disponible qu’un bridge logiciel, même si certaines fonctions sont brièvement indisponibles
      Bien sûr, cela suppose que la puce de switch elle-même ne plante pas et ne se bloque pas
      Selon l’objectif, si l’on veut inspecter tout le trafic traversant le switch, 4 interfaces restent clairement préférables
      Si un switch basé sur l’hôte doit aussi beaucoup communiquer, 4 interfaces offrent 4 Gbps côté hôte, ce qui est préférable à un seul lien 1 Gbps
      On trouve sur eBay des cartes quad 1G d’occasion issues du monde de l’entreprise pour moins de 15 $, et ma préférence va à la Silicom quad bypass 1g PEG4BPI-SD
      La fonction de bypass est amusante et atypique, ce qui les rend moins chères, mais en général, une fois configurées comme une « NIC standard », on peut les brancher ailleurs sans gros problème
      Les premiers modèles sont plus pénibles à utiliser, car le fournisseur et le sous-fournisseur du PCI ID sont tous deux identifiés comme Silicom, tandis que les cartes -SD ont un vendor ID Intel et un subvendor Silicom, donc le pilote standard s’y attache
      Les ports 4x10G demandent davantage de gestion, et selon le système hôte, le débit du bridging logiciel peut ne pas suffire
      Les cartes quad port 10G sont difficiles à trouver, mais les modèles 2x10G peuvent se trouver à un prix raisonnable avec un peu de patience
    • Dans cette approche, le CPU se retrouve dans le chemin de données
      Un switch commute les paquets dans l’ASIC et non dans le CPU ; les performances dépendent donc du CPU, et ce n’est généralement pas une manière très efficace d’utiliser les ressources de calcul disponibles
    • À des vitesses aussi faibles et avec aussi peu de ports, des circuits de commutation matériels ne sont pas indispensables
      Cela dit, si l’on fait abstraction de l’effort de conception et de fabrication, le coût matériel total peut rester sous les 100 $, donc potentiellement moins cher qu’un ordinateur doté de plusieurs interfaces
      Il reste que le réseau à 1 Gb/s est déjà assez ancien

Il est possible de fabriquer un switch réseau administrable plus grand et plus rapide pour un peu plus de 200 $ uniquement avec des composants du commerce
Par exemple, avec un Odroid H4+ disposant de 2 ports et une carte d’extension M.2 ajoutant 4 ports Ethernet, on peut construire un switch 2,5 Gb/s à 6 ports
Une autre approche consiste à utiliser un mini-PC avec un CPU N100 et 4 ports 2,5 Gb/s, que plusieurs fabricants chinois proposent dans cette gamme de prix
Un mini-PC similaire avec 6 ports 2,5 Gb/s est un peu plus cher et peut dépasser légèrement les 300 $

  • Je me demande ce qu’est devenu OpenFlow
    Cela semble parfaitement adapté à ce type d’appareil, mais j’ai perdu l’intérêt faute de pouvoir monter un environnement de labo
    • Il serait possible de créer un client OpenFlow utilisant cette puce de switch comme plan de données, mais ce ne serait peut-être pas idéal, car la plupart des fonctionnalités qu’OpenFlow cherche à utiliser risquent de ne pas pouvoir exploiter le fast path matériel relativement limité
    • OpenFlow était une solution légèrement inadaptée au problème ; les solutions plus appropriées sont plutôt switchdev ou SAI
    • D’après ce que je sais, OpenFlow a été conçu de manière trop générique, s’adaptait mal au matériel réel, et l’abstraction finissait donc par fuir de partout
  • D’après ce que j’ai lu, pour fabriquer un switch 10 Gbit/s, il est très difficile d’éviter de dépendre de certains blobs binaires, car les fabricants de puces d’accélération ne prennent pas en charge les pilotes ouverts
    Faire la commutation sur le CPU serait trop coûteux, donc ce type de puce me paraît nécessaire
    • Le Marvell 88E6393X fonctionne en mode « simple/gestion externe » sans firmware
      Il peut être utilisé avec Linux switchdev, comme l’appareil décrit dans cet article
  • Je me demande s’il prend en charge rSTP
    • Apparemment non ; il semble ne prendre en charge que le STP classique et probablement le MSTP
  • Sans mauvaise intention, et je me trompe peut-être sur quelque chose
    Le diagramme en blocs de RouterBoard a été utilisé comme modèle pour montrer comment le switch matériel se connecte au reste du système, mais l’argumentation semble ensuite dériver vers l’idée que ces appareils sont ingérables ou difficiles à exploiter
    Je me demande si quelqu’un ici a déjà essayé de se procurer un RouterBoard
    On devrait pouvoir compiler OpenWRT pour la plupart des RouterBoard, et le 2011 doit être assez courant même sur le marché de l’occasion
    La meilleure question est de savoir si l’objectif était dès le départ de tout fabriquer soi-même, ou si l’idée d’utiliser le matériel de quelqu’un d’autre a été écartée pour une raison précise
    • J’ai plusieurs appareils de ce type ; ils sont excellents pour leur usage d’origine, mais pas vraiment pour faire tourner du logiciel personnalisé
      J’ai repris le diagramme du RB2011 parce que je le trouve simple et bien expliqué
      Techniquement, le RB1100AHx4, qui utilise la même puce de switch, serait un meilleur exemple, mais c’est encore plus trompeur, car il prétend qu’en utilisant les deux ports CPU et en ignorant la surcharge d’encodage, 2 liens à 1,25 Gb/s équivalent à un lien à 2,5 Gb/s
      La raison pour laquelle je l’ai fabriqué moi-même dès le départ, c’est que le coût est raisonnable et que cet appareil doit s’intégrer dans la boîte d’enregistrement vidéo de FOSDEM
      Il faut résoudre plusieurs problèmes propres à cette conception, notamment exposer 4 ports réseau sur le panneau avant du boîtier tout en les reliant aussi au SBC interne
      Il n’y a pas vraiment assez de place dans le boîtier pour ajouter un passage vers le switch sans câble de boucle externe pour le SBC, et avec un switch simple, il serait en plus impossible de faire de la supervision du système
      Comme nous construisons un certain nombre de ces boîtiers, cela devient une solution raisonnable, et comme c’est du travail bénévole, c’est faisable si l’on ignore le temps de conception
    • Le RouterBoard RB2011 est bloqué sur l’ancienne version OpenWrt 19.07 : https://openwrt.org/toh/mikrotik/rb2011
      Le problème semble lié en partie à la NAND et, si je me souviens bien, à une différence par rapport aux autres RouterBoard pris en charge
      Quelqu’un a proposé une nouvelle solution à ce problème, mais elle n’a pas encore été intégrée : https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... et d’autres discussions