MPLS

Infos générales Mpls

MPLS = multi protocol label switching.

Un label est ajouté à chaque paquet en transit. Les décisions de routage/switching se font en fonction de la valeur du label. Pour qu'un paquet aille d'un point à un autre, il faut que des labels soient distribués le long du chemin. Dès que c'est fait, un circuit (LSP = label switched path) est mis en place, via lequel les paquets peuvent transiter. MPLS est dit "multi protocol" parce que les paquets auxquels sont ajoutés les labels ne sont pas forcément des paquets IP.

C'est très semblable à ce qui se passe avec ATM, où le label s'appelle un "VCI" (virtual circuit identifier). En fait, après l'échec cuisant d'ATM (même Renater a abandonné ATM sur son backbone), MPLS a quelquesatouts psychologiques : - les opérateurs télécom, qui avaient poussé ATM, en vain, se sentent à l'aise avec MPLS. Internet leur semble plus fréquentable avec une signalisation de type ATM. - les acteurs IP perdent leurs complexes par rapport à la signalisation évoluée que permet ATM. Ils éprouvent une certaine satisfaction à voir les protocoles traditionnels IP (OSPF, BGP) servir à la signalisation d'un réseau MPLS. On peut néanmoins s'attendre à ce que ce soit le plus souvent des opérateurs téléphoniques qui implémentent MPLS.

MPLS/BGP VPN est une application MPLS. Ce n'est pas la seule, et c'est la mons utile. Elle permet de "vendre" MPLS.

Quelques idées reçues sur les VPN MPLS/BGP :

- MPLS permet de construire des VPN sécurisés. C'est FAUX. MPLS ne crypte pas le trafic, MPLS n'authentifie pas le trafic. Le trafic MPLS peut être "sniffé" sur tout le trajet entre deux points d'un VPN. Pour sécuriser du trafic MPLS, il faut le crypter avec une solution... IPSEC! Les partisans de VPN MPLS/BGP vous diront que la sécurité de leur solution est équivalente à la sécurité d'un réseau Frame relay ou ATM. Le probléme c'est que la sécurité d'un réseau Frame Relay ou ATM est *nulle*. Seuls des paquets cryptés et authentifiés permetent de sécuriser un VPN. Et crypter et authentifier, c'est la raison d'être d'IPSEC.

- MPLS offre des garanties de QOS. C'est FAUX. MPLS n'a rien à voir avec la QOS, pas plus qu'avec la sécurité. Il faut comprendre qu'il y a deux outils nécessaires pour ofrir une QOS particulière à un certain type de trafic : 1) il faut identifier le trafic auquel une QOS doit être appliquée. 2) il faut un mécanisme sur le routeur pour appliquer la QOS au trafic identifié. Il peut par exemple y avoir plusieurs queues sur une interface, avec des priorités différentes pour chaque queue etc.

Sur ces deux points, MPLS n'apporte *aucune* innovation. Pour le point 2), MPLS utilise les mêmes procédés que pour le trafic IP (WRED sur Cisco, quatre queues différentes sur Juniper etc. Sur nos routeurs Unix nous utilisons HFSC).

Pour le point 1), MPLS a quelques ennuis. Quand un paquet IP (sans MPLS) arrive sur un routeur, l'identification du type de QOS à appliquer est immédiat : on regarde l'IP source, le port, le protocole, le champ TOS (type of service) etc...

Pour MPLS, le routeur ne voit qu'un label. Diable, quelle QOS appliquer quand on n'a comme information qu'un label ? Deux solutions : - on ajoute 3 bits au label. Le label doit être court (idéalement, le label est juste un entier quelconque, ajouter des champs au label est un hack), alors trois bits seulement. Ces trois bits s'appellent "Exp" pour "Experimental" (sic). Ces trois bits ont été ajoutés spécifiquement pour la QOS. Puis on mappe les huit bits TOS IP vers ce champ. On perd de l'information évidemment

-) , mais qu'à cela ne tienne, on peut dire maintenant MPLS = QOS  :-)

- autre solution : comme le label n'encode pas de QOS par défaut, on va créer par signalisation des labels qui auront une signification spéciale de QOS. Autrement dit MPLS devient la solution pour un problème qu'il a créé : on liquide les informations véhiculées par IP (TOS etc) en créant un label opaque. Puis pour retrouver ces informations, on crée des labels supplémentaires.

Maintenant il y a quelques inconvénients (outre la sécurité) que les opérateurs MPLS oublient de signaler à leurs clients :

- "MPLS/BGP VPN" n'est pas standardisé auprès de l'IETF (MPLS est standardisé néanmoins). IPSEC est standardisé. - MPLS est une technologie très compliquée. MPLS est une technologie immature. Dans le cas des VPN, MPLS n'apporte *rien*. Sauf peut-être des ennuis. 40 % des interruptions sur un réseau sont dues à des erreurs humaines. Avec une technologie immature et complexe comme MPLS, les chances d'erreurs sont multipliées. Dans le cas d'un VPN sécurisé MPLS, il faut débugguer quatre technologies (IP, IPSEC, BGP et MPLS). C'est deux de trop.

- la solution BGP/MPLS injecte dans certains routeurs de l'opérateur les routes (privées) des clients, via des sessions BGP. Cette solution n'est pas scalable, et peut devenir catastrophique. Ce n'est pas moi qui le dis, mais Steven M. Bellovin (http://www.research.att.com/~smb/) ou Randy Bush (http://www.psg.com/~randy/). Voir l'article http://www.nwfusion.com/news/2001 /0806mpls.html (que j'ai trouvé avec Google, vous n'aurez pas de mal à trouver d'autres articles dans la même veine). Les routeurs consomment beaucoup plus de ressources pour traiter ces routes. Certaines mauvaises langues disent que MPLS est la technologie qui va servir à Cisco et Juniper pour vendre leurs routeurs haut de gamme... Cisco et Juniper sont à fond dans MPLS. Si ce sont des consultants Cisco ou Juniper qui prennent les décisions chez un opérateur, alors MPLS sera implémenté chez cet opérateur.

- Les VPN BGP/MPLS ne sont pas extensibles à d'autres ISP, ou bien difficilement. Pour que la solution soit extensible à d'autres ISP (par exemple, le client a un site qui est dans un pays non couvert par son opérateur MPLS), il faut un accord entre les ISP concernés. L'immense majorité des ISP refuseront d'accepter des routes privées via un peering BGP/VPN. Même si l'ISP accepte, il faut mettre en place une configuration BGP non standard. Avec IPSEC, aucune autorisation nécessaire, aucune configuration chez le deuxième ISP...

A quoi sert MPLS alors ?

Outre BGP/MPLS VPN, il y a d'autres applications :

- "traffic engineering". MPLS permet d'optimiser l'allocation des ressources en bande passante sur un réseau. C'est très utile sur les réseaux congestionnés. Sur un réseau surprovisionné, c'est inutile.

- "fast reroute". Permet de contourner un lien défaillant rapidement (quelques millisecondes, contre quelques secondes avec un protocole de routage traditionnel). Très utile dans un réseau instable. NB : les protocoles traditionnels implémenteront bientôt des timers très courts, ce qui permettra d'améliorer la convergence (déjà fait pour IS-IS, disponible pour OSPF l'année prochaine).

- transport de protocoles autres qu'IP. On peut transporter du Frame Relay, des VLAN dans un backbone MPLS. Pour un client IP, fonctionnalité inutile. Pour les opérateurs de réseaux historiques Frame Relay ou ATM, permet de migrer vers un réseau IP en douceur. Beaucoup d'opérateurs se sont trompés de technologie avec ATM et Frame Realy, MPLS offre une voie de sortie honorable.

- d'autres types d'applications apparaîtront. Dès qu'une fonctionalité aura besoin de signalisation, MPLS sera utile (tout est envisageable malheureusment : livrer le courrier avec MPLS, livrer des pizzas avec MPLS etc).

MPLS est une technologie brillante. Mais ce n'est pas une solution miracle. En particulier, MPLS N'APPORTE PAS DE SOLUTION AUX PROBLEMES DE SECURITE OU DE QOS. Donc laissez tomber les complexes  :-) Ce n'est pas parce que personne ou presque ne comprend MPLS que MPLS est la réponse à tous les maux de l'humanité. Le client veut un service : un VPN sécurisé. IPSEC répond à l'exigence de service. Pas MPLS. Peut-être que MPLS, c'est l'avenir radieux technologique. Oui. Comme ATMen un autre temps  :-)

Les différentes configurations possibles

VPN seul

Le client a plusieurs sites à relier entre eux, pas d'accès Internet.

VPN seul et accès Internet par une liaison dédiée

Le client à plusieurs sites à relier entre eux. Le client utilise une liaison dédiée pour son accès Internet. Le NAT se fera sur l'équipement client avant de sortir sur le lien Internet.

VPN et accès Internet sur le même lien, NAT chez le client

Le client NAT les paquets vers Internet, un route par défaut dans la VRF du client pointera vers la table de routage globale.

VPN et accès Internet sur le même lien, NAT mutualisé chez Claranet

Les paquets vers Internet sont amenés vers un routeur mutualisé qui sera en charge du NAT.

Il devrait être possible de proposer du firewall (non testé), mais il faut que le firewall puisse distinguer les différentes VRF.

VPN et accès Internet sur le même lien, NAT/FW dédié chez Claranet

Les paquets vers Internet sont amenés vers un firewall dédié qui sera en charge du NAT et du firewall.

Allocation des "route targets" et des "route distinguisher" (SRI)

Les "route distinguisher" (RD) permettent de distinguer les routes identiques de différents VPN (par exemple, deux VPN utiliseront 10.0.0.0/24).

Il existe plusieurs possibilités pour allouer ces RD (on peut par exemple sur un Juniper laisser JunOS choisir le RD de telle sorte qu'il soit unique).

Pour nos configurations, on aura pour chaque VRF (mêmes routes dans la table de routage) le même RD. Autrement dit, routes identiques dans une VRF = nom unique de VRF = RD unique. Le RD sera alloué séquentiellement, au fur et à mesure des mises en service, en mettant à jour la MPLS/BGP VPN map.

Ensuite on doit configurer les "route targets" (RT). Les RT définissent la politique de routage. Les routes exportées par un site seront marquées avec un attribut RT, et ces routes seront importées seulement par les sites configurés pour importer les routes marquées avec cet attribut RT.

Par exemple, prenons le cas d'un client CUST qui achète un VPN, avec trois sites, terminés sur des routeurs différents. Les sites 1, 2 et 3 peuvent communiquer entre eux. Le site 1 est configuré avec le subnet 10.1.0.0/24, le site 2 avec le subnet 10.2.0.0/24, le site 3 avec le subnet 10.3.0.0/24. Le site 3 doit avoir un accès Internet. Le NAT se fera sur un routeur Claranet, sur le site 4.

• les site 1 et 2 auront comme routes 10.1.0.0/24, 10.2.0.0/24 et 10.3.0.0/24.
• le site 3 aura comme routes 10.1.0.0/24, 10.2.0.0/24 et 10.3.0.0/24 et 0.0.0.0/0.
• le site 4 aura comme routes 10.3.0.0/24 et 0.0.0.0/0.

Les sites 1 et 2 ont les mêmes routes. On choisit un nom de VRF unique (CUST), et un RD unique (le prochain disponible comme indiqué dans la MPLS/BGP VPN map). De même, on choisit pour le site 3 le nom de VRF CUST-NET et un RD unique. De même, on choisit pour le site 4 le nom de VRF CUST-NET-HUB et un RD unique.

Ensuite on définit les RT. Les RT doivent être uniques.

Les sites 1 et 2 exportent le RT 300 (routes des sites du client CUST sans accès VPN) et importent les RT 300 et 301 (routes des sites du client CUST sans accès VPN - RT 300, et routes des sites du client CUST avec accès VPN - RT 301). Le site 3 exporte le RT 301 (routes des sites du client CUST avec accès VPN). Le site 3 importe les RT 300, 301 et 500 (routes des sites du client CUST sans accès VPN - RT 300, routes des sites du client CUST avec accès VPN - RT 301, et route par défaut - RT500. Le site 4 importe le RT 301 (routes des sites avec accès VPN). Le site 4 exporte le RT 500 (route par défaut).

Pour chaque service qu'on peut proposer à un site du VPN (aujourd'hui NAT, plus tard monitoring), on exportera le RT correspondant à ce service. Configuration SRI sur un BAS

Donner un nom à la VRF, choisir le RD et les RT (voir plus haut). Mettre à jour la MPLS/BGP VPN map.

Dans le cas d'un VPN "full mesh" sans accès Internet, la configuration sur le BAS sera (voir plus haut comment choisir RD_ID et RT_ID) :

ip vrf NOM-CLIENT
 rd 8975:RD_ID
 route-target export 8975:RT_ID
 route-target import 8975:RT_ID
 maximum routes 10 80

Configurer la redistribution des routes via BGP (attention) :

router bgp 8975
 address-family ipv4 vrf NOM-CLIENT
 redistribute static
 no auto-summary
 no synchronization
 exit-address-family

Configuration TIG

Aller sur l'interface de configuration RADIUS (http://reporting/radius/) Dans notre exemple, le subnet (privé) d'un des sites client est 192.168.0.0/24.

Dans le cas d'un VPN avec de nombreux sites, créer un fichier de configuration spécialement pour ce VPN. Pour chaque site, demander au SRI le nom de la VRF à configurer (ici NOM-CLIENT). Attention, le nom de la VRF ne sera pas forcément le même pour chaque site du client, voir avec le SRI.

mpls1@dsl1.ipadsl Huntgroup-Name="nas_adsl", Password="claran3t", Auth-Type = Local
       Cisco-AVPair= "lcp:interface-config#1=no ip policy route-map clear-df",
       Cisco-AVPair= "lcp:interface-config#2=ip vrf forwarding NOM-CLIENT",
       Cisco-AVPair= "lcp:interface-config#3=ip unnumbered Loopback0",
       Framed-Protocol = PPP,
       Framed-Route="192.168.0.0/24",
       Service-Type = Framed-User

Références

• RFC 2547bis

Inter-AS MPLS VPN

• Hierarchical and Recursive Applications
• MPLS VPN Interautonomous System Support (option b)
• MPLS VPN Inter-AS IPv4 BGP Label Distribution (option c)