Avant de commencer, je rappelle que vous pouvez vous inscrire pour mon webinar SD-Access du 10 décembre prochain. N’hésitez pas à en parler autour de vous! Je ferai gagner une fabric extension par tirage au sort parmi les présents assidus!
Assez rapidement quand on commence à aborder SD-Access se pose la question du multi-site. Comment cette solution va pouvoir scaler à travers l’ensemble des sites du réseau d’entreprise? “SD-Access for Distributed Campus” est le nom officiel de la solution qui permet de gérer plusieurs sites différents et d’assurer leur interconnexion dans un environnement SD-Access. “Multi-sites” était probablement trop simple 🙂
Dans cette architecture, chaque site est une fabric autonome, appelée “fabric site”. Elle dispose donc de ses propres Border Nodes, Control Plane Nodes et contrôleurs Wi-Fi. Cette autonomie de chaque fabric permet d’avoir une résilience maximale puisqu’un site ne dépend d’aucun autre pour fonctionner correctement. Notez bien que c’est vous qui définirez ce qui est pour vous un site: ça peut être un bâtiment, un campus entier, juste un étage… Vous choisissez selon ce qui a le plus de sens pour vous!
SD-Access for Distributed Campus permet d’interconnecter les “fabric sites” entre eux via une Transit Fabric. Deux types de Transit Fabric permettent aujourd’hui d’assurer cette interconnexion selon les cas de figure : les fabric “IP Transit” et “SD-Access Transit”. Je détaille les différences dans la suite de mon article.
Cette approche de fabric multiple est préférée par rapport à la création d’une fabric unique s’étalant à travers plusieurs sites pour plusieurs raisons:
- Indépendance des sites les uns par rapport aux autres. Un incident sur un site ne peut pas avoir d’impact sur une autre fabric (control plane et data plane distincts)
- La création d’une fabric unique a des impacts conséquents en termes de scalabilité puisque les Border Nodes et Control Plane nodes d’une telle fabric devraient être capables de gérer tous les hosts en mémoire. Dans une approche distribuée, seuls les hosts locaux sont gérés. Les hosts distants sont vus à travers des préfixes agrégés, ce qui permet de gagner en espace mémoire et créer au final des fabric plus importantes.
- Il est possible de garantir sur chaque site qu’un Border Node local est choisi, évitant ainsi des effets de “trombonning”. Cela permet par exemple d’accéder à un datacenter ou une sortie Internet locale sans transiter par un Border Node d’un site distant.
- Cette approche offre un point de passage sur le Border Node qui après décapsulation, “voit” ainsi le paquet natif. Il est ainsi possible d’avoir un traitement approprié sur le paquet natif, quand une encapsulation de bout-en-bout ne le permettrait pas. Il devient ainsi possible de déployer des services indispensables au WAN comme la QoS, le Deep Packet Inspection, le routage intelligent, l’optimisation applicative…
Dans la suite de cet article je détaille les deux types de fabric et leur application.
Fabric IP transit
Dans ce type de transit, le Border Node transmet un paquet IP natif vers l’extérieur de la fabric. Chaque Virtual Network (VRF) est interconnectée vers l’extérieur du réseau sur un VLAN dédié, et le routage est effectué avec le protocole de votre choix (je recommande fortement EBGP). Il appartient donc à l’administrateur de garantir la macro-segmentation entre les sites en déployant la technologie adéquate (MPLS-VPN, MPLS over DMVPN, réseau Cisco SD-WAN offrant une segmentation de niveau 3…)
L’avantage de cette solution est que le paquet IP émis par la source est vu par le WAN qui peut ainsi faire le traitement approprié si nécessaire, par exemple :
- Deep Packet Inspection
- QoS sur protocole/port
- Stateful firewalling
- Optimisation applicative
- …
L’autre avantage est lié à la MTU. La paquet transmis au WAN n’étant pas encapsulé, sa taille est inférieure à 1500 octets aussi il peut être transporté par tout type de WAN (qui gèrera au besoin la fragmentation si nécessaire). A nouveau c’est à l’administrateur de choisir le design devra garantir la macro- et la micro-segmentation entre les différents sites.
Pour assurer la macro-segmentation, il est possible de reposer sur :
- Un WAN MPLS-VPN (ou L3VPN)
- Un WAN de type MPLS over DMVPN ou FlexVPN
- Un WAN Cisco SD-WAN qui supporte la segmentation
- Une WAN bâti sur des VRF-Lite
- Des firewalls qui gèrent des contextes
Pour assurer la micro-segmentation, deux approches globales sont possibles afin de propager les informations sur les groupes de sécurité au travers de la transit IP fabric :
- Transporter le SGT (Scalable Group Tag) nativement sur le WAN
- Nativement dans l’en-tête Ethernet
- Dans l’en-tête IPsec si une technologie d’encapsulation IPsec est déployée dans le WAN (DMVPN ou FlexVPN)
- Utiliser le protocole SXP (SGT eXchange Protocol) pour échanger les mappings IP-SGT entre équipements réseau (et/ou ISE). Dans ce cas le SGT n’est pas transporté sur le WAN. Seuls les mappings IP-SGT sont échangés directement via le protocole SXP. A réception d’un paquet depuis le WAN, un Border Node pourra vérifier s’il a le SGT associé à l’adresse IP source dans sa table de mapping. Le cas échéant il repositionnera le SGT associé.
Le schéma ci-après montre un exemple de design IP Transit avec l’utilisation d’un WAN MPLS-VPN.
- Le Border Node décapsule le paquet VXLAN reçu au sein de la fabric.
- Il transmet un paquet IP vers le WAN. L’utilisation d’un VLAN sur l’interconnexion entre le Boder Node et le routeur WAN permet de garantir la macro-segmentation sur ce lien.
- Le routeur WAN (ici un PE MPLS) utilise la technologie MPLS pour étendre la segmentation sur tout le WAN.
- Le PE de destination envoie le paquet au Border Node via un VLAN.
- Le Border Node ré-encapsule le paquet en VXLAN vers le Edge Node du site de destination.
On notera qu’un peering SXP est établi entre les Border Nodes pour échanger les mappings IP-SGT et permettre ainsi une micro-segmentation de bout-en-bout et un filtrage selon les groupes. Une autre option pourrait être d’établir directement des peerings SXP entre les Border Nodes et ISE qui connaît toutes les correspondances entre IP et SGT.
Les fabrics IP transit seront donc principalement utilisées quand les sites sont interconnectés au travers de WAN qui ne permettent pas d’offrir une MTU de 1600B et qui nécessitent de traiter le paquet natif (pour optimisation WAN, QoS, routage intelligent, …)
Pour créer ce type de fabric IP Trabnsit, vous devrez simplement spécifier le numéro d’AS BGP de votre réseau de coeur. Ce numéro sera utilisé pour créer automatiquement les peerings EBGP depuis vos Border Nodes.
SD-Access Transit
Avec SD-Access Transit la connexion de tous les fabric sites est complètement automatisée et simplifiée. La fabric SD-Access Transit interconnecte tous les Border Nodes des différents fabric sites à travers une nouvelle fabric de coeur, reposant elle aussi sur le protocole VXLAN.
L’avantage de cette solution SD-Access Transit est qu’il n’y a absolument rien à configurer sur le WAN. Celui-ci devient simplement l’underlay IP qui permet de transporter les paquets d’un Border Node d’un fabric site à un autre, à travers une encapsulation VXLAN. La Fabric SD-Access Transit conservera nativement la macro- et la micro-segmentation entre les fabric sites, les attributs VNID et SGT étant transportés dans l’en-tête VXLAN. Quelques clics suffisent pour connecter les sites entre eux en conservant toutes les propriétés de SD-Access (Automatisation, Assurance, Segmentation)
Ici il faut spécifier deux Control Plane Nodes qui assureront toute la logique de routage entre les fabric sites. Il est important de s’assurer que l’underlay offre une MTU suffisante (1600B minimum) pour l’encapsulation VXLAN.
Le schéma ci-dessous montre le principe d’une fabric SD-Access Transit. La communication entre les Border Nodes des fabric sites 1 et 2 est assurée par la fabric de Transit SD-Access qui permet de conserver la macro- et micro- segmentation.
Pour rattacher un site à une fabric de transit, rien de plus simple. Il suffit de rajouter la fabric de transit préalablement créée dans la configuration des Border Nodes.
Les fabrics SD-Access transit seront donc principalement utilisées sur des MAN quand le débit, la latence et la MTU sont suffisants, sans de besoin de DPI, de chiffrement, de routage intelligent, d’optimisation applicative…
Voici un exemple dans mon lab de deux fabric-sites virtuellement situés à Issy-les-Moulineaux et Boulogne, et interconnectés à travers une fabric de type SD-Access transit.
Pour résumer, la règle suivante vous aidera à prendre la bonne décision la plupart du temps:
- IP Transit au dessus du WAN
- SD-Access transit au dessus du MAN
Commencez à déployer votre premier site, vous allez vite vous rendre compte comment il est facile d’étendre votre stratégie SD-Access de bout en bout!
Pour en savoir plus…
Authors
