Un réseau d’entreprise tient rarement par la largeur de ses accès; il tient surtout par la qualité de son cœur. Un switch coeur de réseau n’est pas là pour faire du petit routage local: il doit transporter les flux entre bâtiments, consolider les liens vers la distribution et rester disponible sans devenir le point de panne qui paralyse tout le site. Dans cet article, je détaille son rôle, sa place dans une architecture campus, les critères de choix qui comptent vraiment et les erreurs de conception qui coûtent cher ensuite.
L’essentiel à garder en tête avant de dimensionner le cœur
- Le cœur de réseau doit surtout assurer un transport rapide, stable et très disponible entre les blocs du site.
- Je privilégie presque toujours une logique Layer 3 au cœur, avec un minimum de complexité fonctionnelle.
- Les débits courants vont de 10/25/40/100 GbE, et certains modèles haut de gamme montent jusqu’à 400G.
- Sur un petit site, un cœur fusionné avec la distribution peut suffire; sur un campus en croissance, mieux vaut séparer les rôles.
- Le vrai risque n’est pas seulement le manque de ports, mais le point unique de panne et l’oversubscription mal maîtrisée.
Ce qu’un cœur de réseau fait vraiment dans une infrastructure
Le cœur est la colonne vertébrale du réseau. Il agrège les flux venus des commutateurs de distribution, relaie les échanges vers le WAN, Internet ou les serveurs, et doit le faire avec un minimum de traitements intermédiaires. Quand je conçois un site, je considère ce niveau comme une zone de transit rapide, pas comme l’endroit où l’on empile des politiques complexes.
Dans la pratique, cela veut dire deux choses. D’abord, le cœur doit rester simple pour être robuste. Ensuite, il doit être capable d’absorber une montée en charge sans forcer toute l’architecture à se réécrire. Cisco illustre bien cette logique avec des cœurs pensés pour le Layer 3, la haute disponibilité et des débits qui montent aujourd’hui jusqu’au 400G sur certaines références.
| Couche | Rôle principal | Ce que je vérifie en priorité |
|---|---|---|
| Accès | Connecter les terminaux, téléphones, bornes Wi-Fi et imprimantes | PoE, densité de ports, segmentation VLAN, simplicité de gestion |
| Distribution | Faire l’agrégation locale et appliquer une partie de la politique réseau | Redondance, résumé de routes, ACL, boundary entre accès et cœur |
| Cœur | Transporter vite les flux entre blocs de réseau | Haute disponibilité, capacité, faible latence, stabilité Layer 3 |
Cette distinction compte beaucoup, parce qu’un cœur trop chargé en fonctions finit par ressembler à un goulot d’étranglement déguisé. À partir de là, la vraie question n’est plus seulement « quel switch acheter ? », mais « dans quelle architecture l’insérer intelligemment ? »
Comment il s’insère dans une architecture campus
Dans un campus classique, le cœur se situe entre plusieurs blocs de distribution. Il assure le transport entre bâtiments, étages, services partagés et sortie WAN. C’est cette position centrale qui lui donne son importance: si le cœur tombe, ce n’est pas un poste isolé qui s’arrête, c’est souvent tout un pan du site.
Je distingue trois cas de figure. Le premier, c’est l’architecture à trois couches: accès, distribution et cœur séparés. Elle reste la plus lisible pour les sites moyens et grands. Le deuxième, c’est le collapsed core, où le cœur et la distribution sont fusionnés dans une même paire d’équipements. C’est souvent le bon compromis pour un petit site ou une agence qui n’a pas encore explosé en trafic. Le troisième, c’est le cœur modulaire dédié, utile quand la croissance, la maintenance ou la disponibilité imposent une structure plus nette.
Dans les schémas bien pensés, le cœur porte surtout du Layer 3. Une SVI, c’est-à-dire l’interface virtuelle associée à un VLAN, peut y servir de passerelle; cela évite de remonter inutilement les mécanismes de couche 2 et simplifie la convergence. Plus on monte en taille, plus j’essaie de garder le cœur comme un point de transport et non comme un point de décision fonctionnelle lourd.
Le bon réflexe, ici, consiste à regarder le trafic réel: combien de flux circulent entre bâtiments, combien vont vers le cloud, combien remontent vers des serveurs partagés, et quelle croissance prévoir à 24 ou 36 mois. C’est ce qui permet de savoir si une architecture fusionnée suffit encore, ou si le réseau a déjà besoin d’un vrai cœur séparé.
Les critères qui font la différence au moment du choix
Quand on parle d’un switch de cœur, le nombre de ports ne suffit pas. Je regarde d’abord la disponibilité, puis la capacité à encaisser le trafic sans saturation interne, ensuite les fonctions de routage et enfin la facilité d’exploitation. Un modèle qui paraît surdimensionné sur le papier peut devenir juste correct dès que les flux east-west augmentent, c’est-à-dire les échanges internes au site.
Les plateformes récentes montrent bien cette évolution: on trouve du 10/25/40/100 GbE sur de nombreux modèles campus, et certains châssis ou fixed switches montent jusqu’au 400G. Les gammes Cisco Catalyst 9500/9600 ou HPE Aruba Networking CX 8100/8325/8400 illustrent ce virage vers des cœurs plus rapides, mais aussi plus simples à opérer si l’architecture est bien pensée.
| Critère | Ce que je regarde | Pourquoi c’est décisif |
|---|---|---|
| Redondance | Deux équipements, deux alimentations, deux chemins, ou un châssis réellement résilient | Évite qu’une panne matérielle coupe tout le site |
| Débit des uplinks | Souvent 25G ou 100G, avec montée possible vers 400G sur certaines plateformes | Le cœur ne doit jamais devenir le goulot d’étranglement |
| Capacité de commutation | Débit total réellement exploitable, pas seulement le marketing de la fiche technique | Permet de vérifier que les ports peuvent travailler ensemble sans blocage |
| Latence | Comportement du switch sous charge, surtout pour la voix, la vidéo et les applis sensibles | Une faible latence évite les effets de file d’attente |
| Fonctions Layer 3 | Routage dynamique, résumé de routes, VRF, éventuellement ECMP | Le cœur doit rester simple mais capable de route correctement |
| Sécurité | ACL, chiffrement de lien si nécessaire, segmentation claire | Le cœur transporte des flux critiques et doit rester cohérent avec la politique de sécurité |
| Exploitation | Supervision, automatisation, journaux, maintenance, mises à jour sans interruption quand elles existent | Un bon cœur est aussi un cœur facile à maintenir |
Je retiens surtout une règle simple: plus le site devient critique, moins j’accepte de compromis sur la redondance et la simplicité. Si le projet dépend de fenêtres de maintenance courtes, la capacité à faire évoluer le logiciel sans coupure, autrement dit l’ISSU lorsqu’elle est supportée, devient un vrai critère de décision.
Quand choisir un modèle fixe, un châssis ou un cœur fusionné
Il n’existe pas un seul bon format. Un modèle fixe peut être excellent pour un site intermédiaire, parce qu’il est plus simple, moins coûteux à opérer et souvent plus rapide à déployer. Un châssis modulaire prend l’avantage dès que la croissance, la densité de ports, la maintenance ou les exigences de disponibilité deviennent plus lourdes.
Je résume cela en pratique de la façon suivante: si l’environnement est stable, avec quelques centaines d’utilisateurs et un trafic prévisible, je peux vivre avec un cœur fusionné ou une paire de switches fixes bien choisis. Si le site grandit, si plusieurs bâtiments communiquent entre eux, ou si le réseau supporte des applications critiques, je passe volontiers à une paire de cœurs L3 plus robustes, voire à un châssis modulaire.
| Contexte | Architecture que je privilégie | Pourquoi |
|---|---|---|
| Petit site ou agence | Collapsed core avec deux switches fixes Layer 3 | Simplicité, coût plus contenu, exploitation plus légère |
| Campus moyen | Paire de cœurs fixes ou modulaire léger, avec uplinks 25G/100G | Équilibre entre croissance, disponibilité et budget |
| Grand campus ou siège critique | Châssis modulaire redondant, prêt pour 100G et parfois 400G | Capacité, maintenance facilitée, marge pour les futures extensions |
| Environnement à forte contrainte d’exploitation | Architecture très standardisée, supervision centralisée, automatisation | Réduit les erreurs humaines et accélère les interventions |
Le piège classique, c’est d’acheter trop gros « au cas où » ou, à l’inverse, de choisir trop juste en pensant que le trafic restera stable pendant des années. Dans les deux cas, je conseille de dimensionner sur trois ans au minimum, pas sur le mois en cours.
Les erreurs que je vois le plus souvent sur le terrain
La première erreur, c’est de transformer le cœur en usine à règles. Plus on lui ajoute de filtrage, de segmentation bricolée et de fonctions locales, plus on ralentit le réseau et plus on complexifie le dépannage. Le cœur doit router vite et proprement, pas devenir le lieu où l’on empile toutes les exceptions du projet.
La deuxième erreur, c’est le point unique de panne. Un seul équipement, une seule alimentation, un seul chemin vers la distribution: on économise au départ, puis on paie le prix dès qu’une panne ou une mise à jour tourne mal. La troisième erreur, c’est l’oversubscription ignorée, c’est-à-dire un rapport mal équilibré entre les débits entrants et sortants. Tant que le trafic est faible, on ne le voit pas; dès que la vidéo, le cloud ou les sauvegardes montent, les lenteurs apparaissent vite.
- Je vois souvent des cœurs trop chargés en politique réseau alors qu’ils devraient rester des nœuds de transport.
- Je vois aussi des architectures sans vraie redondance, ce qui rend la maintenance anxiogène et les incidents plus coûteux.
- Le choix des liens est parfois sous-estimé: un cœur en 10G peut devenir trop étroit très vite sur un site en croissance.
- La maintenance logicielle est négligée, alors qu’un bon cycle de mise à jour fait partie du design, pas seulement de l’exploitation.
- La supervision arrive trop tard, alors qu’un cœur doit être observé en permanence pour détecter les dérives avant l’incident.
Si je devais résumer cette partie en une phrase, je dirais qu’un cœur de réseau ne doit jamais être spectaculaire. Il doit être fiable, prévisible et facile à maintenir. C’est précisément cette sobriété qui fait sa valeur.
Ce que je valide avant de figer un cœur de réseau pour trois ans
Avant de signer une architecture, je passe toujours par la même liste de vérification. Combien de bâtiments sont réellement raccordés au cœur ? Quel trafic inter-site ou inter-bâtiment est déjà visible ? Quelle marge de croissance faut-il prévoir à 24 ou 36 mois ? Et surtout, combien de panne ou de maintenance le réseau peut-il supporter sans impact métier ?
- Le volume de trafic actuel et la croissance attendue, pas seulement le nombre d’utilisateurs.
- Les besoins d’uplink entre accès, distribution et cœur, avec une cible réaliste en 25G, 100G ou plus.
- La redondance matérielle, y compris alimentations, ventilation et chemins physiques.
- La stratégie de routage, pour garder un cœur Layer 3 simple et stable.
- La maintenabilité, notamment les mises à jour, la supervision et l’automatisation.
Mon réflexe reste le même: tant que le site est petit et prévisible, je privilégie la sobriété et le collapsed core; dès que la charge, la disponibilité ou la croissance deviennent des sujets sérieux, je bascule vers un cœur L3 redondant, plus rapide et plus facile à faire évoluer. C’est ce cadrage qui évite les achats trop fragiles ou trop ambitieux, et qui donne au réseau une base durable.