Dell Enterprise SONiC : prise en main et MC-LAG

Julien HOKINI · 26 juin 2026 · 14 min read

Article 1/3 — Série déploiement SONiC sur Dell PowerSwitch S5212F-ON

Si vous venez de Cisco IOS, de Junos, ou même de Dell OS10 — l'ancien NOS propriétaire des PowerSwitch — la première ouverture de session sur un switch sous SONiC vous réserve une surprise : un prompt Linux. Pas de enable, pas de conf t immédiat, pas d'interface GigabitEthernet, pas de show running-config qui sort 200 lignes d'un coup. Juste un shell Debian avec un utilisateur admin.

Pour ceux qui arrivent d'OS10, la rupture est peut-être encore plus nette : OS10 proposait déjà une CLI Dell cohérente, une gestion de configuration classique, un comportement prévisible. SONiC casse ce modèle volontairement. La configuration n'est plus un fichier texte, c'est une base de données. Les fonctions réseau ne sont plus des processus monolithiques, ce sont des containers. Il faut quelques minutes pour comprendre où on est — et ensuite ça devient logique, voire élégant.

Ce premier article pose les fondations : ce qu'est Dell Enterprise SONiC, comment l'OS est structuré, et comment aller jusqu'à un MC-LAG opérationnel sur deux S5212F-ON. Les articles suivants de la série couvriront la configuration réseau pour un fabric de stockage 25G, puis l'intégration côté serveurs.

Ce qu'est SONiC — et ce que Dell en a fait

SONiC (Software for Open Networking in the Cloud) est un NOS open-source né chez Microsoft, conçu à l'origine pour les fabrics Azure. Il tourne sur Linux (Debian) et repose sur une architecture de micro-services containerisés qui interagissent via une base de données Redis centrale : la CONFIG_DB / APP_DB / STATE_DB. Chaque démon — bgpd, teamd, orchagent, syncd — lit et écrit dans cette DB. C'est ce qui rend SONiC aussi flexible et aussi déroutant au premier abord : la configuration n'est pas dans un fichier plat comme un running-config, elle est dans une base de données.

Dell Enterprise SONiC est la distribution durcie et supportée par Dell. Elle ajoute au-dessus de la base communautaire :

Une CLI de style IOS/Junos appelée MF-CLI (Management Framework CLI), accessible via sonic-cli
Un support étendu des plateformes PowerSwitch (S5212F-ON, S5224F-ON, S5248F-ON, Z9332F-ON, etc.)
Des fonctionnalités enterprise : MC-LAG, BGP EVPN/VXLAN, Dell Fabric Manager
Du support Dell avec SLAs et firmware qualifié

Il existe plusieurs bundles de licence, alignés sur les familles de switches :

Bundle	Plateformes cibles	Usage typique
Enterprise SONiC Lite	S32xx, E32xx	Features Edge/Campus — PoE, 802.1x, switching L2
Enterprise SONiC Standard	S43xx, S52xx, S54xx, Z9xxx	L2/L3 complet, MC-LAG, BGP — usage datacenter production
Enterprise SONiC Premium	Certains équipements spécifiques	Télémétrie avancée, fonctionnalités supplémentaires

Pour un déploiement réseau standard avec deux S5212F-ON en MC-LAG, Enterprise Standard est la cible naturelle.

Les topologies réseau supportées par SONiC

Avant de configurer quoi que ce soit, il est utile de comprendre dans quelle topologie SONiC est conçu pour opérer — et où se situe notre architecture deux switches par rapport aux topologies plus larges.

Leaf-spine (Clos)

La topologie de référence pour les déploiements SONiC en datacenter est le leaf-spine, aussi appelée architecture Clos. Le principe : des switches leaf connectés aux hôtes en L2, des switches spine interconnectés aux leafs en L3, avec de l'ECMP (Equal-Cost Multi-Path) pour distribuer le trafic sur tous les liens uplink disponibles.

Leaf-spine or Clos architecture. Source : Dell Technologies

Chaque leaf est connecté à tous les spines. Si un spine tombe, le trafic continue sur les autres chemins ECMP sans intervention manuelle. C'est l'architecture qu'on retrouve dans les grands datacenters — hyperscalers, cloud providers — là où SONiC a été conçu à l'origine.

Leaf-spine avec super-spines

Pour les très grandes infrastructures multi-datacenter ou multi-pod, on ajoute une couche de super-spines au-dessus des spines. Chaque pod dispose de ses propres spines, interconnectés entre eux via les super-spines. L'ECMP s'applique sur chaque couche. C'est une topologie que vous ne rencontrerez pas sur un déploiement de quelques centaines de serveurs, mais qui illustre bien la capacité de SONiC à scaler horizontalement sans limites architecturales.

*Leaf-spine topology with super spines*. Source : Dell Technologies

Notre architecture : deux switches en MC-LAG

Dans la série d'articles qui suit, nous ne déployons ni spine, ni ECMP, ni VXLAN. Notre topologie est volontairement simple : deux S5212F-ON en MC-LAG, une salle, une baie de stockage, quelques serveurs. C'est le cas de figure typique d'un datacenter de taille intermédiaire ou d'une salle serveurs d'entreprise.

   [ SAN-SW-01 ]----MC-LAG peer-link----[ SAN-SW-02 ]
         |                                    |
    (Fabric A)                           (Fabric B)
         |                                    |
          [Baie de stockage — dual-path iSCSI]
         |                                    |
           [Serveurs — dual-homed via MC-LAG]

Cette topologie ne nécessite pas BGP, pas de VXLAN, pas de SmartFabric Manager. Elle exploite SONiC uniquement sur sa couche L2/MC-LAG — ce qui est précisément son point fort pour ce type d'usage : un NOS moderne, flexible, sans la complexité d'un fabric full L3.

Si vos besoins évoluent vers de la mobilité de VMs entre salles ou plusieurs baies de stockage réparties sur plusieurs racks, l'architecture leaf-spine avec BGP EVPN/VXLAN devient pertinente. SONiC supporte cette évolution sans changer de NOS — c'est l'un de ses atouts majeurs face aux solutions propriétaires.

L'architecture de l'OS : deux couches, deux CLIs

C'est la chose la plus importante à intégrer dès le départ : SONiC a deux espaces distincts, et les confondre est la source numéro un d'erreurs en production.

Le shell Linux (bash)

Quand vous vous connectez en SSH ou console, vous atterrissez ici :

admin@sonic:~$

C'est un shell Debian classique. Vous avez sudo, systemctl, ip, ping, les logs dans /var/log/syslog. Les commandes show de style SONiC communautaire (show interfaces status, show vlan brief) fonctionnent directement depuis ce shell. La configuration persistée se lit dans /etc/sonic/config_db.json.

La base Linux est là, visible, accessible — mais un administrateur réseau n'a pas besoin de la maîtriser pour exploiter le switch en production. C'est précisément la force de Dell Enterprise SONiC avec son Management Framework : chargé automatiquement au boot dans le container sonic-mgmt-framework, il expose quatre interfaces de gestion unifiées — CLI, REST, gNMI et gNOI — qui fournissent une façon cohérente de valider, configurer et gérer l'ensemble des fonctionnalités du switch.

Pour l'administrateur réseau, le point d'entrée naturel est la commande sonic-cli, qui démarre l'interface CLI interactive du Management Framework. Configuration, exploitation, diagnostic — tout se fait depuis cette interface familière, sans toucher au shell Debian.

admin@sonic:~$ docker ps | grep mgmt
00983c37e4a7   docker-sonic-mgmt-framework:latest   "/usr/bin/supervisord"   Up 2 hours   mgmt-framework

Note : les méthodes de configuration legacy — FRR shell et édition directe de config_db.json — restent supportées, mais sont à réserver au dépannage avancé. En exploitation courante, la MF-CLI est la référence.

Sous le capot : une architecture de micro-services containerisés

Ce qui rend SONiC fondamentalement différent d'un IOS, d'un JunOS ou d'un OS10, c'est que chaque fonction réseau tourne dans son propre container Docker. Ce n'est pas une abstraction de présentation — c'est l'architecture réelle du système. L'architecture containerisée de SONiC offre un contrôle maximal, une flexibilité et un choix de composants que les NOS monolithiques ne permettent pas.

Tous ces modules communiquent entre eux via une base de données Redis centrale. Un docker ps sur le switch vous donne une lecture directe de ce qui tourne :

CONTAINER ID   IMAGE                             COMMAND                  STATUS
3f2a1c8e9d12   docker-fpm-frr:latest             "/usr/bin/supervisord"   Up 2 hours
7b4e5f1a2c34   docker-teamd:latest               "/usr/bin/supervisord"   Up 2 hours
9d8c7b6a5e43   docker-syncd-brcm:latest          "/usr/bin/supervisord"   Up 2 hours
1a2b3c4d5e67   docker-swss:latest                "/usr/bin/supervisord"   Up 2 hours
2c3d4e5f6a78   docker-lldp:latest                "/usr/bin/supervisord"   Up 2 hours
4e5f6a7b8c90   docker-snmp:latest                "/usr/bin/supervisord"   Up 2 hours
5f6a7b8c9d01   docker-mgmt-framework:latest      "/usr/bin/supervisord"   Up 2 hours
6a7b8c9d0e12   docker-pmon:latest                "/usr/bin/supervisord"   Up 2 hours
8b9c0d1e2f34   docker-database:latest            "/usr/bin/supervisord"   Up 2 hours
a1b2c3d4e5f6   docker-dhcp-relay:latest          "/usr/bin/supervisord"   Up 2 hours

Les containers officiels de l'architecture SONiC et leur rôle :

database : le cœur névralgique — l'instance Redis qui héberge la CONFIG_DB, APP_DB et STATE_DB. Tous les autres modules lisent et écrivent ici. C'est le bus de communication central.
swss (Switch State Service) : l'orchestrateur principal. Il traduit les changements de configuration en instructions vers le SAI (Switch Abstraction Interface), la couche d'abstraction qui parle à l'ASIC.
syncd : synchronise l'état du SAI avec le driver ASIC physique Broadcom. C'est lui qui programme réellement les tables de forwarding, les ACLs et les VLANs dans le silicium.
bgp (FRRouting) : le stack de routage — gère BGP, OSPF, et les routes statiques. Remplaçable par un autre moteur de routage sans toucher au reste du système.
teamd : gère les PortChannels LACP, dont le peer-link MC-LAG et tous les LAGs hôtes.
lldp : découverte de topologie LLDP, utile pour la supervision et la validation du câblage.
snmp : exposition SNMP pour l'intégration dans les outils de monitoring existants.
pmon (Platform Monitor) : supervision matérielle — températures, alimentation, ventilateurs, état des optiques SFP.
dhcp-relay : agent relais DHCP, intégré nativement dans Linux.
docker-mgmt-framework : expose la MF-CLI via sonic-cli et l'API REST de management. C'est ce container qui vous donne l'expérience IOS-like.

Cette architecture a une conséquence pratique importante : un container qui crashe ne fait pas tomber le switch. Si docker-mgmt-framework redémarre, la CLI est indisponible 30 secondes — le trafic continue, l'impact est minimisé. C'est un comportement radicalement différent d'un OS monolithique où un crash de processus peut impacter le plan de forwarding. Vous pouvez d'ailleurs redémarrer un container manuellement sans coupure de service :

bash

sudo systemctl restart mgmt-framework

La MF-CLI (sonic-cli)

Pour retrouver une expérience IOS-like, on entre dans la MF-CLI :

admin@sonic:~$ sonic-cli
sonic#

Depuis là, configure terminal, interface Eth 1/1, switchport, write memory — tout le vocabulaire IOS est présent. C'est dans cette couche que vous ferez 95 % de votre configuration en production.

La règle d'or : la MF-CLI écrit dans la CONFIG_DB en mémoire. write memory persiste cette CONFIG_DB sur disque (/etc/sonic/config_db.json). Si vous modifiez config_db.json directement en bash sans passer par sonic-cli, vous risquez des incohérences entre l'état actif et l'état persisté. En production, restez dans sonic-cli.

Première connexion et initialisation

Accès console

Connexion série : 115200 baud, 8N1. Sur MobaXterm, utilisez le mode Serial classique. Si votre poste est en AZERTY, soyez vigilant sur la saisie du mot de passe lors du premier login — les raw keycodes console ne respectent pas votre disposition clavier Windows. Tapez en QWERTY ou utilisez copier-coller (Shift+Ins ou clic droit MobaXterm).

Identifiants par défaut :

login    : admin
password : YourPaSsWoRd

Le switch vous forcera à changer le mot de passe à la première connexion.

Désactiver ZTP

Le Zero-Touch Provisioning se lance automatiquement au premier démarrage. Sur un déploiement manuel, il doit être coupé immédiatement — sans quoi la configuration que vous posez peut être écrasée, ou le switch reste en attente d'un serveur DHCP/ZTP qui n'existe pas :

bash

sudo config ztp disable -y

Attendez une à deux minutes, puis vérifiez :

bash

show system status
# Attendu : System is ready

Interface-naming standard et hostname

Par défaut, SONiC nomme ses ports en notation communautaire (Ethernet0, Ethernet4...). La notation Dell standard (Eth 1/1, Eth 1/2) est bien plus lisible et cohérente avec la documentation officielle. À activer en priorité :

admin@sonic:~$ sonic-cli
sonic# configure terminal
sonic(config)# interface-naming standard
Broadcast message: Interface naming mode has changed. [...]
sonic(config)# hostname SAN-SW-01
Broadcast message: Hostname has been changed [...]
sonic(config)# end
sonic# exit
admin@sonic:~$

Ouvrez une nouvelle session après ce changement pour que le renommage des interfaces soit effectif dans votre terminal. C'est un point que l'on oublie régulièrement : la commande prend effet immédiatement dans le système, mais pas dans la session console en cours.

Profil de switching L2/L3

Après installation depuis ONIE, le profil par défaut est L3. Vérifiez le profil actif :

bash

sonic-cli
show running-configuration | grep factory

Pour un switch dédié à du L2 (VLANs, PortChannels, pas de routage inter-VLAN nécessaire sur le switch lui-même), L2 est suffisant et légèrement plus performant sur l'ASIC. Si vous avez besoin de SVIs avec adresses IP — ce qui est utile pour la supervision et le keepalive MC-LAG sans interface Management dédiée — restez en L3.

Pour basculer en L2 :

bash

sonic-cli
configure terminal
factory default profile l2 confirm
# Le switch reboot automatiquement

IP de management

bash

sonic-cli
configure terminal
interface Management 0
  ip address 10.0.0.11/24 gwaddr 10.0.0.1
  no shutdown
end
write memory

Comprendre le MC-LAG avant de le configurer

Le MC-LAG (Multi-Chassis Link Aggregation Group) est le mécanisme qui permet à deux switches physiques distincts de se présenter comme un seul switch logique vis-à-vis des équipements connectés. Un serveur qui câble ses deux ports réseau sur SW-01 et SW-02 voit un seul PortChannel LACP agrégé. C'est la base de la redondance matérielle sans boucle L2 active sur les liens hôte.

Contrairement au VSS Cisco ou au VPC Nexus qui partagent un plan de contrôle, le MC-LAG Dell SONiC garde deux plans de contrôle indépendants. Les deux switches restent des entités distinctes du point de vue BGP, STP, et gestion — seul le plan de données est agrégé côté hôte. C'est une distinction importante pour le troubleshooting.

Trois éléments constituent un MC-LAG Dell SONiC :

Le peer-link est le lien physique direct entre les deux switches. Il transporte le trafic de synchronisation MC-LAG, mais aussi le trafic de données en cas de défaillance d'un uplink hôte (le trafic transite alors par le peer-link vers le switch qui a encore un lien actif vers la destination). Ce lien doit transporter tous les VLANs utilisés en production — un VLAN absent du peer-link sera coupé en cas de basculement. Dell recommande au minimum deux ports physiques pour ce lien, en 25G ou plus.

Le keepalive est le mécanisme de détection de panne entre les deux peers. Il utilise les adresses source-ip et peer-ip définies dans le domaine MC-LAG, et ces adresses doivent être routables entre les deux switches indépendamment du peer-link. L'interface Management 0 est idéale pour ça — si le peer-link tombe mais que Management 0 reste opérationnel, les switches savent qu'ils sont toujours tous les deux en vie (pas de split-brain).

Le domaine MC-LAG est la configuration logique qui lie le tout. Chaque switch a son propre source-ip, connaît le peer-ip de son partenaire, et référence le PortChannel peer-link.

La mclag-system-mac est l'adresse MAC virtuelle partagée par les deux switches pour se présenter comme un seul équipement logique côté LACP. Elle doit être identique sur les deux peers et unique dans votre réseau — choisissez une adresse hors des plages constructeurs connues. Sans cette configuration, certains équipements connectés en MC-LAG peuvent voir des instabilités LACP lors d'un basculement entre les deux switches, car l'adresse MAC source du PDU LACP change.

Le paramètre delay-restore

Souvent négligé, delay-restore définit le délai en secondes avant qu'un switch qui revient en ligne ne reprenne le trafic MC-LAG après un redémarrage. Ce délai laisse le temps à LACP, STP et à la synchronisation MC-LAG de converger avant de remettre du trafic de production sur les ports hôte.

Les valeurs couramment utilisées dans les designs Dell sont 90 secondes et 300 secondes selon la version et la complexité de l'environnement. La valeur doit être alignée sur votre design : un environnement avec beaucoup de VLANs et de PortChannels à renegocier bénéficiera d'un délai plus long. Mettre cette valeur à 0 dans l'espoir d'accélérer le retour provoque régulièrement des micro-coupures lors des maintenances.

Configuration MC-LAG complète — deux S5212F-ON

Configuration de référence pour deux S5212F-ON en MC-LAG L2 pur, sans BGP ni VXLAN. C'est le socle réseau pour la majorité des déploiements de datacenter de taille intermédiaire.

Plan de ports et d'adressage

Les adresses source-ip / peer-ip du domaine MC-LAG peuvent être des loopbacks, des SVIs, ou des adresses Management 0. Ici on utilise Management 0 directement — simple et robuste pour les déploiements sans routage complexe.

Élément	SAN-SW-01	SAN-SW-02
Management 0	10.0.0.11/24	10.0.0.12/24
MC-LAG source-ip	10.0.0.11	10.0.0.12
Peer-link ports	Eth 1/11, Eth 1/12	Eth 1/11, Eth 1/12
Peer-link PortChannel	PortChannel 100	PortChannel 100
MC-LAG system-mac	00:11:22:33:44:55	00:11:22:33:44:55

SAN-SW-01

sonic-cli
configure terminal

! Peer-link PortChannel
interface PortChannel 100
  description MCLAG-Peer-Link
  no shutdown

! Membres physiques du peer-link
interface Eth 1/11
  description Peer-link-to-SAN-SW-02-P1
  channel-group 100
  no shutdown

interface Eth 1/12
  description Peer-link-to-SAN-SW-02-P2
  channel-group 100
  no shutdown

! Domaine MC-LAG
mclag domain 1
  source-ip 10.0.0.11
  peer-ip   10.0.0.12
  peer-link PortChannel 100
  delay-restore 90
  mclag-system-mac 00:11:22:33:44:55

end
write memory

SAN-SW-02

sonic-cli
configure terminal

interface PortChannel 100
  description MCLAG-Peer-Link
  no shutdown

interface Eth 1/11
  description Peer-link-to-SAN-SW-01-P1
  channel-group 100
  no shutdown

interface Eth 1/12
  description Peer-link-to-SAN-SW-01-P2
  channel-group 100
  no shutdown

mclag domain 1
  source-ip 10.0.0.12
  peer-ip   10.0.0.11
  peer-link PortChannel 100
  delay-restore 90
  mclag-system-mac 00:11:22:33:44:55

end
write memory

Vérification

sonic-cli
show mclag brief

Sortie attendue une fois les deux switches reliés et configurés :

Domain ID      : 1
Role           : Active
Session Status : Up
Peer Link      : PortChannel100
Peer Link Status : Up

Le rôle Active / Standby est négocié automatiquement entre les deux peers. Pour la redondance MC-LAG, les deux rôles sont fonctionnels — la distinction n'affecte que certains comportements internes de synchronisation, pas le forwarding de trafic.

show mclag
show interfaces PortChannel 100
show interfaces status

Tant que Session Status est Down, aucun port hôte configuré en MC-LAG ne sera actif sur les deux switches simultanément. C'est le premier point à vérifier avant d'aller plus loin.

Points d'attention spécifiques à Dell Enterprise SONiC

Ces particularités viennent du terrain. Certaines ne sont pas explicitement documentées, d'autres sont des différences de comportement par rapport à Cisco/Junos qui surprennent à la première confrontation.

PortChannel : LACP actif par défaut, LAG statique sur demande La commande interface PortChannel <n> crée par défaut un LAG en mode LACP actif, tout comme la commande interface PortChannel <n> mode active . La commande channel-group X sur l'interface ethernet rattache ensuite l’interface au PortChannel.
Si vous souhaitez configurer un LAG statique (sans LACP), utilisez interface PortChannel <n> mode on.

VLANs réservés : plage 3967–4094 par défaut — la plage de VLANs réservés par défaut va de 3967 à 4094. Cette plage est configurable sur n'importe quelle plage continue de 128 VLANs, mais en dehors d'un besoin spécifique, évitez simplement de vous en approcher. Les utiliser en production provoque des comportements imprévisibles sans message d'erreur explicite.

spanning-tree disable global n'existe pas — contrairement à Cisco, il n'y a pas de commande pour désactiver STP globalement. Sur les ports connectés à des équipements finaux (serveurs, appliances), utilisez spanning-tree portfast port par port pour éviter les délais de 30 secondes au démarrage.

mclag-system-mac obligatoire en production — sans cette commande, le MC-LAG fonctionne mais utilise la MAC système du switch Active. Si ce switch redémarre et que le rôle bascule sur le Standby, l'adresse MAC LACP change côté hôte — ce qui peut provoquer une reconnexion LACP et une micro-coupure. Définir une MAC virtuelle fixe élimine ce risque.

mclag-separate-ip sur le VLAN keepalive — si vous utilisez un SVI dédié (et non Management 0) pour le keepalive MC-LAG, vous devez ajouter mclag-separate-ip sur ce VLAN SVI. Sans cette directive, le trafic keepalive peut emprunter le peer-link en cas de problème réseau, ce qui masque un état de split-brain.

write memory est non négociable — toute configuration posée via sonic-cli est active immédiatement en mémoire, mais n'est pas persistée avant le write memory. Un reboot sans cette commande repart de la configuration précédente. À intégrer comme réflexe après chaque bloc de configuration validé.

Ne pas mélanger bash et MF-CLI — les commandes config du shell bash (sudo config vlan add 100) coexistent avec la MF-CLI mais ne sont pas équivalentes en termes de validation et de persistance. En exploitation courante, restez dans sonic-cli exclusivement pour tout ce qui touche à la configuration.

Ce que couvre la suite

L'article 2 entre dans le concret : présentation de la baie Dell PowerStore, câblage du cluster network sur les deux S5212F-ON en MC-LAG, et création des VLANs iSCSI dual-fabric qui serviront de fondation pour la suite.

Testé en production — Enterprise SONiC 4.5.2 sur Dell PowerSwitch S5212F-ON.

Rédigé avec l'aide de l'IA pour en forme et formulation de l'article.

Dell Networking Enterprise SONiC