Projet de Fin D'Etudes: Diplôme D'ingénieur D'etat en Génie Télécommunications Et Réseaux

Université Cadi Ayyad
Ecole Nationale des sciences

appliquées -Safi
Département Informatique Réseaux et Télécommunications N° d’ordre : ……/22
PROJET DE FIN D’ETUDES

En vue de l’obtention du
Diplôme d’Ingénieur d’Etat en Génie
Télécommunications et Réseaux
Mise en place d’une application Web de

gestion et d’automatisation du réseau basée
sur la solution Cisco ACI
Effectué à : Réalisé par :
Groupe OCP SA Abdelali GRIF
Présenté le 30/06/2022, devant le Jury :
Mme. H. MESTOURI ENSA de Safi Département IRT Présidente
M. A. ZYANE ENSA de Safi Département IRT Rapporteur
M. R. HAMDAOUI Groupe OCP Service RT Encadrant professionnel
M. A. BENLAMKADEM ENSA de Safi Département IRT Encadrant pédagogique
Année universitaire : 2021/2022

Remerciements
REMERCIEMENTS
Mes sincères remerciements vont aux personnes qui ont contribué de près ou de loin au bon
déroulement et à l’aboutissement de ce projet de fin d’études.
En premier lieu, je tiens à exprimer ma profonde reconnaissance à M. Abdellatif

BENLAMKADEM pour son accompagnement constructif tout au long de mon stage, et aussi
pour sa disponibilité et sa manière de communiquer son savoir-faire.
Mes remerciements vont aussi à M. Radouane HAMDAOUI mon encadrant professionnel

qui a bien voulu assurer la responsabilité de mon stage et qui, surtout, par ses conseils et son
aide précieux, m’a guidé tout au long de mon travail.
Il me serait impossible de ne pas dire un grand MERCI à ma famille : mes chers parents, mon
cher frère, mes chères sœurs et mes amis pour leur soutien et leurs encouragements qu’ils
n’ont pas cessés de me témoigner, tout au long de cette période, parfois très difficile. Il est sûr
que sans leur présence, je ne serais pas arrivé à mener à bout ce projet de fin d’études.
Mes remerciements vont également à M. Nour-Eddine MAAMORI et M. Nabil NOUIGA

pour leur disponibilité et leur soutien, leur générosité en matière d’information et de
formation pendant toute la période de stage.
Je voudrais par la même voix remercier amplement les membres de jury qui ont bien voulu
me faire l’honneur d’évaluer et d’apprécier ce travail.
Page I
Résumé
RESUME
Les technologies sous-jacentes ont été évoluées, mais la gestion des réseaux est demeurée
stagnante pendant des décennies. En général, les réseaux qui sont conçus et entretenus
manuellement ne sont plus efficaces pour répondre aux besoins actuels en termes de rapidité
et facilité de gestion.
Par ailleurs, l’automatisation des ressources réseaux et de la gestion des services apporte aux
équipes opérationnelles de multiples avantages concrétisés par l’agilité et la souplesse. Dans
ce sens le SDN (Sofware-Defined Networking) est présenté comme la solution conçue pour
rendre les infrastructures réseaux plus flexibles et plus faciles à gérer. En effet, cette
technologie assure une gestion centralisée et automatique des équipements réseaux, en
ajoutant un niveau d'abstraction à l’infrastructure. La séparation des parties décisionnelles et
opérationnelles autorise une grande souplesse dans le déploiement, l’évolution et
l’automatisation à travers des API (Interfaces de Programmation d'Applications), notamment les
APIs REST.
A cet égard, le groupe OCP a déployé une nouvelle infrastructure basée sur l'offre CISCO
ACI (Application Centric Infrastructure), comme une solution SDN fourni par CISCO. Cette
solution implique un point de contrôle central s’appelle APIC pour la gestion du réseau. Par
lequel, toutes les opérations du réseau sont effectuées en utilisant une interface qu'il expose.
Cette interface est généralement une API REST et permet la programmation du réseau et
l'intégration avec d'autres systèmes.
L’objectif ultime du présent Projet de fin d’étude est la mise en place d’une application Web
de gestion et d’automatisation du réseau permettant à l’APIC d’effectuer toutes les opérations
du réseau. Afin d’avoir une meilleure mise en place de ce projet, l’application est tenu de
fournir des interfaces faciles à utiliser par l’administrateur réseaux, assurer la réduction de
temps moyen d’exécution des tâches et réduire au maximum la complexité des opérations
effectuée.
Mots-clés : Automatisation des réseaux, SDN, Plan de contrôle distribué, Plan de contrôle
P a g e II
Résumé
centralisé, CISCO ACI, APIC, Spine, Leaf, Application Web, CRUD, API REST, URI.
Page
III
Abstract
ABSTRACT
The underlying technologies have evolved, but network management has remained stagnant
for decades. In general, networks that are manually designed and maintained are no longer
effective in meeting today's needs for speed and manageability.
On the other hand, the automation of network resources and service management brings
multiple benefits to operational teams in terms of agility and flexibility. In this sense, SDN
(Software-Defined Networking) is presented as the solution designed to make network
infrastructures more flexible and easier to manage. Indeed, this technology ensures centralized
and automatic management of network equipment, adding a level of abstraction to the
infrastructure. The separation of the decisional and operational parts allows great flexibility in
deployment, evolution and automation through APIs (Application Programming Interfaces),
especially REST APIs.
In this regard, OCP Group has deployed a new infrastructure based on the CISCO ACI
(Application Centric Infrastructure) offering, as an SDN solution provided by CISCO. This
solution involves a central control point called APIC for network management. Through
which, all network operations are performed using an interface that it exposes. This interface
is usually a REST API and allows the programming of the network and the integration with
other systems.
The ultimate goal of this Final Year Project is the implementation of a Web-based network
management and automation application allowing APIC to perform all network operations. In
order to have a better implementation of this project, the application is required to provide
easy- to-use interfaces for the network administrator, ensure the reduction of average task
execution time and reduce the complexity of the operations performed.
Keywords : Networks automation, SDN, Distributed control plane, Centralized control

plane, CISCO ACI, APIC, Spine, Leaf, Web application, CRUD, REST API, UR
P a g e III
Table des matières
TABLE DES MATIERES

REMERCIEMENTS................................................................................................................................................I
RESUME.................................................................................................................................................................II
ABSTRACT...........................................................................................................................................................III
LISTE DES TABLEAUX.....................................................................................................................................VI
LISTE DES FIGURES........................................................................................................................................VII
LISTE DES ABREVIATIONS ET SYMBOLES...............................................................................................IX
GLOSSAIRE...........................................................................................................................................................X
INTRODUCTION GENERALE............................................................................................................................1
CHAPITRE 1 : PRESENTATION D’ORGANISME D’ACCUEIL ET DE PROJET DE FIN D’ETUDES 3
PARTIE 1 : PRESENTATION D’ORGANISME D’ACCUEIL............................................................................................ 4
1.1 Introduction..............................................................................................................................................4
1.2 Présentation du groupe OCP....................................................................................................................4
1.3 Fiche signalétique....................................................................................................................................5
1.4 Organigramme de l’entreprise.................................................................................................................5
1.5 Service réseaux et télécom RT................................................................................................................6
PARTIE 2 : CONTEXTE GENERAL DU PROJET............................................................................................................... 7
2.1 Contexte général......................................................................................................................................7

2.2 Problématique..........................................................................................................................................7
2.3 Le cahier des charges du projet...............................................................................................................7
2.3.1 Contexte pédagogique.........................................................................................................................7
2.3.2 Les objectifs du projet.........................................................................................................................8
2.4 Charte de projet........................................................................................................................................8
2.5 L’équipe de travail...................................................................................................................................9
2.6 Planification...........................................................................................................................................10
2.7 Conclusion.............................................................................................................................................11
CHAPITRE 2 : PRESENTATION DE LA SOLUTION D’AUTOMATISATION CISCO ACI ET LES
APIs REST.............................................................................................................................................................12
1. Introduction............................................................................................................................................13
2. Software-Defined Networks (SDN)......................................................................................................13
3. Application Centric Infrastructure (ACI)...............................................................................................17
3.1. Application Centric Infrastructure : aperçu général..........................................................................17
3.2. Contrôle déclaratif avec le protocole OpFlex dans ACI...................................................................18
3.2.1 ContrôBle déclaratif & contrôle impératif....................................................................................18
3.2.2 OpFlex dans ACI..........................................................................................................................18
3.3. Architecture matérielle......................................................................................................................19
3.3.1 L’architecture Leaf- Spine............................................................................................................19
3.3.2 Application Policy Infrastructure Controller (APIC)....................................................................23
3.3.3 Modèle de configuration de l’ACI (ACI Policy Model)...............................................................25
4. Les interfaces de programmation d'applications : API..........................................................................31
4.1. Les interfaces de programmation d'applications : aperçu général.....................................................31
P a g e IV
Table des matières
4.2. API-REST..........................................................................................................................................32
4.2.1 Contraintes architecturales REST.................................................................................................33
4.2.2 API REST et HTTP.......................................................................................................................35
4.3. Exemple d'appel d'API REST au serveur APIC de Cisco.................................................................39
4.4. Sérialisation des données et JSON....................................................................................................41
4.4.1 L’envoie des variables d'un programme.......................................................................................41
4.4.2 Comparaison entre les langages de sérialisation des données......................................................42
5. Conclusion.............................................................................................................................................45
CHAPITRE 3 : MISE EN PLACE DE L’APPLICATION DE GESTION ET D’AUTOMATISATION DU
RESEAU.................................................................................................................................................................46
1. Introduction............................................................................................................................................47
2. Etude préalable et discussion des besoins..............................................................................................47
2.1. Critique de l'existant..........................................................................................................................47
2.2. Exemple de création d’une politique : création d’un vlan sous un pool...........................................47
2.2.1. L’ouverture d’une session avec l’ACI..........................................................................................47
2.2.2. Création d’un VLAN sous un VLAN pool...................................................................................49
2.3. Discussion des besoins......................................................................................................................50
2.3.1. Spécification des besoins..............................................................................................................50
2.3.2. Besoins fonctionnels.....................................................................................................................50
2.3.3. Besoins non fonctionnels..............................................................................................................51
3. Conception de l’application...................................................................................................................51
3.1. Diagramme de cas d'utilisations........................................................................................................51
3.1.1. Cas d’utilisation de menu ACI......................................................................................................52
3.1.2. Cas d’utilisation de menu Gestion................................................................................................53
3.2. Diagramme de séquence....................................................................................................................54
3.2.1. Le diagramme de séquence « Authentification »..........................................................................54
3.2.2. Le diagramme de séquence « Création d’un VLAN sous un pool »............................................55
4. Mise en place de l’application...............................................................................................................56
4.1. Technologies de développement........................................................................................................56
4.1.1. Outils techniques...........................................................................................................................56
4.1.2. Technologies et Framework..........................................................................................................57
4.2. Déploiement de l’application.............................................................................................................58
4.2.1. Déploiement classique...................................................................................................................58
4.2.2. Déploiement distribué...................................................................................................................58
4.3. GRIFAPIC : une application Web d’automatisation et de gestion de réseaux..................................58
4.3.1. La page d’authentification.............................................................................................................59
4.3.2. Menu Dashboard...........................................................................................................................59
4.3.3. Menu ACI.....................................................................................................................................61
4.3.4. Menu Gestion................................................................................................................................66
5. Conclusion.............................................................................................................................................66
CONCLUSION GENERALE...............................................................................................................................67
BIBLIOGRAPHIE................................................................................................................................................69
ANNEXE 1.............................................................................................................................................................71
ANNEXE 2.............................................................................................................................................................72
ANNEXE 3.............................................................................................................................................................73
Page V
Liste des tableaux
LISTE DES TABLEAUX

Tableau 1: Fiche Signalétique de OCP SA..............................................................................................................5
Tableau 2: Charte du projet......................................................................................................................................9
Tableau 3: Equipe de travail...................................................................................................................................10
Tableau 4: Comparaison des actions CRUD et des verbes HTTP.........................................................................37
P a g e VI
Liste des figures
LISTE DES FIGURES

Figure 1: Organigramme de siège de Casablanca [3]...............................................................................................6
Figure 2: Organigramme du service RT...................................................................................................................6
Figure 3: Diagramme Gantt du projet de fin d’étude.............................................................................................10
Figure 4: Centralisation de contrôle [5]..................................................................................................................14
Figure 5: Routage de paquets avec le protocole OpenFlow [6].............................................................................14
Figure 6: Exemple de processus d'un GET utilisant une API REST [7]................................................................16
Figure 7: Vue d'ensemble d'ACI [8].......................................................................................................................17
Figure 8: Conception d'un réseau Spine-Leaf [10].................................................................................................19
Figure 9: Connexion des end-points dans une architecture Leaf-Spine [11].........................................................20
Figure 10: Normalisation de l'encapsulation ACI [14]...........................................................................................22
Figure 11: Le contrôleur centralisé de l’ACI [15]..................................................................................................23
Figure 12: Transformation du modèle logique vers le modèle concret [14]..........................................................23
Figure 13: Contrôler l’ACI à l'aide de l'APIC [15]................................................................................................24
Figure 14: Modèle de configuration [14]...............................................................................................................25
Figure 15: L'arbre d'information de gestion (MIT) [14].........................................................................................26
Figure 16: Le MO Tenant et ses enfants [14].........................................................................................................27
Figure 17: Les politiques du Tenant pour une simple application Web.................................................................27
Figure 18: Les objets access policy [8]..................................................................................................................30
Figure 19: Association d’EPGs aux access policies [8].........................................................................................31
Figure 20: Opération Client / Serveur avec REST [17]..........................................................................................33
Figure 21: Verbe HTTP et URI dans un en-tête d’une requête [18]......................................................................36
Figure 22: Une requête API REST qui demande une ressource spécifique à travers l’URI [18]..........................38
Figure 23: Structure d’un URI pour une requête REST GET [18].........................................................................38
Figure 24: Structure d’un URI pour une requête REST GET avec des paramètres supplémentaires [17]............39
Figure 25: Appel d'API REST au serveur APIC de Cisco à l’aide de Postman.....................................................40
Figure 26: Échange de représentations internes de variables [17].........................................................................41
Figure 27: Réponse JSON d'une requête API REST..............................................................................................42
Figure 28: Sortie XML d'un appel d'API REST.....................................................................................................44
Figure 29: Fichier YAML utilisé par Ansible........................................................................................................45
Figure 30: Préparation de requête d’authentification..............................................................................................48
Figure 31: Réponse d’authentification du serveur APIC........................................................................................48
Figure 32: Création de vlan sous un pool...............................................................................................................49
Figure 33: Cas d’utilisation de menu ACI..............................................................................................................52
Figure 34: Cas d’utilisation de menu Gestion........................................................................................................53
P a g e VII
Liste des figures
Figure 35: Diagramme de séquence d’Authentification à l’application.................................................................54

Figure 36: Diagramme de séquence de Création d’un VLAN sous un pool..........................................................55
Figure 37: Page d’authentification à l’application..................................................................................................59
Figure 38: Menu Dashboard, synchronisation avec l’ACI.....................................................................................60
Figure 39: Liste des Tenants et domaines physiques..............................................................................................61
Figure 40: Association d’un vlan pool à un domaine physique..............................................................................62
Figure 41: Interfaces de création d’un ou plusieurs VLANs sous un pool............................................................62
Figure 42: Interface de création d’un BD sous un VRF.........................................................................................63
Figure 43: Interface de création d’un EPG.............................................................................................................64
Figure 44: Interfaces d’ajout d’un port statique à un EPG.....................................................................................64
Figure 45: Interface Wizard....................................................................................................................................65
Figure 46: Interface de gestion des équipements réseaux......................................................................................66
Figure 47: Interface de gestion des utilisateurs......................................................................................................66
Figure 48: Organigramme du groupe OCP.............................................................................................................71
P a g e VIII
Liste des abréviations et symboles
LISTE DES ABREVIATIONS ET SYMBOLES

AAEP Attachable Access Entity Profile SSL Secure Socket Layer
ACI Application Centric Infrastructure UDP User Datagram Protocol
API Application Programming Interface TCP Transmission Control Protocol
APIC Application Policy Infrastructure Controller URI Uniform Resource Identifier
BD Bridge Domain VLAN Virtual Local Area Network
CLI Command-line interface VNID VXLAN Network Identier
CRUD Create Read Update Delete VRF Virtual Routing and Forwarding
DN Distinguished Name VTEP VXLAN Tunnel Endpoints
DNA Digital Network Architecture VXLAN Virtual Extensible Local LAN
EPG End-Point Group WWW World Wide Web
HTML Hypertext Markup Language XML eXtensible Markup Language
HTTP Hypertext Transfer Protocol YAML YAML Ain’t Markup Language
HTTPS Hypertext Transfer Protocol Secure
IP Internet Protocol
IR Infrastructures Réseaux
IS-IS Intermediate System to Intermediate System
IT Information Technology
JSON JavaScript Object Notation
MAC Medium Access Control
MIT Management Information Tree
MO Management Object
NBI Northbound Interface
OCP Office Chérifien des Phosphates
REST REpresentational State Transfer
SBI Southbound Interface

SDN Sofware-Defined Networking
P a g e IX
Glossaire
GLOSSAIRE
ACI
un centre de données Cisco qui utilise
La solution SDN pour centre de données de
l'approche ACI.
Cisco, les concepts de définition de politiques
que le contrôleur APIC transmet ensuite aux CRUD
commutateurs du réseau à l'aide du protocole Dans le développement de logiciels, un
OpFlex, le plan de contrôle partiellement acronyme qui fait référence aux quatre actions
distribuer de chaque commutateur créant les les plus courantes effectuées par un programme
entrées de la table de transfert pour prendre en : Créer, Lire, Mettre à jour et Supprimer.
charge les politiques apprises du contrôleur. Il
prend également en charge une GUI, une CLI OpenFlow
et des API. Le standard ouvert pour le Software-Defined
Networking (SDN) tel que défini par l'Open
Ansible Networking Foundation (ONF).
Une application de gestion de configuration
populaire, qui peut être utilisée avec ou sans OpFlex
serveur, utilisant un modèle de poussée pour Le protocole sud utilisé par le contrôleur Cisco
déplacer les configurations dans les dispositifs, ACI et les commutateurs qu'il contrôle
avec de fortes capacités pour gérer les
REST
configurations des périphériques réseau
Un type d'API qui permet à deux programmes
API qui qui résident sur des ordinateurs distincts de
Un mécanisme logiciel qui permet aux communiquer, avec un ensemble de six
composants de communiquer entre eux attributs API primaires tels que définis au
début de ce siècle par son créateur, Roy
API RESTfull Fielding. Ces attributs sont l'architecture
Toute API qui utilise les règles du REST client/serveur, le fonctionnement sans état, la
possibilité d'être caché, les interfaces
APIC
uniformes, les couches et le code à la demande.
Le logiciel qui joue le rôle de contrôleur, en
contrôlant les flux que les commutateurs créent
pour définir où les trames sont transmises, dans
Page X
Introduction générale
INTRODUCTION GENERALE
Dans le modèle traditionnel d'exploitation et de contrôle des réseaux, les ingénieurs réseau
configurent manuellement divers appareils et apportent des modifications. Ils sont
responsables de la planification et de la mise en œuvre de la configuration distribuée des
appareils, appareil par appareil, pour implémenter le réseau. Cela nécessite un long délai pour
planifier et mettre en œuvre les changements. Aujourd'hui, tous les départements
informatiques sont sous pression pour fournir aux clients finaux une plus grande agilité et de
meilleures performances. Par exemple, les entreprises veulent que l'infrastructure lance de
nouvelles applications le plus rapidement possible. Pour y répondre, l'infrastructure doit
s'adapter rapidement et automatiquement aux besoins applicatifs.
L'automatisation des réseaux élimine les étapes manuelles de gestion des services, telles que
la connexion aux routeurs et commutateurs pour modifier la configuration avant de se
déconnecter. Elle permet aux ingénieurs réseau et les opérateurs de mettre en œuvre les
changements plus rapidement, avec une meilleure cohérence et meilleures pratiques
opérationnelles.
Les années 2010 ont vu l'introduction d'un nouveau modèle opérationnel de réseau : le
Software Defined Networking (SDN). Le SDN est une approche visant à rendre les réseaux
plus flexibles et plus agiles à travers le découplage du plan de contrôle sur le plan de données.
À ce jour, le SDN est mondialement reconnu comme une architecture qui permet aux
applications de programmer le réseau pour accélérer son déploiement et d’offrir une meilleure
visibilité sur le réseau. Il n'existe donc pas de SDN unique. Chaque fournisseur conçoit son
SDN en fonction de ses propres intérêts [1].
Le 31 juillet 2014, Cisco a présenté sa solution logicielle de mise en réseau de centres de

données : Application Centric Infrastructure [2]. ACI a entrepris de créer un réseau de centre
de données avec la flexibilité et l'automatisation intégrées au modèle opérationnel. Dans ce
modèle, les politiques sont envoyées d'un contrôleur qui s’appelle APIC, aux dispositifs de
mise
Page 1
Introduction générale
en réseau, ces derniers étant chargés de les mettre en œuvre. En particulier, les contrôleurs
permettent aux programmes de configurer et d'exploiter automatiquement les réseaux par le
biais d'interfaces de programmation d'applications (API) puissantes.
Dans ce cadre, le groupe OCP a déployé une nouvelle infrastructure basée sur l'offre CISCO
ACI. Alors, selon le contexte de stage effectué au sein de service réseau du siège social du
groupe OCP, l’objectif du présent projet est la mise en place d’une application Web
d’automatisation et de gestion de réseau adaptée à la solution CISCO ACI. Cette application
Web présente l’interface utilisé pour effectuer toute les configurations au niveau du contrôleur
ACI, par son API REST (Representational State Transfer). La rapidité, la disponibilité et la
simplicité d’utilisation, sont les conditions que l’application doit assurer, pour arriver à une
meilleure implémentation du projet.
Ce rapport présente le travail effectué sous forme de trois chapitres.
Le premier chapitre est dédié premièrement à la présentation de l’entreprise d’accueil.

Nous allons par la suite détailler le contexte général de projet, en déterminant la
problématique, le cahier de charge et la méthodologie à suivre afin d’atteindre les
objectifs fixés.
Le deuxième chapitre, est entamé par une présentation du Software Defined

Networking (SDN). Par la suite, nous allons traiter d’une manière détaillée la solution
d’automatisation CISCO ACI. Finalement ce chapitre va se concentrer sur les interfaces
API REST.
En dernier chapitre, nous aborderons la mise en place de l’application Web. Pour cela,
nous allons commencer par la détermination des besoins à travers une étude de
l’existant. Par la suite, on va se focaliser sur la conception à l’aide des outils UML et la
présentation des technologies utilisées, afin d’arriver à l’explication des différentes
interfaces de l’application réalisée.
Page 2
Chapitre I
Présentation d’organisme d’accueil et de projet de

fin d’études
Les objectifs principaux de ce premier chapitre sont de présenter des généralités

sur l’’organisme d’accueil. Nous allons détailler par la suite la problématique et
le contexte général du projet, en définissant son cahier de charge et la
méthodologie adoptés afin d'atteindre les objectifs fixés.
Chapitre I : Présentation de l’organisme d’accueil et de PFE
Partie 1 : Présentation d’organisme d’accueil

1.1 Introduction
Le présent projet concerne la mise en place d’une application Web d’automatisation du

réseau. Avant de s’immerger dans le cœur du projet, ce premier chapitre a pour but une
présente globale de l’environnement et du contexte du travail. Nous entamons ce premier
chapitre par une présentation générale de l’organisme d’accueil. Nous allons par la suite
détailler la problématique et le contexte général du projet en définissant son cahier de charge
et la méthodologie adoptés afin d'atteindre les objectifs fixés.
1.2 Présentation du groupe OCP
Le groupe L’Office Chérifien des Phosphates est l’un des leaders mondiaux sur le
marché du phosphate et des produits dérivés. Il est un acteur de référence incontournable sur
le marché international depuis sa création en 1920 [3]. Présent sur toute la chaine de valeur,
l’OCP extrait, valorise et commercialise du phosphate et des produits dérivés, acide
phosphorique et engrais. Il est le premier exportateur mondial de roches et d’acide
phosphorique, et l’un des plus importants producteurs d’engrais. L’OCP maîtrise toute la
chaîne de création de valeur de l’industrie phosphatière : extraction et traitement du minerai,
transformation de cette matière première en un produit liquide intermédiaire : l’acide
phosphorique, et fabrication des produits finis par concentration et granulation de cet acide ou
par purification : engrais et acide phosphorique purifié. La variété et la qualité des sources des
phosphates contenus dans le sous- sol marocain, parmi les plus importantes au monde,
assurent la richesse de la gamme de produits offerts par OCP. Sa stratégie commerciale repose
notamment sur un portefeuille de produits innovants et de qualité, adaptés à la diversité des
sols et des variétés végétales. Sa capacité industrielle massive, couplée à la flexibilité de son
appareil productif, lui assure une structure de coûts optimale.
 Présence mondiale
L’OCP a des filiales dispatchées dans les différents coins dans les cinq continents du
monde. Ses filiales sont bel et bien des bureaux OCP, des bureaux pour les représentations
commerciales ou bien des unités de production.
 Présence nationale
Le groupe OCP a plusieurs sites situés aux différents emplacements du royaume,
Page 4
Casablanca, Jorf Lasfar, Safi, Khouribga, Benguerir, Youssoufia, Laâyoune et Boucraâ. Ces
sites sont principalement des unités d’extraction (sites miniers), ou bien des unités de
transformations chimiques (production d’acide phosphoriques, d’engrais, laverie …).
1.3 Fiche Signalétique
La fiche signalétique est la carte d’identité de l’entreprise. La fiche signalétique de OCP

SA est présentée dans le tableau 1.
Tableau 1: Fiche Signalétique de OCP SA.
Raison sociale OCP SA

Date de création Office Chérifien des Phosphates : 7 août 1920
OCP SA : La loi n° 46-07 promulguée le 26 février 2008
porte transformation de l’Office Chérifien des
Phosphates en
société anonyme.
Activité Production, extraction et commercialisation de phosphate et
produits dérivés
Forme juridique Société anonyme
Capital 8 287 500 000 MAD
Siège social 2, Rue Al Abtal, Hay Erraha, Casablanca
Téléphone +212 522231753
1.4 Organigramme de l’entreprise
La dimension organisationnelle au sein de Groupe OCP SA se caractérise par un dosage

équilibré entre la structure fonctionnelle et celle opérationnelle, ce qui justifie l’organisation
de l’entreprise en plusieurs départements. L’organigramme du groupe OCP SA est présenté
dans l’annexe 1.
Ce stage a été effectué au sein du siège social du groupe OCP dans le service réseaux et
télécoms. La figure 1 représente l’organigramme de la direction du siège de Casablanca.
Page 5
Figure 1: Organigramme de siège de Casablanca [3].
1.5 Service Réseaux et télécom RT
Le service réseaux et télécom englobe quatre filiales, sous la direction de monsieur EL

GONNOUNI Abdeslam. La figure suivante représente L’organigramme du service RT.
Figure 2: Organigramme du service RT
Le rôle principal da la filiale Infrastructures réseaux IR est d’assurer que les

infrastructures réseaux réponds bien aux besoins demandés. Une infrastructure réseau a pour
objectif de centraliser les données de l’entreprise afin de simplifier leur échange sécurisé et la
communication entre les agents.
Page 6
Partie 2 : Contexte général du projet
2.1 Contexte général
Les technologies sous-jacentes ont en grande partie évolué, mais la gestion des réseaux
est demeurée stagnante pendant des décennies. En général, les réseaux sont conçus et
entretenus manuellement. Cependant, les approches traditionnelles et manuelles de
configuration et d'actualisation des réseaux à ce jour sont lentes et sujettes à l'erreur. Par
conséquent, ils ne sont pas efficaces pour répondre aux demandes d'une charge de travail en
constante évolution. L'automatisation des ressources réseaux et de la gestion des services
permet aux équipes opérationnelles de réseau de gagner en agilité et en souplesse, tout en
satisfaisant de manière efficace les exigences des entreprises modernes.
2.2 Problématique
Dans le cadre d’automatisation des réseaux le Sofware-Defined Networking (SDN) est

présenté comme la solution conçue pour rendre les infrastructures réseaux plus flexibles et
plus faciles à gérer. Cette technologie rend possible une gestion centralisée et automatique des
équipements réseaux. Le groupe OCP a déployé une nouvelle infrastructure basée sur l'offre
CISCO ACI (Application Centric Infrastructure), comme une solution SDN fournie par
CISCO.
Sous la lumière de cette solution d’automatisation, Le service réseaux du siège d’OCP a

décidé de mettre en place une application de gestion et d’automatisation du réseau. Et en tant
qu’un stagiaire au sein de ce service, je vais travailler sur la mise en place de cette application
Web qui a pour but d’automatiser les créations des objets d’ACI.
Le développement de cette application Web a pour but de résoudre les problèmes de

complexité et de rapidité.
2.3 Le cahier des charges du projet
2.3.1 Contexte pédagogique
Ce projet est un pré requis d’obtention du diplôme en Génie Télécommunication et

Réseaux en liant entre ce que nous avons appris au cours de nos études d’une part, et ce que
nous avons appris au domaine de travail d’autre part.
Page 7
2.3.2 Les objectifs du projet
Le besoin exprimé par notre service est la mise en place d’une application Web de
gestion et d’automatisation du réseau en vue de faciliter le travail de l’administrateur réseau et
obtenir un meilleur contrôle et une visibilité optimale sur les ressources réseau.
Pour une meilleure mise en place du ce projet, on doit aborder les points suivants :
- Assurer l’authentification et l’échange avec l’ACI.

- Fournit une interface Web claire et facile à utiliser.
- Automatiser les actions de créations des objets d’ACI.
- Distribuer rapidement et facilement des services à grande échelle.
- Réduire le temps moyen de résolution des interruptions de service.
- Augmenter la disponibilité du réseau.
2.4 Charte de projet
Après avoir répondu aux principales questions à citer : Quel est l’objectif que l’on
recherche ? Quel est le planning ? Il s’avère primordial de rédiger la charte de projet, qui se
veut un aperçu détaillé du projet, permet à toutes les parties concernées (intervenants) de
parvenir à une entente et de décrire les principaux aspects comme les objectifs, la portée et les
ressources nécessaires [4]. Le tableau 2 présente la charte de notre projet.
Page 8
Tableau 2: Charte du projet.
Date : 12/04/2022
Charte du projet
Page : 1/1
Nom du projet : la mise en place d’une application Web de gestion et d’automatisation du

réseau.
Objectifs de projet :
 Automatisé les actions de création et modifications des objets d’ACI ;
 Facilité le travail de l’administrateur réseau ;
 Fournit une interface Web claire et facile à utiliser ;
 Distribuer rapidement et facilement des services à grande échelle ;
 Augmenter la disponibilité du réseau ;
 Réduire le temps moyen de résolution des interruptions de service ;
Date début : 01/03/2021 Date fin : 01/07/2021

Les étapes de réalisation :
Etape 1. Documentation sur la solution d’automatisation CISCO ACI ;
Etape 2. Définir les éléments à automatiser (le besoin) ;
Etape 3. Choix des outils nécessaires (langage de développement, framework, serveur, …)
et adéquates pour notre application ;
Etape 4. Créations des menus de l’application.
Etape 5. Test et confirmation ;
Etape 6. Amélioration ;
Maître d'ouvrage : Maître d'œuvre :
Monsieur Radouane HAMDAOUI : Monsieur Abdellatif BENLAMKADEM :
Analyste Senior au sein de service Encadrant pédagogique à l’Ecole Nationale de
Réseaux et Télécoms. Sciences Appliquées.
2.5 L’équipe de travail
Afin de garantir le bon déroulement de n’importe quel projet, il faut s’assurer dans un
premier lieu d’une organisation rigoureuse et efficace de l'équipe projet. Pour cela, après avoir
lancé le projet, une équipe a été construite. Cette équipe est composée de membres de
Page 9
différentes compétences. Le tableau 3 présente la profession et le rôle de chaque membre de

l’équipe de projet.
Tableau 3: Equipe de travail.
Membre Profession Rôle

MAAMORI Nour-Eddine Manager Superviseur du projet
HAMDAOUI Radouane Senior Analyst Encadrent du projet
NOUIGA NABIL Administrateur DB Conseiller
GRIF Abdelali Ingénieur stagiaire Réalisateur du projet
2.6 Planification
Afin de garantir un bon déroulement du projet et permettre un suivi permanent de

l’avancement du travail, un planning des tâches principales est mis au point en utilisant le
diagramme Gantt (Figure 3), dans lequel sont représentées et classées toutes les étapes
principales par lesquelles passera le projet.
Figure 3: Diagramme Gantt du projet de fin d’étude.
P a g e 10
2.7 Conclusion
Ce chapitre introductif est une mise dans le contexte du projet. Nous avons donné un
aperçu général sur l’organisme d’accueil. Ensuite, nous avons présenté le cadre général du
projet y compris la problématique et la démarche que nous allons utiliser lors du traitement de
notre sujet. Le chapitre suivant, portera principalement sur l’état de l’art de la solution
d’automatisation CISCO ACI et les besoins théoriques nécessaires sur les APIs RESTpour la
réalisation de notre application Web.
P a g e 11
Chapitre II
Présentation de La solution d’automatisation CISCO

ACI et les APIs REST
Ce chapitre, portera principalement sur l’état de l’art de la solution

d’automatisation CISCO ACI et les besoins théoriques nécessaires sur les
APIs précisément les APIs REST.
Chapitre II : La solution Cisco ACI et les API REST
1. Introduction
Aujourd'hui, tous les services IT subissent des pressions pour offrir une plus grande
souplesse et un meilleur rendement aux clients finaux. Pour répondre à ces besoins, les
infrastructures doivent s'adapter de manière rapide et automatique aux besoins applicatifs.
C'est pourquoi le Software Defined Networking (SDN) a vu le jour.
L’objectif principal de ce chapitre, est de présenter en premier lieu le SDN, et traiter par
la suite Cisco ACI comme une solution SDN fournie par CISCO. Finalement nous allons se
concentre sur les interfaces de programmation d'applications (API), plus précisément les API
REST (Representational State Transfer).
2. Software-Defined Networks (SDN)
Au cours des dix dernières années, les réseaux définis par logiciel (SDN) et la
programmabilité ont introduit une approche différente de la construction et de la gestion des
réseaux informatiques. Le SDN est une approche visant à rendre les réseaux plus flexibles et
plus agiles. La fondation Open Networking a initialement défini le SDN comme une solution
qui dissocie le plan de contrôle et le plan de données, permettant au plan de contrôle de
devenir directement programmable [6].
A ce jour, le SDN est mondialement reconnu comme une architecture qui ouvre le
réseau aux applications. Celle-ci intègre les deux aspects suivants : permettre aux applications
de programmer le réseau pour accélérer son déploiement ; offrir une meilleure visibilité sur le
réseau. Il n'existe donc pas de SDN unique avec une solution ou un protocole unique. Chaque
fournisseur conçoit son SDN en fonction de ses propres intérêts. Un SDN implique
généralement un point de contrôle central pour la gestion du réseau appelé contrôleur, par
lequel, toutes les opérations du réseau sont effectuées soit en utilisant une interface graphique,
soit une interface qu'il expose. (Voir figure 4). Cette interface (Northbound API) est
généralement une API REST qui permet la programmation du réseau et l'intégration avec
d'autres systèmes. De même, le contrôleur communique avec les périphériques du réseau au
moyen d'une interface appelée "Southbound API", En utilisant des protocoles tels que
OpenFlow, RESTCON et OpFlex.
P a g e 13
Figure 4: Centralisation de contrôle [5].
 Le contrôleur SDN
Un contrôleur, ou contrôleur SDN, centralise le contrôle des périphériques réseau. Le

degré de contrôle, et le type de contrôle, varient considérablement. Par exemple, le contrôleur
peut exécuter toutes les fonctions du plan de contrôle, remplaçant le plan de contrôle distribué
des dispositifs.
En effet, Un contrôleur centralisé contrôle tous les périphériques du réseau, qui sont
chargés de transmettre les paquets d'une interface à une autre selon des règles établies. Pour
cela, le SDN s'appuie sur différents protocoles dont le plus connu est OpenFlow. Ces
protocoles permettent la communication entre les contrôleurs et les périphériques réseau.
Figure 5: Routage de paquets avec le protocole OpenFlow [6].

P a g e 14
La figure 5, montre le routage des paquets entre deux réseaux distants via une
implémentation SDN utilisant le protocole OpenFlow. Dans l'approche SDN, la charge de
calcul associée au contrôle est largement supprimée du routeur. Le routeur différencie le
paquet et détermine qu'il sort de l'interface, mais ce comportement provient des règles
publiées par le contrôleur.
En mode réactif, un routeur qui reçoit un paquet de l'expéditeur envoie un signal

d'événement au contrôleur et reçoit des règles en retour lors de l'échange afin de décider de la
transmission au prochain routeur approprié. Un comportement proactif comprendrait la
transmission des règles avant que le routeur ne reçoive les paquets pertinents.
Par conséquent, les routeurs remplissent essentiellement des fonctions de commutation,

d'où le nom de "commutateurs OpenFlow". OpenFlow utilise divers critères pour identifier
des flux spécifiques, puis effectuer des actions sur ces flux. Un contrôleur OpenFlow
centralisé connaissant l'ensemble de la topologie du réseau peut programmer ces politiques
pour tous les commutateurs du réseau.
 L'interface Southbound (SBI)
Dans une architecture de réseau basée sur un contrôleur, le contrôleur doit

communiquer avec les périphériques de réseau. Ces périphériques réseau se trouvent
généralement sous le contrôleur, comme il est montré dans la Figure 4. Il existe une interface
entre le contrôleur et ces périphériques, cette interface est connue sous le nom (southbound
interface) ou SBI.
 L'interface Northbound (NBI)
En fournissant une interface ouverte Northbound, le SDN offre un mode d'exploitation

différent des réseaux. Il permet aux ingénieurs réseau de programmer le réseau à l'aide de
scripts ou d'outils d'automatisation.
L'interface Northbound (NBI) d'un contrôleur ouvre le contrôleur afin que ses données
et ses fonctions puissent être utilisées par d'autres programmes, permettant la programmation
du réseau, avec un développement beaucoup plus rapide. Les programmes peuvent extraire
des informations du contrôleur en utilisant les APIs de ce dernier. Les NBIs permettent
également aux programmes d'utiliser les capacités du contrôleur pour programmer des flux
dans les dispositifs en utilisant les SBIs du contrôleur.
P a g e 15
Pour bien comprendre le sujet des NBI, voici une brève explication d'une API REST
utilisée pour un contrôleur. REST (Representational State Transfer) décrit un type d'API qui
permet aux applications de s'installer sur différents hôtes, en utilisant des messages HTTP
pour transférer des données sur l'API. Lorsque l'application s'exécute sur un système différent,
quelque part dans le réseau, et non sur le contrôleur, l'API a besoin d'un moyen d'envoyer les
données dans les deux sens sur un réseau IP, et les API REST répondent à ce besoin. La
figure 6 illustre les grandes idées avec une API REST. L'application s'exécute sur un hôte
situé en haut de la figure 6. Dans ce cas, à l'étape 1, elle envoie une requête HTTP GET à un
URI particulier (Les concepts de GET et d'URI seront expliqués plus loin dans ce chapitre).
Toutefois, l'URI ne correspond pas à une page Web, mais identifie plutôt un objet du
contrôleur, généralement une structure de données que l'application doit apprendre puis
traiter. Par exemple, l'URI peut identifier un objet qui est la liste des interfaces physiques d'un
périphérique spécifique ainsi que l'état de chacune d'elles.
Figure 6: Exemple de processus d'un GET utilisant une API REST [7].
À l'étape 2, le contrôleur renvoie un message de réponse HTTP GET avec l'objet. La

plupart des API REST demandent et reçoivent des données structurées. C'est-à-dire qu'au lieu
de recevoir des données qui sont une page Web, comme le ferait un navigateur Web, la
réponse contient des noms de variables et leurs valeurs, dans un format qui peut facilement
être utilisé par les utilisateurs. Les formats courants de données utilisés pour la
programmation du réseau sont JavaScript Object Notation (JSON) et eXtensible Markup
Language (XML).
P a g e 16
3. Application Centric Infrastructure (ACI)
3.1. Application Centric Infrastructure : aperçu général
Le 31 juillet 2014, Cisco a présenté sa solution logicielle de mise en réseau de centres

de données : Cisco Application Centric Infrastructure ACI. Cette section donne un aperçu de
l'ACI [2].
Lorsqu'ils repensent la mise en réseau du centre de données, les concepteurs d’ACI se

concentrent sur les applications exécutées dans le centre de données et leurs exigences. Ils ont
donc construit leurs concepts de mise en réseau autour des architectures applicatives. D'où le
nom 'Application Centric Infrastructure'. L'ACI est illustré à la figure 7.
Figure 7: Vue d'ensemble d'ACI [8].
L'ACI est basé sur un modèle de politique qui dissocie la conception du réseau de
l'infrastructure physique et se concentre sur les besoins (réseau, sécurité et services) des
applications, et permet aux exigences des applications d'être définies comme des politiques.
Dans l'ACI, chaque aspect de la congestion du réseau est défini par des politiques qui
décrivent comment le système doit se comporter.
P a g e 17
Les deux principaux composants de l'ACI sont les commutateurs Nexus L3 câblés selon
une topologie en forme Leaf-Spine pour l'infrastructure de commutation physique,
et l'Application Policy Infrastructure Controller (APIC) pour la gestion centralisée du réseau
et la surveillance en temps réel de son état. L'APIC expose les fonctionnalités de la structure
ACI par le biais d'une API REST prenant en charge les payloads JSON et XML, et permet
l'intégration avec les logiciels de cloud computing (par exemple Google Cloud Platform,
AWS), les logiciels de virtualisation (par exemple VMware vCenter) et les logiciels
d'automatisation (par exemple Terraform, Ansible). Les ingénieurs peuvent également
communiquer avec l'APIC par le biais d'une interface graphique Web offrant une vue
d'ensemble de la structure ACI ou par le biais de scripts personnalisés.
3.2. Contrôle déclaratif avec le protocole OpFlex dans ACI
3.2.1 Contrôle déclaratif & contrôle impératif
Dans un système de contrôle impératif, le contrôleur reçoit les demandes de l'API nord
et indique aux périphériques du réseau comment ils doivent être configurés. En d'autres
termes, le contrôleur indique explicitement aux commutateurs comment gérer le trafic réseau
en leur envoyant les commandes ou instructions exactes pour effectuer le changement. Le
protocole Openflow utilise une approche impérative.
Le contrôle déclaratif utilise les concepts de la théorie des promesses, un modèle basé
sur des objets intelligents qui prennent en charge les changements d'état de la configuration
initiés par un contrôleur central. Ces objets intelligents sont également chargés d'informer le
système central des anomalies et des exceptions. Dans la commande déclarative, le contrôleur
demande aux commutateurs d'atteindre un état souhaité, mais ne leur dit pas précisément
comment le faire. Dans son sens, OpFlex est un système axé sur les politiques utilisé pour
gérer un grand nombre de dispositifs. Il fonctionne en abstrayant les politiques et s'appuie sur
des dispositifs intelligents et autonomes pour les interpréter, d'où le contrôle déclaratif.
3.2.2 OpFlex dans ACI
Le modèle ACI et le contrôleur d'infrastructure de politique d'application (APIC)

adoptent une approche déclarative. Nous avons créé un modèle d'abstraction entre les
applications, l'infrastructure et les opérations qui permettra la simplicité et l'agilité que tout le
monde attend. La résilience est également prise en compte, la perte du contrôleur n'empêche
pas la poursuite de la commutation des données. Ce modèle déclaratif doit être capable de
fonctionner dans un environnement multifournisseur pour transformer et appliquer les
P a g e 18
définitions de politiques à
P a g e 19
travers l'infrastructure. Il n'existe actuellement aucun protocole standard sur tous les
commutateurs physiques et virtuels, les routeurs et les services réseau des couches 4 à 7 pour
y parvenir. Et c'est ce vide qui a conduit au développement de "OpFlex" [9].
3.3. Architecture matérielle
La solution ACI s'appuie sur l'Application Policy Infrastructure Controller (APIC)

redondant d'une part, qui gère un point unique de provisionnement, de configuration, de
déploiement et de monitoring, et d'autre part sur l'infrastructure Leaf/Spine.
L'architecture Leaf-Spine est devenue la norme dans le déploiement actuel des réseaux
de centres de données, en surmontant certaines des limites des architectures traditionnelles.
Cette section se concentre sur l'architecture physique de l’ACI, explique pourquoi la

topologie de la Leaf-Spine a été choisie, et décrit brièvement les façons dont l'ACI peut être
déployé.
3.3.1 L’architecture Leaf- Spine
L'architecture leaf-Spine, comme son nom l'indique, comprend des commutateurs Spine
et Leaf. L’infrastructure de type Fabric Leaf-Spine composée de commutateurs de la série
Nexus 9000. Tous les appareils de la fabrique sont connectés via une liaison 40G, qui peut
être mise à niveau vers 100G. Dans cette conception, comme la figure 8 montre :
- Chaque commutateur Leaf est connecté à chaque commutateur Spine.

- Les commutateurs Leaf ne sont pas connectés les uns aux autres.
- Les commutateurs Spine ne sont pas connectés les uns aux autres.
- Les points d'extrémité (End-points) se connectent uniquement aux commutateurs Leaf.
Figure 8: Conception d'un réseau Spine-Leaf [10].
P a g e 20
Les End-points se connectent uniquement aux commutateurs Leaf et jamais aux

commutateurs Spine. Pour souligner ce point, la Figure 9, montre une version plus détaillée,
cette fois avec des end-points connectés aux commutateurs Leaf. Les points d'extrémité
peuvent être des connexions à des périphériques extérieurs au centre de données, comme le
routeur à gauche. Dans l’ACI, un contrôleur APIC est considéré comme un end-point, il est
donc connecté à un commutateur Leaf.
Figure 9: Connexion des end-points dans une architecture Leaf-Spine [11].
 Trafic est-ouest dans les réseaux de centres de données
Les schémas de trafic dans le centre de données peuvent être divisés en deux catégories
: le trafic nord-sud (ou vertical) et le trafic est-ouest (ou latéral).
Le trafic nord-sud est le trafic entrant (respectivement sortant) du centre de données

depuis (respectivement vers) le monde extérieur, tandis que le trafic est-ouest indique les flux
de trafic entre les points d'extrémité dans le centre de données.
Le trafic est-ouest domine dans les réseaux des centres de données, ce qui est souligné
par Cisco dans le Global Cloud Index 2015-2020 [12]. Cette augmentation du trafic est-ouest
est due à de multiples facteurs.
Tout d'abord, la façon dont les applications sont développées a changé. Pendant
longtemps, le modèle typique était l'application monolithique. Il s'agit d'une seule grande
application composée de plusieurs sous-systèmes ou capacités. Avec une application
P a g e 21
monolithique, le trafic est généralement nord-sud. De nos jours, les applications ont tendance
à être décomposées en plusieurs composants appelés services, ce qui permet de développer et
de déployer chaque service indépendamment des autres. C'est le modèle des micro-services.
Si une application Web est déployée dans un centre de données et elle est construite autour de
l'architecture micro-service, une seule requête à l'application peut nécessiter la
communication de plusieurs services entre eux, ce qui génère des flux de trafic latéraux
puisque les services peuvent probablement résider dans des end-points différents.
 Avantages de la topologie "Spine-Leaf" pour le trafic est-ouest
Dans une architecture traditionnelle, le nombre de sauts peut varier en fonction de

l'emplacement des points d'extrémité. Dans certains cas, les flux de données peuvent n'avoir à
remonter que jusqu'à la couche d'agrégation avant d'atteindre leur destination. Dans d'autres,
ils peuvent avoir à atteindre les routeurs centraux. Cela crée une différence de latence, ce qui
est problématique pour les applications sensibles au temps.
Une topologie Spine-Leaf gère mieux le trafic latéral et offre une meilleure évolutivité.
Cette architecture raccourcit les chemins de communication entre deux end-points. En effet, le
trafic provenant d'un end-point est toujours au même nombre de sauts de sa destination
puisque les Leafs sont entièrement maillées avec les Spines. Par conséquent, la latence du
trafic est- ouest est plus faible et prévisible.
 Redirection du trafic
Toute infrastructure multi-Tenants nécessite une isolation du réseau. Il y a quelques

années, la méthode couramment utilisée pour assurer cette isolation dans le centre de données
était le VLAN (802.1Q).
Le champ VLAN ID inclus dans l'en-tête Ethernet est long de 12 bits, ce qui permet
4096 possibilités. Il est donc possible d'utiliser 4096 VLAN différents sur un même appareil.
Cependant, cela induit certaines limitations pour les réseaux de centres de données. 4096
VLANs, cela semble beaucoup, mais ce n'est pas suffisant dans un environnement cloud
hébergeant l'infrastructure réseau de centaines de clients. Ensuite, l'utilisation d'approches
traditionnelles comme le protocole Spanning Tree pour construire une topologie sans boucle
peut entraîner un grand nombre de liens désactivés pour un réseau L2 couvrant l'ensemble du
centre de données. D'où l'introduction du réseau local extensible virtuel (VXLAN) disponible
dans le RFC 7348 [13]. L’ACI apparaît au monde extérieur comme un commutateur unique et
P a g e 22
distinct en raison de son architecture Spine-Leaf et de l'utilisation des End-points de tunnel

VXLAN. VXLAN est un protocole de tunneling, qui permet d’étirer" un réseau L2 sur un
réseau L3. En d'autres termes, VXLAN est un schéma de superposition de la couche 2 sur un
réseau sous-jacent de la couche 3. Un tunnel (ou segment) VXLAN est identifié par son
VNID (VXLAN Network Identifier) qui est codé sur 24 bits, donc plus de 16 millions de
possibilités.
Le fonctionnement de VXLAN est assez simple. La trame Ethernet de l'extrémité source

est encapsulée dans un datagramme UDP (encapsulation Mac-in-UDP) à l'entrée du tunnel,
puis le paquet est transmis à la sortie du tunnel où il est décapsulé et transmis à l'extrémité de
destination. Les éléments chargés de cette encapsulation (et décapsulation) sont appelés
VTEP, (VXLAN Tunnel End-points). Le format des paquets VXLAN est illustré à la figure9.
À l'entrée, l'ACI encapsule les paquets VLAN externe, VXLAN et NVGRE dans un
paquet VXLAN. La figure 10 illustre la normalisation de l'encapsulation ACI. Il traverse
ensuite la fabrique en deux sauts au plus. À sa sortie, le trafic est décapsulé.
L'adresse IP source (respectivement destination) de l'en-tête IP externe est l'adresse du

VTEP source (respectivement destination). Comme le paquet VXLAN est acheminé, un
protocole de routage est nécessaire dans le réseau sous-jacent (IS-IS dans ACI). De plus, des
routeurs ne connaissant rien au VXLAN peuvent faire partie du réseau sous-jacent ; leur seul
rôle est de router les datagrammes UDP.
Figure 10: Normalisation de l'encapsulation ACI [14].

P a g e 23
3.3.2 Application Policy Infrastructure Controller (APIC)
L'ACI utilise un contrôleur centralisé appelé Application Policy Infrastructure

Controller (APIC), comme le montre la figure 11. Le nom définit la fonction dans ce cas : il
s'agit du contrôleur qui crée les politiques (policies en anglais) d'application pour
l'infrastructure du centre de données. L'APIC prend en charge l'intention (EPG, politiques,
etc.), ce qui change complètement le modèle opérationnel qui s'éloigne de la configuration des
VLAN, des ACL, etc.
Figure 11: Le contrôleur centralisé de l’ACI [15].
Le système d'exploitation ACI Fabric convertit les politiques de l'APIC en un modèle

concret qui s'exécute dans l'infrastructure physique. Le modèle concret est analogue à un
logiciel compilé ; il s'agit de la forme du modèle que le système d'exploitation du
commutateur peut exécuter. La figure 12 montre la relation entre le modèle logique, le modèle
concret et le système d'exploitation du commutateur.
Figure 12: Transformation du modèle logique vers le modèle concret [14].
Tous les nœuds de commutation contiennent une copie complète du modèle concret.
Lorsqu'un administrateur crée dans l'APIC une politique qui représente une configuration,
P a g e 24
l'APIC met à jour le modèle logique. L'APIC effectue ensuite l'étape intermédiaire de création
d'une politique entièrement élaborée qu'il pousse dans tous les nœuds de commutation où le
modèle concret est mis à jour.
L'APIC est responsable de l'activation de la fabrique, de la configuration des politiques

de réseau et de l'instanciation. Bien que l'APIC agisse en tant que moteur de gestion
centralisée des politiques et du réseau pour la fabrique, il est complètement retiré du chemin
des données, y compris de la topologie d'acheminement. Par conséquence, la fabrique peut
continuer à acheminer le trafic même si la communication avec l'APIC est perdue. Donc, Ils
peuvent donc être temporairement déconnectés. Car contrairement aux solutions SDN
traditionnelles, le contrôleur APIC d'ACI, comme on a dit, ne gère aucun trafic et n'est utilisé
que pour pousser la configuration sur le réseau.
L'APIC dispose bien sûr d'une interface graphique pratique, mais la puissance réside
dans le contrôle logiciel, c'est-à-dire dans la programmation du réseau. Le même logiciel de
virtualisation, ou le même logiciel de cloud ou d'automatisation, voire des scripts écrits par
l'ingénieur réseau, peuvent définir les EPGs, les politiques, etc. Mais tous ces acteurs accèdent
au système ACI en s'interfaçant à l'APIC, comme le montre la figure 13 ; l'ingénieur réseau
n'a plus besoin de se connecter à chaque commutateur individuel et de configurer les
commandes CLI.
Figure 13: Contrôler l’ACI à l'aide de l'APIC [15].
P a g e 25
3.3.3 Modèle de configuration de l’ACI (ACI Policy Model)
Le modèle de configuration gère l'ensemble de la structure, y compris l'infrastructure,

l'authentification, la sécurité, les services, les applications et les diagnostics. Les constructions
logiques du modèle de configuration définissent la manière dont la fabrique répond aux
besoins. La figure 14 donne un aperçu du modèle de configuration ACI.
Figure 14: Modèle de configuration [14].
Les composants physiques et logiques qui composent la structure ACI sont enregistrés
dans une structure hiérarchique appelée arbre d'informations de gestion (Management
Information Tree : MIT). Chaque nœud de la MIT est un objet géré (Managed Object : MO)
qui est une abstraction d'une ressource de la fabrique.
Le modèle de politique (policy model) est une structure de données orientée objet
composée d'objets gérés qui sont des instances de classes. Un MO peut représenter un objet
physique tel qu'un commutateur, ou un objet logique tel qu'un EPG. Chaque MO est identifié
par un nom distinctif (Distinguished-Name : DN), et contient les propriétés (relations
enfant/parent, attributs de l'objet, etc.) qui composent l'objet.
Le Northbound REST API de l'APIC est en fait une interface vers le MIT permettant
des opérations CRUD (création, lecture, mise à jour et suppression) sur les MO.
La manipulation des MOs dans le modèle, libère les ingénieurs de la tâche d'administrer
des configurations de composants isolés et individuels. Ces caractéristiques permettent
l'automatisation et le provisionnement flexible des charges de travail qui peuvent localiser
n'importe quelle charge de travail n'importe où dans l'infrastructure. Les services connectés au
P a g e 26
réseau peuvent être facilement déployés et l'APIC fournit un cadre d'automatisation pour gérer
le cycle de vie de ces services connectés au réseau.
Figure 15: L'arbre d'information de gestion (MIT) [14].
La figure 15 présente l’arbre d’information de gestion. Les politiques relatives aux

Tenants et Access, sont abordées ci-dessous. L'objectif des sous-sections suivantes est de
donner un aperçu de la manière dont les politiques sont utilisées et s'intègrent dans certains
cas d'utilisation simples.
3.3.3.1 Tenant
Un Tenant est un conteneur logique pour les politiques d'application qui permettent à un
administrateur d'exercer un contrôle d'accès basé sur le domaine. Un Tenant représente une
unité d'isolement du point de vue de la politique, mais il ne représente pas un réseau privé.
Les Tenants peuvent représenter un client dans un contexte de fournisseur des services, une
organisation ou un domaine dans un contexte d'entreprise, ou simplement un regroupement
pratique des politiques. La figure suivante fournit une vue d'ensemble de la partie Tenant de
la MIT.
P a g e 27
Figure 16: Le MO Tenant et ses enfants [14].
Les Tenants peuvent être isolés les uns des autres ou partager des ressources. Les
principaux éléments que contient le Tenant sont les filtres, les contrats, les réseaux extérieurs,
les Bridge Domains (BD), les Virtual Routing and Forwarding (VRF), et les Applications
profiles qui contiennent des EPG (End-point groups). Les entités du Tenant héritent de ses
politiques. La figure 17 illustre un exemple des policy objects et leurs relations mutuelles
utilisés pour configurer le réseau d'une application à trois niveaux dans ACI.
Figure 17: Les politiques du Tenant pour une simple application Web
P a g e 28
3.3.3.1.1 VRF : Virtual Routing Forwarding
Les Tenants assurent également la segmentation du réseau de couche 3 grâce au

transfert de routage virtuel (VRF). Il s'agit d'une technologie permettant de créer plusieurs
instances de tables de routage au sein d'un seul équipement réseau, et donc de faire coexister
plusieurs réseaux L3. En conséquence, l'ACI prend en charge la multi-Tenancy puisque les
espaces d'adresses IP peuvent être dupliqués dans des VRF distincts.
La communication entre plusieurs VRF reste possible grâce à un processus appelé fuite
de route VRF, de sorte que la communication inter-Tenant peut toujours avoir lieu tant que les
adresses IP ne se chevauchent pas.
Un identifiant de réseau VXLAN (VNID) est toujours associé à un VRF.
3.3.3.1.2 BD : Bridge Domains
Un BD représente un domaine de diffusion de couche 2 dans l'ACI. Alors qu'un VRF

désigne un espace d'adressage unique. Cet espace d'adressage peut être divisé en plusieurs
sous- réseaux. Ces sous-réseaux sont désignés dans un ou plusieurs BD faisant référence au
VRF correspondant. On dit souvent que le BD est "comme un VLAN", ce qui est proche mais
pas tout à fait exact. Les BD ne sont pas soumises aux mêmes limitations que les VLAN,
telles que la limite des 4096 segments.
Lorsqu'un sous-réseau est attribué à un BD, une passerelle est automatiquement créée
sur toutes les Leafs de la fabrique où le BD existe. C’est ce qu'on appelle une passerelle
pervasive ou anycast. L'adresse IP et l'adresse MAC de la passerelle du BD sont les mêmes
sur toutes les Leafs, de sorte que les End-points peuvent se déplacer de manière transparente
entre les Leafs. Un VNID, ainsi qu'une adresse IP multicast sont associés à un BD lors de sa
création.
3.3.3.1.3 Application Profile
L’Application Profile définit les politiques, les services et les relations entre les EPGs.
Les Applications profiles contiennent un ou plusieurs EPGs. Les applications modernes
contiennent de multiples composants. Par exemple, une application de commerce électronique
peut nécessiter un serveur Web, un serveur de base de données, des données situées dans un
réseau de stockage et un accès à des ressources extérieures permettant des transactions
financières. L'application profile contient autant (ou aussi peu) des EPGs que nécessaire qui
sont logiquement liés à la fourniture des capacités d'une application.
P a g e 29
3.3.3.1.4 End-point Groups
L’End-point group (EPG) est l'objet le plus important du modèle de configuration. Un

End-point group est une collection des End-points fournissant une fonction similaire. Il est
utilisé pour regrouper logiquement des objets nécessitant une politique similaire. Les EPGs
peuvent également faire référence à des endpoints situés à l'extérieur de la structure ACI ;
dans ce cas, on parle d'EPG externe.
3.3.3.1.5 Contracts and Filters
L'ACI suit un modèle de confiance zéro, ce qui signifie que la communication inter-
EPG n'est pas autorisée, sauf s'il existe un contrat. Toutefois, les End-points appartenant au
même EPG peuvent librement communiquer entre eux par défaut. Les contrats définissent les
types de trafic qui peuvent passer entre les EPGs, y compris les protocoles et les ports
autorisés.
La relation entre un EPG et un contrat peut être de deux types : un EPG peut fournir ou
consommer un contrat (ou les deux). Et pour être utile, un contrat doit avoir au moins un
consommateur et un fournisseur. Lorsqu'un EPG fournit un contrat, la communication avec ce
EPG peut être initiée par d'autres EPGs conformément aux règles du contrat. Lorsqu'un EPG
consomme un contrat, les terminaux de l'EPG consommateur sont en mesure d'entamer une
communication avec tous les terminaux d'un EPG fournissant ce contrat.
3.3.3.2 Access Policies
Jusqu'à présent, les constructions fondamentales pour configurer le réseau avec une
approche application centric ont été couvertes dans la section précédente. En fait, les
Politiques d'accès doivent être définies au préalable, sinon les politiques du Tenant ne seront
pas activées. Les interfaces externes d'accès au fabrique (Fabric access external-facing
interfaces) se connectent à des périphériques externes tels que des contrôleurs de machines
virtuelles, des hôtes et des routeurs.
Comme pour les Tenant policies, les access policies font également appel à de
nombreux objets de politique. Certains d'entre eux sont présentés dans la Figure 18.
P a g e 30
Figure 18: Les objets access policy [8].
3.3.3.2.1 Domaine
Tous les EPGs ont besoin d'un domaine, qui indique simplement la portée d'un pool de
VLAN (c'est-à-dire où le pool sera appliqué). Un domaine peut être soit physique, soit virtuel,
soit externe.
3.3.3.2.2 VLAN pool
Pourquoi les VLAN sont-ils nécessaires en premier lieu ? Les VLAN sont toujours
nécessaires sur le lien entre un port de Leaf et le dispositif qui s'y connecte, car le nœud Leaf
doit connaître l'EPG de l’End-point à l'origine du trafic. Les VLANs sont donc utilisés par les
leafs pour identifier les End-points. C'est relativement facile si un périphérique comme un
ordinateur portable est directement branché sur le port d'un nœud Leaf. Dans ce cas, le VLAN
par port peut être utilisé, ce qui signifie que le trafic atteignant un nœud Leaf à partir de ce
port sera automatiquement mappé à un VLAN
Un VLAN Pool n'est rien d'autre qu'une collection d'ID de VLAN attribués par blocs.
Chaque domaine doit être associé à un seul pool VLAN. Et chaque AAEP peut être associé à
un ensemble de domaines (VLAN).
3.3.3.2.3 AAEP
Le profil d'entité d'accès attachable (Attachable Access Entity Profile AAEP) est la
construction logique qui lie les pools de VLAN dénommés dans un domaine aux interfaces de
commutateur leaf.
P a g e 31
3.3.3.2.4 Association d’EPGs aux access policies
Dans le modèle de configuration, les EPGs sont étroitement liés aux VLANs. Pour que
le trafic puisse circuler, un EPG doit être déployé sur un port leaf avec un VLAN dans un
domaine physique, VMM, L2out, L3out ou Fibre Channel. Voir la figure 19.
Figure 19: Association d’EPGs aux access policies [8].
Dans le modèle de configuration, le profil de domaine associé à l'EPG contient le profil

d'instance du VLAN. Le profil de domaine contient à la fois le profil d'instance VLAN (VLAN
instance profile) qui s’appelle VLAN pool et le profil d'entité d'accès (AAEP), qui sont
associés directement aux EPGs. L'AAEP déploie les EPG d'application associés à tous les
ports auxquels il est attaché, et automatise la tâche d'attribution des VLANs. Alors qu'un
grand centre de données peut facilement compter des milliers de machines virtuelles actives
provisionnées sur des centaines de VLAN, la fabrique ACI peut attribuer automatiquement
des identifiants VLAN à partir de VLAN pools. Cela permet de gagner un temps
considérable, par rapport à l'attribution de VLAN dans un centre de données traditionnel.
4. Les interfaces de programmation d'applications : API
4.1. Les interfaces de programmation d'applications : aperçu général
Les applications utilisent des interfaces de programmation d'applications (API) pour

communiquer. Pour ce faire, un programme peut apprendre les variables et les structures de
données utilisées par un autre programme, faire des choix logiques en fonction de ces valeurs,
modifier les valeurs de ces variables, créer de nouvelles variables et supprimer des variables.
P a g e 32
Les API permettent aux programmes exécutés sur différents ordinateurs de travailler en
coopération, en échangeant des données pour atteindre un objectif.
Dans un monde de logiciel API, certaines applications créent une API, et de nombreuses
autres applications utilisent (consomment) l'API. Les développeurs de logiciels ajoutent des
API à leurs logiciels afin que d'autres logiciels d'application puissent utiliser les
fonctionnalités de la première application. Lors de l'écriture d'une application, le développeur
écrira un peu de code, mais souvent il peut faire une grande partie du travail en recherchant
les API qui peuvent fournir les données et les fonctions, réduisant la quantité de nouveau code
à écrire. Par conséquence, une grande partie du développement de logiciels modernes est axée
sur la compréhension et l'apprentissage des nouvelles API, ainsi que des bibliothèques
disponibles sous forme des logiciels préconstruits qui peuvent être utilisés pour accomplir des
tâches plutôt que d'écrire l'équivalent à partir de zéro.
Cette section de deuxième chapitre se concentre sur deux conventions qui permettent
aux logiciels d'automatisation de communiquer.
La première partie traite des interfaces de programmation d'applications, plus

précisément des API REST (Representational State Transfer). Les API de tout type permettent
aux applications logicielles de communiquer, tandis que les API RESTful suivent un
ensemble spécifique de règles logicielles. De nombreuses API utilisées aujourd'hui dans
l'automatisation du réseau utilisent des API REST
Ce qui suit se concentre sur les conventions et les normes pour les données et les
variables échangées via les APIs, en se concentrant sur l'une d'entre elles : JavaScript Object
Notation (JSON). Si REST fournit une méthode standard pour communiquer entre deux
programmes automatisés sur un réseau, alors JSON définit comment communiquer les
variables utilisées par les programmes
4.2. API-REST
REST est un style architectural pour les systèmes hypermédia distribués. Comme
d'autres styles architecturaux. Ce style a ses principes directeurs et ses contraintes. Ces
principes doivent être satisfaits si une interface de service doit être qualifiée de RESTful.
P a g e 33
4.2.1 Contraintes architecturales REST
Les API REST suivent un ensemble de règles de base. Tout d'abord, littéralement, l'API
REST contient six propriétés qui ont été définies il y a des décennies par son créateur, Roy
Fielding [16]. Ces six propriétés sont :
 Architecture client/serveur
 Apatride (Stateless)
 Cachable (Cacheable)
 Interface uniforme (Uniforme Interface)
 Système de couches (Layered system)
 Code à la demande (Code on demand)
4.2.1.1 Architecture client/serveur
Comme de nombreuses applications, les applications REST utilisent un modèle

d'architecture client/serveur. Tout d'abord, un développeur d'application crée une API REST
qui agit comme un serveur REST lors de l'exécution. Toute autre application peut appeler une
API REST (client REST) en exécutant du code qui achemine les demandes du client vers le
serveur. La Figure 20 présente un exemple d’opération client/serveur avec REST.
Figure 20: Opération Client / Serveur avec REST [17].
1. Le client REST de gauche exécute un appel d'API REST, qui génère un message envoyé au
serveur REST.
2. Le serveur REST de droite possède un code API qui prend en compte la demande et décide
P a g e 34
de la manière de répondre.
P a g e 35
3. Le serveur REST renvoie le message de réponse avec les variables de données appropriées
dans le message de réponse.
4.2.1.2 Stateless
La nature Stateless (sans état) des API REST signifie que REST n'enregistre ni n'utilise
les informations sur les échanges d'API afin de traiter les échanges d'API ultérieurs. En
d'autres termes, chaque demande et réponse d'API n'utilise pas d'autres antécédents pris en
compte lors du traitement de la demande.
4.2.1.3 Cacheable
Pour comprendre ce que signifie cacehable, imaginez ce qui se passe lorsque vous
naviguez sur un site Web. Lorsqu’un navigateur charge une nouvelle page Web, la page Web
elle-même contient divers objets (texte, images, vidéo, audio). Certains objets changent
rarement, il est donc préférable de les télécharger une seule fois et de ne plus jamais les
télécharger ; dans ce cas, le serveur marque cet objet comme pouvant être mis en cache. Les
API REST exigent que toute ressource demandée via un appel d'API ait une méthode explicite
pour marquer la ressource comme pouvant être mise en cache ou non. L'objectif reste le
même, améliorer les performances en récupérant les ressources moins fréquemment.
4.2.1.4 Uniforme Interface (interface uniforme)
Lors de la création d'API REST, les développeurs acceptent d'utiliser les mêmes
normes. Par conséquent, chaque API a une interface uniforme. Une interface est un contrat
entre un client et un service, partagé par toutes les API REST. Ceci est utile car cela aide les
développeurs à s'assurer qu'ils se comprennent lorsqu'ils utilisent l'API.
4.2.1.5 Layered system (système de couches)
REST permet d’utiliser une architecture système en couches, par exemple, un

développeur peut déployer une API sur le serveur A, puis stocker des données sur le serveur B
et valider les requêtes sur un autre serveur C. Un client ne peut généralement pas savoir s'il se
connecte directement à un serveur de terminaux ou à un intermédiaire.
P a g e 36
4.2.1.6 Code on demand (code à la demande)
Cette contrainte est facultative. La plupart du temps, les représentations de ressources

statiques sont envoyées au format XML ou JSON. Le code à la demande signifie que le
serveur peut étendre ses fonctionnalités en envoyant du code aux clients pour téléchargement.
Par exemple, un client peut appeler une API pour obtenir le code de rendu d'un widget
d'interface utilisateur. Ceci est autorisé.
4.2.2 API REST et HTTP
Une API doit définir les types de protocoles réseau qu'elle prend en charge, et de
nombreuses API basées sur REST utilisent le protocole HTTP.
Les créateurs d'API basées sur REST choisissent souvent HTTP car la logique du
protocole correspond à certains des concepts plus généralement définis pour les API REST.
HTTP utilise les mêmes principes que REST : il fonctionne avec un modèle client/serveur, il
utilise un modèle de fonctionnement sans état et il inclut des en-têtes qui marquent
explicitement les objets comme pouvant ou non être mis en cache. Il comprend également des
verbes qui indiquent l'action souhaitée pour une paire de requête et de réponse HTTP, c'est
ainsi que les applications aiment fonctionner.
Cette section présente les principes de base de la terminologie de la programmation, la

correspondance avec les verbes HTTP et la manière dont les API REST utilisent les
identificateurs de ressources uniformes (Uniform Resource Identifier : URI) pour spécifier les
données souhaitées dans un appel d'API RESTful.
4.2.2.1 Les actions CRUD des logiciels et verbes HTTP
L'industrie du logiciel utilise un acronyme mémorable - CRUD - pour désigner les

quatre actions principales effectuées par une application. Ces actions sont :
 Créer : Permet au client de créer de nouvelles instances de variables et de

structures de données sur le serveur et d'initialiser leurs valeurs comme étant
conservées sur le serveur.
 Read : Permet au client de récupérer (lire) la valeur actuelle des variables qui
existent sur le serveur, en stockant une copie des variables, des structures et des
valeurs sur le client.
P a g e 37
 Update : Permet au client de modifier (mettre à jour) la valeur des variables qui
existent sur le serveur.
 Delete : Permet au client de supprimer du serveur différentes instances de
variables de données.
Par exemple, si vous utilisez l'API REST Northbound d'un contrôleur ACI, vous pouvez
vouloir créer quelque chose de nouveau, comme une nouvelle politique. Du point de vue de la
programmation, la politique existe comme un ensemble connexe de paramètres de
configuration sur l’APIC, représenté en interne par des variables. Pour ce faire, une
application client REST utiliserait une action de création, à l'aide de l'API RESTful de l'APIC,
qui crée des variables sur ce dernier. Le concept de création d'une nouvelle configuration au
niveau du contrôleur est réalisé via l'API à l'aide d'une action Créer selon l'acronyme
générique CRUD.
D'autres exemples d'actions CRUD incluent une vérification de l'état de cette nouvelle
configuration (une action de lecture), une mise à jour pour modifier un paramètre spécifique
de la nouvelle configuration (une action de mise à jour) ou une action pour supprimer
complètement la définition de la politique de sécurité (une action de suppression).
HTTP utilise des verbes qui reflètent les actions CRUD. Il définit le concept de
demande (Request) et de réponse HTTP, le client envoyant une demande et le serveur
répondant par une réponse. Chaque demande/réponse énumère un verbe d'action dans l'en-tête
de la demande HTTP, qui définit l'action HTTP. Les messages HTTP comprennent également
une URI, qui identifie la ressource manipulée pour cette demande. Comme toujours, le
message HTTP est transporté en IP et TCP, avec des en-têtes et des données, comme
représenté sur la Figure 21.
Figure 21: Verbe HTTP et URI dans un en-tête d’une requête [18].
Chaque fois qu’un utilisateur ouvre un navigateur Web et qu’il clique sur un lien, le
navigateur génère un message de requête HTTP GET dont la structure est similaire à celle de
P a g e 38
la figure 21. Le message comprend un en-tête HTTP avec le verbe GET et l'URI. Les
ressources renvoyées dans la réponse sont les composants d'une page Web, comme les
fichiers texte, les
P a g e 39
fichiers image et les fichiers vidéo. HTTP fonctionne bien avec REST en partie parce que
HTTP possède des verbes qui correspondent aux actions de programme courantes dans le
paradigme CRUD. Le Tableau 4 répertorie les verbes HTTP et les termes CRUD à des fins de
référence et d'étude faciles.
Tableau 4: Comparaison des actions CRUD et des verbes HTTP
Terme CRUD Verbe HTTP

Créer (Create) POST
Lire (Read) GET
Mise à jour (Update) PATCH, PUT
Supprimer (Delete) DELETE
4.2.2.2 Utilisation des URIs avec HTTP
En plus d'utiliser les verbes HTTP pour exécuter les fonctions CRUD d'une application,
REST utilise les URI pour identifier la ressource sur laquelle la requête HTTP agit. Pour les
API REST, la ressource peut être l'une des nombreuses ressources définies par l'API. Chaque
ressource contient un ensemble de variables connexes, définies par l'API et identifiées par un
URI.
Par exemple, imaginons qu'un utilisateur crée une API basée sur REST. Ce faisant, il
crée un ensemble de ressources qu'il souhaite mettre à disposition via l'API, et il attribue
également un URI unique à chaque ressource. En d'autres termes, le créateur d'API crée un
URI et un ensemble de variables correspondant, et définit les actions qui peuvent être
exécutées sur ces variables (lecture, mise à jour, etc.).
Le créateur de l'API crée également une documentation API qui répertorie les
ressources et l'URI qui identifie chaque ressource, entre autres détails. Le programmeur d'une
application client REST peut lire la documentation de l'API, élaborer une requête API REST
et demander la ressource spécifique, comme le montre l'exemple de la figure 22.
P a g e 40
Figure 22: Une requête API REST qui demande une ressource spécifique à travers l’URI [18].
La figure 22 présente les URI sous forme de valeurs génériques ; cependant, les
ingénieurs réseau d'aujourd'hui doivent être capables de lire la documentation de l'API, de
voir les URIs dans cette documentation et de comprendre la signification de chaque partie de
l'URI. La figure 23 présente un URI spécifique à Northbound REST API du Cisco DNA
Center comme exemple de certains des composants de l'URI.
Figure 23: Structure d’un URI pour une requête REST GET [18].
 HTTPS : Les lettres qui précèdent le :// identifient le protocole utilisé - dans ce
cas, HTTP Secure (qui utilise HTTP avec un cryptage SSL).
 Nom d'hôte ou adresse IP : Cette valeur se trouve entre le // et le premier /, et
identifie l'hôte.
 Path (Resource) : Cette valeur se trouve après le premier / et se termine soit à la
fin de l'URI ou avant tout autre champ supplémentaire). HTTP appelle ce champ
le Path, mais pour une utilisation avec REST, le champ identifie de manière
unique la ressource telle qu'elle est définie par l’API.
Pour mettre en évidence le lien entre l'API, l'URI et la partie ressource de l'API, il peut
être utile de faire un tour général de la documentation de l'API pour toute API basée sur
REST. Par exemple, lorsque Cisco a créé DNA Center, il a créé l'interface Northbound basée
sur REST et a choisi un URI.
P a g e 41
De nombreux messages de requête HTTP doivent transmettre des informations au

serveur REST au-delà de l'API. Certaines de ces données peuvent être transmises dans des
champs d'en- tête. Par exemple, les API REST utilisent les champs d'en-tête HTTP pour coder
une grande partie des informations d'authentification pour les appels REST. En outre, les
paramètres liés à un appel REST peuvent être transmis en tant que paramètres dans le cadre
de l'URI lui-même.
Par exemple, l'URI de la figure 23 demande au Centre DNA Cisco une liste de tous les
périphériques connus, le Centre DNA Cisco renvoyant un dictionnaire de valeurs pour chaque
périphérique. Il se peut que vous souhaitiez plutôt obtenir ce dictionnaire de valeurs pour un
seul périphérique. L'API du centre Cisco DNA vous le permet en ajoutant des paramètres à la
fin de l'URI. Voir la figure 24.
Figure 24: Structure d’un URI pour une requête REST GET avec des paramètres
supplémentaires [17].
4.3. Exemple d'appel d'API REST au serveur APIC de Cisco
Pour rassembler certains des concepts de l'API REST, la figure 25 présente un exemple
d'appels d'API à l'aide d'une application logicielle appelée outil d'environnement de
développement d'API.
Dans une perspective de développement, lorsqu’on travaille à l'automatisation d'une

partie des tâches d'exploitation du réseau, on utilisera éventuellement un programme qui
effectue des appels d'API. Cependant, au début du processus de développement d'une
application, on pourrait d'abord se concentrer sur les données disponibles dans l'API et ignorer
toute la programmation.
Le DevNet Sandbox offrent aux développeurs un accès facile et sans frais à

l'Application Policy Infrastructure Controller (APIC) de Cisco pour développer et exécuter du
code 24h/24 et 7j/7 [19].
L'exemple suivant, montre l'utilisation d'une application appelée Postman qu’on peut la
télécharger et l’utilisé gratuitement [20]. Pour effectuer un appel d’API REST au serveur
P a g e 42
APIC
P a g e 43
On utilisent une requête REST est de type GET. Dans cet exemple notre requête demande la
liste des Tenants existes dans l’APIC.
Figure 25: Appel d'API REST au serveur APIC de Cisco à l’aide de Postman.
1. : Ce champ définie la nature de l’action. (GET pour la lecture, POST pour la création, …).
2. : L’URI utilisé :
21. : le protocole utilisé dans l’URI
22. : « sandboxapicdc.cisco.com » : indique un nom d'hôte. Dans ce cas est le serveur
ACI fournie par le site DevNet de Cisco.
23. : ce champ indique le path ou le chemin.
24. : ce champ comporte les paramètres qui permettent d’identifier spécifiquement ce
que l'API doit fournir au client REST.
3. : Ce champ montre les données renvoyées sous format JSON par la réponse GET HTTP
REST du serveur APIC.
4. : La réponse contient un nombre des tenants égale à neuf.
5. : Le nom de la première tenant est « infra »
6. : Statut : elle indique le code d'état de la réponse GET, soit 200, ce qui signifie " OK ".
P a g e 44
À ce stade, nous avons une bonne compréhension de base des mécanismes de l'API
REST. En acquérant certaines compétences et en utilisant la documentation de l'API pour
n'importe quelle API REST, nous pouvons maintenant expérimenter et essayer d'effectuer des
opérations REST API CRUD. Les données envoyées dans la requête sous forme de texte,
généralement au format JSON.
4.4. Sérialisation des données et JSON
4.4.1 L’envoie des variables d'un programme
Tout d'abord, les programmes écrits dans des langues différentes utilisent des
conventions différentes pour stocker leurs variables en interne, car il n'existe pas de norme
pour le stockage des variables internes dans toutes les langues. En fait, les programmes écrits
dans la même langue mais avec des versions différentes de cette langue peuvent ne pas
stocker toutes leurs variables avec les mêmes conventions internes.
Pour surmonter ces problèmes, les applications ont besoin d'une méthode standard de
représentation des variables pour la transmission et le stockage de ces variables en dehors du
programme. Les langages de sérialisation des données assurent cette fonction.
La figure 26 montre le flux de processus avec le processus de sérialisation des données

inclus :
Figure 26: Échange de représentations internes de variables [17].
P a g e 45
1. Le serveur collecte les données représentées en interne et les transmet au code API.
2. L'API convertit la représentation interne en un modèle de données représentant ces
variables (avec JSON comme indiqué sur la figure26).
3. Le serveur envoie le modèle de données au format JSON via des messages sur le réseau.
4. Le client REST prend les données reçues et convertit les données au format JSON en
variables dans le format natif de l'application client.
À la fin du processus, l'application client REST dispose maintenant de variables

équivalentes à celles qu'elle a demandées au serveur dans l'appel API.
4.4.2 Comparaison entre les langages de sérialisation des données :
Les différents langages de sérialisation des données existent pour répondre à différents
besoins qui sont apparus au fil des ans.
 JSON :
JavaScript Object Notation tente de trouver un équilibre entre la lisibilité humaine et la

lisibilité machine. Armés de quelques règles JSON, la plupart des humains peuvent lire les
données JSON, ne pas se contenter de deviner leur signification et interpréter en toute
confiance les structures de données définies par les données JSON. Dans le même temps, les
données JSON permettent aux programmes de convertir facilement le texte JSON en
variables, ce qui les rend très utiles pour l'échange de données entre applications à l'aide
d'API.
Figure 27: Réponse JSON d'une requête API REST.
P a g e 46
JSON est construit sur deux structures. Une collection de paires nom/valeur. Dans
différents langages, les structures de ce type peuvent être appelées objets, enregistrements,
dictionnaires, tables de hachage, listes à clés ou tableaux associatifs. Une liste ordonnée de
valeurs. Dans la plupart des langages, cela s'appelle un tableau, une liste, un vecteur ou une
séquence.
Ces deux structures sont des structures de données génériques. Presque tous les
langages de programmation modernes les prennent en charge sous une forme ou une autre. Il
est logique que les formats de données interchangeables avec les langages de programmation
soient également basés sur ces structures.
En JSON, ces deux structures ont les formes suivantes :
 Un objet : est un ensemble non ordonné de paires nom:valeur. Les objets

commencent par “{” et se terminent par “}”. Les Noms sont suivi de “ :”. et les
paires nom : valeur sont séparées par “,”.
 Un tableau est une collection ordonnée de valeurs. Les tableaux commencent par
“[” et se terminent par “]”. Les valeurs sont séparées par “,”.
Les valeurs peuvent être des chaînes, des nombres, des booléens, des valeurs nulles, des
objets ou des tableaux entre guillemets doubles.
 XML :
Dans les années 90, lorsque les navigateurs Web et le WWW ont été créés, les pages
Web utilisaient principalement le HTML pour définir les pages Web. En tant que langage de
marquage, le HTML définissait la manière d'ajouter le texte d'une page Web à un fichier, puis
d'ajouter des "balises". Par exemple, le marquage comprend des codes pour les titres, les types
et tailles de police, les couleurs, les hyperliens, etc.
L'eXtensible Markup Language (XML) est apparu plus tard pour apporter certaines
améliorations aux langages de marquage antérieurs. En particulier, au fil du temps, les pages
Web sont devenues de plus en plus dynamiques, et pour rendre les pages dynamiques, les
fichiers devaient stocker des variables dont les valeurs pouvaient être modifiées et remplacées
au fil du temps par le serveur Web. Pour définir les variables à substituer dans une page Web,
le monde avait besoin d'un langage de marquage capable de définir des variables de données.
P a g e 47
Le XML est un langage de marquage qui possède de nombreuses fonctionnalités pour

définir des variables, des valeurs et des structures de données.
Au fil du temps, le XML s'est développé au-delà de son utilisation initiale en tant que
langage de marquage. Les caractéristiques de XML en font également un langage de
sérialisation de données général utile, et il est utilisé comme tel aujourd'hui.
Si l'on compare XML à JSON, les deux tentent d'être lisibles par l'homme, mais XML
reste un peu plus difficile à lire.
Figure 28: Sortie XML d'un appel d'API REST.
 YAML :
YAML acronyme de Yet Another Markup Language dans sa version 1.0, devient
l'acronyme récursif de YAML Ain't Markup Language . YAML ne tente pas de définir les
détails du marquage (alors que XML le fait). Au lieu de cela, YAML se concentre sur les
détails du modèle de données (structure). YAML s'efforce également d'être propre et simple :
parmi les langages de sérialisation/modélisation de données répertoriés ici, YAML est
facilement le plus facile à lire pour toute personne novice en matière de modèles de données.
Ansible, fait un usage intensif des fichiers YAML. La figure 29 en présente un bref
échantillon. Et pour souligner l'importance de la lisibilité, même si nous avons aucune idée de
ce que fait Ansible, on peut deviner certaines des fonctions en lisant simplement le fichier.
P a g e 48
Figure 29: Fichier YAML utilisé par Ansible.
5. Conclusion
Après la discussion des outils théoriques nécessaires qui permettent de comprendre la

manière d’où la solution d’automatisation Cisco ACI fonctionne, on est prêts maintenant pour
commencer la réalisation de notre application Web. Le chapitre suivant, portera les étapes de
la mise en place de l’application.
P a g e 49
Chapitre III
Mise en place de l’application de gestion et

d’automatisation du réseau
L’objectif principal de ce premier chapitre est de présenter les phases de réalisation

de notre projet
Chapitre III : Mise en place de l’application Web
1. Introduction
N’importe quel projet, a pour but de répondre à un besoin. La mise en place de notre
application Web aura lieu pour faciliter le travail de l’administrateur réseaux au sein du
service IR. L’objectif de ce chapitre est de présenter dans la première partie une étude de
l’existant afin de déterminer les besoins fonctionnelle et non fonctionnelle. La deuxième
partie du chapitre se concentre sur la présentation de la solution à l’aide des outils de
conception UML. La dernière partie sera consacré pour la présentation des technologies et les
outils utilisés pour la réalisation, afin d’arrivé à l’explication des différentes interfaces de
l’application.
2. Etude préalable et discussion des besoins
2.1. Critique de l'existant
Dans le cadre d’automatisation des réseaux, Le groupe OCP a déployé une nouvelle
infrastructure basée sur l'offre CISCO ACI, comme une solution SDN fournie par CISCO.
L’équipe d’infrastructure réseaux du service réseaux télécom est chargé par la mise en place
des actions de création des objets d’ACI, afin d’assurer le bon fonctionnement de
l’architecture. Les actions effectuées sont les suivantes :
 Création d’un vlan sous un pool.
 Création d’un Bridge Domain et l’associer avec une VRF.
 Création d’une EPG (sous une application Profile) et l’associer avec un BD et un
Physical Domain.
 Ajout de ports statiques sous l’EPG (avec choix du port type VPC ou port
standard et choix du tag mode tagged ou untagged).
La communication avec le serveur APIC pour créer ces politiques est effectué à l’aide
de logiciel Postman. La création d’un Vlan sous un VLAN-pool, sera pris comme un exemple
de création d’une politique.
2.2. Exemple de création d’une politique : création d’un vlan sous un pool
2.2.1. L’ouverture d’une session avec l’ACI
Premièrement, en utilisant la documentation de l’API, on doit déterminer l’URI qui va

nous permet de s’authentifier à l’ACI. L’URI fourni qui permet de s’authentifier au serveur
APIC de Sandbox est le suivant : https://sandboxapicdc.cisco.com/api/aaaLogin.json
P a g e 47
L’étape suivante consiste à écrire le corps sous format JSON de la requête qui contient
le nom d’administrateur et le mot de passe. Le corps de chaque type de requête qui s’appelle
payload, est défini précédemment dans les documentations. Il reste alors que copier le
payload correspondant, et modifier les valeurs des variables selon le besoin demandé. Le
payload doivent être injectée dans le champ Body de l’application Postman.
A ce stade, la préparation de l’URI et de payload est terminée. Il nous reste que choisir
le verbe POST et cliqué sur le bouton send pour envoyer la demande au serveur. La figure
suivante montre les étapes expliqué précédemment. La figure 30 présente l’URI et le payload
de la requête d’authentification.
Figure 30: Préparation de requête d’authentification
Le serveur renvoie en retour une réponse JSON qui contient la valeur de l’attribue
« token ». Token est une clé fournie par l’ACI. Elle est utilisée pour ouvrir une session afin de
permettre effectuer n’importe quelle action dans l’ACI. Le message 200 OK indique que
l’authentification à l’ACI est effectuée. La réponse d’authentification est montrée dans La
figure 31.
Figure 31: Réponse d’authentification du serveur APIC.
P a g e 48
2.2.2. Création d’un VLAN sous un VLAN pool
Après la réussite de l’authentification à l’ACI, une session maintenant est ouverte vers
le serveur pour appliquer notre action. Pour créer un VLAN sous un Pool on doit déterminer
initialement l’URI.
https://sandboxapicdc.cisco.com/api/node/mo/uni/infra/
vlanns-[L3_OUT_VLAN_POOL]-static/from-[vlan-31]-to-[vlan-31].json
Dans l’URI on doit déterminer le nom du VLAN pool, le mode d’allocation « static ou
dynamic » et le rang des VLANs qu’on veut créer. Dans ce cas le nom du pool est
L3_OUT_VLAN_POOL, le mode d’allocation est statique et l’ID du vlan est 31.
Avec le même processus que l’authentification, après la détermination de l’URI, la

création du payload est demandée dans cette étape. La figure 32 montre la création du vlan 31
sous le pool L3_OUT_VLAN_POOL.
Figure 32: Création de vlan sous un pool.
Statuts : 200 OK. Donc la création de notre vlan 31 est très bien effectuée.
A la lumière de l’exemple précédent, il est très clair que l’utilisation de Postman pour
effectuer des actions de configuration rencontre les problèmes suivants :
 -La rapidité : Le choix des URIs et la génération des payloads pour chaque
action peut demander un temps très importants.
P a g e 49
 -Erreur de saisies : La manière de remplissage des champs des valeurs,

augmente la probabilité d’avoir des erreurs de saisies. Dans l’exemple précédent,
il est obligatoire d’entrer le nom correct du pool dans les différents champs, ainsi
que l’ID de vlan sous la forme vlan-ID.
 -Complexité : la création des différentes URIs et payloads pour les différentes
actions, rendre la tâche de l’administrateur réseaux un peu complexe.
Suite à l'identification des problématiques, plusieurs actions ont été défini avec des
objectifs précis et clairs. Le besoin exprimé par le service IR, c’est la mise en place d’une
application Web de gestion et d’automatisation du réseau en vue de faciliter le travail de
l’administrateur réseau.
2.3. Discussion des besoins
2.3.1. Spécification des besoins
La phase de spécification des besoins a pour objectif de spécifier les fonctionnalités et

des contraintes du système à mettre en place. Il existe deux types de besoin, les besoins
fonctionnels qui présentent ce que l’utilisateur attend en terme de service et les besoins non
fonctionnels qui présentent les contraintes sous lesquelles l’application doit rester fonctionnelle.
2.3.2. Besoins fonctionnels
Les besoins fonctionnels, sont les fonctionnalités que système doit fournir aux
utilisateurs. Dans notre cas, les besoins fonctionnels dégagé sont :
1. Menu ACI qui comporte :

 L’authentification à l’ACI.
 Création d’un pool.
 Création d’un vlan sous un pool.
 Création d’un Bridge Domain et l’associer avec une VRF.
 Création d’une EPG sous une application Profile et l’associer avec un BD et un
Physical Domain.
 Ajout de ports statiques sous l’EPG avec choix du port type VPC ou port
Standard et choix du tag mode Tagged ou Untagged.
2. Menu Wizard : qui permet d’effectuer toute la configuration du menu ACI d’une
manière successive.
P a g e 50
3. Menu Dashboard : ce menu permet d’afficher les objets (Tenants, VRF, BD, Vlan
pool, …) créer au niveau du serveur APIC.
2.3.3. Besoins non fonctionnels
Les besoins non fonctionnels peuvent être défini par l'expression de besoins en matière
de performance, le type de matériel ou le type de conception.
Bien évidemment, l'application devra être modulaire et extensible afin de pouvoir

ajouter de nouvelles ou modifié d'autres avec des coûts et des délais raisonnables.
L'application doit avoir un niveau de sécurité fiable pour gérer la visibilité d'accès aux
informations partagées dans l'application qui sera déployée sur le réseau de l'entreprise
Côté performance, l'application doit être rapide d'usage pour les utilisateurs avec des
outils de recherche et de temps de réponse rapide.
Niveau ergonomie et interface Homme/Machine, l'application doit offrir une interface

conviviale et facile d'utilisation.
3. Conception de l’application
L’étape de conception est très importante pour la réussite d’un projet informatique.
Cette phase vise à définir une feuille de route, concevoir et valider le projet avant de passer à
la réalisation du système. Elle permette aussi d’avoir une bonne réflexion, une bonne
organisation du travail et une bonne communication entre les différents intervenants.
3.1. Diagramme de cas d'utilisations
Les cas d'utilisation définissent comment le système doit être utilisé et décrivent ses
exigences fonctionnelles. Chaque cas d'utilisation contient un ou plusieurs scénarios qui
définissent la manière dont le système doit interagir avec les utilisateurs (appelés acteurs)
pour atteindre un objectif de travail ou une fonction spécifique. Un acteur de cas d'utilisation
peut être un humain ou un autre système que celui que nous essayons de définir. Les cas
d'utilisation évitent le jargon technique et essaient d'utiliser le langage de l'utilisateur final ou
de l'expert du domaine.
P a g e 51
3.1.1. Cas d’utilisation de menu ACI
Figure 33: Cas d’utilisation de menu ACI.
La figure 33 présente les cas d’utilisation de menu ACI et le Wizard. Un admin a la

possibilité de tester l’authentification à l’ACI et de créer les politiques au niveau de l’APIC
(vlan, EPG, …) d’une manière individuelle ou sous forme d’un Wizard.
Les opérations possibles sont les suivantes :

 La création d’un vlan pool
 La création d’un vlan sous un pool
 La création d’un Bridge Domain sous un VRF
 La création d’un EPG sous une application profile et l’associé à un BD et un
domaine physique.
 L’ajout d’un port statique Ajout de ports statiques sous l’EPG (avec choix du
port type VPC ou port standard et choix du tag mode Tagged ou Untagged)
P a g e 52
 Effectuer les opérations précédentes sous forme d’un Wizard.
3.1.2. Cas d’utilisation de menu Gestion
Figure 34: Cas d’utilisation de menu Gestion.
L’application offre la gestion complète des équipements réseaux et des utilisateurs de

l’application. La figure 34 présente les cas d’utilisations de menu Gestion.
Notant les principales opérations possibles :

 Ajout d’un utilisateur
 Suppression d’un utilisateur (sauf l’administrateur principale)
 Modification du login ou du mot de passe d’un utilisateur.
 Ajout d’un équipement réseaux.
 Suppression d’un équipement réseaux.
 Modification des informations d’un équipement réseaux.
P a g e 53
3.2. Diagramme de séquence
Le diagramme de séquence permet de décrire les scenarios de chaque cas d'utilisation en

mettant l'accent sur la chronologie des opérations en interaction avec les objets. Cette partie
va prendre le cas d’authentification à l’application, et la création d’un vlan sous un pool.
3.2.1. Le diagramme de séquence « Authentification »
Figure 35: Diagramme de séquence d’Authentification à l’application.
La figure 35 montre les scénarios possibles afin d’authentifier à l’application. Dans le

processus d’authentification, l’administrateur demande de se connecter au système. Le
système affiche l’interface du login et mot de passe. L’utilisateur insère son login et mot de
passe. Le système réaffiche l’interface du login et mot de passe au cas où ils sont incorrects.
Au cas où c’est correct, le système affiche l’espace correspondant.
P a g e 54
3.2.2. Le diagramme de séquence « Création d’un VLAN sous un pool »
Figure 36: Diagramme de séquence de Création d’un VLAN sous un pool.
La figure 36 présente le processus de création d’un vlan sous un pool. L’administrateur

interagit avec l’application de la manière suivante :
L’administrateur demande l’interface de création d’un vlan sous un pool. Après le
remplissage des informations d’authentification à l’ACI, le système demande de s’authentifier
au serveur APIC. si les informations sont correctes, une liste des VLANs pools sera afficher.
Après le choix du pool, l’admin doit remplir l’ID du vlan et confirmer la création. Un
message de réussite sera affiché si l’ID de vlan est un nouveau ID.
P a g e 55
4. Mise en place de l’application
La partie de la mise en place de l’application, décrit en premier lieu les différentes

technologies Framework adoptées et utilisées pour la réalisation de notre projrt comme
Laravel dans le back-end, Bootstrap et Blad dans le front-end, MySql dans la base de
données. Par la suite, cette partie montre la phase de déploiement qui était distribuée dans
deux serveurs (Godaddy, Google Cloud) pour sauver l’application au cas d’une panne dans un
serveur. La dernière section de cette partie sera consacrée pour présenter Les interfaces de
l’application.
4.1. Technologies de développement
4.1.1. Outils techniques :
Pour faciliter le travail et le bien organiser, nous avons utilisé plusieurs logiciels.
 Environnement et développement intégrés :
 PHP Storm est un IDE PHP qui "comprend" le code. Il prend

en charge PHP 5.3/5.4/5.5/5.6/7.0/7.1/7.2, fournit la
prévention des erreurs à la volée, les meilleurs outils de saisie
automatiques, un débogage sans configuration et un éditeur
JavaScript, CSS et HTML étendu [21].
 DataGrip est un environnement de gestion de bases de
données pour les développeurs. Il est conçu pour interroger,
créer et gérer des bases de données. Les bases de données
peuvent fonctionner localement, sur un serveur ou dans le
nuage. Prend en charge MySQL, PostgreSQL, Microsoft SQL
Server, Oracle, et plus encore [21].
 Gestion des versions et collaboration :
 Git un logiciel de gestion de versions décentralisé il permet de
conserver un historique des modifications effectuées sur un
projet afin de pouvoir rapidement identifier les changements
effectués et de revenir à une ancienne version en cas de
problème. Ses objectifs sont la rapidité, l'intégrité des données
et la prise en charge des flux de travail distribués et non linéaires [22].
P a g e 56
 Github la plus grande plateforme d’hébergement de projets Git

au monde. Il offre les fonctionnalités de contrôle de version
distribué et de gestion du code source de Git, ainsi que ses
propres fonctionnalités [23].
4.1.2. Technologies et Framework :
 Front End :
 Blade est le moteur de template utilisé par Laravel. Son but est
de permettre d’utiliser du php sur notre vue mais d'une manière
assez particulière [24].
 Bootstrap 4 est un framework CSS. Un framework correspond
à un ensemble de librairies regroupées dans un but précis et
possédant des règles internes que doivent suivre les utilisateurs
[25].
 Back End :
 Laravel est un framework PHP multiplateforme, il offre un
environnement de développement très fonctionnel, ainsi que des
interfaces de ligne de commande intuitives et expressives. Les
applications Laravel sont hautement évolutives et leur base de
code est facile à maintenir [26].
 Database :
 Mysql est un système de gestion de bases de données
relationnelles SQL, stocke les données dans des tables séparées
plutôt que de tout rassembler dans une seule table. Cela améliore
la rapidité et la souplesse de l'ensemble. Les tables sont reliées
par des relations définies, qui rendent possible la combinaison de
données entre plusieurs tables durant une requête [27].
P a g e 57
4.2. Déploiement de l’application
Maintenant l'application est prête à être déployée, pour le déploiement on a deux choix.
Le déploiement classique ou le déploiement distribuer.
4.2.1. Déploiement classique
Le déploiement classique, il s’agit d’un déploiement dans un seul serveur sans aucun
backup pour sauver l’application au cas d’une panne. Cette solution ne coûte pas si cher, mais
elle coûtera trop cher dans le cas d’un échec du système, sans garantie de maintenir le
fonctionnement de l'application.
Dans ce type de déploiement on utilise l’hébergement Godaddy. Pour cela on

commence par La création d’un compte, puis choisir un plan, payer le plan choisi puis des
informations d'identification. On accède au serveur en utilisant SSH et clonant le repo du
projet, en installant les indépendances et lancer l’application pour la première fois.
4.2.2. Déploiement distribué
Pour ce type de déploiement nous assurons le bon fonctionnement de notre application,

car l’application n'est pas hébergée dans un seul serveur ou dans un seul emplacement, En
fait, les services utilisés se base sur le principe hébergement distribué, en d'autres termes : ses
cloud serveurs sont partout dans le monde. Alors notre application est bien sauvegardée dans
plusieurs locations, dans le cas d’un panne le fournisseur de services redirige le trafic vers les
autres serveurs où il existe une autre version de notre application, pour que nous soyons
toujours en ligne. Les plus grands fournisseurs de ses services sont GCP (Google Cloud
Platform) et AWS (Amazon Web Services).
4.3. GRIFAPIC : une application Web d’automatisation et de gestion de réseaux
L’application GRIFAPIC est le fruit de ce projet. www.grifapic.com est le lien de notre

application. Cette section portera la démonstration des différentes fonctionnalités de
l’application. Toute opération sur les objets ACI au niveau de l’APIC est basée sur des
requêtes REST de type GET ou POST. L’annexe 3 présente toutes les requêtes utilisées par
notre application.
P a g e 58
4.3.1. La page d’authentification
Pour accéder à l’application, l’administrateur doit saisir ses coordonnées

d’authentification. La figure 37 présente l’interface d’authentification.
Figure 37: Page d’authentification à l’application.
On peut utiliser les cordonnée de compte d’essai pour accéder.

Login: grifabdelali@ocpgroup.com; password: grifapic.
4.3.2. Menu Dashboard
Après l’authentification le menu Daashboard apparaitre en premier lieu. L’action sur le

bouton synchroniser permet d’afficher une interface pour synchroniser l’application avec le
serveur APIC. Pour cela on doit fournir l’adresse IP ou bien le nom DNS ainsi que le login et
le mot de passe d’ACI. (Voir la figure 38).
P a g e 59
Figure 38: Menu Dashboard, synchronisation avec l’ACI.
Cisco permet la connexion à son serveur APIC en utilisant les informations suivantes :
URL : sandboxapicdc.cisco.com
Login : admin
Password : !v3G@!4@Y
Après la synchronisation, l’ACI envoi la liste des Tenants et la liste des domaines
physiques à notre interface Dashboard. Les Tenants ou bien les domaines physiques
s’affichera sous forme des boutons. Pour afficher la liste des VRFs d’un Tenant il suffit de
cliquer sur le Tenant correspondant. Pour afficher la liste des Bridges Domain d’un VRF, on
clique sur ce VRF. Une clique sur un Bridge Domain, permettre d’afficher quelques
informations sur ce dernier. Le même scénario sera répété si on veut afficher les informations
d’un EPG. On doit choisir le Tenant, l’application profile puis l’EPG. Pour afficher les
informations d’un VLAN pool, on doit accéder à ce dernier à travers son domaine physique.
La figure 39 montre la liste des objets récupérer après la synchronisation avec l’ACI. Chaque
liste des objets est un réponse API REST d’une requête de type GET.
P a g e 60
Figure 39: Liste des Tenants et domaines physiques.
Le menu Dashboard permet aussi la visualisation des équipements réseaux ajouté dans
l’interface gestion des équipements, sous forme d’un tableau qui englobe les informations
nécessaires.
4.3.3. Menu ACI :
Le menu ACI est le menu principal de notre application. La création des différents
objets d’ACI se présente dans ce menu.
4.3.3.1 Création d’un VLAN Pool
Pour créer un vlan pool, il suffit de remplir les informations d’authentification à l’ACI,
choisir le nom du pool, le mode d’allocation, et choisir le rang initial des VLANs dans ce
pool. L’annexe 2 présente l’interface de création de pool sous le nom vlan_grif2 et qui
comporte le rang de VLANs de 10 à 20. Après la création du vlan pool on doit l’associer à un
domaine physique. La figure 40 présente le choix du domaine physique à partir d’une liste
récupérer depuis l’APIC. Ce qui garantit l’élimination d’avoir des erreurs de saisies.
P a g e 61
Figure 40: Association d’un vlan pool à un domaine physique.
Après le choix du domaine, il suffit de cliquer sur créer pour compléter la création. Au
niveau du Back End on a utilisé deux requêtes de type POST. La première est pour la création
d’un pool. La deuxième est pour l’association du pool à un domaine physique. Une requête de
type GET est utilisé pour récupérer les domaines physiques.
4.3.3.2 Création d’un VLAN sous un Pool
Pour créer un ou plusieurs VLANs sous un pool, on doit cliquer sur « Create VLAN
under a Pool », choisir entre un ou plusieurs VLAN, remplir les informations
d’authentification à l’ACI, choisir un pool et taper l’ID du VLAN. La figure 41 montre
l’interface création d’un ou plusieurs VLAN sous un pool.
Figure 41: Interfaces de création d’un ou plusieurs VLANs sous un pool.
La création d’un VLAN sous un pool est l’exemple quand a choisie dans la partie étude
de l’existant, afin d’exprimer les besoins et les problèmes qu’on doit résoudre. La figure 41
P a g e 62
présente une interface facile et dynamique. Si on compare la création de vlan à l’aide de

Postman dans la partie 2.2 de ce chapitre, et celle à travers notre application, on va remarquer
qu’on a gagné en termes de rapidité, d’élimination d’avoir des erreurs de saisie et de
simplification de la tâche de création.
4.3.3.3 Création d’un Bridge Domain sous un VRF
Un Bridge Domain est un objet ACI qu’on doit créer sous un VRF. Comme pour toutes
les actions de créations, on doit remplir initialement les informations d’authentification à
l’ACI. Par la suite on doit choisir un Tenant, un VRF puis saisir les informations de BD. La
figure 42 présente l’interface de création d’un BD.
Figure 42: Interface de création d’un BD sous un VRF.
La création de BD sous un VRF nécessite deux requête GET pour récupérer la liste des
Tenants et la liste des VRF. Les noms de Tenant et de VRF seront utilisés comme des valeur
dans la requête de création de BD.
4.3.3.4 Création d’un EPG sous une application profile
Après l’authentification à l’ACI et le choix de Tenant, on doit saisir les informations

contenant le nom, l’Alias, la description et choisir la priorité pour la création d’un EPG. Ce
dernier doit être créer sous une application profile et associer à un Domain physique et à un
BD. La figure 43 montre l’interface de création d’un EPG.
P a g e 63
Figure 43: Interface de création d’un EPG.
4.3.3.5 Ajout de port statique sous un EPG
L’ajout de port statique un EPG est la dernière action demandé dans le cahier de charge.
Pour ajouter un port statique on doit choisir initialement le type de port, VPC ou standard.
Après l’authentification à l’ACI, on doit choisir un Tenant, une Application profile, un EPG,
un commutateur (Node) en cas du port statique, le port, un VLAN, et le mode de Tag (Trunk,
Access (802.1P) ou Access (Untagged)). La figure 44 montre l’interface d’ajout d’un port
statique de type standard ou VPC à un EPG.
Figure 44: Interfaces d’ajout d’un port statique à un EPG.
P a g e 64
Pour développer l’interface de création d’un port statique, on a utilisé les requêtes suivantes :
 Une requête de type GET pour récupérer la liste des Tenant.

 Une requête de type GET pour récupérer la liste des Applications profiles d’une Tenant.
 Une requête de type GET pour récupérer la liste des EPG d’une application profile.
 Une requête de type GET pour récupérer la liste des ports de type VPC.
 Une requête de type GET pour récupérer la liste des ID des commutateurs (leaf) de
l’architecture.
 Une requête de type GET pour récupérer la liste des noms des ports de switch choisie.
 Une requête de type POST pour ajouter le port statique à l’EPG.
4.3.3.6 Wizard
L’équipe de l’infrastructure réseaux au sein de service réseaux et télécom, ont besoin

d’effectuée les tâches présenter dans les parties de 4.3.3.2 à 4.3.3.5 de ce chapitre, au même
temps et d’une manière successive. Pour cela, on a développé un menu wizard qui répond à ce
besoin. La figure 45 présente l’interface wizard.
Figure 45: Interface Wizard.
L’étape 6 de menu wizard est la confirmation de la création de toute les actions effectuer.
P a g e 65
4.3.4. Menu Gestion
4.3.4.1 Gestion de stock
Pour faciliter la gestion du stock, on a développé un espace des équipements réseaux qui
liste chaque équipement ses informations (référence, type, état, marque, site). La figure 46
montre l’interface de gestion des équipements.
Figure 46: Interface de gestion des équipements réseaux.
4.3.4.2 Gestion des utilisateurs
Chaque utilisateur dispose d’un login et un mot de passe, pour accéder à l’application et
réaliser les tâches demandées.
Figure 47: Interface de gestion des utilisateurs.
5. Conclusion
La phase réalisation est l'étape la plus importante, c’est la concrétisation du tout le

travail fait dans tout le cycle de vie du projet. Dans ce chapitre, nous avons arrivé à répondre
sur le besoin demandé. La mise en place de l’application GRIFAPIC était la solution pour
faciliter les tâches de l’administrateur réseaux et réduire le temps moyen de travail.
P a g e 66
Conclusion Générale
CONCLUSION GENERALE
Ce travail vient pour achever la formation d’ingénieur d’état au sein de l’Ecole Nationale des
Sciences Appliquées de Safi. Il est inscrit dans une démarche d’amélioration des
performances de service réseaux et télécoms de siège de groupe OCP, qui sert à mettre en
place une application de gestion et d’automatisation du réseau, basée sur la solution
d’automatisation Cisco ACI.
Le point de départ pour la réalisation de ce projet était de rassembler les informations

nécessaires pour dresser un état de l’existant, et présenter une vue d'ensemble du problème.
Par la suite, nous avons intéressé à la spécification des besoins, ce qui nous a permet de
déterminer les différents menus de l'application. Le point qui suit était la conception détaillée
de l'application à l’aide de langage UML. Enfin, nous avons passé à la phase de réalisation,
dans laquelle nous avons exposé les outils, les logiciels de développement utilisés et les
interfaces des différents menus de notre application.
Ce projet a permis d’augmenter la productivité de l’équipe réseaux et d’obtenir un meilleur

contrôle et une visibilité optimale sur les ressources réseau. D’une part, cette application a
permis de réduire le temps moyenne d’exécution des tâches de configurations, grâce à
l’automatisation des tâches répétitives et fastidieuses. D’autre part, elle a permis d’augmenter
la disponibilité du réseau grâce à des une gestion plus efficaces. Cela dû à la Réduction de
nombre d'erreurs de saisies, et à la simplicité d’exécution des tâches.
En raison de la politique interne de l'entreprise d’accueil, ce stage est effectué à distance.

Pour cela, on a rencontré des obstacles majeurs en terme d’obtention de la bonne information
dans le bon moment. Alors, Le retard d’exécution des tâches était un résultat direct de cette
situation. Face à ces contraintes, le projet n'a pas réussi à fournir certaines fonctionnalités
importantes. L'automatisation des tâches de suppression et de modification de configuration
est l'une des limites de notre application.
P a g e 67
Conclusion Générale
En perspectives cette application pourrait être améliorée et enrichie par des fonctionnalités
avancées. Elle pourrait être basée sur plusieurs solutions d’automatisation et non pas une
seule. Les offres SDN actuelles de Cisco, à savoir ACI pour le centre de données, SDA
(Software- Defined Access) pour le campus de l'entreprise et SD-WAN (Software-Defined
WAN) pour le réseau étendu de l'entreprise. Avoir une application basée à la fois sur les
solutions ACI et SDA, par exemple, ouvrira un œil sur l’automatisation des réseaux dans le
Software-Defined Networking multi-domaine.
P a g e 68
Bibliographie
BIBLIOGRAPHIE
[1] J. Durant, «Le SDN Pour Les Nuls.,» 2015. [En ligne]. Available: https://alln-extcloud-
storage.cisco.com/gblogs/sites/53/2015/12/JRES2015-SDN-pour-les-nuls-11.pdf. [Accès le 20
juin 2022].
[2] «Happy Birthday, Cisco Application Centric Infrastructure.,» Cisco, 2014. [En ligne]. Available:
https://blogs.cisco.com/perspectives/happy-birthday-cisco-application-centric-infrastructure.
[Accès le 01 06 2022].
[3] Secretariat générale de groupe ocp, «Organigrammes nominatifs des Directions et Filiales du
Groupe OCP,» p. 68, 2009.
[4] «Rédiger la charte de projet,» 15 Mai 2012. [En ligne]. Available:

https://perfectionnement.gestiondeprojet.pm/la-charte-de-projet/. [Accès le 15 03 2022].
[5] W. Odom, «CCNA 200-301 Official Cert Guide,» vol. 2, p. 364, 2020.
[6] M. Tury, «Les risques d’OpenFlow et du SDN,» p. 2, 2015.
[7] W. Odom, «CCNA 200-301 Official Cert Guide,» vol. 2, p. 366, 2020.
[8] «Cisco ACI for Data Center,» Cisco, 2022. [En ligne]. Available:
https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-
infrastructure/. [Accès le 30 mai 2022].
[9] E. Debray, «Au-delà du SDN: OpFlex un nouveau protocole pour Application Centric
Infrastructure,» Cisco, 09 avril 2014. [En ligne]. Available:
https://gblogs.cisco.com/fr/datacenter/14303/. [Accès le 01 juin 2022].
[10] W.Odom, «CCNA 200-301 Official Cert Guide,» vol. 2, p. 371, 2020.
[12] C. Systems, «Cisco Global Cloud Index 2015-2020,» 2015. [En ligne]. Available:
https://www.cisco.com/c/dam/m/en_us/service-
provider/ciscoknowledgenetwork/files/622_11_15-16-Cisco_GCI_CKN_2015-
2020_AMER_EMEAR_NOV2016.pdf. [Accès le 05 juin 2022].
[13] M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell et C.Wright,

«Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer
2 Networks over Layer 3 Networks.,» août 2014. [En ligne]. Available:
http://datatracker.ietf.org/doc/html/rfc7348. [Accès le 12 06 2022].
[14] «Cisco Application Centric Infrastructure Fundamentals, Release 4.2(x),» 08 10 2019. [En ligne].
Available: http://www.cisco.com. [Accès le 08 06 2022].
P a g e 69
Bibliographie
[16] «Roy_Fielding,» [En ligne]. Available: https://stringfixer.com/fr/Roy_Fielding. [Accès le 12 juin

2022].
[17] AlihanLab, «REST-Based API,» [En ligne]. Available: https://alihanlab.co.uk/13-3-understanding-

rest-and-json/. [Accès le 12 juin 2022].
[18] W.ODOM, «Official Cert Guide, CCNA 200-301,,» vol. 2, pp. 414-416, 2020.
[19] Cisco, «ACI Sandboxes,» [En ligne]. Available: https://developer.cisco.com/docs/aci/#!

sandbox/aci-sandboxes. [Accès le 13 juin 2022].
[20] «Download Postman,» [En ligne]. Available: https://www.postman.com/downloads/. [Accès le

13 juin 2022].
[21] Novo Web Design, «Qualifications,» [En ligne]. Available: https://novowebdesign.com/a-

propos/qualifications. [Accès le 15 juin 2022].
[22] PDFprof, «organigramme ocp 2016,» [En ligne]. Available:

https://pdfprof.com/PDF_Doc_Telecharger_Gratuits.php?q=organigramme+ocp+2016/-
26PDF36336-doc1. [Accès le 15 05 2022].
[23] W. Stallings, «Software-Defined Network and OpenFlow,» The Internet Protocol Journal, vol. 16,
n° %11, p. 3, 2013.
[24] S. Jose, «Cisco Application Centric Infrastructure Fundamentals, Release 4.2(x),» 8 octobre
2019. [En ligne]. Available: http://www.cisco.com. [Accès le 05 juin 2022].
[25] «Présentation de Git et de GitHub,» [En ligne]. Available: https://www.pierre-giraud.com/git-

github-apprendre-cours/presentation-git-github/. [Accès le 15 juin 2022].
[26] «9 meilleures alternatives GitHub en 2021,» [En ligne]. Available:

https://fre.myservername.com/9-best-github-alternatives-2021. [Accès le 15 juin 2022].
[27] «FORMATION LARAVEL : BLADE,» 19 octobre 2021. [En ligne]. Available:

https://walkerspider.com/cours/laravel/blade/. [Accès le 15 juin 2022].
[28] «Présentation de Bootstrap,» [En ligne]. Available: https://www.pierre-giraud.com/bootstrap-

apprendre-cours/introduction/. [Accès le 15 juin 2022].
[29] «Le framework PHP Laravel – la construction d’applications web pour tous,» 24 mai 2022. [En
ligne]. Available: https://kinsta.com/fr/base-de-connaissances/qu-est-ce-que-laravel/. [Accès le
15 juin 2022].
[30] «Qu’est-ce que MySQL ? Une explication simple pour les débutants,» 26 mai 2022. [En ligne].
Available: https://kinsta.com/fr/base-de-connaissances/qu-est-ce-que-mysql/. [Accès le 15 juin
2022].
P a g e 70
Annexes
ANNEXE 1
Organigramme du groupe OCP1
Figure 48: Organigramme du groupe OCP
1
[26]
P a g e 71
Annexes
ANNEXE 2
Interface de création d’un VLAN pool
P a g e 72
Annexes
ANNEXE 3
Requêtes de type GET :
 Récupérer la liste des VLANS pool :
base_ URI = 'https://{APIC}/api/'
URI _prepend = 'node/mo/uni/infra.json?query-target=subtree&target- subtree-
class=fvnsVlanInstP&query-target-filter=not(wcard(fvnsVlanInstP.dn," ui_"))'
URI = base_ URI + URI _prepend
 Liste des Domaines physiques :

URI _iprepend = 'node/mo/uni.json?query-target=subtree&target-subtree-class=physDomP&query-target-
filter=not(wcard(physDomP.dn," ui_"))&target-subtree-class=infraRtDomP'
URI = base_ URI + URI_prepend
 Liste des VRF

URI _prepend = 'node/mo/uni/tn-{Tenant_name}.json?query-target=children&target-subtree-
class=fvCtx&query-target-filter=and(not(wcard(fvCtx.dn," ui_")),not(wcard(fvCtx.annotation,"shadow:yes")))'
 Liste des Tenants

URI _prepend = 'node/class/fvTenant.json?query-target-filter=
and(or(wcard(fvTenant.name," ")))'
 Liste des ports de type VPC

URI _prepend = 'node/class/fabricPathEp.json?query-target-
filter=and(eq(fabricPathEp.lagT,"node"),wcard(fabricPathEp.dn,"^topology/pod-[\d]*/protpaths-"))'
 Liste des ports Standard d'un nœud
base_ URI = 'https://{APIC}/api/'.format(APIC=APIC)

URI _prepend = 'node/class/fabricPathEp.json?query-target-filter=and(eq(fabricPathEp.lagT,"not-
aggregated"),eq(fabricPathEp.pathT,"leaf"),wcard(fabricPathEp.dn,"topology/pod-1/paths-
{nodeId}/"),not(or(wcard(fabricPathEp.name,"^tunnel"),wcard(fabricPathEp.name,"^vfc"))))'
 Liste des nœuds :
P a g e 73
Annexes
URI _prepend = 'node/class/fabricNode.json?query-target-

filter=and(not(wcard(fabricNode.dn," ui_")),and(eq(fabricNode.role,"leaf"),eq(fabricNode.fabricSt,"active"),n
e(fabricNode.nodeType,"virtual")))'
 Liste des EPGs :

URI _prepend = 'node/mo/uni/tn-{Tenant_name}/ap-{App_Prof_name}.json?query-target=subtree&target-
subtree-class=fvAEPg'.format(Tenant_name=Tenant_name,App_Prof_name=App_Prof_name)
 Liste des BDs

class=fvBD&query-target-filter=and(not(wcard(fvBD.dn," ui_")),not(wcard(fvBD.annotation,"shadow:yes")))'
 Liste des applications Profiles

class=fvAp&subscription=no&rsp-subtree-include=health,fault-count&order-by=fvAp.name|asc&query-target-
filter=and(not(wcard(fvAp.dn,%22 ui_%22)),not(wcard(fvAp.annotation,%22shadow:yes%22)))'
Requêtes de type POST :

 Authentification :
URI = https://{APIC}/api
payload = {
'aaaUser':
{'attributes':
{'name': '{username}',
'pwd': '{password}',
}
}
}
 Création d'un VLAN :

URI _ URI = 'node/mo/uni/infra/vlanns-[{VlanPool_name}]-{AllocMode}/from-[{Vlan_Range_L}]-to-
[{Vlan_Range_H}].json'
URI = base_url + url_prepend
payload =
{ "fvnsEncapBlk":
{ "attributes": {
"dn": "uni/infra/vlanns-[{VlanPool_name}]-{AllocMode}/from-[{Vlan_Range_L}]-to-[{Vlan_Range_H}]",
"from": "{Vlan_Range_L}",
"to": "{Vlan_Range_H}",
"rn": "from-[{Vlan_Range_L}]-to-[{Vlan_Range_H}]",
"status": "created"
P a g e 74
Annexes
},
"children": []
}
}
 Création d'un VLAN pool :
URI _prepend = 'node/mo/uni/infra/vlanns-[{Vlan_name}]- {AllocMode}.json'
URI = base_url + url_prepend
payload = {
"fvnsVlanInstP": {
"attributes": {
"dn": "uni/infra/vlanns-[{Vlan_name}]-{AllocMode}",
"name": "{Vlan_name}".format(Vlan_name=Vlan_name),
"descr": "{Vlan_description}",
"rn": "vlanns-[{Vlan_name}]-{AllocMode}",
"status": "created"
},
"children": [
{
"fvnsEncapBlk": {
"attributes": {
"dn": "uni/infra/vlanns-[{Vlan_name}]-{AllocMode}/from-[{Vlan_Range_L}]-to-
[{Vlan_Range_H}]",
"allocMode": "{AllocModeRange}",
"descr": "{Vlan_Rangedescription}",
"from": "{Vlan_Range_L}",
"to": "{Vlan_Range_H}",
"rn": "from-[{Vlan_Range_L}]-to-
[{Vlan_Range_H}]",
"status": "created"
},
"children": []
}
}
]
}
}
 Association d'un VLAN pool à un domaine Physique

URI _prepend = 'node/mo/uni/phys-{Domain_name}/rsvlanNs.json'
payload =
{ "infraRsVlanNs":
{ "attributes": {
"tDn": "uni/infra/vlanns-[{Vlan_name}]-{AllocMode}",
"status": "created,modified"
},
"children": []
}
}
 Création d'un EPG

URI _prepend = 'node/mo/uni/tn-{Tenant_name}/ap-{App_Prof_name}/epg-{EPG_name}.json'
P a g e 75
Annexes
payload ={
"fvAEPg":
{ "attributes":
{
"dn": "uni/tn-{Tenant_name}/ap-{App_Prof_name}/epg-{EPG_name}",
"prio": "{prio}",
"name": "{EPG_name}",
"nameAlias": "{EPG_Alias}",
"descr": "{EPG_Description}",
"rn": "epg-{EPG_name}",
},
"children": [
{
"fvRsBd":
{ "attributes":
{
"tnFvBDName": "{BD_name}",
},
"children": []
}
},
{
"fvRsDomAtt": {
"attributes": {
"tDn": "uni/phys-{Domain_name}",
"status": "created"
},
"children": []
}
}
]
}
}
 Création d'un BD :
URI _prepend = 'node/mo/uni/tn-{Tenant_name}/BD-{BD_name}.json'
payload = {
"fvBD": {
"attributes": {
"dn": "uni/tn-{Tenant_name}/BD-{BD_name}",
"arpFlood": "{arpFlood}",
"name": "{BD_name}",
"nameAlias": "{BD_Alias}",
"descr": "{BD_Description}",
"rn": "BD-{BD_name}",
},
"children": [
{
"fvRsCtx":
{ "attributes":
{
P a g e 76
Annexes
"tnFvCtxName": "{VRF_name}",
},
P a g e 77
Annexes
"children": []
}
}
]
}
}
 Ajout de port Statique :

base_ URI = 'https://{APIC}/api/'.format(APIC=APIC)
URI _prepend = 'node/mo/uni/tn-{Tenant_name}/ap-{App_Prof_name}/epg-{EPG_name}/rspathAtt-
[{dn}].json'
Payload mode Trunk
payload ={
"fvRsPathAtt": {
"attributes": {
"dn": "uni/tn-{Tenant_name}/ap-{App_Prof_name}/epg-{EPG_name}/rspathAtt-[{dn}]",
"encap": "{vlan}",
"tDn": "{dn}",
"rn": "rspathAtt-[{dn}]",
"status": "created"
},
"children": []
}
}
Payload mode Access
payload ={
"fvRsPathAtt": {
"attributes": {
"dn": "uni/tn-{Tenant_name}/ap-{App_Prof_name}/epg-{EPG_name}/rspathAtt-[{dn}]",
"encap": "{vlan}",
"mode": "{mode}",
"tDn": "{dn}",
"rn": "rspathAtt-[{dn}]",
"status": "created"
},
"children": []
}
}
P a g e 78
Mise en place d’une application
Web de gestion et
d’automatisation du réseau basée
sur la solution Cisco ACI
Les technologies sous-jacentes ont été évoluées, mais la gestion des réseaux est demeurée stagnante
pendant des décennies. En général, les réseaux qui sont conçus et entretenus manuellement ne sont
plus efficaces pour répondre aux besoins actuels en termes de rapidité et facilité de gestion.
Par ailleurs, l’automatisation des ressources réseaux et de la gestion des services apporte aux équipes
opérationnelles de multiples avantages concrétisés par l’agilité et la souplesse. Dans ce sens le SDN
(Sofware-Defined Networking) est présenté comme la solution conçue pour rendre les infrastructures
réseaux plus flexibles et plus faciles à gérer. En effet, cette technologie assure une gestion centralisée
et automatique des équipements réseaux, en ajoutant un niveau d'abstraction à l’infrastructure. La
séparation des parties décisionnelles et opérationnelles autorise une grande souplesse dans le
déploiement, l’évolution et l’automatisation à travers des API (Interfaces de Programmation
d'Applications), notamment les APIs REST.
A cet égard, le groupe OCP a déployé une nouvelle infrastructure basée sur l'offre CISCO ACI
(Application Centric Infrastructure), comme une solution SDN fourni par CISCO. Cette solution
implique un point de contrôle central s’appelle APIC pour la gestion du réseau. Par lequel, toutes les
opérations du réseau sont effectuées en utilisant une interface qu'il expose. Cette interface est
généralement une API REST et permet la programmation du réseau et l'intégration avec d'autres
systèmes.
L’objectif ultime du présent Projet de fin d’étude est la mise en place d’une application Web de
gestion et d’automatisation du réseau permettant à l’APIC d’effectuer toutes les opérations du réseau.
Afin d’avoir une meilleure mise en place de ce projet, l’application est tenu de fournir des interfaces
faciles à utiliser par l’administrateur réseaux, assurer la réduction de temps moyen d’exécution des
tâches et réduire au maximum la complexité des opérations effectuée.
Mots-clés : Automatisation des réseaux, SDN, Plan de contrôle distribué, Plan de contrôle
centralisé, CISCO ACI, APIC, Spine, Leaf, Application Web, CRUD, API REST, URI.
GRIF Abdelali, Elève ingénieur en Réseaux et Télécommunications, ENSA de SAFI, Promotion 2022

Projet de Fin D'Etudes: Diplôme D'ingénieur D'etat en Génie Télécommunications Et Réseaux

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

Projet de Fin D'Etudes: Diplôme D'ingénieur D'etat en Génie Télécommunications Et Réseaux

Transféré par

Droits d'auteur :

Formats disponibles

Université Cadi Ayyad

Ecole Nationale des sciences

Département Informatique Réseaux et Télécommunications N° d’ordre : ……/22

PROJET DE FIN D’ETUDES

Diplôme d’Ingénieur d’Etat en Génie

Mise en place d’une application Web de

Effectué à : Réalisé par :

Groupe OCP SA Abdelali GRIF

Présenté le 30/06/2022, devant le Jury :

Mme. H. MESTOURI ENSA de Safi Département IRT Présidente

M. A. ZYANE ENSA de Safi Département IRT Rapporteur

M. R. HAMDAOUI Groupe OCP Service RT Encadrant professionnel

M. A. BENLAMKADEM ENSA de Safi Département IRT Encadrant pédagogique

Année universitaire : 2021/2022

En premier lieu, je tiens à exprimer ma profonde reconnaissance à M. Abdellatif

Mes remerciements vont aussi à M. Radouane HAMDAOUI mon encadrant professionnel

Mes remerciements vont également à M. Nour-Eddine MAAMORI et M. Nabil NOUIGA

Keywords : Networks automation, SDN, Distributed control plane, Centralized control

TABLE DES MATIERES

2.1 Contexte général......................................................................................................................................7

LISTE DES TABLEAUX

LISTE DES FIGURES

Figure 35: Diagramme de séquence d’Authentification à l’application.................................................................54

LISTE DES ABREVIATIONS ET SYMBOLES

ACI Application Centric Infrastructure UDP User Datagram Protocol

API Application Programming Interface TCP Transmission Control Protocol

APIC Application Policy Infrastructure Controller URI Uniform Resource Identifier

BD Bridge Domain VLAN Virtual Local Area Network

CLI Command-line interface VNID VXLAN Network Identier

DN Distinguished Name VTEP VXLAN Tunnel Endpoints

DNA Digital Network Architecture VXLAN Virtual Extensible Local LAN

EPG End-Point Group WWW World Wide Web

HTML Hypertext Markup Language XML eXtensible Markup Language

HTTP Hypertext Transfer Protocol YAML YAML Ain’t Markup Language

HTTPS Hypertext Transfer Protocol Secure

IS-IS Intermediate System to Intermediate System

JSON JavaScript Object Notation

MAC Medium Access Control

MIT Management Information Tree

NBI Northbound Interface

OCP Office Chérifien des Phosphates

REST REpresentational State Transfer

SBI Southbound Interface

Le 31 juillet 2014, Cisco a présenté sa solution logicielle de mise en réseau de centres de

Ce rapport présente le travail effectué sous forme de trois chapitres.

Le premier chapitre est dédié premièrement à la présentation de l’entreprise d’accueil.

Le deuxième chapitre, est entamé par une présentation du Software Defined

Présentation d’organisme d’accueil et de projet de

Les objectifs principaux de ce premier chapitre sont de présenter des généralités

Partie 1 : Présentation d’organisme d’accueil

Le présent projet concerne la mise en place d’une application Web d’automatisation du

1.2 Présentation du groupe OCP

La fiche signalétique est la carte d’identité de l’entreprise. La fiche signalétique de OCP

Tableau 1: Fiche Signalétique de OCP SA.

Raison sociale OCP SA

1.4 Organigramme de l’entreprise

La dimension organisationnelle au sein de Groupe OCP SA se caractérise par un dosage

Figure 1: Organigramme de siège de Casablanca [3].

1.5 Service Réseaux et télécom RT

Le service réseaux et télécom englobe quatre filiales, sous la direction de monsieur EL

Figure 2: Organigramme du service RT

Le rôle principal da la filiale Infrastructures réseaux IR est d’assurer que les

Partie 2 : Contexte général du projet