Section II : Conduite du projet
IV.II.1. Contexte et Problématique
La BCC dispose d'un réseau volumineux et de multiples
services entre autres transférer les fonds, créditer les fonds,
débuter les fonds,... utilise une convergence totale vers le protocole
IP pour pouvoir desservir sa clientèle. Ce dernier est limité
à certain niveau, ainsi le protocole IP est un protocole de niveau 3
fonctionnant en mode non connecté. La décision de routage d'un
paquet est faite localement par chaque noeud et imaginons le grand
réseau de BCC cela n'entrainera pas la rapidité au niveau de la
commutation des paquets.
De ce fait, l'émetteur d'un paquet ne pourra pas
prévoir le chemin qui sera emprunté par ce dernier. Alors pour
une optimisation de la QOS au niveau des clients de BCC, nous voyons quelques
faiblesses pour le bon fonctionnement des services à travers le
protocole IP au le sein du coeur du réseau de la BCC.
Cependant, vu que dans ce type de réseau,
l'évolution matérielle est indéniable, il est
nécessaire de trouver les voies et moyens afin de mettre sur pied, une
infrastructure réseau devant assurer l'interconnexion absolue, rapide et
sécurisée entre plusieurs sites distants.
IV.II.2. Méthodologie
Il est important pour nous ici de définir succinctement
les différentes
étapes à suivre pour atteindre les objectifs
visés par notre travail.
1ère étape : Etude et choix des
solutions VPN/MPLS
2ème étape : Mise en place de la
solution VPN/MPLS choisie :
Dans cette partie nous allons rapporter les étapes et les
commandes
nécessaires pour configurer MPLS.VPN sur GNS3, Virtual box
et les IOS CISCO utilisées
pour la virtualisation, à savoir :
? Configuration basic de MPLS
? Mise en place du protocole de routage intra-nuage OSPF ;
Page 78 sur 109
? Mise en place du protocole MP-BGP
? Mise en place des VRS et des interfaces
? Mise en place du protocole de routage CE_PE (RIPv2)
? Gestion de la redistribution des préfixes
Bien que d'après nos recherches il y'a plusieurs
protocoles pour la
configuration, nous avons préféré cela
à cause de la présence des notions vues et
en cours et tout de même on a personnalisé le
travail.
3ème étape : Quelques tests de
fonctionnement de la solution implémentée
IV.II.3. Déploiement de la
solution MPLS/VPN
La réalisation de la solution étant une phase
très capitale, sera axée sur trois (3) points essentiels entre
autres, la Maquette MPLS Opérations du coeur
de notre réseau MPLS/VPN, le Schéma physique VPN/MPLS,
Schéma MPLS Configurations du coeur MPLS/VPN.
IV.II.3.1. Présentation de la maquette de notre
déploiement
Le schéma physique du coeur réseau de la
maquette MPLS/VPN de notre déploiement est illustré dans la
figure ci-après :
Page 78 sur 109
Figure IV.II.3.1: Maquette MPLS Opérations
IV.II.3.2. Schéma fonctionnel du coeur MPLS/VPN
Le schéma ci-dessous, nous présentons le
schéma fonctionnel du coeur de réseau MPLS/VPN.
Page 79 sur 109
Page 79 sur 109
Figure IV.II.3.2. : Le MPLS
Configurations coeur MPLS/VPN
IV.II.3. Plan d'adressage
Un plan d'adressage sert à déterminer l'adresse IP
du réseau, du sous-réseau et donc des équipements
(ordinateur, imprimante, etc..) qui composent le réseau d'entreprise
afin de réduire les possibilités de connexion.
A cet effet, le tableau qui suit montre la répartition des
adresses IP de notre réseau :
Tableau IV.II.3. : Plan
d'adressage
Routeurs Interfaces Adresse IP Adresse
Loopback
|
CEA
|
fi0/0
|
11.0.0.0/24
|
-
|
|
CEB
|
f0/0
|
18.0.0.0/24
|
-
|
|
CEC
|
f0/0
|
19.0.0.0/24
|
-
|
|
PE1
|
f0/0
|
12.0.0.0/24
|
10.10.10.10/32
|
|
f0/1
|
11.0.0.0/24
|
|
PE2
|
f0/0
|
16.0.0.0/24
|
20.20.20.20/32
|
|
f0/1
|
18.0.0.0/24
|
|
PE3
|
f0/0
|
17.0.0.0/24
|
30.30.30.30/32
|
|
f0/1
|
19.0.0.0/24
|
|
P1
|
f0/0
|
13.0.0.0/24
|
1.1.1.1/32
|
|
f0/1
|
12.0.0.0/24
|
|
f0/2
|
15.0.0.0/24
|
|
P2
|
f0/0
|
13.0.0.0/24
|
2.2.2.2/32
|
|
f0/1
|
15.0.0.0/24
|
|
f0/2
|
16.0.0.0/24
|
|
P3
|
f0/0
|
15.0.0.0/24
|
3.3.3.3/32
|
|
f0/1
|
14.0.0.0/24
|
|
f0/2
|
17.0.0.0/24
|
Ici nous précisons que le choix d'adressage a
été fait avec des adresses publiques tout au coeur du
réseau MPLS vu que c'est notre réseau opérateur et nous
avons utilisé les adresses privées pour les machines et routeurs
du client qui sont hors du coeur du réseau.
Page 80 sur 109
Page 80 sur 109
IV.II.4. Méthodologie d'approche
Dans cette partie nous allons rapporter les étapes et les
commandes
nécessaires pour configurer MPLS/VPN sur GNS3, à
savoir :
4. Configuration des interfaces sur chaque routeur
4. la mise en place du protocole de routage intra-nuage OSPF
4. Configuration MPLS
4. Configuration des VRF
4. Mise en place du protocole EIGRP
4. Configuration du protocole BGP
4. Gestion de la redistribution respective des préfixes
4. Configuration de la QOS
IV.II.5. Résultat et
vérification
IV.II.5.1. configuration des interfaces et la mise en
place du protocole de routage intra-nuage OSPF
Cette configuration sera appliquée sur chaque interface
des routeurs respectivement comme dans cette architecture de manière
à respecter le choix d'adressage et de pouvoir s'assurer que l'adressage
a été bien fait et que les noms des routeurs ont
été bien mis en place pour un repérage facile de ces
derniers.
En plus, nous avons l'adresse réseau et le masque
générique pour pouvoir déclarer les réseaux qui
participeront au processus ospf donc on fera pareil pour tous les
différents sous réseaux que nous devons appliquer le protocole
OSPF au sein du coeur du réseau).
Donc on appliquera le protocole OSPF au sein des interfaces
respectives se trouvant au Coeur du réseau à savoir PE1, PE2,
PE3, P1, P2, P3, CEA, CEB et CEC. Le protocole de routage interne au Backbone
sera actif sur les LER et LSR du Backbone IP partagé. Il permettra
d'abord d'assurer la connectivité IP entre les routeurs du Backbone puis
l'établissement de session TDP (Tag Distribution Protocol) issu de Cisco
ou LDP.
? Test :
- PING from PE1 to PE2/PE3
# ping 20.20.20.20
Figure IV.II.5.1. : Test Basic Configuration
1
# ping 30.30.30.30
Figure IV.II.5.1. : Test Basic Configuration
2
Avant de passer à autres choses on doit pinger pour tester
les diagnostics pour que l'on corrige en cas d'erreurs.
Page 81 sur 109
- Routing Table :
# show ip route ospf | begin Gateway
Figure IVII.5.1. : Routing table:
Jusque-là la table de routage fonctionne normalement.
IV.II.6.2. Mise en place du protocole LDP :
? Test :
#do show mpls interfaces
Figure IV.II.5.2. : Test MPLS
interfaces
A ce niveau après le test on trouve que les interfaces
sont bien configurées y compris les adresses IP même si les
tunnels ne sont pas encore là et les BGP mais tout de même les
MPLS sont opérationnels.
#do show mpls ldp neighbor
Page 81 sur 109
Figure IV.II.5.2.: Test
MPLS LDP Neighbor
Page 82 sur 109
Page 82 sur 109
Ici on voit une autre commande pour savoir les voisins de
votre routeur, on voit même les clefs d'identifiant et toutes les
informations sans oublier les paquets envoyées et reçues etc.
#do traceroute 20.20.20.20
Figure IV.II.5.2. : Test trace
route:
On vérifie encore si la route est opérationnelle
vers les autres routeurs et oui on a remarqué que faisable en voyant
même le timing.
IV.II.5.3. Mise en place du protocole MP-BGP
:
A ce niveau on utilise ce protocole pour créer les
tunnels entre les PE pour éviter tout simplement d'échanger les
adresses IP du Backbone avec ceux des clients et la solution est de configurer
le MP-BGP de la manière que voici : PE, PE2 et PE1 :
A savoir si l'interface entre PE1 et P1 tombe en panne on va
perdre
tous.
? Test :
#do show bgp vpnv4 unicast all summary
Figure IV.II.5.3 : Test BGP
Alors on vérifie le test comme après chaque
configuration, comme on nous l'avons remarqué ils s'échangent des
messages donc tout est bien jusque-là ! si jamais cette table
était vite donc là on a un problème de configuration.
IV.II.5.4. Mise en place des VRS et des interfaces
:
Ici on vérifie les tables de routage mais il est
possible de configurer si on a des clients par exemple CE1, CEB et CEC de notre
configuration et il est possible de les affecter les mêmes adresses IP ce
qui est une erreur affichée par le routeur c'est-à-dire les
conflits des adresses. Alors avec le VRF on va créer plusieurs tables de
routage dans le même routeur mais il est possible de créer les
instances de routage. - PE1, PE2 et PE3 :
Page 83 sur 109
Page 83 sur 109
#do show run interface FastEthernet 1/0
Figure IV.II.5.4 Run interface
F1/0
Voilà on voit que cette interface est déjà
configurée.
IV.II.5.4. Mise en place du protocole de routage CE_PE
(RIPv2):
IV.II.5.5. Gestion de la redistribution des
préfixes entre OSPF 1000 et BGP 1 :
- PE1 & PE2 & PE3 :
? Test :
# do show ip route
Figure IV.II.5.6 : IP Route 1
Avec cette image, on a vérifié les
itinéraires statistiques dans la table routage en utilisant la commande
show IP route, en spécifiant l'adresse réseau, le masque de
sous-réseau et l'adresse IP du routeur du prochain saut ou de
l'interface de sortie. Et ça fonctionner !
# ping CE_B / CE_C
Après avoir configuré ces interfaces, on
constate que les CEA, CEB et CEC peuvent pinger et communiquer sans
problème !
Figure IV.II.5.6 Test Ping CEB et CEC
2
Page 84 sur 109
Page 84 sur 109
# do show mpls forwarding-table
Figure IV.II.5.6 : Mpls forwarding-table
3
A noter qu'une table de transfert MPLS détermine la
manière dont MPLS traite les paquets MPLS reçus. Lorsqu'un paquet
MPLS arrive sur une interface principale MPLS, MPLS recherche
l'étiquette ou label MPLS la plus externe du paquet reçu de la
table de transfert MPLS approprié.
Enfin, étant sur une interface du routeur coeur du
réseau à savoir PE ou un routeur d'extrémité PE
nous pouvons visualiser la table de MPLS ou nous pouvons observer le label qui
le leur est assigné, les interfaces de sortie et autres. Ceci
grâce à une commande show mpls forwarding-table.
IV.II.5.7. Configuration de la QOS
? Test :
#show class-map
La QoS ici a été géré avec la
création des class-map pour chaque service que l'on souhaite
contrôler le flux à travers les classes au niveau du champ dscp.
La configuration est utilisée pour placer le plus prioritaire au trafic
du port TCP auquel il correspond et les autres avec leur priorité
respective de manière à pouvoir assurer un service de
qualité pour les utilisateurs.
Figure IV.II.5.7 : Résultat concernant la
QOS
IV.II.5.7.1. La création de la
class-map
Une Access Control List permet de filtrer les paquets
IP, c'est à dire les paquets du niveau 3. Elle permet de
définir les actions possibles des utilisateurs du réseau.
Page 85 sur 109
Page 85 sur 109
IV.II.5.7.2. Création des access
list
Pour une bonne implémentation de notre QoS nous avons
fait des tests avec notre serveur Debian 6.01 contenant les services EMAIL,
SMTP, VOIP, HTTP et VOICE et avons essayé de charger le serveur avec le
Ping de la mort de manière à imaginer qu'un gros
téléchargement était effectué puis nous avons
effectué un appel entre les plusieurs sites pour tester la liaison ceci
en imaginant plusieurs clients VPN qui se transmettaient les informations.
Ainsi avec la notion de classe appliquée à chaque flux nous avons
eu une stabilité du service malgré la perturbation que nous avons
fait subir au flux.
| 
