MPLS VPN Partie 1
Le MPLS VPN est sans doute l'un des termes le plus recherché, le plus abordé et donc le plus mal mené.
- « le protocole MPLS permet à l’opérateur de chiffrer les flux »
- « Carrier Ethernet est la solution concurrente la plus courante face à MPLS »
- « les solutions SD-WAN pour réduire ou éliminer la dépendance aux lignes MPLS, lentes et onéreuses »
J'ai mal à mon MPLS. Le but de cet article est de préciser ce qu'est entendu par ce terme et montrer étape par étape son implémentation classique sur un réseau opérateur miniature.
Kècécè ?
Précisons que par MPLS VPN est couramment entendu L3VPN IP sur MPLS. Plus simplement, nous parlons de MPLS L3VPN et c'est le sujet même de cet article. Il s'agit de transporter des paquets IP de façon cloisonnée sur un réseau MPLS mutualisé. Le MPLS L2VPN existe également mais pour (à l'évidence) transporter des trames Ethernet. Par conséquent, le seul terme de MPLS VPN ne suffit pas : il faut préciser L2 ou L3. Théoriquement, il faudrait aussi préciser la nature du protocole transporté (IP, Ethernet, Frame Relay, etc.)—oui, le L2VPN Frame Relay sur MPLS existe bien, même si jamais vu en vrai (trop jeune…). L'article L2VPN vs L3VPN avait déjà abordé la question de la terminologie.
Dans la pratique, personne ne vous en voudra de parler uniquement de MPLS L3VPN (implicitement IP) ou MPLS L2VPN (implicitement Ethernet). C'est un raccourci acceptable. Cependant, beaucoup de raccourcis sont faits dans le monde réseau et force est de constater que c'est souvent source d'ambiguïté. Ainsi, un responsable peut allouer une ressource humaine à un problème qui n'en est pas un, ce dernier ayant été mal formulé dès le départ.
Enfin, avant d'entrer dans le vif du sujet, voici le nom d'un produit que j'ai croisé sur le bon de commande d'un commercial : « VPN MPLS IP de niveau 2 ». L'intention était bonne : en inscrivant tous les termes possibles, cela ne pouvait qu'être correct. C'est dommage toutefois, il manquait le terme principal : Ethernet. Je me demande encore ce que le client a pensé de ceci. Bref.
Plan de l'article
Sur tout réseau opérateur, la mise en place d'un MPLS L3VPN suit généralement les étapes suivantes :
- Partie 1—cette page
- Étape 1 : un backbone IP
- Étape 2 : un backbone IP/MPLS
- Étape 3 : configuration d'un MPLS L3VPN
- Partie 2—page suivante
- Étape 4 : un peering BGP VPN-IPv4 (plan de contrôle)
- Étape 5 : visualiser le label stacking (plan de données)
- Étape 6 : le routage CE-PE
L'article a été découpé en deux parties pour aborder progressivement les concepts et éviter d'avoir une seule et même page trop chargée. La deuxième partie sera la plus dense. Mais avant d'entrer dans ces étapes, faisons un court aparté sur l'origine des MPLS L3VPN ainsi que sur la maquette utilisée.
Origine
Le MPLS L3VPN a été initialement spécifié dans la RFC 2547 sous le nom de « BGP/MPLS VPNs », le protocole BGP constituant le plan de contrôle. Ce travail a eu lieu quasiment en parallèle de la spécification de l'architecture MPLS, spécifiée dans la RFC 3031, comme nous pouvons le voir via les trackers respectifs :
Ce n'est donc pas un hasard si le MPLS L3VPN fonctionne bien puisque cela a aussi été fait « pour que ça marche » (ce sera néanmoins quelques cinq années plus tard pour le MPLS L2VPN). La RFC 4364 est la version actuellement en vigueur et a renommé, avec raison, la technologie en « BGP/MPLS IP VPNs ».
La maquette utilisée
Notre maquette se veut être un réseau opérateur miniature aligné sur l'architecture de référence MPLS L3VPN :
Each VPN site must contain one or more Customer Edge (CE) devices.
Each CE device is attached, via some sort of attachment circuit, to
one or more Provider Edge (PE) routers.
Routers in the SP's network that do not attach to CE devices are
known as "P routers".
Soit en image :
En tant qu'opérateur français,
nous imaginons que le RIPE—qui
n'est autre que le RIR (Regional Internet Registry) européen en charge de l'attribution des numéros d'AS et des adresses IP—nous
attribue l'AS100 et le réseau public 1.0.0.0/24 (qui sont en réalité déjà pris).
Quelle différence entre PE et P ? Les routeurs PE et P sont tous deux appelés LSR dans la terminologie MPLS. Mais le rôle des PE est bien plus complexe que celui des P. Ils doivent implémenter les mécanismes MPLS L3VPN tels que : appartenance du client à son VPN ou attachment circuit, segmentation des VPN, plan de contrôle des VPN via MP-BGP, etc. Les P, eux, se limitent au label switching classique du MPLS. Pour cette raison, les PE sont souvent plus onéreux que les P et les prix peuvent atteindre plusieurs dizaines de milliers d'euros selon la marque, les performances et les fonctionnalités. Enfin, les P sont souvent appelés core routers, ces derniers constituant le réseau de cœur de l'opérateur (les PE sont, eux, border routers).
À qui appartiennent les CE ? Les routeurs CE sont en général la propriété de l'opérateur, ce qui lui permet de maîtriser de bout-en-bout le VPN fourni. Les clients raccordent en général aux CE leur routeur ou firewall—ceci nécessite une certaine coordination client-opérateur : à quel port du CE se raccorder ? quels sont les subnets souhaités par le client ? etc. J'ai vu des cas où les CE sont propriétés des clients, ce qui complexifie la coordination client-opérateur à mon sens—si un problème réseau survient, l'opérateur n'ayant pas la main sur les CE, il est plus difficile d'identifier la cause et plus facile de se renvoyer la balle. Enfin, le rôle des CE se limitant au routage IP (sans notion de MPLS ni de VPN), ils sont moins onéreux que les PE ou P (quelques centaines d'euros).
Étape 1 : un backbone IP
La première étape consiste à avoir un routage cohérent dans l'AS avec un IGP. Par routage cohérent est entendu : chaque routeur doit pouvoir joindre en IP tout un autre routeur de l'AS, ce qui permettra, lorsque MPLS sera activé à l'étape 2, d'établir les LSP nécessaires qui seront empruntés par les services sus-jacents (L3VPN ici mais aussi L2VPN dans un autre contexte). Dans les réseaux opérateurs, les IGP les plus courants sont OSPF (choisi ici) et IS-IS.
Adressage privé ou public pour le backbone IP ? Les deux cas sont possibles. L'adressage privé (RFC 1918) a pour avantage évident l'économie d'adresses publiques et cela a été mon mode d'adressage favoris pendant plusieurs années. Dans nombre d'architectures opérateurs, l'IGP ne sert qu'à établir le MPLS (underlay) qui porte les services VPN (overlay)—ceux des clients et voire de l'opérateur lui-même qui peut se considérer comme client de son propre réseau. En ceci, un adressage privé est adapté car non visible à l'extérieur du réseau. Cependant, suite à une fusion de réseaux opérateurs à laquelle j'ai participé, ma préférence est plutôt à l'adressage public. Il permet en effet d'éviter les recouvrements d'adresses (qu'il faut corriger en réadressant ou contourner avec du NAT…) et facilite ainsi la fusion. Noter que la RFC 6752 va plutôt dans ce sens également (bien qu'elle aborde un aspect davantage Internet que backbone).
Des liens d'interco en /30 ou /31 ? Bien souvent, les liens d'interco entre PE et P sont point-à-point (et Ethernet), c'est-à-dire qu'il n'y a qu'un routeur de part et d'autre de chaque lien—contrairement à un LAN Ethernet où plusieurs équipements sont raccordés à un même switch. Un /30 réserve quatre IPs et, dans le cas de liens point-à-point, deux IPs sont inutiles et gaspillées (les adresses réseau et broadcast). Si c'est acceptable pour un adressage privé, cela ne l'est pas pour un adressage public car les adresses publiques se font rares. Aussi, depuis la RFC 3021, il est possible d'utiliser un adressage en /31 pour les liens point-à-point, ce qui va favorise l'adressage public à l'intérieur des backbones.
| PE1 | P1 |
|---|---|
|
|
| P2 | PE2 |
|---|---|
|
|
ip ospf network point-to-point.
Un lien OSPF peut en effet être de plusieurs types :
P2P (Point-to-Point), P2MP (Point-to-Multipoint), Broadcast ou NBMA (Non-Broadcast Multi-Access)—la
documentation Huawei
illustre bien la différence.
De ceci dépend la façon dont les adjacences sont établies (Hello Protocol) et le rôle des routeurs dans celles-ci.
Autrement dit, cela permet d'optimiser l'utilisation de OSPF sur le réseau et en ceci,
c'est une best practice d'indiquer le type de lien adéquat.
Ici, il s'agit de liens Ethernet P2P.
Il convient de l'indiquer à OSPF car un lien Ethernet est Broadcast par nature.
À ce stade, nous avons des liens physiques Ethernet point-à-point, des /31 pour l'adressage public et des liens OSPF P2P.
Voilà qui est propre et cohérent !
Étape 2 : un backbone IP/MPLS
La deuxième étape consiste à activer MPLS (et LDP) sur le backbone IP qui devient alors backbone IP/MPLS. L'article MPLS LDP a déjà abordé ceci en détail sur une architecture similaire.
| PE1 | P1 |
|---|---|
|
|
| P2 | PE2 |
|---|---|
|
|
Étape 3 : configuration d'un MPLS L3VPN
Dans cette troisième étape, nous allons configurer un VPN. Cela fait intervenir trois éléments principaux : VRF (VPN Routing and Forwarding), RD (Route Distinguisher) et RT (Route Target).
- Une VRF est tel un routeur virtuel isolé sur un PE (une instance de table de routage).
- Une VRF a un RD qui correspond à un ID unique sur le PE.
- Les VRF sont raccordées entre elles via des RT exportés-importés qui permettent (enfin) de former des VPN !
Soit en image :
Dans le schéma ci-dessus, deux VRF ont été créées : une par site.
Le format de RD le plus courant est <AS Number>:<Assigned Number>
où Assigned Number peut avoir plusieurs sémantiques :
l'ID du client dans le SI de l'opérateur, l'ID du site, le nombre de VRF créé, etc.
La signification est fonction des besoins et processus de l'opérateur.
Ici, j'ai simplement incrémenté de 1.
Même raisonnement pour les RT.
Noter bien, c'est car les RT sont exportés-importés de part et d'autre que le VPN est formé !
Les RT s'apparentent ainsi à des connecteurs de VRF.
En outre, nous pourrions aussi avoir ce schéma :
Cette fois-ci, une seule VRF a été créée pour les deux sites. Le même RD a été utilisé ainsi que le même RT. Cela simplifie l'allocation des numéros. En fait, ces choix d'implémentation—qui relèvent aussi de la conception car il s'agit d'une politique de nommage—dépendent vraiment de l'opérateur. Dans mon expérience, j'ai vu les deux cas, chacun ayant ses avantages et ses inconvénients. En réalité, utiliser des RT différents permet surtout de créer des VPN hub-and-spoke et non full-mesh (le plus fréquent)—voir le §4.3.5. Pour la suite de l'article, j'ai choisi le cas 1 afin de bien distinguer les notions de RD et RT.
| PE1 | PE2 |
|---|---|
|
|
show ip route vrf.
Elle permet d'afficher la table de routage d'une VRF donnée.
Cette table de routage est distincte de celle par défaut appelée GRT (Global Routing Table).
Lien CE-PE ou attachment circuit
Faisons un zoom sur les CE, côté WAN (vers leur PE de rattachement) et côté LAN (vers leur réseau interne) :
172.16.0.0/30 et 172.16.0.4/30)
et les LAN client (192.168.1.0/24 et 192.168.2.0/24) sont représentés.
Comment le CE est-il raccordé au PE ?
Ceci ramène à la notion d'attachment circuit,
c'est-à-dire à l'association d'un CE à sa VRF.
Dans cette maquette, il s'agit simplement d'interfaces physiques liées aux VRF.
Autrement dit, les CE sont raccordés physiquement aux PE en FastEthernet (100M) via des liens cuivre.
C'est un fonctionnement tout à fait valide et réel à la différence que le raccordement se fait plutôt en GigabitEthernet (1G) à l'ère des liens fibre.
Noter que les attachment circuits peuvent aussi se traduire par différents liens logiques sur un même lien physique—par
exemple, le VLAN 10 est associé à la VRF VPN-A1, le VLAN 20 à la VRF VPN-B1, etc.
Routers can be attached to each other, or to end systems, in a
variety of different ways: PPP connections, ATM Virtual Circuits
(VCs), Frame Relay VCs, ethernet interfaces, Virtual Local Area
Networks (VLANs) on ethernet interfaces, GRE tunnels, Layer 2
Tunneling Protocol (L2TP) tunnels, IPsec tunnels, etc. We will use
the term "attachment circuit" to refer generally to some such means
of attaching to a router. An attachment circuit may be the sort of
connection that is usually thought of as a "data link", or it may be
a tunnel of some sort; what matters is that it be possible for two
devices to be network layer peers over the attachment circuit.
Comment sont adressés les attachment circuits ? Un adressage privé en /30 est tout à fait adapté (inutile d'économiser des adresses privées sachant que le /31 n'est pas forcément supporté par tous les CE). Une coordination préalable client-opérateur est nécessaire car le réseau d'interco choisi ne peut être utilisé par le client sur son LAN. Une autre solution, plus maligne, est de fonctionner en adressage public mais sans redistribuer le réseau d'interco public choisi—il reste local au lien—de sorte à ne pas gaspiller d'adresses publiques. Cela a pour avantage de ne pas nécessiter de coordination client-opérateur car le client n'utilise (normalement) pas, de lui-même, des adresses publiques appartenant à l'opérateur. Ici, pour rester simple, des interco privées ont été choisies.
Comment sont routés les LAN client ?
Si les attachment circuits permettent l'attachement des CE à leur VPN, ils ne constituent pas les LAN client pour autant.
Ce qui importe surtout, c'est que les LAN client (192.168.1.0/24 et 192.168.2.0/24 ici) soient routés de bout-en-bout du VPN.
Plusieurs options pour ceci :
soit des routes statiques sont configurées sur les PE dans les VRF adéquates,
soit le CE annonce dynamiquement au PE les routes avec
RIP (acceptable pour un échange de routes sur un hop), OSPF ou BGP.
Dans la deuxième partie de l'article, nous verrons un tel échange en action avec BGP.
Le calme avant la tempête
Avant d'aborder la deuxième partie de l'article, la plus dense, voici finalement ce que perçoit réellement le client du service fourni par l'opérateur :
À ce stade, les VRF sont configurées sur les PE mais ces derniers n'échangent encore rien pour former le VPN proprement dit. Ceci appartient au plan de contrôle qui est l'objet de l'étape 4 dans la deuxième partie de l'article.