MPLS VPN Partie 2
Dans la première partie de l'article, nous avons préparé le backbone IP/MPLS afin qu'il puisse porter un service MPLS L3VPN que nous avons commencé à configurer.
Étape 4 : un peering BGP VPN-IPv4 (plan de contrôle)
Rentrons un peu plus dans le vif du sujet avec le plan de contrôle des MPLS L3VPN qui s'appuie sur MP-BGP (RFC 4760) pour échanger les routes VPN-IPv4 :
The BGP Multiprotocol Extensions [3] allow BGP to carry routes from
multiple "address families". We introduce the notion of the "VPN-
IPv4 address family". A VPN-IPv4 address is a 12-byte quantity,
beginning with an 8-byte "Route Distinguisher (RD)" and ending with a
4-byte IPv4 address. If two VPNs use the same IPv4 address prefix,
the PEs translate these into unique VPN-IPv4 address prefixes. This
ensures that if the same address is used in two different VPNs, it is
possible to install two completely different routes to that address,
one for each VPN.
Pour résumer ceci, une route VPN-IPv4 est une route classique mais préfixée du RD de sa VRF.
C'est précisément ce qui permet à deux VRF différentes d'utiliser les mêmes réseaux sans se recouvrir—si,
évidemment, elles ne forment pas un VPN commun en exportant-important leurs RT (comme vu à l'étape 3).
Par exemple, la route 172.16.0.0/30 de la VRF VPN-A1 devient 100:0:172.16.0.0/30.
Une autre VRF VPN-B1 (d'un autre VPN donc) ayant pour RD 100:53 pourrait utiliser la même route qui deviendrait 100:53:172.16.0.0/30.
Ainsi, ces deux dernières routes ne sont pas les mêmes, car le RD diffère de l'une à l'autre.
Nous retrouverons cette notation RD:prefix plus loin dans les sorties Cisco.
L'établissement du peering
Pour permettre l'échange de routes VPN-IPv4 entre les PE, ces derniers doivent établir un peering BGP entre eux avec la « capacité » VPN-IPv4. Par raccourci, nous parlons de peering MP-BGP ou MP-iBGP (i pour internal car on se situe dans le même AS) :
| PE1 | PE2 |
|---|---|
|
|
neighbor update-source.
Par défaut, BGP tente de joindre un peer en sourçant avec l'adresse IP de l'interface de sortie.
Ici, PE1 tenterait de joindre PE2 en sourçant avec 1.0.0.0.
Or, PE2 s'attend à recevoir une demande de la part de 1.0.0.10,
sans quoi le peering ne montera pas.
Il est alors nécessaire de forcer l'adresse IP source.
Cela peut sembler redondant avec la commande bgp router-id mais cette dernière a en réalité une autre utilité pour BGP :
le Router ID rentre dans l'algorithme de sélection des routes (non détaillé ici, voir ce
message pour les curieux).
La commande neighbor send-community extended,
automatiquement ajoutée par Cisco lors de l'activation de la capacité VPN-IPv4,
permet l'envoi des communautés BGP dites étendues.
C'est ce qui permet l'envoi des RT (comme nous le verrons plus bas lors de l'échange d'une route VPN-IPv4) :
The function performed by the Route Target attribute is similar to
that performed by the BGP Communities attribute. However, the format
of the latter is inadequate for present purposes, since it allows
only a 2-byte numbering space. It is desirable to structure the
format, similar to what we have described for RDs (see Section 4.2),
so that a type field defines the length of an administrator field,
and the remainder of the attribute is a number from the specified
administrator's numbering space. This can be done using BGP Extended
Communities. The Route Targets discussed herein are encoded as BGP
Extended Community Route Targets [BGP-EXTCOMM]. They are structured
similarly to the RDs.
Voici la capture correspondant à l'établissement du peering MP-BGP entre PE1 et PE2 :
OPEN envoyé de PE1 à PE2 et transporté dans le label MPLS 21
(conformément à la LFIB de P1—voir l'étape 2).
Nous noterons surtout la négociation MP-BGP qui va permettre l'échange de routes VPN-IPv4 (l'AFI 1 combiné au SAFI 128) :
The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
NLRI. If the Address Family Identifier (AFI) field is set to 1, and
the Subsequent Address Family Identifier (SAFI) field is set to 128,
the NLRI is an MPLS-labeled VPN-IPv4 address. AFI 1 is used since
the network layer protocol associated with the NLRI is still IP.
Note that this VPN architecture does not require the capability to
distribute unlabeled VPN-IPv4 addresses.
Pour terminer, cet extrait rappelle qu'il n'est pas nécessaire d'établir un peering IPv4 simple (« unlabeled IPv4 addresses ») pour qu'un peering VPN-IPv4 soit fonctionnel. Aussi, nous l'avons explicitement désactivé dans les configurations ci-dessus afin de bien comprendre ceci (et car Cisco l'active par défaut).
L'échange de routes VPN-IPv4
Par défaut, aucune route n'est échangée ou « redistribuée ». Pour l'exemple, activons la redistribution des attachment circuits (qui sont des routes directement connectées) :
| PE1 | PE2 |
|---|---|
|
|
Et analysons la capture associée :
UPDATE envoyé de PE2 à PE1 et transporté dans le label MPLS 27
(conformément à la LFIB de P2—voir l'étape 2).
La route VPN-IPv4 est présente dans l'attribut MP_REACH_NLRI.
Il y a le préfixe 172.16.0.4 et le label 43 que PE1 devra adjoindre—voir le plan de données à l'étape 5.
Mais où est le masque /30 ?
Il est en fait contenu dans le champ Prefix Length qui (je préviens, c'est moche)
comprend à la fois la longueur du label (24 bits) et la longueur du RD (64 bits), soit : 118-24-64 = 30.
Comme attendu, le RT 100:3 est contenu dans l'attribut EXTENDED_COMMUNITIES.
Ce RT est exporté par la VRF VPN-A2 et importé par la VRF VPN-A1 pour former le VPN.
Naturellement, ces informations sont visibles depuis PE1 et PE2 :
| PE1 | PE2 |
|---|---|
|
|
Nous retrouvons ci-dessus les routes VPN-IPV4, les RT exportés et les labels MPLS à adjoindre pour le plan de données, qui est l'objet de l'étape suivante.
Étape 5 : visualiser le label stacking (plan de données)
Comme introduit dans l'article L2VPN vs L3VPN, le plan de données consiste en une pile (stack) de labels MPLS de deux niveaux :
- Le premier niveau est le label LSP et change de proche-en-proche (de P à P)—c'est le label switching classique de MPLS.
- Le deuxième niveau est le label VPN et est inchangé de bout-en-bout (de PE à PE).
Comprenez bien : les P ne voient pas le label VPN et ne traitent que le label LSP. Ainsi, nous percevons bien l'intérêt du LSP : c'est un véritable tunnel dans lequel il est possible d'acheminer plusieurs types de trafic (IP, L2VPN, L3VPN, …, et ce, en fonction de la valeur du label).
Before a customer data packet travels across the Service Provider's
backbone, it is encapsulated with the MPLS label that corresponds, in
the customer's VPN, to the route that is the best match to the
packet's destination address. This MPLS packet is further
encapsulated (e.g., with another MPLS label or with an IP or Generic
Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]) so that
it gets tunneled across the backbone to the proper PE router. Thus,
the backbone core routers do not need to know the VPN routes.
Cet extrait mentionne bien l'encapsulation de MPLS dans MPLS (stack) et l'aspect agnostique des P (core routers). La possibilité de transporter le label VPN directement dans IP ou GRE (RFC 4023) est par ailleurs évoquée, typiquement dans le cas d'un réseau non-MPLS à traverser (non abordé ici—le nombre de cas en architecture réseau est faramineux, tout voir d'un coup n'est pas possible). Pour résumer, nous avons, dans l'ordre des choses :
- Le PE source effectue du label stacking/pushing (empiler le label VPN et label LSP).
- Les P effectuent du label switching (changer le label LSP).
- Le PE destinataire effectue du label unstacking/popping (dépiler le label VPN et le label LSP).
Réalisons un ping dans la VRF VPN-A1 depuis PE1 et analysons les captures associées :
PE1#ping vrf VPN-A1 172.16.0.5 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 172.16.0.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 104/104/104 ms
43 (VPN) et 29 (LSP).
43 (VPN) et 21 (LSP)—seul
le label LSP a changé.
43 (VPN)—seul
le label VPN demeure (mécanisme PHP).
Et voici donc une illustration du plan de données d'un MPLS L3VPN.
Le paquet IP du client est encapsulé dans une stack de labels.
Le label VPN demeure de bout-en-bout.
Le label LSP change de proche-en-proche.
Cette stack de labels est bien visible depuis un traceroute :
PE1#traceroute vrf VPN-A1 172.16.0.5 probe 1
Type escape sequence to abort.
Tracing the route to 172.16.0.5
1 1.0.0.1 [MPLS: Labels 29/43 Exp 0] 72 msec
2 1.0.0.3 [MPLS: Labels 21/43 Exp 0] 72 msec
3 172.16.0.5 [MPLS: Label 43 Exp 0] 76 msec
traceroute emploie l'extension ICMP définie dans la
RFC 4950.
Cette documentation Cisco
explique bien le fonctionnement.
C'est un peu pénible à lire, mais assez intuitif en fait.
De toute façon, on sent bien que le suivi du chemin MPLS peut être automatisé.
Si nous, humains, sommes capables de le suivre (via des captures ou en se connectant sur chaque LSR), alors un protocole peut le faire pour nous !
Petit exercice…
À ce stade, vous devriez être capable de déterminer à partir des LFIB MPLS présentées (étape 2 de la première partie et étape 4 de cette seconde partie) la stack de labels dans le sens PE2 → PE1.
PE2#traceroute vrf VPN-A2 172.16.0.1 probe 1
Type escape sequence to abort.
Tracing the route to 172.16.0.1
1 1.0.0.4 [MPLS: Labels 19/21 Exp 0] 68 msec
2 1.0.0.2 [MPLS: Labels 27/21 Exp 0] 96 msec
3 172.16.0.1 [MPLS: Label 21 Exp 0] 88 msec
Étape 6 : le routage CE-PE
Pour cette dernière étape, commençons par résumer rapidement ce qui a été fait auparavant.
Nous avons configuré un MPLS L3VPN ainsi que les attachment circuits côté PE.
Nous avons visualisé—aux étapes 4 et 5—comment se comportaient le plan de contrôle pour l'échange des préfixes associés
(172.16.0.0/30 et 172.16.0.4/30)
et le plan de données lors d'un ping entre ces préfixes.
Pour terminer, abordons la partie CE car (enfin !) il s'agit de router les LAN client de bout-en-bout du VPN.
Ceci a été introduit à la fin de la première partie de l'article avec la question
« comment sont routés les LAN client ? ».
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.
Pour être plus précis, la question est plutôt : comment le CE et le PE s'échangent-ils les LAN client entre eux ? Et pour être encore plus précis, il y a deux sous-questions : comment le PE apprend les routes du CE ? comment le CE apprend les routes du PE ? En fait, la RFC 4364 résume bien les possibilités :
7. How PEs Learn Routes from CEs
The PE routers that attach to a particular VPN need to know, for each
attachment circuit leading to that VPN, which of the VPN's addresses
should be reached over that attachment circuit.
The possible PE/CE distribution techniques are:
1. Static routing (…)
2. PE and CE routers may be RIP peers (…)
3. The PE and CE routers may be OSPF peers (…)
4. The PE and CE routers may be BGP peers (…)
8. How CEs Learn Routes from PEs
If the PE places a particular route in the VRF it uses to route
packets received from a particular CE, then in general, the PE may
distribute that route to the CE.
In most cases, however, it will be sufficient for the PE to simply
distribute the default route to the CE. (In some cases, it may even
be sufficient for the CE to be configured with a default route
pointing to the PE.)
Dans la suite, spoiler alert, BGP sera utilisé. Mais avant cela, je commente rapidement les possibilités évoquées ci-dessus, en m'appuyant sur les cas que j'ai rencontrés au travail.
How PEs Learn Routes from CEs? Pour les routes statiques, c'est assez immédiat à comprendre (et formateur). La configuration ressemblerait à :
| PE1 | PE2 |
|---|---|
|
|
Cela fonctionnerait. Mais les routes statiques sont à éviter—sauf si elles sont descendues dynamiquement en RADIUS à la montée des CE en PPP-DHCP sur le PE (alors appelé BAS). Pourquoi cela ? Car, dans mon expérience, les routes statiques sont peu adaptées aux processus de (dé)provisioning de l'opérateur. Souvent, elles sont configurées puis oubliées—errare humanum est. Il en résulte des routes qui « traînent », qui n'aident pas au diagnostic et, surtout, qui peuvent avoir des effets de bord.
Concernant RIP, j'ai dû l'employer dans un cas où le CE n'appartenait pas à l'opérateur (déconseillé). Soit le client ne savait que configurer RIP, soit son équipement ne supportait que RIP. Sinon, l'hésitation porte généralement entre OSPF et BGP, ce dernier étant plutôt vainqueur. À juste titre à mon sens. C'est dans sa nature même d'échanger des routes entre AS différents. Le réseau du client peut tout à fait être vu comme un petit AS.
How CEs Learn Routes from PEs? Il est vrai que, point de vue CE, une route par défaut (envoyée dynamiquement en BGP par le PE ou configurée statiquement sur le CE) est suffisante, et ce, car le PE représente sa porte de sortie quelle que soit la destination. Cependant, certains cas nécessitent quand même l'envoi explicite des LAN client. Par exemple, si le CE est double-attaché à plusieurs PE (multi-homing), il est possible, en jouant avec les annonces BGP, de faire en sorte qu'une partie des LAN passent par le premier lien et que l'autre partie passent par le deuxième.
Configuration du peering BGP
Dans la suite, nous allons donc annoncer explicitement les LAN client en BGP, ce qui permettra par la même d'aborder certaines particularités de BGP. L'idée, finalement, est plutôt intuitive : chaque CE annonce son LAN à son PE de rattachement, lequel annonce le LAN du CE opposé. Schématiquement :
+-----+ +-----+ +-----+ +-----+
| | 192.168.1.0/24 >>> | | 192.168.1.0/24 >>> | | 192.168.1.0/24 >>> | |
| CE1 |-------- eBGP --------| PE1 |------- MP-iBGP ------| PE2 |-------- eBGP --------| CE2 |
| | <<< 192.168.2.0/24 | | <<< 192.168.2.0/24 | | <<< 192.168.2.0/24 | |
+-----+ +-----+ +-----+ +-----+
AS64512 AS100 AS100 AS64512
Vous remarquerez alors que le BGP de CE à PE n'est pas le même que celui de PE à PE. Effectivement, de CE à PE, il s'agit d'un simple peering IPv4 et non VPN-IPv4. Les configurations associées :
| CE1 | PE1 |
|---|---|
|
|
| CE2 | PE2 |
|---|---|
|
|
Il y a (encore) à dire… Tout d'abord, nous retrouvons la configuration des attachment circuits et des gateways des LAN client. S'ensuit la configuration des peerings BGP entre les CE et les PE.
Les CE dans un AS privé ?
La première chose à remarquer est l'utilisation de l'AS64512 pour chaque CE.
Ce numéro appartient à la plage 64512-65534 qui est « Reserved for Private Use »
par l'IANA.
C'est une plage que les opérateurs peuvent employer pour des besoins internes.
Notre cas est un bon exemple d'utilisation des AS privés.
Il est possible d'avoir un AS différent pour chaque CE,
comme il est possible d'avoir le même pour tous les CE (quel que soit leur VPN)—comme ici.
La dernière option a pour avantage une gestion simplifiée (qui favorise l'automatisation).
Cependant, elle requiert l'option allowas-in sur les CE.
Pourquoi cela ?
Parce que CE1 va recevoir la route 192.168.2.0/24
ayant dans AS_PATH (un attribut BGP bien connu) l'AS64512 de CE2.
Or, cela correspond à son propre AS et ceci équivaut à une boucle comme l'explique la
RFC 4271 :
If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
route should be excluded from the Phase 2 decision function. AS loop
detection is done by scanning the full AS path (as specified in the
AS_PATH attribute), and checking that the autonomous system number of
the local system does not appear in the AS path. Operations of a BGP
speaker that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.
Par conséquent, la route sera ignorée.
Le même raisonnement s'applique à CE2 pour la route 192.168.1.0/24 de CE1.
Dans notre cas—et c'est répandu—il convient d'autoriser une telle particularité avec allowas-in 1
(le 1 indiquant que AS_PATH peut contenir une seule fois AS64512).
Pourquoi le next-hop-self sur les PE ?
Lorsqu'un routeur A envoie une route en BGP à un routeur B, il remplit l'attribut NEXT_HOP.
Cet attribut prend une valeur qui ne correspond pas
toujours à l'adresse IP du routeur A sur l'interco avec le routeur B—les
différents cas sont indiqués en §5.1.3.
Parfois, il est nécessaire de forcer la valeur à cette adresse IP d'interco.
Dans notre cas, c'est fait implicitement car il s'agit d'un peering eBGP (et non iBGP)
mais cet attribut est suffisamment important pour le rappeler.
Pourquoi des prefix-list sur les PE et les CE ?
Une bonne habitude à prendre en BGP est de filtrer systématiquement les annonces-réceptions
afin de n'autoriser que ce qui est strictement nécessaire—les LAN client ici.
D'ailleurs, les versions récentes de Cisco l'imposent.
Cela permet de se prémunir contre les route leaks,
des routes annoncées par mégarde (c'est souvent dû à une erreur humaine).
Analyse du peering BGP
Après tout ce blabla, voyons maintenant l'état des sessions BGP et les routes annoncées-reçues de part et d'autre :
| CE1 | PE1 |
|---|---|
|
|
| CE2 | PE2 |
|---|---|
|
|
Bon… Cela devient verbeux mais ce qu'il faut retenir, ce sont les concepts. À commencer par le parallèle entre les commandes BGP côté CE et côté PE :
- Côté CE :
show bgp ipv4 unicast - Côté PE :
show bgp vpnv4 unicast vrf
C'est car le peering BGP est établi en VRF côté PE
et en GRT (Global Routing Table) côté CE—c'est-à-dire, dans la table de routage par défaut.
De plus, nous voyons bien AS64512 apparaître dans AS_PATH sur les CE,
particularité rendue possible grâce à l'option allowas-in abordée plus haut.
redistribute connected et redistribute static
pour échanger les routes VPN-IPv4 entre les PE.
Ici, on dirait que les routes annoncées en BGP par les CE ont été automatiquement échangées entre les PE ?
En effet, encore une particularité de BGP :
les routes apprises en eBGP sont automatiquement redistribuées dans l'iBGP
(et inversement, celles apprises en iBGP sont automatiquement redistribuées dans l'eBGP).
Pas de redistribute bgp dans la configuration BGP donc !
100:2:192.168.1.0/24 annoncée par PE1.
Il faudrait aussi établir une session BGP VPN-IPv4 entre PE1 et PE3.
Plus généralement, chaque PE devrait avoir une session BGP VPN-IPv4 avec tous les autres PE,
soit n*(n-1)/2 sessions sur le réseau (où n est le nombre de PE) !
Aussi, la
RFC 4456,
qui propose un modèle centralisé levant ce problème de passage à l'échelle, est couramment utilisée dans les réseaux opérateurs.
Le mode d'allocation des labels sur les PE
Maintenant qu'il y a deux routes dans chaque VRF, nous pouvons remarquer quelque chose. Pour cela, et comme pour les attachment circuits à l'étape 4, affichons les tables de routage en VRF, les routes VPN-IPv4 reçues et les LFIB sur les PE :
| PE1 | PE2 |
|---|---|
|
|
Les deux dernières lignes sont à noter.
Un label différent a été alloué pour chaque route VPN-IPv4.
Sur PE1, il s'agit des labels 21 et 22.
Sur PE2, il s'agit des labels 43 et 44.
En quoi est-ce notable ?
Sur un vrai réseau opérateur, il peut y avoir des milliers de VRF dans lesquelles peuvent se trouver des centaines de routes.
Par conséquent, les labels alloués peuvent poser un problème de mémoire au PE.
En fait, trois modes d'allocation avaient été proposés :
Whether or not each route has a distinct label is an implementation
matter. There are a number of possible algorithms one could use to
determine whether two routes get assigned the same label:
- One may choose to have a single label for an entire VRF (…)
- One may choose to have a single label for each attachment circuit (…)
- One may choose to have a distinct label for each route (…)
There may be other possible algorithms as well. The choice of
algorithm is entirely at the discretion of the egress PE, and is
otherwise transparent.
Chez Cisco, ces modes sont respectivement nommés per-vrf, per-ce et per-prefix.
Le dernier mode est celui par défaut (et donc le nôtre dans la maquette).
Dans la réalité, les deux premiers modes sont davantage employés, le per-vrf étant le plus naturel à mon sens.
Ici, cela impliquerait, par exemple, que le label 21 sur PE1 soit alloué pour les deux routes distinctes
(de même pour le label 43 sur PE2).
Noter qu'il y aurait quand même deux annonces MP-iBGP pour ces routes, cela ne change en rien le protocole d'échange—ainsi, comme
le dit l'extrait, l'implémentation est à la discrétion du PE.
Le test final… Enfin !
Voyons si les LAN des CE peuvent se joindre de bout-en-bout :
CE1#ping 192.168.2.254 source 192.168.1.254 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.2.254, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.254
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 140/140/140 ms
44 (VPN) et 21 (LSP).
Noter que le label LSP est le même que celui du ping des attachment circuits (étape 5).
Victoire ! Achevons ceci avec un traceroute :
CE1#traceroute 192.168.2.254 source 192.168.1.254 probe 1
Type escape sequence to abort.
Tracing the route to 192.168.2.254
1 172.16.0.1 20 msec
2 1.0.0.1 [MPLS: Labels 29/44 Exp 0] 124 msec
3 1.0.0.3 [MPLS: Labels 21/44 Exp 0] 144 msec
4 172.16.0.5 [MPLS: Label 44 Exp 0] 120 msec
5 172.16.0.6 112 msec
Petit exercice…
À ce stade, comme précédemment, vous devriez être capable de déterminer à partir des LFIB MPLS présentées (étape 2 de la première partie et étape 6 de cette seconde partie) la stack de labels dans le sens CE2 → CE1.
CE2#traceroute 192.168.1.254 source 192.168.2.254 probe 1
Type escape sequence to abort.
Tracing the route to 192.168.1.254
1 172.16.0.5 8 msec
2 1.0.0.4 [MPLS: Labels 19/22 Exp 0] 116 msec
3 1.0.0.2 [MPLS: Labels 27/22 Exp 0] 156 msec
4 172.16.0.1 [MPLS: Label 22 Exp 0] 112 msec
5 172.16.0.2 124 msec
Le mot de la fin
Si vous êtes arrivé jusqu'ici, félicitation !
Cet article, et la deuxième partie en particulier, a été dense en notions : backbone, IGP, LDP, VRF, plan de contrôle (BGP, MP-BGP), plan de données (MPLS), etc. Plutôt que de simplement lister les commandes à exécuter pour parvenir à ce réseau opérateur miniature puis dire « regardez, ça marche », j'ai souhaité aborder des questions souvent posées dans le milieu opérateur (quel mode d'adressage ? pourquoi ce mode ? quel routage CE-PE ? pourquoi BGP ? etc.).
L'idée du métier d'ingénieur n'est pas de maîtriser une implémentation particulière, mais de saisir les concepts l'ayant engendrée. Ainsi, le parallèle répété avec les RFC est important pour montrer que Cisco n'est qu'une implémentation de ceci et qu'il en existe d'autres (Huawei, Nokia, Juniper, etc.). Si vous travaillez chez un opérateur qui a un backbone IP/MPLS, vous retrouverez sans doute dans celui-ci nombre de concepts évoqués ici.