MVPN extranet
Après quelques rencontres de clients ces dernières semaines j’ai été surpris de voir cette problématique resurgir à plusieurs reprises. Il faut reconnaître que c’est plus amusant que de faire du spanning-tree alors prenons un peu le temps d’y voir plus clair!
Problématique
La problématique est la suivante: les clients segmentent leurs réseaux en répartissant les usagers dans des L3VPN MPLS (et ainsi garantir une étanchéité des flux dans le coeur) et ils ont des applications multicast qui doivent facilement passer d’un VPN à une autre. On imagine un VPN regroupant de nombreuses caméras de vidéosurveillance dont les flux doivent pouvoir être consultés sur des centres de supervision, mais éventuellement aussi sur tout poste de travail qui peut donc se trouver dans un autre VPN.
Fusion pour l’unicast
En unicast, l’approche généralement adoptée est de mettre en place une “fusion”, c’est à dire un routeur à l’extérieur du coeur MPLS et qui va se connecter aux différents L3VPN via autant d’interfaces/sous-interfaces que nécessaire (une sous-interface par VPN minimum). Ce routeur de fusion va récupérer dans sa table unicast globale les routes des différents VPN (non segmentées) et va donc permettre le routage inter-VPN. Pour passer d’une VRF à une autre, le trafic passera par ce routeur de fusion. En réalité on trouvera plusieurs fusions pour la redondance et bien évidemment une couche de firewalls (ce serait bien dommage de faire des VPN si on ne se souciait guère de sécuriser les flux qui passent d’un VPN à l’autre!)
MVPN extranet
Alors quid du multicast? Oui la solution décrite plus haut fonctionne: on peut imaginer faire transiter tous les flux multicast par notre fusion. Cela pose plusieurs problèmes. Tout d’abord cela encombre le réseau avec des flux multicast (souvent gourmands) qui font des allers-retours à travers la fusion; mais aussi on charge inutilement les firewalls avec un trafic dont ils ne font pas grand chose. L’autre problème est que dans certains designs on demande aux firewalls non pas d’être simplement en coupure mais de gérer le routage. Si pour l’unicast on a quelques solutions il est plus difficile d’avoir PIM-SM supporté. On appelle MVPN extranet les solutions qui nous permet de faire passer du trafic multicast entre VRF sans utiliser la fusion.
Solution 1 – Jouer sur les imports de routes
La solution est simple: il suffit de configurer sur le PE MPLS les 2 VRF (de la source et de la destination du flux multicast) et de s’arranger pour que les routes BGP passent de l’une à l’autre en jouant sur les RT (route-target). Voici un petit exemple simple (j’ai supprimé la définition des neighbors BGP pour simplifier)
vrf definition IPVS rd 65222:2222 route-target export 65222:2222 route-target import 65222:2222 ! address-family ipv4 mdt default 239.2.2.2 exit-address-family ! vrf definition TRAVAIL rd 65111:1111 route-target export 65111:1111 route-target import 65111:1111 route-target import 65222:2222 ! address-family ipv4 mdt default 239.1.1.1 exit-address-family
Ici la VRF TRAVAIL importera automatiquement les routes de la VRF IPVS (IP Videosurveillance) et le trafic multicast pourra s’écouler simplement de la VRF IPVS vers TRAVAIL (et non l’inverse). On pourra faire cette opération soit sur le PE en entrée du réseau (SSC – Source Side Chaining) ou sur le PE de sortie (RSC – Receiver Side Chaining). Si l’on fait la duplication sur le PE en entrée, un trafic multicast à destination de 2 VPN sur un même PE de sortie apparaîtra 2 fois sur le coeur (une fois sur chaque MDT) ce qui peut être vu comme sous-optimal.
Notons tout de même que cette solution n’est pas exclusivement réservée au multicast: le trafic unicast lui aussi suivra le même comportement. Cette manipulation est donc réservée aux VPN qui offrent des services “partagés”, et qui ne nécessitent pas de filtrages particuliers.
Ci-dessous 2 petits schémas pour illustrer les méthodes SSC et RSC:
Cette solution ne permet cependant pas l’échange entre la table multicast globale et un MVPN (pas possible d’importer/exporter les routes de la globale dans les VRF…) On a d’autres solutions pou cela: lisez la suite si vous en avez encore la force…
Solution 2 – Ajouter une mroute statique de fallback
Cette solution est simple: il s’agit de rajouter une mroute qui indique que la source se trouve dans la VRF voisine (ou alors dans la globale).
ip mroute vrf vrf-name source-address mask fallback-lookup {global | vrf vrf-name} [distance]
Il reste nécessaire d’avoir les 2 VRF configurées sur le PE, sauf si bien sûr on échange avec la table globale. Si je reprends ma configuration précédente:
ip mroute vrf TRAVAIL 10.20.20.0 255.255.255.0 fallback-lookup vrf IPVS
Et si mes sources multicast avaient été dans la globale et non dans le VPN IPVS, on aurait configuré:
ip mroute vrf TRAVAIL 10.20.20.0 255.255.255.0 fallback-lookup global
Ca reste du routage statique… Pour garder un comportement dynamique on peut utiliser la solution ci-dessous…
Solution 3 – Choix de la VRF en fonction du groupe
Cette troisième option permet d’utiliser l’adresse multicast comme élément unique qui permettra de savoir dans quelle VRF chercher la source, ou bien si l’on doit la chercher dans la globale. Cela suppose bien sûr que l’on évite les overlaps d’adresses multicast entre les VPN… Un petit exemple vous permettra vite de comprendre: on configure notre réseau pour indiquer que les groupes en 239.1.0.0/16 ont leurs sources dans la globale alors que les groupes en 239.2.0.0/16 ont leurs sources dans le VPN IPVS.
ip multicast vrf TRAVAIL rpf select global group-list 10 ip multicast vrf TRAVAIL rpf select vrf IPVS group-list 20 access-list 10 permit 239.1.0.0 0.0.255.255 access-list 20 permit 239.2.0.0 0.0.255.255
Ici aussi on n’est pas dispensés de configurer les 2 VRF sur le PE!
Quelle plateforme supporte quoi?
J’ai fait mes tests sur ASR1000 en 3.4S. Bien évidemment le support est beaucoup plus large et de nouveaux développements se font tous les jours aussi je vous encourage a chercher dans la documentation en ligne et le feature navigator quelles sont les fonctionnalités supportées sur les routeurs qui sont les vôtres. Je reviendrai dans les semaines à venir sur les MVPN, car il y a pas mal de choses à raconter (méthode d’encapsulation, signalisation, découvert…) et les choses bougent!
Tags:
2 commentaires