Architecture contrôleur vs traditionnelle
Définition
Dans une architecture traditionnelle, chaque équipement contient son propre plan de contrôle : le routeur calcule ses tables, le switch ses ports, et l'administrateur configure device par device. Dans une architecture pilotée par contrôleur (SDN), un plan de contrôle centralisé décide de l'état désiré du réseau et le distribue aux équipements, qui ne font qu'appliquer. Le contrôleur devient l'unique point de configuration ; les appareils deviennent des points de transit.
Contexte
Le blueprint 200-301 v1.1, topics 6.2 et 6.3, demande de comparer les réseaux traditionnels et les réseaux à contrôleur, et de décrire l'architecture logicielle pilotée par contrôleur (overlay, underlay, fabric). Attendu à l'examen : vocabulaire (plan de contrôle, plans northbound/southbound, intention, drift), avantages (cohérence, templating, automatisation), limites (dépendance au contrôleur, protocoles propriétaires), et les noms Cisco connus : DNA Center et Meraki (détails dans l'article dédié aux plateformes de gestion).
Ce que change le contrôleur
Un routeur classique prend ses décisions localement : OSPF construit sa SPF, le switch calcule son spanning-tree, chaque ACL vit dans sa config. À 300 équipements, la « vérité » du réseau est éclatée en 300 fichiers de configuration, et l'ingénieur la reconstruit mentalement. Le contrôleur inverse le modèle : l'opérateur exprime une intention (« les visiteurs sont sur le VLAN 50 avec ce SSID »), le contrôleur la traduit en configurations concrètes et les pousse par un protocole southbound (netconf, RESTCONF, CLI chiffrée selon les plateformes). Le device garde son plan de contrôle de forwarding (il apprend toujours les routes dont il a besoin) mais délègue une part de la décision et de la gestion.
| Critère | Traditionnel (CLI) | Contrôleur (SDN) |
|---|---|---|
| Point de configuration | Chaque device, session SSH individuelle | Interface unique du contrôleur |
| État désiré | Éparpillé dans les running-config | Base centralisée, déclaratif |
| Cohérence à l'échelle | Typo et oubli fréquents sur 100+ devices | Un modèle applique la politique partout |
| Visibilité | show commande par commande, corrélation manuelle | Vue temps réel de tout le fabric |
| Changement | Procédure écrite, exécution manuelle | Intention poussee en lot |
| Dependance | L'expert CLI suffit | Le controleur devient indispensable |
Northbound et southbound
Deux faces d'API encadrent le contrôleur. La northbound API (vers le nord, côté applications) expose les fonctions du réseau au monde logiciel : un ticketing qui réserve un segment, un script Python qui demande « crée un SSID invité » via les API REST de DNA Center ou Meraki. La southbound API (vers le sud, côté équipements) parle aux devices : NETCONF/RESTCONF, CLI pilotée, protocoles de contrôle proprietary selon la plateforme. Le sens de la flèche est une question d'examen classique : northbound = vers les consommateurs d'en haut, southbound = vers l'infrastructure en bas.
Overlay, underlay, fabric
Le contrôleur construit souvent un réseau en deux couches. L'underlay est le réseau physique sous-jacent : les liens, le routage IP qui doit juste « joindre » les équipements (typiquement OSPF ou IS-IS en mode underlay, mtu cohérent, adresses de boucle). L'overlay est le réseau virtuel posé dessus : tunnels VXLAN qui créent des L2 étendus entre switchs, identifiants de segmentation indépendants de la topologie physique. La fabric est l'ensemble piloté : sous l'autorité d'un contrôleur (DNA Center avec son provisioning SD-Access), les nœuds acceptent l'intention et l'overlay se déploie tout seul. Au CCNA, retenir le découpage : underlay = connectivité physique/IP, overlay = virtuel et segmentation, contrôleur = chef d'orchestre des deux.
Bénéfices concrets
Trois gains reviennent dans les questions. Cohérence : une seule définition de la politique VLAN/SSID/QoS, finies les 12 variantes d'ACL tapées au fil de l'eau ; un déploiement sur 300 sites devient une poussée. Templating : le contrôleur (ou Ansible, même logique) remplit un gabarit avec les variables par site ; l'intention « VLAN 50 sur Gi1/0/1 à Gi1/0/24 » devient du code rejouable. Détection de drift : le contrôleur compare en continu l'état réel et l'état désiré, et signale (ou corrige) la trame modifiée à la main un vendredi soir ; en CLI pure, personne ne le voit avant l'incident.
Limites
Le contrôleur est un point de défaillance unique : indisponible, les équipements continuent de forwarder mais plus personne ne provisionne ni ne surveille globalement ; la haute disponibilité du contrôleur doit donc être achetée. Les équipements dégradés gardent souvent un mode autonome, mais l'administrateur y accède par des chemins d'urgence. Deuxième limite : l'enfermement. Les protocoles southbound et le modèle de données d'un contrôleur Meraki ou DNA Center sont propriétaires ; migrer vers un autre constructeur réécrit les scripts d'intégration northbound. Enfin, le coût et la courbe d'apprentissage : l'expertise CLI ne disparaît pas, elle se déplace vers le debug du contrôleur quand il ment sur l'état réel.
Exemple concret chiffré
Un déploiement de 42 sites comparés sur la tâche « appliquer une nouvelle ACL aux 168 switchs d'accès ». Méthode CLI : 2 minutes de session et collage par device, 6 h de travail humain, 7 erreurs relevées en relecture (bonne interface, mauvais ordre de lignes), 3 jours pour fermer le projet. Méthode DNA Center : intention et template poussés en un provisionning, exécution effective 26 minutes sur les 168 devices (file de 20 sessions parallèles, 2 devices hors ligne rattrapés au réveil), 0 dérive constatée à la vérification post-déploiement par la vue « device compliance ». Contrepartie mesurée le mois suivant : une coupure réseau isolant le contrôleur du WAN, 45 minutes sans provisioning possible, les switchs en place continuant de servir le trafic. Gain d'un facteur 7 sur le temps humain, plus une dépendance inédite sur la disponibilité du contrôleur : le blueprint attend de peser les deux plateaux.