Aller au contenu
Mathis Vila

projets but2 sae4rom01-mpls-l3vpn

BUT2 · SAE4.ROM.01 Terminé

Telecom RT : architecture MPLS L3VPN avec évasion Internet centralisée

J'ai conçu et simulé sous GNS3 le cœur MPLS d'un opérateur fictif, avec des VPN de niveau 3 étanches pour trois clients et une évasion Internet centralisée.

Année
BUT2 · S4
Module
SAE4.ROM.01
Type
SAE
Date
16/04/2026
Équipe
seul
Mon rôle
Auteur unique : conception, simulation sous GNS3 et validation de l'architecture

Contexte et objectif

Le rapport se place chez l'opérateur Telecom RT, qui doit raccorder de nouveaux sites distants pour trois clients à travers un cœur de réseau partagé, en garantissant l'étanchéité des flux. Chaque client utilise un protocole de routage différent (OSPF, EIGRP, RIPv2) et les nouveaux sites n'ont aucun accès Internet local. L'objectif est de concevoir, simuler et valider une architecture centralisée et évolutive.

Ce que j'ai réalisé

  • J'ai maquetté l'infrastructure sous GNS3 avec des images Cisco IOS C7200 : trois routeurs P, deux routeurs PE, un routeur d'évasion Internet (EI) et les routeurs clients (CE).
  • J'ai défini le plan d'adressage (liaisons en /30, Loopback en /32, réseaux clients simulés par des Loopback).
  • J'ai déployé OSPFv2 en aire 0, puis LDP sur le backbone.
  • J'ai configuré trois VRF clients sur les PE, avec Route Distinguisher et Route Targets.
  • J'ai établi les sessions iBGP MP-BGP (AS 974, famille VPNv4) entre les PE et l'EI.
  • J'ai mis en place le routage PE-CE de chaque client avec redistribution vers et depuis BGP.
  • J'ai créé sur l'EI une VRF INTERNET exportant la route par défaut et configuré un NAT avec surcharge vers le nuage GNS3.

Difficultés rencontrées et solutions

  • Hétérogénéité des protocoles de routage clients : redistribution de chaque protocole vers MP-BGP, et inversement, au sein de chaque VRF.
  • EIGRP ne peut pas traduire directement les métriques BGP : métriques spécifiées manuellement lors de la redistribution.

Résultats

  • Ping réussi entre les deux sites du client A.
  • Échec immédiat d'un ping du client A vers le client B, ce qui valide l'étanchéité entre VRF.
  • Capture de trame entre PE1 et P1 montrant le double étiquetage (label VPN et label de transport).
  • Table de traduction NAT de l'EI confirmant le masquage des adresses privées.
  • Conclusion du rapport : toutes les contraintes du cahier des charges sont respectées.

Ce que j'en retiens

L'association de MPLS, des VRF, de MP-BGP et du NAT répond aux contraintes d'étanchéité et de connectivité, et la maquette constitue une preuve de concept fonctionnelle. Le modèle centralisé a toutefois des limites (effet trombone, configuration manuelle de chaque équipement) : je recommande à moyen terme de superposer une solution SD-WAN au backbone MPLS.

Technologies

  • MPLS
  • LDP
  • OSPFv2
  • MP-BGP
  • VPNv4
  • VRF
  • Route Distinguisher
  • Route Target
  • EIGRP
  • RIPv2
  • NAT Overload (PAT)
  • GNS3
  • Cisco IOS C7200
  • SD-WAN