Cisco SD-Access est l’architecture Zero-Trust pour le campus, déjà déployée par plusieurs milliers de clients. Nous verrons ensemble comment Cisco SD-Access permet  une automatisation complète du réseau et de ses services, une expérience utilisateur sans précédent, et une sécurité optimale des terminaux connectés. L’architecture SDA assure un contrôle d’accès complet, une micro-segmentation intégrée et une remédiation en cas de détection d’anomalies.

J’agrémenterai ma présentation de nombreuses démos. N’hésitez pas à me dire en commentaires si vous souhaitez que j’adresse des points particuliers!

Les fondamentaux de Cisco SD-Access
DETAILS ET INSCRIPTIONS

Agenda

• Pourquoi SD-Access ?
• Bénéfices de la solution
• Les blocs fonctionnels
• Cas d’utilisation

@JeromeDurand

Aujourd’hui nous allons rester dans le thème des solutions collaboratives, mais en profitant d’une autre fonctionnalité de l’agent ThousandEyes Endpoint.

Comment mieux superviser les expériences collaboratives (Webex, Microsoft Teams, Zoom) ?

Le monde hybride a mis en exergue l’omniprésence des outils de collaborations dans nos quotidiens. Pouvons-nous réellement nous passer de ces outils dans le monde digital actuel ?

Nous allons discuter de la fonctionnalité “Automated Session Tests” qui va permettre de suivre l’expérience d’un utilisateur dès que ce dernier lance l’application collaborative de son choix ! Notre exemple se portera sur la solution Microsoft Teams et nous publierons dans le futur un exemple similaire avec l’application Cisco Webex, afin de montrer les synergies avec ThousandEyes.

Si on souhaite surveiller l’application Microsoft Teams de manière complètement exhaustive, la liste de subnets IPs dédiée a celle-ci est vraiment longue. Est-ce une bonne approche de surveiller l’ensemble des subnets & noms de domaines fournis par l’opérateur ? Dans certains cas oui, mais peut-être que l’on peut aussi faire différemment ?

Une application de visioconférence comme Webex, Microsoft Teams, Zoom, est de nature dynamique :

• D’une part, lorsqu’un utilisateur va rejoindre une réunion, ces applications vont essayer de joindre le(s) datacenter(s) le(s) plus proche(s) d’eux.
• D’autre part, les participants d’une même réunion ne vont pas forcément arriver sur les mêmes ponts audio/vidéo dans le back-end de ces solutions en fonction de leur localisation.

Lorsque je vais rejoindre une réunion Microsoft Teams, l’agent ThousandEyes sera capable de suivre les requêtes qui seront envoyées aux serveurs de Microsoft, de façon totalement dynamique. Et c’est là que toute la magie opère avec la fonctionnalité “Automated Session Tests”.

Depuis le dashboard SaaS de la solution, l’administrateur peut définir des réglages de base assez simple, qui se dérouleront dans l’onglet Endpoint Agents → Test Settings → Automated Session Tests :

On se retrouve avec deux solutions de visioconférences qui sont surveillées, Microsoft Teams et Webex.

Le mardi 24 Janvier 2023, j’ai donc rejoint une réunion Microsoft Teams qui a été initiée par un des partenaires avec qui je travaille au quotidien.

À l’issue de la réunion, je me rends sur le dashboard ThousandEyes, et nous pouvons constater que l’agent a bien déclenché sa surveillance sur la durée de la réunion, soit de 9h30 à 10h :

Il n’y a pas uniquement la collecte d’informations de type Loss/Jitter/Latency. Comme je le disais, l’agent ThousandEyes est aussi capable de montrer à l’administrateur ThousandEyes quelles sont les adresses IP que l’application Microsoft Teams a résolu dans le backend.

Derrière ces différentes addresses IPs se retrouvent des services, qui sont utilisés pour rejoindre une réunion, initier le partage du son et de la vidéo, un partage d’écran, etc. Et elles peuvent être différentes pour chaque collaborateur :

Étant client chez l’opérateur Orange, on peut se rendre compte à gauche de l’image ci-dessus que je passe bien par le réseau de mon opérateur d’une part, avant d’atteindre l’infrastructure Microsoft (AS 8075). Les flux de l’application sont ensuite dirigés, pour différentes raisons et besoins, vers les adresses IP :

• 52.114.104.14 (localisée à Paris),
• 52.114.253.102 & 52.114.253.13 (localisées à Amsterdam),
• 52.114.76.236 (à Dublin) et
• 20.189.173.13 (dans l’IOWA aux USA).

En cliquant sur le noeud “Microsoft Corporation”, nous pouvons savoir les chemins que nous utilisons dans l’infrastructure Microsoft pour joindre l’ensemble de ces destinations.

Cela a pour objectif de savoir d’où pourrait venir un éventuel problème qui serait caractérisé par un lag, coupure vidéo, etc, du point de vue de l’utilisateur final. Ci-dessus, un lien dans le backbone de Microsoft, qui a une latence exceptionnellement anormale d’environ 111ms.

Un moyen de s’assurer de votre stratégie de split tunneling ?

Vers la fin de la réunion avec mon partenaire, j’ai voulu aller un peu plus loin dans les tests. Je me suis donc connecté au VPN de mon entreprise afin de voir ce que l’agent pourrait remonter. À vrai dire, j’ai été coupé de la réunion pendant 10-20 secondes, le temps de récupérer l’audio et la vidéo.

On voit immédiatement la différence au niveau de ce qui est remonté par l’agent ThousandEyes :

On constate que l’on passe maintenant par un VPN via l’outil Cisco AnyConnect, et que les adresses IPs de destination ont elles aussi changées. On se retrouve donc avec 51.104.15.252, 52.113.194.132, 20.189.173.10 et 52.114.253.39 localisées dans différents pays dans le monde.

Il est donc intéressant de noter que pour Microsoft Teams, et de manière spécifique pour cette application, le split tunnelling n’est pas réalisé lorsque je me connecte en VPN. L’ensemble des flux est redirigé maintenant vers le réseau interne Cisco (sans doute pour des raisons de sécurité et de contrôle).

Pour finir, j’ai aussi réalisé le test de connectivité VPN pendant une réunion Webex. Que pouvons-nous voir ?

Lorsque je me connecte via AnyConnect, l’agent ThousandEyes Endpoint détecte qu’un nouveau canal de communication existe et commence à lancer des « probes ». Contrairement à l’expérience sur Microsoft Teams, je continue à utiliser ma sortie internet locale pour rejoindre les services Webex, et je ne subis donc aucune coupure lors de cette nouvelle connexion. Le split tunnelling est activé pour le service Webex, et nous voyons que le chemin via le VPN n’est donc pas utilisé.

C’est donc un excellent moyen pour les équipes techniques/IT de s’assurer que la stratégie globale de split tunneling (multi-site, voire multi-pays/continents) est bien conforme aux attentes opérationnelles.

Conclusion

Pour rappel et en guise de conclusion, la fonctionnalité “Automated Session Tests” permet à l’agent ThousandEyes de :

• Se déclencher automatiquement lorsqu’un utilisateur rejoint une réunion de visioconférence (Webex, Microsoft Teams, Zoom)
• De collecter des métriques réseaux de type Loss/Jitter/Latency
• D’identifier plus facilement le dynamisme constant de ces applications de visioconférence. Des utilisateurs au sein d’une même réunion peuvent arriver sur des serveurs différents. En conséquence, l’expérience d’un collaborateur peut être bien différente d’un autre pour diverses raisons.

Alors, le saviez-vous ?

Mes contacts : #twitter / #linkedin

• Passer sur des châssis (et là pas de problème, on a les Catalyst 9600 et 9400 parfaitement taillés pour faire le travail)
• Séparer la distribution en 2 blocs, et rajouter un étage de coeur (pas de problème non plus avec la famille Catalyst 9500)

Globalement rien de dramatique mais voilà, parfois quand on approchait la limite on pouvait sentir une certaine frustration. Le dernier né des Catalyst 9500, le C9500X-60L4D vient changer la donne, offrant une densité plus importante, toujours sur un RU. Déjà essayons de décrypter le nom de l’équipement, ça vous en dira long sur ses capacités:

• C9500X: il s’agit d’un Catalyst 9500-X, basé sur l’ASIC Silicon One Q200, offrant jusqu’à 12.8Tbps de performance et un scale très important avec 2M de routes IPv4
• 60L: là il faut se rappeler des chiffres romains. L = 50. On a donc 60 ports 10/25/50 GE SFP56 non bloquants
• 4D: ici aussi partons des chiffres romains. D = 500. On va faire une petite approximation parce qu’il s’agit de ports 100/400 GE QSFP-DD

Normalement vous devriez pouvoir décrypter les noms de toutes les plateformes maintenant, même pas besoin de demander à chatGPT

Comme vous pouvez le voir sur la photo ci-dessous, c’est dense! Il ne reste pas beaucoup de place pour coller une étiquette mais heureusement on a le RFID qui est présent ainsi que toutes les fonctionnalités qu’on a sur la gamme Catalyst 9000. C’est bien le même IOS-XE qui tourne sur tous les équipements.

Côté sécurité, on dispose de WAN-MACSEC sur tous les ports et en plus on trouve sur cette plateforme un module de crypto IPsec comme sur les derniers 9300X. Les Object-group ACL et Security group ACL vont permettre de configurer des règles plus simplement avec un maximum de scale (on évite de gaspiller une entrée par préfixe IP!)

Je poursuis sur le scale: là aussi on va pouvoir comme sur le reste de la gamme décider de la manière d’utiliser la mémoire via l’application de SDM template customisé. En gros si vous voulez plus de routes multicast, d’adresses MAC, ou de labels MPLS… vous pouvez ajuster en fonction de vos besoins. Mais avec 2M de routes IPv4 et 256k adresses MAC vous avez de quoi faire.

Que faire de cette plateforme justement? Ce que vous voulez! Core L3, distribution, SD-Access border, BGP EVP VXLAN border leaf, MPLS router, stackwise-virtual ou standalone, management via Cisco DNA Center, monitoring dans le dashboard Meraki , automatisation par Ansible, remontée de télémétrie dans un stack ELK ou TIG… comme toujours vous avez le choix!

N’hésitez pas à réagir à cet article si vous souhaitez parler design!

Plus d’informations sur la datasheet des Catalyst 9500

@JeromeDurand

En effet, Cisco vient d’annoncer, le 31 mars 2023, la fin de vie de Prime Infrastructure.

Pour être plus précis, il s’agit d’une annonce la date d’arrêt de commercialisation et de fin de vie de l’Appliance Gen3 de Prime Infrastructure, de la version Software 3.10 et des Licences associées.

Les clients ont jusqu’au 29 septembre 2023 pour commander les produits concernés. Le centre d’assistance technique de Cisco (TAC) continuera de prendre en charge les clients dont les contrats de service sont en cours, comme illustré dans le tableau 1 du bulletin de fin de vie des produits, qui peut être représenté ci-dessous :

* dates sujettes à changement

Cisco propose deux chemins de migration pour remplacer Cisco Prime Infrastructure:

• Solution “managée” avec Cisco DNA Center
• Solution Cloud SaaS avec Dashboard Cisco Meraki

Cisco DNA Center est un contrôleur “Intent-Based Networking” qui apporte de l’automatisation réseau, de l’assurance et analytique basée sur AI/ML, de l’architecture Software-Defined Access (SD-Access).

Cisco DNA Center peut être déployé sur une appliance physique, dans un cloud public AWS, et dans un cloud privé utilisant ESXi de VMware.

Pour faciliter la démarche de migration vers Cisco DNA Center, différents outils sont disponibles :

• PDART – Prime to DNA Assessment Readiness Tool : qui fait l’audit de l’installation de Prime Infrastructure du client dans le but de migrer vers Cisco DNA Center
• DMT – DNA Migration Tool : qui automatise la migration des données existantes dans Prime Infrastructure vers un DNA Center de façon progressive.

Cisco Meraki Dashboard est une solution basée sur le cloud qui facilite le déploiement et la gestion de l’infrastructure réseau via un tableau de bord centralisé intuitif. L’architecture basée sur le cloud de Cisco Meraki permet une mise en œuvre de façon transparente de l’évolution des infrastructures réseaux.

Cisco Meraki offre aux entreprises une solution complète et facile à utiliser qui améliore la visibilité, la sécurité et l’intelligence via une interface de gestion unique.

Ne pas hésiter à revenir vers les équipes Cisco ou partenaires pour toute information complémentaire et pour vous accompagner dans cette démarche.

Informations additionnelles:

Portail Migration Prime Infrastructure

Visualiser cette video de 4 minutes

PDART Tool

Tips and Tricks for Prime Infrastructure to Cisco DNA Center Migration

Demystifying Prime Infrastructure to Cisco DNA Center Migration

Meraki documentation

Cisco dCloud pour expérimenter avec une démo de Cisco DNA Center, utilisant votre accès cisco.com

Cisco DNA Center Communities

– Allo le support?! Webex/MS Teams/Zoom ne marche pas très bien. Que faire ?

Ces derniers mois, je pense que de nombreuses équipes IT ont dû être confrontées à de nouveaux phénomènes et notamment celui de l’expérience des utilisateurs en situation de mobilité. Les exemples ci-dessus de collaborateurs appelant le support, les équipes techniques ou métiers, sont des échantillons de ce qui peut se dérouler à de plus grandes échelles.

Il est de plus en plus courant d’avoir des utilisateurs qui accèdent aux applications internes/SaaS depuis leur domicile, voire sur leurs smartphones & tablettes, sans forcément avoir la nécessité d’utiliser un VPN. L’incidence de tout cela est que les vecteurs d’analyses en cas de problèmes, qui amèneront sans doute à une mauvaise expérience de l’utilisateur, s’en retrouvent décuplés :

• Où est située l’application en question ? Dans mon DC on-premise, ou bien dans le cloud ?
• Est-ce qu’un VPN doit être utilisé pour accéder à cette application ?
• Mon utilisateur y accède t-il depuis son ordinateur de fonction ? depuis un téléphone ?
• Est-ce que l’utilisateur est en télétravail chez lui ? au bureau ? dans des espaces de co-working ?

À ces questions préliminaires, il y a aussi de nouveaux acteurs qui entrent en jeu :

• Dans le cadre des applications hébergées chez un tiers : Est-ce que ce tiers subit actuellement une panne ? (cela peut même arriver aux Clouds Providers les plus connus)
• Quand mon utilisateur travaille depuis son domicile : Dispose-t-il des bonnes conditions de travail chez lui via son accès internet ? Qu’en est-il de l’opérateur auquel il est connecté ?

Existe-t-il un outil capable d’apporter une réponse à ce type d’interrogation ? Ou a minima guider les équipes techniques dans la recherche de réponses à ces hypothèses ?

Notre réponse chez Cisco s’appelle ThousandEyes. ThousandEyes est une plateforme SaaS offrant une variété de techniques de monitoring actif et passif, donnant aux clients une vision approfondie de l’expérience des utilisateurs à travers les applications et les services fournis sur Internet, grâce à trois types d’agents :

• Les Cloud Agents: Maintenus et déployés dans presque 200 villes dans le monde par ThousandEyes, ils permettent de s’assurer de la disponibilité d’un service (site internet, application SaaS, etc) n’importe où dans le monde.
• Les Enterprise Agents: Certains services et réseaux ne sont pas accessibles depuis le monde extérieur. L’Enterprise Agent permet à une entreprise d’avoir une visibilité depuis ces réseaux privés, connexions WANs, sites distants. Elle peut être proposée sur différents supports comme : Intel NUCs, Raspberry Pis, machine virtuelle, containers, et même des équipements réseaux comme nos switchs Catalyst 9000 (article écrit par Florian Girard).
• Les Endpoint Agents: C’est un agent qui prend la forme d’une application légère à installer sur des postes Windows ou MacOS, et qui va collecter diverses métriques et tests depuis l’environnement d’un collaborateur. C’est le sujet de notre série qui sera découpée en trois articles.

Pour ce premier article, je vous propose de parler de l’histoire d’un de mes collègues, José. Que s’est-il passé ?

José’s Outage Analysis : October 2022 (  )

L’histoire commence fin octobre 2022.

Dans notre équipe, et chez Cisco en général, le télétravail a une grande place dans notre quotidien. Sans doute encore plus depuis le COVID. Il n’est pas rare que l’on s’écrive dans notre groupe de tchat interne lorsque l’un d’entre nous a un souci d’accès à une application. Après tout, nous vivons tous à différents endroits en France, utilisons des systèmes différents (Windows ou Mac), etc. L’origine d’un problème se cache donc parfois dans de subtils détails.

Revenons à José.

Le 27 Octobre 2022 à 11:35. Il poste dans notre groupe, la télémétrie en temps réel de son expérience Webex, lors d’une réunion de visioconférence :

Cette gigue (énorme !) qui culmine a près de 7 secondes correspond à des interruptions de la conversation que vit José pendant sa réunion. Il ne ressent pas de problème lors de la navigation sur internet sur divers sites au fil de la journée, mais lorsqu’il lance une réunion… Bingo ! D’ailleurs, ayant d’autres réunions sur Microsoft Teams, le même scénario se reproduit.

On lui préconise d’installer l’agent Endpoint de ThousandEyes sur son poste.

L’agent prendra donc des métriques qui seront envoyées et disponibles aux administrateurs/ingénieurs de l’entreprise depuis le dashboard SaaS de ThousandEyes.

Quelques configurations plus tard depuis le dashboard (un test simple et régulier vers https://cisco.webex.com), les premiers éléments de l’enquête tombent , et ils permettent déjà d’avoir des pistes pour continuer l’analyse !

Plusieurs choses ressortent en quelques secondes :

• On peut identifier trois grandes aires de responsabilités :
  • Le domicile de José
  • Les différents opérateurs qui sont traversés pour accéder au service Webex
  • L’entrée dans l’infrastructure Webex
• Ce que l’agent voit sur le poste de José : 10% de packet loss ! Pourquoi ?

L’agent ThousandEyes Endpoint a la possibilité de fournir des métriques sur l’environnement réseau du collaborateur et ce, dès que l’agent est actif. Ainsi, on peut donc savoir quel est le pourcentage de mémoire consommé, quelle est la charge CPU, quelle est la qualité de mon signal Wi-Fi et le débit, etc. Le screenshot ci-dessous, qui est un exemple concret depuis mon poste parle de lui-même. Il permet des remontées vers le dashboard tout au long de la journée sauf au moment où l’ordinateur est en veille :

Cette vue pour votre entreprise de 100, 1000 voire 10000+ employées peut grandement aider vos équipes de support pour de l’assistance au quotidien car l’objectif de ThousandEyes est de vous aider à réduire le MTTD (mean time to detect) ainsi que le MTTR (mean time to repair).

Dans le screenshot partagé ci-dessous, on constate que le signal Wi-Fi qui est perçu par l’agent installé sur le poste de José n’est que de 46% (ainsi qu’une vitesse à 13 Mbps), ce qui est très faible pour un environnement Wi-Fi. Cette valeur est en fait issue de la puissance du signal RSSI (Received Signal Strenght Indicator), où -100 dBm correspond à une valeur de 0%. Une valeur de 100% correspond à un signal reçu d’environ -50 dBm.

Pour une navigation sur des pages web, cela peut passer inaperçu. Mais pour une bonne qualité audio/vidéo, surtout dans notre contexte actuel où nous devons réaliser beaucoup de visioconférences, cela ne pardonne pas.

Le fin mot de l’histoire ?

Fin octobre 2022, José venait de déménager dans un logement livré neuf avec toutes les nouvelles normes qui en découlent. Parmi ces nouvelles normes, les arrivées des fibres pour les opérateurs se retrouvent directement nichées dans les coffrets où il y a les arrivées électriques. L’installation de la box internet (point de terminaison de la ligne optique et modem) se fait donc à cet endroit.

Le signal Wi-Fi à 46% correspond à une réunion Webex/MS Teams réalisée par José depuis son salon, se trouvant à quelques mètres de ce coffret qui est naturellement fermé, et séparé sans doute par deux gros murs porteurs !

En continuant l’observation des métriques, cette fois-ci en étant à proximité immédiate du coffret technique ouvert, le signal Wi-Fi est de 100%, avec une vitesse à 780 Mbps.

Il est d’ailleurs important de noter qu’entre l’installation de la box opérateur et l’installation de l’agent ThousandEyes, il ne s’est écoulé qu’un jour. En moins d’une demi-heure, l’agent nous a permis de mettre des valeurs concrètes et chiffrées en face des hypothèses que José avait déjà identifié en amont. Il a depuis trouvé d’autres alternatives pour que le signal soit meilleur dans les différentes pièces de son logement.

Tout le monde n’a pas un vernis technique et il peut parfois être difficile de remettre en cause son environnement de travail. C’est pour cela que nous avons trouvé intéressant de relater cette expérience avec mon collègue.

Pour conclure, imaginez que cette histoire puisse arriver à un de vos collaborateurs en situation de mobilité et que :

• Toutes ses réunions en visioconférence sont de qualité médiocre, ou que l’accès à un site ne fonctionne pas
• Que vous ne sachiez pas non plus que cet employé dispose de nouvelles contraintes (par exemple un déménagement ? etc)

Que feriez-vous ? Better use (call) ThousandEyes.

Mes contacts : #twitter / #linkedin