RAPPORT DE PROJET

D'INTERCONNEXION RÉSEAUX
Remerciements

Je tiens à exprimer ma sincère gratitude à toutes les personnes ayant contribué, de près ou de
loin, à la réalisation de ce projet.

J'adresse mes remerciements particuliers au Dr. Niang, enseignant du cours d'Interconnexion

Réseaux et Adressage à l'ESTM, pour la qualité de son enseignement, ses conseils et les
connaissances qu'il nous a transmises tout au long de cette unité d'enseignement.

Introduction
Aujourd'hui, les entreprises utilisent de plus en plus les réseaux informatiques pour faciliter la
communication entre leurs différents sites et partager leurs ressources. Lorsqu'une entreprise
possède plusieurs agences réparties dans différentes villes, il devient indispensable de mettre
en place une infrastructure réseau capable de relier tous les sites de manière fiable, sécurisée
et performante.

Dans le cadre du cours Interconnexion Réseaux / Adressage, il nous a été demandé de

réaliser un projet complet consistant à concevoir et configurer le réseau d'une entreprise
disposant d'un siège social à Dakar et de plusieurs agences situées à Thiès, Mbour, Kaolack et
Saint-Louis.

L'objectif principal de ce projet est de permettre à tous les sites de communiquer entre eux
grâce à un protocole de routage dynamique, tout en donnant aux utilisateurs des agences un
accès aux différents services hébergés au siège, notamment le serveur DHCP, le serveur
DNS, le serveur Web, le serveur FTP ainsi que le serveur de téléphonie IP.

Pour réaliser ce projet, nous avons utilisé le logiciel Cisco Packet Tracer, qui permet de
simuler une infrastructure réseau complète et de configurer les différents équipements Cisco
comme les routeurs, les switches, les serveurs et les postes clients.

La réalisation de ce projet nous a permis de mettre en pratique plusieurs notions étudiées en

cours, notamment le plan d'adressage IP, la création de VLAN, la configuration des switches,
le routage dynamique avec OSPF, la mise en place des services réseau ainsi que les différents
tests permettant de vérifier le bon fonctionnement de l'infrastructure.

Au cours de la réalisation, plusieurs difficultés ont été rencontrées, notamment lors de la

configuration de certains services comme le serveur DNS, le serveur FTP et le service de
téléphonie IP. Ces difficultés nous ont amenés à effectuer plusieurs vérifications, à analyser
les causes possibles des problèmes et à proposer des solutions adaptées afin d'obtenir un
réseau fonctionnel.

Dans ce rapport, nous présenterons les différentes étapes de réalisation du projet, depuis
l'analyse des besoins jusqu'aux tests de validation, en expliquant les choix techniques
effectués, les configurations mises en place ainsi que les difficultés rencontrées.

Chapitre 1 : Présentation du projet

1.1 Contexte
Dans ce projet, nous jouons le rôle d'un ingénieur Réseaux et Télécommunications recruté
par une entreprise qui souhaite moderniser son infrastructure informatique.

L'entreprise possède un siège social situé à Dakar ainsi que quatre agences réparties dans
différentes régions du Sénégal. Jusqu'à présent, chaque site fonctionne de manière
indépendante, ce qui rend les échanges de données difficiles et limite le partage des
ressources.

Afin d'améliorer son fonctionnement, l'entreprise souhaite mettre en place un réseau unique
permettant à toutes les agences de communiquer entre elles tout en utilisant les différents
services installés au siège social.

Cette nouvelle infrastructure devra également faciliter l'administration du réseau, améliorer la

disponibilité des services et préparer l'entreprise à une évolution future.

1.2 Présentation de l'entreprise

L'entreprise est composée de cinq sites :

Siège social : Dakar

Le siège constitue le centre principal du réseau. Il héberge l'ensemble des serveurs ainsi que
la direction générale de l'entreprise.

On y retrouve notamment :

• la Direction Générale ;
• le Data Center ;
• le serveur DHCP ;
• le serveur DNS ;
• le serveur Web ;
 • le serveur FTP ;
• le serveur VoIP (Call Manager) ;
• trois VLAN utilisateurs ;
• vingt-cinq ordinateurs ;
• dix téléphones IP.

Toutes les agences accèdent aux services installés dans ce Data Center.

Agence de Thiès

Cette agence comprend :

• un service Administration ;
• un service Commercial ;
• un service Support Technique ;
• quinze postes de travail ;
• six téléphones IP.

Agence de Mbour

Cette agence est composée de :

• un service Administration ;
• un service Finance ;
• douze postes de travail ;
• plusieurs téléphones IP.

Agence de Kaolack

Cette agence comprend :

• un service Administration ;
• un service Commercial ;
• quinze postes de travail ;
• plusieurs téléphones IP.

Agence de Saint-Louis

Cette dernière agence est constituée de :

• un service Administration ;
• un service Technique ;
• douze postes de travail ;
• cinq téléphones IP.
L'ensemble de ces sites devra pouvoir communiquer grâce au réseau mis en place.

1.3 Objectifs du projet

Pour répondre aux besoins de l'entreprise, plusieurs objectifs ont été fixés dès le début du
projet.

Le premier objectif est de concevoir une architecture réseau permettant d'interconnecter le

siège social et les quatre agences.

Le deuxième objectif consiste à mettre en place un plan d'adressage IPv4 cohérent afin que
chaque équipement puisse être identifié facilement sur le réseau.

Le troisième objectif est de configurer un protocole de routage dynamique, en l'occurrence

OSPF, afin que les routeurs puissent échanger automatiquement leurs informations de
routage et assurer la communication entre les différents sites.

Le projet prévoit également la création de plusieurs VLAN au niveau du siège afin de mieux
organiser le réseau et de séparer les différents types de trafic.

Enfin, l'entreprise souhaite centraliser plusieurs services réseau (DHCP, DNS, Web, FTP et
VoIP) au niveau de Dakar afin que toutes les agences puissent y accéder.

Je pense que cette première partie pose de bonnes bases pour le rapport. Dans la suite, nous
passerons au Chapitre 2 : Analyse des besoins et choix de l'architecture réseau, où nous
expliquerons pourquoi nous avons retenu cette architecture, les équipements Cisco utilisés et
les choix techniques réalisés avant de commencer les configurations.
Chapitre 2 : Analyse des besoins et conception
de l'architecture réseau

2.1 Analyse des besoins

Avant de commencer la configuration du réseau, il était important d'analyser les besoins de
l'entreprise afin de proposer une solution adaptée.

L'entreprise possède un siège social situé à Dakar ainsi que quatre agences réparties dans
différentes villes du Sénégal. Chaque site regroupe plusieurs utilisateurs qui doivent pouvoir
communiquer entre eux mais également accéder aux différents services installés au siège.

Le principal besoin consiste donc à interconnecter tous les sites afin de former un seul réseau
capable d'assurer les échanges de données entre les agences.

En plus de cette interconnexion, l'entreprise souhaite centraliser plusieurs services importants

au niveau du siège de Dakar. Les utilisateurs des agences doivent ainsi pouvoir accéder au
serveur DHCP pour obtenir automatiquement une adresse IP, au serveur DNS pour résoudre
les noms de domaine, au serveur Web pour consulter les pages internes de l'entreprise, au
serveur FTP pour le partage de fichiers ainsi qu'au serveur Call Manager destiné à la
téléphonie IP.
Le réseau doit également être organisé de manière à faciliter son administration. Pour cela, il
est nécessaire de séparer certains équipements dans différents VLAN afin de limiter les
domaines de diffusion (broadcast) et d'améliorer les performances du réseau.

Enfin, l'entreprise souhaite que les communications entre les différents sites soient assurées
automatiquement grâce à un protocole de routage dynamique. Cette solution évite d'ajouter
manuellement des routes sur chaque routeur et facilite les évolutions futures du réseau.

2.2 Choix de l'architecture réseau

Après avoir étudié les besoins de l'entreprise, nous avons choisi une architecture centralisée.

Dans cette architecture, le siège de Dakar représente le cœur du réseau. Tous les serveurs sont
installés dans le Data Center du siège tandis que les quatre agences sont reliées directement
au routeur principal de Dakar par des liaisons WAN.

Ce choix présente plusieurs avantages.

Tout d'abord, il permet de centraliser tous les services au même endroit. Les administrateurs
n'ont pas besoin d'installer un serveur dans chaque agence, ce qui réduit les coûts de matériel
et simplifie la maintenance.

Ensuite, cette architecture facilite l'administration du réseau. Toutes les configurations

importantes sont concentrées au siège et les agences utilisent les ressources disponibles sur le
réseau principal.

Enfin, cette organisation répond parfaitement aux besoins exprimés dans le sujet du projet
puisque toutes les agences peuvent accéder aux services hébergés au siège social.

2.3 Choix des équipements

Pour réaliser ce projet, nous avons utilisé les équipements disponibles dans Cisco Packet
Tracer.

Les routeurs

Nous avons utilisé des routeurs Cisco 2911.

Chaque site possède son propre routeur. Ces routeurs assurent le routage entre les différents
réseaux locaux et permettent la communication entre toutes les agences grâce au protocole
OSPF.

Le choix du Cisco 2911 est adapté à ce type de projet car il dispose de plusieurs interfaces
Gigabit Ethernet ainsi que de plusieurs interfaces série permettant de réaliser facilement les
liaisons WAN entre les différents sites.
Les switches

Pour connecter les ordinateurs, les téléphones IP et les serveurs, nous avons utilisé des
switches Cisco.

Au siège de Dakar, plusieurs switches sont utilisés afin de séparer les serveurs, les utilisateurs
et les différents VLAN.

Dans les agences, un switch permet de connecter les postes de travail ainsi que les téléphones
IP au routeur local.

Les switches assurent également la gestion des VLAN et des liaisons Trunk entre les
différents équipements.

Les serveurs

Le siège de Dakar héberge cinq serveurs principaux :

• un serveur DHCP chargé d'attribuer automatiquement les adresses IP aux postes

clients ;
• un serveur DNS permettant la résolution des noms de domaine ;
• un serveur Web hébergeant le site interne de l'entreprise ;
• un serveur FTP destiné au partage de fichiers ;
• un serveur Call Manager utilisé pour la téléphonie IP.

La centralisation de ces serveurs permet à toutes les agences d'utiliser les mêmes services tout
en facilitant leur administration.

2.4 Choix du protocole de routage

Pour permettre aux différents sites de communiquer automatiquement, nous avons choisi le
protocole OSPF (Open Shortest Path First).

Ce protocole présente plusieurs avantages.

Il permet aux routeurs d'échanger automatiquement leurs informations de routage sans qu'il
soit nécessaire de créer manuellement des routes statiques.

En cas de modification du réseau, OSPF met automatiquement à jour les tables de routage de
tous les routeurs. Cette solution est donc plus simple à administrer et plus adaptée à un réseau
composé de plusieurs sites.

C'est pour cette raison que nous avons préféré utiliser OSPF plutôt que des routes statiques.
2.5 Schéma logique du réseau
L'architecture retenue peut être résumée de la manière suivante :

• Le siège social de Dakar constitue le point central du réseau.

• Les quatre agences (Thiès, Mbour, Kaolack et Saint-Louis) sont reliées au siège par
des liaisons WAN.
• Tous les serveurs sont installés dans le Data Center de Dakar.
• Les utilisateurs des agences accèdent aux services du siège à travers le réseau WAN.
• Les routeurs échangent automatiquement leurs routes grâce au protocole OSPF.
• Les utilisateurs du siège sont répartis dans différents VLAN afin d'améliorer
l'organisation et la gestion du réseau.

Le schéma détaillé de cette architecture a été réalisé sous Cisco Packet Tracer et servira de
référence pour toutes les configurations présentées dans les chapitres suivants.

Chapitre 3 : Plan d'adressage IP

3.1 Importance du plan d'adressage
Avant de commencer la configuration des différents équipements, il était nécessaire de
définir un plan d'adressage IP clair et cohérent.

Le plan d'adressage permet d'attribuer une adresse unique à chaque équipement connecté au
réseau. Cette organisation facilite l'administration du réseau, le dépannage ainsi que les
futures extensions de l'infrastructure.

Dans notre projet, nous avons choisi d'utiliser des adresses privées de la classe C
(192.168.X.0/24) pour les réseaux locaux (LAN). Ce choix est largement utilisé dans les
réseaux d'entreprise puisqu'il offre un nombre suffisant d'adresses tout en restant simple à
administrer.

Pour les liaisons entre les routeurs (WAN), nous avons utilisé des réseaux en [Link] avec un
masque /30 ([Link]). Ce masque est particulièrement adapté aux connexions point
à point puisqu'il fournit exactement deux adresses utilisables, une pour chaque extrémité de la
liaison.

3.2 Plan d'adressage des réseaux locaux (LAN)

Chaque site dispose de son propre réseau local afin d'éviter tout conflit d'adressage.
Le tableau suivant présente les différents réseaux utilisés.

Site Réseau Masque Passerelle

Dakar [Link] [Link] [Link]
Thiès [Link] [Link] [Link]
Mbour [Link] [Link] [Link]
Kaolack [Link] [Link] [Link]
Saint-Louis [Link] [Link] [Link]

Chaque routeur joue également le rôle de passerelle par défaut pour les équipements présents
dans son agence.

3.3 Adressage des serveurs

Tous les serveurs sont installés dans le Data Center du siège de Dakar.

Afin de faciliter leur administration, nous avons choisi de leur attribuer des adresses IP fixes
(statiques). Ainsi, leurs adresses ne changent jamais et les utilisateurs peuvent toujours les
contacter.

Le tableau ci-dessous présente l'adressage retenu.

Serveur Adresse IP
Serveur DHCP [Link]
Serveur DNS [Link]
Serveur Web [Link]
Serveur FTP [Link]
Serveur Call Manager [Link]

Tous les serveurs utilisent la même configuration réseau :

• Masque : [Link]
• Passerelle : [Link]
• Serveur DNS : [Link]

Cette organisation simplifie la gestion des services et permet aux utilisateurs de toutes les
agences d'y accéder facilement.

3.4 Adressage des liaisons WAN

Pour assurer la communication entre les différents routeurs, nous avons créé plusieurs
liaisons série.
Chaque liaison utilise un sous-réseau distinct avec un masque [Link] (/30).

Le tableau suivant résume les différentes connexions.

Liaison Réseau utilisé

Dakar — Thiès [Link]/30
Dakar — Mbour [Link]/30
Dakar — Kaolack [Link]/30
Dakar — Saint-Louis [Link]/30

Ce choix permet d'utiliser très peu d'adresses IP tout en assurant une communication correcte
entre les routeurs.

3.5 Justification du plan d'adressage

Le plan d'adressage retenu présente plusieurs avantages.

Tout d'abord, chaque agence possède son propre réseau local. Cette organisation permet de
mieux identifier les différents sites et facilite les opérations de maintenance.

Ensuite, l'utilisation d'adresses IP statiques pour les serveurs garantit que leurs adresses
restent toujours identiques. Cela est indispensable pour les services comme le DNS, le Web
ou le FTP.

Enfin, les réseaux /30 utilisés sur les liaisons WAN permettent d'économiser les adresses IP
disponibles tout en répondant parfaitement aux besoins des connexions point à point entre les
routeurs.

Grâce à cette organisation, le réseau reste simple à comprendre, facile à administrer et

suffisamment évolutif pour accueillir de nouveaux équipements ou de nouvelles agences si
nécessaire.

Conclusion du chapitre
Après avoir défini le plan d'adressage, nous disposions désormais de toutes les informations
nécessaires pour commencer la configuration des équipements réseau.

La prochaine étape consistait à mettre en place les VLAN, configurer les switches, les
routeurs ainsi que les différents serveurs afin de rendre l'ensemble du réseau opérationnel.
Chapitre 4 : Mise en œuvre de l'infrastructure
réseau
4.1 Préparation de l'environnement de travail

Après avoir terminé la phase de conception, nous avons commencé la réalisation pratique du
projet sous Cisco Packet Tracer.

Avant toute configuration, nous avons installé les différents équipements nécessaires en
respectant le schéma d'architecture défini lors de la conception.

Chaque site a été équipé de son propre routeur afin d'assurer le routage entre les réseaux
locaux et le réseau étendu (WAN). Des switches ont ensuite été ajoutés afin de connecter les
postes de travail, les téléphones IP ainsi que les serveurs présents au siège social.

Une attention particulière a été portée à l'organisation de la topologie afin de faciliter les
futures configurations et rendre le réseau plus lisible.

À cette étape, aucun équipement n'était encore configuré. Il s'agissait simplement de mettre
en place l'ensemble de l'infrastructure physique qui servirait de base pour la suite du projet.

4.2 Installation des équipements réseau

Pour répondre aux besoins de l'entreprise, plusieurs équipements ont été installés dans Cisco
Packet Tracer.

Le siège social de Dakar constitue le point central du réseau. C'est à ce niveau que nous
avons placé l'ensemble des serveurs de l'entreprise ainsi que les switches destinés aux
utilisateurs.

Chaque agence (Thiès, Mbour, Kaolack et Saint-Louis) dispose quant à elle d'un routeur et
d'un switch permettant de connecter les ordinateurs et les téléphones IP.

Les différents équipements ont ensuite été reliés à l'aide des câbles appropriés.

Les connexions entre les routeurs ont été réalisées avec des liaisons série, tandis que les
connexions entre les routeurs, les switches, les serveurs et les ordinateurs ont été effectuées
avec des câbles Ethernet.

Cette organisation permet de reproduire le fonctionnement réel d'une entreprise possédant

plusieurs sites distants.
4.3 Connexion des différents sites

Une fois tous les équipements installés, nous avons procédé au câblage du réseau.

Le routeur principal de Dakar a été relié directement aux quatre autres routeurs afin de créer
les liaisons WAN entre les différentes agences.

Les connexions réalisées sont les suivantes :

• Dakar ↔ Thiès
• Dakar ↔ Mbour
• Dakar ↔ Kaolack
• Dakar ↔ Saint-Louis

Chaque liaison série a reçu une adresse IP spécifique conformément au plan d'adressage
présenté dans le chapitre précédent.

Après le câblage, plusieurs vérifications ont été effectuées afin de s'assurer que les interfaces
étaient correctement connectées. Les commandes show ip interface brief et show interfaces
status ont été utilisées à plusieurs reprises pour vérifier l'état des interfaces.

Ces vérifications ont permis de confirmer que les interfaces étaient bien actives avant de
poursuivre les configurations.

4.4 Création des VLAN

Afin de mieux organiser le réseau du siège social, nous avons créé plusieurs VLAN.

Le choix des VLAN permet de séparer les différents types de trafic tout en améliorant la
sécurité et les performances du réseau.
Les VLAN créés sont les suivants :

VLAN Nom Rôle

10 SERVEURS Héberge tous les serveurs
20 UTILISATEURS Regroupe les postes utilisateurs
30 VOICE Réservé à la téléphonie IP

Après leur création, chaque port du switch a été affecté au VLAN correspondant.

Les ports utilisés par les serveurs ont été placés dans le VLAN 10 tandis que les ports
destinés aux utilisateurs ont été configurés dans le VLAN 20.

Les ports assurant les communications entre les switches ont été configurés en mode Trunk
afin de transporter simultanément les différents VLAN.

Une fois cette configuration terminée, plusieurs commandes de vérification ont été exécutées
afin de contrôler que tous les ports appartenaient bien au bon VLAN.

Les commandes show vlan brief, show interfaces status et show interfaces trunk nous ont
permis de vérifier le bon fonctionnement de cette partie du réseau.

4.5 Configuration des routeurs

Une fois les switches configurés, nous avons procédé à la configuration des différents
routeurs.

Chaque routeur a reçu les adresses IP prévues dans le plan d'adressage.

Les interfaces Gigabit Ethernet ont été configurées afin d'assurer la communication avec les
réseaux locaux, tandis que les interfaces série ont été utilisées pour les liaisons entre les
différents sites.
Après l'attribution des adresses IP, toutes les interfaces ont été activées à l'aide de la
commande no shutdown.

Pour les interfaces série jouant le rôle de DCE, un clock rate a également été configuré afin
d'assurer la synchronisation des liaisons.

Une fois les interfaces configurées, plusieurs vérifications ont été réalisées grâce à la
commande :

show ip interface brief

Cette commande nous a permis de confirmer que toutes les interfaces importantes étaient
dans l'état up/up, signe que les connexions étaient opérationnelles.
4.6 Configuration du routage dynamique OSPF

Après avoir configuré les adresses IP, nous avons mis en place le protocole de routage
dynamique OSPF.

Le choix de ce protocole permet aux routeurs d'échanger automatiquement leurs informations

de routage sans qu'il soit nécessaire de configurer manuellement des routes statiques.

Chaque routeur a été intégré dans le même Area 0, ce qui simplifie la configuration et facilite
la communication entre tous les sites.

Une fois la configuration terminée, les voisins OSPF ont commencé à échanger leurs routes
automatiquement.

Plusieurs commandes ont été utilisées afin de vérifier le bon fonctionnement du protocole,
notamment :
 • show ip route
• show ip ospf neighbor

Ces commandes ont confirmé que toutes les agences pouvaient communiquer correctement
entre elles.

Fin de la première partie du chapitre 4

4.7 Configuration des services réseau

Une fois l'infrastructure réseau mise en place et le routage fonctionnel, nous avons procédé à
la configuration des différents services réseau installés au siège social de Dakar.

Le choix de centraliser ces services au niveau du siège permet à toutes les agences de
bénéficier des mêmes ressources sans avoir à installer un serveur dans chaque site. Cette
organisation simplifie également l'administration du réseau et facilite la maintenance des
différents services.

Les services configurés sont le serveur DHCP, le serveur DNS, le serveur Web, le serveur
FTP ainsi que le serveur Call Manager destiné à la téléphonie IP.
4.7.1 Configuration du serveur DHCP

Le serveur DHCP a été installé afin d'automatiser l'attribution des adresses IP aux postes
clients.

Sans ce service, chaque ordinateur devrait être configuré manuellement, ce qui deviendrait
rapidement difficile à gérer avec un grand nombre de machines.

Le serveur DHCP a donc été configuré avec plusieurs plages d'adresses correspondant aux
différents réseaux de l'entreprise.

Chaque plage contient notamment :

• le réseau concerné ;
• le masque de sous-réseau ;
• la passerelle par défaut ;
• l'adresse du serveur DNS.

Grâce à cette configuration, lorsqu'un ordinateur est connecté au réseau et configuré en mode
DHCP, il reçoit automatiquement tous les paramètres nécessaires à son fonctionnement.

Pour permettre aux agences distantes d'obtenir elles aussi une adresse IP depuis le serveur
DHCP situé à Dakar, la commande ip helper-address a été configurée sur les interfaces
LAN des routeurs des agences.
Cette commande permet de relayer les requêtes DHCP vers le serveur central.

Après la configuration, plusieurs tests ont été réalisés afin de vérifier que les postes clients
obtenaient correctement une adresse IP et pouvaient communiquer avec leur passerelle.

4.7.2 Configuration du serveur DNS

Le serveur DNS joue un rôle essentiel dans le fonctionnement du réseau.

Son objectif est de traduire les noms de domaine en adresses IP afin que les utilisateurs
n'aient pas besoin de mémoriser les différentes adresses des serveurs.

Dans notre projet, le serveur DNS a reçu l'adresse IP [Link].

Les principaux enregistrements suivants ont été créés :

Nom de domaine Adresse IP

[Link] [Link]
[Link] [Link]

Après cette configuration, nous avons vérifié le fonctionnement du service grâce à la

commande nslookup.

Les résultats obtenus ont confirmé que les noms de domaine étaient correctement résolus vers
les adresses IP correspondantes.

Au cours du projet, nous avons rencontré plusieurs difficultés avec ce serveur. Malgré une
configuration correcte, certaines réponses restaient incohérentes. Après plusieurs
vérifications, nous avons décidé de remplacer entièrement le serveur DNS. Une fois le
nouveau serveur configuré avec les mêmes paramètres, le service a fonctionné normalement
et les tests de résolution de noms ont été concluants.
4.7.3 Configuration du serveur Web

Le serveur Web a été configuré afin de mettre à disposition un site interne accessible depuis
l'ensemble du réseau.

Ce serveur possède l'adresse [Link].

Le service HTTP a été activé directement dans Cisco Packet Tracer.

Une fois cette configuration terminée, plusieurs tests ont été réalisés à partir des postes clients
en ouvrant un navigateur Web.

L'accès à l'adresse IP du serveur a permis d'afficher correctement la page Web par défaut
proposée par Cisco Packet Tracer.

Ce résultat confirme que les utilisateurs des différentes agences peuvent accéder au serveur
Web du siège à travers le réseau.
4.7.4 Configuration du serveur FTP

Le serveur FTP a été installé afin de permettre le partage de fichiers entre les différents sites
de l'entreprise.

Le serveur utilise l'adresse [Link].

Après avoir activé le service FTP, plusieurs essais de connexion ont été réalisés.

Les tests de connectivité (ping) ont montré que le serveur était parfaitement joignable depuis
les autres équipements du réseau.

En revanche, l'ouverture d'une session FTP dans Cisco Packet Tracer a parfois affiché le
message :

Error opening... Disconnecting from FTP server.

Après plusieurs vérifications (configuration IP, passerelle, service activé, connectivité
réseau), aucune erreur de configuration n'a été identifiée.

Nous avons donc conclu que ce comportement provenait probablement d'une limitation ou
d'un dysfonctionnement de Cisco Packet Tracer, car le serveur répondait correctement aux
tests réseau classiques.

Cette limitation n'a pas empêché la validation du reste de l'infrastructure.

4.7.5 Configuration du serveur Call Manager

Le dernier serveur installé au siège est le serveur Call Manager, destiné à la gestion de la
téléphonie IP.

Ce serveur possède l'adresse [Link].

Sa configuration réseau a été réalisée comme pour les autres serveurs, avec une adresse IP
fixe, une passerelle par défaut et le serveur DNS.

Cependant, lors de la mise en œuvre, nous avons constaté que la version de Cisco Packet
Tracer utilisée ne proposait pas le service IP Telephony permettant de configurer
entièrement le Call Manager.
Cette limitation nous a empêchés de réaliser une configuration complète de la téléphonie IP.

Malgré cela, le serveur reste correctement intégré au réseau et répond aux tests de
connectivité. Dans un environnement réel ou avec une version plus complète des outils Cisco,
cette partie pourrait être finalisée sans modifier l'architecture générale du projet.

Bilan de cette étape

À l'issue de cette phase, l'ensemble des services principaux de l'entreprise était installé et
configuré.

Le serveur DHCP distribuait les adresses IP aux postes clients, le serveur DNS assurait la
résolution des noms de domaine, le serveur Web était accessible depuis le réseau et les
différents équipements communiquaient correctement entre eux.

Seuls le service FTP et la téléphonie IP ont présenté certaines limitations liées à

l'environnement de simulation utilisé, sans remettre en cause le fonctionnement global de
l'infrastructure.

Chapitre 5 : Tests et validation du réseau

5.1 Objectif des tests

Après avoir terminé la configuration des différents équipements et services, il était

indispensable de vérifier que le réseau fonctionnait correctement.

Cette phase de test permet de confirmer que les différentes configurations réalisées répondent
bien aux besoins de l'entreprise et que les utilisateurs peuvent accéder aux ressources
disponibles sur le réseau.

Les tests ont été réalisés progressivement, en commençant par les communications locales
avant de vérifier les échanges entre les différents sites.
5.2 Vérification des interfaces réseau

La première étape a consisté à vérifier que toutes les interfaces des routeurs étaient
correctement configurées et activées.

Pour cela, nous avons utilisé la commande :

show ip interface brief

Cette commande permet d'afficher rapidement toutes les interfaces du routeur ainsi que leur
état.

Les résultats obtenus ont montré que les interfaces utilisées dans le projet étaient dans l'état
up/up, ce qui signifie que les connexions physiques et logiques étaient correctement établies.

Cette vérification a été réalisée sur chacun des routeurs afin de s'assurer que toutes les
agences étaient bien connectées.

5.3 Vérification des VLAN

Après la configuration des switches, plusieurs commandes ont été exécutées afin de vérifier
la bonne répartition des ports dans les différents VLAN.

Les principales commandes utilisées sont :

show vlan brief

et

show interfaces status

Ces vérifications ont permis de confirmer que :

• les serveurs appartiennent bien au VLAN 10 ;

• les postes utilisateurs sont placés dans leur VLAN respectif ;
• les ports Trunk assurent correctement le transport des VLAN entre les switches.

Cette étape était importante car une mauvaise affectation des ports aurait empêché les
équipements de communiquer correctement.

5.4 Vérification du routage OSPF

Une fois les routeurs configurés, nous avons vérifié le fonctionnement du protocole OSPF.

Les commandes suivantes ont été utilisées :

show ip route
show ip ospf neighbor

Les résultats obtenus ont confirmé que les différents routeurs échangeaient correctement leurs
informations de routage.

Grâce à OSPF, chaque routeur connaissait automatiquement les réseaux des autres agences,
ce qui permettait aux utilisateurs de communiquer entre les différents sites sans configuration
supplémentaire.

5.5 Test de connectivité

Plusieurs tests de connectivité ont ensuite été réalisés à l'aide de la commande ping.
Ces tests avaient pour objectif de vérifier que les différents équipements pouvaient
communiquer entre eux.

Parmi les principaux tests effectués, on peut citer :

• communication entre les postes clients et leur passerelle ;

• communication entre les agences ;
• communication avec les serveurs du siège ;
• communication entre les routeurs.

Les résultats obtenus ont montré que les échanges entre les différents sites fonctionnaient
correctement.

Les serveurs DHCP, DNS, Web et FTP répondaient également aux requêtes réseau, ce qui
confirme le bon fonctionnement de l'interconnexion.

5.6 Vérification du serveur DHCP

Le serveur DHCP a été testé afin de vérifier qu'il distribuait correctement les adresses IP aux
postes clients.

Les ordinateurs configurés en mode DHCP ont reçu automatiquement :

• une adresse IP ;
• le masque de sous-réseau ;
• la passerelle par défaut ;
• l'adresse du serveur DNS.

Cette étape a permis de confirmer que le service DHCP était opérationnel et que les routeurs
relayaient correctement les requêtes grâce à la commande ip helper-address.

5.7 Vérification du serveur DNS

Le fonctionnement du serveur DNS a été vérifié grâce à la commande :

nslookup [Link]

Le résultat obtenu était le suivant :

Server : [Link]

Name : [Link]

Address : [Link]
Ce résultat montre que le serveur DNS traduit correctement le nom de domaine en adresse IP.

Cette vérification confirme que les utilisateurs peuvent accéder aux services de l'entreprise en
utilisant un nom plutôt qu'une adresse IP.

5.8 Vérification du serveur Web

Le serveur Web a été testé depuis un navigateur Web.

L'accès à l'adresse :

[Link]

a permis d'afficher correctement la page Web par défaut de Cisco Packet Tracer.

Ce test confirme que le serveur HTTP est accessible depuis le réseau et que les utilisateurs
peuvent consulter les ressources hébergées au siège.

5.9 Vérification du serveur FTP

Le serveur FTP a également fait l'objet de plusieurs tests.

Les tests Ping ont montré que le serveur répondait correctement aux requêtes réseau.

Cependant, lors de la tentative de connexion FTP, Cisco Packet Tracer affichait parfois le
message :

Error Opening... Disconnecting from FTP Server

Après plusieurs vérifications (adresse IP, passerelle, service activé, connectivité réseau),
aucune erreur de configuration n'a été trouvée.

Nous avons donc considéré que ce comportement était lié aux limites du simulateur Cisco
Packet Tracer et non à une erreur de configuration.

5.10 Vérification de la téléphonie IP

Le serveur Call Manager a été correctement installé et configuré au niveau du réseau.

En revanche, la version de Cisco Packet Tracer utilisée ne proposait pas le module IP

Telephony, ce qui ne nous a pas permis de finaliser entièrement la configuration des
téléphones IP.

Malgré cette limitation, les équipements étaient correctement connectés et prêts à être
intégrés dans une infrastructure réelle.
5.11 Bilan des tests

À la fin de cette phase de validation, les principaux objectifs du projet ont été atteints.

Les différents sites communiquent correctement grâce au protocole OSPF.

Les utilisateurs peuvent accéder aux principaux services installés au siège social.

Les tests réalisés ont permis de confirmer le bon fonctionnement du réseau dans son
ensemble.

Les seules limites observées concernent le serveur FTP ainsi que la téléphonie IP, limitations
principalement dues aux fonctionnalités disponibles dans Cisco Packet Tracer.

Conclusion du chapitre

Cette phase de validation nous a permis de confirmer que les configurations réalisées
répondaient aux besoins définis au début du projet. Les différents tests ont montré que
l'infrastructure est fonctionnelle et que les services essentiels sont accessibles depuis les
différents sites de l'entreprise.

Chapitre 6 : Difficultés rencontrées et solutions

apportées
6.1 Introduction

Comme tout projet d'interconnexion réseau, la réalisation de cette infrastructure ne s'est pas
déroulée sans difficultés. Plusieurs problèmes techniques sont apparus au cours de la
configuration des équipements et des différents services.

Chaque difficulté rencontrée a nécessité une phase d'analyse, de recherche et de vérification

avant d'identifier la cause du problème et d'apporter une solution adaptée.

Cette partie présente les principaux problèmes rencontrés ainsi que les solutions mises en
œuvre.
6.2 Problème de configuration des liaisons série

L'une des premières difficultés rencontrées concernait les liaisons série entre les différents
routeurs.

Au début du projet, certaines interfaces série restaient dans l'état down, ce qui empêchait la
communication entre les agences.

Après plusieurs vérifications, nous avons constaté que certaines interfaces n'étaient pas
activées ou que le clock rate n'était pas configuré sur les interfaces DCE.

Pour résoudre ce problème, nous avons :

• identifié les interfaces DCE ;

• configuré le clock rate sur ces interfaces ;
• activé les interfaces avec la commande no shutdown.

Une fois ces modifications réalisées, les liaisons sont passées à l'état up/up, ce qui a permis
d'établir la communication entre les routeurs.

6.3 Difficultés liées au protocole OSPF

Lors de la configuration du routage dynamique, les routeurs ne s'échangeaient pas

immédiatement leurs routes.

Après analyse, nous avons constaté que certaines interfaces n'étaient pas correctement
annoncées dans le processus OSPF.

Nous avons donc revérifié les commandes network configurées sur chaque routeur afin de
nous assurer que tous les réseaux locaux et toutes les liaisons série étaient bien pris en
compte.

Après correction, les voisins OSPF ont été établis et les routes ont été propagées
automatiquement.

Les commandes de vérification ont confirmé que chaque routeur connaissait désormais les
réseaux des autres agences.

6.4 Difficultés rencontrées avec le serveur DNS

Le serveur DNS a constitué la principale difficulté de ce projet.

Malgré une configuration correcte de son adresse IP, de sa passerelle, de son serveur DNS et
des enregistrements, certaines requêtes continuaient à échouer de manière aléatoire.
Nous avons effectué de nombreuses vérifications :

• contrôle de la configuration IP ;
• vérification de la passerelle ;
• tests Ping ;
• contrôle des tables ARP ;
• vérification du switch ;
• vérification du routeur ;
• vérification des enregistrements DNS.

Aucune erreur de configuration n'a été détectée.

Après plusieurs essais, nous avons décidé de remplacer complètement le serveur DNS par un
nouveau serveur configuré avec les mêmes paramètres.

Cette solution a permis de retrouver un fonctionnement normal du service et les commandes

nslookup ont ensuite donné les résultats attendus.

Cette expérience montre que certains comportements peuvent être liés au simulateur Cisco
Packet Tracer plutôt qu'à une erreur de configuration.

6.5 Difficultés avec le serveur FTP

Le serveur FTP répondait correctement aux requêtes Ping, ce qui montrait que la connectivité
réseau était fonctionnelle.

Cependant, lors des tentatives de connexion FTP, Cisco Packet Tracer affichait régulièrement
le message :

Error Opening... Disconnecting from FTP Server

Nous avons vérifié :

• l'adresse IP ;
• la passerelle ;
• le service FTP ;
• la connectivité réseau ;
• les tests Ping.

Tous ces éléments étaient correctement configurés.

Nous avons donc conclu que cette anomalie était probablement liée à une limitation du
logiciel Cisco Packet Tracer et non à une erreur de configuration.
6.6 Difficultés liées à la téléphonie IP

Le sujet demandait la mise en place de la téléphonie IP à l'aide d'un serveur Call Manager.

Le serveur a été installé et configuré avec succès.

En revanche, lors de la configuration, nous avons constaté que la version de Cisco Packet
Tracer utilisée ne proposait pas le service IP Telephony, indispensable pour finaliser la
configuration des téléphones IP.

Cette limitation ne nous a donc pas permis d'aller jusqu'au bout de cette partie.

Nous avons néanmoins préparé toute l'infrastructure nécessaire afin que cette fonctionnalité
puisse être ajoutée dans un environnement plus complet.

6.7 Difficultés rencontrées pendant les tests

Au cours des différents tests, certains résultats semblaient parfois contradictoires.

Par exemple, certains équipements répondaient correctement au Ping alors que certains
services restaient momentanément inaccessibles.

Afin d'éviter toute erreur d'interprétation, nous avons systématiquement utilisé plusieurs
méthodes de vérification :

• Ping ;
• ARP ;
• tables MAC ;
• commandes Cisco ;
• tests HTTP ;
• tests DNS.

Cette démarche nous a permis d'identifier plus facilement l'origine réelle des problèmes
rencontrés.

6.8 Enseignements tirés

La réalisation de ce projet nous a permis de comprendre que la mise en place d'une

infrastructure réseau ne consiste pas uniquement à configurer des équipements.

Chaque étape nécessite de nombreuses vérifications afin de s'assurer que toutes les
configurations sont cohérentes.
Nous avons également appris l'importance de procéder méthodiquement lors du dépannage,
en vérifiant successivement les connexions physiques, les adresses IP, le routage, les VLAN
puis les différents services.

Cette expérience nous a permis de renforcer notre compréhension des réseaux d'entreprise
ainsi que des outils de simulation comme Cisco Packet Tracer.

Conclusion du chapitre
Les différentes difficultés rencontrées tout au long du projet ont constitué une véritable
opportunité d'apprentissage.

Chaque problème résolu nous a permis de mieux comprendre le fonctionnement des réseaux,
d'améliorer notre méthode de diagnostic et de développer une démarche plus rigoureuse dans
la résolution des incidents.

Conclusion générale
Au terme de ce projet, nous avons réussi à concevoir et à mettre en place une infrastructure
réseau permettant d'interconnecter le siège social de Dakar avec les agences de Thiès, Mbour,
Kaolack et Saint-Louis. Les différentes étapes, allant de la conception du réseau jusqu'à la
configuration des équipements, nous ont permis d'appliquer les notions étudiées en cours
dans un cas pratique.

Le protocole de routage dynamique OSPF a permis d'assurer la communication entre les

différents sites, tandis que les principaux services du siège (DHCP, DNS, Web et FTP) ont
été installés et configurés. Malgré quelques difficultés rencontrées, notamment avec le
serveur FTP et la téléphonie IP, nous avons pu atteindre les objectifs essentiels du projet. Les
limites observées sont principalement liées aux fonctionnalités disponibles dans Cisco Packet
Tracer.

Ce travail nous a également permis de développer une meilleure maîtrise de Cisco Packet
Tracer, de la configuration des routeurs et des switches Cisco, de l'adressage IP, des VLAN
ainsi que du routage dynamique OSPF. Il nous a surtout appris à analyser les problèmes
rencontrés, à effectuer des vérifications méthodiques et à rechercher des solutions adaptées.

En conclusion, ce projet constitue une excellente expérience pratique et une bonne initiation à
la conception d'un réseau d'entreprise multi-sites. Il nous a permis de renforcer nos
compétences techniques tout en nous préparant aux situations que nous pourrons rencontrer
dans le domaine des réseaux et télécommunications.