Dans l’article précédent, nous avons vu les principes d’une infrastructure réseau de type « Software-Defined Networking ». Cette approche SDN apporte à l’infrastructure l’agilité nécessaire afin d’assurer la réactivité qu’attend toute entreprise de son Système d’Information. Cette réactivité du SI permettra de fluidifier les demandes Métier mais également de répondre à une demande urgente, telle que celle imposée par les situations sanitaires liées à la Covid par exemple.
Cette situation sanitaire toute particulière a imposé à une grande majorité d’entreprises la mise en place du télétravail à marche forcée. Ce contexte spécifique nous servira de fil rouge afin de comprendre tous les bénéfices que l’entreprise peut retirer du SDN. A ce titre, nous présenterons un autre cas d’usage, en pleine explosion à l’heure actuelle directement lié à la situation sanitaire.
Le SDN augmenté, le réseau basé sur l’intention
Mais la seule technologie SDN ne suffira pas à répondre aux attentes de l’entreprise pour les raisons exposées ci-après.
Prenons un exemple. Nous disposons d’un réseau SDN pour le WAN, un autre pour le LAN du campus et un 3ème pour le réseau du datacenter. Nous parlons ici de datacenter au sens d’entité qui héberge nos applications. Une application peut se trouver à un moment donné dans l’infrastructure on-premises et à un autre moment dans un cloud public.
Dans le même temps, le collaborateur peut se trouver sur le campus de l’entreprise, ou en télétravail chez lui, sur un site distant ou même chez son client avec le respect des règles sanitaires.
L’étude ci-dessous a été réalisée avant le début de la pandémie. Gageons que les chiffres présentés soient en forte augmentation à l’heure actuelle :
L’impact pour l’infrastructure réseau est significatif. Nous pouvons le résumer de la façon suivante :
- Les collaborateurs peuvent se trouver n’importe où (je suis incapable de dire où ils sont)
- Même chose pour les applications auxquelles ils accèdent (je suis incapable de dire où elles s’exécutent)
- Les deux vont communiquer directement. Plus aucun flux ne passera par les environnements Campus / Data Center (je suis incapable de dire qui fait quoi et par où).
Pour l’entreprise, il est primordial que les bénéfices qu’elle retire de la mise en place d’une infrastructure SDN soient identiques quelle que soit la localisation du collaborateur.
C’est là que le réseau basé sur l’intention prend tout son sens.
Dans cette approche, le couple historique @IP / VLAN n’a plus aucune signification. Le collaborateur est identifié par son Identité, indépendamment également du terminal qu’il utilise ( smartphone, ordinateurs portables ou autres tablettes).
Des règles (policies) devront être décrites pour définir ce collaborateur et l’ensemble des droits qui lui sont attachés. Il sera ainsi identifié de manière unique tout au long de ses actions au sein des divers réseaux de l’entreprise.
Ces règles doivent être propagées afin de « suivre » le collaborateur. Le bénéfice du réseau basé sur l’intention est une abstraction totale entre une règle, quelle qu’elle soit, mais qui est attachée au collaborateur, et l’infrastructure de transport !
Le collaborateur se déplace, son application aussi. Les règles sont attachées au collaborateur et ses droits seront respectés. Il bénéficiera constamment de la même « Utilisateur Application Expérience ».
Le réseau basé sur l’Intention comprend donc deux principes fondamentaux :
- L’abstraction entre l’identité du collaborateur et le réseau de transport
- La capacité à propager les règles qui définissent l’Identité du collaborateur au sein des différents réseaux SDN.
De l’intérêt du transport de la micro-segmentation
Il y a de nombreuses années, le besoin s’est rapidement fait sentir de disposer d’une hiérarchie dans l’isolation réseau. Le cas d‘usage le plus simple était celui d’un hébergeur qui devait assurer une isolation entre chacun de ses clients et fournir ensuite une isolation plus fine entre diverses entités à l’intérieur d’un client donné.
Nous faisons référence à la macro-segmentation (entre clients) et la micro-segmentation (propre à chaque client).
La technologie historiquement la plus répandue est la VRF par client, puis les VLAN dans chaque VRF.
Cette approche se retrouve aujourd’hui dans les réseaux SDN. L’équivalent de la VRF est le VN (Virtual Network) dans les réseaux LAN, ou le VPN dans le SD-WAN.
Premier élément facilitant la propagation des règles à travers les différents réseaux : corréler la macro-segmentation entre ces différents réseaux. Pour cela, il est nécessaire d’abouter un VN du LAN avec un VPN du WAN afin de garantir la continuité du réseau. Il est important de noter que cette capacité d’isolation macro est primordiale dans le choix des composants d’infrastructure. Car tout comme la fonction VRF impose au commutateur la capacité à supporter de multiples environnements de routage, le Virtual Network impose la même chose sur les commutateurs SDN du LAN.
Précisons un point : le WAN est là pour « transporter ». Le collaborateur et son application seront normalement sur un LAN Campus et un LAN datacenter. Cependant, en général, aucun des éléments du couple collaborateur / application ne sera connecté directement sur le WAN.
Nous allons donc décrire comment la micro-segmentation utilisée pour identifier une application dans le réseau datacenter (DC) est corrélée avec la micro-segmentation utilisée pour identifier un collaborateur dans le réseau LAN campus. Nous verrons également comment cette micro-segmentation provenant du LAN ou du DC est prise en compte par le WAN afin de garantir les SLAs propres à chaque couple collaborateur / application.
Le schéma ci-dessous présente l’évidence de la nécessité de transporter les règles au sein des différents réseau
La micro-segmentation va permettre de descendre au niveau unitaire, d’isoler un collaborateur donné , de lui affecter ses droits ou d’isoler une application donnée au sein du portefeuille applicatif de l’entreprise.
Cette micro-segmentation est définie par deux paramètres distincts en fonction du type de Réseau SDN :
- L’EPG (End-Point Group) sur le réseau du datacenter : il définit une application donnée ou un groupe d’application de même nature, ferme de serveurs Web par exemple,
- Le SGT (Security Group Tag) sur le réseau LAN du Campus : il définit un collaborateur donné ou un groupe de collaborateurs de même nature. Du fait de l’utilisation grandissante du mécanisme SGT pour la micro-segmentation, « Scalable Group Tag » pour l’acronyme SGT est plus fréquent.
Le schéma ci-dessous présente ce qui a été expliqué précédemment :
Chaque réseau SDN dispose de son propre orchestrateur / contrôleur : réseau
- du DC : l’APIC
- WAN : le vManage
- LAN : le DNA-Center.
Un nouveau composant apparait : l’ISE pour Identity Service Engine. L’ISE est le serveur RADIUS historique de Cisco. C’est aussi un remarquable « repository » de règles.
L’ISE assurera le lien entre les orchestrateurs des différents réseaux de transport.
L’APIC pour le DC et le DNA-Center pour le LAN alimenteront l’ISE avec les identifiants de collaborateurs (les SGT) et d’applications (les EPG). Ils récupéreront les associations SGT<=>EPG pour transporter la micro-segmentation entre les deux réseaux LAN et DC.
Une translation entre l’identité du collaborateur (son SGT) et l’identité de l’application (son EPG) sera mise en oeuvre.
Si l’on doit connecter des collaborateurs sur des sites distants, le réseau SD-WAN de transit transportera nativement l’identité (le SGT) de ce groupe d’utilisateur.
Le cas de l’intégration réseau WAN et réseau DC
Le Système d’Information de l’entreprise dispose de plusieurs datacenters distants interconnectés par le réseau WAN.
Dans ce cas, le réseau DC met en œuvre le MSO pour Multi-Sites Orchestrateur. MSO fédérera les contrôleurs APIC de chaque DC afin de présenter un Réseau DC unique couvrant tous les sites.
L’orchestrateur SD-WAN vManage connait les différents chemins entre deux DC en termes de latence, taux de perte, jitter…vManage liste ainsi les SLA pour l’ensemble des chemins.
MSO récupérera ces SLA auprès de vManage et les assignera à une application donnée. Lorsque cette application communiquera entre deux DC à travers le WAN, vManage identifiera le SLA assigné à cette application. Elle sélectionnera le chemin le plus approprié. En cas de dégradation des conditions réseaux sur le chemin initial, vManage basculera automatiquement le flux applicatif sur un autre chemin/ le but sera de toujours respecter le SLA assigné à l’application.
Il s’agit ici de l’« application-aware routing », le routage en fonction de l’application. Nous sommes définitivement très loin du vieux couple @IP / VLAN !
En résumé, le couple collaborateur / application va bénéficier ainsi des apports du réseau basé sur l’Intention, à savoir une identification et un traitement spécifique et cela, indépendamment de sa localisation géographique et du réseau de transport emprunté, LAN, WAN ou DC.
Dans le prochain article, nous allons voir comment étendre abstraction et transparence jusqu’au sein des Clouds Publics, pour des besoins aussi bien IaaS que SaaS.
