Plateformes de gestion : DNA Center et Meraki

Définition

Cisco DNA Center, aujourd'hui appelé Catalyst Center, est une plateforme de gestion réseau déployée sur site : un appliance physique ou virtuel dans le datacenter de l'entreprise qui découvre les équipements, offre des fonctions de Design, Provisioning, Assurance et gestion des images, et expose des API REST northbound. Le Meraki dashboard est son pendant cloud : une plateforme d'administration 100 % hébergée par Cisco, pilotée depuis une interface web ou une API, réservée au matériel Meraki (passerelles MX, switchs MS, points d'accès MR).

Contexte

Le blueprint 200-301, thème 6, demande de décrire les capacités et les avantages des plateformes de gestion Cisco (DNA Center, Meraki). À l'examen, les attentes sont précises : savoir quel produit est on-prem et lequel est cloud-managed, ce que chacun apporte en automatisation (API, templates, zero-touch provisioning), le modèle de licence Meraki, et l'absence de CLI sur Meraki. Une question typique oppose la gestion traditionnelle par CLI à ces plateformes centralisées.

Les deux plateformes en face à face

Critère	DNA Center / Catalyst Center	Meraki dashboard
Déploiement	Appliance sur site (hardware ou virtuel VMware/AWS)	Cloud hébergé par Cisco, navigateur uniquement
Matériel géré	Parc Cisco (Catalyst 9000, ISR), intégration Meraki possible	Uniquement des appareils Meraki
Accès CLI aux équipements	Oui, SSH conservé en parallèle	Non, le dashboard est le seul point d'entrée
Licence	Souscription DNA Advantage par équipement	Licence par appareil, support et fonctionnalités liés
Automatisation	API REST northbound, SDK Python, templates CLI	API REST complète, webhooks, scripts
Assurance	Télémesure, flux, corrélation d'incidents par ML	Analytique cloud, alertes, SLA par application

DNA Center côté pile

DNA Center structure la gestion en workflows : Design (hiérarchie du réseau, pools d'adresses, sites), Provision (déploiement zero-touch par PnP, templates CLI générés), Assurance (collecte de syslog, NetFlow et télémesure, score de santé, détection d'anomalies par machine learning), et Platform (API browser, accès aux centaines de endpoints REST). Les équipements descendent du contrôleur par des protocoles southbound comme NETCONF et RESTCONF, tandis que les scripts et les outils de l'entreprise montent par les API northbound. Le gestionnaire garde la main : le CLI SSH reste disponible pour dépanner ou contourner un workflow.

Meraki côté cloud

Le dashboard Meraki organise tout en hiérarchie organization, network, device. L'appareil ne reçoit aucune configuration au sens classique : il appelle en permanence le cloud pour synchroniser son état, ce qui supprime les sauvegardes de configuration locales. Il n'existe pas de CLI : show running-config n'a aucun équivalent, tout passe par le dashboard ou l'API. La licence est indissociable du matériel : sans licence active, l'appareil cesse de fonctionner correctement, ce qui distingue le modèle du simple support technique. L'API, documentée sur developer.cisco.com, couvre quasiment chaque réglage du dashboard :

import os
import requests

api_key = os.environ["MERAKI_API_KEY"]
org_id = "000000"

url = f"https://api.meraki.com/api/v1/organizations/{org_id}/networks"
resp = requests.get(
    url,
    headers={"X-Cisco-Meraki-API-Key": api_key},
    timeout=10,
)
resp.raise_for_status()

for network in resp.json():
    print(network["name"], network["id"])

Cas d'usage sur un site minier

Un site minier combine typiquement les deux modèles. L'atelier de concentration et la salle serveur, avec leurs Catalyst 9300 et leurs exigences de segmentation (SD-Access), relèvent bien de DNA Center : l'appliance reste au datacenter du site, les API alimentent le SI local, et le provisioning par template déploie les switchs d'accès des nouveaux ateliers. Les zones mobiles et déportées (périmètre de la mine à ciel ouvert, campement, atelier de maintenance) relèvent de Meraki : des MX en 4G/5G ou satellite apportent le trafic, des MR diffusent le WiFi des équipes, et un administrateur central pilote tout depuis le dashboard sans technicien sur place.

Limites de chaque modèle

DNA Center suppose une expertise interne, une infrastructure d'hébergement et un cycle de montée de version de l'appliance : c'est un produit à exploiter, pas un service consommé. Meraki dépend du lien Internet : quand le tunnel cloud lâche, le plan de données continue de transmettre, mais plus aucun changement, plus aucune vue temps réel, et les mises à jour de firmware ne partent plus. Le choix n'est donc pas technologique mais organisationnel : qui administre, où vit la donnée de management, et que se passe-t-il sans connexion.

Exemple concret

Une extension de campement ajoute 18 points d'accès. En CLI classique : 45 minutes de configuration par appareil entre VLAN, SSID et ports uplink, soit 13,5 heures cumulées. Avec des templates DNA Center et le PnP : les boîtes sont livrées, branchées, elles téléphonent à l'appliance et reçoivent leur configuration en 10 minutes chacune, soit 3 heures d'intervention sur site. En Meraki : les MR sont pré-réclamés dans l'organization depuis le bureau du siège, le technicien ne fait que les brancher, temps d'administration effectif proche de zéro, au prix de 18 licences annuelles à renouveler.

Pièges fréquents

1. Chercher un accès SSH sur un appareil Meraki : il n'existe pas, c'est un choix d'architecture.
2. Croire qu'une licence Meraki expirée « ne fait que couper le support » : le matériel cesse de transmettre.
3. Inverser northbound et southbound : l'API REST de DNA Center est northbound, la gestion des équipements est southbound.
4. Oublier que DNA Center est un logiciel à maintenir (patchs, montée de version), contrairement au cloud Meraki.