Rapport PFE Ikram

DEDICACES
"La vie n’est qu’un éclair, Et un jour de réussite est un jour très cher".
À ma chère mère
Votre prière et votre bénédiction m’ont été un grand secours pour mener à bien mes études. Que
Dieu te garde dans son vaste paradis.
À mon cher père

Celui qui s’est toujours sacrifié pour créer le climat affectueux et propice à la poursuite de mes
études. Je prie le bon Dieu de le bénir en espérant qu’il sera toujours fier de moi.
À ma chère sœur, à mes chers frères

Je vous remercie pour votre soutien moral et vos encouragements permanents. Que Dieu vous paye
pour tous vos bienfaits.
À mes amis et tous ceux que j’aime, tous ceux qui m’aiment
Je dédie ce travail
Ikram SLIMANI
ENIG Page i
REMERCIEMENTS
Mes remerciements les plus vifs à dieu le tout puissant qui ne m’a jamais privé de son soutien et
son soin divin.
Je ne trouve pas les mots pour exprimer ma gratitude envers monsieur Amir Mzoughia, pour son
encadrement durant la période du stage. Ses précieux conseils, son aide, ses capacités techniques et
ses compétences étaient mon grand support.
Je veux aussi, adresser mes remerciements à toute l’équipe « Support IT et DC » pour leur soutien,
appui et encouragement tout au long de mon stage.
Je tiens aussi à remercier madame Emna Ben Slimane pour ses conseils précieux et son support
qui m’ont aidées à surmonter beaucoup des difficultés. Je la remercie chaleureusement pour sa pédagogie,
sa disponibilité et son dévouement.
Mes remerciements vont aussi à tous les membres du jury pour avoir accepté de me prêter leur
attention et évaluer mon travail.
ENIG Page ii
TABLE DES MATIERES
LISTE DES FIGURES vii
LISTE DES ABREVIATIONS viii
INTRODUCTION GENERALE 1
1 Étude Préliminaire 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Présentation d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Organigramme d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Direction Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.4 Valeurs d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Réseau Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Réseau de Campus d’Ooredoo . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 État de l’art et Concepts clefs 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Etude de l’architecture 3 tiers d’Ooredoo . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 Architecture existante du réseau Data Center . . . . . . . . . . . . . . . . . 14
2.2.1.1 Couche d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1.2 Couche d’agrégation . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2.1.3 Couche de cœur . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1.4 Core d’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.2 Campus existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3 Protocoles utilisés dans le Data Center et les réseaux campus . . . . . . . . . 20
2.2.3.1 OSPF (Open Shortest Path First) . . . . . . . . . . . . . . . . . . 20
2.2.3.2 HSRP (Hot Standby Routing Protocol) . . . . . . . . . . . . . . . 20
ENIG Page iii

TABLE DES MATIERES
2.2.3.3 RSTP (Rapid Spanning Tree Protocol) . . . . . . . . . . . . . . . 20

2.2.3.4 Technologie VLAN . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.3.5 Technique vPC (Virtual Port Channels) . . . . . . . . . . . . . . 21
2.2.3.6 Technique EtherChannel . . . . . . . . . . . . . . . . . . . . . . 21
2.2.4 Architecture du réseau Backbone existant . . . . . . . . . . . . . . . . . . . 22
2.2.4.1 Réseau MPLS(Multi-Protocol Label Switching) . . . . . . . . . . 22
2.2.4.2 Composants principaux du réseau MPLS . . . . . . . . . . . . . . 22
2.2.5 Protocoles utilisés dans le Backbone . . . . . . . . . . . . . . . . . . . . . . 24
2.2.5.1 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.5.2 Layer 2 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.5.3 Layer 3 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5.4 MP-BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5.5 La technique VRF . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Migration vers l’architecture SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Concept du réseau SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2 Architecture SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.3 ACI(Application Centric Infrastructure) la solution SDN du datacenter . . . 29
2.3.3.1 Présentation de la solution ACI . . . . . . . . . . . . . . . . . . . 29
2.3.3.2 Protocoles ACI . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3.4 SD-Access la solution SDN du Campus . . . . . . . . . . . . . . . . . . . . 32
2.3.4.1 Principe de la solution SD-Access . . . . . . . . . . . . . . . . . 32
2.3.4.2 Composants de la solution SD-Access . . . . . . . . . . . . . . . 33
2.3.4.3 Campus Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3 Réalisations et Tests 36
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Environnement matériel et logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Environnements logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1 Architecture existante du réseau . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Configuration des équipements des Campus . . . . . . . . . . . . . . . . . 40
3.3.2.1 Création des Vlans . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.2.2 Configuration du RSTP . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.2.3 Configuration du routage inter vlan . . . . . . . . . . . . . . . . . 42
3.3.2.4 Configuration du HSRP . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2.5 Configuration de l’OSPF . . . . . . . . . . . . . . . . . . . . . . 43
ENIG Page iv
TABLE DES MATIERES
3.3.3 Configuration des équipements du Data Center . . . . . . . . . . . . . . . . 44

3.3.3.1 Configuration des Vlans . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3.2 Configuration HSRP . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.3.3 Configuration de vPC . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.3.4 Configuration de F5 BIG-IP LTM . . . . . . . . . . . . . . . . . . 48
3.3.4 Configuration des équipements du Backbone . . . . . . . . . . . . . . . . . 55
3.3.4.1 Configuration du protocole MPLS layer 3 VPN . . . . . . . . . . 55
3.3.4.2 Configuration des VRFs . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.4.3 Configuration du protocole MPLS Layer 2 VPN . . . . . . . . . . 59
3.4 Migration vers une architecture 2-tiers . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.4.1 Topologie adoptée pour l’architecture ACI pour les DC . . . . . . . . . . . . 64
3.4.2 Configuration de la topologie adoptée . . . . . . . . . . . . . . . . . . . . . 65
3.4.2.1 Configuration Underlay . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.2.2 Configuration Overlay . . . . . . . . . . . . . . . . . . . . . . . . 67
3.4.3 Simulation de l’architecture SD-Access pour les réseaux de campus . . . . . 69
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
CONCLUSION GENERALE 74
NETOGRAPHIE 75
ANNEXES 79
A.1 Fonctionnalités de l’APIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.2 Architecture existante du réseau de l’entreprise Ooredoo Tunisie . . . . . . . . . . . 79
A.3 Architectures logique du réseau data center Mghira, Campus DSC et Campus DT . . 80
ENIG Page v
LISTE DES FIGURES
1.1 Organigramme d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Architecture 3-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Conception Two-Tier Collapsed Core . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Architecture 2-tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Architecture du réseau DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Topologie du réseau pour une connexion Two-Armed . . . . . . . . . . . . . . . . . 17
2.3 Extrait de l’architecture réseau Ooredoo . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 BGP/MPLS VPN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Passage du réseau traditionnel (classique) vers le réseau SDN . . . . . . . . . . . . . 27
2.6 Les différents couches du SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.7 Composants matériels dans une structure ACI . . . . . . . . . . . . . . . . . . . . . 30
2.8 VTEP VXLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9 Principe de fonctionnement de LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Architecture simplifiée du réseau Ooredoo . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Architecture logique du Campus Lac . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Liste des Vlans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4 Activation du mode d’accès et attribution des vlans . . . . . . . . . . . . . . . . . . 41
3.5 Configuration d’un port trunk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Résultat de la commande Show Spannig-tree . . . . . . . . . . . . . . . . . . . . . . 42
3.7 Configuration du protocole HSRP . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.10 Table de routage de switch Core1Lac . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.11 Architecture logique de DC Charguia . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.12 Double sided vPC au niveau d’agrégation . . . . . . . . . . . . . . . . . . . . . . . 47
3.13 Double sided vPC au niveau d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.14 Architecture du réseau à tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.15 Configuration de l’interface management . . . . . . . . . . . . . . . . . . . . . . . 49
3.16 Création d’un VLAN interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.17 Création d’un VLAN externe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.18 Création d’un nouveau nœud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.19 Configuration d’un nouveau pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
ENIG Page vi
LISTE DES FIGURES
3.20 Création d’un Serveur Virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.21 Orientation vers Server1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.24 Architecture logique du Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.25 Configuration de routeur PE1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.26 Configuration du VRF ShopGabes . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.27 Configuration de l’interface F0/0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.28 Configuration du protocole BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.29 Configuration des routes statiques pour les instances VRF . . . . . . . . . . . . . . . 58
3.30 Table de routage bgp vpnv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.31 Topologie MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.32 Liaison L2VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.33 Configuration d’une classe pseudowire et du MPLS dynamique . . . . . . . . . . . . 60
3.34 Configuration de l’interface FastEthernet0/0 du PE1 . . . . . . . . . . . . . . . . . . 61
3.35 Configuration du routeur CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.36 Vérification des voisins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.37 Résultat de la commande show mpls Forwarding-table . . . . . . . . . . . . . . . . 62
3.38 Vérification du circuit virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.39 Attribution d’une adresse IP par le serveur DHCP . . . . . . . . . . . . . . . . . . . 63
3.40 Configuration d’une route par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.41 Configuration DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.42 Configuration de l’ospf sur le nouveau routeur . . . . . . . . . . . . . . . . . . . . . 63
3.43 Configuration du NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.44 Topologie à tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.45 NVE Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.46 Les VNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.47 Aperçu général du fonctionnement LISP . . . . . . . . . . . . . . . . . . . . . . . . 70
3.48 Topologie à configurer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.1 Architecture globale du réseau Ooredoo . . . . . . . . . . . . . . . . . . . . . . . . 80

A.2 Architecture logique du DC Mghira . . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.3 Architecture logique du réseau de campus DSC . . . . . . . . . . . . . . . . . . . . 81
A.4 Architecture logique du réseau de campus DT . . . . . . . . . . . . . . . . . . . . . 82
ENIG Page vii

LISTE DES ABREVIATIONS
ABR : Area Border Router ETR : Egress Tunnel Router
ACI :Application Centric Infrastructure EVPN : Ethernet Virtual Private Network
API :Application Programming Interface FAI : Fournisseur d’Accès Internet
APIC :Application Policy Infrastructure Controller FEX : Fabric Extender
AS : Autonomous System FHRP : First Hop Redundancy Protocols
ASBR : Autonomous System Boundary Router HDLC :High Level Data Link Control
ASR : Aggregation Services Routers HSRP : Hot Standby Routing Protocol
ATM : Asynchronous Transfer Mode I-BGP :Internal Border Gateway Protocol
BGP : Border Gateway Protocol IEEE :Institute of Electrical and Electronics

Engineers
BUM :Broadcast, Unknown-Unicast and Multicast IETF : Internet Engineering Task Force
CAN :Campus Area Network IGP :Interior Gateway Protocol
CE :Customer Edge IOS :Internetworking Operating System
CLI :Command Line Interface IP :Internet Protocol
CoS :Class of Service IPv4 : Internet Protocolversion 4
CPU :Central Processing Unit IPv6 : Internet Protocolversion 6
CTS :Cisco Trust Security ISE :Identity Service Engine
DC :Data Center IS-IS :Intermediate System- Intermediate

System
DNA :Digital Network Architecture IT :Information Technology
DNS :Domain Name System ITR :Ingress Tunnel Router
DSC : Direction Services Clients LACP :Link Agregation Control Protocol
DT : Direction Technique LAN :Local Area Network
EID : Endpoint Identifiers LDP : Label Distribution Protocol
ENIG Page viii

LER :Label Edge Routeur QoS : Quality of Service
LISP :Locator Identity Separator Protocol RA : Remote Access
LLDP :Local Link Discovery Protocol RD : Route Distinguisher
LSA :Link State Advertisement REST : Representational State Transfer
LSR :Label Switch Router RLOC : Routing Locators
LTM : Local Traffic Manager RP : Rendezvous-Point
L2VPN : Layer 2Virtual Private Network RR : Route Reflector
L3VPN : Layer 3Virtual Private Network RSTP : Rapid Spanning Tree Protocol
MAC : Media Access Control RT : Route Target
MAN : Metropolitan Area Network SaaS : Software as a service
MP-BGP : Multi-Protocol Border Gateway Protocol SD-Access : Software-Defined Access
MPLS : Multiprotocol Label Switching SDN : Software Defined Networking
MR : Map Resolver SGT : Scalable Group Tag
MS : Map Server SI : Système d’Information
MSC : Mobile Switching Center SPB :Shortest Path Bridging
MTU :Maximum Transmission Unit STP : Spanning Tree Protocol
NSSA : Not So Stubby Area SV : Serveur Virtuel
NVE : Network Virtualization Endpoint SVI : Switch Virtual Interface
NX-OS : Nexus Operating System TCO : Total Cost of Ownership
OSPF : Open Shortest Path First TE : Traffic Engineering
OTV : Overlay Transport Virtualization TMOS : Traffic Management Operation System
P : Provider ToR : Top of Rack
PAGP : Port Agregation Protocol TRILL :Transpa- Rent Interconnection of Lots

of Links
PE : Provider Edge TTL : Time To Live
PETR : Proxy Egress Tunnel Router UDP : User Datagram Protocol
PIM : Protocol Independent Multicast VLAN : Virtual Local Area Network
PITR : Proxy Ingress Tunnel Router VM : Virtual Machine
PPP : Point-to-Point Protocol VNI : VXLAN Network Identifier
pxGrid : Platform Exchange Grid vPC : virtual Port Channels
ENIG Page ix
VPN : Virtual Private Network VTEP : VXLAN Tunnel End Points
VRF : Virtual Routing and Forwarding WAN : Wide Area Network
ENIG Page x
INTRODUCTION GÉNÉRALE
De nos jours, la gestion des architectures réseaux traditionnelles au sein des entreprises est devenue
de plus en plus une problématique pour les opérateurs et les administrateurs réseaux. En effet, il
est admis que les architectures IP classiques sont d’une part complexe à gérer à cause de la nature
distribuée des protocoles réseaux et d’autre part difficile à évoluer à cause du fort couplage entre le
plan de contrôle et le plan de données des équipements existants.
Dans les grands datacenters traditionnels, le réseau est généralement composé d’une structure à
trois niveaux qui était la conception généralement la plus recommandée.
En outre, vu le progrès technologique et l’évolution des nouvelles techniques d’information, le

transfert des applications dans le Cloud nécessite une connectivité plus rapide et plus fiable. En plus
les collaborateurs étant de plus en plus mobiles, ils doivent pouvoir compter sur des performances
optimales, partout où ils se trouvent. Ce type d’environnement est difficile à gérer pour les entreprises,
mais possible d’y parvenir en toute confiance à l’aide du SDN (Software Defined Networking).
C’est dans ce cadre que s’inscrit le présent projet intitulé « Refonte et recréation du réseau
entreprise et data center » au sein de l’entreprise Ooredoo Tunisie.Ce projet consiste à faire une
simulation et recréation d’une architecture typique d’un fournisseur de service internet avant de passer
à une architecture cible 2-tiers de réseau Edge entreprise et data center basé SDN qui permettait
d’accroître l’agilité et la fiabilité du réseau en tenant compte de tous les changements nécessaires.
Cette implémentation nous a permis de maîtriser l’architecture existante et mieux comprendre les
prérequis de la migration souhaitée.
En effet, le présent rapport reflète notre travail réalisé durant ce projet. Il s’articule autour de trois
chapitres.
Le premier chapitre « Etude préliminaire » sera consacré à la présentation de l’organisme d’accueil

et l’analyse de l’existant en dégageant les lacunes et en proposant les solutions adéquates. Le second
ENIG Page 1
INTRODUCTION GENERALE
chapitre « Étude Préalable et Concepts clefs » servira à expliquer les concepts clés de notre projet.
Le troisième chapitre « Réalisations et tests » expliquera les différentes phases de la réalisation de
notre projet ainsi que les tests effectués en termes de preuves de concept appuyés par un ensemble de
captures d’écran de nos configurations et nos expérimentations.
Finalement, nous clôturons par une conclusion générale sur tout le travail élaboré et quelques
perspectives envisagées pour étendre notre travail.
ENIG Page 2
Chapitre
1
Étude Préliminaire
Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . 4
1.2.1 Présentation d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Organigramme d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . 4
1.2.3 Direction Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.4 Valeurs d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Réseau Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Réseau de Campus d’Ooredoo . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ENIG Page 3
CHAPITRE 1. ÉTUDE PRÉLIMINAIRE
1.1 Introduction
Ce chapitre a pour objectif de présenter le cadre général du projet. Pour ce faire, nous présenterons
dans une première section l’organisme d’accueil Ooredoo, ses valeurs, sa structure et la hiérarchie de
la société ainsi que l’équipe « Support IT Data Center » où notre projet a été effectué. Dans une
deuxième section, une étude préalable du projet sera établie en analysant et en critiquant l’existant.
La dernière section sera consacrée à la présentation de la solution ainsi que ses objectifs.
1.2 Présentation de l’organisme d’accueil
Dans le cadre de notre formation d’ingénieur en Génie des Communications et des Réseaux à
l’Ecole Nationale d’Ingénieurs de Gabès, nous avons eu l’occasion d’effectuer notre projet de fin
d’études au sein de la direction technique d’Ooredoo Tunisie.
1.2.1 Présentation d’Ooredoo Tunisie
En mai 2002, la deuxième licence Tunisienne de téléphonie mobile a été attribuée à Orascom
Telecom Tunisie. Cette licence, qui a coûté 454 millions de dollars, a marqué la naissance de Tunisiana,
le premier opérateur de télécommunications privé en Tunisie, avec un capital de 359,172 millions de
dinars. Le 26 juillet 2012, le gouvernement Tunisien annonce qu’il compte céder sa part de 25 % du
capital [1]. En 2014, Tunisiana change de nom et devient Ooredoo Tunisie [2].
1.2.2 Organigramme d’Ooredoo Tunisie
La Figure 1.1 présente l’organigramme d’Ooredoo Tunisie qui est composé de sept directions.
Notre stage a été réalisé au sein de la direction technique qui est répartie en 4 secteurs : Systèmes
informatiques, Projet technique, Radio et Opération et maintenance.
ENIG Page 4
F IGURE 1.1: Organigramme d’Ooredoo Tunisie
1.2.3 Direction Technique
La direction technique est en charge de toutes les infrastructures du réseau et se doit d’assurer
leur maintenance. Elle assure quatre fonctions importantes : la conception de nouvelles infrastructures
(software et/ou hardware), le déploiement de ces dernières, leur maintenance et enfin leur optimisation.
Tout ceci est réalisé sous contraintes topographiques et budgétaires.
1.2.4 Valeurs d’Ooredoo Tunisie
Pour atteindre ces objectifs, Ooredoo se base sur quatre valeurs orientant toutes leurs actions et
accompagne la totalité de leurs engagements : Orientation client, Professionnalisme, Transparence et
Innovation.
• Orientation client : Ooredoo a toujours placé la satisfaction de ses clients au centre de ses
préoccupations. Le client est sa raison d’être. Ce simple constat est le point de départ de l’ensemble
de leurs démarches.
• Professionnalisme : La mise en place des processus écrits leur permet de mesurer, d’analyser,
d’évaluer leurs méthodes de travail afin de les améliorer. Son professionnalisme s’inscrit aussi à
ENIG Page 5
travers sa politique de recrutement, la gestion des carrières de ses collaborateurs, les formations
dont ils bénéficient mais surtout la reconnaissance de leurs résultats à travers l’atteinte d’objectifs
prédéfinis.
• Transparence : Ses relations avec ses clients, ses collaborateurs, ses fournisseurs évoluent
dans un climat de transparence. En interne, ils ont mis en place des règles équitables, basées sur
des carrières impartiales, afin de refléter davantage leur volonté. En externe, la mise en place de
procédures d’achat et de sélection des fournisseurs transparents, ainsi qu’une égalité de traitement
des clients, sont la marque d’un respect nécessaire dans tout rapport.
• Innovation : L’arrivée d’Ooredoo en tant qu’opérateur privé a fortement démocratisé le marché

Tunisien de la téléphonie mobile. En lançant des produits innovants, simples et de qualité, à des prix
accessibles, répond ainsi à sa volonté d’être présente dans le monde des nouvelles technologies en
tant qu’acteur essentiel.
1.3 Présentation du projet
L’architecture adoptée au sein de l’entreprise Ooredoo est celle de 3 tiers. Ainsi, on distingue
les Data Center (DC), les réseaux de campus et le réseau cœur (Backbone). Vu les bénéfices de
l’architecture de 2 tiers par rapport à celle de 3 tiers, Ooredoo désire migrer son réseau de l’architecture
à 3 couches vers celle à 2 couches. C’est dans ce contexte que s’inscrit notre projet.
Dans cette section, nous décrivons le réseau DC en architecture 3 tiers et celui de campus , ensuite,
nous exposons la problématique.
1.3.1 Réseau Data Center
Un DC est une infrastructure physique et technique centralisant différents équipements informatiques,

serveurs, systèmes de stockage des données, clusters de calcul et équipements réseau... Ces derniers
assurent la distribution électrique, le refroidissement des équipements informatiques, la sécurité et la
sûreté, afin de fournir un service informatique à une disponibilité donnée.
Notre organisme d’accueil dispose des datacenters traditionnels. En fait, le réseau DC correspondant
est généralement composé d’une structure à trois niveaux décrite par la Figure 1.2.
ENIG Page 6
F IGURE 1.2: Architecture 3-tiers
Ce modèle contient les trois couches suivantes :
• Couche d’accès : c’est la couche le plus basse permettant l’accès au réseau du datacenter.
Généralement, cette couche est composée par des commutateurs d’accès qui sont physiquement
connectés aux serveurs.
• Couche d’agrégation : parfois appelée couche de distribution, les commutateurs d’accès se

connectent aux commutateurs d’agrégation de façon redondante. Ces derniers sont eux-mêmes connectés
à la couche de cœur.
• Couche de cœur : Les commutateurs de cette couche fournit un réseau de routage flexible entre
les différentes sections du datacenter. Le but principal de cette couche est d’assurer la connectivité
avec les éléments externes au datacenter comme la connexion avec d’autres datacenters, la connexion
avec Internet ou la liaison vers des services externes au SI (Système d’informations) d’entreprise
(services cloud, applications Software as a service. . . ).[3]
1.3.2 Réseau de Campus d’Ooredoo
Un réseau de campus CAN (Campus Area Network), dit aussi réseau d’entreprises consiste en
l’interconnexion des réseaux LAN (Local Area Network) dans une zone géographique limitée. Les
équipements de mise en réseau (commutateurs , routeurs ) et les supports de transmission sont presque
entièrement détenus par le propriétaire du campus : une entreprise, une université, un gouvernement,
ENIG Page 7
etc. Ce type du réseau est plus grand qu’un réseau local mais plus petit qu’un réseau MAN (Metropolitan
Area Network) ou un réseau WAN (Wide Area Network).
La conception de réseau varie en fonction de la taille et des exigences des organisations. Il n’y
a pas de règles absolues sur la façon dont un réseau de campus est physiquement construit. S’il
est vrai que de nombreux réseaux de campus sont construits à l’aide de trois niveaux physiques de
commutateurs, ce n’est pas une exigence stricte. Dans un campus plus petit, le réseau peut avoir deux
niveaux de commutateurs dans lesquels les éléments de cœur et de distribution sont combinés en un
seul commutateur physique. Ceci est appelé une conception collapsed core.
Cependant, de nombreux réseaux de petites entreprises ne se développent pas beaucoup au fil du

temps. Par conséquent, une conception hiérarchique à deux niveaux, où les couches de cœur et de
distribution sont regroupées en une seule couche, est souvent plus pratique. Un « cœur réduit » est
lorsque les fonctions de la couche de distribution et de la couche centrale sont implémentées par un
seul équipement. La principale motivation de la conception du cœur réduit est de réduire le coût du
réseau, tout en conservant la plupart des avantages du modèle hiérarchique à trois niveaux.[4]
L’exemple de la Figure 1.3 a regroupé les fonctionnalités de la couche de distribution et la couche

cœur en dispositifs de commutation multicouches.
F IGURE 1.3: Conception Two-Tier Collapsed Core
ENIG Page 8
1.3.3 Problématique
Aujourd’hui, avec l’utilisation des nouvelles technologies émergentes comme l’hyper- convergence
et le Big Data, on constate la naissance d’un nouveau type de trafic. Ce dernier reste principalement
à l’intérieur du DC circulant entre les différents serveurs pour nourrir des applications différentes. Ce
type de trafic est de type Est/Ouest. Ces solutions ont complètement changé notre manière d’interagir
avec les données.
Le besoin aujourd’hui a complètement changé et l’architecture 3 tiers ne répond pas tellement

aux exigences. Nous pouvons mieux comprendre les considérations relatives aux réseaux de centres
de données modernes en comparant les conceptions de réseaux à 3 niveaux et la manière dont elles
peuvent répondre aux besoins des entreprises d’aujourd’hui.
Le modèle des réseaux des datacenters à trois niveaux était la conception généralement la plus
recommandée. Ils fonctionnaient très bien lorsque la majorité du trafic se déplaçait du nord au sud
ou vice versa. Un paquet circule vers la couche Core, est acheminé vers le bon commutateur de
distribution, puis transmis au commutateur d’accès où le serveur était connecté ; se déplaçant sur
seulement 3 sauts physiques, ce qui limite la latence ajoutée par flux de paquets.
Les nouvelles infrastructures définies par logiciel nécessitent des changements dans l’architecture
du réseau traditionnelle exigeant une augmentation des flux de trafic est-ouest. Les principaux concepts
définis par logiciel sont la virtualisation et l’automatisation.
• La virtualisation permettant d’avoir plusieurs contextes logiques au sein de la même infrastructure

physique.
• L’automatisation dont le but est de faciliter et automatiser les tâches répétitives à travers des
solutions comme les scripts et les Workflows.
Ces applications entraînent également une utilisation accrue de la bande passante qui est difficile
à étendre à travers plusieurs périphériques réseau en couches dans l’architecture à trois niveaux. Cela
conduit à ce que les principaux périphériques réseau soient des liaisons haut débit très coûteuses.
Donc le problème avec cette conception pour le datacenter moderne est la grande quantité du
trafic intra-DC ajoutant une latence significative par flux ainsi que davantage de possibilités de goulots
d’étranglement, de dépassements de tampon et de paquets perdus.[5]
ENIG Page 9
1.4 Objectifs du projet
Afin d’améliorer les performances du réseau d’Ooredoo, plus précisément en termes de débit et de
la latence, le recours à la migration vers une architecture 2 tiers devient un besoin crucial plus qu’un
choix.
C’est dans ce cadre que s’inscrit notre projet de fin d’études intitulé « Récréation et refonte du
réseau entreprise et data center ». Notre projet est axé sur deux principaux volets. Le premier volet est
celui de la simulation de l’architecture 3 tiers existante. Le second volet est celui de l’architecture 2
tiers, ceci consiste à concevoir et simuler une architecture à deux couches en adoptant le principe de
le SDN. En effet, avant la migration vers le modèle 2-tiers, l’étude et la simulation de l’architecture
3-tiers sont primordiales vu la grande relation entre les deux types, en plus, la nouvelle architecture
est dérivée de l’architecture 3-tiers.
Aujourd’hui, il est recommandé de migrer vers l’architecture à deux niveaux, dite Leaf-Spine,
illustrée par la Figure 1.4, pour répondre aux besoins des applications modernes : haut débit et faible
latence.
F IGURE 1.4: Architecture 2-tiers
Cette architecture est composée de deux couches :
ENIG Page 10
• La couche Spine : composée des commutateurs effectuant le routage qui sont généralement à
très haut débit, à faible latence disposant de plusieurs portset qui ont des connexions directes à haute
vitesse (10 à100 Gbps par port) à chaque commutateur Leaf.
• La couche Leaf : se compose des commutateurs d’accès qui se connectent à des périphériques
tels que les serveurs, les pares-feux, les équilibreurs de charge et les routeurs Edge.
Les principaux avantages de cette architecture sont :
• Résilience : chaque commutateur Leaf se connecte à chaque commutateur Spine, et chaque

liaison montante peut être utilisée simultanément.
• Latence : il y a un maximum de 2 sauts pour tous les flux de paquets Est-Ouest, donc une latence
ultra-faible est standard.
• Performances : les véritables liaisons montantes actives-actives permettent au trafic de circuler

sur les liaisons haut débit les moins encombrées disponibles.
• Évolutivité : il est facile d’ajouter du matériel et des capacités supplémentaires telles que
l’augmentation du nombre des commutateurs Leaf selon la capacité de ports souhaitée ou l’ajoute
des commutateurs Spine selon les besoins pour les liaisons montantes.
Donc, les architectures à deux niveaux éliminent les points de défaillance uniques, les goulots
d’étranglement du trafic et les problèmes d’évolutivité, tout en améliorant le débit global et la facilité
de gestion. L’architecture à deux niveaux traite de la modernisation du réseau physique.
En effet, l’entreprise Ooredoo est en train de migrer son réseau DC vers une architecture basée sur
SDN conçue pour aider les entreprises à s’adapter à la nature dynamique des applications d’aujourd’hui.
Elle vise à réduire la complexité des réseaux définis de façon statique, automatise les fonctions réseau,
accélère le déploiement des applications et services et simplifie le provisioning et la gestion des
ressources réseau.
1.5 Conclusion
Ce chapitre a été consacré à la présentation du cadre général de notre projet. Pour arriver à
nos fins, nous avons commencé par la présentation de l’entreprise ainsi que le service d’accueil.
ENIG Page 11
La problématique a été identifiée suite à une étude préalable de l’existant. Nous avons terminé ce
chapitre par la présentation de la solution proposée.
Dans le chapitre suivant, nous allons présenter les notions de base permettant de bien comprendre
notre projet et de détailler l’architecture du réseau.
ENIG Page 12
Chapitre
2
État de l’art et Concepts clefs
Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Etude de l’architecture 3 tiers d’Ooredoo . . . . . . . . . . . . . . . 14
2.2.1 Architecture existante du réseau Data Center . . . . . . . . . . . . . . 14
2.2.2 Campus existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.3 Protocoles utilisés dans le Data Center et les réseaux campus . . . . . 20
2.2.4 Architecture du réseau Backbone existant . . . . . . . . . . . . . . . . 22
2.2.5 Protocoles utilisés dans le Backbone . . . . . . . . . . . . . . . . . . . 24
2.3 Migration vers l’architecture SDN . . . . . . . . . . . . . . . . . . . 26
2.3.1 Concept du réseau SDN . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.2 Architecture SDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.3 ACI(Application Centric Infrastructure) la solution SDN du datacenter 29
2.3.4 SD-Access la solution SDN du Campus . . . . . . . . . . . . . . . . . . 32
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
ENIG Page 13
CHAPITRE 2. ÉTAT DE L’ART ET CONCEPTS CLEFS
2.1 Introduction
Après avoir présenté le cadre général de notre projet, nous allons faire, tout au long de ce chapitre,
une étude théorique de l’existant ainsi que la solution choisie précédemment. Nous commencerons
tout d’abord par détailler l’architecture existante du réseau Ooredoo.
Ensuite, nous identifierons et précisons les notions de base et les besoins à satisfaire de notre solution.
2.2 Etude de l’architecture 3 tiers d’Ooredoo
Dans cette section, on étudie l’architecture 3 tiers d’Ooredoo composée de : Data Center, réseaux
de campus et le réseau cœur.
2.2.1 Architecture existante du réseau Data Center
Le réseau datacenter adopte une architecture à 3 niveaux pour les sites de Charguia et Mghira. La
Figure 2.1 illustre l’architecture du réseau DC.
F IGURE 2.1: Architecture du réseau DC
ENIG Page 14
Cela est composé de :
• La couche d’accès
• La couche d’agrégation ou de distribution
• La couche cœur du réseau.
Pour bien expliquer les différents éléments de cette architecture, nous allons détailler chaque
couche.
2.2.1.1 Couche d’accès
Cette couche permet aux groupes du travail et aux utilisateurs d’accéder au réseau. Elle offre
plusieurs caractéristiques, dont les principales sont les suivantes :
• Commutation de couche 2
• Disponibilité élevée
• Sécurité des ports
• Eviter les boucles de niveau 2 à travers le protocole STP(Spanning Tree Protocol) La conception
de cette couche varie en fonction des switchs d’accès niveau 2. Ce sont des switchs de type Cisco
Nexus Operating System (NX-OS) 5k (5000) et 9K (9000) avec hautes performances et une faible
latence. Les switchs N5K-A et N5k-B sont directement reliés aux FEX-A (Cisco Fabric Extender) et
FEX-B. Les autres switchs N9K-A et N9K-B sont attachés aux blades.
Cisco Nexus 5000 : La gamme Cisco Nexus 5000 se compose de commutateurs 10 Gigabit
Ethernet à faible latence et à perte de paquets ultra réduite.[6] Grâce à ses fonctionnalités, les commutateurs
sont idéaux pour l’agrégation FEX.
FEX : La technologie FEX fournit une structure extensible et évolutive qui fournit une solution
flexible et complète. Elle permet une simplicité opérationnelle à grande échelle, avec un seul point de
gestion et d’application de la politique sur le commutateur parent via plus de 1000 ports Ethernet.
Cisco Nexus 9000 : Les commutateurs de la série Nexus 9000 offrent des performances et une
densité éprouvée jusqu’à 400 Gigabit, ainsi qu’une faible latence et une efficacité énergétique exceptionnelle
dans une gamme de facteurs de forme. Les commutateurs sont hautement programmables.[7]
ENIG Page 15
Blade : Une architecture de serveur qui héberge plusieurs modules de serveur dans un même
châssis. Il est utilisé pour économiser de l’espace et améliorer la gestion du système. Les Blades
fournissent généralement leurs propres systèmes de gestion et peuvent inclure un commutateur de
réseau ou de stockage.
2.2.1.2 Couche d’agrégation
Elle fournit la connectivité basée sur les stratégies et contrôle la limite entre les couches d’accès
et cœur [8]. La couche d’agrégation peut offrir :
• L’agrégation des liaisons LAN ou WAN
• La sécurité basée sur des stratégies sous forme de listes de contrôle d’accès et de filtrage
• Les services de routage entre LAN et VLAN(Virtual Local Area Network), et entre domaines de
routage
• La redondance et l’équilibrage de la charge Cette couche se décompose par des switchs de série
Cisco Nexus 7k multicouches utilisés pour segmenter les groupes de travail et isoler les problèmes
réseau dans l’environnement du DC.
Cisco Nexus 7000 : Ces commutateurs offrent un réseau Ethernet de haute densité (10,40 et 100
Gigabit) avec une connaissance approfondie des applications et des analyses de performances. La
série 7000 propose des outils d’automatisation et de programmation pour la configuration et la mise à
jour. Des interfaces API (Application Programming Interface) standards, ouvertes et programmables
sont disponibles pour le contrôle de provisionnement et les plans de données.
OTV (Overlay Transport Virtualization) : La virtualisation du transport par superposition (OTV)

sur les périphériques Cisco NX-OS utilise le routage basé sur l’adresse MAC et le transfert encapsulé
sur un réseau de transport pour prendre en charge les applications nécessitant une adjacence de couche
2, telles que les clusters et la virtualisation. OTV sont reliés par les switchs Nexus 7k afin de connecter
le réseau DC d’Ooredoo avec d’autres réseaux.
Solution F5 BIG-IP LTM(Local Traffic Manager) Le gestionnaire de trafic local F5 BIG-IP

LTM est le seul boitier qui offre à la fois la haute disponibilité, l’amélioration des performances, la
sécurité des applications, le contrôle d’accès. Une seule adresse IP de gestion lui est appliquée pour
permettre d’accéder facilement à l’équipement via une interface de navigateur Web.[9]
ENIG Page 16
Cette solution offre plusieurs bénéfices :
• Accélère nos applications : Réduit le volume du trafic réseau ainsi que l’impact de la latence sur
les performances des applications.
• Sécurise nos applications, notre réseau et nos données : Garantit la protection des applications
sur lesquelles repose notre business avec des fonctionnalités avancées de sécurité.
• Réduit les coûts liés aux serveurs, à la bande passante et à l’administration : Avec F5 BIG-IP
notre infrastructure est optimisée, nos services d’application sont consolidés sur une plateforme de
services unifiée.
• Facilite le déploiement de nos applications : Avec le système d’exploitation Traffic Management

Operation System (TMOS) du F5 et un langage de scripting des événements (F5 iRules), nous
déployons rapidement nos applications.
Le BIG-IP-F5 utilise deux modes de déploiements : One-Armed et Two-Armed Routed Mode.

"Arms" fait référence au nombre de connexions réseau de l’appliance d’équilibrage de charge. One-Arm
a une seule connexion réseau à un LAN sur lequel résident les serveurs et peut-être même les clients.
Dans la topologie Two-Armed, le Load Balancer agit comme un pont entre deux segments de
réseau, il est donc In-Line entre les clients et les serveurs. En général, Two-Arm peut également être
utilisé en quelque chose appelé « mode pont » ou « mode transparent ». C’est un mode simple et facile
à dépanner et donc le plus déployé. Le réseau data center d’Ooredoo utilise la solution Two-Armed.
La Figure 2.2 explique le principe de fonctionnement du mode Two-Armed.
F IGURE 2.2: Topologie du réseau pour une connexion Two-Armed
ENIG Page 17
2.2.1.3 Couche de cœur
La couche cœur assure le transport rapide entre les commutateurs d’agrégation dans le DC. Les
éléments à prendre en considération au niveau du cœur [10] :
• Commutation haute vitesse (Switch Nexus 7k).
• Fiabilité et tolérance aux pannes.
• Mise à l’échelle avec un équipement plus rapide, et non en rajoutant des éléments.
• Pas de traitements complexes des paquets gourmands en ressources processeur (tels que la
sécurité, l’inspection, la classification de qualité de service QoS ou tout autre processus).
2.2.1.4 Core d’entreprise
Le module core d’entreprise est composé de switchs de type ASR 9k (Aggregation Services
Routers 9000). Cette catégorie de switchs est conçue pour évoluer avec les besoins du réseau DC et de
l’entreprise, en tant que plate-forme modulaire, haute densité, économique et sécurisée. La série ASR
9k est conçue pour rationaliser les opérations réseau tout en optimisant les performances de réseau
de manière sécurisée. Ils garantissent l’optimisation de réseau, avec une plate-forme spécialement
conçue pour simplifier l’infrastructure complexe.
L’ASR 9k est attaché en même temps aux :
• Réseaux de campus DSC(Direction Services Clients), DT(Direction Technique) et LAC par

liaisons point à point.
• Backbone
• DC
• Les réseaux de Commerces, de franchise et de MSC (Mobile Switching Center) à travers un

module RA(Remote Access) composé de deux switch catalyseur 6500 en cluster présentant la terminaison
de niveau 3 des réseaux WAN et connectés au backbone IP(Internet Protocol) d’Ooredoo par des
liaisons VPN(Virtual Private Network). Chaque boutique est présentée par un VRF(Virtual Routing
and Forwarding) pour isolement. Par ailleurs, l’ASR9K fournit la connexion au réseau Internet via
le backbone par des liaisons L2VPN avec Sousse / Mannouba. En plus, il relie le DC Charguia avec
ENIG Page 18
le DC Mghira pour le backup en cas de problèmes. Dans la Figure 2.3, on présente un extrait de
l’architecture réseau d’Ooredoo.
F IGURE 2.3: Extrait de l’architecture réseau Ooredoo
2.2.2 Campus existant
Les réseaux campus d’Ooredoo sont représentés par une conception Two-Tier Collapsed Core qui
comprend deux couches :
• Couche Access : Cette couche se compose par des switchs de série c3750. Pour les réseaux de
taille moyenne et les succursales d’entreprise, la gamme Cisco Catalyst 3750 facilite le déploiement
d’applications convergées. Elle s’adapte à l’évolution des besoins commerciaux en offrant une flexibilité
de configuration, une prise en charge des fonctionnalités nécessaires aux réseaux convergés, et une
automatisation des configurations de services réseau intelligents. De plus, la gamme Cisco Catalyst
3750 est optimisée pour les déploiements Gigabit Ethernet de forte densité et comprend un large
éventail de commutateurs. Ces derniers répondent aux besoins de connectivités à l’accès, en agrégation
ou pour la constitution de petit réseau fédérateur.[11]
• Core : Cette couche se décompose par des switchs de série C4510. Les commutateurs de la
gamme Cisco Catalyst4510 permettent des Borderless Networks, offrant des expériences utilisateur
hautes performances. Ils permettent la sécurité, la mobilité, les performances des applications, la vidéo
et les économies d’énergie sur une infrastructure qui prend en charge la résilience, la virtualisation
et l’automatisation. Les commutateurs de la gamme Cisco Catalyst 4510 offrent des performances,
ENIG Page 19
une évolutivité et des services sans frontières avec un coût total de possession (TCO) réduit et une
protection supérieure de l’investissement.
2.2.3 Protocoles utilisés dans le Data Center et les réseaux campus
Après avoir présenté les réseaux de DC ainsi que les réseaux campus d’Ooredoo, nous exposons
dans cette section quelques protocoles de routage, de continuité de service et de partage de charge
utilisés dans le réseau DC et les réseaux campus.
2.2.3.1 OSPF (Open Shortest Path First)
C’est un protocole de routage à état de liens développé par l’IETF qui utilise un algorithme de
Dijkstra. Il est considéré comme une carte complète de la topologie du réseau. Les routeurs à état
de liens connaissent la topologie complète du réseau afin de calculer la somme des liens jusqu’à
destination (en fonction de la bande passante), puis ils choisissent la métrique inférieure. Il utilise les
notions des areas afin d’alléger le processus OSPF.[12]
2.2.3.2 HSRP (Hot Standby Routing Protocol)
C’est un protocole de redondance du premier saut (FHRP, First Hop Redundancy Protocols),
propriétaire Cisco, conçu pour assurer la haute disponibilité de la passerelle d’un réseau[13]. Le but
est qu’une éventuelle panne du routeur ne perturbe pas le routage. Un groupe de routeurs (généralement
2) dont l’un des deux est le routeur Actif, le routeur de secours sera en Standby. Les autres en mode
Listen. Le routeur actif assure le rôle de passerelle par défaut pour le sous-réseau. En cas de panne, le
routeur Standby prendra le relai. Puis, un des routeurs Listen deviendra le nouveau Standby.
2.2.3.3 RSTP (Rapid Spanning Tree Protocol)
Spanning-Tree est un protocole de couche 2 défini dans la norme IEEE 802.1d qui permet d’apporter
une solution au problème posé par la présence de boucles dans les réseaux commutés de type Ethernet
donc garder une topologie physique redondante tout en créant un chemin logique unique. Le principal
défaut du protocole STP est le temps de convergence énorme en cas de panne réseau qui vaut 50
ENIG Page 20
secondes. Le protocole RSTP est identique au STP mais avec un temps de convergence à 6 secondes
maximum ce qui le rend beaucoup plus opérationnel que STP.[14]
2.2.3.4 Technologie VLAN
Les vlans permettent un regroupement des utilisateurs de manière logique permettant une plus
grande flexibilité. Ainsi, les vlans permettent de profiter des avantages de la segmentation en sous-réseaux
sans être limité par des switchs.
2.2.3.5 Technique vPC (Virtual Port Channels)
Un portChannel virtuel permet aux liaisons physiquement connectées à deux périphériques différents
d’apparaître en tant que PortChannel unique vers un troisième périphérique. Ce dernier peut être un
Cisco Nexus, un commutateur, un serveur ou tout autre périphérique réseau.
Bien que les deux commutateurs vPC apparaissent comme un seul commutateur vers un périphérique
en aval, on distingue un vPC principal et un autre secondaire. En cas de panne du périphérique
principal, le périphérique secondaire devient le principal. Néanmoins, lorsque le système se rétablit,
le périphérique précédemment principal maintient son rôle.[15]
2.2.3.6 Technique EtherChannel
La technique EtherChannel a comme rôle l’agrégation de liens. Elle est souvent utilisée pour
augmenter la bande passante entre deux switchs. Cette technique sert à combiner plusieurs liens pour
obtenir un lien virtuel de meilleure capacité.
Par ailleurs, il existe deux manières de créer une agrégation de liens : en forçant l’agrégation et en
utilisant un protocole de négociation. Pour la négociation de l’agrégation, il existe deux protocoles :
• PAGP : Port Agregation Protocol
• LACP : Link Agregation Control Protocol
ENIG Page 21
2.2.4 Architecture du réseau Backbone existant
Le réseau Backbone d’Ooredoo est une architecture MPLS qui se compose de deux grandes
parties : les sites utilisateurs et du domaine MPLS (cœur de réseau). Il supporte la partie la plus
importante du trafic avec une bande passante importante.
2.2.4.1 Réseau MPLS(Multi-Protocol Label Switching)
Lors de l’entrée dans le domaine MPLS, tout paquet ou trame de réseau provenant d’un site
utilisateur (réseau utilisateur) est examiné (examen principalement basé sur le champ Class of Service)
et classé dans une FEC (Forwarding Equivalence Class )à laquelle une étiquette est attribuée avant
l’envoyer au cœur du domaine MPLS : c’est le label pushing. Une fois à l’intérieur du domaine MPLS,
tous les paquets arrivant sur un routeur sont examinés (examen basé sur des étiquettes uniquement)
et les étiquettes sont enlevées, par la suite, une autre étiquette est ajoutée à chacun de ces paquets en
fonction du chemin qu’il prendra : c’est le label swapping. Cette opération sera répétée jusqu’à ce
que les trames arrivent aux frontières du domaine MPLS. A la sortie du domaine MPLS, les trames
provenant du cœur du domaine MPLS sont examinées et leurs étiquettes sont enlevés, puis ces paquets
sont envoyés vers leurs destinations : le label popping.
2.2.4.2 Composants principaux du réseau MPLS
Le backbone du fournisseur de services comprend deux types de routeurs :

• Provider Edge routers (PE routers)
• Provider Core routers (P routers)
Les routeurs PE sont situés à la périphérie du cœur du fournisseur de services et se connectent

directement aux sites des clients. Ces routeurs doivent exécuter BGP-4 (Border Gateway Protocol 4),
y compris les extensions VPN BGP / MPLS. Les routeurs P se connectent directement aux routeurs PE
ou à d’autres routeurs P et ne se connectent pas directement aux sites des clients. Ces routeurs doivent
être capables de commuter les LSP (Label Switched Path) MPLS, c’est-à-dire qu’ils fonctionnent
comme des routeurs à commutation d’étiquette (LSR) MPLS et peuvent fonctionner comme des
routeurs de périphérie d’étiquette (LER). Les routeurs PE communiquent avec les sites clients via une
connexion directe à un périphérique client (CE) situé en bordure du site client. Le périphérique CE
ENIG Page 22
peut être un hôte unique, un commutateur ou, plus généralement, un routeur. Lorsque le périphérique
CE est un routeur, il s’agit d’un homologue de routage de tous les routeurs PE directement connectés,
mais il ne s’agit pas d’un homologue de routage de routeurs CE sur un autre site. Le lien entre
le routeur CE et le routeur PE peut employer n’importe quel type d’encapsulation. L’utilisation de
MPLS n’est pas nécessaire. [16] Dans Figure 2.4, chaque routeur PE se connecte à plusieurs routeurs
CE et au moins un routeur P. Bien qu’un seul site client soit affiché, chaque routeur CE se trouve dans
un site client.
F IGURE 2.4: BGP/MPLS VPN Scenario
Un site client est un réseau qui peut communiquer avec d’autres réseaux dans le même VPN. Un
site client peut appartenir à plus d’un VPN. Deux sites ne peuvent échanger des paquets IP entre eux
que s’ils ont au moins un VPN en commun. Chaque site client connecté à un routeur PE particulier
est également associé à une instance de routage et de transfert VPN (VRF). Chaque VRF a sa propre
table de transfert distincte de celle des autres VRF et de la table de transfert globale du routeur virtuel.
ENIG Page 23
2.2.5 Protocoles utilisés dans le Backbone
2.2.5.1 MPLS
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 il va envoyer le
paquet. Le mécanisme de recherche dans la table de routage est consommateur de temps et de 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 commutant les
paquets en fonction du label, sans avoir à consulter l’entête de niveau 3 et la table de routage. L’intérêt
de MPLS n’est actuellement plus la rapidité mais l’offre de services qu’il permet, avec notamment
les réseaux privés virtuels (VPN) et le Traffic Engineering (TE), qui ne sont pas réalisables sur des
infrastructures IP traditionnelles.[17]
2.2.5.2 Layer 2 VPN
Les VPN de couche 2 de Cisco IOS Multiprotocol Label Switching (MPLS) consolident le trafic
de couche 2 tel qu’Ethernet, Frame Relay, mode de transfert asynchrone (ATM), High Level Data
Link Control (HDLC) et Point-to-Point Protocol (PPP) sur un Réseau IP / MPLS. Cette prise en
charge permet aux fournisseurs de services de protéger leurs investissements en continuant à fournir
des services de données et de voix existants tout en introduisant de nouveaux services et architectures.
Les fournisseurs de services bénéficient également d’économies de coûts de services convergents et
de nouveaux revenus de services grâce à de nouveaux services IP innovants sur le réseau IP / MPLS
nouvellement convergé.[18]
ENIG Page 24
2.2.5.3 Layer 3 VPN
Les VPN MPLS Layer 3 utilisent un modèle peer-to-peer qui utilise le protocole BGP pour
distribuer les informations relatives au VPN. Ce modèle peer-to-peer hautement évolutif permet aux
abonnés d’entreprise d’externaliser les informations de routage à des fournisseurs de services, ce qui
se traduit par des économies de coûts importantes et une réduction de la complexité opérationnelle
pour les entreprises. Les fournisseurs de services peuvent alors offrir des services à valeur ajoutée tels
que la qualité de service (QoS) et l’ingénierie du trafic, permettant une convergence du réseau qui
englobe la voix, la vidéo et les données.[19]
2.2.5.4 MP-BGP
La version normale de BGP ne prenait en charge que les préfixes IPv4 unicast. De nos jours, nous
utilisons MP-BGP (Multiprotocol BGP) qui prend en charge différentes adresses :
• IPv4 unicast
• IPv4 multicast
• IPv6 unicast
• IPv6 multicast
MP-BGP est également utilisé pour MPLS VPN où nous utilisons MP-BGP pour échanger les
étiquettes VPN. Pour chaque type d’adresse différent, MP-BGP utilise une famille d’adresses différente.[20]
2.2.5.5 La technique VRF
La virtualisation est une technique permettant de masquer les caractéristiques physiques des
ressources informatiques de la manière dont d’autres systèmes, applications ou utilisateurs finaux
interagissent avec ces ressources. Cela implique de faire en sorte qu’une seule ressource physique
(comme un serveur, un système d’exploitation, une application, etc. . . ) semble fonctionner comme
plusieurs ressources logiques ; ou cela peut inclure la création de plusieurs ressources physiques (telles
que des périphériques de stockage ou des serveurs) comme une seule ressource logique.
VRF est une technologie Cisco qui permet de segmenter un routeur physique en plusieurs routeurs
virtuels. Le mode VRF permet à un routeur de gérer simultanément plusieurs tables de routage. Ces
ENIG Page 25
tables de routage sont indépendantes, il est donc possible d’utiliser des adresses IP identiques ou qui
se chevauchent dans les réseaux des clients. Le VRF permet une segmentation des routeurs au niveau
3, un peu comme les VLANs permettent une segmentation des commutateurs au niveau 2.
Cette technologie est intéressante pour les opérateurs ou les hébergeurs qui souhaitent isoler les
tables de routages de leurs clients. Le VRF peut être couplé avec du VPN et des protocoles de routage
dynamiques.[21]
2.3 Migration vers l’architecture SDN
2.3.1 Concept du réseau SDN
Lorsqu’on parle d’un équipement réseau « classique », on distingue couramment deux principaux
composants : le plan de contrôle et le plan de transmission (ou plan de données). Le plan de contrôle
désigne l’intelligence de l’équipement, tel que les services et le CPU qui en dépendent. C’est la partie
responsable de la communication avec les autres équipements en utilisant un protocole de routage.
Concernant le plan de transmission, il présente les composants permettant la transmission de données
à hautes performances sur le réseau. Cependant, tout réseau classique présente des limitations, telles
que :
• Complexité : l’ajout ou modification d’équipement et l’implémentation de politiques réseaux

sont complexes, longues et peuvent être source d’interruption des services.
• Mise à l’échelle : les opérateurs ont été obligés de sur-provisionner leurs réseaux à cause de
l’impossibilité de construire un réseau qui s’adapte au trafic.
• Dépendance aux constructeurs : ceci provoque un problème d’adaptation des équipements

réseaux.
Ces nombreuses problématiques seront simplifiées et unifiées au sein d’un réseau SDN. Avec le
concept SDN, on établit une séparation claire entre le plan de contrôle et le plan de données. Dans
le SDN, le plan de contrôle est placé dans un contrôleur centralisé qui a une visibilité complète de la
topologie du réseau comme l’indique la Figure 2.5.
ENIG Page 26
F IGURE 2.5: Passage du réseau traditionnel (classique) vers le réseau SDN
L’architecture des réseaux traditionnels se caractérise par la décentralisation et complexité alors

que les réseaux actuels ont besoin de plus de flexibilité et un dépannage facile. Donc, SDN est destiné
à répondre au fait que centraliser l’intelligence du réseau en sépare le processus de transmission des
paquets réseau (plan de données) et le processus de routage (plan de contrôle qui comporte un ou
plusieurs contrôleurs).
En effet, le SDN vise à réduire la complexité des réseaux définis de façon statique, automatise les
fonctions réseau, accélère le déploiement des applications et services et simplifie le provisioning et la
gestion des ressources réseau.
Les environnements SDN centralisés et programmables peuvent facilement s’adapter aux besoins
en évolution rapide des entreprises. Il peut réduire les coûts et limiter le provisionnement inutile, ainsi
que fournir la flexibilité et l’innovation pour les réseaux. En plus, le SDN s’appuie sur un contrôleur
(cerveau du réseau) relaie les informations aux commutateurs et routeurs via des API vers le sud et
aux applications avec des API vers le nord.
Un réseau SDN permet de :
• Prendre en charge l’allocation dynamique de ressources virtuelles
• Réduire la charge de travail de gestion liée à la configuration
• Surveiller le trafic tout en bénéficiant d’une visibilité de bout en bout du réseau
• Optimiser l’utilisation des ressources réseau
• Réduire les frais d’exploitation
• Evoluer plus rapidement les fonctions réseau
ENIG Page 27
• Mettre en œuvre une fonction de sécurité plus fiable
• Réduire la complexité
• Orchestrer et automatiser la gestion du réseau
2.3.2 Architecture SDN
Dans l’architecture SDN décrite dans la Figure 2.6, la séparation des fonctions de contrôle et de
transmission des données sont appelées « désagrégation ». En effet, ces éléments peuvent être fournis
séparément, plutôt que déployés comme un système intégré. Cette architecture donne aux applications
plus d’informations sur l’état de l’ensemble du réseau à partir du contrôleur, par opposition aux
réseaux traditionnels où le réseau ne connaît que les applications.
F IGURE 2.6: Les différents couches du SDN
Le réseau SDN se compose de trois couches : couche d’application, couche de contrôle et couche
d’infrastructure. Ces dernières sont reliées via des API ascendantes (Northbound) et des API descendantes
(Southbound). La couche applicative comprend des fonctions applicatives et réseau, comme des
pares-feux et un équilibreur de charge. Les réseaux traditionnels utilisent une appliance dédiée pour
mettre en œuvre ces fonctions, tandis que les réseaux SDN utilisent un contrôleur pour gérer le
comportement du panneau de données. Les stratégies et le trafic sur le réseau sont gérés par la couche
de contrôle. La couche d’infrastructure est constituée des commutateurs physiques du réseau.[22]
Les applications SDN : sont des programmes qui communiquent les comportements et les ressources
nécessaires avec le contrôleur SDN via des interfaces de programmation d’application (API). En
outre, les applications créent une vue du réseau en collectant des informations à partir du contrôleur
pour prendre des décisions.
ENIG Page 28
Le contrôleur SDN : est une entité logique qui reçoit des instructions ou des exigences de la
couche d’application SDN et les transmet aux composants réseau. Le contrôleur extrait des informations
réseau à partir des périphériques matériels et les transmet aux applications SDN avec une vue abstraite
du réseau.
Les périphériques réseau SDN : contrôlent les capacités de transfert et de traitement des données
pour le réseau. Cela comprend le transfert et le traitement du chemin de données.
2.3.3 ACI(Application Centric Infrastructure) la solution SDN du datacenter
2.3.3.1 Présentation de la solution ACI
Cisco ACI est le SDN le plus largement adopté dans le secteur pour la mise en réseau des centres
de données. C’est la solution d’infrastructure centrée sur les applications de Cisco qui comprend la
structure de commutation physique (principalement basée sur les commutateurs Nexus 9000 dans
une topologie Leaf/Spine) et le contrôleur d’infrastructure de stratégie d’application (APIC). L’APIC
est un moteur de stratégie et de contrôle de réseau en cluster, responsable de la mise en place de la
structure, de la gestion de la structure, de la configuration des stratégies, etc.
Les commutateurs de l’ACI forment une topologie « fat tree» en connectant chaque nœud Leaf
à chaque nœud Spine du réseau. La structure fournit un transfert cohérent et à faible latence sur les
liaisons à bande passante élevée. Le trafic avec une source et une destination sur la même leaf est géré
localement, tout le reste du trafic étant acheminé entre les leaf d’entrée et de sortie à travers la couche
spine.
La solution ACI repose sur les composants clés suivants :
• Application Policy Infrastructure Controller (APIC) : système de contrôle et de politique de

réseau en cluster assurant la gestion des images, l’amorçage et la configuration des politiques.
• Structure de commutation physique basée sur une topologie leaf/spine : Chaque commutateur
leaf est connecté à chaque commutateur spine (techniquement appelé« bi-partite graph » en utilisant
des connexions 40GE.
La Figure 2.7 montre l’interconnexion des composants matériels pour former ACI Fabric.
ENIG Page 29
F IGURE 2.7: Composants matériels dans une structure ACI
2.3.3.2 Protocoles ACI
ACI est entièrement basé sur un ensemble de normes existantes et évolutives qui permettent les
capacités uniques et puissantes qui fournissent un réseau vraiment flexible, automatisé, évolutif et
moderne pour prendre en charge les applications.
Protocole du plan de données : Le transfert à travers la structure ACI est entièrement encapsulé
dans VXLAN (Virtual Extensible LAN) qui est une technologie clé utilisée dans l’infrastructure
centrée sur les applications. VXLAN est conçu pour remédier à la plupart des lacunes associées aux
VLAN classiques, en particulier :
• Évolutivité supérieure en termes de nombre de segments de couche deux pris en charge. Alors
que les VLAN sont limités à un peu plus de 4000, VXLAN peut évoluer (grâce à l’utilisation d’un ID
24 bits) jusqu’à 16 millions de segments individuels.
• Permet l’extension de la couche deux à travers les limites de la couche trois grâce à l’utilisation
de l’encapsulation MAC-in-UDP.
Dans un environnement exécutant VXLAN, les périphériques qui terminent les tunnels VXLAN
sont appelés VXLAN Tunnel End Points (VTEP). Un VTEP est un périphérique virtuel ou physique
qui mappe les périphériques terminaux aux segments VXLAN et effectue l’encapsulation et la désencapsulation.
Un VTEP a deux interfaces : une sur le segment LAN local, utilisée pour se connecter directement aux
ENIG Page 30
terminaux et l’autre sur le réseau de transport IP, utilisée pour encapsuler des trames de couche 2 dans
des paquets UDP et les envoyer sur le réseau de transport. La Figure 2.8 décrit les VTEP VXLAN.
F IGURE 2.8: VTEP VXLAN
Outre les avantages d’évolutivité et de flexibilité fournis par VXLAN, son utilisation dans la
structure ACI permet également de séparer l’emplacement de l’identité. Dans un environnement
IP traditionnel, l’adresse IP est utilisée pour fournir des informations sur l’identité d’un terminal,
ainsi que des informations sur l’endroit où ce terminal réside sur le réseau. Une technologie de
superposition telle que VXLAN sépare essentiellement ces fonctions et crée deux « Namespaces
» un pour l’identité et un autre pour indiquer où réside ce terminal.
Dans le cas de l’ACI, l’adresse IP du terminal continue d’être utilisée comme identifiant, tandis
qu’une adresse VTEP désigne l’emplacement d’un terminal sur le réseau.
Protocoles du plan de contrôle : Plusieurs protocoles bien compris et testés forment le plan
de contrôle ACI. Chaque nouveau Leaf ou Spine attaché à la structure utilise un type-length-value
spécifique dans un flux de signalisation LLDP (Local Link Discovery Protocol) pour se connecter
à l’APIC et ainsi s’enregistrer comme un nouvel ajout potentiel à la Fabric. L’admission n’est pas
autorisée jusqu’à ce qu’un humain ou un point d’automatisation ajoute le nouvel élément Leaf ou
Spine. Cela empêche l’enregistrement de commutateurs à des fins néfastes. Le transfert à travers la
Fabric et l’accessibilité sont réalisés via un protocole de passerelle intérieure à état de liaison à zone
unique, plus spécifiquement du Intermediate System-Intermediate System (IS-IS). Cela se prête à une
mise à l’échelle massive, avec la simplicité au cœur de la conception.
Différents protocoles de passerelle intérieure sont pris en charge pour la communication avec des
périphériques de routage externes à la périphérie de la Fabric : I-BGP, OSPF et EIGRP(Enhanced
Interior Gateway Routing Protocol), ainsi que le routage statique sont des options pour établir une
ENIG Page 31
communication IP vers et depuis la Fabric elle-même. Ces protocoles s’exécutent uniquement sur le
Leaf de bordure, qui relie physiquement les réseaux adjacents à la Fabric. Les commutateurs de Leaf
de bordure ne sont pas une configuration de périphérique spéciale, seulement une notation du bord de
la Fabric ACI se connectant aux réseaux adjacents.
Étant donné que le plan de données de la Fabric ACI utilise VXLAN, le protocole du plan de
contrôle utilisé, à partir de la version 3.0, est MP-BGP avec EVPN. Cela fournit une amélioration par
rapport à l’utilisation antérieure de la multidiffusion pour faire face aux besoins de trafic du plan de
contrôle autour du trafic de diffusion, de Broadcast Unknown-unicast and Multicast (BUM) à travers
la structure VXLAN.[23]
2.3.4 SD-Access la solution SDN du Campus
2.3.4.1 Principe de la solution SD-Access
L’accès défini par logiciel Cisco (SD-Access) est l’évolution des conceptions de campus traditionnelles
vers des réseaux qui implémentent directement l’intention d’une organisation. SD-Access est une
application logicielle exécutée sur le matériel Cisco DNA (Digital Network Architecture) Center et
utilisée pour automatiser les réseaux de campus câblés et sans fil. La technologie Fabric est une partie
intégrante de SD-Access qui fournit des réseaux de campus câblés et sans fil avec des superpositions
programmables et une virtualisation de réseau facile à déployer, permettant à un réseau physique
d’héberger un ou plusieurs réseaux logiques pour répondre à l’intention de conception. En plus de la
virtualisation du réseau, la technologie de Fabric dans le réseau du campus améliore le contrôle des
communications, en fournissant une segmentation définie par logiciel et une application de politique
basée sur l’identité de l’utilisateur et l’appartenance au groupe.
La segmentation définie par logiciel est parfaitement intégrée à l’aide de la technologie Cisco
TrustSec, fournissant une micro-segmentation pour les groupes au sein d’un réseau virtuel à l’aide
de Scalable Group Tags (SGTs). L’utilisation de Cisco DNA Center pour automatiser la création de
réseaux virtuels avec une sécurité et une segmentation intégrée réduit les dépenses opérationnelles et
réduit les risques.[24]
ENIG Page 32
2.3.4.2 Composants de la solution SD-Access
La solution SD-Access est fournie par une combinaison de Cisco DNA Center, du moteur de
services d’identité (ISE) et de plates-formes de périphériques filaires et sans fil qui ont une fonctionnalité
de structure. Les plates-formes de périphériques filaires et sans fil sont utilisées pour créer les éléments
d’un site Fabric.
Cisco DNA Center : est le portail permettant de contrôler l’ensemble de la topologie SD-Access.
Il s’agit d’une Appliance matérielle qui est localisée sur le WEB. L’idée est de fournir une interface
centralisée pour toutes les opérations :
• De configuration
• De sécurité
• D’analyse du réseau d’entreprise, que ce soit dans LAN, WLAN, ou WAN.
La gestion du réseau devient plus facile, ce qui permet d’accélérer les changements et de répondre
plus rapidement aux besoins de l’entreprise.[25]
Moteur de services d’identité : Cisco Identity Services Engine (ISE) est une plate-forme d’accès
réseau sécurisée permettant un contrôle et une cohérence de gestion accrus pour les utilisateurs et les
périphériques accédant au réseau d’une organisation. ISE est une composante intégrale et obligatoire
de SD-Access pour la mise en œuvre de la politique de contrôle d’accès au réseau.
ISE exécute la mise en œuvre de la politique, permettant le mappage dynamique des utilisateurs
et des périphériques vers des groupes évolutifs, et simplifiant l’application de la politique de sécurité
de bout en bout. Dans ISE, les utilisateurs et les appareils sont représentés dans une interface simple
et flexible. ISE s’intègre à Cisco DNA Center en utilisant Cisco Platform Exchange Grid (pxGrid)
et les API REST (Representational State Transfer Application Programming Interfaces) pour les
notifications d’événements de terminaux et l’automatisation des configurations de politique sur ISE.[26]
2.3.4.3 Campus Fabric
Dans la « Fabric », nous trouvons tous les composants matériels que nous connaissons tel que
routeurs, interrupteurs, contrôleurs LAN sans fil, Points d’accès, etc. Cela inclut tous les périphériques
fonctionnant sous IOS et IOS XE.
ENIG Page 33
Pour configurer les équipements du "Fabric", nous devons utiliser des API mais la CLI(Command
Line Interface) reste aussi disponible pour le dépannage. La « Fabric » contient trois éléments clés :
• Plan de contrôle : basé sur le protocole LISP (Locator Identity Separator Protocol)
• Plan de données : basé sur un LAN virtuel extensible (VXLAN : Virtuel Extensible LAN)
• Politique : basée sur Cisco TrustSec (CTS) Dans le plan de contrôle, le protocole LISP (Locator
Identity Separator Protocol) est utilisé pour simplifier le routage en supprimant les informations de
destination de la table de routage, pour les déplacer vers un système de mappage, très similaire à DNS
(Domain Name System).
Autrement dit, pour trouver une adresse de destination, le routeur demandera directement au
système de mappage de protocole LISP. Les tables de routage des routeurs sont donc plus petites
et nécessitent moins de charge CPU. Le protocole LISP permet donc de tunnéliser le trafic de couche
3 dans le plan de contrôle.
En ce qui concerne le plan de données, qui fonctionne au niveau de la couche 2, la technologie

SD-Access utilise VXLAN pour prendre en charge l’encapsulation de la couche 2 et permet de créer
des stratégies réseau sans les mapper sur des adresses IP ou des sous-réseaux.
En effet, LISP est une architecture de routage et d’adressage développée par Cisco Systems. Son
principe est comme suit : LISP crée deux adresses pour chaque nœud du réseau : une pour son
identité et une autre pour son emplacement dans le réseau. Cette approche contraste avec la pratique
traditionnelle consistant à utiliser une seule adresse qui est l’adresse IP pour représenter à la fois
l’identité et l’emplacement. LISP a été conçu pour aider à faire évoluer les tables de routage Internet,
qui se sont développées de manière agressive au fil des ans et continueront de devenir de plus en plus
complexes à mesure que l’adoption d’IPv6 se poursuit.
Les adresses LISP sont respectivement appelées Endpoint Identifiers (EID) et Routing Locators
(RLOC). Chaque nœud du réseau a un seul Endpoint Identifier mais peut avoir plusieurs Routing
Locators. Le protocole fournit un service de mappage entre eux.
Avec les architectures d’adressage traditionnelles, un appareil a besoin d’une nouvelle adresse IP à
chaque fois qu’il change de réseau. Par conséquent, si un utilisateur de tablette bascule la connectivité
réseau de la 4G vers le Wi-Fi, ou si une machine virtuelle (VM) est migrée vers un autre serveur
physique dans le data center, l’appareil ou l’objet nécessite une nouvelle adresse IP. Dans le scénario
ENIG Page 34
du data center, l’attribution d’une nouvelle adresse IP à une VM migrée signifie que tous les autres
services attachés à la VM : pare-feu et équilibreurs de charge. . . , ne pourront pas trouver la VM
jusqu’à un administrateur les configure avec la nouvelle adresse. LISP permet à un nœud de conserver
la même adresse IP même lorsque son emplacement change car il conserve son EID lors du mappage
vers plusieurs RLOC. Les routeurs périphériques compatibles LISP peuvent agréger les préfixes EID
avec des RLOC étroitement alignés, ce qui permet à un routeur principal de déterminer rapidement
où envoyer les données.[27]
La Figure 2.9 décrit le principe de fonctionnement du protocole LISP.
F IGURE 2.9: Principe de fonctionnement de LISP
2.4 Conclusion
Tout au long de ce chapitre, nous avons fait une étude théorique de notre architecture existante
ainsi que la solution proposée tout en mentionnant ses principes et ses méthodes de fonctionnement
suivi par les différents termes et les notions de base afin de faciliter son implémentation. Nous
allons entamer le dernier chapitre qui sera consacré pour la mise en place de la solution et son
expérimentation.
ENIG Page 35
Chapitre
3
Réalisations et Tests
Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Environnement matériel et logiciel . . . . . . . . . . . . . . . . . . . 37
3.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Environnements logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.1 Architecture existante du réseau . . . . . . . . . . . . . . . . . . . . . 38
3.3.2 Configuration des équipements des Campus . . . . . . . . . . . . . . . 40
3.3.3 Configuration des équipements du Data Center . . . . . . . . . . . . . 44
3.3.4 Configuration des équipements du Backbone . . . . . . . . . . . . . . . 55
3.4 Migration vers une architecture 2-tiers . . . . . . . . . . . . . . . . 64
3.4.1 Topologie adoptée pour l’architecture ACI pour les DC . . . . . . . . . 64
3.4.2 Configuration de la topologie adoptée . . . . . . . . . . . . . . . . . . 65
3.4.3 Simulation de l’architecture SD-Access pour les réseaux de campus . . 69
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
ENIG Page 36
CHAPITRE 3. RÉALISATIONS ET TESTS
3.1 Introduction
Ce chapitre représente la dernière partie de notre projet. Il est consacré pour l’implémentation
et l’exposition du travail réalisé tout au long du stage. Nous commençons par une description de
l’environnement matériel et logiciel avec lesquels nous avons travaillé. Ensuite nous passons à la
phase de configuration, test et validation appuyé par le biais des captures d’écran.
3.2 Environnement matériel et logiciel
Cette section sert à présenter les différents choix adoptés pour la réalisation de notre projet et
justifier leurs utilisations.
3.2.1 Environnement matériel
La réalisation de ce projet a été effectuée sur un ordinateur dont les caractéristiques sont illustrées
dans le Tableau 3.1.
Ordinateur portable Système d’exploitation RAM Disque Dur Processeur
1 Windows 10 8 Go 512 Go Intel Core I3
TABLE 3.1: Prés requis de la machine
3.2.2 Environnements logiciels
Pour l’implémentation et la simulation de deux architectures proposées, nous avons utilisé un

ensemble des logiciels. Par ailleurs, la virtualisation était la meilleure solution pour réaliser une
architecture réseau qui répond aux objectifs de la réalisation. Ainsi, pour mettre en place notre projet,
nous avons utilisé les outils suivants :
• GNS3 (Graphical Network Simulator) : est l’un des émulateurs de réseau que l’on peut opter
pour accéder à une simulation de réseau virtuel de qualité supérieure.
• VMware-workstation 12.5.9 : un outil de virtualisation qui peut être utilisé pour configurer
un environnement de test pour développer de nouveaux logiciels, ou l’installer réellement sur un
ordinateur physique afin de tester l’architecture complexe d’un réseau.
ENIG Page 37
• VMware vCenter Server : est le logiciel centralisé de surveillance et de gestion des ressources
pour l’infrastructure virtuelle VMware.
• VSphere ESXi : un logiciel utilisé dans le réseau d’Ooredoo est un hyperviseur de VMware
qui s’installe directement sur le serveur physique, ceci permet de partitionner ce dernier en plusieurs
serveurs logiques appelées machines virtuelles.
• Cisco NX-OS Software : utilisé pour la nouvelle gamme des switchs cisco Nexus. C’est un
système ouvert, modulaire, programmable et optimisé pour les déploiements de data centers aussi
bien physiques que virtuels.
3.3 Implémentation
Nous étudions ici, en premier temps, l’architecture à 3 niveaux d’Ooredoo. En second temps, nous
exposons quelques configurations adoptées au sein du réseau. Nous aborderons ensuite la migration
vers l’architecture à 2 niveaux basée sur le principe de le SDN. Enfin, nous décrivons des tests
effectués sur l’architecture proposée.
3.3.1 Architecture existante du réseau
Notre architecture étudiée est principalement composée de deux DC, un est appelée Charguia et
l’autre Mghira, un réseau backbone ainsi qu’un ensemble des réseaux de campus. La couche core
d’entreprise est attachée en même temps au DC, backbone, réseaux de campus et les réseaux de
commerce à travers un module RA. En plus, elle relie le DC Charguia avec le DC Mghira pour le
backup en cas de problèmes. La Figure 3.1 présente l’architecture simplifiée du réseau Ooredoo.
ENIG Page 38
F IGURE 3.1: Architecture simplifiée du réseau Ooredoo
Le réseau d’Ooredoo contient plusieurs réseaux de campus, dans le présent rapport, nous nous
intéressons uniquement au campus Lac dont l’architecture logique est décrite à la Figure 3.2.
F IGURE 3.2: Architecture logique du Campus Lac
Cette architecture comporte deux switchs d’accès qui se trouve en bas et qui sont physiquement
connectés aux serveurs appartenant au Vlans 15 et 16 et deux switchs core fournissant un réseau de
routage niveau 3. Le but principal est d’assurer la connectivité avec les éléments externes du campus.
ENIG Page 39
3.3.2 Configuration des équipements des Campus
Cette section sera réservée aux étapes de configuration de différents protocoles utilisés dans les
campus. Prenons l’exemple de la configuration d’un Switch Cisco Catalyst situé au niveau de la
couche Core. Les étapes de la configuration sont les suivantes :
• Création des VLAN
• Configuration du protocole RSTP
• Configuration du routage inter VLAN
• Configuration du protocole HSRP
• Configuration du protocole de routage OSPF
3.3.2.1 Création des Vlans
Comme nous avons déjà citer que les serveurs appartiennent aux différents Vlans, la Figure 3.3
illustre la liste des vlans créés.
F IGURE 3.3: Liste des Vlans
La Figure 3.4 illustre l’activation des ports utilisateurs en mode d’accès et l’attribution des VLANs
au niveau des switchs d’accès.
ENIG Page 40
F IGURE 3.4: Activation du mode d’accès et attribution des vlans
Les ports entre les switchs devront être configurés en mode trunk de manière à supporter plusieurs
vlans comme montre la Figure 3.5.
F IGURE 3.5: Configuration d’un port trunk
3.3.2.2 Configuration du RSTP
Le dernier commutateur est configuré ici en tant que « root principal » pour le vlan 15 et « root
secondaire » pour le vlan 16. La Figure 3.6 présente le résultat de la commande show spanning-tree
de vlans 15 et 16.
ENIG Page 41
F IGURE 3.6: Résultat de la commande Show Spannig-tree
3.3.2.3 Configuration du routage inter vlan
Le routage inter vlan se fait par la création des SVI (interface VLAN de gestion) qui assure le
traitement de couche 3 des paquets vers ou depuis tous les ports de commutateur associés à ce VLAN.
3.3.2.4 Configuration du HSRP
Nous définissons un groupe HSRP pour chacun des vlans, une adresse IP virtuelle commune à tous
les switchs du groupe, une priorité la plus élevée qui décide du switch « active » et de la préemption.
La priorité par défaut est 100. La Figure 3.7 montre notre configuration.
F IGURE 3.7: Configuration du protocole HSRP
ENIG Page 42
Donc le switch sera « active » pour le vlan 15 et « standby » pour le vlan 16 et l’inverse pour
l’autre switch. Cela est représenté par la Figure 3.8
F IGURE 3.8: Résultat de la commande standby brief
3.3.2.5 Configuration de l’OSPF
Le numéro du processus OSPF est 255. L’adresse IP de l’interface connectée à un autre switch L3
est 172.25.255.2 /24 et le numéro de l’aire est 3, elle est configurée en tant que zone NSSA comme
illustré sur la Figure 3.9.
F IGURE 3.9: Configuration du protocole OSPF
La Figure 3.10 présente la table de routage de switch Core1Lac. On remarque la présence d’une
route récapitulative par défaut de type O*IA.
ENIG Page 43
F IGURE 3.10: Table de routage de switch Core1Lac
3.3.3 Configuration des équipements du Data Center
Cette section sera réservée aux étapes de configuration des protocoles utilisés dans le DC. Nous
prenons l’exemple de DC Charguia dont l’architecture logique décrite par La Figure 3.11
F IGURE 3.11: Architecture logique de DC Charguia
Prenons l’exemple de la configuration de l’équipement Nexus 9K situé au niveau de la couche

d’agrégation. Au début, nous devons démarrer le module de supervision actif avec l’image Cisco
NX-OS.
ENIG Page 44
Puis recopier l’image Cisco NX-OS dans le bootflash et définir les variables de démarrage appropriées
pour nous assurons que le système démarre l’image Cisco NX-OS lors du prochain rechargement.
Les étapes de la configuration de l’équipement Nexus 9K sont les suivantes :

• Configuration des VLAN
• Configuration du protocole HSRP
• Configuration de vPC
• Configuration de F5-BIG-LTM
3.3.3.1 Configuration des Vlans
Pour la configuration des interfaces vlans au sein de Nexus, nous devons activer le feature interface-vlan
ensuite utiliser les mêmes commandes utilisées ci-dessus
3.3.3.2 Configuration HSRP
La configuration du protocole HSRP au sein de Nexus et comme suit :
ENIG Page 45
3.3.3.3 Configuration de vPC
Tout d’abord, activons les fonctionnalités nécessaires pour vPC sur les commutateurs. Puis nous
créons un nouveau vrf keepalive.
Nous devons ensuite configurer le domaine vPC. Dans ce cas, nous spécifions le numéro de
domaine et la configuration keepalive. Nous spécifions les adresses IP 168.192.10.1 et 168.192.10.2
ici pour le keepalive vPC. Nous devons créer une interface sur chaque commutateur et les connecter
ensemble.
Nous devons maintenant créer notre vPC peer-link. Cela sera utilisé pour faire passer le trafic
entre les peers dans le cas où l’une des liaisons port-channel tombe en panne.
ENIG Page 46
Alors maintenant, notre peer-link est également configuré. La seule chose que nous devrions
faire maintenant est de configurer la connexion vPC réelle. Nous devons d’abord déterminer si nous
utilisons LACP, PAGP, etc. Nous devons créer le port-channel sur les switchs concernés et ajouter la
commande vpc.
Dans notre cas et puisque les switchs d’accès supportent VPC un port-channel unique peut être
monté entre accès et agrégation. Ceci est appelé « Double Sided vPC ». La Figure 3.12 montre le
résultat de double sided vPC au niveau de deux switchs d’agrégation. Double sided vPC au niveau
d’agrégation
F IGURE 3.12: Double sided vPC au niveau d’agrégation
La Figure 3.13 montre le résultat de double sided vPC au niveau de deux switchs d’accès
ENIG Page 47
F IGURE 3.13: Double sided vPC au niveau d’accès
3.3.3.4 Configuration de F5 BIG-IP LTM
La plate-forme F5 BIG-IP étant conçue comme une architecture de Full-proxy, le LTM peut agir
en tant que proxy pour toute connexion de niveau de service. Dans notre architecture nous allons
utiliser le mode de déploiement Inline. Dans ce mode, le serveur virtuel (SV) se trouve sur le même
réseau et le même VLAN L2 que les membres du pool. Le LTM F5 sera déployé comme étant la
passerelle par défaut des serveurs internes. Les étapes ci-dessous montrent le fonctionnement et le
flux de trafic détaillé du déploiement Inline :
• La requête arrive au Load-Balancer F5 du client destiné à un SV ;
• Le Load-balancer sélectionne le serveur du back-end pour gérer la demande ;
• Le Load-balancer modifie l’IP de destination sur le paquet pour pointer vers le serveur du back-end,
puis le transmet. L’IP du client est maintenue ;
• Le serveur répond au client, en envoyant la réponse au Load-balancer. (Généralement, cela se fait
en faisant du Load-balancer la passerelle par défaut pour les serveurs back-end) ;
• Le Load-balancer modifie l’IP source du paquet vers le SV, puis transmet le paquet au client.
La Figure 3.14 montre une architecture que nous allons tester à titre d’exemple en mode Inline :
ENIG Page 48
F IGURE 3.14: Architecture du réseau à tester
Pour se connecter à F5 BIG-IP nous avons besoin de configurer l’interface management comme
montre la Figure 3.15.
F IGURE 3.15: Configuration de l’interface management
Une fois connecté, nous serons dans la section réseau. Nous avons la possibilité de continuer
l’utilitaire de configuration pour configurer les VLANs internes (côté serveur) et externes (côté client),
ENIG Page 49
ainsi que les interfaces et les adresses IP associées.

La Figure 3.16 illustre la manière de création d’un VLAN interne :
F IGURE 3.16: Création d’un VLAN interne
La Figure 3.17 montre la configuration d’un nouveau VLAN externe.
F IGURE 3.17: Création d’un VLAN externe
ENIG Page 50
• Node
Un nœud est un objet logique du système BIG-IP LTM qui identifie l’adresse IP d’une ressource
physique sur le réseau. Nous pouvons créer explicitement un nœud ou indiquer à Local Traffic
Manager de le créer automatiquement lorsque nous ajoutons un membre à un pool d’équilibrage
de charge. La Figure 3.18 montre la création d’un nouveau nœud.
F IGURE 3.18: Création d’un nouveau nœud
• Pool
Un pool est un ensemble logique des serveurs Web, que nous regroupons pour recevoir et traiter le
trafic. Au lieu d’envoyer le trafic client à l’adresse IP de destination spécifiée dans la demande du
client, le système BIG-IP envoie la demande à l’un des nœuds membres de ce pool. Une fois que nous
avons affecté un pool à un serveur virtuel, le système BIG-IP dirige le trafic entrant sur le serveur
virtuel vers un membre de ce pool. La Figure 3.19 illustre la configuration d’un pool.
ENIG Page 51
F IGURE 3.19: Configuration d’un nouveau pool
• Virtual Server
Le SV est considéré comme un auditeur qui reçoit et traite le trafic sur la plate-forme BIG-IP. Il écoute
une combinaison d’adresse IP et de port, qui représente l’application pour le client. Les connexions
côté serveur seront traduites de la combinaison adresse IP d’écoute et port du SV en combinaison
adresse IP et port du membre du pool auquel la connexion sera envoyée via l’algorithme d’équilibrage
de charge choisi. Le trafic de retour sera réécrit à partir de la combinaison adresse IP et port du membre
du pool ayant reçu la connexion entrante, à la combinaison adresse IP et port du SV auquel le client
s’est connecté lors de l’établissement de la connexion. L’une des propriétés d’un pool de serveurs est
une méthode d’équilibrage de la charge.
• Une méthode d’équilibrage de charge
C’est un algorithme utilisé par le système BIG-IP pour sélectionner un membre du pool afin de traiter
une demande. Par exemple, la méthode d’équilibrage de la charge par défaut est Round Robin, ce
qui amène le système BIG-IP à envoyer chaque demande entrante au prochain membre disponible du
pool, répartissant ainsi les demandes de manière uniforme sur les serveurs du pool. La Figure 3.20
montre la création d’un Serveur Virtuel dont le pool par défaut est celui déjà créé.
ENIG Page 52
F IGURE 3.20: Création d’un Serveur Virtuel
Pour tester la connectivité nous allons ouvrir une nouvelle session de navigateur sur l’utilisateur
externe en tapant l’adresse du SV 10.10.4.100 comme montre la Figure 3.21.
F IGURE 3.21: Orientation vers Server1
Ensuite, il faut actualiser la page Web, donc le F5 BIG-IP va nous orienter vers Server2 comme
ENIG Page 53
Actualisons la page Web une autre fois, cette fois F5 BIG-IP va nous orienter vers Server3 comme
illustre la Figure 3.23.
• iRules
Une iRule est une fonctionnalité puissante et flexible du système de gestion du trafic local BIG-IP
LTM que nous pouvons utiliser pour gérer notre trafic réseau. La fonction iRule nous permet non
ENIG Page 54
seulement de sélectionner des pools en fonction de notre besoin, mais également de diriger le trafic
en recherchant tout type de données que nous définissons.
3.3.4 Configuration des équipements du Backbone
Cette section sera réservée aux étapes de configuration de différents protocoles utilisés dans le
Backbone. La Figure 3.24 présente l’architecture logique du Backbone. Notre réseau de Backbone
est une architecture MPLS qui se compose de deux grandes parties : les sites utilisateurs(les réseaux
de Commerces et les franchises) et le domaine MPLS (cœur de réseau).
F IGURE 3.24: Architecture logique du Backbone
Nous avons effectué une configuration deux routeurs de fournisseur de services MPLS (PE), deux
routeurs pour les clients (CE) sur lesquels chacun d’eux disposent d’une instance VRF. Le réseau
MPLS du fournisseur de services exécutera une configuration OSPF de base et tous les routeurs des
clients participeront à BGP pour atteindre leurs autres sites.
3.3.4.1 Configuration du protocole MPLS layer 3 VPN
Configurons les interfaces des routeurs et OSPF pour établir la connectivité de base. Nous avons
également créé une interface loopback pour servir d’identifiant de routeur pour le processus OSPF et
ENIG Page 55
LDP et configurer les interfaces applicables pour le transfert MPLS dynamique. Prenons l’exemple
de la configuration de routeur PE1 sur la Figure 3.25.
F IGURE 3.25: Configuration de routeur PE1
3.3.4.2 Configuration des VRFs
Cette section sera dédiée à la description de la configuration les VRFs ShopGabes, ShopMarsa,
ShopAriana et ShopAeroport sur les CE.
• RD (Route Distinguisher)
Comme son nom l’indique, un identificateur de route (RD) distingue un ensemble de routes (un VRF)
d’un autre. Il s’agit d’un numéro unique ajouté à chaque route dans un VRF pour l’identifier comme
appartenant à ce VRF ou client particulier. Un RD est transporté avec une route via MP-BGP lors de
l’échange de routes VPN avec d’autres routeurs PE.
• RT (Route Target)
Bien que les RD soient utilisés pour maintenir l’unicité parmi les routes identiques dans différents
VRF, les RT peuvent être utilisées pour partager des routes entre elles. Nous pouvons appliquer des
RT à un VRF pour contrôler l’importation et l’exportation entre les VRFs.
Prenons l’exemple de la configuration de routeur CE2 sur la Figure 3.26.
ENIG Page 56
F IGURE 3.26: Configuration du VRF ShopGabes
Nous activons également les VRFs et configurons une adresse IP sur les interfaces comme montre
la Figure 3.27.
F IGURE 3.27: Configuration de l’interface F0/0.1
Ensuite, le protocole BGP est configuré pour faciliter l’annonce des réseaux clients sur le réseau
MPLS.
• RR (Route Reflector)
Les réflecteurs de route (RR) sont une méthode pour se débarrasser du maillage complet des pairs
IBGP du réseau. L’autre méthode est celle des BGP Confederations.
Le RR permet à tous les speakers IBGP de notre réseau autonome de connaître les routes disponibles
sans introduire de boucles. Cela simplifie beaucoup notre configuration IBGP. Ici, nous avons choisi
PE1 et PE2 dont leurs loopbacks sont respectivement 6.6.6.6 et 7.7.7.7 comme des routes reflectors
dans le but de réduire le nombre de peering BGP dans un AS.
La Figure 3.28 montre la configuration du protocole BGP au sein d’un CE.
ENIG Page 57
F IGURE 3.28: Configuration du protocole BGP
Passons à l’établissement des routes statiques IP pour les instances VRF ainsi que leur distribution.
En effet, les routes statiques VPN ne sont nécessaires que si le trafic VPN retournant aux réseaux du
client est transféré depuis l’interface de sélection VRF. Le routeur PE distant peut également être
configuré pour acheminer le trafic de retour vers les réseaux client directement en utilisant la table de
routage globale.
La Figure 3.29 montre la configuration des routes statiques pour les instances VRF.
F IGURE 3.29: Configuration des routes statiques pour les instances VRF
ENIG Page 58
Maintenant que la configuration est terminée, l’étape de vérification des voisins et des routes est
cruciale. En utilisant la commande show ip bgp vpnv4 all , nous pouvons vérifier les routes BGP
distribuées et à quel VRF elles appartiennent. La Figure 3.30 montre le résultat de la commande.
F IGURE 3.30: Table de routage bgp vpnv4
En utilisant la commande show mpls Forwarding-table, nous vérifions la topologie mpls illustrée
dans la Figure 3.31.
F IGURE 3.31: Topologie MPLS
3.3.4.3 Configuration du protocole MPLS Layer 2 VPN
Les VPN de couche 2 sont un type de réseau privé virtuel (VPN) qui utilise des labels MPLS pour
transporter des données. La communication se produit entre des routeurs appelés routeurs Provider
Edge (PE), car ils se trouvent à la périphérie du réseau du fournisseur, à côté du réseau du client. Les
VPN de couche 2 utilisent le protocole de distribution des labels (LDP) pour communiquer entre les
routeurs PE et établir un circuit virtuel fournissant au client une ou plusieurs connexions point à point
ENIG Page 59
privées.
Dans notre topologie, nous allons configurer trois routeurs de fournisseur de services MPLS (PE) et
deux CE. Les clients doivent disposer d’un circuit virtuel privé pour établir une connexion directe
point à point. En utilisant CDP, les deux sites client doivent apparaître directement connectés.
Le réseau MPLS du fournisseur de services exécutera une configuration OSPF de base et tous les
routeurs des clients utiliseront simplement des routes statiques pour pointer vers leurs autres sites. Le
backbone fournit la connexion aux directions régionales Sousse et Manouba par des liaisons L2VPN.
La Figure 3.32 illustre notre architecture.
F IGURE 3.32: Liaison L2VPN
Comme pour le L3VPN, nous commençons par la configuration des interfaces des PE et OSPF
pour établir la connectivité de base ainsi que la création d’une interface de bouclage qui servira
d’identifiant de routeur pour le processus OSPF et LDP.
Prenons l’exemple de la configuration du routeur PE1.
La Figure 3.33 illustre la configuration d’une classe pseudowire et du MPLS dynamique entre les
périphériques PE.
F IGURE 3.33: Configuration d’une classe pseudowire et du MPLS dynamique
Puis, nous configurons le circuit virtuel afin de fournir une connexion point à point privé pour le
client. Ainsi, la commande xconnect suivie de l’adresse IP du le routeur Peer établit la connexion pour
l’interface locale dans le circuit virtuel privé. La Figure 3.34 montre la configuration de l’interface
FastEthernet0/0 du routeur PE1.
ENIG Page 60
F IGURE 3.34: Configuration de l’interface FastEthernet0/0 du PE1
Passons à la configuration des deux CE avec une configuration de base. Chaque CE aura une seule
route statique dirigeant tout le trafic inconnu vers le CE du site adjacent. La Figure 3.35 montre la
configuration au sein de CE.
F IGURE 3.35: Configuration du routeur CE
Maintenant que la configuration est terminée, vérifions nos voisins et nos routes. En utilisant
les commandes show CDP Neighbors, show mpls Forwarding-table et show mpls l2transport vc
101, nous pouvons vérifier le déploiement MPLS, en utilisant la commande ping pour vérifier la
connectivité de deux PC utilisateurs de deux sites distants.
La Figure 3.36 montre le résultat de la commande show CDP Neighbors sur CE1 pour vérifier que
CE2 apparaît directement connecté
ENIG Page 61
F IGURE 3.36: Vérification des voisins
La Figure 3.37 montre le résultat de la commande show mpls Forwarding-table.
F IGURE 3.37: Résultat de la commande show mpls Forwarding-table
La Figure 3.38 montre le résultat de la commande show mpls l2transport vc 101.
F IGURE 3.38: Vérification du circuit virtuel
La connexion au réseau Internet est fournie via le backbone par des liaisons L2VPN avec Sousse
/ Mannouba. La configuration se fait en ajoutant un nœud cloud ainsi qu’un routeur reliant le cloud à
notre backbone. Commençons par la configuration d’une adresse IP sur le nouveau routeur en utilisant
DHCP ou en attribuant une adresse IP statique dans le même sous-réseau que notre PC local.
La Figure 3.39 montre l’attribution d’une adresse IP au routeur par le serveur DHCP.
ENIG Page 62
F IGURE 3.39: Attribution d’une adresse IP par le serveur DHCP
Passons à la configuration d’une route par défaut comme illustré sur la Figure 3.40.
F IGURE 3.40: Configuration d’une route par défaut
Assurons maintenant que le routeur est configuré pour utiliser le bon serveur DNS. Nous activons
tout d’abord le Domain Name Server (DNS) lookup feature en utilisant la commande ip domain-lookup
puis d’exécuter la commande sur la Figure 3.41.
F IGURE 3.41: Configuration DNS
Nous configurons OSPF au sein du nouveau routeur et nous publions une route par défaut comme
F IGURE 3.42: Configuration de l’ospf sur le nouveau routeur
En plus, la configuration des paramètres DNS dans les autres routeurs est importante à ce niveau.
La Figure 3.43 montre la configuration du NAT sur le nouveau routeur, ceci est nécessaire dans le but
d’envoyer de requête ping aux périphériques Internet.
ENIG Page 63
F IGURE 3.43: Configuration du NAT
3.4 Migration vers une architecture 2-tiers
Nous avons mentionné que l’architecture à 2 niveaux est basée sur le concept SDN suivant le
modèle Spine / Leaf. Cependant, nous n’avons pu exactement implémenter ce concept vu le problème
du contrôleur. En fait, toutes les solutions sont payantes, elles nécessitent d’avoir un contrat de
support avec cisco pour obtenir une clé d’activation. En plus, elles sont très gourmandes en termes de
mémoire. Pour cela, nous avons proposé une topologie simplifiée à deux commutateurs. On s’intéresse
au plan de contrôle et celui de données.
3.4.1 Topologie adoptée pour l’architecture ACI pour les DC
La solution proposée stipule que les commutateurs sont connectés avec un lien routé à travers
deux routeurs, qui agira comme notre underlay. Un hôte est connecté à chaque commutateur. Les
ports hôtes sont des ports d’accès normaux, sur le VLAN 10. Les hôtes sont dans le même sous-réseau
et ne pourront pas communiquer initialement en raison de la liaison routée. Les commutateurs sont
des passerelles VxLAN, qui mappent VLAN 10 à VNI 5000. Les commutateurs utilisés dans ce
laboratoire sont des Nexus 9000 EX Series, exécutant la version 7.0 (3) I7 (2).
La Figure 3.44 représente la topologie à tester.
ENIG Page 64
F IGURE 3.44: Topologie à tester
3.4.2 Configuration de la topologie adoptée
3.4.2.1 Configuration Underlay
L’underlay est la partie routée du réseau. Dans notre topologie, il s’agit du lien entre les deux
commutateurs. Il est important que cette partie soit configurée et qu’elle fonctionne avant la configuration
de l’overlay. Des problèmes dans la partie underlay entraîneront des problèmes dans la partie overlay.
Nous commençons par activer les features OSPF et PIM. OSPF est utilisé pour gérer le routage
dynamique. N’importe quel IGP peut être utilisé ici. PIM est la multidiffusion, qui est utilisée pour
gérer le trafic BUM.
VxLAN ajoute un peu de surcharge, nous devons donc augmenter la taille du MTU sinon nous
pouvons nous retrouver avec des paquets fragmentés, ce qui peut diminuer les performances. La
première étape consiste à démarrer le processus OSPF.
ENIG Page 65
Cette solution utilise deux interfaces de bouclage par commutateur. Les VTEPs sont représentés
par leurs adresses de Loopback 0. Il s’agit d’une adresse / 32 qui doit être publiée dans OSPF et qui
est différente sur chaque commutateur. L’adresse IP dans loopback0 est également utilisée comme
adresse de point de Rendevouz de multidiffusion. Ceci est amélioré avec loopback1, qui est l’adresse
anycast RP. Cette adresse est la même sur les deux commutateurs.
La configuration multicast est assez simple. Chaque interface est configurée en mode sparse. Les
points Anycast Rendevouz sont utilisés pour une haute disponibilité. Les RP seraient généralement
affectés aux commutateurs spine dans une topologie du monde réel. Ces RP sont responsables de tous
les groupes de multidiffusion (224.0.0.0/4).
La configuration du switch SW1 est comme suit :
La configuration du switch SW2 est comme suit :
Maintenant, pour configurer le lien routé, son adresse IP est annoncée dans OSPF et il est en mode
sparse.
ENIG Page 66
Maintenant que la partie underlay est terminée, vérifions qu’elle fonctionne en envoyant un ping
d’un voisin à un autre, y compris vers / depuis les adresses IP de bouclage. Vérifions également que
les relations de voisinage OSPF se forment.
3.4.2.2 Configuration Overlay
Toute la configuration ici doit être effectuée sur les deux commutateurs. Commençons par activer
les features. Le feature « nv overlay » active VxLAN, et la commande « Vn-segment-vlan-based » est
utilisé pour le mappage entre VLAN et VxLAN. Ensuite, nous avons crée le VLAN 10, qui est utilisé
pour les hôtes. Nous mappons ceci à VNI 5000 avec la commande vn-segment. Les ports hôtes sont
configurés avec VLAN 10 comme d’habitude, sans aucune commande VxLAN spéciale.
Sur la plate-forme Nexus, une interface virtuelle appelée interface NVE est utilisée. C’est le VTEP.
La commande source-interface indique au VTEP d’obtenir son adresse IP à partir de loopback0. Nous
devons également indiquer à l’interface les VNI dont il est responsable. Cela se fait avec la commande
member vni. C’est également là que nous mappons le VNI au groupe de multidiffusion 230.1.1.1 pour
la gestion du trafic BUM. La commande member vni doit être utilisée pour chaque VNI utilisé par
le VTEP. Un groupe de multidiffusion séparé peut être utilisé pour chaque VNI, ou un groupe peut
contenir plusieurs VNI.
ENIG Page 67
Par ailleurs, l’affichage des caractéristiques de l’interface VTEP se fait avec interface show nve.
La sortie montre que cette interface utilise l’encapsulation VxLAN, utilise data-plane Learning et
obtient son adresse IP à partir de loopback0.
La Figure 3.45 montre le résultat de la commande show nve interface au niveau des deux switchs.
F IGURE 3.45: NVE Interfaces
Pour voir les VNI sur le VTEP, nous exécutons la commande show nve vni. Ici, nous pouvons voir
VNI 5000, qui est associé au groupe de multidiffusion 230.1.1.1.Le Type montre qu’il s’agit d’un
L2VNI, mappé sur VLAN 10.
La Figure 3.46 montre le résultat de la commande show nve vni au niveau des deux switchs
ENIG Page 68
F IGURE 3.46: Les VNI
3.4.3 Simulation de l’architecture SD-Access pour les réseaux de campus
Voici quelques principaux composants du LISP qui construisent l’architecture LISP :

• ITR (Ingress Tunnel Router) : reçoit le paquet du site local et les encapsule sur le site LISP distant
ou transmet nativement le paquet à un site non LISP.
• ETR (Egress Tunnel Router) : reçoit le paquet du réseau central et désencapsule le paquet et
l’envoie au site.
• PITR (Proxy Ingress Tunnel Router) : reçoit le paquet de sites non LISP et encapsule le paquet
vers les sites LISP ou les transmet nativement.
• PETR (Proxy Egress Tunnel Router) : désencapsule les paquets des sites LISP pour les livrer à
des sites non LISP
• MS (Map Server) : est une base de données de cartographie qui accepte les demandes d’enregistrement
de ses routeurs de tunnel de sortie client (ETR)
• MR (Map Resolver) : La fonction du LISP MR est d’accepter les messages de demande de carte
encapsulés des routeurs de tunnel d’entrée (ITR), de décapsuler ces messages, puis de transmettre les
messages à la MS responsable des routeurs de tunnel de sortie (ETR) qui font autorité pour les EID
demandés.
ENIG Page 69
F IGURE 3.47: Aperçu général du fonctionnement LISP
Dans cette topologie, lorsque l’hôte avec l’adresse IP 10.10.1.1 tente d’atteindre l’hôte avec
l’adresse IP 10.10.2.1, il envoie le paquet à l’ITR local (EDGE01) sur le site. Ensuite, si l’ITR n’a pas
d’entrée dans sa map cache table, il crée une map request à la recherche de l’hôte 10.1.2.1 et l’envoie
au MR. La demande de mappage est également encapsulée LISP où l’en-tête externe a l’adresse
IP source 150.1.1.19 et l’adresse IP de destination 150.1.1.2 (MS / MR). La MS redirige le paquet
vers l’ETR (EDGE02), qui contient les informations sur le préfixe / sous-réseau d’hôte. On pense à
remarquer que les rôles MS et MR peuvent être combinés et fournis par le même nœud. En outre,
une autre chose importante à noter est que la map request arrive vers le mapping system, mais que le
mapping system n’envoie pas la réponse. L’ETR envoie la map reply directement à l’ITR qui a émis
la map request. La map reply contient les entrées de mappage des ETR avec les EID de destination.
La Figure 63 présente un réseau simple pour décrire la configuration et la vérification des fonctionnalités
de base de LISP. Dans le premier scénario, nous nous concentrons uniquement sur la communication
entre les sites LISP. La mise en œuvre de LISP dans ce scénario nécessite la configuration des
composants principales LISP : un ITR, un ETR et le nœud MS / MR. ITR et ETR sur le même
nœud est appelé xTR.
ENIG Page 70
F IGURE 3.48: Topologie à configurer
Sur chaque site LISP, OSPF s’exécute entre le nœud xTR et le commutateur interne. De plus, il y
a BGP entre xTR et ISP. Nous montrons uniquement la configuration liée à LISP car la configuration
BGP et OSPF est très basique dans cet exemple et ne fournit que le transport de sous-couche pour
RLOC et MS / MR.
Ci-dessous la configuration liée au LISP du nœud EDGE01 :
Le nœud EDGE02 est IOS-XE et récemment Cisco a modifié la syntaxe sur cette plate-forme,
donc différente de l’IOS ordinaire.
ENIG Page 71
Enfin, on présente ci-dessous la configuration liée au LISP du nœud MS / MR :
LA configuration LISP est achevée. Elle sert à assurer la communication entre les sites LISP. Dans
l’AS 100 qui simule la fonctionnalité Internet LISP est déployée uniquement sur le nœud MS / MR.
Les autres nœuds de l’AS 100 n’ont pas d’activation de fonctionnalité LISP.
Le réseau LISP est divisé en deux domaines de routage, le RLOC et l’EID où chacun de ces domaines
possède son propre espace d’adresses de routage. Le domaine de routage EID exécute OSPF, tandis
que RLOC exécute BGP. Le routeur xTR s’appuie sur le routeur MS / MR pour résoudre le mappage
EID vers RLOC, de sorte que le réseau sous-jacent doit fonctionner et doit fournir une connectivité
de base entre le RLOC et le nœud MS / MR. En outre, les préfixes EID locaux 10.10.1.0/24 ne sont
pas annoncés dans le réseau ISP à partir de EDGE01. La même chose est vraie pour EDI 10.10.2.0/24
qui ne fait pas de publicité du nœud EDGE02 au FAI. Ces préfixes utiliseront l’encapsulation LISP
pour fournir une connectivité entre les sites LISP.
• Vérification
La commande show ip lisp nous donne beaucoup d’informations comme quel composant LISP spécifique
ENIG Page 72
est activé. En outre, nous pouvons voir ce qu’est le TTL de cache de mappage par défaut, l’adresse IP
RLOC locale et l’IP de MS / MR.
Une autre commande utile que nous pouvons exécuter sur le nœud MS / MR pour vérifier le plan de
contrôle est la show lisp site details. Cette commande nous donne des informations sur le nœud xTR
spécifique enregistré auprès du map server. Une autre commande utile est show lisp session qui donne
des informations sur le pair et son état.
3.5 Conclusion
Ce chapitre nous a permis de présenter la mise en œuvre et l’expérimentation de notre architecture.

Au début, nous avons décrit l’environnement matériel et logiciel sur lesquelles nous avons construit
notre topologie. Nous avons, ensuite, implémenté les configurations nécessaires pour donner une
meilleure idée sur le travail réalisé appuyé par le biais des captures d’écran.
ENIG Page 73
CONCLUSION GÉNÉRALE
Depuis plusieurs années, il est communément admis que le modèle des réseaux de à trois niveaux
était la conception généralement la plus recommandée, mais le besoin aujourd’hui a complétement
changé et l’architecture 3 tiers ne répond plus aux exigences des nouvelles infrastructures définies
par logiciel nécessitant des changements dans l’architecture du réseau traditionnelle exigeant une
augmentation des flux de trafic est-ouest.
Dans ce contexte, la direction technique d’Ooredoo Tunisie, notre entreprise d’accueil, nous a proposé
de développer une solution visant à assurer la résilience, l’évolutivité et les meilleures performances
sur le réseau d’Ooredoo.
Au niveau de ce présent rapport, nous avons présenté notre travail réalisé au cours de ce stage à
savoir : effectuer une étude netographique sur les architectures réseau traditionnelles et l’apport des
architectures à deux niveaux basé SDN.
À l’issue de cette étude, nous avons proposé de mettre en œuvre l’architecture existante d’un FAI
(parties LAN, campus, WAN, edge entreprise . . . ) à travers l’outil d’émulation GNS3, puis de faire
une simulation de la migration de réseau Edge entreprise et data center d’une architecture 3-tiers
vers une autre 2-tiers en tenant compte de tous les changements nécessaires. Ce projet a pour but de
maîtriser et implémenter des protocoles de routage (OSPF, MP-BGP. . . ) ainsi que mettre en place un
réseau d’accès niveau deux (notions de VLAN, VXLAN, HSRP, VPC, L2/L3 VPN. . . ) en suivant les
bonnes pratiques.
Notre travail est d’une importance considérable dans la mesure où il nous a offert une ouverture sur le
monde professionnel et la vie en entreprise. D’un point de vue technique, il nous a permis de mettre
en œuvre les acquis théoriques que nous avons appris tout au long de notre cursus universitaire et
de les enrichir par la découverte de nouvelles technologies dans le monde de réseautage. Nous nous
sommes familiarisés avec le monde des technologies les plus récentes et les plus populaires.
Au terme de ce PFE, nous avons ainsi réussi à réaliser une solution bien appréciée par l’équipe du
ENIG Page 74
CONCLUSION GENERALE
Support IT & DC d’Ooredoo. Désormais cette solution va permettre à l’entreprise de bénéficier d’un
réel avantage en offrant une solution surtout pour les problèmes d’évolutivité, tout en améliorant le
débit global et la facilité de gestion.
Comme perspective, nous proposons de migrer vers une architecture ACI Multi sites. Cette solution
est basée sur un contrôleur qui gère plusieurs sites à la fois. Dans notre cas, on peut gérer les deux
data centers Charguia et Mghira à partir d’un seul APIC installé dans l’un des deux DCs.
Cette nouvelle technologie est implémentée à partir de la version 3 de l’ACI Cisco c’est à dire qu’elle
n’était pas présente dans les versions 1 et 2.
La gestion des deux data centers via le même contrôleur permettra de faciliter le management des
sites et donnera la possibilité d’administrer les deux sites en même temps.
Un autre avantage gagné par cette technologie, c’est la minimisation des coûts en achetant un seul
contrôleur (redondé) au lieu de deux.
ENIG Page 75
NETOGRAPHIE
[1] [Accès le 14-Mars-2020], adresse :

http ://www.lefigaro.fr/flash-eco/2012/07/26/97002-20120726FILWWW00424-tunisiana-la-tunisie-veut
-ceder-25.php

http ://www.ooredoo.tn/institutionnel/qui-sommenous.

https ://www.lemagit.fr/actualites/2240213369/Reseaux-les-datacenters-migrent-vers-des-topologies
-Leaf-Spine.

https ://www.ciscopress.com/articles/article.asp ?p=2202410&seqNum=4.
[5] [Accès le 20-Juin-2020], adresse :

https ://www.wwt.com/article/comparing-two-tier-three-tier-data-centernetworksfbclid=IwAR1TQzFfB
1TR0_xLqtocDRmirQjFvm5d_xkZF8lwjXwmVSfwnjbSDEkBf4.
[6] [Accès le 3-Juillet-2020], adresse :

https ://www.cisco.com/web/FR/documents/pdfs/datasheet/san/data_sheet_c78-461802.pdf.

https ://www.cisco.com/c/fr_ca/products/switches/nexus-9000-series-switches/index.html.

(http ://www.nyuplanet.eu/ccna/semestre4/course/module1/1.1.2.3/1.1.2.3.html.

http ://fr.security.westcon.com/content/vendors/f5/f5-big-ip-local-traffic-manager-ltm

https ://www.nyuplanet.eu/ccna/semestre4/course/module1/1.1.2.4/1.1.2.4.html
ENIG Page 76
NETOGRAPHIE

https ://www.cisco.com/c/dam/global/fr_fr/assets/documents/pdfs/datasheet/switching/Catalyst3750.pdf

https ://nyuplanet.eu/ccna/semestre2/course/module7/7.1.4.4/7.1.4.4.html

https ://routeur.clemanet.com/hsrp-cisco.php

https ://cisco.goffinet.org/ccna/redondance-de-liens/spanning-tree-rapid-stp-pvst-cisco/

https ://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-software/212589-understanding-
vpc-election-process.html

https ://www.memoireonline.com/09/13/7405/m_Conception-et-deploiement-de-la-technologie-MPLS-dans-
un-reseau-metropolitain6.html

(https ://www.frameip.com/mpls-cisco/#1-8211-introduction-au-protocole-mpls
[18] [Accès le 27-Août-2020], adresse :

https ://www.cisco.com/c/en/us/products/ios-nx-os-software/layer-2-vpns/index.html
[19] [Accès le 01-Septembre-2020], adresse :

https ://www.cisco.com/c/en/us/products/ios-nx-os-software/layer-3-vpns-l3vpn/index.html

https ://networklessons.com/bgp/multiprotocol-bgp-mp-bgp-configuration

https ://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/vrf/design/guide/vrfDesignGuide.html

https ://www.sdxcentral.com/networking/sdn/definitions/inside-sdn-architecture/

https ://www.ajsnetworking.com/cisco-aci-introduction-part-2-the-architecture/
ENIG Page 77
NETOGRAPHIE

https ://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html#CiscoDigital
NetworkArchitectureandSoftwareDefinedAccess

https ://formip.com/dna-center/

https ://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html#ISE

https ://searchnetworking.techtarget.com/definition/Cisco-LISP-Cisco-Locator-ID-Separation-Protocol
ENIG Page 78
ANNEXES
A.1 Fonctionnalités de l’APIC
Nous avons décrit, dans le Etude Préliminaire, les composants clés d’une structure ACI. En fait,
l’APIC est l’un de ces composants, il comprend les fonctions de contrôle suivantes :
Policy Manager : référentiel de politiques distribué responsable de la définition et du déploiement de
la configuration basée sur des politiques de Cisco ACI.
Topology Manager : maintient à jour la topologie ACI et les informations d’inventaire.
Observer : le sous-système de surveillance de l’APIC, servant de référentiel de données sur l’état
opérationnel, la santé et les performances de l’ACI.
Boot Director : contrôle le démarrage et les mises à jour du micrologiciel des commutateurs Spine et
Leaf, ainsi que les éléments du contrôleur APIC.
tAppliance Director : responsable de la formation et du contrôle du cluster d’appliance APIC.
VMM Manager : agit comme un agent entre le référentiel de règles et un hyperviseur et est responsable
de l’interaction avec les systèmes de gestion d’hyperviseur tels que vCenter de VMware.
Event Manager : un référentiel pour tous les événements et défauts initiés à partir de l’APIC ou des
nœuds de Fabric.
Appliance Element : gère l’inventaire et l’état de l’appliance APIC locale.
A.2 Architecture existante du réseau de l’entreprise Ooredoo Tunisie
Comme nous avons déjà citer, que notre architecture est principalement composée de deux DC,un
réseau de backbone ainsi qu’un ensemble des réseaux de campus.
La figure ci-dessous représente l’architecture globale du réseau Ooredoo.
ENIG Page 79
ANNEXES
F IGURE A.1: Architecture globale du réseau Ooredoo
A.3 Architectures logique du réseau data center Mghira, Campus
DSC et Campus DT
Les figures ci-dessous représente les architectures logiques du DC Charguia ainsi que les deux
réseaux de campus DT et DSC.
ENIG Page 80
ANNEXES
F IGURE A.2: Architecture logique du DC Mghira
F IGURE A.3: Architecture logique du réseau de campus DSC
ENIG Page 81
ANNEXES
F IGURE A.4: Architecture logique du réseau de campus DT
ENIG Page 82

Rapport PFE Ikram

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport PFE Ikram

Transféré par

Droits d'auteur :

Formats disponibles

DEDICACES

À mon cher père

À ma chère sœur, à mes chers frères

LISTE DES FIGURES vii

LISTE DES ABREVIATIONS viii

2 État de l’art et Concepts clefs 13

ENIG Page iii

2.2.3.3 RSTP (Rapid Spanning Tree Protocol) . . . . . . . . . . . . . . . 20

3.3.3 Configuration des équipements du Data Center . . . . . . . . . . . . . . . . 44

1.1 Organigramme d’Ooredoo Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Architecture du réseau DC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Architecture simplifiée du réseau Ooredoo . . . . . . . . . . . . . . . . . . . . . . . 39

3.20 Création d’un Serveur Virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

A.1 Architecture globale du réseau Ooredoo . . . . . . . . . . . . . . . . . . . . . . . . 80

ENIG Page vii

ABR : Area Border Router ETR : Egress Tunnel Router

ACI :Application Centric Infrastructure EVPN : Ethernet Virtual Private Network

API :Application Programming Interface FAI : Fournisseur d’Accès Internet

APIC :Application Policy Infrastructure Controller FEX : Fabric Extender

AS : Autonomous System FHRP : First Hop Redundancy Protocols

ASR : Aggregation Services Routers HSRP : Hot Standby Routing Protocol

ATM : Asynchronous Transfer Mode I-BGP :Internal Border Gateway Protocol

BGP : Border Gateway Protocol IEEE :Institute of Electrical and Electronics

CAN :Campus Area Network IGP :Interior Gateway Protocol

CE :Customer Edge IOS :Internetworking Operating System

CLI :Command Line Interface IP :Internet Protocol

CoS :Class of Service IPv4 : Internet Protocolversion 4

CPU :Central Processing Unit IPv6 : Internet Protocolversion 6

CTS :Cisco Trust Security ISE :Identity Service Engine

DC :Data Center IS-IS :Intermediate System- Intermediate

DNA :Digital Network Architecture IT :Information Technology

DNS :Domain Name System ITR :Ingress Tunnel Router

DSC : Direction Services Clients LACP :Link Agregation Control Protocol

DT : Direction Technique LAN :Local Area Network

EID : Endpoint Identifiers LDP : Label Distribution Protocol

ENIG Page viii

LER :Label Edge Routeur QoS : Quality of Service

LISP :Locator Identity Separator Protocol RA : Remote Access

LLDP :Local Link Discovery Protocol RD : Route Distinguisher

LSA :Link State Advertisement REST : Representational State Transfer

LSR :Label Switch Router RLOC : Routing Locators

LTM : Local Traffic Manager RP : Rendezvous-Point

L2VPN : Layer 2Virtual Private Network RR : Route Reflector

MAC : Media Access Control RT : Route Target

MAN : Metropolitan Area Network SaaS : Software as a service

MP-BGP : Multi-Protocol Border Gateway Protocol SD-Access : Software-Defined Access

MPLS : Multiprotocol Label Switching SDN : Software Defined Networking

MR : Map Resolver SGT : Scalable Group Tag

MS : Map Server SI : Système d’Information

MSC : Mobile Switching Center SPB :Shortest Path Bridging

MTU :Maximum Transmission Unit STP : Spanning Tree Protocol

NSSA : Not So Stubby Area SV : Serveur Virtuel

NVE : Network Virtualization Endpoint SVI : Switch Virtual Interface

NX-OS : Nexus Operating System TCO : Total Cost of Ownership

OSPF : Open Shortest Path First TE : Traffic Engineering

OTV : Overlay Transport Virtualization TMOS : Traffic Management Operation System

P : Provider ToR : Top of Rack

PAGP : Port Agregation Protocol TRILL :Transpa- Rent Interconnection of Lots

PE : Provider Edge TTL : Time To Live

PETR : Proxy Egress Tunnel Router UDP : User Datagram Protocol

PIM : Protocol Independent Multicast VLAN : Virtual Local Area Network

PITR : Proxy Ingress Tunnel Router VM : Virtual Machine

PPP : Point-to-Point Protocol VNI : VXLAN Network Identifier