UNIVERSITÉ DES SCIENCES

ET TECHNIQUES DE MASUKU ECOLE POLYTECHNIQUE DE MASUKU MOOV AFRICA GABON

------------------
TELECOM

DÉPARTEMENT
GÉNIE INFORMATIQUE ET
TELECOMMUNICATIONS

N° d’ordre : ……/2019/EPM/GIT

Pour l’obtention du Diplôme d’Ingénieur de Conception

Option : Génie Informatique et Télécommunications

CONCEPTION D’UNE PLATEFORME DE SUPERVISION

DEDIEE AU RESEAU VPN 3G/4G DE MOOV AFRICA GABON
TELECOM

Présenté par : Stèn Géris MBOUGOU MBOUGOU

Le 29 janvier 2021 à Franceville

Sous la direction de :
Encadreur Entreprise : M Axel MOUNDOUNGA, Ingénieur Réseau-Télécom
Encadreur Ecole : Dr Mohamed Ali IPOPA, Maître-Assistant CAMES
Sous la supervision scientifique de :
Pr OYOBE OKASSA Aimé Joseph, Maître de Conférences CAMES
Devant le Jury composé de :
Président : Thierry Blanchard EKOGO, Pr Titulaire CAMES (USTM)
Examinateur : Romarick ROTIMBO BOUROU Assistant CAMES (USTM)
Examinateur : Yves Constant MOMBO BOUSSOUGOU, Maître-Assistant CAMES (USTM)
Examinateur : Mohamed Ali IPOPA, Maître-Assistant CAMES (USTM)
Examinateur : Aimé Joseph OYOBE OKASSA, Maître de Conférences CAMES (USTM)

Année Académique 2020 - 2021

 DEDICACES

Avec la conviction qu’aucun mot ne saurait rendre avec exactitude la gratitude que je porte en moi, j’aimerais
dédier ce modeste travail à mes parents. Mme GUIZOMBIE Diane Olga ma chère mère, mon soutient
infaillible et celle qui n’a jamais douté de moi. M MBOUGOU Pierre-Marie, mon père et premier formateur,
celui qui a guidé mon évolution vers l’homme que je suis devenu. Mon grand Frère, M MBOUGOU Freddy
Gernot, mon aîné, mon protecteur, l’homme qui a toujours eu la solution et le recule nécessaires à tous les
problèmes que je lui ai présentés dans ma vie. Puis-je seulement envisager de ne pas citer mes deux sœurs,
MBOUGOU MALAMA Desy Gerolle, Et MBOUGOU DIANGA Henrielle Gerika ? Je n’ai jamais douté
de l’amour et des mobiles bienveillants qui les habitent en permanence me concernant. Le besoin d’être
digne d’elles a toujours été une motivation viscérale pour moi.
Je suis heureux que Dieu m’ait accordé de telles personnes pour m’entourer. J’espère très intimement que
ces personnes sont fières de moi. Une forte pensée également à toutes ces personnes qui m’ont soutenu
moralement ou matériellement tout au long de mon parcours académique.
 REMERCIEMENTS

En préambule ce mémoire, j’aimerai adresser mes sincères remerciement à l’équipe du CNPI, qui m’a
encadré soutenu et guidé durant mon stage académique. Notamment à M MOUNDOUNGA Axel Hemery,
Ingénieur d’Exploitation à MAGT, mon encadreur de stage dont la volonté à faire de moi un Ingénieur tel
que lui n’a jamais faiblie. Dr Mohamed Ali IPOPA, Directeur Des Etudes du Cycle Ingénieur à l’Ecole
Polytechnique de Masuku et mon encadreur académique pour la patience et la disponibilité qu’il a eu vis-à-
vis de moi.
J’adresse de vifs remerciements aux Dr Ing. Nicaise MANFOUMBI et Dr Yves Constant MOMBO,
respectivement Directeur Général de l’Ecole Polytechnique de Masuku et Chef de Département Génie
Informatique et Télécommunications, pour les rôles importants qu’ils ont joué tout au long de mon parcours
académique en cycle Ingénieur à l’EPM.
 AVANT-PROPOS

Dans les entreprises ayant comme cœur de métier les télécommunications, des questions qui peuvent paraître
négligeables de prime abord prennent une importance critique. En effet la gestion de la bande passante, les
choix des politiques de qualité de services par exemple revêtent un intérêt qu’il est difficile de mesurer en
dehors de ces milieux. Cependant, avec le développement des technologies de télécommunications et
l’implantation de plus en plus profonde de l’informatique au cœur de toutes les organisations, plusieurs de
ces questions se posent désormais dans les plus grandes d’entre elles où, plus que jamais, les performances
de leurs infrastructures réseaux deviennent cruciales. La supervision du réseau informatique par exemple
devient le souci de plusieurs entreprises dont le business s’appuie fortement sur ce dernier. Dans ce mémoire
nous verrons comment un opérateur de télécommunications peut se retrouver au cœur de cette réflexion.
 RÉSUMÉ
Les technologies de télécommunication ont connu un grand succès dans les domaines professionnels. Leur
popularité n’a cessé de croître aux près de structures générant un grand trafic financier comme les banques.
Les opérateurs de télécommunications ont alors dû diversifier leurs offres tout en s’adaptant aux contraintes
liées à la sécurité et à la fiabilité que cela a impliqué. La supervision de l’infrastructure de télécommunication
s’inscrit dans cette démarche, elle vise à prévenir les éventuelles pannes et, lorsqu’elles se produisent, à limiter
aux maximum les temps de coupure qu’elles engendrent.
Moov Africa Gabon Telecom dans sa position d’opérateur de télécommunication au Gabon propose
plusieurs services d’interconnexion destinés à sa clientèle professionnelle. Récemment l’entreprise a
développé une offre consistant en l’interconnexion d’un point géographique à plusieurs autres en utilisant
son réseau mobile, le VPN3G/4G. Plusieurs entreprises s’en sont servi pour interconnecter un grand
nombre de leurs succursales sans forcément disposer des ressources nécessaires à la supervision du réseau
ainsi crée. Dans ce contexte, Moov Africa Gabon Telecom met à leur disposition sa plateforme de
supervision centrale, une démarche qui suggère un risque de sécurité pour l’opérateur.
Ce travail propose une étude de l’installation d’une plateforme de supervision secondaire mise à disposition
de ces clients et dédiée aux liaisons VPN3G/4G pour répondre à ce problème. Cette étude s’est réalisée en
trois phases. D’abord il a été question d’étudier l’infrastructure du réseau opérateur afin de définir l’objet de
supervision de la plateforme secondaire, les VPN3G/4G. Puis, il s’est agi de présenter les mécanismes de
supervision en production chez l’opérateur afin de mettre en lumière les limites de la démarche de leur mise
à disposition pour d’éventuels clients. Enfin, nous avons conçu une plateforme de supervision susceptible
de répondre à cette problématique, nous l’avons installée et testée.
Ces travaux ont posé les bases du déploiement d’un système de supervision parallèle dédié aux VPN3G/4G
qu’il sera moins risqué pour l’opérateur de mettre à la disposition de ses clients. En effet, la compromission
de cette plateforme se limitera dans le pire des cas aux extrémités des VPN3G/4G et non à l’ensemble du
réseau de l’entreprise Moov Africa Gabon Telecom. La plateforme installée pourra servir à superviser les
bancs de tests d’architecture dans l’entreprise.

Mots-clés : Supervision ; SNMP ; Shinken ; MPLS ; VPN ; Réseau mobile ; Sécurité.

 ABSTRACT
Telecommunication technologies have seen great success in professional fields. Their popularity has
continued to grow near structures generating a large financial traffic such as banks. Telecommunications
operators then had to diversify their offers while adapting to the constraints related to security and reliability
that this implied. The supervision of the telecommunications infrastructure is part of this approach, it aims
to prevent possible breakdowns and, when they occur, to limit as much as possible the outage times they
generate.
Moov Africa Gabon Telecom in its position as a telecommunications operator offers several interconnection
services intended for its professional customers. Recently the company has developed an offer consisting of
the interconnection of a client of its core network to one or more devices of its mobile network, the
VPN3G/4G. Several customers have used it to interconnect a large number of their sites without necessarily
having the resources necessary to monitor the network thus created. In this context, Moov Africa Gabon
Telecom provides them with its central supervision platform, an approach that suggests a security risk for
the operator.
This work proposes a study of the installation of a secondary supervision platform made available to these
customers and dedicated to VPN3G/4G connections to address this problem. This study was carried out
in three phases. First it was a question of studying the infrastructure of the operator network in order to
define the object of supervision of the secondary platform, the 3G/4G VPNs. Then, it was a question of
presenting the supervision mechanisms in production at the operator's in order to highlight the limits of the
process of making them available to potential customers. Finally, we designed a monitoring platform likely
to respond to this problem, we installed and tested it.
This work laid the foundations for the deployment of a parallel supervision system dedicated to 3G/4G
VPNs that it will be less risky for the operator to make available to its customers. Indeed, the compromise
of this platform will be limited in the worst case to the ends of the 3G/4G VPNs and not to the entire
Moov Africa Gabon Telecom’s network. The installed platform can be used to supervise the architectural
test benches in the company.

Keywords: Supervision; SNMP; Shinken; MPLS; VPN; Mobile Network; Security.

 LISTE DES FIGURES

Figure 1 : Organigramme de MAGT ............................................................................................................................. 4

Figure 2 : Architecture d'un réseau MPLS ................................................................................................................ 8
Figure 3 : Architecture du Backbone MPLS .............................................................................................................. 9
Figure 4 : Schéma global du réseau de Moov Africa Gabon Telecom ..........................................................10
Figure 5 : Switch L3 Cisco ASR 9000 .........................................................................................................................11
Figure 6 : ASR 1001 ..........................................................................................................................................................12
Figure 7 : ASR 1006 .........................................................................................................................................................12
Figure 8 : Cisco Catalyst 6807 XL ................................................................................................................................13
Figure 9 : Cisco Catalyst 6500 ......................................................................................................................................13
Figure 10 : Cisco ASR 920..................................................................................................................................................14
Figure 11 : Cisco Catalyst C9300 .................................................................................................................................14
Figure 12 : Connecteur RJ45, modules SFP électrique et optique ................................................................15
Figure 13 : VPN One Click ..............................................................................................................................................17
Figure 14 : VPN site à site ..............................................................................................................................................17
Figure 15 : VPN d'accès à distance .............................................................................................................................18
Figure 16 : Réseau mobile 3G/4G ...............................................................................................................................19
Figure 17 : Hand-Over .....................................................................................................................................................20
Figure 18 : Réseau mobile MAGT ................................................................................................................................20
Figure 19 : Acheminement vers un réseau IP........................................................................................................21
Figure 20 : Liaison VPN 3G/4G ....................................................................................................................................22
Figure 21 : Quelques fonctionnalité de Orion .......................................................................................................23
Figure 23 : Dashboard d'Orion ....................................................................................................................................24
Figure 24 : Outils de recherche d'Orion ...................................................................................................................25
Figure 25 : Courbe de trafics d'une interface ........................................................................................................25
Figure 22 : SNMP................................................................................................................................................................27
Figure 26 : Accès à Orion ................................................................................................................................................28
Figure 27 : Plateforme alternative de supervision..............................................................................................29
Figure 28 : Architecture de Shinken ..........................................................................................................................34
Figure 29 : Quelques partenaires de Shinken .......................................................................................................35
Figure 30 : Laptop .............................................................................................................................................................37
Figure 31 : réseau de test ...............................................................................................................................................37
Figure 32 : Taux de charge de la RAM de la VM avec 4GB ...............................................................................38
Figure 33 : Taux de charge CPU avec 2 cœurs virtuels .....................................................................................39
Figure 34 : Matériel...........................................................................................................................................................39
Figure 35 : Setup du serveur.........................................................................................................................................41
Figure 36 : UI installation ...............................................................................................................................................41
Figure 37: Choix des logiciels préinstallés..............................................................................................................42
Figure 38 : Compte admin..............................................................................................................................................43
Figure 39 : Interface réseau du serveur ...................................................................................................................43
Figure 40 : Rack CENACOM ...........................................................................................................................................44
Figure 41 : Réseau d'installation.................................................................................................................................45
Figure 42 : Dashboard Shinken ...................................................................................................................................47
Figure 43 : ajout du routeur de test ...........................................................................................................................48
Figure 44 : Ajout du serveur de supervision à la liste autorisée ...................................................................49
Figure 45 : Reponse snmpwalk ...................................................................................................................................49
Figure 46 : Le routeur de test dans la liste des équipements .........................................................................50
Figure 47 : services supervisés ....................................................................................................................................50
Figure 48 : Utilisation des interfaces ........................................................................................................................51
Figure 49 : Vue générale .................................................................................................................................................52
Figure 50 : Sous interface correspondant au VPN3G4G ...................................................................................54
 LISTE DES TABLEAUX

Tableau 1 : Liste des NMS retenus .............................................................................................................................32

Tableau 2 : caractéristiques du serveur...................................................................................................................40
Tableau 3 : récapitulatif de l'installation du serveur .........................................................................................44
 LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES

(E)LSR (Edge)Label Switching Router

ACL Access List

ADSL Asymmetric Digital Subscriber Line

APN Access Point Name

Backhaul Réseau sans fils de transport des communications mobiles

BSC base station controller

BTS Base Transceiver Station

CN Core Network

CNPI Centre National de Production Internet

CNS Centre National de Supervision

CPU Central Processing unit

E Edge Internet

EMS Energy Management System

EPM Ecole Polytechnique de Masuku

FH Faisceau Hertzien

FO Fibre Optique

FTTH Fiber to the Home

GGSN Gateway GPRS Support Node

GW Gateway (Équipement de sortie)

HLR Home Location Register

HSS Home Suscriber Server

ICMP Internet Control Message Protocol

IMSI International Mobile Suscriber Identity

IP Internet Protocol

IPsec Internet Protocol Security

LAN Local Area Network

LDP Label Distribution Protocol

LLI Liaison Louée Internet

LSPM Liaison Spécialisée Point à Multipoint

LSPP Liaison Spécialisée Point à Point

MAGT Moov Africa Gabon Telecom

MIB Management Information Base

MME Mobility Management Entity

MP-BGP Multiprotocol Border Gateway Protocol

MPLS Multiprotocol Label Switching

MSAN Multiservice Access Node (central de distribution multiservice)

MSC Mobile services Switching Center

MSISDN Mobile Station International Subscriber Directory Number

NMS Network Management System

NPM Network Performance Monitor

OLT Optical Line Termination (central de distribution FTTH)

OS Operating System

OSI Open System Interconnexion

P Provider

P-GW Packet Gateway

PE Provider Edge

RAID Redundant Array of Independent Disks

RAM Random Access Memory

RDP Remote Desktop Protocol

RSVP Reservation Protocol

S-GW Serving Gateway

SGSN Serving GPRS Support Node

SNMP Simple Network Management Protocol

SSL Secure Socket Layer

UE User Equipement

UGW Unified Gateway

VPN Virtual Private Network

 TABLE DES MATIÈRES

INTRODUCTION ............................................................................................................................................................... 1

CHAPITRE 1 Présentation de MOOV AFRICA GABON TELECOM et du service d’accueil ............ 3

1.1 Moov Africa Gabon Telecom ......................................................................................................................... 3

1.2 Présentation du CNPI ....................................................................................................................................... 5

1.3 Compétences acquises ..................................................................................................................................... 6

CHAPITRE 2 Présentation de l’infrastructure réseau et du système de supervision de

l’entreprise MAGT ................................................................................................................................................................. 7

2.1 Réseau cœur IP-MPLS à MAGT .................................................................................................................... 7

2.1.1 Architecture ................................................................................................................................................ 7

2.1.2 Équipements .............................................................................................................................................11

2.1.3 Protocoles ..................................................................................................................................................15

2.2 VPN 3G/4G et Supervision à Moov Africa Gabon Telecom ............................................................16

2.2.1 VPN................................................................................................................................................................16

2.2.2 Réseau mobile 3G/4G ...........................................................................................................................18

2.2.3 Supervision des liaisons VPN 3G/4G à MAGT ............................................................................22

2.2.4 Présentation du logiciel Orion et des limites de son usage à MAGT .................................24

2.2.5 Protocole SNMP .......................................................................................................................................26

CHAPITRE 3 Installation et test de la plateforme de supervision alternative ....................................30

3.1 Dimensionnement de la plateforme ........................................................................................................30

3.1.1 Sélection du logiciel de supervision ...............................................................................................30

3.1.2 Simulations ................................................................................................................................................35

3.2 Implémentation et tests ................................................................................................................................39

3.2.1 Installation du serveur .........................................................................................................................40

3.2.2 Installation du système de supervision ........................................................................................44

3.2.3 Installation de Shinken .........................................................................................................................45

 3.2.4 Test................................................................................................................................................................47

RECOMMANDATIONS .................................................................................................................................................53

CONCLUSION ....................................................................................................................................................................55

BIBLIOGRAPHIE ..................................................................................................................................................................i

ANNEXE I ...............................................................................................................................................................................v
 INTRODUCTION

De plus en plus d’entreprises possèdent une division réseau et informatique. Cela s’explique par le
fait que l’outil informatique a aujourd’hui une place prépondérante dans la gestion des ressources
matérielles et humaines de l’entreprise. Qu’il s’agisse de la gestion des stocks ou de réunions avec
des collaborateurs localisés sur des sites distants, posséder des moyens de télécommunications
fiables et sécurisés a un impact important sur les performances de l’entreprise. Par exemple,
certaines entreprises font appel à des opérateurs de télécommunications pour centraliser le
traitement de données recueillies sur plusieurs succursales en un seul point géographique. Ainsi,
elles ont une vue globale des performances de leur business et peuvent ajuster en temps réel leur
stratégie de management. A ce stade, l’infrastructure informatique d’une entreprise tend à devenir
un rouage crucial dans son fonctionnement et son développement.

Cette tendance pousse les opérateurs de télécommunications à travailler sur les limites de ce qu’il
est possible de proposer en termes de solutions tout en garantissant leur fiabilité. MOOV AFRICA
GABON TELECOM (MAGT) dans sa position d’opérateur de téléphonie mobile et de
télécommunications, propose un très grand nombre de solutions qui tirent parti de son
infrastructure réseau dans le but de satisfaire ses clients. Un de ses produits en pleine phase
d’adoption qui allie la disponibilité de son réseau mobile à la flexibilité du cœur de son réseau est
le VPN 3G/4G. Le nombre croissant de souscription à cette solution rendent les questions liées à
sa fiabilité importantes. Plusieurs clients de l’offre ne disposent pas des ressources nécessaires à la
supervision de leur réseau VPN3G/4G. Ils font donc appel à MAGT pour pallier à cette lacune.
Dans la mesure où donner un accès au réseau central de supervision de MAGT constitue une
potentielle vulnérabilité dans son système de sécurité, comment garantir aux consommateurs de ce
service un support de supervision efficace tout en minimisant l’exposition du réseau de MAGT à
des menaces?
Dans ce mémoire, nous nous emploierons à proposer une solution à cette problématique : le
déploiement d’une plateforme de supervision alternative dédiée aux liaisons VPN-3G/4G. Le
développement de cette solution se fera en trois parties, encadrées par une introduction et une
conclusion. La première partie sera dédiée à la présentation de l’entreprise MAGT avec un accent
mis sur le Centre National de Production Internet, le service d’accueil. La deuxième partie sera
dédiée à la présentation de l’infrastructure du réseau cœur de l’entreprise ainsi qu’une définition des
technologies à l’œuvre dans une liaison VPN 3G/4G. Nous en profiterons pour présenter les

Page 1 sur 56
mécanismes de supervision en production chez MAGT en soulignant les limites dont ils font
montre dans le cadre des liaisons VPN3G/4G. Enfin, la troisième partie sera dédiée au
dimensionnement et à l’installation de la plateforme de supervision alternative. Nous conclurons
cette partie par un test de la plateforme sur un équipement dédié à cet usage.

Page 2 sur 56
CHAPITRE 1 Présentation de MOOV AFRICA GABON TELECOM et
du service d’accueil

Il convient de situer le contexte dans lequel les travaux qui vont être présentés ont été réalisés.
Dans ce chapitre, Nous allons présenter Moov Africa Gabon Telecom en nous en appesantissant
sur les charges et les activités du Centre National de Production Internet, notre service d’accueil.

1.1 Moov Africa Gabon Telecom

Moov Africa Gabon Telecom est un opérateur de télécommunications né du rachat de l’entreprise

Gabon Telecom par. L’entreprise propose plusieurs offres à un publique lambda par ses
abonnements de téléphonie mobile et fixe, et de connexion domestique haut débit. Elle propose
également des offres pour une clientèle professionnelle notamment des liaisons internet dédiées et
des interconnexions entre des points géographiquement éloignés.
L’entreprise se décompose en cinq (5) grandes directions :
• La direction générale
• La direction des services
• La direction réseau
• La direction administrative et financière
• Le secrétariat général
La figure 1 présente la structure de MAGT :

Page 3 sur 56
 Figure 1 : Organigramme de MAGT

Notre stage a été effectué au sein de la direction réseau. Elle se charge de la veille technologique
dans le cadre des services que fournit ou que pourrait fournir Moov Africa Gabon Télécom a ses
clients. Elle defini les politiques d’investissement et de déploiement des infrastructures de son
réseau informatique. Elle veille à la mise en condition et à l’exploitation de cette infrastructure. Elle
se compose de trois divisions :
• La division du systeme d’information : Elle oriente l’architecture des infrastructures
informatiques pour garentir au mieux la sécurité et la fiabilité du système d’information de
MAGT. Elle se charge de l’installation et du suivi des services que porte l’infrastructure
réseau de l’entreprise.
• Division ingénieurie et développement : Sa mission est dans un premier temps de planifier
l’évolution des réseaux fixes mobiles et internet (architecture, topologie, fonctionnalité,

Page 4 sur 56
 mise à niveau logicielle et matérielle, capacité et technologie). Puis de concevoir et de définir
les installations nécéssaires a la garantie de la qualité de services liée ces installations dans
des conditions de coût et de délai optimales.
• La division exploitation et maintenance : Elle exploite et maintient les réseaux Fixe, Internet
et Mobile. Elle oriente et élabore les projets de qualité et des services pour l’exploitation, la
maintenance préventive et curative des infrastructures et équipements en garantissant la
disponibilité et la qualité de service aux clients. Le CNPI, notre service d’accueil, est un des
services de cette division.

1.2 Présentation du CNPI

Nous avons effectué notre stage au Centre National de Production Internet au sein de la division
exploitation de la direction réseau, situé au premier étage du CENACOM au 9 étages. Ce centre a
comme charge la maintenance et l’administration du Réseau Coeur (CN) de MAGT. En effet, le
CN de l’entreprise s’étend sur l’ensemble du territoire gabonais, de ce fait plusieurs opérations de
maintenance ont lieu sur ce réseau :
• La montée en capacité des liens qui constituent le réseau
• La mise à jour des équipements du réseau
• La migration vers de nouveaux équipements
• Le déploiement de nouveaux équipements
• Gestion des disfonctionnements des noeuds du réseau
• Modification de la topologie virtuelle du réseau
De même l’exploitation du CN est une activité dont se charge le CNPI. Elle consiste en la
configuration et en la mise en service d’offres de télécommunications directement associés au CN
de l’entreprise :
• Les Liaisons Spécialisées Point à point (LSPP) : Des liaisons destinées à relier un siège à
une de ses agences.
• Les liaisions spécialisés point multipoint (LSPM) : Le principe est le même que
précédemment. Ici cependant il s’agit de relier une entreprise et plusieurs de ses agences
simultanément.
• Les liaisons louees internet (LLI) : Cette offre contient une connexion à internet avec un
débit stable et constant en plus d’une plage d’adresses publiques.
• Les liaisons VPN 3/4G : Ce sont des liaisons point à point dont l’une des extrémité est de
l’autre côté du réseau mobile. Ces laisons ont comme particularité leur facilité d’installation

Page 5 sur 56
En tant que stagiaire dans ce service, notre rôle a été d’assister les opérations d’exploitation et de
maintenance. Notamment la migration et le déploiement de nouveaux équipements. Les activités
au CNPI se résument alors à réaliser les configurations relatives à certaines offres commercialisées
par l’entreprise, et à maintenir son réseau cœur.

1.3 Compétences acquises

Notre stage nous a permis de découvrir le métier d’ingénieur d’exploitation en milieu d’opérateur
de télécommunications. Nous avons pu observer et participer aux travaux qui régissent le
fonctionnement du CNPI. Etant un organe portant un grand nombre de services commercialisés
par l’entreprise, nous avons eu une vue d’ensemble de l’infrastructure réseau de l’entreprise.
Notamment dans nos travaux de :
• Mise à jour de la topologie du réseau de l’entreprise : consistant à vérifier sinon à mettre à
jour certains éléments de la topologie du réseau (adresses IP, ports, etc) sur une carte.
• Migration et création de liaisions LLI ou Point à Point sur de nouveaux commutateurs
d’accès.
• Configuration d’équipement d’extrémité : des routeurs client LLI, des box et des routeurs
pour les liaisons VPN3G/4G, une box pour une liaison FTTH.
• Configuration d’une liaison LLI su un équipement d’agrégation.
• Test et livraison de liaisons LLI
• Présentation du proget de stage

Page 6 sur 56
 CHAPITRE 2 Présentation de l’infrastructure réseau et du système de
supervision de l’entreprise MAGT

Ce chapitre a pour objet la présentation des concepts clés dans la définition d’une liaison VPN
3G/4G. Nous commencerons par définir les technologies à l’œuvre dans ce type de liaison puis
nous verrons sommairement leur implémentation dans le réseau de MAGT.

2.1 Réseau cœur IP-MPLS à MAGT

A son apparition dans les années 90, la technologie MPLS avait pour objectif de proposer un
mécanisme de transport des paquets plus efficace que le protocole IP au sein des cœurs de réseau.
Cet objectif est alors atteint en mettant en œuvre le principe de commutation de label alliant à la
fois la précision du routage et les performances de la commutation. Un label est simplement un
champ de 20 bits dans l’entête du paquet IP. Si cet avantage reste effectif aujourd’hui, d’autres
attributs de la MPLS le rendent aujourd’hui incontournable dans les cœurs de réseau opérateurs.
La variété des services qu’il supporte, sa capacité d’encapsulation des flux et la granularité qu’il
propose dans la gestion de la qualité de service en sont quelques exemples.

2.1.1 Architecture

Comme communément dans les environnements de calcul distribués [1], l’architecture d’un réseau
cœur MPLS peut être entièrement décrite en trois parties.
- La partie Core, La partie la plus sensible, le centre qui communique avec toutes les parties
du réseau et qui les relie.
- La partie Aggregation : déployée dans le but de couvrir ou d’atteindre les zones à fort
potentiel de trafic de manière à le ramener à la partie Core.
- La partie Access : qui sert d’interface physique entre un réseau MPLS et l’extérieur. C’est
à cette couche que les données sont conditionnées de manière à être transportées dans le
réseau MPLS.
Ces couches sont composées d’équipements réseau portant le nom de commutateurs de niveau
trois au sens du modèle OSI. Rappelons que si un commutateur est un équipement réseau n’ayant
qu’une connaissance locale du réseau de par ses interfaces, un commutateur de niveau 3 est capable
de faire du routage. Autrement dit, sa connaissance du réseau s’étant à toutes les destinations qu’il
peut atteindre y compris les nœuds intermédiaires. Ces équipements jouent deux rôles majeurs
dans un CN IP-MPLS [2] :

Page 7 sur 56
Les routeurs LSR (Label Switching Router) qui ont pour rôle la commutation de labels. N’étant
connectés qu’à d’autres routeurs du réseau MPLS, ils font transiter les paquets à l’intérieur du cœur
du réseau de l’opérateur en accord avec sa politique de qualité de service. Ces routeurs accélèrent
les flux dans le cœur du réseau et garantissent à l’opérateur une allocation efficace des ressources
en accord avec les objectifs de qualité. Ils appartiennent à la partie Core.

Les routeurs ELSR (Edge Label Switching Router) en bordure du réseau operateur, ils possèdent
des interfaces IP traditionnelles et des interfaces MPLS. Ils ont pour rôle de calculer les routes
d’acheminement des paquets IP à travers le cœur du réseau, et d’assurer la transition entre le réseau
MPLS et les réseaux IP externes. A ces équipements de la partie Aggregation, des équipements
d’accès sont connectés.

Figure 2 : Architecture d'un réseau MPLS

Ces équipements peuvent être de natures différentes mais ils ont comme rôle d’atteindre chaque
client individuellement. Il peut s’agir de commutateurs, de centraux de distribution internet ou
toute sorte d’équipements susceptibles de générer un trafic important à transmettre à la partie Core.
Au sein de MAGT l’architecture MPLS est appliquée de la manière suivante :
Deux Commutateurs EDGE Internet (E) sont directement connectés au réseau international. Ils
font transiter tout le trafic internet destiné au réseau de distribution de l’entreprise. Ces deux
équipements sont reliés à deux autres commutateurs, les Providers (P). Dans ce contexte ce sont

Page 8 sur 56
des routeurs LSR. Ces Providers sont reliés aux différents Providers EDGE (PE) disséminés sur
toute l’étendue du territoire gabonais. Si les commutateurs E et P sont installés au CNPI, les
Providers Edge sont installés dans des Point de Présence (PoP) sur des sites distants. Ces sites sont
reliés entre eux grâce à des liaisons Fibres Optiques (FO) déployées par AXIONE, un prestataire
de MAGT. Auparavant ces liaisons étaient assurées par des Faisceaux Hertziens (FH), moins
performantes en termes de bande passante, de latence et de stabilité. Aujourd’hui ces liaisons
servent de backup ou de lien dans des zones encore inaccessibles en liaisons FO. Les PE sont donc
les points de jonction entre le cœur du réseau de MAGT et tous les équipements de distribution de
l’entreprise. Il s’agit :
• Des MSAN-OLT dans le cadre de la distribution de l’ADSL (Asymetric Digital Suscriber
Line) ou des liaisons FTTH (Fiber To The Home) ou encore de telephonie fixe.
• D’agrégateurs, des commutateurs de grande capacité dans le cadre de liaisons spécialisées
(LSPP, LSPM) ou des liaisons LLI.
• De BTS (Base Transceiver Station) du réseau mobile.
L’ensemble constitué des routeurs E,P,PE, des liaisons qui les relient ainsi que leur redondances
porte le nom de Backbone IP-MPLS.

Figure 3 : Architecture du Backbone MPLS

Ajoutons que les PE sont reliés suivant à une topologie en boucle qui assure l’existence d’un lien
alternatif en cas de rupture d’une liaison physique. De plus, chaque PE est relié à chaque P. Le
deuxième P étant un équipement de secours en cas de défaillance du premier.

Page 9 sur 56
 Figure 4 : Schéma global du réseau de Moov Africa Gabon Telecom

Sur ce schéma général on peut voir la place que le backbone occupe dans le réseau de MAGT. Par
exemple :
• Il relie les centraux de distribution internet (MSAN OLT) grand public au réseau
international (Internet).
• Il relie les centraux de téléphonie fixe (MSAN OLT) à l’ensemble du réseau téléphonique
de l’entreprise.
• Il achemine le trafic de certaines BTS vers le CN du réseau mobile.
• Il transporte les communications des liaisons LSPP, LSPM, LLI et VPN3G/4G.
En résumé, le backbone IP-MPLS transporte la majeure partie des services commercialisés par
MAGT. La technologie MPLS lui confère la capacité de supporter la voix, la donnée et l’image.
C’est un réseau Triple-Play.

Page 10 sur 56
2.1.2 Équipements

Le CN de MAGT est principalement composé d’équipements CISCO. Le constructeur propose

plusieurs gammes de produits appropriés en milieu opérateur. La gamme ASR (Aggregation
Services Routers) par exemple se compose de commutateurs de niveau trois conçus pour répondre
à des besoins de distribution à l’échelle de métropoles. Ce sont des équipements modulaires, ils
peuvent donc être configurés par rapport à la charge qui va leur être appliquée. Autrement dit, on
peut leur ajouter, en option, des cartes à fin d’étendre leur capacité de traitement et le nombre de
leurs ports. Ils sont privilégiés lors de déploiement de Points de Présence (PoP).

Figure 5 : Switch L3 Cisco ASR 9000

Page 11 sur 56
 Figure 6 : ASR 1001

Figure 7 : ASR 1006

Ces commutateurs robustes sont conçus pour équiper les réseaux métropolitains modernes grâce
au flux considérable de données qu’ils peuvent traiter [3]. Leur système d’exploitation IOS XE,
basé sur Linux, est capable de porter une grande variété de services. Il offre la possibilité aux
administrateurs d’exécuter des applications plutôt complexes pour des équipements de réseau. Il
est par exemple possible d’exécuter directement des applications sur ces équipements [4]. Par
exemple, les E et les P sont des ASR 9000. Selon la demande certains PE peuvent être l’un des trois
équipements illustrés aux figures 5,6 et 7.
Dans le réseau de MAGT, plusieurs commutateurs de niveaux 2 ou 3 constituent la partie Access.
Essentiellement ils étendent le nombre de ports physiques disponibles sur les PE. Les agrégateurs
par exemple sont des commutateurs de niveaux trois modulaires, pouvant attendre un grand
nombre de ports physiques. Ils sont généralement associés à des PE dans PoP concentrant un

Page 12 sur 56
grand nombre de clients. La gamme Catalyst de Cisco propose des équipements se prêtant à cet
usage. Les modèles Catalyst 6500 et 6807 XL sont utilisés dans le réseau de l’entreprise. Ce sont
des commutateurs massifs pouvant attendre une centaine de ports. Ils sont eux aussi modulaires.

Figure 8 : Cisco Catalyst 6807 XL

Figure 9 : Cisco Catalyst 6500

Pour les PoP encore plus sollicités, quelques commutateurs peuvent être ajoutés aux agrégateurs.
Comme modèles souvent utilisés pour cet usage, on a des Cisco ASR 920 ou des Cisco Catalyst
9300. Ces équipements par contre ne sont pas modulables. Ils servent principalement aux clients
entreprise souscrivant aux offres de liaisons spécialisées ou louées internet.

Page 13 sur 56
 Figure 10 : Cisco ASR 920

Figure 11 : Cisco Catalyst C9300

Comme on peut le voir sur les illustrations, ces équipements possèdent en général plusieurs types
de ports. Ils varient selon leurs connecteurs et leurs débits. Deux types de ports nous intéressent :
les ports RJ45, les ports SFP.
• Les port RJ45 sont très rependus, Ils fonctionnent avec des supports électriques et peuvent
attendre des débits variés (100Mbps, 1Gbips, 10Gbps).
• Les ports optiques se popularisent sur les équipements récents et offrent une plus grande
flexibilité en termes de débits et de supports. On les utilise avec des modules dits SFP pour
Small Formefactor Plugable [4]. Ces modules sont vendus séparément et il en existe une
grande variété. On a des modules électriques qui transforment les ports SFP en ports RJ45
leurs conférant les mêmes caractéristiques, et les modules SFP optiques qui s’utilisent avec
des jarretières optiques monomodes ou multimode. Les modules optiques permettent des
vitesses bien plus élevées de l’ordre de 10 à 40Gbps et sur de plus grandes distances. En
effet les supports électriques sont déconseillés pour des distances de plus de 100 mètres
tandis que les supports optiques peuvent atteindre des portées de 80 kilomètres.

Page 14 sur 56
 Figure 12 : Connecteur RJ45, modules SFP électrique et optique

2.1.3 Protocoles

Les opérateurs de télécommunication privilégient la MPLS à d’autres pour interconnecter le cœur

de leur réseau à cause de plusieurs protocoles qui la rendent intéressante dans ce contexte. Citons
quelques mécanismes à l’œuvre durant son fonctionnement :
• La technologie MPLS s’implémente par-dessus un protocole IGP déjà fonctionnel. Elle
supporte un grand nombre de protocoles de routage comme OSPF (Open Shortest Path
First) ou même RIP et ce, même s’ils sont utilisés simultanément sur différentes zones du
réseau. Ainsi chaque routeur MPLS a une connaissance exhaustive de l’ensemble des nœuds
du CN. Le protocole MPLS va alors se servir de cette carte globale de routage pour faire
transiter les paquets dans le réseau [5].

• Dans les réseaux opérateurs, il est possible que plusieurs zones de routage existent. Par
exemple les protocoles de routage internes au réseau (OSFP ou EIGRP) ne sont pas les
mêmes utilisé pour communiquer avec le réseau international (BGP). Ajouté à cela, les
réseaux virtuels peuvent transiter à travers plusieurs zones. Les routeurs utilisent alors le
protocole MP-BGP pour s’échanger toutes ces informations de routage. Ainsi même sans
appartenir à une zone de routage, un routeur peut tout de même joindre efficacement les
destinations de cette dernière [6].

• Dès lors que les routeurs sont interconnectés, ils vont construire des LSP (Label Switching
Path). Ce sont des chemins de commutation basés sur des FEC (Forwarding Equivalence

Page 15 sur 56
 Class). Les FEC sont des classes d’adresses qui seront acheminées de la même manière dans
le réseau cœur suivant des critères tels que la destination et la qualité de service (QoS)
associée (débit, latence). Pour acheminer les paquets, les routeurs commutent des labels. Le
protocole LDP (Label Distribution Path) [4] sert à l’établissement et à la distribution de ces
labels entre les nœuds du CN.

• Pour garantir la QoS des liaisons, le protocole RSVP (ReSerVation Protocol) [5] par
exemple est utilisé pour réserver de la bande passante sur un lien. Les routeurs MPLS
peuvent donc allouer efficacement les ressources ce qui rend les services de
télécommunication particulièrement stables en performance.

• La technologie MPLS permet une grande flexibilité dans l’encapsulation des

communications. Une VRF [6] par exemple est un mécanisme par lequel plusieurs tables
de routages totalement indépendantes vont coexister dans le même routeur MPLS. Ces
tables peuvent réutiliser les mêmes adresses privées sans risque de conflit. Elles seront
cependant identifiées par un Route Distinguisher (RD).

En résumé le protocole MPLS doit son succès à la flexibilité qu’il propose dans l’encapsulation des
communications et à sa robustesse nécessaire aux opérateurs de télécommunication.

2.2 VPN 3G/4G et Supervision à Moov Africa Gabon Telecom

Les Réseau Virtuels Privés (VPN) sont très populaires de nos jours. Dans une société où les
informations les plus sensibles sont transmises via des réseaux de télécommunications, ils sont
devenus incontournables. Au CNPI les VPN sous toutes leurs formes sont des services très prisés.
Cependant, la variété de forme et d’usages qu’on leur attribue jettent parfois la confusion sur ce
qu’ils sont. Dans cette partie nous allons définir précisément la notion de VPN en nous intéressant
particulièrement aux principales technologies au cœur d’une liaison VPN 3G/4G. Cela nous
mènera aux Système de supervision déployé pour ces liaisons.

2.2.1 VPN

Page 16 sur 56
L’acronyme VPN est mis pour Virtual Private Network, Réseau privé virtuel en français. L’idée
sous-jacente est de créer par-dessus un réseau physique (réseau underlay) un réseau virtuel (réseau
overlay) complètement étanche à toutes les autres communications qui ont lieu sur ce réseau
physique. Ces systèmes sont particulièrement utiles lorsqu’il faut isoler des communications
transitant par un réseau de télécommunication public ou extérieur.
D’une manière générale, les VPN peuvent être classés selon les services et les types de trafic pour
lesquels ils sont utilisés. Citons trois principaux types de VPN :

• Les VPN OneClick : Généralement utilisés par des particuliers, il s’agit d’un lien sécurisé
(au niveau 7) entre un client (une application sur un ordinateur ou un smartphone) et un
concentrateur (le serveur de l’entreprise qui propose le service). L’utilité de cette
configuration est de masquer l’identité et/ou la position du client. Du point de vue
d’internet Les requêtes semblent arriver du concentrateur. Les restrictions liées à la
localisation ou à l’identité du client sont donc inapplicables.

Figure 13 : VPN One Click

• VPN de site à site : il s’agit simplement d’une liaison point à point à laquelle une couche de
sécurité (IPsec par exemple) a été ajoutée. Le protocole IPsec [10] opère au niveau 3. Il est
totalement transparent pour les utilisateurs du VPN cependant les communications entre
les deux extrémités son chiffrées. Ainsi, elles ne sont compréhensibles qu’aux extrémités
du tunnel. Ce type de VPN est utile lorsque le transit de l’information implique un réseau
hors de contrôle de l’entité qui le produit.

Figure 14 : VPN site à site

Page 17 sur 56
 • Les VPN MPLS : Dans un réseau MPLS, l’expression VPN désigne simplement un réseau
virtuel étanche créé dans le but de relier deux réseaux situés à deux points géographiques
éloignés. Notons que ce VPN peut être de niveau 2, préférable pour une communication
plus sécurisée, ou de niveau 3, plus évolutifs. C’est cette définition qui est sous entendue
dans le service VPN3G/4G, un VPN de niveau 3.

Figure 15 : VPN d'accès à distance

2.2.2 Réseau mobile 3G/4G

Un réseau mobile est un réseau sans fils qui prend en charge le hand-over ou transfert inter-
cellulaire. Ainsi un grand nombre d’utilisateurs peut être connecté simultanément même en se
déplaçant sur de grandes distances à grande vitesse. Un réseau mobile est constitué de trois parties
[11] :
• L’UE (User Equipement) : L’appareil connecté au réseau mobile. Il peut s’agir d’un
smartphone, d’un ordinateur ou d’un TPE (Terminal de payement électronique). L’UE doit
être équipé d’une SIM pour être identifiable sur le réseau.

• Le RAN (Radio Access Network) : C’est le réseau de couverture du réseau mobile. Il se

compose de stations radio électriques disséminées de manière à couvrir efficacement des
zones géographiques. Les BTS (Base Transceiver Station) ont donc la charge d’agréger
toutes les UE dans leurs zones de couverture en leurs fournissant une QoS satisfaisante.
Les liaisons entre les BTS et les UE sont sans fils. Les BTS sont gérées par des contrôleurs
BSC (BSC pour Base Station Controller) au sein du RAN. Quoique, sur les dernières
générations de réseaux mobiles, plusieurs de ses fonctions sont de plus en plus intégrées
aux BTS ou au cœur du réseau mobile.

Page 18 sur 56
 • Le CN (Core Network) : C’est le centre de commutation et de contrôle du réseau mobile.
Il se compose notamment du commutateur téléphonique central (MSC) de la HLR, la base
de données des abonnés et d’un réseau d’acheminement des paquets IP.

Figure 16 : Réseau mobile 3G/4G

Lorsqu’un utilisateur final (UE) initialement connecté à une BTS doit être pris en charge par une
autre, soit parce que cette dernière est saturée ou parce que l’UE bénéficierait d’une meilleure
couverture sur l’autre BTS, le transfert de communication se fait sans coupure perçue par
l’utilisateur. Cette Opération est assurée soit par le BSC si ce dernier est également connecté à
l’autre BTS, soit par un MSC si le transfert doit s’effectuer entre deux BSC.

Page 19 sur 56
 Figure 17 : Hand-Over

Le réseau mobile de Moov Africa Gabon Telecom fonctionne sur les trois avant dernières
générations de réseaux mobiles (2G, 3G et 4G). Pour ce réseau, MAGT se fournit chez Huawei.
L’entreprise adopte donc l’architecture recommandée par le constructeur.

Figure 18 : Réseau mobile MAGT

La partie RAN est composée de BTS 3G et 4G dont les communications sont transportées par un
Backhaul dit IPRAN. Dans le CN du réseau, un MME gère la commutation centrale. Le réseau
d’acheminement vers des réseaux IP se compose d’une UGW [12] (Unified Gateway) qui cumule
les rôles de P-GW, S-GW et GGSN. Un firewall filtre les communications entre le réseau mobile

Page 20 sur 56
et les réseaux extérieurs. L’UGW et le MME sont connectés à une HLR qui les renseigne sur tous
les abonnés mobiles de MAGT. En ce qui concerne les réseau 3G et 4G, nous nous intéressons
uniquement aux équipements du CN qui participent à l’acheminement des paquets IP dans le réseau
mobile.

Figure 19 : Acheminement vers un réseau IP

Lorsqu’un abonné du réseau mobile demande à accéder à un réseau IP comme Internet, la requête
est traitée par l’UGW. Cet équipement interroge l’HLR afin de regrouper les informations relatives
à cet abonné :
- Son identifiant IMSI (International Mobile Subscriber Identity)
- Son numéro de téléphone MSISDN (Mobile Station International Subscriber Directory
Number)
- Les services autorisés pour cet abonné (Internet, appels téléphoniques, etc)
- L’APN (Access Point Name) de l’abonné
L’APN est associé à un réseau IP dans l’UGW. L’équipement va donc rediriger la requête vers le
réseau IP correspondant en passant par le Firewall. L’UGW fixe également une adresse IP à l’UE.

En conclusion, une liaison VPN 3G/4G est simplement un VPN qui lie un routeur client (CE) à
un abonné du réseau mobile (UE). Le routeur client est connecté au backbone MPLS (généralement
en liaison FO) sur un équipement d’agrégation. On configure ce dernier et tous les équipements
intermédiaires de manière à lier en point à point avec l’agrégateur du CENACOM. De l’agrégateur
on accède au firewall du réseau mobile qui communique directement avec le réseau

Page 21 sur 56
d’acheminement des paquets IP de ce réseaux. Ainsi le CE a accès à l’abonné via une adresse IP
qui lui aura été attribuée par l’UGW.

Figure 20 : Liaison VPN 3G/4G

Clairement, ces liaisons séduisent par la facilité d’accès au réseau mobile de MAGT (Une SIM
suffit) et par la fiabilité des liaisons spécialisées que fournissent l’opérateur. Les entreprises peuvent
ainsi déployer un grand nombre de terminaux, de types différents, sur une grande étendue du
territoire gabonais, sans pour autant dépenser des frais importants dans l’installation de la liaison
proprement dite. Le réseau mobile étant déjà déployés aucune installation n’est nécessaire pour une
nouvelle liaison VPN3G/4G. Les gains financiers et en temps sont significatifs.

2.2.3 Supervision des liaisons VPN 3G/4G à MAGT

Le Centre National de Supervision (CNS) est l’organe en charge de la supervision du réseau de

MAGT. Il effectue le monitoring général de l’entièreté du réseau de l’entreprise et dans une certaine
mesure, il est capable de corriger certains disfonctionnements. Il a également à charge l’analyse des
données recueillies de son activité de monitoring. A cela on ajoute que certains services possèdent
des plateformes de supervision en interne plus spécifiques, mieux optimisés aux métriques
importantes de leurs points de vue. La DSI (Division du système d’information) par exemple
possède une plateforme de supervision dédiée à ses serveurs.

Pour mener à bien ses activités, le CNS dispose de trois outils principaux :

• Un Energy Management System (EMS) qui lui permet de contrôler l’environnement de

fonctionnement des équipements réseau (Température ambiante, tension d’alimentation,
source d’alimentation, charge des batteries de secours, apport des panneaux solaires, etc…).
Grâce à ce système, le CNS est capable d’agir sur les équipements d’alimentation à distance
(redémarrage, démarrage de l’alimentation de secours ou même le diagnostic d’une panne

Page 22 sur 56
 du système d’alimentation). Ce système est le premier rempart face à une panne sur un site
distant de MAGT.

• Master BSS : Étant donné que la plupart des systèmes radio de MAGT sont fournis par
Huawei, ce dernier fournit également une solution de monitoring des équipements de
transmission et de couverture radio. Ainsi le CNS connaît en temps réel l’état des
équipements radios. L’outil intègre également des commandes de contrôle à distance.

• Orion : Cet outil va particulièrement nous intéresser dans la mesure où il sert précisément
à surveiller l’état des équipements réseau de MAGT. Autrement dit cet outil de supervision
donne une vision globale des liens physiques et surtout virtuels entre ces derniers, et il
fournit des outils de diagnostic avancés pour d’éventuels dysfonctionnements. Par exemple,
le système notifie les administrateurs réseau lorsqu’une alimentation redondante d’un
équipement est défaillante. Il va également prévenir la saturation d’un équipement lorsque
ce dernier voit son taux de charge CPU atteindre des niveaux inquiétants. Ce système est
spécialement à disposition d’autres services que le CNS. Le CNPI par exemple en dispose
pour gérer et pour maintenir le réseau cœur de MAGT. Cependant, il n’offre en l’état
aucune interaction directe avec les équipements sous sa supervision.

Figure 21 : Quelques fonctionnalité de Orion

Page 23 sur 56
2.2.4 Présentation du logiciel Orion et des limites de son usage à MAGT

Orion est un logiciel de supervision basé sur le moteur NPM (Network Performances Monitor)
développé par Solarwinds. NPM se base sur plusieurs protocoles réseau dont ICMP et SNMP. Le
protocole SNMP est particulièrement intéressant dans la mesure où il est au cœur de la supervision
des équipements réseaux de MAGT. De plus il est complet en ce sens qu’il permet non seulement
le monitoring des équipements mais également leur configuration.

Orion met à disposition de ses administrateurs une interface web conviviale et pratique. La figure
23 présente le tableau de bord de la plateforme.

Figure 22 : Dashboard d'Orion

En un coup d’œil, l’administrateur voit le nombre d’équipements accessibles, (en bas au centre) en
signifiant les proportions des équipements en bonne santé ceux qui sont dans un état plus ou moins
critique. À droite, une liste d’interfaces du réseau triée par taux de charge, pratique pour anticiper
des saturations. Le tableau de bord permet de visualiser les sites de manière géographique. Orion
dispose d’outils de recherche efficace pour rapidement trouver l’objet de notre intérêt. À gauche,
sur la figure 24, le tableau de bord fourni une arborescence listant l’ensemble des équipements
enregistrés dans le système. Rangés par catégories ou suivant les villes du Gabon. Pour plus de
précision, Il est possible de rechercher un équipement, un site ou même un service grâce à un outil
de recherche assez fourni en filtres.

Page 24 sur 56
 Figure 23 : Outils de recherche d'Orion

Grâce à ce logiciel il est possible de voir précisément l’évolution d’un paramètre particulier. Sur la
figure 23 par exemple on peut apprécier la courbe de traffic de l’interface d’un équipement.

Figure 24 : Courbe de trafics d'une interface

Pour chaque équipement il est possible de voir le taux de charge du CPU, l’espace de la mémoire
utilisée, l’état de l’alimentation électrique de l’équipement, l’état des interfaces réseau (Up/Down).

Page 25 sur 56
Pour les interfaces il est possible de voir les taux de transferts en montée et en descente. Ces
données apparaissent sous forme de courbes comme le montre la figure qui précède. L’interface
graphique d’Orion est simple d’utilisation et affiche des informations pratiques pour se faire
rapidement une idée de la configuration et du fonctionnement général d’un équipement (VLAN,
sous-interfaces, description).
Cependant, ce système présente une limite de par l’usage qui en est faite dans l’entreprise. En effet,
plusieurs clients de MAGT, particulièrement ceux ayant souscrit à l’offre VPN 3G/4G, voient leurs
nombres de liaisons spécialisées augmenter drastiquement mais ne possèdent pas les ressources
pour les superviser. De ce fait, elles font appel à MAGT pour combler cette lacune. Pour y répondre
la solution utilisée consiste à créer un accès à Orion spécialement pour le client.

2.2.5 Protocole SNMP

Le protocole SNMP (Simple Network Management Protocol) est un protocole né en 1993 conçu
pour gérer des équipements réseau, diagnostiquer des pannes matérielles comme logiciel depuis
une seule station de gestion [13]. Il permet de remonter des informations par rapport à l’état des
équipements et il se veut léger pour ne pas saturer le réseau. Ce protocole nous intéresse
particulièrement car il est essentiel au recueil et à la remontée d’informations diverses caractérisant
l’état des l’équipements. Son principe de fonctionnement se base sur trois éléments importants :
• Le NMS (Network Management System) : il s’agit d’un programme ayant la charge
d’interroger les équipements via des requêtes « Get » (ou GetNext) et de recueillir les
informations qu’il reçoit de ces derniers via des requêtes « Response ». De plus, il est
constamment à l’écoute sur de réseau de manière à intercepter les requêtes de type « Trap
» que les équipements envoient pour l’informer de certains événements (interruption, seuil
critique, etc…).

• L’agent SNMP : c’est un programme exécuté sur l’équipement à gérer. C’est par son
intermédiaire que la station de management est capable de communiquer avec l’équipement
sur le réseau. Il traite et répond aux requêtes du manager. Le protocole SNMP étant
largement adopté dans l’industrie, la plupart des équipements possèdent un agent SNMP
par défaut. Dans le cas contraire, certains constructeurs fournissent des agents SNMP
installables. Il est donc possible de superviser une très grande variété d’équipements
(imprimantes, poste d’ordinateur, équipements réseau, serveurs, etc).

Page 26 sur 56
 • La MIB (Management Information Base) : Il s’agit d’une base de données arborescente
définie par l’ISO qui enregistre les informations liées à l’état de l’équipement. Elle contient
notamment des objets de types clef valeur (Ex : InterfaceDescription : GigabitEthernet).
L’agent SNMP interroge cette base de données pour en communiquer les informations à
la station de management. Chaque équipement possède donc sa MIB.

Figure 25 : SNMP

En pratique, un système de management réseau (NMS) grâce à sa sonde interroge l’agent d’un
équipement géré. L’agent analyse l’objet de la requête du NMS puis récupère les informations
demandées dans le MIB. L’agent renvoie les informations collectées au NMS au format SNMP.
Les communications sont effectuées via le port 161 en UDP.
Il existe plusieurs versions de SNMP. La première version est dépréciée du fait de toutes ses failles
de sécurité. Si la seconde (2c) n’apporte pas de manière significative des correctifs de sécurité, elle
est tout de même plus commode à utiliser et plus évoluée en fonctionnalité. Dans cette version,
une chaine de caractères nommée la communauté SNMP sert de mot de passe durant les
communications SNMP. La troisième version cependant est beaucoup plus sécurisé puisqu’elle
apporte une couche de chiffrement DES (Data Encryption Standard) sur les communications entre
le NMS et l’agent [14].
Ces actions consomment des ressources sur l’hôte de la plateforme. La charge augmente avec le
nombre de machines supervisées. Le choix du CPU [15] de notre serveur devra en tenir compte.

Page 27 sur 56
Le serveur de supervision Solarwinds (et tous les équipements du CN de MAGT d’ailleurs) n’est
accessible que par le Firewall de MAGT. Ainsi, toute connexion à ce serveur nécessite une
authentification sur le FireWall. Ce dernier crée ensuite une connexion sécurisée (VPN SSL [16])
entre l’administrateur et le serveur. De plus, une deuxième authentification est nécessaire sur le
serveur de supervision. Pour résumer, l’usage du serveur de supervision par un client nécessite la
création de deux comptes utilisateurs. Un compte sur le FireWall et un autre sur le serveur de
supervision. Ces deux équipements sont connectés à tous les nœuds du réseau cœur de MAGT. Il
va sans dire qu’une compromission de l’un ou de ces deux équipements donnerait un accès
privilégié à des informations sensibles (Topologie du réseau, adresses IP des équipements, etc).
Même si les accès des comptes créés sont limités, la politique de sécurité des clients étant totalement
inconnue de MAGT, cette solution suggère une faille de sécurité dans le système de l’entreprise.

Figure 26 : Accès à Orion

Pour y remédier, nous proposons l’installation d’une plateforme de supervision secondaire dans le
réseau de MAGT qui serait limitée aux liaisons VPN3G/4G des entreprises et qui seraient mise à
disposition des clients désireux d’une plateforme de supervision pour leurs liens chez MAGT.

Page 28 sur 56
 Figure 27 : Plateforme alternative de supervision

Ainsi, la compromission de cette plateforme limitera les potentielles ressources de l’attaquant au

réseau VPN3G/4G des clients et éventuellement au LAN du CNPI.

Page 29 sur 56
 CHAPITRE 3 Installation et test de la plateforme de supervision
alternative

En informatique la supervision est l’ensemble des techniques et des outils visant à connaître en
temps réel l’état des équipements d’un réseau et éventuellement mener des actions à distance sur
ces équipements. L’objectif de la supervision est de prévenir d’éventuelles pannes en analysant les
données recueillies ou, lorsqu’elles se produisent, d’en fournir des diagnostics. Par exemple, un
système de supervision peut signaler la surcharge d’un équipement ou d’un lien. Suivant le type
d’équipement le système peut même fournir des informations sur la qualité du signal reçu par
l’équipement. Bien entendu la supervision d’un réseau n’est pas indispensable à son bon
fonctionnement. Cependant, lorsque le réseau compte un grand nombre d’équipements, une panne
peut rendre plusieurs d’entre eux inaccessibles. De plus, si ces équipements sont éloignés
géographiquement, la connaissance de l’origine de la panne est importante dans l’allocation des
moyens logistiques nécessaires à sa résolution. Suivant l’importance des équipements concernés il
peut s’agir d’une centaine de clients. Dans ce contexte, chaque minute de temps de coupure peut
avoir un impact catastrophique sur le business de ces derniers et donc sur la réputation de
l’opérateur.
Dans ce chapitre nous présenterons la démarche adoptée dans la conception, l’installation et le test
de notre plateforme de supervision.

3.1 Dimensionnement de la plateforme

3.1.1 Sélection du logiciel de supervision

La supervision est un thème vaste, c’est pourquoi il convient de fixer des objectifs à atteindre dans
notre situation. Il existe plusieurs types de solutions de supervision chacune plus adaptée à un cadre
et un besoin particulier que d’autres. On les range en général dans trois grandes catégories [17] :
Les BSM (Business Service Management) : Ces systèmes sont adaptés au suivi de la qualité des
services grâce aux informations sur un système d’information (SI) et ses performances. Ils sont
moins adaptés à la surveillance des équipements mais permettent une meilleure compréhension de
l’impact des performances du système d’information sur les performances financières de
l’entreprise.

Les BAM (Business Activity Monitoring) utiles pour juger du bon fonctionnement des processus
métiers d’une entreprise. Ils fournissent des rapports compréhensibles en temps réel sur les
Page 30 sur 56
performances des applications de l’entreprise aux responsables fonctionnels. Cependant ils
présentent des limites en ce qu’ils ne fournissent pas suffisamment d’informations aux équipes
techniques.

Les APM (Application Performance Management) adaptées à la supervision des applications. Ces
outils « reniflent » les communications du réseau et capturent les paquets afin d’en extraire les
informations liées aux performances des applications. Ils se prêtent particulièrement bien à des
équipes spécialisées dans la maintenance d’applications.

Les NMS (Network Monitoring System) dédiées aux équipes techniques, ils leurs offrent une vision
globale de l’état des nœuds physiques d’un réseau. Ces outils utilisent des programmes (sondes)
pour cartographier et présenter de manière cohérente le réseau aux techniciens et administrateurs.

Dans notre cas de figure, nous allons appliquer la supervision aux équipements d’un réseau de
télécommunications. Nous recherchons donc un outil capable de recueillir des informations sur
l’état des nœuds de notre réseau. La solution devra être performante étant donné la taille potentielle
du réseau à superviser. De plus, elle devra consommer le moins de ressources possibles tout en
étant la moins couteuse possible.

Etude comparative
Il existe un grand nombre de NMS susceptibles de répondre de manière satisfaisante à nos critères
d’exigences. Dans la mesure où ils sont tous différents il va falloir en sélectionner un. Plusieurs
critères peuvent permettre de les discriminer :
• Leur documentation : Le nombre de sources fiables qui peuvent être consultées pour
comprendre leur fonctionnement ;
• Leur modularité : Le fait de pouvoir étendre leurs fonctionnalités est un gage d’adaptabilité.
Leur modularité peut les rendre plus appropriée à l’utilisation que nous voulons en faire.
Par exemple un système qui permet la production automatisée de rapport de supervision
personnalisé est plus avantageux dans notre domaine ;
• Leur coût : Le coût financier de leur acquisition, de leur maintenance éventuellement de
leur documentation.
• Leur coût d’exploitation : La quantité de recourses humaines (temps et en nombre)
nécessaires à leur installation, leur maintenance et leur utilisation ;

Page 31 sur 56
 • Leur capacité de charge : certains systèmes de supervision peuvent gérer des réseaux plus
ou moins grands. C’est une caractéristique à prendre en compte pour éviter une saturation
de la plateforme.
Ces facteurs n’ont pas la même importance dans la sélection de la solution de supervision. Notre
plateforme doit remplir les critères suivants :
• Gratuité : Dans le cadre de ce test la plateforme que nous allons installer doit être libre. Elle
ne doit engager aucun achat de licence ou d’un quelconque support ;
• Capacité de charge élevée : Pour assurer de bonnes performances sur le long terme, le
nombre d’équipements qu’une plateforme peut gérer sera un critère important ;
• Documentation : La solution doit être assez documentée pour réduire les temps
d’installation et de maintenance. Nous voulons des résultats rapides.
• Évolutivité : La plateforme doit proposer une intégration facile de nouvelles fonctionnalités
tout en laissant un contrôle sur l’installation. Elle doit pouvoir communiquer facilement
avec d’autres programmes.
Certains prérequis sont obligatoires dans la mesure où la solution doit être prise en main facilement
par des utilisateurs d’Orion. Notamment :
- Le support du protocole SNMP
- Le monitoring en temps réel des équipements
- Une interface graphique conviviale
- La gestion de plusieurs comptes utilisateurs
Après avoir constitué une liste assez fournie de NMS gratuits à partir de sources diverses, force est
de constater qu’il existe un grand nombre de solution de supervision gratuites. Même après avoir
filtré cette liste avec conditions qui précèdent les possibilités restent nombreuses. Nous avons
examiné les pages web des solutions les plus citées et nous en avons retenu… Les éditeurs de ces
solutions promettent des niveaux de charge élevés, des interfaces graphiques conviviales et le
support de langages performant comme le C/C++, JAVA et ou accessibles comme le Python ou
le PHP.
Tableau 1 : Liste des NMS retenus

Logiciel Langage(s) supporté(s) Particularité

LibreNMS PHP Bonne GUI, Bonne
documentation
Icinga C GUI prévue pour de
nombreux supports

Page 32 sur 56
 Zabbix C Facile à installer
Shinken C, C++, Python Installation très
personnalisable
Nagios C Très populaire

A partir de ces informations nous avons apprécié chaque solution à partir de critères subjectifs :
Le support du Langage Python est un avantage car il propose des performances élevées, il est très
accessible du fait de sa documentation et de la facilité de son écriture, en plus il dispose d’une
grande variété de bibliothèques simples à utiliser qui le rendent versatile.
La possibilité de personnaliser l’installation du logiciel en choisissant nous même les modules que
nous désirons utiliser nous permettra de faire le meilleur usage possible des ressources de notre
installation. Les logiciels avec un bibliothèque claire de modules est appréciable.
De tout cela nous avons sélectionné la solution Shinken.

Le logiciel Shinken
Shinken est une solution bien adaptée à cette problématique dans la mesure où il s’agit d’une
solution gratuite. Une déclinaison payante du logiciel existe mais la version libre est parfaitement
équipée pour la supervision d’un réseau d’opérateur avec les contraintes d’échelle et de
performances que cela implique.
C’est une solution performante. Shinken est une variante de Nagios, une solution écrite en C++
réputée pour ses performances. En plus de repousser encore les limites de performances de Nagios,
Shinken apporte une intégration du langage Python (2.7) dans les langages supportés pour
l’exécution de ses Plugins. Ce qui la rend encore plus flexible dans la personnalisation qu’on peut
en faire.
Cette variante de Nagios a été bien accueillie. Si bien que la documentation et les tutoriels
disponibles pour son installation sont nombreux. L’installation de ce système étant en partie en
ligne de commande (donc délicate), c’est une information capitale dans le choix de la solution.
Cependant l’installation est hautement personnalisable avec une liste de modules faciles à installer
et spécifiques.

Shinken se compose de cinq modules distincts [18] :

Arbitrer : Il distribue les configurations à tous les autres modules durant le démarrage. Il reçoit la
configuration générale du logiciel et il la segmente de manière à distribuer à chaque module la partie
qui le concerne.

Page 33 sur 56
Le Scheduler : Il synchronise les autres modules entre eux en commandant leurs exécutions. Toutes
les données de supervision transitent par lui.
Le Poller : Il a la charge d’exécuter les programmes qui interroge les équipements notamment les
scripts servants à recueillir les informations concernant les objets de la supervision.
Le Broker : Ce module se charge de mettre en formes les informations de supervision lui venant
du Poller. Il les présentera ensuite à une interface homme machine (page web par exemple) ou à
une base de données.
Le Reactionner : Il est l’interface entre la plateforme de supervision et les systèmes de notifications
d’incidents. Il peut par exemple se connecter à un service de mailing pour avertir les administrateurs
d’un évènement sur les objets supervisés.

Figure 28 : Architecture de Shinken

La dernière version du logiciel Shinken (2.4.3) date de 2016 et elle est complètement compatible
avec CentOS à en juger par la pléthore de tutoriels disponibles. Le logiciel Shinken fonctionne avec
le langage Python dans ses versions antérieures à python3 à partir de la version 2.6.

Page 34 sur 56
 Figure 29 : Quelques partenaires de Shinken

3.1.2 Simulations

Avant l’installation du logiciel de supervision il convient de déterminer les conditions d’exécution

optimales de son fonctionnement. Dans ce paragraphe nous montrerons la démarche utilisée dans
la sélection d’un OS hôte pour le logiciel Shinken. Au passage nous mettrons l’accent sur les
spécifications matérielles nécessaires à un fonctionnement satisfaisant.

Sélection du système d’exploitation hôte de la plateforme

Shinken fonctionne en environnement Linux. La recherche est donc orientée vers une distribution
Linux [19] :
Adaptée aux serveurs : En effet il existe une très grande variété de distributions Linux conçues
pour des usages spécifiques dans bien des cas. Certaines sont conçues pour fonctionner avec une
grande variété d’équipements, même les plus anciens et les moins performants. Elles sont donc peu
gourmandes en ressources. D’autres pour des tests de sécurité, donc livrées avec une panoplie
d’outils adaptés à cet usage. Il y a des distributions plus adaptées à des environnements de
production du fait des configurations matérielles qu’elles peuvent prendre en charge. Au besoin
notre processus d’installation doit pouvoir être répliqué c’est donc une caractéristique qui nous
intéresse. Ces distributions offrent également beaucoup de flexibilité dans les outils de base qui
peuvent être préinstallés.
Libre : Autrement dit gratuite et dont le code source est accessible par tous. Bien des entreprises
proposent des distributions Linux adaptées à des usages professionnels. Elles proposent le plus

Page 35 sur 56
souvent un support permanent pour accompagner les administrateurs clients de leur solution. Cela
s’accompagne de l’achat d’une licence souvent onéreuse et de durée limitée. Dans le cadre de notre
projet, nous recherchons donc une distribution gratuite.
Stable : Les distributions Linux suivent bien souvent des cycles de développement. De ce fait
certaines versions sont livrées avec de nouvelles fonctionnalités mais également de nombreux
disfonctionnements et instabilités. En général leur raffinement engendre des versions plus stables,
conseillées pour des usages en production. Les serveurs de supervisions doivent être stables pour
surveiller d’éventuelles problèmes dans un réseau. Nous recherchons un OS capable de nous
assurer une stabilité optimale.
Récente : Bien que nous recherchions un OS stable et que les versions les plus anciennes ont fait
leurs preuves de ce point de vue, notre plateforme se veut moderne. Nous voulons donc un accès
aux fonctionnalités les plus récentes possibles, nous nous sommes concentrés sur les versions les
plus récentes des distributions Linux.
Commode à utiliser : Pour répondre aux contraintes de temps liées à la réalisation de notre projet,
nous voulons minimiser le temps nécessaire à la recherche d’informations liées à la maintenance et
à l’installation de notre serveur. Cette démarche sera grandement simplifiée par une documentation
abondante concernant l’OS sélectionné. Un OS au fonctionnement intuitif et familier (GUI) n’en
sera que plus simple à déployer sur notre serveur.
Nos recherches ont révélé que plusieurs OS Linux sont compatibles avec le logiciel Shinken.
Ubuntu, Debian et RedHat en sont des exemples souvent cités. Bien que Ubuntu soit réputé pour
une utilisation personnelle, il n’est pas très populaire en milieu de production professionnel.
RedHat par contre est une distribution très utilisée en entreprise et largement documentée mais
elle est payante. Cependant il existe une variante gratuite de RedHat qui reprend à peu près les
mêmes fonctionnalités mais qui ne bénéficie pas d’un support dédié dénommée CentOS. Ces deux
distributions partagent le même gestionnaire de packages et les mêmes systèmes de sécurité [19].
Cette distribution a été sélectionnée au détriment de Debian du fait de l’abondance de la
documentation et des tutoriels relatifs au déploiement de systèmes de supervision avec cet OS
comme hôte.
Nous avons sélectionné CentOS dans sa version 7.9 livrée avec python2.7 préinstallé. Bien que la
version 8 de cet OS existe déjà, sa version 7.9 est encore largement maintenue (Mises à jour, partage
le même dépôt que les versions les plus récentes).
Architecture de test
Les tests ont été effectués sur un laptop HP Probook 450 G7 de 24GB de RAM DDR4, 256GB
de stockage SSD et un processeur Intel Core i7 10510U fonctionnant sur l’OS Windows 10. Pour

Page 36 sur 56
virtualiser notre serveur nous avons utilisé le logiciel VMware Workstation pro dans sa version
16.2.1.

Figure 30 : Laptop

Les variantes de la VM de la plateforme dont il est l’hôte ont été testées dans un LAN conçu à cet
effet. A part l’ordinateur, ce LAN se compose des éléments suivants :
Un routeur de test : Le premier équipement soumis à la supervision des différentes VM
Une box Wifi : Chargée d’interconnecter le PC de virtualisation et le routeur de test.

Figure 31 : réseau de test

Cette méthode nous a permis de tester plusieurs variantes de nos installations et de nous affranchir
de problèmes inhérents à ce type de tests (crashes de VM, erreur d’exécution, mémoire corrompue
etc).
Trois paramètres sont déterminants dans le choix des ressources matérielles de notre serveur :
Le CPU : La puissance du processeur central de notre serveur servira à exécuter le système
d’exploitation et le logiciel de supervision. Pour un aperçu plus réaliste, il est possible de tester une

Page 37 sur 56
configuration matérielle avec des outils de Benchmark. Dans la mesure où les seules caractéristiques
du processeur ne suffisent pas à déterminer ses performances réelles les benchmarks fournissent
des scores tenant compte des autres facteurs importants. Notamment sa capacité à utiliser tous se
cœurs simultanément sur des périodes plus ou moins longues sans surchauffer.
La RAM : La mémoire vive est la mémoire de travail de l’ordinateur du fait de sa rapidité d’accès.
Les données de l’OS et des programmes en exécution y sont stockées. De ce fait, lorsque la RAM
est saturée, le système copie une partie de ses fichiers sur la mémoire permanente. Le système fait
du swapping [21]. La mémoire de l’ordinateur étant beaucoup plus lente, cette opération crée un
ralentissement général du système. La fiabilité de notre serveur de supervision dépend beaucoup
de cette caractéristique.
Le stockage permanent : La documentation de CentOS recommande 20GB de stockage pour
héberger l’OS. Pour les besoins du projet, cette caractéristique n’est pas critique dans la mesure où
stocker de larges fichiers n’est pas prévu. De plus le stockage permanent peut être mis à jour plus
tard sans déstabiliser l’installation [20].

Pour déterminer les quantités de ressources dont nous avons besoin nous avons utilisé une
plateforme de virtualisation, VMWARE. Ce logiciel permet de régler facilement ces paramètres sur
des machines virtuelles. Le test consiste donc à créer une instance virtuelle de notre serveur de
supervision et d’augmenter graduellement les ressources de la machine virtuelle tout en surveillant
les taux de charge des paramètres importants précités.
On a pu constater grâce au moniteur système embarqué dans CentOS qu’avec moins de 6GB de
RAM, notre machine virtuelle avec Shinken et Centos7.9 installés utilisait une grande quantité de
mémoire d’échange. Cela s’est traduit par des ralentissements important dans l’interface graphique
(de l’ordre de plusieurs secondes de seconde de latence).

Figure 32 : Taux de charge de la RAM de la VM avec 4GB

La figure 32 montre que 2,4GB de la mémoire d’échange sont utilisés en plus de 4GB pour combler
le manque de RAM. Avec deux cœurs virtuels cadencés à 2.3GHz, le CPU de notre VM etait
suffisamment capable d’assurer un fonctionnement stable à notre serveur.

Page 38 sur 56
 Figure 33 : Taux de charge CPU avec 2 cœurs virtuels

La figure 33 montre un taux de charge CPU avoisinant les 50% en fonctionnement normal.
Ces tests ont révélé que tout serveur ayant une mémoire vive supérieure ou égale à 6 GB et un
score supérieur à 105 en single-core et 428 en multi-core sur geekbech5 peut accueillir la plateforme
de supervision pour réaliser nos tests.

3.2 Implémentation et tests

Les tests effectués précédemment nous ont permis d’établir les caractéristiques matérielles de notre
plateforme de supervision. Le CNPI a mis à notre disposition du matériel afin de mener à bien
l’installation la plateforme. Nous avons donc :
Un serveur physique compatible avec CentOS7.9 [26].
Un routeur Cisco C1121-4P possédant 4GB de DRAM et 4GB de mémoire flash [21]
Une box Huawei B311 [25].

Figure 34 : Matériel

Page 39 sur 56
3.2.1 Installation du serveur

La plus grande partie de nos configurations se feront sur cet équipement. Le serveur qui a été mis
à notre disposition possède les caractéristiques suivantes :
- Processeur : Intel Xeon E5620 2.4GHz x8
- Mémoire vive : 4096MB DDR3 1333MT/s
- Stockage : 2 disque durs HHD 10000rpm de 146GB
- Epaisseur : 1U soit 44,45mm [22]
- Caractéristiques complètes [25] :

Tableau 2 : caractéristiques du serveur

Caractéristique Valeur
Système CentOS 7
Architecture x86_64
Kernel 3.10.0-1160.76.1.el7.x86_64
Vendeur Hewlett-Packard
Model ProLiant DL360 G7
Année 2010
HWid 25E2F
Type Sur rack

Configuration du Système de Virtualisation de Stockage du serveur

Un système de virtualisation de stockage permet d’augmenter les performances et la fiabilité du
stockage d’un ordinateur. On peut soit augmenter la rapidité du stockage en répartissant les
données sur plusieurs disques de manière à paralléliser leur lecture/écriture (RAID 0); soit
augmenter la résilience du stockage par rapport aux pannes en écrivant de manière redondante sur
plusieurs disques de manière à pouvoir récupérer les données au cas où un d’entre eux serait
dysfonctionnel (RAID 1) [22].
Nous avons choisi l’option RAID 1+0 alliant les deux approches. Notre serveur embarque une
solution RAID matérielle HP Smart Array P410i/256 MB Controller.

Page 40 sur 56
Installation de CentOS7.9
L’installation d’un OS nécessite un support de démarrage contenant l’OS en question, et une
procédure de démarrage en général propre à la cible de l’installation. Nous avons utilisé le logiciel
Rufus pour rendre notre clé USB SanDisk 3.0 de 16 GB démarrable.

Figure 35 : Setup du serveur

CentOS propose plusieurs options pour personnaliser son installation. Cependant plusieurs d’entre
elles ont été nécessaires dans l’obtention de nos résultats.

Figure 36 : UI installation

Page 41 sur 56
Comme on peut le voir sur la figure 36, on a plusieurs informations à renseigner pour lancer
l’installation. Notons qu’en dépit de la source et de la destination de l’installation, il nous est
indispensable de sélectionner les logiciels que nous voulons préinstaller sur notre serveur. Les
logiciels suivants nous ont servi durant la suite de l’installation :
- Une interface graphique pour faciliter la navigation au sein de l’OS.
- Les outils de développement qui contiennent une partie des logiciels nécessaires à
l’installation de Shinken
- Les outils de supervision pour ne pas avoir à les réinstaller pour tester l’installation du
logiciel Shinken.
La figure 37 montre la sélection réalisée.

Figure 37: Choix des logiciels préinstallés

La création d’un compte administrateur a été nécessaire pour la suite de notre installation. Sans
quoi il sera impossible de réaliser des actions comme créer un nouvel utilisateur pour Shinken.

Page 42 sur 56
 Figure 38 : Compte admin

Configuration de l’interface réseau du serveur et l’accès à distance

Il nous reste à fixer une adresse et à configurer un accès à distance. Le serveur a l’adresse
10.255.254.19/27 sur le LAN du CNPI. Il utilise les DNS de MAGT. Le primaire ayant une adresse
IP 217.77.71.33 et 217.77.71.1 comme DNS secondaire. Nous avons fixé ces informations sur son
interface réseau comme le montre la figure 39.

Figure 39 : Interface réseau du serveur

Page 43 sur 56
Nous avons installé un serveur XRDP. C’est un serveur d’accès à distance qui permet d’accéder au
bureau d’un ordinateur en réseau. Ainsi, notre serveur est prêt à recevoir le logiciel Shinken. Nous
l’avons installé dans la salle d’exploitation du CENACOM dans le rack 14.

Figure 40 : Rack CENACOM

Tableau 3 : récapitulatif de l'installation du serveur

Ordre Étapes Observations

1 Configuration de système de
virtualisation de stockage
2 Installation de CentOS (1)
3 Installation de CentOS (2)
4 Configuration de l’interface
réseau du serveur
5 Installation du serveur dans la
salle de production
Les deux disques durs physiques sont unifiés.
Le stockage du serveur est plus rapide et
résilient aux pannes.
Sélection des logiciels à préinstaller pour
faciliter l’utilisation du serveur.
Création d’un compte administrateur
Le serveur possède une adresse dans le LAN du
CNPI qui lui permet d’aller sur internet.
Le serveur est alimenté de manière redondante
puis il est connecté au LAN du CNPI.

3.2.2 Installation du système de supervision

Une fois le serveur configuré et fonctionnel, nous avons procédé à l’installation de Shinken et de
ses modules. Nous avons greffé le serveur au réseau de test en interconnectant le LAN du CNPI

Page 44 sur 56
au réseau de test. Idéalement, nous cherchions la plateforme d’installation qui nous permettrait de
tester nos installations et de les appliquer directement. La configuration de notre routeur de test a
été la clef pour faire fonctionner ce réseau. En plus de l’adresse 192.168.8.102/24 fixée sur son
interface VLAN 1, nous avons fixée l’adresse 10.255.254.22/27 sur son interface Gigabit-ethernet
0/0/1. Enfin nous avons configuré un NAT [27] (Network Address Translation) entre les deux
interfaces. Concrètement, depuis notre ordinateur portable connecté au réseau sans fil local de la
Box Wifi nous pouvions :
- Tester nos serveurs virtuels sur notre routeur de test
- Appliquer des modifications au serveur réel grâce au bureau à distance
- Tester le serveur réel sur le routeur de test
- Accéder à internet

Cet objectif a été atteint en effectuant une translation d’adresse entre cette interface et celle reliée
au réseau de test. La box quant à elle n’a eu besoin d’aucune configuration. De par son paramétrage
d’usine elle crée un réseau 192.168.8.0/24 qu’elle distribue sur toutes ses interfaces.

Figure 41 : Réseau d'installation

3.2.3 Installation de Shinken

Durant tous nos tests, quatre étapes étaient à reproduire systématiquement :

Page 45 sur 56
 - Mettre à jour le serveur : Bien que notre procédure d’installation de CentOS nous fournisse
une grande partie des outils dont nous avons besoin, il a toujours été important de vérifier
que le système était à jour. Sans quoi nous n’étions pas à l’abri de problèmes de disponibilité
de paquets dans les versions requises par le logiciel Shinken.

- Installer l’environnement prérequis : Shinken est écrit en partie en Python dans sa version
2.7. Plusieurs modules de python sont nécessaires à son fonctionnement. Il faut donc les
installer soigneusement pour éviter une installation non fonctionnelle. Par exemple pour
certains modules, la dernière version n’est pas compatible avec python2.7. Dans ces cas il
faut rechercher une version compatible et l’installer.

- Installer shinken : Soit en se procurant le répertoire d’installation sur le site de Shinken, soit
directement avec une commande. Dans le cadre de notre projet nous avons installé la
dernière version de shinken (2.4.3).

- Debugger l’installation : Plusieurs erreurs peuvent se produire durant l’installation. De ce

fait, il faut vérifier que cette dernière s’est faite sans encombre. On vérifie que l’interface
web du logiciel est accessible. Par défaut, le serveur de supervision est le premier
équipement supervisé par le logiciel Shinken. Une erreur au niveau de son accessibilité est
souvent liée à un problème d’installation. Et enfin on vérifie les fichiers log de Shinken
dans le répertoire /var/log/shinken pour s’assurer qu’aucune erreur ne s’est produite.

Une fois l’installation terminée, on a accès à notre interface web avec l’adresse
suivante http://10.255.254.19:7767 entrée dans un navigateur web.

Page 46 sur 56
 Figure 42 : Dashboard Shinken

L’apparition de cette interface avec le localhost comme équipement supervisé est un bon indicateur
indiquant que l’installation est réussie (voir figure 42).

3.2.4 Test

Après l’installation du logiciel de supervision, il convient de vérifier sa capacité à recueillir des

informations sur les équipements à superviser. Le système ne peut atteindre ces objectifs qu’à trois
conditions :
• Le serveur doit avoir découvert l’équipement à surveiller. Autrement dit le serveur doit
avoir en mémoire certaines informations sur l’équipement (son nom, son groupe
d’appartenance, son adresse IP, etc…), et en plus le serveur doit pouvoir communiquer via
le protocole IP avec l’équipement. Le logiciel Shinken permet de découvrir les équipements
de manière automatique et il est également possible de les ajouter manuellement. Le logiciel
stocke les équipements à superviser dans le répertoire /etc/shinken/hosts. Dans le cadre
du test de supervisions nous avons renseigné quatre informations importantes :
- Le nom du routeur
- Les packs à utiliser
- L’adresse IP du routeur
- La communauté SNMP du routeur

Page 47 sur 56
 Figure 43 : ajout du routeur de test

Toutes les informations concernant les paramètres à surveiller, les taux de charge critiques sont
contenus dans les packs routeurs et Cisco. La figure 43 montre la modification du fichier
« rtest.cfg » pour l’ajouter en tant qu’équipement à superviser.

• Le serveur doit posséder une liste exhaustive des informations qu’il doit recueillir auprès
de l’équipement. Dépendamment du type d’équipement et du constructeur, certaines
valeurs de la MIB vont être pertinentes à surveiller. Si pour un routeur surveiller son niveau
de charge CPU est pertinent, pour une imprimante il s’agira de vérifier si elle est bourrée
par exemple. Le système doit, pour chaque agent SNMP connaître les valeurs à faire
remonter. Shinken stocke ces valeurs dans des packs. Les packs sont téléchargeables
directement sur le magasin à l’aide de la commande : shinken install. Nous avons installé
les packs routeur et Cisco pour notre routeur de test.
• Le système de supervision doit être autorisé à superviser l’équipement. En ce qui concerne
les équipements Cisco par exemple, les bonnes pratiques lorsqu’on utilise la version 2c du
protocole SNMP veulent qu’un seul le serveur de supervision soit autorisé à envoyer des
requêtes SNMP à l’équipement. En plus de changer la communauté SNMP en un mot de
passe plus robuste bien sûr. En pratique on configure une ACL (Acces-List) qui contiendra
l’adresse IP de tous les NMS autorisés à superviser l’équipement. Puis on associe cette ACL
à la communauté SNMP de supervision.

Page 48 sur 56
 (config)#ip access-list 40 permit 192.168.8.104
(config)#ip access-list 40 permit 10.255.254.19
(config)#snmp-server community cnpiuuu RO 40

Figure 44 : Ajout du serveur de supervision à la liste autorisée

Nous avons donc renseigné les adresses de nos deux serveurs et nous les avons associés à la
communauté cnpiuuu (voir figure 44). A ce stade il s’agit de vérifier que notre routeur de test admet
nos serveurs comme NMS. La commande snmpwalk avec comme paramètre l’adresse de
l’équipement à superviser et sa communauté doit produire une réponse contenant l’entièreté de la
MIB de l’équipement.
La commande snmpwalk permet de tester l’accès à la MIB d’un équipement. Pour notre routeur
de test il a suffi d’entrer la commande snmpwalk -v2c -c cnpiuuu 10.255.254.22 dans les terminaux
de nos serveurs pour vérifier qu’ils arrivent à recueillir les informations relatives à l’état du routeur
de test.

Figure 45 : Reponse snmpwalk

La figure 45 montre la réponse de l’équipement à la requête snmp du serveur. Il s’agit de l’intégralité

du contenu de la MIB de l’équipement. Le serveur parvient donc bel et bien à interroger la MIB du
routeur de test.

Page 49 sur 56
 Figure 46 : Le routeur de test dans la liste des équipements

La figure 46 montre que le routeur de test « rtest » a été ajouté à la liste des équipements supervisés.

Figure 47 : services supervisés

En sélectionnant le routeur de test, on accède à une liste de valeurs liée à son état.
Notamment la charge de son CPU, la mémoire utilisée comme on peut le voir sur la figure 47.

Page 50 sur 56
 Figure 48 : Utilisation des interfaces

Une information importante dans la supervision des équipement réseau est l’état de ses interfaces
réseau. Shinken parvient à en donner l’état de manière exhaustive. Sur la figure 48 on peut voir la
liste complète des interfaces du routeur de test ainsi que leurs taux d’usage.
Shinken nous donne accès à une vue générale sur toutes les équipements sujet à sa supervision. Sur
la figure 49 nous avons une vue récapitulative des équipements supervisés ainsi que l’état de leurs
métriques importantes.

Page 51 sur 56
 Figure 49 : Vue générale

La plateforme n’a pas été mise en production car cela aurait nécessité de plus amples discussions
avec les consommateurs de l’offre puisque cette dernière allait évoluer. Cependant, l’étude a posé
les bases requises en vue d’un futur déploiement. Il faudra néanmoins peaufiner les mécanismes
d’alarmes et de lisibilité de la plateforme pour la rendre aussi utile que Orion. Un autre usage auquel
elle pourra servir est la supervision des bancs de tests effectués au CNPI.

Page 52 sur 56
 RECOMMANDATIONS

Notre système de supervision est perfectible sous biens des aspects. Plusieurs usages sont encore
à implémenter sur cette dernière pour qu’elle serve de manière satisfaisante à de potentiels clients.
• La lisibilité de la plateforme peut être améliorée. Bien que la console Web de Shinken soit
déjà commode à prendre en main, il est cependant difficile de visualiser et d’exporter des
données directement dessus.
o Les logiciels de supervision proposent en général des options de visualisation de
topologie du réseau supervisé. Ainsi, accéder à un équipement ou voir l’impact
global d’un dysfonctionnement est fortement simplifié. Le client verrait en une
seule fois l’état global de son réseau VPN 3G/4G et pourrait agir directement sur
un équipement durant un opération de maintenance.
o Pouvoir visualiser des courbes d’évolutions d’une métrique de notre réseau
(utilisation de la bande passante d’un lien, taux d’usage du CPU d’un nœud) facilite
également les prises de décision par rapport à la maintenance de l’objet de la
supervision. Pouvoir visualiser et exporter facilement ce genre d’informations
fluidifie la compréhension de l’infrastructure supervisée. Le client pourrait par
exemple adapter la bande passante de son lien FO au trafique de ses liaisons VPN
3G/4G.

• Le serveur de supervision aura besoin de plus de mémoire vive pour effectuer une
exécution fluide de l’installation. En effet avec 4GB de RAM, on observe des
ralentissements importants lors de l’utilisation de la plateforme. Cela s’est avéré être une
limite dans l’installation d’éventuels modules qui pourraient encore plus diversifier les
usages de la plateforme.

• En cas de dysfonctionnement après une opération de maintenance ou une mise à jour,

l’administrateur d’un réseau doit pouvoir rétablir l’état de fonctionnement initial des nœuds
de son réseau. Le temps de mener une enquête approfondie visant à déterminer les causes
de la panne. Avoir de manière centralisée l’historique des configurations de chaque nœud
du réseau est logique dans cette démarche. Pour mettre en place cette fonctionnalité, on
intègre en générale à la plateforme de supervision réseau une base de données de manière

Page 53 sur 56
 à stocker un tel historique. Il est également possible de configurer Shinken (et les nœuds
du réseau) pour automatiser une récupération périodique de la configuration de chaque
nœud du réseau.

Les Traps SNMP sont des requêtes servant à alerter la plateforme de supervision lorsqu’un
évènement se produit sur un nœud. Ainsi les administrateurs du réseau pourraient être avertis
directement de la rupture ou de la saturation d’un lien. Le logiciel Shinken prend complètement en
charge ces requêtes et propose d’ailleurs un système de notifications personnalisable à cet effet.
Cela représenterait un gain en performance dans la prise en charge et la prévention de pannes dans
le réseau VPN 3G/4G.

Les liaisons VPN3G/4G sont encapsulées dans des VRF dans le Backbone MPLS. Un moyen
d’établir une connectivité IP entre le serveur de supervision et les extrémités de ces liaisons est
d’introduire le serveur dans toutes ces VRF. Pour cela Il est possible de segmenter l’interface
physique du serveur en plusieurs sous interfaces. Chaque sous interface correspondant à une VRF.

Figure 50 : Sous interface correspondant au VPN3G4G

Le serveur pourra alors joindre directement les extrémités du VPN de l’intérieur.

Page 54 sur 56
 CONCLUSION

Ce mémoire porte sur la conception d’une plateforme de supervision dédiée à l’offre VPN-
3G/4G de Moov Africa Gabon Telecom. L’objectif de ce système étant de répondre aux besoins
de supervision des consommateurs de l’offre tout en minimisant l’exposition de l’infrastructure
de Moov Africa Gabon Telecom à des risques de sécurité.

Ce travail a été fait en trois phases. Premièrement nous avons pris connaissance de l’infrastructure
réseau de l’entreprise afin de comprendre au mieux le contexte de notre projet. Puis, après avoir
cerné les technologies mises en œuvre dans l’offre VPN3G/4G, nous nous sommes intéressés à la
plateforme de supervision en production dans l’entreprise. Enfin, nous avons conçu une
plateforme susceptible de répondre à ce besoin et, après avoir déterminé les caractéristiques de ce
système de supervision, nous avons mis en place une plateforme test.
Comme résultats, la plateforme est capable de recueillir et de montrer en temps réel l’état d’un
équipement (Le taux de charge du CPU, l’état des interfaces réseau, le taux d’utilisation de la
mémoire, etc). Le serveur est exclusivement accessible depuis le LAN du CNPI comme le
préconisait le cahier de charge. Cependant l’installation a montré un ralentissement de son interface
graphique ce qui a entravé nos tentatives de tests plus étendus. La plateforme n’a pas non plus été
testée en environnement réel.
Comme perspectives à ce travail, nous recommandons une augmentation de la mémoire vive du
serveur dans l’optique détendre les tests de déploiement. Cela devrait par la même occasion régler
les problèmes de ralentissements de la plateforme. Idéalement nous préconisons un test sur une
liaison VPN3G/4G ainsi, plus de précisions sur le comportement du serveur en environnement de
production pourraient être recueillies. En effet, la configuration de l’interface réseau du serveur est
décisive dans le déploiement de cette solution. De plus, Plusieurs modules destinés à l’affichage de
courbes montrant l’évolution des métriques du réseau restent à installer pour améliorer la lisibilité
de la plateforme. Autrement la solution serait privée d’un outil d’interprétation indispensable. En
outre, Les plateformes de supervision assurent une sauvegarde de l’historique des configurations
des équipements qu’elles gèrent. Des tests de sauvegarde devrons être effectués sur notre
plateforme afin de couvrir cet aspect. Enfin, des outils lui permettant d’envoyer des sms ou des
mails aux administrateurs réseau sont à installer. En effet, Le protocole SNMP couvre un large
panel d’évènements susceptibles d’enrichir et d’optimiser les décisions liées à la maintenance ou au
dépannage du réseau.

Page 55 sur 56
Page 56 sur 56
 BIBLIOGRAPHIE

[1] M. H. a. J. Moore, "Classic Core/Aggregation/Access Layer Topologies," janvier

2018. [Online]. Available: https://download3.vmware.com/vcat/vmw-vcloud-
architecture-toolkit-spv1-
webworks/index.html#page/Network%20and%20Security/Architecting%20a%
20VMware%20NSX%20Solution/Architecting%20an%20NSX%20Solution.1.019.
html.

[2] C. Support, "MPLS FAQ For Beginners," San Jose, 2016.

[3] C. System, "Cisco ASR 9000 Series Aggregation Services Routers," [Online].
Available: https://www.cisco.com/c/en/us/products/routers/asr-9000-series-
aggregation-services-routers/index.html.

[4] C. Systems, "Chapter: Configuring Wireshark," [Online]. Available:

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/r
elease/3se/consolidated_guide/configuration_guide/b_consolidated_3850_3se_cg
/b_consolidated_3850_3se_cg_chapter_0111000.html?dtid=osscdc000283.

[5] C. Systems, "Cisco SFP Modules for Gigabit Ethernet Applications Data Sheet," 1
mars 2023. [Online]. Available:
https://www.cisco.com/c/en/us/products/collateral/interfaces-
modules/gigabit-ethernet-gbic-sfp-modules/datasheet-c78-366584.html.

[6] G. Pujolle, "Les Réseaux," Sorbonne, 08/07/2004.

[7] C. support, "Multiprotocol BGP MPLS VPN".

[8] A. Dufour, "MPLS LDP," [Online]. Available:

https://www.brindereseau.fr/?article=mpls-ldp.

[9] C. Systems, "Resource Reservation Protocol (RSVP)," 10 janvier 2019. [Online].

Available: https://www.cisco.com/c/en/us/products/ios-nx-os-
software/resource-reservation-protocol-rsvp/index.html?dtid=osscdc000283.

[10] C. Systems, "Virtual Route Forwarding Design Guide," 12 novembre 2008. [Online].
Available:

Page i
 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucme/vrf/design/gui
de/vrfDesignGuide.html?dtid=osscdc000283#wp1035537.

[11] O. C. a. i. affiliates, "Introduction à IPsec," 2010. [Online]. Available:

https://docs.oracle.com/cd/E19957-01/820-2982/ipsec-ov-2/index.html.

[12] D. R. OKOUYI, "Architecture des réseaux mobiles," Franceville, 2021.

[13] Huawei, "UGW," [Online]. Available:

https://carrier.huawei.com/en/products/core-network-v3/Packet-Core/UGW.

[14] M. F. M. S. J. D. J. Case, "A Simple Network Management Protocol (SNMP)," 1990.

[15] C. support, "SNMP Version 3".

[16] I. Corporation, "CPU vs GPU: What's the Difference," [Online]. Available:

https://www.intel.com/content/www/us/en/products/docs/processors/cpu-vs-
gpu.html.

[17] Fortinet, "Définition d’un VPN SSL," [Online]. Available:

https://www.fortinet.com/fr/resources/cyberglossary/ssl-vpn.

[18] G. Leroy, "Gestion du déploiement d’une solution de supervision," dumas-

01875776, 2017.

[19] S. Team, "Welcome to Shinken’s documentation!," [Online]. Available:

https://shinken.readthedocs.io/en/latest/.

[20] R. Hat, "Linux, qu'est-ce que c'est ?," 3 janvier 2023. [Online]. Available:
https://www.redhat.com/fr/topics/linux/what-is-linux.

[21] R. Alloway, "CentOS vs. Red Hat Enterprise Linux (RHEL): Do the Differences Justify
the Cost?," 10 Juin 2020. [Online]. Available:
https://www.openlogic.com/blog/centos-vs-redhat.

[22] M. Halfeld-Ferrari, "Systèmes d'exploitation," Orlean.

[23] K. Technology, "Quelle est la différence entre la mémoire et le stockage ?," Octobre
2020. [Online]. Available: https://www.kingston.com/fr/blog/pc-
performance/difference-between-memory-storage.

[24] RedHat, "catalog.redhat.com," [Online]. Available:

https://catalog.redhat.com/hardware/servers/detail/4098.

Page ii
[25] router-switch, "C1121-4P Datasheet," [Online]. Available: https://www.router-
switch.com/cisco-c1121-4p-datasheet-pdf.html.

[26] Huawei, "HUAWEI B311-221 LTE White," www.amazon.fr, [Online]. Available:

https://www.amazon.fr/HUAWEI-B311-221-LTE-
White/dp/B086QB9ZXQ/ref=psdc_430397031_t1_B07TK2X6NS.

[27] F. Datacenter, "Dimensions d’un U (Rack Unit)," [Online]. Available:

https://www.france-datacenter.fr/comment-choisir-son-datacenter-criteres-
comparatif/dimensions-u-rack-unit/.

[28] L. Hardware, "Caractéristiques du serveur," 2023. [Online]. Available:

https://linux-hardware.org/?probe=37905125fc.

[29] H. support, "RAID Manuel de l'utilisateur".

[30] H. support, "Huawei Firewall: What Is Network Address Translation (NAT)? How
Does NAT Work?," 21 juin 2020. [Online]. Available:
https://support.huawei.com/enterprise/en/doc/EDOC1100086056.

[31] M. M. S. Géris, "Etude de deployement d'une plate-forme de supervision dédiée aux

réseaux VPN3G/4G de MOOV AFRICA GABON TELECOM," FRANCEVILLE, 2023.

[32] C. Support, Secure Your Simple Network Management Protocol, San Jose, USA, 16
janvier 2023.

[33] Huawei, "USN," [Online]. Available:

https://carrier.huawei.com/en/products/core-network-v3/Packet-Core/USN.

[34] C. System, "Cisco 1000 Series Aggregation Services Routers," [Online]. Available:
https://www.cisco.com/c/en/us/products/routers/asr-1000-series-aggregation-
services-routers/index.html.

[35] https://browser.geekbench.com/, "Welcome to the Geekbench Browser," [Online].

Available: https://browser.geekbench.com/.

[36] a. MICHAU, "La supervision," [Online]. Available: http://www-igm.univ-

mlv.fr/~dr/XPOSE2007/dmichau_supervision/supervision.html.

[37] Y. TEAM, "Shinken Monitoring v2.4.3 installation on centos 7+," [Online]. Available:
https://www.yobihat.com/shinken-monitoring-v2-4-3-installation-on-centos-7/.

[38] S. Worldwide, "Orion Platform," [Online]. Available:

https://www.solarwinds.com/orion-platform.

Page iii
Page iv
 ANNEXE I

Scores sur geekbench5 des machines :

VM avec 6GB de RAM : https://browser.geekbench.com/v5/cpu/198594252
PC Laptop HP probook : https://browser.geekbench.com/v5/cpu/19859932
Serveur HP prolian DL360 G7 : https://browser.geekbench.com/v5/cpu/19859545

Page v