Brevet FR3011153A1 — publié le 20150327

L'invention concerne les équipements de réseau tels que ceux utilisés dans les installations à grande échelle telles que grappes de serveurs, réseaux de télécommunications, routeurs... mises en oeuvre par les hébergeurs web, les fournisseurs d'accès Internet, les centres de stockage et de traitement de données de type datacenter, etc. L'invention concerne plus particulièrement, parmi ces équipements, les commutateurs réseau ou "switches" Ethernet, qui sont des dispositifs destinés à assurer sélectivement l'interconnexion entre des ports dits "ports réseau", typiquement jusqu'à 24 ou 48 ports réseau sur un même équi- pement, reliés à des serveurs utilisateurs, ainsi que des fonctions de su- pervision et de filtrage du trafic sur ces ports réseau. Un tel commutateur est classiquement constitué de deux unités fonctionnelles, à savoir un "processeur de paquets" et une unité de gestion dite "CPU de management". Le processeur de paquets est essentiellement un composant matériel, généralement un ASIC, dédié au routage interne à grande vitesse des paquets entre les ports réseau. Il dispose également de quelques ports, généralement un ou deux, dédiés à une liaison dite "uplink" vers le réseau d'infrastructure ou coeur de réseau, c'est-à-dire le réseau propre au ges- tionnaire de l'équipement, par opposition aux réseaux des serveurs utilisa- teurs, clients de ce gestionnaire. Le CPU de management, quant à lui, assure le contrôle du processeur de paquets (notamment la définition du schéma d'interconnexion) et l'application de règles de filtrage sur certains paquets définis, qu'il identifie pour leur appliquer un traitement particulier, par exemple pour les intercepter ou les dupliquer. Le logiciel du CPU de management est configuré à distance par l'administrateur du réseau au moyen de commandes indiquant à ce CPU la manière dont il devra contrôler le processeur de paquets. L'architecture conventionnelle que l'on vient de décrire est efficace pour implémenter les fonctions requises du switch, mais elle n'est pas pour au- tant dépourvue d'inconvénients. En premier lieu, la configuration à distance du CPU de management met typiquement en oeuvre un réseau spécifique, indépendant du processeur de paquets. Le CPU de management est relié à ce réseau spécifique par un port réseau également spécifique, de même type que les ports uplink du processeur de paquets, port qui ne peut pas être utilisé à d'autres fins. Il en résulte un surcoût architectural et une complexité accrue, qui peuvent être des inconvénients sérieux notamment lorsqu'augmente la densité des composants du switch et qu'il est nécessaire de disposer dans une installation donnée d'un très grand nombre de tels switches administrés concurremment. En second lieu, pour la seconde fonction du CPU de management qui est l'analyse des paquets et l'application des règles de filtrage, ces fonctionnalités doivent être implémentées par un logiciel spécifique au processeur de paquets, sans possibilité de mise en oeuvre de modules applicatifs standards préexistants. Cela tient au fait que ces modules standards sont conçus pour analyser et traiter des paquets reçus sur une interface réseau elle-même standard, qui est absente du CPU de management. En effet, les ports réseau recevant les données à analyser sont situés sur le processeur de paquets, lui-même relié au CPU de management par une liaison de contrôle qui n'est pas un lien réseau ; d'autre part, le processeur de paquets est une entité essentiellement matérielle qui ne contient pas de système d'exploitation susceptible de faire tourner des modules applicatifs standards. En d'autres termes, l'architecture traditionnelle, qui ne permet pas à cette interface réseau d'être présente sur le CPU de mana- gement, interdit d'utiliser localement des outils d'analyse standards, éprouvés et peu coûteux à mettre en oeuvre. De tels outils ne pourront être mis en oeuvre qu'à distance, au sein du réseau de gestion, donc avec un surcoût de trafic et de complexité architecturale et logicielle. Le but de l'invention est de remédier à ces limitations et inconvénients d'une architecture conventionnelle de switch Ethernet, en proposant une architecture originale : - qui ne recoure pas à un réseau de gestion distinct pour la configuration du CPU de management ; - qui de ce fait n'occupe pas de port uplink spécifique, le ou les ports de ce type existant sur le switch pouvant être entièrement utilisés à d'autres fins ; et - qui soit compatible avec des logiciels applicatifs standards, implantables au sein même du CPU de management et exécutés localement sous le contrôle du système d'exploitation de ce dernier. L'idée de base de l'invention consiste à présenter, au système d'exploitation implémenté sur le CPU de management, le lien de contrôle entre le processeur de paquets et le CPU de management sous la forme d'une interface réseau standard virtuelle. Le lien de contrôle est alors dissocié logiquement en deux chemins, à sa- voir: - un chemin de configuration, pour paramétrer le processeur de paquets, et - un chemin de données, pour la transmission des paquets à analyser et des résultats des actions de filtrage en retour. Pour la gestion de ces deux chemins, le système d'exploitation du CPU de management contient un composant logiciel qui route les informations (données de configuration, paquets à analyser, etc.) selon le cas soit vers l'application qui définit la manière de piloter le processeur de paquets, soit vers une ou plusieurs interfaces réseau virtuelles. Les interfaces réseau virtuelles donnent au CPU de management la faculté de fournir les données circulant dans le switch à n'importe quel module applicatif utilitaire standard de la même manière que si ces données provenaient directement de l'un des ports du processeur de paquets, de fa- çon transparente avec un interfaçage identique. Au surplus et de façon remarquable, la configuration à distance du switch pourra être opérée par le réseau d'infrastructure directement via le port uplink non spécifique du processeur de paquets, ce qui évite le recours à un réseau spécifique et à un port propre, occupé uniquement à cette fin. Plus précisément, l'invention s'applique à un commutateur réseau Ether- net comprenant, de manière en elle-même connue, un processeur de paquets, une unité de gestion à processeur couplée au processeur de paquets, et une liaison de contrôle établie entre le processeur de paquets et l'unité de gestion pour l'échange bidirectionnel de données et d'informa- tions de contrôle et de configuration. Le processeur de paquets com- prend : une pluralité de premiers ports réseau aptes à être reliés à une pluralité correspondante de serveurs utilisateurs ; au moins un second port réseau apte à être relié à un réseau d'infrastructure ; une interface de liaison à une unité de gestion ; et des moyens d'interconnexion mutuelle des premiers et/ou seconds ports réseau en fonction d'informations de contrôle et de configuration reçues sur l'interface de liaison. L'unité de gestion, quant à elle, comprend : un système d'exploitation ; une application de pilotage du processeur de paquets apte à générer lesdites informations de contrôle et de configuration ; et une interface de liaison au processeur de paquets. De façon caractéristique de l'invention, l'unité de gestion est dépourvue de port réseau matériel dédié, relié au superviseur de gestion à distance du commutateur. Le commutateur est relié à ce superviseur de gestion à distance via le second port réseau du processeur de paquets. Le système d'exploitation de l'unité de gestion est apte à émuler au moins une inter- face réseau virtuelle et comprend en outre un composant logiciel sélecteur intercalé entre, d'une part, l'interface de liaison au processeur de paquets et, d'autre part, l'application de pilotage et les interfaces réseau virtuelles. La liaison de contrôle entre l'unité de gestion et le processeur de paquets comprend, d'une part, un chemin de configuration pour l'échange de données directement avec l'application de pilotage et, d'autre part, un chemin de données pour l'échange de données entre le processeur de paquets et les interfaces réseau virtuelles, ou bien entre le processeur de paquets et l'application de pilotage, sélectivement via le composant logi- ciel sélecteur. L'unité de gestion inclut avantageusement une ou plusieurs applications utilitaires aptes à échanger et à traiter des données via une liaison réseau, notamment des applications de type analyseurs de réseau, enregistreurs de trafic réseau, ou services réseau fournis aux serveurs utilisa- teurs. Ces applications utilitaires opèrent sous le contrôle du système d'exploitation et traitent des données échangées avec le processeur de paquets via les interfaces réseau virtuelles, le composant logiciel sélecteur et le chemin de données de la liaison de contrôle. 0 On va maintenant décrire un exemple de mise en oeuvre du dispositif de l'invention, en référence aux dessins annexés. La Figure 1 illustre une architecture de switch Ethernet selon l'état de la 35 technique. La Figure 2 est homologue de la Figure 1, pour une architecture de switch selon l'invention. 0 Sur la Figure 1, on a représenté l'architecture conventionnelle d'un com- mutateur réseau ou switch Ethernet 10, répartie entre un processeur de paquets 12 ("les bras" du switch) et une unité de gestion ou CPU de management 14 ("le cerveau" du switch). Le processeur de paquets 12 comporte une pluralité de ports réseau 16, typiquement 24 à 96 ports réseau reliés chacun à des serveurs utilisateurs 18 via des liaisons respectives 20 sur lesquelles transitent des données entre ces serveurs utilisateurs selon un schéma d'interconnexion prédéterminé, mis en oeuvre essentiellement par un composant d'interconnexion matérielle de type ASIC compatible avec le débit élevé des don- nées sur les liaisons 20. Le processeur de paquets 12 dispose également d'un nombre limité, généralement un ou deux ports réseau spécifiques dits "ports uplink" 22 reliés non pas à des serveurs utilisateurs mais au réseau d'infrastructure 24 qui assure via une ou plusieurs liaisons dédiées 26 la gestion de l'installa- tion (réseau de télécommunications, routeur, centre de stockage des don- nées, etc.) dans laquelle se trouve le switch. Le CPU de management 14, quant à lui, est une unité essentiellement logicielle, comprenant donc un processeur implémentant un système d'exploitation ou OS schématisé en 28, typiquement un OS de type Linux ou VxWorks (marques déposées). Le CPU de management 14 est relié au processeur de paquets 12 par une liaison de contrôle 30, qui n'est pas une liaison de type réseau. Cette liaison de contrôle 30 est couplée au processeur de paquets par une interface spécifique 32 directe. Le CPU de management 14 embarque une application de pilotage 34 dé- finissant le schéma d'interconnexion entre les ports réseau 16 du processeur de paquets ainsi qu'un certain nombre de paramètres spécifiques à chaque port (actif/inactif, débit autorisé, etc.). Cette application 34 indique également des règles de filtrage que doit exécuter le processeur de pa- guets, si celui-ci dispose de capacités de filtrage avancées. Dans ce cas, il est possible de définir dans le processeur de paquets 12 des règles indiquant par exemple que pour un paquet dont l'adresse IP source présente une valeur prédéterminée, ce paquet doit être redirigé vers une interface spécifique (dite "interface de trap") au lieu de le faire suivre norma- lement vers son destinataire, ou alors qu'il y a lieu de faire une copie de ce paquet vers une interface spécifique (dite "interface mirrof) avant de le laisser continuer son chemin vers son adresse destinataire. Globalement, le switch 10 est géré à distance par un administrateur, notamment pour indiquer au CPU de management 14 la manière dont il doit configurer le processeur de paquets au moyen de l'application de pilotage 34. Pour cela, il est nécessaire de prévoir un réseau de supervision 36 relié à un port uplink spécifique 38 du CPU de management de manière à transmettre sur une liaison 40 correspondante les informations de configura- tion, qui sont ensuite dirigées vers l'application de pilotage 34 via une in- terface 42 depuis le port uplink spécifique 38. La Figure 2 illustre la nouvelle configuration originale de switch selon l'invention. Sur cette Figure 2, les mêmes références numériques désignent des élé- ments identiques ou fonctionnellement semblables à ceux de la Figure 1, qui ne seront donc pas décrits à nouveau en détail. De façon caractéristique de l'invention, la liaison entre le CPU de management 14 et le processeur de paquets 12 prévoit deux chemins logiques : outre le chemin 30 de configuration du processeur de paquets, il est prévu un chemin de données 44 autorisant un échange bidirectionnel par lequel des données (des paquets transmis par le processeur 12) peuvent être échangées entre le CPU de management 14 et le processeur de paquets 12. Le système d'exploitation OS contient un composant logiciel sélecteur 46 permettant d'aiguiller les données incidentes arrivant sur ce chemin 44 soit vers l'application de pilotage 34, soit vers des interfaces réseau virtuelles 50 émulées par le système d'exploitation 28. D'autre part, le CPU de management 14 ne comporte plus de port uplink propre (tel que le port 38 de la Figure 1). Dès lors, pour l'envoi des données de configuration par l'administrateur du réseau, celles-ci le sont via le réseau d'infrastructure 24, et il n'est donc plus besoin d'un réseau spé- cifique de supervision tel que le réseau 36 de la Figure 1. Ces données de paramétrage sont envoyées au processeur de paquets via le port uplink 22, puis vers le CPU de management via l'interface 32, le chemin de données 44 et le sélecteur 46 qui aiguille ces données vers l'application de pi- lotage 34. La commande du sélecteur 46 est déterminée par une informa- tion additionnelle (drapeau) envoyée au CPU de management 14 par le processeur de paquets 12 sur le chemin de données 44). Très avantageusement, les interfaces réseau virtuelles 50 émulées au sein du CPU de management 14 sont utilisées pour alimenter des applica- tions utilitaires 52, 54, 56... Ces applications utilitaires tournent sous le contrôle du système d'exploitation OS et traitent des données envoyées par le processeur de paquets sur le chemin de données 44 via le sélecteur 46, qui aiguille ces données dans ce cas vers les interfaces réseau virtuelles émulées 50. L'utilisation d'une interface réseau pour l'échange de données avec ces applications utilitaires permet d'utiliser pour ces dernières des logiciels préexistants, standards, et de mettre ceux-ci en oeuvre directement à l'intérieur du CPU de management, donc sans surcoût architectural ni trafic de données additionnel vers le réseau d'infrastructure. Ces logiciels standards peuvent être des analyseurs de réseau, des enre- gistreurs de trafic, des logiciels d'implémentation de services (chiffrement SSH, messagerie, etc.), configurés pour fonctionner sous le système d'exploitation du CPU de management, par exemple sous un OS de type Linux, donc sous une forme tout à fait conventionnelle. REVENDICATIONS1. Un commutateur réseau Ethernet (10), comprenant : - un processeur de paquets (12), avec : une pluralité de premiers ports réseau (16) aptes à être reliés à une pluralité correspondante de serveurs utilisateurs (18) ; au moins un second port réseau (22) apte à être relié à un réseau d'infrastructure (24) ; une interface (32) de liaison à une unité de gestion ; et des moyens d'interconnexion mutuelle des premiers et/ou seconds ports réseau en fonction d'informations de contrôle et de configura- tion reçues sur l'interface de liaison ; - une unité de gestion à processeur (14), couplée au processeur de paquets et comprenant : un système d'exploitation (28) ; une application (34) de pilotage du processeur de paquets, apte à générer lesdites informations de contrôle et de configuration ; et une interface de liaison au processeur de paquets ; - une liaison de contrôle, établie entre les interfaces de liaison respectives du processeur de paquets et de l'unité de gestion, pour l'échange bidirectionnel de données ainsi que desdites informations de contrôle et de configuration ; et - une liaison à un superviseur de gestion à distance du commutateur, ce commutateur étant caractérisé en ce que : - l'unité de gestion est dépourvue de port réseau matériel dédié, relié audit superviseur de gestion à distance du commutateur ; - le commutateur est relié au superviseur de gestion à distance du com- mutateur via ledit second port réseau (22) du processeur de paquets ; - le système d'exploitation est apte à émuler au moins une interface réseau virtuelle (50) ; - l'unité de gestion comprend en outre un composant logiciel sélecteur (46) intercalé entre, d'une part, l'interface de liaison au processeur de paquets et, d'autre part, l'application de pilotage et l'(les) interface(s) réseau virtuelle(s) ;- la liaison de contrôle entre l'unité de gestion et le processeur de paquets comprend : - d'une part, un chemin de configuration (30) pour l'échange de données directement avec l'application de pilotage, et - d'autre part un chemin de données (44) pour l'échange de données entre le processeur de paquets et l'(les) interface(s) réseau virtuelle(s), ou bien entre le processeur de paquets et l'application de pilotage, sélectivement via le composant logiciel sélecteur. 2. Le commutateur réseau Ethernet de la revendication 1, dans lequel : - l'unité de gestion inclut en outre au moins une application utilitaire (52, 54, 56) apte à échanger et à traiter des données via une liaison réseau, et - l'(les) application(s) utilitaire(s) opère(nt) sous le contrôle du système d'exploitation et traite(nt) des données échangées avec le processeur de paquets via l'(les) interface(s) réseau virtuelle(s), le composant logiciel sélecteur et le chemin de données de la liaison de contrôle. 3. Le commutateur réseau Ethernet de la revendication 2, dans lequel la- dite au moins une application utilitaire est une application du groupe com- prenant : des analyseurs de réseau, des enregistreurs de trafic réseau, et des services réseau fournis aux serveurs utilisateurs.