La release IOS-XE 17.4 est sortie sur nos switchs catalyst (et quelques autres plateformes). Pour les petits nouveaux je rappelle la règle : 3 releases par an (juillet / novembre/ mars) avec un support plus long (et donc avec davantage de rebuilds) pour la release d’été sur laquelle il convient de se greffer quand on cherche à stabiliser les opérations. Ces petits schémas que vous commencez à connaître vont vous aider à visualiser tout cela.
Comme toujours je liste ici quelques nouveautés principales, vous savez que tout est documenté précisément sur les release notes. Je rappelle que nous avons le même IOS-XE sur toutes nos plateformes Catalyst 9000, facilitant largement les opérations. Je liste également quelques nouvelles features en “limited availability” que vous ne trouverez pas sur les release notes. Vous devez nous contacter avant de les utiliser afin qu’on puisse suivre ensemble que tout se passe bien. Le support est fourni directement par la business unit. Voyons les nouveautés principales:
- RadSec. Et si votre serveur Radius était dans le cloud ? RadSec vient permettre d’encapsuler les requêtes Radius dans une couche TLS afin de sécuriser les échanges, et aller bien au-delà de la “sécurisation” md5 native au protocole. On avait déjà RadSec depuis un moment sur Catalyst 9300, ici on étend le support à toute la gamme. RadSec est supporté dans les VRF, un peu de patience pour IPv6 qui arrivera plus tard.
- Stealthwatch Cloud connector (Limited Availability). Stealthwatch est notre solution de sécurité basée sur l’analyse des flux. En observant mes flux en tout point de votre réseau on peut par exemple observer si un ver ne se ballade pas d’est en ouest, à l’insu de vos firewalls et IDS/IPS en périphérie. Stealthwatch cloud suit globalement le même principe, offert as-a-Service, et intègre des spécificités pour les environnements cloud. Internet oblige, il faut envoyer les flux de manière sécurisée (TLS) et optimisée (compression). C’est tout le principe de ce connecteur Stealthwatch Cloud sur les switchs.
- FQDN dans ACL de redirection (Limited Availability). Quand les services sont on-prem on peut connaître les IP, mais quand tout part dans le cloud cela devient compliqué, l’IP pouvant d’ailleurs varier selon la région. Ici il est possible de rajouter un FQDN dans une ACL de redirection et garder ainsi des configurations homogènes et simples sur un parc international.
- Customisation de la mémoire pour les ACL. Sur les plateformes en UADP 3.0 (9500H, 9600), offrant le plus de scale, on sait redéfinir comment la mémoire peut être utilisée avec une customisation des SDM templates. En gros si vous avez besoin de plus de mémoire pour le NAT ou NETFLOW, et que vous n’avez pas beaucoup d’ACL configurées, vous pouvez réallouer l’espace mémoire non utilisé.
- Intégration des Private VLAN avec VXLAN-EVPN. Ici il est possible au sein d’un même VXLAN de définir des community VLANs qui pourront ou pas communiquer entre eux. Avis aux amateurs de micro-segmentation qui seraient tentés par le “do-it-yourself”. Bon courage quand même pour arriver à la flexibilité que l’on a sur SD-Access.
- Smart Licensing Enhanced. Cette évolution du Smart Licensing est arrivée en 17.3.2 et vous avez peut-être pu voir une jolie bannière orange sur software.cisco.com. Je ferai un article dédié sur le sujet mais l’idée est que le switch accepte toute nouvelle licence sans aucune vérification. Le switch ne fait aucun contrôle et accepte le niveau de licence qu’on lui demande d’activer. Il peut générer un rapport d’utilisation pour contrôler la consommation de vos licences sur votre portail CSSM. On était déjà hyper souples puisque tous les services continuaient toujours à fonctionner que l’on était compliant ou non… Là c’est encore plus basic, vous indiquez ce que vous voulez et le switch dit amen 🙂
- Télémétrie pour l’usage de la TCAM. Pour ceux qui commencent à apprécier la streaming telemetry avec gRPC, on sait maintenant remonter en temps réel l’usage de la TCAM. D’autres modèles YANG ont également été améliorés (BGP, HSRP…) Connectez-vous sur Devnet et GitHub pour voir tous les modèles supportés et leur évolution.
- Wired sensor (Limited Availability). Les sondes c’est toujours pratique pour pouvoir simuler un client qui se connecterait au réseau. Nous avons depuis quelque temps déjà des sondes wireless. Ici nous avons une sonde filaire qui peut être déployée sur les switchs grâce à la capacité de app-hosting disponible à partir du Catalyst 9300/L. Cette sonde est un container Docker, déployée depuis Cisco DNA Center, qui va faire des tests sur le réseau (authentification, FTP, mail, web…). Les résultats des tests sont ensuite remontés sur Cisco DNA Center qui offre une compréhension globale du réseau et de l’expérience utilisateur. Une nouveauté est que cette sonde n’a pas besoin d’un disque SSD externe (USB) mais peut tourner directement sur la flash du switch. C’est tout récent d’où le “limited availability” et il y a aussi des dépendances avec Cisco DNA Center. Consultez-nous si envie d’en savoir plus. J’en profite pour rappeler que vous pouvez aussi faire tourner des agents ThousandEyes, solution qui a intégré Cisco cet été.
J’ai omis volontairement quelques autres nouveautés. Pour les détails consultez les release notes.
Authors
