Je me dis qu’un titre comme cela ne va peut-être pas attirer les foules… Mais après tout il convient avant tout sur ce blog d’être didactique, et pour cela il faut être un peu précis et ne pas avoir peur d’utiliser un certain jargon technique. Vous qui êtes fidèles à ce blog vous aurez compris les nombreux avantages de la solution SD-Access: automatisation complète du réseau, garantie de l’expérience utilisateur, segmentation et sécurité améliorée… mais aussi, comme je le rappelle dans cet article, la mise en oeuvre d’un design propre qui dit enfin adieu au niveau 2 et ses travers qui continuent encore en 2019 de créer des incidents réseau considérables.
Dans un design SD-Access, on va vite oublier ce qu’il se passe au sein de la fabric. On comprend rapidement que tout est automatisé par Cisco DNA Center et qu’il n’est pas vraiment nécessaire de passer du temps à ce niveau-là. Le plan de contrôle LISP distribué au sein de la fabric va permettre la communication entre les utilisateurs, et finalement si les experts vont vouloir maîtriser sur le bout des doigts tous les mécanismes de la communication et le traditionnel “packet-walk”, le commun des mortels va vite se focaliser sur les usages et tirer bénéfice de cette architecture automatisée.
Le point qui concentre toutes les attentions dans un design SD-Access est l’attachement de notre fabric au monde extérieur:
- Comment ce réseau automatisé va pouvoir communiquer avec le reste de votre infrastructure ?
- Comment interconnecter plusieurs sites SD-Access à travers un MAN, un WAN… et pourquoi pas du SD-WAN ?
- Comment appliquer des configurations de sécurité globalement en tirant profit des groupes de sécurité inhérents à SD-Access?
- Comment effectuer les migrations réseau ? (pour aller vers SD-Access et même se rassurer sur la capacité d’en sortir éventuellement)
Je vais ici m’attarder un peu sur des questions de connexion basiques de notre fabric au reste de votre réseau, et expliquer en quoi cela est essentiel pour vos opérations, et notamment pendant les migrations du réseau.
Dans une fabric, vous allez configurer ce que l’on appelle des “segments”. Un segment n’est rien d’autre qu’un pool d’adresses IP configuré dans la fabric au niveau d’un Virtual Network. Une GUI simple vous permet de gérer vos pools d’adresses IP et de les répartir sur vos différents sites.
Chaque pool créé (ILM-Pool18 dans l’exemple ci-dessous) peut ensuite être assigné à une fabric et un Virtual Network. Je rappelle à ce stade qu’un Virtual Network permet d’implémenter de la macro-segmentation. Deux Virtual Networks ne doivent pas communiquer entre eux au sein de la fabric SD-Access. L’objectif est d’assurer un cloisonnement fort. Au niveau d’un commutateur, un Virtual Network (VN) est d’ailleurs instancié par une VRF: vous comprenez ainsi en quoi le cloisonnement entre 2 VN est structurant et va au-delà de l’application d’ACL.
Une fois nos segments créés, la grande question est de savoir comment on va les interconnecter avec le reste du réseau. Et c’est là qu’intervient la notion de “handoff”. Le handoff permet de connecter votre fabric au rester du monde au niveau des Border Nodes (je rappelle ici que les Border Nodes sont les seuls équipements qui autorisent la communication de la fabric avec l’extérieur).
On va distinguer 2 types d’interconnexion:
- L3 handoff: dans ce cas on va interconnecter en IP notre VN avec le reste de votre réseau. On pourra par exemple établir un peering EBGP entre votre Border Node et une autre routeur de votre réseau, et annoncer ainsi vos subnets.
- L2 handoff: dans ce cas on va se contenter d’abouter votre segment à un VLAN extérieur. Cette interconnexion au niveau 2 de votre segment à un VLAN existant de votre réseau permet d’avoir une communication Ethernet switchée entre les 2.
Dans le cas général, vous utiliserez une interconnexion de niveau 3: votre subnet est présent dans la fabric sur un segment et vous désirez un minimum de cloisonnement L3 avec le monde extérieur. Si votre fabric vous permet de vous affranchir de Spanning-Tree et des boucles, autant éviter de la rattacher à un environnement de niveau 2, cela n’en sera que mieux d’un point de vue stabilité. Lors d’une migration, le terminal connecté à la fabric (en filaire ou Wi-Fi) obtiendra une nouvelle adresse IP en DHCP (ou SLAAC/DHCPv6 pour IPv6) et sera associée à un nouveau subnet IP.
Pour faire une connexion L3 vers l’extérieur, vous pouvez rajouter en CLI les configurations de votre choix sur les Border Nodes (quelques lignes que vous maîtrisez bien), ou bien vous pouvez utiliser la GUI de DNA Center.
La première étape consiste à créer une fabric de transit de type “IP Transit”. Cela veut dire que votre trafic sortira en IP natif (pas d’encapsulation VXLAN ou autre). Dans l’exemple ci-dessous je créé un réseau IP Transit appelé “OUTSIDE” et je lui assigne un numéro d’AS. Les peerings EBGP d’interconnexion seront ainsi automatiquement créés avec le bon remote-as BGP.
Une fois le réseau extérieur déclaré, je n’ai plus qu’à créer mes interconnexions. J’indique simplement que mon Border Node est connecté à cette fabric de transit IP puis je déclare l’interface d’interconnexion et les Virtual Networks connectés.
Un troisième menu me permet ensuite de spécifier les subnets d’interconnexion avec davantage de paramètres d’interconnexion dans la toute dernière version. Je rappelle ici qu’il reste toujours possible de faire cette configuration en CLI sur les Border Nodes pour ceux qui préfèrent continuer à gérer la connexion de leur LAN vers l’extérieur comme avant.
On comprend bien dans ce monde d’interconnexion de niveau 3 (ou L3 Handoff) qu’il y a un routage entre la fabric et l’extérieur. Autrement dit cela nécessite un changement d’adresse IP des terminaux quand on va souhaiter les migrer sur SD-Access. Dans le cas général, cela n’est pas un problème. Le terminal obtient une adresse IP en DHCP (ou SLAAC/DHCPv6) et le changement d’adresses IP est indolore. Il existe cependant des cas dans lesquels les terminaux ont des adresses IP configurées statiquement, mettant à mal ce type de raisonnement. Ces IP fixes sont le plus souvent présentes sur des terminaux atypiques, du domaine qui n’est souvent plus du ressort de l’IT. Dans ce cas, le challenge est de pouvoir migrer tous ces équipements vers une fabric SD-Access sans changer leur adresse IP. Comme on se doute que la migration ne pourra pas toujours se faire en un seul bloc, on se retrouve avec la nécessité d’avoir une partie des équipements dans la fabric SD-Access, et une autre sur le réseau traditionnel non encore migré.
Un bon exemple pour illustrer ce type de cas de figure est la connexion d’appareils d’imagerie médicale dans un hôpital. Ces IRM, scanners, … sont tous connectés au réseau et ont le plus souvent de mon expérience des adresses IP configurées statiquement, et sont quasiment systématiquement sur le même subnet. Dans le cas d’une migration vers SD-Access, on va évidemment vouloir migrer progressivement ces terminaux pour éviter de laisser l’hôpital sans imagerie indispensable pour le soin des patients. Il faut donc être en mesure de migrer ces terminaux un à un du réseau traditionnel vers SD-Access, sans pour autant changer leur adresse IP. En d’autres termes il faut abouter le segment de la fabric en niveau 2 vers le VLAN consacré à l’imagerie médicale sur le réseau traditionnel. C’est exactement l’objectif du L2 handoff.
En mode L2 handoff, on va abouter chaque segment à un VLAN extérieur. La GUI du DNA Center permet de réaliser cette opération simplement. Il suffit tout d’abord de choisir au niveau du Border Node le VN dans lequel se trouve le segment pour lequel on va souhaiter effectuer ce L2 Handoff.
Et au sein de ce VN on va pouvoir spécifier pour chaque segment l’interface et le VLAN extérieur vers lequel on veut faire cet attachement de niveau 2.
Vous constaterez combien il est simple de réaliser cette interconnexion de niveau 2, offrant ainsi de nouvelles perspectives pour vos migrations vers SD-Access. Aussi j’entends parfois certains clients exprimer leur crainte de se retrouver pieds et mains liés une fois SD-Access déployé. Vous constaterez que par extension ce mécanisme L2 Handoff peut aussi vous permettre de migrer depuis SD-Access vers toute autre technologie si vous désiriez par malheur changer de solution dans le futur.
Au cas où ça resterait encore un peu obscure pour vous, voici un schéma réseau qui vous permet de visualiser comment un segment est simplement interconnecté à un VLAN en niveau 2, offrant ainsi la capacité d’avoir le même subnet dans et en dehors de la fabric.
Notez que la connexion L2 ne peut se faire que sur un seul Border Node (BN) pour éviter les boucles. Ce BN peut être un stack, un châssis redondé ou très prochainement un Stackwise Virtual (évolution du VSS sur Catalyst 9000). Toutes ces options vous permettent de garantir une interconnexion redondante même si logiquement un seul BN doit être choisi comme indiqué plus haut. Notez aussi que les BN assurant le L3 handoff et le L2 handoff peuvent être différents. Dans tous les cas, on évitera de garder cette connexion de niveau 2 plus longtemps que nécessaire et on la supprimera une fois la migration terminée. Il n’est pas raisonnable, dans une architecture qui se veut mettre fin aux maux liés aux boucles L2, de continuer à prolonger indéfiniment des VLANs.
J’espère vous avoir convaincu que la migration des SD-Access était aisée grâce aux mécanismes de handoff L2 et L3. J’espère vous voir nombreux au webinar de demain mardi 19 novembre sur les nouveautés de DNA Center 1.3. Je ferai courant décembre un webinar sur les nouveautés SD-Access 1.3. En attendant l’annonce ce mercredi vous pouvez déjà vous inscrire!
Authors
