Cisco Meraki MX 26 : ce qui change pour les routeurs MX

Pendant longtemps, une nouvelle génération de firmware Cisco Meraki MX se lisait surtout comme une addition de fonctions de sécurité, de VPN et de correctifs. Avec MX 26, le changement est plus profond. Les routeurs de sécurité Meraki commencent à couvrir des topologies que l’on associait davantage à des plateformes de routage avancé : plusieurs tables de routage, davantage d’uplinks, BGP enrichi, segmentation par groupes de sécurité, inspection du trafic HTTPS et politiques réutilisables à l’échelle d’une organisation.

Cette évolution ne signifie pas que toutes ces fonctions sont immédiatement disponibles sur tous les MX. La génération 26 réunit aujourd’hui deux réalités différentes : MX 26.1 est Generally Available, tandis que MX 26.2 reste en bêta. Certaines capacités conservent aussi leur propre statut Early Access, dépendent d’une licence précise ou sont limitées aux nouveaux Cisco Secure Routers.

Le bon moyen de comprendre MX 26 n’est donc pas de parcourir une longue liste de tickets corrigés. Il faut regarder la trajectoire : MX 26.1 pose les fondations du nouveau routage et de la gestion centralisée des politiques ; MX 26.2 approfondit la sécurité, la haute disponibilité et l’exploitation de réseaux plus complexes.

La chronologie compte autant que la liste des nouveautés. MX 26.1.2 était encore une bêta. MX 26.1.3, publiée le 10 mars 2026, a été la première version Generally Available de cette famille. La version MX 26.1.6, publiée le 23 juillet, appartient toujours à cette catégorie.

En parallèle, Meraki conserve MX 19.2.8 comme branche Recommended. Cette classification est importante : une branche Generally Available a franchi un niveau de maturité supérieur aux versions bêta, mais Meraki ne la présente pas encore comme le choix par défaut pour l’ensemble de sa base installée.

La famille MX 26.2 suit un autre calendrier. MX 26.2.1 a été publiée en bêta le 23 juin 2026, puis MX 26.2.2 le 16 juillet. Cette dernière est explicitement décrite comme la deuxième bêta de la famille 26.2.

Le précédent article consacré à MX 19.2.7 reste utile pour comprendre les améliorations de la branche Recommended. MX 26 doit être lu comme le niveau suivant, destiné aux réseaux qui ont un besoin identifié en matière de routage, de segmentation ou de sécurité.

Cette distinction doit rester visible tout au long de l’article. Dire que « MX 26 est stable » serait trop large : le train 26.1 est GA, le train 26.2 est bêta et plusieurs fonctions possèdent encore leurs propres conditions d’accès.

La principale rupture de MX 26.1 est l’ouverture à des architectures qui nécessitaient auparavant davantage d’équipements, de contournements ou une autre gamme de routeurs.

Les Virtual Routing and Forwarding, ou VRF, permettent à un même routeur de maintenir plusieurs tables de routage indépendantes. Deux entités, deux environnements ou deux clients peuvent ainsi utiliser des plans d’adressage qui se chevauchent sans être mélangés.

Les usages sont nombreux : isoler une activité invitée, séparer plusieurs entreprises dans un bâtiment, intégrer une société acquise sans renuméroter immédiatement son réseau ou construire une segmentation de bout en bout dans AutoVPN. La documentation Meraki prévoit jusqu’à sept VRF configurables en plus de la VRF par défaut avec MX 26.1, puis jusqu’à vingt-neuf avec MX 26.2.

Il faut néanmoins conserver le statut exact de la fonction : VRF reste proposée dans le programme Early Access. Son périmètre évolue aussi selon la version. MX 26.1 sait associer des VLAN et des routes à une VRF, mais BGP dans ce contexte demande MX 26.2.1 ou plus récent. OSPF n’est pas pris en charge avec les VRF, le Client VPN termine dans la VRF par défaut et certaines politiques de sécurité de MX 26.1 ne s’appliquent qu’à cette VRF par défaut.

La nouveauté est donc structurante, sans être une simple case à cocher sur un réseau existant. Elle impose de revoir le routage, la sécurité et les outils de diagnostic dans chaque domaine.

MX 26.1 enrichit BGP avec les communautés standards et personnalisées en sortie, ainsi qu’avec davantage de filtrage en entrée. MX 26.2 va plus loin : BGP peut être activé plus indépendamment d’AutoVPN et dispose de nouveaux contrôles sur les annonces sortantes et la préférence des routes.

MX 26.2.2 ajoute MP-BGP pour échanger des routes IPv4 et IPv6 au sein d’une même session iBGP entre pairs AutoVPN. La même version introduit aussi l’ECMP pour les routes eBGP apprises au travers de plusieurs tunnels IPsec : les nouveaux flux peuvent être distribués entre plusieurs chemins de coût égal.

Ce ne sont pas des raffinements purement théoriques. Ils permettent de construire des interconnexions plus redondantes, de mieux maîtriser les routes propagées entre un datacenter, des sites et des clouds, puis d’exploiter plusieurs tunnels au lieu de conserver des capacités inutilisées en attente d’une panne.

MX 26.2 améliore les scénarios IPv6-only et ajoute IP-in-IP ainsi que DS-Lite. Ces mécanismes répondent surtout aux besoins des opérateurs, hébergeurs et organisations qui doivent transporter IPv4 au-dessus d’une infrastructure IPv6.

Pour une entreprise classique, ce sujet sera rarement le premier motif de migration. Il indique toutefois que le MX ne se limite plus au schéma historique d’une agence IPv4 reliée par AutoVPN. La plateforme vise également les environnements de transition IPv4/IPv6 et les déploiements où l’appliance participe à une architecture de fournisseur de services.

Le deuxième pilier de MX 26 est la connectivité. Il concerne à la fois le nombre de liens disponibles, le comportement du NAT et la manière de publier ou d’interconnecter des réseaux.

Le MultiWAN de MX 26.1 permet d’utiliser plus de deux uplinks actifs sur certains Cisco 8000 Series Secure Routers gérés par Meraki. Le C8455-G2-MX peut exploiter quatre uplinks. Les C8111-G2-MX et C8121-G2-MX peuvent en utiliser trois.

Cette fonction peut servir à agréger plusieurs opérateurs, à séparer certains flux ou à renforcer la résilience d’un site important. Elle reste cependant liée au matériel. Elle ne transforme pas les ports LAN d’un MX67 ou d’un MX95 en quatre interfaces Internet actives.

La compatibilité d’AutoVPN impose également une cohérence de versions : le support complet du MultiWAN dans la fabric nécessite MX 26.1 ou plus récent sur les nœuds concernés. Certaines intégrations, comme Secure Connect et Secure Access, continuent par ailleurs à utiliser WAN 1 et WAN 2.

MX 26.1 élargit les mécanismes de traduction d’adresses dans les VPN. La traduction de sous-réseau aide à connecter deux sites qui utilisent la même plage privée. Les traductions vers un hôte ou un sous-réseau plus petit permettent aussi de conserver des adresses ou de présenter une identité différente dans le VPN.

Cette évolution est utile lors d’une fusion, d’une connexion avec un partenaire ou de l’intégration progressive d’un réseau historique. Elle évite parfois une renumérotation immédiate, mais ne supprime pas la nécessité de documenter les correspondances. Plus les traductions s’accumulent, plus le diagnostic devient difficile pour les équipes qui ne connaissent que l’adresse visible d’un côté du tunnel.

Les NAT Exceptions permettent de désactiver la traduction sur certains VLAN ou uplinks. Un site peut, par exemple, préserver les adresses sources vers un réseau MPLS tout en continuant à faire du NAT sur son accès Internet. La fonction rend aussi possibles des sous-réseaux publics routés ou certaines architectures de DMZ.

MX 26.1 accompagne ce mode routé d’un pare-feu entrant configurable. Le comportement par défaut est un refus global, puis l’administrateur ajoute les flux nécessaires. Cette ouverture apporte davantage de contrôle, mais elle change aussi la frontière de sécurité : une règle entrante imprécise peut exposer des ressources qui étaient auparavant protégées par le comportement NAT du MX.

La fonction a enfin des incompatibilités à connaître. Le No-NAT ne s’applique pas aux VRF autres que celle par défaut et son interaction avec le Client VPN ou les connexions IPsec initiées depuis l’extérieur doit être examinée avant déploiement.

Historiquement, une politique Meraki était souvent configurée réseau par réseau. MX 26 introduit une logique plus centralisée avec les Organization-wide Group Policies.

Une entreprise peut définir une politique une seule fois, y attacher des ensembles de règles et l’appliquer à plusieurs VLAN ou groupes de sécurité dans différents réseaux. Les règles peuvent combiner des critères de couche 3 et de couche 7. MX 26.2 étend cette logique à davantage de critères IPv4 et IPv6, à des destinations FQDN, à des objets réutilisables et à une journalisation par règle.

Pour un parc multisite, le bénéfice est immédiat : une règle destinée aux terminaux de paiement, aux équipements audiovisuels ou aux objets connectés ne doit plus être recopiée dans chaque agence. Une modification centrale est propagée aux MX concernés, ce qui réduit les divergences et facilite l’audit.

Ce nouveau cadre ne se superpose toutefois pas mécaniquement aux règles existantes. Lorsqu’un trafic utilise une politique de groupe à l’échelle de l’organisation, les règles classiques de la page Firewall du réseau ne s’appliquent pas à ce trafic de la même façon. Les réseaux utilisant cette fonction ne peuvent pas non plus être liés à un template dans l’implémentation actuelle.

Le changement est donc autant organisationnel que technique. Il faut décider quelle équipe possède les objets communs, comment les modifications sont relues et comment éviter qu’une politique globale contredise une règle locale encore présente dans le Dashboard.

Le blog BoucheCousue avait présenté Cisco Meraki Adaptive Policy lorsque la fonction concernait surtout la segmentation dans le LAN. MX 26 étend désormais cette logique jusqu’au routeur de sécurité.

MX 26.1.2 permet d’attribuer un Secure Group Tag, ou SGT, à partir d’une Group Policy et de faire correspondre un SGT reçu à une politique. MX 26.2.1 ajoute l’association d’une adresse ou d’un sous-réseau à un SGT, puis l’application de Security Group ACL, ou SGACL, directement sur le MX.

Cette évolution permet d’exprimer une règle avec des identités logiques plutôt qu’avec une succession d’adresses et de VLAN. Un terminal classé « IoT », « Finance » ou « Prestataire » peut conserver son groupe de sécurité lorsqu’il traverse différents segments ou AutoVPN. La politique suit alors davantage le rôle du terminal que son emplacement.

Le modèle reste conditionné par les versions, les licences et le dessin du réseau. L’attribution par Group Policy et l’application de SGACL n’ont pas les mêmes prérequis de licence. Le MX doit aussi router le trafic pour appliquer la règle, et une mauvaise combinaison entre politiques de groupe classiques et SGT peut produire un comportement difficile à prévoir.

La nouveauté de sécurité la plus visible de MX 26.2 est l’inspection TLS et HTTPS. Le MX termine temporairement la session du client, déchiffre le trafic, l’examine, puis établit une nouvelle connexion chiffrée vers le serveur. L’IPS peut ainsi rechercher des menaces dans un flux qui serait autrement opaque.

Cette capacité répond à un problème réel : la majorité des applications et des téléchargements utilisent HTTPS, y compris les contenus malveillants. Un équipement qui ne voit que les adresses, les ports et quelques métadonnées dispose d’un contexte limité pour détecter une charge utile dangereuse.

Mais l’inspection HTTPS n’est utile que si son déploiement est maîtrisé.

Les terminaux inspectés doivent faire confiance à l’autorité qui permet au MX de générer les certificats intermédiaires. Dans un parc géré, cette autorité peut être distribuée par MDM ou par stratégie de groupe. Sur un appareil non maîtrisé, l’utilisateur verra des alertes ou l’application refusera simplement la connexion.

Les applications utilisant le certificate pinning, certains services de paiement ou des logiciels de santé peuvent refuser une connexion interceptée. Cisco prévoit des exclusions par adresse, FQDN, catégorie ou application. Le trafic utilisant Encrypted Client Hello peut également échapper au déchiffrement selon la configuration.

Déchiffrer, inspecter puis rechiffrer une session sollicite le processeur et la mémoire. Le débit peut diminuer et la latence augmenter, y compris sur d’autres flux lorsque l’appliance approche de ses limites. Activer ou désactiver l’inspection termine aussi les sessions HTTPS déjà établies qui sont concernées par le changement.

La recommandation la plus prudente est donc une activation ciblée par Group Policy sur des terminaux gérés, après distribution du certificat et mesure des performances. Une activation réseau entière peut casser immédiatement les équipements qui ne possèdent pas l’autorité de confiance.

Enfin, le déchiffrement seul n’apporte pas de protection : le trafic ainsi rendu visible doit être analysé par l’IPS. Sans IPS actif, l’entreprise paie le coût technique de l’interception sans en obtenir le bénéfice de sécurité attendu.

MX 26.2.2 ajoute les Custom Intrusion Policies. Au lieu de choisir uniquement entre les profils standards Connectivity, Balanced ou Security, l’administrateur peut partir de l’une de ces bases puis modifier des groupes de règles ou des signatures Snort 3 individuelles.

Cette granularité répond aux environnements où une signature provoque un faux positif sur une application métier, ou lorsqu’une catégorie particulière doit être renforcée sans activer le profil le plus strict partout. La politique est créée au niveau de l’organisation puis affectée aux réseaux concernés.

Les limites sont importantes : la fonction nécessite MX 26.2.2 ou plus récent, un matériel compatible avec Snort 3 et une licence adaptée. Une organisation peut créer au maximum dix politiques personnalisées. Une politique utilisée par un réseau ne peut pas être supprimée avant d’en être détachée.

Une sélection plus large de signatures augmente aussi la charge d’inspection. Meraki recommande de valider les performances dans un environnement contrôlé, particulièrement lorsque l’inspection HTTPS et une politique IPS personnalisée sont activées ensemble.

Dans une paire Meraki MX Warm Spare, l’équipement secondaire a longtemps surtout attendu de prendre le relais. Avec WAN Uplink Sharing, MX 26.2 permet au routeur actif d’utiliser un circuit physiquement connecté à l’autre appliance.

Deux opérateurs peuvent ainsi être répartis entre les membres de la paire sans imposer nécessairement une desserte identique des deux côtés. Le trafic vers l’uplink distant traverse un VLAN d’interconnexion HA. Cette logique améliore l’utilisation du matériel de secours et ouvre une forme de fonctionnement actif-actif pour les liens WAN, tout en conservant le mécanisme de bascule des MX.

Cette fonction ne doit pas être confondue avec un cluster actif-actif où les deux routeurs traiteraient indistinctement tout le trafic LAN. Le Dashboard conserve un MX actif pour le routage principal ; le spare met son uplink à disposition au travers du lien HA.

MX 26.2.2 comporte encore plusieurs problèmes connus dans ce domaine. Certains réglages IPS personnalisés peuvent empêcher l’établissement des uplinks partagés. Des sessions iBGP peuvent rester inactives même lorsque AutoVPN fonctionne, et des sous-réseaux qui se chevauchent sur les liens partagés peuvent provoquer des reconnexions eBGP répétées. Le partage de plusieurs uplinks avec un pair VPN Non-Meraki et une adresse virtuelle peut aussi empêcher l’établissement des tunnels.

Ces réserves illustrent précisément l’intérêt du statut bêta : la fonction est assez avancée pour être testée, mais pas pour être généralisée sans qualification de la topologie exacte.

MX 26.2.2 ne se limite pas aux protocoles. La version introduit un nouvel onglet Ports et des profils de ports à l’échelle de l’organisation. Un administrateur peut définir un profil access ou trunk, les VLAN, le PoE et certains paramètres Adaptive Policy, puis l’affecter à plusieurs ports.

La fonction vise les Cisco 8000-G2-MX et exige MX 26.2.2 avec le mode VLAN. Dans sa première bêta, elle n’est pas disponible en Single LAN, ne fonctionne pas avec les templates et ne prend pas en charge les Access Policies. Il ne faut donc pas la présenter comme un remplacement universel de la configuration des ports de tous les MX.

La gestion cellulaire progresse également. MX 26.2.2 permet de créer des profils de consommation de données, d’afficher l’état de la carte SIM et de gérer son code PIN depuis la page locale. Les API exposent davantage d’informations sur la géolocalisation, la cellule utilisée et les bandes radio. Les Z4 et Z4C peuvent convertir leur port 2 en second uplink WAN filaire.

Ces ajouts paraissent secondaires face aux VRF ou à l’inspection HTTPS. Ils participent pourtant au même mouvement : rendre la configuration plus réutilisable et réduire les opérations locales lors d’un déploiement multisite.

Un réseau peut être programmé pour MX 26 sans que chaque équipement exécute ce code. Les restrictions de version par matériel restent déterminantes.

Les MX64, MX65, MX84, MX100 et vMX100 ne peuvent pas dépasser la génération MX 18.1. Lorsqu’un réseau contenant ces modèles reçoit une version plus récente, ils exécutent une version de maintenance MX 18.107.x indiquée dans les notes de version. Les Z3 et Z3C restent sur MX 19.2.x.

Cette situation a deux conséquences. D’abord, les nouvelles fonctions de MX 26 ne deviennent pas disponibles sur ces appareils. Ensuite, un parc mêlant plusieurs générations peut afficher le même firmware cible dans le Dashboard tout en exécutant des versions différentes selon le modèle.

Le sujet rejoint directement la fin de support du Meraki MX84 et la stratégie de renouvellement matériel. Une fonction comme VRF, l’inspection HTTPS ou le MultiWAN peut nécessiter non seulement une nouvelle version, mais aussi le remplacement d’une appliance et parfois une évolution de la licence Cisco Meraki Subscription.

MX 26 ne rend pas soudain tous les réseaux plus simples. Il donne au Dashboard des outils pour administrer des architectures plus ambitieuses sans abandonner le modèle cloud Meraki.

Pour une PME possédant quelques sites, le bénéfice le plus concret pourra être une politique commune, un VPN mieux adapté à des plans d’adressage qui se chevauchent ou un second lien plus utile en haute disponibilité. Pour une entreprise multisite, VRF, BGP, SGT et les règles d’organisation peuvent réduire la duplication des configurations. Pour un environnement fortement sécurisé, l’inspection HTTPS et les politiques Snort personnalisées apportent une visibilité plus profonde, au prix d’une exploitation plus exigeante.

La contrepartie est claire : plus le MX sait faire de choses, moins une mise à jour peut être traitée comme une simple opération de maintenance. Les dépendances entre firmware, matériel, licence, certificat, politique et topologie deviennent une partie du projet.

MX 26.1 constitue aujourd’hui le socle à considérer lorsqu’une fonction 26.x répond à un besoin identifié. MX 26.2 permet de préparer la suite et de conduire des pilotes ciblés. Le maintien de MX 19.2 comme branche Recommended rappelle toutefois qu’il n’existe pas encore une réponse unique pour tous les réseaux Meraki.

Vous souhaitez savoir si MX 26 apporte un bénéfice réel à votre parc, ou qualifier une fonction comme VRF, MultiWAN, Adaptive Policy ou l’inspection HTTPS ? BoucheCousue peut vous accompagner pour inventorier les modèles et licences, définir un périmètre de test et sécuriser la montée de version de vos routeurs Cisco Meraki.