J’ai eu l’occasion de participer cette semaine aux Masters Data Center dans les nouveaux locaux de Cisco France à Paris. L’occasion de faire le point avec les “technical solution architect” français sur les produits Data Center, de voir quelques deep dives, packet walks, et les roadmaps des produits à venir en 2024. Je profite donc de cette occasion pour dépoussiérer ce blog :)

Au programme du mercredi :

• Nouveautés et update ACI
• Update produit : pourquoi évolution 400G/800G
• NXOS / NDFC
• Insertion de service en VxLAN
• Sécurité et micro-segmentation embarquée sur ACI
• Nexus Dashboard et Insights

Voici quelques notes des passages qui m’ont intéressé le plus.

Nouveautés et update ACI

ACI est toujours la solution privilégiée aujourd’hui en Data-Center dans la gamme des produits Cisco, il me semble important de le rappeler, car NDFC n’est pas aussi abouti, moins mature selon moi. En 2024, Cisco cherche à développer l’adoption des différentes features offertes par ACI, car beaucoup de clients ont déjà renouvelé leurs DC mais sont encore beaucoup en “network-centric” et n’utilisent pas vraiment les fonctions avancées (contrats, L4/L7 services…etc). Cisco cherche aussi à développer la partie opérationnelle via le couplage avec NDI (Nexus dashboard Insights) qui offre des options supplémentaires de visualisation et d’assistance au troubleshooting (moyennant le bon niveau de licence, dont le modèle à changé récemment). L’adoption est d’ailleurs poussée via la proposition de “healthcheck ACI”, grâce à des rapports NDI pour les clients qui le souhaitent afin d’en démontrer les avantages.

La cadence des releases change légèrement pour devenir “prédictibles”. À partir de la 6.0, les 3 premières releases sont orientées features (6.0.1, 2 et 3) sur une durée de 12 mois, à partir de 6.0.4, ils freezent le code, et passent en maintenance release pendant 15 mois, par la suite, bug fix exceptionnels seulement, avec focus sécurité et CVE pendant 15 mois à nouveau, il restera alors 6 mois pour upgrader en version supérieure. Il faudra donc changer de train tous les 2 ans environ, ce qui semble une durée raisonnable, surtout lorsque tous les endpoints sont double attachés (possible d’upgrader les équipements pairs/impairs facilement, sans coupure.

La version 5.2(8) est la version recommandée à ce jour. La version 5.3(1) est aussi recommandée pour les clients qui veulent rester sur le train 5.x mais ayant renouvelé leurs APICs avec les nouveaux modèles M/L4. Ces APICs apportent un changement de processeur (AMD) ainsi qu’un changement d’OS (CentOS) et l’appliance est à base d’UCS Gen6.

Cisco développe sa capacité à patcher, pour ajouter du code sur le train logiciel, en ne fixant que ce qui est fixé, 90% des patchs fournis aujourd’hui sont côté control-plane, et ne nécessitent pas de reboot. Ils essayent de faire des patch “hitless”, sans dégradation de traffic. (patchs = SNU = software maintenance update).

Le portfolio N9K évolue avec l’arrivée de la gamme 800G, sur les gros chassis modulaire, assez peu déployés chez les clients. Le scale initialement “arbitraire” en termes de nombre de leafs supportés par Fabric va augmenter, les chiffres annoncés (voir les “scalability guides” ici : https://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html) sont surtout basés sur les tests Cisco , les chiffres évoluent régulièrement.

Les déploiements d’APIC deviennent plus flexibles. Il est possible de ne plus avoir d’APIC connecté aux leafs directement, cela fait suite à des directives de l’ANSSI qui conseille d’avoir des zones de configurations déportées des ports de production. Les nouveaux modes de déploiements sont :

• remote apic cluster > deploy APIC in a remote secure zone
• virtual apic cluster > deploy APIC on ESX hypervisor over L3 network
• cloud hosted apic cluster >deploy APIC in the cloud to manage the on-premise (aws prêt en ACI 6.0.3F, future release pour Azure/GCP)
• NaaS > manage network fabric from cloud as a service

L’intégration d’ACI avec le Campus est également un sujet régulièrement demandé par nos clients (étendre les contextes entre DC et Campus), et annoncé depuis longtemps par Cisco, et semble arriver pour ACI en 6.1.1F et ISE en 3.4 dans le but de faire communiquer les SGT (DNA) avec des EPG (ACI), en utilisant un connecteur entre ACI et ISE, via l’utilisation des licences PXGRID. Actuellement cette intégration est limitée à 1 tenant/1 vrf donc inutile en l’état.

La version 6.1.1F apporte d’autres lots d’améliorations, parmi lesquels :

• Autonomous Remote Leaf (6.1.1F) : si un site distant est composé de plusieurs remote leafs (ex: 5x 2 VPC), en cas de perte de WAN, il était compliqué pour eux de commuter/router des paquets entre eux, mais des la 6.1.1F, la commutation locale sera supportée.
• ACI: Open-standards interop (6.1.1F) : les borders leafs vont supporter l’interco VXLAN standard
• Increasing traffic analytics in ND (6.1.1F) : couverture ACI complète, vue “services”, plus d’options de tshoot
• VMM & open-source integration (6.1.1F) : 5.2(8) ⇒ support vSphere 8, 6.0.3F ⇒ Nutanix AHV arrive !

Un dernier point sur la roadmap long terme, en février 2024, Cisco prévois de rationaliser l’interface des APICs, ils vont l’aligner avec NDI.. Et c’est donc assez effrayant pour ceux qui sont habitués à l’interface actuelle, wait & see :)

Data Center Switching

Du côté du Hardware, comme indiqué plus haut, gros focus de Cisco sur le support du 100/400/800G.

Ce qui m’impacte le plus, et surtout mes clients ces derniers temps c’est la fin de vie annoncée fin Aout des 9332C qui sont beaucoup utilisés en Spine, donc le remplaçant est le N9K-C93600CD-GX, pas vraiment évoqué ici.

Je retiens qu’un nouvel ASIC “Cisco” arrive, et ils vont le standardiser, homogénéisation des ASICs des équipements, et ça signe donc la fin du “cloud-scale ASIC” à long terme… EOL à venir 🙂 ils commencent par les équipements avec forte densité de ports / bande passante (C9800), et seront déclinés sur les plus petits “form-factor”.

Du côté Software VXLAN / NX-OS, la micro-segmentation avec VXLAN EVPN arrive en fin d’année 2023, via des VXLAN GPO (Group Policy Object) transporté dans le header VXLAN (draft ietf en cours), le but étant de classifier les endpoints, basé sur IP/MAC…, un peu comme l’EPG dans ACI. Le service chaining basé sur les groupes arrivera fin 2024, ainsi que l’intéropérabilité avec ACI.

Ici aussi on surfe sur l’IA, parce que oui, pour que l’IA fonctionne, il faut un réseau performant, alors il y a un guide intéressant qui est mis à disposition – blueprint AI/ML pour les DC Cisco.

Démo NXOS / NDFC

Belle présentation de la configuration d’un DC VXLAN via NDFC, ainsi qu’avec Ansible, j’ai pris plus de temps à regarder/écouter qu’à prendre des notes.

Démo VXLAN EVPN / Zoom sur l’ePBR

L’ePBR est l’outil principal pour la création de service-chaining avec VXLAN EVPN, une démonstration complète a été faite sur la feature, peut-être l’occasion de dédier un article à cela plus tard.

Quelques points qui me paraissent importants :

• La redirection PBR intra-site est plutôt simple, très similaire a ACI finalement, une ACL et une policy de redirection vers le firewall. Cela se complexifie en inter-site lorsqu’on passe les border gateways, il est obligatoire d’avoir un firewall dans une VRF distincte et d’étendre cette VRF partout (tous les leafs/spines)
• Nécessité de la licence Advanced !
• Attention au Scale (150 services par switch, 62 ACL/switch, 16 policies/VRF), pour  vérifier : show hardware access-list resoruce utilization
• Les templates d’automatisation dans NDFC pour l’ePBR ne seront disponibles qu’en version NDFC 12.1.3b, en attendant, il faut passer par du “free-form”, plus complexe, full support en 12.2.1 (Q1 2024)

Fin de la session en rappelant qu’ACI est la solution la plus aboutie, on n’en doutait pas.

Cisco Security in ACI

Présentation très intéressante également autour de la sécurité et ACI.

Rappel des objectifs principaux des équipes sécurité : Visibilité, Segmentation et protection contre les menaces.

Le problème : la complexité des politiques entre les environnements hybrides (on-prem, multi-clouds…), mais dans cette session, un focus est fait sur ACI, on-premise.

Rappels ACI :

• ACI n’est pas un firewall
• ACI fait du zero-trust par défaut (VRF enforced)

La segmentation est faite par Tenants, VRF, contrats (acl refléxive stateless).. Attention à l’option “stateful”, elle ne fait que vérifier le “ack” bit pour vérifier le sens de la communication, ACI n’a pas de table de session comme un “vrai” firewall.

Utiliser les contrats pour insérer des “service graphs”, et envoyer du flux aux firewalls.

• EPG = attacher un serveur au réseau + assigner une politique de sécu
• ESG = possibilité de grouper des workloads, sans orienter réseau (le slide 19 est top pour le présenter), via les “tags”.

La session à permis de mettre en avant l’insertion firewall via les L4/L7 services (service-graph) que j’ai d’ailleurs présenté en détail dans mon unique vidéo Youtube.

Ce type d’insertion marche bien, pour du Nord/Sud comme pour de l’Est/Ouest. Cependant, pour les flux Est/ouest, la plupart des clients ont du mal à forcer le filtrage, car ils connaissent mal leurs flux, et c’est là qu’un produit comme Cisco Secure Workload peut avoir un réel intérêt.

À base d’agent sur tous les hôtes d’une application, (ou via une redirection Netflow depuis un Firewall – solution intéressante! qui nécessite une licence 50 hôtes pour le moment), il est possible de placer l’orchestrateur CSW en mode écoute pendant plusieurs heures/jours, puis de choisir le traffic légitime ou non plus tard.

L’enforcement de la sécurité peut alors se faire directement depuis CSW, au plus proche des endpoints, ou alors, envoyer la politique de filtrage vers des firewalls Cisco (limité à Cisco malheureusement), et une prochaine feature long terme “pourrait” permettre de traduire ces politiques en contrat… à suivre !

Je terminerai en remerciant tous les présentateurs de la journée pour la qualité des présentations, la qualité Cisco Live, en Français, à la maison. 🙏

Benoit

Network engineer at CNS Communications. CCIE #47705, focused on R&S, Data Center, SD-WAN & Automation.

More Posts - Website

Follow Me: