PABX-FR.COM
 |
| Implémentation MLPS avec Cisco |
PABX-FR.COM |
|
 |
|
 |
|
Implémentation Mpls avec Cisco 1 - Introduction Dans les réseaux IP traditionnels, le routage des paquets s’effectue en
fonction de l’adresse de destination contenue dans l’entête de niveau 3. Chaque
routeur, pour déterminer le prochain saut (next-hop), consulte sa table de
routage et détermine l’interface de sortie vers laquelle envoyer le paquet. Le
mécanisme de recherche dans la table de routage est consommateur de temps CPU,
et avec la croissance de la taille des réseaux ces dernières années, les tables
de routage des routeurs ont constamment augmenté. Il était donc nécessaire de
trouver une méthode plus efficace pour le routage des paquets. Le but de MPLS
était à l’origine de donner aux routeurs IP une plus grande puissance de
commutation, en basant la décision de routage sur une information de label (ou
tag) inséré entre le niveau 2 (Data-Link Layer) et le niveau 3 (Network Layer).
La transmission des paquets était ainsi réalisée en switchant les paquets en
fonction du label, sans avoir à consulter l’entête de niveau 3 et la table de
routage. 2 - Matériel et configurations utilisés Afin d’étayer d’exemples pratiques les différents principes de MPLS abordés
dans ce
document, deux « pods » (nommés L10 et L20) composés de 7 routeurs chacun ont
été
utilisés. Ces routeurs sont reliés au moyen de liaisons série, de la manière
suivante : 3 - Principes généraux – Terminologie Pour cette partie, seul le pod L10 a été utilisé. Le schéma suivant résume
les différents
subnets et adresses IP configurés sur les routeurs : Comme il l’a été brièvement expliqué en introduction, le principe de base de
MPLS
est la commutation de labels. Ces labels, simples nombres entiers, sont insérés
entre
les entêtes de niveaux 2 et 3, les routeurs permutant ces labels tout au long du
réseau
jusqu’à destination, sans avoir besoin de consulter l’entête IP et leur table de
routage.
Cette technique, appelée Label Swapping, est similaire à la commutation de
cellules
sur ATM avec les informations de VPI/VCI ou à la commutation sur réseau Frame
Relay avec les DLCI. Toutefois, MPLS permet de définir des piles de labels
(label
stack), dont l’intérêt apparaîtra avec le TE et les VPN. Les routeurs réalisant
les
opérations de label swapping sont appelés LSR pour Label Switch Routers. 3.3 - Classification des paquets A l’entrée du réseau MPLS, les paquets IP sont classés dans des FEC (Forwarding Equivalent Classes). Des paquets appartenant à une même FEC suivront le même chemin et auront la même méthode de forwarding. Typiquement, les FEC sont des préfixes IP appris par l’IGP tournant sur le backbone MPLS, mais peuvent aussi être définies par des informations de QoS ou de TE. La classification des paquets s’effectue à l’entrée du backbone MPLS, par les Ingress LSR. A l’intérieur du backbone MPLS, les paquets sont label-switchés, et aucune reclassification des paquets n’a lieu. Chaque LSR affecte un label local, qui sera utilisé en entrée, pour chacune de ses FEC et le propage à ses voisins. Les LSR voisins sont appris grâce à l’IGP. L’ensemble des LSR utilisés pour une FEC, constituant un chemin à travers le réseau, est appelé Label Switch Path (LSP). Il existe un LSP pour chaque FEC et les LSP sont unidirectionnels. 3.4 - Mode trame et mode cellule Il existe deux catégories d’interfaces MPLS sur les routeurs, dépendant de leur mode de fonctionnement. Le premier mode, appelé mode trame (framed mode), correspond aux interfaces traitant des paquets de taille variable, comme par exemple Ethernet, Frame-Relay, PPP, etc. Le second mode concerne les interfaces ATM et est appelé mode cellule (cell mode), la commutation étant basée sur la notion de circuit. Sur ATM, les circuits virtuels sont définis par les champs VPI/VCI de l’entête des cellules. Suivant le mode de fonctionnement d’une interface, les méthodes de propagation des labels aux routeurs voisins diffèrent. 3.5 - Distribution des labels (TDP / LDP) Les LSR se basent sur l’information de label pour commuter les paquets au
travers du
backbone MPLS. Chaque routeur, lorsqu’il reçoit un paquet taggué, utilise le
label
pour déterminer l’interface et le label de sortie. Il est donc nécessaire de
propager les
informations sur ces labels à tous les LSR. Pour cela, des protocoles de
distributions
de labels sont utilisés.
Suivant le type des FEC, différents protocoles sont employés pour l’échange de
labels
entre LSR:
Chaque voisin est listé avec toutes les adresses IP qui lui appartiennent. La
méthode
d’allocation des labels (unsollicited downstream, downstream on demand) est
également indiquée. Comme les interfaces des routeurs de cet exemple sont de
type
série, il s’agit d’interfaces en mode trame et le mode unsollicited downstream
est
employé.
Chaque voisin doit être marqué « xmit/recv » (émission / réception) pour que l’échange des labels puisse avoir lieu. 3.6 - Tables MPLS: TIB et TFIB A partir des informations apprises par TDP / LDP, les LSR construisent deux tables, la TIB et la TFIB. De manière générale, la TIB contient tous les labels appris des LSR voisins, tandis que la TFIB, utilisée pour la commutation proprement dite des paquets, est un sous-ensemble de la TIB. 3.6.1 - Rôle de la TIB (Tag Information Base) La première table construite par le routeur MPLS est la table TIB (Tag Information Base). Elle contient pour chaque subnet IP la liste des labels affectés par les LSR voisins. Il est possible de connaître les labels affectés à un subnet par chaque LSR voisin en utilisant la commande “show tag tdp bindings”. Un exemple de résultat de cette commande est donné ci-dessous:
On remarque que le routeur a affecté le label local 24 pour atteindre le réseau 10.10.4.4/32, et que les routeurs L10-R2 (10.10.2.2) et L10-R3 (10.10.3.3) ont respectivement affecté les label 21 et 20 pour atteindre le subnet 10.10.4.4/32. Il est à noter qu’IOS emploie le terme TSR pour « Tag Switch Router », qui est équivalent à celui de LSR. Pour les interfaces ATM (fonctionnant en mode cellule), la commande à utiliser est « show tag atm-tdp bindings » :
Les labels entre ATM LSR sont échangés au moyen d’un VC de contrôle MPLS, par défaut configuré sur VPI/VCI = 0/32. 3.6.2 - Rôle de la TFIB (Tag Forwarding Information Base) A partir de la table TIB et de la table de routage IP, le routeur construit une table TFIB, qui sera utilisée pour commuter les paquets. Chaque réseau IP est appris par l’IGP, qui détermine le prochain saut (“next-hop”) pour atteindre ce réseau. Le LSR choisit ainsi l’entrée de la table TIB qui correspond au réseau IP et sélectionne comme label de sortie le label annoncé par le voisin déterminé par l’IGP (plus court chemin). Il est possible d’afficher le contenu de la table TFIB grâce à la commande “show tagswitching forwarding”. Le résultat de cette commande sur le routeur utilisé précédemment est donné ci-dessous:
On remarque ainsi que le routeur L10-R1 a sélectionné pour le réseau 10.10.4.4/32 l’entrée de la TIB créée par le voisin 10.10.2.2 (connecté à L10-R1 par l’interface Serial0/1), qui a la meilleure métrique du point de vue de l’IGP (plus court chemin). Ainsi, pour chaque paquet reçu ayant comme label 24, le routeur commutera le paquet sur l’interface de sortie Serial0/1, et en permutant le label 24 par 21. La sélection de L10-R2 comme next-hop est confirmée en consultant l’entrée 10.10.4.4/32 de la table de routage:
Le routeur, lorsqu’il reçoit un paquet taggué, se base sur la TFIB pour
forwarder le
paquet. A partir d’un label d’entrée (local tag), il en déduit l’interface et le
label de
sortie (Outgoing interface et Outgoing tag or VC). Pour pouvoir utiliser la TFIB,
le
routeur doit employer CEF comme technique de commutation, qui doit être activée
globalement et pour chaque interface recevant des paquets taggués. CEF est en
effet le
seul mode de commutation capable d’utiliser la TFIB. Les anciens modes (fastswitching,
optimum switching, etc.) ne sont pas conçus pour gérer cette table.
L’interface de sortie à emprunter pour atteindre le subnet 10.10.4.4/32 est donc
Serial0/1, avec comme adresse de next-hop 10.10.12.2 (routeur L10-R2). Le tag
local
affecté par le routeur L10-R1 est 24 et le tag utilisé en sortie est 21 (appris
de L10-R2
par TDP).
On retrouve donc bien comme tag d’entrée le tag 21 pour atteindre le réseau 10.10.4.4. A partir de la version IOS 12.1(5)T, il est possible de connaître les labels d’un chemin servant à atteindre une destination précise, avec la commande « traceroute » :
Le label MPLS affiché pour chaque hop correspond au label en entrée du routeur.
Le
champ « Exp » (codé sur 3 bits) est similaire au champ TOS de l’entête IP, mais
n’est
pas employé ici. Dans cet exemple, le chemin pour atteindre R6 à partir de R7
est
{ R5, R3, R2, R4, R6 }.
Le schéma suivant montre comment les paquets sont acheminés de R7 jusqu’à R6 : Un LSR “egress” annonçant un réseau, qui lui est soit directement connecté,
soit
rattaché (appris par IGP, EGP, routage statique…) par une interface non tagguée,
n’a
pas besoin de recevoir de paquets taggués pour atteindre ce réseau. En effet, si
les
paquets reçus étaient taggués, le routeur egress devrait d’abord déterminer
l’interface
de sortie grâce à la table TFIB, puis effectuer une recherche dans la table de
routage
IP. L’opération de recherche sur le label dans la TFIB est inutile, car dans
tous les cas
le routeur devra effectuer une recherche dans la table de routage. Le routeur
egress
annonce donc ces réseaux IP avec le label “implicit-null” à ses voisins. Un LSR
ayant
comme label de sortie “implicit-null” aura ainsi pour but de dépiler le premier
label du
paquet et de faire suivre le paquet sur l’interface de sortie spécifiée. Le
routeur egress n’aura alors plus qu’une recherche à faire dans sa table de
routage.
Le réseau 10.10.2.2/32 correspond à l’interface Loopback0 du routeur L10-R2, connecté par un lien série à L10-R1. On constate que le tag de sortie (Outgoing tag) pour 10.10.2.2/32 est déclaré sous le terme « pop tag » pour signaler l’action de dépilement du premier label. Afin d’accélérer la convergence du réseau lors d’un changement de topologie
(lien
défectueux, dysfonctionnement d’un routeur), les LSR conservent dans leur table
TIB
la liste des labels annoncés pour chaque réseau IP par leurs voisins TDP, y
compris de
ceux n’étant pas les next-hops choisis par l’IGP. Ainsi, en cas de perte d’un
lien ou
d’un nœud, la sélection d’un nouveau label de sortie est immédiate : en effet,
il suffit
au routeur d’élire un nouveau next-hop et de sélectionner l’entrée
correspondante dans
la TIB, puis de mettre à jour la TFIB. Ce mode de fonctionnement est appelé mode
libéral (liberal mode). L’avantage de ce procédé est naturellement une
convergence
plus rapide lorsque les informations de routage au niveau 3 changent, avec pour
inconvénients que davantage de mémoire est allouée dans les routeurs et que des
labels supplémentaires sont utilisés. Le mode libéral est appliqué dans le cas
d’interfaces fonctionnant en mode trame. Il existe deux manières d’implémenter MPLS sur des réseaux de type ATM. La
première consiste à mettre en place un backbone constitué de switches purement
ATM, c’est-à-dire sans aucune connaissance de MPLS ou du routage IP. Dans ce
cas,
des PVCs sont simplement établis entre les routeurs MPLS et les labels sont
alors
encapsulés entre l’entête LLC/SNAP et l’entête IP. La deuxième méthode consiste
à
mettre en œuvre MPLS sur des switches ATM dits « IP-aware », c’est-à-dire ayant
connaissance de la topologie IP grâce à un protocole de routage, et où
l’information de
label est encodée dans les champs VPI/VCI. Ces switches sont alors appelés ATM
LSR. Ce paragraphe aborde les spécificités d’un backbone MPLS composé de LSR
ATM par rapport à un backbone purement IP, notamment dans les mécanismes de
distribution des labels. Le MPLS sur ATM natif ayant un fonctionnement similaire
à
des LSR « traditionnels », cette architecture ne sera pas étudiée ici.
Pour distribuer des labels MPLS entre LSR ATM, les protocoles TDP / LDP en mode
downstream on demand sont utilisés. Si le mode unsollicited downstream était
employé, comme dans le cas de LSR non ATM, on aurait le scénario suivant : 3.10 - Pile de labels (label stacking) Chaque paquet MPLS est susceptible de transporter plusieurs labels, formant
ainsi une
pile de labels, qui sont empilés et dépilés par les LSR. Cette possibilité
d’empiler des
labels, désignée sous le terme de Label Stacking, est utilisée par le Traffic
Engineering
et MPLS / VPN. 3.11 - Description de l’entête MPLS Un label MPLS occupe 4 octets (32-bits) et se présente sous la forme: 3.12 - Configuration d’un routeur LSR Cette partie, axée sur la configuration IOS, indique la liste des différentes étapes devant être suivies pour configurer MPLS sur un backbone IP. Les configurations résultantes sont fonctionnelles bien que dénuées d’intérêt pratique, aucun service spécifique à MPLS n’étant mis en œuvre. Elles permettent toutefois d’appréhender les changements induits par MPLS au niveau des commandes IOS par rapport à des routeurs purement IP. Les configurations minimales MPLS ainsi décrites peuvent être consultées en Annexe 1 de ce document. La première opération à effectuer pour utiliser MPLS est d’activer CEF (Cisco Express Forwarding) comme méthode de commutation sur tous les routeurs du backbone. En effet, CEF est la seule méthode de routage capable d’utiliser la TFIB pour commuter les paquets. En cas d’oubli, MPLS ne sera pas fonctionnel. CEF se configure avec la commande globale: “ip cef [distributed]”. Le mot-clé optionnel “distributed” permet d’activer CEF de manière distribuée sur les routeurs disposant de cartes de routage et de cartes filles comme les cartes VIP des routeurs 7500. Ce type de carte fait tourner une version réduite d’IOS et a une certaine autonomie de fonctionnement car disposant d’un processeur et de mémoire dédiée. 3.12.2 - Configuration d’un IGP Un protocole de routage interne doit être utilisé sur le backbone pour pouvoir diffuser les labels MPLS. Il est conseillé d’utiliser un protocole “link-state”, tel que OSPF ou IS-IS, qui sont les seuls à permettre le Traffic Engineering. Il est bien entendu nécessaire de s’assurer que la connectivité est établie partout sur le backbone avant de procéder à la configuration de MPLS. 3.12.3 - Configuration de TDP / LDP Pour permettre à un routeur d’établir une adjacence TDP avec un voisin sur une interface donnée, cette interface doit être configurée avec la commande “tagswitching ip”. Bien que le protocole LDP (standard de l’IETF) ne soit pas encore supporté, la commande “mpls ip” (correspondant à LDP) existe dans la version 12.1(5)T. Toutefois, cette commande a le même effet que “tag-switching ip”. 4 - Virtual Private Networks (VPN) Actuellement, il est très courant qu’une entreprise soit constituée de
plusieurs sites
géographiques (parfois très éloignés) et dont elle souhaite interconnecter les
réseaux
informatiques à travers un WAN (Wide Area Network). La solution la plus connue
et
la plus employée consiste à relier les sites au moyen de liaisons spécialisées,
dédiées à
l’entreprise. Toutefois, le coût prohibitif de ces liaisons, et éventuellement
la non aisabilité technique, par exemple avec des sites séparés de plusieurs centaines
de km,
amènent à rechercher des solutions plus abordables. Les fournisseurs d’accès
Internet
disposent de backbones étendus, et couvrant la plupart du temps une large
portion de
territoire. Il est donc plus simple pour une entreprise de relier ses sites aux
points de
présence (POP) de l’opérateur et mettre en place une solution VPN (Virtual
Private
Networks). Dans cette partie, le réseau de démonstration est constitué du pod L10, avec
R6 et R7
comme placés en tant que routeurs clients. Afin de séparer le plan d’adressage
du
backbone MPLS (adresses en 10.x.y.z), les adresses utilisées par les VPN sont du
type
100.x.y.z, avec les mêmes conventions que précédemment. Par exemple, l’interface
Loopback0 du routeur L10-R6 sera 100.10.6.6. Une terminologie particulière est employée pour désigner les routeurs (en
fonction de
leur rôle) dans un environnement MPLS / VPN : La notion même de VPN implique l’isolation du trafic entre sites clients
n’appartenant
pas aux mêmes VPN. Pour réaliser cette séparation, les routeurs PE ont la
capacité de
gérer plusieurs tables de routage grâce à la notion de VRF (VPN Routing and
Forwarding). Une VRF est constituée d’une table de routage, d’une FIB (Forwarding
Information Base) et d’une table CEF spécifiques, indépendantes des autres VRF
et de
la table de routage globale. Chaque VRF est désignée par un nom (par ex. RED,
GREEN, etc.) sur les routeurs PE. Les noms sont affectés localement, et n’ont
aucune
signification vis-à-vis des autres routeurs.
Chaque interface de PE reliée à un site client est rattachée à une VRF
particulière.
Lors de la réception de paquets IP sur une interfaces client, le routeur PE
procède à un
examen de la table de routage de la VRF à laquelle est rattachée l’interface, et
donc ne
consulte pas sa table de routage globale. Cette possibilité d’utiliser plusieurs
tables de
routage indépendantes permet de gérer un plan d’adressage par sites, même en cas
de
recouvrement d’adresses entre VPN différents.
La commande « ip vrf forwarding <vrf> » permet de placer une interface dans la
VRF spécifiée. Comme le montre l’exemple ci-dessus, la même adresse IP peut être
affectée plusieurs fois à différentes interfaces, car celles-ci sont placées
dans des VRF
différentes.
Si l’on examine la table de routage globale de L10-R4, on constate qu’il s’agit bien d’une table complètement différente et indépendante :
La table CEF d’une VRF peut également être examinée, au moyen de la commande « show ip cef vrf <vrf> <subnet> » :
La table CEF permet donc de déterminer le Next-Hop, l’interface de sortie et les labels utilisés pour atteindre un subnet particulier. 4.4 - Multiprotocol BGP (MP-BGP) Le protocole MP-BGP est une extension du protocole BGP 4, et permettant
d’échanger des routes Multicast et des routes VPNv4.
MP-BGP adopte une terminologie similaire à BGP concernant le peering : 4.4.1 - Notion de RD (Route Distinguisher) Des sites appartenant à des VPN isolés ayant la possibilité d’utiliser des plans d’adressage recouvrants, les routes échangées entre PE doivent être rendues uniques au niveau des updates BGP. Pour cela, un identifiant appelé RD (Route Distinguisher), codé sur 64 bits, est accolé à chaque subnet IPv4 d’une VRF donnée. Le RD s’écrit sous la forme « ASN:nn » ou « IP-Address:nn ». Dans les exemples de configuration fournis avec ce document, le paramètre ASN a été fixé arbitrairement à 100, et « nn » choisi en fonction de la VRF, quel que soit le routeur. Il est toutefois conseillé de choisir un RD unique par routeur et par VRF. Une route VPNv4, formé d’un RD et d’un préfixe IPv4, s’écrit ainsi sous la forme RD:Subnet/Masque. Exemple : 100:1:100.10.5.5/32. Lors de la création d’une VRF sur un PE, un RD doit être configuré. Les routes apprises soit localement (routes statiques, Loopback sur le PE), soit par les CE rattachés au PE seront ainsi exportées dans les updates MP-BGP avec ce RD. Les RD affectés aux différentes VRF existantes sur un PE peuvent être consultés au moyen de la commande « show ip vrf » :
On constate que les interfaces connectées aux VRF sont également listées par cette commande. 4.4.2 - Notion de RT (Route Target) Le RD permet de garantir l’unicité des routes VPNv4 échangées entre PE, mais
ne
définit pas la manière dont les routes vont être insérées dans les VRF des
routeurs PE.
L’import et l’export de routes sont gérés grâce à une communauté étendue BGP
(extended community) appelée RT (Route Target). Les RT ne sont rien de plus que
des
sortes de filtres appliqués sur les routes VPNv4.
Chaque VRF définie sur un PE est configurée pour exporter ses routes suivant un
certain nombre de RT. Une route VPN exportée avec un RT donné sera ajoutée dans
les VRF des autres PE important ce RT. Par exemple, si la route VPN
2000:1:192.168.1.0/24 est exportée par un routeur PE avec comme liste de RT
2000:500 et 2000:501, tous les autres routeurs PE ayant une ou plusieurs VRF
important au minimum un de ces deux RT ajouteront cette route dans leurs VRF
concernées. 4.4.3 - Configuration d’une VRF Les VRF sont configurées sur les routeurs PE avec les paramètres suivants :
En plus du RD et des RT, les updates MP-BGP contiennent d’autres
informations,
telles que le Site d’Origine (SOO), l’adresse IP du PE annonçant la route (PE
nexthop)
et le label VPN affecté par ce PE. 4.4.5 - Configuration MP-BGP d’un PE La configuration d’un routeur PE pour échanger des routes VPNv4 se présente sous la forme suivante :
On remarque la présence d’une section supplémentaire par rapport à une
configuration
BGP traditionnelle, introduite par la commande « address-family vpnv4 ». Cette
partie
de la configuration BGP contient tous les voisins tournant MP-BGP. Pour pouvoir
ajouter un voisin dans la configuration VPNv4, ce voisin doit être préalablement
déclaré dans la configuration globale de BGP (commande « remote- s » et autres).
Pour éviter qu’un voisin ne soit actif à la fois pour BGP et MP-BGP, la ligne «
no
neighbor <neighbor> activate » doit être insérée globalement. Naturellement, il
est
tout à fait possible pour un routeur d’être actif pour BGP et MP-BGP
simultanément.
Par exemple, le BGP traditionnel servira à propager les routes Internet aux
routeurs
PE, tandis que MP-BGP servira à la propagation des routes VPN.
Afin de faciliter l’ajout de nouveaux voisins, la notion de « peer-group » a été utilisée. Un peer group est défini par un nom, et il est possible de fixer certaines propriétés pour ce groupe : AS distant (remote-as), interface source pour les updates (update-source), etc. Chaque voisin est ensuite ajouté dans ce groupe avec un commande du type: « neighbor 10.10.5.5 peer-group iBGP ». Dans cet exemple, toutes les commandes appliquées au groupe « iBGP » le seront pour le voisin 10.10.5.5. 4.4.6 - Vérification du fonctionnement de MP-BGP Plusieurs commandes existent pour s’assurer du bon fonctionnement de BGP sur les routeurs. Par exemple, pour connaître toutes les routes apprises par MP-BGP sur un routeur donné, la commande « show ip bgp vpnv4 all » peut être utilisée :
Si l’on souhaite se restreindre à une VRF donnée, la commande « show ip bgp vpnv4 vrf <vrf> » peut être employée :
Les labels fournis dans les updates MP-BGP peuvent être affichés au moyen de la commande « sh ip bgp vpnv4 [vrf <vrf> | all] tags » :
4.5 - Echange des routes avec les CE Les CE sont des routeurs clients traditionnels, n’ayant aucune connaissance
de MPLS
ou des VRF. Les CE doivent donc échanger leurs routes IP avec leur PE au moyen
de
protocoles de routages classiques. Les protocoles supportés par IOS sont eBGP
(external BGP), RIPv2 et OSPF. La configuration BGP de L10-R5 (routeur PE) pour la VRF « RED » est listée ci-dessous :
L’interface reliant L10-R5 et L10-R7 étant paramétrée comme suit (sur L10-R5):
Chaque voisin devant être actif en eBGP dans une VRF donné doit donc être configuré dans la section « address-family ipv4 vrf <vrf> » correspondante. A titre indicatif, la configuration BGP de L10-R7 est fournie ci-dessous:
On constate donc que la configuration du routeur CE est tout à fait classique, sans présence de VRF ou de toute autre notion de VPN. La configuration RIPv2 avec un routeur CE suit le même principe qu’une configuration eBGP, mais les routes apprises par RIP doivent être réinjectées dans MP-BGP et réciproquement :
L’interface reliant L10-R4 et L10-R6 est paramétrée de la manière suivante (sur L10-R4):
4.6 - Transmission des paquets IP La transmission des paquets IP provenant des CE sur le backbone MPLS emploie la notion de label stacking. Pour atteindre un site donné, le PE source encapsule deux labels : le premier sert à atteindre le PE de destination, tandis que le second détermine l’interface de sortie sur le PE, à laquelle est reliée le CE. Le second label est appris grâce aux updates MP-BGP. Les tables CEF des routeurs peuvent être consultées pour déterminer les labels utilisées. Par exemple, supposons que l’on souhaite connaître les tags employés pour atteindre l’adresse de Loopback 100.10.5.5 configurée sur le routeur L10-R5, et placée dans la VRF « RED ». La consultation de la table de routage de la VRF « RED » sur L10-R4 montre que le next-hop est bien L10-R5 (10.10.5.5):
Le label utilisé pour atteindre L10-R5 est déterminé grâce à la table CEF globale du routeur :
L10-R4 imposera donc le label 27 pour atteindre L10-R5, le prochain saut étant le routeur L10-R2 (10.10.24.2). Le deuxième label (dit label VPN), servant à sélectionner l’interface de sortie sur L10-R5, peut être déterminé grâce à la table CEF de la VRF « RED », indépendante de la table CEF globale :
Le label VPN est donc 26. Pour joindre l’adresse IP 100.10.5.5 de la VRF « RED », le routeur L10-R4 imposera donc la pile de label { 27 26 }. Sur le backbone MPLS, la commutation se fera uniquement en fonction du premier label, comme le montre le résultat de la commande traceroute :
On remarque que seul le premier label a été modifié, le label VPN ayant été conservé intact pendant tout le cheminement sur le backbone. La copie d’écran suivante montre quel aurait été le résultat de la commande traceroute pour atteindre l’adresse de Loopback 10.10.5.5 (adresse globale) à partir de L10-R4 :
Il apparaît clairement que la présence du label VPN n’a pas d’effet sur les
routeurs P
du backbone : ceux-ci switchent les paquets entre routeurs PE et n’ont aucune
information sur les labels VPN.
On retrouve bien le label 26 pour atteindre le subnet 100.10.5.5/32 sur le routeur L10-R5. Si l’on effectue un traceroute vers l’adresse 100.10.7.7, appartenant à L10-R7, on obtient le résultat suivant :
On constate la présence du Penultimate Hop Popping, entre les routeurs L10-R3 (10.10.24.3) et L10-R5. (100.10.57.5). En effet, L10-R3 a retiré le premier label 23, servant à atteindre L10-R5. Ce fonctionnement est confirmé en consultant la table TFIB de L10-R3 :
Le schéma ci-dessous montre le trajet suivi par les paquets, de L10-R4 vers L10-R7 : 
Le principe des VRF permet de concevoir aisément des routeurs virtuels, qui consultent leurs différentes tables de routage en fonction de l’interface d’entrée des paquets. Ces tables sont remplies avec les routes du VPN associé, et le backbone MPLS assure la transmission des paquets entre les routeurs PE. Il se pose alors le problème de l’accès à Internet, situé par définition à l’extérieur des différents VPN. De plus, les fournisseurs d’accès Internet disposant de plusieurs points de sortie, il est important que les sites clients puissent utiliser le meilleur chemin vers l’extérieur. Différentes méthodes existent pour permettre un accès Internet. Les deux premières se situent dans la catégorie « Sub-Optimized Routing », du fait qu’elles ne permettent pas de sélectionner le meilleur chemin vers Internet. La dernière, nommée « Optimum Routing », permet de choisir le chemin optimal, tout en étant la plus « propre » techniquement. 4.7.1 - Route par défaut statique (Static Default Route) La première méthode (la plus ancienne) consiste à une utiliser une extension de la commande « ip route » pour définir une route par défaut dans les VRF des routeurs PE, au moyen de la commande :
où PE-Internet est l’adresse globale du PE fournissant l’accès à Internet. Pour que le retour des paquets puisse être effectif vers le CE concerné, les routes VPN du CE doivent être déclarées globalement sur son PE de rattachement, et propagées au PE-Internet (IGP, iBGP, etc.). Par exemple, si un réseau 120.2.1.0/24 est connecté à un CE 120.1.1.1 appartenant au VPN « GREEN », le PE doit contenir les deux lignes suivantes :
Dans cet exemple, on a supposé que PE-Internet a pour adresse 120.1.1.2. Lorsque le PE recevra un paquet sur la VRF « GREEN », il effectuera un lookup dans la table de routage de cette VRF. Si aucune entrée n’est trouvée pour la destination IP, la route par défaut injectée au moyen de la commande « ip route » sera utilisée. Il est à noter que la table de routage globale du routeur est examinée pour atteindre PEInternet, et que les paquets traversent le backbone MPLS sans label VPN (seul le label de PE-Internet est accolé par le PE). Naturellement, ce type de routage n’est pas optimal, car si plusieurs PE disposent d’un accès Internet, seul le PE déclaré dans la route par défaut sera employé. De plus, cette méthode « casse » la notion de VRF avec la déclaration des routes VPN de manière globale sur les PE. Enfin, tous les PE doivent être configurés de cette manière, avec pour chacun la route par défaut et la mise en place dans la table de routage globale des routes VPN. 4.7.2 - Route par défaut dynamique (Dynamic Default Route) Une solution plus propre techniquement pour propager une route par défaut à tous les PE est d’utiliser la notion de VPN avec une topologie « Hub and Spoke ». Sur le routeur PE-Internet, une VRF particulière est configurée pour annoncer la route par défaut (apprise par un autre routeur, généralement avec eBGP). Si l’on souhaite propager manuellement cette route à un certains sites de différents VPN, il suffit d’employer la politique d’attribution des RT du schéma ci-dessous :  Chacun des sites clients reçoit la route par défaut provenant du site vert central grâce au RT 500:1001. Pour permettre le retour des paquets, chaque site doit exporter vers le site central ses propres routes (RT 500:1000). Chaque PE doit donc être configuré avec ces RT pour permettre la propagation de la route par défaut. Il est ainsi possible de ne propager la route par défaut qu’à certains sites d’un même VPN (les VRF de ces sites devant traiter les RT du VPN « Internet »), en configurant les PE adéquats et en ne changeant rien sur les autres :  Si l’on souhaite propager automatiquement la route par défaut à tous les sites d’un même VPN sans avoir à modifier la configuration des différents PE, il suffit d’importer et d’exporter le RT de ce VPN dans la VRF « Internet ». De cette manière, aucun changement dans la configuration des PE rattachés à ces sites n’est nécessaire. Internet 
4.7.3 - Routage optimal (Optimum Routing) La méthode dite « Optimum Routing » permet aux sites clients d’accéder à Internet, tout en sélectionnant le meilleur chemin si plusieurs PE sont passerelles vers l’extérieur. Le concept clé de l’Optimum Routing est de propager l’ensemble des routes Internet sur tous les PE du backbone MPLS. Naturellement, il n’est pas possible de propager ces routes dans chaque VPN : en supposant que l’on compte 100000 routes Internet ; propager ces routes dans 100 VPN différents (soit 10 millions de routes au total) n’est évidemment pas réalisable. Les routes Internet sont donc échangées entre PE grâce au protocole BGP standard (sessions iBGP entre les PE), et ce sont les tables de routage globales des PE qui contiennent ces routes. Pour permettre aux sites d’accéder à l’extérieur, les CE sont reliés de deux manières au backbone de l’opérateur : la première connexion permet l’accès aux routes Internet globales, tandis que la seconde permet l’accès aux autres sites du VPN, avec l’utilisation d’une VRF.  La mise en place d’une double liaison avec le CE (une avec VRF, l’autre sans) peut être réalisée au moyen de deux sous-interfaces (2 VLAN sur trunk Ethernet, 2 DLCI sur Frame Relay, 2 VC sur ATM, etc.) ou avec un tunnel GRE. Exemple de configuration avec une interface Frame-Relay :
Exemple de configuration avec une interface Ethernet en mode trunk :
Sur le CE, deux approches sont possibles pour accéder à la fois aux autres sites du VPN et à Internet. La première, la plus classique, consiste à sélectionner l’interface de sortie grâce au Policy Routing, au moyen des commandes route-map. La seconde consiste à employer la notion de VRF sur le routeur CE lui-même, mais sans utilisation de MP-BGP. Les VRF peuvent en effet être mises en place sur un routeur, indépendamment de MPLS/VPN. L’exemple suivant montre comment implémenter le Policy Routing sur un CE (en reprenant l’exemple du PE ci-dessus, connecté au CE par une interface FastEthernet) avec translation d’adresse (NAT) :
Pour cet exemple, il est supposé que le VPN client emploie le réseau 10.0.0.0/8 dans son plan d’adressage IP interne. Le route-map « ACCESS » permet de rediriger le trafic destiné à Internet (c’est-à-dire n’étant pas dirigé vers une adresse en 10.x.y.z, voir liste d’accès 100) sur l’interface « Internet », FastEthernet1/0.1. Pour pouvoir communiquer avec l’extérieur, une translation des adresses source en 10.0.0.0/8 (voir liste d’accès 101) du site doit également avoir lieu. Cette action est réalisée avec les commandes « ip nat […] ». Remarque: en cas d’utilisation des VRF sur un routeur CE, il est important de garder à l’esprit que certaines fonctions (par exemple NAT, HSRP, etc.) peuvent ne pas être supportées avec des interfaces VRF. 4.8 - Signalisation Inter-AS (MP-eBGP) A partir de la version 12.1(5)T, il devient possible de créer relier des sites d’un 3ême VPN à travers des Autonomous Systems différents. En effet, l’annonce des routes VPNv4 inter-AS est fonctionnelle, ainsi que la transmission des paquets labellisés entre plusieurs backbones. |
Accueil
